diff --git a/Dockerfile b/Dockerfile index d76317ff7f..3e3335076c 100644 --- a/Dockerfile +++ b/Dockerfile @@ -14,7 +14,9 @@ RUN apk add --no-cache \ openssh-client \ rsync \ build-base \ - libc6-compat + libc6-compat \ + npm && \ + npm install -G autoprefixer postcss-cli ARG HUGO_VERSION diff --git a/Makefile b/Makefile index be53b5eac9..56ec8410f4 100644 --- a/Makefile +++ b/Makefile @@ -4,9 +4,10 @@ NETLIFY_FUNC = $(NODE_BIN)/netlify-lambda # The CONTAINER_ENGINE variable is used for specifying the container engine. By default 'docker' is used # but this can be overridden when calling make, e.g. -# CONTAINER_ENGINE=podman make container-image +# CONTAINER_ENGINE=podman make container-image CONTAINER_ENGINE ?= docker -CONTAINER_IMAGE = kubernetes-hugo +IMAGE_VERSION=$(shell scripts/hash-files.sh Dockerfile Makefile | cut -c 1-12) +CONTAINER_IMAGE = kubernetes-hugo:v$(HUGO_VERSION)-$(IMAGE_VERSION) CONTAINER_RUN = $(CONTAINER_ENGINE) run --rm --interactive --tty --volume $(CURDIR):/src CCRED=\033[0;31m @@ -17,12 +18,15 @@ CCEND=\033[0m help: ## Show this help. @awk 'BEGIN {FS = ":.*?## "} /^[a-zA-Z_-]+:.*?## / {sub("\\\\n",sprintf("\n%22c"," "), $$2);printf "\033[36m%-20s\033[0m %s\n", $$1, $$2}' $(MAKEFILE_LIST) +module-check: + @git submodule status --recursive | awk '/^[+-]/ {printf "\033[31mWARNING\033[0m Submodule not initialized: \033[34m%s\033[0m\n",$$2}' 1>&2 + all: build ## Build site with production settings and put deliverables in ./public -build: ## Build site with production settings and put deliverables in ./public +build: module-check ## Build site with production settings and put deliverables in ./public hugo --minify -build-preview: ## Build site with drafts and future posts enabled +build-preview: module-check ## Build site with drafts and future posts enabled hugo --buildDrafts --buildFuture deploy-preview: ## Deploy preview site via netlify @@ -39,7 +43,7 @@ production-build: build check-headers-file ## Build the production site and ensu non-production-build: ## Build the non-production site, which adds noindex headers to prevent indexing hugo --enableGitInfo -serve: ## Boot the development server. +serve: module-check ## Boot the development server. hugo server --buildFuture docker-image: @@ -60,10 +64,10 @@ container-image: --tag $(CONTAINER_IMAGE) \ --build-arg HUGO_VERSION=$(HUGO_VERSION) -container-build: - $(CONTAINER_RUN) $(CONTAINER_IMAGE) hugo +container-build: module-check + $(CONTAINER_RUN) $(CONTAINER_IMAGE) hugo --minify -container-serve: +container-serve: module-check $(CONTAINER_RUN) --mount type=tmpfs,destination=/src/resources,tmpfs-mode=0755 -p 1313:1313 $(CONTAINER_IMAGE) hugo server --buildFuture --bind 0.0.0.0 test-examples: @@ -81,4 +85,3 @@ docker-internal-linkcheck: container-internal-linkcheck: link-checker-image-pull $(CONTAINER_RUN) $(CONTAINER_IMAGE) hugo --config config.toml,linkcheck-config.toml --buildFuture $(CONTAINER_ENGINE) run --mount type=bind,source=$(CURDIR),target=/test --rm wjdp/htmltest htmltest - diff --git a/OWNERS_ALIASES b/OWNERS_ALIASES index c2b0751dbe..9498e2c228 100644 --- a/OWNERS_ALIASES +++ b/OWNERS_ALIASES @@ -1,21 +1,4 @@ aliases: - sig-cluster-lifecycle-kubeadm-approvers: # Approving changes to kubeadm documentation - - timothysc - - lukemarsden - - luxas - - fabriziopandini - sig-cluster-lifecycle-kubeadm-reviewers: # Reviewing kubeadm documentation - - timothysc - - lukemarsden - - luxas - - fabriziopandini - - kad - - xiangpengzhao - - stealthybox - - liztio - - chuckha - - detiber - - dixudx sig-docs-blog-owners: # Approvers for blog content - castrojo - kbarnard10 @@ -40,30 +23,28 @@ aliases: - rlenferink sig-docs-en-owners: # Admins for English content - bradtopol - - daminisatya + - celestehorgan - jimangel - kbarnard10 - kbhawkey - makoscafee - onlydole - - Rajakavitha1 - savitharaghunathan - sftim - steveperry-53 - tengqm - - vineethreddy02 - xiangpengzhao - zacharysarah - zparnold sig-docs-en-reviews: # PR reviews for English content - bradtopol + - celestehorgan - daminisatya - jimangel - kbarnard10 - kbhawkey - makoscafee - onlydole - - rajakavitha1 - rajeshdeshpande02 - sftim - steveperry-53 @@ -111,12 +92,10 @@ aliases: - avidLearnerInProgress - daminisatya - mittalyashu - - Rajakavitha1 sig-docs-hi-reviews: # PR reviews for Hindi content - avidLearnerInProgress - daminisatya - mittalyashu - - Rajakavitha1 sig-docs-id-owners: # Admins for Indonesian content - girikuncoro - irvifa @@ -125,6 +104,7 @@ aliases: - irvifa - wahyuoi - phanama + - danninov sig-docs-it-owners: # Admins for Italian content - fabriziopandini - mattiaperi @@ -212,6 +192,7 @@ aliases: - potapy4 - dianaabv sig-docs-ru-reviews: # PR reviews for Russian content + - Arhell - msheldyakov - aisonaku - potapy4 @@ -233,4 +214,4 @@ aliases: - butuzov - idvoretskyi - MaxymVlasov - - Potapy4 + - Potapy4 \ No newline at end of file diff --git a/README-de.md b/README-de.md index 76087f403e..bf647d828f 100644 --- a/README-de.md +++ b/README-de.md @@ -15,7 +15,7 @@ Weitere Informationen zum Beitrag zur Kubernetes-Dokumentation finden Sie unter: * [Mitwirkung beginnen](https://kubernetes.io/docs/contribute/start/) * [Ihre Dokumentationsänderungen bereitstellen](http://kubernetes.io/docs/contribute/intermediate#view-your-changes-locally) -* [Seitenvorlagen verwenden](http://kubernetes.io/docs/contribute/style/page-templates/) +* [Seitenvorlagen verwenden](http://kubernetes.io/docs/contribute/style/page-content-types/) * [Dokumentationsstil-Handbuch](http://kubernetes.io/docs/contribute/style/style-guide/) * [Übersetzung der Kubernetes-Dokumentation](https://kubernetes.io/docs/contribute/localization/) diff --git a/README-es.md b/README-es.md index fe71a0fc40..ba2f13a80f 100644 --- a/README-es.md +++ b/README-es.md @@ -18,7 +18,7 @@ Para obtener más información sobre cómo contribuir a la documentación de Kub * [Empezando a contribuir](https://kubernetes.io/docs/contribute/start/) * [Visualizando sus cambios en su entorno local](http://kubernetes.io/docs/contribute/intermediate#view-your-changes-locally) -* [Utilizando las plantillas de las páginas](http://kubernetes.io/docs/contribute/style/page-templates/) +* [Utilizando las plantillas de las páginas](http://kubernetes.io/docs/contribute/style/page-content-types/) * [Guía de estilo de la documentación](http://kubernetes.io/docs/contribute/style/style-guide/) * [Traduciendo la documentación de Kubernetes](https://kubernetes.io/docs/contribute/localization/) diff --git a/README-fr.md b/README-fr.md index 37350a5b81..b493ea60f0 100644 --- a/README-fr.md +++ b/README-fr.md @@ -23,7 +23,7 @@ Pour plus d'informations sur la contribution à la documentation Kubernetes, voi * [Commencez à contribuer](https://kubernetes.io/docs/contribute/start/) * [Apperçu des modifications apportées à votre documentation](http://kubernetes.io/docs/contribute/intermediate#view-your-changes-locally) -* [Utilisation des modèles de page](http://kubernetes.io/docs/contribute/style/page-templates/) +* [Utilisation des modèles de page](https://kubernetes.io/docs/contribute/style/page-content-types/) * [Documentation Style Guide](http://kubernetes.io/docs/contribute/style/style-guide/) * [Traduction de la documentation Kubernetes](https://kubernetes.io/docs/contribute/localization/) diff --git a/README-ja.md b/README-ja.md index 3bc4fcd27a..8fab3900c8 100644 --- a/README-ja.md +++ b/README-ja.md @@ -1,7 +1,6 @@ # Kubernetesのドキュメント -[![Build Status](https://api.travis-ci.org/kubernetes/website.svg?branch=master)](https://travis-ci.org/kubernetes/website) -[![GitHub release](https://img.shields.io/github/release/kubernetes/website.svg)](https://github.com/kubernetes/website/releases/latest) +[![Netlify Status](https://api.netlify.com/api/v1/badges/be93b718-a6df-402a-b4a4-855ba186c97d/deploy-status)](https://app.netlify.com/sites/kubernetes-io-master-staging/deploys) [![GitHub release](https://img.shields.io/github/release/kubernetes/website.svg)](https://github.com/kubernetes/website/releases/latest) このリポジトリには、[KubernetesのWebサイトとドキュメント](https://kubernetes.io/)をビルドするために必要な全アセットが格納されています。貢献に興味を持っていただきありがとうございます！ @@ -14,7 +13,20 @@ Hugoがインストールできたら、以下のコマンドを使ってWebサ ```bash git clone https://github.com/kubernetes/website.git cd website -git submodule update --init --recursive +git submodule update --init --recursive --depth 1 +``` + +**注意:** Kubernetesのウェブサイトでは[DocsyというHugoのテーマ](https://github.com/google/docsy#readme)を使用しています。リポジトリを更新していない場合、 `website/themes/docsy`ディレクトリは空です。 このサイトはテーマのローカルコピーなしでは構築できません。 + +テーマをアップデートするには以下のコマンドを実行します: + +```bash +git submodule update --init --recursive --depth 1 +``` + +サイトをローカルでビルドしてテストするには以下のコマンドを実行します: + +```bash hugo server --buildFuture ``` @@ -33,11 +45,11 @@ hugo server --buildFuture GitHubの画面右上にある**Fork**ボタンをクリックすると、お使いのGitHubアカウントに紐付いた本リポジトリのコピーが作成され、このコピーのことを*フォーク*と呼びます。フォークリポジトリの中ではお好きなように変更を加えていただいて構いません。加えた変更をこのリポジトリに追加したい任意のタイミングにて、フォークリポジトリからPull Reqeustを作成してください。 -Pull Requestが作成されると、レビュー担当者が責任を持って明確かつ実用的なフィードバックを返します。 -Pull Requestの所有者は作成者であるため、**ご自身で作成したPull Requestを編集し、フィードバックに対応するのはご自身の役目です。** +Pull Requestが作成されると、レビュー担当者が責任を持って明確かつ実用的なフィードバックを返します。Pull Requestの所有者は作成者であるため、**ご自身で作成したPull Requestを編集し、フィードバックに対応するのはご自身の役目です。** + また、状況によっては2人以上のレビュアーからフィードバックが返されたり、アサインされていないレビュー担当者からのフィードバックが来ることがある点もご注意ください。 -さらに、特定のケースにおいては、レビュー担当者がKubernetesの技術的なレビュアーに対してレビューを依頼することもあります。 -レビュー担当者はタイムリーにフィードバックを提供するために最善を尽くしますが、応答時間は状況に応じて異なる場合があります。 + +さらに、特定のケースにおいては、レビュー担当者がKubernetesの技術的なレビュアーに対してレビューを依頼することもあります。レビュー担当者はタイムリーにフィードバックを提供するために最善を尽くしますが、応答時間は状況に応じて異なる場合があります。 Kubernetesのドキュメントへの貢献に関する詳細については以下のページをご覧ください: diff --git a/README-uk.md b/README-uk.md index 3aad33660a..f437535353 100644 --- a/README-uk.md +++ b/README-uk.md @@ -55,7 +55,7 @@ hugo server --buildFuture Більше інформації про внесок у документацію Kubernetes ви знайдете у наступних джерелах: * [Внесок: з чого почати](https://kubernetes.io/docs/contribute/) -* [Використання шаблонів сторінок](http://kubernetes.io/docs/contribute/style/page-templates/) +* [Використання шаблонів сторінок](https://kubernetes.io/docs/contribute/style/page-content-types/) * [Керівництво зі стилю оформлення документації](http://kubernetes.io/docs/contribute/style/style-guide/) * [Переклад документації Kubernetes іншими мовами](https://kubernetes.io/docs/contribute/localization/) diff --git a/README-zh.md b/README-zh.md index 8a7898774a..5b4353127f 100644 --- a/README-zh.md +++ b/README-zh.md @@ -1,74 +1,139 @@ # Kubernetes 文档 + +--> -[![Build Status](https://api.travis-ci.org/kubernetes/website.svg?branch=master)](https://travis-ci.org/kubernetes/website) -[![GitHub release](https://img.shields.io/github/release/kubernetes/website.svg)](https://github.com/kubernetes/website/releases/latest) +[![Netlify Status](https://api.netlify.com/api/v1/badges/be93b718-a6df-402a-b4a4-855ba186c97d/deploy-status)](https://app.netlify.com/sites/kubernetes-io-master-staging/deploys) [![GitHub release](https://img.shields.io/github/release/kubernetes/website.svg)](https://github.com/kubernetes/website/releases/latest) -欢迎！本仓库包含了所有用于构建 [Kubernetes 网站和文档](https://kubernetes.io/)的内容。 +This repository contains the assets required to build the [Kubernetes website and documentation](https://kubernetes.io/). We're glad that you want to contribute! +--> +本仓库包含了所有用于构建 [Kubernetes 网站和文档](https://kubernetes.io/) 的软件资产。 我们非常高兴您想要参与贡献！ + +## 在本地使用 Hugo 来运行网站 + +请参考 [Hugo 的官方文档](https://gohugo.io/getting-started/installing/)了解 Hugo 的安装指令。 +请确保安装的是 [`netlify.toml`](netlify.toml#L10) 文件中环境变量 `HUGO_VERSION` 所指定的 +Hugo 扩展版本。 + + +在构造网站之前，先克隆 Kubernetes website 仓库： + +```bash +git clone https://github.com/kubernetes/website.git +cd website +git submodule update --init --recursive +``` + + +**注意：** Kubernetes 网站要部署 [Docsy Hugo 主题](https://github.com/google/docsy#readme). +如果你还没有更新你本地的 website 仓库，目录 `website/themes/docsy` +会是空目录。 +在本地没有主题副本的情况下，网站无法正常构造。 + +使用下面的命令更新网站主题： + +```bash +git submodule update --init --recursive --depth 1 +``` + + +若要在本地构造和测试网站，请运行： + +```bash +hugo server --buildFuture +``` + + +上述命令会在端口 1313 上启动本地 Hugo 服务器。 +启动浏览器，打开 http://localhost:1313 来查看网站。 +当你对源文件作出修改时，Hugo 会更新网站并强制浏览器执行刷新操作。 + + +## 参与 SIG Docs 工作 + +通过 [社区页面](https://github.com/kubernetes/community/tree/master/sig-docs#meetings) +进一步了解 SIG Docs Kubernetes 社区和会议信息。 + +你也可以通过以下渠道联系本项目的维护人员： + +- [Slack](https://kubernetes.slack.com/messages/sig-docs) +- [邮件列表](https://groups.google.com/forum/#!forum/kubernetes-sig-docs) + -## 贡献文档 + +You can click the **Fork** button in the upper-right area of the screen to create a copy of this repository in your GitHub account. This copy is called a *fork*. Make any changes you want in your fork, and when you are ready to send those changes to us, go to your fork and create a new pull request to let us know about it. + +Once your pull request is created, a Kubernetes reviewer will take responsibility for providing clear, actionable feedback. As the owner of the pull request, **it is your responsibility to modify your pull request to address the feedback that has been provided to you by the Kubernetes reviewer.** +--> +## 为文档做贡献 + +你也可以点击屏幕右上方区域的 **Fork** 按钮，在你自己的 GitHub +账号下创建本仓库的拷贝。此拷贝被称作 *fork*。 +你可以在自己的拷贝中任意地修改文档，并在你已准备好将所作修改提交给我们时， +在你自己的拷贝下创建一个拉取请求（Pull Request），以便让我们知道。 + +一旦你创建了拉取请求，某个 Kubernetes 评审人会负责提供明确的、可执行的反馈意见。 +作为拉取请求的拥有者，*修改拉取请求以解决 Kubernetes +评审人所提出的反馈是你的责任*。 -您可以点击屏幕右上方的 **Fork** 按钮，在您的 GitHub 账户下创建一份本仓库的副本。这个副本叫做 *fork*。您可以对 fork 副本进行任意修改， -当准备好把修改提交给我们时，您可以通过创建一个 pull request 来告知我们。 - - -创建 pull request 后，Kubernetes 审核人员将负责提供清晰且可操作的反馈。作为 pull request 的所有者，**您有责任修改 pull request 以解决 Kubernetes 审核者提供给您的反馈。** -另请注意，您最终可能会收到多个 Kubernetes 审核人员为您提供的反馈，也可能出现后面 Kubernetes 审核人员的反馈与前面审核人员的反馈不尽相同的情况。 -此外，在某些情况下，您的某位评审员可能会在需要时要求 [Kubernetes 技术评审员](https://github.com/kubernetes/website/wiki/Tech-reviewers) 进行技术评审。 -审稿人将尽最大努力及时提供反馈，但响应时间可能因情况而异。 + +Furthermore, in some cases, one of your reviewers might ask for a technical review from a Kubernetes tech reviewer when needed. Reviewers will do their best to provide feedback in a timely fashion but response time can vary based on circumstances. +--> +还要提醒的一点，有时可能会有不止一个 Kubernetes 评审人为你提供反馈意见。 +有时候，某个评审人的意见和另一个最初被指派的评审人的意见不同。 + +更进一步，在某些时候，评审人之一可能会在需要的时候请求 Kubernetes +技术评审人来执行技术评审。 +评审人会尽力及时地提供反馈意见，不过具体的响应时间可能会因时而异。 +--> 有关为 Kubernetes 文档做出贡献的更多信息，请参阅： -* [开始贡献](https://kubernetes.io/docs/contribute/start/) -* [缓存您的文档变更](http://kubernetes.io/docs/contribute/intermediate#view-your-changes-locally) -* [使用页面模版](http://kubernetes.io/docs/contribute/style/page-templates/) +* [贡献 Kubernetes 文档](https://kubernetes.io/docs/contribute/) +* [页面内容类型](http://kubernetes.io/docs/contribute/style/page-content-types/) * [文档风格指南](http://kubernetes.io/docs/contribute/style/style-guide/) * [本地化 Kubernetes 文档](https://kubernetes.io/docs/contribute/localization/) - -## `README.md` 的本地化 Kubernetes 文档 - - -### 中文 +## 中文本地化 可以通过以下方式联系中文本地化的维护人员： @@ -76,107 +141,20 @@ You can reach the maintainers of Korean localization at: * He Xiaolong ([GitHub - @markthink](https://github.com/markthink)) * [Slack channel](https://kubernetes.slack.com/messages/kubernetes-docs-zh) - -## 在本地使用 docker 运行网站 - - -在本地运行 Kubernetes 网站的推荐方法是运行包含 [Hugo](https://gohugo.io) 静态网站生成器的专用 [Docker](https://docker.com) 镜像。 - - -> 如果您使用的是 Windows，则需要一些工具，可以使用 [Chocolatey](https://chocolatey.org) 进行安装。`choco install make` - - -> 如果您更喜欢在没有 Docker 的情况下在本地运行网站，请参阅下面的[使用 Hugo 在本地运行网站](#running-the-site-locally-using-hugo) 章节。 - - -如果您已经[安装运行](https://www.docker.com/get-started)了 Docker，使用以下命令在本地构建 `kubernetes-hugo` Docker 镜像： - -```bash -make docker-image -``` - - -一旦创建了镜像，您就可以在本地运行网站了： - -```bash -make docker-serve -``` - - -打开浏览器访问 http://localhost:1313 以查看网站。当您对源文件进行更改时，Hugo 会更新网站并强制刷新浏览器。 - - -## 使用 Hugo 在本地运行网站 {#running-the-site-locally-using-hugo} - - -有关 Hugo 的安装说明，请参阅 [Hugo 官方文档](https://gohugo.io/getting-started/installing/)。 -确保安装对应版本的 Hugo，版本号由 [`netlify.toml`](netlify.toml#L9) 文件中的 `HUGO_VERSION` 环境变量指定。 - - -安装 Hugo 后，在本地运行网站： - -```bash -make serve -``` - - -这将在 1313 端口上启动本地 Hugo 服务器。打开浏览器访问 http://localhost:1313 查看网站。当您对源文件进行更改时，Hugo 会更新网站并强制刷新浏览器。 - - -## 社区、讨论、贡献和支持 - - -在[社区页面](http://kubernetes.io/community/)了解如何与 Kubernetes 社区互动。 - - -您可以通过以下方式联系该项目的维护人员： - -- [Slack](https://kubernetes.slack.com/messages/sig-docs) -- [Mailing List](https://groups.google.com/forum/#!forum/kubernetes-sig-docs) - +Participation in the Kubernetes community is governed by the [CNCF Code of Conduct](https://github.com/cncf/foundation/blob/master/code-of-conduct.md). +--> ### 行为准则 -参与 Kubernetes 社区受 [Kubernetes 行为准则](code-of-conduct.md)的约束。 +参与 Kubernetes 社区受 [CNCF 行为准则](https://github.com/cncf/foundation/blob/master/code-of-conduct.md)约束。 +--> ## 感谢！ Kubernetes 因为社区的参与而蓬勃发展，感谢您对我们网站和文档的贡献！ diff --git a/README.md b/README.md index 4c631b0dc8..d4c13cb77c 100644 --- a/README.md +++ b/README.md @@ -4,22 +4,61 @@ This repository contains the assets required to build the [Kubernetes website and documentation](https://kubernetes.io/). We're glad that you want to contribute! -## Running the website locally using Hugo +# Using this repository -See the [official Hugo documentation](https://gohugo.io/getting-started/installing/) for Hugo installation instructions. Make sure to install the Hugo extended version specified by the `HUGO_VERSION` environment variable in the [`netlify.toml`](netlify.toml#L10) file. +You can run the website locally using Hugo, or you can run it in a container runtime. We strongly recommend using the container runtime, as it gives deployment consistency with the live website. -To run the website locally when you have Hugo installed: +## Prerequisites -```bash +To use this repository, you need the following installed locally: + +- [yarn](https://yarnpkg.com/) +- [npm](https://www.npmjs.com/) +- [Go](https://golang.org/) +- [Hugo](https://gohugo.io/) +- A container runtime, like [Docker](https://www.docker.com/). + +Before you start, install the dependencies. Clone the repository and navigate to the directory: + +``` git clone https://github.com/kubernetes/website.git cd website -git submodule update --init --recursive -hugo server --buildFuture +``` + +The Kubernetes website uses the [Docsy Hugo theme](https://github.com/google/docsy#readme). Even if you plan to run the website in a container, we strongly recommend pulling in the submodule and other development dependencies by running the following: + +``` +# install dependencies +yarn + +# pull in the Docsy submodule +git submodule update --init --recursive --depth 1 +``` + +## Running the website using a container + +To build the site in a container, run the following to build the container image and run it: + +``` +make container-image +make container-serve +``` + +Open up your browser to http://localhost:1313 to view the website. As you make changes to the source files, Hugo updates the website and forces a browser refresh. + +## Running the website locally using Hugo + +Make sure to install the Hugo extended version specified by the `HUGO_VERSION` environment variable in the [`netlify.toml`](netlify.toml#L10) file. + +To build and test the site locally, run: + +```bash +make serve ``` This will start the local Hugo server on port 1313. Open up your browser to http://localhost:1313 to view the website. As you make changes to the source files, Hugo updates the website and forces a browser refresh. -## Get involved with SIG Docs +# Get involved with SIG Docs Learn more about SIG Docs Kubernetes community and meetings on the [community page](https://github.com/kubernetes/community/tree/master/sig-docs#meetings). @@ -28,7 +67,7 @@ You can also reach the maintainers of this project at: - [Slack](https://kubernetes.slack.com/messages/sig-docs) - [Mailing List](https://groups.google.com/forum/#!forum/kubernetes-sig-docs) -## Contributing to the docs +# Contributing to the docs You can click the **Fork** button in the upper-right area of the screen to create a copy of this repository in your GitHub account. This copy is called a *fork*. Make any changes you want in your fork, and when you are ready to send those changes to us, go to your fork and create a new pull request to let us know about it. @@ -45,7 +84,7 @@ For more information about contributing to the Kubernetes documentation, see: * [Documentation Style Guide](https://kubernetes.io/docs/contribute/style/style-guide/) * [Localizing Kubernetes Documentation](https://kubernetes.io/docs/contribute/localization/) -## Localization `README.md`'s +# Localization `README.md`'s | Language | Language | |---|---| @@ -57,10 +96,10 @@ For more information about contributing to the Kubernetes documentation, see: |[Italian](README-it.md)|[Ukrainian](README-uk.md)| |[Japanese](README-ja.md)|[Vietnamese](README-vi.md)| -## Code of conduct +# Code of conduct Participation in the Kubernetes community is governed by the [CNCF Code of Conduct](https://github.com/cncf/foundation/blob/master/code-of-conduct.md). -## Thank you! +# Thank you! Kubernetes thrives on community participation, and we appreciate your contributions to our website and our documentation! \ No newline at end of file diff --git a/SECURITY.md b/SECURITY.md new file mode 100644 index 0000000000..2083d44cdf --- /dev/null +++ b/SECURITY.md @@ -0,0 +1,22 @@ +# Security Policy + +## Security Announcements + +Join the [kubernetes-security-announce] group for security and vulnerability announcements. + +You can also subscribe to an RSS feed of the above using [this link][kubernetes-security-announce-rss]. + +## Reporting a Vulnerability + +Instructions for reporting a vulnerability can be found on the +[Kubernetes Security and Disclosure Information] page. + +## Supported Versions + +Information about supported Kubernetes versions can be found on the +[Kubernetes version and version skew support policy] page on the Kubernetes website. + +[kubernetes-security-announce]: https://groups.google.com/forum/#!forum/kubernetes-security-announce +[kubernetes-security-announce-rss]: https://groups.google.com/forum/feed/kubernetes-security-announce/msgs/rss_v2_0.xml?num=50 +[Kubernetes version and version skew support policy]: https://kubernetes.io/docs/setup/release/version-skew-policy/#supported-versions +[Kubernetes Security and Disclosure Information]: https://kubernetes.io/docs/reference/issues-security/security/#report-a-vulnerability diff --git a/archetypes/concepts.md b/archetypes/concepts.md new file mode 100644 index 0000000000..33653c9114 --- /dev/null +++ b/archetypes/concepts.md @@ -0,0 +1,12 @@ +--- +title: "{{ replace .Name "-" " " | title }}" +content_type: concept +--- + + + + + + + +## {{% heading "whatsnext" %}} diff --git a/archetypes/tasks.md b/archetypes/tasks.md new file mode 100644 index 0000000000..9067df39ce --- /dev/null +++ b/archetypes/tasks.md @@ -0,0 +1,21 @@ +--- +title: "{{ replace .Name "-" " " | title }}" +content_type: task +--- + + + +## {{% heading "prerequisites" %}} + +{{< include "task-tutorial-prereqs.md" >}} + + + + + + + + +## {{% heading "whatsnext" %}} diff --git a/archetypes/tutorials.md b/archetypes/tutorials.md new file mode 100644 index 0000000000..46e2017460 --- /dev/null +++ b/archetypes/tutorials.md @@ -0,0 +1,19 @@ +--- +title: "{{ replace .Name "-" " " | title }}" +content_type: tutorial +--- + + + +## {{% heading "prerequisites" %}} + +{{< include "task-tutorial-prereqs.md" >}} + +## {{% heading "objectives" %}} + + + +## {{% heading "cleanup" %}} + + +## {{% heading "whatsnext" %}} diff --git a/assets/scss/_base.scss b/assets/scss/_base.scss index ddfee42444..ad462067c6 100644 --- a/assets/scss/_base.scss +++ b/assets/scss/_base.scss @@ -65,8 +65,8 @@ footer { .button { display: inline-block; border-radius: 6px; - padding: 0 20px; - line-height: 40px; + padding: 6px 20px; + line-height: 1.3rem; color: white; background-color: $blue; text-decoration: none; @@ -511,7 +511,7 @@ section#cncf { } #desktopKCButton { - position: relative; + position: absolute; font-size: 18px; background-color: $dark-grey; border-radius: 8px; diff --git a/assets/scss/_custom.scss b/assets/scss/_custom.scss index 52364b0a8a..6d353c380c 100644 --- a/assets/scss/_custom.scss +++ b/assets/scss/_custom.scss @@ -101,14 +101,6 @@ section { left: 0; background: #fff; } - - .dropdown-menu { - left: -80px; - } - - &.dropdown:hover { - color: $medium-grey; - } } } @@ -118,7 +110,7 @@ section { } @media only screen and (min-width: 1075px) { - margin-top: 1.5rem !important; + margin-top: 1rem !important; } } @@ -264,6 +256,14 @@ footer { } } +main { + .td-content table code, + .td-content>table td { + word-break: break-word; + } +} + + // blockquotes and callouts blockquote { @@ -299,12 +299,19 @@ blockquote { } } +.td-sidebar-nav { + & > .td-sidebar-nav__section { + padding-top: .5rem; + padding-left: 1.5rem; + } +} + .td-sidebar__inner { form.td-sidebar__search { button.td-sidebar__toggle { &:hover { - color: $white; + color: #000000; } color: $blue; @@ -383,4 +390,4 @@ main.content { } } } -} +} \ No newline at end of file diff --git a/assets/scss/_tablet.scss b/assets/scss/_tablet.scss index 54ead8319c..299e50eebd 100644 --- a/assets/scss/_tablet.scss +++ b/assets/scss/_tablet.scss @@ -91,6 +91,7 @@ $feature-box-div-width: 45%; max-width: 25%; max-height: 100%; transform: translateY(-50%); + width: 100%; } &:nth-child(odd) { @@ -98,6 +99,7 @@ $feature-box-div-width: 45%; .image-wrapper { right: 0; + text-align: right; } } @@ -106,6 +108,7 @@ $feature-box-div-width: 45%; .image-wrapper { left: 0; + text-align: left; } } diff --git a/config.toml b/config.toml index 13961c17c0..4979c17122 100644 --- a/config.toml +++ b/config.toml @@ -153,7 +153,6 @@ css = [ "custom-jekyll/tags" ] js = [ - "custom-jekyll/tags", "script" ] @@ -222,7 +221,7 @@ no = 'Sorry to hear that. Please }} {{< blocks/section id="oceanNodes" >}} {{% blocks/feature image="flower" %}} @@ -59,4 +58,4 @@ Kubernetes ist Open Source und bietet Dir die Freiheit, die Infrastruktur vor Or {{< blocks/kubernetes-features >}} -{{< blocks/case-studies >}} +{{< blocks/case-studies >}} \ No newline at end of file diff --git a/content/de/docs/concepts/architecture/nodes.md b/content/de/docs/concepts/architecture/nodes.md index 8a2b8b7fde..8f3cd0f785 100644 --- a/content/de/docs/concepts/architecture/nodes.md +++ b/content/de/docs/concepts/architecture/nodes.md @@ -123,7 +123,7 @@ Wenn Sie beispielsweise versuchen, einen Node aus folgendem Inhalt zu erstellen: ``` -Kubernetes erstellt intern ein Node-Oject (die Darstellung) und validiert den Node durch Zustandsprüfung basierend auf dem Feld `metadata.name`. +Kubernetes erstellt intern ein Node-Objekt (die Darstellung) und validiert den Node durch Zustandsprüfung basierend auf dem Feld `metadata.name`. Wenn der Node gültig ist, d.h. wenn alle notwendigen Dienste ausgeführt werden, ist er berechtigt, einen Pod auszuführen. Andernfalls wird er für alle Clusteraktivitäten ignoriert, bis er gültig wird. diff --git a/content/de/docs/contribute/localization.md b/content/de/docs/contribute/localization.md index 031eeb8755..d40f941776 100644 --- a/content/de/docs/contribute/localization.md +++ b/content/de/docs/contribute/localization.md @@ -229,10 +229,25 @@ other = "ICH BIN..." ``` Durch die Lokalisierung von Website-Zeichenfolgen kannst du Website-weiten Text und Funktionen anpassen: z. B. den gesetzlichen Copyright-Text in der Fußzeile auf jeder Seite. -### Sprachspezifischer Styleguide und Glossar +## Sprachspezifischer Styleguide Einige Sprachteams haben ihren eigenen sprachspezifischen Styleguide und ihr eigenes Glossar. Siehe zum Beispiel den [Leitfaden zur koreanischen Lokalisierung](/ko/docs/contribute/localization_ko/). +### Informale Schreibweise +Für die deutsche Übersetzungen verwenden wir eine informelle Schreibweise und der Ansprache per `Du`. Allerdings werden keine Jargon, Slang, Wortspiele, Redewendungen oder kulturspezifische Bezüge eingebracht. + +### Datums und Maßeinheiten +Wenn notwendig sollten Datumsangaben in das in Deutschland übliche dd.mm.yyyy überführt werden. Alternativ können diese auch in den Textfluss eingebunden werden: "... am 24. April ....". + +### Abkürzungen +Abkürzungen sollten nach Möglichkeit nicht verwendet werden und entweder ausgeschrieben oder anderweitig umgangen werden. + +### Zusammengesetzte Wörter +Durch die Übersetzung werden oft Nomen aneinandergereiht, diese Wortketten müssen durch Bindestriche verbunden werden. Dies ist auch möglich wenn ein Teil ins Deutsche übersetzt wird ein weiterer jedoch im Englischen bestehen bleibt. Als Richtlinie gilt hier der [Duden](https://www.duden.de/sprachwissen/rechtschreibregeln/bindestrich). + +### Anglizismen +Die Verwendung von Anglizismen ist dann wünschenswert, wenn die Verwendung eines deutschen Wortes, vor allem für technische Begriffe, nicht eindeutig ist oder zu Unklarheiten führt. + ## Branching Strategie Da Lokalisierungsprojekte in hohem Maße gemeinschaftliche Bemühungen sind, ermutigen wir Teams, in gemeinsamen Entwicklungszweigen zu arbeiten. diff --git a/content/de/docs/setup/minikube.md b/content/de/docs/setup/minikube.md index f0484a8447..643348ee89 100644 --- a/content/de/docs/setup/minikube.md +++ b/content/de/docs/setup/minikube.md @@ -38,7 +38,7 @@ Minikube unterstützt die folgenden Treiber: * kvm ([Treiber installation](https://minikube.sigs.k8s.io/docs/drivers/#kvm-driver)) * hyperkit ([Treiber installation](https://minikube.sigs.k8s.io/docs/drivers/#hyperkit-driver)) * xhyve ([Treiber installation](https://minikube.sigs.k8s.io/docs/drivers/#xhyve-driver)) (deprecated) -* hyperv ([Treiber installation](https://github.com/kubernetes/minikube/blob/master/docs/drivers.md#hyperv-driver)) +* hyperv ([Treiber installation](https://minikube.sigs.k8s.io/docs/drivers/#hyperv-driver)) Beachten Sie, dass die unten angegebene IP-Adresse dynamisch ist und sich ändern kann. Sie kann mit `minikube ip` abgerufen werden. * none (Führt die Kubernetes-Komponenten auf dem Host und nicht in einer VM aus. Die Verwendung dieses Treibers erfordert Docker ([Docker installieren](https://docs.docker.com/install/linux/docker-ce/ubuntu/)) und eine Linux-Umgebung) @@ -428,11 +428,11 @@ Weitere Informationen zu Minikube finden Sie im [Vorschlag](https://git.k8s.io/c ## Zusätzliche Links -* **Ziele und Nichtziele**: Die Ziele und Nichtziele des Minikube-Projekts finden Sie in unserer [Roadmap](https://git.k8s.io/minikube/docs/contributors/roadmap.md). +* **Ziele und Nichtziele**: Die Ziele und Nichtziele des Minikube-Projekts finden Sie in unserer [Roadmap](https://minikube.sigs.k8s.io/docs/contrib/roadmap/). * **Entwicklungshandbuch**: Lesen Sie [CONTRIBUTING.md](https://git.k8s.io/minikube/CONTRIBUTING.md) für einen Überblick über das Senden von Pull-Requests. -* **Minikube bauen**: Anweisungen zum Erstellen/Testen von Minikube aus dem Quellcode finden Sie im [build Handbuch](https://git.k8s.io/minikube/docs/contributors/build_guide.md). +* **Minikube bauen**: Anweisungen zum Erstellen/Testen von Minikube aus dem Quellcode finden Sie im [build Handbuch](https://minikube.sigs.k8s.io/docs/contrib/building/). * **Neue Abhängigkeit hinzufügen**: Anweisungen zum Hinzufügen einer neuen Abhängigkeit zu Minikube finden Sie in der [Anleitung zum Hinzufügen von Abhängigkeiten](https://minikube.sigs.k8s.io/docs/drivers/). -* **Neues Addon hinzufügen**: Anweisungen zum Hinzufügen eines neuen Addons für Minikube finden Sie im [Anleitung zum Hinzufügen eines Addons](https://git.k8s.io/minikube/docs/contributors/adding_an_addon.md). +* **Neues Addon hinzufügen**: Anweisungen zum Hinzufügen eines neuen Addons für Minikube finden Sie im [Anleitung zum Hinzufügen eines Addons](https://minikube.sigs.k8s.io/docs/handbook/addons/). * **MicroK8s**: Linux-Benutzer, die die Ausführung einer virtuellen Maschine vermeiden möchten, sollten [MicroK8s](https://microk8s.io/) als Alternative in Betracht ziehen. ## Community diff --git a/content/en/_index.html b/content/en/_index.html index 97e02aa259..e5b4f1922c 100644 --- a/content/en/_index.html +++ b/content/en/_index.html @@ -41,13 +41,12 @@ Kubernetes is open source giving you the freedom to take advantage of on-premise

-
Attend KubeCon EU virtually on August 17-20, 2020



- Attend KubeCon in Boston on November 17-20, 2020 + Attend KubeCon NA virtually on November 17-20, 2020
diff --git a/content/en/blog/_posts/2015-05-00-Kubernetes-On-Openstack.md b/content/en/blog/_posts/2015-05-00-Kubernetes-On-Openstack.md index 35918b5dbe..1e2b4ce3a5 100644 --- a/content/en/blog/_posts/2015-05-00-Kubernetes-On-Openstack.md +++ b/content/en/blog/_posts/2015-05-00-Kubernetes-On-Openstack.md @@ -19,34 +19,20 @@ The entries in the catalog include not just the ability to [start a Kubernetes c -- -Apache web server -- -Nginx web server -- -Crate - The Distributed Database for Docker -- -GlassFish - Java EE 7 Application Server -- -Tomcat - An open-source web server and servlet container -- -InfluxDB - An open-source, distributed, time series database -- -Grafana - Metrics dashboard for InfluxDB -- -Jenkins - An extensible open source continuous integration server -- -MariaDB database -- -MySql database -- -Redis - Key-value cache and store -- -PostgreSQL database -- -MongoDB NoSQL database -- -Zend Server - The Complete PHP Application Platform +- Apache web server +- Nginx web server +- Crate - The Distributed Database for Docker +- GlassFish - Java EE 7 Application Server +- Tomcat - An open-source web server and servlet container +- InfluxDB - An open-source, distributed, time series database +- Grafana - Metrics dashboard for InfluxDB +- Jenkins - An extensible open source continuous integration server +- MariaDB database +- MySql database +- Redis - Key-value cache and store +- PostgreSQL database +- MongoDB NoSQL database +- Zend Server - The Complete PHP Application Platform diff --git a/content/en/blog/_posts/2015-06-00-The-Distributed-System-Toolkit-Patterns.md b/content/en/blog/_posts/2015-06-00-The-Distributed-System-Toolkit-Patterns.md index d8c3c59a08..f5a050bd19 100644 --- a/content/en/blog/_posts/2015-06-00-The-Distributed-System-Toolkit-Patterns.md +++ b/content/en/blog/_posts/2015-06-00-The-Distributed-System-Toolkit-Patterns.md @@ -12,14 +12,10 @@ In many ways the switch from VMs to containers is like the switch from monolithi The benefits of thinking in terms of modular containers are enormous, in particular, modular containers provide the following: -- -Speed application development, since containers can be re-used between teams and even larger communities -- -Codify expert knowledge, since everyone collaborates on a single containerized implementation that reflects best-practices rather than a myriad of different home-grown containers with roughly the same functionality -- -Enable agile teams, since the container boundary is a natural boundary and contract for team responsibilities -- -Provide separation of concerns and focus on specific functionality that reduces spaghetti dependencies and un-testable components +- Speed application development, since containers can be re-used between teams and even larger communities +- Codify expert knowledge, since everyone collaborates on a single containerized implementation that reflects best-practices rather than a myriad of different home-grown containers with roughly the same functionality +- Enable agile teams, since the container boundary is a natural boundary and contract for team responsibilities +- Provide separation of concerns and focus on specific functionality that reduces spaghetti dependencies and un-testable components Building an application from modular containers means thinking about symbiotic groups of containers that cooperate to provide a service, not one container per service.  In Kubernetes, the embodiment of this modular container service is a Pod.  A Pod is a group of containers that share resources like file systems, kernel namespaces and an IP address.  The Pod is the atomic unit of scheduling in a Kubernetes cluster, precisely because the symbiotic nature of the containers in the Pod require that they be co-scheduled onto the same machine, and the only way to reliably achieve this is by making container groups atomic scheduling units. diff --git a/content/en/blog/_posts/2015-07-00-Weekly-Kubernetes-Community-Hangout_23.md b/content/en/blog/_posts/2015-07-00-Weekly-Kubernetes-Community-Hangout_23.md index 753e2250be..9703dd6141 100644 --- a/content/en/blog/_posts/2015-07-00-Weekly-Kubernetes-Community-Hangout_23.md +++ b/content/en/blog/_posts/2015-07-00-Weekly-Kubernetes-Community-Hangout_23.md @@ -14,121 +14,71 @@ Here are the notes from today's meeting: -- -Eric Paris: replacing salt with ansible (if we want) +- Eric Paris: replacing salt with ansible (if we want) - - -In contrib, there is a provisioning tool written in ansible - - -The goal in the rewrite was to eliminate as much of the cloud provider stuff as possible - - -The salt setup does a bunch of setup in scripts and then the environment is setup with salt + - In contrib, there is a provisioning tool written in ansible + - The goal in the rewrite was to eliminate as much of the cloud provider stuff as possible + - The salt setup does a bunch of setup in scripts and then the environment is setup with salt - - -This means that things like generating certs is done differently on GCE/AWS/Vagrant - - -For ansible, everything must be done within ansible - - -Background on ansible + - This means that things like generating certs is done differently on GCE/AWS/Vagrant + - For ansible, everything must be done within ansible + - Background on ansible - - -Does not have clients - - -Provisioner ssh into the machine and runs scripts on the machine - - -You define what you want your cluster to look like, run the script, and it sets up everything at once - - -If you make one change in a config file, ansible re-runs everything (which isn’t always desirable) - - -Uses a jinja2 template - - -Create machines with minimal software, then use ansible to get that machine into a runnable state + - Does not have clients + - Provisioner ssh into the machine and runs scripts on the machine + - You define what you want your cluster to look like, run the script, and it sets up everything at once + - If you make one change in a config file, ansible re-runs everything (which isn’t always desirable) + - Uses a jinja2 template + - Create machines with minimal software, then use ansible to get that machine into a runnable state - - -Sets up all of the add-ons - - -Eliminates the provisioner shell scripts - - -Full cluster setup currently takes about 6 minutes + - Sets up all of the add-ons + - Eliminates the provisioner shell scripts + - Full cluster setup currently takes about 6 minutes - - -CentOS with some packages - - -Redeploy to the cluster takes 25 seconds - - -Questions for Eric + - CentOS with some packages + - Redeploy to the cluster takes 25 seconds + - Questions for Eric - - -Where does the provider-specific configuration go? + - Where does the provider-specific configuration go? - - -The only network setup that the ansible config does is flannel; you can turn it off - - -What about init vs. systemd? + - The only network setup that the ansible config does is flannel; you can turn it off + - What about init vs. systemd? - - -Should be able to support in the code w/o any trouble (not yet implemented) - - -Discussion + - Should be able to support in the code w/o any trouble (not yet implemented) + - Discussion - - -Why not push the setup work into containers or kubernetes config? + - Why not push the setup work into containers or kubernetes config? - - -To bootstrap a cluster drop a kubelet and a manifest - - -Running a kubelet and configuring the network should be the only things required. We can cut a machine image that is preconfigured minus the data package (certs, etc) + - To bootstrap a cluster drop a kubelet and a manifest + - Running a kubelet and configuring the network should be the only things required. We can cut a machine image that is preconfigured minus the data package (certs, etc) - - -The ansible scripts install kubelet & docker if they aren’t already installed - - -Each OS (RedHat, Debian, Ubuntu) could have a different image. We could view this as part of the build process instead of the install process. - - -There needs to be solution for bare metal as well. - - -In favor of the overall goal -- reducing the special configuration in the salt configuration - - -Everything except the kubelet should run inside a container (eventually the kubelet should as well) + - The ansible scripts install kubelet & docker if they aren’t already installed + - Each OS (RedHat, Debian, Ubuntu) could have a different image. We could view this as part of the build process instead of the install process. + - There needs to be solution for bare metal as well. + - In favor of the overall goal -- reducing the special configuration in the salt configuration + - Everything except the kubelet should run inside a container (eventually the kubelet should as well) - - -Running in a container doesn’t cut down on the complexity that we currently have - - -But it does more clearly define the interface about what the code expects - - -These tools (Chef, Puppet, Ansible) conflate binary distribution with configuration + - Running in a container doesn’t cut down on the complexity that we currently have + - But it does more clearly define the interface about what the code expects + - These tools (Chef, Puppet, Ansible) conflate binary distribution with configuration - - -Containers more clearly separate these problems - - -The mesos deployment is not completely automated yet, but the mesos deployment is completely different: kubelets get put on top on an existing mesos cluster + - Containers more clearly separate these problems + - The mesos deployment is not completely automated yet, but the mesos deployment is completely different: kubelets get put on top on an existing mesos cluster - - -The bash scripts allow the mesos devs to see what each cloud provider is doing and re-use the relevant bits - - -There was a large reverse engineering curve, but the bash is at least readable as opposed to the salt - - -Openstack uses a different deployment as well - - -We need a well documented list of steps (e.g. create certs) that are necessary to stand up a cluster + - The bash scripts allow the mesos devs to see what each cloud provider is doing and re-use the relevant bits + - There was a large reverse engineering curve, but the bash is at least readable as opposed to the salt + - Openstack uses a different deployment as well + - We need a well documented list of steps (e.g. create certs) that are necessary to stand up a cluster - - -This would allow us to compare across cloud providers - - -We should reduce the number of steps as much as possible - - -Ansible has 241 steps to launch a cluster -- -1.0 Code freeze + - This would allow us to compare across cloud providers + - We should reduce the number of steps as much as possible + - Ansible has 241 steps to launch a cluster +- 1.0 Code freeze - - -How are we getting out of code freeze? - - -This is a topic for next week, but the preview is that we will move slowly rather than totally opening the firehose + - How are we getting out of code freeze? + - This is a topic for next week, but the preview is that we will move slowly rather than totally opening the firehose - - -We want to clear the backlog as fast as possible while maintaining stability both on HEAD and on the 1.0 branch - - -The backlog of almost 300 PRs but there are also various parallel feature branches that have been developed during the freeze - - -Cutting a cherry pick release today (1.0.1) that fixes a few issues + - We want to clear the backlog as fast as possible while maintaining stability both on HEAD and on the 1.0 branch + - The backlog of almost 300 PRs but there are also various parallel feature branches that have been developed during the freeze + - Cutting a cherry pick release today (1.0.1) that fixes a few issues - Next week we will discuss the cadence for patch releases diff --git a/content/en/blog/_posts/2016-03-00-Elasticbox-Introduces-Elastickube-To.md b/content/en/blog/_posts/2016-03-00-Elasticbox-Introduces-Elastickube-To.md index 1a67c9334e..e1df83d3e2 100644 --- a/content/en/blog/_posts/2016-03-00-Elasticbox-Introduces-Elastickube-To.md +++ b/content/en/blog/_posts/2016-03-00-Elasticbox-Introduces-Elastickube-To.md @@ -16,17 +16,10 @@ Fundamentally, ElasticKube delivers a web console for which compliments Kubernet ElasticKube enables organizations to accelerate adoption by developers, application operations and traditional IT operations teams and shares a mutual goal of increasing developer productivity, driving efficiency in container management and promoting the use of microservices as a modern application delivery methodology. When leveraging ElasticKube in your environment, users need to ensure the following technologies are configured appropriately to guarantee everything runs correctly: -- -Configure Google Container Engine (GKE) for cluster installation and management - -- -Use Kubernetes to provision the infrastructure and clusters for containers   - -- -Use your existing tools of choice to actually build your containers -- - -Use ElasticKube to run, deploy and manage your containers and services +- Configure Google Container Engine (GKE) for cluster installation and management +- Use Kubernetes to provision the infrastructure and clusters for containers   +- Use your existing tools of choice to actually build your containers +- Use ElasticKube to run, deploy and manage your containers and services [![](https://cl.ly/0i3M2L3Q030z/Image%202016-03-11%20at%209.49.12%20AM.png)](http://cl.ly/0i3M2L3Q030z/Image%202016-03-11%20at%209.49.12%20AM.png) @@ -39,14 +32,10 @@ Getting Started with Kubernetes and ElasticKube (this is a 3min walk through video with the following topics) -1. -Deploy ElasticKube to a Kubernetes cluster -2. -Configuration -3. -Admin: Setup and invite a user -4. -Deploy an instance +1. Deploy ElasticKube to a Kubernetes cluster +2. Configuration +3. Admin: Setup and invite a user +4. Deploy an instance diff --git a/content/en/blog/_posts/2016-03-00-Kubernetes-In-Enterprise-With-Fujitsus.md b/content/en/blog/_posts/2016-03-00-Kubernetes-In-Enterprise-With-Fujitsus.md index 3bfa309fd1..b02f089cac 100644 --- a/content/en/blog/_posts/2016-03-00-Kubernetes-In-Enterprise-With-Fujitsus.md +++ b/content/en/blog/_posts/2016-03-00-Kubernetes-In-Enterprise-With-Fujitsus.md @@ -13,24 +13,18 @@ Today, we want to take you on a short tour explaining the background of our offe In mid 2014 we looked at the challenges enterprises are facing in the context of digitization, where traditional enterprises experience that more and more competitors from the IT sector are pushing into the core of their markets. A big part of Fujitsu’s customers are such traditional businesses, so we considered how we could help them and came up with three basic principles: -- -Decouple applications from infrastructure - Focus on where the value for the customer is: the application. -- -Decompose applications - Build applications from smaller, loosely coupled parts. Enable reconfiguration of those parts depending on the needs of the business. Also encourage innovation by low-cost experiments. -- -Automate everything - Fight the increasing complexity of the first two points by introducing a high degree of automation. +- Decouple applications from infrastructure - Focus on where the value for the customer is: the application. +- Decompose applications - Build applications from smaller, loosely coupled parts. Enable reconfiguration of those parts depending on the needs of the business. Also encourage innovation by low-cost experiments. +- Automate everything - Fight the increasing complexity of the first two points by introducing a high degree of automation. We found that Linux containers themselves cover the first point and touch the second. But at this time there was little support for creating distributed applications and running them managed automatically. We found Kubernetes as the missing piece. **Not a free lunch** The general approach of Kubernetes in managing containerized workload is convincing, but as we looked at it with the eyes of customers, we realized that it’s not a free lunch. Many  customers are medium-sized companies whose core business is often bound to strict data protection regulations. The top three requirements we identified are: -- -On-premise deployments (with the option for hybrid scenarios) -- -Efficient operations as part of a (much) bigger IT infrastructure -- -Enterprise-grade support, potentially on global scale +- On-premise deployments (with the option for hybrid scenarios) +- Efficient operations as part of a (much) bigger IT infrastructure +- Enterprise-grade support, potentially on global scale We created Cloud Load Control with these requirements in mind. It is basically a distribution of Kubernetes targeted for on-premise use, primarily focusing on operational aspects of container infrastructure. We are committed to work with the community, and contribute all relevant changes and extensions upstream to the Kubernetes project. **On-premise deployments** @@ -39,12 +33,9 @@ As Kubernetes core developer Tim Hockin often puts it in his[talks](https://spea Cloud Load Control addresses these issues. It enables customers to reliably and readily provision a production grade Kubernetes clusters on their own infrastructure, with the following benefits: -- -Proven setup process, lowers risk of problems while setting up the cluster -- -Reduction of provisioning time to minutes -- -Repeatable process, relevant especially for large, multi-tenant environments +- Proven setup process, lowers risk of problems while setting up the cluster +- Reduction of provisioning time to minutes +- Repeatable process, relevant especially for large, multi-tenant environments Cloud Load Control delivers these benefits for a range of platforms, starting from selected OpenStack distributions in the first versions of Cloud Load Control, and successively adding more platforms depending on customer demand.  We are especially excited about the option to remove the virtualization layer and support Kubernetes bare-metal on Fujitsu servers in the long run. By removing a layer of complexity, the total cost to run the system would be decreased and the missing hypervisor would increase performance. @@ -53,10 +44,8 @@ Right now we are in the process of contributing a generic provider to set up Kub Reducing operation costs is the target of any organization providing IT infrastructure. This can be achieved by increasing the efficiency of operations and helping operators to get their job done. Considering large-scale container infrastructures, we found it is important to differentiate between two types of operations: -- -Platform-oriented, relates to the overall infrastructure, often including various systems, one of which might be Kubernetes. -- -Application-oriented, focusses rather on a single, or a small set of applications deployed on Kubernetes. +- Platform-oriented, relates to the overall infrastructure, often including various systems, one of which might be Kubernetes. +- Application-oriented, focusses rather on a single, or a small set of applications deployed on Kubernetes. Kubernetes is already great for the application-oriented part. Cloud Load Control was created to help platform-oriented operators to efficiently manage Kubernetes as part of the overall infrastructure and make it easy to execute Kubernetes tasks relevant to them. diff --git a/content/en/blog/_posts/2016-03-00-State-Of-Container-World-February-2016.md b/content/en/blog/_posts/2016-03-00-State-Of-Container-World-February-2016.md index 27f84d3e7b..025c311606 100644 --- a/content/en/blog/_posts/2016-03-00-State-Of-Container-World-February-2016.md +++ b/content/en/blog/_posts/2016-03-00-State-Of-Container-World-February-2016.md @@ -11,15 +11,12 @@ Hello, and welcome to the second installment of the Kubernetes state of the cont In January, 71% of respondents were currently using containers, in February, 89% of respondents were currently using containers. The percentage of users not even considering containers also shrank from 4% in January to a surprising 0% in February. Will see if that holds consistent in March.Likewise, the usage of containers continued to march across the dev/canary/prod lifecycle. In all parts of the lifecycle, container usage increased: -- -Development: 80% -\> 88% -- -Test: 67% -\> 72% -- -Pre production: 41% -\> 55% -- -Production: 50% -\> 62% -What is striking in this is that pre-production growth continued, even as workloads were clearly transitioned into true production. Likewise the share of people considering containers for production rose from 78% in January to 82% in February. Again we’ll see if the trend continues into March. +- Development: 80% -\> 88% +- Test: 67% -\> 72% +- Pre production: 41% -\> 55% +- Production: 50% -\> 62% + +What is striking in this is that pre-production growth continued, even as workloads were clearly transitioned into true production. Likewise the share of people considering containers for production rose from 78% in January to 82% in February. Again we’ll see if the trend continues into March. ## Container and cluster sizes diff --git a/content/en/blog/_posts/2016-12-00-Container-Runtime-Interface-Cri-In-Kubernetes.md b/content/en/blog/_posts/2016-12-00-Container-Runtime-Interface-Cri-In-Kubernetes.md index 061a39c196..721b217c47 100644 --- a/content/en/blog/_posts/2016-12-00-Container-Runtime-Interface-Cri-In-Kubernetes.md +++ b/content/en/blog/_posts/2016-12-00-Container-Runtime-Interface-Cri-In-Kubernetes.md @@ -215,14 +215,10 @@ CRI is being actively developed and maintained by the Kubernetes [SIG-Node](http -- -Post issues or feature requests on [GitHub](https://github.com/kubernetes/kubernetes) -- -Join the #sig-node channel on [Slack](https://kubernetes.slack.com/) -- -Subscribe to the [SIG-Node mailing list](mailto:kubernetes-sig-node@googlegroups.com) -- -Follow us on Twitter [@Kubernetesio](https://twitter.com/kubernetesio) for latest updates +- Post issues or feature requests on [GitHub](https://github.com/kubernetes/kubernetes) +- Join the #sig-node channel on [Slack](https://kubernetes.slack.com/) +- Subscribe to the [SIG-Node mailing list](mailto:kubernetes-sig-node@googlegroups.com) +- Follow us on Twitter [@Kubernetesio](https://twitter.com/kubernetesio) for latest updates diff --git a/content/en/blog/_posts/2016-12-00-Five-Days-Of-Kubernetes-1-5.md b/content/en/blog/_posts/2016-12-00-Five-Days-Of-Kubernetes-1-5.md index 14eae43fc6..fa30aba5f7 100644 --- a/content/en/blog/_posts/2016-12-00-Five-Days-Of-Kubernetes-1-5.md +++ b/content/en/blog/_posts/2016-12-00-Five-Days-Of-Kubernetes-1-5.md @@ -21,13 +21,8 @@ This progress is our commitment in continuing to make Kubernetes best way to man Connect -- -[Download](http://get.k8s.io/) Kubernetes -- -Get involved with the Kubernetes project on [GitHub](https://github.com/kubernetes/kubernetes) -- -Post questions (or answer questions) on [Stack Overflow](http://stackoverflow.com/questions/tagged/kubernetes) -- -Connect with the community on [Slack](http://slack.k8s.io/) -- -Follow us on Twitter [@Kubernetesio](https://twitter.com/kubernetesio) for latest updates +- [Download](http://get.k8s.io/) Kubernetes +- Get involved with the Kubernetes project on [GitHub](https://github.com/kubernetes/kubernetes) +- Post questions (or answer questions) on [Stack Overflow](http://stackoverflow.com/questions/tagged/kubernetes) +- Connect with the community on [Slack](http://slack.k8s.io/) +- Follow us on Twitter [@Kubernetesio](https://twitter.com/kubernetesio) for latest updates diff --git a/content/en/blog/_posts/2016-12-00-Windows-Server-Support-Kubernetes.md b/content/en/blog/_posts/2016-12-00-Windows-Server-Support-Kubernetes.md index 7f58071940..ba87948d3c 100644 --- a/content/en/blog/_posts/2016-12-00-Windows-Server-Support-Kubernetes.md +++ b/content/en/blog/_posts/2016-12-00-Windows-Server-Support-Kubernetes.md @@ -36,12 +36,11 @@ Most of the Kubernetes constructs, such as Pods, Services, Labels, etc. work wit | What doesn’t work yet? | -- -Pod abstraction is not same due to networking namespaces. Net result is that Windows containers in a single POD cannot communicate over localhost. Linux containers can share networking stack by placing them in the same network namespace. -- -DNS capabilities are not fully implemented -- -UDP is not supported inside a container + +- Pod abstraction is not same due to networking namespaces. Net result is that Windows containers in a single POD cannot communicate over localhost. Linux containers can share networking stack by placing them in the same network namespace. +- DNS capabilities are not fully implemented +- UDP is not supported inside a container + | | When will it be ready for all production workloads (general availability)? diff --git a/content/en/blog/_posts/2017-05-00-Kubernetes-Monitoring-Guide.md b/content/en/blog/_posts/2017-05-00-Kubernetes-Monitoring-Guide.md index 87a26f14b4..c5f1147072 100644 --- a/content/en/blog/_posts/2017-05-00-Kubernetes-Monitoring-Guide.md +++ b/content/en/blog/_posts/2017-05-00-Kubernetes-Monitoring-Guide.md @@ -78,11 +78,7 @@ _--Jean-Mathieu Saponaro, Research & Analytics Engineer, Datadog_ -- -Get involved with the Kubernetes project on [GitHub](https://github.com/kubernetes/kubernetes)  -- -Post questions (or answer questions) on [Stack Overflow](http://stackoverflow.com/questions/tagged/kubernetes)  -- -Connect with the community on [Slack](http://slack.k8s.io/) -- -Follow us on Twitter [@Kubernetesio](https://twitter.com/kubernetesio) for latest updates +- Get involved with the Kubernetes project on [GitHub](https://github.com/kubernetes/kubernetes)  +- Post questions (or answer questions) on [Stack Overflow](http://stackoverflow.com/questions/tagged/kubernetes)  +- Connect with the community on [Slack](http://slack.k8s.io/) +- Follow us on Twitter [@Kubernetesio](https://twitter.com/kubernetesio) for latest updates diff --git a/content/en/blog/_posts/2017-05-00-Kubespray-Ansible-Collaborative-Kubernetes-Ops.md b/content/en/blog/_posts/2017-05-00-Kubespray-Ansible-Collaborative-Kubernetes-Ops.md index 8c63574864..c6e4007d9a 100644 --- a/content/en/blog/_posts/2017-05-00-Kubespray-Ansible-Collaborative-Kubernetes-Ops.md +++ b/content/en/blog/_posts/2017-05-00-Kubespray-Ansible-Collaborative-Kubernetes-Ops.md @@ -113,11 +113,7 @@ _-- Rob Hirschfeld, co-founder of RackN and co-chair of the Cluster Ops SIG_ -- -Get involved with the Kubernetes project on [GitHub](https://github.com/kubernetes/kubernetes) -- -Post questions (or answer questions) on [Stack Overflow](http://stackoverflow.com/questions/tagged/kubernetes) -- -Connect with the community on [Slack](http://slack.k8s.io/) -- -Follow us on Twitter [@Kubernetesio](https://twitter.com/kubernetesio) for latest updates +- Get involved with the Kubernetes project on [GitHub](https://github.com/kubernetes/kubernetes) +- Post questions (or answer questions) on [Stack Overflow](http://stackoverflow.com/questions/tagged/kubernetes) +- Connect with the community on [Slack](http://slack.k8s.io/) +- Follow us on Twitter [@Kubernetesio](https://twitter.com/kubernetesio) for latest updates diff --git a/content/en/blog/_posts/2017-07-00-Happy-Second-Birthday-Kubernetes.md b/content/en/blog/_posts/2017-07-00-Happy-Second-Birthday-Kubernetes.md index 774bbffad7..7f3c6ebee9 100644 --- a/content/en/blog/_posts/2017-07-00-Happy-Second-Birthday-Kubernetes.md +++ b/content/en/blog/_posts/2017-07-00-Happy-Second-Birthday-Kubernetes.md @@ -26,87 +26,69 @@ Kubernetes has also earned the trust of many [Fortune 500 companies](https://kub July 2016 -- -Kubernauts celebrated its [first anniversary](https://kubernetes.io/blog/2016/07/happy-k8sbday-1) of the Kubernetes 1.0 launch with 20 [#k8sbday](https://twitter.com/search?q=k8sbday&src=typd) parties hosted worldwide -- -Kubernetes [v1.3 release](https://kubernetes.io/blog/2016/07/kubernetes-1-3-bridging-cloud-native-and-enterprise-workloads/) +- Kubernauts celebrated its [first anniversary](https://kubernetes.io/blog/2016/07/happy-k8sbday-1) of the Kubernetes 1.0 launch with 20 [#k8sbday](https://twitter.com/search?q=k8sbday&src=typd) parties hosted worldwide +- Kubernetes [v1.3 release](https://kubernetes.io/blog/2016/07/kubernetes-1-3-bridging-cloud-native-and-enterprise-workloads/) September 2016 -- -Kubernetes [v1.4 release](https://kubernetes.io/blog/2016/09/kubernetes-1-4-making-it-easy-to-run-on-kuberentes-anywhere/) -- -Launch of [kubeadm](https://kubernetes.io/blog/2016/09/how-we-made-kubernetes-easy-to-install), a tool that makes Kubernetes dramatically easier to install -- -[Pokemon Go](https://www.sdxcentral.com/articles/news/google-dealt-pokemon-go-traffic-50-times-beyond-expectations/2016/09/) - one of the largest installs of Kubernetes ever +- Kubernetes [v1.4 release](https://kubernetes.io/blog/2016/09/kubernetes-1-4-making-it-easy-to-run-on-kuberentes-anywhere/) +- Launch of [kubeadm](https://kubernetes.io/blog/2016/09/how-we-made-kubernetes-easy-to-install), a tool that makes Kubernetes dramatically easier to install +- [Pokemon Go](https://www.sdxcentral.com/articles/news/google-dealt-pokemon-go-traffic-50-times-beyond-expectations/2016/09/) - one of the largest installs of Kubernetes ever October 2016 -- -Introduced [Kubernetes service partners program](https://kubernetes.io/blog/2016/10/kubernetes-service-technology-partners-program) and a redesigned [partners page](https://kubernetes.io/partners/) +- Introduced [Kubernetes service partners program](https://kubernetes.io/blog/2016/10/kubernetes-service-technology-partners-program) and a redesigned [partners page](https://kubernetes.io/partners/) November 2016 -- -CloudNativeCon/KubeCon [Seattle](https://www.cncf.io/blog/2016/11/17/cloudnativeconkubecon-2016-wrap/) -- -Cloud Native Computing Foundation partners with The Linux Foundation to launch a [new Kubernetes certification, training and managed service provider program](https://www.cncf.io/blog/2016/11/08/cncf-partners-linux-foundation-launch-new-kubernetes-certification-training-managed-service-provider-program/) +- CloudNativeCon/KubeCon [Seattle](https://www.cncf.io/blog/2016/11/17/cloudnativeconkubecon-2016-wrap/) +- Cloud Native Computing Foundation partners with The Linux Foundation to launch a [new Kubernetes certification, training and managed service provider program](https://www.cncf.io/blog/2016/11/08/cncf-partners-linux-foundation-launch-new-kubernetes-certification-training-managed-service-provider-program/) December 2016 -- -Kubernetes [v1.5 release](https://kubernetes.io/blog/2016/12/kubernetes-1-5-supporting-production-workloads/) +- Kubernetes [v1.5 release](https://kubernetes.io/blog/2016/12/kubernetes-1-5-supporting-production-workloads/) January 2017 -- -[Survey](https://www.cncf.io/blog/2017/01/17/container-management-trends-kubernetes-moves-testing-production/) from CloudNativeCon + KubeCon Seattle showcases the maturation of Kubernetes deployment +- [Survey](https://www.cncf.io/blog/2017/01/17/container-management-trends-kubernetes-moves-testing-production/) from CloudNativeCon + KubeCon Seattle showcases the maturation of Kubernetes deployment March 2017 -- -CloudNativeCon/KubeCon [Europe](https://www.cncf.io/blog/2017/04/17/highlights-cloudnativecon-kubecon-europe-2017/) -- -Kubernetes[v1.6 release](https://kubernetes.io/blog/2017/03/kubernetes-1-6-multi-user-multi-workloads-at-scale) +- CloudNativeCon/KubeCon [Europe](https://www.cncf.io/blog/2017/04/17/highlights-cloudnativecon-kubecon-europe-2017/) +- Kubernetes[v1.6 release](https://kubernetes.io/blog/2017/03/kubernetes-1-6-multi-user-multi-workloads-at-scale) April 2017 -- -The [Battery Open Source Software (BOSS) Index](https://www.battery.com/powered/boss-index-tracking-explosive-growth-open-source-software/) lists Kubernetes as #33 in the top 100 popular open-source software projects +- The [Battery Open Source Software (BOSS) Index](https://www.battery.com/powered/boss-index-tracking-explosive-growth-open-source-software/) lists Kubernetes as #33 in the top 100 popular open-source software projects May 2017 -- -[Four Kubernetes projects](https://www.cncf.io/blog/2017/05/04/cncf-brings-kubernetes-coredns-opentracing-prometheus-google-summer-code-2017/) accepted to The [Google Summer of Code](https://developers.google.com/open-source/gsoc/) (GSOC) 2017 program -- -Stutterstock and Kubernetes appear in [The Wall Street Journal](https://blogs.wsj.com/cio/2017/05/26/shutterstock-ceo-says-new-business-plan-hinged-upon-total-overhaul-of-it/): “On average we [Shutterstock] deploy 45 different releases into production a day using that framework. We use Docker, Kubernetes and Jenkins [to build and run containers and automate development,” said CTO Marty Brodbeck on the company’s IT overhaul and adoption of containerization. +- [Four Kubernetes projects](https://www.cncf.io/blog/2017/05/04/cncf-brings-kubernetes-coredns-opentracing-prometheus-google-summer-code-2017/) accepted to The [Google Summer of Code](https://developers.google.com/open-source/gsoc/) (GSOC) 2017 program +- Stutterstock and Kubernetes appear in [The Wall Street Journal](https://blogs.wsj.com/cio/2017/05/26/shutterstock-ceo-says-new-business-plan-hinged-upon-total-overhaul-of-it/): “On average we [Shutterstock] deploy 45 different releases into production a day using that framework. We use Docker, Kubernetes and Jenkins [to build and run containers and automate development,” said CTO Marty Brodbeck on the company’s IT overhaul and adoption of containerization. June 2017 -- -Kubernetes [v1.7 release](https://kubernetes.io/blog/2017/06/kubernetes-1-7-security-hardening-stateful-application-extensibility-updates) -- -[Survey](https://www.cncf.io/blog/2017/06/28/survey-shows-kubernetes-leading-orchestration-platform/) from CloudNativeCon + KubeCon Europe shows Kubernetes leading as the orchestration platform of choice -- -Kubernetes ranked [#4](https://github.com/cncf/velocity) in the [30 highest velocity open source projects](https://www.cncf.io/blog/2017/06/05/30-highest-velocity-open-source-projects/) +- Kubernetes [v1.7 release](https://kubernetes.io/blog/2017/06/kubernetes-1-7-security-hardening-stateful-application-extensibility-updates) +- [Survey](https://www.cncf.io/blog/2017/06/28/survey-shows-kubernetes-leading-orchestration-platform/) from CloudNativeCon + KubeCon Europe shows Kubernetes leading as the orchestration platform of choice +- Kubernetes ranked [#4](https://github.com/cncf/velocity) in the [30 highest velocity open source projects](https://www.cncf.io/blog/2017/06/05/30-highest-velocity-open-source-projects/) ![](https://lh5.googleusercontent.com/tN_M9v5pFyr3uzwAXTliSKofTGz9DUSMotLHWgy2vl2VSsfIfysagv7h5VRkMA5L9TsNBTMX4dWr-V3O1S9d3dw9IctSj4bAyzblXCAe4xjAhnNJEA3vjSq4Cw79SfoRWfnW-zYY) @@ -116,8 +98,7 @@ Figure 2: The 30 highest velocity open source projects. Source: [https://github. July 2017 -- -Kubernauts celebrate the second anniversary of the Kubernetes 1.0 launch with [#k8sbday](https://twitter.com/search?q=k8sbday&src=typd) parties worldwide! +- Kubernauts celebrate the second anniversary of the Kubernetes 1.0 launch with [#k8sbday](https://twitter.com/search?q=k8sbday&src=typd) parties worldwide! diff --git a/content/en/blog/_posts/2017-07-00-How-Watson-Health-Cloud-Deploys.md b/content/en/blog/_posts/2017-07-00-How-Watson-Health-Cloud-Deploys.md index de516c17a8..b931ec336a 100644 --- a/content/en/blog/_posts/2017-07-00-How-Watson-Health-Cloud-Deploys.md +++ b/content/en/blog/_posts/2017-07-00-How-Watson-Health-Cloud-Deploys.md @@ -92,14 +92,10 @@ Usage of UCD in the Process Flow: UCD is used for deployment and the end-to end deployment process is automated here. UCD component process involves the following steps: -- -Download the required artifacts for deployment from the Gitlab. -- -Login to Bluemix and set the KUBECONFIG based on the Kubernetes cluster used for creating the pods. -- -Create the application pod in the cluster using kubectl create command. -- -If needed, run a rolling update to update the existing pod. +- Download the required artifacts for deployment from the Gitlab. +- Login to Bluemix and set the KUBECONFIG based on the Kubernetes cluster used for creating the pods. +- Create the application pod in the cluster using kubectl create command. +- If needed, run a rolling update to update the existing pod. @@ -150,13 +146,8 @@ To expose our services to outside the cluster, we used Ingress. In IBM Cloud Kub -- -Post questions (or answer questions) on [Stack Overflow](http://stackoverflow.com/questions/tagged/kubernetes) -- -Join the community portal for advocates on [K8sPort](http://k8sport.org/) -- -Follow us on Twitter [@Kubernetesio](https://twitter.com/kubernetesio) for latest updates -- -Connect with the community on [Slack](http://slack.k8s.io/) -- -Get involved with the Kubernetes project on [GitHub](https://github.com/kubernetes/kubernetes) +- Post questions (or answer questions) on [Stack Overflow](http://stackoverflow.com/questions/tagged/kubernetes) +- Join the community portal for advocates on [K8sPort](http://k8sport.org/) +- Follow us on Twitter [@Kubernetesio](https://twitter.com/kubernetesio) for latest updates +- Connect with the community on [Slack](http://slack.k8s.io/) +- Get involved with the Kubernetes project on [GitHub](https://github.com/kubernetes/kubernetes) diff --git a/content/en/blog/_posts/2017-08-00-Kompose-Helps-Developers-Move-Docker.md b/content/en/blog/_posts/2017-08-00-Kompose-Helps-Developers-Move-Docker.md index b266497707..b94ac8b693 100644 --- a/content/en/blog/_posts/2017-08-00-Kompose-Helps-Developers-Move-Docker.md +++ b/content/en/blog/_posts/2017-08-00-Kompose-Helps-Developers-Move-Docker.md @@ -129,14 +129,10 @@ With our graduation, comes the release of Kompose 1.0.0, here’s what’s new: -- -Docker Compose Version 3: Kompose now supports Docker Compose Version 3. New keys such as ‘deploy’ now convert to their Kubernetes equivalent. -- -Docker Push and Build Support: When you supply a ‘build’ key within your `docker-compose.yaml` file, Kompose will automatically build and push the image to the respective Docker repository for Kubernetes to consume. -- -New Keys: With the addition of version 3 support, new keys such as pid and deploy are supported. For full details on what Kompose supports, view our [conversion document](http://kompose.io/conversion/). -- -Bug Fixes: In every release we fix any bugs related to edge-cases when converting. This release fixes issues relating to converting volumes with ‘./’ in the target name. +- Docker Compose Version 3: Kompose now supports Docker Compose Version 3. New keys such as ‘deploy’ now convert to their Kubernetes equivalent. +- Docker Push and Build Support: When you supply a ‘build’ key within your `docker-compose.yaml` file, Kompose will automatically build and push the image to the respective Docker repository for Kubernetes to consume. +- New Keys: With the addition of version 3 support, new keys such as pid and deploy are supported. For full details on what Kompose supports, view our [conversion document](http://kompose.io/conversion/). +- Bug Fixes: In every release we fix any bugs related to edge-cases when converting. This release fixes issues relating to converting volumes with ‘./’ in the target name. @@ -145,28 +141,18 @@ What’s ahead? As we continue development, we will strive to convert as many Docker Compose keys as possible for all future and current Docker Compose releases, converting each one to their Kubernetes equivalent. All future releases will be backwards-compatible. -- -[Install Kompose](https://github.com/kubernetes/kompose/blob/master/docs/installation.md) -- -[Kompose Quick Start Guide](https://github.com/kubernetes/kompose/blob/master/docs/installation.md) -- -[Kompose Web Site](http://kompose.io/) -- -[Kompose Documentation](https://github.com/kubernetes/kompose/tree/master/docs) +- [Install Kompose](https://github.com/kubernetes/kompose/blob/master/docs/installation.md) +- [Kompose Quick Start Guide](https://github.com/kubernetes/kompose/blob/master/docs/installation.md) +- [Kompose Web Site](http://kompose.io/) +- [Kompose Documentation](https://github.com/kubernetes/kompose/tree/master/docs) --Charlie Drage, Software Engineer, Red Hat -- -Post questions (or answer questions) on[Stack Overflow](http://stackoverflow.com/questions/tagged/kubernetes) -- -Join the community portal for advocates on[K8sPort](http://k8sport.org/) -- -Follow us on Twitter[@Kubernetesio](https://twitter.com/kubernetesio) for latest updates -- -Connect with the community on[Slack](http://slack.k8s.io/) -- -Get involved with the Kubernetes project on[GitHub](https://github.com/kubernetes/kubernetes) -- +- Post questions (or answer questions) on[Stack Overflow](http://stackoverflow.com/questions/tagged/kubernetes) +- Join the community portal for advocates on[K8sPort](http://k8sport.org/) +- Follow us on Twitter[@Kubernetesio](https://twitter.com/kubernetesio) for latest updates +- Connect with the community on[Slack](http://slack.k8s.io/) +- Get involved with the Kubernetes project on[GitHub](https://github.com/kubernetes/kubernetes) diff --git a/content/en/blog/_posts/2017-09-00-Kubernetes-Statefulsets-Daemonsets.md b/content/en/blog/_posts/2017-09-00-Kubernetes-Statefulsets-Daemonsets.md index fe156e00df..67f3e084cc 100644 --- a/content/en/blog/_posts/2017-09-00-Kubernetes-Statefulsets-Daemonsets.md +++ b/content/en/blog/_posts/2017-09-00-Kubernetes-Statefulsets-Daemonsets.md @@ -987,13 +987,8 @@ Rolling updates and roll backs close an important feature gap for DaemonSets and -- -Post questions (or answer questions) on [Stack Overflow](http://stackoverflow.com/questions/tagged/kubernetes) -- -Join the community portal for advocates on [K8sPort](http://k8sport.org/) -- -Follow us on Twitter [@Kubernetesio](https://twitter.com/kubernetesio) for latest updates -- -Connect with the community on [Slack](http://slack.k8s.io/) -- -Get involved with the Kubernetes project on [GitHub](https://github.com/kubernetes/kubernetes) +- Post questions (or answer questions) on [Stack Overflow](http://stackoverflow.com/questions/tagged/kubernetes) +- Join the community portal for advocates on [K8sPort](http://k8sport.org/) +- Follow us on Twitter [@Kubernetesio](https://twitter.com/kubernetesio) for latest updates +- Connect with the community on [Slack](http://slack.k8s.io/) +- Get involved with the Kubernetes project on [GitHub](https://github.com/kubernetes/kubernetes) diff --git a/content/en/blog/_posts/2019-03-28-running-kubernetes-locally-on-linux-with-minikube.md b/content/en/blog/_posts/2019-03-28-running-kubernetes-locally-on-linux-with-minikube.md index c33b805b4d..ebbf591772 100644 --- a/content/en/blog/_posts/2019-03-28-running-kubernetes-locally-on-linux-with-minikube.md +++ b/content/en/blog/_posts/2019-03-28-running-kubernetes-locally-on-linux-with-minikube.md @@ -18,7 +18,7 @@ This is post #1 in a series about the local deployment options on Linux, and it [Minikube](https://github.com/kubernetes/minikube) is a cross-platform, community-driven [Kubernetes](https://kubernetes.io/) distribution, which is targeted to be used primarily in local environments. It deploys a single-node cluster, which is an excellent option for having a simple Kubernetes cluster up and running on localhost. -Minikube is designed to be used as a virtual machine (VM), and the default VM runtime is [VirtualBox](https://www.virtualbox.org/). At the same time, extensibility is one of the critical benefits of Minikube, so it's possible to use it with [drivers](https://github.com/kubernetes/minikube/blob/master/docs/drivers.md) outside of VirtualBox. +Minikube is designed to be used as a virtual machine (VM), and the default VM runtime is [VirtualBox](https://www.virtualbox.org/). At the same time, extensibility is one of the critical benefits of Minikube, so it's possible to use it with [drivers](https://minikube.sigs.k8s.io/docs/drivers/) outside of VirtualBox. By default, Minikube uses Virtualbox as a runtime for running the virtual machine. Virtualbox is a cross-platform solution, which can be used on a variety of operating systems, including GNU/Linux, Windows, and macOS. diff --git a/content/en/blog/_posts/2020-06-29-working-with-terraform-and-kubernetes.md b/content/en/blog/_posts/2020-06-29-working-with-terraform-and-kubernetes.md new file mode 100644 index 0000000000..1b15ae28d2 --- /dev/null +++ b/content/en/blog/_posts/2020-06-29-working-with-terraform-and-kubernetes.md @@ -0,0 +1,59 @@ +--- +layout: blog +title: "Working with Terraform and Kubernetes" +date: 2020-06-29 +slug: working-with-terraform-and-kubernetes +url: /blog/2020/06/working-with-terraform-and-kubernetes +--- + +**Author:** [Philipp Strube](https://twitter.com/pst418), Kubestack + +Maintaining Kubestack, an open-source [Terraform GitOps Framework](https://www.kubestack.com/lp/terraform-gitops-framework) for Kubernetes, I unsurprisingly spend a lot of time working with Terraform and Kubernetes. Kubestack provisions managed Kubernetes services like AKS, EKS and GKE using Terraform but also integrates cluster services from Kustomize bases into the GitOps workflow. Think of cluster services as everything that's required on your Kubernetes cluster, before you can deploy application workloads. + +Hashicorp recently announced [better integration between Terraform and Kubernetes](https://www.hashicorp.com/blog/deploy-any-resource-with-the-new-kubernetes-provider-for-hashicorp-terraform/). I took this as an opportunity to give an overview of how Terraform can be used with Kubernetes today and what to be aware of. + +In this post I will however focus only on using Terraform to provision Kubernetes API resources, not Kubernetes clusters. + +[Terraform](https://www.terraform.io/intro/index.html) is a popular infrastructure as code solution, so I will only introduce it very briefly here. In a nutshell, Terraform allows declaring a desired state for resources as code, and will determine and execute a plan to take the infrastructure from its current state, to the desired state. + +To be able to support different resources, Terraform requires providers that integrate the respective API. So, to create Kubernetes resources we need a Kubernetes provider. Here are our options: + +## Terraform `kubernetes` provider (official) + +First, the [official Kubernetes provider](https://github.com/hashicorp/terraform-provider-kubernetes). This provider is undoubtedly the most mature of the three. However, it comes with a big caveat that's probably the main reason why using Terraform to maintain Kubernetes resources is not a popular choice. + +Terraform requires a schema for each resource and this means the maintainers have to translate the schema of each Kubernetes resource into a Terraform schema. This is a lot of effort and was the reason why for a long time the supported resources where pretty limited. While this has improved over time, still not everything is supported. And especially [custom resources](https://kubernetes.io/docs/concepts/extend-kubernetes/api-extension/custom-resources/) are not possible to support this way. + +This schema translation also results in some edge cases to be aware of. For example, `metadata` in the Terraform schema is a list of maps. Which means you have to refer to the `metadata.name` of a Kubernetes resource like this in Terraform: `kubernetes_secret.example.metadata.0.name`. + +On the plus side however, having a Terraform schema means full integration between Kubernetes and other Terraform resources. Like for [example](https://github.com/kbst/terraform-kubestack/blob/e5caa6d20926d546a045144ebe79c7cc8c0b4c8a/aws/_modules/eks/ingress.tf#L37), using Terraform to create a Kubernetes service of type `LoadBalancer` and then use the returned ELB hostname in a Route53 record to configure DNS. + +The biggest benefit when using Terraform to maintain Kubernetes resources is integration into the Terraform plan/apply life-cycle. So you can review planned changes before applying them. Also, using `kubectl`, purging of resources from the cluster is not trivial without manual intervention. Terraform does this reliably. + +## Terraform `kubernetes-alpha` provider + +Second, the new [alpha Kubernetes provider](https://github.com/hashicorp/terraform-provider-kubernetes-alpha). As a response to the limitations of the current Kubernetes provider the Hashicorp team recently released an alpha version of a new provider. + +This provider uses dynamic resource types and server-side-apply to support all Kubernetes resources. I personally think this provider has the potential to be a game changer - even if [managing Kubernetes resources in HCL](https://github.com/hashicorp/terraform-provider-kubernetes-alpha#moving-from-yaml-to-hcl) may still not be for everyone. Maybe the Kustomize provider below will help with that. + +The only downside really is, that it's explicitly discouraged to use it for anything but testing. But the more people test it, the sooner it should be ready for prime time. So I encourage everyone to give it a try. + +## Terraform `kustomize` provider + +Last, we have the [`kustomize` provider](https://github.com/kbst/terraform-provider-kustomize). Kustomize provides a way to do customizations of Kubernetes resources using inheritance instead of templating. It is designed to output the result to `stdout`, from where you can apply the changes using `kubectl`. This approach means that `kubectl` edge cases like no purging or changes to immutable attributes still make full automation difficult. + +Kustomize is a popular way to handle customizations. But I was looking for a more reliable way to automate applying changes. Since this is exactly what Terraform is great at the Kustomize provider was born. + +Not going into too much detail here, but from Terraform's perspective, this provider treats every Kubernetes resource as a JSON string. This way it can handle any Kubernetes resource resulting from the Kustomize build. But it has the big disadvantage that Kubernetes resources can not easily be integrated with other Terraform resources. Remember the load balancer example from above. + +Under the hood, similarly to the new Kubernetes alpha provider, the Kustomize provider also uses the dynamic Kubernetes client and server-side-apply. Going forward, I plan to deprecate this part of the Kustomize provider that overlaps with the new Kubernetes provider and only keep the Kustomize integration. + +## Conclusion + +For teams that are already invested into Terraform, or teams that are looking for ways to replace `kubectl` in automation, Terraform's plan/apply life-cycle has always been a promising option to automate changes to Kubernetes resources. However, the limitations of the official Kubernetes provider resulted in this not seeing significant adoption. + +The new alpha provider removes the limitations and has the potential to make Terraform a prime option to automate changes to Kubernetes resources. + +Teams that have already adopted Kustomize, may find integrating Kustomize and Terraform using the Kustomize provider beneficial over `kubectl` because it avoids common edge cases. Even if in this set up, Terraform can only easily be used to plan and apply the changes, not to adapt the Kubernetes resources. In the future, this issue may be resolved by combining the Kustomize provider with the new Kubernetes provider. + +If you have any questions regarding these three options, feel free to reach out to me on the Kubernetes Slack in either the [#kubestack](https://app.slack.com/client/T09NY5SBT/CMBCT7XRQ) or the [#kustomize](https://app.slack.com/client/T09NY5SBT/C9A5ALABG) channel. If you happen to give any of the providers a try and encounter a problem, please file a GitHub issue to help the maintainers fix it. diff --git a/content/en/blog/_posts/2020-06-30-SIG-Windows-Spotlight/KubernetesComputer_transparent.png b/content/en/blog/_posts/2020-06-30-SIG-Windows-Spotlight/KubernetesComputer_transparent.png new file mode 100644 index 0000000000..86e4bdff5f Binary files /dev/null and b/content/en/blog/_posts/2020-06-30-SIG-Windows-Spotlight/KubernetesComputer_transparent.png differ diff --git a/content/en/blog/_posts/2020-06-30-SIG-Windows-Spotlight/PeopleDoodle_transparent.png b/content/en/blog/_posts/2020-06-30-SIG-Windows-Spotlight/PeopleDoodle_transparent.png new file mode 100644 index 0000000000..6657c31ec4 Binary files /dev/null and b/content/en/blog/_posts/2020-06-30-SIG-Windows-Spotlight/PeopleDoodle_transparent.png differ diff --git a/content/en/blog/_posts/2020-06-30-SIG-Windows-Spotlight/cgroupsNamespacesComboPic.png b/content/en/blog/_posts/2020-06-30-SIG-Windows-Spotlight/cgroupsNamespacesComboPic.png new file mode 100644 index 0000000000..4aae049d00 Binary files /dev/null and b/content/en/blog/_posts/2020-06-30-SIG-Windows-Spotlight/cgroupsNamespacesComboPic.png differ diff --git a/content/en/blog/_posts/2020-06-30-SIG-Windows-Spotlight/index.md b/content/en/blog/_posts/2020-06-30-SIG-Windows-Spotlight/index.md new file mode 100644 index 0000000000..47112fab24 --- /dev/null +++ b/content/en/blog/_posts/2020-06-30-SIG-Windows-Spotlight/index.md @@ -0,0 +1,103 @@ +--- +layout: blog +title: "SIG-Windows Spotlight" +date: 2020-06-30 +slug: sig-windows-spotlight-2020 +--- + +_This post tells the story of how Kubernetes contributors work together to provide a container orchestrator that works for both Linux and Windows._ + +Image of a computer with Kubernetes logo + +Most people who are familiar with Kubernetes are probably used to associating it with Linux. The connection makes sense, since Kubernetes ran on Linux from its very beginning. However, many teams and organizations working on adopting Kubernetes need the ability to orchestrate containers on Windows. Since the release of Docker and rise to popularity of containers, there have been efforts both from the community and from Microsoft itself to make container technology as accessible in Windows systems as it is in Linux systems. + +Within the Kubernetes community, those who are passionate about making Kubernetes accessible to the Windows community can find a home in the Windows Special Interest Group. To learn more about SIG-Windows and the future of Kubernetes on Windows, I spoke to co-chairs [Mark Rossetti](https://github.com/marosset) and [Michael Michael](https://github.com/michmike) about the SIG's goals and how others can contribute. + +## Intro to Windows Containers & Kubernetes + +Kubernetes is the most popular tool for orchestrating container workloads, so to understand the Windows Special Interest Group (SIG) within the Kubernetes project, it's important to first understand what we mean when we talk about running containers on Windows. + +*** +_"When looking at Windows support in Kubernetes," says SIG (Special Interest Group) Co-chairs Mark Rossetti and Michael Michael, "many start drawing comparisons to Linux containers. Although some of the comparisons that highlight limitations are fair, it is important to distinguish between operational limitations and differences between the Windows and Linux operating systems. Windows containers run the Windows operating system and Linux containers run Linux."_ +*** + +In essence, any "container" is simply a process being run on its host operating system, with some key tooling in place to isolate that process and its dependencies from the rest of the environment. The goal is to make that running process safely isolated, while taking up minimal resources from the system to perform that isolation. On Linux, the tooling used to isolate processes to create "containers" commonly boils down to cgroups and namespaces (among a few others), which are themselves tools built in to the Linux Kernel. + +A visual analogy using dogs to explain Linux cgroups and namespaces. + +#### _If dogs were processes: containerization would be like giving each dog their own resources like toys and food using cgroups, and isolating troublesome dogs using namespaces._ + + +Native Windows processes are processes that are or must be run on a Windows operating system. This makes them fundamentally different from a process running on a Linux operating system. Since Linux containers are Linux processes being isolated by the Linux kernel tools known as cgroups and namespaces, containerizing native Windows processes meant implementing similar isolation tools within the Windows kernel itself. Thus, "Windows Containers" and "Linux Containers" are fundamentally different technologies, even though they have the same goals (isolating processes) and in some ways work similarly (using kernel level containerization). + +So when it comes to running containers on Windows, there are actually two very important concepts to consider: + +* Native Windows processes running as native Windows Server style containers, +* and traditional Linux containers running on a Linux Kernel, generally hosted on a lightweight Hyper-V Virtual Machine. + +You can learn more about Linux and Windows containers in this [tutorial](https://docs.microsoft.com/en-us/virtualization/windowscontainers/deploy-containers/linux-containers) from Microsoft. + + + +### Kubernetes on Windows + +Kubernetes was initially designed with Linux containers in mind and was itself designed to run on Linux systems. Because of that, much of the functionality of Kubernetes involves unique Linux functionality. The Linux-specific work is intentional--we all want Kubernetes to run optimally on Linux--but there is a growing demand for similar optimization for Windows servers. For cases where users need container orchestration on Windows, the Kubernetes contributor community of SIG-Windows has incorporated functionality for Windows-specific use cases. + +*** +_"A common question we get is, will I be able to have a Windows-only cluster. The answer is NO. Kubernetes control plane components will continue to be based on Linux, while SIG-Windows is concentrating on the experience of having Windows worker nodes in a Kubernetes cluster."_ +*** + +Rather than separating out the concepts of "Windows Kubernetes," and "Linux Kubernetes," the community of SIG-Windows works toward adding functionality to the main Kubernetes project which allows it to handle use cases for Windows. These Windows capabilities mirror, and in some cases add unique functionality to, the Linux use cases Kubernetes has served since its release in 2014 (want to learn more history? Scroll through this [original design document](https://github.com/kubernetes/kubernetes/blob/e2b948dbfbba62b8cb681189377157deee93bb43/DESIGN.md). + + +## What Does SIG-Windows Do? + +*** +_"SIG-Windows is really the center for all things Windows in Kubernetes,"_ SIG chairs Mark and Michael said, _"We mainly focus on the compute side of things, but really anything related to running Kubernetes on Windows is in scope for SIG-Windows."_ +*** + +In order to best serve users, SIG-Windows works to make the Kubernetes user experience as consistent as possible for users of Windows and Linux. However some use cases simply only apply to one Operating System, and as such, the SIG-Windows group also works to create functionality that is unique to Windows-only workloads. + +Many SIGs, or "Special Interest Groups" within Kubernetes have a narrow focus, allowing members to dive deep on a certain facet of the technology. While specific expertise is welcome, those interested in SIG-Windows will find it to be a great community to build broad understanding across many focus areas of Kubernetes. "Members from our SIG interface with storage, network, testing, cluster-lifecycle and others groups in Kubernetes." + +### Who are SIG-Windows' Users? +The best way to understand the technology a group makes, is often to understand who their customers or users are. + + + +#### "A majority of the users we've interacted with have business-critical infrastructure running on Windows developed over many years and can't move those workloads to Linux for various reasons (cost, time, compliance, etc)," the SIG chairs shared. "By transporting those workloads into Windows containers and running them in Kubernetes they are able to quickly modernize their infrastructure and help migrate it to the cloud." + +As anyone in the Kubernetes space can attest, companies around the world, in many different industries, see Kubernetes as their path to modernizing their infrastructure. Often this involves re-architecting or event totally re-inventing many of the ways they've been doing business. With the goal being to make their systems more scalable, more robust, and more ready for anything the future may bring. But not every application or workload can or should change the core operating system it runs on, so many teams need the ability to run containers at scale on Windows, or Linux, or both. + +"Sometimes the driver to Windows containers is a modernization effort and sometimes it’s because of expiring hardware warranties or end-of-support cycles for the current operating system. Our efforts in SIG-Windows enable Windows developers to take advantage of cloud native tools and Kubernetes to build and deploy distributed applications faster. That’s exciting! In essence, users can retain the benefits of application availability while decreasing costs." + +## Who are SIG-Windows? + +Who are these contributors working on enabling Windows workloads for Kubernetes? It could be you! + +Like with other Kubernetes SIGs, contributors to SIG-Windows can be anyone from independent hobbyists to professionals who work at many different companies. They come from many different parts of the world and bring to the table many different skill sets. + +Image of several people chatting pleasantly + +_"Like most other Kubernetes SIGs, we are a very welcome and open community," explained the SIG co-chairs Michael Michael and Mark Rosetti._ + + +### Becoming a contributor + +For anyone interested in getting started, the co-chairs added, "New contributors can view old community meetings on GitHub (we record every single meeting going back three years), read our documentation, attend new community meetings, ask questions in person or on Slack, and file some issues on Github. We also attend all KubeCon conferences and host 1-2 sessions, a contributor session, and meet-the-maintainer office hours." + +The co-chairs also shared a glimpse into what the path looks like to becoming a member of the SIG-Windows community: + +"We encourage new contributors to initially just join our community and listen, then start asking some questions and get educated on Windows in Kubernetes. As they feel comfortable, they could graduate to improving our documentation, file some bugs/issues, and eventually they can be a code contributor by fixing some bugs. If they have long-term and sustained substantial contributions to Windows, they could become a technical lead or a chair of SIG-Windows. You won't know if you love this area unless you get started :) To get started, [visit this getting-started page](https://github.com/kubernetes/community/tree/master/sig-windows). It's a one stop shop with links to everything related to SIG-Windows in Kubernetes." + +When asked if there were any useful skills for new contributors, the co-chairs said, + +"We are always looking for expertise in Go and Networking and Storage, along with a passion for Windows. Those are huge skills to have. However, we don’t require such skills, and we welcome any and all contributors, with varying skill sets. If you don’t know something, we will help you acquire it." + +You can get in touch with the folks at SIG-Windows in their [Slack channel](https://kubernetes.slack.com/archives/C0SJ4AFB7) or attend one of their regular meetings - currently 30min long on Tuesdays at 12:30PM EST! You can find links to their regular meetings as well as past meeting notes and recordings from the [SIG-Windows README](https://github.com/kubernetes/community/tree/master/sig-windows#readme) on GitHub. + +As a closing message from SIG-Windows: + +*** +#### _"We welcome you to get involved and join our community to share feedback and deployment stories, and contribute to code, docs, and improvements of any kind."_ +*** diff --git a/content/en/blog/_posts/2020-07-27-kubernetes-1-17-release-interview.md b/content/en/blog/_posts/2020-07-27-kubernetes-1-17-release-interview.md new file mode 100644 index 0000000000..c61def44be --- /dev/null +++ b/content/en/blog/_posts/2020-07-27-kubernetes-1-17-release-interview.md @@ -0,0 +1,219 @@ +--- +layout: blog +title: "Music and math: the Kubernetes 1.17 release interview" +date: 2020-07-27 +--- + +**Author**: Adam Glick (Google) + +Every time the Kubernetes release train stops at the station, we like to ask the release lead to take a moment to reflect on their experience. That takes the form of an interview on the weekly [Kubernetes Podcast from Google](https://kubernetespodcast.com/) that I co-host with [Craig Box](https://twitter.com/craigbox). If you're not familiar with the show, every week we summarise the new in the Cloud Native ecosystem, and have an insightful discussion with an interesting guest from the broader Kubernetes community. + +At the time of the 1.17 release in December, we [talked to release team lead Guinevere Saenger](https://kubernetespodcast.com/episode/083-kubernetes-1.17/). We have [shared](https://kubernetes.io/blog/2018/07/16/how-the-sausage-is-made-the-kubernetes-1.11-release-interview-from-the-kubernetes-podcast/) [the](https://kubernetes.io/blog/2019/05/13/cat-shirts-and-groundhog-day-the-kubernetes-1.14-release-interview/) [transcripts](https://kubernetes.io/blog/2019/12/06/when-youre-in-the-release-team-youre-family-the-kubernetes-1.16-release-interview/) of previous interviews on the Kubernetes blog, and we're very happy to share another today. + +Next week we will bring you up to date with the story of Kubernetes 1.18, as we gear up for the release of 1.19 next month. [Subscribe to the show](https://kubernetespodcast.com/subscribe/) wherever you get your podcasts to make sure you don't miss that chat! + +--- + +**ADAM GLICK: You have a nontraditional background for someone who works as a software engineer. Can you explain that background?** + +GUINEVERE SAENGER: My first career was as a [collaborative pianist](https://en.wikipedia.org/wiki/Collaborative_piano), which is an academic way of saying "piano accompanist". I was a classically trained pianist who spends most of her time onstage, accompanying other people and making them sound great. + +**ADAM GLICK: Is that the piano equivalent of pair-programming?** + +GUINEVERE SAENGER: No one has said it to me like that before, but all sorts of things are starting to make sense in my head right now. I think that's a really great way of putting it. + +**ADAM GLICK: That's a really interesting background, as someone who also has a background with music. What made you decide to get into software development?** + +GUINEVERE SAENGER: I found myself in a life situation where I needed more stable source of income, and teaching music, and performing for various gig opportunities, was really just not cutting it anymore. And I found myself to be working really, really hard with not much to show for it. I had a lot of friends who were software engineers. I live in Seattle. That's sort of a thing that happens to you when you live in Seattle — you get to know a bunch of software engineers, one way or the other. + +The ones I met were all lovely people, and they said, hey, I'm happy to show you how to program in Python. And so I did that for a bit, and then I heard about this program called [Ada Developers Academy](https://adadevelopersacademy.org/). That's a year long coding school, targeted at women and non-binary folks that are looking for a second career in tech. And so I applied for that. + +**CRAIG BOX: What can you tell us about that program?** + +GUINEVERE SAENGER: It's incredibly selective, for starters. It's really popular in Seattle and has gotten quite a good reputation. It took me three tries to get in. They do two classes a year, and so it was a while before I got my response saying 'congratulations, we are happy to welcome you into Cohort 6'. I think what sets Ada Developers Academy apart from other bootcamp style coding programs are three things, I think? The main important one is that if you get in, you pay no tuition. The entire program is funded by company sponsors. + +**CRAIG BOX: Right.** + +GUINEVERE SAENGER: The other thing that really convinced me is that five months of the 11-month program are an industry internship, which means you get both practical experience, mentorship, and potential job leads at the end of it. + +**CRAIG BOX: So very much like a condensed version of the University of Waterloo degree, where you do co-op terms.** + +GUINEVERE SAENGER: Interesting. I didn't know about that. + +**CRAIG BOX: Having lived in Waterloo for a while, I knew a lot of people who did that. But what would you say the advantages were of going through such a condensed schooling process in computer science?** + +GUINEVERE SAENGER: I'm not sure that the condensed process is necessarily an advantage. I think it's a necessity, though. People have to quit their jobs to go do this program. It's not an evening school type of thing. + +**CRAIG BOX: Right.** + +GUINEVERE SAENGER: And your internship is basically a full-time job when you do it. One thing that Ada was really, really good at is giving us practical experience that directly relates to the workplace. We learned how to use Git. We learned how to design websites using [Rails](https://rubyonrails.org/). And we also learned how to collaborate, how to pair-program. We had a weekly retrospective, so we sort of got a soft introduction to workflows at a real workplace. Adding to that, the internship, and I think the overall experience is a little bit more 'practical workplace oriented' and a little bit less academic. + +When you're done with it, you don't have to relearn how to be an adult in a working relationship with other people. You come with a set of previous skills. There are Ada graduates who have previously been campaign lawyers, and veterinarians, and nannies, cooks, all sorts of people. And it turns out these skills tend to translate, and they tend to matter. + +**ADAM GLICK: With your background in music, what do you think that that allows you to bring to software development that could be missing from, say, standard software development training that people go through?** + +GUINEVERE SAENGER: People tend to really connect the dots when I tell them I used to be a musician. Of course, I still consider myself a musician, because you don't really ever stop being a musician. But they say, 'oh, yeah, music and math', and that's just a similar sort of brain. And that makes so much sense. And I think there's a little bit of a point to that. When you learn a piece of music, you have to start recognizing patterns incredibly quickly, almost intuitively. + +And I think that is the main skill that translates into programming— recognizing patterns, finding the things that work, finding the things that don't work. And for me, especially as a collaborative pianist, it's the communicating with people, the finding out what people really want, where something is going, how to figure out what the general direction is that we want to take, before we start writing the first line of code. + +**CRAIG BOX: In your experience at Ada or with other experiences you've had, have you been able to identify patterns in other backgrounds for people that you'd recommend, 'hey, you're good at music, so therefore you might want to consider doing something like a course in computer science'?** + +GUINEVERE SAENGER: Overall, I think ultimately writing code is just giving a set of instructions to a computer. And we do that in daily life all the time. We give instructions to our kids, we give instructions to our students. We do math, we write textbooks. We give instructions to a room full of people when you're in court as a lawyer. + +Actually, the entrance exam to Ada Developers Academy used to have questions from the [LSAT](https://en.wikipedia.org/wiki/Law_School_Admission_Test) on it to see if you were qualified to join the program. They changed that when I applied, but I think that's a thing that happened at one point. So, overall, I think software engineering is a much more varied field than we give it credit for, and that there are so many ways in which you can apply your so-called other skills and bring them under the umbrella of software engineering. + +**CRAIG BOX: I do think that programming is effectively half art and half science. There's creativity to be applied. There is perhaps one way to solve a problem most efficiently. But there are many different ways that you can choose to express how you compiled something down to that way.** + +GUINEVERE SAENGER: Yeah, I mean, that's definitely true. I think one way that you could probably prove that is that if you write code at work and you're working on something with other people, you can probably tell which one of your co-workers wrote which package, just by the way it's written, or how it is documented, or how it is styled, or any of those things. I really do think that the human character shines through. + +**ADAM GLICK: What got you interested in Kubernetes and open source?** + +GUINEVERE SAENGER: The honest answer is absolutely nothing. Going back to my programming school— and remember that I had to do a five-month internship as part of my training— the way that the internship works is that sponsor companies for the program get interns in according to how much they sponsored a specific cohort of students. + +So at the time, Samsung and SDS offered to host two interns for five months on their [Cloud Native Computing team](https://samsung-cnct.github.io/) and have that be their practical experience. So I go out of a Ruby on Rails full stack web development bootcamp and show up at my internship, and they said, "Welcome to Kubernetes. Try to bring up a cluster." And I said, "Kuber what?" + +**CRAIG BOX: We've all said that on occasion.** + +**ADAM GLICK: Trial by fire, wow.** + +GUINEVERE SAENGER: I will say that that entire team was absolutely wonderful, delightful to work with, incredibly helpful. And I will forever be grateful for all of the help and support that I got in that environment. It was a great place to learn. + +**CRAIG BOX: You now work on GitHub's Kubernetes infrastructure. Obviously, there was GitHub before there was a Kubernetes, so a migration happened. What can you tell us about the transition that GitHub made to running on Kubernetes?** + +GUINEVERE SAENGER: A disclaimer here— I was not at GitHub at the time that the transition to Kubernetes was made. However, to the best of my knowledge, the decision to transition to Kubernetes was made and people decided, yes, we want to try Kubernetes. We want to use Kubernetes. And mostly, the only decision left was, which one of our applications should we move over to Kubernetes? + +**CRAIG BOX: I thought GitHub was written on Rails, so there was only one application.** + +GUINEVERE SAENGER: [LAUGHING] We have a lot of supplementary stuff under the covers. + +**CRAIG BOX: I'm sure.** + +GUINEVERE SAENGER: But yes, GitHub is written in Rails. It is still written in Rails. And most of the supplementary things are currently running on Kubernetes. We have a fair bit of stuff that currently does not run on Kubernetes. Mainly, that is GitHub Enterprise related things. I would know less about that because I am on the platform team that helps people use the Kubernetes infrastructure. But back to your question, leadership at the time decided that it would be a good idea to start with GitHub the Rails website as the first project to move to Kubernetes. + +**ADAM GLICK: High stakes!** + +GUINEVERE SAENGER: The reason for this was that they decided if they were going to not start big, it really wasn't going to transition ever. It was really not going to happen. So they just decided to go all out, and it was successful, for which I think the lesson would probably be commit early, commit big. + +**CRAIG BOX: Are there any other lessons that you would take away or that you've learned kind of from the transition that the company made, and might be applicable to other people who are looking at moving their companies from a traditional infrastructure to a Kubernetes infrastructure?** + +GUINEVERE SAENGER: I'm not sure this is a lesson specifically, but I was on support recently, and it turned out that, due to unforeseen circumstances and a mix of human error, a bunch of the namespaces on one of our Kubernetes clusters got deleted. + +**ADAM GLICK: Oh, my.** + +GUINEVERE SAENGER: It should not have affected any customers, I should mention, at this point. But all in all, it took a few of us a few hours to almost completely recover from this event. I think that, without Kubernetes, this would not have been possible. + +**CRAIG BOX: Generally, deleting something like that is quite catastrophic. We've seen a number of other vendors suffer large outages when someone's done something to that effect, which is why we get [#hugops](https://twitter.com/hashtag/hugops) on Twitter all the time.** + +GUINEVERE SAENGER: People did send me #hugops, that is a thing that happened. But overall, something like this was an interesting stress test and sort of proved that it wasn't nearly as catastrophic as a worst case scenario. + +**CRAIG BOX: GitHub [runs its own data centers](https://githubengineering.com/githubs-metal-cloud/). Kubernetes was largely built for running on the cloud, but a lot of people do choose to run it on their own, bare metal. How do you manage clusters and provisioning of the machinery you run?** + +GUINEVERE SAENGER: When I started, my onboarding project was to deprovision an old cluster, make sure all the traffic got moved to somewhere where it would keep running, provision a new cluster, and then move website traffic onto the new cluster. That was a really exciting onboarding project. At the time, we provisioned bare metal machines using Puppet. We still do that to a degree, but I believe the team that now runs our computing resources actually inserts virtual machines as an extra layer between the bare metal and the Kubernetes nodes. + +Again, I was not intrinsically part of that decision, but my understanding is that it just makes for a greater reliability and reproducibility across the board. We've had some interesting hardware dependency issues come up, and the virtual machines basically avoid those. + +**CRAIG BOX: You've been working with Kubernetes for a couple of years now. How did you get involved in the release process?** + +GUINEVERE SAENGER: When I first started in the project, I started at the [special interest group for contributor experience](https://github.com/kubernetes/community/tree/master/sig-contributor-experience#readme), namely because one of my co-workers at the time, Aaron Crickenberger, was a big Kubernetes community person. Still is. + +**CRAIG BOX: We've [had him on the show](https://kubernetespodcast.com/episode/046-kubernetes-1.14/) for one of these very release interviews!** + +GUINEVERE SAENGER: In fact, this is true! So Aaron and I actually go way back to Samsung SDS. Anyway, Aaron suggested that I should write up a contribution to the Kubernetes project, and I said, me? And he said, yes, of course. You will be [speaking at KubeCon](https://www.youtube.com/watch?v=TkCDUFR6xqw), so you should probably get started with a PR or something. So I tried, and it was really, really hard. And I complained about it [in a public GitHub issue](https://github.com/kubernetes/community/issues/141), and people said, yeah. Yeah, we know it's hard. Do you want to help with that? + +And so I started getting really involved with the [process for new contributors to get started](https://github.com/kubernetes/community/tree/master/contributors/guide) and have successes, kind of getting a foothold into a project that's as large and varied as Kubernetes. From there on, I began to talk to people, get to know people. The great thing about the Kubernetes community is that there is so much mentorship to go around. + +**ADAM GLICK: Right.** + +GUINEVERE SAENGER: There are so many friendly people willing to help. It's really funny when I talk to other people about it. They say, what do you mean, your coworker? And I said, well, he's really a colleague. He really works for another company. + +**CRAIG BOX: He's sort-of officially a competitor.** + +GUINEVERE SAENGER: Yeah. + +**CRAIG BOX: But we're friends.** + +GUINEVERE SAENGER: But he totally helped me when I didn't know how to git patch my borked pull request. So that happened. And eventually, somebody just suggested that I start following along in the release process and shadow someone on their release team role. And that, at the time, was Tim Pepper, who was bug triage lead, and I shadowed him for that role. + +**CRAIG BOX: Another [podcast guest](https://kubernetespodcast.com/episode/010-kubernetes-1.11/) on the interview train.** + +GUINEVERE SAENGER: This is a pattern that probably will make more sense once I explain to you about the shadow process of the release team. + +**ADAM GLICK: Well, let's turn to the Kubernetes release and the release process. First up, what's new in this release of 1.17?** + +GUINEVERE SAENGER: We have only a very few new things. The one that I'm most excited about is that we have moved [IPv4 and IPv6 dual stack](https://github.com/kubernetes/enhancements/issues/563) support to alpha. That is the most major change, and it has been, I think, a year and a half in coming. So this is the very first cut of that feature, and I'm super excited about that. + +**CRAIG BOX: The people who have been promised IPv6 for many, many years and still don't really see it, what will this mean for them?** + +**ADAM GLICK: And most importantly, why did we skip IPv5 support?** + +GUINEVERE SAENGER: I don't know! + +**CRAIG BOX: Please see [the appendix to this podcast](https://softwareengineering.stackexchange.com/questions/185380/ipv4-to-ipv6-where-is-ipv5) for technical explanations.** + +GUINEVERE SAENGER: Having a dual stack configuration obviously enables people to have a much more flexible infrastructure and not have to worry so much about making decisions that will become outdated or that may be over-complicated. This basically means that pods can have dual stack addresses, and nodes can have dual stack addresses. And that basically just makes communication a lot easier. + +**CRAIG BOX: What about features that didn't make it into the release? We had a conversation with Lachie in the [1.16 interview](https://kubernetespodcast.com/episode/072-kubernetes-1.16/), where he mentioned [sidecar containers](https://github.com/kubernetes/enhancements/blob/master/keps/sig-apps/sidecarcontainers.md). They unfortunately didn't make it into that release. And I see now that they haven't made this one either.** + +GUINEVERE SAENGER: They have not, and we are actually currently undergoing an effort of tracking features that flip multiple releases. + +As a community, we need everyone's help. There are a lot of features that people want. There is also a lot of cleanup that needs to happen. And we have started talking at previous KubeCons repeatedly about problems with maintainer burnout, reviewer burnout, have a hard time finding reviews for your particular contributions, especially if you are not an entrenched member of the community. And it has become very clear that this is an area where the entire community needs to improve. + +So the unfortunate reality is that sometimes life happens, and people are busy. This is an open source project. This is not something that has company mandated OKRs. Particularly during the fourth quarter of the year in North America, but around the world, we have a lot of holidays. It is the end of the year. Kubecon North America happened as well. This makes it often hard to find a reviewer in time or to rally the support that you need for your enhancement proposal. Unfortunately, slipping releases is fairly common and, at this point, expected. We started out with having 42 enhancements and [landed with roughly half of that](https://docs.google.com/spreadsheets/d/1ebKGsYB1TmMnkx86bR2ZDOibm5KWWCs_UjV3Ys71WIs/edit#gid=0). + +**CRAIG BOX: I was going to ask about the truncated schedule due to the fourth quarter of the year, where there are holidays in large parts of the world. Do you find that the Q4 release on the whole is smaller than others, if not for the fact that it's some week shorter?** + +GUINEVERE SAENGER: Q4 releases are shorter by necessity because we are trying to finish the final release of the year before the end of the year holidays. Often, releases are under pressure of KubeCons, during which finding reviewers or even finding the time to do work can be hard to do, if you are attending. And even if you're not attending, your reviewers might be attending. + +It has been brought up last year to make the final release more of a stability release, meaning no new alpha features. In practice, for this release, this is actually quite close to the truth. We have four features graduating to beta and most of our features are graduating to stable. I am hoping to use this as a precedent to change our process to make the final release a stability release from here on out. The timeline fits. The past experience fits this model. + +**ADAM GLICK: On top of all of the release work that was going on, there was also KubeCon that happened. And you were involved in the [contributor summit](https://github.com/kubernetes/community/tree/master/events/2019/11-contributor-summit). How was the summit?** + +GUINEVERE SAENGER: This was the first contributor summit where we had an organized events team with events organizing leads, and handbooks, and processes. And I have heard from multiple people— this is just word of mouth— that it was their favorite contributor summit ever. + +**CRAIG BOX: Was someone allocated to hat production? [Everyone had sailor hats](https://flickr.com/photos/143247548@N03/49093218951/).** + +GUINEVERE SAENGER: Yes, the entire event staff had sailor hats with their GitHub handle on them, and it was pretty fantastic. You can probably see me wearing one in some of the pictures from the contributor summit. That literally was something that was pulled out of a box the morning of the contributor summit, and no one had any idea. But at first, I was a little skeptical, but then I put it on and looked at myself in the mirror. And I was like, yes. Yes, this is accurate. We should all wear these. + +**ADAM GLICK: Did getting everyone together for the contributor summit help with the release process?** + +GUINEVERE SAENGER: It did not. It did quite the opposite, really. Well, that's too strong. + +**ADAM GLICK: Is that just a matter of the time taken up?** + +GUINEVERE SAENGER: It's just a completely different focus. Honestly, it helped getting to know people face-to-face that I had currently only interacted with on video. But we did have to cancel the release team meeting the day of the contributor summit because there was kind of no sense in having it happen. We moved it to the Tuesday, I believe. + +**CRAIG BOX: The role of the release team leader has been described as servant leadership. Do you consider the position proactive or reactive?** + +GUINEVERE SAENGER: Honestly, I think that depends on who's the release team lead, right? There are some people who are very watchful and look for trends, trying to detect problems before they happen. I tend to be in that camp, but I also know that sometimes it's not possible to predict things. There will be last minute bugs sometimes, sometimes not. If there is a last minute bug, you have to be ready to be on top of that. So for me, the approach has been I want to make sure that I have my priorities in order and also that I have backups in case I can't be available. + +**ADAM GLICK: What was the most interesting part of the release process for you?** + +GUINEVERE SAENGER: A release lead has to have served in other roles on the release team prior to being release team lead. To me, it was very interesting to see what other roles were responsible for, ones that I hadn't seen from the inside before, such as docs, CI signal. I had helped out with CI signal for a bit, but I want to give a big shout out to CI signal lead, Alena Varkockova, who was able to communicate effectively and kindly with everyone who was running into broken tests, failing tests. And she was very effective in getting all of our tests up and running. + +So that was actually really cool to see. And yeah, just getting to see more of the workings of the team, for me, it was exciting. The other big exciting thing, of course, was to see all the changes that were going in and all the efforts that were being made. + +**CRAIG BOX: The release lead for 1.18 has just been announced as [Jorge Alarcon](https://twitter.com/alejandrox135). What are you going to put in the proverbial envelope as advice for him?** + +GUINEVERE SAENGER: I would want Jorge to be really on top of making sure that every Special Interest Group that enters a change, that has an enhancement for 1.18, is on top of the timelines and is responsive. Communication tends to be a problem. And I had hinted at this earlier, but some enhancements slipped simply because there wasn't enough reviewer bandwidth. + +Greater communication of timelines and just giving people more time and space to be able to get in their changes, or at least, seemingly give them more time and space by sending early warnings, is going to be helpful. Of course, he's going to have a slightly longer release, too, than I did. This might be related to a unique Q4 challenge. Overall, I would encourage him to take more breaks, to rely more on his release shadows, and split out the work in a fashion that allows everyone to have a turn and everyone to have a break as well. + +**ADAM GLICK: What would your advice be to someone who is hearing your experience and is inspired to get involved with the Kubernetes release or contributer process?** + +GUINEVERE SAENGER: Those are two separate questions. So let me tackle the Kubernetes release question first. Kubernetes [SIG Release](https://github.com/kubernetes/sig-release/#readme) has, in my opinion, a really excellent onboarding program for new members. We have what is called the [Release Team Shadow Program](https://github.com/kubernetes/sig-release/blob/master/release-team/shadows.md). We also have the Release Engineering Shadow Program, or the Release Management Shadow Program. Those are two separate subprojects within SIG Release. And each subproject has a team of roles, and each role can have two to four shadows that are basically people who are part of that role team, and they are learning that role as they are doing it. + +So for example, if I am the lead for bug triage on the release team, I may have two, three or four people that I closely work with on the bug triage tasks. These people are my shadows. And once they have served one release cycle as a shadow, they are now eligible to be lead in that role. We have an application form for this process, and it should probably be going up in January. It usually happens the first week of the release once all the release leads are put together. + +**CRAIG BOX: Do you think being a member of the release team is something that is a good first contribution to the Kubernetes project overall?** + +GUINEVERE SAENGER: It depends on what your goals are, right? I believe so. I believe, for me, personally, it has been incredibly helpful looking into corners of the project that I don't know very much about at all, like API machinery, storage. It's been really exciting to look over all the areas of code that I normally never touch. + +It depends on what you want to get out of it. In general, I think that being a release team shadow is a really, really great on-ramp to being a part of the community because it has a paved path solution to contributing. All you have to do is show up to the meetings, ask questions of your lead, who is required to answer those questions. + +And you also do real work. You really help, you really contribute. If you go across the issues and pull requests in the repo, you will see, 'Hi, my name is so-and-so. I am shadowing the CI signal lead for the current release. Can you help me out here?' And that's a valuable contribution, and it introduces people to others. And then people will recognize your name. They'll see a pull request by you, and they're like oh yeah, I know this person. They're legit. + +--- + +_[Guinevere Saenger](https://twitter.com/guincodes) is a software engineer for GitHub and served as the Kubernetes 1.17 release team lead._ + +_You can find the [Kubernetes Podcast from Google](http://www.kubernetespodcast.com/) at [@KubernetesPod](https://twitter.com/KubernetesPod) on Twitter, and you can [subscribe](https://kubernetespodcast.com/subscribe/) so you never miss an episode._ diff --git a/content/en/blog/_posts/2020-08-03-kubernetes-1-18-release-interview.md b/content/en/blog/_posts/2020-08-03-kubernetes-1-18-release-interview.md new file mode 100644 index 0000000000..a8e4e71736 --- /dev/null +++ b/content/en/blog/_posts/2020-08-03-kubernetes-1-18-release-interview.md @@ -0,0 +1,215 @@ +--- +layout: blog +title: "Physics, politics and Pull Requests: the Kubernetes 1.18 release interview" +date: 2020-08-03 +--- + +**Author**: Craig Box (Google) + +The start of the COVID-19 pandemic couldn't delay the release of Kubernetes 1.18, but unfortunately [a small bug](https://github.com/kubernetes/utils/issues/141) could — thankfully only by a day. This was the last cat that needed to be herded by 1.18 release lead [Jorge Alarcón](https://twitter.com/alejandrox135) before the [release on March 25](https://kubernetes.io/blog/2020/03/25/kubernetes-1-18-release-announcement/). + +One of the best parts about co-hosting the weekly [Kubernetes Podcast from Google](https://kubernetespodcast.com/) is the conversations we have with the people who help bring Kubernetes releases together. [Jorge was our guest on episode 96](https://kubernetespodcast.com/episode/096-kubernetes-1.18/) back in March, and [just like last week](https://kubernetes.io/blog/2020/07/27/music-and-math-the-kubernetes-1.17-release-interview/) we are delighted to bring you the transcript of this interview. + +If you'd rather enjoy the "audiobook version", including another interview when 1.19 is released later this month, [subscribe to the show](https://kubernetespodcast.com/subscribe/) wherever you get your podcasts. + +In the last few weeks, we've talked to long-time Kubernetes contributors and SIG leads [David Oppenheimer](https://kubernetespodcast.com/episode/114-scheduling/), [David Ashpole](https://kubernetespodcast.com/episode/113-instrumentation-and-cadvisor/) and [Wojciech Tyczynski](https://kubernetespodcast.com/episode/111-scalability/). All are worth taking the dog for a longer walk to listen to! + +--- + +**ADAM GLICK: You're a former physicist. I have to ask, what kind of physics did you work on?** + +JORGE ALARCÓN: Back in my days of math and all that, I used to work in [computational biology](https://en.wikipedia.org/wiki/Computational_biology) and a little bit of high energy physics. Computational biology was, for the most part, what I spent most of my time on. And it was essentially exploring the big idea of we have the structure of proteins. We know what they're made of. Now, based on that structure, we want to be able to predict [how they're going to fold](https://en.wikipedia.org/wiki/Protein_folding) and how they're going to behave, which essentially translates into the whole idea of designing pharmaceuticals, designing vaccines, or anything that you can possibly think of that has any connection whatsoever to a living organism. + +**ADAM GLICK: That would seem to ladder itself well into maybe going to something like bioinformatics. Did you take a tour into that, or did you decide to go elsewhere directly?** + +JORGE ALARCÓN: It is related, and I worked a little bit with some people that did focus on bioinformatics on the field specifically, but I never took a detour into it. Really, my big idea with computational biology, to be honest, it wasn't even the biology. That's usually what sells it, what people are really interested in, because protein engineering, all the cool and amazing things that you can do. + +Which is definitely good, and I don't want to take away from it. But my big thing is because biology is such a real thing, it is amazingly complicated. And the math— the models that you have to design to study those systems, to be able to predict something that people can actually experiment and measure, it just captivated me. The level of complexity, the beauty, the mechanisms, all the structures that you see once you got through the math and look at things, it just kind of got to me. + +**ADAM GLICK: How did you go from that world into the world of Kubernetes?** + +JORGE ALARCÓN: That's both a really boring story and an interesting one. + +[LAUGHING] + +I did my thing with physics, and it was good. It was fun. But at some point, I wanted— working in academia— at least my feeling for it is that generally all the people that you're surrounded with are usually academics. Just another bunch of physics, a bunch of mathematicians. + +But very seldom do you actually get the opportunity to take what you're working on and give it to someone else to use. Even with the mathematicians and physicists, the things that we're working on are super specialized, and you can probably find three, four, five people that can actually understand everything that you're saying. A lot of people are going to get the gist of it, but understanding the details, it's somewhat rare. + +One of the things that I absolutely love about tech, about software engineering, coding, all that, is how open and transparent everything is. You can write your library in Python, you can publish it, and suddenly the world is going to actually use it, actually consume it. And because normally, I've seen that it has a large avenue where you can work in something really complicated, you can communicate it, and people can actually go ahead and take it and run with it in their given direction. And that is kind of what happened. + +At some point, by pure accident and chance, I came across this group of people on the internet, and they were in the stages of making up this new group that's called [Data for Democracy](https://datafordemocracy.org/), a non-profit. And the whole idea was the internet, especially Twitter— that's how we congregated— Twitter, the internet. We have a ton of data scientists, people who work as software engineers, and the like. What if we all come together and try to solve some issues that actually affect the daily lives of people. And there were a ton of projects. Helping the ACLU gather data for something interesting that they were doing, gather data and analyze it for local governments— where do you have potholes, how much water is being consumed. + +Try to apply all the science that we knew, combined with all the code that we could write, and offer a good and digestible idea for people to say, OK, this makes sense, let's do something about it— policy, action, whatever. And I started working with this group, Data for Democracy— wonderful set of people. And the person who I believe we can blame for Data for Democracy— the one who got the idea and got it up and running, his name is Jonathan Morgan. And eventually, we got to work together. He started a startup, and I went to work with the startup. And that was essentially the thing that took me away from physics and into the world of software engineering— Data for Democracy, definitely. + +**ADAM GLICK: Were you using Kubernetes as part of that work there?** + +JORGE ALARCÓN: No, it was simple as it gets. You just try to get some data. You create a couple [IPython notebooks](https://ipython.org/), some setting up of really simple MySQL databases, and that was it. + +**ADAM GLICK: Where did you get started using Kubernetes? And was it before you started contributing to it and being a part, or did you decide to jump right in?** + +JORGE ALARCÓN: When I first started using Kubernetes, it was also on my first job. So there wasn't a lot of specific training in regards to software engineering or anything of the sort that I did before I actually started working as a software engineer. I just went from physicist to engineer. And in my days of physics, at least on the computer side, I was completely trained in the super old school system administrator, where you have your 10, 20 computers. You know physically where they are, and you have to connect the cables. + +**ADAM GLICK: All pets— all pets all the time.** + +JORGE ALARCÓN: [LAUGHING] You have to have your huge Python, bash scripts, three, five major versions, all because doing an upgrade will break something really important and you have no idea how to work on it. And that was my training. That was the way that I learned how to do things. Those were the kind of things that I knew how to do. + +And when I got to this company— startup— we were pretty much starting from scratch. We were building a couple applications. We work testing them, we were deploying them on a couple of managed instances. But like everything, there was a lot of toil that we wanted to automate. The whole issue of, OK, after days of work, we finally managed to get this version of the application up and running in these machines. + +It's open to the internet. People can test it out. But it turns out that it is now two weeks behind the latest on all the master branches for this repo, so now we want to update. And we have to go through the process of bringing it back up, creating new machines, do that whole thing. And I had no idea what Kubernetes was, to be honest. My boss at the moment mentioned it to me like, hey, we should use Kubernetes because apparently, Kubernetes is something that might be able to help us here. And we did some— I want to call it research and development. + +It was actually just making— again, startup, small company, small team, so really me just playing around with Kubernetes trying to get it to work, trying to get it to run. I was so lost. I had no idea what I was doing— not enough. I didn't have an idea of how Kubernetes was supposed to help me. And at that point, I did the best Googling that I could manage. Didn't really find a lot of examples. Didn't find a lot of blog posts. It was early. + +**ADAM GLICK: What time frame was this?** + +JORGE ALARCÓN: Three, four years ago, so definitely not 1.13. That's the best guesstimate that I can give at this point. But I wasn't able to find any good examples, any tutorials. The only book that I was able to get my hands on was the one written by Joe Beda, Kelsey Hightower, and I forget the other author. But what is it? "[Kubernetes— Up and Running](](http://shop.oreilly.com/product/0636920223788.do))"? + +And in general, right now I use it as reference— it's really good. But as a beginner, I still was lost. They give all these amazing examples, they provide the applications, but I had no idea why someone might need a Pod, why someone might need a Deployment. So my last resort was to try and find someone who actually knew Kubernetes. + +By accident, during my eternal Googling, I actually found a link to the [Kubernetes Slack](http://slack.kubernetes.io/). I jumped into the Kubernetes Slack hoping that someone might be able to help me out. And that was my entry point into the Kubernetes community. I just kept on exploring the Slack, tried to see what people were talking about, what they were asking to try to make sense of it, and just kept on iterating. And at some point, I think I got the hang of it. + +**ADAM GLICK: What made you decide to be a release lead?** + +JORGE ALARCÓN: The answer to this is my answer to why I have been contributing to Kubernetes. I really just want to be able to help out the community. Kubernetes is something that I absolutely adore. + +Comparing Kubernetes to old school system administration, a handful of years ago, it took me like a week to create a node for an application to run. It took me months to get something that vaguely looked like an Ingress resource— just setting up the Nginx, and allowing someone else to actually use my application. And the fact that I could do all of that in five minutes, it really captivated me. Plus I've got to blame it on the physics. The whole idea with physics, I really like the patterns, and I really like the design of Kubernetes. + +Once I actually got the hang of it, I loved the idea of how everything was designed, and I just wanted to learn a lot more about it. And I wanted to help the contributors. I wanted to help the people who actually build it. I wanted to help maintain it, and help provide the information for new contributors or new users. So instead of taking months for them to be up and running, let's just chat about what your issue is, and let's try to get a fix within the next hour or so. + +**ADAM GLICK: You work for a stealth startup right now. Is it fair to assume that they're using Kubernetes?** + +JORGE ALARCÓN: Yes— + +[LAUGHING] + +—for everything. + +**ADAM GLICK: Are you able to say what [Searchable](https://www.searchable.ai/) does?** + +JORGE ALARCÓN: The thing that we are trying to build is kind of like a search engine for your documents. Usually, if people have a question, they jump on Google. And for the most part, you're going to be able to get a good answer. You can ask something really random, like 'what is the weight of an elephant?' + +Which, if you think about it, it's kind of random, but Google is going to give you an answer. And the thing that we are trying to build is something similar to that, but for files. So essentially, a search engine for your files. And most people, you have your local machine loaded up with— at least mine, I have a couple tens of gigabytes of different files. + +I have Google Drive. I have a lot of documents that live in my email and the like. So the idea is to kind of build a search engine that is going to be able to connect all of those pieces. And besides doing simple word searches— for example, 'Kubernetes interview', and bring me the documents that we're looking at with all the questions— I can also ask things like what issue did I find last week while testing Prometheus. And it's going to be able to read my files, like through natural language processing, understand it, and be able to give me an answer. + +**ADAM GLICK: It is a Google for your personal and non-public information, essentially?** + +JORGE ALARCÓN: Hopefully. + +**ADAM GLICK: Is the work that you do with Kubernetes as the release lead— is that part of your day job, or is that something that you're doing kind of nights and weekends separate from your day job?** + +JORGE ALARCÓN: Both. Strictly speaking, my day job is just keep working on the application, build the things that it needs, maintain the infrastructure, and all that. When I started working at the company— which by the way, the person who brought me into the company was also someone that I met from my days in Data for Democracy— we started talking about the work. + +I mentioned that I do a lot of work with the Kubernetes community and if it was OK that I continue doing it. And to my surprise, the answer was not only a yes, but yeah, you can do it during your day work. And at least for the time being, I just balance— I try to keep things organized. + +Some days I just focus on Kubernetes. Some mornings I do Kubernetes. And then afternoon, I do Searchable, vice-versa, or just go back and forth, and try to balance the work as much as possible. But being release lead, definitely, it is a lot, so nights and weekends. + +**ADAM GLICK: How much time does it take to be the release lead?** + +JORGE ALARCÓN: It varies, but probably, if I had to give an estimate, at the very least you have to be able to dedicate four hours most days. + +**ADAM GLICK: Four hours a day?** + +JORGE ALARCÓN: Yeah, most days. It varies a lot. For example, at the beginning of the release cycle, you don't need to put in that much work because essentially, you're just waiting and helping people get set up, and people are writing their [Kubernetes Enhancement Proposals](https://github.com/kubernetes/enhancements/tree/master/keps), they are implementing it, and you can answer some questions. It's relatively easy, but for the most part, a lot of the time the four hours go into talking with people, just making sure that, hey, are people actually writing their enhancements, do we have all the enhancements that we want. And most of those fours hours, going around, chatting with people, and making sure that things are being done. And if, for some reason, someone needs help, just directing them to the right place to get their answer. + +**ADAM GLICK: What does Searchable get out of you doing this work?** + +JORGE ALARCÓN: Physically, nothing. The thing that we're striving for is to give back to the community. My manager/boss/homeslice— I told him I was going to call him my homeslice— both of us have experience working in open source. At some point, he was also working on a project that I'm probably going to mispronounce, but Mahout with Apache. + +And he also has had this experience. And both of us have this general idea and strive to build something for Searchable that's going to be useful for people, but also build knowledge, build guides, build applications that are going to be useful for the community. And at least one of the things that I was able to do right now is be the lead for the Kubernetes team. And this is a way of giving back to the community. We're using Kubernetes to run our things, so let's try to balance how things work. + +**ADAM GLICK: Lachlan Evenson was the release lead on 1.16 as well as [our guest back in episode 72](https://kubernetespodcast.com/episode/072-kubernetes-1.16/), and he's returned on this release as the [emeritus advisor](https://github.com/kubernetes/sig-release/tree/master/release-team/role-handbooks/emeritus-adviser). What did you learn from him?** + +JORGE ALARCÓN: Oh, everything. And it actually all started back on 1.16. So like you said, an amazing person— he's an amazing individual. And it's truly an opportunity to be able to work with him. During 1.16, I was the CI Signal lead, and Lachie is very hands on. + +He's not the kind of person to just give you a list of things and say, do them. He actually comes to you, has a conversation, and he works with you more than anything. And when we were working together on 1.16, I got to learn a lot from him in terms of CI Signal. And especially because we talked about everything just to make sure that 1.16 was ready to go, I also got to pick up a couple of things that a release lead has to know, has to be able to do, has to work on to get a release out the door. + +And now, during this release, there is a lot of information that's really useful, and there's a lot of advice and general wisdom that comes in handy. For most of the things that impact a lot of things, we are always in communication. Like, I'm doing this, you're doing that, advice. And essentially, every single thing that we do is pretty much a code review. You do it, and then you wait for someone else to give you comments. And that's been a strong part of our relationship working. + +**ADAM GLICK: What would you say the theme for this release is?** + +JORGE ALARCÓN: I think one of the themes is "fit and finish". There are a lot of features that we are bumping from alpha to beta, from beta to stable. And we want to make sure that people have a good user experience. Operators and developers alike just want to get rid of as many bugs as possible, improve the flow of things. + +But the other really cool thing is we have about an equal distribution between alpha, beta, and stable. We are also bringing up a lot of new features. So besides making Kubernetes more stable for all the users that are already using it, we are working on bringing up new things that people can try out for the next release and see how it goes in the future. + +**ADAM GLICK: Did you have a release team mascot?** + +JORGE ALARCÓN: Kind of. + +**ADAM GLICK: Who/what was it?** + +JORGE ALARCÓN: [LAUGHING] I say kind of because I'm using the mascot in the [logo](https://twitter.com/KubernetesPod/status/1242953121380392963), and the logo is inspired by the Large Hadron Collider. + +**ADAM GLICK: Oh, fantastic.** + +JORGE ALARCÓN: Being the release lead, I really had to take a chance on this opportunity to use the LHC as the mascot. + +**ADAM GLICK: We've had [some of the folks from the LHC on the show](https://kubernetespodcast.com/episode/062-cern/), and I know they listen, and they will be thrilled with that.** + +JORGE ALARCÓN: [LAUGHING] Hopefully, they like the logo. + +**ADAM GLICK: If you look at this release, what part of this release, what thing that has been added to it are you personally most excited about?** + +JORGE ALARCÓN: Like a parent can't choose which child is his or her favorite, you really can't choose a specific thing. + +**ADAM GLICK: We have been following online and in the issues an enhancement that's called [sidecar containers](https://github.com/kubernetes/enhancements/issues/753). You'd be able to mark the order of containers starting in a pod. Tim Hockin posted [a long comment on behalf of a number of SIG Node contributors](https://github.com/kubernetes/enhancements/issues/753#issuecomment-597372056) citing social, procedural, and technical concerns about what's going on with that— in particular, that it moved out of 1.18 and is now moving to 1.19. Did you have any thoughts on that?** + +JORGE ALARCÓN: The sidecar enhancement has definitely been an interesting one. First off, thank you very much to Joseph Irving, the author of the KEP. And thank you very much to Tim Hockin, who voiced out the point of view of the approvers, maintainers of SIG Node. And I guess a little bit of context before we move on is, in the Kubernetes community, we have contributors, we have reviewers, and we have approvers. + +Contributors are people who write PRs, who file issues, who troubleshoot issues. Reviewers are contributors who focus on one or multiple specific areas within the project, and then approvers are maintainers for the specific area, for one or multiple specific areas, of the project. So you can think of approvers as people who have write access in a repo or someplace within a repo. + +The issue with the sidecar enhancement is that it has been deferred for multiple releases now, and that's been because there hasn't been a lot of collaboration between the KEP authors and the approvers for specific parts of the project. Something worthwhile to mention— and this was brought up during the original discussion— is this can obviously be frustrating for both contributors and for approvers. From the contributor's side of things, you are working on something. You are doing your best to make sure that it works. + +And to build something that's going to be used by people, both from the approver side of things and, I think, for the most part, every single person in the Kubernetes community, we are all really excited to see this project grow. We want to help improve it, and we love when new people come in and work on new enhancements, bug fixes, and the like. + +But one of the limitations is the day only has so many hours, and there are only so many things that we can work on at a time. So people prioritize in whatever way works best, and some things just fall behind. And a lot of the time, the things that fall behind are not because people don't want them to continue moving forward, but it's just a limited amount of resources, a limited amount of people. + +And I think this discussion around the sidecar enhancement proposal has been very useful, and it points us to the need for more standardized mentoring programs. This is something that multiple SIGs are working on. For example, SIG Contribex, SIG Cluster Lifecycle, SIG Release. The idea is to standardize some sort of mentoring experience so that we can better prepare new contributors to become reviewers and ultimately approvers. + +Because ultimately at the end of the day, if we have more people who are knowledgeable about Kubernetes, or even some specific area of Kubernetes, we can better distribute the load, and we can better collaborate on whatever new things come up. I think the sidecar enhancement has shown us mentoring is something worthwhile, and we need a lot more of it. Because as much work as we do, more things are going to continue popping in throughout the project. And the more people we have who are comfortable working in these really complicated areas of Kubernetes, the better off that we are going to be. + +**ADAM GLICK: Was there any talk of delaying 1.18 due to the current worldwide health situation?** + +JORGE ALARCÓN: We thought about it, and the plan was to just wait and see how people felt. Tried make sure that people were comfortable continuing to work and all the people were landing in new enhancements, or fixing tests, or members of the release team who were making sure that things were happening. We wanted to see that people were comfortable, that they could continue doing their job. And for a moment, I actually thought about delaying just outright— we're going to give it more time, and hopefully at some point, things are going to work out. + +But people just continue doing their amazing work. There was no delay. There was no hitch throughout the process. So at some point, I just figured we stay with the current timeline and see how we went. And at this point, things are more or less set. + +**ADAM GLICK: Amazing power of a distributed team.** + +JORGE ALARCÓN: Yeah, definitely. + +[LAUGHING] + +**ADAM GLICK: [Taylor Dolezal was announced as the 1.19 release lead](https://twitter.com/alejandrox135/status/1239629281766096898). Do you know how that choice was made, and by whom?** + +JORGE ALARCÓN: I actually got to choose the lead. The practice is the current lead for the release team is going to look at people and see, first off, who's interested and out of the people interested, who can do the job, who's comfortable enough with the release team, with the Kubernetes community at large who can actually commit the amount of hours throughout the next, hopefully, three months. + +And for one, I think Taylor has been part of my team. So there is the release team. Then the release team has multiple subgroups. One of those subgroups is actually just for me and my shadows. So for this release, it was mrbobbytables and Taylor. And Taylor volunteered to take over 1.19, and I'm sure that he will do an amazing job. + +**ADAM GLICK: I am as well. What advice will you give Taylor?** + +JORGE ALARCÓN: Over-communicate as much as possible. Normally, if you made it to the point that you are the lead for a release, or even the shadow for a release, you more or less are familiar with a lot of the work— CI Signal, enhancements, documentation, and the like. And a lot of people, if they know how to do their job, they might tell themselves, yeah, I could do it— no need to worry about it. I'm just going to go ahead and sign this PR, debug this test, whatever. + +But one of the interesting aspects is whenever we are actually working in a release, 50% of the work has to go into actually making the release happen. The other 50% of the work has to go into mentoring people, and making sure the newcomers, new members are able to learn everything that they need to learn to do your job, you being in the lead for a subgroup or the entire team. And whenever you actually see that things need to happen, just over-communicate. + +Try to provide the opportunity for someone else to do the work, and over-communicate with them as much as possible to make sure that they are learning whatever it is that they need to learn. If neither you or the other person knows what's going on, then I can over-communicate, so someone hopefully will see your messages and come to the rescue. That happens a lot. There's a lot of really nice and kind people who will come out and tell you how something works, help you fix it. + +**ADAM GLICK: If you were to sum up your experience running this release, what would it be?** + +JORGE ALARCÓN: It's been super fun and a little bit stressing, to be honest. Being the release lead is definitely amazing. You're kind of sitting at the center of Kubernetes. + +You not only see the people who are working on things— the things that are broken, and the users filling out issues, and saying what broke, and the like. But you also get the opportunity to work with a lot of people who do a lot of non-code related work. Docs is one of the most obvious things. There's a lot of work that goes into communications, contributor experience, public relations. + +And being connected, getting to talk with those people mostly every other day, it's really fun. It's a really good experience in terms of becoming a better contributor to the community, but also taking some of that knowledge home with you and applying it somewhere else. If you are a software engineer, if you are a project manager, whatever, it's amazing how much you can learn. + +**ADAM GLICK: I know the community likes to rotate around who are the release leads. But if you were given the opportunity to be a release lead for a future release of Kubernetes, would you do it again?** + +JORGE ALARCÓN: Yeah, it's a fun job. To be honest, it can be really stressing. Especially, as I mentioned, at some point, most of that work is just going to be talking with people, and talking requires a lot more thought and effort than just sitting down and thinking about things sometimes. And some of that can be really stressful. + +But the job itself, it is definitely fun. And at some distant point in the future, if for some reason it was a possibility, I will think about it. But definitely, as you mentioned, one thing that we try to do is cycle out, because I can have fun in it, and that's all good and nice. And hopefully I can help another release go out the door. But providing the opportunity for other people to learn I think is a lot more important than just being the lead itself. + +--- + +_[Jorge Alarcón](https://twitter.com/alejandrox135) is a site reliability engineer with Searchable AI and served as the Kubernetes 1.18 release team lead._ + +_You can find the [Kubernetes Podcast from Google](http://www.kubernetespodcast.com/) at [@KubernetesPod](https://twitter.com/KubernetesPod) on Twitter, and you can [subscribe](https://kubernetespodcast.com/subscribe/) so you never miss an episode._ \ No newline at end of file diff --git a/content/en/case-studies/OWNERS b/content/en/case-studies/OWNERS deleted file mode 100644 index e4131d339e..0000000000 --- a/content/en/case-studies/OWNERS +++ /dev/null @@ -1,10 +0,0 @@ -# See the OWNERS docs at https://go.k8s.io/owners - -# Owned by Kubernetes Blog reviewers. -options: - no_parent_owners: false -reviewers: - - alexcontini -approvers: - - alexcontini - - sarahkconway diff --git a/content/en/case-studies/adform/index.html b/content/en/case-studies/adform/index.html index e9a8acc7a2..be35a2d837 100644 --- a/content/en/case-studies/adform/index.html +++ b/content/en/case-studies/adform/index.html @@ -12,7 +12,7 @@ quote: > Kubernetes enabled the self-healing and immutable infrastructure. We can do faster releases, so our developers are really happy. They can ship our features faster than before, and that makes our clients happier. --- -
+

CASE STUDY:
Improving Performance and Morale with Cloud Native

@@ -66,7 +66,7 @@ The company has a large infrastructure: Ope
-
+
"The fact that Cloud Native Computing Foundation incubated Kubernetes was a really big point for us because it was vendor neutral. And we can see that a community really gathers around it. Everyone shares their experiences, their knowledge, and the fact that it’s open source, you can contribute."

— Edgaras Apšega, IT Systems Engineer, Adform
@@ -83,7 +83,7 @@ The first production cluster was launched in the spring of 2018, and is now up t
-
+
"Releases are really nice for them, because they just push their code to Git and that’s it. They don’t have to worry about their virtual machines anymore."

— Andrius Cibulskis, IT Systems Engineer, Adform
diff --git a/content/en/case-studies/adidas/index.html b/content/en/case-studies/adidas/index.html index 3f7982765a..5f9d0da24a 100644 --- a/content/en/case-studies/adidas/index.html +++ b/content/en/case-studies/adidas/index.html @@ -9,7 +9,7 @@ featured: false ​ -
+

CASE STUDY: adidas

Staying True to Its Culture, adidas Got 40% of Its Most Impactful Systems Running on Kubernetes in a Year
@@ -33,7 +33,7 @@ featured: false
-
+
"For me, Kubernetes is a platform made by engineers for engineers. It’s relieving the development team from tasks that they don’t want to do, but at the same time giving the visibility of what is behind the curtain, so they can also control it."

- FERNANDO CORNAGO, SENIOR DIRECTOR OF PLATFORM ENGINEERING AT ADIDAS

@@ -74,7 +74,7 @@ featured: false ​ ​ -
+
“There is no competitive edge over our competitors like Puma or Nike in running and operating a Kubernetes cluster. Our competitive edge is that we teach our internal engineers how to build cool e-comm stores that are fast, that are resilient, that are running perfectly.”

- DANIEL EICHTEN, SENIOR DIRECTOR OF PLATFORM ENGINEERING AT ADIDAS

diff --git a/content/en/case-studies/ant-financial/index.html b/content/en/case-studies/ant-financial/index.html index 92b46526de..1711ef97b8 100644 --- a/content/en/case-studies/ant-financial/index.html +++ b/content/en/case-studies/ant-financial/index.html @@ -7,7 +7,7 @@ css: /css/style_case_studies.css featured: false --- -
+

CASE STUDY:
Ant Financial’s Hypergrowth Strategy Using Kubernetes

@@ -50,7 +50,7 @@ featured: false To address those challenges and provide reliable and consistent services to its customers, Ant Financial embraced Docker containerization in 2014. But they soon realized that they needed an orchestration solution for some tens-of-thousands-of-node clusters in the company’s data centers.
-
+
"On Double 11 this year, we had plenty of nodes on Kubernetes, but compared to the whole scale of our infrastructure, this is still in progress."

- RANGER YU, GLOBAL TECHNOLOGY PARTNERSHIP & DEVELOPMENT, ANT FINANCIAL @@ -65,7 +65,7 @@ featured: false All core financial systems were containerized by November 2017, and the migration to Kubernetes is ongoing. Ant’s platform also leverages a number of other CNCF projects, including Prometheus, OpenTracing, etcd and CoreDNS. “On Double 11 this year, we had plenty of nodes on Kubernetes, but compared to the whole scale of our infrastructure, this is still in progress,” says Ranger Yu, Global Technology Partnership & Development.
-
+
"We’re very grateful for CNCF and this amazing technology, which we need as we continue to scale globally. We’re definitely embracing the community and open source more in the future."

- HAOJIE HANG, PRODUCT MANAGEMENT, ANT FINANCIAL
diff --git a/content/en/case-studies/appdirect/index.html b/content/en/case-studies/appdirect/index.html index 16d93cce5c..ca6b0b8fe9 100644 --- a/content/en/case-studies/appdirect/index.html +++ b/content/en/case-studies/appdirect/index.html @@ -12,7 +12,7 @@ quote: > We made the right decisions at the right time. Kubernetes and the cloud native technologies are now seen as the de facto ecosystem. --- -
+

CASE STUDY:
AppDirect: How AppDirect Supported the 10x Growth of Its Engineering Staff with Kubernetess

@@ -53,7 +53,7 @@ quote: >
-
+
"We made the right decisions at the right time. Kubernetes and the cloud native technologies are now seen as the de facto ecosystem. We know where to focus our efforts in order to tackle the new wave of challenges we face as we scale out. The community is so active and vibrant, which is a great complement to our awesome internal team."

- Alexandre Gervais, Staff Software Developer, AppDirect @@ -69,7 +69,7 @@ quote: > Lacerte’s strategy ultimately worked because of the very real impact the Kubernetes platform has had to deployment time. Due to less dependency on custom-made, brittle shell scripts with SCP commands, time to deploy a new version has shrunk from 4 hours to a few minutes. Additionally, the company invested a lot of effort to make things self-service for developers. "Onboarding a new service doesn’t require Jira tickets or meeting with three different teams," says Lacerte. Today, the company sees 1,600 deployments per week, compared to 1-30 before.
-
+
"I think our velocity would have slowed down a lot if we didn’t have this new infrastructure."

- Pierre-Alexandre Lacerte, Director of Software Development, AppDirect
diff --git a/content/en/case-studies/babylon/index.html b/content/en/case-studies/babylon/index.html index afdc005411..dce0612175 100644 --- a/content/en/case-studies/babylon/index.html +++ b/content/en/case-studies/babylon/index.html @@ -12,7 +12,7 @@ quote: > --- -
+

CASE STUDY: Babylon

How Cloud Native Is Enabling Babylon’s Medical AI Innovations
@@ -36,7 +36,7 @@ quote: > Instead of waiting hours or days to be able to compute, teams can get access instantaneously. Clinical validations used to take 10 hours; now they are done in under 20 minutes. The portability of the cloud native platform has also enabled Babylon to expand into other countries.
-
+
“Kubernetes is a great platform for machine learning because it comes with all the scheduling and scalability that you need.”

- JÉRÉMIE VALLÉE, AI INFRASTRUCTURE LEAD AT BABYLON

@@ -84,7 +84,7 @@ quote: > -
+
“Giving a Kubernetes-based platform to our data scientists has meant increased security, increased innovation through empowerment, and a more affordable health service as our cloud engineers are building an experience that is used by hundreds on a daily basis, rather than supporting specific bespoke use cases.”

- JEAN MARIE FERDEGUE, DIRECTOR OF PLATFORM OPERATIONS AT BABYLON

diff --git a/content/en/case-studies/booking-com/index.html b/content/en/case-studies/booking-com/index.html index ffeb3f2707..99369a2bf9 100644 --- a/content/en/case-studies/booking-com/index.html +++ b/content/en/case-studies/booking-com/index.html @@ -14,7 +14,7 @@ quote: > ​ -
+

CASE STUDY: Booking.com

After Learning the Ropes with a Kubernetes Distribution, Booking.com Built a Platform of Its Own
@@ -40,7 +40,7 @@ quote: >
-
+
“As our users learn Kubernetes and become more sophisticated Kubernetes users, they put pressure on us to provide a better, more native Kubernetes experience, which is great. It’s a super healthy dynamic.”

- BEN TYLER, PRINCIPAL DEVELOPER, B PLATFORM TRACK AT BOOKING.COM

@@ -91,7 +91,7 @@ quote: > ​ ​ -
+
“We have a tutorial. You follow the tutorial. Your code is running. Then, it’s business-logic time. The time to gain access to resources is decreased enormously.”

- BEN TYLER, PRINCIPAL DEVELOPER, B PLATFORM TRACK AT BOOKING.COM

diff --git a/content/en/case-studies/booz-allen/index.html b/content/en/case-studies/booz-allen/index.html index 2a48c7f3b7..fdda5e976a 100644 --- a/content/en/case-studies/booz-allen/index.html +++ b/content/en/case-studies/booz-allen/index.html @@ -13,7 +13,7 @@ quote: > ​ -
+

CASE STUDY: Booz Allen Hamilton

How Booz Allen Hamilton Is Helping Modernize the Federal Government with Kubernetes
@@ -38,7 +38,7 @@ quote: >
-
+
"When there’s a regulatory change in an agency, or a legislative change in Congress, or an executive order that changes the way you do business, how do I deploy that and get that out to the people who need it rapidly? At the end of the day, that’s the problem we’re trying to help the government solve with tools like Kubernetes."

- JOSH BOYD, CHIEF TECHNOLOGIST AT BOOZ ALLEN HAMILTON

@@ -75,7 +75,7 @@ quote: > ​ ​ -
+
"Kubernetes alone enables a dramatic reduction in cost as resources are prioritized to the day’s event"

- MARTIN FOLKOFF, SENIOR LEAD TECHNOLOGIST AT BOOZ ALLEN HAMILTON

diff --git a/content/en/case-studies/bose/index.html b/content/en/case-studies/bose/index.html index d22de2187a..c77f416c13 100644 --- a/content/en/case-studies/bose/index.html +++ b/content/en/case-studies/bose/index.html @@ -11,7 +11,7 @@ quote: > The CNCF Landscape quickly explains what’s going on in all the different areas from storage to cloud providers to automation and so forth. This is our shopping cart to build a cloud infrastructure. We can go choose from the different aisles. --- -
+

CASE STUDY:
Bose: Supporting Rapid Development for Millions of IoT Products With Kubernetes

@@ -56,7 +56,7 @@ From the beginning, the team knew it wanted a microservices architecture and pla
-
+
"Everybody on the team thinks in terms of automation, leaning out the processes, getting things done as quickly as possible. When you step back and look at what it means for a 50-plus-year-old speaker company to have that sort of culture, it really is quite incredible, and I think the tools that we use and the foundation that we’ve built with them is a huge piece of that."

- Dylan O’Mahony, Cloud Architecture Manager, Bose @@ -70,7 +70,7 @@ From the beginning, the team knew it wanted a microservices architecture and pla
-
+
"The CNCF Landscape quickly explains what’s going on in all the different areas from storage to cloud providers to automation and so forth. This is our shopping cart to build a cloud infrastructure. We can go choose from the different aisles."

- Josh West, Lead Cloud Engineer, Bose
diff --git a/content/en/case-studies/capital-one/index.html b/content/en/case-studies/capital-one/index.html index 773db4869e..f95fb2acc7 100644 --- a/content/en/case-studies/capital-one/index.html +++ b/content/en/case-studies/capital-one/index.html @@ -5,7 +5,7 @@ cid: caseStudies css: /css/style_case_studies.css --- -
+

CASE STUDY:
Supporting Fast Decisioning Applications with Kubernetes

@@ -55,7 +55,7 @@ css: /css/style_case_studies.css
-
+
"We want to provide the tools in the same ecosystem, in a consistent way, rather than have a large custom snowflake ecosystem where every tool needs its own custom deployment. Kubernetes gives us the ability to bring all of these together, so the richness of the open source and even the license community dealing with big data can be corralled." @@ -69,7 +69,7 @@ css: /css/style_case_studies.css
-
+
With Kubernetes, "a team can come to us and we can have them up and running with a basic decisioning app in a fortnight, which before would have taken a whole quarter, if not longer. Kubernetes is a manifold productivity multiplier."
diff --git a/content/en/case-studies/cern/index.html b/content/en/case-studies/cern/index.html index 9bd7970245..48e965d7fb 100644 --- a/content/en/case-studies/cern/index.html +++ b/content/en/case-studies/cern/index.html @@ -7,7 +7,7 @@ css: /css/style_case_studies.css logo: cern_featured_logo.png --- -
+

CASE STUDY: CERN
CERN: Processing Petabytes of Data More Efficiently with Kubernetes

@@ -52,7 +52,7 @@ logo: cern_featured_logo.png
-
+
"Before, the tendency was always: ‘I need this, I get a couple of developers, and I implement it.’ Right now it’s ‘I need this, I’m sure other people also need this, so I’ll go and ask around.’ The CNCF is a good source because there’s a very large catalog of applications available. It’s very hard right now to justify developing a new product in-house. There is really no real reason to keep doing that. It’s much easier for us to try it out, and if we see it’s a good solution, we try to reach out to the community and start working with that community."

- Ricardo Rocha, Software Engineer, CERN @@ -66,7 +66,7 @@ logo: cern_featured_logo.png
-
+
"With Kubernetes, there’s a well-established technology and a big community that we can contribute to. It allows us to do our physics analysis without having to focus so much on the lower level software. This is just exciting. We are looking forward to keep contributing to the community and collaborating with everyone."

- Ricardo Rocha, Software Engineer, CERN
diff --git a/content/en/case-studies/chinaunicom/index.html b/content/en/case-studies/chinaunicom/index.html index 296b2ce1fc..4479d60e67 100644 --- a/content/en/case-studies/chinaunicom/index.html +++ b/content/en/case-studies/chinaunicom/index.html @@ -8,7 +8,7 @@ css: /css/style_case_studies.css featured: false --- -
+

CASE STUDY:
China Unicom: How China Unicom Leveraged Kubernetes to Boost Efficiency
and Lower IT Costs

@@ -51,7 +51,7 @@ featured: false
-
+
"We could never imagine we can achieve this scalability in such a short time."

- Chengyu Zhang, Group Leader of Platform Technology R&D, China Unicom @@ -65,7 +65,7 @@ featured: false
-
+
"This technology is relatively complicated, but as long as developers get used to it, they can enjoy all the benefits."

- Jie Jia, Member of Platform Technology R&D, China Unicom
diff --git a/content/en/case-studies/city-of-montreal/index.html b/content/en/case-studies/city-of-montreal/index.html index 151ce44b21..55378c649e 100644 --- a/content/en/case-studies/city-of-montreal/index.html +++ b/content/en/case-studies/city-of-montreal/index.html @@ -7,7 +7,7 @@ css: /css/style_case_studies.css featured: false --- -
+

CASE STUDY:
City of Montréal - How the City of Montréal Is Modernizing Its 30-Year-Old, Siloed Architecture with Kubernetes

@@ -50,7 +50,7 @@ featured: false The first step to modernize the architecture was containerization. “We based our effort on the new trends; we understood the benefits of immutability and deployments without downtime and such things,” says Solutions Architect Marc Khouzam. The team started with a small Docker farm with four or five servers, with Rancher for providing access to the Docker containers and their logs and Jenkins for deployment.
-
+
"Getting a project running in Kubernetes is entirely dependent on how long you need to program the actual software. It’s no longer dependent on deployment. Deployment is so fast that it’s negligible."

- MARC KHOUZAM, SOLUTIONS ARCHITECT, CITY OF MONTRÉAL @@ -65,7 +65,7 @@ featured: false Another important factor in the decision was vendor neutrality. “As a government entity, it is essential for us to be neutral in our selection of products and providers,” says Thibault. “The independence of the Cloud Native Computing Foundation from any company provides this.”
-
+
"Kubernetes has been great. It’s been stable, and it provides us with elasticity, resilience, and robustness. While re-architecting for Kubernetes, we also benefited from the monitoring and logging aspects, with centralized logging, Prometheus logging, and Grafana dashboards. We have enhanced visibility of what’s being deployed."

- MORGAN MARTINET, ENTERPRISE ARCHITECT, CITY OF MONTRÉAL
diff --git a/content/en/case-studies/denso/index.html b/content/en/case-studies/denso/index.html index 3ad0812d24..27ef1c77ed 100644 --- a/content/en/case-studies/denso/index.html +++ b/content/en/case-studies/denso/index.html @@ -12,7 +12,7 @@ quote: > --- -
+

CASE STUDY: Denso

How DENSO Is Fueling Development on the Vehicle Edge with Kubernetes
@@ -36,7 +36,7 @@ quote: > Critical layer features can take 2-3 years to implement in the traditional, waterfall model of development at DENSO. With the Kubernetes platform and agile methods, there’s a 2-month development cycle for non-critical software. Now, ten new applications are released a year, and a new prototype is introduced every week. "By utilizing Kubernetes managed services, such as GKE/EKS/AKS, we can unify the environment and simplify our maintenance operation," says Koizumi.
-
+
"Another disruptive innovation is coming, so to survive in this situation, we need to change our culture."

- SEIICHI KOIZUMI, R&D PRODUCT MANAGER, DIGITAL INNOVATION DEPARTMENT AT DENSO

@@ -79,7 +79,7 @@ quote: > -
+
"By utilizing Kubernetes managed services, such as GKE/EKS/AKS, we can unify the environment and simplify our maintenance operation."

- SEIICHI KOIZUMI, R&D PRODUCT MANAGER, DIGITAL INNOVATION DEPARTMENT AT DENSO

diff --git a/content/en/case-studies/ibm/index.html b/content/en/case-studies/ibm/index.html index 54e941c9cb..e9a78a9443 100644 --- a/content/en/case-studies/ibm/index.html +++ b/content/en/case-studies/ibm/index.html @@ -9,7 +9,7 @@ logo: ibm_featured_logo.svg featured: false --- -
+

CASE STUDY:
Building an Image Trust Service on Kubernetes with Notary and TUF

@@ -58,7 +58,7 @@ The availability of image signing "is a huge benefit to security-conscious custo
-
+
"Image signing is one key part of our Kubernetes container service offering, and our container registry team saw Notary as the de facto way to implement that capability in the current Docker and container ecosystem"

- Michael Hough, a software developer with the IBM Cloud Container Registry team
@@ -75,7 +75,7 @@ The availability of image signing "is a huge benefit to security-conscious custo
-
+
"With our IBM Cloud Kubernetes as-a-service offering and the admission controller we have made available, it allows both IBM services as well as customers of the IBM public cloud to use security policies to control service deployment."

- Michael Hough, a software developer with the IBM Cloud Container Registry team
diff --git a/content/en/case-studies/ing/index.html b/content/en/case-studies/ing/index.html index 6e2648a455..943daec2de 100644 --- a/content/en/case-studies/ing/index.html +++ b/content/en/case-studies/ing/index.html @@ -11,7 +11,7 @@ quote: > --- -
+

CASE STUDY:
Driving Banking Innovation with Cloud Native

@@ -58,7 +58,7 @@ quote: >
-
+
"We decided to standardize ING on a Kubernetes framework." Everything is run on premise due to banking regulations, he adds, but "we will be building an internal public cloud. We are trying to get on par with what public clouds are doing. That’s one of the reasons we got Kubernetes."

— Thijs Ebbers, Infrastructure Architect, ING @@ -72,7 +72,7 @@ quote: >
-
+
"We have to run the complete platform of services we need, many routing from different places. We need this Kubernetes framework for deploying the containers, with all those components, monitoring, logging. It’s complex."

— Onno Van der Voort, Infrastructure Architect, ING
diff --git a/content/en/case-studies/jd-com/index.html b/content/en/case-studies/jd-com/index.html index 636f226339..aed12fc54b 100644 --- a/content/en/case-studies/jd-com/index.html +++ b/content/en/case-studies/jd-com/index.html @@ -7,7 +7,7 @@ css: /css/style_case_studies.css featured: false --- -
+

CASE STUDY:
JD.com: How JD.com Pioneered Kubernetes for E-Commerce at Hyperscale

@@ -51,7 +51,7 @@ featured: false
-
+
"We customized Kubernetes and built a modern system on top of it. This entire ecosystem of Kubernetes plus our own optimizations have helped us save costs and time."

- HAIFENG LIU, CHIEF ARCHITECT, JD.com @@ -67,7 +67,7 @@ featured: false
-
+
"My advice is first you need to combine this technology with your own businesses, and the second is you need clear goals. You cannot just use the technology because others are using it. You need to consider your own objectives."

- HAIFENG LIU, CHIEF ARCHITECT, JD.com
diff --git a/content/en/case-studies/naic/index.html b/content/en/case-studies/naic/index.html index d40dd19c77..3deb91e480 100644 --- a/content/en/case-studies/naic/index.html +++ b/content/en/case-studies/naic/index.html @@ -9,7 +9,7 @@ logo: naic_featured_logo.png featured: false --- -
+

CASE STUDY:
A Culture and Technology Transition Enabled by Kubernetes

@@ -59,7 +59,7 @@ In addition, NAIC is onboarding teams to the new platform, and those teams have
-
+
"In our experience, vendor lock-in and tooling that is highly specific results in less resilient technology with fewer minds working to solve problems and grow the community."

- Dan Barker, Chief Enterprise Architect, NAIC
@@ -77,7 +77,7 @@ As for other CNCF projects, NAIC is using Prometheus on a small scale and hopes
-
+
"We knew that Kubernetes had become the de facto standard for container orchestration. Two major factors for selecting this were the three major cloud vendors hosting their own versions and having it hosted in a neutral party as fully open source."

- Dan Barker, Chief Enterprise Architect, NAIC
diff --git a/content/en/case-studies/nav/index.html b/content/en/case-studies/nav/index.html index d4cc89590d..bd606e7314 100644 --- a/content/en/case-studies/nav/index.html +++ b/content/en/case-studies/nav/index.html @@ -8,7 +8,7 @@ css: /css/style_case_studies.css featured: false --- -
+

CASE STUDY:
How A Startup Reduced Its Infrastructure Costs by 50% With Kubernetes

@@ -52,7 +52,7 @@ featured: false
-
+
"The community is absolutely vital: being able to pass ideas around, talk about a lot of the similar challenges that we’re all facing, and just get help. I like that we’re able to tackle the same problems for different reasons but help each other along the way."

- Travis Jeppson, Director of Engineering, Nav @@ -65,7 +65,7 @@ featured: false Jeppson’s four-person Engineering Services team got Kubernetes up and running in six months (they decided to use Kubespray to spin up clusters), and the full migration of Nav’s 25 microservices and one primary monolith was completed in another six months. “We couldn’t rewrite everything; we couldn’t stop,” he says. “We had to stay up, we had to stay available, and we had to have minimal amount of downtime. So we got really comfortable around our building pipeline, our metrics and logging, and then around Kubernetes itself: how to launch it, how to upgrade it, how to service it. And we moved little by little.”
-
+
“Kubernetes has brought so much value to Nav by allowing all of these new freedoms that we had just never had before.”

- Travis Jeppson, Director of Engineering, Nav
diff --git a/content/en/case-studies/nerdalize/index.html b/content/en/case-studies/nerdalize/index.html index 127d95c375..2756ce431c 100644 --- a/content/en/case-studies/nerdalize/index.html +++ b/content/en/case-studies/nerdalize/index.html @@ -6,7 +6,7 @@ cid: caseStudies css: /css/style_case_studies.css featured: false --- -
+

CASE STUDY:
Nerdalize: Providing Affordable and Sustainable Cloud Hosting with Kubernetes

@@ -47,7 +47,7 @@ featured: false After trying to develop its own scheduling system using another open source tool, Nerdalize found Kubernetes. “Kubernetes provided us with more functionality out of the gate,” says van der Veer.
-
+
“We always try to get a working version online first, like minimal viable products, and then move to stabilize that,” says van der Veer. “And I think that these kinds of day-two problems are now immediately solved. The rapid prototyping we saw internally is a very valuable aspect of Kubernetes.”

— AD VAN DER VEER, PRODUCT ENGINEER, NERDALIZE @@ -62,7 +62,7 @@ featured: false Not to mention the 40% cost savings. “Every euro that we have to invest for licensing of software that’s not open source comes from that 40%,” says van der Veer. If Nerdalize had used a non-open source orchestration platform instead of Kubernetes, “that would reduce our cost savings proposition to like 30%. Kubernetes directly allows us to have this business model and this strategic advantage.”
-
+
“One of our customers used to spend up to a day setting up the virtual machines, network and software every time they wanted to run a project in the cloud. On our platform, with Docker and Kubernetes, customers can have their projects running in a couple of minutes.”

- MAAIKE STOOPS, CUSTOMER EXPERIENCE QUEEN, NERDALIZE diff --git a/content/en/case-studies/netease/index.html b/content/en/case-studies/netease/index.html index a62ade486f..6cba5579ab 100644 --- a/content/en/case-studies/netease/index.html +++ b/content/en/case-studies/netease/index.html @@ -9,7 +9,7 @@ featured: false --- -
+

CASE STUDY:
How NetEase Leverages Kubernetes to Support Internet Business Worldwide

@@ -47,7 +47,7 @@ featured: false After considering building its own orchestration solution, NetEase decided to base its private cloud platform on Kubernetes. The fact that the technology came out of Google gave the team confidence that it could keep up with NetEase’s scale. “After our 2-to-3-month evaluation, we believed it could satisfy our needs,” says Feng.
-
+
"We leveraged the programmability of Kubernetes so that we can build a platform to satisfy the needs of our internal customers for upgrades and deployment."

- Feng Changjian, Architect for NetEase Cloud and Container Service, NetEase @@ -60,7 +60,7 @@ featured: false And the team is continuing to make improvements. For example, the e-commerce part of the business needs to leverage mixed deployments, which in the past required using two separate platforms: the infrastructure-as-a-service platform and the Kubernetes platform. More recently, NetEase has created a cross-platform application that enables using both with one-command deployment.
-
+
"As long as a company has a mature team and enough developers, I think Kubernetes is a very good technology that can help them."

- Li Lanqing, Kubernetes Developer, NetEase diff --git a/content/en/case-studies/newyorktimes/index.html b/content/en/case-studies/newyorktimes/index.html index c65b5fe883..53dbd06a55 100644 --- a/content/en/case-studies/newyorktimes/index.html +++ b/content/en/case-studies/newyorktimes/index.html @@ -5,7 +5,7 @@ cid: caseStudies css: /css/style_case_studies.css --- -
+

CASE STUDY:
The New York Times: From Print to the Web to Cloud Native

@@ -64,7 +64,7 @@ css: /css/style_case_studies.css
-
+
"We had some internal tooling that attempted to do what Kubernetes does for containers, but for VMs. We asked why are we building and maintaining these tools ourselves?"
@@ -79,7 +79,7 @@ css: /css/style_case_studies.css
-
+
"Right now, every team is running a small Kubernetes cluster, but it would be nice if we could all live in a larger ecosystem," says Kapadia. "Then we can harness the power of things like service mesh proxies that can actually do a lot of instrumentation between microservices, or service-to-service orchestration. Those are the new things that we want to experiment with as we go forward." diff --git a/content/en/case-studies/nokia/index.html b/content/en/case-studies/nokia/index.html index d8aaafc7f5..f824685327 100644 --- a/content/en/case-studies/nokia/index.html +++ b/content/en/case-studies/nokia/index.html @@ -8,7 +8,7 @@ logo: nokia_featured_logo.png --- -
+

CASE STUDY:
Nokia: Enabling 5G and DevOps at a Telecom Company with Kubernetes

@@ -51,7 +51,7 @@ logo: nokia_featured_logo.png
-
+
"Having the community and CNCF around Kubernetes is not only important for having a connection to other companies who are using Kubernetes and a forum where you can ask or discuss features of Kubernetes. But as a company who would like to contribute to Kubernetes, it was very important to have a CLA (Contributors License Agreement) which is connected to the CNCF and not to a particular company. That was a critical step for us to start contributing to Kubernetes and Helm."

- Gergely Csatari, Senior Open Source Engineer, Nokia @@ -65,7 +65,7 @@ logo: nokia_featured_logo.png
-
+
"Kubernetes opened the window to all of these open source projects instead of implementing everything in house. Our engineers can focus more on the application level, which is actually the thing what we are selling, and not on the infrastructure level. For us, the most important thing about Kubernetes is it allows us to focus on value creation of our business."

- Gergely Csatari, Senior Open Source Engineer, Nokia
diff --git a/content/en/case-studies/nordstrom/index.html b/content/en/case-studies/nordstrom/index.html index 5385c2473d..788453de35 100644 --- a/content/en/case-studies/nordstrom/index.html +++ b/content/en/case-studies/nordstrom/index.html @@ -5,7 +5,7 @@ cid: caseStudies css: /css/style_case_studies.css --- -
+

CASE STUDY:
Finding Millions in Potential Savings in a Tough Retail Climate @@ -60,7 +60,7 @@ css: /css/style_case_studies.css
-
+
"We made a bet that Kubernetes was going to take off, informed by early indicators of community support and project velocity, so we rebuilt our system with Kubernetes at the core,"
@@ -77,7 +77,7 @@ The benefits were immediate for the teams that came on board. "Teams running on
-
+
"Teams running on our Kubernetes cluster loved the fact that they had fewer issues to worry about. They didn’t need to manage infrastructure or operating systems," says Grigoriu. "Early adopters loved the declarative nature of Kubernetes. They loved the reduced surface area they had to deal with."
diff --git a/content/en/case-studies/northwestern-mutual/index.html b/content/en/case-studies/northwestern-mutual/index.html index dac0ef0d66..47b4bbc7be 100644 --- a/content/en/case-studies/northwestern-mutual/index.html +++ b/content/en/case-studies/northwestern-mutual/index.html @@ -5,7 +5,7 @@ cid: caseStudies css: /css/style_case_studies.css --- -
+

CASE STUDY:
Cloud Native at Northwestern Mutual @@ -22,7 +22,7 @@ css: /css/style_case_studies.css

Challenge

- In the spring of 2015, Northwestern Mutual acquired a fintech startup, LearnVest, and decided to take "Northwestern Mutual’s leading products and services and meld it with LearnVest’s digital experience and innovative financial planning platform," says Brad Williams, Director of Engineering for Client Experience, Northwestern Mutual. The company’s existing infrastructure had been optimized for batch workflows hosted on on-prem networks; deployments were very traditional, focused on following a process instead of providing deployment agility. "We had to build a platform that was elastically scalable, but also much more responsive, so we could quickly get data to the client website so our end-customers have the experience they expect," says Williams. + In the spring of 2015, Northwestern Mutual acquired a fintech startup, LearnVest, and decided to take "Northwestern Mutual’s leading products and services and meld it with LearnVest’s digital experience and innovative financial planning platform," says Brad Williams, Director of Engineering for Client Experience, Northwestern Mutual. The company’s existing infrastructure had been optimized for batch workflows hosted on on-prem networks; deployments were very traditional, focused on following a process instead of providing deployment agility. "We had to build a platform that was elastically scalable, but also much more responsive, so we could quickly get data to the client website so our end-customers have the experience they expect," says Williams.

Solution

The platform team came up with a plan for using the public cloud (AWS), Docker containers, and Kubernetes for orchestration. "Kubernetes gave us that base framework so teams can be very autonomous in what they’re building and deliver very quickly and frequently," says Northwestern Mutual Cloud Native Engineer Frank Greco Jr. The team also built and open-sourced Kanali, a Kubernetes-native API management tool that uses OpenTracing, Jaeger, and gRPC. @@ -53,7 +53,7 @@ In order to give the company’s 4.5 million clients the digital experience they
-
+
"Kubernetes has definitely been the right choice for us. It gave us that base framework so teams can be autonomous in what they’re building and deliver very quickly and frequently." @@ -63,12 +63,12 @@ In order to give the company’s 4.5 million clients the digital experience they
Williams and the rest of the platform team decided that the first step would be to start moving from private data centers to AWS. With a new microservice architecture in mind—and the freedom to implement what was best for the organization—they began using Docker containers. After looking into the various container orchestration options, they went with Kubernetes, even though it was still in beta at the time. "There was some debate whether we should build something ourselves, or just leverage that product and evolve with it," says Northwestern Mutual Cloud Native Engineer Frank Greco Jr. "Kubernetes has definitely been the right choice for us. It gave us that base framework so teams can be autonomous in what they’re building and deliver very quickly and frequently."

As early adopters, the team had to do a lot of work with Ansible scripts to stand up the cluster. "We had a lot of hard security requirements given the nature of our business," explains Bryan Pfremmer, App Platform Teams Manager, Northwestern Mutual. "We found ourselves running a configuration that very few other people ever tried." The client experience group was the first to use the new platform; today, a few hundred of the company’s 1,500 engineers are using it and more are eager to get on board. -The results have been dramatic. Before, infrastructure deployments could take two weeks; now, it is done in a matter of minutes. Now with a focus on Infrastructure automation, and self-service, "You can take an app to production in that same day if you want to," says Pfremmer. +The results have been dramatic. Before, infrastructure deployments could take two weeks; now, it is done in a matter of minutes. Now with a focus on Infrastructure automation, and self-service, "You can take an app to production in that same day if you want to," says Pfremmer.
-
+
"Now, developers have autonomy, they can use this whenever they want, however they want. It becomes more valuable the more instrumentation downstream that happens, as we mature in it."
diff --git a/content/en/case-studies/ocado/index.html b/content/en/case-studies/ocado/index.html index 6a930f945c..79ac9bf3a8 100644 --- a/content/en/case-studies/ocado/index.html +++ b/content/en/case-studies/ocado/index.html @@ -11,7 +11,7 @@ weight: 4 quote: > People at Ocado Technology have been quite amazed. They ask, ‘Can we do this on a Dev cluster?’ and 10 minutes later we have rolled out something that is deployed across the cluster. The speed from idea to implementation to deployment is amazing. --- -
+

CASE STUDY:
Ocado: Running Grocery Warehouses with a Cloud Native Platform

@@ -32,7 +32,7 @@ quote: >
- +

Impact

With Kubernetes, "the speed from idea to implementation to deployment is amazing," says Bryant. "I’ve seen features go from development to production inside of a week now. In the old world, a new application deployment could easily take over a month." And because there are no longer restrictive deployment windows in the warehouses, the rate of deployments has gone from as few as two per week to dozens per week. Ocado has also achieved cost savings because Kubernetes gives the team the ability to have more fine-grained resource allocation. Says DevOps Team Leader Kevin McCormack: "We have more confidence in the resource allocation/separation features of Kubernetes, so we have been able to migrate from around 10 fleet clusters to one Kubernetes cluster." The team also uses Prometheus and Grafana to visualize resource allocation, and makes the data available to developers. "The increased visibility offered by Prometheus means developers are more aware of what they are using and how their use impacts others, especially since we now have one shared cluster," says McCormack. "I’d estimate that we use about 15-25% less hardware resources to host the same applications in Kubernetes in our test environments." @@ -54,7 +54,7 @@ Bryant had already been using Kubernetes with +
"We were looking for a platform with wide adoption, and that was where the momentum was, the two paths converged, and we didn’t even go through any proof-of-concept stage. The Code for Life work served that purpose,"

- Kevin McCormack, DevOps Team Leader, Ocado
@@ -68,7 +68,7 @@ Bryant had already been using Kubernetes with +
"The unified API of Kubernetes means this is all in one place, and it’s one flow for approval and rollout. I’ve seen features go from development to production inside of a week now. In the old world, a new application deployment could easily take over a month."

- Mike Bryant, Platform Engineer, Ocado
diff --git a/content/en/case-studies/openAI/index.html b/content/en/case-studies/openAI/index.html index 040f704efa..1b95ec5f35 100644 --- a/content/en/case-studies/openAI/index.html +++ b/content/en/case-studies/openAI/index.html @@ -5,7 +5,7 @@ cid: caseStudies css: /css/style_case_studies.css --- -
+

CASE STUDY:
Launching and Scaling Up Experiments, Made Simple

@@ -56,7 +56,7 @@ css: /css/style_case_studies.css
-
+
OpenAI’s experiments take advantage of Kubernetes’ benefits, including portability. "Because Kubernetes provides a consistent API, we can move our research experiments very easily between clusters..." @@ -69,7 +69,7 @@ css: /css/style_case_studies.css
-
+
"One of our researchers who is working on a new distributed training system has been able to get his experiment running in two or three days," says Berner. "In a week or two he scaled it out to hundreds of GPUs. Previously, that would have easily been a couple of months of work."
diff --git a/content/en/case-studies/pearson/index.html b/content/en/case-studies/pearson/index.html index ddb567afb3..78f70228e5 100644 --- a/content/en/case-studies/pearson/index.html +++ b/content/en/case-studies/pearson/index.html @@ -8,7 +8,7 @@ featured: false quote: > We’re already seeing tremendous benefits with Kubernetes—improved engineering productivity, faster delivery of applications and a simplified infrastructure. But this is just the beginning. Kubernetes will help transform the way that educational content is delivered online. --- -
+

CASE STUDY:
Reinventing the World’s Largest Education Company With Kubernetes

@@ -47,7 +47,7 @@ quote: > The team adopted Kubernetes when it was still version 1.2 and are still going strong now on 1.7; they use Terraform and Ansible to deploy it on to basic AWS primitives. "We were trying to understand how we can create value for Pearson from this technology," says Ben Somogyi, Principal Architect for the Cloud Platforms. "It turned out that Kubernetes’ benefits are huge. We’re trying to help our applications development teams that use our platform go faster, so we filled that gap with a CI/CD pipeline that builds their images for them, standardizes them, patches everything up, allows them to deploy their different environments onto the cluster, and obfuscating the details of how difficult the work underneath the covers is."
-
+
"Your internal customers need to feel like they are choosing the very best option for them. We are experiencing this first hand in the growth of adoption. We are seeing triple-digit, year-on-year growth of the service."

— Chris Jackson, Director for Cloud Platforms & SRE at Pearson
@@ -60,7 +60,7 @@ quote: > Jackson estimates they’ve achieved a 15-20% boost in productivity for developer teams who adopt the platform. They also see a reduction in the number of customer-impacting incidents. Plus, says Jackson, "Teams who were previously limited to 1-2 releases per academic year can now ship code multiple times per day!"
-
+
"Teams who were previously limited to 1-2 releases per academic year can now ship code multiple times per day!"

— Chris Jackson, Director for Cloud Platforms & SRE at Pearson
diff --git a/content/en/case-studies/pingcap/index.html b/content/en/case-studies/pingcap/index.html index 637f891b3e..8d032c7a8b 100644 --- a/content/en/case-studies/pingcap/index.html +++ b/content/en/case-studies/pingcap/index.html @@ -7,7 +7,7 @@ css: /css/style_case_studies.css featured: false --- -
+

CASE STUDY:
PingCAP Bets on Cloud Native for Its TiDB Database Platform

@@ -52,7 +52,7 @@ featured: false Knowing that using a distributed system isn’t easy, the PingCAP team began looking for the right orchestration layer to help reduce some of that complexity for end users. Kubernetes had been on their radar for quite some time. "We knew Kubernetes had the promise of helping us solve our problems," says Xu. "We were just waiting for it to mature."
-
+
"With the governance process being so open, it’s not hard to find out what’s the latest development in the technology and community, or figure out who to reach out to if we have problems or issues."

- KEVIN XU, GENERAL MANAGER OF GLOBAL STRATEGY AND OPERATIONS, PINGCAP @@ -65,7 +65,7 @@ featured: false TiDB’s cloud native architecture consists of a stateless SQL layer (also called TiDB) and a persistent key-value storage layer that supports distributed transactions (TiKV, which is now in the CNCF Sandbox), which are loosely coupled. "You can scale both out or in depending on your computation and storage needs, and the two scaling processes can happen independent of each other," says Xu. The PingCAP team also built the TiDB Operator based on Kubernetes, which helps bootstrap a TiDB cluster on any cloud environment and simplifies and automates deployment, scaling, scheduling, upgrades, and maintenance. The company also recently previewed its fully-managed TiDB Cloud offering.
-
+
"A cloud native infrastructure will not only save you money and allow you to be more in control of the infrastructure resources you consume, but also empower new product innovation, new experience for your users, and new business possibilities. It’s both a cost reducer and a money maker."

- KEVIN XU, GENERAL MANAGER OF GLOBAL STRATEGY AND OPERATIONS, PINGCAP
diff --git a/content/en/case-studies/pinterest/index.html b/content/en/case-studies/pinterest/index.html index 0aa2381aa1..e4be7031bb 100644 --- a/content/en/case-studies/pinterest/index.html +++ b/content/en/case-studies/pinterest/index.html @@ -11,7 +11,7 @@ quote: > --- -
+

CASE STUDY:
Pinning Its Past, Present, and Future on Cloud Native

@@ -60,7 +60,7 @@ The first phase involved moving to Docker. "Pinterest has been heavily running o
-
+
"Though Kubernetes lacked certain things we wanted, we realized that by the time we get to productionizing many of those things, we’ll be able to leverage what the community is doing."

— MICHEAL BENEDICT, PRODUCT MANAGER FOR THE CLOUD AND THE DATA INFRASTRUCTURE GROUP AT PINTEREST
@@ -75,7 +75,7 @@ At the beginning of 2018, the team began onboarding its first use case into the
-
+
"So far it’s been good, especially the elasticity around how we can configure our Jenkins workloads on Kubernetes shared cluster. That is the win we were pushing for."

— MICHEAL BENEDICT, PRODUCT MANAGER FOR THE CLOUD AND THE DATA INFRASTRUCTURE GROUP AT PINTEREST
diff --git a/content/en/case-studies/prowise/index.html b/content/en/case-studies/prowise/index.html index 03bbc51173..2f0beda5ae 100644 --- a/content/en/case-studies/prowise/index.html +++ b/content/en/case-studies/prowise/index.html @@ -8,7 +8,7 @@ featured: false --- -
+

CASE STUDY:
Prowise: How Kubernetes is Enabling the Edtech Solution’s Global Expansion

@@ -50,7 +50,7 @@ featured: false The company’s existing infrastructure on Microsoft Azure Cloud was all on virtual machines, “a pretty traditional setup,” van den Bosch says. “We decided that we want some features in our software that requires being able to scale quickly, being able to deploy new applications and versions on different versions of different programming languages quickly. And we didn’t really want the hassle of trying to keep those servers in a particular state.”
-
+
"You don’t have to go all-in immediately. You can just take a few projects, a service, run it alongside your more traditional stack, and build it up from there. Kubernetes scales, so as you add applications and services to it, it will scale with you. You don’t have to do it all at once, and that’s really a secret to everything, but especially true to Kubernetes."

— VICTOR VAN DEN BOSCH, SENIOR DEVOPS ENGINEER, PROWISE @@ -67,7 +67,7 @@ featured: false With its first web-based applications now running in beta on Prowise’s Kubernetes platform, the team is seeing the benefits of rapid and smooth deployments. “The old way of deploying took half an hour of preparations and half an hour deploying it. With Kubernetes, it’s a couple of seconds,” says Senior Developer Bart Haalstra. As a result, adds van den Bosch, “We’ve gone from quarterly releases to a release every month in production. We’re pretty much deploying every hour or just when we find that a feature is ready for production. Before, our releases were mostly done on off-hours, where it couldn’t impact our customers, as our confidence the process itself was relatively low. With Kubernetes, we dare to deploy in the middle of a busy day with high confidence the deployment will succeed.”
-
+
"Kubernetes allows us to really consider the best tools for a problem. Want to have a full-fledged analytics application developed by a third party that is just right for your use case? Run it. Dabbling in machine learning and AI algorithms but getting tired of waiting days for training to complete? It takes only seconds to scale it. Got a stubborn developer that wants to use a programming language no one has heard of? Let him, if it runs in a container, of course. And all of that while your operations team/DevOps get to sleep at night."

- VICTOR VAN DEN BOSCH, SENIOR DEVOPS ENGINEER, PROWISE
diff --git a/content/en/case-studies/ricardo-ch/index.html b/content/en/case-studies/ricardo-ch/index.html index 62501c4f5b..2863ceac75 100644 --- a/content/en/case-studies/ricardo-ch/index.html +++ b/content/en/case-studies/ricardo-ch/index.html @@ -7,7 +7,7 @@ css: /css/style_case_studies.css featured: false --- -
+

CASE STUDY:
ricardo.ch: How Kubernetes Improved Velocity and DevOps Harmony

@@ -48,7 +48,7 @@ featured: false To address the velocity issue, ricardo.ch CTO Jeremy Seitz established a new software factory called EPD, which consists of 65 engineers, 7 product managers and 2 designers. "We brought these three departments together so that they can kind of streamline this and talk to each other much more closely," says Meury.
-
+
"Being in the End User Community demonstrates that we stand behind these technologies. In Switzerland, if all the companies see that ricardo.ch’s using it, I think that will help adoption. I also like that we’re connected to the other end users, so if there is a really heavy problem, I could go to the Slack channel, and say, ‘Hey, you guys…’ Like Reddit, Github and New York Times or whoever can give a recommendation on what to use here or how to solve that. So that’s kind of a superpower."

— CEDRIC MEURY, HEAD OF PLATFORM ENGINEERING, RICARDO.CH @@ -64,7 +64,7 @@ featured: false Meury estimates that half of the application has been migrated to Kubernetes. And the plan is to move everything to the Google Cloud Platform by the end of 2018. "We are still running some servers in our own data centers, but all of the containerization efforts and describing our services as Kubernetes manifests will allow us to quite easily make that shift," says Meury.
-
+
"One of the core moments was when a front-end developer asked me how to do a port forward from his laptop to a front-end application to debug, and I told him the command. And he was like, ‘Wow, that’s all I need to do?’ He was super excited and happy about it. That showed me that this power in the right hands can just accelerate development."

- CEDRIC MEURY, HEAD OF PLATFORM ENGINEERING, RICARDO.CH diff --git a/content/en/case-studies/slamtec/index.html b/content/en/case-studies/slamtec/index.html index 4a99d28fb3..86ebe15f91 100644 --- a/content/en/case-studies/slamtec/index.html +++ b/content/en/case-studies/slamtec/index.html @@ -7,7 +7,7 @@ css: /css/style_case_studies.css featured: false --- -
+

CASE STUDY:



@@ -47,7 +47,7 @@ featured: false After an evaluation of existing technologies, Ji’s team chose Kubernetes for orchestration. "CNCF brings quality assurance and a complete ecosystem for Kubernetes, which is very important for the wide application of Kubernetes," says Ji. Plus, "avoiding binding to an infrastructure technology or provider can help us ensure that our business is deployed and migrated in cross-regional environments, and can serve users all over the world."
-
+
"CNCF brings quality assurance and a complete ecosystem for Kubernetes, which is very important for the wide application of Kubernetes."

- BENNIU JI, DIRECTOR OF CLOUD COMPUTING BUSINESS DIVISION @@ -60,7 +60,7 @@ featured: false The company uses Harbor as a container image repository. "Harbor’s replication function helps us implement CI/CD on both private and public clouds," says Ji. "In addition, multi-project support, certification and policy configuration, and integration with Kubernetes are also excellent functions." Helm is also being used as a package manager, and the team is evaluating the Istio framework. "We’re very pleased that Kubernetes and these frameworks can be seamlessly integrated," Ji adds.
-
+
"Cloud native is suitable for microservice architecture, it’s suitable for fast iteration and agile development, and it has a relatively perfect ecosystem and active community."

- BENNIU JI, DIRECTOR OF CLOUD COMPUTING BUSINESS DIVISION
diff --git a/content/en/case-studies/slingtv/index.html b/content/en/case-studies/slingtv/index.html index a11527c2d9..349ed8c2de 100644 --- a/content/en/case-studies/slingtv/index.html +++ b/content/en/case-studies/slingtv/index.html @@ -11,7 +11,7 @@ quote: > --- -
+

CASE STUDY:
Sling TV: Marrying Kubernetes and AI to Enable Proper Web Scale

@@ -62,7 +62,7 @@ Led by the belief that “the cloud native architectures and patterns really giv
-
+
“We needed the flexibility to enable our use case versus just a simple orchestrater. Enabling our future in a way that did not give us vendor lock-in was also a key part of our strategy. I think that is part of the Rancher value proposition.”

— Brad Linder, Cloud Native & Big Data Evangelist for Sling TV
@@ -75,7 +75,7 @@ With the emphasis on common tooling, “We are getting to the place where we can
-
+
“We have to be able to react to changes and hiccups in the matrix. It is the foundation for our ability to deliver a high-quality service for our customers."

— Brad Linder, Cloud Native & Big Data Evangelist for Sling TV
diff --git a/content/en/case-studies/sos/index.html b/content/en/case-studies/sos/index.html index 64708a20f8..becf486413 100644 --- a/content/en/case-studies/sos/index.html +++ b/content/en/case-studies/sos/index.html @@ -8,7 +8,7 @@ logo: sos_featured_logo.png --- -
+

CASE STUDY:
SOS International: Using Kubernetes to Provide Emergency Assistance in a Connected World

@@ -56,7 +56,7 @@ logo: sos_featured_logo.png
-
+
"We have to deliver new digital services, but we also have to migrate the old stuff, and we have to transform our core systems into new systems built on top of this platform. One of the reasons why we chose this technology is that we could build new digital services while changing the old one."

- Martin Ahrentsen, Head of Enterprise Architecture, SOS International @@ -70,7 +70,7 @@ logo: sos_featured_logo.png
-
+
"During our onboarding, we could see that we were chosen by IT professionals because we provided the new technologies."

- Martin Ahrentsen, Head of Enterprise Architecture, SOS International
diff --git a/content/en/case-studies/spotify/index.html b/content/en/case-studies/spotify/index.html index 85e7fc1e86..63243b08f6 100644 --- a/content/en/case-studies/spotify/index.html +++ b/content/en/case-studies/spotify/index.html @@ -7,7 +7,7 @@ css: /css/style_case_studies.css featured: false --- -
+

CASE STUDY: Spotify
Spotify: An Early Adopter of Containers, Spotify Is Migrating from Homegrown Orchestration to Kubernetes

@@ -52,7 +52,7 @@ featured: false
-
+
"The community has been extremely helpful in getting us to work through all the technology much faster and much easier. And it’s helped us validate all the things we’re doing."

- Dave Zolotusky, Software Engineer, Infrastructure and Operations, Spotify @@ -67,7 +67,7 @@ featured: false
-
+
"We were able to use a lot of the Kubernetes APIs and extensibility features to support and interface with our legacy infrastructure, so the integration was straightforward and easy."

- James Wen, Site Reliability Engineer, Spotify
diff --git a/content/en/case-studies/squarespace/index.html b/content/en/case-studies/squarespace/index.html index d2b2a18c92..27340835f4 100644 --- a/content/en/case-studies/squarespace/index.html +++ b/content/en/case-studies/squarespace/index.html @@ -5,7 +5,7 @@ cid: caseStudies css: /css/style_case_studies.css --- -
+

CASE STUDY:
Squarespace: Gaining Productivity and Resilience with Kubernetes

@@ -51,7 +51,7 @@ Since Squarespace moved to Kubernetes, in conjunction with modernizing its netwo
-
+
After experimenting with another container orchestration platform and "breaking it in very painful ways," Lynch says, the team began experimenting with Kubernetes in mid-2016 and found that it "answered all the questions that we had." @@ -68,7 +68,7 @@ Since Squarespace moved to Kubernetes, in conjunction with modernizing its netwo
-
+
"We switched to Kubernetes, a new world....It allowed us to streamline our process, so we can now easily create an entire microservice project from templates," Lynch says. And the whole process takes only five minutes, an almost 85% reduction in time compared to their VM deployment.
diff --git a/content/en/case-studies/thredup/index.html b/content/en/case-studies/thredup/index.html index 0a35de2b1a..ad990356ff 100644 --- a/content/en/case-studies/thredup/index.html +++ b/content/en/case-studies/thredup/index.html @@ -7,7 +7,7 @@ css: /css/style_case_studies.css featured: false --- -
+

CASE STUDY:



@@ -49,7 +49,7 @@ featured: false "We wanted to make sure that our engineers could embrace the DevOps mindset as they built software," Homer says. "It was really important to us that they could own the life cycle from end to end, from conception at design, through shipping it and running it in production, from marketing to ecommerce, the user experience and our internal distribution center operations."
-
+
"Kubernetes enabled auto scaling in a seamless and easily manageable way on days like Black Friday. We no longer have to sit there adding instances, monitoring the traffic, doing a lot of manual work."

- CHRIS HOMER, COFOUNDER/CTO, THREDUP @@ -62,7 +62,7 @@ featured: false According to the infrastructure team, the key improvement was the consistent experience Kubernetes enabled for developers. "It lets developers work in the same environment that their application will be running in production," says Infrastructure Engineer Oleksandr Snagovskyi. Plus, "It became easier to test, easier to refine, and easier to deploy, because everything’s done automatically," says Infrastructure Engineer Oleksii Asiutin. "One of the main goals of our team is to make developers’ lives more comfortable, and we are achieving this with Kubernetes. They can experiment with existing applications and create new services, and do it all blazingly fast."
-
+
"One of the main goals of our team is to make developers’ lives more comfortable, and we are achieving this with Kubernetes. They can experiment with existing applications and create new services, and do it all blazingly fast."

- OLEKSII ASIUTIN, INFRASTRUCTURE ENGINEER, THREDUP
diff --git a/content/en/case-studies/vsco/index.html b/content/en/case-studies/vsco/index.html index 4ca7aa1bbc..c2ac2a2a72 100644 --- a/content/en/case-studies/vsco/index.html +++ b/content/en/case-studies/vsco/index.html @@ -7,7 +7,7 @@ css: /css/style_case_studies.css featured: false --- -
+

CASE STUDY:
VSCO: How a Mobile App Saved 70% on Its EC2 Bill with Cloud Native

@@ -48,7 +48,7 @@ featured: false
-
+
"Kubernetes seemed to have the strongest open source community around it, plus, we had started to standardize on a lot of the Google stack, with Go as a language, and gRPC for almost all communication between our own services inside the data center. So it seemed pretty natural for us to choose Kubernetes."

- MELINDA LU, ENGINEERING MANAGER FOR VSCO'S MACHINE LEARNING TEAM @@ -64,7 +64,7 @@ featured: false
-
+
"I've been really impressed seeing how our engineers have come up with really creative solutions to things by just combining a lot of Kubernetes primitives, exposing Kubernetes constructs as a service to our engineers as opposed to exposing higher order constructs has worked well for us. It lets you get familiar with the technology and do more interesting things with it."

- MELINDA LU, ENGINEERING MANAGER FOR VSCO’S MACHINE LEARNING TEAM
diff --git a/content/en/case-studies/woorank/index.html b/content/en/case-studies/woorank/index.html index aa41b7cb44..fbb86bdd24 100644 --- a/content/en/case-studies/woorank/index.html +++ b/content/en/case-studies/woorank/index.html @@ -8,7 +8,7 @@ featured: false --- -
+

CASE STUDY:
Woorank: How Kubernetes Helped a Startup Manage 50 Microservices with
12 Engineers—At 30% Less Cost

@@ -50,7 +50,7 @@ featured: false
-
+
"Cloud native technologies have brought to us a transparency on everything going on in our system, from the code to the server. It has brought huge cost savings and a better way of dealing with those costs and keeping them under control. And performance-wise, it has helped our team understand how we can make our code work better on the cloud native infrastructure."

— NILS DE MOOR, CTO/COFOUNDER, WOORANK @@ -66,7 +66,7 @@ featured: false The company’s number one concern was immediately erased: Maintaining Kubernetes is the responsibility of just one person on staff, and it’s not his fulltime job. Updating the old infrastructure “was always a pain,” says De Moor: It used to take two active working days, “and it was always a bit scary when we did that.” With Kubernetes, it’s just a matter of “a few hours of passively following the process.”
-
+
"When things fail and errors pop up, the system tries to heal itself, and that’s really, for us, the key reason to work with Kubernetes. It allowed us to set up certain testing frameworks to just be alerted when things go wrong, instead of having to look at whether everything went right. It’s made people’s lives much easier. It’s quite a big mindset change."

- NILS DE MOOR, CTO/COFOUNDER, WOORANK
diff --git a/content/en/case-studies/workiva/index.html b/content/en/case-studies/workiva/index.html index 95f323d5ae..1c09503bfb 100644 --- a/content/en/case-studies/workiva/index.html +++ b/content/en/case-studies/workiva/index.html @@ -11,7 +11,7 @@ quote: > With OpenTracing, my team was able to look at a trace and make optimization suggestions to another team without ever looking at their code. --- -
+

CASE STUDY:
Using OpenTracing to Help Pinpoint the Bottlenecks

@@ -30,12 +30,12 @@ quote: > Workiva offers a cloud-based platform for managing and reporting business data. This SaaS product, Wdesk, is used by more than 70 percent of the Fortune 500 companies. As the company made the shift from a monolith to a more distributed, microservice-based system, "We had a number of people working on this, all on different teams, so we needed to identify what the issues were and where the bottlenecks were," says Senior Software Architect MacLeod Broad. With back-end code running on Google App Engine, Google Compute Engine, as well as Amazon Web Services, Workiva needed a tracing system that was agnostic of platform. While preparing one of the company’s first products utilizing AWS, which involved a "sync and link" feature that linked data from spreadsheets built in the new application with documents created in the old application on Workiva’s existing system, Broad’s team found an ideal use case for tracing: There were circular dependencies, and optimizations often turned out to be micro-optimizations that didn’t impact overall speed.
- +

Solution

- Broad’s team introduced the platform-agnostic distributed tracing system OpenTracing to help them pinpoint the bottlenecks. + Broad’s team introduced the platform-agnostic distributed tracing system OpenTracing to help them pinpoint the bottlenecks.

Impact

Now used throughout the company, OpenTracing produced immediate results. Software Engineer Michael Davis reports: "Tracing has given us immediate, actionable insight into how to improve our service. Through a combination of seeing where each call spends its time, as well as which calls are most often used, we were able to reduce our average response time by 95 percent (from 600ms to 30ms) in a single fix." @@ -61,14 +61,14 @@ The challenges faced by Broad’s team may sound familiar to other companies tha
-
+
"A tracing system can at a glance explain an architecture, narrow down a performance bottleneck and zero in on it, and generally just help direct an investigation at a high level. Being able to do that at a glance is much faster than at a meeting or with three days of debugging, and it’s a lot faster than never figuring out the problem and just moving on."
— MACLEOD BROAD, SENIOR SOFTWARE ARCHITECT AT WORKIVA
- + Simply put, it was an ideal use case for tracing. "A tracing system can at a glance explain an architecture, narrow down a performance bottleneck and zero in on it, and generally just help direct an investigation at a high level," says Broad. "Being able to do that at a glance is much faster than at a meeting or with three days of debugging, and it’s a lot faster than never figuring out the problem and just moving on."

With Workiva’s back-end code running on Google Compute Engine as well as App Engine and AWS, Broad knew that he needed a tracing system that was platform agnostic. "We were looking at different tracing solutions," he says, "and we decided that because it seemed to be a very evolving market, we didn’t want to get stuck with one vendor. So OpenTracing seemed like the cleanest way to avoid vendor lock-in on what backend we actually had to use."

Once they introduced OpenTracing into this first use case, Broad says, "The trace made it super obvious where the bottlenecks were." Even though everyone had assumed it was Workiva’s existing code that was slowing things down, that wasn’t exactly the case. "It looked like the existing code was slow only because it was reaching out to our next-generation services, and they were taking a very long time to service all those requests," says Broad. "On the waterfall graph you can see the exact same work being done on every request when it was calling back in. So every service request would look the exact same for every response being paged out. And then it was just a no-brainer of, ‘Why is it doing all this work again?’"

@@ -78,7 +78,7 @@ Using the insight OpenTracing gave them, "My team was able to look at a trace an
-
+
"We were looking at different tracing solutions and we decided that because it seemed to be a very evolving market, we didn’t want to get stuck with one vendor. So OpenTracing seemed like the cleanest way to avoid vendor lock-in on what backend we actually had to use."
— MACLEOD BROAD, SENIOR SOFTWARE ARCHITECT AT WORKIVA
@@ -90,7 +90,7 @@ Using the insight OpenTracing gave them, "My team was able to look at a trace an Some teams were won over quickly. "Tracing has given us immediate, actionable insight into how to improve our [Workspaces] service," says Software Engineer Michael Davis. "Through a combination of seeing where each call spends its time, as well as which calls are most often used, we were able to reduce our average response time by 95 percent (from 600ms to 30ms) in a single fix."

Most of Workiva’s major products are now traced using OpenTracing, with data pushed into Google StackDriver. Even the products that aren’t fully traced have some components and libraries that are.

Broad points out that because some of the engineers were working on App Engine and already had experience with the platform’s Appstats library for profiling performance, it didn’t take much to get them used to using OpenTracing. But others were a little more reluctant. "The biggest hindrance to adoption I think has been the concern about how much latency is introducing tracing [and StackDriver] going to cost," he says. "People are also very concerned about adding middleware to whatever they’re working on. Questions about passing the context around and how that’s done were common. A lot of our Go developers were fine with it, because they were already doing that in one form or another. Our Java developers were not super keen on doing that because they’d used other systems that didn’t require that."

-But the benefits clearly outweighed the concerns, and today, Workiva’s official policy is to use tracing." +But the benefits clearly outweighed the concerns, and today, Workiva’s official policy is to use tracing." In fact, Broad believes that tracing naturally fits in with Workiva’s existing logging and metrics systems. "This was the way we presented it internally, and also the way we designed our use," he says. "Our traces are logged in the exact same mechanism as our app metric and logging data, and they get pushed the exact same way. So we treat all that data exactly the same when it’s being created and when it’s being recorded. We have one internal library that we use for logging, telemetry, analytics and tracing." @@ -98,7 +98,7 @@ In fact, Broad believes that tracing naturally fits in with Workiva’s existing
- "Tracing has given us immediate, actionable insight into how to improve our [Workspaces] service. Through a combination of seeing where each call spends its time, as well as which calls are most often used, we were able to reduce our average response time by 95 percent (from 600ms to 30ms) in a single fix."
— Michael Davis, Software Engineer, Workiva + "Tracing has given us immediate, actionable insight into how to improve our [Workspaces] service. Through a combination of seeing where each call spends its time, as well as which calls are most often used, we were able to reduce our average response time by 95 percent (from 600ms to 30ms) in a single fix."
— Michael Davis, Software Engineer, Workiva
diff --git a/content/en/case-studies/ygrene/index.html b/content/en/case-studies/ygrene/index.html index 498dc0ec73..c07443249a 100644 --- a/content/en/case-studies/ygrene/index.html +++ b/content/en/case-studies/ygrene/index.html @@ -12,7 +12,7 @@ quote: > We had to change some practices and code, and the way things were built, but we were able to get our main systems onto Kubernetes in a month or so, and then into production within two months. That’s very fast for a finance company. --- -
+

CASE STUDY:
Ygrene: Using Cloud Native to Bring Security and Scalability to the Finance Industry

@@ -61,7 +61,7 @@ By 2017, deployments and scalability had become pain points. The company was uti
-
+
"CNCF has been an amazing incubator for so many projects. Now we look at its webpage regularly to find out if there are any new, awesome, high-quality projects we can implement into our stack. It’s actually become a hub for us for knowing what software we need to be looking at to make our systems more secure or more scalable."

— Austin Adams, Development Manager, Ygrene Energy Fund
@@ -78,7 +78,7 @@ Notary, in particular, "has been a godsend," says Adams. "We need to know that o
-
+
"We had to change some practices and code, and the way things were built," Adams says, "but we were able to get our main systems onto Kubernetes in a month or so, and then into production within two months. That’s very fast for a finance company."
diff --git a/content/en/docs/concepts/_index.md b/content/en/docs/concepts/_index.md index 27c23bfe4d..8165a3a1f4 100644 --- a/content/en/docs/concepts/_index.md +++ b/content/en/docs/concepts/_index.md @@ -12,61 +12,3 @@ The Concepts section helps you learn about the parts of the Kubernetes system an - -## Overview - -To work with Kubernetes, you use *Kubernetes API objects* to describe your cluster's *desired state*: what applications or other workloads you want to run, what container images they use, the number of replicas, what network and disk resources you want to make available, and more. You set your desired state by creating objects using the Kubernetes API, typically via the command-line interface, `kubectl`. You can also use the Kubernetes API directly to interact with the cluster and set or modify your desired state. - -Once you've set your desired state, the *Kubernetes Control Plane* makes the cluster's current state match the desired state via the Pod Lifecycle Event Generator ([PLEG](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/node/pod-lifecycle-event-generator.md)). To do so, Kubernetes performs a variety of tasks automatically--such as starting or restarting containers, scaling the number of replicas of a given application, and more. The Kubernetes Control Plane consists of a collection of processes running on your cluster: - -* The **Kubernetes Master** is a collection of three processes that run on a single node in your cluster, which is designated as the master node. Those processes are: [kube-apiserver](/docs/admin/kube-apiserver/), [kube-controller-manager](/docs/admin/kube-controller-manager/) and [kube-scheduler](/docs/admin/kube-scheduler/). -* Each individual non-master node in your cluster runs two processes: - * **[kubelet](/docs/admin/kubelet/)**, which communicates with the Kubernetes Master. - * **[kube-proxy](/docs/admin/kube-proxy/)**, a network proxy which reflects Kubernetes networking services on each node. - -## Kubernetes objects - -Kubernetes contains a number of abstractions that represent the state of your system: deployed containerized applications and workloads, their associated network and disk resources, and other information about what your cluster is doing. These abstractions are represented by objects in the Kubernetes API. See [Understanding Kubernetes objects](/docs/concepts/overview/working-with-objects/kubernetes-objects/#kubernetes-objects) for more details. - -The basic Kubernetes objects include: - -* [Pod](/docs/concepts/workloads/pods/pod-overview/) -* [Service](/docs/concepts/services-networking/service/) -* [Volume](/docs/concepts/storage/volumes/) -* [Namespace](/docs/concepts/overview/working-with-objects/namespaces/) - -Kubernetes also contains higher-level abstractions that rely on [controllers](/docs/concepts/architecture/controller/) to build upon the basic objects, and provide additional functionality and convenience features. These include: - -* [Deployment](/docs/concepts/workloads/controllers/deployment/) -* [DaemonSet](/docs/concepts/workloads/controllers/daemonset/) -* [StatefulSet](/docs/concepts/workloads/controllers/statefulset/) -* [ReplicaSet](/docs/concepts/workloads/controllers/replicaset/) -* [Job](/docs/concepts/workloads/controllers/job/) - -## Kubernetes Control Plane - -The various parts of the Kubernetes Control Plane, such as the Kubernetes Master and kubelet processes, govern how Kubernetes communicates with your cluster. The Control Plane maintains a record of all of the Kubernetes Objects in the system, and runs continuous control loops to manage those objects' state. At any given time, the Control Plane's control loops will respond to changes in the cluster and work to make the actual state of all the objects in the system match the desired state that you provided. - -For example, when you use the Kubernetes API to create a Deployment, you provide a new desired state for the system. The Kubernetes Control Plane records that object creation, and carries out your instructions by starting the required applications and scheduling them to cluster nodes--thus making the cluster's actual state match the desired state. - -### Kubernetes Master - -The Kubernetes master is responsible for maintaining the desired state for your cluster. When you interact with Kubernetes, such as by using the `kubectl` command-line interface, you're communicating with your cluster's Kubernetes master. - -> The "master" refers to a collection of processes managing the cluster state. Typically all these processes run on a single node in the cluster, and this node is also referred to as the master. The master can also be replicated for availability and redundancy. - -### Kubernetes Nodes - -The nodes in a cluster are the machines (VMs, physical servers, etc) that run your applications and cloud workflows. The Kubernetes master controls each node; you'll rarely interact with nodes directly. - - - - -## {{% heading "whatsnext" %}} - - -If you would like to write a concept page, see -[Page Content Types](/docs/contribute/style/page-content-types/#concept) -for information about the concept page types. - - diff --git a/content/en/docs/concepts/architecture/_index.md b/content/en/docs/concepts/architecture/_index.md index 3a17d1b08e..61fb48e714 100755 --- a/content/en/docs/concepts/architecture/_index.md +++ b/content/en/docs/concepts/architecture/_index.md @@ -1,5 +1,7 @@ --- title: "Cluster Architecture" weight: 30 +description: > + The architectural concepts behind Kubernetes. --- diff --git a/content/en/docs/concepts/architecture/control-plane-node-communication.md b/content/en/docs/concepts/architecture/control-plane-node-communication.md index 925f14d17a..8040213495 100644 --- a/content/en/docs/concepts/architecture/control-plane-node-communication.md +++ b/content/en/docs/concepts/architecture/control-plane-node-communication.md @@ -46,7 +46,7 @@ These connections terminate at the kubelet's HTTPS endpoint. By default, the api To verify this connection, use the `--kubelet-certificate-authority` flag to provide the apiserver with a root certificate bundle to use to verify the kubelet's serving certificate. -If that is not possible, use [SSH tunneling](/docs/concepts/architecture/master-node-communication/#ssh-tunnels) between the apiserver and kubelet if required to avoid connecting over an +If that is not possible, use [SSH tunneling](#ssh-tunnels) between the apiserver and kubelet if required to avoid connecting over an untrusted or public network. Finally, [Kubelet authentication and/or authorization](/docs/admin/kubelet-authentication-authorization/) should be enabled to secure the kubelet API. diff --git a/content/en/docs/concepts/architecture/nodes.md b/content/en/docs/concepts/architecture/nodes.md index 516e4eb6d9..5482b074bc 100644 --- a/content/en/docs/concepts/architecture/nodes.md +++ b/content/en/docs/concepts/architecture/nodes.md @@ -23,8 +23,6 @@ The [components](/docs/concepts/overview/components/#node-components) on a node {{< glossary_tooltip text="container runtime" term_id="container-runtime" >}}, and the {{< glossary_tooltip text="kube-proxy" term_id="kube-proxy" >}}. - - ## Management @@ -195,7 +193,7 @@ The node lifecycle controller automatically creates The scheduler takes the Node's taints into consideration when assigning a Pod to a Node. Pods can also have tolerations which let them tolerate a Node's taints. -See [Taint Nodes by Condition](/docs/concepts/configuration/taint-and-toleration/#taint-nodes-by-condition) +See [Taint Nodes by Condition](/docs/concepts/scheduling-eviction/taint-and-toleration/#taint-nodes-by-condition) for more details. ### Capacity and Allocatable {#capacity} @@ -339,6 +337,6 @@ for more information. * Read the [API definition for Node](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#node-v1-core). * Read the [Node](https://git.k8s.io/community/contributors/design-proposals/architecture/architecture.md#the-kubernetes-node) section of the architecture design document. -* Read about [taints and tolerations](/docs/concepts/configuration/taint-and-toleration/). +* Read about [taints and tolerations](/docs/concepts/scheduling-eviction/taint-and-toleration/). * Read about [cluster autoscaling](/docs/tasks/administer-cluster/cluster-management/#cluster-autoscaling). diff --git a/content/en/docs/concepts/cluster-administration/_index.md b/content/en/docs/concepts/cluster-administration/_index.md old mode 100755 new mode 100644 index 72af40feec..ec3f9c2f54 --- a/content/en/docs/concepts/cluster-administration/_index.md +++ b/content/en/docs/concepts/cluster-administration/_index.md @@ -1,5 +1,75 @@ --- -title: "Cluster Administration" +title: Cluster Administration +reviewers: +- davidopp +- lavalamp weight: 100 +content_type: concept +description: > + Lower-level detail relevant to creating or administering a Kubernetes cluster. +no_list: true --- + +The cluster administration overview is for anyone creating or administering a Kubernetes cluster. +It assumes some familiarity with core Kubernetes [concepts](/docs/concepts/). + + + +## Planning a cluster + +See the guides in [Setup](/docs/setup/) for examples of how to plan, set up, and configure Kubernetes clusters. The solutions listed in this article are called *distros*. + + {{< note >}} + Not all distros are actively maintained. Choose distros which have been tested with a recent version of Kubernetes. + {{< /note >}} + +Before choosing a guide, here are some considerations: + + - Do you just want to try out Kubernetes on your computer, or do you want to build a high-availability, multi-node cluster? Choose distros best suited for your needs. + - Will you be using **a hosted Kubernetes cluster**, such as [Google Kubernetes Engine](https://cloud.google.com/kubernetes-engine/), or **hosting your own cluster**? + - Will your cluster be **on-premises**, or **in the cloud (IaaS)**? Kubernetes does not directly support hybrid clusters. Instead, you can set up multiple clusters. + - **If you are configuring Kubernetes on-premises**, consider which [networking model](/docs/concepts/cluster-administration/networking/) fits best. + - Will you be running Kubernetes on **"bare metal" hardware** or on **virtual machines (VMs)**? + - Do you **just want to run a cluster**, or do you expect to do **active development of Kubernetes project code**? If the + latter, choose an actively-developed distro. Some distros only use binary releases, but + offer a greater variety of choices. + - Familiarize yourself with the [components](/docs/concepts/overview/components/) needed to run a cluster. + + +## Managing a cluster + +* [Managing a cluster](/docs/tasks/administer-cluster/cluster-management/) describes several topics related to the lifecycle of a cluster: creating a new cluster, upgrading your cluster’s master and worker nodes, performing node maintenance (e.g. kernel upgrades), and upgrading the Kubernetes API version of a running cluster. + +* Learn how to [manage nodes](/docs/concepts/architecture/nodes/). + +* Learn how to set up and manage the [resource quota](/docs/concepts/policy/resource-quotas/) for shared clusters. + +## Securing a cluster + +* [Certificates](/docs/concepts/cluster-administration/certificates/) describes the steps to generate certificates using different tool chains. + +* [Kubernetes Container Environment](/docs/concepts/containers/container-environment/) describes the environment for Kubelet managed containers on a Kubernetes node. + +* [Controlling Access to the Kubernetes API](/docs/reference/access-authn-authz/controlling-access/) describes how to set up permissions for users and service accounts. + +* [Authenticating](/docs/reference/access-authn-authz/authentication/) explains authentication in Kubernetes, including the various authentication options. + +* [Authorization](/docs/reference/access-authn-authz/authorization/) is separate from authentication, and controls how HTTP calls are handled. + +* [Using Admission Controllers](/docs/reference/access-authn-authz/admission-controllers/) explains plug-ins which intercepts requests to the Kubernetes API server after authentication and authorization. + +* [Using Sysctls in a Kubernetes Cluster](/docs/tasks/administer-cluster/sysctl-cluster/) describes to an administrator how to use the `sysctl` command-line tool to set kernel parameters . + +* [Auditing](/docs/tasks/debug-application-cluster/audit/) describes how to interact with Kubernetes' audit logs. + +### Securing the kubelet + * [Control Plane-Node communication](/docs/concepts/architecture/control-plane-node-communication/) + * [TLS bootstrapping](/docs/reference/command-line-tools-reference/kubelet-tls-bootstrapping/) + * [Kubelet authentication/authorization](/docs/reference/command-line-tools-reference/kubelet-authentication-authorization/) + +## Optional Cluster Services + +* [DNS Integration](/docs/concepts/services-networking/dns-pod-service/) describes how to resolve a DNS name directly to a Kubernetes service. + +* [Logging and Monitoring Cluster Activity](/docs/concepts/cluster-administration/logging/) explains how logging in Kubernetes works and how to implement it. diff --git a/content/en/docs/concepts/cluster-administration/addons.md b/content/en/docs/concepts/cluster-administration/addons.md index 5b5110ec92..d2565d1e38 100644 --- a/content/en/docs/concepts/cluster-administration/addons.md +++ b/content/en/docs/concepts/cluster-administration/addons.md @@ -5,35 +5,30 @@ content_type: concept - Add-ons extend the functionality of Kubernetes. This page lists some of the available add-ons and links to their respective installation instructions. Add-ons in each section are sorted alphabetically - the ordering does not imply any preferential status. - - - ## Networking and Network Policy - * [ACI](https://www.github.com/noironetworks/aci-containers) provides integrated container networking and network security with Cisco ACI. * [Calico](https://docs.projectcalico.org/latest/introduction/) is a networking and network policy provider. Calico supports a flexible set of networking options so you can choose the most efficient option for your situation, including non-overlay and overlay networks, with or without BGP. Calico uses the same engine to enforce network policy for hosts, pods, and (if using Istio & Envoy) applications at the service mesh layer. * [Canal](https://github.com/tigera/canal/tree/master/k8s-install) unites Flannel and Calico, providing networking and network policy. * [Cilium](https://github.com/cilium/cilium) is a L3 network and network policy plugin that can enforce HTTP/API/L7 policies transparently. Both routing and overlay/encapsulation mode are supported, and it can work on top of other CNI plugins. * [CNI-Genie](https://github.com/Huawei-PaaS/CNI-Genie) enables Kubernetes to seamlessly connect to a choice of CNI plugins, such as Calico, Canal, Flannel, Romana, or Weave. -* [Contiv](http://contiv.github.io) provides configurable networking (native L3 using BGP, overlay using vxlan, classic L2, and Cisco-SDN/ACI) for various use cases and a rich policy framework. Contiv project is fully [open sourced](http://github.com/contiv). The [installer](http://github.com/contiv/install) provides both kubeadm and non-kubeadm based installation options. -* [Contrail](http://www.juniper.net/us/en/products-services/sdn/contrail/contrail-networking/), based on [Tungsten Fabric](https://tungsten.io), is an open source, multi-cloud network virtualization and policy management platform. Contrail and Tungsten Fabric are integrated with orchestration systems such as Kubernetes, OpenShift, OpenStack and Mesos, and provide isolation modes for virtual machines, containers/pods and bare metal workloads. +* [Contiv](https://contiv.github.io) provides configurable networking (native L3 using BGP, overlay using vxlan, classic L2, and Cisco-SDN/ACI) for various use cases and a rich policy framework. Contiv project is fully [open sourced](https://github.com/contiv). The [installer](https://github.com/contiv/install) provides both kubeadm and non-kubeadm based installation options. +* [Contrail](https://www.juniper.net/us/en/products-services/sdn/contrail/contrail-networking/), based on [Tungsten Fabric](https://tungsten.io), is an open source, multi-cloud network virtualization and policy management platform. Contrail and Tungsten Fabric are integrated with orchestration systems such as Kubernetes, OpenShift, OpenStack and Mesos, and provide isolation modes for virtual machines, containers/pods and bare metal workloads. * [Flannel](https://github.com/coreos/flannel/blob/master/Documentation/kubernetes.md) is an overlay network provider that can be used with Kubernetes. * [Knitter](https://github.com/ZTE/Knitter/) is a plugin to support multiple network interfaces in a Kubernetes pod. * [Multus](https://github.com/Intel-Corp/multus-cni) is a Multi plugin for multiple network support in Kubernetes to support all CNI plugins (e.g. Calico, Cilium, Contiv, Flannel), in addition to SRIOV, DPDK, OVS-DPDK and VPP based workloads in Kubernetes. * [OVN4NFV-K8S-Plugin](https://github.com/opnfv/ovn4nfv-k8s-plugin) is OVN based CNI controller plugin to provide cloud native based Service function chaining(SFC), Multiple OVN overlay networking, dynamic subnet creation, dynamic creation of virtual networks, VLAN Provider network, Direct provider network and pluggable with other Multi-network plugins, ideal for edge based cloud native workloads in Multi-cluster networking * [NSX-T](https://docs.vmware.com/en/VMware-NSX-T/2.0/nsxt_20_ncp_kubernetes.pdf) Container Plug-in (NCP) provides integration between VMware NSX-T and container orchestrators such as Kubernetes, as well as integration between NSX-T and container-based CaaS/PaaS platforms such as Pivotal Container Service (PKS) and OpenShift. * [Nuage](https://github.com/nuagenetworks/nuage-kubernetes/blob/v5.1.1-1/docs/kubernetes-1-installation.rst) is an SDN platform that provides policy-based networking between Kubernetes Pods and non-Kubernetes environments with visibility and security monitoring. -* [Romana](http://romana.io) is a Layer 3 networking solution for pod networks that also supports the [NetworkPolicy API](/docs/concepts/services-networking/network-policies/). Kubeadm add-on installation details available [here](https://github.com/romana/romana/tree/master/containerize). +* [Romana](https://romana.io) is a Layer 3 networking solution for pod networks that also supports the [NetworkPolicy API](/docs/concepts/services-networking/network-policies/). Kubeadm add-on installation details available [here](https://github.com/romana/romana/tree/master/containerize). * [Weave Net](https://www.weave.works/docs/net/latest/kube-addon/) provides networking and network policy, will carry on working on both sides of a network partition, and does not require an external database. ## Service Discovery diff --git a/content/en/docs/concepts/cluster-administration/cloud-providers.md b/content/en/docs/concepts/cluster-administration/cloud-providers.md index 4f49e7bc42..7b10760adf 100644 --- a/content/en/docs/concepts/cluster-administration/cloud-providers.md +++ b/content/en/docs/concepts/cluster-administration/cloud-providers.md @@ -8,8 +8,6 @@ weight: 30 This page explains how to manage Kubernetes running on a specific cloud provider. - - ### kubeadm [kubeadm](/docs/reference/setup-tools/kubeadm/kubeadm/) is a popular option for creating kubernetes clusters. @@ -46,8 +44,10 @@ controllerManager: ``` The in-tree cloud providers typically need both `--cloud-provider` and `--cloud-config` specified in the command lines -for the [kube-apiserver](/docs/admin/kube-apiserver/), [kube-controller-manager](/docs/admin/kube-controller-manager/) and the -[kubelet](/docs/admin/kubelet/). The contents of the file specified in `--cloud-config` for each provider is documented below as well. +for the [kube-apiserver](/docs/reference/command-line-tools-reference/kube-apiserver/), +[kube-controller-manager](/docs/reference/command-line-tools-reference/kube-controller-manager/) and the +[kubelet](/docs/reference/command-line-tools-reference/kubelet/). +The contents of the file specified in `--cloud-config` for each provider is documented below as well. For all external cloud providers, please follow the instructions on the individual repositories, which are listed under their headings below, or one may view [the list of all repositories](https://github.com/kubernetes?q=cloud-provider-&type=&language=) @@ -94,12 +94,12 @@ Different settings can be applied to a load balancer service in AWS using _annot * `service.beta.kubernetes.io/aws-load-balancer-access-log-s3-bucket-prefix`: Used to specify access log s3 bucket prefix. * `service.beta.kubernetes.io/aws-load-balancer-additional-resource-tags`: Used on the service to specify a comma-separated list of key-value pairs which will be recorded as additional tags in the ELB. For example: `"Key1=Val1,Key2=Val2,KeyNoVal1=,KeyNoVal2"`. * `service.beta.kubernetes.io/aws-load-balancer-backend-protocol`: Used on the service to specify the protocol spoken by the backend (pod) behind a listener. If `http` (default) or `https`, an HTTPS listener that terminates the connection and parses headers is created. If set to `ssl` or `tcp`, a "raw" SSL listener is used. If set to `http` and `aws-load-balancer-ssl-cert` is not used then a HTTP listener is used. -* `service.beta.kubernetes.io/aws-load-balancer-ssl-cert`: Used on the service to request a secure listener. Value is a valid certificate ARN. For more, see [ELB Listener Config](http://docs.aws.amazon.com/ElasticLoadBalancing/latest/DeveloperGuide/elb-listener-config.html) CertARN is an IAM or CM certificate ARN, for example `arn:aws:acm:us-east-1:123456789012:certificate/12345678-1234-1234-1234-123456789012`. +* `service.beta.kubernetes.io/aws-load-balancer-ssl-cert`: Used on the service to request a secure listener. Value is a valid certificate ARN. For more, see [ELB Listener Config](https://docs.aws.amazon.com/ElasticLoadBalancing/latest/DeveloperGuide/elb-listener-config.html) CertARN is an IAM or CM certificate ARN, for example `arn:aws:acm:us-east-1:123456789012:certificate/12345678-1234-1234-1234-123456789012`. * `service.beta.kubernetes.io/aws-load-balancer-connection-draining-enabled`: Used on the service to enable or disable connection draining. * `service.beta.kubernetes.io/aws-load-balancer-connection-draining-timeout`: Used on the service to specify a connection draining timeout. * `service.beta.kubernetes.io/aws-load-balancer-connection-idle-timeout`: Used on the service to specify the idle connection timeout. * `service.beta.kubernetes.io/aws-load-balancer-cross-zone-load-balancing-enabled`: Used on the service to enable or disable cross-zone load balancing. -* `service.beta.kubernetes.io/aws-load-balancer-security-groups`: Used to specify the security groups to be added to ELB created. This replaces all other security groups previously assigned to the ELB. +* `service.beta.kubernetes.io/aws-load-balancer-security-groups`: Used to specify the security groups to be added to ELB created. This replaces all other security groups previously assigned to the ELB. Security groups defined here should not be shared between services. * `service.beta.kubernetes.io/aws-load-balancer-extra-security-groups`: Used on the service to specify additional security groups to be added to ELB created * `service.beta.kubernetes.io/aws-load-balancer-internal`: Used on the service to indicate that we want an internal ELB. * `service.beta.kubernetes.io/aws-load-balancer-proxy-protocol`: Used on the service to enable the proxy protocol on an ELB. Right now we only accept the value `*` which means enabling the proxy protocol on all ELB backends. In the future we could adjust this to allow setting the proxy protocol only on certain backends. @@ -358,13 +358,10 @@ Kubernetes network plugin and should appear in the `[Route]` section of the the `extraroutes` extension then use `router-id` to specify a router to add routes to. The router chosen must span the private networks containing your cluster nodes (typically there is only one node network, and this value should be - the default router for the node network). This value is required to use [kubenet] + the default router for the node network). This value is required to use + [kubenet](/docs/concepts/cluster-administration/network-plugins/#kubenet) on OpenStack. -[kubenet]: /docs/concepts/cluster-administration/network-plugins/#kubenet - - - ## OVirt ### Node Name @@ -433,4 +430,4 @@ Alibaba Cloud does not require the format of node name, but the kubelet needs to ### Load Balancers -You can setup external load balancers to use specific features in Alibaba Cloud by configuring the [annotations](https://www.alibabacloud.com/help/en/doc-detail/86531.htm) . \ No newline at end of file +You can setup external load balancers to use specific features in Alibaba Cloud by configuring the [annotations](https://www.alibabacloud.com/help/en/doc-detail/86531.htm) . diff --git a/content/en/docs/concepts/cluster-administration/cluster-administration-overview.md b/content/en/docs/concepts/cluster-administration/cluster-administration-overview.md deleted file mode 100644 index fc2f55fbcd..0000000000 --- a/content/en/docs/concepts/cluster-administration/cluster-administration-overview.md +++ /dev/null @@ -1,73 +0,0 @@ ---- -reviewers: -- davidopp -- lavalamp -title: Cluster Administration Overview -content_type: concept -weight: 10 ---- - - -The cluster administration overview is for anyone creating or administering a Kubernetes cluster. -It assumes some familiarity with core Kubernetes [concepts](/docs/concepts/). - - - -## Planning a cluster - -See the guides in [Setup](/docs/setup/) for examples of how to plan, set up, and configure Kubernetes clusters. The solutions listed in this article are called *distros*. - -Before choosing a guide, here are some considerations: - - - Do you just want to try out Kubernetes on your computer, or do you want to build a high-availability, multi-node cluster? Choose distros best suited for your needs. - - Will you be using **a hosted Kubernetes cluster**, such as [Google Kubernetes Engine](https://cloud.google.com/kubernetes-engine/), or **hosting your own cluster**? - - Will your cluster be **on-premises**, or **in the cloud (IaaS)**? Kubernetes does not directly support hybrid clusters. Instead, you can set up multiple clusters. - - **If you are configuring Kubernetes on-premises**, consider which [networking model](/docs/concepts/cluster-administration/networking/) fits best. - - Will you be running Kubernetes on **"bare metal" hardware** or on **virtual machines (VMs)**? - - Do you **just want to run a cluster**, or do you expect to do **active development of Kubernetes project code**? If the - latter, choose an actively-developed distro. Some distros only use binary releases, but - offer a greater variety of choices. - - Familiarize yourself with the [components](/docs/admin/cluster-components/) needed to run a cluster. - -Note: Not all distros are actively maintained. Choose distros which have been tested with a recent version of Kubernetes. - -## Managing a cluster - -* [Managing a cluster](/docs/tasks/administer-cluster/cluster-management/) describes several topics related to the lifecycle of a cluster: creating a new cluster, upgrading your cluster’s master and worker nodes, performing node maintenance (e.g. kernel upgrades), and upgrading the Kubernetes API version of a running cluster. - -* Learn how to [manage nodes](/docs/concepts/nodes/node/). - -* Learn how to set up and manage the [resource quota](/docs/concepts/policy/resource-quotas/) for shared clusters. - -## Securing a cluster - -* [Certificates](/docs/concepts/cluster-administration/certificates/) describes the steps to generate certificates using different tool chains. - -* [Kubernetes Container Environment](/docs/concepts/containers/container-environment/) describes the environment for Kubelet managed containers on a Kubernetes node. - -* [Controlling Access to the Kubernetes API](/docs/reference/access-authn-authz/controlling-access/) describes how to set up permissions for users and service accounts. - -* [Authenticating](/docs/reference/access-authn-authz/authentication/) explains authentication in Kubernetes, including the various authentication options. - -* [Authorization](/docs/reference/access-authn-authz/authorization/) is separate from authentication, and controls how HTTP calls are handled. - -* [Using Admission Controllers](/docs/reference/access-authn-authz/admission-controllers/) explains plug-ins which intercepts requests to the Kubernetes API server after authentication and authorization. - -* [Using Sysctls in a Kubernetes Cluster](/docs/concepts/cluster-administration/sysctl-cluster/) describes to an administrator how to use the `sysctl` command-line tool to set kernel parameters . - -* [Auditing](/docs/tasks/debug-application-cluster/audit/) describes how to interact with Kubernetes' audit logs. - -### Securing the kubelet - * [Master-Node communication](/docs/concepts/architecture/master-node-communication/) - * [TLS bootstrapping](/docs/reference/command-line-tools-reference/kubelet-tls-bootstrapping/) - * [Kubelet authentication/authorization](/docs/admin/kubelet-authentication-authorization/) - -## Optional Cluster Services - -* [DNS Integration](/docs/concepts/services-networking/dns-pod-service/) describes how to resolve a DNS name directly to a Kubernetes service. - -* [Logging and Monitoring Cluster Activity](/docs/concepts/cluster-administration/logging/) explains how logging in Kubernetes works and how to implement it. - - - - diff --git a/content/en/docs/concepts/cluster-administration/flow-control.md b/content/en/docs/concepts/cluster-administration/flow-control.md index 26fc1194df..2d2abb7b26 100644 --- a/content/en/docs/concepts/cluster-administration/flow-control.md +++ b/content/en/docs/concepts/cluster-administration/flow-control.md @@ -162,6 +162,31 @@ are built in and may not be overwritten: that only matches the `catch-all` FlowSchema will be rejected with an HTTP 429 error. +## Health check concurrency exemption + +The suggested configuration gives no special treatment to the health +check requests on kube-apiservers from their local kubelets --- which +tend to use the secured port but supply no credentials. With the +suggested config, these requests get assigned to the `global-default` +FlowSchema and the corresponding `global-default` priority level, +where other traffic can crowd them out. + +If you add the following additional FlowSchema, this exempts those +requests from rate limiting. + +{{< caution >}} + +Making this change also allows any hostile party to then send +health-check requests that match this FlowSchema, at any volume they +like. If you have a web traffic filter or similar external security +mechanism to protect your cluster's API server from general internet +traffic, you can configure rules to block any health check requests +that originate from outside your cluster. + +{{< /caution >}} + +{{< codenew file="priority-and-fairness/health-for-strangers.yaml" >}} + ## Resources The flow control API involves two kinds of resources. [PriorityLevelConfigurations](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#prioritylevelconfiguration-v1alpha1-flowcontrol-apiserver-k8s-io) @@ -303,15 +328,20 @@ to get a mapping of UIDs to names for both FlowSchemas and PriorityLevelConfigurations. ## Observability + +### Metrics + When you enable the API Priority and Fairness feature, the kube-apiserver exports additional metrics. Monitoring these can help you determine whether your configuration is inappropriately throttling important traffic, or find poorly-behaved workloads that may be harming system health. -* `apiserver_flowcontrol_rejected_requests_total` counts requests that - were rejected, grouped by the name of the assigned priority level, - the name of the assigned FlowSchema, and the reason for rejection. - The reason will be one of the following: +* `apiserver_flowcontrol_rejected_requests_total` is a counter vector + (cumulative since server start) of requests that were rejected, + broken down by the labels `flowSchema` (indicating the one that + matched the request), `priorityLevel` (indicating the one to which + the request was assigned), and `reason`. The `reason` label will be + have one of the following values: * `queue-full`, indicating that too many requests were already queued, * `concurrency-limit`, indicating that the @@ -320,23 +350,72 @@ poorly-behaved workloads that may be harming system health. * `time-out`, indicating that the request was still in the queue when its queuing time limit expired. -* `apiserver_flowcontrol_dispatched_requests_total` counts requests - that began executing, grouped by the name of the assigned priority - level and the name of the assigned FlowSchema. +* `apiserver_flowcontrol_dispatched_requests_total` is a counter + vector (cumulative since server start) of requests that began + executing, broken down by the labels `flowSchema` (indicating the + one that matched the request) and `priorityLevel` (indicating the + one to which the request was assigned). -* `apiserver_flowcontrol_current_inqueue_requests` gives the - instantaneous total number of queued (not executing) requests, - grouped by priority level and FlowSchema. +* `apiserver_current_inqueue_requests` is a gauge vector of recent + high water marks of the number of queued requests, grouped by a + label named `request_kind` whose value is `mutating` or `readOnly`. + These high water marks describe the largest number seen in the one + second window most recently completed. These complement the older + `apiserver_current_inflight_requests` gauge vector that holds the + last window's high water mark of number of requests actively being + served. -* `apiserver_flowcontrol_current_executing_requests` gives the instantaneous - total number of executing requests, grouped by priority level and FlowSchema. +* `apiserver_flowcontrol_read_vs_write_request_count_samples` is a + histogram vector of observations of the then-current number of + requests, broken down by the labels `phase` (which takes on the + values `waiting` and `executing`) and `request_kind` (which takes on + the values `mutating` and `readOnly`). The observations are made + periodically at a high rate. -* `apiserver_flowcontrol_request_queue_length_after_enqueue` gives a - histogram of queue lengths for the queues, grouped by priority level - and FlowSchema, as sampled by the enqueued requests. Each request - that gets queued contributes one sample to its histogram, reporting - the length of the queue just after the request was added. Note that - this produces different statistics than an unbiased survey would. +* `apiserver_flowcontrol_read_vs_write_request_count_watermarks` is a + histogram vector of high or low water marks of the number of + requests broken down by the labels `phase` (which takes on the + values `waiting` and `executing`) and `request_kind` (which takes on + the values `mutating` and `readOnly`); the label `mark` takes on + values `high` and `low`. The water marks are accumulated over + windows bounded by the times when an observation was added to + `apiserver_flowcontrol_read_vs_write_request_count_samples`. These + water marks show the range of values that occurred between samples. + +* `apiserver_flowcontrol_current_inqueue_requests` is a gauge vector + holding the instantaneous number of queued (not executing) requests, + broken down by the labels `priorityLevel` and `flowSchema`. + +* `apiserver_flowcontrol_current_executing_requests` is a gauge vector + holding the instantaneous number of executing (not waiting in a + queue) requests, broken down by the labels `priorityLevel` and + `flowSchema`. + +* `apiserver_flowcontrol_priority_level_request_count_samples` is a + histogram vector of observations of the then-current number of + requests broken down by the labels `phase` (which takes on the + values `waiting` and `executing`) and `priorityLevel`. Each + histogram gets observations taken periodically, up through the last + activity of the relevant sort. The observations are made at a high + rate. + +* `apiserver_flowcontrol_priority_level_request_count_watermarks` is a + histogram vector of high or low water marks of the number of + requests broken down by the labels `phase` (which takes on the + values `waiting` and `executing`) and `priorityLevel`; the label + `mark` takes on values `high` and `low`. The water marks are + accumulated over windows bounded by the times when an observation + was added to + `apiserver_flowcontrol_priority_level_request_count_samples`. These + water marks show the range of values that occurred between samples. + +* `apiserver_flowcontrol_request_queue_length_after_enqueue` is a + histogram vector of queue lengths for the queues, broken down by + the labels `priorityLevel` and `flowSchema`, as sampled by the + enqueued requests. Each request that gets queued contributes one + sample to its histogram, reporting the length of the queue just + after the request was added. Note that this produces different + statistics than an unbiased survey would. {{< note >}} An outlier value in a histogram here means it is likely that a single flow (i.e., requests by one user or for one namespace, depending on @@ -346,14 +425,17 @@ poorly-behaved workloads that may be harming system health. to increase that PriorityLevelConfiguration's concurrency shares. {{< /note >}} -* `apiserver_flowcontrol_request_concurrency_limit` gives the computed - concurrency limit (based on the API server's total concurrency limit and PriorityLevelConfigurations' - concurrency shares) for each PriorityLevelConfiguration. +* `apiserver_flowcontrol_request_concurrency_limit` is a gauge vector + hoding the computed concurrency limit (based on the API server's + total concurrency limit and PriorityLevelConfigurations' concurrency + shares), broken down by the label `priorityLevel`. -* `apiserver_flowcontrol_request_wait_duration_seconds` gives a histogram of how - long requests spent queued, grouped by the FlowSchema that matched the - request, the PriorityLevel to which it was assigned, and whether or not the - request successfully executed. +* `apiserver_flowcontrol_request_wait_duration_seconds` is a histogram + vector of how long requests spent queued, broken down by the labels + `flowSchema` (indicating which one matched the request), + `priorityLevel` (indicating the one to which the request was + assigned), and `execute` (indicating whether the request started + executing). {{< note >}} Since each FlowSchema always assigns requests to a single PriorityLevelConfiguration, you can add the histograms for all the @@ -361,13 +443,71 @@ poorly-behaved workloads that may be harming system health. requests assigned to that priority level. {{< /note >}} -* `apiserver_flowcontrol_request_execution_seconds` gives a histogram of how - long requests took to actually execute, grouped by the FlowSchema that matched the - request and the PriorityLevel to which it was assigned. +* `apiserver_flowcontrol_request_execution_seconds` is a histogram + vector of how long requests took to actually execute, broken down by + the labels `flowSchema` (indicating which one matched the request) + and `priorityLevel` (indicating the one to which the request was + assigned). +### Debug endpoints +When you enable the API Priority and Fairness feature, the kube-apiserver serves the following additional paths at its HTTP[S] ports. +- `/debug/api_priority_and_fairness/dump_priority_levels` - a listing of all the priority levels and the current state of each. You can fetch like this: + ```shell + kubectl get --raw /debug/api_priority_and_fairness/dump_priority_levels + ``` + The output is similar to this: + ``` + PriorityLevelName, ActiveQueues, IsIdle, IsQuiescing, WaitingRequests, ExecutingRequests, + workload-low, 0, true, false, 0, 0, + global-default, 0, true, false, 0, 0, + exempt, , , , , , + catch-all, 0, true, false, 0, 0, + system, 0, true, false, 0, 0, + leader-election, 0, true, false, 0, 0, + workload-high, 0, true, false, 0, 0, + ``` +- `/debug/api_priority_and_fairness/dump_queues` - a listing of all the queues and their current state. You can fetch like this: + ```shell + kubectl get --raw /debug/api_priority_and_fairness/dump_queues + ``` + The output is similar to this: + ``` + PriorityLevelName, Index, PendingRequests, ExecutingRequests, VirtualStart, + workload-high, 0, 0, 0, 0.0000, + workload-high, 1, 0, 0, 0.0000, + workload-high, 2, 0, 0, 0.0000, + ... + leader-election, 14, 0, 0, 0.0000, + leader-election, 15, 0, 0, 0.0000, + ``` + +- `/debug/api_priority_and_fairness/dump_requests` - a listing of all the requests that are currently waiting in a queue. You can fetch like this: + ```shell + kubectl get --raw /debug/api_priority_and_fairness/dump_requests + ``` + The output is similar to this: + ``` + PriorityLevelName, FlowSchemaName, QueueIndex, RequestIndexInQueue, FlowDistingsher, ArriveTime, + exempt, , , , , , + system, system-nodes, 12, 0, system:node:127.0.0.1, 2020-07-23T15:26:57.179170694Z, + ``` + + In addition to the queued requests, the output includeas one phantom line for each priority level that is exempt from limitation. + + You can get a more detailed listing with a command like this: + ```shell + kubectl get --raw '/debug/api_priority_and_fairness/dump_requests?includeRequestDetails=1' + ``` + The output is similar to this: + ``` + PriorityLevelName, FlowSchemaName, QueueIndex, RequestIndexInQueue, FlowDistingsher, ArriveTime, UserName, Verb, APIPath, Namespace, Name, APIVersion, Resource, SubResource, + system, system-nodes, 12, 0, system:node:127.0.0.1, 2020-07-23T15:31:03.583823404Z, system:node:127.0.0.1, create, /api/v1/namespaces/scaletest/configmaps, + system, system-nodes, 12, 1, system:node:127.0.0.1, 2020-07-23T15:31:03.594555947Z, system:node:127.0.0.1, create, /api/v1/namespaces/scaletest/configmaps, + ``` + ## {{% heading "whatsnext" %}} diff --git a/content/en/docs/concepts/cluster-administration/logging.md b/content/en/docs/concepts/cluster-administration/logging.md index 399f8f16cc..c71013081b 100644 --- a/content/en/docs/concepts/cluster-administration/logging.md +++ b/content/en/docs/concepts/cluster-administration/logging.md @@ -13,9 +13,6 @@ Application and systems logs can help you understand what is happening inside yo However, the native functionality provided by a container engine or runtime is usually not enough for a complete logging solution. For example, if a container crashes, a pod is evicted, or a node dies, you'll usually still want to access your application's logs. As such, logs should have a separate storage and lifecycle independent of nodes, pods, or containers. This concept is called _cluster-level-logging_. Cluster-level logging requires a separate backend to store, analyze, and query logs. Kubernetes provides no native storage solution for log data, but you can integrate many existing logging solutions into your Kubernetes cluster. - - - Cluster-level logging architectures are described in assumption that @@ -82,7 +79,8 @@ and the former approach is used in any other environment. In both cases, by default rotation is configured to take place when log file exceeds 10MB. As an example, you can find detailed information about how `kube-up.sh` sets -up logging for COS image on GCP in the corresponding [script][cosConfigureHelper]. +up logging for COS image on GCP in the corresponding +[script](https://github.com/kubernetes/kubernetes/blob/{{< param "githubbranch" >}}/cluster/gce/gci/configure-helper.sh) When you run [`kubectl logs`](/docs/reference/generated/kubectl/kubectl-commands#logs) as in the basic logging example, the kubelet on the node handles the request and @@ -96,8 +94,6 @@ the rotation and there are two files, one 10MB in size and one empty, `kubectl logs` will return an empty response. {{< /note >}} -[cosConfigureHelper]: https://github.com/kubernetes/kubernetes/blob/{{< param "githubbranch" >}}/cluster/gce/gci/configure-helper.sh - ### System component logs There are two types of system components: those that run in a container and those @@ -109,7 +105,7 @@ that do not run in a container. For example: On machines with systemd, the kubelet and container runtime write to journald. If systemd is not present, they write to `.log` files in the `/var/log` directory. System components inside containers always write to the `/var/log` directory, -bypassing the default logging mechanism. They use the [klog][klog] +bypassing the default logging mechanism. They use the [klog](https://github.com/kubernetes/klog) logging library. You can find the conventions for logging severity for those components in the [development docs on logging](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-instrumentation/logging.md). @@ -118,8 +114,6 @@ directory should be rotated. In Kubernetes clusters brought up by the `kube-up.sh` script, those logs are configured to be rotated by the `logrotate` tool daily or once the size exceeds 100MB. -[klog]: https://github.com/kubernetes/klog - ## Cluster-level logging architectures While Kubernetes does not provide a native solution for cluster-level logging, there are several common approaches you can consider. Here are some options: @@ -138,7 +132,7 @@ Because the logging agent must run on every node, it's common to implement it as Using a node-level logging agent is the most common and encouraged approach for a Kubernetes cluster, because it creates only one agent per node, and it doesn't require any changes to the applications running on the node. However, node-level logging _only works for applications' standard output and standard error_. -Kubernetes doesn't specify a logging agent, but two optional logging agents are packaged with the Kubernetes release: [Stackdriver Logging](/docs/user-guide/logging/stackdriver) for use with Google Cloud Platform, and [Elasticsearch](/docs/user-guide/logging/elasticsearch). You can find more information and instructions in the dedicated documents. Both use [fluentd](http://www.fluentd.org/) with custom configuration as an agent on the node. +Kubernetes doesn't specify a logging agent, but two optional logging agents are packaged with the Kubernetes release: [Stackdriver Logging](/docs/tasks/debug-application-cluster/logging-stackdriver/) for use with Google Cloud Platform, and [Elasticsearch](/docs/tasks/debug-application-cluster/logging-elasticsearch-kibana/). You can find more information and instructions in the dedicated documents. Both use [fluentd](https://www.fluentd.org/) with custom configuration as an agent on the node. ### Using a sidecar container with the logging agent @@ -245,7 +239,7 @@ a [ConfigMap](/docs/tasks/configure-pod-container/configure-pod-configmap/) to c {{< note >}} The configuration of fluentd is beyond the scope of this article. For information about configuring fluentd, see the -[official fluentd documentation](http://docs.fluentd.org/). +[official fluentd documentation](https://docs.fluentd.org/). {{< /note >}} The second file describes a pod that has a sidecar container running fluentd. diff --git a/content/en/docs/concepts/cluster-administration/manage-deployment.md b/content/en/docs/concepts/cluster-administration/manage-deployment.md index b052dd3a15..50ed69ff42 100644 --- a/content/en/docs/concepts/cluster-administration/manage-deployment.md +++ b/content/en/docs/concepts/cluster-administration/manage-deployment.md @@ -10,9 +10,6 @@ weight: 40 You've deployed your application and exposed it via a service. Now what? Kubernetes provides a number of tools to help you manage your application deployment, including scaling and updating. Among the features that we will discuss in more depth are [configuration files](/docs/concepts/configuration/overview/) and [labels](/docs/concepts/overview/working-with-objects/labels/). - - - ## Organizing resource configurations @@ -323,7 +320,7 @@ When load on your application grows or shrinks, it's easy to scale with `kubectl kubectl scale deployment/my-nginx --replicas=1 ``` ```shell -deployment.extensions/my-nginx scaled +deployment.apps/my-nginx scaled ``` Now you only have one pod managed by the deployment. @@ -356,7 +353,8 @@ Sometimes it's necessary to make narrow, non-disruptive updates to resources you ### kubectl apply -It is suggested to maintain a set of configuration files in source control (see [configuration as code](http://martinfowler.com/bliki/InfrastructureAsCode.html)), +It is suggested to maintain a set of configuration files in source control +(see [configuration as code](https://martinfowler.com/bliki/InfrastructureAsCode.html)), so that they can be maintained and versioned along with the code for the resources they configure. Then, you can use [`kubectl apply`](/docs/reference/generated/kubectl/kubectl-commands/#apply) to push your configuration changes to the cluster. diff --git a/content/en/docs/concepts/cluster-administration/monitoring.md b/content/en/docs/concepts/cluster-administration/monitoring.md index fbea5e69c1..cd6069d229 100644 --- a/content/en/docs/concepts/cluster-administration/monitoring.md +++ b/content/en/docs/concepts/cluster-administration/monitoring.md @@ -40,14 +40,14 @@ Note that {{< glossary_tooltip term_id="kubelet" text="kubelet" >}} also exposes 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: ``` -apiVersion: rbac.authorization.k8s.io/v1 -kind: ClusterRole -metadata: - name: prometheus -rules: - - nonResourceURLs: - - "/metrics" - verbs: +apiVersion: rbac.authorization.k8s.io/v1 +kind: ClusterRole +metadata: + name: prometheus +rules: + - nonResourceURLs: + - "/metrics" + verbs: - get ``` @@ -130,5 +130,4 @@ cloudprovider_gce_api_request_duration_seconds { request = "list_disk"} * 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](https://kubernetes.io/docs/reference/using-api/deprecation-policy/#deprecating-a-feature-or-behavior ) - +* Read about the [Kubernetes deprecation policy](/docs/reference/using-api/deprecation-policy/#deprecating-a-feature-or-behavior) diff --git a/content/en/docs/concepts/cluster-administration/networking.md b/content/en/docs/concepts/cluster-administration/networking.md index 29044be250..ff30e60b12 100644 --- a/content/en/docs/concepts/cluster-administration/networking.md +++ b/content/en/docs/concepts/cluster-administration/networking.md @@ -12,14 +12,11 @@ understand exactly how it is expected to work. There are 4 distinct networking problems to address: 1. Highly-coupled container-to-container communications: this is solved by - [pods](/docs/concepts/workloads/pods/pod/) and `localhost` communications. + {{< glossary_tooltip text="Pods" term_id="pod" >}} and `localhost` communications. 2. Pod-to-Pod communications: this is the primary focus of this document. 3. Pod-to-Service communications: this is covered by [services](/docs/concepts/services-networking/service/). 4. External-to-Service communications: this is covered by [services](/docs/concepts/services-networking/service/). - - - Kubernetes is all about sharing machines between applications. Typically, @@ -93,7 +90,7 @@ Thanks to the "programmable" characteristic of Open vSwitch, Antrea is able to i ### AOS from Apstra -[AOS](http://www.apstra.com/products/aos/) is an Intent-Based Networking system that creates and manages complex datacenter environments from a simple integrated platform. AOS leverages a highly scalable distributed design to eliminate network outages while minimizing costs. +[AOS](https://www.apstra.com/products/aos/) is an Intent-Based Networking system that creates and manages complex datacenter environments from a simple integrated platform. AOS leverages a highly scalable distributed design to eliminate network outages while minimizing costs. The AOS Reference Design currently supports Layer-3 connected hosts that eliminate legacy Layer-2 switching problems. These Layer-3 hosts can be Linux servers (Debian, Ubuntu, CentOS) that create BGP neighbor relationships directly with the top of rack switches (TORs). AOS automates the routing adjacencies and then provides fine grained control over the route health injections (RHI) that are common in a Kubernetes deployment. @@ -101,7 +98,7 @@ AOS has a rich set of REST API endpoints that enable Kubernetes to quickly chang AOS supports the use of common vendor equipment from manufacturers including Cisco, Arista, Dell, Mellanox, HPE, and a large number of white-box systems and open network operating systems like Microsoft SONiC, Dell OPX, and Cumulus Linux. -Details on how the AOS system works can be accessed here: http://www.apstra.com/products/how-it-works/ +Details on how the AOS system works can be accessed here: https://www.apstra.com/products/how-it-works/ ### AWS VPC CNI for Kubernetes @@ -123,7 +120,7 @@ Azure CNI is available natively in the [Azure Kubernetes Service (AKS)] (https:/ With the help of the Big Cloud Fabric's virtual pod multi-tenant architecture, container orchestration systems such as Kubernetes, RedHat OpenShift, Mesosphere DC/OS & Docker Swarm will be natively integrated alongside with VM orchestration systems such as VMware, OpenStack & Nutanix. Customers will be able to securely inter-connect any number of these clusters and enable inter-tenant communication between them if needed. -BCF was recognized by Gartner as a visionary in the latest [Magic Quadrant](http://go.bigswitch.com/17GatedDocuments-MagicQuadrantforDataCenterNetworking_Reg.html). One of the BCF Kubernetes on-premises deployments (which includes Kubernetes, DC/OS & VMware running on multiple DCs across different geographic regions) is also referenced [here](https://portworx.com/architects-corner-kubernetes-satya-komala-nio/). +BCF was recognized by Gartner as a visionary in the latest [Magic Quadrant](https://go.bigswitch.com/17GatedDocuments-MagicQuadrantforDataCenterNetworking_Reg.html). One of the BCF Kubernetes on-premises deployments (which includes Kubernetes, DC/OS & VMware running on multiple DCs across different geographic regions) is also referenced [here](https://portworx.com/architects-corner-kubernetes-satya-komala-nio/). ### Cilium @@ -135,7 +132,7 @@ addressing, and it can be used in combination with other CNI plugins. ### CNI-Genie from Huawei -[CNI-Genie](https://github.com/Huawei-PaaS/CNI-Genie) is a CNI plugin that enables Kubernetes to [simultaneously have access to different implementations](https://github.com/Huawei-PaaS/CNI-Genie/blob/master/docs/multiple-cni-plugins/README.md#what-cni-genie-feature-1-multiple-cni-plugins-enables) of the [Kubernetes network model](https://github.com/kubernetes/website/blob/master/content/en/docs/concepts/cluster-administration/networking.md#the-kubernetes-network-model) in runtime. This includes any implementation that runs as a [CNI plugin](https://github.com/containernetworking/cni#3rd-party-plugins), such as [Flannel](https://github.com/coreos/flannel#flannel), [Calico](http://docs.projectcalico.org/), [Romana](http://romana.io), [Weave-net](https://www.weave.works/products/weave-net/). +[CNI-Genie](https://github.com/Huawei-PaaS/CNI-Genie) is a CNI plugin that enables Kubernetes to [simultaneously have access to different implementations](https://github.com/Huawei-PaaS/CNI-Genie/blob/master/docs/multiple-cni-plugins/README.md#what-cni-genie-feature-1-multiple-cni-plugins-enables) of the [Kubernetes network model](/docs/concepts/cluster-administration/networking/#the-kubernetes-network-model) in runtime. This includes any implementation that runs as a [CNI plugin](https://github.com/containernetworking/cni#3rd-party-plugins), such as [Flannel](https://github.com/coreos/flannel#flannel), [Calico](https://docs.projectcalico.org/), [Romana](https://romana.io), [Weave-net](https://www.weave.works/products/weave-net/). CNI-Genie also supports [assigning multiple IP addresses to a pod](https://github.com/Huawei-PaaS/CNI-Genie/blob/master/docs/multiple-ips/README.md#feature-2-extension-cni-genie-multiple-ip-addresses-per-pod), each from a different CNI plugin. @@ -157,11 +154,11 @@ network complexity required to deploy Kubernetes at scale within AWS. ### Contiv -[Contiv](https://github.com/contiv/netplugin) provides configurable networking (native l3 using BGP, overlay using vxlan, classic l2, or Cisco-SDN/ACI) for various use cases. [Contiv](http://contiv.io) is all open sourced. +[Contiv](https://github.com/contiv/netplugin) provides configurable networking (native l3 using BGP, overlay using vxlan, classic l2, or Cisco-SDN/ACI) for various use cases. [Contiv](https://contiv.io) is all open sourced. ### Contrail / Tungsten Fabric -[Contrail](http://www.juniper.net/us/en/products-services/sdn/contrail/contrail-networking/), based on [Tungsten Fabric](https://tungsten.io), is a truly open, multi-cloud network virtualization and policy management platform. Contrail and Tungsten Fabric are integrated with various orchestration systems such as Kubernetes, OpenShift, OpenStack and Mesos, and provide different isolation modes for virtual machines, containers/pods and bare metal workloads. +[Contrail](https://www.juniper.net/us/en/products-services/sdn/contrail/contrail-networking/), based on [Tungsten Fabric](https://tungsten.io), is a truly open, multi-cloud network virtualization and policy management platform. Contrail and Tungsten Fabric are integrated with various orchestration systems such as Kubernetes, OpenShift, OpenStack and Mesos, and provide different isolation modes for virtual machines, containers/pods and bare metal workloads. ### DANM @@ -242,7 +239,7 @@ traffic to the internet. ### Kube-router -[Kube-router](https://github.com/cloudnativelabs/kube-router) is a purpose-built networking solution for Kubernetes that aims to provide high performance and operational simplicity. Kube-router provides a Linux [LVS/IPVS](http://www.linuxvirtualserver.org/software/ipvs.html)-based service proxy, a Linux kernel forwarding-based pod-to-pod networking solution with no overlays, and iptables/ipset-based network policy enforcer. +[Kube-router](https://github.com/cloudnativelabs/kube-router) is a purpose-built networking solution for Kubernetes that aims to provide high performance and operational simplicity. Kube-router provides a Linux [LVS/IPVS](https://www.linuxvirtualserver.org/software/ipvs.html)-based service proxy, a Linux kernel forwarding-based pod-to-pod networking solution with no overlays, and iptables/ipset-based network policy enforcer. ### L2 networks and linux bridging @@ -252,8 +249,8 @@ Note that these instructions have only been tried very casually - it seems to work, but has not been thoroughly tested. If you use this technique and perfect the process, please let us know. -Follow the "With Linux Bridge devices" section of [this very nice -tutorial](http://blog.oddbit.com/2014/08/11/four-ways-to-connect-a-docker/) from +Follow the "With Linux Bridge devices" section of +[this very nice tutorial](https://blog.oddbit.com/2014/08/11/four-ways-to-connect-a-docker/) from Lars Kellogg-Stedman. ### Multus (a Multi Network plugin) @@ -274,7 +271,7 @@ Multus supports all [reference plugins](https://github.com/containernetworking/p ### Nuage Networks VCS (Virtualized Cloud Services) -[Nuage](http://www.nuagenetworks.net) provides a highly scalable policy-based Software-Defined Networking (SDN) platform. Nuage uses the open source Open vSwitch for the data plane along with a feature rich SDN Controller built on open standards. +[Nuage](https://www.nuagenetworks.net) provides a highly scalable policy-based Software-Defined Networking (SDN) platform. Nuage uses the open source Open vSwitch for the data plane along with a feature rich SDN Controller built on open standards. The Nuage platform uses overlays to provide seamless policy-based networking between Kubernetes Pods and non-Kubernetes environments (VMs and bare metal servers). Nuage's policy abstraction model is designed with applications in mind and makes it easy to declare fine-grained policies for applications.The platform's real-time analytics engine enables visibility and security monitoring for Kubernetes applications. @@ -294,7 +291,7 @@ at [ovn-kubernetes](https://github.com/openvswitch/ovn-kubernetes). ### Project Calico -[Project Calico](http://docs.projectcalico.org/) is an open source container networking provider and network policy engine. +[Project Calico](https://docs.projectcalico.org/) is an open source container networking provider and network policy engine. Calico provides a highly scalable networking and network policy solution for connecting Kubernetes pods based on the same IP networking principles as the internet, for both Linux (open source) and Windows (proprietary - available from [Tigera](https://www.tigera.io/essentials/)). Calico can be deployed without encapsulation or overlays to provide high-performance, high-scale data center networking. Calico also provides fine-grained, intent based network security policy for Kubernetes pods via its distributed firewall. @@ -302,7 +299,7 @@ Calico can also be run in policy enforcement mode in conjunction with other netw ### Romana -[Romana](http://romana.io) is an open source network and security automation solution that lets you deploy Kubernetes without an overlay network. Romana supports Kubernetes [Network Policy](/docs/concepts/services-networking/network-policies/) to provide isolation across network namespaces. +[Romana](https://romana.io) is an open source network and security automation solution that lets you deploy Kubernetes without an overlay network. Romana supports Kubernetes [Network Policy](/docs/concepts/services-networking/network-policies/) to provide isolation across network namespaces. ### Weave Net from Weaveworks @@ -312,13 +309,9 @@ Weave Net runs as a [CNI plug-in](https://www.weave.works/docs/net/latest/cni-pl or stand-alone. In either version, it doesn't require any configuration or extra code to run, and in both cases, the network provides one IP address per pod - as is standard for Kubernetes. - - ## {{% heading "whatsnext" %}} - The early design of the networking model and its rationale, and some future -plans are described in more detail in the [networking design -document](https://git.k8s.io/community/contributors/design-proposals/network/networking.md). - +plans are described in more detail in the +[networking design document](https://git.k8s.io/community/contributors/design-proposals/network/networking.md). diff --git a/content/en/docs/concepts/configuration/_index.md b/content/en/docs/concepts/configuration/_index.md index 1635c2a5bf..2ed10d601d 100755 --- a/content/en/docs/concepts/configuration/_index.md +++ b/content/en/docs/concepts/configuration/_index.md @@ -1,5 +1,7 @@ --- title: "Configuration" weight: 80 +description: > + Resources that Kubernetes provides for configuring Pods. --- diff --git a/content/en/docs/concepts/configuration/configmap.md b/content/en/docs/concepts/configuration/configmap.md index 1c1a24106e..d7d2feb9d5 100644 --- a/content/en/docs/concepts/configuration/configmap.md +++ b/content/en/docs/concepts/configuration/configmap.md @@ -126,25 +126,32 @@ spec: configMap: # Provide the name of the ConfigMap you want to mount. name: game-demo + # An array of keys from the ConfigMap to create as files + items: + - key: "game.properties" + path: "game.properties" + - key: "user-interface.properties" + path: "user-interface.properties" ``` A ConfigMap doesn't differentiate between single line property values and multi-line file-like values. What matters is how Pods and other objects consume those values. + For this example, defining a volume and mounting it inside the `demo` -container as `/config` creates four files: +container as `/config` creates two files, +`/config/game.properties` and `/config/user-interface.properties`, +even though there are four keys in the ConfigMap. This is because the Pod +definition specifies an `items` array in the `volumes` section. +If you omit the `items` array entirely, every key in the ConfigMap becomes +a file with the same name as the key, and you get 4 files. -- `/config/player_initial_lives` -- `/config/ui_properties_file_name` -- `/config/game.properties` -- `/config/user-interface.properties` +## Using ConfigMaps -If you want to make sure that `/config` only contains files with a -`.properties` extension, use two different ConfigMaps, and refer to both -ConfigMaps in the `spec` for a Pod. The first ConfigMap defines -`player_initial_lives` and `ui_properties_file_name`. The second -ConfigMap defines the files that the kubelet places into `/config`. +ConfigMaps can be mounted as data volumes. ConfigMaps can also be used by other +parts of the system, without being directly exposed to the Pod. For example, +ConfigMaps can hold data that other parts of the system should use for configuration. {{< note >}} The most common way to use ConfigMaps is to configure settings for @@ -157,12 +164,6 @@ or {{< glossary_tooltip text="operators" term_id="operator-pattern" >}} that adjust their behavior based on a ConfigMap. {{< /note >}} -## Using ConfigMaps - -ConfigMaps can be mounted as data volumes. ConfigMaps can also be used by other -parts of the system, without being directly exposed to the Pod. For example, -ConfigMaps can hold data that other parts of the system should use for configuration. - ### Using ConfigMaps as files from a Pod To consume a ConfigMap in a volume in a Pod: @@ -223,7 +224,7 @@ data has the following advantages: - improves performance of your cluster by significantly reducing load on kube-apiserver, by closing watches for config maps marked as immutable. -To use this feature, enable the `ImmutableEmphemeralVolumes` +To use this feature, enable the `ImmutableEphemeralVolumes` [feature gate](/docs/reference/command-line-tools-reference/feature-gates/) and set your Secret or ConfigMap `immutable` field to `true`. For example: ```yaml diff --git a/content/en/docs/concepts/configuration/manage-resources-containers.md b/content/en/docs/concepts/configuration/manage-resources-containers.md index f8989c4a5d..c30e8d243b 100644 --- a/content/en/docs/concepts/configuration/manage-resources-containers.md +++ b/content/en/docs/concepts/configuration/manage-resources-containers.md @@ -132,11 +132,9 @@ metadata: name: frontend spec: containers: - - name: db - image: mysql + - name: app + image: images.my-company.example/app:v4 env: - - name: MYSQL_ROOT_PASSWORD - value: "password" resources: requests: memory: "64Mi" @@ -144,8 +142,8 @@ spec: limits: memory: "128Mi" cpu: "500m" - - name: wp - image: wordpress + - name: log-aggregator + image: images.my-company.example/log-aggregator:v6 resources: requests: memory: "64Mi" @@ -227,7 +225,7 @@ locally-attached writeable devices or, sometimes, by RAM. Pods use ephemeral local storage for scratch space, caching, and for logs. The kubelet can provide scratch space to Pods using local ephemeral storage to -mount [`emptyDir`](https://kubernetes.io/docs/concepts/storage/volumes/#emptydir) +mount [`emptyDir`](/docs/concepts/storage/volumes/#emptydir) {{< glossary_tooltip term_id="volume" text="volumes" >}} into containers. The kubelet also uses this kind of storage to hold @@ -330,18 +328,15 @@ metadata: name: frontend spec: containers: - - name: db - image: mysql - env: - - name: MYSQL_ROOT_PASSWORD - value: "password" + - name: app + image: images.my-company.example/app:v4 resources: requests: ephemeral-storage: "2Gi" limits: ephemeral-storage: "4Gi" - - name: wp - image: wordpress + - name: log-aggregator + image: images.my-company.example/log-aggregator:v6 resources: requests: ephemeral-storage: "2Gi" @@ -657,7 +652,7 @@ Allocated resources: (Total limits may be over 100 percent, i.e., overcommitted.) CPU Requests CPU Limits Memory Requests Memory Limits ------------ ---------- --------------- ------------- - 680m (34%) 400m (20%) 920Mi (12%) 1070Mi (14%) + 680m (34%) 400m (20%) 920Mi (11%) 1070Mi (13%) ``` In the preceding output, you can see that if a Pod requests more than 1120m @@ -757,6 +752,4 @@ You can see that the Container was terminated because of `reason:OOM Killed`, wh * Read the [ResourceRequirements](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#resourcerequirements-v1-core) API reference -* Read about [project quotas](http://xfs.org/docs/xfsdocs-xml-dev/XFS_User_Guide/tmp/en-US/html/xfs-quotas.html) in XFS - - +* Read about [project quotas](https://xfs.org/docs/xfsdocs-xml-dev/XFS_User_Guide/tmp/en-US/html/xfs-quotas.html) in XFS diff --git a/content/en/docs/concepts/configuration/overview.md b/content/en/docs/concepts/configuration/overview.md index 332bdebe28..5882ce95dc 100644 --- a/content/en/docs/concepts/configuration/overview.md +++ b/content/en/docs/concepts/configuration/overview.md @@ -73,7 +73,7 @@ A desired state of an object is described by a Deployment, and if changes to tha ## Container Images -The [imagePullPolicy](/docs/concepts/containers/images/#updating-images) and the tag of the image affect when the [kubelet](/docs/admin/kubelet/) attempts to pull the specified image. +The [imagePullPolicy](/docs/concepts/containers/images/#updating-images) and the tag of the image affect when the [kubelet](/docs/reference/command-line-tools-reference/kubelet/) attempts to pull the specified image. - `imagePullPolicy: IfNotPresent`: the image is pulled only if it is not already present locally. @@ -103,7 +103,7 @@ The caching semantics of the underlying image provider make even `imagePullPolic - Use label selectors for `get` and `delete` operations instead of specific object names. See the sections on [label selectors](/docs/concepts/overview/working-with-objects/labels/#label-selectors) and [using labels effectively](/docs/concepts/cluster-administration/manage-deployment/#using-labels-effectively). -- Use `kubectl run` and `kubectl expose` to quickly create single-container Deployments and Services. See [Use a Service to Access an Application in a Cluster](/docs/tasks/access-application-cluster/service-access-application-cluster/) for an example. +- Use `kubectl create deployment` and `kubectl expose` to quickly create single-container Deployments and Services. See [Use a Service to Access an Application in a Cluster](/docs/tasks/access-application-cluster/service-access-application-cluster/) for an example. diff --git a/content/en/docs/concepts/configuration/pod-overhead.md b/content/en/docs/concepts/configuration/pod-overhead.md index 7057383dac..5eced7954f 100644 --- a/content/en/docs/concepts/configuration/pod-overhead.md +++ b/content/en/docs/concepts/configuration/pod-overhead.md @@ -87,7 +87,7 @@ spec: memory: 100Mi ``` -At admission time the RuntimeClass [admission controller](https://kubernetes.io/docs/reference/access-authn-authz/admission-controllers/) +At admission time the RuntimeClass [admission controller](/docs/reference/access-authn-authz/admission-controllers/) updates the workload's PodSpec to include the `overhead` as described in the RuntimeClass. If the PodSpec already has this field defined, the Pod will be rejected. In the given example, since only the RuntimeClass name is specified, the admission controller mutates the Pod to include an `overhead`. @@ -195,5 +195,3 @@ from source in the meantime. * [RuntimeClass](/docs/concepts/containers/runtime-class/) * [PodOverhead Design](https://github.com/kubernetes/enhancements/blob/master/keps/sig-node/20190226-pod-overhead.md) - - diff --git a/content/en/docs/concepts/configuration/pod-priority-preemption.md b/content/en/docs/concepts/configuration/pod-priority-preemption.md index 9bfc514257..9ca93839f8 100644 --- a/content/en/docs/concepts/configuration/pod-priority-preemption.md +++ b/content/en/docs/concepts/configuration/pod-priority-preemption.md @@ -11,7 +11,7 @@ weight: 70 {{< feature-state for_k8s_version="v1.14" state="stable" >}} -[Pods](/docs/user-guide/pods) can have _priority_. Priority indicates the +[Pods](/docs/concepts/workloads/pods/pod/) can have _priority_. Priority indicates the importance of a Pod relative to other Pods. If a Pod cannot be scheduled, the scheduler tries to preempt (evict) lower priority Pods to make scheduling of the pending Pod possible. @@ -255,7 +255,7 @@ makes Pod P eligible to preempt Pods on another Node. #### Graceful termination of preemption victims When Pods are preempted, the victims get their -[graceful termination period](/docs/concepts/workloads/pods/pod/#termination-of-pods). +[graceful termination period](/docs/concepts/workloads/pods/pod-lifecycle/#pod-termination). They have that much time to finish their work and exit. If they don't, they are killed. This graceful termination period creates a time gap between the point that the scheduler preempts Pods and the time when the pending Pod (P) can be @@ -268,7 +268,7 @@ priority Pods to zero or a small number. #### PodDisruptionBudget is supported, but not guaranteed -A [Pod Disruption Budget (PDB)](/docs/concepts/workloads/pods/disruptions/) +A [PodDisruptionBudget](/docs/concepts/workloads/pods/disruptions/) (PDB) allows application owners to limit the number of Pods of a replicated application that are down simultaneously from voluntary disruptions. Kubernetes supports PDB when preempting Pods, but respecting PDB is best effort. The scheduler tries diff --git a/content/en/docs/concepts/containers/_index.md b/content/en/docs/concepts/containers/_index.md old mode 100755 new mode 100644 index ad442f3ab3..edee4eccc4 --- a/content/en/docs/concepts/containers/_index.md +++ b/content/en/docs/concepts/containers/_index.md @@ -1,5 +1,45 @@ --- -title: "Containers" +title: Containers weight: 40 +description: Technology for packaging an application along with its runtime dependencies. +reviewers: +- erictune +- thockin +content_type: concept +no_list: true --- + + +Each container that you run is repeatable; the standardization from having +dependencies included means that you get the same behavior wherever you +run it. + +Containers decouple applications from underlying host infrastructure. +This makes deployment easier in different cloud or OS environments. + + + + + + +## Container images +A [container image](/docs/concepts/containers/images/) is a ready-to-run +software package, containing everything needed to run an application: +the code and any runtime it requires, application and system libraries, +and default values for any essential settings. + +By design, a container is immutable: you cannot change the code of a +container that is already running. If you have a containerized application +and want to make changes, you need to build a new container that includes +the change, then recreate the container to start from the updated image. + +## Container runtimes + +{{< glossary_definition term_id="container-runtime" length="all" >}} + +## {{% heading "whatsnext" %}} + +* Read about [container images](/docs/concepts/containers/images/) +* Read about [Pods](/docs/concepts/workloads/pods/) + diff --git a/content/en/docs/concepts/containers/container-environment.md b/content/en/docs/concepts/containers/container-environment.md index a57ac2181a..7ec28e97b4 100644 --- a/content/en/docs/concepts/containers/container-environment.md +++ b/content/en/docs/concepts/containers/container-environment.md @@ -28,7 +28,7 @@ The Kubernetes Container environment provides several important resources to Con The *hostname* of a Container is the name of the Pod in which the Container is running. It is available through the `hostname` command or the -[`gethostname`](http://man7.org/linux/man-pages/man2/gethostname.2.html) +[`gethostname`](https://man7.org/linux/man-pages/man2/gethostname.2.html) function call in libc. The Pod name and namespace are available as environment variables through the @@ -51,7 +51,7 @@ FOO_SERVICE_PORT= ``` Services have dedicated IP addresses and are available to the Container via DNS, -if [DNS addon](http://releases.k8s.io/{{< param "githubbranch" >}}/cluster/addons/dns/) is enabled.  +if [DNS addon](https://releases.k8s.io/{{< param "githubbranch" >}}/cluster/addons/dns/) is enabled.  diff --git a/content/en/docs/concepts/containers/container-lifecycle-hooks.md b/content/en/docs/concepts/containers/container-lifecycle-hooks.md index 386e4d00bb..c8e93e93db 100644 --- a/content/en/docs/concepts/containers/container-lifecycle-hooks.md +++ b/content/en/docs/concepts/containers/container-lifecycle-hooks.md @@ -42,7 +42,7 @@ so it must complete before the call to delete the container can be sent. No parameters are passed to the handler. A more detailed description of the termination behavior can be found in -[Termination of Pods](/docs/concepts/workloads/pods/pod/#termination-of-pods). +[Termination of Pods](/docs/concepts/workloads/pods/pod-lifecycle/#pod-termination). ### Hook handler implementations diff --git a/content/en/docs/concepts/containers/images.md b/content/en/docs/concepts/containers/images.md index 402bc98bf2..e136da173a 100644 --- a/content/en/docs/concepts/containers/images.md +++ b/content/en/docs/concepts/containers/images.md @@ -10,7 +10,7 @@ weight: 10 A container image represents binary data that encapsulates an application and all its -software depencies. Container images are executable software bundles that can run +software dependencies. Container images are executable software bundles that can run standalone and that make very well defined assumptions about their runtime environment. You typically create a container image of your application and push it to a registry @@ -19,8 +19,6 @@ before referring to it in a This page provides an outline of the container image concept. - - ## Image names @@ -65,7 +63,7 @@ When `imagePullPolicy` is defined without a specific value, it is also set to `A ## Multi-architecture Images with Manifests -As well as providing binary images, a container registry can also server a [container image manifest](https://github.com/opencontainers/image-spec/blob/master/manifest.md). A manifest can reference image manifests for architecture-specific versions of an container. The idea is that you can have a name for an image (for example: `pause`, `example/mycontainer`, `kube-apiserver`) and allow different systems to fetch the right binary image for the machine architecture they are using. +As well as providing binary images, a container registry can also serve a [container image manifest](https://github.com/opencontainers/image-spec/blob/master/manifest.md). A manifest can reference image manifests for architecture-specific versions of an container. The idea is that you can have a name for an image (for example: `pause`, `example/mycontainer`, `kube-apiserver`) and allow different systems to fetch the right binary image for the machine architecture they are using. Kubernetes itself typically names container images with a suffix `-$(ARCH)`. For backward compatibility, please generate the older images with suffixes. The idea is to generate say `pause` image which has the manifest for all the arch(es) and say `pause-amd64` which is backwards compatible for older configurations or YAML files which may have hard coded the images with suffixes. @@ -91,7 +89,7 @@ These options are explaind in more detail below. ### Configuring Nodes to authenticate to a Private Registry If you run Docker on your nodes, you can configure the Docker container -runtuime to authenticate to a private container registry. +runtime to authenticate to a private container registry. This approach is suitable if you can control node configuration. @@ -129,7 +127,7 @@ example, run these on your desktop/laptop: - for example, to test this out: `for n in $nodes; do scp ~/.docker/config.json root@"$n":/var/lib/kubelet/config.json; done` {{< note >}} -For production clusers, use a configuration management tool so that you can apply this +For production clusters, use a configuration management tool so that you can apply this setting to all the nodes where you need it. {{< /note >}} @@ -261,7 +259,7 @@ EOF This needs to be done for each pod that is using a private registry. However, setting of this field can be automated by setting the imagePullSecrets -in a [ServiceAccount](/docs/user-guide/service-accounts) resource. +in a [ServiceAccount](/docs/tasks/configure-pod-container/configure-service-account/) resource. Check [Add ImagePullSecrets to a Service Account](/docs/tasks/configure-pod-container/configure-service-account/#add-imagepullsecrets-to-a-service-account) for detailed instructions. diff --git a/content/en/docs/concepts/containers/overview.md b/content/en/docs/concepts/containers/overview.md deleted file mode 100644 index 1d996b8b93..0000000000 --- a/content/en/docs/concepts/containers/overview.md +++ /dev/null @@ -1,46 +0,0 @@ ---- -reviewers: -- erictune -- thockin -title: Containers overview -content_type: concept -weight: 1 ---- - - - -Containers are a technology for packaging the (compiled) code for an -application along with the dependencies it needs at run time. Each -container that you run is repeatable; the standardization from having -dependencies included means that you get the same behavior wherever you -run it. - -Containers decouple applications from underlying host infrastructure. -This makes deployment easier in different cloud or OS environments. - - - - - - -## Container images -A [container image](/docs/concepts/containers/images/) is a ready-to-run -software package, containing everything needed to run an application: -the code and any runtime it requires, application and system libraries, -and default values for any essential settings. - -By design, a container is immutable: you cannot change the code of a -container that is already running. If you have a containerized application -and want to make changes, you need to build a new container that includes -the change, then recreate the container to start from the updated image. - -## Container runtimes - -{{< glossary_definition term_id="container-runtime" length="all" >}} - - -## {{% heading "whatsnext" %}} - -* Read about [container images](/docs/concepts/containers/images/) -* Read about [Pods](/docs/concepts/workloads/pods/) - diff --git a/content/en/docs/concepts/containers/runtime-class.md b/content/en/docs/concepts/containers/runtime-class.md index d1857f3807..8f685e35f3 100644 --- a/content/en/docs/concepts/containers/runtime-class.md +++ b/content/en/docs/concepts/containers/runtime-class.md @@ -138,9 +138,7 @@ table](https://github.com/cri-o/cri-o/blob/master/docs/crio.conf.5.md#crioruntim runtime_path = "${PATH_TO_BINARY}" ``` -See CRI-O's [config documentation][100] for more details. - -[100]: https://raw.githubusercontent.com/cri-o/cri-o/9f11d1d/docs/crio.conf.5.md +See CRI-O's [config documentation](https://raw.githubusercontent.com/cri-o/cri-o/9f11d1d/docs/crio.conf.5.md) for more details. ## Scheduling @@ -149,7 +147,8 @@ See CRI-O's [config documentation][100] for more details. As of Kubernetes v1.16, RuntimeClass includes support for heterogenous clusters through its `scheduling` fields. Through the use of these fields, you can ensure that pods running with this RuntimeClass are scheduled to nodes that support it. To use the scheduling support, you must have -the [RuntimeClass admission controller][] enabled (the default, as of 1.16). +the [RuntimeClass admission controller](/docs/reference/access-authn-authz/admission-controllers/#runtimeclass) +enabled (the default, as of 1.16). To ensure pods land on nodes supporting a specific RuntimeClass, that set of nodes should have a common label which is then selected by the `runtimeclass.scheduling.nodeSelector` field. The @@ -165,8 +164,6 @@ by each. To learn more about configuring the node selector and tolerations, see [Assigning Pods to Nodes](/docs/concepts/scheduling-eviction/assign-pod-node/). -[RuntimeClass admission controller]: /docs/reference/access-authn-authz/admission-controllers/#runtimeclass - ### Pod Overhead {{< feature-state for_k8s_version="v1.18" state="beta" >}} diff --git a/content/en/docs/concepts/example-concept-template.md b/content/en/docs/concepts/example-concept-template.md deleted file mode 100644 index adf3741f90..0000000000 --- a/content/en/docs/concepts/example-concept-template.md +++ /dev/null @@ -1,41 +0,0 @@ ---- -title: Example Concept Template -reviewers: -- chenopis -content_type: concept -toc_hide: true ---- - - - -{{< note >}} -Be sure to also [create an entry in the table of contents](/docs/home/contribute/write-new-topic/#creating-an-entry-in-the-table-of-contents) for your new document. -{{< /note >}} - -This page explains ... - - - - - -## Understanding ... - -Kubernetes provides ... - -## Using ... - -To use ... - - - -## {{% heading "whatsnext" %}} - - -**[Optional Section]** - -* Learn more about [Writing a New Topic](/docs/home/contribute/style/write-new-topic/). -* See [Page Content Types - Concept](/docs/home/contribute/style/page-concept-types/#concept). - - - - diff --git a/content/en/docs/concepts/extend-kubernetes/_index.md b/content/en/docs/concepts/extend-kubernetes/_index.md index 93d955441d..4ffb0a831f 100644 --- a/content/en/docs/concepts/extend-kubernetes/_index.md +++ b/content/en/docs/concepts/extend-kubernetes/_index.md @@ -1,4 +1,206 @@ --- title: Extending Kubernetes weight: 110 +description: Different ways to change the behavior of your Kubernetes cluster. +reviewers: +- erictune +- lavalamp +- cheftako +- chenopis +content_type: concept +no_list: true --- + + + +Kubernetes is highly configurable and extensible. As a result, +there is rarely a need to fork or submit patches to the Kubernetes +project code. + +This guide describes the options for customizing a Kubernetes +cluster. It is aimed at {{< glossary_tooltip text="cluster operators" term_id="cluster-operator" >}} who want to +understand how to adapt their Kubernetes cluster to the needs of +their work environment. Developers who are prospective {{< glossary_tooltip text="Platform Developers" term_id="platform-developer" >}} or Kubernetes Project {{< glossary_tooltip text="Contributors" term_id="contributor" >}} will also find it +useful as an introduction to what extension points and patterns +exist, and their trade-offs and limitations. + + + +## Overview + +Customization approaches can be broadly divided into *configuration*, which only involves changing flags, local configuration files, or API resources; and *extensions*, which involve running additional programs or services. This document is primarily about extensions. + +## Configuration + +*Configuration files* and *flags* are documented in the Reference section of the online documentation, under each binary: + +* [kubelet](/docs/reference/command-line-tools-reference/kubelet/) +* [kube-apiserver](/docs/reference/command-line-tools-reference/kube-apiserver/) +* [kube-controller-manager](/docs/reference/command-line-tools-reference/kube-controller-manager/) +* [kube-scheduler](/docs/reference/command-line-tools-reference/kube-scheduler/). + +Flags and configuration files may not always be changeable in a hosted Kubernetes service or a distribution with managed installation. When they are changeable, they are usually only changeable by the cluster administrator. Also, they are subject to change in future Kubernetes versions, and setting them may require restarting processes. For those reasons, they should be used only when there are no other options. + +*Built-in Policy APIs*, such as [ResourceQuota](/docs/concepts/policy/resource-quotas/), [PodSecurityPolicies](/docs/concepts/policy/pod-security-policy/), [NetworkPolicy](/docs/concepts/services-networking/network-policies/) and Role-based Access Control ([RBAC](/docs/reference/access-authn-authz/rbac/)), are built-in Kubernetes APIs. APIs are typically used with hosted Kubernetes services and with managed Kubernetes installations. They are declarative and use the same conventions as other Kubernetes resources like pods, so new cluster configuration can be repeatable and be managed the same way as applications. And, where they are stable, they enjoy a [defined support policy](/docs/reference/using-api/deprecation-policy/) like other Kubernetes APIs. For these reasons, they are preferred over *configuration files* and *flags* where suitable. + +## Extensions + +Extensions are software components that extend and deeply integrate with Kubernetes. +They adapt it to support new types and new kinds of hardware. + +Most cluster administrators will use a hosted or distribution +instance of Kubernetes. As a result, most Kubernetes users will not need to +install extensions and fewer will need to author new ones. + +## Extension Patterns + +Kubernetes is designed to be automated by writing client programs. Any +program that reads and/or writes to the Kubernetes API can provide useful +automation. *Automation* can run on the cluster or off it. By following +the guidance in this doc you can write highly available and robust automation. +Automation generally works with any Kubernetes cluster, including hosted +clusters and managed installations. + +There is a specific pattern for writing client programs that work well with +Kubernetes called the *Controller* pattern. Controllers typically read an +object's `.spec`, possibly do things, and then update the object's `.status`. + +A controller is a client of Kubernetes. When Kubernetes is the client and +calls out to a remote service, it is called a *Webhook*. The remote service +is called a *Webhook Backend*. Like Controllers, Webhooks do add a point of +failure. + +In the webhook model, Kubernetes makes a network request to a remote service. +In the *Binary Plugin* model, Kubernetes executes a binary (program). +Binary plugins are used by the kubelet (e.g. +[Flex Volume Plugins](/docs/concepts/storage/volumes/#flexVolume) +and [Network Plugins](/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/)) +and by kubectl. + +Below is a diagram showing how the extension points interact with the +Kubernetes control plane. + + + + + + +## Extension Points + +This diagram shows the extension points in a Kubernetes system. + + + + + +1. Users often interact with the Kubernetes API using `kubectl`. [Kubectl plugins](/docs/tasks/extend-kubectl/kubectl-plugins/) extend the kubectl binary. They only affect the individual user's local environment, and so cannot enforce site-wide policies. +2. The apiserver handles all requests. Several types of extension points in the apiserver allow authenticating requests, or blocking them based on their content, editing content, and handling deletion. These are described in the [API Access Extensions](#api-access-extensions) section. +3. The apiserver serves various kinds of *resources*. *Built-in resource kinds*, like `pods`, are defined by the Kubernetes project and can't be changed. You can also add resources that you define, or that other projects have defined, called *Custom Resources*, as explained in the [Custom Resources](#user-defined-types) section. Custom Resources are often used with API Access Extensions. +4. The Kubernetes scheduler decides which nodes to place pods on. There are several ways to extend scheduling. These are described in the [Scheduler Extensions](#scheduler-extensions) section. +5. Much of the behavior of Kubernetes is implemented by programs called Controllers which are clients of the API-Server. Controllers are often used in conjunction with Custom Resources. +6. The kubelet runs on servers, and helps pods appear like virtual servers with their own IPs on the cluster network. [Network Plugins](#network-plugins) allow for different implementations of pod networking. +7. The kubelet also mounts and unmounts volumes for containers. New types of storage can be supported via [Storage Plugins](#storage-plugins). + +If you are unsure where to start, this flowchart can help. Note that some solutions may involve several types of extensions. + + + + + + +## API Extensions +### User-Defined Types + +Consider adding a Custom Resource to Kubernetes if you want to define new controllers, application configuration objects or other declarative APIs, and to manage them using Kubernetes tools, such as `kubectl`. + +Do not use a Custom Resource as data storage for application, user, or monitoring data. + +For more about Custom Resources, see the [Custom Resources concept guide](/docs/concepts/extend-kubernetes/api-extension/custom-resources/). + + +### Combining New APIs with Automation + +The combination of a custom resource API and a control loop is called the [Operator pattern](/docs/concepts/extend-kubernetes/operator/). The Operator pattern is used to manage specific, usually stateful, applications. These custom APIs and control loops can also be used to control other resources, such as storage or policies. + +### Changing Built-in Resources + +When you extend the Kubernetes API by adding custom resources, the added resources always fall into a new API Groups. You cannot replace or change existing API groups. +Adding an API does not directly let you affect the behavior of existing APIs (e.g. Pods), but API Access Extensions do. + + +### API Access Extensions + +When a request reaches the Kubernetes API Server, it is first Authenticated, then Authorized, then subject to various types of Admission Control. See [Controlling Access to the Kubernetes API](/docs/reference/access-authn-authz/controlling-access/) for more on this flow. + +Each of these steps offers extension points. + +Kubernetes has several built-in authentication methods that it supports. It can also sit behind an authenticating proxy, and it can send a token from an Authorization header to a remote service for verification (a webhook). All of these methods are covered in the [Authentication documentation](/docs/reference/access-authn-authz/authentication/). + +### Authentication + +[Authentication](/docs/reference/access-authn-authz/authentication/) maps headers or certificates in all requests to a username for the client making the request. + +Kubernetes provides several built-in authentication methods, and an [Authentication webhook](/docs/reference/access-authn-authz/authentication/#webhook-token-authentication) method if those don't meet your needs. + + +### Authorization + +[Authorization](/docs/reference/access-authn-authz/webhook/) determines whether specific users can read, write, and do other operations on API resources. It just works at the level of whole resources -- it doesn't discriminate based on arbitrary object fields. If the built-in authorization options don't meet your needs, and [Authorization webhook](/docs/reference/access-authn-authz/webhook/) allows calling out to user-provided code to make an authorization decision. + + +### Dynamic Admission Control + +After a request is authorized, if it is a write operation, it also goes through [Admission Control](/docs/reference/access-authn-authz/admission-controllers/) steps. In addition to the built-in steps, there are several extensions: + +* The [Image Policy webhook](/docs/reference/access-authn-authz/admission-controllers/#imagepolicywebhook) restricts what images can be run in containers. +* To make arbitrary admission control decisions, a general [Admission webhook](/docs/reference/access-authn-authz/extensible-admission-controllers/#admission-webhooks) can be used. Admission Webhooks can reject creations or updates. + +## Infrastructure Extensions + + +### Storage Plugins + +[Flex Volumes](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/storage/flexvolume-deployment.md +) allow users to mount volume types without built-in support by having the +Kubelet call a Binary Plugin to mount the volume. + + +### Device Plugins + +Device plugins allow a node to discover new Node resources (in addition to the +builtin ones like cpu and memory) via a +[Device Plugin](/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins/). + + +### Network Plugins + +Different networking fabrics can be supported via node-level +[Network Plugins](/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/). + +### Scheduler Extensions + +The scheduler is a special type of controller that watches pods, and assigns +pods to nodes. The default scheduler can be replaced entirely, while +continuing to use other Kubernetes components, or +[multiple schedulers](/docs/tasks/extend-kubernetes/configure-multiple-schedulers/) +can run at the same time. + +This is a significant undertaking, and almost all Kubernetes users find they +do not need to modify the scheduler. + +The scheduler also supports a +[webhook](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/scheduling/scheduler_extender.md) +that permits a webhook backend (scheduler extension) to filter and prioritize +the nodes chosen for a pod. + +## {{% heading "whatsnext" %}} + + +* Learn more about [Custom Resources](/docs/concepts/extend-kubernetes/api-extension/custom-resources/) +* Learn about [Dynamic admission control](/docs/reference/access-authn-authz/extensible-admission-controllers/) +* Learn more about Infrastructure extensions + * [Network Plugins](/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/) + * [Device Plugins](/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins/) +* Learn about [kubectl plugins](/docs/tasks/extend-kubectl/kubectl-plugins/) +* Learn about the [Operator pattern](/docs/concepts/extend-kubernetes/operator/) + diff --git a/content/en/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation.md b/content/en/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation.md index 1f47323301..74147624f5 100644 --- a/content/en/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation.md +++ b/content/en/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation.md @@ -15,8 +15,6 @@ The additional APIs can either be ready-made solutions such as [service-catalog] The aggregation layer is different from [Custom Resources](/docs/concepts/extend-kubernetes/api-extension/custom-resources/), which are a way to make the {{< glossary_tooltip term_id="kube-apiserver" text="kube-apiserver" >}} recognise new kinds of object. - - ## Aggregation layer @@ -34,11 +32,8 @@ If your extension API server cannot achieve that latency requirement, consider m `EnableAggregatedDiscoveryTimeout=false` [feature gate](/docs/reference/command-line-tools-reference/feature-gates/) on the kube-apiserver to disable the timeout restriction. This deprecated feature gate will be removed in a future release. - - ## {{% heading "whatsnext" %}} - * To get the aggregator working in your environment, [configure the aggregation layer](/docs/tasks/extend-kubernetes/configure-aggregation-layer/). * Then, [setup an extension api-server](/docs/tasks/extend-kubernetes/setup-extension-api-server/) to work with the aggregation layer. * Also, learn how to [extend the Kubernetes API using Custom Resource Definitions](/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/). diff --git a/content/en/docs/concepts/extend-kubernetes/api-extension/custom-resources.md b/content/en/docs/concepts/extend-kubernetes/api-extension/custom-resources.md index f2ca2e2435..9a84267445 100644 --- a/content/en/docs/concepts/extend-kubernetes/api-extension/custom-resources.md +++ b/content/en/docs/concepts/extend-kubernetes/api-extension/custom-resources.md @@ -13,8 +13,6 @@ weight: 10 resource to your Kubernetes cluster and when to use a standalone service. It describes the two methods for adding custom resources and how to choose between them. - - ## Custom resources @@ -28,7 +26,7 @@ many core Kubernetes functions are now built using custom resources, making Kube Custom resources can appear and disappear in a running cluster through dynamic registration, and cluster admins can update custom resources independently of the cluster itself. Once a custom resource is installed, users can create and access its objects using -[kubectl](/docs/user-guide/kubectl-overview/), just as they do for built-in resources like +[kubectl](/docs/reference/kubectl/overview/), just as they do for built-in resources like *Pods*. ## Custom controllers @@ -52,7 +50,9 @@ for specific applications into an extension of the Kubernetes API. ## Should I add a custom resource to my Kubernetes Cluster? -When creating a new API, consider whether to [aggregate your API with the Kubernetes cluster APIs](/docs/concepts/api-extension/apiserver-aggregation/) or let your API stand alone. +When creating a new API, consider whether to +[aggregate your API with the Kubernetes cluster APIs](/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation/) +or let your API stand alone. | Consider API aggregation if: | Prefer a stand-alone API if: | | ---------------------------- | ---------------------------- | @@ -178,7 +178,7 @@ Aggregated APIs offer more advanced API features and customization of other feat | Feature | Description | CRDs | Aggregated API | | ------- | ----------- | ---- | -------------- | -| Validation | Help users prevent errors and allow you to evolve your API independently of your clients. These features are most useful when there are many clients who can't all update at the same time. | Yes. Most validation can be specified in the CRD using [OpenAPI v3.0 validation](/docs/tasks/extend-kubernetes/extend-api-custom-resource-definitions/#validation). Any other validations supported by addition of a [Validating Webhook](/docs/reference/access-authn-authz/admission-controllers/#validatingadmissionwebhook-alpha-in-1-8-beta-in-1-9). | Yes, arbitrary validation checks | +| Validation | Help users prevent errors and allow you to evolve your API independently of your clients. These features are most useful when there are many clients who can't all update at the same time. | Yes. Most validation can be specified in the CRD using [OpenAPI v3.0 validation](/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/#validation). Any other validations supported by addition of a [Validating Webhook](/docs/reference/access-authn-authz/admission-controllers/#validatingadmissionwebhook-alpha-in-1-8-beta-in-1-9). | Yes, arbitrary validation checks | | Defaulting | See above | Yes, either via [OpenAPI v3.0 validation](/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/#defaulting) `default` keyword (GA in 1.17), or via a [Mutating Webhook](/docs/reference/access-authn-authz/admission-controllers/#mutatingadmissionwebhook) (though this will not be run when reading from etcd for old objects). | Yes | | Multi-versioning | Allows serving the same object through two API versions. Can help ease API changes like renaming fields. Less important if you control your client versions. | [Yes](/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definition-versioning) | Yes | | Custom Storage | If you need storage with a different performance mode (for example, a time-series database instead of key-value store) or isolation for security (for example, encryption of sensitive information, etc.) | No | Yes | diff --git a/content/en/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins.md b/content/en/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins.md index d27dddd384..2a4ede4a0c 100644 --- a/content/en/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins.md +++ b/content/en/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins.md @@ -19,8 +19,6 @@ The targeted devices include GPUs, high-performance NICs, FPGAs, InfiniBand adap and other similar computing resources that may require vendor specific initialization and setup. - - ## Device plugin registration @@ -39,7 +37,7 @@ During the registration, the device plugin needs to send: * The name of its Unix socket. * The Device Plugin API version against which it was built. * The `ResourceName` it wants to advertise. Here `ResourceName` needs to follow the - [extended resource naming scheme](/docs/concepts/configuration/manage-compute-resources-container/#extended-resources) + [extended resource naming scheme](/docs/concepts/configuration/manage-resources-container/#extended-resources) as `vendor-domain/resourcetype`. (For example, an NVIDIA GPU is advertised as `nvidia.com/gpu`.) @@ -223,7 +221,7 @@ Here are some examples of device plugin implementations: * The [RDMA device plugin](https://github.com/hustcat/k8s-rdma-device-plugin) * The [Solarflare device plugin](https://github.com/vikaschoudhary16/sfc-device-plugin) * The [SR-IOV Network device plugin](https://github.com/intel/sriov-network-device-plugin) -* The [Xilinx FPGA device plugins](https://github.com/Xilinx/FPGA_as_a_Service/tree/master/k8s-fpga-device-plugin/trunk) for Xilinx FPGA devices +* The [Xilinx FPGA device plugins](https://github.com/Xilinx/FPGA_as_a_Service/tree/master/k8s-fpga-device-plugin) for Xilinx FPGA devices ## {{% heading "whatsnext" %}} @@ -232,6 +230,6 @@ Here are some examples of device plugin implementations: * Learn about [scheduling GPU resources](/docs/tasks/manage-gpus/scheduling-gpus/) using device plugins * Learn about [advertising extended resources](/docs/tasks/administer-cluster/extended-resource-node/) on a node * Read about using [hardware acceleration for TLS ingress](https://kubernetes.io/blog/2019/04/24/hardware-accelerated-ssl/tls-termination-in-ingress-controllers-using-kubernetes-device-plugins-and-runtimeclass/) with Kubernetes -* Learn about the [Topology Manager] (/docs/tasks/adminster-cluster/topology-manager/) +* Learn about the [Topology Manager](/docs/tasks/administer-cluster/topology-manager/) diff --git a/content/en/docs/concepts/extend-kubernetes/extend-cluster.md b/content/en/docs/concepts/extend-kubernetes/extend-cluster.md index 7914b1cab5..76c72e74e4 100644 --- a/content/en/docs/concepts/extend-kubernetes/extend-cluster.md +++ b/content/en/docs/concepts/extend-kubernetes/extend-cluster.md @@ -15,14 +15,14 @@ Kubernetes is highly configurable and extensible. As a result, there is rarely a need to fork or submit patches to the Kubernetes project code. -This guide describes the options for customizing a Kubernetes -cluster. It is aimed at {{< glossary_tooltip text="cluster operators" term_id="cluster-operator" >}} who want to -understand how to adapt their Kubernetes cluster to the needs of -their work environment. Developers who are prospective {{< glossary_tooltip text="Platform Developers" term_id="platform-developer" >}} or Kubernetes Project {{< glossary_tooltip text="Contributors" term_id="contributor" >}} will also find it -useful as an introduction to what extension points and patterns -exist, and their trade-offs and limitations. - - +This guide describes the options for customizing a Kubernetes cluster. It is +aimed at {{< glossary_tooltip text="cluster operators" term_id="cluster-operator" >}} +who want to understand how to adapt their +Kubernetes cluster to the needs of their work environment. Developers who are prospective +{{< glossary_tooltip text="Platform Developers" term_id="platform-developer" >}} +or Kubernetes Project {{< glossary_tooltip text="Contributors" term_id="contributor" >}} +will also find it useful as an introduction to what extension points and +patterns exist, and their trade-offs and limitations. @@ -35,14 +35,14 @@ Customization approaches can be broadly divided into *configuration*, which only *Configuration files* and *flags* are documented in the Reference section of the online documentation, under each binary: -* [kubelet](/docs/admin/kubelet/) -* [kube-apiserver](/docs/admin/kube-apiserver/) -* [kube-controller-manager](/docs/admin/kube-controller-manager/) -* [kube-scheduler](/docs/admin/kube-scheduler/). +* [kubelet](/docs/reference/command-line-tools-reference/kubelet/) +* [kube-apiserver](/docs/reference/command-line-tools-reference/kube-apiserver/) +* [kube-controller-manager](/docs/reference/command-line-tools-reference/kube-controller-manager/) +* [kube-scheduler](/docs/reference/command-line-tools-reference/kube-scheduler/). Flags and configuration files may not always be changeable in a hosted Kubernetes service or a distribution with managed installation. When they are changeable, they are usually only changeable by the cluster administrator. Also, they are subject to change in future Kubernetes versions, and setting them may require restarting processes. For those reasons, they should be used only when there are no other options. -*Built-in Policy APIs*, such as [ResourceQuota](/docs/concepts/policy/resource-quotas/), [PodSecurityPolicies](/docs/concepts/policy/pod-security-policy/), [NetworkPolicy](/docs/concepts/services-networking/network-policies/) and Role-based Access Control ([RBAC](/docs/reference/access-authn-authz/rbac/)), are built-in Kubernetes APIs. APIs are typically used with hosted Kubernetes services and with managed Kubernetes installations. They are declarative and use the same conventions as other Kubernetes resources like pods, so new cluster configuration can be repeatable and be managed the same way as applications. And, where they are stable, they enjoy a [defined support policy](/docs/reference/deprecation-policy/) like other Kubernetes APIs. For these reasons, they are preferred over *configuration files* and *flags* where suitable. +*Built-in Policy APIs*, such as [ResourceQuota](/docs/concepts/policy/resource-quotas/), [PodSecurityPolicies](/docs/concepts/policy/pod-security-policy/), [NetworkPolicy](/docs/concepts/services-networking/network-policies/) and Role-based Access Control ([RBAC](/docs/reference/access-authn-authz/rbac/)), are built-in Kubernetes APIs. APIs are typically used with hosted Kubernetes services and with managed Kubernetes installations. They are declarative and use the same conventions as other Kubernetes resources like pods, so new cluster configuration can be repeatable and be managed the same way as applications. And, where they are stable, they enjoy a [defined support policy](/docs/reference/using-api/deprecation-policy/) like other Kubernetes APIs. For these reasons, they are preferred over *configuration files* and *flags* where suitable. ## Extensions @@ -50,7 +50,7 @@ Extensions are software components that extend and deeply integrate with Kuberne They adapt it to support new types and new kinds of hardware. Most cluster administrators will use a hosted or distribution -instance of Kubernetes. As a result, most Kubernetes users will need to +instance of Kubernetes. As a result, most Kubernetes users will not need to install extensions and fewer will need to author new ones. ## Extension Patterns @@ -73,10 +73,9 @@ failure. In the webhook model, Kubernetes makes a network request to a remote service. In the *Binary Plugin* model, Kubernetes executes a binary (program). -Binary plugins are used by the kubelet (e.g. [Flex Volume -Plugins](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-storage/flexvolume.md) -and [Network -Plugins](/docs/concepts/cluster-administration/network-plugins/)) +Binary plugins are used by the kubelet (e.g. +[Flex Volume Plugins](/docs/concepts/storage/volumes/#flexVolume) +and [Network Plugins](/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/)) and by kubectl. Below is a diagram showing how the extension points interact with the @@ -95,13 +94,13 @@ This diagram shows the extension points in a Kubernetes system. -1. Users often interact with the Kubernetes API using `kubectl`. [Kubectl plugins](/docs/tasks/extend-kubectl/kubectl-plugins/) extend the kubectl binary. They only affect the individual user's local environment, and so cannot enforce site-wide policies. -2. The apiserver handles all requests. Several types of extension points in the apiserver allow authenticating requests, or blocking them based on their content, editing content, and handling deletion. These are described in the [API Access Extensions](/docs/concepts/overview/extending#api-access-extensions) section. -3. The apiserver serves various kinds of *resources*. *Built-in resource kinds*, like `pods`, are defined by the Kubernetes project and can't be changed. You can also add resources that you define, or that other projects have defined, called *Custom Resources*, as explained in the [Custom Resources](/docs/concepts/overview/extending#user-defined-types) section. Custom Resources are often used with API Access Extensions. -4. The Kubernetes scheduler decides which nodes to place pods on. There are several ways to extend scheduling. These are described in the [Scheduler Extensions](/docs/concepts/overview/extending#scheduler-extensions) section. -5. Much of the behavior of Kubernetes is implemented by programs called Controllers which are clients of the API-Server. Controllers are often used in conjunction with Custom Resources. -6. The kubelet runs on servers, and helps pods appear like virtual servers with their own IPs on the cluster network. [Network Plugins](/docs/concepts/overview/extending#network-plugins) allow for different implementations of pod networking. -7. The kubelet also mounts and unmounts volumes for containers. New types of storage can be supported via [Storage Plugins](/docs/concepts/overview/extending#storage-plugins). +1. Users often interact with the Kubernetes API using `kubectl`. [Kubectl plugins](/docs/tasks/extend-kubectl/kubectl-plugins/) extend the kubectl binary. They only affect the individual user's local environment, and so cannot enforce site-wide policies. +2. The apiserver handles all requests. Several types of extension points in the apiserver allow authenticating requests, or blocking them based on their content, editing content, and handling deletion. These are described in the [API Access Extensions](/docs/concepts/extend-kubernetes/#api-access-extensions) section. +3. The apiserver serves various kinds of *resources*. *Built-in resource kinds*, like `pods`, are defined by the Kubernetes project and can't be changed. You can also add resources that you define, or that other projects have defined, called *Custom Resources*, as explained in the [Custom Resources](/docs/concepts/extend-kubernetes/#user-defined-types) section. Custom Resources are often used with API Access Extensions. +4. The Kubernetes scheduler decides which nodes to place pods on. There are several ways to extend scheduling. These are described in the [Scheduler Extensions](/docs/concepts/extend-kubernetes/#scheduler-extensions) section. +5. Much of the behavior of Kubernetes is implemented by programs called Controllers which are clients of the API-Server. Controllers are often used in conjunction with Custom Resources. +6. The kubelet runs on servers, and helps pods appear like virtual servers with their own IPs on the cluster network. [Network Plugins](/docs/concepts/extend-kubernetes/#network-plugins) allow for different implementations of pod networking. +7. The kubelet also mounts and unmounts volumes for containers. New types of storage can be supported via [Storage Plugins](/docs/concepts/extend-kubernetes/#storage-plugins). If you are unsure where to start, this flowchart can help. Note that some solutions may involve several types of extensions. @@ -117,7 +116,7 @@ Consider adding a Custom Resource to Kubernetes if you want to define new contro Do not use a Custom Resource as data storage for application, user, or monitoring data. -For more about Custom Resources, see the [Custom Resources concept guide](/docs/concepts/api-extension/custom-resources/). +For more about Custom Resources, see the [Custom Resources concept guide](/docs/concepts/extend-kubernetes/api-extension/custom-resources/). ### Combining New APIs with Automation @@ -162,28 +161,28 @@ After a request is authorized, if it is a write operation, it also goes through ### Storage Plugins -[Flex Volumes](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/storage/flexvolume-deployment.md -) allow users to mount volume types without built-in support by having the +[Flex Volumes](/docs/concepts/storage/volumes/#flexVolume) +allow users to mount volume types without built-in support by having the Kubelet call a Binary Plugin to mount the volume. ### Device Plugins Device plugins allow a node to discover new Node resources (in addition to the -builtin ones like cpu and memory) via a [Device -Plugin](/docs/concepts/cluster-administration/device-plugins/). - +builtin ones like cpu and memory) via a +[Device Plugin](/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins/). ### Network Plugins -Different networking fabrics can be supported via node-level [Network Plugins](/docs/admin/network-plugins/). +Different networking fabrics can be supported via node-level +[Network Plugins](/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/). ### Scheduler Extensions The scheduler is a special type of controller that watches pods, and assigns pods to nodes. The default scheduler can be replaced entirely, while -continuing to use other Kubernetes components, or [multiple -schedulers](/docs/tasks/administer-cluster/configure-multiple-schedulers/) +continuing to use other Kubernetes components, or +[multiple schedulers](/docs/tasks/extend-kubernetes/configure-multiple-schedulers/) can run at the same time. This is a significant undertaking, and almost all Kubernetes users find they @@ -195,16 +194,13 @@ that permits a webhook backend (scheduler extension) to filter and prioritize the nodes chosen for a pod. - - ## {{% heading "whatsnext" %}} - -* Learn more about [Custom Resources](/docs/concepts/api-extension/custom-resources/) +* Learn more about [Custom Resources](/docs/concepts/extend-kubernetes/api-extension/custom-resources/) * Learn about [Dynamic admission control](/docs/reference/access-authn-authz/extensible-admission-controllers/) * Learn more about Infrastructure extensions - * [Network Plugins](/docs/concepts/cluster-administration/network-plugins/) - * [Device Plugins](/docs/concepts/cluster-administration/device-plugins/) + * [Network Plugins](/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/) + * [Device Plugins](/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins/) * Learn about [kubectl plugins](/docs/tasks/extend-kubectl/kubectl-plugins/) * Learn about the [Operator pattern](/docs/concepts/extend-kubernetes/operator/) diff --git a/content/en/docs/concepts/extend-kubernetes/operator.md b/content/en/docs/concepts/extend-kubernetes/operator.md index dda8f0020b..31e8473ca9 100644 --- a/content/en/docs/concepts/extend-kubernetes/operator.md +++ b/content/en/docs/concepts/extend-kubernetes/operator.md @@ -6,14 +6,11 @@ weight: 30 -Operators are software extensions to Kubernetes that make use of [custom -resources](/docs/concepts/extend-kubernetes/api-extension/custom-resources/) +Operators are software extensions to Kubernetes that make use of +[custom resources](/docs/concepts/extend-kubernetes/api-extension/custom-resources/) to manage applications and their components. Operators follow Kubernetes principles, notably the [control loop](/docs/concepts/#kubernetes-control-plane). - - - ## Motivation diff --git a/content/en/docs/concepts/extend-kubernetes/poseidon-firmament-alternate-scheduler.md b/content/en/docs/concepts/extend-kubernetes/poseidon-firmament-alternate-scheduler.md deleted file mode 100644 index 7f81439c41..0000000000 --- a/content/en/docs/concepts/extend-kubernetes/poseidon-firmament-alternate-scheduler.md +++ /dev/null @@ -1,112 +0,0 @@ ---- -title: Poseidon-Firmament Scheduler -content_type: concept -weight: 80 ---- - - - -{{< feature-state for_k8s_version="v1.6" state="alpha" >}} - -The Poseidon-Firmament scheduler is an alternate scheduler that can be deployed alongside the default Kubernetes scheduler. - - - - - - -## Introduction - -Poseidon is a service that acts as the integration glue between the [Firmament scheduler](https://github.com/Huawei-PaaS/firmament) and Kubernetes. Poseidon-Firmament augments the current Kubernetes scheduling capabilities. It incorporates novel flow network graph based scheduling capabilities alongside the default Kubernetes scheduler. The Firmament scheduler models workloads and clusters as flow networks and runs min-cost flow optimizations over these networks to make scheduling decisions. - -Firmament models the scheduling problem as a constraint-based optimization over a flow network graph. This is achieved by reducing scheduling to a min-cost max-flow optimization problem. The Poseidon-Firmament scheduler dynamically refines the workload placements. - -Poseidon-Firmament scheduler runs alongside the default Kubernetes scheduler as an alternate scheduler. You can simultaneously run multiple, different schedulers. - -Flow graph scheduling with the Poseidon-Firmament scheduler provides the following advantages: - -- Workloads (Pods) are bulk scheduled to enable scheduling at massive scale. - The Poseidon-Firmament scheduler outperforms the Kubernetes default scheduler by a wide margin when it comes to throughput performance for scenarios where compute resource requirements are somewhat uniform across your workload (Deployments, ReplicaSets, Jobs). -- The Poseidon-Firmament's scheduler's end-to-end throughput performance and bind time improves as the number of nodes in a cluster increases. As you scale out, Poseidon-Firmament scheduler is able to amortize more and more work across workloads. -- Scheduling in Poseidon-Firmament is dynamic; it keeps cluster resources in a global optimal state during every scheduling run. -- The Poseidon-Firmament scheduler supports scheduling complex rule constraints. - -## How the Poseidon-Firmament scheduler works - -Kubernetes supports [using multiple schedulers](/docs/tasks/administer-cluster/configure-multiple-schedulers/). You can specify, for a particular Pod, that it is scheduled by a custom scheduler (“poseidon” for this case), by setting the `schedulerName` field in the PodSpec at the time of pod creation. The default scheduler will ignore that Pod and allow Poseidon-Firmament scheduler to schedule the Pod on a relevant node. - -For example: - -```yaml -apiVersion: v1 -kind: Pod -... -spec: - schedulerName: poseidon -... -``` - -## Batch scheduling - -As mentioned earlier, Poseidon-Firmament scheduler enables an extremely high throughput scheduling environment at scale due to its bulk scheduling approach versus Kubernetes pod-at-a-time approach. In our extensive tests, we have observed substantial throughput benefits as long as resource requirements (CPU/Memory) for incoming Pods are uniform across jobs (Replicasets/Deployments/Jobs), mainly due to efficient amortization of work across jobs. - -Although, Poseidon-Firmament scheduler is capable of scheduling various types of workloads, such as service, batch, etc., the following are a few use cases where it excels the most: - -1. For “Big Data/AI” jobs consisting of large number of tasks, throughput benefits are tremendous. -2. Service or batch jobs where workload resource requirements are uniform across jobs (Replicasets/Deployments/Jobs). - -## Feature state - -Poseidon-Firmament is designed to work with Kubernetes release 1.6 and all subsequent releases. - -{{< caution >}} -Poseidon-Firmament scheduler does not provide support for high availability; its implementation assumes that the scheduler cannot fail. -{{< /caution >}} - -## Feature comparison {#feature-comparison-matrix} - -{{< table caption="Feature comparison of Kubernetes and Poseidon-Firmament schedulers." >}} -|Feature|Kubernetes Default Scheduler|Poseidon-Firmament Scheduler|Notes| -|--- |--- |--- |--- | -|Node Affinity/Anti-Affinity|Y|Y|| -|Pod Affinity/Anti-Affinity - including support for pod anti-affinity symmetry|Y|Y|The default scheduler outperforms the Poseidon-Firmament scheduler pod affinity/anti-affinity functionality.| -|Taints & Tolerations|Y|Y|| -|Baseline Scheduling capability in accordance to available compute resources (CPU & Memory) on a node|Y|Y†|**†** Not all Predicates & Priorities are supported with Poseidon-Firmament.| -|Extreme Throughput at scale|Y†|Y|**†** Bulk scheduling approach scales or increases workload placement. Firmament scheduler offers high throughput when resource requirements (CPU/Memory) for incoming Pods are uniform across ReplicaSets/Deployments/Jobs.| -|Colocation Interference Avoidance|N|N|| -|Priority Preemption|Y|N†|**†** Partially exists in Poseidon-Firmament versus extensive support in Kubernetes default scheduler.| -|Inherent Rescheduling|N|Y†|**†** Poseidon-Firmament scheduler supports workload re-scheduling. In each scheduling run, Poseidon-Firmament considers all Pods, including running Pods, and as a result can migrate or evict Pods – a globally optimal scheduling environment.| -|Gang Scheduling|N|Y|| -|Support for Pre-bound Persistence Volume Scheduling|Y|Y|| -|Support for Local Volume & Dynamic Persistence Volume Binding Scheduling|Y|N|| -|High Availability|Y|N|| -|Real-time metrics based scheduling|N|Y†|**†** Partially supported in Poseidon-Firmament using Heapster (now deprecated) for placing Pods using actual cluster utilization statistics rather than reservations.| -|Support for Max-Pod per node|Y|Y|Poseidon-Firmament scheduler seamlessly co-exists with Kubernetes default scheduler.| -|Support for Ephemeral Storage, in addition to CPU/Memory|Y|Y|| -{{< /table >}} - -## Installation - -The [Poseidon-Firmament installation guide](https://github.com/kubernetes-sigs/poseidon/blob/master/docs/install/README.md#Installation) explains how to deploy Poseidon-Firmament to your cluster. - -## Performance comparison - -{{< note >}} - Please refer to the [latest benchmark results](https://github.com/kubernetes-sigs/poseidon/blob/master/docs/benchmark/README.md) for detailed throughput performance comparison test results between Poseidon-Firmament scheduler and the Kubernetes default scheduler. -{{< /note >}} - -Pod-by-pod schedulers, such as the Kubernetes default scheduler, process Pods in small batches (typically one at a time). These schedulers have the following crucial drawbacks: - -1. The scheduler commits to a pod placement early and restricts the choices for other pods that wait to be placed. -2. There is limited opportunities for amortizing work across pods because they are considered for placement individually. - -These downsides of pod-by-pod schedulers are addressed by batching or bulk scheduling in Poseidon-Firmament scheduler. Processing several pods in a batch allows the scheduler to jointly consider their placement, and thus to find the best trade-off for the whole batch instead of one pod. At the same time it amortizes work across pods resulting in much higher throughput. - - -## {{% heading "whatsnext" %}} - -* See [Poseidon-Firmament](https://github.com/kubernetes-sigs/poseidon#readme) on GitHub for more information. -* See the [design document](https://github.com/kubernetes-sigs/poseidon/blob/master/docs/design/README.md) for Poseidon. -* Read [Firmament: Fast, Centralized Cluster Scheduling at Scale](https://www.usenix.org/system/files/conference/osdi16/osdi16-gog.pdf), the academic paper on the Firmament scheduling design. -* If you'd like to contribute to Poseidon-Firmament, refer to the [developer setup instructions](https://github.com/kubernetes-sigs/poseidon/blob/master/docs/devel/README.md). - diff --git a/content/en/docs/concepts/overview/_index.md b/content/en/docs/concepts/overview/_index.md index ec86980c4b..a52c470446 100755 --- a/content/en/docs/concepts/overview/_index.md +++ b/content/en/docs/concepts/overview/_index.md @@ -1,4 +1,5 @@ --- title: "Overview" weight: 20 ---- \ No newline at end of file +description: Get a high-level outline of Kubernetes and the components it is built from. +--- diff --git a/content/en/docs/concepts/overview/components.md b/content/en/docs/concepts/overview/components.md index f83f00683e..53e6b84c16 100644 --- a/content/en/docs/concepts/overview/components.md +++ b/content/en/docs/concepts/overview/components.md @@ -3,6 +3,9 @@ reviewers: - lavalamp title: Kubernetes Components content_type: concept +description: > + A Kubernetes cluster consists of the components that represent the control plane + and a set of machines called nodes. weight: 20 card: name: concepts diff --git a/content/en/docs/concepts/overview/kubernetes-api.md b/content/en/docs/concepts/overview/kubernetes-api.md index dd69fb6ccb..aa09776753 100644 --- a/content/en/docs/concepts/overview/kubernetes-api.md +++ b/content/en/docs/concepts/overview/kubernetes-api.md @@ -4,6 +4,9 @@ reviewers: title: The Kubernetes API content_type: concept weight: 30 +description: > + The Kubernetes API lets you query and manipulate the state of objects in Kubernetes. + The core of Kubernetes' control plane is the API server and the HTTP API that it exposes. Users, the different parts of your cluster, and external components all communicate with one another through the API server. card: name: concepts weight: 30 @@ -21,9 +24,6 @@ The Kubernetes API lets you query and manipulate the state of objects in the Kub API endpoints, resource types and samples are described in the [API Reference](/docs/reference/kubernetes-api/). - - - ## API changes @@ -84,7 +84,7 @@ Kubernetes implements an alternative Protobuf based serialization format for the To make it easier to eliminate fields or restructure resource representations, Kubernetes supports multiple API versions, each at a different API path, such as `/api/v1` or -`/apis/extensions/v1beta1`. +`/apis/rbac.authorization.k8s.io/v1alpha1`. Versioning is done at the API level rather than at the resource or field level to ensure that the API presents a clear, consistent view of system resources and behavior, and to enable controlling @@ -134,7 +134,7 @@ There are several API groups in a cluster: (e.g. `apiVersion: batch/v1`). The Kubernetes [API reference](/docs/reference/kubernetes-api/) has a full list of available API groups. -There are two paths to extending the API with [custom resources](/docs/concepts/api-extension/custom-resources/): +There are two paths to extending the API with [custom resources](/docs/concepts/extend-kubernetes/api-extension/custom-resources/): 1. [CustomResourceDefinition](/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/) lets you declaratively define how the API server should provide your chosen resource API. @@ -154,14 +154,6 @@ The flag accepts comma separated set of key=value pairs describing runtime confi {{< note >}}Enabling or disabling groups or resources requires restarting the kube-apiserver and the kube-controller-manager to pick up the `--runtime-config` changes.{{< /note >}} -## Enabling specific resources in the extensions/v1beta1 group - -DaemonSets, Deployments, StatefulSet, NetworkPolicies, PodSecurityPolicies and ReplicaSets in the `extensions/v1beta1` API group are disabled by default. -For example: to enable deployments and daemonsets, set -`--runtime-config=extensions/v1beta1/deployments=true,extensions/v1beta1/daemonsets=true`. - -{{< note >}}Individual resource enablement/disablement is only supported in the `extensions/v1beta1` API group for legacy reasons.{{< /note >}} - ## Persistence Kubernetes stores its serialized state in terms of the API resources by writing them into diff --git a/content/en/docs/concepts/overview/what-is-kubernetes.md b/content/en/docs/concepts/overview/what-is-kubernetes.md index 5b30c8e66e..5060b6f287 100644 --- a/content/en/docs/concepts/overview/what-is-kubernetes.md +++ b/content/en/docs/concepts/overview/what-is-kubernetes.md @@ -74,7 +74,7 @@ Kubernetes lets you store and manage sensitive information, such as passwords, O ## What Kubernetes is not -Kubernetes is not a traditional, all-inclusive PaaS (Platform as a Service) system. Since Kubernetes operates at the container level rather than at the hardware level, it provides some generally applicable features common to PaaS offerings, such as deployment, scaling, load balancing, logging, and monitoring. However, Kubernetes is not monolithic, and these default solutions are optional and pluggable. Kubernetes provides the building blocks for building developer platforms, but preserves user choice and flexibility where it is important. +Kubernetes is not a traditional, all-inclusive PaaS (Platform as a Service) system. Since Kubernetes operates at the container level rather than at the hardware level, it provides some generally applicable features common to PaaS offerings, such as deployment, scaling, load balancing, and lets users integrate their logging, monitoring, and alerting solutions. However, Kubernetes is not monolithic, and these default solutions are optional and pluggable. Kubernetes provides the building blocks for building developer platforms, but preserves user choice and flexibility where it is important. Kubernetes: diff --git a/content/en/docs/concepts/overview/working-with-objects/_index.md b/content/en/docs/concepts/overview/working-with-objects/_index.md index 8661349a3f..f872c20697 100755 --- a/content/en/docs/concepts/overview/working-with-objects/_index.md +++ b/content/en/docs/concepts/overview/working-with-objects/_index.md @@ -1,5 +1,7 @@ --- title: "Working with Kubernetes Objects" weight: 40 +description: > + Kubernetes objects are persistent entities in the Kubernetes system. Kubernetes uses these entities to represent the state of your cluster. + Learn about the Kubernetes object model and how to work with these objects. --- - diff --git a/content/en/docs/concepts/overview/working-with-objects/common-labels.md b/content/en/docs/concepts/overview/working-with-objects/common-labels.md index 11e8944c8a..a0a68c6dff 100644 --- a/content/en/docs/concepts/overview/working-with-objects/common-labels.md +++ b/content/en/docs/concepts/overview/working-with-objects/common-labels.md @@ -35,7 +35,7 @@ on every resource object. | Key | Description | Example | Type | | ----------------------------------- | --------------------- | -------- | ---- | | `app.kubernetes.io/name` | The name of the application | `mysql` | string | -| `app.kubernetes.io/instance` | A unique name identifying the instance of an application | `wordpress-abcxzy` | string | +| `app.kubernetes.io/instance` | A unique name identifying the instance of an application | `mysql-abcxzy` | string | | `app.kubernetes.io/version` | The current version of the application (e.g., a semantic version, revision hash, etc.) | `5.7.21` | string | | `app.kubernetes.io/component` | The component within the architecture | `database` | string | | `app.kubernetes.io/part-of` | The name of a higher level application this one is part of | `wordpress` | string | @@ -49,7 +49,7 @@ kind: StatefulSet metadata: labels: app.kubernetes.io/name: mysql - app.kubernetes.io/instance: wordpress-abcxzy + app.kubernetes.io/instance: mysql-abcxzy app.kubernetes.io/version: "5.7.21" app.kubernetes.io/component: database app.kubernetes.io/part-of: wordpress diff --git a/content/en/docs/concepts/overview/working-with-objects/kubernetes-objects.md b/content/en/docs/concepts/overview/working-with-objects/kubernetes-objects.md index 1f4f4e7509..ab447cdcd6 100644 --- a/content/en/docs/concepts/overview/working-with-objects/kubernetes-objects.md +++ b/content/en/docs/concepts/overview/working-with-objects/kubernetes-objects.md @@ -92,7 +92,7 @@ and the `spec` format for a Deployment can be found in ## {{% heading "whatsnext" %}} * [Kubernetes API overview](/docs/reference/using-api/api-overview/) explains some more API concepts -* Learn about the most important basic Kubernetes objects, such as [Pod](/docs/concepts/workloads/pods/pod-overview/). +* Learn about the most important basic Kubernetes objects, such as [Pod](/docs/concepts/workloads/pods/). * Learn about [controllers](/docs/concepts/architecture/controller/) in Kubernetes diff --git a/content/en/docs/concepts/overview/working-with-objects/labels.md b/content/en/docs/concepts/overview/working-with-objects/labels.md index e995db10a5..e580cadb88 100644 --- a/content/en/docs/concepts/overview/working-with-objects/labels.md +++ b/content/en/docs/concepts/overview/working-with-objects/labels.md @@ -22,10 +22,9 @@ Each object can have a set of key/value labels defined. Each Key must be unique } ``` -Labels allow for efficient queries and watches and are ideal for use in UIs and CLIs. Non-identifying information should be recorded using [annotations](/docs/concepts/overview/working-with-objects/annotations/). - - - +Labels allow for efficient queries and watches and are ideal for use in UIs +and CLIs. Non-identifying information should be recorded using +[annotations](/docs/concepts/overview/working-with-objects/annotations/). @@ -77,7 +76,7 @@ spec: ## Label selectors -Unlike [names and UIDs](/docs/user-guide/identifiers), labels do not provide uniqueness. In general, we expect many objects to carry the same label(s). +Unlike [names and UIDs](/docs/concepts/overview/working-with-objects/names/), labels do not provide uniqueness. In general, we expect many objects to carry the same label(s). Via a _label selector_, the client/user can identify a set of objects. The label selector is the core grouping primitive in Kubernetes. @@ -186,7 +185,10 @@ kubectl get pods -l 'environment,environment notin (frontend)' ### Set references in API objects -Some Kubernetes objects, such as [`services`](/docs/user-guide/services) and [`replicationcontrollers`](/docs/user-guide/replication-controller), also use label selectors to specify sets of other resources, such as [pods](/docs/user-guide/pods). +Some Kubernetes objects, such as [`services`](/docs/concepts/services-networking/service/) +and [`replicationcontrollers`](/docs/concepts/workloads/controllers/replicationcontroller/), +also use label selectors to specify sets of other resources, such as +[pods](/docs/concepts/workloads/pods/pod/). #### Service and ReplicationController @@ -210,7 +212,11 @@ this selector (respectively in `json` or `yaml` format) is equivalent to `compon #### Resources that support set-based requirements -Newer resources, such as [`Job`](/docs/concepts/workloads/controllers/jobs-run-to-completion/), [`Deployment`](/docs/concepts/workloads/controllers/deployment/), [`ReplicaSet`](/docs/concepts/workloads/controllers/replicaset/), and [`DaemonSet`](/docs/concepts/workloads/controllers/daemonset/), support _set-based_ requirements as well. +Newer resources, such as [`Job`](/docs/concepts/workloads/controllers/job/), +[`Deployment`](/docs/concepts/workloads/controllers/deployment/), +[`ReplicaSet`](/docs/concepts/workloads/controllers/replicaset/), and +[`DaemonSet`](/docs/concepts/workloads/controllers/daemonset/), +support _set-based_ requirements as well. ```yaml selector: @@ -228,4 +234,3 @@ selector: One use case for selecting over labels is to constrain the set of nodes onto which a pod can schedule. See the documentation on [node selection](/docs/concepts/scheduling-eviction/assign-pod-node/) for more information. - diff --git a/content/en/docs/concepts/overview/working-with-objects/namespaces.md b/content/en/docs/concepts/overview/working-with-objects/namespaces.md index 5e3acc5123..004c18ad2c 100644 --- a/content/en/docs/concepts/overview/working-with-objects/namespaces.md +++ b/content/en/docs/concepts/overview/working-with-objects/namespaces.md @@ -13,9 +13,6 @@ weight: 30 Kubernetes supports multiple virtual clusters backed by the same physical cluster. These virtual clusters are called namespaces. - - - ## When to Use Multiple Namespaces @@ -26,7 +23,7 @@ need to create or think about namespaces at all. Start using namespaces when yo need the features they provide. Namespaces provide a scope for names. Names of resources need to be unique within a namespace, -but not across namespaces. Namespaces can not be nested inside one another and each Kubernetes +but not across namespaces. Namespaces cannot be nested inside one another and each Kubernetes resource can only be in one namespace. Namespaces are a way to divide cluster resources between multiple users (via [resource quota](/docs/concepts/policy/resource-quotas/)). @@ -35,13 +32,18 @@ In future versions of Kubernetes, objects in the same namespace will have the sa access control policies by default. It is not necessary to use multiple namespaces just to separate slightly different -resources, such as different versions of the same software: use [labels](/docs/user-guide/labels) to distinguish +resources, such as different versions of the same software: use +[labels](/docs/concepts/overview/working-with-objects/labels) to distinguish resources within the same namespace. ## Working with Namespaces -Creation and deletion of namespaces are described in the [Admin Guide documentation -for namespaces](/docs/admin/namespaces). +Creation and deletion of namespaces are described in the +[Admin Guide documentation for namespaces](/docs/tasks/administer-cluster/namespaces). + +{{< note >}} + Avoid creating namespace with prefix `kube-`, since it is reserved for Kubernetes system namespaces. +{{< /note >}} ### Viewing namespaces @@ -89,7 +91,8 @@ kubectl config view --minify | grep namespace: ## Namespaces and DNS -When you create a [Service](/docs/user-guide/services), it creates a corresponding [DNS entry](/docs/concepts/services-networking/dns-pod-service/). +When you create a [Service](/docs/concepts/services-networking/service/), +it creates a corresponding [DNS entry](/docs/concepts/services-networking/dns-pod-service/). This entry is of the form `..svc.cluster.local`, which means that if a container just uses ``, it will resolve to the service which is local to a namespace. This is useful for using the same configuration across @@ -100,7 +103,8 @@ across namespaces, you need to use the fully qualified domain name (FQDN). Most Kubernetes resources (e.g. pods, services, replication controllers, and others) are in some namespaces. However namespace resources are not themselves in a namespace. -And low-level resources, such as [nodes](/docs/admin/node) and +And low-level resources, such as +[nodes](/docs/concepts/architecture/nodes/) and persistentVolumes, are not in any namespace. To see which Kubernetes resources are and aren't in a namespace: @@ -113,12 +117,8 @@ kubectl api-resources --namespaced=true kubectl api-resources --namespaced=false ``` - - ## {{% heading "whatsnext" %}} * Learn more about [creating a new namespace](/docs/tasks/administer-cluster/namespaces/#creating-a-new-namespace). * Learn more about [deleting a namespace](/docs/tasks/administer-cluster/namespaces/#deleting-a-namespace). - - diff --git a/content/en/docs/concepts/overview/working-with-objects/object-management.md b/content/en/docs/concepts/overview/working-with-objects/object-management.md index 97f57ff275..a2dd737e77 100644 --- a/content/en/docs/concepts/overview/working-with-objects/object-management.md +++ b/content/en/docs/concepts/overview/working-with-objects/object-management.md @@ -10,7 +10,6 @@ Kubernetes objects. This document provides an overview of the different approaches. Read the [Kubectl book](https://kubectl.docs.kubernetes.io) for details of managing objects by Kubectl. - ## Management techniques @@ -40,12 +39,6 @@ objects, it provides no history of previous configurations. Run an instance of the nginx container by creating a Deployment object: -```sh -kubectl run nginx --image nginx -``` - -Do the same thing using a different syntax: - ```sh kubectl create deployment nginx --image nginx ``` @@ -173,11 +166,8 @@ Disadvantages compared to imperative object configuration: - Declarative object configuration is harder to debug and understand results when they are unexpected. - Partial updates using diffs create complex merge and patch operations. - - ## {{% heading "whatsnext" %}} - - [Managing Kubernetes Objects Using Imperative Commands](/docs/tasks/manage-kubernetes-objects/imperative-command/) - [Managing Kubernetes Objects Using Object Configuration (Imperative)](/docs/tasks/manage-kubernetes-objects/imperative-config/) - [Managing Kubernetes Objects Using Object Configuration (Declarative)](/docs/tasks/manage-kubernetes-objects/declarative-config/) @@ -186,4 +176,3 @@ Disadvantages compared to imperative object configuration: - [Kubectl Book](https://kubectl.docs.kubernetes.io) - [Kubernetes API Reference](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/) - diff --git a/content/en/docs/concepts/policy/_index.md b/content/en/docs/concepts/policy/_index.md index 41d91de546..d2b42bc4cd 100755 --- a/content/en/docs/concepts/policy/_index.md +++ b/content/en/docs/concepts/policy/_index.md @@ -1,5 +1,6 @@ --- title: "Policies" weight: 90 +description: > + Policies you can configure that apply to groups of resources. --- - diff --git a/content/en/docs/concepts/policy/limit-range.md b/content/en/docs/concepts/policy/limit-range.md index 5b670d38a0..8158b78437 100644 --- a/content/en/docs/concepts/policy/limit-range.md +++ b/content/en/docs/concepts/policy/limit-range.md @@ -8,13 +8,10 @@ weight: 10 -By default, containers run with unbounded [compute resources](/docs/user-guide/compute-resources) on a Kubernetes cluster. +By default, containers run with unbounded [compute resources](/docs/concepts/configuration/manage-resources-containers/) on a Kubernetes cluster. With resource quotas, cluster administrators can restrict resource consumption and creation on a {{< glossary_tooltip text="namespace" term_id="namespace" >}} basis. Within a namespace, a Pod or Container can consume as much CPU and memory as defined by the namespace's resource quota. There is a concern that one Pod or Container could monopolize all available resources. A LimitRange is a policy to constrain resource allocations (to Pods or Containers) in a namespace. - - - A _LimitRange_ provides constraints that can: @@ -54,11 +51,8 @@ there may be contention for resources. In this case, the Containers or Pods will Neither contention nor changes to a LimitRange will affect already created resources. - - ## {{% heading "whatsnext" %}} - Refer to the [LimitRanger design document](https://git.k8s.io/community/contributors/design-proposals/resource-management/admission_control_limit_range.md) for more information. For examples on using limits, see: @@ -68,7 +62,5 @@ For examples on using limits, see: - [how to configure default CPU Requests and Limits per namespace](/docs/tasks/administer-cluster/manage-resources/cpu-default-namespace/). - [how to configure default Memory Requests and Limits per namespace](/docs/tasks/administer-cluster/manage-resources/memory-default-namespace/). - [how to configure minimum and maximum Storage consumption per namespace](/docs/tasks/administer-cluster/limit-storage-consumption/#limitrange-to-limit-requests-for-storage). -- a [detailed example on configuring quota per namespace](/docs/tasks/administer-cluster/quota-memory-cpu-namespace/). - - +- a [detailed example on configuring quota per namespace](/docs/tasks/administer-cluster/manage-resources/quota-memory-cpu-namespace/). diff --git a/content/en/docs/concepts/policy/pod-security-policy.md b/content/en/docs/concepts/policy/pod-security-policy.md index 5a5241c42e..658d3bee7f 100644 --- a/content/en/docs/concepts/policy/pod-security-policy.md +++ b/content/en/docs/concepts/policy/pod-security-policy.md @@ -14,9 +14,6 @@ weight: 20 Pod Security Policies enable fine-grained authorization of pod creation and updates. - - - ## What is a Pod Security Policy? @@ -143,13 +140,13 @@ For a complete example of authorizing a PodSecurityPolicy, see ### Troubleshooting -- The [Controller Manager](/docs/admin/kube-controller-manager/) must be run +- The [Controller Manager](/docs/reference/command-line-tools-reference/kube-controller-manager/) must be run against [the secured API port](/docs/reference/access-authn-authz/controlling-access/), and must not have superuser permissions. Otherwise requests would bypass authentication and authorization modules, all PodSecurityPolicy objects would be allowed, and users would be able to create privileged containers. For more details -on configuring Controller Manager authorization, see [Controller -Roles](/docs/reference/access-authn-authz/rbac/#controller-roles). +on configuring Controller Manager authorization, see +[Controller Roles](/docs/reference/access-authn-authz/rbac/#controller-roles). ## Policy Order @@ -302,7 +299,7 @@ kubectl-user delete pod pause Let's try that again, slightly differently: ```shell -kubectl-user run pause --image=k8s.gcr.io/pause +kubectl-user create deployment pause --image=k8s.gcr.io/pause deployment "pause" created kubectl-user get pods @@ -629,15 +626,12 @@ By default, all safe sysctls are allowed. - `allowedUnsafeSysctls` - allows specific sysctls that had been disallowed by the default list, so long as these are not listed in `forbiddenSysctls`. Refer to the [Sysctl documentation]( -/docs/concepts/cluster-administration/sysctl-cluster/#podsecuritypolicy). - - +/docs/tasks/administer-cluster/sysctl-cluster/#podsecuritypolicy). ## {{% heading "whatsnext" %}} +- See [Pod Security Standards](/docs/concepts/security/pod-security-standards/) for policy recommendations. -See [Pod Security Standards](/docs/concepts/security/pod-security-standards/) for policy recommendations. - -Refer to [Pod Security Policy Reference](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podsecuritypolicy-v1beta1-policy) for the api details. +- Refer to [Pod Security Policy Reference](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podsecuritypolicy-v1beta1-policy) for the api details. diff --git a/content/en/docs/concepts/policy/resource-quotas.md b/content/en/docs/concepts/policy/resource-quotas.md index 4fb3f17a38..07ce03c86a 100644 --- a/content/en/docs/concepts/policy/resource-quotas.md +++ b/content/en/docs/concepts/policy/resource-quotas.md @@ -13,9 +13,6 @@ there is a concern that one team could use more than its fair share of resources Resource quotas are a tool for administrators to address this concern. - - - A resource quota, defined by a `ResourceQuota` object, provides constraints that limit @@ -27,15 +24,21 @@ Resource quotas work like this: - Different teams work in different namespaces. Currently this is voluntary, but support for making this mandatory via ACLs is planned. + - The administrator creates one `ResourceQuota` for each namespace. + - Users create resources (pods, services, etc.) in the namespace, and the quota system tracks usage to ensure it does not exceed hard resource limits defined in a `ResourceQuota`. + - If creating or updating a resource violates a quota constraint, the request will fail with HTTP status code `403 FORBIDDEN` with a message explaining the constraint that would have been violated. + - If quota is enabled in a namespace for compute resources like `cpu` and `memory`, users must specify requests or limits for those values; otherwise, the quota system may reject pod creation. Hint: Use the `LimitRanger` admission controller to force defaults for pods that make no compute resource requirements. - See the [walkthrough](/docs/tasks/administer-cluster/quota-memory-cpu-namespace/) for an example of how to avoid this problem. + + See the [walkthrough](/docs/tasks/administer-cluster/manage-resources/quota-memory-cpu-namespace/) + for an example of how to avoid this problem. The name of a `ResourceQuota` object must be a valid [DNS subdomain name](/docs/concepts/overview/working-with-objects/names#dns-subdomain-names). @@ -63,7 +66,7 @@ A resource quota is enforced in a particular namespace when there is a ## Compute Resource Quota -You can limit the total sum of [compute resources](/docs/user-guide/compute-resources) that can be requested in a given namespace. +You can limit the total sum of [compute resources](/docs/concepts/configuration/manage-resources-containers/) that can be requested in a given namespace. The following resource types are supported: @@ -77,7 +80,7 @@ The following resource types are supported: ### Resource Quota For Extended Resources In addition to the resources mentioned above, in release 1.10, quota support for -[extended resources](/docs/concepts/configuration/manage-compute-resources-container/#extended-resources) is added. +[extended resources](/docs/concepts/configuration/manage-resources-containers/#extended-resources) is added. As overcommit is not allowed for extended resources, it makes no sense to specify both `requests` and `limits` for the same extended resource in a quota. So for extended resources, only quota items @@ -554,7 +557,7 @@ plugins: limitedResources: - resource: pods matchScopes: - - scopeName: PriorityClass + - scopeName: PriorityClass operator: In values: ["cluster-services"] ``` @@ -573,7 +576,7 @@ plugins: limitedResources: - resource: pods matchScopes: - - scopeName: PriorityClass + - scopeName: PriorityClass operator: In values: ["cluster-services"] ``` @@ -596,11 +599,7 @@ See [LimitedResources](https://github.com/kubernetes/kubernetes/pull/36765) and See a [detailed example for how to use resource quota](/docs/tasks/administer-cluster/quota-api-object/). - - ## {{% heading "whatsnext" %}} - -See [ResourceQuota design doc](https://git.k8s.io/community/contributors/design-proposals/resource-management/admission_control_resource_quota.md) for more information. - +- See [ResourceQuota design doc](https://git.k8s.io/community/contributors/design-proposals/resource-management/admission_control_resource_quota.md) for more information. diff --git a/content/en/docs/concepts/scheduling-eviction/_index.md b/content/en/docs/concepts/scheduling-eviction/_index.md index a30a80a451..3a2bf9359f 100644 --- a/content/en/docs/concepts/scheduling-eviction/_index.md +++ b/content/en/docs/concepts/scheduling-eviction/_index.md @@ -1,5 +1,8 @@ --- title: "Scheduling and Eviction" weight: 90 +description: > + In Kubernetes, scheduling refers to making sure that Pods are matched to Nodes so that the kubelet can run them. + Eviction is the process of proactively failing one or more Pods on resource-starved Nodes. --- diff --git a/content/en/docs/concepts/scheduling-eviction/kube-scheduler.md b/content/en/docs/concepts/scheduling-eviction/kube-scheduler.md index 406c3f974b..30454c7c5b 100644 --- a/content/en/docs/concepts/scheduling-eviction/kube-scheduler.md +++ b/content/en/docs/concepts/scheduling-eviction/kube-scheduler.md @@ -10,8 +10,6 @@ In Kubernetes, _scheduling_ refers to making sure that {{< glossary_tooltip text are matched to {{< glossary_tooltip text="Nodes" term_id="node" >}} so that {{< glossary_tooltip term_id="kubelet" >}} can run them. - - ## Scheduling overview {#scheduling} @@ -28,7 +26,7 @@ page will help you learn about scheduling. ## kube-scheduler -[kube-scheduler](https://kubernetes.io/docs/reference/command-line-tools-reference/kube-scheduler/) +[kube-scheduler](/docs/reference/command-line-tools-reference/kube-scheduler/) is the default scheduler for Kubernetes and runs as part of the {{< glossary_tooltip text="control plane" term_id="control-plane" >}}. kube-scheduler is designed so that, if you want and need to, you can @@ -92,7 +90,6 @@ of the scheduler: * Read about [scheduler performance tuning](/docs/concepts/scheduling-eviction/scheduler-perf-tuning/) * Read about [Pod topology spread constraints](/docs/concepts/workloads/pods/pod-topology-spread-constraints/) * Read the [reference documentation](/docs/reference/command-line-tools-reference/kube-scheduler/) for kube-scheduler -* Learn about [configuring multiple schedulers](/docs/tasks/administer-cluster/configure-multiple-schedulers/) +* Learn about [configuring multiple schedulers](/docs/tasks/extend-kubernetes/configure-multiple-schedulers/) * Learn about [topology management policies](/docs/tasks/administer-cluster/topology-manager/) * Learn about [Pod Overhead](/docs/concepts/configuration/pod-overhead/) - diff --git a/content/en/docs/concepts/scheduling-eviction/taint-and-toleration.md b/content/en/docs/concepts/scheduling-eviction/taint-and-toleration.md index 97a190a280..9bb54b3e4f 100644 --- a/content/en/docs/concepts/scheduling-eviction/taint-and-toleration.md +++ b/content/en/docs/concepts/scheduling-eviction/taint-and-toleration.md @@ -175,7 +175,7 @@ toleration to pods that use the special hardware. As in the dedicated nodes use it is probably easiest to apply the tolerations using a custom [admission controller](/docs/reference/access-authn-authz/admission-controllers/). For example, it is recommended to use [Extended -Resources](/docs/concepts/configuration/manage-compute-resources-container/#extended-resources) +Resources](/docs/concepts/configuration/manage-resources-containers/#extended-resources) to represent the special hardware, taint your special hardware nodes with the extended resource name and run the [ExtendedResourceToleration](/docs/reference/access-authn-authz/admission-controllers/#extendedresourcetoleration) diff --git a/content/en/docs/concepts/security/_index.md b/content/en/docs/concepts/security/_index.md index aecc16eee7..3dfb62fe48 100644 --- a/content/en/docs/concepts/security/_index.md +++ b/content/en/docs/concepts/security/_index.md @@ -1,4 +1,6 @@ --- title: "Security" weight: 81 +description: > + Concepts for keeping your cloud-native workload secure. --- diff --git a/content/en/docs/concepts/security/pod-security-standards.md b/content/en/docs/concepts/security/pod-security-standards.md index 2afd6c7335..20574c8f91 100644 --- a/content/en/docs/concepts/security/pod-security-standards.md +++ b/content/en/docs/concepts/security/pod-security-standards.md @@ -236,11 +236,7 @@ well as lower-trust users.The following listed controls should be enforced/disal spec.securityContext.supplementalGroups[*]
spec.securityContext.fsGroup
spec.containers[*].securityContext.runAsGroup
- spec.containers[*].securityContext.supplementalGroups[*]
- spec.containers[*].securityContext.fsGroup
spec.initContainers[*].securityContext.runAsGroup
- spec.initContainers[*].securityContext.supplementalGroups[*]
- spec.initContainers[*].securityContext.fsGroup

Allowed Values:
non-zero
undefined / nil (except for `*.runAsGroup`)
diff --git a/content/en/docs/concepts/services-networking/_index.md b/content/en/docs/concepts/services-networking/_index.md index eea2c65b33..2e7d91427e 100755 --- a/content/en/docs/concepts/services-networking/_index.md +++ b/content/en/docs/concepts/services-networking/_index.md @@ -1,5 +1,12 @@ --- title: "Services, Load Balancing, and Networking" weight: 60 +description: > + Concepts and resources behind networking in Kubernetes. --- +Kubernetes networking addresses four concerns: +- Containers within a Pod use networking to communicate via loopback. +- Cluster networking provides communication between different Pods. +- The Service resource lets you expose an application running in Pods to be reachable from outside your cluster. +- You can also use Services to publish services only for consumption inside your cluster. diff --git a/content/en/docs/concepts/services-networking/add-entries-to-pod-etc-hosts-with-host-aliases.md b/content/en/docs/concepts/services-networking/add-entries-to-pod-etc-hosts-with-host-aliases.md index 4e40307401..8eee03bf9b 100644 --- a/content/en/docs/concepts/services-networking/add-entries-to-pod-etc-hosts-with-host-aliases.md +++ b/content/en/docs/concepts/services-networking/add-entries-to-pod-etc-hosts-with-host-aliases.md @@ -23,7 +23,7 @@ Modification not using HostAliases is not suggested because the file is managed Start an Nginx Pod which is assigned a Pod IP: ```shell -kubectl run nginx --image nginx --generator=run-pod/v1 +kubectl run nginx --image nginx ``` ``` @@ -64,7 +64,7 @@ By default, the `hosts` file only includes IPv4 and IPv6 boilerplates like ## Adding additional entries with hostAliases In addition to the default boilerplate, you can add additional entries to the -`hosts` file. +`hosts` file. For example: to resolve `foo.local`, `bar.local` to `127.0.0.1` and `foo.remote`, `bar.remote` to `10.1.2.3`, you can configure HostAliases for a Pod under `.spec.hostAliases`: diff --git a/content/en/docs/concepts/services-networking/connect-applications-service.md b/content/en/docs/concepts/services-networking/connect-applications-service.md index 79c6053301..86c4dd1623 100644 --- a/content/en/docs/concepts/services-networking/connect-applications-service.md +++ b/content/en/docs/concepts/services-networking/connect-applications-service.md @@ -133,7 +133,7 @@ about the [service proxy](/docs/concepts/services-networking/service/#virtual-ip Kubernetes supports 2 primary modes of finding a Service - environment variables and DNS. The former works out of the box while the latter requires the -[CoreDNS cluster addon](http://releases.k8s.io/{{< param "githubbranch" >}}/cluster/addons/dns/coredns). +[CoreDNS cluster addon](https://releases.k8s.io/{{< param "githubbranch" >}}/cluster/addons/dns/coredns). {{< note >}} If the service environment variables are not desired (because possible clashing with expected program ones, too many variables to process, only using DNS, etc) you can disable this mode by setting the `enableServiceLinks` diff --git a/content/en/docs/concepts/services-networking/dns-pod-service.md b/content/en/docs/concepts/services-networking/dns-pod-service.md index 9d88019e3c..738c6bac14 100644 --- a/content/en/docs/concepts/services-networking/dns-pod-service.md +++ b/content/en/docs/concepts/services-networking/dns-pod-service.md @@ -68,10 +68,19 @@ of the form `auto-generated-name.my-svc.my-namespace.svc.cluster-domain.example` ### A/AAAA records -Any pods created by a Deployment or DaemonSet have the following -DNS resolution available: +In general a pod has the following DNS resolution: -`pod-ip-address.deployment-name.my-namespace.svc.cluster-domain.example.` +`pod-ip-address.my-namespace.pod.cluster-domain.example`. + +For example, if a pod in the `default` namespace has the IP address 172.17.0.3, +and the domain name for your cluster is `cluster.local`, then the Pod has a DNS name: + +`172-17-0-3.default.pod.cluster.local`. + +Any pods created by a Deployment or DaemonSet exposed by a Service have the +following DNS resolution available: + +`pod-ip-address.deployment-name.my-namespace.svc.cluster-domain.example`. ### Pod's hostname and subdomain fields @@ -276,4 +285,3 @@ The availability of Pod DNS Config and DNS Policy "`None`" is shown as below. For guidance on administering DNS configurations, check [Configure DNS Service](/docs/tasks/administer-cluster/dns-custom-nameservers/) - diff --git a/content/en/docs/concepts/services-networking/ingress-controllers.md b/content/en/docs/concepts/services-networking/ingress-controllers.md index 2c363ce7dc..3b375f7421 100644 --- a/content/en/docs/concepts/services-networking/ingress-controllers.md +++ b/content/en/docs/concepts/services-networking/ingress-controllers.md @@ -26,13 +26,13 @@ Kubernetes as a project currently supports and maintains [GCE](https://git.k8s.i * [Ambassador](https://www.getambassador.io/) API Gateway is an [Envoy](https://www.envoyproxy.io) based ingress controller with [community](https://www.getambassador.io/docs) or [commercial](https://www.getambassador.io/pro/) support from [Datawire](https://www.datawire.io/). -* [AppsCode Inc.](https://appscode.com) offers support and maintenance for the most widely used [HAProxy](http://www.haproxy.org/) based ingress controller [Voyager](https://appscode.com/products/voyager). +* [AppsCode Inc.](https://appscode.com) offers support and maintenance for the most widely used [HAProxy](https://www.haproxy.org/) based ingress controller [Voyager](https://appscode.com/products/voyager). * [AWS ALB Ingress Controller](https://github.com/kubernetes-sigs/aws-alb-ingress-controller) enables ingress using the [AWS Application Load Balancer](https://aws.amazon.com/elasticloadbalancing/). * [Contour](https://projectcontour.io/) is an [Envoy](https://www.envoyproxy.io/) based ingress controller provided and supported by VMware. * Citrix provides an [Ingress Controller](https://github.com/citrix/citrix-k8s-ingress-controller) for its hardware (MPX), virtualized (VPX) and [free containerized (CPX) ADC](https://www.citrix.com/products/citrix-adc/cpx-express.html) for [baremetal](https://github.com/citrix/citrix-k8s-ingress-controller/tree/master/deployment/baremetal) and [cloud](https://github.com/citrix/citrix-k8s-ingress-controller/tree/master/deployment) deployments. * F5 Networks provides [support and maintenance](https://support.f5.com/csp/article/K86859508) - for the [F5 BIG-IP Controller for Kubernetes](http://clouddocs.f5.com/products/connectors/k8s-bigip-ctlr/latest). + for the [F5 BIG-IP Container Ingress Services for Kubernetes](https://clouddocs.f5.com/containers/latest/userguide/kubernetes/). * [Gloo](https://gloo.solo.io) is an open-source ingress controller based on [Envoy](https://www.envoyproxy.io) which offers API Gateway functionality with enterprise support from [solo.io](https://www.solo.io). * [HAProxy Ingress](https://haproxy-ingress.github.io) is a highly customizable community-driven ingress controller for HAProxy. * [HAProxy Technologies](https://www.haproxy.com/) offers support and maintenance for the [HAProxy Ingress Controller for Kubernetes](https://github.com/haproxytech/kubernetes-ingress). See the [official documentation](https://www.haproxy.com/documentation/hapee/1-9r1/traffic-management/kubernetes-ingress-controller/). diff --git a/content/en/docs/concepts/services-networking/ingress.md b/content/en/docs/concepts/services-networking/ingress.md index 430ee3c72d..79cb4379b9 100644 --- a/content/en/docs/concepts/services-networking/ingress.md +++ b/content/en/docs/concepts/services-networking/ingress.md @@ -91,7 +91,7 @@ Different [Ingress controller](/docs/concepts/services-networking/ingress-contro The Ingress [spec](https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status) has all the information needed to configure a load balancer or proxy server. Most importantly, it contains a list of rules matched against all incoming requests. Ingress resource only supports rules -for directing HTTP traffic. +for directing HTTP(S) traffic. ### Ingress rules @@ -192,7 +192,7 @@ IngressClass resource will ensure that new Ingresses without an If you have more than one IngressClass marked as the default for your cluster, the admission controller prevents creating new Ingress objects that don't have an `ingressClassName` specified. You can resolve this by ensuring that at most 1 -IngressClasess are marked as default in your cluster. +IngressClasses are marked as default in your cluster. {{< /caution >}} ## Types of Ingress @@ -432,7 +432,7 @@ a Service. It's also worth noting that even though health checks are not exposed directly through the Ingress, there exist parallel concepts in Kubernetes such as -[readiness probes](/docs/tasks/configure-pod-container/configure-liveness-readiness-probes/) +[readiness probes](/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/) that allow you to achieve the same end result. Please review the controller specific documentation to see how they handle health checks ( [nginx](https://git.k8s.io/ingress-nginx/README.md), diff --git a/content/en/docs/concepts/services-networking/network-policies.md b/content/en/docs/concepts/services-networking/network-policies.md index 4a01707ab2..a35eca252f 100644 --- a/content/en/docs/concepts/services-networking/network-policies.md +++ b/content/en/docs/concepts/services-networking/network-policies.md @@ -8,8 +8,6 @@ content_type: concept weight: 50 --- -{{< toc >}} - A network policy is a specification of how groups of {{< glossary_tooltip text="pods" term_id="pod">}} are allowed to communicate with each other and other network endpoints. diff --git a/content/en/docs/concepts/services-networking/service.md b/content/en/docs/concepts/services-networking/service.md index 2ae49ac270..e1f7d09779 100644 --- a/content/en/docs/concepts/services-networking/service.md +++ b/content/en/docs/concepts/services-networking/service.md @@ -20,8 +20,6 @@ With Kubernetes you don't need to modify your application to use an unfamiliar s Kubernetes gives Pods their own IP addresses and a single DNS name for a set of Pods, and can load-balance across them. - - ## Motivation @@ -390,7 +388,7 @@ variables and DNS. When a Pod is run on a Node, the kubelet adds a set of environment variables for each active Service. It supports both [Docker links compatible](https://docs.docker.com/userguide/dockerlinks/) variables (see -[makeLinkVariables](http://releases.k8s.io/{{< param "githubbranch" >}}/pkg/kubelet/envvars/envvars.go#L49)) +[makeLinkVariables](https://releases.k8s.io/{{< param "githubbranch" >}}/pkg/kubelet/envvars/envvars.go#L49)) and simpler `{SVCNAME}_SERVICE_HOST` and `{SVCNAME}_SERVICE_PORT` variables, where the Service name is upper-cased and dashes are converted to underscores. @@ -754,7 +752,7 @@ In the above example, if the Service contained three ports, `80`, `443`, and `8443`, then `443` and `8443` would use the SSL certificate, but `80` would just be proxied HTTP. -From Kubernetes v1.9 onwards you can use [predefined AWS SSL policies](http://docs.aws.amazon.com/elasticloadbalancing/latest/classic/elb-security-policy-table.html) with HTTPS or SSL listeners for your Services. +From Kubernetes v1.9 onwards you can use [predefined AWS SSL policies](https://docs.aws.amazon.com/elasticloadbalancing/latest/classic/elb-security-policy-table.html) with HTTPS or SSL listeners for your Services. To see which policies are available for use, you can use the `aws` command line tool: ```bash @@ -889,7 +887,7 @@ To use a Network Load Balancer on AWS, use the annotation `service.beta.kubernet ``` {{< note >}} -NLB only works with certain instance classes; see the [AWS documentation](http://docs.aws.amazon.com/elasticloadbalancing/latest/network/target-group-register-targets.html#register-deregister-targets) +NLB only works with certain instance classes; see the [AWS documentation](https://docs.aws.amazon.com/elasticloadbalancing/latest/network/target-group-register-targets.html#register-deregister-targets) on Elastic Load Balancing for a list of supported instance types. {{< /note >}} @@ -1046,9 +1044,9 @@ spec: ## Shortcomings Using the userspace proxy for VIPs, work at small to medium scale, but will -not scale to very large clusters with thousands of Services. The [original -design proposal for portals](http://issue.k8s.io/1107) has more details on -this. +not scale to very large clusters with thousands of Services. The +[original design proposal for portals](https://github.com/kubernetes/kubernetes/issues/1107) +has more details on this. Using the userspace proxy obscures the source IP address of a packet accessing a Service. diff --git a/content/en/docs/concepts/storage/_index.md b/content/en/docs/concepts/storage/_index.md index 7e0dd19b12..a6aeac7734 100755 --- a/content/en/docs/concepts/storage/_index.md +++ b/content/en/docs/concepts/storage/_index.md @@ -1,5 +1,7 @@ --- title: "Storage" weight: 70 +description: > + Ways to provide both long-term and temporary storage to Pods in your cluster. --- diff --git a/content/en/docs/concepts/storage/persistent-volumes.md b/content/en/docs/concepts/storage/persistent-volumes.md index 2c3140de83..4933513929 100644 --- a/content/en/docs/concepts/storage/persistent-volumes.md +++ b/content/en/docs/concepts/storage/persistent-volumes.md @@ -19,9 +19,6 @@ weight: 20 This document describes the current state of _persistent volumes_ in Kubernetes. Familiarity with [volumes](/docs/concepts/storage/volumes/) is suggested. - - - ## Introduction @@ -30,7 +27,7 @@ Managing storage is a distinct problem from managing compute instances. The Pers A _PersistentVolume_ (PV) is a piece of storage in the cluster that has been provisioned by an administrator or dynamically provisioned using [Storage Classes](/docs/concepts/storage/storage-classes/). It is a resource in the cluster just like a node is a cluster resource. PVs are volume plugins like Volumes, but have a lifecycle independent of any individual Pod that uses the PV. This API object captures the details of the implementation of the storage, be that NFS, iSCSI, or a cloud-provider-specific storage system. -A _PersistentVolumeClaim_ (PVC) is a request for storage by a user. It is similar to a Pod. Pods consume node resources and PVCs consume PV resources. Pods can request specific levels of resources (CPU and Memory). Claims can request specific size and access modes (e.g., they can be mounted once read/write or many times read-only). +A _PersistentVolumeClaim_ (PVC) is a request for storage by a user. It is similar to a Pod. Pods consume node resources and PVCs consume PV resources. Pods can request specific levels of resources (CPU and Memory). Claims can request specific size and access modes (e.g., they can be mounted ReadWriteOnce, ReadOnlyMany or ReadWriteMany, see [AccessModes](#access-modes)). While PersistentVolumeClaims allow a user to consume abstract storage resources, it is common that users need PersistentVolumes with varying properties, such as performance, for different problems. Cluster administrators need to be able to offer a variety of PersistentVolumes that differ in more ways than just size and access modes, without exposing users to the details of how those volumes are implemented. For these needs, there is the _StorageClass_ resource. @@ -148,7 +145,11 @@ The `Recycle` reclaim policy is deprecated. Instead, the recommended approach is If supported by the underlying volume plugin, the `Recycle` reclaim policy performs a basic scrub (`rm -rf /thevolume/*`) on the volume and makes it available again for a new claim. -However, an administrator can configure a custom recycler Pod template using the Kubernetes controller manager command line arguments as described [here](/docs/admin/kube-controller-manager/). The custom recycler Pod template must contain a `volumes` specification, as shown in the example below: +However, an administrator can configure a custom recycler Pod template using +the Kubernetes controller manager command line arguments as described in the +[reference](/docs/reference/command-line-tools-reference/kube-controller-manager/). +The custom recycler Pod template must contain a `volumes` specification, as +shown in the example below: ```yaml apiVersion: v1 @@ -253,6 +254,16 @@ FlexVolume resize is possible only when the underlying driver supports resize. Expanding EBS volumes is a time-consuming operation. Also, there is a per-volume quota of one modification every 6 hours. {{< /note >}} +#### Recovering from Failure when Expanding Volumes + +If expanding underlying storage fails, the cluster administrator can manually recover the Persistent Volume Claim (PVC) state and cancel the resize requests. Otherwise, the resize requests are continuously retried by the controller without administrator intervention. + +1. Mark the PersistentVolume(PV) that is bound to the PersistentVolumeClaim(PVC) with `Retain` reclaim policy. +2. Delete the PVC. Since PV has `Retain` reclaim policy - we will not loose any data when we recreate the PVC. +3. Delete the `claimRef` entry from PV specs, so as new PVC can bind to it. This should make the PV `Available`. +4. Re-create the PVC with smaller size than PV and set `volumeName` field of the PVC to the name of the PV. This should bind new PVC to existing PV. +5. Don't forget to restore the reclaim policy of the PV. + ## Types of Persistent Volumes diff --git a/content/en/docs/concepts/storage/storage-classes.md b/content/en/docs/concepts/storage/storage-classes.md index d6b3a9e332..f2c8589db4 100644 --- a/content/en/docs/concepts/storage/storage-classes.md +++ b/content/en/docs/concepts/storage/storage-classes.md @@ -15,8 +15,6 @@ This document describes the concept of a StorageClass in Kubernetes. Familiarity with [volumes](/docs/concepts/storage/volumes/) and [persistent volumes](/docs/concepts/storage/persistent-volumes) is suggested. - - ## Introduction @@ -41,7 +39,7 @@ be updated once they are created. Administrators can specify a default StorageClass just for PVCs that don't request any particular class to bind to: see the -[PersistentVolumeClaim section](/docs/concepts/storage/persistent-volumes/#class-1) +[PersistentVolumeClaim section](/docs/concepts/storage/persistent-volumes/#persistentvolumeclaims) for details. ```yaml @@ -168,11 +166,11 @@ A cluster administrator can address this issue by specifying the `WaitForFirstCo will delay the binding and provisioning of a PersistentVolume until a Pod using the PersistentVolumeClaim is created. PersistentVolumes will be selected or provisioned conforming to the topology that is specified by the Pod's scheduling constraints. These include, but are not limited to, [resource -requirements](/docs/concepts/configuration/manage-compute-resources-container), +requirements](/docs/concepts/configuration/manage-resources-containers/), [node selectors](/docs/concepts/scheduling-eviction/assign-pod-node/#nodeselector), [pod affinity and anti-affinity](/docs/concepts/scheduling-eviction/assign-pod-node/#affinity-and-anti-affinity), -and [taints and tolerations](/docs/concepts/configuration/taint-and-toleration). +and [taints and tolerations](/docs/concepts/scheduling-eviction/taint-and-toleration). The following plugins support `WaitForFirstConsumer` with dynamic provisioning: @@ -244,7 +242,7 @@ parameters: ``` * `type`: `io1`, `gp2`, `sc1`, `st1`. See - [AWS docs](http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/EBSVolumeTypes.html) + [AWS docs](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/EBSVolumeTypes.html) for details. Default: `gp2`. * `zone` (Deprecated): AWS zone. If neither `zone` nor `zones` is specified, volumes are generally round-robin-ed across all active zones where Kubernetes cluster @@ -256,7 +254,7 @@ parameters: * `iopsPerGB`: only for `io1` volumes. I/O operations per second per GiB. AWS volume plugin multiplies this with size of requested volume to compute IOPS of the volume and caps it at 20 000 IOPS (maximum supported by AWS, see - [AWS docs](http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/EBSVolumeTypes.html). + [AWS docs](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/EBSVolumeTypes.html). A string is expected here, i.e. `"10"`, not `10`. * `fsType`: fsType that is supported by kubernetes. Default: `"ext4"`. * `encrypted`: denotes whether the EBS volume should be encrypted or not. @@ -686,7 +684,7 @@ provisioner: kubernetes.io/portworx-volume parameters: repl: "1" snap_interval: "70" - io_priority: "high" + priority_io: "high" ``` @@ -695,7 +693,7 @@ parameters: * `repl`: number of synchronous replicas to be provided in the form of replication factor `1..3` (default: `1`) A string is expected here i.e. `"1"` and not `1`. -* `io_priority`: determines whether the volume will be created from higher +* `priority_io`: determines whether the volume will be created from higher performance or a lower priority storage `high/medium/low` (default: `low`). * `snap_interval`: clock/time interval in minutes for when to trigger snapshots. Snapshots are incremental based on difference with the prior snapshot, 0 diff --git a/content/en/docs/concepts/storage/volumes.md b/content/en/docs/concepts/storage/volumes.md index c3f43f0fa5..70854fb37a 100644 --- a/content/en/docs/concepts/storage/volumes.md +++ b/content/en/docs/concepts/storage/volumes.md @@ -18,10 +18,7 @@ Container starts with a clean state. Second, when running Containers together in a `Pod` it is often necessary to share files between those Containers. The Kubernetes `Volume` abstraction solves both of these problems. -Familiarity with [Pods](/docs/user-guide/pods) is suggested. - - - +Familiarity with [Pods](/docs/concepts/workloads/pods/pod/) is suggested. @@ -100,7 +97,7 @@ We welcome additional contributions. ### awsElasticBlockStore {#awselasticblockstore} An `awsElasticBlockStore` volume mounts an Amazon Web Services (AWS) [EBS -Volume](http://aws.amazon.com/ebs/) into your Pod. Unlike +Volume](https://aws.amazon.com/ebs/) into your Pod. Unlike `emptyDir`, which is erased when a Pod is removed, the contents of an EBS volume are preserved and the volume is merely unmounted. This means that an EBS volume can be pre-populated with data, and that data can be "handed off" @@ -401,8 +398,8 @@ See the [Flocker example](https://github.com/kubernetes/examples/tree/{{< param ### gcePersistentDisk {#gcepersistentdisk} -A `gcePersistentDisk` volume mounts a Google Compute Engine (GCE) [Persistent -Disk](http://cloud.google.com/compute/docs/disks) into your Pod. Unlike +A `gcePersistentDisk` volume mounts a Google Compute Engine (GCE) +[Persistent Disk](https://cloud.google.com/compute/docs/disks) into your Pod. Unlike `emptyDir`, which is erased when a Pod is removed, the contents of a PD are preserved and the volume is merely unmounted. This means that a PD can be pre-populated with data, and that data can be "handed off" between Pods. @@ -537,7 +534,7 @@ spec: ### glusterfs {#glusterfs} -A `glusterfs` volume allows a [Glusterfs](http://www.gluster.org) (an open +A `glusterfs` volume allows a [Glusterfs](https://www.gluster.org) (an open source networked filesystem) volume to be mounted into your Pod. Unlike `emptyDir`, which is erased when a Pod is removed, the contents of a `glusterfs` volume are preserved and the volume is merely unmounted. This @@ -589,7 +586,7 @@ Watch out when using this type of volume, because: able to account for resources used by a `hostPath` * the files or directories created on the underlying hosts are only writable by root. You either need to run your process as root in a - [privileged Container](/docs/user-guide/security-context) or modify the file + [privileged Container](/docs/tasks/configure-pod-container/security-context/) or modify the file permissions on the host to be able to write to a `hostPath` volume #### Example Pod @@ -952,7 +949,7 @@ More details and examples can be found [here](https://github.com/kubernetes/exam ### quobyte {#quobyte} -A `quobyte` volume allows an existing [Quobyte](http://www.quobyte.com) volume to +A `quobyte` volume allows an existing [Quobyte](https://www.quobyte.com) volume to be mounted into your Pod. {{< caution >}} @@ -966,8 +963,8 @@ GitHub project has [instructions](https://github.com/quobyte/quobyte-csi#quobyte ### rbd {#rbd} -An `rbd` volume allows a [Rados Block -Device](http://ceph.com/docs/master/rbd/rbd/) volume to be mounted into your +An `rbd` volume allows a +[Rados Block Device](https://ceph.com/docs/master/rbd/rbd/) volume to be mounted into your Pod. Unlike `emptyDir`, which is erased when a Pod is removed, the contents of a `rbd` volume are preserved and the volume is merely unmounted. This means that a RBD volume can be pre-populated with data, and that data can @@ -1044,7 +1041,7 @@ A Container using a Secret as a [subPath](#using-subpath) volume mount will not receive Secret updates. {{< /note >}} -Secrets are described in more detail [here](/docs/user-guide/secrets). +Secrets are described in more detail [here](/docs/concepts/configuration/secret/). ### storageOS {#storageos} @@ -1244,11 +1241,12 @@ medium of the filesystem holding the kubelet root dir (typically Pods. In the future, we expect that `emptyDir` and `hostPath` volumes will be able to -request a certain amount of space using a [resource](/docs/user-guide/compute-resources) +request a certain amount of space using a [resource](/docs/concepts/configuration/manage-resources-containers/) specification, and to select the type of media to use, for clusters that have several media types. ## Out-of-Tree Volume Plugins + The Out-of-tree volume plugins include the Container Storage Interface (CSI) and FlexVolume. They enable storage vendors to create custom storage plugins without adding them to the Kubernetes repository. @@ -1323,7 +1321,7 @@ persistent volume: of a volume. This map must correspond to the map returned in the `volume.attributes` field of the `CreateVolumeResponse` by the CSI driver as defined in the [CSI spec](https://github.com/container-storage-interface/spec/blob/master/spec.md#createvolume). - The map is passed to the CSI driver via the `volume_attributes` field in the + The map is passed to the CSI driver via the `volume_context` field in the `ControllerPublishVolumeRequest`, `NodeStageVolumeRequest`, and `NodePublishVolumeRequest`. - `controllerPublishSecretRef`: A reference to the secret object containing diff --git a/content/en/docs/concepts/workloads/_index.md b/content/en/docs/concepts/workloads/_index.md index ca394ebd00..1aac095cb5 100644 --- a/content/en/docs/concepts/workloads/_index.md +++ b/content/en/docs/concepts/workloads/_index.md @@ -1,5 +1,7 @@ --- title: "Workloads" weight: 50 +description: > + Understand Pods, the smallest deployable compute object in Kubernetes, and the higher-level abstractions that help you to run them. --- diff --git a/content/en/docs/concepts/workloads/controllers/daemonset.md b/content/en/docs/concepts/workloads/controllers/daemonset.md index 7f1b5c4630..0d1e1d34b3 100644 --- a/content/en/docs/concepts/workloads/controllers/daemonset.md +++ b/content/en/docs/concepts/workloads/controllers/daemonset.md @@ -26,9 +26,6 @@ In a simple case, one DaemonSet, covering all nodes, would be used for each type A more complex setup might use multiple DaemonSets for a single type of daemon, but with different flags and/or different memory and cpu requests for different hardware types. - - - ## Writing a DaemonSet Spec @@ -48,7 +45,8 @@ kubectl apply -f https://k8s.io/examples/controllers/daemonset.yaml ### Required Fields As with all other Kubernetes config, a DaemonSet needs `apiVersion`, `kind`, and `metadata` fields. For -general information about working with config files, see [deploying applications](/docs/user-guide/deploying-applications/), +general information about working with config files, see +[running stateless applications](/docs/tasks/run-application/run-stateless-application-deployment/), [configuring containers](/docs/tasks/), and [object management using kubectl](/docs/concepts/overview/working-with-objects/object-management/) documents. The name of a DaemonSet object must be a valid @@ -60,7 +58,7 @@ A DaemonSet also needs a [`.spec`](https://git.k8s.io/community/contributors/dev The `.spec.template` is one of the required fields in `.spec`. -The `.spec.template` is a [pod template](/docs/concepts/workloads/pods/pod-overview/#pod-templates). It has exactly the same schema as a [Pod](/docs/concepts/workloads/pods/pod/), except it is nested and does not have an `apiVersion` or `kind`. +The `.spec.template` is a [pod template](/docs/concepts/workloads/pods/#pod-templates). It has exactly the same schema as a {{< glossary_tooltip text="Pod" term_id="pod" >}}, except it is nested and does not have an `apiVersion` or `kind`. In addition to required fields for a Pod, a Pod template in a DaemonSet has to specify appropriate labels (see [pod selector](#pod-selector)). @@ -71,7 +69,7 @@ A Pod Template in a DaemonSet must have a [`RestartPolicy`](/docs/concepts/workl ### Pod Selector The `.spec.selector` field is a pod selector. It works the same as the `.spec.selector` of -a [Job](/docs/concepts/jobs/run-to-completion-finite-workloads/). +a [Job](/docs/concepts/workloads/controllers/job/). As of Kubernetes 1.8, you must specify a pod selector that matches the labels of the `.spec.template`. The pod selector will no longer be defaulted when left empty. Selector @@ -147,7 +145,7 @@ automatically to DaemonSet Pods. The default scheduler ignores ### Taints and Tolerations Although Daemon Pods respect -[taints and tolerations](/docs/concepts/configuration/taint-and-toleration), +[taints and tolerations](/docs/concepts/scheduling-eviction/taint-and-toleration/), the following tolerations are added to DaemonSet Pods automatically according to the related features. @@ -213,7 +211,7 @@ use a DaemonSet rather than creating individual Pods. ### Static Pods It is possible to create Pods by writing a file to a certain directory watched by Kubelet. These -are called [static pods](/docs/concepts/cluster-administration/static-pod/). +are called [static pods](/docs/tasks/configure-pod-container/static-pod/). Unlike DaemonSet, static Pods cannot be managed with kubectl or other Kubernetes API clients. Static Pods do not depend on the apiserver, making them useful in cluster bootstrapping cases. Also, static Pods may be deprecated in the future. diff --git a/content/en/docs/concepts/workloads/controllers/deployment.md b/content/en/docs/concepts/workloads/controllers/deployment.md index 6b117cdc44..6e6b8c8ecf 100644 --- a/content/en/docs/concepts/workloads/controllers/deployment.md +++ b/content/en/docs/concepts/workloads/controllers/deployment.md @@ -13,8 +13,8 @@ weight: 30 -A _Deployment_ provides declarative updates for [Pods](/docs/concepts/workloads/pods/pod/) and -[ReplicaSets](/docs/concepts/workloads/controllers/replicaset/). +A _Deployment_ provides declarative updates for {{< glossary_tooltip text="Pods" term_id="pod" >}} +{{< glossary_tooltip term_id="replica-set" text="ReplicaSets" >}}. You describe a _desired state_ in a Deployment, and the Deployment {{< glossary_tooltip term_id="controller" >}} changes the actual state to the desired state at a controlled rate. You can define Deployments to create new ReplicaSets, or to remove existing Deployments and adopt all their resources with new Deployments. @@ -22,9 +22,6 @@ You describe a _desired state_ in a Deployment, and the Deployment {{< glossary_ Do not manage ReplicaSets owned by a Deployment. Consider opening an issue in the main Kubernetes repository if your use case is not covered below. {{< /note >}} - - - ## Use Case @@ -1042,7 +1039,8 @@ can create multiple Deployments, one for each release, following the canary patt ## Writing a Deployment Spec As with all other Kubernetes configs, a Deployment needs `.apiVersion`, `.kind`, and `.metadata` fields. -For general information about working with config files, see [deploying applications](/docs/tutorials/stateless-application/run-stateless-application-deployment/), +For general information about working with config files, see +[deploying applications](/docs/tasks/run-application/run-stateless-application-deployment/), configuring containers, and [using kubectl to manage resources](/docs/concepts/overview/working-with-objects/object-management/) documents. The name of a Deployment object must be a valid [DNS subdomain name](/docs/concepts/overview/working-with-objects/names#dns-subdomain-names). @@ -1053,8 +1051,7 @@ A Deployment also needs a [`.spec` section](https://git.k8s.io/community/contrib The `.spec.template` and `.spec.selector` are the only required field of the `.spec`. -The `.spec.template` is a [Pod template](/docs/concepts/workloads/pods/pod-overview/#pod-templates). It has exactly the same schema as a [Pod](/docs/concepts/workloads/pods/pod/), except it is nested and does not have an -`apiVersion` or `kind`. +The `.spec.template` is a [Pod template](/docs/concepts/workloads/pods/#pod-templates). It has exactly the same schema as a {{< glossary_tooltip text="Pod" term_id="pod" >}}, except it is nested and does not have an `apiVersion` or `kind`. In addition to required fields for a Pod, a Pod template in a Deployment must specify appropriate labels and an appropriate restart policy. For labels, make sure not to overlap with other controllers. See [selector](#selector)). @@ -1068,7 +1065,7 @@ allowed, which is the default if not specified. ### Selector -`.spec.selector` is an required field that specifies a [label selector](/docs/concepts/overview/working-with-objects/labels/) +`.spec.selector` is a required field that specifies a [label selector](/docs/concepts/overview/working-with-objects/labels/) for the Pods targeted by this Deployment. `.spec.selector` must match `.spec.template.metadata.labels`, or it will be rejected by the API. @@ -1155,10 +1152,6 @@ created Pod should be ready without any of its containers crashing, for it to be This defaults to 0 (the Pod will be considered available as soon as it is ready). To learn more about when a Pod is considered ready, see [Container Probes](/docs/concepts/workloads/pods/pod-lifecycle/#container-probes). -### Rollback To - -Field `.spec.rollbackTo` has been deprecated in API versions `extensions/v1beta1` and `apps/v1beta1`, and is no longer supported in API versions starting `apps/v1beta2`. Instead, `kubectl rollout undo` as introduced in [Rolling Back to a Previous Revision](#rolling-back-to-a-previous-revision) should be used. - ### Revision History Limit A Deployment's revision history is stored in the ReplicaSets it controls. diff --git a/content/en/docs/concepts/workloads/controllers/garbage-collection.md b/content/en/docs/concepts/workloads/controllers/garbage-collection.md index a20951a35e..79cc905f58 100644 --- a/content/en/docs/concepts/workloads/controllers/garbage-collection.md +++ b/content/en/docs/concepts/workloads/controllers/garbage-collection.md @@ -111,12 +111,6 @@ To control the cascading deletion policy, set the `propagationPolicy` field on the `deleteOptions` argument when deleting an Object. Possible values include "Orphan", "Foreground", or "Background". -Prior to Kubernetes 1.9, the default garbage collection policy for many controller resources was `orphan`. -This included ReplicationController, ReplicaSet, StatefulSet, DaemonSet, and -Deployment. For kinds in the `extensions/v1beta1`, `apps/v1beta1`, and `apps/v1beta2` group versions, unless you -specify otherwise, dependent objects are orphaned by default. In Kubernetes 1.9, for all kinds in the `apps/v1` -group version, dependent objects are deleted by default. - Here's an example that deletes dependents in background: ```shell diff --git a/content/en/docs/concepts/workloads/controllers/job.md b/content/en/docs/concepts/workloads/controllers/job.md index 45fa66bd3d..479858e3d4 100644 --- a/content/en/docs/concepts/workloads/controllers/job.md +++ b/content/en/docs/concepts/workloads/controllers/job.md @@ -24,9 +24,6 @@ due to a node hardware failure or a node reboot). You can also use a Job to run multiple Pods in parallel. - - - ## Running an example Job @@ -122,7 +119,8 @@ A Job also needs a [`.spec` section](https://git.k8s.io/community/contributors/d The `.spec.template` is the only required field of the `.spec`. -The `.spec.template` is a [pod template](/docs/concepts/workloads/pods/pod-overview/#pod-templates). It has exactly the same schema as a [pod](/docs/user-guide/pods), except it is nested and does not have an `apiVersion` or `kind`. + +The `.spec.template` is a [pod template](/docs/concepts/workloads/pods/#pod-templates). It has exactly the same schema as a {{< glossary_tooltip text="Pod" term_id="pod" >}}, except it is nested and does not have an `apiVersion` or `kind`. In addition to required fields for a Pod, a pod template in a Job must specify appropriate labels (see [pod selector](#pod-selector)) and an appropriate restart policy. @@ -215,12 +213,9 @@ To do so, set `.spec.backoffLimit` to specify the number of retries before considering a Job as failed. The back-off limit is set by default to 6. Failed Pods associated with the Job are recreated by the Job controller with an exponential back-off delay (10s, 20s, 40s ...) capped at six minutes. The -back-off count is reset if no new failed Pods appear before the Job's next -status check. +back-off count is reset when a Job's Pod is deleted or successful without any +other Pods for the Job failing around that time. -{{< note >}} -Issue [#54870](https://github.com/kubernetes/kubernetes/issues/54870) still exists for versions of Kubernetes prior to version 1.12 -{{< /note >}} {{< note >}} If your job has `restartPolicy = "OnFailure"`, keep in mind that your container running the Job will be terminated once the job backoff limit has been reached. This can make debugging the Job's executable more difficult. We suggest setting @@ -453,7 +448,7 @@ requires only a single Pod. ### Replication Controller -Jobs are complementary to [Replication Controllers](/docs/user-guide/replication-controller). +Jobs are complementary to [Replication Controllers](/docs/concepts/workloads/controllers/replicationcontroller/). A Replication Controller manages Pods which are not expected to terminate (e.g. web servers), and a Job manages Pods that are expected to terminate (e.g. batch tasks). @@ -477,4 +472,3 @@ object, but maintains complete control over what Pods are created and how work i ## Cron Jobs {#cron-jobs} You can use a [`CronJob`](/docs/concepts/workloads/controllers/cron-jobs/) to create a Job that will run at specified times/dates, similar to the Unix tool `cron`. - diff --git a/content/en/docs/concepts/workloads/controllers/replicationcontroller.md b/content/en/docs/concepts/workloads/controllers/replicationcontroller.md index 2cc8284940..941d8f585e 100644 --- a/content/en/docs/concepts/workloads/controllers/replicationcontroller.md +++ b/content/en/docs/concepts/workloads/controllers/replicationcontroller.md @@ -23,9 +23,6 @@ A _ReplicationController_ ensures that a specified number of pod replicas are ru time. In other words, a ReplicationController makes sure that a pod or a homogeneous set of pods is always up and available. - - - ## How a ReplicationController Works @@ -126,7 +123,7 @@ A ReplicationController also needs a [`.spec` section](https://git.k8s.io/commun The `.spec.template` is the only required field of the `.spec`. -The `.spec.template` is a [pod template](/docs/concepts/workloads/pods/pod-overview/#pod-templates). It has exactly the same schema as a [pod](/docs/concepts/workloads/pods/pod/), except it is nested and does not have an `apiVersion` or `kind`. +The `.spec.template` is a [pod template](/docs/concepts/workloads/pods/#pod-templates). It has exactly the same schema as a {{< glossary_tooltip text="Pod" term_id="pod" >}}, except it is nested and does not have an `apiVersion` or `kind`. In addition to required fields for a Pod, a pod template in a ReplicationController must specify appropriate labels and an appropriate restart policy. For labels, make sure not to overlap with other controllers. See [pod selector](#pod-selector). @@ -134,7 +131,7 @@ labels and an appropriate restart policy. For labels, make sure not to overlap w Only a [`.spec.template.spec.restartPolicy`](/docs/concepts/workloads/pods/pod-lifecycle/#restart-policy) equal to `Always` is allowed, which is the default if not specified. For local container restarts, ReplicationControllers delegate to an agent on the node, -for example the [Kubelet](/docs/admin/kubelet/) or Docker. +for example the [Kubelet](/docs/reference/command-line-tools-reference/kubelet/) or Docker. ### Labels on the ReplicationController @@ -214,7 +211,7 @@ The ReplicationController makes it easy to scale the number of replicas up or do The ReplicationController is designed to facilitate rolling updates to a service by replacing pods one-by-one. -As explained in [#1353](http://issue.k8s.io/1353), the recommended approach is to create a new ReplicationController with 1 replica, scale the new (+1) and old (-1) controllers one by one, and then delete the old controller after it reaches 0 replicas. This predictably updates the set of pods regardless of unexpected failures. +As explained in [#1353](https://issue.k8s.io/1353), the recommended approach is to create a new ReplicationController with 1 replica, scale the new (+1) and old (-1) controllers one by one, and then delete the old controller after it reaches 0 replicas. This predictably updates the set of pods regardless of unexpected failures. Ideally, the rolling update controller would take application readiness into account, and would ensure that a sufficient number of pods were productively serving at any given time. @@ -239,11 +236,11 @@ Pods created by a ReplicationController are intended to be fungible and semantic ## Responsibilities of the ReplicationController -The ReplicationController simply ensures that the desired number of pods matches its label selector and are operational. Currently, only terminated pods are excluded from its count. In the future, [readiness](http://issue.k8s.io/620) and other information available from the system may be taken into account, we may add more controls over the replacement policy, and we plan to emit events that could be used by external clients to implement arbitrarily sophisticated replacement and/or scale-down policies. +The ReplicationController simply ensures that the desired number of pods matches its label selector and are operational. Currently, only terminated pods are excluded from its count. In the future, [readiness](https://issue.k8s.io/620) and other information available from the system may be taken into account, we may add more controls over the replacement policy, and we plan to emit events that could be used by external clients to implement arbitrarily sophisticated replacement and/or scale-down policies. -The ReplicationController is forever constrained to this narrow responsibility. It itself will not perform readiness nor liveness probes. Rather than performing auto-scaling, it is intended to be controlled by an external auto-scaler (as discussed in [#492](http://issue.k8s.io/492)), which would change its `replicas` field. We will not add scheduling policies (for example, [spreading](http://issue.k8s.io/367#issuecomment-48428019)) to the ReplicationController. Nor should it verify that the pods controlled match the currently specified template, as that would obstruct auto-sizing and other automated processes. Similarly, completion deadlines, ordering dependencies, configuration expansion, and other features belong elsewhere. We even plan to factor out the mechanism for bulk pod creation ([#170](http://issue.k8s.io/170)). +The ReplicationController is forever constrained to this narrow responsibility. It itself will not perform readiness nor liveness probes. Rather than performing auto-scaling, it is intended to be controlled by an external auto-scaler (as discussed in [#492](https://issue.k8s.io/492)), which would change its `replicas` field. We will not add scheduling policies (for example, [spreading](https://issue.k8s.io/367#issuecomment-48428019)) to the ReplicationController. Nor should it verify that the pods controlled match the currently specified template, as that would obstruct auto-sizing and other automated processes. Similarly, completion deadlines, ordering dependencies, configuration expansion, and other features belong elsewhere. We even plan to factor out the mechanism for bulk pod creation ([#170](https://issue.k8s.io/170)). -The ReplicationController is intended to be a composable building-block primitive. We expect higher-level APIs and/or tools to be built on top of it and other complementary primitives for user convenience in the future. The "macro" operations currently supported by kubectl (run, scale) are proof-of-concept examples of this. For instance, we could imagine something like [Asgard](http://techblog.netflix.com/2012/06/asgard-web-based-cloud-management-and.html) managing ReplicationControllers, auto-scalers, services, scheduling policies, canaries, etc. +The ReplicationController is intended to be a composable building-block primitive. We expect higher-level APIs and/or tools to be built on top of it and other complementary primitives for user convenience in the future. The "macro" operations currently supported by kubectl (run, scale) are proof-of-concept examples of this. For instance, we could imagine something like [Asgard](https://techblog.netflix.com/2012/06/asgard-web-based-cloud-management-and.html) managing ReplicationControllers, auto-scalers, services, scheduling policies, canaries, etc. ## API Object @@ -271,7 +268,7 @@ Unlike in the case where a user directly created pods, a ReplicationController r ### Job -Use a [`Job`](/docs/concepts/jobs/run-to-completion-finite-workloads/) instead of a ReplicationController for pods that are expected to terminate on their own +Use a [`Job`](/docs/concepts/workloads/controllers/job/) instead of a ReplicationController for pods that are expected to terminate on their own (that is, batch jobs). ### DaemonSet @@ -283,6 +280,6 @@ safe to terminate when the machine is otherwise ready to be rebooted/shutdown. ## For more information -Read [Run Stateless AP Replication Controller](/docs/tutorials/stateless-application/run-stateless-ap-replication-controller/). +Read [Run Stateless Application Deployment](/docs/tasks/run-application/run-stateless-application-deployment/). diff --git a/content/en/docs/concepts/workloads/controllers/statefulset.md b/content/en/docs/concepts/workloads/controllers/statefulset.md index 4f8429d668..fd9833356a 100644 --- a/content/en/docs/concepts/workloads/controllers/statefulset.md +++ b/content/en/docs/concepts/workloads/controllers/statefulset.md @@ -141,6 +141,18 @@ As each Pod is created, it gets a matching DNS subdomain, taking the form: `$(podname).$(governing service domain)`, where the governing service is defined by the `serviceName` field on the StatefulSet. +Depending on how DNS is configured in your cluster, you may not be able to look up the DNS +name for a newly-run Pod immediately. This behavior can occur when other clients in the +cluster have already sent queries for the hostname of the Pod before it was created. +Negative caching (normal in DNS) means that the results of previous failed lookups are +remembered and reused, even after the Pod is running, for at least a few seconds. + +If you need to discover Pods promptly after they are created, you have a few options: + +- Query the Kubernetes API directly (for example, using a watch) rather than relying on DNS lookups. +- Decrease the time of caching in your Kubernetes DNS provider (tpyically this means editing the config map for CoreDNS, which currently caches for 30 seconds). + + As mentioned in the [limitations](#limitations) section, you are responsible for creating the [Headless Service](/docs/concepts/services-networking/service/#headless-services) responsible for the network identity of the pods. @@ -188,7 +200,7 @@ The StatefulSet should not specify a `pod.Spec.TerminationGracePeriodSeconds` of When the nginx example above is created, three Pods will be deployed in the order web-0, web-1, web-2. web-1 will not be deployed before web-0 is -[Running and Ready](/docs/user-guide/pod-states/), and web-2 will not be deployed until +[Running and Ready](/docs/concepts/workloads/pods/pod-lifecycle/), and web-2 will not be deployed until web-1 is Running and Ready. If web-0 should fail, after web-1 is Running and Ready, but before web-2 is launched, web-2 will not be launched until web-0 is successfully relaunched and becomes Running and Ready. @@ -278,5 +290,3 @@ StatefulSet will then begin to recreate the Pods using the reverted template. * Follow an example of [deploying Cassandra with Stateful Sets](/docs/tutorials/stateful-application/cassandra/). * Follow an example of [running a replicated stateful application](/docs/tasks/run-application/run-replicated-stateful-application/). - - diff --git a/content/en/docs/concepts/workloads/controllers/ttlafterfinished.md b/content/en/docs/concepts/workloads/controllers/ttlafterfinished.md index 3a43d5e7b7..6b6ad65e0a 100644 --- a/content/en/docs/concepts/workloads/controllers/ttlafterfinished.md +++ b/content/en/docs/concepts/workloads/controllers/ttlafterfinished.md @@ -20,12 +20,6 @@ Alpha Disclaimer: this feature is currently alpha, and can be enabled with both [feature gate](/docs/reference/command-line-tools-reference/feature-gates/) `TTLAfterFinished`. - - - - - - ## TTL Controller @@ -82,9 +76,7 @@ very small. Please be aware of this risk when setting a non-zero TTL. ## {{% heading "whatsnext" %}} +* [Clean up Jobs automatically](/docs/concepts/workloads/controllers/job/#clean-up-finished-jobs-automatically) -[Clean up Jobs automatically](/docs/concepts/workloads/controllers/jobs-run-to-completion/#clean-up-finished-jobs-automatically) - -[Design doc](https://github.com/kubernetes/enhancements/blob/master/keps/sig-apps/0026-ttl-after-finish.md) - +* [Design doc](https://github.com/kubernetes/enhancements/blob/master/keps/sig-apps/0026-ttl-after-finish.md) diff --git a/content/en/docs/concepts/workloads/pods/_index.md b/content/en/docs/concepts/workloads/pods/_index.md old mode 100755 new mode 100644 index a105f18fb3..90dd7b5618 --- a/content/en/docs/concepts/workloads/pods/_index.md +++ b/content/en/docs/concepts/workloads/pods/_index.md @@ -1,5 +1,271 @@ --- -title: "Pods" +reviewers: +- erictune +title: Pods +content_type: concept weight: 10 +no_list: true +card: + name: concepts + weight: 60 --- + + +_Pods_ are the smallest deployable units of computing that you can create and manage in Kubernetes. + +A _Pod_ (as in a pod of whales or pea pod) is a group of one or more +{{< glossary_tooltip text="containers" term_id="container" >}}, with shared storage/network resources, and a specification +for how to run the containers. A Pod's contents are always co-located and +co-scheduled, and run in a shared context. A Pod models an +application-specific "logical host": it contains one or more application +containers which are relatively tightly coupled. +In non-cloud contexts, applications executed on the same physical or virtual machine are analogous to cloud applications executed on the same logical host. + +As well as application containers, a Pod can contain +[init containers](/docs/concepts/workloads/pods/init-containers/) that run +during Pod startup. You can also inject +[ephemeral containers](/docs/concepts/workloads/pods/ephemeral-containers/) +for debugging if your cluster offers this. + + + +## What is a Pod? + +{{< note >}} +While Kubernetes supports more +{{< glossary_tooltip text="container runtimes" term_id="container-runtime" >}} +than just Docker, [Docker](https://www.docker.com/) is the most commonly known +runtime, and it helps to describe Pods using some terminology from Docker. +{{< /note >}} + +The shared context of a Pod is a set of Linux namespaces, cgroups, and +potentially other facets of isolation - the same things that isolate a Docker +container. Within a Pod's context, the individual applications may have +further sub-isolations applied. + +In terms of Docker concepts, a Pod is similar to a group of Docker containers +with shared namespaces and shared filesystem volumes. + +## Using Pods + +Usually you don't need to create Pods directly, even singleton Pods. Instead, create them using workload resources such as {{< glossary_tooltip text="Deployment" +term_id="deployment" >}} or {{< glossary_tooltip text="Job" term_id="job" >}}. +If your Pods need to track state, consider the +{{< glossary_tooltip text="StatefulSet" term_id="statefulset" >}} resource. + +Pods in a Kubernetes cluster are used in two main ways: + +* **Pods that run a single container**. The "one-container-per-Pod" model is the + most common Kubernetes use case; in this case, you can think of a Pod as a + wrapper around a single container; Kubernetes manages Pods rather than managing + the containers directly. +* **Pods that run multiple containers that need to work together**. A Pod can + encapsulate an application composed of multiple co-located containers that are + tightly coupled and need to share resources. These co-located containers + form a single cohesive unit of service—for example, one container serving data + stored in a shared volume to the public, while a separate _sidecar_ container + refreshes or updates those files. + The Pod wraps these containers, storage resources, and an ephemeral network + identity together as a single unit. + + {{< note >}} + Grouping multiple co-located and co-managed containers in a single Pod is a + relatively advanced use case. You should use this pattern only in specific + instances in which your containers are tightly coupled. + {{< /note >}} + +Each Pod is meant to run a single instance of a given application. If you want to +scale your application horizontally (to provide more overall resources by running +more instances), you should use multiple Pods, one for each instance. In +Kubernetes, this is typically referred to as _replication_. +Replicated Pods are usually created and managed as a group by a workload resource +and its {{< glossary_tooltip text="controller" term_id="controller" >}}. + +See [Pods and controllers](#pods-and-controllers) for more information on how +Kubernetes uses workload resources, and their controllers, to implement application +scaling and auto-healing. + +### How Pods manage multiple containers + +Pods are designed to support multiple cooperating processes (as containers) that form +a cohesive unit of service. The containers in a Pod are automatically co-located and +co-scheduled on the same physical or virtual machine in the cluster. The containers +can share resources and dependencies, communicate with one another, and coordinate +when and how they are terminated. + +For example, you might have a container that +acts as a web server for files in a shared volume, and a separate "sidecar" container +that updates those files from a remote source, as in the following diagram: + +{{< figure src="/images/docs/pod.svg" alt="example pod diagram" width="50%" >}} + +Some Pods have {{< glossary_tooltip text="init containers" term_id="init-container" >}} as well as {{< glossary_tooltip text="app containers" term_id="app-container" >}}. Init containers run and complete before the app containers are started. + +Pods natively provide two kinds of shared resources for their constituent containers: +[networking](#pod-networking) and [storage](#pod-storage). + +## Working with Pods + +You'll rarely create individual Pods directly in Kubernetes—even singleton Pods. This +is because Pods are designed as relatively ephemeral, disposable entities. When +a Pod gets created (directly by you, or indirectly by a +{{< glossary_tooltip text="controller" term_id="controller" >}}), the new Pod is +scheduled to run on a {{< glossary_tooltip term_id="node" >}} in your cluster. +The Pod remains on that node until the Pod finishes execution, the Pod object is deleted, +the Pod is *evicted* for lack of resources, or the node fails. + +{{< note >}} +Restarting a container in a Pod should not be confused with restarting a Pod. A Pod +is not a process, but an environment for running container(s). A Pod persists until +it is deleted. +{{< /note >}} + +When you create the manifest for a Pod object, make sure the name specified is a valid +[DNS subdomain name](/docs/concepts/overview/working-with-objects/names#dns-subdomain-names). + +### Pods and controllers + +You can use workload resources to create and manage multiple Pods for you. A controller +for the resource handles replication and rollout and automatic healing in case of +Pod failure. For example, if a Node fails, a controller notices that Pods on that +Node have stopped working and creates a replacement Pod. The scheduler places the +replacement Pod onto a healthy Node. + +Here are some examples of workload resources that manage one or more Pods: + +* {{< glossary_tooltip text="Deployment" term_id="deployment" >}} +* {{< glossary_tooltip text="StatefulSet" term_id="statefulset" >}} +* {{< glossary_tooltip text="DaemonSet" term_id="daemonset" >}} + +### Pod templates + +Controllers for {{< glossary_tooltip text="workload" term_id="workload" >}} resources create Pods +from a _pod template_ and manage those Pods on your behalf. + +PodTemplates are specifications for creating Pods, and are included in workload resources such as +[Deployments](/docs/concepts/workloads/controllers/deployment/), +[Jobs](/docs/concepts/jobs/run-to-completion-finite-workloads/), and +[DaemonSets](/docs/concepts/workloads/controllers/daemonset/). + +Each controller for a workload resource uses the `PodTemplate` inside the workload +object to make actual Pods. The `PodTemplate` is part of the desired state of whatever +workload resource you used to run your app. + +The sample below is a manifest for a simple Job with a `template` that starts one +container. The container in that Pod prints a message then pauses. + +```yaml +apiVersion: batch/v1 +kind: Job +metadata: + name: hello +spec: + template: + # This is the pod template + spec: + containers: + - name: hello + image: busybox + command: ['sh', '-c', 'echo "Hello, Kubernetes!" && sleep 3600'] + restartPolicy: OnFailure + # The pod template ends here +``` + +Modifying the pod template or switching to a new pod template has no effect on the +Pods that already exist. Pods do not receive template updates directly. Instead, +a new Pod is created to match the revised pod template. + +For example, the deployment controller ensures that the running Pods match the current +pod template for each Deployment object. If the template is updated, the Deployment has +to remove the existing Pods and create new Pods based on the updated template. Each workload +resource implements its own rules for handling changes to the Pod template. + +On Nodes, the {{< glossary_tooltip term_id="kubelet" text="kubelet" >}} does not +directly observe or manage any of the details around pod templates and updates; those +details are abstracted away. That abstraction and separation of concerns simplifies +system semantics, and makes it feasible to extend the cluster's behavior without +changing existing code. + +## Resource sharing and communication + +Pods enable data sharing and communication among their constituent +containers. + +### Storage in Pods {#pod-storage} + +A Pod can specify a set of shared storage +{{< glossary_tooltip text="volumes" term_id="volume" >}}. All containers +in the Pod can access the shared volumes, allowing those containers to +share data. Volumes also allow persistent data in a Pod to survive +in case one of the containers within needs to be restarted. See +[Storage](/docs/concepts/storage/) for more information on how +Kubernetes implements shared storage and makes it available to Pods. + +### Pod networking + +Each Pod is assigned a unique IP address for each address family. Every +container in a Pod shares the network namespace, including the IP address and +network ports. Inside a Pod (and **only** then), the containers that belong to the Pod +can communicate with one another using `localhost`. When containers in a Pod communicate +with entities *outside the Pod*, +they must coordinate how they use the shared network resources (such as ports). +Within a Pod, containers share an IP address and port space, and +can find each other via `localhost`. The containers in a Pod can also communicate +with each other using standard inter-process communications like SystemV semaphores +or POSIX shared memory. Containers in different Pods have distinct IP addresses +and can not communicate by IPC without +[special configuration](/docs/concepts/policy/pod-security-policy/). +Containers that want to interact with a container running in a different Pod can +use IP networking to comunicate. + +Containers within the Pod see the system hostname as being the same as the configured +`name` for the Pod. There's more about this in the [networking](/docs/concepts/cluster-administration/networking/) +section. + +## Privileged mode for containers + +Any container in a Pod can enable privileged mode, using the `privileged` flag on the [security context](/docs/tasks/configure-pod-container/security-context/) of the container spec. This is useful for containers that want to use operating system administrative capabilities such as manipulating the network stack or accessing hardware devices. +Processes within a privileged container get almost the same privileges that are available to processes outside a container. + +{{< note >}} +Your {{< glossary_tooltip text="container runtime" term_id="container-runtime" >}} must support the concept of a privileged container for this setting to be relevant. +{{< /note >}} + +## Static Pods + +_Static Pods_ are managed directly by the kubelet daemon on a specific node, +without the {{< glossary_tooltip text="API server" term_id="kube-apiserver" >}} +observing them. +Whereas most Pods are managed by the control plane (for example, a +{{< glossary_tooltip text="Deployment" term_id="deployment" >}}), for static +Pods, the kubelet directly supervises each static Pod (and restarts it if it fails). + +Static Pods are always bound to one {{< glossary_tooltip term_id="kubelet" >}} on a specific node. +The main use for static Pods is to run a self-hosted control plane: in other words, +using the kubelet to supervise the individual [control plane components](/docs/concepts/overview/components/#control-plane-components). + +The kubelet automatically tries to create a {{< glossary_tooltip text="mirror Pod" term_id="mirror-pod" >}} +on the Kubernetes API server for each static Pod. +This means that the Pods running on a node are visible on the API server, +but cannot be controlled from there. + +## {{% heading "whatsnext" %}} + +* Learn about the [lifecycle of a Pod](/docs/concepts/workloads/pods/pod-lifecycle/). +* Learn about [PodPresets](/docs/concepts/workloads/pods/podpreset/). +* Lean about [RuntimeClass](/docs/concepts/containers/runtime-class/) and how you can use it to + configure different Pods with different container runtime configurations. +* Read about [Pod topology spread constraints](/docs/concepts/workloads/pods/pod-topology-spread-constraints/). +* Read about [PodDisruptionBudget](/docs/concepts/workloads/pods/disruptions/) and how you can use it to manage application availability during disruptions. +* Pod is a top-level resource in the Kubernetes REST API. + The [Pod](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#pod-v1-core) + object definition describes the object in detail. +* [The Distributed System Toolkit: Patterns for Composite Containers](https://kubernetes.io/blog/2015/06/the-distributed-system-toolkit-patterns) explains common layouts for Pods with more than one container. + +To understand the context for why Kubernetes wraps a common Pod API in other resources (such as {{< glossary_tooltip text="StatefulSets" term_id="statefulset" >}} or {{< glossary_tooltip text="Deployments" term_id="deployment" >}}, you can read about the prior art, including: + * [Aurora](http://aurora.apache.org/documentation/latest/reference/configuration/#job-schema) + * [Borg](https://research.google.com/pubs/pub43438.html) + * [Marathon](https://mesosphere.github.io/marathon/docs/rest-api.html) + * [Omega](https://research.google/pubs/pub41684/) + * [Tupperware](https://engineering.fb.com/data-center-engineering/tupperware/). diff --git a/content/en/docs/concepts/workloads/pods/disruptions.md b/content/en/docs/concepts/workloads/pods/disruptions.md index 589bde5668..78e8b39a47 100644 --- a/content/en/docs/concepts/workloads/pods/disruptions.md +++ b/content/en/docs/concepts/workloads/pods/disruptions.md @@ -11,17 +11,14 @@ weight: 60 This guide is for application owners who want to build highly available applications, and thus need to understand -what types of Disruptions can happen to Pods. +what types of disruptions can happen to Pods. -It is also for Cluster Administrators who want to perform automated +It is also for cluster administrators who want to perform automated cluster actions, like upgrading and autoscaling clusters. - - - -## Voluntary and Involuntary Disruptions +## Voluntary and involuntary disruptions Pods do not disappear until someone (a person or a controller) destroys them, or there is an unavoidable hardware or system software error. @@ -48,7 +45,7 @@ Administrator. Typical application owner actions include: - updating a deployment's pod template causing a restart - directly deleting a pod (e.g. by accident) -Cluster Administrator actions include: +Cluster administrator actions include: - [Draining a node](/docs/tasks/administer-cluster/safely-drain-node/) for repair or upgrade. - Draining a node from a cluster to scale the cluster down (learn about @@ -68,19 +65,19 @@ Not all voluntary disruptions are constrained by Pod Disruption Budgets. For exa deleting deployments or pods bypasses Pod Disruption Budgets. {{< /caution >}} -## Dealing with Disruptions +## Dealing with disruptions Here are some ways to mitigate involuntary disruptions: -- Ensure your pod [requests the resources](/docs/tasks/configure-pod-container/assign-cpu-ram-container) it needs. +- Ensure your pod [requests the resources](/docs/tasks/configure-pod-container/assign-memory-resource) it needs. - Replicate your application if you need higher availability. (Learn about running replicated -[stateless](/docs/tasks/run-application/run-stateless-application-deployment/) -and [stateful](/docs/tasks/run-application/run-replicated-stateful-application/) applications.) + [stateless](/docs/tasks/run-application/run-stateless-application-deployment/) + and [stateful](/docs/tasks/run-application/run-replicated-stateful-application/) applications.) - For even higher availability when running replicated applications, -spread applications across racks (using -[anti-affinity](/docs/user-guide/node-selection/#inter-pod-affinity-and-anti-affinity-beta-feature)) -or across zones (if using a -[multi-zone cluster](/docs/setup/multiple-zones).) + spread applications across racks (using + [anti-affinity](/docs/user-guide/node-selection/#inter-pod-affinity-and-anti-affinity-beta-feature)) + or across zones (if using a + [multi-zone cluster](/docs/setup/multiple-zones).) The frequency of voluntary disruptions varies. On a basic Kubernetes cluster, there are no voluntary disruptions at all. However, your cluster administrator or hosting provider @@ -90,58 +87,58 @@ of cluster (node) autoscaling may cause voluntary disruptions to defragment and Your cluster administrator or hosting provider should have documented what level of voluntary disruptions, if any, to expect. -Kubernetes offers features to help run highly available applications at the same -time as frequent voluntary disruptions. We call this set of features -*Disruption Budgets*. - -## How Disruption Budgets Work +## Pod disruption budgets {{< feature-state for_k8s_version="v1.5" state="beta" >}} -An Application Owner can create a `PodDisruptionBudget` object (PDB) for each application. -A PDB limits the number of pods of a replicated application that are down simultaneously from -voluntary disruptions. For example, a quorum-based application would +Kubernetes offers features to help you run highly available applications even when you +introduce frequent voluntary disruptions. + +As an application owner, you can create a PodDisruptionBudget (PDB) for each application. +A PDB limits the number of Pods of a replicated application that are down simultaneously from +voluntary disruptions. For example, a quorum-based application would like to ensure that the number of replicas running is never brought below the number needed for a quorum. A web front end might want to ensure that the number of replicas serving load never falls below a certain percentage of the total. Cluster managers and hosting providers should use tools which -respect Pod Disruption Budgets by calling the [Eviction API](/docs/tasks/administer-cluster/safely-drain-node/#the-eviction-api) -instead of directly deleting pods or deployments. Examples are the `kubectl drain` command -and the Kubernetes-on-GCE cluster upgrade script (`cluster/gce/upgrade.sh`). +respect PodDisruptionBudgets by calling the [Eviction API](/docs/tasks/administer-cluster/safely-drain-node/#the-eviction-api) +instead of directly deleting pods or deployments. -When a cluster administrator wants to drain a node -they use the `kubectl drain` command. That tool tries to evict all -the pods on the machine. The eviction request may be temporarily rejected, -and the tool periodically retries all failed requests until all pods -are terminated, or until a configurable timeout is reached. +For example, the `kubectl drain` subcommand lets you mark a node as going out of +service. When you run `kubectl drain`, the tool tries to evict all of the Pods on +the Node you're taking out of service. The eviction request that `kubectl` submits on +your behalf may be temporarily rejected, so the tool periodically retries all failed +requests until all Pods on the target node are terminated, or until a configurable timeout +is reached. A PDB specifies the number of replicas that an application can tolerate having, relative to how many it is intended to have. For example, a Deployment which has a `.spec.replicas: 5` is supposed to have 5 pods at any given time. If its PDB allows for there to be 4 at a time, -then the Eviction API will allow voluntary disruption of one, but not two pods, at a time. +then the Eviction API will allow voluntary disruption of one (but not two) pods at a time. The group of pods that comprise the application is specified using a label selector, the same as the one used by the application's controller (deployment, stateful-set, etc). -The "intended" number of pods is computed from the `.spec.replicas` of the pods controller. -The controller is discovered from the pods using the `.metadata.ownerReferences` of the object. +The "intended" number of pods is computed from the `.spec.replicas` of the workload resource +that is managing those pods. The control plane discovers the owning workload resource by +examining the `.metadata.ownerReferences` of the Pod. PDBs cannot prevent [involuntary disruptions](#voluntary-and-involuntary-disruptions) from occurring, but they do count against the budget. Pods which are deleted or unavailable due to a rolling upgrade to an application do count -against the disruption budget, but controllers (like deployment and stateful-set) -are not limited by PDBs when doing rolling upgrades -- the handling of failures -during application updates is configured in the controller spec. -(Learn about [updating a deployment](/docs/concepts/workloads/controllers/deployment/#updating-a-deployment).) +against the disruption budget, but workload resources (such as Deployment and StatefulSet) +are not limited by PDBs when doing rolling upgrades. Instead, the handling of failures +during application updates is configured in the spec for the specific workload resource. -When a pod is evicted using the eviction API, it is gracefully terminated (see -`terminationGracePeriodSeconds` in [PodSpec](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podspec-v1-core).) +When a pod is evicted using the eviction API, it is gracefully +[terminated](/docs/concepts/workloads/pods/pod-lifecycle/#pod-termination), honoring the +`terminationGracePeriodSeconds` setting in its [PodSpec](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podspec-v1-core).) -## PDB Example +## PodDisruptionBudget example {#pdb-example} Consider a cluster with 3 nodes, `node-1` through `node-3`. The cluster is running several applications. One of them has 3 replicas initially called @@ -272,4 +269,6 @@ the nodes in your cluster, such as a node or system software upgrade, here are s * Learn more about [draining nodes](/docs/tasks/administer-cluster/safely-drain-node/) +* Learn about [updating a deployment](/docs/concepts/workloads/controllers/deployment/#updating-a-deployment) + including steps to maintain its availability during the rollout. diff --git a/content/en/docs/concepts/workloads/pods/pod-lifecycle.md b/content/en/docs/concepts/workloads/pods/pod-lifecycle.md index 60973c46a8..35fbb562bf 100644 --- a/content/en/docs/concepts/workloads/pods/pod-lifecycle.md +++ b/content/en/docs/concepts/workloads/pods/pod-lifecycle.md @@ -6,16 +6,60 @@ weight: 30 -{{< comment >}}Updated: 4/14/2015{{< /comment >}} -{{< comment >}}Edited and moved to Concepts section: 2/2/17{{< /comment >}} - -This page describes the lifecycle of a Pod. +This page describes the lifecycle of a Pod. Pods follow a defined lifecycle, starting +in the `Pending` [phase](#pod-phase), moving through `Running` if at least one +of its primary containers starts OK, and then through either the `Succeeded` or +`Failed` phases depending on whether any container in the Pod terminated in failure. +Whilst a Pod is running, the kubelet is able to restart containers to handle some +kind of faults. Within a Pod, Kubernetes tracks different container +[states](#container-states) and handles +In the Kubernetes API, Pods have both a specification and an actual status. The +status for a Pod object consists of a set of [Pod conditions](#pod-conditions). +You can also inject [custom readiness information](#pod-readiness-gate) into the +condition data for a Pod, if that is useful to your application. +Pods are only [scheduled](/docs/concepts/scheduling-eviction/) once in their lifetime. +Once a Pod is scheduled (assigned) to a Node, the Pod runs on that Node until it stops +or is [terminated](#pod-termination). +## Pod lifetime + +Like individual application containers, Pods are considered to be relatively +ephemeral (rather than durable) entities. Pods are created, assigned a unique +ID ([UID](/docs/concepts/overview/working-with-objects/names/#uids)), and scheduled +to nodes where they remain until termination (according to restart policy) or +deletion. +If a {{< glossary_tooltip term_id="node" >}} dies, the Pods scheduled to that node +are [scheduled for deletion](#pod-garbage-collection) after a timeout period. + +Pods do not, by themselves, self-heal. If a Pod is scheduled to a +{{< glossary_tooltip text="node" term_id="node" >}} that then fails, +or if the scheduling operation itself fails, the Pod is deleted; likewise, a Pod won't +survive an eviction due to a lack of resources or Node maintenance. Kubernetes uses a +higher-level abstraction, called a +{{< glossary_tooltip term_id="controller" text="controller" >}}, that handles the work of +managing the relatively disposable Pod instances. + +A given Pod (as defined by a UID) is never "rescheduled" to a different node; instead, +that Pod can be replaced by a new, near-identical Pod, with even the same name i +desired, but with a different UID. + +When something is said to have the same lifetime as a Pod, such as a +{{< glossary_tooltip term_id="volume" text="volume" >}}, +that means that the thing exists as long as that specific Pod (with that exact UID) +exists. If that Pod is deleted for any reason, and even if an identical replacement +is created, the related thing (a volume, in this example) is also destroyed and +created anew. + +{{< figure src="/images/docs/pod.svg" title="Pod diagram" width="50%" >}} + +*A multi-container Pod that contains a file puller and a +web server that uses a persistent volume for shared storage between the containers.* + ## Pod phase A Pod's `status` field is a @@ -24,7 +68,7 @@ object, which has a `phase` field. The phase of a Pod is a simple, high-level summary of where the Pod is in its lifecycle. The phase is not intended to be a comprehensive rollup of observations -of Container or Pod state, nor is it intended to be a comprehensive state machine. +of container or Pod state, nor is it intended to be a comprehensive state machine. The number and meanings of Pod phase values are tightly guarded. Other than what is documented here, nothing should be assumed about Pods that @@ -34,188 +78,106 @@ Here are the possible values for `phase`: Value | Description :-----|:----------- -`Pending` | The Pod has been accepted by the Kubernetes system, but one or more of the Container images has not been created. This includes time before being scheduled as well as time spent downloading images over the network, which could take a while. -`Running` | The Pod has been bound to a node, and all of the Containers have been created. At least one Container is still running, or is in the process of starting or restarting. -`Succeeded` | All Containers in the Pod have terminated in success, and will not be restarted. -`Failed` | All Containers in the Pod have terminated, and at least one Container has terminated in failure. That is, the Container either exited with non-zero status or was terminated by the system. -`Unknown` | For some reason the state of the Pod could not be obtained, typically due to an error in communicating with the host of the Pod. +`Pending` | The Pod has been accepted by the Kubernetes cluster, but one or more of the containers has not been set up and made ready to run. This includes time a Pod spends waiting to be scheduled as well as the time spent downloading container images over the network. +`Running` | The Pod has been bound to a node, and all of the containers have been created. At least one container is still running, or is in the process of starting or restarting. +`Succeeded` | All containers in the Pod have terminated in success, and will not be restarted. +`Failed` | All containers in the Pod have terminated, and at least one container has terminated in failure. That is, the container either exited with non-zero status or was terminated by the system. +`Unknown` | For some reason the state of the Pod could not be obtained. This phase typically occurs due to an error in communicating with the node where the Pod should be running. + +If a node dies or is disconnected from the rest of the cluster, Kubernetes +applies a policy for setting the `phase` of all Pods on the lost node to Failed. + +## Container states + +As well as the [phase](#pod-phase) of the Pod overall, Kubernetes tracks the state of +each container inside a Pod. You can use +[container lifecycle hooks](/docs/concepts/containers/container-lifecycle-hooks/) to +trigger events to run at certain points in a container's lifecycle. + +Once the {{< glossary_tooltip text="scheduler" term_id="kube-scheduler" >}} +assigns a Pod to a Node, the kubelet starts creating containers for that Pod +using a {{< glossary_tooltip text="container runtime" term_id="container-runtime" >}}. +There are three possible container states: `Waiting`, `Running`, and `Terminated`. + +To the check state of a Pod's containers, you can use +`kubectl describe pod `. The output shows the state for each container +within that Pod. + +Each state has a specific meaning: + +### `Waiting` {#container-state-waiting} + +If a container is not in either the `Running` or `Terminated` state, it `Waiting`. +A container in the `Waiting` state is still running the operations it requires in +order to complete start up: for example, pulling the container image from a container +image registry, or applying {{< glossary_tooltip text="Secret" term_id="secret" >}} +data. +When you use `kubectl` to query a Pod with a container that is `Waiting`, you also see +a Reason field to summarize why the container is in that state. + +### `Running` {#container-state-running} + +The `Running` status indicates that a container is executing without issues. If there +was a `postStart` hook configured, it has already executed and executed. When you use +`kubectl` to query a Pod with a container that is `Running`, you also see information +about when the container entered the `Running` state. + +### `Terminated` {#container-state-terminated} + +A container in the `Terminated` state has begin execution and has then either run to +completion or has failed for some reason. When you use `kubectl` to query a Pod with +a container that is `Terminated`, you see a reason, and exit code, and the start and +finish time for that container's period of execution. + +If a container has a `preStop` hook configured, that runs before the container enters +the `Terminated` state. + +## Container restart policy {#restart-policy} + +The `spec` of a Pod has a `restartPolicy` field with possible values Always, OnFailure, +and Never. The default value is Always. + +The `restartPolicy` applies to all containers in the Pod. `restartPolicy` only +refers to restarts of the containers by the kubelet on the same node. After containers +in a Pod exit, the kubelet restarts them with an exponential back-off delay (10s, 20s, +40s, …), that is capped at five minutes. Once a container has executed with no problems +for 10 minutes without any problems, the kubelet resets the restart backoff timer for +that container. ## Pod conditions A Pod has a PodStatus, which has an array of [PodConditions](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podcondition-v1-core) -through which the Pod has or has not passed. Each element of the PodCondition -array has six possible fields: +through which the Pod has or has not passed: -* The `lastProbeTime` field provides a timestamp for when the Pod condition - was last probed. +* `PodScheduled`: the Pod has been scheduled to a node. +* `ContainersReady`: all containers in the Pod are ready. +* `Initialized`: all [init containers](/docs/concepts/workloads/pods/init-containers/) + have started successfully. +* `Ready`: the Pod is able to serve requests and should be added to the load + balancing pools of all matching Services. -* The `lastTransitionTime` field provides a timestamp for when the Pod - last transitioned from one status to another. - -* The `message` field is a human-readable message indicating details - about the transition. - -* The `reason` field is a unique, one-word, CamelCase reason for the condition's last transition. - -* The `status` field is a string, with possible values "`True`", "`False`", and "`Unknown`". - -* The `type` field is a string with the following possible values: - - * `PodScheduled`: the Pod has been scheduled to a node; - * `Ready`: the Pod is able to serve requests and should be added to the load - balancing pools of all matching Services; - * `Initialized`: all [init containers](/docs/concepts/workloads/pods/init-containers) - have started successfully; - * `ContainersReady`: all containers in the Pod are ready. +Field name | Description +:--------------------|:----------- +`type` | Name of this Pod condition. +`status` | Indicates whether that condition is applicable, with possible values "`True`", "`False`", or "`Unknown`". +`lastProbeTime` | Timestamp of when the Pod condition was last probed. +`lastTransitionTime` | Timestamp for when the Pod last transitioned from one status to another. +`reason` | Machine-readable, UpperCamelCase text indicating the reason for the condition's last transition. +`message` | Human-readable message indicating details about the last status transition. - -## Container probes - -A [Probe](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#probe-v1-core) is a diagnostic -performed periodically by the [kubelet](/docs/admin/kubelet/) -on a Container. To perform a diagnostic, -the kubelet calls a -[Handler](https://godoc.org/k8s.io/kubernetes/pkg/api/v1#Handler) implemented by -the Container. There are three types of handlers: - -* [ExecAction](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#execaction-v1-core): - Executes a specified command inside the Container. The diagnostic - is considered successful if the command exits with a status code of 0. - -* [TCPSocketAction](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#tcpsocketaction-v1-core): - Performs a TCP check against the Container's IP address on - a specified port. The diagnostic is considered successful if the port is open. - -* [HTTPGetAction](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#httpgetaction-v1-core): - Performs an HTTP Get request against the Container's IP - address on a specified port and path. The diagnostic is considered successful - if the response has a status code greater than or equal to 200 and less than 400. - -Each probe has one of three results: - -* Success: The Container passed the diagnostic. -* Failure: The Container failed the diagnostic. -* Unknown: The diagnostic failed, so no action should be taken. - -The kubelet can optionally perform and react to three kinds of probes on running -Containers: - -* `livenessProbe`: Indicates whether the Container is running. If - the liveness probe fails, the kubelet kills the Container, and the Container - is subjected to its [restart policy](#restart-policy). If a Container does not - provide a liveness probe, the default state is `Success`. - -* `readinessProbe`: Indicates whether the Container is ready to service requests. - If the readiness probe fails, the endpoints controller removes the Pod's IP - address from the endpoints of all Services that match the Pod. The default - state of readiness before the initial delay is `Failure`. If a Container does - not provide a readiness probe, the default state is `Success`. - -* `startupProbe`: Indicates whether the application within the Container is started. - All other probes are disabled if a startup probe is provided, until it succeeds. - If the startup probe fails, the kubelet kills the Container, and the Container - is subjected to its [restart policy](#restart-policy). If a Container does not - provide a startup probe, the default state is `Success`. - -### When should you use a liveness probe? - -{{< feature-state for_k8s_version="v1.0" state="stable" >}} - -If the process in your Container is able to crash on its own whenever it -encounters an issue or becomes unhealthy, you do not necessarily need a liveness -probe; the kubelet will automatically perform the correct action in accordance -with the Pod's `restartPolicy`. - -If you'd like your Container to be killed and restarted if a probe fails, then -specify a liveness probe, and specify a `restartPolicy` of Always or OnFailure. - -### When should you use a readiness probe? - -{{< feature-state for_k8s_version="v1.0" state="stable" >}} - -If you'd like to start sending traffic to a Pod only when a probe succeeds, -specify a readiness probe. In this case, the readiness probe might be the same -as the liveness probe, but the existence of the readiness probe in the spec means -that the Pod will start without receiving any traffic and only start receiving -traffic after the probe starts succeeding. -If your Container needs to work on loading large data, configuration files, or migrations during startup, specify a readiness probe. - -If you want your Container to be able to take itself down for maintenance, you -can specify a readiness probe that checks an endpoint specific to readiness that -is different from the liveness probe. - -Note that if you just want to be able to drain requests when the Pod is deleted, -you do not necessarily need a readiness probe; on deletion, the Pod automatically -puts itself into an unready state regardless of whether the readiness probe exists. -The Pod remains in the unready state while it waits for the Containers in the Pod -to stop. - -### When should you use a startup probe? - -{{< feature-state for_k8s_version="v1.16" state="alpha" >}} - -If your Container usually starts in more than `initialDelaySeconds + failureThreshold × periodSeconds`, you should specify a startup probe that checks the same endpoint as the liveness probe. The default for `periodSeconds` is 30s. -You should then set its `failureThreshold` high enough to allow the Container to start, without changing the default values of the liveness probe. This helps to protect against deadlocks. - -For more information about how to set up a liveness, readiness, startup probe, see -[Configure Liveness, Readiness and Startup Probes](/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/). - -## Pod and Container status - -For detailed information about Pod Container status, see -[PodStatus](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podstatus-v1-core) -and -[ContainerStatus](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#containerstatus-v1-core). -Note that the information reported as Pod status depends on the current -[ContainerState](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#containerstatus-v1-core). - -## Container States - -Once Pod is assigned to a node by scheduler, kubelet starts creating containers using container runtime.There are three possible states of containers: Waiting, Running and Terminated. To check state of container, you can use `kubectl describe pod [POD_NAME]`. State is displayed for each container within that Pod. - -* `Waiting`: Default state of container. If container is not in either Running or Terminated state, it is in Waiting state. A container in Waiting state still runs its required operations, like pulling images, applying Secrets, etc. Along with this state, a message and reason about the state are displayed to provide more information. - - ```yaml - ... - State: Waiting - Reason: ErrImagePull - ... - ``` - -* `Running`: Indicates that the container is executing without issues. The `postStart` hook (if any) is executed prior to the container entering a Running state. This state also displays the time when the container entered Running state. - - ```yaml - ... - State: Running - Started: Wed, 30 Jan 2019 16:46:38 +0530 - ... - ``` - -* `Terminated`: Indicates that the container completed its execution and has stopped running. A container enters into this when it has successfully completed execution or when it has failed for some reason. Regardless, a reason and exit code is displayed, as well as the container's start and finish time. Before a container enters into Terminated, `preStop` hook (if any) is executed. - - ```yaml - ... - State: Terminated - Reason: Completed - Exit Code: 0 - Started: Wed, 30 Jan 2019 11:45:26 +0530 - Finished: Wed, 30 Jan 2019 11:45:26 +0530 - ... - ``` - -## Pod readiness {#pod-readiness-gate} +### Pod readiness {#pod-readiness-gate} {{< feature-state for_k8s_version="v1.14" state="stable" >}} Your application can inject extra feedback or signals into PodStatus: -_Pod readiness_. To use this, set `readinessGates` in the PodSpec to specify -a list of additional conditions that the kubelet evaluates for Pod readiness. +_Pod readiness_. To use this, set `readinessGates` in the Pod's `spec` to +specify a list of additional conditions that the kubelet evaluates for Pod readiness. Readiness gates are determined by the current state of `status.condition` -fields for the Pod. If Kubernetes cannot find such a -condition in the `status.conditions` field of a Pod, the status of the condition +fields for the Pod. If Kubernetes cannot find such a condition in the +`status.conditions` field of a Pod, the status of the condition is defaulted to "`False`". Here is an example: @@ -258,153 +220,226 @@ For a Pod that uses custom conditions, that Pod is evaluated to be ready **only* when both the following statements apply: * All containers in the Pod are ready. -* All conditions specified in `ReadinessGates` are `True`. +* All conditions specified in `readinessGates` are `True`. When a Pod's containers are Ready but at least one custom condition is missing or -`False`, the kubelet sets the Pod's condition to `ContainersReady`. +`False`, the kubelet sets the Pod's [condition](#pod-condition) to `ContainersReady`. -## Restart policy +## Container probes -A PodSpec has a `restartPolicy` field with possible values Always, OnFailure, -and Never. The default value is Always. -`restartPolicy` applies to all Containers in the Pod. `restartPolicy` only -refers to restarts of the Containers by the kubelet on the same node. Exited -Containers that are restarted by the kubelet are restarted with an exponential -back-off delay (10s, 20s, 40s ...) capped at five minutes, and is reset after ten -minutes of successful execution. As discussed in the -[Pods document](/docs/user-guide/pods/#durability-of-pods-or-lack-thereof), -once bound to a node, a Pod will never be rebound to another node. +A [Probe](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#probe-v1-core) is a diagnostic +performed periodically by the [kubelet](/docs/admin/kubelet/) +on a Container. To perform a diagnostic, +the kubelet calls a +[Handler](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#handler-v1-core) implemented by +the container. There are three types of handlers: +* [ExecAction](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#execaction-v1-core): + Executes a specified command inside the container. The diagnostic + is considered successful if the command exits with a status code of 0. -## Pod lifetime +* [TCPSocketAction](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#tcpsocketaction-v1-core): + Performs a TCP check against the Pod's IP address on + a specified port. The diagnostic is considered successful if the port is open. -In general, Pods remain until a human or +* [HTTPGetAction](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#httpgetaction-v1-core): + Performs an HTTP `GET` request against the Pod's IP + address on a specified port and path. The diagnostic is considered successful + if the response has a status code greater than or equal to 200 and less than 400. + +Each probe has one of three results: + +* `Success`: The container passed the diagnostic. +* `Failure`: The container failed the diagnostic. +* `Unknown`: The diagnostic failed, so no action should be taken. + +The kubelet can optionally perform and react to three kinds of probes on running +containers: + +* `livenessProbe`: Indicates whether the container is running. If + the liveness probe fails, the kubelet kills the container, and the container + is subjected to its [restart policy](#restart-policy). If a Container does not + provide a liveness probe, the default state is `Success`. + +* `readinessProbe`: Indicates whether the container is ready to respond to requests. + If the readiness probe fails, the endpoints controller removes the Pod's IP + address from the endpoints of all Services that match the Pod. The default + state of readiness before the initial delay is `Failure`. If a Container does + not provide a readiness probe, the default state is `Success`. + +* `startupProbe`: Indicates whether the application within the container is started. + All other probes are disabled if a startup probe is provided, until it succeeds. + If the startup probe fails, the kubelet kills the container, and the container + is subjected to its [restart policy](#restart-policy). If a Container does not + provide a startup probe, the default state is `Success`. + +For more information about how to set up a liveness, readiness, or startup probe, +see [Configure Liveness, Readiness and Startup Probes](/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/). + +### When should you use a liveness probe? + +{{< feature-state for_k8s_version="v1.0" state="stable" >}} + +If the process in your container is able to crash on its own whenever it +encounters an issue or becomes unhealthy, you do not necessarily need a liveness +probe; the kubelet will automatically perform the correct action in accordance +with the Pod's `restartPolicy`. + +If you'd like your container to be killed and restarted if a probe fails, then +specify a liveness probe, and specify a `restartPolicy` of Always or OnFailure. + +### When should you use a readiness probe? + +{{< feature-state for_k8s_version="v1.0" state="stable" >}} + +If you'd like to start sending traffic to a Pod only when a probe succeeds, +specify a readiness probe. In this case, the readiness probe might be the same +as the liveness probe, but the existence of the readiness probe in the spec means +that the Pod will start without receiving any traffic and only start receiving +traffic after the probe starts succeeding. +If your container needs to work on loading large data, configuration files, or +migrations during startup, specify a readiness probe. + +If you want your container to be able to take itself down for maintenance, you +can specify a readiness probe that checks an endpoint specific to readiness that +is different from the liveness probe. + +{{< note >}} +If you just want to be able to drain requests when the Pod is deleted, you do not +necessarily need a readiness probe; on deletion, the Pod automatically puts itself +into an unready state regardless of whether the readiness probe exists. +The Pod remains in the unready state while it waits for the containers in the Pod +to stop. +{{< /note >}} + +### When should you use a startup probe? + +{{< feature-state for_k8s_version="v1.16" state="alpha" >}} + +Startup probes are useful for Pods that have containers that take a long time to +come into service. Rather than set a long liveness interval, you can configure +a separate configuration for probing the container as it starts up, allowing +a time longer than the liveness interval would allow. + +If your container usually starts in more than +`initialDelaySeconds + failureThreshold × periodSeconds`, you should specify a +startup probe that checks the same endpoint as the liveness probe. The default for +`periodSeconds` is 30s. You should then set its `failureThreshold` high enough to +allow the container to start, without changing the default values of the liveness +probe. This helps to protect against deadlocks. + +## Termination of Pods {#pod-termination} + +Because Pods represent processes running on nodes in the cluster, it is important to +allow those processes to gracefully terminate when they are no longer needed (rather +than being abruptly stopped with a `KILL` signal and having no chance to clean up). + +The design aim is for you to be able to request deletion and know when processes +terminate, but also be able to ensure that deletes eventually complete. +When you request deletion of a Pod, the cluster records and tracks the intended grace period +before the Pod is allowed to be forcefully killed. With that forceful shutdown tracking in +place, the {{< glossary_tooltip text="kubelet" term_id="kubelet" >}} attempts graceful +shutdown. + +Typically, the container runtime sends a a TERM signal is sent to the main process in each +container. Once the grace period has expired, the KILL signal is sent to any remainig +processes, and the Pod is then deleted from the +{{< glossary_tooltip text="API Server" term_id="kube-apiserver" >}}. If the kubelet or the +container runtime's management service is restarted while waiting for processes to terminate, the +cluster retries from the start including the full original grace period. + +An example flow: + +1. You use the `kubectl` tool to manually delete a specific Pod, with the default grace period + (30 seconds). +1. The Pod in the API server is updated with the time beyond which the Pod is considered "dead" + along with the grace period. + If you use `kubectl describe` to check on the Pod you're deleting, that Pod shows up as + "Terminating". + On the node where the Pod is running: as soon as the kubelet sees that a Pod has been marked + as terminating (a graceful shutdown duration has been set), the kubelet begins the local Pod + shutdown process. + 1. If one of the Pod's containers has defined a `preStop` + [hook](/docs/concepts/containers/container-lifecycle-hooks/#hook-details), the kubelet + runs that hook inside of the container. If the `preStop` hook is still running after the + grace period expires, the kubelet requests a small, one-off grace period extension of 2 + seconds. + {{< note >}} + If the `preStop` hook needs longer to complete than the default grace period allows, + you must modify `terminationGracePeriodSeconds` to suit this. + {{< /note >}} + 1. The kubelet triggers the container runtime to send a TERM signal to process 1 inside each + container. + {{< note >}} + The containers in the Pod receive the TERM signal at different times and in an arbitrary + order. If the order of shutdowns matters, consider using a `preStop` hook to synchronize. + {{< /note >}} +1. At the same time as the kubelet is starting graceful shutdown, the control plane removes that + shutting-down Pod from Endpoints (and, if enabled, EndpointSlice) objects where these represent + a {{< glossary_tooltip term_id="service" text="Service" >}} with a configured + {{< glossary_tooltip text="selector" term_id="selector" >}}. + {{< glossary_tooltip text="ReplicaSets" term_id="replica-set" >}} and other workload resources + no longer treat the shutting-down Pod as a valid, in-service replica. Pods that shut down slowly + cannot continue to serve traffic as load balancers (like the service proxy) remove the Pod from + the list of endpoints as soon as the termination grace period _begins_. +1. When the grace period expires, the kubelet triggers forcible shutdown. The container runtime sends + `SIGKILL` to any processes still running in any container in the Pod. + The kubelet also cleans up a hidden `pause` container if that container runtime uses one. +1. The kubelet triggers forcible removal of Pod object from the API server, by setting grace period + to 0 (immediate deletion). +1. The API server deletes the Pod's API object, which is then no longer visible from any client. + +### Forced Pod termination {#pod-termination-forced} + +{{< caution >}} +Forced deletions can be potentially disruptive for some workloads and their Pods. +{{< /caution >}} + +By default, all deletes are graceful within 30 seconds. The `kubectl delete` command supports +the `--grace-period=` option which allows you to override the default and specify your +own value. + +Setting the grace period to `0` forcibly and immediately deletes the Pod from the API +server. If the pod was still running on a node, that forcible deletion triggers the kubelet to +begin immediate cleanup. + +{{< note >}} +You must specify an additional flag `--force` along with `--grace-period=0` in order to perform force deletions. +{{< /note >}} + +When a force deletion is performed, the API server does not wait for confirmation +from the kubelet that the Pod has been terminated on the node it was running on. It +removes the Pod in the API immediately so a new Pod can be created with the same +name. On the node, Pods that are set to terminate immediately will still be given +a small grace period before being force killed. + +If you need to force-delete Pods that are part of a StatefulSet, refer to the task +documentation for +[deleting Pods from a StatefulSet](/docs/tasks/run-application/force-delete-stateful-set-pod/). + +### Garbage collection of failed Pods {#pod-garbage-collection} + +For failed Pods, the API objects remain in the cluster's API until a human or {{< glossary_tooltip term_id="controller" text="controller" >}} process explicitly removes them. -The control plane cleans up terminated Pods (with a phase of `Succeeded` or + +The control plane cleans up terminated Pods (with a phase of `Succeeded` or `Failed`), when the number of Pods exceeds the configured threshold (determined by `terminated-pod-gc-threshold` in the kube-controller-manager). This avoids a resource leak as Pods are created and terminated over time. -There are different kinds of resources for creating Pods: - -- Use a {{< glossary_tooltip term_id="deployment" >}}, - {{< glossary_tooltip term_id="replica-set" >}} or {{< glossary_tooltip term_id="statefulset" >}} - for Pods that are not expected to terminate, for example, web servers. - -- Use a {{< glossary_tooltip term_id="job" >}} - for Pods that are expected to terminate once their work is complete; - for example, batch computations. Jobs are appropriate only for Pods with - `restartPolicy` equal to OnFailure or Never. - -- Use a {{< glossary_tooltip term_id="daemonset" >}} - for Pods that need to run one per eligible node. - -All workload resources contain a PodSpec. It is recommended to create the -appropriate workload resource and let the resource's controller create Pods -for you, rather than directly create Pods yourself. - -If a node dies or is disconnected from the rest of the cluster, Kubernetes -applies a policy for setting the `phase` of all Pods on the lost node to Failed. - -## Examples - -### Advanced liveness probe example - -Liveness probes are executed by the kubelet, so all requests are made in the -kubelet network namespace. - -```yaml -apiVersion: v1 -kind: Pod -metadata: - labels: - test: liveness - name: liveness-http -spec: - containers: - - args: - - /server - image: k8s.gcr.io/liveness - livenessProbe: - httpGet: - # when "host" is not defined, "PodIP" will be used - # host: my-host - # when "scheme" is not defined, "HTTP" scheme will be used. Only "HTTP" and "HTTPS" are allowed - # scheme: HTTPS - path: /healthz - port: 8080 - httpHeaders: - - name: X-Custom-Header - value: Awesome - initialDelaySeconds: 15 - timeoutSeconds: 1 - name: liveness -``` - -### Example states - - * Pod is running and has one Container. Container exits with success. - * Log completion event. - * If `restartPolicy` is: - * Always: Restart Container; Pod `phase` stays Running. - * OnFailure: Pod `phase` becomes Succeeded. - * Never: Pod `phase` becomes Succeeded. - - * Pod is running and has one Container. Container exits with failure. - * Log failure event. - * If `restartPolicy` is: - * Always: Restart Container; Pod `phase` stays Running. - * OnFailure: Restart Container; Pod `phase` stays Running. - * Never: Pod `phase` becomes Failed. - - * Pod is running and has two Containers. Container 1 exits with failure. - * Log failure event. - * If `restartPolicy` is: - * Always: Restart Container; Pod `phase` stays Running. - * OnFailure: Restart Container; Pod `phase` stays Running. - * Never: Do not restart Container; Pod `phase` stays Running. - * If Container 1 is not running, and Container 2 exits: - * Log failure event. - * If `restartPolicy` is: - * Always: Restart Container; Pod `phase` stays Running. - * OnFailure: Restart Container; Pod `phase` stays Running. - * Never: Pod `phase` becomes Failed. - - * Pod is running and has one Container. Container runs out of memory. - * Container terminates in failure. - * Log OOM event. - * If `restartPolicy` is: - * Always: Restart Container; Pod `phase` stays Running. - * OnFailure: Restart Container; Pod `phase` stays Running. - * Never: Log failure event; Pod `phase` becomes Failed. - - * Pod is running, and a disk dies. - * Kill all Containers. - * Log appropriate event. - * Pod `phase` becomes Failed. - * If running under a controller, Pod is recreated elsewhere. - - * Pod is running, and its node is segmented out. - * Node controller waits for timeout. - * Node controller sets Pod `phase` to Failed. - * If running under a controller, Pod is recreated elsewhere. - - - ## {{% heading "whatsnext" %}} - * Get hands-on experience [attaching handlers to Container lifecycle events](/docs/tasks/configure-pod-container/attach-handler-lifecycle-event/). * Get hands-on experience - [Configure Liveness, Readiness and Startup Probes](/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/). - -* Learn more about [Container lifecycle hooks](/docs/concepts/containers/container-lifecycle-hooks/). - - + [configuring Liveness, Readiness and Startup Probes](/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/). +* Learn more about [container lifecycle hooks](/docs/concepts/containers/container-lifecycle-hooks/). +* For detailed information about Pod / Container status in the API, see [PodStatus](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podstatus-v1-core) +and +[ContainerStatus](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#containerstatus-v1-core). diff --git a/content/en/docs/concepts/workloads/pods/pod-overview.md b/content/en/docs/concepts/workloads/pods/pod-overview.md deleted file mode 100644 index e963b7ace6..0000000000 --- a/content/en/docs/concepts/workloads/pods/pod-overview.md +++ /dev/null @@ -1,123 +0,0 @@ ---- -reviewers: -- erictune -title: Pod Overview -content_type: concept -weight: 10 -card: - name: concepts - weight: 60 ---- - - -This page provides an overview of `Pod`, the smallest deployable object in the Kubernetes object model. - - - - -## Understanding Pods - -A *Pod* is the basic execution unit of a Kubernetes application--the smallest and simplest unit in the Kubernetes object model that you create or deploy. A Pod represents processes running on your {{< glossary_tooltip term_id="cluster" text="cluster" >}}. - -A Pod encapsulates an application's container (or, in some cases, multiple containers), storage resources, a unique network identity (IP address), as well as options that govern how the container(s) should run. A Pod represents a unit of deployment: *a single instance of an application in Kubernetes*, which might consist of either a single {{< glossary_tooltip text="container" term_id="container" >}} or a small number of containers that are tightly coupled and that share resources. - -[Docker](https://www.docker.com) is the most common container runtime used in a Kubernetes Pod, but Pods support other [container runtimes](/docs/setup/production-environment/container-runtimes/) as well. - - -Pods in a Kubernetes cluster can be used in two main ways: - -* **Pods that run a single container**. The "one-container-per-Pod" model is the most common Kubernetes use case; in this case, you can think of a Pod as a wrapper around a single container, and Kubernetes manages the Pods rather than the containers directly. -* **Pods that run multiple containers that need to work together**. A Pod might encapsulate an application composed of multiple co-located containers that are tightly coupled and need to share resources. These co-located containers might form a single cohesive unit of service--one container serving files from a shared volume to the public, while a separate "sidecar" container refreshes or updates those files. The Pod wraps these containers and storage resources together as a single manageable entity. - -Each Pod is meant to run a single instance of a given application. If you want to scale your application horizontally (to provide more overall resources by running more instances), you should use multiple Pods, one for each instance. In Kubernetes, this is typically referred to as _replication_. -Replicated Pods are usually created and managed as a group by a workload resource and its {{< glossary_tooltip text="_controller_" term_id="controller" >}}. -See [Pods and controllers](#pods-and-controllers) for more information on how Kubernetes uses controllers to implement workload scaling and healing. - -### How Pods manage multiple containers - -Pods are designed to support multiple cooperating processes (as containers) that form a cohesive unit of service. The containers in a Pod are automatically co-located and co-scheduled on the same physical or virtual machine in the cluster. The containers can share resources and dependencies, communicate with one another, and coordinate when and how they are terminated. - -Note that grouping multiple co-located and co-managed containers in a single Pod is a relatively advanced use case. You should use this pattern only in specific instances in which your containers are tightly coupled. For example, you might have a container that acts as a web server for files in a shared volume, and a separate "sidecar" container that updates those files from a remote source, as in the following diagram: - -{{< figure src="/images/docs/pod.svg" alt="example pod diagram" width="50%" >}} - -Some Pods have {{< glossary_tooltip text="init containers" term_id="init-container" >}} as well as {{< glossary_tooltip text="app containers" term_id="app-container" >}}. Init containers run and complete before the app containers are started. - -Pods provide two kinds of shared resources for their constituent containers: *networking* and *storage*. - -#### Networking - -Each Pod is assigned a unique IP address for each address family. Every container in a Pod shares the network namespace, including the IP address and network ports. Containers *inside a Pod* can communicate with one another using `localhost`. When containers in a Pod communicate with entities *outside the Pod*, they must coordinate how they use the shared network resources (such as ports). - -#### Storage - -A Pod can specify a set of shared storage {{< glossary_tooltip text="volumes" term_id="volume" >}}. All containers in the Pod can access the shared volumes, allowing those containers to share data. Volumes also allow persistent data in a Pod to survive in case one of the containers within needs to be restarted. See [Volumes](/docs/concepts/storage/volumes/) for more information on how Kubernetes implements shared storage in a Pod. - -## Working with Pods - -You'll rarely create individual Pods directly in Kubernetes--even singleton Pods. This is because Pods are designed as relatively ephemeral, disposable entities. When a Pod gets created (directly by you, or indirectly by a {{< glossary_tooltip text="_controller_" term_id="controller" >}}), it is scheduled to run on a {{< glossary_tooltip term_id="node" >}} in your cluster. The Pod remains on that node until the process is terminated, the pod object is deleted, the Pod is *evicted* for lack of resources, or the node fails. - -{{< note >}} -Restarting a container in a Pod should not be confused with restarting a Pod. A Pod is not a process, but an environment for running a container. A Pod persists until it is deleted. -{{< /note >}} - -Pods do not, by themselves, self-heal. If a Pod is scheduled to a Node that fails, or if the scheduling operation itself fails, the Pod is deleted; likewise, a Pod won't survive an eviction due to a lack of resources or Node maintenance. Kubernetes uses a higher-level abstraction, called a controller, that handles the work of managing the relatively disposable Pod instances. Thus, while it is possible to use Pod directly, it's far more common in Kubernetes to manage your pods using a controller. - -### Pods and controllers - -You can use workload resources to create and manage multiple Pods for you. A controller for the resource handles replication and rollout and automatic healing in case of Pod failure. For example, if a Node fails, a controller notices that Pods on that Node have stopped working and creates a replacement Pod. The scheduler places the replacement Pod onto a healthy Node. - -Here are some examples of workload resources that manage one or more Pods: - -* {{< glossary_tooltip text="Deployment" term_id="deployment" >}} -* {{< glossary_tooltip text="StatefulSet" term_id="statefulset" >}} -* {{< glossary_tooltip text="DaemonSet" term_id="daemonset" >}} - - -## Pod templates - -Controllers for {{< glossary_tooltip text="workload" term_id="workload" >}} resources create Pods -from a pod template and manage those Pods on your behalf. - -PodTemplates are specifications for creating Pods, and are included in workload resources such as -[Deployments](/docs/concepts/workloads/controllers/deployment/), -[Jobs](/docs/concepts/jobs/run-to-completion-finite-workloads/), and -[DaemonSets](/docs/concepts/workloads/controllers/daemonset/). - -Each controller for a workload resource uses the PodTemplate inside the workload object to make actual Pods. The PodTemplate is part of the desired state of whatever workload resource you used to run your app. - -The sample below is a manifest for a simple Job with a `template` that starts one container. The container in that Pod prints a message then pauses. - -```yaml -apiVersion: batch/v1 -kind: Job -metadata: - name: hello -spec: - template: - # This is the pod template - spec: - containers: - - name: hello - image: busybox - command: ['sh', '-c', 'echo "Hello, Kubernetes!" && sleep 3600'] - restartPolicy: OnFailure - # The pod template ends here -``` - -Modifying the pod template or switching to a new pod template has no effect on the Pods that already exist. Pods do not receive template updates directly; instead, a new Pod is created to match the revised pod template. - -For example, a Deployment controller ensures that the running Pods match the current pod template. If the template is updated, the controller has to remove the existing Pods and create new Pods based on the updated template. Each workload controller implements its own rules for handling changes to the Pod template. - -On Nodes, the {{< glossary_tooltip term_id="kubelet" text="kubelet" >}} does not directly observe or manage any of the details around pod templates and updates; those details are abstracted away. That abstraction and separation of concerns simplifies system semantics, and makes it feasible to extend the cluster's behavior without changing existing code. - - - -## {{% heading "whatsnext" %}} - -* Learn more about [Pods](/docs/concepts/workloads/pods/pod/) -* [The Distributed System Toolkit: Patterns for Composite Containers](https://kubernetes.io/blog/2015/06/the-distributed-system-toolkit-patterns) explains common layouts for Pods with more than one container -* Learn more about Pod behavior: - * [Pod Termination](/docs/concepts/workloads/pods/pod/#termination-of-pods) - * [Pod Lifecycle](/docs/concepts/workloads/pods/pod-lifecycle/) - diff --git a/content/en/docs/concepts/workloads/pods/pod-topology-spread-constraints.md b/content/en/docs/concepts/workloads/pods/pod-topology-spread-constraints.md index 2b16894e6b..58fe7c4b8c 100644 --- a/content/en/docs/concepts/workloads/pods/pod-topology-spread-constraints.md +++ b/content/en/docs/concepts/workloads/pods/pod-topology-spread-constraints.md @@ -1,7 +1,7 @@ --- title: Pod Topology Spread Constraints content_type: concept -weight: 50 +weight: 40 --- @@ -161,10 +161,10 @@ There are some implicit conventions worth noting here: - Nodes without `topologySpreadConstraints[*].topologyKey` present will be bypassed. It implies that: - 1. the Pods located on those nodes do not impact `maxSkew` calculation - in the above example, suppose "node1" does not have label "zone", then the 2 Pods will be disregarded, hence the incomingPod will be scheduled into "zoneA". + 1. the Pods located on those nodes do not impact `maxSkew` calculation - in the above example, suppose "node1" does not have label "zone", then the 2 Pods will be disregarded, hence the incoming Pod will be scheduled into "zoneA". 2. the incoming Pod has no chances to be scheduled onto this kind of nodes - in the above example, suppose a "node5" carrying label `{zone-typo: zoneC}` joins the cluster, it will be bypassed due to the absence of label key "zone". -- Be aware of what will happen if the incomingPod’s `topologySpreadConstraints[*].labelSelector` doesn’t match its own labels. In the above example, if we remove the incoming Pod’s labels, it can still be placed onto "zoneB" since the constraints are still satisfied. However, after the placement, the degree of imbalance of the cluster remains unchanged - it’s still zoneA having 2 Pods which hold label {foo:bar}, and zoneB having 1 Pod which holds label {foo:bar}. So if this is not what you expect, we recommend the workload’s `topologySpreadConstraints[*].labelSelector` to match its own labels. +- Be aware of what will happen if the incoming Pod’s `topologySpreadConstraints[*].labelSelector` doesn’t match its own labels. In the above example, if we remove the incoming Pod’s labels, it can still be placed onto "zoneB" since the constraints are still satisfied. However, after the placement, the degree of imbalance of the cluster remains unchanged - it’s still zoneA having 2 Pods which hold label {foo:bar}, and zoneB having 1 Pod which holds label {foo:bar}. So if this is not what you expect, we recommend the workload’s `topologySpreadConstraints[*].labelSelector` to match its own labels. - If the incoming Pod has `spec.nodeSelector` or `spec.affinity.nodeAffinity` defined, nodes not matching them will be bypassed. diff --git a/content/en/docs/concepts/workloads/pods/pod.md b/content/en/docs/concepts/workloads/pods/pod.md deleted file mode 100644 index d87dc92cb2..0000000000 --- a/content/en/docs/concepts/workloads/pods/pod.md +++ /dev/null @@ -1,209 +0,0 @@ ---- -reviewers: -title: Pods -content_type: concept -weight: 20 ---- - - - -_Pods_ are the smallest deployable units of computing that can be created and -managed in Kubernetes. - - - - - - -## What is a Pod? - -A _Pod_ (as in a pod of whales or pea pod) is a group of one or more -{{< glossary_tooltip text="containers" term_id="container" >}} (such as -Docker containers), with shared storage/network, and a specification -for how to run the containers. A Pod's contents are always co-located and -co-scheduled, and run in a shared context. A Pod models an -application-specific "logical host" - it contains one or more application -containers which are relatively tightly coupled — in a pre-container -world, being executed on the same physical or virtual machine would mean being -executed on the same logical host. - -While Kubernetes supports more container runtimes than just Docker, Docker is -the most commonly known runtime, and it helps to describe Pods in Docker terms. - -The shared context of a Pod is a set of Linux namespaces, cgroups, and -potentially other facets of isolation - the same things that isolate a Docker -container. Within a Pod's context, the individual applications may have -further sub-isolations applied. - -Containers within a Pod share an IP address and port space, and -can find each other via `localhost`. They can also communicate with each -other using standard inter-process communications like SystemV semaphores or -POSIX shared memory. Containers in different Pods have distinct IP addresses -and can not communicate by IPC without -[special configuration](/docs/concepts/policy/pod-security-policy/). -These containers usually communicate with each other via Pod IP addresses. - -Applications within a Pod also have access to shared {{< glossary_tooltip text="volumes" term_id="volume" >}}, which are defined -as part of a Pod and are made available to be mounted into each application's -filesystem. - -In terms of [Docker](https://www.docker.com/) constructs, a Pod is modelled as -a group of Docker containers with shared namespaces and shared filesystem -volumes. - -Like individual application containers, Pods are considered to be relatively -ephemeral (rather than durable) entities. As discussed in -[pod lifecycle](/docs/concepts/workloads/pods/pod-lifecycle/), Pods are created, assigned a unique ID (UID), and -scheduled to nodes where they remain until termination (according to restart -policy) or deletion. If a {{< glossary_tooltip term_id="node" >}} dies, the Pods scheduled to that node are -scheduled for deletion, after a timeout period. A given Pod (as defined by a UID) is not -"rescheduled" to a new node; instead, it can be replaced by an identical Pod, -with even the same name if desired, but with a new UID (see [replication -controller](/docs/concepts/workloads/controllers/replicationcontroller/) for more details). - -When something is said to have the same lifetime as a Pod, such as a volume, -that means that it exists as long as that Pod (with that UID) exists. If that -Pod is deleted for any reason, even if an identical replacement is created, the -related thing (e.g. volume) is also destroyed and created anew. - -{{< figure src="/images/docs/pod.svg" title="Pod diagram" width="50%" >}} - -*A multi-container Pod that contains a file puller and a -web server that uses a persistent volume for shared storage between the containers.* - -## Motivation for Pods - -### Management - -Pods are a model of the pattern of multiple cooperating processes which form a -cohesive unit of service. They simplify application deployment and management -by providing a higher-level abstraction than the set of their constituent -applications. Pods serve as unit of deployment, horizontal scaling, and -replication. Colocation (co-scheduling), shared fate (e.g. termination), -coordinated replication, resource sharing, and dependency management are -handled automatically for containers in a Pod. - -### Resource sharing and communication - -Pods enable data sharing and communication among their constituents. - -The applications in a Pod all use the same network namespace (same IP and port -space), and can thus "find" each other and communicate using `localhost`. -Because of this, applications in a Pod must coordinate their usage of ports. -Each Pod has an IP address in a flat shared networking space that has full -communication with other physical computers and Pods across the network. - -Containers within the Pod see the system hostname as being the same as the configured -`name` for the Pod. There's more about this in the [networking](/docs/concepts/cluster-administration/networking/) -section. - -In addition to defining the application containers that run in the Pod, the Pod -specifies a set of shared storage volumes. Volumes enable data to survive -container restarts and to be shared among the applications within the Pod. - -## Uses of pods - -Pods can be used to host vertically integrated application stacks (e.g. LAMP), -but their primary motivation is to support co-located, co-managed helper -programs, such as: - -* content management systems, file and data loaders, local cache managers, etc. -* log and checkpoint backup, compression, rotation, snapshotting, etc. -* data change watchers, log tailers, logging and monitoring adapters, event publishers, etc. -* proxies, bridges, and adapters -* controllers, managers, configurators, and updaters - -Individual Pods are not intended to run multiple instances of the same -application, in general. - -For a longer explanation, see [The Distributed System ToolKit: Patterns for -Composite -Containers](https://kubernetes.io/blog/2015/06/the-distributed-system-toolkit-patterns). - -## Alternatives considered - -_Why not just run multiple programs in a single (Docker) container?_ - -1. Transparency. Making the containers within the Pod visible to the - infrastructure enables the infrastructure to provide services to those - containers, such as process management and resource monitoring. This - facilitates a number of conveniences for users. -1. Decoupling software dependencies. The individual containers may be - versioned, rebuilt and redeployed independently. Kubernetes may even support - live updates of individual containers someday. -1. Ease of use. Users don't need to run their own process managers, worry about - signal and exit-code propagation, etc. -1. Efficiency. Because the infrastructure takes on more responsibility, - containers can be lighter weight. - -_Why not support affinity-based co-scheduling of containers?_ - -That approach would provide co-location, but would not provide most of the -benefits of Pods, such as resource sharing, IPC, guaranteed fate sharing, and -simplified management. - -## Durability of pods (or lack thereof) - -Pods aren't intended to be treated as durable entities. They won't survive scheduling failures, node failures, or other evictions, such as due to lack of resources, or in the case of node maintenance. - -In general, users shouldn't need to create Pods directly. They should almost -always use controllers even for singletons, for example, -[Deployments](/docs/concepts/workloads/controllers/deployment/). -Controllers provide self-healing with a cluster scope, as well as replication -and rollout management. -Controllers like [StatefulSet](/docs/concepts/workloads/controllers/statefulset.md) -can also provide support to stateful Pods. - -The use of collective APIs as the primary user-facing primitive is relatively common among cluster scheduling systems, including [Borg](https://research.google.com/pubs/pub43438.html), [Marathon](https://mesosphere.github.io/marathon/docs/rest-api.html), [Aurora](http://aurora.apache.org/documentation/latest/reference/configuration/#job-schema), and [Tupperware](https://www.slideshare.net/Docker/aravindnarayanan-facebook140613153626phpapp02-37588997). - -Pod is exposed as a primitive in order to facilitate: - -* scheduler and controller pluggability -* support for pod-level operations without the need to "proxy" them via controller APIs -* decoupling of Pod lifetime from controller lifetime, such as for bootstrapping -* decoupling of controllers and services — the endpoint controller just watches Pods -* clean composition of Kubelet-level functionality with cluster-level functionality — Kubelet is effectively the "pod controller" -* high-availability applications, which will expect Pods to be replaced in advance of their termination and certainly in advance of deletion, such as in the case of planned evictions or image prefetching. - -## Termination of Pods - -Because Pods represent running processes on nodes in the cluster, it is important to allow those processes to gracefully terminate when they are no longer needed (vs being violently killed with a KILL signal and having no chance to clean up). Users should be able to request deletion and know when processes terminate, but also be able to ensure that deletes eventually complete. When a user requests deletion of a Pod, the system records the intended grace period before the Pod is allowed to be forcefully killed, and a TERM signal is sent to the main process in each container. Once the grace period has expired, the KILL signal is sent to those processes, and the Pod is then deleted from the API server. If the Kubelet or the container manager is restarted while waiting for processes to terminate, the termination will be retried with the full grace period. - -An example flow: - -1. User sends command to delete Pod, with default grace period (30s) -1. The Pod in the API server is updated with the time beyond which the Pod is considered "dead" along with the grace period. -1. Pod shows up as "Terminating" when listed in client commands -1. (simultaneous with 3) When the Kubelet sees that a Pod has been marked as terminating because the time in 2 has been set, it begins the Pod shutdown process. - 1. If one of the Pod's containers has defined a [preStop hook](/docs/concepts/containers/container-lifecycle-hooks/#hook-details), it is invoked inside of the container. If the `preStop` hook is still running after the grace period expires, step 2 is then invoked with a small (2 second) one-time extended grace period. You must modify `terminationGracePeriodSeconds` if the `preStop` hook needs longer to complete. - 1. The container is sent the TERM signal. Note that not all containers in the Pod will receive the TERM signal at the same time and may each require a `preStop` hook if the order in which they shut down matters. -1. (simultaneous with 3) Pod is removed from endpoints list for service, and are no longer considered part of the set of running Pods for replication controllers. Pods that shutdown slowly cannot continue to serve traffic as load balancers (like the service proxy) remove them from their rotations. -1. When the grace period expires, any processes still running in the Pod are killed with SIGKILL. -1. The Kubelet will finish deleting the Pod on the API server by setting grace period 0 (immediate deletion). The Pod disappears from the API and is no longer visible from the client. - -By default, all deletes are graceful within 30 seconds. The `kubectl delete` command supports the `--grace-period=` option which allows a user to override the default and specify their own value. The value `0` [force deletes](/docs/concepts/workloads/pods/pod/#force-deletion-of-pods) the Pod. -You must specify an additional flag `--force` along with `--grace-period=0` in order to perform force deletions. - -### Force deletion of pods - -Force deletion of a Pod is defined as deletion of a Pod from the cluster state and etcd immediately. When a force deletion is performed, the API server does not wait for confirmation from the kubelet that the Pod has been terminated on the node it was running on. It removes the Pod in the API immediately so a new Pod can be created with the same name. On the node, Pods that are set to terminate immediately will still be given a small grace period before being force killed. - -Force deletions can be potentially dangerous for some Pods and should be performed with caution. In case of StatefulSet Pods, please refer to the task documentation for [deleting Pods from a StatefulSet](/docs/tasks/run-application/force-delete-stateful-set-pod/). - -## Privileged mode for pod containers - -Any container in a Pod can enable privileged mode, using the `privileged` flag on the [security context](/docs/tasks/configure-pod-container/security-context/) of the container spec. This is useful for containers that want to use Linux capabilities like manipulating the network stack and accessing devices. Processes within the container get almost the same privileges that are available to processes outside a container. With privileged mode, it should be easier to write network and volume plugins as separate Pods that don't need to be compiled into the kubelet. - -{{< note >}} -Your container runtime must support the concept of a privileged container for this setting to be relevant. -{{< /note >}} - -## API Object - -Pod is a top-level resource in the Kubernetes REST API. -The [Pod API object](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#pod-v1-core) definition -describes the object in detail. -When creating the manifest for a Pod object, make sure the name specified is a valid -[DNS subdomain name](/docs/concepts/overview/working-with-objects/names#dns-subdomain-names). - - diff --git a/content/en/docs/concepts/workloads/pods/podpreset.md b/content/en/docs/concepts/workloads/pods/podpreset.md index f77e34a3f9..9cbb7bdff8 100644 --- a/content/en/docs/concepts/workloads/pods/podpreset.md +++ b/content/en/docs/concepts/workloads/pods/podpreset.md @@ -1,7 +1,7 @@ --- reviewers: - jessfraz -title: Pod Preset +title: Pod Presets content_type: concept weight: 50 --- @@ -32,20 +32,20 @@ specific service do not need to know all the details about that service. In order to use Pod presets in your cluster you must ensure the following: -1. You have enabled the API type `settings.k8s.io/v1alpha1/podpreset`. For - example, this can be done by including `settings.k8s.io/v1alpha1=true` in - the `--runtime-config` option for the API server. In minikube add this flag - `--extra-config=apiserver.runtime-config=settings.k8s.io/v1alpha1=true` while - starting the cluster. -1. You have enabled the admission controller `PodPreset`. One way to doing this - is to include `PodPreset` in the `--enable-admission-plugins` option value specified - for the API server. In minikube, add this flag - - ```shell - --extra-config=apiserver.enable-admission-plugins=NamespaceLifecycle,LimitRanger,ServiceAccount,DefaultStorageClass,DefaultTolerationSeconds,NodeRestriction,MutatingAdmissionWebhook,ValidatingAdmissionWebhook,ResourceQuota,PodPreset - ``` - - while starting the cluster. +1. You have enabled the API type `settings.k8s.io/v1alpha1/podpreset`. For + example, this can be done by including `settings.k8s.io/v1alpha1=true` in + the `--runtime-config` option for the API server. In minikube add this flag + `--extra-config=apiserver.runtime-config=settings.k8s.io/v1alpha1=true` while + starting the cluster. +1. You have enabled the admission controller named `PodPreset`. One way to doing this + is to include `PodPreset` in the `--enable-admission-plugins` option value specified + for the API server. For example, if you use Minikube, add this flag: + + ```shell + --extra-config=apiserver.enable-admission-plugins=NamespaceLifecycle,LimitRanger,ServiceAccount,DefaultStorageClass,DefaultTolerationSeconds,NodeRestriction,MutatingAdmissionWebhook,ValidatingAdmissionWebhook,ResourceQuota,PodPreset + ``` + + while starting your cluster. ## How it works @@ -64,31 +64,28 @@ When a pod creation request occurs, the system does the following: modified by a `PodPreset`. The annotation is of the form `podpreset.admission.kubernetes.io/podpreset-: ""`. -Each Pod can be matched by zero or more Pod Presets; and each `PodPreset` can be -applied to zero or more pods. When a `PodPreset` is applied to one or more -Pods, Kubernetes modifies the Pod Spec. For changes to `Env`, `EnvFrom`, and -`VolumeMounts`, Kubernetes modifies the container spec for all containers in -the Pod; for changes to `Volume`, Kubernetes modifies the Pod Spec. +Each Pod can be matched by zero or more PodPresets; and each PodPreset can be +applied to zero or more Pods. When a PodPreset is applied to one or more +Pods, Kubernetes modifies the Pod Spec. For changes to `env`, `envFrom`, and +`volumeMounts`, Kubernetes modifies the container spec for all containers in +the Pod; for changes to `volumes`, Kubernetes modifies the Pod Spec. {{< note >}} A Pod Preset is capable of modifying the following fields in a Pod spec when appropriate: -- The `.spec.containers` field. -- The `initContainers` field (requires Kubernetes version 1.14.0 or later). +- The `.spec.containers` field +- The `.spec.initContainers` field {{< /note >}} -### Disable Pod Preset for a Specific Pod +### Disable Pod Preset for a specific pod There may be instances where you wish for a Pod to not be altered by any Pod -Preset mutations. In these cases, you can add an annotation in the Pod Spec +preset mutations. In these cases, you can add an annotation in the Pod's `.spec` of the form: `podpreset.admission.kubernetes.io/exclude: "true"`. ## {{% heading "whatsnext" %}} - See [Injecting data into a Pod using PodPreset](/docs/tasks/inject-data-application/podpreset/) For more information about the background, see the [design proposal for PodPreset](https://git.k8s.io/community/contributors/design-proposals/service-catalog/pod-preset.md). - - diff --git a/content/en/docs/contribute/_index.md b/content/en/docs/contribute/_index.md index 2f93af4a35..8616f77afb 100644 --- a/content/en/docs/contribute/_index.md +++ b/content/en/docs/contribute/_index.md @@ -3,6 +3,7 @@ content_type: concept title: Contribute to Kubernetes docs linktitle: Contribute main_menu: true +no_list: true weight: 80 card: name: contribute @@ -23,47 +24,66 @@ Kubernetes documentation contributors: Kubernetes documentation welcomes improvements from all contributors, new and experienced! - - ## Getting started -Anyone can open an issue about documentation, or contribute a change with a pull request (PR) to the [`kubernetes/website` GitHub repository](https://github.com/kubernetes/website). You need to be comfortable with [git](https://git-scm.com/) and [GitHub](https://lab.github.com/) to operate effectively in the Kubernetes community. +Anyone can open an issue about documentation, or contribute a change with a +pull request (PR) to the +[`kubernetes/website` GitHub repository](https://github.com/kubernetes/website). +You need to be comfortable with +[git](https://git-scm.com/) and +[GitHub](https://lab.github.com/) +to work effectively in the Kubernetes community. To get involved with documentation: 1. Sign the CNCF [Contributor License Agreement](https://github.com/kubernetes/community/blob/master/CLA.md). -2. Familiarize yourself with the [documentation repository](https://github.com/kubernetes/website) and the website's [static site generator](https://gohugo.io). -3. Make sure you understand the basic processes for [opening a pull request](/docs/contribute/new-content/new-content/) and [reviewing changes](/docs/contribute/review/reviewing-prs/). +1. Familiarize yourself with the [documentation repository](https://github.com/kubernetes/website) + and the website's [static site generator](https://gohugo.io). +1. Make sure you understand the basic processes for + [opening a pull request](/docs/contribute/new-content/open-a-pr/) and + [reviewing changes](/docs/contribute/review/reviewing-prs/). Some tasks require more trust and more access in the Kubernetes organization. -See [Participating in SIG Docs](/docs/contribute/participating/) for more details about +See [Participating in SIG Docs](/docs/contribute/participate/) for more details about roles and permissions. ## Your first contribution -- Read the [Contribution overview](/docs/contribute/new-content/overview/) to learn about the different ways you can contribute. -- See [Contribute to kubernetes/website](https://github.com/kubernetes/website/contribute) to find issues that make good entry points. -- [Open a pull request using GitHub](/docs/contribute/new-content/new-content/#changes-using-github) to existing documentation and learn more about filing issues in GitHub. -- [Review pull requests](/docs/contribute/review/reviewing-prs/) from other Kubernetes community members for accuracy and language. -- Read the Kubernetes [content](/docs/contribute/style/content-guide/) and [style guides](/docs/contribute/style/style-guide/) so you can leave informed comments. -- Learn about [page content types](/docs/contribute/style/page-content-types/) and [Hugo shortcodes](/docs/contribute/style/hugo-shortcodes/). +- Read the [Contribution overview](/docs/contribute/new-content/overview/) to + learn about the different ways you can contribute. +- Check [`kubernetes/website` issues list](https://github.com/kubernetes/website/issues/) + for issues that make good entry points. +- [Open a pull request using GitHub](/docs/contribute/new-content/open-a-pr/#changes-using-github) + to existing documentation and learn more about filing issues in GitHub. +- [Review pull requests](/docs/contribute/review/reviewing-prs/) from other + Kubernetes community members for accuracy and language. +- Read the Kubernetes [content](/docs/contribute/style/content-guide/) and + [style guides](/docs/contribute/style/style-guide/) so you can leave informed comments. +- Learn about [page content types](/docs/contribute/style/page-content-types/) + and [Hugo shortcodes](/docs/contribute/style/hugo-shortcodes/). ## Next steps -- Learn to [work from a local clone](/docs/contribute/new-content/new-content/#fork-the-repo) of the repository. +- Learn to [work from a local clone](/docs/contribute/new-content/open-a-pr/#fork-the-repo) + of the repository. - Document [features in a release](/docs/contribute/new-content/new-features/). -- Participate in [SIG Docs](/docs/contribute/participating/), and become a [member or reviewer](/docs/contribute/participating/#roles-and-responsibilities). +- Participate in [SIG Docs](/docs/contribute/participate/), and become a + [member or reviewer](/docs/contribute/participate/roles-and-responsibilities/). + - Start or help with a [localization](/docs/contribute/localization/). ## Get involved with SIG Docs -[SIG Docs](/docs/contribute/participating/) is the group of contributors who publish and maintain Kubernetes documentation and the website. Getting involved with SIG Docs is a great way for Kubernetes contributors (feature development or otherwise) to have a large impact on the Kubernetes project. +[SIG Docs](/docs/contribute/participate/) is the group of contributors who +publish and maintain Kubernetes documentation and the website. Getting +involved with SIG Docs is a great way for Kubernetes contributors (feature +development or otherwise) to have a large impact on the Kubernetes project. SIG Docs communicates with different methods: -- [Join `#sig-docs` on the Kubernetes Slack instance](http://slack.k8s.io/). Make sure to +- [Join `#sig-docs` on the Kubernetes Slack instance](https://slack.k8s.io/). Make sure to introduce yourself! - [Join the `kubernetes-sig-docs` mailing list](https://groups.google.com/forum/#!forum/kubernetes-sig-docs), where broader discussions take place and official decisions are recorded. @@ -74,5 +94,3 @@ SIG Docs communicates with different methods: - Visit the [Kubernetes community site](/community/). Participate on Twitter or Stack Overflow, learn about local Kubernetes meetups and events, and more. - Read the [contributor cheatsheet](https://github.com/kubernetes/community/tree/master/contributors/guide/contributor-cheatsheet) to get involved with Kubernetes feature development. - Submit a [blog post or case study](/docs/contribute/new-content/blogs-case-studies/). - - diff --git a/content/en/docs/contribute/advanced.md b/content/en/docs/contribute/advanced.md index 9cf6a65883..52ae7b0efd 100644 --- a/content/en/docs/contribute/advanced.md +++ b/content/en/docs/contribute/advanced.md @@ -13,73 +13,12 @@ This page assumes that you understand how to to learn about more ways to contribute. You need to use the Git command line client and other tools for some of these tasks. - - -## Be the PR Wrangler for a week - -SIG Docs [approvers](/docs/contribute/participating/#approvers) take week-long turns [wrangling PRs](https://github.com/kubernetes/website/wiki/PR-Wranglers) for the repository. - -The PR wrangler’s duties include: - -- Review [open pull requests](https://github.com/kubernetes/website/pulls) daily for quality and adherence to the [Style](/docs/contribute/style/style-guide/) and [Content](/docs/contribute/style/content-guide/) guides. - - Review the smallest PRs (`size/XS`) first, then iterate towards the largest (`size/XXL`). - - Review as many PRs as you can. -- Ensure that the CLA is signed by each contributor. - - Help new contributors sign the [CLA](https://github.com/kubernetes/community/blob/master/CLA.md). - - Use [this](https://github.com/zparnold/k8s-docs-pr-botherer) script to automatically remind contributors that haven’t signed the CLA to sign the CLA. -- Provide feedback on proposed changes and help facilitate technical reviews from members of other SIGs. - - Provide inline suggestions on the PR for the proposed content changes. - - If you need to verify content, comment on the PR and request more details. - - Assign relevant `sig/` label(s). - - If needed, assign reviewers from the `reviewers:` block in the file's front matter. - - Assign `Docs Review` and `Tech Review` labels to indicate the PR's review status. - - Assign `Needs Doc Review` or `Needs Tech Review` for PRs that haven't yet been reviewed. - - Assign `Doc Review: Open Issues` or `Tech Review: Open Issues` for PRs that have been reviewed and require further input or action before merging. - - Assign `/lgtm` and `/approve` labels to PRs that can be merged. -- Merge PRs when they are ready, or close PRs that shouldn’t be accepted. -- Triage and tag incoming issues daily. See [Triage and categorize issues](/docs/contribute/review/for-approvers/#triage-and-categorize-issues) for guidelines on how SIG Docs uses metadata. - -### Helpful GitHub queries for wranglers - -The following queries are helpful when wrangling. After working through these queries, the remaining list of PRs to be -reviewed is usually small. These queries specifically exclude localization PRs, and only include the `master` branch (except for the last one). - -- [No CLA, not eligible to merge](https://github.com/kubernetes/website/pulls?q=is%3Aopen+is%3Apr+label%3A%22cncf-cla%3A+no%22+-label%3Ado-not-merge+label%3Alanguage%2Fen): - Remind the contributor to sign the CLA. If they have already been reminded by both the bot and a human, close - the PR and remind them that they can open it after signing the CLA. - **Do not review PRs whose authors have not signed the CLA!** -- [Needs LGTM](https://github.com/kubernetes/website/pulls?utf8=%E2%9C%93&q=is%3Aopen+is%3Apr+-label%3Ado-not-merge+label%3Alanguage%2Fen+-label%3Algtm+): - If it needs technical review, loop in one of the reviewers suggested by the bot. If it needs docs review - or copy-editing, either suggest changes or add a copyedit commit to the PR to move it along. -- [Has LGTM, needs docs approval](https://github.com/kubernetes/website/pulls?q=is%3Aopen+is%3Apr+-label%3Ado-not-merge+label%3Alanguage%2Fen+label%3Algtm): - Determine whether any additional changes or updates need to be made for the PR to be merged. If you think the PR is ready to be merged, comment `/approve`. -- [Quick Wins](https://github.com/kubernetes/website/pulls?utf8=%E2%9C%93&q=is%3Apr+is%3Aopen+base%3Amaster+-label%3A%22do-not-merge%2Fwork-in-progress%22+-label%3A%22do-not-merge%2Fhold%22+label%3A%22cncf-cla%3A+yes%22+label%3A%22size%2FXS%22+label%3A%22language%2Fen%22+): If it’s a small PR against master with no clear blockers. (change "XS" in the size label as you work through the PRs [XS, S, M, L, XL, XXL]). -- [Not against master](https://github.com/kubernetes/website/pulls?utf8=%E2%9C%93&q=is%3Aopen+is%3Apr+-label%3Ado-not-merge+label%3Alanguage%2Fen+-base%3Amaster): If it's against a `dev-` branch, it's for an upcoming release. Make sure the [release meister](https://github.com/kubernetes/sig-release/tree/master/release-team) knows about it by adding a comment with `/assign @`. If it's against an old branch, help the PR author figure out whether it's targeted against the best branch. - -### When to close Pull Requests - -Reviews and approvals are one tool to keep our PR queue short and current. Another tool is closure. - -- Close any PR where the CLA hasn’t been signed for two weeks. -PR authors can reopen the PR after signing the CLA, so this is a low-risk way to make sure nothing gets merged without a signed CLA. - -- Close any PR where the author has not responded to comments or feedback in 2 or more weeks. - -Don't be afraid to close pull requests. Contributors can easily reopen and resume works in progress. Oftentimes a closure notice is what spurs an author to resume and finish their contribution. - -To close a pull request, leave a `/close` comment on the PR. - -{{< note >}} - -An automated service, [`fejta-bot`](https://github.com/fejta-bot) automatically marks issues as stale after 90 days of inactivity, then closes them after an additional 30 days of inactivity when they become rotten. PR wranglers should close issues after 14-30 days of inactivity. - -{{< /note >}} - ## Propose improvements -SIG Docs [members](/docs/contribute/participating/#members) can propose improvements. +SIG Docs [members](/docs/contribute/participate/roles-and-responsibilities/#members) +can propose improvements. After you've been contributing to the Kubernetes documentation for a while, you may have ideas for improving the [Style Guide](/docs/contribute/style/style-guide/) @@ -102,13 +41,13 @@ documentation testing might involve working with sig-testing. ## Coordinate docs for a Kubernetes release -SIG Docs [approvers](/docs/contribute/participating/#approvers) can coordinate -docs for a Kubernetes release. +SIG Docs [approvers](/docs/contribute/participate/roles-and-responsibilities/#approvers) +can coordinate docs for a Kubernetes release. Each Kubernetes release is coordinated by a team of people participating in the sig-release Special Interest Group (SIG). Others on the release team for a given -release include an overall release lead, as well as representatives from sig-pm, -sig-testing, and others. To find out more about Kubernetes release processes, +release include an overall release lead, as well as representatives from +sig-testing and others. To find out more about Kubernetes release processes, refer to [https://github.com/kubernetes/sig-release](https://github.com/kubernetes/sig-release). @@ -133,8 +72,8 @@ rotated among SIG Docs approvers. ## Serve as a New Contributor Ambassador -SIG Docs [approvers](/docs/contribute/participating/#approvers) can serve as -New Contributor Ambassadors. +SIG Docs [approvers](/docs/contribute/participate/roles-and-responsibilities/#approvers) +can serve as New Contributor Ambassadors. New Contributor Ambassadors welcome new contributors to SIG-Docs, suggest PRs to new contributors, and mentor new contributors through their first @@ -152,14 +91,14 @@ Current New Contributor Ambassadors are announced at each SIG-Docs meeting, and ## Sponsor a new contributor -SIG Docs [reviewers](/docs/contribute/participating/#reviewers) can sponsor -new contributors. +SIG Docs [reviewers](/docs/contribute/participate/roles-and-responsibilities/#reviewers) +can sponsor new contributors. After a new contributor has successfully submitted 5 substantive pull requests to one or more Kubernetes repositories, they are eligible to apply for -[membership](/docs/contribute/participating#members) in the Kubernetes -organization. The contributor's membership needs to be backed by two sponsors -who are already reviewers. +[membership](/docs/contribute/participate/roles-and-responsibilities/#members) +in the Kubernetes organization. The contributor's membership needs to be +backed by two sponsors who are already reviewers. New docs contributors can request sponsors by asking in the #sig-docs channel on the [Kubernetes Slack instance](https://kubernetes.slack.com) or on the @@ -171,7 +110,8 @@ membership in the Kubernetes organization. ## Serve as a SIG Co-chair -SIG Docs [approvers](/docs/contribute/participating/#approvers) can serve a term as a co-chair of SIG Docs. +SIG Docs [approvers](/docs/contribute/participate/roles-and-responsibilities/#approvers) +can serve a term as a co-chair of SIG Docs. ### Prerequisites @@ -180,7 +120,12 @@ Approvers must meet the following requirements to be a co-chair: - Have been a SIG Docs approver for at least 6 months - Have [led a Kubernetes docs release](/docs/contribute/advanced/#coordinate-docs-for-a-kubernetes-release) or shadowed two releases - Understand SIG Docs workflows and tooling: git, Hugo, localization, blog subproject -- Understand how other Kubernetes SIGs and repositories affect the SIG Docs workflow, including: [teams in k/org](https://github.com/kubernetes/org/blob/master/config/kubernetes/sig-docs/teams.yaml), [process in k/community](https://github.com/kubernetes/community/tree/master/sig-docs), plugins in [k/test-infra](https://github.com/kubernetes/test-infra/), and the role of [SIG Architecture](https://github.com/kubernetes/community/tree/master/sig-architecture). +- Understand how other Kubernetes SIGs and repositories affect the SIG Docs + workflow, including: + [teams in k/org](https://github.com/kubernetes/org/blob/master/config/kubernetes/sig-docs/teams.yaml), + [process in k/community](https://github.com/kubernetes/community/tree/master/sig-docs), + plugins in [k/test-infra](https://github.com/kubernetes/test-infra/), and the role of + [SIG Architecture](https://github.com/kubernetes/community/tree/master/sig-architecture). - Commit at least 5 hours per week (and often more) to the role for a minimum of 6 months ### Responsibilities @@ -244,5 +189,3 @@ When you’re ready to start the recording, click Record to Cloud. When you’re ready to stop recording, click Stop. The video uploads automatically to YouTube. - - diff --git a/content/en/docs/contribute/generate-ref-docs/kubectl.md b/content/en/docs/contribute/generate-ref-docs/kubectl.md index f057ce6800..ea6065472e 100644 --- a/content/en/docs/contribute/generate-ref-docs/kubectl.md +++ b/content/en/docs/contribute/generate-ref-docs/kubectl.md @@ -15,21 +15,16 @@ like [kubectl apply](/docs/reference/generated/kubectl/kubectl-commands#apply) and [kubectl taint](/docs/reference/generated/kubectl/kubectl-commands#taint). This topic does not show how to generate the -[kubectl](/docs/reference/generated/kubectl/kubectl/) +[kubectl](/docs/reference/generated/kubectl/kubectl-commands/) options reference page. For instructions on how to generate the kubectl options reference page, see -[Generating Reference Pages for Kubernetes Components and Tools](/docs/home/contribute/generated-reference/kubernetes-components/). +[Generating Reference Pages for Kubernetes Components and Tools](/docs/contribute/generate-ref-docs/kubernetes-components/). {{< /note >}} - - ## {{% heading "prerequisites" %}} - {{< include "prerequisites-ref-docs.md" >}} - - ## Setting up the local repositories @@ -237,6 +232,9 @@ Build the Kubernetes documentation in your local ``. cd make docker-serve ``` +{{< note >}} +The use of `make docker-serve` is deprecated. Please use `make container-serve` instead. +{{< /note >}} View the [local preview](https://localhost:1313/docs/reference/generated/kubectl/kubectl-commands/). diff --git a/content/en/docs/contribute/generate-ref-docs/kubernetes-api.md b/content/en/docs/contribute/generate-ref-docs/kubernetes-api.md index 10482eda97..f2ec01d8e8 100644 --- a/content/en/docs/contribute/generate-ref-docs/kubernetes-api.md +++ b/content/en/docs/contribute/generate-ref-docs/kubernetes-api.md @@ -185,21 +185,23 @@ cd make docker-serve ``` +{{< note >}} +The use of `make docker-serve` is deprecated. Please use `make container-serve` instead. +{{< /note >}} + ## Commit the changes In `` run `git add` and `git commit` to commit the change. Submit your changes as a -[pull request](/docs/contribute/start/) to the +[pull request](/docs/contribute/new-content/open-a-pr/) to the [kubernetes/website](https://github.com/kubernetes/website) repository. Monitor your pull request, and respond to reviewer comments as needed. Continue to monitor your pull request until it has been merged. - ## {{% heading "whatsnext" %}} - * [Generating Reference Documentation Quickstart](/docs/contribute/generate-ref-docs/quickstart/) * [Generating Reference Docs for Kubernetes Components and Tools](/docs/contribute/generate-ref-docs/kubernetes-components/) * [Generating Reference Documentation for kubectl Commands](/docs/contribute/generate-ref-docs/kubectl/) diff --git a/content/en/docs/contribute/generate-ref-docs/prerequisites-ref-docs.md b/content/en/docs/contribute/generate-ref-docs/prerequisites-ref-docs.md index a777fb77e5..c719920813 100644 --- a/content/en/docs/contribute/generate-ref-docs/prerequisites-ref-docs.md +++ b/content/en/docs/contribute/generate-ref-docs/prerequisites-ref-docs.md @@ -18,4 +18,5 @@ - You need to know how to create a pull request to a GitHub repository. This involves creating your own fork of the repository. For more - information, see [Work from a local clone](/docs/contribute/intermediate/#work_from_a_local_clone). + information, see [Work from a local clone](/docs/contribute/new-content/open-a-pr/#fork-the-repo). + diff --git a/content/en/docs/contribute/generate-ref-docs/quickstart.md b/content/en/docs/contribute/generate-ref-docs/quickstart.md index df5cdbb95f..0790f7925a 100644 --- a/content/en/docs/contribute/generate-ref-docs/quickstart.md +++ b/content/en/docs/contribute/generate-ref-docs/quickstart.md @@ -10,15 +10,10 @@ This page shows how to use the `update-imported-docs` script to generate the Kubernetes reference documentation. The script automates the build setup and generates the reference documentation for a release. - - ## {{% heading "prerequisites" %}} - {{< include "prerequisites-ref-docs.md" >}} - - ## Getting the docs repository @@ -87,7 +82,7 @@ The `update-imported-docs` script performs the following steps: the sections in the `kubectl` command reference. When the generated files are in your local clone of the `` -repository, you can submit them in a [pull request](/docs/contribute/start/) +repository, you can submit them in a [pull request](/docs/contribute/new-content/open-a-pr/) to ``. ## Configuration file format diff --git a/content/en/docs/contribute/localization.md b/content/en/docs/contribute/localization.md index 0c698305b9..74c4f8e091 100644 --- a/content/en/docs/contribute/localization.md +++ b/content/en/docs/contribute/localization.md @@ -75,7 +75,7 @@ For an example of adding a label, see the PR for adding the [Italian language la Let Kubernetes SIG Docs know you're interested in creating a localization! Join the [SIG Docs Slack channel](https://kubernetes.slack.com/messages/C1J0BPD2M/). Other localization teams are happy to help you get started and answer any questions you have. -You can also create a Slack channel for your localization in the `kubernetes/community` repository. For an example of adding a Slack channel, see the PR for [adding channels for Indonesian and Portuguese](https://github.com/kubernetes/community/pull/3605). +You can also create a Slack channel for your localization in the `kubernetes/community` repository. For an example of adding a Slack channel, see the PR for [adding a channel for Persian](https://github.com/kubernetes/community/pull/4980). ## Minimum required content @@ -183,7 +183,7 @@ Description | URLs -----|----- Home | [All heading and subheading URLs](/docs/home/) Setup | [All heading and subheading URLs](/docs/setup/) -Tutorials | [Kubernetes Basics](/docs/tutorials/kubernetes-basics/), [Hello Minikube](/docs/tutorials/stateless-application/hello-minikube/) +Tutorials | [Kubernetes Basics](/docs/tutorials/kubernetes-basics/), [Hello Minikube](/docs/tutorials/hello-minikube/) Site strings | [All site strings in a new localized TOML file](https://github.com/kubernetes/website/tree/master/i18n) Translated documents must reside in their own `content/**/` subdirectory, but otherwise follow the same URL path as the English source. For example, to prepare the [Kubernetes Basics](/docs/tutorials/kubernetes-basics/) tutorial for translation into German, create a subfolder under the `content/de/` folder and copy the English source: diff --git a/content/en/docs/contribute/new-content/blogs-case-studies.md b/content/en/docs/contribute/new-content/blogs-case-studies.md index 76acbd2d41..2ec9f35ac0 100644 --- a/content/en/docs/contribute/new-content/blogs-case-studies.md +++ b/content/en/docs/contribute/new-content/blogs-case-studies.md @@ -12,35 +12,77 @@ weight: 30 Anyone can write a blog post and submit it for review. Case studies require extensive review before they're approved. - - -## Write a blog post +## The Kubernetes Blog -Blog posts should not be -vendor pitches. They must contain content that applies broadly to -the Kubernetes community. The SIG Docs [blog subproject](https://github.com/kubernetes/community/tree/master/sig-docs/blog-subproject) manages the review process for blog posts. For more information, see [Submit a post](https://github.com/kubernetes/community/tree/master/sig-docs/blog-subproject#submit-a-post). +The Kubernetes blog is used by the project to communicate new features, community reports, and any news that might be relevant to the Kubernetes community. +This includes end users and developers. +Most of the blog's content is about things happening in the core project, but we encourage you to submit about things happening elsewhere in the ecosystem too! -To submit a blog post, you can either: +Anyone can write a blog post and submit it for review. -- Use the -[Kubernetes blog submission form](https://docs.google.com/forms/d/e/1FAIpQLSdMpMoSIrhte5omZbTE7nB84qcGBy8XnnXhDFoW0h7p2zwXrw/viewform) -- [Open a pull request](/docs/contribute/new-content/new-content/#fork-the-repo) with a new blog post. Create new blog posts in the [`content/en/blog/_posts`](https://github.com/kubernetes/website/tree/master/content/en/blog/_posts) directory. +### Guidelines and expectations -If you open a pull request, ensure that your blog post follows the correct naming conventions and frontmatter information: +- Blog posts should not be vendor pitches. + - Articles must contain content that applies broadly to the Kubernetes community. For example, a submission should focus on upstream Kubernetes as opposed to vendor-specific configurations. Check the [Documentation style guide](https://kubernetes.io/docs/contribute/style/content-guide/#what-s-allowed) for what is typically allowed on Kubernetes properties. + - Links should primarily be to the official Kubernetes documentation. When using external references, links should be diverse - For example a submission shouldn't contain only links back to a single company's blog. + - Sometimes this is a delicate balance. The [blog team](https://kubernetes.slack.com/messages/sig-docs-blog/) is there to give guidance on whether a post is appropriate for the Kubernetes blog, so don't hesitate to reach out. +- Blog posts are not published on specific dates. + - Articles are reviewed by community volunteers. We'll try our best to accommodate specific timing, but we make no guarantees. + - Many core parts of the Kubernetes projects submit blog posts during release windows, delaying publication times. Consider submitting during a quieter period of the release cycle. + - If you are looking for greater coordination on post release dates, coordinating with [CNCF marketing](https://www.cncf.io/about/contact/) is a more appropriate choice than submitting a blog post. + - Sometimes reviews can get backed up. If you feel your review isn't getting the attention it needs, you can reach out to the blog team via [this slack channel](https://kubernetes.slack.com/messages/sig-docs-blog/) to ask in real time. +- Blog posts should be relevant to Kubernetes users. + - Topics related to participation in or results of Kubernetes SIGs activities are always on topic (see the work in the [Upstream Marketing Team](https://github.com/kubernetes/community/blob/master/communication/marketing-team/blog-guidelines.md#upstream-marketing-blog-guidelines) for support on these posts). + - The components of Kubernetes are purposely modular, so tools that use existing integration points like CNI and CSI are on topic. + - Posts about other CNCF projects may or may not be on topic. We recommend asking the blog team before submitting a draft. + - Many CNCF projects have their own blog. These are often a better choice for posts. There are times of major feature or milestone for a CNCF project that users would be interested in reading on the Kubernetes blog. +- Blog posts should be original content + - The official blog is not for repurposing existing content from a third party as new content. + - The [license](https://github.com/kubernetes/website/blob/master/LICENSE) for the blog does allow commercial use of the content for commercial purposes, just not the other way around. +- Blog posts should aim to be future proof + - Given the development velocity of the project, we want evergreen content that won't require updates to stay accurate for the reader. + - It can be a better choice to add a tutorial or update official documentation than to write a high level overview as a blog post. + - Consider concentrating the long technical content as a call to action of the blog post, and focus on the problem space or why readers should care. -- The markdown file name must follow the format `YYY-MM-DD-Your-Title-Here.md`. For example, `2020-02-07-Deploying-External-OpenStack-Cloud-Provider-With-Kubeadm.md`. -- The front matter must include the following: +### Technical Considerations for submitting a blog post + +Submissions need to be in Markdown format to be used by the [Hugo](https://gohugo.io/) generator for the blog. There are [many resources available](https://gohugo.io/documentation/) on how to use this technology stack. + +We recognize that this requirement makes the process more difficult for less-familiar folks to submit, and we're constantly looking at solutions to lower this bar. If you have ideas on how to lower the barrier, please volunteer to help out. + +The SIG Docs [blog subproject](https://github.com/kubernetes/community/tree/master/sig-docs/blog-subproject) manages the review process for blog posts. For more information, see [Submit a post](https://github.com/kubernetes/community/tree/master/sig-docs/blog-subproject#submit-a-post). + +To submit a blog post follow these directions: + +- [Open a pull request](/docs/contribute/new-content/new-content/#fork-the-repo) with a new blog post. New blog posts go under the [`content/en/blog/_posts`](https://github.com/kubernetes/website/tree/master/content/en/blog/_posts) directory. + +- Ensure that your blog post follows the correct naming conventions and the following frontmatter (metadata) information: + + - The Markdown file name must follow the format `YYYY-MM-DD-Your-Title-Here.md`. For example, `2020-02-07-Deploying-External-OpenStack-Cloud-Provider-With-Kubeadm.md`. + - Do **not** include dots in the filename. A name like `2020-01-01-whats-new-in-1.19.md` causes failures during a build. + - The front matter must include the following: + + ```yaml + --- + layout: blog + title: "Your Title Here" + date: YYYY-MM-DD + slug: text-for-URL-link-here-no-spaces + --- + ``` + - The first or initial commit message should be a short summary of the work being done and should stand alone as a description of the blog post. Please note that subsequent edits to your blog will be squashed into this main commit, so it should be as useful as possible. + - Examples of a good commit message: + - _Add blog post on the foo kubernetes feature_ + - _blog: foobar announcement_ + - Examples of bad commit message: + - _Add blog post_ + - _._ + - _initial commit_ + - _draft post_ + - The blog team will then review your PR and give you comments on things you might need to fix. After that the bot will merge your PR and your blog post will be published. -```yaml ---- -layout: blog -title: "Your Title Here" -date: YYYY-MM-DD -slug: text-for-URL-link-here-no-spaces ---- -``` ## Submit a case study @@ -50,11 +92,4 @@ real-world problems. The Kubernetes marketing team and members of the {{< glossa Have a look at the source for the [existing case studies](https://github.com/kubernetes/website/tree/master/content/en/case-studies). -Refer to the [case study guidelines](https://github.com/cncf/foundation/blob/master/case-study-guidelines.md) and submit your request as outlined in the guidelines. - - - -## {{% heading "whatsnext" %}} - - - +Refer to the [case study guidelines](https://github.com/cncf/foundation/blob/master/case-study-guidelines.md) and submit your request as outlined in the guidelines. diff --git a/content/en/docs/contribute/new-content/open-a-pr.md b/content/en/docs/contribute/new-content/open-a-pr.md index 5b2642dd39..d511360e22 100644 --- a/content/en/docs/contribute/new-content/open-a-pr.md +++ b/content/en/docs/contribute/new-content/open-a-pr.md @@ -1,6 +1,5 @@ --- title: Opening a pull request -slug: new-content content_type: concept weight: 10 card: @@ -97,10 +96,12 @@ Make sure you have [git](https://git-scm.com/book/en/v2/Getting-Started-Installi ### Create a local clone and set the upstream -3. In a terminal window, clone your fork: +3. In a terminal window, clone your fork and update the [Docsy Hugo theme](https://github.com/google/docsy#readme): ```bash git clone git@github.com//website + cd website + git submodule update --init --recursive --depth 1 ``` 4. Navigate to the new `website` directory. Set the `kubernetes/website` repository as the `upstream` remote: @@ -261,18 +262,26 @@ The commands below use Docker as default container engine. Set the `CONTAINER_EN Alternately, install and use the `hugo` command on your computer: -5. Install the [Hugo](https://gohugo.io/getting-started/installing/) version specified in [`website/netlify.toml`](https://raw.githubusercontent.com/kubernetes/website/master/netlify.toml). +1. Install the [Hugo](https://gohugo.io/getting-started/installing/) version specified in [`website/netlify.toml`](https://raw.githubusercontent.com/kubernetes/website/master/netlify.toml). -6. In a terminal, go to your Kubernetes website repository and start the Hugo server: +2. If you have not updated your website repository, the `website/themes/docsy` directory is empty. + The site cannot build without a local copy of the theme. To update the website theme, run: + + ```bash + git submodule update --init --recursive --depth 1 + ``` + +3. In a terminal, go to your Kubernetes website repository and start the Hugo server: ```bash cd /website - hugo server + hugo server --buildFuture ``` -7. In your browser’s address bar, enter `https://localhost:1313`. +4. In a web browser, navigate to `https://localhost:1313`. Hugo watches the + changes and rebuilds the site as needed. -8. To stop the local Hugo instance, go back to the terminal and type `Ctrl+C`, +5. To stop the local Hugo instance, go back to the terminal and type `Ctrl+C`, or close the terminal window. {{% /tab %}} @@ -496,6 +505,6 @@ the templates with as much detail as possible when you file issues or PRs. ## {{% heading "whatsnext" %}} -- Read [Reviewing](/docs/contribute/reviewing/revewing-prs) to learn more about the review process. +- Read [Reviewing](/docs/contribute/review/reviewing-prs) to learn more about the review process. diff --git a/content/en/docs/contribute/new-content/overview.md b/content/en/docs/contribute/new-content/overview.md index e9ef332430..b1f7e4f20a 100644 --- a/content/en/docs/contribute/new-content/overview.md +++ b/content/en/docs/contribute/new-content/overview.md @@ -20,8 +20,12 @@ This section contains information you should know before contributing new conten - Write Kubernetes documentation in Markdown and build the Kubernetes site using [Hugo](https://gohugo.io/). - The source is in [GitHub](https://github.com/kubernetes/website). You can find Kubernetes documentation at `/content/en/docs/`. Some of the reference documentation is automatically generated from scripts in the `update-imported-docs/` directory. - [Page content types](/docs/contribute/style/page-content-types/) describe the presentation of documentation content in Hugo. -- In addition to the standard Hugo shortcodes, we use a number of [custom Hugo shortcodes](/docs/contribute/style/hugo-shortcodes/) in our documentation to control the presentation of content. -- Documentation source is available in multiple languages in `/content/`. Each language has its own folder with a two-letter code determined by the [ISO 639-1 standard](https://www.loc.gov/standards/iso639-2/php/code_list.php). For example, English documentation source is stored in `/content/en/docs/`. +- In addition to the standard Hugo shortcodes, we use a number of + [custom Hugo shortcodes](/docs/contribute/style/hugo-shortcodes/) in our documentation to control the presentation of content. +- Documentation source is available in multiple languages in `/content/`. Each + language has its own folder with a two-letter code determined by the + [ISO 639-1 standard](https://www.loc.gov/standards/iso639-2/php/code_list.php). For + example, English documentation source is stored in `/content/en/docs/`. - For more information about contributing to documentation in multiple languages or starting a new translation, see [localization](/docs/contribute/localization). ## Before you begin {#before-you-begin} diff --git a/content/en/docs/contribute/participate/_index.md b/content/en/docs/contribute/participate/_index.md new file mode 100644 index 0000000000..6a86326945 --- /dev/null +++ b/content/en/docs/contribute/participate/_index.md @@ -0,0 +1,120 @@ +--- +title: Participating in SIG Docs +content_type: concept +weight: 60 +card: + name: contribute + weight: 60 +--- + + + +SIG Docs is one of the +[special interest groups](https://github.com/kubernetes/community/blob/master/sig-list.md) +within the Kubernetes project, focused on writing, updating, and maintaining +the documentation for Kubernetes as a whole. See +[SIG Docs from the community github repo](https://github.com/kubernetes/community/tree/master/sig-docs) +for more information about the SIG. + +SIG Docs welcomes content and reviews from all contributors. Anyone can open a +pull request (PR), and anyone is welcome to file issues about content or comment +on pull requests in progress. + +You can also become a [member](/docs/contribute/participate/roles-and-responsibilities/#members), +[reviewer](/docs/contribute/participate/roles-and-responsibilities/#reviewers), or +[approver](/docs/contribute/participate/roles-and-responsibilities/#approvers). +These roles require greater access and entail certain responsibilities for +approving and committing changes. See +[community-membership](https://github.com/kubernetes/community/blob/master/community-membership.md) +for more information on how membership works within the Kubernetes community. + +The rest of this document outlines some unique ways these roles function within +SIG Docs, which is responsible for maintaining one of the most public-facing +aspects of Kubernetes -- the Kubernetes website and documentation. + + + +## SIG Docs chairperson + +Each SIG, including SIG Docs, selects one or more SIG members to act as +chairpersons. These are points of contact between SIG Docs and other parts of +the Kubernetes organization. They require extensive knowledge of the structure +of the Kubernetes project as a whole and how SIG Docs works within it. See +[Leadership](https://github.com/kubernetes/community/tree/master/sig-docs#leadership) +for the current list of chairpersons. + +## SIG Docs teams and automation + +Automation in SIG Docs relies on two different mechanisms: +GitHub teams and OWNERS files. + +### GitHub teams + +There are two categories of SIG Docs [teams](https://github.com/orgs/kubernetes/teams?query=sig-docs) on GitHub: + +- `@sig-docs-{language}-owners` are approvers and leads +- `@sig-docs-{language}-reviewers` are reviewers + +Each can be referenced with their `@name` in GitHub comments to communicate with +everyone in that group. + +Sometimes Prow and GitHub teams overlap without matching exactly. For +assignment of issues, pull requests, and to support PR approvals, the +automation uses information from `OWNERS` files. + +### OWNERS files and front-matter + +The Kubernetes project uses an automation tool called prow for automation +related to GitHub issues and pull requests. The +[Kubernetes website repository](https://github.com/kubernetes/website) uses +two [prow plugins](https://github.com/kubernetes/test-infra/tree/master/prow/plugins): + +- blunderbuss +- approve + +These two plugins use the +[OWNERS](https://github.com/kubernetes/website/blob/master/OWNERS) and +[OWNERS_ALIASES](https://github.com/kubernetes/website/blob/master/OWNERS_ALIASES) +files in the top level of the `kubernetes/website` GitHub repository to control +how prow works within the repository. + +An OWNERS file contains a list of people who are SIG Docs reviewers and +approvers. OWNERS files can also exist in subdirectories, and can override who +can act as a reviewer or approver of files in that subdirectory and its +descendants. For more information about OWNERS files in general, see +[OWNERS](https://github.com/kubernetes/community/blob/master/contributors/guide/owners.md). + +In addition, an individual Markdown file can list reviewers and approvers in its +front-matter, either by listing individual GitHub usernames or GitHub groups. + +The combination of OWNERS files and front-matter in Markdown files determines +the advice PR owners get from automated systems about who to ask for technical +and editorial review of their PR. + +## How merging works + +When a pull request is merged to the branch used to publish content, that content is published to http://kubernetes.io. To ensure that +the quality of our published content is high, we limit merging pull requests to +SIG Docs approvers. Here's how it works. + +- When a pull request has both the `lgtm` and `approve` labels, has no `hold` + labels, and all tests are passing, the pull request merges automatically. +- Kubernetes organization members and SIG Docs approvers can add comments to + prevent automatic merging of a given pull request (by adding a `/hold` comment + or withholding a `/lgtm` comment). +- Any Kubernetes member can add the `lgtm` label by adding a `/lgtm` comment. +- Only SIG Docs approvers can merge a pull request + by adding an `/approve` comment. Some approvers also perform additional + specific roles, such as [PR Wrangler](/docs/contribute/participate/pr-wranglers/) or + [SIG Docs chairperson](#sig-docs-chairperson). + + + +## {{% heading "whatsnext" %}} + + +For more information about contributing to the Kubernetes documentation, see: + +- [Contributing new content](/docs/contribute/new-content/overview/) +- [Reviewing content](/docs/contribute/review/reviewing-prs) +- [Documentation style guide](/docs/contribute/style/) diff --git a/content/en/docs/contribute/participate/pr-wranglers.md b/content/en/docs/contribute/participate/pr-wranglers.md new file mode 100644 index 0000000000..ba4f2925c2 --- /dev/null +++ b/content/en/docs/contribute/participate/pr-wranglers.md @@ -0,0 +1,82 @@ +--- +title: PR wranglers +content_type: concept +weight: 20 +--- + + + +SIG Docs [approvers](/docs/contribute/participating/roles-and-responsibilites/#approvers) take week-long shifts [managing pull requests](https://github.com/kubernetes/website/wiki/PR-Wranglers) for the repository. + +This section covers the duties of a PR wrangler. For more information on giving good reviews, see [Reviewing changes](/docs/contribute/review/). + + + +## Duties + +Each day in a week-long shift as PR Wrangler: + +- Triage and tag incoming issues daily. See [Triage and categorize issues](/docs/contribute/review/for-approvers/#triage-and-categorize-issues) for guidelines on how SIG Docs uses metadata. +- Review [open pull requests](https://github.com/kubernetes/website/pulls) for quality and adherence to the [Style](/docs/contribute/style/style-guide/) and [Content](/docs/contribute/style/content-guide/) guides. + - Start with the smallest PRs (`size/XS`) first, and end with the largest (`size/XXL`). Review as many PRs as you can. +- Make sure PR contributors sign the [CLA](https://github.com/kubernetes/community/blob/master/CLA.md). + - Use [this](https://github.com/zparnold/k8s-docs-pr-botherer) script to remind contributors that haven’t signed the CLA to do so. +- Provide feedback on changes and ask for technical reviews from members of other SIGs. + - Provide inline suggestions on the PR for the proposed content changes. + - If you need to verify content, comment on the PR and request more details. + - Assign relevant `sig/` label(s). + - If needed, assign reviewers from the `reviewers:` block in the file's front matter. +- Use the `/approve` comment to approve a PR for merging. Merge the PR when ready. + - PRs should have a `/lgtm` comment from another member before merging. + - Consider accepting technically accurate content that doesn't meet the [style guidelines](/docs/contribute/style/style-guide/). Open a new issue with the label `good first issue` to address style concerns. + +### Helpful GitHub queries for wranglers + +The following queries are helpful when wrangling. +After working through these queries, the remaining list of PRs to review is usually small. +These queries exclude localization PRs. All queries are against the main branch except the last one. + +- [No CLA, not eligible to merge](https://github.com/kubernetes/website/pulls?q=is%3Aopen+is%3Apr+label%3A%22cncf-cla%3A+no%22+-label%3A%22do-not-merge%2Fwork-in-progress%22+-label%3A%22do-not-merge%2Fhold%22+label%3Alanguage%2Fen): + Remind the contributor to sign the CLA. If both the bot and a human have reminded them, close + the PR and remind them that they can open it after signing the CLA. + **Do not review PRs whose authors have not signed the CLA!** +- [Needs LGTM](https://github.com/kubernetes/website/pulls?q=is%3Aopen+is%3Apr+-label%3A%22cncf-cla%3A+no%22+-label%3Ado-not-merge%2Fwork-in-progress+-label%3Ado-not-merge%2Fhold+label%3Alanguage%2Fen+-label%3Algtm): + Lists PRs that need an LGTM from a member. If the PR needs technical review, loop in one of the reviewers suggested by the bot. If the content needs work, add suggestions and feedback in-line. +- [Has LGTM, needs docs approval](https://github.com/kubernetes/website/pulls?q=is%3Aopen+is%3Apr+-label%3Ado-not-merge%2Fwork-in-progress+-label%3Ado-not-merge%2Fhold+label%3Alanguage%2Fen+label%3Algtm+): + Lists PRs that need an `/approve` comment to merge. +- [Quick Wins](https://github.com/kubernetes/website/pulls?utf8=%E2%9C%93&q=is%3Apr+is%3Aopen+base%3Amaster+-label%3A%22do-not-merge%2Fwork-in-progress%22+-label%3A%22do-not-merge%2Fhold%22+label%3A%22cncf-cla%3A+yes%22+label%3A%22size%2FXS%22+label%3A%22language%2Fen%22): Lists PRs against the main branch with no clear blockers. (change "XS" in the size label as you work through the PRs [XS, S, M, L, XL, XXL]). +- [Not against the main branch](https://github.com/kubernetes/website/pulls?q=is%3Aopen+is%3Apr+label%3Alanguage%2Fen+-base%3Amaster): If the PR is against a `dev-` branch, it's for an upcoming release. Assign the [docs release manager](https://github.com/kubernetes/sig-release/tree/master/release-team#kubernetes-release-team-roles) using: `/assign @`. If the PR is against an old branch, help the author figure out whether it's targeted against the best branch. + +### Helpful Prow commands for wranglers + +``` +# add English label +/language en + +# add squash label to PR if more than one commit +/label tide/merge-method-squash + +# retitle a PR via Prow (such as a work-in-progress [WIP] or better detail of PR) +/retitle [WIP] +``` + +### When to close Pull Requests + +Reviews and approvals are one tool to keep our PR queue short and current. Another tool is closure. + +Close PRs where: +- The author hasn't signed the CLA for two weeks. + + Authors can reopen the PR after signing the CLA. This is a low-risk way to make sure nothing gets merged without a signed CLA. + +- The author has not responded to comments or feedback in 2 or more weeks. + +Don't be afraid to close pull requests. Contributors can easily reopen and resume works in progress. Often a closure notice is what spurs an author to resume and finish their contribution. + +To close a pull request, leave a `/close` comment on the PR. + +{{< note >}} + +The [`fejta-bot`](https://github.com/fejta-bot) bot marks issues as stale after 90 days of inactivity. After 30 more days it marks issues as rotten and closes them. PR wranglers should close issues after 14-30 days of inactivity. + +{{< /note >}} diff --git a/content/en/docs/contribute/participate/roles-and-responsibilities.md b/content/en/docs/contribute/participate/roles-and-responsibilities.md new file mode 100644 index 0000000000..8ebe7a1303 --- /dev/null +++ b/content/en/docs/contribute/participate/roles-and-responsibilities.md @@ -0,0 +1,237 @@ +--- +title: Roles and responsibilities +content_type: concept +weight: 10 +--- + +<!-- overview --> + +Anyone can contribute to Kubernetes. As your contributions to SIG Docs grow, +you can apply for different levels of membership in the community. +These roles allow you to take on more responsibility within the community. +Each role requires more time and commitment. The roles are: + +- Anyone: regular contributors to the Kubernetes documentation +- Members: can assign and triage issues and provide non-binding review on pull requests +- Reviewers: can lead reviews on documentation pull requests and can vouch for a change's quality +- Approvers: can lead reviews on documentation and merge changes + +<!-- body --> + +## Anyone + +Anyone with a GitHub account can contribute to Kubernetes. SIG Docs welcomes all new contributors! + +Anyone can: + +- Open an issue in any [Kubernetes](https://github.com/kubernetes/) + repository, including + [`kubernetes/website`](https://github.com/kubernetes/website) +- Give non-binding feedback on a pull request +- Contribute to a localization +- Suggest improvements on [Slack](https://slack.k8s.io/) or the + [SIG docs mailing list](https://groups.google.com/forum/#!forum/kubernetes-sig-docs). + +After [signing the CLA](/docs/contribute/new-content/overview/#sign-the-cla), anyone can also: + +- Open a pull request to improve existing content, add new content, or write a blog post or case study +- Create diagrams, graphics assets, and embeddable screencasts and videos + +For more information, see [contributing new content](/docs/contribute/new-content/). + +## Members + +A member is someone who has submitted multiple pull requests to +`kubernetes/website`. Members are a part of the +[Kubernetes GitHub organization](https://github.com/kubernetes). + +Members can: + +- Do everything listed under [Anyone](#anyone) +- Use the `/lgtm` comment to add the LGTM (looks good to me) label to a pull request + + {{< note >}} + Using `/lgtm` triggers automation. If you want to provide non-binding + approval, simply commenting "LGTM" works too! + {{< /note >}} + +- Use the `/hold` comment to block merging for a pull request +- Use the `/assign` comment to assign a reviewer to a pull request +- Provide non-binding review on pull requests +- Use automation to triage and categorize issues +- Document new features + +### Becoming a member + +After submitting at least 5 substantial pull requests and meeting the other +[requirements](https://github.com/kubernetes/community/blob/master/community-membership.md#member): + +1. Find two [reviewers](#reviewers) or [approvers](#approvers) to + [sponsor](/docs/contribute/advanced#sponsor-a-new-contributor) your + membership. + + Ask for sponsorship in the [#sig-docs channel on Slack](https://kubernetes.slack.com) or on the + [SIG Docs mailing list](https://groups.google.com/forum/#!forum/kubernetes-sig-docs). + + {{< note >}} + Don't send a direct email or Slack direct message to an individual + SIG Docs member. You must request sponsorship before submitting your application. + {{< /note >}} + +1. Open a GitHub issue in the + [`kubernetes/org`](https://github.com/kubernetes/org/) repository. Use the + **Organization Membership Request** issue template. + +1. Let your sponsors know about the GitHub issue. You can either: + - Mention their GitHub username in an issue (`@<GitHub-username>`) + - Send them the issue link using Slack or email. + + Sponsors will approve your request with a `+1` vote. Once your sponsors + approve the request, a Kubernetes GitHub admin adds you as a member. + Congratulations! + + If your membership request is not accepted you will receive feedback. + After addressing the feedback, apply again. + +1. Accept the invitation to the Kubernetes GitHub organization in your email account. + + {{< note >}} + GitHub sends the invitation to the default email address in your account. + {{< /note >}} + +## Reviewers + +Reviewers are responsible for reviewing open pull requests. Unlike member +feedback, you must address reviewer feedback. Reviewers are members of the +[@kubernetes/sig-docs-{language}-reviews](https://github.com/orgs/kubernetes/teams?query=sig-docs) +GitHub team. + +Reviewers can: + +- Do everything listed under [Anyone](#anyone) and [Members](#members) +- Review pull requests and provide binding feedback + + {{< note >}} + To provide non-binding feedback, prefix your comments with a phrase like "Optionally: ". + {{< /note >}} + +- Edit user-facing strings in code +- Improve code comments + +You can be a SIG Docs reviewer, or a reviewer for docs in a specific subject area. + +### Assigning reviewers to pull requests + +Automation assigns reviewers to all pull requests. You can request a +review from a specific person by commenting: `/assign +[@_github_handle]`. + +If the assigned reviewer has not commented on the PR, another reviewer can +step in. You can also assign technical reviewers as needed. + +### Using `/lgtm` + +LGTM stands for "Looks good to me" and indicates that a pull request is +technically accurate and ready to merge. All PRs need a `/lgtm` comment from a +reviewer and a `/approve` comment from an approver to merge. + +A `/lgtm` comment from reviewer is binding and triggers automation that adds the `lgtm` label. + +### Becoming a reviewer + +When you meet the +[requirements](https://github.com/kubernetes/community/blob/master/community-membership.md#reviewer), +you can become a SIG Docs reviewer. Reviewers in other SIGs must apply +separately for reviewer status in SIG Docs. + +To apply: + +1. Open a pull request that adds your GitHub user name to a section of the + [OWNERS_ALIASES](https://github.com/kubernetes/website/blob/master/OWNERS) file + in the `kubernetes/website` repository. + + {{< note >}} + If you aren't sure where to add yourself, add yourself to `sig-docs-en-reviews`. + {{< /note >}} + +1. Assign the PR to one or more SIG-Docs approvers (user names listed under + `sig-docs-{language}-owners`). + +If approved, a SIG Docs lead adds you to the appropriate GitHub team. Once added, +[K8s-ci-robot](https://github.com/kubernetes/test-infra/tree/master/prow#bots-home) +assigns and suggests you as a reviewer on new pull requests. + +## Approvers + +Approvers review and approve pull requests for merging. Approvers are members of the +[@kubernetes/sig-docs-{language}-owners](https://github.com/orgs/kubernetes/teams/?query=sig-docs) +GitHub teams. + +Approvers can do the following: + +- Everything listed under [Anyone](#anyone), [Members](#members) and [Reviewers](#reviewers) +- Publish contributor content by approving and merging pull requests using the `/approve` comment +- Propose improvements to the style guide +- Propose improvements to docs tests +- Propose improvements to the Kubernetes website or other tooling + +If the PR already has a `/lgtm`, or if the approver also comments with +`/lgtm`, the PR merges automatically. A SIG Docs approver should only leave a +`/lgtm` on a change that doesn't need additional technical review. + + +### Approving pull requests + +Approvers and SIG Docs leads are the only ones who can merge pull requests +into the website repository. This comes with certain responsibilities. + +- Approvers can use the `/approve` command, which merges PRs into the repo. + + {{< warning >}} + A careless merge can break the site, so be sure that when you merge something, you mean it. + {{< /warning >}} + +- Make sure that proposed changes meet the + [contribution guidelines](/docs/contribute/style/content-guide/#contributing-content). + + If you ever have a question, or you're not sure about something, feel free + to call for additional review. + +- Verify that Netlify tests pass before you `/approve` a PR. + + <img src="/images/docs/contribute/netlify-pass.png" width="75%" alt="Netlify tests must pass before approving" /> + +- Visit the Netlify page preview for a PR to make sure things look good before approving. + +- Participate in the + [PR Wrangler rotation schedule](https://github.com/kubernetes/website/wiki/PR-Wranglers) + for weekly rotations. SIG Docs expects all approvers to participate in this + rotation. See [PR wranglers](/docs/contribute/participate/pr-wranglers/). + for more details. + +### Becoming an approver + +When you meet the +[requirements](https://github.com/kubernetes/community/blob/master/community-membership.md#approver), +you can become a SIG Docs approver. Approvers in other SIGs must apply +separately for approver status in SIG Docs. + +To apply: + +1. Open a pull request adding yourself to a section of the + [OWNERS_ALIASES](https://github.com/kubernetes/website/blob/master/OWNERS) + file in the `kubernetes/website` repository. + + {{< note >}} + If you aren't sure where to add yourself, add yourself to `sig-docs-en-owners`. + {{< /note >}} + +2. Assign the PR to one or more current SIG Docs approvers. + +If approved, a SIG Docs lead adds you to the appropriate GitHub team. Once added, +[@k8s-ci-robot](https://github.com/kubernetes/test-infra/tree/master/prow#bots-home) +assigns and suggests you as a reviewer on new pull requests. + +## {{% heading "whatsnext" %}} + +- Read about [PR wrangling](/docs/contribute/participate/pr-wranglers/), a role all approvers take on rotation. diff --git a/content/en/docs/contribute/participating.md b/content/en/docs/contribute/participating.md deleted file mode 100644 index 681c53f994..0000000000 --- a/content/en/docs/contribute/participating.md +++ /dev/null @@ -1,316 +0,0 @@ ---- -title: Participating in SIG Docs -content_type: concept -weight: 60 -card: - name: contribute - weight: 60 ---- - -<!-- overview --> - -SIG Docs is one of the -[special interest groups](https://github.com/kubernetes/community/blob/master/sig-list.md) -within the Kubernetes project, focused on writing, updating, and maintaining -the documentation for Kubernetes as a whole. See -[SIG Docs from the community github repo](https://github.com/kubernetes/community/tree/master/sig-docs) -for more information about the SIG. - -SIG Docs welcomes content and reviews from all contributors. Anyone can open a -pull request (PR), and anyone is welcome to file issues about content or comment -on pull requests in progress. - -You can also become a [member](#members), -[reviewer](#reviewers), or [approver](#approvers). These roles require greater -access and entail certain responsibilities for approving and committing changes. -See [community-membership](https://github.com/kubernetes/community/blob/master/community-membership.md) -for more information on how membership works within the Kubernetes community. - -The rest of this document outlines some unique ways these roles function within -SIG Docs, which is responsible for maintaining one of the most public-facing -aspects of Kubernetes -- the Kubernetes website and documentation. - - - -<!-- body --> - -## Roles and responsibilities - -- **Anyone** can contribute to Kubernetes documentation. To contribute, you must [sign the CLA](/docs/contribute/new-content/overview/#sign-the-cla) and have a GitHub account. -- **Members** of the Kubernetes organization are contributors who have spent time and effort on the Kubernetes project, usually by opening pull requests with accepted changes. See [Community membership](https://github.com/kubernetes/community/blob/master/community-membership.md) for membership criteria. -- A SIG Docs **Reviewer** is a member of the Kubernetes organization who has - expressed interest in reviewing documentation pull requests, and has been - added to the appropriate GitHub group and `OWNERS` files in the GitHub - repository by a SIG Docs Approver. -- A SIG Docs **Approver** is a member in good standing who has shown a continued - commitment to the project. An approver can merge pull requests - and publish content on behalf of the Kubernetes organization. - Approvers can also represent SIG Docs in the larger Kubernetes community. - Some duties of a SIG Docs approver, such as coordinating a release, - require a significant time commitment. - -## Anyone - -Anyone can do the following: - -- Open a GitHub issue against any part of Kubernetes, including documentation. -- Provide non-binding feedback on a pull request. -- Help to localize existing content -- Bring up ideas for improvement on [Slack](http://slack.k8s.io/) or the [SIG docs mailing list](https://groups.google.com/forum/#!forum/kubernetes-sig-docs). -- Use the `/lgtm` Prow command (short for "looks good to me") to recommend the changes in a pull request for merging. - {{< note >}} - If you are not a member of the Kubernetes organization, using `/lgtm` has no effect on automated systems. - {{< /note >}} - -After [signing the CLA](/docs/contribute/new-content/overview/#sign-the-cla), anyone can also: -- Open a pull request to improve existing content, add new content, or write a blog post or case study. - -## Members - -Members are contributors to the Kubernetes project who meet the [membership criteria](https://github.com/kubernetes/community/blob/master/community-membership.md#member). SIG Docs welcomes contributions from all members of the Kubernetes community, -and frequently requests reviews from members of other SIGs for technical accuracy. - -Any member of the [Kubernetes organization](https://github.com/kubernetes) can do the following: - -- Everything listed under [Anyone](#anyone) -- Use the `/lgtm` comment to add the LGTM (looks good to me) label to a pull request. -- Use the `/hold` command to prevent a pull request from being merged, if the pull request already has the LGTM and approve labels. -- Use the `/assign` comment to assign a reviewer to a pull request. - -### Becoming a member - -After you have successfully submitted at least 5 substantive pull requests, you -can request [membership](https://github.com/kubernetes/community/blob/master/community-membership.md#member) -in the Kubernetes organization. Follow these steps: - -1. Find two reviewers or approvers to [sponsor](/docs/contribute/advanced#sponsor-a-new-contributor) - your membership. - - Ask for sponsorship in the [#sig-docs channel on the - Kubernetes Slack instance](https://kubernetes.slack.com) or on the - [SIG Docs mailing list](https://groups.google.com/forum/#!forum/kubernetes-sig-docs). - - {{< note >}} - Don't send a direct email or Slack direct message to an individual - SIG Docs member. - {{< /note >}} - -2. Open a GitHub issue in the `kubernetes/org` repository to request membership. - Fill out the template using the guidelines at - [Community membership](https://github.com/kubernetes/community/blob/master/community-membership.md). - -3. Let your sponsors know about the GitHub issue, either by at-mentioning them - in the GitHub issue (adding a comment with `@<GitHub-username>`) or by sending them the link directly, - so that they can add a `+1` vote. - -4. When your membership is approved, the github admin team member assigned to your request updates the - GitHub issue to show approval and then closes the GitHub issue. - Congratulations, you are now a member! - -If your membership request is not accepted, the -membership committee provides information or steps to take before applying -again. - -## Reviewers - -Reviewers are members of the -[@kubernetes/sig-docs-pr-reviews](https://github.com/orgs/kubernetes/teams/sig-docs-pr-reviews) -GitHub group. Reviewers review documentation pull requests and provide feedback on proposed -changes. Reviewers can: - -- Do everything listed under [Anyone](#anyone) and [Members](#members) -- Document new features -- Triage and categorize issues -- Review pull requests and provide binding feedback -- Create diagrams, graphics assets, and embeddable screencasts and videos -- Edit user-facing strings in code -- Improve code comments - -### Assigning reviewers to pull requests - -Automation assigns reviewers to all pull requests. You can request a -review from a specific reviewer with a comment on the pull request: `/assign -[@_github_handle]`. To indicate that a pull request is technically accurate and -requires no further changes, a reviewer adds a `/lgtm` comment to the pull -request. - -If the assigned reviewer has not yet reviewed the content, another reviewer can -step in. In addition, you can assign technical reviewers and wait for them to -provide a `/lgtm` comment. - -For a trivial change or one that needs no technical review, SIG Docs -[approvers](#approvers) can provide the `/lgtm` as well. - -An `/approve` comment from a reviewer is ignored by automation. - -### Becoming a reviewer - -When you meet the -[requirements](https://github.com/kubernetes/community/blob/master/community-membership.md#reviewer), -you can become a SIG Docs reviewer. Reviewers in other SIGs must apply -separately for reviewer status in SIG Docs. - -To apply, open a pull request to add yourself to the `reviewers` section of the -[top-level OWNERS file](https://github.com/kubernetes/website/blob/master/OWNERS) -in the `kubernetes/website` repository. Assign the PR to one or more current SIG -Docs approvers. - -If your pull request is approved, you are now a SIG Docs reviewer. -[K8s-ci-robot](https://github.com/kubernetes/test-infra/tree/master/prow#bots-home) -will assign and suggest you as a reviewer on new pull requests. - -If you are approved, request that a current SIG Docs approver add you to the -[@kubernetes/sig-docs-pr-reviews](https://github.com/orgs/kubernetes/teams/sig-docs-pr-reviews) -GitHub group. Only members of the `kubernetes-website-admins` GitHub group can -add new members to a GitHub group. - -## Approvers - -Approvers are members of the -[@kubernetes/sig-docs-maintainers](https://github.com/orgs/kubernetes/teams/sig-docs-maintainers) -GitHub group. See [SIG Docs teams and automation](#sig-docs-teams-and-automation) for details. - -Approvers can do the following: - -- Everything listed under [Anyone](#anyone), [Members](#members) and [Reviewers](#reviewers) -- Publish contributor content by approving and merging pull requests using the `/approve` comment. - If someone who is not an approver leaves the approval comment, automation ignores it. -- Participate in a Kubernetes release team as a docs representative -- Propose improvements to the style guide -- Propose improvements to docs tests -- Propose improvements to the Kubernetes website or other tooling - -If the PR already has a `/lgtm`, or if the approver also comments with `/lgtm`, -the PR merges automatically. A SIG Docs approver should only leave a `/lgtm` on -a change that doesn't need additional technical review. - -### Becoming an approver - -When you meet the -[requirements](https://github.com/kubernetes/community/blob/master/community-membership.md#approver), -you can become a SIG Docs approver. Approvers in other SIGs must apply -separately for approver status in SIG Docs. - -To apply, open a pull request to add yourself to the `approvers` section of the -[top-level OWNERS file](https://github.com/kubernetes/website/blob/master/OWNERS) -in the `kubernetes/website` repository. Assign the PR to one or more current SIG -Docs approvers. - -If your pull request is approved, you are now a SIG Docs approver. -[K8s-ci-robot](https://github.com/kubernetes/test-infra/tree/master/prow#bots-home) -will assign and suggest you as a reviewer on new pull requests. - -If you are approved, request that a current SIG Docs approver add you to the -[@kubernetes/sig-docs-maintainers](https://github.com/orgs/kubernetes/teams/sig-docs-maintainers) -GitHub group. Only members of the `kubernetes-website-admins` GitHub group can -add new members to a GitHub group. - -### Approver responsibilities - -Approvers improve the documentation by reviewing and merging pull requests into the website repository. Because this role carries additional privileges, approvers have additional responsibilities: - -- Approvers can use the `/approve` command, which merges PRs into the repo. - - A careless merge can break the site, so be sure that when you merge something, you mean it. - -- Make sure that proposed changes meet the [contribution guidelines](/docs/contribute/style/content-guide/#contributing-content). - - If you ever have a question, or you're not sure about something, feel free to call for additional review. - -- Verify that Netlify tests pass before you `/approve` a PR. - - <img src="/images/docs/contribute/netlify-pass.png" width="75%" alt="Netlify tests must pass before approving" /> - -- Visit the Netlify page preview for a PR to make sure things look good before approving. - -- Participate in the [PR Wrangler rotation schedule](https://github.com/kubernetes/website/wiki/PR-Wranglers) for weekly rotations. SIG Docs expects all approvers to participate in this -rotation. See [Be the PR Wrangler for a week](/docs/contribute/advanced#be-the-pr-wrangler-for-a-week) -for more details. - -## SIG Docs chairperson - -Each SIG, including SIG Docs, selects one or more SIG members to act as -chairpersons. These are points of contact between SIG Docs and other parts of -the Kubernetes organization. They require extensive knowledge of the structure -of the Kubernetes project as a whole and how SIG Docs works within it. See -[Leadership](https://github.com/kubernetes/community/tree/master/sig-docs#leadership) -for the current list of chairpersons. - -## SIG Docs teams and automation - -Automation in SIG Docs relies on two different mechanisms for automation: -GitHub groups and OWNERS files. - -### GitHub groups - -The SIG Docs group defines two teams on GitHub: - - - [@kubernetes/sig-docs-maintainers](https://github.com/orgs/kubernetes/teams/sig-docs-maintainers) - - [@kubernetes/sig-docs-pr-reviews](https://github.com/orgs/kubernetes/teams/sig-docs-pr-reviews) - -Each can be referenced with their `@name` in GitHub comments to communicate with -everyone in that group. - -These teams overlap, but do not exactly match, the groups used by the automation -tooling. For assignment of issues, pull requests, and to support PR approvals, -the automation uses information from OWNERS files. - -### OWNERS files and front-matter - -The Kubernetes project uses an automation tool called prow for automation -related to GitHub issues and pull requests. The -[Kubernetes website repository](https://github.com/kubernetes/website) uses -two [prow plugins](https://github.com/kubernetes/test-infra/tree/master/prow/plugins): - -- blunderbuss -- approve - -These two plugins use the -[OWNERS](https://github.com/kubernetes/website/blob/master/OWNERS) and -[OWNERS_ALIASES](https://github.com/kubernetes/website/blob/master/OWNERS_ALIASES) -files in the top level of the `kubernetes/website` GitHub repository to control -how prow works within the repository. - -An OWNERS file contains a list of people who are SIG Docs reviewers and -approvers. OWNERS files can also exist in subdirectories, and can override who -can act as a reviewer or approver of files in that subdirectory and its -descendents. For more information about OWNERS files in general, see -[OWNERS](https://github.com/kubernetes/community/blob/master/contributors/guide/owners.md). - -In addition, an individual Markdown file can list reviewers and approvers in its -front-matter, either by listing individual GitHub usernames or GitHub groups. - -The combination of OWNERS files and front-matter in Markdown files determines -the advice PR owners get from automated systems about who to ask for technical -and editorial review of their PR. - -## How merging works - -When a pull request is merged to the branch used to publish content (currently -`master`), that content is published and available to the world. To ensure that -the quality of our published content is high, we limit merging pull requests to -SIG Docs approvers. Here's how it works. - -- When a pull request has both the `lgtm` and `approve` labels, has no `hold` - labels, and all tests are passing, the pull request merges automatically. -- Kubernetes organization members and SIG Docs approvers can add comments to - prevent automatic merging of a given pull request (by adding a `/hold` comment - or withholding a `/lgtm` comment). -- Any Kubernetes member can add the `lgtm` label by adding a `/lgtm` comment. -- Only SIG Docs approvers can merge a pull request - by adding an `/approve` comment. Some approvers also perform additional - specific roles, such as [PR Wrangler](/docs/contribute/advanced#be-the-pr-wrangler-for-a-week) or - [SIG Docs chairperson](#sig-docs-chairperson). - - - -## {{% heading "whatsnext" %}} - - -For more information about contributing to the Kubernetes documentation, see: - -- [Contributing new content](/docs/contribute/overview/) -- [Reviewing content](/docs/contribute/review/reviewing-prs) -- [Documentation style guide](/docs/contribute/style/) - - diff --git a/content/en/docs/contribute/review/for-approvers.md b/content/en/docs/contribute/review/for-approvers.md index 0cddbcba6a..82a05bdb86 100644 --- a/content/en/docs/contribute/review/for-approvers.md +++ b/content/en/docs/contribute/review/for-approvers.md @@ -8,7 +8,9 @@ weight: 20 <!-- overview --> -SIG Docs [Reviewers](/docs/contribute/participating/#reviewers) and [Approvers](/docs/contribute/participating/#approvers) do a few extra things when reviewing a change. +SIG Docs [Reviewers](/docs/contribute/participate/#reviewers) and +[Approvers](/docs/contribute/participate/#approvers) do a few extra things +when reviewing a change. Every week a specific docs approver volunteers to triage and review pull requests. This @@ -19,9 +21,6 @@ requests (PRs) that are not already under active review. In addition to the rotation, a bot assigns reviewers and approvers for the PR based on the owners for the affected files. - - - <!-- body --> ## Reviewing a PR @@ -202,9 +201,9 @@ Sample response to a request for support: This issue sounds more like a request for support and less like an issue specifically for docs. I encourage you to bring your question to the `#kubernetes-users` channel in -[Kubernetes slack](http://slack.k8s.io/). You can also search +[Kubernetes slack](https://slack.k8s.io/). You can also search resources like -[Stack Overflow](http://stackoverflow.com/questions/tagged/kubernetes) +[Stack Overflow](https://stackoverflow.com/questions/tagged/kubernetes) for answers to similar questions. You can also open issues for Kubernetes functionality in diff --git a/content/en/docs/contribute/review/reviewing-prs.md b/content/en/docs/contribute/review/reviewing-prs.md index 3c271aa44f..ff6ef9d709 100644 --- a/content/en/docs/contribute/review/reviewing-prs.md +++ b/content/en/docs/contribute/review/reviewing-prs.md @@ -16,10 +16,10 @@ It helps you learn the code base and build trust with other contributors. Before reviewing, it's a good idea to: - Read the [content guide](/docs/contribute/style/content-guide/) and -[style guide](/docs/contribute/style/style-guide/) so you can leave informed comments. -- Understand the different [roles and responsibilities](/docs/contribute/participating/#roles-and-responsibilities) in the Kubernetes documentation community. - - + [style guide](/docs/contribute/style/style-guide/) so you can leave informed comments. +- Understand the different + [roles and responsibilities](/docs/contribute/participate/roles-and-responsibilities/) + in the Kubernetes documentation community. <!-- body --> diff --git a/content/en/docs/contribute/style/content-guide.md b/content/en/docs/contribute/style/content-guide.md index 2f367c9a81..0de4a381a3 100644 --- a/content/en/docs/contribute/style/content-guide.md +++ b/content/en/docs/contribute/style/content-guide.md @@ -9,10 +9,10 @@ weight: 10 This page contains guidelines for Kubernetes documentation. -If you have questions about what's allowed, join the #sig-docs channel in -[Kubernetes Slack](http://slack.k8s.io/) and ask! +If you have questions about what's allowed, join the #sig-docs channel in +[Kubernetes Slack](https://slack.k8s.io/) and ask! -You can register for Kubernetes Slack at http://slack.k8s.io/. +You can register for Kubernetes Slack at https://slack.k8s.io/. For information on creating new content for the Kubernetes docs, follow the [style guide](/docs/contribute/style/style-guide). @@ -28,7 +28,7 @@ Source for the Kubernetes website, including the docs, resides in the Located in the `kubernetes/website/content/<language_code>/docs` folder, the majority of Kubernetes documentation is specific to the [Kubernetes -project](https://github.com/kubernetes/kubernetes). +project](https://github.com/kubernetes/kubernetes). ## What's allowed @@ -41,12 +41,12 @@ Kubernetes docs allow content for third-party projects only when: ### Third party content Kubernetes documentation includes applied examples of projects in the Kubernetes project—projects that live in the [kubernetes](https://github.com/kubernetes) and -[kubernetes-sigs](https://github.com/kubernetes-sigs) GitHub organizations. +[kubernetes-sigs](https://github.com/kubernetes-sigs) GitHub organizations. -Links to active content in the Kubernetes project are always allowed. +Links to active content in the Kubernetes project are always allowed. -Kubernetes requires some third party content to function. Examples include container runtimes (containerd, CRI-O, Docker), -[networking policy](/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/) (CNI plugins), [Ingress controllers](https://kubernetes.io/docs/concepts/services-networking/ingress-controllers/), and [logging](https://kubernetes.io/docs/concepts/cluster-administration/logging/). +Kubernetes requires some third party content to function. Examples include container runtimes (containerd, CRI-O, Docker), +[networking policy](/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/) (CNI plugins), [Ingress controllers](/docs/concepts/services-networking/ingress-controllers/), and [logging](/docs/concepts/cluster-administration/logging/). Docs can link to third-party open source software (OSS) outside the Kubernetes project only if it's necessary for Kubernetes to function. @@ -60,14 +60,14 @@ and grows stale more quickly. {{< note >}} -If you're a maintainer for a Kubernetes project and need help hosting your own docs, +If you're a maintainer for a Kubernetes project and need help hosting your own docs, ask for help in [#sig-docs on Kubernetes Slack](https://kubernetes.slack.com/messages/C1J0BPD2M/). {{< /note >}} ### More information -If you have questions about allowed content, join the [Kubernetes Slack](http://slack.k8s.io/) #sig-docs channel and ask! +If you have questions about allowed content, join the [Kubernetes Slack](https://slack.k8s.io/) #sig-docs channel and ask! @@ -75,5 +75,3 @@ If you have questions about allowed content, join the [Kubernetes Slack](http:// * Read the [Style guide](/docs/contribute/style/style-guide). - - diff --git a/content/en/docs/contribute/style/hugo-shortcodes/index.md b/content/en/docs/contribute/style/hugo-shortcodes/index.md index e4a6d703ad..ab949be7fc 100644 --- a/content/en/docs/contribute/style/hugo-shortcodes/index.md +++ b/content/en/docs/contribute/style/hugo-shortcodes/index.md @@ -232,7 +232,7 @@ Renders to: {{< tabs name="tab_with_file_include" >}} {{< tab name="Content File #1" include="example1" />}} {{< tab name="Content File #2" include="example2" />}} -{{< tab name="JSON File" include="podtemplate" />}} +{{< tab name="JSON File" include="podtemplate.json" />}} {{< /tabs >}} @@ -242,6 +242,6 @@ Renders to: * Learn about [Hugo](https://gohugo.io/). * Learn about [writing a new topic](/docs/contribute/style/write-new-topic/). * Learn about [page content types](/docs/contribute/style/page-content-types/). -* Learn about [creating a pull request](/docs/contribute/new-content/new-content/). +* Learn about [opening a pull request](/docs/contribute/new-content/open-a-pr/). * Learn about [advanced contributing](/docs/contribute/advanced/). diff --git a/content/en/docs/contribute/style/page-content-types.md b/content/en/docs/contribute/style/page-content-types.md index 2a3325d397..5d3b519bc0 100644 --- a/content/en/docs/contribute/style/page-content-types.md +++ b/content/en/docs/contribute/style/page-content-types.md @@ -191,7 +191,7 @@ Within each section, write your content. Use the following guidelines: interested in reading next. An example of a published tutorial topic is -[Running a Stateless Application Using a Deployment](/docs/tutorials/stateless-application/run-stateless-application-deployment/). +[Running a Stateless Application Using a Deployment](/docs/tasks/run-application/run-stateless-application-deployment/). ### Reference diff --git a/content/en/docs/contribute/style/style-guide.md b/content/en/docs/contribute/style/style-guide.md index 78ddd4a787..44653708ec 100644 --- a/content/en/docs/contribute/style/style-guide.md +++ b/content/en/docs/contribute/style/style-guide.md @@ -22,8 +22,11 @@ discussion. <!-- body --> {{< note >}} -Kubernetes documentation uses [Blackfriday Markdown Renderer](https://github.com/russross/blackfriday) along with a few [Hugo Shortcodes](/docs/home/contribute/includes/) to support glossary entries, tabs, -and representing feature state. +Kubernetes documentation uses +[Goldmark Markdown Renderer](https://github.com/yuin/goldmark) +with some adjustments along with a few +[Hugo Shortcodes](/docs/contribute/style/hugo-shortcodes/) to support +glossary entries, tabs, and representing feature state. {{< /note >}} ## Language @@ -121,7 +124,7 @@ document, use the backtick (`` ` ``). {{< table caption = "Do and Don't - Use code style for inline code and commands" >}} Do | Don't :--| :----- -The `kubectl run`command creates a Deployment. | The "kubectl run" command creates a Deployment. +The `kubectl run`command creates a Pod. | The "kubectl run" command creates a Pod. For declarative management, use `kubectl apply`. | For declarative management, use "kubectl apply". Enclose code samples with triple backticks. (\`\`\`)| Enclose code samples with any other syntax. Use single backticks to enclose inline code. For example, `var example = true`. | Use two asterisks (`**`) or an underscore (`_`) to enclose inline code. For example, **var example = true**. @@ -496,7 +499,7 @@ Do | Don't :--| :----- You can explore the API using a browser. | The API can be explored using a browser. The YAML file specifies the replica count. | The replica count is specified in the YAML file. -{{< /table >}} +{{< /table >}} Exception: Use passive voice if active voice leads to an awkward construction. @@ -511,7 +514,7 @@ Do | Don't To create a ReplicaSet, ... | In order to create a ReplicaSet, ... See the configuration file. | Please see the configuration file. View the Pods. | With this next command, we'll view the Pods. -{{< /table >}} +{{< /table >}} ### Address the reader as "you" @@ -520,7 +523,7 @@ Do | Don't :--| :----- You can create a Deployment by ... | We'll create a Deployment by ... In the preceding output, you can see... | In the preceding output, we can see ... -{{< /table >}} +{{< /table >}} ### Avoid Latin phrases @@ -532,7 +535,7 @@ Do | Don't :--| :----- For example, ... | e.g., ... That is, ...| i.e., ... -{{< /table >}} +{{< /table >}} Exception: Use "etc." for et cetera. @@ -550,7 +553,7 @@ Do | Don't Version 1.4 includes ... | In version 1.4, we have added ... Kubernetes provides a new feature for ... | We provide a new feature ... This page teaches you how to use Pods. | In this page, we are going to learn about Pods. -{{< /table >}} +{{< /table >}} ### Avoid jargon and idioms @@ -562,7 +565,7 @@ Do | Don't :--| :----- Internally, ... | Under the hood, ... Create a new cluster. | Turn up a new cluster. -{{< /table >}} +{{< /table >}} ### Avoid statements about the future @@ -581,15 +584,11 @@ Do | Don't :--| :----- In version 1.4, ... | In the current version, ... The Federation feature provides ... | The new Federation feature provides ... -{{< /table >}} - - +{{< /table >}} ## {{% heading "whatsnext" %}} - * Learn about [writing a new topic](/docs/contribute/style/write-new-topic/). * Learn about [using page templates](/docs/contribute/style/page-content-types/). -* Learn about [staging your changes](/docs/contribute/stage-documentation-changes/) * Learn about [creating a pull request](/docs/contribute/new-content/open-a-pr/). diff --git a/content/en/docs/contribute/style/write-new-topic.md b/content/en/docs/contribute/style/write-new-topic.md index 8bd4b8fbe2..7cac1aa6b7 100644 --- a/content/en/docs/contribute/style/write-new-topic.md +++ b/content/en/docs/contribute/style/write-new-topic.md @@ -11,7 +11,7 @@ This page shows how to create a new topic for the Kubernetes docs. ## {{% heading "prerequisites" %}} Create a fork of the Kubernetes documentation repository as described in -[Open a PR](/docs/new-content/open-a-pr/). +[Open a PR](/docs/contribute/new-content/open-a-pr/). <!-- steps --> @@ -28,9 +28,17 @@ Task | A task page shows how to do a single thing. The idea is to give readers a Tutorial | A tutorial page shows how to accomplish a goal that ties together several Kubernetes features. A tutorial might provide several sequences of steps that readers can actually do as they read the page. Or it might provide explanations of related pieces of code. For example, a tutorial could provide a walkthrough of a code sample. A tutorial can include brief explanations of the Kubernetes features that are being tied together, but should link to related concept topics for deep explanations of individual features. {{< /table >}} +### Creating a new page + Use a [content type](/docs/contribute/style/page-content-types/) for each new page -that you write. Using page type helps ensure -consistency among topics of a given type. +that you write. The docs site provides templates or +[Hugo archetypes](https://gohugo.io/content-management/archetypes/) to create +new content pages. To create a new type of page, run `hugo new` with the path to the file +you want to create. For example: + +``` +hugo new docs/concepts/my-first-concept.md +``` ## Choosing a title and filename @@ -152,7 +160,7 @@ submitted to ensure all examples pass the tests. {{< /note >}} For an example of a topic that uses this technique, see -[Running a Single-Instance Stateful Application](/docs/tutorials/stateful-application/run-stateful-application/). +[Running a Single-Instance Stateful Application](/docs/tasks/run-application/run-single-instance-stateful-application/). ## Adding images to a topic diff --git a/content/en/docs/reference/_index.md b/content/en/docs/reference/_index.md index 619430875e..7cf556f02c 100644 --- a/content/en/docs/reference/_index.md +++ b/content/en/docs/reference/_index.md @@ -35,7 +35,7 @@ client libraries: ## CLI Reference * [kubectl](/docs/reference/kubectl/overview/) - Main CLI tool for running commands and managing Kubernetes clusters. - * [JSONPath](/docs/reference/kubectl/jsonpath/) - Syntax guide for using [JSONPath expressions](http://goessner.net/articles/JsonPath/) with kubectl. + * [JSONPath](/docs/reference/kubectl/jsonpath/) - Syntax guide for using [JSONPath expressions](https://goessner.net/articles/JsonPath/) with kubectl. * [kubeadm](/docs/reference/setup-tools/kubeadm/kubeadm/) - CLI tool to easily provision a secure Kubernetes cluster. ## Components Reference @@ -50,6 +50,8 @@ client libraries: ## Design Docs -An archive of the design docs for Kubernetes functionality. Good starting points are [Kubernetes Architecture](https://git.k8s.io/community/contributors/design-proposals/architecture/architecture.md) and [Kubernetes Design Overview](https://git.k8s.io/community/contributors/design-proposals). +An archive of the design docs for Kubernetes functionality. Good starting points are +[Kubernetes Architecture](https://git.k8s.io/community/contributors/design-proposals/architecture/architecture.md) and +[Kubernetes Design Overview](https://git.k8s.io/community/contributors/design-proposals). diff --git a/content/en/docs/reference/access-authn-authz/_index.md b/content/en/docs/reference/access-authn-authz/_index.md index d4966d99a5..4e1bff0818 100644 --- a/content/en/docs/reference/access-authn-authz/_index.md +++ b/content/en/docs/reference/access-authn-authz/_index.md @@ -1,5 +1,4 @@ --- title: Accessing the API weight: 20 -toc-hide: true --- \ No newline at end of file diff --git a/content/en/docs/reference/access-authn-authz/abac.md b/content/en/docs/reference/access-authn-authz/abac.md index 3810942660..99fce41aba 100644 --- a/content/en/docs/reference/access-authn-authz/abac.md +++ b/content/en/docs/reference/access-authn-authz/abac.md @@ -18,7 +18,7 @@ Attribute-based access control (ABAC) defines an access control paradigm whereby To enable `ABAC` mode, specify `--authorization-policy-file=SOME_FILENAME` and `--authorization-mode=ABAC` on startup. -The file format is [one JSON object per line](http://jsonlines.org/). There +The file format is [one JSON object per line](https://jsonlines.org/). There should be no enclosing list or map, just one map per line. Each line is a "policy object", where each such object is a map with the following @@ -127,7 +127,7 @@ up the verbosity: {"apiVersion": "abac.authorization.kubernetes.io/v1beta1", "kind": "Policy", "spec": {"group": "system:unauthenticated", "readonly": true, "nonResourcePath": "*"}} ``` -[Complete file example](http://releases.k8s.io/{{< param "githubbranch" >}}/pkg/auth/authorizer/abac/example_policy_file.jsonl) +[Complete file example](https://releases.k8s.io/{{< param "githubbranch" >}}/pkg/auth/authorizer/abac/example_policy_file.jsonl) ## A quick note on service accounts 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 874bcbeb1c..fda7119caf 100644 --- a/content/en/docs/reference/access-authn-authz/admission-controllers.md +++ b/content/en/docs/reference/access-authn-authz/admission-controllers.md @@ -25,8 +25,8 @@ is authenticated and authorized. The controllers consist of the `kube-apiserver` binary, and may only be configured by the cluster administrator. In that list, there are two special controllers: MutatingAdmissionWebhook and ValidatingAdmissionWebhook. These execute the -mutating and validating (respectively) [admission control -webhooks](/docs/reference/access-authn-authz/extensible-admission-controllers/#admission-webhooks) +mutating and validating (respectively) +[admission control webhooks](/docs/reference/access-authn-authz/extensible-admission-controllers/#admission-webhooks) which are configured in the API. Admission controllers may be "validating", "mutating", or both. Mutating @@ -351,7 +351,10 @@ plugins: {{% /tab %}} {{< /tabs >}} -The ImagePolicyWebhook config file must reference a [kubeconfig](/docs/concepts/cluster-administration/authenticate-across-clusters-kubeconfig/) formatted file which sets up the connection to the backend. It is required that the backend communicate over TLS. +The ImagePolicyWebhook config file must reference a +[kubeconfig](/docs/tasks/access-application-cluster/configure-access-multiple-clusters/) +formatted file which sets up the connection to the backend. +It is required that the backend communicate over TLS. The kubeconfig file's cluster field must point to the remote service, and the user field must contain the returned authorizer. @@ -371,7 +374,8 @@ users: client-key: /path/to/key.pem # key matching the cert ``` -For additional HTTP configuration, refer to the [kubeconfig](/docs/concepts/cluster-administration/authenticate-across-clusters-kubeconfig/) documentation. +For additional HTTP configuration, refer to the +[kubeconfig](/docs/tasks/access-application-cluster/configure-access-multiple-clusters/) documentation. #### Request Payloads @@ -454,7 +458,8 @@ your Kubernetes deployment, you MUST use this admission controller to enforce th be used to apply default resource requests to Pods that don't specify any; currently, the default LimitRanger applies a 0.1 CPU requirement to all Pods in the `default` namespace. -See the [limitRange design doc](https://git.k8s.io/community/contributors/design-proposals/resource-management/admission_control_limit_range.md) and the [example of Limit Range](/docs/tasks/configure-pod-container/limit-range/) for more details. +See the [limitRange design doc](https://git.k8s.io/community/contributors/design-proposals/resource-management/admission_control_limit_range.md) +and the [example of Limit Range](/docs/tasks/administer-cluster/manage-resources/memory-default-namespace/) for more details. ### MutatingAdmissionWebhook {#mutatingadmissionwebhook} @@ -677,9 +682,6 @@ for more information. This admission controller acts on creation and modification of the pod and determines if it should be admitted based on the requested security context and the available Pod Security Policies. -For Kubernetes < 1.6.0, the API Server must enable the extensions/v1beta1/podsecuritypolicy API -extensions group (`--runtime-config=extensions/v1beta1/podsecuritypolicy=true`). - See also [Pod Security Policy documentation](/docs/concepts/policy/pod-security-policy/) for more information. @@ -706,8 +708,8 @@ kind: Namespace metadata: name: apps-that-need-nodes-exclusively annotations: - scheduler.alpha.kubernetes.io/defaultTolerations: '{"operator": "Exists", "effect": "NoSchedule", "key": "dedicated-node"}' - scheduler.alpha.kubernetes.io/tolerationsWhitelist: '{"operator": "Exists", "effect": "NoSchedule", "key": "dedicated-node"}' + scheduler.alpha.kubernetes.io/defaultTolerations: '[{"operator": "Exists", "effect": "NoSchedule", "key": "dedicated-node"}]' + scheduler.alpha.kubernetes.io/tolerationsWhitelist: '[{"operator": "Exists", "effect": "NoSchedule", "key": "dedicated-node"}]' ``` ### Priority {#priority} @@ -734,16 +736,30 @@ for more information. ### SecurityContextDeny {#securitycontextdeny} -This admission controller will deny any pod that attempts to set certain escalating [SecurityContext](/docs/user-guide/security-context) fields. This should be enabled if a cluster doesn't utilize [pod security policies](/docs/user-guide/pod-security-policy) to restrict the set of values a security context can take. +This admission controller will deny any pod that attempts to set certain escalating +[SecurityContext](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#securitycontext-v1-core) +fields, as shown in the +[Configure a Security Context for a Pod or Container](/docs/tasks/configure-pod-container/security-context/) +task. +This should be enabled if a cluster doesn't utilize +[pod security policies](/docs/concepts/policy/pod-security-policy/) +to restrict the set of values a security context can take. ### ServiceAccount {#serviceaccount} -This admission controller implements automation for [serviceAccounts](/docs/user-guide/service-accounts). +This admission controller implements automation for +[serviceAccounts](/docs/tasks/configure-pod-container/configure-service-account/). We strongly recommend using this admission controller if you intend to make use of Kubernetes `ServiceAccount` objects. ### StorageObjectInUseProtection -The `StorageObjectInUseProtection` plugin adds the `kubernetes.io/pvc-protection` or `kubernetes.io/pv-protection` finalizers to newly created Persistent Volume Claims (PVCs) or Persistent Volumes (PV). In case a user deletes a PVC or PV the PVC or PV is not removed until the finalizer is removed from the PVC or PV by PVC or PV Protection Controller. Refer to the [Storage Object in Use Protection](/docs/concepts/storage/persistent-volumes/#storage-object-in-use-protection) for more detailed information. +The `StorageObjectInUseProtection` plugin adds the `kubernetes.io/pvc-protection` or `kubernetes.io/pv-protection` +finalizers to newly created Persistent Volume Claims (PVCs) or Persistent Volumes (PV). +In case a user deletes a PVC or PV the PVC or PV is not removed until the finalizer is removed +from the PVC or PV by PVC or PV Protection Controller. +Refer to the +[Storage Object in Use Protection](/docs/concepts/storage/persistent-volumes/#storage-object-in-use-protection) +for more detailed information. ### TaintNodesByCondition {#taintnodesbycondition} @@ -793,4 +809,4 @@ phase, and therefore is the last admission controller to run. in the mutating phase. For earlier versions, there was no concept of validating versus mutating and the -admission controllers ran in the exact order specified. \ No newline at end of file +admission controllers ran in the exact order specified. diff --git a/content/en/docs/reference/access-authn-authz/authentication.md b/content/en/docs/reference/access-authn-authz/authentication.md index 8cb8013c76..18a83cac6e 100644 --- a/content/en/docs/reference/access-authn-authz/authentication.md +++ b/content/en/docs/reference/access-authn-authz/authentication.md @@ -20,11 +20,24 @@ This page provides an overview of authenticating. All Kubernetes clusters have two categories of users: service accounts managed by Kubernetes, and normal users. -Normal users are assumed to be managed by an outside, independent service. An -admin distributing private keys, a user store like Keystone or Google Accounts, -even a file with a list of usernames and passwords. In this regard, _Kubernetes -does not have objects which represent normal user accounts._ Normal users -cannot be added to a cluster through an API call. +It is assumed that a cluster-independent service manages normal users in the following ways: + +- an administrator distributing private keys +- a user store like Keystone or Google Accounts +- a file with a list of usernames and passwords + +In this regard, _Kubernetes does not have objects which represent normal user +accounts._ Normal users cannot be added to a cluster through an API call. + +Even though normal user cannot be added via an API call, but any user that +presents a valid certificate signed by the cluster’s certificate authority +(CA) is considered authenticated. In this configuration, Kubernetes determines +the username from the common name field in the ‘subject’ of the cert (e.g., +“/CN=bob”). From there, the role based access control (RBAC) sub-system would +determine whether the user is authorized to perform a specific operation on a +resource. For more details, refer to the normal users topic in +[certificate request](/docs/reference/access-authn-authz/certificate-signing-requests/#normal-user) +for more details about this. In contrast, service accounts are users managed by the Kubernetes API. They are bound to specific namespaces, and created automatically by the API server or @@ -47,7 +60,7 @@ with the request: * Username: a string which identifies the end user. Common values might be `kube-admin` or `jane@example.com`. * UID: a string which identifies the end user and attempts to be more consistent and unique than username. -* Groups: a set of strings which associate users with a set of commonly grouped users. +* Groups: a set of strings, each of which indicates the user's membership in a named logical collection of users. Common values might be `system:masters` or `devops-team`. * Extra fields: a map of strings to list of strings which holds additional information authorizers may find useful. All values are opaque to the authentication system and only hold significance @@ -333,8 +346,12 @@ wish to utilize multiple OAuth clients should explore providers which support th tokens on behalf of another. Kubernetes does not provide an OpenID Connect Identity Provider. -You can use an existing public OpenID Connect Identity Provider (such as Google, or [others](http://connect2id.com/products/nimbus-oauth-openid-connect-sdk/openid-connect-providers)). -Or, you can run your own Identity Provider, such as CoreOS [dex](https://github.com/coreos/dex), [Keycloak](https://github.com/keycloak/keycloak), CloudFoundry [UAA](https://github.com/cloudfoundry/uaa), or Tremolo Security's [OpenUnison](https://github.com/tremolosecurity/openunison). +You can use an existing public OpenID Connect Identity Provider (such as Google, or +[others](https://connect2id.com/products/nimbus-oauth-openid-connect-sdk/openid-connect-providers)). +Or, you can run your own Identity Provider, such as CoreOS [dex](https://github.com/coreos/dex), +[Keycloak](https://github.com/keycloak/keycloak), +CloudFoundry [UAA](https://github.com/cloudfoundry/uaa), or +Tremolo Security's [OpenUnison](https://github.com/tremolosecurity/openunison). For an identity provider to work with Kubernetes it must: @@ -418,7 +435,7 @@ Webhook authentication is a hook for verifying bearer tokens. * `--authentication-token-webhook-config-file` a configuration file describing how to access the remote webhook service. * `--authentication-token-webhook-cache-ttl` how long to cache authentication decisions. Defaults to two minutes. -The configuration file uses the [kubeconfig](/docs/concepts/cluster-administration/authenticate-across-clusters-kubeconfig/) +The configuration file uses the [kubeconfig](/docs/concepts/configuration/organize-cluster-access-kubeconfig/) file format. Within the file, `clusters` refers to the remote service and `users` refers to the API server webhook. An example would be: diff --git a/content/en/docs/reference/access-authn-authz/authorization.md b/content/en/docs/reference/access-authn-authz/authorization.md index 74c433b8ee..db668f818a 100644 --- a/content/en/docs/reference/access-authn-authz/authorization.md +++ b/content/en/docs/reference/access-authn-authz/authorization.md @@ -138,8 +138,6 @@ field of the returned object is the result of the query. ```bash kubectl create -f - -o yaml << EOF -``` -``` apiVersion: authorization.k8s.io/v1 kind: SelfSubjectAccessReview spec: @@ -149,7 +147,10 @@ spec: verb: create namespace: dev EOF +``` +The generated `SelfSubjectAccessReview` is: +``` apiVersion: authorization.k8s.io/v1 kind: SelfSubjectAccessReview metadata: diff --git a/content/en/docs/reference/access-authn-authz/certificate-signing-requests.md b/content/en/docs/reference/access-authn-authz/certificate-signing-requests.md index fea62e545e..f208bfb770 100644 --- a/content/en/docs/reference/access-authn-authz/certificate-signing-requests.md +++ b/content/en/docs/reference/access-authn-authz/certificate-signing-requests.md @@ -48,7 +48,7 @@ The CertificateSigningRequest `status.certificate` field is empty until the sign Once the `status.certificate` field has been populated, the request has been completed and clients can now fetch the signed certificate PEM data from the CertificateSigningRequest resource. -Signers can instead deny certificate signing if the approval conditions are not met. +The signers can instead deny certificate signing if the approval conditions are not met. In order to reduce the number of old CertificateSigningRequest resources left in a cluster, a garbage collection controller runs periodically. The garbage collection removes CertificateSigningRequests that have not changed @@ -67,10 +67,10 @@ This includes: 1. **Permitted subjects**: any restrictions on and behavior when a disallowed subject is requested. 1. **Permitted x509 extensions**: including IP subjectAltNames, DNS subjectAltNames, Email subjectAltNames, URI subjectAltNames etc, and behavior when a disallowed extension is requested. 1. **Permitted key usages / extended key usages**: any restrictions on and behavior when usages different than the signer-determined usages are specified in the CSR. -1. **Expiration/certificate lifetime**: whether it is fixed by the signer, configurable by the admin, determined by the CSR object etc and behavior if an expiration different than the signer-determined expiration is specified in the CSR. +1. **Expiration/certificate lifetime**: whether it is fixed by the signer, configurable by the admin, determined by the CSR object etc and the behavior when an expiration is different than the signer-determined expiration that is specified in the CSR. 1. **CA bit allowed/disallowed**: and behavior if a CSR contains a request a for a CA certificate when the signer does not permit it. -Commonly, the `status.certificate` field contains a single PEM-encoded X.509 certificate once the CSR is approved and the certificate is issued. Some signers store multiple certificates into the `status.certificate` field. In that case, the documentation for the signer should specify the meaning of additional certificates; for example, this might be certificate plus intermediates to be presented during TLS handshakes. +Commonly, the `status.certificate` field contains a single PEM-encoded X.509 certificate once the CSR is approved and the certificate is issued. Some signers store multiple certificates into the `status.certificate` field. In that case, the documentation for the signer should specify the meaning of additional certificates; for example, this might be the certificate plus intermediates to be presented during TLS handshakes. ### Kubernetes signers @@ -88,19 +88,18 @@ Kubernetes provides built-in signers that each have a well-known `signerName`: 1. `kubernetes.io/kube-apiserver-client-kubelet`: signs client certificates that will be honored as client-certs by the kube-apiserver. May be auto-approved by {{< glossary_tooltip term_id="kube-controller-manager" >}}. - 1. Trust distribution: signed certificates must be honored as client-certificates by the kube-apiserver. The CA bundle + 1. Trust distribution: signed certificates must be honored as client-certificates by the kube-apiserver. The CA bundle is not distributed by any other means. 1. Permitted subjects - organizations are exactly `[]string{"system:nodes"}`, common name starts with `"system:node:"` - 1. Permitted x509 extensions - honors key usage extensions, forbids subjectAltName extensions, drops other extensions. + 1. Permitted x509 extensions - honors key usage extensions, forbids subjectAltName extensions and drops other extensions. 1. Permitted key usages - exactly `[]string{"key encipherment", "digital signature", "client auth"}` - 1. Expiration/certificate lifetime - minimum of CSR signer or request. Sanity of the time is the concern of the signer. + 1. Expiration/certificate lifetime - minimum of CSR signer or request. The signer is responsible for checking that the certificate lifetime is valid and permissible. 1. CA bit allowed/disallowed - not allowed. 1. `kubernetes.io/kubelet-serving`: signs serving certificates that are honored as a valid kubelet serving certificate by the kube-apiserver, but has no other guarantees. Never auto-approved by {{< glossary_tooltip term_id="kube-controller-manager" >}}. - 1. Trust distribution: signed certificates must be honored by the kube-apiserver as valid to terminate connections to a kubelet. - The CA bundle is not distributed by any other means. + 1. Trust distribution: signed certificates must be honored by the kube-apiserver as valid to terminate connections to a kubelet. The CA bundle is not distributed by any other means. 1. Permitted subjects - organizations are exactly `[]string{"system:nodes"}`, common name starts with `"system:node:"` 1. Permitted x509 extensions - honors key usage and DNSName/IPAddress subjectAltName extensions, forbids EmailAddress and URI subjectAltName extensions, drops other extensions. At least one DNS or IP subjectAltName must be present. 1. Permitted key usages - exactly `[]string{"key encipherment", "digital signature", "server auth"}` @@ -108,13 +107,13 @@ Kubernetes provides built-in signers that each have a well-known `signerName`: 1. CA bit allowed/disallowed - not allowed. 1. `kubernetes.io/legacy-unknown`: has no guarantees for trust at all. Some distributions may honor these as client - certs, but that behavior is not standard Kubernetes behavior. + certs, but that behavior is non-standard Kubernetes behavior. Never auto-approved by {{< glossary_tooltip term_id="kube-controller-manager" >}}. 1. Trust distribution: None. There is no standard trust or distribution for this signer in a Kubernetes cluster. 1. Permitted subjects - any 1. Permitted x509 extensions - honors subjectAltName and key usage extensions and discards other extensions. 1. Permitted key usages - any - 1. Expiration/certificate lifetime - minimum of CSR signer or request. Sanity of the time is the concern of the signer. + 1. Expiration/certificate lifetime - minimum of CSR signer or request. The signer is responsible for checking that the certificate lifetime is valid and permissible. 1. CA bit allowed/disallowed - not allowed. {{< note >}} @@ -226,6 +225,101 @@ rules: - sign ``` +## Normal User + +There are a few steps are required in order to get normal user to be able to authenticate and invoke API. First, this user must have certificate issued by the Kubernetes Cluster, and then present that Certificate into the API call as the Certificate Header, or through the kubectl. + +### Create Private Key + +The following scripts show how to generate PKI private key and CSR. It is important to set CN and O attribute of the CSR. CN is the name of the user and O is the group that this user will belong to. You can refer to [RBAC](/docs/reference/access-authn-authz/rbac/) for standard groups. + +``` +openssl genrsa -out john.key 2048 +openssl req -new -key john.key -out john.csr +``` + +### Create Certificate Request Kubernetes Object + +Create a CertificateSigningRequest and submit it to a Kubernetes Cluster via kubectl. Below is a script to generate the CertificateSigningRequest. + +``` +cat <<EOF | kubectl apply -f - +apiVersion: certificates.k8s.io/v1beta1 +kind: CertificateSigningRequest +metadata: + name: john +spec: + groups: + - system:authenticated + request: LS0tLS1CRUdJTiBDRVJUSUZJQ0FURSBSRVFVRVNULS0tLS0KTUlJQ1ZqQ0NBVDRDQVFBd0VURVBNQTBHQTFVRUF3d0dZVzVuWld4aE1JSUJJakFOQmdrcWhraUc5dzBCQVFFRgpBQU9DQVE4QU1JSUJDZ0tDQVFFQTByczhJTHRHdTYxakx2dHhWTTJSVlRWMDNHWlJTWWw0dWluVWo4RElaWjBOCnR2MUZtRVFSd3VoaUZsOFEzcWl0Qm0wMUFSMkNJVXBGd2ZzSjZ4MXF3ckJzVkhZbGlBNVhwRVpZM3ExcGswSDQKM3Z3aGJlK1o2MVNrVHF5SVBYUUwrTWM5T1Nsbm0xb0R2N0NtSkZNMUlMRVI3QTVGZnZKOEdFRjJ6dHBoaUlFMwpub1dtdHNZb3JuT2wzc2lHQ2ZGZzR4Zmd4eW8ybmlneFNVekl1bXNnVm9PM2ttT0x1RVF6cXpkakJ3TFJXbWlECklmMXBMWnoyalVnald4UkhCM1gyWnVVV1d1T09PZnpXM01LaE8ybHEvZi9DdS8wYk83c0x0MCt3U2ZMSU91TFcKcW90blZtRmxMMytqTy82WDNDKzBERHk5aUtwbXJjVDBnWGZLemE1dHJRSURBUUFCb0FBd0RRWUpLb1pJaHZjTgpBUUVMQlFBRGdnRUJBR05WdmVIOGR4ZzNvK21VeVRkbmFjVmQ1N24zSkExdnZEU1JWREkyQTZ1eXN3ZFp1L1BVCkkwZXpZWFV0RVNnSk1IRmQycVVNMjNuNVJsSXJ3R0xuUXFISUh5VStWWHhsdnZsRnpNOVpEWllSTmU3QlJvYXgKQVlEdUI5STZXT3FYbkFvczFqRmxNUG5NbFpqdU5kSGxpT1BjTU1oNndLaTZzZFhpVStHYTJ2RUVLY01jSVUyRgpvU2djUWdMYTk0aEpacGk3ZnNMdm1OQUxoT045UHdNMGM1dVJVejV4T0dGMUtCbWRSeEgvbUNOS2JKYjFRQm1HCkkwYitEUEdaTktXTU0xMzhIQXdoV0tkNjVoVHdYOWl4V3ZHMkh4TG1WQzg0L1BHT0tWQW9FNkpsYWFHdTlQVmkKdjlOSjVaZlZrcXdCd0hKbzZXdk9xVlA3SVFjZmg3d0drWm89Ci0tLS0tRU5EIENFUlRJRklDQVRFIFJFUVVFU1QtLS0tLQo= + usages: + - client auth +EOF +``` + +Some points to note: + +- usage has to be 'client auth' +- request is the base64 encoded value of the CSR file content. You can use this command to get that ```cat john.csr | base64 | tr -d "\n"``` + +### Approve Certificate Request + +Use kubeadmin to create a CSR and approve it. + +Get the list of CSRs +``` +kubectl get csr +``` + +Approve the CSR +``` +kubectl certificate approve john +``` + +### Get the Certificate + +Retrieve the Certificate from the CSR. + +``` +kubectl get csr/john -o yaml +``` + +The Certificate value is in Base64-encoded format under status.certificate. + +### Create Role and Role Binding + +You get the Certificate already. Now it is time to define the Role and Role Binding for this user to access Kubernetes Cluster resources. + +This is a sample script to create role for this new user +``` +kubectl create role developer --verb=create --verb=get --verb=list --verb=update --verb=delete --resource=pods +``` + +This is a sample script to create role binding for this new user +``` +kubectl create rolebinding developer-binding-john --role=developer --user=john +``` + +### Add to KubeConfig + +The last step is to add this user into the KubeConfig. We assume the key and crt files are located here "/home/vagrant/work/". + +First, we need to add new credentials +``` +kubectl config set-credentials john --client-key=/home/vagrant/work/john.key --client-certificate=/home/vagrant/work/john.crt --embed-certs=true + +``` + +Then, we need to add the context +``` +kubectl config set-context john --cluster=kubernetes --user=john +``` + +To test it, change kubecontext to john +``` +kubectl config use-context john +``` + ## Approval & rejection ### Control plane automated approval {#approval-rejection-control-plane} @@ -322,10 +416,8 @@ signed certificate. ## {{% heading "whatsnext" %}} -* Read [Manage TLS Certificates in a Cluster](https://kubernetes.io/docs/tasks/tls/managing-tls-in-a-cluster/) +* Read [Manage TLS Certificates in a Cluster](/docs/tasks/tls/managing-tls-in-a-cluster/) * View the source code for the kube-controller-manager built in [signer](https://github.com/kubernetes/kubernetes/blob/32ec6c212ec9415f604ffc1f4c1f29b782968ff1/pkg/controller/certificates/signer/cfssl_signer.go) * View the source code for the kube-controller-manager built in [approver](https://github.com/kubernetes/kubernetes/blob/32ec6c212ec9415f604ffc1f4c1f29b782968ff1/pkg/controller/certificates/approver/sarapprove.go) * For details of X.509 itself, refer to [RFC 5280](https://tools.ietf.org/html/rfc5280#section-3.1) section 3.1 * For information on the syntax of PKCS#10 certificate signing requests, refer to [RFC 2986](https://tools.ietf.org/html/rfc2986) - - diff --git a/content/en/docs/reference/access-authn-authz/extensible-admission-controllers.md b/content/en/docs/reference/access-authn-authz/extensible-admission-controllers.md index 718c9d1147..4700810cbd 100644 --- a/content/en/docs/reference/access-authn-authz/extensible-admission-controllers.md +++ b/content/en/docs/reference/access-authn-authz/extensible-admission-controllers.md @@ -589,7 +589,7 @@ Example of a response to forbid a request, customizing the HTTP status code and When allowing a request, a mutating admission webhook may optionally modify the incoming object as well. This is done using the `patch` and `patchType` fields in the response. The only currently supported `patchType` is `JSONPatch`. -See [JSON patch](http://jsonpatch.com/) documentation for more details. +See [JSON patch](https://jsonpatch.com/) documentation for more details. For `patchType: JSONPatch`, the `patch` field contains a base64-encoded array of JSON patch operations. As an example, a single patch operation that would set `spec.replicas` would be `[{"op": "add", "path": "/spec/replicas", "value": 3}]` @@ -949,7 +949,7 @@ See https://kubernetes.io/docs/concepts/overview/working-with-objects/labels for ### Matching requests: matchPolicy API servers can make objects available via multiple API groups or versions. -For example, the Kubernetes API server allows creating and modifying `Deployment` objects +For example, the Kubernetes API server may allow creating and modifying `Deployment` objects via `extensions/v1beta1`, `apps/v1beta1`, `apps/v1beta2`, and `apps/v1` APIs. For example, if a webhook only specified a rule for some API groups/versions (like `apiGroups:["apps"], apiVersions:["v1","v1beta1"]`), diff --git a/content/en/docs/reference/access-authn-authz/rbac.md b/content/en/docs/reference/access-authn-authz/rbac.md index 20b1224e59..2be833826c 100644 --- a/content/en/docs/reference/access-authn-authz/rbac.md +++ b/content/en/docs/reference/access-authn-authz/rbac.md @@ -606,12 +606,15 @@ either do not manually edit the role, or disable auto-reconciliation. <table> <caption>Kubernetes RBAC API discovery roles</caption> -<colgroup><col width="25%" /><col width="25%" /><col /></colgroup> +<colgroup><col style="width: 25%;" /><col style="width: 25%;" /><col /></colgroup> +<thead> <tr> <th>Default ClusterRole</th> <th>Default ClusterRoleBinding</th> <th>Description</th> </tr> +</thead> +<tbody> <tr> <td><b>system:basic-user</b></td> <td><b>system:authenticated</b> group</td> @@ -627,6 +630,7 @@ either do not manually edit the role, or disable auto-reconciliation. <td><b>system:authenticated</b> and <b>system:unauthenticated</b> groups</td> <td>Allows read-only access to non-sensitive information about the cluster. Introduced in Kubernetes v1.14.</td> </tr> +</tbody> </table> ### User-facing roles @@ -649,12 +653,15 @@ metadata: ``` <table> -<colgroup><col width="25%"><col width="25%"><col></colgroup> +<colgroup><col style="width: 25%;" /><col style="width: 25%;" /><col /></colgroup> +<thead> <tr> <th>Default ClusterRole</th> <th>Default ClusterRoleBinding</th> <th>Description</th> </tr> +</thead> +<tbody> <tr> <td><b>cluster-admin</b></td> <td><b>system:masters</b> group</td> @@ -691,17 +698,21 @@ the contents of Secrets enables access to ServiceAccount credentials in the namespace, which would allow API access as any ServiceAccount in the namespace (a form of privilege escalation).</td> </tr> +</tbody> </table> ### Core component roles <table> -<colgroup><col width="25%"><col width="25%"><col></colgroup> +<colgroup><col style="width: 25%;" /><col style="width: 25%;" /><col /></colgroup> +<thead> <tr> <th>Default ClusterRole</th> <th>Default ClusterRoleBinding</th> <th>Description</th> </tr> +</thead> +<tbody> <tr> <td><b>system:kube-scheduler</b></td> <td><b>system:kube-scheduler</b> user</td> @@ -733,17 +744,21 @@ The <tt>system:node</tt> role only exists for compatibility with Kubernetes clus <td><b>system:kube-proxy</b> user</td> <td>Allows access to the resources required by the {{< glossary_tooltip term_id="kube-proxy" text="kube-proxy" >}} component.</td> </tr> +</tbody> </table> ### Other component roles <table> -<colgroup><col width="25%"><col width="25%"><col></colgroup> +<colgroup><col style="width: 25%;" /><col style="width: 25%;" /><col /></colgroup> +<thead> <tr> <th>Default ClusterRole</th> <th>Default ClusterRoleBinding</th> <th>Description</th> </tr> +</thead> +<tbody> <tr> <td><b>system:auth-delegator</b></td> <td>None</td> @@ -786,6 +801,7 @@ This is commonly used by add-on API servers for unified authentication and autho <td>None</td> <td>Allows access to the resources required by most <a href="/docs/concepts/storage/persistent-volumes/#provisioner">dynamic volume provisioners</a>.</td> </tr> +<tbody> </table> ### Roles for built-in controllers {#controller-roles} diff --git a/content/en/docs/reference/access-authn-authz/service-accounts-admin.md b/content/en/docs/reference/access-authn-authz/service-accounts-admin.md index 6d2cf76573..df653a206f 100644 --- a/content/en/docs/reference/access-authn-authz/service-accounts-admin.md +++ b/content/en/docs/reference/access-authn-authz/service-accounts-admin.md @@ -10,8 +10,8 @@ weight: 50 --- <!-- overview --> -This is a Cluster Administrator guide to service accounts. It assumes knowledge of -the [User Guide to Service Accounts](/docs/user-guide/service-accounts). +This is a Cluster Administrator guide to service accounts. You should be familiar with +[configuring Kubernetes service accounts](/docs/tasks/configure-pod-container/configure-service-account/). Support for authorization and user accounts is planned but incomplete. Sometimes incomplete features are referred to in order to better describe service accounts. diff --git a/content/en/docs/reference/command-line-tools-reference/_index.md b/content/en/docs/reference/command-line-tools-reference/_index.md index 5bcfe659c0..6698fe66c0 100644 --- a/content/en/docs/reference/command-line-tools-reference/_index.md +++ b/content/en/docs/reference/command-line-tools-reference/_index.md @@ -1,5 +1,4 @@ --- title: Command line tools reference weight: 60 -toc-hide: true --- diff --git a/content/en/docs/reference/command-line-tools-reference/feature-gates.md b/content/en/docs/reference/command-line-tools-reference/feature-gates.md index 78784eace7..6d6d870262 100644 --- a/content/en/docs/reference/command-line-tools-reference/feature-gates.md +++ b/content/en/docs/reference/command-line-tools-reference/feature-gates.md @@ -129,12 +129,14 @@ different Kubernetes components. | `RuntimeClass` | `false` | Alpha | 1.12 | 1.13 | | `RuntimeClass` | `true` | Beta | 1.14 | | | `SCTPSupport` | `false` | Alpha | 1.12 | | -| `ServiceAppProtocol` | `false` | Alpha | 1.18 | | | `ServerSideApply` | `false` | Alpha | 1.14 | 1.15 | | `ServerSideApply` | `true` | Beta | 1.16 | | +| `ServiceAccountIssuerDiscovery` | `false` | Alpha | 1.18 | | +| `ServiceAppProtocol` | `false` | Alpha | 1.18 | | | `ServiceNodeExclusion` | `false` | Alpha | 1.8 | | | `ServiceTopology` | `false` | Alpha | 1.17 | | -| `StartupProbe` | `false` | Alpha | 1.16 | | +| `StartupProbe` | `false` | Alpha | 1.16 | 1.17 | +| `StartupProbe` | `true` | Beta | 1.18 | | | `StorageVersionHash` | `false` | Alpha | 1.14 | 1.14 | | `StorageVersionHash` | `true` | Beta | 1.15 | | | `StreamingProxyRedirects` | `false` | Beta | 1.5 | 1.5 | @@ -387,11 +389,11 @@ Each feature gate is designed for enabling/disabling a specific feature: - `CustomResourceDefaulting`: Enable CRD support for default values in OpenAPI v3 validation schemas. - `CustomResourcePublishOpenAPI`: Enables publishing of CRD OpenAPI specs. - `CustomResourceSubresources`: Enable `/status` and `/scale` subresources - on resources created from [CustomResourceDefinition](/docs/concepts/api-extension/custom-resources/). + on resources created from [CustomResourceDefinition](/docs/concepts/extend-kubernetes/api-extension/custom-resources/). - `CustomResourceValidation`: Enable schema based validation on resources created from - [CustomResourceDefinition](/docs/concepts/api-extension/custom-resources/). + [CustomResourceDefinition](/docs/concepts/extend-kubernetes/api-extension/custom-resources/). - `CustomResourceWebhookConversion`: Enable webhook-based conversion - on resources created from [CustomResourceDefinition](/docs/concepts/api-extension/custom-resources/). + on resources created from [CustomResourceDefinition](/docs/concepts/extend-kubernetes/api-extension/custom-resources/). troubleshoot a running Pod. - `DevicePlugins`: Enable the [device-plugins](/docs/concepts/cluster-administration/device-plugins/) based resource provisioning on nodes. @@ -432,10 +434,13 @@ Each feature gate is designed for enabling/disabling a specific feature: - `KubeletPluginsWatcher`: Enable probe-based plugin watcher utility to enable kubelet to discover plugins such as [CSI volume drivers](/docs/concepts/storage/volumes/#csi). - `KubeletPodResources`: Enable the kubelet's pod resources grpc endpoint. - See [Support Device Monitoring](https://git.k8s.io/community/keps/sig-node/compute-device-assignment.md) for more details. + See [Support Device Monitoring](https://github.com/kubernetes/enhancements/blob/master/keps/sig-node/compute-device-assignment.md) for more details. - `LegacyNodeRoleBehavior`: When disabled, legacy behavior in service load balancers and node disruption will ignore the `node-role.kubernetes.io/master` label in favor of the feature-specific labels. -- `LocalStorageCapacityIsolation`: Enable the consumption of [local ephemeral storage](/docs/concepts/configuration/manage-compute-resources-container/) and also the `sizeLimit` property of an [emptyDir volume](/docs/concepts/storage/volumes/#emptydir). -- `LocalStorageCapacityIsolationFSQuotaMonitoring`: When `LocalStorageCapacityIsolation` is enabled for [local ephemeral storage](/docs/concepts/configuration/manage-compute-resources-container/) and the backing filesystem for [emptyDir volumes](/docs/concepts/storage/volumes/#emptydir) supports project quotas and they are enabled, use project quotas to monitor [emptyDir volume](/docs/concepts/storage/volumes/#emptydir) storage consumption rather than filesystem walk for better performance and accuracy. +- `LocalStorageCapacityIsolation`: Enable the consumption of [local ephemeral storage](/docs/concepts/configuration/manage-resources-containers/) and also the `sizeLimit` property of an [emptyDir volume](/docs/concepts/storage/volumes/#emptydir). +- `LocalStorageCapacityIsolationFSQuotaMonitoring`: When `LocalStorageCapacityIsolation` is enabled for + [local ephemeral storage](/docs/concepts/configuration/manage-resources-containers/) and the backing filesystem for + [emptyDir volumes](/docs/concepts/storage/volumes/#emptydir) supports project quotas and they are enabled, use project quotas to monitor + [emptyDir volume](/docs/concepts/storage/volumes/#emptydir) storage consumption rather than filesystem walk for better performance and accuracy. - `MountContainers`: Enable using utility containers on host as the volume mounter. - `MountPropagation`: Enable sharing volume mounted by one container to other containers or pods. For more details, please see [mount propagation](/docs/concepts/storage/volumes/#mount-propagation). @@ -472,11 +477,12 @@ Each feature gate is designed for enabling/disabling a specific feature: - `ScheduleDaemonSetPods`: Enable DaemonSet Pods to be scheduled by the default scheduler instead of the DaemonSet controller. - `SCTPSupport`: Enables the usage of SCTP as `protocol` value in `Service`, `Endpoint`, `NetworkPolicy` and `Pod` definitions - `ServerSideApply`: Enables the [Sever Side Apply (SSA)](/docs/reference/using-api/api-concepts/#server-side-apply) path at the API Server. +- `ServiceAccountIssuerDiscovery`: Enable OIDC discovery endpoints (issuer and JWKS URLs) for the service account issuer in the API server. See [Configure Service Accounts for Pods](/docs/tasks/configure-pod-container/configure-service-account/#service-account-issuer-discovery) for more details. - `ServiceAppProtocol`: Enables the `AppProtocol` field on Services and Endpoints. - `ServiceLoadBalancerFinalizer`: Enable finalizer protection for Service load balancers. - `ServiceNodeExclusion`: Enable the exclusion of nodes from load balancers created by a cloud provider. A node is eligible for exclusion if labelled with "`alpha.service-controller.kubernetes.io/exclude-balancer`" key or `node.kubernetes.io/exclude-from-external-load-balancers`. -- `ServiceTopology`: Enable service to route traffic based upon the Node topology of the cluster. See [ServiceTopology](https://kubernetes.io/docs/concepts/services-networking/service-topology/) for more details. +- `ServiceTopology`: Enable service to route traffic based upon the Node topology of the cluster. See [ServiceTopology](/docs/concepts/services-networking/service-topology/) for more details. - `StartupProbe`: Enable the [startup](/docs/concepts/workloads/pods/pod-lifecycle/#when-should-you-use-a-startup-probe) probe in the kubelet. - `StorageObjectInUseProtection`: Postpone the deletion of PersistentVolume or PersistentVolumeClaim objects if they are still being used. @@ -516,4 +522,3 @@ Each feature gate is designed for enabling/disabling a specific feature: * The [deprecation policy](/docs/reference/using-api/deprecation-policy/) for Kubernetes explains the project's approach to removing features and components. - diff --git a/content/en/docs/reference/command-line-tools-reference/kube-scheduler.md b/content/en/docs/reference/command-line-tools-reference/kube-scheduler.md index d510610140..4a788b1ab9 100644 --- a/content/en/docs/reference/command-line-tools-reference/kube-scheduler.md +++ b/content/en/docs/reference/command-line-tools-reference/kube-scheduler.md @@ -14,7 +14,7 @@ and capacity. The scheduler needs to take into account individual and collective resource requirements, quality of service requirements, hardware/software/policy constraints, affinity and anti-affinity specifications, data locality, inter-workload interference, deadlines, and so on. Workload-specific requirements will be exposed -through the API as necessary. See [scheduling](https://kubernetes.io/docs/concepts/scheduling-eviction/) +through the API as necessary. See [scheduling](/docs/concepts/scheduling-eviction/) for more information about scheduling and the kube-scheduler component. ``` @@ -511,8 +511,3 @@ kube-scheduler [flags] </tbody> </table> - - - - - diff --git a/content/en/docs/reference/glossary/cri-o.md b/content/en/docs/reference/glossary/cri-o.md index a2c61e6984..d94e0eaf15 100644 --- a/content/en/docs/reference/glossary/cri-o.md +++ b/content/en/docs/reference/glossary/cri-o.md @@ -17,7 +17,7 @@ A tool that lets you use OCI container runtimes with Kubernetes CRI. CRI-O is an implementation of the {{< glossary_tooltip term_id="cri" >}} to enable using {{< glossary_tooltip text="container" term_id="container" >}} runtimes that are compatible with the Open Container Initiative (OCI) -[runtime spec](http://www.github.com/opencontainers/runtime-spec). +[runtime spec](https://www.github.com/opencontainers/runtime-spec). Deploying CRI-O allows Kubernetes to use any OCI-compliant runtime as the container runtime for running {{< glossary_tooltip text="Pods" term_id="pod" >}}, and to fetch diff --git a/content/en/docs/reference/glossary/endpoint.md b/content/en/docs/reference/glossary/endpoint.md new file mode 100644 index 0000000000..3934faa18a --- /dev/null +++ b/content/en/docs/reference/glossary/endpoint.md @@ -0,0 +1,17 @@ +--- +title: Endpoints +id: endpoints +date: 2020-04-23 +full_link: +short_description: > + Endpoints track the IP addresses of Pods with matching Service selectors. + +aka: +tags: +- networking +--- + Endpoints track the IP addresses of Pods with matching {{< glossary_tooltip text="selectors" term_id="selector" >}}. + +<!--more--> +Endpoints can be configured manually for {{< glossary_tooltip text="Services" term_id="service" >}} without selectors specified. +The {{< glossary_tooltip text="EndpointSlice" term_id="endpoint-slice" >}} resource provides a scalable and extensible alternative to Endpoints. diff --git a/content/en/docs/reference/glossary/managed-service.md b/content/en/docs/reference/glossary/managed-service.md index 61ac76aabd..186588252c 100755 --- a/content/en/docs/reference/glossary/managed-service.md +++ b/content/en/docs/reference/glossary/managed-service.md @@ -14,4 +14,9 @@ tags: <!--more--> -Some examples of Managed Services are AWS EC2, Azure SQL Database, and GCP Pub/Sub, but they can be any software offering that can be used by an application. [Service Catalog](/docs/concepts/service-catalog/) provides a way to list, provision, and bind with Managed Services offered by {{< glossary_tooltip text="Service Brokers" term_id="service-broker" >}}. +Some examples of Managed Services are AWS EC2, Azure SQL Database, and +GCP Pub/Sub, but they can be any software offering that can be used by an application. +[Service Catalog](/docs/concepts/extend-kubernetes/service-catalog/) provides a way to +list, provision, and bind with Managed Services offered by +{{< glossary_tooltip text="Service Brokers" term_id="service-broker" >}}. + diff --git a/content/en/docs/reference/glossary/platform-developer.md b/content/en/docs/reference/glossary/platform-developer.md index ed9a5fa1b7..ed961c27f2 100755 --- a/content/en/docs/reference/glossary/platform-developer.md +++ b/content/en/docs/reference/glossary/platform-developer.md @@ -14,5 +14,10 @@ tags: <!--more--> -A platform developer may, for example, use [Custom Resources](/docs/concepts/api-extension/custom-resources/) or [Extend the Kubernetes API with the aggregation layer](/docs/concepts/api-extension/apiserver-aggregation/) to add functionality to their instance of Kubernetes, specifically for their application. Some Platform Developers are also {{< glossary_tooltip text="contributors" term_id="contributor" >}} and develop extensions which are contributed to the Kubernetes community. Others develop closed-source commercial or site-specific extensions. +A platform developer may, for example, use [Custom Resources](/docs/concepts/extend-Kubernetes/api-extension/custom-resources/) or +[Extend the Kubernetes API with the aggregation layer](/docs/concepts/extend-Kubernetes/api-extension/apiserver-aggregation/) +to add functionality to their instance of Kubernetes, specifically for their application. +Some Platform Developers are also {{< glossary_tooltip text="contributors" term_id="contributor" >}} and +develop extensions which are contributed to the Kubernetes community. +Others develop closed-source commercial or site-specific extensions. diff --git a/content/en/docs/reference/glossary/pod.md b/content/en/docs/reference/glossary/pod.md index f14393072c..b551dead19 100755 --- a/content/en/docs/reference/glossary/pod.md +++ b/content/en/docs/reference/glossary/pod.md @@ -2,7 +2,7 @@ title: Pod id: pod date: 2018-04-12 -full_link: /docs/concepts/workloads/pods/pod-overview/ +full_link: /docs/concepts/workloads/pods/ short_description: > A Pod represents a set of running containers in your cluster. diff --git a/content/en/docs/reference/glossary/service-broker.md b/content/en/docs/reference/glossary/service-broker.md index 84fc8367a1..d35ea3d688 100755 --- a/content/en/docs/reference/glossary/service-broker.md +++ b/content/en/docs/reference/glossary/service-broker.md @@ -14,4 +14,9 @@ tags: <!--more--> -{{< glossary_tooltip text="Service Brokers" term_id="service-broker" >}} implement the [Open Service Broker API spec](https://github.com/openservicebrokerapi/servicebroker/blob/v2.13/spec.md) and provide a standard interface for applications to use their Managed Services. [Service Catalog](/docs/concepts/service-catalog/) provides a way to list, provision, and bind with Managed Services offered by Service Brokers. +{{< glossary_tooltip text="Service Brokers" term_id="service-broker" >}} implement the +[Open Service Broker API spec](https://github.com/openservicebrokerapi/servicebroker/blob/v2.13/spec.md) +and provide a standard interface for applications to use their Managed Services. +[Service Catalog](/docs/concepts/extend-kubernetes/service-catalog/) provides a way to +list, provision, and bind with Managed Services offered by Service Brokers. + diff --git a/content/en/docs/reference/glossary/volume.md b/content/en/docs/reference/glossary/volume.md index 2076378bb3..22cebca917 100755 --- a/content/en/docs/reference/glossary/volume.md +++ b/content/en/docs/reference/glossary/volume.md @@ -6,15 +6,15 @@ full_link: /docs/concepts/storage/volumes/ short_description: > A directory containing data, accessible to the containers in a pod. -aka: +aka: tags: - core-object - fundamental --- A directory containing data, accessible to the {{< glossary_tooltip text="containers" term_id="container" >}} in a {{< glossary_tooltip term_id="pod" >}}. -<!--more--> +<!--more--> A Kubernetes volume lives as long as the Pod that encloses it. Consequently, a volume outlives any containers that run within the Pod, and data in the volume is preserved across container restarts. -See [storage](https://kubernetes.io/docs/concepts/storage/) for more information. +See [storage](/docs/concepts/storage/) for more information. diff --git a/content/en/docs/reference/issues-security/_index.md b/content/en/docs/reference/issues-security/_index.md index ec7a38abe1..530e98bf61 100644 --- a/content/en/docs/reference/issues-security/_index.md +++ b/content/en/docs/reference/issues-security/_index.md @@ -1,5 +1,4 @@ --- title: Kubernetes Issues and Security weight: 10 -toc-hide: true --- \ No newline at end of file diff --git a/content/en/docs/reference/issues-security/security.md b/content/en/docs/reference/issues-security/security.md index b9b1ce7c37..2d16e37662 100644 --- a/content/en/docs/reference/issues-security/security.md +++ b/content/en/docs/reference/issues-security/security.md @@ -19,7 +19,7 @@ This page describes Kubernetes security and disclosure information. Join the [kubernetes-security-announce](https://groups.google.com/forum/#!forum/kubernetes-security-announce) group for emails about security and major API announcements. -You can also subscribe to an RSS feed of the above using [this link](https://groups.google.com/forum/feed/kubernetes-announce/msgs/rss_v2_0.xml?num=50). +You can also subscribe to an RSS feed of the above using [this link](https://groups.google.com/forum/feed/kubernetes-security-announce/msgs/rss_v2_0.xml?num=50). ## Report a Vulnerability diff --git a/content/en/docs/reference/kubectl/cheatsheet.md b/content/en/docs/reference/kubectl/cheatsheet.md index 36629d2c29..71f7e6d3f7 100644 --- a/content/en/docs/reference/kubectl/cheatsheet.md +++ b/content/en/docs/reference/kubectl/cheatsheet.md @@ -166,6 +166,10 @@ kubectl get pv --sort-by=.spec.capacity.storage kubectl get pods --selector=app=cassandra -o \ jsonpath='{.items[*].metadata.labels.version}' +# Retrieve the value of a key with dots, e.g. 'ca.crt' +kubectl get configmap myconfig \ + -o jsonpath='{.data.ca\.crt}' + # Get all worker nodes (use a selector to exclude results that have a label # named 'node-role.kubernetes.io/master') kubectl get node --selector='!node-role.kubernetes.io/master' @@ -200,6 +204,13 @@ kubectl get events --sort-by=.metadata.creationTimestamp # Compares the current state of the cluster against the state that the cluster would be in if the manifest was applied. kubectl diff -f ./my-manifest.yaml + +# Produce a period-delimited tree of all keys returned for nodes +# Helpful when locating a key within a complex nested JSON structure +kubectl get nodes -o json | jq -c 'path(..)|[.[]|tostring]|join(".")' + +# Produce a period-delimited tree of all keys returned for pods, etc +kubectl get pods -o json | jq -c 'path(..)|[.[]|tostring]|join(".")' ``` ## Updating Resources diff --git a/content/en/docs/reference/kubectl/docker-cli-to-kubectl.md b/content/en/docs/reference/kubectl/docker-cli-to-kubectl.md index 790ceea4df..b9c5bf9af1 100644 --- a/content/en/docs/reference/kubectl/docker-cli-to-kubectl.md +++ b/content/en/docs/reference/kubectl/docker-cli-to-kubectl.md @@ -73,9 +73,6 @@ kubectl run [-i] [--tty] --attach <name> --image=<image> Unlike `docker run ...`, if you specify `--attach`, then you attach `stdin`, `stdout` and `stderr`. You cannot control which streams are attached (`docker -a ...`). To detach from the container, you can type the escape sequence Ctrl+P followed by Ctrl+Q. -Because the kubectl run command starts a Deployment for the container, the Deployment restarts if you terminate the attached process by using Ctrl+C, unlike `docker run -it`. -To destroy the Deployment and its pods you need to run `kubectl delete deployment <name>`. - ## docker ps To list what is currently running, see [kubectl get](/docs/reference/generated/kubectl/kubectl-commands/#get). @@ -188,7 +185,7 @@ docker exec -ti 55c103fa1296 /bin/sh kubectl: ```shell -kubectl exec -ti nginx-app-5jyvm -- /bin/sh +kubectl exec -ti nginx-app-5jyvm -- /bin/sh # exit ``` diff --git a/content/en/docs/reference/kubectl/overview.md b/content/en/docs/reference/kubectl/overview.md index 66d63c4b93..a9177da9f5 100644 --- a/content/en/docs/reference/kubectl/overview.md +++ b/content/en/docs/reference/kubectl/overview.md @@ -10,11 +10,16 @@ card: --- <!-- overview --> -The kubectl command line tool lets you control Kubernetes clusters. For configuration, `kubectl` looks for a file named `config` in the `$HOME/.kube` directory. You can specify other [kubeconfig](/docs/concepts/configuration/organize-cluster-access-kubeconfig/) files by setting the KUBECONFIG environment variable or by setting the [`--kubeconfig`](/docs/concepts/configuration/organize-cluster-access-kubeconfig/) flag. - -This overview covers `kubectl` syntax, describes the command operations, and provides common examples. For details about each command, including all the supported flags and subcommands, see the [kubectl](/docs/reference/generated/kubectl/kubectl-commands/) reference documentation. For installation instructions see [installing kubectl](/docs/tasks/kubectl/install/). - +The kubectl command line tool lets you control Kubernetes clusters. +For configuration, `kubectl` looks for a file named `config` in the `$HOME/.kube` directory. +You can specify other [kubeconfig](/docs/concepts/configuration/organize-cluster-access-kubeconfig/) +files by setting the KUBECONFIG environment variable or by setting the +[`--kubeconfig`](/docs/concepts/configuration/organize-cluster-access-kubeconfig/) flag. +This overview covers `kubectl` syntax, describes the command operations, and provides common examples. +For details about each command, including all the supported flags and subcommands, see the +[kubectl](/docs/reference/generated/kubectl/kubectl-commands/) reference documentation. +For installation instructions see [installing kubectl](/docs/tasks/tools/install-kubectl/). <!-- body --> @@ -28,9 +33,12 @@ kubectl [command] [TYPE] [NAME] [flags] where `command`, `TYPE`, `NAME`, and `flags` are: -* `command`: Specifies the operation that you want to perform on one or more resources, for example `create`, `get`, `describe`, `delete`. +* `command`: Specifies the operation that you want to perform on one or more resources, +for example `create`, `get`, `describe`, `delete`. -* `TYPE`: Specifies the [resource type](#resource-types). Resource types are case-insensitive and you can specify the singular, plural, or abbreviated forms. For example, the following commands produce the same output: +* `TYPE`: Specifies the [resource type](#resource-types). Resource types are case-insensitive and + you can specify the singular, plural, or abbreviated forms. + For example, the following commands produce the same output: ```shell kubectl get pod pod1 @@ -208,11 +216,13 @@ In this example, the following command outputs the details for a single pod as a kubectl get pod web-pod-13je7 -o yaml ``` -Remember: See the [kubectl](/docs/user-guide/kubectl/) reference documentation for details about which output format is supported by each command. +Remember: See the [kubectl](/docs/reference/kubectl/kubectl/) reference documentation +for details about which output format is supported by each command. #### Custom columns -To define custom columns and output only the details that you want into a table, you can use the `custom-columns` option. You can choose to define the custom columns inline or use a template file: `-o custom-columns=<spec>` or `-o custom-columns-file=<filename>`. +To define custom columns and output only the details that you want into a table, you can use the `custom-columns` option. +You can choose to define the custom columns inline or use a template file: `-o custom-columns=<spec>` or `-o custom-columns-file=<filename>`. ##### Examples @@ -496,12 +506,8 @@ kubectl whoami Current user: plugins-user ``` - - - ## {{% heading "whatsnext" %}} - * Start using the [kubectl](/docs/reference/generated/kubectl/kubectl-commands/) commands. * To find out more about plugins, take a look at the [example cli plugin](https://github.com/kubernetes/sample-cli-plugin). diff --git a/content/en/docs/reference/scheduling/profiles.md b/content/en/docs/reference/scheduling/profiles.md index fe28d10bd1..3cb4eb71b3 100644 --- a/content/en/docs/reference/scheduling/profiles.md +++ b/content/en/docs/reference/scheduling/profiles.md @@ -91,7 +91,7 @@ extension points: - `NodeResourcesFit`: Checks if the node has all the resources that the Pod is requesting. Extension points: `PreFilter`, `Filter`. -- `NodeResourcesBallancedAllocation`: Favors nodes that would obtain a more +- `NodeResourcesBalancedAllocation`: Favors nodes that would obtain a more balanced resource usage if the Pod is scheduled there. Extension points: `Score`. - `NodeResourcesLeastAllocated`: Favors nodes that have a low allocation of diff --git a/content/en/docs/reference/setup-tools/_index.md b/content/en/docs/reference/setup-tools/_index.md index f1c2f4370c..3988d6485e 100644 --- a/content/en/docs/reference/setup-tools/_index.md +++ b/content/en/docs/reference/setup-tools/_index.md @@ -1,5 +1,4 @@ --- title: Setup tools reference weight: 50 -toc-hide: true --- diff --git a/content/en/docs/reference/setup-tools/kubeadm/_index.md b/content/en/docs/reference/setup-tools/kubeadm/_index.md index 6863791207..32c5c6f0a2 100755 --- a/content/en/docs/reference/setup-tools/kubeadm/_index.md +++ b/content/en/docs/reference/setup-tools/kubeadm/_index.md @@ -1,5 +1,30 @@ --- title: "Kubeadm" weight: 10 -toc-hide: true +no_list: true +content_type: concept +card: + name: reference + weight: 40 --- + +<img src="https://raw.githubusercontent.com/kubernetes/kubeadm/master/logos/stacked/color/kubeadm-stacked-color.png" align="right" width="150px">Kubeadm is a tool built to provide `kubeadm init` and `kubeadm join` as best-practice “fast paths” for creating Kubernetes clusters. + +kubeadm performs the actions necessary to get a minimum viable cluster up and running. By design, it cares only about bootstrapping, not about provisioning machines. Likewise, installing various nice-to-have addons, like the Kubernetes Dashboard, monitoring solutions, and cloud-specific addons, is not in scope. + +Instead, we expect higher-level and more tailored tooling to be built on top of kubeadm, and ideally, using kubeadm as the basis of all deployments will make it easier to create conformant clusters. + +## How to install + +To install kubeadm, see the [installation guide](/docs/setup/production-environment/tools/kubeadm/install-kubeadm). + +## {{% heading "whatsnext" %}} + +* [kubeadm init](/docs/reference/setup-tools/kubeadm/kubeadm-init) to bootstrap a Kubernetes control-plane node +* [kubeadm join](/docs/reference/setup-tools/kubeadm/kubeadm-join) to bootstrap a Kubernetes worker node and join it to the cluster +* [kubeadm upgrade](/docs/reference/setup-tools/kubeadm/kubeadm-upgrade) to upgrade a Kubernetes cluster to a newer version +* [kubeadm config](/docs/reference/setup-tools/kubeadm/kubeadm-config) if you initialized your cluster using kubeadm v1.7.x or lower, to configure your cluster for `kubeadm upgrade` +* [kubeadm token](/docs/reference/setup-tools/kubeadm/kubeadm-token) to manage tokens for `kubeadm join` +* [kubeadm reset](/docs/reference/setup-tools/kubeadm/kubeadm-reset) to revert any changes made to this host by `kubeadm init` or `kubeadm join` +* [kubeadm version](/docs/reference/setup-tools/kubeadm/kubeadm-version) to print the kubeadm version +* [kubeadm alpha](/docs/reference/setup-tools/kubeadm/kubeadm-alpha) to preview a set of features made available for gathering feedback from the community diff --git a/content/en/docs/reference/setup-tools/kubeadm/implementation-details.md b/content/en/docs/reference/setup-tools/kubeadm/implementation-details.md index cb42a34df9..6abc42c131 100644 --- a/content/en/docs/reference/setup-tools/kubeadm/implementation-details.md +++ b/content/en/docs/reference/setup-tools/kubeadm/implementation-details.md @@ -15,7 +15,6 @@ However, it might not be obvious _how_ kubeadm does that. This document provides additional details on what happen under the hood, with the aim of sharing knowledge on Kubernetes cluster best practices. - <!-- body --> ## Core design principles @@ -518,6 +517,7 @@ Please note that: - The automatic CSR approval is managed by the csrapprover controller, according with configuration done the `kubeadm init` process ### (optional) Write init kubelet configuration + {{< feature-state for_k8s_version="v1.9" state="alpha" >}} If kubeadm is invoked with `--feature-gates=DynamicKubeletConfig`: @@ -530,5 +530,3 @@ If kubeadm is invoked with `--feature-gates=DynamicKubeletConfig`: Please note that: 1. To make dynamic kubelet configuration work, flag `--dynamic-config-dir=/var/lib/kubelet/config/dynamic` should be specified in `/etc/systemd/system/kubelet.service.d/10-kubeadm.conf` - - diff --git a/content/en/docs/reference/setup-tools/kubeadm/kubeadm-alpha.md b/content/en/docs/reference/setup-tools/kubeadm/kubeadm-alpha.md index c2356ed966..21a6e628a8 100644 --- a/content/en/docs/reference/setup-tools/kubeadm/kubeadm-alpha.md +++ b/content/en/docs/reference/setup-tools/kubeadm/kubeadm-alpha.md @@ -3,8 +3,10 @@ reviewers: - luxas - jbeda title: kubeadm alpha +content_type: concept weight: 90 --- + {{< caution >}} `kubeadm alpha` provides a preview of a set of features made available for gathering feedback from the community. Please try it out and give us feedback! @@ -67,7 +69,6 @@ Use the following command to enable the DynamicKubeletConfiguration feature. {{< tab name="enable-dynamic" include="generated/kubeadm_alpha_kubelet_config_enable-dynamic.md" />}} {{< /tabs >}} - ## kubeadm alpha selfhosting pivot {#cmd-selfhosting} The subcommand `pivot` can be used to convert a static Pod-hosted control plane into a self-hosted one. @@ -79,8 +80,8 @@ The subcommand `pivot` can be used to convert a static Pod-hosted control plane {{< tab name="pivot" include="generated/kubeadm_alpha_selfhosting_pivot.md" />}} {{< /tabs >}} +## {{% heading "whatsnext" %}} -## What's next * [kubeadm init](/docs/reference/setup-tools/kubeadm/kubeadm-init/) to bootstrap a Kubernetes control-plane node * [kubeadm join](/docs/reference/setup-tools/kubeadm/kubeadm-join/) to connect a node to the cluster * [kubeadm reset](/docs/reference/setup-tools/kubeadm/kubeadm-reset/) to revert any changes made to this host by `kubeadm init` or `kubeadm join` diff --git a/content/en/docs/reference/setup-tools/kubeadm/kubeadm-config.md b/content/en/docs/reference/setup-tools/kubeadm/kubeadm-config.md index a4b0e501d8..655f9ec875 100644 --- a/content/en/docs/reference/setup-tools/kubeadm/kubeadm-config.md +++ b/content/en/docs/reference/setup-tools/kubeadm/kubeadm-config.md @@ -6,6 +6,7 @@ title: kubeadm config content_type: concept weight: 50 --- + <!-- overview --> During `kubeadm init`, kubeadm uploads the `ClusterConfiguration` object to your cluster in a ConfigMap called `kubeadm-config` in the `kube-system` namespace. This configuration is then read during @@ -19,30 +20,31 @@ In Kubernetes v1.13.0 and later to list/pull kube-dns images instead of the Core the `--config` method described [here](/docs/reference/setup-tools/kubeadm/kubeadm-init-phase/#cmd-phase-addon) has to be used. - - <!-- body --> ## kubeadm config view {#cmd-config-view} + {{< include "generated/kubeadm_config_view.md" >}} ## kubeadm config print init-defaults {#cmd-config-print-init-defaults} + {{< include "generated/kubeadm_config_print_init-defaults.md" >}} ## kubeadm config print join-defaults {#cmd-config-print-join-defaults} + {{< include "generated/kubeadm_config_print_join-defaults.md" >}} ## kubeadm config migrate {#cmd-config-migrate} + {{< include "generated/kubeadm_config_migrate.md" >}} ## kubeadm config images list {#cmd-config-images-list} + {{< include "generated/kubeadm_config_images_list.md" >}} ## kubeadm config images pull {#cmd-config-images-pull} + {{< include "generated/kubeadm_config_images_pull.md" >}} - - ## {{% heading "whatsnext" %}} * [kubeadm upgrade](/docs/reference/setup-tools/kubeadm/kubeadm-upgrade/) to upgrade a Kubernetes cluster to a newer version - diff --git a/content/en/docs/reference/setup-tools/kubeadm/kubeadm-init-phase.md b/content/en/docs/reference/setup-tools/kubeadm/kubeadm-init-phase.md index e3fe8c543c..289767e1e1 100644 --- a/content/en/docs/reference/setup-tools/kubeadm/kubeadm-init-phase.md +++ b/content/en/docs/reference/setup-tools/kubeadm/kubeadm-init-phase.md @@ -1,7 +1,9 @@ --- title: kubeadm init phase weight: 90 +content_type: concept --- + `kubeadm init phase` enables you to invoke atomic steps of the bootstrap process. Hence, you can let kubeadm do some of the work and you can fill in the gaps if you wish to apply customization. @@ -80,7 +82,6 @@ Use the following phase to create a local etcd instance based on a static Pod fi {{< tab name="local" include="generated/kubeadm_init_phase_etcd_local.md" />}} {{< /tabs >}} - ## kubeadm init phase upload-config {#cmd-phase-upload-config} You can use this command to upload the kubeadm configuration to your cluster. @@ -93,7 +94,6 @@ Alternatively, you can use [kubeadm config](/docs/reference/setup-tools/kubeadm/ {{< tab name="kubelet" include="generated/kubeadm_init_phase_upload-config_kubelet.md" />}} {{< /tabs >}} - ## kubeadm init phase upload-certs {#cmd-phase-upload-certs} Use the following phase to upload control-plane certificates to the cluster. @@ -103,7 +103,6 @@ By default the certs and encryption key expire after two hours. {{< tab name="upload-certs" include="generated/kubeadm_init_phase_upload-certs.md" />}} {{< /tabs >}} - ## kubeadm init phase mark-control-plane {#cmd-phase-mark-control-plane} Use the following phase to label and taint the node with the `node-role.kubernetes.io/master=""` key-value pair. @@ -112,7 +111,6 @@ Use the following phase to label and taint the node with the `node-role.kubernet {{< tab name="mark-control-plane" include="generated/kubeadm_init_phase_mark-control-plane.md" />}} {{< /tabs >}} - ## kubeadm init phase bootstrap-token {#cmd-phase-bootstrap-token} Use the following phase to configure bootstrap tokens. @@ -156,7 +154,8 @@ Please note that kube-dns usage with kubeadm is deprecated as of v1.18 and will For more details on each field in the `v1beta2` configuration you can navigate to our [API reference pages.] (https://godoc.org/k8s.io/kubernetes/cmd/kubeadm/app/apis/kubeadm/v1beta2) -## What's next +## {{% heading "whatsnext" %}} + * [kubeadm init](/docs/reference/setup-tools/kubeadm/kubeadm-init/) to bootstrap a Kubernetes control-plane node * [kubeadm join](/docs/reference/setup-tools/kubeadm/kubeadm-join/) to connect a node to the cluster * [kubeadm reset](/docs/reference/setup-tools/kubeadm/kubeadm-reset/) to revert any changes made to this host by `kubeadm init` or `kubeadm join` diff --git a/content/en/docs/reference/setup-tools/kubeadm/kubeadm-init.md b/content/en/docs/reference/setup-tools/kubeadm/kubeadm-init.md index 54729065c6..997240399e 100644 --- a/content/en/docs/reference/setup-tools/kubeadm/kubeadm-init.md +++ b/content/en/docs/reference/setup-tools/kubeadm/kubeadm-init.md @@ -9,12 +9,12 @@ weight: 20 <!-- overview --> This command initializes a Kubernetes control-plane node. - <!-- body --> {{< include "generated/kubeadm_init.md" >}} ### Init workflow {#init-workflow} + `kubeadm init` bootstraps a Kubernetes control-plane node by executing the following steps: @@ -166,7 +166,7 @@ to download the certificates when additional control-plane nodes are joining, by The following phase command can be used to re-upload the certificates after expiration: -``` +```shell kubeadm init phase upload-certs --upload-certs --certificate-key=SOME_VALUE --config=SOME_YAML_FILE ``` @@ -175,7 +175,7 @@ If the flag `--certificate-key` is not passed to `kubeadm init` and The following command can be used to generate a new key on demand: -``` +```shell kubeadm alpha certs certificate-key ``` @@ -226,26 +226,26 @@ token distribution for easier automation. To implement this automation, you must know the IP address that the control-plane node will have after it is started, or use a DNS name or an address of a load balancer. -1. Generate a token. This token must have the form `<6 character string>.<16 - character string>`. More formally, it must match the regex: - `[a-z0-9]{6}\.[a-z0-9]{16}`. +1. Generate a token. This token must have the form `<6 character string>.<16 + character string>`. More formally, it must match the regex: + `[a-z0-9]{6}\.[a-z0-9]{16}`. - kubeadm can generate a token for you: + kubeadm can generate a token for you: - ```shell + ```shell kubeadm token generate - ``` + ``` -1. Start both the control-plane node and the worker nodes concurrently with this token. - As they come up they should find each other and form the cluster. The same - `--token` argument can be used on both `kubeadm init` and `kubeadm join`. +1. Start both the control-plane node and the worker nodes concurrently with this token. + As they come up they should find each other and form the cluster. The same + `--token` argument can be used on both `kubeadm init` and `kubeadm join`. -1. Similar can be done for `--certificate-key` when joining additional control-plane - nodes. The key can be generated using: +1. Similar can be done for `--certificate-key` when joining additional control-plane + nodes. The key can be generated using: - ```shell - kubeadm alpha certs certificate-key - ``` + ```shell + kubeadm alpha certs certificate-key + ``` Once the cluster is up, you can grab the admin credentials from the control-plane node at `/etc/kubernetes/admin.conf` and use that to talk to the cluster. @@ -255,8 +255,6 @@ it does not allow the root CA hash to be validated with `--discovery-token-ca-cert-hash` (since it's not generated when the nodes are provisioned). For details, see the [kubeadm join](/docs/reference/setup-tools/kubeadm/kubeadm-join/). - - ## {{% heading "whatsnext" %}} * [kubeadm init phase](/docs/reference/setup-tools/kubeadm/kubeadm-init-phase/) to understand more about @@ -264,4 +262,3 @@ provisioned). For details, see the [kubeadm join](/docs/reference/setup-tools/ku * [kubeadm join](/docs/reference/setup-tools/kubeadm/kubeadm-join/) to bootstrap a Kubernetes worker node and join it to the cluster * [kubeadm upgrade](/docs/reference/setup-tools/kubeadm/kubeadm-upgrade/) to upgrade a Kubernetes cluster to a newer version * [kubeadm reset](/docs/reference/setup-tools/kubeadm/kubeadm-reset/) to revert any changes made to this host by `kubeadm init` or `kubeadm join` - diff --git a/content/en/docs/reference/setup-tools/kubeadm/kubeadm-join-phase.md b/content/en/docs/reference/setup-tools/kubeadm/kubeadm-join-phase.md index c26c0a2e4b..c41054b543 100644 --- a/content/en/docs/reference/setup-tools/kubeadm/kubeadm-join-phase.md +++ b/content/en/docs/reference/setup-tools/kubeadm/kubeadm-join-phase.md @@ -1,7 +1,9 @@ --- title: kubeadm join phase weight: 90 +content_type: concept --- + `kubeadm join phase` enables you to invoke atomic steps of the join process. Hence, you can let kubeadm do some of the work and you can fill in the gaps if you wish to apply customization. @@ -56,7 +58,8 @@ Using this phase you can join a node as a control-plane instance. {{< tab name="mark-control-plane" include="generated/kubeadm_join_phase_control-plane-join_mark-control-plane.md" />}} {{< /tabs >}} -## What's next +## {{% heading "whatsnext" %}} + * [kubeadm init](/docs/reference/setup-tools/kubeadm/kubeadm-init/) to bootstrap a Kubernetes control-plane node * [kubeadm join](/docs/reference/setup-tools/kubeadm/kubeadm-join/) to connect a node to the cluster * [kubeadm reset](/docs/reference/setup-tools/kubeadm/kubeadm-reset/) to revert any changes made to this host by `kubeadm init` or `kubeadm join` diff --git a/content/en/docs/reference/setup-tools/kubeadm/kubeadm-join.md b/content/en/docs/reference/setup-tools/kubeadm/kubeadm-join.md index abceaf5f70..28d489cfb6 100644 --- a/content/en/docs/reference/setup-tools/kubeadm/kubeadm-join.md +++ b/content/en/docs/reference/setup-tools/kubeadm/kubeadm-join.md @@ -9,7 +9,6 @@ weight: 30 <!-- overview --> This command initializes a Kubernetes worker node and joins it to the cluster. - <!-- body --> {{< include "generated/kubeadm_join.md" >}} @@ -59,7 +58,7 @@ kubeadm join phase kubelet-start --help ``` Similar to the [kubeadm init phase](/docs/reference/setup-tools/kubeadm/kubeadm-init/#init-phases) -command, `kubadm join phase` allows you to skip a list of phases using the `--skip-phases` flag. +command, `kubeadm join phase` allows you to skip a list of phases using the `--skip-phases` flag. For example: @@ -105,18 +104,18 @@ if the `kubeadm init` command was called with `--upload-certs`. **Advantages:** - - Allows bootstrapping nodes to securely discover a root of trust for the - control-plane node even if other worker nodes or the network are compromised. +- Allows bootstrapping nodes to securely discover a root of trust for the + control-plane node even if other worker nodes or the network are compromised. - - Convenient to execute manually since all of the information required fits - into a single `kubeadm join` command that is easy to copy and paste. +- Convenient to execute manually since all of the information required fits + into a single `kubeadm join` command that is easy to copy and paste. **Disadvantages:** - - The CA hash is not normally known until the control-plane node has been provisioned, - which can make it more difficult to build automated provisioning tools that - use kubeadm. By generating your CA in beforehand, you may workaround this - limitation. +- The CA hash is not normally known until the control-plane node has been provisioned, + which can make it more difficult to build automated provisioning tools that + use kubeadm. By generating your CA in beforehand, you may workaround this + limitation. #### Token-based discovery without CA pinning @@ -134,18 +133,18 @@ kubeadm join --token abcdef.1234567890abcdef --discovery-token-unsafe-skip-ca-ve **Advantages:** - - Still protects against many network-level attacks. +- Still protects against many network-level attacks. - - The token can be generated ahead of time and shared with the control-plane node and - worker nodes, which can then bootstrap in parallel without coordination. This - allows it to be used in many provisioning scenarios. +- The token can be generated ahead of time and shared with the control-plane node and + worker nodes, which can then bootstrap in parallel without coordination. This + allows it to be used in many provisioning scenarios. **Disadvantages:** - - If an attacker is able to steal a bootstrap token via some vulnerability, - they can use that token (along with network-level access) to impersonate the - control-plane node to other bootstrapping nodes. This may or may not be an appropriate - tradeoff in your environment. +- If an attacker is able to steal a bootstrap token via some vulnerability, + they can use that token (along with network-level access) to impersonate the + control-plane node to other bootstrapping nodes. This may or may not be an appropriate + tradeoff in your environment. #### File or HTTPS-based discovery @@ -158,21 +157,21 @@ In case the discovery file does not contain credentials, the TLS discovery token **Example `kubeadm join` commands:** - - `kubeadm join --discovery-file path/to/file.conf` (local file) +- `kubeadm join --discovery-file path/to/file.conf` (local file) - - `kubeadm join --discovery-file https://url/file.conf` (remote HTTPS URL) +- `kubeadm join --discovery-file https://url/file.conf` (remote HTTPS URL) **Advantages:** - - Allows bootstrapping nodes to securely discover a root of trust for the - control-plane node even if the network or other worker nodes are compromised. +- Allows bootstrapping nodes to securely discover a root of trust for the + control-plane node even if the network or other worker nodes are compromised. **Disadvantages:** - - Requires that you have some way to carry the discovery information from - the control-plane node to the bootstrapping nodes. If the discovery file contains credentials - you must keep it secret and transfer it over a secure channel. This might be possible with your - cloud provider or provisioning tool. +- Requires that you have some way to carry the discovery information from + the control-plane node to the bootstrapping nodes. If the discovery file contains credentials + you must keep it secret and transfer it over a secure channel. This might be possible with your + cloud provider or provisioning tool. ### Securing your installation even more {#securing-more} @@ -194,7 +193,9 @@ After that, `kubeadm join` will block until the admin has manually approved the ```shell kubectl get csr ``` + The output is similar to this: + ``` NAME AGE REQUESTOR CONDITION node-csr-c69HXe7aYcqkS1bKmH4faEnHAWxn6i2bHZ2mD04jZyQ 18s system:bootstrap:878f07 Pending @@ -203,7 +204,9 @@ node-csr-c69HXe7aYcqkS1bKmH4faEnHAWxn6i2bHZ2mD04jZyQ 18s system:bootstra ```shell kubectl certificate approve node-csr-c69HXe7aYcqkS1bKmH4faEnHAWxn6i2bHZ2mD04jZyQ ``` + The output is similar to this: + ``` certificatesigningrequest "node-csr-c69HXe7aYcqkS1bKmH4faEnHAWxn6i2bHZ2mD04jZyQ" approved ``` @@ -211,7 +214,9 @@ certificatesigningrequest "node-csr-c69HXe7aYcqkS1bKmH4faEnHAWxn6i2bHZ2mD04jZyQ" ```shell kubectl get csr ``` + The output is similar to this: + ``` NAME AGE REQUESTOR CONDITION node-csr-c69HXe7aYcqkS1bKmH4faEnHAWxn6i2bHZ2mD04jZyQ 1m system:bootstrap:878f07 Approved,Issued @@ -232,7 +237,9 @@ it off regardless. Doing so will disable the ability to use the `--discovery-tok ```shell kubectl -n kube-public get cm cluster-info -o yaml | grep "kubeconfig:" -A11 | grep "apiVersion" -A10 | sed "s/ //" | tee cluster-info.yaml ``` + The output is similar to this: + ``` apiVersion: v1 kind: Config @@ -276,11 +283,8 @@ kubeadm config print join-defaults For details on individual fields in `JoinConfiguration` see [the godoc](https://godoc.org/k8s.io/kubernetes/cmd/kubeadm/app/apis/kubeadm#JoinConfiguration). - - ## {{% heading "whatsnext" %}} * [kubeadm init](/docs/reference/setup-tools/kubeadm/kubeadm-init/) to bootstrap a Kubernetes control-plane node * [kubeadm token](/docs/reference/setup-tools/kubeadm/kubeadm-token/) to manage tokens for `kubeadm join` * [kubeadm reset](/docs/reference/setup-tools/kubeadm/kubeadm-reset/) to revert any changes made to this host by `kubeadm init` or `kubeadm join` - diff --git a/content/en/docs/reference/setup-tools/kubeadm/kubeadm-reset-phase.md b/content/en/docs/reference/setup-tools/kubeadm/kubeadm-reset-phase.md index 663bb67e24..95c8ea129f 100644 --- a/content/en/docs/reference/setup-tools/kubeadm/kubeadm-reset-phase.md +++ b/content/en/docs/reference/setup-tools/kubeadm/kubeadm-reset-phase.md @@ -1,7 +1,9 @@ --- title: kubeadm reset phase weight: 90 +content_type: concept --- + `kubeadm reset phase` enables you to invoke atomic steps of the node reset process. Hence, you can let kubeadm do some of the work and you can fill in the gaps if you wish to apply customization. @@ -47,7 +49,8 @@ Using this phase you can perform cleanup on this node. {{< tab name="cleanup-node" include="generated/kubeadm_reset_phase_cleanup-node.md" />}} {{< /tabs >}} -## What's next +## {{% heading "whatsnext" %}} + * [kubeadm init](/docs/reference/setup-tools/kubeadm/kubeadm-init/) to bootstrap a Kubernetes control-plane node * [kubeadm join](/docs/reference/setup-tools/kubeadm/kubeadm-join/) to connect a node to the cluster * [kubeadm reset](/docs/reference/setup-tools/kubeadm/kubeadm-reset/) to revert any changes made to this host by `kubeadm init` or `kubeadm join` diff --git a/content/en/docs/reference/setup-tools/kubeadm/kubeadm-reset.md b/content/en/docs/reference/setup-tools/kubeadm/kubeadm-reset.md index 2664283daa..93d5ce0cbb 100644 --- a/content/en/docs/reference/setup-tools/kubeadm/kubeadm-reset.md +++ b/content/en/docs/reference/setup-tools/kubeadm/kubeadm-reset.md @@ -9,7 +9,6 @@ weight: 60 <!-- overview --> Performs a best effort revert of changes made by `kubeadm init` or `kubeadm join`. - <!-- body --> {{< include "generated/kubeadm_reset.md" >}} @@ -36,9 +35,7 @@ etcdctl del "" --prefix See the [etcd documentation](https://github.com/coreos/etcd/tree/master/etcdctl) for more information. - ## {{% heading "whatsnext" %}} * [kubeadm init](/docs/reference/setup-tools/kubeadm/kubeadm-init/) to bootstrap a Kubernetes control-plane node * [kubeadm join](/docs/reference/setup-tools/kubeadm/kubeadm-join/) to bootstrap a Kubernetes worker node and join it to the cluster - diff --git a/content/en/docs/reference/setup-tools/kubeadm/kubeadm-token.md b/content/en/docs/reference/setup-tools/kubeadm/kubeadm-token.md index 92a187bb92..6edb87557d 100644 --- a/content/en/docs/reference/setup-tools/kubeadm/kubeadm-token.md +++ b/content/en/docs/reference/setup-tools/kubeadm/kubeadm-token.md @@ -14,8 +14,6 @@ the cluster and a control-plane node, as described in [authenticating with boots `kubeadm init` creates an initial token with a 24-hour TTL. The following commands allow you to manage such a token and also to create and manage new ones. - - <!-- body --> ## kubeadm token create {#cmd-token-create} {{< include "generated/kubeadm_token_create.md" >}} @@ -29,8 +27,6 @@ such a token and also to create and manage new ones. ## kubeadm token list {#cmd-token-list} {{< include "generated/kubeadm_token_list.md" >}} - ## {{% heading "whatsnext" %}} * [kubeadm join](/docs/reference/setup-tools/kubeadm/kubeadm-join/) to bootstrap a Kubernetes worker node and join it to the cluster - diff --git a/content/en/docs/reference/setup-tools/kubeadm/kubeadm-upgrade-phase.md b/content/en/docs/reference/setup-tools/kubeadm/kubeadm-upgrade-phase.md index 6224a18e0e..a7f4b6d1a6 100644 --- a/content/en/docs/reference/setup-tools/kubeadm/kubeadm-upgrade-phase.md +++ b/content/en/docs/reference/setup-tools/kubeadm/kubeadm-upgrade-phase.md @@ -1,6 +1,7 @@ --- title: kubeadm upgrade phase weight: 90 +content_type: concept --- In v1.15.0, kubeadm introduced preliminary support for `kubeadm upgrade node` phases. Phases for other `kubeadm upgrade` sub-commands such as `apply`, could be added in the @@ -18,7 +19,8 @@ be called on a primary control-plane node. {{< tab name="kubelet-config" include="generated/kubeadm_upgrade_node_phase_kubelet-config.md" />}} {{< /tabs >}} -## What's next +## {{% heading "whatsnext" %}} + * [kubeadm init](/docs/reference/setup-tools/kubeadm/kubeadm-init/) to bootstrap a Kubernetes control-plane node * [kubeadm join](/docs/reference/setup-tools/kubeadm/kubeadm-join/) to connect a node to the cluster * [kubeadm reset](/docs/reference/setup-tools/kubeadm/kubeadm-reset/) to revert any changes made to this host by `kubeadm init` or `kubeadm join` diff --git a/content/en/docs/reference/setup-tools/kubeadm/kubeadm-upgrade.md b/content/en/docs/reference/setup-tools/kubeadm/kubeadm-upgrade.md index 71483aa1d6..5796e7aec7 100644 --- a/content/en/docs/reference/setup-tools/kubeadm/kubeadm-upgrade.md +++ b/content/en/docs/reference/setup-tools/kubeadm/kubeadm-upgrade.md @@ -47,8 +47,6 @@ reports of unexpected results. {{< include "generated/kubeadm_upgrade_node.md" >}} - ## {{% heading "whatsnext" %}} * [kubeadm config](/docs/reference/setup-tools/kubeadm/kubeadm-config/) if you initialized your cluster using kubeadm v1.7.x or lower, to configure your cluster for `kubeadm upgrade` - diff --git a/content/en/docs/reference/setup-tools/kubeadm/kubeadm-version.md b/content/en/docs/reference/setup-tools/kubeadm/kubeadm-version.md index a4b57e796c..aabd8dd656 100644 --- a/content/en/docs/reference/setup-tools/kubeadm/kubeadm-version.md +++ b/content/en/docs/reference/setup-tools/kubeadm/kubeadm-version.md @@ -9,7 +9,5 @@ weight: 80 <!-- overview --> This command prints the version of kubeadm. - <!-- body --> {{< include "generated/kubeadm_version.md" >}} - diff --git a/content/en/docs/reference/setup-tools/kubeadm/kubeadm.md b/content/en/docs/reference/setup-tools/kubeadm/kubeadm.md deleted file mode 100644 index 8c16518bb2..0000000000 --- a/content/en/docs/reference/setup-tools/kubeadm/kubeadm.md +++ /dev/null @@ -1,30 +0,0 @@ ---- -reviewers: -- luxas -- jbeda -title: Overview of kubeadm -weight: 10 -card: - name: reference - weight: 40 ---- -<img src="https://raw.githubusercontent.com/kubernetes/kubeadm/master/logos/stacked/color/kubeadm-stacked-color.png" align="right" width="150px">Kubeadm is a tool built to provide `kubeadm init` and `kubeadm join` as best-practice “fast paths” for creating Kubernetes clusters. - -kubeadm performs the actions necessary to get a minimum viable cluster up and running. By design, it cares only about bootstrapping, not about provisioning machines. Likewise, installing various nice-to-have addons, like the Kubernetes Dashboard, monitoring solutions, and cloud-specific addons, is not in scope. - -Instead, we expect higher-level and more tailored tooling to be built on top of kubeadm, and ideally, using kubeadm as the basis of all deployments will make it easier to create conformant clusters. - -## How to install - -To install kubeadm, see the [installation guide](/docs/setup/production-environment/tools/kubeadm/install-kubeadm). - -## What's next - -* [kubeadm init](/docs/reference/setup-tools/kubeadm/kubeadm-init) to bootstrap a Kubernetes control-plane node -* [kubeadm join](/docs/reference/setup-tools/kubeadm/kubeadm-join) to bootstrap a Kubernetes worker node and join it to the cluster -* [kubeadm upgrade](/docs/reference/setup-tools/kubeadm/kubeadm-upgrade) to upgrade a Kubernetes cluster to a newer version -* [kubeadm config](/docs/reference/setup-tools/kubeadm/kubeadm-config) if you initialized your cluster using kubeadm v1.7.x or lower, to configure your cluster for `kubeadm upgrade` -* [kubeadm token](/docs/reference/setup-tools/kubeadm/kubeadm-token) to manage tokens for `kubeadm join` -* [kubeadm reset](/docs/reference/setup-tools/kubeadm/kubeadm-reset) to revert any changes made to this host by `kubeadm init` or `kubeadm join` -* [kubeadm version](/docs/reference/setup-tools/kubeadm/kubeadm-version) to print the kubeadm version -* [kubeadm alpha](/docs/reference/setup-tools/kubeadm/kubeadm-alpha) to preview a set of features made available for gathering feedback from the community diff --git a/content/en/docs/reference/using-api/_index.md b/content/en/docs/reference/using-api/_index.md index c6bbb2831b..9d6b7c4e36 100644 --- a/content/en/docs/reference/using-api/_index.md +++ b/content/en/docs/reference/using-api/_index.md @@ -1,5 +1,4 @@ --- title: Using the Kubernetes API weight: 10 -toc-hide: true --- \ No newline at end of file diff --git a/content/en/docs/reference/using-api/api-concepts.md b/content/en/docs/reference/using-api/api-concepts.md index f83c43c00f..5accb778ba 100644 --- a/content/en/docs/reference/using-api/api-concepts.md +++ b/content/en/docs/reference/using-api/api-concepts.md @@ -596,7 +596,11 @@ more information about how an object's schema is used to make decisions when merging, see [sigs.k8s.io/structured-merge-diff](https://sigs.k8s.io/structured-merge-diff). -A number of markers were added in Kubernetes 1.16 and 1.17, to allow API developers to describe the merge strategy supported by lists, maps, and structs. These markers can be applied to objects of the respective type, in Go files or OpenAPI specs. +A number of markers were added in Kubernetes 1.16 and 1.17, to allow API +developers to describe the merge strategy supported by lists, maps, and +structs. These markers can be applied to objects of the respective type, +in Go files or in the [OpenAPI schema definition of the +CRD](/docs/reference/generated/kubernetes-api/{{< param "version" >}}#jsonschemaprops-v1-apiextensions-k8s-io): | Golang marker | OpenAPI extension | Accepted values | Description | Introduced in | |---|---|---|---|---| @@ -609,8 +613,12 @@ A number of markers were added in Kubernetes 1.16 and 1.17, to allow API develop By default, Server Side Apply treats custom resources as unstructured data. All keys are treated the same as struct fields, and all lists are considered atomic. -If the validation field is specified in the Custom Resource Definition, it is -used when merging objects of this type. + +If the Custom Resource Definition defines a +[schema](/docs/reference/generated/kubernetes-api/{{< param "version" >}}#jsonschemaprops-v1-apiextensions-k8s-io) +that contains annotations as defined in the previous "Merge Strategy" +section, these annotations will be used when merging objects of this +type. ### Using Server-Side Apply in a controller @@ -706,9 +714,9 @@ Resource versions are strings that identify the server's internal version of an Clients find resource versions in resources, including the resources in watch events, and list responses returned from the server: -[v1.meta/ObjectMeta](https://kubernetes.io/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#objectmeta-v1-meta) - The `metadata.resourceVersion` of a resource instance identifies the resource version the instance was last modified at. +[v1.meta/ObjectMeta](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#objectmeta-v1-meta) - The `metadata.resourceVersion` of a resource instance identifies the resource version the instance was last modified at. -[v1.meta/ListMeta](https://kubernetes.io/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#listmeta-v1-meta) - The `metadata.resourceVersion` of a resource collection (i.e. a list response) identifies the resource version at which the list response was constructed. +[v1.meta/ListMeta](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#listmeta-v1-meta) - The `metadata.resourceVersion` of a resource collection (i.e. a list response) identifies the resource version at which the list response was constructed. ### The ResourceVersion Parameter @@ -726,11 +734,11 @@ For get and list, the semantics of resource version are: **List:** -| paging | resourceVersion unset | resourceVersion="0" | resourceVersion="{value other than 0}" | -|-------------------------------|-----------------------|------------------------------------------------|----------------------------------------| -| limit unset | Most Recent | Any | Not older than | -| limit="n", continue unset | Most Recent | Any | Exact | -| limit="n", continue="<token>" | Continue Token, Exact | Invalid, but treated as Continue Token, Exact | Invalid, HTTP `400 Bad Request` | +| paging | resourceVersion unset | resourceVersion="0" | resourceVersion="{value other than 0}" | +|---------------------------------|-----------------------|------------------------------------------------|----------------------------------------| +| limit unset | Most Recent | Any | Not older than | +| limit="n", continue unset | Most Recent | Any | Exact | +| limit="n", continue="\<token\>" | Continue Token, Exact | Invalid, but treated as Continue Token, Exact | Invalid, HTTP `400 Bad Request` | The meaning of the get and list semantics are: diff --git a/content/en/docs/reference/using-api/api-overview.md b/content/en/docs/reference/using-api/api-overview.md index 25b7d46af9..529c6fc799 100644 --- a/content/en/docs/reference/using-api/api-overview.md +++ b/content/en/docs/reference/using-api/api-overview.md @@ -33,7 +33,7 @@ if you are writing an application using the Kubernetes API. To eliminate fields or restructure resource representations, Kubernetes supports multiple API versions, each at a different API path. For example: `/api/v1` or -`/apis/extensions/v1beta1`. +`/apis/rbac.authorization.k8s.io/v1alpha1`. The version is set at the API level rather than at the resource or field level to: @@ -84,7 +84,7 @@ Currently, there are several API groups in use: * The named groups are at REST path `/apis/$GROUP_NAME/$VERSION`, and use `apiVersion: $GROUP_NAME/$VERSION` (for example, `apiVersion: batch/v1`). You can find the full list of supported API groups in [Kubernetes API reference](/docs/reference/). -The two paths that support extending the API with [custom resources](/docs/concepts/api-extension/custom-resources/) are: +The two paths that support extending the API with [custom resources](/docs/concepts/extend-kubernetes/api-extension/custom-resources/) are: - [CustomResourceDefinition](/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/) for basic CRUD needs. @@ -106,10 +106,3 @@ When you enable or disable groups or resources, you need to restart the apiserve to pick up the `--runtime-config` changes. {{< /note >}} -## Enabling specific resources in the extensions/v1beta1 group - -DaemonSets, Deployments, StatefulSet, NetworkPolicies, PodSecurityPolicies and ReplicaSets in the `extensions/v1beta1` API group are disabled by default. -For example: to enable deployments and daemonsets, set -`--runtime-config=extensions/v1beta1/deployments=true,extensions/v1beta1/daemonsets=true`. - -{{< note >}}Individual resource enablement/disablement is only supported in the `extensions/v1beta1` API group for legacy reasons.{{< /note >}} diff --git a/content/en/docs/reference/using-api/client-libraries.md b/content/en/docs/reference/using-api/client-libraries.md index 1531b2c5df..c4d7e5ea24 100644 --- a/content/en/docs/reference/using-api/client-libraries.md +++ b/content/en/docs/reference/using-api/client-libraries.md @@ -19,13 +19,13 @@ You can use a client library for the programming language you are using. Client libraries often handle common tasks such as authentication for you. Most client libraries can discover and use the Kubernetes Service Account to authenticate if the API client is running inside the Kubernetes cluster, or can -understand the [kubeconfig file](/docs/tasks/access-application-cluster/authenticate-across-clusters-kubeconfig/) +understand the [kubeconfig file](/docs/tasks/access-application-cluster/configure-access-multiple-clusters/) format to read the credentials and the API Server address. ## Officially-supported Kubernetes client libraries -The following client libraries are officially maintained by [Kubernetes SIG API -Machinery](https://github.com/kubernetes/community/tree/master/sig-api-machinery). +The following client libraries are officially maintained by +[Kubernetes SIG API Machinery](https://github.com/kubernetes/community/tree/master/sig-api-machinery). | Language | Client Library | Sample Programs | diff --git a/content/en/docs/reference/using-api/deprecation-policy.md b/content/en/docs/reference/using-api/deprecation-policy.md index a21d0887ba..f714a69472 100644 --- a/content/en/docs/reference/using-api/deprecation-policy.md +++ b/content/en/docs/reference/using-api/deprecation-policy.md @@ -289,8 +289,7 @@ API versions are supported in a series of subsequent releases. ### REST resources (aka API objects) Consider a hypothetical REST resource named Widget, which was present in API v1 -in the above timeline, and which needs to be deprecated. We -[document](/docs/reference/deprecation-policy/) and +in the above timeline, and which needs to be deprecated. We document and [announce](https://groups.google.com/forum/#!forum/kubernetes-announce) the deprecation in sync with release X+1. The Widget resource still exists in API version v1 (deprecated) but not in v2alpha1. The Widget resource continues to diff --git a/content/en/docs/reference/using-api/health-checks.md b/content/en/docs/reference/using-api/health-checks.md new file mode 100644 index 0000000000..a7be3b267f --- /dev/null +++ b/content/en/docs/reference/using-api/health-checks.md @@ -0,0 +1,103 @@ +--- +title: Kubernetes API health endpoints +reviewers: +- logicalhan +content_type: concept +weight: 50 +--- + +<!-- overview --> +The Kubernetes {{< glossary_tooltip term_id="kube-apiserver" text="API server" >}} provides API endpoints to indicate the current status of the API server. +This page describes these API endpoints and explains how you can use them. + +<!-- body --> + +## API endpoints for health + +The Kubernetes API server provides 3 API endpoints (`healthz`, `livez` and `readyz`) to indicate the current status of the API server. +The `healthz` endpoint is deprecated (since Kubernetes v1.16), and you should use the more specific `livez` and `readyz` endpoints instead. +The `livez` endpoint can be used with the `--livez-grace-period` [flag](/docs/reference/command-line-tools-reference/kube-apiserver) to specify the startup duration. +For a graceful shutdown you can specify the `--shutdown-delay-duration` [flag](/docs/reference/command-line-tools-reference/kube-apiserver) with the `/readyz` endpoint. +Machines that check the `health`/`livez`/`readyz` of the API server should rely on the HTTP status code. +A status code `200` indicates the the API server is `healthy`/`live`/`ready`, depending of the called endpoint. +The more verbose options shown below are intended to be used by human operators to debug their cluster or specially the state of the API server. + +The following examples will show how you can interact with the health API endpoints. + +For all endpoints you can use the `verbose` parameter to print out the checks and their status. +This can be useful for a human operator to debug the current status of the Api server, it is not intended to be consumed by a machine: + + ```shell + curl -k https://localhost:6443/livez?verbose + ``` + +or from a remote host with authentication: + + ```shell + kubectl get --raw='/readyz?verbose' + ``` + +The output will look like this: + + [+]ping ok + [+]log ok + [+]etcd ok + [+]poststarthook/start-kube-apiserver-admission-initializer ok + [+]poststarthook/generic-apiserver-start-informers ok + [+]poststarthook/start-apiextensions-informers ok + [+]poststarthook/start-apiextensions-controllers ok + [+]poststarthook/crd-informer-synced ok + [+]poststarthook/bootstrap-controller ok + [+]poststarthook/rbac/bootstrap-roles ok + [+]poststarthook/scheduling/bootstrap-system-priority-classes ok + [+]poststarthook/start-cluster-authentication-info-controller ok + [+]poststarthook/start-kube-aggregator-informers ok + [+]poststarthook/apiservice-registration-controller ok + [+]poststarthook/apiservice-status-available-controller ok + [+]poststarthook/kube-apiserver-autoregistration ok + [+]autoregister-completion ok + [+]poststarthook/apiservice-openapi-controller ok + healthz check passed + +The Kubernetes API server also supports to exclude specific checks. +The query parameters can also be combined like in this example: + + ```shell + curl -k 'https://localhost:6443/readyz?verbose&exclude=etcd' + ``` + +The output show that the `etcd` check is excluded: + + [+]ping ok + [+]log ok + [+]etcd excluded: ok + [+]poststarthook/start-kube-apiserver-admission-initializer ok + [+]poststarthook/generic-apiserver-start-informers ok + [+]poststarthook/start-apiextensions-informers ok + [+]poststarthook/start-apiextensions-controllers ok + [+]poststarthook/crd-informer-synced ok + [+]poststarthook/bootstrap-controller ok + [+]poststarthook/rbac/bootstrap-roles ok + [+]poststarthook/scheduling/bootstrap-system-priority-classes ok + [+]poststarthook/start-cluster-authentication-info-controller ok + [+]poststarthook/start-kube-aggregator-informers ok + [+]poststarthook/apiservice-registration-controller ok + [+]poststarthook/apiservice-status-available-controller ok + [+]poststarthook/kube-apiserver-autoregistration ok + [+]autoregister-completion ok + [+]poststarthook/apiservice-openapi-controller ok + [+]shutdown ok + healthz check passed + +## Individual health checks + +{{< feature-state state="alpha" >}} + +Each individual health check exposes an http endpoint and could can be checked individually. +The schema for the individual health checks is `/livez/<healthcheck-name>` where `livez` and `readyz` and be used to indicate if you want to check thee liveness or the readiness of the API server. +The `<healthcheck-name>` path can be discovered using the `verbose` flag from above and take the path between `[+]` and `ok`. +These individual health checks should not be consumed by machines but can be helpful for a human operator to debug a system: + + ```shell + curl -k https://localhost:6443/livez/etcd + ``` diff --git a/content/en/docs/setup/_index.md b/content/en/docs/setup/_index.md index 91b734953c..59db384258 100644 --- a/content/en/docs/setup/_index.md +++ b/content/en/docs/setup/_index.md @@ -20,35 +20,20 @@ card: <!-- overview --> -This section covers different options to set up and run Kubernetes. - -Different Kubernetes solutions meet different requirements: ease of maintenance, security, control, available resources, and expertise required to operate and manage a cluster. - -You can deploy a Kubernetes cluster on a local machine, cloud, on-prem datacenter, or choose a managed Kubernetes cluster. You can also create custom solutions across a wide range of cloud providers, or bare metal environments. - -More simply, you can create a Kubernetes cluster in learning and production environments. - +This section lists the different ways to set up and run Kubernetes. +When you install Kubernetes, choose an installation type based on: ease of maintenance, security, +control, available resources, and expertise required to operate and manage a cluster. +You can deploy a Kubernetes cluster on a local machine, cloud, on-prem datacenter, or choose a managed Kubernetes cluster. There are also custom solutions across a wide range of cloud providers, or bare metal environments. <!-- body --> ## Learning environment -If you're learning Kubernetes, use the Docker-based solutions: tools supported by the Kubernetes community, or tools in the ecosystem to set up a Kubernetes cluster on a local machine. - -{{< table caption="Local machine solutions table that lists the tools supported by the community and the ecosystem to deploy Kubernetes." >}} - -|Community |Ecosystem | -| ------------ | -------- | -| [Minikube](/docs/setup/learning-environment/minikube/) | [Docker Desktop](https://www.docker.com/products/docker-desktop)| -| [kind (Kubernetes IN Docker)](/docs/setup/learning-environment/kind/) | [Minishift](https://docs.okd.io/latest/minishift/)| -| | [MicroK8s](https://microk8s.io/)| - +If you're learning Kubernetes, use the tools supported by the Kubernetes community, or tools in the ecosystem to set up a Kubernetes cluster on a local machine. ## Production environment When evaluating a solution for a production environment, consider which aspects of operating a Kubernetes cluster (or _abstractions_) you want to manage yourself or offload to a provider. [Kubernetes Partners](https://kubernetes.io/partners/#conformance) includes a list of [Certified Kubernetes](https://github.com/cncf/k8s-conformance/#certified-kubernetes) providers. - - diff --git a/content/en/docs/setup/best-practices/certificates.md b/content/en/docs/setup/best-practices/certificates.md index a85d44e0f4..9e27b40943 100644 --- a/content/en/docs/setup/best-practices/certificates.md +++ b/content/en/docs/setup/best-practices/certificates.md @@ -28,7 +28,7 @@ Kubernetes requires PKI for the following operations: * Client certificate for the API server to talk to etcd * Client certificate/kubeconfig for the controller manager to talk to the API server * Client certificate/kubeconfig for the scheduler to talk to the API server. -* Client and server certificates for the [front-proxy][proxy] +* Client and server certificates for the [front-proxy](/docs/tasks/extend-kubernetes/configure-aggregation-layer/) {{< note >}} `front-proxy` certificates are required only if you run kube-proxy to support [an extension API server](/docs/tasks/extend-kubernetes/setup-extension-api-server/). @@ -54,7 +54,7 @@ Required CAs: |------------------------|---------------------------|----------------------------------| | ca.crt,key | kubernetes-ca | Kubernetes general CA | | etcd/ca.crt,key | etcd-ca | For all etcd-related functions | -| front-proxy-ca.crt,key | kubernetes-front-proxy-ca | For the [front-end proxy][proxy] | +| front-proxy-ca.crt,key | kubernetes-front-proxy-ca | For the [front-end proxy](/docs/tasks/extend-kubernetes/configure-aggregation-layer/) | On top of the above CAs, it is also necessary to get a public/private key pair for service account management, `sa.key` and `sa.pub`. @@ -74,10 +74,11 @@ Required certificates: | kube-apiserver-kubelet-client | kubernetes-ca | system:masters | client | | | front-proxy-client | kubernetes-front-proxy-ca | | client | | -[1]: any other IP or DNS name you contact your cluster on (as used by [kubeadm][kubeadm] the load balancer stable IP and/or DNS name, `kubernetes`, `kubernetes.default`, `kubernetes.default.svc`, +[1]: any other IP or DNS name you contact your cluster on (as used by [kubeadm](/docs/reference/setup-tools/kubeadm/kubeadm/) +the load balancer stable IP and/or DNS name, `kubernetes`, `kubernetes.default`, `kubernetes.default.svc`, `kubernetes.default.svc.cluster`, `kubernetes.default.svc.cluster.local`) -where `kind` maps to one or more of the [x509 key usage][usage] types: +where `kind` maps to one or more of the [x509 key usage](https://godoc.org/k8s.io/api/certificates/v1beta1#KeyUsage) types: | kind | Key usage | |--------|---------------------------------------------------------------------------------| @@ -99,7 +100,8 @@ For kubeadm users only: ### Certificate paths -Certificates should be placed in a recommended path (as used by [kubeadm][kubeadm]). Paths should be specified using the given argument regardless of location. +Certificates should be placed in a recommended path (as used by [kubeadm](/docs/reference/setup-tools/kubeadm/kubeadm/)). +Paths should be specified using the given argument regardless of location. | Default CN | recommended key path | recommended cert path | command | key argument | cert argument | |------------------------------|------------------------------|-----------------------------|----------------|------------------------------|-------------------------------------------| @@ -160,8 +162,4 @@ These files are used as follows: | controller-manager.conf | kube-controller-manager | Must be added to manifest in `manifests/kube-controller-manager.yaml` | | scheduler.conf | kube-scheduler | Must be added to manifest in `manifests/kube-scheduler.yaml` | -[usage]: https://godoc.org/k8s.io/api/certificates/v1beta1#KeyUsage -[kubeadm]: /docs/reference/setup-tools/kubeadm/kubeadm/ -[proxy]: /docs/tasks/extend-kubernetes/configure-aggregation-layer/ - diff --git a/content/en/docs/setup/best-practices/cluster-large.md b/content/en/docs/setup/best-practices/cluster-large.md index c8692c8872..2b8f7b487f 100644 --- a/content/en/docs/setup/best-practices/cluster-large.md +++ b/content/en/docs/setup/best-practices/cluster-large.md @@ -20,7 +20,7 @@ At {{< param "version" >}}, Kubernetes supports clusters with up to 5000 nodes. A cluster is a set of nodes (physical or virtual machines) running Kubernetes agents, managed by a "master" (the cluster-level control plane). -Normally the number of nodes in a cluster is controlled by the value `NUM_NODES` in the platform-specific `config-default.sh` file (for example, see [GCE's `config-default.sh`](http://releases.k8s.io/{{< param "githubbranch" >}}/cluster/gce/config-default.sh)). +Normally the number of nodes in a cluster is controlled by the value `NUM_NODES` in the platform-specific `config-default.sh` file (for example, see [GCE's `config-default.sh`](https://releases.k8s.io/{{< param "githubbranch" >}}/cluster/gce/config-default.sh)). Simply changing that value to something very large, however, may cause the setup script to fail for many cloud providers. A GCE deployment, for example, will run in to quota issues and fail to bring the cluster up. @@ -80,7 +80,7 @@ On AWS, master node sizes are currently set at cluster startup time and do not c ### Addon Resources -To prevent memory leaks or other resource issues in [cluster addons](https://releases.k8s.io/{{< param "githubbranch" >}}/cluster/addons) from consuming all the resources available on a node, Kubernetes sets resource limits on addon containers to limit the CPU and Memory resources they can consume (See PR [#10653](http://pr.k8s.io/10653/files) and [#10778](http://pr.k8s.io/10778/files)). +To prevent memory leaks or other resource issues in [cluster addons](https://releases.k8s.io/{{< param "githubbranch" >}}/cluster/addons) from consuming all the resources available on a node, Kubernetes sets resource limits on addon containers to limit the CPU and Memory resources they can consume (See PR [#10653](https://pr.k8s.io/10653/files) and [#10778](https://pr.k8s.io/10778/files)). For example: @@ -94,28 +94,26 @@ For example: memory: 200Mi ``` -Except for Heapster, these limits are static and are based on data we collected from addons running on 4-node clusters (see [#10335](http://issue.k8s.io/10335#issuecomment-117861225)). The addons consume a lot more resources when running on large deployment clusters (see [#5880](http://issue.k8s.io/5880#issuecomment-113984085)). So, if a large cluster is deployed without adjusting these values, the addons may continuously get killed because they keep hitting the limits. +Except for Heapster, these limits are static and are based on data we collected from addons running on 4-node clusters (see [#10335](https://issue.k8s.io/10335#issuecomment-117861225)). The addons consume a lot more resources when running on large deployment clusters (see [#5880](http://issue.k8s.io/5880#issuecomment-113984085)). So, if a large cluster is deployed without adjusting these values, the addons may continuously get killed because they keep hitting the limits. To avoid running into cluster addon resource issues, when creating a cluster with many nodes, consider the following: * Scale memory and CPU limits for each of the following addons, if used, as you scale up the size of cluster (there is one replica of each handling the entire cluster so memory and CPU usage tends to grow proportionally with size/load on cluster): - * [InfluxDB and Grafana](http://releases.k8s.io/{{< param "githubbranch" >}}/cluster/addons/cluster-monitoring/influxdb/influxdb-grafana-controller.yaml) - * [kubedns, dnsmasq, and sidecar](http://releases.k8s.io/{{< param "githubbranch" >}}/cluster/addons/dns/kube-dns/kube-dns.yaml.in) - * [Kibana](http://releases.k8s.io/{{< param "githubbranch" >}}/cluster/addons/fluentd-elasticsearch/kibana-deployment.yaml) + * [InfluxDB and Grafana](https://releases.k8s.io/{{< param "githubbranch" >}}/cluster/addons/cluster-monitoring/influxdb/influxdb-grafana-controller.yaml) + * [kubedns, dnsmasq, and sidecar](https://releases.k8s.io/{{< param "githubbranch" >}}/cluster/addons/dns/kube-dns/kube-dns.yaml.in) + * [Kibana](https://releases.k8s.io/{{< param "githubbranch" >}}/cluster/addons/fluentd-elasticsearch/kibana-deployment.yaml) * Scale number of replicas for the following addons, if used, along with the size of cluster (there are multiple replicas of each so increasing replicas should help handle increased load, but, since load per replica also increases slightly, also consider increasing CPU/memory limits): - * [elasticsearch](http://releases.k8s.io/{{< param "githubbranch" >}}/cluster/addons/fluentd-elasticsearch/es-statefulset.yaml) + * [elasticsearch](https://releases.k8s.io/{{< param "githubbranch" >}}/cluster/addons/fluentd-elasticsearch/es-statefulset.yaml) * Increase memory and CPU limits slightly for each of the following addons, if used, along with the size of cluster (there is one replica per node but CPU/memory usage increases slightly along with cluster load/size as well): - * [FluentD with ElasticSearch Plugin](http://releases.k8s.io/{{< param "githubbranch" >}}/cluster/addons/fluentd-elasticsearch/fluentd-es-ds.yaml) - * [FluentD with GCP Plugin](http://releases.k8s.io/{{< param "githubbranch" >}}/cluster/addons/fluentd-gcp/fluentd-gcp-ds.yaml) + * [FluentD with ElasticSearch Plugin](https://releases.k8s.io/{{< param "githubbranch" >}}/cluster/addons/fluentd-elasticsearch/fluentd-es-ds.yaml) + * [FluentD with GCP Plugin](https://releases.k8s.io/{{< param "githubbranch" >}}/cluster/addons/fluentd-gcp/fluentd-gcp-ds.yaml) Heapster's resource limits are set dynamically based on the initial size of your cluster (see [#16185](http://issue.k8s.io/16185) and [#22940](http://issue.k8s.io/22940)). If you find that Heapster is running out of resources, you should adjust the formulas that compute heapster memory request (see those PRs for details). -For directions on how to detect if addon containers are hitting resource limits, see the [Troubleshooting section of Compute Resources](/docs/concepts/configuration/manage-compute-resources-container/#troubleshooting). - -In the [future](http://issue.k8s.io/13048), we anticipate to set all cluster addon resource limits based on cluster size, and to dynamically adjust them if you grow or shrink your cluster. -We welcome PRs that implement those features. +For directions on how to detect if addon containers are hitting resource limits, see the +[Troubleshooting section of Compute Resources](/docs/concepts/configuration/manage-resources-containers/#troubleshooting). ### Allowing minor node failure at startup @@ -126,3 +124,4 @@ running `kube-up.sh` set the environment variable `ALLOWED_NOTREADY_NODES` to wh with. This will allow `kube-up.sh` to succeed with fewer than `NUM_NODES` coming up. Depending on the reason for the failure, those additional nodes may join later or the cluster may remain at a size of `NUM_NODES - ALLOWED_NOTREADY_NODES`. + diff --git a/content/en/docs/setup/best-practices/multiple-zones.md b/content/en/docs/setup/best-practices/multiple-zones.md index ab61c839a9..7c2622641b 100644 --- a/content/en/docs/setup/best-practices/multiple-zones.md +++ b/content/en/docs/setup/best-practices/multiple-zones.md @@ -78,7 +78,7 @@ federation support). a single master node by default. While services are highly available and can tolerate the loss of a zone, the control plane is located in a single zone. Users that want a highly available control -plane should follow the [high availability](/docs/admin/high-availability) instructions. +plane should follow the [high availability](/docs/setup/production-environment/tools/kubeadm/high-availability/) instructions. ### Volume limitations The following limitations are addressed with [topology-aware volume binding](/docs/concepts/storage/storage-classes/#volume-binding-mode). diff --git a/content/en/docs/setup/learning-environment/minikube.md b/content/en/docs/setup/learning-environment/minikube.md index a794141f2d..009be9adc8 100644 --- a/content/en/docs/setup/learning-environment/minikube.md +++ b/content/en/docs/setup/learning-environment/minikube.md @@ -198,7 +198,7 @@ This brief demo guides you on how to start, use, and delete Minikube locally. Fo The `minikube start` command can be used to start your cluster. This command creates and configures a Virtual Machine that runs a single-node Kubernetes cluster. -This command also configures your [kubectl](/docs/user-guide/kubectl-overview/) installation to communicate with this cluster. +This command also configures your [kubectl](/docs/reference/kubectl/overview/) installation to communicate with this cluster. {{< note >}} If you are behind a web proxy, you need to pass this information to the `minikube start` command: @@ -514,6 +514,6 @@ For more information about Minikube, see the [proposal](https://git.k8s.io/commu ## Community -Contributions, questions, and comments are all welcomed and encouraged! Minikube developers hang out on [Slack](https://kubernetes.slack.com) in the #minikube channel (get an invitation [here](http://slack.kubernetes.io/)). We also have the [kubernetes-dev Google Groups mailing list](https://groups.google.com/forum/#!forum/kubernetes-dev). If you are posting to the list please prefix your subject with "minikube: ". +Contributions, questions, and comments are all welcomed and encouraged! Minikube developers hang out on [Slack](https://kubernetes.slack.com) in the `#minikube` channel (get an invitation [here](https://slack.kubernetes.io/)). We also have the [kubernetes-dev Google Groups mailing list](https://groups.google.com/forum/#!forum/kubernetes-dev). If you are posting to the list please prefix your subject with "minikube: ". diff --git a/content/en/docs/setup/production-environment/container-runtimes.md b/content/en/docs/setup/production-environment/container-runtimes.md index 575ac4ba5e..77e7bb577a 100644 --- a/content/en/docs/setup/production-environment/container-runtimes.md +++ b/content/en/docs/setup/production-environment/container-runtimes.md @@ -374,16 +374,19 @@ systemctl restart containerd ## Set up the repository ### Install required packages yum install -y yum-utils device-mapper-persistent-data lvm2 +``` ```shell ## Add docker repository yum-config-manager \ --add-repo \ https://download.docker.com/linux/centos/docker-ce.repo +``` ```shell ## Install containerd yum update -y && yum install -y containerd.io +``` ```shell ## Configure containerd diff --git a/content/en/docs/setup/production-environment/on-premises-vm/cloudstack.md b/content/en/docs/setup/production-environment/on-premises-vm/cloudstack.md index 1f7d1fd81f..c440f14b31 100644 --- a/content/en/docs/setup/production-environment/on-premises-vm/cloudstack.md +++ b/content/en/docs/setup/production-environment/on-premises-vm/cloudstack.md @@ -9,12 +9,10 @@ content_type: concept [CloudStack](https://cloudstack.apache.org/) is a software to build public and private clouds based on hardware virtualization principles (traditional IaaS). To deploy Kubernetes on CloudStack there are several possibilities depending on the Cloud being used and what images are made available. CloudStack also has a vagrant plugin available, hence Vagrant could be used to deploy Kubernetes either using the existing shell provisioner or using new Salt based recipes. -[CoreOS](http://coreos.com) templates for CloudStack are built [nightly](http://stable.release.core-os.net/amd64-usr/current/). CloudStack operators need to [register](http://docs.cloudstack.apache.org/projects/cloudstack-administration/en/latest/templates.html) this template in their cloud before proceeding with these Kubernetes deployment instructions. +[CoreOS](https://coreos.com) templates for CloudStack are built [nightly](https://stable.release.core-os.net/amd64-usr/current/). CloudStack operators need to [register](https://docs.cloudstack.apache.org/projects/cloudstack-administration/en/latest/templates.html) this template in their cloud before proceeding with these Kubernetes deployment instructions. This guide uses a single [Ansible playbook](https://github.com/apachecloudstack/k8s), which is completely automated and can deploy Kubernetes on a CloudStack based Cloud using CoreOS images. The playbook, creates an ssh key pair, creates a security group and associated rules and finally starts coreOS instances configured via cloud-init. - - <!-- body --> ## Prerequisites @@ -112,10 +110,7 @@ e9af8293... <node #2 IP> role=node ## Support Level - IaaS Provider | Config. Mgmt | OS | Networking | Docs | Conforms | Support Level -------------------- | ------------ | ------ | ---------- | --------------------------------------------- | ---------| ---------------------------- CloudStack | Ansible | CoreOS | flannel | [docs](/docs/setup/production-environment/on-premises-vm/cloudstack/) | | Community ([@Guiques](https://github.com/ltupin/)) - - diff --git a/content/en/docs/setup/production-environment/tools/kops.md b/content/en/docs/setup/production-environment/tools/kops.md index 338dbee0e5..8394c28faf 100644 --- a/content/en/docs/setup/production-environment/tools/kops.md +++ b/content/en/docs/setup/production-environment/tools/kops.md @@ -27,7 +27,7 @@ kops is an automated provisioning system: * You must [install](https://github.com/kubernetes/kops#installing) `kops` on a 64-bit (AMD64 and Intel 64) device architecture. -* You must have an [AWS account](https://docs.aws.amazon.com/polly/latest/dg/setting-up.html), generate [IAM keys](https://docs.aws.amazon.com/general/latest/gr/aws-sec-cred-types.html#access-keys-and-secret-access-keys) and [configure](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-configure.html#cli-quick-configuration) them. +* You must have an [AWS account](https://docs.aws.amazon.com/polly/latest/dg/setting-up.html), generate [IAM keys](https://docs.aws.amazon.com/general/latest/gr/aws-sec-cred-types.html#access-keys-and-secret-access-keys) and [configure](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-configure.html#cli-quick-configuration) them. The IAM user will need [adequate permissions](https://github.com/kubernetes/kops/blob/master/docs/getting_started/aws.md#setup-iam-user). @@ -140,7 +140,7 @@ you choose for organization reasons (e.g. you are allowed to create records unde but not under `example.com`). Let's assume you're using `dev.example.com` as your hosted zone. You create that hosted zone using -the [normal process](http://docs.aws.amazon.com/Route53/latest/DeveloperGuide/CreatingNewSubdomain.html), or +the [normal process](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/CreatingNewSubdomain.html), or with a command such as `aws route53 create-hosted-zone --name dev.example.com --caller-reference 1`. You must then set up your NS records in the parent domain, so that records in the domain will resolve. Here, @@ -231,9 +231,8 @@ See the [list of add-ons](/docs/concepts/cluster-administration/addons/) to expl ## {{% heading "whatsnext" %}} -* Learn more about Kubernetes [concepts](/docs/concepts/) and [`kubectl`](/docs/user-guide/kubectl-overview/). +* Learn more about Kubernetes [concepts](/docs/concepts/) and [`kubectl`](/docs/reference/kubectl/overview/). * Learn more about `kops` [advanced usage](https://kops.sigs.k8s.io/) for tutorials, best practices and advanced configuration options. * Follow `kops` community discussions on Slack: [community discussions](https://github.com/kubernetes/kops#other-ways-to-communicate-with-the-contributors) * Contribute to `kops` by addressing or raising an issue [GitHub Issues](https://github.com/kubernetes/kops/issues) - diff --git a/content/en/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm.md b/content/en/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm.md index 2c40d7ec68..82184f7784 100644 --- a/content/en/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm.md +++ b/content/en/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm.md @@ -8,7 +8,7 @@ weight: 30 <!-- overview --> -<img src="https://raw.githubusercontent.com/kubernetes/kubeadm/master/logos/stacked/color/kubeadm-stacked-color.png" align="right" width="150px">The `kubeadm` tool helps you bootstrap a minimum viable Kubernetes cluster that conforms to best practices. In fact, you can use `kubeadm` to set up a cluster that will pass the [Kubernetes Conformance tests](https://kubernetes.io/blog/2017/10/software-conformance-certification). +<img src="https://raw.githubusercontent.com/kubernetes/kubeadm/master/logos/stacked/color/kubeadm-stacked-color.png" align="right" width="150px">The `kubeadm` tool helps you bootstrap a minimum viable Kubernetes cluster that conforms to best practices. In fact, you can use `kubeadm` to set up a cluster that will pass the [Kubernetes Conformance tests](https://kubernetes.io/blog/2017/10/software-conformance-certification). `kubeadm` also supports other cluster lifecycle functions, such as [bootstrap tokens](/docs/reference/access-authn-authz/bootstrap-tokens/) and cluster upgrades. @@ -42,7 +42,7 @@ To follow this guide, you need: You also need to use a version of `kubeadm` that can deploy the version of Kubernetes that you want to use in your new cluster. -[Kubernetes' version and version skew support policy](https://kubernetes.io/docs/setup/release/version-skew-policy/#supported-versions) applies to `kubeadm` as well as to Kubernetes overall. +[Kubernetes' version and version skew support policy](/docs/setup/release/version-skew-policy/#supported-versions) applies to `kubeadm` as well as to Kubernetes overall. Check that policy to learn about what versions of Kubernetes and `kubeadm` are supported. This page is written for Kubernetes {{< param "version" >}}. @@ -254,11 +254,11 @@ Read all of this advice carefully before proceeding. **You must deploy a {{< glossary_tooltip text="Container Network Interface" term_id="cni" >}} -(CNI) based Pod network add-on so that your Pods can communicate with each other. +(CNI) based Pod network add-on so that your Pods can communicate with each other. Cluster DNS (CoreDNS) will not start up before a network is installed.** - Take care that your Pod network must not overlap with any of the host - networks: you are likely to see problems if there is any overlap. + networks: you are likely to see problems if there is any overlap. (If you find a collision between your network plugin’s preferred Pod network and some of your host networks, you should think of a suitable CIDR block to use instead, then use that during `kubeadm init` with @@ -266,13 +266,13 @@ Cluster DNS (CoreDNS) will not start up before a network is installed.** - By default, `kubeadm` sets up your cluster to use and enforce use of [RBAC](/docs/reference/access-authn-authz/rbac/) (role based access - control). + control). Make sure that your Pod network plugin supports RBAC, and so do any manifests that you use to deploy it. - If you want to use IPv6--either dual-stack, or single-stack IPv6 only networking--for your cluster, make sure that your Pod network plugin - supports IPv6. + supports IPv6. IPv6 support was added to CNI in [v0.6.0](https://github.com/containernetworking/cni/releases/tag/v0.6.0). {{< /caution >}} @@ -284,10 +284,10 @@ tracker instead of the kubeadm or kubernetes issue trackers. {{< /note >}} Several external projects provide Kubernetes Pod networks using CNI, some of which also -support [Network Policy](/docs/concepts/services-networking/networkpolicies/). +support [Network Policy](/docs/concepts/services-networking/network-policies/). -See the list of available -[networking and network policy add-ons](https://kubernetes.io/docs/concepts/cluster-administration/addons/#networking-and-network-policy). +See a list of add-ons that implement the +[Kubernetes networking model](/docs/concepts/cluster-administration/networking/#how-to-implement-the-kubernetes-networking-model). You can install a Pod network add-on with the following command on the control-plane node or a node that has the kubeconfig credentials: @@ -297,79 +297,6 @@ kubectl apply -f <add-on.yaml> ``` You can install only one Pod network per cluster. -Below you can find installation instructions for some popular Pod network plugins: - -{{< tabs name="tabs-pod-install" >}} - -{{% tab name="Calico" %}} -[Calico](https://docs.projectcalico.org/latest/introduction/) is a networking and network policy provider. Calico supports a flexible set of networking options so you can choose the most efficient option for your situation, including non-overlay and overlay networks, with or without BGP. Calico uses the same engine to enforce network policy for hosts, pods, and (if using Istio & Envoy) applications at the service mesh layer. Calico works on several architectures, including `amd64`, `arm64`, and `ppc64le`. - -Calico will automatically detect which IP address range to use for pod IPs based on the value provided via the `--pod-network-cidr` flag or via kubeadm's configuration. - -```shell -kubectl apply -f https://docs.projectcalico.org/v3.14/manifests/calico.yaml -``` - -{{% /tab %}} - -{{% tab name="Cilium" %}} - -To deploy Cilium you just need to run: - -```shell -kubectl create -f https://raw.githubusercontent.com/cilium/cilium/v1.8/install/kubernetes/quick-install.yaml -``` - -Once all Cilium Pods are marked as `READY`, you start using your cluster. - -```shell -kubectl get pods -n kube-system --selector=k8s-app=cilium -``` -The output is similar to this: -``` -NAME READY STATUS RESTARTS AGE -cilium-drxkl 1/1 Running 0 18m -``` - -Cilium can be used as a replacement for kube-proxy, see [Kubernetes without kube-proxy](https://docs.cilium.io/en/stable/gettingstarted/kubeproxy-free). - -For more information about using Cilium with Kubernetes, see [Kubernetes Install guide for Cilium](https://docs.cilium.io/en/stable/kubernetes/). - -{{% /tab %}} - -{{% tab name="Contiv-VPP" %}} -[Contiv-VPP](https://contivpp.io/) employs a programmable CNF vSwitch based on [FD.io VPP](https://fd.io/), -offering feature-rich & high-performance cloud-native networking and services. - -It implements k8s services and network policies in the user space (on VPP). - -Please refer to this installation guide: [Contiv-VPP Manual Installation](https://github.com/contiv/vpp/blob/master/docs/setup/MANUAL_INSTALL.md) -{{% /tab %}} - -{{% tab name="Kube-router" %}} - -Kube-router relies on kube-controller-manager to allocate Pod CIDR for the nodes. Therefore, use `kubeadm init` with the `--pod-network-cidr` flag. - -Kube-router provides Pod networking, network policy, and high-performing IP Virtual Server(IPVS)/Linux Virtual Server(LVS) based service proxy. - -For information on using the `kubeadm` tool to set up a Kubernetes cluster with Kube-router, please see the official [setup guide](https://github.com/cloudnativelabs/kube-router/blob/master/docs/kubeadm.md). -{{% /tab %}} - -{{% tab name="Weave Net" %}} - -For more information on setting up your Kubernetes cluster with Weave Net, please see [Integrating Kubernetes via the Addon](https://www.weave.works/docs/net/latest/kube-addon/). - -Weave Net works on `amd64`, `arm`, `arm64` and `ppc64le` platforms without any extra action required. -Weave Net sets hairpin mode by default. This allows Pods to access themselves via their Service IP address -if they don't know their PodIP. - -```shell -kubectl apply -f "https://cloud.weave.works/k8s/net?k8s-version=$(kubectl version | base64 | tr -d '\n')" -``` -{{% /tab %}} - -{{< /tabs >}} - Once a Pod network has been installed, you can confirm that it is working by checking that the CoreDNS Pod is `Running` in the output of `kubectl get pods --all-namespaces`. @@ -531,10 +458,9 @@ Talking to the control-plane node with the appropriate credentials, run: ```bash kubectl drain <node name> --delete-local-data --force --ignore-daemonsets -kubectl delete node <node name> ``` -Then, on the node being removed, reset all `kubeadm` installed state: +Before removing the node, reset the state installed by `kubeadm`: ```bash kubeadm reset @@ -552,6 +478,11 @@ If you want to reset the IPVS tables, you must run the following command: ipvsadm -C ``` +Now remove the node: +```bash +kubectl delete node <node name> +``` + If you wish to start over simply run `kubeadm init` or `kubeadm join` with the appropriate arguments. @@ -574,9 +505,9 @@ options. * <a id="lifecycle" />See [Upgrading kubeadm clusters](/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade/) for details about upgrading your cluster using `kubeadm`. * Learn about advanced `kubeadm` usage in the [kubeadm reference documentation](/docs/reference/setup-tools/kubeadm/kubeadm) -* Learn more about Kubernetes [concepts](/docs/concepts/) and [`kubectl`](/docs/user-guide/kubectl-overview/). +* Learn more about Kubernetes [concepts](/docs/concepts/) and [`kubectl`](/docs/reference/kubectl/overview/). * See the [Cluster Networking](/docs/concepts/cluster-administration/networking/) page for a bigger list -of Pod network add-ons. + of Pod network add-ons. * <a id="other-addons" />See the [list of add-ons](/docs/concepts/cluster-administration/addons/) to explore other add-ons, including tools for logging, monitoring, network policy, visualization & control of your Kubernetes cluster. @@ -640,5 +571,3 @@ supports your chosen platform. ## Troubleshooting {#troubleshooting} If you are running into difficulties with kubeadm, please consult our [troubleshooting docs](/docs/setup/production-environment/tools/kubeadm/troubleshooting-kubeadm/). - - diff --git a/content/en/docs/setup/production-environment/tools/kubeadm/high-availability.md b/content/en/docs/setup/production-environment/tools/kubeadm/high-availability.md index 5584309406..e91e9f7a60 100644 --- a/content/en/docs/setup/production-environment/tools/kubeadm/high-availability.md +++ b/content/en/docs/setup/production-environment/tools/kubeadm/high-availability.md @@ -22,7 +22,7 @@ and environment. [This comparison topic](/docs/setup/production-environment/tool If you encounter issues with setting up the HA cluster, please provide us with feedback in the kubeadm [issue tracker](https://github.com/kubernetes/kubeadm/issues/new). -See also [The upgrade documentation](/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade-1-15). +See also [The upgrade documentation](/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade/). {{< caution >}} This page does not address running your cluster on a cloud provider. In a cloud @@ -30,8 +30,6 @@ environment, neither approach documented here works with Service objects of type LoadBalancer, or with dynamic PersistentVolumes. {{< /caution >}} - - ## {{% heading "prerequisites" %}} @@ -51,8 +49,6 @@ For the external etcd cluster only, you also need: - Three additional machines for etcd members - - <!-- steps --> ## First steps for both methods 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 e06918d7b8..42ab59f4db 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 @@ -54,6 +54,8 @@ route, we recommend you add IP route(s) so Kubernetes cluster addresses go via t ## Letting iptables see bridged traffic +Make sure that the `br_netfilter` module is loaded. This can be done by running `lsmod | grep br_netfilter`. To load it explicitly call `sudo modprobe br_netfilter`. + As a requirement for your Linux Node's iptables to correctly see bridged traffic, you should ensure `net.bridge.bridge-nf-call-iptables` is set to 1 in your `sysctl` config, e.g. ```bash @@ -64,9 +66,7 @@ EOF sudo sysctl --system ``` -Make sure that the `br_netfilter` module is loaded before this step. This can be done by running `lsmod | grep br_netfilter`. To load it explicitly call `sudo modprobe br_netfilter`. - -For more details please see the [Network Plugin Requirements](https://kubernetes.io/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/#network-plugin-requirements) page. +For more details please see the [Network Plugin Requirements](/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/#network-plugin-requirements) page. ## Check required ports @@ -191,7 +191,7 @@ sudo apt-mark hold kubelet kubeadm kubectl {{% /tab %}} {{% tab name="CentOS, RHEL or Fedora" %}} ```bash -cat <<EOF > /etc/yum.repos.d/kubernetes.repo +cat <<EOF | sudo tee /etc/yum.repos.d/kubernetes.repo [kubernetes] name=Kubernetes baseurl=https://packages.cloud.google.com/yum/repos/kubernetes-el7-\$basearch @@ -203,12 +203,12 @@ exclude=kubelet kubeadm kubectl EOF # Set SELinux in permissive mode (effectively disabling it) -setenforce 0 -sed -i 's/^SELINUX=enforcing$/SELINUX=permissive/' /etc/selinux/config +sudo setenforce 0 +sudo sed -i 's/^SELINUX=enforcing$/SELINUX=permissive/' /etc/selinux/config -yum install -y kubelet kubeadm kubectl --disableexcludes=kubernetes +sudo yum install -y kubelet kubeadm kubectl --disableexcludes=kubernetes -systemctl enable --now kubelet +sudo systemctl enable --now kubelet ``` **Notes:** @@ -218,39 +218,43 @@ systemctl enable --now kubelet You have to do this until SELinux support is improved in the kubelet. - You can leave SELinux enabled if you know how to configure it but it may require settings that are not supported by kubeadm. - + {{% /tab %}} -{{% tab name="Container Linux" %}} +{{% tab name="Fedora CoreOS" %}} Install CNI plugins (required for most pod network): ```bash CNI_VERSION="v0.8.2" -mkdir -p /opt/cni/bin -curl -L "https://github.com/containernetworking/plugins/releases/download/${CNI_VERSION}/cni-plugins-linux-amd64-${CNI_VERSION}.tgz" | tar -C /opt/cni/bin -xz +sudo mkdir -p /opt/cni/bin +curl -L "https://github.com/containernetworking/plugins/releases/download/${CNI_VERSION}/cni-plugins-linux-amd64-${CNI_VERSION}.tgz" | sudo tar -C /opt/cni/bin -xz +``` + +Define the directory to download command files + +```bash +DOWNLOAD_DIR=/usr/local/bin +sudo mkdir -p $DOWNLOAD_DIR ``` Install crictl (required for kubeadm / Kubelet Container Runtime Interface (CRI)) ```bash CRICTL_VERSION="v1.17.0" -mkdir -p /opt/bin -curl -L "https://github.com/kubernetes-sigs/cri-tools/releases/download/${CRICTL_VERSION}/crictl-${CRICTL_VERSION}-linux-amd64.tar.gz" | tar -C /opt/bin -xz +curl -L "https://github.com/kubernetes-sigs/cri-tools/releases/download/${CRICTL_VERSION}/crictl-${CRICTL_VERSION}-linux-amd64.tar.gz" | sudo tar -C $DOWNLOAD_DIR -xz ``` Install `kubeadm`, `kubelet`, `kubectl` and add a `kubelet` systemd service: ```bash RELEASE="$(curl -sSL https://dl.k8s.io/release/stable.txt)" - -mkdir -p /opt/bin -cd /opt/bin -curl -L --remote-name-all https://storage.googleapis.com/kubernetes-release/release/${RELEASE}/bin/linux/amd64/{kubeadm,kubelet,kubectl} -chmod +x {kubeadm,kubelet,kubectl} +cd $DOWNLOAD_DIR +sudo curl -L --remote-name-all https://storage.googleapis.com/kubernetes-release/release/${RELEASE}/bin/linux/amd64/{kubeadm,kubelet,kubectl} +sudo chmod +x {kubeadm,kubelet,kubectl} RELEASE_VERSION="v0.2.7" -curl -sSL "https://raw.githubusercontent.com/kubernetes/release/${RELEASE_VERSION}/cmd/kubepkg/templates/latest/deb/kubelet/lib/systemd/system/kubelet.service" | sed "s:/usr/bin:/opt/bin:g" > /etc/systemd/system/kubelet.service -mkdir -p /etc/systemd/system/kubelet.service.d -curl -sSL "https://raw.githubusercontent.com/kubernetes/release/${RELEASE_VERSION}/cmd/kubepkg/templates/latest/deb/kubeadm/10-kubeadm.conf" | sed "s:/usr/bin:/opt/bin:g" > /etc/systemd/system/kubelet.service.d/10-kubeadm.conf +curl -sSL "https://raw.githubusercontent.com/kubernetes/release/${RELEASE_VERSION}/cmd/kubepkg/templates/latest/deb/kubelet/lib/systemd/system/kubelet.service" | sed "s:/usr/bin:${DOWNLOAD_DIR}:g" | sudo tee /etc/systemd/system/kubelet.service +sudo mkdir -p /etc/systemd/system/kubelet.service.d +curl -sSL "https://raw.githubusercontent.com/kubernetes/release/${RELEASE_VERSION}/cmd/kubepkg/templates/latest/deb/kubeadm/10-kubeadm.conf" | sed "s:/usr/bin:${DOWNLOAD_DIR}:g" | sudo tee /etc/systemd/system/kubelet.service.d/10-kubeadm.conf ``` Enable and start `kubelet`: @@ -270,7 +274,7 @@ kubeadm to tell it what to do. When using Docker, kubeadm will automatically detect the cgroup driver for the kubelet and set it in the `/var/lib/kubelet/config.yaml` file during runtime. -If you are using a different CRI, you have to modify the file with your `cgroupDriver` value, like so: +If you are using a different CRI, you must pass your `cgroupDriver` value to `kubeadm init`, like so: ```yaml apiVersion: kubelet.config.k8s.io/v1beta1 @@ -278,6 +282,8 @@ kind: KubeletConfiguration cgroupDriver: <value> ``` +For further details, please read [Using kubeadm init with a configuration file](/docs/reference/setup-tools/kubeadm/kubeadm-init/#config-file). + Please mind, that you **only** have to do that if the cgroup driver of your CRI is not `cgroupfs`, because that is the default value in the kubelet already. @@ -306,4 +312,3 @@ If you are running into difficulties with kubeadm, please consult our [troublesh * [Using kubeadm to Create a Cluster](/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm/) - diff --git a/content/en/docs/setup/production-environment/tools/kubeadm/kubelet-integration.md b/content/en/docs/setup/production-environment/tools/kubeadm/kubelet-integration.md index 3ebc31828d..af4eb4a101 100644 --- a/content/en/docs/setup/production-environment/tools/kubeadm/kubelet-integration.md +++ b/content/en/docs/setup/production-environment/tools/kubeadm/kubelet-integration.md @@ -198,9 +198,8 @@ The DEB and RPM packages shipped with the Kubernetes releases are: | Package name | Description | |--------------|-------------| | `kubeadm` | Installs the `/usr/bin/kubeadm` CLI tool and the [kubelet drop-in file](#the-kubelet-drop-in-file-for-systemd) for the kubelet. | -| `kubelet` | Installs the `/usr/bin/kubelet` binary. | +| `kubelet` | Installs the kubelet binary in `/usr/bin` and CNI binaries in `/opt/cni/bin`. | | `kubectl` | Installs the `/usr/bin/kubectl` binary. | -| `kubernetes-cni` | Installs the official CNI binaries into the `/opt/cni/bin` directory. | | `cri-tools` | Installs the `/usr/bin/crictl` binary from the [cri-tools git repository](https://github.com/kubernetes-incubator/cri-tools). | diff --git a/content/en/docs/setup/production-environment/tools/kubeadm/self-hosting.md b/content/en/docs/setup/production-environment/tools/kubeadm/self-hosting.md index 334e2266f2..d860a88bdd 100644 --- a/content/en/docs/setup/production-environment/tools/kubeadm/self-hosting.md +++ b/content/en/docs/setup/production-environment/tools/kubeadm/self-hosting.md @@ -13,14 +13,12 @@ weight: 100 kubeadm allows you to experimentally create a _self-hosted_ Kubernetes control plane. This means that key components such as the API server, controller manager, and scheduler run as [DaemonSet pods](/docs/concepts/workloads/controllers/daemonset/) -configured via the Kubernetes API instead of [static pods](/docs/tasks/administer-cluster/static-pod/) +configured via the Kubernetes API instead of [static pods](/docs/tasks/configure-pod-container/static-pod/) configured in the kubelet via static files. To create a self-hosted cluster see the [kubeadm alpha selfhosting pivot](/docs/reference/setup-tools/kubeadm/kubeadm-alpha/#cmd-selfhosting) command. - - <!-- body --> #### Caveats diff --git a/content/en/docs/setup/production-environment/tools/kubeadm/setup-ha-etcd-with-kubeadm.md b/content/en/docs/setup/production-environment/tools/kubeadm/setup-ha-etcd-with-kubeadm.md index 739b405d14..b707828cc9 100644 --- a/content/en/docs/setup/production-environment/tools/kubeadm/setup-ha-etcd-with-kubeadm.md +++ b/content/en/docs/setup/production-environment/tools/kubeadm/setup-ha-etcd-with-kubeadm.md @@ -23,22 +23,18 @@ becoming unavailable. This task walks through the process of creating a high availability etcd cluster of three members that can be used as an external etcd when using kubeadm to set up a kubernetes cluster. - - ## {{% heading "prerequisites" %}} - * Three hosts that can talk to each other over ports 2379 and 2380. This document assumes these default ports. However, they are configurable through the kubeadm config file. -* Each host must [have docker, kubelet, and kubeadm installed][toolbox]. +* Each host must [have docker, kubelet, and kubeadm installed](/docs/setup/production-environment/tools/kubeadm/install-kubeadm/). +* Each host should have access to the Kubernetes container image registry (`k8s.gcr.io`) or list/pull the required etcd image using +`kubeadm config images list/pull`. This guide will setup etcd instances as +[static pods](/docs/tasks/configure-pod-container/static-pod/) managed by a kubelet. * Some infrastructure to copy files between hosts. For example `ssh` and `scp` can satisfy this requirement. -[toolbox]: /docs/setup/production-environment/tools/kubeadm/install-kubeadm/ - - - <!-- steps --> ## Setting up the cluster diff --git a/content/en/docs/setup/production-environment/tools/kubeadm/troubleshooting-kubeadm.md b/content/en/docs/setup/production-environment/tools/kubeadm/troubleshooting-kubeadm.md index a4d6d54cc2..82ceef4696 100644 --- a/content/en/docs/setup/production-environment/tools/kubeadm/troubleshooting-kubeadm.md +++ b/content/en/docs/setup/production-environment/tools/kubeadm/troubleshooting-kubeadm.md @@ -15,11 +15,10 @@ If your problem is not listed below, please follow the following steps: - Go to [github.com/kubernetes/kubeadm](https://github.com/kubernetes/kubeadm/issues) and search for existing issues. - If no issue exists, please [open one](https://github.com/kubernetes/kubeadm/issues/new) and follow the issue template. -- If you are unsure about how kubeadm works, you can ask on [Slack](http://slack.k8s.io/) in #kubeadm, or open a question on [StackOverflow](https://stackoverflow.com/questions/tagged/kubernetes). Please include +- If you are unsure about how kubeadm works, you can ask on [Slack](https://slack.k8s.io/) in `#kubeadm`, + or open a question on [StackOverflow](https://stackoverflow.com/questions/tagged/kubernetes). Please include relevant tags like `#kubernetes` and `#kubeadm` so folks can help you. - - <!-- body --> ## Not possible to join a v1.18 Node to a v1.17 cluster due to missing RBAC @@ -404,4 +403,8 @@ nodeRegistration: Alternatively, you can modify `/etc/fstab` to make the `/usr` mount writeable, but please be advised that this is modifying a design principle of the Linux distribution. +## `kubeadm upgrade plan` prints out `context deadline exceeded` error message +This error message is shown when upgrading a Kubernetes cluster with `kubeadm` in the case of running an external etcd. This is not a critical bug and happens because older versions of kubeadm perform a version check on the external etcd cluster. You can proceed with `kubeadm upgrade apply ...`. + +This issue is fixed as of version 1.19. \ No newline at end of file diff --git a/content/en/docs/setup/production-environment/tools/kubespray.md b/content/en/docs/setup/production-environment/tools/kubespray.md index 07c0b3c574..02d99d926a 100644 --- a/content/en/docs/setup/production-environment/tools/kubespray.md +++ b/content/en/docs/setup/production-environment/tools/kubespray.md @@ -8,7 +8,7 @@ weight: 30 This quickstart helps to install a Kubernetes cluster hosted on GCE, Azure, OpenStack, AWS, vSphere, Packet (bare metal), Oracle Cloud Infrastructure (Experimental) or Baremetal with [Kubespray](https://github.com/kubernetes-sigs/kubespray). -Kubespray is a composition of [Ansible](http://docs.ansible.com/) playbooks, [inventory](https://github.com/kubernetes-sigs/kubespray/blob/master/docs/ansible.md), provisioning tools, and domain knowledge for generic OS/Kubernetes clusters configuration management tasks. Kubespray provides: +Kubespray is a composition of [Ansible](https://docs.ansible.com/) playbooks, [inventory](https://github.com/kubernetes-sigs/kubespray/blob/master/docs/ansible.md), provisioning tools, and domain knowledge for generic OS/Kubernetes clusters configuration management tasks. Kubespray provides: * a highly available cluster * composable attributes @@ -21,9 +21,8 @@ Kubespray is a composition of [Ansible](http://docs.ansible.com/) playbooks, [in * openSUSE Leap 15 * continuous integration tests -To choose a tool which best fits your use case, read [this comparison](https://github.com/kubernetes-sigs/kubespray/blob/master/docs/comparisons.md) to [kubeadm](/docs/admin/kubeadm/) and [kops](/docs/setup/production-environment/tools/kops/). - - +To choose a tool which best fits your use case, read [this comparison](https://github.com/kubernetes-sigs/kubespray/blob/master/docs/comparisons.md) to +[kubeadm](/docs/reference/setup-tools/kubeadm/kubeadm/) and [kops](/docs/setup/production-environment/tools/kops/). <!-- body --> @@ -35,7 +34,7 @@ Provision servers with the following [requirements](https://github.com/kubernete * **Ansible v2.7.8 and python-netaddr is installed on the machine that will run Ansible commands** * **Jinja 2.9 (or newer) is required to run the Ansible Playbooks** -* The target servers must have access to the Internet in order to pull docker images. Otherwise, additional configuration is required ([See Offline Environment](https://github.com/kubernetes-sigs/kubespray/blob/master/docs/downloads.md#offline-environment)) +* The target servers must have access to the Internet in order to pull docker images. Otherwise, additional configuration is required ([See Offline Environment](https://github.com/kubernetes-sigs/kubespray/blob/master/docs/offline-environment.md)) * The target servers are configured to allow **IPv4 forwarding** * **Your ssh key must be copied** to all the servers part of your inventory * The **firewalls are not managed**, you'll need to implement your own rules the way you used to. in order to avoid any issue during deployment you should disable your firewall @@ -50,7 +49,7 @@ Kubespray provides the following utilities to help provision your environment: ### (2/5) Compose an inventory file -After you provision your servers, create an [inventory file for Ansible](http://docs.ansible.com/ansible/intro_inventory.html). You can do this manually or via a dynamic inventory script. For more information, see "[Building your own inventory](https://github.com/kubernetes-sigs/kubespray/blob/master/docs/getting-started.md#building-your-own-inventory)". +After you provision your servers, create an [inventory file for Ansible](https://docs.ansible.com/ansible/intro_inventory.html). You can do this manually or via a dynamic inventory script. For more information, see "[Building your own inventory](https://github.com/kubernetes-sigs/kubespray/blob/master/docs/getting-started.md#building-your-own-inventory)". ### (3/5) Plan your cluster deployment @@ -68,7 +67,7 @@ Kubespray provides the ability to customize many aspects of the deployment: * {{< glossary_tooltip term_id="cri-o" >}} * Certificate generation methods -Kubespray customizations can be made to a [variable file](http://docs.ansible.com/ansible/playbooks_variables.html). If you are just getting started with Kubespray, consider using the Kubespray defaults to deploy your cluster and explore Kubernetes. +Kubespray customizations can be made to a [variable file](https://docs.ansible.com/ansible/playbooks_variables.html). If you are just getting started with Kubespray, consider using the Kubespray defaults to deploy your cluster and explore Kubernetes. ### (4/5) Deploy a Cluster @@ -110,11 +109,9 @@ When running the reset playbook, be sure not to accidentally target your product ## Feedback -* Slack Channel: [#kubespray](https://kubernetes.slack.com/messages/kubespray/) (You can get your invite [here](http://slack.k8s.io/)) +* Slack Channel: [#kubespray](https://kubernetes.slack.com/messages/kubespray/) (You can get your invite [here](https://slack.k8s.io/)) * [GitHub Issues](https://github.com/kubernetes-sigs/kubespray/issues) - - ## {{% heading "whatsnext" %}} diff --git a/content/en/docs/setup/production-environment/turnkey/aws.md b/content/en/docs/setup/production-environment/turnkey/aws.md index 92dd18075c..be75623158 100644 --- a/content/en/docs/setup/production-environment/turnkey/aws.md +++ b/content/en/docs/setup/production-environment/turnkey/aws.md @@ -23,9 +23,7 @@ To create a Kubernetes cluster on AWS, you will need an Access Key ID and a Secr * [Kubernetes Operations](https://github.com/kubernetes/kops) - Production Grade K8s Installation, Upgrades, and Management. Supports running Debian, Ubuntu, CentOS, and RHEL in AWS. -* [CoreOS Tectonic](https://coreos.com/tectonic/) includes the open-source [Tectonic Installer](https://github.com/coreos/tectonic-installer) that creates Kubernetes clusters with Container Linux nodes on AWS. - -* CoreOS originated and the Kubernetes Incubator maintains [a CLI tool, kube-aws](https://github.com/kubernetes-incubator/kube-aws), that creates and manages Kubernetes clusters with [Container Linux](https://coreos.com/why/) nodes, using AWS tools: EC2, CloudFormation and Autoscaling. +* [kube-aws](https://github.com/kubernetes-incubator/kube-aws), creates and manages Kubernetes clusters with [Flatcar Linux](https://www.flatcar-linux.org/) nodes, using AWS tools: EC2, CloudFormation and Autoscaling. * [KubeOne](https://github.com/kubermatic/kubeone) is an open source cluster lifecycle management tool that creates, upgrades and manages Kubernetes Highly-Available clusters. @@ -50,7 +48,7 @@ export PATH=<path/to/kubernetes-directory>/platforms/darwin/amd64:$PATH export PATH=<path/to/kubernetes-directory>/platforms/linux/amd64:$PATH ``` -An up-to-date documentation page for this tool is available here: [kubectl manual](/docs/user-guide/kubectl/) +An up-to-date documentation page for this tool is available here: [kubectl manual](/docs/reference/kubectl/kubectl/) By default, `kubectl` will use the `kubeconfig` file generated during the cluster startup for authenticating against the API. For more information, please read [kubeconfig files](/docs/tasks/access-application-cluster/configure-access-multiple-clusters/) @@ -65,7 +63,8 @@ For more complete applications, please look in the [examples directory](https:// ## Scaling the cluster -Adding and removing nodes through `kubectl` is not supported. You can still scale the amount of nodes manually through adjustments of the 'Desired' and 'Max' properties within the [Auto Scaling Group](http://docs.aws.amazon.com/autoscaling/latest/userguide/as-manual-scaling.html), which was created during the installation. +Adding and removing nodes through `kubectl` is not supported. You can still scale the amount of nodes manually through adjustments of the 'Desired' and 'Max' properties within the +[Auto Scaling Group](https://docs.aws.amazon.com/autoscaling/latest/userguide/as-manual-scaling.html), which was created during the installation. ## Tearing down the cluster @@ -82,13 +81,8 @@ cluster/kube-down.sh IaaS Provider | Config. Mgmt | OS | Networking | Docs | Conforms | Support Level -------------------- | ------------ | ------------- | ---------- | --------------------------------------------- | ---------| ---------------------------- AWS | kops | Debian | k8s (VPC) | [docs](https://github.com/kubernetes/kops) | | Community ([@justinsb](https://github.com/justinsb)) -AWS | CoreOS | CoreOS | flannel | [docs](/docs/getting-started-guides/aws) | | Community -AWS | Juju | Ubuntu | flannel, calico, canal | [docs](/docs/getting-started-guides/ubuntu) | 100% | Commercial, Community +AWS | CoreOS | CoreOS | flannel | - | | Community +AWS | Juju | Ubuntu | flannel, calico, canal | - | 100% | Commercial, Community AWS | KubeOne | Ubuntu, CoreOS, CentOS | canal, weavenet | [docs](https://github.com/kubermatic/kubeone) | 100% | Commercial, Community -## Further reading - -Please see the [Kubernetes docs](/docs/) for more details on administering -and using a Kubernetes cluster. - diff --git a/content/en/docs/setup/production-environment/turnkey/gce.md b/content/en/docs/setup/production-environment/turnkey/gce.md index 60c4e690d9..78386161a6 100644 --- a/content/en/docs/setup/production-environment/turnkey/gce.md +++ b/content/en/docs/setup/production-environment/turnkey/gce.md @@ -72,7 +72,7 @@ cluster/kube-up.sh If you want more than one cluster running in your project, want to use a different name, or want a different number of worker nodes, see the `<kubernetes>/cluster/gce/config-default.sh` file for more fine-grained configuration before you start up your cluster. If you run into trouble, please see the section on [troubleshooting](/docs/setup/production-environment/turnkey/gce/#troubleshooting), post to the -[Kubernetes Forum](https://discuss.kubernetes.io), or come ask questions on [Slack](/docs/troubleshooting/#slack). +[Kubernetes Forum](https://discuss.kubernetes.io), or come ask questions on `#gke` Slack channel. The next few steps will show you: @@ -85,7 +85,7 @@ The next few steps will show you: The cluster startup script will leave you with a running cluster and a `kubernetes` directory on your workstation. -The [kubectl](/docs/user-guide/kubectl/) tool controls the Kubernetes cluster +The [kubectl](/docs/reference/kubectl/kubectl/) tool controls the Kubernetes cluster manager. It lets you inspect your cluster resources, create, delete, and update components, and much more. You will use it to look at your new cluster and bring up example apps. @@ -98,7 +98,7 @@ gcloud components install kubectl {{< note >}} The kubectl version bundled with `gcloud` may be older than the one -downloaded by the get.k8s.io install script. See [Installing kubectl](/docs/tasks/kubectl/install/) +downloaded by the get.k8s.io install script. See [Installing kubectl](/docs/tasks/tools/install-kubectl/) document to see how you can set up the latest `kubectl` on your workstation. {{< /note >}} @@ -112,7 +112,7 @@ Once `kubectl` is in your path, you can use it to look at your cluster. E.g., ru kubectl get --all-namespaces services ``` -should show a set of [services](/docs/user-guide/services) that look something like this: +should show a set of [services](/docs/concepts/services-networking/service/) that look something like this: ```shell NAMESPACE NAME TYPE CLUSTER_IP EXTERNAL_IP PORT(S) AGE @@ -122,7 +122,7 @@ kube-system kube-ui ClusterIP 10.0.0.3 <none> ... ``` -Similarly, you can take a look at the set of [pods](/docs/user-guide/pods) that were created during cluster startup. +Similarly, you can take a look at the set of [pods](/docs/concepts/workloads/pods/) that were created during cluster startup. You can do this via the ```shell @@ -149,7 +149,7 @@ Some of the pods may take a few seconds to start up (during this time they'll sh ### Run some examples -Then, see [a simple nginx example](/docs/user-guide/simple-nginx) to try out your new cluster. +Then, see [a simple nginx example](/docs/tasks/run-application/run-stateless-application-deployment/) to try out your new cluster. For more complete applications, please look in the [examples directory](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/). The [guestbook example](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/guestbook/) is a good "getting started" walkthrough. @@ -221,9 +221,3 @@ IaaS Provider | Config. Mgmt | OS | Networking | Docs GCE | Saltstack | Debian | GCE | [docs](/docs/setup/production-environment/turnkey/gce/) | | Project -## Further reading - -Please see the [Kubernetes docs](/docs/) for more details on administering -and using a Kubernetes cluster. - - diff --git a/content/en/docs/setup/production-environment/windows/intro-windows-in-kubernetes.md b/content/en/docs/setup/production-environment/windows/intro-windows-in-kubernetes.md index 09a74d1450..0192cfeb5e 100644 --- a/content/en/docs/setup/production-environment/windows/intro-windows-in-kubernetes.md +++ b/content/en/docs/setup/production-environment/windows/intro-windows-in-kubernetes.md @@ -17,7 +17,7 @@ Windows applications constitute a large portion of the services and applications ## Windows containers in Kubernetes -To enable the orchestration of Windows containers in Kubernetes, simply include Windows nodes in your existing Linux cluster. Scheduling Windows containers in [Pods](/docs/concepts/workloads/pods/pod-overview/) on Kubernetes is as simple and easy as scheduling Linux-based containers. +To enable the orchestration of Windows containers in Kubernetes, simply include Windows nodes in your existing Linux cluster. Scheduling Windows containers in {{< glossary_tooltip text="Pods" term_id="pod" >}} on Kubernetes is as simple and easy as scheduling Linux-based containers. In order to run Windows containers, your Kubernetes cluster must include multiple operating systems, with control plane nodes running Linux and workers running either Windows or Linux depending on your workload needs. Windows Server 2019 is the only Windows operating system supported, enabling [Kubernetes Node](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/architecture/architecture.md#the-kubernetes-node) on Windows (including kubelet, [container runtime](https://docs.microsoft.com/en-us/virtualization/windowscontainers/deploy-containers/containerd), and kube-proxy). For a detailed explanation of Windows distribution channels see the [Microsoft documentation](https://docs.microsoft.com/en-us/windows-server/get-started-19/servicing-channels-19). @@ -56,7 +56,7 @@ Windows containers with process isolation have strict compatibility rules, [wher Key Kubernetes elements work the same way in Windows as they do in Linux. In this section, we talk about some of the key workload enablers and how they map to Windows. -* [Pods](/docs/concepts/workloads/pods/pod-overview/) +* [Pods](/docs/concepts/workloads/pods/) A Pod is the basic building block of Kubernetes–the smallest and simplest unit in the Kubernetes object model that you create or deploy. You may not deploy Windows and Linux containers in the same Pod. All containers in a Pod are scheduled onto a single Node where each Node represents a specific platform and architecture. The following Pod capabilities, properties and events are supported with Windows containers: diff --git a/content/en/docs/setup/release/notes.md b/content/en/docs/setup/release/notes.md index d80d6c0ffd..8bc87867bc 100644 --- a/content/en/docs/setup/release/notes.md +++ b/content/en/docs/setup/release/notes.md @@ -63,11 +63,9 @@ filename | sha512 hash ## Changelog since v1.17.0 A complete changelog for the release notes is now hosted in a customizable -format at [https://relnotes.k8s.io][1]. Check it out and please give us your +format at [https://relnotes.k8s.io](https://relnotes.k8s.io/?releaseVersions=1.18.0). Check it out and please give us your feedback! -[1]: https://relnotes.k8s.io/?releaseVersions=1.18.0 - ## What’s New (Major Themes) ### Kubernetes Topology Manager Moves to Beta - Align Up! @@ -80,13 +78,13 @@ Server-side Apply was promoted to Beta in 1.16, but is now introducing a second ### Extending Ingress with and replacing a deprecated annotation with IngressClass -In Kubernetes 1.18, there are two significant additions to Ingress: A new `pathType` field and a new `IngressClass` resource. The `pathType` field allows specifying how paths should be matched. In addition to the default `ImplementationSpecific` type, there are new `Exact` and `Prefix` path types. +In Kubernetes 1.18, there are two significant additions to Ingress: A new `pathType` field and a new `IngressClass` resource. The `pathType` field allows specifying how paths should be matched. In addition to the default `ImplementationSpecific` type, there are new `Exact` and `Prefix` path types. The `IngressClass` resource is used to describe a type of Ingress within a Kubernetes cluster. Ingresses can specify the class they are associated with by using a new `ingressClassName` field on Ingresses. This new resource and field replace the deprecated `kubernetes.io/ingress.class` annotation. ### SIG CLI introduces kubectl debug -SIG CLI was debating the need for a debug utility for quite some time already. With the development of [ephemeral containers](https://kubernetes.io/docs/concepts/workloads/pods/ephemeral-containers/), it became more obvious how we can support developers with tooling built on top of `kubectl exec`. The addition of the `kubectl debug` [command](https://github.com/kubernetes/enhancements/blob/master/keps/sig-cli/20190805-kubectl-debug.md) (it is alpha but your feedback is more than welcome), allows developers to easily debug their Pods inside the cluster. We think this addition is invaluable. This command allows one to create a temporary container which runs next to the Pod one is trying to examine, but also attaches to the console for interactive troubleshooting. +SIG CLI was debating the need for a debug utility for quite some time already. With the development of [ephemeral containers](/docs/concepts/workloads/pods/ephemeral-containers/), it became more obvious how we can support developers with tooling built on top of `kubectl exec`. The addition of the `kubectl debug` [command](https://github.com/kubernetes/enhancements/blob/master/keps/sig-cli/20190805-kubectl-debug.md) (it is alpha but your feedback is more than welcome), allows developers to easily debug their Pods inside the cluster. We think this addition is invaluable. This command allows one to create a temporary container which runs next to the Pod one is trying to examine, but also attaches to the console for interactive troubleshooting. ### Introducing Windows CSI support alpha for Kubernetes @@ -126,7 +124,7 @@ No Known Issues Reported #### kubectl: - `kubectl` and k8s.io/client-go no longer default to a server address of `http://localhost:8080`. If you own one of these legacy clusters, you are *strongly* encouraged to secure your server. If you cannot secure your server, you can set the `$KUBERNETES_MASTER` environment variable to `http://localhost:8080` to continue defaulting the server address. `kubectl` users can also set the server address using the `--server` flag, or in a kubeconfig file specified via `--kubeconfig` or `$KUBECONFIG`. ([#86173](https://github.com/kubernetes/kubernetes/pull/86173), [@soltysh](https://github.com/soltysh)) [SIG API Machinery, CLI and Testing] -- `kubectl run` has removed the previously deprecated generators, along with flags unrelated to creating pods. `kubectl run` now only creates pods. See specific `kubectl create` subcommands to create objects other than pods. +- `kubectl run` has removed the previously deprecated generators, along with flags unrelated to creating pods. `kubectl run` now only creates pods. See specific `kubectl create` subcommands to create objects other than pods. ([#87077](https://github.com/kubernetes/kubernetes/pull/87077), [@soltysh](https://github.com/soltysh)) [SIG Architecture, CLI and Testing] - The deprecated command `kubectl rolling-update` has been removed ([#88057](https://github.com/kubernetes/kubernetes/pull/88057), [@julianvmodesto](https://github.com/julianvmodesto)) [SIG Architecture, CLI and Testing] @@ -193,13 +191,13 @@ No Known Issues Reported - node_memory_working_set_bytes --> node_memory_working_set_bytes - container_cpu_usage_seconds_total --> container_cpu_usage_seconds - container_memory_working_set_bytes --> container_memory_working_set_bytes - - scrape_error --> scrape_error + - scrape_error --> scrape_error ([#86282](https://github.com/kubernetes/kubernetes/pull/86282), [@RainbowMango](https://github.com/RainbowMango)) [SIG Node] - In a future release, kubelet will no longer create the CSI NodePublishVolume target directory, in accordance with the CSI specification. CSI drivers may need to be updated accordingly to properly create and process the target path. ([#75535](https://github.com/kubernetes/kubernetes/issues/75535)) [SIG Storage] #### kube-proxy: - `--healthz-port` and `--metrics-port` flags are deprecated, please use `--healthz-bind-address` and `--metrics-bind-address` instead ([#88512](https://github.com/kubernetes/kubernetes/pull/88512), [@SataQiu](https://github.com/SataQiu)) [SIG Network] -- a new `EndpointSliceProxying` feature gate has been added to control the use of EndpointSlices in kube-proxy. The EndpointSlice feature gate that used to control this behavior no longer affects kube-proxy. This feature has been disabled by default. ([#86137](https://github.com/kubernetes/kubernetes/pull/86137), [@robscott](https://github.com/robscott)) +- a new `EndpointSliceProxying` feature gate has been added to control the use of EndpointSlices in kube-proxy. The EndpointSlice feature gate that used to control this behavior no longer affects kube-proxy. This feature has been disabled by default. ([#86137](https://github.com/kubernetes/kubernetes/pull/86137), [@robscott](https://github.com/robscott)) #### kubeadm: - command line option "kubelet-version" for `kubeadm upgrade node` has been deprecated and will be removed in a future release. ([#87942](https://github.com/kubernetes/kubernetes/pull/87942), [@SataQiu](https://github.com/SataQiu)) [SIG Cluster Lifecycle] @@ -245,7 +243,7 @@ No Known Issues Reported - The alpha feature `ServiceAccountIssuerDiscovery` enables publishing OIDC discovery information and service account token verification keys at `/.well-known/openid-configuration` and `/openid/v1/jwks` endpoints by API servers configured to issue service account tokens. ([#80724](https://github.com/kubernetes/kubernetes/pull/80724), [@cceckman](https://github.com/cceckman)) [SIG API Machinery, Auth, Cluster Lifecycle and Testing] - CustomResourceDefinition schemas that use `x-kubernetes-list-map-keys` to specify properties that uniquely identify list items must make those properties required or have a default value, to ensure those properties are present for all list items. See https://kubernetes.io/docs/reference/using-api/api-concepts/#merge-strategy for details. ([#88076](https://github.com/kubernetes/kubernetes/pull/88076), [@eloyekunle](https://github.com/eloyekunle)) [SIG API Machinery and Testing] - CustomResourceDefinition schemas that use `x-kubernetes-list-type: map` or `x-kubernetes-list-type: set` now enable validation that the list items in the corresponding custom resources are unique. ([#84920](https://github.com/kubernetes/kubernetes/pull/84920), [@sttts](https://github.com/sttts)) [SIG API Machinery] - + #### Configuration file changes: #### kube-apiserver: @@ -257,7 +255,7 @@ No Known Issues Reported - Kube-scheduler can run more than one scheduling profile. Given a pod, the profile is selected by using its `.spec.schedulerName`. ([#88285](https://github.com/kubernetes/kubernetes/pull/88285), [@alculquicondor](https://github.com/alculquicondor)) [SIG Apps, Scheduling and Testing] - Scheduler Extenders can now be configured in the v1alpha2 component config ([#88768](https://github.com/kubernetes/kubernetes/pull/88768), [@damemi](https://github.com/damemi)) [SIG Release, Scheduling and Testing] - The PostFilter of scheduler framework is renamed to PreScore in kubescheduler.config.k8s.io/v1alpha2. ([#87751](https://github.com/kubernetes/kubernetes/pull/87751), [@skilxn-go](https://github.com/skilxn-go)) [SIG Scheduling and Testing] - + #### kube-proxy: - Added kube-proxy flags `--ipvs-tcp-timeout`, `--ipvs-tcpfin-timeout`, `--ipvs-udp-timeout` to configure IPVS connection timeouts. ([#85517](https://github.com/kubernetes/kubernetes/pull/85517), [@andrewsykim](https://github.com/andrewsykim)) [SIG Cluster Lifecycle and Network] - Added optional `--detect-local-mode` flag to kube-proxy. Valid values are "ClusterCIDR" (default matching previous behavior) and "NodeCIDR" ([#87748](https://github.com/kubernetes/kubernetes/pull/87748), [@satyasm](https://github.com/satyasm)) [SIG Cluster Lifecycle, Network and Scheduling] @@ -689,8 +687,8 @@ filename | sha512 hash - Add `rest_client_rate_limiter_duration_seconds` metric to component-base to track client side rate limiter latency in seconds. Broken down by verb and URL. ([#88134](https://github.com/kubernetes/kubernetes/pull/88134), [@jennybuckley](https://github.com/jennybuckley)) [SIG API Machinery, Cluster Lifecycle and Instrumentation] - Allow user to specify resource using --filename flag when invoking kubectl exec ([#88460](https://github.com/kubernetes/kubernetes/pull/88460), [@soltysh](https://github.com/soltysh)) [SIG CLI and Testing] -- Apiserver add a new flag --goaway-chance which is the fraction of requests that will be closed gracefully(GOAWAY) to prevent HTTP/2 clients from getting stuck on a single apiserver. - After the connection closed(received GOAWAY), the client's other in-flight requests won't be affected, and the client will reconnect. +- Apiserver add a new flag --goaway-chance which is the fraction of requests that will be closed gracefully(GOAWAY) to prevent HTTP/2 clients from getting stuck on a single apiserver. + After the connection closed(received GOAWAY), the client's other in-flight requests won't be affected, and the client will reconnect. The flag min value is 0 (off), max is .02 (1/50 requests); .001 (1/1000) is a recommended starting point. Clusters with single apiservers, or which don't use a load balancer, should NOT enable this. ([#88567](https://github.com/kubernetes/kubernetes/pull/88567), [@answer1991](https://github.com/answer1991)) [SIG API Machinery] - Azure: add support for single stack IPv6 ([#88448](https://github.com/kubernetes/kubernetes/pull/88448), [@aramase](https://github.com/aramase)) [SIG Cloud Provider] @@ -739,7 +737,7 @@ filename | sha512 hash - Kubelets perform fewer unnecessary pod status update operations on the API server. ([#88591](https://github.com/kubernetes/kubernetes/pull/88591), [@smarterclayton](https://github.com/smarterclayton)) [SIG Node and Scalability] - Plugin/PluginConfig and Policy APIs are mutually exclusive when running the scheduler ([#88864](https://github.com/kubernetes/kubernetes/pull/88864), [@alculquicondor](https://github.com/alculquicondor)) [SIG Scheduling] - Specifying PluginConfig for the same plugin more than once fails scheduler startup. - + Specifying extenders and configuring .ignoredResources for the NodeResourcesFit plugin fails ([#88870](https://github.com/kubernetes/kubernetes/pull/88870), [@alculquicondor](https://github.com/alculquicondor)) [SIG Scheduling] - Support TLS Server Name overrides in kubeconfig file and via --tls-server-name in kubectl ([#88769](https://github.com/kubernetes/kubernetes/pull/88769), [@deads2k](https://github.com/deads2k)) [SIG API Machinery, Auth and CLI] - Terminating a restartPolicy=Never pod no longer has a chance to report the pod succeeded when it actually failed. ([#88440](https://github.com/kubernetes/kubernetes/pull/88440), [@smarterclayton](https://github.com/smarterclayton)) [SIG Node and Testing] @@ -806,18 +804,18 @@ filename | sha512 hash If you are setting `--redirect-container-streaming=true`, then you must migrate off this configuration. The flag will no longer be able to be enabled starting in v1.20. If you are not setting the flag, no action is necessary. ([#88290](https://github.com/kubernetes/kubernetes/pull/88290), [@tallclair](https://github.com/tallclair)) [SIG API Machinery and Node] - Yes. - + Feature Name: Support using network resources (VNet, LB, IP, etc.) in different AAD Tenant and Subscription than those for the cluster. - + Changes in Pull Request: - + 1. Add properties `networkResourceTenantID` and `networkResourceSubscriptionID` in cloud provider auth config section, which indicates the location of network resources. 2. Add function `GetMultiTenantServicePrincipalToken` to fetch multi-tenant service principal token, which will be used by Azure VM/VMSS Clients in this feature. 3. Add function `GetNetworkResourceServicePrincipalToken` to fetch network resource service principal token, which will be used by Azure Network Resource (Load Balancer, Public IP, Route Table, Network Security Group and their sub level resources) Clients in this feature. 4. Related unit tests. - + None. - + User Documentation: In PR https://github.com/kubernetes-sigs/cloud-provider-azure/pull/301 ([#88384](https://github.com/kubernetes/kubernetes/pull/88384), [@bowen5](https://github.com/bowen5)) [SIG Cloud Provider] ## Changes by Kind @@ -833,8 +831,8 @@ filename | sha512 hash - Added support for multiple sizes huge pages on a container level ([#84051](https://github.com/kubernetes/kubernetes/pull/84051), [@bart0sh](https://github.com/bart0sh)) [SIG Apps, Node and Storage] - AppProtocol is a new field on Service and Endpoints resources, enabled with the ServiceAppProtocol feature gate. ([#88503](https://github.com/kubernetes/kubernetes/pull/88503), [@robscott](https://github.com/robscott)) [SIG Apps and Network] - Fixed missing validation of uniqueness of list items in lists with `x-kubernetes-list-type: map` or x-kubernetes-list-type: set` in CustomResources. ([#84920](https://github.com/kubernetes/kubernetes/pull/84920), [@sttts](https://github.com/sttts)) [SIG API Machinery] -- Introduces optional --detect-local flag to kube-proxy. - Currently the only supported value is "cluster-cidr", +- Introduces optional --detect-local flag to kube-proxy. + Currently the only supported value is "cluster-cidr", which is the default if not specified. ([#87748](https://github.com/kubernetes/kubernetes/pull/87748), [@satyasm](https://github.com/satyasm)) [SIG Cluster Lifecycle, Network and Scheduling] - Kube-scheduler can run more than one scheduling profile. Given a pod, the profile is selected by using its `.spec.SchedulerName`. ([#88285](https://github.com/kubernetes/kubernetes/pull/88285), [@alculquicondor](https://github.com/alculquicondor)) [SIG Apps, Scheduling and Testing] - Moving Windows RunAsUserName feature to GA ([#87790](https://github.com/kubernetes/kubernetes/pull/87790), [@marosset](https://github.com/marosset)) [SIG Apps and Windows] @@ -1048,9 +1046,9 @@ filename | sha512 hash - aggragation api will have alpha support for network proxy ([#87515](https://github.com/kubernetes/kubernetes/pull/87515), [@Sh4d1](https://github.com/Sh4d1)) [SIG API Machinery] - API request throttling (due to a high rate of requests) is now reported in client-go logs at log level 2. The messages are of the form - + Throttling request took 1.50705208s, request: GET:<URL> - + The presence of these messages, may indicate to the administrator the need to tune the cluster accordingly. ([#87740](https://github.com/kubernetes/kubernetes/pull/87740), [@jennybuckley](https://github.com/jennybuckley)) [SIG API Machinery] - kubeadm: reject a node joining the cluster if a node with the same name already exists ([#81056](https://github.com/kubernetes/kubernetes/pull/81056), [@neolit123](https://github.com/neolit123)) [SIG Cluster Lifecycle] - disableAvailabilitySetNodes is added to avoid VM list for VMSS clusters. It should only be used when vmType is "vmss" and all the nodes (including masters) are VMSS virtual machines. ([#87685](https://github.com/kubernetes/kubernetes/pull/87685), [@feiskyer](https://github.com/feiskyer)) [SIG Cloud Provider] diff --git a/content/en/docs/setup/release/version-skew-policy.md b/content/en/docs/setup/release/version-skew-policy.md index cc506352d3..5b189667db 100644 --- a/content/en/docs/setup/release/version-skew-policy.md +++ b/content/en/docs/setup/release/version-skew-policy.md @@ -21,7 +21,7 @@ Specific cluster deployment tools may place additional restrictions on version s ## Supported versions Kubernetes versions are expressed as **x.y.z**, -where **x** is the major version, **y** is the minor version, and **z** is the patch version, following [Semantic Versioning](http://semver.org/) terminology. +where **x** is the major version, **y** is the minor version, and **z** is the patch version, following [Semantic Versioning](https://semver.org/) terminology. For more information, see [Kubernetes Release Versioning](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/release/versioning.md#kubernetes-release-versioning). The Kubernetes project maintains release branches for the most recent three minor releases ({{< skew latestVersion >}}, {{< skew prevMinorVersion >}}, {{< skew oldestMinorVersion >}}). @@ -146,3 +146,16 @@ Running a cluster with `kubelet` instances that are persistently two minor versi * they must be upgraded within one minor version of `kube-apiserver` before the control plane can be upgraded * it increases the likelihood of running `kubelet` versions older than the three maintained minor releases {{</ warning >}} + +### kube-proxy + +* `kube-proxy` must be the same minor version as `kubelet` on the node. +* `kube-proxy` must not be newer than `kube-apiserver`. +* `kube-proxy` must be at most two minor versions older than `kube-apiserver.` + +Example: + +If `kube-proxy` version is **{{< skew latestVersion >}}**: + +* `kubelet` version must be at the same minor version as **{{< skew latestVersion >}}**. +* `kube-apiserver` version must be between **{{< skew oldestMinorVersion >}}** and **{{< skew latestVersion >}}**, inclusive. diff --git a/content/en/docs/tasks/_index.md b/content/en/docs/tasks/_index.md index 552f17e48c..0d424ee4db 100644 --- a/content/en/docs/tasks/_index.md +++ b/content/en/docs/tasks/_index.md @@ -11,9 +11,5 @@ This section of the Kubernetes documentation contains pages that show how to do individual tasks. A task page shows how to do a single thing, typically by giving a short sequence of steps. - -## {{% heading "whatsnext" %}} - - If you would like to write a task page, see [Creating a Documentation Pull Request](/docs/home/contribute/create-pull-request/). diff --git a/content/en/docs/tasks/access-application-cluster/access-cluster.md b/content/en/docs/tasks/access-application-cluster/access-cluster.md index 39ad8b4b7e..d05de37f34 100644 --- a/content/en/docs/tasks/access-application-cluster/access-cluster.md +++ b/content/en/docs/tasks/access-application-cluster/access-cluster.md @@ -8,9 +8,6 @@ content_type: concept This topic discusses multiple ways to interact with clusters. - - - <!-- body --> ## Accessing for the first time with kubectl @@ -29,8 +26,9 @@ Check the location and credentials that kubectl knows about with this command: kubectl config view ``` -Many of the [examples](/docs/user-guide/kubectl-cheatsheet) provide an introduction to using -kubectl and complete documentation is found in the [kubectl manual](/docs/user-guide/kubectl-overview). +Many of the [examples](/docs/reference/kubectl/cheatsheet/) provide an introduction to using +kubectl and complete documentation is found in the +[kubectl manual](/docs/reference/kubectl/overview/). ## Directly accessing the REST API @@ -165,7 +163,7 @@ client libraries. * To get the library, run the following command: `go get k8s.io/client-go@kubernetes-<kubernetes-version-number>`, see [INSTALL.md](https://github.com/kubernetes/client-go/blob/master/INSTALL.md#for-the-casual-user) for detailed installation instructions. See [https://github.com/kubernetes/client-go](https://github.com/kubernetes/client-go#compatibility-matrix) to see which versions are supported. * Write an application atop of the client-go clients. Note that client-go defines its own API objects, so if needed, please import API definitions from client-go rather than from the main repository, e.g., `import "k8s.io/client-go/kubernetes"` is correct. -The Go client can use the same [kubeconfig file](/docs/concepts/cluster-administration/authenticate-across-clusters-kubeconfig/) +The Go client can use the same [kubeconfig file](/docs/concepts/configuration/organize-cluster-access-kubeconfig/) as the kubectl CLI does to locate and authenticate to the apiserver. See this [example](https://git.k8s.io/client-go/examples/out-of-cluster-client-configuration/main.go). If the application is deployed as a Pod in the cluster, please refer to the [next section](#accessing-the-api-from-a-pod). @@ -174,7 +172,7 @@ If the application is deployed as a Pod in the cluster, please refer to the [nex To use [Python client](https://github.com/kubernetes-client/python), run the following command: `pip install kubernetes`. See [Python Client Library page](https://github.com/kubernetes-client/python) for more installation options. -The Python client can use the same [kubeconfig file](/docs/concepts/cluster-administration/authenticate-across-clusters-kubeconfig/) +The Python client can use the same [kubeconfig file](/docs/concepts/configuration/organize-cluster-access-kubeconfig/) as the kubectl CLI does to locate and authenticate to the apiserver. See this [example](https://github.com/kubernetes-client/python/tree/master/examples). ### Other languages @@ -219,7 +217,9 @@ In each case, the credentials of the pod are used to communicate securely with t The previous section was about connecting the Kubernetes API server. This section is about connecting to other services running on Kubernetes cluster. In Kubernetes, the -[nodes](/docs/admin/node), [pods](/docs/user-guide/pods) and [services](/docs/user-guide/services) all have +[nodes](/docs/concepts/architecture/nodes/), +[pods](/docs/concepts/workloads/pods/) and +[services](/docs/concepts/services-networking/service/) all have their own IPs. In many cases, the node IPs, pod IPs, and some service IPs on a cluster will not be routable, so they will not be reachable from a machine outside the cluster, such as your desktop machine. @@ -230,7 +230,7 @@ You have several options for connecting to nodes, pods and services from outside - Access services through public IPs. - Use a service with type `NodePort` or `LoadBalancer` to make the service reachable outside - the cluster. See the [services](/docs/user-guide/services) and + the cluster. See the [services](/docs/concepts/services-networking/service/) and [kubectl expose](/docs/reference/generated/kubectl/kubectl-commands/#expose) documentation. - Depending on your cluster environment, this may just expose the service to your corporate network, or it may expose it to the internet. Think about whether the service being exposed is secure. diff --git a/content/en/docs/tasks/access-application-cluster/communicate-containers-same-pod-shared-volume.md b/content/en/docs/tasks/access-application-cluster/communicate-containers-same-pod-shared-volume.md index 1d00516d28..95066ac612 100644 --- a/content/en/docs/tasks/access-application-cluster/communicate-containers-same-pod-shared-volume.md +++ b/content/en/docs/tasks/access-application-cluster/communicate-containers-same-pod-shared-volume.md @@ -7,19 +7,14 @@ weight: 110 <!-- overview --> This page shows how to use a Volume to communicate between two Containers running -in the same Pod. See also how to allow processes to communicate by [sharing process namespace](/docs/tasks/configure-pod-container/share-process-namespace/) between containers. - - - +in the same Pod. See also how to allow processes to communicate by +[sharing process namespace](/docs/tasks/configure-pod-container/share-process-namespace/) +between containers. ## {{% heading "prerequisites" %}} - {{< include "task-tutorial-prereqs.md" >}} {{< version-check >}} - - - <!-- steps --> ## Creating a Pod that runs two Containers @@ -103,14 +98,15 @@ The output is similar to this: Recall that the debian Container created the `index.html` file in the nginx root directory. Use `curl` to send a GET request to the nginx server: - root@two-containers:/# curl localhost +``` +root@two-containers:/# curl localhost +``` The output shows that nginx serves a web page written by the debian container: - Hello from the debian container - - - +``` +Hello from the debian container +``` <!-- discussion --> @@ -128,20 +124,14 @@ The Volume in this exercise provides a way for Containers to communicate during the life of the Pod. If the Pod is deleted and recreated, any data stored in the shared Volume is lost. - - - ## {{% heading "whatsnext" %}} -* Learn more about -[patterns for composite containers](https://kubernetes.io/blog/2015/06/the-distributed-system-toolkit-patterns). +* Learn more about [patterns for composite containers](https://kubernetes.io/blog/2015/06/the-distributed-system-toolkit-patterns). -* Learn about -[composite containers for modular architecture](http://www.slideshare.net/Docker/slideshare-burns). +* Learn about [composite containers for modular architecture](https://www.slideshare.net/Docker/slideshare-burns). -* See -[Configuring a Pod to Use a Volume for Storage](/docs/tasks/configure-pod-container/configure-volume-storage/). +* See [Configuring a Pod to Use a Volume for Storage](/docs/tasks/configure-pod-container/configure-volume-storage/). * See [Configure a Pod to share process namespace between containers in a Pod](/docs/tasks/configure-pod-container/share-process-namespace/) @@ -149,7 +139,3 @@ the shared Volume is lost. * See [Pod](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#pod-v1-core). - - - - 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 0ce827185c..725afbfb89 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 @@ -11,33 +11,21 @@ microservice. The backend microservice is a hello greeter. The frontend and backend are connected using 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. - - - ## {{% heading "prerequisites" %}} +{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}} -* {{< include "task-tutorial-prereqs.md" >}} {{< version-check >}} - -* This task uses - [Services with external load balancers](/docs/tasks/access-application-cluster/create-external-load-balancer/), which - require a supported environment. If your environment does not - support this, you can use a Service of type - [NodePort](/docs/concepts/services-networking/service/#nodeport) instead. - - - +This task uses +[Services with external load balancers](/docs/tasks/access-application-cluster/create-external-load-balancer/), which +require a supported environment. If your environment does not support this, you can use a Service of type +[NodePort](/docs/concepts/services-networking/service/#nodeport) instead. <!-- lessoncontent --> @@ -153,8 +141,8 @@ service/frontend created ``` {{< note >}} -The nginx configuration is baked into the [container -image](/examples/service/access/Dockerfile). A better way to do this would +The nginx configuration is baked into the +[container image](/examples/service/access/Dockerfile). A better way to do this would be to use a [ConfigMap](/docs/tasks/configure-pod-container/configure-pod-configmap/), so that you can change the configuration more easily. @@ -203,27 +191,22 @@ The output shows the message generated by the backend: {"message":"Hello"} ``` - - ## {{% heading "cleanup" %}} - To delete the Services, enter this command: - kubectl delete services frontend hello +```shell +kubectl delete services frontend hello +``` To delete the Deployments, the ReplicaSets and the Pods that are running the backend and frontend applications, enter this command: - kubectl delete deployment frontend hello - - +```shell +kubectl delete deployment frontend hello +``` ## {{% heading "whatsnext" %}} - * Learn more about [Services](/docs/concepts/services-networking/service/) * Learn more about [ConfigMaps](/docs/tasks/configure-pod-container/configure-pod-configmap/) - - - diff --git a/content/en/docs/tasks/access-application-cluster/ingress-minikube.md b/content/en/docs/tasks/access-application-cluster/ingress-minikube.md index 9288ec3064..77d400aa8d 100644 --- a/content/en/docs/tasks/access-application-cluster/ingress-minikube.md +++ b/content/en/docs/tasks/access-application-cluster/ingress-minikube.md @@ -6,7 +6,7 @@ weight: 100 <!-- overview --> -An [Ingress](/docs/concepts/services-networking/ingress/) is an API object that defines rules which allow external access +An [Ingress](/docs/concepts/services-networking/ingress/) is an API object that defines rules which allow external access to services in a cluster. An [Ingress controller](/docs/concepts/services-networking/ingress-controllers/) fulfills the rules set in the Ingress. This page shows you how to set up a simple Ingress which routes requests to Service web or web2 depending on the HTTP URI. @@ -41,7 +41,7 @@ This page shows you how to set up a simple Ingress which routes requests to Serv ```shell minikube addons enable ingress ``` - + 1. Verify that the NGINX Ingress controller is running ```shell @@ -71,31 +71,31 @@ This page shows you how to set up a simple Ingress which routes requests to Serv ``` Output: - + ```shell deployment.apps/web created ``` -1. Expose the Deployment: +1. Expose the Deployment: ```shell kubectl expose deployment web --type=NodePort --port=8080 ``` - - Output: - + + Output: + ```shell service/web exposed ``` - + 1. Verify the Service is created and is available on a node port: ```shell kubectl get service web - ``` - + ``` + Output: - + ```shell NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE web NodePort 10.104.133.249 <none> 8080:31637/TCP 12m @@ -106,24 +106,24 @@ This page shows you how to set up a simple Ingress which routes requests to Serv ```shell minikube service web --url ``` - + Output: - + ```shell http://172.17.0.15:31637 ``` - + {{< note >}}Katacoda environment only: at the top of the terminal panel, click the plus sign, and then click **Select port to view on Host 1**. Enter the NodePort, in this case `31637`, and then click **Display Port**.{{< /note >}} - + Output: - + ```shell Hello, world! Version: 1.0.0 Hostname: web-55b8c6998d-8k564 ``` - - You can now access the sample app via the Minikube IP address and NodePort. The next step lets you access + + You can now access the sample app via the Minikube IP address and NodePort. The next step lets you access the app using the Ingress resource. ## Create an Ingress resource @@ -132,37 +132,39 @@ The following file is an Ingress resource that sends traffic to your Service via 1. Create `example-ingress.yaml` from the following file: - apiVersion: networking.k8s.io/v1beta1 # for versions before 1.14 use extensions/v1beta1 - kind: Ingress - metadata: - name: example-ingress - annotations: - nginx.ingress.kubernetes.io/rewrite-target: /$1 - spec: - rules: - - host: hello-world.info - http: - paths: - - path: / - backend: - serviceName: web - servicePort: 8080 + ```yaml + apiVersion: networking.k8s.io/v1beta1 + kind: Ingress + metadata: + name: example-ingress + annotations: + nginx.ingress.kubernetes.io/rewrite-target: /$1 + spec: + rules: + - host: hello-world.info + http: + paths: + - path: / + backend: + serviceName: web + servicePort: 8080 + ``` 1. Create the Ingress resource by running the following command: - + ```shell kubectl apply -f example-ingress.yaml ``` - + Output: - + ```shell ingress.networking.k8s.io/example-ingress created ``` -1. Verify the IP address is set: +1. Verify the IP address is set: - ```shell + ```shell kubectl get ingress ``` @@ -173,7 +175,7 @@ The following file is an Ingress resource that sends traffic to your Service via example-ingress hello-world.info 172.17.0.15 80 38s ``` -1. Add the following line to the bottom of the `/etc/hosts` file. +1. Add the following line to the bottom of the `/etc/hosts` file. {{< note >}}If you are running Minikube locally, use `minikube ip` to get the external IP. The IP address displayed within the ingress list will be the internal IP.{{< /note >}} @@ -190,7 +192,7 @@ The following file is an Ingress resource that sends traffic to your Service via ``` Output: - + ```shell Hello, world! Version: 1.0.0 @@ -207,26 +209,26 @@ The following file is an Ingress resource that sends traffic to your Service via kubectl create deployment web2 --image=gcr.io/google-samples/hello-app:2.0 ``` Output: - + ```shell deployment.apps/web2 created ``` - + 1. Expose the Deployment: ```shell kubectl expose deployment web2 --port=8080 --type=NodePort ``` - Output: - + Output: + ```shell service/web2 exposed ``` - + ## Edit Ingress -1. Edit the existing `example-ingress.yaml` and add the following lines: +1. Edit the existing `example-ingress.yaml` and add the following lines: ```yaml - path: /v2 @@ -241,9 +243,10 @@ The following file is an Ingress resource that sends traffic to your Service via kubectl apply -f example-ingress.yaml ``` - Output: + Output: + ```shell - ingress.extensions/example-ingress configured + ingress.networking/example-ingress configured ``` ## Test Your Ingress @@ -255,6 +258,7 @@ The following file is an Ingress resource that sends traffic to your Service via ``` Output: + ```shell Hello, world! Version: 1.0.0 @@ -268,6 +272,7 @@ The following file is an Ingress resource that sends traffic to your Service via ``` Output: + ```shell Hello, world! Version: 2.0.0 diff --git a/content/en/docs/tasks/access-application-cluster/list-all-running-container-images.md b/content/en/docs/tasks/access-application-cluster/list-all-running-container-images.md index d1e1ba1568..3a8983eec8 100644 --- a/content/en/docs/tasks/access-application-cluster/list-all-running-container-images.md +++ b/content/en/docs/tasks/access-application-cluster/list-all-running-container-images.md @@ -9,15 +9,10 @@ weight: 100 This page shows how to use kubectl to list all of the Container images for Pods running in a cluster. - - ## {{% heading "prerequisites" %}} - {{< include "task-tutorial-prereqs.md" >}} {{< version-check >}} - - <!-- steps --> In this exercise you will use kubectl to fetch all of the Pods @@ -30,14 +25,14 @@ of Containers for each. - Format the output to include only the list of Container image names using `-o jsonpath={..image}`. This will recursively parse out the `image` field from the returned json. - - See the [jsonpath reference](/docs/user-guide/jsonpath/) + - See the [jsonpath reference](/docs/reference/kubectl/jsonpath/) for further information on how to use jsonpath. - Format the output using standard tools: `tr`, `sort`, `uniq` - Use `tr` to replace spaces with newlines - Use `sort` to sort the results - Use `uniq` to aggregate image counts -```sh +```shell kubectl get pods --all-namespaces -o jsonpath="{..image}" |\ tr -s '[[:space:]]' '\n' |\ sort |\ @@ -52,7 +47,7 @@ field within the Pod. This ensures the correct field is retrieved even when the field name is repeated, e.g. many fields are called `name` within a given item: -```sh +```shell kubectl get pods --all-namespaces -o jsonpath="{.items[*].spec.containers[*].image}" ``` @@ -74,7 +69,7 @@ Pod is returned instead of a list of items. The formatting can be controlled further by using the `range` operation to iterate over elements individually. -```sh +```shell kubectl get pods --all-namespaces -o=jsonpath='{range .items[*]}{"\n"}{.metadata.name}{":\t"}{range .spec.containers[*]}{.image}{", "}{end}{end}' |\ sort ``` @@ -84,7 +79,7 @@ sort To target only Pods matching a specific label, use the -l flag. The following matches only Pods with labels matching `app=nginx`. -```sh +```shell kubectl get pods --all-namespaces -o=jsonpath="{..image}" -l app=nginx ``` @@ -93,7 +88,7 @@ kubectl get pods --all-namespaces -o=jsonpath="{..image}" -l app=nginx To target only pods in a specific namespace, use the namespace flag. The following matches only Pods in the `kube-system` namespace. -```sh +```shell kubectl get pods --namespace kube-system -o jsonpath="{..image}" ``` @@ -102,27 +97,14 @@ kubectl get pods --namespace kube-system -o jsonpath="{..image}" As an alternative to jsonpath, Kubectl supports using [go-templates](https://golang.org/pkg/text/template/) for formatting the output: - -```sh +```shell kubectl get pods --all-namespaces -o go-template --template="{{range .items}}{{range .spec.containers}}{{.image}} {{end}}{{end}}" ``` - - - - -<!-- discussion --> - - - ## {{% heading "whatsnext" %}} - ### Reference -* [Jsonpath](/docs/user-guide/jsonpath/) reference guide +* [Jsonpath](/docs/reference/kubectl/jsonpath/) reference guide * [Go template](https://golang.org/pkg/text/template/) reference guide - - - diff --git a/content/en/docs/tasks/access-application-cluster/service-access-application-cluster.md b/content/en/docs/tasks/access-application-cluster/service-access-application-cluster.md index fe90981432..1194288386 100644 --- a/content/en/docs/tasks/access-application-cluster/service-access-application-cluster.md +++ b/content/en/docs/tasks/access-application-cluster/service-access-application-cluster.md @@ -45,13 +45,14 @@ Here is the configuration file for the application Deployment: kubectl apply -f https://k8s.io/examples/service/access/hello-application.yaml ``` The preceding command creates a - [Deployment](/docs/concepts/workloads/controllers/deployment/) - object and an associated - [ReplicaSet](/docs/concepts/workloads/controllers/replicaset/) - object. The ReplicaSet has two - [Pods](/docs/concepts/workloads/pods/pod/), + {{< glossary_tooltip text="Deployment" term_id="deployment" >}} + and an associated + {{< glossary_tooltip term_id="replica-set" text="ReplicaSet" >}}. + The ReplicaSet has two + {{< glossary_tooltip text="Pods" term_id="pod" >}} each of which runs the Hello World application. + 1. Display information about the Deployment: ```shell kubectl get deployments hello-world diff --git a/content/en/docs/tasks/access-application-cluster/web-ui-dashboard.md b/content/en/docs/tasks/access-application-cluster/web-ui-dashboard.md index 7a37fdc20b..7bfcf03ebd 100644 --- a/content/en/docs/tasks/access-application-cluster/web-ui-dashboard.md +++ b/content/en/docs/tasks/access-application-cluster/web-ui-dashboard.md @@ -14,15 +14,19 @@ card: <!-- overview --> -Dashboard is a web-based Kubernetes user interface. You can use Dashboard to deploy containerized applications to a Kubernetes cluster, troubleshoot your containerized application, and manage the cluster resources. You can use Dashboard to get an overview of applications running on your cluster, as well as for creating or modifying individual Kubernetes resources (such as Deployments, Jobs, DaemonSets, etc). For example, you can scale a Deployment, initiate a rolling update, restart a pod or deploy new applications using a deploy wizard. +Dashboard is a web-based Kubernetes user interface. +You can use Dashboard to deploy containerized applications to a Kubernetes cluster, +troubleshoot your containerized application, and manage the cluster resources. +You can use Dashboard to get an overview of applications running on your cluster, +as well as for creating or modifying individual Kubernetes resources +(such as Deployments, Jobs, DaemonSets, etc). +For example, you can scale a Deployment, initiate a rolling update, restart a pod +or deploy new applications using a deploy wizard. Dashboard also provides information on the state of Kubernetes resources in your cluster and on any errors that may have occurred. ![Kubernetes Dashboard UI](/images/docs/ui-dashboard.png) - - - <!-- body --> ## Deploying the Dashboard UI @@ -35,8 +39,10 @@ kubectl apply -f https://raw.githubusercontent.com/kubernetes/dashboard/v2.0.0/a ## Accessing the Dashboard UI - -To protect your cluster data, Dashboard deploys with a minimal RBAC configuration by default. Currently, Dashboard only supports logging in with a Bearer Token. To create a token for this demo, you can follow our guide on [creating a sample user](https://github.com/kubernetes/dashboard/blob/master/docs/user/access-control/creating-sample-user.md). +To protect your cluster data, Dashboard deploys with a minimal RBAC configuration by default. +Currently, Dashboard only supports logging in with a Bearer Token. +To create a token for this demo, you can follow our guide on +[creating a sample user](https://github.com/kubernetes/dashboard/blob/master/docs/user/access-control/creating-sample-user.md). {{< warning >}} The sample user created in the tutorial will have administrative privileges and is for educational purposes only. @@ -59,13 +65,17 @@ Kubeconfig Authentication method does NOT support external identity providers or ## Welcome view -When you access Dashboard on an empty cluster, you'll see the welcome page. This page contains a link to this document as well as a button to deploy your first application. In addition, you can view which system applications are running by default in the `kube-system` [namespace](/docs/tasks/administer-cluster/namespaces/) of your cluster, for example the Dashboard itself. +When you access Dashboard on an empty cluster, you'll see the welcome page. +This page contains a link to this document as well as a button to deploy your first application. +In addition, you can view which system applications are running by default in the `kube-system` +[namespace](/docs/tasks/administer-cluster/namespaces/) of your cluster, for example the Dashboard itself. ![Kubernetes Dashboard welcome page](/images/docs/ui-dashboard-zerostate.png) ## Deploying containerized applications -Dashboard lets you create and deploy a containerized application as a Deployment and optional Service with a simple wizard. You can either manually specify application details, or upload a YAML or JSON file containing application configuration. +Dashboard lets you create and deploy a containerized application as a Deployment and optional Service with a simple wizard. +You can either manually specify application details, or upload a YAML or JSON file containing application configuration. Click the **CREATE** button in the upper right corner of any page to begin. @@ -73,17 +83,29 @@ Click the **CREATE** button in the upper right corner of any page to begin. The deploy wizard expects that you provide the following information: -- **App name** (mandatory): Name for your application. A [label](/docs/concepts/overview/working-with-objects/labels/) with the name will be added to the Deployment and Service, if any, that will be deployed. +- **App name** (mandatory): Name for your application. + A [label](/docs/concepts/overview/working-with-objects/labels/) with the name will be + added to the Deployment and Service, if any, that will be deployed. - The application name must be unique within the selected Kubernetes [namespace](/docs/tasks/administer-cluster/namespaces/). It must start with a lowercase character, and end with a lowercase character or a number, and contain only lowercase letters, numbers and dashes (-). It is limited to 24 characters. Leading and trailing spaces are ignored. + The application name must be unique within the selected Kubernetes [namespace](/docs/tasks/administer-cluster/namespaces/). + It must start with a lowercase character, and end with a lowercase character or a number, + and contain only lowercase letters, numbers and dashes (-). It is limited to 24 characters. + Leading and trailing spaces are ignored. -- **Container image** (mandatory): The URL of a public Docker [container image](/docs/concepts/containers/images/) on any registry, or a private image (commonly hosted on the Google Container Registry or Docker Hub). The container image specification must end with a colon. +- **Container image** (mandatory): + The URL of a public Docker [container image](/docs/concepts/containers/images/) on any registry, + or a private image (commonly hosted on the Google Container Registry or Docker Hub). + The container image specification must end with a colon. -- **Number of pods** (mandatory): The target number of Pods you want your application to be deployed in. The value must be a positive integer. +- **Number of pods** (mandatory): The target number of Pods you want your application to be deployed in. + The value must be a positive integer. - A [Deployment](/docs/concepts/workloads/controllers/deployment/) will be created to maintain the desired number of Pods across your cluster. + A [Deployment](/docs/concepts/workloads/controllers/deployment/) will be created to + maintain the desired number of Pods across your cluster. -- **Service** (optional): For some parts of your application (e.g. frontends) you may want to expose a [Service](/docs/concepts/services-networking/service/) onto an external, maybe public IP address outside of your cluster (external Service). +- **Service** (optional): For some parts of your application (e.g. frontends) you may want to expose a + [Service](/docs/concepts/services-networking/service/) onto an external, + maybe public IP address outside of your cluster (external Service). {{< note >}} For external Services, you may need to open up one or more ports to do so. @@ -91,83 +113,137 @@ The deploy wizard expects that you provide the following information: Other Services that are only visible from inside the cluster are called internal Services. - Irrespective of the Service type, if you choose to create a Service and your container listens on a port (incoming), you need to specify two ports. The Service will be created mapping the port (incoming) to the target port seen by the container. This Service will route to your deployed Pods. Supported protocols are TCP and UDP. The internal DNS name for this Service will be the value you specified as application name above. + Irrespective of the Service type, if you choose to create a Service and your container listens + on a port (incoming), you need to specify two ports. + The Service will be created mapping the port (incoming) to the target port seen by the container. + This Service will route to your deployed Pods. Supported protocols are TCP and UDP. + The internal DNS name for this Service will be the value you specified as application name above. If needed, you can expand the **Advanced options** section where you can specify more settings: -- **Description**: The text you enter here will be added as an [annotation](/docs/concepts/overview/working-with-objects/annotations/) to the Deployment and displayed in the application's details. +- **Description**: The text you enter here will be added as an + [annotation](/docs/concepts/overview/working-with-objects/annotations/) + to the Deployment and displayed in the application's details. -- **Labels**: Default [labels](/docs/concepts/overview/working-with-objects/labels/) to be used for your application are application name and version. You can specify additional labels to be applied to the Deployment, Service (if any), and Pods, such as release, environment, tier, partition, and release track. +- **Labels**: Default [labels](/docs/concepts/overview/working-with-objects/labels/) to be used + for your application are application name and version. + You can specify additional labels to be applied to the Deployment, Service (if any), and Pods, + such as release, environment, tier, partition, and release track. Example: -```conf -release=1.0 -tier=frontend -environment=pod -track=stable -``` + ```conf + release=1.0 + tier=frontend + environment=pod + track=stable + ``` -- **Namespace**: Kubernetes supports multiple virtual clusters backed by the same physical cluster. These virtual clusters are called [namespaces](/docs/tasks/administer-cluster/namespaces/). They let you partition resources into logically named groups. +- **Namespace**: Kubernetes supports multiple virtual clusters backed by the same physical cluster. + These virtual clusters are called [namespaces](/docs/tasks/administer-cluster/namespaces/). + They let you partition resources into logically named groups. - Dashboard offers all available namespaces in a dropdown list, and allows you to create a new namespace. The namespace name may contain a maximum of 63 alphanumeric characters and dashes (-) but can not contain capital letters. - Namespace names should not consist of only numbers. If the name is set as a number, such as 10, the pod will be put in the default namespace. + Dashboard offers all available namespaces in a dropdown list, and allows you to create a new namespace. + The namespace name may contain a maximum of 63 alphanumeric characters and dashes (-) but can not contain capital letters. + Namespace names should not consist of only numbers. + If the name is set as a number, such as 10, the pod will be put in the default namespace. - In case the creation of the namespace is successful, it is selected by default. If the creation fails, the first namespace is selected. + In case the creation of the namespace is successful, it is selected by default. + If the creation fails, the first namespace is selected. -- **Image Pull Secret**: In case the specified Docker container image is private, it may require [pull secret](/docs/concepts/configuration/secret/) credentials. +- **Image Pull Secret**: + In case the specified Docker container image is private, it may require + [pull secret](/docs/concepts/configuration/secret/) credentials. - Dashboard offers all available secrets in a dropdown list, and allows you to create a new secret. The secret name must follow the DNS domain name syntax, for example `new.image-pull.secret`. The content of a secret must be base64-encoded and specified in a [`.dockercfg`](/docs/concepts/containers/images/#specifying-imagepullsecrets-on-a-pod) file. The secret name may consist of a maximum of 253 characters. + Dashboard offers all available secrets in a dropdown list, and allows you to create a new secret. + The secret name must follow the DNS domain name syntax, for example `new.image-pull.secret`. + The content of a secret must be base64-encoded and specified in a + [`.dockercfg`](/docs/concepts/containers/images/#specifying-imagepullsecrets-on-a-pod) file. + The secret name may consist of a maximum of 253 characters. In case the creation of the image pull secret is successful, it is selected by default. If the creation fails, no secret is applied. -- **CPU requirement (cores)** and **Memory requirement (MiB)**: You can specify the minimum [resource limits](/docs/tasks/configure-pod-container/limit-range/) for the container. By default, Pods run with unbounded CPU and memory limits. +- **CPU requirement (cores)** and **Memory requirement (MiB)**: + You can specify the minimum [resource limits](/docs/tasks/administer-cluster/manage-resources/memory-default-namespace/) + for the container. By default, Pods run with unbounded CPU and memory limits. -- **Run command** and **Run command arguments**: By default, your containers run the specified Docker image's default [entrypoint command](/docs/tasks/inject-data-application/define-command-argument-container/). You can use the command options and arguments to override the default. +- **Run command** and **Run command arguments**: + By default, your containers run the specified Docker image's default + [entrypoint command](/docs/tasks/inject-data-application/define-command-argument-container/). + You can use the command options and arguments to override the default. -- **Run as privileged**: This setting determines whether processes in [privileged containers](/docs/user-guide/pods/#privileged-mode-for-pod-containers) are equivalent to processes running as root on the host. Privileged containers can make use of capabilities like manipulating the network stack and accessing devices. +- **Run as privileged**: This setting determines whether processes in + [privileged containers](/docs/concepts/workloads/pods/#privileged-mode-for-containers) + are equivalent to processes running as root on the host. + Privileged containers can make use of capabilities like manipulating the network stack and accessing devices. -- **Environment variables**: Kubernetes exposes Services through [environment variables](/docs/tasks/inject-data-application/environment-variable-expose-pod-information/). You can compose environment variable or pass arguments to your commands using the values of environment variables. They can be used in applications to find a Service. Values can reference other variables using the `$(VAR_NAME)` syntax. +- **Environment variables**: Kubernetes exposes Services through + [environment variables](/docs/tasks/inject-data-application/environment-variable-expose-pod-information/). + You can compose environment variable or pass arguments to your commands using the values of environment variables. + They can be used in applications to find a Service. + Values can reference other variables using the `$(VAR_NAME)` syntax. ### Uploading a YAML or JSON file -Kubernetes supports declarative configuration. In this style, all configuration is stored in YAML or JSON configuration files using the Kubernetes [API](/docs/concepts/overview/kubernetes-api/) resource schemas. +Kubernetes supports declarative configuration. +In this style, all configuration is stored in YAML or JSON configuration files +using the Kubernetes [API](/docs/concepts/overview/kubernetes-api/) resource schemas. -As an alternative to specifying application details in the deploy wizard, you can define your application in YAML or JSON files, and upload the files using Dashboard. +As an alternative to specifying application details in the deploy wizard, +you can define your application in YAML or JSON files, and upload the files using Dashboard. ## Using Dashboard Following sections describe views of the Kubernetes Dashboard UI; what they provide and how can they be used. ### Navigation -When there are Kubernetes objects defined in the cluster, Dashboard shows them in the initial view. By default only objects from the _default_ namespace are shown and this can be changed using the namespace selector located in the navigation menu. +When there are Kubernetes objects defined in the cluster, Dashboard shows them in the initial view. +By default only objects from the _default_ namespace are shown and +this can be changed using the namespace selector located in the navigation menu. Dashboard shows most Kubernetes object kinds and groups them in a few menu categories. #### Admin Overview -For cluster and namespace administrators, Dashboard lists Nodes, Namespaces and Persistent Volumes and has detail views for them. Node list view contains CPU and memory usage metrics aggregated across all Nodes. The details view shows the metrics for a Node, its specification, status, allocated resources, events and pods running on the node. +For cluster and namespace administrators, Dashboard lists Nodes, Namespaces and Persistent Volumes and has detail views for them. +Node list view contains CPU and memory usage metrics aggregated across all Nodes. +The details view shows the metrics for a Node, its specification, status, +allocated resources, events and pods running on the node. #### Workloads -Shows all applications running in the selected namespace. The view lists applications by workload kind (e.g., Deployments, Replica Sets, Stateful Sets, etc.) and each workload kind can be viewed separately. The lists summarize actionable information about the workloads, such as the number of ready pods for a Replica Set or current memory usage for a Pod. -Detail views for workloads show status and specification information and surface relationships between objects. For example, Pods that Replica Set is controlling or New Replica Sets and Horizontal Pod Autoscalers for Deployments. +Shows all applications running in the selected namespace. +The view lists applications by workload kind (e.g., Deployments, Replica Sets, Stateful Sets, etc.) +and each workload kind can be viewed separately. +The lists summarize actionable information about the workloads, +such as the number of ready pods for a Replica Set or current memory usage for a Pod. + +Detail views for workloads show status and specification information and +surface relationships between objects. +For example, Pods that Replica Set is controlling or New Replica Sets and Horizontal Pod Autoscalers for Deployments. #### Services -Shows Kubernetes resources that allow for exposing services to external world and discovering them within a cluster. For that reason, Service and Ingress views show Pods targeted by them, internal endpoints for cluster connections and external endpoints for external users. + +Shows Kubernetes resources that allow for exposing services to external world and +discovering them within a cluster. +For that reason, Service and Ingress views show Pods targeted by them, +internal endpoints for cluster connections and external endpoints for external users. #### Storage + Storage view shows Persistent Volume Claim resources which are used by applications for storing data. #### Config Maps and Secrets -Shows all Kubernetes resources that are used for live configuration of applications running in clusters. The view allows for editing and managing config objects and displays secrets hidden by default. + +Shows all Kubernetes resources that are used for live configuration of applications running in clusters. +The view allows for editing and managing config objects and displays secrets hidden by default. #### Logs viewer -Pod lists and detail pages link to a logs viewer that is built into Dashboard. The viewer allows for drilling down logs from containers belonging to a single Pod. + +Pod lists and detail pages link to a logs viewer that is built into Dashboard. +The viewer allows for drilling down logs from containers belonging to a single Pod. ![Logs viewer](/images/docs/ui-dashboard-logs-view.png) - - ## {{% heading "whatsnext" %}} diff --git a/content/en/docs/tasks/administer-cluster/access-cluster-api.md b/content/en/docs/tasks/administer-cluster/access-cluster-api.md index 659c8d777c..5c94dceffc 100644 --- a/content/en/docs/tasks/administer-cluster/access-cluster-api.md +++ b/content/en/docs/tasks/administer-cluster/access-cluster-api.md @@ -6,13 +6,10 @@ content_type: task <!-- overview --> This page shows how to access clusters using the Kubernetes API. - ## {{% heading "prerequisites" %}} - {{< include "task-tutorial-prereqs.md" >}} {{< version-check >}} - <!-- steps --> ## Accessing the Kubernetes API @@ -170,7 +167,7 @@ client-go defines its own API objects, so if needed, import API definitions from {{< /note >}} -The Go client can use the same [kubeconfig file](/docs/concepts/cluster-administration/authenticate-across-clusters-kubeconfig/) +The Go client can use the same [kubeconfig file](/docs/concepts/configuration/organize-cluster-access-kubeconfig/) as the kubectl CLI does to locate and authenticate to the API server. See this [example](https://git.k8s.io/client-go/examples/out-of-cluster-client-configuration/main.go): ```golang @@ -199,7 +196,7 @@ If the application is deployed as a Pod in the cluster, see [Accessing the API f To use [Python client](https://github.com/kubernetes-client/python), run the following command: `pip install kubernetes` See [Python Client Library page](https://github.com/kubernetes-client/python) for more installation options. -The Python client can use the same [kubeconfig file](/docs/concepts/cluster-administration/authenticate-across-clusters-kubeconfig/) +The Python client can use the same [kubeconfig file](/docs/concepts/configuration/organize-cluster-access-kubeconfig/) as the kubectl CLI does to locate and authenticate to the API server. See this [example](https://github.com/kubernetes-client/python/blob/master/examples/out_of_cluster_config.py): ```python @@ -229,7 +226,7 @@ mvn install See [https://github.com/kubernetes-client/java/releases](https://github.com/kubernetes-client/java/releases) to see which versions are supported. -The Java client can use the same [kubeconfig file](/docs/concepts/cluster-administration/authenticate-across-clusters-kubeconfig/) +The Java client can use the same [kubeconfig file](/docs/concepts/configuration/organize-cluster-access-kubeconfig/) as the kubectl CLI does to locate and authenticate to the API server. See this [example](https://github.com/kubernetes-client/java/blob/master/examples/src/main/java/io/kubernetes/client/examples/KubeConfigFileClientExample.java): ```java @@ -283,7 +280,7 @@ public class KubeConfigFileClientExample { To use [dotnet client](https://github.com/kubernetes-client/csharp), run the following command: `dotnet add package KubernetesClient --version 1.6.1` See [dotnet Client Library page](https://github.com/kubernetes-client/csharp) for more installation options. See [https://github.com/kubernetes-client/csharp/releases](https://github.com/kubernetes-client/csharp/releases) to see which versions are supported. -The dotnet client can use the same [kubeconfig file](/docs/concepts/cluster-administration/authenticate-across-clusters-kubeconfig/) +The dotnet client can use the same [kubeconfig file](/docs/concepts/configuration/organize-cluster-access-kubeconfig/) as the kubectl CLI does to locate and authenticate to the API server. See this [example](https://github.com/kubernetes-client/csharp/blob/master/examples/simple/PodList.cs): ```csharp @@ -318,7 +315,7 @@ namespace simple To install [JavaScript client](https://github.com/kubernetes-client/javascript), run the following command: `npm install @kubernetes/client-node`. See [https://github.com/kubernetes-client/javascript/releases](https://github.com/kubernetes-client/javascript/releases) to see which versions are supported. -The JavaScript client can use the same [kubeconfig file](/docs/concepts/cluster-administration/authenticate-across-clusters-kubeconfig/) +The JavaScript client can use the same [kubeconfig file](/docs/concepts/configuration/organize-cluster-access-kubeconfig/) as the kubectl CLI does to locate and authenticate to the API server. See this [example](https://github.com/kubernetes-client/javascript/blob/master/examples/example.js): ```javascript @@ -338,7 +335,7 @@ k8sApi.listNamespacedPod('default').then((res) => { See [https://github.com/kubernetes-client/haskell/releases](https://github.com/kubernetes-client/haskell/releases) to see which versions are supported. -The [Haskell client](https://github.com/kubernetes-client/haskell) can use the same [kubeconfig file](/docs/concepts/cluster-administration/authenticate-across-clusters-kubeconfig/) +The [Haskell client](https://github.com/kubernetes-client/haskell) can use the same [kubeconfig file](/docs/concepts/configuration/organize-cluster-access-kubeconfig/) as the kubectl CLI does to locate and authenticate to the API server. See this [example](https://github.com/kubernetes-client/haskell/blob/master/kubernetes-client/example/App.hs): ```haskell @@ -388,7 +385,7 @@ While running in a Pod, the Kubernetes apiserver is accessible via a Service nam do this automatically. The recommended way to authenticate to the API server is with a -[service account](/docs/user-guide/service-accounts) credential. By default, a Pod +[service account](/docs/tasks/configure-pod-container/configure-service-account/) credential. By default, a Pod is associated with a service account, and a credential (token) for that service account is placed into the filesystem tree of each container in that Pod, at `/var/run/secrets/kubernetes.io/serviceaccount/token`. diff --git a/content/en/docs/tasks/administer-cluster/access-cluster-services.md b/content/en/docs/tasks/administer-cluster/access-cluster-services.md index 979a75a162..c318a3df35 100644 --- a/content/en/docs/tasks/administer-cluster/access-cluster-services.md +++ b/content/en/docs/tasks/administer-cluster/access-cluster-services.md @@ -17,7 +17,8 @@ This page shows how to connect to services running on the Kubernetes cluster. ## Accessing services running on the cluster -In Kubernetes, [nodes](/docs/admin/node), [pods](/docs/user-guide/pods) and [services](/docs/user-guide/services) all have +In Kubernetes, [nodes](/docs/concepts/architecture/nodes/), +[pods](/docs/concepts/workloads/pods/) and [services](/docs/concepts/services-networking/service/) all have their own IPs. In many cases, the node IPs, pod IPs, and some service IPs on a cluster will not be routable, so they will not be reachable from a machine outside the cluster, such as your desktop machine. @@ -28,7 +29,7 @@ You have several options for connecting to nodes, pods and services from outside - Access services through public IPs. - Use a service with type `NodePort` or `LoadBalancer` to make the service reachable outside - the cluster. See the [services](/docs/user-guide/services) and + the cluster. See the [services](/docs/concepts/services-networking/service/) and [kubectl expose](/docs/reference/generated/kubectl/kubectl-commands/#expose) documentation. - Depending on your cluster environment, this may just expose the service to your corporate network, or it may expose it to the internet. Think about whether the service being exposed is secure. diff --git a/content/en/docs/tasks/administer-cluster/change-default-storage-class.md b/content/en/docs/tasks/administer-cluster/change-default-storage-class.md index 453cfef221..9c08a2a4ad 100644 --- a/content/en/docs/tasks/administer-cluster/change-default-storage-class.md +++ b/content/en/docs/tasks/administer-cluster/change-default-storage-class.md @@ -24,7 +24,7 @@ Depending on the installation method, your Kubernetes cluster may be deployed wi an existing StorageClass that is marked as default. This default StorageClass is then used to dynamically provision storage for PersistentVolumeClaims that do not require any specific storage class. See -[PersistentVolumeClaim documentation](/docs/concepts/storage/persistent-volumes/#class-1) +[PersistentVolumeClaim documentation](/docs/concepts/storage/persistent-volumes/#persistentvolumeclaims) for details. The pre-installed default StorageClass may not fit well with your expected workload; diff --git a/content/en/docs/tasks/administer-cluster/change-pv-reclaim-policy.md b/content/en/docs/tasks/administer-cluster/change-pv-reclaim-policy.md index 729c7bde4f..be7cbf2673 100644 --- a/content/en/docs/tasks/administer-cluster/change-pv-reclaim-policy.md +++ b/content/en/docs/tasks/administer-cluster/change-pv-reclaim-policy.md @@ -19,15 +19,15 @@ PersistentVolume. ## Why change reclaim policy of a PersistentVolume -`PersistentVolumes` can have various reclaim policies, including "Retain", -"Recycle", and "Delete". For dynamically provisioned `PersistentVolumes`, +PersistentVolumes can have various reclaim policies, including "Retain", +"Recycle", and "Delete". For dynamically provisioned PersistentVolumes, the default reclaim policy is "Delete". This means that a dynamically provisioned volume is automatically deleted when a user deletes the corresponding -`PersistentVolumeClaim`. This automatic behavior might be inappropriate if the volume +PersistentVolumeClaim. This automatic behavior might be inappropriate if the volume contains precious data. In that case, it is more appropriate to use the "Retain" -policy. With the "Retain" policy, if a user deletes a `PersistentVolumeClaim`, -the corresponding `PersistentVolume` is not be deleted. Instead, it is moved to the -`Released` phase, where all of its data can be manually recovered. +policy. With the "Retain" policy, if a user deletes a PersistentVolumeClaim, +the corresponding PersistentVolume is not be deleted. Instead, it is moved to the +Released phase, where all of its data can be manually recovered. ## Changing the reclaim policy of a PersistentVolume diff --git a/content/en/docs/tasks/administer-cluster/cluster-management.md b/content/en/docs/tasks/administer-cluster/cluster-management.md index 7cbab3aa2c..ecbae2a4b3 100644 --- a/content/en/docs/tasks/administer-cluster/cluster-management.md +++ b/content/en/docs/tasks/administer-cluster/cluster-management.md @@ -13,9 +13,6 @@ upgrading your cluster's master and worker nodes, performing node maintenance (e.g. kernel upgrades), and upgrading the Kubernetes API version of a running cluster. - - - <!-- body --> ## Creating and configuring a Cluster @@ -81,24 +78,33 @@ Different providers, and tools, will manage upgrades differently. It is recomme * [Digital Rebar](https://provision.readthedocs.io/en/tip/doc/content-packages/krib.html) * ... -To upgrade a cluster on a platform not mentioned in the above list, check the order of component upgrade on the [Skewed versions](/docs/setup/release/version-skew-policy/#supported-component-upgrade-order) page. +To upgrade a cluster on a platform not mentioned in the above list, check the order of component upgrade on the +[Skewed versions](/docs/setup/release/version-skew-policy/#supported-component-upgrade-order) page. ## Resizing a cluster -If your cluster runs short on resources you can easily add more machines to it if your cluster is running in [Node self-registration mode](/docs/admin/node/#self-registration-of-nodes). -If you're using GCE or Google Kubernetes Engine it's done by resizing the Instance Group managing your Nodes. It can be accomplished by modifying number of instances on `Compute > Compute Engine > Instance groups > your group > Edit group` [Google Cloud Console page](https://console.developers.google.com) or using gcloud CLI: +If your cluster runs short on resources you can easily add more machines to it if your cluster +is running in [Node self-registration mode](/docs/concepts/architecture/nodes/#self-registration-of-nodes). +If you're using GCE or Google Kubernetes Engine it's done by resizing the Instance Group managing your Nodes. +It can be accomplished by modifying number of instances on +`Compute > Compute Engine > Instance groups > your group > Edit group` +[Google Cloud Console page](https://console.developers.google.com) or using gcloud CLI: ```shell gcloud compute instance-groups managed resize kubernetes-node-pool --size=42 --zone=$ZONE ``` -The Instance Group will take care of putting appropriate image on new machines and starting them, while the Kubelet will register its Node with the API server to make it available for scheduling. If you scale the instance group down, system will randomly choose Nodes to kill. +The Instance Group will take care of putting appropriate image on new machines and starting them, +while the Kubelet will register its Node with the API server to make it available for scheduling. +If you scale the instance group down, system will randomly choose Nodes to kill. In other environments you may need to configure the machine yourself and tell the Kubelet on which machine API server is running. ### Resizing an Azure Kubernetes Service (AKS) cluster -Azure Kubernetes Service enables user-initiated resizing of the cluster from either the CLI or the Azure Portal and is described in the [Azure AKS documentation](https://docs.microsoft.com/en-us/azure/aks/scale-cluster). +Azure Kubernetes Service enables user-initiated resizing of the cluster from either the CLI or +the Azure Portal and is described in the +[Azure AKS documentation](https://docs.microsoft.com/en-us/azure/aks/scale-cluster). ### Cluster autoscaling @@ -106,7 +112,8 @@ Azure Kubernetes Service enables user-initiated resizing of the cluster from eit If you are using GCE or Google Kubernetes Engine, you can configure your cluster so that it is automatically rescaled based on pod needs. -As described in [Compute Resource](/docs/concepts/configuration/manage-compute-resources-container/), users can reserve how much CPU and memory is allocated to pods. +As described in [Compute Resource](/docs/concepts/configuration/manage-resources-containers/), +users can reserve how much CPU and memory is allocated to pods. This information is used by the Kubernetes scheduler to find a place to run the pod. If there is no node that has enough free capacity (or doesn't match other pod requirements) then the pod has to wait until some pods are terminated or a new node is added. @@ -185,7 +192,8 @@ kubectl uncordon $NODENAME If you deleted the node's VM instance and created a new one, then a new schedulable node resource will be created automatically (if you're using a cloud provider that supports -node discovery; currently this is only Google Compute Engine, not including CoreOS on Google Compute Engine using kube-register). See [Node](/docs/admin/node) for more details. +node discovery; currently this is only Google Compute Engine, not including CoreOS on Google Compute Engine using kube-register). +See [Node](/docs/concepts/architecture/nodes/) for more details. ## Advanced Topics diff --git a/content/en/docs/tasks/administer-cluster/cpu-management-policies.md b/content/en/docs/tasks/administer-cluster/cpu-management-policies.md index 1b29abf17c..5ffc40781a 100644 --- a/content/en/docs/tasks/administer-cluster/cpu-management-policies.md +++ b/content/en/docs/tasks/administer-cluster/cpu-management-policies.md @@ -36,7 +36,7 @@ By default, the kubelet uses [CFS quota](https://en.wikipedia.org/wiki/Completel to enforce pod CPU limits.  When the node runs many CPU-bound pods, the workload can move to different CPU cores depending on whether the pod is throttled and which CPU cores are available at -scheduling time.  Many workloads are not sensitive to this migration and thus +scheduling time. Many workloads are not sensitive to this migration and thus work fine without any intervention. However, in workloads where CPU cache affinity and scheduling latency diff --git a/content/en/docs/tasks/administer-cluster/dns-custom-nameservers.md b/content/en/docs/tasks/administer-cluster/dns-custom-nameservers.md index f436b641a0..437e58f39e 100644 --- a/content/en/docs/tasks/administer-cluster/dns-custom-nameservers.md +++ b/content/en/docs/tasks/administer-cluster/dns-custom-nameservers.md @@ -17,7 +17,7 @@ DNS resolution process in your cluster. {{< include "task-tutorial-prereqs.md" >}} Your cluster must be running the CoreDNS add-on. -[Migrating to CoreDNS](https://kubernetes.io/docs/tasks/administer-cluster/coredns/#migrating-to-coredns) +[Migrating to CoreDNS](/docs/tasks/administer-cluster/coredns/#migrating-to-coredns) explains how to use `kubeadm` to migrate from `kube-dns`. {{% version-check %}} @@ -50,7 +50,7 @@ and more. For more information, see [DNS for Services and Pods](/docs/concepts/s If a Pod's `dnsPolicy` is set to `default`, it inherits the name resolution configuration from the node that the Pod runs on. The Pod's DNS resolution should behave the same as the node. -But see [Known issues](/docs/tasks/debug-application-cluster/dns-debugging-resolution/#known-issues). +But see [Known issues](/docs/tasks/administer-cluster/dns-debugging-resolution/#known-issues). If you don't want this, or if you want a different DNS config for pods, you can use the kubelet's `--resolv-conf` flag. Set this flag to "" to prevent Pods from @@ -117,7 +117,7 @@ You can modify the default CoreDNS behavior by modifying the ConfigMap. ### Configuration of Stub-domain and upstream nameserver using CoreDNS -CoreDNS has the ability to configure stubdomains and upstream nameservers using the [forward plugin](https://coredns.io/plugins/forward/). +CoreDNS has the ability to configure stubdomains and upstream nameservers using the [forward plugin](https://coredns.io/plugins/forward/). #### Example If a cluster operator has a [Consul](https://www.consul.io/) domain server located at 10.150.0.1, and all Consul names have the suffix .consul.local. To configure it in CoreDNS, the cluster administrator creates the following stanza in the CoreDNS ConfigMap. @@ -261,4 +261,4 @@ You can also migrate using the offical CoreDNS ## {{% heading "whatsnext" %}} -- Read [Debugging DNS Resolution](/docs/tasks/debug-application-cluster/dns-debugging-resolution/) +- Read [Debugging DNS Resolution](/docs/tasks/administer-cluster/dns-debugging-resolution/) diff --git a/content/en/docs/tasks/debug-application-cluster/dns-debugging-resolution.md b/content/en/docs/tasks/administer-cluster/dns-debugging-resolution.md similarity index 100% rename from content/en/docs/tasks/debug-application-cluster/dns-debugging-resolution.md rename to content/en/docs/tasks/administer-cluster/dns-debugging-resolution.md diff --git a/content/en/docs/tasks/administer-cluster/dns-horizontal-autoscaling.md b/content/en/docs/tasks/administer-cluster/dns-horizontal-autoscaling.md index 6fd887bd8f..f333b215a2 100644 --- a/content/en/docs/tasks/administer-cluster/dns-horizontal-autoscaling.md +++ b/content/en/docs/tasks/administer-cluster/dns-horizontal-autoscaling.md @@ -160,7 +160,7 @@ kubectl scale deployment --replicas=0 dns-autoscaler --namespace=kube-system The output is: - deployment.extensions/dns-autoscaler scaled + deployment.apps/dns-autoscaler scaled Verify that the replica count is zero: diff --git a/content/en/docs/tasks/administer-cluster/extended-resource-node.md b/content/en/docs/tasks/administer-cluster/extended-resource-node.md index 07d8fea616..a95a325d5d 100644 --- a/content/en/docs/tasks/administer-cluster/extended-resource-node.md +++ b/content/en/docs/tasks/administer-cluster/extended-resource-node.md @@ -202,8 +202,8 @@ kubectl describe node <your-node-name> | grep dongle ### For cluster administrators -* [Configure Minimum and Maximum Memory Constraints for a Namespace](/docs/tasks/administer-cluster/memory-constraint-namespace/) -* [Configure Minimum and Maximum CPU Constraints for a Namespace](/docs/tasks/administer-cluster/cpu-constraint-namespace/) +* [Configure Minimum and Maximum Memory Constraints for a Namespace](/docs/tasks/administer-cluster/manage-resources/memory-constraint-namespace/) +* [Configure Minimum and Maximum CPU Constraints for a Namespace](/docs/tasks/administer-cluster/manage-resources/cpu-constraint-namespace/) diff --git a/content/en/docs/tasks/administer-cluster/kms-provider.md b/content/en/docs/tasks/administer-cluster/kms-provider.md index 34cc1d6b66..15bc1290ff 100644 --- a/content/en/docs/tasks/administer-cluster/kms-provider.md +++ b/content/en/docs/tasks/administer-cluster/kms-provider.md @@ -7,10 +7,8 @@ content_type: task <!-- overview --> This page shows how to configure a Key Management Service (KMS) provider and plugin to enable secret data encryption. - ## {{% heading "prerequisites" %}} - * {{< include "task-tutorial-prereqs.md" >}} {{< version-check >}} * Kubernetes version 1.10.0 or later is required @@ -19,8 +17,6 @@ This page shows how to configure a Key Management Service (KMS) provider and plu {{< feature-state for_k8s_version="v1.12" state="beta" >}} - - <!-- steps --> The KMS encryption provider uses an envelope encryption scheme to encrypt data in etcd. The data is encrypted using a data encryption key (DEK); a new DEK is generated for each encryption. The DEKs are encrypted with a key encryption key (KEK) that is stored and managed in a remote KMS. The KMS provider uses gRPC to communicate with a specific KMS @@ -30,10 +26,12 @@ plugin. The KMS plugin, which is implemented as a gRPC server and deployed on th To configure a KMS provider on the API server, include a provider of type ```kms``` in the providers array in the encryption configuration file and set the following properties: - * `name`: Display name of the KMS plugin. - * `endpoint`: Listen address of the gRPC server (KMS plugin). The endpoint is a UNIX domain socket. - * `cachesize`: Number of data encryption keys (DEKs) to be cached in the clear. When cached, DEKs can be used without another call to the KMS; whereas DEKs that are not cached require a call to the KMS to unwrap. - * `timeout`: How long should kube-apiserver wait for kms-plugin to respond before returning an error (default is 3 seconds). +* `name`: Display name of the KMS plugin. +* `endpoint`: Listen address of the gRPC server (KMS plugin). The endpoint is a UNIX domain socket. +* `cachesize`: Number of data encryption keys (DEKs) to be cached in the clear. + When cached, DEKs can be used without another call to the KMS; + whereas DEKs that are not cached require a call to the KMS to unwrap. +* `timeout`: How long should kube-apiserver wait for kms-plugin to respond before returning an error (default is 3 seconds). See [Understanding the encryption at rest configuration.](/docs/tasks/administer-cluster/encrypt-data) @@ -57,17 +55,18 @@ Then use the functions and data structures in the stub file to develop the serve * kms plugin version: `v1beta1` -In response to procedure call Version, a compatible KMS plugin should return v1beta1 as VersionResponse.version + In response to procedure call Version, a compatible KMS plugin should return v1beta1 as VersionResponse.version. * message version: `v1beta1` -All messages from KMS provider have the version field set to current version v1beta1 + All messages from KMS provider have the version field set to current version v1beta1. * protocol: UNIX domain socket (`unix`) -The gRPC server should listen at UNIX domain socket + The gRPC server should listen at UNIX domain socket. ### Integrating a KMS plugin with the remote KMS + The KMS plugin can communicate with the remote KMS using any protocol supported by the KMS. All configuration data, including authentication credentials the KMS plugin uses to communicate with the remote KMS, are stored and managed by the KMS plugin independently. The KMS plugin can encode the ciphertext with additional metadata that may be required before sending it to the KMS for decryption. @@ -80,108 +79,113 @@ To encrypt the data: 1. Create a new encryption configuration file using the appropriate properties for the `kms` provider: - ```yaml - apiVersion: apiserver.config.k8s.io/v1 - kind: EncryptionConfiguration - resources: - - resources: - - secrets - providers: - - kms: - name: myKmsPlugin - endpoint: unix:///tmp/socketfile.sock - cachesize: 100 - timeout: 3s - - identity: {} - ``` + ```yaml + apiVersion: apiserver.config.k8s.io/v1 + kind: EncryptionConfiguration + resources: + - resources: + - secrets + providers: + - kms: + name: myKmsPlugin + endpoint: unix:///tmp/socketfile.sock + cachesize: 100 + timeout: 3s + - identity: {} + ``` -2. Set the `--encryption-provider-config` flag on the kube-apiserver to point to the location of the configuration file. -3. Restart your API server. - -Note: -The alpha version of the encryption feature prior to 1.13 required a config file with -`kind: EncryptionConfig` and `apiVersion: v1`, and used the `--experimental-encryption-provider-config` flag. +1. Set the `--encryption-provider-config` flag on the kube-apiserver to point to the location of the configuration file. +1. Restart your API server. ## Verifying that the data is encrypted -Data is encrypted when written to etcd. After restarting your kube-apiserver, any newly created or updated secret should be encrypted when stored. To verify, you can use the etcdctl command line program to retrieve the contents of your secret. + +Data is encrypted when written to etcd. After restarting your `kube-apiserver`, +any newly created or updated secret should be encrypted when stored. To verify, +you can use the `etcdctl` command line program to retrieve the contents of your secret. 1. Create a new secret called secret1 in the default namespace: -``` -kubectl create secret generic secret1 -n default --from-literal=mykey=mydata -``` -2. Using the etcdctl command line, read that secret out of etcd: -``` -ETCDCTL_API=3 etcdctl get /kubernetes.io/secrets/default/secret1 [...] | hexdump -C -``` - where `[...]` must be the additional arguments for connecting to the etcd server. + ``` + kubectl create secret generic secret1 -n default --from-literal=mykey=mydata + ``` +1. Using the etcdctl command line, read that secret out of etcd: + ``` + ETCDCTL_API=3 etcdctl get /kubernetes.io/secrets/default/secret1 [...] | hexdump -C + ``` + where `[...]` must be the additional arguments for connecting to the etcd server. -3. Verify the stored secret is prefixed with `k8s:enc:kms:v1:`, which indicates that the `kms` provider has encrypted the resulting data. +1. Verify the stored secret is prefixed with `k8s:enc:kms:v1:`, which indicates that the `kms` provider has encrypted the resulting data. -4. Verify that the secret is correctly decrypted when retrieved via the API: -``` -kubectl describe secret secret1 -n default -``` -should match `mykey: mydata` +1. Verify that the secret is correctly decrypted when retrieved via the API: + ``` + kubectl describe secret secret1 -n default + ``` + should match `mykey: mydata` ## Ensuring all secrets are encrypted + Because secrets are encrypted on write, performing an update on a secret encrypts that content. -The following command reads all secrets and then updates them to apply server side encryption. If an error occurs due to a conflicting write, retry the command. For larger clusters, you may wish to subdivide the secrets by namespace or script an update. +The following command reads all secrets and then updates them to apply server side encryption. +If an error occurs due to a conflicting write, retry the command. +For larger clusters, you may wish to subdivide the secrets by namespace or script an update. + ``` kubectl get secrets --all-namespaces -o json | kubectl replace -f - ``` ## Switching from a local encryption provider to the KMS provider + To switch from a local encryption provider to the `kms` provider and re-encrypt all of the secrets: 1. Add the `kms` provider as the first entry in the configuration file as shown in the following example. - ```yaml - apiVersion: apiserver.config.k8s.io/v1 - kind: EncryptionConfiguration - resources: - - resources: - - secrets - providers: - - kms: - name : myKmsPlugin - endpoint: unix:///tmp/socketfile.sock - cachesize: 100 - - aescbc: - keys: - - name: key1 - secret: <BASE 64 ENCODED SECRET> - ``` + ```yaml + apiVersion: apiserver.config.k8s.io/v1 + kind: EncryptionConfiguration + resources: + - resources: + - secrets + providers: + - kms: + name : myKmsPlugin + endpoint: unix:///tmp/socketfile.sock + cachesize: 100 + - aescbc: + keys: + - name: key1 + secret: <BASE 64 ENCODED SECRET> + ``` -2. Restart all kube-apiserver processes. +1. Restart all kube-apiserver processes. -3. Run the following command to force all secrets to be re-encrypted using the `kms` provider. +1. Run the following command to force all secrets to be re-encrypted using the `kms` provider. -``` -kubectl get secrets --all-namespaces -o json| kubectl replace -f - -``` + ``` + kubectl get secrets --all-namespaces -o json| kubectl replace -f - + ``` ## Disabling encryption at rest + To disable encryption at rest: 1. Place the `identity` provider as the first entry in the configuration file: - ```yaml - apiVersion: apiserver.config.k8s.io/v1 - kind: EncryptionConfiguration - resources: - - resources: - - secrets - providers: - - identity: {} - - kms: - name : myKmsPlugin - endpoint: unix:///tmp/socketfile.sock - cachesize: 100 - ``` -2. Restart all kube-apiserver processes. -3. Run the following command to force all secrets to be decrypted. -``` -kubectl get secrets --all-namespaces -o json | kubectl replace -f - -``` + ```yaml + apiVersion: apiserver.config.k8s.io/v1 + kind: EncryptionConfiguration + resources: + - resources: + - secrets + providers: + - identity: {} + - kms: + name : myKmsPlugin + endpoint: unix:///tmp/socketfile.sock + cachesize: 100 + ``` +1. Restart all kube-apiserver processes. +1. Run the following command to force all secrets to be decrypted. + ``` + kubectl get secrets --all-namespaces -o json | kubectl replace -f - + ``` diff --git a/content/en/docs/tasks/administer-cluster/kubeadm/adding-windows-nodes.md b/content/en/docs/tasks/administer-cluster/kubeadm/adding-windows-nodes.md index e82c53f3a6..c3498fce61 100644 --- a/content/en/docs/tasks/administer-cluster/kubeadm/adding-windows-nodes.md +++ b/content/en/docs/tasks/administer-cluster/kubeadm/adding-windows-nodes.md @@ -140,7 +140,7 @@ curl -L https://github.com/kubernetes-sigs/sig-windows-tools/releases/latest/dow ### Joining a Windows worker node {{< note >}} You must install the `Containers` feature and install Docker. Instructions -to do so are available at [Install Docker Engine - Enterprise on Windows Servers](https://docs.docker.com/ee/docker-ee/windows/docker-ee/#install-docker-engine---enterprise). +to do so are available at [Install Docker Engine - Enterprise on Windows Servers](https://docs.mirantis.com/docker-enterprise/v3.1/dockeree-products/docker-engine-enterprise/dee-windows.html). {{< /note >}} {{< note >}} diff --git a/content/en/docs/tasks/administer-cluster/kubeadm/kubeadm-certs.md b/content/en/docs/tasks/administer-cluster/kubeadm/kubeadm-certs.md index 461e45bda6..02687a85f2 100644 --- a/content/en/docs/tasks/administer-cluster/kubeadm/kubeadm-certs.md +++ b/content/en/docs/tasks/administer-cluster/kubeadm/kubeadm-certs.md @@ -12,15 +12,11 @@ weight: 10 Client certificates generated by [kubeadm](/docs/reference/setup-tools/kubeadm/kubeadm/) expire after 1 year. This page explains how to manage certificate renewals with kubeadm. - - ## {{% heading "prerequisites" %}} You should be familiar with [PKI certificates and requirements in Kubernetes](/docs/setup/best-practices/certificates/). - - <!-- steps --> ## Using custom certificates {#custom-certificates} @@ -155,33 +151,29 @@ These are advanced topics for users who need to integrate their organization's c ### Set up a signer The Kubernetes Certificate Authority does not work out of the box. -You can configure an external signer such as [cert-manager][cert-manager-issuer], or you can use the built-in signer. +You can configure an external signer such as [cert-manager](https://docs.cert-manager.io/en/latest/tasks/issuers/setup-ca.html), or you can use the built-in signer. -The built-in signer is part of [`kube-controller-manager`][kcm]. +The built-in signer is part of [`kube-controller-manager`](/docs/reference/command-line-tools-reference/kube-controller-manager/). To activate the built-in signer, you must pass the `--cluster-signing-cert-file` and `--cluster-signing-key-file` flags. -If you're creating a new cluster, you can use a kubeadm [configuration file][config]: +If you're creating a new cluster, you can use a kubeadm [configuration file](https://godoc.org/k8s.io/kubernetes/cmd/kubeadm/app/apis/kubeadm/v1beta2): - ```yaml - apiVersion: kubeadm.k8s.io/v1beta2 - kind: ClusterConfiguration - controllerManager: - extraArgs: - cluster-signing-cert-file: /etc/kubernetes/pki/ca.crt - cluster-signing-key-file: /etc/kubernetes/pki/ca.key - ``` - -[cert-manager-issuer]: https://docs.cert-manager.io/en/latest/tasks/issuers/setup-ca.html -[kcm]: /docs/reference/command-line-tools-reference/kube-controller-manager/ -[config]: https://godoc.org/k8s.io/kubernetes/cmd/kubeadm/app/apis/kubeadm/v1beta2 +```yaml +apiVersion: kubeadm.k8s.io/v1beta2 +kind: ClusterConfiguration +controllerManager: + extraArgs: + cluster-signing-cert-file: /etc/kubernetes/pki/ca.crt + cluster-signing-key-file: /etc/kubernetes/pki/ca.key +``` ### Create certificate signing requests (CSR) You can create the certificate signing requests for the Kubernetes certificates API with `kubeadm alpha certs renew --use-api`. -If you set up an external signer such as [cert-manager][cert-manager], certificate signing requests (CSRs) are automatically approved. -Otherwise, you must manually approve certificates with the [`kubectl certificate`][certs] command. +If you set up an external signer such as [cert-manager](https://github.com/jetstack/cert-manager), certificate signing requests (CSRs) are automatically approved. +Otherwise, you must manually approve certificates with the [`kubectl certificate`](/docs/setup/best-practices/certificates/) command. The following kubeadm command outputs the name of the certificate to approve, then blocks and waits for approval to occur: ```shell @@ -197,7 +189,7 @@ The output is similar to this: If you set up an external signer, certificate signing requests (CSRs) are automatically approved. -Otherwise, you must manually approve certificates with the [`kubectl certificate`][certs] command. e.g. +Otherwise, you must manually approve certificates with the [`kubectl certificate`](/docs/setup/best-practices/certificates/) command. e.g. ```shell kubectl certificate approve kubeadm-cert-kube-apiserver-ld526 @@ -229,20 +221,16 @@ Certificates can be renewed with `kubeadm alpha certs renew --csr-only`. As with `kubeadm init`, an output directory can be specified with the `--csr-dir` flag. A CSR contains a certificate's name, domains, and IPs, but it does not specify usages. -It is the responsibility of the CA to specify [the correct cert usages][cert-table] when issuing a certificate. +It is the responsibility of the CA to specify [the correct cert usages](/docs/setup/best-practices/certificates/#all-certificates) +when issuing a certificate. -* In `openssl` this is done with the [`openssl ca` command][openssl-ca]. -* In `cfssl` you specify [usages in the config file][cfssl-usages] +* In `openssl` this is done with the + [`openssl ca` command](https://superuser.com/questions/738612/openssl-ca-keyusage-extension). +* In `cfssl` you specify + [usages in the config file](https://github.com/cloudflare/cfssl/blob/master/doc/cmd/cfssl.txt#L170). After a certificate is signed using your preferred method, the certificate and the private key must be copied to the PKI directory (by default `/etc/kubernetes/pki`). -[cert-manager]: https://github.com/jetstack/cert-manager -[openssl-ca]: https://superuser.com/questions/738612/openssl-ca-keyusage-extension -[cfssl-usages]: https://github.com/cloudflare/cfssl/blob/master/doc/cmd/cfssl.txt#L170 -[certs]: /docs/setup/best-practices/certificates/ -[cert-cas]: /docs/setup/best-practices/certificates/#single-root-ca -[cert-table]: /docs/setup/best-practices/certificates/#all-certificates - ## Certificate authority (CA) rotation {#certificate-authority-rotation} Kubeadm does not support rotation or replacement of CA certificates out of the box. diff --git a/content/en/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade.md b/content/en/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade.md index 2c4c3d135e..a763f36a58 100644 --- a/content/en/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade.md +++ b/content/en/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade.md @@ -26,11 +26,8 @@ The upgrade workflow at high level is the following: 1. Upgrade additional control plane nodes. 1. Upgrade worker nodes. - - ## {{% heading "prerequisites" %}} - - You need to have a kubeadm Kubernetes cluster running version 1.17.0 or later. - [Swap must be disabled](https://serverfault.com/questions/684771/best-way-to-disable-swap-in-linux). - The cluster should use a static control plane and etcd pods or external etcd. @@ -45,8 +42,6 @@ The upgrade workflow at high level is the following: or between PATCH versions of the same MINOR. That is, you cannot skip MINOR versions when you upgrade. For example, you can upgrade from 1.y to 1.y+1, but not from 1.y to 1.y+2. - - <!-- steps --> ## Determine which version to upgrade to @@ -445,3 +440,4 @@ and post-upgrade manifest file for a certain component, a backup file for it wil - Fetches the kubeadm `ClusterConfiguration` from the cluster. - Upgrades the kubelet configuration for this node. + diff --git a/content/en/docs/tasks/administer-cluster/limit-storage-consumption.md b/content/en/docs/tasks/administer-cluster/limit-storage-consumption.md index 13dec384ea..1347dc85a7 100644 --- a/content/en/docs/tasks/administer-cluster/limit-storage-consumption.md +++ b/content/en/docs/tasks/administer-cluster/limit-storage-consumption.md @@ -8,7 +8,7 @@ content_type: task This example demonstrates an easy way to limit the amount of storage consumed in a namespace. The following resources are used in the demonstration: [ResourceQuota](/docs/concepts/policy/resource-quotas/), -[LimitRange](/docs/tasks/administer-cluster/memory-default-namespace/), +[LimitRange](/docs/tasks/administer-cluster/manage-resources/memory-default-namespace/), and [PersistentVolumeClaim](/docs/concepts/storage/persistent-volumes/). diff --git a/content/en/docs/tasks/administer-cluster/manage-resources/cpu-constraint-namespace.md b/content/en/docs/tasks/administer-cluster/manage-resources/cpu-constraint-namespace.md index d3d1541d27..e3758e05c9 100644 --- a/content/en/docs/tasks/administer-cluster/manage-resources/cpu-constraint-namespace.md +++ b/content/en/docs/tasks/administer-cluster/manage-resources/cpu-constraint-namespace.md @@ -202,7 +202,7 @@ resources: ``` Because your Container did not specify its own CPU request and limit, it was given the -[default CPU request and limit](/docs/tasks/administer-cluster/cpu-default-namespace/) +[default CPU request and limit](/docs/tasks/administer-cluster/manage-resources/cpu-default-namespace/) from the LimitRange. At this point, your Container might be running or it might not be running. Recall that a prerequisite for this task is that your cluster must have at least 1 CPU available for use. If each of your Nodes has only 1 CPU, then there might not be enough allocatable CPU on any Node to accommodate a request of 800 millicpu. If you happen to be using Nodes with 2 CPU, then you probably have enough CPU to accommodate the 800 millicpu request. @@ -247,15 +247,15 @@ kubectl delete namespace constraints-cpu-example ### For cluster administrators -* [Configure Default Memory Requests and Limits for a Namespace](/docs/tasks/administer-cluster/memory-default-namespace/) +* [Configure Default Memory Requests and Limits for a Namespace](/docs/tasks/administer-cluster/manage-resources/memory-default-namespace/) -* [Configure Default CPU Requests and Limits for a Namespace](/docs/tasks/administer-cluster/cpu-default-namespace/) +* [Configure Default CPU Requests and Limits for a Namespace](/docs/tasks/administer-cluster/manage-resources/cpu-default-namespace/) -* [Configure Minimum and Maximum Memory Constraints for a Namespace](/docs/tasks/administer-cluster/memory-constraint-namespace/) +* [Configure Minimum and Maximum Memory Constraints for a Namespace](/docs/tasks/administer-cluster/manage-resources/memory-constraint-namespace/) -* [Configure Memory and CPU Quotas for a Namespace](/docs/tasks/administer-cluster/quota-memory-cpu-namespace/) +* [Configure Memory and CPU Quotas for a Namespace](/docs/tasks/administer-cluster/manage-resources/quota-memory-cpu-namespace/) -* [Configure a Pod Quota for a Namespace](/docs/tasks/administer-cluster/quota-pod-namespace/) +* [Configure a Pod Quota for a Namespace](/docs/tasks/administer-cluster/manage-resources/quota-pod-namespace/) * [Configure Quotas for API Objects](/docs/tasks/administer-cluster/quota-api-object/) diff --git a/content/en/docs/tasks/administer-cluster/manage-resources/cpu-default-namespace.md b/content/en/docs/tasks/administer-cluster/manage-resources/cpu-default-namespace.md index d2e15c91da..0156d67e4d 100644 --- a/content/en/docs/tasks/administer-cluster/manage-resources/cpu-default-namespace.md +++ b/content/en/docs/tasks/administer-cluster/manage-resources/cpu-default-namespace.md @@ -171,15 +171,15 @@ kubectl delete namespace default-cpu-example ### For cluster administrators -* [Configure Default Memory Requests and Limits for a Namespace](/docs/tasks/administer-cluster/memory-default-namespace/) +* [Configure Default Memory Requests and Limits for a Namespace](/docs/tasks/administer-cluster/manage-resources/memory-default-namespace/) -* [Configure Minimum and Maximum Memory Constraints for a Namespace](/docs/tasks/administer-cluster/memory-constraint-namespace/) +* [Configure Minimum and Maximum Memory Constraints for a Namespace](/docs/tasks/administer-cluster/manage-resources/memory-constraint-namespace/) -* [Configure Minimum and Maximum CPU Constraints for a Namespace](/docs/tasks/administer-cluster/cpu-constraint-namespace/) +* [Configure Minimum and Maximum CPU Constraints for a Namespace](/docs/tasks/administer-cluster/manage-resources/cpu-constraint-namespace/) -* [Configure Memory and CPU Quotas for a Namespace](/docs/tasks/administer-cluster/quota-memory-cpu-namespace/) +* [Configure Memory and CPU Quotas for a Namespace](/docs/tasks/administer-cluster/manage-resources/quota-memory-cpu-namespace/) -* [Configure a Pod Quota for a Namespace](/docs/tasks/administer-cluster/quota-pod-namespace/) +* [Configure a Pod Quota for a Namespace](/docs/tasks/administer-cluster/manage-resources/quota-pod-namespace/) * [Configure Quotas for API Objects](/docs/tasks/administer-cluster/quota-api-object/) diff --git a/content/en/docs/tasks/administer-cluster/manage-resources/memory-constraint-namespace.md b/content/en/docs/tasks/administer-cluster/manage-resources/memory-constraint-namespace.md index a5ad383e78..de80b80ce3 100644 --- a/content/en/docs/tasks/administer-cluster/manage-resources/memory-constraint-namespace.md +++ b/content/en/docs/tasks/administer-cluster/manage-resources/memory-constraint-namespace.md @@ -198,7 +198,7 @@ resources: ``` Because your Container did not specify its own memory request and limit, it was given the -[default memory request and limit](/docs/tasks/administer-cluster/memory-default-namespace/) +[default memory request and limit](/docs/tasks/administer-cluster/manage-resources/memory-default-namespace/) from the LimitRange. At this point, your Container might be running or it might not be running. Recall that a prerequisite @@ -247,15 +247,15 @@ kubectl delete namespace constraints-mem-example ### For cluster administrators -* [Configure Default Memory Requests and Limits for a Namespace](/docs/tasks/administer-cluster/memory-default-namespace/) +* [Configure Default Memory Requests and Limits for a Namespace](/docs/tasks/administer-cluster/manage-resources/memory-default-namespace/) -* [Configure Default CPU Requests and Limits for a Namespace](/docs/tasks/administer-cluster/cpu-default-namespace/) +* [Configure Default CPU Requests and Limits for a Namespace](/docs/tasks/administer-cluster/manage-resources/cpu-default-namespace/) -* [Configure Minimum and Maximum CPU Constraints for a Namespace](/docs/tasks/administer-cluster/cpu-constraint-namespace/) +* [Configure Minimum and Maximum CPU Constraints for a Namespace](/docs/tasks/administer-cluster/manage-resources/cpu-constraint-namespace/) -* [Configure Memory and CPU Quotas for a Namespace](/docs/tasks/administer-cluster/quota-memory-cpu-namespace/) +* [Configure Memory and CPU Quotas for a Namespace](/docs/tasks/administer-cluster/manage-resources/quota-memory-cpu-namespace/) -* [Configure a Pod Quota for a Namespace](/docs/tasks/administer-cluster/quota-pod-namespace/) +* [Configure a Pod Quota for a Namespace](/docs/tasks/administer-cluster/manage-resources/quota-pod-namespace/) * [Configure Quotas for API Objects](/docs/tasks/administer-cluster/quota-api-object/) diff --git a/content/en/docs/tasks/administer-cluster/manage-resources/memory-default-namespace.md b/content/en/docs/tasks/administer-cluster/manage-resources/memory-default-namespace.md index df7fce39f2..d2f4790abc 100644 --- a/content/en/docs/tasks/administer-cluster/manage-resources/memory-default-namespace.md +++ b/content/en/docs/tasks/administer-cluster/manage-resources/memory-default-namespace.md @@ -178,15 +178,15 @@ kubectl delete namespace default-mem-example ### For cluster administrators -* [Configure Default CPU Requests and Limits for a Namespace](/docs/tasks/administer-cluster/cpu-default-namespace/) +* [Configure Default CPU Requests and Limits for a Namespace](/docs/tasks/administer-cluster/manage-resources/cpu-default-namespace/) -* [Configure Minimum and Maximum Memory Constraints for a Namespace](/docs/tasks/administer-cluster/memory-constraint-namespace/) +* [Configure Minimum and Maximum Memory Constraints for a Namespace](/docs/tasks/administer-cluster/manage-resources/memory-constraint-namespace/) -* [Configure Minimum and Maximum CPU Constraints for a Namespace](/docs/tasks/administer-cluster/cpu-constraint-namespace/) +* [Configure Minimum and Maximum CPU Constraints for a Namespace](/docs/tasks/administer-cluster/manage-resources/cpu-constraint-namespace/) -* [Configure Memory and CPU Quotas for a Namespace](/docs/tasks/administer-cluster/quota-memory-cpu-namespace/) +* [Configure Memory and CPU Quotas for a Namespace](/docs/tasks/administer-cluster/manage-resources/quota-memory-cpu-namespace/) -* [Configure a Pod Quota for a Namespace](/docs/tasks/administer-cluster/quota-pod-namespace/) +* [Configure a Pod Quota for a Namespace](/docs/tasks/administer-cluster/manage-resources/quota-pod-namespace/) * [Configure Quotas for API Objects](/docs/tasks/administer-cluster/quota-api-object/) diff --git a/content/en/docs/tasks/administer-cluster/manage-resources/quota-memory-cpu-namespace.md b/content/en/docs/tasks/administer-cluster/manage-resources/quota-memory-cpu-namespace.md index d69e3d29d6..4869c35e06 100644 --- a/content/en/docs/tasks/administer-cluster/manage-resources/quota-memory-cpu-namespace.md +++ b/content/en/docs/tasks/administer-cluster/manage-resources/quota-memory-cpu-namespace.md @@ -137,7 +137,7 @@ the memory request total for all Containers running in a namespace. You can also restrict the totals for memory limit, cpu request, and cpu limit. If you want to restrict individual Containers, instead of totals for all Containers, use a -[LimitRange](/docs/tasks/administer-cluster/memory-constraint-namespace/). +[LimitRange](/docs/tasks/administer-cluster/manage-resources/memory-constraint-namespace/). ## Clean up @@ -154,15 +154,15 @@ kubectl delete namespace quota-mem-cpu-example ### For cluster administrators -* [Configure Default Memory Requests and Limits for a Namespace](/docs/tasks/administer-cluster/memory-default-namespace/) +* [Configure Default Memory Requests and Limits for a Namespace](/docs/tasks/administer-cluster/manage-resources/memory-default-namespace/) -* [Configure Default CPU Requests and Limits for a Namespace](/docs/tasks/administer-cluster/cpu-default-namespace/) +* [Configure Default CPU Requests and Limits for a Namespace](/docs/tasks/administer-cluster/manage-resources/cpu-default-namespace/) -* [Configure Minimum and Maximum Memory Constraints for a Namespace](/docs/tasks/administer-cluster/memory-constraint-namespace/) +* [Configure Minimum and Maximum Memory Constraints for a Namespace](/docs/tasks/administer-cluster/manage-resources/memory-constraint-namespace/) -* [Configure Minimum and Maximum CPU Constraints for a Namespace](/docs/tasks/administer-cluster/cpu-constraint-namespace/) +* [Configure Minimum and Maximum CPU Constraints for a Namespace](/docs/tasks/administer-cluster/manage-resources/cpu-constraint-namespace/) -* [Configure a Pod Quota for a Namespace](/docs/tasks/administer-cluster/quota-pod-namespace/) +* [Configure a Pod Quota for a Namespace](/docs/tasks/administer-cluster/manage-resources/quota-pod-namespace/) * [Configure Quotas for API Objects](/docs/tasks/administer-cluster/quota-api-object/) diff --git a/content/en/docs/tasks/administer-cluster/manage-resources/quota-pod-namespace.md b/content/en/docs/tasks/administer-cluster/manage-resources/quota-pod-namespace.md index c44a07681f..b0485f2b45 100644 --- a/content/en/docs/tasks/administer-cluster/manage-resources/quota-pod-namespace.md +++ b/content/en/docs/tasks/administer-cluster/manage-resources/quota-pod-namespace.md @@ -115,15 +115,15 @@ kubectl delete namespace quota-pod-example ### For cluster administrators -* [Configure Default Memory Requests and Limits for a Namespace](/docs/tasks/administer-cluster/memory-default-namespace/) +* [Configure Default Memory Requests and Limits for a Namespace](/docs/tasks/administer-cluster/manage-resources/memory-default-namespace/) -* [Configure Default CPU Requests and Limits for a Namespace](/docs/tasks/administer-cluster/cpu-default-namespace/) +* [Configure Default CPU Requests and Limits for a Namespace](/docs/tasks/administer-cluster/manage-resources/cpu-default-namespace/) -* [Configure Minimum and Maximum Memory Constraints for a Namespace](/docs/tasks/administer-cluster/memory-constraint-namespace/) +* [Configure Minimum and Maximum Memory Constraints for a Namespace](/docs/tasks/administer-cluster/manage-resources/memory-constraint-namespace/) -* [Configure Minimum and Maximum CPU Constraints for a Namespace](/docs/tasks/administer-cluster/cpu-constraint-namespace/) +* [Configure Minimum and Maximum CPU Constraints for a Namespace](/docs/tasks/administer-cluster/manage-resources/cpu-constraint-namespace/) -* [Configure Memory and CPU Quotas for a Namespace](/docs/tasks/administer-cluster/quota-memory-cpu-namespace/) +* [Configure Memory and CPU Quotas for a Namespace](/docs/tasks/administer-cluster/manage-resources/quota-memory-cpu-namespace/) * [Configure Quotas for API Objects](/docs/tasks/administer-cluster/quota-api-object/) diff --git a/content/en/docs/tasks/administer-cluster/namespaces-walkthrough.md b/content/en/docs/tasks/administer-cluster/namespaces-walkthrough.md index 2bf0de8231..1d3d34867c 100644 --- a/content/en/docs/tasks/administer-cluster/namespaces-walkthrough.md +++ b/content/en/docs/tasks/administer-cluster/namespaces-walkthrough.md @@ -36,7 +36,7 @@ This example demonstrates how to use Kubernetes namespaces to subdivide your clu This example assumes the following: 1. You have an [existing Kubernetes cluster](/docs/setup/). -2. You have a basic understanding of Kubernetes _[Pods](/docs/concepts/workloads/pods/pod/)_, _[Services](/docs/concepts/services-networking/service/)_, and _[Deployments](/docs/concepts/workloads/controllers/deployment/)_. +2. You have a basic understanding of Kubernetes {{< glossary_tooltip text="Pods" term_id="pod" >}}, {{< glossary_tooltip term_id="service" text="Services" >}}, and {{< glossary_tooltip text="Deployments" term_id="deployment" >}}. ## Understand the default namespace diff --git a/content/en/docs/tasks/administer-cluster/namespaces.md b/content/en/docs/tasks/administer-cluster/namespaces.md index be7906e40f..3266f06602 100644 --- a/content/en/docs/tasks/administer-cluster/namespaces.md +++ b/content/en/docs/tasks/administer-cluster/namespaces.md @@ -13,7 +13,7 @@ This page shows how to view, work in, and delete {{< glossary_tooltip text="name ## {{% heading "prerequisites" %}} * Have an [existing Kubernetes cluster](/docs/setup/). -* Have a basic understanding of Kubernetes _[Pods](/docs/concepts/workloads/pods/pod/)_, _[Services](/docs/concepts/services-networking/service/)_, and _[Deployments](/docs/concepts/workloads/controllers/deployment/)_. +2. You have a basic understanding of Kubernetes {{< glossary_tooltip text="Pods" term_id="pod" >}}, {{< glossary_tooltip term_id="service" text="Services" >}}, and {{< glossary_tooltip text="Deployments" term_id="deployment" >}}. <!-- steps --> @@ -82,6 +82,10 @@ See the [design doc](https://git.k8s.io/community/contributors/design-proposals/ ## Creating a new namespace +{{< note >}} + Avoid creating namespace with prefix `kube-`, since it is reserved for Kubernetes system namespaces. +{{< /note >}} + 1. Create a new YAML file called `my-namespace.yaml` with the contents: ```yaml diff --git a/content/en/docs/tasks/administer-cluster/network-policy-provider/romana-network-policy.md b/content/en/docs/tasks/administer-cluster/network-policy-provider/romana-network-policy.md index df6adcd39f..93312e199e 100644 --- a/content/en/docs/tasks/administer-cluster/network-policy-provider/romana-network-policy.md +++ b/content/en/docs/tasks/administer-cluster/network-policy-provider/romana-network-policy.md @@ -10,14 +10,9 @@ weight: 40 This page shows how to use Romana for NetworkPolicy. - - ## {{% heading "prerequisites" %}} - -Complete steps 1, 2, and 3 of the [kubeadm getting started guide](/docs/getting-started-guides/kubeadm/). - - +Complete steps 1, 2, and 3 of the [kubeadm getting started guide](/docs/reference/setup-tools/kubeadm/kubeadm/). <!-- steps --> @@ -33,13 +28,10 @@ To apply network policies use one of the following: * [Example of Romana network policy](https://github.com/romana/core/blob/master/doc/policy.md). * The NetworkPolicy API. - - ## {{% heading "whatsnext" %}} - -Once you have installed Romana, you can follow the [Declare Network Policy](/docs/tasks/administer-cluster/declare-network-policy/) to try out Kubernetes NetworkPolicy. - - +Once you have installed Romana, you can follow the +[Declare Network Policy](/docs/tasks/administer-cluster/declare-network-policy/) +to try out Kubernetes NetworkPolicy. diff --git a/content/en/docs/tasks/administer-cluster/network-policy-provider/weave-network-policy.md b/content/en/docs/tasks/administer-cluster/network-policy-provider/weave-network-policy.md index a9d15f40a6..b6b562620a 100644 --- a/content/en/docs/tasks/administer-cluster/network-policy-provider/weave-network-policy.md +++ b/content/en/docs/tasks/administer-cluster/network-policy-provider/weave-network-policy.md @@ -10,14 +10,10 @@ weight: 50 This page shows how to use Weave Net for NetworkPolicy. - - ## {{% heading "prerequisites" %}} - -You need to have a Kubernetes cluster. Follow the [kubeadm getting started guide](/docs/getting-started-guides/kubeadm/) to bootstrap one. - - +You need to have a Kubernetes cluster. Follow the +[kubeadm getting started guide](/docs/reference/setup-tools/kubeadm/kubeadm/) to bootstrap one. <!-- steps --> @@ -25,7 +21,10 @@ You need to have a Kubernetes cluster. Follow the [kubeadm getting started guide Follow the [Integrating Kubernetes via the Addon](https://www.weave.works/docs/net/latest/kube-addon/) guide. -The Weave Net addon for Kubernetes comes with a [Network Policy Controller](https://www.weave.works/docs/net/latest/kube-addon/#npc) that automatically monitors Kubernetes for any NetworkPolicy annotations on all namespaces and configures `iptables` rules to allow or block traffic as directed by the policies. +The Weave Net addon for Kubernetes comes with a +[Network Policy Controller](https://www.weave.works/docs/net/latest/kube-addon/#npc) +that automatically monitors Kubernetes for any NetworkPolicy annotations on all +namespaces and configures `iptables` rules to allow or block traffic as directed by the policies. ## Test the installation @@ -49,13 +48,10 @@ weave-net-pmw8w 2/2 Running 0 9d Each Node has a weave Pod, and all Pods are `Running` and `2/2 READY`. (`2/2` means that each Pod has `weave` and `weave-npc`.) - - ## {{% heading "whatsnext" %}} - -Once you have installed the Weave Net addon, you can follow the [Declare Network Policy](/docs/tasks/administer-cluster/declare-network-policy/) to try out Kubernetes NetworkPolicy. If you have any question, contact us at [#weave-community on Slack or Weave User Group](https://github.com/weaveworks/weave#getting-help). - - - +Once you have installed the Weave Net addon, you can follow the +[Declare Network Policy](/docs/tasks/administer-cluster/declare-network-policy/) +to try out Kubernetes NetworkPolicy. If you have any question, contact us at +[#weave-community on Slack or Weave User Group](https://github.com/weaveworks/weave#getting-help). diff --git a/content/en/docs/tasks/administer-cluster/out-of-resource.md b/content/en/docs/tasks/administer-cluster/out-of-resource.md index a9d2ee3702..10ef986b8c 100644 --- a/content/en/docs/tasks/administer-cluster/out-of-resource.md +++ b/content/en/docs/tasks/administer-cluster/out-of-resource.md @@ -16,9 +16,6 @@ are low. This is especially important when dealing with incompressible compute resources, such as memory or disk space. If such resources are exhausted, nodes become unstable. - - - <!-- body --> ## Eviction Policy @@ -53,8 +50,7 @@ like `free -m`. This is important because `free -m` does not work in a container, and if users use the [node allocatable](/docs/tasks/administer-cluster/reserve-compute-resources/#node-allocatable) feature, out of resource decisions are made local to the end user Pod part of the cgroup hierarchy as well as the -root node. This -[script](/docs/tasks/administer-cluster/out-of-resource/memory-available.sh) +root node. This [script](/docs/tasks/administer-cluster/memory-available.sh) reproduces the same set of steps that the `kubelet` performs to calculate `memory.available`. The `kubelet` excludes inactive_file (i.e. # of bytes of file-backed memory on inactive LRU list) from its calculation as it assumes that diff --git a/content/en/docs/tasks/administer-cluster/quota-api-object.md b/content/en/docs/tasks/administer-cluster/quota-api-object.md index 1fb48c7a2b..11592d2152 100644 --- a/content/en/docs/tasks/administer-cluster/quota-api-object.md +++ b/content/en/docs/tasks/administer-cluster/quota-api-object.md @@ -148,17 +148,17 @@ kubectl delete namespace quota-object-example ### For cluster administrators -* [Configure Default Memory Requests and Limits for a Namespace](/docs/tasks/administer-cluster/memory-default-namespace/) +* [Configure Default Memory Requests and Limits for a Namespace](/docs/tasks/administer-cluster/manage-resources/memory-default-namespace/) -* [Configure Default CPU Requests and Limits for a Namespace](/docs/tasks/administer-cluster/cpu-default-namespace/) +* [Configure Default CPU Requests and Limits for a Namespace](/docs/tasks/administer-cluster/manage-resources/cpu-default-namespace/) -* [Configure Minimum and Maximum Memory Constraints for a Namespace](/docs/tasks/administer-cluster/memory-constraint-namespace/) +* [Configure Minimum and Maximum Memory Constraints for a Namespace](/docs/tasks/administer-cluster/manage-resources/memory-constraint-namespace/) -* [Configure Minimum and Maximum CPU Constraints for a Namespace](/docs/tasks/administer-cluster/cpu-constraint-namespace/) +* [Configure Minimum and Maximum CPU Constraints for a Namespace](/docs/tasks/administer-cluster/manage-resources/cpu-constraint-namespace/) -* [Configure Memory and CPU Quotas for a Namespace](/docs/tasks/administer-cluster/quota-memory-cpu-namespace/) +* [Configure Memory and CPU Quotas for a Namespace](/docs/tasks/administer-cluster/manage-resources/quota-memory-cpu-namespace/) -* [Configure a Pod Quota for a Namespace](/docs/tasks/administer-cluster/quota-pod-namespace/) +* [Configure a Pod Quota for a Namespace](/docs/tasks/administer-cluster/manage-resources/quota-pod-namespace/) ### For app developers diff --git a/content/en/docs/tasks/administer-cluster/reconfigure-kubelet.md b/content/en/docs/tasks/administer-cluster/reconfigure-kubelet.md index 6218e8ce81..7f56e4ec85 100644 --- a/content/en/docs/tasks/administer-cluster/reconfigure-kubelet.md +++ b/content/en/docs/tasks/administer-cluster/reconfigure-kubelet.md @@ -38,7 +38,7 @@ if your cluster is running v1.16 then you can use kubectl v1.15, v1.16 or v1.17; other combinations [aren't supported](/docs/setup/release/version-skew-policy/#kubectl). -Some of the examples use the commandline tool +Some of the examples use the command line tool [jq](https://stedolan.github.io/jq/). You do not need `jq` to complete the task, because there are manual alternatives. @@ -380,4 +380,4 @@ internal failure, see Kubelet log for details | The kubelet encountered some int - For more information on configuring the kubelet via a configuration file, see [Set kubelet parameters via a config file](/docs/tasks/administer-cluster/kubelet-config-file). -- See the reference documentation for [`NodeConfigSource`](https://kubernetes.io/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#nodeconfigsource-v1-core) +- See the reference documentation for [`NodeConfigSource`](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#nodeconfigsource-v1-core) diff --git a/content/en/docs/tasks/administer-cluster/safely-drain-node.md b/content/en/docs/tasks/administer-cluster/safely-drain-node.md index e18b2ed87d..ed1b9657c8 100644 --- a/content/en/docs/tasks/administer-cluster/safely-drain-node.md +++ b/content/en/docs/tasks/administer-cluster/safely-drain-node.md @@ -34,7 +34,7 @@ This task assumes that you have met the following prerequisites: You can use `kubectl drain` to safely evict all of your pods from a node before you perform maintenance on the node (e.g. kernel upgrade, hardware maintenance, etc.). Safe evictions allow the pod's containers -to [gracefully terminate](/docs/concepts/workloads/pods/pod/#termination-of-pods) +to [gracefully terminate](/docs/concepts/workloads/pods/pod-lifecycle/#pod-termination) and will respect the `PodDisruptionBudgets` you have specified. {{< note >}} diff --git a/content/en/docs/tasks/administer-cluster/securing-a-cluster.md b/content/en/docs/tasks/administer-cluster/securing-a-cluster.md index 7e558fb48f..090e292966 100644 --- a/content/en/docs/tasks/administer-cluster/securing-a-cluster.md +++ b/content/en/docs/tasks/administer-cluster/securing-a-cluster.md @@ -32,17 +32,17 @@ they are allowed to perform is the first line of defense. ### Use Transport Layer Security (TLS) for all API traffic Kubernetes expects that all API communication in the cluster is encrypted by default with TLS, and the -majority of installation methods will allow the necessary certificates to be created and distributed to -the cluster components. Note that some components and installation methods may enable local ports over -HTTP and administrators should familiarize themselves with the settings of each component to identify +majority of installation methods will allow the necessary certificates to be created and distributed to +the cluster components. Note that some components and installation methods may enable local ports over +HTTP and administrators should familiarize themselves with the settings of each component to identify potentially unsecured traffic. ### API Authentication -Choose an authentication mechanism for the API servers to use that matches the common access patterns -when you install a cluster. For instance, small single user clusters may wish to use a simple certificate +Choose an authentication mechanism for the API servers to use that matches the common access patterns +when you install a cluster. For instance, small single user clusters may wish to use a simple certificate or static Bearer token approach. Larger clusters may wish to integrate an existing OIDC or LDAP server that -allow users to be subdivided into groups. +allow users to be subdivided into groups. All API clients must be authenticated, even those that are part of the infrastructure like nodes, proxies, the scheduler, and volume plugins. These clients are typically [service accounts](/docs/reference/access-authn-authz/service-accounts-admin/) or use x509 client certificates, and they are created automatically at cluster startup or are setup as part of the cluster installation. @@ -56,17 +56,19 @@ an integrated [Role-Based Access Control (RBAC)](/docs/reference/access-authn-au set of permissions bundled into roles. These permissions combine verbs (get, create, delete) with resources (pods, services, nodes) and can be namespace or cluster scoped. A set of out of the box roles are provided that offer reasonable default separation of responsibility depending on what -actions a client might want to perform. It is recommended that you use the [Node](/docs/reference/access-authn-authz/node/) and [RBAC](/docs/reference/access-authn-authz/rbac/) authorizers together, in combination with the +actions a client might want to perform. It is recommended that you use the +[Node](/docs/reference/access-authn-authz/node/) and +[RBAC](/docs/reference/access-authn-authz/rbac/) authorizers together, in combination with the [NodeRestriction](/docs/reference/access-authn-authz/admission-controllers/#noderestriction) admission plugin. As with authentication, simple and broad roles may be appropriate for smaller clusters, but as more users interact with the cluster, it may become necessary to separate teams into separate namespaces with more limited roles. -With authorization, it is important to understand how updates on one object may cause actions in -other places. For instance, a user may not be able to create pods directly, but allowing them to -create a deployment, which creates pods on their behalf, will let them create those pods -indirectly. Likewise, deleting a node from the API will result in the pods scheduled to that node +With authorization, it is important to understand how updates on one object may cause actions in +other places. For instance, a user may not be able to create pods directly, but allowing them to +create a deployment, which creates pods on their behalf, will let them create those pods +indirectly. Likewise, deleting a node from the API will result in the pods scheduled to that node being terminated and recreated on other nodes. The out of the box roles represent a balance between flexibility and the common use cases, but more limited roles should be carefully reviewed to prevent accidental escalation. You can make roles specific to your use case if the out-of-box ones don't meet your needs. @@ -79,12 +81,12 @@ Kubelets expose HTTPS endpoints which grant powerful control over the node and c Production clusters should enable Kubelet authentication and authorization. -Consult the [Kubelet authentication/authorization reference](/docs/admin/kubelet-authentication-authorization) for more information. +Consult the [Kubelet authentication/authorization reference](/docs/reference/command-line-tools-reference/kubelet-authentication-authorization) for more information. ## Controlling the capabilities of a workload or user at runtime Authorization in Kubernetes is intentionally high level, focused on coarse actions on resources. -More powerful controls exist as **policies** to limit by use case how those objects act on the +More powerful controls exist as **policies** to limit by use case how those objects act on the cluster, themselves, and other resources. ### Limiting resource usage on a cluster @@ -92,9 +94,9 @@ cluster, themselves, and other resources. [Resource quota](/docs/concepts/policy/resource-quotas/) limits the number or capacity of resources granted to a namespace. This is most often used to limit the amount of CPU, memory, or persistent disk a namespace can allocate, but can also control how many pods, services, or -volumes exist in each namespace. +volumes exist in each namespace. -[Limit ranges](/docs/tasks/administer-cluster/memory-default-namespace/) restrict the maximum or minimum size of some of the +[Limit ranges](/docs/tasks/administer-cluster/manage-resources/memory-default-namespace/) restrict the maximum or minimum size of some of the resources above, to prevent users from requesting unreasonably high or low values for commonly reserved resources like memory, or to provide default limits when none are specified. @@ -104,14 +106,14 @@ reserved resources like memory, or to provide default limits when none are speci A pod definition contains a [security context](/docs/tasks/configure-pod-container/security-context/) that allows it to request access to running as a specific Linux user on a node (like root), access to run privileged or access the host network, and other controls that would otherwise -allow it to run unfettered on a hosting node. [Pod security policies](/docs/concepts/policy/pod-security-policy/) +allow it to run unfettered on a hosting node. [Pod security policies](/docs/concepts/policy/pod-security-policy/) can limit which users or service accounts can provide dangerous security context settings. For example, pod security policies can limit volume mounts, especially `hostPath`, which are aspects of a pod that should be controlled. -Generally, most application workloads need limited access to host resources so they can -successfully run as a root process (uid 0) without access to host information. However, -considering the privileges associated with the root user, you should write application -containers to run as a non-root user. Similarly, administrators who wish to prevent -client applications from escaping their containers should use a restrictive pod security +Generally, most application workloads need limited access to host resources so they can +successfully run as a root process (uid 0) without access to host information. However, +considering the privileges associated with the root user, you should write application +containers to run as a non-root user. Similarly, administrators who wish to prevent +client applications from escaping their containers should use a restrictive pod security policy. @@ -147,8 +149,8 @@ kernel on behalf of some more-privileged process.) ### Restricting network access -The [network policies](/docs/tasks/administer-cluster/declare-network-policy/) for a namespace -allows application authors to restrict which pods in other namespaces may access pods and ports +The [network policies](/docs/tasks/administer-cluster/declare-network-policy/) for a namespace +allows application authors to restrict which pods in other namespaces may access pods and ports within their namespaces. Many of the supported [Kubernetes networking providers](/docs/concepts/cluster-administration/networking/) now respect network policy. @@ -157,7 +159,7 @@ load balanced services, which on many clusters can control whether those users a are visible outside of the cluster. Additional protections may be available that control network rules on a per plugin or per -environment basis, such as per-node firewalls, physically separating cluster nodes to +environment basis, such as per-node firewalls, physically separating cluster nodes to prevent cross talk, or advanced networking policy. ### Restricting cloud metadata API access @@ -173,14 +175,14 @@ to the metadata API, and avoid using provisioning data to deliver secrets. ### Controlling which nodes pods may access -By default, there are no restrictions on which nodes may run a pod. Kubernetes offers a +By default, there are no restrictions on which nodes may run a pod. Kubernetes offers a [rich set of policies for controlling placement of pods onto nodes](/docs/concepts/scheduling-eviction/assign-pod-node/) and the [taint based pod placement and eviction](/docs/concepts/scheduling-eviction/taint-and-toleration/) that are available to end users. For many clusters use of these policies to separate workloads can be a convention that authors adopt or enforce via tooling. -As an administrator, a beta admission plugin `PodNodeSelector` can be used to force pods -within a namespace to default or require a specific node selector, and if end users cannot +As an administrator, a beta admission plugin `PodNodeSelector` can be used to force pods +within a namespace to default or require a specific node selector, and if end users cannot alter namespaces, this can strongly limit the placement of all of the pods in a specific workload. @@ -194,7 +196,7 @@ Write access to the etcd backend for the API is equivalent to gaining root on th and read access can be used to escalate fairly quickly. Administrators should always use strong credentials from the API servers to their etcd server, such as mutual auth via TLS client certificates, and it is often recommended to isolate the etcd servers behind a firewall that only the API servers -may access. +may access. {{< caution >}} Allowing other components within the cluster to access the master etcd instance with @@ -206,7 +208,7 @@ access to a subset of the keyspace is strongly recommended. ### Enable audit logging The [audit logger](/docs/tasks/debug-application-cluster/audit/) is a beta feature that records actions taken by the -API for later analysis in the event of a compromise. It is recommended to enable audit logging +API for later analysis in the event of a compromise. It is recommended to enable audit logging and archive the audit file on a secure server. ### Restrict access to alpha or beta features @@ -229,8 +231,8 @@ rotate those tokens frequently. For example, once the bootstrap phase is complet Many third party integrations to Kubernetes may alter the security profile of your cluster. When enabling an integration, always review the permissions that an extension requests before granting it access. For example, many security integrations may request access to view all secrets on -your cluster which is effectively making that component a cluster admin. When in doubt, -restrict the integration to functioning in a single namespace if possible. +your cluster which is effectively making that component a cluster admin. When in doubt, +restrict the integration to functioning in a single namespace if possible. Components that create pods may also be unexpectedly powerful if they can do so inside namespaces like the `kube-system` namespace, because those pods can gain access to service account secrets @@ -251,10 +253,9 @@ are not encrypted or an attacker gains read access to etcd. ### Receiving alerts for security updates and reporting vulnerabilities -Join the [kubernetes-announce](https://groups.google.com/forum/#!forum/kubernetes-announce) -group for emails about security announcements. See the [security reporting](/security/) +Join the [kubernetes-announce](https://groups.google.com/forum/#!forum/kubernetes-announce) +group for emails about security announcements. See the +[security reporting](/docs/reference/issues-security/security/) page for more on how to report vulnerabilities. - - diff --git a/content/en/docs/tasks/configure-pod-container/assign-cpu-resource.md b/content/en/docs/tasks/configure-pod-container/assign-cpu-resource.md index 5e79704cc4..3afda46609 100644 --- a/content/en/docs/tasks/configure-pod-container/assign-cpu-resource.md +++ b/content/en/docs/tasks/configure-pod-container/assign-cpu-resource.md @@ -254,17 +254,17 @@ kubectl delete namespace cpu-example ### For cluster administrators -* [Configure Default Memory Requests and Limits for a Namespace](/docs/tasks/administer-cluster/memory-default-namespace/) +* [Configure Default Memory Requests and Limits for a Namespace](/docs/tasks/administer-cluster/manage-resources/memory-default-namespace/) -* [Configure Default CPU Requests and Limits for a Namespace](/docs/tasks/administer-cluster/cpu-default-namespace/) +* [Configure Default CPU Requests and Limits for a Namespace](/docs/tasks/administer-cluster/manage-resources/cpu-default-namespace/) -* [Configure Minimum and Maximum Memory Constraints for a Namespace](/docs/tasks/administer-cluster/memory-constraint-namespace/) +* [Configure Minimum and Maximum Memory Constraints for a Namespace](/docs/tasks/administer-cluster/manage-resources/memory-constraint-namespace/) -* [Configure Minimum and Maximum CPU Constraints for a Namespace](/docs/tasks/administer-cluster/cpu-constraint-namespace/) +* [Configure Minimum and Maximum CPU Constraints for a Namespace](/docs/tasks/administer-cluster/manage-resources/cpu-constraint-namespace/) -* [Configure Memory and CPU Quotas for a Namespace](/docs/tasks/administer-cluster/quota-memory-cpu-namespace/) +* [Configure Memory and CPU Quotas for a Namespace](/docs/tasks/administer-cluster/manage-resources/quota-memory-cpu-namespace/) -* [Configure a Pod Quota for a Namespace](/docs/tasks/administer-cluster/quota-pod-namespace/) +* [Configure a Pod Quota for a Namespace](/docs/tasks/administer-cluster/manage-resources/quota-pod-namespace/) * [Configure Quotas for API Objects](/docs/tasks/administer-cluster/quota-api-object/) diff --git a/content/en/docs/tasks/configure-pod-container/assign-memory-resource.md b/content/en/docs/tasks/configure-pod-container/assign-memory-resource.md index 394f435d12..79bc2b86b6 100644 --- a/content/en/docs/tasks/configure-pod-container/assign-memory-resource.md +++ b/content/en/docs/tasks/configure-pod-container/assign-memory-resource.md @@ -43,7 +43,7 @@ If the resource metrics API is available, the output includes a reference to `metrics.k8s.io`. ```shell -NAME +NAME v1beta1.metrics.k8s.io ``` @@ -344,17 +344,17 @@ kubectl delete namespace mem-example ### For cluster administrators -* [Configure Default Memory Requests and Limits for a Namespace](/docs/tasks/administer-cluster/memory-default-namespace/) +* [Configure Default Memory Requests and Limits for a Namespace](/docs/tasks/administer-cluster/manage-resources/memory-default-namespace/) -* [Configure Default CPU Requests and Limits for a Namespace](/docs/tasks/administer-cluster/cpu-default-namespace/) +* [Configure Default CPU Requests and Limits for a Namespace](/docs/tasks/administer-cluster/manage-resources/cpu-default-namespace/) -* [Configure Minimum and Maximum Memory Constraints for a Namespace](/docs/tasks/administer-cluster/memory-constraint-namespace/) +* [Configure Minimum and Maximum Memory Constraints for a Namespace](/docs/tasks/administer-cluster/manage-resources/memory-constraint-namespace/) -* [Configure Minimum and Maximum CPU Constraints for a Namespace](/docs/tasks/administer-cluster/cpu-constraint-namespace/) +* [Configure Minimum and Maximum CPU Constraints for a Namespace](/docs/tasks/administer-cluster/manage-resources/cpu-constraint-namespace/) -* [Configure Memory and CPU Quotas for a Namespace](/docs/tasks/administer-cluster/quota-memory-cpu-namespace/) +* [Configure Memory and CPU Quotas for a Namespace](/docs/tasks/administer-cluster/manage-resources/quota-memory-cpu-namespace/) -* [Configure a Pod Quota for a Namespace](/docs/tasks/administer-cluster/quota-pod-namespace/) +* [Configure a Pod Quota for a Namespace](/docs/tasks/administer-cluster/manage-resources/quota-pod-namespace/) * [Configure Quotas for API Objects](/docs/tasks/administer-cluster/quota-api-object/) diff --git a/content/en/docs/tasks/configure-pod-container/attach-handler-lifecycle-event.md b/content/en/docs/tasks/configure-pod-container/attach-handler-lifecycle-event.md index f5116e7691..00b9251be8 100644 --- a/content/en/docs/tasks/configure-pod-container/attach-handler-lifecycle-event.md +++ b/content/en/docs/tasks/configure-pod-container/attach-handler-lifecycle-event.md @@ -75,7 +75,7 @@ set to RUNNING until the postStart handler completes. Kubernetes sends the preStop event immediately before the Container is terminated. Kubernetes' management of the Container blocks until the preStop handler completes, unless the Pod's grace period expires. For more details, see -[Termination of Pods](/docs/concepts/workloads/pods/pod/#termination-of-pods). +[Pod Lifecycle](/docs/concepts/workloads/pods/pod-lifecycle/). {{< note >}} Kubernetes only sends the preStop event when a Pod is *terminated*. diff --git a/content/en/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes.md b/content/en/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes.md index ed5aa24044..6d5363ee58 100644 --- a/content/en/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes.md +++ b/content/en/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes.md @@ -8,7 +8,7 @@ weight: 110 This page shows how to configure liveness, readiness and startup probes for containers. -The [kubelet](/docs/admin/kubelet/) uses liveness probes to know when to +The [kubelet](/docs/reference/command-line-tools-reference/kubelet/) uses liveness probes to know when to restart a container. For example, liveness probes could catch a deadlock, where an application is running, but unable to make progress. Restarting a container in such a state can help to make the application more available @@ -332,7 +332,7 @@ to 1 second. Minimum value is 1. * `successThreshold`: Minimum consecutive successes for the probe to be considered successful after having failed. Defaults to 1. Must be 1 for liveness. Minimum value is 1. -* `failureThreshold`: When a Pod starts and the probe fails, Kubernetes will +* `failureThreshold`: When a probe fails, Kubernetes will try `failureThreshold` times before giving up. Giving up in case of liveness probe means restarting the container. In case of readiness probe the Pod will be marked Unready. Defaults to 3. Minimum value is 1. diff --git a/content/en/docs/tasks/configure-pod-container/configure-persistent-volume-storage.md b/content/en/docs/tasks/configure-pod-container/configure-persistent-volume-storage.md index 6ff6c21530..60e45804c9 100644 --- a/content/en/docs/tasks/configure-pod-container/configure-persistent-volume-storage.md +++ b/content/en/docs/tasks/configure-pod-container/configure-persistent-volume-storage.md @@ -29,13 +29,11 @@ PersistentVolume. {{< glossary_tooltip text="kubectl" term_id="kubectl" >}} command-line tool must be configured to communicate with your cluster. If you do not already have a single-node cluster, you can create one by using -[Minikube](/docs/getting-started-guides/minikube). +[Minikube](/docs/setup/learning-environment/minikube/). * Familiarize yourself with the material in [Persistent Volumes](/docs/concepts/storage/persistent-volumes/). - - <!-- steps --> ## Create an index.html file on your Node diff --git a/content/en/docs/tasks/configure-pod-container/configure-service-account.md b/content/en/docs/tasks/configure-pod-container/configure-service-account.md index eaaabb9e94..e3f97dd5ce 100644 --- a/content/en/docs/tasks/configure-pod-container/configure-service-account.md +++ b/content/en/docs/tasks/configure-pod-container/configure-service-account.md @@ -39,10 +39,14 @@ When they do, they are authenticated as a particular Service Account (for exampl When you create a pod, if you do not specify a service account, it is automatically assigned the `default` service account in the same namespace. -If you get the raw json or yaml for a pod you have created (for example, `kubectl get pods/<podname> -o yaml`), you can see the `spec.serviceAccountName` field has been [automatically set](/docs/user-guide/working-with-resources/#resources-are-automatically-modified). +If you get the raw json or yaml for a pod you have created (for example, `kubectl get pods/<podname> -o yaml`), +you can see the `spec.serviceAccountName` field has been +[automatically set](/docs/concepts/overview/working-with-objects/object-management/). -You can access the API from inside a pod using automatically mounted service account credentials, as described in [Accessing the Cluster](/docs/user-guide/accessing-the-cluster/#accessing-the-api-from-a-pod). -The API permissions of the service account depend on the [authorization plugin and policy](/docs/reference/access-authn-authz/authorization/#authorization-modules) in use. +You can access the API from inside a pod using automatically mounted service account credentials, as described in +[Accessing the Cluster](/docs/tasks/access-application-cluster/access-cluster). +The API permissions of the service account depend on the +[authorization plugin and policy](/docs/reference/access-authn-authz/authorization/#authorization-modules) in use. In version 1.6+, you can opt out of automounting API credentials for a service account by setting `automountServiceAccountToken: false` on the service account: @@ -316,14 +320,14 @@ kubectl create -f https://k8s.io/examples/pods/pod-projected-svc-token.yaml The kubelet will request and store the token on behalf of the pod, make the token available to the pod at a configurable file path, and refresh the token as it approaches expiration. Kubelet proactively rotates the token if it is older than 80% of its total TTL, or if the token is older than 24 hours. -The application is responsible for reloading the token when it rotates. Periodic reloading (e.g. once every 5 minutes) is sufficient for most usecases. +The application is responsible for reloading the token when it rotates. Periodic reloading (e.g. once every 5 minutes) is sufficient for most use cases. ## Service Account Issuer Discovery {{< feature-state for_k8s_version="v1.18" state="alpha" >}} The Service Account Issuer Discovery feature is enabled by enabling the -`ServiceAccountIssuerDiscovery` [feature gate](/docs/reference/command-line-tools-reference/feature) +`ServiceAccountIssuerDiscovery` [feature gate](/docs/reference/command-line-tools-reference/feature-gates) and then enabling the Service Account Token Projection feature as described [above](#service-account-token-volume-projection). diff --git a/content/en/docs/tasks/configure-pod-container/quality-service-pod.md b/content/en/docs/tasks/configure-pod-container/quality-service-pod.md index dec9e8db91..79c5260ead 100644 --- a/content/en/docs/tasks/configure-pod-container/quality-service-pod.md +++ b/content/en/docs/tasks/configure-pod-container/quality-service-pod.md @@ -250,17 +250,17 @@ kubectl delete namespace qos-example ### For cluster administrators -* [Configure Default Memory Requests and Limits for a Namespace](/docs/tasks/administer-cluster/memory-default-namespace/) +* [Configure Default Memory Requests and Limits for a Namespace](/docs/tasks/administer-cluster/manage-resources/memory-default-namespace/) -* [Configure Default CPU Requests and Limits for a Namespace](/docs/tasks/administer-cluster/cpu-default-namespace/) +* [Configure Default CPU Requests and Limits for a Namespace](/docs/tasks/administer-cluster/manage-resources/cpu-default-namespace/) -* [Configure Minimum and Maximum Memory Constraints for a Namespace](/docs/tasks/administer-cluster/memory-constraint-namespace/) +* [Configure Minimum and Maximum Memory Constraints for a Namespace](/docs/tasks/administer-cluster/manage-resources/memory-constraint-namespace/) -* [Configure Minimum and Maximum CPU Constraints for a Namespace](/docs/tasks/administer-cluster/cpu-constraint-namespace/) +* [Configure Minimum and Maximum CPU Constraints for a Namespace](/docs/tasks/administer-cluster/manage-resources/cpu-constraint-namespace/) -* [Configure Memory and CPU Quotas for a Namespace](/docs/tasks/administer-cluster/quota-memory-cpu-namespace/) +* [Configure Memory and CPU Quotas for a Namespace](/docs/tasks/administer-cluster/manage-resources/quota-memory-cpu-namespace/) -* [Configure a Pod Quota for a Namespace](/docs/tasks/administer-cluster/quota-pod-namespace/) +* [Configure a Pod Quota for a Namespace](/docs/tasks/administer-cluster/manage-resources/quota-pod-namespace/) * [Configure Quotas for API Objects](/docs/tasks/administer-cluster/quota-api-object/) diff --git a/content/en/docs/tasks/configure-pod-container/security-context.md b/content/en/docs/tasks/configure-pod-container/security-context.md index 38662760b7..9f69fdccc6 100644 --- a/content/en/docs/tasks/configure-pod-container/security-context.md +++ b/content/en/docs/tasks/configure-pod-container/security-context.md @@ -30,8 +30,8 @@ a Pod or Container. Security context settings include, but are not limited to: * readOnlyRootFilesystem: Mounts the container's root filesystem as read-only. -The above bullets are not a complete set of security context settings -- please see -[SecurityContext](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#securitycontext-v1-core) +The above bullets are not a complete set of security context settings -- please see +[SecurityContext](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#securitycontext-v1-core) for a comprehensive list. For more information about security mechanisms in Linux, see @@ -59,11 +59,11 @@ Here is a configuration file for a Pod that has a `securityContext` and an `empt {{< codenew file="pods/security/security-context.yaml" >}} In the configuration file, the `runAsUser` field specifies that for any Containers in -the Pod, all processes run with user ID 1000. The `runAsGroup` field specifies the primary group ID of 3000 for +the Pod, all processes run with user ID 1000. The `runAsGroup` field specifies the primary group ID of 3000 for all processes within any containers of the Pod. If this field is omitted, the primary group ID of the containers -will be root(0). Any files created will also be owned by user 1000 and group 3000 when `runAsGroup` is specified. -Since `fsGroup` field is specified, all processes of the container are also part of the supplementary group ID 2000. -The owner for volume `/data/demo` and any files created in that volume will be Group ID 2000. +will be root(0). Any files created will also be owned by user 1000 and group 3000 when `runAsGroup` is specified. +Since `fsGroup` field is specified, all processes of the container are also part of the supplementary group ID 2000. +The owner for volume `/data/demo` and any files created in that volume will be Group ID 2000. Create the Pod: @@ -138,7 +138,7 @@ $ id uid=1000 gid=3000 groups=2000 ``` You will see that gid is 3000 which is same as `runAsGroup` field. If the `runAsGroup` was omitted the gid would -remain as 0(root) and the process will be able to interact with files that are owned by root(0) group and that have +remain as 0(root) and the process will be able to interact with files that are owned by root(0) group and that have the required group permissions for root(0) group. Exit your shell: @@ -180,9 +180,9 @@ This is an alpha feature. To use it, enable the [feature gate](/docs/reference/c {{< note >}} This field has no effect on ephemeral volume types such as -[`secret`](https://kubernetes.io/docs/concepts/storage/volumes/#secret), -[`configMap`](https://kubernetes.io/docs/concepts/storage/volumes/#configmap), -and [`emptydir`](https://kubernetes.io/docs/concepts/storage/volumes/#emptydir). +[`secret`](/docs/concepts/storage/volumes/#secret), +[`configMap`](/docs/concepts/storage/volumes/#configmap), +and [`emptydir`](/docs/concepts/storage/volumes/#emptydir). {{< /note >}} @@ -243,7 +243,7 @@ exit ## Set capabilities for a Container -With [Linux capabilities](http://man7.org/linux/man-pages/man7/capabilities.7.html), +With [Linux capabilities](https://man7.org/linux/man-pages/man7/capabilities.7.html), you can grant certain privileges to a process without granting all the privileges of the root user. To add or remove Linux capabilities for a Container, include the `capabilities` field in the `securityContext` section of the Container manifest. @@ -423,6 +423,3 @@ kubectl delete pod security-context-demo-4 * [Pod Security Policies](/docs/concepts/policy/pod-security-policy/) * [AllowPrivilegeEscalation design document](https://git.k8s.io/community/contributors/design-proposals/auth/no-new-privs.md) - - - diff --git a/content/en/docs/tasks/configure-pod-container/static-pod.md b/content/en/docs/tasks/configure-pod-container/static-pod.md index 5189fdb882..cf31d822d6 100644 --- a/content/en/docs/tasks/configure-pod-container/static-pod.md +++ b/content/en/docs/tasks/configure-pod-container/static-pod.md @@ -14,7 +14,7 @@ without the {{< glossary_tooltip text="API server" term_id="kube-apiserver" >}} observing them. Unlike Pods that are managed by the control plane (for example, a {{< glossary_tooltip text="Deployment" term_id="deployment" >}}); -instead, the kubelet watches each static Pod (and restarts it if it crashes). +instead, the kubelet watches each static Pod (and restarts it if it fails). Static Pods are always bound to one {{< glossary_tooltip term_id="kubelet" >}} on a specific node. diff --git a/content/en/docs/tasks/debug-application-cluster/audit.md b/content/en/docs/tasks/debug-application-cluster/audit.md index 600af51d00..ef97d21879 100644 --- a/content/en/docs/tasks/debug-application-cluster/audit.md +++ b/content/en/docs/tasks/debug-application-cluster/audit.md @@ -22,12 +22,10 @@ answer the following questions: - from where was it initiated? - to where was it going? - - - <!-- body --> -[Kube-apiserver][kube-apiserver] performs auditing. Each request on each stage +[Kube-apiserver](/docs/reference/command-line-tools-reference/kube-apiserver/) +performs auditing. Each request on each stage of its execution generates an event, which is then pre-processed according to a certain policy and written to a backend. The policy determines what's recorded and the backends persist the records. The current backend implementations @@ -55,7 +53,8 @@ Additionally, memory consumption depends on the audit logging configuration. Audit policy defines rules about what events should be recorded and what data they should include. The audit policy object structure is defined in the -[`audit.k8s.io` API group][auditing-api]. When an event is processed, it's +[`audit.k8s.io` API group](https://github.com/kubernetes/kubernetes/blob/{{< param "githubbranch" >}}/staging/src/k8s.io/apiserver/pkg/apis/audit/v1/types.go). +When an event is processed, it's compared against the list of rules in order. The first matching rule sets the "audit level" of the event. The known audit levels are: @@ -67,7 +66,7 @@ compared against the list of rules in order. The first matching rule sets the - `RequestResponse` - log event metadata, request and response bodies. This does not apply for non-resource requests. -You can pass a file with the policy to [kube-apiserver][kube-apiserver] +You can pass a file with the policy to `kube-apiserver` using the `--audit-policy-file` flag. If the flag is omitted, no events are logged. Note that the `rules` field __must__ be provided in the audit policy file. A policy with no (0) rules is treated as illegal. @@ -86,12 +85,14 @@ rules: - level: Metadata ``` -The audit profile used by GCE should be used as reference by admins constructing their own audit profiles. You can check the [configure-helper.sh][configure-helper] script, which generates the audit policy file. You can see most of the audit policy file by looking directly at the script. +The audit profile used by GCE should be used as reference by admins constructing their own audit profiles. You can check the +[configure-helper.sh](https://github.com/kubernetes/kubernetes/blob/{{< param "githubbranch" >}}/cluster/gce/gci/configure-helper.sh) +script, which generates the audit policy file. You can see most of the audit policy file by looking directly at the script. ## Audit backends Audit backends persist audit events to an external storage. -[Kube-apiserver][kube-apiserver] out of the box provides three backends: +`Kube-apiserver` out of the box provides three backends: - Log backend, which writes events to a disk - Webhook backend, which sends events to an external API @@ -99,7 +100,7 @@ Audit backends persist audit events to an external storage. In all cases, audit events structure is defined by the API in the `audit.k8s.io` API group. The current version of the API is -[`v1`][auditing-api]. +[`v1`](https://github.com/kubernetes/kubernetes/blob/{{< param "githubbranch" >}}/staging/src/k8s.io/apiserver/pkg/apis/audit/v1/types.go). {{< note >}} In case of patches, request body is a JSON array with patch operations, not a JSON object @@ -125,7 +126,7 @@ request to `/apis/batch/v1/namespaces/some-namespace/jobs/some-job-name`. ### Log backend Log backend writes audit events to a file in JSON format. You can configure -log audit backend using the following [kube-apiserver][kube-apiserver] flags: +log audit backend using the following `kube-apiserver` flags: - `--audit-log-path` specifies the log file path that log backend uses to write audit events. Not specifying this flag disables log backend. `-` means standard out @@ -133,14 +134,49 @@ log audit backend using the following [kube-apiserver][kube-apiserver] flags: - `--audit-log-maxbackup` defines the maximum number of audit log files to retain - `--audit-log-maxsize` defines the maximum size in megabytes of the audit log file before it gets rotated +In case kube-apiserver is configured as a Pod,remember to mount the hostPath to the location of the policy file and log file. For example, +` +--audit-policy-file=/etc/kubernetes/audit-policy.yaml +--audit-log-path=/var/log/audit.log +` +then mount the volumes: + + +``` +volumeMounts: + - mountPath: /etc/kubernetes/audit-policy.yaml + name: audit + readOnly: true + - mountPath: /var/log/audit.log + name: audit-log + readOnly: false +``` +finally the hostPath: + +``` +- name: audit + hostPath: + path: /etc/kubernetes/audit-policy.yaml + type: File + +- name: audit-log + hostPath: + path: /var/log/audit.log + type: FileOrCreate + +``` + + + ### Webhook backend Webhook backend sends audit events to a remote API, which is assumed to be the -same API as [kube-apiserver][kube-apiserver] exposes. You can configure webhook +same API as `kube-apiserver` exposes. You can configure webhook audit backend using the following kube-apiserver flags: - `--audit-webhook-config-file` specifies the path to a file with a webhook - configuration. Webhook configuration is effectively a [kubeconfig][kubeconfig]. + configuration. Webhook configuration is effectively a + [kubeconfig](/docs/tasks/access-application-cluster/configure-access-multiple-clusters). - `--audit-webhook-initial-backoff` specifies the amount of time to wait after the first failed request before retrying. Subsequent requests are retried with exponential backoff. @@ -327,23 +363,29 @@ Currently, this feature has performance implications for the apiserver in the fo ## Setup for multiple API servers -If you're extending the Kubernetes API with the [aggregation layer][kube-aggregator], you can also -set up audit logging for the aggregated apiserver. To do this, pass the configuration options in the -same format as described above to the aggregated apiserver and set up the log ingesting pipeline -to pick up audit logs. Different apiservers can have different audit configurations and different -audit policies. +If you're extending the Kubernetes API with the [aggregation +layer](/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation/), +you can also set up audit logging for the aggregated apiserver. To do this, +pass the configuration options in the same format as described above to the +aggregated apiserver and set up the log ingesting pipeline to pick up audit +logs. Different apiservers can have different audit configurations and +different audit policies. ## Log Collector Examples ### Use fluentd to collect and distribute audit events from log file -[Fluentd][fluentd] is an open source data collector for unified logging layer. +[Fluentd](http://www.fluentd.org/) is an open source data collector for unified logging layer. In this example, we will use fluentd to split audit events by different namespaces. -{{< note >}}Fluent-plugin-forest and fluent-plugin-rewrite-tag-filter are plugins for fluentd. You can get details about plugin installation from [fluentd plugin-management][fluentd_plugin_management_doc]. +{{< note >}} +The `fluent-plugin-forest` and `fluent-plugin-rewrite-tag-filter` are plugins for fluentd. +You can get details about plugin installation from +[fluentd plugin-management](https://docs.fluentd.org/v1.0/articles/plugin-management). {{< /note >}} -1. Install [fluentd][fluentd_install_doc], fluent-plugin-forest and fluent-plugin-rewrite-tag-filter in the kube-apiserver node +1. Install [`fluentd`](https://docs.fluentd.org/v1.0/articles/quickstart#step-1:-installing-fluentd), + `fluent-plugin-forest` and `fluent-plugin-rewrite-tag-filter` in the kube-apiserver node 1. Create a config file for fluentd @@ -416,11 +458,12 @@ In this example, we will use fluentd to split audit events by different namespac ### Use logstash to collect and distribute audit events from webhook backend -[Logstash][logstash] is an open source, server-side data processing tool. In this example, +[Logstash](https://www.elastic.co/products/logstash) +is an open source, server-side data processing tool. In this example, we will use logstash to collect audit events from webhook backend, and save events of different users into different files. -1. install [logstash][logstash_install_doc] +1. install [logstash](https://www.elastic.co/guide/en/logstash/current/installing-logstash.html) 1. create config file for logstash @@ -491,19 +534,6 @@ Note that in addition to file output plugin, logstash has a variety of outputs t let users route data where they want. For example, users can emit audit events to elasticsearch plugin which supports full-text search and analytics. -[kube-apiserver]: /docs/reference/command-line-tools-reference/kube-apiserver/ -[auditing-proposal]: https://github.com/kubernetes/community/blob/master/contributors/design-proposals/api-machinery/auditing.md -[auditing-api]: https://github.com/kubernetes/kubernetes/blob/{{< param "githubbranch" >}}/staging/src/k8s.io/apiserver/pkg/apis/audit/v1/types.go -[configure-helper]: https://github.com/kubernetes/kubernetes/blob/{{< param "githubbranch" >}}/cluster/gce/gci/configure-helper.sh -[kubeconfig]: /docs/tasks/access-application-cluster/configure-access-multiple-clusters/ -[fluentd]: http://www.fluentd.org/ -[fluentd_install_doc]: https://docs.fluentd.org/v1.0/articles/quickstart#step-1:-installing-fluentd -[fluentd_plugin_management_doc]: https://docs.fluentd.org/v1.0/articles/plugin-management -[logstash]: https://www.elastic.co/products/logstash -[logstash_install_doc]: https://www.elastic.co/guide/en/logstash/current/installing-logstash.html -[kube-aggregator]: /docs/concepts/api-extension/apiserver-aggregation - - ## {{% heading "whatsnext" %}} diff --git a/content/en/docs/tasks/debug-application-cluster/debug-application.md b/content/en/docs/tasks/debug-application-cluster/debug-application.md index a5c37541c3..edd23c35e7 100644 --- a/content/en/docs/tasks/debug-application-cluster/debug-application.md +++ b/content/en/docs/tasks/debug-application-cluster/debug-application.md @@ -118,7 +118,7 @@ You can view this resource with: kubectl get endpoints ${SERVICE_NAME} ``` -Make sure that the endpoints match up with the number of containers that you expect to be a member of your service. +Make sure that the endpoints match up with the number of pods that you expect to be members of your service. For example, if your Service is for an nginx container with 3 replicas, you would expect to see three different IP addresses in the Service's endpoints. diff --git a/content/en/docs/tasks/debug-application-cluster/debug-pod-replication-controller.md b/content/en/docs/tasks/debug-application-cluster/debug-pod-replication-controller.md index 9793b472e0..8fb5bffd37 100644 --- a/content/en/docs/tasks/debug-application-cluster/debug-pod-replication-controller.md +++ b/content/en/docs/tasks/debug-application-cluster/debug-pod-replication-controller.md @@ -17,7 +17,8 @@ This page shows how to debug Pods and ReplicationControllers. {{< include "task-tutorial-prereqs.md" >}} {{< version-check >}} * You should be familiar with the basics of - [Pods](/docs/concepts/workloads/pods/pod/) and [Pod Lifecycle](/docs/concepts/workloads/pods/pod-lifecycle/). + {{< glossary_tooltip text="Pods" term_id="pod" >}} and with + Pods' [lifecycles](/docs/concepts/workloads/pods/pod-lifecycle/). diff --git a/content/en/docs/tasks/debug-application-cluster/determine-reason-pod-failure.md b/content/en/docs/tasks/debug-application-cluster/determine-reason-pod-failure.md index 44dcf0e909..543573781b 100644 --- a/content/en/docs/tasks/debug-application-cluster/determine-reason-pod-failure.md +++ b/content/en/docs/tasks/debug-application-cluster/determine-reason-pod-failure.md @@ -78,7 +78,7 @@ only the termination message: ## Customizing the termination message Kubernetes retrieves termination messages from the termination message file -specified in the `terminationMessagePath` field of a Container, which as a default +specified in the `terminationMessagePath` field of a Container, which has a default value of `/dev/termination-log`. By customizing this field, you can tell Kubernetes to use a different file. Kubernetes use the contents from the specified file to populate the Container's status message on both success and failure. diff --git a/content/en/docs/tasks/debug-application-cluster/falco.md b/content/en/docs/tasks/debug-application-cluster/falco.md deleted file mode 100644 index 2b6eb9323d..0000000000 --- a/content/en/docs/tasks/debug-application-cluster/falco.md +++ /dev/null @@ -1,121 +0,0 @@ ---- -reviewers: -- soltysh -- sttts -- ericchiang -content_type: concept -title: Auditing with Falco ---- - -<!-- overview --> -### Use Falco to collect audit events - -[Falco](https://falco.org/) is an open source project for intrusion and abnormality detection for Cloud Native platforms. -This section describes how to set up Falco, how to send audit events to the Kubernetes Audit endpoint exposed by Falco, and how Falco applies a set of rules to automatically detect suspicious behavior. - - - -<!-- body --> - - -#### Install Falco - -Install Falco by using one of the following methods: - -- [Standalone Falco][falco_installation] -- [Kubernetes DaemonSet][falco_installation] -- [Falco Helm Chart][falco_helm_chart] - -Once Falco is installed make sure it is configured to expose the Audit webhook. To do so, use the following configuration: - -```yaml -webserver: - enabled: true - listen_port: 8765 - k8s_audit_endpoint: /k8s_audit - ssl_enabled: false - ssl_certificate: /etc/falco/falco.pem -``` - -This configuration is typically found in the `/etc/falco/falco.yaml` file. If Falco is installed as a Kubernetes DaemonSet, edit the `falco-config` ConfigMap and add this configuration. - -#### Configure Kubernetes Audit - -1. Create a [kubeconfig file](/docs/concepts/configuration/organize-cluster-access-kubeconfig/) for the [kube-apiserver][kube-apiserver] webhook audit backend. - - cat <<EOF > /etc/kubernetes/audit-webhook-kubeconfig - apiVersion: v1 - kind: Config - clusters: - - cluster: - server: http://<ip_of_falco>:8765/k8s_audit - name: falco - contexts: - - context: - cluster: falco - user: "" - name: default-context - current-context: default-context - preferences: {} - users: [] - EOF - -1. Start [kube-apiserver][kube-apiserver] with the following options: - - ```shell - --audit-policy-file=/etc/kubernetes/audit-policy.yaml --audit-webhook-config-file=/etc/kubernetes/audit-webhook-kubeconfig - ``` - -#### Audit Rules - -Rules devoted to Kubernetes Audit Events can be found in [k8s_audit_rules.yaml][falco_k8s_audit_rules]. If Audit Rules is installed as a native package or using the official Docker images, Falco copies the rules file to `/etc/falco/`, so they are available for use. - -There are three classes of rules. - -The first class of rules looks for suspicious or exceptional activities, such as: - -- Any activity by an unauthorized or anonymous user. -- Creating a pod with an unknown or disallowed image. -- Creating a privileged pod, a pod mounting a sensitive filesystem from the host, or a pod using host networking. -- Creating a NodePort service. -- Creating a ConfigMap containing private credentials, such as passwords and cloud provider secrets. -- Attaching to or executing a command on a running pod. -- Creating a namespace external to a set of allowed namespaces. -- Creating a pod or service account in the kube-system or kube-public namespaces. -- Trying to modify or delete a system ClusterRole. -- Creating a ClusterRoleBinding to the cluster-admin role. -- Creating a ClusterRole with wildcarded verbs or resources. For example, overly permissive. -- Creating a ClusterRole with write permissions or a ClusterRole that can execute commands on pods. - -A second class of rules tracks resources being created or destroyed, including: - -- Deployments -- Services -- ConfigMaps -- Namespaces -- Service accounts -- Role/ClusterRoles -- Role/ClusterRoleBindings - -The final class of rules simply displays any Audit Event received by Falco. This rule is disabled by default, as it can be quite noisy. - -For further details, see [Kubernetes Audit Events][falco_ka_docs] in the Falco documentation. - -[kube-apiserver]: /docs/admin/kube-apiserver -[auditing-proposal]: https://github.com/kubernetes/community/blob/master/contributors/design-proposals/api-machinery/auditing.md -[auditing-api]: https://github.com/kubernetes/kubernetes/blob/{{< param "githubbranch" >}}/staging/src/k8s.io/apiserver/pkg/apis/audit/v1/types.go -[gce-audit-profile]: https://github.com/kubernetes/kubernetes/blob/{{< param "githubbranch" >}}/cluster/gce/gci/configure-helper.sh#L735 -[kubeconfig]: /docs/tasks/access-application-cluster/configure-access-multiple-clusters/ -[fluentd]: http://www.fluentd.org/ -[fluentd_install_doc]: https://docs.fluentd.org/v1.0/articles/quickstart#step-1:-installing-fluentd -[fluentd_plugin_management_doc]: https://docs.fluentd.org/v1.0/articles/plugin-management -[logstash]: https://www.elastic.co/products/logstash -[logstash_install_doc]: https://www.elastic.co/guide/en/logstash/current/installing-logstash.html -[kube-aggregator]: /docs/concepts/api-extension/apiserver-aggregation -[falco_website]: https://www.falco.org -[falco_k8s_audit_rules]: https://github.com/falcosecurity/falco/blob/master/rules/k8s_audit_rules.yaml -[falco_ka_docs]: https://falco.org/docs/event-sources/kubernetes-audit -[falco_installation]: https://falco.org/docs/installation -[falco_helm_chart]: https://github.com/falcosecurity/charts/tree/master/falco - - diff --git a/content/en/docs/tasks/debug-application-cluster/resource-metrics-pipeline.md b/content/en/docs/tasks/debug-application-cluster/resource-metrics-pipeline.md index dbd4aa6cf4..098776cb7b 100644 --- a/content/en/docs/tasks/debug-application-cluster/resource-metrics-pipeline.md +++ b/content/en/docs/tasks/debug-application-cluster/resource-metrics-pipeline.md @@ -41,7 +41,7 @@ The API requires metrics server to be deployed in the cluster. Otherwise it will ### CPU -CPU is reported as the average usage, in [CPU cores](https://kubernetes.io/docs/concepts/configuration/manage-compute-resources-container/#meaning-of-cpu), over a period of time. This value is derived by taking a rate over a cumulative CPU counter provided by the kernel (in both Linux and Windows kernels). The kubelet chooses the window for the rate calculation. +CPU is reported as the average usage, in [CPU cores](/docs/concepts/configuration/manage-compute-resources-container/#meaning-of-cpu), over a period of time. This value is derived by taking a rate over a cumulative CPU counter provided by the kernel (in both Linux and Windows kernels). The kubelet chooses the window for the rate calculation. ### Memory @@ -60,5 +60,3 @@ Metrics Server is registered with the main API server through [Kubernetes aggregator](/docs/concepts/api-extension/apiserver-aggregation/). Learn more about the metrics server in [the design doc](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/instrumentation/metrics-server.md). - - diff --git a/content/en/docs/tasks/example-task-template.md b/content/en/docs/tasks/example-task-template.md deleted file mode 100644 index 90d14e98da..0000000000 --- a/content/en/docs/tasks/example-task-template.md +++ /dev/null @@ -1,52 +0,0 @@ ---- -title: Example Task Template -reviewers: -- chenopis -content_type: task -toc_hide: true ---- - -<!-- overview --> - -{{< note >}} -Be sure to also [create an entry in the table of contents](/docs/contribute/style/write-new-topic/#placing-your-topic-in-the-table-of-contents) for your new document. -{{< /note >}} - -This page shows how to ... - - - -## {{% heading "prerequisites" %}} - - -* {{< include "task-tutorial-prereqs.md" >}} {{< version-check >}} -* Do this. -* Do this too. - - - -<!-- steps --> - -## Doing ... - -1. Do this. -1. Do this next. Possibly read this [related explanation](#). - - - -<!-- discussion --> - -## Understanding ... -**[Optional Section]** - -Here's an interesting thing to know about the steps you just did. - - - -## {{% heading "whatsnext" %}} - - -**[Optional Section]** - -* Learn more about [Writing a New Topic](/docs/home/contribute/write-new-topic/). -* Learn about [Page Content Types - Task](/docs/home/contribute/style/page-content-types/#task). diff --git a/content/en/docs/tasks/administer-cluster/configure-multiple-schedulers.md b/content/en/docs/tasks/extend-kubernetes/configure-multiple-schedulers.md similarity index 83% rename from content/en/docs/tasks/administer-cluster/configure-multiple-schedulers.md rename to content/en/docs/tasks/extend-kubernetes/configure-multiple-schedulers.md index e4b58b70e3..b0e272afa0 100644 --- a/content/en/docs/tasks/administer-cluster/configure-multiple-schedulers.md +++ b/content/en/docs/tasks/extend-kubernetes/configure-multiple-schedulers.md @@ -4,11 +4,13 @@ reviewers: - madhusudancs title: Configure Multiple Schedulers content_type: task +weight: 20 --- <!-- overview --> -Kubernetes ships with a default scheduler that is described [here](/docs/admin/kube-scheduler/). +Kubernetes ships with a default scheduler that is described +[here](/docs/reference/command-line-tools-reference/kube-scheduler/). If the default scheduler does not suit your needs you can implement your own scheduler. Not just that, you can even run multiple schedulers simultaneously alongside the default scheduler and instruct Kubernetes what scheduler to use for each of your pods. Let's @@ -19,16 +21,10 @@ document. Please refer to the kube-scheduler implementation in [pkg/scheduler](https://github.com/kubernetes/kubernetes/tree/{{< param "githubbranch" >}}/pkg/scheduler) in the Kubernetes source directory for a canonical example. - - - ## {{% heading "prerequisites" %}} - {{< include "task-tutorial-prereqs.md" >}} {{< version-check >}} - - <!-- steps --> ## Package the scheduler @@ -82,7 +78,7 @@ Note also that we created a dedicated service account `my-scheduler` and bind th `system:kube-scheduler` to it so that it can acquire the same privileges as `kube-scheduler`. Please see the -[kube-scheduler documentation](/docs/admin/kube-scheduler/) for +[kube-scheduler documentation](/docs/reference/command-line-tools-reference/kube-scheduler/) for detailed description of other command line arguments. ## Run the second scheduler in the cluster @@ -99,6 +95,7 @@ Verify that the scheduler pod is running: ```shell kubectl get pods --namespace=kube-system ``` + ``` NAME READY STATUS RESTARTS AGE .... @@ -124,56 +121,22 @@ The control plane creates the lock objects for you, but the namespace must alrea You can use the `kube-system` namespace. {{< /note >}} -If RBAC is enabled on your cluster, you must update the `system:kube-scheduler` cluster role. Add your scheduler name to the resourceNames of the rule applied for `endpoints` and `leases` resources, as in the following example: -``` +If RBAC is enabled on your cluster, you must update the `system:kube-scheduler` cluster role. +Add your scheduler name to the resourceNames of the rule applied for `endpoints` and `leases` resources, as in the following example: + +```shell kubectl edit clusterrole system:kube-scheduler ``` -```yaml -apiVersion: rbac.authorization.k8s.io/v1 -kind: ClusterRole -metadata: - annotations: - rbac.authorization.kubernetes.io/autoupdate: "true" - labels: - kubernetes.io/bootstrapping: rbac-defaults - name: system:kube-scheduler -rules: -- apiGroups: - - coordination.k8s.io - resources: - - leases - verbs: - - create -- apiGroups: - - coordination.k8s.io - resourceNames: - - kube-scheduler - - my-scheduler - resources: - - leases - verbs: - - get - - update -- apiGroups: - - "" - resourceNames: - - kube-scheduler - - my-scheduler - resources: - - endpoints - verbs: - - delete - - get - - patch - - update -``` + +{{< codenew file="admin/sched/clusterrole.yaml" >}} ## Specify schedulers for pods -Now that our second scheduler is running, let's create some pods, and direct them to be scheduled by either the default scheduler or the one we just deployed. In order to schedule a given pod using a specific scheduler, we specify the name of the +Now that our second scheduler is running, let's create some pods, and direct them +to be scheduled by either the default scheduler or the one we just deployed. +In order to schedule a given pod using a specific scheduler, we specify the name of the scheduler in that pod spec. Let's look at three examples. - - Pod spec without any scheduler name {{< codenew file="admin/sched/pod1.yaml" >}} @@ -183,9 +146,9 @@ scheduler in that pod spec. Let's look at three examples. Save this file as `pod1.yaml` and submit it to the Kubernetes cluster. -```shell -kubectl create -f pod1.yaml -``` + ```shell + kubectl create -f pod1.yaml + ``` - Pod spec with `default-scheduler` @@ -196,9 +159,9 @@ kubectl create -f pod1.yaml Save this file as `pod2.yaml` and submit it to the Kubernetes cluster. -```shell -kubectl create -f pod2.yaml -``` + ```shell + kubectl create -f pod2.yaml + ``` - Pod spec with `my-scheduler` @@ -210,17 +173,15 @@ kubectl create -f pod2.yaml Save this file as `pod3.yaml` and submit it to the Kubernetes cluster. -```shell -kubectl create -f pod3.yaml -``` + ```shell + kubectl create -f pod3.yaml + ``` Verify that all three pods are running. -```shell -kubectl get pods -``` - - + ```shell + kubectl get pods + ``` <!-- discussion --> @@ -242,4 +203,3 @@ verify that the pods were scheduled by the desired schedulers. kubectl get events ``` - diff --git a/content/en/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definition-versioning.md b/content/en/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definition-versioning.md index 6eaf0cdd3a..09ab41ea4c 100644 --- a/content/en/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definition-versioning.md +++ b/content/en/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definition-versioning.md @@ -13,19 +13,15 @@ This page explains how to add versioning information to [CustomResourceDefinitions](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#customresourcedefinition-v1beta1-apiextensions), to indicate the stability level of your CustomResourceDefinitions or advance your API to a new version with conversion between API representations. It also describes how to upgrade an object from one version to another. - - ## {{% heading "prerequisites" %}} {{< include "task-tutorial-prereqs.md" >}} -You should have a initial understanding of [custom resources](/docs/concepts/api-extension/custom-resources/). +You should have a initial understanding of [custom resources](/docs/concepts/extend-kubernetes/api-extension/custom-resources/). {{< version-check >}} - - <!-- steps --> ## Overview @@ -291,7 +287,9 @@ conversions that call an external service in case a conversion is required. For * Watch is created in one version but the changed object is stored in another version. * custom resource PUT request is in a different version than storage version. -To cover all of these cases and to optimize conversion by the API server, the conversion requests may contain multiple objects in order to minimize the external calls. The webhook should perform these conversions independently. +To cover all of these cases and to optimize conversion by the API server, +the conversion requests may contain multiple objects in order to minimize the external calls. +The webhook should perform these conversions independently. ### Write a conversion webhook server @@ -302,7 +300,12 @@ that is validated in a Kubernetes e2e test. The webhook handles the results wrapped in `ConversionResponse`. Note that the request contains a list of custom resources that need to be converted independently without changing the order of objects. -The example server is organized in a way to be reused for other conversions. Most of the common code are located in the [framework file](https://github.com/kubernetes/kubernetes/tree/v1.15.0/test/images/crd-conversion-webhook/converter/framework.go) that leaves only [one function](https://github.com/kubernetes/kubernetes/blob/v1.15.0/test/images/crd-conversion-webhook/converter/example_converter.go#L29-L80) to be implemented for different conversions. +The example server is organized in a way to be reused for other conversions. +Most of the common code are located in the +[framework file](https://github.com/kubernetes/kubernetes/tree/v1.15.0/test/images/crd-conversion-webhook/converter/framework.go) +that leaves only +[one function](https://github.com/kubernetes/kubernetes/blob/v1.15.0/test/images/crd-conversion-webhook/converter/example_converter.go#L29-L80) +to be implemented for different conversions. {{< note >}} The example conversion webhook server leaves the `ClientAuth` field @@ -315,12 +318,17 @@ how to [authenticate API servers](/docs/reference/access-authn-authz/extensible- #### Permissible mutations -A conversion webhook must not mutate anything inside of `metadata` of the converted object other than `labels` and `annotations`. Attempted changes to `name`, `UID` and `namespace` are rejected and fail the request which caused the conversion. All other changes are just ignored. +A conversion webhook must not mutate anything inside of `metadata` of the converted object +other than `labels` and `annotations`. +Attempted changes to `name`, `UID` and `namespace` are rejected and fail the request +which caused the conversion. All other changes are just ignored. ### Deploy the conversion webhook service -Documentation for deploying the conversion webhook is the same as for the [admission webhook example service](/docs/reference/access-authn-authz/extensible-admission-controllers/#deploy_the_admission_webhook_service). -The assumption for next sections is that the conversion webhook server is deployed to a service named `example-conversion-webhook-server` in `default` namespace and serving traffic on path `/crdconvert`. +Documentation for deploying the conversion webhook is the same as for the +[admission webhook example service](/docs/reference/access-authn-authz/extensible-admission-controllers/#deploy_the_admission_webhook_service). +The assumption for next sections is that the conversion webhook server is deployed to a service +named `example-conversion-webhook-server` in `default` namespace and serving traffic on path `/crdconvert`. {{< note >}} When the webhook server is deployed into the Kubernetes cluster as a @@ -556,7 +564,7 @@ at the subpath "/my-path", and to verify the TLS connection against the ServerNa {{< tabs name="CustomResourceDefinition_versioning_example_4" >}} {{% tab name="apiextensions.k8s.io/v1" %}} ```yaml -apiVersion: apiextensions.k8s.io/v1b +apiVersion: apiextensions.k8s.io/v1 kind: CustomResourceDefinition ... spec: 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 78b55b58dc..834c6983f7 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 @@ -16,7 +16,6 @@ This page shows how to install a into the Kubernetes API by creating a [CustomResourceDefinition](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#customresourcedefinition-v1beta1-apiextensions). - ## {{% heading "prerequisites" %}} @@ -24,9 +23,7 @@ into the Kubernetes API by creating a * Make sure your Kubernetes cluster has a master version of 1.16.0 or higher to use `apiextensions.k8s.io/v1`, or 1.7.0 or higher for `apiextensions.k8s.io/v1beta1`. -* Read about [custom resources](/docs/concepts/api-extension/custom-resources/). - - +* Read about [custom resources](/docs/concepts/extend-kubernetes/api-extension/custom-resources/). <!-- steps --> @@ -427,7 +424,9 @@ spec: The field `someRandomField` has been pruned. -Note that the `kubectl create` call uses `--validate=false` to skip client-side validation. Because the [OpenAPI validation schemas are also published](/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/#publish-validation-schema-in-openapi-v2) to kubectl, it will also check for unknown fields and reject those objects long before they are sent to the API server. +Note that the `kubectl create` call uses `--validate=false` to skip client-side validation. +Because the [OpenAPI validation schemas are also published](/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/#publish-validation-schema-in-openapi-v2) +to kubectl, it will also check for unknown fields and reject those objects long before they are sent to the API server. ### Controlling pruning @@ -533,11 +532,14 @@ allOf: With one of those specification, both an integer and a string validate. -In [Validation Schema Publishing](/docs/tasks/extend-kubernetes/custom-resources/extend-api-custom-resource-definitions/#publish-validation-schema-in-openapi-v2), `x-kubernetes-int-or-string: true` is unfolded to one of the two patterns shown above. +In [Validation Schema Publishing](/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/#publish-validation-schema-in-openapi-v2), +`x-kubernetes-int-or-string: true` is unfolded to one of the two patterns shown above. ### RawExtension -RawExtensions (as in `runtime.RawExtension` defined in [k8s.io/apimachinery](https://github.com/kubernetes/apimachinery/blob/03ac7a9ade429d715a1a46ceaa3724c18ebae54f/pkg/runtime/types.go#L94)) holds complete Kubernetes objects, i.e. with `apiVersion` and `kind` fields. +RawExtensions (as in `runtime.RawExtension` defined in +[k8s.io/apimachinery](https://github.com/kubernetes/apimachinery/blob/03ac7a9ade429d715a1a46ceaa3724c18ebae54f/pkg/runtime/types.go#L94)) +holds complete Kubernetes objects, i.e. with `apiVersion` and `kind` fields. It is possible to specify those embedded objects (both completely without constraints or partially specified) by setting `x-kubernetes-embedded-resource: true`. For example: @@ -569,8 +571,6 @@ See [Custom resource definition versioning](/docs/tasks/extend-kubernetes/custom for more information about serving multiple versions of your CustomResourceDefinition and migrating your objects from one version to another. - - <!-- discussion --> ## Advanced topics diff --git a/content/en/docs/tasks/extend-kubernetes/http-proxy-access-api.md b/content/en/docs/tasks/extend-kubernetes/http-proxy-access-api.md index dd80c8c349..b3aae7fc3e 100644 --- a/content/en/docs/tasks/extend-kubernetes/http-proxy-access-api.md +++ b/content/en/docs/tasks/extend-kubernetes/http-proxy-access-api.md @@ -17,7 +17,7 @@ If you do not already have an application running in your cluster, start a Hello world application by entering this command: ```shell -kubectl run node-hello --image=gcr.io/google-samples/node-hello:1.0 --port=8080 +kubectl create deployment node-hello --image=gcr.io/google-samples/node-hello:1.0 --port=8080 ``` <!-- steps --> diff --git a/content/en/docs/tasks/inject-data-application/define-environment-variable-container.md b/content/en/docs/tasks/inject-data-application/define-environment-variable-container.md index d75d930c56..cbc3c45260 100644 --- a/content/en/docs/tasks/inject-data-application/define-environment-variable-container.md +++ b/content/en/docs/tasks/inject-data-application/define-environment-variable-container.md @@ -9,17 +9,10 @@ weight: 20 This page shows how to define environment variables for a container in a Kubernetes Pod. - - - ## {{% heading "prerequisites" %}} - {{< include "task-tutorial-prereqs.md" >}} - - - <!-- steps --> ## Define an environment variable for a container @@ -123,13 +116,10 @@ spec: Upon creation, the command `echo Warm greetings to The Most Honorable Kubernetes` is run on the container. - - ## {{% heading "whatsnext" %}} - * Learn more about [environment variables](/docs/tasks/inject-data-application/environment-variable-expose-pod-information/). -* Learn about [using secrets as environment variables](/docs/user-guide/secrets/#using-secrets-as-environment-variables). +* Learn about [using secrets as environment variables](/docs/concepts/configuration/secret/#using-secrets-as-environment-variables). * See [EnvVarSource](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#envvarsource-v1-core). diff --git a/content/en/docs/tasks/inject-data-application/define-interdependent-environment-variables.md b/content/en/docs/tasks/inject-data-application/define-interdependent-environment-variables.md new file mode 100644 index 0000000000..74c5c245db --- /dev/null +++ b/content/en/docs/tasks/inject-data-application/define-interdependent-environment-variables.md @@ -0,0 +1,78 @@ +--- +title: Define Dependent Environment Variables +content_type: task +weight: 20 +--- + +<!-- overview --> + +This page shows how to define dependent environment variables for a container +in a Kubernetes Pod. + + +## {{% heading "prerequisites" %}} + + +{{< include "task-tutorial-prereqs.md" >}} + + +<!-- steps --> + +## Define an environment dependent variable for a container + +When you create a Pod, you can set dependent environment variables for the containers that run in the Pod. To set dependent environment variables, you can use $(VAR_NAME) in the `value` of `env` in the configuration file. + +In this exercise, you create a Pod that runs one container. The configuration +file for the Pod defines an dependent environment variable with common usage defined. Here is the configuration manifest for the +Pod: + +{{< codenew file="pods/inject/dependent-envars.yaml" >}} + +1. Create a Pod based on that manifest: + + ```shell + kubectl apply -f https://k8s.io/examples/pods/inject/dependent-envars.yaml + ``` + ``` + pod/dependent-envars-demo created + ``` + +2. List the running Pods: + + ```shell + kubectl get pods dependent-envars-demo + ``` + ``` + NAME READY STATUS RESTARTS AGE + dependent-envars-demo 1/1 Running 0 9s + ``` + +3. Check the logs for the container running in your Pod: + + ```shell + kubectl logs pod/dependent-envars-demo + ``` + ``` + + UNCHANGED_REFERENCE=$(PROTOCOL)://172.17.0.1:80 + SERVICE_ADDRESS=https://172.17.0.1:80 + ESCAPED_REFERENCE=$(PROTOCOL)://172.17.0.1:80 + ``` + +As shown above, you have defined the correct dependency reference of `SERVICE_ADDRESS`, bad dependency reference of `UNCHANGED_REFERENCE` and skip dependent references of `ESCAPED_REFERENCE`. + +When an environment variable is already defined when being referenced, +the reference can be correctly resolved, such as in the `SERVICE_ADDRESS` case. + +When the environment variable is undefined or only includes some variables, the undefined environment variable is treated as a normal string, such as `UNCHANGED_REFERENCE`. Note that incorrectly parsed environment variables, in general, will not block the container from starting. + +The `$(VAR_NAME)` syntax can be escaped with a double `$`, ie: `$$(VAR_NAME)`. +Escaped references are never expanded, regardless of whether the referenced variable +is defined or not. This can be seen from the `ESCAPED_REFERENCE` case above. + +## {{% heading "whatsnext" %}} + + +* Learn more about [environment variables](/docs/tasks/inject-data-application/environment-variable-expose-pod-information/). +* See [EnvVarSource](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#envvarsource-v1-core). + diff --git a/content/en/docs/tasks/inject-data-application/podpreset.md b/content/en/docs/tasks/inject-data-application/podpreset.md index 6533629ce4..9eea082321 100644 --- a/content/en/docs/tasks/inject-data-application/podpreset.md +++ b/content/en/docs/tasks/inject-data-application/podpreset.md @@ -140,7 +140,7 @@ 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 +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: @@ -290,7 +290,7 @@ kubectl get pod website -o 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](https://kubernetes.io/docs/reference/access-authn-authz/admission-controllers/#podpreset) +[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`: @@ -301,7 +301,7 @@ 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: +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:""} @@ -321,5 +321,3 @@ The output shows that the PodPreset was deleted: ``` podpreset "allow-database" deleted ``` - - diff --git a/content/en/docs/tasks/job/automated-tasks-with-cron-jobs.md b/content/en/docs/tasks/job/automated-tasks-with-cron-jobs.md index e5f0d3a6b7..693e730a09 100644 --- a/content/en/docs/tasks/job/automated-tasks-with-cron-jobs.md +++ b/content/en/docs/tasks/job/automated-tasks-with-cron-jobs.md @@ -128,8 +128,8 @@ You can read more about removing jobs in [garbage collection](/docs/concepts/wor ## Writing a Cron Job Spec As with all other Kubernetes configs, a cron job needs `apiVersion`, `kind`, and `metadata` fields. For general -information about working with config files, see [deploying applications](/docs/user-guide/deploying-applications), -and [using kubectl to manage resources](/docs/user-guide/working-with-resources) documents. +information about working with config files, see [deploying applications](/docs/tasks/run-application/run-stateless-application-deployment/), +and [using kubectl to manage resources](/docs/concepts/overview/working-with-objects/object-management/) documents. A cron job config also needs a [`.spec` section](https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status). @@ -142,7 +142,8 @@ All modifications to a cron job, especially its `.spec`, are applied only to the The `.spec.schedule` is a required field of the `.spec`. It takes a [Cron](https://en.wikipedia.org/wiki/Cron) format string, such as `0 * * * *` or `@hourly`, as schedule time of its jobs to be created and executed. -The format also includes extended `vixie cron` step values. As explained in the [FreeBSD manual](https://www.freebsd.org/cgi/man.cgi?crontab%285%29): +The format also includes extended `vixie cron` step values. As explained in the +[FreeBSD manual](https://www.freebsd.org/cgi/man.cgi?crontab%285%29): > Step values can be used in conjunction with ranges. Following a range > with `/<number>` specifies skips of the number's value through the diff --git a/content/en/docs/tasks/job/coarse-parallel-processing-work-queue.md b/content/en/docs/tasks/job/coarse-parallel-processing-work-queue.md index 346fbdda8d..1bbb49a256 100644 --- a/content/en/docs/tasks/job/coarse-parallel-processing-work-queue.md +++ b/content/en/docs/tasks/job/coarse-parallel-processing-work-queue.md @@ -17,25 +17,20 @@ from a task queue, completes it, deletes it from the queue, and exits. Here is an overview of the steps in this example: 1. **Start a message queue service.** In this example, we use RabbitMQ, but you could use another - one. In practice you would set up a message queue service once and reuse it for many jobs. + one. In practice you would set up a message queue service once and reuse it for many jobs. 1. **Create a queue, and fill it with messages.** Each message represents one task to be done. In - this example, a message is just an integer that we will do a lengthy computation on. + this example, a message is just an integer that we will do a lengthy computation on. 1. **Start a Job that works on tasks from the queue**. The Job starts several pods. Each pod takes - one task from the message queue, processes it, and repeats until the end of the queue is reached. - - - + one task from the message queue, processes it, and repeats until the end of the queue is reached. ## {{% heading "prerequisites" %}} Be familiar with the basic, -non-parallel, use of [Job](/docs/concepts/jobs/run-to-completion-finite-workloads/). +non-parallel, use of [Job](/docs/concepts/workloads/controllers/job/). {{< include "task-tutorial-prereqs.md" >}} - - <!-- steps --> ## Starting a message queue service @@ -304,7 +299,7 @@ do not need to modify your "worker" program to be aware that there is a work que It does require that you run a message queue service. If running a queue service is inconvenient, you may -want to consider one of the other [job patterns](/docs/concepts/jobs/run-to-completion-finite-workloads/#job-patterns). +want to consider one of the other [job patterns](/docs/concepts/workloads/controllers/job/#job-patterns). This approach creates a pod for every work item. If your work items only take a few seconds, though, creating a Pod for every work item may add a lot of overhead. Consider another diff --git a/content/en/docs/tasks/job/fine-parallel-processing-work-queue.md b/content/en/docs/tasks/job/fine-parallel-processing-work-queue.md index f502113c8f..7f3c30121e 100644 --- a/content/en/docs/tasks/job/fine-parallel-processing-work-queue.md +++ b/content/en/docs/tasks/job/fine-parallel-processing-work-queue.md @@ -16,31 +16,24 @@ from a task queue, processes it, and repeats until the end of the queue is reach Here is an overview of the steps in this example: 1. **Start a storage service to hold the work queue.** In this example, we use Redis to store - our work items. In the previous example, we used RabbitMQ. In this example, we use Redis and - a custom work-queue client library because AMQP does not provide a good way for clients to - detect when a finite-length work queue is empty. In practice you would set up a store such - as Redis once and reuse it for the work queues of many jobs, and other things. + our work items. In the previous example, we used RabbitMQ. In this example, we use Redis and + a custom work-queue client library because AMQP does not provide a good way for clients to + detect when a finite-length work queue is empty. In practice you would set up a store such + as Redis once and reuse it for the work queues of many jobs, and other things. 1. **Create a queue, and fill it with messages.** Each message represents one task to be done. In - this example, a message is just an integer that we will do a lengthy computation on. + this example, a message is just an integer that we will do a lengthy computation on. 1. **Start a Job that works on tasks from the queue**. The Job starts several pods. Each pod takes - one task from the message queue, processes it, and repeats until the end of the queue is reached. - - - + one task from the message queue, processes it, and repeats until the end of the queue is reached. ## {{% heading "prerequisites" %}} {{< include "task-tutorial-prereqs.md" >}} - - <!-- steps --> Be familiar with the basic, -non-parallel, use of [Job](/docs/concepts/jobs/run-to-completion-finite-workloads/). - - +non-parallel, use of [Job](/docs/concepts/workloads/controllers/job/). <!-- steps --> @@ -227,14 +220,13 @@ Working on lemon As you can see, one of our pods worked on several work units. - - <!-- discussion --> ## Alternatives If running a queue service or modifying your containers to use a work queue is inconvenient, you may -want to consider one of the other [job patterns](/docs/concepts/jobs/run-to-completion-finite-workloads/#job-patterns). +want to consider one of the other +[job patterns](/docs/concepts/workloads/controllers/job/#job-patterns). If you have a continuous stream of background processing work to run, then consider running your background workers with a `ReplicaSet` instead, diff --git a/content/en/docs/tasks/job/parallel-processing-expansion.md b/content/en/docs/tasks/job/parallel-processing-expansion.md index 3477be2650..e92fa9f5bb 100644 --- a/content/en/docs/tasks/job/parallel-processing-expansion.md +++ b/content/en/docs/tasks/job/parallel-processing-expansion.md @@ -17,12 +17,10 @@ The sample Jobs process each item simply by printing a string then pausing. See [using Jobs in real workloads](#using-jobs-in-real-workloads) to learn about how this pattern fits more realistic use cases. - ## {{% heading "prerequisites" %}} - You should be familiar with the basic, -non-parallel, use of [Job](/docs/concepts/jobs/run-to-completion-finite-workloads/). +non-parallel, use of [Job](/docs/concepts/workloads/controllers/job/). {{< include "task-tutorial-prereqs.md" >}} @@ -33,12 +31,11 @@ To follow the advanced templating example, you need a working installation of library for Python. Once you have Python set up, you can install Jinja2 by running: + ```shell pip install --user jinja2 ``` - - <!-- steps --> ## Create Jobs based on a template @@ -305,7 +302,7 @@ If you plan to create a large number of Job objects, you may find that: on Jobs: the API server permanently rejects some of your requests when you create a great deal of work in one batch. -There are other [job patterns](/docs/concepts/jobs/run-to-completion-finite-workloads/#job-patterns) +There are other [job patterns](/docs/concepts/workloads/controllers/job/#job-patterns) that you can use to process large amounts of work without creating very many Job objects. diff --git a/content/en/docs/tasks/manage-daemon/update-daemon-set.md b/content/en/docs/tasks/manage-daemon/update-daemon-set.md index b9168ed098..f9e35cb0f5 100644 --- a/content/en/docs/tasks/manage-daemon/update-daemon-set.md +++ b/content/en/docs/tasks/manage-daemon/update-daemon-set.md @@ -10,17 +10,10 @@ weight: 10 This page shows how to perform a rolling update on a DaemonSet. - - - ## {{% heading "prerequisites" %}} - * The DaemonSet rolling update feature is only supported in Kubernetes version 1.6 or later. - - - <!-- steps --> ## DaemonSet Update Strategy @@ -164,7 +157,7 @@ make room for new DaemonSet pods. {{< note >}} This will cause service disruption when deleted pods are not controlled by any controllers or pods are not -replicated. This does not respect [PodDisruptionBudget](/docs/tasks/configure-pod-container/configure-pod-disruption-budget/) +replicated. This does not respect [PodDisruptionBudget](/docs/tasks/run-application/configure-pdb/) either. {{< /note >}} diff --git a/content/en/docs/tasks/run-application/delete-stateful-set.md b/content/en/docs/tasks/run-application/delete-stateful-set.md index 7a4a94fab4..57e54e6797 100644 --- a/content/en/docs/tasks/run-application/delete-stateful-set.md +++ b/content/en/docs/tasks/run-application/delete-stateful-set.md @@ -58,7 +58,7 @@ kubectl delete pods -l app=myapp ### Persistent Volumes -Deleting the Pods in a StatefulSet will not delete the associated volumes. This is to ensure that you have the chance to copy data off the volume before deleting it. Deleting the PVC after the pods have left the [terminating state](/docs/concepts/workloads/pods/pod/#termination-of-pods) might trigger deletion of the backing Persistent Volumes depending on the storage class and reclaim policy. You should never assume ability to access a volume after claim deletion. +Deleting the Pods in a StatefulSet will not delete the associated volumes. This is to ensure that you have the chance to copy data off the volume before deleting it. Deleting the PVC after the pods have terminated might trigger deletion of the backing Persistent Volumes depending on the storage class and reclaim policy. You should never assume ability to access a volume after claim deletion. {{< note >}} Use caution when deleting a PVC, as it may lead to data loss. diff --git a/content/en/docs/tasks/run-application/force-delete-stateful-set-pod.md b/content/en/docs/tasks/run-application/force-delete-stateful-set-pod.md index 48a61a260d..e706c6179a 100644 --- a/content/en/docs/tasks/run-application/force-delete-stateful-set-pod.md +++ b/content/en/docs/tasks/run-application/force-delete-stateful-set-pod.md @@ -37,7 +37,7 @@ You can perform a graceful pod deletion with the following command: kubectl delete pods <pod> ``` -For the above to lead to graceful termination, the Pod **must not** specify a `pod.Spec.TerminationGracePeriodSeconds` of 0. The practice of setting a `pod.Spec.TerminationGracePeriodSeconds` of 0 seconds is unsafe and strongly discouraged for StatefulSet Pods. Graceful deletion is safe and will ensure that the [Pod shuts down gracefully](/docs/concepts/workloads/pods/pod/#termination-of-pods) before the kubelet deletes the name from the apiserver. +For the above to lead to graceful termination, the Pod **must not** specify a `pod.Spec.TerminationGracePeriodSeconds` of 0. The practice of setting a `pod.Spec.TerminationGracePeriodSeconds` of 0 seconds is unsafe and strongly discouraged for StatefulSet Pods. Graceful deletion is safe and will ensure that the Pod [shuts down gracefully](/docs/concepts/workloads/pods/pod-lifecycle/#pod-termination) before the kubelet deletes the name from the apiserver. Kubernetes (versions 1.5 or newer) will not delete Pods just because a Node is unreachable. The Pods running on an unreachable Node enter the 'Terminating' or 'Unknown' state after a [timeout](/docs/admin/node/#node-condition). Pods may also enter these states when the user attempts graceful deletion of a Pod on an unreachable Node. The only ways in which a Pod in such a state can be removed from the apiserver are as follows: diff --git a/content/en/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough.md b/content/en/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough.md index 7f3b046b68..6806ba0dc0 100644 --- a/content/en/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough.md +++ b/content/en/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough.md @@ -47,7 +47,7 @@ The Dockerfile has the following content: ``` FROM php:5-apache -ADD index.php /var/www/html/index.php +COPY index.php /var/www/html/index.php RUN chmod a+rx index.php ``` diff --git a/content/en/docs/tasks/tls/manual-rotation-of-ca-certificates.md b/content/en/docs/tasks/tls/manual-rotation-of-ca-certificates.md index 4146608760..9d7516aeef 100644 --- a/content/en/docs/tasks/tls/manual-rotation-of-ca-certificates.md +++ b/content/en/docs/tasks/tls/manual-rotation-of-ca-certificates.md @@ -1,7 +1,7 @@ --- title: Manual Rotation of CA Certificates min-kubernetes-server-version: v1.13 -content_template: templates/task +content_type: task --- <!-- overview --> @@ -14,53 +14,54 @@ This page shows how to manually rotate the certificate authority (CA) certificat - For more information about authentication in Kubernetes, see [Authenticating](/docs/reference/access-authn-authz/authentication). -- For more information about best practices for CA certificates, see [Single root CA](docs/setup/best-practices/certificates/#single-root-ca). +- For more information about best practices for CA certificates, see [Single root CA](/docs/setup/best-practices/certificates/#single-root-ca). <!-- steps --> ## Rotate the CA certificates manually {{< caution >}} - Make sure to back up your certificate directory along with configuration files and any other necessary files. -This approach assumes operation of the Kubernetes control plane in a HA configuration with multiple API servers. Graceful termination of the API server is also assumed so clients can cleanly disconnect from one API server and reconnect to another. +This approach assumes operation of the Kubernetes control plane in a HA configuration with multiple API servers. +Graceful termination of the API server is also assumed so clients can cleanly disconnect from one API server and reconnect to another. Configurations with a single API server will experience unavailability while the API server is being restarted. - {{< /caution >}} -1. Distribute the new CA certificates and private keys (ex: `ca.crt`, `ca.key`, `front-proxy-ca.crt`, and `front-proxy-ca.key`) to all your control plane nodes in the Kubernetes certificates directory. +1. Distribute the new CA certificates and private keys + (ex: `ca.crt`, `ca.key`, `front-proxy-ca.crt`, and `front-proxy-ca.key`) + to all your control plane nodes in the Kubernetes certificates directory. 1. Update *Kubernetes controller manager's* `--root-ca-file` to include both old and new CA and restart controller manager. - Any service account created after this point will get secrets that include both old and new CAs. + Any service account created after this point will get secrets that include both old and new CAs. - {{< note >}} - - Remove the flag `--client-ca-file` from the *Kubernetes controller manager* configuration. You can also replace the existing client CA file or change this configuration item to reference a new, updated CA. [Issue 1350](https://github.com/kubernetes/kubeadm/issues/1350) tracks an issue with *Kubernetes controller manager* being unable to accept a CA bundle. - - {{< /note >}} + {{< note >}} + Remove the flag `--client-ca-file` from the *Kubernetes controller manager* configuration. + You can also replace the existing client CA file or change this configuration item to reference a new, updated CA. + [Issue 1350](https://github.com/kubernetes/kubeadm/issues/1350) tracks an issue with *Kubernetes controller manager* being unable to accept a CA bundle. + {{< /note >}} 1. Update all service account tokens to include both old and new CA certificates. - If any pods are started before new CA is used by API servers, they will get this update and trust both old and new CAs. + If any pods are started before new CA is used by API servers, they will get this update and trust both old and new CAs. - ```shell - base64_encoded_ca="$(base64 <path to file containing both old and new CAs>)" + ```shell + base64_encoded_ca="$(base64 <path to file containing both old and new CAs>)" - for namespace in $(kubectl get ns --no-headers | awk '{print $1}'); do - for token in $(kubectl get secrets --namespace "$namespace" --field-selector type=kubernetes.io/service-account-token -o name); do - kubectl get $token --namespace "$namespace" -o yaml | \ - /bin/sed "s/\(ca.crt:\).*/\1 ${base64_encoded_ca}" | \ - kubectl apply -f - - done - done - ``` + for namespace in $(kubectl get ns --no-headers | awk '{print $1}'); do + for token in $(kubectl get secrets --namespace "$namespace" --field-selector type=kubernetes.io/service-account-token -o name); do + kubectl get $token --namespace "$namespace" -o yaml | \ + /bin/sed "s/\(ca.crt:\).*/\1 ${base64_encoded_ca}" | \ + kubectl apply -f - + done + done + ``` 1. Restart all pods using in-cluster configs (ex: kube-proxy, coredns, etc) so they can use the updated certificate authority data from *ServiceAccount* secrets. - * Make sure coredns, kube-proxy and other pods using in-cluster configs are working as expected. + * Make sure coredns, kube-proxy and other pods using in-cluster configs are working as expected. 1. Append the both old and new CA to the file against `--client-ca-file` and `--kubelet-certificate-authority` flag in the `kube-apiserver` configuration. @@ -68,77 +69,88 @@ Configurations with a single API server will experience unavailability while the 1. Update certificates for user accounts by replacing the content of `client-certificate-data` and `client-key-data` respectively. - For information about creating certificates for individual user accounts, see [Configure certificates for user accounts](/docs/setup/best-practices/certificates/#configure-certificates-for-user-accounts). + For information about creating certificates for individual user accounts, see + [Configure certificates for user accounts](/docs/setup/best-practices/certificates/#configure-certificates-for-user-accounts). - Additionally, update the `certificate-authority-data` section in the kubeconfig files, respectively with Base64-encoded old and new certificate authority data + Additionally, update the `certificate-authority-data` section in the kubeconfig files, + respectively with Base64-encoded old and new certificate authority data 1. Follow below steps in a rolling fashion. - 1. Restart any other *[aggregated api servers](/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation/)* or *webhook handlers* to trust the new CA certificates. + 1. Restart any other *[aggregated api servers](/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation/)* + or *webhook handlers* to trust the new CA certificates. - 1. Restart the kubelet by update the file against `clientCAFile` in kubelet configuration and `certificate-authority-data` in kubelet.conf to use both the old and new CA on all nodes. + 1. Restart the kubelet by update the file against `clientCAFile` in kubelet configuration and + `certificate-authority-data` in kubelet.conf to use both the old and new CA on all nodes. - If your kubelet is not using client certificate rotation update `client-certificate-data` and `client-key-data` in kubelet.conf on all nodes along with the kubelet client certificate file usually found in `/var/lib/kubelet/pki`. + If your kubelet is not using client certificate rotation update `client-certificate-data` and + `client-key-data` in kubelet.conf on all nodes along with the kubelet client certificate file + usually found in `/var/lib/kubelet/pki`. - 1. Restart API servers with the certificates (`apiserver.crt`, `apiserver-kubelet-client.crt` and `front-proxy-client.crt`) signed by new CA. You can use the existing private keys or new private keys. If you changed the private keys then update these in the Kubernetes certificates directory as well. + 1. Restart API servers with the certificates (`apiserver.crt`, `apiserver-kubelet-client.crt` and + `front-proxy-client.crt`) signed by new CA. + You can use the existing private keys or new private keys. + If you changed the private keys then update these in the Kubernetes certificates directory as well. - Since the pod trusts both old and new CAs, there will be a momentarily disconnection after which the pod's kube client will reconnect to the new API server that uses the certificate signed by the new CA. + Since the pod trusts both old and new CAs, there will be a momentarily disconnection + after which the pod's kube client will reconnect to the new API server + that uses the certificate signed by the new CA. - * Restart Scheduler to use the new CAs. + * Restart Scheduler to use the new CAs. - * Make sure control plane components logs no TLS errors. + * Make sure control plane components logs no TLS errors. - {{< note >}} + {{< note >}} + To generate certificates and private keys for your cluster using the `openssl` command line tool, see [Certificates (`openssl`)](/docs/concepts/cluster-administration/certificates/#openssl). + You can also use [`cfssl`](/docs/concepts/cluster-administration/certificates/#cfssl). + {{< /note >}} - To generate certificates and private keys for your cluster using the `openssl` command line tool, see [Certificates (`openssl`)](/docs/concepts/cluster-administration/certificates/#openssl). - You can also use [`cfssl`](/docs/concepts/cluster-administration/certificates/#cfssl). + 1. Annotate any Daemonsets and Deployments to trigger pod replacement in a safer rolling fashion. - {{< /note >}} + Example: - 1. Annotate any Daemonsets and Deployments to trigger pod replacement in a safer rolling fashion. + ```shell + for namespace in $(kubectl get namespace -o jsonpath='{.items[*].metadata.name}'); do + for name in $(kubectl get deployments -n $namespace -o jsonpath='{.items[*].metadata.name}'); do + kubectl patch deployment -n ${namespace} ${name} -p '{"spec":{"template":{"metadata":{"annotations":{"ca-rotation": "1"}}}}}'; + done + for name in $(kubectl get daemonset -n $namespace -o jsonpath='{.items[*].metadata.name}'); do + kubectl patch daemonset -n ${namespace} ${name} -p '{"spec":{"template":{"metadata":{"annotations":{"ca-rotation": "1"}}}}}'; + done + done + ``` - Example: - - ```shell - for namespace in $(kubectl get namespace -o jsonpath='{.items[*].metadata.name}'); do - for name in $(kubectl get deployments -n $namespace -o jsonpath='{.items[*].metadata.name}'); do - kubectl patch deployment -n ${namespace} ${name} -p '{"spec":{"template":{"metadata":{"annotations":{"ca-rotation": "1"}}}}}'; - done - for name in $(kubectl get daemonset -n $namespace -o jsonpath='{.items[*].metadata.name}'); do - kubectl patch daemonset -n ${namespace} ${name} -p '{"spec":{"template":{"metadata":{"annotations":{"ca-rotation": "1"}}}}}'; - done - done - ``` - - {{< note >}} - - To limit the number of concurrent disruptions that your application experiences, see [configure pod disruption budget](docs/tasks/run-application/configure-pdb/). - - {{< /note >}} + {{< note >}} + To limit the number of concurrent disruptions that your application experiences, + see [configure pod disruption budget](/docs/tasks/run-application/configure-pdb/). + {{< /note >}} 1. If your cluster is using bootstrap tokens to join nodes, update the ConfigMap `cluster-info` in the `kube-public` namespace with new CA. - ```shell - base64_encoded_ca="$(base64 /etc/kubernetes/pki/ca.crt)" + ```shell + base64_encoded_ca="$(base64 /etc/kubernetes/pki/ca.crt)" - kubectl get cm/cluster-info --namespace kube-public -o yaml | \ - /bin/sed "s/\(certificate-authority-data:\).*/\1 ${base64_encoded_ca}" | \ - kubectl apply -f - - ``` + kubectl get cm/cluster-info --namespace kube-public -o yaml | \ + /bin/sed "s/\(certificate-authority-data:\).*/\1 ${base64_encoded_ca}" | \ + kubectl apply -f - + ``` 1. Verify the cluster functionality. - 1. Validate the logs from control plane components, along with the kubelet and the kube-proxy are not throwing any tls errors, see [looking at the logs](/docs/tasks/debug-application-cluster/debug-cluster/#looking-at-logs). + 1. Validate the logs from control plane components, along with the kubelet and the + kube-proxy are not throwing any tls errors, see + [looking at the logs](/docs/tasks/debug-application-cluster/debug-cluster/#looking-at-logs). - 1. Validate logs from any aggregated api servers and pods using in-cluster config. + 1. Validate logs from any aggregated api servers and pods using in-cluster config. 1. Once the cluster functionality is successfully verified: - 1. Update all service account tokens to include new CA certificate only. + 1. Update all service account tokens to include new CA certificate only. - * All pods using an in-cluster kubeconfig will eventually need to be restarted to pick up the new SA secret for the old CA to be completely untrusted. + * All pods using an in-cluster kubeconfig will eventually need to be restarted to pick up the new SA secret for the old CA to be completely untrusted. - 1. Restart the control plane components by removing the old CA from the kubeconfig files and the files against `--client-ca-file`, `--root-ca-file` flags resp. + 1. Restart the control plane components by removing the old CA from the kubeconfig files and the files against `--client-ca-file`, `--root-ca-file` flags resp. + + 1. Restart kubelet by removing the old CA from file against the `clientCAFile` flag and kubelet kubeconfig file. - 1. Restart kubelet by removing the old CA from file against the `clientCAFile` flag and kubelet kubeconfig file. diff --git a/content/en/docs/tasks/tools/_index.md b/content/en/docs/tasks/tools/_index.md index cabf9a3c7b..7f43d34be7 100755 --- a/content/en/docs/tasks/tools/_index.md +++ b/content/en/docs/tasks/tools/_index.md @@ -2,5 +2,40 @@ title: "Install Tools" description: Set up Kubernetes tools on your computer. weight: 10 +no_list: true --- +## kubectl + +The Kubernetes command-line tool, `kubectl`, allows you to run commands against +Kubernetes clusters. You can use kubectl to deploy applications, inspect and manage +cluster resources, and view logs. + +See [Install and Set Up kubectl](/docs/tasks/tools/install-kubectl/) for information about how to +download and install `kubectl` and set it up for accessing your cluster. + +You can also read the [`kubectl` reference documentation](/docs/reference/kubectl/). + +## Minikube + +[Minikube](https://minikube.sigs.k8s.io/) is a tool that lets you run +Kubernetes locally. Minikube runs a single-node Kubernetes cluster on your personal +computer (including Windows, macOS and Linux PCs) so that you can try out Kubernetes, +or for daily development work. + +You can follow the official [Get Started!](https://minikube.sigs.k8s.io/docs/start/) +guide, or read [Install Minikube](/docs/tasks/tools/install-minikube/) if your focus +is on getting the tool installed. + +Once you have Minikube working, you can use it to +[run a sample application](/docs/tutorials/hello-minikube/). + +## kind + +Like Minikube, [kind](https://kind.sigs.k8s.io/docs/) lets you run Kubernetes on +your local compute. Unlike Minikuke, kind only works with a single container runtime: +it requires that you have [Docker](https://docs.docker.com/get-docker/) installed +and configured. + +[Quick Start](https://kind.sigs.k8s.io/docs/user/quick-start/) shows you what you +need to do to get up and running with kind. diff --git a/content/en/docs/tasks/tools/install-kubectl.md b/content/en/docs/tasks/tools/install-kubectl.md index 25b5cab9b5..e3d6c0aa9c 100644 --- a/content/en/docs/tasks/tools/install-kubectl.md +++ b/content/en/docs/tasks/tools/install-kubectl.md @@ -28,7 +28,7 @@ You must use a kubectl version that is within one minor version difference of yo 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 + curl -LO "https://storage.googleapis.com/kubernetes-release/release/$(curl -s https://storage.googleapis.com/kubernetes-release/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. @@ -310,7 +310,12 @@ You can install kubectl as part of the Google Cloud SDK. ## Verifying kubectl configuration -In order for kubectl to find and access a Kubernetes cluster, it needs a [kubeconfig file](/docs/tasks/access-application-cluster/configure-access-multiple-clusters/), which is created automatically when you create a cluster using [kube-up.sh](https://github.com/kubernetes/kubernetes/blob/master/cluster/kube-up.sh) or successfully deploy a Minikube cluster. By default, kubectl configuration is located at `~/.kube/config`. +In order for kubectl to find and access a Kubernetes cluster, it needs a +[kubeconfig file](/docs/concepts/configuration/organize-cluster-access-kubeconfig/), +which is created automatically when you create a cluster using +[kube-up.sh](https://github.com/kubernetes/kubernetes/blob/master/cluster/kube-up.sh) +or successfully deploy a Minikube cluster. +By default, kubectl configuration is located at `~/.kube/config`. Check that kubectl is properly configured by getting the cluster state: @@ -518,5 +523,7 @@ compinit * [Install Minikube](/docs/tasks/tools/install-minikube/) * See the [getting started guides](/docs/setup/) for more about creating clusters. * [Learn how to launch and expose your application.](/docs/tasks/access-application-cluster/service-access-application-cluster/) -* If you need access to a cluster you didn't create, see the [Sharing Cluster Access document](/docs/tasks/access-application-cluster/configure-access-multiple-clusters/). +* If you need access to a cluster you didn't create, see the + [Sharing Cluster Access document](/docs/tasks/access-application-cluster/configure-access-multiple-clusters/). * Read the [kubectl reference docs](/docs/reference/kubectl/kubectl/) + diff --git a/content/en/docs/tasks/tools/install-minikube.md b/content/en/docs/tasks/tools/install-minikube.md index f1f3788141..a5e7ed0c2b 100644 --- a/content/en/docs/tasks/tools/install-minikube.md +++ b/content/en/docs/tasks/tools/install-minikube.md @@ -206,7 +206,7 @@ To confirm successful installation of both a hypervisor and Minikube, you can ru {{< note >}} -For setting the `--driver` with `minikube start`, enter the name of the hypervisor you installed in lowercase letters where `<driver_name>` is mentioned below. A full list of `--driver` values is available in [specifying the VM driver documentation](https://kubernetes.io/docs/setup/learning-environment/minikube/#specifying-the-vm-driver). +For setting the `--driver` with `minikube start`, enter the name of the hypervisor you installed in lowercase letters where `<driver_name>` is mentioned below. A full list of `--driver` values is available in [specifying the VM driver documentation](/docs/setup/learning-environment/minikube/#specifying-the-vm-driver). {{< /note >}} diff --git a/content/en/docs/test.md b/content/en/docs/test.md index 848decff35..071a873b37 100644 --- a/content/en/docs/test.md +++ b/content/en/docs/test.md @@ -1,7 +1,6 @@ --- title: Docs smoke test page main_menu: false -mermaid: true --- This page serves two purposes: @@ -235,7 +234,6 @@ link target in parentheses. [Link to Kubernetes.io](https://kubernetes.io/) or You can also use HTML, but it is not preferred. <a href="https://kubernetes.io/">Link to Kubernetes.io</a> - ## Images To format an image, use similar syntax to [links](#links), but add a leading `!` @@ -298,7 +296,8 @@ tables, use HTML instead. ## Visualizations with Mermaid -Add `mermaid: true` to the [front matter](https://gohugo.io/content-management/front-matter/) of any page to enable [Mermaid JS](https://mermaidjs.github.io) visualizations. The Mermaid JS version is specified in [/layouts/partials/head.html](https://github.com/kubernetes/website/blob/master/layouts/partials/head.html) +You can use [Mermaid JS](https://mermaidjs.github.io) visualizations. +The Mermaid JS version is specified in [/layouts/partials/head.html](https://github.com/kubernetes/website/blob/master/layouts/partials/head.html) ``` {{</* mermaid */>}} diff --git a/content/en/docs/tutorials/_index.md b/content/en/docs/tutorials/_index.md index 0deadcd945..2313d78e87 100644 --- a/content/en/docs/tutorials/_index.md +++ b/content/en/docs/tutorials/_index.md @@ -1,6 +1,7 @@ --- title: Tutorials main_menu: true +no_list: true weight: 60 content_type: concept --- @@ -14,8 +15,6 @@ each of which has a sequence of steps. Before walking through each tutorial, you may want to bookmark the [Standardized Glossary](/docs/reference/glossary/) page for later references. - - <!-- body --> ## Basics @@ -64,13 +63,8 @@ Before walking through each tutorial, you may want to bookmark the * [Using Source IP](/docs/tutorials/services/source-ip/) - - ## {{% heading "whatsnext" %}} - If you would like to write a tutorial, see [Content Page Types](/docs/contribute/style/page-content-types/) for information about the tutorial page type. - - diff --git a/content/en/docs/tutorials/configuration/configure-redis-using-configmap.md b/content/en/docs/tutorials/configuration/configure-redis-using-configmap.md index 37f6f9e014..7555a58201 100644 --- a/content/en/docs/tutorials/configuration/configure-redis-using-configmap.md +++ b/content/en/docs/tutorials/configuration/configure-redis-using-configmap.md @@ -93,7 +93,7 @@ Use `kubectl exec` to enter the pod and run the `redis-cli` tool to verify that the configuration was correctly applied: ```shell -kubectl exec -it redis redis-cli +kubectl exec -it redis -- redis-cli 127.0.0.1:6379> CONFIG GET maxmemory 1) "maxmemory" 2) "2097152" diff --git a/content/en/docs/tutorials/hello-minikube.md b/content/en/docs/tutorials/hello-minikube.md index 9ba2de1abf..901e0063cf 100644 --- a/content/en/docs/tutorials/hello-minikube.md +++ b/content/en/docs/tutorials/hello-minikube.md @@ -65,7 +65,7 @@ This tutorial provides a container image that uses NGINX to echo back all the re ## Create a Deployment -A Kubernetes [*Pod*](/docs/concepts/workloads/pods/pod/) is a group of one or more Containers, +A Kubernetes [*Pod*](/docs/concepts/workloads/pods/) is a group of one or more Containers, tied together for the purposes of administration and networking. The Pod in this tutorial has only one Container. A Kubernetes [*Deployment*](/docs/concepts/workloads/controllers/deployment/) checks on the health of your @@ -118,7 +118,7 @@ Pod runs a Container based on the provided Docker image. ``` {{< note >}} - For more information about `kubectl`commands, see the [kubectl overview](/docs/user-guide/kubectl-overview/). +For more information about `kubectl` commands, see the [kubectl overview](/docs/reference/kubectl/overview/). {{< /note >}} ## Create a Service diff --git a/content/en/docs/tutorials/kubernetes-basics/deploy-app/deploy-interactive.html b/content/en/docs/tutorials/kubernetes-basics/deploy-app/deploy-interactive.html index 6d7e15a7c4..fb782458de 100644 --- a/content/en/docs/tutorials/kubernetes-basics/deploy-app/deploy-interactive.html +++ b/content/en/docs/tutorials/kubernetes-basics/deploy-app/deploy-interactive.html @@ -20,7 +20,7 @@ weight: 20 <div class="row"> <div class="col-md-12"> <p> - A Pod is the basic execution unit of a Kubernetes application. Each Pod represents a part of a workload that is running on your cluster. <a href="/docs/concepts/workloads/pods/pod-overview/#understanding-pods">Learn more about Pods</a>. + A Pod is the basic execution unit of a Kubernetes application. Each Pod represents a part of a workload that is running on your cluster. <a href="/docs/concepts/workloads/pods/">Learn more about Pods</a>. </p> </div> </div> diff --git a/content/en/docs/tutorials/kubernetes-basics/expose/expose-intro.html b/content/en/docs/tutorials/kubernetes-basics/expose/expose-intro.html index 8a7d60dd87..c610b6e9f4 100644 --- a/content/en/docs/tutorials/kubernetes-basics/expose/expose-intro.html +++ b/content/en/docs/tutorials/kubernetes-basics/expose/expose-intro.html @@ -28,7 +28,7 @@ weight: 10 <div class="col-md-8"> <h3>Overview of Kubernetes Services</h3> - <p>Kubernetes <a href="/docs/concepts/workloads/pods/pod-overview/">Pods</a> are mortal. Pods in fact have a <a href="/docs/concepts/workloads/pods/pod-lifecycle/">lifecycle</a>. When a worker node dies, the Pods running on the Node are also lost. A <a href="/docs/concepts/workloads/controllers/replicaset/">ReplicaSet</a> might then dynamically drive the cluster back to desired state via creation of new Pods to keep your application running. As another example, consider an image-processing backend with 3 replicas. Those replicas are exchangeable; the front-end system should not care about backend replicas or even if a Pod is lost and recreated. That said, each Pod in a Kubernetes cluster has a unique IP address, even Pods on the same Node, so there needs to be a way of automatically reconciling changes among Pods so that your applications continue to function.</p> + <p>Kubernetes <a href="/docs/concepts/workloads/pods/">Pods</a> are mortal. Pods in fact have a <a href="/docs/concepts/workloads/pods/pod-lifecycle/">lifecycle</a>. When a worker node dies, the Pods running on the Node are also lost. A <a href="/docs/concepts/workloads/controllers/replicaset/">ReplicaSet</a> might then dynamically drive the cluster back to desired state via creation of new Pods to keep your application running. As another example, consider an image-processing backend with 3 replicas. Those replicas are exchangeable; the front-end system should not care about backend replicas or even if a Pod is lost and recreated. That said, each Pod in a Kubernetes cluster has a unique IP address, even Pods on the same Node, so there needs to be a way of automatically reconciling changes among Pods so that your applications continue to function.</p> <p>A Service in Kubernetes is an abstraction which defines a logical set of Pods and a policy by which to access them. Services enable a loose coupling between dependent Pods. A Service is defined using YAML <a href="/docs/concepts/configuration/overview/#general-configuration-tips">(preferred)</a> or JSON, like all Kubernetes objects. The set of Pods targeted by a Service is usually determined by a <i>LabelSelector</i> (see below for why you might want a Service without including <code>selector</code> in the spec).</p> diff --git a/content/en/docs/tutorials/kubernetes-basics/scale/scale-intro.html b/content/en/docs/tutorials/kubernetes-basics/scale/scale-intro.html index 943ef01e0f..86e3621a28 100644 --- a/content/en/docs/tutorials/kubernetes-basics/scale/scale-intro.html +++ b/content/en/docs/tutorials/kubernetes-basics/scale/scale-intro.html @@ -40,7 +40,7 @@ weight: 10 </ul> </div> <div class="content__box content__box_fill"> - <p><i> You can create from the start a Deployment with multiple instances using the --replicas parameter for the kubectl run command </i></p> + <p><i> You can create from the start a Deployment with multiple instances using the --replicas parameter for the kubectl create deployment command </i></p> </div> </div> </div> diff --git a/content/en/docs/tutorials/services/source-ip.md b/content/en/docs/tutorials/services/source-ip.md index 03a9bb097c..3bdf9d492f 100644 --- a/content/en/docs/tutorials/services/source-ip.md +++ b/content/en/docs/tutorials/services/source-ip.md @@ -177,7 +177,7 @@ service/nodeport exposed ```shell NODEPORT=$(kubectl get -o jsonpath="{.spec.ports[0].nodePort}" services nodeport) -NODES=$(kubectl get nodes -o jsonpath='{ $.items[*].status.addresses[?(@.type=="ExternalIP")].address }') +NODES=$(kubectl get nodes -o jsonpath='{ $.items[*].status.addresses[?(@.type=="InternalIP")].address }') ``` If you're running on a cloud provider, you may need to open up a firewall-rule @@ -206,18 +206,19 @@ Note that these are not the correct client IPs, they're cluster internal IPs. Th Visually: -``` - client - \ ^ - \ \ - v \ - node 1 <--- node 2 - | ^ SNAT - | | ---> - v | - endpoint -``` +{{< mermaid >}} +graph LR; + client(client)-->node2[Node 2]; + node2-->client; + node2-. SNAT .->node1[Node 1]; + node1-. SNAT .->node2; + node1-->endpoint(Endpoint); + classDef plain fill:#ddd,stroke:#fff,stroke-width:4px,color:#000; + classDef k8s fill:#326ce5,stroke:#fff,stroke-width:4px,color:#fff; + class node1,node2,endpoint k8s; + class client plain; +{{</ mermaid >}} To avoid this, Kubernetes has a feature to [preserve the client source IP](/docs/tasks/access-application-cluster/create-external-load-balancer/#preserving-the-client-source-ip). @@ -261,17 +262,18 @@ This is what happens: Visually: -``` - client - ^ / \ - / / \ - / v X - node 1 node 2 - ^ | - | | - | v - endpoint -``` +{{< mermaid >}} +graph TD; + client --> node1[Node 1]; + client(client) --x node2[Node 2]; + node1 --> endpoint(endpoint); + endpoint --> node1; + + classDef plain fill:#ddd,stroke:#fff,stroke-width:4px,color:#000; + classDef k8s fill:#326ce5,stroke:#fff,stroke-width:4px,color:#fff; + class node1,node2,endpoint k8s; + class client plain; +{{</ mermaid >}} @@ -324,17 +326,7 @@ deliberately failing health checks. Visually: -``` - client - | - lb VIP - / ^ - v / -health check ---> node 1 node 2 <--- health check - 200 <--- ^ | ---> 500 - | V - endpoint -``` +![Source IP with externalTrafficPolicy](/images/docs/sourceip-externaltrafficpolicy.svg) You can test this by setting the annotation: @@ -420,7 +412,7 @@ protocol between the loadbalancer and backend to communicate the true client IP such as the HTTP [Forwarded](https://tools.ietf.org/html/rfc7239#section-5.2) or [X-FORWARDED-FOR](https://en.wikipedia.org/wiki/X-Forwarded-For) headers, or the -[proxy protocol](http://www.haproxy.org/download/1.5/doc/proxy-protocol.txt). +[proxy protocol](https://www.haproxy.org/download/1.5/doc/proxy-protocol.txt). Load balancers in the second category can leverage the feature described above by creating an HTTP health check pointing at the port stored in the `service.spec.healthCheckNodePort` field on the Service. @@ -447,6 +439,4 @@ kubectl delete deployment source-ip-app ## {{% heading "whatsnext" %}} * Learn more about [connecting applications via services](/docs/concepts/services-networking/connect-applications-service/) -* Read how to [Create an External Load Balancer](https://kubernetes.io/docs/tasks/access-application-cluster/create-external-load-balancer/) - - +* Read how to [Create an External Load Balancer](/docs/tasks/access-application-cluster/create-external-load-balancer/) diff --git a/content/en/docs/tutorials/stateful-application/cassandra.md b/content/en/docs/tutorials/stateful-application/cassandra.md index 3fa56b26ea..72d3f928a8 100644 --- a/content/en/docs/tutorials/stateful-application/cassandra.md +++ b/content/en/docs/tutorials/stateful-application/cassandra.md @@ -7,9 +7,13 @@ weight: 30 --- <!-- overview --> -This tutorial shows you how to run [Apache Cassandra](http://cassandra.apache.org/) on Kubernetes. Cassandra, a database, needs persistent storage to provide data durability (application _state_). In this example, a custom Cassandra seed provider lets the database discover new Cassandra instances as they join the Cassandra cluster. +This tutorial shows you how to run [Apache Cassandra](https://cassandra.apache.org/) on Kubernetes. +Cassandra, a database, needs persistent storage to provide data durability (application _state_). +In this example, a custom Cassandra seed provider lets the database discover new Cassandra instances as they join the Cassandra cluster. -*StatefulSets* make it easier to deploy stateful applications into your Kubernetes cluster. For more information on the features used in this tutorial, see [StatefulSet](/docs/concepts/workloads/controllers/statefulset/). +*StatefulSets* make it easier to deploy stateful applications into your Kubernetes cluster. +For more information on the features used in this tutorial, see +[StatefulSet](/docs/concepts/workloads/controllers/statefulset/). {{< note >}} Cassandra and Kubernetes both use the term _node_ to mean a member of a cluster. In this @@ -38,12 +42,17 @@ new Cassandra Pods as they appear inside your Kubernetes cluster. {{< include "task-tutorial-prereqs.md" >}} -To complete this tutorial, you should already have a basic familiarity with {{< glossary_tooltip text="Pods" term_id="pod" >}}, {{< glossary_tooltip text="Services" term_id="service" >}}, and {{< glossary_tooltip text="StatefulSets" term_id="StatefulSet" >}}. +To complete this tutorial, you should already have a basic familiarity with +{{< glossary_tooltip text="Pods" term_id="pod" >}}, +{{< glossary_tooltip text="Services" term_id="service" >}}, and +{{< glossary_tooltip text="StatefulSets" term_id="StatefulSet" >}}. ### Additional Minikube setup instructions {{< caution >}} -[Minikube](/docs/getting-started-guides/minikube/) defaults to 1024MiB of memory and 1 CPU. Running Minikube with the default resource configuration results in insufficient resource errors during this tutorial. To avoid these errors, start Minikube with the following settings: +[Minikube](/docs/setup/learning-environment/minikube/) defaults to 1024MiB of memory and 1 CPU. +Running Minikube with the default resource configuration results in insufficient resource +errors during this tutorial. To avoid these errors, start Minikube with the following settings: ```shell minikube start --memory 5120 --cpus=4 @@ -51,11 +60,11 @@ minikube start --memory 5120 --cpus=4 {{< /caution >}} - <!-- lessoncontent --> ## Creating a headless Service for Cassandra {#creating-a-cassandra-headless-service} -In Kubernetes, a {{< glossary_tooltip text="Service" term_id="service" >}} describes a set of {{< glossary_tooltip text="Pods" term_id="pod" >}} that perform the same task. +In Kubernetes, a {{< glossary_tooltip text="Service" term_id="service" >}} describes a set of +{{< glossary_tooltip text="Pods" term_id="pod" >}} that perform the same task. The following Service is used for DNS lookups between Cassandra Pods and clients within your cluster: @@ -83,14 +92,17 @@ NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE cassandra ClusterIP None <none> 9042/TCP 45s ``` -If you don't see a Service named `cassandra`, that means creation failed. Read [Debug Services](/docs/tasks/debug-application-cluster/debug-service/) for help troubleshooting common issues. +If you don't see a Service named `cassandra`, that means creation failed. Read +[Debug Services](/docs/tasks/debug-application-cluster/debug-service/) +for help troubleshooting common issues. ## Using a StatefulSet to create a Cassandra ring The StatefulSet manifest, included below, creates a Cassandra ring that consists of three Pods. {{< note >}} -This example uses the default provisioner for Minikube. Please update the following StatefulSet for the cloud you are working with. +This example uses the default provisioner for Minikube. +Please update the following StatefulSet for the cloud you are working with. {{< /note >}} {{< codenew file="application/cassandra/cassandra-statefulset.yaml" >}} @@ -182,7 +194,8 @@ Use `kubectl edit` to modify the size of a Cassandra StatefulSet. kubectl edit statefulset cassandra ``` - This command opens an editor in your terminal. The line you need to change is the `replicas` field. The following sample is an excerpt of the StatefulSet file: + This command opens an editor in your terminal. The line you need to change is the `replicas` field. + The following sample is an excerpt of the StatefulSet file: ```yaml # Please edit the object below. Lines beginning with a '#' will be ignored, @@ -225,10 +238,12 @@ Use `kubectl edit` to modify the size of a Cassandra StatefulSet. ## {{% heading "cleanup" %}} -Deleting or scaling a StatefulSet down does not delete the volumes associated with the StatefulSet. This setting is for your safety because your data is more valuable than automatically purging all related StatefulSet resources. +Deleting or scaling a StatefulSet down does not delete the volumes associated with the StatefulSet. +This setting is for your safety because your data is more valuable than automatically purging all related StatefulSet resources. {{< warning >}} -Depending on the storage class and reclaim policy, deleting the *PersistentVolumeClaims* may cause the associated volumes to also be deleted. Never assume you’ll be able to access data if its volume claims are deleted. +Depending on the storage class and reclaim policy, deleting the *PersistentVolumeClaims* may cause the associated volumes +to also be deleted. Never assume you’ll be able to access data if its volume claims are deleted. {{< /warning >}} 1. Run the following commands (chained together into a single command) to delete everything in the Cassandra StatefulSet: diff --git a/content/en/docs/tutorials/stateful-application/mysql-wordpress-persistent-volume.md b/content/en/docs/tutorials/stateful-application/mysql-wordpress-persistent-volume.md index d43d9b736f..d22d7df5ca 100644 --- a/content/en/docs/tutorials/stateful-application/mysql-wordpress-persistent-volume.md +++ b/content/en/docs/tutorials/stateful-application/mysql-wordpress-persistent-volume.md @@ -190,8 +190,8 @@ Now you can verify that all objects exist. The response should be like this: ``` - NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE - wordpress ClusterIP 10.0.0.89 <pending> 80:32406/TCP 4m + NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE + wordpress LoadBalancer 10.0.0.89 <pending> 80:32406/TCP 4m ``` {{< note >}} diff --git a/content/en/docs/tutorials/stateful-application/zookeeper.md b/content/en/docs/tutorials/stateful-application/zookeeper.md index 3bed3e059c..eaba068b6f 100644 --- a/content/en/docs/tutorials/stateful-application/zookeeper.md +++ b/content/en/docs/tutorials/stateful-application/zookeeper.md @@ -15,25 +15,23 @@ weight: 40 <!-- overview --> This tutorial demonstrates running [Apache Zookeeper](https://zookeeper.apache.org) on Kubernetes using [StatefulSets](/docs/concepts/workloads/controllers/statefulset/), -[PodDisruptionBudgets](/docs/concepts/workloads/pods/disruptions/#specifying-a-poddisruptionbudget), -and [PodAntiAffinity](/docs/user-guide/node-selection/#inter-pod-affinity-and-anti-affinity-beta-feature). - +[PodDisruptionBudgets](/docs/concepts/workloads/pods/disruptions/#pod-disruption-budget), +and [PodAntiAffinity](/docs/concepts/scheduling-eviction/assign-pod-node/#affinity-and-anti-affinity). ## {{% heading "prerequisites" %}} - Before starting this tutorial, you should be familiar with the following Kubernetes concepts. -- [Pods](/docs/user-guide/pods/single-container/) +- [Pods](/docs/concepts/workloads/pods/) - [Cluster DNS](/docs/concepts/services-networking/dns-pod-service/) - [Headless Services](/docs/concepts/services-networking/service/#headless-services) - [PersistentVolumes](/docs/concepts/storage/volumes/) - [PersistentVolume Provisioning](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/staging/persistent-volume-provisioning/) - [StatefulSets](/docs/concepts/workloads/controllers/statefulset/) -- [PodDisruptionBudgets](/docs/concepts/workloads/pods/disruptions/#specifying-a-poddisruptionbudget) -- [PodAntiAffinity](/docs/user-guide/node-selection/#inter-pod-affinity-and-anti-affinity-beta-feature) -- [kubectl CLI](/docs/user-guide/kubectl/) +- [PodDisruptionBudgets](/docs/concepts/workloads/pods/disruptions/#pod-disruption-budget) +- [PodAntiAffinity](/docs/concepts/scheduling-eviction/assign-pod-node/#affinity-and-anti-affinity) +- [kubectl CLI](/docs/reference/kubectl/kubectl/) You will require a cluster with at least four nodes, and each node requires at least 2 CPUs and 4 GiB of memory. In this tutorial you will cordon and drain the cluster's nodes. **This means that the cluster will terminate and evict all Pods on its nodes, and the nodes will temporarily become unschedulable.** You should use a dedicated cluster for this tutorial, or you should ensure that the disruption you cause will not interfere with other tenants. @@ -51,7 +49,7 @@ After this tutorial, you will know the following. - How to consistently configure the ensemble using ConfigMaps. - How to spread the deployment of ZooKeeper servers in the ensemble. - How to use PodDisruptionBudgets to ensure service availability during planned maintenance. - + <!-- lessoncontent --> @@ -75,7 +73,7 @@ ZooKeeper servers keep their entire state machine in memory, and write every mut The manifest below contains a [Headless Service](/docs/concepts/services-networking/service/#headless-services), a [Service](/docs/concepts/services-networking/service/), -a [PodDisruptionBudget](/docs/concepts/workloads/pods/disruptions//#specifying-a-poddisruptionbudget), +a [PodDisruptionBudget](/docs/concepts/workloads/pods/disruptions/#pod-disruption-budgets), and a [StatefulSet](/docs/concepts/workloads/controllers/statefulset/). {{< codenew file="application/zookeeper/zookeeper.yaml" >}} @@ -91,7 +89,7 @@ kubectl apply -f https://k8s.io/examples/application/zookeeper/zookeeper.yaml This creates the `zk-hs` Headless Service, the `zk-cs` Service, the `zk-pdb` PodDisruptionBudget, and the `zk` StatefulSet. -```shell +``` service/zk-hs created service/zk-cs created poddisruptionbudget.policy/zk-pdb created @@ -107,7 +105,7 @@ kubectl get pods -w -l app=zk Once the `zk-2` Pod is Running and Ready, use `CTRL-C` to terminate kubectl. -```shell +``` NAME READY STATUS RESTARTS AGE zk-0 0/1 Pending 0 0s zk-0 0/1 Pending 0 0s @@ -127,7 +125,7 @@ zk-2 1/1 Running 0 40s ``` The StatefulSet controller creates three Pods, and each Pod has a container with -a [ZooKeeper](http://www-us.apache.org/dist/zookeeper/stable/) server. +a [ZooKeeper](https://www-us.apache.org/dist/zookeeper/stable/) server. ### Facilitating Leader Election @@ -143,7 +141,7 @@ for i in 0 1 2; do kubectl exec zk-$i -- hostname; done The StatefulSet controller provides each Pod with a unique hostname based on its ordinal index. The hostnames take the form of `<statefulset name>-<ordinal index>`. Because the `replicas` field of the `zk` StatefulSet is set to `3`, the Set's controller creates three Pods with their hostnames set to `zk-0`, `zk-1`, and `zk-2`. -```shell +``` zk-0 zk-1 zk-2 @@ -159,7 +157,7 @@ for i in 0 1 2; do echo "myid zk-$i";kubectl exec zk-$i -- cat /var/lib/zookeepe Because the identifiers are natural numbers and the ordinal indices are non-negative integers, you can generate an identifier by adding 1 to the ordinal. -```shell +``` myid zk-0 1 myid zk-1 @@ -177,7 +175,7 @@ for i in 0 1 2; do kubectl exec zk-$i -- hostname -f; done The `zk-hs` Service creates a domain for all of the Pods, `zk-hs.default.svc.cluster.local`. -```shell +``` zk-0.zk-hs.default.svc.cluster.local zk-1.zk-hs.default.svc.cluster.local zk-2.zk-hs.default.svc.cluster.local @@ -196,7 +194,7 @@ the file, the `1`, `2`, and `3` correspond to the identifiers in the ZooKeeper servers' `myid` files. They are set to the FQDNs for the Pods in the `zk` StatefulSet. -```shell +``` clientPort=2181 dataDir=/var/lib/zookeeper/data dataLogDir=/var/lib/zookeeper/log @@ -219,7 +217,9 @@ Consensus protocols require that the identifiers of each participant be unique. ```shell kubectl get pods -w -l app=zk +``` +``` NAME READY STATUS RESTARTS AGE zk-0 0/1 Pending 0 0s zk-0 0/1 Pending 0 0s @@ -243,7 +243,7 @@ the FQDNs of the ZooKeeper servers will resolve to a single endpoint, and that endpoint will be the unique ZooKeeper server claiming the identity configured in its `myid` file. -```shell +``` zk-0.zk-hs.default.svc.cluster.local zk-1.zk-hs.default.svc.cluster.local zk-2.zk-hs.default.svc.cluster.local @@ -252,7 +252,7 @@ zk-2.zk-hs.default.svc.cluster.local This ensures that the `servers` properties in the ZooKeepers' `zoo.cfg` files represents a correctly configured ensemble. -```shell +``` server.1=zk-0.zk-hs.default.svc.cluster.local:2888:3888 server.2=zk-1.zk-hs.default.svc.cluster.local:2888:3888 server.3=zk-2.zk-hs.default.svc.cluster.local:2888:3888 @@ -269,7 +269,8 @@ The command below executes the `zkCli.sh` script to write `world` to the path `/ ```shell kubectl exec zk-0 zkCli.sh create /hello world - +``` +``` WATCHER:: WatchedEvent state:SyncConnected type:None path:null @@ -285,7 +286,7 @@ kubectl exec zk-1 zkCli.sh get /hello The data that you created on `zk-0` is available on all the servers in the ensemble. -```shell +``` WATCHER:: WatchedEvent state:SyncConnected type:None path:null @@ -316,6 +317,9 @@ Use the [`kubectl delete`](/docs/reference/generated/kubectl/kubectl-commands/#d ```shell kubectl delete statefulset zk +``` + +``` statefulset.apps "zk" deleted ``` @@ -327,7 +331,7 @@ kubectl get pods -w -l app=zk When `zk-0` if fully terminated, use `CTRL-C` to terminate kubectl. -```shell +``` zk-2 1/1 Terminating 0 9m zk-0 1/1 Terminating 0 11m zk-1 1/1 Terminating 0 10m @@ -358,7 +362,7 @@ kubectl get pods -w -l app=zk Once the `zk-2` Pod is Running and Ready, use `CTRL-C` to terminate kubectl. -```shell +``` NAME READY STATUS RESTARTS AGE zk-0 0/1 Pending 0 0s zk-0 0/1 Pending 0 0s @@ -386,7 +390,7 @@ kubectl exec zk-2 zkCli.sh get /hello Even though you terminated and recreated all of the Pods in the `zk` StatefulSet, the ensemble still serves the original value. -```shell +``` WATCHER:: WatchedEvent state:SyncConnected type:None path:null @@ -430,7 +434,7 @@ kubectl get pvc -l app=zk When the `StatefulSet` recreated its Pods, it remounts the Pods' PersistentVolumes. -```shell +``` NAME STATUS VOLUME CAPACITY ACCESSMODES AGE datadir-zk-0 Bound pvc-bed742cd-bcb1-11e6-994f-42010a800002 20Gi RWO 1h datadir-zk-1 Bound pvc-bedd27d2-bcb1-11e6-994f-42010a800002 20Gi RWO 1h @@ -464,6 +468,8 @@ Get the `zk` StatefulSet. ```shell kubectl get sts zk -o yaml +``` +``` … command: - sh @@ -494,7 +500,7 @@ The command used to start the ZooKeeper servers passed the configuration as comm ### Configuring Logging One of the files generated by the `zkGenConfig.sh` script controls ZooKeeper's logging. -ZooKeeper uses [Log4j](http://logging.apache.org/log4j/2.x/), and, by default, +ZooKeeper uses [Log4j](https://logging.apache.org/log4j/2.x/), and, by default, it uses a time and size based rolling file appender for its logging configuration. Use the command below to get the logging configuration from one of Pods in the `zk` `StatefulSet`. @@ -506,7 +512,7 @@ kubectl exec zk-0 cat /usr/etc/zookeeper/log4j.properties The logging configuration below will cause the ZooKeeper process to write all of its logs to the standard output file stream. -```shell +``` zookeeper.root.logger=CONSOLE zookeeper.console.threshold=INFO log4j.rootLogger=${zookeeper.root.logger} @@ -516,7 +522,10 @@ log4j.appender.CONSOLE.layout=org.apache.log4j.PatternLayout log4j.appender.CONSOLE.layout.ConversionPattern=%d{ISO8601} [myid:%X{myid}] - %-5p [%t:%C{1}@%L] - %m%n ``` -This is the simplest possible way to safely log inside the container. Because the applications write logs to standard out, Kubernetes will handle log rotation for you. Kubernetes also implements a sane retention policy that ensures application logs written to standard out and standard error do not exhaust local storage media. +This is the simplest possible way to safely log inside the container. +Because the applications write logs to standard out, Kubernetes will handle log rotation for you. +Kubernetes also implements a sane retention policy that ensures application logs written to +standard out and standard error do not exhaust local storage media. Use [`kubectl logs`](/docs/reference/generated/kubectl/kubectl-commands/#logs) to retrieve the last 20 log lines from one of the Pods. @@ -526,7 +535,7 @@ kubectl logs zk-0 --tail 20 You can view application logs written to standard out or standard error using `kubectl logs` and from the Kubernetes Dashboard. -```shell +``` 2016-12-06 19:34:16,236 [myid:1] - INFO [NIOServerCxn.Factory:0.0.0.0/0.0.0.0:2181:NIOServerCnxn@827] - Processing ruok command from /127.0.0.1:52740 2016-12-06 19:34:16,237 [myid:1] - INFO [Thread-1136:NIOServerCnxn@1008] - Closed socket connection for client /127.0.0.1:52740 (no session established for client) 2016-12-06 19:34:26,155 [myid:1] - INFO [NIOServerCxn.Factory:0.0.0.0/0.0.0.0:2181:NIOServerCnxnFactory@192] - Accepted socket connection from /127.0.0.1:52749 @@ -583,7 +592,7 @@ kubectl exec zk-0 -- ps -elf As the `runAsUser` field of the `securityContext` object is set to 1000, instead of running as root, the ZooKeeper process runs as the zookeeper user. -```shell +``` F S UID PID PPID C PRI NI ADDR SZ WCHAN STIME TTY TIME CMD 4 S zookeep+ 1 0 0 80 0 - 1127 - 20:46 ? 00:00:00 sh -c zkGenConfig.sh && zkServer.sh start-foreground 0 S zookeep+ 27 1 0 80 0 - 1155556 - 20:46 ? 00:00:19 /usr/lib/jvm/java-8-openjdk-amd64/bin/java -Dzookeeper.log.dir=/var/log/zookeeper -Dzookeeper.root.logger=INFO,CONSOLE -cp /usr/bin/../build/classes:/usr/bin/../build/lib/*.jar:/usr/bin/../share/zookeeper/zookeeper-3.4.9.jar:/usr/bin/../share/zookeeper/slf4j-log4j12-1.6.1.jar:/usr/bin/../share/zookeeper/slf4j-api-1.6.1.jar:/usr/bin/../share/zookeeper/netty-3.10.5.Final.jar:/usr/bin/../share/zookeeper/log4j-1.2.16.jar:/usr/bin/../share/zookeeper/jline-0.9.94.jar:/usr/bin/../src/java/lib/*.jar:/usr/bin/../etc/zookeeper: -Xmx2G -Xms2G -Dcom.sun.management.jmxremote -Dcom.sun.management.jmxremote.local.only=false org.apache.zookeeper.server.quorum.QuorumPeerMain /usr/bin/../etc/zookeeper/zoo.cfg @@ -599,7 +608,7 @@ kubectl exec -ti zk-0 -- ls -ld /var/lib/zookeeper/data Because the `fsGroup` field of the `securityContext` object is set to 1000, the ownership of the Pods' PersistentVolumes is set to the zookeeper group, and the ZooKeeper process is able to read and write its data. -```shell +``` drwxr-sr-x 3 zookeeper zookeeper 4096 Dec 5 20:45 /var/lib/zookeeper/data ``` @@ -621,7 +630,8 @@ You can use `kubectl patch` to update the number of `cpus` allocated to the serv ```shell kubectl patch sts zk --type='json' -p='[{"op": "replace", "path": "/spec/template/spec/containers/0/resources/requests/cpu", "value":"0.3"}]' - +``` +``` statefulset.apps/zk patched ``` @@ -629,7 +639,8 @@ Use `kubectl rollout status` to watch the status of the update. ```shell kubectl rollout status sts/zk - +``` +``` waiting for statefulset rolling update to complete 0 pods at revision zk-5db4499664... Waiting for 1 pods to be ready... Waiting for 1 pods to be ready... @@ -648,7 +659,9 @@ Use the `kubectl rollout history` command to view a history or previous configur ```shell kubectl rollout history sts/zk +``` +``` statefulsets "zk" REVISION 1 @@ -659,13 +672,15 @@ Use the `kubectl rollout undo` command to roll back the modification. ```shell kubectl rollout undo sts/zk +``` +``` statefulset.apps/zk rolled back ``` ### Handling Process Failure -[Restart Policies](/docs/user-guide/pod-states/#restartpolicy) control how +[Restart Policies](/docs/concepts/workloads/pods/pod-lifecycle/#restart-policy) control how Kubernetes handles process failures for the entry point of the container in a Pod. For Pods in a `StatefulSet`, the only appropriate `RestartPolicy` is Always, and this is the default value. For stateful applications you should **never** override @@ -680,7 +695,7 @@ kubectl exec zk-0 -- ps -ef The command used as the container's entry point has PID 1, and the ZooKeeper process, a child of the entry point, has PID 27. -```shell +``` UID PID PPID C STIME TTY TIME CMD zookeep+ 1 0 0 15:03 ? 00:00:00 sh -c zkGenConfig.sh && zkServer.sh start-foreground zookeep+ 27 1 0 15:03 ? 00:00:03 /usr/lib/jvm/java-8-openjdk-amd64/bin/java -Dzookeeper.log.dir=/var/log/zookeeper -Dzookeeper.root.logger=INFO,CONSOLE -cp /usr/bin/../build/classes:/usr/bin/../build/lib/*.jar:/usr/bin/../share/zookeeper/zookeeper-3.4.9.jar:/usr/bin/../share/zookeeper/slf4j-log4j12-1.6.1.jar:/usr/bin/../share/zookeeper/slf4j-api-1.6.1.jar:/usr/bin/../share/zookeeper/netty-3.10.5.Final.jar:/usr/bin/../share/zookeeper/log4j-1.2.16.jar:/usr/bin/../share/zookeeper/jline-0.9.94.jar:/usr/bin/../src/java/lib/*.jar:/usr/bin/../etc/zookeeper: -Xmx2G -Xms2G -Dcom.sun.management.jmxremote -Dcom.sun.management.jmxremote.local.only=false org.apache.zookeeper.server.quorum.QuorumPeerMain /usr/bin/../etc/zookeeper/zoo.cfg @@ -700,7 +715,7 @@ kubectl exec zk-0 -- pkill java The termination of the ZooKeeper process caused its parent process to terminate. Because the `RestartPolicy` of the container is Always, it restarted the parent process. -```shell +``` NAME READY STATUS RESTARTS AGE zk-0 1/1 Running 0 21m zk-1 1/1 Running 0 20m @@ -740,7 +755,7 @@ The Pod `template` for the `zk` `StatefulSet` specifies a liveness probe. The probe calls a bash script that uses the ZooKeeper `ruok` four letter word to test the server's health. -```bash +``` OK=$(echo ruok | nc 127.0.0.1 $1) if [ "$OK" == "imok" ]; then exit 0 @@ -767,7 +782,9 @@ the ensemble are restarted. ```shell kubectl get pod -w -l app=zk +``` +``` NAME READY STATUS RESTARTS AGE zk-0 1/1 Running 0 1h zk-1 1/1 Running 0 1h @@ -816,7 +833,9 @@ domains to ensure availability. To avoid an outage, due to the loss of an individual machine, best practices preclude co-locating multiple instances of the application on the same machine. -By default, Kubernetes may co-locate Pods in a `StatefulSet` on the same node. For the three server ensemble you created, if two servers are on the same node, and that node fails, the clients of your ZooKeeper service will experience an outage until at least one of the Pods can be rescheduled. +By default, Kubernetes may co-locate Pods in a `StatefulSet` on the same node. +For the three server ensemble you created, if two servers are on the same node, and that node fails, +the clients of your ZooKeeper service will experience an outage until at least one of the Pods can be rescheduled. You should always provision additional capacity to allow the processes of critical systems to be rescheduled in the event of node failures. If you do so, then the @@ -832,7 +851,7 @@ for i in 0 1 2; do kubectl get pod zk-$i --template {{.spec.nodeName}}; echo ""; All of the Pods in the `zk` `StatefulSet` are deployed on different nodes. -```shell +``` kubernetes-node-cxpk kubernetes-node-a5aq kubernetes-node-2g2d @@ -854,7 +873,7 @@ This is because the Pods in the `zk` `StatefulSet` have a `PodAntiAffinity` spec ``` The `requiredDuringSchedulingIgnoredDuringExecution` field tells the -Kubernetes Scheduler that it should never co-locate two Pods which have `app` label +Kubernetes Scheduler that it should never co-locate two Pods which have `app` label as `zk` in the domain defined by the `topologyKey`. The `topologyKey` `kubernetes.io/hostname` indicates that the domain is an individual node. Using different rules, labels, and selectors, you can extend this technique to spread @@ -891,7 +910,7 @@ kubectl get pdb zk-pdb The `max-unavailable` field indicates to Kubernetes that at most one Pod from `zk` `StatefulSet` can be unavailable at any time. -```shell +``` NAME MIN-AVAILABLE MAX-UNAVAILABLE ALLOWED-DISRUPTIONS AGE zk-pdb N/A 1 1 ``` @@ -906,7 +925,9 @@ In another terminal, use this command to get the nodes that the Pods are current ```shell for i in 0 1 2; do kubectl get pod zk-$i --template {{.spec.nodeName}}; echo ""; done +``` +``` kubernetes-node-pb41 kubernetes-node-ixsl kubernetes-node-i4c4 @@ -917,6 +938,9 @@ drain the node on which the `zk-0` Pod is scheduled. ```shell kubectl drain $(kubectl get pod zk-0 --template {{.spec.nodeName}}) --ignore-daemonsets --force --delete-local-data +``` + +``` node "kubernetes-node-pb41" cordoned WARNING: Deleting pods not managed by ReplicationController, ReplicaSet, Job, or DaemonSet: fluentd-cloud-logging-kubernetes-node-pb41, kube-proxy-kubernetes-node-pb41; Ignoring DaemonSet-managed pods: node-problem-detector-v0.1-o5elz @@ -927,7 +951,7 @@ node "kubernetes-node-pb41" drained As there are four nodes in your cluster, `kubectl drain`, succeeds and the `zk-0` is rescheduled to another node. -```shell +``` NAME READY STATUS RESTARTS AGE zk-0 1/1 Running 2 1h zk-1 1/1 Running 0 1h @@ -949,17 +973,22 @@ Keep watching the `StatefulSet`'s Pods in the first terminal and drain the node ```shell kubectl drain $(kubectl get pod zk-1 --template {{.spec.nodeName}}) --ignore-daemonsets --force --delete-local-data "kubernetes-node-ixsl" cordoned +``` +``` WARNING: Deleting pods not managed by ReplicationController, ReplicaSet, Job, or DaemonSet: fluentd-cloud-logging-kubernetes-node-ixsl, kube-proxy-kubernetes-node-ixsl; Ignoring DaemonSet-managed pods: node-problem-detector-v0.1-voc74 pod "zk-1" deleted node "kubernetes-node-ixsl" drained ``` -The `zk-1` Pod cannot be scheduled because the `zk` `StatefulSet` contains a `PodAntiAffinity` rule preventing co-location of the Pods, and as only two nodes are schedulable, the Pod will remain in a Pending state. +The `zk-1` Pod cannot be scheduled because the `zk` `StatefulSet` contains a `PodAntiAffinity` rule preventing +co-location of the Pods, and as only two nodes are schedulable, the Pod will remain in a Pending state. ```shell kubectl get pods -w -l app=zk +``` +``` NAME READY STATUS RESTARTS AGE zk-0 1/1 Running 2 1h zk-1 1/1 Running 0 1h @@ -987,6 +1016,8 @@ Continue to watch the Pods of the stateful set, and drain the node on which ```shell kubectl drain $(kubectl get pod zk-2 --template {{.spec.nodeName}}) --ignore-daemonsets --force --delete-local-data +``` +``` node "kubernetes-node-i4c4" cordoned WARNING: Deleting pods not managed by ReplicationController, ReplicaSet, Job, or DaemonSet: fluentd-cloud-logging-kubernetes-node-i4c4, kube-proxy-kubernetes-node-i4c4; Ignoring DaemonSet-managed pods: node-problem-detector-v0.1-dyrog @@ -1007,7 +1038,7 @@ kubectl exec zk-0 zkCli.sh get /hello The service is still available because its `PodDisruptionBudget` is respected. -```shell +``` WatchedEvent state:SyncConnected type:None path:null world cZxid = 0x200000002 @@ -1027,7 +1058,8 @@ Use [`kubectl uncordon`](/docs/reference/generated/kubectl/kubectl-commands/#unc ```shell kubectl uncordon kubernetes-node-pb41 - +``` +``` node "kubernetes-node-pb41" uncordoned ``` @@ -1035,7 +1067,8 @@ node "kubernetes-node-pb41" uncordoned ```shell kubectl get pods -w -l app=zk - +``` +``` NAME READY STATUS RESTARTS AGE zk-0 1/1 Running 2 1h zk-1 1/1 Running 0 1h @@ -1090,9 +1123,10 @@ kubectl uncordon kubernetes-node-ixsl node "kubernetes-node-ixsl" uncordoned ``` -You can use `kubectl drain` in conjunction with `PodDisruptionBudgets` to ensure that your services remain available during maintenance. If drain is used to cordon nodes and evict pods prior to taking the node offline for maintenance, services that express a disruption budget will have that budget respected. You should always allocate additional capacity for critical services so that their Pods can be immediately rescheduled. - - +You can use `kubectl drain` in conjunction with `PodDisruptionBudgets` to ensure that your services remain available during maintenance. +If drain is used to cordon nodes and evict pods prior to taking the node offline for maintenance, +services that express a disruption budget will have that budget respected. +You should always allocate additional capacity for critical services so that their Pods can be immediately rescheduled. ## {{% heading "cleanup" %}} @@ -1102,6 +1136,3 @@ You can use `kubectl drain` in conjunction with `PodDisruptionBudgets` to ensure used in this tutorial. Follow the necessary steps, based on your environment, storage configuration, and provisioning method, to ensure that all storage is reclaimed. - - - diff --git a/content/en/docs/tutorials/stateless-application/expose-external-ip-address.md b/content/en/docs/tutorials/stateless-application/expose-external-ip-address.md index 2974c77c94..5babc2c0b0 100644 --- a/content/en/docs/tutorials/stateless-application/expose-external-ip-address.md +++ b/content/en/docs/tutorials/stateless-application/expose-external-ip-address.md @@ -52,11 +52,11 @@ kubectl apply -f https://k8s.io/examples/service/load-balancer-example.yaml The preceding command creates a - [Deployment](/docs/concepts/workloads/controllers/deployment/) - object and an associated - [ReplicaSet](/docs/concepts/workloads/controllers/replicaset/) - object. The ReplicaSet has five - [Pods](/docs/concepts/workloads/pods/pod/), + {{< glossary_tooltip text="Deployment" term_id="deployment" >}} + and an associated + {{< glossary_tooltip term_id="replica-set" text="ReplicaSet" >}}. + The ReplicaSet has five + {{< glossary_tooltip text="Pods" term_id="pod" >}} each of which runs the Hello World application. 1. Display information about the Deployment: diff --git a/content/en/docs/tutorials/stateless-application/guestbook.md b/content/en/docs/tutorials/stateless-application/guestbook.md index f321d5391a..2b6eef90fa 100644 --- a/content/en/docs/tutorials/stateless-application/guestbook.md +++ b/content/en/docs/tutorials/stateless-application/guestbook.md @@ -365,7 +365,7 @@ Deleting the Deployments and Services also deletes any running Pods. Use labels ## {{% heading "whatsnext" %}} -* Add [ELK logging and monitoring](../guestbook-logs-metrics-with-elk/) to your Guestbook application +* Add [ELK logging and monitoring](/docs/tutorials/stateless-application/guestbook-logs-metrics-with-elk/) to your Guestbook application * Complete the [Kubernetes Basics](/docs/tutorials/kubernetes-basics/) Interactive Tutorials * Use Kubernetes to create a blog using [Persistent Volumes for MySQL and Wordpress](/docs/tutorials/stateful-application/mysql-wordpress-persistent-volume/#visit-your-new-wordpress-blog) * Read more about [connecting applications](/docs/concepts/services-networking/connect-applications-service/) diff --git a/content/en/examples/README.md b/content/en/examples/README.md index 3804697b6f..6a5f3ceea7 100644 --- a/content/en/examples/README.md +++ b/content/en/examples/README.md @@ -1,13 +1,12 @@ -Note: These tests are importing code from kubernetes that isn't really -meant to be used outside the repo. This causes vendoring problems. As -a result, we have to work around those with these lines in the travis -config: +To run the tests for a localization, use the following command: ``` -- rm $GOPATH/src/k8s.io/kubernetes/vendor/k8s.io/apimachinery -- rm $GOPATH/src/k8s.io/kubernetes/vendor/k8s.io/apiserver -- rm $GOPATH/src/k8s.io/kubernetes/vendor/k8s.io/client-go -- cp -r $GOPATH/src/k8s.io/kubernetes/vendor/* $GOPATH/src/ -- rm -rf $GOPATH/src/k8s.io/kubernetes/vendor/* -- cp -r $GOPATH/src/k8s.io/kubernetes/staging/src/* $GOPATH/src/ +go test k8s.io/website/content/<lang>/examples ``` + +where `<lang>` is the two character representation of a language. For example: + +``` +go test k8s.io/website/content/en/examples +``` + diff --git a/content/en/examples/admin/sched/clusterrole.yaml b/content/en/examples/admin/sched/clusterrole.yaml new file mode 100644 index 0000000000..554b8659db --- /dev/null +++ b/content/en/examples/admin/sched/clusterrole.yaml @@ -0,0 +1,37 @@ +apiVersion: rbac.authorization.k8s.io/v1 +kind: ClusterRole +metadata: + annotations: + rbac.authorization.kubernetes.io/autoupdate: "true" + labels: + kubernetes.io/bootstrapping: rbac-defaults + name: system:kube-scheduler +rules: + - apiGroups: + - coordination.k8s.io + resources: + - leases + verbs: + - create + - apiGroups: + - coordination.k8s.io + resourceNames: + - kube-scheduler + - my-scheduler + resources: + - leases + verbs: + - get + - update + - apiGroups: + - "" + resourceNames: + - kube-scheduler + - my-scheduler + resources: + - endpoints + verbs: + - delete + - get + - patch + - update diff --git a/content/en/examples/application/php-apache.yaml b/content/en/examples/application/php-apache.yaml index 5eb04cfb89..e8e1b5aeb4 100644 --- a/content/en/examples/application/php-apache.yaml +++ b/content/en/examples/application/php-apache.yaml @@ -22,9 +22,7 @@ spec: cpu: 500m requests: cpu: 200m - --- - apiVersion: v1 kind: Service metadata: @@ -36,4 +34,3 @@ spec: - port: 80 selector: run: php-apache - diff --git a/content/en/examples/examples_test.go b/content/en/examples/examples_test.go index 7c9664b64c..d653d8303e 100644 --- a/content/en/examples/examples_test.go +++ b/content/en/examples/examples_test.go @@ -28,34 +28,104 @@ import ( "testing" "k8s.io/apimachinery/pkg/runtime" + "k8s.io/apimachinery/pkg/runtime/schema" "k8s.io/apimachinery/pkg/types" "k8s.io/apimachinery/pkg/util/validation/field" "k8s.io/apimachinery/pkg/util/yaml" - utilfeature "k8s.io/apiserver/pkg/util/feature" + // "k8s.io/apiserver/pkg/util/feature" "k8s.io/kubernetes/pkg/api/legacyscheme" - "k8s.io/kubernetes/pkg/api/testapi" + "k8s.io/kubernetes/pkg/apis/apps" apps_validation "k8s.io/kubernetes/pkg/apis/apps/validation" + "k8s.io/kubernetes/pkg/apis/autoscaling" autoscaling_validation "k8s.io/kubernetes/pkg/apis/autoscaling/validation" + "k8s.io/kubernetes/pkg/apis/batch" batch_validation "k8s.io/kubernetes/pkg/apis/batch/validation" + api "k8s.io/kubernetes/pkg/apis/core" "k8s.io/kubernetes/pkg/apis/core/validation" - "k8s.io/kubernetes/pkg/apis/extensions" - ext_validation "k8s.io/kubernetes/pkg/apis/extensions/validation" + + "k8s.io/kubernetes/pkg/apis/networking" + networking_validation "k8s.io/kubernetes/pkg/apis/networking/validation" + "k8s.io/kubernetes/pkg/apis/policy" policy_validation "k8s.io/kubernetes/pkg/apis/policy/validation" + "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" + "k8s.io/kubernetes/pkg/capabilities" "k8s.io/kubernetes/pkg/registry/batch/job" + + // initialize install packages + _ "k8s.io/kubernetes/pkg/apis/apps/install" + _ "k8s.io/kubernetes/pkg/apis/autoscaling/install" + _ "k8s.io/kubernetes/pkg/apis/batch/install" + _ "k8s.io/kubernetes/pkg/apis/core/install" + _ "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" ) +var ( + Groups map[string]TestGroup + serializer runtime.SerializerInfo +) + +// TestGroup contains GroupVersion to uniquely identify the API +type TestGroup struct { + externalGroupVersion schema.GroupVersion +} + +// GroupVersion makes copy of schema.GroupVersion +func (g TestGroup) GroupVersion() *schema.GroupVersion { + copyOfGroupVersion := g.externalGroupVersion + return ©OfGroupVersion +} + +// Codec returns the codec for the API version to test against +func (g TestGroup) Codec() runtime.Codec { + if serializer.Serializer == nil { + return legacyscheme.Codecs.LegacyCodec(g.externalGroupVersion) + } + return legacyscheme.Codecs.CodecForVersions(serializer.Serializer, legacyscheme.Codecs.UniversalDeserializer(), schema.GroupVersions{g.externalGroupVersion}, nil) +} + +func initGroups() { + Groups = make(map[string]TestGroup) + groupNames := []string{ + api.GroupName, + apps.GroupName, + autoscaling.GroupName, + batch.GroupName, + networking.GroupName, + policy.GroupName, + rbac.GroupName, + settings.GroupName, + storage.GroupName, + } + + for _, gn := range groupNames { + versions := legacyscheme.Scheme.PrioritizedVersionsForGroup(gn) + Groups[gn] = TestGroup{ + externalGroupVersion: schema.GroupVersion{ + Group: gn, + Version: versions[0].Version, + }, + } + } +} + func getCodecForObject(obj runtime.Object) (runtime.Codec, error) { kinds, _, err := legacyscheme.Scheme.ObjectKinds(obj) if err != nil { @@ -63,7 +133,7 @@ func getCodecForObject(obj runtime.Object) (runtime.Codec, error) { } kind := kinds[0] - for _, group := range testapi.Groups { + for _, group := range Groups { if group.GroupVersion().Group != kind.Group { continue } @@ -85,7 +155,7 @@ func getCodecForObject(obj runtime.Object) (runtime.Codec, error) { func validateObject(obj runtime.Object) (errors field.ErrorList) { // Enable CustomPodDNS for testing - utilfeature.DefaultFeatureGate.Set("CustomPodDNS=true") + // feature.DefaultFeatureGate.Set("CustomPodDNS=true") switch t := obj.(type) { case *api.ConfigMap: if t.Namespace == "" { @@ -96,7 +166,7 @@ func validateObject(obj runtime.Object) (errors field.ErrorList) { if t.Namespace == "" { t.Namespace = api.NamespaceDefault } - errors = validation.ValidateEndpoints(t) + errors = validation.ValidateEndpointsCreate(t) case *api.LimitRange: if t.Namespace == "" { t.Namespace = api.NamespaceDefault @@ -115,7 +185,10 @@ func validateObject(obj runtime.Object) (errors field.ErrorList) { if t.Namespace == "" { t.Namespace = api.NamespaceDefault } - errors = validation.ValidatePod(t) + opts := validation.PodValidationOptions{ + AllowMultipleHugePageResources: true, + } + errors = validation.ValidatePod(t, opts) case *api.PodList: for i := range t.Items { errors = append(errors, validateObject(&t.Items[i])...) @@ -148,7 +221,7 @@ func validateObject(obj runtime.Object) (errors field.ErrorList) { if t.Namespace == "" { t.Namespace = api.NamespaceDefault } - errors = validation.ValidateService(t) + errors = validation.ValidateService(t, true) case *api.ServiceAccount: if t.Namespace == "" { t.Namespace = api.NamespaceDefault @@ -189,11 +262,15 @@ func validateObject(obj runtime.Object) (errors field.ErrorList) { t.Namespace = api.NamespaceDefault } errors = apps_validation.ValidateDeployment(t) - case *extensions.Ingress: + case *networking.Ingress: if t.Namespace == "" { t.Namespace = api.NamespaceDefault } - errors = ext_validation.ValidateIngress(t) + gv := schema.GroupVersion{ + Group: networking.GroupName, + Version: legacyscheme.Scheme.PrioritizedVersionsForGroup(networking.GroupName)[0].Version, + } + errors = networking_validation.ValidateIngressCreate(t, gv) case *policy.PodSecurityPolicy: errors = policy_validation.ValidatePodSecurityPolicy(t) case *apps.ReplicaSet: @@ -206,6 +283,11 @@ func validateObject(obj runtime.Object) (errors field.ErrorList) { t.Namespace = api.NamespaceDefault } errors = batch_validation.ValidateCronJob(t) + case *networking.NetworkPolicy: + if t.Namespace == "" { + t.Namespace = api.NamespaceDefault + } + errors = networking_validation.ValidateNetworkPolicy(t) case *policy.PodDisruptionBudget: if t.Namespace == "" { t.Namespace = api.NamespaceDefault @@ -247,10 +329,6 @@ func walkConfigFiles(inDir string, t *testing.T, fn func(name, path string, data if err != nil { return err } - // workaround for Jekyllr limit - if bytes.HasPrefix(data, []byte("---\n")) { - return fmt.Errorf("YAML file cannot start with \"---\", please remove the first line") - } name := strings.TrimSuffix(file, ext) var docs [][]byte @@ -286,11 +364,14 @@ func walkConfigFiles(inDir string, t *testing.T, fn func(name, path string, data } func TestExampleObjectSchemas(t *testing.T) { + initGroups() + // Please help maintain the alphabeta order in the map cases := map[string]map[string][]runtime.Object{ "admin": { - "namespace-dev": {&api.Namespace{}}, - "namespace-prod": {&api.Namespace{}}, + "namespace-dev": {&api.Namespace{}}, + "namespace-prod": {&api.Namespace{}}, + "snowflake-deployment": {&apps.Deployment{}}, }, "admin/cloud": { "ccm-example": {&api.ServiceAccount{}, &rbac.ClusterRoleBinding{}, &apps.DaemonSet{}}, @@ -298,6 +379,7 @@ func TestExampleObjectSchemas(t *testing.T) { "admin/dns": { "busybox": {&api.Pod{}}, "dns-horizontal-autoscaler": {&apps.Deployment{}}, + "dnsutils": {&api.Pod{}}, }, "admin/logging": { "fluentd-sidecar-config": {&api.ConfigMap{}}, @@ -343,21 +425,23 @@ func TestExampleObjectSchemas(t *testing.T) { "storagelimits": {&api.LimitRange{}}, }, "admin/sched": { - "my-scheduler": {&api.ServiceAccount{}, &rbac.ClusterRoleBinding{}, &apps.Deployment{}}, + "my-scheduler": {&api.ServiceAccount{}, &rbac.ClusterRoleBinding{}, &rbac.ClusterRoleBinding{}, &apps.Deployment{}}, "pod1": {&api.Pod{}}, "pod2": {&api.Pod{}}, "pod3": {&api.Pod{}}, }, "application": { - "deployment": {&apps.Deployment{}}, - "deployment-patch": {&apps.Deployment{}}, - "deployment-scale": {&apps.Deployment{}}, - "deployment-update": {&apps.Deployment{}}, - "nginx-app": {&api.Service{}, &apps.Deployment{}}, - "nginx-with-request": {&apps.Deployment{}}, - "shell-demo": {&api.Pod{}}, - "simple_deployment": {&apps.Deployment{}}, - "update_deployment": {&apps.Deployment{}}, + "deployment": {&apps.Deployment{}}, + "deployment-patch": {&apps.Deployment{}}, + "deployment-retainkeys": {&apps.Deployment{}}, + "deployment-scale": {&apps.Deployment{}}, + "deployment-update": {&apps.Deployment{}}, + "nginx-app": {&api.Service{}, &apps.Deployment{}}, + "nginx-with-request": {&apps.Deployment{}}, + "php-apache": {&apps.Deployment{}, &api.Service{}}, + "shell-demo": {&api.Pod{}}, + "simple_deployment": {&apps.Deployment{}}, + "update_deployment": {&apps.Deployment{}}, }, "application/cassandra": { "cassandra-service": {&api.Service{}}, @@ -413,15 +497,17 @@ func TestExampleObjectSchemas(t *testing.T) { "configmap-multikeys": {&api.ConfigMap{}}, }, "controllers": { - "daemonset": {&apps.DaemonSet{}}, - "frontend": {&apps.ReplicaSet{}}, - "hpa-rs": {&autoscaling.HorizontalPodAutoscaler{}}, - "job": {&batch.Job{}}, - "replicaset": {&apps.ReplicaSet{}}, - "replication": {&api.ReplicationController{}}, - "replication-nginx-1.7.9": {&api.ReplicationController{}}, - "replication-nginx-1.9.2": {&api.ReplicationController{}}, - "nginx-deployment": {&apps.Deployment{}}, + "daemonset": {&apps.DaemonSet{}}, + "fluentd-daemonset": {&apps.DaemonSet{}}, + "fluentd-daemonset-update": {&apps.DaemonSet{}}, + "frontend": {&apps.ReplicaSet{}}, + "hpa-rs": {&autoscaling.HorizontalPodAutoscaler{}}, + "job": {&batch.Job{}}, + "replicaset": {&apps.ReplicaSet{}}, + "replication": {&api.ReplicationController{}}, + "replication-nginx-1.14.2": {&api.ReplicationController{}}, + "replication-nginx-1.16.1": {&api.ReplicationController{}}, + "nginx-deployment": {&apps.Deployment{}}, }, "debug": { "counter-pod": {&api.Pod{}}, @@ -455,6 +541,8 @@ func TestExampleObjectSchemas(t *testing.T) { "pod-configmap-volume": {&api.Pod{}}, "pod-configmap-volume-specific-key": {&api.Pod{}}, "pod-multiple-configmap-env-variable": {&api.Pod{}}, + "pod-nginx-preferred-affinity": {&api.Pod{}}, + "pod-nginx-required-affinity": {&api.Pod{}}, "pod-nginx-specific-node": {&api.Pod{}}, "pod-nginx": {&api.Pod{}}, "pod-projected-svc-token": {&api.Pod{}}, @@ -462,6 +550,7 @@ func TestExampleObjectSchemas(t *testing.T) { "pod-single-configmap-env-variable": {&api.Pod{}}, "pod-with-node-affinity": {&api.Pod{}}, "pod-with-pod-affinity": {&api.Pod{}}, + "pod-with-toleration": {&api.Pod{}}, "private-reg-pod": {&api.Pod{}}, "share-process-namespace": {&api.Pod{}}, "simple-pod": {&api.Pod{}}, @@ -471,14 +560,17 @@ func TestExampleObjectSchemas(t *testing.T) { "redis-pod": {&api.Pod{}}, }, "pods/inject": { - "dapi-envars-container": {&api.Pod{}}, - "dapi-envars-pod": {&api.Pod{}}, - "dapi-volume": {&api.Pod{}}, - "dapi-volume-resources": {&api.Pod{}}, - "envars": {&api.Pod{}}, - "secret": {&api.Secret{}}, - "secret-envars-pod": {&api.Pod{}}, - "secret-pod": {&api.Pod{}}, + "dapi-envars-container": {&api.Pod{}}, + "dapi-envars-pod": {&api.Pod{}}, + "dapi-volume": {&api.Pod{}}, + "dapi-volume-resources": {&api.Pod{}}, + "envars": {&api.Pod{}}, + "pod-multiple-secret-env-variable": {&api.Pod{}}, + "pod-secret-envFrom": {&api.Pod{}}, + "pod-single-secret-env-variable": {&api.Pod{}}, + "secret": {&api.Secret{}}, + "secret-envars-pod": {&api.Pod{}}, + "secret-pod": {&api.Pod{}}, }, "pods/probe": { "exec-liveness": {&api.Pod{}}, @@ -517,38 +609,53 @@ func TestExampleObjectSchemas(t *testing.T) { "redis": {&api.Pod{}}, }, "policy": { + "baseline-psp": {&policy.PodSecurityPolicy{}}, + "example-psp": {&policy.PodSecurityPolicy{}}, "privileged-psp": {&policy.PodSecurityPolicy{}}, "restricted-psp": {&policy.PodSecurityPolicy{}}, - "example-psp": {&policy.PodSecurityPolicy{}}, "zookeeper-pod-disruption-budget-maxunavailable": {&policy.PodDisruptionBudget{}}, - "zookeeper-pod-disruption-budget-minunavailable": {&policy.PodDisruptionBudget{}}, + "zookeeper-pod-disruption-budget-minavailable": {&policy.PodDisruptionBudget{}}, }, "service": { - "nginx-service": {&api.Service{}}, + "nginx-service": {&api.Service{}}, + "load-balancer-example": {&apps.Deployment{}}, }, "service/access": { - "frontend": {&api.Service{}, &apps.Deployment{}}, - "hello-service": {&api.Service{}}, - "hello": {&apps.Deployment{}}, + "frontend": {&api.Service{}, &apps.Deployment{}}, + "hello-application": {&apps.Deployment{}}, + "hello-service": {&api.Service{}}, + "hello": {&apps.Deployment{}}, }, "service/networking": { - "curlpod": {&apps.Deployment{}}, - "custom-dns": {&api.Pod{}}, - "hostaliases-pod": {&api.Pod{}}, - "ingress": {&extensions.Ingress{}}, - "nginx-secure-app": {&api.Service{}, &apps.Deployment{}}, - "nginx-svc": {&api.Service{}}, - "run-my-nginx": {&apps.Deployment{}}, + "curlpod": {&apps.Deployment{}}, + "custom-dns": {&api.Pod{}}, + "dual-stack-default-svc": {&api.Service{}}, + "dual-stack-ipv4-svc": {&api.Service{}}, + "dual-stack-ipv6-lb-svc": {&api.Service{}}, + "dual-stack-ipv6-svc": {&api.Service{}}, + "hostaliases-pod": {&api.Pod{}}, + "ingress": {&networking.Ingress{}}, + "network-policy-allow-all-egress": {&networking.NetworkPolicy{}}, + "network-policy-allow-all-ingress": {&networking.NetworkPolicy{}}, + "network-policy-default-deny-egress": {&networking.NetworkPolicy{}}, + "network-policy-default-deny-ingress": {&networking.NetworkPolicy{}}, + "network-policy-default-deny-all": {&networking.NetworkPolicy{}}, + "nginx-policy": {&networking.NetworkPolicy{}}, + "nginx-secure-app": {&api.Service{}, &apps.Deployment{}}, + "nginx-svc": {&api.Service{}}, + "run-my-nginx": {&apps.Deployment{}}, }, "windows": { - "configmap-pod": {&api.ConfigMap{}, &api.Pod{}}, - "daemonset": {&apps.DaemonSet{}}, - "deploy-hyperv": {&apps.Deployment{}}, - "deploy-resource": {&apps.Deployment{}}, - "emptydir-pod": {&api.Pod{}}, - "hostpath-volume-pod": {&api.Pod{}}, - "secret-pod": {&api.Secret{}, &api.Pod{}}, - "simple-pod": {&api.Pod{}}, + "configmap-pod": {&api.ConfigMap{}, &api.Pod{}}, + "daemonset": {&apps.DaemonSet{}}, + "deploy-hyperv": {&apps.Deployment{}}, + "deploy-resource": {&apps.Deployment{}}, + "emptydir-pod": {&api.Pod{}}, + "hostpath-volume-pod": {&api.Pod{}}, + "run-as-username-container": {&api.Pod{}}, + "run-as-username-pod": {&api.Pod{}}, + "secret-pod": {&api.Secret{}, &api.Pod{}}, + "simple-pod": {&api.Pod{}}, }, } diff --git a/content/en/examples/pods/inject/dependent-envars.yaml b/content/en/examples/pods/inject/dependent-envars.yaml new file mode 100644 index 0000000000..2509c6f47b --- /dev/null +++ b/content/en/examples/pods/inject/dependent-envars.yaml @@ -0,0 +1,26 @@ +apiVersion: v1 +kind: Pod +metadata: + name: dependent-envars-demo +spec: + containers: + - name: dependent-envars-demo + args: + - while true; do echo -en '\n'; printf UNCHANGED_REFERENCE=$UNCHANGED_REFERENCE'\n'; printf SERVICE_ADDRESS=$SERVICE_ADDRESS'\n';printf ESCAPED_REFERENCE=$ESCAPED_REFERENCE'\n'; sleep 30; done; + command: + - sh + - -c + image: busybox + env: + - name: SERVICE_PORT + value: "80" + - name: SERVICE_IP + value: "172.17.0.1" + - name: UNCHANGED_REFERENCE + value: "$(PROTOCOL)://$(SERVICE_IP):$(SERVICE_PORT)" + - name: PROTOCOL + value: "https" + - name: SERVICE_ADDRESS + value: "$(PROTOCOL)://$(SERVICE_IP):$(SERVICE_PORT)" + - name: ESCAPED_REFERENCE + value: "$$(PROTOCOL)://$(SERVICE_IP):$(SERVICE_PORT)" diff --git a/content/en/examples/priority-and-fairness/health-for-strangers.yaml b/content/en/examples/priority-and-fairness/health-for-strangers.yaml new file mode 100644 index 0000000000..79ee80ab17 --- /dev/null +++ b/content/en/examples/priority-and-fairness/health-for-strangers.yaml @@ -0,0 +1,20 @@ +apiVersion: flowcontrol.apiserver.k8s.io/v1alpha1 +kind: FlowSchema +metadata: + name: health-for-strangers +spec: + matchingPrecedence: 1000 + priorityLevelConfiguration: + name: exempt + rules: + - nonResourceRules: + - nonResourceURLs: + - "/healthz" + - "/livez" + - "/readyz" + verbs: + - "*" + subjects: + - kind: Group + group: + name: system:unauthenticated diff --git a/content/en/includes/partner-script.js b/content/en/includes/partner-script.js deleted file mode 100644 index cdf69bcb29..0000000000 --- a/content/en/includes/partner-script.js +++ /dev/null @@ -1,1609 +0,0 @@ -;(function () { - var partners = [ - { - type: 0, - name: 'Sysdig', - logo: 'sys_dig', - link: 'https://sysdig.com/blog/monitoring-kubernetes-with-sysdig-cloud/', - blurb: 'Sysdig is the container intelligence company. Sysdig has created the only unified platform to deliver monitoring, security, and troubleshooting in a microservices-friendly architecture.' - }, - { - type: 0, - name: 'Puppet', - logo: 'puppet', - link: 'https://puppet.com/blog/announcing-kream-and-new-kubernetes-helm-and-docker-modules', - blurb: 'We\'ve developed tools and products to make your adoption of Kubernetes as efficient as possible, covering your full workflow cycle from development to production. And now Puppet Pipelines for Containers is your complete DevOps dashboard for Kubernetes.' - }, - { - type: 0, - name: 'Citrix', - logo: 'citrix', - link: 'https://www.citrix.com/networking/microservices.html', - blurb: 'Netscaler CPX gives app developers all the features they need to load balance their microservices and containerized apps with Kubernetes.' - }, - { - type: 0, - name: 'Cockroach Labs', - logo: 'cockroach_labs', - link: 'https://www.cockroachlabs.com/blog/running-cockroachdb-on-kubernetes/', - blurb: 'CockroachDB is a distributed SQL database whose built-in replication and survivability model pair with Kubernetes to truly make data easy.' - }, - { - type: 2, - name: 'Weaveworks', - logo: 'weave_works', - link: ' https://weave.works/kubernetes', - blurb: 'Weaveworks enables Developers and Dev/Ops teams to easily connect, deploy, secure, manage, and troubleshoot microservices in Kubernetes.' - }, - { - type: 0, - name: 'Intel', - logo: 'intel', - link: 'https://tectonic.com/press/intel-coreos-collaborate-on-openstack-with-kubernetes.html', - blurb: 'Powering the GIFEE (Google’s Infrastructure for Everyone Else), to run OpenStack deployments on Kubernetes.' - }, - { - type: 3, - name: 'Platform9', - logo: 'platform9', - link: 'https://platform9.com/products/kubernetes/', - blurb: 'Platform9 is the open source-as-a-service company that takes all of the goodness of Kubernetes and delivers it as a managed service.' - }, - { - type: 0, - name: 'Datadog', - logo: 'datadog', - link: 'http://docs.datadoghq.com/integrations/kubernetes/', - blurb: 'Full-stack observability for dynamic infrastructure & applications. Includes precision alerting, analytics and deep Kubernetes integrations. ' - }, - { - type: 0, - name: 'AppFormix', - logo: 'appformix', - link: 'http://www.appformix.com/solutions/appformix-for-kubernetes/', - blurb: 'AppFormix is a cloud infrastructure performance optimization service helping enterprise operators streamline their cloud operations on any Kubernetes cloud. ' - }, - { - type: 0, - name: 'Crunchy', - logo: 'crunchy', - link: 'http://info.crunchydata.com/blog/advanced-crunchy-containers-for-postgresql', - blurb: 'Crunchy PostgreSQL Container Suite is a set of containers for managing PostgreSQL with DBA microservices leveraging Kubernetes and Helm.' - }, - { - type: 0, - name: 'Aqua', - logo: 'aqua', - link: 'http://blog.aquasec.com/security-best-practices-for-kubernetes-deployment', - blurb: 'Deep, automated security for your containers running on Kubernetes.' - }, - { - type: 0, - name: 'Distelli', - logo: 'distelli', - link: 'https://www.distelli.com/', - blurb: 'Pipelines from your source repositories to your Kubernetes Clusters on any cloud.' - }, - { - type: 0, - name: 'Nuage networks', - logo: 'nuagenetworks', - link: 'https://github.com/nuagenetworks/nuage-kubernetes', - blurb: 'The Nuage SDN platform provides policy-based networking between Kubernetes Pods and non-Kubernetes environments with visibility and security monitoring.' - }, - { - type: 0, - name: 'Sematext', - logo: 'sematext', - link: 'https://sematext.com/kubernetes/', - blurb: 'Logging & Monitoring: Automatic collection and processing of Metrics, Events and Logs for auto-discovered pods and Kubernetes nodes.' - }, - { - type: 0, - name: 'Diamanti', - logo: 'diamanti', - link: 'https://www.diamanti.com/products/', - blurb: 'Diamanti deploys containers with guaranteed performance using Kubernetes in the first hyperconverged appliance purpose built for containerized applications.' - }, - { - type: 0, - name: 'Aporeto', - logo: 'aporeto', - link: 'https://aporeto.com/trireme', - blurb: 'Aporeto makes cloud-native applications secure by default without impacting developer velocity and works at any scale, on any cloud.' - }, - { - type: 2, - name: 'Giant Swarm', - logo: 'giantswarm', - link: 'https://giantswarm.io', - blurb: 'Giant Swarm enables you to simply and rapidly create and use Kubernetes clusters on-demand either on-premises or in the cloud. Contact Giant Swarm to learn about the best way to run cloud native applications anywhere.' - }, - { - type: 3, - name: 'Giant Swarm', - logo: 'giantswarm', - link: 'https://giantswarm.io/product/', - blurb: 'Giant Swarm enables you to simply and rapidly create and use Kubernetes clusters on-demand either on-premises or in the cloud. Contact Giant Swarm to learn about the best way to run cloud native applications anywhere.' - }, - { - type: 3, - name: 'Hasura', - logo: 'hasura', - link: 'https://hasura.io', - blurb: 'Hasura is a Kubernetes-based PaaS and a Postgres-based BaaS that accelerates app development with ready-to-use components.' - }, - { - type: 3, - name: 'Mirantis', - logo: 'mirantis', - link: 'https://www.mirantis.com/software/kubernetes/', - blurb: 'Mirantis - Mirantis Cloud Platform' - }, - { - type: 2, - name: 'Mirantis', - logo: 'mirantis', - link: 'https://content.mirantis.com/Containerizing-OpenStack-on-Kubernetes-Video-Landing-Page.html', - blurb: 'Mirantis builds and manages private clouds with open source software such as OpenStack, deployed as containers orchestrated by Kubernetes.' - }, - { - type: 0, - name: 'Kubernetic', - logo: 'kubernetic', - link: 'https://kubernetic.com/', - blurb: 'Kubernetic is a Kubernetes Desktop client that simplifies and democratizes cluster management for DevOps.' - }, - { - type: 1, - name: 'Reactive Ops', - logo: 'reactive_ops', - link: 'https://www.reactiveops.com/the-kubernetes-experts/', - blurb: 'ReactiveOps has written automation on best practices for infrastructure as code on GCP & AWS using Kubernetes, helping you build and maintain a world-class infrastructure at a fraction of the price of an internal hire.' - }, - { - type: 2, - name: 'Livewyer', - logo: 'livewyer', - link: 'https://livewyer.io/services/kubernetes-experts/', - blurb: 'Kubernetes experts that on-board applications and empower IT teams to get the most out of containerised technology.' - }, - { - type: 2, - name: 'Samsung SDS', - logo: 'samsung_sds', - link: 'http://www.samsungsdsa.com/cloud-infrastructure_kubernetes', - blurb: 'Samsung SDS’s Cloud Native Computing Team offers expert consulting across the range of technical aspects involved in building services targeted at a Kubernetes cluster.' - }, - { - type: 2, - name: 'Container Solutions', - logo: 'container_solutions', - link: 'http://container-solutions.com/resources/kubernetes/', - blurb: 'Container Solutions is a premium software consultancy that focuses on programmable infrastructure, offering our expertise in software development, strategy and operations to help you innovate at speed and scale.' - }, - { - type: 4, - name: 'Container Solutions', - logo: 'container_solutions', - link: 'http://container-solutions.com/resources/kubernetes/', - blurb: 'Container Solutions is a premium software consultancy that focuses on programmable infrastructure, offering our expertise in software development, strategy and operations to help you innovate at speed and scale.' - }, - { - type: 2, - name: 'Jetstack', - logo: 'jetstack', - link: 'https://www.jetstack.io/', - blurb: 'Jetstack is an organisation focused entirely on Kubernetes. They will help you to get the most out of Kubernetes through expert professional services and open source tooling. Get in touch, and accelerate your project.' - }, - { - type: 0, - name: 'Tigera', - logo: 'tigera', - link: 'http://docs.projectcalico.org/latest/getting-started/kubernetes/', - blurb: 'Tigera builds high performance, policy driven, cloud native networking solutions for Kubernetes.' - }, - { - type: 1, - name: 'Harbur', - logo: 'harbur', - link: 'https://harbur.io/', - blurb: 'Based in Barcelona, Harbur is a consulting firm that helps companies deploy self-healing solutions empowered by Container technologies' - }, - { - type: 0, - name: 'Spotinst', - logo: 'spotinst', - link: 'http://blog.spotinst.com/2016/08/04/elastigroup-kubernetes-minions-steroids/', - blurb: 'Your Kubernetes For 80% Less. Run K8s workloads on Spot Instances with 100% availability to save 80% + autoscale your Kubernetes with maximum efficiency in heterogenous environments.' - }, - { - type: 2, - name: 'InwinSTACK', - logo: 'inwinstack', - link: 'http://www.inwinstack.com/index.php/en/solutions-en/', - blurb: 'Our container service leverages OpenStack-based infrastructure and its container orchestration engine Magnum to manage Kubernetes clusters.' - }, - { - type: 4, - name: 'InwinSTACK', - logo: 'inwinstack', - link: 'http://www.inwinstack.com/index.php/en/solutions-en/', - blurb: 'Our container service leverages OpenStack-based infrastructure and its container orchestration engine Magnum to manage Kubernetes clusters.' - }, - { - type: 3, - name: 'InwinSTACK', - logo: 'inwinstack', - link: 'https://github.com/inwinstack/kube-ansible', - blurb: 'inwinSTACK - kube-ansible' - }, - { - type: 1, - name: 'Semantix', - logo: 'semantix', - link: 'http://www.semantix.com.br/', - blurb: 'Semantix is a company that works with data analytics and distributed systems. Kubernetes is used to orchestrate services for our customers.' - }, - { - type: 0, - name: 'ASM Technologies Limited', - logo: 'asm', - link: 'http://www.asmtech.com/', - blurb: 'Our technology supply chain portfolio enables your software products to be accessible, viable and available more effectively.' - }, - { - type: 1, - name: 'InfraCloud Technologies', - logo: 'infracloud', - link: 'http://blog.infracloud.io/state-of-kubernetes/', - blurb: 'InfraCloud Technologies is software consultancy which provides services in Containers, Cloud and DevOps.' - }, - { - type: 0, - name: 'SignalFx', - logo: 'signalfx', - link: 'https://github.com/signalfx/integrations/tree/master/kubernetes', - blurb: 'Gain real-time visibility across metrics & the most intelligent alerts for todays architectures, including deep integration with Kubernetes' - }, - { - type: 0, - name: 'NATS', - logo: 'nats', - link: 'https://github.com/pires/kubernetes-nats-cluster', - blurb: 'NATS is a simple, secure, and scalable cloud native messaging system.' - }, - { - type: 2, - name: 'RX-M', - logo: 'rxm', - link: 'http://rx-m.com/training/kubernetes-training/', - blurb: 'Market neutral Kubernetes Dev, DevOps and Production training and consulting services.' - }, - { - type: 4, - name: 'RX-M', - logo: 'rxm', - link: 'http://rx-m.com/training/kubernetes-training/', - blurb: 'Market neutral Kubernetes Dev, DevOps and Production training and consulting services.' - }, - { - type: 1, - name: 'Emerging Technology Advisors', - logo: 'eta', - link: 'https://www.emergingtechnologyadvisors.com/services/kubernetes.html', - blurb: 'ETA helps companies architect, implement, and manage scalable applications using Kubernetes on public or private cloud.' - }, - { - type: 0, - name: 'CloudPlex.io', - logo: 'cloudplex', - link: 'http://www.cloudplex.io', - blurb: 'CloudPlex enables operations teams to visually deploy, orchestrate, manage, and monitor infrastructure, applications, and services in public or private cloud.' - }, - { - type: 2, - name: 'Kumina', - logo: 'kumina', - link: 'https://www.kumina.nl/managed_kubernetes', - blurb: 'Kumina combines the power of Kubernetes with 10+ years of experience in IT operations. We create, build and support fully managed Kubernetes solutions on your choice of infrastructure. We also provide consulting and training.' - }, - { - type: 0, - name: 'CA Technologies', - logo: 'ca', - link: 'https://docops.ca.com/ca-continuous-delivery-director/integrations/en/plug-ins/kubernetes-plug-in', - blurb: 'The CA Continuous Delivery Director Kubernetes plugin orchestrates deployment of containerized applications within an end-to-end release pipeline.' - }, - { - type: 0, - name: 'CoScale', - logo: 'coscale', - link: 'http://www.coscale.com/blog/how-to-monitor-your-kubernetes-cluster', - blurb: 'Full stack monitoring of containers and microservices orchestrated by Kubernetes. Powered by anomaly detection to find problems faster.' - }, - { - type: 2, - name: 'Supergiant.io', - logo: 'supergiant', - link: 'https://supergiant.io/blog/supergiant-packing-algorithm-unique-save-money', - blurb: 'Supergiant autoscales hardware for Kubernetes. Open-source, it makes HA, distributed, stateful apps easy to deploy, manage, and scale.' - }, - { - type: 0, - name: 'Avi Networks', - logo: 'avinetworks', - link: 'https://kb.avinetworks.com/avi-vantage-openshift-installation-guide/', - blurb: 'Avis elastic application services fabric provides scalable, feature rich & integrated L4-7 networking for K8S environments.' - }, - { - type: 1, - name: 'Codecrux web technologies pvt ltd', - logo: 'codecrux', - link: 'http://codecrux.com/kubernetes/', - blurb: 'At CodeCrux we help your organization get the most out of Containers and Kubernetes, regardless of where you are in your journey' - }, - { - type: 0, - name: 'Greenqloud', - logo: 'qstack', - link: 'https://www.qstack.com/application-orchestration/', - blurb: 'Qstack provides self-serviceable on-site Kubernetes clusters with an intuitive User Interface for Infrastructure and Kubernetes management.' - }, - { - type: 1, - name: 'StackOverdrive.io', - logo: 'stackoverdrive', - link: 'http://www.stackoverdrive.net/kubernetes-consulting/', - blurb: 'StackOverdrive helps organizations of all sizes leverage Kubernetes for container based orchestration and management.' - }, - { - type: 0, - name: 'StackIQ, Inc.', - logo: 'stackiq', - link: 'https://www.stackiq.com/kubernetes/', - blurb: 'With Stacki and the Stacki Pallet for Kubernetes, you can go from bare metal to containers in one step very quickly and easily.' - }, - { - type: 0, - name: 'Cobe', - logo: 'cobe', - link: 'https://cobe.io/product-page/', - blurb: 'Manage Kubernetes clusters with a live, searchable model that captures all relationships and performance data in full visualised context.' - }, - { - type: 0, - name: 'Datawire', - logo: 'datawire', - link: 'http://www.datawire.io', - blurb: 'Datawires open source tools let your microservices developers be awesomely productive on Kubernetes, while letting ops sleep at night.' - }, - { - type: 0, - name: 'Mashape, Inc.', - logo: 'kong', - link: 'https://getkong.org/install/kubernetes/', - blurb: 'Kong is a scalable open source API layer that runs in front of any RESTful API and can be provisioned to a Kubernetes cluster.' - }, - { - type: 0, - name: 'F5 Networks', - logo: 'f5networks', - link: 'http://github.com/f5networks', - blurb: 'We have a LB integration into Kubernetes.' - }, - { - type: 1, - name: 'Lovable Tech', - logo: 'lovable', - link: 'http://lovable.tech/', - blurb: 'World class engineers, designers, and strategic consultants helping you ship Lovable web & mobile technology.' - }, - { - type: 0, - name: 'StackState', - logo: 'stackstate', - link: 'http://stackstate.com/platform/container-monitoring', - blurb: 'Operational Analytics across teams and tools. Includes topology visualization, root cause analysis and anomaly detection for Kubernetes.' - }, - { - type: 1, - name: 'INEXCCO INC', - logo: 'inexcco', - link: 'https://www.inexcco.com/', - blurb: 'Strong DevOps and Cloud talent working with couple clients on kubernetes and helm implementations. ' - }, - { - type: 2, - name: 'Bitnami', - logo: 'bitnami', - link: 'http://bitnami.com/kubernetes', - blurb: 'Bitnami brings a catalog of trusted, up to date, and easy to use applications and application building blocks to Kubernetes.' - }, - { - type: 1, - name: 'Nebulaworks', - logo: 'nebulaworks', - link: 'http://www.nebulaworks.com/container-platforms', - blurb: 'Nebulaworks provides services to help the enterprise adopt modern container platforms and optimized processes to enable innovation at scale.' - }, - { - type: 1, - name: 'EASYNUBE', - logo: 'easynube', - link: 'http://easynube.co.uk/devopsnube/', - blurb: 'EasyNube provide architecture, implementation, and manage scalable applications using Kubernetes and Openshift.' - }, - { - type: 1, - name: 'Opcito Technologies', - logo: 'opcito', - link: 'http://www.opcito.com/kubernetes/', - blurb: 'Opcito is a software consultancy that uses Kubernetes to help organisations build, architect & deploy highly scalable applications.' - }, - { - type: 0, - name: 'code by Dell EMC', - logo: 'codedellemc', - link: 'https://blog.codedellemc.com', - blurb: 'Respected as a thought leader in storage persistence for containerized applications. Contributed significant work to K8 and Ecosystem' - }, - { - type: 0, - name: 'Instana', - logo: 'instana', - link: 'https://www.instana.com/supported-technologies/', - blurb: 'Instana monitors performance of the applications, infrastructure, containers and services deployed on a Kubernetes cluster.' - }, - { - type: 0, - name: 'Netsil', - logo: 'netsil', - link: 'https://netsil.com/kubernetes/', - blurb: 'Generate a real-time, auto-discovered application topology map! Monitor Kubernetes pods and namespaces without any code instrumentation.' - }, - { - type: 2, - name: 'Treasure Data', - logo: 'treasuredata', - link: 'https://fluentd.treasuredata.com/kubernetes-logging/', - blurb: 'Fluentd Enterprise brings smart, secure logging to Kubernetes, and brings integrations with backends such as Splunk, Kafka, or AWS S3.' - }, - { - type: 2, - name: 'Kenzan', - logo: 'Kenzan', - link: 'http://kenzan.com/?ref=kubernetes', - blurb: 'We provide custom consulting services leveraging Kubernetes as our foundation. This involves the platform development, delivery pipelines, and the application development within Kubernetes.' - }, - { - type: 2, - name: 'New Context', - logo: 'newcontext', - link: 'https://www.newcontext.com/devsecops-infrastructure-automation-orchestration/', - blurb: 'New Context builds and uplifts secure Kubernetes implementations and migrations, from initial design to infrastructure automation and management.' - }, - { - type: 2, - name: 'Banzai', - logo: 'banzai', - link: 'https://banzaicloud.com/platform/', - blurb: 'Banzai Cloud brings cloud native to the enterprise and simplifies the transition to microservices on Kubernetes.' - }, - { - type: 3, - name: 'Kublr', - logo: 'kublr', - link: 'http://kublr.com', - blurb: 'Kublr - Accelerate and control the deployment, scaling, monitoring and management of your containerized applications.' - }, - { - type: 1, - name: 'ControlPlane', - logo: 'controlplane', - link: 'https://control-plane.io', - blurb: 'We are a London-based Kubernetes consultancy with a focus on security and continuous delivery. We offer consulting & training.' - }, - { - type: 3, - name: 'Nirmata', - logo: 'nirmata', - link: 'https://www.nirmata.com/', - blurb: 'Nirmata - Nirmata Managed Kubernetes' - }, - { - type: 2, - name: 'Nirmata', - logo: 'nirmata', - link: 'https://www.nirmata.com/', - blurb: 'Nirmata is a software platform that helps DevOps teams deliver enterprise-grade and cloud-provider agnostic Kubernetes based container management solutions.' - }, - { - type: 3, - name: 'TenxCloud', - logo: 'tenxcloud', - link: 'https://tenxcloud.com', - blurb: 'TenxCloud - TenxCloud Container Engine (TCE)' - }, - { - type: 2, - name: 'TenxCloud', - logo: 'tenxcloud', - link: 'https://www.tenxcloud.com/', - blurb: 'Founded in October 2014, TenxCloud is a leading enterprise container cloud computing service provider in China, covering the areas such as container PaaS cloud platform, micro-service management, DevOps, development test, AIOps and so on. Provide private cloud PaaS products and solutions for financial, energy, operator, manufacturing, education and other industry customers.' - }, - { - type: 0, - name: 'Twistlock', - logo: 'twistlock', - link: 'https://www.twistlock.com/', - blurb: 'Security at Kubernetes Scale: Twistlock allows you to deploy fearlessly with assurance that your images and containers are free of vulnerabilities and protected at runtime.' - }, - { - type: 0, - name: 'Endocode AG', - logo: 'endocode', - link: 'https://endocode.com/kubernetes/', - blurb: 'Endocode practices and teaches the open source way. Kernel to cluster - Dev to Ops. We offer Kubernetes trainings, services and support.' - }, - { - type: 2, - name: 'Accenture', - logo: 'accenture', - link: 'https://www.accenture.com/us-en/service-application-containers', - blurb: 'Architecture, implementation and operation of world-class Kubernetes solutions for cloud-native clients.' - }, - { - type: 1, - name: 'Biarca', - logo: 'biarca', - link: 'http://biarca.io/', - blurb: 'Biarca is a cloud services provider and key focus areas Key areas of focus for Biarca include Cloud Adoption Services, Infrastructure Services, DevOps Services and Application Services. Biarca leverages Kubernetes to deliver containerized solutions.' - }, - { - type: 2, - name: 'Claranet', - logo: 'claranet', - link: 'http://www.claranet.co.uk/hosting/google-cloud-platform-consulting-managed-services', - blurb: 'Claranet helps people migrate to the cloud and take full advantage of the new world it offers. We consult, design, build and proactively manage the right infrastructure and automation tooling for clients to achieve this.' - }, - { - type: 1, - name: 'CloudKite', - logo: 'cloudkite', - link: 'https://cloudkite.io/', - blurb: 'CloudKite.io helps companies build and maintain highly automated, resilient, and impressively performing software on Kubernetes.' - }, - { - type: 2, - name: 'CloudOps', - logo: 'CloudOps', - link: 'https://www.cloudops.com/services/docker-and-kubernetes-workshops/', - blurb: 'CloudOps gets you hands-on with the K8s ecosystem via workshop/lab. Get prod ready K8s in cloud(s) of your choice with our managed services.' - }, - { - type: 2, - name: 'Ghostcloud', - logo: 'ghostcloud', - link: 'https://www.ghostcloud.cn/ecos-kubernetes', - blurb: 'EcOS is an enterprise-grade PaaS / CaaS based on Docker and Kubernetes, which makes it easier to configure, deploy and manage containerized applications.' - }, - { - type: 3, - name: 'Ghostcloud', - logo: 'ghostcloud', - link: 'https://www.ghostcloud.cn/ecos-kubernetes', - blurb: 'EcOS is an enterprise-grade PaaS / CaaS based on Docker and Kubernetes, which makes it easier to configure, deploy and manage containerized applications.' - }, - { - type: 2, - name: 'Contino', - logo: 'contino', - link: 'https://www.contino.io/', - blurb: 'We help enterprise organizations adopt DevOps, containers and cloud computing. Contino is a global consultancy that enables regulated organizations to accelerate innovation through the adoption of modern approaches to software delivery.' - }, - { - type: 2, - name: 'Booz Allen Hamilton', - logo: 'boozallenhamilton', - link: 'https://www.boozallen.com/', - blurb: 'Booz Allen partners with public and private sector clients to solve their most difficult challenges through a combination of consulting, analytics, mission operations, technology, systems delivery, cybersecurity, engineering, and innovation expertise.' - }, - { - type: 1, - name: 'BigBinary', - logo: 'bigbinary', - link: 'http://blog.bigbinary.com/categories/Kubernetes', - blurb: 'Provider of Digital Solutions for federal and commercial clients, to include DevSecOps, cloud platforms, transformation strategy, cognitive solutions, and UX.' - }, - { - type: 0, - name: 'CloudPerceptions', - logo: 'cloudperceptions', - link: 'https://www.meetup.com/Triangle-Kubernetes-Meetup/files/', - blurb: 'Container security solution for small-to-medium size enterprises who plan to run Kubernetes on shared infrastructure.' - }, - { - type: 2, - name: 'Creationline, Inc.', - logo: 'creationline', - link: 'https://www.creationline.com/ci', - blurb: 'Total solution for container based IT resource management.' - }, - { - type: 0, - name: 'DataCore Software', - logo: 'datacore', - link: 'https://www.datacore.com/solutions/virtualization/containerization', - blurb: 'DataCore provides highly-available, high-performance universal block storage for Kubernetes, radically improving the speed of deployment.' - }, - { - type: 0, - name: 'Elastifile', - logo: 'elastifile', - link: 'https://www.elastifile.com/stateful-containers', - blurb: 'Elastifile’s cross-cloud data fabric delivers elastically scalable, high performance, software-defined persistent storage for Kubernetes.' - }, - { - type: 0, - name: 'GitLab', - logo: 'gitlab', - link: 'https://about.gitlab.com/2016/11/14/idea-to-production/', - blurb: 'With GitLab and Kubernetes, you can deploy a complete CI/CD pipeline with multiple environments, automatic deployments, and automatic monitoring.' - }, - { - type: 0, - name: 'Gravitational, Inc.', - logo: 'gravitational', - link: 'https://gravitational.com/telekube/', - blurb: 'Telekube combines Kubernetes with Teleport, our modern SSH server, so operators can remotely manage a multitude of K8s application deployments.' - }, - { - type: 0, - name: 'Hitachi Data Systems', - logo: 'hitachi', - link: 'https://www.hds.com/en-us/products-solutions/application-solutions/unified-compute-platform-with-kubernetes-orchestration.html', - blurb: 'Build the Applications You Need to Drive Your Business - DEVELOP AND DEPLOY APPLICATIONS FASTER AND MORE RELIABLY.' - }, - { - type: 1, - name: 'Infosys Technologies', - logo: 'infosys', - link: 'https://www.infosys.com', - blurb: 'Monolithic to microservices on openshift is a offering that we are building as part of open source practice.' - }, - { - type: 0, - name: 'JFrog', - logo: 'jfrog', - link: 'https://www.jfrog.com/use-cases/12584/', - blurb: 'You can use Artifactory to store and manage all of your application’s container images and deploy to Kubernetes and setup a build, test, deploy pipeline using Jenkins and Artifactory. Once an image is ready to be rolled out, Artifactory can trigger a rolling-update deployment into a Kubernetes cluster without downtime – automatically!' - }, - { - type: 0, - name: 'Navops by Univa', - logo: 'navops', - link: 'https://www.navops.io', - blurb: 'Navops is a suite of products that enables enterprises to take full advantage of Kubernetes and provides the ability to quickly and efficiently run containers at scale.' - }, - { - type: 0, - name: 'NeuVector', - logo: 'neuvector', - link: 'http://neuvector.com/solutions-for-kubernetes-security/', - blurb: 'NeuVector delivers an application and network intelligent container network security solution integrated with and optimized for Kubernetes.' - }, - { - type: 1, - name: 'OpsZero', - logo: 'opszero', - link: 'https://www.opszero.com/kubernetes.html', - blurb: 'opsZero provides DevOps for Startups. We build and service your Kubernetes and Cloud Infrastructure to accelerate your release cycle.' - }, - { - type: 1, - name: 'Shiwaforce.com Ltd.', - logo: 'shiwaforce', - link: 'https://www.shiwaforce.com/en/', - blurb: 'Shiwaforce.com is the Agile Partner in Digital Transformation. Our solutions follow business changes quickly, easily and cost-effectively.' - }, - { - type: 1, - name: 'SoftServe', - logo: 'softserve', - link: 'https://www.softserveinc.com/en-us/blogs/kubernetes-travis-ci/', - blurb: 'SoftServe allows its clients to adopt modern application design patterns and benefit from fully integrated, highly available, cost effective Kubernetes clusters at any scale.' - }, - { - type: 1, - name: 'Solinea', - logo: 'solinea', - link: 'https://www.solinea.com/cloud-consulting-services/container-microservices-offerings', - blurb: 'Solinea is a digital transformation consultancy that enables businesses to build innovative solutions by adopting cloud native computing.' - }, - { - type: 1, - name: 'Sphere Software, LLC', - logo: 'spheresoftware', - link: 'https://sphereinc.com/kubernetes/', - blurb: 'The Sphere Software team of experts allows customers to architect and implement scalable applications using Kubernetes in Google Cloud, AWS, and Azure.' - }, - { - type: 1, - name: 'Altoros', - logo: 'altoros', - link: 'https://www.altoros.com/container-orchestration-tools-enablement.html', - blurb: 'Deployment and configuration of Kubernetes, Optimization of existing solutions, training for developers on using Kubernetes, support.' - }, - { - type: 0, - name: 'Cloudbase Solutions', - logo: 'cloudbase', - link: 'https://cloudbase.it/kubernetes', - blurb: 'Cloudbase Solutions provides Kubernetes cross-cloud interoperability for Windows and Linux deployments based on open source technologies.' - }, - { - type: 0, - name: 'Codefresh', - logo: 'codefresh', - link: 'https://codefresh.io/kubernetes-deploy/', - blurb: 'Codefresh is a complete DevOps platform built for containers and Kubernetes. With CI/CD pipelines, image management, and deep integrations into Kubernetes and Helm.' - }, - { - type: 0, - name: 'NetApp', - logo: 'netapp', - link: 'http://netapp.io/2016/12/23/introducing-trident-dynamic-persistent-volume-provisioner-kubernetes/', - blurb: 'Dynamic provisioning and persistent storage support.' - }, - { - type: 0, - name: 'OpenEBS', - logo: 'OpenEBS', - link: 'https://openebs.io/', - blurb: 'OpenEBS is containerized storage for containers integrated tightly into Kubernetes and based on distributed block storage and containerization of storage control. OpenEBS derives intent from K8s and other YAML or JSON such as per container QoS SLAs, tiering and replica policies, and more. OpenEBS is EBS API compliant.' - }, - { - type: 3, - name: 'Google Kubernetes Engine', - logo: 'google', - link: 'https://cloud.google.com/kubernetes-engine/', - blurb: 'Google - Google Kubernetes Engine' - }, - { - type: 1, - name: 'Superorbital', - logo: 'superorbital', - link: 'https://superorbit.al/workshops/kubernetes/', - blurb: 'Helping companies navigate the Cloud Native waters through Kubernetes consulting and training.' - }, - { - type: 3, - name: 'Apprenda', - logo: 'apprenda', - link: 'https://apprenda.com/kismatic/', - blurb: 'Apprenda - Kismatic Enterprise Toolkit (KET)' - }, - { - type: 3, - name: 'Red Hat', - logo: 'redhat', - link: 'https://www.openshift.com', - blurb: 'Red Hat - OpenShift Online and OpenShift Container Platform' - }, - { - type: 3, - name: 'Rancher', - logo: 'rancher', - link: 'http://rancher.com/kubernetes/', - blurb: 'Rancher Inc. - Rancher Kubernetes' - }, - { - type: 3, - name: 'Canonical', - logo: 'canonical', - link: 'https://www.ubuntu.com/kubernetes', - blurb: 'The Canonical Distribution of Kubernetes enables you to operate Kubernetes clusters on demand on any major public cloud and private infrastructure.' - }, - { - type: 2, - name: 'Canonical', - logo: 'canonical', - link: 'https://www.ubuntu.com/kubernetes', - blurb: 'Canonical Ltd. - Canonical Distribution of Kubernetes' - }, - { - type: 3, - name: 'Cisco', - logo: 'cisco', - link: 'https://www.cisco.com', - blurb: 'Cisco Systems - Cisco Container Platform' - }, - { - type: 3, - name: 'Cloud Foundry', - logo: 'cff', - link: 'https://www.cloudfoundry.org/container-runtime/', - blurb: 'Cloud Foundry - Cloud Foundry Container Runtime' - }, - { - type: 3, - name: 'IBM', - logo: 'ibm', - link: 'https://www.ibm.com/cloud/container-service', - blurb: 'IBM - IBM Cloud Kubernetes Service' - }, - { - type: 2, - name: 'IBM', - logo: 'ibm', - link: 'https://www.ibm.com/cloud/container-service/', - blurb: 'The IBM Cloud Kubernetes Service combines Docker and Kubernetes to deliver powerful tools, an intuitive user experience, and built-in security and isolation to enable rapid delivery of applications all while leveraging Cloud Services including cognitive capabilities from Watson.' - }, - { - type: 3, - name: 'Samsung', - logo: 'samsung_sds', - link: 'https://github.com/samsung-cnct/kraken', - blurb: 'Samsung SDS - Kraken' - }, - { - type: 3, - name: 'IBM', - logo: 'ibm', - link: 'https://www.ibm.com/cloud-computing/products/ibm-cloud-private/', - blurb: 'IBM - IBM Cloud Private' - }, - { - type: 3, - name: 'Kinvolk', - logo: 'kinvolk', - link: 'https://github.com/kinvolk/kube-spawn', - blurb: 'Kinvolk - kube-spawn' - }, - { - type: 3, - name: 'Heptio', - logo: 'heptio', - link: 'https://aws.amazon.com/quickstart/architecture/heptio-kubernetes', - blurb: 'Heptio - AWS-Quickstart' - }, - { - type: 2, - name: 'Heptio', - logo: 'heptio', - link: 'http://heptio.com', - blurb: 'Heptio helps businesses of all sizes get closer to the vibrant Kubernetes community.' - }, - { - type: 3, - name: 'StackPointCloud', - logo: 'stackpoint', - link: 'https://stackpoint.io', - blurb: 'StackPointCloud - StackPointCloud' - }, - { - type: 2, - name: 'StackPointCloud', - logo: 'stackpoint', - link: 'https://stackpoint.io', - blurb: 'StackPointCloud offers a wide range of support plans for managed Kubernetes clusters built through its universal control plane for Kubernetes Anywhere.' - }, - { - type: 3, - name: 'Caicloud', - logo: 'caicloud', - link: 'https://caicloud.io/products/compass', - blurb: 'Caicloud - Compass' - }, - { - type: 2, - name: 'Caicloud', - logo: 'caicloud', - link: 'https://caicloud.io/', - blurb: 'Founded by ex-Googlers,and early Kubernetes contributors, Caicloud leverages Kubernetes to provide container products which have successfully served Fortune 500 enterprises, and further utilizes Kubernetes as a vehicle to deliver ultra-speed deep learning experience.' - }, - { - type: 3, - name: 'Alibaba', - logo: 'alibaba', - link: 'https://www.aliyun.com/product/containerservice?spm=5176.8142029.388261.219.3836dbccRpJ5e9', - blurb: 'Alibaba Cloud - Alibaba Cloud Container Service' - }, - { - type: 3, - name: 'Tencent', - logo: 'tencent', - link: 'https://cloud.tencent.com/product/ccs?lang=en', - blurb: 'Tencent Cloud - Tencent Cloud Container Service' - }, - { - type: 3, - name: 'Huawei', - logo: 'huawei', - link: 'http://www.huaweicloud.com/product/cce.html', - blurb: 'Huawei - Huawei Cloud Container Engine' - }, - { - type: 2, - name: 'Huawei', - logo: 'huawei', - link: 'http://developer.huawei.com/ict/en/site-paas', - blurb: 'FusionStage is an enterprise-grade Platform as a Service product, the core of which is based on mainstream open source container technology including Kubernetes and Docker.' - }, - { - type: 3, - name: 'Google', - logo: 'google', - link: 'https://github.com/kubernetes/kubernetes/tree/master/cluster', - blurb: 'Google - kube-up.sh on Google Compute Engine' - }, - { - type: 3, - name: 'Poseidon', - logo: 'poseidon', - link: 'https://typhoon.psdn.io/', - blurb: 'Poseidon - Typhoon' - }, - { - type: 3, - name: 'Netease', - logo: 'netease', - link: 'https://www.163yun.com/product/container-service-dedicated', - blurb: 'Netease - Netease Container Service Dedicated' - }, - { - type: 2, - name: 'Loodse', - logo: 'loodse', - link: 'https://loodse.com', - blurb: 'Loodse provides Kubernetes training & consulting, and host related events regularly across Europe.' - }, - { - type: 4, - name: 'Loodse', - logo: 'loodse', - link: 'https://loodse.com', - blurb: 'Loodse provides Kubernetes training & consulting, and host related events regularly across Europe.' - }, - { - type: 4, - name: 'LF Training', - logo: 'lf-training', - link: 'https://training.linuxfoundation.org/', - blurb: 'The Linux Foundation’s training program combines the broad, foundational knowledge with the networking opportunities that attendees need to thrive in their careers today.' - }, - { - type: 3, - name: 'Loodse', - logo: 'loodse', - link: 'https://loodse.com', - blurb: 'Loodse - Kubermatic Container Engine' - }, - { - type: 1, - name: 'LTI', - logo: 'lti', - link: 'https://www.lntinfotech.com/', - blurb: 'LTI helps enterprises architect, develop and support scalable cloud native apps using Docker and Kubernetes for private or public cloud.' - }, - { - type: 3, - name: 'Microsoft', - logo: 'microsoft', - link: 'https://github.com/Azure/acs-engine', - blurb: 'Microsoft - Azure acs-engine' - }, - { - type: 3, - name: 'Microsoft', - logo: 'microsoft', - link: 'https://docs.microsoft.com/en-us/azure/aks/', - blurb: 'Microsoft - Azure Container Service AKS' - }, - { - type: 3, - name: 'Oracle', - logo: 'oracle', - link: 'http://www.wercker.com/product', - blurb: 'Oracle - Oracle Container Engine' - }, - { - type: 3, - name: 'Oracle', - logo: 'oracle', - link: 'https://github.com/oracle/terraform-kubernetes-installer', - blurb: 'Oracle - Oracle Terraform Kubernetes Installer' - }, - { - type: 3, - name: 'Mesosphere', - logo: 'mesosphere', - link: 'https://mesosphere.com/kubernetes/', - blurb: 'Mesosphere - Kubernetes on DC/OS' - }, - { - type: 3, - name: 'Appscode', - logo: 'appscode', - link: 'https://appscode.com/products/cloud-deployment/', - blurb: 'Appscode - Pharmer' - }, - { - type: 3, - name: 'SAP', - logo: 'sap', - link: 'https://cloudplatform.sap.com/index.html', - blurb: 'SAP - Cloud Platform - Gardener (not yet released)' - }, - { - type: 3, - name: 'Oracle', - logo: 'oracle', - link: 'https://www.oracle.com/linux/index.html', - blurb: 'Oracle - Oracle Linux Container Services for use with Kubernetes' - }, - { - type: 3, - name: 'CoreOS', - logo: 'coreos', - link: 'https://github.com/kubernetes-incubator/bootkube', - blurb: 'CoreOS - bootkube' - }, - { - type: 2, - name: 'CoreOS', - logo: 'coreos', - link: 'https://coreos.com/', - blurb: 'Tectonic is the enterprise-ready Kubernetes product, by CoreOS. It adds key features to allow you to manage, update, and control clusters in production.' - }, - { - type: 3, - name: 'Weaveworks', - logo: 'weave_works', - link: '/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm/', - blurb: 'Weaveworks - kubeadm' - }, - { - type: 3, - name: 'Joyent', - logo: 'joyent', - link: 'https://github.com/joyent/triton-kubernetes', - blurb: 'Joyent - Triton Kubernetes' - }, - { - type: 3, - name: 'Wise2c', - logo: 'wise2c', - link: 'http://www.wise2c.com/solution', - blurb: 'Wise2C Technology - WiseCloud' - }, - { - type: 2, - name: 'Wise2c', - logo: 'wise2c', - link: 'http://www.wise2c.com', - blurb: 'Using Kubernetes to providing IT continuous delivery and Enterprise grade container management solution to Financial Industry.' - }, - { - type: 3, - name: 'Docker', - logo: 'docker', - link: 'https://www.docker.com/enterprise-edition', - blurb: 'Docker - Docker Enterprise Edition' - }, - { - type: 3, - name: 'Daocloud', - logo: 'daocloud', - link: 'http://www.daocloud.io/dce', - blurb: 'DaoCloud - DaoCloud Enterprise' - }, - { - type: 2, - name: 'Daocloud', - logo: 'daocloud', - link: 'http://www.daocloud.io/dce', - blurb: 'We provide enterprise-level cloud native application platform that supports both Kubernetes and Docker Swarm.' - }, - { - type: 4, - name: 'Daocloud', - logo: 'daocloud', - link: 'http://www.daocloud.io/dce', - blurb: 'We provide enterprise-level cloud native application platform that supports both Kubernetes and Docker Swarm.' - }, - { - type: 3, - name: 'SUSE', - logo: 'suse', - link: 'https://www.suse.com/products/caas-platform/', - blurb: 'SUSE - SUSE CaaS (Container as a Service) Platform' - }, - { - type: 3, - name: 'Pivotal', - logo: 'pivotal', - link: 'https://cloud.vmware.com/pivotal-container-service', - blurb: 'Pivotal/VMware - Pivotal Container Service (PKS)' - }, - { - type: 3, - name: 'VMware', - logo: 'vmware', - link: 'https://cloud.vmware.com/pivotal-container-service', - blurb: 'Pivotal/VMware - Pivotal Container Service (PKS)' - }, - { - type: 3, - name: 'Alauda', - logo: 'alauda', - link: 'http://www.alauda.cn/product/detail/id/68.html', - blurb: 'Alauda - Alauda EE' - }, - { - type: 4, - name: 'Alauda', - logo: 'alauda', - link: 'http://www.alauda.cn/product/detail/id/68.html', - blurb: 'Alauda provides Kubernetes-Centric Enterprise Platform-as-a-Service offerings with a razor focus on delivering Cloud Native capabilities and DevOps best practices to enterprise customers across industries in China.' - }, - { - type: 2, - name: 'Alauda', - logo: 'alauda', - link: 'www.alauda.io', - blurb: 'Alauda provides Kubernetes-Centric Enterprise Platform-as-a-Service offerings with a razor focus on delivering Cloud Native capabilities and DevOps best practices to enterprise customers across industries in China.' - }, - { - type: 3, - name: 'EasyStack', - logo: 'easystack', - link: 'https://easystack.cn/eks/', - blurb: 'EasyStack - EasyStack Kubernetes Service (EKS)' - }, - { - type: 3, - name: 'CoreOS', - logo: 'coreos', - link: 'https://coreos.com/tectonic/', - blurb: 'CoreOS - Tectonic' - }, - { - type: 0, - name: 'GoPaddle', - logo: 'gopaddle', - link: 'https://gopaddle.io', - blurb: 'goPaddle is a DevOps platform for Kubernetes developers. It simplifies the Kubernetes Service creation and maintenance through source to image conversion, build & version management, team management, access controls and audit logs, single click provision of Kubernetes Clusters across multiple clouds from a single console.' - }, - { - type: 0, - name: 'Vexxhost', - logo: 'vexxhost', - link: 'https://vexxhost.com/public-cloud/container-services/kubernetes/', - blurb: 'VEXXHOST offers a high-performance container management service powered by Kubernetes and OpenStack Magnum.' - }, - { - type: 1, - name: 'Component Soft', - logo: 'componentsoft', - link: 'https://www.componentsoft.eu/?p=3925', - blurb: 'Component Soft offers training, consultation and support around open cloud technologies like Kubernetes, Docker, Openstack and Ceph.' - }, - { - type: 0, - name: 'Datera', - logo: 'datera', - link: 'http://www.datera.io/kubernetes/', - blurb: 'Datera delivers high performance, self-managing elastic block storage with self-service provisioning for deploying Kubernetes at scale.' - }, - { - type: 0, - name: 'Containership', - logo: 'containership', - link: 'https://containership.io/', - blurb: 'Containership is a cloud agnostic managed kubernetes offering that supports automatic provisioning on over 14 cloud providers.' - }, - { - type: 0, - name: 'Pure Storage', - logo: 'pure_storage', - link: 'https://hub.docker.com/r/purestorage/k8s/', - blurb: 'Our flexvol driver and dynamic provisioner allow FlashArray/Flashblade storage devices to be consumed as first class persistent storage from within Kubernetes.' - }, - { - type: 0, - name: 'Elastisys', - logo: 'elastisys', - link: 'https://elastisys.com/kubernetes/', - blurb: 'Predictive autoscaling - detects recurring workload variations, irregular traffic spikes, and everything in between. Runs K8s in any public or private cloud.' - }, - { - type: 0, - name: 'Portworx', - logo: 'portworx', - link: 'https://portworx.com/use-case/kubernetes-storage/', - blurb: 'With Portworx, you can manage any database or stateful service on any infrastructure using Kubernetes. You get a single data management layer for all of your stateful services, no matter where they run.' - }, - { - type: 1, - name: 'Object Computing, Inc.', - logo: 'objectcomputing', - link: 'https://objectcomputing.com/services/software-engineering/devops/kubernetes-services', - blurb: 'Our portfolio of DevOps consulting services includes Kubernetes support, development, and training.' - }, - { - type: 1, - name: 'Isotoma', - logo: 'isotoma', - link: 'https://www.isotoma.com/blog/2017/10/24/containerisation-tips-for-using-kubernetes-with-aws/', - blurb: 'Based in the North of England, Amazon partners who are delivering Kubernetes solutions on AWS for replatforming and native development.' - }, - { - type: 1, - name: 'Servian', - logo: 'servian', - link: 'https://www.servian.com/cloud-and-technology/', - blurb: 'Based in Australia, Servian provides advisory, consulting and managed services to support both application and data centric kubernetes use cases.' - }, - { - type: 1, - name: 'Redzara', - logo: 'redzara', - link: 'http://redzara.com/cloud-service', - blurb: 'Redzara has wide and in-depth experience in Cloud automation, now taking one giant step by providing container service offering and services to our customers.' - }, - { - type: 0, - name: 'Dataspine', - logo: 'dataspine', - link: 'http://dataspine.xyz/', - blurb: 'Dataspine is building a secure, elastic and serverless deployment platform for production ML/AI workloads on top of k8s.' - }, - { - type: 1, - name: 'CloudBourne', - logo: 'cloudbourne', - link: 'https://cloudbourne.com/kubernetes-enterprise-hybrid-cloud/', - blurb: 'Want to achieve maximum build, deploy and monitoring automation using Kubernetes? We can help.' - }, - { - type: 0, - name: 'CloudBourne', - logo: 'cloudbourne', - link: 'https://cloudbourne.com/', - blurb: 'Our AppZ Hybrid Cloud Platform can help you achieve your digital transformation goals using the powerful Kubernetes.' - }, - { - type: 3, - name: 'BoCloud', - logo: 'bocloud', - link: 'http://www.bocloud.com.cn/en/index.html', - blurb: 'BoCloud - BeyondcentContainer' - }, - { - type: 2, - name: 'Naitways', - logo: 'naitways', - link: 'https://www.naitways.com/', - blurb: 'Naitways is an Operator (AS57119), Integrator and Cloud Services Provider (our own !). We aim to provide value-added services through our mastering of the whole value chain (Infrastructure, Network, Human skills). Private and Public Cloud is available through Kubernetes managed or unmanaged.' - }, - { - type: 2, - name: 'Kinvolk', - logo: 'kinvolk', - link: 'https://kinvolk.io/kubernetes/', - blurb: 'Kinvolk offers Kubernetes engineering & operations support from cluster to kernel. Leading cloud-native organizations turn to Kinvolk for deep-stack Linux expertise.' - }, - { - type: 1, - name: 'Cascadeo Corporation', - logo: 'cascadeo', - link: 'http://www.cascadeo.com/', - blurb: 'Cascadeo designs, implements, and manages containerized workloads with Kubernetes, for both existing applications and greenfield development projects.' - }, - { - type: 1, - name: 'Elastisys AB', - logo: 'elastisys', - link: 'https://elastisys.com/services/#kubernetes', - blurb: 'We design, build, and operate Kubernetes clusters. We are experts in highly available and self-optimizing Kubernetes infrastructures' - }, - { - type: 1, - name: 'Greenfield Guild', - logo: 'greenfield', - link: 'http://greenfieldguild.com/', - blurb: 'The Greenfield Guild builds quality open source solutions on, and offers training and support for, Kubernetes in any environment.' - }, - { - type: 1, - name: 'PolarSeven', - logo: 'polarseven', - link: 'https://polarseven.com/what-we-do/kubernetes/', - blurb: 'To get started up and running with Kubernetes (K8s) our PolarSeven consultants can help you with creating a fully functional dockerized environment to run and deploy your applications.' - }, - { - type: 1, - name: 'Kloia', - logo: 'kloia', - link: 'https://kloia.com/kubernetes/', - blurb: 'Kloia is DevOps and Microservices Consultancy company that helps its customers to migrate their environment to cloud platforms for enabling more scalable and secure environments. We use Kubernetes to provide our customers all-in-one solutions in an cloud-agnostic way.' - }, - { - type: 0, - name: 'Bluefyre', - logo: 'bluefyre', - link: 'https://www.bluefyre.io', - blurb: 'Bluefyre offers a developer-first security platform that is native to Kubernetes. Bluefyre helps your development team ship secure code on Kubernetes faster!' - }, - { - type: 0, - name: 'Harness', - logo: 'harness', - link: 'https://harness.io/harness-continuous-delivery/secret-sauce/smart-automation/', - blurb: 'Harness offers Continuous Delivery As-A-Service will full support for containerized apps and Kubernetes clusters.' - }, - { - type: 0, - name: 'VMware - Wavefront', - logo: 'wavefront', - link: 'https://www.wavefront.com/solutions/container-monitoring/', - blurb: 'The Wavefront platform provides metrics-driven analytics and monitoring for Kubernetes and container dashboards for DevOps and developer teams delivering visibility into high-level services as well as granular container metrics.' - }, - { - type: 0, - name: 'Bloombase, Inc.', - logo: 'bloombase', - link: 'https://www.bloombase.com/go/kubernetes', - blurb: 'Bloombase provides high bandwidth, defense-in-depth data-at-rest encryption to lock down Kubernetes crown-jewels at scale.' - }, - { - type: 0, - name: 'Kasten', - logo: 'kasten', - link: 'https://kasten.io/product/', - blurb: 'Kasten provides enterprise solutions specifically built to address the operational complexity of data management in cloud-native environments.' - }, - { - type: 0, - name: 'Humio', - logo: 'humio', - link: 'https://humio.com', - blurb: 'Humio is a log aggregation database. We offer a Kubernetes integration that will give you insights to your logs across apps and instances.' - }, - { - type: 0, - name: 'Outcold Solutions LLC', - logo: 'outcold', - link: 'https://www.outcoldsolutions.com/#monitoring-kubernetes', - blurb: 'Powerful Certified Splunk applications for Monitoring OpenShift, Kubernetes and Docker.' - }, - { - type: 0, - name: 'SysEleven GmbH', - logo: 'syseleven', - link: 'http://www.syseleven.de/', - blurb: 'Enterprise Customers who are in need of bulletproof operations (High Performance E-Commerce and Enterprise Portals)' - }, - { - type: 0, - name: 'Landoop', - logo: 'landoop', - link: 'http://lenses.stream', - blurb: 'Lenses for Apache Kafka, to deploy, manage and operate with confidence data streaming pipelines and topologies at scale with confidence and native Kubernetes integration.' - }, - { - type: 0, - name: 'Redis Labs', - logo: 'redis', - link: 'https://redislabs.com/blog/getting-started-with-kubernetes-and-redis-using-redis-enterprise/', - blurb: 'Redis Enterprise extends open source Redis and delivers stable high performance and linear scaling required for building microservices on the Kubernetes platform.' - }, - { - type: 3, - name: 'Diamanti', - logo: 'diamanti', - link: 'https://diamanti.com/', - blurb: 'Diamanti - Diamanti-D10' - }, - { - type: 3, - name: 'Eking', - logo: 'eking', - link: 'http://www.eking-tech.com/', - blurb: 'Hainan eKing Technology Co. - eKing Cloud Container Platform' - }, - { - type: 3, - name: 'Harmony Cloud', - logo: 'harmony', - link: 'http://harmonycloud.cn/products/rongqiyun/', - blurb: 'Harmonycloud - Harmonycloud Container Platform' - }, - { - type: 3, - name: 'Woqutech', - logo: 'woqutech', - link: 'http://woqutech.com/product_qfusion.html', - blurb: 'Woqutech - QFusion' - }, - { - type: 3, - name: 'Baidu', - logo: 'baidu', - link: 'https://cloud.baidu.com/product/cce.html', - blurb: 'Baidu Cloud - Baidu Cloud Container Engine' - }, - { - type: 3, - name: 'ZTE', - logo: 'zte', - link: 'https://sdnfv.zte.com.cn/en/home', - blurb: 'ZTE - TECS OpenPalette' - }, - { - type: 1, - name: 'Automatic Server AG', - logo: 'asag', - link: 'http://www.automatic-server.com/paas.html', - blurb: 'We install and operate Kubernetes in big enterprises, create deployment workflows and help to migrate.' - }, - { - type: 1, - name: 'Circulo Siete', - logo: 'circulo', - link: 'https://circulosiete.com/consultoria/kubernetes/', - blurb: 'We are a Mexico based company offering training, consulting and support to migrate your workloads to Kubernetes, Cloud Native Microservices & Devops.' - }, - { - type: 1, - name: 'DevOpsGuru', - logo: 'devopsguru', - link: 'http://devopsguru.ca/workshop', - blurb: 'DevOpsGuru work with small business to transform from physical to virtual to containerization.' - }, - { - type: 1, - name: 'EIN Intelligence Co., Ltd', - logo: 'ein', - link: 'https://ein.io', - blurb: 'Startups and agile enterprises in South Korea.' - }, - { - type: 0, - name: 'GuardiCore', - logo: 'guardicore', - link: 'https://www.guardicore.com/', - blurb: 'GuardiCore provided process level visibility and network policy enforcement on containerized assets on the Kubernetes platform.' - }, - { - type: 0, - name: 'Hedvig', - logo: 'hedvig', - link: 'https://www.hedviginc.com/blog/provisioning-hedvig-storage-with-kubernetes', - blurb: 'Hedvig is software-defined storage that uses NFS or iSCSI for persistent volumes for provisioning shared storage for pods and containers.' - }, - { - type: 0, - name: 'Hewlett Packard Enterprise', - logo: 'hpe', - link: ' https://www.hpe.com/us/en/storage/containers.html', - blurb: 'Persistent Storage that makes data as easy to manage as containers: dynamic provisioning, policy-based performance & protection, QoS, & more.' - }, - { - type: 0, - name: 'JetBrains', - logo: 'jetbrains', - link: 'https://blog.jetbrains.com/teamcity/2017/10/teamcity-kubernetes-support-plugin/', - blurb: 'Run TeamCity cloud build agents in a Kubernetes cluster. Provides Helm support as a build step.' - }, - { - type: 2, - name: 'Opensense', - logo: 'opensense', - link: 'http://www.opensense.fr/en/kubernetes-en/', - blurb: 'We provide Kubernetes services (integration, operation, training) as well as development of banking microservices based on our extended experience with cloud of containers, microservices, data management and financial sector.' - }, - { - type: 2, - name: 'SAP SE', - logo: 'sap', - link: 'https://cloudplatform.sap.com', - blurb: 'The SAP Cloud Platform provides in-memory capabilities and unique business services for building and extending applications. With open sourced Project Gardener, SAP utilizes the power of Kubernetes to enable an open, robust, multi-cloud experience for our customers. You can use simple, modern cloud native design principles and leverage skills your organization already has to deliver agile and transformative applications, while integrating with the latest SAP Leonardo business features.' - }, - { - type: 1, - name: 'Mobilise Cloud Services Limited', - logo: 'mobilise', - link: 'https://www.mobilise.cloud/en/services/serverless-application-delivery/', - blurb: 'Mobilise helps organisations adopt Kubernetes and integrate with their CI/CD tooling.' - }, - { - type: 3, - name: 'AWS', - logo: 'aws', - link: 'https://aws.amazon.com/eks/', - blurb: 'Amazon Elastic Container Service for Kubernetes (Amazon EKS) is a managed service that makes it easy for you to run Kubernetes on AWS without needing to install and operate your own Kubernetes clusters.' - }, - { - type: 3, - name: 'Kontena', - logo: 'kontena', - link: 'https://pharos.sh', - blurb: 'Kontena Pharos - The simple, solid, certified Kubernetes distribution that just works.' - }, - { - type: 2, - name: 'NTTData', - logo: 'nttdata', - link: 'http://de.nttdata.com/altemista-cloud', - blurb: 'NTT DATA, a member of the NTT Group, brings the power of the worlds leading infrastructure provider in the global K8s community.' - }, - { - type: 2, - name: 'OCTO', - logo: 'octo', - link: 'https://www.octo.academy/fr/formation/275-kubernetes-utiliser-architecturer-et-administrer-une-plateforme-de-conteneurs', - blurb: 'OCTO technology provides training, architecture, technical consulting and delivery services including containers and Kubernetes.' - }, - { - type: 0, - name: 'Logdna', - logo: 'logdna', - link: 'https://logdna.com/kubernetes', - blurb: 'Pinpoint production issues instantly with LogDNA, the best logging platform you will ever use. Get started with only 2 kubectl commands.' - } - ] - - var kcspContainer = document.getElementById('kcspContainer') - var distContainer = document.getElementById('distContainer') - var ktpContainer = document.getElementById('ktpContainer') - var isvContainer = document.getElementById('isvContainer') - var servContainer = document.getElementById('servContainer') - - var sorted = partners.sort(function (a, b) { - if (a.name > b.name) return 1 - if (a.name < b.name) return -1 - return 0 - }) - - sorted.forEach(function (obj) { - var box = document.createElement('div') - box.className = 'partner-box' - - var img = document.createElement('img') - img.src = '/images/square-logos/' + obj.logo + '.png' - - var div = document.createElement('div') - - var p = document.createElement('p') - p.textContent = obj.blurb - - var link = document.createElement('a') - link.href = obj.link - link.target = '_blank' - link.textContent = 'Learn more' - - div.appendChild(p) - div.appendChild(link) - - box.appendChild(img) - box.appendChild(div) - - var container; - if (obj.type === 0) { - container = isvContainer; - } else if (obj.type === 1) { - container = servContainer; - } else if (obj.type === 2) { - container = kcspContainer; - } else if (obj.type === 3) { - container = distContainer; - } else if (obj.type === 4) { - container = ktpContainer; - } - - container.appendChild(box) - }) -})(); diff --git a/content/en/partners/_index.html b/content/en/partners/_index.html index c652514ac4..7925e03188 100644 --- a/content/en/partners/_index.html +++ b/content/en/partners/_index.html @@ -95,8 +95,4 @@ cid: partners <style> {{< include "partner-style.css" >}} -</style> - -<script> - {{< include "partner-script.js" >}} -</script> +</style> \ No newline at end of file diff --git a/content/es/_index.html b/content/es/_index.html index cf19b195cd..8aecd07aaf 100644 --- a/content/es/_index.html +++ b/content/es/_index.html @@ -4,8 +4,6 @@ abstract: "Automatización del despliegue, escalado y administración de contene cid: home --- -{{< deprecationwarning >}} - {{< blocks/section id="oceanNodes" >}} {{% blocks/feature image="flower" %}} ### Kubernetes (K8s) es una plataforma de código abierto para automatizar la implementación, el escalado y la administración de aplicaciones en contenedores. @@ -57,4 +55,4 @@ Kubernetes es código abierto lo que le brinda la libertad de aprovechar su infr </div> {{< /blocks/section >}} -{{< blocks/case-studies >}} +{{< blocks/case-studies >}} \ No newline at end of file diff --git a/content/es/docs/concepts/_index.md b/content/es/docs/concepts/_index.md index fddd126047..7dd7709bae 100644 --- a/content/es/docs/concepts/_index.md +++ b/content/es/docs/concepts/_index.md @@ -17,11 +17,11 @@ La sección de conceptos te ayudará a conocer los componentes de Kubernetes as En Kubernetes se utilizan los *objetos de la API de Kubernetes* para describir el *estado deseado* del clúster: qué aplicaciones u otras cargas de trabajo se quieren ejecutar, qué imagenes de contenedores usan, el número de replicas, qué red y qué recursos de almacenamiento quieres que tengan disponibles, etc. Se especifica el estado deseado del clúster mediante la creación de objetos usando la API de Kubernetes, típicamente mediante la interfaz de línea de comandos, `kubectl`. También se puede usar la API de Kubernetes directamente para interactuar con el clúster y especificar o modificar tu estado deseado. -Una vez que se especifica el estado deseado, el *Plano de Control de Kubernetes* realizará las acciones necesarias para que el estado actual del clúster coincida con el estado deseado. Para ello, Kubernetes realiza diferentes tareas de forma automática, como pueden ser: parar o arrancar contenedores, escalar el número de réplicas de una aplicación dada, etc. El Plano de Control de Kubernetes consiste en un grupo de procesos que corren en tu clúster: +Una vez que se especifica el estado deseado, el *Plano de Control de Kubernetes* realizará las acciones necesarias para que el estado actual del clúster coincida con el estado deseado. Para ello, Kubernetes realiza diferentes tareas de forma automática, como pueden ser: parar o arrancar contenedores, escalar el número de réplicas de una aplicación dada, etc. El Plano de Control de Kubernetes consiste en un grupo de daemons que corren en tu clúster: -* El **Master de Kubernetes** es un conjunto de tres procesos que se ejecutan en un único nodo del clúster, que se denomina nodo master. Estos procesos son: [kube-apiserver](/docs/admin/kube-apiserver/), [kube-controller-manager](/docs/admin/kube-controller-manager/) y [kube-scheduler](/docs/admin/kube-scheduler/). +* El **Master de Kubernetes** es un conjunto de tres daemons que se ejecutan en un único nodo del clúster, que se denomina nodo master. Estos daemons son: [kube-apiserver](/docs/admin/kube-apiserver/), [kube-controller-manager](/docs/admin/kube-controller-manager/) y [kube-scheduler](/docs/admin/kube-scheduler/). -* Los restantes nodos no master contenidos en tu clúster, ejecutan los siguientes dos procesos: +* Los restantes nodos no master contenidos en tu clúster, ejecutan los siguientes dos daemons: * **[kubelet](/docs/admin/kubelet/)**, el cual se comunica con el Master de Kubernetes. * **[kube-proxy](/docs/admin/kube-proxy/)**, un proxy de red que implementa los servicios de red de Kubernetes en cada nodo. @@ -55,7 +55,7 @@ Por ejemplo, cuando usas la API de Kubernetes para crear un Deployment, estás p El Master de Kubernetes es el responsable de mantener el estado deseado de tu clúster. Cuando interactuas con Kubernetes, como por ejemplo cuando utilizas la interfaz de línea de comandos `kubectl`, te estás comunicando con el master de tu clúster de Kubernetes. -> Por "master" entendemos la colección de procesos que gestionan el estado del clúster. Típicamente, estos procesos se ejecutan todos en un único nodo del clúster, y este nodo recibe por tanto la denominación de master. El master puede estar replicado por motivos de disponibilidad y redundancia. +> Por "master" entendemos la colección de daemons que gestionan el estado del clúster. Típicamente, estos daemons se ejecutan todos en un único nodo del clúster, y este nodo recibe por tanto la denominación de master. El master puede estar replicado por motivos de disponibilidad y redundancia. ### Kubernetes Nodes diff --git a/content/es/docs/concepts/configuration/configmap.md b/content/es/docs/concepts/configuration/configmap.md new file mode 100644 index 0000000000..b607f0b82d --- /dev/null +++ b/content/es/docs/concepts/configuration/configmap.md @@ -0,0 +1,253 @@ +--- +title: ConfigMaps +content_type: concept +weight: 20 +--- + +<!-- overview --> + +{{< glossary_definition term_id="configmap" prepend="Un configmap es " length="all" >}} + +{{< caution >}} +ConfigMap no proporciona encriptación. +Si los datos que quieres almacenar son confidenciales, utiliza un +{{< glossary_tooltip text="Secret" term_id="secret" >}} en lugar de un ConfigMap, +o utiliza otras herramientas externas para mantener los datos seguros. +{{< /caution >}} + + + +<!-- body --> +## Motivo + +Utiliza un ConfigMap para crear una configuración separada del código de la aplicación. + +Por ejemplo, imagina que estás desarrollando una aplicación que puedes correr en +tu propio equipo (para desarrollo) y en el cloud (para mantener tráfico real). +Escribes el código para configurar una variable llamada `DATABASE_HOST`. +En tu equipo configuras la variable con el valor `localhost`. +En el cloud, la configuras con referencia a un kubernetes +{{< glossary_tooltip text="Service" term_id="service" >}} que expone el componente +de la base de datos en tu cluster. + +Esto permite tener una imagen corriendo en un cloud y +tener el mismo código localmente para checkearlo si es necesario. + +## Objeto ConfigMap + +Un ConfigMap es un [objeto](/docs/concepts/overview/working-with-objects/kubernetes-objects/) de la API +que permite almacenar la configuración de otros objetos utilizados. Aunque muchos +objetos de kubernetes que tienen un `spec`, un ConfigMap tiene una sección `data` para +almacenar items, identificados por una clave, y sus valores. + +El nombre del ConfigMap debe ser un +[nombre de subdominio DNS](/docs/concepts/overview/working-with-objects/names#dns-subdomain-names) válido. + +## ConfigMaps y Pods + +Puedes escribir un Pod `spec` y referenciarlo a un ConfigMap y configurar el contenedor(es) +de ese {{< glossary_tooltip text="Pod" term_id="pod" >}} en base a los datos del ConfigMap. El {{< glossary_tooltip text="Pod" term_id="pod" >}} y el ConfigMap deben estar en +el mismo {{< glossary_tooltip text="Namespace" term_id="namespace" >}}. + +Este es un ejemplo de ConfigMap que tiene algunas claves con un valor simple, +y otras claves donde el valor tiene un formato de un fragmento de configuración. + +```yaml +apiVersion: v1 +kind: ConfigMap +metadata: + name: game-demo +data: + # property-like keys; each key maps to a simple value + player_initial_lives: "3" + ui_properties_file_name: "user-interface.properties" + # + # file-like keys + game.properties: | + enemy.types=aliens,monsters + player.maximum-lives=5 + user-interface.properties: | + color.good=purple + color.bad=yellow + allow.textmode=true +``` +Hay cuatro maneras diferentes de usar un ConfigMap para configurar +un contenedor dentro de un {{< glossary_tooltip text="Pod" term_id="pod" >}}: + +1. Argumento en la linea de comandos como entrypoint de un contenedor +1. Variable de enorno de un contenedor +1. Como fichero en un volumen de solo lectura, para que lo lea la aplicación +1. Escribir el código para ejecutar dentro de un {{< glossary_tooltip text="Pod" term_id="pod" >}} que utiliza la API para leer el ConfigMap + +Estos diferentes mecanismos permiten utilizar diferentes métodos para modelar +los datos que se van a usar. +Para los primeros tres mecanismos, el +{{< glossary_tooltip text="kubelet" term_id="kubelet" >}} utiliza la información +del ConfigMap cuando lanza un contenedor (o varios) en un {{< glossary_tooltip text="Pod" term_id="pod" >}}. + +Para el cuarto método, tienes que escribir el código para leer el ConfigMap y sus datos. +Sin embargo, como estás utilizando la API de kubernetes directamente, la aplicación puede +suscribirse para obtener actualizaciones cuando el ConfigMap cambie, y reaccionar +cuando esto ocurra. Accediendo directamente a la API de kubernetes, esta +técnica también permite acceder al ConfigMap en diferentes namespaces. + +En el siguiente ejemplo el Pod utiliza los valores de `game-demo` para configurar el contenedor: +```yaml +apiVersion: v1 +kind: Pod +metadata: + name: configmap-demo-pod +spec: + containers: + - name: demo + image: game.example/demo-game + env: + # Define the environment variable + - name: PLAYER_INITIAL_LIVES # Notice that the case is different here + # from the key name in the ConfigMap. + valueFrom: + configMapKeyRef: + name: game-demo # The ConfigMap this value comes from. + key: player_initial_lives # The key to fetch. + - name: UI_PROPERTIES_FILE_NAME + valueFrom: + configMapKeyRef: + name: game-demo + key: ui_properties_file_name + volumeMounts: + - name: config + mountPath: "/config" + readOnly: true + volumes: + # You set volumes at the Pod level, then mount them into containers inside that Pod + - name: config + configMap: + # Provide the name of the ConfigMap you want to mount. + name: game-demo + # An array of keys from the ConfigMap to create as files + items: + - key: "game.properties" + path: "game.properties" + - key: "user-interface.properties" + path: "user-interface.properties" +``` + + +Un ConfigMap no diferencia entre las propiedades de una linea individual y +un fichero con múltiples lineas y valores. +Lo importante es como los {{< glossary_tooltip text="Pods" term_id="pod" >}} y otros objetos consumen estos valores. + +Para este ejemplo, definimos un {{< glossary_tooltip text="Volumen" term_id="volume" >}} y lo montamos dentro del contenedor +`demo` como `/config` creando dos ficheros, +`/config/game.properties` y `/config/user-interface.properties`, +aunque haya cuatro claves en el ConfigMap. Esto es debido a que enla definición +del {{< glossary_tooltip text="Pod" term_id="pod" >}} se especifica el array `items` en la sección `volumes`. +Si quieres omitir el array `items` entero, cada clave del ConfigMap se convierte en +un fichero con el mismo nombre que la clave, y tienes 4 ficheros. + +## Usando ConfigMaps + +Los ConfigMaps pueden montarse como volúmenes. También pueden ser utilizados por otras +partes del sistema, sin ser expuestos directamente al {{< glossary_tooltip text="Pod" term_id="pod" >}}. Por ejemplo, +los ConfigMaps pueden contener información para que otros elementos del sistema utilicen +para su configuración. + +{{< note >}} +La manera más común de usar los Configmaps es para configurar +los contenedores que están corriendo en un {{< glossary_tooltip text="Pod" term_id="pod" >}} en el mismo {{< glossary_tooltip text="Namespace" term_id="namespace" >}}. +También se pueden usar por separado. + +Por ejemplo, +quizá encuentres {{< glossary_tooltip text="AddOns" term_id="addons" >}} +u {{< glossary_tooltip text="Operadores" term_id="operator-pattern" >}} que +ajustan su comportamiento en base a un ConfigMap. +{{< /note >}} + +### Usando ConfigMaps como ficheros en un Pod + +Para usar un ConfigMap en un volumen en un {{< glossary_tooltip text="Pod" term_id="pod" >}}: + +1. Crear un ConfigMap o usar uno que exista. Múltiples {{< glossary_tooltip text="Pods" term_id="pod" >}} pueden utilizar el mismo ConfigMap. +1. Modifica la configuración del {{< glossary_tooltip text="Pod" term_id="pod" >}} para añadir el volumen en `.spec.volumes[]`. Pon cualquier nombre al {{< glossary_tooltip text="Volumen" term_id="volume" >}}, y tienes un campo `.spec.volumes[].configMap.name` configurado con referencia al objeto ConfigMap. +1. Añade un `.spec.containers[].volumeMounts[]` a cada contenedor que necesite el ConfigMap. Especifica `.spec.containers[].volumeMounts[].readOnly = true` y `.spec.containers[].volumeMounts[].mountPath` en un directorio sin uso donde quieras que aparezca el ConfigMap. +1. Modifica la imagen o el comando utilizado para que el programa busque los ficheros en el directorio. Cada clave del ConfigMap `data` se convierte en un un fichero en el `mountPath`. + +En este ejemplo, el {{< glossary_tooltip text="Pod" term_id="pod" >}} monta un ConfigMap como un {{< glossary_tooltip text="volumen" term_id="volume" >}}: + +```yaml +apiVersion: v1 +kind: Pod +metadata: + name: mypod +spec: + containers: + - name: mypod + image: redis + volumeMounts: + - name: foo + mountPath: "/etc/foo" + readOnly: true + volumes: + - name: foo + configMap: + name: myconfigmap +``` + +Cada ConfigMap que quieras utilizar debe estar referenciado en `.spec.volumes`. + +Si hay múltiples contenedores en el {{< glossary_tooltip text="Pod" term_id="pod" >}}, cada contenedor tiene su propio +bloque `volumeMounts`, pero solo un `.spec.volumes` es necesario por cada ConfigMap. + +#### ConfigMaps montados son actualizados automáticamente + +Cuando un ConfigMap está siendo utilizado en un {{< glossary_tooltip text="volumen" term_id="volume" >}} y es actualizado, las claves son actualizadas también. +El {{< glossary_tooltip text="kubelet" term_id="kubelet" >}} comprueba si el ConfigMap montado está actualizado cada periodo de sincronización. +Sin embargo, el {{< glossary_tooltip text="kubelet" term_id="kubelet" >}} utiliza su caché local para obtener el valor actual del ConfigMap. +El tipo de caché es configurable usando el campo `ConfigMapAndSecretChangeDetectionStrategy` en el +[KubeletConfiguration struct](https://github.com/kubernetes/kubernetes/blob/{{< param "docsbranch" >}}/staging/src/k8s.io/kubelet/config/v1beta1/types.go). +Un ConfigMap puede ser propagado por vista (default), ttl-based, o simplemente redirigiendo +todas las consultas directamente a la API. +Como resultado, el retraso total desde el momento que el ConfigMap es actualizado hasta el momento +que las nuevas claves son proyectadas en el {{< glossary_tooltip text="Pod" term_id="pod" >}} puede ser tan largo como la sincronización del {{< glossary_tooltip text="Pod" term_id="pod" >}} ++ el retraso de propagación de la caché, donde la propagación de la caché depende del tipo de +caché elegido (es igual al retraso de propagación, ttl de la caché, o cero correspondientemente). + +{{< feature-state for_k8s_version="v1.18" state="alpha" >}} + +La característica alpha de kubernetes _Immutable Secrets and ConfigMaps_ provee una opción para configurar +{{< glossary_tooltip text="Secrets" term_id="secret" >}} individuales y ConfigMaps como inmutables. Para los {{< glossary_tooltip text="Clústeres" term_id="cluster" >}} que usan ConfigMaps como extensión +(al menos decenas o cientos de un único ConfigMap montado en {{< glossary_tooltip text="Pods" term_id="pod" >}}), previene cambios en sus +datos con las siguientes ventajas: + +- protección de actualizaciones accidentales (o no deseadas) que pueden causar caídas de aplicaciones +- mejora el rendimiento del {{< glossary_tooltip text="Clúster" term_id="cluster" >}} significativamente reduciendo la carga del {{< glossary_tooltip text="kube-apiserver" term_id="kube-apiserver" >}}, +cerrando las vistas para el ConfigMap marcado como inmutable. + +Para usar esta característica, habilita el `ImmutableEmphemeralVolumes` +[feature gate](/docs/reference/command-line-tools-reference/feature-gates/) y configura +el campo del {{< glossary_tooltip text="Secret" term_id="secret" >}} o ConfigMap `immutable` como `true`. Por ejemplo: +```yaml +apiVersion: v1 +kind: ConfigMap +metadata: + ... +data: + ... +immutable: true +``` + +{{< note >}} +Una vez que un ConfigMap o un {{< glossary_tooltip text="Secret" term_id="secret" >}} es marcado como inmutable, _no_ es posible revertir el cambio +ni cambiar el contenido del campo `data`. Solo se puede eliminar y recrear el ConfigMap. +Los {{< glossary_tooltip text="Pods" term_id="pod" >}} existentes mantiene un punto de montaje del ConfigMap eliminado - es recomendable +recrear los {{< glossary_tooltip text="Pods" term_id="pod" >}}. +{{< /note >}} + + +## {{% heading "whatsnext" %}} + + +* Leer sobre [Secrets](/docs/concepts/configuration/secret/). +* Leer [Configure a Pod to Use a ConfigMap](/docs/tasks/configure-pod-container/configure-pod-configmap/). +* Leer [The Twelve-Factor App](https://12factor.net/) para entender el motivo de separar + el código de la configuración. diff --git a/content/es/docs/concepts/configuration/pod-overhead.md b/content/es/docs/concepts/configuration/pod-overhead.md new file mode 100644 index 0000000000..0d7a89bcd6 --- /dev/null +++ b/content/es/docs/concepts/configuration/pod-overhead.md @@ -0,0 +1,41 @@ +--- +reviewers: +- raelga +title: Sobrecarga de Pod +content_type: concept +weight: 20 +--- + +<!-- overview --> + +{{< feature-state for_k8s_version="v1.16" state="alpha" >}} + +Cuando se está ejecutando un {{< glossary_tooltip text="Pod" term_id="pod" >}} en un {{< glossary_tooltip text="nodo" term_id="node" >}}, el Pod por sí mismo utiliza una cantidad de recursos del sistema. Estos recursos son adicionales a los recursos necesarios para hacer funcionar el/los contenedor(es) dentro del Pod. +La _Sobrecarga de Pod_ es una característica para contabilizar los recursos consumidos por la infraestructura de Pods que están por encima de los valores de _Requests_ y _Limits_ del/los contenedor(es). + +<!-- body --> + +## Sobrecarga de Pod + +En Kubernetes, la sobrecarga de {{< glossary_tooltip text="Pod" term_id="pod" >}} se configura en el tiempo de [admisión](/docs/reference/access-authn-authz/extensible-admission-controllers/#what-are-admission-webhooks) con respecto a la sobrecarga asociada con el [RuntimeClass](/docs/concepts/containers/runtime-class/) del Pod. + +Cuando se habilita la opción de sobrecarga de {{< glossary_tooltip text="Pod" term_id="pod" >}}, se considera tanto la propia sobrecarga como la suma de solicitudes de recursos del contenedor al programar el {{< glossary_tooltip text="Pod" term_id="pod" >}}. Del mismo modo, {{< glossary_tooltip text="Kubelet" term_id="kubelet" >}} incluirá la sobrecarga de {{< glossary_tooltip text="Pod" term_id="pod" >}} cuando se dimensione el cgroup del {{< glossary_tooltip text="Pod" term_id="pod" >}}, y cuando se realice la clasificación de la expulsión de {{< glossary_tooltip text="Pods" term_id="pod" >}}. + +### Configuración + +Debe asegurarse de que el [Feature Gate](/docs/reference/command-line-tools-reference/feature-gates/) `PodOverhead` esté activado (su valor está desactivado de manera predeterminada) en todo el {{< glossary_tooltip text="clúster" term_id="cluster" >}}. Esto significa: + +- en el {{< glossary_tooltip text="kube-scheduler" term_id="kube-scheduler" >}} +- en el {{< glossary_tooltip text="kube-apiserver" term_id="kube-apiserver" >}} +- en el {{< glossary_tooltip text="kubelet" term_id="kubelet" >}} de cada {{< glossary_tooltip text="nodo" term_id="node" >}} +- en cualquier servidor de API personalizado que necesite [Feature Gates](/docs/reference/command-line-tools-reference/feature-gates/). + +{{< note >}} +Los usuarios que pueden escribir recursos del tipo RuntimeClass podrían impactar y poner en riesgo el rendimiento de la carga de trabajo en todo el {{< glossary_tooltip text="clúster" term_id="cluster" >}}. Por ello, se puede limitar el acceso a esta característica usando los controles de acceso de Kubernetes. +Para obtener más detalles vea la [documentación sobre autorización](/docs/reference/access-authn-authz/authorization/). +{{< /note >}} + +<!-- whatsnext --> + +* [RuntimeClass](/docs/concepts/containers/runtime-class/) +* [PodOverhead Design](https://github.com/kubernetes/enhancements/blob/master/keps/sig-node/20190226-pod-overhead.md) diff --git a/content/es/docs/concepts/overview/components.md b/content/es/docs/concepts/overview/components.md new file mode 100644 index 0000000000..64622eeb66 --- /dev/null +++ b/content/es/docs/concepts/overview/components.md @@ -0,0 +1,117 @@ +--- +reviewers: +- raelga +title: Componentes de Kubernetes +content_type: concept +weight: 20 +card: + name: concepts + weight: 20 +--- + +<!-- overview --> + +Este documento describe los distintos componentes que +son necesarios para operar un clúster de Kubernetes. + +<!-- body --> + +## Componentes del plano de control + +Los componentes que forman el plano de control toman decisiones globales sobre +el clúster (por ejemplo, la planificación) y detectan y responden a eventos del clúster, como la creación +de un nuevo pod cuando la propiedad `replicas` de un controlador de replicación no se cumple. + +Estos componentes pueden ejecutarse en cualquier nodo del clúster. Sin embargo para simplificar, los +scripts de instalación típicamente se inician en el mismo nodo de forma exclusiva, +sin que se ejecuten contenedores de los usuarios en esos nodos. El plano de control se ejecuta en varios nodos +para garantizar la [alta disponibilidad](/docs/admin/high-availability/). + +### kube-apiserver + +{{< glossary_definition term_id="kube-apiserver" length="all" >}} + +### etcd + +{{< glossary_definition term_id="etcd" length="all" >}} + +### kube-scheduler + +{{< glossary_definition term_id="kube-scheduler" length="all" >}} + +### kube-controller-manager + +{{< glossary_definition term_id="kube-controller-manager" length="all" >}} + +Estos controladores incluyen: + + * Controlador de nodos: es el responsable de detectar y responder cuándo un nodo deja de funcionar + * Controlador de replicación: es el responsable de mantener el número correcto de pods para cada controlador + de replicación del sistema + * Controlador de endpoints: construye el objeto `Endpoints`, es decir, hace una unión entre los `Services` y los `Pods` + * Controladores de tokens y cuentas de servicio: crean cuentas y tokens de acceso a la API por defecto para los nuevos {{< glossary_tooltip text="Namespaces" term_id="namespace">}}. + +### cloud-controller-manager + +[cloud-controller-manager](/docs/tasks/administer-cluster/running-cloud-controller/) ejecuta controladores que +interactúan con proveedores de la nube. El binario `cloud-controller-manager` es una característica alpha que se introdujo en la versión 1.6 de Kubernetes. + +`cloud-controller-manager` sólo ejecuta ciclos de control específicos para cada proveedor de la nube. Es posible +desactivar estos ciclos en `kube-controller-manager` pasando la opción `--cloud-provider= external` cuando se arranque el `kube-controller-manager`. + +`cloud-controller-manager` permite que el código de Kubernetes y el del proveedor de la nube evolucionen de manera independiente. Anteriormente, el código de Kubernetes dependía de la funcionalidad específica de cada proveedor de la nube. En el futuro, el código que sea específico a una plataforma debería ser mantenido por el proveedor de la nube y enlazado a `cloud-controller-manager` al correr Kubernetes. + +Los siguientes controladores dependen de alguna forma de un proveedor de la nube: + + * Controlador de nodos: es el responsable de detectar y actuar cuándo un nodo deja de responder + * Controlador de rutas: para configurar rutas en la infraestructura de nube subyacente + * Controlador de servicios: para crear, actualizar y eliminar balanceadores de carga en la nube + * Controlador de volúmenes: para crear, conectar y montar volúmenes e interactuar con el proveedor de la nube para orquestarlos + +## Componentes de nodo + +Los componentes de nodo corren en cada nodo, manteniendo a los pods en funcionamiento y proporcionando el entorno de ejecución de Kubernetes. + +### kubelet + +{{< glossary_definition term_id="kubelet" length="all" >}} + +### kube-proxy + +[kube-proxy](/docs/admin/kube-proxy/) permite abstraer un servicio en Kubernetes manteniendo las +reglas de red en el anfitrión y haciendo reenvío de conexiones. + +### Runtime de contenedores + +El {{< glossary_tooltip term_id="container-runtime" text="runtime de los contenedores" >}} es el software responsable de ejecutar los contenedores. Kubernetes soporta varios de +ellos: [Docker](http://www.docker.com), [containerd](https://containerd.io), [cri-o](https://cri-o.io/), [rktlet](https://github.com/kubernetes-incubator/rktlet) y cualquier implementación de la interfaz de runtime de contenedores de Kubernetes, o [Kubernetes CRI](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-node/container-runtime-interface.md). + +## Addons + +Los _addons_ son pods y servicios que implementan funcionalidades del clúster. Estos pueden ser administrados +por `Deployments`, `ReplicationControllers` y otros. Los _addons_ asignados a un espacio de nombres se crean en el espacio `kube-system`. + +Más abajo se describen algunos _addons_. Para una lista más completa de los _addons_ disponibles, por favor visite [Addons](/docs/concepts/cluster-administration/addons/). + +### DNS + +Si bien los otros _addons_ no son estrictamente necesarios, todos los clústers de Kubernetes deberían tener un [DNS interno del clúster](/docs/concepts/services-networking/dns-pod-service/) ya que la mayoría de los ejemplos lo requieren. + +El DNS interno del clúster es un servidor DNS, adicional a los que ya podrías tener en tu red, que sirve registros DNS a los servicios de Kubernetes. + +Los contenedores que son iniciados por Kubernetes incluyen automáticamente este servidor en sus búsquedas DNS. + +### Interfaz Web (Dashboard) {#dashboard} + +El [Dashboard](/docs/tasks/access-application-cluster/web-ui-dashboard/) es una interfaz Web de propósito general para clústeres de Kubernetes. Le permite a los usuarios administrar y resolver problemas que puedan presentar tanto las aplicaciones como el clúster. + +### Monitor de recursos de contenedores + +El [Monitor de recursos de contenedores](/docs/tasks/debug-application-cluster/resource-usage-monitoring/) almacena +de forma centralizada series de tiempo con métricas sobre los contenedores, y provee una interfaz para navegar estos +datos. + +### Registros del clúster + +El mecanismo de [registros del clúster](/docs/concepts/cluster-administration/logging/) está a cargo de almacenar +los registros de los contenedores de forma centralizada, proporcionando una interfaz de búsqueda y navegación. diff --git a/content/es/docs/concepts/overview/working-with-objects/namespaces.md b/content/es/docs/concepts/overview/working-with-objects/namespaces.md index b3c3c73e14..8cd9133f9a 100644 --- a/content/es/docs/concepts/overview/working-with-objects/namespaces.md +++ b/content/es/docs/concepts/overview/working-with-objects/namespaces.md @@ -99,7 +99,7 @@ debes utilizar el nombre cualificado completo de dominio (FQDN). La mayoría de los recursos de Kubernetes (ej. pods, services, replication controllers, y otros) están en algunos espacios de nombres. Sin embargo, los recursos que representan a los propios espacios de nombres no están a su vez en espacios de nombres. -De forma similar, los recursos de bajo nivel, como los nodos [nodos](/docs/admin/node) y +De forma similar, los recursos de bajo nivel, como los [nodos](/docs/admin/node) y los volúmenes persistentes, no están en ningún espacio de nombres. Para comprobar qué recursos de Kubernetes están y no están en un espacio de nombres: diff --git a/content/es/docs/concepts/workloads/controllers/deployment.md b/content/es/docs/concepts/workloads/controllers/deployment.md new file mode 100644 index 0000000000..89563b3b72 --- /dev/null +++ b/content/es/docs/concepts/workloads/controllers/deployment.md @@ -0,0 +1,1110 @@ +--- +title: Deployment +feature: + title: Despliegues y _rollback_ automáticos + description: > + Kubernetes despliega los cambios a tu aplicación o su configuración de forma progresiva mientras monitoriza la salud de la aplicación para asegurarse que no elimina todas tus instancias al mismo tiempo. Si algo sale mal, Kubernetes revertirá el cambio por ti. Aprovéchate del creciente ecosistema de soluciones de despliegue. + +content_type: concept +weight: 30 +--- + +<!-- overview --> + +Un controlador de _Deployment_ proporciona actualizaciones declarativas para los [Pods](/docs/concepts/workloads/pods/pod/) y los +[ReplicaSets](/docs/concepts/workloads/controllers/replicaset/). + +Cuando describes el _estado deseado_ en un objeto Deployment, el controlador del Deployment se encarga de cambiar el estado actual al estado deseado de forma controlada. +Puedes definir Deployments para crear nuevos ReplicaSets, o eliminar Deployments existentes y adoptar todos sus recursos con nuevos Deployments. + +{{< note >}} +No deberías gestionar directamente los ReplicaSets que pertenecen a un Deployment. +Todos los casos de uso deberían cubrirse manipulando el objeto Deployment. +Considera la posibilidad de abrir un incidente en el repositorio principal de Kubernetes si tu caso de uso no está soportado por el motivo que sea. +{{< /note >}} + + + + +<!-- body --> + +## Casos de uso + +A continuación se presentan los casos de uso típicos de los Deployments: + +* [Crear un Deployment para desplegar un ReplicaSet](#creating-a-deployment). El ReplicaSet crea los Pods en segundo plano. Comprueba el estado del despliegue para comprobar si es satisfactorio o no. +* [Declarar el nuevo estado de los Pods](#updating-a-deployment) actualizando el PodTemplateSpec del Deployment. Ello crea un nuevo ReplicaSet y el Deployment gestiona el cambio de los Pods del viejo ReplicaSet al nuevo de forma controlada. Cada nuevo ReplicaSet actualiza la revisión del Deployment. +* [Retroceder a una revisión anterior del Deployment](#rolling-back-a-deployment) si el estado actual de un Deployment no es estable. Cada retroceso actualiza la revisión del Deployment. +* [Escalar horizontalmente el Deployment para soportar más carga](#scaling-a-deployment). +* [Pausar el Deployment](#pausing-and-resuming-a-deployment) para aplicar múltiples arreglos a su PodTemplateSpec y, a continuación, reanúdalo para que comience un nuevo despliegue. +* [Usar el estado del Deployment](#deployment-status) como un indicador de que el despliegue se ha atascado. +* [Limpiar los viejos ReplicaSets](#clean-up-policy) que no necesites más. + +## Crear un Deployment + +El siguiente ejemplo de un Deployment crea un ReplicaSet para arrancar tres Pods con `nginx`: + +{{< codenew file="controllers/nginx-deployment.yaml" >}} + +En este ejemplo: + +* Se crea un Deployment denominado `nginx-deployment`, indicado a través del campo `.metadata.name`. +* El Deployment crea tres Pods replicados, indicado a través del campo `replicas`. +* El campo `selector` define cómo el Deployment identifica los Pods que debe gestionar. + En este caso, simplemente seleccionas una etiqueta que se define en la plantilla Pod (`app: nginx`). + Sin embargo, es posible definir reglas de selección más sofisticadas, + siempre que la plantilla Pod misma satisfaga la regla. + + {{< note >}} + `matchLabels` es un mapa de entradas {clave,valor}. Una entrada simple {clave,valor} en el mapa `matchLabels` + es equivalente a un elemento de `matchExpressions` cuyo campo sea la "clave", el operador sea "In", + y la matriz de valores contenga únicamente un "valor". Todos los requisitos se concatenan con AND. + {{< /note >}} + +* El campo `template` contiene los siguientes sub-campos: + * Los Pods se etiquetan como `app: nginx` usando el campo `labels`. + * La especificación de la plantilla Pod, o el campo `.template.spec`, indica + que los Pods ejecutan un contenedor, `nginx`, que utiliza la versión 1.7.9 de la imagen de `nginx` de + [Docker Hub](https://hub.docker.com/). + * Crea un contenedor y lo llamar `nginx` usando el campo `name`. + * Ejecuta la imagen `nginx` en su versión `1.7.9`. + * Abre el puerto `80` para que el contenedor pueda enviar y recibir tráfico. + +Para crear este Deployment, ejecuta el siguiente comando: + +```shell +kubectl apply -f https://k8s.io/examples/controllers/nginx-deployment.yaml +``` + +{{< note >}} +Debes indicar el parámetro `--record` para registrar el comando ejecutado en la anotación de recurso `kubernetes.io/change-cause`. +Esto es útil para futuras introspecciones, por ejemplo para comprobar qué comando se ha ejecutado en cada revisión del Deployment. +{{< /note >}} + +A continuación, ejecuta el comando `kubectl get deployments`. La salida debe ser parecida a la siguiente: + +```shell +NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE +nginx-deployment 3 0 0 0 1s +``` + +Cuando inspeccionas los Deployments de tu clúster, se muestran los siguientes campos: + +* `NAME` enumera los nombre de los Deployments del clúster. +* `DESIRED` muestra el número deseado de _réplicas_ de la aplicación, que se define + cuando se crea el Deployment. Esto se conoce como el _estado deseado_. +* `CURRENT` muestra cuántas réplicas se están ejecutando actualment. +* `UP-TO-DATE` muestra el número de réplicas que se ha actualizado para alcanzar el estado deseado. +* `AVAILABLE` muestra cuántas réplicas de la aplicación están disponibles para los usuarios. +* `AGE` muestra la cantidad de tiempo que la aplicación lleva ejecutándose. + +Nótese cómo los valores de cada campo corresponden a los valores de la especificación del Deployment: + +* El número de réplicas deseadas es 3 de acuerdo con el campo `.spec.replicas`. +* El número de réplicas actuales es 0 de acuerdo con el campo `.status.replicas`. +* El número de réplicas actualizadas es 0 de acuerdo con el campo `.status.updatedReplicas`. +* El número de réplicas disponibles es 0 de acuerdo con el campo `.status.availableReplicas`. + +Para ver el estado del Deployment, ejecuta el comando `kubectl rollout status deployment.v1.apps/nginx-deployment`. Este comando devuelve el siguiente resultado: + +```shell +Waiting for rollout to finish: 2 out of 3 new replicas have been updated... +deployment.apps/nginx-deployment successfully rolled out +``` + +Ejecuta de nuevo el comando `kubectl get deployments` unos segundos más tarde: + +```shell +NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE +nginx-deployment 3 3 3 3 18s +``` + +Fíjate que el Deployment ha creado todas las tres réplicas, y que todas las réplicas están actualizadas (contienen +la última plantilla Pod) y están disponibles (el estado del Pod tiene el valor Ready al menos para el campo `.spec.minReadySeconds` del Deployment). + +Para ver el ReplicaSet (`rs`) creado por el Deployment, ejecuta el comando `kubectl get rs`: + +```shell +NAME DESIRED CURRENT READY AGE +nginx-deployment-75675f5897 3 3 3 18s +``` + +Fíjate que el nombre del ReplicaSet siempre se formatea con el patrón `[DEPLOYMENT-NAME]-[RANDOM-STRING]`. La cadena aleatoria se +genera de forma aleatoria y usa el pod-template-hash como semilla. + +Para ver las etiquetas generadas automáticamente en cada pod, ejecuta el comando `kubectl get pods --show-labels`. Se devuelve la siguiente salida: + +```shell +NAME READY STATUS RESTARTS AGE LABELS +nginx-deployment-75675f5897-7ci7o 1/1 Running 0 18s app=nginx,pod-template-hash=3123191453 +nginx-deployment-75675f5897-kzszj 1/1 Running 0 18s app=nginx,pod-template-hash=3123191453 +nginx-deployment-75675f5897-qqcnn 1/1 Running 0 18s app=nginx,pod-template-hash=3123191453 +``` + +El ReplicaSet creado garantiza que hay tres Pods de `nginx` ejecutándose en todo momento. + +{{< note >}} +En un Deployment, debes especificar un selector apropiado y etiquetas de plantilla Pod (en este caso, +`app: nginx`). No entremezcles etiquetas o selectores con otros controladores (incluyendo otros Deployments y StatefulSets). +Kubernetes no te impide que lo hagas, pero en el caso de que múltiples controladores tengan selectores mezclados, dichos controladores pueden entrar en conflicto y provocar resultados inesperados. +{{< /note >}} + +### Etiqueta pod-template-hash + +{{< note >}} +No cambies esta etiqueta. +{{< /note >}} + +La etiqueta `pod-template-hash` es añadida por el controlador del Deployment a cada ReplicaSet que el Deployment crea o adopta. + +Esta etiqueta garantiza que todos los hijos ReplicaSets de un Deployment no se entremezclan. Se genera mediante una función hash aplicada al `PodTemplate` del ReplicaSet +y usando el resultado de la función hash como el valor de la etiqueta que se añade al selector del ReplicaSet, en las etiquetas de la plantilla Pod, +y en cualquier Pod existente que el ReplicaSet tenga. + +## Actualizar un Deployment + +{{< note >}} +El lanzamiento de un Deployment se activa si y sólo si la plantilla Pod del Deployment (esto es, `.spec.template`) +se cambia, por ejemplo si se actualiza las etiquetas o las imágenes de contenedor de la plantilla. +Otras actualizaciones, como el escalado del Deployment, no conllevan un lanzamiento de despliegue. +{{< /note >}} + +Asumiendo que ahora quieres actualizar los Pods nginx para que usen la imagen `nginx:1.9.1` +en vez de la imagen `nginx:1.7.9`. + +```shell +kubectl --record deployment.apps/nginx-deployment set image deployment.v1.apps/nginx-deployment nginx=nginx:1.9.1 +``` +``` +image updated +``` + +De forma alternativa, puedes `editar` el Deployment y cambiar el valor del campo `.spec.template.spec.containers[0].image` de `nginx:1.7.9` a `nginx:1.9.1`: + +```shell +kubectl edit deployment.v1.apps/nginx-deployment +``` +``` +deployment.apps/nginx-deployment edited +``` + +Para ver el estado del despliegue, ejecuta: + +```shell +kubectl rollout status deployment.v1.apps/nginx-deployment +``` +``` +Waiting for rollout to finish: 2 out of 3 new replicas have been updated... +deployment.apps/nginx-deployment successfully rolled out +``` + +Cuando el despliegue funciona, puede que quieras `obtener` el Deployment: + +```shell +kubectl get deployments +``` +``` +NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE +nginx-deployment 3 3 3 3 36s +``` + +El número de réplicas actualizadas indica que el Deployment ha actualizado las réplicas según la última configuración. +Las réplicas actuales indican el total de réplicas que gestiona este Deployment, y las réplicas disponibles indican +el número de réplicas actuales que están disponibles. + +Puedes ejecutar el comando `kubectl get rs` para ver que el Deployment actualizó los Pods creando un nuevo ReplicaSet y escalándolo +hasta las 3 réplicas, así como escalando el viejo ReplicaSet a 0 réplicas. + +```shell +kubectl get rs +``` +``` +NAME DESIRED CURRENT READY AGE +nginx-deployment-1564180365 3 3 3 6s +nginx-deployment-2035384211 0 0 0 36s +``` + +Si ejecutas el comando `get pods` deberías ver los nuevos Pods: + +```shell +kubectl get pods +``` +``` +NAME READY STATUS RESTARTS AGE +nginx-deployment-1564180365-khku8 1/1 Running 0 14s +nginx-deployment-1564180365-nacti 1/1 Running 0 14s +nginx-deployment-1564180365-z9gth 1/1 Running 0 14s +``` + +La próxima vez que quieras actualizar estos Pods, sólo necesitas actualizar la plantilla Pod del Deployment otra vez. + +El Deployment permite garantizar que sólo un número determinado de Pods puede eliminarse mientras se están actualizando. +Por defecto, garantiza que al menos el 25% menos del número deseado de Pods se está ejecutando (máx. 25% no disponible). + +El Deployment tmabién permite garantizar que sólo un número determinado de Pods puede crearse por encima del número deseado de +Pods. Por defecto, garantiza que al menos el 25% más del número deseado de Pods se está ejecutando (máx. 25% de aumento). + +Por ejemplo, si miras detenidamente el Deployment de arriba, verás que primero creó un Pod, +luego eliminó algunos viejos Pods y creó otros nuevos. No elimina los viejos Pods hasta que un número suficiente de +nuevos Pods han arrancado, y no crea nuevos Pods hasta que un número suficiente de viejos Pods se han eliminado. +De esta forma, asegura que el número de Pods disponibles siempre es al menos 2, y el número de Pods totales es cómo máximo 4. + +```shell +kubectl describe deployments +``` +``` +Name: nginx-deployment +Namespace: default +CreationTimestamp: Thu, 30 Nov 2017 10:56:25 +0000 +Labels: app=nginx +Annotations: deployment.kubernetes.io/revision=2 +Selector: app=nginx +Replicas: 3 desired | 3 updated | 3 total | 3 available | 0 unavailable +StrategyType: RollingUpdate +MinReadySeconds: 0 +RollingUpdateStrategy: 25% max unavailable, 25% max surge +Pod Template: + Labels: app=nginx + Containers: + nginx: + Image: nginx:1.9.1 + Port: 80/TCP + Environment: <none> + Mounts: <none> + Volumes: <none> +Conditions: + Type Status Reason + ---- ------ ------ + Available True MinimumReplicasAvailable + Progressing True NewReplicaSetAvailable +OldReplicaSets: <none> +NewReplicaSet: nginx-deployment-1564180365 (3/3 replicas created) +Events: + Type Reason Age From Message + ---- ------ ---- ---- ------- + Normal ScalingReplicaSet 2m deployment-controller Scaled up replica set nginx-deployment-2035384211 to 3 + Normal ScalingReplicaSet 24s deployment-controller Scaled up replica set nginx-deployment-1564180365 to 1 + Normal ScalingReplicaSet 22s deployment-controller Scaled down replica set nginx-deployment-2035384211 to 2 + Normal ScalingReplicaSet 22s deployment-controller Scaled up replica set nginx-deployment-1564180365 to 2 + Normal ScalingReplicaSet 19s deployment-controller Scaled down replica set nginx-deployment-2035384211 to 1 + Normal ScalingReplicaSet 19s deployment-controller Scaled up replica set nginx-deployment-1564180365 to 3 + Normal ScalingReplicaSet 14s deployment-controller Scaled down replica set nginx-deployment-2035384211 to 0 +``` + +Aquí puedes ver que cuando creaste por primera vez el Deployment, este creó un ReplicaSet (nginx-deployment-2035384211) +y lo escaló a 3 réplicas directamente. Cuando actualizaste el Deployment, creó un nuevo ReplicaSet +(nginx-deployment-1564180365) y lo escaló a 1 y entonces escaló el viejo ReplicaSet a 2, de forma que al menos +hubiera 2 Pods disponibles y como mucho 4 Pods en total en todo momento. Entonces, continuó escalando +el nuevo y el viejo ReplicaSet con la misma estrategia de actualización continua. Finalmente, el nuevo ReplicaSet acaba con 3 réplicas +disponibles, y el viejo ReplicaSet se escala a 0. + +### Sobrescritura (o sea, múltiples actualizaciones a la vez) + +Cada vez que el controlador del Deployment observa un nuevo objeto de despliegue, se crea un ReplicaSet para arrancar +los Pods deseados si es que no existe otro ReplicaSet haciéndolo. Los ReplicaSet existentes que controlan los Pods cuyas etiquetas +coinciden con el valor del campo `.spec.selector`, pero cuya plantilla no coincide con el valor del campo `.spec.template` se reducen. Al final, +el nuevo ReplicaSet se escala hasta el valor del campo `.spec.replicas` y todos los viejos ReplicaSets se escalan a 0. + +Si actualizas un Deployment mientras otro despliegue está en curso, el Deployment creará un nuevo ReplicaSet +como consecuencia de la actualización y comenzará a escalarlo, y sobrescribirá al ReplicaSet que estaba escalando anteriormente + -- lo añadirá a su lista de viejos ReplicaSets y comenzará a reducirlos. + +Por ejemplo, supongamos que creamos un Deployment para crear 5 réplicas de `nginx:1.7.9`, +pero entonces actualizamos el Deployment para crear 5 réplicas de `nginx:1.9.1` cuando sólo se ha creado 3 +réplicas de `nginx:1.7.9`. En este caso, el Deployment comenzará automáticamente a matar los 3 Pods de `nginx:1.7.9` +que había creado, y empezará a crear los Pods de `nginx:1.9.1`. Es decir, no esperará a que se creen las 5 réplicas de `nginx:1.7.9` +antes de aplicar la nueva configuración. + +### Actualizaciones del selector de etiquetas + +No se recomienda hacer cambios al selector del etiquetas y, por ello, se aconseja encarecidamente planificar el valor de dichos selectores por adelantado. +En cualquier caso, si necesitas cambiar un selector de etiquetas, hazlo con mucho cuidado y asegúrate que entiendes todas sus implicaciones. + +{{< note >}} +En la versión `apps/v1` de la API, el selector de etiquetas del Deployment es inmutable una vez se ha creado. +{{< /note >}} + +* Las adiciones posteriores al selector obligan también a actualizar las etiquetas de la plantilla Pod en la especificación del Deployment con los nuevos valores, +ya que de lo contrario se devolvería un error. Este cambio no es de superposición, es decir, que el nuevo selector +no selecciona los ReplicaSets y Pods creados con el viejo selector, lo que provoca que todos los viejos ReplicaSets se marquen como huérfanos y +la creación de un nuevo ReplicaSet. +* Las actualizaciones de selector -- esto es, cambiar el valor actual en una clave de selector -- provocan el mismo comportamiento que las adiciones. +* Las eliminaciones de selector -- esto es, eliminar una clave actual del selector del Deployment -- no necesitan de cambios en las etiquetas de la plantilla Pod. +No se marca ningún ReplicaSet existente como huérfano, y no se crea ningún ReplicaSet nuevo, pero debe tenerse en cuenta que +la etiqueta eliminada todavía existe en los Pods y ReplicaSets que se están ejecutando. + +## Revertir un Deployment + +En ocasiones necesitas revertir un Deployment; por ejemplo, cuando el Deployment no es estable, como cuando no para de reiniciarse. +Por defecto, toda la historia de despliegue del Deployment se mantiene en el sistema de forma que puedes revertir en cualquier momento +(se puede modificar este comportamiento cambiando el límite de la historia de revisiones de modificaciones). + +{{< note >}} +Cuando se lanza el despligue de un Deployment, se crea una nueva revisión. Esto quiere decir que +la nueva revisión se crea si y sólo si la plantilla Pod del Deployment (`.spec.template`) se cambia; +por ejemplo, si cambias las etiquetas o la imagen del contenedor de la plantilla. +Otras actualizaciones, como escalar el Deployment, +no generan una nueva revisión del Deployment, para poder facilitar el escalado manual simultáneo - o auto-escalado. +Esto significa que cuando reviertes a una versión anterior, sólo la parte de la plantilla Pod del Deployment se revierte. +{{< /note >}} + +Vamos a suponer que hemos cometido un error al actualizar el Deployment, poniendo como nombre de imagen `nginx:1.91` en vez de `nginx:1.9.1`: + +```shell +kubectl set image deployment.v1.apps/nginx-deployment nginx=nginx:1.91 --record=true +``` +``` +deployment.apps/nginx-deployment image updated +``` + +El despliegue se atasca y no progresa. + +```shell +kubectl rollout status deployment.v1.apps/nginx-deployment +``` +``` +Waiting for rollout to finish: 1 out of 3 new replicas have been updated... +``` + +Presiona Ctrl-C para detener la monitorización del despliegue de arriba. Para obtener más información sobre despliegues atascados, +[lee más aquí](#deployment-status). + +Verás que el número de réplicas viejas (nginx-deployment-1564180365 y nginx-deployment-2035384211) es 2, y el número de nuevas réplicas (nginx-deployment-3066724191) es 1. + +```shell +kubectl get rs +``` +``` +NAME DESIRED CURRENT READY AGE +nginx-deployment-1564180365 3 3 3 25s +nginx-deployment-2035384211 0 0 0 36s +nginx-deployment-3066724191 1 1 0 6s +``` + +Echando un vistazo a los Pods creados, verás que uno de los Pods creados por el nuevo ReplicaSet está atascado en un bucle intentando bajar la imagen: + +```shell +kubectl get pods +``` +``` +NAME READY STATUS RESTARTS AGE +nginx-deployment-1564180365-70iae 1/1 Running 0 25s +nginx-deployment-1564180365-jbqqo 1/1 Running 0 25s +nginx-deployment-1564180365-hysrc 1/1 Running 0 25s +nginx-deployment-3066724191-08mng 0/1 ImagePullBackOff 0 6s +``` + +{{< note >}} +El controlador del Deployment parará el despliegue erróneo de forma automática, y detendrá el escalado del nuevo +ReplicaSet. Esto depende de los parámetros del rollingUpdate (`maxUnavailable` específicamente) que hayas configurado. +Kubernetes por defecto establece el valor en el 25%. +{{< /note >}} + +```shell +kubectl describe deployment +``` +``` +Name: nginx-deployment +Namespace: default +CreationTimestamp: Tue, 15 Mar 2016 14:48:04 -0700 +Labels: app=nginx +Selector: app=nginx +Replicas: 3 desired | 1 updated | 4 total | 3 available | 1 unavailable +StrategyType: RollingUpdate +MinReadySeconds: 0 +RollingUpdateStrategy: 25% max unavailable, 25% max surge +Pod Template: + Labels: app=nginx + Containers: + nginx: + Image: nginx:1.91 + Port: 80/TCP + Host Port: 0/TCP + Environment: <none> + Mounts: <none> + Volumes: <none> +Conditions: + Type Status Reason + ---- ------ ------ + Available True MinimumReplicasAvailable + Progressing True ReplicaSetUpdated +OldReplicaSets: nginx-deployment-1564180365 (3/3 replicas created) +NewReplicaSet: nginx-deployment-3066724191 (1/1 replicas created) +Events: + FirstSeen LastSeen Count From SubobjectPath Type Reason Message + --------- -------- ----- ---- ------------- -------- ------ ------- + 1m 1m 1 {deployment-controller } Normal ScalingReplicaSet Scaled up replica set nginx-deployment-2035384211 to 3 + 22s 22s 1 {deployment-controller } Normal ScalingReplicaSet Scaled up replica set nginx-deployment-1564180365 to 1 + 22s 22s 1 {deployment-controller } Normal ScalingReplicaSet Scaled down replica set nginx-deployment-2035384211 to 2 + 22s 22s 1 {deployment-controller } Normal ScalingReplicaSet Scaled up replica set nginx-deployment-1564180365 to 2 + 21s 21s 1 {deployment-controller } Normal ScalingReplicaSet Scaled down replica set nginx-deployment-2035384211 to 1 + 21s 21s 1 {deployment-controller } Normal ScalingReplicaSet Scaled up replica set nginx-deployment-1564180365 to 3 + 13s 13s 1 {deployment-controller } Normal ScalingReplicaSet Scaled down replica set nginx-deployment-2035384211 to 0 + 13s 13s 1 {deployment-controller } Normal ScalingReplicaSet Scaled up replica set nginx-deployment-3066724191 to 1 +``` + +Para arreglar este problema, necesitas volver a una revisión previa del Deployment que sea estable. + +### Comprobar la Historia de Despliegues de un Deployment + +Primero, comprobemos las revisiones de este despliegue: + +```shell +kubectl rollout history deployment.v1.apps/nginx-deployment +``` +``` +deployments "nginx-deployment" +REVISION CHANGE-CAUSE +1 kubectl apply --filename=https://k8s.io/examples/controllers/nginx-deployment.yaml --record=true +2 kubectl set image deployment.v1.apps/nginx-deployment nginx=nginx:1.9.1 --record=true +3 kubectl set image deployment.v1.apps/nginx-deployment nginx=nginx:1.91 --record=true +``` +En el momento de la creación, el mensaje en `CHANGE-CAUSE` se copia de la anotación `kubernetes.io/change-cause` del Deployment a sus revisiones. Podrías indicar el mensaje `CHANGE-CAUSE`: + +* Anotando el Deployment con el comando `kubectl annotate deployment.v1.apps/nginx-deployment kubernetes.io/change-cause="image updated to 1.9.1"` +* Añadiendo el parámetro `--record` para registrar el comando `kubectl` que está haciendo cambios en el recurso. +* Manualmente editando el manifiesto del recursos. + +Para ver más detalles de cada revisión, ejecuta: + +```shell +kubectl rollout history deployment.v1.apps/nginx-deployment --revision=2 +``` +``` +deployments "nginx-deployment" revision 2 + Labels: app=nginx + pod-template-hash=1159050644 + Annotations: kubernetes.io/change-cause=kubectl set image deployment.v1.apps/nginx-deployment nginx=nginx:1.9.1 --record=true + Containers: + nginx: + Image: nginx:1.9.1 + Port: 80/TCP + QoS Tier: + cpu: BestEffort + memory: BestEffort + Environment Variables: <none> + No volumes. +``` + +### Retroceder a una Revisión Previa + +Ahora has decidido que quieres deshacer el despliegue actual y retrocederlo a la revisión previa: + +```shell +kubectl rollout undo deployment.v1.apps/nginx-deployment +``` +``` +deployment.apps/nginx-deployment +``` + +Alternativamente, puedes retroceder a una revisión específica con el parámetro `--to-revision`: + +```shell +kubectl rollout undo deployment.v1.apps/nginx-deployment --to-revision=2 +``` +``` +deployment.apps/nginx-deployment +``` + +Para más detalles acerca de los comandos relacionados con las revisiones de un Deployment, echa un vistazo a [`kubectl rollout`](/docs/reference/generated/kubectl/kubectl-commands#rollout). + +El Deployment se ha revertido ahora a una revisión previa estable. Como se puede comprobar, el controlador del Deployment genera un evento `DeploymentRollback` +al retroceder a la revisión 2. + +```shell +kubectl get deployment nginx-deployment +``` +``` +NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE +nginx-deployment 3 3 3 3 30m +``` + +```shell +kubectl describe deployment nginx-deployment +``` +``` +Name: nginx-deployment +Namespace: default +CreationTimestamp: Sun, 02 Sep 2018 18:17:55 -0500 +Labels: app=nginx +Annotations: deployment.kubernetes.io/revision=4 + kubernetes.io/change-cause=kubectl set image deployment.v1.apps/nginx-deployment nginx=nginx:1.9.1 --record=true +Selector: app=nginx +Replicas: 3 desired | 3 updated | 3 total | 3 available | 0 unavailable +StrategyType: RollingUpdate +MinReadySeconds: 0 +RollingUpdateStrategy: 25% max unavailable, 25% max surge +Pod Template: + Labels: app=nginx + Containers: + nginx: + Image: nginx:1.9.1 + Port: 80/TCP + Host Port: 0/TCP + Environment: <none> + Mounts: <none> + Volumes: <none> +Conditions: + Type Status Reason + ---- ------ ------ + Available True MinimumReplicasAvailable + Progressing True NewReplicaSetAvailable +OldReplicaSets: <none> +NewReplicaSet: nginx-deployment-c4747d96c (3/3 replicas created) +Events: + Type Reason Age From Message + ---- ------ ---- ---- ------- + Normal ScalingReplicaSet 12m deployment-controller Scaled up replica set nginx-deployment-75675f5897 to 3 + Normal ScalingReplicaSet 11m deployment-controller Scaled up replica set nginx-deployment-c4747d96c to 1 + Normal ScalingReplicaSet 11m deployment-controller Scaled down replica set nginx-deployment-75675f5897 to 2 + Normal ScalingReplicaSet 11m deployment-controller Scaled up replica set nginx-deployment-c4747d96c to 2 + Normal ScalingReplicaSet 11m deployment-controller Scaled down replica set nginx-deployment-75675f5897 to 1 + Normal ScalingReplicaSet 11m deployment-controller Scaled up replica set nginx-deployment-c4747d96c to 3 + Normal ScalingReplicaSet 11m deployment-controller Scaled down replica set nginx-deployment-75675f5897 to 0 + Normal ScalingReplicaSet 11m deployment-controller Scaled up replica set nginx-deployment-595696685f to 1 + Normal DeploymentRollback 15s deployment-controller Rolled back deployment "nginx-deployment" to revision 2 + Normal ScalingReplicaSet 15s deployment-controller Scaled down replica set nginx-deployment-595696685f to 0 +``` + +## Escalar un Deployment + +Puedes escalar un Deployment usando el siguiente comando: + +```shell +kubectl scale deployment.v1.apps/nginx-deployment --replicas=10 +``` +``` +deployment.apps/nginx-deployment scaled +``` + +Asumiendo que se ha habilitado el [escalado horizontal de pod](/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough/) +en tu clúster, puedes configurar un auto-escalado para tu Deployment y elegir el mínimo y máximo número de Pods +que quieres ejecutar en base al uso de CPU de tus Pods actuales. + +```shell +kubectl autoscale deployment.v1.apps/nginx-deployment --min=10 --max=15 --cpu-percent=80 +``` +``` +deployment.apps/nginx-deployment scaled +``` + +### Escalado proporcional + +La actualización continua de los Deployments permite la ejecución de múltiples versiones de una aplicación al mismo tiempo. +Cuando tú o un auto-escalado escala un Deployment con actualización continua que está en medio de otro despliegue (bien en curso o pausado), +entonces el controlador del Deployment balanceará las réplicas adicionales de los ReplicaSets activos (ReplicaSets con Pods) +para así poder mitigar el riesgo. Esto se conoce como *escalado proporcional*. + +Por ejemplo, imagina que estás ejecutando un Deployment con 10 réplicas, donde [maxSurge](#max-surge)=3, y [maxUnavailable](#max-unavailable)=2. + +```shell +kubectl get deploy +``` +``` +NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE +nginx-deployment 10 10 10 10 50s +``` + +Si actualizas a una nueva imagen que no puede descargarse desde el clúster: + +```shell +kubectl set image deployment.v1.apps/nginx-deployment nginx=nginx:sometag +``` +``` +deployment.apps/nginx-deployment image updated +``` + +La actualización de la imagen arranca un nuevo despliegue con el ReplicaSet nginx-deployment-1989198191, +pero se bloquea debido al requisito `maxUnavailable` indicado arriba: + +```shell +kubectl get rs +``` +``` +NAME DESIRED CURRENT READY AGE +nginx-deployment-1989198191 5 5 0 9s +nginx-deployment-618515232 8 8 8 1m +``` + +Y entonces se origina una nueva petición de escalado para el Deployment. El auto-escalado incrementa las réplicas del Deployment +a 15. El controlador del Deployment necesita ahora decidir dónde añadir esas nuevas 5 réplicas. +Si no estuvieras usando el escalado proporcional, las 5 se añadirían al nuevo ReplicaSet. Pero con el escalado proporcional, +las réplicas adicionales se distribuyen entre todos los ReplicaSets. Las partes más grandes van a los ReplicaSets +con el mayor número de réplicas y las partes más pequeñas van a los ReplicaSets con menos réplicas. Cualquier resto sobrante se añade +al ReplicaSet con mayor número de réplicas. Aquellos ReplicaSets con 0 réplicas no se escalan. + +En nuestro ejemplo anterior, se añadirán 3 réplicas al viejo ReplicaSet y 2 réplicas al nuevo ReplicaSet. +EL proceso de despliegue debería al final mover todas las réplicas al nuevo ReplicaSet, siempre que las nuevas +réplicas arranquen positivamente. + +```shell +kubectl get deploy +``` +``` +NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE +nginx-deployment 15 18 7 8 7m +``` + +```shell +kubectl get rs +``` +``` +NAME DESIRED CURRENT READY AGE +nginx-deployment-1989198191 7 7 0 7m +nginx-deployment-618515232 11 11 11 7m +``` + +## Pausar y Reanudar un Deployment + +Puedes pausar un Deployment antes de arrancar una o más modificaciones y luego reanudarlo. Esto te permite aplicar múltiples arreglos +entre la pausa y la reanudación sin necesidad de arrancar despliegues innecesarios. + +Por ejemplo, con un Deployment que acaba de crearse: + +```shell +kubectl get deploy +``` +``` +NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE +nginx 3 3 3 3 1m +``` +```shell +kubectl get rs +``` +``` +NAME DESIRED CURRENT READY AGE +nginx-2142116321 3 3 3 1m +``` + +Lo pausamos ejecutando el siguiente comando: + +```shell +kubectl rollout pause deployment.v1.apps/nginx-deployment +``` +``` +deployment.apps/nginx-deployment paused +``` + +Y luego actualizamos la imagen del Deployment: + +```shell +kubectl set image deployment.v1.apps/nginx-deployment nginx=nginx:1.9.1 +``` +``` +deployment.apps/nginx-deployment image updated +``` + +Nótese que no se arranca ningún despliegue nuevo: + +```shell +kubectl rollout history deployment.v1.apps/nginx-deployment +``` +``` +deployments "nginx" +REVISION CHANGE-CAUSE +1 <none> +``` + +```shell +kubectl get rs +``` +``` +NAME DESIRED CURRENT READY AGE +nginx-2142116321 3 3 3 2m +``` + +Puedes realizar tantas modificaciones como quieras, por ejemplo, para actualizar los recursos a utilizar: + +```shell +kubectl set resources deployment.v1.apps/nginx-deployment -c=nginx --limits=cpu=200m,memory=512Mi +``` +``` +deployment.apps/nginx-deployment resource requirements updated +``` + +El estado inicial del Deployment anterior a la pausa continuará su función, pero las nuevas modificaciones +del Deployment no tendrán efecto ya que el Deployment está pausado. + +Al final, reanuda el Deployment y observa cómo se genera un nuevo ReplicaSet con todos los cambios: + +```shell +kubectl rollout resume deployment.v1.apps/nginx-deployment +``` + +``` +deployment.apps/nginx-deployment resumed +``` + +```shell +kubectl get rs -w +``` + +``` +NAME DESIRED CURRENT READY AGE +nginx-2142116321 2 2 2 2m +nginx-3926361531 2 2 0 6s +nginx-3926361531 2 2 1 18s +nginx-2142116321 1 2 2 2m +nginx-2142116321 1 2 2 2m +nginx-3926361531 3 2 1 18s +nginx-3926361531 3 2 1 18s +nginx-2142116321 1 1 1 2m +nginx-3926361531 3 3 1 18s +nginx-3926361531 3 3 2 19s +nginx-2142116321 0 1 1 2m +nginx-2142116321 0 1 1 2m +nginx-2142116321 0 0 0 2m +nginx-3926361531 3 3 3 20s + +``` +```shell +kubectl get rs +``` +``` +NAME DESIRED CURRENT READY AGE +nginx-2142116321 0 0 0 2m +nginx-3926361531 3 3 3 28s +``` + +{{< note >}} +No se puede revertir un Deployment pausado hasta que se vuelve a reanudar. +{{< /note >}} + +## Estado del Deployment + +Un Deployment pasa por varios estados a lo largo de su ciclo de vida. Así, puede estar [progresando](#progressing-deployment) mientras +se despliega un nuevo ReplicaSet, puede estar [completo](#complete-deployment), o puede quedar en estado [fallido](#failed-deployment). + +### Progresar un Deployment + +Kubernetes marca un Deployment como _progresando_ cuando se realiza cualquiera de las siguientes tareas: + +* El Deployment crea un nuevo ReplicaSet. +* El Deployment está escalando su ReplicaSet más nuevo. +* El Deployment está reduciendo su(s) ReplicaSet(s) más antiguo(s). +* Hay nuevos Pods disponibles y listos (listo por lo menos [MinReadySeconds](#min-ready-seconds)). + +Puedes monitorizar el progreso de un Deployment usando el comando `kubectl rollout status`. + +### Completar un Deployment + +Kubernetes marca un Deployment como _completado_ cuando presenta las siguientes características: + +* Todas las réplicas asociadas con el Deployment han sido actualizadas a la última versión indicada, lo cual quiere decir +que todas las actualizaciones se han completado. +* Todas las réplicas asociadas con el Deployment están disponibles. +* No están ejecutándose viejas réplicas del Deployment. + +Puedes comprobar si un Deployment se ha completado usando el comando `kubectl rollout status`. Si el despliegue se ha completado +de forma satisfactoria, el comando `kubectl rollout status` devuelve un código 0 de salida. + +```shell +kubectl rollout status deployment.v1.apps/nginx-deployment +``` +``` +Waiting for rollout to finish: 2 of 3 updated replicas are available... +deployment.apps/nginx-deployment successfully rolled out +$ echo $? +0 +``` + +### Deployment fallido + +Tu Deployment puede quedarse bloqueado intentando desplegar su nuevo ReplicaSet sin nunca completarse. Esto puede ocurrir +debido a algunos de los factores siguientes: + +* Cuota insuficiente +* Fallos en la prueba de estar listo +* Errores en la descarga de imágenes +* Permisos insuficientes +* Rangos de límites de recursos +* Mala configuración del motor de ejecución de la aplicación + +Una forma de detectar este tipo de situación es especificar un parámetro de vencimiento en la especificación de tu Deployment: +([`.spec.progressDeadlineSeconds`](#progress-deadline-seconds)). `.spec.progressDeadlineSeconds` denota el número +de segundos que el controlador del Deployment debe esperar antes de indicar (en el estado del Deployment) que el +Deployment no avanza. + +El siguiente comando `kubectl` configura el campo `progressDeadlineSeconds` para forzar al controlador a +informar de la falta de avance de un Deployment después de 10 minutos: + +```shell +kubectl patch deployment.v1.apps/nginx-deployment -p '{"spec":{"progressDeadlineSeconds":600}}' +``` +``` +deployment.apps/nginx-deployment patched +``` +Una vez que se ha excedido el vencimiento, el controlador del Deployment añade una DeploymentCondition +con los siguientes atributos al campo `.status.conditions` del Deployment: + +* Type=Progressing +* Status=False +* Reason=ProgressDeadlineExceeded + +Ver las [convenciones de la API de Kubernetes](https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#typical-status-properties) para más información acerca de las condiciones de estado. + +{{< note >}} +Kubernetes no emprenderá ninguna acción ante un Deployment parado que no sea la de reportar el estado mediante +`Reason=ProgressDeadlineExceeded`. Los orquestradores de alto nivel pueden aprovecharse y actuar consecuentemente, por ejemplo, +retrocediendo el Deployment a su versión previa. +{{< /note >}} + +{{< note >}} +Si pausas un Deployment, Kubernetes no comprueba el avance en base al vencimiento indicado. Así, es posible pausar +de forma segura un Deployment en medio de un despliegue y reanudarlo sin que se arranque el estado de exceso de vencimiento. +{{< /note >}} + +Puede que notes errores transitorios en tus Deployments, bien debido a un tiempo de vencimiento muy pequeño que hayas configurado +o bien a cualquier otro tipo de error que puede considerarse como transitorio. Por ejemplo, +supongamos que no tienes suficiente cuota. Si describes el Deployment, te darás cuenta de la sección siguiente: + +```shell +kubectl describe deployment nginx-deployment +``` +``` +<...> +Conditions: + Type Status Reason + ---- ------ ------ + Available True MinimumReplicasAvailable + Progressing True ReplicaSetUpdated + ReplicaFailure True FailedCreate +<...> +``` + +Si ejecutas el comando `kubectl get deployment nginx-deployment -o yaml`, el estado del Deployment puede parecerse a: + +``` +status: + availableReplicas: 2 + conditions: + - lastTransitionTime: 2016-10-04T12:25:39Z + lastUpdateTime: 2016-10-04T12:25:39Z + message: Replica set "nginx-deployment-4262182780" is progressing. + reason: ReplicaSetUpdated + status: "True" + type: Progressing + - lastTransitionTime: 2016-10-04T12:25:42Z + lastUpdateTime: 2016-10-04T12:25:42Z + message: Deployment has minimum availability. + reason: MinimumReplicasAvailable + status: "True" + type: Available + - lastTransitionTime: 2016-10-04T12:25:39Z + lastUpdateTime: 2016-10-04T12:25:39Z + message: 'Error creating: pods "nginx-deployment-4262182780-" is forbidden: exceeded quota: + object-counts, requested: pods=1, used: pods=3, limited: pods=2' + reason: FailedCreate + status: "True" + type: ReplicaFailure + observedGeneration: 3 + replicas: 2 + unavailableReplicas: 2 +``` + +Al final, una vez que se supera el vencimiento del progreso del Deployment, Kubernetes actualiza el estado +y la razón de el estado de progreso: + +``` +Conditions: + Type Status Reason + ---- ------ ------ + Available True MinimumReplicasAvailable + Progressing False ProgressDeadlineExceeded + ReplicaFailure True FailedCreate +``` + +Puedes solucionar un problema de cuota insuficiente simplemente reduciendo el número de réplicas de tu Deployment, reduciendo +otros controladores que puedas estar ejecutando, o incrementando la cuota en tu espacio de nombres. Si una vez satisfechas las condiciones de tu cuota, +el controlador del Deployment completa el despliegue, entonces verás que el estado del Deployment se actualiza al estado satisfactorio (`Status=True` y `Reason=NewReplicaSetAvailable`). + +``` +Conditions: + Type Status Reason + ---- ------ ------ + Available True MinimumReplicasAvailable + Progressing True NewReplicaSetAvailable +``` + +`Type=Available` con `Status=True` significa que tu Deployment tiene disponibilidad mínima. La disponibilidad mínima se prescribe +mediante los parámetros indicados en la estrategia de despligue. `Type=Progressing` con `Status=True` significa que tu Deployment +está bien en medio de un despliegue y está progresando o bien que se ha completado de forma satisfactoria y el número mínimo +requerido de nuevas réplicas ya está disponible (ver la Razón del estado para cada caso particular - en nuestro caso +`Reason=NewReplicaSetAvailable` significa que el Deployment se ha completado). + +Puedes comprobar si un Deployment ha fallado en su progreso usando el comando `kubectl rollout status`. `kubectl rollout status` +devuelve un código de salida distinto de 0 si el Deployment ha excedido su tiempo de vencimiento. + +```shell +kubectl rollout status deployment.v1.apps/nginx-deployment +``` +``` +Waiting for rollout to finish: 2 out of 3 new replicas have been updated... +error: deployment "nginx" exceeded its progress deadline +$ echo $? +1 +``` + +### Actuar ante un despliegue fallido + +Todas las acciones que aplican a un Deployment completado también aplican a un Deployment fallido. Puedes escalarlo/reducirlo, retrocederlo +a una revisión previa, o incluso pausarlo si necesitas realizar múltiples cambios a la plantilla Pod del Deployment. + +## Regla de Limpieza + +Puedes configurar el campo `.spec.revisionHistoryLimit` de un Deployment para especificar cuántos ReplicaSets viejos quieres conservar +para este Deployment. El resto será eliminado en segundo plano. Por defecto, es 10. + +{{< note >}} +Poner este campo de forma explícita a 0 resulta en la limpieza de toda la historia de tu Deployment, +por lo que tu Deployment no podrá retroceder a revisiones previas. +{{< /note >}} + +## Casos de Uso + +### Despligue Canary + +Si quieres desplegar nuevas versiones a un sub-conjunto de usuarios o servidores usando el Deployment, +puedes hacerlo creando múltiples Deployments, uno para cada versión nueva, siguiendo el patrón canary descrito en +[gestionar recursos](/docs/concepts/cluster-administration/manage-deployment/#canary-deployments). + +## Escribir una especificación de Deployment + +Al igual que con el resto de configuraciones de Kubernetes, un Deployment requiere los campos `apiVersion`, `kind`, y `metadata`. +Para información general acerca de cómo trabajar con ficheros de configuración, ver los documentos acerca de [desplegar aplicaciones](/docs/tutorials/stateless-application/run-stateless-application-deployment/), +configurar contenedores, y [usar kubectl para gestionar recursos](/docs/concepts/overview/object-management-kubectl/overview/). + +Un Deployment también necesita una [sección `.spec`](https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status). + +### Plantilla Pod + +Tanto `.spec.template` como `.spec.selector` sin campos obligatorios dentro de `.spec`. + +El campo `.spec.template` es una [plantilla Pod](/docs/concepts/workloads/pods/pod-overview/#pod-templates). Tiene exactamente el mismo esquema que un [Pod](/docs/concepts/workloads/pods/pod/), +excepto por el hecho de que está anidado y no tiene `apiVersion` ni `kind`. + +Junto con los campos obligatorios de un Pod, una plantilla Pod de un Deployment debe indicar las etiquetas +y las reglas de reinicio apropiadas. Para el caso de las etiquetas, asegúrate que no se entremezclan con otros controladores. Ver [selector](#selector)). + +Únicamente se permite una [`.spec.template.spec.restartPolicy`](/docs/concepts/workloads/pods/pod-lifecycle/#restart-policy) igual a `Always`, +que es el valor por defecto si no se indica. + +### Réplicas + +`.spec.replicas` es un campo opcional que indica el número de Pods deseados. Su valor por defecto es 1. + +### Selector + +`.spec.selector` es un campo opcional que indica un [selector de etiquetas](/docs/concepts/overview/working-with-objects/labels/) +para los Pods objetivo del deployment. + +`.spec.selector` debe coincidir con `.spec.template.metadata.labels`, o será descartado por la API. + +A partir de la versión `apps/v1` de la API, `.spec.selector` y `.metadata.labels` no toman como valor por defecto el valor de `.spec.template.metadata.labels` si no se indica. +Por ello, debe especificarse de forma explícita. Además hay que mencionar que `.spec.selector` es inmutable tras la creación del Deployment en `apps/v1`. + +Un Deployment puede finalizar aquellos Pods cuyas etiquetas coincidan con el selector si su plantilla es diferente +de `.spec.template` o si el número total de dichos Pods excede `.spec.replicas`. Arranca nuevos +Pods con `.spec.template` si el número de Pods es menor que el número deseado. + +{{< note >}} +No deberías crear otros Pods cuyas etiquetas coincidan con este selector, ni directamente creando +otro Deployment, ni creando otro controlador como un ReplicaSet o un ReplicationController. Si lo haces, +el primer Deployment pensará que también creó esos otros Pods. Kubernetes no te impide hacerlo. +{{< /note >}} + +Si tienes múltiples controladores que entremezclan sus selectores, dichos controladores competirán entre ellos +y no se comportarán de forma correcta. + +### Estrategia + +`.spec.strategy` especifica la estrategia usada para remplazar los Pods viejos con los nuevos. +`.spec.strategy.type` puede tener el valor "Recreate" o "RollingUpdate". "RollingUpdate" el valor predeterminado. + +#### Despliegue mediante recreación + +Todos los Pods actuales se eliminan antes de que los nuevos se creen cuando `.spec.strategy.type==Recreate`. + +#### Despliegue mediante actualización continua + +El Deployment actualiza los Pods en modo de [actualización continua](/docs/tasks/run-application/rolling-update-replication-controller/) +cuando `.spec.strategy.type==RollingUpdate`. Puedes configurar los valores de `maxUnavailable` y `maxSurge` +para controlar el proceso de actualización continua. + +##### Número máximo de pods no disponibles + +`.spec.strategy.rollingUpdate.maxUnavailable` es un campo opcional que indica el número máximo +de Pods que pueden no estar disponibles durante el proceso de actualización. El valor puede ser un número absoluto (por ejemplo, 5) +o un porcentaje de los Pods deseados (por ejemplo, 10%). El número absoluto se calcula a partir del porcentaje +con redondeo a la baja. El valor no puede ser 0 si `.spec.strategy.rollingUpdate.maxSurge` es 0. El valor predeterminado es 25%. + +Por ejemplo, cuando este valor es 30%, el ReplicaSet viejo puede escalarse al 70% de los +Pods deseados de forma inmediata tras comenzar el proceso de actualización. Una vez que los Pods están listos, +el ReplicaSet viejo puede reducirse aún mas, seguido de un escalado del nuevo ReplicaSet, +asegurándose que el número total de Pods disponibles en todo momento durante la actualización +es de al menos el 70% de los Pods deseados. + +##### Número máximo de pods por encima del número deseado + +`.spec.strategy.rollingUpdate.maxSurge` es un campo opcional que indica el número máximo de Pods +que puede crearse por encima del número deseado de Pods. El valor puede ser un número absoluto (por ejemplo, 5) +o un porcentaje de los Pods deseados (por ejemplo, 10%). El valor no puede ser 0 si `MaxUnavailable` es 0. +El número absoluto se calcula a partir del porcentaje con redondeo al alza. El valor predeterminado es 25%. + +Por ejemplo, cuando este valor es 30%, el nuevo ReplicaSet puede escalarse inmediatamente cuando +comienza la actualización continua, de forma que el número total de Pods viejos y nuevos no +excede el 130% de los Pods deseados. Una vez que los viejos Pods se han eliminado, el nuevo ReplicaSet +puede seguir escalándose, asegurándose que el número total de Pods ejecutándose en todo momento +durante la actualización es como mucho del 130% de los Pods deseados. + +### Segundos para vencimiento del progreso + +`.spec.progressDeadlineSeconds` es un campo opcional que indica el número de segundos que quieres +esperar a que tu Deployment avance antes de que el sistema reporte que dicho Deployment +[ha fallado en su avance](#failed-deployment) - expresado como un estado con `Type=Progressing`, `Status=False`. +y `Reason=ProgressDeadlineExceeded` en el recurso. El controlador del Deployment seguirá intentando +el despliegue. En el futuro, una vez que se implemente el retroceso automático, el controlador del Deployment +retrocederá el despliegue en cuanto detecte ese estado. + +Si se especifica, este campo debe ser mayor que `.spec.minReadySeconds`. + +### Tiempo mínimo para considerar el Pod disponible + +`.spec.minReadySeconds` es un campo opcional que indica el número mínimo de segundos en que +un Pod recién creado debería estar listo sin que falle ninguno de sus contenedores, para que se considere disponible. +Por defecto su valor es 0 (el Pod se considera disponible en el momento que está listo). Para aprender más acerca de +cuándo un Pod se considera que está listo, ver las [pruebas de contenedor](/docs/concepts/workloads/pods/pod-lifecycle/#container-probes). + +### Vuelta atrás + +El campo `.spec.rollbackTo` se ha quitado de las versiones `extensions/v1beta1` y `apps/v1beta1` de la API, y ya no se permite en las versiones de la API a partir de `apps/v1beta2`. +En su caso, se debería usar `kubectl rollout undo`, tal y como se explicó en [Retroceder a una Revisión Previa](#rolling-back-to-a-previous-revision). + +### Límite del histórico de revisiones + +La historia de revisiones de un Deployment se almacena en los ReplicaSets que este controla. + +`.spec.revisionHistoryLimit` es un campo opcional que indica el número de ReplicaSets viejos a retener +para permitir los retrocesos. Estos ReplicaSets viejos consumen recursos en `etcd` y rebosan la salida de `kubectl get rs`. +La configuración de cada revisión de Deployment se almacena en sus ReplicaSets; +por lo tanto, una vez que se elimina el ReplicaSet viejo, se pierde la posibilidad de retroceder a dicha revisión del Deployment. +Por defecto, se retienen hasta 10 ReplicaSets viejos; pero su valor ideal depende de la frecuencia y la estabilidad de los nuevos Deployments. + +De forma más específica, si ponemos este campo a cero quiere decir que todos los ReplicaSets viejos con 0 réplicas se limpiarán. +En este caso, el nuevo despliegue del Deployment no se puede deshacer, ya que su historia de revisiones se habrá limpiado. + +### Pausa + +`.spec.paused` es un campo booleano opcional para pausar y reanudar un Deployment. La única diferencia entre +un Deployment pausado y otro que no lo está es que cualquier cambio al PodTemplateSpec del Deployment pausado +no generará nuevos despliegues mientras esté pausado. Un Deployment se pausa de forma predeterminada cuando se crea. + +## Alternativa a los Deployments + +### kubectl rolling update + +[`kubectl rolling update`](/docs/reference/generated/kubectl/kubectl-commands#rolling-update) actualiza los Pods y los ReplicationControllers +de forma similar. Pero se recomienda el uso de Deployments porque se declaran del lado del servidor, y proporcionan características adicionales +como la posibilidad de retroceder a revisiones anteriores incluso después de haber terminado una actualización continua. + + diff --git a/content/es/docs/concepts/workloads/controllers/garbage-collection.md b/content/es/docs/concepts/workloads/controllers/garbage-collection.md new file mode 100644 index 0000000000..bc18541ce2 --- /dev/null +++ b/content/es/docs/concepts/workloads/controllers/garbage-collection.md @@ -0,0 +1,176 @@ +--- +title: Recolección de Basura +content_type: concept +weight: 60 +--- + +<!-- overview --> + +El papel del recolector de basura de Kubernetes es el de eliminar determinados objetos +que en algún momento tuvieron un propietario, pero que ahora ya no. + +<!-- body --> + +## Propietarios y subordinados + +Algunos objetos de Kubernetes son propietarios de otros objetos. Por ejemplo, un ReplicaSet +es el propietario de un conjunto de Pods. Los objetos que se poseen se denominan *subordinados* del +objeto propietario. Cada objeto subordinado tiene un campo `metadata.ownerReferences` +que apunta al objeto propietario. + +En ocasiones, Kubernetes pone el valor del campo `ownerReference` automáticamente. + Por ejemplo, cuando creas un ReplicaSet, Kubernetes automáticamente pone el valor del campo +`ownerReference` de cada Pod en el ReplicaSet. A partir de la versión 1.8, Kubernetes +automáticamente pone el valor de `ownerReference` para los objetos creados o adoptados +por un ReplicationController, ReplicaSet, StatefulSet, DaemonSet, Deployment, Job +y CronJob. + +También puedes configurar las relaciones entre los propietarios y sus subordinados +de forma manual indicando el valor del campo `ownerReference`. + +Aquí se muestra un archivo de configuración para un ReplicaSet que tiene tres Pods: + +{{< codenew file="controllers/replicaset.yaml" >}} + +Si se crea el ReplicaSet y entonces se muestra los metadatos del Pod, se puede +observar el campo OwnerReferences: + +```shell +kubectl apply -f https://k8s.io/examples/controllers/replicaset.yaml +kubectl get pods --output=yaml +``` + +La salida muestra que el propietario del Pod es el ReplicaSet denominado `my-repset`: + +```shell +apiVersion: v1 +kind: Pod +metadata: + ... + ownerReferences: + - apiVersion: apps/v1 + controller: true + blockOwnerDeletion: true + kind: ReplicaSet + name: my-repset + uid: d9607e19-f88f-11e6-a518-42010a800195 + ... +``` + +{{< note >}} +No se recomienda el uso de OwnerReferences entre Namespaces por diseño. Esto quiere decir que: +1) Los subordinados dentro del ámbito de Namespaces sólo pueden definir propietarios en ese mismo Namespace, +y propietarios dentro del ámbito de clúster. +2) Los subordinados dentro del ámbito del clúster sólo pueden definir propietarios dentro del ámbito del clúster, pero no +propietarios dentro del ámbito de Namespaces. +{{< /note >}} + +## Controlar cómo el recolector de basura elimina los subordinados + +Cuando eliminas un objeto, puedes indicar si sus subordinados deben eliminarse también +de forma automática. Eliminar los subordinados automáticamente se denomina *borrado en cascada*. +Hay dos modos de *borrado en cascada*: *en segundo plano* y *en primer plano*. + +Si eliminas un objeto sin borrar sus subordinados de forma automática, +dichos subordinados se convierten en *huérfanos*. + +### Borrado en cascada en primer plano + +En el *borrado en cascada en primer plano*, el objeto raíz primero entra en un estado +llamado "deletion in progress". En este estado "deletion in progress", +se cumplen las siguientes premisas: + + * El objeto todavía es visible a través de la API REST + * Se pone el valor del campo `deletionTimestamp` del objeto + * El campo `metadata.finalizers` del objeto contiene el valor "foregroundDeletion". + +Una vez que se pone el estado "deletion in progress", el recolector de basura elimina +los subordinados del objeto. Una vez que el recolector de basura ha eliminado todos +los subordinados "bloqueantes" (los objetos con `ownerReference.blockOwnerDeletion=true`), elimina +el objeto propietario. + +Cabe mencionar que usando "foregroundDeletion", sólo los subordinados con valor en +`ownerReference.blockOwnerDeletion` bloquean la eliminación del objeto propietario. +A partir de la versión 1.7, Kubernetes añadió un [controlador de admisión](/docs/reference/access-authn-authz/admission-controllers/#ownerreferencespermissionenforcement) +que controla el acceso de usuario cuando se intenta poner el campo `blockOwnerDeletion` a true +con base a los permisos de borrado del objeto propietario, de forma que aquellos subordinados no autorizados +no puedan retrasar la eliminación del objeto propietario. + +Si un controlador (como un Deployment o un ReplicaSet) establece el valor del campo `ownerReferences` de un objeto, +se pone blockOwnerDeletion automáticamente y no se necesita modificar de forma manual este campo. + +### Borrado en cascada en segundo plano + +En el *borrado en cascada en segundo plano*, Kubernetes elimina el objeto propietario +inmediatamente y es el recolector de basura quien se encarga de eliminar los subordinados en segundo plano. + +### Configurar la regla de borrado en cascada + +Para controlar la regla de borrado en cascada, configura el campo `propagationPolicy` +del parámetro `deleteOptions` cuando elimines un objeto. Los valores posibles incluyen "Orphan", +"Foreground", o "Background". + +Antes de la versión 1.9 de Kubernetes, la regla predeterminada del recolector de basura para la mayoría de controladores era `orphan`. +Esto incluía al ReplicationController, ReplicaSet, StatefulSet, DaemonSet, y al Deployment. +Para los tipos dentro de las versiones de grupo `extensions/v1beta1`, `apps/v1beta1`, y `apps/v1beta2`, a menos que +se indique de otra manera, los objetos subordinados se quedan huérfanos por defecto. +En Kubernetes 1.9, para todos los tipos de la versión de grupo `apps/v1`, los objetos subordinados se eliminan por defecto. + +Aquí se muestra un ejemplo que elimina los subordinados en segundo plano: + +```shell +kubectl proxy --port=8080 +curl -X DELETE localhost:8080/apis/apps/v1/namespaces/default/replicasets/my-repset \ +-d '{"kind":"DeleteOptions","apiVersion":"v1","propagationPolicy":"Background"}' \ +-H "Content-Type: application/json" +``` + +Aquí se muestra un ejemplo que elimina los subordinados en primer plano: + +```shell +kubectl proxy --port=8080 +curl -X DELETE localhost:8080/apis/apps/v1/namespaces/default/replicasets/my-repset \ +-d '{"kind":"DeleteOptions","apiVersion":"v1","propagationPolicy":"Foreground"}' \ +-H "Content-Type: application/json" +``` + +Aquí se muestra un ejemplo de subordinados huérfanos: + +```shell +kubectl proxy --port=8080 +curl -X DELETE localhost:8080/apis/apps/v1/namespaces/default/replicasets/my-repset \ +-d '{"kind":"DeleteOptions","apiVersion":"v1","propagationPolicy":"Orphan"}' \ +-H "Content-Type: application/json" +``` + +kubectl también permite el borrado en cascada. +Para eliminar los subordinados automáticamente, utiliza el parámetro `--cascade` a true. + Usa false para subordinados huérfanos. Por defecto, el valor de `--cascade` +es true. + +Aquí se muestra un ejemplo de huérfanos de subordinados de un ReplicaSet: + +```shell +kubectl delete replicaset my-repset --cascade=false +``` + +### Nota adicional sobre los Deployments + +Antes de la versión 1.7, cuando se usaba el borrado en cascada con Deployments se *debía* usar `propagationPolicy: Foreground` +para eliminar no sólo los ReplicaSets creados, sino también sus Pods correspondientes. Si este tipo de _propagationPolicy_ +no se usa, solo se elimina los ReplicaSets, y los Pods se quedan huérfanos. +Ver [kubeadm/#149](https://github.com/kubernetes/kubeadm/issues/149#issuecomment-284766613) para más información. + +## Problemas conocidos + +Seguimiento en [#26120](https://github.com/kubernetes/kubernetes/issues/26120) + + + +## {{% heading "whatsnext" %}} + + +[Documento de Diseño 1](https://git.k8s.io/community/contributors/design-proposals/api-machinery/garbage-collection.md) + +[Documento de Diseño 2](https://git.k8s.io/community/contributors/design-proposals/api-machinery/synchronous-garbage-collection.md) + diff --git a/content/es/docs/concepts/workloads/controllers/jobs-run-to-completion.md b/content/es/docs/concepts/workloads/controllers/jobs-run-to-completion.md new file mode 100644 index 0000000000..f3bd77b4bf --- /dev/null +++ b/content/es/docs/concepts/workloads/controllers/jobs-run-to-completion.md @@ -0,0 +1,457 @@ +--- +title: Jobs - Ejecución hasta el final +content_type: concept +feature: + title: Ejecución en lotes + description: > + Además de los servicios, Kubernetes puede gestionar tus trabajos por lotes y CI, sustituyendo los contenedores que fallen, si así se desea. +weight: 70 +--- + +<!-- overview --> + +Un Job crea uno o más Pods y se asegura de que un número específico de ellos termina de forma satisfactoria. +Conforme los pods terminan satisfactoriamente, el Job realiza el seguimiento de las ejecuciones satisfactorias. +Cuando se alcanza un número específico de ejecuciones satisfactorias, la tarea (esto es, el Job) se completa. +Al eliminar un Job se eliminan los Pods que haya creado. + +Un caso simple de uso es crear un objeto Job para que se ejecute un Pod de manera fiable hasta el final. +El objeto Job arrancará un nuevo Pod si el primer Pod falla o se elimina (por ejemplo +como consecuencia de un fallo de hardware o un reinicio en un nodo). + +También se puede usar un Job para ejecutar múltiples Pods en paralelo. + + + + +<!-- body --> + +## Ejecutar un Job de ejemplo + +Aquí se muestra un ejemplo de configuración de Job. Este ejemplo calcula los primeros 2000 decimales de π y los imprime por pantalla. +Tarda unos 10s en completarse. + +{{< codenew file="controllers/job.yaml" >}} + +Puedes ejecutar el ejemplo con este comando: + +```shell +kubectl apply -f https://k8s.io/examples/controllers/job.yaml +``` +``` +job "pi" created +``` + +Comprueba el estado del Job con `kubectl`: + +```shell +kubectl describe jobs/pi +``` +``` +Name: pi +Namespace: default +Selector: controller-uid=b1db589a-2c8d-11e6-b324-0209dc45a495 +Labels: controller-uid=b1db589a-2c8d-11e6-b324-0209dc45a495 + job-name=pi +Annotations: <none> +Parallelism: 1 +Completions: 1 +Start Time: Tue, 07 Jun 2016 10:56:16 +0200 +Pods Statuses: 0 Running / 1 Succeeded / 0 Failed +Pod Template: + Labels: controller-uid=b1db589a-2c8d-11e6-b324-0209dc45a495 + job-name=pi + Containers: + pi: + Image: perl + Port: + Command: + perl + -Mbignum=bpi + -wle + print bpi(2000) + Environment: <none> + Mounts: <none> + Volumes: <none> +Events: + FirstSeen LastSeen Count From SubobjectPath Type Reason Message + --------- -------- ----- ---- ------------- -------- ------ ------- + 1m 1m 1 {job-controller } Normal SuccessfulCreate Created pod: pi-dtn4q +``` + +Para ver los Pods de un Job que se han completado, usa `kubectl get pods`. + +Para listar todos los Pods que pertenecen a un Job de forma que sea legible, puedes usar un comando como: + +```shell +pods=$(kubectl get pods --selector=job-name=pi --output=jsonpath='{.items[*].metadata.name}') +echo $pods +``` +``` +pi-aiw0a +``` + +En este caso, el selector es el mismo que el selector del Job. La opción `--output=jsonpath` indica un expresión +que simplemente obtiene el nombre de cada Pod en la lista devuelta. + +Mira la salida estándar de uno de los Pods: + +```shell +$ kubectl logs $pods +3.1415926535897932384626433832795028841971693993751058209749445923078164062862089986280348253421170679821480865132823066470938446095505822317253594081284811174502841027019385211055596446229489549303819644288109756659334461284756482337867831652712019091456485669234603486104543266482133936072602491412737245870066063155881748815209209628292540917153643678925903600113305305488204665213841469519415116094330572703657595919530921861173819326117931051185480744623799627495673518857527248912279381830119491298336733624406566430860213949463952247371907021798609437027705392171762931767523846748184676694051320005681271452635608277857713427577896091736371787214684409012249534301465495853710507922796892589235420199561121290219608640344181598136297747713099605187072113499999983729780499510597317328160963185950244594553469083026425223082533446850352619311881710100031378387528865875332083814206171776691473035982534904287554687311595628638823537875937519577818577805321712268066130019278766111959092164201989380952572010654858632788659361533818279682303019520353018529689957736225994138912497217752834791315155748572424541506959508295331168617278558890750983817546374649393192550604009277016711390098488240128583616035637076601047101819429555961989467678374494482553797747268471040475346462080466842590694912933136770289891521047521620569660240580381501935112533824300355876402474964732639141992726042699227967823547816360093417216412199245863150302861829745557067498385054945885869269956909272107975093029553211653449872027559602364806654991198818347977535663698074265425278625518184175746728909777727938000816470600161452491921732172147723501414419735685481613611573525521334757418494684385233239073941433345477624168625189835694855620992192221842725502542568876717904946016534668049886272327917860857843838279679766814541009538837863609506800642251252051173929848960841284886269456042419652850222106611863067442786220391949450471237137869609563643719172874677646575739624138908658326459958133904780275901 +``` + +## Escribir una especificación de Job + +Como con el resto de configuraciones de Kubernetes, un Job necesita los campos `apiVersion`, `kind`, y `metadata`. + +Un Job también necesita la [sección `.spec`](https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status). + +### Plantilla Pod + +El campo `.spec.template` es el único campo obligatorio de `.spec`. + +El campo `.spec.template` es una [plantilla Pod](/docs/concepts/workloads/pods/pod-overview/#pod-templates). Tiene exactamente el mismo esquema que un [pod](/docs/user-guide/pods), +excepto por el hecho de que está anidado y no tiene el campo `apiVersion` o `kind`. + +Además de los campos olbigatorios de un Pod, una plantilla Pod de un Job debe indicar las etiquetas apropiadas +(ver [selector de pod](#pod-selector)) y una regla de reinicio apropiada. + +Sólo se permite los valores `Never` o `OnFailure` para [`RestartPolicy`](/docs/concepts/workloads/pods/pod-lifecycle/#restart-policy). + +### Selector de Pod + +El campo `.spec.selector` es opcional. En la práctica mayoría de los casos no deberías configurarlo. +Mira la sección sobre [configurar tu propio selector de pod](#specifying-your-own-pod-selector). + + +### Jobs en paralelo + +Hay tres tipos principales de tarea aptos para ejecutarse como un Job: + +1. Jobs no paralelos + - normalmente, sólo se arranca un Pod, a menos que el Pod falle. + - el Job se completa tan pronto como su Pod termine de forma satisfactoria. +1. Jobs en paralelo con un *cupo fijo de terminación*: + - se configura un valor positivo distinto de cero para el campo `.spec.completions`. + - el Job representa la tarea en general, y se completa cuando hay una ejecución satisfactoria de un Pod por cada valor dentro del rango de 1 a `.spec.completions`. + - **no implementado todavía:** A cada Pod se le pasa un índice diferenente dentro del rango de 1 a `.spec.completions`. +1. Jobs en paralelo con una *cola de trabajo*: + - no se especifica el campo `.spec.completions`, por defecto `.spec.parallelism`. + - los Pods deben coordinarse entre ellos mismos o a través de un servicio externo que determine quién debe trabajar en qué. + Por ejemplo, un Pod podría ir a buscar un lote de hasta N ítems de una cola de trabajo. + - cada Pod es capaz de forma independiente de determinar si sus compañeros han terminado o no, y como consecuencia el Job entero ha terminado. + - cuando _cualquier_ Pod del Job termina con éxito, no se crean nuevos Pods. + - una vez que al menos uno de los Pods ha terminado con éxito y todos los Pods han terminado, entonces el Job termina con éxito. + - una vez que cualquier Pod ha terminado con éxito, ningún otro Pod debería continuar trabajando en la misma tarea o escribiendo ningún resultado. Todos ellos deberían estar en proceso de terminarse. + +En un Job _no paralelo_, no debes indicar el valor de `.spec.completions` ni `.spec.parallelism`. Cuando ambos se dejan + sin valor, ambos se predeterminan a 1. + +En un Job con _cupo fijo de terminación_, deberías poner el valor de `.spec.completions` al número de terminaciones que se necesiten. +Puedes dar un valor a `.spec.parallelism`, o dejarlo sin valor, en cuyo caso se predetermina a 1. + +En un Job con _cola de trabajo_, no debes indicar el valor de `.spec.completions`, y poner el valor de `.spec.parallelism` a +un entero no negativo. + +Para más información acerca de cómo usar los distintos tipos de Job, ver la sección de [patrones de job](#job-patterns). + + +#### Controlar el paralelismo + +El paralelismo solicitado (`.spec.parallelism`) puede usar cualquier valor no negativo. +Si no se indica, se predeterminad a 1. +Si se indica como 0, entonces el Job se pausa de forma efectiva hasta que se incremente. + +El paralelismo actual (número de pods ejecutándose en cada momento) puede que sea mayor o menor que el solicitado, +por los siguientes motivos: + +- Para los Jobs con _cupo fijo de terminaciones_, el número actual de pods ejecutándose en paralelo no excede el número de terminaciones pendientes. + Los valores superiores de `.spec.parallelism` se ignoran. +- Para los Jobs con _cola de trabajo_, no se arranca nuevos Pods después de que cualquier Pod se haya completado -- sin embargo, se permite que se completen los Pods pendientes. +- Cuando el controlador no ha tenido tiempo para reaccionar. +- Cuando el controlador no pudo crear los Pods por el motivo que fuera (falta de `ResourceQuota`, falta de permisos, etc.), + entonces puede que haya menos pods que los solicitados. +- El controlador puede que regule la creación de nuevos Pods debido al excesivo número de fallos anteriores en el mismo Job. +- Cuando un Pod se para de forma controlada, lleva tiempo pararlo. + +## Gestionar Fallos de Pod y Contenedor + +Un contenedor de un Pod puede fallar por cualquier motivo, como porque el proceso que se estaba ejecutando termina con un código de salida distinto de cero, +o porque se mató el contenedor por exceder un límite de memoria, etc. Si esto ocurre, y se tiene +`.spec.template.spec.restartPolicy = "OnFailure"`, entonces el Pod permance en el nodo, +pero el contenedor se vuelve a ejecutar. Por lo tanto, tu aplicación debe poder gestionar el caso en que se reinicia de forma local, +o bien especificar `.spec.template.spec.restartPolicy = "Never"`. +Ver el [ciclo de vida de un pod](/docs/concepts/workloads/pods/pod-lifecycle/#example-states) para más información sobre `restartPolicy`. + +Un Pod entero puede también fallar por cualquier motivo, como cuando se expulsa al Pod del nodo +(porque el nodo se actualiza, reinicia, elimina, etc.), o si un contenedor del Pod falla +cuando `.spec.template.spec.restartPolicy = "Never"`. Cuando un Pod falla, entonces el controlador del Job +arranca un nuevo Pod. Esto quiere decir que tu aplicación debe ser capaz de gestionar el caso en que se reinicia en un nuevo pod. +En particular, debe ser capaz de gestionar los ficheros temporales, los bloqueos, los resultados incompletos, y cualquier otra dependencia +de ejecuciones previas. + +Nótese que incluso si se configura `.spec.parallelism = 1` y `.spec.completions = 1` y +`.spec.template.spec.restartPolicy = "Never"`, el mismo programa puede arrancarse dos veces. + +Si se especifica `.spec.parallelism` y `.spec.completions` con valores mayores que 1, +entonces puede que haya múltiples pods ejecutándose a la vez. Por ello, tus pods deben tolerar la concurrencia. + +### Regla de retroceso de Pod por fallo + +Hay situaciones en que quieres que el Job falle después de intentar ejecutarlo unas cuantas veces debido +a un error lógico en la configuración, etc. +Para hacerlo, pon el valor de `.spec.backoffLimit` al número de reintentos que quieres +antes de considerar el Job como fallido. El límite de retroceso se predetermina a 6. +Los Pods fallidos asociados al Job son recreados por el controlador del Job con un +retroceso exponencial (10s, 20s, 40s ...) limitado a seis minutos. El contador +de retroceso se resetea si no aparecen Pods fallidos antes del siguiente chequeo de estado del Job. + +{{< note >}} +El problema [#54870](https://github.com/kubernetes/kubernetes/issues/54870) todavía existe en las versiones de Kubernetes anteriores a la versión 1.12 +{{< /note >}} + +## Terminación y Limpieza de un Job + +Cuando un Job se completa, ya no se crea ningún Pod, pero tampoco se elimina los Pods. Guardarlos permite +ver todavía los logs de los pods acabados para comprobar errores, avisos, o cualquier otro resultado de diagnóstico. +El objeto job también se conserva una vez que se ha completado para que se pueda ver su estado. Es decisión del usuario si elimina +los viejos jobs después de comprobar su estado. Eliminar el job con el comando `kubectl` (ej. `kubectl delete jobs/pi` o `kubectl delete -f ./job.yaml`). +Cuando eliminas un job usando el comando `kubectl`, todos los pods que creó se eliminan también. + +Por defecto, un Job se ejecutará de forma ininterrumpida a menos que uno de los Pods falle, en cuyo caso el Job se fija en el valor de +`.spec.backoffLimit` descrito arriba. Otra forma de acabar un Job es poniéndole un vencimiento activo. +Haz esto poniendo el valor del campo `.spec.activeDeadlineSeconds` del Job a un número de segundos. + +El campo `activeDeadlineSeconds` se aplica a la duración del job, independientemente de cuántos Pods se hayan creado. +Una vez que el Job alcanza `activeDeadlineSeconds`, se terminan todos sus Pods y el estado del Job se pone como `type: Failed` con `reason: DeadlineExceeded`. + +Fíjate que el campo `.spec.activeDeadlineSeconds` de un Job tiene precedencia sobre el campo `.spec.backoffLimit`. +Por lo tanto, un Job que está reintentando uno o más Pods fallidos no desplegará nuevos Pods una vez que alcance el límite de tiempo especificado por `activeDeadlineSeconds`, +incluso si todavía no se ha alcanzado el `backoffLimit`. + +Ejemplo: + +```yaml +apiVersion: batch/v1 +kind: Job +metadata: + name: pi-with-timeout +spec: + backoffLimit: 5 + activeDeadlineSeconds: 100 + template: + spec: + containers: + - name: pi + image: perl + command: ["perl", "-Mbignum=bpi", "-wle", "print bpi(2000)"] + restartPolicy: Never +``` + +Fíjate que tanto la especificación del Job como la [especificación de la plantilla Pod](/docs/concepts/workloads/pods/init-containers/#detailed-behavior) +dentro del Job tienen un campo `activeDeadlineSeconds`. Asegúrate que pones el valor de este campo de forma adecuada. + +## Limpiar los Jobs terminados automáticamente + +Normalmente, los Jobs que han terminado ya no se necesitan en el sistema. Conservarlos sólo añade +más presión al servidor API. Si dichos Jobs no se gestionan de forma directa por un controlador de más alto nivel, +como los [CronJobs](/docs/concepts/workloads/controllers/cron-jobs/), los Jobs pueden +limpiarse por medio de CronJobs en base a la regla de limpieza basada en capacidad que se haya especificado. + +### Mecanismo TTL para Jobs terminados + +{{< feature-state for_k8s_version="v1.12" state="alpha" >}} + +Otra forma de limpiar los Jobs terminados (bien `Complete` o `Failed`) +de forma automática es usando un mecanismo TTL proporcionado por un +[controlador TTL](/docs/concepts/workloads/controllers/ttlafterfinished/) de recursos finalizados, +indicando el valor `.spec.ttlSecondsAfterFinished` del Job. + +Cuando el controlador TTL limpia el Job, lo eliminará en cascada, +esto es, eliminará sus objetos subordinados, como Pods, junto con el Job. Nótese +que cuando se elimina el Job, sus garantías de ciclo de vida, como los finalizadores, +se tendrán en cuenta. + +Por ejemplo: + +```yaml +apiVersion: batch/v1 +kind: Job +metadata: + name: pi-with-ttl +spec: + ttlSecondsAfterFinished: 100 + template: + spec: + containers: + - name: pi + image: perl + command: ["perl", "-Mbignum=bpi", "-wle", "print bpi(2000)"] + restartPolicy: Never +``` + +Aquí el Job `pi-with-ttl` será candidato a ser automáticamente eliminado, `100` +segundos después de que termine. + +Si el campo se pone a `0`, el Job será candidato a ser automáticamente eliminado +inmediatamente después de haber terminado. Si no se pone valor al campo, este Job no será eliminado +por el controlador TTL una vez concluya. + +Nótese que este mecanismo TTL está todavía en alpha, a través de la característica denominada `TTLAfterFinished`. +Para más información, ver la documentación del [controlador TTL](/docs/concepts/workloads/controllers/ttlafterfinished/) para +recursos terminados. + +## Patrones de Job + +El objeto Job puede usarse para dar soporte a la ejecución fiable de Pods en paralelo. El objeto Job +no se diseñó para dar soporte a procesos paralelos estrechamente comunicados, como los que comúnmente +se encuentran en la computación científica. Eso sí, permite el proceso paralelo de un conjunto de *ítems de trabajo* independientes, pero relacionados entre sí. +Estos pueden ser correos a enviar, marcos a renderizar, archivos a codificar, rangos de claves en una base de datos NoSQL a escanear, y demás. + +En un sistema complejo, puede haber múltiples diferentes conjuntos de ítems de trabajo. Aquí sólo se está +considerando un conjunto de ítems de trabajo que el usuario quiere gestionar de forma conjunta — un *proceso por lotes*. + +Hay varios patrones diferentes para computación en paralelo, cada uno con sus fortalezas y sus debilidades. +Los sacrificios a tener en cuenta son: + +- Un objeto Job para cada ítem de trabajo vs. un objeto Job simple para todos los ítems de trabajo. El último es mejor + para grandes números de ítems de trabajo. El primero añade sobrecarga para el usuario y para el sistema + al tener que gestionar grandes números de objetos Job. +- El número de pods creados es igual al número de ítems de trabajo vs. cada Pod puede procesar múltiplese ítems de trabajo. + El primero típicamente requiere menos modificaciones al código existente y a los contenedores. + El último es mejor cuanto mayor sea el número de ítems de trabajo, por las mismas razones que antes.. +- Varios enfoques usan una cola de trabajo. Ello requiere ejecutar un servicio de colas, + y modificaciones a las aplicaciones o contenedores existentes para que hagan uso de la cola de trabajo. + Otras estrategias son más fáciles de adaptar a una aplicación ya usando contenedores. + + +Los sacrificios a tener en cuenta se indican a continuación, donde las columnas 2 a 4 representan los sacrificios de arriba. +Los nombres de los patrones son también enlaces a ejemplos e información más detallada. + +| Patrón | Objeto Job simple | ¿Menos pods que ítems de trabajo? | ¿No modificar la aplicación? | ¿Funciona en Kube 1.1? | +| -------------------------------------------------------------------- |:-----------------:|:---------------------------:|:-------------------:|:-------------------:| +| [Extensión de la Plantilla Job](/docs/tasks/job/parallel-processing-expansion/) | | | ✓ | ✓ | +| [Cola con Pod por Ítem de Trabajo](/docs/tasks/job/coarse-parallel-processing-work-queue/) | ✓ | | a veces | ✓ | +| [Cola con Cuenta Variable de Pods](/docs/tasks/job/fine-parallel-processing-work-queue/) | ✓ | ✓ | | ✓ | +| Job simple con Asignación Estática de Trabajo | ✓ | | ✓ | | + +Cuando se especifican terminaciones con `.spec.completions`, cada Pod creado por el controlado del Job +tiene un [`spec`](https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status)idéntico. +Esto significa que todos los pods de una tarea tendrán la misma línea de comandos y la +misma imagne, los mismo volúmenes, y (casi) las mismas variables de entorno. +Estos patrones otorgan diferentes formas de organizar los pods para que trabajen en cosas distintas. + +Esta tabla muestra la configuración necesaria para `.spec.parallelism` y `.spec.completions` para cada uno de los patrones. +Aquí, `T` es el número de ítems de trabajo. + +| Patrón | `.spec.completions` | `.spec.parallelism` | +| -------------------------------------------------------------------- |:-------------------:|:--------------------:| +| [Extensión de la Plantilla Job](/docs/tasks/job/parallel-processing-expansion/) | 1 | debería ser 1 | +| [Cola con Pod por Ítem de Trabajo](/docs/tasks/job/coarse-parallel-processing-work-queue/) | T | cualquiera | +| [Cola con Cuenta Variable de Pods](/docs/tasks/job/fine-parallel-processing-work-queue/) | 1 | cualquiera | +| Job simple con Asignación Estática de Trabajo | T | cualquiera | + + +## Uso Avanzado + +### Especificar tu propio selector de pod + +Normalmente, cuando creas un objeto Job, no especificas el campo `.spec.selector`. +La lógica por defecto del sistema añade este campo cuando se crea el Job. +Se elige un valor de selector que no se entremezcle con otras tareas. + +Sin embargo, en algunos casos, puede que necesites sobreescribir este selector que se configura de forma automática. +Para ello, puedes indicar el valor de `.spec.selector` en el Job. + +Pero ten mucho cuidado cuando lo hagas. Si configuras un selector de etiquta que no + es único para los pods de ese Job, y que selecciona Pods que no tienen que ver, + entonces estos últimos pueden ser eliminados, o este Job puede contar los otros + Pods para terminarse, o uno o ambos Jobs pueden negarse a crear Pods o ejecutarse hasta el final. + Si se elige un selector que no es único, entonces otros controladores (ej. ReplicationController) + y sus Pods puede comportarse de forma impredecibles también. Kubernetes no te impide cometer un error + especificando el `.spec.selector`. + +Aquí se muestra un ejemplo de un caso en que puede que necesites usar esta característica. + +Digamos que el Job `viejo` todavía está ejeuctándose. Quieres que los Pods existentes +sigan corriendo, pero quieres que el resto de los Pods que se creen +usen una plantilla pod diferente y que el Job tenga un nombre nuevo. +Como no puedes modificar el Job porque esos campos no son modificables, eliminas el Job `old`, + pero _dejas sus pods ejecutándose_ mediante el comando `kubectl delete jobs/old --cascade=false`. +Antes de eliminarlo, apúntate el selector actual que está usando: + +``` +kind: Job +metadata: + name: viejo + ... +spec: + selector: + matchLabels: + job-uid: a8f3d00d-c6d2-11e5-9f87-42010af00002 + ... +``` + +Entonces, creas un nuevo Job con el nombre `nuevo` y le configuras explícitamente el mismo selector. +Puesto que los Pods existentes tienen la etiqueta `job-uid=a8f3d00d-c6d2-11e5-9f87-42010af00002`, +son controlados por el Job `nuevo` igualmente. + +Necesitas configurar `manualSelector: true` en el nuevo Job, ya qye no estás usando + el selector que normalmente se genera de forma automática por el sistema. + +``` +kind: Job +metadata: + name: nuevo + ... +spec: + manualSelector: true + selector: + matchLabels: + job-uid: a8f3d00d-c6d2-11e5-9f87-42010af00002 + ... +``` + +El mismo Job nuevo tendrá un uid distinto a `a8f3d00d-c6d2-11e5-9f87-42010af00002`. +Poniendo `manualSelector: true` le dice al sistema que sabes lo que estás haciendo + y que te permita hacer este desajuste. + +## Alternativas + +### Pods simples + +Cuando el nodo donde un Pod simple se estaba ejecutando se reinicia o falla, dicho pod se termina +y no será reinicado. Sin embargo, un Job creará nuevos Pods para sustituir a los que se han terminando. +Por esta razón, se recomienda que se use un Job en vez de un Pod simple, incluso si tu aplicación +sólo necesita un único Pod. + +### Replication Controller + +Los Jobs son complementarios a los [Replication Controllers](/docs/user-guide/replication-controller). +Un Replication Controller gestiona aquellos Pods que se espera que no terminen (ej. servidores web), y un Job +gestiona aquellos Pods que se espera que terminen (ej. tareas por lotes). + +Como se discutió en el [Ciclo de vida de un Pod](/docs/concepts/workloads/pods/pod-lifecycle/), un `Job` *sólo* es apropiado +para aquellos pods con `RestartPolicy` igual a `OnFailure` o `Never`. +(Nota: Si `RestartPolicy` no se pone, el valor predeterminado es `Always`.) + +### Job simple arranca que arranca un controlador de Pod + +Otro patrón es aquel donde un Job simple crea un Pod que, a su vez, crea otros Pods, actuando como una especie +de controlador personalizado para esos Pods. Esto da la máxima flexibilidad, pero puede que +cueste un poco más de entender y ofrece menos integración con Kubernetes. + +Un ejemplo de este patrón sería un Job que arranca un Pod que ejecuta una secuencia de comandos que, a su vez, +arranca un controlador maestro de Spark (ver el [ejemplo de spark](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/staging/spark/README.md)), +ejecuta un manejador de spark, y a continuación lo limpia todo. + +Una ventaja de este enfoque es que el proceso general obtiene la garantía del objeto Job, +además del control completo de los Pods que se crean y cómo se les asigna trabajo. + +## Cron Jobs {#cron-jobs} + +Puedes utilizar un [`CronJob`](/docs/concepts/workloads/controllers/cron-jobs/) para crear un Job que se ejecute en una hora/fecha determinadas, de forma similar +a la herramienta `cron` de Unix. + + diff --git a/content/es/docs/concepts/workloads/controllers/replicaset.md b/content/es/docs/concepts/workloads/controllers/replicaset.md new file mode 100644 index 0000000000..38bbf847c6 --- /dev/null +++ b/content/es/docs/concepts/workloads/controllers/replicaset.md @@ -0,0 +1,370 @@ +--- +title: ReplicaSet +content_type: concept +weight: 10 +--- + +<!-- overview --> + +El objeto de un ReplicaSet es el de mantener un conjunto estable de réplicas de Pods ejecutándose +en todo momento. Así, se usa en numerosas ocasiones para garantizar la disponibilidad de un +número específico de Pods idénticos. + + + + +<!-- body --> + +## Cómo funciona un ReplicaSet + +Un ReplicaSet se define con campos, incluyendo un selector que indica cómo identificar a los Pods que puede adquirir, +un número de réplicas indicando cuántos Pods debería gestionar, y una plantilla pod especificando los datos de los nuevos Pods +que debería crear para conseguir el número de réplicas esperado. Un ReplicaSet alcanza entonces su propósito + mediante la creación y eliminación de los Pods que sea necesario para alcanzar el número esperado. + Cuando un ReplicaSet necesita crear nuevos Pods, utiliza su plantilla Pod. + +El enlace que un ReplicaSet tiene hacia sus Pods es a través del campo del Pod denominado [metadata.ownerReferences](/docs/concepts/workloads/controllers/garbage-collection/#owners-and-dependents), +el cual indica qué recurso es el propietario del objeto actual. Todos los Pods adquiridos por un ReplicaSet tienen su propia +información de identificación del ReplicaSet en su campo ownerReferences. Y es a través de este enlace +cómo el ReplicaSet conoce el estado de los Pods que está gestionando y actúa en consecuencia. + +Un ReplicaSet identifica los nuevos Pods a adquirir usando su selector. Si hay un Pod que no tiene OwnerReference +o donde OwnerReference no es un controlador, pero coincide con el selector del ReplicaSet, +este será inmediatamente adquirido por dicho ReplicaSet. + +## Cuándo usar un ReplicaSet + +Un ReplicaSet garantiza que un número específico de réplicas de un pod se está ejeuctando en todo momento. +Sin embargo, un Deployment es un concepto de más alto nivel que gestiona ReplicaSets y +proporciona actualizaciones de forma declarativa de los Pods junto con muchas otras características útiles. +Por lo tanto, se recomienda el uso de Deployments en vez del uso directo de ReplicaSets, a no ser +que se necesite una orquestración personalizada de actualización o no se necesite las actualizaciones en absoluto. + +En realidad, esto quiere decir que puede que nunca necesites manipular los objetos ReplicaSet: +en vez de ello, usa un Deployment, y define tu aplicación en la sección spec. + +## Ejemplo + +{{< codenew file="controllers/frontend.yaml" >}} + +Si guardas este manifiesto en un archivo llamado `frontend.yaml` y lo lanzas en un clúster de Kubernetes, + se creará el ReplicaSet definido y los Pods que maneja. + +```shell +kubectl apply -f http://k8s.io/examples/controllers/frontend.yaml +``` + +Puedes ver los ReplicaSets actuales desplegados: +```shell +kubectl get rs +``` + +Y ver el frontend que has creado: +```shell +NAME DESIRED CURRENT READY AGE +frontend 3 3 3 6s +``` + +También puedes comprobar el estado del replicaset: +```shell +kubectl describe rs/frontend +``` + +Y verás una salida parecida a la siguiente: +```shell +Name: frontend +Namespace: default +Selector: tier=frontend,tier in (frontend) +Labels: app=guestbook + tier=frontend +Annotations: <none> +Replicas: 3 current / 3 desired +Pods Status: 3 Running / 0 Waiting / 0 Succeeded / 0 Failed +Pod Template: + Labels: app=guestbook + tier=frontend + Containers: + php-redis: + Image: gcr.io/google_samples/gb-frontend:v3 + Port: 80/TCP + Requests: + cpu: 100m + memory: 100Mi + Environment: + GET_HOSTS_FROM: dns + Mounts: <none> + Volumes: <none> +Events: + FirstSeen LastSeen Count From SubobjectPath Type Reason Message + --------- -------- ----- ---- ------------- -------- ------ ------- + 1m 1m 1 {replicaset-controller } Normal SuccessfulCreate Created pod: frontend-qhloh + 1m 1m 1 {replicaset-controller } Normal SuccessfulCreate Created pod: frontend-dnjpy + 1m 1m 1 {replicaset-controller } Normal SuccessfulCreate Created pod: frontend-9si5l +``` + +Y por último, puedes comprobar los Pods que ha arrancado: +```shell +kubectl get Pods +``` + +Deberías ver la información de cada Pod similar a: +```shell +NAME READY STATUS RESTARTS AGE +frontend-9si5l 1/1 Running 0 1m +frontend-dnjpy 1/1 Running 0 1m +frontend-qhloh 1/1 Running 0 1m +``` + +También puedes verificar que la referencia de propietario de dichos pods está puesta al ReplicaSet frontend. +Para ello, obtén el yaml de uno de los Pods ejecutándose: +```shell +kubectl get pods frontend-9si5l -o yaml +``` + +La salida será parecida a esta, donde la información sobre el ReplicaSet aparece en el campo ownerReferences de los metadatos: +```shell +apiVersion: v1 +kind: Pod +metadata: + creationTimestamp: 2019-01-31T17:20:41Z + generateName: frontend- + labels: + tier: frontend + name: frontend-9si5l + namespace: default + ownerReferences: + - apiVersion: extensions/v1beta1 + blockOwnerDeletion: true + controller: true + kind: ReplicaSet + name: frontend + uid: 892a2330-257c-11e9-aecd-025000000001 +... +``` + +## Adquisiciones de Pods fuera de la plantilla + +Aunque puedes crear Pods simples sin problemas, se recomienda encarecidamente asegurarse de que dichos Pods no tienen +etiquetas que puedan coincidir con el selector de alguno de tus ReplicaSets. +La razón de esta recomendación es que un ReplicaSet no se limita a poseer los Pods +especificados en su plantilla -- sino que puede adquirir otros Pods como se explicó en secciones anteriores. + +Toma el ejemplo anterior del ReplicaSet frontend, y los Pods especificados en el siguiente manifiesto: + +{{< codenew file="pods/pod-rs.yaml" >}} + +Como estos Pods no tienen un Controlador (o cualquier otro objeto) como referencia de propietario +y como además su selector coincide con el del ReplicaSet frontend, este último los terminará adquiriendo de forma inmediata. + +Supón que creas los Pods después de que el ReplicaSet frontend haya desplegado los suyos +para satisfacer su requisito de cuenta de réplicas: + +```shell +kubectl apply -f http://k8s.io/examples/pods/pod-rs.yaml +``` + +Los nuevos Pods serán adquiridos por el ReplicaSet, e inmediatamente terminados ya que + el ReplicaSet estaría por encima del número deseado. + +Obtener los Pods: +```shell +kubectl get Pods +``` + +La salida muestra que los nuevos Pods se han terminado, o están en el proceso de terminarse: +```shell +NAME READY STATUS RESTARTS AGE +frontend-9si5l 1/1 Running 0 1m +frontend-dnjpy 1/1 Running 0 1m +frontend-qhloh 1/1 Running 0 1m +pod2 0/1 Terminating 0 4s +``` + +Si creas primero los Pods: +```shell +kubectl apply -f http://k8s.io/examples/pods/pod-rs.yaml +``` + +Y entonces creas el ReplicaSet: +```shell +kubectl apply -f http://k8s.io/examples/controllers/frontend.yaml +``` + +Verás que el ReplicaSet ha adquirido dichos Pods y simplemente ha creado tantos nuevos +como necesarios para cumplir con su especificación hasta que el número de +sus nuevos Pods y los originales coincidan con la cuenta deseado. Al obtener los Pods: +```shell +kubectl get Pods +``` + +Veremos su salida: +```shell +NAME READY STATUS RESTARTS AGE +frontend-pxj4r 1/1 Running 0 5s +pod1 1/1 Running 0 13s +pod2 1/1 Running 0 13s +``` + +De esta forma, un ReplicaSet puede poseer un conjunto no homogéneo de Pods + +## Escribir un manifiesto de ReplicaSet + +Al igual que con el esto de los objeto de la API de Kubernetes, un ReplicaSet necesita los campos +`apiVersion`, `kind`, y `metadata`. Para los ReplicaSets, el tipo es siempre ReplicaSet. +En la versión 1.9 de Kubernetes, la versión `apps/v1` de la API en un tipo ReplicaSet es la versión actual y está habilitada por defecto. +La versión `apps/v1beta2` de la API se ha desaprobado. +Consulta las primeras líneas del ejemplo `frontend.yaml` como guía. + +Un ReplicaSet también necesita una [sección `.spec`](https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status). + +### Plantilla Pod + +El campo `.spec.template` es una [plantilla pod](/docs/concepts/workloads/Pods/pod-overview/#pod-templates) que es + también necesita obligatoriamente tener etiquetas definidas. En nuestro ejemplo `frontend.yaml` teníamos una etiqueta: `tier: frontend`. +Lleva cuidado de que no se entremezcle con los selectores de otros controladores, no sea que traten de adquirir este Pod. + +Para el campo de [regla de reinicio](/docs/concepts/workloads/Pods/pod-lifecycle/#restart-policy) de la plantilla, +`.spec.template.spec.restartPolicy`, el único valor permitido es `Always`, que es el valor predeterminado. + +### Selector de Pod + +El campo `.spec.selector` es un [selector de etiqueta](/docs/concepts/overview/working-with-objects/labels/). +Como se explicó [anteriormente](#how-a-replicaset-works), estas son las etiquetas que se usan para + identificar los Pods potenciales a adquirir. En nuestro ejemplo `frontend.yaml`, el selector era: +```shell +matchLabels: + tier: frontend +``` + +El el ReplicaSet, `.spec.template.metadata.labels` debe coincidir con `spec.selector`, o será + rechazado por la API. + +{{< note >}} +Cuando 2 ReplicaSets especifican el mismo campo `.spec.selector`, pero los campos +`.spec.template.metadata.labels` y `.spec.template.spec` diferentes, cada ReplicaSet +ignora los Pods creados por el otro ReplicaSet. +{{< /note >}} + +### Réplicas + +Puedes configurar cuántos Pods deberían ejecutarse de forma concurrente indicando el campo `.spec.replicas`. +El ReplicaSet creará/eliminará sus Pods para alcanzar este número. + +Si no indicas el valor del campo `.spec.replicas`, entonces por defecto se inicializa a 1. + +## Trabajar con ReplicaSets + +### Eliminar un ReplicaSet y sus Pods + +Para eliminar un ReplicaSet y todos sus Pods, utiliza el comando [`kubectl delete`](/docs/reference/generated/kubectl/kubectl-commands#delete). +El [Recolector de basura](/docs/concepts/workloads/controllers/garbage-collection/) eliminará automáticamente + todos los Pods subordinados por defecto. + +Cuando se usa la API REST o la librería `client-go`, se debe poner el valor de `propagationPolicy` a `Background` o +`Foreground` en la opción -d. +Por ejemplo: +```shell +kubectl proxy --port=8080 +curl -X DELETE 'localhost:8080/apis/extensions/v1beta1/namespaces/default/replicasets/frontend' \ +> -d '{"kind":"DeleteOptions","apiVersion":"v1","propagationPolicy":"Foreground"}' \ +> -H "Content-Type: application/json" +``` + +### Eliminar sólo un ReplicaSet + +Se puede eliminar un ReplicaSet sin afectar a ninguno de sus Pods usando el comando [`kubectl delete`](/docs/reference/generated/kubectl/kubectl-commands#delete) con la opción `--cascade=false`. +Cuando se usa la API REST o la librería `client-go`, se debe poner `propagationPolicy` a `Orphan`. +Por ejemplo: +```shell +kubectl proxy --port=8080 +curl -X DELETE 'localhost:8080/apis/extensions/v1beta1/namespaces/default/replicasets/frontend' \ +> -d '{"kind":"DeleteOptions","apiVersion":"v1","propagationPolicy":"Orphan"}' \ +> -H "Content-Type: application/json" +``` + +Una vez que se ha eliminado el original, se puede crear un nuevo ReplicaSet para sustituirlo. +Mientras el viejo y el nuevo `.spec.selector` sean el mismo, el nuevo adoptará a los viejos Pods. +Sin embargo, no se esforzará en conseguir que los Pods existentes coincidan con una plantilla pod nueva, diferente. +Para actualizar dichos Pods a la nueva especificación de forma controlada, +usa una [actualización en línea](#rolling-updates). + +### Aislar Pods de un ReplicaSet + +Es posible aislar Pods de un ReplicaSet cambiando sus etiquetas. Esta técnica puede usarse +para eliminar Pods de un servicio para poder depurar, recuperar datos, etc. Los Pods +que se eliminar de esta forma serán sustituidos de forma automática (siempre que el +número de réplicas no haya cambiado). + +### Escalar un ReplicaSet + +Se puede aumentar o reducir fácilmente un ReplicaSet simplemente actualizando el campo `.spec.replicas`. +El controlador del ReplicaSet se asegura de que el número deseado de Pods con un selector +de etiquetas coincidente está disponible y operacional. + +### ReplicaSet como blanco de un Horizontal Pod Autoscaler + +Un ReplicaSet puede también ser el blanco de un +[Horizontal Pod Autoscalers (HPA)](/docs/tasks/run-application/horizontal-pod-autoscale/). Esto es, +un ReplicaSet puede auto-escalarse mediante un HPA. Aquí se muestra un ejemplo de HPA dirigido +al ReplicaSet que creamos en el ejemplo anterior. + +{{< codenew file="controllers/hpa-rs.yaml" >}} + +Si guardas este manifiesto en un archivo `hpa-rs.yaml` y lo lanzas contra el clúster de Kubernetes, +debería crear el HPA definido que auto-escala el ReplicaSet destino dependiendo del uso +de CPU de los Pods replicados. + +```shell +kubectl apply -f https://k8s.io/examples/controllers/hpa-rs.yaml +``` + +Alternativamente, puedes usar el comando `kubectl autoscale` para conseguir el mismo objetivo +(¡y mucho más fácil!) + +```shell +kubectl autoscale rs frontend --max=10 +``` + +## Alternativas al ReplicaSet + +### Deployment (recomendado) + +Un[`Deployment`](/docs/concepts/workloads/controllers/deployment/) es un objeto que puede poseer ReplicaSets +y actualizar a estos y a sus Pods mediante actualizaciones en línea declarativas en el servidor. +Aunque que los ReplicaSets puede usarse independientemente, hoy en día se usan principalmente a través de los Deployments +como el mecanismo para orquestrar la creación, eliminación y actualización de los Pods. +Cuando usas Deployments no tienes que preocuparte de gestionar los ReplicaSets que crean. +Los Deployments poseen y gestionan sus ReplicaSets. +Por tanto, se recomienda que se use Deployments cuando se quiera ReplicaSets. + +### Pods simples + +A diferencia del caso en que un usuario creaba Pods de forma directa, un ReplicaSet sustituye los Pods que se eliminan +o se terminan por la razón que sea, como en el caso de un fallo de un nodo o +una intervención disruptiva de mantenimiento, como una actualización de kernel. +Por esta razón, se recomienda que se use un ReplicaSet incluso cuando la aplicación +sólo necesita un único Pod. Entiéndelo de forma similar a un proceso supervisor, +donde se supervisa múltiples Pods entre múltiples nodos en vez de procesos individuales +en un único nodo. Un ReplicaSet delega los reinicios del contenedor local a algún agente +del nodo (por ejemplo, Kubelet o Docker). + +### Job + +Usa un [`Job`](/docs/concepts/jobs/run-to-completion-finite-workloads/) en vez de un ReplicaSet para + aquellos Pods que se esperan que terminen por ellos mismos (esto es, trabajos por lotes). + +### DaemonSet + +Usa un [`DaemonSet`](/docs/concepts/workloads/controllers/daemonset/) en vez de un ReplicaSet para aquellos + Pods que proporcionan funcionalidad a nivel de servidor, como monitorización de servidor o + logging de servidor. Estos Pods tienen un ciclo de vida asociado al del servidor mismo: + el Pod necesita ejecutarse en el servidor antes de que los otros Pods comiencen, y es seguro + que terminen cuando el servidor esté listo para ser reiniciado/apagado. + +### ReplicationController +Los ReplicaSets son los sucesores de los [_ReplicationControllers_](/docs/concepts/workloads/controllers/replicationcontroller/). +Los dos sirven al mismo propósito, y se comportan de forma similar, excepto porque un ReplicationController +no soporta los requisitos del selector basado en conjunto, como se describe en la [guía de usuario de etiquetas](/docs/concepts/overview/working-with-objects/labels/#label-selectors). +Por ello, se prefiere los ReplicaSets a los ReplicationControllers. + + diff --git a/content/es/docs/concepts/workloads/controllers/replicationcontroller.md b/content/es/docs/concepts/workloads/controllers/replicationcontroller.md index 970eb4e8ec..5fe6c94c1e 100644 --- a/content/es/docs/concepts/workloads/controllers/replicationcontroller.md +++ b/content/es/docs/concepts/workloads/controllers/replicationcontroller.md @@ -281,7 +281,7 @@ Incluso se plantea excluir el mecanismo de creación de pods a granel ([#170](ht El ReplicationController está pensado para ser una primitiva de bloques is intended to be a composable building-block primitive. We expect higher-level APIs and/or tools to be built on top of it and other complementary primitives for user convenience in the future. The "macro" operations currently supported by kubectl (run, scale, rolling-update) are proof-of-concept examples of this. For instance, we could imagine something like [Asgard](http://techblog.netflix.com/2012/06/asgard-web-based-cloud-management-and.html) managing ReplicationControllers, auto-scalers, services, scheduling policies, canaries, etc. -## Obejto API +## Objeto API El ReplicationController es un recurso de alto nivel en la API REST de Kubernetes. Más detalles acerca del objeto API se pueden encontrar aquí: diff --git a/content/es/docs/concepts/workloads/pods/pod.md b/content/es/docs/concepts/workloads/pods/pod.md index 4c6b5c7498..54ec37ce28 100644 --- a/content/es/docs/concepts/workloads/pods/pod.md +++ b/content/es/docs/concepts/workloads/pods/pod.md @@ -1,18 +1,18 @@ --- reviewers: title: Pods -content_template: templates/concept +content_type: concept weight: 20 --- -{{% capture overview %}} +<!-- overview --> Los _Pods_ son las unidades de computación desplegables más pequeñas que se pueden crear y gestionar en Kubernetes. -{{% /capture %}} -{{% capture body %}} + +<!-- body --> ## ¿Qué és un Pod? @@ -151,4 +151,4 @@ Pod es un recurso de nivel superior en la API REST de Kubernetes. La definición de [objeto de API Pod](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#pod-v1-core) describe el objeto en detalle. -{{% /capture %}} + diff --git a/content/es/docs/contribute/start.md b/content/es/docs/contribute/start.md new file mode 100644 index 0000000000..607ecc966c --- /dev/null +++ b/content/es/docs/contribute/start.md @@ -0,0 +1,207 @@ +--- +title: Empieza a contribuir +slug: start +content_type: concept +weight: 10 +card: + name: contribute + weight: 10 +--- + +<!-- overview --> + +Si quieres empezar a contribuir a la documentación de Kubernetes esta página y su temas enlazados pueden ayudarte a empezar. No necesitas ser un desarrollador o saber escribir de forma técnica para tener un gran impacto en la documentación y experiencia de usuario en Kubernetes! Todo lo que necesitas para los temas en esta página es una [Cuenta en GitHub](https://github.com/join) y un navegador web. + +Si estas buscando información sobre cómo comenzar a contribuir a los repositorios de Kubernetes, entonces dirígete a [las guías de la comunidad Kubernetes](https://github.com/kubernetes/community/blob/master/governance.md) + +<!-- body --> + +## Lo básico sobre nuestra documentación + +La documentación de Kuberentes esta escrita usando Markdown, procesada y +desplegada usando Hugo. El código fuente está en GitHub accessible en [git.k8s.io/website/](https://github.com/kubernetes/website). +La mayoría de la documentación en castellano está en `/content/es/docs`. Alguna de +la documentación de referencia se genera automática con los scripts del +directorio `/update-imported-docs`. + +Puedes clasificar incidencias, editar contenido y revisar cambios de otros, todo ello +desde la página de GitHub. También puedes usar la historia embebida de GitHub y +las herramientas de búsqueda. + +No todas las tareas se pueden realizar desde la interfaz web de GitHub, también +se discute en las guías de contribución a la documentación +[intermedia](/docs/contribute/intermediate/) y +[avanzada](/docs/contribute/advanced/) + +### Participar en la documentación de los SIG + +La documentación de Kubernetes es mantenida por el {{< glossary_tooltip text="Special Interest Group" term_id="sig" >}} (SIG) denominado SIG Docs. Nos comunicamos usando un canal de Slack, una lista de correo +y una reunión semana por video-conferencia. Siempre son bienvenidos nuevos +participantes al grupo. Para más información ver +[Participar en SIG Docs](/docs/contribute/participating/). + +### Guías de estilo + +Se mantienen unas [guías de estilo](/docs/contribute/style/style-guide/) con la información sobre las elecciones que cada comunidad SIG Docs ha realizado referente a gramática, sintaxis, formato del código fuente y convenciones tipográficas. Revisa la guía de estilos antes de hacer tu primera contribución y úsala para resolver tus dudas. + +Los cambios en la guía de estilos se hacen desde el SIG Docs como grupo. Para añadir o proponer cambios [añade tus comentarios en la agenda](https://docs.google.com/document/d/1Ds87eRiNZeXwRBEbFr6Z7ukjbTow5RQcNZLaSvWWQsE/edit#) para las próximas reuniones del SIG Docs y participe en las discusiones durante la reunión. Revisa el apartado [avanzado](/docs/contribute/advanced/) para más información. + +### Plantillas para páginas + +Se usan plantillas para las páginas de documentación con el objeto de que todas tengan la misma presentación. Asegúrate de entender como funcionan estas plantillas y revisa el apartado [Uso de plantillas para páginas](/docs/contribute/style/page-templates/). Si tienes alguna consulta, no dudes en ponerte en contacto con el resto del equipo en Slack. + +### Hugo shortcodes + +La documentación de Kubernetes se transforma a partir de Markdown para obtener HTML usando Hugo. Hay que conocer los shortcodes estándar de Hugo, así como algunos que son personalizados para la documentación de Kubernetes. Para más información de como usarlos revisa [Hugo shortcodes personalizados](/docs/contribute/style/hugo-shortcodes/). + +### Múltiples idiomas + +La documentación original está disponible en múltiples idiomas en `/content/`. Cada idioma tiene su propia carpeta con el código de dos letras determinado por el [estándar ISO 639-1](https://www.loc.gov/standards/iso639-2/php/code_list.php). Por ejemplo, la documentación original en inglés se encuentra en `/content/en/docs/`. + +Para más información sobre como contribuir a la documentación en múltiples idiomas revisa ["Localizar contenido"](/docs/contribute/intermediate#localize-content) + +Si te interesa empezar una nueva localización revisa ["Localization"](/docs/contribute/localization/). + +## Registro de incidencias + +Cualquier persona con una cuenta de GitHub puede reportar una incidencia en la documentación de Kubernetes. Si ves algo erróneo, aunque no sepas como resolverlo, [reporta una incidencia](#cómo-reportar-una-incidencia). La única excepción a la regla es si se trata de un pequeño error, como alguno que puedes resolver por ti mismo. En este último caso, puedes tratar de [resolverlo](#mejorar-contenido-existente) sin necesidad de reportar una incidencia primero. + +### Cómo reportar una incidencia + +- **En una página existente** + + Si ves un problema en una página existente en la [documentación de Kuberenetes](/docs/) ve al final de la página y haz clic en el botón **Abrir un Issue**. Si no estas autenticado en GitHub, te pedirá que te identifiques y posteriormente un formulario de nueva incidencia aparecerá con contenido pre-cargado. + + Utilizando formato Markdown completa todos los detalles que sea posible. En los lugares en que haya corchetes (`[ ]`) pon una `x` en medio de los corchetes para representar la elección de una opción. Si tienes una posible solución al problema añádela. + +- **Solicitar una nueva página** + + Si crees que un contenido debería añadirse, pero no estás seguro de donde debería añadirse o si crees que no encaja en las páginas que ya existen, puedes crear un incidente. También puedes elegir una página ya existente donde pienses que pudiera encajar y crear el incidente desde esa página, o ir directamente a [https://github.com/kubernetes/website/issues/new/](https://github.com/kubernetes/website/issues/new/) y crearlo desde allí. + +### Cómo reportar correctamente incidencias + +Para estar seguros que tu incidencia se entiende y se puede procesar ten en cuenta esta guía: + +- Usa la plantilla de incidencia y aporta detalles, cuantos más es mejor. +- Explica de forma clara el impacto de la incidencia en los usuarios. +- Mantén el alcance de una incidencia a una cantidad de trabajo razonable. Para problemas con un alcance muy amplio divídela en incidencias más pequeñas. + + Por ejemplo, "Arreglar la documentación de seguridad" no es una incidencia procesable, pero "Añadir detalles en el tema 'Restringir acceso a la red'" si lo es. +- Si la incidencia está relacionada con otra o con una petición de cambio puedes referirte a ella tanto por la URL como con el número de la incidencia o petición de cambio con el carácter `#` delante. Por ejemplo `Introducido por #987654`. +- Se respetuoso y evita desahogarte. Por ejemplo, "La documentación sobre X apesta" no es útil o una crítica constructiva. El [Código de conducta](/community/code-of-conduct/) también aplica para las interacciones en los repositorios de Kubernetes en GitHub. + +## Participa en las discusiones de SIG Docs + +El equipo de SIG Docs se comunica por las siguientes vías: + +- [Únete al Slack de Kubernetes](http://slack.k8s.io/) y entra al canal `#sig-docs` o `#kubernetes-docs-es` para la documentación en castellano. En Slack, discutimos sobre las incidencias de documentación en tiempo real, nos coordinamos y hablamos de temas relacionados con la documentación. No olvides presentarte cuando entres en el canal para que podamos saber un poco más de ti! +- [Únete a la lista de correo `kubernetes-sig-docs`](https://groups.google.com/forum/#!forum/kubernetes-sig-docs), donde tienen lugar las discusiones más amplias y se registran las decisiones oficiales. +- Participa en la video-conferencia [semanal de SIG Docs](https://github.com/kubernetes/community/tree/master/sig-docs), esta se anuncia en el canal de Slack y la lista de correo. Actualmente esta reunión tiene lugar usando Zoom, por lo que necesitas descargar el [cliente Zoom](https://zoom.us/download) o llamar usando un teléfono. + +{{< note >}} +Puedes revisar la reunión semanal de SIG Docs en el [Calendario de reuniones de la comunidad Kubernetes](https://calendar.google.com/calendar/embed?src=cgnt364vd8s86hr2phapfjc6uk%40group.calendar.google.com&ctz=America/Los_Angeles). +{{< /note >}} + +## Mejorar contenido existente + +Para mejorar contenido existente crea una _pull request(PR)_ después de crear un _fork_. Estos términos son [específicos de GitHub](https://help.github.com/categories/collaborating-with-issues-and-pull-requests/). No es necesario conocer todo sobre estos términos porque todo se realiza a través del navegador web. Cuando continúes con la [guía de contribución de documentación intermedia](/docs/contribute/intermediate/) entonces necesitarás un poco más de conocimiento de la metodología Git. + +{{< note >}} +**Desarrolladores de código de Kubernetes**: Si estás documentando una nueva característica para una versión futura de Kubernetes, entonces el proceso es un poco diferente. Mira el proceso y pautas en [Documentar una característica](/docs/contribute/intermediate/#sig-members-documenting-new-features) así como información sobre plazos. +{{< /note >}} + +### Firma el CNCF CLA {#firma-el-cla} + +Antes de poder contribuir o documentar en Kubernetes **es necesario** leer [Guía del contribuidor](https://github.com/kubernetes/community/blob/master/contributors/guide/README.md) y [firmar el `Contributor License Agreement` (CLA)](https://github.com/kubernetes/community/blob/master/CLA.md). No te preocupes esto no lleva mucho tiempo! + +### Busca algo con lo que trabajar + +Si ves algo que quieras arreglar directamente, simplemente sigue las instrucciones más abajo. No es necesario que [reportes una incidencia](#registro-de-incidencias) (aunque de todas formas puedes). + +Si quieres empezar por buscar una incidencia existente para trabajar puedes ir [https://github.com/kubernetes/website/issues](https://github.com/kubernetes/website/issues) y buscar una incidencia con la etiqueta `good first issue` (puedes usar [este](https://github.com/kubernetes/website/issues?q=is%3Aopen+is%3Aissue+label%3A%22good+first+issue%22) atajo). Lee los comentarios y asegurate de que no hay una petición de cambio abierta para esa incidencia y que nadie a dejado un comentario indicando que están trabajando en esa misma incidencia recientemente (3 días es una buena regla). Deja un comentario indicando que te gustaría trabajar en la incidencia. + +### Elije que rama de Git usar + +El aspecto más importante a la hora de mandar una petición de cambio es que rama usar como base para trabajar. Usa estas pautas para tomar la decisión: + +- Utiliza `master` para arreglar problemas en contenido ya existente publicado, o hacer mejoras en contenido ya existente. + - Utiliza una rama de versión (cómo `dev-{{< release-branch >}}` para la versión {{< release-branch>}}) para documentar futuras características o cambios para futuras versiones que todavía no se han publicado. +- Utiliza una rama de características que haya sido acordada por SIG Docs para colaborar en grandes mejoras o cambios en la documentación existente, incluida la reorganización de contenido o cambios en la apariencia del sitio web. + +Si todavía no estás seguro con que rama utilizar, pregunta en `#sig-docs`en Slack o atiende una reunión semanal del SIG Docs para aclarar tus dudas. + +### Enviar una petición de cambio + +Sigue estos pasos para enviar una petición de cambio y mejorar la documentación de Kubernetes. + +1. En la página que hayas visto una incidencia haz clic en el icono del lápiz arriba a la derecha. + Una nueva página de GitHub aparecerá con algunos textos de ayuda. +2. Si nunca has creado un copia del repositorio de documentación de Kubernetes te pedirá que lo haga. + Crea la copia bajo tu usuario de GitHub en lugar de otra organización de la que seas miembro. La copia generalmente tiene una URL como `https://github.com/<username>/website`, a menos que ya tengas un repositorio con un nombre en conflicto con este. + + La razón por la que se pide crear una copia del repositorio es porque no tienes permisos para subir cambios directamente a rama en el repositorio original de Kubernetes. +3. Aparecerá el editor Markdown de GitHub con el fichero Markdown fuente cargado. Realiza tus cambios. Debajo del editor completa el formulario **Propose file change**. El primer campo es el resumen del mensaje de tu commit y no debe ser más largo de 50 caracteres. El segundo campo es opcional, pero puede incluir más información y detalles si procede. + + {{< note >}} + No incluyas referencias a otras incidencias o peticiones de cambio de GitHub en el mensaje de los commits. Esto lo puedes añadir después en la descripción de la petición de cambio. +{{< /note >}} + + Haz clic en **Propose file change**. El cambio se guarda como un commit en una nueva rama de tu copia, automáticamente se le asignará un nombre estilo `patch-1`. + +4. La siguiente pantalla resume los cambios que has hecho pudiendo comparar la nueva rama (la **head fork** y cajas de selección **compare**) con el estado actual del **base fork** y la rama **base** (`master` en el repositorio por defecto `kubernetes/website`). Puedes cambiar cualquiera de las cajas de selección, pero no lo hagas ahora. Hecha un vistazo a las distintas vistas en la parte baja de la pantalla y si todo parece correcto haz clic en **Create pull request**. + + {{< note >}} + Si no deseas crear una petición de cambio puedes hacerlo más delante, solo basta con navegar a la URL principal del repositorio de Kubernetes website o de tu copia. La página de GitHub te mostrará un mensaje para crear una petición de cambio si detecta que has subido una nueva rama a tu repositorio copia. + {{< /note >}} + +5. La pantalla **Open a pull request** aparece. El tema de una petición de cambio es el resumen del commit, pero puedes cambiarlo si lo necesitas. El cuerpo está pre-cargado con el mensaje del commit extendido (si lo hay) junto con una plantilla. Lee la plantilla y llena los detalles requeridos, entonces borra el texto extra de la plantilla. Deja la casilla **Allow edits from maintainers** seleccionada. Haz clic en **Create pull request**. + + Enhorabuena! Tu petición de cambio está disponible en [Pull requests](https://github.com/kubernetes/website/pulls). + + Después de unos minutos ya podrás pre-visualizar la página con los cambios de tu PR aplicados. Ve a la pestaña de **Conversation** en tu PR y haz clic en el enlace **Details** para ver el test `deploy/netlify`, localizado casi al final de la página. Se abrirá en la misma ventana del navegado por defecto. + +6. Espera una revisión. Generalmente `k8s-ci-robot` sugiere unos revisores. Si un revisor te pide que hagas cambios puedes ir a la pestaña **FilesChanged** y hacer clic en el icono del lápiz para hacer tus cambios en cualquiera de los ficheros en la petición de cambio. Cuando guardes los cambios se creará un commit en la rama asociada a la petición de cambio. + +7. Si tu cambio es aceptado, un revisor fusionará tu petición de cambio y tus cambios serán visibles en pocos minutos en la web de [kubernetes.io](https://kubernetes.io). + +Esta es solo una forma de mandar una petición de cambio. Si eres un usuario de Git y GitHub avanzado puedes usar una aplicación GUI local o la linea de comandos con el cliente Git en lugar de usar la UI de GitHub. Algunos conceptos básicos sobre el uso de la línea de comandos Git +cliente se discuten en la guía de documentación [intermedia](/docs/contribute/intermediate/). + +## Revisar peticiones de cambio de documentación + +Las personas que aún no son aprobadores o revisores todavía pueden revisar peticiones de cambio. Las revisiones no se consideran "vinculantes", lo que significa que su revisión por sí sola no hará que se fusionen las peticiones de cambio. Sin embargo, aún puede ser útil. Incluso si no deja ningún comentario de revisión, puede tener una idea de las convenciones y etiquetas en una petición de cambio y acostumbrarse al flujo de trabajo. + +1. Ve a [https://github.com/kubernetes/website/pulls](https://github.com/kubernetes/website/pulls). Desde ahí podrás ver una lista de todas las peticiones de cambio en la documentación del website de Kubernetes. + +2. Por defecto el único filtro que se aplica es `open`, por lo que no puedes ver las que ya se han cerrado o fusionado. Es una buena idea aplicar el filtro `cncf-cla: yes` y para tu primera revisión es una buena idea añadir `size/S` o `size/XS`. La etiqueta `size` se aplica automáticamente basada en el número de lineas modificadas en la PR. Puedes aplicar filtros con las cajas de selección al principio de la página, o usar [estos atajos](https://github.com/kubernetes/website/pulls?q=is%3Aopen+is%3Apr+label%3A%22cncf-cla%3A+yes%22+label%3Asize%2FS) solo para PRs pequeñas. Los filtros son aplicados con `AND` todos juntos, por lo que no se puede buscar a la vez `size/S` y `size/XS` en la misma consulta. + +3. Ve a la pestaña **Files changed**. Mira los cambios introducidos en la PR, y si aplica, mira también los incidentes enlazados. Si ves un algún problema o posibilidad de mejora pasa el cursor sobre la línea y haz click en el símbolo `+` que aparece. + + Puedes entonces dejar un comentario seleccionando **Add single comment** o **Start a review**. Normalmente empezar una revisión es la forma recomendada, ya que te permite hacer varios comentarios y avisar a propietario de la PR solo cuando tu revisión este completada, en lugar de notificar cada comentario. + +4. Cuando hayas acabado de revisar, haz clic en **Review changes** en la parte superior de la página. Puedes ver un resumen de la revisión y puedes elegir entre comentar, aprobar o solicitar cambios. Los nuevos contribuidores siempre deben elegir **Comment**. + +Gracias por revisar una petición de cambio! Cuando eres nuevo en un proyecto es buena idea solicitar comentarios y opiniones en las revisiones de una petición de cambio. Otro buen lugar para solicitar comentarios es en el canal de Slack `#sig-docs`. + +## Escribir un artículo en el blog + +Cualquiera puede escribir un articulo en el blog y enviarlo para revisión. Los artículos del blog no deben ser comerciales y deben consistir en contenido que se pueda aplicar de la forma más amplia posible a la comunidad de Kubernetes. + +Para enviar un artículo al blog puedes hacerlo también usando el formulario [Kubernetes blog submission form](https://docs.google.com/forms/d/e/1FAIpQLSch_phFYMTYlrTDuYziURP6nLMijoXx_f7sLABEU5gWBtxJHQ/viewform), o puedes seguir los siguientes pasos. + +1. [Firma el CLA](#sign-the-cla) si no lo has hecho ya. +2. Revisa el formato Markdown en los artículos del blog existentes en el [repositorio website](https://github.com/kubernetes/website/tree/master/content/en/blog/_posts). +3. Escribe tu artículo usando el editor de texto que prefieras. +4. En el mismo enlace que el paso 2 haz clic en botón **Create new file**. Pega el contenido de tu editor. Nombra el fichero para que coincida con el título del artículo, pero no pongas la fecha en el nombre. Los revisores del blog trabajarán contigo en el nombre final del fichero y la fecha en la que será publicado. +5. Cuando guardes el fichero, GitHub te guiará en el proceso de petición de cambio. +6. Un revisor de artículos del blog revisará tu envío y trabajará contigo aportando comentarios y los detalles finales. Cuando el artículo sea aprobado, se establecerá una fecha de publicación. + +## Envía un caso de estudio + +Un caso de estudio destaca como organizaciones están usando Kubernetes para resolver problemas del mundo real. Estos se escriben en colaboración con el equipo de marketing de Kubernetes que está dirigido por la {{< glossary_tooltip text="CNCF" term_id="cncf" >}}. + +Revisa el código fuente para ver los [casos de estudio existentes](https://github.com/kubernetes/website/tree/master/content/en/case-studies). Usa el formulario [Kubernetes case study submission form](https://www.cncf.io/people/end-user-community/) para enviar tu propuesta. + +## {{% heading "whatsnext" %}} + +Cuando entiendas mejor las tareas mostradas en este tema y quieras formar parte del equipo de documentación de Kubernetes de una forma más activa lee la [guía intermedia de contribución](/docs/contribute/intermediate/). \ No newline at end of file diff --git a/content/es/docs/reference/_index.md b/content/es/docs/reference/_index.md index 070cb93765..a3625a903e 100644 --- a/content/es/docs/reference/_index.md +++ b/content/es/docs/reference/_index.md @@ -49,11 +49,11 @@ En estos momento, las librerías con soporte oficial son: * [kubelet](/docs/admin/kubelet/) - El principal *agente* que se ejecuta en cada nodo. El kubelet toma un conjunto de PodSpecs y asegura que los contenedores descritos estén funcionando y en buen estado. * [kube-apiserver](/docs/admin/kube-apiserver/) - API REST que valida y configura datos para objetos API como pods, servicios, controladores de replicación, ... -* [kube-controller-manager](/docs/admin/kube-controller-manager/) - Demonio que integra los bucles de control enviados con Kubernetes. +* [kube-controller-manager](/docs/admin/kube-controller-manager/) - Daemon que integra los bucles de control enviados con Kubernetes. * [kube-proxy](/docs/admin/kube-proxy/) - Puede hacer fowarding simple o con round-robin de TCP/UDP a través de un conjunto de back-ends. * [kube-scheduler](/docs/admin/kube-scheduler/) - Planificador que gestiona la disponibilidad, el rendimiento y la capacidad. * [federation-apiserver](/docs/admin/federation-apiserver/) - Servidor API para clusters federados. -* [federation-controller-manager](/docs/admin/federation-controller-manager/) - Demonio que integra los bucles de control enviados con la federación Kubernetes. +* [federation-controller-manager](/docs/admin/federation-controller-manager/) - Proceso que integra los bucles de control enviados con la federación Kubernetes. ## Documentos de diseño diff --git a/content/es/docs/reference/glossary/configmap.md b/content/es/docs/reference/glossary/configmap.md new file mode 100644 index 0000000000..577e24dc1f --- /dev/null +++ b/content/es/docs/reference/glossary/configmap.md @@ -0,0 +1,18 @@ +--- +title: Configmap +id: configmap +date: 2020-07-11 +full_link: /docs/concepts/configuration/configmap/ +short_description: > + Almacena información no sensible. + +aka: +tags: +- workload +--- +Un objeto de la API utilizado para almacenar datos no confidenciales en el formato clave-valor. Los {{< glossary_tooltip text="Pods" term_id="pod" >}} pueden utilizar los ConfigMaps como variables de entorno, argumentos de la linea de comandos o como ficheros de configuración en un {{< glossary_tooltip text="Volumen" term_id="volume" >}}. + +Un ConfigMap te permite desacoplar la configuración de un entorno específico de una imagen de contenedor, así las aplicaciones son fácilmente portables. + +<!--more--> + diff --git a/content/es/docs/reference/glossary/controller.md b/content/es/docs/reference/glossary/controller.md new file mode 100755 index 0000000000..8258d0ae86 --- /dev/null +++ b/content/es/docs/reference/glossary/controller.md @@ -0,0 +1,33 @@ +--- +title: Controlador +id: controller +date: 2018-04-12 +full_link: /docs/concepts/architecture/controller/ +short_description: > + Los controladores son bucles de control que observan el estado del clúster, + y ejecutan o solicitan los cambios que sean necesarios para alcanzar el estado + deseado. + +aka: +tags: +- architecture +- fundamental +--- + +En Kubernetes, los controladores son bucles de control que observan el estado del +{{< glossary_tooltip term_id="cluster" text="clúster">}}, y ejecutan o solicitan +los cambios que sean necesarios para llevar el estado actual del clúster más +cerca del estado deseado. + +<!--more--> + +Los controladores observan el estado compartido del clúster a través del +{{< glossary_tooltip text="API Server" term_id="kube-apiserver" >}} (parte del +{{< glossary_tooltip term_id="control-plane" text="plano de control" >}}). + +Algunos controladores también se ejecutan dentro del mismo plano de control, +proporcionado los bucles de control necesarios para las operaciones principales +de Kubernetes. Por ejemplo, el controlador de Deployments, el controlador de +DaemonSets, el controlador de Namespaces y el controlador de volúmenes +persistentes, entre otros, se ejecutan dentro del +{{< glossary_tooltip term_id="kube-controller-manager" >}}. diff --git a/content/es/docs/reference/glossary/etcd.md b/content/es/docs/reference/glossary/etcd.md new file mode 100755 index 0000000000..5ac470a85c --- /dev/null +++ b/content/es/docs/reference/glossary/etcd.md @@ -0,0 +1,24 @@ +--- +title: etcd +id: etcd +date: 2018-04-12 +full_link: /docs/tasks/administer-cluster/configure-upgrade-etcd/ +short_description: > + Almacén de datos persistente, consistente y distribuido de clave-valor utilizado + para almacenar toda a la información del clúster de Kubernetes. + +aka: +tags: +- architecture +- storage +--- + +Almacén de datos persistente, consistente y distribuido de clave-valor utilizado +para almacenar toda a la información del clúster de Kubernetes. + +<!--more--> + +Si tu clúster utiliza etcd como sistema de almacenamiento, échale un vistazo a la +documentación sobre [estrategias de backup](/docs/tasks/administer-cluster/configure-upgrade-etcd/#backing-up-an-etcd-cluster). + +Puedes encontrar información detallada sobre etcd en su [documentación oficial](https://etcd.io/docs/). diff --git a/content/es/docs/reference/glossary/kube-apiserver.md b/content/es/docs/reference/glossary/kube-apiserver.md new file mode 100755 index 0000000000..3363f3edcb --- /dev/null +++ b/content/es/docs/reference/glossary/kube-apiserver.md @@ -0,0 +1,26 @@ +--- +title: API Server +id: kube-apiserver +date: 2020-07-01 +full_link: /docs/reference/generated/kube-apiserver/ +short_description: > + Componente del plano de control que expone la API de Kubernetes. + +aka: +- Servidor de la API +- kube-apiserver +tags: +- architecture +- fundamental +--- + +El servidor de la API es el componente del {{< glossary_tooltip text="plano de control" term_id="control-plane" >}} +de Kubernetes que expone la API de Kubernetes. Se trata del frontend de Kubernetes, +recibe las peticiones y actualiza acordemente el estado en {{< glossary_tooltip term_id="etcd" length="all" >}}. + +<!--more--> + +La principal implementación de un servidor de la API de Kubernetes es +[kube-apiserver](/docs/reference/generated/kube-apiserver/). +Es una implementación preparada para ejecutarse en alta disponiblidad y que +puede escalar horizontalmente para balancear la carga entre varias instancias. \ No newline at end of file diff --git a/content/es/docs/reference/glossary/kube-controller-manager.md b/content/es/docs/reference/glossary/kube-controller-manager.md new file mode 100755 index 0000000000..4a9bd20877 --- /dev/null +++ b/content/es/docs/reference/glossary/kube-controller-manager.md @@ -0,0 +1,21 @@ +--- +title: kube-controller-manager +id: kube-controller-manager +date: 2018-04-12 +full_link: /docs/reference/command-line-tools-reference/kube-controller-manager/ +short_description: > + Componente del plano de control que ejecuta los controladores de Kubernetes. + +aka: +tags: +- architecture +- fundamental +--- + +Componente del plano de control que ejecuta los {{< glossary_tooltip text="controladores" term_id="controller" >}} de Kubernetes. + +<!--more--> + +Lógicamente cada {{< glossary_tooltip text="controlador" term_id="controller" >}} +es un proceso independiente, pero para reducir la complejidad, todos se compilan +en un único binario y se ejecuta en un mismo proceso. diff --git a/content/es/docs/reference/glossary/kube-scheduler.md b/content/es/docs/reference/glossary/kube-scheduler.md new file mode 100755 index 0000000000..ea7914495a --- /dev/null +++ b/content/es/docs/reference/glossary/kube-scheduler.md @@ -0,0 +1,25 @@ +--- +title: kube-scheduler +id: kube-scheduler +date: 2018-04-12 +full_link: /docs/reference/generated/kube-scheduler/ +short_description: > + Componente del plano de control que está pendiente de los pods que no tienen + ningún nodo asignado y seleciona uno dónde ejecutarlo. + +aka: +tags: +- architecture +--- + +Componente del plano de control que está pendiente de los +{{< glossary_tooltip term_id="pod" text="Pods" >}} que no tienen ningún +{{< glossary_tooltip term_id="node" text="nodo">}} asignado +y seleciona uno donde ejecutarlo. + +<!--more--> + +Para decidir en qué {{< glossary_tooltip term_id="node" text="nodo">}} +se ejecutará el {{< glossary_tooltip term_id="pod" text="pod" >}}, se tienen +en cuenta diversos factores: requisitos de recursos, restricciones de hardware/software/políticas, +afinidad y anti-afinidad, localización de datos dependientes, entre otros. diff --git a/content/es/docs/reference/glossary/namespace.md b/content/es/docs/reference/glossary/namespace.md new file mode 100755 index 0000000000..4ceec4db73 --- /dev/null +++ b/content/es/docs/reference/glossary/namespace.md @@ -0,0 +1,22 @@ +--- +title: Namespace +id: namespace +date: 2018-04-12 +full_link: /es/docs/concepts/overview/working-with-objects/namespaces/ +short_description: > + Abstracción utilizada por Kubernetes para soportar múltiples clústeres virtuales en el mismo clúster físico. +aka: +- Espacio de nombres +tags: +- fundamental +--- + +Abstracción utilizada por Kubernetes para soportar múltiples clústeres virtuales +en el mismo {{< glossary_tooltip text="clúster" term_id="cluster" >}} físico. + +<!--more--> + +Los Namespaces, espacios de nombres, se utilizan para organizar objetos del clúster +proporcionando un mecanismo para dividir los recusos del clúster. Los nombres de los +objetos tienen que ser únicos dentro del mismo namespace, pero se pueden repetir en +otros namespaces del mismo clúster. \ No newline at end of file diff --git a/content/es/docs/tasks/_index.md b/content/es/docs/tasks/_index.md index 12d741e263..1b10eb1d35 100644 --- a/content/es/docs/tasks/_index.md +++ b/content/es/docs/tasks/_index.md @@ -65,23 +65,20 @@ Configura componentes en una federación de clústers. Realiza tareas comunes de gestión de aplicaciones con estado, incluyendo escalado, borrado y depuración de StatefulSets. -## Demonios del Clúster +## Daemons del Clúster Realiza tareas comunes de gestión de un DaemonSet, como llevar a cabo una actualización de lanzamiento. ## Gestionar GPUs -COnfigura y planifica GPUs de NVIDIA para hacerlas disponibles como recursos a los nodos de un clúster. +Configura y planifica GPUs de NVIDIA para hacerlas disponibles como recursos a los nodos de un clúster. ## Gestionar HugePages Configura y planifica HugePages como un recurso planificado en un clúster. - - ## {{% heading "whatsnext" %}} - Si quisieras escribir una página de Tareas, echa un vistazo a [Crear una Petición de Subida de Documentación](/docs/home/contribute/create-pull-request/). diff --git a/content/es/docs/tasks/debug-application-cluster/_index.md b/content/es/docs/tasks/debug-application-cluster/_index.md index 12bb04c317..6573112172 100644 --- a/content/es/docs/tasks/debug-application-cluster/_index.md +++ b/content/es/docs/tasks/debug-application-cluster/_index.md @@ -1,4 +1,4 @@ --- title: "Monitorización, Logs y Debugging" weight: 80 ---- \ No newline at end of file +--- diff --git a/content/es/docs/tasks/debug-application-cluster/audit.md b/content/es/docs/tasks/debug-application-cluster/audit.md new file mode 100644 index 0000000000..fc2dec9e27 --- /dev/null +++ b/content/es/docs/tasks/debug-application-cluster/audit.md @@ -0,0 +1,434 @@ +--- +content_type: concept +title: Auditoría +--- + +<!-- overview --> + +La auditoría de Kubernetes proporciona un conjunto de registros cronológicos referentes a la seguridad +que documentan la secuencia de actividades que tanto los usuarios individuales, como +los administradores y otros componentes del sistema ha realizado en el sistema. + Así, permite al administrador del clúster responder a las siguientes cuestiones: + + - ¿qué ha pasado? + - ¿cuándo ha pasado? + - ¿quién lo ha iniciado? + - ¿sobre qué ha pasado? + - ¿dónde se ha observado? + - ¿desde dónde se ha iniciado? + - ¿hacia dónde iba? + + + + +<!-- body --> + +El componente [Kube-apiserver][kube-apiserver] lleva a cabo la auditoría. Cada petición en cada fase +de su ejecución genera un evento, que se pre-procesa según un cierto reglamento y +se escribe en un backend. Este reglamento determina lo que se audita +y los backends persisten los registros. Las implementaciones actuales de backend +incluyen los archivos de logs y los webhooks. + +Cada petición puede grabarse junto con una "etapa" asociada. Las etapas conocidas son: + +- `RequestReceived` - La etapa para aquellos eventos generados tan pronto como +el responsable de la auditoría recibe la petición, pero antes de que sea delegada al +siguiente responsable en la cadena. +- `ResponseStarted` - Una vez que las cabeceras de la respuesta se han enviado, +pero antes de que el cuerpo de la respuesta se envíe. Esta etapa sólo se genera +en peticiones de larga duración (ej. watch). +- `ResponseComplete` - El cuerpo de la respuesta se ha completado y no se enviarán más bytes. +- `Panic` - Eventos que se generan cuando ocurre una situación de pánico. + +{{< note >}} +La característica de registro de auditoría incrementa el consumo de memoria del servidor API +porque requiere de contexto adicional para lo que se audita en cada petición. +De forma adicional, el consumo de memoria depende de la configuración misma del registro. +{{< /note >}} + +## Reglamento de Auditoría + +El reglamento de auditoría define las reglas acerca de los eventos que deberían registrarse y +los datos que deberían incluir. La estructura del objeto de reglas de auditoría se define +en el [`audit.k8s.io` grupo de API][auditing-api]. Cuando se procesa un evento, se compara +con la lista de reglas en orden. La primera regla coincidente establece el "nivel de auditoría" +del evento. Los niveles de auditoría conocidos son: + +- `None` - no se registra eventos que disparan esta regla. +- `Metadata` - se registra los metadatos de la petición (usuario que la realiza, marca de fecha y hora, recurso, + verbo, etc.), pero no la petición ni el cuerpo de la respuesta. +- `Request` - se registra los metadatos del evento y el cuerpo de la petición, pero no el cuerpo de la respuesta. + Esto no aplica para las peticiones que no son de recurso. +- `RequestResponse` - se registra los metadatos del evento, y los cuerpos de la petición y la respuesta. + Esto no aplica para las peticiones que no son de recurso. + +Es posible indicar un archivo al definir el reglamento en el [kube-apiserver][kube-apiserver] +usando el parámetro `--audit-policy-file`. Si dicho parámetros se omite, no se registra ningún evento. +Nótese que el campo `rules` __debe__ proporcionarse en el archivo del reglamento de auditoría. +Un reglamento sin (0) reglas se considera ilegal. + +Abajo se presenta un ejemplo de un archivo de reglamento de auditoría: + +{{< codenew file="audit/audit-policy.yaml" >}} + +Puedes usar un archivo mínimo de reglamento de auditoría para registrar todas las peticiones al nivel `Metadata` de la siguiente forma: + +```yaml +# Log all requests at the Metadata level. +apiVersion: audit.k8s.io/v1 +kind: Policy +rules: +- level: Metadata +``` + +El [perfil de auditoría utilizado por GCE][gce-audit-profile] debería servir como referencia para +que los administradores construyeran sus propios perfiles de auditoría. + +## Backends de auditoría + +Los backends de auditoría persisten los eventos de auditoría en un almacenamiento externo. +El [Kube-apiserver][kube-apiserver] por defecto proporciona tres backends: + +- Backend de logs, que escribe los eventos en disco +- Backend de webhook, que envía los eventos a una API externa +- Backend dinámico, que configura backends de webhook a través de objetos de la API AuditSink. + +En todos los casos, la estructura de los eventos de auditoría se define por la API del grupo +`audit.k8s.io`. La versión actual de la API es +[`v1`][auditing-api]. + +{{< note >}} +En el caso de parches, el cuerpo de la petición es una matriz JSON con operaciones de parcheado, en vez +de un objeto JSON que incluya el objeto de la API de Kubernetes apropiado. Por ejemplo, +el siguiente cuerpo de mensaje es una petición de parcheado válida para +`/apis/batch/v1/namespaces/some-namespace/jobs/some-job-name`. + +```json +[ + { + "op": "replace", + "path": "/spec/parallelism", + "value": 0 + }, + { + "op": "remove", + "path": "/spec/template/spec/containers/0/terminationMessagePolicy" + } +] +``` +{{< /note >}} + +### Backend de Logs + +El backend de logs escribe los eventos de auditoría a un archivo en formato JSON. + Puedes configurar el backend de logs de auditoría usando el siguiente + parámetro de [kube-apiserver][kube-apiserver] flags: + +- `--audit-log-path` especifica la ruta al archivo de log que el backend utiliza para +escribir los eventos de auditoría. Si no se especifica, se deshabilita el backend de logs. `-` significa salida estándar +- `--audit-log-maxage` define el máximo número de días a retener los archivos de log +- `--audit-log-maxbackup` define el máximo número de archivos de log a retener +- `--audit-log-maxsize` define el tamaño máximo en megabytes del archivo de logs antes de ser rotado + +### Backend de Webhook + +El backend de Webhook envía eventos de auditoría a una API remota, que se supone es la misma API +que expone el [kube-apiserver][kube-apiserver]. Puedes configurar el backend de webhook de auditoría usando +los siguientes parámetros de kube-apiserver: + +- `--audit-webhook-config-file` especifica la ruta a un archivo con configuración del webhook. +La configuración del webhook es, de hecho, un archivo [kubeconfig][kubeconfig]. +- `--audit-webhook-initial-backoff` especifica la cantidad de tiempo a esperar tras una petición fallida +antes de volver a intentarla. Los reintentos posteriores se ejecutan con retraso exponencial. + +El archivo de configuración del webhook usa el formato kubeconfig para especificar la dirección remota +del servicio y las credenciales para conectarse al mismo. + +En la versión 1.13, los backends de webhook pueden configurarse [dinámicamente](#dynamic-backend). + +### Procesamiento por lotes + +Tanto el backend de logs como el de webhook permiten procesamiento por lotes. Si usamos el webhook como ejemplo, + aquí se muestra la lista de parámetros disponibles. Para aplicar el mismo parámetro al backend de logs, + simplemente sustituye `webhook` por `log` en el nombre del parámetro. Por defecto, + el procesimiento por lotes está habilitado en `webhook` y deshabilitado en `log`. De forma similar, + por defecto la regulación (throttling) está habilitada en `webhook` y deshabilitada en `log`. + +- `--audit-webhook-mode` define la estrategia de memoria intermedia (búfer), que puede ser una de las siguientes: + - `batch` - almacenar eventos y procesarlos de forma asíncrona en lotes. Esta es la estrategia por defecto. + - `blocking` - bloquear todas las respuestas del servidor API al procesar cada evento de forma individual. + - `blocking-strict` - igual que blocking, pero si ocurre un error durante el registro de la audtoría en la etapa RequestReceived, la petición completa al apiserver fallará. + +Los siguientes parámetros se usan únicamente en el modo `batch`: + +- `--audit-webhook-batch-buffer-size` define el número de eventos a almacenar de forma intermedia antes de procesar por lotes. + Si el ritmo de eventos entrantes desborda la memoria intermedia, dichos eventos se descartan. +- `--audit-webhook-batch-max-size` define el número máximo de eventos en un único proceso por lotes. +- `--audit-webhook-batch-max-wait` define la cantidad máxima de tiempo a esperar de forma incondicional antes de procesar los eventos de la cola. +- `--audit-webhook-batch-throttle-qps` define el promedio máximo de procesos por lote generados por segundo. +- `--audit-webhook-batch-throttle-burst` define el número máximo de procesos por lote generados al mismo tiempo si el QPS permitido no fue usado en su totalidad anteriormente. + +#### Ajuste de parámetros + +Los parámetros deberían ajustarse a la carga del apiserver. + +Por ejemplo, si kube-apiserver recibe 100 peticiones por segundo, y para cada petición se audita +las etapas `ResponseStarted` y `ResponseComplete`, deberías esperar unos ~200 +eventos de auditoría generados por segundo. Asumiendo que hay hasta 100 eventos en un lote, +deberías establecer el nivel de regulación (throttling) por lo menos a 2 QPS. Además, asumiendo +que el backend puede tardar hasta 5 segundos en escribir eventos, deberías configurar el tamaño de la memoria intermedia para almacenar hasta 5 segundos de eventos, esto es, +10 lotes, o sea, 1000 eventos. + +En la mayoría de los casos, sin embargo, los valores por defecto de los parámetros +deberían ser suficientes y no deberías preocuparte de ajustarlos manualmente. +Puedes echar un vistazo a la siguientes métricas de Prometheus que expone kube-apiserver +y también los logs para monitorizar el estado del subsistema de auditoría: + +- `apiserver_audit_event_total` métrica que contiene el número total de eventos de auditoría exportados. +- `apiserver_audit_error_total` métrica que contiene el número total de eventos descartados debido a un error durante su exportación. + +### Truncado + +Tanto el backend de logs como el de webhook permiten truncado. Como ejemplo, aquí se indica la +lista de parámetros disponible para el backend de logs: + + - `audit-log-truncate-enabled` indica si el truncado de eventos y por lotes está habilitado. + - `audit-log-truncate-max-batch-size` indica el tamaño máximo en bytes del lote enviado al backend correspondiente. + - `audit-log-truncate-max-event-size` indica el tamaño máximo en bytes del evento de auditoría enviado al backend correspondiente. + +Por defecto, el truncado está deshabilitado tanto en `webhook` como en `log`; un administrador del clúster debe configurar bien el parámetro `audit-log-truncate-enabled` o `audit-webhook-truncate-enabled` para habilitar esta característica. + +### Backend dinámico + +{{< feature-state for_k8s_version="v1.13" state="alpha" >}} + +En la versión 1.13 de Kubernetes, puedes configurar de forma dinámica los backends de auditoría usando objetos de la API AuditSink. + +Para habilitar la auditoría dinámica, debes configurar los siguientes parámetros de apiserver: + +- `--audit-dynamic-configuration`: el interruptor principal. Cuando esta característica sea GA, el único parámetro necesario. +- `--feature-gates=DynamicAuditing=true`: en evaluación en alpha y beta. +- `--runtime-config=auditregistration.k8s.io/v1alpha1=true`: habilitar la API. + +Cuando se habilita, un objeto AuditSink se provisiona de la siguiente forma: + +```yaml +apiVersion: auditregistration.k8s.io/v1alpha1 +kind: AuditSink +metadata: + name: mysink +spec: + policy: + level: Metadata + stages: + - ResponseComplete + webhook: + throttle: + qps: 10 + burst: 15 + clientConfig: + url: "https://audit.app" +``` + +Para una definición completa de la API, ver [AuditSink](/docs/reference/generated/kubernetes-api/v1.13/#auditsink-v1alpha1-auditregistration). Múltiples objetos existirán como soluciones independientes. + +Aquellos backends estáticos que se configuran con parámetros en tiempo de ejecución no se ven impactados por esta característica. + Sin embargo, estos backends dinámicos comparten las opciones de truncado del webhook estático, de forma que si dichas opciones se configura con parámetros en tiempo de ejecución, entonces se aplican a todos los backends dinámicos. + +#### Reglamento + +El reglamento de AuditSink es diferente del de la auditoría en tiempo de ejecución. Esto es debido a que el objeto de la API sirve para casos de uso diferentes. El reglamento continuará +evolucionando para dar cabida a más casos de uso. + +El campo `level` establece el nivel de auditoría indicado a todas las peticiones. El campo `stages` es actualmente una lista de las etapas que se permite registrar. + +#### Seguridad + +Los administradores deberían tener en cuenta que permitir el acceso en modo escritura de esta característica otorga el modo de acceso de lectura +a toda la información del clúster. Así, el acceso debería gestionarse como un privilegio de nivel `cluster-admin`. + +#### Rendimiento + +Actualmente, esta característica tiene implicaciones en el apiserver en forma de incrementos en el uso de la CPU y la memoria. +Aunque debería ser nominal cuando se trata de un número pequeño de destinos, se realizarán pruebas adicionales de rendimiento para entender su impacto real antes de que esta API pase a beta. + +## Configuración multi-clúster + +Si estás extendiendo la API de Kubernetes mediante la [capa de agregación][kube-aggregator], puedes también +configurar el registro de auditoría para el apiserver agregado. Para ello, pasa las opciones +de configuración en el mismo formato que se describe arriba al apiserver agregado +y configura el mecanismo de ingestión de logs para que recolecte los logs de auditoría. +Cada uno de los apiservers puede tener configuraciones de auditoría diferentes con +diferentes reglamentos de auditoría. + +## Ejemplos de recolectores de Logs + +### Uso de fluentd para recolectar y distribuir eventos de auditoría a partir de un archivo de logs + +[Fluentd][fluentd] es un recolector de datos de libre distribución que proporciona una capa unificada de registros. +En este ejemplo, usaremos fluentd para separar los eventos de auditoría por nombres de espacio: + +1. Instala [fluentd][fluentd_install_doc], fluent-plugin-forest y fluent-plugin-rewrite-tag-filter en el nodo donde corre kube-apiserver +{{< note >}} +Fluent-plugin-forest y fluent-plugin-rewrite-tag-filter son plugins de fluentd. Puedes obtener detalles de la instalación de estos plugins en el documento [fluentd plugin-management][fluentd_plugin_management_doc]. +{{< /note >}} + +1. Crea un archivo de configuración para fluentd: + + ``` + cat <<'EOF' > /etc/fluentd/config + # fluentd conf runs in the same host with kube-apiserver + <source> + @type tail + # audit log path of kube-apiserver + path /var/log/kube-audit + pos_file /var/log/audit.pos + format json + time_key time + time_format %Y-%m-%dT%H:%M:%S.%N%z + tag audit + </source> + + <filter audit> + #https://github.com/fluent/fluent-plugin-rewrite-tag-filter/issues/13 + @type record_transformer + enable_ruby + <record> + namespace ${record["objectRef"].nil? ? "none":(record["objectRef"]["namespace"].nil? ? "none":record["objectRef"]["namespace"])} + </record> + </filter> + + <match audit> + # route audit according to namespace element in context + @type rewrite_tag_filter + <rule> + key namespace + pattern /^(.+)/ + tag ${tag}.$1 + </rule> + </match> + + <filter audit.**> + @type record_transformer + remove_keys namespace + </filter> + + <match audit.**> + @type forest + subtype file + remove_prefix audit + <template> + time_slice_format %Y%m%d%H + compress gz + path /var/log/audit-${tag}.*.log + format json + include_time_key true + </template> + </match> + EOF + ``` + +1. Arranca fluentd: + + ```shell + fluentd -c /etc/fluentd/config -vv + ``` + +1. Arranca el componente kube-apiserver con las siguientes opciones: + + ```shell + --audit-policy-file=/etc/kubernetes/audit-policy.yaml --audit-log-path=/var/log/kube-audit --audit-log-format=json + ``` + +1. Comprueba las auditorías de los distintos espacios de nombres en `/var/log/audit-*.log` + +### Uso de logstash para recolectar y distribuir eventos de auditoría desde un backend de webhook + +[Logstash][logstash] es una herramienta de libre distribución de procesamiento de datos en servidor. +En este ejemplo, vamos a usar logstash para recolectar eventos de auditoría a partir de un backend de webhook, +y grabar los eventos de usuarios diferentes en archivos distintos. + +1. Instala [logstash][logstash_install_doc] + +1. Crea un archivo de configuración para logstash: + + ``` + cat <<EOF > /etc/logstash/config + input{ + http{ + #TODO, figure out a way to use kubeconfig file to authenticate to logstash + #https://www.elastic.co/guide/en/logstash/current/plugins-inputs-http.html#plugins-inputs-http-ssl + port=>8888 + } + } + filter{ + split{ + # Webhook audit backend sends several events together with EventList + # split each event here. + field=>[items] + # We only need event subelement, remove others. + remove_field=>[headers, metadata, apiVersion, "@timestamp", kind, "@version", host] + } + mutate{ + rename => {items=>event} + } + } + output{ + file{ + # Audit events from different users will be saved into different files. + path=>"/var/log/kube-audit-%{[event][user][username]}/audit" + } + } + EOF + ``` + +1. Arranca logstash: + + ```shell + bin/logstash -f /etc/logstash/config --path.settings /etc/logstash/ + ``` + +1. Crea un [archivo kubeconfig](/docs/tasks/access-application-cluster/authenticate-across-clusters-kubeconfig/) para el webhook del backend de auditoría de kube-apiserver: + + cat <<EOF > /etc/kubernetes/audit-webhook-kubeconfig + apiVersion: v1 + clusters: + - cluster: + server: http://<ip_of_logstash>:8888 + name: logstash + contexts: + - context: + cluster: logstash + user: "" + name: default-context + current-context: default-context + kind: Config + preferences: {} + users: [] + EOF + +1. Arranca kube-apiserver con las siguientes opciones: + + ```shell + --audit-policy-file=/etc/kubernetes/audit-policy.yaml --audit-webhook-config-file=/etc/kubernetes/audit-webhook-kubeconfig + ``` + +1. Comprueba las auditorías en los directorios `/var/log/kube-audit-*/audit` de los nodos de logstash + +Nótese que además del plugin para salida en archivos, logstash ofrece una variedad de salidas adicionales +que permiten a los usuarios enviar la información donde necesiten. Por ejemplo, se puede enviar los eventos de auditoría +al plugin de elasticsearch que soporta búsquedas avanzadas y analíticas. + +[kube-apiserver]: /docs/admin/kube-apiserver +[auditing-proposal]: https://github.com/kubernetes/community/blob/master/contributors/design-proposals/api-machinery/auditing.md +[auditing-api]: https://github.com/kubernetes/kubernetes/blob/{{< param "githubbranch" >}}/staging/src/k8s.io/apiserver/pkg/apis/audit/v1/types.go +[gce-audit-profile]: https://github.com/kubernetes/kubernetes/blob/{{< param "githubbranch" >}}/cluster/gce/gci/configure-helper.sh#L735 +[kubeconfig]: /docs/tasks/access-application-cluster/configure-access-multiple-clusters/ +[fluentd]: http://www.fluentd.org/ +[fluentd_install_doc]: https://docs.fluentd.org/v1.0/articles/quickstart#step-1:-installing-fluentd +[fluentd_plugin_management_doc]: https://docs.fluentd.org/v1.0/articles/plugin-management +[logstash]: https://www.elastic.co/products/logstash +[logstash_install_doc]: https://www.elastic.co/guide/en/logstash/current/installing-logstash.html +[kube-aggregator]: /docs/concepts/api-extension/apiserver-aggregation + + diff --git a/content/es/docs/tasks/debug-application-cluster/debug-init-containers.md b/content/es/docs/tasks/debug-application-cluster/debug-init-containers.md new file mode 100644 index 0000000000..d4c8ae141b --- /dev/null +++ b/content/es/docs/tasks/debug-application-cluster/debug-init-containers.md @@ -0,0 +1,129 @@ +--- +title: Depurar Contenedores de Inicialización +content_type: task +--- + +<!-- overview --> + +Esta página muestra cómo investigar problemas relacionados con la ejecución +de los contenedores de inicialización (init containers). Las líneas de comando del ejemplo de abajo +se refieren al Pod como `<pod-name>` y a los Init Containers como `<init-container-1>` e + `<init-container-2>` respectivamente. + + + +## {{% heading "prerequisites" %}} + + +{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}} + +* Deberías estar familizarizado con el concepto de [Init Containers](/docs/concepts/abstractions/init-containers/). +* Deberías conocer la [Configuración de un Init Container](/docs/tasks/configure-pod-container/configure-pod-initialization/#creating-a-pod-that-has-an-init-container/). + + + +<!-- steps --> + +## Comprobar el estado de los Init Containers + +Muestra el estado de tu pod: + +```shell +kubectl get pod <pod-name> +``` + +Por ejemplo, un estado de `Init:1/2` indica que uno de los Init Containers +se ha ejecutado satisfactoriamente: + +``` +NAME READY STATUS RESTARTS AGE +<pod-name> 0/1 Init:1/2 0 7s +``` + +Echa un vistazo a [Comprender el estado de un Pod](#understanding-pod-status) para más ejemplos +de valores de estado y sus significados. + +## Obtener detalles acerca de los Init Containers + +Para ver información detallada acerca de la ejecución de un Init Container: + +```shell +kubectl describe pod <pod-name> +``` + +Por ejemplo, un Pod con dos Init Containers podría mostrar lo siguiente: + +``` +Init Containers: + <init-container-1>: + Container ID: ... + ... + State: Terminated + Reason: Completed + Exit Code: 0 + Started: ... + Finished: ... + Ready: True + Restart Count: 0 + ... + <init-container-2>: + Container ID: ... + ... + State: Waiting + Reason: CrashLoopBackOff + Last State: Terminated + Reason: Error + Exit Code: 1 + Started: ... + Finished: ... + Ready: False + Restart Count: 3 + ... +``` + +También puedes acceder al estado del Init Container de forma programática mediante +la lectura del campo `status.initContainerStatuses` dentro del Pod Spec: + + +```shell +kubectl get pod nginx --template '{{.status.initContainerStatuses}}' +``` + + +Este comando devolverá la misma información que arriba en formato JSON. + +## Acceder a los logs de los Init Containers + +Indica el nombre del Init Container así como el nombre del Pod para + acceder a sus logs. + +```shell +kubectl logs <pod-name> -c <init-container-2> +``` + +Los Init Containers que ejecutan secuencias de línea de comandos muestran los comandos +conforme se van ejecutando. Por ejemplo, puedes hacer lo siguiente en Bash +indicando `set -x` al principio de la secuencia. + + + +<!-- discussion --> + +## Comprender el estado de un Pod + +Un estado de un Pod que comienza con `Init:` especifica el estado de la ejecución de +un Init Container. La tabla a continuación muestra algunos valores de estado de ejemplo +que puedes encontrar al depurar Init Containers. + +Estado | Significado +------ | ------- +`Init:N/M` | El Pod tiene `M` Init Containers, y por el momento se han completado `N`. +`Init:Error` | Ha fallado la ejecución de un Init Container. +`Init:CrashLoopBackOff` | Un Init Container ha fallado de forma repetida. +`Pending` | El Pod todavía no ha comenzado a ejecutar sus Init Containers. +`PodInitializing` o `Running` | El Pod ya ha terminado de ejecutar sus Init Containers. + + + + + diff --git a/content/es/docs/tasks/debug-application-cluster/logging-elasticsearch-kibana.md b/content/es/docs/tasks/debug-application-cluster/logging-elasticsearch-kibana.md new file mode 100644 index 0000000000..af95eaff7c --- /dev/null +++ b/content/es/docs/tasks/debug-application-cluster/logging-elasticsearch-kibana.md @@ -0,0 +1,119 @@ +--- +content_type: concept +title: Escribiendo Logs con Elasticsearch y Kibana +--- + +<!-- overview --> + +En la plataforma Google Compute Engine (GCE), por defecto da soporte a la escritura de logs haciendo uso de +[Stackdriver Logging](https://cloud.google.com/logging/), el cual se describe en detalle en [Logging con Stackdriver Logging](/docs/user-guide/logging/stackdriver). + +Este artículo describe cómo configurar un clúster para la ingesta de logs en +[Elasticsearch](https://www.elastic.co/products/elasticsearch) y su posterior visualización +con [Kibana](https://www.elastic.co/products/kibana), a modo de alternativa a +Stackdriver Logging cuando se utiliza la plataforma GCE. + +{{< note >}} +No se puede desplegar de forma automática Elasticsearch o Kibana en un clúster alojado en Google Kubernetes Engine. Hay que desplegarlos de forma manual. +{{< /note >}} + + + +<!-- body --> + +Para utilizar Elasticsearch y Kibana para escritura de logs del clúster, deberías configurar +la siguiente variable de entorno que se muestra a continuación como parte de la creación +del clúster con kube-up.sh: + +```shell +KUBE_LOGGING_DESTINATION=elasticsearch +``` + +También deberías asegurar que `KUBE_ENABLE_NODE_LOGGING=true` (que es el valor por defecto en la plataforma GCE). + +Así, cuando crees un clúster, un mensaje te indicará que la recolección de logs de los daemons de Fluentd +que corren en cada nodo enviará dichos logs a Elasticsearch: + +```shell +cluster/kube-up.sh +``` +``` +... +Project: kubernetes-satnam +Zone: us-central1-b +... calling kube-up +Project: kubernetes-satnam +Zone: us-central1-b ++++ Staging server tars to Google Storage: gs://kubernetes-staging-e6d0e81793/devel ++++ kubernetes-server-linux-amd64.tar.gz uploaded (sha1 = 6987c098277871b6d69623141276924ab687f89d) ++++ kubernetes-salt.tar.gz uploaded (sha1 = bdfc83ed6b60fa9e3bff9004b542cfc643464cd0) +Looking for already existing resources +Starting master and configuring firewalls +Created [https://www.googleapis.com/compute/v1/projects/kubernetes-satnam/zones/us-central1-b/disks/kubernetes-master-pd]. +NAME ZONE SIZE_GB TYPE STATUS +kubernetes-master-pd us-central1-b 20 pd-ssd READY +Created [https://www.googleapis.com/compute/v1/projects/kubernetes-satnam/regions/us-central1/addresses/kubernetes-master-ip]. ++++ Logging using Fluentd to elasticsearch +``` + +Tanto los pods por nodo de Fluentd, como los pods de Elasticsearch, y los pods de Kibana + deberían ejecutarse en el namespace de kube-system inmediatamente después + de que el clúster esté disponible. + +```shell +kubectl get pods --namespace=kube-system +``` +``` +NAME READY STATUS RESTARTS AGE +elasticsearch-logging-v1-78nog 1/1 Running 0 2h +elasticsearch-logging-v1-nj2nb 1/1 Running 0 2h +fluentd-elasticsearch-kubernetes-node-5oq0 1/1 Running 0 2h +fluentd-elasticsearch-kubernetes-node-6896 1/1 Running 0 2h +fluentd-elasticsearch-kubernetes-node-l1ds 1/1 Running 0 2h +fluentd-elasticsearch-kubernetes-node-lz9j 1/1 Running 0 2h +kibana-logging-v1-bhpo8 1/1 Running 0 2h +kube-dns-v3-7r1l9 3/3 Running 0 2h +monitoring-heapster-v4-yl332 1/1 Running 1 2h +monitoring-influx-grafana-v1-o79xf 2/2 Running 0 2h +``` + +Los pods de `fluentd-elasticsearch` recogen los logs de cada nodo y los envían a los +pods de `elasticsearch-logging`, que son parte de un [servicio](/docs/concepts/services-networking/service/) llamado `elasticsearch-logging`. +Estos pods de Elasticsearch almacenan los logs y los exponen via una API REST. +El pod de `kibana-logging` proporciona una UI via web donde leer los logs almacenados en +Elasticsearch, y es parte de un servicio denominado `kibana-logging`. + +Los servicios de Elasticsearch y Kibana ambos están en el namespace `kube-system` + y no se exponen de forma directa mediante una IP accesible públicamente. Para poder acceder a dichos logs, +sigue las instrucciones acerca de cómo [Acceder a servicios corriendo en un clúster](/docs/concepts/cluster-administration/access-clusater/#accessing-services-running-on-the-cluster). + +Si tratas de acceder al servicio de `elasticsearch-logging` desde tu navegador, +verás una página de estado que se parece a la siguiente: + +![Estado de Elasticsearch](/images/docs/es-browser.png) + +A partir de ese momento, puedes introducir consultas de Elasticsearch directamente en el navegador, si lo necesitas. +Echa un vistazo a la [documentación de Elasticsearch](https://www.elastic.co/guide/en/elasticsearch/reference/current/search-uri-request.html) +para más detalles acerca de cómo hacerlo. + +De forma alternativa, puedes ver los logs de tu clúster en Kibana (de nuevo usando las +[instrucciones para acceder a un servicio corriendo en un clúster](/docs/user-guide/accessing-the-cluster/#accessing-services-running-on-the-cluster)). +La primera vez que visitas la URL de Kibana se te presentará una página que te pedirá +que configures una vista de los logs. Selecciona la opción de valores de serie temporal + y luego `@timestamp`. En la página siguiente selecciona la pestaña de `Discover` +y entonces deberías ver todos los logs. Puedes establecer el intervalo de actualización +en 5 segundos para refrescar los logs de forma regular. + +Aquí se muestra una vista típica de logs desde el visor de Kibana: + +![Kibana logs](/images/docs/kibana-logs.png) + + + +## {{% heading "whatsnext" %}} + + +¡Kibana te permite todo tipo de potentes opciones para explorar tus logs! Puedes encontrar +algunas ideas para profundizar en el tema en la [documentación de Kibana](https://www.elastic.co/guide/en/kibana/current/discover.html). + + diff --git a/content/es/docs/tasks/debug-application-cluster/logging-stackdriver.md b/content/es/docs/tasks/debug-application-cluster/logging-stackdriver.md new file mode 100644 index 0000000000..3a247b5e88 --- /dev/null +++ b/content/es/docs/tasks/debug-application-cluster/logging-stackdriver.md @@ -0,0 +1,366 @@ +--- +title: Escribiendo Logs con Stackdriver +content_type: concept +--- + +<!-- overview --> + +Antes de seguir leyendo esta página, deberías familiarizarte con el +[resumen de escritura de logs en Kubernetes](/docs/concepts/cluster-administration/logging). + +{{< note >}} +Por defecto, Stackdriver recolecta toda la salida estándar de tus contenedores, así +como el flujo de la salida de error. Para recolectar cualquier log tu aplicación escribe en un archivo (por ejemplo), +ver la [estrategia de sidecar](/docs/concepts/cluster-administration/logging#sidecar-container-with-a-logging-agent) +en el resumen de escritura de logs en Kubernetes. +{{< /note >}} + + + + +<!-- body --> + +## Despliegue + +Para ingerir logs, debes desplegar el agente de Stackdriver Logging en cada uno de los nodos de tu clúster. +Dicho agente configura una instancia de `fluentd`, donde la configuración se guarda en un `ConfigMap` +y las instancias se gestionan a través de un `DaemonSet` de Kubernetes. El despliegue actual del +`ConfigMap` y el `DaemonSet` dentro de tu clúster depende de tu configuración individual del clúster. + +### Desplegar en un nuevo clúster + +#### Google Kubernetes Engine + +Stackdriver es la solución por defecto de escritura de logs para aquellos clústeres desplegados en Google Kubernetes Engine. +Stackdriver Logging se despliega por defecto en cada clúster a no ser que se le indique de forma explícita no hacerlo. + +#### Otras plataformas + +Para desplegar Stackdriver Logging en un *nuevo* clúster que estés creando con +`kube-up.sh`, haz lo siguiente: + +1. Configura la variable de entorno `KUBE_LOGGING_DESTINATION` con el valor `gcp`. +1. **Si no estás trabajando en GCE**, incluye `beta.kubernetes.io/fluentd-ds-ready=true` +en la variable `KUBE_NODE_LABELS`. + +Una vez que tu clúster ha arrancado, cada nodo debería ejecutar un agente de Stackdriver Logging. +Los `DaemonSet` y `ConfigMap` se configuran como extras. Si no estás usando `kube-up.sh`, +considera la posibilidad de arrancar un clúster sin una solución pre-determinada de escritura de logs +y entonces desplegar los agentes de Stackdriver Logging una vez el clúster esté ejecutándose. + +{{< warning >}} +El proceso de Stackdriver Logging reporta problemas conocidos en plataformas distintas +a Google Kubernetes Engine. Úsalo bajo tu propio riesgo. +{{< /warning >}} + +### Desplegar a un clúster existente + +1. Aplica una etiqueta en cada nodo, si no estaba presente ya. + + El despliegue del agente de Stackdriver Logging utiliza etiquetas de nodo para + determinar en qué nodos debería desplegarse. Estas etiquetas fueron introducidas + para distinguir entre nodos de Kubernetes de la versión 1.6 o superior. + Si el clúster se creó con Stackdriver Logging configurado y el nodo tiene la + versión 1.5.X o inferior, ejecutará fluentd como un pod estático. Puesto que un nodo + no puede tener más de una instancia de fluentd, aplica únicamente las etiquetas + a los nodos que no tienen un pod de fluentd ya desplegado. Puedes confirmar si tu nodo + ha sido etiquetado correctamente ejecutando `kubectl describe` de la siguiente manera: + + ``` + kubectl describe node $NODE_NAME + ``` + + La salida debería ser similar a la siguiente: + + ``` + Name: NODE_NAME + Role: + Labels: beta.kubernetes.io/fluentd-ds-ready=true + ... + ``` + + Asegúrate que la salida contiene la etiqueta `beta.kubernetes.io/fluentd-ds-ready=true`. + Si no está presente, puedes añadirla usando el comando `kubectl label` como se indica: + + ``` + kubectl label node $NODE_NAME beta.kubernetes.io/fluentd-ds-ready=true + ``` + + {{< note >}} + Si un nodo falla y tiene que volver a crearse, deberás volver a definir + la etiqueta al nuevo nodo. Para facilitar esta tarea, puedes utilizar el + parámetro de línea de comandos del Kubelet para aplicar dichas etiquetas + cada vez que se arranque un nodo. + {{< /note >}} + +1. Despliega un `ConfigMap` con la configuración del agente de escritura de logs ejecutando el siguiente comando: + + ``` + kubectl apply -f https://k8s.io/examples/debug/fluentd-gcp-configmap.yaml + ``` + + Este comando crea el `ConfigMap` en el espacio de nombres `default`. Puedes descargar el archivo + manualmente y cambiarlo antes de crear el objeto `ConfigMap`. + +1. Despliega el agente `DaemonSet` de escritura de logs ejecutando el siguiente comando: + + ``` + kubectl apply -f https://k8s.io/examples/debug/fluentd-gcp-ds.yaml + ``` + + Puedes descargar y editar este archivo antes de usarlo igualmente. + +## Verificar el despliegue de tu agente de escritura de logs + +Tras el despliegue del `DaemonSet` de StackDriver, puedes comprobar el estado de +cada uno de los despliegues de los agentes ejecutando el siguiente comando: + +```shell +kubectl get ds --all-namespaces +``` + +Si tienes 3 nodos en el clúster, la salida debería ser similar a esta: + +``` +NAMESPACE NAME DESIRED CURRENT READY NODE-SELECTOR AGE +... +default fluentd-gcp-v2.0 3 3 3 beta.kubernetes.io/fluentd-ds-ready=true 5m +... +``` +Para comprender cómo funciona Stackdriver, considera la siguiente especificación +de un generador de logs sintéticos [counter-pod.yaml](/examples/debug/counter-pod.yaml): + +{{< codenew file="debug/counter-pod.yaml" >}} + +Esta especificación de pod tiene un contenedor que ejecuta una secuencia de comandos bash +que escribe el valor de un contador y la fecha y hora cada segundo, de forma indefinida. +Vamos a crear este pod en el espacio de nombres por defecto. + +```shell +kubectl apply -f https://k8s.io/examples/debug/counter-pod.yaml +``` + +Puedes observar el pod corriendo: + +```shell +kubectl get pods +``` +``` +NAME READY STATUS RESTARTS AGE +counter 1/1 Running 0 5m +``` + +Durante un período de tiempo corto puedes observar que el estado del pod es 'Pending', debido a que el kubelet +tiene primero que descargar la imagen del contenedor. Cuando el estado del pod cambia a `Running` +puedes usar el comando `kubectl logs` para ver la salida de este pod contador. + +```shell +kubectl logs counter +``` +``` +0: Mon Jan 1 00:00:00 UTC 2001 +1: Mon Jan 1 00:00:01 UTC 2001 +2: Mon Jan 1 00:00:02 UTC 2001 +... +``` + +Como se describe en el resumen de escritura de logs, este comando visualiza las entradas de logs +del archivo de logs del contenedor. Si se termina el contenedor y Kubernetes lo reinicia, +todavía puedes acceder a los logs de la ejecución previa del contenedor. Sin embargo, +si el pod se desaloja del nodo, los archivos de log se pierden. Vamos a demostrar este +comportamiento mediante el borrado del contenedor que ejecuta nuestro contador: + +```shell +kubectl delete pod counter +``` +``` +pod "counter" deleted +``` + +y su posterior re-creación: + +```shell +kubectl create -f https://k8s.io/examples/debug/counter-pod.yaml +``` +``` +pod/counter created +``` + +Tras un tiempo, puedes acceder a los logs del pod contador otra vez: + +```shell +kubectl logs counter +``` +``` +0: Mon Jan 1 00:01:00 UTC 2001 +1: Mon Jan 1 00:01:01 UTC 2001 +2: Mon Jan 1 00:01:02 UTC 2001 +... +``` + +Como era de esperar, únicamente se visualizan las líneas de log recientes. Sin embargo, +para una aplicación real seguramente prefieras acceder a los logs de todos los contenedores, +especialmente cuando te haga falta depurar problemas. Aquí es donde haber habilitado +Stackdriver Logging puede ayudarte. + +## Ver logs + +El agente de Stackdriver Logging asocia metadatos a cada entrada de log, para que puedas usarlos posteriormente +en consultas para seleccionar sólo los mensajes que te interesan: por ejemplo, +los mensajes de un pod en particular. + +Los metadatos más importantes son el tipo de recurso y el nombre del log. +El tipo de recurso de un log de contenedor tiene el valor `container`, que se muestra como +`GKE Containers` en la UI (incluso si el clúster de Kubernetes no está en Google Kubernetes Engine). +El nombre de log es el nombre del contenedor, de forma que si tienes un pod con +dos contenedores, denominados `container_1` y `container_2` en la especificación, sus logs +tendrán los nombres `container_1` y `container_2` respectivamente. + +Los componentes del sistema tienen el valor `compute` como tipo de recursos, que se muestra como +`GCE VM Instance` en la UI. Los nombres de log para los componentes del sistema son fijos. +Para un nodo de Google Kubernetes Engine, cada entrada de log de cada componente de sistema tiene uno de los siguientes nombres: + +* docker +* kubelet +* kube-proxy + +Puedes aprender más acerca de cómo visualizar los logs en la [página dedicada a Stackdriver](https://cloud.google.com/logging/docs/view/logs_viewer). + +Uno de los posibles modos de ver los logs es usando el comando de línea de interfaz +[`gcloud logging`](https://cloud.google.com/logging/docs/api/gcloud-logging) +del [SDK de Google Cloud](https://cloud.google.com/sdk/). +Este comando usa la [sintaxis de filtrado](https://cloud.google.com/logging/docs/view/advanced_filters) de StackDriver Logging +para consultar logs específicos. Por ejemplo, puedes ejecutar el siguiente comando: + +```none +gcloud beta logging read 'logName="projects/$YOUR_PROJECT_ID/logs/count"' --format json | jq '.[].textPayload' +``` +``` +... +"2: Mon Jan 1 00:01:02 UTC 2001\n" +"1: Mon Jan 1 00:01:01 UTC 2001\n" +"0: Mon Jan 1 00:01:00 UTC 2001\n" +... +"2: Mon Jan 1 00:00:02 UTC 2001\n" +"1: Mon Jan 1 00:00:01 UTC 2001\n" +"0: Mon Jan 1 00:00:00 UTC 2001\n" +``` + +Como puedes observar, muestra los mensajes del contenedor contador tanto de la +primera como de la segunda ejecución, a pesar de que el kubelet ya había eliminado los logs del primer contenedor. + +### Exportar logs + +Puedes exportar los logs al [Google Cloud Storage](https://cloud.google.com/storage/) +o a [BigQuery](https://cloud.google.com/bigquery/) para llevar a cabo un análisis más profundo. +Stackdriver Logging ofrece el concepto de destinos, donde puedes especificar el destino de +las entradas de logs. Más información disponible en la [página de exportación de logs](https://cloud.google.com/logging/docs/export/configure_export_v2) de StackDriver. + +## Configurar los agentes de Stackdriver Logging + +En ocasiones la instalación por defecto de Stackdriver Logging puede que no se ajuste a tus necesidades, por ejemplo: + +* Puede que quieras añadir más recursos porque el rendimiento por defecto no encaja con tus necesidades. +* Puede que quieras añadir un parseo adicional para extraer más metadatos de tus mensajes de log, +como la severidad o referencias al código fuente. +* Puede que quieras enviar los logs no sólo a Stackdriver o sólo enviarlos a Stackdriver parcialmente. + +En cualquiera de estos casos, necesitas poder cambiar los parámetros del `DaemonSet` y el `ConfigMap`. + +### Prerequisitos + +Si estás usando GKE y Stackdriver Logging está habilitado en tu clúster, no puedes +cambiar su configuración, porque ya está gestionada por GKE. +Sin embargo, puedes deshabilitar la integración por defecto y desplegar la tuya propia. + +{{< note >}} +Tendrás que mantener y dar soporte tú mismo a la nueva configuración desplegada: +actualizar la imagen y la configuración, ajustar los recuros y todo eso. +{{< /note >}} + +Para deshabilitar la integración por defecto, usa el siguiente comando: + +``` +gcloud beta container clusters update --logging-service=none CLUSTER +``` + +Puedes encontrar notas acerca de cómo instalar los agentes de Stackdriver Logging + en un clúster ya ejecutándose en la [sección de despliegue](#deploying). + +### Cambiar los parámetros del `DaemonSet` + +Cuando tienes un `DaemonSet` de Stackdriver Logging en tu clúster, puedes simplemente +modificar el campo `template` en su especificación, y el controlador del daemonset actualizará los pods por ti. Por ejemplo, +asumamos que acabas de instalar el Stackdriver Logging como se describe arriba. Ahora quieres cambiar +el límite de memoria que se le asigna a fluentd para poder procesar más logs de forma segura. + +Obtén la especificación del `DaemonSet` que corre en tu clúster: + +```shell +kubectl get ds fluentd-gcp-v2.0 --namespace kube-system -o yaml > fluentd-gcp-ds.yaml +``` + +A continuación, edita los requisitos del recurso en el `spec` y actualiza el objeto `DaemonSet` +en el apiserver usando el siguiente comando: + +```shell +kubectl replace -f fluentd-gcp-ds.yaml +``` + +Tras un tiempo, los pods de agente de Stackdriver Logging se reiniciarán con la nueva configuración. + +### Cambiar los parámetros de fluentd + +La configuración de Fluentd se almacena en un objeto `ConfigMap`. Realmente se trata de un conjunto +de archivos de configuración que se combinan conjuntamente. Puedes aprender acerca de +la configuración de fluentd en el [sitio oficial](http://docs.fluentd.org). + +Imagina que quieres añadir una nueva lógica de parseo a la configuración actual, de forma que fluentd pueda entender +el formato de logs por defecto de Python. Un filtro apropiado de fluentd para conseguirlo sería: + +``` +<filter reform.**> + type parser + format /^(?<severity>\w):(?<logger_name>\w):(?<log>.*)/ + reserve_data true + suppress_parse_error_log true + key_name log +</filter> +``` + +Ahora tienes que añadirlo a la configuración actual y que los agentes de Stackdriver Logging la usen. +Para ello, obtén la versión actual del `ConfigMap` de Stackdriver Logging de tu clúster +ejecutando el siguiente comando: + +```shell +kubectl get cm fluentd-gcp-config --namespace kube-system -o yaml > fluentd-gcp-configmap.yaml +``` + +Luego, como valor de la clave `containers.input.conf`, inserta un nuevo filtro justo después +de la sección `source`. + +{{< note >}} +El orden es importante. +{{< /note >}} + +Actualizar el `ConfigMap` en el apiserver es más complicado que actualizar el `DaemonSet`. +Es mejor considerar que un `ConfigMap` es inmutable. Así, para poder actualizar la configuración, deberías +crear un nuevo `ConfigMap` con otro nombre y cambiar el `DaemonSet` para que apunte al nuevo +siguiendo la [guía de arriba](#changing-daemonset-parameters). + +### Añadir plugins de fluentd + +Fluentd está desarrollado en Ruby y permite extender sus capacidades mediante el uso de +[plugins](http://www.fluentd.org/plugins). Si quieres usar un plugin que no está incluido en +la imagen por defecto del contenedor de Stackdriver Logging, debes construir tu propia imagen. +Imagina que quieres añadir un destino Kafka para aquellos mensajes de un contenedor en particular +para poder procesarlos posteriormente. Puedes reusar los [fuentes de imagen de contenedor](https://git.k8s.io/contrib/fluentd/fluentd-gcp-image) +con algunos pequeños cambios: + +* Cambia el archivo Makefile para que apunte a tu repositorio de contenedores, ej. `PREFIX=gcr.io/<your-project-id>`. +* Añade tu dependencia al archivo Gemfile, por ejemplo `gem 'fluent-plugin-kafka'`. + +Luego, ejecuta `make build push` desde ese directorio. Cuando el `DaemonSet` haya tomado los cambios de la nueva imagen, +podrás usar el plugin que has indicado en la configuración de fluentd. + + diff --git a/content/es/docs/tasks/manage-daemon/_index.md b/content/es/docs/tasks/manage-daemon/_index.md index 000b87a214..dfd787f9c5 100755 --- a/content/es/docs/tasks/manage-daemon/_index.md +++ b/content/es/docs/tasks/manage-daemon/_index.md @@ -1,4 +1,4 @@ --- -title: Gestionar y ejecutar demonios +title: Gestionar y ejecutar daemons weight: 45 --- \ No newline at end of file diff --git a/content/es/examples/audit/audit-policy.yaml b/content/es/examples/audit/audit-policy.yaml new file mode 100644 index 0000000000..cdc46be754 --- /dev/null +++ b/content/es/examples/audit/audit-policy.yaml @@ -0,0 +1,68 @@ +apiVersion: audit.k8s.io/v1 # Esto es obligatorio. +kind: Policy +# No generar eventos de auditoría para las peticiones en la etapa RequestReceived. +omitStages: + - "RequestReceived" +rules: + # Registrar los cambios del pod al nivel RequestResponse + - level: RequestResponse + resources: + - group: "" + # Los recursos "pods" no hacen coincidir las peticiones a cualquier sub-recurso de pods, + # lo que es consistente con la regla RBAC. + resources: ["pods"] + # Registrar "pods/log", "pods/status" al nivel Metadata + - level: Metadata + resources: + - group: "" + resources: ["pods/log", "pods/status"] + + # No registrar peticiones al configmap denominado "controller-leader" + - level: None + resources: + - group: "" + resources: ["configmaps"] + resourceNames: ["controller-leader"] + + # No registrar peticiones de observación hechas por "system:kube-proxy" sobre puntos de acceso o servicios + - level: None + users: ["system:kube-proxy"] + verbs: ["watch"] + resources: + - group: "" # Grupo API base + resources: ["endpoints", "services"] + + # No registrar peticiones autenticadas a ciertas rutas URL que no son recursos. + - level: None + userGroups: ["system:authenticated"] + nonResourceURLs: + - "/api*" # Coincidencia por comodín. + - "/version" + + # Registrar el cuerpo de la petición de los cambios de configmap en kube-system. + - level: Request + resources: + - group: "" # Grupo API base + resources: ["configmaps"] + # Esta regla sólo aplica a los recursos en el Namespace "kube-system". + # La cadena vacía "" se puede usar para seleccionar los recursos sin Namespace. + namespaces: ["kube-system"] + + # Registrar los cambios de configmap y secret en todos los otros Namespaces al nivel Metadata. + - level: Metadata + resources: + - group: "" # Grupo API base + resources: ["secrets", "configmaps"] + + # Registrar todos los recursos en core y extensions al nivel Request. + - level: Request + resources: + - group: "" # Grupo API base + - group: "extensions" # La versión del grupo NO debería incluirse. + + # Regla para "cazar" todos las demás peticiones al nivel Metadata. + - level: Metadata + # Las peticiones de larga duración, como los watches, que caen bajo esta regla no + # generan un evento de auditoría en RequestReceived. + omitStages: + - "RequestReceived" diff --git a/content/es/examples/controllers/frontend.yaml b/content/es/examples/controllers/frontend.yaml new file mode 100644 index 0000000000..4a10c52a7d --- /dev/null +++ b/content/es/examples/controllers/frontend.yaml @@ -0,0 +1,21 @@ +apiVersion: apps/v1 +kind: ReplicaSet +metadata: + name: frontend + labels: + app: guestbook + tier: frontend +spec: + # modifica las réplicas según tu caso de uso + replicas: 3 + selector: + matchLabels: + tier: frontend + template: + metadata: + labels: + tier: frontend + spec: + containers: + - name: php-redis + image: gcr.io/google_samples/gb-frontend:v3 diff --git a/content/es/examples/controllers/hpa-rs.yaml b/content/es/examples/controllers/hpa-rs.yaml new file mode 100644 index 0000000000..a8388530dc --- /dev/null +++ b/content/es/examples/controllers/hpa-rs.yaml @@ -0,0 +1,11 @@ +apiVersion: autoscaling/v1 +kind: HorizontalPodAutoscaler +metadata: + name: frontend-scaler +spec: + scaleTargetRef: + kind: ReplicaSet + name: frontend + minReplicas: 3 + maxReplicas: 10 + targetCPUUtilizationPercentage: 50 diff --git a/content/es/examples/controllers/job.yaml b/content/es/examples/controllers/job.yaml new file mode 100644 index 0000000000..b448f2eb81 --- /dev/null +++ b/content/es/examples/controllers/job.yaml @@ -0,0 +1,14 @@ +apiVersion: batch/v1 +kind: Job +metadata: + name: pi +spec: + template: + spec: + containers: + - name: pi + image: perl + command: ["perl", "-Mbignum=bpi", "-wle", "print bpi(2000)"] + restartPolicy: Never + backoffLimit: 4 + diff --git a/content/es/examples/controllers/nginx-deployment.yaml b/content/es/examples/controllers/nginx-deployment.yaml new file mode 100644 index 0000000000..f7f95deebb --- /dev/null +++ b/content/es/examples/controllers/nginx-deployment.yaml @@ -0,0 +1,21 @@ +apiVersion: apps/v1 +kind: Deployment +metadata: + name: nginx-deployment + labels: + app: nginx +spec: + replicas: 3 + selector: + matchLabels: + app: nginx + template: + metadata: + labels: + app: nginx + spec: + containers: + - name: nginx + image: nginx:1.7.9 + ports: + - containerPort: 80 diff --git a/content/es/examples/controllers/replicaset.yaml b/content/es/examples/controllers/replicaset.yaml new file mode 100644 index 0000000000..e5dfdf6c43 --- /dev/null +++ b/content/es/examples/controllers/replicaset.yaml @@ -0,0 +1,17 @@ +apiVersion: apps/v1 +kind: ReplicaSet +metadata: + name: my-repset +spec: + replicas: 3 + selector: + matchLabels: + pod-is-for: garbage-collection-example + template: + metadata: + labels: + pod-is-for: garbage-collection-example + spec: + containers: + - name: nginx + image: nginx diff --git a/content/es/examples/debug/counter-pod.yaml b/content/es/examples/debug/counter-pod.yaml new file mode 100644 index 0000000000..f997886386 --- /dev/null +++ b/content/es/examples/debug/counter-pod.yaml @@ -0,0 +1,10 @@ +apiVersion: v1 +kind: Pod +metadata: + name: counter +spec: + containers: + - name: count + image: busybox + args: [/bin/sh, -c, + 'i=0; while true; do echo "$i: $(date)"; i=$((i+1)); sleep 1; done'] diff --git a/content/es/examples/pods/pod-rs.yaml b/content/es/examples/pods/pod-rs.yaml new file mode 100644 index 0000000000..df7b390597 --- /dev/null +++ b/content/es/examples/pods/pod-rs.yaml @@ -0,0 +1,23 @@ +apiVersion: v1 +kind: Pod +metadata: + name: pod1 + labels: + tier: frontend +spec: + containers: + - name: hello1 + image: gcr.io/google-samples/hello-app:2.0 + +--- + +apiVersion: v1 +kind: Pod +metadata: + name: pod2 + labels: + tier: frontend +spec: + containers: + - name: hello2 + image: gcr.io/google-samples/hello-app:1.0 diff --git a/content/fr/_index.html b/content/fr/_index.html index 89a66f48b6..3b659534e8 100644 --- a/content/fr/_index.html +++ b/content/fr/_index.html @@ -3,9 +3,6 @@ title: "Solution professionnelle d’orchestration de conteneurs" abstract: "Déploiement, mise à l'échelle et gestion automatisée des conteneurs" cid: home --- -{{< announcement >}} - -{{< deprecationwarning >}} {{< blocks/section id="oceanNodes" >}} {{% blocks/feature image="flower" %}} diff --git a/content/fr/docs/concepts/cluster-administration/cluster-administration-overview.md b/content/fr/docs/concepts/cluster-administration/cluster-administration-overview.md index 134a6fb3a0..8d1df672a4 100644 --- a/content/fr/docs/concepts/cluster-administration/cluster-administration-overview.md +++ b/content/fr/docs/concepts/cluster-administration/cluster-administration-overview.md @@ -40,7 +40,7 @@ A noter: Toutes les distributions ne sont pas activement maintenues. Choisissez * La rubrique [Certificats](/docs/concepts/cluster-administration/certificates/) décrit les étapes à suivre pour générer des certificats à l’aide de différentes suites d'outils. -* L' [Environnement de conteneur dans Kubernetes](/docs/concepts/containers/container-environment-variables/) décrit l'environnement des conteneurs gérés par la Kubelet sur un nœud Kubernetes. +* L' [Environnement de conteneur dans Kubernetes](/docs/concepts/containers/container-environment/) décrit l'environnement des conteneurs gérés par Kubelet sur un nœud Kubernetes. * Le [Contrôle de l'accès à l'API Kubernetes](/docs/reference/access-authn-authz/controlling-access/) explique comment configurer les autorisations pour les utilisateurs et les comptes de service. @@ -64,4 +64,3 @@ A noter: Toutes les distributions ne sont pas activement maintenues. Choisissez * [Integration DNS](/docs/concepts/services-networking/dns-pod-service/) décrit comment résoudre un nom DNS directement vers un service Kubernetes. * [Journalisation des évènements et surveillance de l'activité du cluster](/docs/concepts/cluster-administration/logging/) explique le fonctionnement de la journalisation des évènements dans Kubernetes et son implémentation. - diff --git a/content/fr/docs/concepts/containers/container-environment-variables.md b/content/fr/docs/concepts/containers/container-environment.md similarity index 95% rename from content/fr/docs/concepts/containers/container-environment-variables.md rename to content/fr/docs/concepts/containers/container-environment.md index 547809ffbf..adad1ab64a 100644 --- a/content/fr/docs/concepts/containers/container-environment-variables.md +++ b/content/fr/docs/concepts/containers/container-environment.md @@ -1,6 +1,6 @@ --- -title: Les variables d’environnement du conteneur -description: Variables d'environnement pour conteneur Kubernetes +title: L'environnement du conteneur +description: L'environnement du conteneur Kubernetes content_type: concept weight: 20 --- diff --git a/content/fr/docs/concepts/overview/working-with-objects/namespaces.md b/content/fr/docs/concepts/overview/working-with-objects/namespaces.md new file mode 100644 index 0000000000..90229676b0 --- /dev/null +++ b/content/fr/docs/concepts/overview/working-with-objects/namespaces.md @@ -0,0 +1,111 @@ +--- +title: Namespaces +content_type: concept +weight: 30 +--- + +<!-- overview --> + +Kubernetes prend en charge plusieurs clusters virtuels presents sur le même cluster physique. +Ces clusters virtuels sont appelés namespaces (espaces de noms en français). + +<!-- body --> + +## Quand utiliser plusieurs namespaces + +Les namespaces sont destinés à être utilisés dans les environnements ayant de nombreux utilisateurs répartis en plusieurs équipes ou projets. Pour les clusters de quelques dizaines d'utilisateurs, vous n'avez pas +besoin d'utiliser de namespaces. Commencez à utiliser des namespaces lorsque vous avez +besoin des fonctionnalités qu'ils fournissent. + +Les namespaces sont des groupes de noms. Ils fournissent un modèle d'isolation de nommage des ressources. Les noms des ressources doivent être uniques dans un namespace, +mais pas dans l'ensemble des namespaces. Les namespaces ne peuvent pas être imbriqués les uns dans les autres et chaque ressource Kubernetes ne peut se trouver que dans un seul namespace. + +Les namespaces sont un moyen de répartir les ressources d'un cluster entre plusieurs utilisateurs (via [quota de ressources](/docs/concepts/policy/resource-quotas/)). + +Dans les futures versions de Kubernetes, les objets du même namespace auront les mêmes +stratégies de contrôle d'accès par défaut. + +Il n'est pas nécessaire d'utiliser plusieurs namespaces juste pour séparer des ressources légèrement différentes, telles que les versions du même logiciel: utiliser les [labels](/docs/user-guide/labels) pour distinguer les +ressources dans le même namespace. + +## Utilisation des namespaces + +La création et la suppression des namespaces sont décrites dans la [Documentation du guide d'administration pour les namespaces](/docs/admin/namespaces). + +{{< note >}} +Évitez de créer des namespaces avec le préfixe `kube-`, car il est réservé aux namespaces système de Kubernetes. +{{< /note >}} + +### Affichage des namespaces + +Dans un cluster vous pouvez lister les namespaces actuels à l'aide de: + +```shell +kubectl get namespace +``` + +``` +NAME STATUS AGE +default Active 1d +kube-node-lease Active 1d +kube-public Active 1d +kube-system Active 1d +``` + +Kubernetes démarre avec quatre namespaces initiaux: + +- `default` Le namespace par défaut pour les objets sans autre namespace +- `kube-system` Le namespace pour les objets créés par Kubernetes lui-même +- `kube-public` Ce namespace est créé automatiquement et est visible par tous les utilisateurs (y compris ceux qui ne sont pas authentifiés). Ce namespace est principalement réservé à l'utilisation du cluster, au cas où certaines ressources devraient être disponibles publiquement dans l'ensemble du cluster. L'aspect public de ce namespace n'est qu'une convention, pas une exigence. +- `kube-node-lease` Ce namespace contient les objets de bail associés à chaque nœud, ce qui améliore les performances des pulsations du nœud à mesure que le cluster évolue. + +### Définition du namespaces pour une requête + +Pour définir le namespace pour une requête en cours, utilisez l'indicateur `--namespace`. + +Par exemple: + +```shell +kubectl run nginx --image=nginx --namespace=<insert-namespace-name-here> +kubectl get pods --namespace=<insert-namespace-name-here> +``` + +### Spécifier un namespace + +Vous pouvez enregistrer de manière permanente le namespace à utiliser pour toutes les commandes kubectl à suivre. + +```shell +kubectl config set-context --current --namespace=<insert-namespace-name-here> +# Validez-le +kubectl config view --minify | grep namespace: +``` + +## Namespaces et DNS + +Lorsque vous créez un [Service](/fr/docs/concepts/services-networking/service/), il crée une [entrée DNS](/fr/docs/concepts/services-networking/dns-pod-service/) correspondante. +Cette entrée est de la forme `<nom-service>.<nom-namespace>.svc.cluster.local`, ce qui signifie +que si un conteneur utilise simplement `<nom-service>`, il résoudra le service qui +est local à un namespace. Ceci est utile pour utiliser la même configuration pour +plusieurs namespaces tels que le Développement, la Qualification et la Production. Si vous voulez naviguer +entre plusieurs namespaces, vous devez utiliser le nom de domaine complet (FQDN ou nom de domaine complet en français). + +## Tous les objets ne se trouvent pas dans un namespace + +La plupart des ressources Kubernetes (par exemple, pods, services, contrôleurs de réplication et autres) sont +dans des namespaces. Cependant, les ressources de type namespace ne sont pas elles-mêmes dans un namespace. +Et les ressources de bas niveau, telles que les [noeuds](/docs/admin/node) et les volumes persistants, ne se trouvent dans aucun namespace. + +Pour voir quelles ressources Kubernetes sont et ne sont pas dans un namespace: + +```shell +# Dans un namespace +kubectl api-resources --namespaced=true + +# Pas dans un namespace +kubectl api-resources --namespaced=false +``` + +## {{% heading "whatsnext" %}} + +- En savoir plus sur [créer un nouveau namespace](/docs/tasks/administer-cluster/namespaces/#creating-a-new-namespace). +- En savoir plus sur [suppression d'un namespace](/docs/tasks/administer-cluster/namespaces/#deleting-a-namespace). diff --git a/content/fr/docs/concepts/workloads/pods/pod-lifecycle.md b/content/fr/docs/concepts/workloads/pods/pod-lifecycle.md index 9a6f96d36a..aece7de62c 100644 --- a/content/fr/docs/concepts/workloads/pods/pod-lifecycle.md +++ b/content/fr/docs/concepts/workloads/pods/pod-lifecycle.md @@ -63,10 +63,8 @@ du tableau de PodCondition a six champs possibles : * `PodScheduled` : le Pod a été affecté à un nœud ; * `Ready` : le Pod est prêt à servir des requêtes et doit être rajouté aux équilibreurs de charge de tous les Services correspondants ; - * `Initialized` : tous les [init containers](/docs/concepts/workloads/pods/init-containers) + * `Initialized` : tous les [init containers](/fr/docs/concepts/workloads/pods/init-containers) ont démarré correctement ; - * `Unschedulable` : le scheduler ne peut pas affecter le Pod pour l'instant, par exemple - par manque de ressources ou en raison d'autres contraintes ; * `ContainersReady` : tous les conteneurs du Pod sont prêts. @@ -98,12 +96,12 @@ Chaque sonde a un résultat parmi ces trois : * Failure: Le Conteneur a échoué au diagnostic. * Unknown: L'exécution du diagnostic a échoué, et donc aucune action ne peut être prise. -kubelet peut optionnellement exécuter et réagir à deux types de sondes sur des conteneurs +kubelet peut optionnellement exécuter et réagir à trois types de sondes sur des conteneurs en cours d'exécution : * `livenessProbe` : Indique si le Conteneur est en cours d'exécution. Si la liveness probe échoue, kubelet tue le Conteneur et le Conteneur - est soumis à sa [politique de redémarrage](#restart-policy) (restart policy). + est soumis à sa [politique de redémarrage](#politique-de-redemarrage) (restart policy). Si un Conteneur ne fournit pas de liveness probe, l'état par défaut est `Success`. * `readinessProbe` : Indique si le Conteneur est prêt à servir des requêtes. @@ -113,7 +111,13 @@ en cours d'exécution : `Failure`. Si le Conteneur ne fournit pas de readiness probe, l'état par défaut est `Success`. -### Quand devez-vous utiliser une liveness ou une readiness probe ? +* `startupProbe`: Indique si l'application à l'intérieur du conteneur a démarré. + Toutes les autres probes sont désactivées si une starup probe est fournie, + jusqu'à ce qu'elle réponde avec succès. Si la startup probe échoue, le kubelet + tue le conteneur, et le conteneur est assujetti à sa [politique de redémarrage](#politique-de-redemarrage). + Si un conteneur ne fournit pas de startup probe, l'état par défaut est `Success`. + +### Quand devez-vous utiliser une liveness probe ? Si le process de votre Conteneur est capable de crasher de lui-même lorsqu'il rencontre un problème ou devient inopérant, vous n'avez pas forcément besoin @@ -124,6 +128,10 @@ Si vous désirez que votre Conteneur soit tué et redémarré si une sonde écho spécifiez une liveness probe et indiquez une valeur pour `restartPolicy` à Always ou OnFailure. +### Quand devez-vous utiliser une readiness probe ? + +{{< feature-state for_k8s_version="v1.0" state="stable" >}} + Si vous voulez commencer à envoyer du trafic à un Pod seulement lorsqu'une sonde réussit, spécifiez une readiness probe. Dans ce cas, la readiness probe peut être la même que la liveness probe, mais l'existence de la readiness probe dans la spec @@ -142,8 +150,16 @@ de sa suppression, le Pod se met automatiquement dans un état non prêt, que la readiness probe existe ou non. Le Pod reste dans le statut non prêt le temps que les Conteneurs du Pod s'arrêtent. -Pour plus d'informations sur la manière de mettre en place une liveness ou readiness probe, -voir [Configurer des Liveness et Readiness Probes](/docs/tasks/configure-pod-container/configure-liveness-readiness-probes/). +### Quand devez-vous utiliser une startup probe ? + +{{< feature-state for_k8s_version="v1.16" state="alpha" >}} + +Si votre conteneur démarre habituellement en plus de `initialDelaySeconds + failureThreshold × periodSeconds`, +vous devriez spécifier une startup probe qui vérifie le même point de terminaison que la liveness probe. La valeur par défaut pour `periodSeconds` est 30s. +Vous devriez alors mettre sa valeur `failureThreshold` suffisamment haute pour permettre au conteneur de démarrer, sans changer les valeurs par défaut de la liveness probe. Ceci aide à se protéger de deadlocks. + +Pour plus d'informations sur la manière de mettre en place une liveness, readiness ou startup probe, +voir [Configurer des Liveness, Readiness et Startup Probes](/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/). ## Statut d'un Pod et d'un Conteneur @@ -172,9 +188,7 @@ d'informations. ... ``` -* `Running` : Indique que le conteneur s'exécute sans problème. Une fois qu'un centeneur est -dans l'état Running, le hook `postStart` est exécuté (s'il existe). Cet état affiche aussi -le moment auquel le conteneur est entré dans l'état Running. +* `Running` : Indique que le conteneur s'exécute sans problème. Le hook `postStart` (s'il existe) est exécuté avant que le conteneur entre dans l'état Running. Cet état affiche aussi le moment auquel le conteneur est entré dans l'état Running. ```yaml ... @@ -199,27 +213,30 @@ dans l'état Terminated, le hook `preStop` est exécuté (s'il existe). ... ``` -## Pod readiness gate +## Pod readiness {#pod-readiness-gate} {{< feature-state for_k8s_version="v1.14" state="stable" >}} -Afin d'étendre la readiness d'un Pod en autorisant l'injection de données -supplémentaires ou des signaux dans `PodStatus`, Kubernetes 1.11 a introduit -une fonctionnalité appelée [Pod ready++](https://github.com/kubernetes/enhancements/blob/master/keps/sig-network/0007-pod-ready%2B%2B.md). -Vous pouvez utiliser le nouveau champ `ReadinessGate` dans `PodSpec` -pour spécifier des conditions additionnelles à évaluer pour la readiness d'un Pod. -Si Kubernetes ne peut pas trouver une telle condition dans le champ `status.conditions` -d'un Pod, le statut de la condition est "`False`" par défaut. Voici un exemple : +Votre application peut injecter des données dans `PodStatus`. + +_Pod readiness_. Pour utiliser cette fonctionnalité, remplissez `readinessGates` dans le PodSpec avec +une liste de conditions supplémentaires que le kubelet évalue pour la disponibilité du Pod. + +Les Readiness gates sont déterminées par l'état courant des champs `status.condition` du Pod. +Si Kubernetes ne peut pas trouver une telle condition dans le champs `status.conditions` d'un Pod, the statut de la condition +est mise par défaut à "`False`". + +Voici un exemple : ```yaml -Kind: Pod +kind: Pod ... spec: readinessGates: - conditionType: "www.example.com/feature-1" status: conditions: - - type: Ready # ceci est une builtin PodCondition + - type: Ready # une PodCondition intégrée status: "False" lastProbeTime: null lastTransitionTime: 2018-01-01T00:00:00Z @@ -233,27 +250,26 @@ status: ... ``` -Les nouvelles conditions du Pod doivent être conformes au [format des étiquettes](/docs/concepts/overview/working-with-objects/labels/#syntax-and-character-set) de Kubernetes. -La commande `kubectl patch` ne prenant pas encore en charge la modifictaion du statut -des objets, les nouvelles conditions du Pod doivent être injectées avec -l'action `PATCH` en utilisant une des [bibliothèques KubeClient](/docs/reference/using-api/client-libraries/). +Les conditions du Pod que vous ajoutez doivent avoir des noms qui sont conformes au [format des étiquettes](/docs/concepts/overview/working-with-objects/labels/#syntax-and-character-set) de Kubernetes. -Avec l'introduction de nouvelles conditions d'un Pod, un Pod est considéré comme prêt -**seulement** lorsque les deux déclarations suivantes sont vraies : +### Statut de la disponibilité d'un Pod {#statut-pod-disponibilité} + +La commande `kubectl patch` ne peut pas patcher le statut d'un objet. +Pour renseigner ces `status.conditions` pour le pod, les applications et +{{< glossary_tooltip term_id="operator-pattern" text="operators">}} doivent utiliser l'action `PATCH`. +Vous pouvez utiliser une [bibliothèque client Kubernetes](/docs/reference/using-api/client-libraries/) pour +écrire du code qui renseigne les conditions particulières pour la disponibilité dun Pod. + +Pour un Pod utilisant des conditions particulières, ce Pod est considéré prêt **seulement** +lorsque les deux déclarations ci-dessous sont vraies : * Tous les conteneurs du Pod sont prêts. -* Toutes les conditions spécifiées dans `ReadinessGates` sont à "`True`". +* Toutes les conditions spécifiées dans `ReadinessGates` sont `True`. -Pour faciliter le changement de l'évaluation de la readiness d'un Pod, -une nouvelle condition de Pod `ContainersReady` est introduite pour capturer -l'ancienne condition `Ready` d'un Pod. +Lorsque les conteneurs d'un Pod sont prêts mais qu'au moins une condition particulière +est manquante ou `False`, le kubelet renseigne la condition du Pod à `ContainersReady`. -Avec K8s 1.11, en tant que fonctionnalité alpha, "Pod Ready++" doit être explicitement activé en mettant la [feature gate](/docs/reference/command-line-tools-reference/feature-gates/) `PodReadinessGates` -à true. - -Avec K8s 1.12, la fonctionnalité est activée par défaut. - -## Restart policy +## Politique de redémarrage La structure PodSpec a un champ `restartPolicy` avec comme valeur possible Always, OnFailure et Never. La valeur par défaut est Always. @@ -267,33 +283,30 @@ une fois attaché à un nœud, un Pod ne sera jamais rattaché à un autre nœud ## Durée de vie d'un Pod -En général, un Pod ne disparaît pas avant que quelqu'un le détruise. Ceci peut être -un humain ou un contrôleur. La seule exception à cette règle est pour les Pods ayant -une `phase` Succeeded ou Failed depuis une durée donnée (déterminée -par `terminated-pod-gc-threshold` sur le master), qui expireront et seront -automatiquement détruits. +En général, les Pods restent jusqu'à ce qu'un humain ou un process de +{{< glossary_tooltip term_id="controller" text="contrôleur" >}} les supprime explicitement. -Trois types de contrôleurs sont disponibles : +Le plan de contrôle nettoie les Pods terminés (avec une phase à `Succeeded` ou +`Failed`), lorsque le nombre de Pods excède le seuil configuré +(determiné par `terminated-pod-gc-threshold` dans le kube-controller-manager). +Ceci empêche une fuite de ressources lorsque les Pods sont créés et supprimés au fil du temps. -- Utilisez un [Job](/docs/concepts/jobs/run-to-completion-finite-workloads/) pour des -Pods qui doivent se terminer, par exemple des calculs par batch. Les Jobs sont appropriés +Il y a différents types de ressources pour créer des Pods : + +- Utilisez un {{< glossary_tooltip term_id="deployment" >}}, + {{< glossary_tooltip term_id="replica-set" >}} ou {{< glossary_tooltip term_id="statefulset" >}} + pour les Pods qui ne sont pas censés terminer, par exemple des serveurs web. + +- Utilisez un {{< glossary_tooltip term_id="job" >}} + pour les Pods qui sont censés se terminer une fois leur tâche accomplie. Les Jobs sont appropriés seulement pour des Pods ayant `restartPolicy` égal à OnFailure ou Never. -- Utilisez un [ReplicationController](/docs/concepts/workloads/controllers/replicationcontroller/), - [ReplicaSet](/docs/concepts/workloads/controllers/replicaset/) ou - [Deployment](/docs/concepts/workloads/controllers/deployment/) - pour des Pods qui ne doivent pas s'arrêter, par exemple des serveurs web. - ReplicationControllers sont appropriés pour des Pods ayant `restartPolicy` égal à - Always. +- Utilisez un {{< glossary_tooltip term_id="daemonset" >}} + pour les Pods qui doivent s'exécuter sur chaque noeud éligible. -- Utilisez un [DaemonSet](/docs/concepts/workloads/controllers/daemonset/) pour des Pods - qui doivent s'exécuter une fois par machine, car ils fournissent un service système - au niveau de la machine. - -Les trois types de contrôleurs contiennent un PodTemplate. Il est recommandé -de créer le contrôleur approprié et de le laisser créer les Pods, plutôt que de -créer directement les Pods vous-même. Ceci car les Pods seuls ne sont pas résilients -aux pannes machines, alors que les contrôleurs le sont. +Toutes les ressources de charges de travail contiennent une PodSpec. Il est recommandé de créer +la ressource de charges de travail appropriée et laisser le contrôleur de la ressource créer les Pods +pour vous, plutôt que de créer directement les Pods vous-même. Si un nœud meurt ou est déconnecté du reste du cluster, Kubernetes applique une politique pour mettre la `phase` de tous les Pods du nœud perdu à Failed. @@ -391,7 +404,7 @@ spec: [attacher des handlers à des événements de cycle de vie d'un conteneur](/docs/tasks/configure-pod-container/attach-handler-lifecycle-event/). * Apprenez par la pratique - [configurer des liveness et readiness probes](/docs/tasks/configure-pod-container/configure-liveness-readiness-probes/). + [configurer des liveness, readiness et startup probes](/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/). * En apprendre plus sur les [hooks de cycle de vie d'un Conteneur](/docs/concepts/containers/container-lifecycle-hooks/). diff --git a/content/fr/docs/concepts/workloads/pods/pod-overview.md b/content/fr/docs/concepts/workloads/pods/pod-overview.md index b1803ba5e0..bfa5e02c62 100644 --- a/content/fr/docs/concepts/workloads/pods/pod-overview.md +++ b/content/fr/docs/concepts/workloads/pods/pod-overview.md @@ -16,23 +16,18 @@ Cette page fournit un aperçu du `Pod`, l'objet déployable le plus petit dans l ## Comprendre les Pods -Un *Pod* est l'unité d'exécution de base d'une application Kubernetes--l'unité la plus petite et la plus simple dans le modèle d'objets de Kubernetes--que vous créez ou déployez. Un Pod représente des process en cours d'exécution dans votre {{< glossary_tooltip term_id="cluster" >}}. +Un *Pod* est l'unité d'exécution de base d'une application Kubernetes--l'unité la plus petite et la plus simple dans le modèle d'objets de Kubernetes--que vous créez ou déployez. Un Pod représente des process en cours d'exécution dans votre {{< glossary_tooltip term_id="cluster" text="cluster" >}}. -Un Pod encapsule un conteneur applicatif (ou, dans certains cas, plusieurs conteneurs), des ressources de stockage, une IP réseau unique, et des options qui contrôlent comment le ou les conteneurs doivent s'exécuter. Un Pod représente une unité de déploiement : *une instance unique d'une application dans Kubernetes*, qui peut consister soit en un unique {{< glossary_tooltip text="container" term_id="container" >}} soit en un petit nombre de conteneurs qui sont étroitement liés et qui partagent des ressources. +Un Pod encapsule un conteneur applicatif (ou, dans certains cas, plusieurs conteneurs), des ressources de stockage, une identité réseau (adresse IP) unique, ainsi que des options qui contrôlent comment le ou les conteneurs doivent s'exécuter. Un Pod représente une unité de déploiement : *une instance unique d'une application dans Kubernetes*, qui peut consister soit en un unique {{< glossary_tooltip text="container" term_id="container" >}} soit en un petit nombre de conteneurs qui sont étroitement liés et qui partagent des ressources. -> [Docker](https://www.docker.com) est le runtime de conteneurs le plus courant utilisé dans un Pod Kubernetes, mais les Pods prennent également en charge d'autres [runtimes de conteneurs](https://kubernetes.io/docs/setup/production-environment/container-runtimes/). +> [Docker](https://www.docker.com) est le runtime de conteneurs le plus courant utilisé dans un Pod Kubernetes, mais les Pods prennent également en charge d'autres [runtimes de conteneurs](/docs/setup/production-environment/container-runtimes/). Les Pods dans un cluster Kubernetes peuvent être utilisés de deux manières différentes : * **les Pods exécutant un conteneur unique**. Le modèle "un-conteneur-par-Pod" est le cas d'utilisation Kubernetes le plus courant ; dans ce cas, vous pouvez voir un Pod comme un wrapper autour d'un conteneur unique, et Kubernetes gère les Pods plutôt que directement les conteneurs. * **les Pods exécutant plusieurs conteneurs devant travailler ensemble**. Un Pod peut encapsuler une application composée de plusieurs conteneurs co-localisés qui sont étroitement liés et qui doivent partager des ressources. Ces conteneurs co-localisés pourraient former une unique unité de service cohésive--un conteneur servant des fichiers d'un volume partagé au public, alors qu'un conteneur "sidecar" séparé rafraîchit ou met à jour ces fichiers. Le Pod enveloppe ensemble ces conteneurs et ressources de stockage en une entité maniable de base. -Le [Blog Kubernetes](http://kubernetes.io/blog) contient quelques informations supplémentaires sur les cas d'utilisation des Pods. Pour plus d'informations, voir : - -* [The Distributed System Toolkit: Patterns for Composite Containers](https://kubernetes.io/blog/2015/06/the-distributed-system-toolkit-patterns) -* [Container Design Patterns](https://kubernetes.io/blog/2016/06/container-design-patterns) - -Chaque Pod est destiné à exécuter une instance unique d'une application donnée. Si vous désirez mettre à l'échelle votre application horizontalement, (par ex., exécuter plusieurs instances), vous devez utiliser plusieurs Pods, un pour chaque instance. Dans Kubernetes, on parle généralement de _réplication_. Des Pods répliqués sont en général créés et gérés comme un groupe par une abstraction appelée Controller. Voir [Pods et Controllers](#pods-and-controllers) pour plus d'informations. +Chaque Pod est destiné à exécuter une instance unique d'une application donnée. Si vous désirez mettre à l'échelle votre application horizontalement, (pour fournir plus de ressources au global en exécutant plus d'instances), vous devez utiliser plusieurs Pods, un pour chaque instance. Dans Kubernetes, on parle typiquement de _réplication_. Des Pods répliqués sont en général créés et gérés en tant que groupe par une ressource de charge de travail et son {{< glossary_tooltip text="_contrôleur_" term_id="controller" >}}. Voir [Pods et contrôleurs](#pods-et-controleurs) pour plus d'informations. ### Comment les Pods gèrent plusieurs conteneurs @@ -48,61 +43,76 @@ Les Pods fournissent deux types de ressources partagées pour leurs conteneurs : #### Réseau -Chaque Pod se voit assigner une adresse IP unique. Tous les conteneurs d'un Pod partagent le même namespace réseau, y compris l'adresse IP et les ports réseau. Les conteneurs *à l'intérieur d'un Pod* peuvent communiquer entre eux en utilisant `localhost`. Lorsque les conteneurs dans un Pod communiquent avec des entités *en dehors du Pod*, ils doivent coordonner comment ils utilisent les ressources réseau partagées (comme les ports). +Chaque Pod se voit assigner une adresse IP unique pour chaque famille d'adresses. Tous les conteneurs d'un Pod partagent le même namespace réseau, y compris l'adresse IP et les ports réseau. Les conteneurs *à l'intérieur d'un Pod* peuvent communiquer entre eux en utilisant `localhost`. Lorsque les conteneurs dans un Pod communiquent avec des entités *en dehors du Pod*, ils doivent coordonner comment ils utilisent les ressources réseau partagées (comme les ports). #### Stockage -Un Pod peut spécifier un jeu de {{< glossary_tooltip text="Volumes" term_id="volume" >}} de stockage partagés. Tous les conteneurs dans le Pod peuvent accéder aux volumes partagés, permettant à ces conteneurs de partager des données. Les volumes permettent aussi les données persistantes d'un Pod de survivre au cas où un des conteneurs doit être redémarré. Voir [Volumes](/docs/concepts/storage/volumes/) pour plus d'informations sur la façon dont Kubernetes implémente le stockage partagé dans un Pod. +Un Pod peut spécifier un jeu de {{< glossary_tooltip text="volumes" term_id="volume" >}} de stockage partagés. Tous les conteneurs dans le Pod peuvent accéder aux volumes partagés, permettant à ces conteneurs de partager des données. Les volumes permettent aussi les données persistantes d'un Pod de survivre au cas où un des conteneurs doit être redémarré. Voir [Volumes](/docs/concepts/storage/volumes/) pour plus d'informations sur la façon dont Kubernetes implémente le stockage partagé dans un Pod. ## Travailler avec des Pods -Vous aurez rarement à créer directement des Pods individuels dans Kubernetes--même des Pods à un seul conteneur. Ceci est dû au fait que les Pods sont conçus comme des entités relativement éphémères et jetables. Lorsqu'un Pod est créé (directement par vous ou indirectement par un Controller), il est programmé pour s'exécuter sur un {{< glossary_tooltip term_id="node" >}} dans votre cluster. Le Pod reste sur ce Nœud jusqu'à ce que le process se termine, l'objet pod soit supprimé, le pod soit *expulsé* par manque de ressources, ou le Nœud soit en échec. +Vous aurez rarement à créer directement des Pods individuels dans Kubernetes--même des Pods à un seul conteneur. Ceci est dû au fait que les Pods sont conçus comme des entités relativement éphémères et jetables. Lorsqu'un Pod est créé (directement par vous ou indirectement par un {{< glossary_tooltip text="_contrôleur_" term_id="controller" >}}), il est programmé pour s'exécuter sur un {{< glossary_tooltip term_id="node" >}} dans votre cluster. Le Pod reste sur ce nœud jusqu'à ce que le process se termine, l'objet pod soit supprimé, le pod soit *expulsé* par manque de ressources, ou le nœud soit en échec. {{< note >}} -Redémarrer un conteneur dans un Pod ne doit pas être confondu avec redémarrer le Pod. Le Pod lui-même ne s'exécute pas, mais est un environnement dans lequel les conteneurs s'exécutent, et persiste jusqu'à ce qu'il soit supprimé. +Redémarrer un conteneur dans un Pod ne doit pas être confondu avec redémarrer un Pod. Un Pod n'est pas un process, mais un environnement pour exécuter un conteneur. Un Pod persiste jusqu'à ce qu'il soit supprimé. {{< /note >}} -Les Pods ne se guérissent pas par eux-mêmes. Si un Pod est programmé sur un Nœud qui échoue, ou si l'opération de programmation elle-même échoue, le Pod est supprimé ; de plus, un Pod ne survivra pas à une expulsion due à un manque de ressources ou une mise en maintenance du Nœud. Kubernetes utilise une abstraction de plus haut niveau, appelée un *Controller*, qui s'occupe de gérer les instances de Pods relativement jetables. Ainsi, même s'il est possible d'utiliser des Pods directement, il est beaucoup plus courant dans Kubernetes de gérer vos Pods en utilisant un Controller. Voir [Pods et Controllers](#pods-and-controllers) pour plus d'informations sur la façon dont Kubernetes utilise des Controllers pour implémenter la mise à l'échelle et la guérison des Pods. +Les Pods ne se guérissent pas par eux-mêmes. Si un Pod est programmé sur un Nœud qui échoue, ou si l'opération de programmation elle-même échoue, le Pod est supprimé ; de plus, un Pod ne survivra pas à une expulsion due à un manque de ressources ou une mise en maintenance du Nœud. Kubernetes utilise une abstraction de plus haut niveau, appelée un *contrôleur*, qui s'occupe de gérer les instances de Pods relativement jetables. Ainsi, même s'il est possible d'utiliser des Pods directement, il est beaucoup plus courant dans Kubernetes de gérer vos Pods en utilisant un contrôleur. -### Pods et Controllers +### Pods et contrôleurs -Un Controller peut créer et gérer plusieurs Pods pour vous, s'occupant de la réplication et du déploiement et fournissant des capacités d'auto-guérison au niveau du cluster. Par exemple, si un Nœud échoue, le Controller peut automatiquement remplacer le Pod en programmant un remplaçant identique sur un Nœud différent. +Vous pouvez utiliser des ressources de charges de travail pour créer et gérer plusieurs Pods pour vous. Un contrôleur pour la ressource gère la réplication, +le plan de déploiement et la guérison automatique en cas de problèmes du Pod. Par exemple, si un noeud est en échec, un contrôleur note que les Pods de ce noeud +ont arrêté de fonctionner et créent des Pods pour les remplacer. L'ordonnanceur place le Pod de remplacement sur un noeud en fonctionnement. -Quelques exemples de Controllers qui contiennent un ou plusieurs pods : +Voici quelques exemples de ressources de charges de travail qui gèrent un ou plusieurs Pods : -* [Deployment](/docs/concepts/workloads/controllers/deployment/) -* [StatefulSet](/docs/concepts/workloads/controllers/statefulset/) -* [DaemonSet](/docs/concepts/workloads/controllers/daemonset/) - -En général, les Controllers utilisent des Templates de Pod que vous lui fournissez pour créer les Pods dont il est responsable. +* {{< glossary_tooltip text="Deployment" term_id="deployment" >}} +* {{< glossary_tooltip text="StatefulSet" term_id="statefulset" >}} +* {{< glossary_tooltip text="DaemonSet" term_id="daemonset" >}} ## Templates de Pod -Les Templates de Pod sont des spécifications de pod qui sont inclus dans d'autres objets, comme les -[Replication Controllers](/docs/concepts/workloads/controllers/replicationcontroller/), [Jobs](/docs/concepts/jobs/run-to-completion-finite-workloads/), et -[DaemonSets](/docs/concepts/workloads/controllers/daemonset/). Les Controllers utilisent les Templates de Pod pour créer réellement les pods. -L'exemple ci-dessous est un manifeste simple pour un Pod d'un conteneur affichant un message. +Les Templates de Pod sont des spécifications pour créer des Pods, et sont inclus dans les ressources de charges de travail comme +les [Deployments](/fr/docs/concepts/workloads/controllers/deployment/), les [Jobs](/docs/concepts/jobs/run-to-completion-finite-workloads/) et +les [DaemonSets](/docs/concepts/workloads/controllers/daemonset/). + +Chaque contrôleur pour une ressource de charges de travail utilise le template de pod à l'intérieur de l'objet pour créer les Pods. Le template de pod fait partie de l'état désiré de la ressource de charges de travail que vous avez utilisé pour exécuter votre application. + +L'exemple ci-dessous est un manifest pour un Job simple avec un `template` qui démarre un conteneur. Le conteneur dans ce Pod affiche un message puis se met en pause. ```yaml -apiVersion: v1 -kind: Pod +apiVersion: batch/v1 +kind: Job metadata: - name: myapp-pod - labels: - app: myapp + name: hello spec: - containers: - - name: myapp-container - image: busybox - command: ['sh', '-c', 'echo Hello Kubernetes! && sleep 3600'] + template: + # Ceci est un template de pod + spec: + containers: + - name: hello + image: busybox + command: ['sh', '-c', 'echo "Hello, Kubernetes!" && sleep 3600'] + restartPolicy: OnFailure + # Le template de pod se termine ici ``` -Plutôt que de spécifier tous les états désirés courants de tous les réplicas, les templates de pod sont comme des emporte-pièces. Une fois qu'une pièce a été coupée, la pièce n'a plus de relation avec l'outil. Il n'y a pas de lien qui persiste dans le temps entre le template et le pod. Un changement à venir dans le template ou même le changement pour un nouveau template n'a pas d'effet direct sur les pods déjà créés. De manière similaire, les pods créés par un replication controller peuvent par la suite être modifiés directement. C'est en contraste délibéré avec les pods, qui spécifient l'état désiré courant de tous les conteneurs appartenant au pod. Cette approche simplifie radicalement la sémantique système et augmente la flexibilité de la primitive. + +Modifier le template de pod ou changer pour un nouvau template de pod n'a pas d'effet sur les pods déjà existants. Les Pods ne reçoivent pas une mise à jour +du template directement ; au lieu de cela, un nouveau Pod est créé pour correspondre au nouveau template de pod. + +Par exemple, un contrôleur de Deployment s'assure que les Pods en cours d'exécution correspondent au template de pod en cours. Si le template est mis à jour, +le contrôleur doit supprimer les pods existants et créer de nouveaux Pods avec le nouveau template. Chaque contrôleur de charges de travail implémente ses propres +règles pour gérer les changements du template de Pod. + +Sur les noeuds, le {{< glossary_tooltip term_id="kubelet" text="kubelet" >}} n'observe ou ne gère pas directement les détails concernant les templates de pods et leurs mises à jours ; ces détails sont abstraits. Cette abstraction et cette séparation des préoccupations simplifie la sémantique du système, et rend possible l'extension du comportement du cluster sans changer le code existant. ## {{% heading "whatsnext" %}} * En savoir plus sur les [Pods](/docs/concepts/workloads/pods/pod/) +* [The Distributed System Toolkit: Patterns for Composite Containers](https://kubernetes.io/blog/2015/06/the-distributed-system-toolkit-patterns) explique les dispositions courantes pour des Pods avec plusieurs conteneurs * En savoir plus sur le comportement des Pods : * [Terminaison d'un Pod](/docs/concepts/workloads/pods/pod/#termination-of-pods) * [Cycle de vie d'un Pod](/docs/concepts/workloads/pods/pod-lifecycle/) diff --git a/content/fr/docs/concepts/workloads/pods/pod.md b/content/fr/docs/concepts/workloads/pods/pod.md index 4d685cca80..b989a8fd8d 100644 --- a/content/fr/docs/concepts/workloads/pods/pod.md +++ b/content/fr/docs/concepts/workloads/pods/pod.md @@ -164,7 +164,7 @@ Un exemple de déroulement : 1. Le Pod dans l'API server est mis à jour avec le temps au delà duquel le Pod est considéré "mort" ainsi que la période de grâce. 1. Le Pod est affiché comme "Terminating" dans les listes des commandes client 1. (en même temps que 3) Lorsque Kubelet voit qu'un Pod a été marqué "Terminating", le temps ayant été mis en 2, il commence le processus de suppression du pod. - 1. Si un des conteneurs du Pod a défini un [preStop hook](/docs/concepts/containers/container-lifecycle-hooks/#hook-details), il est exécuté à l'intérieur du conteneur. Si le `preStop` hook est toujours en cours d'exécution à la fin de la période de grâce, l'étape 2 est invoquée avec une courte (2 secondes) période de grâce supplémentaire. + 1. Si un des conteneurs du Pod a défini un [preStop hook](/fr/docs/concepts/containers/container-lifecycle-hooks/#hook-details), il est exécuté à l'intérieur du conteneur. Si le `preStop` hook est toujours en cours d'exécution à la fin de la période de grâce, l'étape 2 est invoquée avec une courte (2 secondes) période de grâce supplémentaire une seule fois. Vous devez modifier `terminationGracePeriodSeconds` si le hook `preStop` a besoin de plus de temps pour se terminer. 1. Le signal TERM est envoyé aux conteneurs. Notez que tous les conteneurs du Pod ne recevront pas le signal TERM en même temps et il peut être nécessaire de définir des `preStop` hook si l'ordre d'arrêt est important. 1. (en même temps que 3) Le Pod est supprimé des listes d'endpoints des services, et n'est plus considéré comme faisant partie des pods en cours d'exécution pour les contrôleurs de réplication. Les Pods s'arrêtant lentement ne peuvent pas continuer à servir du trafic, les load balancers (comme le service proxy) les supprimant de leurs rotations. 1. Lorsque la période de grâce expire, les processus s'exécutant toujours dans le Pod sont tués avec SIGKILL. @@ -186,7 +186,6 @@ Si le master exécute Kubernetes v1.1 ou supérieur, et les nœuds exécutent un Si l'utilisateur appelle `kubectl describe pod FooPodName`, l'utilisateur peut voir la raison pour laquelle le pod est en état "pending". La table d'événements dans la sortie de la commande "describe" indiquera : `Error validating pod "FooPodName"."FooPodNamespace" from api, ignoring: spec.containers[0].securityContext.privileged: forbidden '<*>(0xc2089d3248)true'` - Si le master exécute une version antérieure à v1.1, les pods privilégiés ne peuvent alors pas être créés. Si l'utilisateur tente de créer un pod ayant un conteneur privilégié, l'utilisateur obtiendra l'erreur suivante : `The Pod "FooPodName" is invalid. spec.containers[0].securityContext.privileged: forbidden '<*>(0xc20b222db0)true'` @@ -196,4 +195,4 @@ spec.containers[0].securityContext.privileged: forbidden '<*>(0xc20b222db0)true' Le Pod est une ressource au plus haut niveau dans l'API REST Kubernetes. Plus de détails sur l'objet de l'API peuvent être trouvés à : [Objet de l'API Pod](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#pod-v1-core). - +Lorsque vous créez un manifest pour un objet Pod, soyez certain que le nom spécifié est un [nom de sous-domaine DNS](/docs/concepts/overview/working-with-objects/names#dns-subdomain-names) valide. diff --git a/content/fr/docs/reference/glossary/addons.md b/content/fr/docs/reference/glossary/addons.md new file mode 100644 index 0000000000..1911696b3f --- /dev/null +++ b/content/fr/docs/reference/glossary/addons.md @@ -0,0 +1,16 @@ +--- +title: Add-ons +id: addons +date: 2019-12-15 +full_link: /docs/concepts/cluster-administration/addons/ +short_description: > + Ressources qui étendent les fonctionnalités de Kubernetes. + +aka: +tags: +- tool +--- + Ressources qui étendent les fonctionnalités de Kubernetes. + +<!--more--> +[Installer des addons](/docs/concepts/cluster-administration/addons/) explique l'utilisation des modules complémentaires avec votre cluster et répertorie certains modules complémentaires populaires. diff --git a/content/fr/docs/reference/glossary/reviewer.md b/content/fr/docs/reference/glossary/reviewer.md new file mode 100644 index 0000000000..7f2e66b1cb --- /dev/null +++ b/content/fr/docs/reference/glossary/reviewer.md @@ -0,0 +1,17 @@ +--- +title: Reviewer +id: reviewer +date: 2018-04-12 +full_link: +short_description: > + Une personne qui examine la qualité et l'exactitude du code sur une partie du projet. + +aka: +tags: +- community +--- + Une personne qui examine la qualité et l'exactitude du code sur une partie du projet. + +<!--more--> + +Les réviseurs connaissent bien la base de code (codebase) et les principes d'ingénierie logicielle. Le statut du réviseur est limité à une partie de la base de code. diff --git a/content/fr/docs/reference/glossary/uid.md b/content/fr/docs/reference/glossary/uid.md new file mode 100644 index 0000000000..80f73c9c5c --- /dev/null +++ b/content/fr/docs/reference/glossary/uid.md @@ -0,0 +1,17 @@ +--- +title: UID +id: uid +date: 2018-04-12 +full_link: /docs/concepts/overview/working-with-objects/names +short_description: > + Chaîne de caractères générée par les systèmes Kubernetes pour identifier de manière unique les objets. + +aka: +tags: +- fundamental +--- + Chaîne de caractères générée par les systèmes Kubernetes pour identifier de manière unique les objets. + +<!--more--> + +Chaque objet créé pendant toute la durée de vie d'un cluster Kubernetes possède un UID distinct. Il vise à distinguer les occurrences historiques d'entités similaires. \ No newline at end of file diff --git a/content/fr/docs/reference/glossary/volume.md b/content/fr/docs/reference/glossary/volume.md new file mode 100644 index 0000000000..deeca963b6 --- /dev/null +++ b/content/fr/docs/reference/glossary/volume.md @@ -0,0 +1,20 @@ +--- +title: Volume +id: volume +date: 2018-04-12 +full_link: /fr/docs/concepts/storage/volumes/ +short_description: > + Un répertoire contenant des données, accessible aux conteneurs d'un pod. + +aka: +tags: +- core-object +- fundamental +--- + Un répertoire contenant des données, accessible aux {{< glossary_tooltip text="conteneurs" term_id="container" >}} d'un {{< glossary_tooltip term_id="pod" >}}. + +<!--more--> + +Un volume Kubernetes vit aussi longtemps que le pod qui le contient. Par conséquent, un volume survit à tous les conteneurs qui s'exécutent dans le pod, et les données contenues dans le volume sont préservées lors des redémarrages du conteneur. + +Voir [stockage](/fr/docs/concepts/storage/) pour plus d'informations. \ No newline at end of file diff --git a/content/fr/docs/reference/glossary/workload.md b/content/fr/docs/reference/glossary/workload.md new file mode 100644 index 0000000000..8b3a0fd3c3 --- /dev/null +++ b/content/fr/docs/reference/glossary/workload.md @@ -0,0 +1,22 @@ +--- +title: Workload +id: workloads +date: 2019-02-13 +full_link: /fr/docs/concepts/workloads/ +short_description: > + Une charge de travail (workload) est une application exécutée sur Kubernetes. + +aka: +tags: +- fundamental +--- + Une charge de travail (workload) est une application exécutée sur Kubernetes. + +<!--more--> + +Divers objets de base qui représentent différents types ou parties d'une charge de travail +incluent les objets DaemonSet, Deployment, Job, ReplicaSet et StatefulSet. + +Par exemple, une charge de travail constituée d'un serveur Web et d'une base de données peut exécuter la +base de données dans un {{< glossary_tooltip term_id="StatefulSet" >}} et le serveur web +dans un {{< glossary_tooltip term_id="Deployment" >}}. diff --git a/content/fr/docs/reference/kubectl/kubectl.md b/content/fr/docs/reference/kubectl/kubectl.md index 64a3c89ce1..23d788c0c3 100755 --- a/content/fr/docs/reference/kubectl/kubectl.md +++ b/content/fr/docs/reference/kubectl/kubectl.md @@ -1,6 +1,6 @@ --- title: kubectl -content_template: templates/tool-reference +content_type: tool-reference description: Référence kubectl notitle: true --- diff --git a/content/fr/docs/setup/learning-environment/minikube.md b/content/fr/docs/setup/learning-environment/minikube.md index 77ddde7f4d..77be61831f 100644 --- a/content/fr/docs/setup/learning-environment/minikube.md +++ b/content/fr/docs/setup/learning-environment/minikube.md @@ -235,16 +235,16 @@ minikube start --vm-driver=<nom_du_pilote> Minikube prend en charge les pilotes suivants: {{< note >}} -Voir [DRIVERS](https://git.k8s.io/minikube/docs/drivers.md) pour plus de détails sur les pilotes pris en charge et comment installer les plugins. +Voir [DRIVERS](https://minikube.sigs.k8s.io/docs/drivers/) pour plus de détails sur les pilotes pris en charge et comment installer les plugins. {{< /note >}} * virtualbox * vmwarefusion -* kvm2 ([installation du pilote](https://git.k8s.io/minikube/docs/drivers.md#kvm2-driver)) -* hyperkit ([installation du pilote](https://git.k8s.io/minikube/docs/drivers.md#hyperkit-driver)) -* hyperv ([installation du pilote](https://github.com/kubernetes/minikube/blob/master/docs/drivers.md#hyperv-driver)) +* kvm2 ([installation du pilote](https://minikube.sigs.k8s.io/docs/drivers/#kvm2-driver)) +* hyperkit ([installation du pilote](https://minikube.sigs.k8s.io/docs/drivers/#hyperkit-driver)) +* hyperv ([installation du pilote](https://minikube.sigs.k8s.io/docs/drivers/#hyperv-driver)) Notez que l'adresse IP ci-dessous est dynamique et peut changer. Il peut être récupéré avec `minikube ip`. -* vmware ([installation du pilote](https://github.com/kubernetes/minikube/blob/master/docs/drivers.md#vmware-unified-driver)) (VMware unified driver) +* vmware ([installation du pilote](https://minikube.sigs.k8s.io/docs/drivers/#vmware-unified-driver)) (VMware unified driver) * none (Exécute les composants Kubernetes sur l’hôte et non sur une machine virtuelle. Il n'est pas recommandé d'exécuter le pilote none sur des postes de travail personnels. L'utilisation de ce pilote nécessite Docker ([docker installer](https://docs.docker.com/install/linux/docker-ce/ubuntu/)) et un environnement Linux) #### Démarrage d'un cluster sur des exécutions de conteneur alternatives diff --git a/content/fr/docs/tasks/configure-pod-container/configure-service-account.md b/content/fr/docs/tasks/configure-pod-container/configure-service-account.md new file mode 100644 index 0000000000..1147f2234e --- /dev/null +++ b/content/fr/docs/tasks/configure-pod-container/configure-service-account.md @@ -0,0 +1,282 @@ +--- +title: Configurer les comptes de service pour les pods +content_type: task +weight: 90 +--- + +<!-- overview --> +Un ServiceAccount (compte de service) fournit une identité pour les processus qui s'exécutent dans un Pod. + +*Ceci est une introduction aux comptes de service pour les utilisateurs. Voir aussi +[Guide de l'administrateur du cluster des comptes de service](/docs/reference/access-authn-authz/service-accounts-admin/).* + +{{< note >}} +Ce document décrit le comportement des comptes de service dans un cluster mis en place conformément aux recommandations du projet Kubernetes. L'administrateur de votre cluster a peut-être personnalisé le comportement dans votre cluster, dans ce cas cette documentation pourrait être non applicable. +{{< /note >}} + +Lorsque vous (un humain) accédez au cluster (par exemple, en utilisant `kubectl`), vous êtes +authentifié par l'apiserver en tant que compte d'utilisateur particulier (actuellement, il s'agit +généralement de l'utilisateur `admin`, à moins que votre administrateur de cluster n'ait personnalisé votre cluster). Les processus dans les conteneurs dans les Pods peuvent également contacter l'apiserver. Dans ce cas, ils sont authentifiés en tant que compte de service particulier (par exemple, `default`). + + + + +## {{% heading "prerequisites" %}} + + +{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}} + + + +<!-- steps --> + +## Utiliser le compte de service par défaut pour accéder au API server. + +Si vous obtenez le raw json ou yaml pour un Pod que vous avez créé (par exemple, `kubectl get pods/<podname> -o yaml`), vous pouvez voir que le champ `spec.serviceAccountName` a été [automatiquement assigné](/docs/user-guide/working-with-resources/#resources-are-automatically-modified). + +Vous pouvez accéder à l'API depuis l'intérieur d'un Pod en utilisant les identifiants de compte de service montés automatiquement, comme décrit dans [Accès au cluster](/docs/user-guide/accessing-the-cluster/#accessing-the-api-from-a-pod). +Les permissions API du compte de service dépendent du [plugin d'autorisation et de la politique](/docs/reference/access-authn-authz/authorization/#authorization-modules) en usage. + +Dans la version 1.6+, vous pouvez choisir de ne pas utiliser le montage automatique des identifiants API pour un compte de service en définissant `automountServiceAccountToken: false` sur le compte de service : + +```yaml +apiVersion: v1 +kind: ServiceAccount +metadata: + name: build-robot +automountServiceAccountToken: false +... +``` + +Dans la version 1.6+, vous pouvez également choisir de ne pas monter automatiquement les identifiants API pour un Pod particulier : + +```yaml +apiVersion: v1 +kind: Pod +metadata: + name: my-pod +spec: + serviceAccountName: build-robot + automountServiceAccountToken: false + ... +``` + +La spéc de Pod a prépondérance par rapport au compte de service si les deux spécifient la valeur `automountServiceAccountToken`. + +## Utiliser plusieurs comptes de services. + +Chaque Namespace possède une ressource ServiceAccount par défaut appelée `default`. +Vous pouvez lister cette ressource et toutes les autres ressources de ServiceAccount dans le Namespace avec cette commande : + +```shell +kubectl get serviceAccounts +``` +La sortie est comme la suivante : + +``` +NAME SECRETS AGE +default 1 1d +``` + +Vous pouvez créer des objets ServiceAccount supplémentaires comme ceci : + +```shell +kubectl apply -f - <<EOF +apiVersion: v1 +kind: ServiceAccount +metadata: + name: build-robot +EOF +``` + +Si vous obtenez un dump complet de l'objet compte de service, par exemple : + +```shell +kubectl get serviceaccounts/build-robot -o yaml +``` +La sortie est comme la suivante : + +``` +apiVersion: v1 +kind: ServiceAccount +metadata: + creationTimestamp: 2015-06-16T00:12:59Z + name: build-robot + namespace: default + resourceVersion: "272500" + selfLink: /api/v1/namespaces/default/serviceaccounts/build-robot + uid: 721ab723-13bc-11e5-aec2-42010af0021e +secrets: +- name: build-robot-token-bvbk5 +``` + +vous verrez alors qu'un token a été automatiquement créé et est référencé par le compte de service. + +Vous pouvez utiliser des plugins d'autorisation pour [définir les permissions sur les comptes de service](/docs/reference/access-authn-authz/rbac/#service-account-permissions). + +Pour utiliser un compte de service autre que par défaut, il suffit de spécifier le `spec.serviceAccountName` d'un Pod au nom du compte de service que vous souhaitez utiliser. + +Le compte de service doit exister au moment de la création du Pod, sinon il sera rejeté. + +Vous ne pouvez pas mettre à jour le compte de service d'un Pod déjà créé. + +Vous pouvez supprimer le compte de service de cet exemple comme ceci : + +```shell +kubectl delete serviceaccount/build-robot +``` + +## Créez manuellement un API token de compte de service. + +Supposons que nous ayons un compte de service existant nommé "build-robot" comme mentionné ci-dessus,et que nous allons créer un nouveau Secret manuellement. + +```shell +kubectl apply -f - <<EOF +apiVersion: v1 +kind: Secret +metadata: + name: build-robot-secret + annotations: + kubernetes.io/service-account.name: build-robot +type: kubernetes.io/service-account-token +EOF +``` + +Vous pouvez maintenant confirmer que le Secret nouvellement construit est rempli d'un API token pour le compte de service "build-robot". + +Tous les tokens pour des comptes de service non-existants seront nettoyés par le contrôleur de token. + +```shell +kubectl describe secrets/build-robot-secret +``` +La sortie est comme la suivante : + +``` +Name: build-robot-secret +Namespace: default +Labels: <none> +Annotations: kubernetes.io/service-account.name=build-robot + kubernetes.io/service-account.uid=da68f9c6-9d26-11e7-b84e-002dc52800da + +Type: kubernetes.io/service-account-token + +Data +==== +ca.crt: 1338 bytes +namespace: 7 bytes +token: ... +``` + +{{< note >}} +Le contenu de `token` est éludé ici. +{{< /note >}} + +## Ajouter ImagePullSecrets à un compte de service + +Tout d'abord, créez un imagePullSecret, comme décrit [ici](/docs/concepts/containers/images/#specifying-imagepullsecrets-on-a-pod). +Puis, vérifiez qu'il a été créé. Par exemple : + +```shell +kubectl get secrets myregistrykey +``` + +La sortie est comme la suivante : + +``` +NAME TYPE DATA AGE +myregistrykey   kubernetes.io/.dockerconfigjson   1       1d +``` + +Ensuite, modifiez le compte de service par défaut du Namespace pour utiliser ce Secret comme un `imagePullSecret`. + +```shell +kubectl patch serviceaccount default -p '{"imagePullSecrets": [{"name": "myregistrykey"}]}' +``` + +La version interactive nécessite un traitement manuel : + +```shell +kubectl get serviceaccounts default -o yaml > ./sa.yaml +``` + +La sortie du fichier `sa.yaml` est similaire à celle-ci : + +```shell +apiVersion: v1 +kind: ServiceAccount +metadata: + creationTimestamp: 2015-08-07T22:02:39Z + name: default + namespace: default + resourceVersion: "243024" + selfLink: /api/v1/namespaces/default/serviceaccounts/default + uid: 052fb0f4-3d50-11e5-b066-42010af0d7b6 +secrets: +- name: default-token-uudge +``` + +En utilisant l'éditeur de votre choix (par exemple `vi`), ouvrez le fichier `sa.yaml`, supprimez la ligne avec la clé `resourceVersion`, ajoutez les lignes avec `imagePullSecrets:` et sauvegardez. + +La sortie du fichier `sa.yaml` est similaire à celle-ci : + +```shell +apiVersion: v1 +kind: ServiceAccount +metadata: + creationTimestamp: 2015-08-07T22:02:39Z + name: default + namespace: default + selfLink: /api/v1/namespaces/default/serviceaccounts/default + uid: 052fb0f4-3d50-11e5-b066-42010af0d7b6 +secrets: +- name: default-token-uudge +imagePullSecrets: +- name: myregistrykey +``` + +Enfin, remplacez le compte de service par le nouveau fichier `sa.yaml` mis à jour. + +```shell +kubectl replace serviceaccount default -f ./sa.yaml +``` + +Maintenant, tous les nouveaux Pods créés dans le Namespace courant auront ceci ajouté à leurs spécifications : + +```yaml +spec: + imagePullSecrets: + - name: myregistrykey +``` + +## Projection du volume des tokens de compte de service + +{{< feature-state for_k8s_version="v1.12" state="beta" >}} + +{{< note >}} +Ce ServiceAccountTokenVolumeProjection est __beta__ en 1.12 et +activé en passant tous les paramètres suivants au serveur API : + +* `--service-account-issuer` +* `--service-account-signing-key-file` +* `--service-account-api-audiences` + +{{< /note >}} + +Kubelet peut également projeter un token de compte de service dans un Pod. Vous pouvez spécifier les propriétés souhaitées du token, telles que l'audience et la durée de validité. +Ces propriétés ne sont pas configurables sur le compte de service par défaut. Le token de compte de service devient également invalide par l'API lorsque le Pod ou le ServiceAccount est supprimé + +Ce comportement est configuré sur un PodSpec utilisant un type de ProjectedVolume appelé +[ServiceAccountToken](/docs/concepts/storage/volumes/#projected). Pour fournir un +Pod avec un token avec une audience de "vault" et une durée de validité de deux heures, vous devriez configurer ce qui suit dans votre PodSpec : + +{{< codenew file="pods/pod-projected-svc-token.yaml" >}} + +Créez le Pod + +```shell +kubectl create -f https://k8s.io/examples/pods/pod-projected-svc-token.yaml +``` + +Kubelet demandera et stockera le token a la place du Pod, rendra le token disponible pour le Pod à un chemin d'accès configurable, et rafraîchissez le token à l'approche de son expiration. Kubelet fait tourner le token de manière proactive s'il est plus vieux que 80% de son TTL total, ou si le token est plus vieux que 24 heures. + +L'application est responsable du rechargement du token lorsque celui ci est renouvelé. Un rechargement périodique (par ex. toutes les 5 minutes) est suffisant pour la plupart des cas d'utilisation. diff --git a/content/fr/docs/tasks/tools/install-kubectl.md b/content/fr/docs/tasks/tools/install-kubectl.md index 8d60357aea..2a88388374 100644 --- a/content/fr/docs/tasks/tools/install-kubectl.md +++ b/content/fr/docs/tasks/tools/install-kubectl.md @@ -121,7 +121,7 @@ kubectl version --client curl -LO https://storage.googleapis.com/kubernetes-release/release/{{< param "fullversion" >}}/bin/darwin/amd64/kubectl ``` -2. Rendrez le binaire kubectl exécutable. +2. Rendez le binaire kubectl exécutable. ``` chmod +x ./kubectl diff --git a/content/fr/docs/tutorials/hello-minikube.md b/content/fr/docs/tutorials/hello-minikube.md index 724919d0e6..a934464b77 100644 --- a/content/fr/docs/tutorials/hello-minikube.md +++ b/content/fr/docs/tutorials/hello-minikube.md @@ -78,7 +78,7 @@ Les déploiements sont le moyen recommandé pour gérer la création et la mise Pod utilise un conteneur basé sur l'image Docker fournie. ```shell - kubectl create deployment hello-node --image=gcr.io/hello-minikube-zero-install/hello-node + kubectl create deployment hello-node --image=k8s.gcr.io/echoserver:1.4 ``` 2. Affichez le déploiement : diff --git a/content/fr/examples/pods/pod-projected-svc-token.yaml b/content/fr/examples/pods/pod-projected-svc-token.yaml new file mode 100644 index 0000000000..985073c8d3 --- /dev/null +++ b/content/fr/examples/pods/pod-projected-svc-token.yaml @@ -0,0 +1,20 @@ +apiVersion: v1 +kind: Pod +metadata: + name: nginx +spec: + containers: + - image: nginx + name: nginx + volumeMounts: + - mountPath: /var/run/secrets/tokens + name: vault-token + serviceAccountName: build-robot + volumes: + - name: vault-token + projected: + sources: + - serviceAccountToken: + path: vault-token + expirationSeconds: 7200 + audience: vault diff --git a/content/id/_index.html b/content/id/_index.html index 47d7f71ced..e95d661b76 100644 --- a/content/id/_index.html +++ b/content/id/_index.html @@ -4,7 +4,6 @@ abstract: "Otomatisasi Kontainer deployment, scaling, dan management" cid: home --- -{{< deprecationwarning >}} {{< blocks/section id="oceanNodes" >}} {{% blocks/feature image="flower" %}} @@ -60,4 +59,4 @@ Kubernetes sebagai <i>open source</i> memberikan kamu kebebasan untuk menggunaka {{< blocks/kubernetes-features >}} -{{< blocks/case-studies >}} +{{< blocks/case-studies >}} \ No newline at end of file diff --git a/content/id/docs/concepts/_index.md b/content/id/docs/concepts/_index.md index ebc205d84a..33f4ada445 100644 --- a/content/id/docs/concepts/_index.md +++ b/content/id/docs/concepts/_index.md @@ -49,19 +49,19 @@ untuk penjelasan yang lebih mendetail. Objek mendasar Kubernetes termasuk: -* [Pod](/docs/concepts/workloads/pods/pod-overview/) -* [Service](/docs/concepts/services-networking/service/) -* [Volume](/docs/concepts/storage/volumes/) -* [Namespace](/docs/concepts/overview/working-with-objects/namespaces/) +* [Pod](/id/docs/concepts/workloads/pods/pod-overview/) +* [Service](/id/docs/concepts/services-networking/service/) +* [Volume](/id/docs/concepts/storage/volumes/) +* [Namespace](/id/docs/concepts/overview/working-with-objects/namespaces/) Sebagai tambahan, Kubernetes memiliki beberapa abstraksi yang lebih tinggi yang disebut kontroler. Kontroler merupakan objek mendasar dengan fungsi tambahan, contoh dari kontroler ini adalah: -* [ReplicaSet](/docs/concepts/workloads/controllers/replicaset/) -* [Deployment](/docs/concepts/workloads/controllers/deployment/) -* [StatefulSet](/docs/concepts/workloads/controllers/statefulset/) -* [DaemonSet](/docs/concepts/workloads/controllers/daemonset/) -* [Job](/docs/concepts/workloads/controllers/jobs-run-to-completion/) +* [ReplicaSet](/id/docs/concepts/workloads/controllers/replicaset/) +* [Deployment](/id/docs/concepts/workloads/controllers/deployment/) +* [StatefulSet](/id/docs/concepts/workloads/controllers/statefulset/) +* [DaemonSet](/id/docs/concepts/workloads/controllers/daemonset/) +* [Job](/id/docs/concepts/workloads/controllers/jobs-run-to-completion/) ## *Control Plane* Kubernetes @@ -95,7 +95,7 @@ dengan *node* secara langsung. #### Metadata objek -* [Anotasi](/docs/concepts/overview/working-with-objects/annotations/) +* [Anotasi](/id/docs/concepts/overview/working-with-objects/annotations/) diff --git a/content/id/docs/concepts/architecture/master-node-communication.md b/content/id/docs/concepts/architecture/control-plane-node-communication.md similarity index 60% rename from content/id/docs/concepts/architecture/master-node-communication.md rename to content/id/docs/concepts/architecture/control-plane-node-communication.md index 80644983a4..b538179670 100644 --- a/content/id/docs/concepts/architecture/master-node-communication.md +++ b/content/id/docs/concepts/architecture/control-plane-node-communication.md @@ -1,12 +1,12 @@ --- -title: Komunikasi Master-Node +title: Komunikasi antara Control Plane dan Node content_type: concept weight: 20 --- <!-- overview --> -Dokumen ini menjelaskan tentang jalur-jalur komunikasi di antara klaster Kubernetes dan master yang sebenarnya hanya berhubungan dengan apiserver saja. +Dokumen ini menjelaskan tentang jalur-jalur komunikasi di antara klaster Kubernetes dan control plane yang sebenarnya hanya berhubungan dengan apiserver saja. Kenapa ada dokumen ini? Supaya kamu, para pengguna Kubernetes, punya gambaran bagaimana mengatur instalasi untuk memperketat konfigurasi jaringan di dalam klaster. Hal ini cukup penting, karena klaster bisa saja berjalan pada jaringan tak terpercaya (<i>untrusted network</i>), ataupun melalui alamat-alamat IP publik pada penyedia cloud. @@ -15,31 +15,24 @@ Hal ini cukup penting, karena klaster bisa saja berjalan pada jaringan tak terpe <!-- body --> -## Klaster menuju Master +## Node Menuju Control Plane -Semua jalur komunikasi dari klaster menuju master diterminasi pada apiserver. -Tidak ada komponen apapun di dalam master, selain apiserver, yang terekspos ke luar untuk diakses dari servis <i>remote</i>. -Untuk instalasi klaster pada umumnya, apiserver diatur untuk <i>listen</i> ke koneksi <i>remote</i> melalui port HTTPS (443) yang aman, dengan satu atau beberapa metode [autentikasi](/docs/reference/access-authn-authz/authentication/) <i>client</i> yang telah terpasang. +Kubernetes memiliki sebuah pola API "hub-and-spoke". Semua penggunaan API dari Node (atau Pod dimana Pod-Pod tersebut dijalankan) akan diterminasi pada apiserver (tidak ada satu komponen _control plane_ apa pun yang didesain untuk diekspos pada servis _remote_). +Apiserver dikonfigurasi untuk mendengarkan koneksi aman _remote_ yang pada umumnya terdapat pada porta HTTPS (443) dengan satu atau lebih bentuk [autentikasi](/docs/reference/access-authn-authz/authentication/) klien yang dipasang. Sebaiknya, satu atau beberapa metode [otorisasi](/docs/reference/access-authn-authz/authorization/) juga dipasang, terutama jika kamu memperbolehkan [permintaan anonim (<i>anonymous request</i>)](/docs/reference/access-authn-authz/authentication/#anonymous-requests) ataupun [service account token](/docs/reference/access-authn-authz/authentication/#service-account-tokens). -Node-node seharusnya disediakan dengan <i>public root certificate</i> untuk klaster, sehingga node-node tersebut bisa terhubung secara aman ke apiserver dengan kredensial <i>client</i> yang valid. -Contohnya, untuk instalasi GKE dengan standar konfigurasi, kredensial <i>client</i> harus diberikan kepada kubelet dalam bentuk <i>client certificate</i>. -Lihat [menghidupkan TLS kubelet](/docs/reference/command-line-tools-reference/kubelet-tls-bootstrapping/) untuk menyediakan <i>client certificate</i> untuk kubelet secara otomatis. +Jika diperlukan, Pod-Pod dapat terhubung pada apiserver secara aman dengan menggunakan ServiceAccount. +Dengan ini, Kubernetes memasukkan _public root certificate_ dan _bearer token_ yang valid ke dalam Pod, secara otomatis saat Pod mulai dijalankan. +Kubernetes Service (di dalam semua Namespace) diatur dengan sebuah alamat IP virtual. Semua yang mengakses alamat IP ini akan dialihkan (melalui kube-proxy) menuju _endpoint_ HTTPS dari apiserver. -Jika diperlukan, pod-pod dapat terhubung pada apiserver secara aman dengan menggunakan <i>service account</i>. -Dengan ini, Kubernetes memasukkan <i>public root certificate</i> dan <i>bearer token</i> yang valid ke dalam pod, secara otomatis saat pod mulai dijalankan. -Kubernetes <i>service</i> (di dalam semua <i>namespace</i>) diatur dengan sebuah alamat IP virtual. -Semua yang mengakses alamat IP ini akan dialihkan (melalui kube-proxy) menuju <i>endpoint</i> HTTPS dari apiserver. +Komponen-komponen juga melakukan koneksi pada apiserver klaster melalui porta yang aman. -Komponen-komponen master juga berkomunikasi dengan apiserver melalui port yang aman di dalam klaster. -Akibatnya, untuk konfigurasi yang umum dan standar, semua koneksi dari klaster (node-node dan pod-pod yang berjalan di atas node tersebut) menuju master sudah terhubung dengan aman. -Dan juga, klaster dan master bisa terhubung melalui jaringan publik dan/atau yang tak terpercaya (<i>untrusted</i>). +Akibatnya, untuk konfigurasi yang umum dan standar, semua koneksi dari klaster (node-node dan pod-pod yang berjalan di atas node tersebut) menujucontrol planesudah terhubung dengan aman. +Dan juga, klaster dancontrol planebisa terhubung melalui jaringan publik dan/atau yang tak terpercaya (<i>untrusted</i>). -## Master menuju Klaster +## Control Plane menuju Node -Ada dua jalur komunikasi utama dari master (apiserver) menuju klaster. -Pertama, dari apiserver ke <i>process</i> kubelet yang berjalan pada setiap node di dalam klaster. -Kedua, dari apiserver ke setiap node, pod, ataupun service melalui fungsi <i>proxy</i> pada apiserver. +Ada dua jalur komunikasi utama dari _control plane_ (apiserver) menuju klaster. Pertama, dari apiserver ke proses kubelet yang berjalan pada setiap Node di dalam klaster. Kedua, dari apiserver ke setiap Node, Pod, ataupun Service melalui fungsi proksi pada apiserver ### Apiserver menuju kubelet @@ -67,11 +60,9 @@ Koneksi ini **tidak aman** untuk dilalui pada jaringan publik dan/atau tak terpe ### Tunnel SSH -Kubernetes menyediakan tunnel SSH untuk mengamankan jalur komunikasi Master -> Klaster. +Kubernetes menyediakan tunnel SSH untuk mengamankan jalur komunikasi control plane -> Klaster. Dengan ini, apiserver menginisiasi sebuah <i>tunnel</i> SSH untuk setiap node di dalam klaster (terhubung ke server SSH di port 22) dan membuat semua trafik menuju kubelet, node, pod, atau service dilewatkan melalui <i>tunnel</i> tesebut. <i>Tunnel</i> ini memastikan trafik tidak terekspos keluar jaringan dimana node-node berada. <i>Tunnel</i> SSH saat ini sudah usang (<i>deprecated</i>), jadi sebaiknya jangan digunakan, kecuali kamu tahu pasti apa yang kamu lakukan. Sebuah desain baru untuk mengganti kanal komunikasi ini sedang disiapkan. - - diff --git a/content/id/docs/concepts/architecture/controller.md b/content/id/docs/concepts/architecture/controller.md index a0ff6b9256..6cf90cf9e6 100644 --- a/content/id/docs/concepts/architecture/controller.md +++ b/content/id/docs/concepts/architecture/controller.md @@ -33,7 +33,7 @@ klaster saat ini mendekati keadaan yang diinginkan. Sebuah _controller_ melacak sekurang-kurangnya satu jenis sumber daya dari Kubernetes. -[objek-objek](/docs/concepts/overview/working-with-objects/kubernetes-objects/) ini +[objek-objek](/id/docs/concepts/overview/working-with-objects/kubernetes-objects/) ini memiliki *spec field* yang merepresentasikan keadaan yang diinginkan. Satu atau lebih _controller_ untuk *resource* tersebut bertanggung jawab untuk membuat keadaan sekarang mendekati keadaan yang diinginkan. @@ -174,6 +174,6 @@ khusus itu lakukan. * Silahkan baca tentang [_control plane_ Kubernetes](/docs/concepts/#kubernetes-control-plane) * Temukan beberapa dasar tentang [objek-objek Kubernetes](/docs/concepts/#kubernetes-objects) -* Pelajari lebih lanjut tentang [Kubernetes API](/docs/concepts/overview/kubernetes-api/) -* Apabila kamu ingin membuat _controller_ sendiri, silakan lihat [pola perluasan](/docs/concepts/extend-kubernetes/extend-cluster/#extension-patterns) dalam memperluas Kubernetes. +* Pelajari lebih lanjut tentang [Kubernetes API](/id/docs/concepts/overview/kubernetes-api/) +* Apabila kamu ingin membuat _controller_ sendiri, silakan lihat [pola perluasan](/id/docs/concepts/extend-kubernetes/extend-cluster/#extension-patterns) dalam memperluas Kubernetes. diff --git a/content/id/docs/concepts/architecture/nodes.md b/content/id/docs/concepts/architecture/nodes.md index 8913c9df65..ab13cf122a 100644 --- a/content/id/docs/concepts/architecture/nodes.md +++ b/content/id/docs/concepts/architecture/nodes.md @@ -8,8 +8,8 @@ weight: 10 Node merupakan sebuah mesin <i>worker</i> di dalam Kubernetes, yang sebelumnya dinamakan `minion`. Sebuah node bisa berupa VM ataupun mesin fisik, tergantung dari klaster-nya. -Masing-masing node berisi beberapa servis yang berguna untuk menjalankan banyak [pod](/docs/concepts/workloads/pods/pod/) dan diatur oleh komponen-komponen yang dimiliki oleh master. -Servis-servis di dalam sebuah node terdiri dari [runtime kontainer](/docs/concepts/overview/components/#node-components), kubelet dan kube-proxy. +Masing-masing node berisi beberapa servis yang berguna untuk menjalankan banyak [pod](/id/docs/concepts/workloads/pods/pod/) dan diatur oleh komponen-komponen yang dimiliki oleh master. +Servis-servis di dalam sebuah node terdiri dari [runtime kontainer](/id/docs/concepts/overview/components/#node-components), kubelet dan kube-proxy. Untuk lebih detail, lihat dokumentasi desain arsitektur pada [Node Kubernetes](https://git.k8s.io/community/contributors/design-proposals/architecture/architecture.md#the-kubernetes-node). @@ -67,12 +67,12 @@ Pada kasus tertentu ketika node terputus jaringannya, apiserver tidak dapat berk Keputusan untuk menghilangkan pod tidak dapat diberitahukan pada kubelet, sampai komunikasi dengan apiserver terhubung kembali. Sementara itu, pod-pod akan terus berjalan pada node yang sudah terputus, walaupun mendapati <i>schedule</i> untuk dihilangkan. -Pada versi Kubernetes sebelum 1.5, kontroler node dapat menghilangkan dengan paksa ([force delete](/docs/concepts/workloads/pods/pod/#force-deletion-of-pods)) pod-pod yang terputus dari apiserver. +Pada versi Kubernetes sebelum 1.5, kontroler node dapat menghilangkan dengan paksa ([force delete](/id/docs/concepts/workloads/pods/pod/#force-deletion-of-pods)) pod-pod yang terputus dari apiserver. Namun, pada versi 1.5 dan seterusnya, kontroler node tidak menghilangkan pod dengan paksa, sampai ada konfirmasi bahwa pod tersebut sudah berhenti jalan di dalam klaster. Pada kasus dimana Kubernetes tidak bisa menarik kesimpulan bahwa ada node yang telah meninggalkan klaster, admin klaster mungkin perlu untuk menghilangkan node secara manual. Menghilangkan obyek node dari Kubernetes akan membuat semua pod yang berjalan pada node tersebut dihilangkan oleh apiserver, dan membebaskan nama-namanya agar bisa digunakan kembali. -Pada versi 1.12, fitur `TaintNodesByCondition` telah dipromosikan ke beta, sehingga kontroler <i>lifecycle</i> node secara otomatis membuat [taints](/docs/concepts/configuration/taint-and-toleration/) yang merepresentasikan <i>conditions</i>. +Pada versi 1.12, fitur `TaintNodesByCondition` telah dipromosikan ke beta, sehingga kontroler <i>lifecycle</i> node secara otomatis membuat [taints](/id/docs/concepts/configuration/taint-and-toleration/) yang merepresentasikan <i>conditions</i>. Akibatnya, <i>scheduler</i> menghiraukan <i>conditions</i> ketika mempertimbangkan sebuah Node; <i>scheduler</i> akan melihat pada <i>taints</i> sebuah Node dan <i>tolerations</i> sebuah Pod. Sekarang, para pengguna dapat memilih antara model <i>scheduling</i> yang lama dan model <i>scheduling</i> yang lebih fleksibel. @@ -93,7 +93,7 @@ Informasi ini dikumpulkan oleh Kubelet di dalam node. ## Manajemen -Tidak seperti [pod](/docs/concepts/workloads/pods/pod/) dan [service](/docs/concepts/services-networking/service/), sebuah node tidaklah dibuat dan dikonfigurasi oleh Kubernetes: tapi node dibuat di luar klaster oleh penyedia layanan cloud, seperti Google Compute Engine, atau <i>pool</i> mesin fisik ataupun virtual (VM) yang kamu punya. +Tidak seperti [pod](/id/docs/concepts/workloads/pods/pod/) dan [service](/id/docs/concepts/services-networking/service/), sebuah node tidaklah dibuat dan dikonfigurasi oleh Kubernetes: tapi node dibuat di luar klaster oleh penyedia layanan cloud, seperti Google Compute Engine, atau <i>pool</i> mesin fisik ataupun virtual (VM) yang kamu punya. Jadi ketika Kubernetes membuat sebuah node, obyek yang merepresentasikan node tersebut akan dibuat. Setelah pembuatan, Kubernetes memeriksa apakah node tersebut valid atau tidak. Contohnya, jika kamu mencoba untuk membuat node dari konten berikut: @@ -164,7 +164,7 @@ Pada kasus ini, kontroler node berasumsi ada masalah pada jaringan master, dan m Mulai dari Kubernetes 1.6, kontroler node juga bertanggung jawab untuk melakukan <i>eviction</i> pada pod-pod yang berjalan di atas node dengan <i>taints</i> `NoExecute`, ketika pod-pod tersebut sudah tidak lagi <i>tolerate</i> terhadap <i>taints</i>. Sebagai tambahan, hal ini di-nonaktifkan secara <i>default</i> pada fitur alpha, kontroler node bertanggung jawab untuk menambahkan <i>taints</i> yang berhubungan dengan masalah pada node, seperti terputus atau `NotReady`. -Lihat [dokumentasi ini](/docs/concepts/configuration/taint-and-toleration/) untuk bahasan detail tentang <i>taints</i> `NoExecute` dan fitur alpha. +Lihat [dokumentasi ini](/id/docs/concepts/configuration/taint-and-toleration/) untuk bahasan detail tentang <i>taints</i> `NoExecute` dan fitur alpha. Mulai dari versi 1.8, kontroler node bisa diatur untuk bertanggung jawab pada pembuatan <i>taints</i> yang merepresentasikan node <i>condition</i>. Ini merupakan fitur alpha untuk versi 1.8. @@ -218,7 +218,7 @@ Jika kamu melakukan [administrasi node manual](#manual-node-administration), mak <i>Scheduler</i> Kubernetes memastikan kalau ada <i>resource</i> yang cukup untuk menjalankan semua pod di dalam sebuah node. Kubernetes memeriksa jumlah semua <i>request</i> untuk kontainer pada sebuah node tidak lebih besar daripada kapasitas node. -Hal ini termasuk semua kontainer yang dijalankan oleh kubelet. Namun, ini tidak termasuk kontainer-kontainer yang dijalankan secara langsung oleh [runtime kontainer](/docs/concepts/overview/components/#node-components) ataupun <i>process</i> yang ada di luar kontainer. +Hal ini termasuk semua kontainer yang dijalankan oleh kubelet. Namun, ini tidak termasuk kontainer-kontainer yang dijalankan secara langsung oleh [runtime kontainer](/id/docs/concepts/overview/components/#node-components) ataupun <i>process</i> yang ada di luar kontainer. Kalau kamu ingin secara eksplisit menyimpan <i>resource</i> cadangan untuk menjalankan <i>process-process</i> selain Pod, ikut tutorial [menyimpan resource cadangan untuk <i>system daemon</i>](/docs/tasks/administer-cluster/reserve-compute-resources/#system-reserved). diff --git a/content/id/docs/concepts/cluster-administration/addons.md b/content/id/docs/concepts/cluster-administration/addons.md index b404465d8f..ca50347492 100644 --- a/content/id/docs/concepts/cluster-administration/addons.md +++ b/content/id/docs/concepts/cluster-administration/addons.md @@ -32,7 +32,7 @@ Laman ini akan menjabarkan beberapa *add-ons* yang tersedia serta tautan instruk * [Multus](https://github.com/Intel-Corp/multus-cni) merupakan sebuah multi *plugin* agar Kubernetes mendukung multipel jaringan secara bersamaan sehingga dapat menggunakan semua *plugin* CNI (contoh: Calico, Cilium, Contiv, Flannel), ditambah pula dengan SRIOV, DPDK, OVS-DPDK dan VPP pada *workload* Kubernetes. * [NSX-T](https://docs.vmware.com/en/VMware-NSX-T/2.0/nsxt_20_ncp_kubernetes.pdf) Container Plug-in (NCP) menyediakan integrasi antara VMware NSX-T dan orkestrator kontainer seperti Kubernetes, termasuk juga integrasi antara NSX-T dan platform CaaS/PaaS berbasis kontainer seperti *Pivotal Container Service* (PKS) dan OpenShift. * [Nuage](https://github.com/nuagenetworks/nuage-kubernetes/blob/v5.1.1-1/docs/kubernetes-1-installation.rst) merupakan platform SDN yang menyediakan *policy-based* jaringan antara Kubernetes Pods dan non-Kubernetes *environment* dengan *monitoring* visibilitas dan keamanan. -* [Romana](http://romana.io) merupakan solusi jaringan *Layer* 3 untuk jaringan pod yang juga mendukung [*NetworkPolicy* API](/docs/concepts/services-networking/network-policies/). Instalasi Kubeadm *add-on* ini tersedia [di sini](https://github.com/romana/romana/tree/master/containerize). +* [Romana](http://romana.io) merupakan solusi jaringan *Layer* 3 untuk jaringan pod yang juga mendukung [*NetworkPolicy* API](/id/docs/concepts/services-networking/network-policies/). Instalasi Kubeadm *add-on* ini tersedia [di sini](https://github.com/romana/romana/tree/master/containerize). * [Weave Net](https://www.weave.works/docs/net/latest/kube-addon/) menyediakan jaringan serta *policy* jaringan, yang akan membawa kedua sisi dari partisi jaringan, serta tidak membutuhkan basis data eksternal. ## _Service Discovery_ diff --git a/content/id/docs/concepts/cluster-administration/certificates.md b/content/id/docs/concepts/cluster-administration/certificates.md index a605a78547..ee1f91cbeb 100644 --- a/content/id/docs/concepts/cluster-administration/certificates.md +++ b/content/id/docs/concepts/cluster-administration/certificates.md @@ -245,6 +245,6 @@ done. Kamu dapat menggunakan API `Certificate.k8s.io` untuk menyediakan sertifikat x509 yang digunakan untuk autentikasi seperti yang didokumentasikan -[di sini](/docs/tasks/tls/managing-tls-in-a-cluster). +[di sini](/id/docs/tasks/tls/managing-tls-in-a-cluster). diff --git a/content/id/docs/concepts/cluster-administration/cloud-providers.md b/content/id/docs/concepts/cluster-administration/cloud-providers.md index 45820e3660..9a32af1eb8 100644 --- a/content/id/docs/concepts/cluster-administration/cloud-providers.md +++ b/content/id/docs/concepts/cluster-administration/cloud-providers.md @@ -56,7 +56,7 @@ Bagian ini akan menjelaskan semua konfigurasi yang dapat diatur saat menjalankan Penyedia layanan cloud AWS menggunakan nama DNS privat dari *instance* AWS sebagai nama dari objek Kubernetes Node. ### *Load Balancer* -Kamu dapat mengatur [load balancers eksternal](/docs/tasks/access-application-cluster/create-external-load-balancer/) sehingga dapat menggunakan fitur khusus AWS dengan mengatur anotasi seperti di bawah ini. +Kamu dapat mengatur [load balancers eksternal](/id/docs/tasks/access-application-cluster/create-external-load-balancer/) sehingga dapat menggunakan fitur khusus AWS dengan mengatur anotasi seperti di bawah ini. ```yaml apiVersion: v1 diff --git a/content/id/docs/concepts/cluster-administration/cluster-administration-overview.md b/content/id/docs/concepts/cluster-administration/cluster-administration-overview.md index b485b5e142..b2bd349908 100644 --- a/content/id/docs/concepts/cluster-administration/cluster-administration-overview.md +++ b/content/id/docs/concepts/cluster-administration/cluster-administration-overview.md @@ -20,10 +20,10 @@ Lihat panduan di [Persiapan](/docs/setup) untuk mempelajari beberapa contoh tent Sebelum memilih panduan, berikut adalah beberapa hal yang perlu dipertimbangkan: - Apakah kamu hanya ingin mencoba Kubernetes pada komputermu, atau kamu ingin membuat sebuah klaster dengan *high-availability*, *multi-node*? Pilihlah distro yang paling sesuai dengan kebutuhanmu. - - **Jika kamu merencanakan klaster dengan _high-availability_**, pelajari bagaimana cara mengonfigurasi [klaster pada *multiple zone*](/docs/concepts/cluster-administration/federation/). + - **Jika kamu merencanakan klaster dengan _high-availability_**, pelajari bagaimana cara mengonfigurasi [klaster pada *multiple zone*](/id/docs/concepts/cluster-administration/federation/). - Apakah kamu akan menggunakan **Kubernetes klaster di _hosting_**, seperti [Google Kubernetes Engine](https://cloud.google.com/kubernetes-engine/), atau **_hosting_ sendiri klastermu**? - Apakah klastermu berada pada **_on-premises_**, atau **di cloud (IaaS)**? Kubernetes belum mendukung secara langsung klaster hibrid. Sebagai gantinya, kamu dapat membuat beberapa klaster. - - **Jika kamu ingin mengonfigurasi Kubernetes _on-premises_**, pertimbangkan [model jaringan](/docs/concepts/cluster-administration/networking/) yang paling sesuai. + - **Jika kamu ingin mengonfigurasi Kubernetes _on-premises_**, pertimbangkan [model jaringan](/id/docs/concepts/cluster-administration/networking/) yang paling sesuai. - Apakah kamu ingin menjalankan Kubernetes pada **"bare metal" _hardware_** atau pada **_virtual machines_ (VM)**? - Apakah kamu **hanya ingin mencoba klaster Kubernetes**, atau kamu ingin ikut aktif melakukan **pengembangan kode dari proyek Kubernetes**? Jika jawabannya yang terakhir, pilihlah distro yang aktif dikembangkan. Beberapa distro hanya menggunakan rilis *binary*, namun menawarkan lebih banyak variasi pilihan. - Pastikan kamu paham dan terbiasa dengan beberapa [komponen](/docs/admin/cluster-components/) yang dibutuhkan untuk menjalankan sebuah klaster. @@ -36,13 +36,13 @@ Catatan: Tidak semua distro aktif dikelola. Pilihlah distro yang telah diuji den * Pelajari bagaimana cara [mengatur *node*](/docs/concepts/nodes/node/). -* Pelajari bagaimana cara membuat dan mengatur kuota resource [(*resource quota*)](/docs/concepts/policy/resource-quotas/) untuk *shared* klaster. +* Pelajari bagaimana cara membuat dan mengatur kuota resource [(*resource quota*)](/id/docs/concepts/policy/resource-quotas/) untuk *shared* klaster. ## Mengamankan Klaster -* [Sertifikat (*certificate*)](/docs/concepts/cluster-administration/certificates/) akan menjabarkan langkah-langkah untuk membuat sertifikat menggunakan beberapa *tool chains*. +* [Sertifikat (*certificate*)](/id/docs/concepts/cluster-administration/certificates/) akan menjabarkan langkah-langkah untuk membuat sertifikat menggunakan beberapa *tool chains*. -* [Kubernetes *Container Environment*](/docs/concepts/containers/container-environment-variables/) akan menjelaskan *environment* untuk kontainer yang dikelola oleh Kubelet pada Kubernetes *node*. +* [Kubernetes *Container Environment*](/id/docs/concepts/containers/container-environment-variables/) akan menjelaskan *environment* untuk kontainer yang dikelola oleh Kubelet pada Kubernetes *node*. * [Mengontrol Akses ke Kubernetes API](/docs/reference/access-authn-authz/controlling-access/) akan menjabarkan bagaimana cara mengatur izin (*permission*) untuk akun pengguna dan *service account*. @@ -63,9 +63,9 @@ Catatan: Tidak semua distro aktif dikelola. Pilihlah distro yang telah diuji den ## Layanan Tambahan Klaster -* [Integrasi DNS](/docs/concepts/services-networking/dns-pod-service/) akan menjelaskan bagaimana cara *resolve* suatu nama DNS langsung pada *service* Kubernetes. +* [Integrasi DNS](/id/docs/concepts/services-networking/dns-pod-service/) akan menjelaskan bagaimana cara *resolve* suatu nama DNS langsung pada *service* Kubernetes. -* [*Logging* dan *Monitoring* Aktivitas Klaster](/docs/concepts/cluster-administration/logging/) akan menjelaskan bagaimana cara *logging* bekerja di Kubernetes serta bagaimana cara mengimplementasikannya. +* [*Logging* dan *Monitoring* Aktivitas Klaster](/id/docs/concepts/cluster-administration/logging/) akan menjelaskan bagaimana cara *logging* bekerja di Kubernetes serta bagaimana cara mengimplementasikannya. diff --git a/content/id/docs/concepts/cluster-administration/federation.md b/content/id/docs/concepts/cluster-administration/federation.md index 7690a75a82..d59da126ad 100644 --- a/content/id/docs/concepts/cluster-administration/federation.md +++ b/content/id/docs/concepts/cluster-administration/federation.md @@ -106,7 +106,7 @@ Berikut merupakan panduan yang akan menjelaskan masing-masing _resource_ secara * [Namespaces](/docs/tasks/administer-federation/namespaces/) * [ReplicaSets](/docs/tasks/administer-federation/replicaset/) * [Secrets](/docs/tasks/administer-federation/secret/) -* [Services](/docs/concepts/cluster-administration/federation-service-discovery/) +* [Services](/id/docs/concepts/cluster-administration/federation-service-discovery/) [Referensi Dokumentasi API](/docs/reference/federation/) memberikan semua daftar diff --git a/content/id/docs/concepts/cluster-administration/logging.md b/content/id/docs/concepts/cluster-administration/logging.md index 53203777f2..75f3b97189 100644 --- a/content/id/docs/concepts/cluster-administration/logging.md +++ b/content/id/docs/concepts/cluster-administration/logging.md @@ -173,7 +173,7 @@ Menggunakan agen _logging_ di dalam kontainer _sidecar_ dapat berakibat pengguna {{< /note >}} Sebagai contoh, kamu dapat menggunakan [Stackdriver](/docs/tasks/debug-application-cluster/logging-stackdriver/), -yang menggunakan fluentd sebagai agen _logging_. Berikut ini dua _file_ konfigurasi yang dapat kamu pakai untuk mengimplementasikan cara ini. _File_ yang pertama berisi sebuah [ConfigMap](/docs/tasks/configure-pod-container/configure-pod-configmap/) untuk mengonfigurasi fluentd. +yang menggunakan fluentd sebagai agen _logging_. Berikut ini dua _file_ konfigurasi yang dapat kamu pakai untuk mengimplementasikan cara ini. _File_ yang pertama berisi sebuah [ConfigMap](/id/docs/tasks/configure-pod-container/configure-pod-configmap/) untuk mengonfigurasi fluentd. {{< codenew file="admin/logging/fluentd-sidecar-config.yaml" >}} diff --git a/content/id/docs/concepts/cluster-administration/manage-deployment.md b/content/id/docs/concepts/cluster-administration/manage-deployment.md index 81c0ba4d08..d67da9c13e 100644 --- a/content/id/docs/concepts/cluster-administration/manage-deployment.md +++ b/content/id/docs/concepts/cluster-administration/manage-deployment.md @@ -6,7 +6,7 @@ weight: 40 <!-- overview --> -Kamu telah melakukan _deploy_ pada aplikasimu dan mengeksposnya melalui sebuah _service_. Lalu? Kubernetes menyediakan berbagai peralatan untuk membantu mengatur mekanisme _deploy_ aplikasi, termasuk pengaturan kapasitas dan pembaruan. Diantara fitur yang akan didiskusikan lebih mendalam yaitu [berkas konfigurasi](/docs/concepts/configuration/overview/) dan [label](/docs/concepts/overview/working-with-objects/labels/). +Kamu telah melakukan _deploy_ pada aplikasimu dan mengeksposnya melalui sebuah _service_. Lalu? Kubernetes menyediakan berbagai peralatan untuk membantu mengatur mekanisme _deploy_ aplikasi, termasuk pengaturan kapasitas dan pembaruan. Diantara fitur yang akan didiskusikan lebih mendalam yaitu [berkas konfigurasi](/id/docs/concepts/configuration/overview/) dan [label](/id/docs/concepts/overview/working-with-objects/labels/). @@ -290,7 +290,7 @@ my-nginx-2035384211-u3t6x 1/1 Running 0 23m fe Akan muncul semua _pod_ dengan "app=nginx" dan sebuah kolom label tambahan yaitu tier (ditentukan dengan `-L` atau `--label-columns`). -Untuk informasi lebih lanjut, silahkan baca [label](/docs/concepts/overview/working-with-objects/labels/) dan [kubectl label](/docs/reference/generated/kubectl/kubectl-commands/#label). +Untuk informasi lebih lanjut, silahkan baca [label](/id/docs/concepts/overview/working-with-objects/labels/) dan [kubectl label](/docs/reference/generated/kubectl/kubectl-commands/#label). ## Memperbarui anotasi @@ -309,7 +309,7 @@ metadata: ... ``` -Untuk informasi lebih lanjut, silahkan lihat laman [annotations](/docs/concepts/overview/working-with-objects/annotations/) dan [kubectl annotate](/docs/reference/generated/kubectl/kubectl-commands/#annotate). +Untuk informasi lebih lanjut, silahkan lihat laman [annotations](/id/docs/concepts/overview/working-with-objects/annotations/) dan [kubectl annotate](/docs/reference/generated/kubectl/kubectl-commands/#annotate). ## Memperbesar dan memperkecil aplikasi kamu @@ -432,7 +432,7 @@ Untuk memperbarui versi ke 1.9.1, ganti `.spec.template.spec.containers[0].image kubectl edit deployment/my-nginx ``` -Selesai! Deployment akan memperbarui aplikasi nginx yang terdeploy secara berangsur di belakang. Dia akan menjamin hanya ada sekian replika lama yang akan down selagi pembaruan berjalan dan hanya ada sekian replika baru akan dibuat melebihi jumlah pod. Untuk mempelajari lebih lanjut, kunjungi [laman Deployment](/docs/concepts/workloads/controllers/deployment/). +Selesai! Deployment akan memperbarui aplikasi nginx yang terdeploy secara berangsur di belakang. Dia akan menjamin hanya ada sekian replika lama yang akan down selagi pembaruan berjalan dan hanya ada sekian replika baru akan dibuat melebihi jumlah pod. Untuk mempelajari lebih lanjut, kunjungi [laman Deployment](/id/docs/concepts/workloads/controllers/deployment/). @@ -440,6 +440,6 @@ Selesai! Deployment akan memperbarui aplikasi nginx yang terdeploy secara berang - [Pelajari tentang bagaimana memakai `kubectl` untuk memeriksa dan _debug_ aplikasi.](/docs/tasks/debug-application-cluster/debug-application-introspection/) -- [Praktik Terbaik dan Tips Konfigurasi](/docs/concepts/configuration/overview/) +- [Praktik Terbaik dan Tips Konfigurasi](/id/docs/concepts/configuration/overview/) diff --git a/content/id/docs/concepts/cluster-administration/networking.md b/content/id/docs/concepts/cluster-administration/networking.md index 038465bcb8..6bcd78d7ef 100644 --- a/content/id/docs/concepts/cluster-administration/networking.md +++ b/content/id/docs/concepts/cluster-administration/networking.md @@ -10,10 +10,10 @@ untuk memahami persis bagaimana mengharapkannya bisa bekerja. Ada 4 masalah yang berbeda untuk diatasi: 1. Komunikasi antar kontainer yang sangat erat: hal ini diselesaikan oleh - [Pod](/docs/concepts/workloads/pods/pod/) dan komunikasi `localhost`. + [Pod](/id/docs/concepts/workloads/pods/pod/) dan komunikasi `localhost`. 2. Komunikasi antar Pod: ini adalah fokus utama dari dokumen ini. -3. Komunikasi Pod dengan Service: ini terdapat di [Service](/docs/concepts/services-networking/service/). -4. Komunikasi eksternal dengan Service: ini terdapat di [Service](/docs/concepts/services-networking/service/). +3. Komunikasi Pod dengan Service: ini terdapat di [Service](/id/docs/concepts/services-networking/service/). +4. Komunikasi eksternal dengan Service: ini terdapat di [Service](/id/docs/concepts/services-networking/service/). @@ -213,7 +213,7 @@ Calico juga dapat dijalankan dalam mode penegakan kebijakan bersama dengan solus ### Romana -[Romana](http://romana.io) adalah jaringan sumber terbuka dan solusi otomasi keamanan yang memungkinkan kamu menggunakan Kubernetes tanpa jaringan hamparan. Romana mendukung Kubernetes [Kebijakan Jaringan](/docs/concepts/services-networking/network-policies/) untuk memberikan isolasi di seluruh ruang nama jaringan. +[Romana](http://romana.io) adalah jaringan sumber terbuka dan solusi otomasi keamanan yang memungkinkan kamu menggunakan Kubernetes tanpa jaringan hamparan. Romana mendukung Kubernetes [Kebijakan Jaringan](/id/docs/concepts/services-networking/network-policies/) untuk memberikan isolasi di seluruh ruang nama jaringan. ### Weave Net dari Weaveworks diff --git a/content/id/docs/concepts/cluster-administration/proxies.md b/content/id/docs/concepts/cluster-administration/proxies.md index 5595414aa9..f3567233e0 100644 --- a/content/id/docs/concepts/cluster-administration/proxies.md +++ b/content/id/docs/concepts/cluster-administration/proxies.md @@ -14,7 +14,7 @@ Laman ini menjelaskan berbagai <i>proxy</i> yang ada di dalam Kubernetes. Ada beberapa jenis <i>proxy</i> yang akan kamu temui saat menggunakan Kubernetes: -1. [kubectl proxy](/docs/tasks/access-application-cluster/access-cluster/#directly-accessing-the-rest-api): +1. [kubectl proxy](/id/docs/tasks/access-application-cluster/access-cluster/#directly-accessing-the-rest-api): - dijalankan pada <i>desktop</i> pengguna atau di dalam sebuah Pod - melakukan <i>proxy</i> dari alamat localhost ke apiserver Kubernetes @@ -23,7 +23,7 @@ Ada beberapa jenis <i>proxy</i> yang akan kamu temui saat menggunakan Kubernetes - mencari lokasi apiserver - menambahkan <i>header</i> autentikasi -1. [apiserver proxy](/docs/tasks/access-application-cluster/access-cluster/#discovering-builtin-services): +1. [apiserver proxy](/id/docs/tasks/access-application-cluster/access-cluster/#discovering-builtin-services): - merupakan sebuah <i>bastion</i> yang ada di dalam apiserver - menghubungkan pengguna di luar klaster ke alamat-alamat IP di dalam klaster yang tidak bisa terjangkau @@ -33,7 +33,7 @@ Ada beberapa jenis <i>proxy</i> yang akan kamu temui saat menggunakan Kubernetes - dapat digunakan untuk menghubungi Node, Pod, atau Service - melakukan <i>load balancing</i> saat digunakan untuk menjangkau sebuah Service -1. [kube proxy](/docs/concepts/services-networking/service/#ips-and-vips): +1. [kube proxy](/id/docs/concepts/services-networking/service/#ips-and-vips): - dijalankan pada setiap Node - melakukan <i>proxy</i> untuk UDP, TCP dan SCTP diff --git a/content/id/docs/concepts/configuration/assign-pod-node.md b/content/id/docs/concepts/configuration/assign-pod-node.md index 8af1abba28..ee9e8bf2f4 100644 --- a/content/id/docs/concepts/configuration/assign-pod-node.md +++ b/content/id/docs/concepts/configuration/assign-pod-node.md @@ -7,7 +7,7 @@ weight: 30 <!-- overview --> -Kamu dapat memaksa sebuah [pod](/docs/concepts/workloads/pods/pod/) untuk hanya dapat berjalan pada [node](/docs/concepts/architecture/nodes/) tertentu atau mengajukannya agar berjalan pada node tertentu. Ada beberapa cara untuk melakukan hal tersebut. Semua cara yang direkomendasikan adalah dengan menggunakan [_selector_ label](/docs/concepts/overview/working-with-objects/labels/) untuk menetapkan pilihan yang kamu inginkan. Pada umumnya, pembatasan ini tidak dibutuhkan, sebagaimana _scheduler_ akan melakukan penempatan yang proporsional dengan otomatis (seperti contohnya menyebar pod di node-node, tidak menempatkan pod pada node dengan sumber daya yang tidak memadai, dst.) tetapi ada keadaan-keadaan tertentu yang membuat kamu memiliki kendali lebih terhadap node yang menjadi tempat pod dijalankan, contohnya untuk memastikan pod dijalankan pada mesin yang telah terpasang SSD, atau untuk menempatkan pod-pod dari dua servis yang berbeda yang sering berkomunikasi bersamaan ke dalam zona ketersediaan yang sama. +Kamu dapat memaksa sebuah [pod](/id/docs/concepts/workloads/pods/pod/) untuk hanya dapat berjalan pada [node](/id/docs/concepts/architecture/nodes/) tertentu atau mengajukannya agar berjalan pada node tertentu. Ada beberapa cara untuk melakukan hal tersebut. Semua cara yang direkomendasikan adalah dengan menggunakan [_selector_ label](/id/docs/concepts/overview/working-with-objects/labels/) untuk menetapkan pilihan yang kamu inginkan. Pada umumnya, pembatasan ini tidak dibutuhkan, sebagaimana _scheduler_ akan melakukan penempatan yang proporsional dengan otomatis (seperti contohnya menyebar pod di node-node, tidak menempatkan pod pada node dengan sumber daya yang tidak memadai, dst.) tetapi ada keadaan-keadaan tertentu yang membuat kamu memiliki kendali lebih terhadap node yang menjadi tempat pod dijalankan, contohnya untuk memastikan pod dijalankan pada mesin yang telah terpasang SSD, atau untuk menempatkan pod-pod dari dua servis yang berbeda yang sering berkomunikasi bersamaan ke dalam zona ketersediaan yang sama. Kamu dapat menemukan semua berkas untuk contoh-contoh berikut pada [dokumentasi yang kami sediakan di sini](https://github.com/kubernetes/website/tree/{{< param "docsbranch" >}}/content/en/docs/concepts/configuration/) @@ -114,7 +114,7 @@ Berikut ini contoh dari pod yang menggunakan afinitas node: Aturan afinitas node tersebut menyatakan pod hanya bisa ditugaskan pada node dengan label yang memiliki kunci `kubernetes.io/e2e-az-name` dan bernilai `e2e-az1` atau `e2e-az2`. Selain itu, dari semua node yang memenuhi kriteria tersebut, mode dengan label dengan kunci `another-node-label-key` and bernilai `another-node-label-value` harus lebih diutamakan. -Kamu dapat meilhat operator `In` digunakan dalam contoh berikut. Sitaksis afinitas node yang baru mendukung operator-operator berikut: `In`, `NotIn`, `Exists`, `DoesNotExist`, `Gt`, `Lt`. Kamu dapat menggunakan `NotIn` dan `DoesNotExist` untuk mewujudkan perilaku node anti-afinitas, atau menggunakan [node taints](/docs/concepts/configuration/taint-and-toleration/) untuk menolak pod dari node tertentu. +Kamu dapat meilhat operator `In` digunakan dalam contoh berikut. Sitaksis afinitas node yang baru mendukung operator-operator berikut: `In`, `NotIn`, `Exists`, `DoesNotExist`, `Gt`, `Lt`. Kamu dapat menggunakan `NotIn` dan `DoesNotExist` untuk mewujudkan perilaku node anti-afinitas, atau menggunakan [node taints](/id/docs/concepts/configuration/taint-and-toleration/) untuk menolak pod dari node tertentu. Jika kamu menyatakan `nodeSelector` dan `nodeAffinity`. *keduanya* harus dipenuhi agar pod dapat dijadwalkan pada node kandidat. @@ -284,7 +284,7 @@ Lihat [tutorial ZooKeeper](/docs/tutorials/stateful-application/zookeeper/#toler Untuk informasi lebih lanjut tentang afinitas/anti-afinitas antar pod, lihat [design doc](https://git.k8s.io/community/contributors/design-proposals/scheduling/podaffinity.md). -Kamu juga dapat mengecek [Taints](/docs/concepts/configuration/taint-and-toleration/), yang memungkinkan sebuah *node* untuk *menolak* sekumpulan pod. +Kamu juga dapat mengecek [Taints](/id/docs/concepts/configuration/taint-and-toleration/), yang memungkinkan sebuah *node* untuk *menolak* sekumpulan pod. ## nodeName diff --git a/content/id/docs/concepts/configuration/manage-compute-resources-container.md b/content/id/docs/concepts/configuration/manage-compute-resources-container.md index 3450bab459..600a4cc6cd 100644 --- a/content/id/docs/concepts/configuration/manage-compute-resources-container.md +++ b/content/id/docs/concepts/configuration/manage-compute-resources-container.md @@ -10,7 +10,7 @@ feature: <!-- overview --> -Saat kamu membuat spesifikasi sebuah [Pod](/docs/concepts/workloads/pods/pod/), kamu +Saat kamu membuat spesifikasi sebuah [Pod](/id/docs/concepts/workloads/pods/pod/), kamu dapat secara opsional menentukan seberapa banyak CPU dan memori (RAM) yang dibutuhkan oleh setiap Container. Saat Container-Container menentukan _request_ (permintaan) sumber daya, scheduler dapat membuat keputusan yang lebih baik mengenai Node mana yang akan dipilih @@ -42,8 +42,8 @@ Hal ini berbeda dari sumber daya `memory` dan `cpu` (yang dapat di-_overcommit_) CPU dan memori secara kolektif disebut sebagai _sumber daya komputasi_, atau cukup _sumber daya_ saja. Sumber daya komputasi adalah jumlah yang dapat diminta, dialokasikan, -dan dikonsumsi. Mereka berbeda dengan [sumber daya API](/docs/concepts/overview/kubernetes-api/). -Sumber daya API, seperti Pod dan [Service](/docs/concepts/services-networking/service/) adalah +dan dikonsumsi. Mereka berbeda dengan [sumber daya API](/id/docs/concepts/overview/kubernetes-api/). +Sumber daya API, seperti Pod dan [Service](/id/docs/concepts/services-networking/service/) adalah objek-objek yang dapat dibaca dan diubah melalui Kubernetes API Server. ## Request dan Limit Sumber daya dari Pod dan Container @@ -270,7 +270,7 @@ _daemon_ sistem menggunakan sebagian dari sumber daya yang ada. Kolom `allocatab memberikan jumlah sumber daya yang tersedia untuk Pod-Pod. Untuk lebih lanjut, lihat [Sumber daya Node yang dapat dialokasikan](https://git.k8s.io/community/contributors/design-proposals/node/node-allocatable.md). -Fitur [kuota sumber daya](/docs/concepts/policy/resource-quotas/) dapat disetel untuk +Fitur [kuota sumber daya](/id/docs/concepts/policy/resource-quotas/) dapat disetel untuk membatasi jumlah sumber daya yang dapat digunakan. Jika dipakai bersama dengan Namespace, kuota sumber daya dapat mencegah suatu tim menghabiskan semua sumber daya. @@ -489,7 +489,7 @@ Sumber daya yang diperluas pada tingkat Node terikat pada Node. ##### Sumber daya Device Plugin yang dikelola Lihat [Device -Plugin](/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins/) untuk +Plugin](/id/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins/) untuk cara menyatakan sumber daya _device plugin_ yang dikelola pada setiap node. ##### Sumber daya lainnya diff --git a/content/id/docs/concepts/configuration/organize-cluster-access-kubeconfig.md b/content/id/docs/concepts/configuration/organize-cluster-access-kubeconfig.md index 929c895821..caba991a8d 100644 --- a/content/id/docs/concepts/configuration/organize-cluster-access-kubeconfig.md +++ b/content/id/docs/concepts/configuration/organize-cluster-access-kubeconfig.md @@ -24,7 +24,7 @@ tanda [`--kubeconfig`](/docs/reference/generated/kubectl/kubectl/). Instruksi langkah demi langkah untuk membuat dan menentukan berkas kubeconfig, bisa mengacu pada [Mengatur Akses Pada Beberapa Klaster] -(/docs/tasks/access-application-cluster/configure-access-multiple-clusters). +(/id/docs/tasks/access-application-cluster/configure-access-multiple-clusters). @@ -103,7 +103,7 @@ kubeconfig: abaikan mereka. Beberapa contoh pengaturan variabel _environment_ `KUBECONFIG`, bisa melihat pada - [pengaturan vaiabel _environment_ KUBECONFIG](/docs/tasks/access-application-cluster/configure-access-multiple-clusters/#set-the-kubeconfig-environment-variable). + [pengaturan vaiabel _environment_ KUBECONFIG](/id/docs/tasks/access-application-cluster/configure-access-multiple-clusters/#set-the-kubeconfig-environment-variable). Sebaliknya, bisa menggunakan berkas kubeconfig _default_, `$HOME/.kube/config`, tanpa melakukan penggabungan. @@ -158,7 +158,7 @@ _absolute path_ akan disimpan secara mutlak. ## {{% heading "whatsnext" %}} -* [Mengatur Akses Pada Beberapa Klaster](/docs/tasks/access-application-cluster/configure-access-multiple-clusters/) +* [Mengatur Akses Pada Beberapa Klaster](/id/docs/tasks/access-application-cluster/configure-access-multiple-clusters/) * [`kubectl config`](/docs/reference/generated/kubectl/kubectl-commands#config) diff --git a/content/id/docs/concepts/configuration/overview.md b/content/id/docs/concepts/configuration/overview.md index 76d68658ec..67fb2061fe 100644 --- a/content/id/docs/concepts/configuration/overview.md +++ b/content/id/docs/concepts/configuration/overview.md @@ -32,14 +32,14 @@ Dokumentasi ini terbuka. Jika Anda menemukan sesuatu yang tidak ada dalam daftar ## "Naked" Pods vs ReplicaSets, Deployments, and Jobs -- Jangan gunakan Pods naked (artinya, Pods tidak terikat dengan a [ReplicaSet](/docs/concepts/workloads/controllers/replicaset/) a [Deployment](/docs/concepts/workloads/controllers/deployment/)) jika kamu bisa menghindarinya. Pod naked tidak akan dijadwal ulang jika terjadi kegagalan pada node. +- Jangan gunakan Pods naked (artinya, Pods tidak terikat dengan a [ReplicaSet](/id/docs/concepts/workloads/controllers/replicaset/) a [Deployment](/id/docs/concepts/workloads/controllers/deployment/)) jika kamu bisa menghindarinya. Pod naked tidak akan dijadwal ulang jika terjadi kegagalan pada node. - Deployment, yang keduanya menciptakan ReplicaSet untuk memastikan bahwa jumlah Pod yang diinginkan selalu tersedia, dan menentukan strategi untuk mengganti Pods (seperti [RollingUpdate](/docs/concepts/workloads/controllers/deployment/#rolling-update-deployment)), hampir selalu lebih disukai daripada membuat Pods secara langsung, kecuali untuk beberapa yang eksplisit [`restartPolicy: Never`](/docs/concepts/workloads/pods/pod-lifecycle/#restart-policy) banyak skenario . A [Job](/docs/concepts/workloads/controllers/jobs-run-to-completion/) mungkin juga sesuai. + Deployment, yang keduanya menciptakan ReplicaSet untuk memastikan bahwa jumlah Pod yang diinginkan selalu tersedia, dan menentukan strategi untuk mengganti Pods (seperti [RollingUpdate](/id/docs/concepts/workloads/controllers/deployment/#rolling-update-deployment)), hampir selalu lebih disukai daripada membuat Pods secara langsung, kecuali untuk beberapa yang eksplisit [`restartPolicy: Never`](/id/docs/concepts/workloads/pods/pod-lifecycle/#restart-policy) banyak skenario . A [Job](/id/docs/concepts/workloads/controllers/jobs-run-to-completion/) mungkin juga sesuai. ## Services -- Buat [Service](/docs/concepts/services-networking/service/) sebelum workloads backend terkait (Penyebaran atau ReplicaSets), dan sebelum workloads apa pun yang perlu mengaksesnya. Ketika Kubernetes memulai sebuah container, ia menyediakan environment variabel yang menunjuk ke semua Layanan yang berjalan ketika container itu dimulai. Misalnya, jika Layanan bernama `foo` ada, semua container akan mendapatkan variabel berikut di environment awalnya: +- Buat [Service](/id/docs/concepts/services-networking/service/) sebelum workloads backend terkait (Penyebaran atau ReplicaSets), dan sebelum workloads apa pun yang perlu mengaksesnya. Ketika Kubernetes memulai sebuah container, ia menyediakan environment variabel yang menunjuk ke semua Layanan yang berjalan ketika container itu dimulai. Misalnya, jika Layanan bernama `foo` ada, semua container akan mendapatkan variabel berikut di environment awalnya: ```shell FOO_SERVICE_HOST=<the host the Service is running on> @@ -48,26 +48,26 @@ Dokumentasi ini terbuka. Jika Anda menemukan sesuatu yang tidak ada dalam daftar *Ini menunjukan persyaratan pemesanan * - `Service` apa pun yang ingin diakses oleh` Pod` harus dibuat sebelum `Pod` itu sendiri, atau environment variabel tidak akan diisi. DNS tidak memiliki batasan ini. -- Opsional (meskipun sangat disarankan) [cluster add-on](/docs/concepts/cluster-administration/addons/) adalah server DNS. +- Opsional (meskipun sangat disarankan) [cluster add-on](/id/docs/concepts/cluster-administration/addons/) adalah server DNS. Server DNS melihat API Kubernetes untuk `Service` baru dan membuat satu set catatan DNS untuk masing-masing. Jika DNS telah diaktifkan di seluruh cluster maka semua `Pods` harus dapat melakukan resolusi nama`Service` secara otomatis. - Jangan tentukan `hostPort` untuk Pod kecuali jika benar-benar diperlukan. Ketika Anda bind Pod ke `hostPort`, hal itu membatasi jumlah tempat Pod dapat dijadwalkan, karena setiap kombinasi <` hostIP`, `hostPort`,` protokol`> harus unik. Jika Anda tidak menentukan `hostIP` dan` protokol` secara eksplisit, Kubernetes akan menggunakan `0.0.0.0` sebagai` hostIP` dan `TCP` sebagai default` protokol`. - Jika kamu hanya perlu akses ke port untuk keperluan debugging, Anda bisa menggunakan [apiserver proxy](/docs/tasks/access-application-cluster/access-cluster/#manually-constructing-apiserver-proxy-urls) atau [`kubectl port-forward`](/docs/tasks/access-application-cluster/port-forward-access-application-cluster/). + Jika kamu hanya perlu akses ke port untuk keperluan debugging, Anda bisa menggunakan [apiserver proxy](/id/docs/tasks/access-application-cluster/access-cluster/#manually-constructing-apiserver-proxy-urls) atau [`kubectl port-forward`](/id/docs/tasks/access-application-cluster/port-forward-access-application-cluster/). - Jika Anda secara eksplisit perlu mengekspos port Pod pada node, pertimbangkan untuk menggunakan [NodePort](/docs/concepts/services-networking/service/#nodeport) Service sebelum beralih ke `hostPort`. + Jika Anda secara eksplisit perlu mengekspos port Pod pada node, pertimbangkan untuk menggunakan [NodePort](/id/docs/concepts/services-networking/service/#nodeport) Service sebelum beralih ke `hostPort`. - Hindari menggunakan `hostNetwork`, untuk alasan yang sama seperti` hostPort`. -- Gunakan [headless Services](/docs/concepts/services-networking/service/#headless- +- Gunakan [headless Services](/id/docs/concepts/services-networking/service/#headless- services) (yang memiliki `ClusterIP` dari` None`) untuk Service discovery yang mudah ketika Anda tidak membutuhkan `kube-proxy` load balancing. ## Menggunakan label -- Deklarasi dan gunakan [labels] (/docs/concepts/overview/working-with-objects/labels/) untuk identifikasi __semantic attributes__ aplikasi atau Deployment kamu, seperti `{ app: myapp, tier: frontend, phase: test, deployment: v3 }`. Kamu dapat menggunakan label ini untuk memilih Pod yang sesuai untuk sumber daya lainnya; misalnya, Service yang memilih semua `tier: frontend` Pods, atau semua komponen` phase: test` dari `app: myapp`. Lihat [guestbook](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/guestbook/) aplikasi untuk contoh-contoh pendekatan ini. +- Deklarasi dan gunakan [labels] (/id/docs/concepts/overview/working-with-objects/labels/) untuk identifikasi __semantic attributes__ aplikasi atau Deployment kamu, seperti `{ app: myapp, tier: frontend, phase: test, deployment: v3 }`. Kamu dapat menggunakan label ini untuk memilih Pod yang sesuai untuk sumber daya lainnya; misalnya, Service yang memilih semua `tier: frontend` Pods, atau semua komponen` phase: test` dari `app: myapp`. Lihat [guestbook](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/guestbook/) aplikasi untuk contoh-contoh pendekatan ini. -Service dapat dibuat untuk menjangkau beberapa Penyebaran dengan menghilangkan label khusus rilis dari pemilihnya. [Deployments](/docs/concepts/workloads/controllers/deployment/) membuatnya mudah untuk memperbarui Service yang sedang berjalan tanpa downtime. +Service dapat dibuat untuk menjangkau beberapa Penyebaran dengan menghilangkan label khusus rilis dari pemilihnya. [Deployments](/id/docs/concepts/workloads/controllers/deployment/) membuatnya mudah untuk memperbarui Service yang sedang berjalan tanpa downtime. Keadaan objek yang diinginkan dideskripsikan oleh Deployment, dan jika perubahan terhadap spesifikasi tersebut adalah _applied_, Deployment controller mengubah keadaan aktual ke keadaan yang diinginkan pada tingkat yang terkontrol. @@ -75,7 +75,7 @@ Keadaan objek yang diinginkan dideskripsikan oleh Deployment, dan jika perubahan ## Container Images -Ini [imagePullPolicy](/docs/concepts/containers/images/#updating-images) dan tag dari image mempengaruhi ketika [kubelet](/docs/admin/kubelet/) mencoba menarik image yang ditentukan +Ini [imagePullPolicy](/id/docs/concepts/containers/images/#updating-images) dan tag dari image mempengaruhi ketika [kubelet](/docs/admin/kubelet/) mencoba menarik image yang ditentukan - `imagePullPolicy: IfNotPresent`: image ditarik hanya jika belum ada secara lokal. @@ -105,7 +105,7 @@ Semantik caching dari penyedia gambar yang mendasarinya membuat bahkan `imagePul - Gunakan `kubectl apply -f <directory>`. Ini mencari konfigurasi Kubernetes di semua file `.yaml`,` .yml`, dan `.json` di` <directory> `dan meneruskannya ke` apply`. -- Gunakan label selector untuk operasi `get` dan` delete` alih-alih nama objek tertentu. Lihat bagian di [label selectors](/docs/concepts/overview/working-with-objects/labels/#label-selectors) dan [using labels effectively](/docs/concepts/cluster-administration/manage-deployment/#using-labels-effectively). +- Gunakan label selector untuk operasi `get` dan` delete` alih-alih nama objek tertentu. Lihat bagian di [label selectors](/id/docs/concepts/overview/working-with-objects/labels/#label-selectors) dan [using labels effectively](/id/docs/concepts/cluster-administration/manage-deployment/#using-labels-effectively). - Gunakan `kubectl run` dan` kubectl expose` untuk dengan cepat membuat Deployment dan Service single-container. Lihat [Use a Service to Access an Application in a Cluster](/docs/tasks/access-application-cluster/service-access-application-cluster/) untuk Contoh. diff --git a/content/id/docs/concepts/configuration/pod-overhead.md b/content/id/docs/concepts/configuration/pod-overhead.md index e59301bb96..13db4e32f8 100644 --- a/content/id/docs/concepts/configuration/pod-overhead.md +++ b/content/id/docs/concepts/configuration/pod-overhead.md @@ -22,7 +22,7 @@ _Pod Overhead_ adalah fitur yang berfungsi untuk menghitung sumber daya digunaka Pada Kubernetes, Overhead Pod ditentukan pada [saat admisi](/docs/reference/access-authn-authz/extensible-admission-controllers/#what-are-admission-webhooks) sesuai dengan Overhead yang ditentukan di dalam -[RuntimeClass](/docs/concepts/containers/runtime-class/) milik Pod. +[RuntimeClass](/id/docs/concepts/containers/runtime-class/) milik Pod. Ketika Overhead Pod diaktifkan, Overhead akan dipertimbangkan sebagai tambahan terhadap jumlah permintaan sumber daya Container saat menjadwalkan Pod. Begitu pula Kubelet, yang akan memasukkan Overhead Pod saat menentukan ukuran @@ -49,7 +49,7 @@ Lihat [Ringkasan Otorisasi](/docs/reference/access-authn-authz/authorization/) u ## {{% heading "whatsnext" %}} -* [RuntimeClass](/docs/concepts/containers/runtime-class/) +* [RuntimeClass](/id/docs/concepts/containers/runtime-class/) * [Desain PodOverhead](https://github.com/kubernetes/enhancements/blob/master/keps/sig-node/20190226-pod-overhead.md) diff --git a/content/id/docs/concepts/configuration/pod-priority-preemption.md b/content/id/docs/concepts/configuration/pod-priority-preemption.md index a0c6035482..7350470fa3 100644 --- a/content/id/docs/concepts/configuration/pod-priority-preemption.md +++ b/content/id/docs/concepts/configuration/pod-priority-preemption.md @@ -24,7 +24,7 @@ Versi Kubernetes | Keadaan Priority and Pemindahan | Dihidupkan secara Bawaan 1.11 | beta | ya 1.14 | stable | ya -{{< warning >}}Pada sebuah klaster di mana tidak semua pengguna dipercaya, seorang pengguna yang berniat jahat dapat membuat Pod-pod dengan prioritas paling tinggi, membuat Pod-pod lainnya dipindahkan/tidak dapat dijadwalkan. Untuk mengatasi masalah ini, [ResourceQuota](/docs/concepts/policy/resource-quotas/) ditambahkan untuk mendukung prioritas Pod. Seorang admin dapat membuat ResourceQuota untuk pengguna-pengguna pada tingkat prioritas tertentu, mencegah mereka untuk membuat Pod-pod pada prioritas tinggi. Fitur ini telah beta sejak Kubernetes 1.12. +{{< warning >}}Pada sebuah klaster di mana tidak semua pengguna dipercaya, seorang pengguna yang berniat jahat dapat membuat Pod-pod dengan prioritas paling tinggi, membuat Pod-pod lainnya dipindahkan/tidak dapat dijadwalkan. Untuk mengatasi masalah ini, [ResourceQuota](/id/docs/concepts/policy/resource-quotas/) ditambahkan untuk mendukung prioritas Pod. Seorang admin dapat membuat ResourceQuota untuk pengguna-pengguna pada tingkat prioritas tertentu, mencegah mereka untuk membuat Pod-pod pada prioritas tinggi. Fitur ini telah beta sejak Kubernetes 1.12. {{< /warning >}} @@ -178,11 +178,11 @@ Harap catat bahwa Pod P tidak harus dijadwalkan pada "_nominated_ Node" (Node ya #### Penghentian secara sopan dari korban-korban pemindahan Pod -Saat Pod-pod dipindahkan, korban-korbannya mendapatkan [periode penghentian secara sopan](/docs/concepts/workloads/pods/pod/#penghentian-pod). Mereka memiliki waktu sebanyak itu untuk menyelesaikan pekerjaan merekan dan berhenti. Jika mereka tidak menyelesaikannya sebelum waktu tersebut, mereka akan dihentikan secara paksa. Periode penghentian secara sopan ini membuat sebuah jarak waktu antara saat di mana Scheduler memindahkan Pod-pod dengan waktu saat Pod yang tertunda tersebut (P) dapat dijadwalkan pada Node tersebut (N). Sementara itu, Scheduler akan terus menjadwalkan Pod-pod lain yang tertunda. Oleh karena itu, biasanya ada jarak waktu antara titik di mana Scheduler memindahkan korban-korban dan titik saat Pod P dijadwalkan. Untuk meminimalkan jarak waktu ini, kamu dapat menyetel periode penghentian secara sopan dari Pod-pod dengan prioritas lebih rendah menjadi nol atau sebuah angka yang kecil. +Saat Pod-pod dipindahkan, korban-korbannya mendapatkan [periode penghentian secara sopan](/id/docs/concepts/workloads/pods/pod/#penghentian-pod). Mereka memiliki waktu sebanyak itu untuk menyelesaikan pekerjaan merekan dan berhenti. Jika mereka tidak menyelesaikannya sebelum waktu tersebut, mereka akan dihentikan secara paksa. Periode penghentian secara sopan ini membuat sebuah jarak waktu antara saat di mana Scheduler memindahkan Pod-pod dengan waktu saat Pod yang tertunda tersebut (P) dapat dijadwalkan pada Node tersebut (N). Sementara itu, Scheduler akan terus menjadwalkan Pod-pod lain yang tertunda. Oleh karena itu, biasanya ada jarak waktu antara titik di mana Scheduler memindahkan korban-korban dan titik saat Pod P dijadwalkan. Untuk meminimalkan jarak waktu ini, kamu dapat menyetel periode penghentian secara sopan dari Pod-pod dengan prioritas lebih rendah menjadi nol atau sebuah angka yang kecil. #### PodDisruptionBudget didukung, tapi tidak dijamin! -Sebuah [Pod Disruption Budget (PDB)](/docs/concepts/workloads/pods/disruptions/) memungkinkan pemilik-pemilik aplikasi untuk membatasi jumlah Pod-pod dari sebuah aplikasi yang direplikasi yang mati secara bersamaan dikarenakan disrupsi yang disengaja. Kubernetes 1.9 mendukung PDB saat memindahkan Pod-pod, tetapi penghormatan terhadap PDB ini bersifat "usaha terbaik" (_best-effort_). Scheduler akan mencoba mencari korban-korban yang PDB-nya tidak dilanggar oleh pemindahan, tetapi jika tidak ada korban yang ditemukan, pemindahan akan tetap terjadi, dan Pod-pod dengan prioritas lebih rendah akan dihapus/dipindahkan meskipun PDB mereka dilanggar. +Sebuah [Pod Disruption Budget (PDB)](/id/docs/concepts/workloads/pods/disruptions/) memungkinkan pemilik-pemilik aplikasi untuk membatasi jumlah Pod-pod dari sebuah aplikasi yang direplikasi yang mati secara bersamaan dikarenakan disrupsi yang disengaja. Kubernetes 1.9 mendukung PDB saat memindahkan Pod-pod, tetapi penghormatan terhadap PDB ini bersifat "usaha terbaik" (_best-effort_). Scheduler akan mencoba mencari korban-korban yang PDB-nya tidak dilanggar oleh pemindahan, tetapi jika tidak ada korban yang ditemukan, pemindahan akan tetap terjadi, dan Pod-pod dengan prioritas lebih rendah akan dihapus/dipindahkan meskipun PDB mereka dilanggar. #### Afinitas antar-Pod pada Pod-pod dengan prioritas lebih rendah diff --git a/content/id/docs/concepts/configuration/secret.md b/content/id/docs/concepts/configuration/secret.md index a6ca8dca88..40875648ff 100644 --- a/content/id/docs/concepts/configuration/secret.md +++ b/content/id/docs/concepts/configuration/secret.md @@ -49,7 +49,7 @@ Mekanisme otomatisasi pembuatan secret dan penggunaan kredensial API dapat di no atau di-_override_ jika kamu menginginkannya. Meskipun begitu, jika apa yang kamu butuhkan hanyalah mengakses apiserver secara aman, maka mekanisme _default_ inilah yang disarankan. -Baca lebih lanjut dokumentasi [_Service Account_](/docs/tasks/configure-pod-container/configure-service-account/) +Baca lebih lanjut dokumentasi [_Service Account_](/id/docs/tasks/configure-pod-container/configure-service-account/) untuk informasi lebih lanjut mengenai bagaimana cara kerja _Service Account_. ### Membuat Objek Secret Kamu Sendiri @@ -569,7 +569,7 @@ _delay_ propagasi _cache_, dimana _delay_ propagasi _cache_ bergantung pada jeni {{< note >}} Sebuah container menggunakan Secret sebagai -[subPath](/docs/concepts/storage/volumes#using-subpath) dari _volume_ +[subPath](/id/docs/concepts/storage/volumes#using-subpath) dari _volume_ yang di-_mount_ tidak akan menerima perubahan Secret. {{< /note >}} @@ -636,7 +636,7 @@ pada Kubelet, sehingga Kubelet dapat mengunduh _image_ dan menempatkannya pada P **Memberikan spesifikasi manual dari sebuah imagePullSecret** -Penggunaan imagePullSecrets dideskripsikan di dalam [dokumentasi _image_](/docs/concepts/containers/images/#specifying-imagepullsecrets-on-a-pod) +Penggunaan imagePullSecrets dideskripsikan di dalam [dokumentasi _image_](/id/docs/concepts/containers/images/#specifying-imagepullsecrets-on-a-pod) ### Mekanisme yang Dapat Diterapkan agar imagePullSecrets dapat Secara Otomatis Digunakan @@ -644,7 +644,7 @@ Kamu dapat secara manual membuat sebuah imagePullSecret, serta merujuk imagePull yang sudah kamu buat dari sebuah serviceAccount. Semua Pod yang dibuat dengan menggunakan serviceAccount tadi atau serviceAccount _default_ akan menerima _field_ imagePullSecret dari serviceAccount yang digunakan. -Bacalah [Cara menambahkan ImagePullSecrets pada sebuah _service account_](/docs/tasks/configure-pod-container/configure-service-account/#add-imagepullsecrets-to-a-service-account) +Bacalah [Cara menambahkan ImagePullSecrets pada sebuah _service account_](/id/docs/tasks/configure-pod-container/configure-service-account/#add-imagepullsecrets-to-a-service-account) untuk informasi lebih detail soal proses yang dijalankan. ### Mekanisme _Mounting_ Otomatis dari Secret yang Sudah Dibuat @@ -985,7 +985,7 @@ hanya boleh dimiliki oleh komponen pada sistem level yang paling _previleged_. Aplikasi yang membutuhkan akses ke API secret harus melakukan _request_ `get` pada secret yang dibutuhkan. Hal ini memungkinkan administrator untuk membatasi -akses pada semua secret dengan tetap memberikan [akses pada instans secret tertentu](/docs/reference/access-authn-authz/rbac/#referring-to-resources) +akses pada semua secret dengan tetap memberikan [akses pada instans secret tertentu](/id/docs/reference/access-authn-authz/rbac/#referring-to-resources) yang dibutuhkan aplikasi. Untuk meningkatkan performa dengan menggunakan iterasi `get`, klien dapat mendesain diff --git a/content/id/docs/concepts/configuration/taint-and-toleration.md b/content/id/docs/concepts/configuration/taint-and-toleration.md index 9a30b48f5b..723bbd1c9c 100644 --- a/content/id/docs/concepts/configuration/taint-and-toleration.md +++ b/content/id/docs/concepts/configuration/taint-and-toleration.md @@ -6,7 +6,7 @@ weight: 40 <!-- overview --> -Afinitas Node, seperti yang dideskripsikan [di sini](/docs/concepts/configuration/assign-pod-node/#node-affinity-beta-feature), +Afinitas Node, seperti yang dideskripsikan [di sini](/id/docs/concepts/configuration/assign-pod-node/#node-affinity-beta-feature), adalah salah satu properti dari Pod yang menyebabkan pod tersebut memiliki preferensi untuk ditempatkan di sekelompok Node tertentu (preferensi ini dapat berupa _soft constraints_ atau _hard constraints_ yang harus dipenuhi). _Taint_ merupakan kebalikan dari afinitas -- @@ -193,7 +193,7 @@ khusus (misalnya, `kubectl taint nodes nodename special=true:NoSchedule` atau yang sesuai pada _pod_ yang menggunakan _node_ dengan perangkat keras khusus. Seperti halnya pada kebutuhan _dedicated_ _node_, hal ini dapat dilakukan dengan mudah dengan cara menulis [_admission controller_](/docs/reference/access-authn-authz/admission-controllers/) yang -bersifat khusus. Misalnya, kita dapat menggunakan [_Extended Resource_](/docs/concepts/configuration/manage-compute-resources-container/#extended-resources) +bersifat khusus. Misalnya, kita dapat menggunakan [_Extended Resource_](/id/docs/concepts/configuration/manage-compute-resources-container/#extended-resources) untuk merepresentasikan perangkat keras khusus, kemudian _taint_ _node_ dengan perangkat keras khusus dengan nama _extended resource_ dan jalankan _admission controller_ [ExtendedResourceToleration](/docs/reference/access-authn-authz/admission-controllers/#extendedresourcetoleration). @@ -244,7 +244,7 @@ dan logika normal untuk melakukan _eviction_ pada _pod_ dari suatu _node_ terten dari _Ready_ yang ada pada _NodeCondition_ dinonaktifkan. {{< note >}} -Untuk menjaga perilaku [_rate limiting_](/docs/concepts/architecture/nodes/) yang +Untuk menjaga perilaku [_rate limiting_](/id/docs/concepts/architecture/nodes/) yang ada pada _eviction_ _pod_ apabila _node_ mengalami masalah, sistem sebenarnya menambahkan _taint_ dalam bentuk _rate limiter_. Hal ini mencegah _eviction_ besar-besaran pada _pod_ pada skenario dimana master menjadi terpisah dari _node_ lainnya. @@ -280,7 +280,7 @@ _node_ apabila salah satu masalah terdeteksi. Kedua _toleration_ _default_ tadi ditambahkan oleh [DefaultTolerationSeconds _admission controller_](https://git.k8s.io/kubernetes/plugin/pkg/admission/defaulttolerationseconds). -_Pod-pod_ pada [DaemonSet](/docs/concepts/workloads/controllers/daemonset/) dibuat dengan _toleration_ +_Pod-pod_ pada [DaemonSet](/id/docs/concepts/workloads/controllers/daemonset/) dibuat dengan _toleration_ `NoExecute` untuk _taint_ tanpa `tolerationSeconds`: * `node.kubernetes.io/unreachable` diff --git a/content/id/docs/concepts/containers/container-environment.md b/content/id/docs/concepts/containers/container-environment.md index affb371001..6c0ba354e8 100644 --- a/content/id/docs/concepts/containers/container-environment.md +++ b/content/id/docs/concepts/containers/container-environment.md @@ -17,7 +17,7 @@ Laman ini menjelaskan berbagai *resource* yang tersedia di dalam Kontainer pada *Environment* Kontainer pada Kubernetes menyediakan beberapa *resource* penting yang tersedia di dalam Kontainer: -* Sebuah *Filesystem*, yang merupakan kombinasi antara [image](/docs/concepts/containers/images/) dan satu atau banyak [*volumes*](/docs/concepts/storage/volumes/). +* Sebuah *Filesystem*, yang merupakan kombinasi antara [image](/id/docs/concepts/containers/images/) dan satu atau banyak [*volumes*](/id/docs/concepts/storage/volumes/). * Informasi tentang Kontainer tersebut. * Informasi tentang objek-objek lain di dalam klaster. @@ -53,7 +53,7 @@ jika [*addon* DNS](http://releases.k8s.io/{{< param "githubbranch" >}}/cluster/a ## {{% heading "whatsnext" %}} -* Pelajari lebih lanjut tentang [berbagai *hook* pada *lifecycle* Kontainer](/docs/concepts/containers/container-lifecycle-hooks/). +* Pelajari lebih lanjut tentang [berbagai *hook* pada *lifecycle* Kontainer](/id/docs/concepts/containers/container-lifecycle-hooks/). * Dapatkan pengalaman praktis soal [memberikan *handler* untuk *event* dari *lifecycle* Kontainer](/docs/tasks/configure-pod-container/attach-handler-lifecycle-event/). diff --git a/content/id/docs/concepts/containers/container-lifecycle-hooks.md b/content/id/docs/concepts/containers/container-lifecycle-hooks.md index a7b5164864..d45a5ad23e 100644 --- a/content/id/docs/concepts/containers/container-lifecycle-hooks.md +++ b/content/id/docs/concepts/containers/container-lifecycle-hooks.md @@ -40,7 +40,7 @@ Hal ini bersifat *blocking*, yang artinya panggilan bersifat sinkron (*synchrono untuk menghapus kontainer tersebut. Tidak ada parameter yang diberikan pada *handler*. -Penjelasan yang lebih rinci tentang proses terminasi dapat dilihat pada [Terminasi Pod](/docs/concepts/workloads/pods/pod/#termination-of-pods). +Penjelasan yang lebih rinci tentang proses terminasi dapat dilihat pada [Terminasi Pod](/id/docs/concepts/workloads/pods/pod/#termination-of-pods). ### Implementasi *handler* untuk *hook* @@ -113,7 +113,7 @@ Events: ## {{% heading "whatsnext" %}} -* Pelajari lebih lanjut tentang [*environment* Kontainer](/docs/concepts/containers/container-environment-variables/). +* Pelajari lebih lanjut tentang [*environment* Kontainer](/id/docs/concepts/containers/container-environment-variables/). * Pelajari bagaimana caranya [melakukan *attach handler* pada *event lifecycle* sebuah Kontainer](/docs/tasks/configure-pod-container/attach-handler-lifecycle-event/). diff --git a/content/id/docs/concepts/containers/images.md b/content/id/docs/concepts/containers/images.md index 7a5fa28154..8fa81801ff 100644 --- a/content/id/docs/concepts/containers/images.md +++ b/content/id/docs/concepts/containers/images.md @@ -26,7 +26,7 @@ selalu diunduh, kamu bisa melakukan salah satu dari berikut: - buang `imagePullPolicy` dan juga _tag_ untuk _image_. - aktifkan [AlwaysPullImages](/docs/reference/access-authn-authz/admission-controllers/#alwayspullimages) _admission controller_. -Harap diingat kamu sebaiknya hindari penggunaan _tag_ `:latest`, lihat [panduan konfigurasi](/docs/concepts/configuration/overview/#container-images) untuk informasi lebih lanjut. +Harap diingat kamu sebaiknya hindari penggunaan _tag_ `:latest`, lihat [panduan konfigurasi](/id/docs/concepts/configuration/overview/#container-images) untuk informasi lebih lanjut. ## Membuat Image Multi-arsitektur dengan Manifest @@ -142,7 +142,7 @@ Setelah kamu membuat registri, kamu akan menggunakan kredensial berikut untuk lo * `DOCKER_EMAIL`: `${some-email-address}` Ketika kamu sudah memiliki variabel-variabel di atas, kamu dapat -[mengkonfigurasi sebuah Kubernetes Secret dan menggunakannya untuk _deploy_ sebuah Pod](/docs/concepts/containers/images/#specifying-imagepullsecrets-on-a-pod). +[mengkonfigurasi sebuah Kubernetes Secret dan menggunakannya untuk _deploy_ sebuah Pod](/id/docs/concepts/containers/images/#specifying-imagepullsecrets-on-a-pod). ### Menggunakan IBM Cloud Container Registry IBM Cloud Container Registry menyediakan sebuah registri _image_ privat yang _multi-tenant_, dapat kamu gunakan untuk menyimpan dan membagikan _image-image_ secara aman. Secara _default_, _image-image_ di dalam registri privat kamu akan dipindai (_scan_) oleh Vulnerability Advisor terintegrasi untuk deteksi isu @@ -291,7 +291,7 @@ kubectl create secret docker-registry <name> --docker-server=DOCKER_REGISTRY_SER Jika kamu sudah memiliki berkas kredensial Docker, daripada menggunakan perintah di atas, kamu dapat mengimpor berkas kredensial sebagai Kubernetes Secret. -[Membuat sebuah Secret berbasiskan pada kredensial Docker yang sudah ada](/docs/tasks/configure-pod-container/pull-image-private-registry/#registry-secret-existing-credentials) menjelaskan bagaimana mengatur ini. +[Membuat sebuah Secret berbasiskan pada kredensial Docker yang sudah ada](/id/docs/tasks/configure-pod-container/pull-image-private-registry/#registry-secret-existing-credentials) menjelaskan bagaimana mengatur ini. Cara ini berguna khususnya jika kamu menggunakan beberapa registri kontainer privat, perintah `kubectl create secret docker-registry` akan membuat sebuah Secret yang akan hanya bekerja menggunakan satu registri privat. @@ -331,7 +331,7 @@ Cara ini perlu untuk diselesaikan untuk setiap Pod yang mengguunakan registri pr Hanya saja, mengatur _field_ ini dapat diotomasi dengan mengatur imagePullSecrets di dalam sumber daya [serviceAccount](/docs/user-guide/service-accounts). -Periksa [Tambahan ImagePullSecrets untuk sebuah Service Account](/docs/tasks/configure-pod-container/configure-service-account/#add-imagepullsecrets-to-a-service-account) untuk instruksi yang lebih detail. +Periksa [Tambahan ImagePullSecrets untuk sebuah Service Account](/id/docs/tasks/configure-pod-container/configure-service-account/#add-imagepullsecrets-to-a-service-account) untuk instruksi yang lebih detail. Kamu dapat menggunakan cara ini bersama `.docker/config.json` pada setiap Node. Kredensial-kredensial akan dapat di-_merged_. Cara ini akan dapat bekerja pada Google Kubernetes Engine. diff --git a/content/id/docs/concepts/containers/overview.md b/content/id/docs/concepts/containers/overview.md index d31c760ee0..715230d14d 100644 --- a/content/id/docs/concepts/containers/overview.md +++ b/content/id/docs/concepts/containers/overview.md @@ -21,7 +21,7 @@ ini membuat penyebaran lebih mudah di lingkungan cloud atau OS yang berbeda. ## Image-Image Kontainer -[Kontainer image](/docs/concepts/containers/images/) meruapakan paket perangkat lunak +[Kontainer image](/id/docs/concepts/containers/images/) meruapakan paket perangkat lunak yang siap dijalankan, mengandung semua yang diperlukan untuk menjalankan sebuah aplikasi: kode dan setiap *runtime* yang dibutuhkan, *library* dari aplikasi dan sistem, dan nilai *default* untuk penganturan yang penting. diff --git a/content/id/docs/concepts/containers/runtime-class.md b/content/id/docs/concepts/containers/runtime-class.md index 31bd8a25ec..73252a03e4 100644 --- a/content/id/docs/concepts/containers/runtime-class.md +++ b/content/id/docs/concepts/containers/runtime-class.md @@ -45,7 +45,7 @@ soal bagaimana melakukan konfigurasi untuk implementasi CRI yang kamu miliki. Untuk saat ini, RuntimeClass berasumsi bahwa semua _node_ di dalam klaster punya konfigurasi yang sama (homogen). Jika ada _node_ yang punya konfigurasi berbeda dari yang lain (heterogen), maka perbedaan ini harus diatur secara independen di luar RuntimeClass -melalui fitur _scheduling_ (lihat [Menempatkan Pod pada Node](/docs/concepts/configuration/assign-pod-node/)). +melalui fitur _scheduling_ (lihat [Menempatkan Pod pada Node](/id/docs/concepts/configuration/assign-pod-node/)). {{< /note >}} Seluruh konfigurasi memiliki nama `handler` yang terkait, dijadikan referensi oleh RuntimeClass. @@ -91,7 +91,7 @@ spec: Kubelet akan mendapat instruksi untuk menggunakan RuntimeClass dengan nama yang sudah ditentukan tersebut untuk menjalankan Pod ini. Jika RuntimeClass dengan nama tersebut tidak ditemukan, atau CRI tidak dapat -menjalankan _handler_ yang terkait, maka Pod akan memasuki [tahap](/docs/concepts/workloads/pods/pod-lifecycle/#pod-phase) `Failed`. +menjalankan _handler_ yang terkait, maka Pod akan memasuki [tahap](/id/docs/concepts/workloads/pods/pod-lifecycle/#pod-phase) `Failed`. Lihat [_event_](/docs/tasks/debug-application-cluster/debug-application-introspection/) untuk mengetahui pesan error yang terkait. Jika tidak ada `runtimeClassName` yang ditentukan di dalam Pod, maka RuntimeHandler yang _default_ akan digunakan. diff --git a/content/id/docs/concepts/extend-kubernetes/api-extension/custom-resources.md b/content/id/docs/concepts/extend-kubernetes/api-extension/custom-resources.md index d8be642856..3a3ece65b0 100644 --- a/content/id/docs/concepts/extend-kubernetes/api-extension/custom-resources.md +++ b/content/id/docs/concepts/extend-kubernetes/api-extension/custom-resources.md @@ -14,7 +14,7 @@ _Custom Resource_ adalah ekstensi dari Kubernetes API. Laman ini mendiskusikan k ## _Custom Resource_ -Sebuah sumber daya adalah sebuah *endpoint* pada [Kubernetes API](/docs/reference/using-api/api-overview/) yang menyimpan sebuah koleksi [objek API](/docs/concepts/overview/working-with-objects/kubernetes-objects/) dari sebuah jenis tertentu. Sebagai contoh, sumber daya bawaan Pod mengandung sebuah koleksi objek-objek Pod. +Sebuah sumber daya adalah sebuah *endpoint* pada [Kubernetes API](/docs/reference/using-api/api-overview/) yang menyimpan sebuah koleksi [objek API](/id/docs/concepts/overview/working-with-objects/kubernetes-objects/) dari sebuah jenis tertentu. Sebagai contoh, sumber daya bawaan Pod mengandung sebuah koleksi objek-objek Pod. Sebuah _Custom Resource_ adalah sebuah ekstensi dari Kubernetes API yang tidak seharusnya tersedia pada pemasangan default Kubernetes. Namun, banyak fungsi-fungsi inti Kubernetes yang sekarang dibangun menggunakan _Custom Resource_, membuat Kubernetes lebih modular. @@ -25,7 +25,7 @@ dipasang, pengguna dapat membuat dan mengakses objek-objek _Custom Resource_ men Dengan sendirinya, _Custom Resource_ memungkinkan kamu untuk menyimpan dan mengambil data terstruktur. Ketika kamu menggabungkan sebuah _Custom Resource_ dengan _controller_ khusus, _Custom Resource_ akan memberikan sebuah API deklaratif yang sebenarnya. -Sebuah [API deklaratif](/docs/concepts/overview/working-with-objects/kubernetes-objects/#memahami-konsep-objek-objek-yang-ada-pada-kubernetes) +Sebuah [API deklaratif](/id/docs/concepts/overview/working-with-objects/kubernetes-objects/#memahami-konsep-objek-objek-yang-ada-pada-kubernetes) memungkinkan kamu untuk mendeklarasikan atau menspesifikasikan keadaan dari sumber daya kamu dan mencoba untuk menjaga agar keadaan saat itu tersinkronisasi dengan keadaan yang diinginkan. *Controller* menginterpretasikan data terstruktur sebagai sebuah rekaman dari keadaan yang diinginkan pengguna, dan secara kontinu menjaga keadaan ini. Kamu bisa men-_deploy_ dan memperbaharui sebuah _controller_ khusus pada sebuah klaster yang berjalan, secara independen dari siklus hidup klaster itu sendiri. _Controller_ khusus dapat berfungsi dengan sumber daya jenis apapun, tetapi mereka sangat efektif ketika dikombinasikan dengan _Custom Resource_. [_Operator pattern_](https://coreos.com/blog/introducing-operators.html) mengkombinasikan _Custom Resource_ dan _controller_ khusus. Kamu bisa menggunakan _controller_ khusus untuk menyandi pengetahuan domain untuk aplikasi spesifik menjadi sebuah ekstensi dari Kubernetes API. @@ -40,7 +40,7 @@ Ketika membuat sebuah API baru, pikirkan apakah kamu ingin [mengagregasikan API | Kamu mau tipe baru yang dapat dibaca dan ditulis dengan `kubectl`.| Dukungan `kubectl` tidak diperlukan | | Kamu mau melihat tipe baru pada sebuah Kubernetes UI, seperti dasbor, bersama dengan tipe-tipe bawaan. | Dukungan Kubernetes UI tidak diperlukan. | | Kamu mengembangkan sebuah API baru. | Kamu memiliki sebuah program yang melayani API kamu dan dapat berkerja dengan baik. | -| Kamu bersedia menerima pembatasan format yang Kubernetes terapkan pada jalur sumber daya API (Lihat [Ikhtisar API](/docs/concepts/overview/kubernetes-api/).) | Kamu perlu memiliki jalur REST spesifik agar menjadi cocok dengan REST API yang telah didefinisikan. | +| Kamu bersedia menerima pembatasan format yang Kubernetes terapkan pada jalur sumber daya API (Lihat [Ikhtisar API](/id/docs/concepts/overview/kubernetes-api/).) | Kamu perlu memiliki jalur REST spesifik agar menjadi cocok dengan REST API yang telah didefinisikan. | | Sumber daya kamu secara alami mencakup hingga sebuah klaster atau sebuah *namespace* dari sebuah klaster. | Sumber daya yang mencakup klaster atau *namespace* adalah sebuah ketidakcocokan; kamu perlu mengendalikan jalur sumber daya spesifik. | | Kamu ingin menggunakan kembali [dukungan fitur Kubernetes API](#fitur-umum). | Kamu tidak membutuhkan fitur tersebut. | @@ -77,7 +77,7 @@ Gunakan ConfigMap jika salah satu hal berikut berlaku: * Kamu ingin melakukan pembaharuan bergulir lewat Deployment, dll, ketika berkas diperbaharui. {{< note >}} -Gunakan sebuah [Secret](/docs/concepts/configuration/secret/) untuk data sensitif, yang serupa dengan ConfigMap tetapi lebih aman. +Gunakan sebuah [Secret](/id/docs/concepts/configuration/secret/) untuk data sensitif, yang serupa dengan ConfigMap tetapi lebih aman. {{< /note >}} Gunakan sebuah _Custom Resource_ (CRD atau _Aggregated API_) jika kebanyakan dari hal berikut berlaku: @@ -93,11 +93,11 @@ Gunakan sebuah _Custom Resource_ (CRD atau _Aggregated API_) jika kebanyakan dar Kubernetes menyediakan dua cara untuk menambahkan sumber daya ke klaster kamu: - CRD cukup sederhana dan bisa diciptakan tanpa pemrograman apapun. -- [Agregasi API](/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation/) membutuhkan pemrograman, tetapi memungkinkan kendali lebih terhadap perilaku API seperti bagaimana data disimpan dan perubahan antar versi API. +- [Agregasi API](/id/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation/) membutuhkan pemrograman, tetapi memungkinkan kendali lebih terhadap perilaku API seperti bagaimana data disimpan dan perubahan antar versi API. Kubernetes menyediakan kedua opsi tersebut untuk memenuhi kebutuhan pengguna berbeda, jadi tidak ada kemudahan penggunaan atau fleksibilitas yang dikompromikan. -_Aggregated API_ adalah bawahan dari APIServer yang duduk dibelakang API server utama, yang bertindak sebagai sebuah _proxy_. Pengaturan ini disebut [Agregasi API](/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation/) (AA). Untuk pengguna, yang terlihat adalah Kubernetes API yang diperluas. +_Aggregated API_ adalah bawahan dari APIServer yang duduk dibelakang API server utama, yang bertindak sebagai sebuah _proxy_. Pengaturan ini disebut [Agregasi API](/id/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation/) (AA). Untuk pengguna, yang terlihat adalah Kubernetes API yang diperluas. CRD memungkinkan pengguna untuk membuat tipe baru sumber daya tanpa menambahkan APIserver lain. Kamu tidak perlu mengerti Agregasi API untuk menggunakan CRD. @@ -115,7 +115,7 @@ Lihat [contoh *controller* khusus](https://github.com/kubernetes/sample-controll Biasanya, tiap sumber daya di API Kubernetes membutuhkan kode yang menangani permintaan REST dan mengatur peyimpanan tetap dari objek-objek. Server Kubernetes API utama menangani sumber daya bawaan seperti Pod dan Service, dan juga menangani _Custom Resource_ dalam sebuah cara yang umum melalui [CRD](#customresourcedefinition). -[Lapisan agregasi](/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation/) memungkinkan kamu untuk menyediakan implementasi khusus untuk _Custom Resource_ dengan menulis dan men-_deploy_ API server kamu yang berdiri sendiri. API server utama menlimpahkan permintaan kepada kamu untuk _Custom Resource_ yang kamu tangani, membuat mereka tersedia untuk semua kliennya. +[Lapisan agregasi](/id/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation/) memungkinkan kamu untuk menyediakan implementasi khusus untuk _Custom Resource_ dengan menulis dan men-_deploy_ API server kamu yang berdiri sendiri. API server utama menlimpahkan permintaan kepada kamu untuk _Custom Resource_ yang kamu tangani, membuat mereka tersedia untuk semua kliennya. ## Memilih sebuah metode untuk menambahkan _Custom Resource_ @@ -216,7 +216,7 @@ Ketika kamu menambahkan sebuah _Custom Resource_, kamu dapat mengaksesnya dengan ## {{% heading "whatsnext" %}} -* Belajar bagaimana untuk [Memperluas Kubernetes API dengan lapisan agregasi](/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation/). +* Belajar bagaimana untuk [Memperluas Kubernetes API dengan lapisan agregasi](/id/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation/). * Belajar bagaimana untuk [Memperluas Kubernetes API dengan CustomResourceDefinition](/docs/tasks/access-kubernetes-api/custom-resources/custom-resource-definitions/). diff --git a/content/id/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins.md b/content/id/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins.md index 014a40171e..62f7c8d41d 100644 --- a/content/id/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins.md +++ b/content/id/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins.md @@ -37,7 +37,7 @@ Dalam pendaftaran, _plugin_ perangkat perlu mengirim: * Nama Unix socket-nya. * Versi API Plugin Perangkat yang dipakai. * `ResourceName` yang ingin ditunjukkan. `ResourceName` ini harus mengikuti - [skema penamaan sumber daya ekstensi](/docs/concepts/configuration/manage-compute-resources-container/#extended-resources) + [skema penamaan sumber daya ekstensi](/id/docs/concepts/configuration/manage-compute-resources-container/#extended-resources) sebagai `vendor-domain/tipe-sumber-daya`. (Contohnya, NVIDIA GPU akan dinamai `nvidia.com/gpu`.) @@ -221,7 +221,7 @@ Berikut beberapa contoh implementasi _plugin_ perangkat: * [Plugin perangkat RDMA](https://github.com/hustcat/k8s-rdma-device-plugin) * [Plugin perangkat Solarflare](https://github.com/vikaschoudhary16/sfc-device-plugin) * [Plugin perangkat SR-IOV Network](https://github.com/intel/sriov-network-device-plugin) -* [Plugin perangkat Xilinx FPGA](https://github.com/Xilinx/FPGA_as_a_Service/tree/master/k8s-fpga-device-plugin/trunk) untuk perangkat Xilinx FPGA +* [Plugin perangkat Xilinx FPGA](https://github.com/Xilinx/FPGA_as_a_Service/tree/master/k8s-fpga-device-plugin) untuk perangkat Xilinx FPGA ## {{% heading "whatsnext" %}} diff --git a/content/id/docs/concepts/extend-kubernetes/extend-cluster.md b/content/id/docs/concepts/extend-kubernetes/extend-cluster.md index b7b07b46ff..9d80881724 100644 --- a/content/id/docs/concepts/extend-kubernetes/extend-cluster.md +++ b/content/id/docs/concepts/extend-kubernetes/extend-cluster.md @@ -36,7 +36,7 @@ _Flag-flag_ dan _berkas-berkas konfigurasi_ didokumentasikan di bagian Referensi _Flag-flag_ dan berkas-berkas konfigurasi mungkin tidak selalu dapat diubah pada layanan Kubernetes yang _hosted_ atau pada distribusi dengan instalasi yang dikelola. Ketika mereka dapat diubah, mereka biasanya hanya dapat diubah oleh Administrator Klaster. Dan juga, mereka dapat sewaktu-waktu diubah dalam versi Kubernetes di masa depan, dan menyetel mereka mungkin memerlukan proses pengulangan kembali. Oleh karena itu, mereka harus digunakan hanya ketika tidak ada pilihan lain. -*API kebijakan bawaan*, seperti [ResourceQuota](/docs/concepts/policy/resource-quotas/), [PodSecurityPolicy](/docs/concepts/policy/pod-security-policy/), [NetworkPolicy](/docs/concepts/services-networking/network-policies/) dan Role-based Access Control ([RBAC](/docs/reference/access-authn-authz/rbac/)), adalah API bawaan Kubernetes. API biasanya digunakan oleh layanan Kubernetes yang _hosted_ dan diatur oleh instalasi Kubernetes. Mereka bersifat deklaratif dan menggunakan konvensi yang sama dengan sumber daya Kubernetes lainnya seperti pod-pod, jadi konfigurasi klaster baru dapat diulang-ulang dan dapat diatur dengan cara yang sama dengan aplikasi. Dan, ketika mereka stabil, mereka mendapatkan keuntungan dari [kebijakan pendukung yang jelas](/docs/reference/deprecation-policy/) seperti API Kubernetes lainnya. Oleh karena itu, mereka lebih disukai daripada _berkas konfigurasi_ dan _flag-flag_ saat mereka cocok dengan situasi yang dibutuhkan. +*API kebijakan bawaan*, seperti [ResourceQuota](/id/docs/concepts/policy/resource-quotas/), [PodSecurityPolicy](/id/docs/concepts/policy/pod-security-policy/), [NetworkPolicy](/id/docs/concepts/services-networking/network-policies/) dan Role-based Access Control ([RBAC](/id/docs/reference/access-authn-authz/rbac/)), adalah API bawaan Kubernetes. API biasanya digunakan oleh layanan Kubernetes yang _hosted_ dan diatur oleh instalasi Kubernetes. Mereka bersifat deklaratif dan menggunakan konvensi yang sama dengan sumber daya Kubernetes lainnya seperti pod-pod, jadi konfigurasi klaster baru dapat diulang-ulang dan dapat diatur dengan cara yang sama dengan aplikasi. Dan, ketika mereka stabil, mereka mendapatkan keuntungan dari [kebijakan pendukung yang jelas](/docs/reference/deprecation-policy/) seperti API Kubernetes lainnya. Oleh karena itu, mereka lebih disukai daripada _berkas konfigurasi_ dan _flag-flag_ saat mereka cocok dengan situasi yang dibutuhkan. ## Perluasan @@ -107,7 +107,7 @@ Untuk lebih jelasnya tentang Sumber Daya _Custom_, lihat [Panduan Konsep Sumber ### Menggabungkan API Baru dengan Otomasi -Kombinasi antara sebuah API sumber daya _custom_ dan _loop_ kontrol disebut [Pola Operator](/docs/concepts/extend-kubernetes/operator/). Pola Operator digunakan untuk mengelola aplikasi yang spesifik dan biasanya _stateful_. API-API _custom_ dan _loop_ kontrol ini dapat digunakan untuk mengatur sumber daya lainnya, seperti penyimpanan dan kebijakan-kebijakan. +Kombinasi antara sebuah API sumber daya _custom_ dan _loop_ kontrol disebut [Pola Operator](/id/docs/concepts/extend-kubernetes/operator/). Pola Operator digunakan untuk mengelola aplikasi yang spesifik dan biasanya _stateful_. API-API _custom_ dan _loop_ kontrol ini dapat digunakan untuk mengatur sumber daya lainnya, seperti penyimpanan dan kebijakan-kebijakan. ### Mengubah Sumber Daya Bawaan @@ -173,6 +173,6 @@ Penjadwal juga mendukung [_webhook_](https://github.com/kubernetes/community/blo * [_Plugin_ Jaringan](/docs/concepts/cluster-administration/network-plugins/) * [_Plugin_ Perangkat](/docs/concepts/cluster-administration/device-plugins/) * Pelajari tentang [_Plugin_ kubectl](/docs/tasks/extend-kubectl/kubectl-plugins/) -* Pelajari tentang [Pola Operator](/docs/concepts/extend-kubernetes/operator/) +* Pelajari tentang [Pola Operator](/id/docs/concepts/extend-kubernetes/operator/) diff --git a/content/id/docs/concepts/extend-kubernetes/operator.md b/content/id/docs/concepts/extend-kubernetes/operator.md index 02df63bb79..315ae35e3d 100644 --- a/content/id/docs/concepts/extend-kubernetes/operator.md +++ b/content/id/docs/concepts/extend-kubernetes/operator.md @@ -7,7 +7,7 @@ weight: 30 <!-- overview --> Operator adalah ekstensi perangkat lunak untuk Kubernetes yang memanfaatkan -[_custom resource_](/docs/concepts/extend-kubernetes/api-extension/custom-resources/) +[_custom resource_](/id/docs/concepts/extend-kubernetes/api-extension/custom-resources/) untuk mengelola aplikasi dan komponen-komponennya. Operator mengikuti prinsip Kubernetes, khususnya dalam hal [_control loop_](/docs/concepts/#kubernetes-control-plane). @@ -124,11 +124,9 @@ Kamu juga dapat mengimplementasikan Operator (yaitu, _Controller_) dengan menggunakan bahasa / _runtime_ yang dapat bertindak sebagai [klien dari API Kubernetes](/docs/reference/using-api/client-libraries/). +## {{% heading "whatsnext" %}} - -{{% capture Selanjutnya %}} - -* Memahami lebih lanjut tentang [_custome resources_](/docs/concepts/extend-kubernetes/api-extension/custom-resources/) +* Memahami lebih lanjut tentang [_custome resources_](/id/docs/concepts/extend-kubernetes/api-extension/custom-resources/) * Temukan "ready-made" _operators_ dalam [OperatorHub.io](https://operatorhub.io/) untuk memenuhi use case kamu * Menggunakan perangkat yang ada untuk menulis Operator kamu sendiri, misalnya: diff --git a/content/id/docs/concepts/extend-kubernetes/service-catalog.md b/content/id/docs/concepts/extend-kubernetes/service-catalog.md index efea4eda97..cd63a89355 100644 --- a/content/id/docs/concepts/extend-kubernetes/service-catalog.md +++ b/content/id/docs/concepts/extend-kubernetes/service-catalog.md @@ -46,7 +46,7 @@ untuk berkomunikasi dengan makelar servis, bertindak sebagai perantara untuk API merundingkan penyediaan awal dan mengambil kredensial untuk aplikasi bisa menggunakan servis terkelola tersebut. Ini terimplementasi sebagai ekstensi API Server dan pengontrol, menggunakan etcd sebagai media penyimpanan. -Ini juga menggunakan [lapisan agregasi](/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation/) +Ini juga menggunakan [lapisan agregasi](/id/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation/) yang tersedia pada Kubernetes versi 1.7+ untuk menampilkan API-nya. <br> diff --git a/content/id/docs/concepts/overview/components.md b/content/id/docs/concepts/overview/components.md index 63e7b4b3af..aa2ee52152 100644 --- a/content/id/docs/concepts/overview/components.md +++ b/content/id/docs/concepts/overview/components.md @@ -120,7 +120,7 @@ Meskipun tidak semua <i>addons</i> dibutuhkan, semua klaster Kubernetes hendakny memiliki DNS klaster. Komponen ini penting karena banyak dibutuhkan oleh komponen lainnya. -[Klaster DNS](/docs/concepts/cluster-administration/addons/) adalah server DNS, selain beberapa server DNS lain yang sudah ada di +[Klaster DNS](/id/docs/concepts/cluster-administration/addons/) adalah server DNS, selain beberapa server DNS lain yang sudah ada di <i>environment</i> kamu, yang berfungsi sebagai catatan DNS bagi Kubernetes <i>services</i> Kontainer yang dimulai oleh kubernetes secara otomatis akan memasukkan server DNS ini @@ -129,7 +129,7 @@ ke dalam mekanisme pencarian DNS yang dimilikinya. ### <i>Web UI</i> (Dasbor) -[Dasbor](/docs/tasks/access-application-cluster/web-ui-dashboard/) adalah antar muka berbasis web multifungsi yang ada pada klaster Kubernetes. +[Dasbor](/id/docs/tasks/access-application-cluster/web-ui-dashboard/) adalah antar muka berbasis web multifungsi yang ada pada klaster Kubernetes. Dasbor ini memungkinkan user melakukan manajemen dan <i>troubleshooting</i> klaster maupun aplikasi yang ada pada klaster itu sendiri. @@ -143,7 +143,7 @@ untuk melakukan pencarian data yang dibutuhkan. ### <i>Cluster-level Logging</i> -[Cluster-level logging](/docs/concepts/cluster-administration/logging/) bertanggung jawab mencatat <i>log</i> kontainer pada +[Cluster-level logging](/id/docs/concepts/cluster-administration/logging/) bertanggung jawab mencatat <i>log</i> kontainer pada penyimpanan <i>log</i> terpusat dengan antar muka yang dapat digunakan untuk melakukan pencarian. diff --git a/content/id/docs/concepts/overview/object-management-kubectl/declarative-config.md b/content/id/docs/concepts/overview/object-management-kubectl/declarative-config.md index 9599feaf24..46066769d4 100644 --- a/content/id/docs/concepts/overview/object-management-kubectl/declarative-config.md +++ b/content/id/docs/concepts/overview/object-management-kubectl/declarative-config.md @@ -25,8 +25,8 @@ Lihat [Pengelolaan Objek Kubernetes](/docs/concepts/overview/object-management-k Konfigurasi objek secara deklaratif membutuhkan pemahaman yang baik tentang definisi dan konfigurasi objek-objek Kubernetes. Jika belum pernah, kamu disarankan untuk membaca terlebih dulu dokumen-dokumen berikut: -- [Pengelolaan Objek Kubernetes Menggunakan Perintah Imperatif](/docs/concepts/overview/object-management-kubectl/imperative-command/) -- [Pengelolaan Objek Kubernetes Menggunakan File Konfigurasi Imperatif](/docs/concepts/overview/object-management-kubectl/imperative-config/) +- [Pengelolaan Objek Kubernetes Menggunakan Perintah Imperatif](/id/docs/concepts/overview/object-management-kubectl/imperative-command/) +- [Pengelolaan Objek Kubernetes Menggunakan File Konfigurasi Imperatif](/id/docs/concepts/overview/object-management-kubectl/imperative-config/) Berikut adalah beberapa defnisi dari istilah-istilah yang digunakan dalam dokumen ini: @@ -862,8 +862,8 @@ template: ## {{% heading "whatsnext" %}} -- [Pengelolaan Objek Kubernetes Menggunakan Perintah Imperatif](/docs/concepts/overview/object-management-kubectl/imperative-command/) -- [Pengelolaan Objek Kubernetes secara Imperatif Menggunakan File Konfigurasi](/docs/concepts/overview/object-management-kubectl/imperative-config/) +- [Pengelolaan Objek Kubernetes Menggunakan Perintah Imperatif](/id/docs/concepts/overview/object-management-kubectl/imperative-command/) +- [Pengelolaan Objek Kubernetes secara Imperatif Menggunakan File Konfigurasi](/id/docs/concepts/overview/object-management-kubectl/imperative-config/) - [Rujukan Perintah Kubectl](/docs/reference/generated/kubectl/kubectl/) - [Rujukan API Kubernetes](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/) diff --git a/content/id/docs/concepts/overview/object-management-kubectl/imperative-command.md b/content/id/docs/concepts/overview/object-management-kubectl/imperative-command.md index e77cc9ca63..23489efb59 100644 --- a/content/id/docs/concepts/overview/object-management-kubectl/imperative-command.md +++ b/content/id/docs/concepts/overview/object-management-kubectl/imperative-command.md @@ -126,8 +126,8 @@ kubectl create --edit -f /tmp/srv.yaml ## {{% heading "whatsnext" %}} -- [Pengelolaan Objek Kubernetes secara Imperatif dengan Menggunakan Konfigurasi Objek](/docs/concepts/overview/object-management-kubectl/imperative-config/) -- [Pengelolaan Objek Kubernetes secara Deklaratif dengan Menggunakan File Konfigurasi](/docs/concepts/overview/object-management-kubectl/declarative-config/) +- [Pengelolaan Objek Kubernetes secara Imperatif dengan Menggunakan Konfigurasi Objek](/id/docs/concepts/overview/object-management-kubectl/imperative-config/) +- [Pengelolaan Objek Kubernetes secara Deklaratif dengan Menggunakan File Konfigurasi](/id/docs/concepts/overview/object-management-kubectl/declarative-config/) - [Rujukan Perintah Kubectl](/docs/reference/generated/kubectl/kubectl/) - [Kubernetes API Reference](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/) diff --git a/content/id/docs/concepts/overview/object-management-kubectl/imperative-config.md b/content/id/docs/concepts/overview/object-management-kubectl/imperative-config.md index 7df68f579d..94f1082e35 100644 --- a/content/id/docs/concepts/overview/object-management-kubectl/imperative-config.md +++ b/content/id/docs/concepts/overview/object-management-kubectl/imperative-config.md @@ -108,8 +108,8 @@ template: ## {{% heading "whatsnext" %}} -- [Pengelolaan Objek Kubernetes Menggunakan Perintah Imperatif](/docs/concepts/overview/object-management-kubectl/imperative-command/) -- [Pengelolaan Objek Kubernetes secara Deklaratif dengan Menggunakan File Konfigurasi](/docs/concepts/overview/object-management-kubectl/declarative-config/) +- [Pengelolaan Objek Kubernetes Menggunakan Perintah Imperatif](/id/docs/concepts/overview/object-management-kubectl/imperative-command/) +- [Pengelolaan Objek Kubernetes secara Deklaratif dengan Menggunakan File Konfigurasi](/id/docs/concepts/overview/object-management-kubectl/declarative-config/) - [Rujukan Perintah Kubectl](/docs/reference/generated/kubectl/kubectl/) - [Rujukan API Kubernetes](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/) diff --git a/content/id/docs/concepts/overview/working-with-objects/annotations.md b/content/id/docs/concepts/overview/working-with-objects/annotations.md index 8a822f255d..aaa238add5 100644 --- a/content/id/docs/concepts/overview/working-with-objects/annotations.md +++ b/content/id/docs/concepts/overview/working-with-objects/annotations.md @@ -80,5 +80,5 @@ Prefiks `kubernetes.io/` dan `k8s.io/` merupakan reservasi dari komponen inti Ku ## {{% heading "whatsnext" %}} -Pelajari lebih lanjut tentang [Label dan Selektor](/docs/concepts/overview/working-with-objects/labels/). +Pelajari lebih lanjut tentang [Label dan Selektor](/id/docs/concepts/overview/working-with-objects/labels/). diff --git a/content/id/docs/concepts/overview/working-with-objects/field-selectors.md b/content/id/docs/concepts/overview/working-with-objects/field-selectors.md index 7cd81495cd..e46916ee3d 100644 --- a/content/id/docs/concepts/overview/working-with-objects/field-selectors.md +++ b/content/id/docs/concepts/overview/working-with-objects/field-selectors.md @@ -3,14 +3,14 @@ title: Selektor Field weight: 60 --- -Selektor *field* memungkinkan kamu untuk [memilih (*select*) *resource* Kubernetes](/docs/concepts/overview/working-with-objects/kubernetes-objects) berdasarkan +Selektor *field* memungkinkan kamu untuk [memilih (*select*) *resource* Kubernetes](/id/docs/concepts/overview/working-with-objects/kubernetes-objects) berdasarkan nilai dari satu atau banyak *field resource*. Di bawah ini merupakan contoh dari beberapa *query* selektor *field*: * `metadata.name=my-service` * `metadata.namespace!=default` * `status.phase=Pending` -Perintah `kubectl` di bawah ini memilih semua Pod dengan *field* [`status.phase`](/docs/concepts/workloads/pods/pod-lifecycle/#pod-phase) yang bernilai +Perintah `kubectl` di bawah ini memilih semua Pod dengan *field* [`status.phase`](/id/docs/concepts/workloads/pods/pod-lifecycle/#pod-phase) yang bernilai `Running`: ```shell @@ -50,7 +50,7 @@ kubectl get services --field-selector metadata.namespace!=default ## Selektor berantai -Seperti halnya [label](/docs/concepts/overview/working-with-objects/labels) dan selektor-selektor lainnya, kamu dapat membuat selektor *field* berantai +Seperti halnya [label](/id/docs/concepts/overview/working-with-objects/labels) dan selektor-selektor lainnya, kamu dapat membuat selektor *field* berantai (*chained*) dengan *list* yang dipisahkan oleh koma. Perintah `kubectl` di bawah ini memilih semua Pod dengan `status.phase` tidak sama dengan `Running` dan *field* `spec.restartPolicy` sama dengan `Always`: diff --git a/content/id/docs/concepts/overview/working-with-objects/kubernetes-objects.md b/content/id/docs/concepts/overview/working-with-objects/kubernetes-objects.md index 57eef5e9c6..aa702827b9 100644 --- a/content/id/docs/concepts/overview/working-with-objects/kubernetes-objects.md +++ b/content/id/docs/concepts/overview/working-with-objects/kubernetes-objects.md @@ -30,7 +30,7 @@ memberikan informasi pada sistem Kubernetes mengenai perilaku apakah yang kamu i dengan kata lain ini merupakan definisi _state_ klaster yang kamu inginkan. Untuk menggunakan objek-objek Kubernetes--baik membuat, mengubah, atau menghapus objek-objek tersebut--kamu -harus menggunakan [API Kubernetes](/docs/concepts/overview/kubernetes-api/). +harus menggunakan [API Kubernetes](/id/docs/concepts/overview/kubernetes-api/). Ketika kamu menggunakan perintah `kubectl`, perintah ini akan melakukan _API call_ untuk perintah yang kamu berikan. Kamu juga dapat menggunakan API Kubernetes secara langsung pada program yang kamu miliki menggunakan salah satu [_library_ klien](/docs/reference/using-api/client-libraries/) yang disediakan. @@ -103,7 +103,7 @@ dan format _spec_ untuk _Deployment_ dapat ditemukan ## {{% heading "whatsnext" %}} -* Pelajari lebih lanjut mengenai dasar-dasar penting bagi objek Kubernetes, seperti [Pod](/docs/concepts/workloads/pods/pod-overview/). +* Pelajari lebih lanjut mengenai dasar-dasar penting bagi objek Kubernetes, seperti [Pod](/id/docs/concepts/workloads/pods/pod-overview/). diff --git a/content/id/docs/concepts/overview/working-with-objects/names.md b/content/id/docs/concepts/overview/working-with-objects/names.md index 5527c15b72..0d6528c41d 100644 --- a/content/id/docs/concepts/overview/working-with-objects/names.md +++ b/content/id/docs/concepts/overview/working-with-objects/names.md @@ -8,7 +8,7 @@ weight: 20 Seluruh objek di dalam REST API Kubernetes secara jelas ditandai dengan nama dan UID. -Apabila pengguna ingin memberikan atribut tidak unik, Kubernetes menyediakan [label](/docs/user-guide/labels) dan [anotasi](/docs/concepts/overview/working-with-objects/annotations/). +Apabila pengguna ingin memberikan atribut tidak unik, Kubernetes menyediakan [label](/docs/user-guide/labels) dan [anotasi](/id/docs/concepts/overview/working-with-objects/annotations/). Bacalah [dokumentasi desain penanda](https://git.k8s.io/community/contributors/design-proposals/architecture/identifiers.md) agar kamu dapat memahami lebih lanjut sintaks yang digunakan untuk Nama dan UID. diff --git a/content/id/docs/concepts/overview/working-with-objects/namespaces.md b/content/id/docs/concepts/overview/working-with-objects/namespaces.md index 5eb358a17a..89ffb8ea14 100644 --- a/content/id/docs/concepts/overview/working-with-objects/namespaces.md +++ b/content/id/docs/concepts/overview/working-with-objects/namespaces.md @@ -19,7 +19,7 @@ Kubernetes mendukung banyak klaster virtual di dalam satu klaster fisik. Klaster *Namespace* menyediakan ruang untuk nama objek. Nama dari *resource* atau objek harus berbeda di dalam sebuah *namespace*, tetapi boleh sama jika berbeda *namespace*. *Namespace* tidak bisa dibuat di dalam *namespace* lain dan setiap *resource* atau objek Kubernetes hanya dapat berada di dalam satu *namespace*. -*Namespace* merupakan cara yang digunakan untuk memisahkan *resource* klaster untuk beberapa pengguna (dengan [*resource quota*](/docs/concepts/policy/resource-quotas/)). +*Namespace* merupakan cara yang digunakan untuk memisahkan *resource* klaster untuk beberapa pengguna (dengan [*resource quota*](/id/docs/concepts/policy/resource-quotas/)). Dalam versi Kubernetes yang akan datang, objek di dalam satu *namespace* akan mempunyai *access control policies* yang sama secara *default*. @@ -74,7 +74,7 @@ kubectl config view | grep namespace: ## Namespace dan DNS -Saat kamu membuat sebuah [Service](/docs/user-guide/services), Kubernetes membuat [Entri DNS](/docs/concepts/services-networking/dns-pod-service/) untuk *service* tersebut. Entri *DNS* ini berformat `<service-name>.<namespace-name>.svc.cluster.local`, yang berarti jika sebuah kontainer hanya menggunakan `<service-name>`, kontainer tersebut akan berkomunikasi dengan *service* yang berada di dalam satu *namespace*. Ini berguna untuk menggunakan konfigurasi yang sama di beberapa *namespace* seperti *Development*, *Staging*, dan *Production*. Jika kamu ingin berkomunikasi antar *namespace*, kamu harus menggunakan seluruh *fully qualified domain name (FQDN)*. +Saat kamu membuat sebuah [Service](/docs/user-guide/services), Kubernetes membuat [Entri DNS](/id/docs/concepts/services-networking/dns-pod-service/) untuk *service* tersebut. Entri *DNS* ini berformat `<service-name>.<namespace-name>.svc.cluster.local`, yang berarti jika sebuah kontainer hanya menggunakan `<service-name>`, kontainer tersebut akan berkomunikasi dengan *service* yang berada di dalam satu *namespace*. Ini berguna untuk menggunakan konfigurasi yang sama di beberapa *namespace* seperti *Development*, *Staging*, dan *Production*. Jika kamu ingin berkomunikasi antar *namespace*, kamu harus menggunakan seluruh *fully qualified domain name (FQDN)*. ## Tidak semua objek di dalam Namespace diff --git a/content/id/docs/concepts/policy/limit-range.md b/content/id/docs/concepts/policy/limit-range.md index 6de9d69dd2..106f4c1a84 100644 --- a/content/id/docs/concepts/policy/limit-range.md +++ b/content/id/docs/concepts/policy/limit-range.md @@ -1,6 +1,6 @@ --- title: LimitRange -content_template: templates/concept +content_type: concept weight: 10 --- diff --git a/content/id/docs/concepts/policy/pod-security-policy.md b/content/id/docs/concepts/policy/pod-security-policy.md index 2dbbd53144..991ebb44aa 100644 --- a/content/id/docs/concepts/policy/pod-security-policy.md +++ b/content/id/docs/concepts/policy/pod-security-policy.md @@ -45,13 +45,13 @@ Sejak API dari Pod Security Policy (`policy/v1beta1/podsecuritypolicy`) diaktifk ## Mengizinkan Kebijakan -Saat sebuah sumber daya PodSecurityPolicy dibuat, ia tidak melakukan apa-apa. Untuk menggunakannya, [Service Account](/docs/tasks/configure-pod-container/configure-service-account/) dari pengguna yang memintanya atau target Pod-nya harus diizinkan terlebih dahulu untuk menggunakan kebijakan tersebut, dengan membolehkan kata kerja `use` terhadap kebijakan tersebut. +Saat sebuah sumber daya PodSecurityPolicy dibuat, ia tidak melakukan apa-apa. Untuk menggunakannya, [Service Account](/id/docs/tasks/configure-pod-container/configure-service-account/) dari pengguna yang memintanya atau target Pod-nya harus diizinkan terlebih dahulu untuk menggunakan kebijakan tersebut, dengan membolehkan kata kerja `use` terhadap kebijakan tersebut. -Kebanyakan Pod Kubernetes tidak dibuat secara langsung oleh pengguna. Sebagai gantinya, mereka biasanya dibuat secara tidak langsung sebagai bagian dari sebuah [Deployment](/docs/concepts/workloads/controllers/deployment/), [ReplicaSet](/docs/concepts/workloads/controllers/replicaset/), atau pengontrol yang sudah ditemplat lainnya melalui Controller Manager. Memberikan akses untuk pengontrol terhadap kebijakan tersebut akan mengizinkan akses untuk *semua* Pod yang dibuat oleh pengontrol tersebut, sehingga metode yang lebih baik untuk mengizinkan kebijakan adalah dengan memberikan akses pada Service Account milik Pod (lihat [contohnya](#run-another-pod)). +Kebanyakan Pod Kubernetes tidak dibuat secara langsung oleh pengguna. Sebagai gantinya, mereka biasanya dibuat secara tidak langsung sebagai bagian dari sebuah [Deployment](/id/docs/concepts/workloads/controllers/deployment/), [ReplicaSet](/id/docs/concepts/workloads/controllers/replicaset/), atau pengontrol yang sudah ditemplat lainnya melalui Controller Manager. Memberikan akses untuk pengontrol terhadap kebijakan tersebut akan mengizinkan akses untuk *semua* Pod yang dibuat oleh pengontrol tersebut, sehingga metode yang lebih baik untuk mengizinkan kebijakan adalah dengan memberikan akses pada Service Account milik Pod (lihat [contohnya](#run-another-pod)). ### Melalui RBAC -[RBAC](/docs/reference/access-authn-authz/rbac/) adalah mode otorisasi standar Kubernetes, dan dapat digunakan dengan mudah untuk mengotorisasi penggunaan kebijakan-kebijakan. +[RBAC](/id/docs/reference/access-authn-authz/rbac/) adalah mode otorisasi standar Kubernetes, dan dapat digunakan dengan mudah untuk mengotorisasi penggunaan kebijakan-kebijakan. Pertama-tama, sebuah `Role` atau `ClusterRole` perlu memberikan akses pada kata kerja `use` terhadap kebijakan-kebijakan yang diinginkan. `rules` yang digunakan untuk memberikan akses tersebut terlihat seperti berikut: @@ -103,12 +103,12 @@ Jika sebuah `RoleBinding` (bukan `ClusterRoleBinding`) digunakan, maka ia hanya name: system:authenticated ``` -Untuk lebih banyak contoh pengikatan RBAC, lihat [Contoh Role Binding](/docs/reference/access-authn-authz/rbac#role-binding-examples). +Untuk lebih banyak contoh pengikatan RBAC, lihat [Contoh Role Binding](/id/docs/reference/access-authn-authz/rbac#role-binding-examples). Untuk contoh lengkap untuk mengotorisasi sebuah PodSecurityPolicy, lihat [di bawah](#contoh). ### Mengatasi Masalah -- [Controller Manager](/docs/admin/kube-controller-manager/) harus dijalankan terhadap [port API yang telah diamankan](/docs/reference/access-authn-authz/controlling-access/), dan tidak boleh memiliki izin _superuser_, atau semua permintaan akan melewati modul-modul otentikasi dan otorisasi, semua objek PodSecurityPolicy tidak akan diizinkan, dan semua pengguna dapat membuat Container-container yang _privileged_. Untuk lebih detil tentang mengkonfigurasi otorisasi Controller Manager, lihat [Controller Roles](/docs/reference/access-authn-authz/rbac/#controller-roles). +- [Controller Manager](/docs/admin/kube-controller-manager/) harus dijalankan terhadap [port API yang telah diamankan](/docs/reference/access-authn-authz/controlling-access/), dan tidak boleh memiliki izin _superuser_, atau semua permintaan akan melewati modul-modul otentikasi dan otorisasi, semua objek PodSecurityPolicy tidak akan diizinkan, dan semua pengguna dapat membuat Container-container yang _privileged_. Untuk lebih detil tentang mengkonfigurasi otorisasi Controller Manager, lihat [Controller Roles](/id/docs/reference/access-authn-authz/rbac/#controller-roles). ## Urutan Kebijakan @@ -324,7 +324,7 @@ determines if any container in a pod can enable privileged mode. ### Volume dan _file system_ -**Volume** - Menyediakan sebuah daftar putih dari tipe-tipe Volume yang diizinkan. Nilai-nilai yang diizinkan sesuai dengan sumber Volume yang didefinisikan saat membuat sebuah Volume. Untuk daftar lengkap tipe-tipe Volume, lihat [tipe-tipe Volume](/docs/concepts/storage/volumes/#tipe-tipe-volume). Sebagai tambahan, `*` dapat digunakan untuk mengizinkan semua tipe Volume. +**Volume** - Menyediakan sebuah daftar putih dari tipe-tipe Volume yang diizinkan. Nilai-nilai yang diizinkan sesuai dengan sumber Volume yang didefinisikan saat membuat sebuah Volume. Untuk daftar lengkap tipe-tipe Volume, lihat [tipe-tipe Volume](/id/docs/concepts/storage/volumes/#tipe-tipe-volume). Sebagai tambahan, `*` dapat digunakan untuk mengizinkan semua tipe Volume. **Kumpulan Volume-volume minimal yang direkomendasikan** untuk PodSecurityPolicy baru adalah sebagai berikut: diff --git a/content/id/docs/concepts/policy/resource-quotas.md b/content/id/docs/concepts/policy/resource-quotas.md index 47bfa996bb..c001ef4a40 100644 --- a/content/id/docs/concepts/policy/resource-quotas.md +++ b/content/id/docs/concepts/policy/resource-quotas.md @@ -81,7 +81,7 @@ Berikut jenis-jenis sumber daya yang didukung: ### Resource Quota untuk sumber daya yang diperluas Sebagai tambahan untuk sumber daya yang disebutkan di atas, pada rilis 1.10, dukungan kuota untuk -[sumber daya yang diperluas](/docs/concepts/configuration/manage-compute-resources-container/#extended-resources) ditambahkan. +[sumber daya yang diperluas](/id/docs/concepts/configuration/manage-compute-resources-container/#extended-resources) ditambahkan. Karena _overcommit_ tidak diperbolehkan untuk sumber daya yang diperluas, tidak masuk akal untuk menentukan keduanya; `requests` dan `limits` untuk sumber daya yang diperluas yang sama pada sebuah kuota. Jadi, untuk @@ -98,7 +98,7 @@ Lihat [Melihat dan Menyetel Kuota](#melihat-dan-menyetel-kuota) untuk informasi ## Resource Quota untuk penyimpanan -Kamu dapat membatasi jumlah total [sumber daya penyimpanan](/docs/concepts/storage/persistent-volumes/) yang dapat +Kamu dapat membatasi jumlah total [sumber daya penyimpanan](/id/docs/concepts/storage/persistent-volumes/) yang dapat diminta pada sebuah Namespace. Sebagai tambahan, kamu dapat membatasi penggunaan sumber daya penyimpanan berdasarkan _storage class_ @@ -107,9 +107,9 @@ sumber daya penyimpanan tersebut. | Nama Sumber Daya | Deskripsi | | --------------------- | ----------------------------------------------------------- | | `requests.storage` | Pada seluruh Persistent Volume Claim, jumlah `requests` penyimpanan tidak dapat melebihi nilai ini. | -| `persistentvolumeclaims` | Jumlah kuantitas [Persistent Volume Claim](/docs/concepts/storage/persistent-volumes/#persistentvolumeclaims) yang dapat ada di dalam sebuah Namespace. | +| `persistentvolumeclaims` | Jumlah kuantitas [Persistent Volume Claim](/id/docs/concepts/storage/persistent-volumes/#persistentvolumeclaims) yang dapat ada di dalam sebuah Namespace. | | `<storage-class-name>.storageclass.storage.k8s.io/requests.storage` | Pada seluruh Persistent Volume Claim yang dikaitkan dengan sebuah nama _storage-class_ (melalui kolom `storageClassName`), jumlah permintaan penyimpanan tidak dapat melebihi nilai ini. | -| `<storage-class-name>.storageclass.storage.k8s.io/persistentvolumeclaims` | Pada seluruh Persistent Volume Claim yang dikaitkan dengan sebuah nama _storage-class_ (melalui kolom `storageClassName`), jumlah kuantitas [Persistent Volume Claim](/docs/concepts/storage/persistent-volumes/#persistentvolumeclaims) yang dapat ada di dalam sebuah Namespace. | +| `<storage-class-name>.storageclass.storage.k8s.io/persistentvolumeclaims` | Pada seluruh Persistent Volume Claim yang dikaitkan dengan sebuah nama _storage-class_ (melalui kolom `storageClassName`), jumlah kuantitas [Persistent Volume Claim](/id/docs/concepts/storage/persistent-volumes/#persistentvolumeclaims) yang dapat ada di dalam sebuah Namespace. | Sebagai contoh, jika sebuah operator ingin membatasi penyimpanan dengan Storage Class `gold` yang berbeda dengan Storage Class `bronze`, maka operator tersebut dapat menentukan kuota sebagai berikut: @@ -163,7 +163,7 @@ Berikut jenis-jenis yang telah didukung: | Nama Sumber Daya | Deskripsi | | ------------------------------- | ------------------------------------------------- | | `configmaps` | Jumlah total ConfigMap yang dapat berada pada suatu Namespace. | -| `persistentvolumeclaims` | Jumlah total PersistentVolumeClaim[persistent volume claims](/docs/concepts/storage/persistent-volumes/#persistentvolumeclaims) yang dapat berada pada suatu Namespace. | +| `persistentvolumeclaims` | Jumlah total PersistentVolumeClaim[persistent volume claims](/id/docs/concepts/storage/persistent-volumes/#persistentvolumeclaims) yang dapat berada pada suatu Namespace. | | `pods` | Jumlah total Pod yang berada pada kondisi non-terminal yang dapat berada pada suatu Namespace. Sebuah Pod berada kondisi terminal yaitu jika `.status.phase in (Failed, Succeded)` adalah `true`. | | `replicationcontrollers` | Jumlah total ReplicationController yang dapat berada pada suatu Namespace. | | `resourcequotas` | Jumlah total [ResourceQuota](/docs/reference/access-authn-authz/admission-controllers/#resourcequota) yang dapat berada pada suatu Namespace. | @@ -208,7 +208,7 @@ Lingkup `Terminating`, `NotTerminating`, dan `NotBestEffort` membatasi sebuah k {{< feature-state for_k8s_version="1.12" state="beta" >}} -Pod-Pod dapat dibuat dengan sebuah [Priority (prioritas)](/docs/concepts/configuration/pod-priority-preemption/#pod-priority) tertentu. +Pod-Pod dapat dibuat dengan sebuah [Priority (prioritas)](/id/docs/concepts/configuration/pod-priority-preemption/#pod-priority) tertentu. Kamu dapat mengontrol konsumsi sumber daya sistem sebuah Pod berdasarkan Priority Pod tersebut, menggunakan kolom `scopeSelector` pada spesifikasi kuota tersebut. diff --git a/content/id/docs/concepts/scheduling/kube-scheduler.md b/content/id/docs/concepts/scheduling/kube-scheduler.md index f4cd477608..6f7efab3d9 100644 --- a/content/id/docs/concepts/scheduling/kube-scheduler.md +++ b/content/id/docs/concepts/scheduling/kube-scheduler.md @@ -94,10 +94,10 @@ penilaian oleh penjadwal: ## {{% heading "whatsnext" %}} -* Baca tentang [penyetelan performa penjadwal](/docs/concepts/scheduling/scheduler-perf-tuning/) -* Baca tentang [pertimbangan penyebarang topologi pod](/docs/concepts/workloads/pods/pod-topology-spread-constraints/) +* Baca tentang [penyetelan performa penjadwal](/id/docs/concepts/scheduling/scheduler-perf-tuning/) +* Baca tentang [pertimbangan penyebarang topologi pod](/id/docs/concepts/workloads/pods/pod-topology-spread-constraints/) * Baca [referensi dokumentasi](/docs/reference/command-line-tools-reference/kube-scheduler/) untuk _kube-scheduler_ * Pelajari tentang [mengkonfigurasi beberapa penjadwal](/docs/tasks/administer-cluster/configure-multiple-schedulers/) * Pelajari tentang [aturan manajemen topologi](/docs/tasks/administer-cluster/topology-manager/) -* Pelajari tentang [pengeluaran tambahan Pod](/docs/concepts/configuration/pod-overhead/) +* Pelajari tentang [pengeluaran tambahan Pod](/id/docs/concepts/configuration/pod-overhead/) diff --git a/content/id/docs/concepts/scheduling/scheduler-perf-tuning.md b/content/id/docs/concepts/scheduling/scheduler-perf-tuning.md index 0a20d9050a..3689ecf7cb 100644 --- a/content/id/docs/concepts/scheduling/scheduler-perf-tuning.md +++ b/content/id/docs/concepts/scheduling/scheduler-perf-tuning.md @@ -8,7 +8,7 @@ weight: 70 {{< feature-state for_k8s_version="v1.14" state="beta" >}} -[kube-scheduler](/docs/concepts/scheduling/kube-scheduler/#kube-scheduler) +[kube-scheduler](/id/docs/concepts/scheduling/kube-scheduler/#kube-scheduler) merupakan penjadwal (_scheduler_) Kubernetes bawaan yang bertanggung jawab terhadap penempatan Pod-Pod pada seluruh Node di dalam sebuah klaster. @@ -66,7 +66,7 @@ Kamu bisa mengatur ambang batas untuk menentukan berapa banyak jumlah Node minim persentase bagian dari seluruh Node di dalam klaster kamu. kube-scheduler akan mengubahnya menjadi bilangan bulat berisi jumlah Node. Saat penjadwalan, jika kube-scheduler mengidentifikasi cukup banyak Node-Node layak untuk melewati jumlah persentase yang diatur, maka kube-scheduler -akan berhenti mencari Node-Node layak dan lanjut ke [fase penskoran] (/docs/concepts/scheduling/kube-scheduler/#kube-scheduler-implementation). +akan berhenti mencari Node-Node layak dan lanjut ke [fase penskoran] (/id/docs/concepts/scheduling/kube-scheduler/#kube-scheduler-implementation). [Bagaimana penjadwal mengecek Node](#bagaimana-penjadwal-mengecek-node) menjelaskan proses ini secara detail. diff --git a/content/id/docs/concepts/security/overview.md b/content/id/docs/concepts/security/overview.md index caff040bc5..bc271e0645 100644 --- a/content/id/docs/concepts/security/overview.md +++ b/content/id/docs/concepts/security/overview.md @@ -107,11 +107,11 @@ Kebanyakan dari saran yang disebut di atas dapat diotomasi di dalam _delivery pi ## {{% heading "whatsnext" %}} -* Pelajari tentang [Network Policy untuk Pod](/docs/concepts/services-networking/network-policies/) +* Pelajari tentang [Network Policy untuk Pod](/id/docs/concepts/services-networking/network-policies/) * Pelajari tentang [mengamankan klaster kamu](/docs/tasks/administer-cluster/securing-a-cluster/) * Pelajari tentang [kontrol akses API](/docs/reference/access-authn-authz/controlling-access/) -* Pelajari tentang [enkripsi data saat transit](/docs/tasks/tls/managing-tls-in-a-cluster/) for the control plane +* Pelajari tentang [enkripsi data saat transit](/id/docs/tasks/tls/managing-tls-in-a-cluster/) for the control plane * Pelajari tentang [enkripsi data saat diam](/docs/tasks/administer-cluster/encrypt-data/) -* Pelajari tentang [Secret (data sensitif) pada Kubernetes](/docs/concepts/configuration/secret/) +* Pelajari tentang [Secret (data sensitif) pada Kubernetes](/id/docs/concepts/configuration/secret/) diff --git a/content/id/docs/concepts/services-networking/connect-applications-service.md b/content/id/docs/concepts/services-networking/connect-applications-service.md index 4bbd0bbf56..806fff3a46 100644 --- a/content/id/docs/concepts/services-networking/connect-applications-service.md +++ b/content/id/docs/concepts/services-networking/connect-applications-service.md @@ -47,7 +47,7 @@ kubectl get pods -l run=my-nginx -o yaml | grep podIP Kamu dapat melakukan akses dengan *ssh* ke dalam *node* di dalam klaster dan mengakses IP *Pod* tersebut menggunakan *curl*. Perlu dicatat bahwa kontainer tersebut tidak menggunakan *port* 80 di dalam *node*, atau aturan *NAT* khusus untuk merutekan trafik ke dalam *Pod*. Ini berarti kamu dapat menjalankan banyak *nginx Pod* di *node* yang sama dimana setiap *Pod* dapat menggunakan *containerPort* yang sama, kamu dapat mengakses semua itu dari *Pod* lain ataupun dari *node* di dalam klaster menggunakan IP. Seperti *Docker*, *port* masih dapat di publikasi ke dalam * interface node*, tetapi kebutuhan seperti ini sudah berkurang karena model jaringannya. -Kamu dapat membaca lebih detail [bagaimana kita melakukan ini](/docs/concepts/cluster-administration/networking/#how-to-achieve-this) jika kamu penasaran. +Kamu dapat membaca lebih detail [bagaimana kita melakukan ini](/id/docs/concepts/cluster-administration/networking/#how-to-achieve-this) jika kamu penasaran. ## Membuat Service @@ -107,7 +107,7 @@ NAME ENDPOINTS AGE my-nginx 10.244.2.5:80,10.244.3.4:80 1m ``` -Kamu sekarang dapat melakukan *curl* ke dalam *nginx Service* di `<CLUSTER-IP>:<PORT>` dari *node* manapun di klaster. Perlu dicatat bahwa *Service IP* adalah IP virtual, IP tersebut tidak pernah ada di *interface node* manapun. Jika kamu penasaran bagaimana konsep ini bekerja, kamu dapat membaca lebih lanjut tentang [service proxy](/docs/concepts/services-networking/service/#virtual-ips-and-service-proxies). +Kamu sekarang dapat melakukan *curl* ke dalam *nginx Service* di `<CLUSTER-IP>:<PORT>` dari *node* manapun di klaster. Perlu dicatat bahwa *Service IP* adalah IP virtual, IP tersebut tidak pernah ada di *interface node* manapun. Jika kamu penasaran bagaimana konsep ini bekerja, kamu dapat membaca lebih lanjut tentang [service proxy](/id/docs/concepts/services-networking/service/#virtual-ips-and-service-proxies). ## Mengakses Service @@ -194,7 +194,7 @@ Hingga sekarang kita hanya mengakses *nginx* server dari dalam klaster. Sebelum * *Self signed certificates* untuk *https* (kecuali jika kamu sudah mempunyai *identity certificate*) * Sebuah server *nginx* yang terkonfigurasi untuk menggunakan *certificate* tersebut -* Sebuah [secret](/docs/concepts/configuration/secret/) yang membuat setifikat tersebut dapat diakses oleh *pod* +* Sebuah [secret](/id/docs/concepts/configuration/secret/) yang membuat setifikat tersebut dapat diakses oleh *pod* Kamu dapat melihat semua itu di [contoh nginx https](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/staging/https-nginx/). Contoh ini mengaharuskan kamu melakukan instalasi *go* dan *make*. Jika kamu tidak ingin melakukan instalasi tersebut, ikuti langkah-langkah manualnya nanti, singkatnya: @@ -362,6 +362,6 @@ LoadBalancer Ingress: a320587ffd19711e5a37606cf4a74574-1142138393.us-east-1.el ## {{% heading "whatsnext" %}} -Kubernetes juga mendukung *Federated Service*, yang bisa mempengaruhi banyak klaster dan penyedia layanan *cloud*, untuk meningkatkan ketersediaan, peningkatan toleransi kesalahan, dan pengembangan dari *Service* kamu. Lihat [Panduan Federated Service](/docs/concepts/cluster-administration/federation-service-discovery/) untuk informasi lebih lanjut. +Kubernetes juga mendukung *Federated Service*, yang bisa mempengaruhi banyak klaster dan penyedia layanan *cloud*, untuk meningkatkan ketersediaan, peningkatan toleransi kesalahan, dan pengembangan dari *Service* kamu. Lihat [Panduan Federated Service](/id/docs/concepts/cluster-administration/federation-service-discovery/) untuk informasi lebih lanjut. diff --git a/content/id/docs/concepts/services-networking/dns-pod-service.md b/content/id/docs/concepts/services-networking/dns-pod-service.md index 52ec19a420..efdba8d7a1 100644 --- a/content/id/docs/concepts/services-networking/dns-pod-service.md +++ b/content/id/docs/concepts/services-networking/dns-pod-service.md @@ -50,7 +50,7 @@ menggunakan penjadwalan Round-Robin dari set yang ada. ### SRV _record_ SRV _record_ dibuat untuk port bernama yang merupakan bagian dari Service normal maupun [Headless -Services](/docs/concepts/services-networking/service/#headless-services). +Services](/id/docs/concepts/services-networking/service/#headless-services). Untuk setiap port bernama, SRV _record_ akan memiliki format `_my-port-name._my-port-protocol.my-svc.my-namespace.svc.cluster-domain.example`. Untuk sebuah Service normal, ini akan melakukan resolusi pada nomor port dan diff --git a/content/id/docs/concepts/services-networking/endpoint-slices.md b/content/id/docs/concepts/services-networking/endpoint-slices.md index 224e7b4bbd..1782f4273e 100644 --- a/content/id/docs/concepts/services-networking/endpoint-slices.md +++ b/content/id/docs/concepts/services-networking/endpoint-slices.md @@ -45,7 +45,7 @@ term_id="selector" >}} dituliskan. EndpointSlice tersebut akan memiliki referensi-referensi menuju Pod manapun yang cocok dengan selektor pada Service tersebut. EndpointSlice mengelompokkan _endpoint_ jaringan berdasarkan kombinasi Service dan Port yang unik. Nama dari sebuah objek EndpointSlice haruslah berupa -[nama subdomain DNS](/docs/concepts/overview/working-with-objects/names#dns-subdomain-names) yang sah. +[nama subdomain DNS](/id/docs/concepts/overview/working-with-objects/names#dns-subdomain-names) yang sah. Sebagai contoh, berikut merupakan sampel sumber daya EndpointSlice untuk sebuah Service Kubernetes yang bernama `example`. @@ -180,6 +180,6 @@ bersangkutan. * [Mengaktifkan EndpointSlice](/docs/tasks/administer-cluster/enabling-endpointslices) -* Baca [Menghubungkan Aplikasi dengan Service](/docs/concepts/services-networking/connect-applications-service/) +* Baca [Menghubungkan Aplikasi dengan Service](/id/docs/concepts/services-networking/connect-applications-service/) diff --git a/content/id/docs/concepts/services-networking/ingress-controllers.md b/content/id/docs/concepts/services-networking/ingress-controllers.md index 9491f5dc1c..645f2dbf8d 100644 --- a/content/id/docs/concepts/services-networking/ingress-controllers.md +++ b/content/id/docs/concepts/services-networking/ingress-controllers.md @@ -71,7 +71,7 @@ Pastikan kamu sudah terlebih dahulu memahami dokumentasi kontroler Ingress yang ## {{% heading "whatsnext" %}} -* Pelajari [Ingress](/docs/concepts/services-networking/ingress/) lebih lanjut. +* Pelajari [Ingress](/id/docs/concepts/services-networking/ingress/) lebih lanjut. * [Melakukan konfigurasi Ingress pada Minikube dengan kontroler NGINX](/docs/tasks/access-application-cluster/ingress-minikube) diff --git a/content/id/docs/concepts/services-networking/ingress.md b/content/id/docs/concepts/services-networking/ingress.md index 617581b421..1cc56c5960 100644 --- a/content/id/docs/concepts/services-networking/ingress.md +++ b/content/id/docs/concepts/services-networking/ingress.md @@ -16,8 +16,8 @@ Untuk memudahkan, di awal akan dijelaskan beberapa terminologi yang sering dipak * Node: Sebuah mesin fisik atau virtual yang berada di dalam klaster Kubernetes. * Klaster: Sekelompok node yang merupakan *resource* komputasi primer yang diatur oleh Kubernetes, biasanya diproteksi dari internet dengan menggunakan *firewall*. * *Edge router*: Sebuah *router* mengatur *policy firewall* pada klaster kamu. *Router* ini bisa saja berupa *gateway* yang diatur oleh penyedia layanan *cloud* maupun perangkat keras. -* Jaringan klaster: Seperangkat *links* baik logis maupus fisik, yang memfasilitasi komunikasi di dalam klaster berdasarkan [model jaringan Kubernetes](/docs/concepts/cluster-administration/networking/). -* *Service*: Sebuah [*Service*](/docs/concepts/services-networking/service/) yang mengidentifikasi beberapa *Pod* dengan menggunakan *selector label*. Secara umum, semua *Service* diasumsikan hanya memiliki IP virtual yang hanya dapat diakses dari dalam jaringan klaster. +* Jaringan klaster: Seperangkat *links* baik logis maupus fisik, yang memfasilitasi komunikasi di dalam klaster berdasarkan [model jaringan Kubernetes](/id/docs/concepts/cluster-administration/networking/). +* *Service*: Sebuah [*Service*](/id/docs/concepts/services-networking/service/) yang mengidentifikasi beberapa *Pod* dengan menggunakan *selector label*. Secara umum, semua *Service* diasumsikan hanya memiliki IP virtual yang hanya dapat diakses dari dalam jaringan klaster. ## Apakah *Ingress* itu? @@ -34,11 +34,11 @@ Mekanisme *routing* trafik dikendalikan oleh aturan-aturan yang didefinisikan pa ``` Sebuah *Ingress* dapat dikonfigurasi agar berbagai *Service* memiliki URL yang dapat diakses dari eksternal (luar klaster), melakukan *load balance* pada trafik, terminasi SSL, serta Virtual Host berbasis Nama. -Sebuah [kontroler Ingress](/docs/concepts/services-networking/ingress-controllers) bertanggung jawab untuk menjalankan fungsi Ingress yaitu sebagai *loadbalancer*, meskipun dapat juga digunakan untuk mengatur *edge router* atau *frontend* tambahan untuk menerima trafik. +Sebuah [kontroler Ingress](/id/docs/concepts/services-networking/ingress-controllers) bertanggung jawab untuk menjalankan fungsi Ingress yaitu sebagai *loadbalancer*, meskipun dapat juga digunakan untuk mengatur *edge router* atau *frontend* tambahan untuk menerima trafik. Sebuah *Ingress* tidak mengekspos sembarang *port* atau protokol. Mengekspos *Service* untuk protokol selain HTTP ke HTTPS internet biasanya dilakukan dengan menggunakan -*service* dengan tipe [Service.Type=NodePort](/docs/concepts/services-networking/service/#nodeport) atau -[Service.Type=LoadBalancer](/docs/concepts/services-networking/service/#loadbalancer). +*service* dengan tipe [Service.Type=NodePort](/id/docs/concepts/services-networking/service/#nodeport) atau +[Service.Type=LoadBalancer](/id/docs/concepts/services-networking/service/#loadbalancer). ## Prasyarat @@ -47,7 +47,7 @@ Sebuah *Ingress* tidak mengekspos sembarang *port* atau protokol. Mengekspos *Se Sebelum kamu mulai menggunakan *Ingress*, ada beberapa hal yang perlu kamu ketahui sebelumnya. *Ingress* merupakan *resource* dengan tipe beta. {{< note >}} -Kamu harus terlebih dahulu memiliki [kontroler Ingress](/docs/concepts/services-networking/ingress-controllers) untuk dapat memenuhi *Ingress*. Membuat sebuah *Ingress* tanpa adanya kontroler *Ingres* tidak akan berdampak apa pun. +Kamu harus terlebih dahulu memiliki [kontroler Ingress](/id/docs/concepts/services-networking/ingress-controllers) untuk dapat memenuhi *Ingress*. Membuat sebuah *Ingress* tanpa adanya kontroler *Ingres* tidak akan berdampak apa pun. {{< /note >}} GCE/Google Kubernetes Engine melakukan deploy kontroler *Ingress* pada *master*. Perhatikan laman berikut @@ -56,7 +56,7 @@ kontroler ini jika kamu menggunakan GCE/GKE. Jika kamu menggunakan *environment* selain GCE/Google Kubernetes Engine, kemungkinan besar kamu harus [melakukan proses deploy kontroler ingress kamu sendiri](https://kubernetes.github.io/ingress-nginx/deploy/). Terdapat beberapa jenis -[kontroler Ingress](/docs/concepts/services-networking/ingress-controllers) yang bisa kamu pilih. +[kontroler Ingress](/id/docs/concepts/services-networking/ingress-controllers) yang bisa kamu pilih. ### Sebelum kamu memulai @@ -89,10 +89,10 @@ spec: ``` Seperti layaknya *resource* Kubernetes yang lain, sebuah Ingress membutuhkan *field* `apiVersion`, `kind`, dan `metadata`. - Untuk informasi umum soal bagaimana cara bekerja dengan menggunakan file konfigurasi, silahkan merujuk pada [melakukan deploy aplikasi](/docs/tasks/run-application/run-stateless-application-deployment/), [konfigurasi kontainer](/docs/tasks/configure-pod-container/configure-pod-configmap/), [mengatur *resource*](/docs/concepts/cluster-administration/manage-deployment/). + Untuk informasi umum soal bagaimana cara bekerja dengan menggunakan file konfigurasi, silahkan merujuk pada [melakukan deploy aplikasi](/docs/tasks/run-application/run-stateless-application-deployment/), [konfigurasi kontainer](/id/docs/tasks/configure-pod-container/configure-pod-configmap/), [mengatur *resource*](/id/docs/concepts/cluster-administration/manage-deployment/). Ingress seringkali menggunakan anotasi untuk melakukan konfigurasi beberapa opsi yang ada bergantung pada kontroler Ingress yang digunakan, sebagai contohnya adalah [anotasi rewrite-target](https://github.com/kubernetes/ingress-nginx/blob/master/docs/examples/rewrite/README.md). - [Kontroler Ingress](/docs/concepts/services-networking/ingress-controllers) yang berbeda memiliki jenis anotasi yang berbeda. Pastikan kamu sudah terlebih dahulu memahami dokumentasi + [Kontroler Ingress](/id/docs/concepts/services-networking/ingress-controllers) yang berbeda memiliki jenis anotasi yang berbeda. Pastikan kamu sudah terlebih dahulu memahami dokumentasi kontroler Ingress yang akan kamu pakai untuk mengetahui jenis anotasi apa sajakah yang disediakan. [Spesifikasi](https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status) Ingress @@ -111,7 +111,7 @@ Setiap *rule* HTTP mengandung informasi berikut: dan `servicePort`. Baik *host* dan *path* harus sesuai dengan konten dari *request* yang masuk sebelum *loadbalancer* akan mengarahkan trafik pada *service* yang sesuai. * Suatu *backend* adalah kombinasi *service* dan *port* seperti yang dideskripsikan di - [dokumentasi *Service*](/docs/concepts/services-networking/service/). *Request* HTTP (dan HTTPS) yang sesuai dengan + [dokumentasi *Service*](/id/docs/concepts/services-networking/service/). *Request* HTTP (dan HTTPS) yang sesuai dengan *host* dan *path* yang ada pada *rule* akan diteruskan pada *backend* terkait. *Backend default* seringkali dikonfigurasi pada kontroler kontroler Ingress, tugas *backend default* ini adalah @@ -120,7 +120,7 @@ Setiap *rule* HTTP mengandung informasi berikut: ### *Backend Default* Sebuah Ingress yang tidak memiliki *rules* akan mengarahkan semua trafik pada sebuah *backend default*. *Backend default* inilah yang -biasanya bisa dimasukkan sebagai salah satu opsi konfigurasi dari [kontroler Ingress](/docs/concepts/services-networking/ingress-controllers) dan tidak dimasukkan dalam spesifikasi *resource* Ingress. +biasanya bisa dimasukkan sebagai salah satu opsi konfigurasi dari [kontroler Ingress](/id/docs/concepts/services-networking/ingress-controllers) dan tidak dimasukkan dalam spesifikasi *resource* Ingress. Jika tidak ada *host* atau *path* yang sesuai dengan *request* HTTP pada objek Ingress, maka trafik tersebut akan diarahkan pada *backend default*. @@ -218,8 +218,8 @@ Apabila *Ingress* selesai dibuat, maka kamu dapat melihat alamat IP dari berbaga pada kolom `address`. {{< note >}} -Kamu mungkin saja membutuhkan konfigurasi default-http-backend [Service](/docs/concepts/services-networking/service/) -bergantung pada [kontroler Ingress](/docs/concepts/services-networking/ingress-controllers) yang kamu pakai. +Kamu mungkin saja membutuhkan konfigurasi default-http-backend [Service](/id/docs/concepts/services-networking/service/) +bergantung pada [kontroler Ingress](/id/docs/concepts/services-networking/ingress-controllers) yang kamu pakai. {{< /note >}} ### Virtual Host berbasis Nama @@ -291,7 +291,7 @@ spec: ### TLS -Kamu dapat mengamankan *Ingress* yang kamu miliki dengan memberikan spesifikasi [secret](/docs/concepts/configuration/secret) +Kamu dapat mengamankan *Ingress* yang kamu miliki dengan memberikan spesifikasi [secret](/id/docs/concepts/configuration/secret) yang mengandung *private key* dan sertifikat TLS. Saat ini, Ingress hanya memiliki fitur untuk melakukan konfigurasi *single TLS port*, yaitu 443, serta melakukan terminasi TLS. Jika *section* TLS pada Ingress memiliki spesifikasi *host* yang berbeda, @@ -448,8 +448,8 @@ Ingress yang ingin diubah. ## Mekanisme *failing* pada beberapa zona *availability* Teknik untuk menyeimbangkan persebaran trafik pada *failure domain* berbeda antar penyedia layanan *cloud*. -Kamu dapat mempelajari dokumentasi yang relevan bagi [kontoler Ingress](/docs/concepts/services-networking/ingress-controllers) -untuk informasi yang lebih detail. Kamu juga dapat mempelajari [dokumentasi federasi](/docs/concepts/cluster-administration/federation/) +Kamu dapat mempelajari dokumentasi yang relevan bagi [kontoler Ingress](/id/docs/concepts/services-networking/ingress-controllers) +untuk informasi yang lebih detail. Kamu juga dapat mempelajari [dokumentasi federasi](/id/docs/concepts/cluster-administration/federation/) untuk informasi lebih detail soal bagaimana melakukan *deploy* untuk federasi klaster. ## Pengembangan selanjutnya @@ -463,8 +463,8 @@ soal perubahan berbagai kontroler. Kamu dapat mengekspos sebuah *Service* dalam berbagai cara, tanpa harus menggunakan *resource* Ingress, dengan menggunakan: -* [Service.Type=LoadBalancer](/docs/concepts/services-networking/service/#loadbalancer) -* [Service.Type=NodePort](/docs/concepts/services-networking/service/#nodeport) +* [Service.Type=LoadBalancer](/id/docs/concepts/services-networking/service/#loadbalancer) +* [Service.Type=NodePort](/id/docs/concepts/services-networking/service/#nodeport) * [Port Proxy](https://git.k8s.io/contrib/for-demos/proxy-to-service) diff --git a/content/id/docs/concepts/services-networking/network-policies.md b/content/id/docs/concepts/services-networking/network-policies.md index 25f42ddb98..fe510b846d 100644 --- a/content/id/docs/concepts/services-networking/network-policies.md +++ b/content/id/docs/concepts/services-networking/network-policies.md @@ -80,7 +80,7 @@ kecuali penyedia jaringan mendukung network policy. **_Field-field_ yang bersifat wajib**: Sama dengan seluruh _config_ Kubernetes lainnya, sebuah `NetworkPolicy` membutuhkan _field-field_ `apiVersion`, `kind`, dan `metadata`. Informasi generik mengenai bagaimana bekerja dengan _file_ `config`, dapat dilihat di -[Konfigurasi Kontainer menggunakan `ConfigMap`](/docs/tasks/configure-pod-container/configure-pod-configmap/), +[Konfigurasi Kontainer menggunakan `ConfigMap`](/id/docs/tasks/configure-pod-container/configure-pod-configmap/), serta [Manajemen Objek](/docs/concepts/overview/object-management-kubectl/overview/). **spec**: `NetworkPolicy` [spec](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-architecture/api-conventions.md#spec-and-status) memiliki semua informasi yang harus diberikan untuk memberikan definisi _network policy_ yang ada pada _namespace_ tertentu. diff --git a/content/id/docs/concepts/services-networking/service-topology.md b/content/id/docs/concepts/services-networking/service-topology.md index ef15d1ab3d..05abffa323 100644 --- a/content/id/docs/concepts/services-networking/service-topology.md +++ b/content/id/docs/concepts/services-networking/service-topology.md @@ -186,5 +186,5 @@ spec: * Baca tentang [mengaktifkan topologi Service](/docs/tasks/administer-cluster/enabling-service-topology) -* Baca [menghubungkan aplikasi dengan Service](/docs/concepts/services-networking/connect-applications-service/) +* Baca [menghubungkan aplikasi dengan Service](/id/docs/concepts/services-networking/connect-applications-service/) diff --git a/content/id/docs/concepts/services-networking/service.md b/content/id/docs/concepts/services-networking/service.md index 97626bf9ce..00bf4e6241 100644 --- a/content/id/docs/concepts/services-networking/service.md +++ b/content/id/docs/concepts/services-networking/service.md @@ -12,9 +12,9 @@ weight: 10 <!-- overview --> -[`Pod`](/docs/concepts/workloads/pods/pod/) pada Kubernetes bersifat *mortal*. +[`Pod`](/id/docs/concepts/workloads/pods/pod/) pada Kubernetes bersifat *mortal*. Artinya apabila _pod-pod_ tersebut dibuat dan kemudian mati, _pod-pod_ tersebut -tidak akan dihidupkan kembali. [`ReplicaSets`](/docs/concepts/workloads/controllers/replicaset/) secara +tidak akan dihidupkan kembali. [`ReplicaSets`](/id/docs/concepts/workloads/controllers/replicaset/) secara khusus bertugas membuat dan menghapus `Pod` secara dinamsi (misalnya, pada proses *scaling out* atau *scaling in*). Meskipun setiap `Pod` memiliki alamat IP-nya masing-masing, kamu tidak dapat mengandalkan alamat IP yang diberikan pada _pod-pod_ tersebut, karena alamat IP yang diberikan tidak stabil. @@ -26,7 +26,7 @@ Inilah alasan kenapa `Service` ada. Sebuah `Service` pada Kubernetes adalah sebuah abstraksi yang memberikan definisi set logis yang terdiri beberapa `Pod` serta _policy_ bagaimana cara kamu mengakses sekumpulan `Pod` tadi - seringkali disebut sebagai _microservices_. -Set `Pod` yang dirujuk oleh suatu `Service` (biasanya) ditentukan oleh sebuah [`Label Selector`](/docs/concepts/overview/working-with-objects/labels/#label-selectors) +Set `Pod` yang dirujuk oleh suatu `Service` (biasanya) ditentukan oleh sebuah [`Label Selector`](/id/docs/concepts/overview/working-with-objects/labels/#label-selectors) (lihat penjelasan di bawah untuk mengetahui alasan kenapa kamu mungkin saja membutuhkan `Service` tanpa sebuah _selector_). @@ -95,7 +95,7 @@ mereka juga melakukan abstraksi bagi _backend_ lainnya. Misalnya saja: * Kamu ingin memiliki sebuah basis data eksternal di _environment_ _production_ tapi pada tahap _test_, kamu ingin menggunakan basis datamu sendiri. * Kamu ingin merujuk _service_ kamu pada _service_ lainnya yang berada pada - [_Namespace_](/docs/concepts/overview/working-with-objects/namespaces/) yang berbeda atau bahkan klaster yang berbeda. + [_Namespace_](/id/docs/concepts/overview/working-with-objects/namespaces/) yang berbeda atau bahkan klaster yang berbeda. * Kamu melakukan migrasi _workloads_ ke Kubernetes dan beberapa _backend_ yang kamu miliki masih berada di luar klaster Kubernetes. @@ -319,7 +319,7 @@ Meskipun begitu, DNS tidak memiliki keterbatasan ini. ### DNS -Salah satu [_add-on_](/docs/concepts/cluster-administration/addons/) opsional +Salah satu [_add-on_](/id/docs/concepts/cluster-administration/addons/) opsional (meskipun sangat dianjurkan) adalah server DNS. Server DNS bertugas untuk mengamati apakah terdapat objek `Service` baru yang dibuat dan kemudian bertugas menyediakan DNS baru untuk _Service_ tersebut. Jika DNS ini diaktifkan untuk seluruh klaster, maka semua `Pod` akan secara otomatis @@ -338,7 +338,7 @@ nomor _port_ yang digunakan oleh _http_. Server DNS Kubernetes adalah satu-satunya cara untuk mengakses _Service_ dengan tipe `ExternalName`. Informasi lebih lanjut tersedia di -[DNS _Pods_ dan _Services_](/docs/concepts/services-networking/dns-pod-service/). +[DNS _Pods_ dan _Services_](/id/docs/concepts/services-networking/dns-pod-service/). ## `Service` _headless_ @@ -745,10 +745,10 @@ dan tidak akan menerima trafik apa pun. Untuk menghasilkan distribusi trafik yang merata, kamu dapat menggunakan _DaemonSet_ atau melakukan spesifikasi -[pod anti-affinity](/docs/concepts/configuration/assign-pod-node/#inter-pod-affinity-and-anti-affinity-beta-feature) +[pod anti-affinity](/id/docs/concepts/configuration/assign-pod-node/#inter-pod-affinity-and-anti-affinity-beta-feature) agar `Pod` tidak di-_assign_ ke _node_ yang sama. -NLB juga dapat digunakan dengan anotasi [internal load balancer](/docs/concepts/services-networking/service/#internal-load-balancer). +NLB juga dapat digunakan dengan anotasi [internal load balancer](/id/docs/concepts/services-networking/service/#internal-load-balancer). Agar trafik klien berhasil mencapai _instances_ dibelakang ELB, _security group_ dari _node_ akan diberikan _rules_ IP sebagai berikut: @@ -1006,7 +1006,7 @@ alternatif penggunaan `Service` untuk HTTP/HTTPS. {{< feature-state for_k8s_version="v1.1" state="stable" >}} -Apabila penyedia layanan _cloud_ yang kamu gunakan mendukung, (misalnya saja, [AWS](/docs/concepts/cluster-administration/cloud-providers/#aws)), +Apabila penyedia layanan _cloud_ yang kamu gunakan mendukung, (misalnya saja, [AWS](/id/docs/concepts/cluster-administration/cloud-providers/#aws)), _Service_ dengan _type_ `LoadBalancer` untuk melakukan konfigurasi _load balancer_ di luar Kubernetes sendiri, serta akan melakukan _forwarding_ koneksi yang memiliki prefiks [protokol PROXY](https://www.haproxy.org/download/1.8/doc/proxy-protocol.txt). diff --git a/content/id/docs/concepts/storage/dynamic-provisioning.md b/content/id/docs/concepts/storage/dynamic-provisioning.md index ac206dfacd..4b9fa6f35c 100644 --- a/content/id/docs/concepts/storage/dynamic-provisioning.md +++ b/content/id/docs/concepts/storage/dynamic-provisioning.md @@ -8,7 +8,7 @@ weight: 40 Penyediaan volume dinamis memungkinkan volume penyimpanan untuk dibuat sesuai permintaan (_on-demand_). Tanpa adanya penyediaan dinamis (_dynamic provisioning_), untuk membuat volume penyimpanan baru, admin klaster secara manual harus -memanggil penyedia layanan cloud atau layanan penyimpanan, dan kemudian membuat [objek PersistentVolume](/docs/concepts/storage/persistent-volumes/) +memanggil penyedia layanan cloud atau layanan penyimpanan, dan kemudian membuat [objek PersistentVolume](/id/docs/concepts/storage/persistent-volumes/) sebagai representasi di Kubernetes. Fitur penyediaan dinamis menghilangkan kebutuhan admin klaster untuk menyediakan penyimpanan sebelumnya (_pre-provision_). Dengan demikian, penyimpanan akan tersedia secara otomatis ketika diminta oleh pengguna. @@ -32,7 +32,7 @@ kumpulan parameter tertentu. Desain ini memastikan bahwa pengguna tidak perlu kh rumitnya mekanisme penyediaan penyimpanan, tapi tetap memiliki kemampuan untuk memilih berbagai macam pilihan penyimpanan. -Info lebih lanjut mengenai _storage class_ dapat dilihat [di sini](/docs/concepts/storage/storage-classes/). +Info lebih lanjut mengenai _storage class_ dapat dilihat [di sini](/id/docs/concepts/storage/storage-classes/). ## Mengaktifkan Penyediaan Dinamis (_Dynamic Provisioning_) @@ -123,6 +123,6 @@ tidak bisa terbuat. Pada klaster [Multi-Zona](/docs/setup/multiple-zones), Pod dapat tersebar di banyak Zona pada sebuah Region. Penyimpanan dengan *backend* Zona-Tunggal seharusnya disediakan pada Zona-Zona dimana Pod dijalankan. Hal ini dapat dicapai dengan mengatur -[Mode Volume Binding](/docs/concepts/storage/storage-classes/#volume-binding-mode). +[Mode Volume Binding](/id/docs/concepts/storage/storage-classes/#volume-binding-mode). diff --git a/content/id/docs/concepts/storage/persistent-volumes.md b/content/id/docs/concepts/storage/persistent-volumes.md index f75941b86a..51163d36a9 100644 --- a/content/id/docs/concepts/storage/persistent-volumes.md +++ b/content/id/docs/concepts/storage/persistent-volumes.md @@ -11,7 +11,7 @@ weight: 20 <!-- overview --> -Dokumen ini menjelaskan kondisi terkini dari `PersistentVolumes` pada Kubernetes. Disarankan telah memiliki familiaritas dengan [volume](/docs/concepts/storage/volumes/). +Dokumen ini menjelaskan kondisi terkini dari `PersistentVolumes` pada Kubernetes. Disarankan telah memiliki familiaritas dengan [volume](/id/docs/concepts/storage/volumes/). @@ -34,7 +34,7 @@ mode akses, tanpa memaparkan detail-detail bagaimana cara volume tersebut diimpl kepada para pengguna. Untuk mengatasi hal ini maka dibutuhkan sumber daya `StorageClass`. -Silakan lihat [panduan mendetail dengan contoh-contoh yang sudah berjalan](/docs/tasks/configure-pod-container/configure-persistent-volume-storage/). +Silakan lihat [panduan mendetail dengan contoh-contoh yang sudah berjalan](/id/docs/tasks/configure-pod-container/configure-persistent-volume-storage/). ## Siklus hidup dari sebuah volume dan klaim @@ -360,7 +360,7 @@ Pada CLI, mode-mode akses tersebut disingkat menjadi: Sebuah PV bisa memiliki sebuah kelas, yang dispesifikasi dalam pengaturan atribut `storageClassName` menjadi nama -[StorageClass](/docs/concepts/storage/storage-classes/). +[StorageClass](/id/docs/concepts/storage/storage-classes/). Sebuah PV dari kelas tertentu hanya dapat terikat dengan PVC yang meminta kelas tersebut. Sebuah PV tanpa `storageClassName` tidak memiliki kelas dan hanya dapat terikat dengan PVC yang tidak meminta kelas tertentu. @@ -412,7 +412,7 @@ akan dihilangkan sepenuhnya pada rilis Kubernetes mendatang. ### Afinitas Node {{< note >}} -Untuk kebanyakan tipe volume, kamu tidak perlu memasang kolom ini. Kolom ini secara otomatis terisi untuk tipe blok volume [AWS EBS](/docs/concepts/storage/volumes/#awselasticblockstore), [GCE PD](/docs/concepts/storage/volumes/#gcepersistentdisk) dan [Azure Disk](/docs/concepts/storage/volumes/#azuredisk). Kamu harus mengaturnya secara eksplisit untuk volume [lokal](/docs/concepts/storage/volumes/#local). +Untuk kebanyakan tipe volume, kamu tidak perlu memasang kolom ini. Kolom ini secara otomatis terisi untuk tipe blok volume [AWS EBS](/id/docs/concepts/storage/volumes/#awselasticblockstore), [GCE PD](/id/docs/concepts/storage/volumes/#gcepersistentdisk) dan [Azure Disk](/id/docs/concepts/storage/volumes/#azuredisk). Kamu harus mengaturnya secara eksplisit untuk volume [lokal](/id/docs/concepts/storage/volumes/#local). {{< /note >}} Sebuah PV dapat menspesifikasi [afinitas node](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#volumenodeaffinity-v1-core) untuk mendefinisikan batasan yang membatasi _node_ mana saja yang dapat mengakses volume tersebut. _Pod_ yang menggunakan sebuah PV hanya akan bisa dijadwalkan ke _node_ yang dipilih oleh afinitas _node_. @@ -466,7 +466,7 @@ Klaim, seperti _pod_, bisa meminta sumber daya dengan jumlah tertentu. Pada kas ### _Selector_ -Klaim dapat menspesifikasi [_label selector_](/docs/concepts/overview/working-with-objects/labels/#label-selectors) untuk memilih serangkaian volume lebih jauh. Hanya volume yang cocok labelnya dengan _selector_ yang dapat terikat dengan klaim. _Selector_ dapat terdiri dari dua kolom: +Klaim dapat menspesifikasi [_label selector_](/id/docs/concepts/overview/working-with-objects/labels/#label-selectors) untuk memilih serangkaian volume lebih jauh. Hanya volume yang cocok labelnya dengan _selector_ yang dapat terikat dengan klaim. _Selector_ dapat terdiri dari dua kolom: * `matchLabels` - volume harus memiliki label dengan nilai ini * `matchExpressions` - daftar dari persyaratan yang dibuat dengan menentukan kunci, daftar nilai, dan operator yang menghubungkan kunci dengan nilai. Operator yang valid meliputi In, NotIn, Exists, dan DoesNotExist. @@ -476,7 +476,7 @@ Semua persyaratan tersebut, dari `matchLabels` dan `matchExpressions` akan dilak ### Kelas Sebuah klaim dapat meminta kelas tertentu dengan menspesifikasi nama dari -[StorageClass](/docs/concepts/storage/storage-classes/) +[StorageClass](/id/docs/concepts/storage/storage-classes/) menggunakan atribut `storageClassName`. Hanya PV dari kelas yang diminta, yang memiliki `storageClassName` yang sama dengan PVC, yang dapat terikat dengan PVC. @@ -647,7 +647,7 @@ Hanya volume yang disediakan secara statis yang didukung untuk rilis alfa. Admin {{< feature-state for_k8s_version="v1.12" state="alpha" >}} -Fitur _volume snapshot_ ditambahkan hanya untuk mendukung _CSI Volume Plugins_. Untuk lebih detail, lihat [_volume snapshots_](/docs/concepts/storage/volume-snapshots/). +Fitur _volume snapshot_ ditambahkan hanya untuk mendukung _CSI Volume Plugins_. Untuk lebih detail, lihat [_volume snapshots_](/id/docs/concepts/storage/volume-snapshots/). Untuk mengaktifkan dukungan pemulihan sebuah volume dari sebuah sumber data _volume snapshot_, aktifkan gerbang fitur `VolumeSnapshotDataSource` pada apiserver dan _controller-manager_. diff --git a/content/id/docs/concepts/storage/storage-classes.md b/content/id/docs/concepts/storage/storage-classes.md index 6de85830e8..2897399e80 100644 --- a/content/id/docs/concepts/storage/storage-classes.md +++ b/content/id/docs/concepts/storage/storage-classes.md @@ -8,8 +8,8 @@ weight: 30 Dokumen ini mendeskripsikan konsep StorageClass yang ada pada Kubernetes. Sebelum lanjut membaca, sangat dianjurkan untuk memiliki pengetahuan terhadap -[volumes](/docs/concepts/storage/volumes/) dan -[peristent volume](/docs/concepts/storage/persistent-volumes) terlebih dahulu. +[volumes](/id/docs/concepts/storage/volumes/) dan +[peristent volume](/id/docs/concepts/storage/persistent-volumes) terlebih dahulu. @@ -40,7 +40,7 @@ dan objek yang sudah dibuat tidak dapat diubah lagi definisinya. Administrator dapat memberikan spesifikasi StorageClass _default_ bagi PVC yang tidak membutuhkan kelas tertentu untuk dapat melakukan mekanisme _bind_: -kamu dapat membaca [bagian `PersistentVolumeClaim`](/docs/concepts/storage/persistent-volumes/#class-1) +kamu dapat membaca [bagian `PersistentVolumeClaim`](/id/docs/concepts/storage/persistent-volumes/#persistentvolumeclaims) untuk penjelasan lebih lanjut. ```yaml @@ -131,7 +131,7 @@ akan gagal apabila salah satu dari keduanya bersifat invalid. ### Mode Volume _Binding_ _Field_ `volumeBindingMode` mengontrol kapan mekanisme [_binding_ volume dan -_provisioning_ dinamis](/docs/concepts/storage/persistent-volumes/#provisioning) +_provisioning_ dinamis](/id/docs/concepts/storage/persistent-volumes/#provisioning) harus dilakukan. Secara _default_, ketika mode `Immediate` yang mengindikasikan @@ -148,11 +148,11 @@ dan _binding_ dari sebuah PersistentVolume hingga sebuah Pod yang menggunakan PersistentVolumeClaim dibuat. PersistentVolume akan dipilih atau di-_provisioning_ sesuai dengan topologi yang dispesifikasikan oleh limitasi yang diberikan oleh mekanisme _scheduling_ Pod. Hal ini termasuk, tetapi tidak hanya terbatas pada, -[persyaratan sumber daya](/docs/concepts/configuration/manage-compute-resources-container), -[_node selector_](/docs/concepts/configuration/assign-pod-node/#nodeselector), +[persyaratan sumber daya](/id/docs/concepts/configuration/manage-compute-resources-container), +[_node selector_](/id/docs/concepts/configuration/assign-pod-node/#nodeselector), [afinitas dan -anti-afinitas Pod](/docs/concepts/configuration/assign-pod-node/#affinity-and-anti-affinity), -serta [_taint_ dan _toleration_](/docs/concepts/configuration/taint-and-toleration). +anti-afinitas Pod](/id/docs/concepts/configuration/assign-pod-node/#affinity-and-anti-affinity), +serta [_taint_ dan _toleration_](/id/docs/concepts/configuration/taint-and-toleration). Beberapa _plugin_ di bawah ini mendukung `WaitForFirstConsumer` dengan _provisioning_ dinamis: @@ -168,7 +168,7 @@ PersistentVolume yang terlebih dahulu dibuat: * [Lokal](#lokal) {{< feature-state state="beta" for_k8s_version="1.14" >}} -[Volume-volume CSI](/docs/concepts/storage/volumes/#csi) juga didukung +[Volume-volume CSI](/id/docs/concepts/storage/volumes/#csi) juga didukung dengan adanya _provisioning_ dinamis serta PV yang telah terlebih dahulu dibuat, meskipun demikian, akan lebih baik apabila kamu melihat dokumentasi untuk driver spesifik CSI untuk melihat topologi _key_ yang didukung @@ -634,8 +634,8 @@ parameters: di dalam grup sumber daya yang sama dengan klaster, serta `skuName` dan `location` akan diabaikan. Selama _provision_, sebuah secret dibuat untuk menyimpan _credentials_. Jika klaster -menggunakan konsep [RBAC](/docs/reference/access-authn-authz/rbac/) dan -[_Roles_ Controller](/docs/reference/access-authn-authz/rbac/#controller-roles), +menggunakan konsep [RBAC](/id/docs/reference/access-authn-authz/rbac/) dan +[_Roles_ Controller](/id/docs/reference/access-authn-authz/rbac/#controller-roles), menambahkan kapabilitas `create` untuk sumber daya `secret` bagi clusterrole `system:controller:persistent-volume-binder`. diff --git a/content/id/docs/concepts/storage/volume-pvc-datasource.md b/content/id/docs/concepts/storage/volume-pvc-datasource.md index 4a5f5d8c8c..481e74c976 100644 --- a/content/id/docs/concepts/storage/volume-pvc-datasource.md +++ b/content/id/docs/concepts/storage/volume-pvc-datasource.md @@ -7,7 +7,7 @@ weight: 30 <!-- overview --> {{< feature-state for_k8s_version="v1.16" state="beta" >}} -Dokumen ini mendeskripsikan konsep pengklonaan Volume CSI yang telah tersedia di dalam Kubernetes. Pengetahuan tentang [Volume](/docs/concepts/storage/volumes) disarankan. +Dokumen ini mendeskripsikan konsep pengklonaan Volume CSI yang telah tersedia di dalam Kubernetes. Pengetahuan tentang [Volume](/id/docs/concepts/storage/volumes) disarankan. diff --git a/content/id/docs/concepts/storage/volume-snapshot-classes.md b/content/id/docs/concepts/storage/volume-snapshot-classes.md index 0414a9d7de..fff7de9baa 100644 --- a/content/id/docs/concepts/storage/volume-snapshot-classes.md +++ b/content/id/docs/concepts/storage/volume-snapshot-classes.md @@ -7,8 +7,8 @@ weight: 30 <!-- overview --> Laman ini menjelaskan tentang konsep VolumeSnapshotClass pada Kubernetes. Sebelum melanjutkan, -sangat disarankan untuk membaca [_snapshot_ volume](/docs/concepts/storage/volume-snapshots/) -dan [kelas penyimpanan (_storage class_)](/docs/concepts/storage/storage-classes) terlebih dahulu. +sangat disarankan untuk membaca [_snapshot_ volume](/id/docs/concepts/storage/volume-snapshots/) +dan [kelas penyimpanan (_storage class_)](/id/docs/concepts/storage/storage-classes) terlebih dahulu. diff --git a/content/id/docs/concepts/storage/volume-snapshots.md b/content/id/docs/concepts/storage/volume-snapshots.md index 39ab3d31aa..5ddfc2aaa6 100644 --- a/content/id/docs/concepts/storage/volume-snapshots.md +++ b/content/id/docs/concepts/storage/volume-snapshots.md @@ -7,7 +7,7 @@ weight: 20 <!-- overview --> {{< feature-state for_k8s_version="v1.12" state="alpha" >}} -Laman ini menjelaskan tentang fitur VolumeSnapshot pada Kubernetes. Sebelum lanjut membaca, sangat disarankan untuk memahami [PersistentVolume](/docs/concepts/storage/persistent-volumes/) terlebih dahulu. +Laman ini menjelaskan tentang fitur VolumeSnapshot pada Kubernetes. Sebelum lanjut membaca, sangat disarankan untuk memahami [PersistentVolume](/id/docs/concepts/storage/persistent-volumes/) terlebih dahulu. @@ -48,7 +48,7 @@ Seorang adminstrator klaster membuat beberapa VolumeSnapshotContent, yang masing #### Dinamis Ketika VolumeSnapshotContent yang dibuat oleh administrator tidak ada yang sesuai dengan VolumeSnapshot yang dibuat pengguna, klaster bisa saja mencoba untuk menyediakan sebuah VolumeSnapshot secara dinamis, khususnya untuk objek VolumeSnapshot. -Proses penyediaan ini berdasarkan VolumeSnapshotClasses: VolumeSnapshot harus meminta sebuah [VolumeSnapshotClass](/docs/concepts/storage/volume-snapshot-classes/) +Proses penyediaan ini berdasarkan VolumeSnapshotClasses: VolumeSnapshot harus meminta sebuah [VolumeSnapshotClass](/id/docs/concepts/storage/volume-snapshot-classes/) dan administrator harus membuat serta mengatur _class_ tersebut supaya penyediaan dinamis bisa terjadi. ### Ikatan (_Binding_) @@ -93,7 +93,7 @@ spec: ### _Class_ Suatu VolumeSnapshotContent dapat memiliki suatu _class_, yang didapat dengan mengatur atribut -`snapshotClassName` dengan nama dari [VolumeSnapshotClass](/docs/concepts/storage/volume-snapshot-classes/). +`snapshotClassName` dengan nama dari [VolumeSnapshotClass](/id/docs/concepts/storage/volume-snapshot-classes/). VolumeSnapshotContent dari _class_ tertentu hanya dapat terikat (_bound_) dengan VolumeSnapshot yang "meminta" _class_ tersebut. VolumeSnapshotContent tanpa `snapshotClassName` tidak memiliki _class_ dan hanya dapat terikat (_bound_) dengan VolumeSnapshot yang "meminta" untuk tidak menggunakan _class_. @@ -117,7 +117,7 @@ spec: ### _Class_ Suatu VolumeSnapshot dapat meminta sebuah _class_ tertentu dengan mengatur nama dari -[VolumeSnapshotClass](/docs/concepts/storage/volume-snapshot-classes/) +[VolumeSnapshotClass](/id/docs/concepts/storage/volume-snapshot-classes/) menggunakan atribut `snapshotClassName`. Hanya VolumeSnapshotContent dari _class_ yang diminta, memiliki `snapshotClassName` yang sama dengan VolumeSnapshot, dapat terikat (_bound_) dengan VolumeSnapshot tersebut. @@ -127,6 +127,6 @@ dengan VolumeSnapshot, dapat terikat (_bound_) dengan VolumeSnapshot tersebut. Kamu dapat menyediakan sebuah volume baru, yang telah terisi dengan data dari suatu _snapshot_, dengan menggunakan _field_ `dataSource` pada objek PersistentVolumeClaim. -Untuk detailnya bisa dilihat pada [VolumeSnapshot and Mengembalikan Volume dari _Snapshot_](/docs/concepts/storage/persistent-volumes/#volume-snapshot-and-restore-volume-from-snapshot-support). +Untuk detailnya bisa dilihat pada [VolumeSnapshot and Mengembalikan Volume dari _Snapshot_](/id/docs/concepts/storage/persistent-volumes/#volume-snapshot-and-restore-volume-from-snapshot-support). diff --git a/content/id/docs/concepts/storage/volumes.md b/content/id/docs/concepts/storage/volumes.md index 679de8c865..8d593f1eba 100644 --- a/content/id/docs/concepts/storage/volumes.md +++ b/content/id/docs/concepts/storage/volumes.md @@ -185,7 +185,7 @@ Pada saat fitur migrasi CSI untuk Cinder diaktifkan, fitur ini akan menterjemahk ### configMap {#configmap} -Sumber daya [`configMap`](/docs/tasks/configure-pod-container/configure-pod-configmap/) memungkinkan kamu untuk menyuntikkan data konfigurasi ke dalam Pod. +Sumber daya [`configMap`](/id/docs/tasks/configure-pod-container/configure-pod-configmap/) memungkinkan kamu untuk menyuntikkan data konfigurasi ke dalam Pod. Data yang ditaruh di dalam sebuah objek `ConfigMap` dapat dirujuk dalam sebuah Volume dengan tipe `configMap` dan kemudian digunakan oleh aplikasi/container yang berjalan di dalam sebuah Pod. Saat mereferensikan sebuah objek `configMap`, kamu tinggal memasukkan nama ConfigMap tersebut ke dalam rincian Volume yang bersangkutan. Kamu juga dapat mengganti _path_ spesifik yang akan digunakan pada ConfigMap. Misalnya, untuk menambatkan ConfigMap `log-config` pada Pod yang diberi nama `configmap-pod`, kamu dapat menggunakan YAML ini: @@ -215,7 +215,7 @@ ConfigMap `log-config` ditambatkan sebagai sebuah Volume, dan semua isinya yang Perlu dicatat bahwa _path_ tersebut berasal dari isian `mountPath` pada Volume, dan `path` yang ditunjuk dengan `key` bernama `log_level`. {{< caution >}} -Kamu harus membuat sebuah [ConfigMap](/docs/tasks/configure-pod-container/configure-pod-configmap/) sebelum kamu dapat menggunakannya. +Kamu harus membuat sebuah [ConfigMap](/id/docs/tasks/configure-pod-container/configure-pod-configmap/) sebelum kamu dapat menggunakannya. {{< /caution >}} {{< note >}} @@ -346,7 +346,7 @@ Fitur [Regional Persistent Disks](https://cloud.google.com/compute/docs/disks/#r #### Menyediakan sebuah Regional PD PersistentVolume Secara Manual -Penyediaan secara dinamis mungkin dilakukan dengan sebuah [StorageClass untuk GCE PD](/docs/concepts/storage/storage-classes/#gce). +Penyediaan secara dinamis mungkin dilakukan dengan sebuah [StorageClass untuk GCE PD](/id/docs/concepts/storage/storage-classes/#gce). Sebelum membuat sebuah PersistentVolume, kamu harus membuat PD-nya: ```shell @@ -533,7 +533,7 @@ Kolom `nodeAffinity` ada PersistentVolue dibutuhkan saat menggunakan Volume `loc Kolom `volumeMode` pada PersistentVolume sekarang dapat disetel menjadi "Block" (menggantikan nilai bawaan "Filesystem") untuk membuka Volume `local` tersebut sebagai media penyimpanan blok mentah. Hal ini membutuhkan diaktifkannya _Alpha feature gate_ `BlockVolume`. -Saat menggunakan Volume `local`, disarankan untuk membuat sebuah StorageClass dengan `volumeBindingMode` yang disetel menjadi `WaitForFirstConsumer`. Lihat[contohnya](/docs/concepts/storage/storage-classes/#local). Menunda pengikatan Volume memastikan bahwa keputusan pengikatan PersistentVolumeClaim juga akan dievaluasi terhadap batasan-batasan Node yang berlaku pada Pod, seperti kebutuhan sumber daya Node, `nodeSelector`, `podAffinity`, dan `podAntiAffinity`. +Saat menggunakan Volume `local`, disarankan untuk membuat sebuah StorageClass dengan `volumeBindingMode` yang disetel menjadi `WaitForFirstConsumer`. Lihat[contohnya](/id/docs/concepts/storage/storage-classes/#local). Menunda pengikatan Volume memastikan bahwa keputusan pengikatan PersistentVolumeClaim juga akan dievaluasi terhadap batasan-batasan Node yang berlaku pada Pod, seperti kebutuhan sumber daya Node, `nodeSelector`, `podAffinity`, dan `podAntiAffinity`. Sebuah penyedia statis eksternal dapat berjalan secara terpisah untuk memperbaik pengaturan siklus hidup Volume `local`. Perlu dicatat bahwa penyedia ini belum mendukung _dynamic provisioning_. Untuk contoh bagaimana menjalankan penyedia Volume `local` eksternal, lihat [petunjuk penggunaannya](https://github.com/kubernetes-sigs/sig-storage-local-static-provisioner). @@ -554,9 +554,9 @@ Lihat [contoh NFS](https://github.com/kubernetes/examples/tree/{{< param "github ### persistentVolumeClaim {#persistentvolumeclaim} -Sebuah Volume `persistentVolumeClaim` digunakan untuk menambatkan sebuah [PersistentVolume](/docs/concepts/storage/persistent-volumes/) ke dalam sebuag Pod. PersistentVolume adalah sebuah cara bagi pengguna untuk "mengklaim" penyimpanan yang _durable_ (seperti sebuah GCE PD atau sebuah volume iSCSI) tanpa mengetahui detil lingkungan _cloud_ yang bersangkutan. +Sebuah Volume `persistentVolumeClaim` digunakan untuk menambatkan sebuah [PersistentVolume](/id/docs/concepts/storage/persistent-volumes/) ke dalam sebuag Pod. PersistentVolume adalah sebuah cara bagi pengguna untuk "mengklaim" penyimpanan yang _durable_ (seperti sebuah GCE PD atau sebuah volume iSCSI) tanpa mengetahui detil lingkungan _cloud_ yang bersangkutan. -Lihat [contoh PersistentVolumes](/docs/concepts/storage/persistent-volumes/) untuk lebih lanjut. +Lihat [contoh PersistentVolumes](/id/docs/concepts/storage/persistent-volumes/) untuk lebih lanjut. ### projected {#projected} @@ -742,7 +742,7 @@ Lihat [contoh RBD](https://github.com/kubernetes/examples/tree/{{< param "github ### scaleIO {#scaleio} -ScaleIO adalah _platform_ penyimpanan berbasis perangkat lunak yang dapat menggunakan perangkat keras yang sudah tersedia untuk membuat klaster-klaster media penyimpanan terhubung jaringan yang _scalable_. _Plugin_ Volume `scaleIO` memungkinkan Pod-pod yang di-_deploy_ untuk mengakses Volume-volume ScaleIO yang telah tersedia (atau dapat menyediakan volume-volume untuk PersistentVolumeClaim secara dinamis, lihat [Persistent Volume ScaleIO](/docs/concepts/storage/persistent-volumes/#scaleio)). +ScaleIO adalah _platform_ penyimpanan berbasis perangkat lunak yang dapat menggunakan perangkat keras yang sudah tersedia untuk membuat klaster-klaster media penyimpanan terhubung jaringan yang _scalable_. _Plugin_ Volume `scaleIO` memungkinkan Pod-pod yang di-_deploy_ untuk mengakses Volume-volume ScaleIO yang telah tersedia (atau dapat menyediakan volume-volume untuk PersistentVolumeClaim secara dinamis, lihat [Persistent Volume ScaleIO](/id/docs/concepts/storage/persistent-volumes/#scaleio)). {{< caution >}} Kamu harus memiliki klaster ScaleIO yang berjalan dengan volume-volume yang sudah dibuat sebelum kamu dapat menggunakannya. @@ -1033,7 +1033,7 @@ Dimulai pada versi 1.11, CSI memperkenalkan dukungak untuk volume blok _raw_, ya Dukungan untuk volume blok CSI bersifat _feature-gate_, tapi secara bawaan diaktifkan. Kedua _feature-gate_ yang harus diaktifkan adalah `BlockVolume` dan `CSIBlockVolume`. -Pelajari cara [menyiapkan PV/PVC dengan dukungan volume blok _raw_](/docs/concepts/storage/persistent-volumes/#raw-block-volume-support). +Pelajari cara [menyiapkan PV/PVC dengan dukungan volume blok _raw_](/id/docs/concepts/storage/persistent-volumes/#raw-block-volume-support). #### Volume CSI Sementara diff --git a/content/id/docs/concepts/workloads/controllers/cron-jobs.md b/content/id/docs/concepts/workloads/controllers/cron-jobs.md index 29fde331ea..ca5df2d86d 100644 --- a/content/id/docs/concepts/workloads/controllers/cron-jobs.md +++ b/content/id/docs/concepts/workloads/controllers/cron-jobs.md @@ -6,7 +6,7 @@ weight: 80 <!-- overview --> -Suatu CronJob menciptakan [Job](/docs/concepts/workloads/controllers/jobs-run-to-completion/) yang dijadwalkan berdasarkan waktu tertentu. +Suatu CronJob menciptakan [Job](/id/docs/concepts/workloads/controllers/jobs-run-to-completion/) yang dijadwalkan berdasarkan waktu tertentu. Satu objek CronJob sepadan dengan satu baris pada _file_ _crontab_ (_cron table_). CronJob tersebut menjalankan suatu pekerjaan secara berkala pada waktu tertentu, dituliskan dalam format [Cron](https://en.wikipedia.org/wiki/Cron). @@ -15,7 +15,7 @@ pada waktu tertentu, dituliskan dalam format [Cron](https://en.wikipedia.org/wik Seluruh waktu `schedule:` pada _**CronJob**_ mengikuti zona waktu dari _master_ di mana Job diinisiasi. {{< /note >}} -Untuk panduan dalam berkreasi dengan _cron job_, dan contoh _spec file_ untuk suatu _cron job_, lihat [Menjalankan otomasi _task_ dengan _cron job_](/docs/tasks/job/automated-tasks-with-cron-jobs). +Untuk panduan dalam berkreasi dengan _cron job_, dan contoh _spec file_ untuk suatu _cron job_, lihat [Menjalankan otomasi _task_ dengan _cron job_](/id/docs/tasks/job/automated-tasks-with-cron-jobs). diff --git a/content/id/docs/concepts/workloads/controllers/daemonset.md b/content/id/docs/concepts/workloads/controllers/daemonset.md index baa79aa3f2..0b1c0e71e9 100644 --- a/content/id/docs/concepts/workloads/controllers/daemonset.md +++ b/content/id/docs/concepts/workloads/controllers/daemonset.md @@ -48,7 +48,7 @@ kubectl apply -f https://k8s.io/examples/controllers/daemonset.yaml Seperti semua konfigurasi Kubernetes lainnya, DaemonSet membutuhkan _field_ `apiVersion`, `kind`, dan `metadata`. Untuk informasi umum tentang berkas konfigurasi, lihat dokumen [men-_deploy_ aplikasi](/docs/user-guide/deploying-applications/), -[pengaturan kontainer](/docs/tasks/), dan [pengelolaan objek dengan kubectl](/docs/concepts/overview/working-with-objects/object-management/). +[pengaturan kontainer](/docs/tasks/), dan [pengelolaan objek dengan kubectl](/id/docs/concepts/overview/working-with-objects/object-management/). DaemonSet juga membutuhkan bagian [`.spec`](https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status). @@ -61,7 +61,7 @@ DaemonSet juga membutuhkan bagian [`.spec`](https://git.k8s.io/community/contrib Selain _field_ wajib untuk Pod, templat Pod di DaemonSet harus menspesifikasikan label yang sesuai (lihat [selektor Pod](#selektor-pod)). -Templat Pod di DaemonSet harus memiliki [`RestartPolicy`](/docs/concepts/workloads/pods/pod-lifecycle/#restart-policy) +Templat Pod di DaemonSet harus memiliki [`RestartPolicy`](/id/docs/concepts/workloads/pods/pod-lifecycle/#restart-policy) yang bernilai `Always`, atau tidak dispesifikasikan, sehingga _default_ menjadi `Always`. DaemonSet dengan nilai `Always` membuat Pod akan selalu di-_restart_ saat kontainer keluar/berhenti atau terjadi _crash_. @@ -77,7 +77,7 @@ Mengubah selektor Pod dapat menyebabkan Pod _orphan_ yang tidak disengaja, dan m Objek `.spec.selector` memiliki dua _field_: -* `matchLabels` - bekerja seperti `.spec.selector` pada [ReplicationController](/docs/concepts/workloads/controllers/replicationcontroller/). +* `matchLabels` - bekerja seperti `.spec.selector` pada [ReplicationController](/id/docs/concepts/workloads/controllers/replicationcontroller/). * `matchExpressions` - bisa digunakan untuk membuat selektor yang lebih canggih dengan mendefinisikan _key_, daftar _value_ dan operator yang menyatakan hubungan antara _key_ dan _value_. @@ -97,8 +97,8 @@ membuat Pod dengan nilai yang berbeda di sebuah Node untuk _testing_. Jika kamu menspesifikasikan `.spec.template.spec.nodeSelector`, maka _controller_ DaemonSet akan membuat Pod pada Node yang cocok dengan [selektor -Node](/docs/concepts/configuration/assign-pod-node/). Demikian juga, jika kamu menspesifikasikan `.spec.template.spec.affinity`, -maka _controller_ DaemonSet akan membuat Pod pada Node yang cocok dengan [Node affinity](/docs/concepts/configuration/assign-pod-node/). +Node](/id/docs/concepts/configuration/assign-pod-node/). Demikian juga, jika kamu menspesifikasikan `.spec.template.spec.affinity`, +maka _controller_ DaemonSet akan membuat Pod pada Node yang cocok dengan [Node affinity](/id/docs/concepts/configuration/assign-pod-node/). Jika kamu tidak menspesifikasikan sama sekali, maka _controller_ DaemonSet akan membuat Pod pada semua Node. @@ -116,7 +116,7 @@ mendatangkan masalah-masalah berikut: * Inkonsistensi perilaku Pod: Pod normal yang menunggu dijadwalkan akan dibuat dalam keadaan `Pending`, tapi Pod DaemonSet tidak seperti itu. Ini membingungkan untuk pengguna. - * [Pod preemption](/docs/concepts/configuration/pod-priority-preemption/) + * [Pod preemption](/id/docs/concepts/configuration/pod-priority-preemption/) ditangani oleh _default scheduler_. Ketika _preemption_ dinyalakan, _controller_ DaemonSet akan membuat keputusan penjadwalan tanpa memperhitungkan prioritas Pod dan _preemption_. @@ -148,7 +148,7 @@ mengabaikan Node `unschedulable` ketika menjadwalkan Pod DaemonSet. ### _Taint_ dan _Toleration_ Meskipun Pod Daemon menghormati -[taint dan toleration](/docs/concepts/configuration/taint-and-toleration), +[taint dan toleration](/id/docs/concepts/configuration/taint-and-toleration), _toleration_ berikut ini akan otomatis ditambahkan ke Pod DaemonSet sesuai dengan fitur yang bersangkutan. @@ -170,7 +170,7 @@ Beberapa pola yang mungkin digunakan untuk berkomunikasi dengan Pod dalam Daemon - **Push**: Pod dalam DaemonSet diatur untuk mengirim pembaruan status ke servis lain, contohnya _stats database_. Pod ini tidak memiliki klien. - **IP Node dan Konvensi Port**: Pod dalam DaemonSet dapat menggunakan `hostPort`, sehingga Pod dapat diakses menggunakan IP Node. Klien tahu daftar IP Node dengan suatu cara, dan tahu port berdasarkan konvensi. -- **DNS**: Buat [headless service](/docs/concepts/services-networking/service/#headless-services) dengan Pod selektor yang sama, +- **DNS**: Buat [headless service](/id/docs/concepts/services-networking/service/#headless-services) dengan Pod selektor yang sama, dan temukan DaemonSet menggunakan _resource_ `endpoints` atau mengambil beberapa A _record_ dari DNS. - **Service**: Buat Servis dengan Pod selektor yang sama, dan gunakan Servis untuk mengakses _daemon_ pada Node random. (Tidak ada cara mengakses spesifik Node) @@ -223,7 +223,7 @@ _bootstrapping_ klaster. ### Deployment -DaemonSet mirip dengan [Deployment](/docs/concepts/workloads/controllers/deployment/) sebab mereka +DaemonSet mirip dengan [Deployment](/id/docs/concepts/workloads/controllers/deployment/) sebab mereka sama-sama membuat Pod, dan Pod yang mereka buat punya proses yang seharusnya tidak berhenti (e.g. peladen web, peladen penyimpanan) diff --git a/content/id/docs/concepts/workloads/controllers/deployment.md b/content/id/docs/concepts/workloads/controllers/deployment.md index 045c04e59b..8eae6c579f 100644 --- a/content/id/docs/concepts/workloads/controllers/deployment.md +++ b/content/id/docs/concepts/workloads/controllers/deployment.md @@ -51,14 +51,14 @@ Dalam contoh ini: Dalam kasus ini, kamu hanya perlu memilih sebuah label yang didefinisikan pada templat Pod (`app: nginx`). Namun, aturan pemilihan yang lebih canggih mungkin dilakukan asal templat Pod-nya memenuhi aturan. {{< note >}} - Kolom `matchLabels` berbentuk pasangan {key,value}. Sebuah {key,value} dalam _map_ `matchLabels` ekuivalen dengan + Kolom `matchLabels` berbentuk pasangan {key,value}. Sebuah {key,value} dalam _map_ `matchLabels` ekuivalen dengan elemen pada `matchExpressions`, yang mana kolom key adalah "key", operator adalah "In", dan larik values hanya berisi "value". Semua prasyarat dari `matchLabels` maupun `matchExpressions` harus dipenuhi agar dapat dicocokkan. {{< /note >}} * Kolom `template` berisi sub kolom berikut: * Pod dilabeli `app: nginx` dengan kolom `labels`. - * Spesifikasi templat Pod atau kolom `.template.spec` menandakan bahwa Pod mennjalankan satu kontainer `nginx`, + * Spesifikasi templat Pod atau kolom `.template.spec` menandakan bahwa Pod mennjalankan satu kontainer `nginx`, yang menjalankan image `nginx` [Docker Hub](https://hub.docker.com/) dengan versi 1.7.9. * Membuat satu kontainer bernama `nginx` sesuai kolom `name`. @@ -123,8 +123,8 @@ Dalam contoh ini: ReplicaSet yang dibuat menjamin bahwa ada tiga Pod `nginx`. {{< note >}} - Kamu harus memasukkan selektor dan label templat Pod yang benar pada Deployment (dalam kasus ini, `app: nginx`). - Jangan membuat label atau selektor yang beririsan dengan kontroler lain (termasuk Deployment dan StatefulSet lainnya). Kubernetes tidak akan mencegah adanya label yang beririsan. + Kamu harus memasukkan selektor dan label templat Pod yang benar pada Deployment (dalam kasus ini, `app: nginx`). + Jangan membuat label atau selektor yang beririsan dengan kontroler lain (termasuk Deployment dan StatefulSet lainnya). Kubernetes tidak akan mencegah adanya label yang beririsan. Namun, jika beberapa kontroler memiliki selektor yang beririsan, kontroler itu mungkin akan konflik dan berjalan dengan tidak semestinya. {{< /note >}} @@ -144,7 +144,7 @@ Label ini menjamin anak-anak ReplicaSet milik Deployment tidak tumpang tindih. D Rilis Deployment hanya dapat dipicu oleh perubahan templat Pod Deployment (yaitu, `.spec.template`), contohnya perubahan kolom label atau image container. Yang lain, seperti replika, tidak akan memicu rilis. {{< /note >}} -Ikuti langkah-langkah berikut untuk membarui Deployment: +Ikuti langkah-langkah berikut untuk membarui Deployment: 1. Ganti Pod nginx menjadi image `nginx:1.9.1` dari image `nginx:1.7.9`. @@ -191,7 +191,7 @@ Untuk menampilkan detail lain dari Deployment yang terbaru: nginx-deployment 3 3 3 3 36s ``` -* Jalankan `kubectl get rs` to see that the Deployment updated the Pods dengan membuat ReplicaSet baru dan +* Jalankan `kubectl get rs` to see that the Deployment updated the Pods dengan membuat ReplicaSet baru dan menggandakannya menjadi 3 replika, sembari menghapus ReplicaSet menjadi 0 replika. ```shell @@ -228,7 +228,7 @@ menggandakannya menjadi 3 replika, sembari menghapus ReplicaSet menjadi 0 replik Umumnya, dia memastikan paling banyak ada 125% jumlah Pod yang diinginkan menyala (25% tambahan maksimal). Misalnya, jika kamu lihat Deployment diatas lebih jauh, kamu akan melihat bahwa pertama-tama dia membuat Pod baru, - kemudian menghapus beberapa Pod lama, dan membuat yang baru. Dia tidak akan menghapus Pod lama sampai ada cukup + kemudian menghapus beberapa Pod lama, dan membuat yang baru. Dia tidak akan menghapus Pod lama sampai ada cukup Pod baru menyala, dan pula tidak membuat Pod baru sampai ada cukup Pod lama telah mati. Dia memastikan paling sedikit 2 Pod menyala dan paling banyak total 4 Pod menyala. @@ -236,7 +236,7 @@ menggandakannya menjadi 3 replika, sembari menghapus ReplicaSet menjadi 0 replik ```shell kubectl describe deployments ``` - Keluaran akan tampil seperti berikut: + Keluaran akan tampil seperti berikut: ``` Name: nginx-deployment Namespace: default @@ -277,15 +277,15 @@ menggandakannya menjadi 3 replika, sembari menghapus ReplicaSet menjadi 0 replik ``` Disini bisa dilihat ketika pertama Deployment dibuat, dia membuat ReplicaSet (nginx-deployment-2035384211) dan langsung menggandakannya menjadi 3 replika. Saat Deployment diperbarui, dia membuat ReplicaSet baru - (nginx-deployment-1564180365) dan menambah 1 replika kemudian mengecilkan ReplicaSet lama menjadi 2, + (nginx-deployment-1564180365) dan menambah 1 replika kemudian mengecilkan ReplicaSet lama menjadi 2, sehingga paling sedikit 2 Pod menyala dan paling banyak 4 Pod dibuat setiap saat. Dia kemudian lanjut menaik-turunkan - ReplicaSet baru dan ReplicaSet lama, dengan strategi pembaruan rolling yang sama. + ReplicaSet baru dan ReplicaSet lama, dengan strategi pembaruan rolling yang sama. Terakhir, kamu akan dapat 3 replika di ReplicaSet baru telah menyala, dan ReplicaSet lama akan hilang (berisi 0). ### Perpanjangan (alias banyak pembaruan secara langsung) -Setiap kali Deployment baru is teramati oleh Deployment kontroler, ReplicaSet dibuat untuk membangkitkan Pod sesuai keinginan. -Jika Deployment diperbarui, ReplicaSet yang terkait Pod dengan label `.spec.selector` yang cocok, +Setiap kali Deployment baru is teramati oleh Deployment kontroler, ReplicaSet dibuat untuk membangkitkan Pod sesuai keinginan. +Jika Deployment diperbarui, ReplicaSet yang terkait Pod dengan label `.spec.selector` yang cocok, namun kolom `.spec.template` pada templat tidak cocok akan dihapus. Kemudian, ReplicaSet baru akan digandakan sebanyak `.spec.replicas` dan semua ReplicaSet lama dihapus. @@ -294,7 +294,7 @@ tiap perubahan dan memulai penggandaan. Lalu, dia akan mengganti ReplicaSet yang -- mereka ditambahkan ke dalam daftar ReplicaSet lama dan akan mulai dihapus. Contohnya, ketika kamu membuat Deployment untuk membangkitkan 5 replika `nginx:1.7.9`, -kemudian membarui Deployment dengan versi `nginx:1.9.1` ketika ada 3 replika `nginx:1.7.9` yang dibuat. +kemudian membarui Deployment dengan versi `nginx:1.9.1` ketika ada 3 replika `nginx:1.7.9` yang dibuat. Dalam kasus ini, Deployment akan segera menghapus 3 replika Pod `nginx:1.7.9` yang telah dibuat, dan mulai membuat Pod `nginx:1.9.1`. Dia tidak akan menunggu kelima replika `nginx:1.7.9` selesai baru menjalankan perubahan. @@ -310,8 +310,8 @@ Pada versi API `apps/v1`, selektor label Deployment tidak bisa diubah ketika sel * Penambahan selektor mensyaratkan label templat Pod di spek Deployment untuk diganti dengan label baru juga. Jika tidak, galat validasi akan muncul. Perubahan haruslah tidak tumpang-tindih, dengan kata lain selektor baru tidak mencakup ReplicaSet dan Pod yang dibuat dengan selektor lama. Sehingga, semua ReplicaSet lama akan menggantung sedangkan ReplicaSet baru tetap dibuat. * Pengubahan selektor mengubah nilai pada kunci selektor -- menghasilkan perilaku yang sama dengan penambahan. -* Penghapusan selektor menghilangkan kunci yang ada pada selektor Deployment -- tidak mensyaratkan perubahan apapun pada label templat Pod. -ReplicaSet yang ada tidak menggantung dan ReplicaSet baru tidak dibuat. +* Penghapusan selektor menghilangkan kunci yang ada pada selektor Deployment -- tidak mensyaratkan perubahan apapun pada label templat Pod. +ReplicaSet yang ada tidak menggantung dan ReplicaSet baru tidak dibuat. Tapi perhatikan bahwa label yang dihapus masih ada pada Pod dan ReplicaSet masing-masing. ## Membalikkan Deployment @@ -321,10 +321,10 @@ Umumnya, semua riwayat rilis Deployment disimpan oleh sistem sehingga kamu dapat (kamu dapat mengubahnya dengan mengubah batas riwayat revisi). {{< note >}} -Revisi Deployment dibuat saat rilis Deployment dipicu. Ini berarti revisi baru dibuat jika dan hanya jika -templat Pod Deployment (`.spec.template`) berubah, misalnya jika kamu membarui label atau image kontainer pada templat. -Pembaruan lain, seperti penggantian skala Deployment, tidak membuat revisi Deployment, jadi kamu dapat memfasilitasi -penggantian skala secara manual atau otomatis secara simultan. Artinya saat kamu membalikkan ke versi sebelumnya, +Revisi Deployment dibuat saat rilis Deployment dipicu. Ini berarti revisi baru dibuat jika dan hanya jika +templat Pod Deployment (`.spec.template`) berubah, misalnya jika kamu membarui label atau image kontainer pada templat. +Pembaruan lain, seperti penggantian skala Deployment, tidak membuat revisi Deployment, jadi kamu dapat memfasilitasi +penggantian skala secara manual atau otomatis secara simultan. Artinya saat kamu membalikkan ke versi sebelumnya, hanya bagian templat Pod Deployment yang dibalikkan. {{< /note >}} @@ -350,7 +350,7 @@ hanya bagian templat Pod Deployment yang dibalikkan. Waiting for rollout to finish: 1 out of 3 new replicas have been updated... ``` -* Tekan Ctrl-C untuk menghentikan pemeriksaan status rilis di atas. Untuk info lebih lanjut +* Tekan Ctrl-C untuk menghentikan pemeriksaan status rilis di atas. Untuk info lebih lanjut tentang rilis tersendat, [baca disini](#status-deployment). * Kamu lihat bahwa jumlah replika lama (`nginx-deployment-1564180365` dan `nginx-deployment-2035384211`) adalah 2, dan replika baru (nginx-deployment-3066724191) adalah 1. @@ -383,17 +383,17 @@ tentang rilis tersendat, [baca disini](#status-deployment). ``` {{< note >}} - Controller Deployment menghentikan rilis yang buruk secara otomatis dan juga berhenti meningkatkan ReplicaSet baru. + Controller Deployment menghentikan rilis yang buruk secara otomatis dan juga berhenti meningkatkan ReplicaSet baru. Ini tergantung pada parameter rollingUpdate (secara khusus `maxUnavailable`) yang dimasukkan. Kubernetes umumnya mengatur jumlahnya menjadi 25%. {{< /note >}} -* Tampilkan deskripsi Deployment: +* Tampilkan deskripsi Deployment: ```shell kubectl describe deployment ``` - Keluaran akan tampil seperti berikut: + Keluaran akan tampil seperti berikut: ``` Name: nginx-deployment Namespace: default @@ -440,11 +440,11 @@ tentang rilis tersendat, [baca disini](#status-deployment). Ikuti langkah-langkah berikut untuk mengecek riwayat rilis: -1. Pertama, cek revisi Deployment sekarang: +1. Pertama, cek revisi Deployment sekarang: ```shell kubectl rollout history deployment.v1.apps/nginx-deployment ``` - Keluaran akan tampil seperti berikut: + Keluaran akan tampil seperti berikut: ``` deployments "nginx-deployment" REVISION CHANGE-CAUSE @@ -464,7 +464,7 @@ Ikuti langkah-langkah berikut untuk mengecek riwayat rilis: kubectl rollout history deployment.v1.apps/nginx-deployment --revision=2 ``` - Keluaran akan tampil seperti berikut: + Keluaran akan tampil seperti berikut: ``` deployments "nginx-deployment" revision 2 Labels: app=nginx @@ -489,7 +489,7 @@ Ikuti langkah-langkah berikut untuk membalikkan Deployment dari versi sekarang k kubectl rollout undo deployment.v1.apps/nginx-deployment ``` - Keluaran akan tampil seperti berikut: + Keluaran akan tampil seperti berikut: ``` deployment.apps/nginx-deployment ``` @@ -499,7 +499,7 @@ Ikuti langkah-langkah berikut untuk membalikkan Deployment dari versi sekarang k kubectl rollout undo deployment.v1.apps/nginx-deployment --to-revision=2 ``` - Keluaran akan tampil seperti berikut: + Keluaran akan tampil seperti berikut: ``` deployment.apps/nginx-deployment ``` @@ -514,16 +514,16 @@ Ikuti langkah-langkah berikut untuk membalikkan Deployment dari versi sekarang k kubectl get deployment nginx-deployment ``` - Keluaran akan tampil seperti berikut: + Keluaran akan tampil seperti berikut: ``` NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE nginx-deployment 3 3 3 3 30m ``` -3. Tampilkan deskripsi Deployment: +3. Tampilkan deskripsi Deployment: ```shell kubectl describe deployment nginx-deployment ``` - Keluaran akan tampil seperti berikut: + Keluaran akan tampil seperti berikut: ``` Name: nginx-deployment Namespace: default @@ -594,9 +594,9 @@ deployment.apps/nginx-deployment scaled ### Pengaturan skala proporsional -Deployment RollingUpdate mendukung beberapa versi aplikasi berjalan secara bersamaan. Ketika kamu atau autoscaler -mengubah skala Deployment RollingUpdate yang ada di tengah rilis (yang sedang berjalan maupun terjeda), -kontroler Deployment menyeimbangkan replika tambahan dalam ReplicaSet aktif (ReplicaSet dengan Pod) untuk mencegah resiko. +Deployment RollingUpdate mendukung beberapa versi aplikasi berjalan secara bersamaan. Ketika kamu atau autoscaler +mengubah skala Deployment RollingUpdate yang ada di tengah rilis (yang sedang berjalan maupun terjeda), +kontroler Deployment menyeimbangkan replika tambahan dalam ReplicaSet aktif (ReplicaSet dengan Pod) untuk mencegah resiko. Ini disebut *pengaturan skala proporsional*. Sebagai contoh, kamu menjalankan Deployment dengan 10 replika, [maxSurge](#max-surge)=3, dan [maxUnavailable](#max-unavailable)=2. @@ -636,20 +636,20 @@ persyaratan `maxUnavailable` yang disebut di atas. Cek status rilis: * Kemudian, permintaan peningkatan untuk Deployment akan masuk. Autoscaler menambah replika Deployment menjadi 15. Controller Deployment perlu menentukan dimana 5 replika ini ditambahkan. Jika kamu memakai -pengaturan skala proporsional, kelima replika akan ditambahkan ke ReplicaSet baru. Dengan pengaturan skala proporsional, +pengaturan skala proporsional, kelima replika akan ditambahkan ke ReplicaSet baru. Dengan pengaturan skala proporsional, kamu menyebarkan replika tambahan ke semua ReplicaSet. Proporsi terbesar ada pada ReplicaSet dengan -replika terbanyak dan proporsi yang lebih kecil untuk replika dengan ReplicaSet yang lebih sedikit. +replika terbanyak dan proporsi yang lebih kecil untuk replika dengan ReplicaSet yang lebih sedikit. Sisanya akan diberikan ReplicaSet dengan replika terbanyak. ReplicaSet tanpa replika tidak akan ditingkatkan. -Dalam kasus kita di atas, 3 replika ditambahkan ke ReplicaSet lama dan 2 replika ditambahkan ke ReplicaSet baru. -Proses rilis akan segera memindahkan semua ReplicaSet baru, dengan asumsi semua replika dalam kondisi sehat. -Untuk memastikannya, jalankan: +Dalam kasus kita di atas, 3 replika ditambahkan ke ReplicaSet lama dan 2 replika ditambahkan ke ReplicaSet baru. +Proses rilis akan segera memindahkan semua ReplicaSet baru, dengan asumsi semua replika dalam kondisi sehat. +Untuk memastikannya, jalankan: ```shell kubectl get deploy ``` -Keluaran akan tampil seperti berikut: +Keluaran akan tampil seperti berikut: ``` NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE nginx-deployment 15 18 7 8 7m @@ -668,7 +668,7 @@ nginx-deployment-618515232 11 11 11 7m ## Menjeda dan Melanjutkan Deployment -Kamu dapat menjeda Deployment sebelum memicu satu atau lebih pembaruan kemudian meneruskannya. +Kamu dapat menjeda Deployment sebelum memicu satu atau lebih pembaruan kemudian meneruskannya. Hal ini memungkinkanmu menerapkan beberapa perbaikan selama selang jeda tanpa melakukan rilis yang tidak perlu. * Sebagai contoh, Deployment yang baru dibuat: @@ -743,7 +743,7 @@ Hal ini memungkinkanmu menerapkan beberapa perbaikan selama selang jeda tanpa me deployment.apps/nginx-deployment resource requirements updated ``` - The state awal Deployment sebelum jeda akan melanjutkan fungsinya, tapi perubahan + The state awal Deployment sebelum jeda akan melanjutkan fungsinya, tapi perubahan Deployment tidak akan berefek apapun selama Deployment masih terjeda. * Kemudian, mulai kembali Deployment dan perhatikan ReplicaSet baru akan muncul dengan semua perubahan baru: @@ -795,7 +795,7 @@ Kamu tidak bisa membalikkan Deployment yang terjeda sampai dia diteruskan. ## Status Deployment -Deployment melalui berbagai state dalam daur hidupnya. Dia dapat [berlangsung](#deployment-berlangsung) selagi merilis ReplicaSet baru, bisa juga [selesai](#deployment-selesai), +Deployment melalui berbagai state dalam daur hidupnya. Dia dapat [berlangsung](#deployment-berlangsung) selagi merilis ReplicaSet baru, bisa juga [selesai](#deployment-selesai), atau juga [gagal](#deployment-gagal). ### Deployment Berlangsung @@ -817,7 +817,7 @@ Kubernetes menandai Deployment sebagai _complete_ saat memiliki karakteristik be * Semua replika terkait Deployment dapat diakses. * Tidak ada replika lama untuk Deployment yang berjalan. -Kamu dapat mengecek apakah Deployment telah selesai dengan `kubectl rollout status`. +Kamu dapat mengecek apakah Deployment telah selesai dengan `kubectl rollout status`. Jika rilis selesai, `kubectl rollout status` akan mengembalikan nilai balik nol. ```shell @@ -833,7 +833,7 @@ $ echo $? ### Deployment Gagal -Deployment-mu bisa saja terhenti saat mencoba deploy ReplicaSet terbaru tanpa pernah selesai. +Deployment-mu bisa saja terhenti saat mencoba deploy ReplicaSet terbaru tanpa pernah selesai. Ini dapat terjadi karena faktor berikut: * Kuota tidak mencukupi @@ -868,7 +868,7 @@ berikut ke `.status.conditions` milik Deployment: Lihat [konvensi Kubernetes API](https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#typical-status-properties) untuk info lebih lanjut tentang kondisi status. {{< note >}} -Kubernetes tidak melakukan apapun pada Deployment yang tersendat selain melaporkannya sebagai `Reason=ProgressDeadlineExceeded`. +Kubernetes tidak melakukan apapun pada Deployment yang tersendat selain melaporkannya sebagai `Reason=ProgressDeadlineExceeded`. Orkestrator yang lebih tinggi dapat memanfaatkannya untuk melakukan tindak lanjut. Misalnya, mengembalikan Deployment ke versi sebelumnya. {{< /note >}} @@ -877,7 +877,7 @@ Jika Deployment terjeda, Kubernetes tidak akan mengecek kemajuan pada selang itu Kamu dapat menjeda Deployment di tengah rilis dan melanjutkannya dengan aman tanpa memicu kondisi saat tenggat telah lewat. {{< /note >}} -Kamu dapat mengalami galat sejenak pada Deployment disebabkan timeout yang dipasang terlalu kecil atau +Kamu dapat mengalami galat sejenak pada Deployment disebabkan timeout yang dipasang terlalu kecil atau hal-hal lain yang terjadi sementara. Misalnya, kamu punya kuota yang tidak mencukupi. Jika kamu mendeskripsikan Deployment kamu akan menjumpai pada bagian ini: @@ -937,7 +937,7 @@ Conditions: ReplicaFailure True FailedCreate ``` -Kamu dapat menangani isu keterbatasan kuota dengan menurunkan jumlah Deployment, bisa dengan menghapus kontrolers +Kamu dapat menangani isu keterbatasan kuota dengan menurunkan jumlah Deployment, bisa dengan menghapus kontrolers yang sedang berjalan, atau dengan meningkatkan kuota pada namespace. Jika kuota tersedia, kemudian kontroler Deployment akan dapat menyelesaikan rilis Deployment. Kamu akan melihat bahwa status Deployment berubah menjadi kondisi sukses (`Status=True` dan `Reason=NewReplicaSetAvailable`). @@ -951,7 +951,7 @@ Conditions: `Type=Available` dengan `Status=True` artinya Deployment-mu punya ketersediaan minimum. Ketersediaan minimum diatur oleh parameter yang dibuat pada strategi deployment. `Type=Progressing` dengan `Status=True` berarti Deployment -sedang dalam rilis dan masih berjalan atau sudah selesai berjalan dan jumlah minimum replika tersedia +sedang dalam rilis dan masih berjalan atau sudah selesai berjalan dan jumlah minimum replika tersedia (lihat bagian Alasan untuk kondisi tertentu - dalam kasus ini `Reason=NewReplicaSetAvailable` berarti Deployment telah selesai). Kamu dapat mengecek apakah Deployment gagal berkembang dengan perintah `kubectl rollout status`. `kubectl rollout status` @@ -974,7 +974,7 @@ Semua aksi yang dapat diterapkan pada Deployment yang selesai berjalan juga pada ## Kebijakan Pembersihan -Kamu dapat mengisi kolom `.spec.revisionHistoryLimit` di Deployment untuk menentukan banyak ReplicaSet +Kamu dapat mengisi kolom `.spec.revisionHistoryLimit` di Deployment untuk menentukan banyak ReplicaSet pada Deployment yang ingin dipertahankan. Sisanya akan di garbage-collected di balik layar. Umumnya, nilai kolom berisi 10. {{< note >}} @@ -984,7 +984,7 @@ sehingga Deployment tidak akan dapat dikembalikan. ## Deployment Canary -Jika kamu ingin merilis ke sebagian pengguna atau server menggunakan Deployment, +Jika kamu ingin merilis ke sebagian pengguna atau server menggunakan Deployment, kamu dapat membuat beberapa Deployment, satu tiap rilis, dengan mengikuti pola canary yang didesripsikan pada [mengelola sumber daya](/id/docs/concepts/cluster-administration/manage-deployment/#deploy-dengan-canary). @@ -1002,7 +1002,7 @@ Dalam `.spec` hanya ada kolom `.spec.template` dan `.spec.selector` yang wajib d `.spec.template` adalah [templat Pod](/id/docs/concepts/workloads/pods/pod-overview/#templat-pod). Dia memiliki skema yang sama dengan [Pod](/id/docs/concepts/workloads/pods/pod/). Bedanya dia bersarang dan tidak punya `apiVersion` atau `kind`. -Selain kolom wajib untuk Pod, templat Pod pada Deployment harus menentukan label dan aturan menjalankan ulang yang tepat. +Selain kolom wajib untuk Pod, templat Pod pada Deployment harus menentukan label dan aturan menjalankan ulang yang tepat. Untuk label, pastikaan tidak bertumpang tindih dengan kontroler lainnya. Lihat [selektor](#selektor)). [`.spec.template.spec.restartPolicy`](/id/docs/concepts/workloads/pods/pod-lifecycle/#aturan-menjalankan-ulang) hanya boleh berisi `Always`, @@ -1019,21 +1019,21 @@ untuk Pod yang dituju oleh Deployment ini. `.spec.selector` harus sesuai `.spec.template.metadata.labels`, atau akan ditolak oleh API. -Di versi API `apps/v1`, `.spec.selector` dan `.metadata.labels` tidak berisi `.spec.template.metadata.labels` jika tidak disetel. +Di versi API `apps/v1`, `.spec.selector` dan `.metadata.labels` tidak berisi `.spec.template.metadata.labels` jika tidak disetel. Jadi mereka harus disetel secara eksplisit. Perhatikan juga `.spec.selector` tidak dapat diubah setelah Deployment dibuat pada `apps/v1`. Deployment dapat mematikan Pod yang labelnya cocok dengan selektor jika templatnya berbeda -dari `.spec.template` atau total jumlah Pod melebihi `.spec.replicas`. Dia akan membuat Pod baru +dari `.spec.template` atau total jumlah Pod melebihi `.spec.replicas`. Dia akan membuat Pod baru dengan `.spec.template` jika jumlah Pod kurang dari yang diinginkan. {{< note >}} -Kamu sebaiknya tidak membuat Pod lain yang labelnya cocok dengan selektor ini, baik secara langsung, -melalui Deployment lain, atau membuat kontroler lain seperti ReplicaSet atau ReplicationController. -Kalau kamu melakukannya, Deployment pertama akan mengira dia yang membuat Pod-pod ini. +Kamu sebaiknya tidak membuat Pod lain yang labelnya cocok dengan selektor ini, baik secara langsung, +melalui Deployment lain, atau membuat kontroler lain seperti ReplicaSet atau ReplicationController. +Kalau kamu melakukannya, Deployment pertama akan mengira dia yang membuat Pod-pod ini. Kubernetes tidak akan mencegahmu melakukannya. {{< /note >}} -Jika kamu punya beberapa kontroler dengan selektor bertindihan, mereka akan saling bertikai +Jika kamu punya beberapa kontroler dengan selektor bertindihan, mereka akan saling bertikai dan tidak akan berjalan semestinya. ### Strategi @@ -1047,65 +1047,65 @@ Semua Pod yang ada dimatikan sebelum yang baru dibuat ketika nilai `.spec.strate #### Membarui Deployment secara Bergulir -Deployment membarui Pod secara [bergulir](/id/docs/tasks/run-application/rolling-update-replication-controller/) +Deployment membarui Pod secara bergulir saat `.spec.strategy.type==RollingUpdate`. Kamu dapat menentukan `maxUnavailable` dan `maxSurge` untuk mengatur proses pembaruan bergulir. ##### Ketidaktersediaan Maksimum -`.spec.strategy.rollingUpdate.maxUnavailable` adalah kolom opsional yang mengatur jumlah Pod maksimal -yang tidak tersedia selama proses pembaruan. Nilainya bisa berupa angka mutlak (contohnya 5) -atau persentase dari Pod yang diinginkan (contohnya 10%). Angka mutlak dihitung berdasarkan persentase -dengan pembulatan ke bawah. Nilai tidak bisa nol jika `.spec.strategy.rollingUpdate.maxSurge` juga nol. +`.spec.strategy.rollingUpdate.maxUnavailable` adalah kolom opsional yang mengatur jumlah Pod maksimal +yang tidak tersedia selama proses pembaruan. Nilainya bisa berupa angka mutlak (contohnya 5) +atau persentase dari Pod yang diinginkan (contohnya 10%). Angka mutlak dihitung berdasarkan persentase +dengan pembulatan ke bawah. Nilai tidak bisa nol jika `.spec.strategy.rollingUpdate.maxSurge` juga nol. Nilai bawaannya yaitu 25%. -Sebagai contoh, ketika nilai berisi 30%, ReplicaSet lama dapat segera diperkecil menjadi 70% dari Pod -yang diinginkan saat pembaruan bergulir dimulai. Seketika Pod baru siap, ReplicaSet lama dapat lebih diperkecil lagi, -diikuti dengan pembesaran ReplicaSet, menjamin total jumlah Pod yang siap kapanpun ketika pembaruan +Sebagai contoh, ketika nilai berisi 30%, ReplicaSet lama dapat segera diperkecil menjadi 70% dari Pod +yang diinginkan saat pembaruan bergulir dimulai. Seketika Pod baru siap, ReplicaSet lama dapat lebih diperkecil lagi, +diikuti dengan pembesaran ReplicaSet, menjamin total jumlah Pod yang siap kapanpun ketika pembaruan paling sedikit 70% dari Pod yang diinginkan. ##### Kelebihan Maksimum -`.spec.strategy.rollingUpdate.maxSurge` adalah kolom opsional yang mengatur jumlah Pod maksimal yang -dapat dibuat melebihi jumlah Pod yang diinginkan. Nilainya bisa berupa angka mutlak (contohnya 5) atau persentase -dari Pod yang diinginkan (contohnya 10%). Nilai tidak bisa nol jika `MaxUnavailable` juga nol. Angka mutlak +`.spec.strategy.rollingUpdate.maxSurge` adalah kolom opsional yang mengatur jumlah Pod maksimal yang +dapat dibuat melebihi jumlah Pod yang diinginkan. Nilainya bisa berupa angka mutlak (contohnya 5) atau persentase +dari Pod yang diinginkan (contohnya 10%). Nilai tidak bisa nol jika `MaxUnavailable` juga nol. Angka mutlak dihitung berdasarkan persentase dengan pembulatan ke bawah. Nilai bawaannya yaitu 25%. -Sebagai contoh, ketika nilai berisi 30%, ReplicaSet baru dapat segera diperbesar saat pembaruan bergulir dimulai, -sehingga total jumlah Pod yang baru dan lama tidak melebihi 130% dari Pod yang diinginkan. -Saat Pod lama dimatikan, ReplicaSet baru dapat lebih diperbesar lagi, menjamin total jumlah Pod yang siap +Sebagai contoh, ketika nilai berisi 30%, ReplicaSet baru dapat segera diperbesar saat pembaruan bergulir dimulai, +sehingga total jumlah Pod yang baru dan lama tidak melebihi 130% dari Pod yang diinginkan. +Saat Pod lama dimatikan, ReplicaSet baru dapat lebih diperbesar lagi, menjamin total jumlah Pod yang siap kapanpun ketika pembaruan paling banyak 130% dari Pod yang diinginkan. ### Tenggat Kemajuan dalam Detik -`.spec.progressDeadlineSeconds` adalah kolom opsional yang mengatur lama tunggu dalam dalam detik untuk Deployment-mu berjalan -sebelum sistem melaporkan lagi bahwa Deployment [gagal](#deployment-gagal) - ditunjukkan dengan kondisi `Type=Progressing`, `Status=False`, -dan `Reason=ProgressDeadlineExceeded` pada status sumber daya. Controller Deployment akan tetap mencoba ulang Deployment. -Nantinya begitu pengembalian otomatis diimplementasikan, kontroler Deployment akan membalikkan Deployment segera +`.spec.progressDeadlineSeconds` adalah kolom opsional yang mengatur lama tunggu dalam dalam detik untuk Deployment-mu berjalan +sebelum sistem melaporkan lagi bahwa Deployment [gagal](#deployment-gagal) - ditunjukkan dengan kondisi `Type=Progressing`, `Status=False`, +dan `Reason=ProgressDeadlineExceeded` pada status sumber daya. Controller Deployment akan tetap mencoba ulang Deployment. +Nantinya begitu pengembalian otomatis diimplementasikan, kontroler Deployment akan membalikkan Deployment segera saat dia menjumpai kondisi tersebut. Jika ditentukan, kolom ini harus lebih besar dari `.spec.minReadySeconds`. ### Lama Minimum untuk Siap dalam Detik -`.spec.minReadySeconds` adalah kolom opsional yang mengatur lama minimal sebuah Pod yang baru dibuat +`.spec.minReadySeconds` adalah kolom opsional yang mengatur lama minimal sebuah Pod yang baru dibuat seharusnya siap tanpa ada kontainer yang rusak, untuk dianggap tersedia, dalam detik. -Nilai bawaannya yaitu 0 (Pod akan dianggap tersedia segera ketika siap). Untuk mempelajari lebih lanjut +Nilai bawaannya yaitu 0 (Pod akan dianggap tersedia segera ketika siap). Untuk mempelajari lebih lanjut kapan Pod dianggap siap, lihat [Pemeriksaan Kontainer](/id/docs/concepts/workloads/pods/pod-lifecycle/#pemeriksaan-kontainer). ### Kembali Ke -Kolom `.spec.rollbackTo` telah ditinggalkan pada versi API `extensions/v1beta1` dan `apps/v1beta1`, dan sudah tidak didukung mulai versi API `apps/v1beta2`. +Kolom `.spec.rollbackTo` telah ditinggalkan pada versi API `extensions/v1beta1` dan `apps/v1beta1`, dan sudah tidak didukung mulai versi API `apps/v1beta2`. Sebagai gantinya, disarankan untuk menggunakan `kubectl rollout undo` sebagaimana diperkenalkan dalam [Kembali ke Revisi Sebelumnya](#kembali-ke-revisi-sebelumnya). ### Batas Riwayat Revisi Riwayat revisi Deployment disimpan dalam ReplicaSet yang dia kendalikan. -`.spec.revisionHistoryLimit` adalah kolom opsional yang mengatur jumlah ReplicaSet lama yang dipertahankan -untuk memungkinkan pengembalian. ReplicaSet lama ini mengambil sumber daya dari `etcd` dan memunculkan keluaran -dari `kubectl get rs`. Konfigurasi tiap revisi Deployment disimpan pada ReplicaSet-nya; sehingga, begitu ReplicaSet lama dihapus, -kamu tidak mampu lagi membalikkan revisi Deployment-nya. Umumnya, 10 ReplicaSet lama akan dipertahankan, +`.spec.revisionHistoryLimit` adalah kolom opsional yang mengatur jumlah ReplicaSet lama yang dipertahankan +untuk memungkinkan pengembalian. ReplicaSet lama ini mengambil sumber daya dari `etcd` dan memunculkan keluaran +dari `kubectl get rs`. Konfigurasi tiap revisi Deployment disimpan pada ReplicaSet-nya; sehingga, begitu ReplicaSet lama dihapus, +kamu tidak mampu lagi membalikkan revisi Deployment-nya. Umumnya, 10 ReplicaSet lama akan dipertahankan, namun nilai idealnya tergantung pada frekuensi dan stabilitas Deployment-deployment baru. Lebih spesifik, mengisi kolom dengan nol berarti semua ReplicaSet lama dengan 0 replika akan dibersihkan. @@ -1114,7 +1114,7 @@ Dalam kasus ini, rilis Deployment baru tidak dapat dibalikkan, sebab riwayat rev ### Terjeda `.spec.paused` adalah kolom boolean opsional untuk menjeda dan melanjutkan Deployment. Perbedaan antara Deployment yang terjeda -dan yang tidak hanyalah perubahan apapun pada PodTemplateSpec Deployment terjeda tidak akan memicu rilis baru selama masih terjeda. +dan yang tidak hanyalah perubahan apapun pada PodTemplateSpec Deployment terjeda tidak akan memicu rilis baru selama masih terjeda. Deployment umumnya tidak terjeda saat dibuat. ## Alternatif untuk Deployment @@ -1122,7 +1122,6 @@ Deployment umumnya tidak terjeda saat dibuat. ### kubectl rolling update [`kubectl rolling update`](/id/docs/reference/generated/kubectl/kubectl-commands#rolling-update) membarui Pod dan ReplicationController -dengan cara yang serupa. Namun, Deployments lebih disarankan karena deklaratif, berjalan di sisi server, dan punya fitur tambahan, +dengan cara yang serupa. Namun, Deployments lebih disarankan karena deklaratif, berjalan di sisi server, dan punya fitur tambahan, seperti pembalikkan ke revisi manapun sebelumnya bahkan setelah pembaruan rolling selesais. - diff --git a/content/id/docs/concepts/workloads/controllers/jobs-run-to-completion.md b/content/id/docs/concepts/workloads/controllers/jobs-run-to-completion.md index 4aca03535f..5f4720646b 100644 --- a/content/id/docs/concepts/workloads/controllers/jobs-run-to-completion.md +++ b/content/id/docs/concepts/workloads/controllers/jobs-run-to-completion.md @@ -119,14 +119,14 @@ Sebuah Job juga membutuhkan sebuah [bagian `.spec`](https://git.k8s.io/community _Field_ `.spec.template` merupakan satu-satunya _field_ wajib pada `.spec`. -_Field_ `.spec.template` merupakan sebuah [templat Pod](/docs/concepts/workloads/pods/pod-overview/#pod-templates). _Field_ ini memiliki skema yang sama dengan yang ada pada [Pod](/docs/user-guide/pods), +_Field_ `.spec.template` merupakan sebuah [templat Pod](/id/docs/concepts/workloads/pods/pod-overview/#pod-templates). _Field_ ini memiliki skema yang sama dengan yang ada pada [Pod](/docs/user-guide/pods), kecuali _field_ ini bersifat _nested_ dan tidak memiliki _field_ `apiVersion` atau _field_ `kind`. Sebagai tambahan dari _field_ wajib pada sebuah Job, sebuah tempat pod pada Job haruslah menspesifikasikan label yang sesuai (perhatikan [selektor pod](#pod-selektor)) dan sebuah mekanisme _restart_ yang sesuai. -Hanya sebuah [`RestartPolicy`](/docs/concepts/workloads/pods/pod-lifecycle/#restart-policy) yang sesuai dengan `Never` atau `OnFailure` yang bersifat valid. +Hanya sebuah [`RestartPolicy`](/id/docs/concepts/workloads/pods/pod-lifecycle/#restart-policy) yang sesuai dengan `Never` atau `OnFailure` yang bersifat valid. ### Selektor Pod @@ -194,7 +194,7 @@ Jika hal ini terjadi, dan `.spec.template.spec.restartPolicy = "OnFailure"`, mak akan tetap ada di dalam node, tetapi Container tersebut akan dijalankan kembali. Dengan demikian, program kamu harus dapat mengatasi kasus dimana program tersebut di-_restart_ secara lokal, atau jika tidak maka spesifikasikan `.spec.template.spec.restartPolicy = "Never"`. Perhatikan -[_lifecycle_ pod](/docs/concepts/workloads/pods/pod-lifecycle/#example-states) untuk informasi lebih lanjut mengenai `restartPolicy`. +[_lifecycle_ pod](/id/docs/concepts/workloads/pods/pod-lifecycle/#example-states) untuk informasi lebih lanjut mengenai `restartPolicy`. Sebuah Pod juga dapat gagal secara menyeluruh, untuk beberapa alasan yang mungkin, misalnya saja, ketika Pod tersebut dipindahkan dari Node (ketika Node diperbarui, di-_restart_, dihapus, dsb.), atau @@ -288,7 +288,7 @@ Pastikan kamu telah menspesifikasikan nilai tersebut pada level yang dibutuhkan. Job yang sudah selesai biasanya tidak lagi dibutuhkan di dalam sistem. Tetap menjaga keberadaan objek-objek tersebut di dalam sistem akan memberikan tekanan tambahan pada API server. Jika sebuah Job yang diatur secara langsung oleh _controller_ dengan level yang lebih tinggi, seperti -[CronJob](/docs/concepts/workloads/controllers/cron-jobs/), maka Job ini dapat +[CronJob](/id/docs/concepts/workloads/controllers/cron-jobs/), maka Job ini dapat di-_clean up_ oleh CronJob berdasarkan _policy_ berbasis kapasitas yang dispesifikasikan. ### Mekanisme TTL untuk Job yang Telah Selesai Dijalankan @@ -298,7 +298,7 @@ di-_clean up_ oleh CronJob berdasarkan _policy_ berbasis kapasitas yang dispesif Salah satu cara untuk melakukan _clean up_ Job yang telah selesai dijalankan (baik dengan status `Complete` atau `Failed`) secara otomatis adalah dengan menerapkan mekanisme TTL yang disediakan oleh -[_controller_ TTL](/docs/concepts/workloads/controllers/ttlafterfinished/) untuk +[_controller_ TTL](/id/docs/concepts/workloads/controllers/ttlafterfinished/) untuk sumber daya yang telah selesai digunakan, dengan cara menspesifikasikan _field_ `.spec.ttlSecondsAfterFinished` dari Job tersebut. @@ -334,7 +334,7 @@ maka Job ini tidak akan dihapus oleh _controller_ TTL setelah Job ini selesai di Perhatikan bahwa mekanisme TTL ini merupakan fitur alpha, dengan gerbang fitur `TTLAfterFinished`. Untuk informasi lebih lanjut, kamu dapat membaca dokumentasi untuk -[_controller_ TTL](/docs/concepts/workloads/controllers/ttlafterfinished/) untuk +[_controller_ TTL](/id/docs/concepts/workloads/controllers/ttlafterfinished/) untuk sumber daya yang telah selesai dijalankan. ## Pola Job @@ -478,7 +478,7 @@ Job merupakan komplemen dari [Replication Controller](/docs/user-guide/replicati Sebuah Replication Controller mengatur Pod yang diharapkan untuk tidak dihentikan (misalnya, _web server_), dan sebuah Job mengatur Pod yang diharapkan untuk berhenti (misalnya, _batch task_). -Seperti yang sudah dibahas pada [_Lifecycle_ Pod](/docs/concepts/workloads/pods/pod-lifecycle/), `Job` *hanya* pantas +Seperti yang sudah dibahas pada [_Lifecycle_ Pod](/id/docs/concepts/workloads/pods/pod-lifecycle/), `Job` *hanya* pantas digunakan untuk Pod dengan `RestartPolicy` yang sama dengan `OnFailure` atau `Never`. (Perhatikan bahwa: Jika `RestartPolicy` tidak dispesifikasikan, nilai defaultnya adalah `Always`.) @@ -499,7 +499,7 @@ dari sebuah Job, tetapi kontrol secara mutlak atas Pod yang dibuat serta tugas y ## CronJob {#cron-jobs} -Kamu dapat menggunakan [`CronJob`](/docs/concepts/workloads/controllers/cron-jobs/) untuk membuat Job yang akan +Kamu dapat menggunakan [`CronJob`](/id/docs/concepts/workloads/controllers/cron-jobs/) untuk membuat Job yang akan dijalankan pada waktu/tanggal yang spesifik, mirip dengan perangkat lunak `cron` yang ada pada Unix. diff --git a/content/id/docs/concepts/workloads/controllers/replicaset.md b/content/id/docs/concepts/workloads/controllers/replicaset.md index c0c3a83d51..57b1124208 100644 --- a/content/id/docs/concepts/workloads/controllers/replicaset.md +++ b/content/id/docs/concepts/workloads/controllers/replicaset.md @@ -197,7 +197,7 @@ Untuk _field_ [_restart policy_](/docs/concepts/workloads/Pods/pod-lifecycle/#re ### Selektor Pod -_Field_ `.spec.selector` adalah sebuah [selektor labe](/docs/concepts/overview/working-with-objects/labels/). Seperti yang telah dibahas [sebelumnya](#how-a-replicaset-works), _field_ ini adalah label yang digunakan untuk mengidentifikasi Pod yang memungkinkan untuk diakuisisi. Pada contoh `frontend.yaml`, selektornya adalah: +_Field_ `.spec.selector` adalah sebuah [selektor labe](/id/docs/concepts/overview/working-with-objects/labels/). Seperti yang telah dibahas [sebelumnya](#how-a-replicaset-works), _field_ ini adalah label yang digunakan untuk mengidentifikasi Pod yang memungkinkan untuk diakuisisi. Pada contoh `frontend.yaml`, selektornya adalah: ```shell matchLabels: tier: frontend @@ -219,7 +219,7 @@ Jika nilai `.spec.replicas` tidak ditentukan maka akan diatur ke nilai _default_ ### Menghapus ReplicaSet dan Pod-nya -Untuk menghapus sebuah ReplicaSet beserta dengan Pod-nya, gunakan [`kubectl delete`](/docs/reference/generated/kubectl/kubectl-commands#delete). [_Garbage collector_](/docs/concepts/workloads/controllers/garbage-collection/) secara otomatis akan menghapus semua Pod dependen secara _default_. +Untuk menghapus sebuah ReplicaSet beserta dengan Pod-nya, gunakan [`kubectl delete`](/docs/reference/generated/kubectl/kubectl-commands#delete). [_Garbage collector_](/id/docs/concepts/workloads/controllers/garbage-collection/) secara otomatis akan menghapus semua Pod dependen secara _default_. Ketika menggunakan REST API atau _library_ `client-go`, kamu harus mengatur nilai `propagationPolicy` menjadi `Background` atau `Foreground` pada opsi -d. Sebagai contoh: @@ -243,7 +243,7 @@ curl -X DELETE 'localhost:8080/apis/extensions/v1beta1/namespaces/default/repli ``` Ketika ReplicaSet yang asli telah dihapus, kamu dapat membuat ReplicaSet baru untuk menggantikannya. Selama _field_ `.spec.selector` yang lama dan baru memilki nilai yang sama, maka ReplicaSet baru akan mengadopsi Pod lama namun tidak serta merta membuat Pod yang sudah ada sama dan sesuai dengan templat Pod yang baru. -Untuk memperbarui Pod dengan _spec_ baru dapat menggunakan [Deployment](/docs/concepts/workloads/controllers/deployment/#creating-a-deployment) karena ReplicaSet tidak mendukung pembaruan secara langsung. +Untuk memperbarui Pod dengan _spec_ baru dapat menggunakan [Deployment](/id/docs/concepts/workloads/controllers/deployment/#creating-a-deployment) karena ReplicaSet tidak mendukung pembaruan secara langsung. ### Mengisolasi Pod dari ReplicaSet @@ -275,7 +275,7 @@ kubectl autoscale rs frontend --max=10 ### Deployment (direkomendasikan) -[`Deployment`](/docs/concepts/workloads/controllers/deployment/) adalah sebuah objek yang bisa memiliki ReplicaSet dan memperbarui ReplicaSet dan Pod-nya melalui _rolling update_ deklaratif dan _server-side_. +[`Deployment`](/id/docs/concepts/workloads/controllers/deployment/) adalah sebuah objek yang bisa memiliki ReplicaSet dan memperbarui ReplicaSet dan Pod-nya melalui _rolling update_ deklaratif dan _server-side_. Walaupun ReplicaSet dapat digunakan secara independen, seringkali ReplicaSet digunakan oleh Deployments sebagai mekanisme untuk mengorkestrasi pembuatan, penghapusan dan pembaruan Pod. Ketika kamu menggunakan Deployments kamu tidak perlu khawatir akan pengaturan dari ReplicaSet yang dibuat. Deployments memiliki dan mengatur ReplicaSet-nya sendiri. Maka dari itu penggunaan Deployments direkomendasikan jika kamu menginginkan ReplicaSet. @@ -289,9 +289,9 @@ Gunakan [`Job`](/docs/concepts/jobs/run-to-completion-finite-workloads/) alih-al ### DaemonSet -Gunakan [`DaemonSet`](/docs/concepts/workloads/controllers/daemonset/) alih-alih ReplicaSet untuk Pod yang menyediakan fungsi pada level mesin, seperti _monitoring_ mesin atau _logging_ mesin. Pod ini memiliki waktu hidup yang bergantung terhadap waktu hidup mesin: Pod perlu untuk berjalan pada mesin sebelum Pod lain dijalankan, dan aman untuk diterminasi ketika mesin siap untuk di-_reboot_ atau dimatikan. +Gunakan [`DaemonSet`](/id/docs/concepts/workloads/controllers/daemonset/) alih-alih ReplicaSet untuk Pod yang menyediakan fungsi pada level mesin, seperti _monitoring_ mesin atau _logging_ mesin. Pod ini memiliki waktu hidup yang bergantung terhadap waktu hidup mesin: Pod perlu untuk berjalan pada mesin sebelum Pod lain dijalankan, dan aman untuk diterminasi ketika mesin siap untuk di-_reboot_ atau dimatikan. ### ReplicationController -ReplicaSet adalah suksesor dari [_ReplicationControllers_](/docs/concepts/workloads/controllers/replicationcontroller/). Keduanya memenuhi tujuan yang sama dan memiliki perilaku yang serupa, kecuali bahwa ReplicationController tidak mendukung kebutuhan selektor _set-based_ seperti yang dijelaskan pada [panduan penggunaan label](/docs/concepts/overview/working-with-objects/labels/#label-selectors). Pada kasus tersebut, ReplicaSet lebih direkomendasikan dibandingkan ReplicationController. +ReplicaSet adalah suksesor dari [_ReplicationControllers_](/id/docs/concepts/workloads/controllers/replicationcontroller/). Keduanya memenuhi tujuan yang sama dan memiliki perilaku yang serupa, kecuali bahwa ReplicationController tidak mendukung kebutuhan selektor _set-based_ seperti yang dijelaskan pada [panduan penggunaan label](/id/docs/concepts/overview/working-with-objects/labels/#label-selectors). Pada kasus tersebut, ReplicaSet lebih direkomendasikan dibandingkan ReplicationController. diff --git a/content/id/docs/concepts/workloads/controllers/replicationcontroller.md b/content/id/docs/concepts/workloads/controllers/replicationcontroller.md index f828ff9c64..48ec718a6d 100644 --- a/content/id/docs/concepts/workloads/controllers/replicationcontroller.md +++ b/content/id/docs/concepts/workloads/controllers/replicationcontroller.md @@ -13,7 +13,7 @@ weight: 20 <!-- overview --> {{< note >}} -[`Deployment`](/docs/concepts/workloads/controllers/deployment/) yang mengonfigurasi [`ReplicaSet`](/docs/concepts/workloads/controllers/replicaset/) sekarang menjadi cara yang direkomendasikan untuk melakukan replikasi. +[`Deployment`](/id/docs/concepts/workloads/controllers/deployment/) yang mengonfigurasi [`ReplicaSet`](/id/docs/concepts/workloads/controllers/replicaset/) sekarang menjadi cara yang direkomendasikan untuk melakukan replikasi. {{< /note >}} Sebuah _ReplicationController_ memastikan bahwa terdapat sejumlah Pod yang sedang berjalan dalam suatu waktu tertentu. Dengan kata lain, ReplicationController memastikan bahwa sebuah Pod atau sebuah kumpulan Pod yang homogen selalu berjalan dan tersedia. @@ -101,7 +101,7 @@ Pada perintah di atas, selektor yang dimaksud adalah selektor yang sama dengan y Seperti semua konfigurasi Kubernetes lainnya, sebuah ReplicationController membutuhkan _field_ `apiVersion`, `kind`, dan `metadata`. -Untuk informasi umum mengenai berkas konfigurasi, kamu dapat melihat [pengaturan objek](/docs/concepts/overview/working-with-objects/object-management/). +Untuk informasi umum mengenai berkas konfigurasi, kamu dapat melihat [pengaturan objek](/id/docs/concepts/overview/working-with-objects/object-management/). Sebuah ReplicationController juga membutuhkan [bagian `.spec`](https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status). @@ -109,11 +109,11 @@ Sebuah ReplicationController juga membutuhkan [bagian `.spec`](https://git.k8s.i `.spec.template` adalah satu-satunya _field_ yang diwajibkan pada `.spec`. -`.spec.template` adalah sebuah [templat Pod](/docs/concepts/workloads/pods/pod-overview/#pod-templates). Ia memiliki skema yang sama persis dengan sebuah [Pod](/docs/concepts/workloads/pods/pod/), namun dapat berbentuk _nested_ dan tidak memiliki _field_ `apiVersion` ataupun `kind`. +`.spec.template` adalah sebuah [templat Pod](/id/docs/concepts/workloads/pods/pod-overview/#pod-templates). Ia memiliki skema yang sama persis dengan sebuah [Pod](/id/docs/concepts/workloads/pods/pod/), namun dapat berbentuk _nested_ dan tidak memiliki _field_ `apiVersion` ataupun `kind`. Selain _field-field_ yang diwajibkan untuk sebuah Pod, templat Pod pada ReplicationController harus menentukan label dan kebijakan pengulangan kembali yang tepat. Untuk label, pastikan untuk tidak tumpang tindih dengan kontroler lain. Lihat [selektor pod](#selektor-pod). -Nilai yang diperbolehkan untuk [`.spec.template.spec.restartPolicy`](/docs/concepts/workloads/pods/pod-lifecycle/#restart-policy) hanyalah `Always`, yaitu nilai bawaan jika tidak ditentukan. +Nilai yang diperbolehkan untuk [`.spec.template.spec.restartPolicy`](/id/docs/concepts/workloads/pods/pod-lifecycle/#restart-policy) hanyalah `Always`, yaitu nilai bawaan jika tidak ditentukan. Untuk pengulangan kembali dari sebuah kontainer lokal, ReplicationController mendelegasikannya ke agen pada Node, contohnya [Kubelet](/docs/admin/kubelet/) atau Docker. @@ -123,7 +123,7 @@ ReplicationController itu sendiri dapat memiliki label (`.metadata.labels`). Bia ### Selektor Pod -_Field_ `.spec.selector` adalah sebuah [selektor label](/docs/concepts/overview/working-with-objects/labels/#label-selectors). Sebuah ReplicationController mengatur semua Pod dengan label yang sesuai dengan nilai selektor tersebut. Ia tidak membedakan antara Pod yang ia buat atau hapus atau Pod yang dibuat atau dihapus oleh orang atau proses lain. Hal ini memungkinkan ReplicationController untuk digantikan tanpa memengaruhi Pod-Pod yang sedang berjalan. +_Field_ `.spec.selector` adalah sebuah [selektor label](/id/docs/concepts/overview/working-with-objects/labels/#label-selectors). Sebuah ReplicationController mengatur semua Pod dengan label yang sesuai dengan nilai selektor tersebut. Ia tidak membedakan antara Pod yang ia buat atau hapus atau Pod yang dibuat atau dihapus oleh orang atau proses lain. Hal ini memungkinkan ReplicationController untuk digantikan tanpa memengaruhi Pod-Pod yang sedang berjalan. Jika ditentukan, `.spec.template.metadata.labels` harus memiliki nilai yang sama dengan `.spec.selector`, atau akan ditolak oleh API. Jika `.spec.selector` tidak ditentukan, maka akan menggunakan nilai bawaan yaitu `.spec.template.metadata.labels`. @@ -216,13 +216,13 @@ ReplicationController adalah sebuah sumber daya _top-level_ pada REST API Kubern ### ReplicaSet -[`ReplicaSet`](/docs/concepts/workloads/controllers/replicaset/) adalah kelanjutan dari ReplicationController yang mendukung selektor [selektor label _set-based_](/docs/concepts/overview/working-with-objects/labels/#set-based-requirement) yang baru. Umumnya digunakan oleh [`Deployment`](/docs/concepts/workloads/controllers/deployment/) sebagai mekanisme untuk mengorkestrasi pembuatan, penghapusan, dan pembaruan Pod. +[`ReplicaSet`](/id/docs/concepts/workloads/controllers/replicaset/) adalah kelanjutan dari ReplicationController yang mendukung selektor [selektor label _set-based_](/id/docs/concepts/overview/working-with-objects/labels/#set-based-requirement) yang baru. Umumnya digunakan oleh [`Deployment`](/id/docs/concepts/workloads/controllers/deployment/) sebagai mekanisme untuk mengorkestrasi pembuatan, penghapusan, dan pembaruan Pod. Perhatikan bahwa kami merekomendasikan untuk menggunakan Deployment sebagai ganti dari menggunakan ReplicaSet secara langsung, kecuali jika kamu membutuhkan orkestrasi pembaruan khusus atau tidak membutuhkan pembaruan sama sekali. ### Deployment (Direkomendasikan) -[`Deployment`](/docs/concepts/workloads/controllers/deployment/) adalah objek API tingkat tinggi yang memperbarui ReplicaSet dan Pod-Pod di bawahnya yang mirip dengan cara kerja `kubectl rolling-update`. Deployment direkomendasikan jika kamu menginginkan fungsionalitas dari pembaruan bergulir ini, karena tidak seperti `kubectl rolling-update`, Deployment memiliki sifat deklaratif, _server-side_, dan memiliki beberapa fitur tambahan lainnya. +[`Deployment`](/id/docs/concepts/workloads/controllers/deployment/) adalah objek API tingkat tinggi yang memperbarui ReplicaSet dan Pod-Pod di bawahnya yang mirip dengan cara kerja `kubectl rolling-update`. Deployment direkomendasikan jika kamu menginginkan fungsionalitas dari pembaruan bergulir ini, karena tidak seperti `kubectl rolling-update`, Deployment memiliki sifat deklaratif, _server-side_, dan memiliki beberapa fitur tambahan lainnya. ### Pod sederhana @@ -234,7 +234,7 @@ Gunakan [`Job`](/docs/concepts/jobs/run-to-completion-finite-workloads/) sebagai ### DaemonSet -Gunakan [`DaemonSet`](/docs/concepts/workloads/controllers/daemonset/) sebagai ganti ReplicationController untuk Pod-Pod yang menyediakan fungsi pada level mesin, seperti pengamatan mesin atau pencatatan mesin. Pod-Pod ini memiliki waktu hidup yang bergantung dengan waktu hidup mesin: Pod butuh untuk dijalankan di mesin sebelum Pod-Pod lainnya dimulai, dan aman untuk diterminasi ketika mesin sudah siap untuk dinyalakan ulang atau dimatikan. +Gunakan [`DaemonSet`](/id/docs/concepts/workloads/controllers/daemonset/) sebagai ganti ReplicationController untuk Pod-Pod yang menyediakan fungsi pada level mesin, seperti pengamatan mesin atau pencatatan mesin. Pod-Pod ini memiliki waktu hidup yang bergantung dengan waktu hidup mesin: Pod butuh untuk dijalankan di mesin sebelum Pod-Pod lainnya dimulai, dan aman untuk diterminasi ketika mesin sudah siap untuk dinyalakan ulang atau dimatikan. ## Informasi lanjutan diff --git a/content/id/docs/concepts/workloads/controllers/statefulset.md b/content/id/docs/concepts/workloads/controllers/statefulset.md index 9d12de91dd..aa99acd6e6 100644 --- a/content/id/docs/concepts/workloads/controllers/statefulset.md +++ b/content/id/docs/concepts/workloads/controllers/statefulset.md @@ -31,8 +31,8 @@ Stabil dalam poin-poin di atas memiliki arti yang sama dengan persisten pada Pod saat dilakukan _(re)scheduling_. Jika suatu aplikasi tidak membutuhkan identitas yang stabil atau _deployment_ yang memiliki urutan, penghapusan, atau mekanisme _scaling_, kamu harus melakukan _deploy_ aplikasi dengan _controller_ yang menyediakan -replika _stateless_. _Controller_ seperti [Deployment](/docs/concepts/workloads/controllers/deployment/) atau -[ReplicaSet](/docs/concepts/workloads/controllers/replicaset/) akan lebih sesuai dengan kebutuhan kamu. +replika _stateless_. _Controller_ seperti [Deployment](/id/docs/concepts/workloads/controllers/deployment/) atau +[ReplicaSet](/id/docs/concepts/workloads/controllers/replicaset/) akan lebih sesuai dengan kebutuhan kamu. ## Keterbatasan @@ -40,7 +40,7 @@ replika _stateless_. _Controller_ seperti [Deployment](/docs/concepts/workloads pada Kubernetes rilis sebelum versi 1.5. * Penyimpanan untuk sebuah Pod harus terlebih dahulu di-_provision_ dengan menggunakan sebuah [Provisioner PersistentVolume](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/staging/persistent-volume-provisioning/README.md) berdasarkan `storage class` yang dispesifikasikan, atau sudah ditentukan sebelumnya oleh administrator. * Menghapus dan/atau _scaling_ sebuah StatefulSet *tidak akan* menghapus volume yang berkaitan dengan StatefulSet tersebut. Hal ini dilakukan untuk menjamin data yang disimpan, yang secara umum dinilai lebih berhaga dibandingkan dengan mekanisme penghapusan data secara otomatis pada sumber daya terkait. -* StatefulSet saat ini membutuhkan sebuah [Headless Service](/docs/concepts/services-networking/service/#headless-services) yang nantinya akan bertanggung jawab terhadap pada identitas jaringan pada Pod. Kamulah yang bertanggung jawab untuk membuat Service tersebut. +* StatefulSet saat ini membutuhkan sebuah [Headless Service](/id/docs/concepts/services-networking/service/#headless-services) yang nantinya akan bertanggung jawab terhadap pada identitas jaringan pada Pod. Kamulah yang bertanggung jawab untuk membuat Service tersebut. * StatefulSet tidak menjamin terminasi Pod ketika sebuah StatefulSet dihapus. Untuk mendapatkan terminasi Pod yang terurut dan _graceful_ pada StatefulSet, kita dapat melakukan _scale down_ Pod ke 0 sebelum penghapusan. * Ketika menggunakan [Rolling Update](#mekanisme-strategi-update-rolling-update) dengan [Kebijakan Manajemen Pod](#kebijakan-manajemen-pod) (`OrderedReady`) secara default, @@ -52,7 +52,7 @@ Contoh di bawah ini akna menunjukkan komponen-komponen penyusun StatefulSet. * Sebuah Service Headless, dengan nama nginx, digunakan untuk mengontrol domain jaringan. * StatefulSet, dengan nama web, memiliki Spek yang mengindikasikan terdapat 3 replika Container yang akan dihidupkan pada Pod yang unik. -* _Field_ `volumeClaimTemplates` akan menyediakan penyimpanan stabil menggunakan [PersistentVolume](/docs/concepts/storage/persistent-volumes/) yang di-_provision_ oleh sebuah Provisioner PersistentVolume. +* _Field_ `volumeClaimTemplates` akan menyediakan penyimpanan stabil menggunakan [PersistentVolume](/id/docs/concepts/storage/persistent-volumes/) yang di-_provision_ oleh sebuah Provisioner PersistentVolume. ```yaml apiVersion: v1 @@ -124,7 +124,7 @@ Setiap Pod di dalam StatefulSet memiliki _hostname_ diturunkan dari nama Satetul serta ordinal Pod tersebut. Pola pada _hostname_ yang terbentuk adalah `$(statefulset name)-$(ordinal)`. Contoh di atas akan menghasilkan tiga Pod dengan nama `web-0,web-1,web-2`. -Sebuah StatefulSet dapat menggunakan sebuah [Service Headless](/docs/concepts/services-networking/service/#headless-services) +Sebuah StatefulSet dapat menggunakan sebuah [Service Headless](/id/docs/concepts/services-networking/service/#headless-services) untuk mengontrol domain dari Pod yang ada. Domain yang diatur oleh Service ini memiliki format: `$(service name).$(namespace).svc.cluster.local`, dimana "cluster.local" merupakan domain klaster. @@ -133,7 +133,7 @@ Seiring dibuatnya setiap Pod, Pod tersebut akan memiliki subdomain DNS-nya sendi _field_ `serviceName` pada StatefulSet. Seperti sudah disebutkan di dalam bagian [keterbatasan](#keterbatasan), kamulah yang bertanggung jawab -untuk membuat [Service Headless](/docs/concepts/services-networking/service/#headless-services) +untuk membuat [Service Headless](/id/docs/concepts/services-networking/service/#headless-services) yang bertanggung jawab terhadap identitas jaringan pada Pod. Di sini terdapat beberapa contoh penggunaan Domain Klaster, nama Service, @@ -147,12 +147,12 @@ Domain Klaster | Service (ns/nama) | StatefulSet (ns/nama) | Domain StatefulSet {{< note >}} Domain klaster akan diatur menjadi `cluster.local` kecuali -[nilainya dikonfigurasi](/docs/concepts/services-networking/dns-pod-service/). +[nilainya dikonfigurasi](/id/docs/concepts/services-networking/dns-pod-service/). {{< /note >}} ### Penyimpanan Stabil -Kubernetes membuat sebuah [PersistentVolume](/docs/concepts/storage/persistent-volumes/) untuk setiap +Kubernetes membuat sebuah [PersistentVolume](/id/docs/concepts/storage/persistent-volumes/) untuk setiap VolumeClaimTemplate. Pada contoh nginx di atas, setiap Pod akan menerima sebuah PersistentVolume dengan StorageClass `my-storage-class` dan penyimpanan senilai 1 Gib yang sudah di-_provisioning_. Jika tidak ada StorageClass yang dispesifikasikan, maka StorageClass _default_ akan digunakan. Ketika sebuah Pod dilakukan _(re)schedule_ diff --git a/content/id/docs/concepts/workloads/controllers/ttlafterfinished.md b/content/id/docs/concepts/workloads/controllers/ttlafterfinished.md index f2c232faf2..0e1b36ccc5 100644 --- a/content/id/docs/concepts/workloads/controllers/ttlafterfinished.md +++ b/content/id/docs/concepts/workloads/controllers/ttlafterfinished.md @@ -10,7 +10,7 @@ weight: 65 Pengendali TTL menyediakan mekanisme TTL yang membatasi umur dari suatu objek sumber daya yang telah selesai digunakan. Pengendali TTL untuk saat ini hanya menangani -[Jobs](/docs/concepts/workloads/controllers/jobs-run-to-completion/), +[Jobs](/id/docs/concepts/workloads/controllers/jobs-run-to-completion/), dan nantinya bisa saja digunakan untuk sumber daya lain yang telah selesai digunakan misalnya saja Pod atau sumber daya khusus (_custom resource_) lainnya. @@ -32,7 +32,7 @@ Pengendali TTL untuk saat ini hanya mendukung Job. Sebuah operator klaster dapat menggunakan fitur ini untuk membersihkan Job yang telah dieksekusi (baik `Complete` atau `Failed`) secara otomatis dengan menentukan _field_ `.spec.ttlSecondsAfterFinished` pada Job, seperti yang tertera di -[contoh](/docs/concepts/workloads/controllers/jobs-run-to-completion/#clean-up-finished-jobs-automatically). +[contoh](/id/docs/concepts/workloads/controllers/jobs-run-to-completion/#clean-up-finished-jobs-automatically). Pengendali TTL akan berasumsi bahwa sebuah sumber daya dapat dihapus apabila TTL dari sumber daya tersebut telah habis. Proses dihapusnya sumber daya ini dilakukan secara berantai, dimana sumber daya lain yang @@ -83,7 +83,7 @@ Perhatikan bahwa hal ini dapat terjadi apabila TTL diaktifkan dengan nilai selai ## {{% heading "whatsnext" %}} -[Membersikan Job secara Otomatis](/docs/concepts/workloads/controllers/jobs-run-to-completion/#clean-up-finished-jobs-automatically) +[Membersikan Job secara Otomatis](/id/docs/concepts/workloads/controllers/jobs-run-to-completion/#clean-up-finished-jobs-automatically) [Dokumentasi Rancangan](https://github.com/kubernetes/enhancements/blob/master/keps/sig-apps/0026-ttl-after-finish.md) diff --git a/content/id/docs/concepts/workloads/pods/disruptions.md b/content/id/docs/concepts/workloads/pods/disruptions.md index 1adde6c949..7a09eed3a5 100644 --- a/content/id/docs/concepts/workloads/pods/disruptions.md +++ b/content/id/docs/concepts/workloads/pods/disruptions.md @@ -79,7 +79,7 @@ Jumlah Pod yang "diharapkan" dihitung dari `.spec.replicas` dari pengendali Pod PDB tidak dapat mencegah [disrupsi yang tidak disengaja](#disrupsi-yang-disengaja-dan-tidak-disengaja), tapi disrupsi ini akan dihitung terhadap bujet PDB. -Pod yang dihapus atau tidak tersetia dikarenakan pembaruan bertahap juga dihitung terhadap bujet PDB, tetapi pengendali (seperti Deployment dan StatefulSet) tidak dibatasi oleh PDB ketika melakukan pembaruan bertahap; Penanganan kerusakan saat pembaruan aplikasi dikonfigurasikan pada spesifikasi pengendali. (Pelajari tentang [memperbarui sebuah Deployment](/docs/concepts/workloads/controllers/deployment/#updating-a-deployment).) +Pod yang dihapus atau tidak tersetia dikarenakan pembaruan bertahap juga dihitung terhadap bujet PDB, tetapi pengendali (seperti Deployment dan StatefulSet) tidak dibatasi oleh PDB ketika melakukan pembaruan bertahap; Penanganan kerusakan saat pembaruan aplikasi dikonfigurasikan pada spesifikasi pengendali. (Pelajari tentang [memperbarui sebuah Deployment](/id/docs/concepts/workloads/controllers/deployment/#updating-a-deployment).) Saat sebuah Pod diusir menggunakan _eviction API_, Pod tersebut akan dihapus secara _graceful_ (lihat `terminationGracePeriodSeconds` pada [PodSpec](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#Podspec-v1-core).)) diff --git a/content/id/docs/concepts/workloads/pods/ephemeral-containers.md b/content/id/docs/concepts/workloads/pods/ephemeral-containers.md index 45154caf25..e952bdd19b 100644 --- a/content/id/docs/concepts/workloads/pods/ephemeral-containers.md +++ b/content/id/docs/concepts/workloads/pods/ephemeral-containers.md @@ -80,7 +80,7 @@ pun, sehingga sulit untuk memecahkan masalah _image distroless_ dengan menggunakan `kubectl exec` saja. Saat menggunakan kontainer sementara, akan sangat membantu untuk mengaktifkan -[_process namespace sharing_](/docs/tasks/configure-pod-container/share-process-namespace/) +[_process namespace sharing_](/id/docs/tasks/configure-pod-container/share-process-namespace/) sehingga kamu dapat melihat proses pada kontainer lain. ### Contoh diff --git a/content/id/docs/concepts/workloads/pods/init-containers.md b/content/id/docs/concepts/workloads/pods/init-containers.md index 91807fdaf6..9cd208fbc8 100644 --- a/content/id/docs/concepts/workloads/pods/init-containers.md +++ b/content/id/docs/concepts/workloads/pods/init-containers.md @@ -14,7 +14,7 @@ Fitur ini telah keluar dari trek Beta sejak versi 1.6. Init Container dapat disp ## Memahami Init Container -Sebuah [Pod](/docs/concepts/workloads/pods/pod-overview/) dapat memiliki beberapa Container yang berjalan di dalamnya, dan dapat juga memiliki satu atau lebih Init Container, yang akan berjalan sebelum Container aplikasi dijalankan. +Sebuah [Pod](/id/docs/concepts/workloads/pods/pod-overview/) dapat memiliki beberapa Container yang berjalan di dalamnya, dan dapat juga memiliki satu atau lebih Init Container, yang akan berjalan sebelum Container aplikasi dijalankan. Init Container sama saja seperti Container biasa, kecuali: @@ -59,7 +59,7 @@ Berikut beberapa contoh kasus penggunaan Init Container: * Mengklon sebuah _git repository_ ke dalam sebuah _volume_. * Menaruh nilai-nilai tertentu ke dalam sebuah _file_ konfigurasi dan menjalankan peralatan _template_ untuk membuat _file_ konfigurasi secara dinamis untuk Container aplikasi utama. Misalnya, untuk menaruh nilai POD_IP ke dalam sebuah konfigurasi dan membuat konfigurasi aplikasi utama menggunakan Jinja. -Contoh-contoh penggunaan yang lebih detail dapat dilihat pada [dokumentasi StatefulSet](/docs/concepts/workloads/controllers/statefulset/) dan [petunjuk Produksi Pod](/docs/tasks/configure-pod-container/configure-pod-initialization/). +Contoh-contoh penggunaan yang lebih detail dapat dilihat pada [dokumentasi StatefulSet](/id/docs/concepts/workloads/controllers/statefulset/) dan [petunjuk Produksi Pod](/docs/tasks/configure-pod-container/configure-pod-initialization/). ### Menggunakan Init Container diff --git a/content/id/docs/concepts/workloads/pods/pod-lifecycle.md b/content/id/docs/concepts/workloads/pods/pod-lifecycle.md index 8dac6706a7..fdb3e7b71c 100644 --- a/content/id/docs/concepts/workloads/pods/pod-lifecycle.md +++ b/content/id/docs/concepts/workloads/pods/pod-lifecycle.md @@ -52,7 +52,7 @@ Suatu Pod memiliki sebuah PodStatus, yang merupakan _array_ dari [PodConditions] * `PodScheduled`: Pod telah dijadwalkan masuk ke node; * `Ready`: Pod sudah mampu menerima _request_ masuk dan seharusnya sudah ditambahkan ke daftar pembagian beban kerja untuk servis yang sama; - * `Initialized`: Semua [init containers](/docs/concepts/workloads/pods/init-containers) telah berjalan sempurna. + * `Initialized`: Semua [init containers](/id/docs/concepts/workloads/pods/init-containers) telah berjalan sempurna. * `Unschedulable`: _scheduler_ belum dapat menjadwalkan Pod saat ini, sebagai contoh karena kekurangan _resources_ atau ada batasan-batasan lain. * `ContainersReady`: Semua kontainer di dalam Pod telah siap. @@ -191,7 +191,7 @@ status: ... ``` -Kondisi Pod yang baru harus memenuhi [format label](/docs/concepts/overview/working-with-objects/labels/#syntax-and-character-set) pada Kubernetes. +Kondisi Pod yang baru harus memenuhi [format label](/id/docs/concepts/overview/working-with-objects/labels/#syntax-and-character-set) pada Kubernetes. Sejak perintah `kubectl patch` belum mendukung perubahan status objek, kondisi Pod yang baru harus mengubah melalui aksi `PATCH` dengan menggunakan salah satu dari [KubeClient _libraries_](/docs/reference/using-api/client-libraries/). @@ -232,13 +232,13 @@ Tiga tipe pengontrol yang tersedia yaitu: sebagai contoh, penghitungan dalam jumlah banyak. Jobs hanyak cocok untuk Pod dengan `restartPolicy` yang bernilai OnFailure atau Never. -- Menggunakan sebuah [ReplicationController](/docs/concepts/workloads/controllers/replicationcontroller/), - [ReplicaSet](/docs/concepts/workloads/controllers/replicaset/), atau - [Deployment](/docs/concepts/workloads/controllers/deployment/) untuk Pod yang tidak diharapkan untuk berakhir, +- Menggunakan sebuah [ReplicationController](/id/docs/concepts/workloads/controllers/replicationcontroller/), + [ReplicaSet](/id/docs/concepts/workloads/controllers/replicaset/), atau + [Deployment](/id/docs/concepts/workloads/controllers/deployment/) untuk Pod yang tidak diharapkan untuk berakhir, sebagai contoh, _web servers_. ReplicationControllers hanya cocok digunakan pada Pod dengan `restartPolicy` yang bernilai Always. -- Menggunakan sebuah [DaemonSet](/docs/concepts/workloads/controllers/daemonset/) untuk Pod yang akan berjalan +- Menggunakan sebuah [DaemonSet](/id/docs/concepts/workloads/controllers/daemonset/) untuk Pod yang akan berjalan hanya satu untuk setiap mesin, karena menyediakan servis yang spesifik untuk suatu mesin. @@ -346,7 +346,7 @@ spec: * Dapatkan pengalaman langsung mengenai [pengaturan _liveness_ dan _readiness probes_](/docs/tasks/configure-pod-container/configure-liveness-readiness-probes/). -* Pelajari lebih lanjut mengenai [_lifecycle hooks_ pada kontainer](/docs/concepts/containers/container-lifecycle-hooks/). +* Pelajari lebih lanjut mengenai [_lifecycle hooks_ pada kontainer](/id/docs/concepts/containers/container-lifecycle-hooks/). diff --git a/content/id/docs/concepts/workloads/pods/pod-overview.md b/content/id/docs/concepts/workloads/pods/pod-overview.md index 0e9593e0d1..f427358999 100644 --- a/content/id/docs/concepts/workloads/pods/pod-overview.md +++ b/content/id/docs/concepts/workloads/pods/pod-overview.md @@ -47,7 +47,7 @@ Setiap *Pod* diberikan sebuah alamat *IP* unik. Setiap kontainer di dalam *Pod* #### Penyimpanan -*Pod* dapat menentukan penyimpanan bersama yaitu *volumes*. Semua kontainer di dalam *Pod* dapat mengakses *volumes* ini, mengizinkan kontainer untuk berbagi data. *Volumes* juga memungkinkan data di *Pod* untuk bertahan jika salah satu kontainer perlu melakukan proses *restart*. Lihat *[Volumes](/docs/concepts/storage/volumes/)* untuk informasi lebih lanjut bagaimana Kubernetes mengimplementasikan penyimpanan di dalam *Pod*. +*Pod* dapat menentukan penyimpanan bersama yaitu *volumes*. Semua kontainer di dalam *Pod* dapat mengakses *volumes* ini, mengizinkan kontainer untuk berbagi data. *Volumes* juga memungkinkan data di *Pod* untuk bertahan jika salah satu kontainer perlu melakukan proses *restart*. Lihat *[Volumes](/id/docs/concepts/storage/volumes/)* untuk informasi lebih lanjut bagaimana Kubernetes mengimplementasikan penyimpanan di dalam *Pod*. ## Bekerja dengan Pod @@ -66,16 +66,16 @@ Kontroler dapat membuat dan mengelola banyak *Pod* untuk kamu, menangani replika Beberapa contoh kontroler yang berisi satu atau lebih *Pod* meliputi: -* [Deployment](/docs/concepts/workloads/controllers/deployment/) -* [StatefulSet](/docs/concepts/workloads/controllers/statefulset/) -* [DaemonSet](/docs/concepts/workloads/controllers/daemonset/) +* [Deployment](/id/docs/concepts/workloads/controllers/deployment/) +* [StatefulSet](/id/docs/concepts/workloads/controllers/statefulset/) +* [DaemonSet](/id/docs/concepts/workloads/controllers/daemonset/) Secara umum, kontroler menggunakan templat *Pod* yang kamu sediakan untuk membuat *Pod*. ## Templat Pod Templat *Pod* adalah spesifikasi dari *Pod* yang termasuk di dalam objek lain seperti -[Replication Controllers](/docs/concepts/workloads/controllers/replicationcontroller/), [Jobs](/docs/concepts/jobs/run-to-completion-finite-workloads/), dan [DaemonSets](/docs/concepts/workloads/controllers/daemonset/). Kontroler menggunakan templat *Pod* untuk membuat *Pod*. +[Replication Controllers](/id/docs/concepts/workloads/controllers/replicationcontroller/), [Jobs](/docs/concepts/jobs/run-to-completion-finite-workloads/), dan [DaemonSets](/id/docs/concepts/workloads/controllers/daemonset/). Kontroler menggunakan templat *Pod* untuk membuat *Pod*. Contoh di bawah merupakan manifestasi sederhana untuk *Pod* yang berisi kontainer yang membuat sebuah pesan. @@ -102,6 +102,6 @@ Perubahan yang terjadi pada templat atau berganti ke templat yang baru tidak mem ## {{% heading "whatsnext" %}} * Pelajari lebih lanjut tentang perilaku *Pod*: - * [Terminasi Pod](/docs/concepts/workloads/pods/pod/#termination-of-pods) - * [Lifecycle Pod](/docs/concepts/workloads/pods/pod-lifecycle/) + * [Terminasi Pod](/id/docs/concepts/workloads/pods/pod/#termination-of-pods) + * [Lifecycle Pod](/id/docs/concepts/workloads/pods/pod-lifecycle/) diff --git a/content/id/docs/concepts/workloads/pods/pod-topology-spread-constraints.md b/content/id/docs/concepts/workloads/pods/pod-topology-spread-constraints.md new file mode 100644 index 0000000000..f1d970a473 --- /dev/null +++ b/content/id/docs/concepts/workloads/pods/pod-topology-spread-constraints.md @@ -0,0 +1,290 @@ +--- +title: Batasan Persebaran Topologi Pod +content_type: concept +weight: 50 +--- + +<!-- overview --> + +{{< feature-state for_k8s_version="v1.18" state="beta" >}} + +Kamu dapat menggunakan batasan perseberan topologi (_topology spread constraints_) +untuk mengatur bagaimana {{< glossary_tooltip text="Pod" term_id="Pod" >}} akan disebarkan +pada klaster yang ditetapkan sebagai _failure-domains_, seperti wilayah, zona, Node dan domain +topologi yang ditentukan oleh pengguna. Ini akan membantu untuk mencapai ketersediaan yang tinggi +dan juga penggunaan sumber daya yang efisien. + + + +<!-- body --> + +## Persyaratan + +### Mengaktifkan Gerbang Fitur + +[Gerbang fitur (_feature gate_)](/docs/reference/command-line-tools-reference/feature-gates/) +`EvenPodsSpread` harus diaktifkan untuk +{{< glossary_tooltip text="API Server" term_id="kube-apiserver" >}} **dan** +{{< glossary_tooltip text="penjadwal (_scheduler_)" term_id="kube-scheduler" >}}. + +### Label Node + +Batasan persebaran topologi bergantung dengan label pada Node untuk menentukan +domain topologi yang memenuhi untuk semua Node. Misalnya saja, sebuah Node bisa memiliki +label sebagai berikut: `node=node1,zone=us-east-1a,region=us-east-1` + +Misalkan kamu memiliki klaster dengan 4 Node dengan label sebagai berikut: + +``` +NAME STATUS ROLES AGE VERSION LABELS +node1 Ready <none> 4m26s v1.16.0 node=node1,zone=zoneA +node2 Ready <none> 3m58s v1.16.0 node=node2,zone=zoneA +node3 Ready <none> 3m17s v1.16.0 node=node3,zone=zoneB +node4 Ready <none> 2m43s v1.16.0 node=node4,zone=zoneB +``` + +Maka klaster tersebut secara logika akan dilihat sebagai berikut: + +``` ++---------------+---------------+ +| zoneA | zoneB | ++-------+-------+-------+-------+ +| node1 | node2 | node3 | node4 | ++-------+-------+-------+-------+ +``` + +Tanpa harus memberi label secara manual, kamu dapat menggunakan [label ternama] +(/docs/reference/kubernetes-api/labels-annotations-taints/) yang terbuat dan terkumpulkan +secara otomatis pada kebanyakan klaster. + +## Batasan Persebaran untuk Pod + +### API + +_Field_ `pod.spec.topologySpreadConstraints` diperkenalkan pada versi 1.16 sebagai berikut: + +```yaml +apiVersion: v1 +kind: Pod +metadata: + name: mypod +spec: + topologySpreadConstraints: + - maxSkew: <integer> + topologyKey: <string> + whenUnsatisfiable: <string> + labelSelector: <object> +``` + +Kamu dapat mendefinisikan satu atau lebih `topologySpreadConstraint` untuk menginstruksikan +kube-scheduler mengenai cara peletakan tiap Pod baru dengan menggunakan kondisi Pod yang +sudah ada dalam klaster kamu. _Field_ yang ada adalah: + +- **maxSkew** menentukan batasan yang menandakan Pod tidak tersebar secara merata. +Ini merupakan nilai maksimal dari selisih jumlah Pod yang sama untuk setiap 2 domain topologi +yang sama. Nilai ini harus lebih dari 0. +- **topologyKey** adalah kunci dari label Node. Jika terdapat dua Node memiliki label dengan +kunci ini dan memiliki nilai yang identik untuk label tersebut, maka penjadwal akan menganggap +kedua Noode dalam topologi yang sama. Penjadwal akan mencoba untuk menyeimbangkan jumlah Pod +dalam setiap domain topologi. +- **whenUnsatisfiable** mengindikasikan cara menangani Pod yang tidak memenuhi batasan persebaran: + - `DoNotSchedule` (_default_) memberitahukan penjadwal untuk tidak menjadwalkan Pod tersebut. + - `ScheduleAnyway` memberitahukan penjadwal untuk tetap menjadwalkan Pod namun tetap menjaga ketidakseimbangan Node sekecil mungkin. +- **labelSelector** digunakan untuk mencari Pod yang sesuai. Pod dengan label yang sama dengan ini akan dihitung untuk menentukan jumlah Pod dalam domain topologi yang sesuai. Silakan baca [Label dan Selector](/id/docs/concepts/overview/working-with-objects/labels/#selektor-label) untuk lebih detailnya. + +Kamu juga bisa membaca lebih detail mengenai _field_ ini dengan menjalankan perintah +`kubectl explain Pod.spec.topologySpreadConstraints`. + +### Contoh: Satu TopologySpreadConstraint + +Misalkan kamu memiliki klaster dengan 4 Node dimana 3 Pod berlabel `foo:bar` terdapat pada node1, +node2 dan node3 (`P` merepresentasikan Pod): + +``` ++---------------+---------------+ +| zoneA | zoneB | ++-------+-------+-------+-------+ +| node1 | node2 | node3 | node4 | ++-------+-------+-------+-------+ +| P | P | P | | ++-------+-------+-------+-------+ +``` + +Jika kita ingin Pod baru akan disebar secara merata berdasarkan Pod yang telah ada pada semua zona, +maka _spec_ bernilai sebagai berikut: + +{{< codenew file="pods/topology-spread-constraints/one-constraint.yaml" >}} + +`topologyKey: zone` berarti persebaran merata hanya akan digunakan pada Node dengan pasangan label +"zone: <nilai apapun>". `whenUnsatisfiable: DoNotSchedule` memberitahukan penjadwal untuk membiarkan +tetap ditunda jika Pod yang baru tidak memenuhi batasan yang diterapkan. + +Jika penjadwal menempatkan Pod baru pada "zoneA", persebaran Pod akan menjadi [3, 1], menjadikan +ketidakseimbangan menjadi bernilai 2 (3 - 1), yang mana akan melanggar batasan `maxSkew: 1`. +Dalam contoh ini, Pod baru hanya dapat ditempatkan pada "zoneB": + +``` ++---------------+---------------+ +---------------+---------------+ +| zoneA | zoneB | | zoneA | zoneB | ++-------+-------+-------+-------+ +-------+-------+-------+-------+ +| node1 | node2 | node3 | node4 | OR | node1 | node2 | node3 | node4 | ++-------+-------+-------+-------+ +-------+-------+-------+-------+ +| P | P | P | P | | P | P | P P | | ++-------+-------+-------+-------+ +-------+-------+-------+-------+ +``` + +Kamu dapat mengatur spesifikasi Pod untuk memenuhi beberapa persyaratan berikut: + +- Ubah nilai `maxSkew` menjadi lebih besar, misal "2", sehingga Pod baru dapat ditempatkan pada "zoneA". +- Ubah nilai `topologyKey` menjadi "node" agar Pod disebarkan secara merata pada semua Node, bukan zona. Pada contoh di atas, jika `maxSkew` tetap bernilai "1", maka Pod baru hanya akan ditempatkan pada "node4". +- Ubah nilai `whenUnsatisfiable: DoNotSchedule` menjadi `whenUnsatisfiable: ScheduleAnyway` untuk +menjamin agar semua Pod baru akan tetap dijadwalkan (misalkan saja API penjadwalan lain tetap +terpenuhi). Namun, ini lebih suka ditempatkan pada domain topologi yang memiliki lebih sedikit +Pod yang sesuai. (Harap diperhatikan bahwa preferensi ini digabungkan bersama dengan prioritas +penjadwalan internal yang lain, seperti rasio penggunaan sumber daya, dan lain sebagainya.) + +### Contoh: Beberapa TopologySpreadConstraint + +Ini dibuat berdasarkan contoh sebelumnya. Misalkan kamu memiliki klaster dengan 4 Node dengan +3 Pod berlabel `foo:bar` yang ditempatkan pada node1, node2 dan node3. (`P` merepresentasikan Pod): + +``` ++---------------+---------------+ +| zoneA | zoneB | ++-------+-------+-------+-------+ +| node1 | node2 | node3 | node4 | ++-------+-------+-------+-------+ +| P | P | P | | ++-------+-------+-------+-------+ +``` + +Kamu dapat menggunakan 2 TopologySpreadConstraint untuk mengatur persebaran Pod pada zona dan Node: + +{{< codenew file="pods/topology-spread-constraints/two-constraints.yaml" >}} + +Dalam contoh ini, untuk memenuhi batasan pertama, Pod yang baru hanya akan ditempatkan pada "zoneB", +sedangkan untuk batasan kedua, Pod yang baru hanya akan ditempatkan pada "node4". Maka hasil dari +2 batasan ini akan digunakan (_AND_), sehingga opsi untuk menempatkan Pod hanya pada "node4". + +Beberapa batasan dapat berujung pada konflik. Misalnya saja kamu memiliki klaster dengan 3 Node +pada 2 zona berbeda: + +``` ++---------------+-------+ +| zoneA | zoneB | ++-------+-------+-------+ +| node1 | node2 | node3 | ++-------+-------+-------+ +| P P | P | P P | ++-------+-------+-------+ +``` + +Jika kamu menerapkan "two-constraints.yaml" pada klaster ini, kamu akan mendapatkan "mypod" tetap +dalam kondisi `Pending`. Ini dikarenakan oleh: untuk memenuhi batasan pertama, "mypod" hanya dapat +ditempatkan pada "zoneB", sedangkan untuk batasan kedua, "mypod" hanya dapat ditempatkan pada +"node2". Tidak ada hasil penggabungan dari "zoneB" dan "node2". + +Untuk mengatasi situasi ini, kamu bisa menambahkan nilai `maxSkew` atau mengubah salah satu dari +batasan untuk menggunakan `whenUnsatisfiable: ScheduleAnyway`. + +### Konvensi + +Ada beberapa konvensi implisit yang perlu diperhatikan di sini: + +- Hanya Pod dengan Namespace yang sama dengan Pod baru yang bisa menjadi kandidat yang cocok. + +- Node tanpa memiliki `topologySpreadConstraints[*].topologyKey` akan dilewatkan. Ini berarti: + 1. Pod yang ditempatkan pada Node tersebut tidak berpengaruh pada perhitungan `maxSkew`. Dalam contoh di atas, misalkan "node1" tidak memiliki label "zone", maka kedua Pod tidak diperhitungkan dan menyebabkan Pod yang baru akan dijadwalkan masuk ke "zoneA". + 2. Pod yang baru tidak memiliki kesempatan untuk dijadwalkan ke Node tersebut, pada contoh di atas, misalkan terdapat "node5" dengan label `{zone-typo: zoneC}` bergabung dalam klaster, Node ini akan dilewatkan karena tidak memiliki label dengan kunci "zone". + +- Harap diperhatikan mengenai hal yang terjadi jika nilai `topologySpreadConstraints[*].labelSelector` pada Pod yang baru tidak sesuai dengan labelnya. +Pada contoh di atas, jika kita menghapus label pada Pod yang baru, maka Pod akan tetap ditempatkan +pada "zoneB" karena batasan yang ada masih terpenuhi. Namun, setelah ditempatkan, nilai +ketidakseimbangan pada klaster masih tetap tidak berubah, zoneA tetap memiliki 2 Pod dengan label +{foo:bar} dan zoneB memiliki 1 Pod dengan label {foo:bar}. Jadi jika ini tidak yang kamu harapkan, +kami menyarankan nilai dari `topologySpreadConstraints[*].labelSelector` disamakan dengan labelnya. + +- Jika Pod yang baru memiliki `spec.nodeSelector` atau `spec.affinity.nodeAffinity`, Node yang tidak +sesuai dengan nilai tersebut akan dilewatkan. + + Misalkan kamu memiliki klaster dengan 5 Node dari zoneA sampai zoneC: + + ``` + +---------------+---------------+-------+ + | zoneA | zoneB | zoneC | + +-------+-------+-------+-------+-------+ + | node1 | node2 | node3 | node4 | node5 | + +-------+-------+-------+-------+-------+ + | P | P | P | | | + +-------+-------+-------+-------+-------+ + ``` + + dan kamu mengetahui bahwa "zoneC" harus tidak diperhitungkan. Dalam kasus ini, kamu dapat membuat + berkas yaml seperti di bawah, jadi "mypod" akan ditempatkan pada "zoneB", bukan "zoneC". + Demikian juga `spec.nodeSelector` akan digunakan. + + {{< codenew file="pods/topology-spread-constraints/one-constraint-with-nodeaffinity.yaml" >}} + +### Batasan _default_ pada tingkat klaster + +{{< feature-state for_k8s_version="v1.18" state="alpha" >}} + +Ini memungkinkan untuk mengatur batasan persebaran topologi bawaan untuk klaster. +Batasan persebaran topologi bawaan akan digunakan pada Pod jika dan hanya jika: + +- Hal ini tidak mendefinisikan batasan apapun pada `.spec.topologySpreadConstraints`. +- Hal ini milik sebuah Service, ReplicationController, ReplicaSet atau StatefulSet. + +Batasan bawaan akan diatur sebagai bagian dari argumen pada _plugin_ `PodTopologySpread` +di dalam sebuah [profil penjadwalan](/docs/reference/scheduling/profiles). +Batasan dispesifikasikan dengan [API yang sama dengan di atas](#api), kecuali bagian `labelSelector` +harus kosong. _selector_ akan dihitung dari Service, ReplicationController, ReplicaSet atau +StatefulSet yang dimiliki oleh Pod tersebut. + +Sebuah contoh konfigurasi sebagai berikut: + + +```yaml +apiVersion: kubescheduler.config.k8s.io/v1alpha2 +kind: KubeSchedulerConfiguration + +profiles: + pluginConfig: + - name: PodTopologySpread + args: + defaultConstraints: + - maxSkew: 1 + topologyKey: failure-domain.beta.kubernetes.io/zone + whenUnsatisfiable: ScheduleAnyway +``` + +{{< note >}} +Nilai yang dihasilkan oleh batasan penjadwalan bawaan mungkin akan konflik dengan +nilai yang dihasilkan oleh +[`DefaultPodTopologySpread` plugin](/docs/reference/scheduling/profiles/#scheduling-plugins). +Direkomendasikan untuk kamu menonaktifkan _plugin_ ini dalam profil penjadwalan ketika +menggunakan batasan _default_ untuk `PodTopologySpread`. +{{< /note >}} + +## Perbandingan dengan PodAffinity/PodAntiAffinity + +Di Kubernetes, arahan yang terkait dengan "Afinitas" mengontrol bagaimana Pod dijadwalkan - +lebih terkumpul atau lebih tersebar. + +- Untuk `PodAffinity`, kamu dapat mencoba mengumpulkan beberapa Pod ke dalam suatu +domain topologi yang memenuhi syarat. +- Untuk `PodAntiAffinity`, hanya satu Pod yang dalam dijadwalkan pada sebuah domain topologi. + +Fitur "EvenPodsSpread" memberikan opsi fleksibilas untuk mendistribusikan Pod secara merata +pada domain topologi yang berbeda, untuk meraih ketersediaan yang tinggi atau menghemat biaya. +Ini juga dapat membantu saat perbaruan bergilir dan menaikan jumlah replika dengan lancar. +Silakan baca [motivasi](https://github.com/kubernetes/enhancements/blob/master/keps/sig-scheduling/20190221-even-pods-spreading.md#motivation) untuk lebih detail. + +## Limitasi yang diketahui + +Pada versi 1.18, dimana fitur ini masih Beta, beberapa limitasi yang sudah diketahui: + +- Pengurangan jumlah Deployment akan membuat ketidakseimbangan pada persebaran Pod. +- Pod yang cocok pada _tainted_ Node akan dihargai. Lihat [Issue 80921](https://github.com/kubernetes/kubernetes/issues/80921) + + diff --git a/content/id/docs/concepts/workloads/pods/pod.md b/content/id/docs/concepts/workloads/pods/pod.md index 3838ec56b5..e25a3a9104 100644 --- a/content/id/docs/concepts/workloads/pods/pod.md +++ b/content/id/docs/concepts/workloads/pods/pod.md @@ -39,7 +39,7 @@ dan bisa saling berkomunikasi melalui `localhost`. Komunikasi tersebut mengunaka standar _inter-process communications_ (IPC) seperti SystemV semaphores atau POSIX shared memory. Kontainer pada Pod yang berbeda memiliki alamat IP yang berbeda dan tidak dapat berkomunikasi menggunakan IPC tanpa -[pengaturan khusus](/docs/concepts/policy/pod-security-policy/). Kontainer ini +[pengaturan khusus](/id/docs/concepts/policy/pod-security-policy/). Kontainer ini biasa berkomunikasi dengan yang lain menggunakan alamat IP setiap Pod. Aplikasi dalam suatu Pod juga memiliki akses ke {{< glossary_tooltip text="ruang penyimpanan" term_id="volume" >}} bersama, @@ -51,14 +51,14 @@ gabungan dari kontainer Docker yang berbagi _namespace_ dan ruang penyimpanan _f Layaknya aplikasi dengan kontainer, Pod dianggap sebagai entitas yang relatif tidak kekal (tidak bertahan lama). Seperti yang didiskusikan dalam -[siklus hidup Pod](/docs/concepts/workloads/pods/pod-lifecycle/), Pod dibuat, diberikan +[siklus hidup Pod](/id/docs/concepts/workloads/pods/pod-lifecycle/), Pod dibuat, diberikan ID unik (UID), dan dijadwalkan pada suatu mesin dan akan tetap disana hingga dihentikan (bergantung pada aturan _restart_) atau dihapus. Jika {{< glossary_tooltip text="mesin" term_id="node" >}} mati, maka semua Pod pada mesin tersebut akan dijadwalkan untuk dihapus, namun setelah suatu batas waktu. Suatu Pod tertentu (sesuai dengan ID unik) tidak akan dijadwalkan ulang ke mesin baru, namun akan digantikan oleh Pod yang identik, bahkan jika dibutuhkan bisa dengan nama yang sama, tapi dengan ID unik yang baru -(baca [_replication controller_](/docs/concepts/workloads/controllers/replicationcontroller/) +(baca [_replication controller_](/id/docs/concepts/workloads/controllers/replicationcontroller/) untuk info lebih lanjut) Ketika sesuatu dikatakan memiliki umur yang sama dengan Pod, misalnya saja ruang penyimpanan, @@ -96,7 +96,7 @@ dan Pod lain dalam jaringan yang sama. Kontainer dalam suatu Pod melihat _hostname_ sistem sebagai sesuatu yang sama dengan konfigurasi `name` pada Pod. Informasi lebih lanjut terdapat dibagian -[jaringan](/docs/concepts/cluster-administration/networking/). +[jaringan](/id/docs/concepts/cluster-administration/networking/). Sebagai tambahan dalam mendefinisikan kontainer aplikasi yang berjalan dalam Pod, Pod memberikan sepaket sistem penyimpanan bersama. Sistem penyimpanan memungkinkan @@ -153,10 +153,10 @@ kasus mesin sedang dalam pemeliharaan. Secara umum, pengguna tidak seharusnya butuh membuat Pod secara langsung. Mereka seharusnya selalu menggunakan pengontrol, sekalipun untuk yang tunggal, misalnya, -[_Deployment_](/docs/concepts/workloads/controllers/deployment/). Pengontrol +[_Deployment_](/id/docs/concepts/workloads/controllers/deployment/). Pengontrol menyediakan penyembuhan diri dengan ruang lingkup kelompok, begitu juga dengan pengelolaan replikasi dan penluncuran. -Pengontrol seperti [_StatefulSet_](/docs/concepts/workloads/controllers/statefulset.md) +Pengontrol seperti [_StatefulSet_](/id/docs/concepts/workloads/controllers/statefulset.md) bisa memberikan dukungan terhadap Pod yang _stateful_. Penggunaan API kolektif sebagai _user-facing primitive_ utama adalah hal yang @@ -202,7 +202,7 @@ bersama dengan masa tenggang. 1. (bersamaan dengan poin 3) Ketika Kubelet melihat Pod sudah ditandai sebagai "Terminating" karena waktu pada poin 2 sudah diatur, ini memulai proses penghentian Pod 1. Jika salah satu kontainer pada Pod memiliki - [preStop _hook_](/docs/concepts/containers/container-lifecycle-hooks/#hook-details), + [preStop _hook_](/id/docs/concepts/containers/container-lifecycle-hooks/#hook-details), maka akan dipanggil di dalam kontainer. Jika `preStop` _hook_ masih berjalan setelah masa tenggang habis, langkah 2 akan dipanggil dengan tambahan masa tenggang yang sedikit, 2 detik. @@ -223,7 +223,7 @@ Secara _default_, semua penghapusan akan berjalan normal selama 30 detik. Perint `kubectl delete` mendukung opsi `--grace-period=<waktu dalam detik>` yang akan memperbolehkan pengguna untuk menimpa nilai awal dan memberikan nilai sesuai keinginan pengguna. Nilai `0` akan membuat Pod -[dihapus paksa](/docs/concepts/workloads/pods/pod/#force-deletion-of-pods). +[dihapus paksa](/id/docs/concepts/workloads/pods/pod/#force-deletion-of-pods). Kamu harus memberikan opsi tambahan `--force` bersamaan dengan `--grace-period=0` untuk melakukan penghapusan paksa. @@ -243,7 +243,7 @@ dokumentasi untuk [penghentian Pod dari StatefulSet](/docs/tasks/run-application ## Hak istimewa untuk kontainer pada Pod Setiap kontainer dalam Pod dapat mengaktifkan hak istimewa (mode _privileged_), dengan menggunakan tanda -`privileged` pada [konteks keamanan](/docs/tasks/configure-pod-container/security-context/) +`privileged` pada [konteks keamanan](/id/docs/tasks/configure-pod-container/security-context/) pada spesifikasi kontainer. Ini akan berguna untuk kontainer yang ingin menggunakan kapabilitas Linux seperti memanipulasi jaringan dan mengakses perangkat. Proses dalam kontainer mendapatkan hak istimewa yang hampir sama dengan proses di luar kontainer. diff --git a/content/id/docs/concepts/workloads/pods/podpreset.md b/content/id/docs/concepts/workloads/pods/podpreset.md index 2fc1b8598b..9b899c4687 100644 --- a/content/id/docs/concepts/workloads/pods/podpreset.md +++ b/content/id/docs/concepts/workloads/pods/podpreset.md @@ -57,6 +57,6 @@ Dalam rangka untuk menggunakan Pod Preset di dalam klaster kamu, kamu harus mema ## {{% heading "whatsnext" %}} - * [Memasukkan data ke dalam sebuah Pod dengan PodPreset](/docs/concepts/workloads/pods/pod/#injecting-data-into-a-pod-using-podpreset.md) + * [Memasukkan data ke dalam sebuah Pod dengan PodPreset](/id/docs/concepts/workloads/pods/pod/#injecting-data-into-a-pod-using-podpreset.md) diff --git a/content/id/docs/contribute/participate/_index.md b/content/id/docs/contribute/participate/_index.md new file mode 100644 index 0000000000..72c561432b --- /dev/null +++ b/content/id/docs/contribute/participate/_index.md @@ -0,0 +1,116 @@ +--- +title: Berpartisipasi dalam SIG Docs +content_type: concept +weight: 60 +card: + name: contribute + weight: 60 +--- + +<!-- overview --> + +SIG Docs merupakan salah satu +[kelompok peminatan khusus (_special interest groups_)](https://github.com/kubernetes/community/blob/master/sig-list.md) +dalam proyek Kubernetes, yang berfokus pada penulisan, pembaruan, dan pemeliharaan +dokumentasi untuk Kubernetes secara keseluruhan. Lihatlah +[SIG Docs dari repositori github komunitas](https://github.com/kubernetes/community/tree/master/sig-docs) +untuk informasi lebih lanjut tentang SIG. + +SIG Docs menerima konten dan ulasan dari semua kontributor. Siapa pun dapat membuka +_pull request_ (PR), dan siapa pun boleh mengajukan isu tentang konten atau komen +pada _pull request_ yang sedang berjalan. + +Kamu juga bisa menjadi [anggota (_member_)](/id/docs/contribute/participating/roles-and-responsibilities/#anggota), +[pengulas (_reviewer_](/id/docs/contribute/participating/roles-and-responsibilities/#pengulas), atau [pemberi persetujuan (_approver_)](/id/docs/contribute/participating/roles-and-responsibilities/#approvers). Peran tersebut membutuhkan +akses dan mensyaratkan tanggung jawab tertentu untuk menyetujui dan melakukan perubahan. +Lihatlah [keanggotaan-komunitas (_community-membership_)](https://github.com/kubernetes/community/blob/master/community-membership.md) +untuk informasi lebih lanjut tentang cara kerja keanggotaan dalam komunitas Kubernetes. + +Selebihnya dari dokumen ini akan menguraikan beberapa cara unik dari fungsi peranan tersebut dalam +SIG Docs, yang bertanggung jawab untuk memelihara salah satu aspek yang paling berhadapan dengan publik +dalam Kubernetes - situs web dan dokumentasi dari Kubernetes. + + +<!-- body --> + +## Ketua umum (_chairperson_) SIG Docs {#ketua-umum-sig-docs} + +Setiap SIG, termasuk SIG Docs, memilih satu atau lebih anggota SIG untuk bertindak sebagai +ketua umum. Mereka merupakan kontak utama antara SIG Docs dan bagian lain dari +organisasi Kubernetes. Mereka membutuhkan pengetahuan yang luas tentang struktur +proyek Kubernetes secara keseluruhan dan bagaimana SIG Docs bekerja di dalamnya. Lihatlah +[Kepemimpinan (_leadership_)](https://github.com/kubernetes/community/tree/master/sig-docs#leadership) +untuk daftar ketua umum yang sekarang. + +## Tim dan automasi dalam SIG Docs + +Automasi dalam SIG Docs bergantung pada dua mekanisme berbeda: +Tim GitHub dan berkas OWNERS. + +### Tim GitHub + +Terdapat dua kategori tim dalam SIG Docs [tim (_teams_)](https://github.com/orgs/kubernetes/teams?query=sig-docs) dalam GitHub: + +- `@sig-docs-{language}-owners` merupakan pemberi persetujuan (_approver_) dan pemimpin (_lead_) +- `@sig-docs-{language}-reviewers` merupakan pengulas (_reviewer_) + +Setiap tim dapat direferensikan dengan `@name` mereka dalam komen GitHub untuk berkomunikasi dengan setiap orang di dalam grup. + +Terkadang tim Prow dan GitHub tumpang tindih (_overlap_) tanpa kecocokan sama persis. Untuk penugasan masalah, _pull request_, dan untuk mendukung persetujuan PR, +otomatisasi menggunakan informasi dari berkas `OWNERS`. + + +### Berkas OWNERS dan bagian yang utama (_front-matter_) + +Proyek Kubernetes menggunakan perangkat otomatisasi yang disebut prow untuk melakukan automatisasi +yang terkait dengan isu dan _pull request_ dalam GitHub. +[Repositori situs web Kubernetes](https://github.com/kubernetes/website) menggunakan +dua buah [prow _plugin_](https://github.com/kubernetes/test-infra/tree/master/prow/plugins): + +- blunderbuss +- approve + +Kedua _plugin_ menggunakan berkas +[OWNERS](https://github.com/kubernetes/website/blob/master/OWNERS) dan +[OWNERS_ALIASES](https://github.com/kubernetes/website/blob/master/OWNERS_ALIASES) +dalam level teratas dari repositori GitHub `kubernetes/website` untuk mengontrol +bagaimana prow bekerja di dalam repositori. + +Berkas OWNERS berisi daftar orang-orang yang menjadi pengulas dan pemberi persetujuan di dalam SIG Docs. +Berkas OWNERS juga bisa terdapat di dalam subdirektori, dan dapat menimpa peranan karena +dapat bertindak sebagai pengulas atau pemberi persetujuan berkas untuk subdirektori itu dan +apa saja yang ada di dalamnya. Untuk informasi lebih lanjut tentang berkas OWNERS pada umumnya, lihatlah +[OWNERS](https://github.com/kubernetes/community/blob/master/contributors/guide/owners.md). + +Selanjutnya, berkas _markdown_ individu dapat menyimpan daftar pengulas dan pemberi persetujuan +pada bagian yang utama, baik dengan menyimpan daftar nama pengguna individu GitHub atau grup GitHub. + +Kombinasi dari berkas OWNERS dan bagian yang utama dalam berkas _markdown_ menentukan +saran kepada pemilik PR yang didapat dari sistem otomatis tentang siapa yang akan meminta ulasan teknis +dan ulasan editorial untuk PR mereka. + +## Cara menggabungkan pekerjaan + +Ketika _pull request_ digabungkan ke cabang (_branch_) yang digunakan untuk mempublikasikan konten, konten itu dipublikasikan di http://kubernetes.io. Untuk memastikan bahwa +kualitas konten yang kita terbitkan bermutu tinggi, kita membatasi penggabungan _pull request_ bagi para pemberi persetujuan +SIG Docs. Beginilah cara kerjanya. + +- Ketika _pull request_ memiliki label `lgtm` dan `approve`, tidak memiliki label `hold`, + dan telah lulus semua tes, _pull request_ akan digabungkan secara otomatis. +- Anggota organisasi Kubernetes dan pemberi persetujuan SIG Docs dapat menambahkan komen + untuk mencegah penggabungan otomatis dari _pull request_ yang diberikan (dengan menambahkan komen `/hold` + atau menahan komen `/lgtm`). +- Setiap anggota Kubernetes dapat menambahkan label `lgtm` dengan menambahkan komen `lgtm` +- Hanya pemberi persetujuan SIG Docs yang bisa menggabungkan _pull request_ + dengan menambahkan komen `/approve`. Beberapa pemberi persetujuan juga dapat melakukan + tugas tambahan seperti [PR _Wrangler_](/id/docs/contribute/advanced#menjadi-pr-wrangler-untuk-seminggu) atau + [Ketua Umum SIG Docs](#ketua-umum-sig-docs). + + +## {{% heading "whatsnext" %}} + +Untuk informasi lebih lanjut tentang cara berkontribusi pada dokumentasi Kubernetes, lihatlah: + +- [Berkontribusi konten baru](/id/docs/contribute/overview/) +- [Mengulas konten](/id/docs/contribute/review/reviewing-prs) +- [Panduan gaya dokumentasi](/id/docs/contribute/style/) diff --git a/content/id/docs/contribute/suggesting-improvements.md b/content/id/docs/contribute/suggesting-improvements.md new file mode 100644 index 0000000000..588bebeb6d --- /dev/null +++ b/content/id/docs/contribute/suggesting-improvements.md @@ -0,0 +1,65 @@ +--- +title: Menyarankan peningkatan kualitas konten +slug: suggest-improvements +content_type: concept +weight: 10 +card: + name: contribute + weight: 20 +--- + +<!-- overview --> + +Jika kamu menemukan masalah pada dokumentasi Kubernetes, atau mempunyai ide untuk +konten baru, maka silakan untuk membuat isu pada Github. Kamu hanya membutuhkan +sebuah [akun Github](https://github.com/join) dan sebuah _web browser_. + +Pada kebanyakan kasus, pekerjaan dalam dokumentasi Kubernetes diawali dengan sebuah +isu pada Github. Kontributor Kubernetes akan mengkaji, mengkategorisasi dan menandai isu +sesuai kebutuhan. Selanjutnya, kamu atau anggota lain dari komunitas Kubernetes dapat membuat +_pull request_ dengan perubahan yang akan menyelesaikan masalahnya. + +<!-- body --> + +## Membuka sebuah issue + +Jika kamu mau menyarankan peningkatan kualitas pada konten yang sudah ada, atau menemukan kesalahan, +maka silakan membuka sebuah isu. + +1. Turun ke bagian bawah dari suatu halaman dan klik pada tombol **Buat Isu**. Ini akan +mengantarmu pada halaman Github isu dengan beberapa tajuk yang telah diisi. +2. Deskripsikan isu atau saran untuk peningkatan kualitas. Sediakan detail sebanyak mungkin yang kamu bisa. +3. Klik **Submit new issue** + +Setelah dikirim, cek isu yang kamu buat secara berkala atau hidupkan notifikasi Github. +Pengulas (_reviewer_) atau anggota komunitas lainnya mungkin akan menanyakan pertanyaan +sebelum mereka mengambil suatu tindakan terhadap isumu. + +## Menyarankan konten baru + +Jika kamu memiliki ide untuk konten baru, tapi kamu tidak yakin dimana mengutarakannya, +kamu tetap dapat membuat sebuah isu. Antara lain: + +- Pilih halaman pada bagian yang menurutmu konten tersebut berhubungan dan klik **Buat Isu**. +- Pergi ke [Github](https://github.com/kubernetes/website/issues/new/) dan langsung membuat isu. + +## Bagaimana cara membuat isu yang bagus + +Perhatikan hal berikut ketika membuat sebuah isu: + +- Memberikan deskripsi isu yang jelas. Deskripsikan apa yang memang kurang, tertinggal, + salah atau konten mana yang memerlukan peningkatan kualitas. +- Jelaskan dampak spesifik dari isu terhadap pengguna. +- Batasi cakupan dari sebuah isu menjadi ukuran pekerjaan yang masuk akal. + Untuk masalah dengan cakupan yang besar, pecah isu itu menjadi beberapa isu lebih kecil. + Misal, "Membenahi dokumentasi keamanan" masih sangat luas cakupannya, tapi "Penambahan + detail pada topik 'Pembatasan akses jaringan'" adalah lebih spesifik untuk dikerjakan. +- Mencari isu yang sudah ada untuk melihat apakah ada sesuatu yang berhubungan atau + mirip dengan isu yang baru. +- Jika isu yang baru berhubungan dengan isu lain atau _pull request_, tambahkan rujukan + dengan menuliskan URL lengkap atau dengan nomor isu atau _pull request_ yang diawali dengan + karakter `#`. Contohnya, `Diajukan oleh #987654`. +- Mengikuti [Kode Etik Komunitas](/id/community/code-of-conduct/). Menghargai kontributor lain. + Misalnya, "Dokumentasi ini sangat jelek" adalah contoh yang tidak membantu dan juga bukan + masukan yang sopan. + diff --git a/content/id/docs/reference/access-authn-authz/rbac.md b/content/id/docs/reference/access-authn-authz/rbac.md new file mode 100644 index 0000000000..49aa20ed6e --- /dev/null +++ b/content/id/docs/reference/access-authn-authz/rbac.md @@ -0,0 +1,1195 @@ +--- +title: Menggunakan Otorisasi RBAC +content_type: concept +aliases: [../../../rbac/] +weight: 70 +--- + +<!-- overview --> +Kontrol akses berbasis peran (RBAC) adalah metode pengaturan akses ke sumber daya komputer +atau jaringan berdasarkan peran pengguna individu dalam organisasi kamu. + + +<!-- body --> +Otorisasi RBAC menggunakan `rbac.authorization.k8s.io` kelompok API untuk mengendalikan keputusan +otorisasi, memungkinkan kamu untuk mengkonfigurasi kebijakan secara dinamis melalui API Kubernetes. + +Untuk mengaktifkan RBAC, jalankan Kubernetes dengan _flag_ `--authorization-mode` atur +dengan daftar yang dipisahkan koma dengan menyertakan `RBAC`; +sebagai contoh: +```shell +kube-apiserver --authorization-mode=Example,RBAC --other-options --more-options +``` + +## Objek API {#api-overview} + +API RBAC mendeklarasikan empat jenis objek Kubernetes: Role, ClusterRole, +RoleBinding and ClusterRoleBinding. kamu bisa [mendeskripsikan beberapa objek](/id/docs/concepts/overview/working-with-objects/kubernetes-objects/#understanding-kubernetes-objects), atau mengubahnya menggunakan alat seperti `kubectl`, seperti objek Kubernetes lain. + +{{< caution >}} +Objek-objek ini, dengan disengaja, memaksakan pembatasan akses. Jika kamu melakukan perubahan +ke klaster saat kamu belajar, lihat +[pencegahan eskalasi hak istimewa dan _bootstrap_](#privilege-eskalasi-pencegahan-dan-bootstrap) +untuk memahami bagaimana pembatasan tersebut dapat mencegah kamu melakukan beberapa perubahan. +{{< /caution >}} + +### Role dan ClusterRole + +Sebuah RBAC Role atau ClusterRole berisi aturan yang mewakili sekumpulan izin. +Izin bersifat aditif (tidak ada aturan "tolak"). + +Sebuah Role selalu mengatur izin dalam Namespace tertentu; +ketika kamu membuat Role, kamu harus menentukan Namespace tempat Role tersebut berada. + +ClusterRole, sebaliknya, adalah sumber daya tanpa Namespace. Sumber daya tersebut memiliki nama yang berbeda (Role +dan ClusterRole) karena objek Kubernetes selalu harus menggunakan Namespace atau tanpa Namespace; +tidak mungkin keduanya. + +ClusterRole memiliki beberapa kegunaan. Kamu bisa menggunakan ClusterRole untuk: + +1. mendefinisikan izin pada sumber daya dalam Namespace dan diberikan dalam sebuah Namespace atau lebih +1. mendefinisikan izin pada sumber daya dalam Namespace dan diberikan dalam seluruh Namespace +1. mendefinisikan izin pada sumber daya yang dicakup klaster + +Jika kamu ingin mendefinisikan sebuah peran dalam Namespace, gunakan Role; jika kamu ingin mendefinisikan +peran di level klaster, gunakan ClusterRole. + +#### Contoh Role + +Berikut adalah contoh Role dalam Namespace bawaan yang dapat digunakan +untuk memberikan akses baca pada Pod: + +```yaml +apiVersion: rbac.authorization.k8s.io/v1 +kind: Role +metadata: + Namespace: default + name: pod-reader +rules: +- apiGroups: [""] # "" mengindikasikan core API group + resources: ["pods"] + verbs: ["get", "watch", "list"] +``` + +#### Contoh ClusterRole + +ClusterRole dapat digunakan untuk memberikan izin yang sama dengan Role. +Karena ClusterRole memiliki lingkup-klaster, kamu juga dapat menggunakannya untuk memberikan akses ke: + +* sumber daya lingkup-klaster (seperti Nodes) +* berbagai _endpoint_ non-sumber daya (seperti `/healthz`) +* sumber daya Namespace (seperti Pod), di semua Namespace + Sebagai contoh: kamu bisa menggunakan ClusterRole untuk memungkinkan pengguna tertentu untuk menjalankan +`kubectl get pods --all-namespaces`. + +Berikut adalah contoh ClusterRole yang dapat digunakan untuk memberikan akses baca pada +Secret di Namespace tertentu, atau di semua Namespace (tergantung bagaimana itu [terikat](#rolebinding-dan-clusterrolebinding)): + +```yaml +apiVersion: rbac.authorization.k8s.io/v1 +kind: ClusterRole +metadata: + # "namespace" dihilangkan karena ClusterRole tidak menggunakan Namespace + name: secret-reader +rules: +- apiGroups: [""] + # +  # di tingkat HTTP, nama sumber daya untuk mengakses objek Secret +  # adalah "secrets" + resources: ["secrets"] + verbs: ["get", "watch", "list"] +``` + +Nama objek Role dan ClusterRole harus menggunakan [nama _path segment_](/id/docs/concepts/overview/working-with-objects/names#path-segment-names) yang valid. + +### RoleBinding dan ClusterRoleBinding + +Sebuah RoleBinding memberikan izin yang ditentukan dalam sebuah Role kepada pengguna atau sekelompok pengguna. +Ini menyimpan daftar subjek (pengguna, grup, atau ServiceAccount), dan referensi ke +Role yang diberikan. +RoleBinding memberikan izin dalam Namespace tertentu sedangkan ClusterRoleBinding +memberikan akses tersebut pada lingkup klaster. + +RoleBinding dapat merujuk Role apa pun di Namespace yang sama. Atau, RoleBinding +dapat mereferensikan ClusterRole dan memasangkan ClusterRole tersebut ke Namespace dari RoleBinding. +Jika kamu ingin memasangkan ClusterRole ke semua Namespace di klaster kamu, kamu dapat menggunakan +ClusterRoleBinding. + +Nama objek RoleBinding atau ClusterRoleBinding harus valid menggunakan +[nama _path segment_](/id/docs/concepts/overview/working-with-objects/names#path-segment-names) yang valid. + +#### Contoh RoleBinding + +Berikut adalah contoh dari RoleBinding yang memberikan Role "pod-reader" kepada pengguna "jane" +pada Namespace bawaan. +Ini memungkinkan "jane" untuk membaca Pod di Namespace bawaan. + +```yaml +apiVersion: rbac.authorization.k8s.io/v1 +# Role binding memungkinkan "jane" untuk membaca Pod di Namespace bawaan +# Kamu harus sudah memiliki Role bernama "pod-reader" di Namespace tersebut. +kind: RoleBinding +metadata: + name: read-pods + namespace: default +subjects: +# Kamu bisa mencantumkan lebih dari satu "subjek" +- kind: User + name: jane # "name" peka huruf besar-kecil + apiGroup: rbac.authorization.k8s.io +roleRef: + # "roleRef" menentukan pengikatan ke Role / ClusterRole + kind: Role # ini harus Role atau ClusterRole + name: pod-reader # ini harus sesuai dengan nama Role atau ClusterRole yang ingin kamu gunakan + apiGroup: rbac.authorization.k8s.io +``` + +RoleBinding juga bisa mereferensikan ClusterRole untuk memberikan izin yang didefinisikan di dalam +ClusterRole ke sumber daya di dalam Namespace RoleBinding. Referensi semacam ini +memungkinkan kamu menentukan sekumpulan Role yang umum di seluruh klaster kamu, lalu menggunakannya kembali di dalam +beberapa Namespace. + +Sebagai contoh, meskipun RoleBinding berikut merujuk ke ClusterRole, +"dave" (subjek, peka huruf besar-kecil) hanya akan dapat membaca Secret di dalam Namespace "development", +karena Namespace RoleBinding (di dalam metadata-nya) adalah "development". + +```yaml +apiVersion: rbac.authorization.k8s.io/v1 +# role binding memungkinkan "dave" untuk membaca Secret di Namespace "development". +# Kamu sudah harus memiliki ClusterRole bernama "secret-reader". +kind: RoleBinding +metadata: + name: read-secrets + # + # Namespace dari RoleBinding menentukan dimana izin akan diberikan. + # Ini hanya memberikan izin di dalam Namespace "development". + namespace: development +subjects: +- kind: User + name: dave # Nama peka huruf besar-kecil + apiGroup: rbac.authorization.k8s.io +roleRef: + kind: ClusterRole + name: secret-reader + apiGroup: rbac.authorization.k8s.io +``` + +#### Contoh ClusterRoleBinding + +Untuk memberikan izin di seluruh klaster, kamu dapat menggunakan ClusterRoleBinding. +ClusterRoleBinding berikut memungkinkan seluruh pengguna di dalam kelompok "manager" untuk +membaca Secret di berbagai Namespace. + +```yaml +apiVersion: rbac.authorization.k8s.io/v1 +# Cluster role binding ini memungkinkan siapapun di dalam kelompok "manager" untuk membaca Secret di berbagai Namespace. +kind: ClusterRoleBinding +metadata: + name: read-secrets-global +subjects: +- kind: Group + name: manager # Nama peka huruf besar-kecil + apiGroup: rbac.authorization.k8s.io +roleRef: + kind: ClusterRole + name: secret-reader + apiGroup: rbac.authorization.k8s.io +``` +Setelah kamu membuat sebuat ikatan, kamu tidak dapat mengganti Role atau ClusterRole dirujuk. +Jika kamu mencoba mengganti sebuah ikatan `roleRef`, kamu mendapatkan kesalahan validasi. Jika kamu +tidak ingin mengganti `roleRef` untuk sebuah ikatan, kamu harus menghapus objek ikatan tersebut dan membuat +sebuah pengganti. + +Ada dua alasan untuk pembatasan tersebut: + +1. Membuat `roleRef` tidak dapat diubah memungkinkan seseorang untuk melakukan `update` pada objek ikatan yang ada, +sehingga mereka dapat mengelola daftar subyek, tanpa bisa berubah +Role yang diberikan kepada subyek tersebut. + +1. Ikatan pada Role yang berbeda adalah ikatan yang berbeda secara fundamental. +Mengharuskan sebuah ikatan untuk dihapus/diciptakan kembali untuk dalam upaya mengubah `roleRef` akan +memastikan daftar lengkap subyek dalam ikatan akan diberikan diberikan +Role baru (sebagai langkah untuk mencegah modifikasi secara tidak sengaja hanya pada roleRef +tanpa memverifikasi semua subyek yang seharusnya diberikan izin pada Role baru). + +Utilitas baris perintah `kubectl auth reconcile` membuat atau memperbaharui berkas manifes yang mengandung objek RBAC, +dan menangani penghapusan dan pembuatan objek ikatan jika dibutuhkan untuk mengganti Role yang dirujuk. +Lihat [penggunaan perintah dan contoh](#kubectl-auth-reconcile) untuk informasi tambahan. + +### Mengacu pada sumber daya + +Pada API Kubernetes, sebagian besar sumber daya diwakili dan diakses menggunakan representasi +nama objek, seperti `pods` untuk Pod. RBAC mengacu pada sumber daya yang menggunakan nama yang persis sama +dengan yang muncul di URL untuk berbagai _endpoint_ API yang relevan. +Beberapa Kubernetes APIs melibatkan +_subresource_, seperti catatan untuk Pod. Permintaan untuk catatan Pod terlihat seperti: + +```http +GET /api/v1/namespaces/{namespace}/pods/{name}/log +``` + +Dalam hal ini, `pods` adalah sumber daya Namespace untuk sumber daya Pod, dan `log` adalah sebuah +sub-sumber daya `pods`. Untuk mewakili ini dalam sebuah Role RBAC, gunakan garis miring (`/`) untuk +membatasi sumber daya dan sub-sumber daya. Untuk memungkinkan subjek membaca `pods` dan +juga mengakses sub-sumber daya `log` untuk masing-masing Pod tersebut, kamu dapat menulis: + +```yaml +apiVersion: rbac.authorization.k8s.io/v1 +kind: Role +metadata: + namespace: default + name: pod-and-pod-logs-reader +rules: +- apiGroups: [""] + resources: ["pods", "pods/log"] + verbs: ["get", "list"] +``` + +Kamu juga dapat merujuk ke sumber daya dengan nama untuk permintaan tertentu melalui daftar `resourceNames`. +Ketika nama dicantumkan, permintaan dapat dibatasi untuk setiap objek sumber daya. +Berikut adalah contoh yang membatasi subjeknya hanya untuk melakukan `get` atau` update` pada sebuah +ConfigMap bernama `my-configmap`: + +```yaml +apiVersion: rbac.authorization.k8s.io/v1 +kind: Role +metadata: + namespace: default + name: configmap-updater +rules: +- apiGroups: [""] + # + # pada level HTTP, nama sumber daya untuk mengakses objek ConfigMap + # adalah "configmaps" + resources: ["configmaps"] + resourceNames: ["my-configmap"] + verbs: ["update", "get"] +``` + +{{< note >}} +Kamu tidak dapat membatasi permintaan `create` atau` deletecollection` dengan nama sumber daya. Untuk `create`, +Keterbatasan ini dikarenakan nama objek yang tidak dikenal pada waktu otorisasi. +{{< /note >}} + +### Agregat ClusterRole + +Kamu dapat mengumpulkan beberapa ClusterRole menjadi satu ClusterRole gabungan. +_Controller_, yang berjalan sebagai bagian dari _control plane_ klaster, mengamati objek ClusterRole +dengan `aggregationRule`. `AggregationRule` mendefinisikan label +Selector yang digunakan oleh _Controller_ untuk mencocokkan objek ClusterRole lain +yang harus digabungkan ke dalam `rules`. + +Berikut adalah contoh ClusterRole agregat: + +```yaml +apiVersion: rbac.authorization.k8s.io/v1 +kind: ClusterRole +metadata: + name: monitoring +aggregationRule: + clusterRoleSelectors: + - matchLabels: + rbac.example.com/aggregate-to-monitoring: "true" +rules: [] # _Control plane_ secara otomatis mengisi rules +``` + +Jika kamu membuat ClusterRole baru yang cocok dengan _selector_ label dari ClusterRole agregat yang ada, +perubahan itu memicu penambahan aturan baru ke dalam ClusterRole agregat. +Berikut adalah contoh yang menambahkan aturan ke "monitoring" ClusterRole, dengan membuat sebuah +ClusterRole lain berlabel `rbac.example.com/aggregate-to-monitoring: true`. + +```yaml +apiVersion: rbac.authorization.k8s.io/v1 +kind: ClusterRole +metadata: + name: monitoring-endpoints + labels: + rbac.example.com/aggregate-to-monitoring: "true" +# ketika kamu membuat ClusterRole "monitoring-endpoints", +# aturan di bawah ini akan ditambahkan ke ClusterRole "monitoring". +rules: +- apiGroups: [""] + resources: ["services", "endpoints", "pods"] + verbs: ["get", "list", "watch"] +``` + +[Role bawaan pengguna](#role-dan-role-binding-bawaan) menggunakan agregasi ClusterRole. Ini memungkinkan kamu, +sebagai administrator klaster, menambahkan aturan untuk sumber daya kustom, seperti yang dilayani oleh CustomResourceDefinition +atau _aggregated_ server API, untuk memperluas Role bawaan. + +Sebagai contoh: ClusterRole berikut mengizinkan Role bawaan "admin" dan "edit" mengelola sumber daya kustom +bernama CronTab, sedangkan Role "view" hanya dapat melakukan tindakan membaca sumber daya CronTab. +Kamu dapat mengasumsikan bahwa objek CronTab dinamai `"crontab"` dalam URL yang terlihat oleh server API. + +```yaml +apiVersion: rbac.authorization.k8s.io/v1 +kind: ClusterRole +metadata: + name: aggregate-cron-tabs-edit + labels: + # Tambahkan izin berikut ke Role bawaan "admin" and "edit". + rbac.authorization.k8s.io/aggregate-to-admin: "true" + rbac.authorization.k8s.io/aggregate-to-edit: "true" +rules: +- apiGroups: ["stable.example.com"] + resources: ["crontabs"] + verbs: ["get", "list", "watch", "create", "update", "patch", "delete"] +--- +kind: ClusterRole +apiVersion: rbac.authorization.k8s.io/v1 +metadata: + name: aggregate-cron-tabs-view + labels: + # Tambahkan izin berikut ke Role bawaan "view" + rbac.authorization.k8s.io/aggregate-to-view: "true" +rules: +- apiGroups: ["stable.example.com"] + resources: ["crontabs"] + verbs: ["get", "list", "watch"] +``` + +#### Contoh Role + +Contoh berikut adalah potongan dari objek Role atau ClusterRole, yang hanya menampilkan +bagian `rules`. + +Mengizinkan pembacaan sumber daya `"pods`` pada kumpulan API inti: + +```yaml +rules: +- apiGroups: [""] + # + # pada tingkat HTTP, nama dari sumber daya untuk mengakses objek Pod + # adalah "pods" + resources: ["pods"] + verbs: ["get", "list", "watch"] +``` + +Mengizinkan pembacaan/penulisan Deployment (pada tingkat HTTP: objek dengan `"deployments"` +di bagian sumber daya dari URL) pada masing-masing kumpulan API `"extensions"` dan `"apps"`: + +```yaml +rules: +- apiGroups: ["extensions", "apps"] + # + # pada tingkat HTTP, nama dari sumber daya untuk mengakses objek Deployment + # adalah "deployments" + resources: ["deployments"] + verbs: ["get", "list", "watch", "create", "update", "patch", "delete"] +``` + +Mengizinkan pembacaan pada Pods pada kumpulan API inti, dan juga serta pembacaan atau penulisan Job +di kumpulan API `"batch"` atau `"extensions"`: + +```yaml +rules: +- apiGroups: [""] + # + # pada tingkat HTTP, nama dari sumber daya untuk mengakses objek Pod + # adalah "pods" + resources: ["pods"] + verbs: ["get", "list", "watch"] +- apiGroups: ["batch", "extensions"] + # + # pada tingkat HTTP, nama dari sumber daya untuk mengakses objek Job + # adalah "jobs" + resources: ["jobs"] + verbs: ["get", "list", "watch", "create", "update", "patch", "delete"] +``` + +Mengizinkan pembacaan ConfigMap bernama "my-config" (harus terikat dengan +RoleBinding untuk membatasi pada sebuah ConfigMap di sebuah Namespace): + +```yaml +rules: +- apiGroups: [""] + # + # pada tingkat HTTP, nama dari sumber daya untuk mengakses objek ConfigMap + # adalah "configmaps" + resources: ["configmaps"] + resourceNames: ["my-config"] + verbs: ["get"] +``` + +Mengizinkan pembacaan sumber daya `"nodes"` pada kumpulan API inti (karena sebuah node +ada pada lingkup-klaster, ini harus berupa ClusterRole yang terikat dengan ClusterRoleBinding +agar efektif): + +```yaml +rules: +- apiGroups: [""] + # + # pada tingkat HTTP, nama dari sumber daya untuk mengakses objek Node + # adalah "nodes" + resources: ["nodes"] + verbs: ["get", "list", "watch"] +``` + +Mengizinkan permintaan GET dan POST kepada _endpoint_ non-sumber daya `/healthz` dan seluruh _subpath_ +(harus berada di dalam ClusterRole yang terikat dengan ClusterRoleBinding agar efektif): + +```yaml +rules: +- nonResourceURLs: ["/healthz", "/healthz/*"] # '*' in a nonResourceURL is a suffix glob match + verbs: ["get", "post"] +``` + +### Mengacu Pada Subjek + +RoleBinding atau ClusterRoleBinding mengikat sebuah Role ke subjek. +Subjek dapat berupa kelompok, pengguna atau ServiceAccount. + +Kubernetes merepresentasikan _username_ sebagai string. +Ini bisa berupa: nama sederhana, seperti "alice"; email, seperti "bob@example.com"; +atau ID pengguna numerik yang direpresentasikan sebagai string. Terserah kamu sebagai administrator klaster +untuk mengkonfigurasi [modul otentikasi](/docs/reference/access-authn-authz/authentication/) +sehingga otentikasi menghasilkan _username_ dalam format yang kamu inginkan. + +{{< caution >}} +Awalan `system:` direservasi untuk sistem Kubernetes, jadi kamu harus memastikan +bahwa kamu tidak memiliki pengguna atau grup dengan nama yang dimulai dengan `system:` secara tidak sengaja. +Selain awalan khusus ini, sistem otorisasi RBAC tidak memerlukan format apa pun +untuk nama pengguna. +{{< /caution >}} + +Di Kubernetes, modul otentikasi menyediakan informasi grup. +Grup, seperti halnya pengguna, direpresentasikan sebagai string, dan string tersebut tidak memiliki format tertentu, +selain awalan `system:` yang sudah direservasi. + +[ServiceAccount](/id/docs/tasks/configure-pod-container/configure-service-account/) memiliki nama yang diawali dengan `system:serviceaccount:`, dan menjadi milik grup yang diawali dengan nama `system:serviceaccounts:`. + +{{< note >}} +- `system:serviceaccount:` (tunggal) adalah awalan untuk ServiceAccount _username_. +- `system:serviceaccounts:` (jamak) adalah awalan untuk ServiceAccount grup. +{{< /note >}} + +#### Contoh RoleBinding {#role-binding-examples} + +Contoh-contoh berikut ini hanya potongan RoleBinding yang hanya memperlihatkan +bagian `subjects`. + +Untuk pengguna bernama `alice@example.com`: + +```yaml +subjects: +- kind: User + name: "alice@example.com" + apiGroup: rbac.authorization.k8s.io +``` + +Untuk grup bernama `frontend-admins`: + +```yaml +subjects: +- kind: Group + name: "frontend-admins" + apiGroup: rbac.authorization.k8s.io +``` + +Untuk ServiceAccount bawaan di Namespace "kube-system": + +```yaml +subjects: +- kind: ServiceAccount + name: default + namespace: kube-system +``` + +Untuk seluruh ServiceAccount di Namespace qa: + +```yaml +subjects: +- kind: Group + name: system:serviceaccounts:qa + apiGroup: rbac.authorization.k8s.io +``` + +Untuk seluruh ServiceAccount di Namespace apapun: + +```yaml +subjects: +- kind: Group + name: system:serviceaccounts + apiGroup: rbac.authorization.k8s.io +``` + +Untuk seluruh pengguna yang terotentikasi: + +```yaml +subjects: +- kind: Group + name: system:authenticated + apiGroup: rbac.authorization.k8s.io +``` + +Untuk seluruh pengguna yang tidak terotentikasi: + +```yaml +subjects: +- kind: Group + name: system:unauthenticated + apiGroup: rbac.authorization.k8s.io +``` + +Untuk seluruh pengguna: + +```yaml +subjects: +- kind: Group + name: system:authenticated + apiGroup: rbac.authorization.k8s.io +- kind: Group + name: system:unauthenticated + apiGroup: rbac.authorization.k8s.io +``` + +## Role dan RoleBinding Bawaan + +API membuat satu set objek ClusterRole dan ClusterRoleBinding bawaan. +Sebagian besar dari objek berawalan `system:`, menunjukkan bahwa sumber daya tersebut +secara langsung dikelolah oleh _control plane_ klaster. Seluruh ClusterRole dan ClusterRoleBinding dilabeli dengan +`kubernetes.io/bootstrapping=rbac-defaults`. + +{{< caution >}} +Berhati-hatilah saat memodifikasi CLusterRole dan ClusterRoleBinding dengan nama yang +memiliki awalan `system:`. +Modifikasi sumber daya ini dapat mengakibatkan klaster yang malfungsi. +{{< /caution >}} + +### Rekonsiliasi Otomatis + +Pada setiap _start-up-_, server API memperbaharui ClusterRole bawaan dengan berbagai izin yang hilang, +dan memperbaharui ikatan ClusterRole bawaan dengan subjek yang hilang. +Ini memungkinkan klaster untuk memperbaiki modifikasi yang tidak disengaja, dan membantu menjaga Role +dan RoleBinding selalu terkini karena izin dan subjek berubah pada rilis terbaru Kubernetes. + +Untuk menon-aktifkan rekonsiliasi ini, setel anotasi `rbac.authorization.kubernetes.io/autoupdate` +pada ClusterRole bawaan atau RoleBinding bawaan menjadi `false`. +Ingat bahwa hilangnya izin dan subjek bawaan dapat mengakibatkan klaster tidak berfungsi. + +Rekonsiliasi otomatis diaktifkan secara bawaan jika otorizer RBAC aktif. + +### Role API discovery {#discovery-roles} + +RoleBinding bawaan memberi otorisasi kepada pengguna yang tidak terotentikasi untuk membaca informasi API yang dianggap aman +untuk diakses publik (termasuk CustomResourceDefinitions). Untuk menonaktifkan akses anonim, tambahkan `--anonymous-auth=false` ke konfigurasi server API. + +Untuk melihat konfigurasi Role ini melalui `kubectl` jalankan perintah: + +```shell +kubectl get clusterroles system:discovery -o yaml +``` + +{{< note >}} +Jika kamu mengubah ClusterRole tersebut, perubahan kamu akan ditimpa pada penyalaan ulang server API melalui +[rekonsiliasi-otomatis](#auto-reconciliation). Untuk menghindari penulisan ulang tersebut, hindari mengubah Role secara manual, +atau nonaktifkan rekonsiliasi otomatis +{{< /note >}} + +<table> +<caption>Kubernetes RBAC API discovery roles</caption> +<colgroup><col width="25%" /><col width="25%" /><col /></colgroup> +<tr> +<th>ClusterRole Bawaan</th> +<th>ClusterRoleBinding Bawaan</th> +<th>Deskripsi</th> +</tr> +<tr> +<td><b>system:basic-user</b></td> +<td><b>system:authenticated</b> group</td> +<td>Mengizinkan pengguna hanya dengan akses baca untuk mengakses informasi dasar tentang diri mereka sendiri. Sebelum v1.14, Role ini juga terikat pada <tt>system:unauthenticated</tt> secara bawaan.</td> +</tr> +<tr> +<td><b>system:discovery</b></td> +<td><b>system:authenticated</b> group</td> +<td>Mengizinkan akses baca pada berbagai _API discovery endpoint_ yang dibutuhkan untuk menemukan dan melakukan negosiasi pada tingkat API. Sebelum v1.14, Role ini juga terikat pada <tt>system:unauthenticated</tt> secara bawaan.</td> +</tr> +<tr> +<td><b>system:public-info-viewer</b></td> +<td><b>system:authenticated</b> and <b>system:unauthenticated</b> groups</td> +<td>Mengizinkan akses baca pada informasi yang tidak sensitif tentang klaster. Diperkenalkan pada Kubernetes v1.14.</td> +</tr> +</table> + +### Role Pengguna + +Beberapa ClusterRole bawaan tidak diawali dengan `system:`. Ini dimaksudkan untuk Role pengguna. +Ini termasuk Role super-user (`cluster-admin`), Role yang dimaksudkan untuk diberikan akses seluruh klaster dengan +menggunakan ClusterRoleBinding, dan Role yang dimaksudkan untuk diberikan pada Namespace tertentu +dengan menggunakan RoleBinding (`admin`, `edit`, `view`). + +ClusterRole menggunakan [aggregasi ClusterRole](#aggregated-clusterroles) untuk mengizinkan admin untuk memasukan peraturan untuk sumber daya khusus pada ClusterRole ini. Untuk menambahkan aturan kepada Role `admin`, `edit`, atau `view`, buat sebuah CLusterRole +dengan satu atau lebih label berikut: + +```yaml +metadata: + labels: + rbac.authorization.k8s.io/aggregate-to-admin: "true" + rbac.authorization.k8s.io/aggregate-to-edit: "true" + rbac.authorization.k8s.io/aggregate-to-view: "true" +``` + +<table> +<colgroup><col width="25%"><col width="25%"><col></colgroup> +<tr> +<th>ClusterRole Bawaan</th> +<th>ClusterRoleBinding Bawaan</th> +<th>Deskripsi</th> +</tr> +<tr> +<td><b>cluster-admin</b></td> +<td><b>system:masters</b> group</td> +<td>Mengizinkan akses super-user access untuk melakukan berbagai aksi pada berbagai sumber daya. +Ketika digunakan pada <b>ClusterRoleBinding</b>, ini memberikan kendali penuh terhadap seluruh sumber daya pada klaster dan seluruh Namespace. +Ketika digunakan pada <b>RoleBinding</b>, ini memberikan kendali penuh terhadap setiap sumber daya pada Namespace RoleBinding, termasuk Namespace itu sendiri.</td> +</tr> +<tr> +<td><b>admin</b></td> +<td>None</td> +<td>mengizinkan akses admin, yang dimaksudkan untuk diberikan dalam sebuah Namespace menggunakan <b>RoleBinding</b>. +Jika digunakan dalam <b>RoleBinding</b>, ini memungkikan akses baca/tulis ke sebagian besar sumber daya di sebuah Namespace, +termasuk kemampuan untuk membuat Role dan RoleBinding dalam Namespace. +Role ini tidak memungkinkan akses tulis pada kuota sumber daya atau ke Namespace itu sendiri.</td> +</tr> +<tr> +<td><b>edit</b></td> +<td>None</td> +<td>Mengizinkan akses baca/tulis pada seluruh objek dalam Namespace. + +Role ini tidak memungkinkan untuk melihat dan merubah Role dan RoleBinding. +Namun, Role ini memungkinkan untuk mengakses Secret dan menjalankan Pod seperti ServiceAccount dalam Namespace, +sehingga dapat digunakan untuk mendapatkan tingkat akses API dari setiap ServiceAccount di Namespace. +</td> +</tr> +<tr> +<td><b>view</b></td> +<td>None</td> +<td>Mengizinkan akses baca untuk melihat hampir seluruh objek dalam Namespace. + +Ini tidak memungkinkan untuk melihat Role dan RoleBinding. + +Role ini tidak memungkikan melihat Secret, karena pembacaan konten Secret memungkinkan +akses ke kredensial ServiceAccount dalam Namespace, yang akan memungkinkan akses API sebagai +ServiceAccount apapun di Namespace (bentuk eskalasi hak istimewa). +</td> +</tr> +</table> + +### Core component roles + +<table> +<colgroup><col width="25%"><col width="25%"><col></colgroup> +<tr> +<th>Default ClusterRole</th> +<th>Default ClusterRoleBinding</th> +<th>Description</th> +</tr> +<tr> +<td><b>system:kube-scheduler</b></td> +<td><b>system:kube-scheduler</b> user</td> +<td>Allows access to the resources required by the {{< glossary_tooltip term_id="kube-scheduler" text="scheduler" >}} component.</td> +</tr> +<tr> +<td><b>system:volume-scheduler</b></td> +<td><b>system:kube-scheduler</b> user</td> +<td>Allows access to the volume resources required by the kube-scheduler component.</td> +</tr> +<tr> +<td><b>system:kube-controller-manager</b></td> +<td><b>system:kube-controller-manager</b> user</td> +<td>Allows access to the resources required by the {{< glossary_tooltip term_id="kube-controller-manager" text="controller manager" >}} component. +The permissions required by individual controllers are detailed in the <a href="#controller-roles">controller roles</a>.</td> +</tr> +<tr> +<td><b>system:node</b></td> +<td>None</td> +<td>Allows access to resources required by the kubelet, <b>including read access to all secrets, and write access to all pod status objects</b>. + +You should use the <a href="/docs/reference/access-authn-authz/node/">Node authorizer</a> and <a href="/docs/reference/access-authn-authz/admission-controllers/#noderestriction">NodeRestriction admission plugin</a> instead of the <tt>system:node</tt> role, and allow granting API access to kubelets based on the Pods scheduled to run on them. + +The <tt>system:node</tt> role only exists for compatibility with Kubernetes clusters upgraded from versions prior to v1.8. +</td> +</tr> +<tr> +<td><b>system:node-proxier</b></td> +<td><b>system:kube-proxy</b> user</td> +<td>Allows access to the resources required by the {{< glossary_tooltip term_id="kube-proxy" text="kube-proxy" >}} component.</td> +</tr> +</table> + +### Other component roles + +<table> +<colgroup><col width="25%"><col width="25%"><col></colgroup> +<tr> +<th>Default ClusterRole</th> +<th>Default ClusterRoleBinding</th> +<th>Description</th> +</tr> +<tr> +<td><b>system:auth-delegator</b></td> +<td>None</td> +<td>Allows delegated authentication and authorization checks. +This is commonly used by add-on API servers for unified authentication and authorization.</td> +</tr> +<tr> +<td><b>system:heapster</b></td> +<td>None</td> +<td>Role for the <a href="https://github.com/kubernetes/heapster">Heapster</a> component (deprecated).</td> +</tr> +<tr> +<td><b>system:kube-aggregator</b></td> +<td>None</td> +<td>Role for the <a href="https://github.com/kubernetes/kube-aggregator">kube-aggregator</a> component.</td> +</tr> +<tr> +<td><b>system:kube-dns</b></td> +<td><b>kube-dns</b> service account in the <b>kube-system</b> namespace</td> +<td>Role for the <a href="/docs/concepts/services-networking/dns-pod-service/">kube-dns</a> component.</td> +</tr> +<tr> +<td><b>system:kubelet-api-admin</b></td> +<td>None</td> +<td>Allows full access to the kubelet API.</td> +</tr> +<tr> +<td><b>system:node-bootstrapper</b></td> +<td>None</td> +<td>Allows access to the resources required to perform +<a href="/docs/reference/command-line-tools-reference/kubelet-tls-bootstrapping/">kubelet TLS bootstrapping</a>.</td> +</tr> +<tr> +<td><b>system:node-problem-detector</b></td> +<td>None</td> +<td>Role for the <a href="https://github.com/kubernetes/node-problem-detector">node-problem-detector</a> component.</td> +</tr> +<tr> +<td><b>system:persistent-volume-provisioner</b></td> +<td>None</td> +<td>Allows access to the resources required by most <a href="/docs/concepts/storage/persistent-volumes/#provisioner">dynamic volume provisioners</a>.</td> +</tr> +</table> + +### Roles for built-in controllers {#controller-roles} + +The Kubernetes {{< glossary_tooltip term_id="kube-controller-manager" text="controller manager" >}} runs +{{< glossary_tooltip term_id="controller" text="controllers" >}} that are built in to the Kubernetes +control plane. +When invoked with `--use-service-account-credentials`, kube-controller-manager starts each controller +using a separate service account. +Corresponding roles exist for each built-in controller, prefixed with `system:controller:`. +If the controller manager is not started with `--use-service-account-credentials`, it runs all control loops +using its own credential, which must be granted all the relevant roles. +These roles include: + +* `system:controller:attachdetach-controller` +* `system:controller:certificate-controller` +* `system:controller:clusterrole-aggregation-controller` +* `system:controller:cronjob-controller` +* `system:controller:daemon-set-controller` +* `system:controller:deployment-controller` +* `system:controller:disruption-controller` +* `system:controller:endpoint-controller` +* `system:controller:expand-controller` +* `system:controller:generic-garbage-collector` +* `system:controller:horizontal-pod-autoscaler` +* `system:controller:job-controller` +* `system:controller:namespace-controller` +* `system:controller:node-controller` +* `system:controller:persistent-volume-binder` +* `system:controller:pod-garbage-collector` +* `system:controller:pv-protection-controller` +* `system:controller:pvc-protection-controller` +* `system:controller:replicaset-controller` +* `system:controller:replication-controller` +* `system:controller:resourcequota-controller` +* `system:controller:root-ca-cert-publisher` +* `system:controller:route-controller` +* `system:controller:service-account-controller` +* `system:controller:service-controller` +* `system:controller:statefulset-controller` +* `system:controller:ttl-controller` + +## Privilege escalation prevention and bootstrapping + +The RBAC API prevents users from escalating privileges by editing roles or role bindings. +Because this is enforced at the API level, it applies even when the RBAC authorizer is not in use. + +### Restrictions on role creation or update + +You can only create/update a role if at least one of the following things is true: + +1. You already have all the permissions contained in the role, at the same scope as the object being modified +(cluster-wide for a ClusterRole, within the same namespace or cluster-wide for a Role). +2. You are granted explicit permission to perform the `escalate` verb on the `roles` or `clusterroles` resource in the `rbac.authorization.k8s.io` API group. + +For example, if `user-1` does not have the ability to list Secrets cluster-wide, they cannot create a ClusterRole +containing that permission. To allow a user to create/update roles: + +1. Grant them a role that allows them to create/update Role or ClusterRole objects, as desired. +2. Grant them permission to include specific permissions in the roles they create/update: + * implicitly, by giving them those permissions (if they attempt to create or modify a Role or ClusterRole with permissions they themselves have not been granted, the API request will be forbidden) + * or explicitly allow specifying any permission in a `Role` or `ClusterRole` by giving them permission to perform the `escalate` verb on `roles` or `clusterroles` resources in the `rbac.authorization.k8s.io` API group + +### Restrictions on role binding creation or update + +You can only create/update a role binding if you already have all the permissions contained in the referenced role +(at the same scope as the role binding) *or* if you have been authorized to perform the `bind` verb on the referenced role. +For example, if `user-1` does not have the ability to list Secrets cluster-wide, they cannot create a ClusterRoleBinding +to a role that grants that permission. To allow a user to create/update role bindings: + +1. Grant them a role that allows them to create/update RoleBinding or ClusterRoleBinding objects, as desired. +2. Grant them permissions needed to bind a particular role: + * implicitly, by giving them the permissions contained in the role. + * explicitly, by giving them permission to perform the `bind` verb on the particular Role (or ClusterRole). + +For example, this ClusterRole and RoleBinding would allow `user-1` to grant other users the `admin`, `edit`, and `view` roles in the namespace `user-1-namespace`: + +```yaml +apiVersion: rbac.authorization.k8s.io/v1 +kind: ClusterRole +metadata: + name: role-grantor +rules: +- apiGroups: ["rbac.authorization.k8s.io"] + resources: ["rolebindings"] + verbs: ["create"] +- apiGroups: ["rbac.authorization.k8s.io"] + resources: ["clusterroles"] + verbs: ["bind"] + resourceNames: ["admin","edit","view"] +--- +apiVersion: rbac.authorization.k8s.io/v1 +kind: RoleBinding +metadata: + name: role-grantor-binding + namespace: user-1-namespace +roleRef: + apiGroup: rbac.authorization.k8s.io + kind: ClusterRole + name: role-grantor +subjects: +- apiGroup: rbac.authorization.k8s.io + kind: User + name: user-1 +``` + +When bootstrapping the first roles and role bindings, it is necessary for the initial user to grant permissions they do not yet have. +To bootstrap initial roles and role bindings: + +* Use a credential with the "system:masters" group, which is bound to the "cluster-admin" super-user role by the default bindings. +* If your API server runs with the insecure port enabled (`--insecure-port`), you can also make API calls via that port, which does not enforce authentication or authorization. + +## Command-line utilities + +### `kubectl create role` + +Creates a Role object defining permissions within a single namespace. Examples: + +* Create a Role named "pod-reader" that allows users to perform `get`, `watch` and `list` on pods: + + ```shell + kubectl create role pod-reader --verb=get --verb=list --verb=watch --resource=pods + ``` + +* Create a Role named "pod-reader" with resourceNames specified: + + ```shell + kubectl create role pod-reader --verb=get --resource=pods --resource-name=readablepod --resource-name=anotherpod + ``` + +* Create a Role named "foo" with apiGroups specified: + + ```shell + kubectl create role foo --verb=get,list,watch --resource=replicasets.apps + ``` + +* Create a Role named "foo" with subresource permissions: + + ```shell + kubectl create role foo --verb=get,list,watch --resource=pods,pods/status + ``` + +* Create a Role named "my-component-lease-holder" with permissions to get/update a resource with a specific name: + + ```shell + kubectl create role my-component-lease-holder --verb=get,list,watch,update --resource=lease --resource-name=my-component + ``` + +### `kubectl create clusterrole` + +Creates a ClusterRole. Examples: + +* Create a ClusterRole named "pod-reader" that allows user to perform `get`, `watch` and `list` on pods: + + ```shell + kubectl create clusterrole pod-reader --verb=get,list,watch --resource=pods + ``` + +* Create a ClusterRole named "pod-reader" with resourceNames specified: + + ```shell + kubectl create clusterrole pod-reader --verb=get --resource=pods --resource-name=readablepod --resource-name=anotherpod + ``` + +* Create a ClusterRole named "foo" with apiGroups specified: + + ```shell + kubectl create clusterrole foo --verb=get,list,watch --resource=replicasets.apps + ``` + +* Create a ClusterRole named "foo" with subresource permissions: + + ```shell + kubectl create clusterrole foo --verb=get,list,watch --resource=pods,pods/status + ``` + +* Create a ClusterRole named "foo" with nonResourceURL specified: + + ```shell + kubectl create clusterrole "foo" --verb=get --non-resource-url=/logs/* + ``` + +* Create a ClusterRole named "monitoring" with an aggregationRule specified: + + ```shell + kubectl create clusterrole monitoring --aggregation-rule="rbac.example.com/aggregate-to-monitoring=true" + ``` + +### `kubectl create rolebinding` + +Grants a Role or ClusterRole within a specific namespace. Examples: + +* Within the namespace "acme", grant the permissions in the "admin" ClusterRole to a user named "bob": + + ```shell + kubectl create rolebinding bob-admin-binding --clusterrole=admin --user=bob --namespace=acme + ``` + +* Within the namespace "acme", grant the permissions in the "view" ClusterRole to the service account in the namespace "acme" named "myapp": + + ```shell + kubectl create rolebinding myapp-view-binding --clusterrole=view --serviceaccount=acme:myapp --namespace=acme + ``` + +* Within the namespace "acme", grant the permissions in the "view" ClusterRole to a service account in the namespace "myappnamespace" named "myapp": + + ```shell + kubectl create rolebinding myappnamespace-myapp-view-binding --clusterrole=view --serviceaccount=myappnamespace:myapp --namespace=acme + ``` + +### `kubectl create clusterrolebinding` + +Grants a ClusterRole across the entire cluster (all namespaces). Examples: + +* Across the entire cluster, grant the permissions in the "cluster-admin" ClusterRole to a user named "root": + + ```shell + kubectl create clusterrolebinding root-cluster-admin-binding --clusterrole=cluster-admin --user=root + ``` + +* Across the entire cluster, grant the permissions in the "system:node-proxier" ClusterRole to a user named "system:kube-proxy": + + ```shell + kubectl create clusterrolebinding kube-proxy-binding --clusterrole=system:node-proxier --user=system:kube-proxy + ``` + +* Across the entire cluster, grant the permissions in the "view" ClusterRole to a service account named "myapp" in the namespace "acme": + + ```shell + kubectl create clusterrolebinding myapp-view-binding --clusterrole=view --serviceaccount=acme:myapp + ``` + +### `kubectl auth reconcile` {#kubectl-auth-reconcile} + +Creates or updates `rbac.authorization.k8s.io/v1` API objects from a manifest file. + +Missing objects are created, and the containing namespace is created for namespaced objects, if required. + +Existing roles are updated to include the permissions in the input objects, +and remove extra permissions if `--remove-extra-permissions` is specified. + +Existing bindings are updated to include the subjects in the input objects, +and remove extra subjects if `--remove-extra-subjects` is specified. + +Examples: + +* Test applying a manifest file of RBAC objects, displaying changes that would be made: + + ``` + kubectl auth reconcile -f my-rbac-rules.yaml --dry-run=client + ``` + +* Apply a manifest file of RBAC objects, preserving any extra permissions (in roles) and any extra subjects (in bindings): + + ```shell + kubectl auth reconcile -f my-rbac-rules.yaml + ``` + +* Apply a manifest file of RBAC objects, removing any extra permissions (in roles) and any extra subjects (in bindings): + + ```shell + kubectl auth reconcile -f my-rbac-rules.yaml --remove-extra-subjects --remove-extra-permissions + ``` + +## ServiceAccount permissions {#service-account-permissions} + +Default RBAC policies grant scoped permissions to control-plane components, nodes, +and controllers, but grant *no permissions* to service accounts outside the `kube-system` namespace +(beyond discovery permissions given to all authenticated users). + +This allows you to grant particular roles to particular ServiceAccounts as needed. +Fine-grained role bindings provide greater security, but require more effort to administrate. +Broader grants can give unnecessary (and potentially escalating) API access to +ServiceAccounts, but are easier to administrate. + +In order from most secure to least secure, the approaches are: + +1. Grant a role to an application-specific service account (best practice) + + This requires the application to specify a `serviceAccountName` in its pod spec, + and for the service account to be created (via the API, application manifest, `kubectl create serviceaccount`, etc.). + + For example, grant read-only permission within "my-namespace" to the "my-sa" service account: + + ```shell + kubectl create rolebinding my-sa-view \ + --clusterrole=view \ + --serviceaccount=my-namespace:my-sa \ + --namespace=my-namespace + ``` + +2. Grant a role to the "default" service account in a namespace + + If an application does not specify a `serviceAccountName`, it uses the "default" service account. + + {{< note >}} + Permissions given to the "default" service account are available to any pod + in the namespace that does not specify a `serviceAccountName`. + {{< /note >}} + + For example, grant read-only permission within "my-namespace" to the "default" service account: + + ```shell + kubectl create rolebinding default-view \ + --clusterrole=view \ + --serviceaccount=my-namespace:default \ + --namespace=my-namespace + ``` + + Many [add-ons](/id/docs/concepts/cluster-administration/addons/) run as the + "default" service account in the `kube-system` namespace. + To allow those add-ons to run with super-user access, grant cluster-admin + permissions to the "default" service account in the `kube-system` namespace. + + {{< caution >}} + Enabling this means the `kube-system` namespace contains Secrets + that grant super-user access to your cluster's API. + {{< /caution >}} + + ```shell + kubectl create clusterrolebinding add-on-cluster-admin \ + --clusterrole=cluster-admin \ + --serviceaccount=kube-system:default + ``` + +3. Grant a role to all service accounts in a namespace + + If you want all applications in a namespace to have a role, no matter what service account they use, + you can grant a role to the service account group for that namespace. + + For example, grant read-only permission within "my-namespace" to all service accounts in that namespace: + + ```shell + kubectl create rolebinding serviceaccounts-view \ + --clusterrole=view \ + --group=system:serviceaccounts:my-namespace \ + --namespace=my-namespace + ``` + +4. Grant a limited role to all service accounts cluster-wide (discouraged) + + If you don't want to manage permissions per-namespace, you can grant a cluster-wide role to all service accounts. + + For example, grant read-only permission across all namespaces to all service accounts in the cluster: + + ```shell + kubectl create clusterrolebinding serviceaccounts-view \ + --clusterrole=view \ + --group=system:serviceaccounts + ``` + +5. Grant super-user access to all service accounts cluster-wide (strongly discouraged) + + If you don't care about partitioning permissions at all, you can grant super-user access to all service accounts. + + {{< warning >}} + This allows any application full access to your cluster, and also grants + any user with read access to Secrets (or the ability to create any pod) + full access to your cluster. + {{< /warning >}} + + ```shell + kubectl create clusterrolebinding serviceaccounts-cluster-admin \ + --clusterrole=cluster-admin \ + --group=system:serviceaccounts + ``` + +## Upgrading from ABAC + +Clusters that originally ran older Kubernetes versions often used +permissive ABAC policies, including granting full API access to all +service accounts. + +Default RBAC policies grant scoped permissions to control-plane components, nodes, +and controllers, but grant *no permissions* to service accounts outside the `kube-system` namespace +(beyond discovery permissions given to all authenticated users). + +While far more secure, this can be disruptive to existing workloads expecting to automatically receive API permissions. +Here are two approaches for managing this transition: + +### Parallel authorizers + +Run both the RBAC and ABAC authorizers, and specify a policy file that contains +the [legacy ABAC policy](/docs/reference/access-authn-authz/abac/#policy-file-format): + +``` +--authorization-mode=...,RBAC,ABAC --authorization-policy-file=mypolicy.json +``` + +To explain that first command line option in detail: if earlier authorizers, such as Node, +deny a request, then the the RBAC authorizer attempts to authorize the API request. If RBAC +also denies that API request, the ABAC authorizer is then run. This means that any request +allowed by *either* the RBAC or ABAC policies is allowed. + +When the kube-apiserver is run with a log level of 5 or higher for the RBAC component +(`--vmodule=rbac*=5` or `--v=5`), you can see RBAC denials in the API server log +(prefixed with `RBAC`). +You can use that information to determine which roles need to be granted to which users, groups, or service accounts. + +Once you have [granted roles to service accounts](#service-account-permissions) and workloads +are running with no RBAC denial messages in the server logs, you can remove the ABAC authorizer. + +### Permissive RBAC permissions + +You can replicate a permissive ABAC policy using RBAC role bindings. + +{{< warning >}} +The following policy allows **ALL** service accounts to act as cluster administrators. +Any application running in a container receives service account credentials automatically, +and could perform any action against the API, including viewing secrets and modifying permissions. +This is not a recommended policy. + +```shell +kubectl create clusterrolebinding permissive-binding \ + --clusterrole=cluster-admin \ + --user=admin \ + --user=kubelet \ + --group=system:serviceaccounts +``` +{{< /warning >}} + +After you have transitioned to use RBAC, you should adjust the access controls +for your cluster to ensure that these meet your information security needs. + + diff --git a/content/id/docs/reference/kubectl/cheatsheet.md b/content/id/docs/reference/kubectl/cheatsheet.md index 9afe999064..671ac6b77a 100644 --- a/content/id/docs/reference/kubectl/cheatsheet.md +++ b/content/id/docs/reference/kubectl/cheatsheet.md @@ -319,8 +319,8 @@ kubectl taint nodes foo dedicated=special-user:NoSchedule ### Berbagai Tipe Sumber Daya -Mendapatkan seluruh daftar tipe sumber daya yang didukung lengkap dengan singkatan pendeknya, [grup API](/docs/concepts/overview/kubernetes-api/#api-groups), -apakah sumber daya merupakan sumber daya yang berada di dalam Namespace atau tidak, serta [Kind](/docs/concepts/overview/working-with-objects/kubernetes-objects): +Mendapatkan seluruh daftar tipe sumber daya yang didukung lengkap dengan singkatan pendeknya, [grup API](/id/docs/concepts/overview/kubernetes-api/#api-groups), +apakah sumber daya merupakan sumber daya yang berada di dalam Namespace atau tidak, serta [Kind](/id/docs/concepts/overview/working-with-objects/kubernetes-objects): ```bash kubectl api-resources diff --git a/content/id/docs/setup/best-practices/multiple-zones.md b/content/id/docs/setup/best-practices/multiple-zones.md index 2727db559d..e2e314eb63 100644 --- a/content/id/docs/setup/best-practices/multiple-zones.md +++ b/content/id/docs/setup/best-practices/multiple-zones.md @@ -1,16 +1,16 @@ --- title: Menjalankan klaster dalam beberapa zona weight: 10 -content_template: templates/concept +content_type: concept --- -{{% capture overview %}} +<!-- overview --> Laman ini menjelaskan tentang bagaimana menjalankan sebuah klaster dalam beberapa zona. -{{% /capture %}} -{{% capture body %}} + +<!-- body --> ## Pendahuluan @@ -398,4 +398,4 @@ KUBERNETES_PROVIDER=aws KUBE_USE_EXISTING_MASTER=true KUBE_AWS_ZONE=us-west-2b k KUBERNETES_PROVIDER=aws KUBE_AWS_ZONE=us-west-2a kubernetes/cluster/kube-down.sh ``` -{{% /capture %}} + diff --git a/content/id/docs/setup/production-environment/container-runtimes.md b/content/id/docs/setup/production-environment/container-runtimes.md new file mode 100644 index 0000000000..bca967593c --- /dev/null +++ b/content/id/docs/setup/production-environment/container-runtimes.md @@ -0,0 +1,414 @@ +--- +title: Runtime Container +content_type: concept +weight: 10 +--- +<!-- overview --> +{{< feature-state for_k8s_version="v1.6" state="stable" >}} + +Untuk menjalankan Container di Pod, Kubernetes menggunakan _runtime_ Container (Container runtimes). Berikut ini adalah +petunjuk instalasi untuk berbagai macam _runtime_. + + +<!-- body --> + + +{{< caution >}} +Sebuah kekurangan ditemukan dalam cara `runc` menangani pendeskripsi berkas (_file_) sistem ketika menjalankan Container. +Container yang berbahaya dapat menggunakan kekurangan ini untuk menimpa konten biner `runc` dan +akibatnya Container tersebut dapat menjalankan perintah yang sewenang-wenang pada sistem host dari Container tersebut. + +Silahkan merujuk pada [CVE-2019-5736](https://access.redhat.com/security/cve/cve-2019-5736) untuk informasi lebih lanjut tentang masalah ini. +{{< /caution >}} + +### Penerapan + +{{< note >}} +Dokumen ini ditulis untuk pengguna yang memasang CRI (Container Runtime Interface) pada sistem operasi Linux. Untuk sistem operasi yang lain, +silahkan cari dokumentasi khusus untuk platform kamu. + +{{< /note >}} + +Kamu harus menjalankan semua perintah dalam panduan ini sebagai `root`. Sebagai contoh, awali perintah +dengan `sudo`, atau masuk sebagai `root` dan kemudian baru menjalankan perintah sebagai pengguna `root`. + +### _Driver_ cgroup + +Ketika systemd dipilih sebagai sistem init untuk sebuah distribusi Linux, proses init menghasilkan +dan menggunakan grup kontrol root (`cgroup`) dan proses ini akan bertindak sebagai manajer cgroup. Systemd memiliki integrasi yang ketat +dengan cgroup dan akan mengalokasikan cgroups untuk setiap proses. Kamu dapat mengonfigurasi +_runtime_ Container dan kubelet untuk menggunakan `cgroupfs`. Menggunakan `cgroupfs` bersama dengan systemd berarti +akan ada dua manajer cgroup yang berbeda. + +Cgroup digunakan untuk membatasi sumber daya yang dialokasikan untuk proses. +Sebuah manajer cgroup tunggal akan menyederhanakan pandangan tentang sumber daya apa yang sedang dialokasikan +dan secara bawaan (_default_) akan memiliki pandangan yang lebih konsisten tentang sumber daya yang tersedia dan yang sedang digunakan. Ketika kita punya memiliki +dua manajer maka kita pun akan memiliki dua pandangan berbeda tentang sumber daya tersebut. Kita telah melihat kasus di lapangan +di mana Node yang dikonfigurasi menggunakan `cgroupfs` untuk kubelet dan Docker, dan `systemd` +untuk semua sisa proses yang berjalan pada Node maka Node tersebut akan menjadi tidak stabil di bawah tekanan sumber daya. + +Mengubah aturan sedemikian rupa sehingga _runtime_ Container dan kubelet kamu menggunakan `systemd` sebagai _driver_ cgroup +akan menstabilkan sistem. Silahkan perhatikan opsi `native.cgroupdriver=systemd` dalam pengaturan Docker di bawah ini. + +{{< caution >}} +Mengubah driver cgroup dari Node yang telah bergabung kedalam sebuah Cluster sangat tidak direkomendasikan. +Jika kubelet telah membuat Pod menggunakan semantik dari sebuah _driver_ cgroup, mengubah _runtime_ Container +ke _driver_ cgroup yang lain dapat mengakibatkan kesalahan pada saat percobaan untuk membuat kembali PodSandbox +untuk Pod yang sudah ada. Menjalankan ulang (_restart_) kubelet mungkin tidak menyelesaikan kesalahan tersebut. Rekomendasi yang dianjurkan +adalah untuk menguras Node dari beban kerjanya, menghapusnya dari Cluster dan menggabungkannya kembali. + +{{< /caution >}} + +## Docker + +Pada setiap mesin kamu, mari menginstall Docker. +Versi yang direkomendasikan adalah 19.03.11, tetapi versi 1.13.1, 17.03, 17.06, 17.09, 18.06 dan 18.09 juga diketahui bekerja dengan baik. +Jagalah versi Docker pada versi terbaru yang sudah terverifikasi pada catatan rilis Kubernetes. + +Gunakan perintah berikut untuk menginstal Docker pada sistem kamu: + +{{< tabs name="tab-cri-docker-installation" >}} +{{% tab name="Ubuntu 16.04+" %}} + +```shell +# (Menginstal Docker CE) +## Mengatur repositori: +### Menginstal packet untuk mengijinkan apt untuk menggunakan repositori melalui HTTPS +apt-get update && apt-get install -y \ + apt-transport-https ca-certificates curl software-properties-common gnupg2 +``` + +```shell +# Menambahkan key GPG resmi dari Docker: +curl -fsSL https://download.docker.com/linux/ubuntu/gpg | apt-key add - +``` + +```shell +# Menambahkan repositori apt dari Docker: +add-apt-repository \ + "deb [arch=amd64] https://download.docker.com/linux/ubuntu \ + $(lsb_release -cs) \ + stable" +``` + +```shell +# Menginstal Docker CE +apt-get update && apt-get install -y \ + containerd.io=1.2.13-2 \ + docker-ce=5:19.03.11~3-0~ubuntu-$(lsb_release -cs) \ + docker-ce-cli=5:19.03.11~3-0~ubuntu-$(lsb_release -cs) +``` + +```shell +# Mengatur daemon Docker +cat > /etc/docker/daemon.json <<EOF +{ + "exec-opts": ["native.cgroupdriver=systemd"], + "log-driver": "json-file", + "log-opts": { + "max-size": "100m" + }, + "storage-driver": "overlay2" +} +EOF +``` + +```shell +mkdir -p /etc/systemd/system/docker.service.d +``` + +```shell +# Menjalankan ulang Docker +systemctl daemon-reload +systemctl restart docker +``` +{{% /tab %}} +{{% tab name="CentOS/RHEL 7.4+" %}} + +```shell +# (Menginstal Docker CE) +## Mengatur repositori +### Menginstal paket yang diperlukan +yum install -y yum-utils device-mapper-persistent-data lvm2 +``` + +```shell +## Menambahkan repositori apt dari Docker +yum-config-manager --add-repo \ + https://download.docker.com/linux/centos/docker-ce.repo +``` + +```shell +# Menginstal Docker CE +yum update -y && yum install -y \ + containerd.io-1.2.13 \ + docker-ce-19.03.11 \ + docker-ce-cli-19.03.11 +``` + +```shell +## Membuat berkas /etc/docker +mkdir /etc/docker +``` + +```shell +# Mengatur daemon Docker +cat > /etc/docker/daemon.json <<EOF +{ + "exec-opts": ["native.cgroupdriver=systemd"], + "log-driver": "json-file", + "log-opts": { + "max-size": "100m" + }, + "storage-driver": "overlay2", + "storage-opts": [ + "overlay2.override_kernel_check=true" + ] +} +EOF +``` + +```shell +mkdir -p /etc/systemd/system/docker.service.d +``` + +```shell +# Menjalankan ulang Docker +systemctl daemon-reload +systemctl restart docker +``` +{{% /tab %}} +{{< /tabs >}} + +Jika kamu menginginkan layanan Docker berjalan dari saat memulai pertama (_boot_), jalankan perintah ini: + +```shell +sudo systemctl enable docker +``` + +Silahkan merujuk pada [Panduan resmi instalasi Docker](https://docs.docker.com/engine/installation/) +untuk informasi lebih lanjut. + +## CRI-O + +Bagian ini mencakup langkah-langkah yang diperlukan untuk menginstal `CRI-O` sebagai _runtime_ CRI. + +Gunakan perintah-perinath berikut untuk menginstal CRI-O pada sistem kamu: + +{{< note >}} +Versi mayor dan minor dari CRI-O harus sesuai dengan versi mayor dan minor dari Kubernetes. +Untuk informasi lebih lanjut, lihatlah [Matriks kompatibilitas CRI-O](https://github.com/cri-o/cri-o). +{{< /note >}} + +### Prasyarat + +```shell +modprobe overlay +modprobe br_netfilter + +# Mengatur parameter sysctl yang diperlukan, dimana ini akan bernilai tetap setiap kali penjalanan ulang. +cat > /etc/sysctl.d/99-kubernetes-cri.conf <<EOF +net.bridge.bridge-nf-call-iptables = 1 +net.ipv4.ip_forward = 1 +net.bridge.bridge-nf-call-ip6tables = 1 +EOF + +sysctl --system +``` + +{{< tabs name="tab-cri-cri-o-installation" >}} +{{% tab name="Debian" %}} + +```shell +# Debian Unstable/Sid +echo 'deb http://download.opensuse.org/repositories/devel:/kubic:/libcontainers:/stable/Debian_Unstable/ /' > /etc/apt/sources.list.d/devel:kubic:libcontainers:stable.list +wget -nv https://download.opensuse.org/repositories/devel:kubic:libcontainers:stable/Debian_Unstable/Release.key -O- | sudo apt-key add - +``` + +```shell +# Debian Testing +echo 'deb http://download.opensuse.org/repositories/devel:/kubic:/libcontainers:/stable/Debian_Testing/ /' > /etc/apt/sources.list.d/devel:kubic:libcontainers:stable.list +wget -nv https://download.opensuse.org/repositories/devel:kubic:libcontainers:stable/Debian_Testing/Release.key -O- | sudo apt-key add - +``` + +```shell +# Debian 10 +echo 'deb http://download.opensuse.org/repositories/devel:/kubic:/libcontainers:/stable/Debian_10/ /' > /etc/apt/sources.list.d/devel:kubic:libcontainers:stable.list +wget -nv https://download.opensuse.org/repositories/devel:kubic:libcontainers:stable/Debian_10/Release.key -O- | sudo apt-key add - +``` + +```shell +# Raspbian 10 +echo 'deb http://download.opensuse.org/repositories/devel:/kubic:/libcontainers:/stable/Raspbian_10/ /' > /etc/apt/sources.list.d/devel:kubic:libcontainers:stable.list +wget -nv https://download.opensuse.org/repositories/devel:kubic:libcontainers:stable/Raspbian_10/Release.key -O- | sudo apt-key add - +``` + +dan kemudian install CRI-O: +```shell +sudo apt-get install cri-o-1.17 +``` + +{{% /tab %}} + +{{% tab name="Ubuntu 18.04, 19.04 and 19.10" %}} + +```shell +# Mengatur repositori paket +. /etc/os-release +sudo sh -c "echo 'deb http://download.opensuse.org/repositories/devel:/kubic:/libcontainers:/stable/x${NAME}_${VERSION_ID}/ /' > /etc/apt/sources.list.d/devel:kubic:libcontainers:stable.list" +wget -nv https://download.opensuse.org/repositories/devel:kubic:libcontainers:stable/x${NAME}_${VERSION_ID}/Release.key -O- | sudo apt-key add - +sudo apt-get update +``` + +```shell +# Menginstal CRI-O +sudo apt-get install cri-o-1.17 +``` +{{% /tab %}} + +{{% tab name="CentOS/RHEL 7.4+" %}} + +```shell +# Menginstal prasyarat +curl -L -o /etc/yum.repos.d/devel:kubic:libcontainers:stable.repo https://download.opensuse.org/repositories/devel:kubic:libcontainers:stable/CentOS_7/devel:kubic:libcontainers:stable.repo +curl -L -o /etc/yum.repos.d/devel:kubic:libcontainers:stable:cri-o:{{< skew latestVersion >}}.repo https://download.opensuse.org/repositories/devel:kubic:libcontainers:stable:cri-o:{{< skew latestVersion >}}/CentOS_7/devel:kubic:libcontainers:stable:cri-o:{{< skew latestVersion >}}.repo +``` + +```shell +# Menginstal CRI-O +yum install -y cri-o +``` +{{% /tab %}} + +{{% tab name="openSUSE Tumbleweed" %}} + +```shell +sudo zypper install cri-o +``` +{{% /tab %}} +{{< /tabs >}} + +### Memulai CRI-O + +```shell +systemctl daemon-reload +systemctl start crio +``` + +Silahkan merujuk pada [Panduan instalasi CRI-O](https://github.com/kubernetes-sigs/cri-o#getting-started) +untuk informasi lanjut. + +## Containerd + +Bagian ini berisi langkah-langkah yang diperlukan untuk menggunakan `containerd` sebagai _runtime_ CRI. + +Gunakan perintah-perintah berikut untuk menginstal containerd pada sistem kamu: + + +### Prasyarat + +```shell +cat > /etc/modules-load.d/containerd.conf <<EOF +overlay +br_netfilter +EOF + +modprobe overlay +modprobe br_netfilter + +# Mengatur parameter sysctl yang diperlukan, dimana ini akan bernilai tetap setiap kali penjalanan ulang. +cat > /etc/sysctl.d/99-kubernetes-cri.conf <<EOF +net.bridge.bridge-nf-call-iptables = 1 +net.ipv4.ip_forward = 1 +net.bridge.bridge-nf-call-ip6tables = 1 +EOF + +sysctl --system +``` + +### Menginstal containerd + +{{< tabs name="tab-cri-containerd-installation" >}} +{{% tab name="Ubuntu 16.04" %}} + +```shell +# (Meninstal containerd) +## Mengatur repositori paket +### Install packages to allow apt to use a repository over HTTPS +apt-get update && apt-get install -y apt-transport-https ca-certificates curl software-properties-common +``` + +```shell +## Menambahkan key GPG resmi dari Docker: +curl -fsSL https://download.docker.com/linux/ubuntu/gpg | apt-key add - +``` + +```shell +## Mengatur repositori paket Docker +add-apt-repository \ + "deb [arch=amd64] https://download.docker.com/linux/ubuntu \ + $(lsb_release -cs) \ + stable" +``` + +```shell +## Menginstal containerd +apt-get update && apt-get install -y containerd.io +``` + +```shell +# Mengonfigure containerd +mkdir -p /etc/containerd +containerd config default > /etc/containerd/config.toml +``` + +```shell +# Menjalankan ulang containerd +systemctl restart containerd +``` +{{% /tab %}} +{{% tab name="CentOS/RHEL 7.4+" %}} + +```shell +# (Menginstal containerd) +## Mengatur repositori +### Menginstal paket prasyarat +yum install -y yum-utils device-mapper-persistent-data lvm2 +``` + +```shell +## Menambahkan repositori Docker +yum-config-manager \ + --add-repo \ + https://download.docker.com/linux/centos/docker-ce.repo +``` + +```shell +## Menginstal containerd +yum update -y && yum install -y containerd.io +``` + +```shell +## Mengonfigurasi containerd +mkdir -p /etc/containerd +containerd config default > /etc/containerd/config.toml +``` + +```shell +# Menjalankan ulang containerd +systemctl restart containerd +``` +{{% /tab %}} +{{< /tabs >}} + +### systemd + +Untuk menggunakan driver cgroup `systemd`, atur `plugins.cri.systemd_cgroup = true` pada `/etc/containerd/config.toml`. +Ketika menggunakan kubeadm, konfigurasikan secara manual +[driver cgroup untuk kubelet](/id/docs/setup/production-environment/tools/kubeadm/install-kubeadm/#mengonfigurasi-cgroup-untuk-kubelet-pada-node-control-plane) + +## _Runtime_ CRI yang lainnya: Frakti + +Silahkan lihat [Panduan cepat memulai Frakti](https://github.com/kubernetes/frakti#quickstart) untuk informasi lebih lanjut. + + diff --git a/content/id/docs/setup/production-environment/tools/_index.md b/content/id/docs/setup/production-environment/tools/_index.md new file mode 100644 index 0000000000..fc98544230 --- /dev/null +++ b/content/id/docs/setup/production-environment/tools/_index.md @@ -0,0 +1,4 @@ +--- +title: Menginstal Kubernetes dengan perkakas penyebaran +weight: 30 +--- diff --git a/content/id/docs/setup/production-environment/tools/kubeadm/_index.md b/content/id/docs/setup/production-environment/tools/kubeadm/_index.md new file mode 100644 index 0000000000..f88a749c9b --- /dev/null +++ b/content/id/docs/setup/production-environment/tools/kubeadm/_index.md @@ -0,0 +1,4 @@ +--- +title: "Menyiapkan klaster dengan kubeadm" +weight: 10 +--- diff --git a/content/id/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm.md b/content/id/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm.md index 4b7b15e91c..8a345296a3 100644 --- a/content/id/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm.md +++ b/content/id/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm.md @@ -1,10 +1,10 @@ --- title: Membuat sebuah klaster dengan control-plane tunggal menggunakan kubeadm -content_template: templates/task +content_type: task weight: 30 --- -{{% capture overview %}} +<!-- overview --> Perkakas <img src="https://raw.githubusercontent.com/kubernetes/kubeadm/master/logos/stacked/color/kubeadm-stacked-color.png" align="right" width="150px">`kubeadm` membantu kamu membuat sebuah klaster Kubernetes minimum yang layak dan sesuai dengan _best practice_. Bahkan, kamu dapat menggunakan `kubeadm` untuk membuat sebuah klaster yang lolos [uji Kubernetes Conformance](https://kubernetes.io/blog/2017/10/software-conformance-certification). `kubeadm` juga mendukung fungsi siklus hidup (_lifecycle_) @@ -22,9 +22,10 @@ server di _cloud_, sebuah Raspberry Pi, dan lain-lain. Baik itu men-_deploy_ pad _cloud_ ataupun _on-premise_, kamu dapat mengintegrasikan `kubeadm` pada sistem _provisioning_ seperti Ansible atau Terraform. -{{% /capture %}} -{{% capture prerequisites %}} + +## {{% heading "prerequisites" %}} + Untuk mengikuti panduan ini, kamu membutuhkan: @@ -51,9 +52,9 @@ sedikit seiring dengan berevolusinya kubeadm, namun secara umum implementasinya Semua perintah di dalam `kubeadm alpha`, sesuai definisi, didukung pada level _alpha_. {{< /note >}} -{{% /capture %}} -{{% capture steps %}} + +<!-- steps --> ## Tujuan @@ -65,7 +66,7 @@ Semua perintah di dalam `kubeadm alpha`, sesuai definisi, didukung pada level _a ### Menginstal kubeadm pada hos -Lihat ["Menginstal kubeadm"](/docs/setup/production-environment/tools/kubeadm/install-kubeadm/). +Lihat ["Menginstal kubeadm"](/id/docs/setup/production-environment/tools/kubeadm/install-kubeadm/). {{< note >}} Jika kamu sudah menginstal kubeadm sebelumnya, jalankan `apt-get update && @@ -93,7 +94,7 @@ yang spesifik pada penyedia tertentu. Lihat [Menginstal _add-on_ jaringan Pod](# 3. (Opsional) Sejak versi 1.14, `kubeadm` mencoba untuk mendeteksi _runtime_ kontainer pada Linux dengan menggunakan daftar _domain socket path_ yang umum diketahui. Untuk menggunakan _runtime_ kontainer yang berbeda atau jika ada lebih dari satu yang terpasang pada Node yang digunakan, tentukan argumen `--cri-socket` -pada `kubeadm init`. Lihat [Menginstal _runtime_](/docs/setup/production-environment/tools/kubeadm/install-kubeadm/#installing-runtime). +pada `kubeadm init`. Lihat [Menginstal _runtime_](/id/docs/setup/production-environment/tools/kubeadm/install-kubeadm/#installing-runtime). 4. (Opsional) Kecuali ditentukan sebelumnya, `kubeadm` akan menggunakan antarmuka jaringan yang diasosiasikan dengan _default gateway_ untuk mengatur alamat _advertise_ untuk API Server pada Node _control-plane_ ini. Untuk menggunakan antarmuka jaringan yang berbeda, tentukan argumen `--apiserver-advertise-address=<ip-address>` @@ -261,7 +262,7 @@ DNS klaster (CoreDNS) tidak akan menyala sebelum jaringan dipasangkan.** `--pod-network-cidr`, atau sebagai penggantinya pada YAML _plugin_ jaringan kamu). - Secara bawaan, `kubeadm` mengatur klastermu untuk menggunakan dan melaksanakan penggunaan - [RBAC](/docs/reference/access-authn-authz/rbac/) (_role based access control_). + [RBAC](/id/docs/reference/access-authn-authz/rbac/) (_role based access control_). Pastikan _plugin_ jaringan Pod mendukung RBAC, dan begitu juga seluruh manifes yang kamu gunakan untuk men-_deploy_-nya. @@ -559,9 +560,9 @@ Lihat dokumentasi referensi [`kubeadm reset`](/docs/reference/setup-tools/kubead untuk informasi lebih lanjut mengenai sub-perintah ini dan opsinya. -{{% /capture %}} -{{% capture discussion %}} + +<!-- discussion --> ## Selanjutnya @@ -570,14 +571,14 @@ opsinya. untuk detail mengenai pembaruan klaster menggunakan `kubeadm`. * Pelajari penggunaan `kubeadm` lebih lanjut pada [dokumentasi referensi kubeadm](/docs/reference/setup-tools/kubeadm/kubeadm) * Pelajari lebih lanjut mengenai [konsep-konsep](/docs/concepts/) Kubernetes dan [`kubectl`](/docs/user-guide/kubectl-overview/). -* Lihat halaman [Cluster Networking](/docs/concepts/cluster-administration/networking/) untuk daftar +* Lihat halaman [Cluster Networking](/id/docs/concepts/cluster-administration/networking/) untuk daftar _add-on_ jaringan Pod yang lebih banyak. -* <a id="other-addons" />Lihat [daftar _add-on_](/docs/concepts/cluster-administration/addons/) untuk +* <a id="other-addons" />Lihat [daftar _add-on_](/id/docs/concepts/cluster-administration/addons/) untuk mengeksplor _add-on_ lainnya, termasuk perkakas untuk _logging_, _monitoring_, _network policy_, visualisasi & pengendalian klaster Kubernetes. * Atur bagaimana klaster mengelola log untuk peristiwa-peristiwa klaster dan dari aplikasi-aplikasi yang berjalan pada Pod. - Lihat [Arsitektur Logging](/docs/concepts/cluster-administration/logging/) untuk + Lihat [Arsitektur Logging](/id/docs/concepts/cluster-administration/logging/) untuk gambaran umum tentang hal-hal yang terlibat. ### Umpan balik @@ -601,7 +602,7 @@ Karena kita tidak dapat memprediksi masa depan, CLI kubeadm v{{< skew latestVers Sumber daya ini menyediakan informasi lebih lanjut mengenai _version skew_ yang didukung antara kubelet dan _control plane_, serta komponen Kubernetes lainnya: * [Kebijakan versi and version-skew Kubernetes](/docs/setup/release/version-skew-policy/) -* [Panduan instalasi](/docs/setup/production-environment/tools/kubeadm/install-kubeadm/#installing-kubeadm-kubelet-and-kubectl) spesifik untuk kubeadm +* [Panduan instalasi](/id/docs/setup/production-environment/tools/kubeadm/install-kubeadm/#installing-kubeadm-kubelet-and-kubectl) spesifik untuk kubeadm ## Keterbatasan @@ -635,4 +636,4 @@ mendukung platform pilihanmu. Jika kamu menemui kesulitan dengan kubeadm, silakan merujuk pada [dokumen penyelesaian masalah](/docs/setup/production-environment/tools/kubeadm/troubleshooting-kubeadm/). -{{% /capture %}} + diff --git a/content/id/docs/setup/production-environment/tools/kubeadm/high-availability.md b/content/id/docs/setup/production-environment/tools/kubeadm/high-availability.md new file mode 100644 index 0000000000..afe6d1e6b8 --- /dev/null +++ b/content/id/docs/setup/production-environment/tools/kubeadm/high-availability.md @@ -0,0 +1,364 @@ +--- +title: Membangun Klaster dengan Ketersediaan Tinggi menggunakan kubeadm +content_type: task +weight: 60 +--- + +<!-- overview --> + +Laman ini menjelaskan dua pendekatan yang berbeda untuk membuat klaster Kubernetes dengan ketersediaan tinggi menggunakan kubeadm: + +- Dengan Node _control plane_ yang bertumpuk (_stacked_). Pendekatan ini membutuhkan sumber daya infrastruktur yang lebih sedikit. Anggota-anggota etcd dan Node _control plane_ diletakkan pada tempat yang sama (_co-located_). +- Dengan klaster etcd eksternal. Pendekatan ini membutuhkan lebih banyak sumber daya infrastruktur. Node _control plane_ dan anggota etcd berada pada tempat yang berbeda. + +Sebelum memulai, kamu harus memikirkan dengan matang pendekatan mana yang paling sesuai untuk kebutuhan aplikasi dan _environment_-mu. [Topik perbandingan berikut](/id/docs/setup/production-environment/tools/kubeadm/ha-topology/) menguraikan kelebihan dan kekurangan dari masing-masing pendekatan. + +Jika kamu menghadapi masalah dalam pembuatan klaster dengan ketersediaan tinggi, silakan berikan umpan balik +pada [pelacak isu](https://github.com/kubernetes/kubeadm/issues/new) kubeadm. + +Lihat juga [dokumentasi pembaruan](/id/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade-1-15). + +{{< caution >}} +Laman ini tidak menunjukkan cara untuk menjalankan klastermu pada penyedia layanan cloud. Pada _environment_ cloud, kedua pendekatan yang didokumentasikan di sini tidak akan bekerja untuk objek Service dengan tipe LoadBalancer maupun PersistentVolume dinamis. +{{< /caution >}} + + + +## {{% heading "prerequisites" %}} + + +Untuk kedua metode kamu membutuhkan infrastruktur seperti berikut: + +- Tiga mesin yang memenuhi [kebutuhan minimum kubeadm](/id/docs/setup/production-environment/tools/kubeadm/install-kubeadm/#sebelum-mulai) untuk + Node _control plane_ +- Tiga mesin yang memenuhi [kebutuhan minimum kubeadm](/id/docs/setup/production-environment/tools/kubeadm/install-kubeadm/#sebelum-mulai) untuk Node _worker_ +- Konektivitas internet pada seluruh mesin di dalam klaster (baik jaringan publik maupun jaringan pribadi) +- Hak akses sudo pada seluruh mesin +- Akses SSH dari satu perangkat ke seluruh Node pada sistem +- Perkakas `kubeadm` dan `kubelet` diinstal pada seluruh mesin. Perkakas `kubectl` bersifat opsional. + +Untuk klaster etcd eksternal saja, kamu juga membutuhkan: + +- Tiga mesin tambahan untuk anggota-anggota etcd + + + +<!-- steps --> + +## Langkah pertama untuk kedua metode + +### Membuat _load balancer_ untuk kube-apiserver + +{{< note >}} +Akan ada banyak konfigurasi untuk _load balancer_. Contoh berikut ini hanyalah salah satu +opsi. Kebutuhan klastermu mungkin membutuhkan konfigurasi berbeda. +{{< /note >}} + +1. Buat sebuah _load balancer_ kube-apiserver dengan sebuah nama yang yang akan mengubah ke dalam bentuk DNS. + + - Pada _environment_ cloud kamu harus meletakkan Node _control plane_ di belakang _load balancer_ yang meneruskan TCP. _Load balancer_ ini mendistribusikan trafik ke seluruh Node _control plane_ pada daftar tujuan. _Health check_ untuk + apiserver adalah pengujian TCP pada porta yang didengarkan oleh kube-apiserver + (nilai semula `:6443`). + + - Tidak direkomendasikan untuk menggunakan alamat IP secara langsung pada _environment_ cloud. + + - _Load balancer_ harus dapat berkomunikasi dengan seluruh Node _control plane_ + pada porta yang digunakan apiserver. _Load balancer_ tersebut juga harus mengizinkan trafik masuk pada porta yang didengarkannya. + + - Pastikan alamat _load balancer_ sesuai + dengan alamat `ControlPlaneEndpoint` pada kubeadm. + + - Baca panduan [Opsi untuk _Software Load Balancing_](https://github.com/kubernetes/kubeadm/blob/master/id/docs/ha-considerations.md#options-for-software-load-balancing) + untuk detail lebih lanjut. + +2. Tambahkan Node _control plane_ pertama pada _load balancer_ dan lakukan pengujian koneksi: + + ```sh + nc -v LOAD_BALANCER_IP PORT + ``` + + - Kegalatan koneksi yang ditolak memang diantisipasi karena apiserver belum + berjalan. Namun jika mendapat _timeout_, berarti _load balancer_ tidak dapat berkomunikasi + dengan Node _control plane_. Jika terjadi _timeout_, lakukan pengaturan ulang pada _load balancer_ agar dapat berkomunikasi dengan Node _control plane_. + +3. Tambahkan Node _control plane_ lainnya pada grup tujuan _load balancer_. + +## Node _control plane_ dan etcd bertumpuk (_stacked_) + +### Langkah-langkah untuk Node _control plane_ pertama + +1. Inisialisasi _control plane_: + + ```sh + sudo kubeadm init --control-plane-endpoint "LOAD_BALANCER_DNS:LOAD_BALANCER_PORT" --upload-certs + ``` + + - Kamu bisa menggunakan opsi `--kubernetes-version` untuk mengatur versi Kubernetes yang akan digunakan. + Direkomendasikan untuk menggunakan versi kubeadm, kubelet, kubectl, dan Kubernetes yang sama. + + - Opsi `--control-plane-endpoint` harus diatur menuju alamat atau DNS dan porta dari _load balancer_. + + - Opsi `--upload-certs` digunakan untuk mengunggah sertifikat-sertifikat yang harus dibagikan ke seluruh + Node _control plane_ pada klaster. Jika sebaliknya, kamu memilih untuk menyalin sertifikat ke + seluruh Node _control plane_ sendiri atau menggunakan perkakas automasi, silakan hapus opsi ini dan merujuk ke bagian [Distribusi sertifikat manual](#distribusi-sertifikat-manual) di bawah. + + {{< note >}} + Opsi `--config` dan `--certificate-key` pada `kubeadm init` tidak dapat digunakan secara bersamaan, maka dari itu jika kamu ingin menggunakan + [konfigurasi kubeadm](https://godoc.org/k8s.io/kubernetes/cmd/kubeadm/app/apis/kubeadm/v1beta2) + kamu harus menambahkan _field_ `certificateKey` pada lokasi pengaturan yang sesuai + (berada di bawah `InitConfiguration` dan `JoinConfiguration: controlPlane`). + {{< /note >}} + + {{< note >}} + Beberapa _plugin_ jaringan CNI membutuhkan pengaturan tambahan, seperti menentukan CIDR IP untuk Pod, meski beberapa lainnya tidak. + Lihat [dokumentasi jaringan CNI](/id/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm/#jaringan-pod). + Untuk menambahkan CIDR Pod, tambahkan opsi `--pod-network-cidr`, atau jika kamu menggunakan berkas konfigurasi kubeadm + pasang _field_ `podSubnet` di bawah objek `networking` dari `ClusterConfiguration`. + {{< /note >}} + + - Keluaran yang dihasilkan terlihat seperti berikut ini: + + ```sh + ... + You can now join any number of control-plane node by running the following command on each as a root: + kubeadm join 192.168.0.200:6443 --token 9vr73a.a8uxyaju799qwdjv --discovery-token-ca-cert-hash sha256:7c2e69131a36ae2a042a339b33381c6d0d43887e2de83720eff5359e26aec866 --control-plane --certificate-key f8902e114ef118304e561c3ecd4d0b543adc226b7a07f675f56564185ffe0c07 + + Please note that the certificate-key gives access to cluster sensitive data, keep it secret! + As a safeguard, uploaded-certs will be deleted in two hours; If necessary, you can use kubeadm init phase upload-certs to reload certs afterward. + + Then you can join any number of worker nodes by running the following on each as root: + kubeadm join 192.168.0.200:6443 --token 9vr73a.a8uxyaju799qwdjv --discovery-token-ca-cert-hash sha256:7c2e69131a36ae2a042a339b33381c6d0d43887e2de83720eff5359e26aec866 + ``` + + - Salin keluaran ini pada sebuah berkas teks. Kamu akan membutuhkannya nanti untuk menggabungkan Node _control plane_ dan _worker_ ke klaster. + - Ketika opsi `--upload-certs` digunakan dengan `kubeadm init`, sertifikat dari _control plane_ utama + akan dienkripsi dan diunggah ke Secret `kubeadm-certs`. + - Untuk mengunggah ulang sertifikat dan membuat kunci dekripsi baru, gunakan perintah berikut pada Node _control plane_ + yang sudah tergabung pada klaster: + + ```sh + sudo kubeadm init phase upload-certs --upload-certs + ``` + + - Kamu juga dapat menentukan `--certificate-key` _custom_ pada saat `init` yang nanti dapat digunakan pada saat `join`. + Untuk membuat kunci tersebut kamu dapat menggunakan perintah berikut: + + ```sh + kubeadm alpha certs certificate-key + ``` + + {{< note >}} + Secret `kubeadm-certs` dan kunci dekripsi akan kadaluarsa setelah dua jam. + {{< /note >}} + + {{< caution >}} + Seperti yang tertera pada keluaran perintah, kunci sertifikat memberikan akses ke data klaster yang bersifat sensitif, jaga kerahasiaannya! + {{< /caution >}} + +2. Pasang _plugin_ CNI pilihanmu: + [Ikuti petunjuk berikut](/id/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm/#jaringan-pod) + untuk menginstal penyedia CNI. Pastikan konfigurasinya sesuai dengan CIDR Pod yang ditentukan pada berkas konfigurasi kubeadm jika diterapkan. + + Pada contoh berikut kami menggunakan Weave Net: + + ```sh + kubectl apply -f "https://cloud.weave.works/k8s/net?k8s-version=$(kubectl version | base64 | tr -d '\n')" + ``` + +3. Tulis perintah berikut dan saksikan Pod komponen-komponen _control plane_ mulai dinyalakan: + + ```sh + kubectl get pod -n kube-system -w + ``` + +### Langkah-langkah selanjutnya untuk Node _control plane_ + +{{< note >}} +Sejak kubeadm versi 1.15 kamu dapat menggabungkan beberapa Node _control plane_ secara bersamaan. +Pada versi sebelumnya, kamu harus menggabungkan Node _control plane_ baru secara berurutan, setelah +Node pertama selesai diinisialisasi. +{{< /note >}} + +Untuk setiap Node _control plane_ kamu harus: + +1. Mengeksekusi perintah untuk bergabung yang sebelumnya diberikan pada keluaran `kubeadm init` pada Node pertama. + Perintah tersebut terlihat seperti ini: + + ```sh + sudo kubeadm join 192.168.0.200:6443 --token 9vr73a.a8uxyaju799qwdjv --discovery-token-ca-cert-hash sha256:7c2e69131a36ae2a042a339b33381c6d0d43887e2de83720eff5359e26aec866 --control-plane --certificate-key f8902e114ef118304e561c3ecd4d0b543adc226b7a07f675f56564185ffe0c07 + ``` + + - Opsi `--control-plane` menunjukkan `kubeadm join` untuk membuat _control plane_ baru. + - Opsi `--certificate-key ...` akan membuat sertifikat _control plane_ diunduh + dari Secret `kubeadm-certs` pada klaster dan didekripsi menggunakan kunci yang diberikan. + +## Node etcd eksternal + +Membangun sebuah klaster dengan Node etcd eksternal memiliki prosedur yang mirip dengan etcd bertumpuk +dengan pengecualian yaitu kamu harus setup etcd terlebih dulu, dan kamu harus memberikan informasi etcd +pada berkas konfigurasi kubeadm. + +### Memasang klaster etcd + +1. Ikuti [petunjuk berikut](/docs/setup/production-environment/tools/kubeadm/setup-ha-etcd-with-kubeadm/) untuk membangun klaster etcd. + +2. Lakukan pengaturan SSH seperti yang dijelaskan [di sini](#distribusi-sertifikat-manual). + +3. Salin berkas-berkas berikut dari Node etcd manapun pada klaster ke Node _control plane_ pertama: + + ```sh + export CONTROL_PLANE="ubuntu@10.0.0.7" + scp /etc/kubernetes/pki/etcd/ca.crt "${CONTROL_PLANE}": + scp /etc/kubernetes/pki/apiserver-etcd-client.crt "${CONTROL_PLANE}": + scp /etc/kubernetes/pki/apiserver-etcd-client.key "${CONTROL_PLANE}": + ``` + + - Ganti nilai `CONTROL_PLANE` dengan `user@host` dari mesin _control plane_ pertama. + +### Mengatur Node _control plane_ pertama + +1. Buat sebuah berkas bernama `kubeadm-config.yaml` dengan konten sebagai berikut: + + apiVersion: kubeadm.k8s.io/v1beta2 + kind: ClusterConfiguration + kubernetesVersion: stable + controlPlaneEndpoint: "LOAD_BALANCER_DNS:LOAD_BALANCER_PORT" + etcd: + external: + endpoints: + - https://ETCD_0_IP:2379 + - https://ETCD_1_IP:2379 + - https://ETCD_2_IP:2379 + caFile: /etc/kubernetes/pki/etcd/ca.crt + certFile: /etc/kubernetes/pki/apiserver-etcd-client.crt + keyFile: /etc/kubernetes/pki/apiserver-etcd-client.key + + {{< note >}} + Perbedaan antara etcd bertumpuk dan etcd eksternal yaitu etcd eksternal membutuhkan + sebuah berkas konfigurasi dengan _endpoint_ etcd di bawah objek `external`untuk `etcd`. + Pada kasus ini topologi etcd bertumpuk dikelola secara otomatis. + {{< /note >}} + + - Ganti variabel-variabel berikut pada templat konfigurasi dengan nilai yang sesuai untuk klastermu: + + - `LOAD_BALANCER_DNS` + - `LOAD_BALANCER_PORT` + - `ETCD_0_IP` + - `ETCD_1_IP` + - `ETCD_2_IP` + +Langkah-langkah berikut sama dengan pengaturan pada etcd bertumpuk: + +1. Jalankan `sudo kubeadm init --config kubeadm-config.yaml --upload-certs` pada Node ini. + +2. Tulis perintah untuk bergabung yang didapat dari keluaran ke dalam sebuah berkas teks untuk digunakan nanti. + +3. Pasang _plugin_ CNI pilihanmu. Contoh berikut ini untuk Weave Net: + + ```sh + kubectl apply -f "https://cloud.weave.works/k8s/net?k8s-version=$(kubectl version | base64 | tr -d '\n')" + ``` + +### Langkah selanjutnya untuk Node _control plane_ lainnya + +Langkah-langkah selanjutnya sama untuk pengaturan etcd bertumpuk: + +- Pastikan Node _control plane_ pertama sudah diinisialisasi dengan sempurna. +- Gabungkan setiap Node _control plane_ dengan perintah untuk bergabung yang kamu simpan dalam berkas teks. Direkomendasikan untuk +menggabungkan Node _control plane_ satu persatu. +- Jangan lupakan bahwa kunci dekripsi dari `--certificate-key` akan kadaluarsa setelah dua jam, pada pengaturan semula. + +## Tugas-tugas umum setelah menyiapkan _control plane_ + +### Menginstal _worker_ + +Node _worker_ bisa digabungkan ke klaster menggunakan perintah yang kamu simpan sebelumnya +dari keluaran perintah `kubeadm init`: + +```sh +sudo kubeadm join 192.168.0.200:6443 --token 9vr73a.a8uxyaju799qwdjv --discovery-token-ca-cert-hash sha256:7c2e69131a36ae2a042a339b33381c6d0d43887e2de83720eff5359e26aec866 +``` + +## Distribusi sertifikat manual + +Jika kamu memilih untuk tidak menggunakan `kubeadm init` dengan opsi `--upload-certs` berarti kamu harus +menyalin sertifikat dari Node _control plane_ utama secara manual ke +Node _control plane_ yang akan bergabung. + +Ada beberapa cara untuk melakukan hal ini. Pada contoh berikut ini kami menggunakan `ssh` dan `scp`: + +SSH dibutuhkan jika kamu ingin mengendalikan seluruh Node dari satu mesin. + +1. Nyalakan ssh-agent pada perangkat utamamu yang memiliki akses ke seluruh Node pada + sistem: + + ``` + eval $(ssh-agent) + ``` + +2. Tambahkan identitas SSH milikmu ke dalam sesi: + + ``` + ssh-add ~/.ssh/path_to_private_key + ``` + +3. Lakukan SSH secara bergantian ke setiap Node untuk memastikan koneksi bekerja dengan baik. + + - Ketika kamu melakukan SSH ke Node, pastikan untuk menambahkan opsi `-A`: + + ``` + ssh -A 10.0.0.7 + ``` + + - Jika kamu menggunakan sudo pada Node, pastikan kamu menyimpan _environment_ yang ada sehingga penerusan SSH + dapat bekerja dengan baik: + + ``` + sudo -E -s + ``` + +4. Setelah mengatur SSH pada seluruh Node kamu harus menjalankan skrip berikut pada Node _control plane_ pertama setelah + menjalankan `kubeadm init`. Skrip ini akan menyalin sertifikat dari Node _control plane_ pertama ke Node + _control plane_ lainnya: + + Pada contoh berikut, ganti `CONTROL_PLANE_IPS` dengan alamat IP dari + Node _control plane_ lainnya. + ```sh + USER=ubuntu # dapat disesuaikan + CONTROL_PLANE_IPS="10.0.0.7 10.0.0.8" + for host in ${CONTROL_PLANE_IPS}; do + scp /etc/kubernetes/pki/ca.crt "${USER}"@$host: + scp /etc/kubernetes/pki/ca.key "${USER}"@$host: + scp /etc/kubernetes/pki/sa.key "${USER}"@$host: + scp /etc/kubernetes/pki/sa.pub "${USER}"@$host: + scp /etc/kubernetes/pki/front-proxy-ca.crt "${USER}"@$host: + scp /etc/kubernetes/pki/front-proxy-ca.key "${USER}"@$host: + scp /etc/kubernetes/pki/etcd/ca.crt "${USER}"@$host:etcd-ca.crt + # Kutip baris berikut jika kamu menggunakan etcd eksternal + scp /etc/kubernetes/pki/etcd/ca.key "${USER}"@$host:etcd-ca.key + done + ``` + + {{< caution >}} + Salinlah hanya sertifikat yang berada pada daftar di atas saja. Perkakas kubeadm akan mengambil alih pembuatan sertifikat lainnya + dengan SANs yang dibutuhkan untuk Node _control plane_ yang akan bergabung. Jika kamu menyalin seluruh sertifikat tanpa sengaja, + pembuatan Node tambahan dapat gagal akibat tidak adanya SANs yang dibutuhkan. + {{< /caution >}} + +5. Lalu, pada setiap Node _control plane_ yang bergabung kamu harus menjalankan skrip berikut sebelum menjalankan `kubeadm join`. + Skrip ini akan memindahkan sertifikat yang telah disalin sebelumnya dari direktori _home_ ke `/etc/kubernetes/pki`: + + ```sh + USER=ubuntu # dapat disesuaikan + mkdir -p /etc/kubernetes/pki/etcd + mv /home/${USER}/ca.crt /etc/kubernetes/pki/ + mv /home/${USER}/ca.key /etc/kubernetes/pki/ + mv /home/${USER}/sa.pub /etc/kubernetes/pki/ + mv /home/${USER}/sa.key /etc/kubernetes/pki/ + mv /home/${USER}/front-proxy-ca.crt /etc/kubernetes/pki/ + mv /home/${USER}/front-proxy-ca.key /etc/kubernetes/pki/ + mv /home/${USER}/etcd-ca.crt /etc/kubernetes/pki/etcd/ca.crt + # Kutip baris berikut jika kamu menggunakan etcd eksternal + mv /home/${USER}/etcd-ca.key /etc/kubernetes/pki/etcd/ca.key + ``` + diff --git a/content/id/docs/setup/production-environment/tools/kubeadm/install-kubeadm.md b/content/id/docs/setup/production-environment/tools/kubeadm/install-kubeadm.md new file mode 100644 index 0000000000..adcf73db77 --- /dev/null +++ b/content/id/docs/setup/production-environment/tools/kubeadm/install-kubeadm.md @@ -0,0 +1,307 @@ +--- +title: Menginstal kubeadm +content_type: task +weight: 10 +card: + name: setup + weight: 20 + title: Menginstal alat persiapan kubeadm +--- + +<!-- overview --> + +<img src="https://raw.githubusercontent.com/kubernetes/kubeadm/master/logos/stacked/color/kubeadm-stacked-color.png" align="right" width="150px">Laman ini menunjukkan cara untuk menginstal `kubeadm`. +Untuk informasi mengenai cara membuat sebuah klaster dengan kubeadm setelah kamu melakukan proses instalasi ini, lihat laman [Menggunakan kubeadm untuk Membuat Sebuah Klaster](/id/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm/). + + + +## {{% heading "prerequisites" %}} + + +* Satu mesin atau lebih yang menjalankan: + - Ubuntu 16.04+ + - Debian 9+ + - CentOS 7 + - Red Hat Enterprise Linux (RHEL) 7 + - Fedora 25+ + - HypriotOS v1.0.1+ + - Container Linux (teruji pada versi 1800.6.0) +* 2 GB RAM atau lebih per mesin (kurang dari nilai tersebut akan menyisakan sedikit ruang untuk + aplikasi-aplikasimu) +* 2 CPU atau lebih +* Koneksi internet pada seluruh mesin pada klaster (kamu dapat menggunakan internet + publik ataupun pribadi) +* _Hostname_ yang unik, alamat MAC, dan product_uuid untuk setiap Node. Lihat [di sini](#memastikan-alamat-mac) untuk detail lebih lanjut. +* Porta tertentu pada mesin. Lihat [di sini](#memeriksa-porta-yang-dibutuhkan) untuk detail lebih lanjut. +* _Swap_ dinonaktifkan. Kamu **HARUS** menonaktifkan _swap_ agar kubelet dapat berfungsi dengan baik. + + + +<!-- steps --> + +## Memastikan alamat MAC dan product_uuid yang unik untuk setiap Node {#memastikan-alamat-mac} + +* Kamu bisa mendapatkan alamat MAC dari antarmuka jaringan menggunakan perintah `ip link` atau `ifconfig -a` +* product_uuid didapatkan dengan perintah `sudo cat /sys/class/dmi/id/product_uuid` + +Sangat memungkinkan bagi perangkat keras untuk memiliki alamat yang unik, namun beberapa mesin virtual bisa memiliki +nilai yang identik. Kubernetes menggunakan nilai-nilai tersebut untuk mengidentifikasi Node-Node secara unik pada klaster. +Jika nilai-nilai tersebut tidak unik pada tiap Node, proses instalasi +bisa saja [gagal](https://github.com/kubernetes/kubeadm/issues/31). + +## Memeriksa adaptor jaringan + +Jika kamu memiliki lebih dari satu adaptor jaringan, dan komponen Kubernetes tidak dapat dijangkau melalui rute bawaan (_default route_), +kami merekomendasikan kamu untuk menambahkan rute IP sehingga alamat-alamat klaster Kubernetes melewati adaptor yang tepat. + +## Membuat iptables melihat _bridged traffic_ + +Agar iptables pada Node Linux dapat melihat _bridged traffic_ dengan benar, kamu harus memastikan `net.bridge.bridge-nf-call-iptables` bernilai 1 pada pengaturan `sysctl`, misalnya. + +```bash +cat <<EOF | sudo tee /etc/sysctl.d/k8s.conf +net.bridge.bridge-nf-call-ip6tables = 1 +net.bridge.bridge-nf-call-iptables = 1 +EOF +sudo sysctl --system +``` + +Pastikan modul `br_netfilter` sudah dimuat sebelum melakukan langkah ini. Hal ini dilakukan dengan menjalankan `lsmod | grep br_netfilter`. Untuk memuatnya secara eksplisit gunakan `sudo modprobe br_netfilter`. + +Untuk detail lebih lanjut, silakan lihat laman [Persyaratan _Plugin_ Jaringan](/id/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/#persyaratan-plugin-jaringan). + +## Memeriksa porta yang dibutuhkan + +### Node _control-plane_ + +| Protokol | Arah | Rentang Porta | Kegunaan | Digunakan oleh | +|----------|-----------|------------|-------------------------|---------------------------| +| TCP | Inbound | 6443* | Kubernetes API server | All | +| TCP | Inbound | 2379-2380 | etcd server client API | kube-apiserver, etcd | +| TCP | Inbound | 10250 | Kubelet API | Self, Control plane | +| TCP | Inbound | 10251 | kube-scheduler | Self | +| TCP | Inbound | 10252 | kube-controller-manager | Self | + +### Node pekerja (_worker_) + +| Protokol | Arah | Rentang Porta | Kegunaan | Digunakan oleh | +|----------|-----------|-------------|-----------------------|-------------------------| +| TCP | Inbound | 10250 | Kubelet API | Self, Control plane | +| TCP | Inbound | 30000-32767 | NodePort Services† | All | + +† Jangkauan porta bawaan untuk [Service NodePort](/id/docs/concepts/services-networking/service/). + +Angka porta yang ditandai dengan * dapat diganti (_overrideable_), sehingga kamu harus memastikan porta khusus lainnya yang kamu sediakan juga terbuka. + +Meskipun porta etcd turut dituliskan pada Node _control-plane_, kamu juga bisa menghos klaster etcd-mu sendiri +secara eksternal atau pada porta _custom_. + +_Plugin_ jaringan Pod yang kamu gunakan (lihat di bawah) juga mungkin membutuhkan porta tertentu untuk terbuka. +Karena hal ini dapat berbeda pada setiap _plugin_ jaringan Pod, silakan lihat +dokumentasi _plugin_ mengenai porta yang dibutuhkan. + +## Menginstal _runtime_ + +Untuk menjalankan Container pada Pod, Kubernetes menggunakan +{{< glossary_tooltip term_id="container-runtime" text="_runtime_ Container" >}}. + +{{< tabs name="container_runtime" >}} +{{% tab name="Linux nodes" %}} + +Secara bawaan, Kubernetes menggunakan +{{< glossary_tooltip term_id="cri" text="Container Runtime Interface">}} (CRI) +sebagai perantara dengan _runtime_ Container pilihanmu. + +Jika kamu tidak menentukan _runtime_, kubeadm secara otomatis mencoba untuk mendeteksi +_runtime_ Container yang terinstal dengan memindai sekumpulan soket domain Unix yang umum digunakan. +Tabel berikut menunjukkan _runtime_ Container dan lokasi soketnya: + +{{< table caption = "_Runtime_ Container dan lokasi soketnya" >}} +| _Runtime_ | Lokasi domain soket Unix | +|------------|-----------------------------------| +| Docker | `/var/run/docker.sock` | +| containerd | `/run/containerd/containerd.sock` | +| CRI-O | `/var/run/crio/crio.sock` | +{{< /table >}} + +<br /> +Jika ditemukan Docker dan containerd secara bersamaan, Docker akan terpilih. Hal ini diperlukan +karena Docker 18.09 dirilis dengan containerd dan keduanya dapat ditemukan meskipun kamu +hanya menginstal Docker. +Jika ditemukan selain dari kedua _runtime_ Container tersebut, kubeadm akan berhenti dengan kegagalan. + +Komponen kubelet berintegrasi dengan Docker melalui implementasi CRI `dockershim` bawaannya. + +Lihat [_runtime_ Container](/id/docs/setup/production-environment/container-runtimes/) +untuk informasi lebih lanjut. +{{% /tab %}} +{{% tab name="sistem operasi lainnya" %}} +Secara bawaan, kubeadm menggunakan {{< glossary_tooltip term_id="docker" >}} sebagai _runtime_ Container. +Komponen kubelet berintegrasi dengan Docker melalui implementasi CRI `dockershim` bawaannya. + +Lihat [_runtime_ Container](/id/docs/setup/production-environment/container-runtimes/) +untuk informasi lebih lanjut. +{{% /tab %}} +{{< /tabs >}} + + +## Menginstal kubeadm, kubelet, dan kubectl + +Kamu akan menginstal _package_ berikut pada semua mesinmu: + +* `kubeadm`: alat untuk mem-_bootstrap_ klaster. + +* `kubelet`: komponen yang berjalan pada seluruh mesin pada klaster + dan memiliki tugas seperti menjalankan Pod dan Container. + +* `kubectl`: alat untuk berinteraksi dengan klastermu. + +Alat kubeadm **tidak akan** menginstal atau mengelola `kubelet` ataupun `kubectl` untukmu, jadi kamu harus memastikan +keduanya memiliki versi yang cocok dengan _control plane_ Kubernetes yang akan kamu instal +dengan kubeadm. Jika tidak, ada risiko _version skew_ yang dapat terjadi dan +dapat berujung pada perangai yang bermasalah dan tidak terduga. Namun, _satu_ _version skew_ minor antara +kubelet dan _control plane_ masih diperbolehkan, tetapi versi kubelet tidak boleh melebihi versi API +Server. Sebagai contoh, kubelet yang berjalan pada versi 1.7.0 akan kompatibel dengan API Server versi 1.8.0, tetapi tidak sebaliknya. + +Untuk informasi mengenai instalasi `kubectl`, lihat [Menginstal dan mengatur kubectl](/id/docs/tasks/tools/install-kubectl/). + +{{< warning >}} +Instruksi ini membuat seluruh _package_ Kubernetes keluar dari _system upgrade_. +Hal ini karena kubeadm dan Kubernetes membutuhkan +[perhatian khusus untuk pembaharuan](/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade/). +{{</ warning >}} + +Untuk informasi lebih lanjut mengenai _version skew_, lihat: + +* [Kebijakan _version-skew_ dan versi Kubernetes](/docs/setup/release/version-skew-policy/) +* [Kebijakan _version skew_](/id/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm/#version-skew-policy) yang spesifik untuk kubeadm + +{{< tabs name="k8s_install" >}} +{{% tab name="Ubuntu, Debian atau HypriotOS" %}} +```bash +sudo apt-get update && sudo apt-get install -y apt-transport-https curl +curl -s https://packages.cloud.google.com/apt/doc/apt-key.gpg | sudo apt-key add - +cat <<EOF | sudo tee /etc/apt/sources.list.d/kubernetes.list +deb https://apt.kubernetes.io/ kubernetes-xenial main +EOF +sudo apt-get update +sudo apt-get install -y kubelet kubeadm kubectl +sudo apt-mark hold kubelet kubeadm kubectl +``` +{{% /tab %}} +{{% tab name="CentOS, RHEL atau Fedora" %}} +```bash +cat <<EOF > /etc/yum.repos.d/kubernetes.repo +[kubernetes] +name=Kubernetes +baseurl=https://packages.cloud.google.com/yum/repos/kubernetes-el7-\$basearch +enabled=1 +gpgcheck=1 +repo_gpgcheck=1 +gpgkey=https://packages.cloud.google.com/yum/doc/yum-key.gpg https://packages.cloud.google.com/yum/doc/rpm-package-key.gpg +exclude=kubelet kubeadm kubectl +EOF + +# Mengatur SELinux menjadi permissive mode (menonaktifkannya secara efektif) +setenforce 0 +sed -i 's/^SELINUX=enforcing$/SELINUX=permissive/' /etc/selinux/config + +yum install -y kubelet kubeadm kubectl --disableexcludes=kubernetes + +systemctl enable --now kubelet +``` + + **Catatan:** + + - Mengatur SELinux menjadi _permissive mode_ dengan menjalankan `setenforce 0` dan `sed ...` menonaktifkannya secara efektif. + Hal ini diperlukan untuk mengizinkan Container untuk mengakses _filesystem_ hos, yang dibutuhkan untuk jaringan Pod sebagai contoh. + Kamu harus melakukan ini sampai dukungan SELinux ditingkatkan pada kubelet. + + - Kamu dapat membiarkan SELinux aktif jika kamu mengetahui cara mengonfigurasinya, tetapi hal tersebut mungkin membutuhkan pengaturan yang tidak didukung oleh kubeadm. + +{{% /tab %}} +{{% tab name="Container Linux" %}} +Menginstal _plugin_ CNI (dibutuhkan untuk kebanyakan jaringan Pod): + +```bash +CNI_VERSION="v0.8.2" +mkdir -p /opt/cni/bin +curl -L "https://github.com/containernetworking/plugins/releases/download/${CNI_VERSION}/cni-plugins-linux-amd64-${CNI_VERSION}.tgz" | tar -C /opt/cni/bin -xz +``` + +Menginstal crictl (dibutuhkan untuk kubeadm / Kubelet Container Runtime Interface (CRI)) + +```bash +CRICTL_VERSION="v1.17.0" +mkdir -p /opt/bin +curl -L "https://github.com/kubernetes-sigs/cri-tools/releases/download/${CRICTL_VERSION}/crictl-${CRICTL_VERSION}-linux-amd64.tar.gz" | tar -C /opt/bin -xz +``` + +Menginstal `kubeadm`, `kubelet`, `kubectl` dan menambahkan _systemd service_ `kubelet`: + +```bash +RELEASE="$(curl -sSL https://dl.k8s.io/release/stable.txt)" + +mkdir -p /opt/bin +cd /opt/bin +curl -L --remote-name-all https://storage.googleapis.com/kubernetes-release/release/${RELEASE}/bin/linux/amd64/{kubeadm,kubelet,kubectl} +chmod +x {kubeadm,kubelet,kubectl} + +RELEASE_VERSION="v0.2.7" +curl -sSL "https://raw.githubusercontent.com/kubernetes/release/${RELEASE_VERSION}/cmd/kubepkg/templates/latest/deb/kubelet/lib/systemd/system/kubelet.service" | sed "s:/usr/bin:/opt/bin:g" > /etc/systemd/system/kubelet.service +mkdir -p /etc/systemd/system/kubelet.service.d +curl -sSL "https://raw.githubusercontent.com/kubernetes/release/${RELEASE_VERSION}/cmd/kubepkg/templates/latest/deb/kubeadm/10-kubeadm.conf" | sed "s:/usr/bin:/opt/bin:g" > /etc/systemd/system/kubelet.service.d/10-kubeadm.conf +``` + +Mengaktifkan dan menjalankan `kubelet`: + +```bash +systemctl enable --now kubelet +``` +{{% /tab %}} +{{< /tabs >}} + + +Sekarang kubelet akan melakukan _restart_ setiap beberapa detik, sambil menunggu dalam kondisi _crashloop_ sampai kubeadm memberikan instruksi yang harus dilakukan. + +## Mengonfigurasi _driver_ cgroup yang digunakan oleh kubelet pada Node _control-plane_ {#mengonfigurasi-cgroup-untuk-kubelet-pada-node-control-plane} + +Ketika menggunakan Docker, kubeadm akan mendeteksi secara otomatis _driver_ cgroup untuk kubelet +dan mengaturnya pada berkas `/var/lib/kubelet/config.yaml` pada saat _runtime_. + +Jika kamu menggunakan CRI yang berbeda, kamu harus memodifikasi berkasnya dengan nilai `cgroupDriver` yang kamu gunakan, seperti berikut: + +```yaml +apiVersion: kubelet.config.k8s.io/v1beta1 +kind: KubeletConfiguration +cgroupDriver: <value> +``` + +Harap diperhatikan, kamu **hanya** perlu melakukannya jika _driver_ cgroup dari CRI pilihanmu +bukanlah `cgroupfs`, karena nilai tersebut merupakan nilai bawaan yang digunakan oleh kubelet. + +{{< note >}} +Karena opsi `--cgroup-driver` sudah dihilangkan pada kubelet, jika kamu memilikinya pada `/var/lib/kubelet/kubeadm-flags.env` +atau `/etc/default/kubelet`(`/etc/sysconfig/kubelet` untuk RPM), silakan hapus dan gunakan KubeletConfiguration +(secara bawaan disimpan di `/var/lib/kubelet/config.yaml`). +{{< /note >}} + +Kamu harus melakukan _restart_ pada kubelet: + +```bash +systemctl daemon-reload +systemctl restart kubelet +``` + +Deteksi _driver_ cgroup secara otomatis untuk _runtime_ Container lainnya +seperti CRI-O dan containerd masih dalam proses pengembangan. + + +## Penyelesaian masalah + +Jika kamu menemui kesulitan dengan kubeadm, silakan merujuk pada [dokumen penyelesaian masalah](/docs/setup/production-environment/tools/kubeadm/troubleshooting-kubeadm/). + +## {{% heading "whatsnext" %}} + + +* [Menggunakan kubeadm untuk Membuat Sebuah Klaster](/id/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm/) diff --git a/content/id/docs/tasks/access-application-cluster/access-cluster.md b/content/id/docs/tasks/access-application-cluster/access-cluster.md index 148f402402..6a575ad8f1 100644 --- a/content/id/docs/tasks/access-application-cluster/access-cluster.md +++ b/content/id/docs/tasks/access-application-cluster/access-cluster.md @@ -178,7 +178,7 @@ Saat mengakses API dari Pod, pencarian dan autentikasi ke apiserver agak berbeda Cara yang disarankan untuk menemukan apiserver di dalam Pod adalah dengan nama DNS `kubernetes.default.svc`, yang akan mengubah kedalam bentuk Service IP yang pada gilirannya akan dialihkan ke apiserver. -Cara yang disarankan untuk mengautentikasi ke apiserver adalah dengan kredensial [akun servis](/docs/tasks/configure-pod-container/configure-service-account/). +Cara yang disarankan untuk mengautentikasi ke apiserver adalah dengan kredensial [akun servis](/id/docs/tasks/configure-pod-container/configure-service-account/). Oleh kube-system, Pod dikaitkan dengan sebuah akun servis (_service account_), dan sebuah kredensial (token) untuk akun servis (_service account_) tersebut ditempatkan ke pohon sistem berkas (_file system tree_) dari setiap Container di dalam Pod tersebut, di `/var/run/secrets/kubernetes.io/serviceaccount/token`. @@ -317,7 +317,7 @@ Ada beberapa proksi berbeda yang mungkin kamu temui saat menggunakan Kubernetes: - dapat digunakan untuk menjangkau Node, Pod, atau Service - melakukan _load balancing_ saat digunakan untuk menjangkau sebuah Service -1. [kube-proxy](/docs/concepts/services-networking/service/#ips-and-vips): +1. [kube-proxy](/id/docs/concepts/services-networking/service/#ips-and-vips): - berjalan di setiap Node - memproksi UDP dan TCP diff --git a/content/id/docs/tasks/access-application-cluster/configure-access-multiple-clusters.md b/content/id/docs/tasks/access-application-cluster/configure-access-multiple-clusters.md index b2b80aacba..8775823304 100644 --- a/content/id/docs/tasks/access-application-cluster/configure-access-multiple-clusters.md +++ b/content/id/docs/tasks/access-application-cluster/configure-access-multiple-clusters.md @@ -320,7 +320,7 @@ contexts: ``` Untuk informasi lebih tentang bagaimana berkas Kubeconfig tergabung, lihat -[Mengatur Akses Cluster Menggunakan Berkas Kubeconfig](/docs/concepts/configuration/organize-cluster-access-kubeconfig/) +[Mengatur Akses Cluster Menggunakan Berkas Kubeconfig](/id/docs/concepts/configuration/organize-cluster-access-kubeconfig/) ## Jelajahi direktori $HOME/.kube @@ -372,7 +372,7 @@ $Env:KUBECONFIG=$ENV:KUBECONFIG_SAVED ## {{% heading "whatsnext" %}} -* [Mengatur Akses Cluster Menggunakan Berkas Kubeconfig](/docs/concepts/configuration/organize-cluster-access-kubeconfig/) +* [Mengatur Akses Cluster Menggunakan Berkas Kubeconfig](/id/docs/concepts/configuration/organize-cluster-access-kubeconfig/) * [kubectl config](/docs/reference/generated/kubectl/kubectl-commands#config) diff --git a/content/id/docs/tasks/access-application-cluster/create-external-load-balancer.md b/content/id/docs/tasks/access-application-cluster/create-external-load-balancer.md new file mode 100644 index 0000000000..d6d04df2ad --- /dev/null +++ b/content/id/docs/tasks/access-application-cluster/create-external-load-balancer.md @@ -0,0 +1,197 @@ +--- +title: Membuat Load Balancer Eksternal +content_type: task +weight: 80 +--- + + +<!-- overview --> + +Laman ini menjelaskan bagaimana membuat _Load Balancer_ Eksternal. + +{{< note >}} +Fitur ini hanya tersedia untuk penyedia cloud atau lingkungan yang mendukung _load balancer_ eksternal. +{{< /note >}} + +Ketika membuat Service, kamu mempunyai opsi untuk tersambung dengan jaringan cloud _load balancer_ secara otomatis. +Hal ini menyediakan akses eksternal alamat IP yang dapat mengirim lalu lintas melalui porta yang tepat pada klaster Node kamu +_asalkan klaster kamu beroperasi pada lingkungan yang mendukung dan terkonfigurasi dengan paket penyedia cloud load balancer yang benar_. + +Untuk informasi mengenai penyediaan dan penggunaan sumber daya Ingress yang dapat memberikan +servis URL yang dapat dijangkau secara eksternal, penyeimbang beban lalu lintas, terminasi SSL, dll., +silahkan cek dokumentasi [Ingress](/id/docs/concepts/services-networking/ingress/) + + + +## {{% heading "prerequisites" %}} + + +* {{< include "task-tutorial-prereqs.md" >}} {{< version-check >}} + + + +<!-- steps --> + +## Berkas konfigurasi + +Untuk membuat _load balancer_ eksternal, tambahkan baris di bawah ini ke +[berkas konfigurasi Service](/id/docs/concepts/services-networking/service/#loadbalancer) kamu: + +```yaml + type: LoadBalancer +``` + +Berkas konfigurasi kamu mungkin terlihat seperti ini: + +```yaml +apiVersion: v1 +kind: Service +metadata: + name: example-service +spec: + selector: + app: example + ports: + - port: 8765 + targetPort: 9376 + type: LoadBalancer +``` + +## Menggunakan kubectl + +Kamu dapat membuat Service dengan perintah `kubectl expose` dan +_flag_ `--type=LoadBalancer`: + +```bash +kubectl expose rc example --port=8765 --target-port=9376 \ + --name=example-service --type=LoadBalancer +``` + +Perintah ini membuat Service baru dengan menggunakan pemilih yang sama dengan +sumber daya yang dirujuk (dalam hal contoh di atas, ReplicationController bernama `example`). + +Untuk informasi lebih lanjut, termasuk opsi _flag_, mengacu kepada +[referensi `kubectl expose`](/docs/reference/generated/kubectl/kubectl-commands/#expose). + +## Menemukan alamat IP kamu + +Kamu dapat menemukan alamat IP yang telah dibuat untuk Service kamu dengan mendapatkan +informasi Service melalui `kubectl`: + +```bash +kubectl describe services example-service +``` + +yang seharusnya menghasilkan keluaran seperti ini: + +```bash + Name: example-service + Namespace: default + Labels: <none> + Annotations: <none> + Selector: app=example + Type: LoadBalancer + IP: 10.67.252.103 + LoadBalancer Ingress: 192.0.2.89 + Port: <unnamed> 80/TCP + NodePort: <unnamed> 32445/TCP + Endpoints: 10.64.0.4:80,10.64.1.5:80,10.64.2.4:80 + Session Affinity: None + Events: <none> +``` + +Alamat IP tercantum di sebelah `LoadBalancer Ingress`. + +{{< note >}} +Jika kamu menjalankan Service dari Minikube, kamu dapat menemukan alamat IP dan porta yang ditetapkan dengan: +{{< /note >}} + +```bash +minikube service example-service --url +``` + +## Preservasi IP sumber klien + +Implementasi dari fitur ini menyebabkan sumber IP yang terlihat pada Container +target *bukan sebagai sumber IP asli* dari klien. Untuk mengaktifkan +preservasi IP klien, bidang berikut dapat dikonfigurasikan di dalam +spek Service (mendukung lingkungan GCE/Google Kubernetes Engine): + +* `service.spec.externalTrafficPolicy` - menunjukkan jika Service menginginkan rute lalu lintas +eksternal ke titik akhir _node-local_ atau _cluster-wide_. Terdapat dua opsi yang tersedia: +`Cluster` (bawaan) dan `Local`. `Cluster` mengaburkan sumber IP klien dan mungkin menyebabkan +hop kedua ke Node berbeda, namun harus mempunyai penyebaran beban (_load-spreading_) yang baik secara keseluruhan. +`Local` mempreservasi sumber IP client dan menghindari hop kedua `LoadBalancer` dan Service dengan tipe `NodePort`, namun +resiko berpotensi penyebaran lalu lintas yang tidak merata. +* `service.spec.healthCheckNodePort` - menentukan pemeriksaan kesehatan porta dari sebuah Node (angka porta numerik) untuk Service. +Jika `healthCheckNodePort` tidak ditentukan, pengendali Service mengalokasi +porta dari rentang `NodePort` dari klaster kamu. Kamu dapat mengonfigurasi +rentangan tersebut dari pengaturan opsi barisan perintah API server, +`--service-node-port-range`. Hal itu menggunakan nilai `healthCheckNodePort` pengguna spesifik +jika ditentukan oleh klien. Hal itu dapat berefek hanya ketika `type` diset ke `LoadBalancer` dan +`externalTrafficPolicy` diset ke `Local`. + +Pengaturan `externalTrafficPolicy` ke `Local` pada berkas konfigurasi Service mengaktifkan +fitur ini. + +```yaml +apiVersion: v1 +kind: Service +metadata: + name: example-service +spec: + selector: + app: example + ports: + - port: 8765 + targetPort: 9376 + externalTrafficPolicy: Local + type: LoadBalancer +``` + +## Pengumpul Sampah (Garbage Collector) Load Balancer + +{{< feature-state for_k8s_version="v1.17" state="stable" >}} + +Pada kasus biasa, sumber daya _load balancer_ yang berkorelasi pada penyedia cloud perlu +dibersihkan segera setelah Service bertipe _LoadBalancer_ dihapus. Namun perlu diketahui +bahwa terdapat kasus tepi dimana sumber daya cloud yatim piatu (_orphaned_) setelah +Service yang berkaitan dihapus. _Finalizer Protection_ untuk Service _LoadBalancer_ +diperkenalkan untuk mencegah hal ini terjadi. Dengan menggunakan _finalizers_, sebuah sumber daya Service +tidak akan pernah dihapus hingga sumber daya _load balancer_ yang berkorelasi juga dihapus. + +Secara khusus, jika Service mempunyai `type LoadBalancer`, pengendali Service akan melekatkan +_finalizer_ bernama `service.kubernetes.io/load-balancer-cleanup`. +_Finalizer_ hanya akan dihapus setelah sumber daya _load balancer_ dibersihkan. +Hal ini mencegah sumber daya _load balancer_ yang teruntai bahkan setelah kasus tepi seperti +pengendali Service berhenti. + +## Penyedia Load Balancer Eksternal + +Penting untuk dicatat bahwa jalur data untuk fungsionalitas ini disediakan oleh _load balancer_ eksternal ke klaster Kubernetes. + +Ketika Service `type` diset `LoadBalancer`, Kubernetes menyediakan fungsionalitas yang ekuivalen dengan `type` sebanding `ClusterIP` +ke berbagai Pod di dalam klaster dan mengekstensinya dengan pemrograman (eksternal dari Kubernetes) _load balancer_ dengan entri pada Pod +Kubernetes. Pengendali Service Kubernetes mengotomasi pembuatan _load balancer_ eksternal, cek kesehatan (jika dibutuhkan), +dinding api (_firewall_) (jika dibutuhkan), dan mengambil IP eksternal yang dialokasikan oleh penyedia cloud dan mengisinya pada objek Service. + +## Peringatan dan and Limitasi ketika preservasi sumber IP + +_Load balancers_ GCE/AWS tidak menyediakan bobot pada kolam targetnya (target pools). Hal ini bukan merupakan isu dengan aturan kube-proxy +_Load balancer_ lama yang akan menyeimbangkan semua titik akhir dengan benar. + +Dengan fungsionalitas yang baru, lalu lintas eksternal tidak menyeimbangkan beban secara merata pada seluruh Pod, namun +sebaliknya menyeimbangkan secara merata pada level Node (karena GCE/AWS dan implementasi _load balancer_ eksternal lainnya tidak mempunyai +kemampuan untuk menentukan bobot setiap Node, mereka menyeimbangkan secara merata pada semua Node target, mengabaikan jumlah +Pod pada tiap Node). + + +Namun demikian, kita dapat menyatakan bahwa NumServicePods << NumNodes atau NumServicePods >> NumNodes, distribusi yang cukup mendekati +sama akan terlihat, meski tanpa bobot. + +Sekali _load balancer_ eksternal menyediakan bobot, fungsionalitas ini dapat ditambahkan pada jalur pemrograman _load balancer_. +*Pekerjaan Masa Depan: Tidak adanya dukungan untuk bobot yang disediakan untuk rilis 1.4, namun dapat ditambahkan di masa mendatang* + +Pod internal ke lalu lintas Pod harus berperilaku sama seperti Service ClusterIP, dengan probabilitas yang sama pada seluruh Pod. + + diff --git a/content/id/docs/tasks/access-application-cluster/list-all-running-container-images.md b/content/id/docs/tasks/access-application-cluster/list-all-running-container-images.md new file mode 100644 index 0000000000..f2140e5276 --- /dev/null +++ b/content/id/docs/tasks/access-application-cluster/list-all-running-container-images.md @@ -0,0 +1,129 @@ +--- +title: Membuat Daftar Semua Image Container yang Berjalan dalam Klaster +content_type: task +weight: 100 +--- + +<!-- overview --> + +Laman ini menunjukkan cara menggunakan kubectl untuk membuat daftar semua _image_ Container +untuk Pod yang berjalan dalam sebuah klaster. + + + +## {{% heading "prerequisites" %}} + + +{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}} + + + +<!-- steps --> + +Dalam latihan ini kamu akan menggunakan kubectl untuk mengambil semua Pod yang +berjalan dalam sebuah klaster, dan mengubah format keluarannya untuk melihat daftar +Container untuk masing-masing Pod. + +## Membuat daftar semua _image_ Container pada semua Namespace + +- Silakan ambil semua Pod dalam Namespace dengan menggunakan perintah `kubectl get pods --all-namespaces` +- Silakan format keluarannya agar hanya menyertakan daftar nama _image_ dari Container + dengan menggunakan perintah `-o jsonpath={..image}`. Perintah ini akan mem-_parsing field_ + `image` dari keluaran json yang dihasilkan. + - Silakan lihat [referensi jsonpath](/docs/user-guide/jsonpath/) + untuk informasi lebih lanjut tentang cara menggunakan `jsonpath`. +- Silakan format keluaran dengan menggunakan peralatan standar: `tr`, `sort`, `uniq` + - Gunakan `tr` untuk mengganti spasi dengan garis baru + - Gunakan `sort` untuk menyortir hasil + - Gunakan `uniq` untuk mengumpulkan jumlah _image_ + +```sh +kubectl get pods --all-namespaces -o jsonpath="{..image}" |\ +tr -s '[[:space:]]' '\n' |\ +sort |\ +uniq -c +``` + +Perintah di atas secara berulang akan mengembalikan semua _field_ bernama `image` +dari semua poin yang dikembalikan. + +Sebagai pilihan, dimungkinkan juga untuk menggunakan jalur (_path_) absolut ke _field image_ +di dalam Pod. Hal ini memastikan _field_ yang diambil benar +bahkan ketika nama _field_ tersebut diulangi, +misalnya banyak _field_ disebut dengan `name` dalam sebuah poin yang diberikan: + +```sh +kubectl get pods --all-namespaces -o jsonpath="{.items[*].spec.containers[*].image}" +``` + +`Jsonpath` dapat diartikan sebagai berikut: + +- `.items[*]`: untuk setiap nilai yang dihasilkan +- `.spec`: untuk mendapatkan spesifikasi +- `.containers[*]`: untuk setiap Container +- `.image`: untuk mendapatkan _image_ + +{{< note >}} +Pada saat mengambil sebuah Pod berdasarkan namanya, misalnya `kubectl get pod nginx`, +bagian `.items[*]` dari jalur harus dihilangkan karena hanya akan menghasilkan sebuah Pod +sebagai keluarannya, bukan daftar dari semua Pod. + +{{< /note >}} + +## Membuat daftar _image_ Container berdasarkan Pod + +Format dapat dikontrol lebih lanjut dengan menggunakan operasi `range` untuk +melakukan iterasi untuk setiap elemen secara individual. + +```sh +kubectl get pods --all-namespaces -o=jsonpath='{range .items[*]}{"\n"}{.metadata.name}{":\t"}{range .spec.containers[*]}{.image}{", "}{end}{end}' |\ +sort +``` + +## Membuat daftar _image_ yang difilter berdasarkan label dari Pod + +Untuk menargetkan hanya Pod yang cocok dengan label tertentu saja, gunakan tanda -l. Filter +dibawah ini akan menghasilkan Pod dengan label yang cocok dengan `app=nginx`. + +```sh +kubectl get pods --all-namespaces -o=jsonpath="{..image}" -l app=nginx +``` + +## Membuat daftar _image_ Container yang difilter berdasarkan Namespace Pod + +Untuk hanya menargetkan Pod pada Namespace tertentu, gunakankan tanda Namespace. Filter +dibawah ini hanya menyaring Pod pada Namespace `kube-system`. + +```sh +kubectl get pods --namespace kube-system -o jsonpath="{..image}" +``` + +## Membuat daftar _image_ Container dengan menggunakan go-template sebagai alternatif dari jsonpath + +Sebagai alternatif untuk `jsonpath`, kubectl mendukung penggunaan [go-template](https://golang.org/pkg/text/template/) +untuk memformat keluaran seperti berikut: + + +```sh +kubectl get pods --all-namespaces -o go-template --template="{{range .items}}{{range .spec.containers}}{{.image}} {{end}}{{end}}" +``` + + + + + +<!-- discussion --> + + + +## {{% heading "whatsnext" %}} + + +### Referensi + +* Referensi panduan [Jsonpath](/docs/user-guide/jsonpath/). +* Referensi panduan [Go template](https://golang.org/pkg/text/template/). + + + + diff --git a/content/id/docs/tasks/access-application-cluster/web-ui-dashboard.md b/content/id/docs/tasks/access-application-cluster/web-ui-dashboard.md index a83605db40..99d23c823d 100644 --- a/content/id/docs/tasks/access-application-cluster/web-ui-dashboard.md +++ b/content/id/docs/tasks/access-application-cluster/web-ui-dashboard.md @@ -69,17 +69,17 @@ Tekan tombol **CREATE** di pojok kanan atas di laman apapun untuk memulai. _Deploy wizard_ meminta kamu untuk menyediakan informasi sebagai berikut: -- **App name** (wajib): Nama dari aplikasi kamu. Sebuah [label](/docs/concepts/overview/working-with-objects/labels/) dengan nama tersebut akan ditambahkan ke Deployment dan Service, jika ada, akan di-_deploy_. +- **App name** (wajib): Nama dari aplikasi kamu. Sebuah [label](/id/docs/concepts/overview/working-with-objects/labels/) dengan nama tersebut akan ditambahkan ke Deployment dan Service, jika ada, akan di-_deploy_. Nama aplikasi harus unik di dalam [Namespace](/docs/tasks/administer-cluster/namespaces/) Kubernetes yang kamu pilih. Nama tersebut harus dimulai dengan huruf kecil, dan diakhiri dengan huruf kecil atau angka, dan hanya berisi huruf kecil, angka dan tanda hubung (-). Nama tersebut juga dibatasi hanya 24 karakter. Spasi di depan dan belakang nama tersebut diabaikan. -- **Container image** (wajib): Tautan publik dari sebuah [_image_](/docs/concepts/containers/images/) kontainer Docker pada _registry_ apapun, atau sebuah _image_ privat (biasanya di-_hosting_ di Google Container Registry atau Docker Hub). Spesifikasi _image_ kontainer tersebut harus diakhiri dengan titik dua. +- **Container image** (wajib): Tautan publik dari sebuah [_image_](/id/docs/concepts/containers/images/) kontainer Docker pada _registry_ apapun, atau sebuah _image_ privat (biasanya di-_hosting_ di Google Container Registry atau Docker Hub). Spesifikasi _image_ kontainer tersebut harus diakhiri dengan titik dua. - **Number of pods** (wajib): Berapa banyak Pod yang kamu inginkan untuk men-_deploy_ aplikasimu. Nilainya haruslah sebuah bilangan bulat positif. - Sebuah [Deployment](/docs/concepts/workloads/controllers/deployment/) akan terbuat untuk mempertahankan jumlah Pod di klaster kamu. + Sebuah [Deployment](/id/docs/concepts/workloads/controllers/deployment/) akan terbuat untuk mempertahankan jumlah Pod di klaster kamu. -- **Service** (opsional): Untuk beberapa aplikasi (misalnya aplikasi _frontend_) kamu mungkin akan mengekspos sebuah [Service](/docs/concepts/services-networking/service/) ke alamat IP publik yang mungkin berada diluar klaster kamu(Service eksternal). Untuk Service eksternal, kamu mungkin perlu membuka lebih dari satu porta jaringan untuk mengeksposnya. Lihat lebih lanjut [di sini](/docs/tasks/access-application-cluster/configure-cloud-provider-firewall/). +- **Service** (opsional): Untuk beberapa aplikasi (misalnya aplikasi _frontend_) kamu mungkin akan mengekspos sebuah [Service](/id/docs/concepts/services-networking/service/) ke alamat IP publik yang mungkin berada diluar klaster kamu(Service eksternal). Untuk Service eksternal, kamu mungkin perlu membuka lebih dari satu porta jaringan untuk mengeksposnya. Lihat lebih lanjut [di sini](/docs/tasks/access-application-cluster/configure-cloud-provider-firewall/). Service lainnya yang hanya dapat diakses dari dalam klaster disebut Service internal. @@ -87,9 +87,9 @@ _Deploy wizard_ meminta kamu untuk menyediakan informasi sebagai berikut: Jika membutuhkan, kamu dapat membuka bagian **Advanced options** di mana kamu dapat menyetel lebih banyak pengaturan: -- **Description**: Tels yang kamu masukkan ke sini akan ditambahkan sebagai sebuah [anotasi](/docs/concepts/overview/working-with-objects/annotations/) ke Deployment dan akan ditampilkan di detail aplikasi. +- **Description**: Tels yang kamu masukkan ke sini akan ditambahkan sebagai sebuah [anotasi](/id/docs/concepts/overview/working-with-objects/annotations/) ke Deployment dan akan ditampilkan di detail aplikasi. -- **Labels**: [Label-label](/docs/concepts/overview/working-with-objects/labels/) bawaan yang akan digunakan untuk aplikasi kamu adalah `name` dan `version` aplikasi. Kamu dapat menentukan label lain untuk diterapkan ke Deployment, Service (jika ada), dan Pod, seperti `release`, `environment`, `tier`, `partition`, dan `track` rilis. +- **Labels**: [Label-label](/id/docs/concepts/overview/working-with-objects/labels/) bawaan yang akan digunakan untuk aplikasi kamu adalah `name` dan `version` aplikasi. Kamu dapat menentukan label lain untuk diterapkan ke Deployment, Service (jika ada), dan Pod, seperti `release`, `environment`, `tier`, `partition`, dan `track` rilis. Contoh: @@ -107,9 +107,9 @@ track=stable Jika pembuatan Namespace berhasil, Namespace tersebut akan dipilih secara bawaan. Jika pembuatannya gagal, maka Namespace yang pertama akan terpilih. -- **_Image Pull Secret_**: Jika kamu menggunakan _image_ kontainer Docker yang privat, mungkin diperlukan kredensial [_pull secret_](/docs/concepts/configuration/secret/). +- **_Image Pull Secret_**: Jika kamu menggunakan _image_ kontainer Docker yang privat, mungkin diperlukan kredensial [_pull secret_](/id/docs/concepts/configuration/secret/). - Dashboard menampilkan semua _secret_ yang tersedia dengan daftar _dropdown_, dan mengizinkan kamu untuk membuat _secret_ baru. Nama _secret_ tersebut harus mengikuti aturan Nama DNS, misalnya `new.image-pull.secret`. Isi dari sebuah _secret_ harus dienkode dalam bentuk _base64_ dan ditentukan dalam sebuah berkas [`.dockercfg`](/docs/concepts/containers/images/#specifying-imagepullsecrets-on-a-pod). Nama kredensial dapat berisi maksimal 253 karakter. + Dashboard menampilkan semua _secret_ yang tersedia dengan daftar _dropdown_, dan mengizinkan kamu untuk membuat _secret_ baru. Nama _secret_ tersebut harus mengikuti aturan Nama DNS, misalnya `new.image-pull.secret`. Isi dari sebuah _secret_ harus dienkode dalam bentuk _base64_ dan ditentukan dalam sebuah berkas [`.dockercfg`](/id/docs/concepts/containers/images/#specifying-imagepullsecrets-on-a-pod). Nama kredensial dapat berisi maksimal 253 karakter. Jika pembuatan _image pull secret_ berhasil, _image pull secret_ tersebut akan terpilih secara bawaan. Jika gagal, maka tidak ada _secret_ yang dipilih. @@ -123,7 +123,7 @@ track=stable ### Menggungah berkas YAML atau JSON -Kubernetes mendukung pengaturan deklaratif. Dengan cara ini, semua pengaturan disimpan dalam bentuk berkas YAML atau JSON menggunakan skema sumber daya [[API](/docs/concepts/overview/kubernetes-api/). +Kubernetes mendukung pengaturan deklaratif. Dengan cara ini, semua pengaturan disimpan dalam bentuk berkas YAML atau JSON menggunakan skema sumber daya [[API](/id/docs/concepts/overview/kubernetes-api/). Sebagai alternatif untuk menentukan detail aplikasi di _deploy wizard_, kamu dapat menentukan sendiri detail aplikasi kamu dalam berkas YAML atau JSON, dan mengunggah berkas tersebut menggunakan Dashboard. diff --git a/content/id/docs/tasks/administer-cluster/configure-upgrade-etcd.md b/content/id/docs/tasks/administer-cluster/configure-upgrade-etcd.md new file mode 100644 index 0000000000..f0a9d789b2 --- /dev/null +++ b/content/id/docs/tasks/administer-cluster/configure-upgrade-etcd.md @@ -0,0 +1,234 @@ +--- +title: Mengoperasikan klaster etcd untuk Kubernetes +content_type: task +--- + +<!-- overview --> + +{{< glossary_definition term_id="etcd" length="all" prepend="etcd adalah ">}} + + + + +## {{% heading "prerequisites" %}} + + +{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}} + + + +<!-- steps --> + +## Prerequisites + +* Jalankan etcd sebagai klaster dimana anggotanya berjumlah ganjil. + +* Etcd adalah sistem terdistribusi berbasis _leader_. Pastikan _leader_ secara berkala mengirimkan _heartbeat_ dengan tepat waktu ke semua pengikutnya untuk menjaga kestabilan klaster. + +* Pastikan tidak terjadi kekurangan sumber daya. + + Kinerja dan stabilitas dari klaster sensitif terhadap jaringan dan _IO disk_. Kekurangan sumber daya apa pun dapat menyebabkan _timeout_ dari _heartbeat_, yang menyebabkan ketidakstabilan klaster. Etcd yang tidak stabil mengindikasikan bahwa tidak ada _leader_ yang terpilih. Dalam keadaan seperti itu, sebuah klaster tidak dapat membuat perubahan apa pun ke kondisi saat ini, yang menyebabkan tidak ada Pod baru yang dapat dijadwalkan. + +* Menjaga kestabilan klaster etcd sangat penting untuk stabilitas klaster Kubernetes. Karenanya, jalankan klaster etcd pada mesin khusus atau lingkungan terisolasi untuk [persyaratan sumber daya terjamin](https://github.com/coreos/etcd/blob/master/Documentation/op-guide/hardware.md#hardware-recommendations). + +* Versi minimum yang disarankan untuk etcd yang dijalankan dalam lingkungan produksi adalah `3.2.10+`. + +## Persyaratan sumber daya + +Mengoperasikan etcd dengan sumber daya terbatas hanya cocok untuk tujuan pengujian. Untuk peluncuran dalam lingkungan produksi, diperlukan konfigurasi perangkat keras lanjutan. Sebelum meluncurkan etcd dalam produksi, lihat [dokumentasi referensi persyaratan sumber daya](https://github.com/coreos/etcd/blob/master/Documentation/op-guide/hardware.md#example-hardware-configurations). + +## Memulai Klaster etcd + +Bagian ini mencakup bagaimana memulai klaster etcd dalam Node tunggal dan Node multipel. + +### Klaster etcd dalam Node tunggal + +Gunakan Klaster etcd Node tunggal hanya untuk tujuan pengujian + +1. Jalankan perintah berikut ini: + + ```sh + ./etcd --listen-client-urls=http://$PRIVATE_IP:2379 --advertise-client-urls=http://$PRIVATE_IP:2379 + ``` + +2. Start server API Kubernetes dengan _flag_ `--etcd-servers=$PRIVATE_IP:2379`. + + Ganti `PRIVATE_IP` dengan IP klien etcd kamu. + +### Klaster etcd dengan Node multipel + +Untuk daya tahan dan ketersediaan tinggi, jalankan etcd sebagai klaster dengan Node multipel dalam lingkungan produksi dan cadangkan secara berkala. Sebuah klaster dengan lima anggota direkomendasikan dalam lingkungan produksi. Untuk informasi lebih lanjut, lihat [Dokumentasi FAQ](https://github.com/coreos/etcd/blob/master/Documentation/faq.md#what-is-failure-tolerance). + +Mengkonfigurasi klaster etcd baik dengan informasi anggota statis atau dengan penemuan dinamis. Untuk informasi lebih lanjut tentang pengklasteran, lihat [Dokumentasi pengklasteran etcd](https://github.com/coreos/etcd/blob/master/Documentation/op-guide/clustering.md). + +Sebagai contoh, tinjau sebuah klaster etcd dengan lima anggota yang berjalan dengan URL klien berikut: `http://$IP1:2379`, `http://$IP2:2379`, `http://$IP3:2379`, `http://$IP4:2379`, dan `http://$IP5:2379`. Untuk memulai server API Kubernetes: + +1. Jalankan perintah berikut ini: + + ```sh + ./etcd --listen-client-urls=http://$IP1:2379, http://$IP2:2379, http://$IP3:2379, http://$IP4:2379, http://$IP5:2379 --advertise-client-urls=http://$IP1:2379, http://$IP2:2379, http://$IP3:2379, http://$IP4:2379, http://$IP5:2379 + ``` + +2. Start server Kubernetes API dengan flag `--etcd-servers=$IP1:2379, $IP2:2379, $IP3:2379, $IP4:2379, $IP5:2379`. + + Ganti `IP` dengan alamat IP klien kamu. + +### Klaster etcd dengan Node multipel dengan load balancer + +Untuk menjalankan penyeimbangan beban (_load balancing_) untuk klaster etcd: + +1. Siapkan sebuah klaster etcd. +2. Konfigurasikan sebuah _load balancer_ di depan klaster etcd. + Sebagai contoh, anggap saja alamat _load balancer_ adalah `$LB`. +3. Mulai Server API Kubernetes dengan _flag_ `--etcd-servers=$LB:2379`. + +## Mengamankan klaster etcd + +Akses ke etcd setara dengan izin root pada klaster sehingga idealnya hanya server API yang memiliki akses ke etcd. Dengan pertimbangan sensitivitas data, disarankan untuk memberikan izin hanya kepada Node-Node yang membutuhkan akses ke klaster etcd. + +Untuk mengamankan etcd, tetapkan aturan _firewall_ atau gunakan fitur keamanan yang disediakan oleh etcd. Fitur keamanan etcd tergantung pada Infrastruktur Kunci Publik / _Public Key Infrastructure_ (PKI) x509. Untuk memulai, buat saluran komunikasi yang aman dengan menghasilkan pasangan kunci dan sertifikat. Sebagai contoh, gunakan pasangan kunci `peer.key` dan `peer.cert` untuk mengamankan komunikasi antara anggota etcd, dan `client.key` dan `client.cert` untuk mengamankan komunikasi antara etcd dan kliennya. Lihat [contoh skrip](https://github.com/coreos/etcd/tree/master/hack/tls-setup) yang disediakan oleh proyek etcd untuk menghasilkan pasangan kunci dan berkas CA untuk otentikasi klien. + +### Mengamankan komunikasi + +Untuk mengonfigurasi etcd dengan _secure peer communication_, tentukan _flag_ `--peer-key-file=peer.key` dan `--peer-cert-file=peer.cert`, dan gunakan https sebagai skema URL. + +Demikian pula, untuk mengonfigurasi etcd dengan _secure client communication_, tentukan _flag_ `--key-file=k8sclient.key` dan `--cert-file=k8sclient.cert`, dan gunakan https sebagai skema URL. + +### Membatasi akses klaster etcd + +Setelah konfigurasi komunikasi aman, batasi akses klaster etcd hanya ke server API Kubernetes. Gunakan otentikasi TLS untuk melakukannya. + +Sebagai contoh, anggap pasangan kunci `k8sclient.key` dan `k8sclient.cert` dipercaya oleh CA `etcd.ca`. Ketika etcd dikonfigurasi dengan `--client-cert-auth` bersama dengan TLS, etcd memverifikasi sertifikat dari klien dengan menggunakan CA dari sistem atau CA yang dilewati oleh _flag_ `--trusted-ca-file`. Menentukan _flag_ `--client-cert-auth=true` dan `--trusted-ca-file=etcd.ca` akan membatasi akses kepada klien yang mempunyai sertifikat `k8sclient.cert`. + +Setelah etcd dikonfigurasi dengan benar, hanya klien dengan sertifikat yang valid dapat mengaksesnya. Untuk memberikan akses kepada server Kubernetes API, konfigurasikan dengan _flag_ `--etcd-certfile=k8sclient.cert`,`--etcd-keyfile=k8sclient.key` dan `--etcd-cafile=ca.cert`. + +{{< note >}} +Otentikasi etcd saat ini tidak didukung oleh Kubernetes. Untuk informasi lebih lanjut, lihat masalah terkait [Mendukung Auth Dasar untuk Etcd v2](https://github.com/kubernetes/kubernetes/issues/23398). +{{< /note >}} + +## Mengganti anggota etcd yang gagal + +Etcd klaster mencapai ketersediaan tinggi dengan mentolerir kegagalan dari sebagian kecil anggota. Namun, untuk meningkatkan kesehatan keseluruhan dari klaster, segera ganti anggota yang gagal. Ketika banyak anggota yang gagal, gantilah satu per satu. Mengganti anggota yang gagal melibatkan dua langkah: menghapus anggota yang gagal dan menambahkan anggota baru. + +Meskipun etcd menyimpan ID anggota unik secara internal, disarankan untuk menggunakan nama unik untuk setiap anggota untuk menghindari kesalahan manusia. Sebagai contoh, sebuah klaster etcd dengan tiga anggota. Jadikan URL-nya, member1=http://10.0.0.1, member2=http://10.0.0.2, and member3=http://10.0.0.3. Ketika member1 gagal, ganti dengan member4=http://10.0.0.4. + +1. Dapatkan ID anggota yang gagal dari member1: + + `etcdctl --endpoints=http://10.0.0.2,http://10.0.0.3 member list` + + Akan tampil pesan berikut: + + 8211f1d0f64f3269, started, member1, http://10.0.0.1:2380, http://10.0.0.1:2379 + 91bc3c398fb3c146, started, member2, http://10.0.0.2:2380, http://10.0.0.2:2379 + fd422379fda50e48, started, member3, http://10.0.0.3:2380, http://10.0.0.3:2379 + +2. Hapus anggota yang gagal: + + `etcdctl member remove 8211f1d0f64f3269` + + Akan tampil pesan berikut: + + Removed member 8211f1d0f64f3269 from cluster + +3. Tambahkan anggota baru: + + `./etcdctl member add member4 --peer-urls=http://10.0.0.4:2380` + + Akan tampil pesan berikut: + + Member 2be1eb8f84b7f63e added to cluster ef37ad9dc622a7c4 + +4. Jalankan anggota yang baru ditambahkan pada mesin dengan IP `10.0.0.4`: + + export ETCD_NAME="member4" + export ETCD_INITIAL_CLUSTER="member2=http://10.0.0.2:2380,member3=http://10.0.0.3:2380,member4=http://10.0.0.4:2380" + export ETCD_INITIAL_CLUSTER_STATE=existing + etcd [flags] + +5. Lakukan salah satu dari yang berikut: + + 1. Perbarui _flag_ `--etcd-server` untuk membuat Kubernetes mengetahui perubahan konfigurasi, lalu start ulang server API Kubernetes. + 2. Perbarui konfigurasi _load balancer_ jika _load balancer_ digunakan dalam Deployment. + +Untuk informasi lebih lanjut tentang konfigurasi ulang klaster, lihat [Dokumentasi Konfigurasi etcd](https://github.com/coreos/etcd/blob/master/Documentation/op-guide/runtime-configuration.md#remove-a-member). + +## Mencadangkan klaster etcd + +Semua objek Kubernetes disimpan dalam etcd. Mencadangkan secara berkala data klaster etcd penting untuk memulihkan klaster Kubernetes di bawah skenario bencana, seperti kehilangan semua Node _control plane_. Berkas _snapshot_ berisi semua status Kubernetes dan informasi penting. Untuk menjaga data Kubernetes yang sensitif aman, enkripsi berkas _snapshot_. + +Mencadangkan klaster etcd dapat dilakukan dengan dua cara: _snapshot_ etcd bawaan dan _snapshot_ volume. + +### Snapshot bawaan + +Fitur _snapshot_ didukung oleh etcd secara bawaan, jadi mencadangkan klaster etcd lebih mudah. _Snapshot_ dapat diambil dari anggota langsung dengan command `etcdctl snapshot save` atau dengan menyalin `member/snap/db` berkas dari etcd [direktori data](https://github.com/coreos/etcd/blob/master/Documentation/op-guide/configuration.md#--data-dir) yang saat ini tidak digunakan oleh proses etcd. Mengambil _snapshot_ biasanya tidak akan mempengaruhi kinerja anggota. + +Di bawah ini adalah contoh untuk mengambil _snapshot_ dari _keyspace_ yang dilayani oleh `$ENDPOINT` ke berkas `snapshotdb`: + +```sh +ETCDCTL_API=3 etcdctl --endpoints $ENDPOINT snapshot save snapshotdb +# keluar 0 + +# memverifikasi hasil snapshot +ETCDCTL_API=3 etcdctl --write-out=table snapshot status snapshotdb ++----------+----------+------------+------------+ +| HASH | REVISION | TOTAL KEYS | TOTAL SIZE | ++----------+----------+------------+------------+ +| fe01cf57 | 10 | 7 | 2.1 MB | ++----------+----------+------------+------------+ +``` + +### Snapshot volume + +Jika etcd berjalan pada volume penyimpanan yang mendukung cadangan, seperti Amazon Elastic Block Store, buat cadangan data etcd dengan mengambil _snapshot_ dari volume penyimpanan. + +## Memperbesar skala dari klaster etcd + +Peningkatan skala klaster etcd meningkatkan ketersediaan dengan menukarnya untuk kinerja. Penyekalaan tidak akan meningkatkan kinerja atau kemampuan klaster. Aturan umum adalah untuk tidak melakukan penyekalaan naik atau turun untuk klaster etcd. Jangan mengonfigurasi grup penyekalaan otomatis untuk klaster etcd. Sangat disarankan untuk selalu menjalankan klaster etcd statis dengan lima anggota untuk klaster produksi Kubernetes untuk setiap skala yang didukung secara resmi. + +Penyekalaan yang wajar adalah untuk meningkatkan klaster dengan tiga anggota menjadi dengan lima anggota, ketika dibutuhkan lebih banyak keandalan. Lihat [Dokumentasi Rekonfigurasi etcd](https://github.com/coreos/etcd/blob/master/Documentation/op-guide/runtime-configuration.md#remove-a-member) untuk informasi tentang cara menambahkan anggota ke klaster yang ada. + +## Memulihkan klaster etcd + +Etcd mendukung pemulihan dari _snapshot_ yang diambil dari proses etcd dari versi [major.minor](http://semver.org/). Memulihkan versi dari versi patch lain dari etcd juga didukung. Operasi pemulihan digunakan untuk memulihkan data klaster yang gagal. + +Sebelum memulai operasi pemulihan, berkas _snapshot_ harus ada. Ini bisa berupa berkas _snapshot_ dari operasi pencadangan sebelumnya, atau dari sisa [direktori data](https://github.com/coreos/etcd/blob/master/Documentation/op-guide/configuration.md#--data-dir). Untuk informasi dan contoh lebih lanjut tentang memulihkan klaster dari berkas _snapshot_, lihat [dokumentasi pemulihan bencana etcd](https://github.com/coreos/etcd/blob/master/Documentation/op-guide/recovery.md#restoring-a-cluster). + +Jika akses URL dari klaster yang dipulihkan berubah dari klaster sebelumnya, maka server API Kubernetes harus dikonfigurasi ulang sesuai dengan URL tersebut. Pada kasus ini, start kembali server API Kubernetes dengan _flag_ `--etcd-servers=$NEW_ETCD_CLUSTER` bukan _flag_ `--etcd-servers=$OLD_ETCD_CLUSTER`. Ganti `$NEW_ETCD_CLUSTER` dan `$OLD_ETCD_CLUSTER` dengan alamat IP masing-masing. Jika _load balancer_ digunakan di depan klaster etcd, kamu mungkin hanya perlu memperbarui _load balancer_ sebagai gantinya. + +Jika mayoritas anggota etcd telah gagal secara permanen, klaster etcd dianggap gagal. Dalam skenario ini, Kubernetes tidak dapat membuat perubahan apa pun ke kondisi saat ini. Meskipun Pod terjadwal mungkin terus berjalan, tidak ada Pod baru yang bisa dijadwalkan. Dalam kasus seperti itu, pulihkan klaster etcd dan kemungkinan juga untuk mengonfigurasi ulang server API Kubernetes untuk memperbaiki masalah ini. + +## Memutakhirkan dan memutar balikan klaster etcd + +Pada Kubernetes v1.13.0, etcd2 tidak lagi didukung sebagai _backend_ penyimpanan untuk klaster Kubernetes baru atau yang sudah ada. _Timeline_ untuk dukungan Kubernetes untuk etcd2 dan etcd3 adalah sebagai berikut: + +- Kubernetes v1.0: hanya etcd2 +- Kubernetes v1.5.1: dukungan etcd3 ditambahkan, standar klaster baru yang dibuat masih ke etcd2 +- Kubernetes v1.6.0: standar klaster baru yang dibuat dengan `kube-up.sh` adalah etcd3, + dan `kube-apiserver` standarnya ke etcd3 +- Kubernetes v1.9.0: pengumuman penghentian _backend_ penyimpanan etcd2 diumumkan +- Kubernetes v1.13.0: _backend_ penyimpanan etcd2 dihapus, `kube-apiserver` akan + menolak untuk start dengan `--storage-backend=etcd2`, dengan pesan + `etcd2 is no longer a supported storage backend` + +Sebelum memutakhirkan v1.12.x kube-apiserver menggunakan `--storage-backend=etcd2` ke +v1.13.x, data etcd v2 harus dimigrasikan ke _backend_ penyimpanan v3 dan +permintaan kube-apiserver harus diubah untuk menggunakan `--storage-backend=etcd3`. + +Proses untuk bermigrasi dari etcd2 ke etcd3 sangat tergantung pada bagaimana +klaster etcd diluncurkan dan dikonfigurasi, serta bagaimana klaster Kubernetes diluncurkan dan dikonfigurasi. Kami menyarankan kamu berkonsultasi dengan dokumentasi penyedia kluster kamu untuk melihat apakah ada solusi yang telah ditentukan. + +Jika klaster kamu dibuat melalui `kube-up.sh` dan masih menggunakan etcd2 sebagai penyimpanan _backend_, silakan baca [Kubernetes v1.12 etcd cluster upgrade docs](https://v1-12.docs.kubernetes.io/docs/tasks/administer-cluster/configure-upgrade-etcd/#upgrading-and-rolling-back-etcd-clusters) + +## Masalah umum: penyeimbang klien etcd dengan _secure endpoint_ + +Klien etcd v3, dirilis pada etcd v3.3.13 atau sebelumnya, memiliki [_critical bug_](https://github.com/kubernetes/kubernetes/issues/72102) yang mempengaruhi kube-apiserver dan penyebaran HA. Pemindahan kegagalan (_failover_) penyeimbang klien etcd tidak bekerja dengan baik dengan _secure endpoint_. Sebagai hasilnya, server etcd boleh gagal atau terputus sesaat dari kube-apiserver. Hal ini mempengaruhi peluncuran HA dari kube-apiserver. + +Perbaikan dibuat di [etcd v3.4](https://github.com/etcd-io/etcd/pull/10911) (dan di-backport ke v3.3.14 atau yang lebih baru): klien baru sekarang membuat bundel kredensial sendiri untuk menetapkan target otoritas dengan benar dalam fungsi dial. + +Karena perbaikan tersebut memerlukan pemutakhiran dependensi dari gRPC (ke v1.23.0), _downstream_ Kubernetes [tidak mendukung upgrade etcd](https://github.com/kubernetes/kubernetes/issues/72102#issuecomment-526645978), yang berarti [perbaikan etcd di kube-apiserver](https://github.com/etcd-io/etcd/pull/10911/commits/db61ee106ca9363ba3f188ecf27d1a8843da33ab) hanya tersedia mulai Kubernetes 1.16. + +Untuk segera memperbaiki celah keamanan (_bug_) ini untuk Kubernetes 1.15 atau sebelumnya, buat kube-apiserver khusus. kamu dapat membuat perubahan lokal ke [`vendor/google.golang.org/grpc/credentials/credentials.go`](https://github.com/kubernetes/kubernetes/blob/7b85be021cd2943167cd3d6b7020f44735d9d90b/vendor/google.golang.org/grpc/credentials/credentials.go#L135) dengan [etcd@db61ee106](https://github.com/etcd-io/etcd/pull/10911/commits/db61ee106ca9363ba3f188ecf27d1a8843da33ab). + +Lihat ["kube-apiserver 1.13.x menolak untuk bekerja ketika server etcd pertama tidak tersedia"](https://github.com/kubernetes/kubernetes/issues/72102). + + diff --git a/content/id/docs/tasks/administer-cluster/dns-custom-nameservers.md b/content/id/docs/tasks/administer-cluster/dns-custom-nameservers.md new file mode 100644 index 0000000000..7028405b82 --- /dev/null +++ b/content/id/docs/tasks/administer-cluster/dns-custom-nameservers.md @@ -0,0 +1,262 @@ +--- +title: Kustomisasi Service DNS +content_type: task +min-kubernetes-server-version: v1.12 +--- + +<!-- overview --> +Laman ini menjelaskan cara mengonfigurasi DNS +{{< glossary_tooltip text="Pod" term_id="pod" >}} kamu dan menyesuaikan +proses resolusi DNS pada klaster kamu. + +## {{% heading "prerequisites" %}} + +{{< include "task-tutorial-prereqs.md" >}} + +Klaster kamu harus menjalankan tambahan (_add-on_) CoreDNS terlebih dahulu. +[Migrasi ke CoreDNS](/docs/tasks/administer-cluster/coredns/#migrasi-ke-coredns) +menjelaskan tentang bagaimana menggunakan `kubeadm` untuk melakukan migrasi dari `kube-dns`. + +{{% version-check %}} + +<!-- steps --> + +## Pengenalan + +DNS adalah Service bawaan dalam Kubernetes yang diluncurkan secara otomatis +melalui _addon manager_ +[add-on klaster](http://releases.k8s.io/{{< param "githubbranch" >}}/cluster/addons/README.md). + +Sejak Kubernetes v1.12, CoreDNS adalah server DNS yang direkomendasikan untuk menggantikan kube-dns. Jika klaster kamu +sebelumnya menggunakan kube-dns, maka kamu mungkin masih menggunakan `kube-dns` daripada CoreDNS. + +{{< note >}} +Baik Service CoreDNS dan kube-dns diberi nama `kube-dns` pada _field_ `metadata.name`. +Hal ini agar ada interoperabilitas yang lebih besar dengan beban kerja yang bergantung pada nama Service `kube-dns` lama untuk me-_resolve_ alamat internal ke dalam klaster. Dengan menggunakan sebuah Service yang bernama `kube-dns` mengabstraksi detail implementasi yang dijalankan oleh penyedia DNS di belakang nama umum tersebut. +{{< /note >}} + +Jika kamu menjalankan CoreDNS sebagai sebuah Deployment, maka biasanya akan ditampilkan sebagai sebuah Service Kubernetes dengan alamat IP yang statis. +Kubelet meneruskan informasi DNS _resolver_ ke setiap Container dengan argumen `--cluster-dns=<dns-service-ip>`. + +Nama DNS juga membutuhkan domain. Kamu dapat mengonfigurasi domain lokal di kubelet +dengan argumen `--cluster-domain=<default-local-domain>`. + +Server DNS mendukung _forward lookup_ (_record_ A dan AAAA), _port lookup_ (_record_ SRV), _reverse lookup_ alamat IP (_record_ PTR), +dan lain sebagainya. Untuk informasi lebih lanjut, lihatlah [DNS untuk Service dan Pod](/id/docs/concepts/services-networking/dns-pod-service/). + +Jika `dnsPolicy` dari Pod diatur menjadi `default`, itu berarti mewarisi konfigurasi resolusi nama +dari Node yang dijalankan Pod. Resolusi DNS pada Pod +harus berperilaku sama dengan Node tersebut. +Tapi lihat [Isu-isu yang telah diketahui](/docs/tasks/debug-application-cluster/dns-debugging-resolution/#known-issues). + +Jika kamu tidak menginginkan hal ini, atau jika kamu menginginkan konfigurasi DNS untuk Pod berbeda, kamu bisa +menggunakan argumen `--resolv-conf` pada kubelet. Atur argumen ini menjadi "" untuk mencegah Pod tidak +mewarisi konfigurasi DNS. Atur ke jalur (_path_) berkas yang tepat untuk berkas yang berbeda dengan +`/etc/resolv.conf` untuk menghindari mewarisi konfigurasi DNS. + +## CoreDNS + +CoreDNS adalah server DNS otoritatif untuk kegunaan secara umum yang dapat berfungsi sebagai Service DNS untuk klaster, yang sesuai dengan [spesifikasi dns](https://github.com/kubernetes/dns/blob/master/docs/specification.md). + +### Opsi ConfigMap pada CoreDNS + +CoreDNS adalah server DNS yang modular dan mudah dipasang, dan setiap _plugin_ dapat menambahkan fungsionalitas baru ke CoreDNS. +Fitur ini dapat dikonfigurasikan dengan menjaga berkas [Corefile](https://coredns.io/2017/07/23/corefile-explained/), yang merupakan +berkas konfigurasi dari CoreDNS. Sebagai administrator klaster, kamu dapat memodifikasi +{{< glossary_tooltip text="ConfigMap" term_id="configmap" >}} untuk Corefile dari CoreDNS dengan mengubah cara perilaku pencarian Service DNS +pada klaster tersebut. + +Di Kubernetes, CoreDNS diinstal dengan menggunakan konfigurasi Corefile bawaan sebagai berikut: + +```yaml +apiVersion: v1 +kind: ConfigMap +metadata: + name: coredns + namespace: kube-system +data: + Corefile: | + .:53 { + errors + health { + lameduck 5s + } + ready + kubernetes cluster.local in-addr.arpa ip6.arpa { + pods insecure + fallthrough in-addr.arpa ip6.arpa + ttl 30 + } + prometheus :9153 + forward . /etc/resolv.conf + cache 30 + loop + reload + loadbalance + } +``` + +Konfigurasi Corefile meliputi [_plugin_](https://coredns.io/plugins/) berikut ini dari CoreDNS: + +* [errors](https://coredns.io/plugins/errors/): Kesalahan yang ditampilkan ke output standar (_stdout_) +* [health](https://coredns.io/plugins/health/): Kesehatan dari CoreDNS dilaporkan pada `http://localhost:8080/health`. Dalam sintaks yang diperluas `lameduck` akan menangani proses tidak sehat agar menunggu selama 5 detik sebelum proses tersebut dimatikan. +* [ready](https://coredns.io/plugins/ready/): _Endpoint_ HTTP pada port 8181 akan mengembalikan OK 200, ketika semua _plugin_ yang dapat memberi sinyal kesiapan, telah memberikan sinyalnya. +* [kubernetes](https://coredns.io/plugins/kubernetes/): CoreDNS akan menjawab pertanyaan (_query_) DNS berdasarkan IP Service dan Pod pada Kubernetes. Kamu dapat menemukan [lebih detail](https://coredns.io/plugins/kubernetes/) tentang _plugin_ itu dalam situs web CoreDNS. `ttl` memungkinkan kamu untuk mengatur TTL khusus untuk respon dari pertanyaan DNS. Standarnya adalah 5 detik. TTL minimum yang diizinkan adalah 0 detik, dan maksimum hanya dibatasi sampai 3600 detik. Mengatur TTL ke 0 akan mencegah _record_ untuk di simpan sementara dalam _cache_. + Opsi `pods insecure` disediakan untuk kompatibilitas dengan Service _kube-dns_ sebelumnya. Kamu dapat menggunakan opsi `pods verified`, yang mengembalikan _record_ A hanya jika ada Pod pada Namespace yang sama untuk alamat IP yang sesuai. Opsi `pods disabled` dapat digunakan jika kamu tidak menggunakan _record_ Pod. +* [prometheus](https://coredns.io/plugins/metrics/): Metrik dari CoreDNS tersedia pada `http://localhost:9153/metrics` dalam format yang sesuai dengan [Prometheus](https://prometheus.io/) (dikenal juga sebagai OpenMetrics). +* [forward](https://coredns.io/plugins/forward/): Setiap pertanyaan yang tidak berada dalam domain klaster Kubernetes akan diteruskan ke _resolver_ yang telah ditentukan dalam berkas (/etc/resolv.conf). +* [cache](https://coredns.io/plugins/cache/): Ini untuk mengaktifkan _frontend cache_. +* [loop](https://coredns.io/plugins/loop/): Mendeteksi _forwarding loop_ sederhana dan menghentikan proses CoreDNS jika _loop_ ditemukan. +* [reload](https://coredns.io/plugins/reload): Mengizinkan _reload_ otomatis Corefile yang telah diubah. Setelah kamu mengubah konfigurasi ConfigMap, beri waktu sekitar dua menit agar perubahan yang kamu lakukan berlaku. +* [loadbalance](https://coredns.io/plugins/loadbalance): Ini adalah _load balancer_ DNS secara _round-robin_ yang mengacak urutan _record_ A, AAAA, dan MX dalam setiap responnya. + +Kamu dapat memodifikasi perilaku CoreDNS bawaan dengan memodifikasi ConfigMap. + +### Konfigurasi _Stub-domain_ dan _Nameserver Upstream_ dengan menggunakan CoreDNS + +CoreDNS memiliki kemampuan untuk mengonfigurasi _stubdomain_ dan _nameserver upstream_ dengan menggunakan [_plugin_ forward](https://coredns.io/plugins/forward/). + +#### Contoh + +Jika operator klaster memiliki sebuah server domain [Consul](https://www.consul.io/) yang terletak di 10.150.0.1, dan semua nama Consul memiliki akhiran .consul.local. Untuk mengonfigurasinya di CoreDNS, administrator klaster membuat bait (_stanza_) berikut dalam ConfigMap CoreDNS. + +``` +consul.local:53 { + errors + cache 30 + forward . 10.150.0.1 + } +``` + +Untuk memaksa secara eksplisit semua pencarian DNS _non-cluster_ melalui _nameserver_ khusus pada 172.16.0.1, arahkan `forward` ke _nameserver_ bukan ke `/etc/resolv.conf` + +``` +forward . 172.16.0.1 +``` + +ConfigMap terakhir bersama dengan konfigurasi `Corefile` bawaan terlihat seperti berikut: + +```yaml +apiVersion: v1 +kind: ConfigMap +metadata: + name: coredns + namespace: kube-system +data: + Corefile: | + .:53 { + errors + health + kubernetes cluster.local in-addr.arpa ip6.arpa { + pods insecure + fallthrough in-addr.arpa ip6.arpa + } + prometheus :9153 + forward . 172.16.0.1 + cache 30 + loop + reload + loadbalance + } + consul.local:53 { + errors + cache 30 + forward . 10.150.0.1 + } +``` + +Perangkat `kubeadm` mendukung terjemahan otomatis dari ConfigMap kube-dns +ke ConfigMap CoreDNS yang setara. + +{{< note >}} +Sementara ini kube-dns dapat menerima FQDN untuk _stubdomain_ dan _nameserver_ (mis: ns.foo.com), namun CoreDNS belum mendukung fitur ini. +Selama penerjemahan, semua _nameserver_ FQDN akan dihilangkan dari konfigurasi CoreDNS. +{{< /note >}} + +## Konfigurasi CoreDNS yang setara dengan kube-dns + +CoreDNS mendukung fitur kube-dns dan banyak lagi lainnya. +ConfigMap dibuat agar kube-dns mendukung `StubDomains` dan `upstreamNameservers` untuk diterjemahkan ke _plugin_ `forward` dalam CoreDNS. +Begitu pula dengan _plugin_ `Federations` dalam kube-dns melakukan translasi untuk _plugin_ `federation` dalam CoreDNS. + +### Contoh + +Contoh ConfigMap ini untuk kube-dns menentukan federasi, _stub domain_ dan server _upstream nameserver_: + +```yaml +apiVersion: v1 +data: + federations: | + {"foo" : "foo.feddomain.com"} + stubDomains: | + {"abc.com" : ["1.2.3.4"], "my.cluster.local" : ["2.3.4.5"]} + upstreamNameservers: | + ["8.8.8.8", "8.8.4.4"] +kind: ConfigMap +``` + +Untuk konfigurasi yang setara dengan CoreDNS buat Corefile berikut: + +* Untuk federasi: +``` +federation cluster.local { + foo foo.feddomain.com +} +``` + +* Untuk stubDomain: +```yaml +abc.com:53 { + errors + cache 30 + forward . 1.2.3.4 +} +my.cluster.local:53 { + errors + cache 30 + forward . 2.3.4.5 +} +``` + +Corefile lengkap dengan _plugin_ bawaan: + +``` +.:53 { + errors + health + kubernetes cluster.local in-addr.arpa ip6.arpa { + pods insecure + fallthrough in-addr.arpa ip6.arpa + } + federation cluster.local { + foo foo.feddomain.com + } + prometheus :9153 + forward . 8.8.8.8 8.8.4.4 + cache 30 +} +abc.com:53 { + errors + cache 30 + forward . 1.2.3.4 +} +my.cluster.local:53 { + errors + cache 30 + forward . 2.3.4.5 +} +``` + +## Migrasi ke CoreDNS + +Untuk bermigrasi dari kube-dns ke CoreDNS, +[artikel blog](https://coredns.io/2018/05/21/migration-from-kube-dns-to-coredns/) yang detail +tersedia untuk membantu pengguna mengadaptasi CoreDNS sebagai pengganti dari kube-dns. + +Kamu juga dapat bermigrasi dengan menggunakan +[skrip _deploy_](https://github.com/coredns/deployment/blob/master/kubernetes/deploy.sh) CoreDNS yang resmi. + + +## {{% heading "whatsnext" %}} + +- Baca [_Debugging_ Resolusi DNS](/docs/tasks/administer-cluster/dns-debugging-resolution/) diff --git a/content/id/docs/tasks/administer-cluster/dns-custom-nameservers/dns.png b/content/id/docs/tasks/administer-cluster/dns-custom-nameservers/dns.png new file mode 100644 index 0000000000..b048875f53 Binary files /dev/null and b/content/id/docs/tasks/administer-cluster/dns-custom-nameservers/dns.png differ diff --git a/content/id/docs/tasks/administer-cluster/highly-available-master.md b/content/id/docs/tasks/administer-cluster/highly-available-master.md new file mode 100644 index 0000000000..0b2ebea7fe --- /dev/null +++ b/content/id/docs/tasks/administer-cluster/highly-available-master.md @@ -0,0 +1,177 @@ +--- +title: Mengatur Control Plane Kubernetes dengan Ketersediaan Tinggi (High-Availability) +content_type: task +--- + +<!-- overview --> + +{{< feature-state for_k8s_version="v1.5" state="alpha" >}} + +Kamu dapat mereplikasi _control plane_ Kubernetes dalam skrip `kube-up` atau `kube-down` untuk Google Compute Engine (GCE). +Dokumen ini menjelaskan cara menggunakan skrip kube-up/down untuk mengelola _control plane_ dengan ketersedian tinggi atau _high_availability_ (HA) dan bagaimana _control plane_ HA diimplementasikan untuk digunakan dalam GCE. + + + +## {{% heading "prerequisites" %}} + + +{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}} + + + +<!-- steps --> + +## Memulai klaster yang kompatibel dengan HA + +Untuk membuat klaster yang kompatibel dengan HA, kamu harus mengatur tanda ini pada skrip `kube-up`: + +* `MULTIZONE=true` - untuk mencegah penghapusan replika _control plane_ kubelet dari zona yang berbeda dengan zona bawaan server. +Ini diperlukan jika kamu ingin menjalankan replika _control plane_ pada zona berbeda, dimana hal ini disarankan. + +* `ENABLE_ETCD_QUORUM_READ=true` - untuk memastikan bahwa pembacaan dari semua server API akan mengembalikan data terbaru. +Jika `true`, bacaan akan diarahkan ke replika pemimpin dari etcd. +Menetapkan nilai ini menjadi `true` bersifat opsional: pembacaan akan lebih dapat diandalkan tetapi juga akan menjadi lebih lambat. + +Sebagai pilihan, kamu dapat menentukan zona GCE tempat dimana replika _control plane_ pertama akan dibuat. +Atur tanda berikut: + +* `KUBE_GCE_ZONE=zone` - zona tempat di mana replika _control plane_ pertama akan berjalan. + +Berikut ini contoh perintah untuk mengatur klaster yang kompatibel dengan HA pada zona GCE europe-west1-b: + +```shell +MULTIZONE=true KUBE_GCE_ZONE=europe-west1-b ENABLE_ETCD_QUORUM_READS=true ./cluster/kube-up.sh +``` + +Perhatikan bahwa perintah di atas digunakan untuk membuat klaster dengan sebuah _control plane_; +Namun, kamu bisa menambahkan replika _control plane_ baru ke klaster dengan perintah berikutnya. + + +## Menambahkan replika _control plane_ yang baru + +Setelah kamu membuat klaster yang kompatibel dengan HA, kamu bisa menambahkan replika _control plane_ ke sana. +Kamu bisa menambahkan replika _control plane_ dengan menggunakan skrip `kube-up` dengan tanda berikut ini: + +* `KUBE_REPLICATE_EXISTING_MASTER=true` - untuk membuat replika dari _control plane_ yang sudah ada. + +* `KUBE_GCE_ZONE=zone` - zona di mana replika _control plane_ itu berjalan. +Region ini harus sama dengan region dari zona replika yang lain. + +Kamu tidak perlu mengatur tanda `MULTIZONE` atau `ENABLE_ETCD_QUORUM_READS`, +karena tanda itu diturunkan pada saat kamu memulai klaster yang kompatible dengan HA. + +Berikut ini contoh perintah untuk mereplikasi _control plane_ pada klaster sebelumnya yang kompatibel dengan HA: + +```shell +KUBE_GCE_ZONE=europe-west1-c KUBE_REPLICATE_EXISTING_MASTER=true ./cluster/kube-up.sh +``` + +## Menghapus replika _control plane_ + +Kamu dapat menghapus replika _control plane_ dari klaster HA dengan menggunakan skrip `kube-down` dengan tanda berikut: + +* `KUBE_DELETE_NODES=false` - untuk mencegah penghapusan kubelet. + +* `KUBE_GCE_ZONE=zone` - zona di mana replika _control plane_ akan dihapus. + +* `KUBE_REPLICA_NAME=replica_name` - (opsional) nama replika _control plane_ yang akan dihapus. +Jika kosong: replika mana saja dari zona yang diberikan akan dihapus. + +Berikut ini contoh perintah untuk menghapus replika _control plane_ dari klaster HA yang sudah ada sebelumnya: + +```shell +KUBE_DELETE_NODES=false KUBE_GCE_ZONE=europe-west1-c ./cluster/kube-down.sh +``` + +## Mengatasi replika _control plane_ yang gagal + +Jika salah satu replika _control plane_ di klaster HA kamu gagal, +praktek terbaik adalah menghapus replika dari klaster kamu dan menambahkan replika baru pada zona yang sama. +Berikut ini contoh perintah yang menunjukkan proses tersebut: + +1. Menghapus replika yang gagal: + +```shell +KUBE_DELETE_NODES=false KUBE_GCE_ZONE=replica_zone KUBE_REPLICA_NAME=replica_name ./cluster/kube-down.sh +``` + +2. Menambahkan replika baru untuk menggantikan replika yang lama + +```shell +KUBE_GCE_ZONE=replica-zone KUBE_REPLICATE_EXISTING_MASTER=true ./cluster/kube-up.sh +``` + +## Praktek terbaik untuk mereplikasi _control plane_ untuk klaster HA + +* Usahakan untuk menempatkan replika _control plane_ pada zona yang berbeda. Pada saat terjadi kegagalan zona, semua _control plane_ yang ditempatkan dalam zona tersebut akan gagal pula. +Untuk bertahan dari kegagalan pada sebuah zona, tempatkan juga Node pada beberapa zona yang lain +(Lihatlah [multi-zona](/id/docs/setup/best-practices/multiple-zones/) untuk lebih detail). + +* Jangan gunakan klaster dengan dua replika _control plane_. Konsensus pada klaster dengan dua replika membutuhkan kedua replika tersebut berjalan pada saat mengubah keadaan yang persisten. +Akibatnya, kedua replika tersebut diperlukan dan kegagalan salah satu replika mana pun mengubah klaster dalam status kegagalan mayoritas. +Dengan demikian klaster dengan dua replika lebih buruk, dalam hal HA, daripada klaster dengan replika tunggal. + +* Ketika kamu menambahkan sebuah replika _control plane_, status klaster (etcd) disalin ke sebuah _instance_ baru. +Jika klaster itu besar, mungkin butuh waktu yang lama untuk menduplikasi keadaannya. +Operasi ini dapat dipercepat dengan memigrasi direktori data etcd, seperti yang dijelaskan [di sini](https://coreos.com/etcd/docs/latest/admin_guide.html#member-migration) +(Kami sedang mempertimbangkan untuk menambahkan dukungan untuk migrasi direktori data etcd di masa mendatang). + + + +<!-- discussion --> + +## Catatan implementasi + +![ha-master-gce](/images/docs/ha-master-gce.png) + +### Ikhtisar + +Setiap replika _control plane_ akan menjalankan komponen berikut dalam mode berikut: + +* _instance_ etcd: semua _instance_ akan dikelompokkan bersama menggunakan konsensus; + +* server API : setiap server akan berbicara dengan lokal etcd - semua server API pada cluster akan tersedia; + +* pengontrol (_controller_), penjadwal (_scheduler_), dan _scaler_ klaster automatis: akan menggunakan mekanisme sewa - dimana hanya satu _instance_ dari masing-masing mereka yang akan aktif dalam klaster; + +* manajer tambahan (_add-on_): setiap manajer akan bekerja secara independen untuk mencoba menjaga tambahan dalam sinkronisasi. + +Selain itu, akan ada penyeimbang beban (_load balancer_) di depan server API yang akan mengarahkan lalu lintas eksternal dan internal menuju mereka. + + +### Penyeimbang Beban + +Saat memulai replika _control plane_ kedua, penyeimbang beban yang berisi dua replika akan dibuat +dan alamat IP dari replika pertama akan dipromosikan ke alamat IP penyeimbang beban. +Demikian pula, setelah penghapusan replika _control plane_ kedua yang dimulai dari paling akhir, penyeimbang beban akan dihapus dan alamat IP-nya akan diberikan ke replika terakhir yang ada. +Mohon perhatikan bahwa pembuatan dan penghapusan penyeimbang beban adalah operasi yang rumit dan mungkin perlu beberapa waktu (~20 menit) untuk dipropagasikan. + + +### Service _control plane_ & kubelet + +Daripada sistem mencoba untuk menjaga daftar terbaru dari apiserver Kubernetes yang ada dalam Service Kubernetes, +sistem akan mengarahkan semua lalu lintas ke IP eksternal: + +* dalam klaster dengan satu _control plane_, IP diarahkan ke _control plane_ tunggal. + +* dalam klaster dengan multiple _control plane_, IP diarahkan ke penyeimbang beban yang ada di depan _control plane_. + +Demikian pula, IP eksternal akan digunakan oleh kubelet untuk berkomunikasi dengan _control plane_. + + +### Sertifikat _control plane_ + +Kubernetes menghasilkan sertifikat TLS _control plane_ untuk IP publik eksternal dan IP lokal untuk setiap replika. +Tidak ada sertifikat untuk IP publik sementara (_ephemeral_) dari replika; +Untuk mengakses replika melalui IP publik sementara, kamu harus melewatkan verifikasi TLS. + +### Pengklasteran etcd + +Untuk mengizinkan pengelompokkan etcd, porta yang diperlukan untuk berkomunikasi antara _instance_ etcd akan dibuka (untuk komunikasi dalam klaster). +Untuk membuat penyebaran itu aman, komunikasi antara _instance_ etcd diotorisasi menggunakan SSL. + +## Bacaan tambahan + +[Dokumen desain - Penyebaran master HA automatis](https://git.k8s.io/community/contributors/design-proposals/cluster-lifecycle/ha_master.md) + + diff --git a/content/id/docs/tasks/administer-cluster/namespaces.md b/content/id/docs/tasks/administer-cluster/namespaces.md new file mode 100644 index 0000000000..409e42dd70 --- /dev/null +++ b/content/id/docs/tasks/administer-cluster/namespaces.md @@ -0,0 +1,302 @@ +--- +title: Membagi sebuah Klaster dengan Namespace +content_type: task +--- + +<!-- overview --> +Laman ini menunjukkan bagaimana cara melihat, menggunakan dan menghapus {{< glossary_tooltip text="namespaces" term_id="namespace" >}}. Laman ini juga menunjukkan bagaimana cara menggunakan Namespace Kubernetes namespaces untuk membagi klaster kamu. + + +## {{% heading "prerequisites" %}} + +* Memiliki [Klaster Kubernetes](/id/docs/setup/). +* Memiliki pemahaman dasar [_Pod_](/id/docs/concepts/workloads/pods/pod/), [_Service_](/id/docs/concepts/services-networking/service/), dan [_Deployment_](/id/docs/concepts/workloads/controllers/deployment/) dalam Kubernetes. + + +<!-- steps --> + +## Melihat Namespace + +1. Untuk melihat Namespace yang ada saat ini pada sebuah klaster anda bisa menggunakan: + +```shell +kubectl get namespaces +``` +``` +NAME STATUS AGE +default Active 11d +kube-system Active 11d +kube-public Active 11d +``` + +Kubernetes mulai dengan tiga Namespace pertama: + + * `default` Namespace bawaan untuk objek-objek yang belum terkait dengan Namespace lain + * `kube-system` Namespace untuk objek-objek yang dibuat oleh sistem Kubernetes + * `kube-public` Namespace ini dibuat secara otomatis dan dapat dibaca oleh seluruh pengguna (termasuk yang tidak terotentikasi). Namespace ini sering dicadangkan untuk kepentingan klaster, untuk kasus dimana beberapa sumber daya seharusnya dapat terlihat dan dapat terlihat secara publik di seluruh klaster. Aspek publik pada Namespace ini hanya sebuah konvensi bukan suatu kebutuhan. + +Kamu bisa mendapat ringkasan Namespace tertentu dengan menggunakan: + +```shell +kubectl get namespaces <name> +``` + +Atau kamu bisa mendapatkan informasi detail menggunakan: + +```shell +kubectl describe namespaces <name> +``` +``` +Name: default +Labels: <none> +Annotations: <none> +Status: Active + +No resource quota. + +Resource Limits + Type Resource Min Max Default + ---- -------- --- --- --- + Container cpu - - 100m +``` + +Sebagai catatan, detail diatas menunjukkan baik kuota sumber daya (jika ada) dan juga jangkauan batas sumber daya. + +Kuota sumber daya melacak penggunaan total sumber daya didalam Namespace dan mengijinkan operator-operator klaster mendefinisikan batas atas penggunaan sumber daya yang dapat di gunakan sebuah Namespace. + +Jangkauan batas mendefinisikan pertimbangan min/maks jumlah sumber daya yang dapat di gunakan oleh sebuah entitas dalam sebuah Namespace. + +Lihatlah [Kontrol Admisi: Rentang Batas](https://git.k8s.io/community/contributors/design-proposals/resource-management/admission_control_limit_range.md) + +Sebuah Namespace dapat berada dalam salah satu dari dua buah fase: + + * `Active` Namespace sedang digunakan + * `Terminating` Namespace sedang dihapus dan tidak dapat digunakan untuk objek-objek baru + +Lihat [dokumentasi desain](https://git.k8s.io/community/contributors/design-proposals/architecture/namespaces.md#phases) untuk detil lebih lanjut. + +## Membuat sebuah Namespace baru + +{{< note >}} + Hindari membuat Namespace dengan awalan `kube-`, karena awalan ini dicadangkan untuk Namespace dari sistem Kubernetes. +{{< /note >}} + +1. Buat berkas YAML baru dengan nama `my-namespace.yaml` dengan isi berikut ini: + + ```yaml + apiVersion: v1 + kind: Namespace + metadata: + name: <masukkan-nama-namespace-disini> + ``` + Then run: + + ``` + kubectl create -f ./my-namespace.yaml + ``` + +2. Sebagai alternatif, kamu bisa membuat Namespace menggunakan perintah dibawah ini: + + ``` + kubectl create namespace <masukkan-nama-namespace-disini> + ``` + +Nama Namespace kamu harus merupakan +[Label DNS](/docs/concepts/overview/working-with-objects/names#dns-label-names) yang valid. + +Ada kolom opsional `finalizers`, yang memungkinkan _observables_ untuk membersihkan sumber daya ketika Namespace dihapus. Ingat bahwa jika kamu memberikan finalizer yang tidak ada, Namespace akan dibuat tapi akan berhenti pada status `Terminating` jika pengguna mencoba untuk menghapusnya. + +Informasi lebih lanjut mengenai `finalizers` bisa dibaca pada [dokumentasi desain](https://git.k8s.io/community/contributors/design-proposals/architecture/namespaces.md#finalizers) dari Namespace. + +## Menghapus Namespace + +Hapus Namespace dengan + +```shell +kubectl delete namespaces <insert-some-namespace-name> +``` + +{{< warning >}} +Ini akan menghapus semua hal yang ada dalam Namespace! +{{< /warning >}} + +Proses penghapusan ini asinkron, jadi untuk beberapa waktu kamu akan melihat Namespace dalam status `Terminating`. + +## Membagi klaster kamu menggunakan Namespace Kubernetes + +1. Pahami Namespace bawaan + + Secara bawaan, sebuah klaster Kubernetes akan membuat Namespace bawaan ketika menyediakan klaster untuk menampung Pod, Service, dan Deployment yang digunakan oleh klaster. + + Dengan asumsi kamu memiliki klaster baru, kamu bisa mengecek Namespace yang tersedia dengan melakukan hal berikut: + + ```shell + kubectl get namespaces + ``` + ``` + NAME STATUS AGE + default Active 13m + ``` + +2. Membuat Namespace baru + + Untuk latihan ini, kita akan membuat dua Namespace Kubernetes tambahan untuk menyimpan konten kita + + Dalam sebuah skenario dimana sebuah organisasi menggunakan klaster Kubernetes yang digunakan bersama untuk penggunaan pengembangan dan produksi: + + Tim pengembang ingin mengelola ruang di dalam klaster dimana mereka bisa melihat daftar Pod, Service, dan Deployment yang digunakan untuk membangun dan menjalankan apliksi mereka. Di ruang ini sumber daya akan datang dan pergi, dan pembatasan yang tidak ketat mengenai siapa yang bisa atau tidak bisa memodifikasi sumber daya untuk mendukung pengembangan secara gesit (_agile_). + + Tim operasi ingin mengelola ruang didalam klaster dimana mereka bisa memaksakan prosedur ketat mengenai siapa yang bisa atau tidak bisa melakukan manipulasi pada kumpulan Pod, Layanan, dan Deployment yang berjalan pada situs produksi. + + Satu pola yang bisa diikuti organisasi ini adalah dengan membagi klaster Kubernetes menjadi dua Namespace: `development` dan `production` + + Mari kita buat dua Namespace untuk menyimpan hasil kerja kita. + + Buat Namespace `development` menggunakan kubectl: + + ```shell + kubectl create -f https://k8s.io/examples/admin/namespace-dev.json + ``` + + Kemudian mari kita buat Namespace `production` menggunakan kubectl: + + ```shell + kubectl create -f https://k8s.io/examples/admin/namespace-prod.json + ``` + + Untuk memastikan apa yang kita lakukan benar, lihat seluruh Namespace dalam klaster. + + ```shell + kubectl get namespaces --show-labels + ``` + ``` + NAME STATUS AGE LABELS + default Active 32m <none> + development Active 29s name=development + production Active 23s name=production + ``` + +3. Buat pod pada setiap Namespace + + Sebuah Namespace Kubernetes memberikan batasan untuk Pod, Service, dan Deployment dalam klaster. + + Pengguna yang berinteraksi dengan salah satu Namespace tidak melihat konten di dalam Namespace lain + + Untuk menunjukkan hal ini, mari kita jalankan Deployment dan Pod sederhana di dalam Namespace `development`. + + ```shell + kubectl create deployment snowflake --image=k8s.gcr.io/serve_hostname -n=development + kubectl scale deployment snowflake --replicas=2 -n=development + ``` + Kita baru aja membuat sebuah Deployment yang memiliki ukuran replika dua yang menjalankan Pod dengan nama `snowflake` dengan sebuah Container dasar yang hanya melayani _hostname_. + + + ```shell + kubectl get deployment -n=development + ``` + ``` + NAME READY UP-TO-DATE AVAILABLE AGE + snowflake 2/2 2 2 2m + ``` + ```shell + kubectl get pods -l app=snowflake -n=development + ``` + ``` + NAME READY STATUS RESTARTS AGE + snowflake-3968820950-9dgr8 1/1 Running 0 2m + snowflake-3968820950-vgc4n 1/1 Running 0 2m + ``` + + Dan ini merupakan sesuatu yang bagus, dimana pengembang bisa melakukan hal yang ingin mereka lakukan tanpa harus khawatir hal itu akan mempengaruhi konten pada namespace `production`. + + Mari kita pindah ke Namespace `production` dan menujukkan bagaimana sumber daya di satu Namespace disembunyikan dari yang lain + + Namespace `production` seharusnya kosong, dan perintah berikut ini seharusnya tidak menghasilkan apapun. + + ```shell + kubectl get deployment -n=production + kubectl get pods -n=production + ``` + + `Production` Namespace ingin menjalankan `cattle`, mari kita buat beberapa Pod `cattle`. + + ```shell + kubectl create deployment cattle --image=k8s.gcr.io/serve_hostname -n=production + kubectl scale deployment cattle --replicas=5 -n=production + + kubectl get deployment -n=production + ``` + ``` + NAME READY UP-TO-DATE AVAILABLE AGE + cattle 5/5 5 5 10s + ``` + + ```shell + kubectl get pods -l app=cattle -n=production + ``` + ``` + NAME READY STATUS RESTARTS AGE + cattle-2263376956-41xy6 1/1 Running 0 34s + cattle-2263376956-kw466 1/1 Running 0 34s + cattle-2263376956-n4v97 1/1 Running 0 34s + cattle-2263376956-p5p3i 1/1 Running 0 34s + cattle-2263376956-sxpth 1/1 Running 0 34s + ``` + +Sampai sini, seharusnya sudah jelas bahwa sumber daya yang dibuat pengguna pada sebuah Namespace disembunyikan dari Namespace lainnya. + +Seiring dengan evolusi dukungan kebijakan di Kubernetes, kami akan memperluas skenario ini untuk menunjukkan bagaimana kamu bisa menyediakan aturan otorisasi yang berbeda untuk tiap Namespace. + + +<!-- discussion --> + +## Memahami motivasi penggunaan Namespace + +Sebuah klaster tunggal umumnya bisa memenuhi kebutuhan pengguna yang berbeda atau kelompok pengguna (itulah sebabnya disebut 'komunitas pengguna'). + +Namespace Kubernetes membantu proyek-proyek, tim-tim dan pelanggan yang berbeda untuk berbagi klaster Kubernetes. + +Ini dilakukan dengan menyediakan hal berikut: + +1. Cakupan untuk [Names](/id/docs/concepts/overview/working-with-objects/names/). +2. Sebuah mekanisme untuk memasang otorisasi dan kebijakan untuk bagian dari klaster. + +Penggunaan Namespace berbeda merupakan hal opsional. + +Tiap komunitas pengguna ingin bisa bekerja secara terisolasi dari komunitas lainnya. + +Tiap komunitas pengguna memiliki hal berikut sendiri: + +1. sumber daya (Pod, Service, ReplicationController, dll.) +2. kebijakan (siapa yang bisa atau tidak bisa melakukan hal tertentu dalam komunitasnya) +3. batasan (komunitas ini diberi kuota sekian, dll.) + +Seorang operator klaster dapat membuat sebuah Namespace untuk tiap komunitas user yang unik. + +Namespace tersebut memberikan cakupan yang unik untuk: + +1. penamaan sumber daya (untuk menghindari benturan penamaan dasar) +2. pendelegasian otoritas pengelolaan untuk pengguna yang dapat dipercaya +3. kemampuan untuk membatasi konsumsi sumber daya komunitas + +Contoh penggunaan mencakup + +1. Sebagai operator klaster, aku ingin mendukung beberapa komunitas pengguna dalam sebuah klaster. +2. Sebagai operator klaster, aku ingin mendelegasikan otoritas untuk mempartisi klaster ke pengguna terpercaya di komunitasnya. +3. Sebagai operator klaster, aku ingin membatasi jumlah sumber daya yang bisa dikonsumsi komunitas dalam rangka membatasi dampak ke komunitas lain yang menggunakan klaster yang sama. +4. Sebagai pengguna klaster, aku ingin berinteraksi dengan sumber daya yang berkaitan dengan komunitas pengguna saya secara terisolasi dari apa yang dilakukan komunitas lain di klaster yang sama. + +## Memahami Namespace dan DNS + +Ketika kamu membuat sebuah [Service](/docs/concepts/services-networking/service/), akan terbentuk [entri DNS](/id/docs/concepts/services-networking/dns-pod-service/) untuk Service tersebut. +Entri DNS ini dalam bentuk `<service-name>.<namespace-name>.svc.cluster.local`, yang berarti jika sebuah Container hanya menggunakan `<service-name>` maka dia akan me-_resolve_ ke layanan yang lokal dalam Namespace yang sama. Ini berguna untuk menggunakan konfigurasi yang sama pada Namespace yang berbeda seperti _Development_, _Staging_ dan _Production_. Jika kami ingin menjangkau antar Namespace, kamu harus menggunakan _fully qualified domain name_ (FQDN). + + + +## {{% heading "whatsnext" %}} + +* Pelajari lebih lanjut mengenai [pengaturan preferensi Namespace](/id/docs/concepts/overview/working-with-objects/namespaces/#pengaturan-preferensi-namespace). +* Pelajari lebih lanjut mengenai [pengaturan namespace untuk sebuah permintaan](/id/docs/concepts/overview/working-with-objects/namespaces/#pengaturan-namespace-untuk-sebuah-permintaan) +* Baca [desain Namespace](https://github.com/kubernetes/community/blob/{{< param "githubbranch" >}}/contributors/design-proposals/architecture/namespaces.md). + + diff --git a/content/id/docs/tasks/administer-cluster/network-policy-provider/calico-network-policy.md b/content/id/docs/tasks/administer-cluster/network-policy-provider/calico-network-policy.md new file mode 100644 index 0000000000..9eb79e7676 --- /dev/null +++ b/content/id/docs/tasks/administer-cluster/network-policy-provider/calico-network-policy.md @@ -0,0 +1,52 @@ +--- +title: Menggunakan Calico untuk NetworkPolicy +content_type: task +weight: 10 +--- + +<!-- overview --> +Laman ini menunjukkan beberapa cara cepat untuk membuat klaster Calico pada Kubernetes. + + +## {{% heading "prerequisites" %}} + +Putuskan apakah kamu ingin menggelar (_deploy_) sebuah klaster di [_cloud_](#membuat-klaster-calico-menggunakan-google-kubernetes-engine-gke) atau di [lokal](#membuat-klaster-calico-dengan-kubeadm). + + +<!-- steps --> +## Membuat klaster Calico dengan menggunakan _Google Kubernetes Engine_ (GKE) {#membuat-klaster-calico-menggunakan-google-kubernetes-engine-gke} + +**Prasyarat**: [gcloud](https://cloud.google.com/sdk/docs/quickstarts). + +1. Untuk meluncurkan klaster GKE dengan Calico, cukup sertakan opsi `--enable-network-policy`. + + **Sintaksis** + ```shell + gcloud container clusters create [CLUSTER_NAME] --enable-network-policy + ``` + + **Contoh** + ```shell + gcloud container clusters create my-calico-cluster --enable-network-policy + ``` + +2. Untuk memverifikasi penggelaran, gunakanlah perintah berikut ini. + + ```shell + kubectl get pods --namespace=kube-system + ``` + + Pod Calico dimulai dengan kata `calico`. Periksa untuk memastikan bahwa statusnya `Running`. + +## Membuat klaster lokal Calico dengan kubeadm {#membuat-klaster-calico-dengan-kubeadm} + +Untuk membuat satu klaster Calico dengan hos tunggal dalam waktu lima belas menit dengan menggunakan kubeadm, silakan merujuk pada + +[Memulai cepat Calico](https://docs.projectcalico.org/latest/getting-started/kubernetes/). + + +## {{% heading "whatsnext" %}} + +Setelah klaster kamu berjalan, kamu dapat mengikuti [Mendeklarasikan Kebijakan Jaringan](/id/docs/tasks/administer-cluster/declare-network-policy/) untuk mencoba NetworkPolicy Kubernetes. + + diff --git a/content/id/docs/tasks/configure-pod-container/assign-pods-nodes-using-node-affinity.md b/content/id/docs/tasks/configure-pod-container/assign-pods-nodes-using-node-affinity.md new file mode 100644 index 0000000000..a60d862fd2 --- /dev/null +++ b/content/id/docs/tasks/configure-pod-container/assign-pods-nodes-using-node-affinity.md @@ -0,0 +1,119 @@ +--- +title: Menempatkan Pod pada Node Menggunakan Afinitas Pod +min-kubernetes-server-version: v1.10 +content_type: task +weight: 120 +--- + +<!-- overview --> +Dokumen ini menunjukkan cara menempatkan Pod Kubernetes pada sebuah Node menggunakan +Afinitas Node di dalam klaster Kubernetes. + + +## {{% heading "prerequisites" %}} + + +{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}} + + + +<!-- steps --> + +## Menambahkan sebuah Label pada sebuah Node + +1. Jabarkan Node-Node yang ada pada klaster kamu, bersamaan dengan label yang ada: + + ```shell + kubectl get nodes --show-labels + ``` + Keluaran dari perintah tersebut akan berupa: + + ```shell + NAME STATUS ROLES AGE VERSION LABELS + worker0 Ready <none> 1d v1.13.0 ...,kubernetes.io/hostname=worker0 + worker1 Ready <none> 1d v1.13.0 ...,kubernetes.io/hostname=worker1 + worker2 Ready <none> 1d v1.13.0 ...,kubernetes.io/hostname=worker2 + ``` +1. Pilihkan salah satu dari Node yang ada dan tambahkan label pada Node tersebut. + + ```shell + kubectl label nodes <nama-node-kamu> disktype=ssd + ``` + dimana `<nama-node-kamu>` merupakan nama dari Node yang kamu pilih. + +1. Keluaran dari Node yang kamu pilih dan sudah memiliki label `disktype=ssd`: + + ```shell + kubectl get nodes --show-labels + ``` + + Keluaran dari perintah tersebut akan berupa: + + ``` + NAME STATUS ROLES AGE VERSION LABELS + worker0 Ready <none> 1d v1.13.0 ...,disktype=ssd,kubernetes.io/hostname=worker0 + worker1 Ready <none> 1d v1.13.0 ...,kubernetes.io/hostname=worker1 + worker2 Ready <none> 1d v1.13.0 ...,kubernetes.io/hostname=worker2 + ``` + + Pada keluaran dari perintah di atas, kamu dapat melihat bahwa Node `worker0` + memiliki label `disktype=ssd`. + +## Menjadwalkan Pod menggunakan Afinitas Node + +Konfigurasi ini menunjukkan sebuah Pod yang memiliki afinitas node `requiredDuringSchedulingIgnoredDuringExecution`, `disktype: ssd`. +Dengan kata lain, Pod hanya akan dijadwalkan hanya pada Node yang memiliki label `disktype=ssd`. + +{{< codenew file="pods/pod-nginx-required-affinity.yaml" >}} + +1. Terapkan konfigurasi berikut untuk membuat sebuah Pod yang akan dijadwalkan pada Node yang kamu pilih: + + ```shell + kubectl apply -f https://k8s.io/examples/pods/pod-nginx-required-affinity.yaml + ``` + +1. Verifikasi apakah Pod yang kamu pilih sudah dijalankan pada Node yang kamu pilih: + + ```shell + kubectl get pods --output=wide + ``` + + Keluaran dari perintah tersebut akan berupa: + + ``` + NAME READY STATUS RESTARTS AGE IP NODE + nginx 1/1 Running 0 13s 10.200.0.4 worker0 + ``` + +## Jadwalkan Pod menggunakan Afinitas Node yang Dipilih + +Konfigurasi ini memberikan deskripsi sebuah Pod yang memiliki afinitas Node `preferredDuringSchedulingIgnoredDuringExecution`,`disktype: ssd`. +Artinya Pod akan diutamakan dijalankan pada Node yang memiliki label `disktype=ssd`. + +{{< codenew file="pods/pod-nginx-preferred-affinity.yaml" >}} + +1. Terapkan konfigurasi berikut untuk membuat sebuah Pod yang akan dijadwalkan pada Node yang kamu pilih: + + ```shell + kubectl apply -f https://k8s.io/examples/pods/pod-nginx-preferred-affinity.yaml + ``` + +1. Verifikasi apakah Pod yang kamu pilih sudah dijalankan pada Node yang kamu pilih: + + ```shell + kubectl get pods --output=wide + ``` + + Keluaran dari perintah tersebut akan berupa: + + ``` + NAME READY STATUS RESTARTS AGE IP NODE + nginx 1/1 Running 0 13s 10.200.0.4 worker0 + ``` + + + +## {{% heading "whatsnext" %}} + +Pelajari lebih lanjut mengenai +[Afinitas Node](/id/docs/concepts/scheduling-eviction/assign-pod-node/#node-affinity). diff --git a/content/id/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes.md b/content/id/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes.md index 1d36713f7f..934f6178cd 100644 --- a/content/id/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes.md +++ b/content/id/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes.md @@ -1,10 +1,10 @@ --- title: Mengatur Probe Liveness, Readiness dan Startup -content_template: templates/task +content_type: task weight: 110 --- -{{% capture overview %}} +<!-- overview --> Laman ini memperlihatkan bagaimana cara untuk mengatur _probe liveness_, _readiness_, dan _startup_ untuk Container. @@ -26,15 +26,16 @@ berhasil, kamu harus memastikan _probe_ tersebut tidak mengganggu _startup_ dari Mekanisme ini dapat digunakan untuk mengadopsi pemeriksaan _liveness_ pada saat memulai Container yang lambat, untuk menghindari Container dimatikan oleh kubelet sebelum Container mulai dan berjalan. -{{% /capture %}} -{{% capture prerequisites %}} + +## {{% heading "prerequisites" %}} + {{< include "task-tutorial-prereqs.md" >}} {{< version-check >}} -{{% /capture %}} -{{% capture steps %}} + +<!-- steps --> ## Mendefinisikan perintah liveness @@ -358,9 +359,10 @@ Untuk _probe_ TCP, kubelet membuat koneksi _probe_ pada Node, tidak pada Pod, ya kamu tidak menggunakan nama Service di dalam parameter `host` karena kubelet tidak bisa me-_resolve_-nya. -{{% /capture %}} -{{% capture whatsnext %}} + +## {{% heading "whatsnext" %}} + * Pelajari lebih lanjut tentang [Probe Container](/id/docs/concepts/workloads/pods/pod-lifecycle/#container-probes). @@ -371,4 +373,4 @@ Kamu juga dapat membaca rujukan API untuk: * [Container](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#container-v1-core) * [Probe](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#probe-v1-core) -{{% /capture %}} + diff --git a/content/id/docs/tasks/configure-pod-container/configure-persistent-volume-storage.md b/content/id/docs/tasks/configure-pod-container/configure-persistent-volume-storage.md index 22e13e2c8a..1d41c53e4c 100644 --- a/content/id/docs/tasks/configure-pod-container/configure-persistent-volume-storage.md +++ b/content/id/docs/tasks/configure-pod-container/configure-persistent-volume-storage.md @@ -1,10 +1,10 @@ --- title: Mengatur Pod untuk Penyimpanan dengan PersistentVolume -content_template: templates/task +content_type: task weight: 60 --- -{{% capture overview %}} +<!-- overview --> Laman ini akan menjelaskan bagaimana kamu dapat mengatur sebuah Pod dengan menggunakan {{< glossary_tooltip text="PersistentVolumeClaim" term_id="persistent-volume-claim" >}} @@ -19,9 +19,10 @@ PersistentVolumeClaim yang secara otomatis terikat dengan PersistentVolume yang 3. Kamu membuat sebuah Pod yang menggunakan PersistentVolumeClaim di atas untuk penyimpanan. -{{% /capture %}} -{{% capture prerequisites %}} + +## {{% heading "prerequisites" %}} + * Kamu membutuhkan sebuah klaster Kubernetes yang hanya memiliki satu Node, dan {{< glossary_tooltip text="kubectl" term_id="kubectl" >}} @@ -32,9 +33,9 @@ tidak memiliki sebuah klaster dengan Node tunggal, kamu dapat membuatnya dengan * Familiar dengan materi di [Persistent Volumes](/id/docs/concepts/storage/persistent-volumes/). -{{% /capture %}} -{{% capture steps %}} + +<!-- steps --> ## Membuat sebuah berkas index.html di dalam Node kamu @@ -235,10 +236,10 @@ sudo rmdir /mnt/data Sekarang kamu dapat menutup _shell_ Node kamu. -{{% /capture %}} -{{% capture discussion %}} + +<!-- discussion --> ## Kontrol akses @@ -266,10 +267,11 @@ Ketika sebuah Pod mengkonsumsi PersistentVolume, GID yang terkait dengan Persist tidak ada di dalam sumberdaya Pod itu sendiri. {{< /note >}} -{{% /capture %}} -{{% capture whatsnext %}} + +## {{% heading "whatsnext" %}} + * Belajar lebih lanjut tentang [PersistentVolume](/id/docs/concepts/storage/persistent-volumes/). * Baca [dokumen perancangan Penyimpanan _Persistent_](https://git.k8s.io/community/contributors/design-proposals/storage/persistent-storage.md). @@ -281,4 +283,4 @@ tidak ada di dalam sumberdaya Pod itu sendiri. * [PersistentVolumeClaim](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#persistentvolumeclaim-v1-core) * [PersistentVolumeClaimSpec](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#persistentvolumeclaimspec-v1-core) -{{% /capture %}} + diff --git a/content/id/docs/tasks/configure-pod-container/configure-pod-configmap.md b/content/id/docs/tasks/configure-pod-container/configure-pod-configmap.md index e5175ccf0e..bfdad56610 100644 --- a/content/id/docs/tasks/configure-pod-container/configure-pod-configmap.md +++ b/content/id/docs/tasks/configure-pod-container/configure-pod-configmap.md @@ -35,7 +35,7 @@ kubectl create configmap <map-name> <data-source> di mana \<map-name> merupakan nama yang ingin kamu berikan pada ConfigMap tersebut dan \<data-source> adalah direktori, berkas, atau nilai harfiah yang digunakan sebagai sumber data. Nama dari sebuah objek ConfigMap haruslah berupa -[nama subdomain DNS](/docs/concepts/overview/working-with-objects/names#dns-subdomain-names) yang sah. +[nama subdomain DNS](/id/docs/concepts/overview/working-with-objects/names#dns-subdomain-names) yang sah. Ketika kamu membuat ConfigMap dari sebuah berkas, secara bawaan, _basename_ dari berkas tersebut akan menjadi kunci pada \<data-source>, dan isi dari berkas tersebut akan menjadi nilai dari kunci tersebut. @@ -615,14 +615,14 @@ Seperti sebelumnya, semua berkas yang sebelumnya berada pada direktori `/etc/con ### Memproyeksikan kunci ke jalur dan perizinan berkas tertentu Kamu dapat memproyeksikan kunci ke jalur dan perizinan tertentu pada setiap -berkas. Panduan pengguna [Secret](/docs/concepts/configuration/secret/#using-secrets-as-files-from-a-pod) menjelaskan mengenai sintaks-sintaksnya. +berkas. Panduan pengguna [Secret](/id/docs/concepts/configuration/secret/#using-secrets-as-files-from-a-pod) menjelaskan mengenai sintaks-sintaksnya. ### ConfigMap yang dipasang akan diperbarui secara otomatis Ketika sebuah ConfigMap yang sudah dipasang pada sebuah volume diperbarui, kunci-kunci yang diproyeksikan akan turut diperbarui. Kubelet akan memeriksa apakah ConfigMap yang dipasang merupakan yang terbaru pada sinkronisasi berkala. Namun, ConfigMap menggunakan _cache_ lokal berbasis ttl (_time-to-live_) miliknya untuk mendapatkan nilai dari ConfigMap saat ini. Hasilnya, keseluruhan penundaan dari saat ketika ConfigMap diperbarui sampai saat ketika kunci-kunci baru diproyeksikan ke pada Pod bisa selama periode sinkronisasi kubelet (secara bawaan selama 1 menit) + ttl dari _cache_ ConfigMap (secara bawaan selama 1 menit) pada kubelet. Kamu dapat memicu pembaruan langsung dengan memperbarui salah satu dari anotasi Pod. {{< note >}} -Kontainer yang menggunakan ConfigMap sebagai volume [subPath](/docs/concepts/storage/volumes/#using-subpath) tidak akan menerima pembaruan ConfigMap. +Kontainer yang menggunakan ConfigMap sebagai volume [subPath](/id/docs/concepts/storage/volumes/#using-subpath) tidak akan menerima pembaruan ConfigMap. {{< /note >}} @@ -631,10 +631,10 @@ Kontainer yang menggunakan ConfigMap sebagai volume [subPath](/docs/concepts/sto ## Memahami ConfigMap dan Pod -Sumber daya API ConfigMap menyimpan data konfigurasi sebagai pasangan kunci-nilai. Data tersebut dapat dikonsumsi oleh Pod atau sebagai penyedia konfigurasi untuk komponen-komponen sistem seperti kontroler. ConfigMap mirip dengan [Secret](/docs/concepts/configuration/secret/), tetapi ConfigMap dimaksudkan untuk mengolah tulisan yang tidak memiliki informasi yang sensitif. Baik pengguna maupun komponen sistem dapat menyimpan data konfigurasi pada ConfigMap. +Sumber daya API ConfigMap menyimpan data konfigurasi sebagai pasangan kunci-nilai. Data tersebut dapat dikonsumsi oleh Pod atau sebagai penyedia konfigurasi untuk komponen-komponen sistem seperti kontroler. ConfigMap mirip dengan [Secret](/id/docs/concepts/configuration/secret/), tetapi ConfigMap dimaksudkan untuk mengolah tulisan yang tidak memiliki informasi yang sensitif. Baik pengguna maupun komponen sistem dapat menyimpan data konfigurasi pada ConfigMap. {{< note >}} -ConfigMap harus mereferensikan berkas-berkas properti, bukan menggantikannya. Anggaplah ConfigMap sebagai sesuatu yang merepresentasikan direktori `/etc` beserta isinya pada Linux. Sebagai contoh, jika kamu membuat sebuah [Volume Kubernetes](/docs/concepts/storage/volumes/) dari ConfigMap, tiap butir data pada ConfigMap direpresentasikan sebagai sebuah berkas pada volume. +ConfigMap harus mereferensikan berkas-berkas properti, bukan menggantikannya. Anggaplah ConfigMap sebagai sesuatu yang merepresentasikan direktori `/etc` beserta isinya pada Linux. Sebagai contoh, jika kamu membuat sebuah [Volume Kubernetes](/id/docs/concepts/storage/volumes/) dari ConfigMap, tiap butir data pada ConfigMap direpresentasikan sebagai sebuah berkas pada volume. {{< /note >}} Kolom `data` pada ConfigMap berisi data konfigurasi. Seperti pada contoh di bawah, hal ini bisa berupa sesuatu yang sederhana -- seperti properti individual yang ditentukan menggunakan `--from-literal` -- atau sesuatu yang kompleks -- seperti berkas konfigurasi atau _blob_ JSON yang ditentukan dengan `--from-file`. diff --git a/content/id/docs/tasks/configure-pod-container/configure-service-account.md b/content/id/docs/tasks/configure-pod-container/configure-service-account.md new file mode 100644 index 0000000000..4a4d5999db --- /dev/null +++ b/content/id/docs/tasks/configure-pod-container/configure-service-account.md @@ -0,0 +1,333 @@ +--- +title: Mengatur ServiceAccount untuk Pod +content_type: task +weight: 90 +--- + +<!-- overview --> +ServiceAccount menyediakan identitas untuk proses yang sedang berjalan dalam sebuah Pod. + +{{< note >}} +Dokumen ini digunakan sebagai pengenalan untuk pengguna terhadap ServiceAccount dan menjelaskan bagaimana perilaku ServiceAccount dalam konfigurasi klaster seperti yang direkomendasikan Kubernetes. Pengubahan perilaku yang bisa saja dilakukan administrator klaster terhadap klaster tidak menjadi bagian pembahasan dokumentasi ini. +{{< /note >}} + +Ketika kamu mengakses klaster (contohnya menggunakan `kubectl`), kamu terautentikasi oleh apiserver sebagai sebuah akun pengguna (untuk sekarang umumnya sebagai `admin`, kecuali jika administrator klustermu telah melakukan pengubahan). Berbagai proses yang ada di dalam kontainer dalam Pod juga dapat mengontak apiserver. Ketika itu terjadi, mereka akan diautentikasi sebagai sebuah ServiceAccount (contohnya sebagai `default`). + + + + +## {{% heading "prerequisites" %}} + + +{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}} + + + +<!-- steps --> + +## Menggunakan Default ServiceAccount untuk Mengakses API server. + +Ketika kamu membuat sebuah Pod, jika kamu tidak menentukan sebuah ServiceAccount, maka ia akan otomatis ditetapkan sebagai ServiceAccount`default` di Namespace yang sama. Jika kamu mendapatkan json atau yaml mentah untuk sebuah Pod yang telah kamu buat (contohnya menggunakan `kubectl get pods/<podname> -o yaml`), kamu akan melihat _field_ `spec.serviceAccountName` yang telah secara [otomatis ditentukan](/docs/user-guide/working-with-resources/#resources-are-automatically-modified). + +Kamu dapat mengakses API dari dalam Pod menggunakan kredensial ServiceAccount yang ditambahkan secara otomatis seperti yang dijelaskan dalam [Mengakses Klaster](/docs/user-guide/accessing-the-cluster/#accessing-the-api-from-a-pod). +Hak akses API dari ServiceAccount menyesuaikan dengan [kebijakan dan plugin otorisasi](/docs/reference/access-authn-authz/authorization/#authorization-modules) yang sedang digunakan. + +Di versi 1.6+, kamu dapat tidak memilih _automounting_ kredensial API dari sebuah ServiceAccount dengan mengatur `automountServiceAccountToken: false` pada ServiceAccount: + +```yaml +apiVersion: v1 +kind: ServiceAccount +metadata: + name: build-robot +automountServiceAccountToken: false +... +``` + +Di versi 1.6+, kamu juga dapat tidak memilih _automounting_ kredensial API dari suatu Pod tertentu: + +```yaml +apiVersion: v1 +kind: Pod +metadata: + name: my-pod +spec: + serviceAccountName: build-robot + automountServiceAccountToken: false + ... +``` + +Pengaturan dari spesifikasi Pod didahulukan dibanding ServiceAccount jika keduanya menentukan nilai dari `automountServiceAccountToken`. + +## Menggunakan Beberapa ServiceAccount. + +Setiap Namespace memiliki sumber daya ServiceAccount standar `default`. +Kamu dapat melihatnya dan sumber daya serviceAccount lainnya di Namespace tersebut dengan perintah: + +```shell +kubectl get serviceaccounts +``` +Keluarannya akan serupa dengan: + +``` +NAME SECRETS AGE +default 1 1d +``` + +Kamu dapat membuat objek ServiceAccount tambahan seperti ini: + +```shell +kubectl apply -f - <<EOF +apiVersion: v1 +kind: ServiceAccount +metadata: + name: build-robot +EOF +``` + +Nama dari objek ServiceAccount haruslah sebuah [nama subdomain DNS](/id/docs/concepts/overview/working-with-objects/names#dns-subdomain-names) yang valid. + +Jika kamu mendapatkan objek ServiceAccount secara komplit, seperti ini: + +```shell +kubectl get serviceaccounts/build-robot -o yaml +``` +Keluarannya akan serupa dengan: + +``` +apiVersion: v1 +kind: ServiceAccount +metadata: + creationTimestamp: 2015-06-16T00:12:59Z + name: build-robot + namespace: default + resourceVersion: "272500" + uid: 721ab723-13bc-11e5-aec2-42010af0021e +secrets: +- name: build-robot-token-bvbk5 +``` + +maka kamu dapat melihat bahwa _token_ telah dibuat secara otomatis dan dirujuk oleh ServiceAccount. + +Kamu dapat menggunakan _plugin_ otorisasi untuk [mengatur hak akses dari ServiceAccount](/id/docs/reference/access-authn-authz/rbac/#service-account-permissions). + +Untuk menggunakan ServiceAccount selain nilai standar, atur _field_ `spec.serviceAccountName` dari Pod menjadi nama dari ServiceAccount yang hendak kamu gunakan. + +_Service account_ harus ada ketika Pod dibuat, jika tidak maka akan ditolak. + +Kamu tidak dapat memperbarui ServiceAccount dari Pod yang telah dibuat. + +Kamu dapat menghapus ServiceAccount dari contoh seperti ini: + +```shell +kubectl delete serviceaccount/build-robot +``` + +## Membuat token API ServiceAccount secara manual. + +Asumsikan kita memiliki ServiceAccount dengan nama "build-robot" seperti yang disebukan di atas, dan kita membuat Secret secara manual. + +```shell +kubectl apply -f - <<EOF +apiVersion: v1 +kind: Secret +metadata: + name: build-robot-secret + annotations: + kubernetes.io/service-account.name: build-robot +type: kubernetes.io/service-account-token +EOF +``` + +Sekarang kamu dapat mengonfirmasi bahwa Secret yang baru saja dibuat diisi dengan _token_ API dari ServiceAccount "build-robot". + +Setiap _token_ dari ServiceAccount yang tidak ada akan dihapus oleh _token controller_. + +```shell +kubectl describe secrets/build-robot-secret +``` +Keluarannya akan serupa dengan: + +``` +Name: build-robot-secret +Namespace: default +Labels: <none> +Annotations: kubernetes.io/service-account.name=build-robot + kubernetes.io/service-account.uid=da68f9c6-9d26-11e7-b84e-002dc52800da + +Type: kubernetes.io/service-account-token + +Data +==== +ca.crt: 1338 bytes +namespace: 7 bytes +token: ... +``` + +{{< note >}} +Isi dari `token` tidak dirinci di sini. +{{< /note >}} + +## Menambahkan ImagePullSecret ke ServiceAccount. + +### Membuat imagePullSecret + +- Membuat sebuah imagePullSecret, seperti yang dijelaskan pada [Menentukan ImagePullSecret pada Pod](/id/docs/concepts/containers/images/#tentukan-imagepullsecrets-pada-sebuah-pod). + + ```shell + kubectl create secret docker-registry myregistrykey --docker-server=DUMMY_SERVER \ + --docker-username=DUMMY_USERNAME --docker-password=DUMMY_DOCKER_PASSWORD \ + --docker-email=DUMMY_DOCKER_EMAIL + ``` + +- Memastikan bahwa Secret telah terbuat. + ```shell + kubectl get secrets myregistrykey + ``` + + Keluarannya akan serupa dengan: + + ``` + NAME TYPE DATA AGE + myregistrykey   kubernetes.io/.dockerconfigjson   1       1d + ``` + +### Menambahkan imagePullSecret ke ServiceAccount + +Selanjutnya, modifikasi ServiceAccount standar dari Namespace untuk menggunakan Secret ini sebagai imagePullSecret. + + +```shell +kubectl patch serviceaccount default -p '{"imagePullSecrets": [{"name": "myregistrykey"}]}' +``` + +Sebagai gantinya kamu dapat menggunakan `kubectl edit`, atau melakukan pengubahan secara manual manifes YAML seperti di bawah ini: + +```shell +kubectl get serviceaccounts default -o yaml > ./sa.yaml +``` + +Keluaran dari berkas `sa.yaml` akan serupa dengan: + +```shell +apiVersion: v1 +kind: ServiceAccount +metadata: + creationTimestamp: 2015-08-07T22:02:39Z + name: default + namespace: default + resourceVersion: "243024" + uid: 052fb0f4-3d50-11e5-b066-42010af0d7b6 +secrets: +- name: default-token-uudge +``` + +Menggunakan _editor_ pilihanmu (misalnya `vi`), buka berkas `sa.yaml`, hapus baris dengan key `resourceVersion`, tambahkan baris dengan `imagePullSecrets:` dan simpan. + +Keluaran dari berkas `sa.yaml` akan serupa dengan: + +```shell +apiVersion: v1 +kind: ServiceAccount +metadata: + creationTimestamp: 2015-08-07T22:02:39Z + name: default + namespace: default + uid: 052fb0f4-3d50-11e5-b066-42010af0d7b6 +secrets: +- name: default-token-uudge +imagePullSecrets: +- name: myregistrykey +``` + +Terakhir ganti serviceaccount dengan berkas `sa.yaml` yang telah diperbarui. + +```shell +kubectl replace serviceaccount default -f ./sa.yaml +``` + +### Memverifikasi imagePullSecrets sudah ditambahkan ke spesifikasi Pod + +Ketika Pod baru dibuat dalam Namespace yang sedang aktif dan menggunakan ServiceAccount, Pod baru akan memiliki _field_ `spec.imagePullSecrets` yang ditentukan secara otomatis: + +```shell +kubectl run nginx --image=nginx --restart=Never +kubectl get pod nginx -o=jsonpath='{.spec.imagePullSecrets[0].name}{"\n"}' +``` + +Keluarannya adalah: + +``` +myregistrykey +``` + +<!--## Menambahkan Secrets ke sebuah ServiceAccount. + +TODO: Tes dan jelaskan bagaimana cara menambahkan Secret tambahan non-K8s dengan ServiceAccount yang sudah ada. +--> + +## ServiceAccountTokenVolumeProjection + +{{< feature-state for_k8s_version="v1.12" state="beta" >}} + +{{< note >}} +ServiceAccountTokenVolumeProjection masih dalam tahap __beta__ untuk versi 1.12 dan diaktifkan dengan memberikan _flag_ berikut ini ke API server: + +* `--service-account-issuer` +* `--service-account-signing-key-file` +* `--service-account-api-audiences` + +{{< /note >}} + +Kubelet juga dapat memproyeksikan _token_ ServiceAccount ke Pod. Kamu dapat menentukan properti yang diinginkan dari _token_ seperti target pengguna dan durasi validitas. Properti tersebut tidak dapat diubah pada _token_ ServiceAccount standar. _Token_ ServiceAccount juga akan menjadi tidak valid terhadap API ketika Pod atau ServiceAccount dihapus. + +Perilaku ini diatur pada PodSpec menggunakan tipe ProjectedVolume yaitu [ServiceAccountToken](/id/docs/concepts/storage/volumes/#projected). Untuk memungkinkan Pod dengan _token_ dengan pengguna bertipe _"vault"_ dan durasi validitas selama dua jam, kamu harus mengubah bagian ini pada PodSpec: + +{{< codenew file="pods/pod-projected-svc-token.yaml" >}} + +Buat Pod: + +```shell +kubectl create -f https://k8s.io/examples/pods/pod-projected-svc-token.yaml +``` + +_Token_ yang mewakili Pod akan diminta dan disimpan kubelet, lalu kubelet akan membuat _token_ yang dapat diakses oleh Pod pada _file path_ yang ditentukan, dan melakukan _refresh_ _token_ ketika telah mendekati waktu berakhir. _Token_ akan diganti oleh kubelet jika _token_ telah melewati 80% dari total TTL, atau jika _token_ telah melebihi waktu 24 jam. + +Aplikasi bertanggung jawab untuk memuat ulang _token_ ketika terjadi penggantian. Pemuatan ulang teratur (misalnya sekali setiap 5 menit) cukup untuk mencakup kebanyakan kasus. + +## ServiceAccountIssuerDiscovery + +{{< feature-state for_k8s_version="v1.18" state="alpha" >}} + +Fitur ServiceAccountIssuerDiscovery diaktifkan dengan mengaktifkan [gerbang fitur](/docs/reference/command-line-tools-reference/feature-gate) `ServiceAccountIssuerDiscovery` dan mengaktifkan fitur _Service Account Token Volume Projection_ seperti yang telah dijelaskan [di atas](#service-account-token-volume-projection). + +{{< note >}} +URL _issuer_ harus sesuai dengan _[OIDC Discovery Spec](https://openid.net/specs/openid-connect-discovery-1_0.html)_. Pada implementasinya, hal ini berarti URL harus menggunakan skema `https` dan harus menyediakan konfigurasi penyedia OpenID pada `{service-account-issuer}/.well-known/openid-configuration`. + +Jika URL tidak sesuai dengan aturan, _endpoint_ `ServiceAccountIssuerDiscovery` tidak akan didaftarkan meskipun fitur telah diaktifkan. +{{< /note >}} + +Fitur _Service Account Issuer Discovery_ memungkinkan federasi dari berbagai _token_ ServiceAccount Kubernetes yang dibuat oleh sebuah klaster (penyedia identitas) dan sistem eksternal. + +Ketika diaktifkan, server API Kubernetes menyediakan dokumen OpenID Provider Configuration pada `/.well-known/openid-configuration` dan JSON Web Key Set (JWKS) terkait pada `/openid/v1/jwks`. OpenID Provider Configuration terkadang disebut juga dengan sebutan _discovery document_. + +Ketika diaktifkan, klaster juga dikonfigurasi dengan RBAC ClusterRole standar yaitu `system:service-account-issuer-discovery`. _Role binding_ tidak disediakan secara _default_. Administrator dimungkinkan untuk, sebagai contoh, menentukan apakah peran akan disematkan ke `system:authenticated` atau `system:unauthenticated` tergantung terhadap kebutuhan keamanan dan sistem eksternal yang direncakanan untuk diintegrasikan. + +{{< note >}} +Respons yang disediakan pada `/.well-known/openid-configuration` dan`/openid/v1/jwks` dirancang untuk kompatibel dengan OIDC, tetapi tidak sepenuhnya sesuai dengan ketentuan OIDC. Dokumen tersebut hanya berisi parameter yang dibutuhkan untuk melakukan validasi terhadap _token_ ServiceAccount Kubernetes. +{{< /note >}} + +Respons JWKS memuat kunci publik yang dapat digunakan oleh sistem eksternal untuk melakukan validasi _token_ ServiceAccount Kubernetes. Awalnya sistem eksternal akan mengkueri OpenID Provider Configuration, dan selanjutnya dapat menggunakan _field_ `jwks_uri` pada respons kueri untuk mendapatkan JWKS. + +Pada banyak kasus, server API Kubernetes tidak tersedia di internet publik, namun _endpoint_ publik yang menyediakan respons hasil _cache_ dari server API dapat dibuat menjadi tersedia oleh pengguna atau penyedia servis. Pada kasus ini, dimungkinkan untuk mengganti `jwks_uri` pada OpenID Provider Configuration untuk diarahkan ke _endpoint_ publik sebagai ganti alamat server API dengan memberikan _flag_ `--service-account-jwks-uri` ke API server. serupa dengan URL _issuer_, URI JWKS diharuskan untuk menggunakan skema `https`. + + +## {{% heading "whatsnext" %}} + + +Lihat juga: + +- [Panduan Admin Kluster mengenai ServiceAccount](/docs/reference/access-authn-authz/service-accounts-admin/) +- [ServiceAccount Signing Key Retrieval KEP](https://github.com/kubernetes/enhancements/blob/master/keps/sig-auth/20190730-oidc-discovery.md) +- [OIDC Discovery Spec](https://openid.net/specs/openid-connect-discovery-1_0.html) + + diff --git a/content/id/docs/tasks/configure-pod-container/pull-image-private-registry.md b/content/id/docs/tasks/configure-pod-container/pull-image-private-registry.md new file mode 100644 index 0000000000..50aad8de9a --- /dev/null +++ b/content/id/docs/tasks/configure-pod-container/pull-image-private-registry.md @@ -0,0 +1,212 @@ +--- +title: Menarik Image dari Register Pribadi +content_type: task +weight: 100 +--- + +<!-- overview --> + +Laman ini menunjukkan cara membuat Pod dengan menggunakan Secret untuk menarik _image_ dari sebuah +register atau repositori pribadi untuk Docker. + + +## {{% heading "prerequisites" %}} + + +* {{< include "task-tutorial-prereqs.md" >}} {{< version-check >}} + +* Untuk melakukan latihan ini, kamu memerlukan sebuah +[nama pengguna (ID) Docker](https://docs.docker.com/docker-id/) dan kata sandi (_password_). + + +<!-- steps --> + +## Masuk (_login_) ke Docker {#masuk-ke-docker} + +Pada laptop kamu, kamu harus melakukan autentikasi dengan register untuk menarik _image_ pribadi: + +```shell +docker login +``` + +Ketika diminta, masukkan nama pengguna dan kata sandi Docker kamu. + +Proses _login_ membuat atau memperbarui berkas `config.json` yang menyimpan sebuah _token_ otorisasi. + +Lihatlah berkas `config.json`: + + +```shell +cat ~/.docker/config.json +``` + +Keluaran berisi bagian yang serupa dengan ini: + +```json +{ + "auths": { + "https://index.docker.io/v1/": { + "auth": "c3R...zE2" + } + } +} +``` + +{{< note >}} +Jika kamu menggunakan tempat penyimpanan kredensial (_credential_) untuk Docker, maka kamu tidak akan melihat entri `auth` tetapi entri `credsStore` dengan nama tempat penyimpanan sebagai nilainya. +{{< /note >}} + +## Membuat Secret berdasarkan kredensial Docker yang sudah ada {#register-secret-kredensial-yang-ada} + +Klaster Kubernetes menggunakan Secret dari tipe `docker-registry` untuk melakukan autentikasi dengan +register Container untuk menarik _image_ pribadi. + +Jika kamu sudah menjalankan `docker login`, kamu dapat menyalin kredensial itu ke Kubernetes: + +```shell +kubectl create secret generic regcred \ + --from-file=.dockerconfigjson=<path/to/.docker/config.json> \ + --type=kubernetes.io/dockerconfigjson +``` + +Jika kamu memerlukan lebih banyak kontrol (misalnya, untuk mengatur Namespace atau label baru pada Secret) +maka kamu dapat menyesuaikan Secret tersebut sebelum menyimpannya. +Pastikan untuk: + + +- Mengatur nama dari pokok (_item_) data menjadi `.dockerconfigjson` +- Melakukan enkode secara _base64_ dari Dockerfile (berkas Docker) dan memindahkan urutan huruf (_string_) tersebut, secara tidak terputus sebagai nilai untuk bidang `data[".dockerconfigjson"]` +- Mengatur `type` menjadi `kubernetes.io/dockerconfigjson` + +Sebagai contoh: + +```yaml +apiVersion: v1 +kind: Secret +metadata: + name: myregistrykey + namespace: awesomeapps +data: + .dockerconfigjson: UmVhbGx5IHJlYWxseSByZWVlZWVlZWVlZWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWxsbGxsbGxsbGxsbGxsbGxsbGxsbGxsbGxsbGxsbGx5eXl5eXl5eXl5eXl5eXl5eXl5eSBsbGxsbGxsbGxsbGxsbG9vb29vb29vb29vb29vb29vb29vb29vb29vb25ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubmdnZ2dnZ2dnZ2dnZ2dnZ2dnZ2cgYXV0aCBrZXlzCg== +type: kubernetes.io/dockerconfigjson +``` + +Jika kamu mendapat pesan kesalahan `error: no objects passed to create`, ini berarti pengkodean _base64_ dari urutan huruf tersebut tidak valid. +Jika kamu mendapat pesan kesalahan seperti `Secret "myregistrykey" is invalid: data[.dockerconfigjson]: invalid value ...`, ini berarti +enkode _base64_ dari urutan huruf dalam data tersebut sukses didekodekan, tetapi tidak bisa diuraikan menjadi berkas `.docker/config.json`. + +## Membuat Secret dengan memberikan kredensial pada baris perintah + +Buatlah Secret ini, dan berilah nama `regcred`: + +```shell +kubectl create secret docker-registry regcred --docker-server=<your-registry-server> --docker-username=<your-name> --docker-password=<your-pword> --docker-email=<your-email> +``` + +dimana: + +* `<your-registry-server>` merupakan FQDN dari register privat Docker kamu. (https://index.docker.io/v1/ untuk DockerHub) +* `<your-name>` adalah nama pengguna Docker kamu. +* `<your-pword>` adalah kata sandi Docker kamu. +* `<your-email>` adalah alamat email Docker kamu. + +Kamu telah berhasil mengatur kredensial untuk Docker kamu pada klaster sebagai sebuah Secret yang dipanggil dengan nama `regcred`. + +{{< note >}} + +Mengetik Secret pada baris perintah dapat menyimpannya dalam riwayat (_history_) dari _shell_ kamu tanpa perlindungan, dan +Secret tersebut mungkin juga terlihat oleh pengguna lain dalam PC kamu selama perintah `kubectl` sedang berjalan. +{{< /note >}} + + +## Menginspeksi Secret `regcred` {#menginspeksi-secret-regcred} + +Untuk memahami isi Secret `regcred` yang baru saja kamu buat, mulailah dengan melihat Secret dalam format YAML: + +```shell +kubectl get secret regcred --output=yaml +``` +Keluarannya akan seperti ini: + +```yaml +apiVersion: v1 +kind: Secret +metadata: + ... + name: regcred + ... +data: + .dockerconfigjson: eyJodHRwczovL2luZGV4L ... J0QUl6RTIifX0= +type: kubernetes.io/dockerconfigjson +``` + +Nilai dari bidang `.dockerconfigjson` merupakan representasi dalam _base64_ dari kredensial Docker kamu. + +Untuk memahami apa yang ada dalam bidang `.dockerconfigjson`, ubahlah data Secret menjadi format yang bisa terbaca: + +```shell +kubectl get secret regcred --output="jsonpath={.data.\.dockerconfigjson}" | base64 --decode +``` + +Keluarannya akan seperti ini: + +```json +{"auths":{"your.private.registry.example.com":{"username":"janedoe","password":"xxxxxxxxxxx","email":"jdoe@example.com","auth":"c3R...zE2"}}} +``` + +Untuk memahami apa yang ada dalam bidang `auth`, ubahlah data Secret menjadi format yang bisa terbaca: + +```shell +echo "c3R...zE2" | base64 --decode +``` + +Keluarannya, nama pengguna dan kata sandi yang digabungkan dengan tanda `:`, seperti dibawah ini: + +```none +janedoe:xxxxxxxxxxx +``` + +Perhatikan bahwa data Secret berisi token otorisasi yang serupa dengan berkas `~/.docker/config.json` lokal kamu. + +Kamu telah berhasil menetapkan kredensial Docker kamu sebagai sebuah Secret yang dipanggil dengan `regcred` pada klaster. + + +## Membuat Pod yang menggunakan Secret kamu + + +Berikut ini adalah berkas konfigurasi untuk Pod yang memerlukan akses ke kredensial Docker kamu pada `regcred`: + +{{< codenew file="pods/private-reg-pod.yaml" >}} + +Unduh berkas diatas: + +```shell +wget -O my-private-reg-pod.yaml https://k8s.io/examples/pods/private-reg-pod.yaml +``` + +Dalam berkas `my-private-reg-pod.yaml`, ubah `<your-private-image>` dengan tautan ke _image_ dalam register pribadi seperti ini: + +```none +your.private.registry.example.com/janedoe/jdoe-private:v1 +``` + +Untuk menarik _image_ dari register pribadi, Kubernetes memerlukan kredensial. +Bidang `imagePullSecrets` dalam berkas konfigurasi menentukan bahwa Kubernetes harus mendapatkan kredensial dari Secret yang bernama `regcred`. + +Buatlah Pod yang menggunakan Secret kamu, dan verifikasi bahwa Pod tersebut berjalan: + +```shell +kubectl apply -f my-private-reg-pod.yaml +kubectl get pod private-reg +``` + + +## {{% heading "whatsnext" %}} + + +* Pelajari lebih lanjut tentang [Secret](/id/docs/concepts/configuration/secret/). +* Pelajari lebih lanjut tentang [menggunakan register pribadi](/id/docs/concepts/containers/images/#menggunakan-register-privat). +* Pelajari lebih lanjut tentang [menambahkan Secret untuk menarik _image_ ke dalam sebuah akun service](/id/docs/tasks/configure-pod-container/configure-service-account/#add-imagepullsecrets-to-a-service-account). +* Lihatlah [kubectl create secret docker-registry](/docs/reference/generated/kubectl/kubectl-commands/#-em-secret-docker-registry-em-). +* Lihatlah [Secret](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#secret-v1-core). +* Lihatlah bidang `imagePullSecrets` dari [PodSpec](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podspec-v1-core). diff --git a/content/id/docs/tasks/configure-pod-container/security-context.md b/content/id/docs/tasks/configure-pod-container/security-context.md index 6ea554f2d6..d190468399 100644 --- a/content/id/docs/tasks/configure-pod-container/security-context.md +++ b/content/id/docs/tasks/configure-pod-container/security-context.md @@ -1,10 +1,10 @@ --- title: Mengonfigurasi Konteks Keamanan untuk Pod atau Container -content_template: templates/task +content_type: task weight: 80 --- -{{% capture overview %}} +<!-- overview --> Konteks keamanan (_security context_) menentukan wewenang (_privilege_) dan aturan kontrol akses untuk sebuah Pod atau Container. Aturan konteks keamanan meliputi hal-hal berikut ini namun tidak terbatas pada hal-hal tersebut: @@ -31,15 +31,16 @@ Poin-poin di atas bukanlah sekumpulan lengkap dari aturan konteks keamanan - sil Untuk informasi lebih lanjut tentang mekanisme keamanan pada Linux, silahkan lihat [ikhtisar fitur keamanan pada Kernel Linux](https://www.linux.com/learn/overview-linux-kernel-security-features) -{{% /capture %}} -{{% capture prerequisites %}} + +## {{% heading "prerequisites" %}} + {{< include "task-tutorial-prereqs.md" >}} {{< version-check >}} -{{% /capture %}} -{{% capture steps %}} + +<!-- steps --> ## Mengatur konteks keamanan untuk Pod @@ -401,16 +402,17 @@ kubectl delete pod security-context-demo-3 kubectl delete pod security-context-demo-4 ``` -{{% /capture %}} -{{% capture whatsnext %}} + +## {{% heading "whatsnext" %}} + * [PodSecurityContext](/docs/reference/generated/kubernetes-api/{{<param"version">}}/#podsecuritycontext-v1-core) * [SecurityContext](/docs/reference/generated/kubernetes-api/{{<param"version">}}/#securitycontext-v1-core) * [Menyetel Docker dengan peningkatan keamanan terbaru](https://opensource.com/business/15/3/docker-security-tuning) * [Dokumen desain konteks keamanan](https://git.k8s.io/community/contributors/design-proposals/auth/security_context.md) * [Dokumen desain manajemen kepemilikan](https://git.k8s.io/community/contributors/design-proposals/storage/volume-ownership-management.md) -* [Kebijakan keamanan Pod](/docs/concepts/policy/pod-security-policy/) +* [Kebijakan keamanan Pod](/id/docs/concepts/policy/pod-security-policy/) * [Dokumen desain AllowPrivilegeEscalation](https://git.k8s.io/community/contributors/design-proposals/auth/no-new-privs.md) -{{% /capture %}} + diff --git a/content/id/docs/tasks/configure-pod-container/share-process-namespace.md b/content/id/docs/tasks/configure-pod-container/share-process-namespace.md new file mode 100644 index 0000000000..9b32d74b3c --- /dev/null +++ b/content/id/docs/tasks/configure-pod-container/share-process-namespace.md @@ -0,0 +1,118 @@ +--- +title: Pembagian Namespace Proses antar Container pada sebuah Pod +min-kubernetes-server-version: v1.10 +content_type: task +weight: 160 +--- + +<!-- overview --> + +{{< feature-state state="stable" for_k8s_version="v1.17" >}} + +Dokumen ini akan menjelaskan menkanisme konfigurasi pembagian namespace +process dalam sebuah Pod. Ketika pembagian _namespace_ proses diaktifkan untuk sebuah Pod, +proses yang ada di dalam Container akan bersifat transparan pada semua Container +yang terdapat di dalam Pod tersebut. + +Kamu dapat mengaktifkan fitur ini untuk melakukan konfigurasi kontainer yang saling terhubung, +misalnya saja kontainer _sidecar_ yang bertugas dalam urusan log, atau untuk melakukan +proses pemecahan masalah (_troubleshoot_) image kontainer yang tidak memiliki utilitas _debugging_ seperti shell. + + + +## {{% heading "prerequisites" %}} + + +{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}} + + + +<!-- steps --> + +## Mengatur sebuah Pod + +Pembagian _namespace_ proses (_Process Namespace Sharing_) diaktifkan menggunakan _field_ `shareProcessNamespace` +`v1.PodSpec`. Sebagai contoh: + +{{< codenew file="pods/share-process-namespace.yaml" >}} + +1. Buatlah sebuah Pod `nginx` di dalam klaster kamu: + + ```shell + kubectl apply -f https://k8s.io/examples/pods/share-process-namespace.yaml + ``` + +2. Tempelkan kontainer `shell` dan jalankan perintah `ps`: + + ```shell + kubectl attach -it nginx -c shell + ``` + + Jika kamu tidak melihat _prompt_ perintah, kamu dapat menekan tombol enter: + + ``` + / # ps ax + PID USER TIME COMMAND + 1 root 0:00 /pause + 8 root 0:00 nginx: master process nginx -g daemon off; + 14 101 0:00 nginx: worker process + 15 root 0:00 sh + 21 root 0:00 ps ax + ``` + +Kamu dapat memberikan sinyal pada kontainer lain. Misalnya saja, mengirim sinyal `SIGHUP` pada +nginx untuk menjalankan ulang proses worker. Hal ini membutuhkan kapabilitas `SYS_PTRACE`. + +``` +/ # kill -HUP 8 +/ # ps ax +PID USER TIME COMMAND + 1 root 0:00 /pause + 8 root 0:00 nginx: master process nginx -g daemon off; + 15 root 0:00 sh + 22 101 0:00 nginx: worker process + 23 root 0:00 ps ax +``` + +Hal ini juga merupakan alasan mengapa kita dapat mengakses kontainer lain menggunakan +tautan (_link_) `/proc/$pid/root`. + +``` +/ # head /proc/8/root/etc/nginx/nginx.conf + +user nginx; +worker_processes 1; + +error_log /var/log/nginx/error.log warn; +pid /var/run/nginx.pid; + + +events { + worker_connections 1024; +``` + + + +<!-- discussion --> + +## Memahami Pembagian Namespace Process + +Pod berbagi banyak sumber daya yang ada sehingga memungkinkan adanya pembagian _namespace_ +proses. Beberapa _image_ kontainer bisa jadi terisolasi dari kontainer lainnya, +meskipun begitu, memahami beberapa perbedaan berikut juga merupakan hal yang +penting untuk diketahui: + +1. **Proses kontainer tidak lagi memiliki PID 1.** Beberapa image kontainer akan menolak + untuk dijalankan (contohnya, kontainer yang menggunakan `systemd`) atau menjalankan + perintah seperti `kill -HUP 1` untuk memberikan sinyal pada proses kontainer. Di dalam Pod dengan + sebuah namespace process terbagi, sinyal `kill -HUP 1` akan diberikan pada _sandbox_ Pod. + (`/pause` pada contoh di atas.) + +2. **Proses-proses yang ada akan transparan pada kontainer lain di dalam Pod.** Hal ini termasuk + informasi pada `/proc`, seperti kata sandi yang diberikan sebagai argumen atau _environment variable_. + Hal ini hanya dilindungi oleh perizinan reguler Unix. + +3. **Berkas sistem (_filesystem_) kontainer bersifat transparan pada kontainer lain di dalam Pod melalui link + `/proc/$pid/root`.** Hal ini memungkinkan proses _debugging_ menjadi lebih mudah, meskipun begitu hal ini + juga berarti kata kunci (_secret_) yang ada di dalam _filesystem_ juga hanya dilindungi oleh perizinan _filesystem_ saja. + diff --git a/content/id/docs/tasks/debug-application-cluster/_index.md b/content/id/docs/tasks/debug-application-cluster/_index.md new file mode 100755 index 0000000000..a99e0b6580 --- /dev/null +++ b/content/id/docs/tasks/debug-application-cluster/_index.md @@ -0,0 +1,6 @@ +--- +title: "Pemantauan, Pencatatan, and Debugging" +description: Mengatur pemantauan dan pencatatan untuk memecahkan masalah klaster, atau men-_debug_ aplikasi yang terkontainerisasi. +weight: 80 +--- + diff --git a/content/id/docs/tasks/debug-application-cluster/get-shell-running-container.md b/content/id/docs/tasks/debug-application-cluster/get-shell-running-container.md index 39d2317de5..e15a8a4df6 100644 --- a/content/id/docs/tasks/debug-application-cluster/get-shell-running-container.md +++ b/content/id/docs/tasks/debug-application-cluster/get-shell-running-container.md @@ -1,24 +1,25 @@ --- title: Mendapatkan Shell Untuk Masuk ke Container yang Sedang Berjalan -content_template: templates/task +content_type: task --- -{{% capture overview %}} +<!-- overview --> Laman ini menunjukkan bagaimana cara menggunakan `kubectl exec` untuk mendapatkan _shell_ untuk masuk ke dalam Container yang sedang berjalan. -{{% /capture %}} -{{% capture prerequisites %}} + +## {{% heading "prerequisites" %}} + {{< include "task-tutorial-prereqs.md" >}} {{< version-check >}} -{{% /capture %}} -{{% capture steps %}} + +<!-- steps --> ## Mendapatkan sebuah _shell_ untuk masuk ke sebuah Container @@ -118,9 +119,9 @@ kubectl exec shell-demo ls / kubectl exec shell-demo cat /proc/1/mounts ``` -{{% /capture %}} -{{% capture discussion %}} + +<!-- discussion --> ## Membuka sebuah _shell_ ketika sebuah Pod memiliki lebih dari satu Container @@ -134,14 +135,15 @@ _shell_ ke Container dengan nama main-app. kubectl exec -it my-pod --container main-app -- /bin/bash ``` -{{% /capture %}} -{{% capture whatsnext %}} + +## {{% heading "whatsnext" %}} + * [kubectl exec](/docs/reference/generated/kubectl/kubectl-commands/#exec) -{{% /capture %}} + diff --git a/content/id/docs/tasks/debug-application-cluster/resource-usage-monitoring.md b/content/id/docs/tasks/debug-application-cluster/resource-usage-monitoring.md new file mode 100644 index 0000000000..eeb16411d2 --- /dev/null +++ b/content/id/docs/tasks/debug-application-cluster/resource-usage-monitoring.md @@ -0,0 +1,57 @@ +--- +content_type: concept +title: Perangkat untuk Memantau Sumber Daya +--- + +<!-- overview --> + +Untuk melukan penyekalaan aplikasi dan memberikan Service yang handal, kamu perlu +memahami bagaimana aplikasi berperilaku ketika aplikasi tersebut digelar (_deploy_). Kamu bisa memeriksa +kinerja aplikasi dalam klaster Kubernetes dengan memeriksa Container, +[Pod](/docs/user-guide/pods), [Service](/docs/user-guide/services), dan +karakteristik klaster secara keseluruhan. Kubernetes memberikan detail +informasi tentang penggunaan sumber daya dari aplikasi pada setiap level ini. +Informasi ini memungkinkan kamu untuk mengevaluasi kinerja aplikasi kamu dan +mengevaluasi di mana kemacetan dapat dihilangkan untuk meningkatkan kinerja secara keseluruhan. + + + +<!-- body --> + +Di Kubernetes, pemantauan aplikasi tidak bergantung pada satu solusi pemantauan saja. Pada klaster baru, kamu bisa menggunakan _pipeline_ [metrik sumber daya](#pipeline-metrik-sumber-daya) atau _pipeline_ [metrik penuh](#pipeline-metrik-penuh) untuk mengumpulkan statistik pemantauan. + +## _Pipeline_ Metrik Sumber Daya + +_Pipeline_ metrik sumber daya menyediakan sekumpulan metrik terbatas yang terkait dengan +komponen-komponen klaster seperti _controller_ [HorizontalPodAutoscaler](/id/docs/tasks/run-application/horizontal-pod-autoscaler), begitu juga dengan utilitas `kubectl top`. +Metrik ini dikumpulkan oleh memori yang ringan, jangka pendek, dalam +[_metrics-server_](https://github.com/kubernetes-incubator/metrics-server) dan +diekspos ke API `metrics.k8s.io`. + +_Metrics-server_ menemukan semua Node dalam klaster dan +bertanya ke setiap +[kubelet](/docs/reference/command-line-tools-reference/kubelet) dari Node tentang penggunaan CPU dan +memori. Kubelet bertindak sebagai jembatan antara _control plane_ Kubernetes dan +Node, mengelola Pod dan Container yang berjalan pada sebuah mesin. Kubelet +menerjemahkan setiap Pod ke Container yang menyusunnya dan mengambil masing-masing +statistik penggunaan untuk setiap Container dari _runtime_ Container melalui +antarmuka _runtime_ Container. Kubelet mengambil informasi ini dari cAdvisor yang terintegrasi +untuk pengintegrasian Docker yang lama. Hal ini yang kemudian memperlihatkan +statistik penggunaan sumber daya dari kumpulan Pod melalui API sumber daya _metrics-server_. +API ini disediakan pada `/metrics/resource/v1beta1` pada kubelet yang terautentikasi dan +porta _read-only_. + +## _Pipeline_ Metrik Penuh + +_Pipeline_ metrik penuh memberi kamu akses ke metrik yang lebih banyak. Kubernetes bisa +menanggapi metrik ini secara otomatis dengan mengubah skala atau mengadaptasi klaster +berdasarkan kondisi saat ini, dengan menggunakan mekanisme seperti HorizontalPodAutoscaler. +_Pipeline_ pemantauan mengambil metrik dari kubelet dan +kemudian memgekspos ke Kubernetes melalui adaptor dengan mengimplementasikan salah satu dari API +`custom.metrics.k8s.io` atau API `external.metrics.k8s.io`. + + +[Prometheus](https://prometheus.io), sebuah proyek CNCF, yang dapat secara alami memonitor Kubernetes, Node, dan Prometheus itu sendiri. +Proyek _pipeline_ metrik penuh yang bukan merupakan bagian dari CNCF berada di luar ruang lingkup dari dokumentasi Kubernetes. + + diff --git a/content/id/docs/tasks/inject-data-application/define-command-argument-container.md b/content/id/docs/tasks/inject-data-application/define-command-argument-container.md index 28a3a1d7e9..9f2cd7a7ae 100644 --- a/content/id/docs/tasks/inject-data-application/define-command-argument-container.md +++ b/content/id/docs/tasks/inject-data-application/define-command-argument-container.md @@ -1,26 +1,27 @@ --- title: Mendefinisikan Perintah dan Argumen untuk sebuah Kontainer -content_template: templates/task +content_type: task weight: 10 --- -{{% capture overview %}} +<!-- overview --> Laman ini menunjukkan bagaimana cara mendefinisikan perintah-perintah dan argumen-argumen saat kamu menjalankan Container dalam sebuah {{< glossary_tooltip term_id="Pod" >}}. -{{% /capture %}} -{{% capture prerequisites %}} + +## {{% heading "prerequisites" %}} + {{< include "task-tutorial-prereqs.md" >}} {{< version-check >}} -{{% /capture %}} -{{% capture steps %}} + +<!-- steps --> ## Mendefinisikan sebuah perintah dan argumen-argumen saat kamu membuat sebuah Pod @@ -145,12 +146,13 @@ Berikut ini beberapa contoh: | `[/ep-1]` | `[foo bar]` | `[/ep-2]` | `[zoo boo]` | `[ep-2 zoo boo]` | -{{% /capture %}} -{{% capture whatsnext %}} + +## {{% heading "whatsnext" %}} + * Pelajari lebih lanjut tentang [mengatur Pod and Container](/id/docs/tasks/). * Pelajari lebih lanjut tentang [menjalankan perintah di dalam sebuah Container](/id/docs/tasks/debug-application-cluster/get-shell-running-container/). * Lihat [Container](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#container-v1-core). -{{% /capture %}} + diff --git a/content/id/docs/tasks/job/automated-tasks-with-cron-jobs.md b/content/id/docs/tasks/job/automated-tasks-with-cron-jobs.md index 2139f51629..c2c4b9399f 100644 --- a/content/id/docs/tasks/job/automated-tasks-with-cron-jobs.md +++ b/content/id/docs/tasks/job/automated-tasks-with-cron-jobs.md @@ -16,7 +16,7 @@ CronJob memiliki keterbatasan dan kekhasan. Misalnya, dalam keadaan tertentu, sebuah CronJob dapat membuat banyak Job. Karena itu, Job haruslah _idempotent._ -Untuk informasi lanjut mengenai keterbatasan, lihat [CronJob](/docs/concepts/workloads/controllers/cron-jobs). +Untuk informasi lanjut mengenai keterbatasan, lihat [CronJob](/id/docs/concepts/workloads/controllers/cron-jobs). @@ -127,7 +127,7 @@ kubectl delete cronjob hello ``` Menghapus CronJob akan menghapus semua Job dan Pod yang telah terbuat dan menghentikanya dari pembuatan Job tambahan. -Kamu dapat membaca lebih lanjut tentang menghapus Job di [_garbage collection_](/docs/concepts/workloads/controllers/garbage-collection/). +Kamu dapat membaca lebih lanjut tentang menghapus Job di [_garbage collection_](/id/docs/concepts/workloads/controllers/garbage-collection/). ## Menulis Speifikasi Sebuah Cron @@ -162,8 +162,8 @@ Sebuah tanda tanya (`?`) dalam penjadwalan memiliki makna yang sama dengan tanda ### Templat Job `.spec.JobTemplate` adalah templat untuk sebuah Job, dan itu wajib. -Templat Job memiliki skema yang sama dengan [Job](/docs/concepts/workloads/controllers/jobs-run-to-completion/), kecuali jika bersarang dan tidak memiliki sebuah `apiVersion` atau `kind`. -Untuk informasi lebih lanjut tentang menulis sebuah Job `.spec` lihat [Menulis spesifikasi Job](/docs/concepts/workloads/controllers/jobs-run-to-completion/#writing-a-job-spec). +Templat Job memiliki skema yang sama dengan [Job](/id/docs/concepts/workloads/controllers/jobs-run-to-completion/), kecuali jika bersarang dan tidak memiliki sebuah `apiVersion` atau `kind`. +Untuk informasi lebih lanjut tentang menulis sebuah Job `.spec` lihat [Menulis spesifikasi Job](/id/docs/concepts/workloads/controllers/jobs-run-to-completion/#writing-a-job-spec). ### _Starting Deadline_ diff --git a/content/id/docs/tasks/manage-daemon/_index.md b/content/id/docs/tasks/manage-daemon/_index.md new file mode 100644 index 0000000000..c3044a9265 --- /dev/null +++ b/content/id/docs/tasks/manage-daemon/_index.md @@ -0,0 +1,6 @@ +--- +title: "Mengelola Daemon Klaster" +description: Melakukan tugas-tugas umum untuk mengelola sebuah DaemonSet, misalnya _rolling update_. +weight: 130 +--- + diff --git a/content/id/docs/tasks/manage-daemon/rollback-daemon-set.md b/content/id/docs/tasks/manage-daemon/rollback-daemon-set.md new file mode 100644 index 0000000000..dcc030289d --- /dev/null +++ b/content/id/docs/tasks/manage-daemon/rollback-daemon-set.md @@ -0,0 +1,140 @@ +--- +title: Melakukan Rollback pada DaemonSet +content_type: task +weight: 20 +min-kubernetes-server-version: 1.7 +--- + +<!-- overview --> + +Laman ini memperlihatkan bagaimana caranya untuk melakukan _rollback_ pada sebuah {{< glossary_tooltip term_id="daemonset" >}}. + + +## {{% heading "prerequisites" %}} + +{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}} + +Sebelum lanjut, alangkah baiknya jika kamu telah mengetahui cara +untuk [melakukan _rolling update_ pada sebuah DaemonSet](/docs/tasks/manage-daemon/update-daemon-set/). + +<!-- steps --> + +## Melakukan _rollback_ pada DaemonSet + +### Langkah 1: Dapatkan nomor revisi DaemonSet yang ingin dikembalikan + +Lompati langkah ini jika kamu hanya ingin kembali (_rollback_) ke revisi terakhir. + +Perintah di bawah ini akan memperlihatkan daftar semua revisi dari DaemonSet: + +```shell +kubectl rollout history daemonset <nama-daemonset> +``` + +Perintah tersebut akan menampilkan daftar revisi seperti di bawah: + +``` +daemonsets "<nama-daemonset>" +REVISION CHANGE-CAUSE +1 ... +2 ... +... +``` + +* Alasan perubahan (_change cause_) kolom di atas merupakan salinan dari anotasi `kubernetes.io/change-cause` yang berkaitan dengan revisi pada DaemonSet. Kamu boleh menyetel _flag_ `--record=true` melalui `kubectl` untuk merekam perintah yang dijalankan akibat dari anotasi alasan perubahan. + +Untuk melihat detail dari revisi tertentu, jalankan perintah di bawah ini: + +```shell +kubectl rollout history daemonset <daemonset-name> --revision=1 +``` + +Perintah tersebut memberikan detail soal nomor revisi tertentu: + +``` +daemonsets "<nama-daemonset>" with revision #1 +Pod Template: +Labels: foo=bar +Containers: +app: + Image: ... + Port: ... + Environment: ... + Mounts: ... +Volumes: ... +``` + +### Langkah 2: _Rollback_ ke revisi tertentu + +```shell +# Tentukan nomor revisi yang kamu dapatkan dari Langkah 1 melalui --to-revision +kubectl rollout undo daemonset <nama-daemonset> --to-revision=<nomor-revisi> +``` + +Jika telah berhasil, perintah tersebut akan memberikan keluaran berikut: + +``` +daemonset "<nama-daemonset>" rolled back +``` + +{{< note >}} +Jika _flag_ `--to-revision` tidak diberikan, maka kubectl akan memilihkan revisi yang terakhir. +{{< /note >}} + +### Langkah 3: Lihat progres pada saat _rollback_ DaemonSet + +Perintah `kubectl rollout undo daemonset` memberitahu server untuk memulai _rollback_ DaemonSet. +_Rollback_ sebenarnya terjadi secara _asynchronous_ di dalam klaster {{< glossary_tooltip term_id="control-plane" text="_control plane_" >}}. + +Perintah di bawah ini dilakukan untuk melihat progres dari _rollback_: + +```shell +kubectl rollout status ds/<nama-daemonset> +``` + +Ketika _rollback_ telah selesai dilakukan, keluaran di bawah akan ditampilkan: + +``` +daemonset "<nama-daemonset>" successfully rolled out +``` + + +<!-- discussion --> + +## Memahami revisi DaemonSet + +Pada langkah `kubectl rollout history` sebelumnya, kamu telah mendapatkan +daftar revisi DaemonSet. Setiap revisi disimpan di dalam sumber daya bernama ControllerRevision. + +Untuk melihat apa yang disimpan pada setiap revisi, dapatkan sumber daya mentah (_raw_) dari +revisi DaemonSet: + +```shell +kubectl get controllerrevision -l <kunci-selektor-daemonset>=<nilai-selektor-daemonset> +``` + +Perintah di atas akan mengembalikan daftar ControllerRevision: + +``` +NAME CONTROLLER REVISION AGE +<nama-daemonset>-<hash-revisi> DaemonSet/<nama-daemonset> 1 1h +<nama-daemonset>-<hash-revisi> DaemonSet/<nama-daemonset> 2 1h +``` + +Setiap ControllerRevision menyimpan anotasi dan templat dari sebuah revisi DaemonSet. + +Perintah `kubectl rollout undo` mengambil ControllerRevision yang spesifik dan mengganti templat +DaemonSet dengan templat yang tersimpan pada ControllerRevision. +Perintah `kubectl rollout undo` sama seperti untuk memperbarui templat +DaemonSet ke revisi sebelumnya dengan menggunakan perintah lainnya, seperti `kubectl edit` atau `kubectl apply`. + +{{< note >}} +Revisi DaemonSet hanya bisa _roll_ ke depan. Artinya, setelah _rollback_ selesai dilakukan, +nomor revisi dari ControllerRevision (_field_ `.revision`) yang sedang di-_rollback_ akan maju ke depan. +Misalnya, jika kamu memiliki revisi 1 dan 2 pada sistem, lalu _rollback_ dari revisi 2 ke revisi 1, +ControllerRevision dengan `.revision: 1` akan menjadi `.revision: 3`. +{{< /note >}} + +## _Troubleshoot_ + +* Lihat cara untuk melakukan [_troubleshoot rolling update_ pada DaemonSet](/docs/tasks/manage-daemon/update-daemon-set/#troubleshooting). diff --git a/content/id/docs/tasks/manage-kubernetes-objects/_index.md b/content/id/docs/tasks/manage-kubernetes-objects/_index.md new file mode 100644 index 0000000000..26a982813e --- /dev/null +++ b/content/id/docs/tasks/manage-kubernetes-objects/_index.md @@ -0,0 +1,5 @@ +--- +title: "Mengelola Objek Kubernetes" +description: Paradigma deklaratif dan imperatif untuk berinteraksi dengan API Kubernetes. +weight: 25 +--- \ No newline at end of file diff --git a/content/id/docs/tasks/manage-kubernetes-objects/kustomization.md b/content/id/docs/tasks/manage-kubernetes-objects/kustomization.md new file mode 100644 index 0000000000..680b20d371 --- /dev/null +++ b/content/id/docs/tasks/manage-kubernetes-objects/kustomization.md @@ -0,0 +1,841 @@ +--- +title: Mengelola Objek Kubernetes secara Deklaratif menggunakan Kustomize +content_type: task +weight: 20 +--- + +<!-- overview --> + +[Kustomize](https://github.com/kubernetes-sigs/kustomize) merupakan sebuah alat +untuk melakukan kustomisasi objek Kubernetes melalui sebuah berkas [berkas kustomization](https://github.com/kubernetes-sigs/kustomize/blob/master/docs/glossary.md#kustomization). + +Sejak versi 1.14, kubectl mendukung pengelolaan objek Kubernetes melalui berkas kustomization. +Untuk melihat sumber daya yang ada di dalam direktori yang memiliki berkas kustomization, jalankan perintah berikut: + +```shell +kubectl kustomize <direktori_kustomization> +``` + +Untuk menerapkan sumber daya tersebut, jalankan perintah `kubectl apply` dengan _flag_ `--kustomize` atau `-k`: + +```shell +kubectl apply -k <kustomization_directory> +``` + + + +## {{% heading "prerequisites" %}} + + +Instal [`kubectl`](/id/docs/tasks/tools/install-kubectl/) terlebih dahulu. + +{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}} + + + +<!-- steps --> + +## Gambaran Umum Kustomize + +Kustomize adalah sebuah alat untuk melakukan kustomisasi konfigurasi Kubernetes. Untuk mengelola berkas-berkas konfigurasi, kustomize memiliki fitur -fitur di bawah ini: + +* membangkitkan (_generate_) sumber daya dari sumber lain +* mengatur _field_ dari berbagai sumber daya yang bersinggungan +* mengkomposisikan dan melakukan kustomisasi sekelompok sumber daya + +### Membangkitkan Sumber Daya + +ConfigMap dan Secret menyimpan konfigurasi atau data sensitif yang digunakan oleh objek-objek Kubernetes lainnya, seperti Pod. +Biasanya, _source of truth_ dari ConfigMap atau Secret berasal dari luar klaster, seperti berkas `.properties` atau berkas kunci SSH. +Kustomize memiliki `secretGenerator` dan `configMapGenerator`, yang akan membangkitkan (_generate_) Secret dan ConfigMap dari berkas-berkas atau nilai-nilai literal. + +#### configMapGenerator + +Untuk membangkitkan sebuah ConfigMap dari berkas, tambahkan entri ke daftar `files` pada `configMapGenerator`. +Contoh di bawah ini membangkitkan sebuah ConfigMap dengan data dari berkas `.properties`: + +```shell +# Membuat berkas application.properties +cat <<EOF >application.properties +FOO=Bar +EOF + +cat <<EOF >./kustomization.yaml +configMapGenerator: +- name: example-configmap-1 + files: + - application.properties +EOF +``` + +ConfigMap yang telah dibangkitkan dapat dilihat menggunakan perintah berikut: + +```shell +kubectl kustomize ./ +``` + +Isinya seperti di bawah ini: + +```yaml +apiVersion: v1 +data: + application.properties: | + FOO=Bar +kind: ConfigMap +metadata: + name: example-configmap-1-8mbdf7882g +``` + +ConfigMap juga dapat dibangkitkan dari pasangan _key-value_ literal. Untuk membangkitkan secara literal, tambahkan entri pada daftar `literals` di `configMapGenerator`. +Contoh di bawah ini membangkitkan ConfigMap dengan data dari pasangan _key-value_: + +```shell +cat <<EOF >./kustomization.yaml +configMapGenerator: +- name: example-configmap-2 + literals: + - FOO=Bar +EOF +``` + +ConfigMap yang dibangkitkan dapat dilihat menggunakan perintah berikut: + +```shell +kubectl kustomize ./ +``` + +Isinya seperti ini: + +```yaml +apiVersion: v1 +data: + FOO: Bar +kind: ConfigMap +metadata: + name: example-configmap-2-g2hdhfc6tk +``` + +#### secretGenerator + +Kamu dapat membangkitkan Secret dari berkas atau pasangan _key-value_ literal. Untuk membangkitkan dari berkas, tambahkan entri pada daftar `files` di `secretGenerator`. +Contoh di bawah ini membangkitkan Secret dengan data dari berkas: + +```shell +# Membuat berkas password.txt +cat <<EOF >./password.txt +username=admin +password=secret +EOF + +cat <<EOF >./kustomization.yaml +secretGenerator: +- name: example-secret-1 + files: + - password.txt +EOF +``` + +Isinya seperti ini: + +```yaml +apiVersion: v1 +data: + password.txt: dXNlcm5hbWU9YWRtaW4KcGFzc3dvcmQ9c2VjcmV0Cg== +kind: Secret +metadata: + name: example-secret-1-t2kt65hgtb +type: Opaque +``` + +Untuk membangkitkan secara literal dari pasangan _key-value_, tambahkan entri pada daftar `literals` di `secretGenerator`. +Contoh di bawah ini membangkitkan Secret dengan data dari pasangan _key-value_: + +```shell +cat <<EOF >./kustomization.yaml +secretGenerator: +- name: example-secret-2 + literals: + - username=admin + - password=secret +EOF +``` + +Isinya seperti ini: + +```yaml +apiVersion: v1 +data: + password: c2VjcmV0 + username: YWRtaW4= +kind: Secret +metadata: + name: example-secret-2-t52t6g96d8 +type: Opaque +``` + +#### generatorOptions + +ConfigMap dan Secret yang dibangkitkan memiliki informasi sufiks _hash_. Hal ini memastikan bahwa ConfigMap atau Secret yang baru, dibangkitkan saat isinya berubah. +Untuk menonaktifkan penambahan sufiks ini, kamu bisa menggunakan `generatorOptions`. Selain itu, melalui _field_ ini kamu juga bisa mengatur opsi-opsi yang bersinggungan untuk ConfigMap dan Secret yang dibangkitkan. + +```shell +cat <<EOF >./kustomization.yaml +configMapGenerator: +- name: example-configmap-3 + literals: + - FOO=Bar +generatorOptions: + disableNameSuffixHash: true + labels: + type: generated + annotations: + note: generated +EOF +``` + +Jalankan perintah `kubectl kustomize ./` untuk melihat ConfigMap yang dibangkitkan: + +```yaml +apiVersion: v1 +data: + FOO: Bar +kind: ConfigMap +metadata: + annotations: + note: generated + labels: + type: generated + name: example-configmap-3 +``` + +### Mengatur _field_ yang bersinggungan + +Mengatur _field-field_ yang bersinggungan untuk semua sumber daya Kubernetes dalam sebuah proyek. +Beberapa contoh kasusnya seperti di bawah ini: + +* mengatur Namespace yang sama untuk semua sumber daya +* menambahkan prefiks atau sufiks yang sama +* menambahkan kumpulan label yang sama +* menambahkan kumpulan anotasi yang sama + +Lihat contoh di bawah ini: + +```shell +# Membuat sebuah deployment.yaml +cat <<EOF >./deployment.yaml +apiVersion: apps/v1 +kind: Deployment +metadata: + name: nginx-deployment + labels: + app: nginx +spec: + selector: + matchLabels: + app: nginx + template: + metadata: + labels: + app: nginx + spec: + containers: + - name: nginx + image: nginx +EOF + +cat <<EOF >./kustomization.yaml +namespace: my-namespace +namePrefix: dev- +nameSuffix: "-001" +commonLabels: + app: bingo +commonAnnotations: + oncallPager: 800-555-1212 +resources: +- deployment.yaml +EOF +``` + +Jalankan perintah `kubectl kustomize ./` untuk melihat _field-field_ tersebut telah terisi di dalam sumber daya Deployment: + +```yaml +apiVersion: apps/v1 +kind: Deployment +metadata: + annotations: + oncallPager: 800-555-1212 + labels: + app: bingo + name: dev-nginx-deployment-001 + namespace: my-namespace +spec: + selector: + matchLabels: + app: bingo + template: + metadata: + annotations: + oncallPager: 800-555-1212 + labels: + app: bingo + spec: + containers: + - image: nginx + name: nginx +``` + +### Mengkomposisi dan Melakukan Kustomisasi Sumber Daya + +Mengkomposisi kumpulan sumber daya dalam sebuah proyek dan mengelolanya di dalam berkas atau direktori yang sama merupakan hal yang cukup umum dilakukan. +Kustomize menyediakan cara untuk mengkomposisi sumber daya dari berkas-berkas yang berbeda, lalu menerapkan _patch_ atau kustomisasi lain di atasnya. + +#### Melakukan Komposisi + +Kustomize mendukung komposisi dari berbagai sumber daya yang berbeda. _Field_ `resources` pada berkas `kustomization.yaml`, mendefinisikan daftar sumber daya yang diinginkan dalam sebuah konfigurasi. Atur terlebih dahulu jalur (_path_) ke berkas konfigurasi sumber daya pada daftar `resources`. +Contoh di bawah ini merupakan sebuah aplikasi NGINX yang terdiri dari sebuah Deployment dan sebuah Service: + +```shell +# Membuat berkas deployment.yaml +cat <<EOF > deployment.yaml +apiVersion: apps/v1 +kind: Deployment +metadata: + name: my-nginx +spec: + selector: + matchLabels: + run: my-nginx + replicas: 2 + template: + metadata: + labels: + run: my-nginx + spec: + containers: + - name: my-nginx + image: nginx + ports: + - containerPort: 80 +EOF + +# Membuat berkas service.yaml +cat <<EOF > service.yaml +apiVersion: v1 +kind: Service +metadata: + name: my-nginx + labels: + run: my-nginx +spec: + ports: + - port: 80 + protocol: TCP + selector: + run: my-nginx +EOF + +# Membuat berkas kustomization.yaml yang terdiri dari keduanya +cat <<EOF >./kustomization.yaml +resources: +- deployment.yaml +- service.yaml +EOF +``` + +Sumber daya dari `kubectl kustomize ./` berisi kedua objek Deployment dan Service. + +#### Melakukan Kustomisasi + +_Patch_ dapat digunakan untuk menerapkan berbagai macam kustomisasi pada sumber daya. Kustomize mendukung berbagai mekanisme _patching_ yang berbeda melalui `patchesStrategicMerge` dan `patchesJson6902`. `patchesStrategicMerge` adalah daftar dari yang berisi tentang _path_ berkas. Setiap berkas akan dioperasikan dengan cara [strategic merge patch](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-api-machinery/strategic-merge-patch.md). Nama di dalam _patch_ harus sesuai dengan nama sumber daya yang telah dimuat. Kami menyarankan _patch-patch_ kecil yang hanya melakukan satu hal saja. +Contoh membuat sebuah _patch_ di bawah ini akan menambahkan jumlah replika Deployment dan _patch_ lainnya untuk mengatur limit memori. + +```shell +# Membuat berkas deployment.yaml +cat <<EOF > deployment.yaml +apiVersion: apps/v1 +kind: Deployment +metadata: + name: my-nginx +spec: + selector: + matchLabels: + run: my-nginx + replicas: 2 + template: + metadata: + labels: + run: my-nginx + spec: + containers: + - name: my-nginx + image: nginx + ports: + - containerPort: 80 +EOF + +# Membuat sebuah patch increase_replicas.yaml +cat <<EOF > increase_replicas.yaml +apiVersion: apps/v1 +kind: Deployment +metadata: + name: my-nginx +spec: + replicas: 3 +EOF + +# Membuat patch lainnya set_memory.yaml +cat <<EOF > set_memory.yaml +apiVersion: apps/v1 +kind: Deployment +metadata: + name: my-nginx +spec: + template: + spec: + containers: + - name: my-nginx + resources: + limits: + memory: 512Mi +EOF + +cat <<EOF >./kustomization.yaml +resources: +- deployment.yaml +patchesStrategicMerge: +- increase_replicas.yaml +- set_memory.yaml +EOF +``` + +Jalankan perintah `kubectl kustomize ./` untuk melihat isi dari Deployment: + +```yaml +apiVersion: apps/v1 +kind: Deployment +metadata: + name: my-nginx +spec: + replicas: 3 + selector: + matchLabels: + run: my-nginx + template: + metadata: + labels: + run: my-nginx + spec: + containers: + - image: nginx + limits: + memory: 512Mi + name: my-nginx + ports: + - containerPort: 80 +``` + +Tidak semua sumber daya atau _field_ mendukung _strategic merge patch_. Untuk mendukung _field_ sembarang pada sumber daya _field_, Kustomize +menyediakan penerapan [_patch_ JSON](https://tools.ietf.org/html/rfc6902) melalui `patchesJson6902`. +Untuk mencari sumber daya yang tepat dengan sebuah _patch_ Json, maka grup, versi, jenis dan nama dari sumber daya harus dispesifikasikan dalam `kustomization.yaml`. +Contoh di bawah ini menambahkan jumlah replika dari objek Deployment yang bisa juga dilakukan melalui `patchesJson6902`. + +```shell +# Membuat berkas deployment.yaml +cat <<EOF > deployment.yaml +apiVersion: apps/v1 +kind: Deployment +metadata: + name: my-nginx +spec: + selector: + matchLabels: + run: my-nginx + replicas: 2 + template: + metadata: + labels: + run: my-nginx + spec: + containers: + - name: my-nginx + image: nginx + ports: + - containerPort: 80 +EOF + +# Membuat patch json +cat <<EOF > patch.yaml +- op: replace + path: /spec/replicas + value: 3 +EOF + +# Membuat berkas kustomization.yaml +cat <<EOF >./kustomization.yaml +resources: +- deployment.yaml + +patchesJson6902: +- target: + group: apps + version: v1 + kind: Deployment + name: my-nginx + path: patch.yaml +EOF +``` + +Jalankan perintah `kubectl kustomize ./` untuk melihat _field_ `replicas` yang telah diperbarui: + +```yaml +apiVersion: apps/v1 +kind: Deployment +metadata: + name: my-nginx +spec: + replicas: 3 + selector: + matchLabels: + run: my-nginx + template: + metadata: + labels: + run: my-nginx + spec: + containers: + - image: nginx + name: my-nginx + ports: + - containerPort: 80 +``` + +Selain _patch_, Kustomize juga menyediakan cara untuk melakukan kustomisasi _image_ Container atau memasukkan nilai _field_ dari objek lainnya ke dalam Container tanpa membuat _patch_. Sebagai contoh, kamu dapat melakukan kustomisasi _image_ yang digunakan di dalam Container dengan menyebutkan spesifikasi _field_ `images` di dalam `kustomization.yaml`. + +```shell +cat <<EOF > deployment.yaml +apiVersion: apps/v1 +kind: Deployment +metadata: + name: my-nginx +spec: + selector: + matchLabels: + run: my-nginx + replicas: 2 + template: + metadata: + labels: + run: my-nginx + spec: + containers: + - name: my-nginx + image: nginx + ports: + - containerPort: 80 +EOF + +cat <<EOF >./kustomization.yaml +resources: +- deployment.yaml +images: +- name: nginx + newName: my.image.registry/nginx + newTag: 1.4.0 +EOF +``` + +Jalankan perintah `kubectl kustomize ./` untuk melihat _image_ yang sedang digunakan telah diperbarui: +```yaml +apiVersion: apps/v1 +kind: Deployment +metadata: + name: my-nginx +spec: + replicas: 2 + selector: + matchLabels: + run: my-nginx + template: + metadata: + labels: + run: my-nginx + spec: + containers: + - image: my.image.registry/nginx:1.4.0 + name: my-nginx + ports: + - containerPort: 80 +``` + +Terkadang, aplikasi yang berjalan di dalam Pod perlu untuk menggunakan nilai konfigurasi dari objek lainnya. +Contohnya, sebuah Pod dari objek Deployment perlu untuk membaca nama Service dari Env atau sebagai argumen perintah. +Ini karena nama Service bisa saja berubah akibat dari penambahan `namePrefix` atau `nameSuffix` pada berkas `kustomization.yaml`. +Kami tidak menyarankan kamu untuk meng-_hardcode_ nama Service di dalam argumen perintah. +Untuk penggunaan ini, Kustomize dapat memasukkan nama Service ke dalam Container melalui `vars`. + +```shell +# Membuat berkas deployment.yaml +cat <<EOF > deployment.yaml +apiVersion: apps/v1 +kind: Deployment +metadata: + name: my-nginx +spec: + selector: + matchLabels: + run: my-nginx + replicas: 2 + template: + metadata: + labels: + run: my-nginx + spec: + containers: + - name: my-nginx + image: nginx + command: ["start", "--host", "\$(MY_SERVICE_NAME)"] +EOF + +# Membuat berkas service.yaml +cat <<EOF > service.yaml +apiVersion: v1 +kind: Service +metadata: + name: my-nginx + labels: + run: my-nginx +spec: + ports: + - port: 80 + protocol: TCP + selector: + run: my-nginx +EOF + +cat <<EOF >./kustomization.yaml +namePrefix: dev- +nameSuffix: "-001" + +resources: +- deployment.yaml +- service.yaml + +vars: +- name: MY_SERVICE_NAME + objref: + kind: Service + name: my-nginx + apiVersion: v1 +EOF +``` + +Jalankan perintah `kubectl kustomize ./` untuk melihat nama Service yang dimasukkan ke dalam Container menjadi `dev-my-nginx-001`: + +```yaml +apiVersion: apps/v1 +kind: Deployment +metadata: + name: dev-my-nginx-001 +spec: + replicas: 2 + selector: + matchLabels: + run: my-nginx + template: + metadata: + labels: + run: my-nginx + spec: + containers: + - command: + - start + - --host + - dev-my-nginx-001 + image: nginx + name: my-nginx +``` + +## Base dan Overlay + +Kustomize memiliki konsep **base** dan **overlay**. **base** merupakan direktori dengan `kustomization.yaml`, yang berisi +sekumpulan sumber daya dan kustomisasi yang terkait. **base** dapat berupa direktori lokal maupun direktori dari repo _remote_, +asalkan berkas `kustomization.yaml` ada di dalamnya. **overlay** merupakan direktori dengan `kustomization.yaml` yang merujuk pada +direktori kustomization lainnya sebagai **base**-nya. **base** tidak memiliki informasi tentang **overlay**. dan dapat digunakan pada beberapa **overlay** sekaligus. +**overlay** bisa memiliki beberapa **base** dan terdiri dari semua sumber daya yang berasal dari **base** yang juga dapat memiliki kustomisasi lagi di atasnya. + +Contoh di bawah ini memperlihatkan kegunaan dari **base**: + +```shell +# Membuat direktori untuk menyimpan base +mkdir base +# Membuat base/deployment.yaml +cat <<EOF > base/deployment.yaml +apiVersion: apps/v1 +kind: Deployment +metadata: + name: my-nginx +spec: + selector: + matchLabels: + run: my-nginx + replicas: 2 + template: + metadata: + labels: + run: my-nginx + spec: + containers: + - name: my-nginx + image: nginx +EOF + +# Membuat berkas base/service.yaml +cat <<EOF > base/service.yaml +apiVersion: v1 +kind: Service +metadata: + name: my-nginx + labels: + run: my-nginx +spec: + ports: + - port: 80 + protocol: TCP + selector: + run: my-nginx +EOF + +# Membuat berkas base/kustomization.yaml +cat <<EOF > base/kustomization.yaml +resources: +- deployment.yaml +- service.yaml +EOF +``` + +**base** ini dapat digunakan di dalam beberapa **overlay** sekaligus. Kamu dapat menambahkan `namePrefix` yang berbeda ataupun +_field_ lainnya yang bersinggungan di dalam **overlay** berbeda. Di bawah ini merupakan dua buah **overlay** yang menggunakan **base** yang sama. + +```shell +mkdir dev +cat <<EOF > dev/kustomization.yaml +bases: +- ../base +namePrefix: dev- +EOF + +mkdir prod +cat <<EOF > prod/kustomization.yaml +bases: +- ../base +namePrefix: prod- +EOF +``` + +## Cara menerapkan/melihat/menghapus objek menggunakan Kustomize + +Gunakan `--kustomize` atau `-k` di dalam perintah `kubectl` untuk mengenali sumber daya yang dikelola oleh `kustomization.yaml`. +Perhatikan bahwa `-k` harus merujuk pada direktori kustomization, misalnya: + +```shell +kubectl apply -k <direktori kustomization>/ +``` + +Buatlah `kustomization.yaml` seperti di bawah ini: + +```shell +# Membuat berkas deployment.yaml +cat <<EOF > deployment.yaml +apiVersion: apps/v1 +kind: Deployment +metadata: + name: my-nginx +spec: + selector: + matchLabels: + run: my-nginx + replicas: 2 + template: + metadata: + labels: + run: my-nginx + spec: + containers: + - name: my-nginx + image: nginx + ports: + - containerPort: 80 +EOF + +# Membuat berkas kustomization.yaml +cat <<EOF >./kustomization.yaml +namePrefix: dev- +commonLabels: + app: my-nginx +resources: +- deployment.yaml +EOF +``` + +Jalankan perintah di bawah ini untuk menerapkan objek Deployment `dev-my-nginx`: + +```shell +> kubectl apply -k ./ +deployment.apps/dev-my-nginx created +``` + +Jalankan perintah di bawah ini untuk melihat objek Deployment `dev-my-nginx`: + +```shell +kubectl get -k ./ +``` + +```shell +kubectl describe -k ./ +``` + +Jalankan perintah di bawah ini untuk membandingkan objek Deployment `dev-my-nginx` dengan kondisi yang diinginkan pada klaster jika manifes telah berhasil diterapkan: + +```shell +kubectl diff -k ./ +``` + +Jalankan perintah di bawah ini untuk menghapus objek Deployment `dev-my-nginx`: + +```shell +> kubectl delete -k ./ +deployment.apps "dev-my-nginx" deleted +``` + +## Daftar Fitur Kustomize + +| _Field_ | Tipe | Deskripsi | +|-----------------------|--------------------------------------------------------------------------------------------------------------|------------------------------------------------------------------------------------| +| namespace | string | menambahkan Namespace untuk semua sumber daya | +| namePrefix | string | nilai dari _field_ ini ditambahkan di awal pada nama dari semua sumber daya | +| nameSuffix | string | nilai dari _field_ ini ditambahkan di akhir pada nama dari semua sumber daya | +| commonLabels | map[string]string | label untuk ditambahkan pada semua sumber daya dan selektor | +| commonAnnotations | map[string]string | anotasi untuk ditambahkan pada semua sumber daya | +| resources | []string | setiap entri di dalam daftar ini harus diselesaikan pada berkas konfigurasi sumber daya yang sudah ada | +| configmapGenerator | [][ConfigMapArgs](https://github.com/kubernetes-sigs/kustomize/blob/release-kustomize-v4.0/api/types/kustomization.go#L99) | setiap entri di dalam daftar ini membangkitkan ConfigMap | +| secretGenerator | [][SecretArgs](https://github.com/kubernetes-sigs/kustomize/blob/release-kustomize-v4.0/api/types/kustomization.go#L106) | setiap entri di dalam daftar ini membangkitkan Secret | +| generatorOptions | [GeneratorOptions](https://github.com/kubernetes-sigs/kustomize/blob/release-kustomize-v4.0/api/types/kustomization.go#L109) | memodifikasi perilaku dari semua generator ConfigMap dan Secret | +| bases | []string | setiap entri di dalam daftar ini harus diselesaikan ke dalam sebuah direktori yang berisi berkas kustomization.yaml | +| patchesStrategicMerge | []string | setiap entri di dalam daftar ini harus diselesaikan dengan _strategic merge patch_ dari sebuah objek Kubernetes | +| patchesJson6902 | [][Json6902](https://github.com/kubernetes-sigs/kustomize/blob/release-kustomize-v4.0/api/types/patchjson6902.go#L8) | setiap entri di dalam daftar ini harus diselesaikan ke suatu objek Kubernetes atau _patch_ Json | +| vars | [][Var](https://github.com/kubernetes-sigs/kustomize/blob/master/api/types/var.go#L31) | setiap entri digunakan untuk menangkap teks yang berasal dari _field_ sebuah sumber daya | +| images | [][Image](https://github.com/kubernetes-sigs/kustomize/tree/master/api/types/image.go#L23) | setiap entri digunakan untuk memodifikasi nama, tag dan/atau _digest_ untuk sebuah _image_ tanpa membuat _patch_ | +| configurations | []string | setiap entri di dalam daftar ini harus diselesaikan ke sebuah berkas yang berisi [konfigurasi transformer Kustomize](https://github.com/kubernetes-sigs/kustomize/tree/master/examples/transformerconfigs) | +| crds | []string | setiap entri di dalam daftar ini harus diselesaikan ke sebuah berkas definisi OpenAPI untuk tipe Kubernetes | + + + +## {{% heading "whatsnext" %}} + + +* [Kustomize](https://github.com/kubernetes-sigs/kustomize) +* [Buku Kubectl](https://kubectl.docs.kubernetes.io) +* [Rujukan Perintah Kubectl](/id/docs/reference/generated/kubectl/kubectl/) +* [Rujukan API Kubernetes](/id/docs/reference/generated/kubernetes-api/{{< param "version" >}}/) + + diff --git a/content/id/docs/tasks/run-application/_index.md b/content/id/docs/tasks/run-application/_index.md new file mode 100644 index 0000000000..7c5e073f2b --- /dev/null +++ b/content/id/docs/tasks/run-application/_index.md @@ -0,0 +1,5 @@ +--- +title: "Menjalankan" +description: Menjalankan dan mengatur aplikasi stateless dan stateful. +weight: 40 +--- diff --git a/content/id/docs/tasks/run-application/horizontal-pod-autoscaler.md b/content/id/docs/tasks/run-application/horizontal-pod-autoscaler.md new file mode 100644 index 0000000000..c4ed16413f --- /dev/null +++ b/content/id/docs/tasks/run-application/horizontal-pod-autoscaler.md @@ -0,0 +1,453 @@ +--- +title: HorizontalPodAutoscaler +feature: + title: Horizontal scaling + description: > + Scale up dan scale down aplikasimu dengan sebuah perintah yang serderhana, dengan UI, atau otomatis bersadarkan penggunaan CPU. +content_type: concept +weight: 90 +--- + +<!-- overview --> + +HorizontalPodAutoscaler secara otomatis akan memperbanyak jumlah Pod di dalam ReplicationController, Deployment, +ReplicaSet ataupun StatefulSet berdasarkan hasil observasi penggunaan CPU(atau, dengan +[metrik khusus](https://git.k8s.io/community/contributors/design-proposals/instrumentation/custom-metrics-api.md), pada beberapa aplikasi yang menyediakan metrik). +Perlu dicatat bahwa HorizontalPodAutoscale tidak dapat diterapkan pada objek yang tidak dapat diperbanyak, seperti DeamonSets. + +HorizontalPodAutoscaler diimplementasikan sebagai Kubernetes API *resource* dan sebuah _controller_. +*Resource* tersebut akan menentukan perilaku dari _controller_-nya. +Kontroler akan mengubah jumlah replika pada ReplicationController atau pada Deployment untuk menyesuaikan dengan hasil observasi rata-rata +penggunaan CPU sesuai dengan yang ditentukan oleh pengguna. + + + + +<!-- body --> + +## Bagaimana cara kerja HorizontalPodAutoscaler? + +![Diagram HorizontalPodAutoscaler](/images/docs/horizontal-pod-autoscaler.svg) + +HorizontalPodAutoscaler diimplementasikan sebagai sebuah _loop_ kontrol, yang secara +berkala dikontrol oleh *flag* `--horizontal-pod-autoscaler-sync-period` pada _controller manager_ +(dengan nilai bawaan 15 detik). + +Dalam setiap periode, _controller manager_ melakukan kueri penggunaan sumber daya dan membandingkan +dengan metrik yang dispesifikasikan pada HorizontalPodAutoscaler. _Controller manager_ mendapat +metrik dari sumber daya metrik API (untuk metrik per Pod) atau dari API metrik khusus (untuk semua metrik lainnya). + +* Untuk metrik per Pod (seperti CPU), _controller_ mengambil metrik dari sumber daya metrik API + untuk setiap Pod yang ditargetkan oleh HorizontalPodAutoscaler. Kemudian, jika nilai target penggunaan ditentukan, + maka _controller_ akan menghitung nilai penggunaan sebagai persentasi dari pengguaan sumber daya dari Container + pada masing-masing Pod. Jika target nilai mentah (*raw value*) ditentukan, maka nilai metrik mentah (*raw metric*) + akan digunakan secara langsung. _Controller_ kemudian mengambil nilai rata-rata penggunaan atau nilai mentah (tergantung + dengan tipe target yang ditentukan) dari semua Pod yang ditargetkan dan menghasilkan perbandingan yang + digunakan untuk menentukan jumlah replika yang akan diperbanyak. + + Perlu dicatat bahwa jika beberapa Container pada Pod tidak memiliki nilai *resource request*, penggunaan CPU + pada Pod tersebut tidak akan ditentukan dan *autoscaler* tidak akan melakukan tindakan apapun untuk metrik tersebut. + Perhatikan pada bagian [detail algoritma](#detail-algoritma) di bawah ini untuk informasi lebih lanjut mengenai + cara kerja algoritma *autoscale*. + +* Untuk metrik khusus per Pod, _controller_ bekerja sama seperti sumber daya metrik per Pod, + kecuali Pod bekerja dengan nilai mentah, bukan dengan nilai utilisasi (*utilization values*). + +* Untuk objek metrik dan metrik eksternal, sebuah metrik diambil, dimana metrik tersebut menggambarkan + objek tersebut. Metrik ini dibandingkan dengan nilai target untuk menghasilkan perbandingan seperti di atas. + Pada API `autoscaling/v2beta2`, nilai perbandingan dapat secara opsional dibagi dengan jumlah Pod + sebelum perbandingan dibuat. + +Pada normalnya, HorizontalPodAutoscaler mengambil metrik dari serangkaian API yang sudah diagregat +(`custom.metric.k8s.io`, dan `external.metrics.k8s.io`). API `metrics.k8s.io` biasanya disediakan oleh +*metric-server*, dimana *metric-server* dijalankan secara terpisah. Perhatikan +[*metrics-server*](/docs/tasks/debug-application-cluster/resource-metrics-pipeline/#metrics-server) sebagai petunjuk. +HorizontalPodAutoscaler juga mengambil metrik dari Heapster secara langsung. + +{{< note >}} +{{< feature-state state="deprecated" for_k8s_version="v1.11" >}} +Pengambian metrik dari Heapster tidak didukung lagi pada Kubernetes versi 1.11. +{{< /note >}} + +Perhatikan [Dukungan untuk API metrik](#dukungan-untuk-api-metrik) untuk lebih detail. + +*Autoscaler* mengkases _controller_ yang dapat diperbanyak (seperti ReplicationController, Deployment, dan ReplicaSet) +dengan menggunakan *scale sub-resource*. Untuk lebih detail mengenai *scale sub-resource* dapat ditemukan +[di sini](https://git.k8s.io/community/contributors/design-proposals/autoscaling/horizontal-pod-autoscaler.md#scale-subresource). + +### Detail Algoritma + +Dari sudut pandang paling sederhana, _controller_ HorizontalPodAutoscaler mengoperasikan +perbandingan metrik yang diinginkan dengan kedaan metrik sekarang. + +``` +desiredReplicas = ceil[currentReplicas * ( currentMetricValue / desiredMetricValue )] +``` + +Sebagai contoh, jika nilai metrik sekarang adalah `200m` dan nilai metrik yang +diinginkan adalah `100m`, jumlah replika akan ditambah dua kali lipat, +karena `200.0 / 100.0 == 2.0`. Jika nilai metrik sekarang adalah `50m`, +maka jumlah replika akan dikurangi setengah, karena `50.0 / 100.0 == 0.5`. +Kita tetap memperbanyak replika (_scale_) jika nilai perbandingan mendekati 1.0 (dalam toleransi yang +dapat dikonfigurasi secata global, dari *flag* `--horizontal-pod-autoscaler-tolerance` +dengan nilai bawaan 0.1. + +Ketika `targetAverageValue` (nilai target rata-rata) atau `targetAverageUtilization` +(target penggunaan rata-rata) ditentukan, `currentMetricValue` (nilai metrik sekaraang) +dihitung dengan mengambil rata-rata dari metrik dari semua Pod yang ditargetkan oleh +HorizontalPodAutoscaler. Sebelum mengecek toleransi dan menentukan nilai akhir, +kita mengambil kesiapan Pod dan metrik yang hilang sebagai pertimbangan. + +Semua Pod yang memiliki waktu penghapusan (Pod dalam proses penutupan) +dan semua Pod yang mengalami kegagalan akan dibuang. + +Jika ada metrik yang hilang dari Pod, maka Pod akan dievaluasi nanti. +Pod dengan nilai metrik yang hilang akan digunakan untuk menyesuaikan +jumlah akhir Pod yang akan diperbanyak atau dikurangi. + +Ketika _scaling_ dilakukan karena CPU, jika terdapat Pod yang akan siap (dengan kata lain +Pod tersebut sedang dalam tahap inisialisasi) *atau* metrik terakhir dari Pod +adalah metrik sebelum Pod dalam keadaan siap, maka Pod tersebut juga +akan dievaluasi nantinya. + +Akibat keterbatasan teknis, _controller_ HorizontalPodAutoscaler tidak dapat +menentukan dengan tepat kapan pertama kali Pod akan dalam keadaan siap +ketika menentukan apakah metrik CPU tertentu perlu dibuang. Sebaliknya, +HorizontalPodAutoscaler mempertimbangkan sebuah Pod "tidak dalam keadaan siap" +jika Pod tersebut dalam keadaan tidak siap dan dalam transisi ke status tidak +siap dalam waktu singkat, rentang waktu dapat dikonfigurasi, sejak Pod tersebut dijalankan. +Rentang waktu tersebut dapat dikonfigurasi dengan *flag* `--horizontal-pod-autoscaler-initial-readiness-delay` +dan waktu bawaannya adalah 30 detik. Ketika suatu Pod sudah dalam keadaan siap, +Pod tersebut mempertimbangkan untuk siap menjadi yang pertama jika itu terjadi dalam +waktu yang lebih lama, rentang waktu dapat dikonfigurasi, sejak Pod tersebut dijalankan. +Rentang waktu tersebut dapat dikonfigurasi dengan *flag* `--horizontal-pod-autoscaler-cpu-initialization-period` +dan nilai bawaannya adalah 5 menit. + +Skala perbandingan dasar `currentMetricValue / desiredMetricValue` +dihitung menggunakan Pod yang tersisa yang belum disisihkan atau dibuang dari +kondisi di atas. + +Jika terdapat metrik yang hilang, kita menghitung ulang rata-rata dengan lebih +konservatif, dengan asumsi Pod mengkonsumsi 100% dari nilai yang diharapkan +jika jumlahnya dikurangi (*scale down*) dan 0% jika jumlahnya diperbanyak (*scale up*). +Ini akan mengurangi besarnya kemungkinan untuk *scale*. + +Selanjutnya, jika terdapat Pod dalam keadaan tidak siap, dan kita akan +memperbanyak replikas (*scale up*) tanpa memperhitungkan metrik yang hilang atau Pod yang tidak dalam +keadaan siap, kita secara konservatif mengasumsikan Pod yang tidak dalam keadaan siap +mengkonsumsi 0% dari metrik yang diharapkan, akhirnya meredam jumlah replika yang diperbanyak (*scale up*). + +Seteleh memperhitungkan Pod yang tidak dalam keadaan siap dan metrik yang hilang, +kita menghitung ulang menggunakan perbandingan. Jika perbandingan yang baru membalikkan +arah *scale*-nya atau masih di dalam toleransi, kita akan melakukan *scale* dengan tepat. Jika tidak, +kita menggunakan perbandingan yang baru untuk memperbanyak atau mengurangi jumlah replika. + +Perlu dicatat bahwa nilai asli untuk rata-rata penggunaan dilaporkan kembali melalui +status HorizontalPodAutoscaler, tanpa memperhitungkan Pod yang tidak dalam keadaan siap atau +metrik yang hilang, bahkan ketika perbandingan yang baru digunakan. + +Jika beberapa metrik ditentukan pada sebuah HorizontalPodAutoscaler, perhitungan +dilakukan untuk setiap metrik dan nilai replika terbesar yang diharapkan akan dipilih. +Jika terdapat metrik yang tidak dapat diubah menjadi jumlah replika yang diharapkan +(contohnya terdapat kesalahan ketika mengambil metrik dari API metrik) dan pengurangan replika +disarankan dari metrik yang dapat diambil, maka *scaling* akan diabaikan. Ini berarti +HorizontalPodAutoscaler masih mampu untuk memperbanyak replika jika satu atau lebih metrik +memberikan sebuah `desiredReplicas` lebih besar dari nilai yang sekarang. + +Pada akhirnya, sebelum HorizontalPodAutoscaler memperbanyak target, rekomendasi *scaling* akan +dicatat. _Controller_ mempertimbangkan semua rekomendasi dalam rentang waktu yang dapat +dikonfigurasi untuk memilih rekomendasi tertinggi. Nilai ini dapat dikonfigurasi menggunakan +*flag* `--horizontal-pod-autoscaler-downscale-stabilization`, dengan nilai bawaan +5 menit. Ini berarti pengurangan replika akan terjadi secara bertahap, untuk mengurangi dampak dari +perubahan nilai metrik yang cepat. + +## Objek API + +HorizontalPodAutoscaler adalah sebuah API dalam grup `autoscaling` pada Kubernetes. +Versi stabil, yang hanya mendukung untuk *autoscale* CPU, dapat ditemukan pada versi +API `autoscaling/v1`. + +Versi *beta*, yang mendukung untuk *scaling* berdasarkan memori dan metrik khusus, +dapat ditemukan pada `autoscaling/v2beta2`. *Field* yang baru diperkenalkan pada +`autoscaling/v2beta2` adalah *preserved* sebagai anotasi ketika menggunakan `autoscaling/v1`. + +Ketika kamu membuat sebuah HorizontalPodAutoscaler, pastikan nama yang ditentukan adalah valid +[nama subdomain DNS](/id/docs/concepts/overview/working-with-objects/names#nama). +Untuk lebih detail tentang objek API ini dapat ditemukan di +[Objek HorizontalPodAutoscaler](https://git.k8s.io/community/contributors/design-proposals/autoscaling/horizontal-pod-autoscaler.md#horizontalpodautoscaler-object). + +## Dukungan untuk HorizontalPodAutoscaler pada kubectl + +Seperti sumber daya API lainnya, HorizontalPodAutoscaler didukung secara bawaan oleh `kubectl`. +Kita dapat membuat *autoscaler* yang baru dengan menggunakan perintah `kubectl create`. +Kita dapat melihat daftar *autoscaler* dengan perintah `kubectl get hpa` dan melihat deskripsi +detailnya dengan perintah `kubectl describe hpa`. Akhirnya, kita dapat menghapus *autoscaler* +meggunakan perintah `kubectl delete hpa`. + +Sebagai tambahan, terdapat sebuah perintah khusus `kubectl autoscaler` untuk mempermudah pembuatan +HorizontalPodAutoscaler. Sebagai contoh, mengeksekusi +`kubectl autoscaler rs foo --min=2 --max=5 --cpu-percent=80` akan membuat sebuah *autoscaler* untuk +ReplicaSet *foo*, dengan target pengguaan CPU `80%` dan jumlah replika antara 2 sampai dengan 5. +Dokumentasi lebih detail tentang `kubectl autoscaler` dapat ditemukan di +[sini](/docs/reference/generated/kubectl/kubectl-commands/#autoscale). + +## Autoscaling ketika Rolling Update + +Saat ini, dimungkinkan untuk melakukan *rolling update* menggunakan objek Deployment, yang akan +mengatur ReplicaSet untuk kamu. HorizontalPodAutoscaler hanya mendukung pendekatan terakhir: +HorizontalPodAutoscaler terikat dengan objek Deployment, yang mengatur seberapa besar dari objek Deployment tersebut, +dan Deployment bertugas untuk mengatur besar dari ReplicaSet. + +HorizontalPodAutoscaler tidak bekerja dengan *rolling update* yang menggunakan manipulasi +pada ReplicationContoller secara langsung, dengan kata lain kamu tidak bisa mengikat +HorizontalPodAutoscaler dengan ReplicationController dan melakukan *rolling update*. +Alasan HorizontalPodAutoscaler tidak bekerja ketika *rolling update* membuat ReplicationController +yang baru adalah HorizontalPodAutoscaler tidak akan terikat dengan ReplicationController yang baru tersebut. + +## Dukungan untuk *Cooldown* / Penundaan + +Ketika mengolah *scaleing* dari sebuah grup replika menggunakan HorizonalPodAutoscaler, +jumlah replika dimungkinkan tetap berubah secara sering disebabkan oleh perubahan dinamis +dari metrik yang dievaluasi. Hal ini sering disebut dengan *thrashing*. + +Mulai dari versi 1.6, operator klaster dapat mengatasi masalah ini dengan mengatur +konfigurasi HorizontalPodAutoscaler global sebagai *flag* `kube-controller-manager`. + +Mulai dari versi 1.12, sebuah algoritma pembaruan baru menghilangkan kebutuhan terhadap +penundaan memperbanyak replika (*upscale*). + +- `--horizontal-pod-autoscaler-downscale-stabilization`: Nilai untuk opsi ini adalah + sebuah durasi yang menentukan berapa lama *autoscaler* menunggu sebelum operasi + pengurangan replika (*downscale*) yang lain dilakukan seteleh operasi sekarang selesai. Nilai bawaannya + adalah 5 menit (`5m0s`). + +{{< note >}} +Ketika mengubah nilai paramater ini, sebuah operator klaster sadar akan kemungkinan +konsekuensi. Jika waktu penundaan diset terlalu lama, kemungkinan akan membuat +HorizontalPodAutoscaler tidak responsif terharap perubahan beban kerja. Namun, jika +waktu penundaan diset terlalu cepat, kemungkinan replikasi akan *trashing* seperti +biasanya. +{{< /note >}} + +## Dukungan untuk Beberapa Metrik + +Kubernetes versi 1.6 menambah dukungan untuk *scaling* berdasarkan beberapa metrik. +Kamu dapat menggunakan API versi `autoscaling/v2beta2` untuk menentukan beberapa metrik +yang akan digunakan HorizontalPodAutoscaler untuk menambah atau mengurangi jumlah replika. +Kemudian, _controller_ HorizontalPodAutoscaler akan mengevaluasi setiap metrik dan menyarankan jenis +*scaling* yang baru berdasarkan metrik tersebut. Jumlah replika terbanyak akan digunakan untuk *scale* +yang baru. + +## Dukungan untuk Metrik Khusus + +{{< note >}} +Kubernetes versi 1.2 menambah dukungan *alpha* untuk melakukan *scaling* berdasarkan metrik +yang spesifik dengan aplikasi menggunakan anotasi khusus. Dukungan untuk anotasi ini +dihilangkan pada Kubernetes versi 1.6 untuk mendukung API *autoscaling* yang baru. Selama +cara lama untuk mendapatkan metrik khusus masih tersedia, metrik ini tidak akan tersedia untuk +digunakan oleh HorizontalPodAutoscaler dan anotasi sebelumnya untuk menentukan metrik khusus untuk +*scaling* tidak lagi digunakan oleh _controller_ HorizontalPodAutscaler. +{{< /note >}} + +Kubernetes versi 1.6 menambah dukungan untuk menggunakan metrik khusus pada HorizontalPodAutoscaler. +Kamu dapat menambahkan metrik khusus untuk HorizontalPodAutoscaler pada API versi `autoscaling/v2beta2`. +Kubernetes kemudian memanggil API metrik khusu untuk mengambil nilai dari metrik khusus. + +@girikuncoro +girikuncoro 4 days ago Contributor + +typo +Suggested change +Kubernetes kemudian memanggil API metrik khusu untuk mengambil nilai dari metrik khusus. +Kubernetes kemudian memanggil API metrik khusus untuk mengambil nilai dari metrik khusus. +@ecojuntak + +Lihat [Dukungan untuk API metrik](#dukungan-untuk-api-metrik) untuk kubutuhannya. + +## Dukungan untuk API metrik + +Secara standar, _controller_ HorizontalPodAutoscaler mengambil metrik dari beberapa API. Untuk dapat +mengakses API ini, administrator klaster harus memastikan bahwa: + +* [API Later Pengumpulan](/docs/tasks/access-kubernetes-api/configure-aggregation-layer/) diaktifkan. + +* API berikut ini terdaftar: + + * Untuk metrik sumber daya, ini adalah API `metrics.k8s.io`, pada umumnya disediakan oleh + [metrics-server](https://github.com/kubernetes-incubator/metrics-server). API tersebut dapat + diaktifkan sebagai *addon* atau tambahan pada klaster. + + * Untuk metrik khusus, ini adalah API `custom.metrics.k8s.io`. API ini disediakan oleh API + adaptor server yang disediakan oleh vendor yang memberi solusi untuk metrik. Cek dengan + *pipeline* metrikmu atau [daftar solusi yang sudah diketahui](https://github.com/kubernetes/metrics/blob/master/IMPLEMENTATIONS.md#custom-metrics-api). Jika kamu ingin membuat sendiri, perhatikan + [*boilerplate* berikut](https://github.com/kubernetes-incubator/custom-metrics-apiserver) untuk memulai. + + * Untuk metrik eksternal, ini adalah API `external.metrics.k8s.io`. API ini mungkin disediakan oleh penyedia + metrik khusus diatas. + +* Nilai dari `--horizontal-pod-autoscaler-use-rest-clients` adalah `true` atau tidak ada. Ubah nilai tersebut menjadi + `false` untuk mengubah ke *autoscaling* berdasarkan Heapster, dimana ini sudah tidak didukung lagi. + +Untuk informasi lebih lanjut mengenai metrik-metrik ini dan bagaimana perbedaan setiap metrik, perhatikan proposal +desain untuk [HPA V2](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/autoscaling/hpa-v2.md), +[custom.metrics.k8s.io](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/instrumentation/custom-metrics-api.md) +dan [external.metrics.k8s.io](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/instrumentation/external-metrics-api.md). + +Untuk contoh bagaimana menggunakan metrik-metrik ini, perhatikan [panduan penggunaan metrik khusus](/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough/#autoscaling-on-multiple-metrics-and-custom-metrics) +dan [panduan penggunaan metrik eksternal](/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough/#autoscaling-on-metrics-not-related-to-kubernetes-objects). + +## Dukungan untuk Perilaku *Scaling* yang dapat Dikonfigurasi + +Mulai dari versi [v1.18](https://github.com/kubernetes/enhancements/blob/master/keps/sig-autoscaling/20190307-configurable-scale-velocity-for-hpa.md), API `v2beta2` mengizinkan perilaku *scaling* dapat +dikonfigurasi melalui *field* `behavior` pada HorizontalPodAutoscaler. Perilaku *scaling up* dan *scaling down* +ditentukan terpisah pada *field* `slaceUp` dan *field* `scaleDown`, dibawah dari *field* `behavior`. +Sebuah stabilisator dapat ditentukan untuk kedua arah *scale* untuk mencegah perubahan replika yang terlalu +berbeda pada target *scaling*. Menentukan *scaling policies* akan mengontrol perubahan replika +ketika *scaling*. + +### Scaling Policies + +Satu atau lebih *scaling policies* dapat ditentukan pada *field* `behavior`. Ketika beberapa +*policies* ditentukan, *policy* yang mengizinkan *scale* terbesar akan dipilih secara *default*. +Contoh berikut menunjukkan perilaku ketika mengurangi replika: + +```yaml +behavior: + scaleDown: + policies: + - type: Pods + value: 4 + periodSeconds: 60 + - type: Percent + value: 10 + periodSeconds: 60 +``` + +Ketika jumlah Pod lebih besar dari 40, *policy* kedua akan digunakan untuk *scaling down*. +Misalnya, jika terdapat 80 replika dan target sudah di *scale down* ke 10 replika, 8 replika +akan dikurangi pada tahapan pertama. Pada iterasi berikutnya, ketika jumlah replika adalah 72, +10% dari Pod adalah 7.2 tetapi akan dibulatkan menjadi 8. Dalam setiap iterasi pada _controller_ +*autoscaler* jumlah Pod yang akan diubah akan dihitung ulang berdarkan jumlah replika sekarang. +Ketika jumlah replika dibawah 40, *policy* pertama (Pods) akan digunakan dan 4 replika akan dikurangi +dalam satu waktu. + +`periodSeconds` menunjukkan berapa lama waktu pada iterasi terkhir untuk menunjukkan *policy* +mana yang akan digunakan. *Policy* pertama mengizinkan maksimal 4 replika di *scale down* +dalam satu menit. *Policy* kedua mengixinkan maksimal 10% dari total replika sekarang di +*scale down* dalam satu menit. + +Pemilihan *policy* dapat diubah dengan menentukannya pada *field* `selectPolicy` untuk sebuah +arah *scale* (baik *scale up* ataupun *scale down*). Dengan menentukan nilai `Min`, +HorizontalPodAutoscaler akan memilih *policy* yang mengizinkan pergantian replika paling sedikit. +Dengan menuntukan nilai `Disable`, akan menghentikan *scaling* pada arah *scale* tersebut. + +### Jendela Stabilisasi + +Jendela stabilisasi digunakan untuk membatasi perubahan replika yang terlalu drastis ketika +metrik yang digunakan untuk *scaling* tetap berubah-ubah. Jendela stabilisasi digunakan oleh +algoritma *autoscaling* untuk memperhitungkan jumlah replika yang diharapkan dari *scaling* +sebelumnya untuk mencengah *scaling. Berikut adalah contoh penggunaan jendela stabilisasi +pada `scaleDown`. +```yaml +scaleDown: + stabilizationWindowSeconds: 300 +``` +Ketika metrik menandakan bahwa replika pada target akan dikurangi, algoritma akan memperhatikan +jumlah replika yang diharapkan sebelumnya dan menggunakan nilai terbesar dari interval +yang ditentukan. Pada contoh diatas, semua jumlah replika yang diharapkan pada 5 menit +yang lalu akan dipertimbangkan. +### Perilaku Standar +Untuk menggunakan *scaling* khusus, tidak semua *field* perlu ditentukan. Hanta nilai yang +perlu diubah saja yang ditentukan. Nilai khusus ini akan digabungkan dengan nilai standar. +Berikut adalah nilai standar perilaku pada algoritma yang digunakan HorizontalPodAutoscaler. + +```yaml +behavior: + scaleDown: + stabilizationWindowSeconds: 300 + policies: + - type: Percent + value: 100 + periodSeconds: 15 + scaleUp: + stabilizationWindowSeconds: 0 + policies: + - type: Percent + value: 100 + periodSeconds: 15 + - type: Pods + value: 4 + periodSeconds: 15 + selectPolicy: Max +``` + +Untuk `scaleDown`, nilai dari jendela stabilisasi adalah 300 detik (atau nilai dari +*flag* `--horizontal-pod-autoscaler-downscale-stabilization` jika ditentukan). Hanya terdapat +satu *policy*, yaitu mengizinkan menghapus 100% dari replika yang berjalan, +artinya target replikasi di *scale* ke jumlah replika minimum. Untuk `scaleUp`, tidak terdapat +jendela stabilisasi. Jika metrik menunjukkan bahwa replika pada target perlu diperbanyak, maka replika akan +diperbanyak di secara langsung. Untuk `scaleUp` terdapat dua *policy*, yaitu empat Pod atau 100% dari +replika yang berjalan akan ditambahkan setiap 15 detik sampai HorizontalPodAutoscaler +dalam keadaan stabil. + +### Contoh: Mengubah Jendela Stabiliasi pada *field* scaleDown + +Untuk membuat jendela stabilisai untuk pengurangan replika selama satu menit, perilaku +berikut ditambahkan pada HorizontalPodAutoscaler. + +```yaml +behavior: + scaleDown: + stabilizationWindowSeconds: 60 +``` + +### Contoh: Membatasi nilai *scale down* + +Untuk membatasi total berapa Pod yang akan dihapus, 10% setiap menut, perilaku +berikut ditambahkan pada HorizontalPodAutoscaler. + +```yaml +behavior: + scaleDown: + policies: + - type: Percent + value: 10 + periodSeconds: 60 +``` + +Untuk mengizinkan penghapusan 5 Pod terakhir, *policy* lain dapat ditambahkan. + +```yaml +behavior: + scaleDown: + policies: + - type: Percent + value: 10 + periodSeconds: 60 + - type: Pods + value: 5 + periodSeconds: 60 + selectPolicy: Max +``` + +### Contoh: menonakfitkan *scale down* + +Nilai `Disable` pada `selectPolicy` akan menonaktifkan *scaling* pada arah yang +ditentukan. Untuk mencegah pengurangan replika dapat menggunakan *policy* berikut. + +```yaml +behavior: + scaleDown: + selectPolicy: Disabled +``` + + + +## {{% heading "whatsnext" %}} + + +* Dokumentasi desain [Horizontal Pod Autoscaling](https://git.k8s.io/community/contributors/design-proposals/autoscaling/horizontal-pod-autoscaler.md). +* Perintah kubectl autoscale [kubectl autoscale](/docs/reference/generated/kubectl/kubectl-commands/#autoscale). +* Contoh penggunaan [HorizontalPodAutoscaler](/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough/). + + diff --git a/content/id/docs/tasks/run-application/run-stateless-application-deployment.md b/content/id/docs/tasks/run-application/run-stateless-application-deployment.md new file mode 100644 index 0000000000..a069188de6 --- /dev/null +++ b/content/id/docs/tasks/run-application/run-stateless-application-deployment.md @@ -0,0 +1,158 @@ +--- +title: Menjalankan Aplikasi Stateless Menggunakan Deployment +min-kubernetes-server-version: v1.9 +content_type: tutorial +weight: 10 +--- + +<!-- overview --> + +Dokumen ini menunjukkan cara bagaimana cara menjalankan sebuah aplikasi menggunakan objek Deployment Kubernetes. + + + + +## {{% heading "objectives" %}} + + +* Membuat sebuah Deployment Nginx. +* Menggunakan kubectl untuk mendapatkan informasi mengenai Deployment. +* Mengubah Deployment. + + + + +## {{% heading "prerequisites" %}} + + +{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}} + + + + +<!-- lessoncontent --> + +## Membuat dan Menjelajahi Deployment Nginx + +Kamu dapat menjalankan aplikasi dengan membuat sebuah objek Deployment Kubernetes, dan kamu +dapat mendeskripsikan sebuah Deployment di dalam berkas YAML. Sebagai contohnya, berkas +YAML berikut mendeskripsikan sebuah Deployment yang menjalankan _image_ Docker nginx:1.14.2: + +{{< codenew file="application/deployment.yaml" >}} + + +1. Buatlah sebuah Deployment berdasarkan berkas YAML: + + kubectl apply -f https://k8s.io/examples/application/deployment.yaml + +2. Tampilkan informasi dari Deployment: + + kubectl describe deployment nginx-deployment + + Keluaran dari perintah tersebut akan menyerupai: + + user@computer:~/website$ kubectl describe deployment nginx-deployment + Name: nginx-deployment + Namespace: default + CreationTimestamp: Tue, 30 Aug 2016 18:11:37 -0700 + Labels: app=nginx + Annotations: deployment.kubernetes.io/revision=1 + Selector: app=nginx + Replicas: 2 desired | 2 updated | 2 total | 2 available | 0 unavailable + StrategyType: RollingUpdate + MinReadySeconds: 0 + RollingUpdateStrategy: 1 max unavailable, 1 max surge + Pod Template: + Labels: app=nginx + Containers: + nginx: + Image: nginx:1.14.2 + Port: 80/TCP + Environment: <none> + Mounts: <none> + Volumes: <none> + Conditions: + Type Status Reason + ---- ------ ------ + Available True MinimumReplicasAvailable + Progressing True NewReplicaSetAvailable + OldReplicaSets: <none> + NewReplicaSet: nginx-deployment-1771418926 (2/2 replicas created) + No events. + +3. Lihatlah daftar Pod-Pod yang dibuat oleh Deployment: + + kubectl get pods -l app=nginx + + Keluaran dari perintah tersebut akan menyerupai: + + NAME READY STATUS RESTARTS AGE + nginx-deployment-1771418926-7o5ns 1/1 Running 0 16h + nginx-deployment-1771418926-r18az 1/1 Running 0 16h + +4. Tampilkan informasi mengenai Pod: + + kubectl describe pod <nama-pod> + + dimana `<nama-pod>` merupakan nama dari Pod kamu. + +## Mengubah Deployment + +Kamu dapat mengubah Deployment dengan cara mengaplikasikan berkas YAML yang baru. +Berkas YAML ini memberikan spesifikasi Deployment untuk menggunakan Nginx versi 1.16.1. + +{{< codenew file="application/deployment-update.yaml" >}} + +1. Terapkan berkas YAML yang baru: + + kubectl apply -f https://k8s.io/examples/application/deployment-update.yaml + +2. Perhatikan bahwa Deployment membuat Pod-Pod dengan nama baru dan menghapus Pod-Pod lama: + + kubectl get pods -l app=nginx + +## Meningkatkan Jumlah Aplikasi dengan Meningkatkan Ukuran Replika + +Kamu dapat meningkatkan jumlah Pod di dalam Deployment dengan menerapkan +berkas YAML baru. Berkas YAML ini akan meningkatkan jumlah replika menjadi 4, +yang nantinya memberikan spesifikasi agar Deployment memiliki 4 buah Pod. + +{{< codenew file="application/deployment-scale.yaml" >}} + +1. Terapkan berkas YAML: + + kubectl apply -f https://k8s.io/examples/application/deployment-scale.yaml + +2. Verifikasi Deployment kamu saat ini yang memiliki empat Pod: + + kubectl get pods -l app=nginx + + Keluaran dari perintah tersebut akan menyerupai: + + NAME READY STATUS RESTARTS AGE + nginx-deployment-148880595-4zdqq 1/1 Running 0 25s + nginx-deployment-148880595-6zgi1 1/1 Running 0 25s + nginx-deployment-148880595-fxcez 1/1 Running 0 2m + nginx-deployment-148880595-rwovn 1/1 Running 0 2m + +## Menghapus Deployment + +Menghapus Deployment dengan nama: + + kubectl delete deployment nginx-deployment + +## Cara Lama Menggunakan: ReplicationController + +Cara yang dianjurkan untuk membuat aplikasi dengan replika adalah dengan menggunakan Deployment, +yang nantinya akan menggunakan ReplicaSet. Sebelum Deployment dan ReplicaSet ditambahkan +ke Kubernetes, aplikasi dengan replika dikonfigurasi menggunakan [ReplicationController](/id/docs/concepts/workloads/controllers/replicationcontroller/). + + + + +## {{% heading "whatsnext" %}} + + +* Pelajari lebih lanjut mengenai [objek Deployment](/id/docs/concepts/workloads/controllers/deployment/). + + diff --git a/content/id/docs/tasks/tls/_index.md b/content/id/docs/tasks/tls/_index.md new file mode 100755 index 0000000000..8607aa28d2 --- /dev/null +++ b/content/id/docs/tasks/tls/_index.md @@ -0,0 +1,5 @@ +--- +title: "TLS" +weight: 100 +--- + diff --git a/content/id/docs/tasks/tls/managing-tls-in-a-cluster.md b/content/id/docs/tasks/tls/managing-tls-in-a-cluster.md new file mode 100644 index 0000000000..e672a7b265 --- /dev/null +++ b/content/id/docs/tasks/tls/managing-tls-in-a-cluster.md @@ -0,0 +1,214 @@ +--- +title: Kelola Sertifikat TLS Pada Klaster +content_type: task +--- + +<!-- overview --> + +Kubernetes menyediakan API `certificates.k8s.io` yang memungkinkan kamu membuat sertifikat +TLS yang ditandatangani oleh Otoritas Sertifikat (CA) yang kamu kendalikan. CA dan sertifikat ini +bisa digunakan oleh _workload_ untuk membangun kepercayaan. + +API `certificates.k8s.io` menggunakan protokol yang mirip dengan [konsep ACME](https://github.com/ietf-wg-acme/acme/). + +{{< note >}} +Sertifikat yang dibuat menggunakan API `certificates.k8s.io` ditandatangani oleh CA +khusus. Ini memungkinkan untuk mengkonfigurasi klaster kamu agar menggunakan CA _root_ klaster untuk tujuan ini, +namun jangan pernah mengandalkan ini. Jangan berasumsi bahwa sertifikat ini akan melakukan validasi +dengan CA _root_ klaster +{{< /note >}} + + + + +## {{% heading "prerequisites" %}} + + +{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}} + + + +<!-- steps --> + +## Mempercayai TLS dalam Klaster + +Mempercayai CA khusus dari aplikasi yang berjalan sebagai Pod biasanya memerlukan +beberapa tambahan konfigurasi aplikasi. Kamu harus menambahkan bundel sertifikat CA +ke daftar sertifikat CA yang dipercaya klien atau server TLS. +Misalnya, kamu akan melakukan ini dengan konfigurasi TLS golang dengan mengurai rantai sertifikat +dan menambahkan sertifikat yang diurai ke `RootCAs` di _struct_ +[`tls.Config`](https://godoc.org/crypto/tls#Config). + +Kamu bisa mendistribusikan sertifikat CA sebagai sebuah +[ConfigMap](/id/docs/tasks/configure-pod-container/configure-pod-configmap) yang bisa diakses oleh Pod kamu. + +## Meminta Sertifikat + +Bagian berikut mendemonstrasikan cara membuat sertifikat TLS untuk sebuah +Service kubernetes yang diakses melalui DNS. + +{{< note >}} +Tutorial ini menggunakan CFSSL: PKI dan peralatan TLS dari Cloudflare [klik disini](https://blog.cloudflare.com/introducing-cfssl/) untuk mengetahui lebih jauh. +{{< /note >}} + +## Unduh dan Pasang CFSSL + +Contoh ini menggunakan cfssl yang dapat diunduh pada +[https://pkg.cfssl.org/](https://pkg.cfssl.org/). + +## Membuat CertificateSigningRequest + +Buat kunci pribadi dan CertificateSigningRequest (CSR) dengan menggunakan perintah berikut: + +```shell +cat <<EOF | cfssl genkey - | cfssljson -bare server +{ + "hosts": [ + "my-svc.my-namespace.svc.cluster.local", + "my-pod.my-namespace.pod.cluster.local", + "192.0.2.24", + "10.0.34.2" + ], + "CN": "my-pod.my-namespace.pod.cluster.local", + "key": { + "algo": "ecdsa", + "size": 256 + } +} +EOF +``` + +`192.0.2.24` adalah klaster IP Service, +`my-svc.my-namespace.svc.cluster.local` adalah nama DNS Service, +`10.0.34.2` adalah IP Pod dan `my-pod.my-namespace.pod.cluster.local` +adalah nama DNS Pod. Kamu akan melihat keluaran berikut: + +``` +2017/03/21 06:48:17 [INFO] generate received request +2017/03/21 06:48:17 [INFO] received CSR +2017/03/21 06:48:17 [INFO] generating key: ecdsa-256 +2017/03/21 06:48:17 [INFO] encoded CSR +``` + +Perintah ini menghasilkan dua berkas; Ini menghasilkan `server.csr` yang berisi permintaan sertifikasi PEM +tersandi [pkcs#10](https://tools.ietf.org/html/rfc2986), +dan `server-key.pem` yang berisi PEM kunci yang tersandi untuk sertifikat yang +masih harus dibuat. + +## Membuat objek CertificateSigningRequest untuk dikirim ke API Kubernetes +Buat sebuah yaml CSR dan kirim ke API Server dengan menggunakan perintah berikut: + +```shell +cat <<EOF | kubectl apply -f - +apiVersion: certificates.k8s.io/v1beta1 +kind: CertificateSigningRequest +metadata: + name: my-svc.my-namespace +spec: + request: $(cat server.csr | base64 | tr -d '\n') + usages: + - digital signature + - key encipherment + - server auth +EOF +``` + +Perhatikan bahwa berkas `server.csr` yang dibuat pada langkah 1 merupakan base64 tersandi +dan disimpan di _field_ `.spec.request`. Kami juga meminta +sertifikat dengan penggunaan kunci "_digital signature_", "_key enchiperment_", dan "_server +auth_". Kami mendukung semua penggunaan kunci dan penggunaan kunci yang diperpanjang yang terdaftar +[di sini](https://godoc.org/k8s.io/api/certificates/v1beta1#KeyUsage) +sehingga kamu dapat meminta sertifikat klien dan sertifikat lain menggunakan +API yang sama. + +CSR semestinya bisa dilihat dari API pada status _Pending_. Kamu bisa melihatnya dengan menjalankan: + +```shell +kubectl describe csr my-svc.my-namespace +``` + +```none +Name: my-svc.my-namespace +Labels: <none> +Annotations: <none> +CreationTimestamp: Tue, 21 Mar 2017 07:03:51 -0700 +Requesting User: yourname@example.com +Status: Pending +Subject: + Common Name: my-svc.my-namespace.svc.cluster.local + Serial Number: +Subject Alternative Names: + DNS Names: my-svc.my-namespace.svc.cluster.local + IP Addresses: 192.0.2.24 + 10.0.34.2 +Events: <none> +``` + +## Mendapatkan Persetujuan CertificateSigningRequest + +Penyetujuan CertificateSigningRequest dapat dilakukan dengan otomatis +atau dilakukan sekali oleh administrator klaster. Informasi lebih lanjut tentang +apa yang terjadi dibahas dibawah ini. + +## Unduh dan Gunakan Sertifikat + +Setelah CSR ditandatangani dan disetujui, kamu akan melihat: + +```shell +kubectl get csr +``` + +```none +NAME AGE REQUESTOR CONDITION +my-svc.my-namespace 10m yourname@example.com Approved,Issued +``` + +Kamu bisa mengundur sertifikat yang telah diterbitkan dan menyimpannya ke berkas +`server.crt` dengan menggunakan perintah berikut: + +```shell +kubectl get csr my-svc.my-namespace -o jsonpath='{.status.certificate}' \ + | base64 --decode > server.crt +``` + +Sekarang kamu bisa menggunakan `server.crt` dan `server-key.pem` sebagai pasangan +kunci untuk memulai server HTTPS kamu. + +## Penyetujuan CertificateSigningRequest + +Administrator Kubernetes (dengan izin yang cukup) dapat menyetujui secara manual +(atau menolak) Certificate Signing Requests dengan menggunakan perintah `kubectl certificate +approve` dan `kubectl certificate deny`. Namun jika kamu bermaksud +untuk menggunakan API ini secara sering, kamu dapat mempertimbangkan untuk menulis +Certificate _controller_ otomatis. + +Baik itu mesin atau manusia yang menggunakan kubectl seperti di atas, peran pemberi persetujuan adalah +untuk memverifikasi bahwa CSR memenuhi dua persyaratan: +1. Subjek CSR mengontrol kunci pribadi yang digunakan untuk menandatangani CSR. Ini + mengatasi ancaman pihak ketiga yang menyamar sebagai subjek resmi. + Pada contoh di atas, langkah ini adalah untuk memverifikasi bahwa Pod mengontrol + kunci pribadi yang digunakan untuk menghasilkan CSR. +2. Subjek CSR berwenang untuk bertindak dalam konteks yang diminta. Ini + mengatasi ancaman subjek yang tidak diinginkan bergabung dengan klaster. Dalam + contoh di atas, langkah ini untuk memverifikasi bahwa Pod diizinkan + berpartisipasi dalam Service yang diminta. + +Jika dan hanya jika kedua persyaratan ini dipenuhi, pemberi persetujuan harus menyetujui +CSR dan sebaliknya harus menolak CSR. + +## Peringatan tentang Izin Persetujuan + +Kemampuan untuk menyetujui CSR menentukan siapa yang mempercayai siapa di dalam lingkungan kamu. +Kemampuan untuk menyetujui CSR tersebut seharusnya tidak diberikan secara luas. +Persyaratan tantangan yang disebutkan di bagian sebelumnya dan +dampak dari mengeluarkan sertifikat khusus, harus sepenuhnya dipahami +sebelum memberikan izin ini. + +## Catatan Untuk Administrator Klaster + +Tutorial ini mengasumsikan bahwa penanda tangan diatur untuk melayani API sertifikat. +Kubernetes _controller manager_ menyediakan implementasi bawaan dari penanda tangan. Untuk +mengaktifkan, berikan parameter `--cluster-signed-cert-file` dan +`--cluster-signed-key-file` ke _controller manager_ dengan _path_ ke +pasangan kunci CA kamu. + diff --git a/content/id/docs/tasks/tools/install-kubectl.md b/content/id/docs/tasks/tools/install-kubectl.md index e4d0019c3e..bc112c3cdd 100644 --- a/content/id/docs/tasks/tools/install-kubectl.md +++ b/content/id/docs/tasks/tools/install-kubectl.md @@ -284,7 +284,7 @@ Kamu dapat menginstal `kubectl` sebagai bagian dari Google Cloud SDK. ## Memeriksa konfigurasi kubectl -Agar `kubectl` dapat mengakses klaster Kubernetes, dibutuhkan sebuah [berkas kubeconfig](/docs/tasks/access-application-cluster/configure-access-multiple-clusters/), yang akan otomatis dibuat ketika kamu membuat klaster baru menggunakan [kube-up.sh](https://github.com/kubernetes/kubernetes/blob/master/cluster/kube-up.sh) atau setelah berhasil men-_deploy_ klaster Minikube. Secara bawaan, konfigurasi `kubectl` disimpan di `~/.kube/config`. +Agar `kubectl` dapat mengakses klaster Kubernetes, dibutuhkan sebuah [berkas kubeconfig](/id/docs/tasks/access-application-cluster/configure-access-multiple-clusters/), yang akan otomatis dibuat ketika kamu membuat klaster baru menggunakan [kube-up.sh](https://github.com/kubernetes/kubernetes/blob/master/cluster/kube-up.sh) atau setelah berhasil men-_deploy_ klaster Minikube. Secara bawaan, konfigurasi `kubectl` disimpan di `~/.kube/config`. Kamu dapat memeriksa apakah konfigurasi `kubectl` sudah benar dengan mengambil keadaan klaster: @@ -490,9 +490,9 @@ compinit ## {{% heading "whatsnext" %}} -* [Menginstal Minikube.](/docs/tasks/tools/install-minikube/) +* [Menginstal Minikube.](/id/docs/tasks/tools/install-minikube/) * Lihat [panduan persiapan](/docs/setup/) untuk mencari tahu tentang pembuatan klaster. * [Pelajari cara untuk menjalankan dan mengekspos aplikasimu.](/docs/tasks/access-application-cluster/service-access-application-cluster/) -* Jika kamu membutuhkan akses ke klaster yang tidak kamu buat, lihat [dokumen Berbagi Akses Klaster](/docs/tasks/access-application-cluster/configure-access-multiple-clusters/). +* Jika kamu membutuhkan akses ke klaster yang tidak kamu buat, lihat [dokumen Berbagi Akses Klaster](/id/docs/tasks/access-application-cluster/configure-access-multiple-clusters/). * Baca [dokumen referensi kubectl](/docs/reference/kubectl/kubectl/) diff --git a/content/id/docs/tasks/tools/install-minikube.md b/content/id/docs/tasks/tools/install-minikube.md index 342f05246a..d3e10f4fd6 100644 --- a/content/id/docs/tasks/tools/install-minikube.md +++ b/content/id/docs/tasks/tools/install-minikube.md @@ -9,7 +9,7 @@ card: <!-- overview --> -Halaman ini menunjukkan cara instalasi [Minikube](/docs/tutorials/hello-minikube), sebuah alat untuk menjalankan sebuah klaster Kubernetes dengan satu Node pada mesin virtual yang ada di komputer kamu. +Halaman ini menunjukkan cara instalasi [Minikube](/id/docs/tutorials/hello-minikube), sebuah alat untuk menjalankan sebuah klaster Kubernetes dengan satu Node pada mesin virtual yang ada di komputer kamu. @@ -65,7 +65,7 @@ Hyper-V Requirements: A hypervisor has been detected. Features required for ### Menginstal kubectl -Pastikan kamu mempunyai kubectl yang terinstal. Kamu bisa menginstal kubectl dengan mengikuti instruksi pada halaman [Menginstal dan Menyiapkan kubectl](/docs/tasks/tools/install-kubectl/#install-kubectl-on-linux). +Pastikan kamu mempunyai kubectl yang terinstal. Kamu bisa menginstal kubectl dengan mengikuti instruksi pada halaman [Menginstal dan Menyiapkan kubectl](/id/docs/tasks/tools/install-kubectl/#install-kubectl-on-linux). ### Menginstal sebuah Hypervisor @@ -125,7 +125,7 @@ brew install minikube {{% tab name="macOS" %}} ### Instalasi kubectl -Pastikan kamu mempunyai kubectl yang terinstal. Kamu bisa menginstal kubectl berdasarkan instruksi pada laman [Menginstal dan Menyiapkan kubectl](/docs/tasks/tools/install-kubectl/#install-kubectl-on-macos). +Pastikan kamu mempunyai kubectl yang terinstal. Kamu bisa menginstal kubectl berdasarkan instruksi pada laman [Menginstal dan Menyiapkan kubectl](/id/docs/tasks/tools/install-kubectl/#install-kubectl-on-macos). ### Instalasi sebuah Hypervisor @@ -161,7 +161,7 @@ sudo mv minikube /usr/local/bin {{% tab name="Windows" %}} ### Instalasi kubectl -Pastikan kamu mempunyai kubectl yang terinstal. Kamu bisa menginstal kubectl berdasarkan instruksi pada halaman [Menginstal dan Menyiapkan kubectl](/docs/tasks/tools/install-kubectl/#install-kubectl-on-windows). +Pastikan kamu mempunyai kubectl yang terinstal. Kamu bisa menginstal kubectl berdasarkan instruksi pada halaman [Menginstal dan Menyiapkan kubectl](/id/docs/tasks/tools/install-kubectl/#install-kubectl-on-windows). ### Menginstal sebuah Hypervisor diff --git a/content/id/docs/tasks/tools/kubeadm/_index.md b/content/id/docs/tasks/tools/kubeadm/_index.md new file mode 100644 index 0000000000..e342c2da51 --- /dev/null +++ b/content/id/docs/tasks/tools/kubeadm/_index.md @@ -0,0 +1,4 @@ +--- +title: "Membangun klaster menggunakan kubeadm" +weight: 10 +--- diff --git a/content/id/docs/tutorials/_index.md b/content/id/docs/tutorials/_index.md index 1093644e15..f56702b94e 100644 --- a/content/id/docs/tutorials/_index.md +++ b/content/id/docs/tutorials/_index.md @@ -24,7 +24,7 @@ Sebelum melangkah lebih lanjut ke tutorial, sebaiknya tandai dulu halaman [Kamus * [Pengenalan Kubernetes (edX)](https://www.edx.org/course/introduction-kubernetes-linuxfoundationx-lfs158x#) -* [Halo Minikube](/docs/tutorials/hello-minikube/) +* [Halo Minikube](/id/docs/tutorials/hello-minikube/) ## Konfigurasi @@ -32,7 +32,7 @@ Sebelum melangkah lebih lanjut ke tutorial, sebaiknya tandai dulu halaman [Kamus ## Aplikasi Stateless -* [Memberi Akses Aplikasi di dalam Klaster melalui IP Eksternal](/docs/tutorials/stateless-application/expose-external-ip-address/) +* [Memberi Akses Aplikasi di dalam Klaster melalui IP Eksternal](/id/docs/tutorials/stateless-application/expose-external-ip-address/) * [Contoh: Deploy aplikasi Guestbook PHP dengan Redis](/docs/tutorials/stateless-application/guestbook/) diff --git a/content/id/docs/tutorials/hello-minikube.md b/content/id/docs/tutorials/hello-minikube.md index f2588e776b..faba283d89 100644 --- a/content/id/docs/tutorials/hello-minikube.md +++ b/content/id/docs/tutorials/hello-minikube.md @@ -19,7 +19,7 @@ Tutorial ini menunjukkan bagaimana caranya menjalankan aplikasi sederhana Node.j Katacoda menyediakan <i>environment</i> Kubernetes secara gratis di dalam browser. {{< note >}} -Kamupun bisa mengikuti tutorial ini kalau sudah instalasi [Minikube di lokal](/docs/tasks/tools/install-minikube/) kamu. +Kamupun bisa mengikuti tutorial ini kalau sudah instalasi [Minikube di lokal](/id/docs/tasks/tools/install-minikube/) kamu. {{< /note >}} @@ -68,9 +68,9 @@ Untuk info lebih lanjut tentang perintah `docker build`, baca [dokumentasi Docke ## Membuat sebuah Deployment -Sebuah Kubernetes [*Pod*](/docs/concepts/workloads/pods/pod/) adalah kumpulan dari satu atau banyak Kontainer, +Sebuah Kubernetes [*Pod*](/id/docs/concepts/workloads/pods/pod/) adalah kumpulan dari satu atau banyak Kontainer, saling terhubung untuk kebutuhan administrasi dan jaringan. Pod dalam tutorial ini hanya punya satu Kontainer. Sebuah Kubernetes -[*Deployment*](/docs/concepts/workloads/controllers/deployment/) selalu memeriksa kesehatan +[*Deployment*](/id/docs/concepts/workloads/controllers/deployment/) selalu memeriksa kesehatan Pod kamu dan melakukan <i>restart</i> saat Kontainer di dalam Pod tersebut mati. Deployment adalah cara jitu untuk membuat dan mereplikasi Pod. 1. Gunakan perintah `kubectl create` untuk membuat Deployment yang dapat mengatur Pod. @@ -122,7 +122,7 @@ Pod menjalankan Kontainer sesuai dengan image Docker yang telah diberikan. ## Membuat sebuah Servis Secara <i>default</i>, Pod hanya bisa diakses melalui alamat IP internal di dalam klaster Kubernetes. -Supaya Kontainer `hello-node` bisa diakses dari luar jaringan virtual Kubernetes, kamu harus ekspos Pod sebagai [*Servis*](/docs/concepts/services-networking/service/) Kubernetes. +Supaya Kontainer `hello-node` bisa diakses dari luar jaringan virtual Kubernetes, kamu harus ekspos Pod sebagai [*Servis*](/id/docs/concepts/services-networking/service/) Kubernetes. 1. Ekspos Pod pada internet publik menggunakan perintah `kubectl expose`: @@ -266,8 +266,8 @@ minikube delete ## {{% heading "whatsnext" %}} -* Pelajari lebih lanjut tentang [Deployment](/docs/concepts/workloads/controllers/deployment/). +* Pelajari lebih lanjut tentang [Deployment](/id/docs/concepts/workloads/controllers/deployment/). * Pelajari lebih lanjut tentang [Deploy aplikasi](/docs/user-guide/deploying-applications/). -* Pelajari lebih lanjut tentang [Servis](/docs/concepts/services-networking/service/). +* Pelajari lebih lanjut tentang [Servis](/id/docs/concepts/services-networking/service/). diff --git a/content/id/docs/tutorials/kubernetes-basics/create-cluster/_index.md b/content/id/docs/tutorials/kubernetes-basics/create-cluster/_index.md new file mode 100644 index 0000000000..6ae659eca3 --- /dev/null +++ b/content/id/docs/tutorials/kubernetes-basics/create-cluster/_index.md @@ -0,0 +1,4 @@ +--- +title: Membuat Klaster +weight: 10 +--- diff --git a/content/id/docs/tutorials/kubernetes-basics/create-cluster/cluster-interactive.html b/content/id/docs/tutorials/kubernetes-basics/create-cluster/cluster-interactive.html new file mode 100644 index 0000000000..aeae9f469d --- /dev/null +++ b/content/id/docs/tutorials/kubernetes-basics/create-cluster/cluster-interactive.html @@ -0,0 +1,37 @@ +--- +title: Tutorial Interaktif - Membuat Klaster +weight: 20 +--- + +<!DOCTYPE html> + +<html lang="id"> + +<body> + +<link href="/docs/tutorials/kubernetes-basics/public/css/styles.css" rel="stylesheet"> +<link href="/docs/tutorials/kubernetes-basics/public/css/overrides.css" rel="stylesheet"> +<script src="https://katacoda.com/embed.js"></script> + +<div class="layout" id="top"> + + <main class="content katacoda-content"> + + <div class="katacoda"> + <div class="katacoda__alert"> + Layar terlalu kecil untuk berinteraksi dengan Terminal, silahkan gunakan desktop/tablet. + </div> + <div class="katacoda__box" id="inline-terminal-1" data-katacoda-lang="id" data-katacoda-id="kubernetes-bootcamp/1" data-katacoda-color="326de6" data-katacoda-secondary="273d6d" data-katacoda-hideintro="false" data-katacoda-font="Roboto" data-katacoda-fontheader="Roboto Slab" data-katacoda-prompt="Kubernetes Bootcamp Terminal" style="height: 600px;"></div> + </div> + <div class="row"> + <div class="col-md-12"> + <a class="btn btn-lg btn-success" href="/docs/tutorials/kubernetes-basics/deploy-app/deploy-intro/" role="button">Lanjut ke Modul 2<span class="btn__next">›</span></a> + </div> + </div> + + </main> + +</div> + +</body> +</html> diff --git a/content/id/docs/tutorials/kubernetes-basics/create-cluster/cluster-intro.html b/content/id/docs/tutorials/kubernetes-basics/create-cluster/cluster-intro.html new file mode 100644 index 0000000000..debeaf6d48 --- /dev/null +++ b/content/id/docs/tutorials/kubernetes-basics/create-cluster/cluster-intro.html @@ -0,0 +1,107 @@ +--- +title: Menggunakan Minikube Untuk Membuat Klaster +weight: 10 +--- + +<!DOCTYPE html> + +<html lang="id"> + +<body> + + <link href="/docs/tutorials/kubernetes-basics/public/css/styles.css" rel="stylesheet"> + +<div class="layout" id="top"> + + <main class="content"> + + <div class="row"> + + <div class="col-md-8"> + <h3>Objectives</h3> + <ul> + <li>Belajar apa itu klaster Kubernetes.</li> + <li>Belajar apa itu Minikube.</li> + <li>Memulai klaster Kubernetes menggunakan terminal _online_.</li> + </ul> + </div> + + <div class="col-md-8"> + <h3>Klaster Kubernetes</h3> + <p> + <b>Kubernetes mengoordinasikan klaster komputer ketersediaan tinggi (_highly available_) yang saling terhubung sebagai unit tunggal.</b> Abstraksi pada Kubernetes mengizinkan kamu untuk men-_deploy_ aplikasi terkemas (_containerized_) ke sebuah klaster tanpa perlu membalutnya secara spesifik pada setiap mesin. Untuk menggunakan model baru _deployment_ ini, aplikasi perlu dikemas dengan cara memisahkan mereka dari hos individu: mereka perlu dikemas. Aplikasi terkemas lebih fleksibel dan tersedia dibanding model _deployment_ lama, dimana aplikasi dipasang secara langsung didalam mesin spesifik sebagai paket yang sangat terintegrasi dengan hos. <b>Kubernetes mengotomasisasikan distribusi dan penjadwalan kontainer aplikasi sebuah klaster secara menyeluruh dengan cara yang lebih efisien.</b> Kubernetes merupakan platform _open-source_ dan siap produksi. + </p> + <p>Klaster Kubernetes terdiri dari 2 tipe sumber daya: + <ul> + <li><b>Master</b> mengoordinasikan klaster</li> + <li><b>Node</b> adalah pekerja (_worker_) yang menjalankan aplikasi</li> + </ul> + </p> + </div> + + <div class="col-md-4"> + <div class="content_box content_box_lined"> + <h3>Summary:</h3> + <ul> + <li>Klaster Kubernetes</li> + <li>Minikube</li> + </ul> + </div> + <div class="content_box content_box_fill"> + <p><i> + Kubernetes merupakan platform _open-source_ tingkat produksi yang mengatur penjadwalan dan eksekusi kontainer aplikasi didalam dan keseluruhan klaster komputer. + </i></p> + </div> + </div> + </div> + <br> + + <div class="row"> + <div class="col-md-8"> + <h2 style="color: #3771e3;">Diagram Klaster</h2> + </div> + </div> + + <div class="row"> + <div class="col-md-8"> + <p><img src="/docs/tutorials/kubernetes-basics/public/images/module_01_cluster.svg"></p> + </div> + </div> + <br> + + <div class="row"> + <div class="col-md-8"> + <p><b>Master mempunyai kewajiban untuk mengelola klaster.</b> Master mengoordinasikan semua aktifitas di klaster kamu, seperti penjadwalan aplikasi, pemeliharaan keadaan (_state_) aplikasi yang diinginkan, _scaling_ aplikasi, dan _roll-out_ pembaharuan.</p> + <p><b>Node merupakan VM atau komputer fisik yang berfungsi sebagai mesin pekerja dalam klaster Kubernetes.</b> Setiap node mempunyai Kubelet, sebuah agen untuk mengatur Node dan komunikasi dengan Kubernetes master. Node juga harus mempunyai alat untuk menangani operasi kontainer, seperti Docker atau rkt. Sebuah klaster Kubernetes yang menangani trafik produksi harus mempunyai minimal 3 Node.</p> + </div> + <div class="col-md-4"> + <div class="content_box content_box_fill"> + <p><i>Master mengatur klaster dan Node yang digunakan sebagai hos dari aplikasi yang berjalan.</i></p> + </div> + </div> + </div> + + <div class="row"> + <div class="col-md-8"> + <p>Ketika kamu men-_deploy_ aplikasi pada Kubernetes, kamu memberitahu master untuk memulai kontainer aplikasi. Master melakukan penjadwalan kontainer untuk berjalan diatas klaster Node. <b>Node berkomunikasi dengan master menggunakan <a href="/docs/concepts/overview/kubernetes-api/">Kubernetes API</a></b>, yang disediakan oleh master. Pengguna akhir juga dapat menggunakan Kubernetes API secara langsung untuk berinteraksi dengan klaster.</p> + + <p>Klaster Kubernetes dapat di-_deploy_ ke mesik fisik maupun virtual. Untuk memulai pengembangan Kubernetes, kamu dapat menggunakan Minikube. Minikube merupakan implementasi Kubernetes ringan yang membuat VM padi mesin lokal kamu dan men-_deploy_ klaster sederhanya yang terdiri atas 1 Node. Minikube tersedia untuk Linux, macOS, dan sistem Windows. Minikube CLI menyediakan operasi _bootstraping_ dasar untuk bekerja dengan klaster kamu. Namun untuk tutorial ini, kamu akan menggunakan online terminal yang sudah disediakan dengan Minikube yang sudah diinstall sebelumnya.</p> + + <p>Sekarang kamu telah mengetahui apa itu Kubernetes, mari kita pergi ke tutorial online dan memulai klaster pertama kita!</p> + + </div> + </div> + <br> + + <div class="row"> + <div class="col-md-12"> + <a class="btn btn-lg btn-success" href="/docs/tutorials/kubernetes-basics/create-cluster/cluster-interactive/" role="button">Mulai Tutorial Interaktif<span class="btn_next">›</span></a> + </div> + </div> + + </main> + +</div> + +</body> +</html> diff --git a/content/id/docs/tutorials/stateless-application/_index.md b/content/id/docs/tutorials/stateless-application/_index.md new file mode 100644 index 0000000000..6923ee8165 --- /dev/null +++ b/content/id/docs/tutorials/stateless-application/_index.md @@ -0,0 +1,5 @@ +--- +title: "Aplikasi Stateless" +weight: 40 +--- + diff --git a/content/id/docs/tutorials/stateless-application/expose-external-ip-address.md b/content/id/docs/tutorials/stateless-application/expose-external-ip-address.md new file mode 100644 index 0000000000..df297f4c63 --- /dev/null +++ b/content/id/docs/tutorials/stateless-application/expose-external-ip-address.md @@ -0,0 +1,173 @@ +--- +title: Mengekspos Alamat IP Eksternal untuk Mengakses Aplikasi di dalam Klaster +content_type: tutorial +weight: 10 +--- + +<!-- overview --> + +Dokumen ini menjelaskan bagaimana cara membuat objek Service Kubernetes +yang mengekspos alamat IP eksternal. + + + + +## {{% heading "prerequisites" %}} + + + * Instal [kubectl](/id/docs/tasks/tools/install-kubectl/). + + * Gunakan sebuah penyedia layanan cloud seperti Google Kubernetes Engine atau Amazon Web Services + untuk membuat sebuah klaster Kubernetes. Tutorial ini membuat sebuah + [_load balancer_ eksternal](/id/docs/tasks/access-application-cluster/create-external-load-balancer/), + yang membutuhkan sebuah penyedia layanan cloud. + + * Konfigurasi `kubectl` agar dapat berkomunikasi dengan Kubernetes API Server kamu. + Untuk informasi lebih lanjut, kamu dapat merujuk pada dokumentasi penyedia layanan cloud + yang kamu gunakan. + + + +## {{% heading "objectives" %}} + +* Jalankan lima buah instans dari aplikasi Hello World. +* Buatlah sebuah objek Service yang mengekspos sebuah alamat IP eksternal. +* Gunakan sebuah objek Service untuk mengakses aplikasi yang sedang dijalankan. + + + +<!-- lessoncontent --> + +## Membuat sebuah objek Service untuk sebuah aplikasi yang dijalankan pada lima buah Pod + +1. Jalankan sebuah aplikasi Hello World pada klaster kamu: + +{{< codenew file="service/load-balancer-example.yaml" >}} + +```shell +kubectl apply -f https://k8s.io/examples/service/load-balancer-example.yaml +``` + + +Perintah di atas akan membuat sebuah + objek [Deployment](/id/docs/concepts/workloads/controllers/deployment/) + dan sebuah objek + [ReplicaSet](/id/docs/concepts/workloads/controllers/replicaset/) + yang diasosiasikan dengan Deployment yang dibuat. ReplicaSet memiliki lima buah + [Pod](/id/docs/concepts/workloads/pods/pod/), + yang masing-masing dari Pod tersebut menjalankan aplikasi Hello World. + +1. Tampilkan informasi mengenai Deployment: + + kubectl get deployments hello-world + kubectl describe deployments hello-world + +1. Tampilkan informasi mengenai objek ReplicaSet: + + kubectl get replicasets + kubectl describe replicasets + +1. Buatlah sebuah objek Service yang mengekspos deployment: + + kubectl expose deployment hello-world --type=LoadBalancer --name=my-service + +1. Tampilkan informasi mengenai Service: + + kubectl get services my-service + + Keluaran dari perintah di atas akan menyerupai tampilan berikut: + + NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE + my-service LoadBalancer 10.3.245.137 104.198.205.71 8080/TCP 54s + + {{< note >}} + + Service dengan `type=LoadBalancer` didukung oleh penyedia layanan cloud eksternal, yang tidak tercakup dalam contoh ini, silahkan merujuk pada [laman berikut](/id/docs/concepts/services-networking/service/#loadbalancer) untuk informasi lebih lanjut. + + {{< /note >}} + + {{< note >}} + + Jika sebuah alamat IP eksternal yang ditunjukkan dalam status \<pending\>, tunggulah hingga satu menit kemudian masukkan perintah yang sama lagi. + + {{< /note >}} + +1. Tampilkan informasi detail mengenai Service: + + kubectl describe services my-service + + Perintah di atas akan menampilkan keluaran sebagai berikut: + + Name: my-service + Namespace: default + Labels: app.kubernetes.io/name=load-balancer-example + Annotations: <none> + Selector: app.kubernetes.io/name=load-balancer-example + Type: LoadBalancer + IP: 10.3.245.137 + LoadBalancer Ingress: 104.198.205.71 + Port: <unset> 8080/TCP + NodePort: <unset> 32377/TCP + Endpoints: 10.0.0.6:8080,10.0.1.6:8080,10.0.1.7:8080 + 2 more... + Session Affinity: None + Events: <none> + + Pastikan nilai dari alamat IP eksternal (`LoadBalancer Ingress`) diekspos + pada Service yang kamu buat. Pada contoh ini, alamat IP eksternal yang diberikan adalah 104.198.205.71. + Kemudian pastikan nilai dari `Port` dan `NodePort`. Pada contoh ini, `Port` + yang digunakan adalah 8080 dan `NodePort` adalah 32377. + +1. Pada keluaran perintah sebelumnya, kamu dapat melihat beberapa Service dengan beberapa endpoint: + 10.0.0.6:8080,10.0.1.6:8080,10.0.1.7:8080 + 2 lainnya. Berikut ini merupakan alamat IP dari Pod + dimana aplikasi tersebut dijalankan. Untuk melakukan verifikasi alamat-alamat IP yang digunakan oleh Pod, + masukkan perintah berikut: + + kubectl get pods --output=wide + + Keluaran yang diberikan akan menyerupai: + + NAME ... IP NODE + hello-world-2895499144-1jaz9 ... 10.0.1.6 gke-cluster-1-default-pool-e0b8d269-1afc + hello-world-2895499144-2e5uh ... 10.0.1.8 gke-cluster-1-default-pool-e0b8d269-1afc + hello-world-2895499144-9m4h1 ... 10.0.0.6 gke-cluster-1-default-pool-e0b8d269-5v7a + hello-world-2895499144-o4z13 ... 10.0.1.7 gke-cluster-1-default-pool-e0b8d269-1afc + hello-world-2895499144-segjf ... 10.0.2.5 gke-cluster-1-default-pool-e0b8d269-cpuc + +1. Gunakan alamat IP eksternal (`LoadBalancer Ingress`) untuk mengakses aplikasi Hello World: + + curl http://<external-ip>:<port> + + dimana `<external-ip>` adalah alamat IP eksternal (`LoadBalancer Ingress`) + dari Service kamu, dan `<port>` adalah nilai dari `Port` dari deskripsi Service kamu. + Jika kamu menggunakan minikube, menuliskan perintah `minikube service my-service` akan + secara otomatis membuka aplikasi Hello World pada _browser_. + + Respons yang diberikan apabila permintaan ini berhasil adalah sebuah pesan sapaan: + + Hello Kubernetes! + + + + +## {{% heading "cleanup" %}} + + +Untuk menghapus Service, kamu dapat menggunakan perintah ini: + + kubectl delete services my-service + +Untuk menghapus Deployment, ReplicaSet, dan Pod-Pod yang digunakan untuk +menjalankan aplikasi Hello World, kamu dapat memasukkan perintah berikut: + + kubectl delete deployment hello-world + + + + +## {{% heading "whatsnext" %}} + + +Pelajari lebih lanjut cara untuk +[menghubungkan aplikasi dengan berbagai Service](/id/docs/concepts/services-networking/connect-applications-service/). + + diff --git a/content/id/examples/application/deployment-scale.yaml b/content/id/examples/application/deployment-scale.yaml new file mode 100644 index 0000000000..84e326eee1 --- /dev/null +++ b/content/id/examples/application/deployment-scale.yaml @@ -0,0 +1,19 @@ +apiVersion: apps/v1 # untuk versi sebelum 1.9.0 gunakan apps/v1beta2 +kind: Deployment +metadata: + name: nginx-deployment +spec: + selector: + matchLabels: + app: nginx + replicas: 4 # Memperbarui replica dari 2 menjadi 4 + template: + metadata: + labels: + app: nginx + spec: + containers: + - name: nginx + image: nginx:1.14.2 + ports: + - containerPort: 80 diff --git a/content/id/examples/application/deployment-update.yaml b/content/id/examples/application/deployment-update.yaml new file mode 100644 index 0000000000..63fbdb69cf --- /dev/null +++ b/content/id/examples/application/deployment-update.yaml @@ -0,0 +1,19 @@ +apiVersion: apps/v1 # untuk versi sebelum 1.9.0 gunakan apps/v1beta2 +kind: Deployment +metadata: + name: nginx-deployment +spec: + selector: + matchLabels: + app: nginx + replicas: 2 + template: + metadata: + labels: + app: nginx + spec: + containers: + - name: nginx + image: nginx:1.16.1 # Memperbarui versi nginx dari 1.14.2 ke 1.16.1 + ports: + - containerPort: 80 diff --git a/content/id/examples/pods/pod-nginx-preferred-affinity.yaml b/content/id/examples/pods/pod-nginx-preferred-affinity.yaml new file mode 100644 index 0000000000..f169576bc2 --- /dev/null +++ b/content/id/examples/pods/pod-nginx-preferred-affinity.yaml @@ -0,0 +1,20 @@ +apiVersion: v1 +kind: Pod +metadata: + name: nginx +spec: + affinity: + nodeAffinity: + preferredDuringSchedulingIgnoredDuringExecution: + - weight: 1 + preference: + matchExpressions: + - key: disktype + operator: In + values: + - ssd + containers: + - name: nginx + image: nginx + imagePullPolicy: IfNotPresent + diff --git a/content/id/examples/pods/pod-nginx-required-affinity.yaml b/content/id/examples/pods/pod-nginx-required-affinity.yaml new file mode 100644 index 0000000000..a1093da188 --- /dev/null +++ b/content/id/examples/pods/pod-nginx-required-affinity.yaml @@ -0,0 +1,19 @@ +apiVersion: v1 +kind: Pod +metadata: + name: nginx +spec: + affinity: + nodeAffinity: + requiredDuringSchedulingIgnoredDuringExecution: + nodeSelectorTerms: + - matchExpressions: + - key: disktype + operator: In + values: + - ssd + containers: + - name: nginx + image: nginx + imagePullPolicy: IfNotPresent + diff --git a/content/id/examples/pods/pod-projected-svc-token.yaml b/content/id/examples/pods/pod-projected-svc-token.yaml new file mode 100644 index 0000000000..985073c8d3 --- /dev/null +++ b/content/id/examples/pods/pod-projected-svc-token.yaml @@ -0,0 +1,20 @@ +apiVersion: v1 +kind: Pod +metadata: + name: nginx +spec: + containers: + - image: nginx + name: nginx + volumeMounts: + - mountPath: /var/run/secrets/tokens + name: vault-token + serviceAccountName: build-robot + volumes: + - name: vault-token + projected: + sources: + - serviceAccountToken: + path: vault-token + expirationSeconds: 7200 + audience: vault diff --git a/content/id/examples/pods/private-reg-pod.yaml b/content/id/examples/pods/private-reg-pod.yaml new file mode 100644 index 0000000000..594e47a7c5 --- /dev/null +++ b/content/id/examples/pods/private-reg-pod.yaml @@ -0,0 +1,11 @@ +apiVersion: v1 +kind: Pod +metadata: + name: private-reg +spec: + containers: + - name: private-reg-container + image: <image-pribadi-kamu> + imagePullSecrets: + - name: regcred + diff --git a/content/id/examples/pods/share-process-namespace.yaml b/content/id/examples/pods/share-process-namespace.yaml new file mode 100644 index 0000000000..af812732a2 --- /dev/null +++ b/content/id/examples/pods/share-process-namespace.yaml @@ -0,0 +1,17 @@ +apiVersion: v1 +kind: Pod +metadata: + name: nginx +spec: + shareProcessNamespace: true + containers: + - name: nginx + image: nginx + - name: shell + image: busybox + securityContext: + capabilities: + add: + - SYS_PTRACE + stdin: true + tty: true diff --git a/content/id/examples/pods/topology-spread-constraints/one-constraint-with-nodeaffinity.yaml b/content/id/examples/pods/topology-spread-constraints/one-constraint-with-nodeaffinity.yaml new file mode 100644 index 0000000000..98823f9d86 --- /dev/null +++ b/content/id/examples/pods/topology-spread-constraints/one-constraint-with-nodeaffinity.yaml @@ -0,0 +1,26 @@ +kind: Pod +apiVersion: v1 +metadata: + name: mypod + labels: + foo: bar +spec: + topologySpreadConstraints: + - maxSkew: 1 + topologyKey: zone + whenUnsatisfiable: DoNotSchedule + labelSelector: + matchLabels: + foo: bar + affinity: + nodeAffinity: + requiredDuringSchedulingIgnoredDuringExecution: + nodeSelectorTerms: + - matchExpressions: + - key: zone + operator: NotIn + values: + - zoneC + containers: + - name: pause + image: k8s.gcr.io/pause:3.1 \ No newline at end of file diff --git a/content/id/examples/pods/topology-spread-constraints/one-constraint.yaml b/content/id/examples/pods/topology-spread-constraints/one-constraint.yaml new file mode 100644 index 0000000000..a0a41188ec --- /dev/null +++ b/content/id/examples/pods/topology-spread-constraints/one-constraint.yaml @@ -0,0 +1,17 @@ +kind: Pod +apiVersion: v1 +metadata: + name: mypod + labels: + foo: bar +spec: + topologySpreadConstraints: + - maxSkew: 1 + topologyKey: zone + whenUnsatisfiable: DoNotSchedule + labelSelector: + matchLabels: + foo: bar + containers: + - name: pause + image: k8s.gcr.io/pause:3.1 \ No newline at end of file diff --git a/content/id/examples/pods/topology-spread-constraints/two-constraints.yaml b/content/id/examples/pods/topology-spread-constraints/two-constraints.yaml new file mode 100644 index 0000000000..aa142b7abb --- /dev/null +++ b/content/id/examples/pods/topology-spread-constraints/two-constraints.yaml @@ -0,0 +1,23 @@ +kind: Pod +apiVersion: v1 +metadata: + name: mypod + labels: + foo: bar +spec: + topologySpreadConstraints: + - maxSkew: 1 + topologyKey: zone + whenUnsatisfiable: DoNotSchedule + labelSelector: + matchLabels: + foo: bar + - maxSkew: 1 + topologyKey: node + whenUnsatisfiable: DoNotSchedule + labelSelector: + matchLabels: + foo: bar + containers: + - name: pause + image: k8s.gcr.io/pause:3.1 \ No newline at end of file diff --git a/content/id/examples/service/load-balancer-example.yaml b/content/id/examples/service/load-balancer-example.yaml new file mode 100644 index 0000000000..ea88fd1548 --- /dev/null +++ b/content/id/examples/service/load-balancer-example.yaml @@ -0,0 +1,21 @@ +apiVersion: apps/v1 +kind: Deployment +metadata: + labels: + app.kubernetes.io/name: load-balancer-example + name: hello-world +spec: + replicas: 5 + selector: + matchLabels: + app.kubernetes.io/name: load-balancer-example + template: + metadata: + labels: + app.kubernetes.io/name: load-balancer-example + spec: + containers: + - image: gcr.io/google-samples/node-hello:1.0 + name: hello-world + ports: + - containerPort: 8080 diff --git a/content/it/docs/concepts/_index.md b/content/it/docs/concepts/_index.md index 89b80f409d..a4175f8f8a 100644 --- a/content/it/docs/concepts/_index.md +++ b/content/it/docs/concepts/_index.md @@ -59,7 +59,7 @@ Il master Kubernetes è responsabile della gestione dello stato desiderato per i ### Kubernetes Nodes -I nodi di un cluster sono le macchine (VM, server fisici, ecc.) Che eseguono i flussi di lavoro delle applicazioni e del cloud. Il master Kubernetes controlla ciascun nodo; raramente interagirai direttamente con i nodi. +I nodi di un cluster sono le macchine (VM, server fisici, ecc.) che eseguono i flussi di lavoro delle applicazioni e del cloud. Il master Kubernetes controlla ciascun nodo; raramente interagirai direttamente con i nodi. #### Object Metadata diff --git a/content/it/docs/concepts/architecture/controller.md b/content/it/docs/concepts/architecture/controller.md new file mode 100644 index 0000000000..f8402fb161 --- /dev/null +++ b/content/it/docs/concepts/architecture/controller.md @@ -0,0 +1,90 @@ +--- +title: Controller +content_template: concept +weight: 30 +--- + +<!-- overview --> + +Nella robotica e nell'automazione, un _circuito di controllo_ (_control loop_) è un un'iterazione senza soluzione di continuità che regola lo stato di un sistema. + +Ecco un esempio di un circuito di controllo: il termostato di una stanza. + +Quando viene impostata la temperatura, si definisce attraverso il termostato lo *stato desiderato*. L'attuale temperatura nella stanza è invece lo *stato corrente*. Il termostato agisce per portare lo stato corrente il più vicino possibile allo stato desiderato accendendo e spegnendo le apparecchiature. + +{{< glossary_definition term_id="controller" length="short" >}} + +<!-- body --> + +## Il modello del controller + +Un _controller_ monitora almeno una tipo di risorsa registrata in Kubernetes. +Questi [oggetti](/docs/concepts/overview/working-with-objects/kubernetes-objects/#kubernetes-objects) hanno una proprietà chiamata *spec* (specifica) che rappresenta lo stato desiderato. Il o i *controller* per quella risorsa sono responsabili di mantenere lo stato corrente il più simile possibile rispetto allo stato desiderato. + +Il _controller_ potrebbe eseguire l'azione relativa alla risorsa in questione da sé; più comunemente, in Kubernetes, un _controller_ invia messaggi all'{{< glossary_tooltip text="API server" term_id="kube-apiserver" >}} che a sua volta li rende disponibili ad altri componenti nel cluster. Di seguito troverete esempi per questo scenario. + +{{< comment >}} +Alcuni controller nativi, come ad esempio l'_endpoints_ controller, agiscono su oggetti che non hanno una specifica. Per semplicità, questa pagina non entra in quel dettaglio. +{{< /comment >}} + +### Controllo attraverso l'API server + +Il {{< glossary_tooltip term_id="job" >}} _controller_ è un esempio di un _controller_ nativo in Kubernetes. I _controller_ nativi gestiscono lo stato interagendo con l'API server presente nel cluster. + +Il Job è una risorsa di Kubernetes che lancia uno o più {{< glossary_tooltip term_id="pod" text="Pod" >}} per eseguire un lavoro (task) e poi fermarsi. + +(Una volta che è stato [schedulato](/docs/concepts/scheduling-eviction/), un oggetto _Pod_ diventa parte dello stato desisderato di un dato _kubelet_). + +Quando il Job _controller_ vede un nuovo lavoro da svolgere si assicura che, da qualche parte nel cluster, i _kubelet_ anche sparsi su più nodi eseguano il numero corretto di _Pod_ necessari per eseguire il lavoro richiesto. Il Job _controller_ non esegue direttamente alcun _Pod_ o _container_ bensì chiede all'API server di creare o rimuovere i _Pod_. Altri componenti appartenenti al {{< glossary_tooltip text="control plane" term_id="control-plane" >}} reagiscono in base alle nuove informazioni (ci sono nuovi _Pod_ da creare e gestire) e cooperano al completamento del job. + +Dopo che un nuovo Job è stato creato, lo stato desiderato per quel Job è il suo completamento. Il Job _controller_ fa sì che lo stato corrente per quel Job sia il più vicino possibile allo stato desiderato: creare _Pod_ che eseguano il lavoro che deve essere effettuato attraverso il Job, così che il Job sia prossimo al completamento. + +I _controller_ aggiornano anche gli oggetti che hanno configurato. Ad esempio: una volta che il lavoro relativo ad un dato Job è stato completato, il Job _controller_ aggiorna l'oggetto Job segnandolo come `Finished`. + +(Questo è simile allo scenario del termostato che spegne un certo led per indicare che ora la stanza ha raggiungo la temperatura impostata) + +### Controllo diretto + +A differenza del Job, alcuni _controller_ devono eseguire delle modifiche a parti esterne al cluster. + +Per esempio, se viene usato un circuito di controllo per assicurare che ci sia un numero sufficiente di {{< glossary_tooltip text="Nodi" term_id="node" >}} nel cluster, allora il _controller_ ha bisogno che qualcosa al di fuori del cluster configuri i nuovi _Nodi_ quando sarà necessario. + +I _controller_ che interagiscono con un sistema esterno trovano il loro stato desiderato attraverso l'API server, quindi comunicano direttamente con un sistema esterno per portare il loro stato corrente più in linea possibile con lo stato desiderato + +(In realtà c'è un _controller_ che scala orizzontalmente i nodi nel cluster. Vedi [Cluster autoscaling](/docs/tasks/administer-cluster/cluster-management/#cluster-autoscaling)). + +## Stato desiderato versus corrente {#desiderato-vs-corrente} + +Kubernetes ha una visione *cloud-native* dei sistemi, ed è in grado di gestire continue modifiche. + +Il cluster viene modificato continuamente durante la sua attività ed il _circuito di controllo_ è in grado di risolvere automaticamente i possibili guasti. + +Fino a che i _controller_ del cluster sono in funzione ed in grado di apportare le dovute modifiche, non è rilevante che lo stato complessivo del cluster sia o meno stabile. + +## Progettazione + +Come cardine della sua progettazione, Kubernetes usa vari _controller_ ognuno dei quali è responsabile per un particolare aspetto dello stato del cluster. Più comunemente, un dato _circuito di controllo_ (_controller_) usa un tipo di risorsa per il suo stato desiderato, ed utilizza anche risorse di altro tipo per raggiungere questo stato desiderato. Per esempio il Job _controller_ tiene traccia degli oggetti di tipo _Job_ (per scoprire nuove attività da eseguire) e degli oggetti di tipo _Pod_ (questi ultimi usati per eseguire i _Job_, e quindi per controllare quando il loro lavoro è terminato). In questo caso, qualcos'altro crea i _Job_, mentre il _Job_ _controller_ crea i _Pod_. + +È utile avere semplici _controller_ piuttosto che un unico, monolitico, _circuito di controllo_. I _controller_ possono guastarsi, quindi Kubernetes è stato disegnato per gestire questa eventualità. + +{{< note >}} +Ci possono essere diversi _controller_ che creato o aggiornano lo stesso tipo di oggetti. Dietro le quinte, i _controller_ di Kubernetes si preoccupano esclusivamente delle risorse (di altro tipo) collegate alla risorsa primaria da essi controllata. + +Per esempio, si possono avere _Deployment_ e _Job_; entrambe creano _Pod_. Il Job _controller_ non distrugge i _Pod_ creati da un _Deployment_, perché ci sono informazioni (*{{< glossary_tooltip term_id="label" text="labels" >}}*) che vengono usate dal _controller_ per distinguere i _Pod_. +{{< /note >}} + +## I modi per eseguire i _controller_ {#eseguire-controller} + +Kubernetes annovera un insieme di _controller_ nativi che sono in esecuzione all'interno del {{< glossary_tooltip term_id="kube-controller-manager" >}}. Questi _controller_ nativi forniscono importanti funzionalità di base. + +Il Deployment _controller_ ed il Job _controller_ sono esempi di _controller_ che vengono forniti direttamente da Kubernetes stesso (ovvero _controller_ "nativi"). +Kubernetes consente di eseguire un _piano di controllo_(_control plane_) resiliente, di modo che se un dei _controller_ nativi dovesse fallire, un'altra parte del piano di controllo si occuperà di eseguire quel lavoro. + +Al fine di estendere Kubernetes, si possono avere _controller_ in esecuzione al di fuori del piano di controllo. Oppure, se si desidera, è possibile scriversi un nuovo _controller_. È possibile eseguire il proprio controller come una serie di _Pod_, oppure esternamente rispetto a Kubernetes. Quale sia la soluzione migliore, dipende dalla responsabilità di un dato controller. + +## {{% heading "whatsnext" %}} +* Leggi in merito [Kubernetes control plane](/docs/concepts/#kubernetes-control-plane) +* Scopri alcune delle basi degli [oggetti di Kubernetes](/docs/concepts/#kubernetes-objects) +* Per saperne di più riguardo alle [API di Kubernetes](/docs/concepts/overview/kubernetes-api/) +* Se vuoi creare un tuo _controller_, guarda [i modelli per l'estensibilità](/docs/concepts/extend-kubernetes/extend-cluster/#extension-patterns) in Estendere Kubernetes. + diff --git a/content/it/docs/concepts/containers/_index.md b/content/it/docs/concepts/containers/_index.md index 2ae51e8f39..4c510e9ef2 100755 --- a/content/it/docs/concepts/containers/_index.md +++ b/content/it/docs/concepts/containers/_index.md @@ -1,4 +1,30 @@ --- -title: "Containers" +title: Containers weight: 40 +description: La tecnologia per distribuire un'applicazione insieme con le dipendenze necessarie per la sua esecuzione. +content_type: concept +no_list: true --- + +<!-- overview --> + +Ogni _container_ che viene eseguito è riproducibile; la pratica di includere le dipendenze all'interno di ciascuno _container_ permette di ottenere sempre lo stesso risultato ad ogni esecuzione del medesimo _container_. + +I _Container_ permettono di disaccoppiare le applicazioni dall'infrastruttura del host su cui vengono eseguite. Questo approccio rende più facile il _deployment_ su cloud o sitemi operativi differenti tra loro. + +<!-- body --> + +## Immagine di container +L'[immagine di un container](/docs/concepts/containers/images/) e' un pacchetto software che contiene tutto ciò che serve per eseguire un'applicazione: il codice sorgente e ciascun _runtime_ necessario, librerie applicative e di sistema, e le impostazioni predefinite per ogni configurazione necessaria. + +Un _container_ è immutabile per definizione: non è possibile modificare il codice di un _container_ in esecuzione. Se si ha un'applicazione containerizzata e la si vuole modificare, si deve costruire un nuovo _container_ che includa il cambiamento desiderato, e quindi ricreare il _container_ partendo dalla nuova immagine aggiornata. + +## Container runtimes + +{{< glossary_definition term_id="container-runtime" length="all" >}} + +## {{% heading "whatsnext" %}} + +* Leggi in merito [immagine di container](/docs/concepts/containers/images/) +* Leggi in merito [Pods](/docs/concepts/workloads/pods/) + diff --git a/content/it/docs/reference/glossary/controller.md b/content/it/docs/reference/glossary/controller.md new file mode 100755 index 0000000000..df5a7cfb94 --- /dev/null +++ b/content/it/docs/reference/glossary/controller.md @@ -0,0 +1,21 @@ +--- +title: Controller +id: controller +date: 2018-04-12 +full_link: /docs/concepts/architecture/controller/ +short_description: > + Un software che implementa un circuito di controllo che osserva lo stato condiviso del cluster attraverso l'API server e apporta le modifiche necessarie per portate lo stato corrente verso lo stato desiderato. + +aka: +tags: +- architecture +- fundamental +--- +In Kubernetes, i _controller_ sono circuiti di controllo che osservano lo stato del {{< glossary_tooltip term_id="cluster" text="cluster">}}, e apportano o richiedono modifiche quando necessario. Ogni _controller_ prova a portare lo stato corrente del cluster verso lo stato desiderato. + +<!--more--> + +I _controller_ osservano lo stato condiviso del cluster attraverso il {{< glossary_tooltip text="apiserver" term_id="kube-apiserver" >}} (che è parte del {{< glossary_tooltip term_id="control-plane" >}}). + +Alcuni _controller_ vengono eseguiti all'interno del _piano di controllo_ (_control plane_), e forniscono circuiti di controllo che sono parte dell'operatività base di Kubernetes. Ad esempio: il _deployment_ _controller_, il _daemonset_ _controller_, il _namespace_ _controller_, ed il _persistent volume_ +_controller_ (e altri) vengono tutti eseguiti all'interno del {{< glossary_tooltip term_id="kube-controller-manager" >}}. diff --git a/content/it/docs/reference/glossary/job.md b/content/it/docs/reference/glossary/job.md new file mode 100755 index 0000000000..6d3f8ef3af --- /dev/null +++ b/content/it/docs/reference/glossary/job.md @@ -0,0 +1,20 @@ +--- +title: Job +id: job +date: 2018-04-12 +full_link: /docs/concepts/workloads/controllers/jobs-run-to-completion +short_description: > + Uno o più lavori (task) che vengono eseguiti fino al loro completamento. + +aka: +tags: +- fundamental +- core-object +- workload +--- + Uno o più lavori (task) che vengono eseguiti fino al loro completamento. + +<!--more--> + +Crea uno o più oggetti di tipo {{< glossary_tooltip term_id="pod" >}} ed assicura che un numero preciso di questi venga completato con successo. Quando i _Pod_ vengono eseguiti con successo, il _Job_ tiene traccia della completamento andato a buon fine. + diff --git a/content/it/docs/reference/glossary/node.md b/content/it/docs/reference/glossary/node.md index 25bd25f3d0..3bc3df62bf 100755 --- a/content/it/docs/reference/glossary/node.md +++ b/content/it/docs/reference/glossary/node.md @@ -16,4 +16,4 @@ tags: Un worker node può essere una VM o una macchina fisica, in base al cluster. Possiede daemon locali o servizi ncessari a eseguire {{< glossary_tooltip text="Pods" term_id="pod" >}} e viene gestito dalla control plane. I deamon i un node includono {{< glossary_tooltip text="kubelet" term_id="kubelet" >}}, {{< glossary_tooltip text="kube-proxy" term_id="kube-proxy" >}}, e un container runtiome che implementa {{< glossary_tooltip text="CRI" term_id="cri" >}} come ad esempio {{< glossary_tooltip term_id="docker" >}}. -Nelle prime versioni di Kubernetes, i Node venivano chiamati "Minions". \ No newline at end of file +Nelle prime versioni di Kubernetes, i Node venivano chiamati "Minion". diff --git a/content/ja/_index.html b/content/ja/_index.html index 7d01d366b7..a42c9484f9 100644 --- a/content/ja/_index.html +++ b/content/ja/_index.html @@ -41,13 +41,12 @@ Kubernetesはオープンソースなので、オンプレミスやパブリッ <button id="desktopShowVideoButton" onclick="kub.showVideo()">ビデオを見る</button> <br> <br> - <br> - <a href="https://events.linuxfoundation.org/events/kubecon-cloudnativecon-europe-2020/" button id="desktopKCButton">2020年4月のKubeCon アムステルダムに参加する</a> + <a href="https://events.linuxfoundation.org/kubecon-cloudnativecon-europe/?utm_source=kubernetes.io&utm_medium=nav&utm_campaign=kccnceu20" button id="desktopKCButton">2020年8月17日-20日のKubeCon EUバーチャルに参加する</a> <br> <br> <br> <br> - <a href="https://events19.lfasiallc.com/events/kubecon-cloudnativecon-china-2019/" button id="desktopKCButton">2020年7月のKubeCon 上海に参加する</a> + <a href="https://events.linuxfoundation.org/kubecon-cloudnativecon-north-america/?utm_source=kubernetes.io&utm_medium=nav&utm_campaign=kccncna20" button id="desktopKCButton">2020年11月17日-20日のKubeCon NAバーチャルに参加する</a> </div> <div id="videoPlayer"> <iframe data-url="https://www.youtube.com/embed/H06qrNmGqyE?autoplay=1" frameborder="0" allowfullscreen></iframe> diff --git a/content/ja/docs/concepts/_index.md b/content/ja/docs/concepts/_index.md index 0f03287083..1e22892eca 100644 --- a/content/ja/docs/concepts/_index.md +++ b/content/ja/docs/concepts/_index.md @@ -19,14 +19,14 @@ Kubernetesを機能させるには、*Kubernetes API オブジェクト* を使 一旦desired state (望ましい状態)を設定すると、Pod Lifecycle Event Generator([PLEG](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/node/pod-lifecycle-event-generator.md))を使用した*Kubernetes コントロールプレーン*が機能し、クラスターの現在の状態をdesired state (望ましい状態)に一致させます。そのためにKubernetesはさまざまなタスク(たとえば、コンテナの起動または再起動、特定アプリケーションのレプリカ数のスケーリング等)を自動的に実行します。Kubernetesコントロールプレーンは、クラスターで実行されている以下のプロセスで構成されています。 -* **Kubernetes Master** :[kube-apiserver](/docs/admin/kube-apiserver/)、[kube-controller-manager](/docs/admin/kube-controller-manager/)、[kube-scheduler](/docs/admin/kube-scheduler/) の3プロセスの集合です。これらのプロセスはクラスター内の一つのノード上で実行されます。実行ノードはマスターノードとして指定します。 +* **Kubernetes Master**: [kube-apiserver](/docs/admin/kube-apiserver/)、[kube-controller-manager](/docs/admin/kube-controller-manager/)、[kube-scheduler](/docs/admin/kube-scheduler/) の3プロセスの集合です。これらのプロセスはクラスター内の一つのノード上で実行されます。実行ノードはマスターノードとして指定します。 * クラスター内の個々の非マスターノードは、それぞれ2つのプロセスを実行します。 - * **[kubelet](/docs/admin/kubelet/)**, Kubernetes Masterと通信します。 - * **[kube-proxy](/docs/admin/kube-proxy/)**, 各ノードのKubernetesネットワークサービスを反映するネットワークプロキシです。 + * **[kubelet](/docs/admin/kubelet/)**: Kubernetes Masterと通信します。 + * **[kube-proxy](/docs/admin/kube-proxy/)**: 各ノードのKubernetesネットワークサービスを反映するネットワークプロキシです。 -## Kubernetesオブジェクト +## Kubernetesオブジェクト {#kubernetes-objects} -Kubernetesには、デプロイ済みのコンテナ化されたアプリケーションやワークロード、関連するネットワークとディスクリソース、クラスターが何をしているかに関するその他の情報といった、システムの状態を表現する抽象が含まれています。これらの抽象は、Kubernetes APIのオブジェクトによって表現されます。詳細については、[Kubernetesオブジェクトについて知る](/ja/docs/concepts/overview/working-with-objects/kubernetes-objects/)をご覧ください。 +Kubernetesには、デプロイ済みのコンテナ化されたアプリケーションやワークロード、関連するネットワークとディスクリソース、クラスターが何をしているかに関するその他の情報といった、システムの状態を表現する抽象が含まれています。これらの抽象は、Kubernetes APIのオブジェクトによって表現されます。詳細については、[Kubernetesオブジェクトについて知る](/ja/docs/concepts/overview/working-with-objects/kubernetes-objects/#kubernetes-objects)をご覧ください。 基本的なKubernetesのオブジェクトは次のとおりです。 @@ -43,7 +43,7 @@ Kubernetesには、[コントローラー](/docs/concepts/architecture/controlle * [ReplicaSet](/ja/docs/concepts/workloads/controllers/replicaset/) * [Job](/docs/concepts/workloads/controllers/jobs-run-to-completion/) -## Kubernetesコントロールプレーン +## Kubernetesコントロールプレーン {#kubernetes-control-plane} Kubernetesマスターや kubeletプロセスといったKubernetesコントロールプレーンのさまざまなパーツは、Kubernetesがクラスターとどのように通信するかを統制します。コントロールプレーンはシステム内のすべてのKubernetesオブジェクトの記録を保持し、それらのオブジェクトの状態を管理するために継続的制御ループを実行します。コントロールプレーンの制御ループは常にクラスターの変更に反応し、システム内のすべてのオブジェクトの実際の状態が、指定した状態に一致するように動作します。 diff --git a/content/ja/docs/concepts/architecture/_index.md b/content/ja/docs/concepts/architecture/_index.md index d81eeab89c..b8906ee100 100644 --- a/content/ja/docs/concepts/architecture/_index.md +++ b/content/ja/docs/concepts/architecture/_index.md @@ -1,4 +1,4 @@ --- -title: "Kubernetesのアーキテクチャ" +title: "クラスターのアーキテクチャ" weight: 30 --- diff --git a/content/ja/docs/concepts/architecture/cloud-controller.md b/content/ja/docs/concepts/architecture/cloud-controller.md index d722ced7a6..8cf85db09b 100644 --- a/content/ja/docs/concepts/architecture/cloud-controller.md +++ b/content/ja/docs/concepts/architecture/cloud-controller.md @@ -1,14 +1,14 @@ --- title: クラウドコントローラーマネージャーとそのコンセプト content_type: concept -weight: 30 +weight: 40 --- <!-- overview --> -クラウドコントローラマネージャー(CCM)のコンセプト(バイナリと混同しないでください)は、もともとクラウドベンダー固有のソースコードと、Kubernetesのコアソースコードを独立して進化させることが出来るように作られました。クラウドコントローラーマネージャーは、Kubernetesコントローラーマネージャー、APIサーバー、そしてスケジューラーのような他のマスターコンポーネントと並行して動きます。またKubernetesのアドオンとしても動かすことができ、その場合はKubernetes上で動きます。 +クラウドコントローラマネージャー(CCM)のコンセプト(バイナリと混同しないでください)は、もともとクラウドベンダー固有のソースコードと、Kubernetesのコアソースコードを独立して進化させることができるように作られました。クラウドコントローラーマネージャーは、Kubernetesコントローラーマネージャー、APIサーバー、そしてスケジューラーのような他のマスターコンポーネントと並行して動きます。またKubernetesのアドオンとしても動かすことができ、その場合はKubernetes上で動きます。 -クラウドコントローラーマネージャーの設計は「プラグインメカニズム」をベースにしています。そうすることで、新しいクラウドプロバイダーがプラグインを使ってKubernetesと簡単に統合出来るようになります。新しいクラウドプロバイダーに向けてKubernetesのオンボーディングを行ったり、古いモデルを利用しているクラウドプロバイダーに、新しいCCMモデルに移行させるような計画があります。 +クラウドコントローラーマネージャーの設計は「プラグインメカニズム」をベースにしています。そうすることで、新しいクラウドプロバイダーがプラグインを使ってKubernetesと簡単に統合できるようになります。新しいクラウドプロバイダーに向けてKubernetesのオンボーディングを行ったり、古いモデルを利用しているクラウドプロバイダーに、新しいCCMモデルに移行させるような計画があります。 このドキュメントでは、クラウドコントローラーマネージャーの背景にあるコンセプトと、それに関連する機能の詳細について話します。 @@ -52,7 +52,7 @@ CCMは、Kubernetesコントローラーマネージャー(KCM)からいくつ ボリュームコントローラーは、意図的にCCMの一部になっていません。複雑さと、ベンダー固有のボリュームロジックを抽象化するのに費やした労力を考え、CCMの一部に移行しないことが決定されました。 {{< /note >}} -CCMを使ったボリュームをサポートする元の計画は、プラガブルなボリュームをサポートするため、Flexボリュームを使うことでした。しかし、競合しているCSIとして知られている機能が、Flexを置き換える予定です。 +CCMを使ったボリュームをサポートする元の計画は、プラガブルなボリュームをサポートするため、[Flex](/docs/concepts/storage/volumes/#flexVolume)ボリュームを使うことでした。しかし、競合している[CSI](/docs/concepts/storage/volumes/#csi)として知られている機能が、Flexを置き換える予定です。 これらのダイナミクスを考慮し、我々はCSIが利用できるようになるまで、間を取った暫定措置を取ることにしました。 @@ -79,11 +79,11 @@ CCMの大半の機能は、KCMから派生しています。前セクション #### ルートコントローラー -ルートコントローラーは、クラスタ内の異なるノード上で稼働しているコンテナが相互に通信出来るように、クラウド内のルートを適切に設定する責務を持ちます。ルートコントローラーはGoogle Compute Engineのクラスターのみに該当します。 +ルートコントローラーは、クラスタ内の異なるノード上で稼働しているコンテナが相互に通信できるように、クラウド内のルートを適切に設定する責務を持ちます。ルートコントローラーはGoogle Compute Engineのクラスターのみに該当します。 #### サービスコントローラー -サービスコントローラーは、サービスの作成、更新、そして削除イベントの待ち受けに責務を持ちます。Kubernetes内のサービスの現在の状態を、クラウド上のロードバランサー(ELB、Google LB、またOracle Cloud Infrastructure LBなど)に反映するための設定を行います。更に、クラウドロードバランサーのバックエンドが最新の状態になっていることを保証します。 +サービスコントローラーは、サービスの作成、更新、そして削除イベントの待ち受けに責務を持ちます。Kubernetes内のサービスの現在の状態を、クラウド上のロードバランサー(ELB、Google LB、またOracle Cloud Infrastructure LBなど)に反映するための設定を行います。さらに、クラウドロードバランサーのバックエンドが最新の状態になっていることを保証します。 ### 2. Kubelet @@ -93,7 +93,7 @@ CCMの大半の機能は、KCMから派生しています。前セクション ## プラグインメカニズム -クラウドコントローラーマネージャーは、Goのインターフェースを利用してクラウドの実装をプラグイン化出来るようにしています。具体的には、[こちら](https://github.com/kubernetes/cloud-provider/blob/9b77dc1c384685cb732b3025ed5689dd597a5971/cloud.go#L42-L62)で定義されているクラウドプロバイダーインターフェースを利用しています。 +クラウドコントローラーマネージャーは、Goのインターフェースを利用してクラウドの実装をプラグイン化できるようにしています。具体的には、[こちら](https://github.com/kubernetes/cloud-provider/blob/9b77dc1c384685cb732b3025ed5689dd597a5971/cloud.go#L42-L62)で定義されているクラウドプロバイダーインターフェースを利用しています。 上で強調した4つの共有コントローラーの実装、そしていくつかの共有クラウドプロバイダーインターフェースと一部の連携機能は、Kubernetesのコアにとどまります。クラウドプロバイダー特有の実装はコア機能外で構築され、コア機能内で定義されたインターフェースを実装します。 @@ -223,13 +223,18 @@ rules: 下記のクラウドプロバイダーがCCMを実装しています: -* [Digital Ocean](https://github.com/digitalocean/digitalocean-cloud-controller-manager) -* [Oracle](https://github.com/oracle/oci-cloud-controller-manager) -* [Azure](https://github.com/kubernetes/cloud-provider-azure) -* [GCP](https://github.com/kubernetes/cloud-provider-gcp) +* [Alibaba Cloud](https://github.com/kubernetes/cloud-provider-alibaba-cloud) * [AWS](https://github.com/kubernetes/cloud-provider-aws) +* [Azure](https://github.com/kubernetes/cloud-provider-azure) * [BaiduCloud](https://github.com/baidu/cloud-provider-baiducloud) +* [DigitalOcean](https://github.com/digitalocean/digitalocean-cloud-controller-manager) +* [GCP](https://github.com/kubernetes/cloud-provider-gcp) +* [Hetzner](https://github.com/hetznercloud/hcloud-cloud-controller-manager) * [Linode](https://github.com/linode/linode-cloud-controller-manager) +* [OpenStack](https://github.com/kubernetes/cloud-provider-openstack) +* [Oracle](https://github.com/oracle/oci-cloud-controller-manager) +* [TencentCloud](https://github.com/TencentCloud/tencentcloud-cloud-controller-manager) + ## クラスター管理 diff --git a/content/ja/docs/concepts/architecture/controller.md b/content/ja/docs/concepts/architecture/controller.md new file mode 100644 index 0000000000..0a13635fe8 --- /dev/null +++ b/content/ja/docs/concepts/architecture/controller.md @@ -0,0 +1,90 @@ +--- +title: コントローラー +content_type: concept +weight: 30 +--- + +<!-- overview --> + +ロボット工学やオートメーションの分野において、 _制御ループ_ とは、あるシステムの状態を制御する終了状態のないループのことです。 + +ここでは、制御ループの一例として、部屋の中にあるサーモスタットを挙げます。 + +あなたが温度を設定すると、それはサーモスタットに *目的の状態(desired state)* を伝えることになります。実際の部屋の温度は *現在の状態* です。サーモスタットは、装置をオンまたはオフにすることによって、現在の状態を目的の状態に近づけるように動作します。 + +{{< glossary_definition term_id="controller" length="short">}} + +<!-- body --> + +## コントローラーパターン + +コントローラーは少なくとも1種類のKubernetesのリソースを監視します。これらの[オブジェクト](/ja/docs/concepts/overview/working-with-objects/kubernetes-objects/#kubernetes-objects)には目的の状態を表すspecフィールドがあります。リソースのコントローラーは、現在の状態を目的の状態に近づける責務を持ちます。 + +コントローラーは自分自身でアクションを実行する場合もありますが、Kubernetesではコントローラーが{{< glossary_tooltip text="APIサーバー" term_id="kube-apiserver" >}}に意味のある副作用を持つメッセージを送信することが一般的です。以下では、このような例を見ていきます。 + +{{< comment >}} +ネームスペースコントローラーなどの一部のビルトインのコントローラーは、specのないオブジェクトに対して作用します。簡単のため、このページではそのような詳細な説明は省略します。 +{{< /comment >}} + +### APIサーバー経由でコントロールする + +{{< glossary_tooltip term_id="job" >}}コントローラーはKubernetesのビルトインのコントローラーの一例です。ビルトインのコントローラーは、クラスターのAPIサーバーとやりとりをして状態を管理します。 + +Jobは、1つ以上の{{< glossary_tooltip term_id="pod" >}}を起動して、タスクを実行した後に停止する、Kubernetesのリソースです。 + +(1度[スケジュール](/ja/docs/concepts/scheduling-eviction/)されると、Podオブジェクトはkubeletに対する目的の状態の一部になります。) + +Jobコントローラーが新しいタスクを見つけると、その処理が完了するように、クラスター上のどこかで、一連のNode上のkubeletが正しい数のPodを実行することを保証します。ただし、Jobコントローラーは、自分自身でPodやコンテナを実行することはありません。代わりに、APIサーバーに対してPodの作成や削除を依頼します。{{< glossary_tooltip text="コントロールプレーン" term_id="control-plane" >}}上の他のコンポーネントが(スケジュールして実行するべき新しいPodが存在するという)新しい情報を基に動作することによって、最終的に目的の処理が完了します。 + +新しいJobが作成されたとき、目的の状態は、そのJobが完了することです。JobコントローラーはそのJobに対する現在の状態を目的の状態に近づけるようにします。つまり、そのJobが行ってほしい処理を実行するPodを作成し、Jobが完了に近づくようにします。 + +コントローラーは、コントローラーを設定するオブジェクトも更新します。たとえば、あるJobが完了した場合、Jobコントローラーは、Jobオブジェクトに`Finished`というマークを付けます。 + +(これは、部屋が設定温度になったことを示すために、サーモスタットがランプを消灯するのに少し似ています。) + +### 直接的なコントロール + +Jobとは対照的に、クラスターの外部に変更を加える必要があるコントローラーもあります。 + +たとえば、クラスターに十分な数の{{< glossary_tooltip text="Node" term_id="node" >}}が存在することを保証する制御ループの場合、そのコントローラーは、必要に応じて新しいNodeをセットアップするために、現在のクラスターの外部とやりとりをする必要があります。 + +外部の状態とやりとりをするコントローラーは、目的の状態をAPIサーバーから取得した後、外部のシステムと直接通信し、現在の状態を目的の状態に近づけます。 + +(クラスター内のノードを水平にスケールさせるコントローラーが実際に存在します。詳しくは、[クラスターのオートスケーリング](/docs/tasks/administer-cluster/cluster-management/#cluster-autoscaling)を読んでください。) + +## 目的の状態 vs 現在の状態 {#desired-vs-current} + +Kubernetesはシステムに対してクラウドネイティブな見方をするため、常に変化し続けるような状態を扱えるように設計されています。 + +処理を実行したり、制御ループが故障を自動的に修正したりしているどの時点でも、クラスターは変化中である可能性があります。つまり、クラスターは決して安定した状態にならない可能性があるということです。 + +コントローラーがクラスターのために実行されていて、有用な変更が行われるのであれば、全体的な状態が安定しているかどうかは問題にはなりません。 + +## 設計 + +設計理念として、Kubernetesは多数のコントローラーを使用しており、各コントローラーはクラスターの状態の特定の側面をそれぞれ管理しています。最もよくあるパターンは、特定の制御ループ(コントローラー)が目的の状態として1種類のリソースを使用し、目的の状態を実現することを管理するために別の種類のリソースを用意するというものです。 + +相互にリンクされた単一のモノリシックな制御ループよりは、複数の単純なコントローラーが存在する方が役に立ちます。コントローラーは故障することがあるため、Kubernetesは故障を許容するように設計されています。 + +たとえば、Jobのコントローラーは、Jobオブジェクト(新しい処理を見つけるため)およびPodオブジェクト(Jobを実行し、処理が完了したか確認するため)を監視します。この場合、なにか別のものがJobを作成し、JobコントローラーはPodを作成します。 + +{{< note >}} +同じ種類のオブジェクトを作成または更新するコントローラーが、複数存在する場合があります。実際には、Kubernetesコントローラーは、自分が制御するリソースに関連するリソースにのみ注意を払うように作られています。 + +たとえば、DeploymentとJobがありますが、これらは両方ともPodを作成するものです。しかし、JobコントローラーはDeploymentが作成したPodを削除することはありません。各コントローラーが2つのPodを区別できる情報({{< glossary_tooltip term_id="label" text="ラベル" >}})が存在するためです。 +{{< /note >}} + +## コントローラーを実行する方法 {#running-controllers} + +Kubernetesには、{{< glossary_tooltip term_id="kube-controller-manager" >}}内部で動作する一組のビルトインのコントローラーが用意されています。これらビルトインのコントローラーは、コアとなる重要な振る舞いを提供します。 + +DeploymentコントローラーとJobコントローラーは、Kubernetes自体の一部として同梱されているコントローラーの例です(それゆえ「ビルトイン」のコントローラーと呼ばれます)。Kubernetesは回復性のあるコントロールプレーンを実行できるようにしているため、ビルトインのコントローラーの一部が故障しても、コントロールプレーンの別の部分が作業を引き継いでくれます。 + +Kubernetesを拡張するためにコントロールプレーンの外で動作するコントローラーもあります。もし望むなら、新しいコントローラーを自分で書くこともできます。自作のコントローラーをPodセットとして動作させたり、Kubernetesの外部で動作させることもできます。どのような動作方法が最も適しているかは、そのコントローラーがどのようなことを行うのかに依存します。 + +## {{% heading "whatsnext" %}} + +* [Kubernetesコントロールプレーン](/ja/docs/concepts/#kubernetes-control-plane)について読む +* 基本的な[Kubernetesオブジェクト](/ja/docs/concepts/#kubernetes-objects)について学ぶ +* [Kubernetes API](/ja/docs/concepts/overview/kubernetes-api/)について学ぶ +* 自分でコントローラーを書きたい場合は、「Kubernetesを拡張する」の[エクステンションパターン](/ja/docs/concepts/extend-kubernetes/extend-cluster/#extension-patterns)を読んでください。 diff --git a/content/ja/docs/concepts/architecture/master-node-communication.md b/content/ja/docs/concepts/architecture/master-node-communication.md index 14f0678a20..e15d1187ad 100644 --- a/content/ja/docs/concepts/architecture/master-node-communication.md +++ b/content/ja/docs/concepts/architecture/master-node-communication.md @@ -6,8 +6,8 @@ weight: 20 <!-- overview --> -本ドキュメントでは、KubernetesにおけるMaster(実態はAPIサーバー)及びクラスター間のコミュニケーション経路についてまとめます。 -この文書の目的は、信頼できないネットワーク上（またはクラウドプロバイダ上の完全にパブリックなIP上）でクラスタを実行できるように、ユーザーがインストールをカスタマイズしてネットワーク構成を強化できるようにすることです。 +本ドキュメントでは、KubernetesにおけるMaster(実態はAPIサーバー)およびクラスター間のコミュニケーション経路についてまとめます。 +この文書の目的は、信頼できないネットワーク上(またはクラウドプロバイダ上の完全にパブリックなIP上)でクラスタを実行できるように、ユーザーがインストールをカスタマイズしてネットワーク構成を強化できるようにすることです。 @@ -16,8 +16,8 @@ weight: 20 ## クラスターからマスターへの通信 -クラスターからマスターへのすべての通信経路は、APIサーバーで終端します（他のマスターコンポーネントはどれもリモートサービスを公開するように設計されていません）。 -一般的には、1つ以上の形式のクライアント[認証](/docs/reference/access-authn-authz/authentication/)が有効になっている状態で、APIサーバーはセキュアなHTTPSポート（443）でリモート接続をlistenするように構成されています。 +クラスターからマスターへのすべての通信経路は、APIサーバーで終端します(他のマスターコンポーネントはどれもリモートサービスを公開するように設計されていません)。 +一般的には、1つ以上の形式のクライアント[認証](/docs/reference/access-authn-authz/authentication/)が有効になっている状態で、APIサーバーはセキュアなHTTPSポート(443)でリモート接続をlistenするように構成されています。 特に[匿名のリクエスト](/docs/reference/access-authn-authz/authentication/#anonymous-requests)または[サービスアカウントトークン](/docs/reference/access-authn-authz/authentication/#service-account-tokens)が許可されている場合は、1つまたは複数の[認証](/docs/reference/access-authn-authz/authorization/)を有効にする必要があります。 ノードには、有効なクライアント認証情報を使って安全にAPIサーバーに接続できるように、クラスターのパブリックなルート証明書をプロビジョニングする必要があります。 @@ -26,15 +26,15 @@ kubeletのクライアント証明書を自動プロビジョニングする方 APIサーバーに接続したいPodは、サービスアカウントを利用することで接続を安全にすることができます。そうすることで、Podが作成されたときにKubernetesがパブリックなルート証明書と有効なBearer TokenをPodに自動的に挿入します。 -`kubernetes`サービスには（すべてのネームスペースで）、APIサーバー上のHTTPSエンドポイントに（kube-proxy経由で）リダイレクトされる仮想IPアドレスが設定されています。 +`kubernetes`サービスには(すべてのネームスペースで)、APIサーバー上のHTTPSエンドポイントに(kube-proxy経由で)リダイレクトされる仮想IPアドレスが設定されています。 マスターコンポーネントは、セキュアなポートを介してクラスターAPIサーバーとも通信します。 -その結果、クラスター（ノードとそのノードで実行されているPod）からマスターへの接続はデフォルトで保護され、信頼できないネットワークやパブリックネットワークを介して実行できます。 +その結果、クラスター(ノードとそのノードで実行されているPod)からマスターへの接続はデフォルトで保護され、信頼できないネットワークやパブリックネットワークを介して実行できます。 ## マスターからクラスターへの通信 -マスター（APIサーバー）からクラスターへの通信には、2つの主要な通信経路があります。 +マスター(APIサーバー)からクラスターへの通信には、2つの主要な通信経路があります。 1つ目は、APIサーバーからクラスター内の各ノードで実行されるkubeletプロセスへの通信です。 2つ目は、APIサーバーのプロキシ機能を介した、APIサーバーから任意のノード、Pod、またはサービスへのアクセスです。 @@ -43,7 +43,7 @@ APIサーバーに接続したいPodは、サービスアカウントを利用 APIサーバーからkubeletへの接続は以下の目的で使用されます: * Podのログを取得する - * 実行中のPodに（kubectlを通して）接続する + * 実行中のPodに(kubectlを通して)接続する * kubeletのポート転送機能を提供する これらの接続は、kubeletのHTTPSエンドポイントで終了します。 @@ -64,7 +64,7 @@ API URL内のノード、Pod、またはサービス名に`https:`を付ける ### SSHトンネル Kubernetesはマスターからクラスターへの通信経路を保護するためにSSHトンネルをサポートしています。 -この設定では、APIサーバーはクラスター内の各ノード（ポート22でlistenしているsshサーバーに接続）へのSSHトンネルを開始し、トンネルを介してkubelet、ノード、Pod、またはサービス宛てのすべてのトラフィックを渡します。 +この設定では、APIサーバーはクラスター内の各ノード(ポート22でlistenしているsshサーバーに接続)へのSSHトンネルを開始し、トンネルを介してkubelet、ノード、Pod、またはサービス宛てのすべてのトラフィックを渡します。 このトンネルにより、ノードが実行されているネットワークの外部にトラフィックが公開されないようにします。 SSHトンネルは現在非推奨なので、自分がしていることが分からない限り、使用しないでください。この通信チャネルに代わるものが設計されています。 diff --git a/content/ja/docs/concepts/architecture/nodes.md b/content/ja/docs/concepts/architecture/nodes.md index d5631319a7..1c3d47c019 100644 --- a/content/ja/docs/concepts/architecture/nodes.md +++ b/content/ja/docs/concepts/architecture/nodes.md @@ -43,7 +43,6 @@ kubectl describe node <ノード名> | ノードのCondition | 概要 | |----------------|-------------| -| `OutOfDisk` | 新しいPodを追加するために必要なディスク容量が足りない場合に`True`になります。それ以外のときは`False`です。 | | `Ready` | ノードの状態がHealthyでPodを配置可能な場合に`True`になります。ノードの状態に問題があり、Podが配置できない場合に`False`になります。ノードコントローラーが、`node-monitor-grace-period`で設定された時間内(デフォルトでは40秒)に該当ノードと疎通できない場合、`Unknown`になります。 | | `MemoryPressure` | ノードのメモリが圧迫されているときに`True`になります。圧迫とは、メモリの空き容量が少ないことを指します。それ以外のときは`False`です。 | | `PIDPressure` | プロセスが圧迫されているときに`True`になります。圧迫とは、プロセス数が多すぎることを指します。それ以外のときは`False`です。 | @@ -69,18 +68,9 @@ Ready conditionが`pod-eviction-timeout`に設定された時間を超えても` バージョン1.5よりも前のKubernetesでは、ノードコントローラーはAPIサーバーから到達不能なそれらのPodを[強制削除](/ja/docs/concepts/workloads/pods/pod/#podの強制削除)していました。しかしながら、1.5以降では、ノードコントローラーはクラスター内でPodが停止するのを確認するまでは強制的に削除しないようになりました。到達不能なノード上で動いているPodは`Terminating`または`Unknown`のステータスになります。Kubernetesが基盤となるインフラストラクチャーを推定できない場合、クラスター管理者は手動でNodeオブジェクトを削除する必要があります。KubernetesからNodeオブジェクトを削除すると、そのノードで実行されているすべてのPodオブジェクトがAPIサーバーから削除され、それらの名前が解放されます。 -バージョン1.12において、`TaintNodesByCondition`機能がBetaに昇格し、それによってノードのライフサイクルコントローラーがconditionを表した[taint](/docs/concepts/configuration/taint-and-toleration/)を自動的に生成するようになりました。 -同様に、スケジューラーがPodを配置するノードを検討する際、ノードのtaintとPodのtolerationsを見るかわりにconditionを無視するようになりました。 +ノードのライフサイクルコントローラーがconditionを表した[taint](/docs/concepts/configuration/taint-and-toleration/)を自動的に生成します。 -ユーザーは、古いスケジューリングモデルか、新しくてより柔軟なスケジューリングモデルのどちらかを選択できるようになりました。 -上記のtolerationがないPodは古いスケジュールモデルに従ってスケジュールされます。しかし、特定のノードのtaintを許容するPodについては、条件に合ったノードにスケジュールすることができます。 - -{{< caution >}} - -この機能を有効にすると、conditionが観測されてからtaintが作成されるまでの間にわずかな遅延が発生します。 -この遅延は通常1秒未満ですが、正常にスケジュールされているが、kubeletによって配置を拒否されたPodの数が増える可能性があります。 - -{{< /caution >}} +スケジューラーがPodをノードに割り当てる際、ノードのtaintを考慮します。Podが許容するtaintは例外です。 ### CapacityとAllocatable {#capacity} @@ -91,7 +81,7 @@ allocatableブロックは、通常のPodによって消費されるノード上 CapacityとAllocatableについて深く知りたい場合は、ノード上でどのように[コンピュートリソースが予約されるか](/docs/tasks/administer-cluster/reserve-compute-resources/#node-allocatable)を読みながら学ぶことができます。 -### Info +### Info {#info} カーネルのバージョン、Kubernetesのバージョン（kubeletおよびkube-proxyのバージョン）、（使用されている場合）Dockerのバージョン、OS名など、ノードに関する一般的な情報です。 この情報はノードからkubeletを通じて取得されます。 @@ -114,6 +104,7 @@ CapacityとAllocatableについて深く知りたい場合は、ノード上で ``` Kubernetesは内部的にNodeオブジェクトを作成し、 `metadata.name`フィールドに基づくヘルスチェックによってノードを検証します。ノードが有効な場合、つまり必要なサービスがすべて実行されている場合は、Podを実行する資格があります。それ以外の場合、該当ノードが有効になるまではいかなるクラスターの活動に対しても無視されます。 +Nodeオブジェクトの名前は有効な[DNSサブドメイン名](/ja/docs/concepts/overview/working-with-objects/names#dns-subdomain-names)である必要があります。 {{< note >}} Kubernetesは無効なノードのためにオブジェクトを保存し、それをチェックし続けます。 @@ -136,9 +127,19 @@ Kubernetesは無効なノードのためにオブジェクトを保存し、そ ノードが到達不能(例えば、ノードがダウンしているなどので理由で、ノードコントローラーがハートビートの受信を停止した場合)になると、ノードコントローラーは、NodeStatusのNodeReady conditionをConditionUnknownに変更する役割があります。その後も該当ノードが到達不能のままであった場合、Graceful Terminationを使って全てのPodを退役させます。デフォルトのタイムアウトは、ConditionUnknownの報告を開始するまで40秒、その後Podの追い出しを開始するまで5分に設定されています。 ノードコントローラーは、`--node-monitor-period`に設定された秒数ごとに各ノードの状態をチェックします。 -バージョン1.13よりも前のKubernetesにおいて、NodeStatusはノードからのハートビートでした。Kubernetes 1.13から、NodeLeaseがアルファ機能として導入されました（Feature Gate `NodeLease`, [KEP-0009](https://github.com/kubernetes/community/blob/master/keps/sig-node/0009-node-heartbeat.md)）。 +#### ハートビート +ハートビートは、Kubernetesノードから送信され、ノードが利用可能か判断するのに役立ちます。 +２つのハートビートがあります：`NodeStatus`の更新と[Lease object](/docs/reference/generated/kubernetes-api/{{< latest-version >}}#lease-v1-coordination-k8s-io)です。 +各ノードは`kube-node-lease`という{{< glossary_tooltip term_id="namespace" text="namespace">}}に関連したLeaseオブジェクトを持ちます。 +Leaseは軽量なリソースで、クラスターのスケールに応じてノードのハートビートにおけるパフォーマンスを改善します。 + +kubeletが`NodeStatus`とLeaseオブジェクトの作成および更新を担当します。 + +- kubeletは、ステータスに変化があったり、設定した間隔の間に更新がない時に`NodeStatus`を更新します。`NodeStatus`更新のデフォルト間隔は５分です。（到達不能の場合のデフォルトタイムアウトである40秒よりもはるかに長いです） +- kubeletは10秒間隔(デフォルトの更新間隔)でLeaseオブジェクトの生成と更新を実施します。Leaseの更新は`NodeStatus`の更新とは独立されて行われます。Leaseの更新が失敗した場合、kubeletは200ミリ秒から始まり7秒を上限とした指数バックオフでリトライします。 + +#### 信頼性 -NodeLeaseが有効になっている場合、各ノードは `kube-node-lease`というNamespaceに関連付けられた`Lease`オブジェクトを持ち、ノードによって定期的に更新されます。NodeStatusとNodeLeaseの両方がノードからのハートビートとして扱われます。NodeLeaseは頻繁に更新されますが、NodeStatusはノードからマスターへの変更があるか、または十分な時間が経過した場合にのみ報告されます（デフォルトは1分で、到達不能の場合のデフォルトタイムアウトである40秒よりも長いです）。NodeLeaseはNodeStatusよりもはるかに軽量であるため、スケーラビリティとパフォーマンスの両方の観点においてノードのハートビートのコストを下げます。 Kubernetes 1.4では、マスターに問題が発生した場合の対処方法を改善するように、ノードコントローラーのロジックをアップデートしています（マスターのネットワークに問題があるため） バージョン1.4以降、ノードコントローラーは、Podの退役について決定する際に、クラスター内のすべてのノードの状態を調べます。 @@ -201,6 +202,11 @@ DaemonSetコントローラーによって作成されたPodはKubernetesスケ これは、再起動の準備中にアプリケーションからアプリケーションが削除されている場合でも、デーモンがマシンに属していることを前提としているためです。 {{< /note >}} +{{< caution >}} +`kubectl cordon`はノードに'unschedulable'としてマークします。それはロードバランサーのターゲットリストからノードを削除するという +サービスコントローラーの副次的な効果をもたらします。これにより、ロードバランサトラフィックの流入をcordonされたノードから効率的に除去する事ができます。 +{{< /caution >}} + ### ノードのキャパシティ ノードのキャパシティ（CPUの数とメモリの量）はNodeオブジェクトの一部です。 @@ -213,6 +219,11 @@ Kubernetesスケジューラーは、ノード上のすべてのPodに十分な Pod以外のプロセス用にリソースを明示的に予約したい場合は、このチュートリアルに従って[Systemデーモン用にリソースを予約](/docs/tasks/administer-cluster/reserve-compute-resources/#system-reserved)してください。 +## ノードのトポロジー + +{{< feature-state state="alpha" >}} +`TopologyManager`の[フィーチャーゲート](/ja/docs/reference/command-line-tools-reference/feature-gates/)を有効にすると、 +kubeletはリソースの割当を決定する際にトポロジーのヒントを利用できます。 ## APIオブジェクト @@ -220,3 +231,7 @@ NodeはKubernetesのREST APIにおけるトップレベルのリソースです [Node APIオブジェクト](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#node-v1-core). +## {{% heading "whatsnext" %}} + +* [ノードコンポーネント](/ja/docs/concepts/overview/components/#node-components)について読む。 +* ノードレベルのトポロジーについて読む: [ノードのトポロジー管理ポリシーを制御する](/docs/tasks/administer-cluster/topology-manager/) diff --git a/content/ja/docs/concepts/cluster-administration/cluster-administration-overview.md b/content/ja/docs/concepts/cluster-administration/cluster-administration-overview.md index 49e00df3a0..5d85797649 100644 --- a/content/ja/docs/concepts/cluster-administration/cluster-administration-overview.md +++ b/content/ja/docs/concepts/cluster-administration/cluster-administration-overview.md @@ -16,13 +16,13 @@ Kubernetesクラスターの計画、セットアップ、設定の例を知る ガイドを選択する前に、いくつかの考慮事項を挙げます。 - - ユーザーのコンピューター上でKubernetesを試したいでしょうか、それとも高可用性のあるマルチノードクラスターを構築したいでしょうか? あなたのニーズにあったディストリビューションを選択してください。 + - ユーザーのコンピューター上でKubernetesを試したいでしょうか、それとも高可用性のあるマルチノードクラスターを構築したいでしょうか？あなたのニーズにあったディストリビューションを選択してください。 - **もしあなたが高可用性を求める場合**、 [複数ゾーンにまたがるクラスター](/docs/concepts/cluster-administration/federation/)の設定について学んでください。 - - [Google Kubernetes Engine](https://cloud.google.com/kubernetes-engine/)のような**ホストされているKubernetesクラスター**を使用するのか、それとも**自分自身でクラスターをホストするのでしょうか**? - - 使用するクラスターは**オンプレミス**なのか、それとも**クラウド (IaaS)**でしょうか? Kubernetesはハイブリッドクラスターを直接サポートしていません。その代わりユーザーは複数のクラスターをセットアップできます。 - - Kubernetesを**"ベアメタル"なハードウェア** 上で稼働させますか? それとも**仮想マシン (VMs)** 上で稼働させますか? + - [Google Kubernetes Engine](https://cloud.google.com/kubernetes-engine/)のような**ホストされているKubernetesクラスター**を使用するのか、それとも**自分自身でクラスターをホストするのでしょうか**？ + - 使用するクラスターは**オンプレミス**なのか、それとも**クラウド(IaaS)** でしょうか？Kubernetesはハイブリッドクラスターを直接サポートしていません。その代わりユーザーは複数のクラスターをセットアップできます。 + - Kubernetesを **「ベアメタル」なハードウェア**上で稼働させますか？それとも**仮想マシン(VMs)** 上で稼働させますか？ - **もしオンプレミスでKubernetesを構築する場合**、どの[ネットワークモデル](/ja/docs/concepts/cluster-administration/networking/)が最適か検討してください。 - - **ただクラスターを稼働させたいだけ**でしょうか、それとも**Kubernetesプロジェクトのコードの開発**を行いたいでしょうか? もし後者の場合、開発が進行中のディストリビューションを選択してください。いくつかのディストリビューションはバイナリリリースのみ使用していますが、多くの選択肢があります。 + - **ただクラスターを稼働させたいだけ**でしょうか、それとも**Kubernetesプロジェクトのコードの開発**を行いたいでしょうか？もし後者の場合、開発が進行中のディストリビューションを選択してください。いくつかのディストリビューションはバイナリリリースのみ使用していますが、多くの選択肢があります。 - クラスターを稼働させるのに必要な[コンポーネント](/ja/docs/concepts/overview/components/)についてよく理解してください。 注意: 全てのディストリビューションがアクティブにメンテナンスされている訳ではありません。最新バージョンのKubernetesでテストされたディストリビューションを選択してください。 diff --git a/content/ja/docs/concepts/cluster-administration/controller-metrics.md b/content/ja/docs/concepts/cluster-administration/controller-metrics.md deleted file mode 100644 index d77f5bdf44..0000000000 --- a/content/ja/docs/concepts/cluster-administration/controller-metrics.md +++ /dev/null @@ -1,42 +0,0 @@ ---- -title: コントローラーマネージャーの指標 -content_type: concept -weight: 100 ---- - -<!-- overview --> -コントローラーマネージャーの指標は、コントローラー内部のパフォーマンスについての重要で正確な情報と、クラウドコントローラーの状態についての情報を提供します。 - - - -<!-- body --> -## コントローラーマネージャーの指標とは何か - -コントローラーマネージャーの指標は、コントローラー内部のパフォーマンスについての重要で正確な情報と、クラウドコントローラーの状態についての情報を提供します。 -これらの指標にはgo_routineのカウントなどの一般的なGo言語ランタイムの指標と、etcdのリクエストレイテンシまたはCloudprovider（AWS、GCE、OpenStack）APIのレイテンシといったコントローラー固有の指標が含まれていて、クラスターの状態を測定するために利用できます。 - -Kubernetes 1.7からGCE、AWS、Vsphere、OpenStackのストレージ操作の詳細なCloudproviderの指標が利用可能になりました。 -これらの指標は永続的ボリュームの操作状況を監視するために利用できます。 - -たとえば、GCEの場合にはこれらの指標は次のように呼び出されます。 - -``` -cloudprovider_gce_api_request_duration_seconds { request = "instance_list"} -cloudprovider_gce_api_request_duration_seconds { request = "disk_insert"} -cloudprovider_gce_api_request_duration_seconds { request = "disk_delete"} -cloudprovider_gce_api_request_duration_seconds { request = "attach_disk"} -cloudprovider_gce_api_request_duration_seconds { request = "detach_disk"} -cloudprovider_gce_api_request_duration_seconds { request = "list_disk"} -``` - - - -## 設定 - -クラスターではコントローラーマネージャーの指標はコントローラーマネージャーが実行されているホストの`http://localhost:10252/metrics`から取得可能です。 - -この指標は[prometheusフォーマット](https://prometheus.io/docs/instrumenting/exposition_formats/)で出力され人間が読める形式になっています。 - -本番環境ではこれらの指標を定期的に収集し、なんらかの時系列データベースで使用できるようにprometheusやその他の指標のスクレイパーを構成することが推奨されます。 - - diff --git a/content/ja/docs/concepts/cluster-administration/networking.md b/content/ja/docs/concepts/cluster-administration/networking.md index 2ec89adc4d..53b899dc32 100644 --- a/content/ja/docs/concepts/cluster-administration/networking.md +++ b/content/ja/docs/concepts/cluster-administration/networking.md @@ -81,7 +81,7 @@ Details on how the AOS system works can be accessed here: http://www.apstra.com/ [AWS VPC CNI](https://github.com/aws/amazon-vpc-cni-k8s)は、Kubernetesクラスター向けの統合されたAWS Virtual Private Cloud(VPC)ネットワーキングを提供します。このCNIプラグインは、高いスループットと可用性、低遅延、および最小のネットワークジッタを提供します。さらに、ユーザーは、Kubernetesクラスターを構築するための既存のAWS VPCネットワーキングとセキュリティのベストプラクティスを適用できます。これには、ネットワークトラフィックの分離にVPCフローログ、VPCルーティングポリシー、およびセキュリティグループを使用する機能が含まれます。 -このCNIプラグインを使用すると、Kubernetes PodはVPCネットワーク上と同じIPアドレスをPod内に持つことができます。CNIはAWS Elastic Networking Interfaces（ENI）を各Kubernetesノードに割り当て、ノード上のPodに各ENIのセカンダリIP範囲を使用します。このCNIには、Podの起動時間を短縮するためのENIとIPアドレスの事前割り当ての制御が含まれており、最大2,000ノードの大規模クラスターが可能です。 +このCNIプラグインを使用すると、Kubernetes PodはVPCネットワーク上と同じIPアドレスをPod内に持つことができます。CNIはAWS Elastic Networking Interface(ENI)を各Kubernetesノードに割り当て、ノード上のPodに各ENIのセカンダリIP範囲を使用します。このCNIには、Podの起動時間を短縮するためのENIとIPアドレスの事前割り当ての制御が含まれており、最大2,000ノードの大規模クラスターが可能です。 さらに、このCNIは[ネットワークポリシーの適用のためにCalico](https://docs.aws.amazon.com/ja_jp/eks/latest/userguide/calico.html)と一緒に実行できます。AWS VPC CNIプロジェクトは、[GitHubのドキュメント](https://github.com/aws/amazon-vpc-cni-k8s)とともにオープンソースで公開されています。 @@ -89,7 +89,7 @@ Details on how the AOS system works can be accessed here: http://www.apstra.com/ [Azure CNI](https://docs.microsoft.com/en-us/azure/virtual-network/container-networking-overview) is an [open source](https://github.com/Azure/azure-container-networking/blob/master/docs/cni.md) plugin that integrates Kubernetes Pods with an Azure Virtual Network (also known as VNet) providing network performance at par with VMs. Pods can connect to peered VNet and to on-premises over Express Route or site-to-site VPN and are also directly reachable from these networks. Pods can access Azure services, such as storage and SQL, that are protected by Service Endpoints or Private Link. You can use VNet security policies and routing to filter Pod traffic. The plugin assigns VNet IPs to Pods by utilizing a pool of secondary IPs pre-configured on the Network Interface of a Kubernetes node. Azure CNI is available natively in the [Azure Kubernetes Service (AKS)] (https://docs.microsoft.com/en-us/azure/aks/configure-azure-cni). - + ### Big Cloud Fabric from Big Switch Networks @@ -289,4 +289,3 @@ to run, and in both cases, the network provides one IP address per pod - as is s ネットワークモデルの初期設計とその根拠、および将来の計画については、[ネットワーク設計ドキュメント](https://git.k8s.io/community/contributors/design-proposals/network/networking.md)で詳細に説明されています。 - diff --git a/content/ja/docs/concepts/configuration/assign-pod-node.md b/content/ja/docs/concepts/configuration/assign-pod-node.md index 7a6c27a1e5..fc05700e28 100644 --- a/content/ja/docs/concepts/configuration/assign-pod-node.md +++ b/content/ja/docs/concepts/configuration/assign-pod-node.md @@ -7,7 +7,7 @@ weight: 30 <!-- overview --> -[Pod](/ja/docs/concepts/workloads/pods/pod/)が稼働する[Node](/ja/docs/concepts/architecture/nodes/)を特定のものに指定したり、優先条件を指定して制限することができます。 +{{< glossary_tooltip text="Pod" term_id="pod" >}}が稼働する{{< glossary_tooltip text="Node" term_id="node" >}}を特定のものに指定したり、優先条件を指定して制限することができます。 これを実現するためにはいくつかの方法がありますが、推奨されている方法は[ラベルでの選択](/ja/docs/concepts/overview/working-with-objects/labels/)です。 スケジューラーが最適な配置を選択するため、一般的にはこのような制限は不要です(例えば、複数のPodを別々のNodeへデプロイしたり、Podを配置する際にリソースが不十分なNodeにはデプロイされないことが挙げられます)が、 SSDが搭載されているNodeにPodをデプロイしたり、同じアベイラビリティーゾーン内で通信する異なるサービスのPodを同じNodeにデプロイする等、柔軟な制御が必要なこともあります。 @@ -27,7 +27,7 @@ SSDが搭載されているNodeにPodをデプロイしたり、同じアベイ ### ステップ0: 前提条件 -この例では、KubernetesのPodに関して基本的な知識を有していることと、[Kubernetesクラスターのセットアップ](https://github.com/kubernetes/kubernetes#documentation)がされていることが前提となっています。 +この例では、KubernetesのPodに関して基本的な知識を有していることと、[Kubernetesクラスターのセットアップ](/ja/docs/setup/)がされていることが前提となっています。 ### ステップ1: Nodeへのラベルの付与 @@ -63,17 +63,20 @@ nodeSelectorを以下のように追加します: `kubectl apply -f https://k8s.io/examples/pods/pod-nginx.yaml`により、Podは先ほどラベルを付与したNodeへスケジュールされます。 `kubectl get pods -o wide`で表示される"NODE"の列から、PodがデプロイされているNodeを確認することができます。 -## 補足: ビルトインNodeラベル +## 補足: ビルトインNodeラベル {#built-in-node-labels} 明示的に[付与](#step-one-attach-label-to-the-node)するラベルの他に、事前にNodeへ付与されているものもあります。 以下のようなラベルが該当します。 -* `kubernetes.io/hostname` -* `failure-domain.beta.kubernetes.io/zone` -* `failure-domain.beta.kubernetes.io/region` -* `beta.kubernetes.io/instance-type` -* `kubernetes.io/os` -* `kubernetes.io/arch` +* [`kubernetes.io/hostname`](/docs/reference/kubernetes-api/labels-annotations-taints/#kubernetes-io-hostname) +* [`failure-domain.beta.kubernetes.io/zone`](/docs/reference/kubernetes-api/labels-annotations-taints/#failure-domainbetakubernetesiozone) +* [`failure-domain.beta.kubernetes.io/region`](/docs/reference/kubernetes-api/labels-annotations-taints/#failure-domainbetakubernetesioregion) +* [`topology.kubernetes.io/zone`](/docs/reference/kubernetes-api/labels-annotations-taints/#topologykubernetesiozone) +* [`topology.kubernetes.io/region`](/docs/reference/kubernetes-api/labels-annotations-taints/#topologykubernetesiozone) +* [`beta.kubernetes.io/instance-type`](/docs/reference/kubernetes-api/labels-annotations-taints/#beta-kubernetes-io-instance-type) +* [`node.kubernetes.io/instance-type`](/docs/reference/kubernetes-api/labels-annotations-taints/#nodekubernetesioinstance-type) +* [`kubernetes.io/os`](/docs/reference/kubernetes-api/labels-annotations-taints/#kubernetes-io-os) +* [`kubernetes.io/arch`](/docs/reference/kubernetes-api/labels-annotations-taints/#kubernetes-io-arch) {{< note >}} これらのラベルは、クラウドプロバイダー固有であり、確実なものではありません。 @@ -88,131 +91,127 @@ Nodeにラベルを付与することで、Podは特定のNodeやNodeグルー これは、安全性が損なわれたNodeがkubeletの認証情報をNodeのオブジェクトに設定したり、スケジューラーがそのようなNodeにデプロイすることを防ぎます。 `NodeRestriction`プラグインは、kubeletが`node-restriction.kubernetes.io/`プレフィックスを有するラベルの設定や上書きを防ぎます。 -Nodeの隔離にラベルのプレフィックスを使用するためには、以下の３点を確認してください。 +Nodeの隔離にラベルのプレフィックスを使用するためには、以下のようにします。 -1. NodeRestrictionを使用するため、Kubernetesのバージョンがv1.11以上であること。 -2. [Node authorizer](/docs/reference/access-authn-authz/node/)を使用していることと、[NodeRestriction admission plugin](/docs/reference/access-authn-authz/admission-controllers/#noderestriction)が有効になっていること。 -3. Nodeに`node-restriction.kubernetes.io/` プレフィックスのラベルを付与し、そのラベルがnode selectorに指定されていること。 +1. [Node authorizer](/docs/reference/access-authn-authz/node/)を使用していることと、[NodeRestriction admission plugin](/docs/reference/access-authn-authz/admission-controllers/#noderestriction)が_有効_になっていること。 +2. Nodeに`node-restriction.kubernetes.io/` プレフィックスのラベルを付与し、そのラベルがnode selectorに指定されていること。 例えば、`example.com.node-restriction.kubernetes.io/fips=true` または `example.com.node-restriction.kubernetes.io/pci-dss=true`のようなラベルです。 -## Affinity と Anti-Affinity {#affinity-and-anti-affinity} +## アフィニティとアンチアフィニティ {#affinity-and-anti-affinity} `nodeSelector`はPodの稼働を特定のラベルが付与されたNodeに制限する最も簡単な方法です。 -Affinity/Anti-Affinityでは、より柔軟な指定方法が提供されています。 +アフィニティ/アンチアフィニティでは、より柔軟な指定方法が提供されています。 拡張機能は以下の通りです。 -1. 様々な指定方法がある ("AND条件"に限らない) -2. 必須条件ではなく優先条件を指定でき、条件を満たさない場合でもPodをスケジュールさせることができる -3. Node自体のラベルではなく、Node(または他のトポロジカルドメイン)上で稼働している他のPodのラベルに対して条件を指定することができ、そのPodと同じ、または異なるドメインで稼働させることができる +1. アフィニティ/アンチアフィニティという用語はとても表現豊かです。この用語は論理AND演算で作成された完全一致だけではなく、より多くのマッチングルールを提供します。 +2. 必須条件ではなく優先条件を指定でき、条件を満たさない場合でもPodをスケジュールさせることができます。 +3. Node自体のラベルではなく、Node(または他のトポロジカルドメイン)上で稼働している他のPodのラベルに対して条件を指定することができ、そのPodと同じ、または異なるドメインで稼働させることができます。 -Affinityは"Node Affinity"と"Inter-Pod Affinity/Anti-Affinity"の2種類から成ります。 -Node affinityは`nodeSelector`(前述の2つのメリットがあります)に似ていますが、Inter-Pod Affinity/Anti-Affinityは、上記の3番目の機能に記載している通り、NodeのラベルではなくPodのラベルに対して制限をかけます。 +アフィニティは"Nodeアフィニティ"と"Pod間アフィニティ/アンチアフィニティ"の2種類から成ります。 +Nodeアフィニティは`nodeSelector`(前述の2つのメリットがあります)に似ていますが、Pod間アフィニティ/アンチアフィニティは、上記の3番目の機能に記載している通り、NodeのラベルではなくPodのラベルに対して制限をかけます。 -`nodeSelector`は問題なく使用することができますが、Node affinityは`nodeSelector`で指定できる条件を全て実現できるため、将来的には推奨されなくなります。 +### Nodeアフィニティ -### Node Affinity +Nodeアフィニティは概念的には、NodeのラベルによってPodがどのNodeにスケジュールされるかを制限する`nodeSelector`と同様です。 -Node Affinityはα機能としてKubernetesのv1.2から導入されました。 -Node Affinityは概念的には、NodeのラベルによってPodがどのNodeにスケジュールされるかを制限する`nodeSelector`と同様です。 - -現在は2種類のNode Affinityがあり、`requiredDuringSchedulingIgnoredDuringExecution`と`preferredDuringSchedulingIgnoredDuringExecution`です。 +現在は2種類のNodeアフィニティがあり、`requiredDuringSchedulingIgnoredDuringExecution`と`preferredDuringSchedulingIgnoredDuringExecution`です。 前者はNodeにスケジュールされるPodが条件を満たすことが必須(`nodeSelector`に似ていますが、より柔軟に条件を指定できます)であり、後者は条件を指定できますが保証されるわけではなく、優先的に考慮されます。 "IgnoredDuringExecution"の意味するところは、`nodeSelector`の機能と同様であり、Nodeのラベルが変更され、Podがその条件を満たさなくなった場合でも PodはそのNodeで稼働し続けるということです。 -将来的には、`requiredDuringSchedulingIgnoredDuringExecution`に、PodのNode Affinityに記された必須要件を満たさなくなったNodeからそのPodを退避させることができる機能を備えた`requiredDuringSchedulingRequiredDuringExecution`が提供される予定です。 +将来的には、`requiredDuringSchedulingIgnoredDuringExecution`に、PodのNodeアフィニティに記された必須要件を満たさなくなったNodeからそのPodを退避させることができる機能を備えた`requiredDuringSchedulingRequiredDuringExecution`が提供される予定です。 それぞれの使用例として、 `requiredDuringSchedulingIgnoredDuringExecution` は、"インテルCPUを供えたNode上でPodを稼働させる"、 `preferredDuringSchedulingIgnoredDuringExecution`は、"ゾーンXYZでPodの稼働を試みますが、実現不可能な場合には他の場所で稼働させる" といった方法が挙げられます。 -Node Affinityは、PodSpecの`affinity`フィールドにある`nodeAffinity`フィールドで特定します。 +Nodeアフィニティは、PodSpecの`affinity`フィールドにある`nodeAffinity`フィールドで特定します。 -Node Affinityを使用したPodの例を以下に示します: +Nodeアフィニティを使用したPodの例を以下に示します: {{< codenew file="pods/pod-with-node-affinity.yaml" >}} -このNode Affinityでは、Podはキーが`kubernetes.io/e2e-az-name`、値が`e2e-az1`または`e2e-az2`のラベルが付与されたNodeにしか配置されません。 +このNodeアフィニティでは、Podはキーが`kubernetes.io/e2e-az-name`、値が`e2e-az1`または`e2e-az2`のラベルが付与されたNodeにしか配置されません。 加えて、キーが`another-node-label-key`、値が`another-node-label-value`のラベルが付与されたNodeが優先されます。 この例ではオペレーター`In`が使われています。 -Node Affinityでは、`In`、`NotIn`、`Exists`、`DoesNotExist`、`Gt`、`Lt`のオペレーターが使用できます。 -`NotIn`と`DoesNotExist`はNode Anti-Affinity、またはPodを特定のNodeにスケジュールさせない場合に使われる[Taints](/docs/concepts/configuration/taint-and-toleration/)に使用します。 +Nodeアフィニティでは、`In`、`NotIn`、`Exists`、`DoesNotExist`、`Gt`、`Lt`のオペレーターが使用できます。 +`NotIn`と`DoesNotExist`はNodeアンチアフィニティ、またはPodを特定のNodeにスケジュールさせない場合に使われる[Taints](/docs/concepts/configuration/taint-and-toleration/)に使用します。 `nodeSelector`と`nodeAffinity`の両方を指定した場合、Podは**両方の**条件を満たすNodeにスケジュールされます。 -`nodeAffinity`内で複数の`nodeSelectorTerms`を指定した場合、Podは**いずれかの**`nodeSelectorTerms`を満たしたNodeへスケジュールされます。 +`nodeAffinity`内で複数の`nodeSelectorTerms`を指定した場合、Podは**全ての**`nodeSelectorTerms`を満たしたNodeへスケジュールされます。 -`nodeSelectorTerms`内で複数の`matchExpressions`を指定した場合にはPodは**全ての**`matchExpressions`を満たしたNodeへスケジュールされます。 +`nodeSelectorTerms`内で複数の`matchExpressions`を指定した場合にはPodは**いずれかの**`matchExpressions`を満たしたNodeへスケジュールされます。 PodがスケジュールされたNodeのラベルを削除したり変更しても、Podは削除されません。 -言い換えると、AffinityはPodをスケジュールする際にのみ考慮されます。 +言い換えると、アフィニティはPodをスケジュールする際にのみ考慮されます。 `preferredDuringSchedulingIgnoredDuringExecution`内の`weight`フィールドは、1から100の範囲で指定します。 -全ての必要条件(リソースやRequiredDuringScheduling Affinity等)を満たしたNodeに対して、スケジューラーはそのNodeがMatchExpressionsを満たした場合に、このフィルードの"weight"を加算して合計を計算します。 +全ての必要条件(リソースやRequiredDuringSchedulingアフィニティ等)を満たしたNodeに対して、スケジューラーはそのNodeがMatchExpressionsを満たした場合に、このフィルードの"weight"を加算して合計を計算します。 このスコアがNodeの他の優先機能のスコアと組み合わせれ、最も高いスコアを有したNodeが優先されます。 -### Inter-Pod Affinity/Anti-Affinity +### Pod間アフィニティとアンチアフィニティ -Inter-Pod AffinityとAnti-Affinityは、Nodeのラベルではなく、すでにNodeで稼働しているPodのラベルに従ってPodがスケジュールされるNodeを制限します。 -このポリシーは、"XにてルールYを満たすPodがすでに稼働している場合、このPodもXで稼働させる(Anti-Affinityの場合は稼働させない)"という形式です。 +Pod間アフィニティとアンチアフィニティは、Nodeのラベルではなく、すでにNodeで稼働しているPodのラベルに従ってPodがスケジュールされるNodeを制限します。 +このポリシーは、"XにてルールYを満たすPodがすでに稼働している場合、このPodもXで稼働させる(アンチアフィニティの場合は稼働させない)"という形式です。 Yはnamespaceのリストで指定したLabelSelectorで表されます。 Nodeと異なり、Podはnamespaceで区切られているため(それゆえPodのラベルも暗黙的にnamespaceで区切られます)、Podのラベルを指定するlabel selectorは、どのnamespaceにselectorを適用するかを指定する必要があります。 概念的に、XはNodeや、ラック、クラウドプロバイダゾーン、クラウドプロバイダのリージョン等を表すトポロジードメインです。 -これらを表すためにシステムが使用するNode Labelのキーである`topologyKey`を使うことで、トポロジードメインを指定することができます。 +これらを表すためにシステムが使用するNodeラベルのキーである`topologyKey`を使うことで、トポロジードメインを指定することができます。 先述のセクション[補足: ビルトインNodeラベル](#interlude-built-in-node-labels)にてラベルの例が紹介されています。 {{< note >}} -Inter-Pod AffinityとAnti-Affinityは、大規模なクラスター上で使用する際にスケジューリングを非常に遅くする恐れのある多くの処理を要します。 +Pod間アフィニティとアンチアフィニティは、大規模なクラスター上で使用する際にスケジューリングを非常に遅くする恐れのある多くの処理を要します。 そのため、数百台以上のNodeから成るクラスターでは使用することを推奨されません。 {{< /note >}} {{< note >}} -Pod Anti-Affinityは、Nodeに必ずラベルが付与されている必要があります。 -例えば、クラスターの全てのNodeが、`topologyKey`で指定されたものに合致する適切なラベルが必要になります。 +Podのアンチアフィニティは、Nodeに必ずラベルが付与されている必要があります。 +言い換えると、クラスターの全てのNodeが、`topologyKey`で指定されたものに合致する適切なラベルが必要になります。 それらが付与されていないNodeが存在する場合、意図しない挙動を示すことがあります。 {{< /note >}} -Node Affinityと同様に、Pod AffinityとPod Anti-Affinityにも必須条件と優先条件を示す`requiredDuringSchedulingIgnoredDuringExecution`と`preferredDuringSchedulingIgnoredDuringExecution`があります。 -前述のNode Affinityのセクションを参照してください。 -`requiredDuringSchedulingIgnoredDuringExecution`を指定するAffinityの使用例は、"Service AのPodとService BのPodが密に通信する際、それらを同じゾーンで稼働させる場合"です。 -また、`preferredDuringSchedulingIgnoredDuringExecution`を指定するAnti-Affinityの使用例は、"ゾーンをまたいでPodのサービスを稼働させる場合"(Podの数はゾーンの数よりも多いため、必須条件を指定すると合理的ではありません)です。 +Nodeアフィニティと同様に、PodアフィニティとPodアンチアフィニティにも必須条件と優先条件を示す`requiredDuringSchedulingIgnoredDuringExecution`と`preferredDuringSchedulingIgnoredDuringExecution`があります。 +前述のNodeアフィニティのセクションを参照してください。 +`requiredDuringSchedulingIgnoredDuringExecution`を指定するアフィニティの使用例は、"Service AのPodとService BのPodが密に通信する際、それらを同じゾーンで稼働させる場合"です。 +また、`preferredDuringSchedulingIgnoredDuringExecution`を指定するアンチアフィニティの使用例は、"ゾーンをまたいでPodのサービスを稼働させる場合"(Podの数はゾーンの数よりも多いため、必須条件を指定すると合理的ではありません)です。 -Inter-Pod Affinityは、PodSpecの`affinity`フィールド内に`podAffinity`で指定し、Inter-Pod Anti-Affinityは、`podAntiAffinity`で指定します。 +Pod間アフィニティは、PodSpecの`affinity`フィールド内に`podAffinity`で指定し、Pod間アンチアフィニティは、`podAntiAffinity`で指定します。 -#### Pod Affinityを使用したPodの例 +#### Podアフィニティを使用したPodの例 {{< codenew file="pods/pod-with-pod-affinity.yaml" >}} -このPodのAffifnityは、Pod AffinityとPod Anti-Affinityを1つずつ定義しています。 +このPodのアフィニティは、PodアフィニティとPodアンチアフィニティを1つずつ定義しています。 この例では、`podAffinity`に`requiredDuringSchedulingIgnoredDuringExecution`、`podAntiAffinity`に`preferredDuringSchedulingIgnoredDuringExecution`が設定されています。 -Pod Affinityは、「キーが"security"、値が"S1"のラベルが付与されたPodが少なくとも1つは稼働しているNodeが同じゾーンにあれば、PodはそのNodeにスケジュールされる」という条件を指定しています(より正確には、キーが"security"、値が"S1"のラベルが付与されたPodが稼働しており、キーが`failure-domain.beta.kubernetes.io/zone`、値がVであるNodeが少なくとも1つはある状態で、 +Podアフィニティは、「キーが"security"、値が"S1"のラベルが付与されたPodが少なくとも1つは稼働しているNodeが同じゾーンにあれば、PodはそのNodeにスケジュールされる」という条件を指定しています(より正確には、キーが"security"、値が"S1"のラベルが付与されたPodが稼働しており、キーが`failure-domain.beta.kubernetes.io/zone`、値がVであるNodeが少なくとも1つはある状態で、 Node Nがキー`failure-domain.beta.kubernetes.io/zone`、値Vのラベルを持つ場合に、PodはNode Nで稼働させることができます)。 -Pod Anti-Affinityは、「すでにあるNode上で、キーが"security"、値が"S2"であるPodが稼働している場合に、Podを可能な限りそのNode上で稼働させない」という条件を指定しています +Podアンチアフィニティは、「すでにあるNode上で、キーが"security"、値が"S2"であるPodが稼働している場合に、Podを可能な限りそのNode上で稼働させない」という条件を指定しています (`topologyKey`が`failure-domain.beta.kubernetes.io/zone`であった場合、キーが"security"、値が"S2"であるであるPodが稼働しているゾーンと同じゾーン内のNodeにはスケジュールされなくなります)。 -Pod AffinityとPod Anti-Affinityや、`requiredDuringSchedulingIgnoredDuringExecution`と`preferredDuringSchedulingIgnoredDuringExecution`に関する他の使用例は[デザインドック](https://git.k8s.io/community/contributors/design-proposals/scheduling/podaffinity.md)を参照してください。 +PodアフィニティとPodアンチアフィニティや、`requiredDuringSchedulingIgnoredDuringExecution`と`preferredDuringSchedulingIgnoredDuringExecution`に関する他の使用例は[デザインドック](https://git.k8s.io/community/contributors/design-proposals/scheduling/podaffinity.md)を参照してください。 -Pod AffinityとPod Anti-Affinityで使用できるオペレーターは、`In`、`NotIn`、 `Exists`、 `DoesNotExist`です。 +PodアフィニティとPodアンチアフィニティで使用できるオペレーターは、`In`、`NotIn`、 `Exists`、 `DoesNotExist`です。 原則として、`topologyKey`には任意のラベルとキーが使用できます。 しかし、パフォーマンスやセキュリティの観点から、以下の制約があります: -1. Affinityと、`requiredDuringSchedulingIgnoredDuringExecution`を指定したPod Anti-Affinityでは、`topologyKey`を指定しないことは許可されていません。 -2. `requiredDuringSchedulingIgnoredDuringExecution`を指定したPod Anti-Affinityでは、`kubernetes.io/hostname`の`topologyKey`を制限するため、アドミッションコントローラー`LimitPodHardAntiAffinityTopology`が導入されました。 +1. アフィニティと、`requiredDuringSchedulingIgnoredDuringExecution`を指定したPodアンチアフィニティは、`topologyKey`を指定しないことは許可されていません。 +2. `requiredDuringSchedulingIgnoredDuringExecution`を指定したPodアンチアフィニティでは、`kubernetes.io/hostname`の`topologyKey`を制限するため、アドミッションコントローラー`LimitPodHardAntiAffinityTopology`が導入されました。 トポロジーをカスタマイズする場合には、アドミッションコントローラーを修正または無効化する必要があります。 -3. `preferredDuringSchedulingIgnoredDuringExecution`を指定したPod Anti-Affinityでは、`topologyKey`を指定しなかった場合、"全てのトポロジー"と解釈されます("全てのトポロジー"とは、ここでは`kubernetes.io/hostname`、`failure-domain.beta.kubernetes.io/zone`、`failure-domain.beta.kubernetes.io/region`を合わせたものを意味します)。 +3. `preferredDuringSchedulingIgnoredDuringExecution`を指定したPodアンチアフィニティでは、`topologyKey`を省略することはできません。 4. 上記の場合を除き、`topologyKey` は任意のラベルとキーを指定することができあます。 `labelSelector`と`topologyKey`に加え、`labelSelector`が合致すべき`namespaces`のリストを特定することも可能です(これは`labelSelector`と`topologyKey`を定義することと同等です)。 -省略した場合や空の場合は、AffinityとAnti-Affinityが定義されたPodのnamespaceがデフォルトで設定されます。 +省略した場合や空の場合は、アフィニティとアンチアフィニティが定義されたPodのnamespaceがデフォルトで設定されます。 -`requiredDuringSchedulingIgnoredDuringExecution`が指定されたAffinityとAnti-Affinityでは、`matchExpressions`に記載された全ての条件が満たされるNodeにPodがスケジュールされます。 +`requiredDuringSchedulingIgnoredDuringExecution`が指定されたアフィニティとアンチアフィニティでは、`matchExpressions`に記載された全ての条件が満たされるNodeにPodがスケジュールされます。 #### 実際的なユースケース -Inter-Pod AffinityとAnti-Affinityは、ReplicaSet、StatefulSet、Deploymentなどのより高レベルなコレクションと併せて使用すると更に有用です。 +Pod間アフィニティとアンチアフィニティは、ReplicaSet、StatefulSet、Deploymentなどのより高レベルなコレクションと併せて使用するとさらに有用です。 Workloadが、Node等の定義された同じトポロジーに共存させるよう、簡単に設定できます。 @@ -325,7 +324,7 @@ web-server-1287567482-s330j 1/1 Running 0 7m 10.192.3 ##### 同じNodeに共存させない場合 上記の例では `PodAntiAffinity`を`topologyKey: "kubernetes.io/hostname"`と合わせて指定することで、redisクラスター内の2つのインスタンスが同じホストにデプロイされない場合を扱いました。 -同様の方法で、Anti-Affinityを用いて高可用性を実現したStatefulSetの使用例は[ZooKeeper tutorial](/docs/tutorials/stateful-application/zookeeper/#tolerating-node-failure)を参照してください。 +同様の方法で、アンチアフィニティを用いて高可用性を実現したStatefulSetの使用例は[ZooKeeper tutorial](/docs/tutorials/stateful-application/zookeeper/#tolerating-node-failure)を参照してください。 ## nodeName @@ -338,7 +337,7 @@ web-server-1287567482-s330j 1/1 Running 0 7m 10.192.3 `nodeName`を使用することによる制約は以下の通りです: - その名前のNodeが存在しない場合、Podは起動されす、自動的に削除される場合があります。 -- その名前のNodeにPodを稼働させるためのリソースがない場合、Podの起動は失敗し、理由はOutOfmemoryやOutOfcpuになります。 +- その名前のNodeにPodを稼働させるためのリソースがない場合、Podの起動は失敗し、理由は例えばOutOfmemoryやOutOfcpuになります。 - クラウド上のNodeの名前は予期できず、変更される可能性があります。 `nodeName`を指定したPodの設定ファイルの例を示します: @@ -364,8 +363,9 @@ spec: [Taints](/docs/concepts/configuration/taint-and-toleration/)を使うことで、NodeはPodを追い出すことができます。 -[Node Affinity](https://git.k8s.io/community/contributors/design-proposals/scheduling/nodeaffinity.md)と -[Inter-Pod Affinity/Anti-Affinity](https://git.k8s.io/community/contributors/design-proposals/scheduling/podaffinity.md) -には、Taintsの要点に関して様々な背景が紹介されています。 - +[Nodeアフィニティ](https://git.k8s.io/community/contributors/design-proposals/scheduling/nodeaffinity.md)と +[Pod間アフィニティ/アンチアフィニティ](https://git.k8s.io/community/contributors/design-proposals/scheduling/podaffinity.md) +のデザインドキュメントには、これらの機能の追加のバックグラウンドの情報が記載されています。 +一度PodがNodeに割り当たると、kubeletはPodを起動してノード内のリソースを確保します。 +[トポロジーマネージャー](/docs/tasks/administer-cluster/topology-manager/)はNodeレベルのリソース割り当てを決定する際に関与します。 diff --git a/content/ja/docs/concepts/configuration/configmap.md b/content/ja/docs/concepts/configuration/configmap.md new file mode 100644 index 0000000000..54147a7a90 --- /dev/null +++ b/content/ja/docs/concepts/configuration/configmap.md @@ -0,0 +1,191 @@ +--- +title: ConfigMap +content_type: concept +weight: 20 +--- + +<!-- overview --> + +{{< glossary_definition term_id="configmap" prepend="ConfigMapは、" length="all" >}} + +{{< caution >}} +ConfigMapは機密性や暗号化を提供しません。保存したいデータが機密情報である場合は、ConfigMapの代わりに{{< glossary_tooltip text="Secret" term_id="secret" >}}を使用するか、追加の(サードパーティー)ツールを使用してデータが非公開になるようにしてください。 +{{< /caution >}} + +<!-- body --> + +## 動機 + +アプリケーションのコードとは別に設定データを設定するには、ConfigMapを使用します。 + +たとえば、アプリケーションを開発していて、(開発用時には)自分のコンピューター上と、(実際のトラフィックをハンドルするときは)クラウド上とで実行することを想像してみてください。あなたは、`DATABASE_HOST`という名前の環境変数を使用するコードを書きます。ローカルでは、この変数を`localhost`に設定します。クラウド上では、データベースコンポーネントをクラスター内に公開するKubernetesの{{< glossary_tooltip text="Service" term_id="service" >}}を指すように設定します。 + +こうすることで、必要であればクラウド上で実行しているコンテナイメージを取得することで、ローカルでも完全に同じコードを使ってデバッグができるようになります。 + +## ConfigMapオブジェクト + +ConfigMapは、他のオブジェクトが使うための設定を保存できるAPI[オブジェクト](/ja/docs/concepts/overview/working-with-objects/kubernetes-objects/)です。ほとんどのKubernetesオブジェクトに`spec`セクションがあるのとは違い、ConfigMapにはアイテム(キー)と値を保存するための`data`セクションがあります。 + +ConfigMapの名前は、有効な[DNSのサブドメイン名](/ja/docs/concepts/overview/working-with-objects/names#dns-subdomain-names)でなければなりません。 + +## ConfigMapとPod + +ConfigMapを参照して、ConfigMap内のデータを元にしてPod内のコンテナの設定をするPodの`spec`を書くことができます。このとき、PodとConfigMapは同じ{{< glossary_tooltip text="名前空間" term_id="namespace" >}}内に存在する必要があります。 + +以下に、ConfigMapの例を示します。単一の値を持つキーと、Configuration形式のデータ片のような値を持つキーがあります。 + +```yaml +apiVersion: v1 +kind: ConfigMap +metadata: + name: game-demo +data: + # プロパティーに似たキー。各キーは単純な値にマッピングされている + player_initial_lives: "3" + ui_properties_file_name: "user-interface.properties" + # + # ファイルに似たキー + game.properties: | + enemy.types=aliens,monsters + player.maximum-lives=5 + user-interface.properties: | + color.good=purple + color.bad=yellow + allow.textmode=true +``` + +ConfigMapを利用してPod内のコンテナを設定する方法には、次の4種類があります。 + +1. コマンドライン引数をコンテナのエントリーポイントに渡す +1. 環境変数をコンテナに渡す +1. 読み取り専用のボリューム内にファイルを追加し、アプリケーションがそのファイルを読み取る +1. Kubernetes APIを使用してConfigMapを読み込むコードを書き、そのコードをPod内で実行する + +これらのさまざまな方法は、利用するデータをモデル化するのに役立ちます。最初の3つの方法では、{{< glossary_tooltip text="kubelet" term_id="kubelet" >}}がPodのコンテナを起動する時にConfigMapのデータを使用します。 + +4番目の方法では、ConfigMapとそのデータを読み込むためのコードを自分自身で書く必要があります。しかし、Kubernetes APIを直接使用するため、アプリケーションはConfigMapがいつ変更されても更新イベントを受信でき、変更が発生したときにすぐに反応できます。この手法では、Kubernetes APIに直接アクセスすることで、別の名前空間にあるConfigMapにもアクセスできます。 + +以下に、Podを設定するために`game-demo`から値を使用するPodの例を示します。 + +```yaml +apiVersion: v1 +kind: Pod +metadata: + name: configmap-demo-pod +spec: + containers: + - name: demo + image: game.example/demo-game + env: + # 環境変数を定義します。 + - name: PLAYER_INITIAL_LIVES # ここではConfigMap内のキーの名前とは違い + # 大文字が使われていることに着目してください。 + valueFrom: + configMapKeyRef: + name: game-demo # この値を取得するConfigMap。 + key: player_initial_lives # 取得するキー。 + - name: UI_PROPERTIES_FILE_NAME + valueFrom: + configMapKeyRef: + name: game-demo + key: ui_properties_file_name + volumeMounts: + - name: config + mountPath: "/config" + readOnly: true + volumes: + # Podレベルでボリュームを設定し、Pod内のコンテナにマウントします。 + - name: config + configMap: + # マウントしたいConfigMapの名前を指定します。 + name: game-demo + # ファイルとして作成するConfigMapのキーの配列 + items: + - key: "game.properties" + path: "game.properties" + - key: "user-interface.properties" + path: "user-interface.properties" +``` + +ConfigMapは1行のプロパティの値と複数行のファイルに似た形式の値を区別しません。問題となるのは、Podや他のオブジェクトによる値の使用方法です。 + +この例では、ボリュームを定義して、`demo`コンテナの内部で`/config`にマウントしています。これにより、ConfigMap内には4つのキーがあるにもかかわらず、2つのファイル`/config/game.properties`および`/config/user-interface.properties`だけが作成されます。 + +これは、Podの定義が`volumes`セクションで`items`という配列を指定しているためです。もし`items`の配列を完全に省略すれば、ConfigMap内の各キーがキーと同じ名前のファイルになり、4つのファイルが作成されます。 + +## ConfigMapを使う + +ConfigMapは、データボリュームとしてマウントできます。ConfigMapは、Podへ直接公開せずにシステムの他の部品として使うこともできます。たとえば、ConfigMapには、システムの他の一部が設定のために使用するデータを保存できます。 + +{{< note >}} +ConfigMapの最も一般的な使い方では、同じ名前空間にあるPod内で実行されているコンテナに設定を構成します。ConfigMapを独立して使用することもできます。 + +たとえば、ConfigMapに基づいて動作を調整する{{< glossary_tooltip text="アドオン" term_id="addons" >}}や{{< glossary_tooltip text="オペレーター" term_id="operator-pattern" >}}を見かけることがあるかもしれません。 +{{< /note >}} + +### ConfigMapをPodからファイルとして使う + +ConfigMapをPod内のボリュームで使用するには、次のようにします。 + +1. ConfigMapを作成するか、既存のConfigMapを使用します。複数のPodから同じConfigMapを参照することもできます。 +1. Podの定義を修正して、`.spec.volumes[]`以下にボリュームを追加します。ボリュームに任意の名前を付け、`.spec.volumes[].configMap.name`フィールドにConfigMapオブジェクトへの参照を設定します。 +1. ConfigMapが必要な各コンテナに`.spec.containers[].volumeMounts[]`を追加します。`.spec.containers[].volumeMounts[].readOnly = true`を指定して、`.spec.containers[].volumeMounts[].mountPath`には、ConfigMapのデータを表示したい未使用のディレクトリ名を指定します。 +1. イメージまたはコマンドラインを修正して、プログラムがそのディレクトリ内のファイルを読み込むように設定します。ConfigMapの`data`マップ内の各キーが、`mountPath`以下のファイル名になります。 + +以下は、ボリューム内にConfigMapをマウントするPodの例です。 + +```yaml +apiVersion: v1 +kind: Pod +metadata: + name: mypod +spec: + containers: + - name: mypod + image: redis + volumeMounts: + - name: foo + mountPath: "/etc/foo" + readOnly: true + volumes: + - name: foo + configMap: + name: myconfigmap +``` + +使用したいそれぞれのConfigMapごとに、`.spec.volumes`内で参照する必要があります。 + +Pod内に複数のコンテナが存在する場合、各コンテナにそれぞれ別の`volumeMounts`のブロックが必要ですが、`.spec.volumes`はConfigMapごとに1つしか必要ありません。 + +#### マウントしたConfigMapの自動的な更新 + +ボリューム内で現在使用中のConfigMapが更新されると、射影されたキーも最終的に(eventually)更新されます。kubeletは定期的な同期のたびにマウントされたConfigMapが新しいかどうか確認します。しかし、kubeletが現在のConfigMapの値を取得するときにはローカルキャッシュを使用します。キャッシュの種類は、[KubeletConfiguration構造体](https://github.com/kubernetes/kubernetes/blob/{{< param "docsbranch" >}}/staging/src/k8s.io/kubelet/config/v1beta1/types.go)の中の`ConfigMapAndSecretChangeDetectionStrategy`フィールドで設定可能です。ConfigMapは、監視(デフォルト)、ttlベース、またはすべてのリクエストを直接APIサーバーへ単純にリダイレクトする方法のいずれかによって伝搬されます。その結果、ConfigMapが更新された瞬間から、新しいキーがPodに射影されるまでの遅延の合計は、最長でkubeletの同期期間+キャッシュの伝搬遅延になります。ここで、キャッシュの伝搬遅延は選択したキャッシュの種類に依存します(監視の伝搬遅延、キャッシュのttl、または0に等しくなります)。 + +{{< feature-state for_k8s_version="v1.18" state="alpha" >}} + +Kubernetesのアルファ版の機能である _イミュータブルなSecretおよびConfigMap_ は、個別のSecretやConfigMapをイミュータブルに設定するオプションを提供します。ConfigMapを広範に使用している(少なくとも数万のConfigMapがPodにマウントされている)クラスターでは、データの変更を防ぐことにより、以下のような利点が得られます。 + +- アプリケーションの停止を引き起こす可能性のある予想外の(または望まない)変更を防ぐことができる +- ConfigMapをイミュータブルにマークして監視を停止することにより、kube-apiserverへの負荷を大幅に削減し、クラスターの性能が向上する + +この機能を使用するには、`ImmutableEmphemeralVolumes`[フィーチャーゲート](/ja/docs/reference/command-line-tools-reference/feature-gates/)を有効にして、SecretやConfigMapの`immutable`フィールドを`true`に設定してください。次に例を示します。 + +```yaml +apiVersion: v1 +kind: ConfigMap +metadata: + ... +data: + ... +immutable: true +``` + +{{< note >}} +一度ConfigMapやSecretがイミュータブルに設定すると、この変更を元に戻したり、`data`フィールドのコンテンツを変更することは*できません*。既存のPodは削除されたConfigMapのマウントポイントを保持するため、こうしたPodは再作成することをおすすめします。 +{{< /note >}} + +## {{% heading "whatsnext" %}} + +* [Secret](/docs/concepts/configuration/secret/)について読む。 +* [Podを構成してConfigMapを使用する](/ja/docs/tasks/configure-pod-container/configure-pod-configmap/)を読む。 +* コードを設定から分離する動機を理解するために[The Twelve-Factor App](https://12factor.net/ja/)を読む。 diff --git a/content/ja/docs/concepts/configuration/overview.md b/content/ja/docs/concepts/configuration/overview.md index 791582e11b..2a5dfc4a51 100644 --- a/content/ja/docs/concepts/configuration/overview.md +++ b/content/ja/docs/concepts/configuration/overview.md @@ -27,11 +27,11 @@ weight: 10 - よりよいイントロスペクションのために、オブジェクトの説明をアノテーションに入れましょう。 -## "真っ裸"のPod に対する ReplicaSet、Deployment、およびJob +## "真っ裸"のPod に対する ReplicaSet、Deployment、およびJob {#naked-pods-vs-replicasets-deployments-and-jobs} - 可能な限り、"真っ裸"のPod([ReplicaSet](/ja/docs/concepts/workloads/controllers/replicaset/)や[Deployment](/ja/docs/concepts/workloads/controllers/deployment/)にバインドされていないPod)は使わないでください。Nodeに障害が発生した場合、これらのPodは再スケジュールされません。 - 明示的に[`restartPolicy: Never`](/ja/docs/concepts/workloads/pods/pod-lifecycle/#restart-policy)を使いたいシーンを除いて、DeploymentはPodを直接作成するよりもほとんど常に望ましい方法です。Deploymentには、希望する数のPodが常に使用可能であることを確認するためにReplicaSetを作成したり、Podを置き換えるための戦略（RollingUpdateなど）を指定したりできます。[Job](/docs/concepts/workloads/controllers/jobs-run-to-completion/)のほうが適切な場合もあるかもしれません。 + 明示的に[`restartPolicy: Never`](/ja/docs/concepts/workloads/pods/pod-lifecycle/#restart-policy)を使いたいシーンを除いて、DeploymentはPodを直接作成するよりもほとんど常に望ましい方法です。Deploymentには、希望する数のPodが常に使用可能であることを確認するためにReplicaSetを作成したり、Podを置き換えるための戦略(RollingUpdateなど)を指定したりできます。[Job](/docs/concepts/workloads/controllers/jobs-run-to-completion/)のほうが適切な場合もあるかもしれません。 ## Service @@ -81,7 +81,7 @@ weight: 10 - `imagePullPolicy: Never`: 常にローカルでイメージを探そうとします。ない場合にもイメージはpullしません。 {{< note >}} -コンテナが常に同じバージョンのイメージを使用するようにするためには、そのコンテナイメージの[ダイジェスト](https://docs.docker.com/engine/reference/commandline/pull/#pull-an-image-by-digest-immutable-identifier)を指定することができます(例:`sha256:45b23dee08af5e43a7fea6c4cf9c25ccf269ee113168c19722f87876677c5cb2`)。このダイジェストはイメージの特定のバージョンを一意に識別するため、ダイジェスト値を変更しない限り、Kubernetesによって更新されることはありません。 +コンテナが常に同じバージョンのイメージを使用するようにするためには、そのコンテナイメージの[ダイジェスト](https://docs.docker.com/engine/reference/commandline/pull/#pull-an-image-by-digest-immutable-identifier)を指定することができます。`<image-name>:<tag>`を`<image-name>@<digest>`で置き換えます(例:`image@sha256:45b23dee08af5e43a7fea6c4cf9c25ccf269ee113168c19722f87876677c5cb2`)。このダイジェストはイメージの特定のバージョンを一意に識別するため、ダイジェスト値を変更しない限り、Kubernetesによって更新されることはありません。 {{< /note >}} {{< note >}} @@ -89,7 +89,7 @@ weight: 10 {{< /note >}} {{< note >}} -ベースイメージのプロバイダーのキャッシュセマンティクスにより、`imagePullPolicy：Always`もより効率的になります。たとえば、Dockerでは、イメージが既に存在する場合すべてのイメージレイヤーがキャッシュされ、イメージのダウンロードが不要であるため、pullが高速になります。 +ベースイメージのプロバイダーのキャッシュセマンティクスにより、`imagePullPolicy：Always`もより効率的になります。たとえば、Dockerでは、イメージがすでに存在する場合すべてのイメージレイヤーがキャッシュされ、イメージのダウンロードが不要であるため、pullが高速になります。 {{< /note >}} ## kubectlの使い方 diff --git a/content/ja/docs/concepts/configuration/secret.md b/content/ja/docs/concepts/configuration/secret.md new file mode 100644 index 0000000000..26ce98ab50 --- /dev/null +++ b/content/ja/docs/concepts/configuration/secret.md @@ -0,0 +1,1157 @@ +--- +title: Secrets +content_type: concept +feature: + title: Secretと構成管理 + description: > + Secretやアプリケーションの構成情報を、イメージの再ビルドや機密情報を晒すことなくデプロイ、更新します +weight: 30 +--- + +<!-- overview --> + +KubernetesのSecretはパスワード、OAuthトークン、SSHキーのような機密情報を保存し、管理できるようにします。 +Secretに機密情報を保存することは、それらを{{< glossary_tooltip text="Pod" term_id="pod" >}}の定義や{{< glossary_tooltip text="コンテナイメージ" term_id="image" >}}に直接記載するより、安全で柔軟です。詳しくは[Secretの設計文書](https://git.k8s.io/community/contributors/design-proposals/auth/secrets.md)を参照してください。 + + + +<!-- body --> + +## Secretの概要 + +Secretはパスワード、トークン、キーのような小容量の機密データを含むオブジェクトです。 +他の方法としては、そのような情報はPodの定義やイメージに含めることができます。 +ユーザーはSecretを作ることができ、またシステムが作るSecretもあります。 + +Secretを使うには、PodはSecretを参照することが必要です。 +PodがSecretを使う方法は3種類あります。 + +- {{< glossary_tooltip text="ボリューム" term_id="volume" >}}内の[ファイル](#using-secrets-as-files-from-a-pod)として、Podの単一または複数のコンテナにマウントする +- [コンテナの環境変数](#using-secrets-as-environment-variables)として利用する +- Podを生成するために[kubeletがイメージをpullする](#using-imagepullsecrets)ときに使用する + +### 内蔵のSecret + +#### 自動的にサービスアカウントがAPIの認証情報のSecretを生成し、アタッチする + +KubernetesはAPIにアクセスするための認証情報を含むSecretを自動的に生成し、この種のSecretを使うように自動的にPodを改変します。 + +必要であれば、APIの認証情報が自動生成され利用される機能は無効化したり、上書きしたりすることができます。しかし、安全にAPIサーバーでアクセスすることのみが必要なのであれば、これは推奨されるワークフローです。 + +サービスアカウントがどのように機能するのかについては、[サービスアカウント](/docs/tasks/configure-pod-container/configure-service-account/) +のドキュメントを参照してください。 + +### Secretを作成する + +#### `kubectl`を利用してSecretを作成する + +SecretにはPodがデータベースにアクセスするために必要な認証情報を含むことができます。 +例えば、ユーザー名とパスワードからなる接続文字列です。 +ローカルマシンのファイル`./username.txt`にユーザー名を、ファイル`./password.txt`にパスワードを保存することができます。 + +```shell +# この後の例で使用するファイルを作成します +echo -n 'admin' > ./username.txt +echo -n '1f2d1e2e67df' > ./password.txt +``` + +`kubectl create secret`コマンドはそれらのファイルをSecretに格納して、APIサーバー上でオブジェクトを作成します。 +Secretオブジェクトの名称は正当な[DNSサブドメイン名](/ja/docs/concepts/overview/working-with-objects/names/#dns-subdomain-names)である必要があります。 + +```shell +kubectl create secret generic db-user-pass --from-file=./username.txt --from-file=./password.txt +``` + +次のように出力されます: + +``` +secret "db-user-pass" created +``` + +デフォルトのキー名はファイル名です。`[--from-file=[key=]source]`を使って任意でキーを指定することができます。 + +```shell +kubectl create secret generic db-user-pass --from-file=username=./username.txt --from-file=password=./password.txt +``` + +{{< note >}} +`$`、`\`、`*`、`=`、`!`のような特殊文字は[シェル](https://ja.wikipedia.org/wiki/%E3%82%B7%E3%82%A7%E3%83%AB)に解釈されるので、エスケープする必要があります。 +ほとんどのシェルではパスワードをエスケープする最も簡単な方法はシングルクォート(`'`)で囲むことです。 +例えば、実際のパスワードが`S!B\*d$zDsb=`だとすると、実行すべきコマンドは下記のようになります。 + +```shell +kubectl create secret generic dev-db-secret --from-literal=username=devuser --from-literal=password='S!B\*d$zDsb=' +``` + +`--from-file`を使ってファイルからパスワードを読み込む場合、ファイルに含まれるパスワードの特殊文字をエスケープする必要はありません。 +{{< /note >}} + +Secretが作成されたことを確認できます。 + +```shell +kubectl get secrets +``` + +出力は次のようになります。 + +``` +NAME TYPE DATA AGE +db-user-pass Opaque 2 51s +``` + +Secretの説明を参照することができます。 + +```shell +kubectl describe secrets/db-user-pass +``` + +出力は次のようになります。 + +``` +Name: db-user-pass +Namespace: default +Labels: <none> +Annotations: <none> + +Type: Opaque + +Data +==== +password.txt: 12 bytes +username.txt: 5 bytes +``` + +{{< note >}} +`kubectl get`や`kubectl describe`コマンドはデフォルトではSecretの内容の表示を避けます。 +これはSecretを誤って盗み見られたり、ターミナルのログへ記録されてしまったりすることがないよう保護するためです。 +{{< /note >}} + +Secretの内容を参照する方法は[Secretのデコード](#decoding-a-secret)を参照してください。 + +#### 手動でSecretを作成する + +SecretをJSONまたはYAMLフォーマットのファイルで作成し、その後オブジェクトを作成することができます。 +Secretオブジェクトの名称は正当な[DNSサブドメイン名](/ja/docs/concepts/overview/working-with-objects/names/#dns-subdomain-names)である必要があります。 +[Secret](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#secret-v1-core)は、`data`と`stringData`の2つの連想配列を持ちます。 +`data`フィールドは任意のデータの保存に使われ、Base64でエンコードされています。 +`stringData`は利便性のために存在するもので、機密データをエンコードされない文字列で扱えます。 + +例えば、`data`フィールドを使って1つのSecretに2つの文字列を保存するには、次のように文字列をBase64エンコードします。 + +```shell +echo -n 'admin' | base64 +``` + +出力は次のようになります。 + +``` +YWRtaW4= +``` + +```shell +echo -n '1f2d1e2e67df' | base64 +``` + +出力は次のようになります。 + +``` +MWYyZDFlMmU2N2Rm +``` + +このようなSecretを書きます。 + +```yaml +apiVersion: v1 +kind: Secret +metadata: + name: mysecret +type: Opaque +data: + username: YWRtaW4= + password: MWYyZDFlMmU2N2Rm +``` + +これでSecretを[`kubectl apply`](/docs/reference/generated/kubectl/kubectl-commands#apply)コマンドで作成できるようになりました。 + +```shell +kubectl apply -f ./secret.yaml +``` + +出力は次のようになります。 + +``` +secret "mysecret" created +``` + +状況によっては、代わりに`stringData`フィールドを使いたいときもあるでしょう。 +このフィールドを使えばBase64でエンコードされていない文字列を直接Secretに書くことができて、その文字列はSecretが作られたり更新されたりするときにエンコードされます。 + +実用的な例として、設定ファイルの格納にSecretを使うアプリケーションをデプロイすることを考えます。 +デプロイプロセスの途中で、この設定ファイルの一部のデータを投入したいとしましょう。 + +例えば、アプリケーションは次のような設定ファイルを使用するとします。 + +```yaml +apiUrl: "https://my.api.com/api/v1" +username: "user" +password: "password" +``` + +次のような定義を使用して、この設定ファイルをSecretに保存することができます。 + +```yaml +apiVersion: v1 +kind: Secret +metadata: + name: mysecret +type: Opaque +stringData: + config.yaml: |- + apiUrl: "https://my.api.com/api/v1" + username: {{username}} + password: {{password}} +``` + +デプロイツールは`kubectl apply`を実行する前に`{{username}}`と`{{password}}`のテンプレート変数を置換することができます。 + +`stringData`フィールドは利便性のための書き込み専用フィールドです。 +Secretを取得するときに出力されることは決してありません。 +例えば、次のコマンドを実行すると、 + +```shell +kubectl get secret mysecret -o yaml +``` + +出力は次のようになります。 + +```yaml +apiVersion: v1 +kind: Secret +metadata: + creationTimestamp: 2018-11-15T20:40:59Z + name: mysecret + namespace: default + resourceVersion: "7225" + uid: c280ad2e-e916-11e8-98f2-025000000001 +type: Opaque +data: + config.yaml: YXBpVXJsOiAiaHR0cHM6Ly9teS5hcGkuY29tL2FwaS92MSIKdXNlcm5hbWU6IHt7dXNlcm5hbWV9fQpwYXNzd29yZDoge3twYXNzd29yZH19 +``` + +`username`のようなフィールドを`data`と`stringData`の両方で指定すると、`stringData`の値が使用されます。 +例えば、次のSecret定義からは + +```yaml +apiVersion: v1 +kind: Secret +metadata: + name: mysecret +type: Opaque +data: + username: YWRtaW4= +stringData: + username: administrator +``` + +次のようなSecretが生成されます。 + +```yaml +apiVersion: v1 +kind: Secret +metadata: + creationTimestamp: 2018-11-15T20:46:46Z + name: mysecret + namespace: default + resourceVersion: "7579" + uid: 91460ecb-e917-11e8-98f2-025000000001 +type: Opaque +data: + username: YWRtaW5pc3RyYXRvcg== +``` + +`YWRtaW5pc3RyYXRvcg==`をデコードすると`administrator`になります。 + +`data`や`stringData`のキーは英数字または'-'、'_'、'.'からなる必要があります。 + +{{< note >}} +シリアライズされたJSONやYAMLの機密データはBase64エンコードされています。 +文字列の中の改行は不正で、含まれていてはなりません。 +Darwin/macOSの`base64`ユーティリティーを使うときは、長い行を分割する`-b`オプションを指定するのは避けるべきです。 +反対に、Linuxユーザーは`base64`コマンドに`-w 0`オプションを指定するか、`-w`オプションが使えない場合は`base64 | tr -d '\n'`のようにパイプ*すべき*です。 +{{< /note >}} + +#### ジェネレーターからSecretを作成する + +Kubernetes v1.14から、`kubectl`は[Kustomizeを使ったオブジェクトの管理](/docs/tasks/manage-kubernetes-objects/kustomization/)に対応しています。 +KustomizeはSecretやConfigMapを生成するリソースジェネレーターを提供します。 +Kustomizeのジェネレーターはディレクトリの中の`kustomization.yaml`ファイルにて指定されるべきです。 +Secretが生成された後には、`kubectl apply`コマンドを使用してAPIサーバー上にSecretを作成することができます。 + +#### ファイルからのSecretの生成 + +./username.txtと./password.txtのファイルから生成するように`secretGenerator`を定義することで、Secretを生成することができます。 + +```shell +cat <<EOF >./kustomization.yaml +secretGenerator: +- name: db-user-pass + files: + - username.txt + - password.txt +EOF +``` + +Secretを生成するには、`kustomization.yaml`を含むディレクトリをapplyします。 + +```shell +kubectl apply -k . +``` + +出力は次のようになります。 + +``` +secret/db-user-pass-96mffmfh4k created +``` + +Secretが生成されたことを確認できます。 + +```shell +kubectl get secrets +``` + +出力は次のようになります。 + +``` +NAME TYPE DATA AGE +db-user-pass-96mffmfh4k Opaque 2 51s +``` + +```shell +kubectl describe secrets/db-user-pass-96mffmfh4k +``` + +出力は次のようになります。 + +``` +Name: db-user-pass +Namespace: default +Labels: <none> +Annotations: <none> + +Type: Opaque + +Data +==== +password.txt: 12 bytes +username.txt: 5 bytes +``` + +#### 文字列リテラルからのSecretの生成 + +リテラル`username=admin`と`password=secret`から生成するように`secretGenerator`を定義して、Secretを生成することができます。 + +```shell +cat <<EOF >./kustomization.yaml +secretGenerator: +- name: db-user-pass + literals: + - username=admin + - password=secret +EOF +``` + +Secretを生成するには、`kustomization.yaml`を含むディレクトリをapplyします。 + +```shell +kubectl apply -k . +``` + +出力は次のようになります。 + +``` +secret/db-user-pass-dddghtt9b5 created +``` + +{{< note >}} +Secretが生成されるとき、Secretのデータからハッシュ値が算出され、Secretの名称にハッシュ値が加えられます。 +これはデータが更新されたときに毎回新しいSecretが生成されることを保証します。 +{{< /note >}} + +#### Secretのデコード + +Secretは`kubectl get secret`を実行することで取得可能です。 +例えば、前のセクションで作成したSecretは次のコマンドを実行することで参照できます。 + +```shell +kubectl get secret mysecret -o yaml +``` + +出力は次のようになります。 + +```yaml +apiVersion: v1 +kind: Secret +metadata: + creationTimestamp: 2016-01-22T18:41:56Z + name: mysecret + namespace: default + resourceVersion: "164619" + uid: cfee02d6-c137-11e5-8d73-42010af00002 +type: Opaque +data: + username: YWRtaW4= + password: MWYyZDFlMmU2N2Rm +``` + +`password`フィールドをデコードします。 + +```shell +echo 'MWYyZDFlMmU2N2Rm' | base64 --decode +``` + +出力は次のようになります。 + +``` +1f2d1e2e67df +``` + +#### Secretの編集 + +既存のSecretは次のコマンドで編集することができます。 + +```shell +kubectl edit secrets mysecret +``` + +デフォルトに設定されたエディターが開かれ、`data`フィールドのBase64でエンコードされたSecretの値を編集することができます。 + +```yaml +# Please edit the object below. Lines beginning with a '#' will be ignored, +# and an empty file will abort the edit. If an error occurs while saving this file will be +# reopened with the relevant failures. +# +apiVersion: v1 +data: + username: YWRtaW4= + password: MWYyZDFlMmU2N2Rm +kind: Secret +metadata: + annotations: + kubectl.kubernetes.io/last-applied-configuration: { ... } + creationTimestamp: 2016-01-22T18:41:56Z + name: mysecret + namespace: default + resourceVersion: "164619" + uid: cfee02d6-c137-11e5-8d73-42010af00002 +type: Opaque +``` + +## Secretの使用 + +Podの中のコンテナがSecretを使うために、データボリュームとしてマウントしたり、{{< glossary_tooltip text="環境変数" term_id="container-env-variables" >}}として値を参照できるようにできます。 +Secretは直接Podが参照できるようにはされず、システムの別の部分に使われることもあります。 +例えば、Secretはあなたに代わってシステムの他の部分が外部のシステムとやりとりするために使う機密情報を保持することもあります。 + +### SecretをファイルとしてPodから利用する + +PodのボリュームとしてSecretを使うには、 + +1. Secretを作成するか既存のものを使用します。複数のPodが同一の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`以下のファイル名になります。 + +これはSecretをボリュームとしてマウントするPodの例です。 + +```yaml +apiVersion: v1 +kind: Pod +metadata: + name: mypod +spec: + containers: + - name: mypod + image: redis + volumeMounts: + - name: foo + mountPath: "/etc/foo" + readOnly: true + volumes: + - name: foo + secret: + secretName: mysecret +``` + +使用したいSecretはそれぞれ`.spec.volumes`の中で参照されている必要があります。 + +Podに複数のコンテナがある場合、それぞれのコンテナが`volumeMounts`ブロックを必要としますが、`.spec.volumes`はSecret1つあたり1つで十分です。 + +多くのファイルを一つのSecretにまとめることも、多くのSecretを使うことも、便利な方を採ることができます。 + +#### Secretのキーの特定のパスへの割り当て + +Secretのキーが割り当てられるパスを制御することができます。 +それぞれのキーがターゲットとするパスは`.spec.volumes[].secret.items`フィールドによって指定てきます。 + +```yaml +apiVersion: v1 +kind: Pod +metadata: + name: mypod +spec: + containers: + - name: mypod + image: redis + volumeMounts: + - name: foo + mountPath: "/etc/foo" + readOnly: true + volumes: + - name: foo + secret: + secretName: mysecret + items: + - key: username + path: my-group/my-username +``` + +次のような挙動をします。 + +* `username`は`/etc/foo/username`の代わりに`/etc/foo/my-group/my-username`の元に格納されます。 +* `password`は現れません。 + +`.spec.volumes[].secret.items`が使われるときは、`items`の中で指定されたキーのみが現れます。 +Secretの中の全てのキーを使用したい場合は、`items`フィールドに全て列挙する必要があります。 +列挙されたキーは対応するSecretに存在する必要があり、そうでなければボリュームは生成されません。 + +#### Secretファイルのパーミッション + +単一のSecretキーに対して、ファイルアクセスパーミッションビットを指定することができます。 +パーミッションを指定しない場合、デフォルトで`0644`が使われます。 +Secretボリューム全体のデフォルトモードを指定し、必要に応じてキー単位で上書きすることもできます。 + +例えば、次のようにしてデフォルトモードを指定できます。 + +```yaml +apiVersion: v1 +kind: Pod +metadata: + name: mypod +spec: + containers: + - name: mypod + image: redis + volumeMounts: + - name: foo + mountPath: "/etc/foo" + volumes: + - name: foo + secret: + secretName: mysecret + defaultMode: 0400 +``` + +Secretは`/etc/foo`にマウントされ、Secretボリュームが生成する全てのファイルはパーミッション`0400`に設定されます。 + +JSONの仕様は8進数の記述に対応していないため、パーミッション0400を示す値として256を使用することに注意が必要です。 +Podの定義にJSONではなくYAMLを使う場合は、パーミッションを指定するためにより自然な8進表記を使うことができます。 + +`kubectl exec`を使ってPodに入るときは、期待したファイルモードを知るためにシンボリックリンクを辿る必要があることに注意してください。 + +例として、PodのSecretのファイルモードを確認します。 +``` +kubectl exec mypod -it sh + +cd /etc/foo +ls -l +``` + +出力は次のようになります。 +``` +total 0 +lrwxrwxrwx 1 root root 15 May 18 00:18 password -> ..data/password +lrwxrwxrwx 1 root root 15 May 18 00:18 username -> ..data/username +``` + +正しいファイルモードを知るためにシンボリックリンクを辿ります。 + +``` +cd /etc/foo/..data +ls -l +``` + +出力は次のようになります。 +``` +total 8 +-r-------- 1 root root 12 May 18 00:18 password +-r-------- 1 root root 5 May 18 00:18 username +``` + +前の例のようにマッピングを使い、ファイルごとに異なるパーミッションを指定することができます。 + +```yaml +apiVersion: v1 +kind: Pod +metadata: + name: mypod +spec: + containers: + - name: mypod + image: redis + volumeMounts: + - name: foo + mountPath: "/etc/foo" + volumes: + - name: foo + secret: + secretName: mysecret + items: + - key: username + path: my-group/my-username + mode: 0777 +``` + +この例では、ファイル`/etc/foo/my-group/my-username`のパーミッションは`0777`になります。 +JSONを使う場合は、JSONの制約により10進表記の`511`と記述する必要があります。 + +後で参照する場合、このパーミッションの値は10進表記で表示されることがあることに注意してください。 + +#### Secretの値のボリュームによる利用 + +Secretのボリュームがマウントされたコンテナからは、Secretのキーはファイル名として、Secretの値はBase64デコードされ、それらのファイルに格納されます。 +上記の例のコンテナの中でコマンドを実行した結果を示します。 + +```shell +ls /etc/foo/ +``` + +出力は次のようになります。 + +``` +username +password +``` + +```shell +cat /etc/foo/username +``` + +出力は次のようになります。 + +``` +admin +``` + +```shell +cat /etc/foo/password +``` + +出力は次のようになります。 + +``` +1f2d1e2e67df +``` + +コンテナ内のプログラムはファイルからSecretの内容を読み取る責務を持ちます。 + +#### マウントされたSecretの自動更新 + +ボリュームとして使用されているSecretが更新されると、やがて割り当てられたキーも同様に更新されます。 +kubeletは定期的な同期のたびにマウントされたSecretが新しいかどうかを確認します。 +しかしながら、kubeletはSecretの現在の値の取得にローカルキャッシュを使用します。 +このキャッシュは[KubeletConfiguration struct](https://github.com/kubernetes/kubernetes/blob/{{< param "docsbranch" >}}/staging/src/k8s.io/kubelet/config/v1beta1/types.go)内の`ConfigMapAndSecretChangeDetectionStrategy`フィールドによって設定可能です。 +Secretはwatch（デフォルト）、TTLベース、単に全てのリクエストをAPIサーバーへリダイレクトすることのいずれかによって伝搬します。 +結果として、Secretが更新された時点からPodに新しいキーが反映されるまでの遅延時間の合計は、kubeletの同期間隔 + キャッシュの伝搬遅延となります。 +キャッシュの遅延は、キャッシュの種別により、それぞれwatchの伝搬遅延、キャッシュのTTL、0になります。 + +{{< note >}} +Secretを[subPath](/docs/concepts/storage/volumes#using-subpath)を指定してボリュームにマウントしているコンテナには、Secretの更新が反映されません。 +{{< /note >}} + +{{< feature-state for_k8s_version="v1.18" state="alpha" >}} + +Kubernetesのアルファ機能である _Immutable Secrets and ConfigMaps_ は各SecretやConfigMapが不変であると設定できるようにします。 +Secretを広範に利用しているクラスター（PodにマウントされているSecretが1万以上）においては、データが変更されないようにすることで次のような利点が得られます。 + +- 意図しない（または望まない）変更によってアプリケーションの停止を引き起こすことを防ぎます +- 不変であると設定されたSecretの監視を停止することにより、kube-apiserverの負荷が著しく軽減され、クラスターのパフォーマンスが改善されます + +この機能を利用するには、`ImmutableEphemeralVolumes`[feature gate](/ja/docs/reference/command-line-tools-reference/feature-gates/)を有効にして、SecretまたはConfigMapの`immutable`フィールドに`true`を指定します。例えば、次のようにします。 + +```yaml +apiVersion: v1 +kind: Secret +metadata: + ... +data: + ... +immutable: true +``` + +{{< note >}} +一度SecretやConfigMapを不変であると設定すると、この変更を戻すことや`data`フィールドの内容を書き換えることは _できません_ 。 +Secretを削除して、再生成することだけができます。 +既存のPodは削除されたSecretへのマウントポイントを持ち続けるため、Podを再生成することが推奨されます。 +{{< /note >}} + +### Secretを環境変数として使用する {#using-secrets-as-environment-variables} + +SecretをPodの{{< glossary_tooltip text="環境変数" term_id="container-env-variables" >}}として使用するには、 + +1. Secretを作成するか既存のものを使います。複数のPodが同一のSecretを参照することができます。 +1. Podの定義を変更し、Secretを使用したいコンテナごとにSecretのキーと割り当てたい環境変数を指定します。Secretキーを利用する環境変数は`env[].valueFrom.secretKeyRef`にSecretの名前とキーを指定すべきです。 +1. イメージまたはコマンドライン（もしくはその両方）を変更し、プログラムが指定した環境変数を参照するようにします。 + +Secretを環境変数で参照するPodの例を示します。 + +```yaml +apiVersion: v1 +kind: Pod +metadata: + name: secret-env-pod +spec: + containers: + - name: mycontainer + image: redis + env: + - name: SECRET_USERNAME + valueFrom: + secretKeyRef: + name: mysecret + key: username + - name: SECRET_PASSWORD + valueFrom: + secretKeyRef: + name: mysecret + key: password + restartPolicy: Never +``` + +#### 環境変数からのSecretの値の利用 + +Secretを環境変数として利用するコンテナの内部では、Secretのキーは一般の環境変数名として現れ、値はBase64デコードされた状態で保持されます。 + +上記の例のコンテナの内部でコマンドを実行した結果の例を示します。 + +```shell +echo $SECRET_USERNAME +``` + +出力は次のようになります。 + +``` +admin +``` + +```shell +echo $SECRET_PASSWORD +``` + +出力は次のようになります。 + +``` +1f2d1e2e67df +``` + +### imagePullSecretsを使用する {#using-imagepullsecrets} + +`imagePullSecrets`フィールドは同一のネームスペース内のSecretの参照のリストです。 +kubeletにDockerやその他のイメージレジストリのパスワードを渡すために、`imagePullSecrets`にそれを含むSecretを指定することができます。 +kubeletはこの情報をPodのためにプライベートイメージをpullするために使います。 +`imagePullSecrets`の詳細は[PodSpec API](/docs/reference/generated/kubernetes-api/{{< latest-version >}}/#podspec-v1-core)を参照してください。 + +#### imagePullSecretを手動で指定する + +`ImagePullSecrets`の指定の方法は[コンテナイメージのドキュメント](/docs/concepts/containers/images/#specifying-imagepullsecrets-on-a-pod)に記載されています。 + +### imagePullSecretsが自動的にアタッチされるようにする + +`imagePullSecrets`を手動で作成し、サービスアカウントから参照することができます。 +サービスアカウントが指定されるまたはデフォルトでサービスアカウントが設定されたPodは、サービスアカウントが持つ`imagePullSecrets`フィールドを得ます。 +詳細な手順の説明は[サービスアカウントへのImagePullSecretsの追加](/docs/tasks/configure-pod-container/configure-service-account/#add-imagepullsecrets-to-a-service-account)を参照してください。 + +### 手動で作成されたSecretの自動的なマウント + +手動で作成されたSecret（例えばGitHubアカウントへのアクセスに使うトークンを含む）はサービスアカウントを基に自動的にアタッチすることができます。 +詳細な説明は[PodPresetを使ったPodへの情報の注入](/docs/tasks/inject-data-application/podpreset/)を参照してください。 + +## 詳細 + +### 制限事項 + +Secretボリュームは指定されたオブジェクト参照が実際に存在するSecretオブジェクトを指していることを保証するため検証されます。 +そのため、Secretはそれを必要とするPodよりも先に作成する必要があります。 + +Secretリソースは{{< glossary_tooltip text="namespace" term_id="namespace" >}}に属します。 +Secretは同一のnamespaceに属するPodからのみ参照することができます。 + +各Secretは1MiBの容量制限があります。 +これはAPIサーバーやkubeletのメモリーを枯渇するような非常に大きなSecretを作成することを避けるためです。 +しかしながら、小さなSecretを多数作成することも同様にメモリーを枯渇させます。 +Secretに起因するメモリー使用量をより網羅的に制限することは、将来計画されています。 + +kubeletがPodに対してSecretを使用するとき、APIサーバーから取得されたSecretのみをサポートします。 +これには`kubectl`を利用して、またはレプリケーションコントローラーによって間接的に作成されたPodが含まれます。 +kubeletの`--manifest-url`フラグ、`--config`フラグ、またはREST APIにより生成されたPodは含まれません +（これらはPodを生成するための一般的な方法ではありません）。 + +環境変数として使われるSecretは任意と指定されていない限り、それを使用するPodよりも先に作成される必要があります。 +存在しないSecretへの参照はPodの起動を妨げます。 + +Secretに存在しないキーへの参照（`secretKeyRef`フィールド）はPodの起動を妨げます。 + +Secretを`envFrom`フィールドによって環境変数へ設定する場合、環境変数の名称として不適切なキーは飛ばされます。 +Podは起動することを認められます。 +このとき、reasonが`InvalidVariableNames`であるイベントが発生し、メッセージに飛ばされたキーのリストが含まれます。 +この例では、Podは2つの不適切なキー`1badkey`と`2alsobad`を含むdefault/mysecretを参照しています。 + +```shell +kubectl get events +``` + +出力は次のようになります。 + +``` +LASTSEEN FIRSTSEEN COUNT NAME KIND SUBOBJECT TYPE REASON +0s 0s 1 dapi-test-pod Pod Warning InvalidEnvironmentVariableNames kubelet, 127.0.0.1 Keys [1badkey, 2alsobad] from the EnvFrom secret default/mysecret were skipped since they are considered invalid environment variable names. +``` + +### SecretとPodの相互作用 + +Kubernetes APIがコールされてPodが生成されるとき、参照するSecretの存在は確認されません。 +Podがスケジューリングされると、kubeletはSecretの値を取得しようとします。 +Secretが存在しない、または一時的にAPIサーバーへの接続が途絶えたことにより取得できない場合、kubeletは定期的にリトライします。 +kubeletはPodがまだ起動できない理由に関するイベントを報告します。 +Secretが取得されると、kubeletはそのボリュームを作成しマウントします。 +Podのボリュームが全てマウントされるまでは、Podのコンテナは起動することはありません。 + +## ユースケース + +### ユースケース: コンテナの環境変数として + +Secretの作成 +```yaml +apiVersion: v1 +kind: Secret +metadata: + name: mysecret +type: Opaque +data: + USER_NAME: YWRtaW4= + PASSWORD: MWYyZDFlMmU2N2Rm +``` + +```shell +kubectl apply -f mysecret.yaml +``` + +`envFrom`を使ってSecretの全てのデータをコンテナの環境変数として定義します。 +SecretのキーはPod内の環境変数の名称になります。 + +```yaml +apiVersion: v1 +kind: Pod +metadata: + name: secret-test-pod +spec: + containers: + - name: test-container + image: k8s.gcr.io/busybox + command: [ "/bin/sh", "-c", "env" ] + envFrom: + - secretRef: + name: mysecret + restartPolicy: Never +``` + +### ユースケース: SSH鍵を持つPod + +SSH鍵を含むSecretを作成します。 + +```shell +kubectl create secret generic ssh-key-secret --from-file=ssh-privatekey=/path/to/.ssh/id_rsa --from-file=ssh-publickey=/path/to/.ssh/id_rsa.pub +``` + +出力は次のようになります。 + +``` +secret "ssh-key-secret" created +``` + +SSH鍵を含む`secretGenerator`フィールドを持つ`kustomization.yaml`を作成することもできます。 + +{{< caution >}} +自身のSSH鍵を送る前に慎重に検討してください。クラスターの他のユーザーがSecretにアクセスできる可能性があります。 +Kubernetesクラスターを共有しているユーザー全員がアクセスできるようにサービスアカウントを使用し、ユーザーが安全でない状態になったらアカウントを無効化することができます。 +{{< /caution >}} + +SSH鍵のSecretを参照し、ボリュームとして使用するPodを作成することができます。 + +```yaml +apiVersion: v1 +kind: Pod +metadata: + name: secret-test-pod + labels: + name: secret-test +spec: + volumes: + - name: secret-volume + secret: + secretName: ssh-key-secret + containers: + - name: ssh-test-container + image: mySshImage + volumeMounts: + - name: secret-volume + readOnly: true + mountPath: "/etc/secret-volume" +``` + +コンテナのコマンドを実行するときは、下記のパスにて鍵が利用可能です。 + +``` +/etc/secret-volume/ssh-publickey +/etc/secret-volume/ssh-privatekey +``` + +コンテナーはSecretのデータをSSH接続を確立するために使用することができます。 + +### ユースケース: 本番、テスト用の認証情報を持つPod + +あるPodは本番の認証情報のSecretを使用し、別のPodはテスト環境の認証情報のSecretを使用する例を示します。 + +`secretGenerator`フィールドを持つ`kustomization.yaml`を作成するか、`kubectl create secret`を実行します。 + +```shell +kubectl create secret generic prod-db-secret --from-literal=username=produser --from-literal=password=Y4nys7f11 +``` + +出力は次のようになります。 + +``` +secret "prod-db-secret" created +``` + +```shell +kubectl create secret generic test-db-secret --from-literal=username=testuser --from-literal=password=iluvtests +``` + +出力は次のようになります。 + +``` +secret "test-db-secret" created +``` + +{{< note >}} +`$`、`\`、`*`、`=`、`!`のような特殊文字は[シェル](https://ja.wikipedia.org/wiki/%E3%82%B7%E3%82%A7%E3%83%AB)に解釈されるので、エスケープする必要があります。 +ほとんどのシェルではパスワードをエスケープする最も簡単な方法はシングルクォート(`'`)で囲むことです。 +例えば、実際のパスワードが`S!B\*d$zDsb=`だとすると、実行すべきコマンドは下記のようになります。 + +```shell +kubectl create secret generic dev-db-secret --from-literal=username=devuser --from-literal=password='S!B\*d$zDsb=' +``` + +`--from-file`によってファイルを指定する場合は、そのパスワードに含まれる特殊文字をエスケープする必要はありません。 +{{< /note >}} + +Podを作成します。 + +```shell +cat <<EOF > pod.yaml +apiVersion: v1 +kind: List +items: +- kind: Pod + apiVersion: v1 + metadata: + name: prod-db-client-pod + labels: + name: prod-db-client + spec: + volumes: + - name: secret-volume + secret: + secretName: prod-db-secret + containers: + - name: db-client-container + image: myClientImage + volumeMounts: + - name: secret-volume + readOnly: true + mountPath: "/etc/secret-volume" +- kind: Pod + apiVersion: v1 + metadata: + name: test-db-client-pod + labels: + name: test-db-client + spec: + volumes: + - name: secret-volume + secret: + secretName: test-db-secret + containers: + - name: db-client-container + image: myClientImage + volumeMounts: + - name: secret-volume + readOnly: true + mountPath: "/etc/secret-volume" +EOF +``` + +同じkustomization.yamlにPodを追記します。 + +```shell +cat <<EOF >> kustomization.yaml +resources: +- pod.yaml +EOF +``` + +下記のコマンドを実行して、APIサーバーにこれらのオブジェクト群を適用します。 + +```shell +kubectl apply -k . +``` + +両方のコンテナはそれぞれのファイルシステムに下記に示すファイルを持ちます。ファイルの値はそれぞれのコンテナの環境ごとに異なります。 + +``` +/etc/secret-volume/username +/etc/secret-volume/password +``` + +2つのPodの仕様の差分は1つのフィールドのみである点に留意してください。 +これは共通のPodテンプレートから異なる能力を持つPodを作成することを容易にします。 + +2つのサービスアカウントを使用すると、ベースのPod仕様をさらに単純にすることができます。 + +1. `prod-user` と `prod-db-secret` +1. `test-user` と `test-db-secret` + +簡略化されたPod仕様は次のようになります。 + +```yaml +apiVersion: v1 +kind: Pod +metadata: + name: prod-db-client-pod + labels: + name: prod-db-client +spec: + serviceAccount: prod-db-client + containers: + - name: db-client-container + image: myClientImage +``` + +### ユースケース: Secretボリューム内のdotfile + +キーをドットから始めることで、データを「隠す」ことができます。 +このキーはdotfileまたは「隠し」ファイルを示します。例えば、次のSecretは`secret-volume`ボリュームにマウントされます。 + +```yaml +apiVersion: v1 +kind: Secret +metadata: + name: dotfile-secret +data: + .secret-file: dmFsdWUtMg0KDQo= +--- +apiVersion: v1 +kind: Pod +metadata: + name: secret-dotfiles-pod +spec: + volumes: + - name: secret-volume + secret: + secretName: dotfile-secret + containers: + - name: dotfile-test-container + image: k8s.gcr.io/busybox + command: + - ls + - "-l" + - "/etc/secret-volume" + volumeMounts: + - name: secret-volume + readOnly: true + mountPath: "/etc/secret-volume" +``` + +このボリュームは`.secret-file`という単一のファイルを含み、`dotfile-test-container`はこのファイルを`/etc/secret-volume/.secret-file`のパスに持ちます。 + +{{< note >}} +ドットから始まるファイルは`ls -l`の出力では隠されるため、ディレクトリの内容を参照するときには`ls -la`を使わなければなりません。 +{{< /note >}} + +### ユースケース: Podの中の単一コンテナのみが参照できるSecret + +HTTPリクエストを扱い、複雑なビジネスロジックを処理し、メッセージにHMACによる認証コードを付与する必要のあるプログラムを考えます。 +複雑なアプリケーションロジックを持つため、サーバーにリモートのファイルを読み出せる未知の脆弱性がある可能性があり、この脆弱性は攻撃者に秘密鍵を晒してしまいます。 + +このプログラムは2つのコンテナに含まれる2つのプロセスへと分割することができます。 +フロントエンドのコンテナはユーザーとのやりとりやビジネスロジックを扱い、秘密鍵を参照することはできません。 +署名コンテナは秘密鍵を参照することができて、単にフロントエンドからの署名リクエストに応答します。例えば、localhostの通信によって行います。 + +この分割する手法によって、攻撃者はアプリケーションサーバーを騙して任意の処理を実行させる必要があるため、ファイルの内容を読み出すより困難になります。 + +<!-- TODO: explain how to do this while still using automation. --> + +## ベストプラクティス + +### Secret APIを使用するクライアント + +Secret APIとやりとりするアプリケーションをデプロイするときには、[RBAC]( +/docs/reference/access-authn-authz/rbac/)のような[認可ポリシー]( +/docs/reference/access-authn-authz/authorization/)を使用して、アクセスを制限すべきです。 +Secretは様々な種類の重要な値を保持することが多く、サービスアカウントのトークンのようにKubernetes内部や、外部のシステムで昇格できるものも多くあります。個々のアプリケーションが、Secretの能力について推論することができたとしても、同じネームスペースの別のアプリケーションがその推定を覆すこともあります。 + +これらの理由により、ネームスペース内のSecretに対する`watch`や`list`リクエストはかなり強力な能力であり、避けるべきです。Secretのリストを取得することはクライアントにネームスペース内の全てのSecretの値を調べさせることを認めるからです。クラスター内の全てのSecretに対する`watch`、`list`権限は最も特権的な、システムレベルのコンポーネントに限って認めるべきです。 + +Secret APIへのアクセスが必要なアプリケーションは、必要なSecretに対する`get`リクエストを発行すべきです。管理者は全てのSecretに対するアクセスは制限しつつ、アプリケーションが必要とする[個々のインスタンスに対するアクセス許可](/docs/reference/access-authn-authz/rbac/#referring-to-resources)を与えることができます。 + +`get`リクエストの繰り返しに対するパフォーマンスを向上するために、クライアントはSecretを参照するリソースを設計し、それを`watch`して、参照が変更されたときにSecretを再度リクエストすることができます。加えて、個々のリソースを`watch`することのできる["bulk watch" API](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/api-machinery/bulk_watch.md)が提案されており、将来のKubernetesリリースにて利用可能になる可能性があります。 + +## セキュリティ特性 + +### 保護 + +Secretはそれを使用するPodとは独立に作成されるので、Podを作ったり、参照したり、編集したりするワークフローにおいてSecretが晒されるリスクは軽減されています。 +システムは、可能であればSecretの内容をディスクに書き込まないような、Secretについて追加の考慮も行っています。 + +Secretはノード上のPodが必要とした場合のみ送られます。 +kubeletはSecretがディスクストレージに書き込まれないよう、`tmpfs`に保存します。 +Secretを必要とするPodが削除されると、kubeletはSecretのローカルコピーも同様に削除します。 + +同一のノードにいくつかのPodに対する複数のSecretが存在することもあります。 +しかし、コンテナから参照できるのはPodが要求したSecretのみです。 +そのため、あるPodが他のPodのためのSecretにアクセスすることはできません。 + +Podに複数のコンテナが含まれることもあります。しかし、Podの各コンテナはコンテナ内からSecretを参照するために`volumeMounts`によってSecretボリュームを要求する必要があります。 +これは[Podレベルでのセキュリティ分離](#use-case-secret-visible-to-one-container-in-a-pod)を実装するのに便利です。 + +ほとんどのKubernetesディストリビューションにおいては、ユーザーとAPIサーバー間やAPIサーバーからkubelet間の通信はSSL/TLSで保護されています。 +そのような経路で伝送される場合、Secretは保護されています。 + +{{< feature-state for_k8s_version="v1.13" state="beta" >}} + + +[保存データの暗号化](/docs/tasks/administer-cluster/encrypt-data/)を有効にして、Secretが{{< glossary_tooltip term_id="etcd" >}}に平文で保存されないようにすることができます。 + +### リスク + + - APIサーバーでは、機密情報は{{< glossary_tooltip term_id="etcd" >}}に保存されます。 + そのため、 + - 管理者はクラスターデータの保存データの暗号化を有効にすべきです（v1.13以降が必要）。 + - 管理者はetcdへのアクセスを管理ユーザに限定すべきです。 + - 管理者はetcdで使用していたディスクを使用しなくなったときにはそれをワイプするか完全消去したくなるでしょう。 + - クラスターの中でetcdが動いている場合、管理者はetcdのピアツーピア通信がSSL/TLSを利用していることを確認すべきです。 + - Secretをマニフェストファイル（JSONまたはYAML）を介して設定する場合、それはBase64エンコードされた機密情報を含んでいるので、ファイルを共有したりソースリポジトリに入れることは秘密が侵害されることを意味します。Base64エンコーディングは暗号化手段では _なく_ 、平文と同様であると判断すべきです。 + - アプリケーションはボリュームからSecretの値を読み取った後も、その値を保護する必要があります。例えば意図せずログに出力する、信用できない相手に送信するようなことがないようにです。 + - Secretを利用するPodを作成できるユーザーはSecretの値を見ることができます。たとえAPIサーバーのポリシーがユーザーにSecretの読み取りを許可していなくても、ユーザーはSecretを晒すPodを実行することができます。 + - 現在、任意のノードでルート権限を持つ人は誰でも、kubeletに偽装することで _任意の_ SecretをAPIサーバーから読み取ることができます。 + 単一のノードのルート権限を不正に取得された場合の影響を抑えるため、実際に必要としているノードに対してのみSecretを送る機能が計画されています。 diff --git a/content/ja/docs/concepts/containers/container-lifecycle-hooks.md b/content/ja/docs/concepts/containers/container-lifecycle-hooks.md index e3e44ba7e0..13ad6f2578 100644 --- a/content/ja/docs/concepts/containers/container-lifecycle-hooks.md +++ b/content/ja/docs/concepts/containers/container-lifecycle-hooks.md @@ -30,7 +30,7 @@ Angularなどのコンポーネントライフサイクルフックを持つ多 `PreStop` -このフックは、liveness probeの失敗、プリエンプション、リソース競合などのAPI要求または管理イベントが原因でコンテナが終了する直前に呼び出されます。コンテナが既に終了状態または完了状態にある場合、preStopフックの呼び出しは失敗します。 +このフックは、liveness probeの失敗、プリエンプション、リソース競合などのAPI要求または管理イベントが原因でコンテナが終了する直前に呼び出されます。コンテナがすでに終了状態または完了状態にある場合、preStopフックの呼び出しは失敗します。 これはブロッキング、つまり同期的であるため、コンテナを削除するための呼び出しを送信する前に完了する必要があります。 ハンドラーにパラメーターは渡されません。 diff --git a/content/ja/docs/concepts/containers/runtime-class.md b/content/ja/docs/concepts/containers/runtime-class.md index 6ea1f1e4e1..bd6cc59c49 100644 --- a/content/ja/docs/concepts/containers/runtime-class.md +++ b/content/ja/docs/concepts/containers/runtime-class.md @@ -26,11 +26,10 @@ RuntimeClassはコンテナランタイムの設定を選択するための機 ### セットアップ -RuntimeClass機能のFeature Gateが有効になっていることを確認してください(デフォルトで有効です)。Feature Gateを有効にする方法については、[Feature -Gates](/docs/reference/command-line-tools-reference/feature-gates/)を参照してください。 -その`RuntimeClass`のFeature GateはApiServerとkubeletのどちらも有効になっていなければなりません。 +RuntimeClass機能のフィーチャーゲートが有効になっていることを確認してください(デフォルトで有効です)。フィーチャーゲートを有効にする方法については、[フィーチャーゲート](/ja/docs/reference/command-line-tools-reference/feature-gates/)を参照してください。 +その`RuntimeClass`のフィーチャーゲートはApiServerとkubeletのどちらも有効になっていなければなりません。 -1. ノード上でCRI実装を設定する。（ランタイムに依存） +1. ノード上でCRI実装を設定する。(ランタイムに依存) 2. 対応するRuntimeClassリソースを作成する。 #### 1. ノード上でCRI実装を設定する。 @@ -39,8 +38,8 @@ RuntimeClassを通じて利用可能な設定はContainer Runtime Interface (CRI ユーザーの環境のCRI実装の設定方法は、対応するドキュメント([下記](#cri-configuration))を参照ください。 {{< note >}} -RuntimeClassは現時点において、クラスター全体で同じ種類のNode設定であることを仮定しています。(これは全てのNodeがコンテナランタイムに関して同じ方法で構成されていることを意味します)。 -設定が異なるNodeに関しては、スケジューリング機能を通じてRuntimeClassとは独立して管理されなくてはなりません。([PodをNodeに割り当てる方法](/ja/docs/concepts/configuration/assign-pod-node/)を参照して下さい)。 +RuntimeClassは、クラスター全体で同じ種類のノード設定であることを仮定しています。(これは全てのノードがコンテナランタイムに関して同じ方法で構成されていることを意味します)。 +設定が異なるノードをサポートするには、[スケジューリング](#scheduling)を参照してください。 {{< /note >}} RuntimeClassの設定は、RuntimeClassによって参照される`ハンドラー`名を持ちます。そのハンドラーは正式なDNS-1123に準拠する形式のラベルでなくてはなりません(英数字 + `-`の文字で構成されます)。 @@ -60,6 +59,9 @@ metadata: handler: myconfiguration # 対応するCRI設定 ``` +RuntimeClassオブジェクトの名前は[DNSサブドメイン名](/ja/docs/concepts/overview/working-with-objects/names#dns-subdomain-names)に従う必要があります。 + + {{< note >}} RuntimeClassの書き込み操作(create/update/patch/delete)はクラスター管理者のみに制限されることを推奨します。 これはたいていデフォルトで有効となっています。さらなる詳細に関しては[Authorization @@ -94,7 +96,7 @@ CRIランタイムのセットアップに関するさらなる詳細は、[CRI Kubernetesのビルトインのdockershim CRIは、ランタイムハンドラーをサポートしていません。 -#### [containerd](https://containerd.io/) +#### {{< glossary_tooltip term_id="containerd" >}} ランタイムハンドラーは、`/etc/containerd/config.toml`にあるcontainerdの設定ファイルにより設定されます。 正しいハンドラーは、その`runtime`セクションで設定されます。 @@ -106,20 +108,49 @@ Kubernetesのビルトインのdockershim CRIは、ランタイムハンドラ containerdの設定に関する詳細なドキュメントは下記を参照してください。 https://github.com/containerd/cri/blob/master/docs/config.md -#### [cri-o](https://cri-o.io/) +#### {{< glossary_tooltip term_id="cri-o" >}} -ランタイムハンドラーは、`/etc/crio/crio.conf`にあるcri-oの設定ファイルにより設定されます。 +ランタイムハンドラーは、`/etc/crio/crio.conf`にあるCRI-Oの設定ファイルにより設定されます。 正しいハンドラーは[crio.runtime -table](https://github.com/kubernetes-sigs/cri-o/blob/master/docs/crio.conf.5.md#crioruntime-table)で設定されます。 +table](https://github.com/cri-o/cri-o/blob/master/docs/crio.conf.5.md#crioruntime-table)で設定されます。 ``` [crio.runtime.runtimes.${HANDLER_NAME}] runtime_path = "${PATH_TO_BINARY}" ``` -cri-oの設定に関する詳細なドキュメントは下記を参照してください。 -https://github.com/kubernetes-sigs/cri-o/blob/master/cmd/crio/config.go +CRI-Oの[設定に関するドキュメント][100]の詳細は下記を参照してください。 +[100]: https://raw.githubusercontent.com/cri-o/cri-o/9f11d1d/docs/crio.conf.5.md + +### スケジューリング {#scheduling} + +{{< feature-state for_k8s_version="v1.16" state="beta" >}} + +Kubernetes 1.16では、RuntimeClassは`scheduling`フィールドを使ったクラスター内での異なる設定をサポートしています。 +このフィールドによって、設定されたRuntimeClassをサポートするノードに対してPodがスケジュールされることを保証できます。 +スケジューリングをサポートするためにはRuntimeClass [アドミッションコントローラー][]を有効にしなければなりません。(1.16ではデフォルトです) + +特定のRuntimeClassをサポートしているノードへPodが配置されることを保証するために、各ノードは`runtimeclass.scheduling.nodeSelector`フィールドによって選択される共通のラベルを持つべきです。 +RuntimeClassのnodeSelectorはアドミッション機能によりPodのnodeSelectorに統合され、効率よくノードを選択します。 +もし設定が衝突した場合は、Pod作成は拒否されるでしょう。 + +もしサポートされているノードが他のRuntimeClassのPodが稼働しないようにtaint付与されていた場合、RuntimeClassに対して`tolerations`を付与することができます。 +`nodeSelector`と同様に、tolerationsはPodのtolerationsにアドミッション機能によって統合され、効率よく許容されたノードを選択します。 + +ノードの選択とtolerationsについての詳細は[ノード上へのPodのスケジューリング](/ja/docs/concepts/configuration/assign-pod-node/)を参照してください。 + +[アドミッションコントローラー]: /docs/reference/access-authn-authz/admission-controllers/ + +### Podオーバーヘッド + +{{< feature-state for_k8s_version="v1.16" state="alpha" >}} + +Kubernetes 1.16ではRuntimeClassは[`PodOverhead`](/docs/concepts/configuration/pod-overhead/)機能の一部である、Podが稼働する時に関連するオーバーヘッドを指定することをサポートしています。 +`PodOverhead`を使うためには、PodOverhead[フィーチャーゲート](/ja/docs/reference/command-line-tools-reference/feature-gates/)を有効にしなければなりません。(デフォルトではoffです) + +PodのオーバーヘッドはRuntimeClass内の`Overhead`フィールドによって定義されます。 +このフィールドを使用することで、RuntimeClassを使用して稼働するPodのオーバーヘッドを指定することができ、Kubernetes内部で使用されるオーバーヘッドを確保することができます。 ### RutimeClassをα版からβ版にアップグレードする @@ -140,3 +171,9 @@ RuntimeClassのβ版の機能は、下記の変更点を含みます。 - `runtimeHandler`の指定がないか、もしくは空文字の場合や、ハンドラー名に`.`文字列が使われている場合はα版のRuntimeClassにおいてもはや有効ではありません。正しい形式のハンドラー設定に変更しなくてはなりません(先ほど記載した内容を確認ください)。 +### 参考文献 + +- [RuntimeClassデザイン](https://github.com/kubernetes/enhancements/blob/master/keps/sig-node/runtime-class.md) +- [RuntimeClassスケジューリングデザイン](https://github.com/kubernetes/enhancements/blob/master/keps/sig-node/runtime-class-scheduling.md) +- [Podオーバーヘッド](/docs/concepts/configuration/pod-overhead/)のコンセプトを読む +- [PodOverhead機能デザイン](https://github.com/kubernetes/enhancements/blob/master/keps/sig-node/20190226-pod-overhead.md) diff --git a/content/ja/docs/concepts/extend-kubernetes/api-extension/custom-resources.md b/content/ja/docs/concepts/extend-kubernetes/api-extension/custom-resources.md index 41f96a20ce..c05b35cdbc 100644 --- a/content/ja/docs/concepts/extend-kubernetes/api-extension/custom-resources.md +++ b/content/ja/docs/concepts/extend-kubernetes/api-extension/custom-resources.md @@ -1,7 +1,7 @@ --- title: カスタムリソース content_type: concept -weight: 20 +weight: 10 --- <!-- overview --> @@ -24,7 +24,7 @@ weight: 20 カスタムリソースそれ自身は、単純に構造化データを格納、取り出す機能を提供します。カスタムリソースを *カスタムコントローラー* と組み合わせることで、カスタムリソースは真の _宣言的API_ を提供します。 -[宣言的API](/ja/docs/concepts/overview/working-with-objects/kubernetes-objects/#kubernetesオブジェクトを理解する)は、リソースのあるべき状態を _宣言_ または指定することを可能にし、Kubernetesオブジェクトの現在の状態を、あるべき状態に同期し続けるように動きます。 +[宣言的API](/ja/docs/concepts/overview/kubernetes-api/)は、リソースのあるべき状態を _宣言_ または指定することを可能にし、Kubernetesオブジェクトの現在の状態を、あるべき状態に同期し続けるように動きます。 コントローラーは、構造化データをユーザーが指定したあるべき状態と解釈し、その状態を管理し続けます。 稼働しているクラスターのライフサイクルとは無関係に、カスタムコントローラーをデプロイ、更新することが可能です。カスタムコントローラーはあらゆるリソースと連携できますが、カスタムリソースと組み合わせると特に効果を発揮します。[オペレーターパターン](https://coreos.com/blog/introducing-operators.html)は、カスタムリソースとカスタムコントローラーの組み合わせです。カスタムコントローラーにより、特定アプリケーションのドメイン知識を、Kubernetes APIの拡張に変換することができます。 @@ -67,7 +67,7 @@ APIが宣言的ではない兆候として、次のものがあります: - APIをオブジェクトとして簡単に表現できない - 停止している処理を処理ID、もしくは処理オブジェクトで表現することを選択している -## ConfigMapとカスタムリソースのどちらを使うべきか? +## ConfigMapとカスタムリソースのどちらを使うべきか？ 下記のいずれかに該当する場合は、ConfigMapを使ってください: @@ -99,7 +99,7 @@ Kubernetesは、クラスターへカスタムリソースを追加する2つの Kubernetesは、さまざまなユーザーのニーズを満たすためにこれら2つのオプションを提供しており、使いやすさや柔軟性が損なわれることはありません。 -アグリゲートAPIは、プロキシーとして機能するプライマリAPIサーバーの背後にある、下位のAPIServerです。このような配置は[APIアグリゲーション](/ja/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation/) (AA)と呼ばれています。ユーザーにとっては、単にAPIサーバーが拡張されているように見えます。 +アグリゲートAPIは、プロキシーとして機能するプライマリAPIサーバーの背後にある、下位のAPIServerです。このような配置は[APIアグリゲーション](/ja/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation/)(AA)と呼ばれています。ユーザーにとっては、単にAPIサーバーが拡張されているように見えます。 CRDでは、APIサーバーの追加なしに、ユーザーが新しい種類のリソースを作成できます。CRDを使うには、APIアグリゲーションを理解する必要はありません。 @@ -108,6 +108,7 @@ CRDでは、APIサーバーの追加なしに、ユーザーが新しい種類 ## CustomResourceDefinition [CustomResourceDefinition](/docs/tasks/access-kubernetes-api/custom-resources/custom-resource-definitions/)APIリソースは、カスタムリソースを定義します。CRDオブジェクトを定義することで、指定した名前、スキーマで新しいカスタムリソースが作成されます。Kubernetes APIは、作成したカスタムリソースのストレージを提供、および処理します。 +CRDオブジェクトの名前は[DNSサブドメイン名](/ja/docs/concepts/overview/working-with-objects/names/#dns-subdomain-names)に従わなければなりません。 これはカスタムリソースを処理するために、独自のAPIサーバーを書くことから解放してくれますが、一般的な性質として[APIサーバーアグリゲーション](#APIサーバーアグリゲーション)と比べると、柔軟性に欠けます。 @@ -115,7 +116,7 @@ CRDでは、APIサーバーの追加なしに、ユーザーが新しい種類 ## APIサーバーアグリゲーション -通常、Kubernetes APIの各リソースは、RESTリクエストとオブジェクトの永続的なストレージを管理するためのコードが必要です。メインのKubernetes APIサーバーは *Pod* や *Service* のようなビルトインのリソースを処理し、また[CRD](#customresourcedefinition)を通じて、同じ方法でカスタムリソースも管理できます。 +通常、Kubernetes APIの各リソースは、RESTリクエストとオブジェクトの永続的なストレージを管理するためのコードが必要です。メインのKubernetes APIサーバーは *Pod* や *Service* のようなビルトインのリソースを処理し、またカスタムリソースも[CRD](#customresourcedefinition)を通じて同じように管理することができます。 [アグリゲーションレイヤー](/ja/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation/)は、独自のスタンドアローンAPIサーバーを書き、デプロイすることで、カスタムリソースに特化した実装の提供を可能にします。メインのAPIサーバーが、処理したいカスタムリソースへのリクエストを委譲することで、他のクライアントからも利用できるようにします。 @@ -134,7 +135,7 @@ CRDは、アグリゲートAPIと比べ、簡単に作れます。 | CRD | アグリゲートAPI | | -------------------------- | --------------- | -| プログラミングが不要で、ユーザーはCRDコントローラーとしてどの言語でも選択可能 | Go言語でプログラミングし、バイナリとイメージの作成が必要。ユーザーはCRDコントローラーとしてどの言語でも選択可能 | +| プログラミングが不要で、ユーザーはCRDコントローラーとしてどの言語でも選択可能 | Go言語でプログラミングし、バイナリとイメージの作成が必要 | | 追加のサービスは不要。カスタムリソースはAPIサーバーで処理される | 追加のサービス作成が必要で、障害が発生する可能性がある | | CRDが作成されると、継続的なサポートは無い。バグ修正は通常のKubernetesマスターのアップグレードで行われる | 定期的にアップストリームからバグ修正の取り込み、リビルド、そしてアグリゲートAPIサーバーの更新が必要かもしれない | | 複数バージョンのAPI管理は不要。例えば、あるリソースを操作するクライアントを管理していた場合、APIのアップグレードと一緒に更新される | 複数バージョンのAPIを管理しなければならない。例えば、世界中に共有されている拡張機能を開発している場合 | @@ -146,16 +147,16 @@ CRDは、アグリゲートAPIと比べ、簡単に作れます。 | 機能 | 詳細 | CRD | アグリゲートAPI | | ---- | ---- | --- | --------------- | | バリデーション | エラーを予防し、クライアントと無関係にAPIを発達させることができるようになる。これらの機能は多数のクライアントがおり、同時に全てを更新できないときに最も効果を発揮する | はい、ほとんどのバリデーションは[OpenAPI v3.0 validation](/docs/tasks/access-kubernetes-api/extend-api-custom-resource-definitions/#validation)で、CRDに指定できる。その他のバリデーションは[Webhookのバリデーション](/docs/reference/access-authn-authz/admission-controllers/#validatingadmissionwebhook-alpha-in-1-8-beta-in-1-9)によりサポートされている | はい、任意のバリデーションが可能 | -| デフォルト設定 | 上記を参照 | はい、[OpenAPI v3.0 validation](/docs/tasks/access-kubernetes-api/extend-api-custom-resource-definitions/#defaulting)の`default`キーワード(1.16でベータ)、または[Mutating Webhook](/docs/reference/access-authn-authz/admission-controllers/#mutatingadmissionwebhook-beta-in-1-9)を通じて可能 | はい | +| デフォルト設定 | 上記を参照 | はい、[OpenAPI v3.0 validation](/docs/tasks/access-kubernetes-api/extend-api-custom-resource-definitions/#defaulting)の`default`キーワード(1.17でGA)、または[Mutating Webhook](/docs/reference/access-authn-authz/admission-controllers/#mutatingadmissionwebhook)を通じて可能 (ただし、この方法は古いオブジェクトをetcdから読み込む場合には動きません) | はい | | 複数バージョニング | 同じオブジェクトを、違うAPIバージョンで利用可能にする。フィールドの名前を変更するなどのAPIの変更を簡単に行うのに役立つ。クライアントのバージョンを管理する場合、重要性は下がる | [はい](/docs/tasks/access-kubernetes-api/custom-resources/custom-resource-definition-versioning) | はい | | カスタムストレージ | 異なる性能のストレージが必要な場合(例えば、キーバリューストアの代わりに時系列データベース)または、セキュリティの分離(例えば、機密情報の暗号化、その他)| いいえ | はい | | カスタムビジネスロジック | オブジェクトが作成、読み込み、更新、また削除されるときに任意のチェック、アクションを実行する| はい、[Webhooks](/docs/reference/access-authn-authz/extensible-admission-controllers/#admission-webhooks)を利用 | はい | | サブリソースのスケール | HorizontalPodAutoscalerやPodDisruptionBudgetなどのシステムが、新しいリソースと連携できるようにする | [はい](/docs/tasks/access-kubernetes-api/extend-api-custom-resource-definitions/#scale-subresource) | はい | -| サブリソースの状態 | <ul><li>より詳細なアクセスコントロール: ユーザーがspecセクションに書き込み、コントローラーがstatusセクションに書き込む</li><li>カスタムリソースのデータ変換時にオブジェクトの世代を上げられるようにする(リソースがspecと、statusでセクションが分離している必要がある)</li></ul> | [はい](/docs/tasks/access-kubernetes-api/extend-api-custom-resource-definitions/#status-subresource) | はい | +| サブリソースの状態 | ユーザーがspecセクションに書き込み、コントローラーがstatusセクションに書き込む際に、より詳細なアクセスコントロールができるようにする。カスタムリソースのデータ変換時にオブジェクトの世代を上げられるようにする(リソース内のspecとstatusでセクションが分離している必要がある) | [はい](/docs/tasks/access-kubernetes-api/extend-api-custom-resource-definitions/#status-subresource) | はい | | その他のサブリソース | "logs"や"exec"のような、CRUD以外の処理の追加 | いいえ | はい | | strategic-merge-patch |`Content-Type: application/strategic-merge-patch+json`で、PATCHをサポートする新しいエンドポイント。ローカル、サーバー、どちらでも更新されうるオブジェクトに有用。さらなる情報は["APIオブジェクトをkubectl patchで決まった場所で更新"](/docs/tasks/run-application/update-api-object-kubectl-patch/)を参照 | いいえ | はい | | プロトコルバッファ | プロトコルバッファを使用するクライアントをサポートする新しいリソース | いいえ | はい | -| OpenAPIスキーマ | サーバーから動的に取得できる型のOpenAPI(スワッガー)スキーマはあるか、許可されたフィールドのみが設定されるようにすることで、ユーザーはフィールド名のスペルミスから保護されているか、型は強制されているか(言い換えると、「文字列」フィールドに「int」を入れさせない) | はい、[OpenAPI v3.0 validation](/docs/tasks/access-kubernetes-api/extend-api-custom-resource-definitions/#validation) スキーマがベース(1.16でGA) | はい | +| OpenAPIスキーマ | サーバーから動的に取得できる型のOpenAPI(Swagger)スキーマはあるか、許可されたフィールドのみが設定されるようにすることで、ユーザーはフィールド名のスペルミスから保護されているか、型は強制されているか(言い換えると、「文字列」フィールドに「int」を入れさせない) | はい、[OpenAPI v3.0 validation](/docs/tasks/access-kubernetes-api/extend-api-custom-resource-definitions/#validation) スキーマがベース(1.16でGA) | はい | ### 一般的な機能 @@ -174,7 +175,7 @@ CRD、またはアグリゲートAPI、どちらを使ってカスタムリソ | ファイナライザー | 外部リソースの削除が終わるまで、拡張リソースの削除をブロック | | Admission Webhooks | 拡張リソースの作成/更新/削除処理時に、デフォルト値の設定、バリデーションを実施 | | UI/CLI 表示 | kubectl、ダッシュボードで拡張リソースを表示 | -| 未設定 vs 空設定 | クライアントは、フィールドの未設定とゼロ値を区別することができる | +| 未設定 対 空設定 | クライアントは、フィールドの未設定とゼロ値を区別することができる | | クライアントライブラリーの生成 | Kubernetesは、一般的なクライアントライブラリーと、タイプ固有のクライアントライブラリーを生成するツールを提供 | | ラベルとアノテーション | ツールがコアリソースとカスタムリソースの編集方法を知っているオブジェクト間で、共通のメタデータを提供 | @@ -184,7 +185,7 @@ CRD、またはアグリゲートAPI、どちらを使ってカスタムリソ ### サードパーティのコードと新しい障害点 -CRDを作成しても、勝手に新しい障害点が追加されてしまうことはありませんが（たとえば、サードパーティのコードをAPIサーバーで実行することによって）、パッケージ（たとえば、チャート）またはその他のインストールバンドルには、多くの場合、CRDと新しいカスタムリソースのビジネスロジックを実装するサードパーティコードが入ったDeploymentが含まれます。 +CRDを作成しても、勝手に新しい障害点が追加されてしまうことはありませんが(たとえば、サードパーティのコードをAPIサーバーで実行することによって)、パッケージ(たとえば、Chart)またはその他のインストールバンドルには、多くの場合、CRDと新しいカスタムリソースのビジネスロジックを実装するサードパーティコードが入ったDeploymentが含まれます。 アグリゲートAPIサーバーのインストールすると、常に新しいDeploymentが付いてきます。 @@ -220,5 +221,3 @@ Kubernetesの[クライアントライブラリー](/docs/reference/using-api/cl * [Kubernetes APIをアグリゲーションレイヤーで拡張する方法](/ja/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation/)について学ぶ * [Kubernetes APIをCustomResourceDefinitionで拡張する方法](/docs/tasks/access-kubernetes-api/custom-resources/custom-resource-definitions/)について学ぶ - - diff --git a/content/ja/docs/concepts/extend-kubernetes/extend-cluster.md b/content/ja/docs/concepts/extend-kubernetes/extend-cluster.md index dad9190345..a1a1af7c6b 100644 --- a/content/ja/docs/concepts/extend-kubernetes/extend-cluster.md +++ b/content/ja/docs/concepts/extend-kubernetes/extend-cluster.md @@ -32,7 +32,7 @@ Kubernetesは柔軟な設定が可能で、高い拡張性を持っています ホスティングされたKubernetesサービスやマネージドなKubernetesでは、フラグと設定ファイルが常に変更できるとは限りません。変更可能な場合でも、通常はクラスターの管理者のみが変更できます。また、それらは将来のKubernetesバージョンで変更される可能性があり、設定変更にはプロセスの再起動が必要になるかもしれません。これらの理由により、この方法は他の選択肢が無いときにのみ利用するべきです。 -[ResourceQuota](/docs/concepts/policy/resource-quotas/)、[PodSecurityPolicy](/docs/concepts/policy/pod-security-policy/)、[NetworkPolicy](/docs/concepts/services-networking/network-policies/)、そしてロールベースアクセス制御([RBAC](/docs/reference/access-authn-authz/rbac/))といった *ビルトインポリシーAPI* は、ビルトインのKubernetes APIです。APIは通常、ホスティングされたKubernetesサービスやマネージドなKubernetesで利用されます。これらは宣言的で、Podのような他のKubernetesリソースと同じ慣例に従っています。そのため、新しいクラスターの設定は繰り返し再利用することができ、アプリケーションと同じように管理することが可能です。更に、安定版（stable）を利用している場合、他のKubernetes APIのような[定義済みのサポートポリシー](/docs/reference/deprecation-policy/)を利用することができます。これらの理由により、この方法は、適切な用途の場合、 *設定ファイル* や *フラグ* よりも好まれます。 +[ResourceQuota](/docs/concepts/policy/resource-quotas/)、[PodSecurityPolicy](/docs/concepts/policy/pod-security-policy/)、[NetworkPolicy](/docs/concepts/services-networking/network-policies/)、そしてロールベースアクセス制御([RBAC](/docs/reference/access-authn-authz/rbac/))といった *ビルトインポリシーAPI* は、ビルトインのKubernetes APIです。APIは通常、ホスティングされたKubernetesサービスやマネージドなKubernetesで利用されます。これらは宣言的で、Podのような他のKubernetesリソースと同じ慣例に従っています。そのため、新しいクラスターの設定は繰り返し再利用することができ、アプリケーションと同じように管理することが可能です。さらに、安定版(stable)を利用している場合、他のKubernetes APIのような[定義済みのサポートポリシー](/docs/reference/deprecation-policy/)を利用することができます。これらの理由により、この方法は、適切な用途の場合、 *設定ファイル* や *フラグ* よりも好まれます。 ## エクステンション @@ -42,7 +42,7 @@ Kubernetesは柔軟な設定が可能で、高い拡張性を持っています ほとんどのクラスター管理者は、ホスティングされている、またはディストリビューションとしてのKubernetesを使っているでしょう。 結果として、ほとんどのKubernetesユーザーは既存のエクステンションを使えばよいため、新しいエクステンションを書く必要は無いと言えます。 -## エクステンションパターン +## エクステンションパターン {#extension-patterns} Kubernetesは、クライアントのプログラムを書くことで自動化ができるようにデザインされています。 Kubernetes APIに読み書きをするどのようなプログラムも、役に立つ自動化機能を提供することができます。 @@ -57,8 +57,8 @@ Kubernetes上でうまく動くクライアントプログラムを書くため 呼び出されるサービスは *Webhookバックエンド* と呼ばれます。コントローラーのように、Webhookも障害点を追加します。 Webhookのモデルでは、Kubernetesは外部のサービスを呼び出します。 -*バイナリプラグイン* モデルでは、Kubernetesはバイナリ（プログラム）を実行します。 -バイナリプラグインはkubelet（例、[FlexVolumeプラグイン](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-storage/flexvolume.md)、[ネットワークプラグイン](/docs/concepts/cluster-administration/network-plugins/)）、またkubectlで利用されています。 +*バイナリプラグイン* モデルでは、Kubernetesはバイナリ(プログラム)を実行します。 +バイナリプラグインはkubelet(例、[FlexVolumeプラグイン](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-storage/flexvolume.md)、[ネットワークプラグイン](/docs/concepts/cluster-administration/network-plugins/))、またkubectlで利用されています。 下図は、それぞれの拡張ポイントが、Kubernetesのコントロールプレーンとどのように関わっているかを示しています。 @@ -103,7 +103,7 @@ Webhookのモデルでは、Kubernetesは外部のサービスを呼び出しま ### ビルトインリソースの変更 -カスタムリソースを追加し、KubernetesAPIを拡張する場合、新たに追加されたリソースは常に新しいAPIグループに分類されます。既存のAPIグループを置き換えたり、変更することはできません。APIを追加することは直接、既存のAPI（例、Pod）の振る舞いに影響を与えることは無いですが、APIアクセスエクステンションの場合、その可能性があります。 +カスタムリソースを追加し、KubernetesAPIを拡張する場合、新たに追加されたリソースは常に新しいAPIグループに分類されます。既存のAPIグループを置き換えたり、変更することはできません。APIを追加することは直接、既存のAPI(例、Pod)の振る舞いに影響を与えることは無いですが、APIアクセスエクステンションの場合、その可能性があります。 ### APIアクセスエクステンション @@ -111,7 +111,7 @@ Webhookのモデルでは、Kubernetesは外部のサービスを呼び出しま これらの各ステップごとに拡張ポイントが用意されています。 -Kubdernetesはいくつかのビルトイン認証方式をサポートしています。それは認証プロキシの後ろに配置することも可能で、認可ヘッダーを通じて（Webhookの）検証のために外部サービスにトークンを送ることもできます。全てのこれらの方法は[認証ドキュメント](/docs/reference/access-authn-authz/authentication/)でカバーされています。 +Kubdernetesはいくつかのビルトイン認証方式をサポートしています。それは認証プロキシの後ろに配置することも可能で、認可ヘッダーを通じて(Webhookの)検証のために外部サービスにトークンを送ることもできます。全てのこれらの方法は[認証ドキュメント](/docs/reference/access-authn-authz/authentication/)でカバーされています。 ### 認証 @@ -138,7 +138,7 @@ Kubernetesはいくつかのビルトイン認証方式と、それらが要件 ### デバイスプラグイン -[デバイスプラグイン](/docs/concepts/cluster-administration/device-plugins/)を通じて、ノードが新たなノードのリソース（CPU、メモリなどのビルトインのものに加え）を見つけることを可能にします。 +[デバイスプラグイン](/docs/concepts/cluster-administration/device-plugins/)を通じて、ノードが新たなノードのリソース(CPU、メモリなどのビルトインのものに加え)を見つけることを可能にします。 ### ネットワークプラグイン @@ -150,7 +150,7 @@ Kubernetesはいくつかのビルトイン認証方式と、それらが要件 これはかなりの大きな作業で、ほとんど全てのKubernetesユーザーはスケジューラーを変更する必要はありません。 -スケジューラは[Webhook](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/scheduling/scheduler_extender.md)もサポートしており、Webhookバックエンド（スケジューラーエクステンション）を通じてPodを配置するために選択されたノードをフィルタリング、優先度付けすることが可能です。 +スケジューラは[Webhook](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/scheduling/scheduler_extender.md)もサポートしており、Webhookバックエンド(スケジューラーエクステンション)を通じてPodを配置するために選択されたノードをフィルタリング、優先度付けすることが可能です。 diff --git a/content/ja/docs/concepts/extend-kubernetes/operator.md b/content/ja/docs/concepts/extend-kubernetes/operator.md index 0448510a4f..507463359d 100644 --- a/content/ja/docs/concepts/extend-kubernetes/operator.md +++ b/content/ja/docs/concepts/extend-kubernetes/operator.md @@ -24,7 +24,7 @@ Kubernetes上でワークロードを稼働させている人は、しばしば ## Kubernetesにおけるオペレーター Kubernetesは自動化のために設計されています。追加の作業、設定無しに、Kubernetesのコア機能によって多数のビルトインされた自動化機能が提供されます。 -ワークロードのデプロイ及び稼働を自動化するためにKubernetesを使うことができます。 *更に* Kubernetesがそれをどのように行うかの自動化も可能です。 +ワークロードのデプロイおよび稼働を自動化するためにKubernetesを使うことができます。 *さらに* Kubernetesがそれをどのように行うかの自動化も可能です。 Kubernetesの{{< glossary_tooltip text="コントローラー" term_id="controller" >}}コンセプトは、Kubernetesのソースコードを修正すること無く、クラスターの振る舞いを拡張することを可能にします。 オペレーターはKubernetes APIのクライアントで、[Custom Resource](/docs/concepts/api-extension/custom-resources/)にとっての、コントローラーのように振る舞います。 diff --git a/content/ja/docs/concepts/overview/components.md b/content/ja/docs/concepts/overview/components.md index 43e839d19c..a70f3d2e97 100644 --- a/content/ja/docs/concepts/overview/components.md +++ b/content/ja/docs/concepts/overview/components.md @@ -67,7 +67,7 @@ cloud-controller-managerを使用すると、クラウドベンダーのコー * サービスコントローラー：クラウドプロバイダーのロードバランサーの作成、更新、削除を行います。 * ボリュームコントローラー：ボリュームを作成、アタッチ、マウントしたり、クラウドプロバイダーとやり取りしてボリュームを調整したりします。 -## ノードコンポーネント +## ノードコンポーネント {#node-components} ノードコンポーネントはすべてのノードで実行され、稼働中のPodの管理やKubernetesの実行環境を提供します。 @@ -116,6 +116,6 @@ Kubernetesによって開始されたコンテナは、DNS検索にこのDNSサ * [ノード](/ja/docs/concepts/architecture/nodes/)について学ぶ * [コントローラー](/docs/concepts/architecture/controller/)について学ぶ -* [kube-scheduler](/ja/docs/concepts/scheduling/kube-scheduler/)について学ぶ +* [kube-scheduler](/ja/docs/concepts/scheduling-eviction/kube-scheduler/)について学ぶ * etcdの公式 [ドキュメント](https://etcd.io/docs/)を読む diff --git a/content/ja/docs/concepts/overview/kubernetes-api.md b/content/ja/docs/concepts/overview/kubernetes-api.md index 4e21db1633..5d95929bef 100644 --- a/content/ja/docs/concepts/overview/kubernetes-api.md +++ b/content/ja/docs/concepts/overview/kubernetes-api.md @@ -3,7 +3,7 @@ reviewers: title: Kubernetes API content_type: concept weight: 30 -card: +card: name: concepts weight: 30 --- @@ -16,7 +16,7 @@ APIエンドポイント、リソースタイプ、そしてサンプルは[API APIへの外部からのアクセスは、[APIアクセス制御ドキュメント](/docs/reference/access-authn-authz/controlling-access/)に記載されています。 -Kubernetes APIは、システムの宣言的設定スキーマの基礎としても機能します。[kubectl](/docs/reference/kubectl/overview/)コマンドラインツールから、APIオブジェクトを作成、更新、削除、取得することが出来ます。 +Kubernetes APIは、システムの宣言的設定スキーマの基礎としても機能します。[kubectl](/docs/reference/kubectl/overview/)コマンドラインツールから、APIオブジェクトを作成、更新、削除、取得することができます。 また、Kubernetesは、シリアライズされた状態を(現在は[etcd](https://coreos.com/docs/distributed-configuration/getting-started-with-etcd/)に)APIリソースの単位で保存しています。 @@ -30,7 +30,7 @@ Kubernetesそれ自身は複数のコンポーネントから構成されてお 我々の経験上、成功を収めているどのようなシステムも、新しいユースケースへの対応、既存の変更に合わせ、成長し変わっていく必要があります。したがって、Kubernetesにも継続的に変化、成長することを期待しています。一方で、長期間にわたり、既存のクライアントとの互換性を損なわないようにする予定です。一般的に、新しいAPIリソースとリソースフィールドは頻繁に追加されることが予想されます。リソース、フィールドの削除は、[API廃止ポリシー](/docs/reference/using-api/deprecation-policy/)への準拠を必要とします。 -何が互換性のある変更を意味するか、またAPIをどのように変更するかは、[API変更ドキュメント](https://git.k8s.io/community/contributors/devel/api_changes.md)に詳解されています。 +何が互換性のある変更を意味するか、またAPIをどのように変更するかは、[API変更ドキュメント](https://git.k8s.io/community/contributors/devel/sig-architecture/api_changes.md)に詳解されています。 ## OpenAPIとSwaggerの定義 @@ -41,10 +41,10 @@ Kubernetes 1.10から、KubernetesAPIサーバーは`/openapi/v2`のエンドポ ヘッダ | 設定可能な値 ------ | --------------- -Accept | `application/json`, `application/com.github.proto-openapi.spec.v2@v1.0+protobuf` （デフォルトのcontent-typeは、`*/*`に対して`application/json`か、もしくはこのヘッダーを送信しません） -Accept-Encoding | `gzip` （このヘッダーを送信しないことも許容されています） +Accept | `application/json`, `application/com.github.proto-openapi.spec.v2@v1.0+protobuf` (デフォルトのcontent-typeは、`*/*`に対して`application/json`か、もしくはこのヘッダーを送信しません) +Accept-Encoding | `gzip` (このヘッダーを送信しないことも許容されています) -1.14より前のバージョンでは、フォーマット分離エンドポイント（`/swagger.json`, `/swagger-2.0.0.json`, `/swagger-2.0.0.pb-v1`, `/swagger-2.0.0.pb-v1.gz`）が、OpenAPI仕様を違うフォーマットで提供しています。これらのエンドポイントは非推奨となっており、Kubernetes1.14で削除される予定です。 +1.14より前のバージョンでは、フォーマット分離エンドポイント(`/swagger.json`, `/swagger-2.0.0.json`, `/swagger-2.0.0.pb-v1`, `/swagger-2.0.0.pb-v1.gz`)が、OpenAPI仕様を違うフォーマットで提供しています。これらのエンドポイントは非推奨となっており、Kubernetes1.14で削除されました。 **OpenAPI仕様の取得サンプル**: @@ -57,7 +57,7 @@ GET /swagger-2.0.0.pb-v1.gz | GET /openapi/v2 **Accept**: application/com.github Kubernetesは、他の手段として主にクラスター間の連携用途向けのAPIに、Protocol buffersをベースにしたシリアライズフォーマットを実装しており、そのフォーマットの概要は[デザイン提案](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/api-machinery/protobuf.md)に記載されています。また各スキーマのIDFファイルは、APIオブジェクトを定義しているGoパッケージ内に配置されています。 また、1.14より前のバージョンのKubernetesAPIサーバーでは、[Swagger v1.2](http://swagger.io/)をベースにしたKubernetes仕様を、`/swaggerapi`で公開しています。 -このエンドポイントは非推奨となっており、Kubernetes1.14で削除される予定です。 +このエンドポイントは非推奨となっており、Kubernetes1.14で削除されました。 ## APIバージョニング @@ -67,16 +67,16 @@ APIが、システムリソースと動作について明確かつ一貫した APIとソフトウエアのバージョニングは、間接的にしか関連していないことに注意してください。[APIとリリースバージョニング提案](https://git.k8s.io/community/contributors/design-proposals/release/versioning.md)で、APIとソフトウェアのバージョニングの関連について記載しています。 -異なるバージョンのAPIは、異なるレベル（版）の安定性とサポートを持っています。それぞれのレベル（版）の基準は、[API変更ドキュメント](https://git.k8s.io/community/contributors/devel/sig-architecture/api_changes.md#alpha-beta-and-stable-versions)に詳細が記載されています。下記に簡潔にまとめます: +異なるバージョンのAPIでは、安定性やサポートのレベルも変わります。各レベルの詳細な条件は、[API変更ドキュメント](https://git.k8s.io/community/contributors/devel/sig-architecture/api_changes.md#alpha-beta-and-stable-versions)に記載されています。下記に簡潔にまとめます: -- アルファレベル（版）: - - バージョン名に`alpha`を含みます（例、`v1alpha1`）。 +- アルファレベル(版): + - バージョン名に`alpha`を含みます(例、`v1alpha1`)。 - バグが多いかもしれません。アルファ機能の有効化がバグを顕在化させるかもしれません。デフォルトでは無効となっています。 - アルファ機能のサポートは、いつでも通知無しに取りやめられる可能性があります。 - ソフトウェアリリース後、APIが通知無しに互換性が無い形で変更される可能性があります。 - バグが増えるリスク、また長期サポートが無いことから、短期間のテスト用クラスターでの利用を推奨します。 -- ベータレベル（版）: - - バージョン名に`beta`を含みます（例、`v2beta3`）。 +- ベータレベル(版): + - バージョン名に`beta`を含みます(例、`v2beta3`)。 - コードは十分にテストされています。ベータ機能の有効化は安全だと考えられます。デフォルトで有効化されています。 - 全体的な機能のサポートは取りやめられませんが、詳細は変更される可能性があります。 - オブジェクトのスキーマ、意味はその後のベータ、安定版リリースで互換性が無い形で変更される可能性があります。その場合、次のバージョンへアップデートするための手順を提供します。その手順ではAPIオブジェクトの削除、修正、再作成が必要になるかもしれません。修正のプロセスは多少の検討が必要になるかもしれません。これは、この機能を利用しているアプリケーションでダウンタイムが必要になる可能性があるためです。 @@ -93,24 +93,24 @@ APIグループは、RESTのパスとシリアライズされたオブジェク 現在、いくつかのAPIグループが利用されています: -1. *core* グループ（度々、*legacy group* と呼ばれます）は、`/api/v1`というRESTのパスで、`apiVersion: v1`を使います。 +1. *core* グループ(たびたび、*legacy group* と呼ばれます)は、`/api/v1`というRESTのパスで、`apiVersion: v1`を使います。 -1. 名前付きのグループは、`/apis/$GROUP_NAME/$VERSION`というRESTのパスで、`apiVersion: $GROUP_NAME/$VERSION`（例、`apiVersion: batch/v1`）を使います。サポートされているAPIグループの全リストは、[Kubernetes APIリファレンス](/docs/reference/)を参照してください。 +1. 名前付きのグループは、`/apis/$GROUP_NAME/$VERSION`というRESTのパスで、`apiVersion: $GROUP_NAME/$VERSION`(例、`apiVersion: batch/v1`)を使います。サポートされているAPIグループの全リストは、[Kubernetes APIリファレンス](/docs/reference/)を参照してください。 [カスタムリソース](/docs/concepts/api-extension/custom-resources/)でAPIを拡張するために、2つの方法がサポートされています: 1. [カスタムリソース定義](/docs/tasks/access-kubernetes-api/extend-api-custom-resource-definitions/)は、とても基本的なCRUDが必要なユーザー向けです。 1. 独自のAPIサーバーを実装可能な、フルセットのKubernetes APIが必要なユーザーは、[アグリゲーター](/docs/tasks/access-kubernetes-api/configure-aggregation-layer/)を使い、クライアントにシームレスな形で拡張を行います。 -## APIグループの有効化 +## APIグループの有効化、無効化 いくつかのリソースとAPIグループはデフォルトで有効になっています。それらは、APIサーバーの`--runtime-config`設定で、有効化、無効化できます。`--runtime-config`は、カンマ区切りの複数の値を設定可能です。例えば、batch/v1を無効化する場合、`--runtime-config=batch/v1=false`をセットし、batch/v2alpha1を有効化する場合、`--runtime-config=batch/v2alpha1`をセットします。このフラグは、APIサーバーのランタイム設定を表すkey=valueのペアを、カンマ区切りで指定したセットを指定可能です。 -重要: APIグループ、リソースの有効化、無効化は、`--runtime-config`の変更を反映するため、APIサーバーとコントローラーマネージャーの再起動が必要です。 +{{< note >}}APIグループ、リソースの有効化、無効化は、`--runtime-config`の変更を反映するため、APIサーバーとコントローラーマネージャーの再起動が必要です。{{< /note >}} -## APIグループのリソースの有効化 - -DaemonSets、Deployments、HorizontalPodAutoscalers、Ingresses、JobsReplicaSets、そしてReplicaSetsはデフォルトで有効です。 -その他の拡張リソースは、APIサーバーの`--runtime-config`を設定することで有効化できます。`--runtime-config`はカンマ区切りの複数の値を設定可能です。例えば、deploymentsとingressを無効化する場合、`--runtime-config=extensions/v1beta1/deployments=false,extensions/v1beta1/ingresses=false`と設定します。 +## APIグループextensions/v1beta1に含まれる特定のリソースの有効化 +APIグループ`extensions/v1beta1`に含まれるDaemonSets、Deployments、StatefulSet、NetworkPolicies、PodSecurityPolicies、ReplicaSetsはデフォルトで無効にされています。 +例えば、deploymentとdaemonsetを有効にするには、`--runtime-config=extensions/v1beta1/deployments=true,extensions/v1beta1/daemonsets=true`と設定します。 +{{< note >}}リソースを個別に有効化、無効化することは歴史的な理由によりAPIグループ`extensions/v1beta1`に含まれるリソースに限りサポートされています。{{< /note >}} diff --git a/content/ja/docs/concepts/overview/what-is-kubernetes.md b/content/ja/docs/concepts/overview/what-is-kubernetes.md index 1b90ef4a3f..5f2f4bbf18 100644 --- a/content/ja/docs/concepts/overview/what-is-kubernetes.md +++ b/content/ja/docs/concepts/overview/what-is-kubernetes.md @@ -1,8 +1,11 @@ --- +reviewers: title: Kubernetesとは何か？ +description: > + Kubernetesは、宣言的な構成管理と自動化を促進し、コンテナ化されたワークロードやサービスを管理するための、ポータブルで拡張性のあるオープンソースのプラットフォームです。Kubernetesは巨大で急速に成長しているエコシステムを備えており、それらのサービス、サポート、ツールは幅広い形で利用可能です。 content_type: concept weight: 10 -card: +card: name: concepts weight: 10 --- @@ -12,94 +15,76 @@ card: <!-- body --> -Kubernetesは、宣言的な構成管理と自動化を促進し、コンテナ化されたワークロードやサービスを管理するための、ポータブルで拡張性のあるオープンソースプラットホームです。 +Kubernetesは、宣言的な構成管理と自動化を促進し、コンテナ化されたワークロードやサービスを管理するための、ポータブルで拡張性のあるオープンソースのプラットフォームです。Kubernetesは巨大で急速に成長しているエコシステムを備えており、それらのサービス、サポート、ツールは幅広い形で利用可能です。 -Kubernetesは膨大で、急速に成長しているエコシステムを備えており、それらのサービス、サポート、ツールは幅広い形で利用可能です。 +Kubernetesの名称は、ギリシャ語に由来し、操舵手やパイロットを意味しています。Googleは2014年にKubernetesプロジェクトをオープンソース化しました。Kubernetesは、本番環境で大規模なワークロードを稼働させた[Googleの15年以上の経験](/blog/2015/04/borg-predecessor-to-kubernetes/)と、コミュニティからの最高のアイディアや実践を組み合わせています。 -Googleは2014年にKubernetesプロジェクトをオープンソース化しました。Kubernetesは[Googleが大規模な本番ワークロードを動かしてきた10年半の経験](https://research.google.com/pubs/pub43438.html)と、コミュニティから得られた最善のアイデア、知見に基づいています。 +## 過去を振り返ってみると -## なぜKubernetesが必要で、どんなことができるのか？ +過去を振り返って、Kubernetesがなぜこんなに便利なのかを見てみましょう。 -Kubernetesには多くの機能があります。考えられるものとしては +![Deployment evolution](/images/docs/Container_Evolution.svg) -- コンテナ基盤 -- マイクロサービス基盤 -- ポータブルなクラウド基盤 +**仮想化ができる前の時代におけるデプロイ (Traditional deployment):** 初期の頃は、組織は物理サーバー上にアプリケーションを実行させていました。物理サーバー上でアプリケーションのリソース制限を設定する方法がなかったため、リソースの割当問題が発生していました。例えば、複数のアプリケーションを実行させた場合、ひとつのアプリケーションがリソースの大半を消費してしまうと、他のアプリケーションのパフォーマンスが低下してしまうことがありました。この解決方法は、それぞれのアプリケーションを別々の物理サーバーで動かすことでした。しかし、リソースが十分に活用できなかったため、拡大しませんでした。また組織にとって多くの物理サーバーを維持することは費用がかかりました。 -など、他にもいろいろ +**仮想化を使ったデプロイ (Virtualized deployment):** ひとつの解決方法として、仮想化が導入されました。1台の物理サーバーのCPU上で、複数の仮想マシン(VM)を実行させることができるようになりました。仮想化によりアプリケーションをVM毎に隔離する事ができ、ひとつのアプリケーションの情報が他のアプリケーションから自由にアクセスさせないといったセキュリティレベルを提供することができます。 -Kubernetesは、**コンテナを中心とした**管理基盤です。ユーザーワークロードの代表格であるコンピューティング、ネットワーキング、ストレージインフラストラクチャのオーケストレーションを行います。それによって、Platform as a Service(PaaS)の簡単さの大部分を、Infrastructure as a Service(IaaS)の柔軟さとともに提供し、インフラストラクチャプロバイダの垣根を超えたポータビリティを実現します。 +仮想化により、物理サーバー内のリソース使用率が向上し、アプリケーションの追加や更新が容易になり、ハードウェアコストの削減などスケーラビリティが向上します。仮想化を利用すると、物理リソースのセットを使い捨て可能な仮想マシンのクラスターとして提示することができます。 -## Kubernetesが基盤になるってどういうこと？ +各VMは、仮想ハードウェア上で各自のOSを含んだ全コンポーネントを実行する完全なマシンです。 -Kubernetesが多くの機能を提供すると言いつつも、新しい機能から恩恵を受ける新しいシナリオは常にあります。アプリケーション固有のワークフローを効率化して開発者のスピードを早めることができます。最初は許容できるアドホックなオーケストレーションでも、大規模で堅牢な自動化が必要となることはしばしばあります。これが、Kubernetesがアプリケーションのデプロイ、拡張、および管理を容易にするために、コンポーネントとツールのエコシステムを構築するための基盤としても機能するように設計された理由です。 +**コンテナを使ったデプロイ (Container deployment):** コンテナはVMと似ていますが、アプリケーション間でオペレーティング・システム(OS)を共有できる緩和された分離特性を持っています。そのため、コンテナは軽量だといわれます。VMと同じように、コンテナは各自のファイルシステム、CPU、メモリー、プロセス空間等を持っています。基盤のインフラストラクチャから分離されているため、クラウドやOSディストリビューションを越えて移動することが可能です。 -[ラベル](/ja/docs/concepts/overview/working-with-objects/labels/)を使用すると、ユーザーは自分のリソースを整理できます。[アノテーション](/ja/docs/concepts/overview/working-with-objects/annotations/)を使用すると、ユーザーは自分のワークフローを容易にし、管理ツールが状態をチェックするための簡単な方法を提供するためにカスタムデータを使ってリソースを装飾できるようになります。 +コンテナは、その他にも次のようなメリットを提供するため、人気が高まっています。 -さらに、[Kubernetesコントロールプレーン](/ja/docs/concepts/overview/components/)は、開発者やユーザーが使える[API](/docs/reference/using-api/api-overview/)の上で成り立っています。ユーザーは[スケジューラー](https://github.com/kubernetes/community/blob/{{< param "githubbranch" >}}/contributors/devel/scheduler.md)などの独自のコントローラーを、汎用の[コマンドラインツール](/docs/user-guide/kubectl-overview/)で使える[独自のAPI](/docs/concepts/api-extension/custom-resources/)を持たせて作成することができます。 +* アジャイルアプリケーションの作成とデプロイ: VMイメージの利用時と比較して、コンテナイメージ作成の容易さと効率性が向上します。 +* 継続的な開発、インテグレーションとデプロイ: 信頼できる頻繁なコンテナイメージのビルドと、素早く簡単にロールバックすることが可能なデプロイを提供します。(イメージが不変であれば) +* 開発者と運用者の関心を分離: アプリケーションコンテナイメージの作成は、デプロイ時ではなく、ビルド/リリース時に行います。それによって、インフラストラクチャとアプリケーションを分離します。 +* 可観測性はOSレベルの情報とメトリクスだけではなく、アプリケーションの稼働状態やその他の警告も表示します。 +* 開発、テスト、本番環境を越えた環境の一貫性: クラウドで実行させるのと同じようにノートPCでも実行させる事ができます。 +* クラウドとOSディストリビューションの可搬性: Ubuntu、RHEL、CoreOS上でも、オンプレミスも、主要なパブリッククラウドでも、それ以外のどんな環境でも、実行できます。 +* アプリケーション中心の管理: 仮想マシン上でOSを実行するから、論理リソースを使用してOS上でアプリケーションを実行するへと抽象度のレベルを向上させます。 +* 疎結合、分散化、拡張性、柔軟性のあるマイクロサービス: アプリケーションを小さく、同時にデプロイと管理が可能な独立した部品に分割されます。1台の大きな単一目的のマシン上に実行するモノリシックなスタックではありません。 +* リソースの分割: アプリケーションのパフォーマンスが予測可能です。 +* リソースの効率的な利用: 高い効率性と集約性が可能です。 -この[デザイン](https://git.k8s.io/community/contributors/design-proposals/architecture/architecture.md)によって、他の多くのシステムがKubernetes上で構築できるようになりました。 +## Kubernetesが必要な理由と提供する機能 {#why-you-need-kubernetes-and-what-can-it-do} -## Kubernetesにないこと +コンテナは、アプリケーションを集約して実行する良い方法です。本番環境では、アプリケーションを実行しダウンタイムが発生しないように、コンテナを管理する必要があります。例えば、コンテナがダウンした場合、他のコンテナを起動する必要があります。このような動作がシステムに組込まれていると、管理が簡単になるのではないでしょうか？ -Kubernetesは伝統的な何でも入りのPaaSシステムではありません。Kubernetesはハードウェアレベルではなくコンテナレベルで動作するため、PaaS製品が提供するような、共通のいくつかの一般的に適用可能な機能(デプロイ、拡張、負荷分散、ログ記録、監視など)を提供します。ただし、Kubernetesはモノリシックではなく、これらのデフォルトのソリューションは任意に脱着可能です。Kubernetesは開発者の基盤を構築するための構成要素を提供しますが、重要な場合はユーザーの選択と柔軟性を維持します。 +そこを助けてくれるのがKubernetesです! Kubernetesは分散システムを弾力的に実行するフレームワークを提供してくれます。あなたのアプリケーションのためにスケーリングとフェイルオーバーの面倒を見てくれて、デプロイのパターンなどを提供します。例えば、Kubernetesはシステムにカナリアデプロイを簡単に管理することができます。 + +Kubernetesは以下を提供します。 + +* **サービスディスカバリーと負荷分散** +Kubernetesは、DNS名または独自のIPアドレスを使ってコンテナを公開することができます。コンテナへのトラフィックが多い場合は、Kubernetesは負荷分散し、ネットワークトラフィックを振り分けることができるたため、デプロイが安定します。 +* **ストレージ オーケストレーション** +Kubernetesは、ローカルストレージやパブリッククラウドプロバイダーなど、選択したストレージシステムを自動でマウントすることができます。 +* **自動化されたロールアウトとロールバック** +Kubernetesを使うとデプロイしたコンテナのあるべき状態を記述することができ、制御されたスピードで実際の状態をあるべき状態に変更することができます。例えば、アプリケーションのデプロイのために、新しいコンテナの作成や既存コンテナの削除、新しいコンテナにあらゆるリソースを適用する作業を、Kubernetesで自動化できます。 +* **自動ビンパッキング** +コンテナ化されたタスクを実行するノードのクラスターをKubernetesへ提供します。各コンテナがどれくらいCPUやメモリー(RAM)を必要とするのかをKubernetesに宣言することができます。Kubernetesはコンテナをノードにあわせて調整することができ、リソースを最大限に活用してくれます。 +* **自己修復** +Kubernetesは、処理が失敗したコンテナを再起動し、コンテナを入れ替え、定義したヘルスチェックに応答しないコンテナを強制終了します。処理の準備ができるまでは、クライアントに通知しません。 +* **機密情報と構成管理** +Kubernetesは、パスワードやOAuthトークン、SSHキーのよう機密の情報を保持し、管理することができます。機密情報をデプロイし、コンテナイメージを再作成することなくアプリケーションの構成情報を更新することができます。スタック構成の中で機密情報を晒してしまうこともありません。 + +## Kubernetesにないもの + +Kubernetesは、従来型の全部入りなPaaS(Platform as a Service)のシステムではありません。Kubernetesはハードウェアレベルではなく、コンテナレベルで動作するため、デプロイ、スケーリング、負荷分散、ロギングやモニタリングといったPasSが提供するのと共通の機能をいくつか提供しています。また一方、Kubernetesはモノリシックでなく、標準のソリューションは選択が自由で、追加と削除が容易な構成になっています。Kubernetesは開発プラットフォーム構築のためにビルディングブロックを提供しますが、重要な部分はユーザーの選択と柔軟性を維持しています。 Kubernetesは... -* サポートするアプリケーションの種類を限定しません。Kubernetesはステートレス、ステートフル、およびデータ処理ワークロードなど、非常に多様なワークロードをサポートするように作られています。アプリケーションをコンテナ内で実行できる場合は、Kubernetes上でもうまく動作するはずです。 -* ソースコードのデプロイやアプリケーションのビルドを行いません。継続的インテグレーション、デリバリー、デプロイ(CI/CD)ワークフローは、技術選定がそうであるように、組織の文化や好みによって決まるからです。 -* ミドルウェア(例: message buses)、データ処理フレームワーク(例: Spark)、データベース(例: mysql)、キャッシュ、クラスターストレージシステム(例: Ceph) のような、アプリケーションレベルの機能は組み込みでは提供しません。これらのコンポーネントはKubernetesの上で動作できますし、Open Service Brokerのようなポータブルメカニズムを経由してKubernetes上のアプリケーションからアクセスすることもできます。 -* ロギング、モニタリング、アラーティングソリューションへの指示は行いません。概念実証(PoC)としていくつかのインテグレーション、およびメトリックを収集およびエクスポートするためのメカニズムを提供します。 -* 設定言語/システム(例： jsonnet)を提供も強制もしません。任意の形式の宣言仕様の対象となる可能性がある宣言APIを提供します。 -* 包括的なインフラ構成、保守、管理、またはセルフヒーリングシステムを提供、導入しません。 - -さらに、Kubernetesは単なる *オーケストレーションシステム* ではありません。実際、オーケストレーションは不要です。*オーケストレーション* の技術的定義は、定義されたワークフローの実行です。最初にA、次にB、次にCを実行します。対照的に、Kubernetesは現在の状態を提供された望ましい状態に向かって継続的に推進する一連の独立した構成可能な制御プロセスで構成されます。AからCへのアクセス方法は関係ありません。集中管理も必要ありません。これにより、使いやすく、より強力で、堅牢で、回復力があり、そして拡張性のあるシステムが得られます。 - -## なぜコンテナなのか？ - -なぜコンテナを使うべきかの理由をお探しですか？ - -![なぜコンテナなのか？](/images/docs/why_containers.svg) - -アプリケーションをデプロイするための古い方法は、オペレーティングシステムのパッケージマネージャを使用してアプリケーションをホストにインストールすることでした。これには、アプリケーションの実行ファイル、構成、ライブラリ、ライフサイクルがそれぞれ、またホストOS自身と絡み合うというデメリットがありました。予測可能なロールアウトとロールバックを実現するために、不変の仮想マシンイメージを作成することもできますが、VMは重く、移植性がありません。 - -新しい方法は、ハードウェア仮想化ではなく、オペレーティングシステムレベルの仮想化に基づいてコンテナを展開することです。各コンテナは互いに、そしてホストから隔離されています。また、独自のファイルシステムを持ち、お互いのプロセスを見ることができず、計算リソースの使用量を制限することができます。これはVMよりも構築が簡単で、基盤となるインフラストラクチャとホストのファイルシステムから分離されているため、クラウドやOSのディストリビューション間で移植性があります。 - -コンテナは小さくて速いので、1つのアプリケーションを各コンテナイメージにまとめることができます。この1対1のアプリケーションとイメージの関係により、コンテナの利点が完全に引き出されます。コンテナを使用すると、各アプリケーションを残りのアプリケーションスタックと合成したり、本番インフラストラクチャ環境と結合したりする必要がないため、不変のコンテナイメージをデプロイ時ではなく、ビルド時またはリリース時に作成できます。ビルド/リリース時にコンテナイメージを生成することで、開発から運用に一貫した環境を持ち込むことができます。同様に、コンテナはVMよりもはるかに透過的であるため、監視と管理が容易になります。これは、コンテナのプロセスライフサイクルがコンテナ内のプロセススーパーバイザによって隠されるのではなく、インフラストラクチャによって管理される場合に特に当てはまります。最後に、コンテナごとに1つのアプリケーションを使用すると、コンテナの管理はアプリケーションのデプロイ管理と同等になります。 - -コンテナの利点をまとめると: - -* **アジャイルなアプリケーション作成とデプロイ**: - VMイメージの使用と比べ、コンテナイメージ作成は容易で効率も高いです。 -* **継続的な開発、インテグレーション、デプロイ**: - 迅速で簡単なロールバックで、信頼性の高い頻繁なコンテナイメージのビルドとデプロイを提供します(イメージの不変性にもよります)。 -* **開発と運用の懸念を分離**: - デプロイ時ではなくビルド時またはリリース時にアプリケーションのコンテナイメージを作成することで、アプリケーションをインフラストラクチャから切り離します。 -* **可観測性** - OSレベルの情報や測定基準だけでなく、アプリケーションの正常性やその他のシグナルも明確にします。 -* **開発、テスト、本番環境に跨った環境の一貫性**: - 手元のノートPC上でも、クラウド上と同じように動作します。 -* **クラウドとOSディストリビューションの移植性**: - Ubuntu、RHEL、CoreOS、オンプレミス、Google Kubernetes Engine、その他のどこでも動作します。 -* **アプリケーション中心の管理**: - 仮想ハードウェア上でのOS実行から、論理リソースを使用したOS上でのアプリケーション実行へと、抽象度のレベルを上げます。 -* **疎結合で、分散された、伸縮自在の遊離した[マイクロサービス](https://martinfowler.com/articles/microservices.html)**: - アプリケーションは小さな独立した欠片に分割され、動的に配置および管理できます。1つの大きな単一目的のマシンで実行されるモノリシックなスタックではありません。 -* **リソース分割**: - アプリケーションパフォーマンスが予測可能です。 -* **リソースの効率利用**: - 高効率で高密度です。 - -## Kubernetesってどういう意味？K8sって何？ - -**Kubernetes** という名前はギリシャ語で *操舵手* や *パイロット* という意味があり、*知事* や[サイバネティックス](http://www.etymonline.com/index.php?term=cybernetics)の語源にもなっています。*K8s* は、8文字の「ubernete」を「8」に置き換えた略語です。 - +* サポートするアプリケーションの種類を制限しません。Kubernetesは、スレートレス、ステートフルやデータ処理のワークロードなど、非常に多様なワークロードをサポートすることを目的としています。アプリケーションがコンテナで実行できるのであれば、Kubernetes上で問題なく実行できるはずです。 +* ソースコードのデプロイやアプリケーションのビルドは行いません。継続的なインテグレーション、デリバリー、デプロイ(CI/CD)のワークフローは、技術的な要件だけでなく組織の文化や好みで決められます。 +* ミドルウェア(例:メッセージバス)、データ処理フレームワーク(例:Spark)、データベース(例:MySQL)、キャッシュ、クラスターストレージシステム(例:Ceph)といったアプリケーションレベルの機能を組み込んで提供しません。それらのコンポーネントは、Kubernetes上で実行することもできますし、[Open Service Broker](https://openservicebrokerapi.org/)のようなポータブルメカニズムを経由してKubernetes上で実行されるアプリケーションからアクセスすることも可能です。 +* ロギング、モニタリングやアラートを行うソリューションは指定しません。PoCとしていくつかのインテグレーションとメトリクスを収集し出力するメカニズムを提供します。 +* 構成言語/システム(例:Jsonnet)の提供も指示もしません。任意の形式の宣言型仕様の対象となる可能性のある宣言型APIを提供します。 +* 統合的なマシンの構成、メンテナンス、管理、または自己修復を行うシステムは提供も採用も行いません。 +* さらに、Kubernetesは単なるオーケストレーションシステムではありません。実際には、オーケストレーションの必要性はありません。オーケストレーションの技術的な定義は、「最初にAを実行し、次にB、その次にCを実行」のような定義されたワークフローの実行です。対照的にKubernetesは、現在の状態から提示されたあるべき状態にあわせて継続的に維持するといった、独立していて構成可能な制御プロセスのセットを提供します。AからCへどのように移行するかは問題ではありません。集中管理も必要ありません。これにより、使いやすく、より強力で、堅牢で、弾力性と拡張性があるシステムが実現します。 ## {{% heading "whatsnext" %}} -* [はじめる](/docs/setup/)準備はできましたか？ -* さらなる詳細については、[Kubernetesのドキュメント](/ja/docs/home/)を御覧ください。 - - - +* [Kubernetesのコンポーネント](/ja/docs/concepts/overview/components/)を御覧ください。 +* [はじめる](/ja/docs/setup/)準備はできましたか？ diff --git a/content/ja/docs/concepts/overview/working-with-objects/kubernetes-objects.md b/content/ja/docs/concepts/overview/working-with-objects/kubernetes-objects.md index 16d1bdd27a..48cbed282a 100644 --- a/content/ja/docs/concepts/overview/working-with-objects/kubernetes-objects.md +++ b/content/ja/docs/concepts/overview/working-with-objects/kubernetes-objects.md @@ -2,7 +2,7 @@ title: Kubernetesオブジェクトを理解する content_type: concept weight: 10 -card: +card: name: concepts weight: 40 --- @@ -12,31 +12,31 @@ card: <!-- body --> -## Kubernetesオブジェクトを理解する +## Kubernetesオブジェクトを理解する {#kubernetes-objects} -*Kubernetesオブジェクト* は、Kubernetes上で永続的なエンティティです。Kubernetesはこれらのエンティティを使い、クラスターの状態を表現します。具体的に言うと、下記のような内容が表現出来ます: +*Kubernetesオブジェクト* は、Kubernetes上で永続的なエンティティです。Kubernetesはこれらのエンティティを使い、クラスターの状態を表現します。具体的に言うと、下記のような内容が表現できます: -* どのようなコンテナ化されたアプリケーションが稼働しているか（またそれらはどのノード上で動いているか） +* どのようなコンテナ化されたアプリケーションが稼働しているか(またそれらはどのノード上で動いているか) * それらのアプリケーションから利用可能なリソース * アプリケーションがどのように振る舞うかのポリシー、例えば再起動、アップグレード、耐障害性ポリシーなど -Kubernetesオブジェクトは"意図の記録"です。一度オブジェクトを作成すると、Kubernetesは常にそのオブジェクトが存在し続けるように動きます。オブジェクトを作成することで、Kubernetesに対し効果的にあなたのクラスターのワークロードがこのようになっていて欲しいと伝えているのです。これが、あなたのクラスターの**望ましい状態**です。 +Kubernetesオブジェクトは「意図の記録」です。一度オブジェクトを作成すると、Kubernetesは常にそのオブジェクトが存在し続けるように動きます。オブジェクトを作成することで、Kubernetesに対し効果的にあなたのクラスターのワークロードがこのようになっていて欲しいと伝えているのです。これが、あなたのクラスターの**望ましい状態**です。 Kubernetesオブジェクトを操作するには、作成、変更、または削除に関わらず[Kubernetes API](/ja/docs/concepts/overview/kubernetes-api/)を使う必要があるでしょう。例えば`kubectl`コマンドラインインターフェースを使った場合、このCLIが処理に必要なKubernetes API命令を、あなたに代わり発行します。あなたのプログラムから[クライアントライブラリ](/docs/reference/using-api/client-libraries/)を利用し、直接Kubernetes APIを利用することも可能です。 -### オブジェクトのspec（仕様）とstatus（状態） +### オブジェクトのspec(仕様)とstatus(状態) ほとんどのKubernetesオブジェクトは、オブジェクトの設定を管理する２つの入れ子になったオブジェクトのフィールドを持っています。それはオブジェクト *`spec`* とオブジェクト *`status`* です。`spec`を持っているオブジェクトに関しては、オブジェクト作成時に`spec`を設定する必要があり、望ましい状態としてオブジェクトに持たせたい特徴を記述する必要があります。 `status` オブジェクトはオブジェクトの *現在の状態* を示し、その情報はKubernetesとそのコンポーネントにより提供、更新されます。Kubernetes{{< glossary_tooltip text="コントロールプレーン" term_id="control-plane" >}}は、あなたから指定された望ましい状態と現在の状態が一致するよう常にかつ積極的に管理をします。 -例えば、KubernetesのDeploymentはクラスター上で稼働するアプリケーションを表現するオブジェクトです。Deploymentを作成するとき、アプリケーションの複製を３つ稼働させるようDeploymentのspecで指定するかもしれません。KubernetesはDeploymentのspecを読み取り、指定されたアプリケーションを３つ起動し、現在の状態がspecに一致するようにします。もしこれらのインスタンスでどれかが落ちた場合（statusが変わる）、Kubernetesはspecと、statusの違いに反応し、修正しようとします。この場合は、落ちたインスタンスの代わりのインスタンスを立ち上げます。 +例えば、KubernetesのDeploymentはクラスター上で稼働するアプリケーションを表現するオブジェクトです。Deploymentを作成するとき、アプリケーションの複製を３つ稼働させるようDeploymentのspecで指定するかもしれません。KubernetesはDeploymentのspecを読み取り、指定されたアプリケーションを３つ起動し、現在の状態がspecに一致するようにします。もしこれらのインスタンスでどれかが落ちた場合(statusが変わる)、Kubernetesはspecと、statusの違いに反応し、修正しようとします。この場合は、落ちたインスタンスの代わりのインスタンスを立ち上げます。 spec、status、metadataに関するさらなる情報は、[Kubernetes API Conventions](https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md)をご確認ください。 ### Kubernetesオブジェクトを記述する -Kubernetesでオブジェクトを作成する場合、オブジェクトの基本的な情報（例えば名前）と共に、望ましい状態を記述したオブジェクトのspecを渡さなければいけません。KubernetesAPIを利用しオブジェクトを作成する場合（直接APIを呼ぶか、`kubectl`を利用するかに関わらず）、APIリクエストはそれらの情報をJSON形式でリクエストのBody部に含んでいなければなりません。 +Kubernetesでオブジェクトを作成する場合、オブジェクトの基本的な情報(例えば名前)と共に、望ましい状態を記述したオブジェクトのspecを渡さなければいけません。KubernetesAPIを利用しオブジェクトを作成する場合(直接APIを呼ぶか、`kubectl`を利用するかに関わらず)、APIリクエストはそれらの情報をJSON形式でリクエストのBody部に含んでいなければなりません。 ここで、KubernetesのDeploymentに必要なフィールドとオブジェクトのspecを記載した`.yaml`ファイルの例を示します: @@ -63,7 +63,7 @@ Kubernetesオブジェクトを`.yaml`ファイルに記載して作成する場 * `metadata` - オブジェクトを一意に特定するための情報、文字列の`name`、`UID`、また任意の`namespace`が該当する * `spec` - オブジェクトの望ましい状態 -`spec`の正確なフォーマットは、Kubernetesオブジェクトごとに異なり、オブジェクトごとに特有な入れ子のフィールドを持っています。[Kubernetes API リファレンス](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/)が、Kubernetesで作成出来る全てのオブジェクトに関するspecのフォーマットを探すのに役立ちます。 +`spec`の正確なフォーマットは、Kubernetesオブジェクトごとに異なり、オブジェクトごとに特有な入れ子のフィールドを持っています。[Kubernetes API リファレンス](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/)が、Kubernetesで作成できる全てのオブジェクトに関するspecのフォーマットを探すのに役立ちます。 例えば、`Pod`オブジェクトに関する`spec`のフォーマットは[PodSpec v1 core](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podspec-v1-core)を、また`Deployment`オブジェクトに関する`spec`のフォーマットは[DeploymentSpec v1 apps](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#deploymentspec-v1-apps)をご確認ください。 diff --git a/content/ja/docs/concepts/overview/working-with-objects/labels.md b/content/ja/docs/concepts/overview/working-with-objects/labels.md index 95442bdf4c..c7ebacf360 100644 --- a/content/ja/docs/concepts/overview/working-with-objects/labels.md +++ b/content/ja/docs/concepts/overview/working-with-objects/labels.md @@ -185,7 +185,7 @@ kubectl get pods -l 'environment in (production),tier in (frontend)' ``` すでに言及したように、*集合ベース* の要件は、*等価ベース* の要件より表現力があります。 -例えば、値に対する_OR_ オペレーターを実装して以下のように書けます。 +例えば、値に対する _OR_ オペレーターを実装して以下のように書けます。 ```shell kubectl get pods -l 'environment in (production, qa)' diff --git a/content/ja/docs/concepts/overview/working-with-objects/namespaces.md b/content/ja/docs/concepts/overview/working-with-objects/namespaces.md index 1286e3c667..1b66e046f1 100644 --- a/content/ja/docs/concepts/overview/working-with-objects/namespaces.md +++ b/content/ja/docs/concepts/overview/working-with-objects/namespaces.md @@ -78,7 +78,7 @@ kubectl config view --minify | grep namespace: ## NamespaceとDNS ユーザーが[Service](/ja/docs/concepts/services-networking/service/)を作成するとき、Serviceは対応する[DNSエントリ](/ja/docs/concepts/services-networking/dns-pod-service/)を作成します。 -このエントリは`<service-name>.<namespace-name>.svc.cluster.local`という形式になり,これはもしあるコンテナがただ`<service-name>`を指定していた場合、Namespace内のローカルのServiceに対して名前解決されます。 +このエントリは`<service-name>.<namespace-name>.svc.cluster.local`という形式になり、これはもしあるコンテナがただ`<service-name>`を指定していた場合、Namespace内のローカルのServiceに対して名前解決されます。 これはデベロップメント、ステージング、プロダクションといって複数のNamespaceをまたいで同じ設定を使う時に効果的です。 もしユーザーがNamespaceをまたいでアクセスしたい時、 完全修飾ドメイン名(FQDN)を指定する必要があります。 diff --git a/content/ja/docs/concepts/overview/working-with-objects/object-management.md b/content/ja/docs/concepts/overview/working-with-objects/object-management.md index bbf0085cf1..49092c6dea 100644 --- a/content/ja/docs/concepts/overview/working-with-objects/object-management.md +++ b/content/ja/docs/concepts/overview/working-with-objects/object-management.md @@ -63,7 +63,7 @@ kubectl create deployment nginx --image nginx ## 命令型オブジェクト設定 -命令型オブジェクト設定では、kubectlコマンドに処理内容（create、replaceなど）、任意のフラグ、そして最低1つのファイル名を指定します。 +命令型オブジェクト設定では、kubectlコマンドに処理内容(create、replaceなど)、任意のフラグ、そして最低1つのファイル名を指定します。 指定されたファイルは、YAMLまたはJSON形式でオブジェクトの全ての定義情報を含んでいなければいけません。 オブジェクト定義の詳細は、[APIリファレンス](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/)を参照してください。 @@ -150,7 +150,7 @@ kubectl apply -R -f configs/ 命令型オブジェクト設定手法に対する長所: - 現行オブジェクトに直接行われた変更が、それらが設定ファイルに反映されていなかったとしても、保持されます -- 宣言型オブジェクト設定は、ディレクトリごとの処理をより良くサポートしており、自動的にオブジェクトごとに操作のタイプ（作成、パッチ、削除）を検出します +- 宣言型オブジェクト設定は、ディレクトリごとの処理をより良くサポートしており、自動的にオブジェクトごとに操作のタイプ(作成、パッチ、削除)を検出します 命令型オブジェクト設定手法に対する短所: @@ -163,9 +163,9 @@ kubectl apply -R -f configs/ - [命令型コマンドを利用したKubernetesオブジェクトの管理](/docs/tasks/manage-kubernetes-objects/imperative-command/) -- [オブジェクト設定（命令型）を利用したKubernetesオブジェクトの管理](/docs/tasks/manage-kubernetes-objects/imperative-config/) -- [オブジェクト設定（宣言型）を利用したKubernetesオブジェクトの管理](/docs/tasks/manage-kubernetes-objects/declarative-config/) -- [Kustomize（宣言型）を利用したKubernetesオブジェクトの管理](/docs/tasks/manage-kubernetes-objects/kustomization/) +- [オブジェクト設定(命令型)を利用したKubernetesオブジェクトの管理](/docs/tasks/manage-kubernetes-objects/imperative-config/) +- [オブジェクト設定(宣言型)を利用したKubernetesオブジェクトの管理](/docs/tasks/manage-kubernetes-objects/declarative-config/) +- [Kustomize(宣言型)を利用したKubernetesオブジェクトの管理](/docs/tasks/manage-kubernetes-objects/kustomization/) - [Kubectlコマンドリファレンス](/docs/reference/generated/kubectl/kubectl-commands/) - [Kubectl Book](https://kubectl.docs.kubernetes.io) - [Kubernetes APIリファレンス](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/) diff --git a/content/ja/docs/concepts/policy/limit-range.md b/content/ja/docs/concepts/policy/limit-range.md new file mode 100644 index 0000000000..656ba98a12 --- /dev/null +++ b/content/ja/docs/concepts/policy/limit-range.md @@ -0,0 +1,57 @@ +--- +title: Limit Range +content_type: concept +weight: 10 +--- + +<!-- overview --> + +デフォルトでは、コンテナは、Kubernetesクラスター上の[計算リソース](/docs/concepts/configuration/manage-resources-containers/)の消費を制限されずに実行されます。リソースクォータを利用すれば、クラスター管理者はリソースの消費と作成を{{< glossary_tooltip text="名前空間" term_id="namespace" >}}ベースで制限することができます。名前空間内では、Podやコンテナは名前空間のリソースクォータで定義された範囲内でできるだけ多くのCPUとメモリーを消費できてしまうため、1つのPodまたはコンテナが利用可能なすべてのリソースを専有してしまう恐れがあります。LimitRangeを利用すれば、このような名前空間内での(Podやコンテナへの)リソースの割り当てを制限するポリシーを定めることができます。 + +<!-- body --> + +*LimitRange*を利用すると、次のような制約を課せるようになります。 + +- 名前空間内のPodまたはコンテナごとに、計算リソースの使用量の最小値と最大値を強制する。 +- 名前空間内のPersistentVolumeClaimごとに、ストレージリクエストの最小値と最大値を強制する。 +- 名前空間内で、リソースのrequestとlimitの割合を強制する。 +- 名前空間内の計算リソースのデフォルトのrequest/limitの値を設定して、実行時にコンテナに自動的に注入する。 + +## LimitRangeを有効にする + +Kubernetes 1.10以降では、LimitRangeのサポートはデフォルトで有効になりました。 + +LimitRangeが特定の名前空間内で強制されるのは、その名前空間内にLimitRangeオブジェクトが存在する場合です。 + +LimitRangeオブジェクトの名前は、有効な[DNSサブドメイン名](/ja/docs/concepts/overview/working-with-objects/names#dns-subdomain-names)でなければなりません。 + +### Limit Rangeの概要 + +- 管理者は、1つの名前空間に1つのLimitRangeを作成します。 +- ユーザーは、Pod、コンテナ、PersistentVolumeClaimのようなリソースを名前空間内に作成します。 +- `LimitRanger`アドミッションコントローラーは、計算リソース要求が設定されていないすべてのPodとコンテナに対して、デフォルト値と制限値を強制します。そして、リソースの使用量を追跡し、名前空間内に存在するすべてのLimitRangeで定義された最小値、最大値、割合を外れないことを保証します。 +- LimitRangeの制約を破るようなリソース(Pod、コンテナ、PersistentVolumeClaim)の作成や更新を行うと、APIサーバーへのリクエストがHTTPステータスコード`403 FORBIDDEN`で失敗し、破られた制約を説明するメッセージが返されます。 +- 名前空間内でLimitRangeが`cpu`や`memory`などの計算リソースに対して有効になっている場合、ユーザーはrequestsやlimitsに値を指定しなければなりません。指定しなかった場合、システムはPodの作成を拒否する可能性があります。 +- LimitRangeの検証は、Podのアドミッションステージでのみ発生し、実行中のPodでは発生しません。 + +以下は、LimitRangeを使用して作成できるポリシーの例です。 + +- 8GiBのRAMと16コアのCPUの容量がある2ノードのクラスター上で、名前空間内のPodに対して、CPUには100mのrequestと最大500mのlimitの制約を課し、メモリーには200Miのrequestと600Miのlimitの制約を課す。 +- Spec内のrequestsにcpuやmemoryを指定せずに起動したコンテナに対して、CPUにはデフォルトで150mのlimitとrequestを、メモリーにはデフォルトで300Miのrequestをそれぞれ定義する。 + +名前空間のlimitの合計が、Podやコンテナのlimitの合計よりも小さくなる場合、リソースの競合が起こる可能性があります。その場合、コンテナやPodは作成されません。 + +LimitRangeに対する競合や変更は、すでに作成済みのリソースに対しては影響しません。 + +## {{% heading "whatsnext" %}} + +より詳しい情報は、[LimitRangerの設計ドキュメント](https://git.k8s.io/community/contributors/design-proposals/resource-management/admission_control_limit_range.md)を参照してください。 + +制限の使用例については、以下のページを読んでください。 + +- [名前空間ごとにCPUの最小値と最大値の制約を設定する方法](/docs/tasks/administer-cluster/manage-resources/cpu-constraint-namespace/)。 +- [名前空間ごとにメモリーの最小値と最大値の制約を設定する方法](/docs/tasks/administer-cluster/manage-resources/memory-constraint-namespace/)。 +- [名前空間ごとにCPUのRequestとLimitのデフォルト値を設定する方法](/docs/tasks/administer-cluster/manage-resources/cpu-default-namespace/)。 +- [名前空間ごとにメモリーのRequestとLimitのデフォルト値を設定する方法](/docs/tasks/administer-cluster/manage-resources/memory-default-namespace/)。 +- [名前空間ごとにストレージ消費量の最小値と最大値を設定する方法](/docs/tasks/administer-cluster/limit-storage-consumption/#limitrange-to-limit-requests-for-storage)。 +- [名前空間ごとのクォータを設定する詳細な例](/docs/tasks/administer-cluster/manage-resources/quota-memory-cpu-namespace/)。 diff --git a/content/ja/docs/concepts/scheduling-eviction/_index.md b/content/ja/docs/concepts/scheduling-eviction/_index.md new file mode 100644 index 0000000000..37b8e9507f --- /dev/null +++ b/content/ja/docs/concepts/scheduling-eviction/_index.md @@ -0,0 +1,8 @@ +--- +title: "スケジューリングと退避" +weight: 90 +description: > + Kubernetesにおいてスケジューリングとは、稼働させたいPodをNodeにマッチさせ、kubeletが実行できるようにすることを指します。 + 退避とは、リソース不足のNodeで1つ以上のPodを積極的に停止させるプロセスです。 +--- + diff --git a/content/ja/docs/concepts/scheduling/kube-scheduler.md b/content/ja/docs/concepts/scheduling-eviction/kube-scheduler.md similarity index 96% rename from content/ja/docs/concepts/scheduling/kube-scheduler.md rename to content/ja/docs/concepts/scheduling-eviction/kube-scheduler.md index 4e7d14284d..513b7d48a1 100644 --- a/content/ja/docs/concepts/scheduling/kube-scheduler.md +++ b/content/ja/docs/concepts/scheduling-eviction/kube-scheduler.md @@ -104,7 +104,7 @@ kube-schedulerは、デフォルトで用意されているスケジューリン - `ImageLocalityPriority`: すでにPodに対するコンテナイメージをローカルにキャッシュしているNodeを優先します。 -- `ServiceSpreadingPriority`: このポリシーの目的は、特定のServiceに対するバックエンドのPodが、それぞれ異なるNodeで実行されるようにすることです。このポリシーではServiceのバックエンドのPodが既に実行されていないNode上にスケジュールするように優先します。これによる結果として、Serviceは単体のNode障害に対してより耐障害性が高まります。 +- `ServiceSpreadingPriority`: このポリシーの目的は、特定のServiceに対するバックエンドのPodが、それぞれ異なるNodeで実行されるようにすることです。このポリシーではServiceのバックエンドのPodがすでに実行されていないNode上にスケジュールするように優先します。これによる結果として、Serviceは単体のNode障害に対してより耐障害性が高まります。 - `CalculateAntiAffinityPriorityMap`: このポリシーは[PodのAnti-Affinity](/ja/docs/concepts/configuration/assign-pod-node/#affinity-and-anti-affinity)の実装に役立ちます。 @@ -113,7 +113,7 @@ kube-schedulerは、デフォルトで用意されているスケジューリン ## {{% heading "whatsnext" %}} -* [スケジューラーのパフォーマンスチューニング](/docs/concepts/scheduling/scheduler-perf-tuning/)を参照してください。 +* [スケジューラーのパフォーマンスチューニング](/ja/docs/concepts/scheduling-eviction/scheduler-perf-tuning/)を参照してください。 * [Podトポロジーの分散制約](/docs/concepts/workloads/pods/pod-topology-spread-constraints/)を参照してください。 * kube-schedulerの[リファレンスドキュメント](/docs/reference/command-line-tools-reference/kube-scheduler/)を参照してください。 * [複数のスケジューラーの設定](/docs/tasks/administer-cluster/configure-multiple-schedulers/)について学んでください。 diff --git a/content/ja/docs/concepts/scheduling/scheduler-perf-tuning.md b/content/ja/docs/concepts/scheduling-eviction/scheduler-perf-tuning.md similarity index 88% rename from content/ja/docs/concepts/scheduling/scheduler-perf-tuning.md rename to content/ja/docs/concepts/scheduling-eviction/scheduler-perf-tuning.md index 2a096295a1..7adfe28827 100644 --- a/content/ja/docs/concepts/scheduling/scheduler-perf-tuning.md +++ b/content/ja/docs/concepts/scheduling-eviction/scheduler-perf-tuning.md @@ -8,9 +8,9 @@ weight: 70 {{< feature-state for_k8s_version="1.14" state="beta" >}} -[kube-scheduler](/docs/concepts/scheduling/kube-scheduler/#kube-scheduler)はKubernetesのデフォルトのスケジューラーです。クラスター内のノード上にPodを割り当てる責務があります。 +[kube-scheduler](/ja/docs/concepts/scheduling-eviction/kube-scheduler/#kube-scheduler)はKubernetesのデフォルトのスケジューラーです。クラスター内のノード上にPodを割り当てる責務があります。 -クラスター内に存在するノードで、Podのスケジューリング要求を満たすものはPodに対して_割り当て可能_ なノードと呼ばれます。スケジューラーはPodに対する割り当て可能なノードをみつけ、それらの割り当て可能なノードにスコアをつけます。その中から最も高いスコアのノードを選択し、Podに割り当てるためのいくつかの関数を実行します。スケジューラーは_Binding_ と呼ばれる処理中において、APIサーバーに対して割り当てが決まったノードの情報を通知します。 +クラスター内に存在するノードで、Podのスケジューリング要求を満たすものはPodに対して*割り当て可能*なノードと呼ばれます。スケジューラーはPodに対する割り当て可能なノードをみつけ、それらの割り当て可能なノードにスコアをつけます。その中から最も高いスコアのノードを選択し、Podに割り当てるためのいくつかの関数を実行します。スケジューラーは*Binding*と呼ばれる処理中において、APIサーバーに対して割り当てが決まったノードの情報を通知します。 このページでは、大規模のKubernetesクラスターにおけるパフォーマンス最適化のためのチューニングについて説明します。 @@ -35,11 +35,11 @@ algorithmSource: percentageOfNodesToScore: 50 ``` -{{< note >}} +{{< note >}} 割り当て可能なノードが50未満のクラスターにおいては、割り当て可能なノードの探索を止めるほどノードが多くないため、スケジューラーは全てのノードをチェックします。 {{< /note >}} -**この機能を無効にするためには**、`percentageOfNodesToScore`を100に設定してください。 +**この機能を無効にするためには**、`percentageOfNodesToScore`を100に設定してください。 ### percentageOfNodesToScoreのチューニング diff --git a/content/ja/docs/concepts/scheduling-eviction/taint-and-toleration.md b/content/ja/docs/concepts/scheduling-eviction/taint-and-toleration.md new file mode 100644 index 0000000000..90930357a8 --- /dev/null +++ b/content/ja/docs/concepts/scheduling-eviction/taint-and-toleration.md @@ -0,0 +1,221 @@ +--- +title: TaintとToleration +content_type: concept +weight: 40 +--- + + +<!-- overview --> +[_Nodeアフィニティ_](/docs/concepts/configuration/assign-pod-node/#affinity-and-anti-affinity)は +{{< glossary_tooltip text="Pod" term_id="pod" >}}の属性であり、ある{{< glossary_tooltip text="Node" term_id="node" >}}群を*引きつけます*（優先条件または必須条件）。反対に _taint_ はNodeがある種のPodを排除できるようにします。 + +_toleration_ はPodに適用され、一致するtaintが付与されたNodeへPodがスケジューリングされることを認めるものです。ただしそのNodeへ必ずスケジューリングされるとは限りません。 + +taintとtolerationは組になって機能し、Podが不適切なNodeへスケジューリングされないことを保証します。taintはNodeに一つまたは複数個付与することができます。これはそのNodeがtaintを許容しないPodを受け入れるべきではないことを示します。 + + +<!-- body --> + +## コンセプト + +Nodeにtaintを付与するには[kubectl taint](/docs/reference/generated/kubectl/kubectl-commands#taint)コマンドを使用します。 +例えば、次のコマンドは + +```shell +kubectl taint nodes node1 key=value:NoSchedule +``` + +`node1`にtaintを設定します。このtaintのキーは`key`、値は`value`、taintの効果は`NoSchedule`です。 +これは`node1`にはPodに合致するtolerationがなければスケジューリングされないことを意味します。 + +上記のコマンドで付与したtaintを外すには、下記のコマンドを使います。 +```shell +kubectl taint nodes node1 key:NoSchedule- +``` + +PodのtolerationはPodSpecの中に指定します。下記のtolerationはどちらも、上記の`kubectl taint`コマンドで追加したtaintと合致するため、どちらのtolerationが設定されたPodも`node1`へスケジューリングされることができます。 + +```yaml +tolerations: +- key: "key" + operator: "Equal" + value: "value" + effect: "NoSchedule" +``` + +```yaml +tolerations: +- key: "key" + operator: "Exists" + effect: "NoSchedule" +``` + +tolerationを設定したPodの例を示します。 + +{{< codenew file="pods/pod-with-toleration.yaml" >}} + +`operator`のデフォルトは`Equal`です。 + +tolerationがtaintと合致するのは、`key`と`effect`が同一であり、さらに下記の条件のいずれかを満たす場合です。 + +* `operator`が`Exists`（`value`を指定すべきでない場合） +* `operator`が`Equal`であり、かつ`value`が同一である場合 + +{{< note >}} + +2つ特殊な場合があります。 + +空の`key`と演算子`Exists`は全ての`key`、`value`、`effect`と一致するため、すべてのtaintと合致します。 + +空の`effect`は`key`が一致する全てのeffectと合致します。 + +{{< /note >}} + +上記の例では`effect`に`NoSchedule`を指定しました。代わりに、`effect`に`PreferNoSchedule`を指定することができます。 +これは`NoSchedule`の「ソフトな」バージョンであり、システムはtaintに対応するtolerationが設定されていないPodがNodeへ配置されることを避けようとしますが、必須の条件とはしません。3つ目の`effect`の値として`NoExecute`がありますが、これについては後述します。 + +同一のNodeに複数のtaintを付与することや、同一のPodに複数のtolerationを設定することができます。 +複数のtaintやtolerationが設定されている場合、Kubernetesはフィルタのように扱います。最初はNodeの全てのtaintがある状態から始め、Podが対応するtolerationを持っているtaintは無視され外されていきます。無視されずに残ったtaintが効果を及ぼします。 +具体的には、 + +* effect `NoSchedule`のtaintが無視されず残った場合、KubernetesはそのPodをNodeへスケジューリングしません。 +* effect `NoSchedule`のtaintは残らず、effect `PreferNoSchedule`のtaintは残った場合、KubernetesはそのNodeへのスケジューリングをしないように試みます。 +* effect `NoExecute`のtaintが残った場合、既に稼働中のPodはそのNodeから排除され、まだ稼働していないPodはスケジューリングされないようになります。 + +例として、下記のようなtaintが付与されたNodeを考えます。 + +```shell +kubectl taint nodes node1 key1=value1:NoSchedule +kubectl taint nodes node1 key1=value1:NoExecute +kubectl taint nodes node1 key2=value2:NoSchedule +``` + +Podには2つのtolerationが設定されています。 + +```yaml +tolerations: +- key: "key1" + operator: "Equal" + value: "value1" + effect: "NoSchedule" +- key: "key1" + operator: "Equal" + value: "value1" + effect: "NoExecute" +``` + +この例では、3つ目のtaintと合致するtolerationがないため、PodはNodeへはスケジューリングされません。 +しかし、これらのtaintが追加された時点で、そのNodeでPodが稼働していれば続けて稼働することが可能です。 これは、Podのtolerationと合致しないtaintは3つあるtaintのうちの3つ目のtaintのみであり、それが`NoSchedule`であるためです。 + +一般に、effect `NoExecute`のtaintがNodeに追加されると、合致するtolerationが設定されていないPodは即時にNodeから排除され、合致するtolerationが設定されたPodが排除されることは決してありません。 +しかし、effect`NoExecute`に対するtolerationは`tolerationSeconds`フィールドを任意で指定することができ、これはtaintが追加された後にそのNodeにPodが残る時間を示します。例えば、 + +```yaml +tolerations: +- key: "key1" + operator: "Equal" + value: "value1" + effect: "NoExecute" + tolerationSeconds: 3600 +``` + +この例のPodが稼働中で、対応するtaintがNodeへ追加された場合、PodはそのNodeに3600秒残り、その後排除されます。仮にtaintがそれよりも前に外された場合、Podは排除されません。 + +## ユースケースの例 + +taintとtolerationは、実行されるべきではないNodeからPodを遠ざけたり、排除したりするための柔軟な方法です。いくつかのユースケースを示します。 + +* **専有Node**: あるNode群を特定のユーザーに専有させたい場合、そのNode群へtaintを追加し(`kubectl taint nodes nodename dedicated=groupName:NoSchedule`) 対応するtolerationをPodへ追加します（これを実現する最も容易な方法はカスタム +[アドミッションコントローラー](/docs/reference/access-authn-authz/admission-controllers/)を書くことです）。 +tolerationが設定されたPodはtaintの設定された（専有の）Nodeと、クラスターにあるその他のNodeの使用が認められます。もしPodが必ず専有Node*のみ*を使うようにしたい場合は、taintと同様のラベルをそのNode群に設定し(例: `dedicated=groupName`)、アドミッションコントローラーはNodeアフィニティを使ってPodが`dedicated=groupName`のラベルの付いたNodeへスケジューリングすることが必要であるということも設定する必要があります。 + +* **特殊なハードウェアを備えるNode**: クラスターの中の少数のNodeが特殊なハードウェア（例えばGPU）を備える場合、そのハードウェアを必要としないPodがスケジューリングされないようにして、後でハードウェアを必要とするPodができたときの余裕を確保したいことがあります。 +これは特殊なハードウェアを持つNodeにtaintを追加(例えば `kubectl taint nodes nodename special=true:NoSchedule` または +`kubectl taint nodes nodename special=true:PreferNoSchedule`)して、ハードウェアを使用するPodに対応するtolerationを追加することで可能です。 +専有Nodeのユースケースと同様に、tolerationを容易に適用する方法はカスタム +[アドミッションコントローラー](/docs/reference/access-authn-authz/admission-controllers/)を使うことです。 +例えば、特殊なハードウェアを表すために[拡張リソース](/docs/concepts/configuration/manage-compute-resources-container/#extended-resources) +を使い、ハードウェアを備えるNodeに拡張リソースの名称のtaintを追加して、 +[拡張リソースtoleration](/docs/reference/access-authn-authz/admission-controllers/#extendedresourcetoleration) +アドミッションコントローラーを実行することが推奨されます。Nodeにはtaintが付与されているため、tolerationのないPodはスケジューリングされません。しかし拡張リソースを要求するPodを作成しようとすると、`拡張リソースtoleration` アドミッションコントローラーはPodに自動的に適切なtolerationを設定し、Podはハードウェアを備えるNodeへスケジューリングされます。 +これは特殊なハードウェアを備えたNodeではそれを必要とするPodのみが稼働し、Podに対して手作業でtolerationを追加しなくて済むようにします。 + +* **taintを基にした排除**: Nodeに問題が起きたときにPodごとに排除する設定を行うことができます。次のセクションにて説明します。 + +## taintを基にした排除 + +{{< feature-state for_k8s_version="v1.18" state="stable" >}} + +上述したように、effect `NoExecute`のtaintはNodeで実行中のPodに次のような影響を与えます。 + + * 対応するtolerationのないPodは即座に除外される + * 対応するtolerationがあり、それに`tolerationSeconds`が指定されていないPodは残り続ける + * 対応するtolerationがあり、それに`tolerationSeconds`が指定されているPodは指定された間、残される + +Nodeコントローラーは特定の条件を満たす場合に自動的にtaintを追加します。 +組み込まれているtaintは下記の通りです。 + + * `node.kubernetes.io/not-ready`: Nodeの準備ができていない場合。これはNodeCondition `Ready`が`False`である場合に対応します。 + * `node.kubernetes.io/unreachable`: NodeがNodeコントローラーから到達できない場合。これはNodeCondition`Ready`が`Unknown`の場合に対応します。 + * `node.kubernetes.io/out-of-disk`: Nodeのディスクの空きがない場合。 + * `node.kubernetes.io/memory-pressure`: Nodeのメモリーが不足している場合。 + * `node.kubernetes.io/disk-pressure`: Nodeのディスクが不足している場合。 + * `node.kubernetes.io/network-unavailable`: Nodeのネットワークが利用できない場合。 + * `node.kubernetes.io/unschedulable`: Nodeがスケジューリングできない場合。 + * `node.cloudprovider.kubernetes.io/uninitialized`: kubeletが外部のクラウド事業者により起動されたときに設定されるtaintで、このNodeは利用不可能であることを示します。cloud-controller-managerによるコントローラーがこのNodeを初期化した後にkubeletはこのtaintを外します。 + +Nodeから追い出すときには、Nodeコントローラーまたはkubeletは関連するtaintを`NoExecute`効果の状態で追加します。 +不具合のある状態から通常の状態へ復帰した場合は、kubeletまたはNodeコントローラーは関連するtaintを外すことができます。 + +{{< note >}} +コントロールプレーンは新しいtaintをNodeに加えるレートを制限しています。 +このレート制限は一度に多くのNodeが到達不可能になった場合（例えばネットワークの断絶）に、退役させられるNodeの数を制御します。 +{{< /note >}} + +Podに`tolerationSeconds`を指定することで不具合があるか応答のないNodeに残る時間を指定することができます。 + +例えば、ローカルの状態を多数持つアプリケーションとネットワークが分断された場合を考えます。ネットワークが復旧して、Podを排除しなくて済むことを見込んで、長時間Nodeから排除されないようにしたいこともあるでしょう。 +この場合Podに設定するtolerationは次のようになります。 + +```yaml +tolerations: +- key: "node.kubernetes.io/unreachable" + operator: "Exists" + effect: "NoExecute" + tolerationSeconds: 6000 +``` + +{{< note >}} +Kubernetesはユーザーまたはコントローラーが明示的に指定しない限り、自動的に`node.kubernetes.io/not-ready`と`node.kubernetes.io/unreachable`に対するtolerationを`tolerationSeconds=300`にて設定します。 + +自動的に設定されるtolerationは、taintに対応する問題がNodeで検知されても5分間はそのNodeにPodが残されることを意味します。 +{{< /note >}} + +[DaemonSet](/docs/concepts/workloads/controllers/daemonset/)のPodは次のtaintに対して`NoExecute`のtolerationが`tolerationSeconds`を指定せずに設定されます。 + + * `node.kubernetes.io/unreachable` + * `node.kubernetes.io/not-ready` + +これはDaemonSetのPodはこれらの問題によって排除されないことを保証します。 + +## 条件によるtaintの付与 + +NodeのライフサイクルコントローラーはNodeの状態に応じて`NoSchedule`効果のtaintを付与します。 +スケジューラーはNodeの状態ではなく、taintを確認します。 +Nodeに何がスケジューリングされるかは、そのNodeの状態に影響されないことを保証します。ユーザーは適切なtolerationをPodに付与することで、どの種類のNodeの問題を無視するかを選ぶことができます。 + +DaemonSetのコントローラーは、DaemonSetが中断されるのを防ぐために自動的に次の`NoSchedule`tolerationを全てのDaemonSetに付与します。 + + * `node.kubernetes.io/memory-pressure` + * `node.kubernetes.io/disk-pressure` + * `node.kubernetes.io/out-of-disk` (*重要なPodのみ*) + * `node.kubernetes.io/unschedulable` (1.10またはそれ以降) + * `node.kubernetes.io/network-unavailable` (*ホストネットワークのみ*) + +これらのtolerationを追加することは後方互換性を保証します。DaemonSetに任意のtolerationを加えることもできます。 + + +## {{% heading "whatsnext" %}} + +* [リソース枯渇の対処](/docs/tasks/administer-cluster/out-of-resource/)とどのような設定ができるかについてを読む +* [Podの優先度](/docs/concepts/configuration/pod-priority-preemption/)を読む diff --git a/content/ja/docs/concepts/scheduling/_index.md b/content/ja/docs/concepts/scheduling/_index.md deleted file mode 100644 index c428c68198..0000000000 --- a/content/ja/docs/concepts/scheduling/_index.md +++ /dev/null @@ -1,5 +0,0 @@ ---- -title: "スケジューリング" -weight: 90 ---- - diff --git a/content/ja/docs/concepts/services-networking/add-entries-to-pod-etc-hosts-with-host-aliases.md b/content/ja/docs/concepts/services-networking/add-entries-to-pod-etc-hosts-with-host-aliases.md new file mode 100644 index 0000000000..5c89abf5e7 --- /dev/null +++ b/content/ja/docs/concepts/services-networking/add-entries-to-pod-etc-hosts-with-host-aliases.md @@ -0,0 +1,118 @@ +--- +title: HostAliasesを使用してPodの/etc/hostsにエントリーを追加する +content_type: concept +weight: 60 +min-kubernetes-server-version: 1.7 +--- + + +<!-- overview --> + +Podの`/etc/hosts`ファイルにエントリーを追加すると、DNSやその他の選択肢を利用できない場合に、Podレベルでホスト名の名前解決を上書きできるようになります。このようなカスタムエントリーは、PodSpecのHostAliasesフィールドに追加できます。 + +HostAliasesを使用せずにファイルを修正することはおすすめできません。このファイルはkubeletが管理しており、Podの作成や再起動時に上書きされる可能性があるためです。 + + +<!-- body --> + +## デフォルトのhostsファイルの内容 + +Nginx Podを実行すると、Pod IPが割り当てられます。 + +```shell +kubectl run nginx --image nginx +``` + +``` +pod/nginx created +``` + +Pod IPを確認します。 + +```shell +kubectl get pods --output=wide +``` + +``` +NAME READY STATUS RESTARTS AGE IP NODE +nginx 1/1 Running 0 13s 10.200.0.4 worker0 +``` + +hostsファイルの内容は次のようになります。 + +```shell +kubectl exec nginx -- cat /etc/hosts +``` + +``` +# Kubernetes-managed hosts file. +127.0.0.1 localhost +::1 localhost ip6-localhost ip6-loopback +fe00::0 ip6-localnet +fe00::0 ip6-mcastprefix +fe00::1 ip6-allnodes +fe00::2 ip6-allrouters +10.200.0.4 nginx +``` + +デフォルトでは、`hosts`ファイルには、`localhost`やPod自身のホスト名などのIPv4とIPv6のボイラープレートだけが含まれています。 + +## 追加エントリーをhostAliasesに追加する + +デフォルトのボイラープレートに加えて、`hosts`ファイルに追加エントリーを追加できます。たとえば、`foo.local`と`bar.local`を`127.0.0.1`に、`foo.remote`と`bar.remote`を`10.1.2.3`にそれぞれ解決するためには、PodのHostAliasesを`.spec.hostAliases`以下に設定します。 + +{{< codenew file="service/networking/hostaliases-pod.yaml" >}} + +この設定を使用したPodを開始するには、次のコマンドを実行します。 + +```shell +kubectl apply -f https://k8s.io/examples/service/networking/hostaliases-pod.yaml +``` + +``` +pod/hostaliases-pod created +``` + +Podの詳細情報を表示して、IPv4アドレスと状態を確認します。 + +```shell +kubectl get pod --output=wide +``` + +``` +NAME READY STATUS RESTARTS AGE IP NODE +hostaliases-pod 0/1 Completed 0 6s 10.200.0.5 worker0 +``` + +`hosts`ファイルの内容は次のようになります。 + +```shell +kubectl logs hostaliases-pod +``` + +``` +# Kubernetes-managed hosts file. +127.0.0.1 localhost +::1 localhost ip6-localhost ip6-loopback +fe00::0 ip6-localnet +fe00::0 ip6-mcastprefix +fe00::1 ip6-allnodes +fe00::2 ip6-allrouters +10.200.0.5 hostaliases-pod + +# Entries added by HostAliases. +127.0.0.1 foo.local bar.local +10.1.2.3 foo.remote bar.remote +``` + +ファイルの最後に追加エントリーが指定されています。 + +## kubeletがhostsファイルを管理するのはなぜですか？ {#why-does-kubelet-manage-the-hosts-file} + +kubeletがPodの各コンテナの`hosts`ファイルを[管理する](https://github.com/kubernetes/kubernetes/issues/14633)のは、コンテナ起動後にDockerがファイルを[編集する](https://github.com/moby/moby/issues/17190)のを防ぐためです。 + +{{< caution >}} +コンテナ内部でhostsファイルを手動で変更するのは控えてください。 + +hostsファイルを手動で変更すると、コンテナが終了したときに変更が失われてしまいます。 +{{< /caution >}} diff --git a/content/ja/docs/concepts/services-networking/dual-stack.md b/content/ja/docs/concepts/services-networking/dual-stack.md new file mode 100644 index 0000000000..4dd77cf2bb --- /dev/null +++ b/content/ja/docs/concepts/services-networking/dual-stack.md @@ -0,0 +1,100 @@ +--- +title: IPv4/IPv6デュアルスタック +feature: + title: IPv4/IPv6デュアルスタック + description: > + IPv4およびIPv6のアドレスをPodとServiceに割り当てる +content_type: concept +weight: 70 +--- + +<!-- overview --> + +{{< feature-state for_k8s_version="v1.16" state="alpha" >}} + + IPv4/IPv6デュアルスタックを利用すると、IPv4とIPv6のアドレスの両方を{{< glossary_tooltip text="Pod" term_id="pod" >}}および{{< glossary_tooltip text="Service" term_id="service" >}}に指定できるようになります。 + + KubernetesクラスターでIPv4/IPv6デュアルスタックのネットワークを有効にすれば、クラスターはIPv4とIPv6のアドレスの両方を同時に割り当てることをサポートするようになります。 + +<!-- body --> + +## サポートされている機能 + +KubernetesクラスターでIPv4/IPv6デュアルスタックを有効にすると、以下の機能が提供されます。 + + * デュアルスタックのPodネットワーク(PodごとにIPv4とIPv6のアドレスが1つずつ割り当てられます) + * IPv4およびIPv6が有効化されたService(各Serviceは1つのアドレスファミリーでなければなりません) + * IPv4およびIPv6インターフェイスを経由したPodのクラスター外向きの(たとえば、インターネットへの)ルーティング + +## 前提条件 + +IPv4/IPv6デュアルスタックのKubernetesクラスターを利用するには、以下の前提条件を満たす必要があります。 + + * Kubernetesのバージョンが1.16以降である + * プロバイダーがデュアルスタックのネットワークをサポートしている(クラウドプロバイダーなどが、ルーティング可能なIPv4/IPv6ネットワークインターフェイスが搭載されたKubernetesを提供可能である) + * ネットワークプラグインがデュアルスタックに対応している(KubenetやCalicoなど) + +## IPv4/IPv6デュアルスタックを有効にする + +IPv4/IPv6デュアルスタックを有効にするには、クラスターの関連コンポーネントで`IPv6DualStack`[フィーチャーゲート](/ja/docs/reference/command-line-tools-reference/feature-gates/)を有効にして、デュアルスタックのクラスターネットワークの割り当てを以下のように設定します。 + + * kube-apiserver: + * `--feature-gates="IPv6DualStack=true"` + * kube-controller-manager: + * `--feature-gates="IPv6DualStack=true"` + * `--cluster-cidr=<IPv4 CIDR>,<IPv6 CIDR>` + * `--service-cluster-ip-range=<IPv4 CIDR>,<IPv6 CIDR>` + * `--node-cidr-mask-size-ipv4|--node-cidr-mask-size-ipv6` デフォルトのサイズは、IPv4では/24、IPv6では/64です + * kubelet: + * `--feature-gates="IPv6DualStack=true"` + * kube-proxy: + * `--cluster-cidr=<IPv4 CIDR>,<IPv6 CIDR>` + * `--feature-gates="IPv6DualStack=true"` + +{{< note >}} +IPv4 CIDRの例: `10.244.0.0/16` (自分のクラスターのアドレス範囲を指定してください) + +IPv6 CIDRの例: `fdXY:IJKL:MNOP:15::/64` (これはフォーマットを示すための例であり、有効なアドレスではありません。詳しくは[RFC 4193](https://tools.ietf.org/html/rfc4193)を参照してください) + +{{< /note >}} + +## Service + +クラスターでIPv4/IPv6デュアルスタックのネットワークを有効にした場合、IPv4またはIPv6のいずれかのアドレスを持つ{{< glossary_tooltip text="Service" term_id="service" >}}を作成できます。Serviceのcluster IPのアドレスファミリーは、Service上に`.spec.ipFamily`フィールドを設定することで選択できます。このフィールドを設定できるのは、新しいServiceの作成時のみです。`.spec.ipFamily`フィールドの指定はオプションであり、{{< glossary_tooltip text="Service" term_id="service" >}}と{{< glossary_tooltip text="Ingress" term_id="ingress" >}}でIPv4とIPv6を有効にする予定がある場合にのみ使用するべきです。このフィールドの設定は、[外向きのトラフィック](#egress-traffic)に対する要件には含まれません。 + +{{< note >}} +クラスターのデフォルトのアドレスファミリーは、kube-controller-managerに`--service-cluster-ip-range`フラグで設定した、最初のservice cluster IPの範囲のアドレスファミリーです。 +{{< /note >}} + +`.spec.ipFamily`は、次のいずれかに設定できます。 + + * `IPv4`: APIサーバーは`ipv4`の`service-cluster-ip-range`の範囲からIPアドレスを割り当てます + * `IPv6`: APIサーバーは`ipv6`の`service-cluster-ip-range`の範囲からIPアドレスを割り当てます + +次のServiceのspecには`ipFamily`フィールドが含まれていません。Kubernetesは、最初に設定した`service-cluster-ip-range`の範囲からこのServiceにIPアドレス(別名「cluster IP」)を割り当てます。 + +{{< codenew file="service/networking/dual-stack-default-svc.yaml" >}} + +次のServiceのspecには`ipFamily`フィールドが含まれています。Kubernetesは、最初に設定した`service-cluster-ip-range`の範囲からこのServiceにIPv6のアドレス(別名「cluster IP」)を割り当てます。 + +{{< codenew file="service/networking/dual-stack-ipv6-svc.yaml" >}} + +比較として次のServiceのspecを見ると、このServiceには最初に設定した`service-cluster-ip-range`の範囲からIPv4のアドレス(別名「cluster IP」)が割り当てられます。 + +{{< codenew file="service/networking/dual-stack-ipv4-svc.yaml" >}} + +### Type LoadBalancer + +IPv6が有効になった外部ロードバランサーをサポートしているクラウドプロバイダーでは、`type`フィールドに`LoadBalancer`を指定し、`ipFamily`フィールドに`IPv6`を指定することにより、クラウドロードバランサーをService向けにプロビジョニングできます。 + +## 外向きのトラフィック {#egress-traffic} + +パブリックおよび非パブリックでのルーティングが可能なIPv6アドレスのブロックを利用するためには、クラスターがベースにしている{{< glossary_tooltip text="CNI" term_id="cni" >}}プロバイダーがIPv6の転送を実装している必要があります。もし非パブリックでのルーティングが可能なIPv6アドレスを使用するPodがあり、そのPodをクラスター外の送信先(例:パブリックインターネット)に到達させたい場合、外向きのトラフィックと応答の受信のためにIPマスカレードを設定する必要があります。[ip-masq-agent](https://github.com/kubernetes-incubator/ip-masq-agent)はデュアルスタックに対応しているため、デュアルスタックのクラスター上でのIPマスカレードにはip-masq-agentが利用できます。 + +## 既知の問題 + + * Kubenetは、IPv4,IPv6の順番にIPを報告することを強制します(--cluster-cidr) + +## {{% heading "whatsnext" %}} + +* [IPv4/IPv6デュアルスタックのネットワークを検証する](/docs/tasks/network/validate-dual-stack) diff --git a/content/ja/docs/concepts/services-networking/ingress-controllers.md b/content/ja/docs/concepts/services-networking/ingress-controllers.md new file mode 100644 index 0000000000..f19d21ef43 --- /dev/null +++ b/content/ja/docs/concepts/services-networking/ingress-controllers.md @@ -0,0 +1,57 @@ +--- +title: Ingressコントローラー +reviewers: +content_type: concept +weight: 40 +--- + +<!-- overview --> + +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)のコントローラーをサポートし、保守しています。 + + + +<!-- body --> + +## 追加のコントローラー {#additional-controllers} + +* [AKS Application Gateway Ingress Controller](https://github.com/Azure/application-gateway-kubernetes-ingress)は[Azure Application Gateway](https://docs.microsoft.com/azure/application-gateway/overview)を利用して[AKSクラスター](https://docs.microsoft.com/azure/aks/kubernetes-walkthrough-portal)でIngressを実行可能にするIngressコントローラーです。 +* [Ambassador](https://www.getambassador.io/) API Gatewayは[Envoy](https://www.envoyproxy.io)ベースのIngressコントローラーで、[Datawire](https://www.datawire.io/)による[コミュニティ版](https://www.getambassador.io/docs)または[商用版](https://www.getambassador.io/pro/)のサポートがあります。 +* [AppsCode Inc.](https://appscode.com)では、最も広く使用されている[HAProxy](http://www.haproxy.org/)ベースのIngressコントローラーである[Voyager](https://appscode.com/products/voyager)のサポートと保守を提供しています。 +* [AWS ALB Ingress Controller](https://github.com/kubernetes-sigs/aws-alb-ingress-controller)は[AWS Application Load Balancer](https://aws.amazon.com/elasticloadbalancing/)を使用したIngressを有効にします。 +* [Contour](https://projectcontour.io/)は、VMwareが提供し、サポートしている[Envoy](https://www.envoyproxy.io/)ベースのIngressコントローラーです。 +* Citrixは、[ベアメタル](https://github.com/citrix/citrix-k8s-ingress-controller/tree/master/deployment/baremetal)と[クラウド](https://github.com/citrix/citrix-k8s-ingress-controller/tree/master/deployment)のデプロイ用に、ハードウェア(MPX）、仮想化(VPX)、[フリーコンテナ化(CPX) ADC](https://www.citrix.com/products/citrix-adc/cpx-express.html)用の[Ingressコントローラー](https://github.com/citrix/citrix-k8s-ingress-controller)を提供しています。 +* F5 Networksは[F5 BIG-IP Controller for Kubernetes](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コントローラーで、[solo.io](https://www.solo.io)からのエンタープライズサポートでAPI Gateway機能を提供しています。 +* [HAProxy Ingress](https://haproxy-ingress.github.io)は、HAProxy用の高度にカスタマイズ可能なコミュニティ主導のIngressコントローラーです。 +* [HAProxy Technologies](https://www.haproxy.com/)は[HAProxy Ingress Controller for Kubernetes](https://github.com/haproxytech/kubernetes-ingress)のサポートと保守を提供しています。[公式ドキュメント](https://www.haproxy.com/documentation/hapee/1-9r1/traffic-management/kubernetes-ingress-controller/)を参照してください。 +* [Istio](https://istio.io/)ベースのIngressコントローラー[Control Ingress Traffic](https://istio.io/docs/tasks/traffic-management/ingress/)。 +* [Kong](https://konghq.com/)は、[Kong Ingress Controller for Kubernetes](https://github.com/Kong/kubernetes-ingress-controller)の[コミュニティ版](https://discuss.konghq.com/c/kubernetes)と[商用版]](https://konghq.com/kong-enterprise/)のサポートと保守を提供しています。 +* [NGINX, Inc.](https://www.nginx.com/)は[NGINX Ingress Controller for Kubernetes](https://www.nginx.com/products/nginx/kubernetes-ingress-controller)のサポートと保守を提供しています。 +* [Skipper](https://opensource.zalando.com/skipper/kubernetes/ingress-controller/)は、カスタムプロキシーを構築するためのライブラリーとして設計された、Kubernetes Ingressなどのユースケースを含む、サービス構成用のHTTPルーターとリバースプロキシーです。 +* [Traefik](https://github.com/containous/traefik)はフル機能([Let's Encrypt](https://letsencrypt.org), secrets, http2, websocket)のIngressコントローラーで、[Containous](https://containo.us/services)による商用サポートもあります。 + +## 複数のIngressコントローラーの使用 {#using-multiple-ingress-controllers} + +[Ingressコントローラーは、好きな数だけ](https://git.k8s.io/ingress-nginx/docs/user-guide/multiple-ingress.md#multiple-ingress-controllers))クラスターにデプロイすることができます。Ingressを作成する際には、クラスター内に複数のIngressコントローラーが存在する場合にどのIngressコントローラーを使用するかを示すために適切な[`ingress.class`](https://git.k8s.io/ingress-gce/docs/faq/README.md#how-do-i-run-multiple-ingress-controllers-in-the-same-cluster)のアノテーションを指定します。 + +クラスを定義しない場合、クラウドプロバイダーはデフォルトのIngressコントローラーを使用する場合があります。 + +理想的には、すべてのIngressコントローラーはこの仕様を満たすべきですが、いくつかのIngressコントローラーはわずかに異なる動作をします。 + + +{{< note >}} +Ingressコントローラーのドキュメントを確認して、選択する際の注意点を理解してください。 +{{< /note >}} + + + +## {{% heading "whatsnext" %}} + + +* [Ingress](/ja/docs/concepts/services-networking/ingress/)の詳細 +* [Set up Ingress on Minikube with the NGINX Controller](/docs/tasks/access-application-cluster/ingress-minikube) diff --git a/content/ja/docs/concepts/services-networking/service-topology.md b/content/ja/docs/concepts/services-networking/service-topology.md new file mode 100644 index 0000000000..6af79ca7b3 --- /dev/null +++ b/content/ja/docs/concepts/services-networking/service-topology.md @@ -0,0 +1,144 @@ +--- +title: Serviceトポロジー +feature: + title: Serviceトポロジー + description: > + Serviceのトラフィックをクラスタートポロジーに基づいてルーティングします。 +content_type: concept +weight: 10 +--- + + +<!-- overview --> + +{{< feature-state for_k8s_version="v1.17" state="alpha" >}} + +*Serviceトポロジー*を利用すると、Serviceのトラフィックをクラスターのノードトポロジーに基づいてルーティングできるようになります。たとえば、あるServiceのトラフィックに対して、できるだけ同じノードや同じアベイラビリティゾーン上にあるエンドポイントを優先してルーティングするように指定できます。 + +<!-- body --> + +## はじめに + +デフォルトでは、`ClusterIP`や`NodePort`Serviceに送信されたトラフィックは、Serviceに対応する任意のバックエンドのアドレスにルーティングされる可能性があります。しかし、Kubernetes 1.7以降では、「外部の」トラフィックをそのトラフィックを受信したノード上のPodにルーティングすることが可能になりました。しかし、この機能は`ClusterIP`Serviceでは対応しておらず、ゾーン内ルーティングなどのより複雑なトポロジーは実現不可能でした。*Serviceトポロジー*の機能を利用すれば、Serviceの作者が送信元ノードと送信先ノードのNodeのラベルに基づいてトラフィックをルーティングするためのポリシーを定義できるようになるため、この問題を解決できます。 + +送信元と送信先の間のNodeラベルのマッチングを使用することにより、オペレーターは、そのオペレーターの要件に適したメトリクスを使用して、お互いに「より近い」または「より遠い」ノードのグループを指定できます。たとえば、パブリッククラウド上のさまざまなオペレーターでは、Serviceのトラフィックを同一ゾーン内に留めようとする傾向があります。パブリッククラウドでは、ゾーンをまたぐトラフィックでは関連するコストがかかる一方、ゾーン内のトラフィックにはコストがかからない場合があるからです。その他のニーズとしては、DaemonSetが管理するローカルのPodにトラフィックをルーティングできるようにしたり、レイテンシーを低く抑えるために同じラック上のスイッチに接続されたノードにトラフィックを限定したいというものがあります。 + +## Serviceトポロジーを利用する + +クラスターのServiceトポロジーが有効になっていれば、Serviceのspecに`topologyKeys`フィールドを指定することで、Serviceのトラフィックのルーティングを制御できます。このフィールドは、Nodeラベルの優先順位リストで、このServiceにアクセスするときにエンドポイントをソートするために使われます。トラフィックは、最初のラベルの値が送信元Nodeのものと一致するNodeに送信されます。一致したノード上にServiceに対応するバックエンドが存在しなかった場合は、2つ目のラベルについて検討が行われ、同様に、残っているラベルが順番に検討されまます。 + +一致するキーが1つも見つからなかった場合、トラフィックは、Serviceに対応するバックエンドが存在しなかったかのように拒否されます。言い換えると、エンドポイントは、利用可能なバックエンドが存在する最初のトポロジーキーに基づいて選択されます。このフィールドが指定され、すべてのエントリーでクライアントのトポロジーに一致するバックエンドが存在しない場合、そのクライアントに対するバックエンドが存在しないものとしてコネクションが失敗します。「任意のトポロジー」を意味する特別な値`"*"`を指定することもできます。任意の値にマッチするこの値に意味があるのは、リストの最後の値として使った場合だけです。 + +`topologyKeys`が未指定または空の場合、トポロジーの制約は適用されません。 + +ホスト名、ゾーン名、リージョン名のラベルが付いたNodeを持つクラスターについて考えてみましょう。このとき、Serviceの`topologyKeys`の値を設定することで、トラフィックの向きを以下のように制御できます。 + +* トラフィックを同じノード上のエンドポイントのみに向け、同じノード上にエンドポイントが1つも存在しない場合には失敗するようにする: `["kubernetes.io/hostname"]`。 +* 同一ノード上のエンドポイントを優先し、失敗した場合には同一ゾーン上のエンドポイント、同一リージョンゾーンのエンドポイントへとフォールバックし、それ以外の場合には失敗する: `["kubernetes.io/hostname", "topology.kubernetes.io/zone", "topology.kubernetes.io/region"]`。これは、たとえばデータのローカリティが非常に重要である場合などに役に立ちます。 +* 同一ゾーンを優先しますが、ゾーン内に利用可能なノードが存在しない場合は、利用可能な任意のエンドポイントにフォールバックする: `["topology.kubernetes.io/zone", "*"]`。 + +## 制約 + +* Serviceトポロジーは`externalTrafficPolicy=Local`と互換性がないため、Serviceは2つの機能を同時に利用できません。2つの機能を同じクラスター上の異なるServiceでそれぞれ利用することは可能ですが、同一のService上では利用できません。 + +* 有効なトポロジーキーは、現在は`kubernetes.io/hostname`、`topology.kubernetes.io/zone`、および`topology.kubernetes.io/region`に限定されています。しかし、将来は一般化され、他のノードラベルも使用できるようになる予定です。 + +* トポロジーキーは有効なラベルのキーでなければならず、最大で16個のキーまで指定できます。 + +* すべての値をキャッチする`"*"`を使用する場合は、トポロジーキーの最後の値として指定しなければなりません。 + +## 例 + +以下では、Serviceトポロジーの機能を利用したよくある例を紹介します。 + +### ノードローカルのエンドポイントだけを使用する + +ノードローカルのエンドポイントのみにルーティングするServiceの例です。もし同一ノード上にエンドポイントが存在しない場合、トラフィックは損失します。 + +```yaml +apiVersion: v1 +kind: Service +metadata: + name: my-service +spec: + selector: + app: my-app + ports: + - protocol: TCP + port: 80 + targetPort: 9376 + topologyKeys: + - "kubernetes.io/hostname" +``` + +### ノードローカルのエンドポイントを優先して使用する + +ノードローカルのエンドポイントを優先して使用しますが、ノードローカルのエンドポイントが存在しない場合にはクラスター全体のエンドポイントにフォールバックするServiceの例です。 + +```yaml +apiVersion: v1 +kind: Service +metadata: + name: my-service +spec: + selector: + app: my-app + ports: + - protocol: TCP + port: 80 + targetPort: 9376 + topologyKeys: + - "kubernetes.io/hostname" + - "*" +``` + + +### 同一ゾーンや同一リージョンのエンドポイントだけを使用する + +同一リージョンのエンドポイントより同一ゾーンのエンドポイントを優先するServiceの例です。もしいずれのエンドポイントも存在しない場合、トラフィックは損失します。 + +```yaml +apiVersion: v1 +kind: Service +metadata: + name: my-service +spec: + selector: + app: my-app + ports: + - protocol: TCP + port: 80 + targetPort: 9376 + topologyKeys: + - "topology.kubernetes.io/zone" + - "topology.kubernetes.io/region" +``` + +### ノードローカル、同一ゾーン、同一リーションのエンドポイントを優先して使用する + +ノードローカル、同一ゾーン、同一リージョンのエンドポイントを順番に優先し、クラスター全体のエンドポイントにフォールバックするServiceの例です。 + +```yaml +apiVersion: v1 +kind: Service +metadata: + name: my-service +spec: + selector: + app: my-app + ports: + - protocol: TCP + port: 80 + targetPort: 9376 + topologyKeys: + - "kubernetes.io/hostname" + - "topology.kubernetes.io/zone" + - "topology.kubernetes.io/region" + - "*" +``` + +## {{% heading "whatsnext" %}} + +* [Serviceトポトジーを有効にする](/docs/tasks/administer-cluster/enabling-service-topology)を読む。 +* [サービスとアプリケーションの接続](/ja/docs/concepts/services-networking/connect-applications-service/)を読む。 + diff --git a/content/ja/docs/concepts/workloads/controllers/cron-jobs.md b/content/ja/docs/concepts/workloads/controllers/cron-jobs.md index acc1ff3722..60e8e68370 100644 --- a/content/ja/docs/concepts/workloads/controllers/cron-jobs.md +++ b/content/ja/docs/concepts/workloads/controllers/cron-jobs.md @@ -46,7 +46,7 @@ Cannot determine if job needs to be started. Too many missed start time (> 100). 例として、CronJobが`08:30:00`を開始時刻として1分ごとに新しいJobをスケジュールするように設定され、`startingDeadlineSeconds`フィールドが設定されていない場合を想定します。CronJobコントローラーが`08:29:00` から`10:21:00`の間にダウンしていた場合、スケジューリングを逃したジョブの数が100を超えているため、ジョブは開始されません。 -このコンセプトを更に掘り下げるために、CronJobが`08:30:00`から1分ごとに新しいJobを作成し、`startingDeadlineSeconds`が200秒に設定されている場合を想定します。CronJobコントローラーが前回の例と同じ期間(`08:29:00` から`10:21:00`まで)にダウンしている場合でも、10:22:00時点でJobはまだ動作しています。このようなことは、過去200秒間(言い換えると、3回の失敗)に何回スケジュールが間に合わなかったをコントローラーが確認するときに発生します。これは最後にスケジュールされた時間から今までのものではありません。 +このコンセプトをさらに掘り下げるために、CronJobが`08:30:00`から1分ごとに新しいJobを作成し、`startingDeadlineSeconds`が200秒に設定されている場合を想定します。CronJobコントローラーが前回の例と同じ期間(`08:29:00` から`10:21:00`まで)にダウンしている場合でも、10:22:00時点でJobはまだ動作しています。このようなことは、過去200秒間(言い換えると、3回の失敗)に何回スケジュールが間に合わなかったをコントローラーが確認するときに発生します。これは最後にスケジュールされた時間から今までのものではありません。 CronJobはスケジュールに一致するJobの作成にのみ関与するのに対して、JobはJobが示すPod管理を担います。 diff --git a/content/ja/docs/concepts/workloads/controllers/deployment.md b/content/ja/docs/concepts/workloads/controllers/deployment.md index 8fae6041e8..f3b210ff4a 100644 --- a/content/ja/docs/concepts/workloads/controllers/deployment.md +++ b/content/ja/docs/concepts/workloads/controllers/deployment.md @@ -3,7 +3,7 @@ title: Deployment feature: title: 自動化されたロールアウトとロールバック description: > - Kubernetesはアプリケーションや設定への変更を段階的に行い、アプリケーションの状態を監視しながら、全てのインスタンスが同時停止しないようにします。更新に問題が起きたとき、Kubernetesは変更のロールバックを行います。進化を続けるDeploymnetのエコシステムを活用してください。 + Kubernetesはアプリケーションや設定への変更を段階的に行い、アプリケーションの状態を監視しながら、全てのインスタンスが同時停止しないようにします。更新に問題が起きたとき、Kubernetesは変更のロールバックを行います。進化を続けるDeploymentのエコシステムを活用してください。 content_type: concept weight: 30 @@ -1001,7 +1001,7 @@ Deploymentのセレクターに一致するラベルを持つPodを直接作成 Deploymentのリビジョン履歴は、Deploymentが管理するReplicaSetに保持されています。 -`.spec.revisionHistoryLimit`はオプションのフィールドで、ロールバック可能な古いReplicaSetの数を指定します。この古いReplicaSetは`etcd`内のリソースを消費し、`kubectl get rs`の出力結果を見にくくします。Deploymentの各リビジョンの設定はReplicaSetに保持されます。このため一度古いReplicaSetが削除されると、そのリビジョンのDeploymentにロールバックすることができなくなります。デフォルトでは10もの古いReplicaSetが保持されます。しかし、この値の最適値は新しいDeploymnetの更新頻度と安定性に依存します。 +`.spec.revisionHistoryLimit`はオプションのフィールドで、ロールバック可能な古いReplicaSetの数を指定します。この古いReplicaSetは`etcd`内のリソースを消費し、`kubectl get rs`の出力結果を見にくくします。Deploymentの各リビジョンの設定はReplicaSetに保持されます。このため一度古いReplicaSetが削除されると、そのリビジョンのDeploymentにロールバックすることができなくなります。デフォルトでは10もの古いReplicaSetが保持されます。しかし、この値の最適値は新しいDeploymentの更新頻度と安定性に依存します。 さらに詳しく言うと、この値を0にすると、0のレプリカを持つ古い全てのReplicaSetが削除されます。このケースでは、リビジョン履歴が完全に削除されているため新しいDeploymentのロールアウトを完了することができません。 diff --git a/content/ja/docs/concepts/workloads/controllers/job.md b/content/ja/docs/concepts/workloads/controllers/job.md new file mode 100644 index 0000000000..4a3849ee1e --- /dev/null +++ b/content/ja/docs/concepts/workloads/controllers/job.md @@ -0,0 +1,387 @@ +--- +title: Job +content_type: concept +feature: + title: バッチ実行 + description: > + Kubernetesはサービスに加えて、バッチやCIのワークロードを管理し、必要に応じて失敗したコンテナを置き換えることができます。 +weight: 60 +--- + +<!-- overview --> + +Jobは1つ以上のPodを作成し、指定された数のPodが正常に終了することを保証します。 +JobはPodの正常終了を追跡します。正常終了が指定された回数に達すると、そのタスク(つまりJob)は完了します。Jobを削除すると、そのJobが作成したPodがクリーンアップされます。 + +簡単な例としては、1つのPodを確実に実行して完了させるために、1つのJobオブジェクトを作成することです。 +ノードのハードウェア障害やノードの再起動などにより最初のPodが失敗したり削除されたりした場合、Jobオブジェクトは新たなPodを立ち上げます。 + +また、Jobを使用して複数のPodを並行して実行することもできます。 + + + + +<!-- body --> + +## Jobの実行例 + +ここでは、Jobの設定例を示します。πの値を2000桁目まで計算して出力します。 +完了までに10秒程度かかります。 + +{{< codenew file="controllers/job.yaml" >}} + +このコマンドで例を実行できます。 + +```shell +kubectl apply -f https://kubernetes.io/examples/controllers/job.yaml +``` +``` +job.batch/pi created +``` + +Jobのステータスは、`kubectl`を用いて確認します。 + +```shell +kubectl describe jobs/pi +``` +``` +Name: pi +Namespace: default +Selector: controller-uid=c9948307-e56d-4b5d-8302-ae2d7b7da67c +Labels: controller-uid=c9948307-e56d-4b5d-8302-ae2d7b7da67c + job-name=pi +Annotations: kubectl.kubernetes.io/last-applied-configuration: + {"apiVersion":"batch/v1","kind":"Job","metadata":{"annotations":{},"name":"pi","namespace":"default"},"spec":{"backoffLimit":4,"template":... +Parallelism: 1 +Completions: 1 +Start Time: Mon, 02 Dec 2019 15:20:11 +0200 +Completed At: Mon, 02 Dec 2019 15:21:16 +0200 +Duration: 65s +Pods Statuses: 0 Running / 1 Succeeded / 0 Failed +Pod Template: + Labels: controller-uid=c9948307-e56d-4b5d-8302-ae2d7b7da67c + job-name=pi + Containers: + pi: + Image: perl + Port: <none> + Host Port: <none> + Command: + perl + -Mbignum=bpi + -wle + print bpi(2000) + Environment: <none> + Mounts: <none> + Volumes: <none> +Events: + Type Reason Age From Message + ---- ------ ---- ---- ------- + Normal SuccessfulCreate 14m job-controller Created pod: pi-5rwd7 +``` + +Jobの完了したPodを表示するには、`kubectl get pods`を使います。 + +あるJobに属するすべてのPodの一覧を機械可読な形式で出力するには、次のようなコマンドを使います。 + +```shell +pods=$(kubectl get pods --selector=job-name=pi --output=jsonpath='{.items[*].metadata.name}') +echo $pods +``` +``` +pi-5rwd7 +``` + +ここでのセレクターは、Jobのセレクターと同じです。`--output = jsonpath`オプションは、返されたリストの各Podから名前だけを取得する式を指定します。 + + +いずれかのPodの標準出力を表示します。 + +```shell +kubectl logs $pods +``` +出力例は以下の通りです。 +```shell +3.1415926535897932384626433832795028841971693993751058209749445923078164062862089986280348253421170679821480865132823066470938446095505822317253594081284811174502841027019385211055596446229489549303819644288109756659334461284756482337867831652712019091456485669234603486104543266482133936072602491412737245870066063155881748815209209628292540917153643678925903600113305305488204665213841469519415116094330572703657595919530921861173819326117931051185480744623799627495673518857527248912279381830119491298336733624406566430860213949463952247371907021798609437027705392171762931767523846748184676694051320005681271452635608277857713427577896091736371787214684409012249534301465495853710507922796892589235420199561121290219608640344181598136297747713099605187072113499999983729780499510597317328160963185950244594553469083026425223082533446850352619311881710100031378387528865875332083814206171776691473035982534904287554687311595628638823537875937519577818577805321712268066130019278766111959092164201989380952572010654858632788659361533818279682303019520353018529689957736225994138912497217752834791315155748572424541506959508295331168617278558890750983817546374649393192550604009277016711390098488240128583616035637076601047101819429555961989467678374494482553797747268471040475346462080466842590694912933136770289891521047521620569660240580381501935112533824300355876402474964732639141992726042699227967823547816360093417216412199245863150302861829745557067498385054945885869269956909272107975093029553211653449872027559602364806654991198818347977535663698074265425278625518184175746728909777727938000816470600161452491921732172147723501414419735685481613611573525521334757418494684385233239073941433345477624168625189835694855620992192221842725502542568876717904946016534668049886272327917860857843838279679766814541009538837863609506800642251252051173929848960841284886269456042419652850222106611863067442786220391949450471237137869609563643719172874677646575739624138908658326459958133904780275901 +``` + +## Jobの仕様の作成 + +他のすべてのKubernetesの設定と同様に、Jobには`apiVersion`、` kind`、および`metadata`フィールドが必要です。 +その名前は有効な[DNSサブドメイン名](/ja/docs/concepts/overview/working-with-objects/names#dns-subdomain-names)である必要があります。 + +Jobには[`.spec`セクション](https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status)も必要です。 + +### Podテンプレート + +`.spec.template`は、`.spec`の唯一の必須フィールドです。 + +`.spec.template`は[Podテンプレート](/ja/docs/concepts/workloads/pods/#pod-templates)です。 +ネストされており、`apiVersion`や`kind`ないことを除けば、{{< glossary_tooltip text="Pod" term_id="pod" >}}とまったく同じスキーマを持ちます。 + +Podの必須フィールドに加えて、JobのPodテンプレートでは、適切なラベル([Podセレクター](#pod-selector)参照)と適切な再起動ポリシーを指定しなければなりません。 + +`Never`または`OnFailure`と等しい[`RestartPolicy`](/ja/docs/concepts/workloads/pods/pod-lifecycle/#restart-policy)のみが許可されます。 + +### Podセレクター {#pod-selector} + +`.spec.selector`フィールドはオプションです。ほとんどの場合、指定すべきではありません。 +セクション「[独自のPodセレクターの指定](#specifying-your-own-pod-selector)」を参照してください。 + + +### Jobの並列実行 {#parallel-jobs} + +Jobとして実行するのに適したタスクは、大きく分けて3つあります。 + +1. 非並列Job + - 通常は、Podが失敗しない限り、1つのPodのみが起動されます。 + - そのPodが正常に終了するとすぐにJobが完了します。 +2. *固定の完了数*を持つ並列Job + - `.spec.completions`に、0以外の正の値を指定します。 + - Jobはタスク全体を表し、1から`.spec.completions`の範囲内の各値に対して、1つの成功したPodがあれば完了です。 + - **まだ実装されていません**が、各Podには、1から`.spec.completions`の範囲内で異なるインデックスが渡されます。 +3. *ワークキュー*を持つ並列Job + - `.spec.completions`は指定しません。デフォルトは`.spec.parallelism`です。 + - Podは、それぞれが何を処理するか決定するために、 Pod間または外部サービス間で調整する必要があります。例えば、あるPodはワークキューから最大N個のアイテムのバッチを取得します。 + - 各Podはすべてのピアが完了したかどうか、つまりJob全体が完了したかどうかを、独立して判断できます。 + - Jobの _任意の_ Podが正常終了すると、新しいPodは作成されません。 + - 少なくとも1つのPodが正常終了し、すべてのPodが終了すると、Jobは正常に完了します。 + - Podが正常終了した後は、他のPodがこのタスクの処理を行ったり、出力を書き込んだりしてはなりません。それらはすべて終了する必要があります。 + +_非並列_ Jobの場合、`.spec.completions`と`.spec.parallelism`の両方を未設定のままにすることができます。両方が設定されていない場合、どちらもデフォルトで1になります。 + +_ワークキュー_ を持つJobの場合、`.spec.completions`を未設定のままにし、`.spec.parallelism`を非負整数にする必要があります。 + + +様々な種類のJobを利用する方法の詳細については、セクション「[Jobのパターン](#job-patterns)」をご覧ください。 + +#### 並列処理の制御 + +並列処理数(`.spec.parallelism`)については、任意の非負整数を設定できます。 +指定しない場合、デフォルトで1になります。 +0を指定した場合、並列処理数が増えるまで、Jobは実質的に一時停止されます。 + +以下に挙げる様々な理由から、実際の並列処理数(任意の時点で実行されるPodの数)が、要求された数より多い場合と少ない場合があります。 + +- _固定完了数_ を持つJobの場合、並行して実行されるPodの実際の数は、残りの完了数を超えることはありません。`.spec.parallelism`の大きい値は事実上無視されます。 +- _ワークキュー_ を持つJobの場合、Podが成功しても新しいPodは開始されません。ただし、残りのPodは完了できます。 +- Jobコントローラー({{< glossary_tooltip term_id="controller" >}})が反応する時間がない場合も考えられます。 +- Jobコントローラーが何らかの理由(`ResourceQuota`がない、権限がないなど)でPodの作成に失敗した場合、要求された数よりも少ないPod数になる可能性があります。 +- Jobコントローラーは、同じJob内で以前のPodが過剰に失敗したために、新しいPodの作成を調整する場合があります。 +- Podをグレースフルにシャットダウンした場合、停止までに時間がかかります。 + +## Podおよびコンテナの障害の処理 + +Pod内のコンテナは、その中のプロセスが0以外の終了コードで終了した、またはメモリー制限を超えたためにコンテナが強制終了されたなど、さまざまな理由で失敗する可能性があります。これが発生し、`.spec.template.spec.restartPolicy = "OnFailure"`であ場合、Podはノードに残りますが、コンテナは再実行されます。したがって、プログラムはローカルで再起動するケースを処理するか、`.spec.template.spec.restartPolicy = "Never"`を指定する必要があります。 +`restartPolicy`の詳細な情報は、[Podのライフサイクル](/ja/docs/concepts/workloads/pods/pod-lifecycle/#example-states)を参照してください。 + +さまざまな理由で、Pod全体が失敗することもあります。例えば、Podが(ノードのアップグレード、再起動、削除などにより)ノードから切り離された場合や、Podのコンテナが失敗して`.spec.template.spec.restartPolicy = "Never"`が設定されている場合などです。Podが失敗した場合、Jobコントローラーは新しいPodを開始します。つまり、アプリケーションは新しいPodで再起動されたケースを処理する必要があります。特に、前の実行によって発生した一時ファイル、ロック、不完全な出力などに対する処理が必要です。 + +たとえ`.spec.parallelism = 1`、`.spec.completions = 1`、`.spec.template.spec.restartPolicy = "Never"`を指定しても、同じプログラムが2回起動される場合があることに注意してください。 + +`.spec.parallelism`と`.spec.completions`の両方を1より大きい値に指定した場合は、複数のPodが同時に実行される可能性があります。したがって、Podは同時実行性にも対応する必要があります。 + +### Pod Backoff Failure Policy + +構成の論理エラーなどが原因で、ある程度の再試行後にJobを失敗させたい場合があります。 +そのためには、`.spec.backoffLimit`を設定して、Jobが失敗したと見なすまでの再試行回数を指定します。デフォルトでは6に設定されています。 +失敗したPodは、6分を上限とする指数バックオフ遅延(10秒、20秒、40秒...)に従って、Jobコントローラーにより再作成されます。 +JobのPodが削除されるか、Jobの他のPodがその時間に失敗することなく成功すると、バックオフカウントがリセットされます。 + +{{< note >}} +Jobに`restartPolicy = "OnFailure"`がある場合、Jobのバックオフ制限に達すると、Jobを実行しているコンテナが終了することに注意してください。これにより、Jobの実行可能ファイルのデバッグがより困難になる可能性があります。Jobのデバッグするまたはロギングシステムを使用する場合は、`restartPolicy = "Never"`を設定して、失敗したJobからの出力が誤って失われないようにすることをお勧めします。 +{{< /note >}} + +## Jobの終了とクリーンアップ + +Jobが完了すると、Podは作成されなくなりますが、Podの削除も行われません。それらを保持しておくと、完了したPodのログを表示して、エラー、警告、またはその他の診断の出力を確認できます。 +Jobオブジェクトは完了後も残るため、ステータスを表示できます。ステータスを確認した後、古いJobを削除するのはユーザーの責任です。`kubectl`(例えば`kubectl delete jobs/pi`や`kubectl delete -f ./job.yaml`)を用いてJobを削除してください。`kubectl`でJobを削除すると、Jobが作成したすべてのPodも削除されます。 + +デフォルトでは、Podが失敗する(`restartPolicy=Never`)かコンテナがエラーで終了する(`restartPolicy=OnFailure`)場合を除き、Jobは中断されずに実行されます。その時点でJobは上記の`.spec.backoffLimit`に従います。`.spec.backoffLimit`に達すると、Jobは失敗としてマークされ、実行中のPodはすべて終了されます。 + +Jobを終了する別の方法は、アクティブな期限を設定することです。 +これを行うには、Jobの`.spec.activeDeadlineSeconds`フィールドを秒数に設定します +`activeDeadlineSeconds`は、作成されたPodの数に関係なく、Jobの期間に適用されます。 +Jobが`activeDeadlineSeconds`に到達すると、実行中のすべてのPodが終了し、Jobのステータスは`type: Failed`および`reason: DeadlineExceeded`となります。 + +Jobの`.spec.activeDeadlineSeconds`は、`.spec.backoffLimit`よりも優先されることに注意してください。したがって、1つ以上の失敗したPodを再試行しているJobは、`backoffLimit`にまだ達していない場合でも、`activeDeadlineSeconds`で指定された制限時間に達すると、追加のPodをデプロイしません。 + +以下に例を挙げます。 + +```yaml +apiVersion: batch/v1 +kind: Job +metadata: + name: pi-with-timeout +spec: + backoffLimit: 5 + activeDeadlineSeconds: 100 + template: + spec: + containers: + - name: pi + image: perl + command: ["perl", "-Mbignum=bpi", "-wle", "print bpi(2000)"] + restartPolicy: Never +``` + +Job内のJobの仕様と[Podテンプレートの仕様](/ja/docs/concepts/workloads/pods/init-containers/#detailed-behavior)の両方に`activeDeadlineSeconds`フィールドがあることに注意してください。このフィールドが適切なレベルに設定されていることを確認してください。 + +`restartPolicy`はPodに適用され、Job自体には適用されないことに注意してください。Jobのステータスが`type: Failed`になると、Jobの自動再起動は行われません。 +つまり、 `.spec.activeDeadlineSeconds`と`.spec.backoffLimit`でアクティブ化されるJob終了のメカニズムは、手作業での介入が必要になるような永続的なJobの失敗を引き起こします。 + +## 終了したJobの自動クリーンアップ + +終了したJobは、通常、もう必要ありません。それらをシステム内に保持すると、APIサーバーに負担がかかります。[CronJobs](/ja/docs/concepts/workloads/controllers/cron-jobs/)などの上位レベルのコントローラーによってJobが直接管理されている場合、指定された容量ベースのクリーンアップポリシーに基づいて、JobをCronJobsでクリーンアップできます。 + +### 終了したJobのTTLメカニズム + +{{< feature-state for_k8s_version="v1.12" state="alpha" >}} + +完了したJob(`Complete`または`Failed`)を自動的にクリーンアップする別の方法は、[TTLコントローラー](/ja/docs/concepts/workloads/controllers/ttlafterfinished/)が提供するTTLメカニズムを使用して、完了したリソースを指定することです。Jobの`.spec.ttlSecondsAfterFinished`フィールドに指定します。 + +TTLコントローラーがJobをクリーンアップすると、Jobが連鎖的に削除されます。つまり、Podなどの依存オブジェクトがJobとともに削除されます。Jobが削除されるとき、ファイナライザーなどのライフサイクル保証が優先されることに注意してください。 + +例は以下の通りです。 + +```yaml +apiVersion: batch/v1 +kind: Job +metadata: + name: pi-with-ttl +spec: + ttlSecondsAfterFinished: 100 + template: + spec: + containers: + - name: pi + image: perl + command: ["perl", "-Mbignum=bpi", "-wle", "print bpi(2000)"] + restartPolicy: Never +``` + +Job`pi-with-ttl`は、Jobが終了してから`100`秒後に自動的に削除される。 + +フィールドが`0`に設定されている場合は、Jobは終了後すぐに自動的に削除されます。フィールドが設定されていない場合は、このJobは終了後にTTLコントローラーによってクリーンアップされません。 + +このTTLメカニズムはアルファ版であり、`TTLAfterFinished`フィーチャーゲートであることに注意してください。詳細は[TTLコントローラー](/ja/docs/concepts/workloads/controllers/ttlafterfinished/)のドキュメントを参照してください。 + +## Jobのパターン {#job-patterns} + +Jobオブジェクトは、Podの信頼性の高い並列実行をサポートするために使用できます。Jobオブジェクトは、科学的コンピューティングで一般的に見られるような、密接に通信する並列プロセスをサポートするようには設計されていません。しかし、独立しているが関連性のある*ワークアイテム*の集合の並列処理はサポートしています。 + +例えば送信する電子メール、レンダリングするフレーム、トランスコードするファイル、スキャンするNoSQLデータベースのキーの範囲などです。 + +複雑なシステムでは、複数の異なるワークアイテムの集合があるかもしれません。ここでは、ユーザーがまとめて管理したい作業項目の1つの集合(バッチJob)を考えています。 + +並列計算にはいくつかのパターンがあり、それぞれ長所と短所があります。 +トレードオフは以下の通りです。 + +- 各ワークアイテムに1つのJobオブジェクトを使用する場合と、すべてのワークアイテムに1つのJobオブジェクトを使用する場合を比較すると、後者の方がワークアイテムの数が多い場合に適しています。前者では、ユーザーとシステムが大量のJobオブジェクトを管理するためのオーバーヘッドが発生します。 +- 作成されたPodの数がワークアイテムの数に等しい場合と、各Podが複数のワークアイテムを処理する場合を比較すると、前者の方が一般的に既存のコードやコンテナへの変更が少ないです。後者は上記の項目と同様の理由で、大量のワークアイテムを処理するのに適しています。 +- いくつかのアプローチでは、ワークキューを使用します。これはキューサービスを実行している必要があり、既存のプログラムやコンテナを変更してワークキューを使用するようにする必要があります。他のアプローチは、既存のコンテナ化されたアプリケーションに適応するのがさらに容易です。 + +ここでは、上記のトレードオフに対応するものを、2から4列目にまとめています。 +パターン名は、例とより詳細な説明へのリンクでもあります。 + +| パターン名 | 単一のJobオブジェクト | ワークアイテムよりPodが少ないか？ | アプリをそのまま使用するか？ | Kube 1.1で動作するか？ | +| ----------------------------------------------------------------------------------------------- |:-----------------:|:---------------------------:|:-------------------:|:-------------------:| +| [Jobテンプレートを拡張する](/ja/docs/tasks/job/parallel-processing-expansion/) | | | ✓ | ✓ | +| [ワークアイテムごとにPodでキューを作成する](/ja/docs/tasks/job/coarse-parallel-processing-work-queue/) | ✓ | | 場合による | ✓ | +| [Pod数が可変であるキューを作成する](/ja/docs/tasks/job/fine-parallel-processing-work-queue/) | ✓ | ✓ | | ✓ | +| 単一のJob静的な処理を割り当てる | ✓ | | ✓ | | + +完了数を`.spec.completions`で指定すると、Jobコントローラーが作成した各Podは同じ[`spec`](https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status)を持ちます。つまり、あるタスクを実行するすべてのPodは、同じコマンドラインと同じイメージ、同じボリューム、そして(ほぼ)同じ環境変数を持ちます。これらのパターンは、Podが異なる処理を行うように配置するための様々な方法です。 + +以下の表では、パターンごとに必要な`.spec.parallelism`と`.spec.completions`の設定を示します。 +ここで、`W`はワークアイテム数とします。 + +| パターン名 | `.spec.completions` | `.spec.parallelism` | +| ----------------------------------------------------------------------------------------------- |:-------------------:|:--------------------:| +| [Jobテンプレートを拡張する](/ja/docs/tasks/job/parallel-processing-expansion/) | 1 | 1とする必要あり | +| [ワークアイテムごとにPodでキューを作成する](/ja/docs/tasks/job/coarse-parallel-processing-work-queue/) | W | 任意 | +| [Pod数が可変であるキューを作成する](/ja/docs/tasks/job/fine-parallel-processing-work-queue/) | 1 | 任意 | +| 単一のJob静的な処理を割り当てる | W | 任意 | + + +## 高度な使用方法 + +### 独自のPodセレクターを指定する {#specifying-your-own-pod-selector} + +通常、Jobオブジェクトを作成する際には`.spec.selector`を指定しません。 +システムのデフォルトのロジックで、Jobの作成時にこのフィールドを追加します。 +セレクターの値は、他のJobと重複しないように選択されます。 + +しかし、場合によっては、この自動的に設定されるセレクターを上書きする必要があるかもしれません。 +これを行うには、Jobの`.spec.selector`を指定します。 + +これを行う際には十分に注意が必要です。もし指定したラベルセレクターが、そのJobのPodに対して固有でなく、無関係なPodにマッチする場合、無関係なJobのPodが削除されたり、このJobが他のPodを完了したものとしてカウントしたり、一方または両方のJobがPodの作成や完了まで実行を拒否することがあります。 +もし固有でないセレクターを選択した場合は、他のコントローラー(例えばレプリケーションコントローラーなど)やそのPodも予測不能な動作をする可能性があります。Kubernetesは`.spec.selector`を指定する際のミスを防ぐことはできません。 + +ここでは、この機能を使いたくなるようなケースの例をご紹介します。 +`old`というJobがすでに実行されているとします。既存のPodを実行し続けたいが、作成した残りのPodには別のPodテンプレートを使用し、Jobには新しい名前を付けたいとします。 +これらのフィールドは更新が不可能であるため、Jobを更新することはできません。 +そのため、`kubectl delete jobs/old --cascade=false`を使って、`old`というJobを削除し、一方で _そのPodは実行したまま_ にします。 +削除する前に、どのセレクターを使っているかメモしておきます。 + +``` +kubectl get job old -o yaml +``` +``` +kind: Job +metadata: + name: old + ... +spec: + selector: + matchLabels: + controller-uid: a8f3d00d-c6d2-11e5-9f87-42010af00002 + ... +``` +次に`new`という名前の新しいJobを作成し、同じセレクターを明示的に指定します。 +既存のPodには`controller-uid=a8f3d00d-c6d2-11e5-9f87-42010af00002`というラベルが付いているので、それらも同様にJob`new`で制御されます。 + +システムが自動的に生成するセレクターを使用していないので、新しいJobでは`manualSelector: true`を指定する必要があります。 + +``` +kind: Job +metadata: + name: new + ... +spec: + manualSelector: true + selector: + matchLabels: + controller-uid: a8f3d00d-c6d2-11e5-9f87-42010af00002 + ... +``` + +新しいJob自体は`a8f3d00d-c6d2-11e5-9f87-42010af00002`とは異なるuidを持つでしょう。 +`manualSelector: true`を設定すると、あなたが何をしているかを知っていることをシステムに伝え、この不一致を許容するようにします。 + +## 代替案 + +### ベアPod + +Podが実行されているノードが再起動したり障害が発生したりすると、Podは終了し、再起動されません。しかし、Jobは終了したPodを置き換えるために新しいPodを作成します。 +このため、アプリケーションが単一のPodしか必要としない場合でも、ベアPodではなくJobを使用することをお勧めします。 + +### レプリケーションコントローラー + +Jobは[レプリケーションコントローラー](/ja/docs/user-guide/replication-controller)を補完するものです。 +レプリケーションコントローラーは終了が予想されないPod(例えばWebサーバー)を管理し、Jobは終了が予想されるPod(例えばバッチタスク)を管理します。 + +[Podのライフサイクル](/ja/docs/concepts/workloads/pods/pod-lifecycle/)で説明したように、`Job`は`RestartPolicy`が`OnFailure`または`Never`と等しいPodに対して*のみ*適切です。 +(注意: `RestartPolicy`が設定されていない場合、デフォルト値は`Always`です。) + +### 単一のJobでコントローラーPodを起動 + +もう一つのパターンは、単一のJobでPodを作成し、そのPodが他のPodを作成し、それらのPodに対するカスタムコントローラーのように動作するというものです。これは最も柔軟性がありますが、始めるのがやや複雑で、Kubernetesとの統合性が低いかもしれません。 + +このパターンの例として、Podを起動してスクリプトを実行するJobがSparkマスターコントローラー([Sparkの例](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/staging/spark/README.md)を参照)を起動し、Sparkドライバーを実行してからクリーンアップするというものがあります。 + +このアプローチの利点は、全体的なプロセスがJobオブジェクトが完了する保証を得ながらも、どのようなPodが作成され、どのように作業が割り当てられるかを完全に制御できることです。 + +## Cron Job {#cron-jobs} + +Unixのツールである`cron`と同様に、指定した日時に実行されるJobを作成するために、[`CronJob`](/ja/docs/concepts/workloads/controllers/cron-jobs/)を使用することができます。 diff --git a/content/ja/docs/concepts/workloads/controllers/ttlafterfinished.md b/content/ja/docs/concepts/workloads/controllers/ttlafterfinished.md index e663d5b9c9..d1b1cc3354 100644 --- a/content/ja/docs/concepts/workloads/controllers/ttlafterfinished.md +++ b/content/ja/docs/concepts/workloads/controllers/ttlafterfinished.md @@ -29,7 +29,7 @@ TTLコントローラーは、そのリソースが終了したあと指定し TTL秒はいつでもセット可能です。下記はJobの`.spec.ttlSecondsAfterFinished`フィールドのセットに関するいくつかの例です。 * Jobがその終了後にいくつか時間がたった後に自動的にクリーンアップできるように、そのリソースマニフェストにこの値を指定します。 -* この新しい機能を適用させるために、存在していて既に終了したリソースに対してこのフィールドをセットします。 +* この新しい機能を適用させるために、存在していてすでに終了したリソースに対してこのフィールドをセットします。 * リソース作成時に、このフィールドを動的にセットするために、[管理webhookの変更](/docs/reference/access-authn-authz/extensible-admission-controllers/#admission-webhooks)をさせます。クラスター管理者は、終了したリソースに対して、このTTLポリシーを強制するために使うことができます。 * リソースが終了した後に、このフィールドを動的にセットしたり、リソースステータスやラベルなどの値に基づいて異なるTTL値を選択するために、[管理webhookの変更](/docs/reference/access-authn-authz/extensible-admission-controllers/#admission-webhooks)をさせます。 diff --git a/content/ja/docs/concepts/workloads/pods/init-containers.md b/content/ja/docs/concepts/workloads/pods/init-containers.md index 5d285b15d8..3486c55219 100644 --- a/content/ja/docs/concepts/workloads/pods/init-containers.md +++ b/content/ja/docs/concepts/workloads/pods/init-containers.md @@ -8,7 +8,7 @@ weight: 40 このページでは、Initコンテナについて概観します。Initコンテナとは、{{< glossary_tooltip text="Pod" term_id="pod" >}}内でアプリケーションコンテナの前に実行される特別なコンテナです。 Initコンテナにはアプリケーションコンテナのイメージに存在しないセットアップスクリプトやユーティリティーを含めることができます。 -Initコンテナは、Podの仕様のうち`containers`という配列（これがアプリケーションコンテナを示します）と並べて指定します。 +Initコンテナは、Podの仕様のうち`containers`という配列(これがアプリケーションコンテナを示します)と並べて指定します。 <!-- body --> ## Initコンテナを理解する {#understanding-init-containers} @@ -202,7 +202,7 @@ myapp-pod 1/1 Running 0 9m このシンプルな例を独自のInitコンテナを作成する際の参考にしてください。[次の項目](#what-s-next)にさらに詳細な使用例に関するリンクがあります。 -## Initコンテナのふるまいに関する詳細 {#Detailed behavior} +## Initコンテナのふるまいに関する詳細 {#detailed-behavior} Podの起動時において、各Initコンテナはネットワークとボリュームが初期化されたのちに順番に起動します。各Initコンテナは次のInitコンテナが起動する前に正常に終了しなくてはなりません。もしあるInitコンテナがランタイムもしくはエラーにより起動失敗した場合、そのPodの`restartPolicy`の値に従ってリトライされます。しかし、もしPodの`restartPolicy`が`Always`に設定されていた場合、Initコンテナの`restartPolicy`は`OnFailure`が適用されます。 @@ -213,7 +213,7 @@ Podは全てのInitコンテナが完了するまで`Ready`状態となりませ Initコンテナの仕様の変更は、コンテナイメージのフィールドのみに制限されています。 Initコンテナのイメージフィールド値を変更すると、そのPodは再起動されます。 -Initコンテナは何度も再起動およびリトライ可能なため、べき等（Idempotent）である必要があります。特に、`EmptyDirs`にファイルを書き込むコードは、書き込み先のファイルがすでに存在している可能性を考慮に入れる必要があります。 +Initコンテナは何度も再起動およびリトライ可能なため、べき等(Idempotent)である必要があります。特に、`EmptyDirs`にファイルを書き込むコードは、書き込み先のファイルがすでに存在している可能性を考慮に入れる必要があります。 Initコンテナはアプリケーションコンテナの全てのフィールドを持っています。しかしKubernetesは、Initコンテナが完了と異なる状態を定義できないため`readinessProbe`が使用されることを禁止しています。これはバリデーションの際に適用されます。 @@ -230,11 +230,11 @@ Initコンテナの順序と実行を考えるとき、リソースの使用に * リソースに対する全てのアプリケーションコンテナのリクエスト／リミットの合計 * リソースに対する有効なinitリクエスト／リミット * スケジューリングは有効なリクエスト／リミットに基づいて実行されます。つまり、InitコンテナはPodの生存中には使用されない初期化用のリソースを確保することができます。 -* Podの*有効なQos（quality of service）ティアー* は、Initコンテナとアプリケーションコンテナで同様です。 +* Podの*有効なQoS(quality of service)ティアー* は、Initコンテナとアプリケーションコンテナで同様です。 クォータとリミットは有効なPodリクエストとリミットに基づいて適用されます。 -Podレベルのコントロールグループ（cgroups）は、スケジューラーと同様に、有効なPodリクエストとリミットに基づいています。 +Podレベルのコントロールグループ(cgroups)は、スケジューラーと同様に、有効なPodリクエストとリミットに基づいています。 ### Podの再起動の理由 {#pod-restart-reasons} @@ -250,4 +250,3 @@ Podレベルのコントロールグループ（cgroups）は、スケジュー * [Initコンテナを含むPodの作成](/docs/tasks/configure-pod-container/configure-pod-initialization/#creating-a-pod-that-has-an-init-container)方法について学ぶ。 * [Initコンテナのデバッグ](/ja/docs/tasks/debug-application-cluster/debug-init-containers/)を行う方法について学ぶ。 - diff --git a/content/ja/docs/concepts/workloads/pods/pod-overview.md b/content/ja/docs/concepts/workloads/pods/pod-overview.md index 1917d6adf2..76e8f11a62 100644 --- a/content/ja/docs/concepts/workloads/pods/pod-overview.md +++ b/content/ja/docs/concepts/workloads/pods/pod-overview.md @@ -1,5 +1,5 @@ --- -title: Podについての概観(Pod Overview) +title: Podの概観 content_type: concept weight: 10 card: @@ -8,7 +8,7 @@ card: --- <!-- overview --> -このページでは、Kubernetesのオブジェクトモデルにおいて、デプロイ可能な最小単位のオブジェクトである`Pod`に関して概観します。 +このページでは、Kubernetesのオブジェクトモデルにおいて、デプロイ可能な最小単位のオブジェクトである`Pod`に関して説明します。 <!-- body --> @@ -62,7 +62,7 @@ Podは、Podによって構成されたコンテナ群のために2種類の共 ## Podを利用する ユーザーはまれに、Kubenetes内で独立したPodを直接作成する場合があります(シングルトンPodなど)。 -これはPodが比較的、一時的な使い捨てエンティティとしてデザインされているためです。Podが作成された時（ユーザーによって直接的、またはコントローラーによって間接的に作成された場合）、ユーザーのクラスター内の単一の{{< glossary_tooltip term_id="node" >}}上で稼働するようにスケジューリングされます。そのPodはプロセスが停止されたり、Podオブジェクトが削除されたり、Podがリソースの欠如のために*追い出され* たり、ノードが故障するまでノード上に残り続けます。 +これはPodが比較的、一時的な使い捨てエンティティとしてデザインされているためです。Podが作成された時(ユーザーによって直接的、またはコントローラーによって間接的に作成された場合)、ユーザーのクラスター内の単一の{{< glossary_tooltip term_id="node" >}}上で稼働するようにスケジューリングされます。そのPodはプロセスが停止されたり、Podオブジェクトが削除されたり、Podがリソースの欠如のために*追い出され* たり、ノードが故障するまでノード上に残り続けます。 {{< note >}} 単一のPod内でのコンテナを再起動することと、そのPodを再起動することを混同しないでください。Podはそれ自体は実行されませんが、コンテナが実行される環境であり、削除されるまで存在し続けます。 @@ -111,7 +111,7 @@ spec: ## {{% heading "whatsnext" %}} -* [Pod](/ja/docs/concepts/workloads/pods/pod/)について更に学びましょう +* [Pod](/ja/docs/concepts/workloads/pods/pod/)についてさらに学びましょう * Podの振る舞いに関して学ぶには下記を参照してください * [Podの停止](/ja/docs/concepts/workloads/pods/pod/#termination-of-pods) * [Podのライフサイクル](/ja/docs/concepts/workloads/pods/pod-lifecycle/) diff --git a/content/ja/docs/concepts/workloads/pods/pod.md b/content/ja/docs/concepts/workloads/pods/pod.md index e46e5cad9e..fbb003c21b 100644 --- a/content/ja/docs/concepts/workloads/pods/pod.md +++ b/content/ja/docs/concepts/workloads/pods/pod.md @@ -16,7 +16,7 @@ _Pod_ は、Kubernetesで作成および管理できる、デプロイ可能な ## Podとは -_Pod_ は（クジラの小群やエンドウ豆のさやのように）、共有のストレージ/ネットワークを持つ1つ以上のコンテナ（例えばDockerコンテナ）、およびコンテナを実行する方法についての仕様です。Pod内のコンテナ群は常に同じ場所に配置され、協調してスケジューリングされ、共通のコンテキストで実行されます。Podは、アプリケーション固有の「論理ホスト」――やや密に結合した1つ以上のアプリケーション・コンテナを含むもの――をモデル化します。コンテナ以前の世界では、同じ物理または仮想マシン上で実行されることが、同じ論理ホスト上で実行されることを意味するでしょう。 +_Pod_ は(クジラの小群やエンドウ豆のさやのように)、共有のストレージ/ネットワークを持つ1つ以上のコンテナ(例えばDockerコンテナ)、およびコンテナを実行する方法についての仕様です。Pod内のコンテナ群は常に同じ場所に配置され、協調してスケジューリングされ、共通のコンテキストで実行されます。Podは、アプリケーション固有の「論理ホスト」――やや密に結合した1つ以上のアプリケーション・コンテナを含むもの――をモデル化します。コンテナ以前の世界では、同じ物理または仮想マシン上で実行されることが、同じ論理ホスト上で実行されることを意味するでしょう。 Kubernetesは、Dockerだけでなくより多くのコンテナ・ランタイムをサポートしていますが、Dockerは最もよく知られているランタイムであり、Dockerの用語を使ってPodを説明することが可能です。 @@ -24,7 +24,7 @@ Pod内では、Linux namespaceやcgroupなどのDockerコンテナを分離す Podのコンテキスト内で、個々のアプリケーションに更なる分離が適用されることがあります。 Pod内のコンテナはIPアドレスとポートの空間を共有し、 `localhost` を通じてお互いを見つけることができます 。 -また、SystemVセマフォやPOSIX共有メモリなどの標準のプロセス間通信（IPC）を使用して互いに通信することもできます。 +また、SystemVセマフォやPOSIX共有メモリなどの標準のプロセス間通信(IPC)を使用して互いに通信することもできます。 異なるPodのコンテナは異なるIPアドレスを持ち、[特別な設定](/docs/concepts/policy/pod-security-policy/)がなければIPCでは通信できません。 これらのコンテナは通常、Pod IPアドレスを介して互いに通信します。 @@ -33,18 +33,18 @@ Pod内のアプリケーションからアクセスできる共有ボリュー [Docker](https://www.docker.com/)の用語でいえば、Podは共有namespaceと共有[ボリューム](/docs/concepts/storage/volumes/)を持つDockerコンテナのグループとしてモデル化されています。 -個々のアプリケーションコンテナと同様に、Podは（永続的ではなく）比較的短期間の存在と捉えられます。 -[Podのライフサイクル](/ja/docs/concepts/workloads/pods/pod-lifecycle/)で説明しているように、Podが作成されると、一意のID（UID）が割り当てられ、（再起動ポリシーに従って）終了または削除されるまでNodeで実行されるようにスケジュールされます。 +個々のアプリケーションコンテナと同様に、Podは(永続的ではなく)比較的短期間の存在と捉えられます。 +[Podのライフサイクル](/ja/docs/concepts/workloads/pods/pod-lifecycle/)で説明しているように、Podが作成されると、一意のID(UID)が割り当てられ、(再起動ポリシーに従って)終了または削除されるまでNodeで実行されるようにスケジュールされます。 Nodeが停止した場合、そのNodeにスケジュールされたPodは、タイムアウト時間の経過後に削除されます。 -特定のPod（UIDで定義）は新しいNodeに「再スケジュール」されません。 -代わりに、必要に応じて同じ名前で、新しいUIDを持つ同一のPodに置き換えることができます（詳細については[ReplicationController](/docs/concepts/workloads/controllers/replicationcontroller/)を参照してください）。 +特定のPod(UIDで定義)は新しいNodeに「再スケジュール」されません。 +代わりに、必要に応じて同じ名前で、新しいUIDを持つ同一のPodに置き換えることができます(詳細については[ReplicationController](/docs/concepts/workloads/controllers/replicationcontroller/)を参照してください)。 -ボリュームなど、Podと同じ存続期間を持つものがあると言われる場合、それは（そのUIDを持つ）Podが存在する限り存在することを意味します。 -そのPodが何らかの理由で削除された場合、たとえ同じ代替物が作成されたとしても、関連するもの（例えばボリューム）も同様に破壊されて再作成されます。 +ボリュームなど、Podと同じ存続期間を持つものがあると言われる場合、それは(そのUIDを持つ)Podが存在する限り存在することを意味します。 +そのPodが何らかの理由で削除された場合、たとえ同じ代替物が作成されたとしても、関連するもの(例えばボリューム)も同様に破壊されて再作成されます。 {{< figure src="/images/docs/pod.svg" title="Podの図" width="50%" >}} -*file puller（ファイル取得コンテナ）とWebサーバーを含むマルチコンテナのPod。コンテナ間の共有ストレージとして永続ボリュームを使用している。* +*file puller(ファイル取得コンテナ)とWebサーバーを含むマルチコンテナのPod。コンテナ間の共有ストレージとして永続ボリュームを使用している。* ## Podを用いる動機 @@ -53,13 +53,13 @@ Nodeが停止した場合、そのNodeにスケジュールされたPodは、タ Podは、まとまったサービスの単位を形成する複数の協調プロセスのパターンをモデル化したものです。 構成要素であるアプリケーションの集まりよりも高いレベルの抽象化を提供することによって、アプリケーションのデプロイと管理を単純化します。 Podは、デプロイや水平スケーリング、レプリケーションの単位として機能します。 -Pod内のコンテナに対しては、同じ場所への配置（共同スケジューリング）、命運の共有（つまり停止）、協調レプリケーション、リソース共有や依存関係の管理が自動的に取り扱われます。 +Pod内のコンテナに対しては、同じ場所への配置(共同スケジューリング)、命運の共有(つまり停止)、協調レプリケーション、リソース共有や依存関係の管理が自動的に取り扱われます。 ### リソース共有と通信 Podは、構成要素間でのデータ共有および通信を可能にします。 -Pod内のアプリケーションはすべて同じネットワーク名前空間（同じIPおよびポートスペース）を使用するため、 `localhost` としてお互いを「見つけて」通信できます。 +Pod内のアプリケーションはすべて同じネットワーク名前空間(同じIPおよびポートスペース)を使用するため、 `localhost` としてお互いを「見つけて」通信できます。 このため、Pod内のアプリケーションはそれぞれ使用するポートを調整する必要があります。 各Podは、他の物理コンピュータやPodと自由に通信するためのフラットな共有ネットワーク空間上にIPアドレスを持ちます。 @@ -71,7 +71,7 @@ Podで実行されるアプリケーションコンテナの定義に加えて ## Podの用途 -Podは、垂直に統合されたアプリケーションスタック（例：LAMP）をホストするために使用できます。 +Podは、垂直に統合されたアプリケーションスタック(例:LAMP)をホストするために使用できます。 しかし、Podを使う主な動機は、次のように同じ場所に配置され、共に管理されるヘルパープログラムをサポートすることです。 * コンテンツ管理システム(CMS)、ファイルやデータのローダー、ローカルのキャッシュマネージャーなど @@ -83,11 +83,11 @@ Podは、垂直に統合されたアプリケーションスタック（例：LA 個々のPodは、一般に、同じアプリケーションの複数のインスタンスを実行することを目的としていません。 詳細については、[The Distributed System ToolKit: Patterns for -Composite Containers](https://kubernetes.io/blog/2015/06/the-distributed-system-toolkit-patterns)（分散システムツールキット：複合コンテナのパターン）を参照してください。 +Composite Containers](https://kubernetes.io/blog/2015/06/the-distributed-system-toolkit-patterns)(分散システムツールキット：複合コンテナのパターン)を参照してください。 ## 考えられる代替案 -_単一の（Docker）コンテナで複数のプログラムを実行しないのはなぜですか？_ +_単一の(Docker)コンテナで複数のプログラムを実行しないのはなぜですか？_ 1. 透明性のため。Pod内のコンテナをインフラストラクチャから見えるようにすることで、インフラストラクチャはプロセス管理やリソース監視などのサービスをコンテナに提供できます。 これは、ユーザーに多くの便益を提供します。 @@ -97,13 +97,13 @@ Kubernetesはいつか個々のコンテナのライブアップデートをサ 1. 使いやすさのため。ユーザーは独自のプロセスマネージャーを実行する必要はありません。シグナルや終了コードの伝播などについて心配する必要はありません。 1. 効率のため。インフラストラクチャがより責任を負うため、コンテナはより軽量になります。 -_アフィニティ（結合性、親和性）ベースのコンテナの共同スケジューリングをサポートしないのはなぜですか？_ +_アフィニティ(結合性、親和性)ベースのコンテナの共同スケジューリングをサポートしないのはなぜですか？_ このアプローチによって、コンテナの共同配置は提供されるでしょう。 しかし、リソース共有やIPC、保証された命運の共有、および簡素化された管理といったPodの利点のほとんどは提供されないでしょう。 -## Podの耐久性（またはその欠如） +## Podの耐久性(またはその欠如) {#pod-durability} Podは、耐久性のある存在として扱われることを意図していません。 スケジューリングの失敗や、Nodeの故障には耐えられません。 @@ -128,7 +128,7 @@ Podは、以下のことを容易にするためにプリミティブとして ## Podの終了 {#termination-of-pods} -Podは、クラスター内のNodeで実行中のプロセスを表すため、不要になったときにそれらのプロセスを正常に終了できるようにすることが重要です（対照的なケースは、KILLシグナルで強制終了され、クリーンアップする機会がない場合）。 +Podは、クラスター内のNodeで実行中のプロセスを表すため、不要になったときにそれらのプロセスを正常に終了できるようにすることが重要です(対照的なケースは、KILLシグナルで強制終了され、クリーンアップする機会がない場合)。 ユーザーは削除を要求可能であるべきで、プロセスがいつ終了するかを知ることができなければなりませんが、削除が最終的に完了することも保証できるべきです。 ユーザーがPodの削除を要求すると、システムはPodが強制終了される前に意図された猶予期間を記録し、各コンテナのメインプロセスにTERMシグナルが送信されます。 猶予期間が終了すると、プロセスにKILLシグナルが送信され、PodはAPIサーバーから削除されます。 @@ -136,17 +136,17 @@ Podは、クラスター内のNodeで実行中のプロセスを表すため、 フローの例は下のようになります。 -1. ユーザーがデフォルトの猶予期間（30秒）でPodを削除するコマンドを送信する +1. ユーザーがデフォルトの猶予期間(30秒)でPodを削除するコマンドを送信する 1. APIサーバー内のPodは、猶予期間を越えるとPodが「死んでいる」と見なされるように更新される 1. クライアントのコマンドに表示されたとき、Podは「終了中」と表示される -1. （3と同時に）Kubeletは、2の期間が設定されたためにPodが終了中となったことを認識すると、Podのシャットダウン処理を開始する +1. (3と同時に)Kubeletは、2の期間が設定されたためにPodが終了中となったことを認識すると、Podのシャットダウン処理を開始する 1. Pod内のコンテナの1つが[preStopフック](/docs/concepts/containers/container-lifecycle-hooks/#hook-details)を定義している場合は、コンテナの内側で呼び出される。 - 猶予期間が終了した後も `preStop`フックがまだ実行されている場合は、一度だけ猶予期間を延長して（2秒）、ステップ2が呼び出される。`preStop`フックが完了するまでにより長い時間が必要な場合は、`terminationGracePeriodSeconds`を変更する必要がある。 + 猶予期間が終了した後も `preStop`フックがまだ実行されている場合は、一度だけ猶予期間を延長して(2秒)、ステップ2が呼び出される。`preStop`フックが完了するまでにより長い時間が必要な場合は、`terminationGracePeriodSeconds`を変更する必要がある。 1. コンテナにTERMシグナルが送信される。Pod内のすべてのコンテナが同時にTERMシグナルを受信するわけではなく、シャットダウンの順序が問題になる場合はそれぞれに `preStop` フックが必要になることがある -1. （3と同時に）Podはサービスを提供するエンドポイントのリストから削除され、ReplicationControllerの実行中のPodの一部とは見なされなくなる。 -ゆっくりとシャットダウンするPodは、（サービスプロキシのような）ロードバランサーがローテーションからそれらを削除するので、トラフィックを処理し続けることはできない +1. (3と同時に)Podはサービスを提供するエンドポイントのリストから削除され、ReplicationControllerの実行中のPodの一部とは見なされなくなる。 +ゆっくりとシャットダウンするPodは、(サービスプロキシのような)ロードバランサーがローテーションからそれらを削除するので、トラフィックを処理し続けることはできない 1. 猶予期間が終了すると、Pod内でまだ実行中のプロセスはSIGKILLで強制終了される -1. Kubeletは猶予期間を0（即時削除）に設定することでAPIサーバー上のPodの削除を終了する。 +1. Kubeletは猶予期間を0(即時削除)に設定することでAPIサーバー上のPodの削除を終了する。 PodはAPIから消え、クライアントからは見えなくなる デフォルトでは、すべての削除は30秒以内に正常に行われます。 @@ -186,5 +186,3 @@ spec.containers[0].securityContext.privileged: forbidden '<*>(0xc20b222db0)true' PodはKubernetes REST APIのトップレベルのリソースです。 APIオブジェクトの詳細については、[Pod APIオブジェクト](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#pod-v1-core)を参照してください 。 - - diff --git a/content/ja/docs/contribute/_index.md b/content/ja/docs/contribute/_index.md index 8491c85dc4..008b575e1a 100644 --- a/content/ja/docs/contribute/_index.md +++ b/content/ja/docs/contribute/_index.md @@ -32,7 +32,7 @@ Kubernetesのドキュメントは、GitHubのリポジトリーにあります ## 貢献するためのベストプラクティス - 明快で意味のあるGitコミットメッセージを書いてください。 -- PRがマージされたときにissueを参照し、自動的にissueをクローズする_Github Special Keywords_を必ず含めるようにしてください。 +- PRがマージされたときにissueを参照し、自動的にissueをクローズする _Github Special Keywords_ を必ず含めるようにしてください。 - タイプミスの修正や、スタイルの変更、文法の変更などのような小さな変更をPRに加える場合は、比較的小さな変更のためにコミットの数が増えすぎないように、コミットはまとめてください。 - あなたがコードを変更をした理由を示し、レビュアーがあなたのPRを理解するのに十分な情報を確保した適切なPR説明を、必ず含めるようにしてください。 - 追加文献 : diff --git a/content/ja/docs/contribute/localization.md b/content/ja/docs/contribute/localization.md index c9b1221b53..ab1639c294 100644 --- a/content/ja/docs/contribute/localization.md +++ b/content/ja/docs/contribute/localization.md @@ -9,272 +9,148 @@ card: <!-- overview --> -このページでは、ドキュメントを異なる言語に[翻訳](https://blog.mozilla.org/l10n/2011/12/14/i18n-vs-l10n-whats-the-diff/)する方法について紹介します。 +このページでは、Kubernetesドキュメントにおける日本語翻訳の方針について説明します。 <!-- body --> -## はじめる +## ドキュメントを日本語に翻訳するまでの流れ -コントリビューターが自分自身のプルリクエストを承認することはできないため、翻訳を始めるには、最低でも2人が必要です。 +翻訳を行うための基本的な流れについて説明します。不明点がある場合は[Kubernetes公式Slack](http://slack.kubernetes.io/)の`#kubernetes-docs-ja`チャンネルにてお気軽にご質問ください。 -すべての翻訳チームは、自分たちのリソースを継続的に自己管理しなければいけません。私たちはドキュメントを喜んでホストしますが、あなたの代わりに翻訳することはできないからです。 +### 前提知識 -### 2文字の言語コードを探す +翻訳作業は全て[GitHubのIssue](https://github.com/kubernetes/website/issues?q=is%3Aissue+is%3Aopen+label%3Alanguage%2Fja)によって管理されています。翻訳作業を行いたい場合は、Issueの一覧をまず最初にご確認ください。 -最初に、[ISO 639-1標準](https://www.loc.gov/standards/iso639-2/php/code_list.php)のドキュメントから、翻訳先の言語に対応する2文字の国コードを探してください。たとえば、韓国語の国コードは`ko`です。 +また、Kubernetes傘下のリポジトリでは`CLA`と呼ばれる同意書に署名しないと、Pull Requestをマージすることができません。詳しくは[英語のドキュメント](https://github.com/kubernetes/community/blob/master/CLA.md)や、[Qiitaに有志の方が書いてくださった日本語のまとめ](https://qiita.com/jlandowner/items/d14d9bc8797a62b65e67)をご覧ください。 -### リポジトリをフォーク・クローンする {#fork-and-clone-the-repo} +### 翻訳を始めるまで -初めに、[kubernetes/website](https://github.com/kubernetes/website)リポジトリの[自分用のフォークを作成](/docs/contribute/start/#improve-existing-content)します。 +#### 翻訳を希望するページのIssueが存在しない場合 -そして、フォークをクローンして、ディレクトリに`cd`します。 +1. [こちらのサンプル](https://github.com/kubernetes/website/issues/22340)に従う形でIssueを作成する +2. 自分自身を翻訳作業に割り当てたい場合は、Issueのメッセージまたはコメントに`/assign`と書く +3. [新規ページを翻訳する場合](#translate-new-page)のステップに進む -```shell -git clone https://github.com/<username>/website -cd website -``` +**不明点がある場合は[Kubernetes公式Slack](http://slack.kubernetes.io/)の`#kubernetes-docs-ja`チャンネルにてお気軽にご質問ください。** -### プルリクエストを開く +#### 翻訳を希望するページのIssueが存在する場合 -次に、`kubernetes/website`リポジトリに翻訳を追加するための[プルリクエスト(PR)を開きます](/docs/contribute/start/#submit-a-pull-request)。 +1. 自分自身を翻訳作業に割り当てるために、Issueのコメントに`/assign`と書く +2. [新規ページを翻訳する場合](#translate-new-page)のステップに進む -このPRが承認されるためには、[最低限必要なコンテンツ](#minimum-required-content)が含まれていなければなりません。 +### Pull Requestを送るまで -新しい翻訳を追加する例としては、[フランス語版ドキュメントを追加するPR](https://github.com/kubernetes/website/pull/12548)を参考にしてください。 +未翻訳ページの新規翻訳作業と既存ページの修正作業でそれぞれ手順が異なります。 -### Kubernetes GitHub organizationに参加する +既存ページへの追加修正については、後述の[マイルストーンについて](#milestones)に目を通すことをおすすめします。 -翻訳のPRを作ると、Kubernetes GitHub organizationのメンバーになることができます。チームの各個人は、それぞれ`kubernetes/org`リポジトリに[Organization Membership Request](https://github.com/kubernetes/org/issues/new/choose)を作成する必要があります。 +#### 新規ページを翻訳する場合の手順 {#translate-new-page} -### 翻訳チームをGitHubに追加する {#add-your-localization-team-in-github} +1. `kubernetes/website`リポジトリをフォークする +2. `master`から任意の名前でブランチを作成する +3. `content/en`のディレクトリから必要なファイルを`content/ja`にコピーし、翻訳する +4. `master`ブランチに向けてPull Requestを作成する -次に、Kubernetesの翻訳チームを[`sig-docs/teams.yaml`](https://github.com/kubernetes/org/blob/master/config/kubernetes/sig-docs/teams.yaml)に追加します。翻訳チームを追加する例として、[スペイン語の翻訳チーム](https://github.com/kubernetes/org/pull/685)を追加するPRを見てください。 +#### 既存のページの誤字脱字や古い記述を修正する場合の手順 -`@kubernetes/sig-docs-**-owners`のメンバーは、翻訳のディレクトリ`/content/**/`以下のコンテンツのみを変更するPRを承認できます。 +1. `kubernetes/website`リポジトリをフォークする +2. `dev-1.18-ja.1`(最新のマイルストーンブランチに適宜読み替えること)から任意の名前でブランチを作成し、該当箇所を編集する +3. `dev-1.18-ja.1`(最新のマイルストーンブランチに適宜読み替えること)ブランチに向けてPull Requestを作成する -各翻訳ごとに、新しいPRに対して`@kubernetes/sig-docs-**-reviews`チームがレビューに自動的にアサインされます。 +### マイルストーンについて {#milestones} -`@kubernetes/website-maintainers`のメンバーは、翻訳作業を調整するために新しい開発ブランチを作ることができます。 +翻訳作業を集中的に管理するために、日本語を含む複数の言語ではマイルストーンを採用しています。 -`@kubernetes/website-milestone-maintainers`のメンバーは、issueやPRにマイルストーンをアサインするために、`/milestone`[Prowコマンド](https://prow.k8s.io/command-help)が使用できます。 +各マイルストーンでは、 -### ワークフローを設定する {#configure-the-workflow} +- 最低要件のコンテンツの追加・更新(項目については[こちら](https://kubernetes.io/docs/contribute/localization/#translating-documents)を参照してください) +- バージョンに追従できていない翻訳済みコンテンツの更新 -次に、`kubernetes/test-infra`リポジトリに新しい翻訳用のGitHubラベルを追加します。ラベルを利用すると、issueやプルリクエストを特定の言語のものだけにフィルタできます。 +を行い、ドキュメントの全体的なメンテナンスを行っています。 -ラベルを追加する例としては、[イタリア語の言語ラベル](https://github.com/kubernetes/test-infra/pull/11316)を追加するPRを見てください。 +マイルストーンのバージョンはOwner権限を持つメンバーが管理するものとします。 -### コミュニティを見つける +## 翻訳スタイルガイド -Kubernetes SIG Docsに、新しく翻訳チームを作りたいという意思を知らせてください！[SIG Docs Slackチャンネル](https://kubernetes.slack.com/messages/C1J0BPD2M/)に参加してください。他の言語のメンバーが、翻訳を始めるのを喜んで助けてくれ、どんな疑問にも答えてくれます。 +### 基本方針 -`kubernetes/community`リポジトリ内で、翻訳用のSlackチャンネルを作ることもできます。Slackチャンネルを追加する例としては、[インドネシア語とポルトガル語用のチャンネルを追加する](https://github.com/kubernetes/community/pull/3605)ためのPRを見てください。 +- 本文を、敬体（ですます調）で統一 + - 特に、「〜になります」「〜となります」という表現は「〜です」の方が適切な場合が多いため注意 +- 句読点は「、」と「。」を使用 +- 漢字、ひらがな、カタカナは全角で表記 +- 数字とアルファベットは半角で表記 +- スペースと括弧 `()` 、コロン `:` は半角、それ以外の記号類は全角で表記 +- 英単語と日本語の間に半角スペースは不要 -## 最低限必要なコンテンツ {#minimum-required-content} +### 頻出単語 -### サイトの設定を修正する +英語 | 日本語 +--------- | --------- +cluster|クラスター +orchestrate(動詞)|オーケストレーションする +Persistent Volume|KubernetesリソースとしてのPersistentVolumeはママ表記、一般的な用語としての場合は、永続ボリューム +Deployment/Deploy|KubernetesリソースとしてのDeploymentはママ表記、一般的な用語としてのdeployの場合は、デプロイ +Addon/Add-on|アドオン +Quota|クォータ +For more information|さらなる情報(一時的) +prefix | プレフィックス +container | コンテナ +directory | ディレクトリ +binary | バイナリ +controller | コントローラー +opeartor | オペレーター +Aggregation Layer | アグリゲーションレイヤー +Issue | Issue (ママ表記) +Pull Request | Pull Request (ママ表記) +GitHub | GitHub (ママ表記) +registry | レジストリ +architecture | アーキテクチャ +secure | セキュア +stacked | 積層(例: stacked etcd clusterは積層etcdクラスター) +a set of ~ | ～の集合 -Kubernetesのウェブサイトでは、Hugoをウェブフレームワークとして使用しています。ウェブサイトのHugoの設定は、[`config.toml`](https://github.com/kubernetes/website/tree/master/config.toml)ファイルの中に書かれています。新しい翻訳をサポートするには、`config.toml`を修正する必要があります。 +### 備考 -`config.toml`の既存の`[languages]`ブロックの下に、新しい言語の設定ブロックを追加してください。たとえば、ドイツ語のブロックの場合、次のようになります。 +ServiceやDeploymentなどのKubernetesのAPIオブジェクトや技術仕様的な固有名詞は、無理に日本語訳せずそのまま書いてください。 -```toml -[languages.de] -title = "Kubernetes" -description = "Produktionsreife Container-Verwaltung" -languageName = "Deutsch" -contentDir = "content/de" -weight = 3 -``` +また、日本語では名詞を複数形にする意味はあまりないので、英語の名詞を利用する場合は原則として単数形で表現してください。 -ブロックの`weight`パラメーターの設定では、言語の一覧から最も数字の大きい番号を探し、その値に1を加えた値を指定してください。 +例: -Hugoの多言語サポートについての詳しい情報は、「[多言語モード](https://gohugo.io/content-management/multilingual/)」を参照してください。 +- Kubernetes Service +- Node +- Pod -### 新しい翻訳のディレクトリを追加する +外部サイトへの参照の記事タイトルは翻訳しましょう。(一時的) -[`content`](https://github.com/kubernetes/website/tree/master/content)フォルダーに、言語用のサブディレクトリを追加してください。2文字の言語コードが`de`であるドイツ語の場合、次のようにディレクトリを作ります。 +### 頻出表記（日本語） -```shell -mkdir content/de -``` +よくある表記 | あるべき形 +--------- | --------- +〜ので、〜から、〜だから| 〜のため 、〜ため +（あいうえお。）| （あいうえお）。 +〇,〇,〇|〇、〇、〇（※今回列挙はすべて読点で統一） -### Community Code of Conductを翻訳する +### 単語末尾に長音記号(「ー」)を付けるかどうか -あなたの言語のcode of conductを追加するために、PRを[`cncf/foundation`](https://github.com/cncf/foundation/tree/master/code-of-conduct-languages)リポジトリに対して開いてください。 +「サーバー」「ユーザー」など英単語をカタカナに訳すときに、末尾の「ー」を付けるかどうか。 -### 翻訳したREADMEを追加する +- 「r」「re」「y」などで終わる単語については、原則付ける +- 上の頻出語のように、別途まとめたものは例外とする -他の翻訳のコントリビューターをガイドするために、kubernetes/websiteのトップレベルに新しい[`README-**.md`](https://help.github.com/articles/about-readmes/)を追加してください。ここで、`**`は2文字の言語コードです。たとえば、ドイツ語のREADMEファイルは`README-de.md`です。 +参考: https://kubernetes.slack.com/archives/CAG2M83S8/p1554096635015200 辺りのやりとり -翻訳された`README-**.md`ファイルの中で、翻訳のコントリビューターにガイダンスを提供してください。`README.md`に含まれているのと同じ情報に加えて、以下の情報も追加してください。 +### cron jobの訳し方に関して -- 翻訳プロジェクトのための連絡先 -- 翻訳固有の情報 +混同を避けるため、cron jobはcronジョブと訳し、CronJobはリソース名としてのままにする。 +cron「の」ジョブは、「の」が続く事による解釈の難から基本的にはつけないものとする。 -翻訳されたREADMEを作成したら、メインの英語の`README.md`からそのファイルへのリンクを追加し、英語で連絡先情報も書いてください。GitHub ID、メールアドレス、[Slackチャンネル](https://slack.com)、その他の連絡手段を提供できます。翻訳されたCommunity Code of Conductへのリンクも必ず提供してください。 +### その他基本方針など -### OWNERSファイルを設定する - -翻訳にコントリビュートする各ユーザーのロールを設定するには、言語用のサブディレクトリの中に`OWNERS`ファイルを作成し、以下の項目を設定します。 - -- **レビュアー**: レビュアーのロールを持つkubernetesチームのリストです。この場合は、[GitHubで翻訳チームを追加](#add-your-localization-team-in-github)で作成した`sig-docs-**-reviews`チームです。 -- **承認者**: 承認者のロールを持つkubernetesチームのリストです。この場合は、[GitHubで翻訳チームを追加](#add-your-localization-team-in-github)で追加した`sig-docs-**-owners`チームです。 -- **ラベル**: PRに自動的に適用されるGitHub上のラベルのリストです。この場合は、[ワークフローを設定する](#configure-the-workflow)で作成した言語ラベルです。 - -`OWNERS`ファイルに関するより詳しい情報は、[go.k8s.io/owners](https://go.k8s.io/owners)を参照してください。 - -言語コードが`es`の[スペイン語のOWNERSファイル](https://git.k8s.io/website/content/es/OWNERS)は次のようになります。 - -```yaml -# See the OWNERS docs at https://go.k8s.io/owners - -# This is the localization project for Spanish. -# Teams and members are visible at https://github.com/orgs/kubernetes/teams. - -reviewers: -- sig-docs-es-reviews - -approvers: -- sig-docs-es-owners - -labels: -- language/es -``` - -特定の言語用の`OWNERS`ファイルを追加したら、[ルートの`OWNERS_ALIASES`](https://git.k8s.io/website/OWNERS_ALIASES)ファイルを、翻訳のための新しいKuerbetesチーム、`sig-docs-**-owners`および`sig-docs-**-reviews`で更新します。 - -各チームごとに、[翻訳チームをGitHubに追加する](#add-your-localization-team-in-github)でリクエストしたGitHubユーザーのリストをアルファベット順で追加してください。 - -```diff ---- a/OWNERS_ALIASES -+++ b/OWNERS_ALIASES -@@ -48,6 +48,14 @@ aliases: - - stewart-yu - - xiangpengzhao - - zhangxiaoyu-zidif -+ sig-docs-es-owners: # Admins for Spanish content -+ - alexbrand -+ - raelga -+ sig-docs-es-reviews: # PR reviews for Spanish content -+ - alexbrand -+ - electrocucaracha -+ - glo-pena -+ - raelga - sig-docs-fr-owners: # Admins for French content - - perriea - - remyleone -``` - -## コンテンツを翻訳する - -Kubernetesのドキュメントの *すべて* を翻訳するのは、非常に大きな作業です。小さく始めて、時間をかけて拡大していけば大丈夫です。 - -最低限、すべての翻訳には以下のコンテンツが必要です。 - -説明 | URL ------|----- -ホーム | [すべての見出しと小見出しのURL](/docs/home/) -セットアップ | [すべての見出しと小見出しのURL](/docs/setup/) -チュートリアル | [Kubernetes Basics](/docs/tutorials/kubernetes-basics/)、[Hello Minikube](/docs/tutorials/hello-minikube/) -サイト文字列 | [翻訳された新しいTOMLファイル内のすべてのサイト文字列](https://github.com/kubernetes/website/tree/master/i18n) - -翻訳されたドキュメントは、言語ごとに`content/**/`サブディレクトリに置き、英語のソースと同じURLパスに従うようにしなければいけません。たとえば、[Kubernetes Basics](/docs/tutorials/kubernetes-basics/)のチュートリアルをドイツ語に翻訳する準備をするには、次のように、`content/de/`フォルダ以下にサブディレクトリを作り、英語のソースをコピーします。 - -```shell -mkdir -p content/de/docs/tutorials -cp content/en/docs/tutorials/kubernetes-basics.md content/de/docs/tutorials/kubernetes-basics.md -``` - -翻訳ツールを使えば、翻訳のプロセスをスピードアップできます。たとえば、エディタによってはテキストを高速に翻訳してくれるプラグインがあります。 - -{{< caution >}} -機械生成された翻訳は、そのままでは最低限の品質基準を満たしません。基準を満たすためには、人間による十分なレビューが必要です。 -{{< /caution >}} - -文法と意味の正確さを保証するために、公開する前に翻訳チームのメンバーが機械生成されたすべての翻訳を注意深くレビューしなければいけません。 - -### ソースファイル - -翻訳は、最新のリリース{{< latest-version >}}の英語のファイルをベースにしなければなりません。 - -最新のリリースのソースファイルを見つけるには、次のように探してください。 - -1. Kubernetesのウェブサイトのリポジトリ https://github.com/kubernetes/website に移動する。 -2. 最新バージョンの`release-1.X`ブランチを選択する。 - -最新バージョンは{{< latest-version >}}であるため、最新のリリースブランチは[`{{< release-branch >}}`](https://github.com/kubernetes/website/tree/{{< release-branch >}})です。 - -### i18n/内のサイト文字列 - -翻訳には、[`i18n/en.toml`](https://github.com/kubernetes/website/blob/master/i18n/en.toml)の内容を新しい言語用のファイル内に含める必要があります。ドイツ語を例に取ると、ファイル名は`i18n/de.toml`です。 - -新しい翻訳ファイルを`i18n/`に追加します。たとえば、ドイツ語(`de`)であれば次のようになります。 - -```shell -cp i18n/en.toml i18n/de.toml -``` - -そして、各文字列の値を翻訳します。 - -```TOML -[docs_label_i_am] -other = "ICH BIN..." -``` - -サイト文字列を翻訳することで、サイト全体で使われるテキストや機能をカスタマイズできます。たとえば、各ページのフッターにある著作権のテキストなどです。 - -### 言語固有のスタイルガイドと用語集 - -一部の言語チームには、言語固有のスタイルガイドや用語集があります。たとえば、[韓国語の翻訳ガイド](/ko/docs/contribute/localization_ko/)を見てください。 - -## ブランチの戦略 - -翻訳プロジェクトは協力が非常に重要な活動のため、チームごとに共有の開発ブランチで作業することを推奨します。 - -開発ブランチ上で共同作業するためには、以下の手順を行います。 - -1. [@kubernetes/website-maintainers](https://github.com/orgs/kubernetes/teams/website-maintainers)のチームメンバーが https://github.com/kubernetes/website のソースブランチから開発ブランチを作る。 - - [`kubernetes/org`](https://github.com/kubernetes/org)リポジトリに[翻訳チームを追加](#add-your-localization-team-in-github)したとき、チームの承認者は`@kubernetes/website-maintainers`チームに参加します。 - - 次のようなブランチの命名規則に従うことを推奨します。 - - `dev-<ソースのバージョン>-<言語コード>.<チームのマイルストーン>` - - たとえば、ドイツ語の翻訳チームの承認者は、Kubernetes v1.12のソースブランチをベースに、k/websiteリポジトリから直接開発ブランチ`dev-1.12-de.1`を作ります。 - -2. 各コントリビューターが、開発ブランチをベースにフィーチャーブランチを作る。 - - たとえば、ドイツ語のコントリビューターは、`username:local-branch-name`から`kubernetes:dev-1.12-de.1`に対して、変更を含むプルリクエストを開きます。 - -3. 承認者がフィーチャーブランチをレビューして、開発ブランチにマージする。 - -4. 定期的に新しいプルリクエストを開いて承認することで、承認者が開発ブランチをソースブランチにマージする。プルリクエストを承認する前にコミットをsquashするようにしてください。 - -翻訳が完了するまで、1-4のステップを必要なだけ繰り返します。たとえば、ドイツ語のブランチは、`dev-1.12-de.2`、`dev-1.12-de.3`と続きます。 - -チームは、翻訳したコンテンツを元となったリリースブランチにマージする必要があります。たとえば、{{< release-branch >}}から作られた開発ブランチは、必ず{{< release-branch >}}にマージしなければなりません。 - -承認者は、ソースブランチを最新の状態に保ち、マージのコンフリクトを解決することで、開発ブランチをメンテナンスしなければなりません。開発ブランチが長く開いたままであるほど、一般により多くのメンテナンスが必要になります。そのため、非常に長い期間に渡って開発ブランチを維持するよりは、定期的に開発ブランチをマージして、新しいブランチを作ることを考えてください。 - -各チームマイルストーンの最初には、1つ前の開発ブランチと現在の開発ブランチの間のアップストリームの変更を比較するissueを開くと役に立ちます。 - -新しい開発ブランチを開いたりプルリクエストをマージできるのは承認者だけですが、新しい開発ブランチには誰でもプルリクエストを開くことができます。特別な許可は必要ありません。 - -フォークやリポジトリから直接行う作業についての詳しい情報は、「[リポジトリをフォーク・クローンする](#fork-and-clone-the-repo)」を読んでください。 +- 意訳と直訳で迷った場合は「直訳」で訳す +- 訳で難しい・わからないと感じたらSlackの#kubernetes-docs-jaでみんなに聞く +- できることを挙手制で、できないときは早めに報告 ## アップストリームのコントリビューター SIG Docsでは、英語のソースに対する[アップストリームへのコントリビュートや誤りの訂正](/docs/contribute/intermediate#localize-content)を歓迎しています。 - -## 既存の翻訳を助ける - -コンテンツの追加や改善により既存の翻訳を助けることもできます。翻訳のための[Slackチャンネル](https://kubernetes.slack.com/messages/C1J0BPD2M/)に参加して、助けとなるPRを開くことを始めましょう。 - -## {{% heading "whatsnext" %}} - -翻訳がワークフローと最小限のコンテンツの要件を満たしたら、SIG docsは次の作業を行います。 - -- ウェブサイト上で言語の選択を有効にする。 -- [Kubernetesブログ](https://kubernetes.io/blog/)を含む[Cloud Native Computing Foundation](https://www.cncf.io/about/)(CNCF)のチャンネルで、翻訳が利用できるようになったことを公表する。 diff --git a/content/ja/docs/home/_index.md b/content/ja/docs/home/_index.md index fda3c24817..7f8837ce60 100644 --- a/content/ja/docs/home/_index.md +++ b/content/ja/docs/home/_index.md @@ -18,7 +18,7 @@ menu: description: > Kubernetesは、コンテナ化されたアプリケーションの展開、スケーリング、また管理を自動化するためのオープンソースコンテナプラットフォームです。このオープンソースプロジェクトは、Cloud Native Computing Foundationによってホストされています。 overview: > - Kubernetesは、コンテナ化されたアプリケーションの展開、スケーリング、また管理を自動化するためのオープンソースコンテナプラットフォームです。このオープンソースプロジェクトは、Cloud Native Computing Foundationによってホストされています（<a href="https://www.cncf.io/about">CNCF</a>）。 + Kubernetesは、コンテナ化されたアプリケーションの展開、スケーリング、また管理を自動化するためのオープンソースコンテナプラットフォームです。このオープンソースプロジェクトは、Cloud Native Computing Foundationによってホストされています(<a href="https://www.cncf.io/about">CNCF</a>)。 cards: - name: concepts title: "基本を理解する" @@ -52,7 +52,7 @@ cards: button_path: /docs/reference - name: contribute title: "ドキュメントにコントリビュートする" - description: "プロジェクトに不慣れでも、長い間関わっていたとしても、誰でもコントリビュートすることが出来ます。" + description: "プロジェクトに不慣れでも、長い間関わっていたとしても、誰でもコントリビュートすることができます。" button: "ドキュメントにコントリビュートする" button_path: /docs/contribute - name: download diff --git a/content/ja/docs/home/supported-doc-versions.md b/content/ja/docs/home/supported-doc-versions.md index a4c9ac18ce..0ca6fcee64 100644 --- a/content/ja/docs/home/supported-doc-versions.md +++ b/content/ja/docs/home/supported-doc-versions.md @@ -9,7 +9,7 @@ card: <!-- overview --> -本ウェブサイトでは、現行版とその直前4バージョンのKubernetesドキュメントを含んでいます。 +本ウェブサイトには、現行版とその直前4バージョンのKubernetesドキュメントがあります。 @@ -17,8 +17,7 @@ card: ## 現行版 -現在のバージョンは -[{{< param "version" >}}](/). +現在のバージョンは[{{< param "version" >}}](/)です。 ## 以前のバージョン diff --git a/content/ja/docs/reference/access-authn-authz/authentication.md b/content/ja/docs/reference/access-authn-authz/authentication.md new file mode 100644 index 0000000000..297bcce9d0 --- /dev/null +++ b/content/ja/docs/reference/access-authn-authz/authentication.md @@ -0,0 +1,711 @@ +--- +title: 認証 +content_type: concept +weight: 10 +--- + +<!-- overview --> +このページでは、認証の概要について説明します。 + + +<!-- body --> +## Kubernetesにおけるユーザー + +すべてのKubernetesクラスターには、2種類のユーザーがあります。Kubernetesによって管理されるサービスアカウントと、通常のユーザーです。 + +通常のユーザーは外部の独立したサービスが管理することを想定しています。秘密鍵を配布する管理者、KeystoneやGoogle Accountsのようなユーザーストア、さらにはユーザー名とパスワードのリストを持つファイルなどです。この点において、_Kubernetesは通常のユーザーアカウントを表すオブジェクトを持ちません。_ APIコールを介して、通常のユーザーをクラスターに追加することはできません。 + +対照的に、サービスアカウントはKubernetes APIによって管理されるユーザーです。サービスアカウントは特定の名前空間にバインドされており、APIサーバーによって自動的に作成されるか、APIコールによって手動で作成されます。サービスアカウントは、`Secrets`として保存された資格情報の集合に紐付けられています。これをPodにマウントすることで、クラスター内のプロセスがKubernetes APIと通信できるようにします。 + +APIリクエストは、通常のユーザーかサービスアカウントに紐付けられているか、[匿名リクエスト](#anonymous-requests)として扱われます。つまり、ワークステーションで`kubectl`を入力する人間のユーザーから、ノード上の`kubelets`やコントロールプレーンのメンバーまで、クラスター内外の全てのプロセスは、APIサーバーへのリクエストを行う際に認証を行うか匿名ユーザーとして扱われる必要があります。 + +## 認証戦略 + +Kubernetesは、クライアント証明書、Bearerトークン、認証プロキシー、HTTP Basic認証を使い、認証プラグインを通してAPIリクエストを認証します。APIサーバーにHTTPリクエストが送信されると、プラグインは以下の属性をリクエストに関連付けようとします。 + +* ユーザー名: エンドユーザーを識別する文字列です。一般的にな値は、`kube-admin`や`jane@example.com`です。 +* UID: エンドユーザーを識別する文字列であり、ユーザー名よりも一貫性と一意性を持たせようとするものです。 +* グループ: 各要素がユーザーの役割を示すような意味を持つ文字列の集合です。`system:masters`や`devops-team`といった値が一般的です。 +* 追加フィールド: 認証者が有用と思われる追加情報を保持する文字列のリストに対する、文字列のマップです。 + +すべての値は認証システムに対して非透過であり、[認可機能](/docs/reference/access-authn-authz/authorization/)が解釈した場合にのみ意味を持ちます。 + + +一度に複数の認証方法を有効にすることができます。通常は、以下のように少なくとも2つの方法を使用するべきです。 + + - サービスアカウント用のサービスアカウントトークン + - ユーザー認証のための、少なくとも1つの他の方法 + +複数の認証モジュールが有効化されている場合、リクエストの認証に成功した最初のモジュールが、評価が簡略化します。APIサーバーは、認証の実行順序を保証しません。 + +`system:authenticated`グループには、すべての認証済みユーザーのグループのリストが含まれます。 + +他の認証プロトコル(LDAP、SAML、Kerberos、X509スキームなど)との統合は、[認証プロキシー](#authenticating-proxy)や[認証Webhook](#webhook-token-authentication)を使用して実施できます。 + + +### X509クライアント証明書 + +クライアント証明書認証は、APIサーバーに`--client-ca-file=SOMEFILE`オプションを渡すことで有効になります。参照されるファイルには、APIサーバーに提示されたクライアント証明書を検証するために使用する1つ以上の認証局が含まれている必要があります。クライアント証明書が提示され、検証された場合、サブジェクトのCommon Nameがリクエストのユーザー名として使用されます。Kubernetes1.4時点では、クライアント証明書は、証明書のOrganizationフィールドを使用して、ユーザーのグループメンバーシップを示すこともできます。あるユーザーに対して複数のグループメンバーシップを含めるには、証明書に複数のOrganizationフィールドを含めます。 + +例えば、証明書署名要求を生成するために、`openssl`コマンドラインツールを使用します。 + +``` bash +openssl req -new -key jbeda.pem -out jbeda-csr.pem -subj "/CN=jbeda/O=app1/O=app2" +``` + +これにより、"app1"と"app2"の2つのグループに属するユーザー名"jbeda"の証明書署名要求が作成されます。 + +クライアント証明書の生成方法については、[証明書の管理](/docs/concepts/cluster-administration/certificates/)を参照してください。 + +### 静的なトークンファイル + +コマンドラインで`--token-auth-file=SOMEFILE`オプションを指定すると、APIサーバーはファイルからBearerトークンを読み込みます。現在のところ、トークンの有効期限は無く、APIサーバーを再起動しない限りトークンのリストを変更することはできません。 + +トークンファイルは、トークン、ユーザー名、ユーザーUIDの少なくとも3つの列を持つcsvファイルで、その後にオプションでグループ名が付きます。 + +{{< note >}} +複数のグループがある場合はダブルクォートで囲む必要があります。 + +```conf +token,user,uid,"group1,group2,group3" +``` +{{< /note >}} + +#### リクエストにBearerトークンを含める {#putting-a-bearer-token-in-a-request} + +HTTPクライアントからBearerトークン認証を利用する場合、APIサーバーは`Bearer THETOKEN`という値を持つ`Authorization`ヘッダーを待ち受けます。Bearerトークンは、HTTPのエンコーディングとクォート機能を利用してHTTPヘッダーの値に入れることができる文字列でなければなりません。例えば、Bearerトークンが`31ada4fd-adec-460c-809a-9e56ceb75269`であれば、HTTPのヘッダを以下のようにします。 + +```http +Authorization: Bearer 31ada4fd-adec-460c-809a-9e56ceb75269 +``` + +### ブートストラップトークン + +{{< feature-state for_k8s_version="v1.18" state="stable" >}} + +新しいクラスタの効率的なブートストラップを可能にするために、Kubernetesには*ブートストラップトークン*と呼ばれる動的に管理されたBearerトークンタイプが含まれています。これらのトークンは、`kube-system`名前空間にSecretsとして格納され、動的に管理したり作成したりすることができます。コントローラーマネージャーには、TokenCleanerコントローラーが含まれており、ブートストラップトークンの有効期限が切れると削除します。 + +トークンの形式は`[a-z0-9]{6}.[a-z0-9]{16}`です。最初のコンポーネントはトークンIDであり、第2のコンポーネントはToken Secretです。以下のように、トークンをHTTPヘッダーに指定します。 + +```http +Authorization: Bearer 781292.db7bc3a58fc5f07e +``` + +APIサーバーの`--enable-bootstrap-token-auth`フラグで、Bootstrap Token Authenticatorを有効にする必要があります。TokenCleanerコントローラーを有効にするには、コントローラーマネージャーの`--controllers`フラグを使います。`--controllers=*,tokencleaner`のようにして行います。クラスターをブートストラップするために`kubeadm`を使用している場合は、`kubeadm`がこれを代行してくれます。 + +認証機能は`system:bootstrap:<Token ID>`という名前で認証します。これは`system:bootstrappers`グループに含まれます。名前とグループは意図的に制限されており、ユーザーがブートストラップ後にこれらのトークンを使わないようにしています。ユーザー名とグループは、クラスタのブートストラップをサポートする適切な認可ポリシーを作成するために使用され、`kubeadm`によって使用されます。 + +ブートストラップトークンの認証機能やコントローラーについての詳細な説明、`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つのフラグを取ります。 + +* `--service-account-key-file`: Bearerトークンに署名するためのPEMエンコードされた鍵を含むファイルです。指定しない場合は、APIサーバーのTLS秘密鍵が使われます。 +* `--service-account-lookup`: 有効にすると、APIから削除されたトークンは取り消されます。 + +サービスアカウントは通常、APIサーバーによって自動的に作成され、`ServiceAccount`[Admission Controller](/docs/reference/access-authn-authz/admission-controllers/)を介してクラスター内のPodに関連付けられます。Bearerトークンは、Podのよく知られた場所にマウントされ、これによりクラスター内のプロセスがAPIサーバー通信できるようになります。アカウントは`PodSpec`の`serviceAccountName`フィールドを使って、明示的にPodに関連付けることができます。 + +{{< note >}} +自動で行われるため、通常`serviceAccountName`は省略します。 +{{< /note >}} + +```yaml +apiVersion: apps/v1 # このapiVersionは、Kubernetes1.9時点で適切です +kind: Deployment +metadata: + name: nginx-deployment + namespace: default +spec: + replicas: 3 + template: + metadata: + # ... + spec: + serviceAccountName: bob-the-bot + containers: + - name: nginx + image: nginx:1.14.2 +``` + +サービスアカウントのBearerトークンは、クラスター外で使用するために完全に有効であり、Kubernetes APIと通信したい長期的なジョブのアイデンティティを作成するために使用することができます。サービスアカウントを手動で作成するには、単に`kubectl create serviceaccount (NAME)`コマンドを使用します。これにより、現在の名前空間にサービスアカウントと関連するSecretが作成されます。 + + +```bash +kubectl create serviceaccount jenkins +``` + +```none +serviceaccount "jenkins" created +``` + +以下のように、関連するSecretを確認できます。 + +```bash +kubectl get serviceaccounts jenkins -o yaml +``` + +```yaml +apiVersion: v1 +kind: ServiceAccount +metadata: + # ... +secrets: +- name: jenkins-token-1yvwg +``` + +作成されたSecretは、APIサーバーのパブリック認証局と署名されたJSON Web Token(JWT)を保持します。 + +```bash +kubectl get secret jenkins-token-1yvwg -o yaml +``` + +```yaml +apiVersion: v1 +data: + ca.crt: (base64でエンコードされたAPIサーバーの認証局) + namespace: ZGVmYXVsdA== + token: (base64でエンコードされたBearerトークン) +kind: Secret +metadata: + # ... +type: kubernetes.io/service-account-token +``` + +{{< note >}} +Secretは常にbase64でエンコードされるため、これらの値もbase64でエンコードされています。 +{{< /note >}} + +署名されたJWTは、与えられたサービスアカウントとして認証するためのBearerトークンとして使用できます。トークンをリクエストに含める方法については、[リクエストにBearerトークンを含める](#putting-a-bearer-token-in-a-request)を参照してください。通常、これらのSecretはAPIサーバーへのクラスタ内アクセス用にPodにマウントされますが、クラスター外からも使用することができます。 + +サービスアカウントは、ユーザー名`system:serviceaccount:(NAMESPACE):(SERVICEACCOUNT)`で認証され、グループ`system:serviceaccounts`と`system:serviceaccounts:(NAMESPACE)`に割り当てられます。 + +警告: サービスアカウントトークンはSecretに保持されているため、Secretにアクセスできるユーザーは誰でもサービスアカウントとして認証することができます。サービスアカウントに権限を付与したり、Secretの読み取り機能を付与したりする際には注意が必要です。 + +### OpenID Connectトークン +[OpenID Connect](https://openid.net/connect/)は、Azure Active Directory、Salesforce、Googleなど、いくつかのOAuth2プロバイダーでサポートされているOAuth2の一種です。 +このプロトコルのOAuth2の主な拡張機能は、[ID Token](https://openid.net/specs/openid-connect-core-1_0.html#IDToken)と呼ばれる、アクセストークンとアクセストークンと一緒に返される追加フィールドです。 +このトークンは、ユーザーの電子メールなどのよく知られたフィールドを持つJSON Web Token(JWT)であり、サーバーによって署名されています。トークンをリクエストに含める方法については、[リクエストにBearerトークンを含める](#putting-a-bearer-token-in-a-request)を参照してください。 + +![Kubernetes OpenID Connect Flow](/images/docs/admin/k8s_oidc_login.svg) + +1. IDプロバイダーにログインします +2. IDプロバイダーは、`access_token`、`id_token`、`refresh_token`を提供します +3. `kubectl`を使う場合は、`--token`フラグで`id_token`を使うか、`kubeconfig`に直接追加してください +4. `kubectl`は、`id_token`をAuthorizationと呼ばれるヘッダーでAPIサーバーに送ります +5. APIサーバーは、設定で指定された証明書と照合することで、JWT署名が有効であることを確認します +6. `id_token`の有効期限が切れていないことを確認します +7. ユーザーが認可されていることを確認します +8. 認可されると、APIサーバーは`kubectl`にレスポンスを返します +9. `kubectl`はユーザーにフィードバックを提供します + +自分が誰であるかを確認するために必要なデータはすべて`id_token`の中にあるので、KubernetesはIDプロバイダーと通信する必要がありません。すべてのリクエストがステートレスであるモデルでは、これは非常に認証のためのスケーラブルなソリューションを提供します。一方で、以下のようにいくつか課題があります。 + +1. Kubernetesには、認証プロセスを起動するための"Webインターフェース"がありません。クレデンシャルを収集するためのブラウザやインターフェースがないため、まずIDプロバイダに認証を行う必要があります。 +2. `id_token`は、取り消すことができません。これは証明書のようなもので、有効期限が短い(数分のみ)必要があるので、数分ごとに新しいトークンを取得しなければならないのは非常に面倒です。 +3. Kubernetesダッシュボードへの認証において、`kubectl proxy`コマンドや`id_token`を注入するリバースプロキシーを使う以外に、簡単な方法はありません。 + + +#### APIサーバーの設定 + +プラグインを有効にするには、APIサーバーで以下のフラグを設定します。 + +| パラメーター | 説明 | 例 | 必須か | +| --------- | ----------- | ------- | ------- | +| `--oidc-issuer-url` | APIサーバーが公開署名鍵を発見できるようにするプロバイダーのURLです。 `https://`スキームを使用するURLのみが受け入れられます。これは通常、"https://accounts.google.com"や"https://login.salesforce.com"のようにパスを持たないプロバイダのディスカバリーURLです。このURLは、`.well-known/openid-configuration`の下のレベルを指す必要があります。 | ディスカバリーURLが`https://accounts.google.com/.well-known/openid-configuration`である場合、値は`https://accounts.google.com`とします。 | はい | +| `--oidc-client-id` | すべてのトークンが発行されなければならないクライアントIDです。 | kubernetes | はい | +| `--oidc-username-claim` | ユーザー名として使用するJWTのクレームを指定します。デフォルトでは`sub`が使用されますが、これはエンドユーザーの一意の識別子であることが期待されます。管理者はプロバイダーに応じて`email`や`name`などの他のクレームを選択することができます。ただし、他のプラグインとの名前の衝突を防ぐために、`email`以外のクレームには、プレフィックスとして発行者のURLが付けられます。 | sub | いいえ | +| `--oidc-username-prefix` | 既存の名前(`system:`ユーザーなど)との衝突を防ぐために、ユーザー名の前にプレフィックスを付加します。例えば`oidc:`という値は、`oidc:jane.doe`のようなユーザー名を生成します。このフラグが指定されておらず、`--oidc-username-claim`が`email`以外の値である場合、プレフィックスのデフォルトは`(Issuer URL)#`で、`(Issuer URL)`は`--oidc-issuer-url`の値です。すべてのプレフィックスを無効にするためには、`-`という値を使用できます。 | `oidc:` | いいえ | +| `--oidc-groups-claim` | ユーザーのグループとして使用するJWTのクレームです。クレームがある場合は、文字列の配列である必要があります。 | groups | いいえ | +| `--oidc-groups-prefix` | 既存の名前(`system:`グループなど)との衝突を防ぐために、グループ名の前にプレフィックスを付加します。例えば`oidc:`という値は、`oidc:engineering`や`oidc:infra`のようなグループ名を生成します。 | `oidc:` | いいえ | +| `--oidc-required-claim` | IDトークンの中の必須クレームを記述するkey=valueのペアです。設定されている場合、クレームが一致する値でIDトークンに存在することが検証されます。このフラグを繰り返して複数のクレームを指定します。 | `claim=value` | いいえ | +| `--oidc-ca-file` | IDプロバイダーのWeb証明書に署名した認証局の証明書へのパスです。デフォルトはホストのルート認証局が指定されます。 | `/etc/kubernetes/ssl/kc-ca.pem` | いいえ | + +重要なのは、APIサーバーはOAuth2クライアントではなく、ある単一の発行者を信頼するようにしか設定できないことです。これにより、サードパーティーに発行されたクレデンシャルを信頼せずに、Googleのようなパブリックプロバイダーを使用することができます。複数のOAuthクライアントを利用したい管理者は、`azp`クレームをサポートしているプロバイダや、あるクライアントが別のクライアントに代わってトークンを発行できるような仕組みを検討する必要があります。 + +KubernetesはOpenID Connect IDプロバイダーを提供していません。既存のパブリックなOpenID Connect IDプロバイダー(Googleや[その他](http://connect2id.com/products/nimbus-oauth-openid-connect-sdk/openid-connect-providers)など)を使用できます。もしくは、CoreOS [dex](https://github.com/coreos/dex)、[Keycloak](https://github.com/keycloak/keycloak)、CloudFoundry[UAA](https://github.com/cloudfoundry/uaa)、Tremolo Securityの[OpenUnison](https://github.com/tremolosecurity/openunison)など、独自のIDプロバイダーを実行することもできます。 + +IDプロバイダーがKubernetesと連携するためには、以下のことが必要です。 + +1. すべてではないが、[OpenID Connect Discovery](https://openid.net/specs/openid-connect-discovery-1_0.html）をサポートしていること +2. 廃れていない暗号を用いたTLSで実行されていること +3. 認証局が署名した証明書を持っていること(認証局が商用ではない場合や、自己署名の場合も可) + +上述の要件#3、認証局署名付き証明書を必要とすることについて、注意事項があります。GoogleやMicrosoftなどのクラウドプロバイダーではなく、独自のIDプロバイダーをデプロイする場合は、たとえ自己署名されていても、`CA`フラグが`TRUE`に設定されている証明書によって署名されたIDプロバイダーのWebサーバー証明書を持っていなければなりません。これは、Go言語のTLSクライアント実装が、証明書検証に関する標準に対して非常に厳格であるためです。認証局をお持ちでない場合は、CoreOSチームの[このスクリプト](https://github.com/coreos/dex/blob/1ee5920c54f5926d6468d2607c728b71cfe98092/examples/k8s/gencert.sh)を使用して、シンプルな認証局と署名付きの証明書と鍵のペアを作成することができます。 +または、[この類似のスクリプト](https://raw.githubusercontent.com/TremoloSecurity/openunison-qs-kubernetes/master/src/main/bash/makessl.sh)を使って、より寿命が長く、よりキーサイズの大きいSHA256証明書を生成できます。 + +特定のシステム用のセットアップ手順は、以下を参照してください。 + +- [UAA](https://docs.cloudfoundry.org/concepts/architecture/uaa.html) +- [Dex](https://github.com/dexidp/dex/blob/master/Documentation/kubernetes.md) +- [OpenUnison](https://www.tremolosecurity.com/orchestra-k8s/) + +#### kubectlの使用 + +##### 選択肢1 - OIDC認証機能 + +最初の選択肢は、kubectlの`oidc`認証機能を利用することです。これはすべてのリクエストのBearerトークンとして`id_token`を設定し、有効期限が切れるとトークンを更新します。プロバイダーにログインした後、kubectlを使って`id_token`、`refresh_token`、`client_id`、`client_secret`を追加してプラグインを設定します。 + +リフレッシュトークンのレスポンスの一部として`id_token`を返さないプロバイダーは、このプラグインではサポートされていないので、以下の"選択肢2"を使用してください。 + +```bash +kubectl config set-credentials USER_NAME \ + --auth-provider=oidc \ + --auth-provider-arg=idp-issuer-url=( issuer url ) \ + --auth-provider-arg=client-id=( your client id ) \ + --auth-provider-arg=client-secret=( your client secret ) \ + --auth-provider-arg=refresh-token=( your refresh token ) \ + --auth-provider-arg=idp-certificate-authority=( path to your ca certificate ) \ + --auth-provider-arg=id-token=( your id_token ) +``` + +例として、IDプロバイダーに認証した後に以下のコマンドを実行します。 + +```bash +kubectl config set-credentials mmosley \ + --auth-provider=oidc \ + --auth-provider-arg=idp-issuer-url=https://oidcidp.tremolo.lan:8443/auth/idp/OidcIdP \ + --auth-provider-arg=client-id=kubernetes \ + --auth-provider-arg=client-secret=1db158f6-177d-4d9c-8a8b-d36869918ec5 \ + --auth-provider-arg=refresh-token=q1bKLFOyUiosTfawzA93TzZIDzH2TNa2SMm0zEiPKTUwME6BkEo6Sql5yUWVBSWpKUGphaWpxSVAfekBOZbBhaEW+VlFUeVRGcluyVF5JT4+haZmPsluFoFu5XkpXk5BXqHega4GAXlF+ma+vmYpFcHe5eZR+slBFpZKtQA= \ + --auth-provider-arg=idp-certificate-authority=/root/ca.pem \ + --auth-provider-arg=id-token=eyJraWQiOiJDTj1vaWRjaWRwLnRyZW1vbG8ubGFuLCBPVT1EZW1vLCBPPVRybWVvbG8gU2VjdXJpdHksIEw9QXJsaW5ndG9uLCBTVD1WaXJnaW5pYSwgQz1VUy1DTj1rdWJlLWNhLTEyMDIxNDc5MjEwMzYwNzMyMTUyIiwiYWxnIjoiUlMyNTYifQ.eyJpc3MiOiJodHRwczovL29pZGNpZHAudHJlbW9sby5sYW46ODQ0My9hdXRoL2lkcC9PaWRjSWRQIiwiYXVkIjoia3ViZXJuZXRlcyIsImV4cCI6MTQ4MzU0OTUxMSwianRpIjoiMm96US15TXdFcHV4WDlHZUhQdy1hZyIsImlhdCI6MTQ4MzU0OTQ1MSwibmJmIjoxNDgzNTQ5MzMxLCJzdWIiOiI0YWViMzdiYS1iNjQ1LTQ4ZmQtYWIzMC0xYTAxZWU0MWUyMTgifQ.w6p4J_6qQ1HzTG9nrEOrubxIMb9K5hzcMPxc9IxPx2K4xO9l-oFiUw93daH3m5pluP6K7eOE6txBuRVfEcpJSwlelsOsW8gb8VJcnzMS9EnZpeA0tW_p-mnkFc3VcfyXuhe5R3G7aa5d8uHv70yJ9Y3-UhjiN9EhpMdfPAoEB9fYKKkJRzF7utTTIPGrSaSU6d2pcpfYKaxIwePzEkT4DfcQthoZdy9ucNvvLoi1DIC-UocFD8HLs8LYKEqSxQvOcvnThbObJ9af71EwmuE21fO5KzMW20KtAeget1gnldOosPtz1G5EwvaQ401-RPQzPGMVBld0_zMCAwZttJ4knw +``` + +これは以下のような構成になります。 + +```yaml +users: +- name: mmosley + user: + auth-provider: + config: + client-id: kubernetes + client-secret: 1db158f6-177d-4d9c-8a8b-d36869918ec5 + id-token: eyJraWQiOiJDTj1vaWRjaWRwLnRyZW1vbG8ubGFuLCBPVT1EZW1vLCBPPVRybWVvbG8gU2VjdXJpdHksIEw9QXJsaW5ndG9uLCBTVD1WaXJnaW5pYSwgQz1VUy1DTj1rdWJlLWNhLTEyMDIxNDc5MjEwMzYwNzMyMTUyIiwiYWxnIjoiUlMyNTYifQ.eyJpc3MiOiJodHRwczovL29pZGNpZHAudHJlbW9sby5sYW46ODQ0My9hdXRoL2lkcC9PaWRjSWRQIiwiYXVkIjoia3ViZXJuZXRlcyIsImV4cCI6MTQ4MzU0OTUxMSwianRpIjoiMm96US15TXdFcHV4WDlHZUhQdy1hZyIsImlhdCI6MTQ4MzU0OTQ1MSwibmJmIjoxNDgzNTQ5MzMxLCJzdWIiOiI0YWViMzdiYS1iNjQ1LTQ4ZmQtYWIzMC0xYTAxZWU0MWUyMTgifQ.w6p4J_6qQ1HzTG9nrEOrubxIMb9K5hzcMPxc9IxPx2K4xO9l-oFiUw93daH3m5pluP6K7eOE6txBuRVfEcpJSwlelsOsW8gb8VJcnzMS9EnZpeA0tW_p-mnkFc3VcfyXuhe5R3G7aa5d8uHv70yJ9Y3-UhjiN9EhpMdfPAoEB9fYKKkJRzF7utTTIPGrSaSU6d2pcpfYKaxIwePzEkT4DfcQthoZdy9ucNvvLoi1DIC-UocFD8HLs8LYKEqSxQvOcvnThbObJ9af71EwmuE21fO5KzMW20KtAeget1gnldOosPtz1G5EwvaQ401-RPQzPGMVBld0_zMCAwZttJ4knw + idp-certificate-authority: /root/ca.pem + idp-issuer-url: https://oidcidp.tremolo.lan:8443/auth/idp/OidcIdP + refresh-token: q1bKLFOyUiosTfawzA93TzZIDzH2TNa2SMm0zEiPKTUwME6BkEo6Sql5yUWVBSWpKUGphaWpxSVAfekBOZbBhaEW+VlFUeVRGcluyVF5JT4+haZmPsluFoFu5XkpXk5BXq + name: oidc +``` +`id_token`の有効期限が切れると、`kubectl`は`refresh_token`と`client_secret`を用いて`id_token`の更新しようとします。`refresh_token`と`id_token`の新しい値は、`.kube/config`に格納されます。 + +##### 選択肢2 - `--token`オプションの使用 + +`kubectl`コマンドでは、`--token`オプションを使ってトークンを渡すことができる。以下のように、このオプションに`id_token`をコピーして貼り付けるだけです。 + +```bash +kubectl --token=eyJhbGciOiJSUzI1NiJ9.eyJpc3MiOiJodHRwczovL21sYi50cmVtb2xvLmxhbjo4MDQzL2F1dGgvaWRwL29pZGMiLCJhdWQiOiJrdWJlcm5ldGVzIiwiZXhwIjoxNDc0NTk2NjY5LCJqdGkiOiI2RDUzNXoxUEpFNjJOR3QxaWVyYm9RIiwiaWF0IjoxNDc0NTk2MzY5LCJuYmYiOjE0NzQ1OTYyNDksInN1YiI6Im13aW5kdSIsInVzZXJfcm9sZSI6WyJ1c2VycyIsIm5ldy1uYW1lc3BhY2Utdmlld2VyIl0sImVtYWlsIjoibXdpbmR1QG5vbW9yZWplZGkuY29tIn0.f2As579n9VNoaKzoF-dOQGmXkFKf1FMyNV0-va_B63jn-_n9LGSCca_6IVMP8pO-Zb4KvRqGyTP0r3HkHxYy5c81AnIh8ijarruczl-TK_yF5akjSTHFZD-0gRzlevBDiH8Q79NAr-ky0P4iIXS8lY9Vnjch5MF74Zx0c3alKJHJUnnpjIACByfF2SCaYzbWFMUNat-K1PaUk5-ujMBG7yYnr95xD-63n8CO8teGUAAEMx6zRjzfhnhbzX-ajwZLGwGUBT4WqjMs70-6a7_8gZmLZb2az1cZynkFRj2BaCkVT3A2RrjeEwZEtGXlMqKJ1_I2ulrOVsYx01_yD35-rw get nodes +``` + + +### Webhookトークン認証 {#webhook-token-authentication} + +Webhook認証は、Bearerトークンを検証するためのフックです。 + +* `--authentication-token-webhook-config-file`: リモートのWebhookサービスへのアクセス方法を記述した設定ファイルです +* `--authentication-token-webhook-cache-ttl`: 認証をキャッシュする時間を決定します。デフォルトは2分です + +設定ファイルは、[kubeconfig](/docs/concepts/cluster-administration/authenticate-across-clusters-kubeconfig/)のファイル形式を使用します。 +ファイル内で、`clusters`はリモートサービスを、`users`はAPIサーバーのWebhookを指します。例えば、以下のようになります。 + +```yaml +# Kubernetes APIのバージョン +apiVersion: v1 +# APIオブジェクトの種類 +kind: Config +# clustersは、リモートサービスを指します。 +clusters: + - name: name-of-remote-authn-service + cluster: + certificate-authority: /path/to/ca.pem # リモートサービスを検証するためのCA + server: https://authn.example.com/authenticate # クエリするリモートサービスのURL。'https'を使用する必要があります。 + +# usersは、APIサーバーのWebhook設定を指します。 +users: + - name: name-of-api-server + user: + client-certificate: /path/to/cert.pem # Webhookプラグインを使うための証明書 + client-key: /path/to/key.pem # 証明書に合致する鍵 + +# kubeconfigファイルにはコンテキストが必要です。APIサーバー用のものを用意してください。 +current-context: webhook +contexts: +- context: + cluster: name-of-remote-authn-service + user: name-of-api-sever + name: webhook +``` + +クライアントが[上記](#putting-a-bearer-token-in-a-request)のようにBearerトークンを使用してAPIサーバーとの認証を試みた場合、認証Webhookはトークンを含むJSONでシリアライズされた`authentication.k8s.io/v1beta1` `TokenReview`オブジェクトをリモートサービスにPOSTします。Kubernetesはそのようなヘッダーが不足しているリクエストを作成しようとはしません。 + +Webhook APIオブジェクトは、他のKubernetes APIオブジェクトと同じように、[Versioning Compatibility Rule](/docs/concepts/overview/kubernetes-api/)に従うことに注意してください。実装者は、ベータオブジェクトで保証される互換性が緩いことに注意し、正しいデシリアライゼーションが使用されるようにリクエストの"apiVersion"フィールドを確認する必要があります。さらにAPIサーバーは、API拡張グループ`authentication.k8s.io/v1beta1`を有効にしなければなりません(`--runtime config=authentication.k8s.io/v1beta1=true`)。 + +POSTボディは、以下の形式になります。 + +```json +{ + "apiVersion": "authentication.k8s.io/v1beta1", + "kind": "TokenReview", + "spec": { + "token": "(Bearerトークン)" + } +} +``` + +リモートサービスはログインの成功を示すために、リクエストの`status`フィールドを埋めることが期待されます。レスポンスボディの`spec`フィールドは無視され、省略することができます。Bearerトークンの検証に成功すると、以下のようにBearerトークンが返されます。 + +```json +{ + "apiVersion": "authentication.k8s.io/v1beta1", + "kind": "TokenReview", + "status": { + "authenticated": true, + "user": { + "username": "janedoe@example.com", + "uid": "42", + "groups": [ + "developers", + "qa" + ], + "extra": { + "extrafield1": [ + "extravalue1", + "extravalue2" + ] + } + } + } +} +``` + +リクエストに失敗した場合は、以下のように返されます。 + +```json +{ + "apiVersion": "authentication.k8s.io/v1beta1", + "kind": "TokenReview", + "status": { + "authenticated": false + } +} +``` + +HTTPステータスコードは、追加のエラーコンテキストを提供するために使うことができます。 + + +### 認証プロキシー {#authenticating-proxy} + +APIサーバーは、`X-Remote-User`のようにリクエストヘッダの値からユーザーを識別するように設定することができます。 +これは、リクエストヘッダの値を設定する認証プロキシーと組み合わせて使用するために設計です。 + +* `--requestheader-username-headers`: 必須であり、大文字小文字を区別しません。ユーザーのIDをチェックするためのヘッダー名を順番に指定します。値を含む最初のヘッダーが、ユーザー名として使われます。 +* `--requestheader-group-headers`: バージョン1.6以降で任意であり、大文字小文字を区別しません。"X-Remote-Group"を推奨します。ユーザーのグループをチェックするためのヘッダー名を順番に指定します。指定されたヘッダーの全ての値が、グループ名として使われます。 +* `--requestheader-extra-headers-prefix` バージョン1.6以降で任意であり、大文字小文字を区別しません。"X-Remote-Extra-"を推奨します。ユーザーに関する追加情報を判断するために検索するヘッダーのプレフィックスです。通常、設定された認可プラグインによって使用されます。指定されたプレフィックスのいずれかで始まるヘッダーは、プレフィックスが削除されます。ヘッダー名の残りの部分は小文字化され[パーセントデコーディング](https://tools.ietf.org/html/rfc3986#section-2.1)されて追加のキーとなり、ヘッダーの値が追加の値となります。 + +{{< note >}} +1.11.3(および1.10.7、1.9.11)よりも前のバージョンでは、追加のキーには[HTTPヘッダーラベルで使用可能な文字](https://tools.ietf.org/html/rfc7230#section-3.2.6)のみを含めることができました。 +{{< /note >}} + +例えば、このような設定を行います。 + +``` +--requestheader-username-headers=X-Remote-User +--requestheader-group-headers=X-Remote-Group +--requestheader-extra-headers-prefix=X-Remote-Extra- +``` + +以下のようなリクエストを考えます。 + +```http +GET / HTTP/1.1 +X-Remote-User: fido +X-Remote-Group: dogs +X-Remote-Group: dachshunds +X-Remote-Extra-Acme.com%2Fproject: some-project +X-Remote-Extra-Scopes: openid +X-Remote-Extra-Scopes: profile +``` + +このリクエストは、このユーザー情報を取得します。 + +```yaml +name: fido +groups: +- dogs +- dachshunds +extra: + acme.com/project: + - some-project + scopes: + - openid + - profile +``` + +ヘッダーのスプーフィングを防ぐため、認証プロキシーはリクエストヘッダーがチェックされる前に、指定された認証局に対する検証のために有効なクライアント証明書をAPIサーバーへ提示する必要があります。 + + +* `--requestheader-client-ca-file`: 必須です。PEMエンコードされた証明書バンドルです。有効なクライアント証明書を提示し、リクエストヘッダーでユーザー名がチェックされる前に、指定されたファイル内の認証局に対して検証する必要があります。 +* `--requestheader-allowed-names`: 任意です。Common Name(CN)の値のリストです。設定されている場合、リクエストヘッダーでユーザー名がチェックされる前に、指定されたリストのCNを持つ有効なクライアント証明書を提示する必要があります。空の場合は、任意のCNが許可されます。 + + +## 匿名リクエスト {#anonymous-requests} + +この機能を有効にすると、他の設定された認証方法で拒否されなかったリクエストは匿名リクエストとして扱われ、 `system:anonymous`というユーザー名と`system:unauthenticated`というグループが与えられます。 + +例えば、トークン認証が設定されており、匿名アクセスが有効になっているサーバー上で、無効なBearerトークンを提供するリクエストは`401 Unauthorized`エラーを受け取ります。Bearerトークンを提供しないリクエストは匿名リクエストとして扱われます。 + +バージョン1.5.1から1.5.xでは、匿名アクセスはデフォルトでは無効になっており、APIサーバーに `--anonymous-auth=true`オプションを渡すことで有効にすることができます。 + +バージョン1.6以降では、`AlwaysAllow`以外の認証モードが使用されている場合、匿名アクセスがデフォルトで有効であり、`--anonymous-auth=false`オプションをAPIサーバーに渡すことで無効にできます。 +1.6以降、ABACおよびRBAC認可機能は、`system:anonymous`ユーザーまたは`system:unauthenticated`グループの明示的な認証を必要とするようになったため、`*`ユーザーまたは`*`グループへのアクセスを許可する従来のポリシールールには匿名ユーザーは含まれません。 + +## ユーザーの偽装 + +ユーザーは偽装ヘッダーを使って別のユーザーとして振る舞うことができます。これにより、リクエストが認証したユーザー情報を手動で上書きすることが可能です。例えば、管理者はこの機能を使って一時的に別のユーザーに偽装、リクエストが拒否されたかどうかを確認することで認可ポリシーをデバッグすることができます。 + +偽装リクエストは最初にリクエスト中のユーザーとして認証を行い、次に偽装ユーザー情報に切り替えます。 + +* ユーザーは、認証情報と偽装ヘッダーを使ってAPIコールを行います。 +* APIサーバーはユーザーを認証します。 +* APIサーバーは、認証されたユーザーが偽装した権限を持っていることを確認します。 +* リクエストされたユーザー情報は、偽装した値に置き換えられます。 +* リクエストが評価され、認可は偽装されたユーザー情報に基づいて実行されます。 + +偽装リクエストを実行する際には、以下のHTTPヘッダを使用することができます。 + +* `Impersonate-User`: ユーザー名を指定します。このユーザーとして振る舞います。 +* `Impersonate-Group`: グループ名を指定します。このグループとして振る舞います。複数回指定して複数のグループを設定することができます。任意であり、"Impersonate-User"が必要です。 +* `Impersonate-Extra-( extra name )`: 追加フィールドをユーザーに関連付けるために使用される動的なヘッダーです。任意であり、"Impersonate-User"が必要です。一貫して保存されるためには、`( extra name )`は小文字である必要があり、[HTTPヘッダーラベルで使用可能な文字](https://tools.ietf.org/html/rfc7230#section-3.2.6)以外の文字は、UTF-8であり、[パーセントエンコーディング](https://tools.ietf.org/html/rfc3986#section-2.1)されている必要があります. + +{{< note >}} +1.11.3(および1.10.7、1.9.11)よりも前のバージョンでは、`( extra name )`には[HTTPヘッダーラベルで使用可能な文字](https://tools.ietf.org/html/rfc7230#section-3.2.6)のみを含めることができました。 +{{< /note >}} + +以下が、ヘッダーの例です。 + +```http +Impersonate-User: jane.doe@example.com +Impersonate-Group: developers +Impersonate-Group: admins +Impersonate-Extra-dn: cn=jane,ou=engineers,dc=example,dc=com +Impersonate-Extra-acme.com%2Fproject: some-project +Impersonate-Extra-scopes: view +Impersonate-Extra-scopes: development +``` + +`kubectl`を使う場合は、`--as`フラグに`Impersonate-User`ヘッダーを、`--as-group`フラグに`Impersonate-Group`ヘッダーを設定します。 + + +```bash +kubectl drain mynode +``` + +```none +Error from server (Forbidden): User "clark" cannot get nodes at the cluster scope. (get nodes mynode) +``` + +`--as`フラグと`--as-group`フラグを設定します。 + +```bash +kubectl drain mynode --as=superman --as-group=system:masters +``` + +```none +node/mynode cordoned +node/mynode drained +``` + +ユーザー、グループ、または追加フィールドを偽装するために、偽装ユーザーは偽装される属性の種類("user"、"group"など)に対して、"偽装した"操作を行う能力を持っている必要があります。RBAC認可プラグインが有効なクラスターの場合、以下のClusterRoleは、ユーザーとグループの偽装ヘッダーを設定するために必要なルールを網羅しています。 + +```yaml +apiVersion: rbac.authorization.k8s.io/v1 +kind: ClusterRole +metadata: + name: impersonator +rules: +- apiGroups: [""] + resources: ["users", "groups", "serviceaccounts"] + verbs: ["impersonate"] +``` + +追加フィールドは、"userextras"リソースのサブリソースとして評価されます。ユーザーが追加フィールド"scopes"に偽装ヘッダーを使用できるようにするには、ユーザーに以下のようなロールを付与する必要があります。 + +```yaml +apiVersion: rbac.authorization.k8s.io/v1 +kind: ClusterRole +metadata: + name: scopes-impersonator +rules: +# "Impersonate-Extra-scopes"ヘッダーを設定できます。 +- apiGroups: ["authentication.k8s.io"] + resources: ["userextras/scopes"] + verbs: ["impersonate"] +``` + +偽装ヘッダーの値は、リソースが取り得る`resourceNames`の集合を制限することで、管理することもできます。 + +```yaml +apiVersion: rbac.authorization.k8s.io/v1 +kind: ClusterRole +metadata: + name: limited-impersonator +rules: +# "jane.doe@example.com"というユーザーを偽装できます。 +- apiGroups: [""] + resources: ["users"] + verbs: ["impersonate"] + resourceNames: ["jane.doe@example.com"] + +# "developers"と"admins"というグループを偽装できます。 +- apiGroups: [""] + resources: ["groups"] + verbs: ["impersonate"] + resourceNames: ["developers","admins"] + +# "view"と"development"を値に持つ"scopes"という追加フィールドを偽装できます。 +- apiGroups: ["authentication.k8s.io"] + resources: ["userextras/scopes"] + verbs: ["impersonate"] + resourceNames: ["view", "development"] +``` + +## client-goクレデンシャルプラグイン + +{{< feature-state for_k8s_version="v1.11" state="beta" >}} + +`k8s.io/client-go`と、それを使用する`kubectl`や`kubelet`のようなツールは、外部コマンドを実行してユーザーの認証情報を受け取ることができます。 + +この機能は`k8s.io/client-go`がネイティブにサポートしていない認証プロトコル(LDAP、Kerberos、OAuth2、SAMLなど)とクライアントサイドで統合するためのものです。プラグインはプロトコル固有のロジックを実装し、使用する不透明なクレデンシャルを返します。ほとんどすべてのクレデンシャルプラグインのユースケースでは、クライアントプラグインが生成するクレデンシャルフォーマットを解釈するために、[Webhookトークン認証](#webhook-token-authentication)をサポートするサーバーサイドコンポーネントが必要です。 + +### 使用例 + +ある組織は、LDAPクレデンシャルをユーザー固有の署名済みトークンと交換する外部サービスを実行すると仮定します。このサービスは、トークンを検証するために[Webhookトークン認証](#webhook-token-authentication)リクエストに応答することもできます。ユーザーはワークステーションにクレデンシャルプラグインをインストールする必要があります。 + +以下のようにして、APIに対して認証を行います。 + +* ユーザーは`kubectl`コマンドを発行します。 +* クレデンシャルプラグインは、LDAPクレデンシャルの入力をユーザーに要求し、クレデンシャルを外部サービスとトークンと交換します。 +* クレデンシャルプラグインはトークンを`client-go`に返します。これはAPIサーバーに対するBearerトークンとして使用されます。 +* APIサーバーは、[Webhookトークン認証](#webhook-token-authentication)を使用して、`TokenReview`を外部サービスに送信します。 +* 外部サービスはトークンの署名を検証し、ユーザーのユーザー名とグループを返します。 + +### 設定 + +クレデンシャルプラグインの設定は、userフィールドの一部として[kubectlの設定ファイル](/docs/tasks/access-application-cluster/configure-access-multiple-clusters/)で行います。 + +```yaml +apiVersion: v1 +kind: Config +users: +- name: my-user + user: + exec: + # 実行するコマンドです。必須です。 + command: "example-client-go-exec-plugin" + + # ExecCredentialsリソースをデコードする際に使用するAPIのバージョン。必須です。 + # + # プラグインが返すAPIのバージョンは、ここに記載されているバージョンと一致しなければなりません + # + # 複数のバージョンをサポートするツール(client.authentication.k8s.io/v1alpha1など)と統合するには、 + # 環境変数を設定するか、execプラグインが期待するバージョンを示す引数をツールに渡します。 + apiVersion: "client.authentication.k8s.io/v1beta1" + + # プラグインを実行する際に設定する環境変数です。任意です。 + env: + - name: "FOO" + value: "bar" + + # プラグインを実行する際に渡す引数です。任意です。 + args: + - "arg1" + - "arg2" +clusters: +- name: my-cluster + cluster: + server: "https://172.17.4.100:6443" + certificate-authority: "/etc/kubernetes/ca.pem" +contexts: +- name: my-cluster + context: + cluster: my-cluster + user: my-user +current-context: my-cluster +``` + +相対的なコマンドパスは、設定ファイルのディレクトリーからの相対的なものとして解釈されます。KUBECONFIGが`/home/jane/kubeconfig`に設定されていて、execコマンドが`./bin/example-client-go-exec-plugin`の場合、バイナリー`/home/jane/bin/example-client-go-exec-plugin`が実行されます。 + +```yaml +- name: my-user + user: + exec: + # kubeconfigのディレクトリーへの相対パス + command: "./bin/example-client-go-exec-plugin" + apiVersion: "client.authentication.k8s.io/v1beta1" +``` + +### 入出力フォーマット + +実行されたコマンドは`ExecCredential`オブジェクトを`stdout`に出力します。`k8s.io/client-go`は`status`で返された認証情報を用いて、Kubernetes APIに対して認証を行ういます。 + +対話的なセッションから実行する場合、`stdin`はプラグインに直接公開されます。プラグインは[TTYチェック](https://godoc.org/golang.org/x/crypto/ssh/terminal#IsTerminal)を使って、対話的にユーザーにプロンプトを出すことが適切かどうかを判断する必要があります。 + +Bearerトークンのクレデンシャルを使用するために、プラグインは`ExecCredential`のステータスにトークンを返します。 + +```json +{ + "apiVersion": "client.authentication.k8s.io/v1beta1", + "kind": "ExecCredential", + "status": { + "token": "my-bearer-token" + } +} +``` + +あるいは、PEMエンコードされたクライアント証明書と鍵を返して、TLSクライアント認証を使用することもできます。 +プラグインが後続の呼び出しで異なる証明書と鍵を返すと、`k8s.io/client-go`はサーバーとの既存の接続を閉じて、新しいTLSハンドシェイクを強制します + +指定された場合、`clientKeyData`と`clientCertificateData`両方が存在しなければなりません。 + +`clientCertificateData`には、サーバーに送信するための中間証明書を含めることができます。 + +```json +{ + "apiVersion": "client.authentication.k8s.io/v1beta1", + "kind": "ExecCredential", + "status": { + "clientCertificateData": "-----BEGIN CERTIFICATE-----\n...\n-----END CERTIFICATE-----", + "clientKeyData": "-----BEGIN RSA PRIVATE KEY-----\n...\n-----END RSA PRIVATE KEY-----" + } +} +``` + +オプションで、レスポンスにはRFC3339のタイムスタンプとしてフォーマットされたクレデンシャルの有効期限を含めることができます。有効期限の有無には、以下のような影響あります。 + +- 有効期限が含まれている場合、BearerトークンとTLSクレデンシャルは有効期限に達するまで、またはサーバーがHTTPステータスコード401で応答したとき、またはプロセスが終了するまでキャッシュされます。 +- 有効期限が省略された場合、BearerトークンとTLSクレデンシャルはサーバーがHTTPステータスコード401で応答したとき、またはプロセスが終了するまでキャッシュされます。 + +```json +{ + "apiVersion": "client.authentication.k8s.io/v1beta1", + "kind": "ExecCredential", + "status": { + "token": "my-bearer-token", + "expirationTimestamp": "2018-03-05T17:30:20-08:00" + } +} +``` diff --git a/content/ja/docs/reference/glossary/cncf.md b/content/ja/docs/reference/glossary/cncf.md new file mode 100755 index 0000000000..85e6f60f0a --- /dev/null +++ b/content/ja/docs/reference/glossary/cncf.md @@ -0,0 +1,20 @@ +--- +title: Cloud Native Computing Foundation (CNCF) +id: cncf +date: 2019-05-26 +full_link: https://cncf.io/ +short_description: > + Cloud Native Computing Foundation + +aka: +tags: +- community +--- + Cloud Native Computing Foundation (CNCF)は、持続可能なエコシステムを構築し、マイクロサービスアーキテクチャの一部としてコンテナをオーケストレーションする[プロジェクト](https://www.cncf.io/projects/)を中心としたコミュニティを育成します。 + +KubernetesはCNCFプロジェクトです。 + +<!--more--> + +CNCFは[Linux Foundation](https://www.linuxfoundation.org/)のサブファウンデーションです。 +CNCFの使命は、クラウドネイティブコンピューティングをユビキタスにすることです。 diff --git a/content/ja/docs/reference/glossary/configmap.md b/content/ja/docs/reference/glossary/configmap.md new file mode 100755 index 0000000000..434c64b7a7 --- /dev/null +++ b/content/ja/docs/reference/glossary/configmap.md @@ -0,0 +1,17 @@ +--- +title: ConfigMap +id: configmap +date: 2018-04-12 +full_link: /ja/docs/concepts/configuration/configmap/ +short_description: > + 機密性のないデータをキーと値のペアで保存するために使用されるAPIオブジェクトです。環境変数、コマンドライン引数、またはボリューム内の設定ファイルとして使用できます。 +aka: +tags: +- core-object +--- + + 機密性のないデータをキーと値のペアで保存するために使用されるAPIオブジェクトです。{{< glossary_tooltip text="Pod" term_id="pod" >}}は、環境変数、コマンドライン引数、または{{< glossary_tooltip text="ボリューム" term_id="volume" >}}内の設定ファイルとしてConfigMapを使用できます。 + +<!--more--> + +ConfigMapを使用すると、環境固有の設定を{{< glossary_tooltip text="コンテナイメージ" term_id="image" >}}から分離できるため、アプリケーションを簡単に移植できるようになります。 diff --git a/content/ja/docs/reference/glossary/container.md b/content/ja/docs/reference/glossary/container.md index 616405a720..480934867a 100644 --- a/content/ja/docs/reference/glossary/container.md +++ b/content/ja/docs/reference/glossary/container.md @@ -4,14 +4,14 @@ id: container date: 2018-04-12 full_link: /docs/concepts/overview/what-is-kubernetes/#why-containers short_description: > - 軽量でポータブルなソフトウェアとそのすべての依存関係が含まれている実行可能なイメージ + 軽量でポータブルなソフトウェアとそのすべての依存関係が含まれている実行可能なイメージです。 aka: tags: - fundamental - workload --- - 軽量でポータブルなソフトウェアとそのすべての依存関係が含まれている実行可能なイメージ + 軽量でポータブルなソフトウェアとそのすべての依存関係が含まれている実行可能なイメージです。 <!--more--> diff --git a/content/ja/docs/reference/glossary/deployment.md b/content/ja/docs/reference/glossary/deployment.md index d3483b58fb..569cbbd6a1 100755 --- a/content/ja/docs/reference/glossary/deployment.md +++ b/content/ja/docs/reference/glossary/deployment.md @@ -4,7 +4,7 @@ id: deployment date: 2018-04-12 full_link: /ja/docs/concepts/workloads/controllers/deployment/ short_description: > - 複製されたアプリケーションを管理するAPIオブジェクト。 + 複製されたアプリケーションを管理するAPIオブジェクトです。 aka: tags: @@ -12,7 +12,7 @@ tags: - core-object - workload --- - 複製されたアプリケーションを管理するAPIオブジェクト。 + 複製されたアプリケーションを管理するAPIオブジェクトです。 <!--more--> diff --git a/content/ja/docs/reference/glossary/image.md b/content/ja/docs/reference/glossary/image.md new file mode 100755 index 0000000000..c677808747 --- /dev/null +++ b/content/ja/docs/reference/glossary/image.md @@ -0,0 +1,17 @@ +--- +title: イメージ +id: image +date: 2018-04-12 +full_link: +short_description: > + アプリケーションの実行に必要なソフトウェアのセットを持つ、保存されたコンテナの実体です。 + +aka: +tags: +- fundamental +--- + アプリケーションの実行に必要なソフトウェアのセットを持つ、保存された{{< glossary_tooltip text="コンテナ" term_id="container" >}}の実体です。 + +<!--more--> + +コンテナレジストリに格納し、ローカルシステムにプルして、アプリケーションとして実行できるようにするソフトウェアをパッケージ化する方法です。イメージに含まれているメタデータは、実行する実行可能ファイル、作成者、およびその他の情報を示すことができます。 diff --git a/content/ja/docs/reference/glossary/index.md b/content/ja/docs/reference/glossary/index.md index eb6d2c00fd..1f0da77b5e 100755 --- a/content/ja/docs/reference/glossary/index.md +++ b/content/ja/docs/reference/glossary/index.md @@ -1,5 +1,5 @@ --- -title: Standardized Glossary +title: 標準化用語集 layout: glossary noedit: true default_active_tag: fundamental @@ -7,6 +7,6 @@ weight: 5 card: name: reference weight: 10 - title: Glossary + title: 用語集 --- diff --git a/content/ja/docs/reference/glossary/name.md b/content/ja/docs/reference/glossary/name.md index 48c4ca4db9..214f3d571e 100755 --- a/content/ja/docs/reference/glossary/name.md +++ b/content/ja/docs/reference/glossary/name.md @@ -14,5 +14,5 @@ tags: <!--more--> -同じ種類のオブジェクトは、同じ名前を同時に持つことは出来ません。しかし、オブジェクトを削除することで、旧オブジェクトと同じ名前で新しいオブジェクトを作成できます。 +同じ種類のオブジェクトは、同じ名前を同時に持つことはできません。しかし、オブジェクトを削除することで、旧オブジェクトと同じ名前で新しいオブジェクトを作成できます。 diff --git a/content/ja/docs/reference/glossary/persistent-volume-claim.md b/content/ja/docs/reference/glossary/persistent-volume-claim.md index 7366429a24..021c998def 100644 --- a/content/ja/docs/reference/glossary/persistent-volume-claim.md +++ b/content/ja/docs/reference/glossary/persistent-volume-claim.md @@ -6,13 +6,13 @@ full_link: /docs/concepts/storage/persistent-volumes/ short_description: > コンテナ内でボリュームとしてマウントするためにPersistentVolume内で定義されたストレージリソースを要求します。 -aka: +aka: tags: - core-object - storage --- {{< glossary_tooltip text="コンテナ" term_id="container" >}}内でボリュームとしてマウントするために{{< glossary_tooltip text="PersistentVolume" term_id="persistent-volume" >}}内で定義されたストレージリソースを要求します。 -<!--more--> +<!--more--> -ストレージサイズ、ストレージへのアクセス制御（読み取り専用、読み取り/書き込み、排他的）、および再利用方法（保持、リサイクル、削除）を指定します。ストレージ自体の詳細はPersistentVolumeオブジェクトに記載されています。 +ストレージサイズ、ストレージへのアクセス制御(読み取り専用、読み取り/書き込み、排他的)、および再利用方法（保持、リサイクル、削除）を指定します。ストレージ自体の詳細はPersistentVolumeオブジェクトに記載されています。 diff --git a/content/ja/docs/reference/glossary/service.md b/content/ja/docs/reference/glossary/service.md index 212c3acce1..304e781b53 100755 --- a/content/ja/docs/reference/glossary/service.md +++ b/content/ja/docs/reference/glossary/service.md @@ -11,7 +11,7 @@ tags: - fundamental - core-object --- -{{< glossary_tooltip text="Pods" term_id="pod" >}}の集合で実行されているアプリケーションをネットワークサービスとして公開する抽象的な方法。 +{{< glossary_tooltip text="Pod" term_id="pod" >}}の集合で実行されているアプリケーションをネットワークサービスとして公開する抽象的な方法です。 <!--more--> diff --git a/content/ja/docs/reference/glossary/statefulset.md b/content/ja/docs/reference/glossary/statefulset.md index bcb947367d..1fad77bd62 100755 --- a/content/ja/docs/reference/glossary/statefulset.md +++ b/content/ja/docs/reference/glossary/statefulset.md @@ -4,7 +4,7 @@ id: statefulset date: 2018-04-12 full_link: /ja/docs/concepts/workloads/controllers/statefulset/ short_description: > - Manages the deployment and scaling of a set of Pods, *and provides guarantees about the ordering and uniqueness* of these Pods. + StatefulSetはDeploymentとPodのセットのスケーリングを管理し、それらのPodの *順序と一意性を保証* します。 aka: tags: @@ -14,7 +14,7 @@ tags: - storage --- -StatefulSetはDeploymentと{{< glossary_tooltip text="Pod" term_id="pod" >}}のセットのスケーリングの管理をし、それらのPodの*順序とユニーク性を保証* します。 +StatefulSetはDeploymentと{{< glossary_tooltip text="Pod" term_id="pod" >}}のセットのスケーリングを管理し、それらのPodの*順序と一意性を保証* します。 <!--more--> diff --git a/content/ja/docs/reference/glossary/volume.md b/content/ja/docs/reference/glossary/volume.md index 8ea7702e4c..6a81f84522 100644 --- a/content/ja/docs/reference/glossary/volume.md +++ b/content/ja/docs/reference/glossary/volume.md @@ -4,14 +4,14 @@ id: volume date: 2018-04-12 full_link: /docs/concepts/storage/volumes/ short_description: > - Pod内のコンテナからアクセス可能なデータを含むディレクトリ。 + Pod内のコンテナからアクセス可能なデータを含むディレクトリです。 aka: tags: - core-object - fundamental --- - {{< glossary_tooltip text="Pod" term_id="pod" >}}内の{{< glossary_tooltip text="コンテナ" term_id="container" >}}からアクセス可能なデータを含むディレクトリ。 + {{< glossary_tooltip text="Pod" term_id="pod" >}}内の{{< glossary_tooltip text="コンテナ" term_id="container" >}}からアクセス可能なデータを含むディレクトリです。 <!--more--> diff --git a/content/ja/docs/reference/kubectl/cheatsheet.md b/content/ja/docs/reference/kubectl/cheatsheet.md index cc1da85b76..d63654bd38 100644 --- a/content/ja/docs/reference/kubectl/cheatsheet.md +++ b/content/ja/docs/reference/kubectl/cheatsheet.md @@ -323,7 +323,7 @@ kubectl cluster-info # Kubernet kubectl cluster-info dump # 現在のクラスター状態を標準出力にダンプします kubectl cluster-info dump --output-directory=/path/to/cluster-state # 現在のクラスター状態を/path/to/cluster-stateにダンプします -# special-userキーとNoScheduleエフェクトを持つTaintが既に存在する場合、その値は指定されたとおりに置き換えられます +# special-userキーとNoScheduleエフェクトを持つTaintがすでに存在する場合、その値は指定されたとおりに置き換えられます kubectl taint nodes foo dedicated=special-user:NoSchedule ``` diff --git a/content/ja/docs/setup/_index.md b/content/ja/docs/setup/_index.md index 8ba1773f75..2d602e9300 100644 --- a/content/ja/docs/setup/_index.md +++ b/content/ja/docs/setup/_index.md @@ -49,6 +49,6 @@ Kubernetesについて学んでいる場合、Dockerベースのソリューシ 本番環境用のソリューションを評価する際には、Kubernetesクラスター(または抽象レイヤ)の運用においてどの部分を自分で管理し、どの部分をプロバイダーに任せるのかを考慮してください。 -[Certified Kubernetes](https://github.com/cncf/k8s-conformance/#certified-kubernetes)プロバイダーの一覧については、"[Partners](https://kubernetes.io/partners/#conformance)"を参照してください。 +[Certified Kubernetes](https://github.com/cncf/k8s-conformance/#certified-kubernetes)プロバイダーの一覧については、「[パートナー](https://kubernetes.io/ja/partners/#conformance)」を参照してください。 diff --git a/content/ja/docs/setup/best-practices/certificates.md b/content/ja/docs/setup/best-practices/certificates.md index ff6fe29dd1..7f67ee7006 100644 --- a/content/ja/docs/setup/best-practices/certificates.md +++ b/content/ja/docs/setup/best-practices/certificates.md @@ -72,7 +72,7 @@ CAの秘密鍵をクラスターにコピーしたくない場合、自身で全 | kube-apiserver-kubelet-client | kubernetes-ca | system:masters | client | | | front-proxy-client | kubernetes-front-proxy-ca | | client | | -[1]: クラスターに接続するIPおよびDNS名（ [kubeadm][kubeadm]を使用する場合と同様、ロードバランサーのIPおよびDNS名、`kubernetes`、`kubernetes.default`、`kubernetes.default.svc`、`kubernetes.default.svc.cluster`、`kubernetes.default.svc.cluster.local`） +[1]: クラスターに接続するIPおよびDNS名( [kubeadm][kubeadm]を使用する場合と同様、ロードバランサーのIPおよびDNS名、`kubernetes`、`kubernetes.default`、`kubernetes.default.svc`、`kubernetes.default.svc.cluster`、`kubernetes.default.svc.cluster.local`) `kind`は下記の[x509の鍵用途][usage]のタイプにマッピングされます: @@ -82,7 +82,7 @@ CAの秘密鍵をクラスターにコピーしたくない場合、自身で全 | client | digital signature, key encipherment, client auth | {{< note >}} -上記に挙げられたホスト名（SAN）は、クラスターを動作させるために推奨されるものです。 +上記に挙げられたホスト名(SAN)は、クラスターを動作させるために推奨されるものです。 特別なセットアップが求められる場合、全てのサーバー証明書にSANを追加する事ができます。 {{< /note >}} diff --git a/content/ja/docs/setup/best-practices/multiple-zones.md b/content/ja/docs/setup/best-practices/multiple-zones.md index 577cc42650..3590f6fa8c 100644 --- a/content/ja/docs/setup/best-practices/multiple-zones.md +++ b/content/ja/docs/setup/best-practices/multiple-zones.md @@ -303,7 +303,7 @@ kubectl get nodes --show-labels Create the guestbook-go example, which includes an RC of size 3, running a simple web app: ```shell -find kubernetes/examples/guestbook-go/ -name '*.json' | xargs -I {} kubectl create -f {} +find kubernetes/examples/guestbook-go/ -name '*.json' | xargs -I {} kubectl apply -f {} ``` The pods should be spread across all 3 zones: diff --git a/content/ja/docs/setup/best-practices/node-conformance.md b/content/ja/docs/setup/best-practices/node-conformance.md index 129bd762ba..0db9cb4432 100644 --- a/content/ja/docs/setup/best-practices/node-conformance.md +++ b/content/ja/docs/setup/best-practices/node-conformance.md @@ -7,43 +7,35 @@ weight: 30 ## ノード適合テスト -*Node conformance test* is a containerized test framework that provides a system -verification and functionality test for a node. The test validates whether the -node meets the minimum requirements for Kubernetes; a node that passes the test -is qualified to join a Kubernetes cluster. +*ノード適合テスト* は、システムの検証とノードに対する機能テストを提供するコンテナ型のテストフレームワークです。このテストは、ノードがKubernetesの最小要件を満たしているかどうかを検証するもので、テストに合格したノードはKubernetesクラスタに参加する資格があることになります。 ## 制約 -In Kubernetes version 1.5, node conformance test has the following limitations: +Kubernetesのバージョン1.5ではノード適合テストには以下の制約があります: -* Node conformance test only supports Docker as the container runtime. +* ノード適合テストはコンテナのランタイムとしてDockerのみをサポートします。 ## ノードの前提条件 -To run node conformance test, a node must satisfy the same prerequisites as a -standard Kubernetes node. At a minimum, the node should have the following -daemons installed: +適合テストを実行するにはノードは通常のKubernetesノードと同じ前提条件を満たしている必要があります。 最低でもノードに以下のデーモンがインストールされている必要があります: -* Container Runtime (Docker) +* コンテナランタイム (Docker) * Kubelet ## ノード適合テストの実行 -To run the node conformance test, perform the following steps: +ノード適合テストを実行するには、以下の手順に従います: -1. Point your Kubelet to localhost `--api-servers="http://localhost:8080"`, -because the test framework starts a local master to test Kubelet. There are some -other Kubelet flags you may care: - * `--pod-cidr`: If you are using `kubenet`, you should specify an arbitrary CIDR - to Kubelet, for example `--pod-cidr=10.180.0.0/24`. - * `--cloud-provider`: If you are using `--cloud-provider=gce`, you should - remove the flag to run the test. +1. Kubeletをlocalhostに指定します(`--api-servers="http://localhost:8080"`)、 +このテストフレームワークはKubeletのテストにローカルマスターを起動するため、Kubeletをローカルホストに設定します(`--api-servers="http://localhost:8080"`)。他にも配慮するべきKubeletフラグがいくつかあります: + * `--pod-cidr`: `kubenet`を利用している場合は、Kubeletに任意のCIDR(例: `--pod-cidr=10.180.0.0/24`)を指定する必要があります。 + * `--cloud-provider`: `--cloud-provider=gce`を指定している場合は、テストを実行する前にこのフラグを取り除いてください。 -2. Run the node conformance test with command: +2. 以下のコマンドでノード適合テストを実行します: ```shell -# $CONFIG_DIR is the pod manifest path of your Kubelet. -# $LOG_DIR is the test output path. +# $CONFIG_DIRはKubeletのPodのマニフェストパスです。 +# $LOG_DIRはテスト出力のパスです。 sudo docker run -it --rm --privileged --net=host \ -v /:/rootfs -v $CONFIG_DIR:$CONFIG_DIR -v $LOG_DIR:/var/result \ k8s.gcr.io/node-test:0.2 @@ -51,8 +43,7 @@ sudo docker run -it --rm --privileged --net=host \ ## 他アーキテクチャ向けのノード適合テストの実行 -Kubernetes also provides node conformance test docker images for other -architectures: +Kubernetesは他のアーキテクチャ用のノード適合テストのdockerイメージを提供しています: Arch | Image | --------|:-----------------:| @@ -62,37 +53,30 @@ architectures: ## 選択したテストの実行 -To run specific tests, overwrite the environment variable `FOCUS` with the -regular expression of tests you want to run. +特定のテストを実行するには、環境変数`FOCUS`を実行したいテストの正規表現で上書きします。 ```shell sudo docker run -it --rm --privileged --net=host \ -v /:/rootfs:ro -v $CONFIG_DIR:$CONFIG_DIR -v $LOG_DIR:/var/result \ - -e FOCUS=MirrorPod \ # Only run MirrorPod test + -e FOCUS=MirrorPod \ # MirrorPodテストのみを実行します k8s.gcr.io/node-test:0.2 ``` -To skip specific tests, overwrite the environment variable `SKIP` with the -regular expression of tests you want to skip. +特定のテストをスキップするには、環境変数`SKIP`をスキップしたいテストの正規表現で上書きします。 ```shell sudo docker run -it --rm --privileged --net=host \ -v /:/rootfs:ro -v $CONFIG_DIR:$CONFIG_DIR -v $LOG_DIR:/var/result \ - -e SKIP=MirrorPod \ # Run all conformance tests but skip MirrorPod test + -e SKIP=MirrorPod \ # MirrorPodテスト以外のすべてのノード適合テストを実行します k8s.gcr.io/node-test:0.2 ``` -Node conformance test is a containerized version of [node e2e test](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-node/e2e-node-tests.md). -By default, it runs all conformance tests. +ノード適合テストは、[node e2e test](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-node/e2e-node-tests.md)のコンテナ化されたバージョンです。 +デフォルトでは、すべての適合テストが実行されます。 -Theoretically, you can run any node e2e test if you configure the container and -mount required volumes properly. But **it is strongly recommended to only run conformance -test**, because it requires much more complex configuration to run non-conformance test. +理論的には、コンテナを構成し必要なボリュームを適切にマウントすれば、どのノードのe2eテストも実行できます。しかし、不適合テストを実行するためにはより複雑な設定が必要となるため、**適合テストのみを実行することを強く推奨します**。 ## 注意事項 -* The test leaves some docker images on the node, including the node conformance - test image and images of containers used in the functionality - test. -* The test leaves dead containers on the node. These containers are created - during the functionality test. +* このテストでは、ノード適合テストイメージや機能テストで使用されるコンテナのイメージなど、いくつかのdockerイメージがノード上に残ります。 +* このテストでは、ノード上にデッドコンテナが残ります。これらのコンテナは機能テスト中に作成されます。 diff --git a/content/ja/docs/setup/learning-environment/_index.md b/content/ja/docs/setup/learning-environment/_index.md index 051413db61..fad99fb4e8 100644 --- a/content/ja/docs/setup/learning-environment/_index.md +++ b/content/ja/docs/setup/learning-environment/_index.md @@ -1,4 +1,4 @@ --- -title: 環境について学ぶ +title: 学習環境 weight: 20 --- diff --git a/content/ja/docs/setup/learning-environment/kind.md b/content/ja/docs/setup/learning-environment/kind.md new file mode 100644 index 0000000000..8c17327144 --- /dev/null +++ b/content/ja/docs/setup/learning-environment/kind.md @@ -0,0 +1,15 @@ +--- +title: Kindを使用してKubernetesをインストールする +weight: 40 +content_type: concept +--- + +<!-- overview --> + +Kindは、Dockerコンテナをノードとして使用して、ローカルのKubernetesクラスターを実行するためのツールです。 + +<!-- body --> + +## インストール + +[Kindをインストールする](https://kind.sigs.k8s.io/docs/user/quick-start/)を参照してください。 diff --git a/content/ja/docs/setup/learning-environment/minikube.md b/content/ja/docs/setup/learning-environment/minikube.md index 543256b4e3..67b0002946 100644 --- a/content/ja/docs/setup/learning-environment/minikube.md +++ b/content/ja/docs/setup/learning-environment/minikube.md @@ -1,143 +1,257 @@ --- title: Minikubeを使用してローカル環境でKubernetesを動かす +weight: 30 content_type: concept --- + <!-- overview --> Minikubeはローカル環境でKubernetesを簡単に実行するためのツールです。Kubernetesを試したり日々の開発への使用を検討するユーザー向けに、PC上のVM内でシングルノードのKubernetesクラスタを実行することができます。 - <!-- body --> ## Minikubeの機能 -* MinikubeのサポートするKubernetesの機能: - * DNS - * NodePorts - * ConfigMapsとSecrets - * ダッシュボード - * コンテナランタイム: Docker, [rkt](https://github.com/rkt/rkt), [CRI-O](https://cri-o.io/), [containerd](https://github.com/containerd/containerd) - * CNI (Container Network Interface) の有効化 - * Ingress +MinikubeのサポートするKubernetesの機能: + +* DNS +* NodePort +* ConfigMapとSecret +* ダッシュボード +* コンテナランタイム: Docker、[CRI-O](https://cri-o.io/)および[containerd](https://github.com/containerd/containerd) +* CNI (Container Network Interface) の有効化 +* Ingress ## インストール -[Minikubeのインストール](/ja/docs/tasks/tools/install-minikube/) を参照 +[Minikubeのインストール](/ja/docs/tasks/tools/install-minikube/)を参照してください。 ## クイックスタート -これはMinikubeの使い方の簡単なデモです。 -もしVMドライバを変更したい場合は、適切な `--vm-driver=xxx` フラグを `minikube start` に設定してください。Minikubeは以下のドライバをサポートしています。 +これはMinikubeの起動、使用、削除をローカルで実施する簡単なデモです。下記の手順に従って、Minikubeを起動し試してください。 -* virtualbox +1. Minikubeを起動し、クラスターを作成します: + + ```shell + minikube start + ``` + + 出力はこのようになります: + + ``` + Starting local Kubernetes cluster... + Running pre-create checks... + Creating machine... + Starting local Kubernetes cluster... + ``` + + 特定のKubernetesのバージョン、VM、コンテナランタイム上でクラスターを起動するための詳細は、[クラスターの起動](#starting-a-cluster)を参照してください。 + +2. kubectlを使用してクラスターと対話できるようになります。詳細は[クラスターに触れてみよう](#interacting-with-your-cluster)を参照してください。 +単純なHTTPサーバーである`echoserver`という既存のイメージを使用して、Kubernetes Deploymentを作りましょう。そして`--port`を使用して8080番ポートで公開しましょう。 + + ```shell + kubectl create deployment hello-minikube --image=k8s.gcr.io/echoserver:1.10 + ``` + + 出力はこのようになります: + + ``` + deployment.apps/hello-minikube created + ``` + +3. `hello-minikube`Deploymentに接続するために、Serviceとして公開します: + + ```shell + kubectl expose deployment hello-minikube --type=NodePort --port=8080 + ``` + + `--type=NodePort`オプションで、Serviceのタイプを指定します。 + 出力はこのようになります: + + ``` + service/hello-minikube exposed + ``` + +4. `hello-minikube`Podが起動開始されましたが、公開したService経由で接続する前にPodが起動完了になるまで待つ必要があります。 + + Podが稼働しているか確認します: + ```shell + kubectl get pod + ``` + + `STATUS`に`ContainerCreating`と表示されている場合、Podはまだ作成中です: + + ``` + NAME READY STATUS RESTARTS AGE + hello-minikube-3383150820-vctvh 0/1 ContainerCreating 0 3s + ``` + + `STATUS`に`Running`と表示されている場合、Podは稼働中です: + + ``` + NAME READY STATUS RESTARTS AGE + hello-minikube-3383150820-vctvh 1/1 Running 0 13s + ``` + +5. Serviceの詳細を確認するため、公開したServiceのURLを取得します: + + ```shell + minikube service hello-minikube --url + ``` + +6. ローカル環境のクラスターについて詳細を確認するには、出力から得たURLをブラウザー上でコピーアンドペーストしてください。 + + 出力はこのようになります: + + ``` + Hostname: hello-minikube-7c77b68cff-8wdzq + + Pod Information: + -no pod information available- + + Server values: + server_version=nginx: 1.13.3 - lua: 10008 + + Request Information: + client_address=172.17.0.1 + method=GET + real path=/ + query= + request_version=1.1 + request_scheme=http + request_uri=http://192.168.99.100:8080/ + + Request Headers: + accept=*/* + host=192.168.99.100:30674 + user-agent=curl/7.47.0 + + Request Body: + -no body in request- + ``` + + Serviceやクラスターをこれ以上稼働させない場合、削除する事ができます。 + +7. `hello-minikube`Serviceを削除します: + + ```shell + kubectl delete services hello-minikube + ``` + + 出力はこのようになります: + + ``` + service "hello-minikube" deleted + ``` + +8. `hello-minikube`Deploymentを削除します: + + ```shell + kubectl delete deployment hello-minikube + ``` + + 出力はこのようになります: + + ``` + deployment.extensions "hello-minikube" deleted + ``` + +9. ローカル環境のMinikubeクラスターを停止します: + + ```shell + minikube stop + ``` + + 出力はこのようになります: + + ``` + Stopping local Kubernetes cluster... + Stopping "minikube"... + ``` + + 詳細は[クラスターの停止](#stopping-a-cluster)を参照ください。 + +10. ローカルのMinikubeクラスターを削除します: + + ```shell + minikube delete + ``` + + 出力はこのようになります: + + ``` + Deleting "minikube" ... + The "minikube" cluster has been deleted. + ``` + + 詳細は[クラスターの削除](#deleting-a-cluster)を参照ください。 + +## クラスターの管理 + +### クラスターの起動 {#starting-a-cluster} + +`minikube start`コマンドを使用してクラスターを起動することができます。 +このコマンドはシングルノードのKubernetesクラスターを実行する仮想マシンを作成・設定します。 +また、このクラスターと通信する[kubectl](/ja/docs/reference/kubectl/overview/)のインストールも設定します。 + +{{< note >}} +もしWebプロキシーを通している場合、そのプロキシー情報を`minikube start`コマンドに渡す必要があります: + +```shell +https_proxy=<my proxy> minikube start --docker-env http_proxy=<my proxy> --docker-env https_proxy=<my proxy> --docker-env no_proxy=192.168.99.0/24 +``` + +残念なことに、ただ環境変数を設定するだけではうまく動作しません。 + +Minikubeは"minikube"コンテキストも作成し、そのコンテキストをデフォルト設定としてkubectlに設定します。 +あとでコンテキストを切り戻すには、このコマンドを実行してください: `kubectl config use-context minikube` +{{< /note >}} + +#### Kubernetesバージョンの指定 + +`minikube start`コマンドに`--kubernetes-version`文字列を追加することで、 +MinikubeにKubernetesの特定のバージョンを指定することができます。 +例えば、{{< param "fullversion" >}}のバージョンを実行するには以下を実行します: + +``` +minikube start --kubernetes-version {{< param "fullversion" >}} +``` + +#### VMドライバーの指定 + +もしVMドライバーを変更したい場合は、`--vm-driver=<enter_driver_name>`フラグを`minikube start`に設定してください。例えば、コマンドは以下のようになります。 + +```shell +minikube start --vm-driver=<driver_name> +``` + +Minikubeは以下のドライバーをサポートしています: + {{< note >}} +サポートされているドライバーとプラグインのインストールの詳細については[DRIVERS](https://git.k8s.io/minikube/docs/drivers.md)を参照してください。 +{{< /note >}} + +* virtualbox * vmwarefusion -* kvm2 ([driver installation](https://git.k8s.io/minikube/docs/drivers.md#kvm2-driver)) -* kvm ([driver installation](https://git.k8s.io/minikube/docs/drivers.md#kvm-driver)) -* hyperkit ([driver installation](https://git.k8s.io/minikube/docs/drivers.md#hyperkit-driver)) -* xhyve ([driver installation](https://git.k8s.io/minikube/docs/drivers.md#xhyve-driver)) (非推奨) +* kvm2 ([driver installation](https://minikube.sigs.k8s.io/docs/drivers/#kvm2-driver)) +* hyperkit ([driver installation](https://minikube.sigs.k8s.io/docs/drivers/#hyperkit-driver)) * hyperv ([driver installation](https://github.com/kubernetes/minikube/blob/master/docs/drivers.md#hyperv-driver)) -注意: 以下のIPは動的であり、変更される可能性があります。IPは `minikube ip` で取得することができます。 -* none (VMではなくホスト上でKubernetesコンポーネントを起動する。このドライバを使用するにはDocker ([docker install](https://docs.docker.com/install/linux/docker-ce/ubuntu/)) とLinux環境を必要とします) +注意: 以下のIPは動的であり、変更される可能性があります。IPは`minikube ip`で取得することができます。 +* vmware ([driver installation](https://minikube.sigs.k8s.io/docs/reference/drivers/vmware/)) (VMware unified driver) +* none (VMではなくホスト上でKubernetesコンポーネントを起動。このドライバーを使用するには{{< glossary_tooltip term_id="docker" >}}とLinux環境を必要とします) -```shell -minikube start -``` -``` -Starting local Kubernetes cluster... -Running pre-create checks... -Creating machine... -Starting local Kubernetes cluster... -``` -```shell -kubectl create deployment hello-minikube --image=k8s.gcr.io/echoserver:1.10 -``` -``` -deployment.apps/hello-minikube created -``` - -```shell -kubectl expose deployment hello-minikube --type=NodePort --port=8080 -``` -``` -service/hello-minikube exposed -``` -``` -# We have now launched an echoserver pod but we have to wait until the pod is up before curling/accessing it -# via the exposed service. -# To check whether the pod is up and running we can use the following: -kubectl get pod -``` -``` -NAME READY STATUS RESTARTS AGE -hello-minikube-3383150820-vctvh 0/1 ContainerCreating 0 3s -``` -```shell -# We can see that the pod is still being created from the ContainerCreating status -kubectl get pod -``` -``` -NAME READY STATUS RESTARTS AGE -hello-minikube-3383150820-vctvh 1/1 Running 0 13s -``` -```shell -# We can see that the pod is now Running and we will now be able to curl it: -curl $(minikube service hello-minikube --url) -``` -``` - -Hostname: hello-minikube-7c77b68cff-8wdzq - -Pod Information: - -no pod information available- - -Server values: - server_version=nginx: 1.13.3 - lua: 10008 - -Request Information: - client_address=172.17.0.1 - method=GET - real path=/ - query= - request_version=1.1 - request_scheme=http - request_uri=http://192.168.99.100:8080/ - -Request Headers: - accept=*/* - host=192.168.99.100:30674 - user-agent=curl/7.47.0 - -Request Body: - -no body in request- -``` - -```shell -kubectl delete services hello-minikube -``` -``` -service "hello-minikube" deleted -``` - -```shell -kubectl delete deployment hello-minikube -``` -``` -deployment.extensions "hello-minikube" deleted -``` - -```shell -minikube stop -``` -``` -Stopping local Kubernetes cluster... -Stopping "minikube"... -``` +{{< caution >}} +`none`ドライバーを使用する場合、一部のKubernetesのコンポーネントは特権付きのコンテナとして稼働するため、Minikube環境外に副作用をもたらします。 +この副作用から、`none`ドライバーは、個人の作業環境では推奨されません。 +{{< /caution >}} ### コンテナランタイムの代替 +下記のコンテナランタイム上でMinikubeを起動できます。 -#### containerd +{{< tabs name="container_runtimes" >}} +{{% tab name="containerd" %}} [containerd](https://github.com/containerd/containerd) をコンテナランタイムとして使用するには以下を実行してください: @@ -160,10 +274,9 @@ minikube start \ --extra-config=kubelet.image-service-endpoint=unix:///run/containerd/containerd.sock \ --bootstrapper=kubeadm ``` - -#### CRI-O - -[CRI-O](https://github.com/kubernetes-incubator/cri-o) をコンテナランタイムとして使用するには以下を実行してください: +{{% /tab %}} +{{% tab name="CRI-O" %}} +[CRI-O](https://cri-o.io/)をコンテナランタイムとして使用するには以下を実行してください: ```bash minikube start \ @@ -184,47 +297,33 @@ minikube start \ --extra-config=kubelet.image-service-endpoint=/var/run/crio.sock \ --bootstrapper=kubeadm ``` - -#### rktコンテナエンジン - -[rkt](https://github.com/rkt/rkt) をコンテナランタイムとして使用するには以下を実行してください: - -```shell -minikube start \ - --network-plugin=cni \ - --enable-default-cni \ - --container-runtime=rkt -``` - -これはrktとDockerの両方を含んだ代替のMinikubeのISOイメージを使用し、CNIネットワークを有効にします。 - -### ドライバープラグイン - -サポートされているドライバとプラグインのインストールの詳細については [DRIVERS](https://git.k8s.io/minikube/docs/drivers.md) を参照してください。 +{{% /tab %}} +{{< /tabs >}} ### Dockerデーモンの再利用によるローカルイメージの使用 -Kubernetesの単一のVMを使用する場合、Minikube組み込みのDockerデーモンの再利用がおすすめです。ホストマシン上にDockerレジストリを構築してイメージをプッシュする必要がなく、ローカルでの実験を加速させるMinikubeと同じDockerデーモンの中に構築することができます。ただDockerイメージに'latest'以外のタグを付け、そのタグを使用してイメージをプルしてください。イメージのバージョンを指定しなければ、`Always` のプルイメージポリシーにより `:latest` と仮定され、もしデフォルトのDockerレジストリ(通常はDockerHub)にどのバージョンのDockerイメージもまだ存在しない場合には、`ErrImagePull` になる恐れがあります。 +Kubernetesの単一のVMを使用する場合、Minikube組み込みのDockerデーモンの再利用がおすすめです。ホストマシン上にDockerレジストリを構築してイメージをプッシュする必要がなく、ローカルでの実験を加速させるMinikubeと同じDockerデーモンの中に構築することができます。 -Mac/LinuxのホストでDockerデーモンを操作できるようにするには、shell内で `docker-env command` を使います: +{{< note >}} +Dockerイメージに'latest'以外のタグを付け、そのタグを使用してイメージをプルしてください。イメージのバージョンを指定しなければ`Always`のプルイメージポリシーにより`:latest`と仮定され、もしデフォルトのDockerレジストリ(通常はDockerHub)にどのバージョンのDockerイメージもまだ存在しない場合には、`ErrImagePull`になる恐れがあります。 +{{< /note >}} -```shell -eval $(minikube docker-env) -``` +Mac/LinuxのホストでDockerデーモンを操作できるようにするには、`minikube docker-env`を実行します。 -これにより、MinikubeのVM内のDockerデーモンと通信しているホストのMac/LinuxマシンのコマンドラインでDockerを使用できるようになっているはずです。 +これにより、MinikubeのVM内のDockerデーモンと通信しているホストのMac/LinuxマシンのコマンドラインでDockerを使用できるようになります: ```shell docker ps ``` +{{< note >}} CentOS 7では、Dockerが以下のエラーを出力することがあります: -```shell +``` Could not read CA certificate "/etc/docker/ca.pem": open /etc/docker/ca.pem: no such file or directory ``` -修正方法としては、/etc/sysconfig/docker を更新してMinikube環境の変更が確実に反映されるようにすることです: +修正方法としては、/etc/sysconfig/dockerを更新してMinikube環境の変更が確実に反映されるようにすることです: ```shell < DOCKER_CERT_PATH=/etc/docker @@ -233,37 +332,7 @@ Could not read CA certificate "/etc/docker/ca.pem": open /etc/docker/ca.pem: no > DOCKER_CERT_PATH=/etc/docker > fi ``` - -imagePullPolicy:Alwaysをオフにすることを忘れないでください: さもなければKubernetesはローカルに構築したイメージを使用しません。 - -## クラスターの管理 - -### クラスターの起動 - -`minikube start` コマンドはクラスターを起動することができます。 -このコマンドはシングルノードのKubernetesクラスターを実行する仮想マシンを作成・設定します。 -また、このクラスターと通信する [kubectl](/docs/user-guide/kubectl-overview/) のインストールも設定します。 - -もしWebプロキシーを通している場合、そのプロキシー情報を `minikube start` コマンドに渡す必要があります: - -```shell -https_proxy=<my proxy> minikube start --docker-env http_proxy=<my proxy> --docker-env https_proxy=<my proxy> --docker-env no_proxy=192.168.99.0/24 -``` - -残念なことに、ただ環境変数を設定するだけではうまく動作しません。 - -Minikubeは "minikube" コンテキストも作成し、そのコンテキストをデフォルト設定としてkubectlに設定します。 -あとでコンテキストを切り戻すには、このコマンドを実行してください: `kubectl config use-context minikube` - -#### Kubernetesバージョンの指定 - -`minikube start` コマンドに `--kubernetes-version` 文字列を追加することで、 -MinikubeにKubernetesの特定のバージョンを指定することができます。 -例えば、`v1.7.3` のバージョンを実行するには以下を実行します: - -``` -minikube start --kubernetes-version v1.7.3 -``` +{{< /note >}} ### Kubernetesの設定 @@ -293,16 +362,19 @@ Kubeletの `MaxPods` 設定を5に変更するには、このフラグを渡し `apiserver` の `AuthorizationMode` を `RABC` に設定するには、このフラグを使います: `--extra-config=apiserver.authorization-mode=RBAC`. -### クラスターの停止 +### クラスターの停止 {#stopping-a-cluster} `minikube stop` コマンドを使ってクラスターを停止することができます。 このコマンドはMinikube仮想マシンをシャットダウンしますが、すべてのクラスターの状態とデータを保存します。 クラスターを再起動すると、以前の状態に復元されます。 -### クラスターの削除 +### クラスターの削除 {#deleting-a-cluster} `minikube delete` コマンドを使ってクラスターを削除することができます。 このコマンドはMinikube仮想マシンをシャットダウンして削除します。データや状態は保存されません。 -## クラスターに触れてみよう +### minikubeのアップグレード {#upgrading-minikube} +[minikubeのアップグレード](https://minikube.sigs.k8s.io/docs/start/macos/)を参照してください。 + +## クラスターに触れてみよう {#interacting-with-your-cluster} ### Kubectl @@ -379,7 +451,7 @@ spec: | VirtualBox | Linux | /home | /hosthome | | VirtualBox | macOS | /Users | /Users | | VirtualBox | Windows | C://Users | /c/Users | -| VMware Fusion | macOS | /Users | /Users | +| VMware Fusion | macOS | /Users | /mnt/hgfs/Users | | Xhyve | macOS | /Users | /Users | ## プライベートコンテナレジストリ @@ -417,10 +489,8 @@ export no_proxy=$no_proxy,$(minikube ip) ``` ## 既知の問題 -* クラウドプロバイダーを必要とする機能はMinikubeでは動作しません - * ロードバランサー -* 複数ノードを必要とする機能 - * 高度なスケジューリングポリシー + +複数ノードを必要とする機能はMinikubeでは動作しません。 ## 設計 @@ -440,5 +510,3 @@ Minikubeの詳細については、[proposal](https://git.k8s.io/community/contr ## コミュニティ コントリビューションや質問、コメントは歓迎・奨励されています! Minikubeの開発者は[Slack](https://kubernetes.slack.com)の#minikubeチャンネルにいます(Slackへの招待状は[こちら](http://slack.kubernetes.io/))。[kubernetes-dev Google Groupsメーリングリスト](https://groups.google.com/forum/#!forum/kubernetes-dev)もあります。メーリングリストに投稿する際は件名の最初に "minikube: " をつけてください。 - - diff --git a/content/ja/docs/setup/production-environment/container-runtimes.md b/content/ja/docs/setup/production-environment/container-runtimes.md index a9604a7b59..667726bc64 100644 --- a/content/ja/docs/setup/production-environment/container-runtimes.md +++ b/content/ja/docs/setup/production-environment/container-runtimes.md @@ -25,7 +25,7 @@ Podのコンテナを実行するために、Kubernetesはコンテナランタ ### 適用性 {{< note >}} -このドキュメントはLinuxにCRIをインストールするユーザーの為に書かれています。 +このドキュメントはLinuxにCRIをインストールするユーザーのために書かれています。 他のオペレーティングシステムの場合、プラットフォーム固有のドキュメントを見つけてください。 {{< /note >}} @@ -47,38 +47,46 @@ systemdと一緒に `cgroupfs` を使用するということは、2つの異な kubeletとDockerに `cgroupfs` を使用し、ノード上で実行されている残りのプロセスに `systemd` を使用するように設定されたノードが、 リソース圧迫下で不安定になる場合があります。 -あなたのコンテナランタイムとkubeletにcgroupドライバーとしてsystemdを使用するように設定を変更することはシステムを安定させました。 +コンテナランタイムとkubeletがcgroupドライバーとしてsystemdを使用するように設定を変更することでシステムは安定します。 以下のDocker設定の `native.cgroupdriver=systemd` オプションに注意してください。 +{{< caution >}} +すでにクラスターに組み込まれているノードのcgroupドライバーを変更することは非常におすすめしません。 +kubeletが一方のcgroupドライバーを使用してPodを作成した場合、コンテナランタイムを別のもう一方のcgroupドライバーに変更すると、そのような既存のPodのPodサンドボックスを再作成しようとするとエラーが発生する可能性があります。 +kubeletを再起動しても問題は解決しないでしょう。 +ワークロードからノードを縮退させ、クラスターから削除して再び組み込むことを推奨します。 +{{< /caution >}} + ## Docker それぞれのマシンに対してDockerをインストールします。 -バージョン18.06.2が推奨されていますが、1.11、1.12、1.13、17.03、18.09についても動作が確認されています。 +バージョン19.03.4が推奨されていますが、1.13.1、17.03、17.06、17.09、18.06、18.09についても動作が確認されています。 Kubernetesのリリースノートにある、Dockerの動作確認済み最新バージョンについてもご確認ください。 システムへDockerをインストールするには、次のコマンドを実行します。 {{< tabs name="tab-cri-docker-installation" >}} -{{< tab name="Ubuntu 16.04" codelang="bash" >}} +{{< tab name="Ubuntu 16.04+" codelang="bash" >}} # Docker CEのインストール ## リポジトリをセットアップ -### aptパッケージインデックスを更新 - apt-get update - ### HTTPS越しのリポジトリの使用をaptに許可するために、パッケージをインストール - apt-get update && apt-get install apt-transport-https ca-certificates curl software-properties-common +apt-get update && apt-get install -y \ + apt-transport-https ca-certificates curl software-properties-common gnupg2 ### Docker公式のGPG鍵を追加 - curl -fsSL https://download.docker.com/linux/ubuntu/gpg | apt-key add - +curl -fsSL https://download.docker.com/linux/ubuntu/gpg | apt-key add - -### dockerのaptリポジトリを追加 - add-apt-repository \ - "deb [arch=amd64] https://download.docker.com/linux/ubuntu \ - $(lsb_release -cs) \ - stable" +### Dockerのaptリポジトリを追加 +add-apt-repository \ + "deb [arch=amd64] https://download.docker.com/linux/ubuntu \ + $(lsb_release -cs) \ + stable" -## docker ceのインストール -apt-get update && apt-get install docker-ce=18.06.2~ce~3-0~ubuntu +## Docker CEのインストール +apt-get update && apt-get install -y \ + containerd.io=1.2.10-3 \ + docker-ce=5:19.03.4~3-0~ubuntu-$(lsb_release -cs) \ + docker-ce-cli=5:19.03.4~3-0~ubuntu-$(lsb_release -cs) # デーモンをセットアップ cat > /etc/docker/daemon.json <<EOF @@ -103,15 +111,17 @@ systemctl restart docker # Docker CEのインストール ## リポジトリをセットアップ ### 必要なパッケージのインストール - yum install yum-utils device-mapper-persistent-data lvm2 +yum install -y yum-utils device-mapper-persistent-data lvm2 -### dockerパッケージ用のyumリポジトリを追加 -yum-config-manager \ - --add-repo \ - https://download.docker.com/linux/centos/docker-ce.repo +### Dockerリポジトリの追加 +yum-config-manager --add-repo \ + https://download.docker.com/linux/centos/docker-ce.repo -## docker ceのインストール -yum update && yum install docker-ce-18.06.2.ce +## Docker CEのインストール +yum update -y && yum install -y \ + containerd.io-1.2.10 \ + docker-ce-19.03.4 \ + docker-ce-cli-19.03.4 ## /etc/docker ディレクトリを作成 mkdir /etc/docker @@ -147,7 +157,12 @@ systemctl restart docker システムへCRI-Oをインストールするためには以下のコマンドを利用します: -### 必要な設定の追加 +{{< note >}} +CRI-OのメジャーとマイナーバージョンはKubernetesのメジャーとマイナーバージョンと一致しなければなりません。 +詳細は[CRI-O互換性表](https://github.com/cri-o/cri-o)を参照してください。 +{{< /note >}} + +### 事前準備 ```shell modprobe overlay @@ -164,33 +179,55 @@ sysctl --system ``` {{< tabs name="tab-cri-cri-o-installation" >}} -{{< tab name="Ubuntu 16.04" codelang="bash" >}} +{{< tab name="Debian" codelang="bash" >}} +# Debian Unstable/Sid +echo 'deb http://download.opensuse.org/repositories/devel:/kubic:/libcontainers:/stable/Debian_Unstable/ /' > /etc/apt/sources.list.d/devel:kubic:libcontainers:stable.list +wget -nv https://download.opensuse.org/repositories/devel:kubic:libcontainers:stable/Debian_Unstable/Release.key -O- | sudo apt-key add - -# 必要なパッケージをインストールし、リポジトリを追加 -apt-get update -apt-get install software-properties-common +# Debian Testing +echo 'deb http://download.opensuse.org/repositories/devel:/kubic:/libcontainers:/stable/Debian_Testing/ /' > /etc/apt/sources.list.d/devel:kubic:libcontainers:stable.list +wget -nv https://download.opensuse.org/repositories/devel:kubic:libcontainers:stable/Debian_Testing/Release.key -O- | sudo apt-key add - -add-apt-repository ppa:projectatomic/ppa -apt-get update +# Debian 10 +echo 'deb http://download.opensuse.org/repositories/devel:/kubic:/libcontainers:/stable/Debian_10/ /' > /etc/apt/sources.list.d/devel:kubic:libcontainers:stable.list +wget -nv https://download.opensuse.org/repositories/devel:kubic:libcontainers:stable/Debian_10/Release.key -O- | sudo apt-key add - -# CRI-Oをインストール -apt-get install cri-o-1.11 +# Raspbian 10 +echo 'deb http://download.opensuse.org/repositories/devel:/kubic:/libcontainers:/stable/Raspbian_10/ /' > /etc/apt/sources.list.d/devel:kubic:libcontainers:stable.list +wget -nv https://download.opensuse.org/repositories/devel:kubic:libcontainers:stable/Raspbian_10/Release.key -O- | sudo apt-key add - +# CRI-Oのインストール +sudo apt-get install cri-o-1.17 {{< /tab >}} + +{{< tab name="Ubuntu 18.04, 19.04 and 19.10" codelang="bash" >}} +# リポジトリの設定 +. /etc/os-release +sudo sh -c "echo 'deb http://download.opensuse.org/repositories/devel:/kubic:/libcontainers:/stable/x${NAME}_${VERSION_ID}/ /' > /etc/apt/sources.list.d/devel:kubic:libcontainers:stable.list" +wget -nv https://download.opensuse.org/repositories/devel:kubic:libcontainers:stable/x${NAME}_${VERSION_ID}/Release.key -O- | sudo apt-key add - +sudo apt-get update + +# CRI-Oのインストール +sudo apt-get install cri-o-1.17 +{{< /tab >}} + {{< tab name="CentOS/RHEL 7.4+" codelang="bash" >}} +# 必要なパッケージのインストール +yum-config-manager --add-repo=https://cbs.centos.org/repos/paas7-crio-115-release/x86_64/os/ -# 必要なリポジトリを追加 -yum-config-manager --add-repo=https://cbs.centos.org/repos/paas7-crio-311-candidate/x86_64/os/ - -# CRI-Oをインストール -yum install --nogpgcheck cri-o +# CRI-Oのインストール +yum install --nogpgcheck -y cri-o +{{< /tab >}} +{{< tab name="openSUSE Tumbleweed" codelang="bash" >}} +sudo zypper install cri-o {{< /tab >}} {{< /tabs >}} ### CRI-Oの起動 ``` +systemctl daemon-reload systemctl start crio ``` @@ -205,6 +242,11 @@ systemctl start crio ### 必要な設定の追加 ```shell +cat > /etc/modules-load.d/containerd.conf <<EOF +overlay +br_netfilter +EOF + modprobe overlay modprobe br_netfilter @@ -218,36 +260,61 @@ EOF sysctl --system ``` +### containerdのインストール + {{< tabs name="tab-cri-containerd-installation" >}} -{{< tab name="Ubuntu 16.04+" codelang="bash" >}} -apt-get install -y libseccomp2 +{{< tab name="Ubuntu 16.04" codelang="bash" >}} +# containerdのインストール +## リポジトリの設定 +### HTTPS越しのリポジトリの使用をaptに許可するために、パッケージをインストール +apt-get update && apt-get install -y apt-transport-https ca-certificates curl software-properties-common + +### Docker公式のGPG鍵を追加 +curl -fsSL https://download.docker.com/linux/ubuntu/gpg | apt-key add - + +### Dockerのaptリポジトリの追加 +add-apt-repository \ + "deb [arch=amd64] https://download.docker.com/linux/ubuntu \ + $(lsb_release -cs) \ + stable" + +## containerdのインストール +apt-get update && apt-get install -y containerd.io + +# containerdの設定 +mkdir -p /etc/containerd +containerd config default > /etc/containerd/config.toml + +# containerdの再起動 +systemctl restart containerd {{< /tab >}} {{< tab name="CentOS/RHEL 7.4+" codelang="bash" >}} -yum install -y libseccomp +# containerdのインストール +## リポジトリの設定 +### 必要なパッケージのインストール +yum install -y yum-utils device-mapper-persistent-data lvm2 + +### Dockerのリポジトリの追加 +yum-config-manager \ + --add-repo \ + https://download.docker.com/linux/centos/docker-ce.repo + +## containerdのインストール +yum update -y && yum install -y containerd.io + +# containerdの設定 +mkdir -p /etc/containerd +containerd config default > /etc/containerd/config.toml + +# containerdの再起動 +systemctl restart containerd {{< /tab >}} {{< /tabs >}} -### containerdのインストール +### systemd -[Containerdは定期的にリリース](https://github.com/containerd/containerd/releases)されますが、以下に示すコマンドで利用している値は、この手順が作成された時点での最新のバージョンにしたがって書かれています。より新しいバージョンとダウンロードするファイルのハッシュ値については[こちら](https://storage.googleapis.com/cri-containerd-release)で確認するようにしてください。 - -```shell -# 必要な環境変数をexportします。 -export CONTAINERD_VERSION="1.1.2" -export CONTAINERD_SHA256="d4ed54891e90a5d1a45e3e96464e2e8a4770cd380c21285ef5c9895c40549218" - -# containerdのtarボールをダウンロードします。 -wget https://storage.googleapis.com/cri-containerd-release/cri-containerd-${CONTAINERD_VERSION}.linux-amd64.tar.gz - -# ハッシュ値をチェックします。 -echo "${CONTAINERD_SHA256} cri-containerd-${CONTAINERD_VERSION}.linux-amd64.tar.gz" | sha256sum --check - - -# 解凍して展開します。 -tar --no-overwrite-dir -C / -xzf cri-containerd-${CONTAINERD_VERSION}.linux-amd64.tar.gz - -# containerdを起動します。 -systemctl start containerd -``` +`systemd`のcgroupドライバーを使うには、`/etc/containerd/config.toml`内で`plugins.cri.systemd_cgroup = true`を設定してください。 +kubeadmを使う場合は[kubeletのためのcgroupドライバー](/ja/docs/setup/production-environment/tools/kubeadm/install-kubeadm/#マスターノードのkubeletによって使用されるcgroupドライバーの設定)を手動で設定してください。 ## その他のCRIランタイム: frakti diff --git a/content/ja/docs/setup/production-environment/on-premises-vm/_index.md b/content/ja/docs/setup/production-environment/on-premises-vm/_index.md index a8dcf3523c..6de2892840 100644 --- a/content/ja/docs/setup/production-environment/on-premises-vm/_index.md +++ b/content/ja/docs/setup/production-environment/on-premises-vm/_index.md @@ -1,4 +1,4 @@ --- title: オンプレミスVM -weight: 60 +weight: 40 --- diff --git a/content/ja/docs/setup/production-environment/on-premises-vm/dcos.md b/content/ja/docs/setup/production-environment/on-premises-vm/dcos.md index a41309d23b..d869b2fe90 100644 --- a/content/ja/docs/setup/production-environment/on-premises-vm/dcos.md +++ b/content/ja/docs/setup/production-environment/on-premises-vm/dcos.md @@ -5,7 +5,7 @@ content_type: concept <!-- overview --> -Mesosphereは[DC/OS](https://mesosphere.com/product/)上にKubernetesを構築する為の簡単な選択肢を提供します。それは +Mesosphereは[DC/OS](https://mesosphere.com/product/)上にKubernetesを構築するための簡単な選択肢を提供します。それは * 純粋なアップストリームのKubernetes * シングルクリッククラスター構築 diff --git a/content/ja/docs/setup/production-environment/tools/kops.md b/content/ja/docs/setup/production-environment/tools/kops.md index e0203ca097..92899a300a 100644 --- a/content/ja/docs/setup/production-environment/tools/kops.md +++ b/content/ja/docs/setup/production-environment/tools/kops.md @@ -1,6 +1,6 @@ --- title: kopsを使ったAWS上でのKubernetesのインストール -content_type: concept +content_type: task weight: 20 --- @@ -9,35 +9,40 @@ weight: 20 This quickstart shows you how to easily install a Kubernetes cluster on AWS. It uses a tool called [`kops`](https://github.com/kubernetes/kops). -kops is an opinionated provisioning system: +kops is an automated provisioning system: * Fully automated installation * Uses DNS to identify clusters * Self-healing: everything runs in Auto-Scaling Groups -* Multiple OS support (Debian, Ubuntu 16.04 supported, CentOS & RHEL, Amazon Linux and CoreOS) - see the [images.md](https://github.com/kubernetes/kops/blob/master/docs/images.md) -* High-Availability support - see the [high_availability.md](https://github.com/kubernetes/kops/blob/master/docs/high_availability.md) +* Multiple OS support (Debian, Ubuntu 16.04 supported, CentOS & RHEL, Amazon Linux and CoreOS) - see the [images.md](https://github.com/kubernetes/kops/blob/master/docs/operations/images.md) +* High-Availability support - see the [high_availability.md](https://github.com/kubernetes/kops/blob/master/docs/operations/high_availability.md) * Can directly provision, or generate terraform manifests - see the [terraform.md](https://github.com/kubernetes/kops/blob/master/docs/terraform.md) -If your opinions differ from these you may prefer to build your own cluster using [kubeadm](/docs/admin/kubeadm/) as -a building block. kops builds on the kubeadm work. + + +## {{% heading "prerequisites" %}} + + +* You must have [kubectl](/docs/tasks/tools/install-kubectl/) installed. + +* You must [install](https://github.com/kubernetes/kops#installing) `kops` on a 64-bit (AMD64 and Intel 64) device architecture. + +* You must have an [AWS account](https://docs.aws.amazon.com/polly/latest/dg/setting-up.html), generate [IAM keys](https://docs.aws.amazon.com/general/latest/gr/aws-sec-cred-types.html#access-keys-and-secret-access-keys) and [configure](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-configure.html#cli-quick-configuration) them. -<!-- body --> +<!-- steps --> ## クラスタの作成 ### (1/5) kopsのインストール -#### 要件 - -You must have [kubectl](/ja/docs/tasks/tools/install-kubectl/) installed in order for kops to work. - #### インストール Download kops from the [releases page](https://github.com/kubernetes/kops/releases) (it is also easy to build from source): -On macOS: +{{< tabs name="kops_installation" >}} +{{% tab name="macOS" %}} Download the latest release with the command: @@ -45,14 +50,12 @@ Download the latest release with the command: curl -LO https://github.com/kubernetes/kops/releases/download/$(curl -s https://api.github.com/repos/kubernetes/kops/releases/latest | grep tag_name | cut -d '"' -f 4)/kops-darwin-amd64 ``` -To download a specific version, replace the +To download a specific version, replace the following portion of the command with the specific kops version. ```shell $(curl -s https://api.github.com/repos/kubernetes/kops/releases/latest | grep tag_name | cut -d '"' -f 4) ``` -portion of the command with the specific version. - For example, to download kops version v1.15.0 type: ```shell @@ -76,8 +79,8 @@ You can also install kops using [Homebrew](https://brew.sh/). ```shell brew update && brew install kops ``` - -On Linux: +{{% /tab %}} +{{% tab name="Linux" %}} Download the latest release with the command: @@ -85,11 +88,11 @@ Download the latest release with the command: curl -LO https://github.com/kubernetes/kops/releases/download/$(curl -s https://api.github.com/repos/kubernetes/kops/releases/latest | grep tag_name | cut -d '"' -f 4)/kops-linux-amd64 ``` -To download a specific version, replace the +To download a specific version of kops, replace the following portion of the command with the specific kops version. + ```shell $(curl -s https://api.github.com/repos/kubernetes/kops/releases/latest | grep tag_name | cut -d '"' -f 4) ``` -portion of the command with the specific version. For example, to download kops version v1.15.0 type: @@ -115,9 +118,13 @@ You can also install kops using [Homebrew](https://docs.brew.sh/Homebrew-on-Linu brew update && brew install kops ``` +{{% /tab %}} +{{< /tabs >}} + + ### (2/5) クラスタ用のroute53ドメインの作成 -kops uses DNS for discovery, both inside the cluster and so that you can reach the kubernetes API server +kops uses DNS for discovery, both inside the cluster and outside, so that you can reach the kubernetes API server from clients. kops has a strong opinion on the cluster name: it should be a valid DNS name. By doing so you will @@ -174,7 +181,7 @@ the S3 bucket name. ### (4/5) クラスタ設定の構築 -Run "kops create cluster" to create your cluster configuration: +Run `kops create cluster` to create your cluster configuration: `kops create cluster --zones=us-east-1c useast1.dev.example.com` @@ -213,24 +220,20 @@ for production clusters! ### 他のアドオンの参照 -See the [list of add-ons](/docs/concepts/cluster-administration/addons/) to explore other add-ons, including tools for logging, monitoring, network policy, visualization & control of your Kubernetes cluster. +See the [list of add-ons](/docs/concepts/cluster-administration/addons/) to explore other add-ons, including tools for logging, monitoring, network policy, visualization, and control of your Kubernetes cluster. ## クリーンアップ * To delete your cluster: `kops delete cluster useast1.dev.example.com --yes` -## フィードバック - -* Slack Channel: [#kops-users](https://kubernetes.slack.com/messages/kops-users/) -* [GitHub Issues](https://github.com/kubernetes/kops/issues) - ## {{% heading "whatsnext" %}} * Learn more about Kubernetes [concepts](/docs/concepts/) and [`kubectl`](/docs/user-guide/kubectl-overview/). -* Learn about `kops` [advanced usage](https://github.com/kubernetes/kops) -* See the `kops` [docs](https://github.com/kubernetes/kops) section for tutorials, best practices and advanced configuration options. +* Learn more about `kops` [advanced usage](https://kops.sigs.k8s.io/) for tutorials, best practices and advanced configuration options. +* Follow `kops` community discussions on Slack: [community discussions](https://github.com/kubernetes/kops#other-ways-to-communicate-with-the-contributors) +* Contribute to `kops` by addressing or raising an issue [GitHub Issues](https://github.com/kubernetes/kops/issues) diff --git a/content/ja/docs/setup/production-environment/tools/kubeadm/control-plane-flags.md b/content/ja/docs/setup/production-environment/tools/kubeadm/control-plane-flags.md index b4ff9024f6..b2b41f9128 100644 --- a/content/ja/docs/setup/production-environment/tools/kubeadm/control-plane-flags.md +++ b/content/ja/docs/setup/production-environment/tools/kubeadm/control-plane-flags.md @@ -35,7 +35,7 @@ kubeadmの`ClusterConfiguration`オブジェクトはAPIServer、ControllerManag 詳細は[kube-apiserverのリファレンスドキュメント](/docs/reference/command-line-tools-reference/kube-apiserver/)を参照してください。 -Example usage: +使用例: ```yaml apiVersion: kubeadm.k8s.io/v1beta2 kind: ClusterConfiguration @@ -52,7 +52,7 @@ apiServer: 詳細は[kube-controller-managerのリファレンスドキュメント](/docs/reference/command-line-tools-reference/kube-controller-manager/)を参照してください。 -Example usage: +使用例: ```yaml apiVersion: kubeadm.k8s.io/v1beta2 kind: ClusterConfiguration @@ -68,7 +68,7 @@ controllerManager: 詳細は[kube-schedulerのリファレンスドキュメント](/docs/reference/command-line-tools-reference/kube-scheduler/)を参照してください。 -Example usage: +使用例: ```yaml apiVersion: kubeadm.k8s.io/v1beta2 kind: ClusterConfiguration diff --git a/content/ja/docs/setup/production-environment/tools/kubeadm/high-availability.md b/content/ja/docs/setup/production-environment/tools/kubeadm/high-availability.md index b9e82a7838..6b7cb8b610 100644 --- a/content/ja/docs/setup/production-environment/tools/kubeadm/high-availability.md +++ b/content/ja/docs/setup/production-environment/tools/kubeadm/high-availability.md @@ -8,16 +8,14 @@ weight: 60 このページでは、kubeadmを使用して、高可用性クラスターを作成する、2つの異なるアプローチを説明します: -- 積み重なったコントロールプレーンノードを使う方法。こちらのアプローチは、必要なインフラストラクチャーが少ないです。etcdのメンバーと、コントロールプレーンノードは同じ場所に置かれます。 +- 積層コントロールプレーンノードを使う方法。こちらのアプローチは、必要なインフラストラクチャーが少ないです。etcdのメンバーと、コントロールプレーンノードは同じ場所に置かれます。 - 外部のetcdクラスターを使う方法。こちらのアプローチには、より多くのインフラストラクチャーが必要です。コントロールプレーンノードと、etcdのメンバーは分離されます。 -先へ進む前に、どちらのアプローチがアプリケーションの要件と、環境に適合するか、慎重に検討してください。[こちらの比較](/ja/docs/setup/independent/ha-topology/)が、それぞれの利点/欠点について概説しています。 +先へ進む前に、どちらのアプローチがアプリケーションの要件と、環境に適合するか、慎重に検討してください。[こちらの比較](/ja/docs/setup/production-environment/tools/kubeadm/ha-topology/)が、それぞれの利点/欠点について概説しています。 -クラスターではKubernetesのバージョン1.12以降を使用する必要があります。また、kubeadmを使用した高可用性クラスターはまだ実験的な段階であり、将来のバージョンではもっとシンプルになることに注意してください。たとえば、クラスターのアップグレードに際し問題に遭遇するかもしれません。両方のアプローチを試し、kueadmの[issue tracker](https://github.com/kubernetes/kubeadm/issues/new)で我々にフィードバックを提供してくれることを推奨します。 +高可用性クラスターの作成で問題が発生した場合は、kueadmの[issue tracker](https://github.com/kubernetes/kubeadm/issues/new)でフィードバックを提供してください。 -alpha feature gateである`HighAvailability`はv1.12で非推奨となり、v1.13で削除されたことに留意してください。 - -[高可用性クラスターのアップグレード](/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade-ha-1-13)も参照してください。 +[高可用性クラスターのアップグレード](/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade/)も参照してください。 {{< caution >}} このページはクラウド上でクラスターを構築することには対応していません。ここで説明されているどちらのアプローチも、クラウド上で、LoadBalancerタイプのServiceオブジェクトや、動的なPersistentVolumeを利用して動かすことはできません。 @@ -30,8 +28,8 @@ alpha feature gateである`HighAvailability`はv1.12で非推奨となり、v1. どちらの方法でも、以下のインフラストラクチャーが必要です: -- master用に、[kubeadmの最小要件](/ja/docs/setup/independent/install-kubeadm/#before-you-begin)を満たす3台のマシン -- worker用に、[kubeadmの最小要件](/ja/docs/setup/independent/install-kubeadm/#before-you-begin)を満たす3台のマシン +- master用に、[kubeadmの最小要件](/ja/docs/setup/production-environment/tools/kubeadm/install-kubeadm/#始める前に)を満たす3台のマシン +- worker用に、[kubeadmの最小要件](/ja/docs/setup/production-environment/tools/kubeadm/install-kubeadm/#始める前に)を満たす3台のマシン - クラスター内のすべてのマシン間がフルにネットワーク接続可能であること(パブリック、もしくはプライベートネットワーク) - すべてのマシンにおいて、sudo権限 - あるデバイスから、システム内のすべてのノードに対しSSH接続できること @@ -41,22 +39,11 @@ alpha feature gateである`HighAvailability`はv1.12で非推奨となり、v1. - etcdメンバー用に、追加で3台のマシン -{{< note >}} -以下の例では、CalicoをPodネットワーキングプロバイダーとして使用します。別のネットワーキングプロバイダーを使用する場合、必要に応じてデフォルトの値を変更してください。 -{{< /note >}} - - <!-- steps --> ## 両手順における最初のステップ -{{< note >}} -コントロールプレーンや、etcdノードでのコマンドはすべてrootとして実行してください。 -{{< /note >}} - -- CalicoなどのいくつかのCNIネットワークプラグインは`192.168.0.0/16`のようなCIDRを必要としますが、Weaveなどは必要としません。[CNIネットワークドキュメント](/ja/docs/setup/independent/create-cluster-kubeadm/#pod-network)を参照してください。PodにCIDRを設定するには、`ClusterConfiguration`の`networking`オブジェクトに`podSubnet: 192.168.0.0/16`フィールドを設定してください。 - ### kube-apiserver用にロードバランサーを作成 {{< note >}} @@ -84,7 +71,181 @@ alpha feature gateである`HighAvailability`はv1.12で非推奨となり、v1. 1. 残りのコントロールプレーンノードを、ロードバランサーのターゲットグループに追加します。 -### SSHの設定 +## 積層コントロールプレーンとetcdノード + +### 最初のコントロールプレーンノードの手順 + +1. 最初のコントロールプレーンノードを初期化します: + + ```sh + sudo kubeadm init --control-plane-endpoint "LOAD_BALANCER_DNS:LOAD_BALANCER_PORT" --upload-certs + ``` + + - `--kubernetes-version`フラグで使用するKubernetesのバージョンを設定できます。kubeadm、kubelet、kubectl、Kubernetesのバージョンを一致させることが推奨されます。 + - `--control-plane-endpoint`フラグは、ロードバランサーのIPアドレスまたはDNS名と、ポートが設定される必要があります。 + - `--upload-certs`フラグは全てのコントロールプレーンノードで共有する必要がある証明書をクラスターにアップロードするために使用されます。代わりに、コントロールプレーンノード間で手動あるいは自動化ツールを使用して証明書をコピーしたい場合は、このフラグを削除し、以下の[証明書の手動配布](#manual-certs)のセクションを参照してください。 + + {{< note >}}`kubeadm init`の`--config`フラグと`--certificate-key`フラグは混在させることはできないため、[kubeadm configuration](https://godoc.org/k8s.io/kubernetes/cmd/kubeadm/app/apis/kubeadm/v1beta2)を使用する場合は`certificateKey`フィールドを適切な場所に追加する必要があります(`InitConfiguration`と`JoinConfiguration: controlPlane`の配下)。{{< /note >}} + + {{< note >}}CalicoなどのいくつかのCNIネットワークプラグインは`192.168.0.0/16`のようなCIDRを必要としますが、Weaveなどは必要としません。[CNIネットワークドキュメント](/ja/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm/#pod-network)を参照してください。PodにCIDRを設定するには、`ClusterConfiguration`の`networking`オブジェクトに`podSubnet: 192.168.0.0/16`フィールドを設定してください。{{< /note >}} + + - このような出力がされます: + + ```sh + ... + You can now join any number of control-plane node by running the following command on each as a root: + kubeadm join 192.168.0.200:6443 --token 9vr73a.a8uxyaju799qwdjv --discovery-token-ca-cert-hash sha256:7c2e69131a36ae2a042a339b33381c6d0d43887e2de83720eff5359e26aec866 --control-plane --certificate-key f8902e114ef118304e561c3ecd4d0b543adc226b7a07f675f56564185ffe0c07 + + Please note that the certificate-key gives access to cluster sensitive data, keep it secret! + As a safeguard, uploaded-certs will be deleted in two hours; If necessary, you can use kubeadm init phase upload-certs to reload certs afterward. + + Then you can join any number of worker nodes by running the following on each as root: + kubeadm join 192.168.0.200:6443 --token 9vr73a.a8uxyaju799qwdjv --discovery-token-ca-cert-hash sha256:7c2e69131a36ae2a042a339b33381c6d0d43887e2de83720eff5359e26aec866 + ``` + + - この出力をテキストファイルにコピーします。あとで、他のコントロールプレーンノードとワーカーノードをクラスターに参加させる際に必要です。 + + - `--upload-certs`フラグを`kubeadm init`で使用すると、プライマリコントロールプレーンの証明書が暗号化されて、`kubeadm-certs` Secretにアップロードされます。 + + - 証明書を再アップロードして新しい復号キーを生成するには、すでにクラスターに参加しているコントロールプレーンノードで次のコマンドを使用します: + + ```sh + sudo kubeadm init phase upload-certs --upload-certs + ``` + + - また、後で`join`で使用できるように、`init`中にカスタムした`--certificate-key`を指定することもできます。このようなキーを生成するには、次のコマンドを使用します: + + ```sh + kubeadm alpha certs certificate-key + ``` + + {{< note >}} + `kubeadm-certs`のSecretと復号キーは2時間で期限切れとなります。 + {{< /note >}} + + {{< caution >}} + コマンド出力に記載されているように、証明書キーはクラスターの機密データへのアクセスを提供します。秘密にしてください！ + {{< /caution >}} + +1. 使用するCNIプラグインを適用します: + [こちらの手順に従い](/ja/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm/#pod-network)CNIプロバイダーをインストールします。該当する場合は、kubeadmの設定で指定されたPodのCIDRに対応していることを確認してください。 + + Weave Netを使用する場合の例: + + ```sh + kubectl apply -f "https://cloud.weave.works/k8s/net?k8s-version=$(kubectl version | base64 | tr -d '\n')" + ``` + +1. 以下のコマンドを入力し、コンポーネントのPodが起動するのを確認します: + + ```sh + kubectl get pod -n kube-system -w + ``` + +### 残りのコントロールプレーンノードの手順 + +{{< note >}} +kubeadmバージョン1.15以降、複数のコントロールプレーンノードを並行してクラスターに参加させることができます。 +このバージョンの前は、最初のノードの初期化が完了した後でのみ、新しいコントロールプレーンノードを順番にクラスターに参加させる必要があります。 +{{< /note >}} + +追加のコントロールプレーンノード毎に、以下の手順を行います。 + +1. `kubeadm init`を最初のノードで実行した際に取得したjoinコマンドを使って、新しく追加するコントロールプレーンノードで`kubeadm join`を開始します。このようなコマンドになるはずです: + + ```sh + sudo kubeadm join 192.168.0.200:6443 --token 9vr73a.a8uxyaju799qwdjv --discovery-token-ca-cert-hash sha256:7c2e69131a36ae2a042a339b33381c6d0d43887e2de83720eff5359e26aec866 --control-plane --certificate-key f8902e114ef118304e561c3ecd4d0b543adc226b7a07f675f56564185ffe0c07 + ``` + + - `--control-plane`フラグによって、`kubeadm join`の実行は新しいコントロールプレーンを作成します。 + - `-certificate-key ...`を指定したキーを使って、クラスターの`kubeadm-certs` Secretからダウンロードされたコントロールプレーンの証明書が復号されます。 + +## 外部のetcdノード + +外部のetcdノードを使ったクラスターの設定は、積層etcdの場合と似ていますが、最初にetcdを設定し、kubeadmの設定ファイルにetcdの情報を渡す必要があります。 + +### etcdクラスターの構築 + +1. [こちらの手順](/ja/docs/setup/production-environment/tools/kubeadm/setup-ha-etcd-with-kubeadm/)にしたがって、etcdクラスターを構築してください。 + +1. [こちらの手順](#manual-certs)にしたがって、SSHを構築してください。 + +1. 以下のファイルをクラスター内の任意のetcdノードから最初のコントロールプレーンノードにコピーしてください: + + ```sh + export CONTROL_PLANE="ubuntu@10.0.0.7" + scp /etc/kubernetes/pki/etcd/ca.crt "${CONTROL_PLANE}": + scp /etc/kubernetes/pki/apiserver-etcd-client.crt "${CONTROL_PLANE}": + scp /etc/kubernetes/pki/apiserver-etcd-client.key "${CONTROL_PLANE}": + ``` + + - `CONTROL_PLANE`の値を、最初のコントロールプレーンノードの`user@host`で置き換えます。 + +### 最初のコントロールプレーンノードの構築 + +1. 以下の内容で、`kubeadm-config.yaml`という名前の設定ファイルを作成します: + + apiVersion: kubeadm.k8s.io/v1beta2 + kind: ClusterConfiguration + kubernetesVersion: stable + controlPlaneEndpoint: "LOAD_BALANCER_DNS:LOAD_BALANCER_PORT" + etcd: + external: + endpoints: + - https://ETCD_0_IP:2379 + - https://ETCD_1_IP:2379 + - https://ETCD_2_IP:2379 + caFile: /etc/kubernetes/pki/etcd/ca.crt + certFile: /etc/kubernetes/pki/apiserver-etcd-client.crt + keyFile: /etc/kubernetes/pki/apiserver-etcd-client.key + + {{< note >}} + ここで、積層etcdと外部etcdの違いは、外部etcdの構成では`etcd`の`external`オブジェクトにetcdのエンドポイントが記述された設定ファイルが必要です。積層etcdトポロジーの場合、これは自動で管理されます。 + {{< /note >}} + + - テンプレート内の以下の変数を、クラスターに合わせて適切な値に置き換えます: + + - `LOAD_BALANCER_DNS` + - `LOAD_BALANCER_PORT` + - `ETCD_0_IP` + - `ETCD_1_IP` + - `ETCD_2_IP` + +以下の手順は、積層etcdの構築と同様です。 + +1. `sudo kubeadm init --config kubeadm-config.yaml --upload-certs`をこのノードで実行します。 + +1. 表示されたjoinコマンドを、あとで使うためにテキストファイルに書き込みます。 + +1. 使用するCNIプラグインを適用します。以下はWeave CNIの場合です: + + ```sh + kubectl apply -f "https://cloud.weave.works/k8s/net?k8s-version=$(kubectl version | base64 | tr -d '\n')" + ``` + +### 残りのコントロールプレーンノードの手順 + +手順は、積層etcd構築の場合と同じです: + +- 最初のコントロールプレーンノードが完全に初期化されているのを確認します。 +- テキストファイルに保存したjoinコマンドを使って、それぞれのコントロールプレーンノードをクラスターへ参加させます。コントロールプレーンノードは1台ずつクラスターへ参加させるのを推奨します。 +- `--certificate-key`で指定する復号キーは、デフォルトで2時間で期限切れになることを忘れないでください。 + +## コントロールプレーン起動後の共通タスク + +### workerのインストール + +`kubeadm init`コマンドから返されたコマンドを利用して、workerノードをクラスターに参加させることが可能です。 + +```sh +sudo kubeadm join 192.168.0.200:6443 --token 9vr73a.a8uxyaju799qwdjv --discovery-token-ca-cert-hash sha256:7c2e69131a36ae2a042a339b33381c6d0d43887e2de83720eff5359e26aec866 +``` + +## 証明書の手動配布 {#manual-certs} + +`--upload-certs`フラグを指定して`kubeadm init`を実行しない場合、プライマリコントロールプレーンノードから他のコントロールプレーンノードへ証明書を手動でコピーする必要があります。 + +コピーを行うには多くの方法があります。次の例では`ssh`と`scp`を使用しています。 1台のマシンから全てのノードをコントロールしたいのであれば、SSHが必要です。 @@ -114,61 +275,12 @@ alpha feature gateである`HighAvailability`はv1.12で非推奨となり、v1. sudo -E -s ``` -## 積み重なったコントロールプレーンとetcdノード +1. 全てのノードでSSHを設定したら、`kubeadm init`を実行した後、最初のコントロールノードプレーンノードで次のスクリプトを実行します。このスクリプトは、最初のコントロールプレーンノードから残りのコントロールプレーンノードへ証明書ファイルをコピーします: -### 最初のコントロールプレーンノードの手順 - -1. 最初のコントロールプレーンノードで、`kubeadm-config.yaml`という設定ファイルを作成します: - - apiVersion: kubeadm.k8s.io/v1beta1 - kind: ClusterConfiguration - kubernetesVersion: stable - apiServer: - certSANs: - - "LOAD_BALANCER_DNS" - controlPlaneEndpoint: "LOAD_BALANCER_DNS:LOAD_BALANCER_PORT" - - - `kubernetesVersion`には使用するKubernetesのバージョンを設定します。この例では`stable`を使用しています。 - - `controlPlaneEndpoint` はロードバランサーのアドレスかDNSと、ポートに一致する必要があります。 - - kubeadm、kubelet、kubectlとKubernetesのバージョンを一致させることが推奨されます。 - -1. ノードがきれいな状態であることを確認します: + 次の例の、`CONTROL_PLANE_IPS`を他のコントロールプレーンノードのIPアドレスに置き換えます。 ```sh - sudo kubeadm init --config=kubeadm-config.yaml - ``` - - このような出力がされます: - - ```sh - ... - You can now join any number of machines by running the following on each node - as root: - - kubeadm join 192.168.0.200:6443 --token j04n3m.octy8zely83cy2ts --discovery-token-ca-cert-hash sha256:84938d2a22203a8e56a787ec0c6ddad7bc7dbd52ebabc62fd5f4dbea72b14d1f - ``` - -1. この出力をテキストファイルにコピーします。あとで、他のコントロールプレーンノードをクラスターに参加させる際に必要になります。 - -1. Weave CNIプラグインをapplyします: - - ```sh - kubectl apply -f "https://cloud.weave.works/k8s/net?k8s-version=$(kubectl version | base64 | tr -d '\n')" - ``` - -1. 以下のコマンドを入力し、コンポーネントのPodが起動するのを確認します: - - ```sh - kubectl get pod -n kube-system -w - ``` - - - 最初のコントロールプレーンノードが初期化を完了してから、新しいノードを参加させることが推奨されます。 - -1. 証明書ファイルを最初のコントロールプレーンノードから残りのノードにコピーします: - - 以下の例では、`CONTROL_PLANE_IPS`を他のコントロールプレーンノードのIPアドレスで置き換えます。 - ```sh - USER=ubuntu # 変更可能 + USER=ubuntu # 環境に合わせる CONTROL_PLANE_IPS="10.0.0.7 10.0.0.8" for host in ${CONTROL_PLANE_IPS}; do scp /etc/kubernetes/pki/ca.crt "${USER}"@$host: @@ -178,21 +290,19 @@ alpha feature gateである`HighAvailability`はv1.12で非推奨となり、v1. scp /etc/kubernetes/pki/front-proxy-ca.crt "${USER}"@$host: scp /etc/kubernetes/pki/front-proxy-ca.key "${USER}"@$host: scp /etc/kubernetes/pki/etcd/ca.crt "${USER}"@$host:etcd-ca.crt + # 外部のetcdノード使用時はこちらのコマンドを実行 scp /etc/kubernetes/pki/etcd/ca.key "${USER}"@$host:etcd-ca.key - scp /etc/kubernetes/admin.conf "${USER}"@$host: done ``` -{{< caution >}} -上のリストにある証明書だけをコピーしてください。kubeadmが、参加するコントロールプレーンノード用に、残りの証明書と必要なSANの生成を行います。間違って全ての証明書をコピーしてしまったら、必要なSANがないため、追加ノードの作成は失敗するかもしれません。 -{{< /caution >}} + {{< caution >}} + 上のリストにある証明書だけをコピーしてください。kubeadmが、参加するコントロールプレーンノード用に、残りの証明書と必要なSANの生成を行います。間違って全ての証明書をコピーしてしまったら、必要なSANがないため、追加ノードの作成は失敗するかもしれません。 + {{< /caution >}} -### 残りのコントロールプレーンノードの手順 - -1. `scp`を使用する手順で作成したファイルを移動します: +1. 次に、クラスターに参加させる残りの各コントロールプレーンノードで`kubeadm join`を実行する前に次のスクリプトを実行する必要があります。このスクリプトは、前の手順でコピーした証明書をホームディレクトリから`/etc/kubernetes/pki`へ移動します: ```sh - USER=ubuntu # 変更可能 + USER=ubuntu # 環境に合わせる mkdir -p /etc/kubernetes/pki/etcd mv /home/${USER}/ca.crt /etc/kubernetes/pki/ mv /home/${USER}/ca.key /etc/kubernetes/pki/ @@ -201,103 +311,6 @@ alpha feature gateである`HighAvailability`はv1.12で非推奨となり、v1. mv /home/${USER}/front-proxy-ca.crt /etc/kubernetes/pki/ mv /home/${USER}/front-proxy-ca.key /etc/kubernetes/pki/ mv /home/${USER}/etcd-ca.crt /etc/kubernetes/pki/etcd/ca.crt + # 外部のetcdノード使用時はこちらのコマンドを実行 mv /home/${USER}/etcd-ca.key /etc/kubernetes/pki/etcd/ca.key - mv /home/${USER}/admin.conf /etc/kubernetes/admin.conf ``` - - この手順で、`/etc/kubernetes`フォルダーに必要な全てのファイルが書き込まれます。 - -1. `kubeadm init`を最初のノードで実行した際に取得したjoinコマンドを使って、このノードで`kubeadm join`を開始します。このようなコマンドになるはずです: - - ```sh - sudo kubeadm join 192.168.0.200:6443 --token j04n3m.octy8zely83cy2ts --discovery-token-ca-cert-hash sha256:84938d2a22203a8e56a787ec0c6ddad7bc7dbd52ebabc62fd5f4dbea72b14d1f --experimental-control-plane - ``` - - `--experimental-control-plane`フラグが追加されています。このフラグは、コントロールプレーンノードのクラスターへの参加を自動化します。 - -1. 以下のコマンドをタイプし、コンポーネントのPodが起動するのを確認します: - - ```sh - kubectl get pod -n kube-system -w - ``` - -1. これらのステップを、残りのコントロールプレーンノードに対して繰り返します。 - -## 外部のetcdノード - -### etcdクラスターの構築 - -- [こちらの手順](/ja/docs/setup/independent/setup-ha-etcd-with-kubeadm/)にしたがって、etcdクラスターを構築してください。 - -### 最初のコントロールプレーンノードの構築 - -1. 以下のファイルをetcdクラスターのどれかのノードからこのノードへコピーしてください: - - ```sh - export CONTROL_PLANE="ubuntu@10.0.0.7" - +scp /etc/kubernetes/pki/etcd/ca.crt "${CONTROL_PLANE}": - +scp /etc/kubernetes/pki/apiserver-etcd-client.crt "${CONTROL_PLANE}": - +scp /etc/kubernetes/pki/apiserver-etcd-client.key "${CONTROL_PLANE}": - ``` - - - `CONTROL_PLANE`の値を、このマシンの`user@host`で置き換えます。 - -1. 以下の内容で、`kubeadm-config.yaml`という名前の設定ファイルを作成します: - - apiVersion: kubeadm.k8s.io/v1beta1 - kind: ClusterConfiguration - kubernetesVersion: stable - apiServer: - certSANs: - - "LOAD_BALANCER_DNS" - controlPlaneEndpoint: "LOAD_BALANCER_DNS:LOAD_BALANCER_PORT" - etcd: - external: - endpoints: - - https://ETCD_0_IP:2379 - - https://ETCD_1_IP:2379 - - https://ETCD_2_IP:2379 - caFile: /etc/kubernetes/pki/etcd/ca.crt - certFile: /etc/kubernetes/pki/apiserver-etcd-client.crt - keyFile: /etc/kubernetes/pki/apiserver-etcd-client.key - - - ここで、積み重なったetcdと外部etcdの違いは、kubeadmコンフィグの`etcd`に`external`フィールドを使用していることです。積み重なったetcdトポロジーの場合、これは自動で管理されます。 - - - テンプレート内の以下の変数を、クラスターに合わせて適切な値に置き換えます: - - - `LOAD_BALANCER_DNS` - - `LOAD_BALANCER_PORT` - - `ETCD_0_IP` - - `ETCD_1_IP` - - `ETCD_2_IP` - -1. `kubeadm init --config kubeadm-config.yaml`をこのノードで実行します。 - -1. 表示されたjoinコマンドを、あとで使うためにテキストファイルに書き込みます。 - -1. Weave CNIプラグインをapplyします: - - ```sh - kubectl apply -f "https://cloud.weave.works/k8s/net?k8s-version=$(kubectl version | base64 | tr -d '\n')" - ``` - -### 残りのコントロールプレーンノードの手順 - -残りのコントロールプレーンノードを参加させるために、[こちらの手順](#残りのコントロールプレーンノードの手順)に従います。ローカルetcdメンバーが作られないことを除いて、積み重なったetcdの構築と同じ手順です。 - -まとめると: - -- 最初のコントロールプレーンノードが完全に初期化されているのを確認します。 -- 証明書を、最初のコントロールプレーンノードから他のコントロールプレーンノードへコピーします。 -- テキストファイルに保存したjoinコマンドに`--experimental-control-plane` フラグを加えたものを使って、それぞれのコントロールプレーンノードを参加させます。 - -## コントロールプレーン起動後の共通タスク - -### Podネットワークのインストール - -Podネットワークをインストールするには、[こちらの手順に従ってください](/ja/docs/setup/independent/create-cluster-kubeadm/#pod-network)。master設定ファイルで提供したPod CIDRのどれかに一致することを確認します。 - -### workerのインストール - -`kubeadm init`コマンドから返されたコマンドを利用して、workerノードをクラスターに参加させることが可能です。workerノードには、`--experimental-control-plane`フラグを追加する必要はありません。 - - diff --git a/content/ja/docs/setup/production-environment/tools/kubeadm/install-kubeadm.md b/content/ja/docs/setup/production-environment/tools/kubeadm/install-kubeadm.md index b03166af12..155ce30fd1 100644 --- a/content/ja/docs/setup/production-environment/tools/kubeadm/install-kubeadm.md +++ b/content/ja/docs/setup/production-environment/tools/kubeadm/install-kubeadm.md @@ -1,7 +1,7 @@ --- title: kubeadmのインストール content_type: task -weight: 20 +weight: 10 card: name: setup weight: 20 @@ -11,13 +11,13 @@ card: <!-- overview --> <img src="https://raw.githubusercontent.com/kubernetes/kubeadm/master/logos/stacked/color/kubeadm-stacked-color.png" align="right" width="150px"> + このページでは`kubeadm`コマンドをインストールする方法を示します。このインストール処理実行後にkubeadmを使用してクラスターを作成する方法については、[kubeadmを使用したシングルマスタークラスターの作成](/ja/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm/)を参照してください。 ## {{% heading "prerequisites" %}} - * 次のいずれかが動作しているマシンが必要です - Ubuntu 16.04+ - Debian 9+ @@ -48,6 +48,22 @@ card: 複数のネットワークアダプターがあり、Kubernetesコンポーネントにデフォルトで到達できない場合、IPルートを追加して、Kubernetesクラスターのアドレスが適切なアダプターを経由するように設定することをお勧めします。 +## iptablesがブリッジを通過するトラフィックを処理できるようにする + +Linuxノードのiptablesがブリッジを通過するトラフィックを正確に処理する要件として、`net.bridge.bridge-nf-call-iptables`を`sysctl`の設定ファイルで1に設定してください。例えば以下のようにします。 + +```bash +cat <<EOF > /etc/sysctl.d/k8s.conf +net.bridge.bridge-nf-call-ip6tables = 1 +net.bridge.bridge-nf-call-iptables = 1 +EOF +sysctl --system +``` + +この手順の前に`br_netfilter`モジュールがロードされていることを確認してください。`lsmod | grep br_netfilter`を実行することで確認できます。明示的にロードするには`modprobe br_netfilter`を実行してください。 + +詳細は[ネットワークプラグインの要件](https://kubernetes.io/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/#network-plugin-requirements)を参照してください。 + ## iptablesがnftablesバックエンドを使用しないようにする Linuxでは、カーネルのiptablesサブシステムの最新の代替品としてnftablesが利用できます。`iptables`ツールは互換性レイヤーとして機能し、iptablesのように動作しますが、実際にはnftablesを設定します。このnftablesバックエンドは現在のkubeadmパッケージと互換性がありません。(ファイアウォールルールが重複し、`kube-proxy`を破壊するためです。) @@ -55,11 +71,12 @@ Linuxでは、カーネルのiptablesサブシステムの最新の代替品と もしあなたのシステムの`iptables`ツールがnftablesバックエンドを使用している場合、これらの問題を避けるために`iptables`ツールをレガシーモードに切り替える必要があります。これは、少なくともDebian 10(Buster)、Ubuntu 19.04、Fedora 29、およびこれらのディストリビューションの新しいリリースでのデフォルトです。RHEL 8はレガシーモードへの切り替えをサポートしていないため、現在のkubeadmパッケージと互換性がありません。 {{< tabs name="iptables_legacy" >}} -{{% tab name="Debian or Ubuntu" %}} +{{% tab name="DebianまたはUbuntu" %}} ```bash # レガシーバイナリがインストールされていることを確認してください sudo apt-get install -y iptables arptables ebtables +# レガシーバージョンに切り替えてください。 sudo update-alternatives --set iptables /usr/sbin/iptables-legacy sudo update-alternatives --set ip6tables /usr/sbin/ip6tables-legacy sudo update-alternatives --set arptables /usr/sbin/arptables-legacy @@ -75,56 +92,66 @@ update-alternatives --set iptables /usr/sbin/iptables-legacy ## 必須ポートの確認 -### マスターノード +### コントロールプレーンノード | プロトコル | 通信の向き | ポート範囲 | 目的 | 使用者 | |-----------|------------|------------|-------------------------|---------------------------| -| TCP | Inbound | 6443* | Kubernetes API server | All | -| TCP | Inbound | 2379-2380 | etcd server client API | kube-apiserver, etcd | -| TCP | Inbound | 10250 | Kubelet API | Self, Control plane | -| TCP | Inbound | 10251 | kube-scheduler | Self | -| TCP | Inbound | 10252 | kube-controller-manager | Self | +| TCP | Inbound | 6443* | Kubernetes API server | 全て | +| TCP | Inbound | 2379-2380 | etcd server client API | kube-apiserver、etcd | +| TCP | Inbound | 10250 | Kubelet API | 自身、コントロールプレーン | +| TCP | Inbound | 10251 | kube-scheduler | 自身 | +| TCP | Inbound | 10252 | kube-controller-manager | 自身 | ### ワーカーノード -| プロトコル | 通信の向き | ポート範囲 | 目的 | 使用者 | -|-----------|------------|-------------|-------------------------|-------------------------| -| TCP | Inbound | 10250 | Kubelet API | Self, Control plane | -| TCP | Inbound | 30000-32767 | NodePort Services** | All | +| プロトコル | 通信の向き | ポート範囲 | 目的 | 使用者 | +|-----------|------------|-------------|-------------------------|---------------------------| +| TCP | Inbound | 10250 | Kubelet API | 自身、コントロールプレーン | +| TCP | Inbound | 30000-32767 | NodePort Service† | 全て | -** [NodePort Services](/ja/docs/concepts/services-networking/service/)のデフォルトのポートの範囲 +† [NodePort Service](/ja/docs/concepts/services-networking/service/)のデフォルトのポートの範囲 \*の項目は書き換え可能です。そのため、あなたが指定したカスタムポートも開いていることを確認する必要があります。 etcdポートはコントロールプレーンノードに含まれていますが、独自のetcdクラスターを外部またはカスタムポートでホストすることもできます。 -使用するPodネットワークプラグイン（以下を参照）のポートも開く必要があります。これは各Podネットワークプラグインによって異なるため、必要なポートについてはプラグインのドキュメントを参照してください。 +使用するPodネットワークプラグイン(以下を参照)のポートも開く必要があります。これは各Podネットワークプラグインによって異なるため、必要なポートについてはプラグインのドキュメントを参照してください。 ## ランタイムのインストール {#installing-runtime} -v1.6.0以降、KubernetesはデフォルトでCRI(Container Runtime Interface)の使用を有効にしています。 +Podのコンテナを実行するために、Kubernetesは{{< glossary_tooltip term_id="container-runtime" text="コンテナランタイム" >}}を使用します。 -また、v1.14.0以降、kubeadmは既知のドメインソケットのリストをスキャンして、Linuxノード上のコンテナランタイムを自動的に検出しようとします。検出可能なランタイムとソケットパスは、以下の表に記載されています。 +{{< tabs name="container_runtime" >}} +{{% tab name="Linuxノード" %}} -| ランタイム | ドメインソケット | -|------------|----------------------------------| -| Docker | /var/run/docker.sock | -| containerd | /run/containerd/containerd.sock | -| CRI-O | /var/run/crio/crio.sock | +デフォルトでは、Kubernetesは選択されたコンテナランタイムと通信するために{{< glossary_tooltip term_id="cri" text="Container Runtime Interface">}} (CRI)を使用します。 +ランタイムを指定しない場合、kubeadmはよく知られたUnixドメインソケットのリストをスキャンすることで、インストールされたコンテナランタイムの検出を試みます。 +次の表がコンテナランタイムと関連するソケットのパスリストです。 + +{{< table caption = "コンテナランタイムとソケットパス" >}} +| ランタイム | Unixドメインソケットのパス | +|------------|-----------------------------------| +| Docker | `/var/run/docker.sock` | +| containerd | `/run/containerd/containerd.sock` | +| CRI-O | `/var/run/crio/crio.sock` | +{{< /table >}} + +<br /> Dockerとcontainerdの両方が同時に検出された場合、Dockerが優先されます。Docker 18.09にはcontainerdが同梱されており、両方が検出可能であるため、この仕様が必要です。他の2つ以上のランタイムが検出された場合、kubeadmは適切なエラーメッセージで終了します。 -Linux以外のノードでは、デフォルトで使用されるコンテナランタイムはDockerです。 +kubeletは、組み込まれた`dockershim`CRIを通してDockerと連携します。 -もしコンテナランタイムとしてDockerを選択した場合、`kebelet`内に組み込まれた`dockershim` CRIが使用されます。 +詳細は、[コンテナランタイム](/ja/docs/setup/production-environment/container-runtimes/)を参照してください。 +{{% /tab %}} +{{% tab name="その他のOS" %}} +デフォルトでは、kubeadmは{{< glossary_tooltip term_id="docker" >}}をコンテナランタイムとして使用します。 +kubeletは、組み込まれた`dockershim`CRIを通してDockerと連携します。 -その他のCRIに基づくランタイムでは以下を使用します +詳細は、[コンテナランタイム](/ja/docs/setup/production-environment/container-runtimes/)を参照してください。 +{{% /tab %}} +{{< /tabs >}} -- [containerd](https://github.com/containerd/cri) (CRI plugin built into containerd) -- [cri-o](https://cri-o.io/) -- [frakti](https://github.com/kubernetes/frakti) - -詳細は[CRIのインストール](/ja/docs/setup/production-environment/container-runtimes/)を参照してください。 ## kubeadm、kubelet、kubectlのインストール @@ -142,7 +169,7 @@ kubeadmは`kubelet`や`kubectl`をインストールまたは管理**しない** `kubectl`のインストールに関する詳細情報は、[kubectlのインストールおよびセットアップ](/ja/docs/tasks/tools/install-kubectl/)を参照してください。 {{< warning >}} -これらの手順はシステムアップグレードによるすべてのKubernetesパッケージの更新を除きます。これはkubeadmとKubernetesが[アップグレードにおける特別な注意](docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade/)を必要とするからです。 +これらの手順はシステムアップグレードによるすべてのKubernetesパッケージの更新を除きます。これはkubeadmとKubernetesが[アップグレードにおける特別な注意](/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade/)を必要とするからです。 {{</ warning >}} バージョン差異(version skew)に関しては下記を参照してください。 @@ -151,7 +178,7 @@ kubeadmは`kubelet`や`kubectl`をインストールまたは管理**しない** * Kubeadm-specific [バージョン互換ポリシー](/ja/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm/#version-skew-policy) {{< tabs name="k8s_install" >}} -{{% tab name="Ubuntu, Debian or HypriotOS" %}} +{{% tab name="Ubuntu、Debian、またはHypriotOS" %}} ```bash sudo apt-get update && sudo apt-get install -y apt-transport-https curl curl -s https://packages.cloud.google.com/apt/doc/apt-key.gpg | sudo apt-key add - @@ -163,7 +190,7 @@ sudo apt-get install -y kubelet kubeadm kubectl sudo apt-mark hold kubelet kubeadm kubectl ``` {{% /tab %}} -{{% tab name="CentOS, RHEL or Fedora" %}} +{{% tab name="CentOS、RHEL、またはFedora" %}} ```bash cat <<EOF > /etc/yum.repos.d/kubernetes.repo [kubernetes] @@ -175,7 +202,7 @@ repo_gpgcheck=1 gpgkey=https://packages.cloud.google.com/yum/doc/yum-key.gpg https://packages.cloud.google.com/yum/doc/rpm-package-key.gpg EOF -# Set SELinux in permissive mode (effectively disabling it) +# SELinuxをpermissiveモードに設定する(効果的に無効化する) setenforce 0 sed -i 's/^SELINUX=enforcing$/SELINUX=permissive/' /etc/selinux/config @@ -186,23 +213,13 @@ systemctl enable --now kubelet **Note:** - - Setting SELinux in permissive mode by running `setenforce 0` and `sed ...` effectively disables it. - This is required to allow containers to access the host filesystem, which is needed by pod networks for example. - You have to do this until SELinux support is improved in the kubelet. - - Some users on RHEL/CentOS 7 have reported issues with traffic being routed incorrectly due to iptables being bypassed. You should ensure - `net.bridge.bridge-nf-call-iptables` is set to 1 in your `sysctl` config, e.g. + - `setenforce 0`および`sed ...`を実行することによりSELinuxをpermissiveモードに設定し、効果的に無効化できます。 + これはコンテナがホストのファイルシステムにアクセスするために必要です。例えば、Podのネットワークに必要とされます。 + kubeletにおけるSELinuxのサポートが改善されるまでは、これを実行しなければなりません。 - ```bash - cat <<EOF > /etc/sysctl.d/k8s.conf - net.bridge.bridge-nf-call-ip6tables = 1 - net.bridge.bridge-nf-call-iptables = 1 - EOF - sysctl --system - ``` - - Make sure that the `br_netfilter` module is loaded before this step. This can be done by running `lsmod | grep br_netfilter`. To load it explicitly call `modprobe br_netfilter`. {{% /tab %}} {{% tab name="Container Linux" %}} -Install CNI plugins (required for most pod network): +CNIプラグインをインストールする(ほとんどのPodのネットワークに必要です): ```bash CNI_VERSION="v0.8.2" @@ -210,7 +227,7 @@ mkdir -p /opt/cni/bin curl -L "https://github.com/containernetworking/plugins/releases/download/${CNI_VERSION}/cni-plugins-linux-amd64-${CNI_VERSION}.tgz" | tar -C /opt/cni/bin -xz ``` -Install crictl (required for kubeadm / Kubelet Container Runtime Interface (CRI)) +crictlをインストールする (kubeadm / Kubelet Container Runtime Interface (CRI)に必要です) ```bash CRICTL_VERSION="v1.16.0" @@ -218,7 +235,7 @@ mkdir -p /opt/bin curl -L "https://github.com/kubernetes-sigs/cri-tools/releases/download/${CRICTL_VERSION}/crictl-${CRICTL_VERSION}-linux-amd64.tar.gz" | tar -C /opt/bin -xz ``` -Install `kubeadm`, `kubelet`, `kubectl` and add a `kubelet` systemd service: +`kubeadm`、`kubelet`、`kubectl`をインストールし`kubelet`をsystemd serviceに登録します: ```bash RELEASE="$(curl -sSL https://dl.k8s.io/release/stable.txt)" @@ -233,7 +250,7 @@ mkdir -p /etc/systemd/system/kubelet.service.d curl -sSL "https://raw.githubusercontent.com/kubernetes/kubernetes/${RELEASE}/build/debs/10-kubeadm.conf" | sed "s:/usr/bin:/opt/bin:g" > /etc/systemd/system/kubelet.service.d/10-kubeadm.conf ``` -Enable and start `kubelet`: +`kubelet`を有効化し起動します: ```bash systemctl enable --now kubelet @@ -243,7 +260,7 @@ systemctl enable --now kubelet kubeadmが何をすべきか指示するまで、kubeletはクラッシュループで数秒ごとに再起動します。 -## マスターノードのkubeletによって使用されるcgroupドライバーの設定 +## コントロールプレーンノードのkubeletによって使用されるcgroupドライバーの設定 Dockerを使用した場合、kubeadmは自動的にkubelet向けのcgroupドライバーを検出し、それを実行時に`/var/lib/kubelet/kubeadm-flags.env`ファイルに設定します。 @@ -255,7 +272,7 @@ KUBELET_EXTRA_ARGS=--cgroup-driver=<value> このファイルは、kubeletの追加のユーザー定義引数を取得するために、`kubeadm init`および`kubeadm join`によって使用されます。 -CRIのcgroupドライバーが`cgroupfs`でない場合に**のみ**それを行う必要があることに注意してください。なぜなら、これは既にkubeletのデフォルト値であるためです。 +CRIのcgroupドライバーが`cgroupfs`でない場合に**のみ**それを行う必要があることに注意してください。なぜなら、これはすでにkubeletのデフォルト値であるためです。 kubeletをリスタートする方法: @@ -274,5 +291,3 @@ kubeadmで問題が発生した場合は、[トラブルシューティング](/ * [kubeadmを使用したシングルコントロールプレーンクラスターの作成](/ja/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm/) - - diff --git a/content/ja/docs/setup/production-environment/tools/kubeadm/kubelet-integration.md b/content/ja/docs/setup/production-environment/tools/kubeadm/kubelet-integration.md index 95ad810bfc..e061315381 100644 --- a/content/ja/docs/setup/production-environment/tools/kubeadm/kubelet-integration.md +++ b/content/ja/docs/setup/production-environment/tools/kubeadm/kubelet-integration.md @@ -8,21 +8,11 @@ weight: 80 {{< feature-state for_k8s_version="1.11" state="stable" >}} -The lifecycle of the kubeadm CLI tool is decoupled from the -[kubelet](/docs/reference/command-line-tools-reference/kubelet), which is a daemon that runs -on each node within the Kubernetes cluster. The kubeadm CLI tool is executed by the user when Kubernetes is -initialized or upgraded, whereas the kubelet is always running in the background. +kubeadm CLIツールのライフサイクルは、Kubernetesクラスター内の各ノード上で稼働するデーモンである[kubelet](/docs/reference/command-line-tools-reference/kubelet)から分離しています。kubeadm CLIツールはKubernetesを初期化またはアップグレードする際にユーザーによって実行されます。一方で、kubeletは常にバックグラウンドで稼働しています。 -Since the kubelet is a daemon, it needs to be maintained by some kind of a init -system or service manager. When the kubelet is installed using DEBs or RPMs, -systemd is configured to manage the kubelet. You can use a different service -manager instead, but you need to configure it manually. +kubeletはデーモンのため、何らかのinitシステムやサービスマネージャーで管理する必要があります。DEBパッケージやRPMパッケージからkubeletをインストールすると、systemdはkubeletを管理するように設定されます。代わりに別のサービスマネージャーを使用することもできますが、手動で設定する必要があります。 -Some kubelet configuration details need to be the same across all kubelets involved in the cluster, while -other configuration aspects need to be set on a per-kubelet basis, to accommodate the different -characteristics of a given machine, such as OS, storage, and networking. You can manage the configuration -of your kubelets manually, but [kubeadm now provides a `KubeletConfiguration` API type for managing your -kubelet configurations centrally](#configure-kubelets-using-kubeadm). +いくつかのkubeletの設定は、クラスターに含まれる全てのkubeletで同一である必要があります。一方で、特定のマシンの異なる特性(OS、ストレージ、ネットワークなど)に対応するために、kubeletごとに設定が必要なものもあります。手動で設定を管理することも可能ですが、kubeadmは[一元的な設定管理](#configure-kubelets-using-kubeadm)のための`KubeletConfiguration`APIを提供しています。 @@ -30,29 +20,19 @@ kubelet configurations centrally](#configure-kubelets-using-kubeadm). ## Kubeletの設定パターン -The following sections describe patterns to kubelet configuration that are simplified by -using kubeadm, rather than managing the kubelet configuration for each Node manually. +以下のセクションでは、kubeadmを使用したkubeletの設定パターンについて説明します。これは手動で各Nodeの設定を管理するよりも簡易に行うことができます。 -### 各kubeletにクラスターレベルの設定を配布 +### 各kubeletにクラスターレベルの設定を配布 {#propagating-cluster-level-configuration-to-each-kubelet} -You can provide the kubelet with default values to be used by `kubeadm init` and `kubeadm join` -commands. Interesting examples include using a different CRI runtime or setting the default subnet -used by services. +`kubeadm init`および`kubeadm join`コマンドを使用すると、kubeletにデフォルト値を設定することができます。興味深い例として、異なるCRIランタイムを使用したり、Serviceが使用するデフォルトのサブネットを設定したりすることができます。 -If you want your services to use the subnet `10.96.0.0/12` as the default for services, you can pass -the `--service-cidr` parameter to kubeadm: +Serviceが使用するデフォルトのサブネットとして`10.96.0.0/12`を設定する必要がある場合は、`--service-cidr`パラメーターを渡します。 ```bash kubeadm init --service-cidr 10.96.0.0/12 ``` -Virtual IPs for services are now allocated from this subnet. You also need to set the DNS address used -by the kubelet, using the `--cluster-dns` flag. This setting needs to be the same for every kubelet -on every manager and Node in the cluster. The kubelet provides a versioned, structured API object -that can configure most parameters in the kubelet and push out this configuration to each running -kubelet in the cluster. This object is called **the kubelet's ComponentConfig**. -The ComponentConfig allows the user to specify flags such as the cluster DNS IP addresses expressed as -a list of values to a camelCased key, illustrated by the following example: +これによってServiceの仮想IPはこのサブネットから割り当てられるようになりました。また、`--cluster-dns`フラグを使用し、kubeletが用いるDNSアドレスを設定する必要もあります。この設定はクラスター内の全てのマネージャーとNode上で同一である必要があります。kubeletは、**kubeletのComponentConfig**と呼ばれる、バージョン管理と構造化されたAPIオブジェクトを提供します。これはkubelet内のほとんどのパラメーターを設定し、その設定をクラスター内で稼働中の各kubeletへ適用することを可能にします。以下の例のように、キャメルケースのキーに値のリストとしてクラスターDNS IPアドレスなどのフラグを指定することができます。 ```yaml apiVersion: kubelet.config.k8s.io/v1beta1 @@ -61,109 +41,72 @@ clusterDNS: - 10.96.0.10 ``` -For more details on the ComponentConfig have a look at [this section](#configure-kubelets-using-kubeadm). +ComponentConfigの詳細については、[このセクション](#configure-kubelets-using-kubeadm)をご覧ください -### インスタンス固有の設定内容を適用 +### インスタンス固有の設定内容を適用 {#providing-instance-specific-configuration-details} -Some hosts require specific kubelet configurations, due to differences in hardware, operating system, -networking, or other host-specific parameters. The following list provides a few examples. +いくつかのホストでは、ハードウェア、オペレーティングシステム、ネットワーク、その他ホスト固有のパラメータの違いのため、特定のkubeletの設定を必要とします。以下にいくつかの例を示します。 -- The path to the DNS resolution file, as specified by the `--resolv-conf` kubelet - configuration flag, may differ among operating systems, or depending on whether you are using - `systemd-resolved`. If this path is wrong, DNS resolution will fail on the Node whose kubelet - is configured incorrectly. +- DNS解決ファイルへのパスは`--resolv-conf`フラグで指定することができますが、オペレーティングシステムや`systemd-resolved`を使用するかどうかによって異なる場合があります。このパスに誤りがある場合、そのNode上でのDNS解決は失敗します。 +- クラウドプロバイダーを使用していない場合、Node APIオブジェクト`.metadata.name`はデフォルトでマシンのホスト名に設定されます。異なるNode名を指定する必要がある場合には、`--hostname-override`フラグによってこの挙動を書き換えることができます。 +- 現在のところ、kubletはCRIランタイムが使用するcgroupドライバを自動で検知することができませんが、kubeletの稼働を保証するためには、`--cgroup-driver`の値はCRIランタイムが使用するcgroupドライバに一致していなければなりません。 +- クラスターが使用するCRIランタイムによっては、異なるフラグを指定する必要があるかもしれません。例えば、Dockerを使用している場合には、`--network-plugin=cni`のようなフラグを指定する必要があります。外部のランタイムを使用している場合には、`--container-runtime=remote`と指定し、`--container-runtime-endpoint=<path>`のようにCRIエンドポイントを指定する必要があります。 -- The Node API object `.metadata.name` is set to the machine's hostname by default, - unless you are using a cloud provider. You can use the `--hostname-override` flag to override the - default behavior if you need to specify a Node name different from the machine's hostname. +これらのフラグは、systemdなどのサービスマネージャー内のkubeletの設定によって指定することができます。 -- Currently, the kubelet cannot automatically detects the cgroup driver used by the CRI runtime, - but the value of `--cgroup-driver` must match the cgroup driver used by the CRI runtime to ensure - the health of the kubelet. +## kubeadmを使用したkubeletの設定 {#configure-kubelets-using-kubeadm} -- Depending on the CRI runtime your cluster uses, you may need to specify different flags to the kubelet. - For instance, when using Docker, you need to specify flags such as `--network-plugin=cni`, but if you - are using an external runtime, you need to specify `--container-runtime=remote` and specify the CRI - endpoint using the `--container-runtime-path-endpoint=<path>`. +`kubeadm ... --config some-config-file.yaml`のように、カスタムの`KubeletConfiguration`APIオブジェクトを設定ファイルを介して渡すことで、kubeadmによって起動されるkubeletに設定を反映することができます。 -You can specify these flags by configuring an individual kubelet's configuration in your service manager, -such as systemd. +`kubeadm config print init-defaults --component-configs KubeletConfiguration`を実行することによって、この構造体の全てのデフォルト値を確認することができます。 -## kubeadmを使用したkubeletの設定 - -It is possible to configure the kubelet that kubeadm will start if a custom `KubeletConfiguration` -API object is passed with a configuration file like so `kubeadm ... --config some-config-file.yaml`. - -By calling `kubeadm config print init-defaults --component-configs KubeletConfiguration` you can -see all the default values for this structure. - -Also have a look at the [API reference for the -kubelet ComponentConfig](https://godoc.org/k8s.io/kubernetes/pkg/kubelet/apis/config#KubeletConfiguration) -for more information on the individual fields. +また、各フィールドの詳細については、[kubelet ComponentConfigに関するAPIリファレンス](https://godoc.org/k8s.io/kubernetes/pkg/kubelet/apis/config#KubeletConfiguration)を参照してください。 ### `kubeadm init`実行時の流れ -When you call `kubeadm init`, the kubelet configuration is marshalled to disk -at `/var/lib/kubelet/config.yaml`, and also uploaded to a ConfigMap in the cluster. The ConfigMap -is named `kubelet-config-1.X`, where `.X` is the minor version of the Kubernetes version you are -initializing. A kubelet configuration file is also written to `/etc/kubernetes/kubelet.conf` with the -baseline cluster-wide configuration for all kubelets in the cluster. This configuration file -points to the client certificates that allow the kubelet to communicate with the API server. This -addresses the need to -[propagate cluster-level configuration to each kubelet](#propagating-cluster-level-configuration-to-each-kubelet). +`kubeadm init`を実行した場合、kubeletの設定は`/var/lib/kubelet/config.yaml`に格納され、クラスターのConfigMapにもアップロードされます。ConfigMapは`kubelet-config-1.X`という名前で、`.X`は初期化するKubernetesのマイナーバージョンを表します。またこの設定ファイルは、クラスタ内の全てのkubeletのために、クラスター全体設定の基準と共に`/etc/kubernetes/kubelet.conf`にも書き込まれます。この設定ファイルは、kubeletがAPIサーバと通信するためのクライアント証明書を指し示します。これは、[各kubeletにクラスターレベルの設定を配布](#propagating-cluster-level-configuration-to-each-kubelet)することの必要性を示しています。 -To address the second pattern of -[providing instance-specific configuration details](#providing-instance-specific-configuration-details), -kubeadm writes an environment file to `/var/lib/kubelet/kubeadm-flags.env`, which contains a list of -flags to pass to the kubelet when it starts. The flags are presented in the file like this: +二つ目のパターンである、[インスタンス固有の設定内容を適用](#providing-instance-specific-configuration-details)するために、kubeadmは環境ファイルを`/var/lib/kubelet/kubeadm-flags.env`へ書き出します。このファイルは以下のように、kubelet起動時に渡されるフラグのリストを含んでいます。 ```bash KUBELET_KUBEADM_ARGS="--flag1=value1 --flag2=value2 ..." ``` -In addition to the flags used when starting the kubelet, the file also contains dynamic -parameters such as the cgroup driver and whether to use a different CRI runtime socket -(`--cri-socket`). +kubelet起動時に渡されるフラグに加えて、このファイルはcgroupドライバーや異なるCRIランタイムソケットを使用するかどうか(`--cri-socket`)といった動的なパラメータも含みます。 -After marshalling these two files to disk, kubeadm attempts to run the following two -commands, if you are using systemd: +これら二つのファイルがディスク上に格納されると、systemdを使用している場合、kubeadmは以下の二つのコマンドを実行します。 ```bash systemctl daemon-reload && systemctl restart kubelet ``` -If the reload and restart are successful, the normal `kubeadm init` workflow continues. +リロードと再起動に成功すると、通常の`kubeadm init`のワークフローが続きます。 ### `kubeadm join`実行時の流れ -When you run `kubeadm join`, kubeadm uses the Bootstrap Token credential to perform -a TLS bootstrap, which fetches the credential needed to download the -`kubelet-config-1.X` ConfigMap and writes it to `/var/lib/kubelet/config.yaml`. The dynamic -environment file is generated in exactly the same way as `kubeadm init`. +`kubeadm join`を実行した場合、kubeadmはBootstrap Token証明書を使用してTLS bootstrapを行い、ConfigMap`kubelet-config-1.X`をダウンロードするために必要なクレデンシャルを取得し、`/var/lib/kubelet/config.yaml`へ書き込みます。動的な環境ファイルは、`kubeadm init`の場合と全く同様の方法で生成されます。 -Next, `kubeadm` runs the following two commands to load the new configuration into the kubelet: +次に、`kubeadm`は、kubeletに新たな設定を読み込むために、以下の二つのコマンドを実行します。 ```bash systemctl daemon-reload && systemctl restart kubelet ``` -After the kubelet loads the new configuration, kubeadm writes the -`/etc/kubernetes/bootstrap-kubelet.conf` KubeConfig file, which contains a CA certificate and Bootstrap -Token. These are used by the kubelet to perform the TLS Bootstrap and obtain a unique -credential, which is stored in `/etc/kubernetes/kubelet.conf`. When this file is written, the kubelet -has finished performing the TLS Bootstrap. +kubeletが新たな設定を読み込むと、kubeadmは、KubeConfigファイル`/etc/kubernetes/bootstrap-kubelet.conf`を書き込みます。これは、CA証明書とBootstrap Tokenを含みます。これらはkubeletがTLS Bootstrapを行い`/etc/kubernetes/kubelet.conf`に格納されるユニークなクレデンシャルを取得するために使用されます。ファイルが書き込まれると、kubeletはTLS Bootstrapを終了します。 -## kubelet用のsystemdファイル +## kubelet用のsystemdファイル {#the-kubelet-drop-in-file-for-systemd} -The configuration file installed by the kubeadm DEB or RPM package is written to -`/etc/systemd/system/kubelet.service.d/10-kubeadm.conf` and is used by systemd. +`kubeadm`には、systemdがどのようにkubeletを実行するかを指定した設定ファイルが同梱されています。 +kubeadm CLIコマンドは決してこのsystemdファイルには触れないことに注意してください。 + +kubeadmの[DEBパッケージ](https://github.com/kubernetes/kubernetes/blob/master/build/debs/10-kubeadm.conf)または[RPMパッケージ](https://github.com/kubernetes/kubernetes/blob/master/build/rpms/10-kubeadm.conf)によってインストールされたこの設定ファイルは、`/etc/systemd/system/kubelet.service.d/10-kubeadm.conf`に書き込まれ、systemdで使用されます。基本的な`kubelet.service`([RPM用](https://github.com/kubernetes/release/blob/master/cmd/kubepkg/templates/latest/rpm/kubelet/kubelet.service)または、 [DEB用](https://github.com/kubernetes/release/blob/master/cmd/kubepkg/templates/latest/deb/kubelet/lib/systemd/system/kubelet.service))を拡張します。 ```none [Service] Environment="KUBELET_KUBECONFIG_ARGS=--bootstrap-kubeconfig=/etc/kubernetes/bootstrap-kubelet.conf --kubeconfig=/etc/kubernetes/kubelet.conf" Environment="KUBELET_CONFIG_ARGS=--config=/var/lib/kubelet/config.yaml" -# This is a file that "kubeadm init" and "kubeadm join" generates at runtime, populating +# This is a file that "kubeadm init" and "kubeadm join" generate at runtime, populating the KUBELET_KUBEADM_ARGS variable dynamically EnvironmentFile=-/var/lib/kubelet/kubeadm-flags.env # This is a file that the user can use for overrides of the kubelet args as a last resort. Preferably, @@ -174,27 +117,23 @@ ExecStart= ExecStart=/usr/bin/kubelet $KUBELET_KUBECONFIG_ARGS $KUBELET_CONFIG_ARGS $KUBELET_KUBEADM_ARGS $KUBELET_EXTRA_ARGS ``` -This file specifies the default locations for all of the files managed by kubeadm for the kubelet. +このファイルは、kubeadmがkubelet用に管理する全ファイルが置かれるデフォルトの場所を指定します。 -- The KubeConfig file to use for the TLS Bootstrap is `/etc/kubernetes/bootstrap-kubelet.conf`, - but it is only used if `/etc/kubernetes/kubelet.conf` does not exist. -- The KubeConfig file with the unique kubelet identity is `/etc/kubernetes/kubelet.conf`. -- The file containing the kubelet's ComponentConfig is `/var/lib/kubelet/config.yaml`. -- The dynamic environment file that contains `KUBELET_KUBEADM_ARGS` is sourced from `/var/lib/kubelet/kubeadm-flags.env`. -- The file that can contain user-specified flag overrides with `KUBELET_EXTRA_ARGS` is sourced from - `/etc/default/kubelet` (for DEBs), or `/etc/sysconfig/kubelet` (for RPMs). `KUBELET_EXTRA_ARGS` - is last in the flag chain and has the highest priority in the event of conflicting settings. +- TLS Bootstrapに使用するKubeConfigファイルは`/etc/kubernetes/bootstrap-kubelet.conf`ですが、`/etc/kubernetes/kubelet.conf`が存在しない場合にのみ使用します。 +- ユニークなkublet識別子を含むKubeConfigファイルは`/etc/kubernetes/kubelet.conf`です。 +- kubeletのComponentConfigを含むファイルは`/var/lib/kubelet/config.yaml`です。 +- `KUBELET_KUBEADM_ARGS`を含む動的な環境ファイルは`/var/lib/kubelet/kubeadm-flags.env`から取得します。 +- `KUBELET_EXTRA_ARGS`によるユーザー定義のフラグの上書きを格納できるファイルは`/etc/default/kubelet`(DEBの場合)、または`/etc/sysconfig/kubelet`(RPMの場合)から取得します。`KUBELET_EXTRA_ARGS`はフラグの連なりの最後に位置し、優先度が最も高いです。 ## Kubernetesバイナリとパッケージの内容 -The DEB and RPM packages shipped with the Kubernetes releases are: +Kubernetesに同梱されるDEB、RPMのパッケージは以下の通りです。 -| Package name | Description | +| パッケージ名 | 説明 | |--------------|-------------| -| `kubeadm` | Installs the `/usr/bin/kubeadm` CLI tool and the [kubelet drop-in file](#the-kubelet-drop-in-file-for-systemd) for the kubelet. | -| `kubelet` | Installs the `/usr/bin/kubelet` binary. | -| `kubectl` | Installs the `/usr/bin/kubectl` binary. | -| `kubernetes-cni` | Installs the official CNI binaries into the `/opt/cni/bin` directory. | -| `cri-tools` | Installs the `/usr/bin/crictl` binary from the [cri-tools git repository](https://github.com/kubernetes-incubator/cri-tools). | - +| `kubeadm` | `/usr/bin/kubeadm`CLIツールと、[kubelet用のsystemdファイル](#the-kubelet-drop-in-file-for-systemd)をインストールします。 | +| `kubelet` | kubeletバイナリを`/usr/bin`に、CNIバイナリを`/opt/cni/bin`にインストールします。 | +| `kubectl` | `/usr/bin/kubectl`バイナリをインストールします。 | +| `kubernetes-cni` | 公式のCNIバイナリを`/opt/cni/bin`ディレクトリにインストールします。 | +| `cri-tools` | `/usr/bin/crictl`バイナリを[cri-tools gitリポジトリ](https://github.com/kubernetes-incubator/cri-tools)からインストールします。 | diff --git a/content/ja/docs/setup/production-environment/tools/kubeadm/self-hosting.md b/content/ja/docs/setup/production-environment/tools/kubeadm/self-hosting.md index 08f9efe0b8..a7bee37727 100644 --- a/content/ja/docs/setup/production-environment/tools/kubeadm/self-hosting.md +++ b/content/ja/docs/setup/production-environment/tools/kubeadm/self-hosting.md @@ -8,7 +8,7 @@ weight: 100 ### Self-hosting the Kubernetes control plane {#self-hosting} -As of 1.8, you can experimentally create a _self-hosted_ Kubernetes control +kubeadm allows you to experimentally create a _self-hosted_ Kubernetes control plane. This means that key components such as the API server, controller manager, and scheduler run as [DaemonSet pods](/ja/docs/concepts/workloads/controllers/daemonset/) configured via the Kubernetes API instead of [static pods](/docs/tasks/administer-cluster/static-pod/) diff --git a/content/ja/docs/setup/production-environment/tools/kubeadm/setup-ha-etcd-with-kubeadm.md b/content/ja/docs/setup/production-environment/tools/kubeadm/setup-ha-etcd-with-kubeadm.md index 90725de1d4..0d73dc2df6 100644 --- a/content/ja/docs/setup/production-environment/tools/kubeadm/setup-ha-etcd-with-kubeadm.md +++ b/content/ja/docs/setup/production-environment/tools/kubeadm/setup-ha-etcd-with-kubeadm.md @@ -6,6 +6,14 @@ weight: 70 <!-- overview --> +{{< note >}} +While kubeadm is being used as the management tool for external etcd nodes +in this guide, please note that kubeadm does not plan to support certificate rotation +or upgrades for such nodes. The long term plan is to empower the tool +[etcdadm](https://github.com/kubernetes-sigs/etcdadm) to manage these +aspects. +{{< /note >}} + Kubeadm defaults to running a single member etcd cluster in a static pod managed by the kubelet on the control plane node. This is not a high availability setup as the etcd cluster contains only one member and cannot sustain any members @@ -52,7 +60,8 @@ this example. cat << EOF > /etc/systemd/system/kubelet.service.d/20-etcd-service-manager.conf [Service] ExecStart= - ExecStart=/usr/bin/kubelet --address=127.0.0.1 --pod-manifest-path=/etc/kubernetes/manifests + # Replace "systemd" with the cgroup driver of your container runtime. The default value in the kubelet is "cgroupfs". + ExecStart=/usr/bin/kubelet --address=127.0.0.1 --pod-manifest-path=/etc/kubernetes/manifests --cgroup-driver=systemd Restart=always EOF @@ -81,7 +90,7 @@ this example. HOST=${ETCDHOSTS[$i]} NAME=${NAMES[$i]} cat << EOF > /tmp/${HOST}/kubeadmcfg.yaml - apiVersion: "kubeadm.k8s.io/v1beta1" + apiVersion: "kubeadm.k8s.io/v1beta2" kind: ClusterConfiguration etcd: local: @@ -241,15 +250,17 @@ this example. ```sh docker run --rm -it \ --net host \ - -v /etc/kubernetes:/etc/kubernetes quay.io/coreos/etcd:${ETCD_TAG} etcdctl \ - --cert-file /etc/kubernetes/pki/etcd/peer.crt \ - --key-file /etc/kubernetes/pki/etcd/peer.key \ - --ca-file /etc/kubernetes/pki/etcd/ca.crt \ - --endpoints https://${HOST0}:2379 cluster-health + -v /etc/kubernetes:/etc/kubernetes k8s.gcr.io/etcd:${ETCD_TAG} etcdctl \ + --cert /etc/kubernetes/pki/etcd/peer.crt \ + --key /etc/kubernetes/pki/etcd/peer.key \ + --cacert /etc/kubernetes/pki/etcd/ca.crt \ + --endpoints https://${HOST0}:2379 endpoint health --cluster ... - cluster is healthy + https://[HOST0 IP]:2379 is healthy: successfully committed proposal: took = 16.283339ms + https://[HOST1 IP]:2379 is healthy: successfully committed proposal: took = 19.44402ms + https://[HOST2 IP]:2379 is healthy: successfully committed proposal: took = 35.926451ms ``` - - Set `${ETCD_TAG}` to the version tag of your etcd image. For example `v3.2.24`. + - Set `${ETCD_TAG}` to the version tag of your etcd image. For example `3.4.3-0`. To see the etcd image and tag that kubeadm uses execute `kubeadm config images list --kubernetes-version ${K8S_VERSION}`, where `${K8S_VERSION}` is for example `v1.17.0` - Set `${HOST0}`to the IP address of the host you are testing. diff --git a/content/ja/docs/setup/production-environment/tools/kubeadm/troubleshooting-kubeadm.md b/content/ja/docs/setup/production-environment/tools/kubeadm/troubleshooting-kubeadm.md index 669cc3a302..8e9067a4eb 100644 --- a/content/ja/docs/setup/production-environment/tools/kubeadm/troubleshooting-kubeadm.md +++ b/content/ja/docs/setup/production-environment/tools/kubeadm/troubleshooting-kubeadm.md @@ -1,7 +1,7 @@ --- title: kubeadmのトラブルシューティング content_type: concept -weight: 90 +weight: 20 --- <!-- overview --> @@ -152,7 +152,7 @@ Unable to connect to the server: x509: certificate signed by unknown authority ( - Verify that the `$HOME/.kube/config` file contains a valid certificate, and regenerate a certificate if necessary. The certificates in a kubeconfig file - are base64 encoded. The `base64 -d` command can be used to decode the certificate + are base64 encoded. The `base64 --decode` command can be used to decode the certificate and `openssl x509 -text -noout` can be used for viewing the certificate information. - Unset the `KUBECONFIG` environment variable using: @@ -170,6 +170,7 @@ Unable to connect to the server: x509: certificate signed by unknown authority ( ```sh mv $HOME/.kube $HOME/.kube.bak + mkdir $HOME/.kube sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config sudo chown $(id -u):$(id -g) $HOME/.kube/config ``` @@ -197,15 +198,15 @@ Error from server: Get https://10.19.0.41:10250/containerLogs/default/mysql-ddc6 ``` - This may be due to Kubernetes using an IP that can not communicate with other IPs on the seemingly same subnet, possibly by policy of the machine provider. -- Digital Ocean assigns a public IP to `eth0` as well as a private one to be used internally as anchor for their floating IP feature, yet `kubelet` will pick the latter as the node's `InternalIP` instead of the public one. +- DigitalOcean assigns a public IP to `eth0` as well as a private one to be used internally as anchor for their floating IP feature, yet `kubelet` will pick the latter as the node's `InternalIP` instead of the public one. - Use `ip addr show` to check for this scenario instead of `ifconfig` because `ifconfig` will not display the offending alias IP address. Alternatively an API endpoint specific to Digital Ocean allows to query for the anchor IP from the droplet: + Use `ip addr show` to check for this scenario instead of `ifconfig` because `ifconfig` will not display the offending alias IP address. Alternatively an API endpoint specific to DigitalOcean allows to query for the anchor IP from the droplet: ```sh curl http://169.254.169.254/metadata/v1/interfaces/public/0/anchor_ipv4/address ``` - The workaround is to tell `kubelet` which IP to use using `--node-ip`. When using Digital Ocean, it can be the public one (assigned to `eth0`) or the private one (assigned to `eth1`) should you want to use the optional private network. The [`KubeletExtraArgs` section of the kubeadm `NodeRegistrationOptions` structure](https://github.com/kubernetes/kubernetes/blob/release-1.13/cmd/kubeadm/app/apis/kubeadm/v1beta1/types.go) can be used for this. + The workaround is to tell `kubelet` which IP to use using `--node-ip`. When using DigitalOcean, it can be the public one (assigned to `eth0`) or the private one (assigned to `eth1`) should you want to use the optional private network. The [`KubeletExtraArgs` section of the kubeadm `NodeRegistrationOptions` structure](https://github.com/kubernetes/kubernetes/blob/release-1.13/cmd/kubeadm/app/apis/kubeadm/v1beta1/types.go) can be used for this. Then restart `kubelet`: @@ -306,16 +307,56 @@ The tracking issue for this problem is [here](https://github.com/kubernetes/kube *Note: This [issue](https://github.com/kubernetes/kubeadm/issues/1358) only applies to tools that marshal kubeadm types (e.g. to a YAML configuration file). It will be fixed in kubeadm API v1beta2.* -By default, kubeadm applies the `role.kubernetes.io/master:NoSchedule` taint to control-plane nodes. +By default, kubeadm applies the `node-role.kubernetes.io/master:NoSchedule` taint to control-plane nodes. If you prefer kubeadm to not taint the control-plane node, and set `InitConfiguration.NodeRegistration.Taints` to an empty slice, the field will be omitted when marshalling. When the field is omitted, kubeadm applies the default taint. There are at least two workarounds: -1. Use the `role.kubernetes.io/master:PreferNoSchedule` taint instead of an empty slice. [Pods will get scheduled on masters](https://kubernetes.io/docs/concepts/configuration/taint-and-toleration/), unless other nodes have capacity. +1. Use the `node-role.kubernetes.io/master:PreferNoSchedule` taint instead of an empty slice. [Pods will get scheduled on masters](/docs/concepts/configuration/taint-and-toleration/), unless other nodes have capacity. 2. Remove the taint after kubeadm init exits: ```bash -kubectl taint nodes NODE_NAME role.kubernetes.io/master:NoSchedule- +kubectl taint nodes NODE_NAME node-role.kubernetes.io/master:NoSchedule- + ``` + +## `/usr` is mounted read-only on nodes {#usr-mounted-read-only} + +On Linux distributions such as Fedora CoreOS, the directory `/usr` is mounted as a read-only filesystem. +For [flex-volume support](https://github.com/kubernetes/community/blob/ab55d85/contributors/devel/sig-storage/flexvolume.md), +Kubernetes components like the kubelet and kube-controller-manager use the default path of +`/usr/libexec/kubernetes/kubelet-plugins/volume/exec/`, yet the flex-volume directory _must be writeable_ +for the feature to work. + +To workaround this issue you can configure the flex-volume directory using the kubeadm +[configuration file](https://godoc.org/k8s.io/kubernetes/cmd/kubeadm/app/apis/kubeadm/v1beta2). + +On the primary control-plane Node (created using `kubeadm init`) pass the following +file using `--config`: + +```yaml +apiVersion: kubeadm.k8s.io/v1beta2 +kind: InitConfiguration +nodeRegistration: + kubeletExtraArgs: + volume-plugin-dir: "/opt/libexec/kubernetes/kubelet-plugins/volume/exec/" +--- +apiVersion: kubeadm.k8s.io/v1beta2 +kind: ClusterConfiguration +controllerManager: + extraArgs: + flex-volume-plugin-dir: "/opt/libexec/kubernetes/kubelet-plugins/volume/exec/" ``` +On joining Nodes: + +```yaml +apiVersion: kubeadm.k8s.io/v1beta2 +kind: JoinConfiguration +nodeRegistration: + kubeletExtraArgs: + volume-plugin-dir: "/opt/libexec/kubernetes/kubelet-plugins/volume/exec/" +``` + +Alternatively, you can modify `/etc/fstab` to make the `/usr` mount writeable, but please +be advised that this is modifying a design principle of the Linux distribution. diff --git a/content/ja/docs/setup/production-environment/tools/kubespray.md b/content/ja/docs/setup/production-environment/tools/kubespray.md index 921ab0e3d8..6c02ca5374 100644 --- a/content/ja/docs/setup/production-environment/tools/kubespray.md +++ b/content/ja/docs/setup/production-environment/tools/kubespray.md @@ -6,22 +6,22 @@ weight: 30 <!-- overview --> -This quickstart helps to install a Kubernetes cluster hosted on GCE, Azure, OpenStack, AWS, vSphere, Oracle Cloud Infrastructure (Experimental) or Baremetal with [Kubespray](https://github.com/kubernetes-incubator/kubespray). +This quickstart helps to install a Kubernetes cluster hosted on GCE, Azure, OpenStack, AWS, vSphere, Packet (bare metal), Oracle Cloud Infrastructure (Experimental) or Baremetal with [Kubespray](https://github.com/kubernetes-sigs/kubespray). -Kubespray is a composition of [Ansible](http://docs.ansible.com/) playbooks, [inventory](https://github.com/kubernetes-incubator/kubespray/blob/master/docs/ansible.md), provisioning tools, and domain knowledge for generic OS/Kubernetes clusters configuration management tasks. Kubespray provides: +Kubespray is a composition of [Ansible](http://docs.ansible.com/) playbooks, [inventory](https://github.com/kubernetes-sigs/kubespray/blob/master/docs/ansible.md), provisioning tools, and domain knowledge for generic OS/Kubernetes clusters configuration management tasks. Kubespray provides: * a highly available cluster * composable attributes * support for most popular Linux distributions * Container Linux by CoreOS - * Debian Jessie, Stretch, Wheezy + * Debian Buster, Jessie, Stretch, Wheezy * Ubuntu 16.04, 18.04 - * CentOS/RHEL 7 - * Fedora/CentOS Atomic - * openSUSE Leap 42.3/Tumbleweed + * CentOS/RHEL/Oracle Linux 7 + * Fedora 28 + * openSUSE Leap 15 * continuous integration tests -To choose a tool which best fits your use case, read [this comparison](https://github.com/kubernetes-incubator/kubespray/blob/master/docs/comparisons.md) to [kubeadm](/docs/admin/kubeadm/) and [kops](../kops). +To choose a tool which best fits your use case, read [this comparison](https://github.com/kubernetes-sigs/kubespray/blob/master/docs/comparisons.md) to [kubeadm](/docs/admin/kubeadm/) and [kops](/docs/setup/production-environment/tools/kops/). @@ -31,11 +31,11 @@ To choose a tool which best fits your use case, read [this comparison](https://g ### (1/5) 下地の要件の確認 -Provision servers with the following [requirements](https://github.com/kubernetes-incubator/kubespray#requirements): +Provision servers with the following [requirements](https://github.com/kubernetes-sigs/kubespray#requirements): -* **Ansible v2.5 (or newer) and python-netaddr is installed on the machine that will run Ansible commands** +* **Ansible v2.7.8 and python-netaddr is installed on the machine that will run Ansible commands** * **Jinja 2.9 (or newer) is required to run the Ansible Playbooks** -* The target servers must have **access to the Internet** in order to pull docker images +* The target servers must have access to the Internet in order to pull docker images. Otherwise, additional configuration is required ([See Offline Environment](https://github.com/kubernetes-sigs/kubespray/blob/master/docs/offline-environment.md)) * The target servers are configured to allow **IPv4 forwarding** * **Your ssh key must be copied** to all the servers part of your inventory * The **firewalls are not managed**, you'll need to implement your own rules the way you used to. in order to avoid any issue during deployment you should disable your firewall @@ -44,12 +44,13 @@ Provision servers with the following [requirements](https://github.com/kubernete Kubespray provides the following utilities to help provision your environment: * [Terraform](https://www.terraform.io/) scripts for the following cloud providers: - * [AWS](https://github.com/kubernetes-incubator/kubespray/tree/master/contrib/terraform/aws) - * [OpenStack](https://github.com/kubernetes-incubator/kubespray/tree/master/contrib/terraform/openstack) + * [AWS](https://github.com/kubernetes-sigs/kubespray/tree/master/contrib/terraform/aws) + * [OpenStack](https://github.com/kubernetes-sigs/kubespray/tree/master/contrib/terraform/openstack) + * [Packet](https://github.com/kubernetes-sigs/kubespray/tree/master/contrib/terraform/packet) ### (2/5) インベントリファイルの用意 -After you provision your servers, create an [inventory file for Ansible](http://docs.ansible.com/ansible/intro_inventory.html). You can do this manually or via a dynamic inventory script. For more information, see "[Building your own inventory](https://github.com/kubernetes-incubator/kubespray/blob/master/docs/getting-started.md#building-your-own-inventory)". +After you provision your servers, create an [inventory file for Ansible](http://docs.ansible.com/ansible/intro_inventory.html). You can do this manually or via a dynamic inventory script. For more information, see "[Building your own inventory](https://github.com/kubernetes-sigs/kubespray/blob/master/docs/getting-started.md#building-your-own-inventory)". ### (3/5) クラスタ作成の計画 @@ -58,14 +59,14 @@ Kubespray provides the ability to customize many aspects of the deployment: * Choice deployment mode: kubeadm or non-kubeadm * CNI (networking) plugins * DNS configuration -* Choice of control plane: native/binary or containerized with docker or rkt +* Choice of control plane: native/binary or containerized * Component versions * Calico route reflectors * Component runtime options - * docker - * rkt - * cri-o -* Certificate generation methods (**Vault being discontinued**) + * {{< glossary_tooltip term_id="docker" >}} + * {{< glossary_tooltip term_id="containerd" >}} + * {{< glossary_tooltip term_id="cri-o" >}} +* Certificate generation methods Kubespray customizations can be made to a [variable file](http://docs.ansible.com/ansible/playbooks_variables.html). If you are just getting started with Kubespray, consider using the Kubespray defaults to deploy your cluster and explore Kubernetes. @@ -73,18 +74,18 @@ Kubespray customizations can be made to a [variable file](http://docs.ansible.co Next, deploy your cluster: -Cluster deployment using [ansible-playbook](https://github.com/kubernetes-incubator/kubespray/blob/master/docs/getting-started.md#starting-custom-deployment). +Cluster deployment using [ansible-playbook](https://github.com/kubernetes-sigs/kubespray/blob/master/docs/getting-started.md#starting-custom-deployment). ```shell ansible-playbook -i your/inventory/inventory.ini cluster.yml -b -v \ --private-key=~/.ssh/private_key ``` -Large deployments (100+ nodes) may require [specific adjustments](https://github.com/kubernetes-incubator/kubespray/blob/master/docs/large-deployments.md) for best results. +Large deployments (100+ nodes) may require [specific adjustments](https://github.com/kubernetes-sigs/kubespray/blob/master/docs/large-deployments.md) for best results. ### (5/5) デプロイの確認 -Kubespray provides a way to verify inter-pod connectivity and DNS resolve with [Netchecker](https://github.com/kubernetes-incubator/kubespray/blob/master/docs/netcheck.md). Netchecker ensures the netchecker-agents pods can resolve DNS requests and ping each over within the default namespace. Those pods mimic similar behavior of the rest of the workloads and serve as cluster health indicators. +Kubespray provides a way to verify inter-pod connectivity and DNS resolve with [Netchecker](https://github.com/kubernetes-sigs/kubespray/blob/master/docs/netcheck.md). Netchecker ensures the netchecker-agents pods can resolve DNS requests and ping each over within the default namespace. Those pods mimic similar behavior of the rest of the workloads and serve as cluster health indicators. ## クラスタの操作 @@ -92,16 +93,16 @@ Kubespray provides additional playbooks to manage your cluster: _scale_ and _upg ### クラスタのスケール -You can add worker nodes from your cluster by running the scale playbook. For more information, see "[Adding nodes](https://github.com/kubernetes-incubator/kubespray/blob/master/docs/getting-started.md#adding-nodes)". -You can remove worker nodes from your cluster by running the remove-node playbook. For more information, see "[Remove nodes](https://github.com/kubernetes-incubator/kubespray/blob/master/docs/getting-started.md#remove-nodes)". +You can add worker nodes from your cluster by running the scale playbook. For more information, see "[Adding nodes](https://github.com/kubernetes-sigs/kubespray/blob/master/docs/getting-started.md#adding-nodes)". +You can remove worker nodes from your cluster by running the remove-node playbook. For more information, see "[Remove nodes](https://github.com/kubernetes-sigs/kubespray/blob/master/docs/getting-started.md#remove-nodes)". ### クラスタのアップグレード -You can upgrade your cluster by running the upgrade-cluster playbook. For more information, see "[Upgrades](https://github.com/kubernetes-incubator/kubespray/blob/master/docs/upgrades.md)". +You can upgrade your cluster by running the upgrade-cluster playbook. For more information, see "[Upgrades](https://github.com/kubernetes-sigs/kubespray/blob/master/docs/upgrades.md)". ## クリーンアップ -You can reset your nodes and wipe out all components installed with Kubespray via the [reset playbook](https://github.com/kubernetes-incubator/kubespray/blob/master/reset.yml). +You can reset your nodes and wipe out all components installed with Kubespray via the [reset playbook](https://github.com/kubernetes-sigs/kubespray/blob/master/reset.yml). {{< caution >}} When running the reset playbook, be sure not to accidentally target your production cluster! @@ -109,14 +110,13 @@ When running the reset playbook, be sure not to accidentally target your product ## フィードバック -* Slack Channel: [#kubespray](https://kubernetes.slack.com/messages/kubespray/) -* [GitHub Issues](https://github.com/kubernetes-incubator/kubespray/issues) +* Slack Channel: [#kubespray](https://kubernetes.slack.com/messages/kubespray/) (You can get your invite [here](http://slack.k8s.io/)) +* [GitHub Issues](https://github.com/kubernetes-sigs/kubespray/issues) ## {{% heading "whatsnext" %}} -Check out planned work on Kubespray's [roadmap](https://github.com/kubernetes-incubator/kubespray/blob/master/docs/roadmap.md). - +Check out planned work on Kubespray's [roadmap](https://github.com/kubernetes-sigs/kubespray/blob/master/docs/roadmap.md). diff --git a/content/ja/docs/setup/production-environment/turnkey/_index.md b/content/ja/docs/setup/production-environment/turnkey/_index.md index c39cd2a714..6b9dabb7ab 100644 --- a/content/ja/docs/setup/production-environment/turnkey/_index.md +++ b/content/ja/docs/setup/production-environment/turnkey/_index.md @@ -1,4 +1,4 @@ --- title: ターンキークラウドソリューション -weight: 40 +weight: 30 --- diff --git a/content/ja/docs/setup/production-environment/turnkey/alibaba-cloud.md b/content/ja/docs/setup/production-environment/turnkey/alibaba-cloud.md index f8323743cf..4506e9cba0 100644 --- a/content/ja/docs/setup/production-environment/turnkey/alibaba-cloud.md +++ b/content/ja/docs/setup/production-environment/turnkey/alibaba-cloud.md @@ -4,9 +4,9 @@ title: Alibaba CloudでKubernetesを動かす ## Alibaba Cloud Container Service -[Alibaba Cloud Container Service](https://www.alibabacloud.com/product/container-service)はAlibaba Cloud ECSインスタンスのクラスター上でDockerアプリケーションを起動して管理します。著名なオープンソースのコンテナオーケストレーターであるDocker SwarmおよびKubernetesをサポートしています。 +[Alibaba Cloud Container Service](https://www.alibabacloud.com/product/container-service)はAlibaba Cloud ECSインスタンスのクラスター上もしくはサーバーレスの形態でDockerアプリケーションを起動して管理します。著名なオープンソースのコンテナオーケストレーターであるDocker SwarmおよびKubernetesをサポートしています。 -クラスターの構築と管理を簡素化する為に、[Alibaba Cloud Container Serviceの為のKubernetesサポート](https://www.alibabacloud.com/product/kubernetes)を使用します。[Kubernetes walk-through](https://www.alibabacloud.com/help/doc-detail/86737.htm)に従ってすぐに始めることができ、中国語の[Alibaba CloudにおけるKubernetesサポートの為のチュートリアル](https://yq.aliyun.com/teams/11/type_blog-cid_200-page_1)もあります。 +クラスターの構築と管理を簡素化するために、[Alibaba Cloud Container ServiceのためのKubernetesサポート](https://www.alibabacloud.com/product/kubernetes)を使用します。[Kubernetes walk-through](https://www.alibabacloud.com/help/doc-detail/86737.htm)に従ってすぐに始めることができ、中国語の[Alibaba CloudにおけるKubernetesサポートのためのチュートリアル](https://yq.aliyun.com/teams/11/type_blog-cid_200-page_1)もあります。 カスタムバイナリもしくはオープンソースKubernetesを使用する場合は、以下の手順に従って下さい。 @@ -14,4 +14,4 @@ title: Alibaba CloudでKubernetesを動かす [Alibaba Cloudプロバイダーが実装されたKubernetesのソースコード](https://github.com/AliyunContainerService/kubernetes)はオープンソースであり、GitHubから入手可能です。 -さらなる情報は英語の[Kubernetesのクイックデプロイメント - Alibaba CloudのVPC環境](https://www.alibabacloud.com/forum/read-830)および[中国語](https://yq.aliyun.com/articles/66474)をご覧下さい。 +さらなる情報は英語の[Kubernetesのクイックデプロイメント - Alibaba CloudのVPC環境](https://www.alibabacloud.com/forum/read-830)をご覧下さい。 diff --git a/content/ja/docs/setup/production-environment/turnkey/aws.md b/content/ja/docs/setup/production-environment/turnkey/aws.md index ebbb93160d..1fc53a1f28 100644 --- a/content/ja/docs/setup/production-environment/turnkey/aws.md +++ b/content/ja/docs/setup/production-environment/turnkey/aws.md @@ -16,7 +16,7 @@ AWS上でKubernetesクラスターを作成するには、AWSからアクセス ### サポートされているプロダクショングレードのツール -* [conjure-up](/docs/getting-started-guides/ubuntu/)はUbuntu上でネイティブなAWSインテグレーションを用いてKubernetesクラスターを作成するオープンソースのインストーラーです。 +* [conjure-up](https://docs.conjure-up.io/stable/en/cni/k8s-and-aws)はUbuntu上でネイティブなAWSインテグレーションを用いてKubernetesクラスターを作成するオープンソースのインストーラーです。 * [Kubernetes Operations](https://github.com/kubernetes/kops) - プロダクショングレードなKubernetesのインストール、アップグレード、管理が可能です。AWS上のDebian、Ubuntu、CentOS、RHELをサポートしています。 diff --git a/content/ja/docs/setup/production-environment/turnkey/icp.md b/content/ja/docs/setup/production-environment/turnkey/icp.md index 79783a6364..9d1a0a17b3 100644 --- a/content/ja/docs/setup/production-environment/turnkey/icp.md +++ b/content/ja/docs/setup/production-environment/turnkey/icp.md @@ -35,9 +35,9 @@ IBM Cloud Private can also run on the AWS cloud platform by using Terraform. To ## Azure上でのIBM Cloud Private -You can enable Microsoft Azure as a cloud provider for IBM Cloud Private deployment and take advantage of all the IBM Cloud Private features on the Azure public cloud. For more information, see [IBM Cloud Private on Azure](https://www.ibm.com/support/knowledgecenter/SSBS6K_3.1.2/supported_environments/azure_overview.html). +You can enable Microsoft Azure as a cloud provider for IBM Cloud Private deployment and take advantage of all the IBM Cloud Private features on the Azure public cloud. For more information, see [IBM Cloud Private on Azure](https://www.ibm.com/support/knowledgecenter/SSBS6K_3.2.0/supported_environments/azure_overview.html). -## Red Hat OpenShift上でのIBM Cloud Private +## Red Hat OpenShiftを用いたIBM Cloud Private You can deploy IBM certified software containers that are running on IBM Cloud Private onto Red Hat OpenShift. @@ -49,7 +49,7 @@ Integration capabilities: * Integrated core platform services, such as monitoring, metering, and logging * IBM Cloud Private uses the OpenShift image registry -For more information see, [IBM Cloud Private on OpenShift](https://www.ibm.com/support/knowledgecenter/SSBS6K_3.1.2/supported_environments/openshift/overview.html). +For more information see, [IBM Cloud Private on OpenShift](https://www.ibm.com/support/knowledgecenter/SSBS6K_3.2.0/supported_environments/openshift/overview.html). ## VirtualBox上でのIBM Cloud Private diff --git a/content/ja/docs/setup/production-environment/turnkey/stackpoint.md b/content/ja/docs/setup/production-environment/turnkey/stackpoint.md deleted file mode 100644 index 47711bf4d8..0000000000 --- a/content/ja/docs/setup/production-environment/turnkey/stackpoint.md +++ /dev/null @@ -1,187 +0,0 @@ ---- -title: Stackpoint.ioを利用して複数のクラウド上でKubernetesを動かす -content_type: concept ---- - -<!-- overview --> - -[StackPointCloud](https://stackpoint.io/) is the universal control plane for Kubernetes Anywhere. StackPointCloud allows you to deploy and manage a Kubernetes cluster to the cloud provider of your choice in 3 steps using a web-based interface. - - - -<!-- body --> - -## AWS - -To create a Kubernetes cluster on AWS, you will need an Access Key ID and a Secret Access Key from AWS. - -1. Choose a Provider - - a. Log in to [stackpoint.io](https://stackpoint.io) with a GitHub, Google, or Twitter account. - - b. Click **+ADD A CLUSTER NOW**. - - c. Click to select Amazon Web Services (AWS). - -1. Configure Your Provider - - a. Add your Access Key ID and a Secret Access Key from AWS. Select your default StackPointCloud SSH keypair, or click **ADD SSH KEY** to add a new keypair. - - b. Click **SUBMIT** to submit the authorization information. - -1. Configure Your Cluster - - Choose any extra options you may want to include with your cluster, then click **SUBMIT** to create the cluster. - -1. Run the Cluster - - You can monitor the status of your cluster and suspend or delete it from [your stackpoint.io dashboard](https://stackpoint.io/#/clusters). - - For information on using and managing a Kubernetes cluster on AWS, [consult the Kubernetes documentation](/docs/getting-started-guides/aws/). - - -## GCE - -To create a Kubernetes cluster on GCE, you will need the Service Account JSON Data from Google. - -1. Choose a Provider - - a. Log in to [stackpoint.io](https://stackpoint.io) with a GitHub, Google, or Twitter account. - - b. Click **+ADD A CLUSTER NOW**. - - c. Click to select Google Compute Engine (GCE). - -1. Configure Your Provider - - a. Add your Service Account JSON Data from Google. Select your default StackPointCloud SSH keypair, or click **ADD SSH KEY** to add a new keypair. - - b. Click **SUBMIT** to submit the authorization information. - -1. Configure Your Cluster - - Choose any extra options you may want to include with your cluster, then click **SUBMIT** to create the cluster. - -1. Run the Cluster - - You can monitor the status of your cluster and suspend or delete it from [your stackpoint.io dashboard](https://stackpoint.io/#/clusters). - - For information on using and managing a Kubernetes cluster on GCE, [consult the Kubernetes documentation](/docs/getting-started-guides/gce/). - - -## Google Kubernetes Engine - -To create a Kubernetes cluster on Google Kubernetes Engine, you will need the Service Account JSON Data from Google. - -1. Choose a Provider - - a. Log in to [stackpoint.io](https://stackpoint.io) with a GitHub, Google, or Twitter account. - - b. Click **+ADD A CLUSTER NOW**. - - c. Click to select Google Kubernetes Engine. - -1. Configure Your Provider - - a. Add your Service Account JSON Data from Google. Select your default StackPointCloud SSH keypair, or click **ADD SSH KEY** to add a new keypair. - - b. Click **SUBMIT** to submit the authorization information. - -1. Configure Your Cluster - - Choose any extra options you may want to include with your cluster, then click **SUBMIT** to create the cluster. - -1. Run the Cluster - - You can monitor the status of your cluster and suspend or delete it from [your stackpoint.io dashboard](https://stackpoint.io/#/clusters). - - For information on using and managing a Kubernetes cluster on Google Kubernetes Engine, consult [the official documentation](/ja/docs/home/). - - -## DigitalOcean - -To create a Kubernetes cluster on DigitalOcean, you will need a DigitalOcean API Token. - -1. Choose a Provider - - a. Log in to [stackpoint.io](https://stackpoint.io) with a GitHub, Google, or Twitter account. - - b. Click **+ADD A CLUSTER NOW**. - - c. Click to select DigitalOcean. - -1. Configure Your Provider - - a. Add your DigitalOcean API Token. Select your default StackPointCloud SSH keypair, or click **ADD SSH KEY** to add a new keypair. - - b. Click **SUBMIT** to submit the authorization information. - -1. Configure Your Cluster - - Choose any extra options you may want to include with your cluster, then click **SUBMIT** to create the cluster. - -1. Run the Cluster - - You can monitor the status of your cluster and suspend or delete it from [your stackpoint.io dashboard](https://stackpoint.io/#/clusters). - - For information on using and managing a Kubernetes cluster on DigitalOcean, consult [the official documentation](/ja/docs/home/). - - -## Microsoft Azure - -To create a Kubernetes cluster on Microsoft Azure, you will need an Azure Subscription ID, Username/Email, and Password. - -1. Choose a Provider - - a. Log in to [stackpoint.io](https://stackpoint.io) with a GitHub, Google, or Twitter account. - - b. Click **+ADD A CLUSTER NOW**. - - c. Click to select Microsoft Azure. - -1. Configure Your Provider - - a. Add your Azure Subscription ID, Username/Email, and Password. Select your default StackPointCloud SSH keypair, or click **ADD SSH KEY** to add a new keypair. - - b. Click **SUBMIT** to submit the authorization information. - -1. Configure Your Cluster - - Choose any extra options you may want to include with your cluster, then click **SUBMIT** to create the cluster. - -1. Run the Cluster - - You can monitor the status of your cluster and suspend or delete it from [your stackpoint.io dashboard](https://stackpoint.io/#/clusters). - - For information on using and managing a Kubernetes cluster on Azure, [consult the Kubernetes documentation](/docs/getting-started-guides/azure/). - - -## Packet - -To create a Kubernetes cluster on Packet, you will need a Packet API Key. - -1. Choose a Provider - - a. Log in to [stackpoint.io](https://stackpoint.io) with a GitHub, Google, or Twitter account. - - b. Click **+ADD A CLUSTER NOW**. - - c. Click to select Packet. - -1. Configure Your Provider - - a. Add your Packet API Key. Select your default StackPointCloud SSH keypair, or click **ADD SSH KEY** to add a new keypair. - - b. Click **SUBMIT** to submit the authorization information. - -1. Configure Your Cluster - - Choose any extra options you may want to include with your cluster, then click **SUBMIT** to create the cluster. - -1. Run the Cluster - - You can monitor the status of your cluster and suspend or delete it from [your stackpoint.io dashboard](https://stackpoint.io/#/clusters). - - For information on using and managing a Kubernetes cluster on Packet, consult [the official documentation](/ja/docs/home/). - - diff --git a/content/ja/docs/setup/production-environment/windows/flannel-master-kubeclt-get-pods.png b/content/ja/docs/setup/production-environment/windows/flannel-master-kubeclt-get-pods.png deleted file mode 100644 index 73da333fcf..0000000000 Binary files a/content/ja/docs/setup/production-environment/windows/flannel-master-kubeclt-get-pods.png and /dev/null differ diff --git a/content/ja/docs/setup/production-environment/windows/flannel-master-kubectl-get-ds.png b/content/ja/docs/setup/production-environment/windows/flannel-master-kubectl-get-ds.png deleted file mode 100644 index cda9353316..0000000000 Binary files a/content/ja/docs/setup/production-environment/windows/flannel-master-kubectl-get-ds.png and /dev/null differ diff --git a/content/ja/docs/setup/production-environment/windows/intro-windows-in-kubernetes.md b/content/ja/docs/setup/production-environment/windows/intro-windows-in-kubernetes.md index ab0181fd49..c821fca425 100644 --- a/content/ja/docs/setup/production-environment/windows/intro-windows-in-kubernetes.md +++ b/content/ja/docs/setup/production-environment/windows/intro-windows-in-kubernetes.md @@ -1,73 +1,72 @@ --- -title: Intro to Windows support in Kubernetes +title: KubernetesのWindowsサポート概要 content_type: concept weight: 65 --- <!-- overview --> -Windows applications constitute a large portion of the services and applications that run in many organizations. [Windows containers](https://aka.ms/windowscontainers) provide a modern way to encapsulate processes and package dependencies, making it easier to use DevOps practices and follow cloud native patterns for Windows applications. Kubernetes has become the defacto standard container orchestrator, and the release of Kubernetes 1.14 includes production support for scheduling Windows containers on Windows nodes in a Kubernetes cluster, enabling a vast ecosystem of Windows applications to leverage the power of Kubernetes. Organizations with investments in Windows-based applications and Linux-based applications don't have to look for separate orchestrators to manage their workloads, leading to increased operational efficiencies across their deployments, regardless of operating system. +Windowsアプリケーションは、多くの組織で実行されているサービスやアプリケーションの大部分を占めています。[Windowsコンテナ](https://aka.ms/windowscontainers)は、プロセスとパッケージの依存関係を一つにまとめる最新の方法を提供し、DevOpsプラクティスの使用とWindowsアプリケーションのクラウドネイティブパターンの追求を容易にします。Kubernetesは事実上、標準的なコンテナオーケストレータになりました。Kubernetes 1.14のリリースでは、Kubernetesクラスター内のWindowsノードでWindowsコンテナをスケジューリングする本番環境サポートが含まれたので、Windowsアプリケーションの広大なエコシステムにおいて、Kubernetesを有効的に活用できます。WindowsベースのアプリケーションとLinuxベースのアプリケーションに投資している組織は、ワークロードを管理する個別のオーケストレーターが不要となるため、オペレーティングシステムに関係なくアプリケーション全体の運用効率が向上します。 <!-- body --> -## Windows containers in Kubernetes +## KubernetesのWindowsコンテナ -To enable the orchestration of Windows containers in Kubernetes, simply include Windows nodes in your existing Linux cluster. Scheduling Windows containers in [Pods](/ja/docs/concepts/workloads/pods/pod-overview/) on Kubernetes is as simple and easy as scheduling Linux-based containers. +KubernetesでWindowsコンテナのオーケストレーションを有効にする方法は、既存のLinuxクラスターにWindowsノードを含めるだけです。Kubernetesの[Pod](/ja/docs/concepts/workloads/pods/pod-overview/)でWindowsコンテナをスケジュールすることは、Linuxベースのコンテナをスケジュールするのと同じくらいシンプルで簡単です。 -In order to run Windows containers, your Kubernetes cluster must include multiple operating systems, with control plane nodes running Linux and workers running either Windows or Linux depending on your workload needs. Windows Server 2019 is the only Windows operating system supported, enabling [Kubernetes Node](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/architecture/architecture.md#the-kubernetes-node) on Windows (including kubelet, [container runtime](https://docs.microsoft.com/en-us/virtualization/windowscontainers/deploy-containers/containerd), and kube-proxy). For a detailed explanation of Windows distribution channels see the [Microsoft documentation](https://docs.microsoft.com/en-us/windows-server/get-started-19/servicing-channels-19). +Windowsコンテナを実行するには、Kubernetesクラスターに複数のオペレーティングシステムを含める必要があります。コントロールプレーンノードはLinux、ワーカーノードはワークロードのニーズに応じてWindowsまたはLinuxで実行します。Windows Server 2019は、サポートされている唯一のWindowsオペレーティングシステムであり、Windows (kubelet、[コンテナランタイム](https://docs.microsoft.com/en-us/virtualization/windowscontainers/deploy-containers/containerd)、kube-proxyを含む)で[Kubernetesノード](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/architecture/architecture.md#the-kubernetes-node)を有効にします。Windowsディストリビューションチャンネルの詳細については、[Microsoftのドキュメント](https://docs.microsoft.com/en-us/windows-server/get-started-19/servicing-channels-19)を参照してください。 {{< note >}} -The Kubernetes control plane, including the [master components](/ja/docs/concepts/overview/components/), continues to run on Linux. There are no plans to have a Windows-only Kubernetes cluster. +[マスターコンポーネント](/ja/docs/concepts/overview/components/)を含むKubernetesコントロールプレーンは、Linuxで実行し続けます。WindowsのみのKubernetesクラスターを導入する計画はありません。 {{< /note >}} - {{< note >}} -In this document, when we talk about Windows containers we mean Windows containers with process isolation. Windows containers with [Hyper-V isolation](https://docs.microsoft.com/en-us/virtualization/windowscontainers/manage-containers/hyperv-container) is planned for a future release. +このドキュメントでは、Windowsコンテナについて説明する場合、プロセス分離のWindowsコンテナを意味します。[Hyper-V分離](https://docs.microsoft.com/en-us/virtualization/windowscontainers/manage-containers/hyperv-container)のWindowsコンテナは、将来リリースが計画されています。 {{< /note >}} -## Supported Functionality and Limitations +## サポートされている機能と制限 -### Supported Functionality +### サポートされている機能 -#### Compute +#### コンピュート -From an API and kubectl perspective, Windows containers behave in much the same way as Linux-based containers. However, there are some notable differences in key functionality which are outlined in the limitation section. +APIとkubectlの観点から見ると、WindowsコンテナはLinuxベースのコンテナとほとんど同じように動作します。ただし、制限セクションで概説されている主要な機能には、いくつかの顕著な違いがあります。 -Let's start with the operating system version. Refer to the following table for Windows operating system support in Kubernetes. A single heterogeneous Kubernetes cluster can have both Windows and Linux worker nodes. Windows containers have to be scheduled on Windows nodes and Linux containers on Linux nodes. +オペレーティングシステムのバージョンから始めましょう。KubernetesのWindowsオペレーティングシステムのサポートについては、次の表を参照してください。単一の混成Kubernetesクラスターは、WindowsとLinuxの両方のワーカーノードを持つことができます。WindowsコンテナはWindowsノードで、LinuxコンテナはLinuxノードでスケジュールする必要があります。 -| Kubernetes version | Host OS version (Kubernetes Node) | | | +| Kubernetes バージョン | ホストOS バージョン (Kubernetes ノード) | | | | --- | --- | --- | --- | | | *Windows Server 1709* | *Windows Server 1803* | *Windows Server 1809/Windows Server 2019* | -| *Kubernetes v1.14* | Not Supported | Not Supported| Supported for Windows Server containers Builds 17763.* with Docker EE-basic 18.09 | +| *Kubernetes v1.14* | サポートされていません | サポートされていません| Windows Server containers Builds 17763.* と Docker EE-basic 18.09 がサポートされています | {{< note >}} -We don't expect all Windows customers to update the operating system for their apps frequently. Upgrading your applications is what dictates and necessitates upgrading or introducing new nodes to the cluster. For the customers that chose to upgrade their operating system for containers running on Kubernetes, we will offer guidance and step-by-step instructions when we add support for a new operating system version. This guidance will include recommended upgrade procedures for upgrading user applications together with cluster nodes. Windows nodes adhere to Kubernetes [version-skew policy](/ja/docs/setup/release/version-skew-policy/) (node to control plane versioning) the same way as Linux nodes do today. +すべてのWindowsユーザーがアプリのオペレーティングシステムを頻繁に更新することは望んでいません。アプリケーションのアップグレードは、クラスターに新しいノードをアップグレードまたは導入することを要求する必要があります。Kubernetesで実行されているコンテナのオペレーティングシステムをアップグレードすることを選択したユーザーには、新しいオペレーティングシステムバージョンのサポート追加時に、ガイダンスと段階的な指示を提供します。このガイダンスには、クラスターノードと共にアプリケーションをアップグレードするための推奨アップグレード手順が含まれます。Windowsノードは、現在のLinuxノードと同じように、Kubernetes[バージョンスキューポリシー](/ja/docs/setup/release/version-skew-policy/)(ノードからコントロールプレーンのバージョン管理)に準拠しています。 {{< /note >}} {{< note >}} -The Windows Server Host Operating System is subject to the [Windows Server ](https://www.microsoft.com/en-us/cloud-platform/windows-server-pricing) licensing. The Windows Container images are subject to the [Supplemental License Terms for Windows containers](https://docs.microsoft.com/en-us/virtualization/windowscontainers/images-eula). +Windows Serverホストオペレーティングシステムには、[Windows Server](https://www.microsoft.com/en-us/cloud-platform/windows-server-pricing)ライセンスが適用されます。Windowsコンテナイメージには、[Windowsコンテナの追加ライセンス条項](https://docs.microsoft.com/en-us/virtualization/windowscontainers/images-eula)ライセンスが提供されます。 {{< /note >}} {{< note >}} -Windows containers with process isolation have strict compatibility rules, [where the host OS version must match the container base image OS version](https://docs.microsoft.com/en-us/virtualization/windowscontainers/deploy-containers/version-compatibility). Once we support Windows containers with Hyper-V isolation in Kubernetes, the limitation and compatibility rules will change. +プロセス分離のWindowsコンテナには、[ホストOSのバージョンはコンテナのベースイメージのOSバージョンと一致する必要がある](https://docs.microsoft.com/en-us/virtualization/windowscontainers/deploy-containers/version-compatibility)という厳格な互換性ルールがあります。KubernetesでHyper-V分離のWindowsコンテナをサポートする際には、制限と互換性ルールが変更されます。 {{< /note >}} -Key Kubernetes elements work the same way in Windows as they do in Linux. In this section, we talk about some of the key workload enablers and how they map to Windows. +Kubernetesの主要な要素は、WindowsでもLinuxと同じように機能します。このセクションでは、主要なワークロードイネーブラーのいくつかと、それらがWindowsにどのようにマップされるかについて説明します。 * [Pods](/ja/docs/concepts/workloads/pods/pod-overview/) - A Pod is the basic building block of Kubernetes–the smallest and simplest unit in the Kubernetes object model that you create or deploy. The following Pod capabilities, properties and events are supported with Windows containers: + Podは、Kubernetesにおける最も基本的な構成要素です。人間が作成またはデプロイするKubernetesオブジェクトモデルの中で最小かつ最もシンプルな単位です。WindowsとLinuxのコンテナを同じPodにデプロイすることはできません。Pod内のすべてのコンテナは、各ノードが特定のプラットフォームとアーキテクチャを表す単一のノードにスケジュールされます。次のPod機能、プロパティ、およびイベントがWindowsコンテナでサポートされています。: - * Single or multiple containers per Pod with process isolation and volume sharing - * Pod status fields - * Readiness and Liveness probes - * postStart & preStop container lifecycle events - * ConfigMap, Secrets: as environment variables or volumes + * プロセス分離とボリューム共有を備えたPodごとの単一または複数のコンテナ + * Podステータスフィールド + * ReadinessとLiveness Probe + * postStartとpreStopコンテナのライフサイクルイベント + * 環境変数またはボリュームとしてのConfigMap、 Secrets * EmptyDir - * Named pipe host mounts - * Resource limits + * 名前付きパイプホストマウント + * リソース制限 * [Controllers](/ja/docs/concepts/workloads/controllers/) - Kubernetes controllers handle the desired state of Pods. The following workload controllers are supported with Windows containers: + Kubernetesコントローラは、Podの望ましい状態を処理します。次のワークロードコントローラーは、Windowsコンテナでサポートされています。: * ReplicaSet * ReplicationController @@ -78,322 +77,340 @@ Key Kubernetes elements work the same way in Windows as they do in Linux. In thi * CronJob * [Services](/ja/docs/concepts/services-networking/service/) - A Kubernetes Service is an abstraction which defines a logical set of Pods and a policy by which to access them - sometimes called a micro-service. You can use services for cross-operating system connectivity. In Windows, services can utilize the following types, properties and capabilities: + Kubernetes Serviceは、Podの論理セットとPodにアクセスするためのポリシーを定義する抽象概念です。マイクロサービスと呼ばれることもあります。オペレーティングシステム間の接続にServiceを使用できます。WindowsでのServiceは、次のタイプ、プロパティと機能を利用できます。: - * Service Environment variables + * サービス環境変数 * NodePort * ClusterIP * LoadBalancer * ExternalName * Headless services -Pods, Controllers and Services are critical elements to managing Windows workloads on Kubernetes. However, on their own they are not enough to enable the proper lifecycle management of Windows workloads in a dynamic cloud native environment. We added support for the following features: +Pod、Controller、Serviceは、KubernetesでWindowsワークロードを管理するための重要な要素です。ただし、それだけでは、動的なクラウドネイティブ環境でWindowsワークロードの適切なライフサイクル管理を可能にするのに十分ではありません。次の機能のサポートを追加しました： -* Pod and container metrics -* Horizontal Pod Autoscaler support +* Podとコンテナのメトリクス +* Horizontal Pod Autoscalerサポート * kubectl Exec -* Resource Quotas -* Scheduler preemption +* リソースクォータ +* Schedulerのプリエンプション -#### Container Runtime +#### コンテナランタイム -Docker EE-basic 18.09 is required on Windows Server 2019 / 1809 nodes for Kubernetes. This works with the dockershim code included in the kubelet. Additional runtimes such as CRI-ContainerD may be supported in later Kubernetes versions. +KubernetesのWindows Server 2019/1809ノードでは、Docker EE-basic 18.09が必要です。これは、kubeletに含まれているdockershimコードで動作します。CRI-ContainerDなどの追加のランタイムは、Kubernetesの以降のバージョンでサポートされる可能性があります。 -#### Storage +#### 永続ストレージ -Kubernetes Volumes enable complex applications with data persistence and Pod volume sharing requirements to be deployed on Kubernetes. Kubernetes on Windows supports the following types of [volumes](/ja/docs/concepts/storage/volumes/): +Kubernetes[ボリューム](/docs/concepts/storage/volumes/)を使用すると、データの永続性とPodボリュームの共有要件を備えた複雑なアプリケーションをKubernetesにデプロイできます。特定のストレージバックエンドまたはプロトコルに関連付けられた永続ボリュームの管理には、ボリュームのプロビジョニング/プロビジョニング解除/サイズ変更、Kubernetesノードへのボリュームのアタッチ/デタッチ、およびデータを永続化する必要があるPod内の個別のコンテナへのボリュームのマウント/マウント解除などのアクションが含まれます。特定のストレージバックエンドまたはプロトコルに対してこれらのボリューム管理アクションを実装するコードは、Kubernetesボリューム[プラグイン](/docs/concepts/storage/volumes/#types-of-volumes)の形式で出荷されます。次の幅広いクラスのKubernetesボリュームプラグインがWindowsでサポートされています。: -* FlexVolume out-of-tree plugin with [SMB and iSCSI](https://github.com/Microsoft/K8s-Storage-Plugins/tree/master/flexvolume/windows) support -* [azureDisk](/ja/docs/concepts/storage/volumes/#azuredisk) -* [azureFile](/ja/docs/concepts/storage/volumes/#azurefile) -* [gcePersistentDisk](/ja/docs/concepts/storage/volumes/#gcepersistentdisk) +##### In-treeボリュームプラグイン +In-treeボリュームプラグインに関連付けられたコードは、コアKubernetesコードベースの一部として提供されます。In-treeボリュームプラグインのデプロイでは、追加のスクリプトをインストールしたり、個別のコンテナ化されたプラグインコンポーネントをデプロイしたりする必要はありません。これらのプラグインは、ストレージバックエンドでのボリュームのプロビジョニング/プロビジョニング解除とサイズ変更、Kubernetesノードへのボリュームのアタッチ/アタッチ解除、Pod内の個々のコンテナーへのボリュームのマウント/マウント解除を処理できます。次のIn-treeプラグインは、Windowsノードをサポートしています。: -#### Networking +* [awsElasticBlockStore](/docs/concepts/storage/volumes/#awselasticblockstore) +* [azureDisk](/docs/concepts/storage/volumes/#azuredisk) +* [azureFile](/docs/concepts/storage/volumes/#azurefile) +* [gcePersistentDisk](/docs/concepts/storage/volumes/#gcepersistentdisk) +* [vsphereVolume](/docs/concepts/storage/volumes/#vspherevolume) -Networking for Windows containers is exposed through [CNI plugins](/ja/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/). Windows containers function similarly to virtual machines in regards to networking. Each container has a virtual network adapter (vNIC) which is connected to a Hyper-V virtual switch (vSwitch). The Host Networking Service (HNS) and the Host Compute Service (HCS) work together to create containers and attach container vNICs to networks. HCS is responsible for the management of containers whereas HNS is responsible for the management of networking resources such as: +##### FlexVolume Plugins +[FlexVolume](/docs/concepts/storage/volumes/#flexVolume)プラグインに関連付けられたコードは、ホストに直接デプロイする必要があるout-of-treeのスクリプトまたはバイナリとして出荷されます。FlexVolumeプラグインは、Kubernetesノードとの間のボリュームのアタッチ/デタッチ、およびPod内の個々のコンテナとの間のボリュームのマウント/マウント解除を処理します。FlexVolumeプラグインに関連付けられた永続ボリュームのプロビジョニング/プロビジョニング解除は、通常FlexVolumeプラグインとは別の外部プロビジョニング担当者を通じて処理できます。次のFlexVolume[プラグイン](https://github.com/Microsoft/K8s-Storage-Plugins/tree/master/flexvolume/windows)は、Powershellスクリプトとしてホストにデプロイされ、Windowsノードをサポートします: -* Virtual networks (including creation of vSwitches) -* Endpoints / vNICs -* Namespaces -* Policies (Packet encapsulations, Load-balancing rules, ACLs, NAT'ing rules, etc.) +* [SMB](https://github.com/microsoft/K8s-Storage-Plugins/tree/master/flexvolume/windows/plugins/microsoft.com~smb.cmd) +* [iSCSI](https://github.com/microsoft/K8s-Storage-Plugins/tree/master/flexvolume/windows/plugins/microsoft.com~iscsi.cmd) -The following service spec types are supported: +##### CSIプラグイン + +{{< feature-state for_k8s_version="v1.16" state="alpha" >}} + +{{< glossary_tooltip text="CSI" term_id="csi" >}}プラグインに関連付けられたコードは、通常、コンテナイメージとして配布され、DaemonSetやStatefulSetなどの標準のKubernetesコンポーネントを使用してデプロイされるout-of-treeのスクリプトおよびバイナリとして出荷されます。CSIプラグインは、ボリュームのプロビジョニング/プロビジョニング解除/サイズ変更、Kubernetesノードへのボリュームのアタッチ/ボリュームからのデタッチ、Pod内の個々のコンテナへのボリュームのマウント/マウント解除、バックアップ/スナップショットとクローニングを使用した永続データのバックアップ/リストアといった、Kubernetesの幅広いボリューム管理アクションを処理します。CSIプラグインは通常、ノードプラグイン（各ノードでDaemonSetとして実行される）とコントローラープラグインで構成されます。 + +CSIノードプラグイン（特に、ブロックデバイスまたは共有ファイルシステムとして公開された永続ボリュームに関連付けられているプラ​​グイン）は、ディスクデバイスのスキャン、ファイルシステムのマウントなど、さまざまな特権操作を実行する必要があります。これらの操作は、ホストオペレーティングシステムごとに異なります。Linuxワーカーノードの場合、コンテナ化されたCSIノードプラグインは通常、特権コンテナとしてデプロイされます。Windowsワーカーノードの場合、コンテナ化されたCSIノードプラグインの特権操作は、[csi-proxy](https://github.com/kubernetes-csi/csi-proxy)を使用してサポートされます。各Windowsノードにプリインストールされている。詳細については、展開するCSIプラグインの展開ガイドを参照してください。 + +#### ネットワーキング + +Windowsコンテナのネットワークは、[CNIプラグイン](/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/)を通じて公開されます。Windowsコンテナは、ネットワークに関して仮想マシンと同様に機能します。各コンテナには、Hyper-V仮想スイッチ(vSwitch)に接続されている仮想ネットワークアダプター(vNIC)があります。Host Network Service(HNS)とHost Compute Service(HCS)は連携してコンテナを作成し、コンテナvNICをネットワークに接続します。HCSはコンテナの管理を担当するのに対し、HNSは次のようなネットワークリソースの管理を担当します。: + +* 仮想ネットワーク(vSwitchの作成を含む) +* エンドポイント/vNIC +* 名前空間 +* ポリシー(パケットのカプセル化、負荷分散ルール、ACL、NATルールなど) + +次のServiceタイプがサポートされています。: * NodePort * ClusterIP * LoadBalancer * ExternalName -Windows supports five different networking drivers/modes: L2bridge, L2tunnel, Overlay, Transparent, and NAT. In a heterogeneous cluster with Windows and Linux worker nodes, you need to select a networking solution that is compatible on both Windows and Linux. The following out-of-tree plugins are supported on Windows, with recommendations on when to use each CNI: +Windowsは、L2bridge、L2tunnel、Overlay、Transparent、NATの5つの異なるネットワークドライバー/モードをサポートしています。WindowsとLinuxのワーカーノードを持つ異種クラスターでは、WindowsとLinuxの両方で互換性のあるネットワークソリューションを選択する必要があります。以下のツリー外プラグインがWindowsでサポートされており、各CNIをいつ使用するかに関する推奨事項があります。: -| Network Driver | Description | Container Packet Modifications | Network Plugins | Network Plugin Characteristics | +| ネットワークドライバー | 説明 | コンテナパケットの変更 | ネットワークプラグイン | ネットワークプラグインの特性 | | -------------- | ----------- | ------------------------------ | --------------- | ------------------------------ | -| L2bridge | Containers are attached to an external vSwitch. Containers are attached to the underlay network, although the physical network doesn't need to learn the container MACs because they are rewritten on ingress/egress. Inter-container traffic is bridged inside the container host. | MAC is rewritten to host MAC, IP remains the same. | [win-bridge](https://github.com/containernetworking/plugins/tree/master/plugins/main/windows/win-bridge), [Azure-CNI](https://github.com/Azure/azure-container-networking/blob/master/docs/cni.md), Flannel host-gateway uses win-bridge | win-bridge uses L2bridge network mode, connects containers to the underlay of hosts, offering best performance. Requires L2 adjacency between container hosts | -| L2Tunnel | This is a special case of l2bridge, but only used on Azure. All packets are sent to the virtualization host where SDN policy is applied. | MAC rewritten, IP visible on the underlay network | [Azure-CNI](https://github.com/Azure/azure-container-networking/blob/master/docs/cni.md) | Azure-CNI allows integration of containers with Azure vNET, and allows them to leverage the set of capabilities that [Azure Virtual Network provides](https://azure.microsoft.com/en-us/services/virtual-network/). For example, securely connect to Azure services or use Azure NSGs. See [azure-cni for some examples](https://docs.microsoft.com/en-us/azure/aks/concepts-network#azure-cni-advanced-networking) | -| Overlay (Overlay networking for Windows in Kubernetes is in *alpha* stage) | Containers are given a vNIC connected to an external vSwitch. Each overlay network gets its own IP subnet, defined by a custom IP prefix.The overlay network driver uses VXLAN encapsulation. | Encapsulated with an outer header, inner packet remains the same. | [Win-overlay](https://github.com/containernetworking/plugins/tree/master/plugins/main/windows/win-overlay), Flannel VXLAN (uses win-overlay) | win-overlay should be used when virtual container networks are desired to be isolated from underlay of hosts (e.g. for security reasons). Allows for IPs to be re-used for different overlay networks (which have different VNID tags) if you are restricted on IPs in your datacenter. This option may be used when the container hosts are not L2 adjacent but have L3 connectivity | -| Transparent (special use case for [ovn-kubernetes](https://github.com/openvswitch/ovn-kubernetes)) | Requires an external vSwitch. Containers are attached to an external vSwitch which enables intra-pod communication via logical networks (logical switches and routers). | Packet is encapsulated either via [GENEVE](https://datatracker.ietf.org/doc/draft-gross-geneve/) or [STT](https://datatracker.ietf.org/doc/draft-davie-stt/) tunneling to reach pods which are not on the same host. <br/> Packets are forwarded or dropped via the tunnel metadata information supplied by the ovn network controller. <br/> NAT is done for north-south communication. | [ovn-kubernetes](https://github.com/openvswitch/ovn-kubernetes) | [Deploy via ansible](https://github.com/openvswitch/ovn-kubernetes/tree/master/contrib). Distributed ACLs can be applied via Kubernetes policies. IPAM support. Load-balancing can be achieved without kube-proxy. NATing is done without using iptables/netsh. | -| NAT (*not used in Kubernetes*) | Containers are given a vNIC connected to an internal vSwitch. DNS/DHCP is provided using an internal component called [WinNAT](https://blogs.technet.microsoft.com/virtualization/2016/05/25/windows-nat-winnat-capabilities-and-limitations/) | MAC and IP is rewritten to host MAC/IP. | [nat](https://github.com/Microsoft/windows-container-networking/tree/master/plugins/nat) | Included here for completeness | +| L2bridge | コンテナは外部のvSwitchに接続されます。コンテナはアンダーレイネットワークに接続されますが、物理ネットワークはコンテナのMACを上り/下りで書き換えるため、MACを学習する必要はありません。コンテナ間トラフィックは、コンテナホスト内でブリッジされます。 | MACはホストのMACに書き換えられ、IPは変わりません。| [win-bridge](https://github.com/containernetworking/plugins/tree/master/plugins/main/windows/win-bridge)、[Azure-CNI](https://github.com/Azure/azure-container-networking/blob/master/docs/cni.md)、Flannelホストゲートウェイは、win-bridgeを使用します。 | win-bridgeはL2bridgeネットワークモードを使用して、コンテナをホストのアンダーレイに接続して、最高のパフォーマンスを提供します。ノード間接続にはユーザー定義ルート(UDR)が必要です。 | +| L2Tunnel | これはl2bridgeの特殊なケースですが、Azureでのみ使用されます。すべてのパケットは、SDNポリシーが適用されている仮想化ホストに送信されます。| MACが書き換えられ、IPがアンダーレイネットワークで表示されます。 | [Azure-CNI](https://github.com/Azure/azure-container-networking/blob/master/docs/cni.md) | Azure-CNIを使用すると、コンテナをAzure vNETと統合し、[Azure Virtual Networkが提供](https://azure.microsoft.com/en-us/services/virtual-network/)する一連の機能を活用できます。たとえば、Azureサービスに安全に接続するか、Azure NSGを使用します。[azure-cniのいくつかの例](https://docs.microsoft.com/en-us/azure/aks/concepts-network#azure-cni-advanced-networking)を参照してください。| +| オーバーレイ(KubernetesのWindows用のオーバーレイネットワークは *アルファ* 段階です) | コンテナには、外部のvSwitchに接続されたvNICが付与されます。各オーバーレイネットワークは、カスタムIPプレフィックスで定義された独自のIPサブネットを取得します。オーバーレイネットワークドライバーは、VXLANを使用してカプセル化します。 | 外部ヘッダーでカプセル化されます。 | [Win-overlay](https://github.com/containernetworking/plugins/tree/master/plugins/main/windows/win-overlay)、Flannel VXLAN (win-overlayを使用) | win-overlayは、仮想コンテナーネットワークをホストのアンダーレイから分離する必要がある場合に使用する必要があります(セキュリティ上の理由など)。データセンター内のIPが制限されている場合に、(異なるVNIDタグを持つ)異なるオーバーレイネットワークでIPを再利用できるようにします。このオプションには、Windows Server 2019で[KB4489899](https://support.microsoft.com/help/4489899)が必要です。| +| 透過的([ovn-kubernetes](https://github.com/openvswitch/ovn-kubernetes)の特別な使用例) | 外部のvSwitchが必要です。コンテナは外部のvSwitchに接続され、論理ネットワーク(論理スイッチおよびルーター)を介したPod内通信を可能にします。 | パケットは、[GENEVE](https://datatracker.ietf.org/doc/draft-gross-geneve/)または[STT](https://datatracker.ietf.org/doc/draft-davie-stt/)トンネリングを介してカプセル化され、同じホスト上にないポッドに到達します。パケットは、ovnネットワークコントローラーによって提供されるトンネルメタデータ情報を介して転送またはドロップされます。NATは南北通信のために行われます。 | [ovn-kubernetes](https://github.com/openvswitch/ovn-kubernetes) | [ansible経由でデプロイ](https://github.com/openvswitch/ovn-kubernetes/tree/master/contrib)します。分散ACLは、Kubernetesポリシーを介して適用できます。 IPAMをサポートします。負荷分散は、kube-proxyなしで実現できます。 NATは、ip​​tables/netshを使用せずに行われます。 | +| NAT(*Kubernetesでは使用されません*) | コンテナには、内部のvSwitchに接続されたvNICが付与されます。DNS/DHCPは、[WinNAT](https://blogs.technet.microsoft.com/virtualization/2016/05/25/windows-nat-winnat-capabilities-and-limitations/)と呼ばれる内部コンポーネントを使用して提供されます。 | MACおよびIPはホストMAC/IPに書き換えられます。 | [nat](https://github.com/Microsoft/windows-container-networking/tree/master/plugins/nat) | 完全を期すためにここに含まれています。 | -As outlined above, the [Flannel](https://github.com/coreos/flannel) CNI [meta plugin](https://github.com/containernetworking/plugins/tree/master/plugins/meta/flannel) is also supported on [Windows](https://github.com/containernetworking/plugins/tree/master/plugins/meta/flannel#windows-support-experimental) via the [VXLAN network backend](https://github.com/coreos/flannel/blob/master/Documentation/backends.md#vxlan) (**alpha support** ; delegates to win-overlay) and [host-gateway network backend](https://github.com/coreos/flannel/blob/master/Documentation/backends.md#host-gw) (stable support; delegates to win-bridge). This plugin supports delegating to one of the reference CNI plugins (win-overlay, win-bridge), to work in conjunction with Flannel daemon on Windows (Flanneld) for automatic node subnet lease assignment and HNS network creation. This plugin reads in its own configuration file (net-conf.json), and aggregates it with the environment variables from the FlannelD generated subnet.env file. It then delegates to one of the reference CNI plugins for network plumbing, and sends the correct configuration containing the node-assigned subnet to the IPAM plugin (e.g. host-local). +上で概説したように、[Flannel](https://github.com/coreos/flannel) CNI[メタプラグイン](https://github.com/containernetworking/plugins/tree/master/plugins/meta/flannel)は、[VXLANネットワークバックエンド](https://github.com/coreos/flannel/blob/master/Documentation/backends.md#vxlan)(**アルファサポート**、win-overlayへのデリゲート)および[ホストゲートウェイネットワークバックエンド](https://github.com/coreos/flannel/blob/master/Documentation/backends.md#host-gw)(安定したサポート、win-bridgeへのデリゲート)を介して[Windows](https://github.com/containernetworking/plugins/tree/master/plugins/meta/flannel#windows-support-experimental)でもサポートされます。このプラグインは、参照CNIプラグイン(win-overlay、win-bridge)の1つへの委任をサポートし、WindowsのFlannelデーモン(Flanneld)と連携して、ノードのサブネットリースの自動割り当てとHNSネットワークの作成を行います。このプラグインは、独自の構成ファイル(cni.conf)を読み取り、FlannelDで生成されたsubnet.envファイルからの環境変数と統合します。次に、ネットワークプラミング用の参照CNIプラグインの1つに委任し、ノード割り当てサブネットを含む正しい構成をIPAMプラグイン(ホストローカルなど)に送信します。 -For the node, pod, and service objects, the following network flows are supported for TCP/UDP traffic: +Node、Pod、およびServiceオブジェクトの場合、TCP/UDPトラフィックに対して次のネットワークフローがサポートされます。: * Pod -> Pod (IP) * Pod -> Pod (Name) * Pod -> Service (Cluster IP) -* Pod -> Service (PQDN, but only if there are no ".") +* Pod -> Service (PQDN、ただし、「.」がない場合のみ) * Pod -> Service (FQDN) * Pod -> External (IP) * Pod -> External (DNS) * Node -> Pod * Pod -> Node -The following IPAM options are supported on Windows: +Windowsでは、次のIPAMオプションがサポートされています。 -* [Host-local](https://github.com/containernetworking/plugins/tree/master/plugins/ipam/host-local) -* HNS IPAM (Inbox platform IPAM, this is a fallback when no IPAM is set) -* [Azure-vnet-ipam](https://github.com/Azure/azure-container-networking/blob/master/docs/ipam.md) (for azure-cni only) +* [ホストローカル](https://github.com/containernetworking/plugins/tree/master/plugins/ipam/host-local) +* HNS IPAM (受信トレイプラットフォームIPAM、これはIPAMが設定されていない場合のフォールバック) +* [Azure-vnet-ipam](https://github.com/Azure/azure-container-networking/blob/master/docs/ipam.md)(azure-cniのみ) -### Limitations +### 制限 -#### Control Plane +#### コントロールプレーン -Windows is only supported as a worker node in the Kubernetes architecture and component matrix. This means that a Kubernetes cluster must always include Linux master nodes, zero or more Linux worker nodes, and zero or more Windows worker nodes. +Windowsは、Kubernetesアーキテクチャとコンポーネントマトリックスのワーカーノードとしてのみサポートされています。つまり、Kubernetesクラスタには常にLinuxマスターノード、0以上のLinuxワーカーノード、0以上のWindowsワーカーノードが含まれている必要があります。 -#### Compute +#### コンピュート -##### Resource management and process isolation +##### リソース管理とプロセス分離 - Linux cgroups are used as a pod boundary for resource controls in Linux. Containers are created within that boundary for network, process and file system isolation. The cgroups APIs can be used to gather cpu/io/memory stats. In contrast, Windows uses a Job object per container with a system namespace filter to contain all processes in a container and provide logical isolation from the host. There is no way to run a Windows container without the namespace filtering in place. This means that system privileges cannot be asserted in the context of the host, and thus privileged containers are not available on Windows. Containers cannot assume an identity from the host because the Security Account Manager (SAM) is separate. +Linux cgroupsは、Linuxのリソースを制御するPodの境界として使用されます。コンテナは、ネットワーク、プロセス、およびファイルシステムを分離するのために、その境界内に作成されます。cgroups APIを使用して、cpu/io/memoryの統計を収集できます。対照的に、Windowsはシステムネームスペースフィルターを備えたコンテナごとのジョブオブジェクトを使用して、コンテナ内のすべてのプロセスを格納し、ホストからの論理的な分離を提供します。ネームスペースフィルタリングを行わずにWindowsコンテナを実行する方法はありません。これは、ホストの環境ではシステム特権を主張できないため、Windowsでは特権コンテナを使用できないことを意味します。セキュリティアカウントマネージャー(SAM)が独立しているため、コンテナはホストからIDを引き受けることができません。 -##### Operating System Restrictions +##### オペレーティングシステムの制限 -Windows has strict compatibility rules, where the host OS version must match the container base image OS version. Only Windows containers with a container operating system of Windows Server 2019 are supported. Hyper-V isolation of containers, enabling some backward compatibility of Windows container image versions, is planned for a future release. +Windowsには厳密な互換性ルールがあり、ホストOSのバージョンとコンテナのベースイメージOSのバージョンは、一致する必要があります。Windows Server 2019のコンテナオペレーティングシステムを備えたWindowsコンテナのみがサポートされます。Hyper-V分離のコンテナは、Windowsコンテナのイメージバージョンに下位互換性を持たせることは、将来のリリースで計画されています。 -##### Feature Restrictions +##### 機能制限 -* TerminationGracePeriod: not implemented -* Single file mapping: to be implemented with CRI-ContainerD -* Termination message: to be implemented with CRI-ContainerD -* Privileged Containers: not currently supported in Windows containers -* HugePages: not currently supported in Windows containers -* The existing node problem detector is Linux-only and requires privileged containers. In general, we don't expect this to be used on Windows because privileged containers are not supported -* Not all features of shared namespaces are supported (see API section for more details) +* TerminationGracePeriod：実装されていません +* 単一ファイルのマッピング：CRI-ContainerDで実装されます +* 終了メッセージ：CRI-ContainerDで実装されます +* 特権コンテナ：現在Windowsコンテナではサポートされていません +* HugePages：現在Windowsコンテナではサポートされていません +* 既存のノード問題を検出する機能はLinux専用であり、特権コンテナが必要です。一般的に、特権コンテナはサポートされていないため、これがWindowsで使用されることは想定していません。 +* ネームスペース共有については、すべての機能がサポートされているわけではありません（詳細については、APIセクションを参照してください） -##### Memory Reservations and Handling +##### メモリ予約と処理 -Windows does not have an out-of-memory process killer as Linux does. Windows always treats all user-mode memory allocations as virtual, and pagefiles are mandatory. The net effect is that Windows won't reach out of memory conditions the same way Linux does, and processes page to disk instead of being subject to out of memory (OOM) termination. If memory is over-provisioned and all physical memory is exhausted, then paging can slow down performance. +Windowsには、Linuxのようなメモリ不足のプロセスキラーはありません。Windowsは常に全ユーザーモードのメモリ割り当てを仮想として扱い、ページファイルは必須です。正味の効果は、WindowsはLinuxのようなメモリ不足の状態にはならず、メモリ不足（OOM）終了の影響を受ける代わりにページをディスクに処理します。メモリが過剰にプロビジョニングされ、物理メモリのすべてが使い果たされると、ページングによってパフォーマンスが低下する可能性があります。 -Keeping memory usage within reasonable bounds is possible with a two-step process. First, use the kubelet parameters `--kubelet-reserve` and/or `--system-reserve` to account for memory usage on the node (outside of containers). This reduces [NodeAllocatable](/ja/docs/tasks/administer-cluster/reserve-compute-resources/#node-allocatable)). As you deploy workloads, use resource limits (must set only limits or limits must equal requests) on containers. This also subtracts from NodeAllocatable and prevents the scheduler from adding more pods once a node is full. +2ステップのプロセスで、メモリ使用量を妥当な範囲内に保つことが可能です。まず、kubeletパラメータ`--kubelet-reserve`や`--system-reserve`を使用して、ノード（コンテナ外）でのメモリ使用量を明確にします。これにより、[NodeAllocatable](/ja/docs/tasks/administer-cluster/reserve-compute-resources/#node-allocatable))が削減されます。ワークロードをデプロイするときは、コンテナにリソース制限をかけます（制限のみを設定するか、制限が要求と等しくなければなりません）。これにより、NodeAllocatableも差し引かれ、ノードのリソースがフルな状態になるとSchedulerがPodを追加できなくなります。 -A best practice to avoid over-provisioning is to configure the kubelet with a system reserved memory of at least 2GB to account for Windows, Docker, and Kubernetes processes. +過剰なプロビジョニングを回避するためのベストプラクティスは、Windows、Docker、およびKubernetesのプロセスに対応するために、最低2GBのメモリを予約したシステムでkubeletを構成することです。 -The behavior of the flags behave differently as described below: +フラグの振舞いについては、次のような異なる動作をします。: -* `--kubelet-reserve`, `--system-reserve` , and `--eviction-hard` flags update Node Allocatable -* Eviction by using `--enforce-node-allocable` is not implemented -* Eviction by using `--eviction-hard` and `--eviction-soft` are not implemented -* MemoryPressure Condition is not implemented -* There are no OOM eviction actions taken by the kubelet -* Kubelet running on the windows node does not have memory restrictions. `--kubelet-reserve` and `--system-reserve` do not set limits on kubelet or processes running on the host. This means kubelet or a process on the host could cause memory resource starvation outside the node-allocatable and scheduler +* `--kubelet-reserve`、`--system-reserve`、および`--eviction-hard`フラグはノードの割り当て可能数を更新します +* `--enforce-node-allocable`を使用した排除は実装されていません +* `--eviction-hard`および`--eviction-soft`を使用した排除は実装されていません +* MemoryPressureの制約は実装されていません +* kubeletによって実行されるOOMを排除することはありません +* Windowsノードで実行されているKubeletにはメモリ制限がありません。`--kubelet-reserve`と`--system-reserve`は、ホストで実行されているkubeletまたはプロセスに制限を設定しません。これは、ホスト上のkubeletまたはプロセスが、NodeAllocatableとSchedulerの外でメモリリソース不足を引き起こす可能性があることを意味します。 -#### Storage +#### ストレージ -Windows has a layered filesystem driver to mount container layers and create a copy filesystem based on NTFS. All file paths in the container are resolved only within the context of that container. +Windowsには、コンテナレイヤーをマウントして、NTFSに基づいて複製されたファイルシステムを作るためのレイヤー構造のファイルシステムドライバーがあります。コンテナ内のすべてのファイルパスは、そのコンテナの環境内だけで決められます。 -* Volume mounts can only target a directory in the container, and not an individual file -* Volume mounts cannot project files or directories back to the host filesystem -* Read-only filesystems are not supported because write access is always required for the Windows registry and SAM database. However, read-only volumes are supported -* Volume user-masks and permissions are not available. Because the SAM is not shared between the host & container, there's no mapping between them. All permissions are resolved within the context of the container +* ボリュームマウントは、コンテナ内のディレクトリのみを対象にすることができ、個別のファイルは対象にできません +* ボリュームマウントは、ファイルまたはディレクトリをホストファイルシステムに投影することはできません +* WindowsレジストリとSAMデータベースには常に書き込みアクセスが必要であるため、読み取り専用ファイルシステムはサポートされていません。ただし、読み取り専用ボリュームはサポートされています +* ボリュームのユーザーマスクと権限は使用できません。SAMはホストとコンテナ間で共有されないため、それらの間のマッピングはありません。すべての権限はコンテナの環境内で決められます -As a result, the following storage functionality is not supported on Windows nodes +その結果、次のストレージ機能はWindowsノードではサポートされません。 -* Volume subpath mounts. Only the entire volume can be mounted in a Windows container. -* Subpath volume mounting for Secrets -* Host mount projection -* DefaultMode (due to UID/GID dependency) -* Read-only root filesystem. Mapped volumes still support readOnly -* Block device mapping -* Memory as the storage medium -* CSI plugins which require privileged containers -* File system features like uui/guid, per-user Linux filesystem permissions -* NFS based storage/volume support -* Expanding the mounted volume (resizefs) +* ボリュームサブパスのマウント。Windowsコンテナにマウントできるのはボリューム全体だけです。 +* シークレットのサブパスボリュームのマウント +* ホストマウントプロジェクション +* DefaultMode（UID/GID依存関係による） +* 読み取り専用のルートファイルシステム。マップされたボリュームは引き続き読み取り専用をサポートします +* ブロックデバイスマッピング +* 記憶媒体としてのメモリ +* uui/guid、ユーザーごとのLinuxファイルシステム権限などのファイルシステム機能 +* NFSベースのストレージ/ボリュームのサポート +* マウントされたボリュームの拡張（resizefs） -#### Networking +#### ネットワーキング -Windows Container Networking differs in some important ways from Linux networking. The [Microsoft documentation for Windows Container Networking](https://docs.microsoft.com/en-us/virtualization/windowscontainers/container-networking/architecture) contains additional details and background. +Windowsコンテナネットワーキングは、Linuxネットワーキングとはいくつかの重要な実装方法の違いがあります。[Microsoft documentation for Windows Container Networking](https://docs.microsoft.com/en-us/virtualization/windowscontainers/container-networking/architecture)には、追加の詳細と背景があります。 -The Windows host networking networking service and virtual switch implement namespacing and can create virtual NICs as needed for a pod or container. However, many configurations such as DNS, routes, and metrics are stored in the Windows registry database rather than /etc/... files as they are on Linux. The Windows registry for the container is separate from that of the host, so concepts like mapping /etc/resolv.conf from the host into a container don't have the same effect they would on Linux. These must be configured using Windows APIs run in the context of that container. Therefore CNI implementations need to call the HNS instead of relying on file mappings to pass network details into the pod or container. +Windowsホストネットワーキングサービスと仮想スイッチはネームスペースを実装して、Podまたはコンテナの必要に応じて仮想NICを作成できます。ただし、DNS、ルート、メトリックなどの多くの構成は、Linuxのような/etc/...ファイルではなく、Windowsレジストリデータベースに保存されます。コンテナのWindowsレジストリはホストのレジストリとは別であるため、ホストからコンテナへの/etc/resolv.confのマッピングなどの概念は、Linuxの場合と同じ効果をもたらしません。これらは、そのコンテナの環境で実行されるWindows APIを使用して構成する必要があります。したがって、CNIの実装は、ファイルマッピングに依存する代わりにHNSを呼び出して、ネットワークの詳細をPodまたはコンテナに渡す必要があります。 -The following networking functionality is not supported on Windows nodes +次のネットワーク機能はWindowsノードではサポートされていません -* Host networking mode is not available for Windows pods -* Local NodePort access from the node itself fails (works for other nodes or external clients) -* Accessing service VIPs from nodes will be available with a future release of Windows Server -* Overlay networking support in kube-proxy is an alpha release. In addition, it requires [KB4482887](https://support.microsoft.com/en-us/help/4482887/windows-10-update-kb4482887) to be installed on Windows Server 2019 -* Local Traffic Policy and DSR mode -* Windows containers connected to l2bridge, l2tunnel, or overlay networks do not support communicating over the IPv6 stack. There is outstanding Windows platform work required to enable these network drivers to consume IPv6 addresses and subsequent Kubernetes work in kubelet, kube-proxy, and CNI plugins. -* Outbound communication using the ICMP protocol via the win-overlay, win-bridge, and Azure-CNI plugin. Specifically, the Windows data plane ([VFP](https://www.microsoft.com/en-us/research/project/azure-virtual-filtering-platform/)) doesn't support ICMP packet transpositions. This means: - * ICMP packets directed to destinations within the same network (e.g. pod to pod communication via ping) work as expected and without any limitations - * TCP/UDP packets work as expected and without any limitations - * ICMP packets directed to pass through a remote network (e.g. pod to external internet communication via ping) cannot be transposed and thus will not be routed back to their source - * Since TCP/UDP packets can still be transposed, one can substitute `ping <destination>` with `curl <destination>` to be able to debug connectivity to the outside world. +* ホストネットワーキングモードはWindows Podでは使用できません +* ノード自体からのローカルNodePortアクセスは失敗します（他のノードまたは外部クライアントで機能） +* ノードからのService VIPへのアクセスは、Windows Serverの将来のリリースで利用可能になる予定です +* kube-proxyのオーバーレイネットワーキングサポートはアルファリリースです。さらに、[KB4482887](https://support.microsoft.com/en-us/help/4482887/windows-10-update-kb4482887)がWindows Server 2019にインストールされている必要があります +* ローカルトラフィックポリシーとDSRモード +* l2bridge、l2tunnel、またはオーバーレイネットワークに接続されたWindowsコンテナは、IPv6スタックを介した通信をサポートしていません。これらのネットワークドライバーがIPv6アドレスを使用できるようにするために必要な機能として、優れたWindowsプラットフォームの機能があり、それに続いて、kubelet、kube-proxy、およびCNIプラグインといったKubernetesの機能があります。 +* win-overlay、win-bridge、およびAzure-CNIプラグインを介したICMPプロトコルを使用したアウトバウンド通信。具体的には、Windowsデータプレーン([VFP](https://www.microsoft.com/en-us/research/project/azure-virtual-filtering-platform/))は、ICMPパケットの置き換えをサポートしていません。これの意味は： + * 同じネットワーク内の宛先に向けられたICMPパケット（pingを介したPod間通信など）は期待どおりに機能し、制限はありません + * TCP/UDPパケットは期待どおりに機能し、制限はありません + * リモートネットワーク（Podからping経由の外部インターネット通信など）を通過するように指示されたICMPパケットは置き換えできないため、ソースにルーティングされません。 + * TCP/UDPパケットは引き続き置き換えできるため、`ping <destination>`を`curl <destination>`に置き換えることで、外部への接続をデバッグできます。 -These features were added in Kubernetes v1.15: +これらの機能はKubernetes v1.15で追加されました。 * `kubectl port-forward` -##### CNI Plugins +##### CNIプラグイン -* Windows reference network plugins win-bridge and win-overlay do not currently implement [CNI spec](https://github.com/containernetworking/cni/blob/master/SPEC.md) v0.4.0 due to missing "CHECK" implementation. -* The Flannel VXLAN CNI has the following limitations on Windows: +* Windowsリファレンスネットワークプラグインのwin-bridgeとwin-overlayは、[CNI仕様](https://github.com/containernetworking/cni/blob/master/SPEC.md)v0.4.0において「CHECK」実装がないため、今のところ実装されていません。 +* Flannel VXLAN CNIについては、Windowsで次の制限があります。: -1. Node-pod connectivity isn't possible by design. It's only possible for local pods with Flannel [PR 1096](https://github.com/coreos/flannel/pull/1096) -2. We are restricted to using VNI 4096 and UDP port 4789. The VNI limitation is being worked on and will be overcome in a future release (open-source flannel changes). See the official [Flannel VXLAN](https://github.com/coreos/flannel/blob/master/Documentation/backends.md#vxlan) backend docs for more details on these parameters. +1. Node-podの直接間接続は設計上不可能です。Flannel[PR 1096](https://github.com/coreos/flannel/pull/1096)を使用するローカルPodでのみ可能です +2. VNI 4096とUDPポート4789の使用に制限されています。VNIの制限は現在取り組んでおり、将来のリリースで解決される予定です（オープンソースのflannelの変更）。これらのパラメーターの詳細については、公式の[Flannel VXLAN](https://github.com/coreos/flannel/blob/master/Documentation/backends.md#vxlan)バックエンドのドキュメントをご覧ください。 ##### DNS {#dns-limitations} -* ClusterFirstWithHostNet is not supported for DNS. Windows treats all names with a '.' as a FQDN and skips PQDN resolution -* On Linux, you have a DNS suffix list, which is used when trying to resolve PQDNs. On Windows, we only have 1 DNS suffix, which is the DNS suffix associated with that pod's namespace (mydns.svc.cluster.local for example). Windows can resolve FQDNs and services or names resolvable with just that suffix. For example, a pod spawned in the default namespace, will have the DNS suffix **default.svc.cluster.local**. On a Windows pod, you can resolve both **kubernetes.default.svc.cluster.local** and **kubernetes**, but not the in-betweens, like **kubernetes.default** or **kubernetes.default.svc**. +* ClusterFirstWithHostNetは、DNSでサポートされていません。Windowsでは、FQDNとしてすべての名前を「.」で扱い、PQDNでの名前解決はスキップします。 +* Linuxでは、PQDNで名前解決しようとするときに使用するDNSサフィックスリストがあります。Windowsでは、1つのDNSサフィックスしかありません。これは、そのPodのNamespaceに関連付けられているDNSサフィックスです（たとえば、mydns.svc.cluster.local）。Windowsでは、そのサフィックスだけで名前解決可能なFQDNおよびServiceまたはNameでの名前解決ができます。たとえば、defaultのNamespaceで生成されたPodには、DNSサフィックス**default.svc.cluster.local**が付けられます。WindowsのPodでは、**kubernetes.default.svc.cluster.local**と**kubernetes**の両方を名前解決できますが、**kubernetes.default**や**kubernetes.default.svc**のような中間での名前解決はできません。 +* Windowsでは、複数のDNSリゾルバーを使用できます。これらには少し異なる動作が付属しているため、ネームクエリの解決には`Resolve-DNSName`ユーティリティを使用することをお勧めします。 -##### Security +##### セキュリティ -Secrets are written in clear text on the node's volume (as compared to tmpfs/in-memory on linux). This means customers have to do two things +Secretはノードのボリュームに平文テキストで書き込まれます（Linuxのtmpfs/in-memoryの比較として）。これはカスタマーが2つのことを行う必要があります -1. Use file ACLs to secure the secrets file location -2. Use volume-level encryption using [BitLocker](https://docs.microsoft.com/en-us/windows/security/information-protection/bitlocker/bitlocker-how-to-deploy-on-windows-server) +1. ファイルACLを使用してSecretファイルの場所を保護する +2. [BitLocker](https://docs.microsoft.com/en-us/windows/security/information-protection/bitlocker/bitlocker-how-to-deploy-on-windows-server)を使って、ボリュームレベルの暗号化を使用する -[RunAsUser ](/ja/docs/concepts/policy/pod-security-policy/#users-and-groups)is not currently supported on Windows. The workaround is to create local accounts before packaging the container. The RunAsUsername capability may be added in a future release. +[RunAsUser](/docs/concepts/policy/pod-security-policy/#users-and-groups)は、現在Windowsではサポートされていません。回避策は、コンテナをパッケージ化する前にローカルアカウントを作成することです。RunAsUsername機能は、将来のリリースで追加される可能性があります。 -Linux specific pod security context privileges such as SELinux, AppArmor, Seccomp, Capabilities (POSIX Capabilities), and others are not supported. +SELinux、AppArmor、Seccomp、特性（POSIX機能）のような、Linux固有のPodセキュリティ環境の権限はサポートされていません。 -In addition, as mentioned already, privileged containers are not supported on Windows. +さらに、既に述べたように特権付きコンテナは、Windowsにおいてサポートされていません。 #### API -There are no differences in how most of the Kubernetes APIs work for Windows. The subtleties around what's different come down to differences in the OS and container runtime. In certain situations, some properties on workload APIs such as Pod or Container were designed with an assumption that they are implemented on Linux, failing to run on Windows. +ほとんどのKubernetes APIがWindowsでも機能することに違いはありません。そのわずかな違いはOSとコンテナランタイムの違いによるものです。特定の状況では、PodやコンテナなどのワークロードAPIの一部のプロパティが、Linuxで実装されているが、Windowsでは実行できないことを前提に設計されています。 -At a high level, these OS concepts are different: +高いレベルで、これらOSのコンセプトに違いがります。: -* Identity - Linux uses userID (UID) and groupID (GID) which are represented as integer types. User and group names are not canonical - they are just an alias in `/etc/groups` or `/etc/passwd` back to UID+GID. Windows uses a larger binary security identifier (SID) which is stored in the Windows Security Access Manager (SAM) database. This database is not shared between the host and containers, or between containers. -* File permissions - Windows uses an access control list based on SIDs, rather than a bitmask of permissions and UID+GID -* File paths - convention on Windows is to use `\` instead of `/`. The Go IO libraries typically accept both and just make it work, but when you're setting a path or command line that's interpreted inside a container, `\` may be needed. -* Signals - Windows interactive apps handle termination differently, and can implement one or more of these: - * A UI thread handles well-defined messages including WM_CLOSE - * Console apps handle ctrl-c or ctrl-break using a Control Handler - * Services register a Service Control Handler function that can accept SERVICE_CONTROL_STOP control codes +* ID - Linuxでは、Integer型として表されるuserID（UID）とgroupID（GID）を使用します。ユーザー名とグループ名は正規ではありません - それらは、UID+GIDの背後にある`/etc/groups`または`/etc/passwd`の単なるエイリアスです。Windowsは、Windows Security Access Manager（SAM）データベースに格納されているより大きなバイナリセキュリティ識別子（SID）を使用します。このデータベースは、ホストとコンテナ間、またはコンテナ間で共有されません。 +* ファイル権限 - Windowsは、権限とUID+GIDのビットマスクではなく、SIDに基づくアクセス制御リストを使用します +* ファイルパス - Windowsの規則では、`/`ではなく`\`を使用します。Go IOライブラリは通常両方を受け入れ、それを機能させるだけですが、コンテナ内で解釈されるパスまたはコマンドラインを設定する場合、`\`が必要になる場合があります。 +* シグナル - Windowsのインタラクティブなアプリは終了を異なる方法で処理し、次の1つ以上を実装できます。: + * UIスレッドは、WM_CLOSEを含む明確に定義されたメッセージを処理します + * コンソールアプリは、コントロールハンドラーを使用してctrl-cまたはctrl-breakを処理します + * サービスは、SERVICE_CONTROL_STOP制御コードを受け入れることができるサービスコントロールハンドラー関数を登録します。 -Exit Codes follow the same convention where 0 is success, nonzero is failure. The specific error codes may differ across Windows and Linux. However, exit codes passed from the Kubernetes components (kubelet, kube-proxy) are unchanged. +終了コードは、0が成功、0以外が失敗の場合と同じ規則に従います。特定のエラーコードは、WindowsとLinuxで異なる場合があります。ただし、Kubernetesのコンポーネント（kubelet、kube-proxy）から渡される終了コードは変更されていません。 ##### V1.Container -* V1.Container.ResourceRequirements.limits.cpu and V1.Container.ResourceRequirements.limits.memory - Windows doesn't use hard limits for CPU allocations. Instead, a share system is used. The existing fields based on millicores are scaled into relative shares that are followed by the Windows scheduler. [see: kuberuntime/helpers_windows.go](https://github.com/kubernetes/kubernetes/blob/master/pkg/kubelet/kuberuntime/helpers_windows.go), [see: resource controls in Microsoft docs](https://docs.microsoft.com/en-us/virtualization/windowscontainers/manage-containers/resource-controls) - * Huge pages are not implemented in the Windows container runtime, and are not available. They require [asserting a user privilege](https://docs.microsoft.com/en-us/windows/desktop/Memory/large-page-support) that's not configurable for containers. -* V1.Container.ResourceRequirements.requests.cpu and V1.Container.ResourceRequirements.requests.memory - Requests are subtracted from node available resources, so they can be used to avoid overprovisioning a node. However, they cannot be used to guarantee resources in an overprovisioned node. They should be applied to all containers as a best practice if the operator wants to avoid overprovisioning entirely. -* V1.Container.SecurityContext.allowPrivilegeEscalation - not possible on Windows, none of the capabilities are hooked up -* V1.Container.SecurityContext.Capabilities - POSIX capabilities are not implemented on Windows -* V1.Container.SecurityContext.privileged - Windows doesn't support privileged containers -* V1.Container.SecurityContext.procMount - Windows doesn't have a /proc filesystem -* V1.Container.SecurityContext.readOnlyRootFilesystem - not possible on Windows, write access is required for registry & system processes to run inside the container -* V1.Container.SecurityContext.runAsGroup - not possible on Windows, no GID support -* V1.Container.SecurityContext.runAsNonRoot - Windows does not have a root user. The closest equivalent is ContainerAdministrator which is an identity that doesn't exist on the node. -* V1.Container.SecurityContext.runAsUser - not possible on Windows, no UID support as int. -* V1.Container.SecurityContext.seLinuxOptions - not possible on Windows, no SELinux -* V1.Container.terminationMessagePath - this has some limitations in that Windows doesn't support mapping single files. The default value is /dev/termination-log, which does work because it does not exist on Windows by default. +* V1.Container.ResourceRequirements.limits.cpuおよびV1.Container.ResourceRequirements.limits.memory - Windowsは、CPU割り当てにハード制限を使用しません。代わりに、共有システムが使用されます。ミリコアに基づく既存のフィールドは、Windowsスケジューラーによって追従される相対共有にスケーリングされます。[参照: kuberuntime/helpers_windows.go](https://github.com/kubernetes/kubernetes/blob/master/pkg/kubelet/kuberuntime/helpers_windows.go)、[参照: resource controls in Microsoft docs](https://docs.microsoft.com/en-us/virtualization/windowscontainers/manage-containers/resource-controls) + * Huge Pagesは、Windowsコンテナランタイムには実装されてないので、使用できません。コンテナに対して設定できない[ユーザー特権を主張](https://docs.microsoft.com/en-us/windows/desktop/Memory/large-page-support)する必要があります。 +* V1.Container.ResourceRequirements.requests.cpuおよびV1.Container.ResourceRequirements.requests.memory - リクエストはノードの利用可能なリソースから差し引かれるので、ノードのオーバープロビジョニングを回避するために使用できます。ただし、過剰にプロビジョニングされたノードのリソースを保証するために使用することはできません。オペレーターが完全にプロビジョニングし過ぎないようにする場合は、ベストプラクティスとしてこれらをすべてのコンテナに適用する必要があります。 +* V1.Container.SecurityContext.allowPrivilegeEscalation - Windowsでは使用できません、接続されている機能はありません +* V1.Container.SecurityContext.Capabilities - POSIX機能はWindowsでは実装されていません +* V1.Container.SecurityContext.privileged - Windowsでは特権コンテナをサポートしていません +* V1.Container.SecurityContext.procMount - Windowsでは/procファイルシステムがありません +* V1.Container.SecurityContext.readOnlyRootFilesystem - Windowsでは使用できません、レジストリおよびシステムプロセスがコンテナ内で実行するには、書き込みアクセスが必要です +* V1.Container.SecurityContext.runAsGroup - Windowsでは使用できません、GIDのサポートもありません +* V1.Container.SecurityContext.runAsNonRoot - Windowsではrootユーザーが存在しません。最も近いものは、ノードに存在しないIDであるContainerAdministratorです。 +* V1.Container.SecurityContext.runAsUser - Windowsでは使用できません。intとしてのUIDはサポートされていません。 +* V1.Container.SecurityContext.seLinuxOptions - Windowsでは使用できません、SELinuxがありません +* V1.Container.terminationMessagePath - これは、Windowsが単一ファイルのマッピングをサポートしないという点でいくつかの制限があります。デフォルト値は/dev/termination-logであり、デフォルトではWindowsに存在しないため動作します。 ##### V1.Pod -* V1.Pod.hostIPC, v1.pod.hostpid - host namespace sharing is not possible on Windows -* V1.Pod.hostNetwork - There is no Windows OS support to share the host network -* V1.Pod.dnsPolicy - ClusterFirstWithHostNet - is not supported because Host Networking is not supported on Windows. -* V1.Pod.podSecurityContext - see V1.PodSecurityContext below -* V1.Pod.shareProcessNamespace - this is a beta feature, and depends on Linux namespaces which are not implemented on Windows. Windows cannot share process namespaces or the container's root filesystem. Only the network can be shared. -* V1.Pod.terminationGracePeriodSeconds - this is not fully implemented in Docker on Windows, see: [reference](https://github.com/moby/moby/issues/25982). The behavior today is that the ENTRYPOINT process is sent CTRL_SHUTDOWN_EVENT, then Windows waits 5 seconds by default, and finally shuts down all processes using the normal Windows shutdown behavior. The 5 second default is actually in the Windows registry [inside the container](https://github.com/moby/moby/issues/25982#issuecomment-426441183), so it can be overridden when the container is built. -* V1.Pod.volumeDevices - this is a beta feature, and is not implemented on Windows. Windows cannot attach raw block devices to pods. -* V1.Pod.volumes - EmptyDir, Secret, ConfigMap, HostPath - all work and have tests in TestGrid - * V1.emptyDirVolumeSource - the Node default medium is disk on Windows. Memory is not supported, as Windows does not have a built-in RAM disk. -* V1.VolumeMount.mountPropagation - mount propagation is not supported on Windows. +* V1.Pod.hostIPC、v1.pod.hostpid - Windowsではホストのネームスペースを共有することはできません +* V1.Pod.hostNetwork - ホストのネットワークを共有するためのWindows OSサポートはありません +* V1.Pod.dnsPolicy - ClusterFirstWithHostNet - Windowsではホストネットワーキングがサポートされていないため、サポートされていません。 +* V1.Pod.podSecurityContext - 以下のV1.PodSecurityContextを参照 +* V1.Pod.shareProcessNamespace - これはベータ版の機能であり、Windowsに実装されていないLinuxのNamespace機能に依存しています。Windowsでは、プロセスのネームスペースまたはコンテナのルートファイルシステムを共有できません。共有できるのはネットワークだけです。 +* V1.Pod.terminationGracePeriodSeconds - これはWindowsのDockerに完全には実装されていません。[リファレンス](https://github.com/moby/moby/issues/25982)を参照してください。今日の動作では、ENTRYPOINTプロセスにCTRL_SHUTDOWN_EVENTが送信され、Windowsではデフォルトで5秒待機し、最後に通常のWindowsシャットダウン動作を使用してすべてのプロセスをシャットダウンします。5秒のデフォルトは、実際にはWindowsレジストリー[コンテナ内](https://github.com/moby/moby/issues/25982#issuecomment-426441183)にあるため、コンテナ作成時にオーバーライドできます。 +* V1.Pod.volumeDevices - これはベータ機能であり、Windowsには実装されていません。Windowsでは、rawブロックデバイスをPodに接続できません。 +* V1.Pod.volumes-EmptyDir、Secret、ConfigMap、HostPath - すべて動作し、TestGridにテストがあります + * V1.emptyDirVolumeSource - ノードのデフォルトのメディアはWindowsのディスクです。Windowsでは、RAMディスクが組み込まれていないため、メモリはサポートされていません。 +* V1.VolumeMount.mountPropagation - mount propagationは、Windowsではサポートされていません。 ##### V1.PodSecurityContext -None of the PodSecurityContext fields work on Windows. They're listed here for reference. +Windowsでは、PodSecurityContextフィールドはどれも機能しません。これらは参照用にここにリストされています。 -* V1.PodSecurityContext.SELinuxOptions - SELinux is not available on Windows -* V1.PodSecurityContext.RunAsUser - provides a UID, not available on Windows -* V1.PodSecurityContext.RunAsGroup - provides a GID, not available on Windows -* V1.PodSecurityContext.RunAsNonRoot - Windows does not have a root user. The closest equivalent is ContainerAdministrator which is an identity that doesn't exist on the node. -* V1.PodSecurityContext.SupplementalGroups - provides GID, not available on Windows -* V1.PodSecurityContext.Sysctls - these are part of the Linux sysctl interface. There's no equivalent on Windows. +* V1.PodSecurityContext.SELinuxOptions - SELinuxは、Windowsでは使用できません +* V1.PodSecurityContext.RunAsUser - UIDを提供しますが、Windowsでは使用できません +* V1.PodSecurityContext.RunAsGroup - GIDを提供しますが、Windowsでは使用できません +* V1.PodSecurityContext.RunAsNonRoot - Windowsにはrootユーザーがありません。最も近いものは、ノードに存在しないIDであるContainerAdministratorです。 +* V1.PodSecurityContext.SupplementalGroups - GIDを提供しますが、Windowsでは使用できません +* V1.PodSecurityContext.Sysctls - これらはLinuxのsysctlインターフェースの一部です。Windowsには同等のものはありません。 -## Getting Help and Troubleshooting {#troubleshooting} +## ヘルプとトラブルシューティングを学ぶ {#troubleshooting} -Your main source of help for troubleshooting your Kubernetes cluster should start with this [section](/ja/docs/tasks/debug-application-cluster/troubleshooting/). Some additional, Windows-specific troubleshooting help is included in this section. Logs are an important element of troubleshooting issues in Kubernetes. Make sure to include them any time you seek troubleshooting assistance from other contributors. Follow the instructions in the SIG-Windows [contributing guide on gathering logs](https://github.com/kubernetes/community/blob/master/sig-windows/CONTRIBUTING.md#gathering-logs). +Kubernetesクラスターのトラブルシューティングの主なヘルプソースは、この[セクション](/docs/tasks/debug-application-cluster/troubleshooting/)から始める必要があります。このセクションには、いくつか追加的な、Windows固有のトラブルシューティングヘルプが含まれています。ログは、Kubernetesにおけるトラブルシューティング問題の重要な要素です。他のコントリビューターからトラブルシューティングの支援を求めるときは、必ずそれらを含めてください。SIG-Windows[ログ収集に関するコントリビュートガイド](https://github.com/kubernetes/community/blob/master/sig-windows/CONTRIBUTING.md#gathering-logs)の指示に従ってください。 -1. How do I know start.ps1 completed successfully? +1. start.ps1が正常に完了したことをどのように確認できますか？ - You should see kubelet, kube-proxy, and (if you chose Flannel as your networking solution) flanneld host-agent processes running on your node, with running logs being displayed in separate PowerShell windows. In addition to this, your Windows node should be listed as "Ready" in your Kubernetes cluster. + ノード上でkubelet、kube-proxy、および（ネットワーキングソリューションとしてFlannelを選択した場合）flanneldホストエージェントプロセスが実行され、実行ログが個別のPowerShellウィンドウに表示されます。これに加えて、WindowsノードがKubernetesクラスターで「Ready」として表示されているはずです。 -1. Can I configure the Kubernetes node processes to run in the background as services? +1. Kubernetesノードのプロセスをサービスとしてバックグラウンドで実行するように構成できますか？ - Kubelet and kube-proxy are already configured to run as native Windows Services, offering resiliency by re-starting the services automatically in the event of failure (for example a process crash). You have two options for configuring these node components as services. + Kubeletとkube-proxyは、ネイティブのWindowsサービスとして実行するように既に構成されています、障害（例えば、プロセスのクラッシュ）が発生した場合にサービスを自動的に再起動することにより、復元性を提供します。これらのノードコンポーネントをサービスとして構成するには、2つのオプションがあります。 - 1. As native Windows Services + 1. ネイティブWindowsサービスとして - Kubelet & kube-proxy can be run as native Windows Services using `sc.exe`. + Kubeletとkube-proxyは、`sc.exe`を使用してネイティブのWindowsサービスとして実行できます。 ```powershell - # Create the services for kubelet and kube-proxy in two separate commands + # 2つの個別のコマンドでkubeletおよびkube-proxyのサービスを作成する sc.exe create <component_name> binPath= "<path_to_binary> --service <other_args>" - # Please note that if the arguments contain spaces, they must be escaped. + # 引数にスペースが含まれている場合は、エスケープする必要があることに注意してください。 sc.exe create kubelet binPath= "C:\kubelet.exe --service --hostname-override 'minion' <other_args>" - # Start the services + # サービスを開始する Start-Service kubelet Start-Service kube-proxy - # Stop the service + # サービスを停止する Stop-Service kubelet (-Force) Stop-Service kube-proxy (-Force) - # Query the service status + # サービスの状態を問い合わせる Get-Service kubelet Get-Service kube-proxy ``` - 1. Using nssm.exe + 1. nssm.exeの使用 - You can also always use alternative service managers like [nssm.exe](https://nssm.cc/) to run these processes (flanneld, kubelet & kube-proxy) in the background for you. You can use this [sample script](https://github.com/Microsoft/SDN/tree/master/Kubernetes/flannel/register-svc.ps1), leveraging nssm.exe to register kubelet, kube-proxy, and flanneld.exe to run as Windows services in the background. + また、[nssm.exe](https://nssm.cc/)などの代替サービスマネージャーを使用して、これらのプロセス（flanneld、kubelet、kube-proxy）をバックグラウンドで実行することもできます。この[サンプルスクリプト](https://github.com/Microsoft/SDN/tree/master/Kubernetes/flannel/register-svc.ps1)を使用すると、nssm.exeを利用してkubelet、kube-proxy、flanneld.exeを登録し、Windowsサービスとしてバックグラウンドで実行できます。 ```powershell register-svc.ps1 -NetworkMode <Network mode> -ManagementIP <Windows Node IP> -ClusterCIDR <Cluster subnet> -KubeDnsServiceIP <Kube-dns Service IP> -LogDir <Directory to place logs> - # NetworkMode = The network mode l2bridge (flannel host-gw, also the default value) or overlay (flannel vxlan) chosen as a network solution - # ManagementIP = The IP address assigned to the Windows node. You can use ipconfig to find this - # ClusterCIDR = The cluster subnet range. (Default value 10.244.0.0/16) - # KubeDnsServiceIP = The Kubernetes DNS service IP (Default value 10.96.0.10) - # LogDir = The directory where kubelet and kube-proxy logs are redirected into their respective output files (Default value C:\k) + # NetworkMode = ネットワークソリューションとして選択されたネットワークモードl2bridge（flannel host-gw、これもデフォルト値）またはoverlay（flannel vxlan） + # ManagementIP = Windowsノードに割り当てられたIPアドレス。 ipconfigを使用してこれを見つけることができます + # ClusterCIDR = クラスターのサブネット範囲。（デフォルト値 10.244.0.0/16） + # KubeDnsServiceIP = Kubernetes DNSサービスIP（デフォルト値 10.96.0.10） + # LogDir = kubeletおよびkube-proxyログがそれぞれの出力ファイルにリダイレクトされるディレクトリ（デフォルト値 C:\k） ``` - If the above referenced script is not suitable, you can manually configure nssm.exe using the following examples. + 上記のスクリプトが適切でない場合は、次の例を使用してnssm.exeを手動で構成できます。 ```powershell - # Register flanneld.exe + # flanneld.exeを登録する nssm install flanneld C:\flannel\flanneld.exe nssm set flanneld AppParameters --kubeconfig-file=c:\k\config --iface=<ManagementIP> --ip-masq=1 --kube-subnet-mgr=1 nssm set flanneld AppEnvironmentExtra NODE_NAME=<hostname> nssm set flanneld AppDirectory C:\flannel nssm start flanneld - # Register kubelet.exe - # Microsoft releases the pause infrastructure container at mcr.microsoft.com/k8s/core/pause:1.2.0 - # For more info search for "pause" in the "Guide for adding Windows Nodes in Kubernetes" + # kubelet.exeを登録 + # マイクロソフトは、mcr.microsoft.com/k8s/core/pause:1.2.0としてポーズインフラストラクチャコンテナをリリース + # 詳細については、「KubernetesにWindowsノードを追加するためのガイド」で「pause」を検索してください nssm install kubelet C:\k\kubelet.exe nssm set kubelet AppParameters --hostname-override=<hostname> --v=6 --pod-infra-container-image=mcr.microsoft.com/k8s/core/pause:1.2.0 --resolv-conf="" --allow-privileged=true --enable-debugging-handlers --cluster-dns=<DNS-service-IP> --cluster-domain=cluster.local --kubeconfig=c:\k\config --hairpin-mode=promiscuous-bridge --image-pull-progress-deadline=20m --cgroups-per-qos=false --log-dir=<log directory> --logtostderr=false --enforce-node-allocatable="" --network-plugin=cni --cni-bin-dir=c:\k\cni --cni-conf-dir=c:\k\cni\config nssm set kubelet AppDirectory C:\k nssm start kubelet - # Register kube-proxy.exe (l2bridge / host-gw) + # kube-proxy.exeを登録する (l2bridge / host-gw) nssm install kube-proxy C:\k\kube-proxy.exe nssm set kube-proxy AppDirectory c:\k nssm set kube-proxy AppParameters --v=4 --proxy-mode=kernelspace --hostname-override=<hostname>--kubeconfig=c:\k\config --enable-dsr=false --log-dir=<log directory> --logtostderr=false @@ -401,7 +418,7 @@ Your main source of help for troubleshooting your Kubernetes cluster should star nssm set kube-proxy DependOnService kubelet nssm start kube-proxy - # Register kube-proxy.exe (overlay / vxlan) + # kube-proxy.exeを登録する (overlay / vxlan) nssm install kube-proxy C:\k\kube-proxy.exe nssm set kube-proxy AppDirectory c:\k nssm set kube-proxy AppParameters --v=4 --proxy-mode=kernelspace --feature-gates="WinOverlay=true" --hostname-override=<hostname> --kubeconfig=c:\k\config --network-name=vxlan0 --source-vip=<source-vip> --enable-dsr=false --log-dir=<log directory> --logtostderr=false @@ -410,68 +427,68 @@ Your main source of help for troubleshooting your Kubernetes cluster should star ``` - For initial troubleshooting, you can use the following flags in [nssm.exe](https://nssm.cc/) to redirect stdout and stderr to a output file: + 最初のトラブルシューティングでは、[nssm.exe](https://nssm.cc/)で次のフラグを使用して、stdoutおよびstderrを出力ファイルにリダイレクトできます。: ```powershell nssm set <Service Name> AppStdout C:\k\mysvc.log nssm set <Service Name> AppStderr C:\k\mysvc.log ``` - For additional details, see official [nssm usage](https://nssm.cc/usage) docs. + 詳細については、公式の[nssmの使用法](https://nssm.cc/usage)のドキュメントを参照してください。 -1. My Windows Pods do not have network connectivity +1. Windows Podにネットワーク接続がありません - If you are using virtual machines, ensure that MAC spoofing is enabled on all the VM network adapter(s). + 仮想マシンを使用している場合は、すべてのVMネットワークアダプターでMACスプーフィングが有効になっていることを確認してください。 -1. My Windows Pods cannot ping external resources +1. Windows Podが外部リソースにpingできません - Windows Pods do not have outbound rules programmed for the ICMP protocol today. However, TCP/UDP is supported. When trying to demonstrate connectivity to resources outside of the cluster, please substitute `ping <IP>` with corresponding `curl <IP>` commands. + 現在、Windows Podには、ICMPプロトコル用にプログラムされた送信ルールはありません。ただし、TCP/UDPはサポートされています。クラスター外のリソースへの接続を実証する場合は、`ping <IP>`に対応する`curl <IP>`コマンドに置き換えてください。 - If you are still facing problems, most likely your network configuration in [cni.conf](https://github.com/Microsoft/SDN/blob/master/Kubernetes/flannel/l2bridge/cni/config/cni.conf) deserves some extra attention. You can always edit this static file. The configuration update will apply to any newly created Kubernetes resources. + それでも問題が解決しない場合は、[cni.conf](https://github.com/Microsoft/SDN/blob/master/Kubernetes/flannel/l2bridge/cni/config/cni.conf)のネットワーク構成に値する可能性があるので、いくつかの特別な注意が必要です。この静的ファイルはいつでも編集できます。構成の更新は、新しく作成されたすべてのKubernetesリソースに適用されます。 - One of the Kubernetes networking requirements (see [Kubernetes model](/ja/docs/concepts/cluster-administration/networking/)) is for cluster communication to occur without NAT internally. To honor this requirement, there is an [ExceptionList](https://github.com/Microsoft/SDN/blob/master/Kubernetes/flannel/l2bridge/cni/config/cni.conf#L20) for all the communication where we do not want outbound NAT to occur. However, this also means that you need to exclude the external IP you are trying to query from the ExceptionList. Only then will the traffic originating from your Windows pods be SNAT'ed correctly to receive a response from the outside world. In this regard, your ExceptionList in `cni.conf` should look as follows: + Kubernetesのネットワーキング要件の1つ(参照[Kubernetesモデル](/ja/docs/concepts/cluster-administration/networking/))は、内部でNATを使用せずにクラスター通信を行うためのものです。この要件を遵守するために、すべての通信に[ExceptionList](https://github.com/Microsoft/SDN/blob/master/Kubernetes/flannel/l2bridge/cni/config/cni.conf#L20)があり、アウトバウンドNATが発生しないようにします。ただし、これは、クエリしようとしている外部IPをExceptionListから除外する必要があることも意味します。そうして初めて、Windows PodからのトラフィックがSNAT処理され、外部からの応答を受信できるようになります。この点で、`cni.conf`のExceptionListは次のようになります。: ```conf "ExceptionList": [ - "10.244.0.0/16", # Cluster subnet - "10.96.0.0/12", # Service subnet - "10.127.130.0/24" # Management (host) subnet + "10.244.0.0/16", # クラスターのサブネット + "10.96.0.0/12", # Serviceのサブネット + "10.127.130.0/24" # 管理 (ホスト) のサブネット ] ``` -1. My Windows node cannot access NodePort service +1. WindowsノードがNodePort Serviceにアクセスできません - Local NodePort access from the node itself fails. This is a known limitation. NodePort access works from other nodes or external clients. + ノード自体からのローカルNodePortアクセスは失敗します。これは既知の制限です。NodePortアクセスは、他のノードまたは外部クライアントから行えます。 -1. vNICs and HNS endpoints of containers are being deleted +1. コンテナのvNICとHNSエンドポイントが削除されています - This issue can be caused when the `hostname-override` parameter is not passed to [kube-proxy](/ja/docs/reference/command-line-tools-reference/kube-proxy/). To resolve it, users need to pass the hostname to kube-proxy as follows: + この問題は、`hostname-override`パラメータが[kube-proxy](/docs/reference/command-line-tools-reference/kube-proxy/)に渡されない場合に発生する可能性があります。これを解決するには、ユーザーは次のようにホスト名をkube-proxyに渡す必要があります。: ```powershell C:\k\kube-proxy.exe --hostname-override=$(hostname) ``` -1. With flannel my nodes are having issues after rejoining a cluster +1. flannelを使用すると、クラスターに再参加した後、ノードに問題が発生します - Whenever a previously deleted node is being re-joined to the cluster, flannelD tries to assign a new pod subnet to the node. Users should remove the old pod subnet configuration files in the following paths: + 以前に削除されたノードがクラスターに再参加するときはいつも、flannelDは新しいPodサブネットをノードに割り当てようとします。ユーザーは、次のパスにある古いPodサブネット構成ファイルを削除する必要があります。: ```powershell Remove-Item C:\k\SourceVip.json Remove-Item C:\k\SourceVipRequest.json ``` -1. After launching `start.ps1`, flanneld is stuck in "Waiting for the Network to be created" +1. `start.ps1`を起動した後、flanneldが「ネットワークが作成されるのを待っています」と表示されたままになります - There are numerous reports of this [issue which are being investigated](https://github.com/coreos/flannel/issues/1066); most likely it is a timing issue for when the management IP of the flannel network is set. A workaround is to simply relaunch start.ps1 or relaunch it manually as follows: + この[調査中の問題](https://github.com/coreos/flannel/issues/1066)に関する多数の報告があります。最も可能性が高いのは、flannelネットワークの管理IPが設定されるタイミングの問題です。回避策は、単純にstart.ps1を再起動するか、次のように手動で再起動することです。: ```powershell PS C:> [Environment]::SetEnvironmentVariable("NODE_NAME", "<Windows_Worker_Hostname>") PS C:> C:\flannel\flanneld.exe --kubeconfig-file=c:\k\config --iface=<Windows_Worker_Node_IP> --ip-masq=1 --kube-subnet-mgr=1 ``` -1. My Windows Pods cannot launch because of missing `/run/flannel/subnet.env` +1. `/run/flannel/subnet.env`がないため、Windows Podを起動できません - This indicates that Flannel didn't launch correctly. You can either try to restart flanneld.exe or you can copy the files over manually from `/run/flannel/subnet.env` on the Kubernetes master to` C:\run\flannel\subnet.env` on the Windows worker node and modify the `FLANNEL_SUBNET` row to a different number. For example, if node subnet 10.244.4.1/24 is desired: + これは、Flannelが正しく起動しなかったことを示しています。 flanneld.exeの再起動を試みるか、Kubernetesマスターの`/run/flannel/subnet.env`からWindowsワーカーノードの`C:\run\flannel\subnet.env`に手動でファイルをコピーすることができます。「FLANNEL_SUBNET」行を別の番号に変更します。たとえば、ノードサブネット10.244.4.1/24が必要な場合は以下となります。: ```env FLANNEL_NETWORK=10.244.0.0/16 @@ -480,77 +497,91 @@ Your main source of help for troubleshooting your Kubernetes cluster should star FLANNEL_IPMASQ=true ``` -1. My Windows node cannot access my services using the service IP +1. WindowsノードがService IPを使用してServiceにアクセスできない - This is a known limitation of the current networking stack on Windows. Windows Pods are able to access the service IP however. + これは、Windows上の現在のネットワークスタックの既知の制限です。ただし、Windows PodはService IPにアクセスできます。 -1. No network adapter is found when starting kubelet +1. kubeletの起動時にネットワークアダプターが見つかりません - The Windows networking stack needs a virtual adapter for Kubernetes networking to work. If the following commands return no results (in an admin shell), virtual network creation — a necessary prerequisite for Kubelet to work — has failed: + WindowsネットワーキングスタックがKubernetesネットワーキングを動かすには、仮想アダプターが必要です。次のコマンドを実行しても結果が返されない場合（管理シェルで）、仮想ネットワークの作成（Kubeletが機能するために必要な前提条件）に失敗したことになります。: ```powershell Get-HnsNetwork | ? Name -ieq "cbr0" Get-NetAdapter | ? Name -Like "vEthernet (Ethernet*" ``` - Often it is worthwhile to modify the [InterfaceName](https://github.com/Microsoft/SDN/blob/master/Kubernetes/flannel/l2bridge/start.ps1#L6) parameter of the start.ps1 script, in cases where the host's network adapter isn't "Ethernet". Otherwise, consult the output of the `start-kubelet.ps1` script to see if there are errors during virtual network creation. + ホストのネットワークアダプターが「イーサネット」ではない場合、多くの場合、start.ps1スクリプトの[InterfaceName](https://github.com/microsoft/SDN/blob/master/Kubernetes/flannel/start.ps1#L6)パラメーターを修正する価値があります。そうでない場合は`start-kubelet.ps1`スクリプトの出力結果を調べて、仮想ネットワークの作成中にエラーがないか確認します。 -1. My Pods are stuck at "Container Creating" or restarting over and over +1. Podが「Container Creating」と表示されたまま動かなくなったり、何度も再起動を繰り返します - Check that your pause image is compatible with your OS version. The [instructions](https://docs.microsoft.com/en-us/virtualization/windowscontainers/kubernetes/deploying-resources) assume that both the OS and the containers are version 1803. If you have a later version of Windows, such as an Insider build, you need to adjust the images accordingly. Please refer to the Microsoft's [Docker repository](https://hub.docker.com/u/microsoft/) for images. Regardless, both the pause image Dockerfile and the sample service expect the image to be tagged as :latest. + PauseイメージがOSバージョンと互換性があることを確認してください。[説明](https://docs.microsoft.com/en-us/virtualization/windowscontainers/kubernetes/deploying-resources)では、OSとコンテナの両方がバージョン1803であると想定しています。それ以降のバージョンのWindowsを使用している場合は、Insiderビルドなどでは、それに応じてイメージを調整する必要があります。イメージについては、Microsoftの[Dockerレジストリ](https://hub.docker.com/u/microsoft/)を参照してください。いずれにしても、PauseイメージのDockerfileとサンプルサービスの両方で、イメージに:latestのタグが付けられていると想定しています。 - Starting with Kubernetes v1.14, Microsoft releases the pause infrastructure container at `mcr.microsoft.com/k8s/core/pause:1.2.0`. For more information search for "pause" in the [Guide for adding Windows Nodes in Kubernetes](../user-guide-windows-nodes). + Kubernetes v1.14以降、MicrosoftはPauseインフラストラクチャコンテナを`mcr.microsoft.com/k8s/core/pause:1.2.0`でリリースしています。詳細については、[KubernetesにWindowsノードを追加するためのガイド](../user-guide-windows-nodes)で「Pause」を検索してください。 -1. DNS resolution is not properly working +1. DNS名前解決が正しく機能していない - Check the DNS limitations for Windows in this [section](#dns-limitations). + この[セクション](#dns-limitations)でDNSの制限を確認してください。 -1. `kubectl port-forward` fails with "unable to do port forwarding: wincat not found" +1. `kubectl port-forward`が「ポート転送を実行できません:wincatが見つかりません」で失敗します - This was implemented in Kubernetes 1.15, and the pause infrastructure container `mcr.microsoft.com/k8s/core/pause:1.2.0`. Be sure to use these versions or newer ones. - If you would like to build your own pause infrastructure container, be sure to include [wincat](https://github.com/kubernetes-sigs/sig-windows-tools/tree/master/cmd/wincat) + これはKubernetes 1.15、およびPauseインフラストラクチャコンテナ`mcr.microsoft.com/k8s/core/pause:1.2.0`で実装されました。必ずこれらのバージョン以降を使用してください。 + 独自のPauseインフラストラクチャコンテナを構築する場合は、必ず[wincat](https://github.com/kubernetes-sigs/sig-windows-tools/tree/master/cmd/wincat)を含めてください。 -### Further investigation +1. Windows Serverノードがプロキシの背後にあるため、Kubernetesのインストールが失敗します -If these steps don't resolve your problem, you can get help running Windows containers on Windows nodes in Kubernetes through: + プロキシの背後にある場合は、次のPowerShell環境変数を定義する必要があります。: + ```PowerShell + [Environment]::SetEnvironmentVariable("HTTP_PROXY", "http://proxy.example.com:80/", [EnvironmentVariableTarget]::Machine) + [Environment]::SetEnvironmentVariable("HTTPS_PROXY", "http://proxy.example.com:443/", [EnvironmentVariableTarget]::Machine) + ``` -* StackOverflow [Windows Server Container](https://stackoverflow.com/questions/tagged/windows-server-container) topic -* Kubernetes Official Forum [discuss.kubernetes.io](https://discuss.kubernetes.io/) +1. `pause`コンテナとは何ですか + + Kubernetes Podでは、インフラストラクチャまたは「pause」コンテナが最初に作成され、コンテナエンドポイントをホストします。インフラストラクチャやワーカーコンテナなど、同じPodに属するコンテナは、共通のネットワークネームスペースとエンドポイント（同じIPとポートスペース）を共有します。Pauseコンテナは、ネットワーク構成を失うことなくクラッシュまたは再起動するワーカーコンテナに対応するために必要です。 + + 「pause」（インフラストラクチャ）イメージは、Microsoft Container Registry（MCR）でホストされています。`docker pull mcr.microsoft.com/k8s/core/pause:1.2.0`を使用してアクセスできます。詳細については、[DOCKERFILE](https://github.com/kubernetes-sigs/sig-windows-tools/tree/master/cmd/wincat)をご覧ください。 + +### さらなる調査 + +これらの手順で問題が解決しない場合は、次の方法で、KubernetesのWindowsノードでWindowsコンテナを実行する際のヘルプを利用できます。: + +* StackOverflow [Windows Server Container](https://stackoverflow.com/questions/tagged/windows-server-container)トピック +* Kubernetesオフィシャルフォーラム [discuss.kubernetes.io](https://discuss.kubernetes.io/) * Kubernetes Slack [#SIG-Windows Channel](https://kubernetes.slack.com/messages/sig-windows) -## Reporting Issues and Feature Requests +## IssueとFeatureリクエストの報告 -If you have what looks like a bug, or you would like to make a feature request, please use the [GitHub issue tracking system](https://github.com/kubernetes/kubernetes/issues). You can open issues on [GitHub](https://github.com/kubernetes/kubernetes/issues/new/choose) and assign them to SIG-Windows. You should first search the list of issues in case it was reported previously and comment with your experience on the issue and add additional logs. SIG-Windows Slack is also a great avenue to get some initial support and troubleshooting ideas prior to creating a ticket. +バグのようなものがある場合、またはFeatureリクエストを行う場合は、[GitHubのIssueシステム](https://github.com/kubernetes/kubernetes/issues)を使用してください。[GitHub](https://github.com/kubernetes/kubernetes/issues/new/choose)でIssueを開いて、SIG-Windowsに割り当てることができます。以前に報告された場合は、まずIssueリストを検索し、Issueについての経験をコメントして、追加のログを加える必要があります。SIG-Windows Slackは、チケットを作成する前に、初期サポートとトラブルシューティングのアイデアを得るための素晴らしい手段でもあります。 -If filing a bug, please include detailed information about how to reproduce the problem, such as: +バグを報告する場合は、問題の再現方法に関する次のような詳細情報を含めてください。: -* Kubernetes version: kubectl version -* Environment details: Cloud provider, OS distro, networking choice and configuration, and Docker version -* Detailed steps to reproduce the problem -* [Relevant logs](https://github.com/kubernetes/community/blob/master/sig-windows/CONTRIBUTING.md#gathering-logs) -* Tag the issue sig/windows by commenting on the issue with `/sig windows` to bring it to a SIG-Windows member's attention +* Kubernetesのバージョン: kubectlのバージョン +* 環境の詳細: クラウドプロバイダー、OSのディストリビューション、選択したネットワーキングと構成、およびDockerのバージョン +* 問題を再現するための詳細な手順 +* [関連するログ](https://github.com/kubernetes/community/blob/master/sig-windows/CONTRIBUTING.md#gathering-logs) +* `/sig windows`でIssueにコメントして、Issueにsig/windowsのタグを付けて、SIG-Windowsメンバーが気付くようにします ## {{% heading "whatsnext" %}} -We have a lot of features in our roadmap. An abbreviated high level list is included below, but we encourage you to view our [roadmap project](https://github.com/orgs/kubernetes/projects/8) and help us make Windows support better by [contributing](https://github.com/kubernetes/community/blob/master/sig-windows/). +ロードマップには多くの機能があります。高レベルの簡略リストを以下に示しますが、[ロードマッププロジェクト](https://github.com/orgs/kubernetes/projects/8)を見て、[貢献すること](https://github.com/kubernetes/community/blob/master/sig-windows/)によってWindowsサポートを改善することをお勧めします。 ### CRI-ContainerD -{{< glossary_tooltip term_id="containerd" >}} is another OCI-compliant runtime that recently graduated as a {{< glossary_tooltip text="CNCF" term_id="cncf" >}} project. It's currently tested on Linux, but 1.3 will bring support for Windows and Hyper-V. [[reference](https://blog.docker.com/2019/02/containerd-graduates-within-the-cncf/)] +{{< glossary_tooltip term_id="containerd" >}}は、最近{{< glossary_tooltip text="CNCF" term_id="cncf" >}}プロジェクトとして卒業した、もう1つのOCI準拠ランタイムです。現在Linuxでテストされていますが、1.3はWindowsとHyper-Vをサポートします。[[リファレンス](https://blog.docker.com/2019/02/containerd-graduates-within-the-cncf/)] -The CRI-ContainerD interface will be able to manage sandboxes based on Hyper-V. This provides a foundation where RuntimeClass could be implemented for new use cases including: +CRI-ContainerDインターフェイスは、Hyper-Vに基づいてサンドボックスを管理できるようになります。これにより、RuntimeClassを次のような新しいユースケースに実装できる基盤が提供されます: -* Hypervisor-based isolation between pods for additional security -* Backwards compatibility allowing a node to run a newer Windows Server version without requiring containers to be rebuilt -* Specific CPU/NUMA settings for a pod -* Memory isolation and reservations +* Pod間のハイパーバイザーベースの分離により、セキュリティを強化 +* 下位互換性により、コンテナの再構築を必要とせずにノードで新しいWindows Serverバージョンを実行 +* Podの特定のCPU/NUMA設定 +* メモリの分離と予約 -### Hyper-V isolation +### Hyper-V分離 -The existing Hyper-V isolation support, an experimental feature as of v1.10, will be deprecated in the future in favor of the CRI-ContainerD and RuntimeClass features mentioned above. To use the current features and create a Hyper-V isolated container, the kubelet should be started with feature gates `HyperVContainer=true` and the Pod should include the annotation `experimental.windows.kubernetes.io/isolation-type=hyperv`. In the experiemental release, this feature is limited to 1 container per Pod. +既存のHyper-V分離サポートは、v1.10の試験的な機能であり、上記のCRI-ContainerD機能とRuntimeClass機能を優先して将来廃止される予定です。現在の機能を使用してHyper-V分離コンテナを作成するには、kubeletのフィーチャーゲートを`HyperVContainer=true`で開始し、Podにアノテーション`experimental.windows.kubernetes.io/isolation-type=hyperv`を含める必要があります。実験的リリースでは、この機能はPodごとに1つのコンテナに制限されています。 ```yaml apiVersion: apps/v1 @@ -576,13 +607,11 @@ spec: - containerPort: 80 ``` -### Deployment with kubeadm and cluster API - -Kubeadm is becoming the de facto standard for users to deploy a Kubernetes cluster. Windows node support in kubeadm will come in a future release. We are also making investments in cluster API to ensure Windows nodes are properly provisioned. - -### A few other key features -* Beta support for Group Managed Service Accounts -* More CNIs -* More Storage Plugins +### kubeadmとクラスターAPIを使用したデプロイ +Kubeadmは、ユーザーがKubernetesクラスターをデプロイするための事実上の標準になりつつあります。kubeadmのWindowsノードのサポートは、将来のリリースで提供予定です。Windowsノードが適切にプロビジョニングされるように、クラスターAPIにも投資しています。 +### その他の主な機能 +* グループ管理サービスアカウントのベータサポート +* その他のCNI +* その他のストレージプラグイン diff --git a/content/ja/docs/setup/production-environment/windows/kubecluster.ps1-install.gif b/content/ja/docs/setup/production-environment/windows/kubecluster.ps1-install.gif new file mode 100644 index 0000000000..e3d94b9b54 Binary files /dev/null and b/content/ja/docs/setup/production-environment/windows/kubecluster.ps1-install.gif differ diff --git a/content/ja/docs/setup/production-environment/windows/kubecluster.ps1-join.gif b/content/ja/docs/setup/production-environment/windows/kubecluster.ps1-join.gif new file mode 100644 index 0000000000..828417d685 Binary files /dev/null and b/content/ja/docs/setup/production-environment/windows/kubecluster.ps1-join.gif differ diff --git a/content/ja/docs/setup/production-environment/windows/kubecluster.ps1-reset.gif b/content/ja/docs/setup/production-environment/windows/kubecluster.ps1-reset.gif new file mode 100644 index 0000000000..e71d40d6df Binary files /dev/null and b/content/ja/docs/setup/production-environment/windows/kubecluster.ps1-reset.gif differ diff --git a/content/ja/docs/setup/production-environment/windows/user-guide-windows-containers.md b/content/ja/docs/setup/production-environment/windows/user-guide-windows-containers.md index 24d61e8bbd..ee1ed7b9f1 100644 --- a/content/ja/docs/setup/production-environment/windows/user-guide-windows-containers.md +++ b/content/ja/docs/setup/production-environment/windows/user-guide-windows-containers.md @@ -27,44 +27,47 @@ Windows applications constitute a large portion of the services and applications To deploy a Windows container on Kubernetes, you must first create an example application. The example YAML file below creates a simple webserver application. Create a service spec named `win-webserver.yaml` with the contents below: ```yaml - apiVersion: v1 - kind: Service - metadata: - name: win-webserver - labels: - app: win-webserver - spec: - ports: - # the port that this service should serve on - - port: 80 - targetPort: 80 - selector: - app: win-webserver - type: NodePort - --- - apiVersion: extensions/v1beta1 - kind: Deployment +apiVersion: v1 +kind: Service +metadata: + name: win-webserver + labels: + app: win-webserver +spec: + ports: + # the port that this service should serve on + - port: 80 + targetPort: 80 + selector: + app: win-webserver + type: NodePort +--- +apiVersion: apps/v1 +kind: Deployment +metadata: + labels: + app: win-webserver + name: win-webserver +spec: + replicas: 2 + selector: + matchLabels: + app: win-webserver + template: metadata: labels: app: win-webserver name: win-webserver spec: - replicas: 2 - template: - metadata: - labels: - app: win-webserver - name: win-webserver - spec: - containers: - - name: windowswebserver - image: mcr.microsoft.com/windows/servercore:ltsc2019 - command: + containers: + - name: windowswebserver + image: mcr.microsoft.com/windows/servercore:ltsc2019 + command: - powershell.exe - -command - - "<#code used from https://gist.github.com/wagnerandrade/5424431#> ; $$listener = New-Object System.Net.HttpListener ; $$listener.Prefixes.Add('http://*:80/') ; $$listener.Start() ; $$callerCounts = @{} ; Write-Host('Listening at http://*:80/') ; while ($$listener.IsListening) { ;$$context = $$listener.GetContext() ;$$requestUrl = $$context.Request.Url ;$$clientIP = $$context.Request.RemoteEndPoint.Address ;$$response = $$context.Response ;Write-Host '' ;Write-Host('> {0}' -f $$requestUrl) ; ;$$count = 1 ;$$k=$$callerCounts.Get_Item($$clientIP) ;if ($$k -ne $$null) { $$count += $$k } ;$$callerCounts.Set_Item($$clientIP, $$count) ;$$ip=(Get-NetAdapter | Get-NetIpAddress); $$header='<html><body><H1>Windows Container Web Server</H1>' ;$$callerCountsString='' ;$$callerCounts.Keys | % { $$callerCountsString+='<p>IP {0} callerCount {1} ' -f $$ip[1].IPAddress,$$callerCounts.Item($$_) } ;$$footer='</body></html>' ;$$content='{0}{1}{2}' -f $$header,$$callerCountsString,$$footer ;Write-Output $$content ;$$buffer = [System.Text.Encoding]::UTF8.GetBytes($$content) ;$$response.ContentLength64 = $$buffer.Length ;$$response.OutputStream.Write($$buffer, 0, $$buffer.Length) ;$$response.Close() ;$$responseStatus = $$response.StatusCode ;Write-Host('< {0}' -f $$responseStatus) } ; " - nodeSelector: - kubernetes.io/os: windows + - "<#code used from https://gist.github.com/wagnerandrade/5424431#> ; $$listener = New-Object System.Net.HttpListener ; $$listener.Prefixes.Add('http://*:80/') ; $$listener.Start() ; $$callerCounts = @{} ; Write-Host('Listening at http://*:80/') ; while ($$listener.IsListening) { ;$$context = $$listener.GetContext() ;$$requestUrl = $$context.Request.Url ;$$clientIP = $$context.Request.RemoteEndPoint.Address ;$$response = $$context.Response ;Write-Host '' ;Write-Host('> {0}' -f $$requestUrl) ; ;$$count = 1 ;$$k=$$callerCounts.Get_Item($$clientIP) ;if ($$k -ne $$null) { $$count = $$k } ;$$callerCounts.Set_Item($$clientIP, $$count) ;$$ip=(Get-NetAdapter | Get-NetIpAddress); $$header='<html><body><H1>Windows Container Web Server</H1>' ;$$callerCountsString='' ;$$callerCounts.Keys | % { $$callerCountsString='<p>IP {0} callerCount {1} ' -f $$ip[1].IPAddress,$$callerCounts.Item($$_) } ;$$footer='</body></html>' ;$$content='{0}{1}{2}' -f $$header,$$callerCountsString,$$footer ;Write-Output $$content ;$$buffer = [System.Text.Encoding]::UTF8.GetBytes($$content) ;$$response.ContentLength64 = $$buffer.Length ;$$response.OutputStream.Write($$buffer, 0, $$buffer.Length) ;$$response.Close() ;$$responseStatus = $$response.StatusCode ;Write-Host('< {0}' -f $$responseStatus) } ; " + nodeSelector: + kubernetes.io/os: windows ``` {{< note >}} @@ -101,6 +104,18 @@ Port mapping is also supported, but for simplicity in this example the container Windows container hosts are not able to access the IP of services scheduled on them due to current platform limitations of the Windows networking stack. Only Windows pods are able to access service IPs. {{< /note >}} +## Observability + +### Capturing logs from workloads + +Logs are an important element of observability; they enable users to gain insights into the operational aspect of workloads and are a key ingredient to troubleshooting issues. Because Windows containers and workloads inside Windows containers behave differently from Linux containers, users had a hard time collecting logs, limiting operational visibility. Windows workloads for example are usually configured to log to ETW (Event Tracing for Windows) or push entries to the application event log. [LogMonitor](https://github.com/microsoft/windows-container-tools/tree/master/LogMonitor), an open source tool by Microsoft, is the recommended way to monitor configured log sources inside a Windows container. LogMonitor supports monitoring event logs, ETW providers, and custom application logs, piping them to STDOUT for consumption by `kubectl logs <pod>`. + +Follow the instructions in the LogMonitor GitHub page to copy its binaries and configuration files to all your containers and add the necessary entrypoints for LogMonitor to push your logs to STDOUT. + +## Using configurable Container usernames + +Starting with Kubernetes v1.16, Windows containers can be configured to run their entrypoints and processes with different usernames than the image defaults. The way this is achieved is a bit different from the way it is done for Linux containers. Learn more about it [here](/docs/tasks/configure-pod-container/configure-runasusername/). + ## Managing Workload Identity with Group Managed Service Accounts Starting with Kubernetes v1.14, Windows container workloads can be configured to use Group Managed Service Accounts (GMSA). Group Managed Service Accounts are a specific type of Active Directory account that provides automatic password management, simplified service principal name (SPN) management, and the ability to delegate the management to other administrators across multiple servers. Containers configured with a GMSA can access external Active Directory Domain resources while carrying the identity configured with the GMSA. Learn more about configuring and using GMSA for Windows containers [here](/docs/tasks/configure-pod-container/configure-gmsa/). @@ -116,22 +131,114 @@ Users can ensure Windows containers can be scheduled on the appropriate host usi * kubernetes.io/os = [windows|linux] * kubernetes.io/arch = [amd64|arm64|...] -If a Pod specification does not specify a nodeSelector like `"beta.kubernetes.io/os": windows`, it is possible the Pod can be scheduled on any host, Windows or Linux. This can be problematic since a Windows container can only run on Windows and a Linux container can only run on Linux. The best practice is to use a nodeSelector. +If a Pod specification does not specify a nodeSelector like `"kubernetes.io/os": windows`, it is possible the Pod can be scheduled on any host, Windows or Linux. This can be problematic since a Windows container can only run on Windows and a Linux container can only run on Linux. The best practice is to use a nodeSelector. However, we understand that in many cases users have a pre-existing large number of deployments for Linux containers, as well as an ecosystem of off-the-shelf configurations, such as community Helm charts, and programmatic Pod generation cases, such as with Operators. In those situations, you may be hesitant to make the configuration change to add nodeSelectors. The alternative is to use Taints. Because the kubelet can set Taints during registration, it could easily be modified to automatically add a taint when running on Windows only. -For example: `--register-with-taints='os=Win1809:NoSchedule'` +For example: `--register-with-taints='os=windows:NoSchedule'` By adding a taint to all Windows nodes, nothing will be scheduled on them (that includes existing Linux Pods). In order for a Windows Pod to be scheduled on a Windows node, it would need both the nodeSelector to choose Windows, and the appropriate matching toleration. ```yaml nodeSelector: - "beta.kubernetes.io/os": windows + kubernetes.io/os: windows + node.kubernetes.io/windows-build: '10.0.17763' tolerations: - key: "os" operator: "Equal" - value: "Win1809" + value: "windows" effect: "NoSchedule" ``` +### Handling multiple Windows versions in the same cluster +The Windows Server version used by each pod must match that of the node. If you want to use multiple Windows +Server versions in the same cluster, then you should set additional node labels and nodeSelectors. + +Kubernetes 1.17 automatically adds a new label `node.kubernetes.io/windows-build` to simplify this. If you're running an older version, then it's recommended to add this label manually to Windows nodes. + +This label reflects the Windows major, minor, and build number that need to match for compatibility. Here are values used today for each Windows Server version. + +| Product Name | Build Number(s) | +|--------------------------------------|------------------------| +| Windows Server 2019 | 10.0.17763 | +| Windows Server version 1809 | 10.0.17763 | +| Windows Server version 1903 | 10.0.18362 | + + +### Simplifying with RuntimeClass + +[RuntimeClass] can be used to simplify the process of using taints and tolerations. A cluster administrator can create a `RuntimeClass` object which is used to encapsulate these taints and tolerations. + + +1. Save this file to `runtimeClasses.yml`. It includes the appropriate `nodeSelector` for the Windows OS, architecture, and version. + +```yaml +apiVersion: node.k8s.io/v1beta1 +kind: RuntimeClass +metadata: + name: windows-2019 +handler: 'docker' +scheduling: + nodeSelector: + kubernetes.io/os: 'windows' + kubernetes.io/arch: 'amd64' + node.kubernetes.io/windows-build: '10.0.17763' + tolerations: + - effect: NoSchedule + key: os + operator: Equal + value: "windows" +``` + +1. Run `kubectl create -f runtimeClasses.yml` using as a cluster administrator +1. Add `runtimeClassName: windows-2019` as appropriate to Pod specs + +For example: + +```yaml +apiVersion: apps/v1 +kind: Deployment +metadata: + name: iis-2019 + labels: + app: iis-2019 +spec: + replicas: 1 + template: + metadata: + name: iis-2019 + labels: + app: iis-2019 + spec: + runtimeClassName: windows-2019 + containers: + - name: iis + image: mcr.microsoft.com/windows/servercore/iis:windowsservercore-ltsc2019 + resources: + limits: + cpu: 1 + memory: 800Mi + requests: + cpu: .1 + memory: 300Mi + ports: + - containerPort: 80 + selector: + matchLabels: + app: iis-2019 +--- +apiVersion: v1 +kind: Service +metadata: + name: iis +spec: + type: LoadBalancer + ports: + - protocol: TCP + port: 80 + selector: + app: iis-2019 +``` + +[RuntimeClass]: https://kubernetes.io/docs/concepts/containers/runtime-class/ \ No newline at end of file diff --git a/content/ja/docs/setup/production-environment/windows/user-guide-windows-nodes.md b/content/ja/docs/setup/production-environment/windows/user-guide-windows-nodes.md index 29035e15d9..6edce770c1 100644 --- a/content/ja/docs/setup/production-environment/windows/user-guide-windows-nodes.md +++ b/content/ja/docs/setup/production-environment/windows/user-guide-windows-nodes.md @@ -91,9 +91,9 @@ Once you have a Linux-based Kubernetes master node you are ready to choose a net 1. In the `net-conf.json` section of your `kube-flannel.yml`, double-check: 1. The cluster subnet (e.g. "10.244.0.0/16") is set as per your IP plan. - * VNI 4096 is set in the backend - * Port 4789 is set in the backend - 2. In the `cni-conf.json` section of your `kube-flannel.yml`, change the network name to `vxlan0`. + * VNI 4096 is set in the backend + * Port 4789 is set in the backend + 1. In the `cni-conf.json` section of your `kube-flannel.yml`, change the network name to `vxlan0`. Your `cni-conf.json` should look as follows: @@ -134,7 +134,18 @@ Once you have a Linux-based Kubernetes master node you are ready to choose a net kubectl get pods --all-namespaces ``` - ![alt_text](../flannel-master-kubeclt-get-pods.png "flannel master kubectl get pods screen capture") + The output looks like as follows: + + ``` + NAMESPACE NAME READY STATUS RESTARTS AGE + kube-system etcd-flannel-master 1/1 Running 0 1m + kube-system kube-apiserver-flannel-master 1/1 Running 0 1m + kube-system kube-controller-manager-flannel-master 1/1 Running 0 1m + kube-system kube-dns-86f4d74b45-hcx8x 3/3 Running 0 12m + kube-system kube-flannel-ds-54954 1/1 Running 0 1m + kube-system kube-proxy-Zjlxz 1/1 Running 0 1m + kube-system kube-scheduler-flannel-master 1/1 Running 0 1m + ``` Verify that the Flannel DaemonSet has the NodeSelector applied. @@ -142,13 +153,20 @@ Once you have a Linux-based Kubernetes master node you are ready to choose a net kubectl get ds -n kube-system ``` - ![alt_text](../flannel-master-kubectl-get-ds.png "flannel master kubectl get ds screen capture") + The output looks like as follows. The NodeSelector `beta.kubernetes.io/os=linux` is applied. + + ``` + NAME DESIRED CURRENT READY UP-TO-DATE AVAILABLE NODE SELECTOR AGE + kube-flannel-ds 2 2 2 2 2 beta.kubernetes.io/arch=amd64,beta.kubernetes.io/os=linux 21d + kube-proxy 2 2 2 2 2 beta.kubernetes.io/os=linux 26d + ``` #### Join Windows Worker In this section we'll cover configuring a Windows node from scratch to join a cluster on-prem. If your cluster is on a cloud you'll likely want to follow the cloud specific guides in the next section. #### Preparing a Windows Node + {{< note >}} All code snippets in Windows sections are to be run in a PowerShell environment with elevated permissions (Admin). {{< /note >}} @@ -171,9 +189,28 @@ All code snippets in Windows sections are to be run in a PowerShell environment [Environment]::SetEnvironmentVariable("HTTPS_PROXY", "http://proxy.example.com:443/", [EnvironmentVariableTarget]::Machine) ``` - If after reboot you see the following error, you need to restart the docker service manually + After reboot, you can verify that the docker service is ready with the command below. - ![alt_text](../windows-docker-error.png "windows docker error screen capture") + ```PowerShell + docker version + ``` + + If you see error message like the following, you need to start the docker service manually. + + ``` + Client: + Version: 17.06.2-ee-11 + API version: 1.30 + Go version: go1.8.7 + Git commit: 06fc007 + Built: Thu May 17 06:14:39 2018 + OS/Arch: windows / amd64 + error during connect: Get http://%2F%2F.%2Fpipe%2Fdocker_engine/v1.30/version: open //./pipe/docker_engine: The system c + annot find the file specified. In the default daemon configuration on Windows, the docker client must be run elevated to + connect. This error may also indicate that the docker daemon is not running. + ``` + + You can start the docker service manually like below. ```PowerShell Start-Service docker @@ -220,7 +257,13 @@ wget https://raw.githubusercontent.com/Microsoft/SDN/master/Kubernetes/flannel/s {{< /note >}} ```PowerShell -.\start.ps1 -ManagementIP <Windows Node IP> -NetworkMode overlay -ClusterCIDR <Cluster CIDR> -ServiceCIDR <Service CIDR> -KubeDnsServiceIP <Kube-dns Service IP> -LogDir <Log directory> +cd c:\k +.\start.ps1 -ManagementIP <Windows Node IP> ` + -NetworkMode overlay ` + -ClusterCIDR <Cluster CIDR> ` + -ServiceCIDR <Service CIDR> ` + -KubeDnsServiceIP <Kube-dns Service IP> ` + -LogDir <Log directory> ``` | Parameter | Default Value | Notes | @@ -261,4 +304,3 @@ Kubeadm is becoming the de facto standard for users to deploy a Kubernetes clust Now that you've configured a Windows worker in your cluster to run Windows containers you may want to add one or more Linux nodes as well to run Linux containers. You are now ready to schedule Windows containers on your cluster. - diff --git a/content/ja/docs/setup/production-environment/windows/windows-docker-error.png b/content/ja/docs/setup/production-environment/windows/windows-docker-error.png deleted file mode 100644 index d00528c0d4..0000000000 Binary files a/content/ja/docs/setup/production-environment/windows/windows-docker-error.png and /dev/null differ diff --git a/content/ja/docs/setup/release/_index.md b/content/ja/docs/setup/release/_index.md index e930b48a08..8c812f72de 100755 --- a/content/ja/docs/setup/release/_index.md +++ b/content/ja/docs/setup/release/_index.md @@ -1,4 +1,4 @@ --- -title: "リリースノート及びバージョンスキュー" +title: "リリースノートおよびバージョンスキュー" weight: 10 --- diff --git a/content/ja/docs/setup/release/building-from-source.md b/content/ja/docs/setup/release/building-from-source.md deleted file mode 100644 index 21f056ce39..0000000000 --- a/content/ja/docs/setup/release/building-from-source.md +++ /dev/null @@ -1,30 +0,0 @@ ---- -title: リリースのビルド -content_type: concept -card: - name: download - weight: 20 - title: リリースのビルド ---- -<!-- overview --> -ソースコードからリリースをビルドすることもできますし、既にビルドされたリリースをダウンロードすることも可能です。Kubernetesを開発する予定が無いのであれば、[リリースノート](/docs/setup/release/notes/)内にて既にビルドされたバージョンを使用することを推奨します。 - -Kubernetes のソースコードは[kubernetes/kubernetes](https://github.com/kubernetes/kubernetes)のリポジトリからダウンロードすることが可能です。 - - -<!-- body --> -## ソースからのビルド - -単にソースからリリースをビルドするだけであれば、完全なGOの環境を準備する必要はなく、全てのビルドはDockerコンテナの中で行われます。 - -リリースをビルドすることは簡単です。 - -```shell -git clone https://github.com/kubernetes/kubernetes.git -cd kubernetes -make release -``` - -リリース手段の詳細な情報はkubernetes/kubernetes内の[`build`](http://releases.k8s.io/{{< param "githubbranch" >}}/build/)ディレクトリを参照して下さい。 - - diff --git a/content/ja/docs/setup/release/version-skew-policy.md b/content/ja/docs/setup/release/version-skew-policy.md index 19200d80a6..5c1a18b8ee 100644 --- a/content/ja/docs/setup/release/version-skew-policy.md +++ b/content/ja/docs/setup/release/version-skew-policy.md @@ -5,7 +5,7 @@ weight: 30 --- <!-- overview --> -このドキュメントでは、さまざまなKubernetesコンポーネント間でサポートされる最大のバージョンの差異（バージョンスキュー）について説明します。特定のクラスターデプロイツールは、バージョンの差異に追加の制限を加える場合があります。 +このドキュメントでは、さまざまなKubernetesコンポーネント間でサポートされる最大のバージョンの差異(バージョンスキュー)について説明します。特定のクラスターデプロイツールは、バージョンの差異に追加の制限を加える場合があります。 <!-- body --> @@ -16,9 +16,10 @@ Kubernetesのバージョンは**x.y.z**の形式で表現され、**x**はメ Kubernetesプロジェクトでは、最新の3つのマイナーリリースについてリリースブランチを管理しています。 -セキュリティフィックスを含む適用可能な修正は、重大度や実行可能性によってはこれら3つのリリースブランチにバックポートされることもあります。パッチリリースは、[定期的](https://git.k8s.io/sig-release/releases/patch-releases.md#cadence)または必要に応じてこれらのブランチから分岐されます。[リリースマネージャー](https://git.k8s.io/sig-release/release-managers.md)グループがこれを決定しています。 +セキュリティフィックスを含む適用可能な修正は、重大度や実行可能性によってはこれら3つのリリースブランチにバックポートされることもあります。パッチリリースは、定期的または必要に応じてこれらのブランチから分岐されます。[パッチリリースチーム](https://github.com/kubernetes/sig-release/blob/master/release-engineering/role-handbooks/patch-release-team.md#release-timing)がこれを決定しています。パッチリリースチームは[リリースマネージャー](https://github.com/kubernetes/sig-release/blob/master/release-managers.md)の一部です。 +詳細は、[Kubernetesパッチリリース](https://github.com/kubernetes/sig-release/blob/master/releases/patch-releases.md)ページを参照してください。 -詳細は、Kubernetes[パッチリリース](https://git.k8s.io/sig-release/releases/patch-releases.md)ページを参照してください。 +マイナーリリースは約3ヶ月ごとに行われるため、マイナーリリースのブランチはそれぞれ約9ヶ月保守されます。 ## サポートされるバージョンの差異 @@ -51,7 +52,7 @@ HAクラスター内の`kube-apiserver`間にバージョンの差異がある ### kube-controller-manager、kube-scheduler、およびcloud-controller-manager -`kube-controller-manager`、`kube-scheduler`および`cloud-controller-manager`は、通信する`kube-apiserver`インスタンスよりも新しいバージョンであってはなりません。`kube-apiserver`のマイナーバージョンと一致することが期待されますが、1つ古いマイナーバージョンでも可能です（ライブアップグレードを可能にするため）。 +`kube-controller-manager`、`kube-scheduler`および`cloud-controller-manager`は、通信する`kube-apiserver`インスタンスよりも新しいバージョンであってはなりません。`kube-apiserver`のマイナーバージョンと一致することが期待されますが、1つ古いマイナーバージョンでも可能です(ライブアップグレードを可能にするため)。 例: @@ -59,17 +60,17 @@ HAクラスター内の`kube-apiserver`間にバージョンの差異がある * `kube-controller-manager`、`kube-scheduler`および`cloud-controller-manager`は**1.13**および**1.12**がサポートされます {{< note >}} -HAクラスター内の`kube-apiserver`間にバージョンの差異があり、これらのコンポーネントがクラスター内のいずれかの`kube-apiserver`と通信する場合（たとえばロードバランサーを経由して）、コンポーネントの有効なバージョンは少なくなります。 +HAクラスター内の`kube-apiserver`間にバージョンの差異があり、これらのコンポーネントがクラスター内のいずれかの`kube-apiserver`と通信する場合(たとえばロードバランサーを経由して)、コンポーネントの有効なバージョンは少なくなります。 {{< /note >}} 例: * `kube-apiserver`インスタンスが**1.13**および**1.12**であるとします -* いずれかの`kube-apiserver`インスタンスへ配信するロードバランサーと通信する`kube-controller-manager`、`kube-scheduler`および`cloud-controller-manager`は**1.12**がサポートされます（**1.13**はバージョン**1.12**の`kube-apiserver`よりも新しくなるためサポートされません） +* いずれかの`kube-apiserver`インスタンスへ配信するロードバランサーと通信する`kube-controller-manager`、`kube-scheduler`および`cloud-controller-manager`は**1.12**がサポートされます(**1.13**はバージョン**1.12**の`kube-apiserver`よりも新しくなるためサポートされません) ### kubectl -`kubectl`は`kube-apiserver`の1つ以内のバージョン（古い、または新しいもの）をサポートします。 +`kubectl`は`kube-apiserver`の1つ以内のバージョン(古い、または新しいもの)をサポートします。 例: @@ -83,25 +84,25 @@ HAクラスター内の`kube-apiserver`間にバージョンの差異がある 例: * `kube-apiserver`インスタンスが**1.13**および**1.12**であるとします -* `kubectl`は**1.13**および**1.12**がサポートされます（ほかのバージョンでは、ある`kube-apiserver`コンポーネントからマイナーバージョンが2つ以上離れる可能性があります） +* `kubectl`は**1.13**および**1.12**がサポートされます(ほかのバージョンでは、ある`kube-apiserver`コンポーネントからマイナーバージョンが2つ以上離れる可能性があります) ## サポートされるコンポーネントのアップグレード順序 -コンポーネント間でサポートされるバージョンの差異は、コンポーネントをアップグレードする順序に影響されます。このセクションでは、既存のクラスターをバージョン**1.n**から**1.(n+1)**へ移行するために、コンポーネントをアップグレードする順序を説明します。 +コンポーネント間でサポートされるバージョンの差異は、コンポーネントをアップグレードする順序に影響されます。このセクションでは、既存のクラスターをバージョン**1.n**から**1.(n+1)** へ移行するために、コンポーネントをアップグレードする順序を説明します。 ### kube-apiserver 前提条件: * シングルインスタンスのクラスターにおいて、既存の`kube-apiserver`インスタンスは**1.n**とします -* HAクラスターにおいて、既存の`kube-apiserver`は**1.n**または**1.(n+1)**とします（最新と最古の間で、最大で1つのマイナーバージョンの差異となります） -* サーバーと通信する`kube-controller-manager`、`kube-scheduler`および`cloud-controller-manager`はバージョン**1.n**とします（必ず既存のAPIサーバーのバージョンよりも新しいものでなく、かつ新しいAPIサーバーのバージョンの1つ以内のマイナーバージョンとなります） -* すべてのノードの`kubelet`インスタンスはバージョン**1.n**または**1.(n-1)**とします（必ず既存のAPIサーバーよりも新しいバージョンでなく、かつ新しいAPIサーバーのバージョンの2つ以内のマイナーバージョンとなります） +* HAクラスターにおいて、既存の`kube-apiserver`は**1.n**または**1.(n+1)** とします(最新と最古の間で、最大で1つのマイナーバージョンの差異となります) +* サーバーと通信する`kube-controller-manager`、`kube-scheduler`および`cloud-controller-manager`はバージョン**1.n**とします(必ず既存のAPIサーバーのバージョンよりも新しいものでなく、かつ新しいAPIサーバーのバージョンの1つ以内のマイナーバージョンとなります) +* すべてのノードの`kubelet`インスタンスはバージョン**1.n**または**1.(n-1)** とします(必ず既存のAPIサーバーよりも新しいバージョンでなく、かつ新しいAPIサーバーのバージョンの2つ以内のマイナーバージョンとなります) * 登録されたAdmission webhookは、新しい`kube-apiserver`インスタンスが送信するこれらのデータを扱うことができます: - * `ValidatingWebhookConfiguration`および`MutatingWebhookConfiguration`オブジェクトは、**1.(n+1)**で追加されたRESTリソースの新しいバージョンを含んで更新されます（または、v1.15から利用可能な[`matchPolicy: Equivalent`オプション](/docs/reference/access-authn-authz/extensible-admission-controllers/#matching-requests-matchpolicy)を使用してください） - * Webhookは送信されたRESTリソースの新しいバージョン、および**1.(n+1)**のバージョンで追加された新しいフィールドを扱うことができます + * `ValidatingWebhookConfiguration`および`MutatingWebhookConfiguration`オブジェクトは、**1.(n+1)** で追加されたRESTリソースの新しいバージョンを含んで更新されます(または、v1.15から利用可能な[`matchPolicy: Equivalent`オプション](/docs/reference/access-authn-authz/extensible-admission-controllers/#matching-requests-matchpolicy)を使用してください) + * Webhookは送信されたRESTリソースの新しいバージョン、および**1.(n+1)** のバージョンで追加された新しいフィールドを扱うことができます -`kube-apiserver`を**1.(n+1)**にアップグレードしてください。 +`kube-apiserver`を**1.(n+1)** にアップグレードしてください。 {{< note >}} [非推奨API](/docs/reference/using-api/deprecation-policy/)および[APIの変更ガイドライン](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-architecture/api_changes.md)のプロジェクトポリシーにおいては、シングルインスタンスの場合でも`kube-apiserver`のアップグレードの際にマイナーバージョンをスキップしてはなりません。 @@ -111,17 +112,17 @@ HAクラスター内の`kube-apiserver`間にバージョンの差異がある 前提条件: -* これらのコンポーネントと通信する`kube-apiserver`インスタンスが**1.(n+1)**であること（これらのコントロールプレーンコンポーネントが、クラスター内の`kube-apiserver`インスタンスと通信できるHAクラスターでは、これらのコンポーネントをアップグレードする前にすべての`kube-apiserver`インスタンスをアップグレードしなければなりません） +* これらのコンポーネントと通信する`kube-apiserver`インスタンスが**1.(n+1)** であること(これらのコントロールプレーンコンポーネントが、クラスター内の`kube-apiserver`インスタンスと通信できるHAクラスターでは、これらのコンポーネントをアップグレードする前にすべての`kube-apiserver`インスタンスをアップグレードしなければなりません) -`kube-controller-manager`、`kube-scheduler`および`cloud-controller-manager`を**1.(n+1)**にアップグレードしてください。 +`kube-controller-manager`、`kube-scheduler`および`cloud-controller-manager`を**1.(n+1)** にアップグレードしてください。 ### kubelet 前提条件: -* `kubelet`と通信する`kube-apiserver`が**1.(n+1)**であること +* `kubelet`と通信する`kube-apiserver`が**1.(n+1)** であること -必要に応じて、`kubelet`インスタンスを**1.(n+1)**にアップグレードしてください（**1.n**や**1.(n-1)**のままにすることもできます）。 +必要に応じて、`kubelet`インスタンスを**1.(n+1)** にアップグレードしてください(**1.n**や**1.(n-1)** のままにすることもできます)。 {{< warning >}} `kube-apiserver`と2つのマイナーバージョンの`kubelet`インスタンスを使用してクラスターを実行させることは推奨されません: diff --git a/content/ja/docs/tasks/access-application-cluster/ingress-minikube.md b/content/ja/docs/tasks/access-application-cluster/ingress-minikube.md new file mode 100644 index 0000000000..563ce2478e --- /dev/null +++ b/content/ja/docs/tasks/access-application-cluster/ingress-minikube.md @@ -0,0 +1,305 @@ +--- +title: Minikube上でNGINX Ingressコントローラーを使用してIngressをセットアップする +content_type: task +weight: 100 +--- + +<!-- overview --> + +[Ingress](/ja/docs/concepts/services-networking/ingress/)とは、クラスター内のServiceに外部からのアクセスを許可するルールを定義するAPIオブジェクトです。[Ingressコントローラー](/ja/docs/concepts/services-networking/ingress-controllers/)はIngress内に設定されたルールを満たすように動作します。 + +このページでは、簡単なIngressをセットアップして、HTTPのURIに応じてwebまたはweb2というServiceにリクエストをルーティングする方法を説明します。 + + + +## {{% heading "prerequisites" %}} + + +{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}} + + + +<!-- steps --> + +## Minikubeクラスターを作成する + +1. **Launch Terminal**をクリックします。 + + {{< kat-button >}} + +1. (オプション) Minikubeをローカル環境にインストールした場合は、次のコマンドを実行します。 + + ```shell + minikube start + ``` + +## Ingressコントローラーを有効化する + +1. NGINX Ingressコントローラーを有効にするために、次のコマンドを実行します。 + + ```shell + minikube addons enable ingress + ``` + +1. NGINX Ingressコントローラーが起動したことを確認します。 + + ```shell + kubectl get pods -n kube-system + ``` + + {{< note >}} + このコマンドの実行には数分かかる場合があります。 + {{< /note >}} + + 出力は次のようになります。 + + ```shell + NAME READY STATUS RESTARTS AGE + default-http-backend-59868b7dd6-xb8tq 1/1 Running 0 1m + kube-addon-manager-minikube 1/1 Running 0 3m + kube-dns-6dcb57bcc8-n4xd4 3/3 Running 0 2m + kubernetes-dashboard-5498ccf677-b8p5h 1/1 Running 0 2m + nginx-ingress-controller-5984b97644-rnkrg 1/1 Running 0 1m + storage-provisioner 1/1 Running 0 2m + ``` + +## Hello Worldアプリをデプロイする + +1. 次のコマンドを実行して、Deploymentを作成します。 + + ```shell + kubectl create deployment web --image=gcr.io/google-samples/hello-app:1.0 + ``` + + 出力は次のようになります。 + + ```shell + deployment.apps/web created + ``` + +1. Deploymentを公開します。 + + ```shell + kubectl expose deployment web --type=NodePort --port=8080 + ``` + + 出力は次のようになります。 + + ```shell + service/web exposed + ``` + +1. Serviceが作成され、NodePort上で利用できるようになったことを確認します。 + + ```shell + kubectl get service web + ``` + + 出力は次のようになります。 + + ```shell + NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE + web NodePort 10.104.133.249 <none> 8080:31637/TCP 12m + ``` + +1. NodePort経由でServiceを訪問します。 + + ```shell + minikube service web --url + ``` + + 出力は次のようになります。 + + ```shell + http://172.17.0.15:31637 + ``` + + {{< note >}} + Katacoda環境の場合のみ: 上部のterminalパネルでプラスのアイコンをクリックして、**Select port to view on Host 1**(Host 1を表示するポートを選択)をクリックします。NodePort(上の例では`31637`)を入力して、**Display Port**(ポートを表示)をクリックしてください。 + {{< /note >}} + + 出力は次のようになります。 + + ```shell + Hello, world! + Version: 1.0.0 + Hostname: web-55b8c6998d-8k564 + ``` + + これで、MinikubeのIPアドレスとNodePort経由で、サンプルアプリにアクセスできるようになりました。次のステップでは、Ingressリソースを使用してアプリにアクセスできるように設定します。 + +## Ingressリソースを作成する + +以下に示すファイルは、hello-world.info経由で送られたトラフィックをServiceに送信するIngressリソースです。 + +1. 以下の内容で`example-ingress.yaml`を作成します。 + + ```yaml + apiVersion: networking.k8s.io/v1beta1 + kind: Ingress + metadata: + name: example-ingress + annotations: + nginx.ingress.kubernetes.io/rewrite-target: /$1 + spec: + rules: + - host: hello-world.info + http: + paths: + - path: / + backend: + serviceName: web + servicePort: 8080 + ``` + +1. 次のコマンドを実行して、Ingressリソースを作成します。 + + ```shell + kubectl apply -f example-ingress.yaml + ``` + + 出力は次のようになります。 + + ```shell + ingress.networking.k8s.io/example-ingress created + ``` + +1. 次のコマンドで、IPアドレスが設定されていることを確認します。 + + ```shell + kubectl get ingress + ``` + + {{< note >}} + このコマンドの実行には数分かかる場合があります。 + {{< /note >}} + + ```shell + NAME HOSTS ADDRESS PORTS AGE + example-ingress hello-world.info 172.17.0.15 80 38s + ``` + +1. 次の行を`/etc/hosts`ファイルの最後に書きます。 + + {{< note >}} + Minikubeをローカル環境で実行している場合、`minikube ip`コマンドを使用すると外部のIPが取得できます。Ingressのリスト内に表示されるIPアドレスは、内部のIPになるはずです。 + {{< /note >}} + + ``` + 172.17.0.15 hello-world.info + ``` + + この設定により、リクエストがhello-world.infoからMinikubeに送信されるようになります。 + +1. Ingressコントローラーがトラフィックを制御していることを確認します。 + + ```shell + curl hello-world.info + ``` + + 出力は次のようになります。 + + ```shell + Hello, world! + Version: 1.0.0 + Hostname: web-55b8c6998d-8k564 + ``` + + {{< note >}} + Minikubeをローカル環境で実行している場合、ブラウザからhello-world.infoにアクセスできます。 + {{< /note >}} + +## 2番目のDeploymentを作成する + +1. 次のコマンドを実行して、v2のDeploymentを作成します。 + + ```shell + kubectl create deployment web2 --image=gcr.io/google-samples/hello-app:2.0 + ``` + + 出力は次のようになります。 + + ```shell + deployment.apps/web2 created + ``` + +1. Deploymentを公開します。 + + ```shell + kubectl expose deployment web2 --port=8080 --type=NodePort + ``` + + 出力は次のようになります。 + + ```shell + service/web2 exposed + ``` + +## Ingressを編集する + +1. 既存の`example-ingress.yaml`を編集して、以下の行を追加します。 + + ```yaml + - path: /v2 + backend: + serviceName: web2 + servicePort: 8080 + ``` + +1. 次のコマンドで変更を適用します。 + + ```shell + kubectl apply -f example-ingress.yaml + ``` + + 出力は次のようになります。 + + ```shell + ingress.networking/example-ingress configured + ``` + +## Ingressを試す + +1. Hello Worldアプリの1番目のバージョンにアクセスします。 + + ```shell + curl hello-world.info + ``` + + 出力は次のようになります。 + + ```shell + Hello, world! + Version: 1.0.0 + Hostname: web-55b8c6998d-8k564 + ``` + +1. Hello Worldアプリの2番目のバージョンにアクセスします。 + + ```shell + curl hello-world.info/v2 + ``` + + 出力は次のようになります。 + + ```shell + Hello, world! + Version: 2.0.0 + Hostname: web2-75cd47646f-t8cjk + ``` + + {{< note >}} + Minikubeをローカル環境で実行している場合、ブラウザからhello-world.infoおよびhello-world.info/v2にアクセスできます。 + {{< /note >}} + + + + +## {{% heading "whatsnext" %}} + +* [Ingress](/ja/docs/concepts/services-networking/ingress/)についてさらに学ぶ。 +* [Ingressコントローラー](/ja/docs/concepts/services-networking/ingress-controllers/)についてさらに学ぶ。 +* [Service](/ja/docs/concepts/services-networking/service/)についてさらに学ぶ。 + + + diff --git a/content/ja/docs/tasks/access-application-cluster/list-all-running-container-images.md b/content/ja/docs/tasks/access-application-cluster/list-all-running-container-images.md new file mode 100644 index 0000000000..3d36d99539 --- /dev/null +++ b/content/ja/docs/tasks/access-application-cluster/list-all-running-container-images.md @@ -0,0 +1,112 @@ +--- +title: クラスターで実行されているすべてのコンテナイメージを一覧表示する +content_type: task +weight: 100 +--- + +<!-- overview --> + +このページでは、kubectlを使用して、クラスターで実行されているPodのすべてのコンテナイメージを一覧表示する方法を説明します。 + + + +## {{% heading "prerequisites" %}} + + +{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}} + + + +<!-- steps --> + +この演習では、kubectlを使用してクラスターで実行されているすべてのPodを取得し、出力をフォーマットしてそれぞれのコンテナの一覧を取得します。 + +## すべての名前空間のコンテナイメージを一覧表示する {#list-all-container-images-in-all-namespaces} + +- `kubectl get pods --all-namespaces`を使用して、すべての名前空間のPodを取得します +- `-o jsonpath={.. image}`を使用して、コンテナイメージ名のリストのみが含まれるように出力をフォーマットします。これは、返されたjsonの`image`フィールドを再帰的に解析します。 + - jsonpathの使い方については、[jsonpathリファレンス](/docs/user-guide/jsonpath/)を参照してください。 +- `tr`、`sort`、`uniq`などの標準ツールを使用して出力をフォーマットします。 + - `tr`を使用してスペースを改行に置換します。 + - `sort`を使用して結果を並べ替えます。 + - `uniq`を使用してイメージ数を集計します。 + +```sh +kubectl get pods --all-namespaces -o jsonpath="{..image}" |\ +tr -s '[[:space:]]' '\n' |\ +sort |\ +uniq -c +``` + +上記のコマンドは、返されるすべてのアイテムについて、`image`という名前のすべてのフィールドを再帰的に返します。 + +別の方法として、Pod内のimageフィールドへの絶対パスを使用することができます。これにより、フィールド名が繰り返されている場合でも正しいフィールドが取得されます。多くのフィールドは与えられたアイテム内で`name`と呼ばれます: + +```sh +kubectl get pods --all-namespaces -o jsonpath="{.items[*].spec.containers[*].image}" +``` + +jsonpathは次のように解釈されます: + +- `.items[*]`: 各戻り値 +- `.spec`: 仕様の取得 +- `.containers[*]`: 各コンテナ +- `.image`: イメージの取得 + +{{< note >}} +例えば`kubectl get pod nginx`のように名前を指定して単一のPodを取得する場合、アイテムのリストではなく単一のPodが返されるので、パスの`.items[*]`部分は省略してください。 +{{< /note >}} + +## Podごとにコンテナイメージを一覧表示する {#list-container-images-by-pod} + +`range`を使用して要素を個別に繰り返し処理することにより、フォーマットをさらに制御できます。 + +```sh +kubectl get pods --all-namespaces -o=jsonpath='{range .items[*]}{"\n"}{.metadata.name}{":\t"}{range .spec.containers[*]}{.image}{", "}{end}{end}' |\ +sort +``` + +## Podのラベルを使用してコンテナイメージ一覧をフィルタリングする {#list-container-images-filtering-by-pod-namespace} + +特定のラベルに一致するPodのみを対象とするには、-lフラグを使用します。以下は、`app=nginx`に一致するラベルを持つPodのみに一致します。 + +```sh +kubectl get pods --all-namespaces -o=jsonpath="{..image}" -l app=nginx +``` + +## Podの名前空間でコンテナイメージ一覧をフィルタリングする {#list-container-images-filtering-by-pod-namespace} + +特定の名前空間のPodのみを対象とするには、namespaceフラグを使用します。以下は`kube-system`名前空間のPodのみに一致します。 + +```sh +kubectl get pods --namespace kube-system -o jsonpath="{..image}" +``` + +## jsonpathの代わりにgo-templateを使用してコンテナイメージを一覧表示する {#list-container-images-using-a-go-template-instead-of-jsonpath} + +jsonpathの代わりに、kubectlは[go-templates](https://golang.org/pkg/text/template/)を使用した出力のフォーマットをサポートしています: + + +```sh +kubectl get pods --all-namespaces -o go-template --template="{{range .items}}{{range .spec.containers}}{{.image}} {{end}}{{end}}" +``` + + + + + +<!-- discussion --> + + + +## {{% heading "whatsnext" %}} + + +### 参照 + +* [jsonpath](/docs/user-guide/jsonpath/)参照ガイド +* [Go template](https://golang.org/pkg/text/template/)参照ガイド + + + + diff --git a/content/ja/docs/tasks/access-application-cluster/service-access-application-cluster.md b/content/ja/docs/tasks/access-application-cluster/service-access-application-cluster.md index 8b0439ec3a..1fe8e47e7b 100644 --- a/content/ja/docs/tasks/access-application-cluster/service-access-application-cluster.md +++ b/content/ja/docs/tasks/access-application-cluster/service-access-application-cluster.md @@ -23,7 +23,7 @@ weight: 60 ## {{% heading "objectives" %}} -* 2つのHellow Worldアプリケーションを稼働させる。 +* 2つのHello Worldアプリケーションを稼働させる。 * Nodeのポートを公開するServiceオブジェクトを作成する。 * 稼働しているアプリケーションにアクセスするためにServiceオブジェクトを使用する。 diff --git a/content/ja/docs/tasks/access-application-cluster/web-ui-dashboard.md b/content/ja/docs/tasks/access-application-cluster/web-ui-dashboard.md index 99585c4631..8087e5602e 100644 --- a/content/ja/docs/tasks/access-application-cluster/web-ui-dashboard.md +++ b/content/ja/docs/tasks/access-application-cluster/web-ui-dashboard.md @@ -92,12 +92,12 @@ Kubeconfigの認証方法は、外部IDプロバイダーやx509証明書ベー 例: - ```conf -release=1.0 -tier=frontend -environment=pod -track=stable -``` + ```conf + release=1.0 + tier=frontend + environment=pod + track=stable + ``` - **Namespace**: Kubernetesは、同じ物理クラスターを基盤とする複数の仮想クラスターをサポートしています。これらの仮想クラスタは[名前空間](/docs/tasks/administer-cluster/namespaces/) と呼ばれます。これにより、リソースを論理的に名前のついたグループに分割することができます。 diff --git a/content/ja/docs/tasks/administer-cluster/coredns.md b/content/ja/docs/tasks/administer-cluster/coredns.md index 7122e3dc34..068832e852 100644 --- a/content/ja/docs/tasks/administer-cluster/coredns.md +++ b/content/ja/docs/tasks/administer-cluster/coredns.md @@ -39,7 +39,7 @@ kubeadm upgrade apply v1.11.0 --feature-gates=CoreDNS=true Kubernetesバージョン1.13以降では、`CoreDNS`フィーチャーゲートが削除され、CoreDNSがデフォルトで使用されます。アップグレードしたクラスターでkube-dnsを使用する場合は、[こちら](/docs/reference/setup-tools/kubeadm/kubeadm-init-phase#cmd-phase-addon)のガイドに従ってください。 -1.11以前のバージョンでは、Corefileはアップグレード中に作成されたものによって**上書き**されます。**カスタマイズしている場合は、既存のConfigMapを保存する必要があります。**新しいConfigMapが稼働したら、カスタマイズを再適用できます。 +1.11以前のバージョンでは、Corefileはアップグレード中に作成されたものによって**上書き**されます。**カスタマイズしている場合は、既存のConfigMapを保存する必要があります。** 新しいConfigMapが稼働したら、カスタマイズを再適用できます。 Kubernetesバージョン1.11以降でCoreDNSを実行している場合、アップグレード中、既存のCorefileは保持されます。 diff --git a/content/ja/docs/tasks/administer-cluster/enabling-service-topology.md b/content/ja/docs/tasks/administer-cluster/enabling-service-topology.md new file mode 100644 index 0000000000..304e0937a6 --- /dev/null +++ b/content/ja/docs/tasks/administer-cluster/enabling-service-topology.md @@ -0,0 +1,44 @@ +--- +title: Serviceトポロジーを有効にする +content_type: task +--- + +<!-- overview --> +このページでは、Kubernetes上でServiceトポロジーを有効にする方法の概要について説明します。 + + +## {{% heading "prerequisites" %}} + + {{< include "task-tutorial-prereqs.md" >}} {{< version-check >}} + + +<!-- steps --> + +## はじめに + +*Serviceトポロジー*は、クラスターのノードのトポロジーに基づいてトラフィックをルーティングできるようにする機能です。たとえば、あるServiceのトラフィックに対して、できるだけ同じノードや同じアベイラビリティゾーン上にあるエンドポイントを優先してルーティングするように指定できます。 + +## 前提 + +トポロジーを考慮したServiceのルーティングを有効にするには、以下の前提を満たしている必要があります。 + + * Kubernetesバージョン1.17以降である + * {{< glossary_tooltip text="Kube-proxy" term_id="kube-proxy" >}}がiptableモードまたはIPVSモードで稼働している + * [Endpoint Slice](/docs/concepts/services-networking/endpoint-slices/)を有効にしている + +## Serviceトポロジーを有効にする + +{{< feature-state for_k8s_version="v1.17" state="alpha" >}} + +Serviceトポロジーを有効にするには、すべてのKubernetesコンポーネントで`ServiceTopology`と`EndpointSlice`フィーチャーゲートを有効にする必要があります。 + +``` +--feature-gates="ServiceTopology=true,EndpointSlice=true" +``` + +## {{% heading "whatsnext" %}} + +* [Serviceトポロジー](/ja/docs/concepts/services-networking/service-topology)のコンセプトについて読む +* [Endpoint Slice](/docs/concepts/services-networking/endpoint-slices)について読む +* [サービスとアプリケーションの接続](/ja/docs/concepts/services-networking/connect-applications-service/)を読む + diff --git a/content/ja/docs/tasks/administer-cluster/extended-resource-node.md b/content/ja/docs/tasks/administer-cluster/extended-resource-node.md new file mode 100644 index 0000000000..59156efd89 --- /dev/null +++ b/content/ja/docs/tasks/administer-cluster/extended-resource-node.md @@ -0,0 +1,169 @@ +--- +title: 拡張リソースをNodeにアドバタイズする +content_type: task +--- + +<!-- overview --> + +このページでは、Nodeに対して拡張リソースを指定する方法を説明します。拡張リソースを利用すると、Kubernetesにとって未知のノードレベルのリソースをクラスター管理者がアドバタイズできるようになります。 + +## {{% heading "prerequisites" %}} + +{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}} + +<!-- steps --> + +## Nodeの名前を取得する + +```shell +kubectl get nodes +``` + +この練習で使いたいNodeを1つ選んでください。 + +## Nodeの1つで新しい拡張リソースをアドバタイズする + +Node上の新しい拡張リソースをアドバタイズするには、HTTPのPATCHリクエストをKubernetes APIサーバーに送ります。たとえば、Nodeの1つに4つのドングルが接続されているとします。以下に、4つのドングルリソースをNodeにアドバタイズするPATCHリクエストの例を示します。 + +```shell +PATCH /api/v1/nodes/<選択したNodeの名前>/status HTTP/1.1 +Accept: application/json +Content-Type: application/json-patch+json +Host: k8s-master:8080 + +[ + { + "op": "add", + "path": "/status/capacity/example.com~1dongle", + "value": "4" + } +] +``` + +Kubernetesは、ドングルとは何かも、ドングルが何に利用できるのかを知る必要もないことに注意してください。上のPATCHリクエストは、ただNodeが4つのドングルと呼ばれるものを持っているとKubernetesに教えているだけです。 + +Kubernetes APIサーバーに簡単にリクエストを送れるように、プロキシーを実行します。 + +```shell +kubectl proxy +``` + +もう1つのコマンドウィンドウを開き、HTTPのPATCHリクエストを送ります。`<選択したNodeの名前>`の部分は、選択したNodeの名前に置き換えてください。 + +```shell +curl --header "Content-Type: application/json-patch+json" \ +--request PATCH \ +--data '[{"op": "add", "path": "/status/capacity/example.com~1dongle", "value": "4"}]' \ +http://localhost:8001/api/v1/nodes/<選択したNodeの名前>/status +``` + +{{< note >}} +上のリクエストにある`~1`は、PATCHのパスにおける`/`という文字をエンコーディングしたものです。JSON-Patch内のoperationのpathはJSON-Pointerとして解釈されます。詳細については、[IETF RFC 6901](https://tools.ietf.org/html/rfc6901)のsection 3を読んでください。 +{{< /note >}} + +出力には、Nodeがキャパシティー4のdongleを持っていることが示されます。 + +``` +"capacity": { + "cpu": "2", + "memory": "2049008Ki", + "example.com/dongle": "4", +``` + +Nodeの説明を確認します。 + +``` +kubectl describe node <選択したNodeの名前> +``` + +出力には、再びdongleリソースが表示されます。 + +```yaml +Capacity: + cpu: 2 + memory: 2049008Ki + example.com/dongle: 4 +``` + +これで、アプリケーション開発者は特定の数のdongleをリクエストするPodを作成できるようになりました。詳しくは、[拡張リソースをコンテナに割り当てる](/docs/tasks/configure-pod-container/extended-resource/)を読んでください。 + +## 議論 + +拡張リソースは、メモリやCPUリソースと同様のものです。たとえば、Nodeが持っている特定の量のメモリやCPUがNode上で動作している他のすべてのコンポーネントと共有されるのと同様に、Nodeが搭載している特定の数のdongleが他のすべてのコンポーネントと共有されます。そして、アプリケーション開発者が特定の量のメモリとCPUをリクエストするPodを作成できるのと同様に、Nodeが搭載している特定の数のdongleをリクエストするPodが作成できます。 + +拡張リソースはKubernetesには詳細を意図的に公開しないため、Kubernetesは拡張リソースの実体をまったく知りません。Kubernetesが知っているのは、Nodeが特定の数の拡張リソースを持っているということだけです。拡張リソースは整数値でアドバタイズしなければなりません。たとえば、Nodeは4つのdongleをアドバタイズできますが、4.5のdongleというのはアドバタイズできません。 + +### Storageの例 + +Nodeに800GiBの特殊なディスクストレージがあるとします。この特殊なストレージの名前、たとえばexample.com/special-storageという名前の拡張リソースが作れます。そして、そのなかの一定のサイズ、たとえば100GiBのチャンクをアドバタイズできます。この場合、Nodeはexample.com/special-storageという種類のキャパシティ8のリソースを持っているとアドバタイズします。 + +```yaml +Capacity: + ... + example.com/special-storage: 8 +``` + +特殊なストレージに任意のサイズのリクエストを許可したい場合、特殊なストレージを1バイトのサイズのチャンクでアドバタイズできます。その場合、example.com/special-storageという種類の800Giのリソースとしてアドバタイズします。 + +```yaml +Capacity: + ... + example.com/special-storage: 800Gi +``` + +すると、コンテナは好きなバイト数の特殊なストレージを最大800Giまでリクエストできるようになります。 + +## クリーンアップ + +以下に、dongleのアドバタイズをNodeから削除するPATCHリクエストを示します。 + +``` +PATCH /api/v1/nodes/<選択したNodeの名前>/status HTTP/1.1 +Accept: application/json +Content-Type: application/json-patch+json +Host: k8s-master:8080 + +[ + { + "op": "remove", + "path": "/status/capacity/example.com~1dongle", + } +] +``` + +Kubernetes APIサーバーに簡単にリクエストを送れるように、プロキシーを実行します。 + +```shell +kubectl proxy +``` + +もう1つのコマンドウィンドウで、HTTPのPATCHリクエストを送ります。`<選択したNodeの名前>`の部分は、選択したNodeの名前に置き換えてください。 + +```shell +curl --header "Content-Type: application/json-patch+json" \ +--request PATCH \ +--data '[{"op": "remove", "path": "/status/capacity/example.com~1dongle"}]' \ +http://localhost:8001/api/v1/nodes/<選択したNodeの名前>/status +``` + +dongleのアドバタイズが削除されたことを検証します。 + +``` +kubectl describe node <選択したNodeの名前> | grep dongle +``` + +(出力には何も表示されないはずです) + +## {{% heading "whatsnext" %}} + +### アプリケーション開発者向け + +* [拡張リソースをコンテナに割り当てる](/ja/docs/tasks/configure-pod-container/extended-resource/) + +### クラスター管理者向け + +* [Namespaceに対してメモリの最小値と最大値の制約を設定する](/docs/tasks/administer-cluster/manage-resources/memory-constraint-namespace/) +* [Namespaceに対してCPUの最小値と最大値の制約を設定する](/docs/tasks/administer-cluster/manage-resources/cpu-constraint-namespace/) + + + diff --git a/content/ja/docs/tasks/administer-cluster/running-cloud-controller.md b/content/ja/docs/tasks/administer-cluster/running-cloud-controller.md index e98cee60d8..9a06821517 100644 --- a/content/ja/docs/tasks/administer-cluster/running-cloud-controller.md +++ b/content/ja/docs/tasks/administer-cluster/running-cloud-controller.md @@ -9,7 +9,7 @@ content_type: concept Kubernetes v1.6では`cloud-controller-manager`という新しいバイナリが導入されました。`cloud-controller-manager`はクラウド固有の制御ループを組み込むデーモンです。これらのクラウド固有の制御ループはもともと`kube-controller-manager`にありました。クラウドプロバイダーはKubernetesプロジェクトとは異なるペースで開発およびリリースされるため、プロバイダー固有のコードを`cloud-controller-manager`バイナリに抽象化することでクラウドベンダーはKubernetesのコアのコードとは独立して開発が可能となりました。 -`cloud-controller-manager`は、[cloudprovider.Interface](https://github.com/kubernetes/cloud-provider/blob/master/cloud.go)を満たす任意のクラウドプロバイダーと接続できます。下位互換性のためにKubernetesのコアプロジェクトで提供される[cloud-controller-manager](https://github.com/kubernetes/kubernetes/tree/master/cmd/cloud-controller-manager)は`kube-controller-manager`と同じクラウドライブラリを使用します。Kubernetesのコアリポジトリで既にサポートされているクラウドプロバイダーは、Kubernetesリポジトリにあるcloud-controller-managerを使用してKubernetesのコアから移行することが期待されています。今後のKubernetesのリリースでは、すべてのクラウドコントローラーマネージャーはsigリードまたはクラウドベンダーが管理するKubernetesのコアプロジェクトの外で開発される予定です。 +`cloud-controller-manager`は、[cloudprovider.Interface](https://github.com/kubernetes/cloud-provider/blob/master/cloud.go)を満たす任意のクラウドプロバイダーと接続できます。下位互換性のためにKubernetesのコアプロジェクトで提供される[cloud-controller-manager](https://github.com/kubernetes/kubernetes/tree/master/cmd/cloud-controller-manager)は`kube-controller-manager`と同じクラウドライブラリを使用します。Kubernetesのコアリポジトリですでにサポートされているクラウドプロバイダーは、Kubernetesリポジトリにあるcloud-controller-managerを使用してKubernetesのコアから移行することが期待されています。今後のKubernetesのリリースでは、すべてのクラウドコントローラーマネージャーはsigリードまたはクラウドベンダーが管理するKubernetesのコアプロジェクトの外で開発される予定です。 @@ -24,7 +24,7 @@ Kubernetes v1.6では`cloud-controller-manager`という新しいバイナリが * クラウドの認証/認可: クラウドではAPIへのアクセスを許可するためにトークンまたはIAMルールが必要になる場合があります * kubernetesの認証/認可: cloud-controller-managerは、kubernetes apiserverと通信するためにRBACルールの設定を必要とする場合があります -* 高可用性: kube-controller-managerのように、リーダー選出を使用したクラウドコントローラーマネージャーの高可用性のセットアップが必要になる場合があります（デフォルトでオンになっています）。 +* 高可用性: kube-controller-managerのように、リーダー選出を使用したクラウドコントローラーマネージャーの高可用性のセットアップが必要になる場合があります(デフォルトでオンになっています)。 ### cloud-controller-managerを動かす @@ -35,7 +35,7 @@ cloud-controller-managerを正常に実行するにはクラスター構成に クラウドコントローラーマネージャーを使用するようにクラスターを設定するとクラスターの動作がいくつか変わることに注意してください。 -* `--cloud-provider=external`を指定したkubeletは、初期化時に`NoSchedule`の`node.cloudprovider.kubernetes.io/uninitialized`汚染を追加します。これによりノードは作業をスケジュールする前に外部のコントローラーからの2回目の初期化が必要であるとマークされます。クラウドコントローラーマネージャーが使用できない場合クラスター内の新しいノードはスケジュールできないままになることに注意してください。スケジューラーはリージョンやタイプ（高CPU、GPU、高メモリ、スポットインスタンスなど）などのノードに関するクラウド固有の情報を必要とする場合があるためこの汚染は重要です。 +* `--cloud-provider=external`を指定したkubeletは、初期化時に`NoSchedule`の`node.cloudprovider.kubernetes.io/uninitialized`汚染を追加します。これによりノードは作業をスケジュールする前に外部のコントローラーからの2回目の初期化が必要であるとマークされます。クラウドコントローラーマネージャーが使用できない場合クラスター内の新しいノードはスケジュールできないままになることに注意してください。スケジューラーはリージョンやタイプ(高CPU、GPU、高メモリ、スポットインスタンスなど)などのノードに関するクラウド固有の情報を必要とする場合があるためこの汚染は重要です。 * クラスター内のノードに関するクラウド情報はローカルメタデータを使用して取得されなくなりましたが、代わりにノード情報を取得するためのすべてのAPI呼び出しはクラウドコントローラーマネージャーを経由して行われるようになります。これはセキュリティを向上させるためにkubeletでクラウドAPIへのアクセスを制限できることを意味します。大規模なクラスターではクラスター内からクラウドのほとんどすべてのAPI呼び出しを行うため、クラウドコントローラーマネージャーがレートリミットに達するかどうかを検討する必要があります。 v1.8の時点でクラウドコントローラーマネージャーは以下を実装できます。 @@ -69,7 +69,7 @@ Kubernetesのコアリポジトリにないクラウドコントローラーマ ### ボリュームのサポート -ボリュームの統合にはkubeletとの調整も必要になるためクラウドコントローラーマネージャーは`kube-controller-manager`にあるボリュームコントローラーを実装しません。CSI（コンテナストレージインターフェイス）が進化してFlexボリュームプラグインの強力なサポートが追加されるにつれ、クラウドがボリュームと完全に統合できるようクラウドコントローラーマネージャーに必要なサポートが追加されます。Kubernetesリポジトリの外部にあるCSIボリュームプラグインの詳細については[こちら](https://github.com/kubernetes/features/issues/178)をご覧ください。 +ボリュームの統合にはkubeletとの調整も必要になるためクラウドコントローラーマネージャーは`kube-controller-manager`にあるボリュームコントローラーを実装しません。CSI(コンテナストレージインターフェイス)が進化してFlexボリュームプラグインの強力なサポートが追加されるにつれ、クラウドがボリュームと完全に統合できるようクラウドコントローラーマネージャーに必要なサポートが追加されます。Kubernetesリポジトリの外部にあるCSIボリュームプラグインの詳細については[こちら](https://github.com/kubernetes/features/issues/178)をご覧ください。 ### スケーラビリティ @@ -79,7 +79,7 @@ Kubernetesのコアリポジトリにないクラウドコントローラーマ クラウドコントローラーマネージャープロジェクトの目標はKubernetesのコアプロジェクトからクラウドに関する機能の開発を切り離すことです。残念ながら、Kubernetesプロジェクトの多くの面でクラウドプロバイダーの機能がKubernetesプロジェクトに緊密に結びついているという前提があります。そのため、この新しいアーキテクチャを採用するとクラウドプロバイダーの情報を要求する状況が発生する可能性がありますが、クラウドコントローラーマネージャーはクラウドプロバイダーへのリクエストが完了するまでその情報を返すことができない場合があります。 -これの良い例は、KubeletのTLSブートストラップ機能です。現在、TLSブートストラップはKubeletがすべてのアドレスタイプ（プライベート、パブリックなど）をクラウドプロバイダー（またはローカルメタデータサービス）に要求する能力を持っていると仮定していますが、クラウドコントローラーマネージャーは最初に初期化されない限りノードのアドレスタイプを設定できないためapiserverと通信するためにはkubeletにTLS証明書が必要です。 +これの良い例は、KubeletのTLSブートストラップ機能です。現在、TLSブートストラップはKubeletがすべてのアドレスタイプ(プライベート、パブリックなど)をクラウドプロバイダー(またはローカルメタデータサービス)に要求する能力を持っていると仮定していますが、クラウドコントローラーマネージャーは最初に初期化されない限りノードのアドレスタイプを設定できないためapiserverと通信するためにはkubeletにTLS証明書が必要です。 このイニシアチブが成熟するに連れ、今後のリリースでこれらの問題に対処するための変更が行われます。 diff --git a/content/ja/docs/tasks/configure-pod-container/assign-cpu-resource.md b/content/ja/docs/tasks/configure-pod-container/assign-cpu-resource.md index 5940705cdd..8091ded576 100644 --- a/content/ja/docs/tasks/configure-pod-container/assign-cpu-resource.md +++ b/content/ja/docs/tasks/configure-pod-container/assign-cpu-resource.md @@ -196,7 +196,7 @@ kubectl delete pod cpu-demo-2 --namespace=cpu-example クラスターで動作するコンテナにCPU要求と制限を設定することで、クラスターのノードで利用可能なCPUリソースを効率的に使用することができます。PodのCPU要求を低く保つことで、Podがスケジュールされやすくなります。CPU要求よりも大きい制限を与えることで、次の2つを実現できます: -* Podは利用可能なCPUリソースを、突発的な活動（バースト）に使用することができます。 +* Podは利用可能なCPUリソースを、突発的な活動(バースト)に使用することができます。 * バースト中のPodのCPUリソース量は、適切な量に制限されます。 diff --git a/content/ja/docs/tasks/configure-pod-container/assign-memory-resource.md b/content/ja/docs/tasks/configure-pod-container/assign-memory-resource.md index fb361dfa72..1af80012fc 100644 --- a/content/ja/docs/tasks/configure-pod-container/assign-memory-resource.md +++ b/content/ja/docs/tasks/configure-pod-container/assign-memory-resource.md @@ -97,7 +97,7 @@ resources: kubectl top pod memory-demo --namespace=mem-example ``` -この出力では、Podが約162,900,000バイト（約150MiB）のメモリーを使用していることを示しています。Podの100MiBの要求を超えていますが、200MiBの制限には収まっています。 +この出力では、Podが約162,900,000バイト(約150MiB)のメモリーを使用していることを示しています。Podの100MiBの要求を超えていますが、200MiBの制限には収まっています。 ``` NAME CPU(cores) MEMORY(bytes) @@ -278,7 +278,7 @@ kubectl delete pod memory-demo-3 --namespace=mem-example クラスターで動作するコンテナにメモリー要求と制限を設定することで、クラスターのノードで利用可能なメモリーリソースを効率的に使用することができます。Podのメモリー要求を低く保つことで、Podがスケジュールされやすくなります。メモリー要求よりも大きい制限を与えることで、次の2つを実現できます: -* Podは利用可能なメモリーを、突発的な活動（バースト）に使用することができます。 +* Podは利用可能なメモリーを、突発的な活動(バースト)に使用することができます。 * バースト中のPodのメモリー使用量は、適切な量に制限されます。 ## クリーンアップ diff --git a/content/ja/docs/tasks/configure-pod-container/assign-pods-nodes.md b/content/ja/docs/tasks/configure-pod-container/assign-pods-nodes.md new file mode 100644 index 0000000000..e2e4e1d647 --- /dev/null +++ b/content/ja/docs/tasks/configure-pod-container/assign-pods-nodes.md @@ -0,0 +1,93 @@ +--- +title: Podをノードに割り当てる +content_type: task +weight: 120 +--- + +<!-- overview --> +このページでは、KubernetesのPodをKubernetesクラスター上の特定のノードに割り当てる方法を説明します。 + +## {{% heading "prerequisites" %}} + +{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}} + +<!-- steps --> + +## ラベルをノードに追加する + +1. クラスター内の{{< glossary_tooltip term_id="node" text="ノード" >}}のリストをラベル付きで表示します。 + + ```shell + kubectl get nodes --show-labels + ``` + + 出力は次のようになります。 + + ```shell + NAME STATUS ROLES AGE VERSION LABELS + worker0 Ready <none> 1d v1.13.0 ...,kubernetes.io/hostname=worker0 + worker1 Ready <none> 1d v1.13.0 ...,kubernetes.io/hostname=worker1 + worker2 Ready <none> 1d v1.13.0 ...,kubernetes.io/hostname=worker2 + ``` +1. ノードの1つを選択して、ラベルを追加します。 + + ```shell + kubectl label nodes <your-node-name> disktype=ssd + ``` + + ここで、`<your-node-name>`は選択したノードの名前です。 + +1. 選択したノードに`disktype=ssd`ラベルがあることを確認します。 + + ```shell + kubectl get nodes --show-labels + ``` + + 出力は次のようになります。 + + ```shell + NAME STATUS ROLES AGE VERSION LABELS + worker0 Ready <none> 1d v1.13.0 ...,disktype=ssd,kubernetes.io/hostname=worker0 + worker1 Ready <none> 1d v1.13.0 ...,kubernetes.io/hostname=worker1 + worker2 Ready <none> 1d v1.13.0 ...,kubernetes.io/hostname=worker2 + ``` + + 上の出力を見ると、`worker0`に`disktype=ssd`というラベルがあることがわかります。 + +## 選択したノードにスケジューリングされるPodを作成する + +以下のPodの構成ファイルには、nodeSelectorに`disktype: ssd`を持つPodが書かれています。これにより、Podは`disktype: ssd`というラベルを持っているノードにスケジューリングされるようになります。 + +{{< codenew file="pods/pod-nginx.yaml" >}} + +1. 構成ファイルを使用して、選択したノードにスケジューリングされるPodを作成します。 + + ```shell + kubectl apply -f https://k8s.io/examples/pods/pod-nginx.yaml + ``` + +1. Podが選択したノード上で実行されているをことを確認します。 + + ```shell + kubectl get pods --output=wide + ``` + + 出力は次のようになります。 + + ```shell + NAME READY STATUS RESTARTS AGE IP NODE + nginx 1/1 Running 0 13s 10.200.0.4 worker0 + ``` + +## 特定のノードにスケジューリングされるPodを作成する + +`nodeName`という設定を使用して、Podを特定のノードにスケジューリングすることもできます。 + +{{< codenew file="pods/pod-nginx-specific-node.yaml" >}} + +構成ファイルを使用して、`foo-node`にだけスケジューリングされるPodを作成します。 + +## {{% heading "whatsnext" %}} + +* [ラベルとセレクター](/ja/docs/concepts/overview/working-with-objects/labels/)についてさらに学ぶ。 +* [ノード](/ja/docs/concepts/architecture/nodes/)についてさらに学ぶ。 diff --git a/content/ja/docs/tasks/configure-pod-container/configure-projected-volume-storage.md b/content/ja/docs/tasks/configure-pod-container/configure-projected-volume-storage.md index f8e7341bb2..c67c826c4d 100644 --- a/content/ja/docs/tasks/configure-pod-container/configure-projected-volume-storage.md +++ b/content/ja/docs/tasks/configure-pod-container/configure-projected-volume-storage.md @@ -5,7 +5,7 @@ weight: 70 --- <!-- overview --> -このページでは、[`projected`](/docs/concepts/storage/volumes/#projected)（投影）ボリュームを使用して、既存の複数のボリュームソースを同一ディレクトリ内にマウントする方法を説明します。 +このページでは、[`projected`](/docs/concepts/storage/volumes/#projected)(投影)ボリュームを使用して、既存の複数のボリュームソースを同一ディレクトリ内にマウントする方法を説明します。 現在、`secret`、`configMap`、`downwardAPI`および`serviceAccountToken`ボリュームを投影できます。 {{< note >}} diff --git a/content/ja/docs/tasks/configure-pod-container/configure-volume-storage.md b/content/ja/docs/tasks/configure-pod-container/configure-volume-storage.md index 87fa5d965e..a7bb1a0d65 100644 --- a/content/ja/docs/tasks/configure-pod-container/configure-volume-storage.md +++ b/content/ja/docs/tasks/configure-pod-container/configure-volume-storage.md @@ -87,7 +87,7 @@ weight: 50 root@redis:/data/redis# kill <pid> ``` - ここで`<pid>`はRedisプロセスID（PID）です。 + ここで`<pid>`はRedisプロセスID(PID)です。 1. 元の端末で、Redis Podへの変更を監視します。最終的には、このようなものが表示されます: diff --git a/content/ja/docs/tasks/configure-pod-container/extended-resource.md b/content/ja/docs/tasks/configure-pod-container/extended-resource.md new file mode 100644 index 0000000000..b056fc7389 --- /dev/null +++ b/content/ja/docs/tasks/configure-pod-container/extended-resource.md @@ -0,0 +1,124 @@ +--- +title: 拡張リソースをコンテナに割り当てる +content_type: task +weight: 40 +--- + +<!-- overview --> + +{{< feature-state state="stable" >}} + +このページでは、拡張リソースをコンテナに割り当てる方法について説明します。 + +## {{% heading "prerequisites" %}} + +{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}} + +この練習を始める前に、[Nodeに拡張リソースをアドバタイズする](/ja/docs/tasks/administer-cluster/extended-resource-node/)の練習を行ってください。これにより、Nodeの1つがドングルリソースをアドバタイズするように設定されます。 + +<!-- steps --> + +## 拡張リソースをPodに割り当てる + +拡張リソースをリクエストするには、コンテナのマニフェストに`resources:requests`フィールドを含めます。拡張リソースは、`*.kubernetes.io/`以外の任意のドメインで完全修飾されます。有効な拡張リソース名は、`example.com/foo`という形式になります。ここで、`example.com`はあなたの組織のドメインで、`foo`は記述的なリソース名で置き換えます。 + +1つのコンテナからなるPodの構成ファイルを示します。 + +{{< codenew file="pods/resource/extended-resource-pod.yaml" >}} + +構成ファイルでは、コンテナが3つのdongleをリクエストしていることがわかります。 + +次のコマンドでPodを作成します。 + +```shell +kubectl apply -f https://k8s.io/examples/pods/resource/extended-resource-pod.yaml +``` + +Podが起動したことを確認します。 + +```shell +kubectl get pod extended-resource-demo +``` + +Podの説明を表示します。 + +```shell +kubectl describe pod extended-resource-demo +``` + +dongleのリクエストが表示されます。 + +```yaml +Limits: + example.com/dongle: 3 +Requests: + example.com/dongle: 3 +``` + +## 2つ目のPodの作成を試みる + +以下に、1つのコンテナを持つPodの構成ファイルを示します。コンテナは2つのdongleをリクエストします。 + +{{< codenew file="pods/resource/extended-resource-pod-2.yaml" >}} + +Kubernetesは、2つのdongleのリクエストを満たすことができません。1つ目のPodが、利用可能な4つのdongleのうち3つを使用してしまっているためです。 + +Podを作成してみます。 + +```shell +kubectl apply -f https://k8s.io/examples/pods/resource/extended-resource-pod-2.yaml +``` + +Podの説明を表示します。 + +```shell +kubectl describe pod extended-resource-demo-2 +``` + +出力にはPodがスケジュールできないことが示されます。2つのdongleが利用できるNodeが存在しないためです。 + +``` +Conditions: + Type Status + PodScheduled False +... +Events: + ... + ... Warning FailedScheduling pod (extended-resource-demo-2) failed to fit in any node +fit failure summary on nodes : Insufficient example.com/dongle (1) +``` + +Podのステータスを表示します。 + +```shell +kubectl get pod extended-resource-demo-2 +``` + +出力には、Podは作成されたものの、Nodeにスケジュールされなかったことが示されています。PodはPending状態になっています。 + +```yaml +NAME READY STATUS RESTARTS AGE +extended-resource-demo-2 0/1 Pending 0 6m +``` + +## クリーンアップ + +この練習で作成したPodを削除します。 + +```shell +kubectl delete pod extended-resource-demo +kubectl delete pod extended-resource-demo-2 +``` + +## {{% heading "whatsnext" %}} + +### アプリケーション開発者向け + +* [コンテナおよびPodへのメモリーリソースの割り当て](/ja/docs/tasks/configure-pod-container/assign-memory-resource/) +* [コンテナおよびPodへのCPUリソースの割り当て](/ja/docs/tasks/configure-pod-container/assign-cpu-resource/) + +### クラスター管理者向け + +* [Nodeに拡張リソースをアドバタイズする](/ja/docs/tasks/administer-cluster/extended-resource-node/) + + diff --git a/content/ja/docs/tasks/configure-pod-container/share-process-namespace.md b/content/ja/docs/tasks/configure-pod-container/share-process-namespace.md index 513da2365c..b5fd61777e 100644 --- a/content/ja/docs/tasks/configure-pod-container/share-process-namespace.md +++ b/content/ja/docs/tasks/configure-pod-container/share-process-namespace.md @@ -97,7 +97,7 @@ Podは多くのリソースを共有するため、プロセスの名前空間 ただし、一部のコンテナイメージは他のコンテナから分離されることが期待されるため、これらの違いを理解することが重要です: 1. **コンテナプロセスは PID 1ではなくなります。** - 一部のコンテナイメージは、PID 1なしで起動することを拒否し（たとえば、`systemd`を使用するコンテナ）、`kill -HUP 1`などのコマンドを実行してコンテナプロセスにシグナルを送信します。 + 一部のコンテナイメージは、PID 1なしで起動することを拒否し(たとえば、`systemd`を使用するコンテナ)、`kill -HUP 1`などのコマンドを実行してコンテナプロセスにシグナルを送信します。 共有プロセス名前空間を持つPodでは、`kill -HUP 1`はPodサンドボックスにシグナルを送ります。(上の例では`/pause`) 1. **プロセスはPod内の他のコンテナに表示されます。** diff --git a/content/ja/docs/tasks/debug-application-cluster/debug-init-containers.md b/content/ja/docs/tasks/debug-application-cluster/debug-init-containers.md index 5577881c95..fa5255ca7f 100644 --- a/content/ja/docs/tasks/debug-application-cluster/debug-init-containers.md +++ b/content/ja/docs/tasks/debug-application-cluster/debug-init-containers.md @@ -14,7 +14,7 @@ content_type: task {{< include "task-tutorial-prereqs.md" >}} {{< version-check >}} -* [Initコンテナ](/ja/docs/concepts/abstractions/init-containers/)の基本を理解しておきましょう。 +* [Initコンテナ](/ja/docs/concepts/workloads/pods/init-containers/)の基本を理解しておきましょう。 * [Initコンテナを設定](/docs/tasks/configure-pod-container/configure-pod-initialization/#creating-a-pod-that-has-an-init-container/)しておきましょう。 @@ -100,7 +100,7 @@ kubectl logs <pod-name> -c <init-container-2> <!-- discussion --> -## Podのステータスを理解する +## Podのステータスを理解する {#understanding-pod-status} `Init：`で始まるPodステータスはInitコンテナの実行ステータスを要約します。以下の表は、Initコンテナのデバッグ中に表示される可能性のあるステータス値の例をいくつか示しています。 diff --git a/content/ja/docs/tasks/debug-application-cluster/debug-service.md b/content/ja/docs/tasks/debug-application-cluster/debug-service.md index c4c965458b..a8332cbcfb 100644 --- a/content/ja/docs/tasks/debug-application-cluster/debug-service.md +++ b/content/ja/docs/tasks/debug-application-cluster/debug-service.md @@ -4,9 +4,7 @@ title: Serviceのデバッグ --- <!-- overview --> -新規にKubernetesをインストールした環境でかなり頻繁に発生する問題は、Serviceが適切に機能しないというものです。 -Deployment（または他のワークロードコントローラー）を通じてPodを実行し、サービスを作成したにもかかわらず、アクセスしようとしても応答がありません。 -何が問題になっているのかを理解するのに、このドキュメントがきっと役立つでしょう。 +新規にKubernetesをインストールした環境でかなり頻繁に発生する問題は、Serviceが適切に機能しないというものです。Deployment(または他のワークロードコントローラー)を通じてPodを実行し、サービスを作成したにもかかわらず、アクセスしようとしても応答がありません。何が問題になっているのかを理解するのに、このドキュメントがきっと役立つでしょう。 @@ -16,8 +14,7 @@ Deployment（または他のワークロードコントローラー）を通じ ## Pod内でコマンドを実行する -ここでの多くのステップでは、クラスターで実行されているPodが見ているものを確認する必要があります。 -これを行う最も簡単な方法は、インタラクティブなalpineのPodを実行することです。 +ここでの多くのステップでは、クラスターで実行されているPodが見ているものを確認する必要があります。これを行う最も簡単な方法は、インタラクティブなalpineのPodを実行することです。 ```none kubectl run -it --rm --restart=Never alpine --image=alpine sh @@ -27,7 +24,7 @@ kubectl run -it --rm --restart=Never alpine --image=alpine sh コマンドプロンプトが表示されない場合は、Enterキーを押してみてください。 {{< /note >}} -使用したい実行中のPodが既にある場合は、以下のようにしてそのPod内でコマンドを実行できます。 +使用したい実行中のPodがすでにある場合は、以下のようにしてそのPod内でコマンドを実行できます。 ```shell kubectl exec <POD-NAME> -c <CONTAINER-NAME> -- <COMMAND> @@ -35,8 +32,7 @@ kubectl exec <POD-NAME> -c <CONTAINER-NAME> -- <COMMAND> ## セットアップ -このドキュメントのウォークスルーのために、いくつかのPodを実行しましょう。 -おそらくあなた自身のServiceをデバッグしているため、あなた自身の詳細に置き換えることもできますし、これに沿って2番目のデータポイントを取得することもできます。 +このドキュメントのウォークスルーのために、いくつかのPodを実行しましょう。おそらくあなた自身のServiceをデバッグしているため、あなた自身の詳細に置き換えることもできますし、これに沿って2番目のデータポイントを取得することもできます。 ```shell kubectl run hostnames --image=k8s.gcr.io/serve_hostname \ @@ -48,7 +44,7 @@ deployment.apps/hostnames created `kubectl`コマンドは作成、変更されたリソースのタイプと名前を出力するため、この後のコマンドで使用することもできます。 -{{< note >}} + これは、次のYAMLでDeploymentを開始した場合と同じです。 ```yaml @@ -72,7 +68,6 @@ spec: ``` "run"ラベルは`kubectl run`によって、Deploymentの名前に自動的にセットされます。 -{{< /note >}} Podが実行されていることを確認できます。 @@ -86,8 +81,7 @@ hostnames-632524106-ly40y 1/1 Running 0 2m hostnames-632524106-tlaok 1/1 Running 0 2m ``` -Podが機能していることも確認できます。 -Pod IP アドレスリストを取得し、直接テストできます。 +Podが機能していることも確認できます。Pod IP アドレスリストを取得し、直接テストできます。 ```shell kubectl get pods -l run=hostnames \ @@ -117,8 +111,7 @@ hostnames-bvc05 hostnames-yp2kp ``` -この時点で期待通りの応答が得られない場合、Podが正常でないか、想定しているポートでリッスンしていない可能性があります。 -なにが起きているかを確認するために`kubectl logs`が役立ちます、Podに直接に入りデバッグする場合は `kubectl exec`が必要になります。 +この時点で期待通りの応答が得られない場合、Podが正常でないか、想定しているポートでリッスンしていない可能性があります。なにが起きているかを確認するために`kubectl logs`が役立ちます。Podに直接に入りデバッグする場合は`kubectl exec`が必要になります。 これまでにすべての計画が完了していると想定すると、Serviceが機能しない理由を調査することができます。 @@ -126,8 +119,7 @@ hostnames-yp2kp 賢明な読者は、Serviceをまだ実際に作成していないことにお気付きかと思いますが、これは意図的です。これは時々忘れられるステップであり、最初に確認すべきことです。 -存在しないServiceにアクセスしようとするとどうなるでしょうか？ -このServiceを名前で利用する別のPodがあると仮定すると、次のような結果が得られます。 +存在しないServiceにアクセスしようとするとどうなるでしょうか？このServiceを名前で利用する別のPodがあると仮定すると、次のような結果が得られます。 ```shell wget -O- hostnames @@ -147,8 +139,7 @@ No resources found. Error from server (NotFound): services "hostnames" not found ``` -Serviceを作成しましょう。 -前と同様に、これはウォークスルー用です。ご自身のServiceの詳細を使用することもできます。 +Serviceを作成しましょう。前と同様に、これはウォークスルー用です。ご自身のServiceの詳細を使用することもできます。 ```shell kubectl expose deployment hostnames --port=80 --target-port=9376 @@ -169,7 +160,6 @@ hostnames ClusterIP 10.0.1.175 <none> 80/TCP 5s これで、Serviceが存在することがわかりました。 -{{< note >}} 前と同様に、これは次のようなYAMLでServiceを開始した場合と同じです。 ```yaml @@ -187,14 +177,11 @@ spec: targetPort: 9376 ``` -構成の全範囲をハイライトするため、ここで作成したServiceはPodとは異なるポート番号を使用します。 -多くの実際のServiceでは、これらのポートは同じになる場合があります。 -{{< /note >}} +構成の全範囲をハイライトするため、ここで作成したServiceはPodとは異なるポート番号を使用します。多くの実際のServiceでは、これらのポートは同じになる場合があります。 ## サービスはDNS名によって機能しているか？ -クライアントがサービスを使用する最も一般的な方法の1つは、DNS名を使用することです。 -同じNamespaceのPodから次のコマンドを実行してください。 +クライアントがサービスを使用する最も一般的な方法の1つは、DNS名を使用することです。同じNamespaceのPodから次のコマンドを実行してください。 ```shell nslookup hostnames @@ -219,8 +206,7 @@ Name: hostnames.default Address 1: 10.0.1.175 hostnames.default.svc.cluster.local ``` -これが機能する場合、クロスネームスペース名を使用するようにアプリケーションを調整するか、同じNamespaceでアプリとServiceを実行する必要があります。 -これでも失敗する場合は、完全修飾名を試してください。 +これが機能する場合、クロスネームスペース名を使用するようにアプリケーションを調整するか、同じNamespaceでアプリとServiceを実行する必要があります。これでも失敗する場合は、完全修飾名を試してください。 ```shell nslookup hostnames.default.svc.cluster.local @@ -232,10 +218,7 @@ Name: hostnames.default.svc.cluster.local Address 1: 10.0.1.175 hostnames.default.svc.cluster.local ``` -ここでのサフィックス"default.svc.cluster.local"に注意してください。 -"default"は、操作しているNamespaceです。 -"svc"は、これがServiceであることを示します。 -"cluster.local"はクラスタードメインであり、あなたのクラスターでは異なる場合があります。 +ここでのサフィックス"default.svc.cluster.local"に注意してください。"default"は、操作しているNamespaceです。"svc"は、これがServiceであることを示します。"cluster.local"はクラスタードメインであり、あなたのクラスターでは異なる場合があります。 クラスター内のノードからも試すこともできます。 @@ -254,8 +237,7 @@ Name: hostnames.default.svc.cluster.local Address: 10.0.1.175 ``` -完全修飾名では検索できるのに、相対名ではできない場合、Podの`/etc/resolv.conf`ファイルが正しいことを確認する必要があります。 -Pod内から実行します。 +完全修飾名では検索できるのに、相対名ではできない場合、Podの`/etc/resolv.conf`ファイルが正しいことを確認する必要があります。Pod内から実行します。 ```shell cat /etc/resolv.conf @@ -269,25 +251,15 @@ search default.svc.cluster.local svc.cluster.local cluster.local example.com options ndots:5 ``` -nameserver行はクラスターのDNS Serviceを示さなければなりません。 -これは、`--cluster-dns`フラグで`kubelet`に渡されます。 +nameserver行はクラスターのDNS Serviceを示さなければなりません。これは、`--cluster-dns`フラグで`kubelet`に渡されます。 -`search`行には、`Service`名を見つけるための適切なサフィックスを含める必要があります。 -この場合、ローカルの`Namespace`で`Service`を見つけるためのサフィックス(`default.svc.cluster.local`)、すべての`Namespaces`で`Service`を見つけるためのサフィックス(`svc.cluster.local`)、およびクラスターのサフィックス(`cluster.local`)です。 -インストール方法によっては、その後に追加のレコードがある場合があります(合計6つまで)。 -クラスターのサフィックスは、`--cluster-domain`フラグを使用して`kubelet`に渡されます。 -このドキュメントではそれが"cluster.local"であると仮定していますが、あなたのクラスターでは異なる場合があります。 -その場合は、上記のすべてのコマンドでクラスターのサフィックスを変更する必要があります。 +`search`行には、`Service`名を見つけるための適切なサフィックスを含める必要があります。この場合、ローカルの`Namespace`で`Service`を見つけるためのサフィックス(`default.svc.cluster.local`)、すべての`Namespaces`で`Service`を見つけるためのサフィックス(`svc.cluster.local`)、およびクラスターのサフィックス(`cluster.local`)です。インストール方法によっては、その後に追加のレコードがある場合があります(合計6つまで)。クラスターのサフィックスは、`--cluster-domain`フラグを使用して`kubelet`に渡されます。このドキュメントではそれが"cluster.local"であると仮定していますが、あなたのクラスターでは異なる場合があります。その場合は、上記のすべてのコマンドでクラスターのサフィックスを変更する必要があります。 -`options`行では、DNSクライアントライブラリーが検索パスをまったく考慮しないように`ndots`を十分に高く設定する必要があります。 -Kubernetesはデフォルトでこれを5に設定します。これは、生成されるすべてのDNS名をカバーするのに十分な大きさです。 +`options`行では、DNSクライアントライブラリーが検索パスをまったく考慮しないように`ndots`を十分に高く設定する必要があります。Kubernetesはデフォルトでこれを5に設定します。これは、生成されるすべてのDNS名をカバーするのに十分な大きさです。 -### DNS名で機能するServiceはありますか？ {#does-any-service-exist-in-dns} +### DNS名で機能するServiceはあるか？ {#does-any-service-exist-in-dns} -上記がまだ失敗する場合、DNSルックアップがServiceに対して機能していません。 -一歩離れて、他の何が機能していないかを確認しましょう。 -KubernetesマスターのServiceは常に機能するはずです。 -Pod内から実行します。 +上記がまだ失敗する場合、DNSルックアップがServiceに対して機能していません。一歩離れて、他の何が機能していないかを確認しましょう。KubernetesマスターのServiceは常に機能するはずです。Pod内から実行します。 ```shell nslookup kubernetes.default @@ -300,12 +272,11 @@ Name: kubernetes.default Address 1: 10.0.0.1 kubernetes.default.svc.cluster.local ``` -これが失敗する場合は、このドキュメントの [kube-proxy](#is-the-kube-proxy-working)セクションを参照するか、このドキュメントの先頭に戻って最初からやり直してください。ただし、あなた自身のServiceをデバッグするのではなく 、DNSサービスをデバッグします。 +これが失敗する場合は、このドキュメントの[kube-proxy](#is-the-kube-proxy-working)セクションを参照するか、このドキュメントの先頭に戻って最初からやり直してください。ただし、あなた自身のServiceをデバッグするのではなく、DNSサービスをデバッグします。 ## ServiceはIPでは機能するか？ -DNSサービスが正しく動作できると仮定すると、次にテストするのはIPによってServiceが動作しているかどうかです。 -上述の`kubectl get`で確認できるIPに、クラスター内のPodからアクセスします。 +DNSサービスが正しく動作できると仮定すると、次にテストするのはIPによってServiceが動作しているかどうかです。上述の`kubectl get`で確認できるIPに、クラスター内のPodからアクセスします。 ```shell for i in $(seq 1 3); do @@ -321,13 +292,11 @@ hostnames-bvc05 hostnames-yp2kp ``` -Serviceが機能している場合は、正しい応答が得られるはずです。 -そうでない場合、おかしい可能性のあるものがいくつかあるため、続けましょう。 +Serviceが機能している場合は、正しい応答が得られるはずです。そうでない場合、おかしい可能性のあるものがいくつかあるため、続けましょう。 ## Serviceは正しく定義されているか？ -馬鹿げているように聞こえるかもしれませんが、Serviceが正しく定義されPodのポートとマッチすることを二度、三度と確認すべきです。 -Serviceを読み返して確認しましょう。 +馬鹿げているように聞こえるかもしれませんが、Serviceが正しく定義されPodのポートとマッチすることを二度、三度と確認すべきです。Serviceを読み返して確認しましょう。 ```shell kubectl get service hostnames -o json @@ -377,8 +346,7 @@ kubectl get service hostnames -o json ## ServiceにEndpointsがあるか？ -ここまで来たということは、Serviceは正しく定義され、DNSによって名前解決できることが確認できているでしょう。 -ここでは、実行したPodがServiceによって実際に選択されていることを確認しましょう。 +ここまで来たということは、Serviceは正しく定義され、DNSによって名前解決できることが確認できているでしょう。ここでは、実行したPodがServiceによって実際に選択されていることを確認しましょう。 以前に、Podが実行されていることを確認しました。再確認しましょう。 @@ -395,8 +363,7 @@ hostnames-yp2kp 1/1 Running 0 1h "AGE"列は、これらのPodが約1時間前のものであることを示しており、それらが正常に実行され、クラッシュしていないことを意味します。 -"RESTARTS"列は、これらのポッドが頻繁にクラッシュしたり、再起動されていないことを示しています。 頻繁に再起動すると、断続的な接続性の問題が発生する可能性があります。 -再起動回数が多い場合は、[ポッドをデバッグする](/ja/docs/tasks/debug-application-cluster/debug-pod-replication-controller/#podのデバッグ)を参照してください。 +"RESTARTS"列は、これらのポッドが頻繁にクラッシュしたり、再起動されていないことを示しています。頻繁に再起動すると、断続的な接続性の問題が発生する可能性があります。再起動回数が多い場合は、[ポッドをデバッグする](/ja/docs/tasks/debug-application-cluster/debug-pod-replication-controller/#podのデバッグ)を参照してください。 Kubernetesシステム内には、すべてのServiceのセレクターを評価し、結果をEndpointsオブジェクトに保存するコントロールループがあります。 @@ -407,15 +374,11 @@ NAME ENDPOINTS hostnames 10.244.0.5:9376,10.244.0.6:9376,10.244.0.7:9376 ``` -これにより、EndpointsコントローラーがServiceの正しいPodを見つけていることを確認できます。 -`ENDPOINTS`列が`<none>`の場合、Serviceの`spec.selector`フィールドが実際にPodの`metadata.labels`値を選択していることを確認する必要があります。 -よくある間違いは、タイプミスまたは他のエラー、たとえばServiceが`app=hostnames`を選択しているのにDeploymentが`run=hostnames`を指定していることです。 +これにより、EndpointsコントローラーがServiceの正しいPodを見つけていることを確認できます。`ENDPOINTS`列が`<none>`の場合、Serviceの`spec.selector`フィールドが実際にPodの`metadata.labels`値を選択していることを確認する必要があります。よくある間違いは、タイプミスまたは他のエラー、たとえばServiceが`app=hostnames`を選択しているのにDeploymentが`run=hostnames`を指定していることです。 ## Podは機能しているか？ -この時点で、Serviceが存在し、Podを選択していることがわかります。 -このウォークスルーの最初に、Pod自体を確認しました。 -Podが実際に機能していることを確認しましょう。Serviceメカニズムをバイパスして、上記EndpointsにリストされているPodに直接アクセスすることができます。 +この時点で、Serviceが存在し、Podを選択していることがわかります。このウォークスルーの最初に、Pod自体を確認しました。Podが実際に機能していることを確認しましょう。Serviceメカニズムをバイパスして、上記EndpointsにリストされているPodに直接アクセスすることができます。 {{< note >}} これらのコマンドは、Serviceポート(80)ではなく、Podポート(9376)を使用します。 @@ -437,23 +400,17 @@ hostnames-bvc05 hostnames-yp2kp ``` -Endpointsリスト内の各Podは、それぞれの自身のホスト名を返すはずです。 -そうならない(または、あなた自身のPodの正しい振る舞いにならない)場合は、そこで何が起こっているのかを調査する必要があります。 +Endpointsリスト内の各Podは、それぞれの自身のホスト名を返すはずです。そうならない(または、あなた自身のPodの正しい振る舞いにならない)場合は、そこで何が起こっているのかを調査する必要があります。 ## kube-proxyは機能しているか？ {#is-the-kube-proxy-working} -ここに到達したのなら、Serviceは実行され、Endpointsがあり、Podが実際にサービスを提供しています。 -この時点で、Serviceのプロキシーメカニズム全体が疑わしいです。 -ひとつひとつ確認しましょう。 +ここに到達したのなら、Serviceは実行され、Endpointsがあり、Podが実際にサービスを提供しています。この時点で、Serviceのプロキシーメカニズム全体が疑わしいです。ひとつひとつ確認しましょう。 -Serviceのデフォルト実装、およびほとんどのクラスターで使用されるものは、kube-proxyです。 -kube-proxyはそれぞれのノードで実行され、Serviceの抽象化を提供するための小さなメカニズムセットの1つを構成するプログラムです。 -クラスターがkube-proxyを使用しない場合、以下のセクションは適用されず、使用しているServiceの実装を調査する必要があります。 +Serviceのデフォルト実装、およびほとんどのクラスターで使用されるものは、kube-proxyです。kube-proxyはそれぞれのノードで実行され、Serviceの抽象化を提供するための小さなメカニズムセットの1つを構成するプログラムです。クラスターがkube-proxyを使用しない場合、以下のセクションは適用されず、使用しているServiceの実装を調査する必要があります。 ### kube-proxyは実行されているか？ -`kube-proxy`がノード上で実行されていることを確認しましょう。 -ノードで実行されていれば、以下のような結果が得られるはずです。 +`kube-proxy`がノード上で実行されていることを確認しましょう。ノードで実行されていれば、以下のような結果が得られるはずです。 ```shell ps auxw | grep kube-proxy @@ -462,11 +419,7 @@ ps auxw | grep kube-proxy root 4194 0.4 0.1 101864 17696 ? Sl Jul04 25:43 /usr/local/bin/kube-proxy --master=https://kubernetes-master --kubeconfig=/var/lib/kube-proxy/kubeconfig --v=2 ``` -次に、マスターとの接続など、明らかな失敗をしていないことを確認します。 -これを行うには、ログを確認する必要があります。 -ログへのアクセス方法は、ノードのOSに依存します。 -一部のOSでは/var/log/kube-proxy.logのようなファイルですが、他のOSでは`journalctl`を使用してログにアクセスします。 -次のように表示されます。 +次に、マスターとの接続など、明らかな失敗をしていないことを確認します。これを行うには、ログを確認する必要があります。ログへのアクセス方法は、ノードのOSに依存します。一部のOSでは/var/log/kube-proxy.logのようなファイルですが、他のOSでは`journalctl`を使用してログにアクセスします。次のように表示されます。 ```none I1027 22:14:53.995134 5063 server.go:200] Running in resource-only container "/kube-proxy" @@ -483,12 +436,9 @@ I1027 22:14:54.040223 5063 proxier.go:294] Adding new service "kube-system/ku マスターに接続できないことに関するエラーメッセージが表示された場合、ノードの設定とインストール手順をダブルチェックする必要があります。 -`kube-proxy`が正しく実行できない理由の可能性の1つは、必須の`conntrack`バイナリが見つからないことです。 -これは、例えばKubernetesをスクラッチからインストールするなど、クラスターのインストール方法に依存して、一部のLinuxシステムで発生する場合があります。 -これが該当する場合は、`conntrack`パッケージを手動でインストール(例: Ubuntuでは`sudo apt install conntrack`)する必要があり、その後に再試行する必要があります。 +`kube-proxy`が正しく実行できない理由の可能性の1つは、必須の`conntrack`バイナリが見つからないことです。これは、例えばKubernetesをスクラッチからインストールするなど、クラスターのインストール方法に依存して、一部のLinuxシステムで発生する場合があります。これが該当する場合は、`conntrack`パッケージを手動でインストール(例: Ubuntuでは`sudo apt install conntrack`)する必要があり、その後に再試行する必要があります。 -kube-proxyは、いくつかのモードのいずれかで実行できます。 上記のログの`Using iptables Proxier`という行は、kube-proxyが「iptables」モードで実行されていることを示しています。 -最も一般的な他のモードは「ipvs」です。 古い「ユーザースペース」モードは、主にこれらに置き換えられました。 +kube-proxyは、いくつかのモードのいずれかで実行できます。上記のログの`Using iptables Proxier`という行は、kube-proxyが「iptables」モードで実行されていることを示しています。最も一般的な他のモードは「ipvs」です。古い「ユーザースペース」モードは、主にこれらに置き換えられました。 #### Iptables mode @@ -510,9 +460,7 @@ iptables-save | grep hostnames -A KUBE-SVC-NWV5X2332I4OT4T3 -m comment --comment "default/hostnames:" -j KUBE-SEP-57KPRZ3JQVENLNBR ``` -各サービスのポートごとに、 `KUBE-SERVICES`に1つのルールと1つの` KUBE-SVC- <hash> `チェーンが必要です。 -Podエンドポイントごとに、その `KUBE-SVC- <hash>`に少数のルールがあり、少数のルールが含まれる1つの `KUBE-SEP- <hash>`チェーンがあるはずです。 -正確なルールは、正確な構成（NodePortとLoadBalancerを含む）に基づいて異なります。 +各サービスのポートごとに、`KUBE-SERVICES`に1つのルールと1つの` KUBE-SVC- <hash> `チェーンが必要です。Podエンドポイントごとに、その`KUBE-SVC- <hash>`に少数のルールがあり、少数のルールが含まれる1つの`KUBE-SEP- <hash>`チェーンがあるはずです。正確なルールは、正確な構成(NodePortとLoadBalancerを含む)に基づいて異なります。 #### IPVS mode @@ -532,12 +480,9 @@ TCP 10.0.1.175:80 rr ... ``` -各Serviceの各ポートに加えて、NodePort、External IP、およびLoad Balancer IPに対して、kube-proxyは仮想サーバーを作成します。 -Pod endpointごとに、対応する実サーバーが作成されます。 -この例では, サービスhostnames(`10.0.1.175:80`) は3つのendpoints(`10.244.0.5:9376`,`10.244.0.6:9376`, `10.244.0.7:9376`)を持っています。 +各Serviceの各ポートに加えて、NodePort、External IP、およびLoad Balancer IPに対して、kube-proxyは仮想サーバーを作成します。Pod endpointごとに、対応する実サーバーが作成されます。この例では、サービスhostnames(`10.0.1.175:80`)は3つのendpoints(`10.244.0.5:9376`、`10.244.0.6:9376`、`10.244.0.7:9376`)を持っています。 -IPVSプロキシーは、各Serviceアドレス(Cluster IP、External IP、NodePort IP、Load Balancer IPなど)毎の仮想サーバーと、Serviceのエンドポイントが存在する場合に対応する実サーバーを作成します。 -この例では、hostnames Service(`10.0.1.175:80`)は3つのエンドポイント(`10.244.0.5:9376`、`10.244.0.6:9376`、`10.244.0.7:9376`)を持ち、上と似た結果が得られるはずです。 +IPVSプロキシーは、各Serviceアドレス(Cluster IP、External IP、NodePort IP、Load Balancer IPなど)毎の仮想サーバーと、Serviceのエンドポイントが存在する場合に対応する実サーバーを作成します。この例では、hostnames Service(`10.0.1.175:80`)は3つのエンドポイント(`10.244.0.5:9376`、`10.244.0.6:9376`、`10.244.0.7:9376`)を持ち、上と似た結果が得られるはずです。 #### Userspace mode @@ -553,7 +498,7 @@ iptables-save | grep hostnames -A KUBE-PORTALS-HOST -d 10.0.1.175/32 -p tcp -m comment --comment "default/hostnames:default" -m tcp --dport 80 -j DNAT --to-destination 10.240.115.247:48577 ``` -サービスの各ポートには2つのルールが必要です（この例では1つだけ）-「KUBE-PORTALS-CONTAINER」と「KUBE-PORTALS-HOST」です。 +サービスの各ポートには2つのルールが必要です(この例では1つだけ)-「KUBE-PORTALS-CONTAINER」と「KUBE-PORTALS-HOST」です。 「userspace」モードを使用する必要はほとんどないので、ここでこれ以上時間を費やすことはありません。 @@ -568,11 +513,9 @@ curl 10.0.1.175:80 hostnames-0uton ``` -もしこれが失敗し、あなたがuserspaceプロキシーを使用している場合、プロキシーへの直接アクセスを試してみてください。 -もしiptablesプロキシーを使用している場合、このセクションはスキップしてください。 +もしこれが失敗し、あなたがuserspaceプロキシーを使用している場合、プロキシーへの直接アクセスを試してみてください。もしiptablesプロキシーを使用している場合、このセクションはスキップしてください。 -上記の`iptables-save`の出力を振り返り、`kube-proxy`がServiceに使用しているポート番号を抽出します。 -上記の例では"48577"です。このポートに接続してください。 +上記の`iptables-save`の出力を振り返り、`kube-proxy`がServiceに使用しているポート番号を抽出します。上記の例では"48577"です。このポートに接続してください。 ```shell curl localhost:48577 @@ -589,18 +532,13 @@ Setting endpoints for default/hostnames:default to [10.244.0.5:9376 10.244.0.6:9 これらが表示されない場合は、`-v`フラグを4に設定して`kube-proxy`を再起動してから、再度ログを確認してください。 -### エッジケース: PodがService IP経由で自身に到達できない。 {#a-pod-fails-to-reach-itself-via-the-service-ip} +### エッジケース: PodがService IP経由で自身に到達できない {#a-pod-fails-to-reach-itself-via-the-service-ip} -これはありそうに聞こえないかもしれませんが、実際には起こり、動作するはずです。 -これはネットワークが"hairpin"トラフィック用に適切に設定されていない場合、通常は`kube-proxy`が`iptables`モードで実行され、Podがブリッジネットワークに接続されている場合に発生します。 -`Kubelet`は`hairpin-mode`[フラグ](/docs/admin/kubelet/)を公開します。 -これにより、Serviceのエンドポイントが自身のServiceのVIPにアクセスしようとした場合に、自身への負荷分散を可能にします。 -`hairpin-mode`フラグは`hairpin-veth`または`promiscuous-bridge`に設定する必要があります。 +これはありそうに聞こえないかもしれませんが、実際には起こり、動作するはずです。これはネットワークが"hairpin"トラフィック用に適切に設定されていない場合、通常は`kube-proxy`が`iptables`モードで実行され、Podがブリッジネットワークに接続されている場合に発生します。`Kubelet`は`hairpin-mode`[フラグ](/docs/admin/kubelet/)を公開します。これにより、Serviceのエンドポイントが自身のServiceのVIPにアクセスしようとした場合に、自身への負荷分散を可能にします。`hairpin-mode`フラグは`hairpin-veth`または`promiscuous-bridge`に設定する必要があります。 この問題をトラブルシューティングする一般的な手順は次のとおりです。 -* `hairpin-mode`が`hairpin-veth`または`promiscuous-bridge`に設定されていることを確認します。 -次のような表示がされるはずです。この例では、`hairpin-mode`は`promiscuous-bridge`に設定されています。 +* `hairpin-mode`が`hairpin-veth`または`promiscuous-bridge`に設定されていることを確認します。次のような表示がされるはずです。この例では、`hairpin-mode`は`promiscuous-bridge`に設定されています。 ```shell ps auxw | grep kubelet @@ -609,20 +547,13 @@ ps auxw | grep kubelet root 3392 1.1 0.8 186804 65208 ? Sl 00:51 11:11 /usr/local/bin/kubelet --enable-debugging-handlers=true --config=/etc/kubernetes/manifests --allow-privileged=True --v=4 --cluster-dns=10.0.0.10 --cluster-domain=cluster.local --configure-cbr0=true --cgroup-root=/ --system-cgroups=/system --hairpin-mode=promiscuous-bridge --runtime-cgroups=/docker-daemon --kubelet-cgroups=/kubelet --babysit-daemons=true --max-pods=110 --serialize-image-pulls=false --outofdisk-transition-frequency=0 ``` -* 実際に使われている`hairpin-mode`を確認します。 -これを行うには、kubeletログを確認する必要があります。 -ログへのアクセス方法は、ノードのOSによって異なります。 -一部のOSでは/var/log/kubelet.logなどのファイルですが、他のOSでは`journalctl`を使用してログにアクセスします。 -互換性のために、実際に使われている`hairpin-mode`が`--hairpin-mode`フラグと一致しない場合があることに注意してください。 -kubelet.logにキーワード`hairpin`を含むログ行があるかどうかを確認してください。 -実際に使われている`hairpin-mode`を示す以下のようなログ行があるはずです。 +* 実際に使われている`hairpin-mode`を確認します。これを行うには、kubeletログを確認する必要があります。ログへのアクセス方法は、ノードのOSによって異なります。一部のOSでは/var/log/kubelet.logなどのファイルですが、他のOSでは`journalctl`を使用してログにアクセスします。互換性のために、実際に使われている`hairpin-mode`が`--hairpin-mode`フラグと一致しない場合があることに注意してください。kubelet.logにキーワード`hairpin`を含むログ行があるかどうかを確認してください。実際に使われている`hairpin-mode`を示す以下のようなログ行があるはずです。 ```none I0629 00:51:43.648698 3252 kubelet.go:380] Hairpin mode set to "promiscuous-bridge" ``` -* 実際に使われている`hairpin-mode`が`hairpin-veth`の場合、`Kubelet`にノードの`/sys`で操作する権限があることを確認します。 -すべてが正常に機能している場合、次のようなものが表示されます。 +* 実際に使われている`hairpin-mode`が`hairpin-veth`の場合、`Kubelet`にノードの`/sys`で操作する権限があることを確認します。すべてが正常に機能している場合、次のようなものが表示されます。 ```shell for intf in /sys/devices/virtual/net/cbr0/brif/*; do cat $intf/hairpin_mode; done @@ -634,8 +565,7 @@ for intf in /sys/devices/virtual/net/cbr0/brif/*; do cat $intf/hairpin_mode; don 1 ``` -実際に使われている`hairpin-mode`が`promiscuous-bridge`の場合、`Kubelet`にノード上のLinuxブリッジを操作する権限があることを確認してください。 -`cbr0`ブリッジが使用され適切に構成されている場合、以下が表示されます。 +実際に使われている`hairpin-mode`が`promiscuous-bridge`の場合、`Kubelet`にノード上のLinuxブリッジを操作する権限があることを確認してください。`cbr0`ブリッジが使用され適切に構成されている場合、以下が表示されます。 ```shell ifconfig cbr0 |grep PROMISC @@ -648,15 +578,9 @@ UP BROADCAST RUNNING PROMISC MULTICAST MTU:1460 Metric:1 ## 助けを求める -ここまでたどり着いたということは、とてもおかしなことが起こっています。 -Serviceは実行中で、Endpointsがあり、Podは実際にサービスを提供しています。 -DNSは動作していて、`kube-proxy`も誤動作していないようです。 -それでも、あなたのServiceは機能していません。 -おそらく私たちにお知らせ頂いた方がよいでしょう。調査をお手伝いします！ +ここまでたどり着いたということは、とてもおかしなことが起こっています。Serviceは実行中で、Endpointsがあり、Podは実際にサービスを提供しています。DNSは動作していて、`kube-proxy`も誤動作していないようです。それでも、あなたのServiceは機能していません。おそらく私たちにお知らせ頂いた方がよいでしょう。調査をお手伝いします！ -[Slack](/docs/troubleshooting/#slack)または -[Forum](https://discuss.kubernetes.io)または -[GitHub](https://github.com/kubernetes/kubernetes)でお問い合わせください。 +[Slack](/docs/troubleshooting/#slack)、[Forum](https://discuss.kubernetes.io)または[GitHub](https://github.com/kubernetes/kubernetes)でお問い合わせください。 diff --git a/content/ja/docs/tasks/debug-application-cluster/get-shell-running-container.md b/content/ja/docs/tasks/debug-application-cluster/get-shell-running-container.md index b6825075b8..684fa981c1 100644 --- a/content/ja/docs/tasks/debug-application-cluster/get-shell-running-container.md +++ b/content/ja/docs/tasks/debug-application-cluster/get-shell-running-container.md @@ -47,7 +47,7 @@ kubectl exec -it shell-demo -- /bin/bash ``` {{< note >}} -ダブルダッシュの記号 "--" はコマンドに渡す引数とkubectlの引数を分離します。 +ダブルダッシュの記号 `--` はコマンドに渡す引数とkubectlの引数を分離します。 {{< /note >}} diff --git a/content/ja/docs/tasks/inject-data-application/environment-variable-expose-pod-information.md b/content/ja/docs/tasks/inject-data-application/environment-variable-expose-pod-information.md new file mode 100644 index 0000000000..a6679de198 --- /dev/null +++ b/content/ja/docs/tasks/inject-data-application/environment-variable-expose-pod-information.md @@ -0,0 +1,149 @@ +--- +title: 環境変数によりコンテナにPod情報を共有する +content_type: task +weight: 30 +--- + +<!-- overview --> + +このページでは、Podが内部で実行しているコンテナに自身の情報を共有する方法を説明します。環境変数ではPodのフィールドとコンテナのフィールドを共有することができます。 + + + + +## {{% heading "prerequisites" %}} + + +{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}} + + + + +<!-- steps --> + +## Downward API {#the-downward-api} + +Podとコンテナのフィールドを実行中のコンテナに共有する方法は2つあります: + +* 環境変数 +* [ボリュームファイル](/docs/tasks/inject-data-application/downward-api-volume-expose-pod-information/#the-downward-api) + +これら2つの方法を合わせて、Podとコンテナフィールドを共有する方法を*Downward API*と呼びます。 + + +## Podフィールドを環境変数の値として使用する {#use-pod-fields-as-values-for-environment-variables} + +この演習では、1つのコンテナを持つPodを作成します。Podの設定ファイルは次のとおりです: + +{{< codenew file="pods/inject/dapi-envars-pod.yaml" >}} + +設定ファイルには、5つの環境変数があります。`env`フィールドは[EnvVars](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#envvar-v1-core)の配列です。配列の最初の要素では、環境変数`MY_NODE_NAME`の値をPodの`spec.nodeName`フィールドから取得することを指定します。同様に、他の環境変数もPodのフィールドから名前を取得します。 + +{{< note >}} +この例のフィールドはPodのフィールドです。これらはPod内のコンテナのフィールドではありません。 +{{< /note >}} + +Podを作成します: + +```shell +kubectl apply -f https://k8s.io/examples/pods/inject/dapi-envars-pod.yaml +``` + +Podのコンテナが実行されていることを確認します: + +```shell +kubectl get pods +``` + +コンテナのログを表示します: + +```shell +kubectl logs dapi-envars-fieldref +``` + +出力には、選択した環境変数の値が表示されます: + +``` +minikube +dapi-envars-fieldref +default +172.17.0.4 +default +``` + +これらの値がログにある理由を確認するには、設定ファイルの`command`および`args`フィールドを確認してください。コンテナが起動すると、5つの環境変数の値が標準出力に書き込まれます。これを10秒ごとに繰り返します。 + +次に、Podで実行しているコンテナへのシェルを取得します: + +```shell +kubectl exec -it dapi-envars-fieldref -- sh +``` + +シェルで環境変数を表示します: + +```shell +/# printenv +``` + +出力は、特定の環境変数にPodフィールドの値が割り当てられていることを示しています: + +``` +MY_POD_SERVICE_ACCOUNT=default +... +MY_POD_NAMESPACE=default +MY_POD_IP=172.17.0.4 +... +MY_NODE_NAME=minikube +... +MY_POD_NAME=dapi-envars-fieldref +``` + +## コンテナフィールドを環境変数の値として使用する {#use-container-fields-as-values-for-environment-variables} + +前の演習では、環境変数の値としてPodフィールドを使用しました。次の演習では、環境変数の値としてコンテナフィールドを使用します。これは、1つのコンテナを持つPodの設定ファイルです: + +{{< codenew file="pods/inject/dapi-envars-container.yaml" >}} + +設定ファイルには、4つの環境変数があります。`env`フィールドは[EnvVars](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#envvar-v1-core)の配列です。配列の最初の要素では、環境変数`MY_CPU_REQUEST`の値を`test-container`という名前のコンテナの`requests.cpu`フィールドから取得することを指定します。同様に、他の環境変数もコンテナのフィールドから値を取得します。 + +Podを作成します: + +```shell +kubectl apply -f https://k8s.io/examples/pods/inject/dapi-envars-container.yaml +``` + +Podのコンテナが実行されていることを確認します: + +```shell +kubectl get pods +``` + +コンテナのログを表示します: + +```shell +kubectl logs dapi-envars-resourcefieldref +``` + +出力には、選択した環境変数の値が表示されます: + +``` +1 +1 +33554432 +67108864 +``` + + + +## {{% heading "whatsnext" %}} + + +* [コンテナの環境変数の定義](/ja/docs/tasks/inject-data-application/define-environment-variable-container/) +* [PodSpec](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podspec-v1-core) +* [Container](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#container-v1-core) +* [EnvVar](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#envvar-v1-core) +* [EnvVarSource](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#envvarsource-v1-core) +* [ObjectFieldSelector](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#objectfieldselector-v1-core) +* [ResourceFieldSelector](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#resourcefieldselector-v1-core) + + diff --git a/content/ja/docs/tasks/manage-gpus/scheduling-gpus.md b/content/ja/docs/tasks/manage-gpus/scheduling-gpus.md new file mode 100644 index 0000000000..b4a01a7bd7 --- /dev/null +++ b/content/ja/docs/tasks/manage-gpus/scheduling-gpus.md @@ -0,0 +1,184 @@ +--- +content_type: concept +title: GPUのスケジューリング +description: クラスター内のノードのリソースとしてGPUを設定してスケジューリングします +--- + +<!-- overview --> + +{{< feature-state state="beta" for_k8s_version="v1.10" >}} + +Kubernetesには、複数ノードに搭載されたAMDおよびNVIDIAのGPU(graphical processing unit)を管理するための**実験的な**サポートが含まれています。 + +このページでは、異なるバージョンのKubernetesを横断してGPUを使用する方法と、現時点での制限について説明します。 + +<!-- body --> + +## デバイスプラグインを使用する + +Kubernetesでは、GPUなどの特別なハードウェアの機能にPodがアクセスできるようにするために、{{< glossary_tooltip text="デバイスプラグイン" term_id="device-plugin" >}}が実装されています。 + +管理者として、ノード上に対応するハードウェアベンダーのGPUドライバーをインストールして、以下のような対応するGPUベンダーのデバイスプラグインを実行する必要があります。 + +* [AMD](#deploying-amd-gpu-device-plugin) +* [NVIDIA](#deploying-nvidia-gpu-device-plugin) + +上記の条件を満たしていれば、Kubernetesは`amd.com/gpu`または`nvidia.com/gpu`をスケジュール可能なリソースとして公開します。 + +これらのGPUをコンテナから使用するには、`cpu`や`memory`をリクエストするのと同じように`<vendor>.com/gpu`というリソースをリクエストするだけです。ただし、GPUを使用するときにはリソースのリクエストの指定方法にいくつか制限があります。 + +- GPUは`limits`セクションでのみ指定されることが想定されている。この制限は、次のことを意味します。 + * Kubernetesはデフォルトでlimitの値をrequestの値として使用するため、GPUの`requests`を省略して`limits`を指定できる。 + * GPUを`limits`と`requests`の両方で指定できるが、これら2つの値は等しくなければならない。 + * GPUの`limits`を省略して`requests`だけを指定することはできない。 +- コンテナ(およびPod)はGPUを共有しない。GPUのオーバーコミットは起こらない。 +- 各コンテナは1つ以上のGPUをリクエストできる。1つのGPUの一部だけをリクエストすることはできない。 + +以下に例を示します。 + +```yaml +apiVersion: v1 +kind: Pod +metadata: + name: cuda-vector-add +spec: + restartPolicy: OnFailure + containers: + - name: cuda-vector-add + # https://github.com/kubernetes/kubernetes/blob/v1.7.11/test/images/nvidia-cuda/Dockerfile + image: "k8s.gcr.io/cuda-vector-add:v0.1" + resources: + limits: + nvidia.com/gpu: 1 # 1 GPUをリクエストしています +``` + +### AMDのGPUデバイスプラグインをデプロイする {#deploying-amd-gpu-device-plugin} + +[AMD公式のGPUデバイスプラグイン](https://github.com/RadeonOpenCompute/k8s-device-plugin)には以下の要件があります。 + +- Kubernetesのノードに、AMDのGPUのLinuxドライバーがあらかじめインストール済みでなければならない。 + +クラスターが起動して上記の要件が満たされれば、以下のコマンドを実行することでAMDのデバイスプラグインをデプロイできます。 + +```shell +kubectl create -f https://raw.githubusercontent.com/RadeonOpenCompute/k8s-device-plugin/v1.10/k8s-ds-amdgpu-dp.yaml +``` + +このサードパーティーのデバイスプラグインに関する問題は、[RadeonOpenCompute/k8s-device-plugin](https://github.com/RadeonOpenCompute/k8s-device-plugin)で報告できます。 + +### NVIDIAのGPUデバイスプラグインをデプロイする {#deploying-nvidia-gpu-device-plugin} + +現在、NVIDIAのGPU向けのデバイスプラグインの実装は2種類あります。 + +#### NVIDIA公式のGPUデバイスプラグイン + +[NVIDIA公式のGPUデバイスプラグイン](https://github.com/NVIDIA/k8s-device-plugin)には以下の要件があります。 + +- Kubernetesのノードに、NVIDIAのドライバーがあらかじめインストール済みでなければならない。 +- Kubernetesのノードに、[nvidia-docker 2.0](https://github.com/NVIDIA/nvidia-docker)があらかじめインストール済みでなければならない。 +- KubeletはコンテナランタイムにDockerを使用しなければならない。 +- runcの代わりにDockerの[デフォルトランタイム](https://github.com/NVIDIA/k8s-device-plugin#preparing-your-gpu-nodes)として、`nvidia-container-runtime`を設定しなければならない。 +- NVIDIAのドライバーのバージョンが次の条件を満たさなければならない ~= 384.81。 + +クラスターが起動して上記の要件が満たされれば、以下のコマンドを実行することでNVIDIAのデバイスプラグインがデプロイできます。 + +```shell +kubectl create -f https://raw.githubusercontent.com/NVIDIA/k8s-device-plugin/1.0.0-beta4/nvidia-device-plugin.yml +``` + +このサードパーティーのデバイスプラグインに関する問題は、[NVIDIA/k8s-device-plugin](https://github.com/NVIDIA/k8s-device-plugin)で報告できます。 + +#### GCEで使用されるNVIDIAのGPUデバイスプラグイン + +[GCEで使用されるNVIDIAのGPUデバイスプラグイン](https://github.com/GoogleCloudPlatform/container-engine-accelerators/tree/master/cmd/nvidia_gpu)は、nvidia-dockerを必要としないため、KubernetesのContainer Runtime Interface(CRI)と互換性のある任意のコンテナランタイムで動作するはずです。このデバイスプラグインは[Container-Optimized OS](https://cloud.google.com/container-optimized-os/)でテストされていて、1.9以降ではUbuntu向けの実験的なコードも含まれています。 + +以下のコマンドを実行すると、NVIDIAのドライバーとデバイスプラグインをインストールできます。 + +```shell +# NVIDIAドライバーをContainer-Optimized OSにインストールする +kubectl create -f https://raw.githubusercontent.com/GoogleCloudPlatform/container-engine-accelerators/stable/daemonset.yaml + +# NVIDIAドライバーをUbuntuにインストールする(実験的) +kubectl create -f https://raw.githubusercontent.com/GoogleCloudPlatform/container-engine-accelerators/stable/nvidia-driver-installer/ubuntu/daemonset.yaml + +# デバイスプラグインをインストールする +kubectl create -f https://raw.githubusercontent.com/kubernetes/kubernetes/release-1.14/cluster/addons/device-plugins/nvidia-gpu/daemonset.yaml +``` + +このサードパーティーのデバイスプラグインの使用やデプロイに関する問題は、[GoogleCloudPlatform/container-engine-accelerators](https://github.com/GoogleCloudPlatform/container-engine-accelerators)で報告できます。 + +Googleは、GKE上でNVIDIAのGPUを使用するための[手順](https://cloud.google.com/kubernetes-engine/docs/how-to/gpus)も公開しています。 + +## 異なる種類のGPUを搭載するクラスター + +クラスター上の別のノードに異なる種類のGPUが搭載されている場合、[NodeラベルとNodeセレクター](/docs/tasks/configure-pod-container/assign-pods-nodes/)を使用することで、Podを適切なノードにスケジューリングできます。 + +以下に例を示します。 + +```shell +# アクセラレーターを搭載したノードにラベルを付けます。 +kubectl label nodes <node-with-k80> accelerator=nvidia-tesla-k80 +kubectl label nodes <node-with-p100> accelerator=nvidia-tesla-p100 +``` + +## 自動的なNodeラベルの付加 {#node-labeller} + +AMDのGPUデバイスを使用している場合、[Node Labeller](https://github.com/RadeonOpenCompute/k8s-device-plugin/tree/master/cmd/k8s-node-labeller)をデプロイできます。Node Labellerは{{< glossary_tooltip text="コントローラー" term_id="controller" >}}の1種で、GPUデバイスのプロパティを持つノードに自動的にラベルを付けてくれます。 + +現在は、このコントローラーは以下のプロパティに基づいてラベルを追加できます。 + +* デバイスID(-device-id) +* VRAMのサイズ(-vram) +* SIMDの数(-simd-count) +* Compute Unitの数(-cu-count) +* ファームウェアとフィーチャーのバージョン(-firmware) +* 2文字の頭字語で表されたGPUファミリー(-family) + * SI - Southern Islands + * CI - Sea Islands + * KV - Kaveri + * VI - Volcanic Islands + * CZ - Carrizo + * AI - Arctic Islands + * RV - Raven + +```shell +kubectl describe node cluster-node-23 +``` + +``` + Name: cluster-node-23 + Roles: <none> + Labels: beta.amd.com/gpu.cu-count.64=1 + beta.amd.com/gpu.device-id.6860=1 + beta.amd.com/gpu.family.AI=1 + beta.amd.com/gpu.simd-count.256=1 + beta.amd.com/gpu.vram.16G=1 + beta.kubernetes.io/arch=amd64 + beta.kubernetes.io/os=linux + kubernetes.io/hostname=cluster-node-23 + Annotations: kubeadm.alpha.kubernetes.io/cri-socket: /var/run/dockershim.sock + node.alpha.kubernetes.io/ttl: 0 + … +``` + +Node Labellerを使用すると、GPUの種類をPodのspec内で指定できます。 + +```yaml +apiVersion: v1 +kind: Pod +metadata: + name: cuda-vector-add +spec: + restartPolicy: OnFailure + containers: + - name: cuda-vector-add + # https://github.com/kubernetes/kubernetes/blob/v1.7.11/test/images/nvidia-cuda/Dockerfile + image: "k8s.gcr.io/cuda-vector-add:v0.1" + resources: + limits: + nvidia.com/gpu: 1 + nodeSelector: + accelerator: nvidia-tesla-p100 # または nvidia-tesla-k80 など +``` + +これにより、指定した種類のGPUを搭載したノードにPodがスケジューリングされることを保証できます。 diff --git a/content/ja/docs/tasks/manage-hugepages/scheduling-hugepages.md b/content/ja/docs/tasks/manage-hugepages/scheduling-hugepages.md new file mode 100644 index 0000000000..ed87cf4e3f --- /dev/null +++ b/content/ja/docs/tasks/manage-hugepages/scheduling-hugepages.md @@ -0,0 +1,93 @@ +--- +title: huge pageを管理する +content_type: task +description: クラスター内のスケジュール可能なリソースとしてhuge pageの設定と管理を行います。 +--- + +<!-- overview --> +{{< feature-state state="stable" >}} + +Kubernetesでは、事前割り当てされたhuge pageをPod内のアプリケーションに割り当てたり利用したりすることをサポートしています。このページでは、ユーザーがhuge pageを利用できるようにする方法について説明します。 + +## {{% heading "prerequisites" %}} + +1. Kubernetesのノードがhuge pageのキャパシティを報告するためには、ノード上でhuge pageを事前割り当てしておく必要があります。1つのノードでは複数のサイズのhuge pageが事前割り当てできます。 + +ノードは、すべてのhuge pageリソースを、スケジュール可能なリソースとして自動的に探索・報告してくれます。 + +<!-- steps --> + +## API + +huge pageはコンテナレベルのリソース要求で`hugepages-<size>`という名前のリソースを指定することで利用できます。ここで、`<size>`は、特定のノード上でサポートされている整数値を使った最も小さなバイナリ表記です。たとえば、ノードが2048KiBと1048576KiBのページサイズをサポートしている場合、ノードはスケジュール可能なリソースとして、`hugepages-2Mi`と`hugepages-1Gi`の2つのリソースを公開します。CPUやメモリとは違い、huge pageはオーバーコミットをサポートしません。huge pageリソースをリクエストするときには、メモリやCPUリソースを同時にリクエストしなければならないことに注意してください。 + +1つのPodのspec内に書くことで、Podから複数のサイズのhuge pageを利用することもできます。その場合、すべてのボリュームマウントで`medium: HugePages-<hugepagesize>`という表記を使う必要があります。 + +```yaml +apiVersion: v1 +kind: Pod +metadata: + name: huge-pages-example +spec: + containers: + - name: example + image: fedora:latest + command: + - sleep + - inf + volumeMounts: + - mountPath: /hugepages-2Mi + name: hugepage-2mi + - mountPath: /hugepages-1Gi + name: hugepage-1gi + resources: + limits: + hugepages-2Mi: 100Mi + hugepages-1Gi: 2Gi + memory: 100Mi + requests: + memory: 100Mi + volumes: + - name: hugepage-2mi + emptyDir: + medium: HugePages-2Mi + - name: hugepage-1gi + emptyDir: + medium: HugePages-1Gi +``` + +Podで1種類のサイズのhuge pageをリクエストするときだけは、`medium: HugePages`という表記を使うこともできます。 + +```yaml +apiVersion: v1 +kind: Pod +metadata: + name: huge-pages-example +spec: + containers: + - name: example + image: fedora:latest + command: + - sleep + - inf + volumeMounts: + - mountPath: /hugepages + name: hugepage + resources: + limits: + hugepages-2Mi: 100Mi + memory: 100Mi + requests: + memory: 100Mi + volumes: + - name: hugepage + emptyDir: + medium: HugePages +``` + +- huge pageのrequestsはlimitsと等しくなければなりません。limitsを指定した場合にはこれがデフォルトですが、requestsを指定しなかった場合にはデフォルトではありません。 +- huge pageはコンテナのスコープで隔離されるため、各コンテナにはそれぞれのcgroupサンドボックスの中でcontainer specでリクエストされた通りのlimitが設定されます。 +- huge pageベースのEmptyDirボリュームは、Podがリクエストしたよりも大きなサイズのページメモリーを使用できません。 +- `shmget()`に`SHM_HUGETLB`を指定して取得したhuge pageを使用するアプリケーションは、`/proc/sys/vm/hugetlb_shm_group`に一致する補助グループ(supplemental group)を使用して実行する必要があります。 +- namespace内のhuge pageの使用量は、ResourceQuotaに対して`cpu`や`memory`のような他の計算リソースと同じように`hugepages-<size>`というトークンを使用することで制御できます。 +- 複数のサイズのhuge pageのサポートはフィーチャーゲートによる設定が必要です。{{< glossary_tooltip text="kubelet" term_id="kubelet" >}}と{{< glossary_tooltip text="kube-apiserver" term_id="kube-apiserver" >}}上で、`HugePageStorageMediumSize`[フィーチャーゲート](/ja/docs/reference/command-line-tools-reference/feature-gates/)を使用すると有効にできます(`--feature-gates=HugePageStorageMediumSize=true`)。 diff --git a/content/ja/docs/tasks/run-application/force-delete-stateful-set-pod.md b/content/ja/docs/tasks/run-application/force-delete-stateful-set-pod.md index efa6f5a6ae..7d6830a50f 100644 --- a/content/ja/docs/tasks/run-application/force-delete-stateful-set-pod.md +++ b/content/ja/docs/tasks/run-application/force-delete-stateful-set-pod.md @@ -21,7 +21,7 @@ weight: 70 StatefulSetの通常の操作では、StatefulSet Podを強制的に削除する必要は**まったく**ありません。StatefulSetコントローラーは、StatefulSetのメンバーの作成、スケール、削除を行います。それは序数0からN-1までの指定された数のPodが生きていて準備ができていることを保証しようとします。StatefulSetは、クラスター内で実行されている特定のIDを持つ最大1つのPodがいつでも存在することを保証します。これは、StatefulSetによって提供される*最大1つの*セマンティクスと呼ばれます。 -手動による強制削除は、StatefulSetに固有の最大1つのセマンティクスに違反する可能性があるため、慎重に行う必要があります。StatefulSetを使用して、安定したネットワークIDと安定した記憶域を必要とする分散型およびクラスター型アプリケーションを実行できます。これらのアプリケーションは、固定IDを持つ固定数のメンバーのアンサンブルに依存する構成を持つことがよくあります。同じIDを持つ複数のメンバーを持つことは悲惨なことになり、データの損失につながる可能性があります（例：定足数ベースのシステムでのスプリットブレインシナリオ）。 +手動による強制削除は、StatefulSetに固有の最大1つのセマンティクスに違反する可能性があるため、慎重に行う必要があります。StatefulSetを使用して、安定したネットワークIDと安定した記憶域を必要とする分散型およびクラスター型アプリケーションを実行できます。これらのアプリケーションは、固定IDを持つ固定数のメンバーのアンサンブルに依存する構成を持つことがよくあります。同じIDを持つ複数のメンバーを持つことは悲惨なことになり、データの損失につながる可能性があります(例：定足数ベースのシステムでのスプリットブレインシナリオ)。 ## Podの削除 @@ -33,13 +33,13 @@ kubectl delete pods <pod> 上記がグレースフルターミネーションにつながるためには、`pod.Spec.TerminationGracePeriodSeconds`に0を指定しては**いけません**。`pod.Spec.TerminationGracePeriodSeconds`を0秒に設定することは安全ではなく、StatefulSet Podには強くお勧めできません。グレースフル削除は安全で、kubeletがapiserverから名前を削除する前に[Podが適切にシャットダウンする](/ja/docs/concepts/workloads/pods/pod/#termination-of-pods)ことを保証します。 -Kubernetes（バージョン1.5以降）は、Nodeにアクセスできないという理由だけでPodを削除しません。到達不能なNodeで実行されているPodは、[タイムアウト](/docs/admin/node/#node-condition)の後に`Terminating`または`Unknown`状態になります。到達不能なNode上のPodをユーザーが適切に削除しようとすると、Podはこれらの状態に入ることもあります。そのような状態のPodをapiserverから削除することができる唯一の方法は以下の通りです: +Kubernetes(バージョン1.5以降)は、Nodeにアクセスできないという理由だけでPodを削除しません。到達不能なNodeで実行されているPodは、[タイムアウト](/docs/admin/node/#node-condition)の後に`Terminating`または`Unknown`状態になります。到達不能なNode上のPodをユーザーが適切に削除しようとすると、Podはこれらの状態に入ることもあります。そのような状態のPodをapiserverから削除することができる唯一の方法は以下の通りです: * (ユーザーまたは[Node Controller](/docs/admin/node)によって)Nodeオブジェクトが削除されます。<br/> * 応答していないNodeのkubeletが応答を開始し、Podを終了してapiserverからエントリーを削除します。<br/> * ユーザーによりPodを強制削除します。 -推奨されるベストプラクティスは、1番目または2番目のアプローチを使用することです。Nodeが死んでいることが確認された（例えば、ネットワークから恒久的に切断された、電源が切られたなど）場合、Nodeオブジェクトを削除します。Nodeがネットワークパーティションに苦しんでいる場合は、これを解決するか、解決するのを待ちます。パーティションが回復すると、kubeletはPodの削除を完了し、apiserverでその名前を解放します。 +推奨されるベストプラクティスは、1番目または2番目のアプローチを使用することです。Nodeが死んでいることが確認された(例えば、ネットワークから恒久的に切断された、電源が切られたなど)場合、Nodeオブジェクトを削除します。Nodeがネットワークパーティションに苦しんでいる場合は、これを解決するか、解決するのを待ちます。パーティションが回復すると、kubeletはPodの削除を完了し、apiserverでその名前を解放します。 通常、PodがNode上で実行されなくなるか、管理者によってそのNodeが削除されると、システムは削除を完了します。あなたはPodを強制的に削除することでこれを無効にすることができます。 diff --git a/content/ja/docs/tasks/service-catalog/_index.md b/content/ja/docs/tasks/service-catalog/_index.md new file mode 100755 index 0000000000..a7d91e4ea7 --- /dev/null +++ b/content/ja/docs/tasks/service-catalog/_index.md @@ -0,0 +1,6 @@ +--- +title: "サービスカタログ" +description: サービスカタログ拡張APIをインストールする +weight: 150 +--- + diff --git a/content/ja/docs/tasks/service-catalog/install-service-catalog-using-sc.md b/content/ja/docs/tasks/service-catalog/install-service-catalog-using-sc.md new file mode 100644 index 0000000000..a0211e2a18 --- /dev/null +++ b/content/ja/docs/tasks/service-catalog/install-service-catalog-using-sc.md @@ -0,0 +1,68 @@ +--- +title: SCを使用したサービスカタログのインストール +content_type: task +--- + +<!-- overview --> +{{< glossary_definition term_id="service-catalog" length="all" prepend="サービスカタログは" >}} + +GCPの[Service Catalog Installer](https://github.com/GoogleCloudPlatform/k8s-service-catalog#installation)ツールを使うと、Kubernetesクラスター上にサービスカタログを簡単にインストール・アンインストールして、Google Cloudのプロジェクトに紐付けることもできます。 + +サービスカタログ自体は、Google Cloudだけではなく、どのような種類のマネージドサービスでも動作します。 + +## {{% heading "prerequisites" %}} + +* [サービスカタログ](/docs/concepts/service-catalog/)の基本概念を理解してください。 +* [Go 1.6+](https://golang.org/dl/)をインストールして、`GOPATH`を設定してください。 +* SSLに関するファイルを生成するために必要な[cfssl](https://github.com/cloudflare/cfssl)ツールをインストールしてください。 +* サービスカタログを使用するには、Kubernetesクラスターのバージョンが1.7以降である必要があります。 +* [kubectlのインストールおよびセットアップ](/ja/docs/tasks/tools/install-kubectl/)を参考に、v1.7以降のkubectlをインストールし、設定を行ってください。 +* サービスカタログをインストールするためには、kubectlのユーザーが*cluster-admin*ロールにバインドされている必要があります。正しくバインドされていることを確認するには、次のコマンドを実行します。 + + kubectl create clusterrolebinding cluster-admin-binding --clusterrole=cluster-admin --user=<user-name> + +<!-- steps --> +## ローカル環境に`sc`をインストールする + +インストーラーは、ローカルのコンピューター上で`sc`と呼ばれるCLIツールとして実行します。 + +`go get`を使用してインストールします。 + +```shell +go get github.com/GoogleCloudPlatform/k8s-service-catalog/installer/cmd/sc +``` + +これで、`sc`が`GOPATH/bin`ディレクトリー内にインストールされたはずです。 + +## Kubernetesクラスターにサービスカタログをインストールする + +まず、すべての依存関係がインストールされていることを確認します。次のコマンドを実行してください。 + +```shell +sc check +``` + +チェックが成功したら、次のように表示されるはずです。 + +``` +Dependency check passed. You are good to go. +``` + +次に、バックアップに使用したい`storageclass`を指定して、installコマンドを実行します。 + +```shell +sc install --etcd-backup-storageclass "standard" +``` + +## サービスカタログのアンインストール + +Kubernetesクラスターからサービスカタログをアンインストールしたい場合は、`sc`ツールを使って次のコマンドを実行します。 + +```shell +sc uninstall +``` + +## {{% heading "whatsnext" %}} + +* [サービスブローカーのサンプル](https://github.com/openservicebrokerapi/servicebroker/blob/master/gettingStarted.md#sample-service-brokers)を読む。 +* [kubernetes-incubator/service-catalog](https://github.com/kubernetes-incubator/service-catalog)プロジェクトを探索する。 diff --git a/content/ja/docs/tasks/tls/_index.md b/content/ja/docs/tasks/tls/_index.md new file mode 100755 index 0000000000..42234c709e --- /dev/null +++ b/content/ja/docs/tasks/tls/_index.md @@ -0,0 +1,6 @@ +--- +title: "TLS" +weight: 100 +description: Transport Layer Security(TLS)を使用して、クラスター内のトラフィックを保護する方法について理解します。 +--- + diff --git a/content/ja/docs/tasks/tls/certificate-rotation.md b/content/ja/docs/tasks/tls/certificate-rotation.md new file mode 100644 index 0000000000..1d2026962c --- /dev/null +++ b/content/ja/docs/tasks/tls/certificate-rotation.md @@ -0,0 +1,41 @@ +--- +title: Kubeletの証明書のローテーションを設定する +content_type: task +--- + +<!-- overview --> +このページでは、kubeletの証明書のローテーションを設定する方法を説明します。 + +{{< feature-state for_k8s_version="v1.8" state="beta" >}} + +## {{% heading "prerequisites" %}} + +* Kubernetesはバージョン1.8.0以降である必要があります。 + +<!-- steps --> + +## 概要 + +kubeletは、Kubernetes APIへの認証のために証明書を使用します。デフォルトでは、証明書は1年間の有効期限付きで発行されるため、頻繁に更新する必要はありません。 + +Kubernetes 1.8にはベータ機能の[kubelet certificate rotation](/docs/reference/command-line-tools-reference/kubelet-tls-bootstrapping/)が含まれているため、現在の証明書の有効期限が近づいたときに自動的に新しい鍵を生成して、Kubernetes APIに新しい証明書をリクエストできます。新しい証明書が利用できるようになると、Kubernetes APIへの接続の認証に利用されます。 + +## クライアント証明書のローテーションを有効にする + +`kubelet`プロセスは`--rotate-certificates`という引数を受け付けます。この引数によって、現在使用している証明書の有効期限が近づいたときに、kubeletが自動的に新しい証明書をリクエストするかどうかを制御できます。証明書のローテーションはベータ機能であるため、`--feature-gates=RotateKubeletClientCertificate=true`を使用してフィーチャーフラグを有効にする必要もあります。 + +`kube-controller-manager`プロセスは、`--experimental-cluster-signing-duration`という引数を受け付け、この引数で証明書が発行される期間を制御できます。 + +## 証明書のローテーションの設定を理解する + +kubeletが起動すると、ブートストラップが設定されている場合(`--bootstrap-kubeconfig`フラグを使用した場合)、初期証明書を使用してKubernetes APIに接続して、証明書署名リクエスト(certificate signing request、CSR)を発行します。証明書署名リクエストのステータスは、次のコマンドで表示できます。 + +```sh +kubectl get csr +``` + +ノード上のkubeletから発行された証明書署名リクエストは、初めは`Pending`状態です。証明書署名リクエストが特定の条件を満たすと、コントローラーマネージャーに自動的に承認され、`Approved`状態になります。次に、コントローラーマネージャーは`--experimental-cluster-signing-duration`パラメーターで指定された有効期限で発行された証明書に署名を行い、署名された証明書が証明書署名リクエストに添付されます。 + +kubeletは署名された証明書をKubernetes APIから取得し、ディスク上の`--cert-dir`で指定された場所に書き込みます。その後、kubeletは新しい証明書を使用してKubernetes APIに接続するようになります。 + +署名された証明書の有効期限が近づくと、kubeletはKubernetes APIを使用して新しい証明書署名リクエストを自動的に発行します。再び、コントローラーマネージャーは証明書のリクエストを自動的に承認し、署名された証明書を証明書署名リクエストに添付します。kubeletは新しい署名された証明書をKubernetes APIから取得してディスクに書き込みます。その後、kubeletは既存のコネクションを更新して、新しい証明書でKubernetes APIに再接続します。 diff --git a/content/ja/docs/tasks/tools/install-kubectl.md b/content/ja/docs/tasks/tools/install-kubectl.md index 7c0d08d9c5..e468404469 100644 --- a/content/ja/docs/tasks/tools/install-kubectl.md +++ b/content/ja/docs/tasks/tools/install-kubectl.md @@ -5,7 +5,7 @@ weight: 10 card: name: tasks weight: 20 - title: Install kubectl + title: kubectlのインストール --- <!-- overview --> @@ -143,7 +143,7 @@ macOSで[Homebrew](https://brew.sh/)パッケージマネージャーを使用 1. インストールコマンドを実行してください: ``` - brew install kubectl + brew install kubectl ``` または @@ -186,7 +186,7 @@ macOSで[MacPorts](https://macports.org/)パッケージマネージャーを使 curl -LO https://storage.googleapis.com/kubernetes-release/release/{{< param "fullversion" >}}/bin/windows/amd64/kubectl.exe ``` - 最新の安定版を入手する際は（たとえばスクリプトで使用する場合）、[https://storage.googleapis.com/kubernetes-release/release/stable.txt](https://storage.googleapis.com/kubernetes-release/release/stable.txt)を参照してください。 + 最新の安定版を入手する際は(たとえばスクリプトで使用する場合)、[https://storage.googleapis.com/kubernetes-release/release/stable.txt](https://storage.googleapis.com/kubernetes-release/release/stable.txt)を参照してください。 2. バイナリをPATHに追加します 3. `kubectl`のバージョンがダウンロードしたものと同じであることを確認してください: @@ -202,7 +202,7 @@ macOSで[MacPorts](https://macports.org/)パッケージマネージャーを使 Windowsで[Powershell Gallery](https://www.powershellgallery.com/)パッケージマネージャーを使用していれば、Powershellでkubectlをインストールおよびアップデートすることもできます。 -1. インストールコマンドを実行してください（必ず`DownloadLocation`を指定してください）: +1. インストールコマンドを実行してください(必ず`DownloadLocation`を指定してください): ``` Install-Script -Name install-kubectl -Scope CurrentUser -Force @@ -301,7 +301,7 @@ URLのレスポンスが表示されている場合は、kubectlはクラスタ The connection to the server <server-name:port> was refused - did you specify the right host or port? ``` -たとえば、ラップトップ上（ローカル環境）でKubernetesクラスターを起動するような場合、Minikubeなどのツールを最初にインストールしてから、上記のコマンドを再実行する必要があります。 +たとえば、ラップトップ上(ローカル環境)でKubernetesクラスターを起動するような場合、Minikubeなどのツールを最初にインストールしてから、上記のコマンドを再実行する必要があります。 kubectl cluster-infoがURLレスポンスを返したにもかかわらずクラスターにアクセスできない場合は、次のコマンドで設定が正しいことを確認してください: @@ -315,7 +315,7 @@ kubectl cluster-info dump kubectlはBashおよびZshの自動補完を提供しています。これにより、入力を大幅に削減することができます。 -以下にBash（LinuxとmacOSの違いも含む）およびZshの自動補完の設定手順を示します。 +以下にBash(LinuxとmacOSの違いも含む)およびZshの自動補完の設定手順を示します。 {{< tabs name="kubectl_autocompletion" >}} @@ -325,11 +325,11 @@ kubectlはBashおよびZshの自動補完を提供しています。これによ Bashにおけるkubectlの補完スクリプトは`kubectl completion bash`コマンドで生成できます。シェル内で補完スクリプトをsourceすることでkubectlの自動補完が有効になります。 -ただし、補完スクリプトは[**bash-completion**](https://github.com/scop/bash-completion)に依存しているため、このソフトウェアを最初にインストールしておく必要があります（`type _init_completion`を実行することで、bash-completionがすでにインストールされていることを確認できます）。 +ただし、補完スクリプトは[**bash-completion**](https://github.com/scop/bash-completion)に依存しているため、このソフトウェアを最初にインストールしておく必要があります(`type _init_completion`を実行することで、bash-completionがすでにインストールされていることを確認できます)。 ### bash-completionをインストールする -bash-completionは多くのパッケージマネージャーから提供されています（[こちら](https://github.com/scop/bash-completion#installation)を参照してください）。`apt-get install bash-completion`または`yum install bash-completion`などでインストールできます。 +bash-completionは多くのパッケージマネージャーから提供されています([こちら](https://github.com/scop/bash-completion#installation)を参照してください)。`apt-get install bash-completion`または`yum install bash-completion`などでインストールできます。 上記のコマンドでbash-completionの主要スクリプトである`/usr/share/bash-completion/bash_completion`が作成されます。パッケージマネージャーによっては、このファイルを`~/.bashrc`にて手動でsourceする必要があります。 @@ -382,7 +382,7 @@ Bashにおけるkubectlの補完スクリプトは`kubectl completion bash`コ ただし、補完スクリプトは[**bash-completion**](https://github.com/scop/bash-completion)に依存しているため、事前にインストールする必要があります。 {{< warning>}} -bash-completionにはv1とv2のバージョンがあり、v1はBash 3.2（macOSのデフォルト）用で、v2はBash 4.1以降向けです。kubectlの補完スクリプトはbash-completionのv1とBash 3.2では正しく**動作しません**。**bash-completion v2**および**Bash 4.1**が必要になります。したがって、macOSで正常にkubectlの補完を使用するには、Bash 4.1以降をインストールする必要があります([*手順*](https://itnext.io/upgrading-bash-on-macos-7138bd1066ba))。以下の手順では、Bash4.1以降（Bashのバージョンが4.1またはそれより新しいことを指します）を使用することを前提とします。 +bash-completionにはv1とv2のバージョンがあり、v1はBash 3.2(macOSのデフォルト)用で、v2はBash 4.1以降向けです。kubectlの補完スクリプトはbash-completionのv1とBash 3.2では正しく**動作しません**。**bash-completion v2**および**Bash 4.1**が必要になります。したがって、macOSで正常にkubectlの補完を使用するには、Bash 4.1以降をインストールする必要があります([*手順*](https://itnext.io/upgrading-bash-on-macos-7138bd1066ba))。以下の手順では、Bash4.1以降(Bashのバージョンが4.1またはそれより新しいことを指します)を使用することを前提とします。 {{< /warning >}} ### bashのアップグレード @@ -410,7 +410,7 @@ Homebrewは通常、`/usr/local/bin/bash`にインストールします。 ### bash-completionをインストールする {{< note >}} -前述のとおり、この手順ではBash 4.1以降であることが前提のため、bash-completion v2をインストールすることになります（これとは逆に、Bash 3.2およびbash-completion v1の場合ではkubectlの補完は動作しません）。 +前述のとおり、この手順ではBash 4.1以降であることが前提のため、bash-completion v2をインストールすることになります(これとは逆に、Bash 3.2およびbash-completion v1の場合ではkubectlの補完は動作しません)。 {{< /note >}} `type _init_completion`を実行することで、bash-completionがすでにインストールされていることを確認できます。ない場合は、Homebrewを使用してインストールすることもできます: @@ -452,7 +452,7 @@ export BASH_COMPLETION_COMPAT_DIR="/usr/local/etc/bash_completion.d" echo 'complete -F __start_kubectl k' >>~/.bashrc ``` -- kubectlをHomwbrewでインストールした場合（[前述](#homebrewを使用してmacosへインストールする)のとおり）、kubectlの補完スクリプトはすでに`/usr/local/etc/bash_completion.d/kubectl`に格納されているでしょう。この場合、なにも操作する必要はありません。 +- kubectlをHomwbrewでインストールした場合([前述](#homebrewを使用してmacosへインストールする)のとおり)、kubectlの補完スクリプトはすでに`/usr/local/etc/bash_completion.d/kubectl`に格納されているでしょう。この場合、なにも操作する必要はありません。 {{< note >}} Homebrewでインストールしたbash-completion v2は`BASH_COMPLETION_COMPAT_DIR`ディレクトリ内のすべてのファイルをsourceするため、後者の2つの方法が機能します。 diff --git a/content/ja/docs/tasks/tools/install-minikube.md b/content/ja/docs/tasks/tools/install-minikube.md index 51e6cd8417..30b15718ca 100644 --- a/content/ja/docs/tasks/tools/install-minikube.md +++ b/content/ja/docs/tasks/tools/install-minikube.md @@ -29,7 +29,7 @@ grep -E --color 'vmx|svm' /proc/cpuinfo ``` sysctl -a | grep -E --color 'machdep.cpu.features|VMX' ``` -出力に`VMX`が表示されている場合（色付けされているはずです）、VT-x機能がマシンで有効になっています。 +出力に`VMX`が表示されている場合(色付けされているはずです)、VT-x機能がマシンで有効になっています。 {{% /tab %}} {{% tab name="Windows" %}} diff --git a/content/ja/docs/tutorials/configuration/configure-redis-using-configmap.md b/content/ja/docs/tutorials/configuration/configure-redis-using-configmap.md index d09929b9ee..0e2b699e89 100644 --- a/content/ja/docs/tutorials/configuration/configure-redis-using-configmap.md +++ b/content/ja/docs/tutorials/configuration/configure-redis-using-configmap.md @@ -89,7 +89,7 @@ pod/redis 1/1 Running 0 52s `kubectl exec`を使ってPodに入り、`redis-cli`ツールを実行して設定が正しく適用されたことを確認してください: ```shell -kubectl exec -it redis redis-cli +kubectl exec -it redis -- redis-cli 127.0.0.1:6379> CONFIG GET maxmemory 1) "maxmemory" 2) "2097152" diff --git a/content/ja/docs/tutorials/kubernetes-basics/_index.html b/content/ja/docs/tutorials/kubernetes-basics/_index.html index 99174c2b21..3f31b8d5bc 100644 --- a/content/ja/docs/tutorials/kubernetes-basics/_index.html +++ b/content/ja/docs/tutorials/kubernetes-basics/_index.html @@ -39,7 +39,7 @@ card: <div class="row"> <div class="col-md-9"> - <h2>Kubernetesはどんなことができるの?</h2> + <h2>Kubernetesはどんなことができるの？</h2> <p>モダンなWebサービスでは、ユーザはアプリケーションが24時間365日利用可能であることを期待しており、開発者はそれらのアプリケーションの新しいバージョンを1日に数回デプロイすることを期待しています。コンテナ化は、パッケージソフトウェアがこれらの目標を達成するのを助け、アプリケーションをダウンタイムなしで簡単かつ迅速にリリース、アップデートできるようにします。Kubernetesを使用すると、コンテナ化されたアプリケーションをいつでもどこでも好きなときに実行できるようになり、それらが機能するために必要なリソースとツールを見つけやすくなります。Kubernetesは、コンテナオーケストレーションにおけるGoogleのこれまでの経験と、コミュニティから得られた最善のアイデアを組み合わせて設計された、プロダクションレディなオープンソースプラットフォームです。</p> </div> </div> diff --git a/content/ja/docs/tutorials/kubernetes-basics/deploy-app/deploy-interactive.html b/content/ja/docs/tutorials/kubernetes-basics/deploy-app/deploy-interactive.html index c9d25cd3fb..9b59db721b 100644 --- a/content/ja/docs/tutorials/kubernetes-basics/deploy-app/deploy-interactive.html +++ b/content/ja/docs/tutorials/kubernetes-basics/deploy-app/deploy-interactive.html @@ -20,7 +20,7 @@ weight: 20 <div class="row"> <div class="col-md-12"> <p> - Podは、Kubernetesアプリケーションの基本的な実行単位です。各Podは、クラスターで実行されているワークロードの一部を表します。<a href="/ja/docs/concepts/workloads/pods/pod-overview/#understanding-pods">Podの詳細はこちらです。</a>。 + Podは、Kubernetesアプリケーションの基本的な実行単位です。各Podは、クラスターで実行されているワークロードの一部を表します。<a href="/ja/docs/concepts/workloads/pods/pod-overview/#understanding-pods">Podの詳細はこちらです</a>。 </p> </div> </div> diff --git a/content/ja/docs/tutorials/services/_index.md b/content/ja/docs/tutorials/services/_index.md new file mode 100755 index 0000000000..2a2a0eb7b6 --- /dev/null +++ b/content/ja/docs/tutorials/services/_index.md @@ -0,0 +1,5 @@ +--- +title: "Service" +weight: 70 +--- + diff --git a/content/ja/docs/tutorials/services/source-ip.md b/content/ja/docs/tutorials/services/source-ip.md new file mode 100644 index 0000000000..69c626d532 --- /dev/null +++ b/content/ja/docs/tutorials/services/source-ip.md @@ -0,0 +1,421 @@ +--- +title: 送信元IPを使用する +content_type: tutorial +min-kubernetes-server-version: v1.5 +--- + +<!-- overview --> + +Kubernetesクラスター内で実行されているアプリケーションは、Serviceという抽象化を経由して、他のアプリケーションや外の世界との発見や通信を行います。このドキュメントでは、異なる種類のServiceに送られたパケットの送信元IPに何が起こるのか、そして必要に応じてこの振る舞いを切り替える方法について説明します。 + +## {{% heading "prerequisites" %}} + +### 用語 + +このドキュメントでは、以下の用語を使用します。 + +{{< comment >}} +If localizing this section, link to the equivalent Wikipedia pages for +the target localization. +{{< /comment >}} + +[NAT](https://ja.wikipedia.org/wiki/%E3%83%8D%E3%83%83%E3%83%88%E3%83%AF%E3%83%BC%E3%82%AF%E3%82%A2%E3%83%89%E3%83%AC%E3%82%B9%E5%A4%89%E6%8F%9B) +: ネットワークアドレス変換(network address translation) + +[送信元NAT](https://en.wikipedia.org/wiki/Network_address_translation#SNAT) +: パケットの送信元のIPを置換します。このページでは、通常ノードのIPアドレスを置換することを意味します。 + +[送信先NAT](https://en.wikipedia.org/wiki/Network_address_translation#DNAT) +: パケットの送信先のIPを置換します。このページでは、通常{{< glossary_tooltip term_id="pod" >}}のIPアドレスを置換することを意味します。 + +[VIP](/ja/docs/concepts/services-networking/service/#virtual-ips-and-service-proxies) +: Kubernetes内のすべての{{< glossary_tooltip text="Service" term_id="service" >}}などに割り当てられる仮想IPアドレス(virtual IP address)です。 + +[kube-proxy](/ja/docs/concepts/services-networking/service/#virtual-ips-and-service-proxies) +: すべてのノード上でServiceのVIPを管理するネットワークデーモンです。 + +### 前提条件 + +{{< include "task-tutorial-prereqs.md" >}} + +以下の例では、HTTPヘッダー経由で受け取ったリクエストの送信元IPをエコーバックする、小さなnginxウェブサーバーを使用します。次のコマンドでウェブサーバーを作成できます。 + +```shell +kubectl create deployment source-ip-app --image=k8s.gcr.io/echoserver:1.4 +``` + +出力は次のようになります。 + +``` +deployment.apps/source-ip-app created +``` + +## {{% heading "objectives" %}} + +* 単純なアプリケーションを様々な種類のService経由で公開する +* それぞれの種類のServiceがどのように送信元IPのNATを扱うかを理解する +* 送信元IPを保持することに関わるトレードオフを理解する + +<!-- lessoncontent --> + +## `Type=ClusterIP`を使用したServiceでの送信元IP + +kube-proxyが[iptablesモード](/ja/docs/concepts/services-networking/service/#proxy-mode-iptables)(デフォルト)で実行されている場合、クラスター内部からClusterIPに送られたパケットに送信元のNATが行われることは決してありません。kube-proxyが実行されているノード上で`http://localhost:10249/proxyMode`にリクエストを送って、kube-proxyのモードを問い合わせてみましょう。 + +```console +kubectl get nodes +``` + +出力は次のようになります。 + +``` +NAME STATUS ROLES AGE VERSION +kubernetes-node-6jst Ready <none> 2h v1.13.0 +kubernetes-node-cx31 Ready <none> 2h v1.13.0 +kubernetes-node-jj1t Ready <none> 2h v1.13.0 +``` + +これらのノードの1つでproxyモードを取得します(kube-proxyはポート10249をlistenしています)。 + +```shell +# このコマンドは、問い合わせを行いたいノード上のシェルで実行してください。 +curl http://localhost:10249/proxyMode +``` + +出力は次のようになります。 + +``` +iptables +``` + +source IPアプリのServiceを作成することで、送信元IPが保持されているかテストできます。 + +```shell +kubectl expose deployment source-ip-app --name=clusterip --port=80 --target-port=8080 +``` + +出力は次のようになります。 + +``` +service/clusterip exposed +``` +```shell +kubectl get svc clusterip +``` + +出力は次のようになります。 + +``` +NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE +clusterip ClusterIP 10.0.170.92 <none> 80/TCP 51s +``` + +そして、同じクラスター上のPodから`ClusterIP`にアクセスします。 + +```shell +kubectl run busybox -it --image=busybox --restart=Never --rm +``` + +出力は次のようになります。 + +``` +Waiting for pod default/busybox to be running, status is Pending, pod ready: false +If you don't see a command prompt, try pressing enter. + +``` + +これで、Podの内部でコマンドが実行できます。 + +```shell +# このコマンドは、"kubectl run" のターミナルの内部で実行してください +ip addr +``` +``` +1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue + link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 + inet 127.0.0.1/8 scope host lo + valid_lft forever preferred_lft forever + inet6 ::1/128 scope host + valid_lft forever preferred_lft forever +3: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1460 qdisc noqueue + link/ether 0a:58:0a:f4:03:08 brd ff:ff:ff:ff:ff:ff + inet 10.244.3.8/24 scope global eth0 + valid_lft forever preferred_lft forever + inet6 fe80::188a:84ff:feb0:26a5/64 scope link + valid_lft forever preferred_lft forever +``` + +そして、`wget`を使用してローカルのウェブサーバーに問い合わせます。 + +```shell +# 10.0.170.92 の部分をウェブサーバーのPodのIPv4アドレスに置き換えてください +wget -qO - 10.0.170.92 +``` +``` +CLIENT VALUES: +client_address=10.244.3.8 +command=GET +... +``` + +`client_address`は常にクライアントのPodのIPアドレスになります。これは、クライアントのPodとサーバーのPodが同じノード内にあっても異なるノードにあっても変わりません。 + +## `Type=NodePort`を使用したServiceでの送信元IP + +[`Type=NodePort`](/ja/docs/concepts/services-networking/service/#nodeport)を使用したServiceに送られたパケットは、デフォルトで送信元のNATが行われます。`NodePort` Serviceを作ることでテストできます。 + +```shell +kubectl expose deployment source-ip-app --name=nodeport --port=80 --target-port=8080 --type=NodePort +``` + +出力は次のようになります。 + +``` +service/nodeport exposed +``` + +```shell +NODEPORT=$(kubectl get -o jsonpath="{.spec.ports[0].nodePort}" services nodeport) +NODES=$(kubectl get nodes -o jsonpath='{ $.items[*].status.addresses[?(@.type=="ExternalIP")].address }') +``` + +クラウドプロバイダーで実行する場合、上に示した`nodes:nodeport`に対してファイアウォールのルールを作成する必要があるかもしれません。それでは、上で割り当てたノードポート経由で、クラスターの外部からServiceにアクセスしてみましょう。 + +```shell +for node in $NODES; do curl -s $node:$NODEPORT | grep -i client_address; done +``` + +出力は次のようになります。 + +``` +client_address=10.180.1.1 +client_address=10.240.0.5 +client_address=10.240.0.3 +``` + +これらは正しいクライアントIPではなく、クラスターのinternal IPであることがわかります。ここでは、次のようなことが起こっています。 + +* クライアントがパケットを`node2:nodePort`に送信する +* `node2`は、パケット内の送信元IPアドレスを自ノードのIPアドレスに置換する(SNAT) +* `node2`は、パケット内の送信先IPアドレスをPodのIPアドレスに置換する +* パケットはnode1にルーティングされ、endpointにルーティングされる +* Podからの応答がnode2にルーティングされて戻ってくる +* Podからの応答がクライアントに送り返される + +図で表すと次のようになります。 + +``` + client + \ ^ + \ \ + v \ + node 1 <--- node 2 + | ^ SNAT + | | ---> + v | + endpoint +``` + +クライアントのIPが失われることを回避するために、Kubernetesには[クライアントの送信元IPを保持する](/docs/tasks/access-application-cluster/create-external-load-balancer/#preserving-the-client-source-ip)機能があります。`service.spec.externalTrafficPolicy`の値を`Local`に設定すると、kube-proxyはローカルに存在するエンドポイントへのプロキシーリクエストだけをプロキシーし、他のノードへはトラフィックを転送しなくなります。このアプローチでは、オリジナルの送信元IPアドレスが保持されます。ローカルにエンドポイントが存在しない場合には、そのノードに送信されたパケットは損失します。そのため、エンドポイントに到達するパケットに適用する可能性のあるパケット処理ルールでは、送信元IPが正しいことを信頼できます。 + +次のようにして`service.spec.externalTrafficPolicy`フィールドを設定します。 + +```shell +kubectl patch svc nodeport -p '{"spec":{"externalTrafficPolicy":"Local"}}' +``` + +出力は次のようになります。 + +``` +service/nodeport patched +``` + +そして、再度テストしてみます。 + +```shell +for node in $NODES; do curl --connect-timeout 1 -s $node:$NODEPORT | grep -i client_address; done +``` + +出力は次のようになります。 + +``` +client_address=198.51.100.79 +``` + +今度は、*正しい*クライアントIPが含まれる応答が1つだけ得られました。これは、エンドポイントのPodが実行されているノードから来たものです。 + +ここでは、次のようなことが起こっています。 + +* クライアントがパケットをエンドポイントが存在しない`node2:nodePort`に送信する +* パケットが損失する +* クライアントがパケットをエンドポイントが*存在する*`node1:nodePort`に送信する +* node1は、正しい送信元IPを持つパケットをエンドポイントにルーティングする + +図で表すと次のようになります。 + +``` + client + ^ / \ + / / \ + / v X + node 1 node 2 + ^ | + | | + | v + endpoint +``` + +## `Type=LoadBalancer`を使用したServiceでの送信元IP + +[`Type=LoadBalancer`](/ja/docs/concepts/services-networking/service/#loadbalancer)を使用したServiceに送られたパケットは、デフォルトでは送信元のNATは行われません。`Ready`状態にあるすべてのスケジュール可能なKubernetesのNodeは、ロードバランサーからのトラフィックを受付可能であるためです。そのため、エンドポイントが存在しないノードにパケットが到達した場合、システムはエンドポイントが*存在する*ノードにパケットをプロシキーします。このとき、(前のセクションで説明したように)パケットの送信元IPがノードのIPに置換されます。 + +ロードバランサー経由でsource-ip-appを公開することで、これをテストできます。 + +```shell +kubectl expose deployment source-ip-app --name=loadbalancer --port=80 --target-port=8080 --type=LoadBalancer +``` + +出力は次のようになります。 + +``` +service/loadbalancer exposed +``` + +ServiceのIPアドレスを表示します。 + +```console +kubectl get svc loadbalancer +``` + +出力は次のようになります。 + +``` +NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE +loadbalancer LoadBalancer 10.0.65.118 203.0.113.140 80/TCP 5m +``` + +次に、Serviceのexternal-ipにリクエストを送信します。 + +```shell +curl 203.0.113.140 +``` + +出力は次のようになります。 + +``` +CLIENT VALUES: +client_address=10.240.0.5 +... +``` + +しかし、Google Kubernetes EngineやGCE上で実行している場合、同じ`service.spec.externalTrafficPolicy`フィールドを`Local`に設定すると、ロードバランサーからのトラフィックを受け付け可能なノードのリストから、Serviceエンドポイントが*存在しない*ノードが強制的に削除されます。この動作は、ヘルスチェックを意図的に失敗させることによって実現されています。 + +図で表すと次のようになります。 + +``` + client + | + lb VIP + / ^ + v / +ヘルスチェック ---> node 1 node 2 <--- ヘルスチェック + 200 <--- ^ | ---> 500 + | V + endpoint +``` + +アノテーションを設定することで動作をテストできます。 + +```shell +kubectl patch svc loadbalancer -p '{"spec":{"externalTrafficPolicy":"Local"}}' +``` + +Kubernetesにより割り当てられた`service.spec.healthCheckNodePort`フィールドをすぐに確認します。 + +```shell +kubectl get svc loadbalancer -o yaml | grep -i healthCheckNodePort +``` + +出力は次のようになります。 + +```yaml + healthCheckNodePort: 32122 +``` + +`service.spec.healthCheckNodePort`フィールドは、`/healthz`でhealth checkを配信しているすべてのノード上のポートを指しています。次のコマンドでテストできます。 + +```shell +kubectl get pod -o wide -l run=source-ip-app +``` + +出力は次のようになります。 + +``` +NAME READY STATUS RESTARTS AGE IP NODE +source-ip-app-826191075-qehz4 1/1 Running 0 20h 10.180.1.136 kubernetes-node-6jst +``` + +`curl`を使用して、さまざまなノード上の`/healthz`エンドポイントからデータを取得します。 + +```shell +# このコマンドは選んだノードのローカル上で実行してください +curl localhost:32122/healthz +``` +``` +1 Service Endpoints found +``` + +ノードが異なると、得られる結果も異なる可能性があります。 + +```shell +# このコマンドは、選んだノード上でローカルに実行してください +curl localhost:32122/healthz +``` +``` +No Service Endpoints Found +``` + +{{< glossary_tooltip text="コントロールプレーン" term_id="control-plane" >}}上で実行中のコントローラーは、クラウドのロードバランサーを割り当てる責任があります。同じコントローラーは、各ノード上のポートやパスを指すHTTPのヘルスチェックも割り当てます。エンドポイントが存在しない2つのノードがヘルスチェックに失敗するまで約10秒待った後、`curl`を使用してロードバランサーのIPv4アドレスに問い合わせます。 + +```shell +curl 203.0.113.140 +``` + +出力は次のようになります。 + +``` +CLIENT VALUES: +client_address=198.51.100.79 +... +``` + +## クロスプラットフォームのサポート + +`Type=LoadBalancer`を使用したServiceで送信元IPを保持する機能を提供しているのは一部のクラウドプロバイダだけです。実行しているクラウドプロバイダによっては、以下のように異なる方法でリクエストを満たす場合があります。 + +1. クライアントとのコネクションをプロキシーが終端し、ノードやエンドポイントとの接続には新しいコネクションが開かれる。このような場合、送信元IPは常にクラウドのロードバランサーのものになり、クライアントのIPにはなりません。 + +2. クライアントからロードバランサーのVIPに送信されたリクエストが、中間のプロキシーではなく、クライアントの送信元IPとともにノードまで到達するようなパケット転送が使用される。 + +1つめのカテゴリーのロードバランサーの場合、真のクライアントIPと通信するために、 HTTPの[Forwarded](https://tools.ietf.org/html/rfc7239#section-5.2)ヘッダーや[X-FORWARDED-FOR](https://ja.wikipedia.org/wiki/X-Forwarded-For)ヘッダー、[proxy protocol](http://www.haproxy.org/download/1.5/doc/proxy-protocol.txt)などの、ロードバランサーとバックエンドの間で合意されたプロトコルを使用する必要があります。2つ目のカテゴリーのロードバランサーの場合、Serviceの`service.spec.healthCheckNodePort`フィールドに保存されたポートを指すHTTPのヘルスチェックを作成することで、上記の機能を活用できます。 + +## {{% heading "cleanup" %}} + +Serviceを削除します。 + +```shell +kubectl delete svc -l run=source-ip-app +``` + +Deployment、ReplicaSet、Podを削除します。 + +```shell +kubectl delete deployment source-ip-app +``` + +## {{% heading "whatsnext" %}} + +* [Service経由でアプリケーションに接続する](/ja/docs/concepts/services-networking/connect-applications-service/)方法についてさらに学ぶ。 +* [External Load Balancerを作成する](/docs/tasks/access-application-cluster/create-external-load-balancer/)方法について学ぶ。 + + diff --git a/content/ja/docs/tutorials/stateful-application/_index.md b/content/ja/docs/tutorials/stateful-application/_index.md new file mode 100755 index 0000000000..421915d42c --- /dev/null +++ b/content/ja/docs/tutorials/stateful-application/_index.md @@ -0,0 +1,5 @@ +--- +title: "ステートフルアプリケーション" +weight: 50 +--- + diff --git a/content/ja/docs/tutorials/stateful-application/basic-stateful-set.md b/content/ja/docs/tutorials/stateful-application/basic-stateful-set.md new file mode 100644 index 0000000000..d8a0acbdf6 --- /dev/null +++ b/content/ja/docs/tutorials/stateful-application/basic-stateful-set.md @@ -0,0 +1,1026 @@ +--- +title: StatefulSetの基本 +content_type: tutorial +weight: 10 +--- + +<!-- overview --> +このチュートリアルでは、{{< glossary_tooltip text="StatefulSet" term_id="statefulset" >}}を使用したアプリケーションを管理するための基本を説明します。StatefulSetのPodを作成、削除、スケール、そして更新する方法について紹介します。 + +## {{% heading "prerequisites" %}} + +このチュートリアルを始める前に、以下のKubernetesの概念について理解しておく必要があります。 + +* [Pod](/ja/docs/concepts/workloads/pods/) +* [Cluster DNS](/ja/docs/concepts/services-networking/dns-pod-service/) +* [Headless Service](/ja/docs/concepts/services-networking/service/#headless-services) +* [PersistentVolume](/ja/docs/concepts/storage/persistent-volumes/) +* [PersistentVolumeのプロビジョニング](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/staging/persistent-volume-provisioning/) +* [StatefulSet](/ja/docs/concepts/workloads/controllers/statefulset/) +* [kubectl](/docs/reference/kubectl/kubectl/)コマンドラインツール + +{{< note >}} +このチュートリアルでは、クラスターがPersistentVolumeの動的なプロビジョニングが行われるように設定されていることを前提としています。クラスターがそのように設定されていない場合、チュートリアルを始める前に1GiBのボリュームを2つ手動でプロビジョニングする必要があります。 +{{< /note >}} + +## {{% heading "objectives" %}} + +StatefulSetはステートフルアプリケーションや分散システムで使用するために存在します。しかし、Kubernetes上のステートフルアプリケーションや分散システムは、広範で複雑なトピックです。StatefulSetの基本的な機能を示すという目的のため、また、ステートフルアプリケーションを分散システムと混同しないようにするために、ここでは、Statefulsetを使用する単純なウェブアプリケーションのデプロイを行います。 + +このチュートリアルを終えると、以下のことが理解できるようになります。 + +* StatefulSetの作成方法 +* StatefulSetがどのようにPodを管理するのか +* StatefulSetの削除方法 +* StatefulSetのスケール方法 +* StatefulSetが管理するPodの更新方法 + +<!-- lessoncontent --> + +## StatefulSetを作成する {#ordered-pod-creation} + +はじめに、以下の例を使ってStatefulSetを作成しましょう。これは、コンセプトの[StatefulSet](/ja/docs/concepts/workloads/controllers/statefulset/)のページで使ったものと同じような例です。`nginx`という[headless Service](/ja/docs/concepts/services-networking/service/#headless-services)を作成し、`web`というStatefulSet内のPodのIPアドレスを公開します。 + +{{< codenew file="application/web/web.yaml" >}} + +上の例をダウンロードして、`web.yaml`という名前で保存します。 + +ここでは、ターミナルウィンドウを2つ使う必要があります。1つ目のターミナルでは、[`kubectl get`](/ja/docs/reference/generated/kubectl/kubectl-commands/#get)を使って、StatefulSetのPodの作成を監視します。 + +```shell +kubectl get pods -w -l app=nginx +``` + +2つ目のターミナルでは、[`kubectl apply`](/ja/docs/reference/generated/kubectl/kubectl-commands/#apply)を使って、`web.yaml`に定義されたheadless ServiceとStatefulSetを作成します。 + +```shell +kubectl apply -f web.yaml +``` +``` +service/nginx created +statefulset.apps/web created +``` + +上のコマンドを実行すると、2つのPodが作成され、それぞれのPodで[NGINX](https://www.nginx.com)ウェブサーバーが実行されます。`nginx`Serviceを取得してみましょう。 +```shell +kubectl get service nginx +``` +``` +NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE +nginx ClusterIP None <none> 80/TCP 12s +``` +そして、`web`StatefulSetを取得して、2つのリソースの作成が成功したことも確認します。 +```shell +kubectl get statefulset web +``` +``` +NAME DESIRED CURRENT AGE +web 2 1 20s +``` + +### 順序付きPodの作成 + +_n_ 個のレプリカを持つStatefulSetは、Podをデプロイするとき、1つずつ順番に作成し、 _{0..n-1}_ という順序付けを行います。1つ目のターミナルで`kubectl get`コマンドの出力を確認しましょう。最終的に、以下の例のような出力が表示されるはずです。 + +```shell +kubectl get pods -w -l app=nginx +``` +``` +NAME READY STATUS RESTARTS AGE +web-0 0/1 Pending 0 0s +web-0 0/1 Pending 0 0s +web-0 0/1 ContainerCreating 0 0s +web-0 1/1 Running 0 19s +web-1 0/1 Pending 0 0s +web-1 0/1 Pending 0 0s +web-1 0/1 ContainerCreating 0 0s +web-1 1/1 Running 0 18s +``` + +`web-0`Podが _Running_ ([Pod Phase](/ja/docs/concepts/workloads/pods/pod-lifecycle/#pod-phase)を参照)かつ _Ready_ ([Pod Conditions](/ja/docs/concepts/workloads/pods/pod-lifecycle/#pod-conditions)の`type`を参照)の状態になるまでは、`web-1`Podが起動していないことに注目してください。 + +## StatefulSet内のPod + +StatefulSet内のPodは、ユニークな順序インデックスと安定したネットワーク識別子を持ちます。 + +### Podの順序インデックスを確かめる + +StatefulSetのPodを取得します。 + +```shell +kubectl get pods -l app=nginx +``` +``` +NAME READY STATUS RESTARTS AGE +web-0 1/1 Running 0 1m +web-1 1/1 Running 0 1m +``` + +[StatefulSet](/ja/docs/concepts/workloads/controllers/statefulset/)のコンセプトで説明したように、StatefulSet内のPodは安定したユニークな識別子を持ちます。この識別子は、StatefulSet{{< glossary_tooltip term_id="controller" text="コントローラー">}}によって各Podに割り当てられる、ユニークな順序インデックスに基づいて付けられます。Podの名前は、`<statefulsetの名前>-<順序インデックス>`という形式です。`web`StatefulSetは2つのレプリカを持つため、`web-0`と`web-1`という2つのPodを作成します。 + +### 安定したネットワーク識別子の使用 + +各Podは、順序インデックスに基づいた安定したホスト名を持ちます。[`kubectl exec`](/ja/docs/reference/generated/kubectl/kubectl-commands/#exec)を使用して、各Pod内で`hostname`コマンドを実行してみましょう。 + +```shell +for i in 0 1; do kubectl exec "web-$i" -- sh -c 'hostname'; done +``` +``` +web-0 +web-1 +``` + +[`kubectl run`](/ja/docs/reference/generated/kubectl/kubectl-commands/#run)を使用して、`dnsutils`パッケージの`nslookup`コマンドを提供するコンテナを実行します。Podのホスト名に対して`nslookup`を実行すると、クラスター内のDNSアドレスが確認できます。 + +```shell +kubectl run -i --tty --image busybox:1.28 dns-test --restart=Never --rm +``` +これにより、新しいシェルが起動します。新しいシェルで、次のコマンドを実行します。 +```shell +# このコマンドは、dns-testコンテナのシェルで実行してください +nslookup web-0.nginx +``` +出力は次のようになります。 +``` +Server: 10.0.0.10 +Address 1: 10.0.0.10 kube-dns.kube-system.svc.cluster.local + +Name: web-0.nginx +Address 1: 10.244.1.6 + +nslookup web-1.nginx +Server: 10.0.0.10 +Address 1: 10.0.0.10 kube-dns.kube-system.svc.cluster.local + +Name: web-1.nginx +Address 1: 10.244.2.6 +``` + +(コンテナのシェルを終了するために、`exit`コマンドを実行してください。) + +headless serviceのCNAMEは、SRVレコードを指しています(1つのレコードがRunningかつReadyのPodに対応します)。SRVレコードは、PodのIPアドレスを含むAレコードを指します。 + +1つ目のターミナルで、StatefulSetのPodを監視します。 + +```shell +kubectl get pod -w -l app=nginx +``` +2つ目のターミナルで、[`kubectl delete`](/ja/docs/reference/generated/kubectl/kubectl-commands/#delete)を使用して、StatefulSetのすべてのPodを削除します。 + +```shell +kubectl delete pod -l app=nginx +``` +``` +pod "web-0" deleted +pod "web-1" deleted +``` + +StatefulSetがPodを再起動して、2つのPodがRunningかつReadyの状態に移行するのを待ちます。 + +```shell +kubectl get pod -w -l app=nginx +``` +``` +NAME READY STATUS RESTARTS AGE +web-0 0/1 ContainerCreating 0 0s +NAME READY STATUS RESTARTS AGE +web-0 1/1 Running 0 2s +web-1 0/1 Pending 0 0s +web-1 0/1 Pending 0 0s +web-1 0/1 ContainerCreating 0 0s +web-1 1/1 Running 0 34s +``` + +`kubectl exec`と`kubectl run`コマンドを使用して、Podのホスト名とクラスター内DNSエントリーを確認します。まず、Podのホスト名を見てみましょう。 + +```shell +for i in 0 1; do kubectl exec web-$i -- sh -c 'hostname'; done +``` +``` +web-0 +web-1 +``` +その後、次のコマンドを実行します。 +``` +kubectl run -i --tty --image busybox:1.28 dns-test --restart=Never --rm /bin/sh +``` +これにより、新しいシェルが起動します。新しいシェルで、次のコマンドを実行します。 +```shell +# このコマンドは、dns-testコンテナのシェルで実行してください +nslookup web-0.nginx +``` +出力は次のようになります。 +``` +Server: 10.0.0.10 +Address 1: 10.0.0.10 kube-dns.kube-system.svc.cluster.local + +Name: web-0.nginx +Address 1: 10.244.1.7 + +nslookup web-1.nginx +Server: 10.0.0.10 +Address 1: 10.0.0.10 kube-dns.kube-system.svc.cluster.local + +Name: web-1.nginx +Address 1: 10.244.2.8 +``` + +(コンテナのシェルを終了するために、`exit`コマンドを実行してください。) + +Podの順序インデックス、ホスト名、SRVレコード、そしてAレコード名は変化していませんが、Podに紐付けられたIPアドレスは変化する可能性があります。このチュートリアルで使用しているクラスターでは、IPアドレスは変わりました。このようなことがあるため、他のアプリケーションがStatefulSet内のPodに接続するときには、IPアドレスで指定しないことが重要です。 + +StatefulSetの有効なメンバーを探して接続する必要がある場合は、headless ServiceのCNAME(`nginx.default.svc.cluster.local`)をクエリしなければなりません。CNAMEに紐付けられたSRVレコードには、StatefulSet内のRunnningかつReadyなPodだけが含まれます。 + +アプリケーションがlivenessとreadinessをテストするコネクションのロジックをすでに実装している場合、PodのSRVレコード(`web-0.nginx.default.svc.cluster.local`、`web-1.nginx.default.svc.cluster.local`)をPodが安定しているものとして使用できます。PodがRunning and Readyな状態に移行すれば、アプリケーションはPodのアドレスを発見できるようになります。 + +### 安定したストレージへの書き込み {#writing-to-stable-storage} + +`web-0`および`web-1`のためのPersistentVolumeClaimを取得しましょう。 + +```shell +kubectl get pvc -l app=nginx +``` +出力は次のようになります。 +``` +NAME STATUS VOLUME CAPACITY ACCESSMODES AGE +www-web-0 Bound pvc-15c268c7-b507-11e6-932f-42010a800002 1Gi RWO 48s +www-web-1 Bound pvc-15c79307-b507-11e6-932f-42010a800002 1Gi RWO 48s +``` + +StatefulSetコントローラーは、2つの{{< glossary_tooltip text="PersistentVolume" term_id="persistent-volume" >}}にバインドされた2つの{{< glossary_tooltip text="PersistentVolumeClaim" term_id="persistent-volume-claim" >}}を作成しています。 + +このチュートリアルで使用しているクラスターでは、PersistentVolumeの動的なプロビジョニングが設定されているため、PersistentVolumeが自動的に作成されてバインドされています。 + +デフォルトでは、NGINXウェブサーバーは`/usr/share/nginx/html/index.html`に置かれたindexファイルを配信します。StatefulSetの`spec`内の`volumeMounts`フィールドによって、`/usr/share/nginx/html`ディレクトリがPersistentVolume上にあることが保証されます。 + +Podのホスト名を`index.html`ファイルに書き込むことで、NGINXウェブサーバーがホスト名を配信することを検証しましょう。 + +```shell +for i in 0 1; do kubectl exec "web-$i" -- sh -c 'echo "$(hostname)" > /usr/share/nginx/html/index.html'; done + +for i in 0 1; do kubectl exec -i -t "web-$i" -- curl http://localhost/; done +``` +``` +web-0 +web-1 +``` + +{{< note >}} +上記のcurlコマンドに対して代わりに**403 Forbidden**というレスポンスが返ってくる場合、`volumeMounts`でマウントしたディレクトリのパーミッションを修正する必要があります(これは、[hostPathボリュームを使用したときに起こるバグ](https://github.com/kubernetes/kubernetes/issues/2630)が原因です)。この問題に対処するには、上の`curl`コマンドを再実行する前に、次のコマンドを実行します。 + +`for i in 0 1; do kubectl exec web-$i -- chmod 755 /usr/share/nginx/html; done` +{{< /note >}} + +1つ目のターミナルで、StatefulSetのPodを監視します。 + +```shell +kubectl get pod -w -l app=nginx +``` + +2つ目のターミナルで、StatefulSetのすべてのPodを削除します。 + +```shell +kubectl delete pod -l app=nginx +``` +``` +pod "web-0" deleted +pod "web-1" deleted +``` +1つ目のターミナルで`kubectl get`コマンドの出力を確認して、すべてのPodがRunningかつReadyの状態に変わるまで待ちます。 + +```shell +kubectl get pod -w -l app=nginx +``` +``` +NAME READY STATUS RESTARTS AGE +web-0 0/1 ContainerCreating 0 0s +NAME READY STATUS RESTARTS AGE +web-0 1/1 Running 0 2s +web-1 0/1 Pending 0 0s +web-1 0/1 Pending 0 0s +web-1 0/1 ContainerCreating 0 0s +web-1 1/1 Running 0 34s +``` + +ウェブサーバーがホスト名を配信し続けていることを確認します。 + +``` +for i in 0 1; do kubectl exec -i -t "web-$i" -- curl http://localhost/; done +``` +``` +web-0 +web-1 +``` + +もし`web-0`および`web-1`が再スケジュールされたとしても、Podは同じホスト名を配信し続けます。これは、PodのPersistentVolumeClaimに紐付けられたPersistentVolumeが、Podの`volumeMounts`に再マウントされるためです。`web-0`と`web-1`がどんなノードにスケジュールされたとしても、PodのPersistentVolumeは適切なマウントポイントにマウントされます。 + +## StatefulSetをスケールする + +StatefulSetのスケールとは、レプリカ数を増減することを意味します。これは、`replicas`フィールドを更新することによって実現できます。StatefulSetのスケールには、[`kubectl scale`](/ja/docs/reference/generated/kubectl/kubectl-commands/#scale)と +[`kubectl patch`](/ja/docs/reference/generated/kubectl/kubectl-commands/#patch)のどちらも使用できます。 + +### スケールアップ + +1つ目のターミナルで、StatefulSet内のPodを監視します。 + +```shell +kubectl get pods -w -l app=nginx +``` + +2つ目のターミナルで、`kubectl scale`を使って、レプリカ数を5にスケールします。 + +```shell +kubectl scale sts web --replicas=5 +``` +``` +statefulset.apps/web scaled +``` + +1つ目のターミナルの`kubectl get`コマンドの出力を確認して、3つの追加のPodがRunningかつReadyの状態に変わるまで待ちます。 + +```shell +kubectl get pods -w -l app=nginx +``` +``` +NAME READY STATUS RESTARTS AGE +web-0 1/1 Running 0 2h +web-1 1/1 Running 0 2h +NAME READY STATUS RESTARTS AGE +web-2 0/1 Pending 0 0s +web-2 0/1 Pending 0 0s +web-2 0/1 ContainerCreating 0 0s +web-2 1/1 Running 0 19s +web-3 0/1 Pending 0 0s +web-3 0/1 Pending 0 0s +web-3 0/1 ContainerCreating 0 0s +web-3 1/1 Running 0 18s +web-4 0/1 Pending 0 0s +web-4 0/1 Pending 0 0s +web-4 0/1 ContainerCreating 0 0s +web-4 1/1 Running 0 19s +``` + +StatefulSetコントローラーはレプリカ数をスケールします。 +[StatefulSetを作成する](#ordered-pod-creation)で説明したように、StatefulSetコントローラーは各Podを順序インデックスに従って1つずつ作成し、次のPodを起動する前に、1つ前のPodがRunningかつReadyの状態になるまで待ちます。 + +### スケールダウン {#scaling-down} + +1つ目のターミナルで、StatefulSetのPodを監視します。 + +```shell +kubectl get pods -w -l app=nginx +``` + +2つ目のターミナルで、`kubectl patch`コマンドを使用して、StatefulSetを3つのレプリカにスケールダウンします。 + +```shell +kubectl patch sts web -p '{"spec":{"replicas":3}}' +``` +``` +statefulset.apps/web patched +``` + +`web-4`および`web-3`がTerminatingの状態になるまで待ちます。 + +```shell +kubectl get pods -w -l app=nginx +``` +``` +NAME READY STATUS RESTARTS AGE +web-0 1/1 Running 0 3h +web-1 1/1 Running 0 3h +web-2 1/1 Running 0 55s +web-3 1/1 Running 0 36s +web-4 0/1 ContainerCreating 0 18s +NAME READY STATUS RESTARTS AGE +web-4 1/1 Running 0 19s +web-4 1/1 Terminating 0 24s +web-4 1/1 Terminating 0 24s +web-3 1/1 Terminating 0 42s +web-3 1/1 Terminating 0 42s +``` + +### 順序付きPodを削除する + +コントローラーは、順序インデックスの逆順に1度に1つのPodを削除し、次のPodを削除する前には、各Podが完全にシャットダウンするまで待機しています。 + +StatefulSetのPersistentVolumeClaimを取得しましょう。 + +```shell +kubectl get pvc -l app=nginx +``` +``` +NAME STATUS VOLUME CAPACITY ACCESSMODES AGE +www-web-0 Bound pvc-15c268c7-b507-11e6-932f-42010a800002 1Gi RWO 13h +www-web-1 Bound pvc-15c79307-b507-11e6-932f-42010a800002 1Gi RWO 13h +www-web-2 Bound pvc-e1125b27-b508-11e6-932f-42010a800002 1Gi RWO 13h +www-web-3 Bound pvc-e1176df6-b508-11e6-932f-42010a800002 1Gi RWO 13h +www-web-4 Bound pvc-e11bb5f8-b508-11e6-932f-42010a800002 1Gi RWO 13h + +``` + +まだ、5つのPersistentVolumeClaimと5つのPersistentVolumeが残っています。[安定したストレージへの書き込み](#writing-to-stable-storage)を読むと、StatefulSetのPodが削除されても、StatefulSetのPodにマウントされたPersistentVolumeは削除されないと書かれています。このことは、StatefulSetのスケールダウンによってPodが削除された場合にも当てはまります。 + +## StatefulSetsを更新する + +Kubernetes 1.7以降では、StatefulSetコントローラーは自動アップデートをサポートしています。使われる戦略は、StatefulSet APIオブジェクトの`spec.updateStrategy`フィールドによって決まります。この機能はコンテナイメージのアップグレード、リソースのrequestsやlimits、ラベル、StatefulSet内のPodのアノテーションの更新時に利用できます。有効なアップデートの戦略は、`RollingUpdate`と`OnDelete`の2種類です。 + +`RollingUpdate`は、StatefulSetのデフォルトのアップデート戦略です。 + +### RollingUpdate + +`RollingUpdate`アップデート戦略は、StatefulSetの保証を尊重しながら、順序インデックスの逆順にStatefulSet内のすべてのPodをアップデートします。 + +`web`StatefulSetにpatchを当てて、`RollingUpdate`アップデート戦略を適用しましょう。 + +```shell +kubectl patch statefulset web -p '{"spec":{"updateStrategy":{"type":"RollingUpdate"}}}' +``` +``` +statefulset.apps/web patched +``` + +1つ目のターミナルで、`web`StatefulSetに再度patchを当てて、コンテナイメージを変更します。 + +```shell +kubectl patch statefulset web --type='json' -p='[{"op": "replace", "path": "/spec/template/spec/containers/0/image", "value":"gcr.io/google_containers/nginx-slim:0.8"}]' +``` +``` +statefulset.apps/web patched +``` + +2つ目のターミナルで、StatefulSet内のPodを監視します。 + +```shell +kubectl get pod -l app=nginx -w +``` +出力は次のようになります。 +``` +NAME READY STATUS RESTARTS AGE +web-0 1/1 Running 0 7m +web-1 1/1 Running 0 7m +web-2 1/1 Running 0 8m +web-2 1/1 Terminating 0 8m +web-2 1/1 Terminating 0 8m +web-2 0/1 Terminating 0 8m +web-2 0/1 Terminating 0 8m +web-2 0/1 Terminating 0 8m +web-2 0/1 Terminating 0 8m +web-2 0/1 Pending 0 0s +web-2 0/1 Pending 0 0s +web-2 0/1 ContainerCreating 0 0s +web-2 1/1 Running 0 19s +web-1 1/1 Terminating 0 8m +web-1 0/1 Terminating 0 8m +web-1 0/1 Terminating 0 8m +web-1 0/1 Terminating 0 8m +web-1 0/1 Pending 0 0s +web-1 0/1 Pending 0 0s +web-1 0/1 ContainerCreating 0 0s +web-1 1/1 Running 0 6s +web-0 1/1 Terminating 0 7m +web-0 1/1 Terminating 0 7m +web-0 0/1 Terminating 0 7m +web-0 0/1 Terminating 0 7m +web-0 0/1 Terminating 0 7m +web-0 0/1 Terminating 0 7m +web-0 0/1 Pending 0 0s +web-0 0/1 Pending 0 0s +web-0 0/1 ContainerCreating 0 0s +web-0 1/1 Running 0 10s +``` + +StatefulSet内のPodは、順序インデックスの逆順に更新されました。StatefulSetコントローラーは各Podを終了させ、次のPodを更新する前に、新しいPodがRunningかつReadyの状態に変わるまで待機します。ここで、StatefulSetコントローラーは順序インデックスの前のPodがRunningかつReadyの状態になるまで次のPodの更新を始めず、現在の状態へのアップデートに失敗したPodがあった場合、そのPodをリストアすることに注意してください。 + +すでにアップデートを受け取ったPodは、アップデートされたバージョンにリストアされます。まだアップデートを受け取っていないPodは、前のバージョンにリストアされます。このような方法により、もし途中で失敗が起こっても、コントローラはアプリケーションが健全な状態を保ち続けられるようにし、更新が一貫したものになるようにします。 + +Podを取得して、コンテナイメージを確認してみましょう。 + +```shell +for p in 0 1 2; do kubectl get pod "web-$p" --template '{{range $i, $c := .spec.containers}}{{$c.image}}{{end}}'; echo; done +``` +``` +k8s.gcr.io/nginx-slim:0.8 +k8s.gcr.io/nginx-slim:0.8 +k8s.gcr.io/nginx-slim:0.8 + +``` + +現在、StatefulSet内のすべてのPodは、前のコンテナイメージを実行しています。 + +{{< note >}} +`kubectl rollout status sts/<name>`を使って、StatefulSetへのローリングアップデートの状態を確認することもできます。 +{{< /note >}} + +#### ステージングアップデート {#staging-an-update} + +`RollingUpdate`アップデート戦略に`partition`パラメーターを使用すると、StatefulSetへのアップデートをステージングすることができます。ステージングアップデートを利用すれば、StatefulSet内のすべてのPodを現在のバージョンにしたまま、StatefulSetの`.spec.template`を変更することが可能になります。 + +`web`StatefulSetにpatchを当てて、`updateStrategy`フィールドにpartitionを追加しましょう。 + +```shell +kubectl patch statefulset web -p '{"spec":{"updateStrategy":{"type":"RollingUpdate","rollingUpdate":{"partition":3}}}}' +``` +``` +statefulset.apps/web patched +``` + +StatefulSetに再度patchを当てて、コンテナイメージを変更します。 + +```shell +kubectl patch statefulset web --type='json' -p='[{"op": "replace", "path": "/spec/template/spec/containers/0/image", "value":"k8s.gcr.io/nginx-slim:0.7"}]' +``` +``` +statefulset.apps/web patched +``` + +StatefulSet内のPodを削除します。 + +```shell +kubectl delete pod web-2 +``` +``` +pod "web-2" deleted +``` + +PodがRunningかつReadyになるまで待ちます。 + +```shell +kubectl get pod -l app=nginx -w +``` +``` +NAME READY STATUS RESTARTS AGE +web-0 1/1 Running 0 4m +web-1 1/1 Running 0 4m +web-2 0/1 ContainerCreating 0 11s +web-2 1/1 Running 0 18s +``` + +Podのコンテナイメージを取得します。 + +```shell +kubectl get pod web-2 --template '{{range $i, $c := .spec.containers}}{{$c.image}}{{end}}' +``` +``` +k8s.gcr.io/nginx-slim:0.8 +``` + +アップデート戦略が`RollingUpdate`であっても、StatefulSetが元のコンテナを持つPodをリストアしたことがわかります。これは、Podの順序インデックスが`updateStrategy`で指定した`partition`より小さいためです。 + +#### カナリア版をロールアウトする {#rolling-out-a-canary} + +[ステージングアップデート](#staging-an-update)のときに指定した`partition`を小さくすることで、変更をテストするためのカナリア版をロールアウトできます。 + +StatefulSetにpatchを当てて、partitionを小さくします。 + +```shell +kubectl patch statefulset web -p '{"spec":{"updateStrategy":{"type":"RollingUpdate","rollingUpdate":{"partition":2}}}}' +``` +``` +statefulset.apps/web patched +``` + +`web-2`がRunningかつReadyの状態になるまで待ちます。 + +```shell +kubectl get pod -l app=nginx -w +``` +``` +NAME READY STATUS RESTARTS AGE +web-0 1/1 Running 0 4m +web-1 1/1 Running 0 4m +web-2 0/1 ContainerCreating 0 11s +web-2 1/1 Running 0 18s +``` + +Podのコンテナを取得します。 + +```shell +kubectl get pod web-2 --template '{{range $i, $c := .spec.containers}}{{$c.image}}{{end}}' +``` +``` +k8s.gcr.io/nginx-slim:0.7 + +``` + +`partition`を変更すると、StatefulSetコントローラーはPodを自動的に更新します。Podの順序インデックスが`partition`以上の値であるためです。 + +`web-1`Podを削除します。 + +```shell +kubectl delete pod web-1 +``` +``` +pod "web-1" deleted +``` + +`web-1`PodがRunningかつReadyになるまで待ちます。 + +```shell +kubectl get pod -l app=nginx -w +``` +出力は次のようになります。 +``` +NAME READY STATUS RESTARTS AGE +web-0 1/1 Running 0 6m +web-1 0/1 Terminating 0 6m +web-2 1/1 Running 0 2m +web-1 0/1 Terminating 0 6m +web-1 0/1 Terminating 0 6m +web-1 0/1 Terminating 0 6m +web-1 0/1 Pending 0 0s +web-1 0/1 Pending 0 0s +web-1 0/1 ContainerCreating 0 0s +web-1 1/1 Running 0 18s +``` + +`web-1`Podのコンテナイメージを取得します。 + +```shell +kubectl get pod web-1 --template '{{range $i, $c := .spec.containers}}{{$c.image}}{{end}}' +``` +``` +k8s.gcr.io/nginx-slim:0.8 +``` + +Podの順序インデックスがpartitionよりも小さいため、`web-1`は元の設定のコンテナイメージにリストアされました。partitionを指定すると、StatefulSetの`.spec.template`が更新されたときに、順序インデックスがそれ以上の値を持つすべてのPodがアップデートされます。partitionよりも小さな順序インデックスを持つPodが削除されたり終了されたりすると、元の設定のPodにリストアされます。 + +#### フェーズロールアウト + +[カナリア版](#rolling-out-a-canary)をロールアウトするのと同じような方法でパーティションされたローリングアップデートを使用すると、フェーズロールアウト(例: 線形、幾何級数的、指数関数的ロールアウト)を実行できます。フェーズロールアウトを実行するには、コントローラーがアップデートを途中で止めてほしい順序インデックスを`partition`に設定します。 + +現在、partitionは`2`に設定されています。partitionを`0`に設定します。 + +```shell +kubectl patch statefulset web -p '{"spec":{"updateStrategy":{"type":"RollingUpdate","rollingUpdate":{"partition":0}}}}' +``` +``` +statefulset.apps/web patched +``` + +StatefulSet内のすべてのPodがRunningかつReadyの状態になるまで待ちます。 + +```shell +kubectl get pod -l app=nginx -w +``` +出力は次のようになります。 +``` +NAME READY STATUS RESTARTS AGE +web-0 1/1 Running 0 3m +web-1 0/1 ContainerCreating 0 11s +web-2 1/1 Running 0 2m +web-1 1/1 Running 0 18s +web-0 1/1 Terminating 0 3m +web-0 1/1 Terminating 0 3m +web-0 0/1 Terminating 0 3m +web-0 0/1 Terminating 0 3m +web-0 0/1 Terminating 0 3m +web-0 0/1 Terminating 0 3m +web-0 0/1 Pending 0 0s +web-0 0/1 Pending 0 0s +web-0 0/1 ContainerCreating 0 0s +web-0 1/1 Running 0 3s +``` + +StatefulSet内のPodのコンテナイメージの詳細を取得します。 + +```shell +for p in 0 1 2; do kubectl get pod "web-$p" --template '{{range $i, $c := .spec.containers}}{{$c.image}}{{end}}'; echo; done +``` +``` +k8s.gcr.io/nginx-slim:0.7 +k8s.gcr.io/nginx-slim:0.7 +k8s.gcr.io/nginx-slim:0.7 +``` + +`partition`を`0`に移動することで、StatefulSetがアップデート処理を続けられるようにできます。 + +### OnDelete + +`OnDelete`アップデート戦略は、(1.6以前の)レガシーな動作を実装しています。このアップデート戦略を選択すると、StatefulSetの`.spec.template`フィールドへ変更を加えても、StatefulSetコントローラーが自動的にPodを更新しなくなります。この戦略を選択するには、`.spec.template.updateStrategy.type`に`OnDelete`を設定します。 + +## StatefulSetを削除する + +StatefulSetは、非カスケードな削除とカスケードな削除の両方をサポートしています。非カスケードな削除では、StatefulSetが削除されても、StatefulSet内のPodは削除されません。カスケードな削除では、StatefulSetとPodが一緒に削除されます。 + +### 非カスケードな削除 + +1つ目のターミナルで、StatefulSet内のPodを監視します + +``` +kubectl get pods -w -l app=nginx +``` + +[`kubectl delete`](/ja/docs/reference/generated/kubectl/kubectl-commands/#delete)を使用して、StatefulSetを削除します。このとき、`--cascade=false`パラメーターをコマンドに与えてください。このパラメーターは、Kubernetesに対して、StatefulSetだけを削除して配下のPodは削除しないように指示します。 + +```shell +kubectl delete statefulset web --cascade=false +``` +``` +statefulset.apps "web" deleted +``` + +Podを取得して、ステータスを確認します。 + +```shell +kubectl get pods -l app=nginx +``` +``` +NAME READY STATUS RESTARTS AGE +web-0 1/1 Running 0 6m +web-1 1/1 Running 0 7m +web-2 1/1 Running 0 5m +``` + +`web`が削除されても、すべてのPodはまだRunningかつReadyの状態のままです。`web-0`を削除します。 + +```shell +kubectl delete pod web-0 +``` +``` +pod "web-0" deleted +``` + +StatefulSetのPodを取得します。 + +```shell +kubectl get pods -l app=nginx +``` +``` +NAME READY STATUS RESTARTS AGE +web-1 1/1 Running 0 10m +web-2 1/1 Running 0 7m +``` + +`web`StatefulSetはすでに削除されているため、`web-0`は再起動しません。 + +1つ目のターミナルで、StatefulSetのPodを監視します。 + +```shell +kubectl get pods -w -l app=nginx +``` + +2つ目のターミナルで、StatefulSetを再作成します。もし`nginx`Serviceを削除しなかった場合(この場合は削除するべきではありませんでした)、Serviceがすでに存在することを示すエラーが表示されます。 + +```shell +kubectl apply -f web.yaml +``` +``` +statefulset.apps/web created +service/nginx unchanged +``` + +このエラーは無視してください。このメッセージは、すでに存在する _nginx_ というheadless Serviceを作成しようと試みたということを示しているだけです。 + +1つ目のターミナルで、`kubectl get`コマンドの出力を確認します。 + +```shell +kubectl get pods -w -l app=nginx +``` +``` +NAME READY STATUS RESTARTS AGE +web-1 1/1 Running 0 16m +web-2 1/1 Running 0 2m +NAME READY STATUS RESTARTS AGE +web-0 0/1 Pending 0 0s +web-0 0/1 Pending 0 0s +web-0 0/1 ContainerCreating 0 0s +web-0 1/1 Running 0 18s +web-2 1/1 Terminating 0 3m +web-2 0/1 Terminating 0 3m +web-2 0/1 Terminating 0 3m +web-2 0/1 Terminating 0 3m +``` + + `web`StatefulSetが再作成されると、最初に`web-0`を再実行します。`web-1`はすでにRunningかつReadyの状態であるため、`web-0`がRunningかつReadyの状態に移行すると、StatefulSetは単純にこのPodを選びます。StatefulSetを`replicas`を2にして再作成したため、一度`web-0`が再作成されて、`web-1`がすでにRunningかつReadyの状態であることが判明したら、`web-2`は停止されます。 + +Podのウェブサーバーが配信している`index.html`ファイルのコンテンツをもう一度見てみましょう。 + +```shell +for i in 0 1; do kubectl exec -i -t "web-$i" -- curl http://localhost/; done +``` +``` +web-0 +web-1 +``` + +たとえStatefulSetと`web-0`Podの両方が削除されても、Podは最初に`index.html`ファイルに書き込んだホスト名をまだ配信しています。これは、StatefulSetがPodに紐付けられたPersistentVolumeを削除しないためです。StatefulSetを再作成して`web-0`を再実行すると、元のPersistentVolumeが再マウントされます。 + +### カスケードな削除 + +1つ目のターミナルで、StatefulSet内のPodを監視します。 + +```shell +kubectl get pods -w -l app=nginx +``` + +2つ目のターミナルで、StatefulSetをもう一度削除します。今回は、`--cascade=false`パラメーターを省略します。 + +```shell +kubectl delete statefulset web +``` +``` +statefulset.apps "web" deleted +``` + +1つ目のターミナルで実行している`kubectl get`コマンドの出力を確認し、すべてのPodがTerminatingの状態に変わるまで待ちます。 + +```shell +kubectl get pods -w -l app=nginx +``` +``` +NAME READY STATUS RESTARTS AGE +web-0 1/1 Running 0 11m +web-1 1/1 Running 0 27m +NAME READY STATUS RESTARTS AGE +web-0 1/1 Terminating 0 12m +web-1 1/1 Terminating 0 29m +web-0 0/1 Terminating 0 12m +web-0 0/1 Terminating 0 12m +web-0 0/1 Terminating 0 12m +web-1 0/1 Terminating 0 29m +web-1 0/1 Terminating 0 29m +web-1 0/1 Terminating 0 29m + +``` + +[スケールダウン](#scaling-down)のセクションで見たように、順序インデックスの逆順に従って、Podは一度に1つずつ終了します。StatefulSetコントローラーは、次のPodを終了する前に、前のPodが完全に終了するまで待ちます。 + +{{< note >}} +カスケードな削除ではStatefulSetがPodとともに削除されますが、StatefulSetと紐付けられたheadless Serviceは削除されません。そのため、`nginx`Serviceは手動で削除する必要があります。 +{{< /note >}} + + +```shell +kubectl delete service nginx +``` +``` +service "nginx" deleted +``` + +さらにもう一度、StatefulSetとheadless Serviceを再作成します。 + +```shell +kubectl apply -f web.yaml +``` +``` +service/nginx created +statefulset.apps/web created +``` + +StatefulSet上のすべてのPodがRunningかつReadyの状態に変わったら、Pod上の`index.html`ファイルのコンテンツを取得します。 + +```shell +for i in 0 1; do kubectl exec -i -t "web-$i" -- curl http://localhost/; done +``` +``` +web-0 +web-1 +``` + +StatefulSetを完全に削除して、すべてのPodが削除されたとしても、PersistentVolumeがマウントされたPodが再生成されて、`web-0`と`web-1`はホスト名の配信を続けます。 + +最後に、`web`StatefulSetを削除します。 + +```shell +kubectl delete service nginx +``` +``` +service "nginx" deleted +``` +そして、`nginx`Serviceも削除します。 +```shell +kubectl delete statefulset web +``` +``` +statefulset "web" deleted +``` + +## Pod管理ポリシー + +分散システムによっては、StatefulSetの順序の保証が不必要であったり望ましくない場合もあります。こうしたシステムでは、一意性と同一性だけが求められます。この問題に対処するために、Kubernetes 1.7でStatefulSet APIオブジェクトに`.spec.podManagementPolicy`が導入されました。 + +### OrderedReadyのPod管理 + +`OrderedReady`のPod管理はStatefulSetのデフォルトの設定です。StatefulSetコントローラーに対して、これまでに紹介したような順序の保証を尊重するように指示します。 + +### ParallelのPod管理 + +`Parallel`のPod管理では、StatefulSetコントローラーに対して、PodがRunningかつReadyの状態や完全に停止するまで待たないように指示し、すべてのPodを並列に起動または停止させるようにします。 + +{{< codenew file="application/web/web-parallel.yaml" >}} + +上の例をダウンロードして、`web-parallel.yaml`という名前でファイルに保存してください。 + +このマニフェストは、`.spec.podManagementPolicy`が`Parallel`に設定されている以外は、前にダウンロードした`web`StatefulSetと同一です。 + +1つ目のターミナルで、StatefulSet内のPodを監視します。 + +```shell +kubectl get pod -l app=nginx -w +``` + +2つ目のターミナルで、マニフェスト内のStatefulSetとServiceを作成します。 + +```shell +kubectl apply -f web-parallel.yaml +``` +``` +service/nginx created +statefulset.apps/web created +``` + +1つ目のターミナルで実行した`kubectl get`コマンドの出力を確認します。 + +```shell +kubectl get pod -l app=nginx -w +``` +``` +NAME READY STATUS RESTARTS AGE +web-0 0/1 Pending 0 0s +web-0 0/1 Pending 0 0s +web-1 0/1 Pending 0 0s +web-1 0/1 Pending 0 0s +web-0 0/1 ContainerCreating 0 0s +web-1 0/1 ContainerCreating 0 0s +web-0 1/1 Running 0 10s +web-1 1/1 Running 0 10s +``` + +StatefulSetコントローラーは`web-0`と`web-1`を同時に起動しています。 + +2つ目のターミナルで、StatefulSetをスケールしてみます。 + +```shell +kubectl scale statefulset/web --replicas=4 +``` +``` +statefulset.apps/web scaled +``` + +`kubectl get`コマンドを実行しているターミナルの出力を確認します。 + +``` +web-3 0/1 Pending 0 0s +web-3 0/1 Pending 0 0s +web-3 0/1 Pending 0 7s +web-3 0/1 ContainerCreating 0 7s +web-2 1/1 Running 0 10s +web-3 1/1 Running 0 26s +``` + +StatefulSetが2つのPodを実行し、1つ目のPodがRunningかつReadyの状態になるのを待たずに2つ目のPodを実行しているのがわかります。 + +## {{% heading "cleanup" %}} + +2つのターミナルが開かれているはずなので、クリーンアップの一部として`kubectl`コマンドを実行する準備ができています。 + +```shell +kubectl delete sts web +# stsは、statefulsetの略です。 +``` + +`kubectl get`を監視すると、Podが削除されていく様子を確認できます。 + +```shell +kubectl get pod -l app=nginx -w +``` +``` +web-3 1/1 Terminating 0 9m +web-2 1/1 Terminating 0 9m +web-3 1/1 Terminating 0 9m +web-2 1/1 Terminating 0 9m +web-1 1/1 Terminating 0 44m +web-0 1/1 Terminating 0 44m +web-0 0/1 Terminating 0 44m +web-3 0/1 Terminating 0 9m +web-2 0/1 Terminating 0 9m +web-1 0/1 Terminating 0 44m +web-0 0/1 Terminating 0 44m +web-2 0/1 Terminating 0 9m +web-2 0/1 Terminating 0 9m +web-2 0/1 Terminating 0 9m +web-1 0/1 Terminating 0 44m +web-1 0/1 Terminating 0 44m +web-1 0/1 Terminating 0 44m +web-0 0/1 Terminating 0 44m +web-0 0/1 Terminating 0 44m +web-0 0/1 Terminating 0 44m +web-3 0/1 Terminating 0 9m +web-3 0/1 Terminating 0 9m +web-3 0/1 Terminating 0 9m +``` + +削除の間、StatefulSetはすべてのPodを並列に削除し、順序インデックスが1つ前のPodが停止するのを待つことはありません。 + +`kubectl get`コマンドを実行しているターミナルを閉じて、`nginx`Serviceを削除します。 + +```shell +kubectl delete svc nginx +``` + +{{< note >}} +このチュートリアルで使用したPersistentVolumeのための永続ストレージも削除する必要があります。 + +すべてのストレージが再利用できるようにするために、環境、ストレージの設定、プロビジョニング方法に基づいて必要な手順に従ってください。 +{{< /note >}} diff --git a/content/ja/docs/tutorials/stateful-application/cassandra.md b/content/ja/docs/tutorials/stateful-application/cassandra.md new file mode 100644 index 0000000000..32b215e62d --- /dev/null +++ b/content/ja/docs/tutorials/stateful-application/cassandra.md @@ -0,0 +1,261 @@ +--- +title: "例: StatefulSetを使用したCassandraのデプロイ" +content_type: tutorial +weight: 30 +--- + +<!-- overview --> +このチュートリアルでは、[Apache Cassandra](http://cassandra.apache.org/)をKubernetes上で実行する方法を紹介します。データベースの一種であるCassandraには、データの耐久性(アプリケーションの*状態*)を提供するために永続ストレージが必要です。この例では、カスタムのCassandraのseed providerにより、Cassandraクラスターに参加した新しいCassandraインスタンスを検出できるようにします。 + +*StatefulSet*を利用すると、ステートフルなアプリケーションをKubernetesクラスターにデプロイするのが簡単になります。このチュートリアルで使われている機能のより詳しい情報は、[StatefulSet](/ja/docs/concepts/workloads/controllers/statefulset/)を参照してください。 + +{{< note >}} +CassandraとKubernetesは、ともにクラスターのメンバーを表すために*ノード*という用語を使用しています。このチュートリアルでは、StatefulSetに属するPodはCassandraのノードであり、Cassandraクラスター(*ring*と呼ばれます)のメンバーでもあります。これらのPodがKubernetesクラスター内で実行されるとき、Kubernetesのコントロールプレーンは、PodをKubernetesの{{< glossary_tooltip text="Node" term_id="node" >}}上にスケジュールします。 + +Cassandraノードが開始すると、*シードリスト*を使ってring上の他のノードの検出が始まります。このチュートリアルでは、Kubernetesクラスター内に現れた新しいCassandra Podを検出するカスタムのCassandraのseed providerをデプロイします。 +{{< /note >}} + + +## {{% heading "objectives" %}} + +* Cassandraのheadless {{< glossary_tooltip text="Service" term_id="service" >}}を作成して検証する。 +* {{< glossary_tooltip term_id="StatefulSet" >}}を使用してCassandra ringを作成する。 +* StatefulSetを検証する。 +* StatefulSetを編集する。 +* StatefulSetと{{< glossary_tooltip text="Pod" term_id="pod" >}}を削除する。 + + +## {{% heading "prerequisites" %}} + +{{< include "task-tutorial-prereqs.md" >}} + +このチュートリアルを完了するには、{{< glossary_tooltip text="Pod" term_id="pod" >}}、{{< glossary_tooltip text="Service" term_id="service" >}}、{{< glossary_tooltip text="StatefulSet" term_id="StatefulSet" >}}の基本についてすでに知っている必要があります。 + +### Minikubeのセットアップに関する追加の設定手順 + +{{< caution >}} +[Minikube](/ja/docs/getting-started-guides/minikube/)は、デフォルトでは1024MiBのメモリと1CPUに設定されます。デフォルトのリソース設定で起動したMinikubeでは、このチュートリアルの実行中にリソース不足のエラーが発生してしまいます。このエラーを回避するためにはMinikubeを次の設定で起動してください。 + +```shell +minikube start --memory 5120 --cpus=4 +``` +{{< /caution >}} + + + +<!-- lessoncontent --> +## Cassandraのheadless Serviceを作成する {#creating-a-cassandra-headless-service} + +Kubernetesでは、{{< glossary_tooltip text="Service" term_id="service" >}}は同じタスクを実行する{{< glossary_tooltip text="Pod" term_id="pod" >}}の集合を表します。 + +以下のServiceは、Cassandra Podとクラスター内のクライアント間のDNSルックアップに使われます。 + +{{< codenew file="application/cassandra/cassandra-service.yaml" >}} + +`cassandra-service.yaml`ファイルから、Cassandra StatefulSetのすべてのメンバーをトラッキングするServiceを作成します。 + +```shell +kubectl apply -f https://k8s.io/examples/application/cassandra/cassandra-service.yaml +``` + + +### 検証 (オプション) {#validating} + +Cassandra Serviceを取得します。 + +```shell +kubectl get svc cassandra +``` + +結果は次のようになります。 + +``` +NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE +cassandra ClusterIP None <none> 9042/TCP 45s +``` + + +`cassandra`という名前のServiceが表示されない場合、作成に失敗しています。よくある問題のトラブルシューティングについては、[Serviceのデバッグ](/ja/docs/tasks/debug-application-cluster/debug-service/)を読んでください。 + +## StatefulSetを使ってCassandra ringを作成する + +以下に示すStatefulSetマニフェストは、3つのPodからなるCassandra ringを作成します。 + +{{< note >}} +この例ではMinikubeのデフォルトのプロビジョナーを使用しています。クラウドを使用している場合、StatefulSetを更新してください。 +{{< /note >}} + +{{< codenew file="application/cassandra/cassandra-statefulset.yaml" >}} + +`cassandra-statefulset.yaml`ファイルから、CassandraのStatefulSetを作成します。 + +```shell +# cassandra-statefulset.yaml を編集せずにapplyできる場合は、このコマンドを使用してください +kubectl apply -f https://k8s.io/examples/application/cassandra/cassandra-statefulset.yaml +``` + +クラスターに合わせて`cassandra-statefulset.yaml`を編集する必要がある場合、 https://k8s.io/examples/application/cassandra/cassandra-statefulset.yaml をダウンロードして、修正したバージョンを保存したフォルダからマニフェストを適用してください。 + +```shell +# cassandra-statefulset.yaml をローカルで編集する必要がある場合、このコマンドを使用してください +kubectl apply -f cassandra-statefulset.yaml +``` + + +## CassandraのStatefulSetを検証する + +1. CassandraのStatefulSetを取得します + + ```shell + kubectl get statefulset cassandra + ``` + + 結果は次のようになるはずです。 + + ``` + NAME DESIRED CURRENT AGE + cassandra 3 0 13s + ``` + + `StatefulSet`リソースがPodを順番にデプロイします。 + +1. Podを取得して順序付きの作成ステータスを確認します + + ```shell + kubectl get pods -l="app=cassandra" + ``` + + 結果は次のようになるはずです。 + + ```shell + NAME READY STATUS RESTARTS AGE + cassandra-0 1/1 Running 0 1m + cassandra-1 0/1 ContainerCreating 0 8s + ``` + + 3つすべてのPodのデプロイには数分かかる場合があります。デプロイが完了すると、同じコマンドは次のような結果を返します。 + + ``` + NAME READY STATUS RESTARTS AGE + cassandra-0 1/1 Running 0 10m + cassandra-1 1/1 Running 0 9m + cassandra-2 1/1 Running 0 8m + ``` + +3. 1番目のPodの中でCassandraの[nodetool](https://cwiki.apache.org/confluence/display/CASSANDRA2/NodeTool)を実行して、ringのステータスを表示します。 + + ```shell + kubectl exec -it cassandra-0 -- nodetool status + ``` + + 結果は次のようになるはずです。 + + ``` + Datacenter: DC1-K8Demo + ====================== + Status=Up/Down + |/ State=Normal/Leaving/Joining/Moving + -- Address Load Tokens Owns (effective) Host ID Rack + UN 172.17.0.5 83.57 KiB 32 74.0% e2dd09e6-d9d3-477e-96c5-45094c08db0f Rack1-K8Demo + UN 172.17.0.4 101.04 KiB 32 58.8% f89d6835-3a42-4419-92b3-0e62cae1479c Rack1-K8Demo + UN 172.17.0.6 84.74 KiB 32 67.1% a6a1e8c2-3dc5-4417-b1a0-26507af2aaad Rack1-K8Demo + ``` + +## CassandraのStatefulSetを変更する + +`kubectl edit`を使うと、CassandraのStatefulSetのサイズを変更できます。 + +1. 次のコマンドを実行します。 + + ```shell + kubectl edit statefulset cassandra + ``` + + このコマンドを実行すると、ターミナルでエディタが起動します。変更が必要な行は`replicas`フィールドです。以下の例は、StatefulSetファイルの抜粋です。 + + ```yaml + # Please edit the object below. Lines beginning with a '#' will be ignored, + # and an empty file will abort the edit. If an error occurs while saving this file will be + # reopened with the relevant failures. + # + apiVersion: apps/v1 + kind: StatefulSet + metadata: + creationTimestamp: 2016-08-13T18:40:58Z + generation: 1 + labels: + app: cassandra + name: cassandra + namespace: default + resourceVersion: "323" + uid: 7a219483-6185-11e6-a910-42010a8a0fc0 + spec: + replicas: 3 + ``` + +1. レプリカ数を4に変更し、マニフェストを保存します。 + + これで、StatefulSetが4つのPodを実行するようにスケールされました。 + +1. CassandraのStatefulSetを取得して、変更を確かめます。 + + ```shell + kubectl get statefulset cassandra + ``` + + 結果は次のようになるはずです。 + + ``` + NAME DESIRED CURRENT AGE + cassandra 4 4 36m + ``` + + + +## {{% heading "cleanup" %}} + +StatefulSetを削除したりスケールダウンしても、StatefulSetに関係するボリュームは削除されません。StatefulSetに関連するすべてのリソースを自動的に破棄するよりも、データの方がより貴重であるため、安全のためにこのような設定になっています。 + +{{< warning >}} +ストレージクラスやreclaimポリシーによっては、*PersistentVolumeClaim*を削除すると、関連するボリュームも削除される可能性があります。PersistentVolumeClaimの削除後にもデータにアクセスできるとは決して想定しないでください。 +{{< /warning >}} + +1. 次のコマンドを実行して(単一のコマンドにまとめています)、CassandraのStatefulSetに含まれるすべてのリソースを削除します。 + + ```shell + grace=$(kubectl get pod cassandra-0 -o=jsonpath='{.spec.terminationGracePeriodSeconds}') \ + && kubectl delete statefulset -l app=cassandra \ + && echo "Sleeping ${grace} seconds" 1>&2 \ + && sleep $grace \ + && kubectl delete persistentvolumeclaim -l app=cassandra + ``` + +1. 次のコマンドを実行して、CassandraをセットアップしたServiceを削除します。 + + ```shell + kubectl delete service -l app=cassandra + ``` + +## Cassandraコンテナの環境変数 + +このチュートリアルのPodでは、Googleの[コンテナレジストリ](https://cloud.google.com/container-registry/docs/)の[`gcr.io/google-samples/cassandra:v13`](https://github.com/kubernetes/examples/blob/master/cassandra/image/Dockerfile)イメージを使用しました。このDockerイメージは[debian-base](https://github.com/kubernetes/kubernetes/tree/master/build/debian-base)をベースにしており、OpenJDK 8が含まれています。 + +このイメージには、Apache Debianリポジトリの標準のCassandraインストールが含まれます。環境変数を利用すると、`cassandra.yaml`に挿入された値を変更できます。 + +| 環境変数 | デフォルト値 | +| ------------------------ |:---------------: | +| `CASSANDRA_CLUSTER_NAME` | `'Test Cluster'` | +| `CASSANDRA_NUM_TOKENS` | `32` | +| `CASSANDRA_RPC_ADDRESS` | `0.0.0.0` | + + + +## {{% heading "whatsnext" %}} + + +* [StatefulSetのスケール](/ja/docs/tasks/run-application/scale-stateful-set/)を行う方法を学ぶ。 +* [*KubernetesSeedProvider*](https://github.com/kubernetes/examples/blob/master/cassandra/java/src/main/java/io/k8s/cassandra/KubernetesSeedProvider.java)についてもっと学ぶ。 +* カスタムの[Seed Providerの設定](https://git.k8s.io/examples/cassandra/java/README.md)についてもっと学ぶ。 + + + diff --git a/content/ja/docs/tutorials/stateful-application/mysql-wordpress-persistent-volume.md b/content/ja/docs/tutorials/stateful-application/mysql-wordpress-persistent-volume.md new file mode 100644 index 0000000000..7aed33777e --- /dev/null +++ b/content/ja/docs/tutorials/stateful-application/mysql-wordpress-persistent-volume.md @@ -0,0 +1,241 @@ +--- +title: "例: Persistent Volumeを使用したWordpressとMySQLをデプロイする" +content_type: tutorial +weight: 20 +card: + name: tutorials + weight: 40 + title: "ステートフルの例: Persistent Volumeを使用したWordpress" +--- + +<!-- overview --> +このチュートリアルでは、WordPressのサイトとMySQLデータベースをMinikubeを使ってデプロイする方法を紹介します。2つのアプリケーションとも、データを保存するためにPersistentVolumeとPersistentVolumeClaimを使用します。 + +[PersistentVolume](/ja/docs/concepts/storage/persistent-volumes/)(PV)とは、管理者が手動でプロビジョニングを行うか、[StorageClass](/docs/concepts/storage/storage-classes)を使ってKubernetesによって動的にプロビジョニングされた、クラスター内のストレージの一部です。[PersistentVolumeClaim](/ja/docs/concepts/storage/persistent-volumes/#persistentvolumeclaims)(PVC)は、PVによって満たすことができる、ユーザーによるストレージへのリクエストのことです。PersistentVolumeとPersistentVolumeClaimは、Podのライフサイクルからは独立していて、Podの再起動、Podの再スケジューリング、さらにはPodの削除が行われたとしても、その中のデータは削除されずに残ります。 + +{{< warning >}} +シングルインスタンスのWordPressとMySQLのPodを使用しているため、ここで行うデプロイは本番のユースケースには適しません。WordPressを本番環境にデプロイするときは、[WordPress Helm Chart](https://github.com/kubernetes/charts/tree/master/stable/wordpress)を使用することを検討してください。 +{{< /warning >}} + +{{< note >}} +このチュートリアルで提供されるファイルは、GAとなっているDeployment APIを使用しているため、Kubernetesバージョン1.9以降のためのものになっています。もしこのチュートリアルを古いバージョンのKubernetesで使いたい場合は、APIのバージョンを適切にアップデートするか、このチュートリアルの古いバージョンを参照してください。 +{{< /note >}} + + + +## {{% heading "objectives" %}} + +* PersistentVolumeClaimとPersistentVolumeを作成する +* 以下を含む`kustomization.yaml`を作成する + * Secret generator + * MySQLリソースの設定 + * WordPressリソースの設定 +* kustomizationディレクトリを`kubectl apply -k ./`で適用する +* クリーンアップする + + + +## {{% heading "prerequisites" %}} + + +{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}} +このページで示された例は、`kubectl` 1.14以降で動作します。 + +以下の設定ファイルをダウンロードします。 + +1. [mysql-deployment.yaml](/examples/application/wordpress/mysql-deployment.yaml) + +1. [wordpress-deployment.yaml](/examples/application/wordpress/wordpress-deployment.yaml) + + + +<!-- lessoncontent --> + +## PersistentVolumeClaimとPersistentVolumeを作成する + +MySQLとWordpressはそれぞれ、データを保存するためのPersistentVolumeを必要とします。各PersistentVolumeClaimはデプロイの段階で作成されます。 + +多くのクラスタ環境では、デフォルトのStorageClassがインストールされています。StorageClassがPersistentVolumeClaim中で指定されていなかった場合、クラスターのデフォルトのStorageClassが代わりに使われます。 + +PersistentVolumeClaimが作成されるとき、StorageClassの設定に基づいてPersistentVolumeが動的にプロビジョニングされます。 + +{{< warning >}} +ローカルのクラスターでは、デフォルトのStorageClassには`hostPath`プロビジョナーが使われます。`hostPath`ボリュームは開発およびテストにのみ適しています。`hostPath`ボリュームでは、データはPodがスケジュールされたノード上の`/tmp`内に保存されます。そのため、もしPodが死んだり、クラスター上の他のノードにスケジュールされたり、ノードが再起動すると、データは失われます。 +{{< /warning >}} + +{{< note >}} +`hostPath`プロビジョナーを使用する必要があるクラスターを立ち上げたい場合は、`--enable-hostpath-provisioner`フラグを `controller-manager` コンポーネントで設定する必要があります。 +{{< /note >}} + +{{< note >}} +Google Kubernetes Engine上で動作するKubernetesクラスターを使っている場合は、[このガイド](https://cloud.google.com/kubernetes-engine/docs/tutorials/persistent-disk?hl=ja)に従ってください。 +{{< /note >}} + +## kustomization.yamlを作成する + +### Secret generatorを追加する + +[Secret](/docs/concepts/configuration/secret/)とは、パスワードやキーのような機密性の高いデータ片を保存するためのオブジェクトです。バージョン1.14からは、`kubectl`がkustomizationファイルを使用したKubernetesオブジェクトの管理をサポートしています。`kustomization.yaml`内のgeneratorによってSecretを作成することができます。 + +以下のコマンドを実行して、`kustomization.yaml`の中にSecret generatorを追加します。`YOUR_PASSWORD`の部分を使いたいパスワードに置換してください。 + +```shell +cat <<EOF >./kustomization.yaml +secretGenerator: +- name: mysql-pass + literals: + - password=YOUR_PASSWORD +EOF +``` + +## MySQLとWordPressのためのリソースの設定を追加する + +以下のマニフェストには、シングルインスタンスのMySQLのDeploymentが書かれています。MySQLコンテナはPersistentVolumeを`/var/lib/mysql`にマウントします。`MYSQL_ROOT_PASSWORD`環境変数には、Secretから得られたデータベースのパスワードが設定されます。 + +{{< codenew file="application/wordpress/mysql-deployment.yaml" >}} + +以下のマニフェストには、シングルインスタンスのWordPressのDeploymentが書かれています。WordPressコンテナはPersistentVolumeをウェブサイトのデータファイルのために`/var/www/html`にマウントします。`WORDPRESS_DB_HOST`環境変数に上で定義したMySQLのServiceの名前を設定すると、WordPressはServiceによってデータベースにアクセスします。`WORDPRESS_DB_PASSWORD`環境変数には、kustomizeが生成したSecretから得たデータベースのパスワードが設定されます。 + + +{{< codenew file="application/wordpress/wordpress-deployment.yaml" >}} + +1. MySQLのDeploymentの設定ファイルをダウンロードします。 + + ```shell + curl -LO https://k8s.io/examples/application/wordpress/mysql-deployment.yaml + ``` + +2. WordPressの設定ファイルをダウンロードします。 + + ```shell + curl -LO https://k8s.io/examples/application/wordpress/wordpress-deployment.yaml + ``` + +3. これらを`kustomization.yaml`ファイルに追加します。 + +```shell +cat <<EOF >>./kustomization.yaml +resources: + - mysql-deployment.yaml + - wordpress-deployment.yaml +EOF +``` + +## 適用と確認 + +`kustomization.yaml`には、WordPressのサイトとMySQLデータベースのためのすべてのリソースが含まれています。次のコマンドでこのディレクトリを適用できます。 + +```shell +kubectl apply -k ./ +``` + +これで、すべてのオブジェクトが存在していることを確認できます。 + +1. 次のコマンドを実行して、Secretが存在していることを確認します。 + + ```shell + kubectl get secrets + ``` + + 結果は次のようになるはずです。 + + ```shell + NAME TYPE DATA AGE + mysql-pass-c57bb4t7mf Opaque 1 9s + ``` + +1. 次のコマンドを実行して、PersistentVolumeが動的にプロビジョニングされていることを確認します。 + + ```shell + kubectl get pvc + ``` + + {{< note >}} + PVがプロビジョニングされてバインドされるまでに、最大で数分かかる場合があります。 + {{< /note >}} + + 結果は次のようになるはずです。 + + ```shell + NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS AGE + mysql-pv-claim Bound pvc-8cbd7b2e-4044-11e9-b2bb-42010a800002 20Gi RWO standard 77s + wp-pv-claim Bound pvc-8cd0df54-4044-11e9-b2bb-42010a800002 20Gi RWO standard 77s + ``` + +3. 次のコマンドを実行して、Podが実行中であることを確認します。 + + ```shell + kubectl get pods + ``` + + {{< note >}} + PodのStatusが`Running`の状態になる前に、最大で数分かかる場合があります。 + {{< /note >}} + + 結果は次のようになるはずです。 + + ``` + NAME READY STATUS RESTARTS AGE + wordpress-mysql-1894417608-x5dzt 1/1 Running 0 40s + ``` + +4. 次のコマンドを実行して、Serviceが実行中であることを確認します。 + + ```shell + kubectl get services wordpress + ``` + + 結果は次のようになるはずです。 + + ``` + NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE + wordpress ClusterIP 10.0.0.89 <pending> 80:32406/TCP 4m + ``` + + {{< note >}} + MinikubeではServiceを`NodePort`経由でしか公開できません。EXTERNAL-IPは常にpendingのままになります。 + {{< /note >}} + +5. 次のコマンドを実行して、WordPress ServiceのIPアドレスを取得します。 + + ```shell + minikube service wordpress --url + ``` + + 結果は次のようになるはずです。 + + ``` + http://1.2.3.4:32406 + ``` + +6. IPアドレスをコピーして、ブラウザーで読み込み、サイトを表示しましょう。 + + WordPressによりセットアップされた次のスクリーンショットのようなページが表示されるはずです。 + + ![wordpress-init](https://raw.githubusercontent.com/kubernetes/examples/master/mysql-wordpress-pd/WordPress.png) + +{{< warning >}} +WordPressのインストールをこのページのまま放置してはいけません。もしほかのユーザーがこのページを見つけた場合、その人はインスタンス上にウェブサイトをセットアップして、悪意のあるコンテンツの配信に利用できてしまいます。<br/><br/>ユーザー名とパスワードを決めてWordPressをインストールするか、このインスタンスを削除してください。 +{{< /warning >}} + + + +## {{% heading "cleanup" %}} + + +1. 次のコマンドを実行して、Secret、Deployment、Service、およびPersistentVolumeClaimを削除します。 + + ```shell + kubectl delete -k ./ + ``` + + + +## {{% heading "whatsnext" %}} + + +* [イントロスペクションとデバッグ](/docs/tasks/debug-application-cluster/debug-application-introspection/)についてさらに学ぶ +* [Job](/docs/concepts/workloads/controllers/job/)についてさらに学ぶ +* [Portフォワーディング](/docs/tasks/access-application-cluster/port-forward-access-application-cluster/)についてさらに学ぶ +* [コンテナへのシェルを取得する](/ja/docs/tasks/debug-application-cluster/get-shell-running-container/)方法について学ぶ + diff --git a/content/ja/docs/tutorials/stateless-application/guestbook.md b/content/ja/docs/tutorials/stateless-application/guestbook.md new file mode 100644 index 0000000000..e08abdb62c --- /dev/null +++ b/content/ja/docs/tutorials/stateless-application/guestbook.md @@ -0,0 +1,370 @@ +--- +title: "例: Redisを使用したPHPのゲストブックアプリケーションのデプロイ" +content_type: tutorial +weight: 20 +card: + name: tutorials + weight: 30 + title: "ステートレスの例: Redisを使用したPHPのゲストブック" +--- + +<!-- overview --> +このチュートリアルでは、Kubernetesと[Docker](https://www.docker.com/)を使用した、シンプルなマルチティアのウェブアプリケーションのビルドとデプロイの方法を紹介します。この例は、以下のコンポーネントから構成されています。 + +* ゲストブックのエントリーを保存するための、シングルインスタンスの[Redis](https://redis.io/)マスター +* 読み込みデータ配信用の、複数の[レプリケーションされたRedis](https://redis.io/topics/replication)インスタンス +* 複数のウェブフロントエンドのインスタンス + + + +## {{% heading "objectives" %}} + +* Redisのマスターを起動する。 +* Redisのスレーブを起動する。 +* ゲストブックのフロントエンドを起動する。 +* フロントエンドのServiceを公開して表示を確認する。 +* クリーンアップする。 + + +## {{% heading "prerequisites" %}} + + +{{< include "task-tutorial-prereqs.md" >}} + +{{< version-check >}} + + + +<!-- lessoncontent --> + +## Redisのマスターを起動する + +ゲストブックアプリケーションでは、データを保存するためにRedisを使用します。ゲストブックはRedisのマスターインスタンスにデータを書き込み、複数のRedisのスレーブインスタンスからデータを読み込みます。 + +### RedisのマスターのDeploymentを作成する + +以下のマニフェストファイルは、シングルレプリカのRedisのマスターPodを実行するDeploymentコントローラーを指定しています。 + +{{< codenew file="application/guestbook/redis-master-deployment.yaml" >}} + +1. マニフェストファイルをダウンロードしたディレクトリ内で、ターミナルウィンドウを起動します。 +1. `redis-master-deployment.yaml`ファイルから、RedisのマスターのDeploymentを適用します。 + + ```shell + kubectl apply -f https://k8s.io/examples/application/guestbook/redis-master-deployment.yaml + ``` + +1. Podのリストを問い合わせて、RedisのマスターのPodが実行中になっていることを確認します。 + + ```shell + kubectl get pods + ``` + + 結果は次のようになるはずです。 + + ```shell + NAME READY STATUS RESTARTS AGE + redis-master-1068406935-3lswp 1/1 Running 0 28s + ``` + +1. 次のコマンドを実行して、RedisのマスターのPodからログを表示します。 + + ```shell + kubectl logs -f POD-NAME + ``` + +{{< note >}} +POD-NAMEの部分を実際のPodの名前に書き換えてください。 +{{< /note >}} + +### RedisのマスターのServiceを作成する + +ゲストブックアプリケーションは、データを書き込むためにRedisのマスターと通信する必要があります。そのためには、[Service](/docs/concepts/services-networking/service/)を適用して、トラフィックをRedisのマスターのPodへプロキシーしなければなりません。Serviceは、Podにアクセスするためのポリシーを指定します。 + +{{< codenew file="application/guestbook/redis-master-service.yaml" >}} + +1. 次の`redis-master-service.yaml`から、RedisのマスターのServiceを適用します。 + + ```shell + kubectl apply -f https://k8s.io/examples/application/guestbook/redis-master-service.yaml + ``` + +1. Serviceのリストを問い合わせて、RedisのマスターのServiceが実行中になっていることを確認します。 + + ```shell + kubectl get service + ``` + + The response should be similar to this: + + ```shell + NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE + kubernetes ClusterIP 10.0.0.1 <none> 443/TCP 1m + redis-master ClusterIP 10.0.0.151 <none> 6379/TCP 8s + ``` + +{{< note >}} +このマニフェストファイルは、`redis-master`という名前のServiceを、前に定義したラベルにマッチする一連のラベル付きで作成します。これにより、ServiceはネットワークトラフィックをRedisのマスターのPodへとルーティングできるようになります。 +{{< /note >}} + + +## Redisのスレーブを起動する + +Redisのマスターは1つのPodですが、レプリカのRedisのスレーブを追加することで、トラフィックの需要を満たすための高い可用性を持たせることができます。 + +### RedisのスレーブのDeploymentを作成する + +Deploymentはマニフェストファイル内に書かれた設定に基づいてスケールします。ここでは、Deploymentオブジェクトは2つのレプリカを指定しています。 + +もし1つもレプリカが実行されていなければ、このDeploymentは2つのレプリカをコンテナクラスター上で起動します。逆に、もしすでに2つ以上のレプリカが実行されていれば、実行中のレプリカが2つになるようにスケールダウンします。 + +{{< codenew file="application/guestbook/redis-slave-deployment.yaml" >}} + +1. `redis-slave-deployment.yaml`ファイルから、RedisのスレーブのDeploymentを適用します。 + + ```shell + kubectl apply -f https://k8s.io/examples/application/guestbook/redis-slave-deployment.yaml + ``` + +1. Podのリストを問い合わせて、RedisのスレーブのPodが実行中になっていることを確認します。 + + ```shell + kubectl get pods + ``` + + 結果は次のようになるはずです。 + + ```shell + NAME READY STATUS RESTARTS AGE + redis-master-1068406935-3lswp 1/1 Running 0 1m + redis-slave-2005841000-fpvqc 0/1 ContainerCreating 0 6s + redis-slave-2005841000-phfv9 0/1 ContainerCreating 0 6s + ``` + +### RedisのスレーブのServiceを作成する + +ゲストブックアプリケーションは、データを読み込むためにRedisのスレーブと通信する必要があります。Redisのスレーブが発見できるようにするためには、Serviceをセットアップする必要があります。Serviceは一連のPodに対する透過的なロードバランシングを提供します。 + +{{< codenew file="application/guestbook/redis-slave-service.yaml" >}} + +1. 次の`redis-slave-service.yaml`ファイルから、RedisのスレーブのServiceを適用します。 + + ```shell + kubectl apply -f https://k8s.io/examples/application/guestbook/redis-slave-service.yaml + ``` + +1. Serviceのリストを問い合わせて、RedisのスレーブのServiceが実行中になっていることを確認します。 + + ```shell + kubectl get services + ``` + + 結果は次のようになるはずです。 + + ``` + NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE + kubernetes ClusterIP 10.0.0.1 <none> 443/TCP 2m + redis-master ClusterIP 10.0.0.151 <none> 6379/TCP 1m + redis-slave ClusterIP 10.0.0.223 <none> 6379/TCP 6s + ``` + +## ゲストブックのフロントエンドをセットアップして公開する + +ゲストブックアプリケーションには、HTTPリクエストをサーブするPHPで書かれたウェブフロントエンドがあります。このアプリケーションは、書き込みリクエストに対しては`redis-master` Serviceに、読み込みリクエストに対しては`redis-slave` Serviceに接続するように設定されています。 + +### ゲストブックのフロントエンドのDeploymentを作成する + +{{< codenew file="application/guestbook/frontend-deployment.yaml" >}} + +1. `frontend-deployment.yaml`ファイルから、フロントエンドのDeploymentを適用します。 + + ```shell + kubectl apply -f https://k8s.io/examples/application/guestbook/frontend-deployment.yaml + ``` + +1. Podのリストを問い合わせて、3つのフロントエンドのレプリカが実行中になっていることを確認します。 + + ```shell + kubectl get pods -l app=guestbook -l tier=frontend + ``` + + 結果は次のようになるはずです。 + + ``` + NAME READY STATUS RESTARTS AGE + frontend-3823415956-dsvc5 1/1 Running 0 54s + frontend-3823415956-k22zn 1/1 Running 0 54s + frontend-3823415956-w9gbt 1/1 Running 0 54s + ``` + +### フロントエンドのServiceを作成する + +適用した`redis-slave`および`redis-master` Serviceは、コンテナクラスター内部からのみアクセス可能です。これは、デフォルトのServiceのtypeが[ClusterIP](/docs/concepts/services-networking/service/#publishing-services---service-types)であるためです。`ClusterIP`は、Serviceが指している一連のPodに対して1つのIPアドレスを提供します。このIPアドレスはクラスター内部からのみアクセスできます。 + +もしゲストの人にゲストブックにアクセスしてほしいのなら、フロントエンドServiceを外部から見えるように設定しなければなりません。そうすれば、クライアントはコンテナクラスターの外部からServiceにリクエストを送れるようになります。Minikubeでは、Serviceを`NodePort`でのみ公開できます。 + +{{< note >}} +一部のクラウドプロバイダーでは、Google Compute EngineやGoogle Kubernetes Engineなど、外部のロードバランサーをサポートしているものがあります。もしクラウドプロバイダーがロードバランサーをサポートしていて、それを使用したい場合は、`type: NodePort`という行を単に削除またはコメントアウトして、`type: LoadBalancer`のコメントアウトを外せば使用できます。 +{{< /note >}} + +{{< codenew file="application/guestbook/frontend-service.yaml" >}} + +1. `frontend-service.yaml`ファイルから、フロントエンドのServiceを提供します。 + + ```shell + kubectl apply -f https://k8s.io/examples/application/guestbook/frontend-service.yaml + ``` + +1. Serviceのリストを問い合わせて、フロントエンドのServiceが実行中であることを確認します。 + + ```shell + kubectl get services + ``` + + 結果は次のようになるはずです。 + + ``` + NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE + frontend NodePort 10.0.0.112 <none> 80:31323/TCP 6s + kubernetes ClusterIP 10.0.0.1 <none> 443/TCP 4m + redis-master ClusterIP 10.0.0.151 <none> 6379/TCP 2m + redis-slave ClusterIP 10.0.0.223 <none> 6379/TCP 1m + ``` + +### フロントエンドのServiceを`NodePort`経由で表示する + +このアプリケーションをMinikubeやローカルのクラスターにデプロイした場合、ゲストブックを表示するためのIPアドレスを見つける必要があります。 + +1. 次のコマンドを実行すると、フロントエンドServiceに対するIPアドレスを取得できます。 + + ```shell + minikube service frontend --url + ``` + + 結果は次のようになるはずです。 + + ``` + http://192.168.99.100:31323 + ``` + +1. IPアドレスをコピーして、ブラウザー上でページを読み込み、ゲストブックを表示しましょう。 + +### フロントエンドのServiceを`LoadBalancer`経由で表示する + +もし`frontend-service.yaml`マニフェストを`type: LoadBalancer`でデプロイした場合、ゲストブックを表示するためのIPアドレスを見つける必要があります。 + +1. 次のコマンドを実行すると、フロントエンドServiceに対するIPアドレスを取得できます。 + + ```shell + kubectl get service frontend + ``` + + 結果は次のようになるはずです。 + + ``` + NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE + frontend ClusterIP 10.51.242.136 109.197.92.229 80:32372/TCP 1m + ``` + +1. 外部IPアドレス(EXTERNAL-IP)をコピーして、ブラウザー上でページを読み込み、ゲストブックを表示しましょう。 + +## ウェブフロントエンドをスケールする + +サーバーがDeploymentコントローラーを使用するServiceとして定義されているため、スケールアップやスケールダウンは簡単です。 + +1. 次のコマンドを実行すると、フロントエンドのPodの数をスケールアップできます。 + + ```shell + kubectl scale deployment frontend --replicas=5 + ``` + +1. Podのリストを問い合わせて、実行中のフロントエンドのPodの数を確認します。 + + ```shell + kubectl get pods + ``` + + 結果は次のようになるはずです。 + + ``` + NAME READY STATUS RESTARTS AGE + frontend-3823415956-70qj5 1/1 Running 0 5s + frontend-3823415956-dsvc5 1/1 Running 0 54m + frontend-3823415956-k22zn 1/1 Running 0 54m + frontend-3823415956-w9gbt 1/1 Running 0 54m + frontend-3823415956-x2pld 1/1 Running 0 5s + redis-master-1068406935-3lswp 1/1 Running 0 56m + redis-slave-2005841000-fpvqc 1/1 Running 0 55m + redis-slave-2005841000-phfv9 1/1 Running 0 55m + ``` + +1. 次のコマンドを実行すると、フロントエンドのPodの数をスケールダウンできます。 + + ```shell + kubectl scale deployment frontend --replicas=2 + ``` + +1. Podのリストを問い合わせて、実行中のフロントエンドのPodの数を確認します。 + + ```shell + kubectl get pods + ``` + + 結果は次のようになるはずです。 + + ``` + NAME READY STATUS RESTARTS AGE + frontend-3823415956-k22zn 1/1 Running 0 1h + frontend-3823415956-w9gbt 1/1 Running 0 1h + redis-master-1068406935-3lswp 1/1 Running 0 1h + redis-slave-2005841000-fpvqc 1/1 Running 0 1h + redis-slave-2005841000-phfv9 1/1 Running 0 1h + ``` + + + +## {{% heading "cleanup" %}} + +DeploymentとServiceを削除すると、実行中のPodも削除されます。ラベルを使用すると、複数のリソースを1つのコマンドで削除できます。 + +1. 次のコマンドを実行すると、すべてのPod、Deployment、Serviceが削除されます。 + + ```shell + kubectl delete deployment -l app=redis + kubectl delete service -l app=redis + kubectl delete deployment -l app=guestbook + kubectl delete service -l app=guestbook + ``` + + 結果は次のようになるはずです。 + + ``` + deployment.apps "redis-master" deleted + deployment.apps "redis-slave" deleted + service "redis-master" deleted + service "redis-slave" deleted + deployment.apps "frontend" deleted + service "frontend" deleted + ``` + +1. Podのリストを問い合わせて、実行中のPodが存在しないことを確認します。 + + ```shell + kubectl get pods + ``` + + 結果は次のようになるはずです。 + + ``` + No resources found. + ``` + + + +## {{% heading "whatsnext" %}} + +* ゲストブックアプリケーションに対する[ELKによるロギングとモニタリング](/docs/tutorials/stateless-application/guestbook-logs-metrics-with-elk/) +* [Kubernetesの基本](/ja/docs/tutorials/kubernetes-basics/)のインタラクティブチュートリアルを終わらせる +* Kubernetesを使って、[MySQLとWordpressのためにPersistent Volume](/docs/tutorials/stateful-application/mysql-wordpress-persistent-volume/#visit-your-new-wordpress-blog)を使用したブログを作成する +* [サービスとアプリケーションの接続](/ja/docs/concepts/services-networking/connect-applications-service/)についてもっと読む +* [リソースの管理](/docs/concepts/cluster-administration/manage-deployment/#using-labels-effectively)についてもっと読む diff --git a/content/ja/examples/pods/pod-nginx-specific-node.yaml b/content/ja/examples/pods/pod-nginx-specific-node.yaml new file mode 100644 index 0000000000..401814df92 --- /dev/null +++ b/content/ja/examples/pods/pod-nginx-specific-node.yaml @@ -0,0 +1,10 @@ +apiVersion: v1 +kind: Pod +metadata: + name: nginx +spec: + nodeName: foo-node # 特定のノードにPodをスケジューリングする + containers: + - name: nginx + image: nginx + imagePullPolicy: IfNotPresent diff --git a/content/ja/examples/pods/pod-with-toleration.yaml b/content/ja/examples/pods/pod-with-toleration.yaml new file mode 100644 index 0000000000..79f2756a8c --- /dev/null +++ b/content/ja/examples/pods/pod-with-toleration.yaml @@ -0,0 +1,15 @@ +apiVersion: v1 +kind: Pod +metadata: + name: nginx + labels: + env: test +spec: + containers: + - name: nginx + image: nginx + imagePullPolicy: IfNotPresent + tolerations: + - key: "example-key" + operator: "Exists" + effect: "NoSchedule" diff --git a/content/ja/examples/service/networking/dual-stack-default-svc.yaml b/content/ja/examples/service/networking/dual-stack-default-svc.yaml new file mode 100644 index 0000000000..00ed87ba19 --- /dev/null +++ b/content/ja/examples/service/networking/dual-stack-default-svc.yaml @@ -0,0 +1,11 @@ +apiVersion: v1 +kind: Service +metadata: + name: my-service +spec: + selector: + app: MyApp + ports: + - protocol: TCP + port: 80 + targetPort: 9376 \ No newline at end of file diff --git a/content/ja/examples/service/networking/dual-stack-ipv4-svc.yaml b/content/ja/examples/service/networking/dual-stack-ipv4-svc.yaml new file mode 100644 index 0000000000..a875f44d6d --- /dev/null +++ b/content/ja/examples/service/networking/dual-stack-ipv4-svc.yaml @@ -0,0 +1,12 @@ +apiVersion: v1 +kind: Service +metadata: + name: my-service +spec: + ipFamily: IPv4 + selector: + app: MyApp + ports: + - protocol: TCP + port: 80 + targetPort: 9376 \ No newline at end of file diff --git a/content/ja/examples/service/networking/dual-stack-ipv6-lb-svc.yaml b/content/ja/examples/service/networking/dual-stack-ipv6-lb-svc.yaml new file mode 100644 index 0000000000..2586ec9b39 --- /dev/null +++ b/content/ja/examples/service/networking/dual-stack-ipv6-lb-svc.yaml @@ -0,0 +1,15 @@ +apiVersion: v1 +kind: Service +metadata: + name: my-service + labels: + app: MyApp +spec: + ipFamily: IPv6 + type: LoadBalancer + selector: + app: MyApp + ports: + - protocol: TCP + port: 80 + targetPort: 9376 \ No newline at end of file diff --git a/content/ja/examples/service/networking/dual-stack-ipv6-svc.yaml b/content/ja/examples/service/networking/dual-stack-ipv6-svc.yaml new file mode 100644 index 0000000000..2aa0725059 --- /dev/null +++ b/content/ja/examples/service/networking/dual-stack-ipv6-svc.yaml @@ -0,0 +1,12 @@ +apiVersion: v1 +kind: Service +metadata: + name: my-service +spec: + ipFamily: IPv6 + selector: + app: MyApp + ports: + - protocol: TCP + port: 80 + targetPort: 9376 \ No newline at end of file diff --git a/content/ja/training/_index.html b/content/ja/training/_index.html index 8c92ea7f22..6762f56dec 100644 --- a/content/ja/training/_index.html +++ b/content/ja/training/_index.html @@ -1,7 +1,7 @@ --- title: トレーニング bigheader: Kubernetesのトレーニングと資格 -abstract: トレーニングプログラム、資格、及びパートナーについて。 +abstract: トレーニングプログラム、資格、およびパートナーについて。 layout: basic cid: training class: training @@ -18,7 +18,7 @@ class: training </div> <div class="cta-text"> <h2>あなたのクラウドネイティブなキャリアを創る</h2> - <p>Kubernetesはクラウドネイティブムーブメントの中核を担っています。Linux Foundation及びトレーニングパートナーのトレーニングを受け、認定資格を取得することで、キャリアに投資し、Kubernetesを学び、クラウドネイティブプロジェクトを成功に繋げます。</p> + <p>Kubernetesはクラウドネイティブムーブメントの中核を担っています。Linux Foundationおよびトレーニングパートナーのトレーニングを受け、認定資格を取得することで、キャリアに投資し、Kubernetesを学び、クラウドネイティブプロジェクトを成功に繋げます。</p> </div> </div> </div> diff --git a/content/ko/_index.html b/content/ko/_index.html index c8d9d593c1..cde99ff2d3 100644 --- a/content/ko/_index.html +++ b/content/ko/_index.html @@ -41,7 +41,6 @@ Google이 일주일에 수십억 개의 컨테이너들을 운영하게 해준 <button id="desktopShowVideoButton" onclick="kub.showVideo()">Watch Video</button> <br> <br> - <br> <a href="https://events.linuxfoundation.org/kubecon-cloudnativecon-europe/?utm_source=kubernetes.io&utm_medium=nav&utm_campaign=kccnceu20" button id="desktopKCButton">Attend KubeCon in Amsterdam on August 13-16, 2020</a> <br> <br> diff --git a/content/ko/case-studies/adform/index.html b/content/ko/case-studies/adform/index.html index e9a8acc7a2..be35a2d837 100644 --- a/content/ko/case-studies/adform/index.html +++ b/content/ko/case-studies/adform/index.html @@ -12,7 +12,7 @@ quote: > Kubernetes enabled the self-healing and immutable infrastructure. We can do faster releases, so our developers are really happy. They can ship our features faster than before, and that makes our clients happier. --- -<div class="banner1 desktop" style="background-image: url('/images/CaseStudy_adform_banner1.jpg')"> +<div class="banner1 desktop" style="background-image: url('/images/case-studies/adform/banner1.jpg')"> <h1> CASE STUDY:<img src="/images/adform_logo.png" style="width:15%;margin-bottom:0%" class="header_logo"><br> <div class="subhead">Improving Performance and Morale with Cloud Native </div></h1> @@ -66,7 +66,7 @@ The company has a large infrastructure: <a href="https://www.openstack.org/">Ope </div> </section> -<div class="banner3" style="background-image: url('/images/CaseStudy_adform_banner3.jpg')"> +<div class="banner3" style="background-image: url('/images/case-studies/adform/banner3.jpg')"> <div class="banner3text"> "The fact that Cloud Native Computing Foundation incubated Kubernetes was a really big point for us because it was vendor neutral. And we can see that a community really gathers around it. Everyone shares their experiences, their knowledge, and the fact that it’s open source, you can contribute."<span style="font-size:14px;letter-spacing:0.12em;padding-top:20px;text-transform:uppercase;line-height:14px"><br><br>— Edgaras Apšega, IT Systems Engineer, Adform</span> </div> @@ -83,7 +83,7 @@ The first production cluster was launched in the spring of 2018, and is now up t </div> </section> -<div class="banner4" style="background-image: url('/images/CaseStudy_adform_banner4.jpg')"> +<div class="banner4" style="background-image: url('/images/case-studies/adform/banner4.jpg')"> <div class="banner4text"> "Releases are really nice for them, because they just push their code to Git and that’s it. They don’t have to worry about their virtual machines anymore." <span style="font-size:14px;letter-spacing:0.12em;padding-top:20px;text-transform:uppercase;line-height:14px"><br><br>— Andrius Cibulskis, IT Systems Engineer, Adform</span> </div> diff --git a/content/ko/case-studies/capital-one/index.html b/content/ko/case-studies/capital-one/index.html index 773db4869e..f95fb2acc7 100644 --- a/content/ko/case-studies/capital-one/index.html +++ b/content/ko/case-studies/capital-one/index.html @@ -5,7 +5,7 @@ cid: caseStudies css: /css/style_case_studies.css --- -<div class="banner1 desktop" style="background-image: url('/images/CaseStudy_capitalone_banner1.jpg')"> +<div class="banner1 desktop" style="background-image: url('/images/case-studies/capitalone/banner1.jpg')"> <h1> CASE STUDY:<img src="/images/capitalone-logo.png" style="margin-bottom:-2%" class="header_logo"><br> <div class="subhead">Supporting Fast Decisioning Applications with Kubernetes </div></h1> @@ -55,7 +55,7 @@ css: /css/style_case_studies.css </div> </section> -<div class="banner3" style="background-image: url('/images/CaseStudy_capitalone_banner3.jpg')"> +<div class="banner3" style="background-image: url('/images/case-studies/capitalone/banner3.jpg')"> <div class="banner3text"> "We want to provide the tools in the same ecosystem, in a consistent way, rather than have a large custom snowflake ecosystem where every tool needs its own custom deployment. Kubernetes gives us the ability to bring all of these together, so the richness of the open source and even the license community dealing with big data can be corralled." @@ -69,7 +69,7 @@ css: /css/style_case_studies.css </div> </section> -<div class="banner4" style="background-image: url('/images/CaseStudy_capitalone_banner4.jpg')"> +<div class="banner4" style="background-image: url('/images/case-studies/capitalone/banner4.jpg')"> <div class="banner4text"> With Kubernetes, "a team can come to us and we can have them up and running with a basic decisioning app in a fortnight, which before would have taken a whole quarter, if not longer. Kubernetes is a manifold productivity multiplier." </div> diff --git a/content/ko/case-studies/ibm/index.html b/content/ko/case-studies/ibm/index.html index 54e941c9cb..e9a78a9443 100644 --- a/content/ko/case-studies/ibm/index.html +++ b/content/ko/case-studies/ibm/index.html @@ -9,7 +9,7 @@ logo: ibm_featured_logo.svg featured: false --- -<div class="banner1" style="background-image: url('/images/CaseStudy_ibm_banner1.jpg')"> +<div class="banner1" style="background-image: url('/images/case-studies/ibm/banner1.jpg')"> <h1> CASE STUDY:<img src="/images/ibm_logo.png" class="header_logo" style="width:10%"><br> <div class="subhead">Building an Image Trust Service on Kubernetes with Notary and TUF</div></h1> </div> @@ -58,7 +58,7 @@ The availability of image signing "is a huge benefit to security-conscious custo </div> </section> -<div class="banner3" style="background-image: url('/images/CaseStudy_ibm_banner3.jpg')"> +<div class="banner3" style="background-image: url('/images/case-studies/ibm/banner3.jpg')"> <div class="banner3text"> "Image signing is one key part of our Kubernetes container service offering, and our container registry team saw Notary as the de facto way to implement that capability in the current Docker and container ecosystem"<span style="font-size:14px;letter-spacing:2px;text-transform:uppercase;margin-top:5% !important;"><br><br>- Michael Hough, a software developer with the IBM Cloud Container Registry team</span> </div> @@ -75,7 +75,7 @@ The availability of image signing "is a huge benefit to security-conscious custo </div> </section> -<div class="banner4" style="background-image: url('/images/CaseStudy_ibm_banner4.jpg')"> +<div class="banner4" style="background-image: url('/images/case-studies/ibm/banner4.jpg')"> <div class="banner4text"> "With our IBM Cloud Kubernetes as-a-service offering and the admission controller we have made available, it allows both IBM services as well as customers of the IBM public cloud to use security policies to control service deployment."<span style="font-size:14px;letter-spacing:2px;text-transform:uppercase;margin-top:5% !important;"><br><br>- Michael Hough, a software developer with the IBM Cloud Container Registry team</span> </div> diff --git a/content/ko/case-studies/ing/index.html b/content/ko/case-studies/ing/index.html index 6e2648a455..943daec2de 100644 --- a/content/ko/case-studies/ing/index.html +++ b/content/ko/case-studies/ing/index.html @@ -11,7 +11,7 @@ quote: > --- -<div class="banner1" style="background-image: url('/images/CaseStudy_ing_banner1.jpg')"> +<div class="banner1" style="background-image: url('/images/case-studies/ing/banner1.jpg')"> <h1> CASE STUDY:<img src="/images/ing_logo.png" style="margin-bottom:-1.5%;" class="header_logo"><br> <div class="subhead"> Driving Banking Innovation with Cloud Native </div></h1> @@ -58,7 +58,7 @@ quote: > </div> </section> -<div class="banner3" style="background-image: url('/images/CaseStudy_ing_banner3.jpg')"> +<div class="banner3" style="background-image: url('/images/case-studies/ing/banner3.jpg')"> <div class="banner3text"> "We decided to standardize ING on a Kubernetes framework." Everything is run on premise due to banking regulations, he adds, but "we will be building an internal public cloud. We are trying to get on par with what public clouds are doing. That’s one of the reasons we got Kubernetes." <span style="font-size:16px;text-transform:uppercase;letter-spacing:0.1em;"><br><br>— Thijs Ebbers, Infrastructure Architect, ING</span> @@ -72,7 +72,7 @@ quote: > </div> </section> -<div class="banner4" style="background-image: url('/images/CaseStudy_ing_banner4.jpg')"> +<div class="banner4" style="background-image: url('/images/case-studies/ing/banner4.jpg')"> <div class="banner4text"> "We have to run the complete platform of services we need, many routing from different places. We need this Kubernetes framework for deploying the containers, with all those components, monitoring, logging. It’s complex." <span style="font-size:16px;text-transform:uppercase;letter-spacing:0.1em;"><br><br>— Onno Van der Voort, Infrastructure Architect, ING</span> </div> diff --git a/content/ko/case-studies/naic/index.html b/content/ko/case-studies/naic/index.html index d40dd19c77..3deb91e480 100644 --- a/content/ko/case-studies/naic/index.html +++ b/content/ko/case-studies/naic/index.html @@ -9,7 +9,7 @@ logo: naic_featured_logo.png featured: false --- -<div class="banner1" style="background-image: url('/images/CaseStudy_naic_banner1.jpg')"> +<div class="banner1" style="background-image: url('/images/case-studies/naic/banner1.jpg')"> <h1> CASE STUDY:<img src="/images/naic_logo.png" class="header_logo" style="width:18%"><br> <div class="subhead" style="margin-top:1%">A Culture and Technology Transition Enabled by Kubernetes</div></h1> </div> @@ -59,7 +59,7 @@ In addition, NAIC is onboarding teams to the new platform, and those teams have </div> </section> -<div class="banner3" style="background-image: url('/images/CaseStudy_naic_banner3.jpg')"> +<div class="banner3" style="background-image: url('/images/case-studies/naic/banner3.jpg')"> <div class="banner3text"> "In our experience, vendor lock-in and tooling that is highly specific results in less resilient technology with fewer minds working to solve problems and grow the community." <br style="height:25px"><span style="font-size:14px;letter-spacing:2px;text-transform:uppercase;margin-top:5% !important;"><br>- Dan Barker, Chief Enterprise Architect, NAIC</span> </div> @@ -77,7 +77,7 @@ As for other CNCF projects, NAIC is using Prometheus on a small scale and hopes </div> </section> -<div class="banner4" style="background-image: url('/images/CaseStudy_naic_banner4.jpg')"> +<div class="banner4" style="background-image: url('/images/case-studies/naic/banner4.jpg')"> <div class="banner4text"> "We knew that Kubernetes had become the de facto standard for container orchestration. Two major factors for selecting this were the three major cloud vendors hosting their own versions and having it hosted in a neutral party as fully open source."<span style="font-size:14px;letter-spacing:2px;text-transform:uppercase;margin-top:5% !important;"><br><br>- Dan Barker, Chief Enterprise Architect, NAIC</span> </div> diff --git a/content/ko/case-studies/nordstrom/index.html b/content/ko/case-studies/nordstrom/index.html index 5385c2473d..788453de35 100644 --- a/content/ko/case-studies/nordstrom/index.html +++ b/content/ko/case-studies/nordstrom/index.html @@ -5,7 +5,7 @@ cid: caseStudies css: /css/style_case_studies.css --- -<div class="banner1" style="background-image: url('/images/CaseStudy_nordstrom_banner1.jpg')"> +<div class="banner1" style="background-image: url('/images/case-studies/nordstrom/banner1.jpg')"> <h1> CASE STUDY:<img src="/images/nordstrom_logo.png" class="header_logo" style="margin-bottom:-1.5% !important;width:20% !important;"><br> <div class="subhead">Finding Millions in Potential Savings in a Tough Retail Climate @@ -60,7 +60,7 @@ css: /css/style_case_studies.css </div> </section> -<div class="banner3" style="background-image: url('/images/CaseStudy_nordstrom_banner3.jpg')"> +<div class="banner3" style="background-image: url('/images/case-studies/nordstrom/banner3.jpg')"> <div class="banner3text"> "We made a bet that Kubernetes was going to take off, informed by early indicators of community support and project velocity, so we rebuilt our system with Kubernetes at the core," </div> @@ -77,7 +77,7 @@ The benefits were immediate for the teams that came on board. "Teams running on </div> </section> -<div class="banner4" style="background-image: url('/images/CaseStudy_nordstrom_banner4.jpg')"> +<div class="banner4" style="background-image: url('/images/case-studies/nordstrom/banner4.jpg')"> <div class="banner4text"> "Teams running on our Kubernetes cluster loved the fact that they had fewer issues to worry about. They didn’t need to manage infrastructure or operating systems," says Grigoriu. "Early adopters loved the declarative nature of Kubernetes. They loved the reduced surface area they had to deal with." </div> diff --git a/content/ko/case-studies/northwestern-mutual/index.html b/content/ko/case-studies/northwestern-mutual/index.html index dac0ef0d66..47b4bbc7be 100644 --- a/content/ko/case-studies/northwestern-mutual/index.html +++ b/content/ko/case-studies/northwestern-mutual/index.html @@ -5,7 +5,7 @@ cid: caseStudies css: /css/style_case_studies.css --- -<div class="banner1 desktop" style="background-image: url('/images/CaseStudy_northwestern_banner1.jpg')"> +<div class="banner1 desktop" style="background-image: url('/images/case-studies/northwestern/banner1.jpg')"> <h1> CASE STUDY:<img src="/images/northwestern_logo.png" style="margin-bottom:-1%" class="header_logo"><br> <div class="subhead">Cloud Native at Northwestern Mutual @@ -22,7 +22,7 @@ css: /css/style_case_studies.css <div class="cols"> <div class="col1"> <h2>Challenge</h2> - In the spring of 2015, Northwestern Mutual acquired a fintech startup, LearnVest, and decided to take "Northwestern Mutual’s leading products and services and meld it with LearnVest’s digital experience and innovative financial planning platform," says Brad Williams, Director of Engineering for Client Experience, Northwestern Mutual. The company’s existing infrastructure had been optimized for batch workflows hosted on on-prem networks; deployments were very traditional, focused on following a process instead of providing deployment agility. "We had to build a platform that was elastically scalable, but also much more responsive, so we could quickly get data to the client website so our end-customers have the experience they expect," says Williams. + In the spring of 2015, Northwestern Mutual acquired a fintech startup, LearnVest, and decided to take "Northwestern Mutual’s leading products and services and meld it with LearnVest’s digital experience and innovative financial planning platform," says Brad Williams, Director of Engineering for Client Experience, Northwestern Mutual. The company’s existing infrastructure had been optimized for batch workflows hosted on on-prem networks; deployments were very traditional, focused on following a process instead of providing deployment agility. "We had to build a platform that was elastically scalable, but also much more responsive, so we could quickly get data to the client website so our end-customers have the experience they expect," says Williams. <br> <h2>Solution</h2> The platform team came up with a plan for using the public cloud (AWS), Docker containers, and Kubernetes for orchestration. "Kubernetes gave us that base framework so teams can be very autonomous in what they’re building and deliver very quickly and frequently," says Northwestern Mutual Cloud Native Engineer Frank Greco Jr. The team also built and open-sourced <a href="https://github.com/northwesternmutual/kanali">Kanali</a>, a Kubernetes-native API management tool that uses OpenTracing, Jaeger, and gRPC. @@ -53,7 +53,7 @@ In order to give the company’s 4.5 million clients the digital experience they </div> </section> -<div class="banner3" style="background-image: url('/images/CaseStudy_northwestern_banner3.jpg')"> +<div class="banner3" style="background-image: url('/images/case-studies/northwestern/banner3.jpg')"> <div class="banner3text"> "Kubernetes has definitely been the right choice for us. It gave us that base framework so teams can be autonomous in what they’re building and deliver very quickly and frequently." @@ -63,12 +63,12 @@ In order to give the company’s 4.5 million clients the digital experience they <div class="fullcol"> Williams and the rest of the platform team decided that the first step would be to start moving from private data centers to AWS. With a new microservice architecture in mind—and the freedom to implement what was best for the organization—they began using Docker containers. After looking into the various container orchestration options, they went with Kubernetes, even though it was still in beta at the time. "There was some debate whether we should build something ourselves, or just leverage that product and evolve with it," says Northwestern Mutual Cloud Native Engineer Frank Greco Jr. "Kubernetes has definitely been the right choice for us. It gave us that base framework so teams can be autonomous in what they’re building and deliver very quickly and frequently."<br><br> As early adopters, the team had to do a lot of work with Ansible scripts to stand up the cluster. "We had a lot of hard security requirements given the nature of our business," explains Bryan Pfremmer, App Platform Teams Manager, Northwestern Mutual. "We found ourselves running a configuration that very few other people ever tried." The client experience group was the first to use the new platform; today, a few hundred of the company’s 1,500 engineers are using it and more are eager to get on board. -The results have been dramatic. Before, infrastructure deployments could take two weeks; now, it is done in a matter of minutes. Now with a focus on Infrastructure automation, and self-service, "You can take an app to production in that same day if you want to," says Pfremmer. +The results have been dramatic. Before, infrastructure deployments could take two weeks; now, it is done in a matter of minutes. Now with a focus on Infrastructure automation, and self-service, "You can take an app to production in that same day if you want to," says Pfremmer. </div> </section> -<div class="banner4" style="background-image: url('/images/CaseStudy_northwestern_banner4.jpg')"> +<div class="banner4" style="background-image: url('/images/case-studies/northwestern/banner4.jpg')"> <div class="banner4text"> "Now, developers have autonomy, they can use this whenever they want, however they want. It becomes more valuable the more instrumentation downstream that happens, as we mature in it." </div> diff --git a/content/ko/case-studies/ocado/index.html b/content/ko/case-studies/ocado/index.html index 6a930f945c..79ac9bf3a8 100644 --- a/content/ko/case-studies/ocado/index.html +++ b/content/ko/case-studies/ocado/index.html @@ -11,7 +11,7 @@ weight: 4 quote: > People at Ocado Technology have been quite amazed. They ask, ‘Can we do this on a Dev cluster?’ and 10 minutes later we have rolled out something that is deployed across the cluster. The speed from idea to implementation to deployment is amazing. --- -<div class="banner1" style="background-image: url('/images/CaseStudy_ocado_banner1.jpg')"> +<div class="banner1" style="background-image: url('/images/case-studies/ocado/banner1.jpg')"> <h1> CASE STUDY:<img src="/images/ocado_logo.png" class="header_logo"><br> <div class="subhead">Ocado: Running Grocery Warehouses with a Cloud Native Platform</div></h1> </div> @@ -32,7 +32,7 @@ quote: > </div> <div class="col2"> - + <h2>Impact</h2> With Kubernetes, "the speed from idea to implementation to deployment is amazing," says Bryant. "I’ve seen features go from development to production inside of a week now. In the old world, a new application deployment could easily take over a month." And because there are no longer restrictive deployment windows in the warehouses, the rate of deployments has gone from as few as two per week to dozens per week. Ocado has also achieved cost savings because Kubernetes gives the team the ability to have more fine-grained resource allocation. Says DevOps Team Leader Kevin McCormack: "We have more confidence in the resource allocation/separation features of Kubernetes, so we have been able to migrate from around 10 fleet clusters to one Kubernetes cluster." The team also uses <a href="https://prometheus.io/">Prometheus</a> and <a href="https://grafana.com/">Grafana</a> to visualize resource allocation, and makes the data available to developers. "The increased visibility offered by Prometheus means developers are more aware of what they are using and how their use impacts others, especially since we now have one shared cluster," says McCormack. "I’d estimate that we use about 15-25% less hardware resources to host the same applications in Kubernetes in our test environments." @@ -54,7 +54,7 @@ Bryant had already been using Kubernetes with <a href="https://www.codeforlife.e </div> </section> -<div class="banner3" style="background-image: url('/images/CaseStudy_ocado_banner3.jpg')"> +<div class="banner3" style="background-image: url('/images/case-studies/ocado/banner3.jpg')"> <div class="banner3text"> "We were looking for a platform with wide adoption, and that was where the momentum was, the two paths converged, and we didn’t even go through any proof-of-concept stage. The Code for Life work served that purpose," <span style="font-size:14px;letter-spacing:2px;text-transform:uppercase;margin-top:5% !important;"><br><br>- Kevin McCormack, DevOps Team Leader, Ocado</span> </div> @@ -68,7 +68,7 @@ Bryant had already been using Kubernetes with <a href="https://www.codeforlife.e </div> </section> -<div class="banner4" style="background-image: url('/images/CaseStudy_ocado_banner4.jpg')"> +<div class="banner4" style="background-image: url('/images/case-studies/ocado/banner4.jpg')"> <div class="banner4text"> "The unified API of Kubernetes means this is all in one place, and it’s one flow for approval and rollout. I’ve seen features go from development to production inside of a week now. In the old world, a new application deployment could easily take over a month." <span style="font-size:14px;letter-spacing:2px;text-transform:uppercase;margin-top:5% !important;"><br><br>- Mike Bryant, Platform Engineer, Ocado</span> </div> diff --git a/content/ko/case-studies/openAI/index.html b/content/ko/case-studies/openAI/index.html index 040f704efa..1b95ec5f35 100644 --- a/content/ko/case-studies/openAI/index.html +++ b/content/ko/case-studies/openAI/index.html @@ -5,7 +5,7 @@ cid: caseStudies css: /css/style_case_studies.css --- -<div class="banner1 desktop" style="background-image: url('/images/CaseStudy_openAI_banner1.jpg')"> +<div class="banner1 desktop" style="background-image: url('/images/case-studies/openAI/banner1.jpg')"> <h1> CASE STUDY:<img src="/images/openAI_logo.png" style="margin-bottom:-1%" class="header_logo"><br> <div class="subhead">Launching and Scaling Up Experiments, Made Simple </div></h1> @@ -56,7 +56,7 @@ css: /css/style_case_studies.css </div> </section> -<div class="banner3" style="background-image: url('/images/CaseStudy_openAI_banner3.jpg')"> +<div class="banner3" style="background-image: url('/images/case-studies/openAI/banner3.jpg')"> <div class="banner3text"> OpenAI’s experiments take advantage of Kubernetes’ benefits, including portability. "Because Kubernetes provides a consistent API, we can move our research experiments very easily between clusters..." @@ -69,7 +69,7 @@ css: /css/style_case_studies.css </div> </section> -<div class="banner4" style="background-image: url('/images/CaseStudy_openAI_banner4.jpg')"> +<div class="banner4" style="background-image: url('/images/case-studies/openAI/banner4.jpg')"> <div class="banner4text"> "One of our researchers who is working on a new distributed training system has been able to get his experiment running in two or three days," says Berner. "In a week or two he scaled it out to hundreds of GPUs. Previously, that would have easily been a couple of months of work." </div> diff --git a/content/ko/case-studies/pearson/index.html b/content/ko/case-studies/pearson/index.html index ddb567afb3..78f70228e5 100644 --- a/content/ko/case-studies/pearson/index.html +++ b/content/ko/case-studies/pearson/index.html @@ -8,7 +8,7 @@ featured: false quote: > We’re already seeing tremendous benefits with Kubernetes—improved engineering productivity, faster delivery of applications and a simplified infrastructure. But this is just the beginning. Kubernetes will help transform the way that educational content is delivered online. --- -<div class="banner1" style="background-image: url('/images/CaseStudy_pearson_banner1.jpg')"> +<div class="banner1" style="background-image: url('/images/case-studies/pearson/banner1.jpg')"> <h1> CASE STUDY:<img src="/images/pearson_logo.png" style="margin-bottom:-1.5%;" class="header_logo"><br> <div class="subhead">Reinventing the World’s Largest Education Company With Kubernetes </div></h1> </div> @@ -47,7 +47,7 @@ quote: > The team adopted Kubernetes when it was still version 1.2 and are still going strong now on 1.7; they use Terraform and Ansible to deploy it on to basic AWS primitives. "We were trying to understand how we can create value for Pearson from this technology," says Ben Somogyi, Principal Architect for the Cloud Platforms. "It turned out that Kubernetes’ benefits are huge. We’re trying to help our applications development teams that use our platform go faster, so we filled that gap with a CI/CD pipeline that builds their images for them, standardizes them, patches everything up, allows them to deploy their different environments onto the cluster, and obfuscating the details of how difficult the work underneath the covers is." </div> </section> -<div class="banner3" style="background-image: url('/images/CaseStudy_pearson_banner3.jpg')"> +<div class="banner3" style="background-image: url('/images/case-studies/pearson/banner3.jpg')"> <div class="banner3text"> "Your internal customers need to feel like they are choosing the very best option for them. We are experiencing this first hand in the growth of adoption. We are seeing triple-digit, year-on-year growth of the service."<span style="font-size:16px;text-transform:uppercase;letter-spacing:0.1em;"><br><br>— Chris Jackson, Director for Cloud Platforms & SRE at Pearson</span> </div> @@ -60,7 +60,7 @@ quote: > Jackson estimates they’ve achieved a 15-20% boost in productivity for developer teams who adopt the platform. They also see a reduction in the number of customer-impacting incidents. Plus, says Jackson, "Teams who were previously limited to 1-2 releases per academic year can now ship code multiple times per day!" </div> </section> -<div class="banner4" style="background-image: url('/images/CaseStudy_pearson_banner4.jpg')"> +<div class="banner4" style="background-image: url('/images/case-studies/pearson/banner4.jpg')"> <div class="banner4text"> "Teams who were previously limited to 1-2 releases per academic year can now ship code multiple times per day!" <span style="font-size:16px;text-transform:uppercase;letter-spacing:0.1em;"><br><br>— Chris Jackson, Director for Cloud Platforms & SRE at Pearson</span> </div> diff --git a/content/ko/case-studies/pinterest/index.html b/content/ko/case-studies/pinterest/index.html index 0aa2381aa1..e4be7031bb 100644 --- a/content/ko/case-studies/pinterest/index.html +++ b/content/ko/case-studies/pinterest/index.html @@ -11,7 +11,7 @@ quote: > --- -<div class="banner1 desktop" style="background-image: url('/images/CaseStudy_pinterest_banner1.jpg')"> +<div class="banner1 desktop" style="background-image: url('/images/case-studies/pinterest/banner1.jpg')"> <h1> CASE STUDY:<img src="/images/pinterest_logo.png" style="margin-bottom:-1%" class="header_logo"><br> <div class="subhead">Pinning Its Past, Present, and Future on Cloud Native </div></h1> @@ -60,7 +60,7 @@ The first phase involved moving to Docker. "Pinterest has been heavily running o </div> </section> -<div class="banner3" style="background-image: url('/images/CaseStudy_pinterest_banner3.jpg')"> +<div class="banner3" style="background-image: url('/images/case-studies/pinterest/banner3.jpg')"> <div class="banner3text"> "Though Kubernetes lacked certain things we wanted, we realized that by the time we get to productionizing many of those things, we’ll be able to leverage what the community is doing." <span style="font-size:14px;letter-spacing:0.12em;padding-top:20px;text-transform:uppercase;line-height:14px"><br><br>— MICHEAL BENEDICT, PRODUCT MANAGER FOR THE CLOUD AND THE DATA INFRASTRUCTURE GROUP AT PINTEREST</span> </div> @@ -75,7 +75,7 @@ At the beginning of 2018, the team began onboarding its first use case into the </div> </section> -<div class="banner4" style="background-image: url('/images/CaseStudy_pinterest_banner4.jpg')"> +<div class="banner4" style="background-image: url('/images/case-studies/pinterest/banner4.jpg')"> <div class="banner4text"> "So far it’s been good, especially the elasticity around how we can configure our Jenkins workloads on Kubernetes shared cluster. That is the win we were pushing for." <span style="font-size:14px;letter-spacing:0.12em;padding-top:20px;text-transform:uppercase;line-height:14px"><br><br>— MICHEAL BENEDICT, PRODUCT MANAGER FOR THE CLOUD AND THE DATA INFRASTRUCTURE GROUP AT PINTEREST</span> </div> diff --git a/content/ko/case-studies/slingtv/index.html b/content/ko/case-studies/slingtv/index.html index a11527c2d9..349ed8c2de 100644 --- a/content/ko/case-studies/slingtv/index.html +++ b/content/ko/case-studies/slingtv/index.html @@ -11,7 +11,7 @@ quote: > --- -<div class="banner1 desktop" style="background-image: url('/images/CaseStudy_slingtv_banner1.jpg')"> +<div class="banner1 desktop" style="background-image: url('/images/case-studies/slingtv/banner1.jpg')"> <h1> CASE STUDY:<img src="/images/slingtv_logo.png" style="margin-bottom:-1.5%;width:15% !important" class="header_logo"><br> <div class="subhead" style="padding-top:1% !important">Sling TV: Marrying Kubernetes and AI to Enable Proper Web Scale </div></h1> @@ -62,7 +62,7 @@ Led by the belief that “the cloud native architectures and patterns really giv </div> </section> -<div class="banner3" style="background-image: url('/images/CaseStudy_slingtv_banner3.jpg')"> +<div class="banner3" style="background-image: url('/images/case-studies/slingtv/banner3.jpg')"> <div class="banner3text"> “We needed the flexibility to enable our use case versus just a simple orchestrater. Enabling our future in a way that did not give us vendor lock-in was also a key part of our strategy. I think that is part of the Rancher value proposition.” <span style="font-size:14px;letter-spacing:0.12em;padding-top:20px;text-transform:uppercase;line-height:14px"><br><br>— Brad Linder, Cloud Native & Big Data Evangelist for Sling TV</span> </div> @@ -75,7 +75,7 @@ With the emphasis on common tooling, “We are getting to the place where we can </div> </section> -<div class="banner4" style="background-image: url('/images/CaseStudy_slingtv_banner4.jpg')"> +<div class="banner4" style="background-image: url('/images/case-studies/slingtv/banner4.jpg')"> <div class="banner4text"> “We have to be able to react to changes and hiccups in the matrix. It is the foundation for our ability to deliver a high-quality service for our customers." <span style="font-size:14px;letter-spacing:0.12em;padding-top:20px;text-transform:uppercase;line-height:14px"><br><br>— Brad Linder, Cloud Native & Big Data Evangelist for Sling TV</span> </div> diff --git a/content/ko/case-studies/squarespace/index.html b/content/ko/case-studies/squarespace/index.html index d2b2a18c92..27340835f4 100644 --- a/content/ko/case-studies/squarespace/index.html +++ b/content/ko/case-studies/squarespace/index.html @@ -5,7 +5,7 @@ cid: caseStudies css: /css/style_case_studies.css --- -<div class="banner1 desktop" style="background-image: url('/images/CaseStudy_squarespace_banner1.jpg')"> +<div class="banner1 desktop" style="background-image: url('/images/case-studies/squarespace/banner1.jpg')"> <h1> CASE STUDY:<img src="/images/squarespace_logo.png" class="header_logo"><br> <div class="subhead">Squarespace: Gaining Productivity and Resilience with Kubernetes </div></h1> @@ -51,7 +51,7 @@ Since Squarespace moved to Kubernetes, in conjunction with modernizing its netwo </div> </section> -<div class="banner3" style="background-image: url('/images/CaseStudy_squarespace_banner3.jpg')"> +<div class="banner3" style="background-image: url('/images/case-studies/squarespace/banner3.jpg')"> <div class="banner3text"> After experimenting with another container orchestration platform and "breaking it in very painful ways," Lynch says, the team began experimenting with Kubernetes in mid-2016 and found that it "answered all the questions that we had." @@ -68,7 +68,7 @@ Since Squarespace moved to Kubernetes, in conjunction with modernizing its netwo </div> </section> -<div class="banner4" style="background-image: url('/images/CaseStudy_squarespace_banner4.jpg')"> +<div class="banner4" style="background-image: url('/images/case-studies/squarespace/banner4.jpg')"> <div class="banner4text"> "We switched to Kubernetes, a new world....It allowed us to streamline our process, so we can now easily create an entire microservice project from templates," Lynch says. And the whole process takes only five minutes, an almost 85% reduction in time compared to their VM deployment. </div> diff --git a/content/ko/case-studies/workiva/index.html b/content/ko/case-studies/workiva/index.html index 95f323d5ae..1c09503bfb 100644 --- a/content/ko/case-studies/workiva/index.html +++ b/content/ko/case-studies/workiva/index.html @@ -11,7 +11,7 @@ quote: > With OpenTracing, my team was able to look at a trace and make optimization suggestions to another team without ever looking at their code. --- -<div class="banner1 desktop" style="background-image: url('/images/CaseStudy_workiva_banner1.jpg')"> +<div class="banner1 desktop" style="background-image: url('/images/case-studies/workiva/banner1.jpg')"> <h1> CASE STUDY:<img src="/images/workiva_logo.png" style="margin-bottom:0%" class="header_logo"><br> <div class="subhead">Using OpenTracing to Help Pinpoint the Bottlenecks </div></h1> @@ -30,12 +30,12 @@ quote: > <a href="https://www.workiva.com/">Workiva</a> offers a cloud-based platform for managing and reporting business data. This SaaS product, Wdesk, is used by more than 70 percent of the Fortune 500 companies. As the company made the shift from a monolith to a more distributed, microservice-based system, "We had a number of people working on this, all on different teams, so we needed to identify what the issues were and where the bottlenecks were," says Senior Software Architect MacLeod Broad. With back-end code running on Google App Engine, Google Compute Engine, as well as Amazon Web Services, Workiva needed a tracing system that was agnostic of platform. While preparing one of the company’s first products utilizing AWS, which involved a "sync and link" feature that linked data from spreadsheets built in the new application with documents created in the old application on Workiva’s existing system, Broad’s team found an ideal use case for tracing: There were circular dependencies, and optimizations often turned out to be micro-optimizations that didn’t impact overall speed. <br> - + </div> <div class="col2"> <h2>Solution</h2> - Broad’s team introduced the platform-agnostic distributed tracing system OpenTracing to help them pinpoint the bottlenecks. + Broad’s team introduced the platform-agnostic distributed tracing system OpenTracing to help them pinpoint the bottlenecks. <br> <h2>Impact</h2> Now used throughout the company, OpenTracing produced immediate results. Software Engineer Michael Davis reports: "Tracing has given us immediate, actionable insight into how to improve our service. Through a combination of seeing where each call spends its time, as well as which calls are most often used, we were able to reduce our average response time by 95 percent (from 600ms to 30ms) in a single fix." @@ -61,14 +61,14 @@ The challenges faced by Broad’s team may sound familiar to other companies tha </div> </section> -<div class="banner3" style="background-image: url('/images/CaseStudy_workiva_banner3.jpg')"> +<div class="banner3" style="background-image: url('/images/case-studies/workiva/banner3.jpg')"> <div class="banner3text"> "A tracing system can at a glance explain an architecture, narrow down a performance bottleneck and zero in on it, and generally just help direct an investigation at a high level. Being able to do that at a glance is much faster than at a meeting or with three days of debugging, and it’s a lot faster than never figuring out the problem and just moving on."<span style="font-size:14px;letter-spacing:0.12em;padding-top:20px;text-transform:uppercase"><br>— MACLEOD BROAD, SENIOR SOFTWARE ARCHITECT AT WORKIVA</span> </div> </div> <section class="section3"> <div class="fullcol"> - + Simply put, it was an ideal use case for tracing. "A tracing system can at a glance explain an architecture, narrow down a performance bottleneck and zero in on it, and generally just help direct an investigation at a high level," says Broad. "Being able to do that at a glance is much faster than at a meeting or with three days of debugging, and it’s a lot faster than never figuring out the problem and just moving on."<br><br> With Workiva’s back-end code running on <a href="https://cloud.google.com/compute/">Google Compute Engine</a> as well as App Engine and AWS, Broad knew that he needed a tracing system that was platform agnostic. "We were looking at different tracing solutions," he says, "and we decided that because it seemed to be a very evolving market, we didn’t want to get stuck with one vendor. So OpenTracing seemed like the cleanest way to avoid vendor lock-in on what backend we actually had to use."<br><br> Once they introduced OpenTracing into this first use case, Broad says, "The trace made it super obvious where the bottlenecks were." Even though everyone had assumed it was Workiva’s existing code that was slowing things down, that wasn’t exactly the case. "It looked like the existing code was slow only because it was reaching out to our next-generation services, and they were taking a very long time to service all those requests," says Broad. "On the waterfall graph you can see the exact same work being done on every request when it was calling back in. So every service request would look the exact same for every response being paged out. And then it was just a no-brainer of, ‘Why is it doing all this work again?’"<br><br> @@ -78,7 +78,7 @@ Using the insight OpenTracing gave them, "My team was able to look at a trace an </div> </section> -<div class="banner4" style="background-image: url('/images/CaseStudy_workiva_banner4.jpg')"> +<div class="banner4" style="background-image: url('/images/case-studies/workiva/banner4.jpg')"> <div class="banner4text"> "We were looking at different tracing solutions and we decided that because it seemed to be a very evolving market, we didn’t want to get stuck with one vendor. So OpenTracing seemed like the cleanest way to avoid vendor lock-in on what backend we actually had to use." <span style="font-size:14px;letter-spacing:0.12em;padding-top:20px;text-transform:uppercase"><br>— MACLEOD BROAD, SENIOR SOFTWARE ARCHITECT AT WORKIVA</span> </div> @@ -90,7 +90,7 @@ Using the insight OpenTracing gave them, "My team was able to look at a trace an Some teams were won over quickly. "Tracing has given us immediate, actionable insight into how to improve our [Workspaces] service," says Software Engineer Michael Davis. "Through a combination of seeing where each call spends its time, as well as which calls are most often used, we were able to reduce our average response time by 95 percent (from 600ms to 30ms) in a single fix." <br><br> Most of Workiva’s major products are now traced using OpenTracing, with data pushed into <a href="https://cloud.google.com/stackdriver/">Google StackDriver</a>. Even the products that aren’t fully traced have some components and libraries that are. <br><br> Broad points out that because some of the engineers were working on App Engine and already had experience with the platform’s Appstats library for profiling performance, it didn’t take much to get them used to using OpenTracing. But others were a little more reluctant. "The biggest hindrance to adoption I think has been the concern about how much latency is introducing tracing [and StackDriver] going to cost," he says. "People are also very concerned about adding middleware to whatever they’re working on. Questions about passing the context around and how that’s done were common. A lot of our Go developers were fine with it, because they were already doing that in one form or another. Our Java developers were not super keen on doing that because they’d used other systems that didn’t require that."<br><br> -But the benefits clearly outweighed the concerns, and today, Workiva’s official policy is to use tracing." +But the benefits clearly outweighed the concerns, and today, Workiva’s official policy is to use tracing." In fact, Broad believes that tracing naturally fits in with Workiva’s existing logging and metrics systems. "This was the way we presented it internally, and also the way we designed our use," he says. "Our traces are logged in the exact same mechanism as our app metric and logging data, and they get pushed the exact same way. So we treat all that data exactly the same when it’s being created and when it’s being recorded. We have one internal library that we use for logging, telemetry, analytics and tracing." @@ -98,7 +98,7 @@ In fact, Broad believes that tracing naturally fits in with Workiva’s existing <div class="banner5"> <div class="banner5text"> - "Tracing has given us immediate, actionable insight into how to improve our [Workspaces] service. Through a combination of seeing where each call spends its time, as well as which calls are most often used, we were able to reduce our average response time by 95 percent (from 600ms to 30ms) in a single fix." <span style="font-size:14px;letter-spacing:0.12em;padding-top:20px;text-transform:uppercase"><br>— Michael Davis, Software Engineer, Workiva </span> + "Tracing has given us immediate, actionable insight into how to improve our [Workspaces] service. Through a combination of seeing where each call spends its time, as well as which calls are most often used, we were able to reduce our average response time by 95 percent (from 600ms to 30ms) in a single fix." <span style="font-size:14px;letter-spacing:0.12em;padding-top:20px;text-transform:uppercase"><br>— Michael Davis, Software Engineer, Workiva </span> </div> </div> diff --git a/content/ko/case-studies/ygrene/index.html b/content/ko/case-studies/ygrene/index.html index 498dc0ec73..c07443249a 100644 --- a/content/ko/case-studies/ygrene/index.html +++ b/content/ko/case-studies/ygrene/index.html @@ -12,7 +12,7 @@ quote: > We had to change some practices and code, and the way things were built, but we were able to get our main systems onto Kubernetes in a month or so, and then into production within two months. That’s very fast for a finance company. --- -<div class="banner1 desktop" style="background-image: url('/images/CaseStudy_ygrene_banner1.jpg')"> +<div class="banner1 desktop" style="background-image: url('/images/case-studies/ygrene/banner1.jpg')"> <h1> CASE STUDY:<img src="/images/ygrene_logo.png" style="margin-bottom:-1%" class="header_logo"><br> <div class="subhead">Ygrene: Using Cloud Native to Bring Security and Scalability to the Finance Industry </div></h1> @@ -61,7 +61,7 @@ By 2017, deployments and scalability had become pain points. The company was uti </div> </section> -<div class="banner3" style="background-image: url('/images/CaseStudy_ygrene_banner3.jpg')"> +<div class="banner3" style="background-image: url('/images/case-studies/ygrene/banner3.jpg')"> <div class="banner3text"> "CNCF has been an amazing incubator for so many projects. Now we look at its webpage regularly to find out if there are any new, awesome, high-quality projects we can implement into our stack. It’s actually become a hub for us for knowing what software we need to be looking at to make our systems more secure or more scalable."<span style="font-size:14px;letter-spacing:0.12em;padding-top:20px;text-transform:uppercase;line-height:14px"><br><br>— Austin Adams, Development Manager, Ygrene Energy Fund</span> </div> @@ -78,7 +78,7 @@ Notary, in particular, "has been a godsend," says Adams. "We need to know that o </div> </section> -<div class="banner4" style="background-image: url('/images/CaseStudy_ygrene_banner4.jpg')"> +<div class="banner4" style="background-image: url('/images/case-studies/ygrene/banner4.jpg')"> <div class="banner4text"> "We had to change some practices and code, and the way things were built," Adams says, "but we were able to get our main systems onto Kubernetes in a month or so, and then into production within two months. That’s very fast for a finance company."</span> </div> diff --git a/content/ko/docs/concepts/_index.md b/content/ko/docs/concepts/_index.md index 30424ead72..f23bec1529 100644 --- a/content/ko/docs/concepts/_index.md +++ b/content/ko/docs/concepts/_index.md @@ -12,61 +12,3 @@ weight: 40 <!-- body --> - -## 개요 - -쿠버네티스를 사용하려면, *쿠버네티스 API 오브젝트* 로 클러스터에 대해 사용자가 *바라는 상태* 를 기술해야 한다. 어떤 애플리케이션이나 워크로드를 구동시키려고 하는지, 어떤 컨테이너 이미지를 쓰는지, 복제의 수는 몇 개인지, 어떤 네트워크와 디스크 자원을 쓸 수 있도록 할 것인지 등을 의미한다. 바라는 상태를 설정하는 방법은 쿠버네티스 API를 사용해서 오브젝트를 만드는 것인데, 대개 `kubectl`이라는 커맨드라인 인터페이스를 사용한다. 클러스터와 상호 작용하고 바라는 상태를 설정하거나 수정하기 위해서 쿠버네티스 API를 직접 사용할 수도 있다. - -바라는 상태를 설정하면, *쿠버네티스 컨트롤 플레인* 은 Pod Lifecycle Event Generator ([PLEG](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/node/pod-lifecycle-event-generator.md))를 통해 클러스터의 현재 상태를 바라는 상태와 일치시킨다. 그렇게 함으로써, 쿠버네티스가 컨테이너를 시작 또는 재시작하거나, 주어진 애플리케이션의 복제 수를 스케일링하는 등의 다양한 작업을 자동으로 수행한다. 쿠버네티스 컨트롤 플레인은 클러스터에서 실행 중인 프로세스의 묶음(collection)으로 구성된다. - -* **쿠버네티스 마스터**는 클러스터 내 마스터 노드로 지정된 노드 내에서 구동되는 세 개의 프로세스 묶음이다. 해당 프로세스는 [kube-apiserver](/docs/admin/kube-apiserver/), [kube-controller-manager](/docs/admin/kube-controller-manager/) 및 [kube-scheduler](/docs/admin/kube-scheduler/)이다. -* 클러스터 내 마스터 노드가 아닌 각각의 노드는 다음 두 개의 프로세스를 구동시킨다. - * 쿠버네티스 마스터와 통신하는 **[kubelet](/docs/admin/kubelet/)**. - * 각 노드의 쿠버네티스 네트워킹 서비스를 반영하는 네트워크 프록시인 **[kube-proxy](/docs/admin/kube-proxy/)**. - -## 쿠버네티스 오브젝트 - -쿠버네티스는 시스템의 상태를 나타내는 추상 개념을 다수 포함하고 있다. 컨테이너화되어 배포된 애플리케이션과 워크로드, 이에 연관된 네트워크와 디스크 자원, 그 밖에 클러스터가 무엇을 하고 있는지에 대한 정보가 이에 해당한다. 이런 추상 개념은 쿠버네티스 API 내 오브젝트로 표현된다. 보다 자세한 내용은 [쿠버네티스 오브젝트 이해하기](/ko/docs/concepts/overview/working-with-objects/kubernetes-objects/#kubernetes-objects) 문서를 참조한다. - -기초적인 쿠버네티스 오브젝트에는 다음과 같은 것들이 있다. - -* [파드](/ko/docs/concepts/workloads/pods/pod-overview/) -* [서비스](/ko/docs/concepts/services-networking/service/) -* [볼륨](/ko/docs/concepts/storage/volumes/) -* [네임스페이스](/ko/docs/concepts/overview/working-with-objects/namespaces/) - -또한, 쿠버네티스에는 기초 오브젝트를 기반으로, 부가 기능 및 편의 기능을 제공하는 [컨트롤러](/ko/docs/concepts/architecture/controller/)에 의존하는 보다 높은 수준의 추상 개념도 포함되어 있다. 다음이 포함된다. - -* [디플로이먼트](/ko/docs/concepts/workloads/controllers/deployment/) -* [데몬 셋](/ko/docs/concepts/workloads/controllers/daemonset/) -* [스테이트풀 셋](/ko/docs/concepts/workloads/controllers/statefulset/) -* [레플리카 셋](/ko/docs/concepts/workloads/controllers/replicaset/) -* [잡](/ko/docs/concepts/workloads/controllers/jobs-run-to-completion/) - -## 쿠버네티스 컨트롤 플레인 - -쿠버네티스 마스터와 kubelet 프로세스와 같은 쿠버네티스 컨트롤 플레인의 다양한 구성 요소는 쿠버네티스가 클러스터와 통신하는 방식을 관장한다. 컨트롤 플레인은 시스템 내 모든 쿠버네티스 오브젝트의 레코드를 유지하면서, 오브젝트의 상태를 관리하는 제어 루프를 지속적으로 구동시킨다. 컨트롤 플레인의 제어 루프는 클러스터 내 변경이 발생하면 언제라도 응답하고 시스템 내 모든 오브젝트의 실제 상태가 사용자가 바라는 상태와 일치시키기 위한 일을 한다. - -예를 들어, 쿠버네티스 API를 사용해서 디플로이먼트를 만들 때에는, 바라는 상태를 시스템에 신규로 입력해야한다. 쿠버네티스 컨트롤 플레인이 오브젝트 생성을 기록하고, 사용자 지시대로 필요한 애플리케이션을 시작시키고 클러스터 노드에 스케줄링한다. 그래서 결국 클러스터의 실제 상태가 바라는 상태와 일치하게 된다. - -### 쿠버네티스 마스터 - -클러스터에 대해 바라는 상태를 유지할 책임은 쿠버네티스 마스터에 있다. `kubectl` 커맨드라인 인터페이스와 같은 것을 사용해서 쿠버네티스로 상호 작용할 때에는 쿠버네티스 마스터와 통신하고 있는 셈이다. - -> "마스터"는 클러스터 상태를 관리하는 프로세스의 묶음이다. 주로 모든 프로세스는 클러스터 내 단일 노드에서 구동되며, 이 노드가 바로 마스터이다. 마스터는 가용성과 중복을 위해 복제될 수도 있다. - -### 쿠버네티스 노드 - -클러스터 내 노드는 애플리케이션과 클라우드 워크플로우를 구동시키는 머신(VM, 물리 서버 등)이다. 쿠버네티스 마스터는 각 노드를 관리한다. 직접 노드와 직접 상호 작용할 일은 거의 없을 것이다. - - - - -## {{% heading "whatsnext" %}} - - -개념 페이지를 작성하기를 원하면, -개념 페이지 유형과 개념 템플릿에 대한 정보가 있는 -[페이지 템플릿 사용하기](/docs/home/contribute/page-templates/)를 참조한다. - - diff --git a/content/ko/docs/concepts/architecture/_index.md b/content/ko/docs/concepts/architecture/_index.md index cbcb8e810d..4a83cc3c08 100644 --- a/content/ko/docs/concepts/architecture/_index.md +++ b/content/ko/docs/concepts/architecture/_index.md @@ -1,4 +1,6 @@ --- title: "클러스터 아키텍처" weight: 30 +description: > + 쿠버네티스 뒤편의 구조와 설계 개념들 --- diff --git a/content/ko/docs/concepts/architecture/cloud-controller.md b/content/ko/docs/concepts/architecture/cloud-controller.md index 12b1d714e8..b3806591c2 100644 --- a/content/ko/docs/concepts/architecture/cloud-controller.md +++ b/content/ko/docs/concepts/architecture/cloud-controller.md @@ -19,7 +19,6 @@ weight: 40 - <!-- body --> ## 디자인 @@ -31,6 +30,7 @@ weight: 40 프로세스에 여러 {{< glossary_tooltip text="컨트롤러" term_id="controller" >}}를 구현한다. + {{< note >}} 또한 사용자는 클라우드 컨트롤러 매니저를 컨트롤 플레인의 일부가 아닌 쿠버네티스 {{< glossary_tooltip text="애드온" term_id="addons" >}}으로 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 819ee0c384..62fd283b2f 100644 --- a/content/ko/docs/concepts/architecture/control-plane-node-communication.md +++ b/content/ko/docs/concepts/architecture/control-plane-node-communication.md @@ -15,7 +15,7 @@ aliases: <!-- body --> ## 노드에서 컨트롤 플레인으로의 통신 -노드에서 컨트롤 플레인까지의 모든 통신 경로는 API 서버에서 종료된다(다른 마스터 컴포넌트 중 어느 것도 원격 서비스를 노출하도록 설계되지 않았다). 일반적인 배포에서 API 서버는 하나 이상의 클라이언트 [인증](/docs/reference/access-authn-authz/authentication/) 형식이 활성화된 보안 HTTPS 포트(443)에서 원격 연결을 수신하도록 구성된다. +쿠버네티스에는 "허브 앤 스포크(hub-and-spoke)" API 패턴을 가지고 있다. 노드(또는 노드에서 실행되는 파드들)의 모든 API 사용은 API 서버에서 종료된다(다른 컨트롤 플레인 컴포넌트 중 어느 것도 원격 서비스를 노출하도록 설계되지 않았다). API 서버는 하나 이상의 클라이언트 [인증](/docs/reference/access-authn-authz/authentication/) 형식이 활성화된 보안 HTTPS 포트(일반적으로 443)에서 원격 연결을 수신하도록 구성된다. 특히 [익명의 요청](/docs/reference/access-authn-authz/authentication/#anonymous-requests) 또는 [서비스 어카운트 토큰](/docs/reference/access-authn-authz/authentication/#service-account-tokens)이 허용되는 경우, 하나 이상의 [권한 부여](/docs/reference/access-authn-authz/authorization/) 형식을 사용해야 한다. 노드는 유효한 클라이언트 자격 증명과 함께 API 서버에 안전하게 연결할 수 있도록 클러스터에 대한 공개 루트 인증서로 프로비전해야 한다. 예를 들어, 기본 GKE 배포에서, kubelet에 제공되는 클라이언트 자격 증명은 클라이언트 인증서 형식이다. kubelet 클라이언트 인증서의 자동 프로비저닝은 [kubelet TLS 부트스트랩](/docs/reference/command-line-tools-reference/kubelet-tls-bootstrapping/)을 참고한다. @@ -28,9 +28,11 @@ API 서버에 연결하려는 파드는 쿠버네티스가 공개 루트 인증 결과적으로, 노드 및 노드에서 실행되는 파드에서 컨트롤 플레인으로 연결하기 위한 기본 작동 모드는 기본적으로 보호되며 신뢰할 수 없는 네트워크 및/또는 공용 네트워크에서 실행될 수 있다. ## 컨트롤 플레인에서 노드로의 통신 + 컨트롤 플레인(API 서버)에서 노드로는 두 가지 기본 통신 경로가 있다. 첫 번째는 API 서버에서 클러스터의 각 노드에서 실행되는 kubelet 프로세스이다. 두 번째는 API 서버의 프록시 기능을 통해 API 서버에서 모든 노드, 파드 또는 서비스에 이르는 것이다. ### API 서버에서 kubelet으로의 통신 + API 서버에서 kubelet으로의 연결은 다음의 용도로 사용된다. * 파드에 대한 로그를 가져온다. @@ -58,9 +60,10 @@ API 서버에서 노드, 파드 또는 서비스로의 연결은 기본적으로 SSH 터널은 현재 더 이상 사용되지 않으므로 수행 중인 작업이 어떤 것인지 모른다면 사용하면 안된다. Konnectivity 서비스는 이 통신 채널을 대체한다. ### Konnectivity 서비스 + {{< feature-state for_k8s_version="v1.18" state="beta" >}} -SSH 터널을 대체하는 Konnectivity 서비스는 컨트롤 플레인에서 클러스터 통신에 TCP 레벨 프록시를 제공한다. Konnectivity는 컨트롤 플레인 네트워크와 노드 네트워크에서 각각 실행되는 Konnectivity 서버와 Konnectivity 에이전트의 두 부분으로 구성된다. Konnectivity 에이전트는 Konnectivity 서버에 대한 연결을 시작하고 연결을 유지한다. -그런 다음 컨트롤 플레인에서 노드로의 모든 트래픽은 이 연결을 통과한다. +SSH 터널을 대체하는 Konnectivity 서비스는 컨트롤 플레인에서 클러스터 통신에 TCP 레벨 프록시를 제공한다. Konnectivity 서비스는 컨트롤 플레인 네트워크와 노드 네트워크에서 각각 실행되는 Konnectivity 서버와 Konnectivity 에이전트의 두 부분으로 구성된다. Konnectivity 에이전트는 Konnectivity 서버에 대한 연결을 시작하고 네트워크 연결을 유지한다. +Konnectivity 서비스를 활성화한 후, 모든 컨트롤 플레인에서 노드로의 트래픽은 이 연결을 통과한다. -클러스터에서 설정하는 방법에 대해서는 [Konnectivity 서비스 설정](/docs/tasks/setup-konnectivity/)을 참조한다. +[Konnectivity 서비스 태스크](/docs/tasks/extend-kubernetes/setup-konnectivity/)에 따라 클러스터에서 Konnectivity 서비스를 설정한다. diff --git a/content/ko/docs/concepts/architecture/controller.md b/content/ko/docs/concepts/architecture/controller.md index 6688a969d7..7782d27855 100644 --- a/content/ko/docs/concepts/architecture/controller.md +++ b/content/ko/docs/concepts/architecture/controller.md @@ -48,7 +48,7 @@ weight: 30 내장 컨트롤러의 예시이다. 내장 컨트롤러는 클러스터 API 서버와 상호 작용하며 상태를 관리한다. -잡은 단일 {{< glossary_tooltip term_id="pod" >}} 또는 여러 파드를 실행하고, +잡은 단일 {{< glossary_tooltip text="파드" term_id="pod" >}} 또는 여러 파드를 실행하고, 작업을 수행한 다음 중지하는 쿠버네티스 리소스 이다. diff --git a/content/ko/docs/concepts/architecture/nodes.md b/content/ko/docs/concepts/architecture/nodes.md index 197ae71422..7fb92302f9 100644 --- a/content/ko/docs/concepts/architecture/nodes.md +++ b/content/ko/docs/concepts/architecture/nodes.md @@ -31,7 +31,8 @@ weight: 10 1. 노드의 kubelet으로 컨트롤 플레인에 자체 등록 2. 사용자 또는 다른 사용자가 노드 오브젝트를 수동으로 추가 -노드 오브젝트 또는 노드의 kubelet으로 자체 등록한 후 컨트롤 플레인은 새 노드 오브젝트가 유효한지 확인한다. +노드 오브젝트 또는 노드의 kubelet으로 자체 등록한 후 +컨트롤 플레인은 새 노드 오브젝트가 유효한지 확인한다. 예를 들어 다음 JSON 매니페스트에서 노드를 만들려는 경우이다. ```json @@ -61,11 +62,12 @@ kubelet이 노드의 `metadata.name` 필드와 일치하는 API 서버에 등록 노드 오브젝트를 명시적으로 삭제해야한다. {{< /note >}} -노드 오브젝트의 이름은 유효한 [DNS 서브도메인 이름](/ko/docs/concepts/overview/working-with-objects/names/#dns-서브도메인-이름들)이어야 한다. +노드 오브젝트의 이름은 유효한 +[DNS 서브도메인 이름](/ko/docs/concepts/overview/working-with-objects/names/#dns-서브도메인-이름)이어야 한다. ### 노드에 대한 자체-등록 -kubelet 플래그 `--register-node`는 참(기본값)일 경우, kubelet 은 API 서버에 +kubelet 플래그 `--register-node`는 참(기본값)일 경우, kubelet 은 API 서버에 스스로 등록을 시도할 것이다. 이는 대부분의 배포판에 의해 이용되는, 선호하는 패턴이다. 자체-등록에 대해, kubelet은 다음 옵션과 함께 시작된다. @@ -73,7 +75,9 @@ kubelet 플래그 `--register-node`는 참(기본값)일 경우, kubelet 은 API - `--kubeconfig` - apiserver에 스스로 인증하기 위한 자격증명에 대한 경로. - `--cloud-provider` - 자신에 대한 메터데이터를 읽기 위해 어떻게 {{< glossary_tooltip text="클라우드 제공자" term_id="cloud-provider" >}}와 소통할지에 대한 방법. - `--register-node` - 자동으로 API 서버에 등록. - - `--register-with-taints` - 주어진 taint 리스트 (콤마로 분리된 `<key>=<value>:<effect>`)를 가진 노드 등록. `register-node`가 거짓이면 동작 안함. + - `--register-with-taints` - 주어진 {{< glossary_tooltip text="테인트(taint)" term_id="taint" >}} 리스트(콤마로 분리된 `<key>=<value>:<effect>`)를 가진 노드 등록. + + `register-node`가 거짓이면 동작 안 함. - `--node-ip` - 노드의 IP 주소. - `--node-labels` - 클러스터에 노드를 등록할 때 추가 할 {{< glossary_tooltip text="레이블" term_id="label" >}}([NodeRestriction admission plugin](/docs/reference/access-authn-authz/admission-controllers/#noderestriction)에 의해 적용되는 레이블 제한 사항 참고). - `--node-status-update-frequency` - 얼마나 자주 kubelet이 마스터에 노드 상태를 게시할 지 정의. @@ -176,7 +180,7 @@ kubectl describe node <insert-node-name-here> ready 컨디션의 상태가 `pod-eviction-timeout` ({{< glossary_tooltip text="kube-controller-manager" term_id="kube-controller-manager" >}}에 전달된 인수) 보다 더 길게 `Unknown` 또는 `False`로 유지되는 경우, 노드 상에 모든 파드는 노드 컨트롤러에 의해 삭제되도록 스케줄 된다. 기본 축출 타임아웃 기간은 **5분** 이다. 노드에 접근이 불가할 때와 같은 경우, apiserver는 노드 상의 kubelet과 통신이 불가하다. apiserver와의 통신이 재개될 때까지 파드 삭제에 대한 결정은 kubelet에 전해질 수 없다. 그 사이, 삭제되도록 스케줄 되어진 파드는 분할된 노드 상에서 계속 동작할 수도 있다. 노드 컨트롤러가 클러스터 내 동작 중지된 것을 확신할 때까지는 파드를 -강제로 삭제하지 않는다. 파드가 `Terminating` 또는 `Unknown` 상태로 있을 때 접근 불가한 노드 상에서 +강제로 삭제하지 않는다. 파드가 `Terminating` 또는 `Unknown` 상태로 있을 때 접근 불가한 노드 상에서 동작되고 있는 것을 보게 될 수도 있다. 노드가 영구적으로 클러스터에서 삭제되었는지에 대한 여부를 쿠버네티스가 기반 인프라로부터 유추할 수 없는 경우, 노드가 클러스터를 영구적으로 탈퇴하게 되면, 클러스터 관리자는 손수 노드 오브젝트를 삭제해야 할 수도 있다. @@ -184,13 +188,16 @@ ready 컨디션의 상태가 `pod-eviction-timeout` ({{< glossary_tooltip text=" apiserver로부터 삭제되어 그 이름을 사용할 수 있는 결과를 낳는다. 노드 수명주기 컨트롤러는 자동으로 컨디션을 나타내는 -[테인트(taints)](/docs/concepts/scheduling-eviction/taint-and-toleration/)를 생성한다. +[테인트(taints)](/ko/docs/concepts/scheduling-eviction/taint-and-toleration/)를 생성한다. 스케줄러는 파드를 노드에 할당 할 때 노드의 테인트를 고려한다. 또한 파드는 노드의 테인트를 극복(tolerate)할 수 있는 톨러레이션(toleration)을 가질 수 있다. +자세한 내용은 +[컨디션별 노드 테인트하기](/ko/docs/concepts/scheduling-eviction/taint-and-toleration/#컨디션별-노드-테인트하기)를 참조한다. + ### 용량과 할당가능 {#capacity} -노드 상에 사용 가능한 리소스를 나타낸다. 리소스에는 CPU, 메모리 그리고 +노드 상에 사용 가능한 리소스를 나타낸다. 리소스에는 CPU, 메모리 그리고 노드 상으로 스케줄 되어질 수 있는 최대 파드 수가 있다. 용량 블록의 필드는 노드에 있는 리소스의 총량을 나타낸다. @@ -201,7 +208,7 @@ apiserver로부터 삭제되어 그 이름을 사용할 수 있는 결과를 낳 [컴퓨팅 리소스 예약](/docs/tasks/administer-cluster/reserve-compute-resources/#node-allocatable)하는 방법을 배우는 동안 용량 및 할당가능 리소스에 대해 자세히 읽어보자. -### 정보 {#info} +### 정보 커널 버전, 쿠버네티스 버전 (kubelet과 kube-proxy 버전), (사용하는 경우) Docker 버전, OS 이름과 같은노드에 대한 일반적인 정보를 보여준다. 이 정보는 Kubelet에 의해 노드로부터 수집된다. @@ -214,18 +221,18 @@ apiserver로부터 삭제되어 그 이름을 사용할 수 있는 결과를 낳 노드 컨트롤러는 노드가 생성되어 유지되는 동안 다양한 역할을 한다. 첫째는 등록 시점에 (CIDR 할당이 사용토록 설정된 경우) 노드에 CIDR 블럭을 할당하는 것이다. -두 번째는 노드 컨트롤러의 내부 노드 리스트를 클라우드 제공사업자의 -사용 가능한 머신 리스트 정보를 근거로 최신상태로 유지하는 것이다. 클라우드 환경에서 -동작 중일 경우, 노드상태가 불량할 때마다, 노드 컨트롤러는 -해당 노드용 VM이 여전히 사용 가능한지에 대해 클라우드 제공사업자에게 묻는다. 사용 가능하지 않을 경우, +두 번째는 노드 컨트롤러의 내부 노드 리스트를 클라우드 제공사업자의 +사용 가능한 머신 리스트 정보를 근거로 최신상태로 유지하는 것이다. 클라우드 환경에서 +동작 중일 경우, 노드상태가 불량할 때마다, 노드 컨트롤러는 +해당 노드용 VM이 여전히 사용 가능한지에 대해 클라우드 제공사업자에게 묻는다. 사용 가능하지 않을 경우, 노드 컨트롤러는 노드 리스트로부터 그 노드를 삭제한다. -세 번째는 노드의 동작 상태를 모니터링 하는 것이다. 노드 컨트롤러는 -노드가 접근 불가할 경우 (즉 노드 컨트롤러가 어떠한 사유로 하트비트 +세 번째는 노드의 동작 상태를 모니터링 하는 것이다. 노드 컨트롤러는 +노드가 접근 불가할 경우 (즉 노드 컨트롤러가 어떠한 사유로 하트비트 수신을 중지하는 경우, 예를 들어 노드 다운과 같은 경우이다.) -NodeStatus의 NodeReady 컨디션을 ConditionUnknown으로 업데이트 하는 책임을 지고, -노드가 계속 접근 불가할 경우 나중에 노드로부터 (정상적인 종료를 이용하여) 모든 파드를 축출시킨다. -(ConditionUnknown을 알리기 시작하는 기본 타임아웃 값은 40초 이고, +NodeStatus의 NodeReady 컨디션을 ConditionUnknown으로 업데이트 하는 책임을 지고, +노드가 계속 접근 불가할 경우 나중에 노드로부터 (정상적인 종료를 이용하여) 모든 파드를 축출시킨다. +(ConditionUnknown을 알리기 시작하는 기본 타임아웃 값은 40초 이고, 파드를 축출하기 시작하는 값은 5분이다.) 노드 컨트롤러는 매 `--node-monitor-period` 초 마다 각 노드의 상태를 체크한다. @@ -253,30 +260,30 @@ kubelet은 `NodeStatus` 와 리스 오브젝트를 생성하고 업데이트 할 #### 안정성 - 대부분의 경우, 노드 컨트롤러는 초당 `--node-eviction-rate`(기본값 0.1)로 -축출 비율을 제한한다. 이 말은 10초당 1개의 노드를 초과하여 + 대부분의 경우, 노드 컨트롤러는 초당 `--node-eviction-rate`(기본값 0.1)로 +축출 비율을 제한한다. 이 말은 10초당 1개의 노드를 초과하여 파드 축출을 하지 않는다는 의미가 된다. 노드 축출 행위는 주어진 가용성 영역 내 하나의 노드가 상태가 불량할 -경우 변화한다. 노드 컨트롤러는 영역 내 동시에 상태가 불량한 노드의 퍼센티지가 얼마나 되는지 -체크한다(NodeReady 컨디션은 ConditionUnknown 또는 ConditionFalse 다.). -상태가 불량한 노드의 일부가 최소 +경우 변화한다. 노드 컨트롤러는 영역 내 동시에 상태가 불량한 노드의 퍼센티지가 얼마나 되는지 +체크한다(NodeReady 컨디션은 ConditionUnknown 또는 ConditionFalse 다.). +상태가 불량한 노드의 일부가 최소 `--unhealthy-zone-threshold` 기본값 0.55) 가 -되면 축출 비율은 감소한다. 클러스터가 작으면 (즉 -`--large-cluster-size-threshold` 노드 이하면 - 기본값 50) 축출은 중지되고, -그렇지 않으면 축출 비율은 초당 -`--secondary-node-eviction-rate`(기본값 0.01)로 감소된다. -이 정책들이 가용성 영역 단위로 실행되어지는 이유는 나머지가 연결되어 있는 동안 -하나의 가용성 영역이 마스터로부터 분할되어 질 수도 있기 때문이다. -만약 클러스터가 여러 클라우드 제공사업자의 가용성 영역에 걸쳐 있지 않으면, +되면 축출 비율은 감소한다. 클러스터가 작으면 (즉 +`--large-cluster-size-threshold` 노드 이하면 - 기본값 50) 축출은 중지되고, +그렇지 않으면 축출 비율은 초당 +`--secondary-node-eviction-rate`(기본값 0.01)로 감소된다. +이 정책들이 가용성 영역 단위로 실행되어지는 이유는 나머지가 연결되어 있는 동안 +하나의 가용성 영역이 마스터로부터 분할되어 질 수도 있기 때문이다. +만약 클러스터가 여러 클라우드 제공사업자의 가용성 영역에 걸쳐 있지 않으면, 오직 하나의 가용성 영역만 (전체 클러스터) 존재하게 된다. -노드가 가용성 영역들에 걸쳐 퍼져 있는 주된 이유는 하나의 전체 영역이 -장애가 발생할 경우 워크로드가 상태 양호한 영역으로 이전되어질 수 있도록 하기 위해서이다. -그러므로, 하나의 영역 내 모든 노드들이 상태가 불량하면 노드 컨트롤러는 -`--node-eviction-rate` 의 정상 비율로 축출한다. 코너 케이스란 모든 영역이 -완전히 상태불량 (즉 클러스터 내 양호한 노드가 없는 경우) 한 경우이다. -이러한 경우, 노드 컨트롤러는 마스터 연결에 문제가 있어 일부 연결이 +노드가 가용성 영역들에 걸쳐 퍼져 있는 주된 이유는 하나의 전체 영역이 +장애가 발생할 경우 워크로드가 상태 양호한 영역으로 이전되어질 수 있도록 하기 위해서이다. +그러므로, 하나의 영역 내 모든 노드들이 상태가 불량하면 노드 컨트롤러는 +`--node-eviction-rate` 의 정상 비율로 축출한다. 코너 케이스란 모든 영역이 +완전히 상태불량 (즉 클러스터 내 양호한 노드가 없는 경우) 한 경우이다. +이러한 경우, 노드 컨트롤러는 마스터 연결에 문제가 있어 일부 연결이 복원될 때까지 모든 축출을 중지하는 것으로 여긴다. 또한, 노드 컨트롤러는 파드가 테인트를 허용하지 않을 때 `NoExecute` 테인트 상태의 @@ -285,6 +292,7 @@ kubelet은 `NodeStatus` 와 리스 오브젝트를 생성하고 업데이트 할 {{< glossary_tooltip text="테인트" term_id="taint" >}}를 추가한다. 이는 스케줄러가 비정상적인 노드에 파드를 배치하지 않게 된다. + {{< caution >}} `kubectl cordon` 은 노드를 'unschedulable'로 표기하는데, 이는 서비스 컨트롤러가 이전에 자격 있는 로드밸런서 노드 대상 목록에서 해당 노드를 제거하기에 @@ -315,10 +323,9 @@ kubelet은 `NodeStatus` 와 리스 오브젝트를 생성하고 업데이트 할 {{< feature-state state="alpha" for_k8s_version="v1.16" >}} -`TopologyManager` -[기능 게이트(feature gate)](/docs/reference/command-line-tools-reference/feature-gates/)를 +`TopologyManager` +[기능 게이트(feature gate)](/ko/docs/reference/command-line-tools-reference/feature-gates/)를 활성화 시켜두면, kubelet이 리소스 할당 결정을 할 때 토폴로지 힌트를 사용할 수 있다. - 자세한 내용은 [노드의 컨트롤 토폴로지 관리 정책](/docs/tasks/administer-cluster/topology-manager/)을 본다. @@ -331,4 +338,3 @@ kubelet은 `NodeStatus` 와 리스 오브젝트를 생성하고 업데이트 할 섹션을 읽어본다. * [테인트와 톨러레이션](/ko/docs/concepts/configuration/taint-and-toleration/)을 읽어본다. * [클러스터 오토스케일링](/ko/docs/tasks/administer-cluster/cluster-management/#클러스터-오토스케일링)을 읽어본다. - diff --git a/content/ko/docs/concepts/cluster-administration/_index.md b/content/ko/docs/concepts/cluster-administration/_index.md index e13a5fdb48..c21e17e3ec 100755 --- a/content/ko/docs/concepts/cluster-administration/_index.md +++ b/content/ko/docs/concepts/cluster-administration/_index.md @@ -1,5 +1,71 @@ --- -title: "클러스터 관리" +title: 클러스터 관리 weight: 100 +content_type: concept +description: > + 쿠버네티스 클러스터 생성 또는 관리에 관련된 로우-레벨(lower-level)의 세부 정보를 설명한다. +no_list: true --- +<!-- overview --> +클러스터 관리 개요는 쿠버네티스 클러스터를 생성하거나 관리하는 모든 사람들을 위한 것이다. +핵심 쿠버네티스 [개념](/ko/docs/concepts/)에 어느 정도 익숙하다고 가정한다. + +<!-- body --> +## 클러스터 계획 + +쿠버네티스 클러스터를 계획, 설정 및 구성하는 방법에 대한 예는 [시작하기](/ko/docs/setup/)에 있는 가이드를 참고한다. 이 문서에 나열된 솔루션을 *배포판* 이라고 한다. + + {{< note >}} + 모든 배포판이 활발하게 유지되는 것은 아니다. 최신 버전의 쿠버네티스에서 테스트된 배포판을 선택한다. + {{< /note >}} + +가이드를 선택하기 전에 고려해야 할 사항은 다음과 같다. + + - 컴퓨터에서 쿠버네티스를 그냥 한번 사용해보고 싶은가? 아니면, 고가용 멀티 노드 클러스터를 만들고 싶은가? 사용자의 필요에 따라 가장 적합한 배포판을 선택한다. + - [구글 쿠버네티스 엔진(Google Kubernetes Engine)](https://cloud.google.com/kubernetes-engine/)과 같은 클라우드 제공자의 **쿠버네티스 클러스터 호스팅** 을 사용할 것인가? 아니면, **자체 클러스터를 호스팅** 할 것인가? + - 클러스터가 **온-프레미스 환경** 에 있나? 아니면, **클라우드(IaaS)** 에 있나? 쿠버네티스는 하이브리드 클러스터를 직접 지원하지는 않는다. 대신 여러 클러스터를 설정할 수 있다. + - **온-프레미스 환경에 쿠버네티스** 를 구성하는 경우, 어떤 [네트워킹 모델](/ko/docs/concepts/cluster-administration/networking/)이 가장 적합한 지 고려한다. + - 쿠버네티스를 **"베어 메탈" 하드웨어** 에서 실행할 것인가? 아니면, **가상 머신(VM)** 에서 실행할 것인가? + - **단지 클러스터만 실행할 것인가?** 아니면, **쿠버네티스 프로젝트 코드를 적극적으로 개발** 하는 것을 기대하는가? 만약 + 후자라면, 활발하게 개발이 진행되고 있는 배포판을 선택한다. 일부 배포판은 바이너리 릴리스만 사용하지만, + 더 다양한 선택을 제공한다. + - 클러스터를 실행하는 데 필요한 [컴포넌트](/ko/docs/concepts/overview/components/)에 익숙해지자. + + +## 클러스터 관리 + +* [클러스터 관리](/ko/docs/tasks/administer-cluster/cluster-management/)는 클러스터 라이프사이클과 관련된 몇 가지 주제를 설명한다. 새로운 클러스터 생성, 클러스터의 마스터 및 워커 노드 업그레이드, 노드 유지 관리 수행(예: 커널 업그레이드) 및 실행 중인 클러스터의 쿠버네티스 API 버전 업그레이드 + +* [노드 관리](/ko/docs/concepts/architecture/nodes/) 방법을 배운다. + +* 공유 클러스터에 대한 [리소스 쿼터](/ko/docs/concepts/policy/resource-quotas/)를 설정하고 관리하는 방법을 배운다. + +## 클러스터 보안 + +* [인증서](/ko/docs/concepts/cluster-administration/certificates/)는 다른 툴 체인을 사용하여 인증서를 생성하는 단계를 설명한다. + +* [쿠버네티스 컨테이너 환경](/ko/docs/concepts/containers/container-environment/)은 쿠버네티스 노드에서 Kubelet으로 관리하는 컨테이너에 대한 환경을 설명한다. + +* [쿠버네티스 API에 대한 접근 제어](/docs/reference/access-authn-authz/controlling-access/)는 사용자와 서비스 어카운트에 대한 권한을 설정하는 방법을 설명한다. + +* [인증](/docs/reference/access-authn-authz/authentication/)은 다양한 인증 옵션을 포함한 쿠버네티스에서의 인증에 대해 설명한다. + +* [인가](/docs/reference/access-authn-authz/authorization/)는 인증과는 별개로, HTTP 호출 처리 방법을 제어한다. + +* [어드미션 컨트롤러 사용하기](/docs/reference/access-authn-authz/admission-controllers/)는 인증과 권한 부여 후 쿠버네티스 API 서버에 대한 요청을 가로채는 플러그인에 대해 설명한다. + +* [쿠버네티스 클러스터에서 Sysctls 사용하기](/docs/concepts/cluster-administration/sysctl-cluster/)는 관리자가 `sysctl` 커맨드라인 도구를 사용하여 커널 파라미터를 설정하는 방법에 대해 설명한다. + +* [감사(audit)](/docs/tasks/debug-application-cluster/audit/)는 쿠버네티스의 감사 로그를 다루는 방법에 대해 설명한다. + +### kubelet 보안 + * [마스터-노드 통신](/ko/docs/concepts/architecture/control-plane-node-communication/) + * [TLS 부트스트래핑(bootstrapping)](/docs/reference/command-line-tools-reference/kubelet-tls-bootstrapping/) + * [Kubelet 인증/인가](/docs/admin/kubelet-authentication-authorization/) + +## 선택적 클러스터 서비스 + +* [DNS 통합](/ko/docs/concepts/services-networking/dns-pod-service/)은 DNS 이름을 쿠버네티스 서비스로 직접 확인하는 방법을 설명한다. + +* [클러스터 액티비티 로깅과 모니터링](/ko/docs/concepts/cluster-administration/logging/)은 쿠버네티스에서의 로깅이 어떻게 작동하는지와 구현 방법에 대해 설명한다. diff --git a/content/ko/docs/concepts/cluster-administration/addons.md b/content/ko/docs/concepts/cluster-administration/addons.md index 9e6f5ab7ec..1838688d38 100644 --- a/content/ko/docs/concepts/cluster-administration/addons.md +++ b/content/ko/docs/concepts/cluster-administration/addons.md @@ -33,7 +33,7 @@ content_type: concept * [OVN4NFV-K8S-Plugin](https://github.com/opnfv/ovn4nfv-k8s-plugin)은 OVN 기반의 CNI 컨트롤러 플러그인으로 클라우드 네이티브 기반 서비스 기능 체인(Service function chaining(SFC)), 다중 OVN 오버레이 네트워킹, 동적 서브넷 생성, 동적 가상 네트워크 생성, VLAN 공급자 네트워크, 직접 공급자 네트워크와 멀티 클러스터 네트워킹의 엣지 기반 클라우드 등 네이티브 워크로드에 이상적인 멀티 네티워크 플러그인이다. * [NSX-T](https://docs.vmware.com/en/VMware-NSX-T/2.0/nsxt_20_ncp_kubernetes.pdf) 컨테이너 플러그인(NCP)은 VMware NSX-T와 쿠버네티스와 같은 컨테이너 오케스트레이터 간의 통합은 물론 NSX-T와 PKS(Pivotal 컨테이너 서비스) 및 OpenShift와 같은 컨테이너 기반 CaaS/PaaS 플랫폼 간의 통합을 제공한다. * [Nuage](https://github.com/nuagenetworks/nuage-kubernetes/blob/v5.1.1-1/docs/kubernetes-1-installation.rst)는 가시성과 보안 모니터링 기능을 통해 쿠버네티스 파드와 비-쿠버네티스 환경 간에 폴리시 기반 네트워킹을 제공하는 SDN 플랫폼이다. -* [Romana](http://romana.io)는 [네트워크폴리시 API](/docs/concepts/services-networking/network-policies/)도 지원하는 파드 네트워크용 Layer 3 네트워킹 솔루션이다. Kubeadm 애드온 설치에 대한 세부 정보는 [여기](https://github.com/romana/romana/tree/master/containerize)에 있다. +* [Romana](http://romana.io)는 [네트워크폴리시 API](/ko/docs/concepts/services-networking/network-policies/)도 지원하는 파드 네트워크용 Layer 3 네트워킹 솔루션이다. Kubeadm 애드온 설치에 대한 세부 정보는 [여기](https://github.com/romana/romana/tree/master/containerize)에 있다. * [Weave Net](https://www.weave.works/docs/net/latest/kube-addon/)은 네트워킹 및 네트워크 폴리시를 제공하고, 네트워크 파티션의 양면에서 작업을 수행하며, 외부 데이터베이스는 필요하지 않다. ## 서비스 검색 @@ -54,5 +54,3 @@ content_type: concept 더 이상 사용되지 않는 [cluster/addons](https://git.k8s.io/kubernetes/cluster/addons) 디렉터리에 다른 여러 애드온이 문서화되어 있다. 잘 관리된 것들이 여기에 연결되어 있어야 한다. PR을 환영한다! - - diff --git a/content/ko/docs/concepts/cluster-administration/cloud-providers.md b/content/ko/docs/concepts/cluster-administration/cloud-providers.md index 30dc7b230e..3d5ba7e9d0 100644 --- a/content/ko/docs/concepts/cluster-administration/cloud-providers.md +++ b/content/ko/docs/concepts/cluster-administration/cloud-providers.md @@ -99,7 +99,7 @@ _어노테이션_ 을 사용하여 AWS의 로드 밸런서 서비스에 다른 * `service.beta.kubernetes.io/aws-load-balancer-connection-draining-timeout`: 서비스에서 연결 드레이닝 타임아웃 값을 지정하는 데 사용된다. * `service.beta.kubernetes.io/aws-load-balancer-connection-idle-timeout`: 서비스에서 유휴 연결 타임아웃 값을 지정하는 데 사용된다. * `service.beta.kubernetes.io/aws-load-balancer-cross-zone-load-balancing-enabled`: 서비스에서 교차 영역의 로드 밸런싱을 활성화하거나 비활성화하는 데 사용된다. -* `service.beta.kubernetes.io/aws-load-balancer-security-groups`: 생성된 ELB에 추가할 보안 그룹을 지정하는 데 사용된다. 이는 이전에 ELB에 할당된 다른 모든 보안 그룹을 대체한다. +* `service.beta.kubernetes.io/aws-load-balancer-security-groups`: 생성된 ELB에 추가할 보안 그룹을 지정하는 데 사용된다. 이는 이전에 ELB에 할당된 다른 모든 보안 그룹을 대체한다. 여기에 정의된 보안 그룹은 서비스 간에 공유해서는 안된다. * `service.beta.kubernetes.io/aws-load-balancer-extra-security-groups`: 서비스에서 생성된 ELB에 추가할 추가적인 보안 그룹을 지정하는 데 사용된다. * `service.beta.kubernetes.io/aws-load-balancer-internal`: 서비스에서 내부 ELB 사용 희망을 표시하기 위해 사용된다. * `service.beta.kubernetes.io/aws-load-balancer-proxy-protocol`: 서비스에서 ELB에서 프록시 프로토콜을 활성화하는 데 사용된다. 현재는 모든 ELB 백엔드에서 프록시 프로토콜을 사용하도록 설정하는 `*` 값만 허용한다. 향후에는 특정 백엔드에서만 프록시 프로토콜을 설정할 수 있도록 이를 조정할 수 있게 된다. @@ -134,13 +134,13 @@ CloudStack 클라우드 제공자는 쿠버네티스 노드 오브젝트의 이 GCE 클라우드 제공자는 쿠버네티스 노드 오브젝트의 이름으로 노드의 (kubelet에 의해 결정되거나 `--hostname-override` 로 재정의된) 호스트 이름을 사용한다. 참고로 쿠버네티스 노드 이름의 첫 번째 세그먼트는 GCE 인스턴스 이름과 일치해야 한다(예: `kubernetes-node-2.c.my-proj.internal` 이름이 지정된 노드는 `kubernetes-node-2` 이름이 지정된 인스턴스에 해당해야 함). -## HUAWEI 클라우드 +## HUAWEI CLOUD 외부 클라우드 제공자를 사용하려는 경우, 해당 리포지터리는 [kubernetes-sigs/cloud-provider-huaweicloud](https://github.com/kubernetes-sigs/cloud-provider-huaweicloud)이다. ### 노드 이름 -HUAWEI 클라우드 제공자는 쿠버네티스 노드 오브젝트의 이름으로 노드의 프라이빗 IP 주소가 필요하다. +HUAWEI CLOUD 제공자는 쿠버네티스 노드 오브젝트의 이름으로 노드의 프라이빗 IP 주소가 필요하다. 노드에서 kubelet을 시작할 때 반드시 `--hostname-override=<node private IP>` 를 사용한다. ## OpenStack @@ -415,6 +415,7 @@ Baidu 클라우드 제공자는 쿠버네티스 노드 오브젝트의 이름으 참고로 쿠버네티스 노드 이름은 Baidu VM 프라이빗 IP와 일치해야 한다. ## Tencent 쿠버네티스 엔진 + 이 외부 클라우드 제공자를 사용하려는 경우, 해당 리포지터리는 [TencentCloud/tencentcloud-cloud-controller-manager](https://github.com/TencentCloud/tencentcloud-cloud-controller-manager)이다. ### 노드 이름 diff --git a/content/ko/docs/concepts/cluster-administration/cluster-administration-overview.md b/content/ko/docs/concepts/cluster-administration/cluster-administration-overview.md deleted file mode 100644 index d454b85ca0..0000000000 --- a/content/ko/docs/concepts/cluster-administration/cluster-administration-overview.md +++ /dev/null @@ -1,68 +0,0 @@ ---- -title: 클러스터 관리 개요 -content_type: concept -weight: 10 ---- - -<!-- overview --> -클러스터 관리 개요는 쿠버네티스 클러스터를 만들거나 관리하는 모든 사람들을 위한 것이다. -여기서는 쿠버네티스의 핵심 [개념](/ko/docs/concepts/)에 대해 잘 알고 있다고 가정한다. - - -<!-- body --> -## 클러스터 계획 - -[올바른 솔루션 고르기](/ko/docs/setup/pick-right-solution/)에서 쿠버네티스 클러스터를 어떻게 계획하고, 셋업하고, 구성하는 지에 대한 예시를 참조하자. 이 글에 쓰여진 솔루션들은 *배포판* 이라고 부른다. - -가이드를 고르기 전에, 몇 가지 고려사항이 있다. - - - 단지 자신의 컴퓨터에 쿠버네티스를 테스트를 하는지, 또는 고가용성의 멀티 노드 클러스터를 만들려고 하는지에 따라 니즈에 가장 적절한 배포판을 고르자. - - [구글 쿠버네티스 엔진](https://cloud.google.com/kubernetes-engine/)과 같은 **호스팅된 쿠버네티스 클러스터** 를 사용할 것인지, **자신의 클러스터에 호스팅할 것인지**? - - 클러스터가 **온프레미스** 인지, 또는 **클라우드(IaaS)** 인지? 쿠버네티스는 하이브리드 클러스터를 직접적으로 지원하지는 않는다. 대신에, 사용자는 여러 클러스터를 구성할 수 있다. - - **만약 온프레미스에서 쿠버네티스를 구성한다면**, 어떤 [네트워킹 모델](/docs/concepts/cluster-administration/networking/)이 가장 적합한지 고려한다. - - 쿠버네티스 실행을 **"베어메탈" 하드웨어** 또는, **가상 머신 (VMs)** 중 어디에서 할 것 인지? - - **단지 클러스터 동작** 만 할 것인지, 아니면 **쿠버네티스 프로젝트 코드의 적극적인 개발** 을 원하는지? 만약 후자의 경우라면, - 적극적으로 개발된 배포판을 선택한다. 몇몇 배포판은 바이너리 릴리스 밖에 없지만, - 매우 다양한 선택권을 제공한다. - - 스스로 클러스터 구동에 필요한 [구성요소](/docs/admin/cluster-components/)에 익숙해지자. - -참고: 모든 배포판이 적극적으로 유지되는 것은 아니다. 최근 버전의 쿠버네티스로 테스트 된 배포판을 선택하자. - -## 클러스터 관리 - -* [클러스터 관리](/ko/docs/tasks/administer-cluster/cluster-management/)는 클러스터의 라이프사이클과 관련된 몇 가지 주제를 설명한다. 이는 새 클러스터 생성, 마스터와 워커노드 업그레이드, 노드 유지보수 실행 (예: 커널 업그레이드), 그리고 동작 중인 클러스터의 쿠버네티스 API 버전 업그레이드 등을 포함한다. - -* 어떻게 [노드 관리](/ko/docs/concepts/architecture/nodes/)를 하는지 배워보자. - -* 공유된 클러스터의 [리소스 쿼터](/ko/docs/concepts/policy/resource-quotas/)를 어떻게 셋업하고 관리할 것인지 배워보자. - -## 클러스터 보안 - -* [인증서](/docs/concepts/cluster-administration/certificates/)는 다른 툴 체인을 이용하여 인증서를 생성하는 방법을 설명한다. - -* [쿠버네티스 컨테이너 환경](/ko/docs/concepts/containers/container-environment/)은 쿠버네티스 노드에서 Kubelet에 의해 관리되는 컨테이너 환경에 대해 설명한다. - -* [쿠버네티스 API에 대한 접근 제어](/docs/reference/access-authn-authz/controlling-access/)는 사용자와 서비스 계정에 어떻게 권한 설정을 하는지 설명한다. - -* [인증](/docs/reference/access-authn-authz/authentication/)은 다양한 인증 옵션을 포함한 쿠버네티스에서의 인증을 설명한다. - -* [인가](/docs/reference/access-authn-authz/authorization/)은 인증과 다르며, HTTP 호출이 처리되는 방법을 제어한다. - -* [어드미션 컨트롤러 사용](/docs/reference/access-authn-authz/admission-controllers/)은 쿠버네티스 API 서버에서 인증과 인가 후 요청을 가로채는 플러그인을 설명한다. - -* [쿠버네티스 클러스터에서 Sysctls 사용](/docs/concepts/cluster-administration/sysctl-cluster/)는 관리자가 `sysctl` 커맨드라인 툴을 사용하여 커널 파라미터를 설정하는 방법을 설명한다. - -* [감시](/docs/tasks/debug-application-cluster/audit/)는 쿠버네티스 감시 로그가 상호작용 하는 방법을 설명한다. - -### kubelet 보안 - * [마스터노드 커뮤니케이션](/ko/docs/concepts/architecture/master-node-communication/) - * [TLS 부트스트래핑](/docs/reference/command-line-tools-reference/kubelet-tls-bootstrapping/) - * [Kubelet 인증/인가](/docs/admin/kubelet-authentication-authorization/) - -## 선택적 클러스터 서비스 - -* [DNS 통합](/ko/docs/concepts/services-networking/dns-pod-service/)은 DNS 이름이 쿠버네티스 서비스에 바로 연결되도록 변환하는 방법을 설명한다. - -* [클러스터 활동 로깅과 모니터링](/docs/concepts/cluster-administration/logging/)은 쿠버네티스 로깅이 로깅의 작동 방법과 로깅을 어떻게 구현하는지 설명한다. - - 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 a6907ad44c..d749710484 100644 --- a/content/ko/docs/concepts/cluster-administration/kubelet-garbage-collection.md +++ b/content/ko/docs/concepts/cluster-administration/kubelet-garbage-collection.md @@ -78,7 +78,6 @@ kubelet이 관리하지 않는 컨테이너는 컨테이너 가비지 수집 대 - ## {{% heading "whatsnext" %}} diff --git a/content/ko/docs/concepts/cluster-administration/logging.md b/content/ko/docs/concepts/cluster-administration/logging.md index 5c7ce6cd8d..4f516ed41e 100644 --- a/content/ko/docs/concepts/cluster-administration/logging.md +++ b/content/ko/docs/concepts/cluster-administration/logging.md @@ -78,7 +78,8 @@ kubectl logs counter 전자의 접근 방식은 다른 환경에서 사용된다. 두 경우 모두, 기본적으로 로그 파일이 10MB를 초과하면 로테이션이 되도록 구성된다. -예를 들어, `kube-up.sh` 가 해당 [스크립트][cosConfigureHelper]에서 +예를 들어, `kube-up.sh` 가 해당 +[스크립트](https://github.com/kubernetes/kubernetes/blob/{{< param "githubbranch" >}}/cluster/gce/gci/configure-helper.sh)에서 GCP의 COS 이미지 로깅을 설정하는 방법에 대한 자세한 정보를 찾을 수 있다. 기본 로깅 예제에서와 같이 [`kubectl logs`](/docs/reference/generated/kubectl/kubectl-commands#logs)를 @@ -93,8 +94,6 @@ GCP의 COS 이미지 로깅을 설정하는 방법에 대한 자세한 정보를 그 후 `kubectl logs` 는 빈 응답을 반환한다. {{< /note >}} -[cosConfigureHelper]: https://github.com/kubernetes/kubernetes/blob/{{< param "githubbranch" >}}/cluster/gce/gci/configure-helper.sh - ### 시스템 컴포넌트 로그 시스템 컴포넌트에는 컨테이너에서 실행되는 것과 컨테이너에서 실행되지 않는 두 가지 유형이 있다. @@ -106,7 +105,7 @@ GCP의 COS 이미지 로깅을 설정하는 방법에 대한 자세한 정보를 systemd를 사용하는 시스템에서, kubelet과 컨테이너 런타임은 journald에 작성한다. systemd를 사용하지 않으면, `/var/log` 디렉터리의 `.log` 파일에 작성한다. 컨테이너 내부의 시스템 컴포넌트는 기본 로깅 메커니즘을 무시하고, -항상 `/var/log` 디렉터리에 기록한다. 그것은 [klog][klog] +항상 `/var/log` 디렉터리에 기록한다. 그것은 [klog](https://github.com/kubernetes/klog) 로깅 라이브러리를 사용한다. [로깅에 대한 개발 문서](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-instrumentation/logging.md)에서 해당 컴포넌트의 로깅 심각도(severity)에 대한 규칙을 찾을 수 있다. @@ -115,8 +114,6 @@ systemd를 사용하지 않으면, `/var/log` 디렉터리의 `.log` 파일에 로그는 매일 또는 크기가 100MB를 초과하면 `logrotate` 도구에 의해 로테이트가 되도록 구성된다. -[klog]: https://github.com/kubernetes/klog - ## 클러스터 레벨 로깅 아키텍처 쿠버네티스는 클러스터-레벨 로깅을 위한 네이티브 솔루션을 제공하지 않지만, 고려해야 할 몇 가지 일반적인 접근 방법을 고려할 수 있다. 여기 몇 가지 옵션이 있다. diff --git a/content/ko/docs/concepts/cluster-administration/manage-deployment.md b/content/ko/docs/concepts/cluster-administration/manage-deployment.md index 6bed969e90..c2835e78cb 100644 --- a/content/ko/docs/concepts/cluster-administration/manage-deployment.md +++ b/content/ko/docs/concepts/cluster-administration/manage-deployment.md @@ -400,7 +400,7 @@ rm /tmp/nginx.yaml `kubectl patch` 를 사용하여 API 오브젝트를 인플레이스 업데이트할 수 있다. 이 명령은 JSON 패치, JSON 병합 패치 그리고 전략적 병합 패치를 지원한다. -[kubectl patch를 사용한 인플레이스 API 오브젝트 업데이트](/docs/tasks/run-application/update-api-object-kubectl-patch/)와 +[kubectl patch를 사용한 인플레이스 API 오브젝트 업데이트](/docs/tasks/manage-kubernetes-objects/update-api-object-kubectl-patch/)와 [kubectl patch](/docs/reference/generated/kubectl/kubectl-commands/#patch)를 참조한다. diff --git a/content/ko/docs/concepts/cluster-administration/monitoring.md b/content/ko/docs/concepts/cluster-administration/monitoring.md new file mode 100644 index 0000000000..440da51dd8 --- /dev/null +++ b/content/ko/docs/concepts/cluster-administration/monitoring.md @@ -0,0 +1,129 @@ +--- +title: 쿠버네티스 컨트롤 플레인에 대한 메트릭 +content_type: concept +weight: 60 +aliases: +- controller-metrics.md +--- + +<!-- overview --> + +시스템 컴포넌트 메트릭으로 내부에서 발생하는 상황을 더 잘 파악할 수 있다. 메트릭은 대시보드와 경고를 만드는 데 특히 유용하다. + +쿠버네티스 컨트롤 플레인의 메트릭은 [프로메테우스 형식](https://prometheus.io/docs/instrumenting/exposition_formats/)으로 출력되며 사람이 읽기 쉽다. + + + +<!-- body --> + +## 쿠버네티스의 메트릭 + +대부분의 경우 메트릭은 HTTP 서버의 `/metrics` 엔드포인트에서 사용할 수 있다. 기본적으로 엔드포인트를 노출하지 않는 컴포넌트의 경우 `--bind-address` 플래그를 사용하여 활성화할 수 있다. + +해당 컴포넌트의 예는 다음과 같다. + +* {{< 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" >}} + +프로덕션 환경에서는 이러한 메트릭을 주기적으로 수집하고 시계열 데이터베이스에서 사용할 수 있도록 +[프로메테우스 서버](https://prometheus.io/) 또는 다른 메트릭 수집기(scraper)를 구성할 수 있다. + +참고로 {{< glossary_tooltip term_id="kubelet" text="kubelet" >}}도 `/metrics/cadvisor`, `/metrics/resource` 그리고 `/metrics/probes` 엔드포인트에서 메트릭을 노출한다. 이러한 메트릭은 동일한 라이프사이클을 가지지 않는다. + +클러스터가 {{< glossary_tooltip term_id="rbac" text="RBAC" >}}을 사용하는 경우, 메트릭을 읽으려면 `/metrics` 에 접근을 허용하는 클러스터롤(ClusterRole)을 가지는 사용자, 그룹 또는 서비스어카운트(ServiceAccount)를 통한 권한이 필요하다. +예를 들면, 다음과 같다. +``` +apiVersion: rbac.authorization.k8s.io/v1 +kind: ClusterRole +metadata: + name: prometheus +rules: + - nonResourceURLs: + - "/metrics" + verbs: + - get +``` + +## 메트릭 라이프사이클 + +알파 메트릭 → 안정적인 메트릭 → 사용 중단된 메트릭 → 히든(hidden) 메트릭 → 삭제 + +알파 메트릭은 안정성을 보장하지 않는다. 따라서 언제든지 수정되거나 삭제될 수 있다. + +안정적인 메트릭은 변경되지 않는다는 보장을 할 수 있다. 특히 안정성은 다음을 의미한다. + +* 메트릭 자체는 삭제되거나 이름이 변경되지 않는다 +* 메트릭 유형은 수정되지 않는다 + +사용 중단된 메트릭은 메트릭이 결국 삭제된다는 것을 나타낸다. 어떤 버전을 찾으려면, 해당 메트릭이 어떤 쿠버네티스 버전에서부터 사용 중단될 것인지를 고려하는 내용을 포함하는 어노테이션을 확인해야 한다. + +사용 중단되기 전에는 아래와 같다. + +``` +# 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 +``` + +메트릭이 일단 숨겨지면 기본적으로 메트릭은 수집용으로 게시되지 않는다. 히든 메트릭을 사용하려면, 관련 클러스터 컴포넌트의 구성을 오버라이드(override)해야 한다. + +메트릭이 삭제되면, 메트릭이 게시되지 않는다. 오버라이드해서 이를 변경할 수 없다. + + +## 히든 메트릭 표시 + +위에서 설명한 것처럼, 관리자는 특정 바이너리의 커맨드 라인 플래그를 통해 히든 메트릭을 활성화할 수 있다. 관리자가 지난 릴리스에서 사용 중단된 메트릭의 마이그레이션을 놓친 경우 관리자를 위한 임시방편으로 사용된다. + +`show-hidden-metrics-for-version` 플래그는 해당 릴리스에서 사용 중단된 메트릭을 보여주려는 버전을 사용한다. 버전은 xy로 표시되며, 여기서 x는 메이저(major) 버전이고, y는 마이너(minor) 버전이다. 패치 릴리스에서 메트릭이 사용 중단될 수 있지만, 패치 버전은 필요하지 않다. 그 이유는 메트릭 사용 중단 정책이 마이너 릴리스에 대해 실행되기 때문이다. + +플래그는 그 값으로 이전의 마이너 버전만 사용할 수 있다. 관리자가 이전 버전을 `show-hidden-metrics-for-version` 에 설정하면 이전 버전의 모든 히든 메트릭이 생성된다. 사용 중단 메트릭 정책을 위반하기 때문에 너무 오래된 버전은 허용되지 않는다. + +1.n 버전에서 사용 중단되었다고 가정한 메트릭 `A` 를 예로 들어보겠다. 메트릭 사용 중단 정책에 따르면, 다음과 같은 결론에 도달할 수 있다. + +* `1.n` 릴리스에서는 메트릭이 사용 중단되었으며, 기본적으로 생성될 수 있다. +* `1.n+1` 릴리스에서는 기본적으로 메트릭이 숨겨져 있으며, `show-hidden-metrics-for-version=1.n` 커맨드 라인에 의해서 생성될 수 있다. +* `1.n+2` 릴리스에서는 코드베이스에서 메트릭이 제거되어야 한다. 더이상 임시방편은 존재하지 않는다. + +릴리스 `1.12` 에서 `1.13` 으로 업그레이드 중이지만, `1.12` 에서 사용 중단된 메트릭 `A` 를 사용하고 있다면, 커맨드 라인에서 `--show-hidden-metrics=1.12` 플래그로 히든 메트릭을 설정해야 하고, `1.14` 로 업그레이드하기 전에 이 메트릭을 사용하지 않도록 의존성을 제거하는 것을 기억해야 한다. + +## 컴포넌트 메트릭 + +### kube-controller-manager 메트릭 + +컨트롤러 관리자 메트릭은 컨트롤러 관리자의 성능과 상태에 대한 중요한 인사이트를 제공한다. +이러한 메트릭에는 go_routine 수와 같은 일반적인 Go 언어 런타임 메트릭과 +etcd 요청 대기 시간 또는 Cloudprovider(AWS, GCE, OpenStack) API 대기 시간과 같은 컨트롤러 특정 메트릭이 포함되어 +클러스터의 상태를 측정하는 데 사용할 수 있다. + +쿠버네티스 1.7부터 GCE, AWS, Vsphere 및 OpenStack의 스토리지 운영에 대한 상세한 Cloudprovider 메트릭을 사용할 수 있다. +이 메트릭은 퍼시스턴트 볼륨 동작의 상태를 모니터링하는 데 사용할 수 있다. + +예를 들어, GCE의 경우 이러한 메트릭을 다음과 같이 호출한다. + +``` +cloudprovider_gce_api_request_duration_seconds { request = "instance_list"} +cloudprovider_gce_api_request_duration_seconds { request = "disk_insert"} +cloudprovider_gce_api_request_duration_seconds { request = "disk_delete"} +cloudprovider_gce_api_request_duration_seconds { request = "attach_disk"} +cloudprovider_gce_api_request_duration_seconds { request = "detach_disk"} +cloudprovider_gce_api_request_duration_seconds { request = "list_disk"} +``` + + + +## {{% heading "whatsnext" %}} + +* 메트릭에 대한 [프로메테우스 텍스트 형식](https://github.com/prometheus/docs/blob/master/content/docs/instrumenting/exposition_formats.md#text-based-format)에 대해 읽어본다 +* [안정적인 쿠버네티스 메트릭](https://github.com/kubernetes/kubernetes/blob/master/test/instrumentation/testdata/stable-metrics-list.yaml) 목록을 참고한다 +* [쿠버네티스 사용 중단 정책](/docs/reference/using-api/deprecation-policy/#deprecating-a-feature-or-behavior)에 대해 읽어본다 diff --git a/content/ko/docs/concepts/configuration/_index.md b/content/ko/docs/concepts/configuration/_index.md index 11dbabc7b2..5485f559a1 100755 --- a/content/ko/docs/concepts/configuration/_index.md +++ b/content/ko/docs/concepts/configuration/_index.md @@ -1,5 +1,6 @@ --- title: "구성" weight: 80 +description: > + 쿠버네티스가 파드 구성을 위해 제공하는 리소스 --- - diff --git a/content/ko/docs/concepts/configuration/configmap.md b/content/ko/docs/concepts/configuration/configmap.md index 8e5eb3bed1..3b339ca18f 100644 --- a/content/ko/docs/concepts/configuration/configmap.md +++ b/content/ko/docs/concepts/configuration/configmap.md @@ -43,7 +43,7 @@ API [오브젝트](/ko/docs/concepts/overview/working-with-objects/kubernetes-ob 컨피그맵의 이름은 유효한 [DNS 서브도메인 이름](/ko/docs/concepts/overview/working-with-objects/names/#dns-서브도메인-이름)이어야 한다. -## 컨피그맵과 파드(Pod) +## 컨피그맵과 파드 컨피그맵을 참조하는 파드 `spec` 을 작성하고 컨피그맵의 데이터를 기반으로 해당 파드의 컨테이너를 구성할 수 있다. 파드와 컨피그맵은 @@ -60,7 +60,7 @@ metadata: name: game-demo data: # 속성과 비슷한 키; 각 키는 간단한 값으로 매핑됨 - player_initial_lives: 3 + player_initial_lives: "3" ui_properties_file_name: "user-interface.properties" # # 파일과 비슷한 키 @@ -85,9 +85,9 @@ data: 방식에 따라 다르게 쓰인다. 처음 세 가지 방법의 경우, {{< glossary_tooltip text="kubelet" term_id="kubelet" >}}은 파드의 컨테이너를 시작할 때 -시크릿의 데이터를 사용한다. +컨피그맵의 데이터를 사용한다. -네 번째 방법은 시크릿과 데이터를 읽기 위해 코드를 작성해야 한다는 것을 의미한다. +네 번째 방법은 컨피그맵과 데이터를 읽기 위해 코드를 작성해야 한다는 것을 의미한다. 그러나, 쿠버네티스 API를 직접 사용하기 때문에, 애플리케이션은 컨피그맵이 변경될 때마다 업데이트를 받기 위해 구독할 수 있고, 업데이트가 있으면 반응한다. 쿠버네티스 API에 직접 접근하면, 이 @@ -126,25 +126,32 @@ spec: configMap: # 마운트하려는 컨피그맵의 이름을 제공한다. name: game-demo + # 컨피그맵에서 파일로 생성할 키 배열 + items: + - key: "game.properties" + path: "game.properties" + - key: "user-interface.properties" + path: "user-interface.properties" ``` 컨피그맵은 단일 라인 속성(single line property) 값과 멀티 라인의 파일과 비슷한(multi-line file-like) 값을 구분하지 않는다. 더 중요한 것은 파드와 다른 오브젝트가 이러한 값을 소비하는 방식이다. + 이 예제에서, 볼륨을 정의하고 `demo` 컨테이너에 -`/config` 로 마운트하면 4개의 파일이 생성된다. +`/config` 로 마운트하면 컨피그맵에 4개의 키가 있더라도 +`/config/game.properties` 와 `/config/user-interface.properties` +2개의 파일이 생성된다. 이것은 파드 정의가 +`volume` 섹션에서 `items` 배열을 지정하기 때문이다. +`items` 배열을 완전히 생략하면, 컨피그맵의 모든 키가 +키와 이름이 같은 파일이 되고, 4개의 파일을 얻게 된다. -- `/config/player_initial_lives` -- `/config/ui_properties_file_name` -- `/config/game.properties` -- `/config/user-interface.properties` +## 컨피그맵 사용하기 -`/config` 에 `.properties` 확장자를 가진 파일만 -포함시키려면, 두 개의 다른 컨피그맵을 사용하고, 파드에 -대해서는 `spec` 의 두 컨피그맵을 참조한다. 첫 번째 컨피그맵은 -`player_initial_lives` 와 `ui_properties_file_name` 을 정의한다. 두 번째 -컨피그맵은 kubelet이 `/config` 에 넣는 파일을 정의한다. +컨피그맵은 데이터 볼륨으로 마운트할 수 있다. 컨피그맵은 파드에 직접적으로 +노출되지 않고, 시스템의 다른 부분에서도 사용할 수 있다. 예를 들어, +컨피그맵은 시스템의 다른 부분이 구성을 위해 사용해야 하는 데이터를 보유할 수 있다. {{< note >}} 컨피그맵을 사용하는 가장 일반적인 방법은 동일한 네임스페이스의 @@ -157,7 +164,85 @@ spec: 사용할 수도 있다. {{< /note >}} +### 파드에서 컨피그맵을 파일로 사용하기 +파드의 볼륨에서 컨피그맵을 사용하려면 다음을 수행한다. + +1. 컨피그맵을 생성하거나 기존 컨피그맵을 사용한다. 여러 파드가 동일한 컨피그맵을 참조할 수 있다. +1. 파드 정의를 수정해서 `.spec.volumes[]` 아래에 볼륨을 추가한다. 볼륨 이름은 원하는 대로 정하고, 컨피그맵 오브젝트를 참조하도록 `.spec.volumes[].configMap.name` 필드를 설정한다. +1. 컨피그맵이 필요한 각 컨테이너에 `.spec.containers[].volumeMounts[]` 를 추가한다. `.spec.containers[].volumeMounts[].readOnly = true` 를 설정하고 컨피그맵이 연결되기를 원하는 곳에 사용하지 않은 디렉터리 이름으로 `.spec.containers[].volumeMounts[].mountPath` 를 지정한다. +1. 프로그램이 해당 디렉터리에서 파일을 찾도록 이미지 또는 커맨드 라인을 수정한다. 컨피그맵의 `data` 맵 각 키는 `mountPath` 아래의 파일 이름이 된다. + +다음은 볼륨에 컨피그맵을 마운트하는 파드의 예시이다. + +```yaml +apiVersion: v1 +kind: Pod +metadata: + name: mypod +spec: + containers: + - name: mypod + image: redis + volumeMounts: + - name: foo + mountPath: "/etc/foo" + readOnly: true + volumes: + - name: foo + configmap: + name: myconfigmap +``` + +사용하려는 각 컨피그맵은 `.spec.volumes` 에서 참조해야 한다. + +파드에 여러 컨테이너가 있는 경우 각 컨테이너에는 자체 `volumeMounts` 블록이 필요하지만, +컨피그맵은 각 컨피그맵 당 하나의 `.spec.volumes` 만 필요하다. + +#### 마운트된 컨피그맵이 자동으로 업데이트 + +현재 볼륨에서 사용된 컨피그맵이 업데이트되면, 프로젝션된 키도 마찬가지로 업데이트된다. +kubelet은 모든 주기적인 동기화에서 마운트된 컨피그맵이 최신 상태인지 확인한다. +그러나, kubelet은 로컬 캐시를 사용해서 컨피그맵의 현재 값을 가져온다. +캐시 유형은 [KubeletConfiguration 구조체](https://github.com/kubernetes/kubernetes/blob/{{< param "docsbranch" >}}/staging/src/k8s.io/kubelet/config/v1beta1/types.go)의 +`ConfigMapAndSecretChangeDetectionStrategy` 필드를 사용해서 구성할 수 있다. + +컨피그맵은 watch(기본값), ttl 기반 또는 API 서버로 직접 +모든 요청을 리디렉션할 수 있다. +따라서 컨피그맵이 업데이트되는 순간부터 새 키가 파드에 업데이트되는 순간까지의 +총 지연시간은 kubelet 동기화 기간 + 캐시 전파 지연만큼 길 수 있다. 여기서 캐시 +전파 지연은 선택한 캐시 유형에 따라 달라질 수 있다(전파 +지연을 지켜보거나, 캐시의 ttl 또는 0에 상응함). + +{{< feature-state for_k8s_version="v1.18" state="alpha" >}} + +쿠버네티스 알파 기능인 _변경할 수 없는(immutable) 시크릿과 컨피그맵_ 은 개별 시크릿과 +컨피그맵을 변경할 수 없는 것으로 설정하는 옵션을 제공한다. 컨피그맵을 광범위하게 +사용하는 클러스터(최소 수만 개의 고유한 컨피그맵이 파드에 마운트)의 경우 +데이터 변경을 방지하면 다음과 같은 이점이 있다. + +- 애플리케이션 중단을 일으킬 수 있는 우발적(또는 원하지 않는) 업데이트로부터 보호 +- immutable로 표시된 컨피그맵에 대한 감시를 중단하여, kube-apiserver의 부하를 크게 줄임으로써 클러스터의 성능을 향상시킴 + +이 기능을 사용하려면 `ImmutableEmphemeralVolumes` +[기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)를 활성화하고 +시크릿 또는 컨피그맵의 `immutable` 필드를 `true` 로 한다. 다음은 예시이다. +```yaml +apiVersion: v1 +kind: ConfigMap +metadata: + ... +data: + ... +immutable: true +``` + +{{< note >}} +컨피그맵 또는 시크릿을 immutable로 표시하면, 이 변경 사항을 되돌리거나 +`data` 필드 내용을 변경할 수 _없다_. 컨피그맵만 삭제하고 다시 작성할 수 있다. +기존 파드는 삭제된 컨피그맵에 대한 마운트 지점을 유지하며, 이러한 파드를 다시 작성하는 +것을 권장한다. +{{< /note >}} ## {{% heading "whatsnext" %}} @@ -166,5 +251,3 @@ spec: * [컨피그맵을 사용하도록 파드 구성하기](/docs/tasks/configure-pod-container/configure-pod-configmap/)를 읽어본다. * 코드를 구성에서 분리하려는 동기를 이해하려면 [Twelve-Factor 앱](https://12factor.net/ko/)을 읽어본다. - - diff --git a/content/ko/docs/concepts/configuration/manage-resources-containers.md b/content/ko/docs/concepts/configuration/manage-resources-containers.md index 90991bc49e..42036c7da8 100644 --- a/content/ko/docs/concepts/configuration/manage-resources-containers.md +++ b/content/ko/docs/concepts/configuration/manage-resources-containers.md @@ -227,7 +227,7 @@ kubelet은 파드의 컨테이너를 시작할 때, CPU와 메모리 제한을 파드는 스크래치 공간, 캐싱 및 로그에 대해 임시 로컬 스토리지를 사용한다. kubelet은 로컬 임시 스토리지를 사용하여 컨테이너에 -[`emptyDir`](https://kubernetes.io/docs/concepts/storage/volumes/#emptydir) +[`emptyDir`](/ko/docs/concepts/storage/volumes/#emptydir) {{< glossary_tooltip term_id="volume" text="볼륨" >}}을 마운트하기 위해 파드에 스크래치 공간을 제공할 수 있다. kubelet은 이러한 종류의 스토리지를 사용하여 @@ -292,7 +292,7 @@ kubelet은 사용 중인 로컬 스토리지 양을 측정할 수 있다. 이것 제공한다. - `LocalStorageCapacityIsolation` - [기능 게이트](/docs/reference/command-line-tools-reference/feature-gates/)(이 + [기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)(이 기능이 기본적으로 설정되어 있음)를 활성화하고, - 로컬 임시 스토리지에 대한 지원되는 구성 중 하나를 사용하여 노드를 설정한다. @@ -441,7 +441,7 @@ kubelet은 각 `emptyDir` 볼륨, 컨테이너 로그 디렉터리 및 쓰기 프로젝트 쿼터를 사용하려면, 다음을 수행해야 한다. * kubelet 구성에서 `LocalStorageCapacityIsolationFSQuotaMonitoring=true` - [기능 게이트](/docs/reference/command-line-tools-reference/feature-gates/)를 + [기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)를 활성화한다. * 루트 파일시스템(또는 선택적인 런타임 파일시스템)에 @@ -657,7 +657,7 @@ Allocated resources: (Total limits may be over 100 percent, i.e., overcommitted.) CPU Requests CPU Limits Memory Requests Memory Limits ------------ ---------- --------------- ------------- - 680m (34%) 400m (20%) 920Mi (12%) 1070Mi (14%) + 680m (34%) 400m (20%) 920Mi (11%) 1070Mi (13%) ``` 위의 출력에서, ​파드가 1120m 이상의 CPU 또는 6.23Gi의 메모리를 @@ -758,5 +758,3 @@ LastState: map[terminated:map[exitCode:137 reason:OOM Killed startedAt:2015-07-0 * [ResourceRequirements](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#resourcerequirements-v1-core) API 레퍼런스 읽어보기 * XFS의 [프로젝트 쿼터](http://xfs.org/docs/xfsdocs-xml-dev/XFS_User_Guide/tmp/en-US/html/xfs-quotas.html)에 대해 읽어보기 - - diff --git a/content/ko/docs/concepts/configuration/organize-cluster-access-kubeconfig.md b/content/ko/docs/concepts/configuration/organize-cluster-access-kubeconfig.md index 0e50a842bb..a002414b67 100644 --- a/content/ko/docs/concepts/configuration/organize-cluster-access-kubeconfig.md +++ b/content/ko/docs/concepts/configuration/organize-cluster-access-kubeconfig.md @@ -58,8 +58,8 @@ kubectl config use-context ## KUBECONFIG 환경 변수 `KUBECONFIG` 환경 변수는 kubeconfig 파일 목록을 보유한다. -Linux 및 Mac의 경우 이는 콜론(:)으로 구분된 목록이다. -Windows는 세미콜론(;)으로 구분한다. `KUBECONFIG` 환경 변수가 필수는 아니다. +리눅스 및 Mac의 경우 이는 콜론(:)으로 구분된 목록이다. +윈도우는 세미콜론(;)으로 구분한다. `KUBECONFIG` 환경 변수가 필수는 아니다. `KUBECONFIG` 환경 변수가 없으면, `kubectl`은 기본 kubeconfig 파일인 `$HOME/.kube/config`를 사용한다. @@ -99,7 +99,7 @@ kubectl config view `KUBECONFIG` 환경 변수 설정의 예로, [KUBECONFIG 환경 변수 설정](/ko/docs/tasks/access-application-cluster/configure-access-multiple-clusters/#kubeconfig-환경-변수-설정)를 참조한다. - 그렇지 않다면, 병합하지 않고 기본 kubecofig 파일인 `$HOME/.kube/config`를 사용한다. + 그렇지 않다면, 병합하지 않고 기본 kubeconfig 파일인 `$HOME/.kube/config`를 사용한다. 1. 이 체인에서 첫 번째를 기반으로 사용할 컨텍스트를 결정한다. diff --git a/content/ko/docs/concepts/configuration/overview.md b/content/ko/docs/concepts/configuration/overview.md index db45ca2d2c..387a794a6b 100644 --- a/content/ko/docs/concepts/configuration/overview.md +++ b/content/ko/docs/concepts/configuration/overview.md @@ -28,16 +28,16 @@ weight: 10 - 더 나은 인트로스펙션(introspection)을 위해서, 어노테이션에 오브젝트의 설명을 넣는다. -## "단독(Naked)" 파드 vs 레플리카 셋, 디플로이먼트, 그리고 잡 {#naked-pods-vs-replicasets-deployments-and-jobs} +## "단독(Naked)" 파드 vs 레플리카셋(ReplicaSet), 디플로이먼트(Deployment), 그리고 잡(Job) {#naked-pods-vs-replicasets-deployments-and-jobs} -- 가능하다면 단독 파드(즉, [레플리카 셋](/ko/docs/concepts/workloads/controllers/replicaset/)이나 [디플로이먼트](/ko/docs/concepts/workloads/controllers/deployment/)에 연결되지 않은 파드)를 사용하지 않는다. 단독 파드는 노드 장애 이벤트가 발생해도 다시 스케줄링되지 않는다. +- 가능하다면 단독 파드(즉, [레플리카셋](/ko/docs/concepts/workloads/controllers/replicaset/)이나 [디플로이먼트](/ko/docs/concepts/workloads/controllers/deployment/)에 연결되지 않은 파드)를 사용하지 않는다. 단독 파드는 노드 장애 이벤트가 발생해도 다시 스케줄링되지 않는다. - 명백하게 [`restartPolicy: Never`](/ko/docs/concepts/workloads/pods/pod-lifecycle/#재시작-정책)를 사용하는 상황을 제외한다면, 의도한 파드의 수가 항상 사용 가능한 상태를 유지하는 레플리카 셋을 생성하고, 파드를 교체하는 전략([롤링 업데이트](/ko/docs/concepts/workloads/controllers/deployment/#디플로이먼트-롤링-업데이트)와 같은)을 명시하는 디플로이먼트는 파드를 직접 생성하기 위해 항상 선호되는 방법이다. [잡](/ko/docs/concepts/workloads/controllers/jobs-run-to-completion/) 또한 적절할 수 있다. + 명백하게 [`restartPolicy: Never`](/ko/docs/concepts/workloads/pods/pod-lifecycle/#재시작-정책)를 사용하는 상황을 제외한다면, 의도한 파드의 수가 항상 사용 가능한 상태를 유지하는 레플리카셋을 생성하고, 파드를 교체하는 전략([롤링 업데이트](/ko/docs/concepts/workloads/controllers/deployment/#디플로이먼트-롤링-업데이트)와 같은)을 명시하는 디플로이먼트는 파드를 직접 생성하기 위해 항상 선호되는 방법이다. [잡](/ko/docs/concepts/workloads/controllers/job/) 또한 적절할 수 있다. ## 서비스 -- 서비스에 대응하는 백엔드 워크로드(디플로이먼트 또는 레플리카 셋) 또는 서비스 접근이 필요한 어떠한 워크로드를 생성하기 전에 [서비스](/ko/docs/concepts/services-networking/service/)를 미리 생성한다. 쿠버네티스가 컨테이너를 시작할 때, 쿠버네티스는 컨테이너 시작 당시에 생성되어 있는 모든 서비스를 가리키는 환경 변수를 컨테이너에 제공한다. 예를 들어, `foo` 라는 이름의 서비스가 존재한다면, 모든 컨테이너들은 초기 환경에서 다음의 변수들을 얻을 것이다. +- 서비스에 대응하는 백엔드 워크로드(디플로이먼트 또는 레플리카셋) 또는 서비스 접근이 필요한 어떠한 워크로드를 생성하기 전에 [서비스](/ko/docs/concepts/services-networking/service/)를 미리 생성한다. 쿠버네티스가 컨테이너를 시작할 때, 쿠버네티스는 컨테이너 시작 당시에 생성되어 있는 모든 서비스를 가리키는 환경 변수를 컨테이너에 제공한다. 예를 들어, `foo` 라는 이름의 서비스가 존재한다면, 모든 컨테이너들은 초기 환경에서 다음의 변수들을 얻을 것이다. ```shell FOO_SERVICE_HOST=<서비스가 동작 중인 호스트> @@ -46,7 +46,7 @@ weight: 10 *이는 순서를 정하는 일이 요구됨을 암시한다* - `파드`가 접근하기를 원하는 어떠한 `서비스`는 `파드` 스스로가 생성되기 전에 미리 생성되어 있어야 하며, 그렇지 않으면 환경 변수가 설정되지 않을 것이다. DNS는 이러한 제한을 가지고 있지 않다. -- 선택적인(그렇지만 매우 권장되는) [클러스터 애드온](/docs/concepts/cluster-administration/addons/)은 DNS 서버이다. +- 선택적인(그렇지만 매우 권장되는) [클러스터 애드온](/ko/docs/concepts/cluster-administration/addons/)은 DNS 서버이다. DNS 서버는 새로운 `서비스`를 위한 쿠버네티스 API를 Watch하며, 각 서비스를 위한 DNS 레코드 셋을 생성한다. 만약 DNS가 클러스터에 걸쳐 활성화되어 있다면, 모든 `파드`는 `서비스`의 이름을 자동으로 해석할 수 있어야 한다. - 반드시 필요한 것이 아니라면 파드에 `hostPort` 를 명시하지 않는다. <`hostIP`, `hostPort`, `protocol`> 조합은 유일해야 하기 때문에, `hostPort`로 바인드하는 것은 파드가 스케줄링될 수 있는 위치의 개수를 제한한다. 만약 `hostIP`와 `protocol`을 뚜렷히 명시하지 않으면, 쿠버네티스는 `hostIP`의 기본 값으로 `0.0.0.0`를, `protocol`의 기본 값으로 `TCP`를 사용한다. @@ -61,13 +61,13 @@ DNS 서버는 새로운 `서비스`를 위한 쿠버네티스 API를 Watch하며 ## 레이블 사용하기 -- `{ app: myapp, tier: frontend, phase: test, deployment: v3 }`처럼 애플리케이션이나 디플로이먼트의 __속성에 대한 의미__를 식별하는 [레이블](/ko/docs/concepts/overview/working-with-objects/labels/)을 정의해 사용한다. 다른 리소스를 위해 적절한 파드를 선택하는 용도로 이러한 레이블을 이용할 수 있다. 예를 들어, 모든 `tier: frontend` 파드를 선택하거나, `app: myapp`의 모든 `phase: test` 컴포넌트를 선택하는 서비스를 생각해 볼 수 있다. 이 접근 방법의 예시는 [방명록](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/guestbook/) 앱을 참고한다. +- `{ app: myapp, tier: frontend, phase: test, deployment: v3 }`처럼 애플리케이션이나 디플로이먼트의 __속성에 대한 의미__ 를 식별하는 [레이블](/ko/docs/concepts/overview/working-with-objects/labels/)을 정의해 사용한다. 다른 리소스를 위해 적절한 파드를 선택하는 용도로 이러한 레이블을 이용할 수 있다. 예를 들어, 모든 `tier: frontend` 파드를 선택하거나, `app: myapp`의 모든 `phase: test` 컴포넌트를 선택하는 서비스를 생각해 볼 수 있다. 이 접근 방법의 예시는 [방명록](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/guestbook/) 앱을 참고한다. 릴리스에 특정되는 레이블을 서비스의 셀렉터에서 생략함으로써 여러 개의 디플로이먼트에 걸치는 서비스를 생성할 수 있다. [디플로이먼트](/ko/docs/concepts/workloads/controllers/deployment/)는 생성되어 있는 서비스를 다운타임 없이 수정하기 쉽도록 만든다. 오브젝트의 의도한 상태는 디플로이먼트에 의해 기술되며, 만약 그 스펙에 대한 변화가 _적용될_ 경우, 디플로이먼트 컨트롤러는 일정한 비율로 실제 상태를 의도한 상태로 변화시킨다. -- 디버깅을 위해 레이블을 조작할 수 있다. (레플리카 셋과 같은) 쿠버네티스 컨트롤러와 서비스는 셀렉터 레이블을 사용해 파드를 선택하기 때문에, 관련된 레이블을 파드에서 삭제하는 것은 컨트롤러로부터 관리되거나 서비스로부터 트래픽을 전달받는 것을 중단시킨다. 만약 이미 존재하는 파드의 레이블을 삭제한다면, 파드의 컨트롤러는 그 자리를 대신할 새로운 파드를 생성한다. 이것은 이전에 "살아 있는" 파드를 "격리된" 환경에서 디버그할 수 있는 유용한 방법이다. 레이블을 상호적으로 추가하고 삭제하기 위해서, [`kubectl label`](/docs/reference/generated/kubectl/kubectl-commands#label)를 사용할 수 있다. +- 디버깅을 위해 레이블을 조작할 수 있다. (레플리카셋과 같은) 쿠버네티스 컨트롤러와 서비스는 셀렉터 레이블을 사용해 파드를 선택하기 때문에, 관련된 레이블을 파드에서 삭제하는 것은 컨트롤러로부터 관리되거나 서비스로부터 트래픽을 전달받는 것을 중단시킨다. 만약 이미 존재하는 파드의 레이블을 삭제한다면, 파드의 컨트롤러는 그 자리를 대신할 새로운 파드를 생성한다. 이것은 이전에 "살아 있는" 파드를 "격리된" 환경에서 디버그할 수 있는 유용한 방법이다. 레이블을 상호적으로 추가하고 삭제하기 위해서, [`kubectl label`](/docs/reference/generated/kubectl/kubectl-commands#label)를 사용할 수 있다. ## 컨테이너 이미지 @@ -99,8 +99,6 @@ DNS 서버는 새로운 `서비스`를 위한 쿠버네티스 API를 Watch하며 - `kubectl apply -f <디렉터리>`를 사용한다. 이 명령어는 `<디렉터리>` 내부의 모든 `.yaml`, `.yml`, 그리고 `.json` 쿠버네티스 구성 파일을 찾아 `apply`에 전달한다. -- `get`과 `delete` 동작을 위해 특정 오브젝트의 이름 대신 레이블 셀렉터를 사용한다. [레이블 셀렉터](/ko/docs/concepts/overview/working-with-objects/labels/#레이블-셀렉터)와 [효율적으로 레이블 사용하기](/docs/concepts/cluster-administration/manage-deployment/#using-labels-effectively)를 참고할 수 있다. - -- 단일 컨테이너로 구성된 디플로이먼트와 서비스를 빠르게 생성하기 위해 `kubectl run`와 `kubectl expose`를 사용한다. [클러스터 내부의 애플리케이션에 접근하기 위한 서비스 사용](/docs/tasks/access-application-cluster/service-access-application-cluster/)에서 예시를 확인할 수 있다. - +- `get`과 `delete` 동작을 위해 특정 오브젝트의 이름 대신 레이블 셀렉터를 사용한다. [레이블 셀렉터](/ko/docs/concepts/overview/working-with-objects/labels/#레이블-셀렉터)와 [효율적으로 레이블 사용하기](/ko/docs/concepts/cluster-administration/manage-deployment/#효과적인-레이블-사용)를 참고할 수 있다. +- 단일 컨테이너로 구성된 디플로이먼트와 서비스를 빠르게 생성하기 위해 `kubectl create deployment` 와 `kubectl expose` 를 사용한다. [클러스터 내부의 애플리케이션에 접근하기 위한 서비스 사용](/docs/tasks/access-application-cluster/service-access-application-cluster/)에서 예시를 확인할 수 있다. diff --git a/content/ko/docs/concepts/configuration/pod-overhead.md b/content/ko/docs/concepts/configuration/pod-overhead.md index cafd3a921d..2a08de53fb 100644 --- a/content/ko/docs/concepts/configuration/pod-overhead.md +++ b/content/ko/docs/concepts/configuration/pod-overhead.md @@ -8,9 +8,10 @@ weight: 20 {{< feature-state for_k8s_version="v1.18" state="beta" >}} + 노드 위에서 파드를 구동할 때, 파드는 그 자체적으로 많은 시스템 리소스를 사용한다. 이러한 리소스는 파드 내의 컨테이너들을 구동하기 위한 리소스 이외에 추가적으로 필요한 것이다. -_파드 오버헤드_ 는 컨테이너 리소스 요청과 상한 위에서 파드의 인프라에 의해 +_파드 오버헤드_ 는 컨테이너 리소스 요청과 상한 위에서 파드의 인프라에 의해 소비되는 리소스를 계산하는 기능이다. @@ -19,25 +20,25 @@ _파드 오버헤드_ 는 컨테이너 리소스 요청과 상한 위에서 파 <!-- body --> -쿠버네티스에서 파드의 오버헤드는 파드의 -[런타임클래스](/ko/docs/concepts/containers/runtime-class/) 와 관련된 오버헤드에 따라 -[어드미션](/docs/reference/access-authn-authz/extensible-admission-controllers/#what-are-admission-webhooks) +쿠버네티스에서 파드의 오버헤드는 파드의 +[런타임클래스](/ko/docs/concepts/containers/runtime-class/) 와 관련된 오버헤드에 따라 +[어드미션](/docs/reference/access-authn-authz/extensible-admission-controllers/#what-are-admission-webhooks) 이 수행될 때 지정된다. -파드 오버헤드가 활성화 되면, 파드를 노드에 스케줄링 할 때 컨테이너 리소스 요청의 합에 -파드의 오버헤드를 추가해서 스케줄링을 고려한다. 마찬가지로, Kubelet은 파드의 cgroups 크기를 변경하거나 +파드 오버헤드가 활성화 되면, 파드를 노드에 스케줄링 할 때 컨테이너 리소스 요청의 합에 +파드의 오버헤드를 추가해서 스케줄링을 고려한다. 마찬가지로, Kubelet은 파드의 cgroups 크기를 변경하거나 파드의 축출 등급을 부여할 때에도 파드의 오버헤드를 포함하여 고려한다. ## 파드 오버헤드 활성화하기 {#set-up} -기능 활성화를 위해 클러스터에서 -`PodOverhead` [기능 게이트](/docs/reference/command-line-tools-reference/feature-gates/) 가 활성화 되어 있고 (1.18 버전에서는 기본적으로 활성화), +기능 활성화를 위해 클러스터에서 +`PodOverhead` [기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)가 활성화되어 있고(1.18 버전에서는 기본적으로 활성화), `overhead` 필드를 정의하는 `RuntimeClass` 가 사용되고 있는지 확인해야 한다. ## 사용 예제 파드 오버헤드 기능을 사용하기 위하여, `overhead` 필드를 정의하는 런타임클래스가 필요하다. -예를 들어, 가상 머신 및 게스트 OS에 대하여 파드 당 120 MiB를 사용하는 +예를 들어, 가상 머신 및 게스트 OS에 대하여 파드 당 120 MiB를 사용하는 가상화 컨테이너 런타임의 런타임클래스의 경우 다음과 같이 정의 할 수 있다. ```yaml @@ -53,7 +54,7 @@ overhead: cpu: "250m" ``` -`kata-fc` 런타임클래스 핸들러를 지정하는 워크로드는 리소스 쿼터 계산, +`kata-fc` 런타임클래스 핸들러를 지정하는 워크로드는 리소스 쿼터 계산, 노드 스케줄링 및 파드 cgroup 크기 조정을 위하여 메모리와 CPU 오버헤드를 고려한다. 주어진 예제 워크로드 test-pod의 구동을 고려해보자. @@ -82,9 +83,9 @@ spec: memory: 100Mi ``` -어드미션 수행 시에, [어드미션 컨트롤러](https://kubernetes.io/docs/reference/access-authn-authz/admission-controllers/)는 -런타임클래스에 기술된 `overhead` 를 포함하기 위하여 워크로드의 PodSpec 항목을 갱신한다. 만약 PodSpec이 이미 해당 필드에 정의되어 있으면, -파드는 거부된다. 주어진 예제에서, 오직 런타임클래스의 이름만이 정의되어 있기 때문에, 어드미션 컨트롤러는 파드가 +어드미션 수행 시에, [어드미션 컨트롤러](/docs/reference/access-authn-authz/admission-controllers/)는 +런타임클래스에 기술된 `overhead` 를 포함하기 위하여 워크로드의 PodSpec 항목을 갱신한다. 만약 PodSpec이 이미 해당 필드에 정의되어 있으면, +파드는 거부된다. 주어진 예제에서, 오직 런타임클래스의 이름만이 정의되어 있기 때문에, 어드미션 컨트롤러는 파드가 `overhead` 를 포함하도록 변경한다. 런타임클래스의 어드미션 수행 후에, 파드의 스펙이 갱신된 것을 확인할 수 있다. @@ -98,11 +99,11 @@ kubectl get pod test-pod -o jsonpath='{.spec.overhead}' map[cpu:250m memory:120Mi] ``` -만약 리소스쿼터 항목이 정의되어 있다면, 컨테이너의 리소스 요청의 합에는 +만약 리소스쿼터 항목이 정의되어 있다면, 컨테이너의 리소스 요청의 합에는 `overhead` 필드도 추가된다. -kube-scheduler 는 어떤 노드에 파드가 기동 되어야 할지를 정할 때, 파드의 `overhead` 와 -해당 파드에 대한 컨테이너의 리소스 요청의 합을 고려한다. 이 예제에서, 스케줄러는 +kube-scheduler 는 어떤 노드에 파드가 기동 되어야 할지를 정할 때, 파드의 `overhead` 와 +해당 파드에 대한 컨테이너의 리소스 요청의 합을 고려한다. 이 예제에서, 스케줄러는 리소스 요청과 파드의 오버헤드를 더하고, 2.25 CPU와 320 MiB 메모리가 사용 가능한 노드를 찾는다. 일단 파드가 특정 노드에 스케줄링 되면, 해당 노드에 있는 kubelet 은 파드에 대한 새로운 {{< glossary_tooltip text="cgroup" term_id="cgroup" >}}을 생성한다. @@ -141,7 +142,7 @@ CPU 2250m와 메모리 320MiB 가 리소스로 요청되었으며, 이 결과는 ## 파드 cgroup 상한 확인하기 -워크로드가 실행 중인 노드에서 파드의 메모리 cgroup들을 확인 해보자. 다음의 예제에서, [`crictl`](https://github.com/kubernetes-sigs/cri-tools/blob/master/docs/crictl.md)은 노드에서 사용되며, +워크로드가 실행 중인 노드에서 파드의 메모리 cgroup들을 확인 해보자. 다음의 예제에서, [`crictl`](https://github.com/kubernetes-sigs/cri-tools/blob/master/docs/crictl.md)은 노드에서 사용되며, CRI-호환 컨테이너 런타임을 위해서 노드에서 사용할 수 있는 CLI 를 제공한다. 파드의 오버헤드 동작을 보여주는 좋은 예이며, 사용자가 노드에서 직접 cgroup들을 확인하지 않아도 된다. @@ -177,8 +178,8 @@ sudo crictl inspectp -o=json $POD_ID | grep cgroupsPath ``` ### 관찰성 -`kube_pod_overhead` 항목은 [kube-state-metrics](https://github.com/kubernetes/kube-state-metrics) -에서 사용할 수 있어, 파드 오버헤드가 사용되는 시기를 식별하고, +`kube_pod_overhead` 항목은 [kube-state-metrics](https://github.com/kubernetes/kube-state-metrics) +에서 사용할 수 있어, 파드 오버헤드가 사용되는 시기를 식별하고, 정의된 오버헤드로 실행되는 워크로드의 안정성을 관찰할 수 있다. 이 기능은 kube-state-metrics 의 1.9 릴리스에서는 사용할 수 없지만, 다음 릴리스에서는 가능할 예정이다. 그 전까지는 소스로부터 kube-state-metric 을 빌드해야 한다. @@ -190,5 +191,3 @@ sudo crictl inspectp -o=json $POD_ID | grep cgroupsPath * [런타임클래스](/ko/docs/concepts/containers/runtime-class/) * [파드오버헤드 디자인](https://github.com/kubernetes/enhancements/blob/master/keps/sig-node/20190226-pod-overhead.md) - - diff --git a/content/ko/docs/concepts/configuration/pod-priority-preemption.md b/content/ko/docs/concepts/configuration/pod-priority-preemption.md index ac39ed6c94..e0d6317b29 100644 --- a/content/ko/docs/concepts/configuration/pod-priority-preemption.md +++ b/content/ko/docs/concepts/configuration/pod-priority-preemption.md @@ -160,7 +160,7 @@ description: "이 프라이어리티 클래스는 XYZ 서비스 파드에만 사 해당 프라이어리티클래스의 파드는 비-선점될 것이다. `PreemptionPolicy` 필드를 사용하려면 `NonPreemptingPriority` -[기능 게이트](/docs/reference/command-line-tools-reference/feature-gates/)가 +[기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)가 활성화되어야 한다. 예제 유스케이스는 데이터 과학 관련 워크로드이다. @@ -408,4 +408,3 @@ kubelet 리소스 부족 축출은 사용량이 요청을 초과하지 않는 ## {{% heading "whatsnext" %}} * 프라이어리티클래스와 관련하여 리소스쿼터 사용에 대해 [기본적으로 프라이어리티 클래스 소비 제한](/ko/docs/concepts/policy/resource-quotas/#기본적으로-우선-순위-클래스-소비-제한)을 읽어보자. - diff --git a/content/ko/docs/concepts/configuration/resource-bin-packing.md b/content/ko/docs/concepts/configuration/resource-bin-packing.md index 4a8a6b7f2f..998456ca49 100644 --- a/content/ko/docs/concepts/configuration/resource-bin-packing.md +++ b/content/ko/docs/concepts/configuration/resource-bin-packing.md @@ -128,23 +128,23 @@ CPU: 1 Node Score: intel.com/foo = resourceScoringFunction((2+1),4) - = (100 - ((4-3)*100/4) - = (100 - 25) - = 75 - = rawScoringFunction(75) - = 7 + = (100 - ((4-3)*100/4) + = (100 - 25) + = 75 # requested + used = 75% * available + = rawScoringFunction(75) + = 7 # floor(75/10) Memory = resourceScoringFunction((256+256),1024) = (100 -((1024-512)*100/1024)) - = 50 + = 50 # requested + used = 50% * available = rawScoringFunction(50) - = 5 + = 5 # floor(50/10) CPU = resourceScoringFunction((2+1),8) = (100 -((8-3)*100/8)) - = 37.5 + = 37.5 # requested + used = 37.5% * available = rawScoringFunction(37.5) - = 3 + = 3 # floor(37.5/10) NodeScore = (7 * 5) + (5 * 1) + (3 * 3) / (5 + 1 + 3) = 5 @@ -189,5 +189,3 @@ NodeScore = (5 * 5) + (7 * 1) + (10 * 3) / (5 + 1 + 3) = 7 ``` - - diff --git a/content/ko/docs/concepts/containers/_index.md b/content/ko/docs/concepts/containers/_index.md index bdcb03bde5..76b1756a19 100755 --- a/content/ko/docs/concepts/containers/_index.md +++ b/content/ko/docs/concepts/containers/_index.md @@ -1,5 +1,41 @@ --- -title: "컨테이너" +title: 컨테이너 weight: 40 +description: 런타임 의존성과 함께 애플리케이션을 패키징하는 기술 +content_type: concept +no_list: true --- +<!-- overview --> + +실행하는 각 컨테이너는 반복 가능하다. 의존성이 포함된 표준화는 +어디에서 실행하던지 동일한 동작을 얻는다는 것을 +의미한다. + +컨테이너는 기본 호스트 인프라에서 애플리케이션을 분리한다. +따라서 다양한 클라우드 또는 OS 환경에서 보다 쉽게 ​​배포할 수 있다. + + + + +<!-- body --> + +## 컨테이너 이미지 +[컨테이너 이미지](/ko/docs/concepts/containers/images/)는 애플리케이션을 +실행하는 데 필요한 모든 것이 포함된 실행할 준비가 되어있는(ready-to-run) 소프트웨어 패키지이다. +여기에는 실행하는 데 필요한 코드와 모든 런타임, 애플리케이션 및 시스템 라이브러리, +그리고 모든 필수 설정에 대한 기본값이 포함된다. + +설계 상, 컨테이너는 변경할 수 없다. 이미 실행 중인 컨테이너의 코드를 +변경할 수 없다. 컨테이너화된 애플리케이션이 있고 +변경하려는 경우, 변경 사항이 포함된 새 컨테이너를 빌드한 +다음, 업데이트된 이미지에서 시작하도록 컨테이너를 다시 생성해야 한다. + +## 컨테이너 런타임 + +{{< glossary_definition term_id="container-runtime" length="all" >}} + +## {{% heading "whatsnext" %}} + +* [컨테이너 이미지](/ko/docs/concepts/containers/images/)에 대해 읽어보기 +* [파드](/ko/docs/concepts/workloads/pods/)에 대해 읽어보기 diff --git a/content/ko/docs/concepts/containers/container-environment.md b/content/ko/docs/concepts/containers/container-environment.md index 95671af60d..799306a9ff 100644 --- a/content/ko/docs/concepts/containers/container-environment.md +++ b/content/ko/docs/concepts/containers/container-environment.md @@ -56,6 +56,7 @@ FOO_SERVICE_PORT=<서비스가 동작 중인 포트> * [컨테이너 라이프사이클 훅(hooks)](/ko/docs/concepts/containers/container-lifecycle-hooks/)에 대해 더 배워 보기. -* [컨테이너 라이프사이클 이벤트에 핸들러 부착](/docs/tasks/configure-pod-container/attach-handler-lifecycle-event/) 실제 경험 얻기. +* [컨테이너 라이프사이클 이벤트에 핸들러 부착](/docs/tasks/configure-pod-container/attach-handler-lifecycle-event/) + 실제 경험 얻기. diff --git a/content/ko/docs/concepts/containers/images.md b/content/ko/docs/concepts/containers/images.md index afc9a3076a..0f7bb0cb13 100644 --- a/content/ko/docs/concepts/containers/images.md +++ b/content/ko/docs/concepts/containers/images.md @@ -6,18 +6,51 @@ weight: 10 <!-- overview --> -사용자 Docker 이미지를 생성하고 레지스트리에 푸시(push)하여 쿠버네티스 파드에서 참조되기 이전에 대비한다. +컨테이너 이미지는 애플리케이션과 모든 소프트웨어 의존성을 캡슐화하는 바이너리 데이터를 +나타낸다. 컨테이너 이미지는 독립적으로 실행할 수 있고 런타임 환경에 대해 +잘 정의된 가정을 만드는 실행 가능한 소프트웨어 번들이다. -컨테이너의 `image` 속성은 `docker` 커맨드에서 지원하는 문법과 같은 문법을 지원한다. 이는 프라이빗 레지스트리와 태그를 포함한다. +일반적으로 {{< glossary_tooltip text="파드" term_id="pod" >}}에서 +참조하기 전에 애플리케이션의 컨테이너 이미지를 +생성해서 레지스트리로 푸시한다. + +이 페이지는 컨테이너 이미지 개념의 개요를 제공한다. <!-- body --> +## 이미지 이름 + +컨테이너 이미지는 일반적으로 `pause`, `example/mycontainer` 또는 `kube-apiserver` 와 같은 이름을 부여한다. +이미지는 또한 레지스트리 호스트 이름을 포함할 수 있다. 예를 들면, `fictional.registry.example/imagename` +과 같다. 그리고 포트 번호도 포함할 수 있다. 예를 들면, `fictional.registry.example:10443/imagename` 과 같다. + +레지스트리 호스트 이름을 지정하지 않으면, 쿠버네티스는 도커 퍼블릭 레지스트리를 의미한다고 가정한다. + +이미지 이름 부분 다음에 _tag_ 를 추가할 수 있다(`docker` 와 `podman` +등의 명령과 함께 사용). +태그를 사용하면 동일한 시리즈 이미지의 다른 버전을 식별할 수 있다. + +이미지 태그는 소문자와 대문자, 숫자, 밑줄(`_`), +마침표(`.`) 및 대시(`-`)로 구성된다. +이미지 태그 안에서 구분 문자(`_`, `-` 그리고 `.`)를 +배치할 수 있는 위치에 대한 추가 규칙이 있다. +태그를 지정하지 않으면, 쿠버네티스는 태그 `latest` 를 의미한다고 가정한다. + +{{< caution >}} +프로덕션에서 컨테이너를 배포할 때는 `latest` 태그를 사용하지 않아야 한다. +실행 중인 이미지 버전을 추적하기가 어렵고 +이전에 잘 동작하던 버전으로 롤백하기가 더 어렵다. + +대신, `v1.42.0` 과 같은 의미있는 태그를 지정한다. +{{< /caution >}} + ## 이미지 업데이트 -기본 풀(pull) 정책은 `IfNotPresent`이며, 이것은 Kubelet이 이미 +기본 풀(pull) 정책은 `IfNotPresent`이며, 이것은 +{{< glossary_tooltip text="kubelet" term_id="kubelet" >}}이 이미 존재하는 이미지에 대한 풀을 생략하게 한다. 만약 항상 풀을 강제하고 싶다면, 다음 중 하나를 수행하면 된다. @@ -26,45 +59,18 @@ weight: 10 - `imagePullPolicy`와 사용할 이미지의 태그를 생략. - [AlwaysPullImages](/docs/reference/access-authn-authz/admission-controllers/#alwayspullimages) 어드미션 컨트롤러를 활성화. -`:latest` 태그 사용은 피해야 한다는 것을 참고하고, 자세한 정보는 [구성을 위한 모범 사례](/ko/docs/concepts/configuration/overview/#컨테이너-이미지)를 참고한다. +`imagePullPolicy` 가 특정값 없이 정의되면, `Always` 로 설정된다. -## 매니페스트로 멀티-아키텍처 이미지 빌드 +## 매니페스트가 있는 다중 아키텍처 이미지 -Docker CLI는 현재 `docker manifest` 커맨드와 `create`, `annotate`, `push`와 같은 서브 커맨드를 함께 지원한다. 이 커맨드는 매니페스트를 빌드하고 푸시하는데 사용할 수 있다. 매니페스트를 보기 위해서는 `docker manifest inspect`를 사용하면 된다. +바이너리 이미지를 제공할 뿐만 아니라, 컨테이너 레지스트리는 컨테이너 [이미지 매니페스트](https://github.com/opencontainers/image-spec/blob/master/manifest.md)를 제공할 수도 있다. 매니페스트는 아키텍처별 버전의 컨테이너에 대한 이미지 매니페스트를 참조할 수 있다. 아이디어는 이미지의 이름(예를 들어, `pause`, `example/mycontainer`, `kube-apiserver`)을 가질 수 있다는 것이다. 그래서 다른 시스템들이 사용하고 있는 컴퓨터 아키텍처에 적합한 바이너리 이미지를 가져올 수 있다. -다음에서 docker 문서를 확인하기 바란다. -https://docs.docker.com/edge/engine/reference/commandline/manifest/ - -이것을 사용하는 방법에 대한 예제는 빌드 하니스(harness)에서 참조한다. -https://cs.k8s.io/?q=docker%20manifest%20(create%7Cpush%7Cannotate)&i=nope&files=&repos= - -이 커맨드는 Docker CLI에 의존하며 그에 전적으로 구현된다. `$HOME/.docker/config.json` 편집 및 `experimental` 키를 `enabled`로 설정하거나, CLI 커맨드 호출 시 간단히 `DOCKER_CLI_EXPERIMENTAL` 환경 변수를 `enabled`로만 설정해도 된다. - -{{< note >}} -Docker *18.06 또는 그 이상* 을 사용하길 바란다. 더 낮은 버전은 버그가 있거나 실험적인 명령줄 옵션을 지원하지 않는다. 예를 들어 https://github.com/docker/cli/issues/1135 는 containerd에서 문제를 일으킨다. -{{< /note >}} - -오래된 매니페스트 업로드를 실행하는 데 어려움을 겪는다면, `$HOME/.docker/manifests`에서 오래된 매니페스트를 정리하여 새롭게 시작하면 된다. - -쿠버네티스의 경우, 일반적으로 접미사 `-$(ARCH)`가 있는 이미지를 사용해 왔다. 하위 호환성을 위해, 접미사가 있는 구형 이미지를 생성하길 바란다. 접미사에 대한 아이디어는 모든 아키텍처를 위한 매니페스트를 가졌다는 의미가 내포된 `pause` 이미지를 생성하고, 접미사가 붙은 이미지가 하드 코드되어 있을 오래된 구성 또는 YAML 파일에 대해 하위 호환된다는 의미가 내포되어 있는 `pause-amd64`를 생성하기 위한 것이다. +쿠버네티스 자체는 일반적으로 `-$(ARCH)` 접미사로 컨테이너 이미지의 이름을 지정한다. 이전 버전과의 호환성을 위해, 접미사가 있는 오래된 이미지를 생성한다. 아이디어는 모든 아키텍처에 대한 매니페스트가 있는 `pause` 이미지와 이전 구성 또는 이전에 접미사로 이미지를 하드 코딩한 YAML 파일과 호환되는 `pause-amd64` 라고 하는 이미지를 생성한다. ## 프라이빗 레지스트리 사용 프라이빗 레지스트리는 해당 레지스트리에서 이미지를 읽을 수 있는 키를 요구할 것이다. 자격 증명(credential)은 여러 가지 방법으로 제공될 수 있다. - - - Google 컨테이너 레지스트리 사용 - - 각 클러스터에 대하여 - - Google 컴퓨트 엔진 또는 Google 쿠버네티스 엔진에서 자동적으로 구성됨 - - 모든 파드는 해당 프로젝트의 프라이빗 레지스트리를 읽을 수 있음 - - AWS Elastic Container Registry(ECR) 사용 - - IAM 역할 및 정책을 사용하여 ECR 저장소에 접근을 제어함 - - ECR 로그인 자격 증명은 자동으로 갱신됨 - - Oracle 클라우드 인프라스트럭처 레지스트리(OCIR) 사용 - - IAM 역할과 정책을 사용하여 OCIR 저장소에 접근을 제어함 - - Azure 컨테이너 레지스트리(ACR) 사용 - - IBM 클라우드 컨테이너 레지스트리 사용 - - IAM 역할 및 정책을 사용하여 IBM 클라우드 컨테이너 레지스트리에 대한 접근 권한 부여 - 프라이빗 레지스트리에 대한 인증을 위한 노드 구성 - 모든 파드는 구성된 프라이빗 레지스트리를 읽을 수 있음 - 클러스터 관리자에 의한 노드 구성 필요 @@ -73,133 +79,57 @@ Docker *18.06 또는 그 이상* 을 사용하길 바란다. 더 낮은 버전 - 셋업을 위해서는 모든 노드에 대해서 root 접근이 필요 - 파드에 ImagePullSecrets을 명시 - 자신의 키를 제공하는 파드만 프라이빗 레지스트리에 접근 가능 + - 공급 업체별 또는 로컬 확장 + - 사용자 정의 노드 구성을 사용하는 경우, 사용자(또는 클라우드 + 제공자)가 컨테이너 레지스트리에 대한 노드 인증 메커니즘을 + 구현할 수 있다. -각 옵션은 아래에서 더 자세히 설명한다. +이들 옵션은 아래에서 더 자세히 설명한다. +### 프라이빗 레지스트리에 인증하도록 노드 구성 -### Google 컨테이너 레지스트리 사용 +노드에서 도커를 실행하는 경우, 프라이빗 컨테이너 레지스트리를 인증하도록 +도커 컨테이너 런타임을 구성할 수 있다. -쿠버네티스는 Google 컴퓨트 엔진(GCE)에서 동작할 때, [Google 컨테이너 -레지스트리(GCR)](https://cloud.google.com/tools/container-registry/)를 자연스럽게 -지원한다. 사용자의 클러스터가 GCE 또는 Google 쿠버네티스 엔진에서 동작 중이라면, 간단히 -이미지의 전체 이름(예: gcr.io/my_project/image:tag)을 사용하면 된다. - -클러스터 내에서 모든 파드는 해당 레지스트리에 있는 이미지에 읽기 접근 권한을 가질 것이다. - -Kubelet은 해당 인스턴스의 Google 서비스 계정을 이용하여 -GCR을 인증할 것이다. 인스턴스의 서비스 계정은 -`https://www.googleapis.com/auth/devstorage.read_only`라서, -프로젝트의 GCR로부터 풀은 할 수 있지만 푸시는 할 수 없다. - -### Amazon Elastic Container Registry 사용 - -쿠버네티스는 노드가 AWS EC2 인스턴스일 때, [Amazon Elastic Container Registry](https://aws.amazon.com/ecr/)를 자연스럽게 지원한다. - -간단히 이미지의 전체 이름(예: `ACCOUNT.dkr.ecr.REGION.amazonaws.com/imagename:tag`)을 -파드 정의에 사용하면 된다. - -파드를 생성할 수 있는 클러스터의 모든 사용자는 ECR 레지스트리에 있는 어떠한 -이미지든지 파드를 실행하는데 사용할 수 있다. - -kubelet은 ECR 자격 증명을 가져오고 주기적으로 갱신할 것이다. 이것을 위해서는 다음에 대한 권한이 필요하다. - -- `ecr:GetAuthorizationToken` -- `ecr:BatchCheckLayerAvailability` -- `ecr:GetDownloadUrlForLayer` -- `ecr:GetRepositoryPolicy` -- `ecr:DescribeRepositories` -- `ecr:ListImages` -- `ecr:BatchGetImage` - -요구 사항: - -- Kubelet 버전 `v1.2.0` 이상을 사용해야 한다. (예: `/usr/bin/kubelet --version=true`를 실행). -- 노드가 지역 A에 있고 레지스트리가 다른 지역 B에 있다면, 버전 `v1.3.0` 이상이 필요하다. -- 사용자의 지역에서 ECR이 지원되어야 한다. - -문제 해결: - -- 위의 모든 요구 사항을 확인한다. -- 워크스테이션에서 $REGION (예: `us-west-2`)의 자격 증명을 얻는다. 그 자격 증명을 사용하여 해당 호스트로 SSH를 하고 Docker를 수동으로 실행한다. 작동하는가? -- kubelet이 `--cloud-provider=aws`로 실행 중인지 확인한다. -- kubelet 로그 수준을 최소 3 이상으로 늘리고 kubelet 로그에서 (예: `journalctl -u kubelet`) 다음과 같은 로그 라인을 확인한다. - - `aws_credentials.go:109] unable to get ECR credentials from cache, checking ECR API` - - `aws_credentials.go:116] Got ECR credentials from ECR API for <AWS account ID for ECR>.dkr.ecr.<AWS region>.amazonaws.com` - -### Azure 컨테이너 레지스트리(ACR) 사용 -[Azure 컨테이너 레지스트리](https://azure.microsoft.com/en-us/services/container-registry/)를 사용하는 경우 -관리자 역할의 사용자나 서비스 주체(principal) 중 하나를 사용하여 인증할 수 있다. -어느 경우라도, 인증은 표준 Docker 인증을 통해서 수행된다. 이러한 지침은 -[azure-cli](https://github.com/azure/azure-cli) 명령줄 도구 사용을 가정한다. - -우선 레지스트리를 생성하고 자격 증명을 만들어야한다. 이에 대한 전체 문서는 -[Azure 컨테이너 레지스트리 문서](https://docs.microsoft.com/en-us/azure/container-registry/container-registry-get-started-azure-cli)에서 찾을 수 있다. - -컨테이너 레지스트리를 생성하고 나면, 다음의 자격 증명을 사용하여 로그인한다. - - * `DOCKER_USER` : 서비스 주체 또는 관리자 역할의 사용자명 - * `DOCKER_PASSWORD`: 서비스 주체 패스워드 또는 관리자 역할의 사용자 패스워드 - * `DOCKER_REGISTRY_SERVER`: `${some-registry-name}.azurecr.io` - * `DOCKER_EMAIL`: `${some-email-address}` - -해당 변수에 대한 값을 채우고 나면 -[쿠버네티스 시크릿을 구성하고 그것을 파드 디플로이를 위해서 사용](/ko/docs/concepts/containers/images/#파드에-imagepullsecrets-명시)할 수 있다. - -### IBM 클라우드 컨테이너 레지스트리 사용 -IBM 클라우드 컨테이너 레지스트리는 멀티-테넌트 프라이빗 이미지 레지스트리를 제공하여 사용자가 이미지를 안전하게 저장하고 공유할 수 있도록 한다. 기본적으로, 프라이빗 레지스트리의 이미지는 통합된 취약점 조언기(Vulnerability Advisor)를 통해 조사되어 보안 이슈와 잠재적 취약성을 검출한다. IBM 클라우드 계정의 모든 사용자가 이미지에 접근할 수 있도록 하거나, IAM 역할과 정책으로 IBM 클라우드 컨테이너 레지스트리 네임스페이스의 접근 권한을 부여해서 사용할 수 있다. - -IBM 클라우드 컨테이너 레지스트리 CLI 플러그인을 설치하고 사용자 이미지를 위한 네임스페이스를 생성하기 위해서는, [IBM 클라우드 컨테이너 레지스트리 시작하기](https://cloud.ibm.com/docs/Registry?topic=Registry-getting-started)를 참고한다. - -다른 추가적인 구성이 없는 IBM 클라우드 쿠버네티스 서비스 클러스터의 IBM 클라우드 컨테이너 레지스트리 내 기본 네임스페이스에 저장되어 있는 배포된 이미지를 동일 계정과 동일 지역에서 사용하려면 [이미지로부터 컨테이너 빌드하기](https://cloud.ibm.com/docs/containers?topic=containers-images)를 본다. 다른 구성 옵션에 대한 것은 [레지스트리부터 클러스터에 이미지를 가져오도록 권한을 부여하는 방법 이해하기](https://cloud.ibm.com/docs/containers?topic=containers-registry#cluster_registry_auth)를 본다. - -### 프라이빗 레지스트리에 대한 인증을 위한 노드 구성 +이 방법은 노드 구성을 제어할 수 있는 경우에 적합하다. {{< note >}} -Google 쿠버네티스 엔진에서 동작 중이라면, 이미 각 노드에 Google 컨테이너 레지스트리에 대한 자격 증명과 함께 `.dockercfg`가 있을 것이다. 그렇다면 이 방법은 쓸 수 없다. -{{< /note >}} - -{{< note >}} -AWS EC2에서 동작 중이고 EC2 컨테이너 레지스트리(ECR)을 사용 중이라면, 각 노드의 kubelet은 -ECR 로그인 자격 증명을 관리하고 업데이트할 것이다. 그렇다면 이 방법은 쓸 수 없다. -{{< /note >}} - -{{< note >}} -이 방법은 노드의 구성을 제어할 수 있는 경우에만 적합하다. 이 방법은 -GCE 및 자동 노드 교체를 수행하는 다른 클라우드 제공자에 대해서는 신뢰성 있게 작동하지 -않을 것이다. -{{< /note >}} - -{{< note >}} -현재 쿠버네티스는 docker 설정의 `auths`와 `HttpHeaders` 섹션만 지원한다. 이는 자격증명 도우미(`credHelpers` 또는 `credStore`)가 지원되지 않는다는 뜻이다. +쿠버네티스는 도커 구성에서 `auths` 와 `HttpHeaders` 섹션만 지원한다. +도커 자격 증명 도우미(`credHelpers` 또는 `credsStore`)는 지원되지 않는다. {{< /note >}} -Docker는 프라이빗 레지스트리를 위한 키를 `$HOME/.dockercfg` 또는 `$HOME/.docker/config.json` 파일에 저장한다. 만약 동일한 파일을 +도커는 프라이빗 레지스트리를 위한 키를 `$HOME/.dockercfg` 또는 `$HOME/.docker/config.json` 파일에 저장한다. 만약 동일한 파일을 아래의 검색 경로 리스트에 넣으면, kubelete은 이미지를 풀 할 때 해당 파일을 자격 증명 공급자로 사용한다. -* `{--root-dir:-/var/lib/kubelet}/config.json` -* `{cwd of kubelet}/config.json` -* `${HOME}/.docker/config.json` -* `/.docker/config.json` -* `{--root-dir:-/var/lib/kubelet}/.dockercfg` -* `{cwd of kubelet}/.dockercfg` -* `${HOME}/.dockercfg` -* `/.dockercfg` +* `{--root-dir:-/var/lib/kubelet}/config.json` +* `{cwd of kubelet}/config.json` +* `${HOME}/.docker/config.json` +* `/.docker/config.json` +* `{--root-dir:-/var/lib/kubelet}/.dockercfg` +* `{cwd of kubelet}/.dockercfg` +* `${HOME}/.dockercfg` +* `/.dockercfg` {{< note >}} -아마도 kubelet을 위한 사용자의 환경 파일에 `HOME=/root`을 명시적으로 설정해야 할 것이다. +kubelet 프로세스의 환경 변수에서 `HOME=/root` 를 명시적으로 설정해야 할 수 있다. {{< /note >}} 프라이빗 레지스트리를 사용도록 사용자의 노드를 구성하기 위해서 권장되는 단계는 다음과 같다. 이 예제의 경우, 사용자의 데스크탑/랩탑에서 아래 내용을 실행한다. - 1. 사용하고 싶은 각 자격 증명 세트에 대해서 `docker login [서버]`를 실행한다. 이것은 `$HOME/.docker/config.json`를 업데이트한다. + 1. 사용하고 싶은 각 자격 증명 세트에 대해서 `docker login [서버]`를 실행한다. 이것은 여러분 PC의 `$HOME/.docker/config.json`를 업데이트한다. 1. 편집기에서 `$HOME/.docker/config.json`를 보고 사용하고 싶은 자격 증명만 포함하고 있는지 확인한다. 1. 노드의 리스트를 구한다. 예를 들면 다음과 같다. - - 이름을 원하는 경우: `nodes=$(kubectl get nodes -o jsonpath='{range.items[*].metadata}{.name} {end}')` - - IP를 원하는 경우: `nodes=$(kubectl get nodes -o jsonpath='{range .items[*].status.addresses[?(@.type=="ExternalIP")]}{.address} {end}')` + - 이름을 원하는 경우: `nodes=$( kubectl get nodes -o jsonpath='{range.items[*].metadata}{.name} {end}' )` + - IP를 원하는 경우: `nodes=$( kubectl get nodes -o jsonpath='{range .items[*].status.addresses[?(@.type=="ExternalIP")]}{.address} {end}' )` 1. 로컬의 `.docker/config.json`를 위의 검색 경로 리스트 중 하나에 복사한다. - - 예: `for n in $nodes; do scp ~/.docker/config.json root@$n:/var/lib/kubelet/config.json; done` + - 이를 테스트하기 위한 예: `for n in $nodes; do scp ~/.docker/config.json root@"$n":/var/lib/kubelet/config.json; done` + +{{< note >}} +프로덕션 클러스터의 경우, 이 설정을 필요한 모든 노드에 적용할 수 있도록 +구성 관리 도구를 사용한다. +{{< /note >}} 프라이빗 이미지를 사용하는 파드를 생성하여 검증한다. 예를 들면 다음과 같다. @@ -256,11 +186,11 @@ Google 쿠버네티스 엔진에서 동작 중이라면, 이미 각 노드에 Go {{< note >}} 이 방법은 노드의 구성을 제어할 수 있는 경우에만 적합하다. 이 방법은 -GCE 및 자동 노드 교체를 수행하는 다른 클라우드 제공자에 대해서는 신뢰성 있게 작동하지 -않을 것이다. +클라우드 제공자가 노드를 관리하고 자동으로 교체한다면 안정적으로 +작동하지 않을 것이다. {{< /note >}} -기본적으로, kubelet은 지정된 레지스트리에서 각 이미지를 풀 하려고 할 것이다. +기본적으로, kubelet은 지정된 레지스트리에서 각 이미지를 풀 하려고 한다. 그러나, 컨테이너의 `imagePullPolicy` 속성이 `IfNotPresent` 또는 `Never`으로 설정되어 있다면, 로컬 이미지가 사용된다(우선적으로 또는 배타적으로). @@ -274,13 +204,13 @@ GCE 및 자동 노드 교체를 수행하는 다른 클라우드 제공자에 ### 파드에 ImagePullSecrets 명시 {{< note >}} -이 방법은 현재 Google 쿠버네티스 엔진, GCE 및 노드 생성이 자동화된 모든 클라우드 제공자에게 +이 방법은 프라이빗 레지스트리의 이미지를 기반으로 컨테이너를 실행하는 데 권장된다. {{< /note >}} -쿠버네티스는 파드에 레지스트리 키를 명시하는 것을 지원한다. +쿠버네티스는 파드에 컨테이너 이미지 레지스트리 키를 명시하는 것을 지원한다. -#### Docker 구성으로 시크릿 생성 +#### 도커 구성으로 시크릿 생성 대문자 값을 적절히 대체하여, 다음 커맨드를 실행한다. @@ -288,12 +218,14 @@ GCE 및 자동 노드 교체를 수행하는 다른 클라우드 제공자에 kubectl create secret docker-registry <name> --docker-server=DOCKER_REGISTRY_SERVER --docker-username=DOCKER_USER --docker-password=DOCKER_PASSWORD --docker-email=DOCKER_EMAIL ``` -만약 Docker 자격 증명 파일이 이미 존재한다면, 위의 명령을 사용하지 않고, -자격 증명 파일을 쿠버네티스 시크릿으로 가져올 수 있다. -[기존 Docker 자격 증명으로 시크릿 생성](/docs/tasks/configure-pod-container/pull-image-private-registry/#registry-secret-existing-credentials)에서 관련 방법을 설명하고 있다. +만약 도커 자격 증명 파일이 이미 존재한다면, 위의 명령을 사용하지 않고, +자격 증명 파일을 쿠버네티스 {{< glossary_tooltip text="시크릿" term_id="secret" >}}으로 +가져올 수 있다. +[기존 도커 자격 증명으로 시크릿 생성](/ko/docs/tasks/configure-pod-container/pull-image-private-registry/#registry-secret-existing-credentials)에서 관련 방법을 설명하고 있다. + `kubectl create secret docker-registry`는 -하나의 개인 레지스트리에서만 작동하는 시크릿을 생성하기 때문에, -여러 개인 컨테이너 레지스트리를 사용하는 경우 특히 유용하다. +하나의 프라이빗 레지스트리에서만 작동하는 시크릿을 생성하기 때문에, +여러 프라이빗 컨테이너 레지스트리를 사용하는 경우 특히 유용하다. {{< note >}} 파드는 이미지 풀 시크릿을 자신의 네임스페이스에서만 참조할 수 있다. @@ -305,6 +237,8 @@ kubectl create secret docker-registry <name> --docker-server=DOCKER_REGISTRY_SER 이제, `imagePullSecrets` 섹션을 파드의 정의에 추가함으로써 해당 시크릿을 참조하는 파드를 생성할 수 있다. +예를 들면 다음과 같다. + ```shell cat <<EOF > pod.yaml apiVersion: v1 @@ -330,28 +264,29 @@ EOF 그러나, 이 필드의 셋팅은 [서비스 어카운트](/docs/user-guide/service-accounts) 리소스에 imagePullSecrets을 셋팅하여 자동화할 수 있다. + 자세한 지침을 위해서는 [서비스 어카운트에 ImagePullSecrets 추가](/docs/tasks/configure-pod-container/configure-service-account/#add-imagepullsecrets-to-a-service-account)를 확인한다. 이것은 노드 당 `.docker/config.json`와 함께 사용할 수 있다. 자격 증명은 -병합될 것이다. 이 방법은 Google 쿠버네티스 엔진에서 작동될 것이다. +병합될 것이다. -### 유스케이스 +## 유스케이스 프라이빗 레지스트리를 구성하기 위한 많은 솔루션이 있다. 다음은 여러 가지 일반적인 유스케이스와 제안된 솔루션이다. 1. 비소유 이미지(예를 들어, 오픈소스)만 실행하는 클러스터의 경우. 이미지를 숨길 필요가 없다. - - Docker hub의 퍼블릭 이미지를 사용한다. + - 도커 허브의 퍼블릭 이미지를 사용한다. - 설정이 필요 없다. - - GCE 및 Google 쿠버네티스 엔진에서는, 속도와 가용성 향상을 위해서 로컬 미러가 자동적으로 사용된다. + - 일부 클라우드 제공자는 퍼블릭 이미지를 자동으로 캐시하거나 미러링하므로, 가용성이 향상되고 이미지를 가져오는 시간이 줄어든다. 1. 모든 클러스터 사용자에게는 보이지만, 회사 외부에는 숨겨야하는 일부 독점 이미지를 실행하는 클러스터의 경우. - - 호스트 된 프라이빗 [Docker 레지스트리](https://docs.docker.com/registry/)를 사용한다. - - 그것은 [Docker Hub](https://hub.docker.com/signup)에 호스트 되어 있거나, 다른 곳에 되어 있을 것이다. + - 호스트 된 프라이빗 [도커 레지스트리](https://docs.docker.com/registry/)를 사용한다. + - 그것은 [도커 허브](https://hub.docker.com/signup)에 호스트 되어 있거나, 다른 곳에 되어 있을 것이다. - 위에 설명된 바와 같이 수동으로 .docker/config.json을 구성한다. - 또는, 방화벽 뒤에서 읽기 접근 권한을 가진 내부 프라이빗 레지스트리를 실행한다. - 쿠버네티스 구성은 필요 없다. - - 또는, GCE 및 Google 쿠버네티스 엔진에서는, 프로젝트의 Google 컨테이너 레지스트리를 사용한다. + - 이미지 접근을 제어하는 ​​호스팅된 컨테이너 이미지 레지스트리 서비스를 사용한다. - 그것은 수동 노드 구성에 비해서 클러스터 오토스케일링과 더 잘 동작할 것이다. - 또는, 노드의 구성 변경이 불편한 클러스터에서는, `imagePullSecrets`를 사용한다. 1. 독점 이미지를 가진 클러스터로, 그 중 일부가 더 엄격한 접근 제어를 필요로 하는 경우. @@ -365,6 +300,8 @@ imagePullSecrets을 셋팅하여 자동화할 수 있다. 다중 레지스트리에 접근해야 하는 경우, 각 레지스트리에 대해 하나의 시크릿을 생성할 수 있다. -Kubelet은 모든`imagePullSecrets` 파일을 하나의 가상`.docker / config.json` 파일로 병합한다. +Kubelet은 모든 `imagePullSecrets` 파일을 하나의 가상 `.docker/config.json` 파일로 병합한다. +## {{% heading "whatsnext" %}} +* [OCI 이미지 매니페스트 명세](https://github.com/opencontainers/image-spec/blob/master/manifest.md) 읽어보기 diff --git a/content/ko/docs/concepts/containers/overview.md b/content/ko/docs/concepts/containers/overview.md deleted file mode 100644 index 7ad30f5749..0000000000 --- a/content/ko/docs/concepts/containers/overview.md +++ /dev/null @@ -1,44 +0,0 @@ ---- -title: 컨테이너 개요 -content_type: concept -weight: 10 ---- - -<!-- overview --> - -컨테이너는 런타임에 필요한 종속성과 애플리케이션의 -컴파일 된 코드를 패키징 하는 기술이다. 실행되는 각각의 -컨테이너는 반복해서 사용 가능하다. 종속성이 포함된 표준화를 -통해 컨테이너가 실행되는 환경과 무관하게 항상 동일하게 -동작한다. - -컨테이너는 기본 호스트 인프라 환경에서 애플리케이션의 실행환경을 분리한다. -따라서 다양한 클라우드 환경이나 운영체제에서 쉽게 배포 할 수 있다. - - - - -<!-- body --> - -## 컨테이너 이미지 -[컨테이너 이미지](/ko/docs/concepts/containers/images/) 는 즉시 실행할 수 있는 -소프트웨어 패키지이며, 애플리케이션을 실행하는데 필요한 모든 것 -(필요한 코드와 런타임, 애플리케이션 및 시스템 라이브러리 등의 모든 필수 설정에 대한 기본값) -을 포함한다. - -원칙적으로, 컨테이너는 변경되지 않는다. 이미 구동 중인 컨테이너의 -코드를 변경할 수 없다. 컨테이너화 된 애플리케이션이 있고 그 -애플리케이션을 변경하려는 경우, 변경사항을 포함하여 만든 -새로운 이미지를 통해 컨테이너를 다시 생성해야 한다. - - -## 컨테이너 런타임 - -{{< glossary_definition term_id="container-runtime" length="all" >}} - - -## {{% heading "whatsnext" %}} - -* [컨테이너 이미지](/ko/docs/concepts/containers/images/)에 대해 읽어보기 -* [파드](/ko/docs/concepts/workloads/pods/)에 대해 읽어보기 - diff --git a/content/ko/docs/concepts/containers/runtime-class.md b/content/ko/docs/concepts/containers/runtime-class.md index 8af3bda7a8..3da41dfde0 100644 --- a/content/ko/docs/concepts/containers/runtime-class.md +++ b/content/ko/docs/concepts/containers/runtime-class.md @@ -1,5 +1,5 @@ --- -title: 런타임 클래스 +title: 런타임클래스(RuntimeClass) content_type: concept weight: 20 --- @@ -8,7 +8,7 @@ weight: 20 {{< feature-state for_k8s_version="v1.12" state="alpha" >}} -이 페이지는 런타임 클래스(RuntimeClass) 리소스와 런타임 선택 메커니즘에 대해서 설명한다. +이 페이지는 런타임클래스 리소스와 런타임 선택 메커니즘에 대해서 설명한다. 런타임클래스는 컨테이너 런타임을 구성을 선택하는 기능이다. 컨테이너 런타임 구성은 파드의 컨테이너를 실행하는데 사용된다. @@ -20,69 +20,69 @@ weight: 20 ## 동기 -서로 다른 파드간에 런타임 클래스를 설정하여 +서로 다른 파드간에 런타임클래스를 설정하여 성능대 보안의 균형을 유지할 수 있다. 예를 들어, 일부 작업에서 높은 수준의 정보 보안 보증이 요구되는 경우, 하드웨어 가상화를 이용하는 컨테이너 런타임으로 파드를 실행하도록 예약하는 선택을 할 수 있다. 그러면 몇가지 추가적인 오버헤드는 있지만 대체 런타임을 추가 분리하는 유익이 있다. -또한 런타임 클래스를 사용하여 컨테이너 런타임이 같으나 설정이 다른 +또한 런타임클래스를 사용하여 컨테이너 런타임이 같으나 설정이 다른 여러 파드를 실행할 수 있다. ## 셋업 -RuntimeClass 특징 게이트가 활성화(기본값)를 확인한다. -특징 게이트 활성화에 대한 설명은 [특징 게이트](/docs/reference/command-line-tools-reference/feature-gates/)를 -참고한다. `RuntimeClass` 특징 게이트는 apiservers _및_ kubelets에서 활성화되어야 한다. +런타임클래스 기능 게이트가 활성화(기본값)된 것을 확인한다. +기능 게이트 활성화에 대한 설명은 [기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)를 +참고한다. `RuntimeClass` 기능 게이트는 apiservers _및_ kubelets에서 활성화되어야 한다. 1. CRI 구현(implementation)을 노드에 설정(런타임에 따라서) -2. 상응하는 런타임 클래스 리소스 생성 +2. 상응하는 런타임클래스 리소스 생성 ### 1. CRI 구현을 노드에 설정 -런타임 클래스를 통한 가능한 구성은 컨테이너 런타임 인터페이스(CRI) 구현에 의존적이다. +런타임클래스를 통한 가능한 구성은 컨테이너 런타임 인터페이스(CRI) 구현에 의존적이다. 사용자의 CRI 구현에 따른 설정 방법은 연관된 문서를 통해서 확인한다([아래](#cri-configuration)). {{< note >}} -런타임 클래스는 기본적으로 클러스터 전체에 걸쳐 동질의 노드 설정 +런타임클래스는 기본적으로 클러스터 전체에 걸쳐 동질의 노드 설정 (모든 노드가 컨테이너 런타임에 준하는 동일한 방식으로 설정되었음을 의미)을 가정한다. 이종의(heterogenous) 노드 설정을 지원하기 위해서는, 아래 [스케줄](#스케줄)을 참고한다. {{< /note >}} -해당 설정은 상응하는 `handler` 이름을 가지며, 이는 런타임 클래스에 의해서 참조된다. +해당 설정은 상응하는 `handler` 이름을 가지며, 이는 런타임클래스에 의해서 참조된다. 런타임 핸들러는 유효한 DNS 1123 서브도메인(알파-숫자 + `-`와 `.`문자)을 가져야 한다. -### 2. 상응하는 런타임 클래스 리소스 생성 +### 2. 상응하는 런타임클래스 리소스 생성 1단계에서 셋업 한 설정은 연관된 `handler` 이름을 가져야 하며, 이를 통해서 설정을 식별할 수 있다. -각 런타임 핸들러(그리고 선택적으로 비어있는 `""` 핸들러)에 대해서, 상응하는 런타임 클래스 오브젝트를 생성한다. +각 런타임 핸들러(그리고 선택적으로 비어있는 `""` 핸들러)에 대해서, 상응하는 런타임클래스 오브젝트를 생성한다. -현재 런타임 클래스 리소스는 런타임 클래스 이름(`metadata.name`)과 런타임 핸들러 +현재 런타임클래스 리소스는 런타임클래스 이름(`metadata.name`)과 런타임 핸들러 (`handler`)로 단 2개의 중요 필드만 가지고 있다. 오브젝트 정의는 다음과 같은 형태이다. ```yaml -apiVersion: node.k8s.io/v1beta1 # 런타임 클래스는 node.k8s.io API 그룹에 정의되어 있음 +apiVersion: node.k8s.io/v1beta1 # 런타임클래스는 node.k8s.io API 그룹에 정의되어 있음 kind: RuntimeClass metadata: - name: myclass # 런타임 클래스는 해당 이름을 통해서 참조됨 - # 런타임 클래스는 네임스페이스가 없는 리소스임 + name: myclass # 런타임클래스는 해당 이름을 통해서 참조됨 + # 런타임클래스는 네임스페이스가 없는 리소스임 handler: myconfiguration # 상응하는 CRI 설정의 이름임 ``` -런타임 클래스 오브젝트의 이름은 유효한 -[DNS 서브도메인 이름](/ko/docs/concepts/overview/working-with-objects/names/#dns-서브도메인-이름들)어이야 한다. +런타임클래스 오브젝트의 이름은 유효한 +[DNS 서브도메인 이름](/ko/docs/concepts/overview/working-with-objects/names/#dns-서브도메인-이름)어이야 한다. {{< note >}} -런타임 클래스 쓰기 작업(create/update/patch/delete)은 +런타임클래스 쓰기 작업(create/update/patch/delete)은 클러스터 관리자로 제한할 것을 권장한다. 이것은 일반적으로 기본 설정이다. 더 자세한 정보는 [권한 개요](/docs/reference/access-authn-authz/authorization/)를 참고한다. {{< /note >}} ## 사용 -클러스터를 위해서 런타임 클래스를 설정하고 나면, 그것을 사용하는 것은 매우 간단하다. 파드 스펙에 +클러스터를 위해서 런타임클래스를 설정하고 나면, 그것을 사용하는 것은 매우 간단하다. 파드 스펙에 `runtimeClassName`를 명시한다. 예를 들면 다음과 같다. ```yaml @@ -95,18 +95,18 @@ spec: # ... ``` -이것은 Kubelet이 지명된 런타임 클래스를 사용하여 해당 파드를 실행하도록 지시할 것이다. -만약 지명된 런타임 클래스가 없거나, CRI가 상응하는 핸들러를 실행할 수 없는 경우, 파드는 -`Failed` 터미널 [단계](/ko/docs/concepts/workloads/pods/pod-lifecycle/#pod-phase)로 들어간다. +이것은 Kubelet이 지명된 런타임클래스를 사용하여 해당 파드를 실행하도록 지시할 것이다. +만약 지명된 런타임클래스가 없거나, CRI가 상응하는 핸들러를 실행할 수 없는 경우, 파드는 +`Failed` 터미널 [단계](/ko/docs/concepts/workloads/pods/pod-lifecycle/#파드의-단계-phase)로 들어간다. 에러 메시지에 상응하는 [이벤트](/docs/tasks/debug-application-cluster/debug-application-introspection/)를 확인한다. 만약 명시된 `runtimeClassName`가 없다면, 기본 런타임 핸들러가 사용되며, -런타임 클래스 특징이 비활성화되었을 때와 동일하게 동작한다. +런타임클래스 기능이 비활성화되었을 때와 동일하게 동작한다. ### CRI 구성 {#cri-configuration} -CRI 런타임 설치에 대한 자세한 내용은 [CRI 설치](/docs/setup/production-environment/container-runtimes/)를 확인한다. +CRI 런타임 설치에 대한 자세한 내용은 [CRI 설치](/ko/docs/setup/production-environment/container-runtimes/)를 확인한다. #### dockershim @@ -135,43 +135,41 @@ https://github.com/containerd/cri/blob/master/docs/config.md runtime_path = "${PATH_TO_BINARY}" ``` -더 자세한 것은 CRI-O의 [설정 문서][100]를 본다. - -[100]: https://raw.githubusercontent.com/cri-o/cri-o/9f11d1d/docs/crio.conf.5.md +더 자세한 것은 CRI-O의 [설정 문서](https://raw.githubusercontent.com/cri-o/cri-o/9f11d1d/docs/crio.conf.5.md)를 본다. ## 스케줄 {{< feature-state for_k8s_version="v1.16" state="beta" >}} -쿠버네티스 v1.16 부터, 런타임 클래스는 `scheduling` 필드를 통해 이종의 클러스터 지원을 포함한다. -이 필드를 사용하면, 이 런타임 클래스를 갖는 파드가 이를 지원하는 노드로 스케줄된다는 것을 보장할 수 있다. -이 스케줄링 기능을 사용하려면, [런타임 클래스 어드미션(admission) 컨트롤러][]를 활성화(1.16 부터 기본 값)해야 한다. +쿠버네티스 v1.16 부터, 런타임 클래스는 `scheduling` 필드를 통해 이종의 클러스터 +지원을 포함한다. 이 필드를 사용하면, 이 런타임 클래스를 갖는 파드가 이를 지원하는 +노드로 스케줄된다는 것을 보장할 수 있다. 이 스케줄링 기능을 사용하려면, +[런타임 클래스 어드미션(admission) 컨트롤러](/docs/reference/access-authn-authz/admission-controllers/#runtimeclass)를 +활성화(1.16 부터 기본값)해야 한다. -파드가 지정된 런타임 클래스를 지원하는 노드에 안착한다는 것을 보장하려면, +파드가 지정된 런타임클래스를 지원하는 노드에 안착한다는 것을 보장하려면, 해당 노드들은 `runtimeClass.scheduling.nodeSelector` 필드에서 선택되는 공통 레이블을 가져야한다. 런타임 클래스의 nodeSelector는 파드의 nodeSelector와 어드미션 시 병합되어서, 실질적으로 -각각에 의해 선택된 노드의 교집합을 취한다. 충돌이 있는 경우, 파드는 거부된다. +각각에 의해 선택된 노드의 교집합을 취한다. 충돌이 있는 경우, +파드는 거부된다. -지원되는 노드가 테인트(taint)되어서 다른 런타임 클래스 파드가 노드에서 구동되는 것을 막고 있다면, -`tolerations`를 런타임 클래스에 추가할 수 있다. `nodeSelector`를 사용하면, 어드미션 시 +지원되는 노드가 테인트(taint)되어서 다른 런타임클래스 파드가 노드에서 구동되는 것을 막고 있다면, +`tolerations`를 런타임클래스에 추가할 수 있다. `nodeSelector`를 사용하면, 어드미션 시 해당 톨러레이션(toleration)이 파드의 톨러레이션과 병합되어, 실질적으로 각각에 의해 선택된 노드의 합집합을 취한다. 노드 셀렉터와 톨러레이션 설정에 대해 더 배우려면 [노드에 파드 할당](/ko/docs/concepts/scheduling-eviction/assign-pod-node/)을 참고한다. -[런타임 클래스 어드미션 컨트롤러]: /docs/reference/access-authn-authz/admission-controllers/#runtimeclass - ### 파드 오버헤드 {{< feature-state for_k8s_version="v1.18" state="beta" >}} 파드 실행과 연관되는 _오버헤드_ 리소스를 지정할 수 있다. 오버헤드를 선언하면 클러스터(스케줄러 포함)가 파드와 리소스에 대한 결정을 내릴 때 처리를 할 수 있다. -PodOverhead를 사용하려면, PodOverhead [기능 게이트](/docs/reference/command-line-tools-reference/feature-gates/) +PodOverhead를 사용하려면, PodOverhead [기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/) 를 활성화 시켜야 한다. (기본으로 활성화 되어 있다.) - 파드 오버헤드는 런타임 클래스에서 `overhead` 필드를 통해 정의된다. 이 필드를 사용하면, 해당 런타임 클래스를 사용해서 구동 중인 파드의 오버헤드를 특정할 수 있고 이 오버헤드가 쿠버네티스 내에서 처리된다는 것을 보장할 수 있다. @@ -180,9 +178,7 @@ PodOverhead를 사용하려면, PodOverhead [기능 게이트](/docs/reference/c ## {{% heading "whatsnext" %}} -- [런타임 클래스 설계](https://github.com/kubernetes/enhancements/blob/master/keps/sig-node/runtime-class.md) -- [런타임 클래스 스케줄링 설계](https://github.com/kubernetes/enhancements/blob/master/keps/sig-node/runtime-class-scheduling.md) -- [파드 오버헤드](/docs/concepts/configuration/pod-overhead/) 개념에 대해 읽기 +- [런타임클래스 설계](https://github.com/kubernetes/enhancements/blob/master/keps/sig-node/runtime-class.md) +- [런타임클래스 스케줄링 설계](https://github.com/kubernetes/enhancements/blob/master/keps/sig-node/runtime-class-scheduling.md) +- [파드 오버헤드](/ko/docs/concepts/configuration/pod-overhead/) 개념에 대해 읽기 - [파드 오버헤드 기능 설계](https://github.com/kubernetes/enhancements/blob/master/keps/sig-node/20190226-pod-overhead.md) - - diff --git a/content/ko/docs/concepts/extend-kubernetes/_index.md b/content/ko/docs/concepts/extend-kubernetes/_index.md index ff8525f171..29d8672fca 100644 --- a/content/ko/docs/concepts/extend-kubernetes/_index.md +++ b/content/ko/docs/concepts/extend-kubernetes/_index.md @@ -1,4 +1,206 @@ --- -title: 쿠버네티스 확장하기 +title: 쿠버네티스 확장 weight: 110 +description: 쿠버네티스 클러스터의 동작을 변경하는 다양한 방법 +content_type: concept +no_list: true --- + +<!-- overview --> + +쿠버네티스는 매우 유연하게 구성할 수 있고 확장 가능하다. 결과적으로 +쿠버네티스 프로젝트를 포크하거나 코드에 패치를 제출할 필요가 +거의 없다. + +이 가이드는 쿠버네티스 클러스터를 사용자 정의하기 위한 옵션을 설명한다. +쿠버네티스 클러스터를 업무 환경의 요구에 맞게 +조정하는 방법을 이해하려는 {{< glossary_tooltip text="클러스터 운영자" term_id="cluster-operator" >}}를 대상으로 한다. +잠재적인 {{< glossary_tooltip text="플랫폼 개발자" term_id="platform-developer" >}} 또는 쿠버네티스 프로젝트 {{< glossary_tooltip text="컨트리뷰터" term_id="contributor" >}}인 개발자에게도 +어떤 익스텐션(extension) 포인트와 패턴이 있는지, +그리고 그것들의 트레이드오프와 제약에 대한 소개 자료로 유용할 것이다. + + + + +<!-- body --> + +## 개요 + +사용자 정의 방식은 크게 플래그, 로컬 구성 파일 또는 API 리소스 변경만 포함하는 *구성* 과 추가 프로그램이나 서비스 실행과 관련된 *익스텐션* 으로 나눌 수 있다. 이 문서는 주로 익스텐션에 관한 것이다. + +## 구성 + +*구성 파일* 및 *플래그* 는 온라인 문서의 레퍼런스 섹션에 각 바이너리 별로 문서화되어 있다. + +* [kubelet](/docs/admin/kubelet/) +* [kube-apiserver](/docs/admin/kube-apiserver/) +* [kube-controller-manager](/docs/admin/kube-controller-manager/) +* [kube-scheduler](/docs/admin/kube-scheduler/). + +호스팅된 쿠버네티스 서비스 또는 매니지드 설치 환경의 배포판에서 플래그 및 구성 파일을 항상 변경할 수 있는 것은 아니다. 변경 가능한 경우 일반적으로 클러스터 관리자만 변경할 수 있다. 또한 향후 쿠버네티스 버전에서 변경될 수 있으며, 이를 설정하려면 프로세스를 다시 시작해야 할 수도 있다. 이러한 이유로 다른 옵션이 없는 경우에만 사용해야 한다. + +[리소스쿼터](/ko/docs/concepts/policy/resource-quotas/), [파드시큐리티폴리시(PodSecurityPolicy)](/ko/docs/concepts/policy/pod-security-policy/), [네트워크폴리시](/ko/docs/concepts/services-networking/network-policies/) 및 역할 기반 접근 제어([RBAC](/docs/reference/access-authn-authz/rbac/))와 같은 *빌트인 정책 API(built-in Policy API)* 는 기본적으로 제공되는 쿠버네티스 API이다. API는 일반적으로 호스팅된 쿠버네티스 서비스 및 매니지드 쿠버네티스 설치 환경과 함께 사용된다. 그것들은 선언적이며 파드와 같은 다른 쿠버네티스 리소스와 동일한 규칙을 사용하므로, 새로운 클러스터 구성을 반복할 수 있고 애플리케이션과 동일한 방식으로 관리할 수 ​​있다. 또한, 이들 API가 안정적인 경우, 다른 쿠버네티스 API와 같이 [정의된 지원 정책](/docs/reference/deprecation-policy/)을 사용할 수 있다. 이러한 이유로 인해 구성 파일과 플래그보다 선호된다. + +## 익스텐션 + +익스텐션은 쿠버네티스를 확장하고 쿠버네티스와 긴밀하게 통합되는 소프트웨어 컴포넌트이다. +이들 컴포넌트는 쿠버네티스가 새로운 유형과 새로운 종류의 하드웨어를 지원할 수 있게 해준다. + +대부분의 클러스터 관리자는 쿠버네티스의 호스팅 또는 배포판 인스턴스를 사용한다. +결과적으로 대부분의 쿠버네티스 사용자는 익스텐션 기능을 설치할 필요가 없고 +새로운 익스텐션 기능을 작성할 필요가 있는 사람은 더 적다. + +## 익스텐션 패턴 + +쿠버네티스는 클라이언트 프로그램을 작성하여 자동화 되도록 설계되었다. +쿠버네티스 API를 읽고 쓰는 프로그램은 유용한 자동화를 제공할 수 있다. +*자동화* 는 클러스터 상에서 또는 클러스터 밖에서 실행할 수 있다. 이 문서의 지침에 따라 +고가용성과 강력한 자동화를 작성할 수 있다. +자동화는 일반적으로 호스트 클러스터 및 매니지드 설치 환경을 포함한 모든 +쿠버네티스 클러스터에서 작동한다. + +쿠버네티스와 잘 작동하는 클라이언트 프로그램을 작성하기 위한 특정 패턴은 *컨트롤러* 패턴이라고 한다. +컨트롤러는 일반적으로 오브젝트의 `.spec`을 읽고, 가능한 경우 수행한 다음 +오브젝트의 `.status`를 업데이트 한다. + +컨트롤러는 쿠버네티스의 클라이언트이다. 쿠버네티스가 클라이언트이고 +원격 서비스를 호출할 때 이를 *웹훅(Webhook)* 이라고 한다. 원격 서비스를 +*웹훅 백엔드* 라고 한다. 컨트롤러와 마찬가지로 웹훅은 장애 지점을 +추가한다. + +웹훅 모델에서 쿠버네티스는 원격 서비스에 네트워크 요청을 한다. +*바이너리 플러그인* 모델에서 쿠버네티스는 바이너리(프로그램)를 실행한다. +바이너리 플러그인은 kubelet(예: +[Flex Volume 플러그인](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-storage/flexvolume.md)과 +[네트워크 플러그인](/ko/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/))과 +kubectl에서 +사용한다. + +아래는 익스텐션 포인트가 쿠버네티스 컨트롤 플레인과 상호 작용하는 방법을 +보여주는 다이어그램이다. + +<img src="https://docs.google.com/drawings/d/e/2PACX-1vQBRWyXLVUlQPlp7BvxvV9S1mxyXSM6rAc_cbLANvKlu6kCCf-kGTporTMIeG5GZtUdxXz1xowN7RmL/pub?w=960&h=720"> + +<!-- image source drawing https://docs.google.com/drawings/d/1muJ7Oxuj_7Gtv7HV9-2zJbOnkQJnjxq-v1ym_kZfB-4/edit?ts=5a01e054 --> + + +## 익스텐션 포인트 + +이 다이어그램은 쿠버네티스 시스템의 익스텐션 포인트를 보여준다. + +<img src="https://docs.google.com/drawings/d/e/2PACX-1vSH5ZWUO2jH9f34YHenhnCd14baEb4vT-pzfxeFC7NzdNqRDgdz4DDAVqArtH4onOGqh0bhwMX0zGBb/pub?w=425&h=809"> + +<!-- image source diagrams: https://docs.google.com/drawings/d/1k2YdJgNTtNfW7_A8moIIkij-DmVgEhNrn3y2OODwqQQ/view --> + +1. 사용자는 종종 `kubectl`을 사용하여 쿠버네티스 API와 상호 작용한다. [Kubectl 플러그인](/ko/docs/tasks/extend-kubectl/kubectl-plugins/)은 kubectl 바이너리를 확장한다. 개별 사용자의 로컬 환경에만 영향을 미치므로 사이트 전체 정책을 적용할 수는 없다. +2. apiserver는 모든 요청을 처리한다. apiserver의 여러 유형의 익스텐션 포인트는 요청을 인증하거나, 콘텐츠를 기반으로 요청을 차단하거나, 콘텐츠를 편집하고, 삭제 처리를 허용한다. 이 내용은 [API 접근 익스텐션](/ko/docs/concepts/extend-kubernetes/extend-cluster/#api-접근-익스텐션) 섹션에 설명되어 있다. +3. apiserver는 다양한 종류의 *리소스* 를 제공한다. `pods`와 같은 *빌트인 리소스 종류* 는 쿠버네티스 프로젝트에 의해 정의되며 변경할 수 없다. 직접 정의한 리소스를 추가할 수도 있고, [커스텀 리소스](/ko/docs/concepts/extend-kubernetes/extend-cluster/#사용자-정의-유형) 섹션에 설명된대로 *커스텀 리소스* 라고 부르는 다른 프로젝트에서 정의한 리소스를 추가할 수도 있다. 커스텀 리소스는 종종 API 접근 익스텐션과 함께 사용된다. +4. 쿠버네티스 스케줄러는 파드를 배치할 노드를 결정한다. 스케줄링을 확장하는 몇 가지 방법이 있다. 이들은 [스케줄러 익스텐션](/ko/docs/concepts/extend-kubernetes/extend-cluster/#스케줄러-익스텐션) 섹션에 설명되어 있다. +5. 쿠버네티스의 많은 동작은 API-Server의 클라이언트인 컨트롤러(Controller)라는 프로그램으로 구현된다. 컨트롤러는 종종 커스텀 리소스와 함께 사용된다. +6. kubelet은 서버에서 실행되며 파드가 클러스터 네트워크에서 자체 IP를 가진 가상 서버처럼 보이도록 한다. [네트워크 플러그인](/ko/docs/concepts/extend-kubernetes/extend-cluster/#네트워크-플러그인)을 사용하면 다양한 파드 네트워킹 구현이 가능하다. +7. kubelet은 컨테이너의 볼륨을 마운트 및 마운트 해제한다. 새로운 유형의 스토리지는 [스토리지 플러그인](/ko/docs/concepts/extend-kubernetes/extend-cluster/#스토리지-플러그인)을 통해 지원될 수 있다. + +어디서부터 시작해야 할지 모르겠다면, 이 플로우 차트가 도움이 될 수 있다. 일부 솔루션에는 여러 유형의 익스텐션이 포함될 수 있다. + + +<img src="https://docs.google.com/drawings/d/e/2PACX-1vRWXNNIVWFDqzDY0CsKZJY3AR8sDeFDXItdc5awYxVH8s0OLherMlEPVUpxPIB1CSUu7GPk7B2fEnzM/pub?w=1440&h=1080"> + +<!-- image source drawing: https://docs.google.com/drawings/d/1sdviU6lDz4BpnzJNHfNpQrqI9F19QZ07KnhnxVrp2yg/edit --> + +## API 익스텐션 +### 사용자 정의 유형 + +새 컨트롤러, 애플리케이션 구성 오브젝트 또는 기타 선언적 API를 정의하고 `kubectl` 과 같은 쿠버네티스 도구를 사용하여 관리하려면 쿠버네티스에 커스텀 리소스를 추가하자. + +애플리케이션, 사용자 또는 모니터링 데이터의 데이터 저장소로 커스텀 리소스를 사용하지 않는다. + +커스텀 리소스에 대한 자세한 내용은 [커스텀 리소스 개념 가이드](/ko/docs/concepts/extend-kubernetes/api-extension/custom-resources/)를 참고하길 바란다. + + +### 새로운 API와 자동화의 결합 + +사용자 정의 리소스 API와 컨트롤 루프의 조합을 [오퍼레이터(operator) 패턴](/ko/docs/concepts/extend-kubernetes/operator/)이라고 한다. 오퍼레이터 패턴은 특정 애플리케이션, 일반적으로 스테이트풀(stateful) 애플리케이션을 관리하는 데 사용된다. 이러한 사용자 정의 API 및 컨트롤 루프를 사용하여 스토리지나 정책과 같은 다른 리소스를 제어할 수도 있다. + +### 빌트인 리소스 변경 + +사용자 정의 리소스를 추가하여 쿠버네티스 API를 확장하면 추가된 리소스는 항상 새로운 API 그룹에 속한다. 기존 API 그룹을 바꾸거나 변경할 수 없다. +API를 추가해도 기존 API(예: 파드)의 동작에 직접 영향을 미치지는 않지만 API 접근 익스텐션은 영향을 준다. + + +### API 접근 익스텐션 + +요청이 쿠버네티스 API 서버에 도달하면 먼저 인증이 되고, 그런 다음 승인된 후 다양한 유형의 어드미션 컨트롤이 적용된다. 이 흐름에 대한 자세한 내용은 [쿠버네티스 API에 대한 접근 제어](/docs/reference/access-authn-authz/controlling-access/)를 참고하길 바란다. + +이러한 각 단계는 익스텐션 포인트를 제공한다. + +쿠버네티스에는 이를 지원하는 몇 가지 빌트인 인증 방법이 있다. 또한 인증 프록시 뒤에 있을 수 있으며 인증 헤더에서 원격 서비스로 토큰을 전송하여 확인할 수 있다(웹훅). 이러한 방법은 모두 [인증 설명서](/docs/reference/access-authn-authz/authentication/)에 설명되어 있다. + +### 인증 + +[인증](/docs/reference/access-authn-authz/authentication/)은 모든 요청의 헤더 또는 인증서를 요청하는 클라이언트의 사용자 이름에 매핑한다. + +쿠버네티스는 몇 가지 빌트인 인증 방법과 필요에 맞지 않는 경우 [인증 웹훅](/docs/reference/access-authn-authz/authentication/#webhook-token-authentication) 방법을 제공한다. + + +### 인가 + +[인가](/docs/reference/access-authn-authz/webhook/)은 특정 사용자가 API 리소스에서 읽고, 쓰고, 다른 작업을 수행할 수 있는지를 결정한다. 전체 리소스 레벨에서 작동하며 임의의 오브젝트 필드를 기준으로 구별하지 않는다. 빌트인 인증 옵션이 사용자의 요구를 충족시키지 못하면 [인가 웹훅](/docs/reference/access-authn-authz/webhook/)을 통해 사용자가 제공한 코드를 호출하여 인증 결정을 내릴 수 있다. + + +### 동적 어드미션 컨트롤 + +요청이 승인된 후, 쓰기 작업인 경우 [어드미션 컨트롤](/docs/reference/access-authn-authz/admission-controllers/) 단계도 수행된다. 빌트인 단계 외에도 몇 가지 익스텐션이 있다. + +* [이미지 정책 웹훅](/docs/reference/access-authn-authz/admission-controllers/#imagepolicywebhook)은 컨테이너에서 실행할 수 있는 이미지를 제한한다. +* 임의의 어드미션 컨트롤 결정을 내리기 위해 일반적인 [어드미션 웹훅](/docs/reference/access-authn-authz/extensible-admission-controllers/#admission-webhooks)을 사용할 수 있다. 어드미션 웹훅은 생성 또는 업데이트를 거부할 수 있다. + +## 인프라스트럭처 익스텐션 + + +### 스토리지 플러그인 + +[Flex Volumes](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/storage/flexvolume-deployment.md)을 사용하면 +Kubelet이 바이너리 플러그인을 호출하여 볼륨을 마운트하도록 함으로써 +빌트인 지원 없이 볼륨 유형을 마운트 할 수 있다. + + +### 장치 플러그인 + +장치 플러그인은 노드가 [장치 플러그인](/ko/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins/)을 +통해 새로운 노드 리소스(CPU 및 메모리와 같은 빌트인 자원 외에)를 +발견할 수 있게 해준다. + + +### 네트워크 플러그인 + +노드-레벨의 [네트워크 플러그인](/docs/admin/network-plugins/)을 통해 다양한 네트워킹 패브릭을 지원할 수 있다. + +### 스케줄러 익스텐션 + +스케줄러는 파드를 감시하고 파드를 노드에 할당하는 특수한 유형의 +컨트롤러이다. 다른 쿠버네티스 컴포넌트를 계속 사용하면서 +기본 스케줄러를 완전히 교체하거나, +[여러 스케줄러](/docs/tasks/administer-cluster/configure-multiple-schedulers/)를 +동시에 실행할 수 있다. + +이것은 중요한 부분이며, 거의 모든 쿠버네티스 사용자는 스케줄러를 수정할 +필요가 없다는 것을 알게 된다. + +스케줄러는 또한 웹훅 백엔드(스케줄러 익스텐션)가 +파드에 대해 선택된 노드를 필터링하고 우선 순위를 지정할 수 있도록 하는 +[웹훅](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/scheduling/scheduler_extender.md)을 +지원한다. + + + + +## {{% heading "whatsnext" %}} + + +* [커스텀 리소스](/ko/docs/concepts/extend-kubernetes/api-extension/custom-resources/)에 대해 더 알아보기 +* [동적 어드미션 컨트롤](/docs/reference/access-authn-authz/extensible-admission-controllers/)에 대해 알아보기 +* 인프라스트럭처 익스텐션에 대해 더 알아보기 + * [네트워크 플러그인](/ko/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/) + * [장치 플러그인](/ko/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins/) +* [kubectl 플러그인](/ko/docs/tasks/extend-kubectl/kubectl-plugins/)에 대해 알아보기 +* [오퍼레이터 패턴](/ko/docs/concepts/extend-kubernetes/operator/)에 대해 알아보기 diff --git a/content/ko/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation.md b/content/ko/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation.md index 3b0b42dfcc..db2eddb3d1 100644 --- a/content/ko/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation.md +++ b/content/ko/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation.md @@ -27,7 +27,7 @@ Extension-apiserver는 kube-apiserver로 오가는 연결의 레이턴시가 낮 kube-apiserver로 부터의 디스커버리 요청은 왕복 레이턴시가 5초 이내여야 한다. extention API server가 레이턴시 요구 사항을 달성할 수 없는 경우 이를 충족할 수 있도록 변경하는 것을 고려한다. -`EnableAggregatedDiscoveryTimeout=false` [기능 게이트](/docs/reference/command-line-tools-reference/feature-gates/)를 설정해서 타임아웃 +`EnableAggregatedDiscoveryTimeout=false` [기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)를 설정해서 타임아웃 제한을 비활성화 할 수 있다. 이 사용 중단(deprecated)된 기능 게이트는 향후 릴리스에서 제거될 예정이다. @@ -35,9 +35,7 @@ extention API server가 레이턴시 요구 사항을 달성할 수 없는 경 ## {{% heading "whatsnext" %}} -* 사용자의 환경에서 Aggregator를 동작시키려면, [애그리게이션 레이어를 설정한다](/docs/tasks/access-kubernetes-api/configure-aggregation-layer/). -* 다음에, [extension api-server를 구성해서](/docs/tasks/access-kubernetes-api/setup-extension-api-server/) 애그리게이션 레이어와 연계한다. -* 또한, 어떻게 [쿠버네티스 API를 커스텀 리소스 데피니션으로 확장하는지](/docs/tasks/access-kubernetes-api/extend-api-custom-resource-definitions/)를 배워본다. +* 사용자의 환경에서 Aggregator를 동작시키려면, [애그리게이션 레이어를 설정한다](/docs/tasks/extend-kubernetes/configure-aggregation-layer/). +* 다음에, [확장 API 서버를 구성해서](/docs/tasks/extend-kubernetes/setup-extension-api-server/) 애그리게이션 레이어와 연계한다. +* 또한, 어떻게 [쿠버네티스 API를 커스텀 리소스 데피니션으로 확장하는지](/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/)를 배워본다. * [API 서비스](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#apiservice-v1-apiregistration-k8s-io)의 사양을 읽어본다. - - diff --git a/content/ko/docs/concepts/extend-kubernetes/api-extension/custom-resources.md b/content/ko/docs/concepts/extend-kubernetes/api-extension/custom-resources.md index 9e9f3e9e29..159c0fc846 100644 --- a/content/ko/docs/concepts/extend-kubernetes/api-extension/custom-resources.md +++ b/content/ko/docs/concepts/extend-kubernetes/api-extension/custom-resources.md @@ -25,7 +25,7 @@ weight: 10 동적 등록을 통해 실행 중인 클러스터에서 커스텀 리소스가 나타나거나 사라질 수 있으며 클러스터 관리자는 클러스터 자체와 독립적으로 커스텀 리소스를 업데이트 할 수 있다. 커스텀 리소스가 설치되면 사용자는 *파드* 와 같은 빌트인 리소스와 마찬가지로 -[kubectl](/docs/user-guide/kubectl-overview/)을 사용하여 해당 오브젝트를 생성하고 +[kubectl](/ko/docs/reference/kubectl/overview/)을 사용하여 해당 오브젝트를 생성하고 접근할 수 있다. ## 커스텀 컨트롤러 @@ -175,15 +175,15 @@ CRD는 애그리게이트 API보다 생성하기가 쉽다. | 기능 | 설명 | CRD | 애그리게이트 API | | ------- | ----------- | ---- | -------------- | -| 유효성 검사 | 사용자가 오류를 방지하고 클라이언트와 독립적으로 API를 발전시킬 수 있도록 도와준다. 이러한 기능은 동시에 많은 클라이언트를 모두 업데이트할 수 없는 경우에 아주 유용하다. | 예. [OpenAPI v3.0 유효성 검사](/docs/tasks/access-kubernetes-api/extend-api-custom-resource-definitions/#validation)를 사용하여 CRD에서 대부분의 유효성 검사를 지정할 수 있다. [웹훅 유효성 검사](/docs/reference/access-authn-authz/admission-controllers/#validatingadmissionwebhook-alpha-in-1-8-beta-in-1-9)를 추가해서 다른 모든 유효성 검사를 지원한다. | 예, 임의의 유효성 검사를 지원한다. | -| 기본 설정 | 위를 참고하자. | 예, [OpenAPI v3.0 유효성 검사](/docs/tasks/access-kubernetes-api/extend-api-custom-resource-definitions/#defaulting)의 `default` 키워드(1.17에서 GA) 또는 [웹훅 변형(mutating)](/docs/reference/access-authn-authz/admission-controllers/#mutatingadmissionwebhook)(이전 오브젝트의 etcd에서 읽을 때는 실행되지 않음)을 통해 지원한다. | 예 | -| 다중 버전 관리 | 두 가지 API 버전을 통해 동일한 오브젝트를 제공할 수 있다. 필드 이름 바꾸기와 같은 API 변경을 쉽게 할 수 있다. 클라이언트 버전을 제어하는 ​​경우는 덜 중요하다. | [예](/docs/tasks/access-kubernetes-api/custom-resources/custom-resource-definition-versioning) | 예 | +| 유효성 검사 | 사용자가 오류를 방지하고 클라이언트와 독립적으로 API를 발전시킬 수 있도록 도와준다. 이러한 기능은 동시에 많은 클라이언트를 모두 업데이트할 수 없는 경우에 아주 유용하다. | 예. [OpenAPI v3.0 유효성 검사](/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/#validation)를 사용하여 CRD에서 대부분의 유효성 검사를 지정할 수 있다. [웹훅 유효성 검사](/docs/reference/access-authn-authz/admission-controllers/#validatingadmissionwebhook-alpha-in-1-8-beta-in-1-9)를 추가해서 다른 모든 유효성 검사를 지원한다. | 예, 임의의 유효성 검사를 지원한다. | +| 기본 설정 | 위를 참고하자. | 예, [OpenAPI v3.0 유효성 검사](/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/#defaulting)의 `default` 키워드(1.17에서 GA) 또는 [웹훅 변형(mutating)](/docs/reference/access-authn-authz/admission-controllers/#mutatingadmissionwebhook)(이전 오브젝트의 etcd에서 읽을 때는 실행되지 않음)을 통해 지원한다. | 예 | +| 다중 버전 관리 | 두 가지 API 버전을 통해 동일한 오브젝트를 제공할 수 있다. 필드 이름 바꾸기와 같은 API 변경을 쉽게 할 수 있다. 클라이언트 버전을 제어하는 ​​경우는 덜 중요하다. | [예](/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definition-versioning) | 예 | | 사용자 정의 스토리지 | 다른 성능 모드(예를 들어, 키-값 저장소 대신 시계열 데이터베이스)나 보안에 대한 격리(예를 들어, 암호화된 시크릿이나 다른 암호화) 기능을 가진 스토리지가 필요한 경우 | 아니오 | 예 | | 사용자 정의 비즈니스 로직 | 오브젝트를 생성, 읽기, 업데이트 또는 삭제를 할 때 임의의 점검 또는 조치를 수행한다. | 예, [웹훅](/docs/reference/access-authn-authz/extensible-admission-controllers/#admission-webhooks)을 사용한다. | 예 | -| 서브리소스 크기 조정 | HorizontalPodAutoscaler 및 PodDisruptionBudget과 같은 시스템이 새로운 리소스와 상호 작용할 수 있다. | [예](/docs/tasks/access-kubernetes-api/extend-api-custom-resource-definitions/#scale-subresource) | 예 | -| 서브리소스 상태 | 사용자가 스펙 섹션을 작성하고 컨트롤러가 상태 섹션을 작성하는 세분화된 접근 제어를 허용한다. 커스텀 리소스 데이터 변형 시 오브젝트 생성을 증가시킨다(리소스에서 별도의 스펙과 상태 섹션 필요). | [예](/docs/tasks/access-kubernetes-api/extend-api-custom-resource-definitions/#status-subresource) | 예 | +| 서브리소스 크기 조정 | HorizontalPodAutoscaler 및 PodDisruptionBudget과 같은 시스템이 새로운 리소스와 상호 작용할 수 있다. | [예](/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/#scale-subresource) | 예 | +| 서브리소스 상태 | 사용자가 스펙 섹션을 작성하고 컨트롤러가 상태 섹션을 작성하는 세분화된 접근 제어를 허용한다. 커스텀 리소스 데이터 변형 시 오브젝트 생성을 증가시킨다(리소스에서 별도의 스펙과 상태 섹션 필요). | [예](/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/#status-subresource) | 예 | | 기타 서브리소스 | "logs" 또는 "exec"과 같은 CRUD 이외의 작업을 추가한다. | 아니오 | 예 | -| strategic-merge-patch | 새로운 엔드포인트는 `Content-Type: application/strategic-merge-patch+json` 형식의 PATCH를 지원한다. 로컬 및 서버 양쪽에서 수정할 수도 있는 오브젝트를 업데이트하는 데 유용하다. 자세한 내용은 ["kubectl 패치를 사용한 API 오브젝트 업데이트"](/docs/tasks/run-application/update-api-object-kubectl-patch/)를 참고한다. | 아니오 | 예 | +| strategic-merge-patch | 새로운 엔드포인트는 `Content-Type: application/strategic-merge-patch+json` 형식의 PATCH를 지원한다. 로컬 및 서버 양쪽에서 수정할 수도 있는 오브젝트를 업데이트하는 데 유용하다. 자세한 내용은 ["kubectl 패치를 사용한 API 오브젝트 업데이트"](/docs/tasks/manage-kubernetes-objects/update-api-object-kubectl-patch/)를 참고한다. | 아니오 | 예 | | 프로토콜 버퍼 | 새로운 리소스는 프로토콜 버퍼를 사용하려는 클라이언트를 지원한다. | 아니오 | 예 | | OpenAPI 스키마 | 서버에서 동적으로 가져올 수 있는 타입에 대한 OpenAPI(스웨거(swagger)) 스키마가 있는가? 허용된 필드만 설정하여 맞춤법이 틀린 필드 이름으로부터 사용자를 보호하는가? 타입이 적용되는가(즉, `string` 필드에 `int`를 넣지 않는가?) | 예, [OpenAPI v3.0 유효성 검사](/docs/tasks/access-kubernetes-api/extend-api-custom-resource-definitions/#validation)를 기반으로 하는 스키마(1.16에서 GA) | 예 | @@ -234,7 +234,7 @@ CRD는 항상 API 서버의 빌트인 리소스와 동일한 인증, 권한 부 ## 커스텀 리소스에 접근 -쿠버네티스 [클라이언트 라이브러리](/docs/reference/using-api/client-libraries/)를 사용하여 커스텀 리소스에 접근할 수 있다. 모든 클라이언트 라이브러리가 커스텀 리소스를 지원하는 것은 아니다. _Go_ 와 _python_ 클라이언트 라이브러리가 지원한다. +쿠버네티스 [클라이언트 라이브러리](/ko/docs/reference/using-api/client-libraries/)를 사용하여 커스텀 리소스에 접근할 수 있다. 모든 클라이언트 라이브러리가 커스텀 리소스를 지원하는 것은 아니다. _Go_ 와 _python_ 클라이언트 라이브러리가 지원한다. 커스텀 리소스를 추가하면 다음을 사용하여 접근할 수 있다. @@ -250,6 +250,4 @@ CRD는 항상 API 서버의 빌트인 리소스와 동일한 인증, 권한 부 * [애그리게이션 레이어(aggregation layer)로 쿠버네티스 API 확장](/ko/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation/)하는 방법에 대해 배우기. -* [커스텀리소스데피니션으로 쿠버네티스 API 확장](/docs/tasks/access-kubernetes-api/custom-resources/custom-resource-definitions/)하는 방법에 대해 배우기. - - +* [커스텀리소스데피니션으로 쿠버네티스 API 확장](/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/)하는 방법에 대해 배우기. diff --git a/content/ko/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins.md b/content/ko/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins.md index d75601de9f..bfdb7ef8c3 100644 --- a/content/ko/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins.md +++ b/content/ko/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins.md @@ -38,7 +38,7 @@ service Registration { * 유닉스 소켓의 이름. * 빌드된 장치 플러그인 API 버전. * 알리려는 `ResourceName`. 여기서 `ResourceName` 은 - [확장된 리소스 네이밍 체계](/docs/concepts/configuration/manage-compute-resources-container/#extended-resources)를 + [확장된 리소스 네이밍 체계](/ko/docs/concepts/configuration/manage-resources-containers/#확장된-리소스)를 `vendor-domain/resourcetype` 의 형식으로 따라야 한다. (예를 들어, NVIDIA GPU는 `nvidia.com/gpu` 로 알려진다.) @@ -158,7 +158,7 @@ kubelet 인스턴스에 자신을 다시 등록할 것으로 기대된다. 현 장치 플러그인에서 제공하는 리소스를 모니터링하려면, 모니터링 에이전트가 노드에서 사용 중인 장치 셋을 검색하고 메트릭과 연관될 컨테이너를 설명하는 메타데이터를 얻을 수 있어야 한다. 장치 모니터링 에이전트에 의해 노출된 -[프로메테우스(Prometheus)](https://prometheus.io/) 지표는 +[프로메테우스](https://prometheus.io/) 지표는 [쿠버네티스 Instrumentation 가이드라인](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-instrumentation/instrumentation.md)을 따라 `pod`, `namespace` 및 `container` 프로메테우스 레이블을 사용하여 컨테이너를 식별해야 한다. @@ -181,7 +181,7 @@ gRPC 서비스는 `/var/lib/kubelet/pod-resources/kubelet.sock` 의 유닉스 `/var/lib/kubelet/pod-resources` 를 {{< glossary_tooltip text="볼륨" term_id="volume" >}}으로 마운트해야 한다. -"PodResources 서비스"를 지원하려면 `KubeletPodResources` [기능 게이트](/docs/reference/command-line-tools-reference/feature-gates/)를 활성화해야 한다. 쿠버네티스 1.15부터 기본적으로 활성화되어 있다. +"PodResources 서비스"를 지원하려면 `KubeletPodResources` [기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)를 활성화해야 한다. 쿠버네티스 1.15부터 기본적으로 활성화되어 있다. ## 토폴로지 관리자와 장치 플러그인 통합 @@ -222,15 +222,13 @@ pluginapi.Device{ID: "25102017", Health: pluginapi.Healthy, Topology:&pluginapi. * [RDMA 장치 플러그인](https://github.com/hustcat/k8s-rdma-device-plugin) * [Solarflare 장치 플러그인](https://github.com/vikaschoudhary16/sfc-device-plugin) * [SR-IOV 네트워크 장치 플러그인](https://github.com/intel/sriov-network-device-plugin) -* Xilinx FPGA 장치용 [Xilinx FPGA 장치 플러그인](https://github.com/Xilinx/FPGA_as_a_Service/tree/master/k8s-fpga-device-plugin/trunk) +* Xilinx FPGA 장치용 [Xilinx FPGA 장치 플러그인](https://github.com/Xilinx/FPGA_as_a_Service/tree/master/k8s-fpga-device-plugin) ## {{% heading "whatsnext" %}} -* 장치 플러그인을 사용한 [GPU 리소스 스케줄링](/docs/tasks/manage-gpus/scheduling-gpus/)에 대해 알아보기 -* 노드에서의 [확장 리소스 알리기](/docs/tasks/administer-cluster/extended-resource-node/)에 대해 배우기 +* 장치 플러그인을 사용한 [GPU 리소스 스케줄링](/ko/docs/tasks/manage-gpus/scheduling-gpus/)에 대해 알아보기 +* 노드에서의 [확장 리소스 알리기](/ko/docs/tasks/administer-cluster/extended-resource-node/)에 대해 배우기 * 쿠버네티스에서 [TLS 수신에 하드웨어 가속](https://kubernetes.io/blog/2019/04/24/hardware-accelerated-ssl/tls-termination-in-ingress-controllers-using-kubernetes-device-plugins-and-runtimeclass/) 사용에 대해 읽기 * [토폴로지 관리자](/docs/tasks/adminster-cluster/topology-manager/)에 대해 알아보기 - - diff --git a/content/ko/docs/concepts/extend-kubernetes/extend-cluster.md b/content/ko/docs/concepts/extend-kubernetes/extend-cluster.md index ecf57f49fc..543b5cfa48 100644 --- a/content/ko/docs/concepts/extend-kubernetes/extend-cluster.md +++ b/content/ko/docs/concepts/extend-kubernetes/extend-cluster.md @@ -45,7 +45,7 @@ weight: 10 이들 컴포넌트는 쿠버네티스가 새로운 유형과 새로운 종류의 하드웨어를 지원할 수 있게 해준다. 대부분의 클러스터 관리자는 쿠버네티스의 호스팅 또는 배포판 인스턴스를 사용한다. -결과적으로 대부분의 쿠버네티스 사용자는 익스텐션 기능을 설치할 필요가 있고 +결과적으로 대부분의 쿠버네티스 사용자는 익스텐션 기능을 설치할 필요가 없고 새로운 익스텐션 기능을 작성할 필요가 있는 사람은 더 적다. ## 익스텐션 패턴 @@ -70,7 +70,7 @@ weight: 10 *바이너리 플러그인* 모델에서 쿠버네티스는 바이너리(프로그램)를 실행한다. 바이너리 플러그인은 kubelet(예: [Flex Volume 플러그인](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-storage/flexvolume.md)과 -[네트워크 플러그인](/docs/concepts/cluster-administration/network-plugins/))과 +[네트워크 플러그인](/ko/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/))과 kubectl에서 사용한다. @@ -90,7 +90,7 @@ kubectl에서 <!-- image source diagrams: https://docs.google.com/drawings/d/1k2YdJgNTtNfW7_A8moIIkij-DmVgEhNrn3y2OODwqQQ/view --> -1. 사용자는 종종 `kubectl`을 사용하여 쿠버네티스 API와 상호 작용한다. [Kubectl 플러그인](/docs/tasks/extend-kubectl/kubectl-plugins/)은 kubectl 바이너리를 확장한다. 개별 사용자의 로컬 환경에만 영향을 미치므로 사이트 전체 정책을 적용할 수는 없다. +1. 사용자는 종종 `kubectl`을 사용하여 쿠버네티스 API와 상호 작용한다. [Kubectl 플러그인](/ko/docs/tasks/extend-kubectl/kubectl-plugins/)은 kubectl 바이너리를 확장한다. 개별 사용자의 로컬 환경에만 영향을 미치므로 사이트 전체 정책을 적용할 수는 없다. 2. apiserver는 모든 요청을 처리한다. apiserver의 여러 유형의 익스텐션 포인트는 요청을 인증하거나, 콘텐츠를 기반으로 요청을 차단하거나, 콘텐츠를 편집하고, 삭제 처리를 허용한다. 이 내용은 [API 접근 익스텐션](/ko/docs/concepts/extend-kubernetes/extend-cluster/#api-접근-익스텐션) 섹션에 설명되어 있다. 3. apiserver는 다양한 종류의 *리소스* 를 제공한다. `pods`와 같은 *빌트인 리소스 종류* 는 쿠버네티스 프로젝트에 의해 정의되며 변경할 수 없다. 직접 정의한 리소스를 추가할 수도 있고, [커스텀 리소스](/ko/docs/concepts/extend-kubernetes/extend-cluster/#사용자-정의-유형) 섹션에 설명된대로 *커스텀 리소스* 라고 부르는 다른 프로젝트에서 정의한 리소스를 추가할 수도 있다. 커스텀 리소스는 종종 API 접근 익스텐션과 함께 사용된다. 4. 쿠버네티스 스케줄러는 파드를 배치할 노드를 결정한다. 스케줄링을 확장하는 몇 가지 방법이 있다. 이들은 [스케줄러 익스텐션](/ko/docs/concepts/extend-kubernetes/extend-cluster/#스케줄러-익스텐션) 섹션에 설명되어 있다. @@ -164,7 +164,7 @@ Kubelet이 바이너리 플러그인을 호출하여 볼륨을 마운트하도 ### 장치 플러그인 -장치 플러그인은 노드가 [장치 플러그인](/docs/concepts/cluster-administration/device-plugins/)을 +장치 플러그인은 노드가 [장치 플러그인](/ko/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins/)을 통해 새로운 노드 리소스(CPU 및 메모리와 같은 빌트인 자원 외에)를 발견할 수 있게 해준다. @@ -198,9 +198,7 @@ Kubelet이 바이너리 플러그인을 호출하여 볼륨을 마운트하도 * [커스텀 리소스](/ko/docs/concepts/extend-kubernetes/api-extension/custom-resources/)에 대해 더 알아보기 * [동적 어드미션 컨트롤](/docs/reference/access-authn-authz/extensible-admission-controllers/)에 대해 알아보기 * 인프라스트럭처 익스텐션에 대해 더 알아보기 - * [네트워크 플러그인](/docs/concepts/cluster-administration/network-plugins/) - * [장치 플러그인](/docs/concepts/cluster-administration/device-plugins/) -* [kubectl 플러그인](/docs/tasks/extend-kubectl/kubectl-plugins/)에 대해 알아보기 -* [오퍼레이터 패턴](/docs/concepts/extend-kubernetes/operator/)에 대해 알아보기 - - + * [네트워크 플러그인](/ko/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/) + * [장치 플러그인](/ko/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins/) +* [kubectl 플러그인](/ko/docs/tasks/extend-kubectl/kubectl-plugins/)에 대해 알아보기 +* [오퍼레이터 패턴](/ko/docs/concepts/extend-kubernetes/operator/)에 대해 알아보기 diff --git a/content/ko/docs/concepts/overview/_index.md b/content/ko/docs/concepts/overview/_index.md index ae91f70ffd..0b3df10062 100755 --- a/content/ko/docs/concepts/overview/_index.md +++ b/content/ko/docs/concepts/overview/_index.md @@ -1,4 +1,5 @@ --- title: "개요" weight: 20 ---- \ No newline at end of file +description: 쿠버네티스와 그 컴포넌트에 대한 하이-레벨(high-level) 개요를 제공한다. +--- diff --git a/content/ko/docs/concepts/overview/components.md b/content/ko/docs/concepts/overview/components.md index 3d4a8b8370..ace13900c6 100644 --- a/content/ko/docs/concepts/overview/components.md +++ b/content/ko/docs/concepts/overview/components.md @@ -1,8 +1,11 @@ --- title: 쿠버네티스 컴포넌트 content_type: concept +description: > + 쿠버네티스 클러스터는 컴퓨터 집합인 노드 컴포넌트와 컨트롤 플레인 + 컴포넌트로 구성된다. weight: 20 -card: +card: name: concepts weight: 20 --- @@ -56,6 +59,8 @@ card: ### cloud-controller-manager +{{< glossary_definition term_id="cloud-controller-manager" length="short" >}} + cloud-controller-manager는 클라우드 제공자 전용 컨트롤러만 실행한다. 자신의 사내 또는 PC 내부의 학습 환경에서 쿠버네티스를 실행 중인 경우 클러스터에는 클라우드 컨트롤러 매니저가 없다. @@ -94,7 +99,7 @@ kube-controller-manager와 마찬가지로 cloud-controller-manager는 논리적 애드온에 대한 네임스페이스 리소스는 `kube-system` 네임스페이스에 속한다. 선택된 일부 애드온은 아래에 설명하였고, 사용 가능한 전체 확장 애드온 리스트는 -[애드온](/docs/concepts/cluster-administration/addons/)을 참조한다. +[애드온](/ko/docs/concepts/cluster-administration/addons/)을 참조한다. ### DNS @@ -115,7 +120,7 @@ kube-controller-manager와 마찬가지로 cloud-controller-manager는 논리적 ### 클러스터-레벨 로깅 -[클러스터-레벨 로깅](/docs/concepts/cluster-administration/logging/) 메커니즘은 +[클러스터-레벨 로깅](/ko/docs/concepts/cluster-administration/logging/) 메커니즘은 검색/열람 인터페이스와 함께 중앙 로그 저장소에 컨테이너 로그를 저장하는 책임을 진다. @@ -125,4 +130,3 @@ kube-controller-manager와 마찬가지로 cloud-controller-manager는 논리적 * [컨트롤러](/ko/docs/concepts/architecture/controller/)에 대해 더 배우기 * [kube-scheduler](/ko/docs/concepts/scheduling-eviction/kube-scheduler/)에 대해 더 배우기 * etcd의 공식 [문서](https://etcd.io/docs/) 읽기 - diff --git a/content/ko/docs/concepts/overview/kubernetes-api.md b/content/ko/docs/concepts/overview/kubernetes-api.md index aa5d4a043d..26047a8814 100644 --- a/content/ko/docs/concepts/overview/kubernetes-api.md +++ b/content/ko/docs/concepts/overview/kubernetes-api.md @@ -2,6 +2,9 @@ title: 쿠버네티스 API content_type: concept weight: 30 +description: > + 쿠버네티스 API를 사용하면 쿠버네티스 오브젝트들의 상태를 쿼리하고 조작할 수 있다. + 쿠버네티스 컨트롤 플레인의 핵심은 API 서버와 그것이 노출하는 HTTP API이다. 사용자와 클러스터의 다른 부분 및 모든 외부 컴포넌트는 API 서버를 통해 서로 통신한다. card: name: concepts weight: 30 @@ -9,17 +12,15 @@ card: <!-- overview --> -전체 API 관례는 [API conventions doc](https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md)에 기술되어 있다. +쿠버네티스 {{< glossary_tooltip text="컨트롤 플레인" term_id="control-plane" >}}의 핵심은 +{{< glossary_tooltip text="API 서버" term_id="kube-apiserver" >}}이다. API 서버는 +최종 사용자, 클러스터의 다른 부분 그리고 외부 컴포넌트가 서로 통신할 +수 있도록 HTTP API를 제공한다. -API 엔드포인트, 리소스 타입과 샘플은 [API Reference](/docs/reference)에 기술되어 있다. +쿠버네티스 API를 사용하면 쿠버네티스 API 오브젝트(예: +파드(Pod), 네임스페이스(Namespace), 컨피그맵(ConfigMap) 그리고 이벤트(Event))를 질의하고 조작할 수 있다. -API에 원격 접속하는 방법은 [Controlling API Access doc](/docs/reference/access-authn-authz/controlling-access/)에서 논의되었다. - -쿠버네티스 API는 시스템을 위한 선언적 설정 스키마를 위한 기초가 되기도 한다. [kubectl](/ko/docs/reference/kubectl/overview/) 커맨드라인 툴을 사용해서 API 오브젝트를 생성, 업데이트, 삭제 및 조회할 수 있다. - -쿠버네티스는 또한 API 리소스에 대해 직렬화된 상태를 (현재는 [etcd](https://coreos.com/docs/distributed-configuration/getting-started-with-etcd/)에) 저장한다. - -쿠버네티스 자체는 여러 컴포넌트로 나뉘어져서 각각의 API를 통해 상호작용한다. +API 엔드포인트, 리소스 타입과 샘플은 [API Reference](/ko/docs/reference)에 기술되어 있다. @@ -28,54 +29,77 @@ API에 원격 접속하는 방법은 [Controlling API Access doc](/docs/referenc ## API 변경 -경험에 따르면, 성공적인 시스템은 새로운 유스케이스의 등장과 기존 유스케이스의 변경에 맞춰 성장하고 변경될 필요가 있다. 그래서, 쿠버네티스 API가 지속적으로 변경되고 성장하기를 바란다. 그러나, 일정 기간 동안은 현재의 클라이언트와의 호환성을 깨지 않으려고 한다. 일반적으로, 새로운 API 리소스와 새로운 리소스 필드가 주기적으로 추가될 것이다. 리소스나 필드를 없애는 일은 다음의 [API deprecation policy](/docs/reference/using-api/deprecation-policy/)를 따른다. +새로운 유스케이스가 등장하거나 기존 시스템이 변경됨에 따라 성공적인 시스템은 성장하고 변경될 필요가 있다. +따라서, 쿠버네티스는 쿠버네티스 API를 지속적으로 변경하고 성장시킬 수 있는 디자인 기능을 가지고 있다. +쿠버네티스 프로젝트는 기존 클라이언트와의 호환성을 중단하지 _않고_, +다른 프로젝트가 적응할 수 있도록 오랫동안 호환성을 유지하는 것을 목표로 한다. -호환되는 변경에 어떤 내용이 포함되는지, 어떻게 API를 변경하는지에 대한 자세한 내용은 [API change document](https://git.k8s.io/community/contributors/devel/sig-architecture/api_changes.md)에 있다. +일반적으로, 새로운 API 리소스와 새로운 리소스 필드가 주기적으로 추가될 것이다. +리소스나 필드를 없애는 일은 다음의 +[API 사용 중단 정책](/docs/reference/using-api/deprecation-policy/)을 따른다. -## OpenAPI 및 Swagger 정의 +호환되는 변경에 어떤 내용이 포함되는지, 어떻게 API를 변경하는지에 대한 자세한 내용은 +[API 변경](https://git.k8s.io/community/contributors/devel/sig-architecture/api_changes.md#readme)을 참고한다. + +## OpenAPI 명세 {#api-specification} 완전한 API 상세 내용은 [OpenAPI](https://www.openapis.org/)를 활용해서 문서화했다. -쿠버네티스 1.10부터, OpenAPI 규격은 `/openapi/v2` 엔드포인트에서만 제공된다. -요청 형식은 HTTP 헤더에 명시해서 설정할 수 있다. +OpenAPI 규격은 `/openapi/v2` 엔드포인트에서만 제공된다. +다음과 같은 요청 헤더를 사용해서 응답 형식을 요청할 수 있다. -헤더 | 가능한 값 ------- | --------- -Accept | `application/json`, `application/com.github.proto-openapi.spec.v2@v1.0+protobuf` (기본 content-type은 `*/*`에 대해 `application/json`이거나 이 헤더를 전달하지 않음) -Accept-Encoding | `gzip` (이 헤더를 전달하지 않아도 됨) - -1.14 이전 버전에서 형식이 구분된 엔드포인트(`/swagger.json`, `/swagger-2.0.0.json`, `/swagger-2.0.0.pb-v1`, `/swagger-2.0.0.pb-v1.gz`)는 OpenAPI 스펙을 다른 포맷으로 제공한다. -이러한 엔드포인트는 사용이 중단되었으며, 쿠버네티스 1.14에서 제거되었다. - -**OpenAPI 규격을 조회하는 예제** - -1.10 이전 | 쿠버네티스 1.10 이상 ------------ | ----------------------------- -GET /swagger.json | GET /openapi/v2 **Accept**: application/json -GET /swagger-2.0.0.pb-v1 | GET /openapi/v2 **Accept**: application/com.github.proto-openapi.spec.v2@v1.0+protobuf -GET /swagger-2.0.0.pb-v1.gz | GET /openapi/v2 **Accept**: application/com.github.proto-openapi.spec.v2@v1.0+protobuf **Accept-Encoding**: gzip +<table> + <thead> + <tr> + <th>Header</th> + <th style="min-width: 50%;">Possible values</th> + <th>Notes</th> + </tr> + </thead> + <tbody> + <tr> + <td><code>Accept-Encoding</code></td> + <td><code>gzip</code></td> + <td><em>not supplying this header is also acceptable</em></td> + </tr> + <tr> + <td rowspan="3"><code>Accept</code></td> + <td><code>application/com.github.proto-openapi.spec.v2@v1.0+protobuf</code></td> + <td><em>mainly for intra-cluster use</em></td> + </tr> + <tr> + <td><code>application/json</code></td> + <td><em>default</em></td> + </tr> + <tr> + <td><code>*</code></td> + <td><em>serves </em><code>application/json</code></td> + </tr> + </tbody> + <caption>Valid request header values for OpenAPI v2 queries</caption> +</table> 쿠버네티스는 주로 클러스터 내부 통신용 API를 위해 대안적인 Protobuf에 기반한 직렬화 형식을 구현한다. 해당 API는 [design proposal](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/api-machinery/protobuf.md) 문서와 IDL 파일에 문서화되어 있고 각각의 스키마를 담고 있는 IDL 파일은 API 오브젝트를 정의하는 Go 패키지에 들어있다. -1.14 이전 버전에서 쿠버네티스 apiserver는 `/swaggerapi`에서 [Swagger v1.2](http://swagger.io/) -쿠버네티스 API 스펙을 검색하는데 사용할 수 있는 API도 제공한다. -이러한 엔드포인트는 사용이 중단되었으며, 쿠버네티스 1.14에서 제거되었다. - ## API 버전 규칙 필드를 없애거나 리소스 표현을 재구성하기 쉽도록, 쿠버네티스는 `/api/v1`이나 `/apis/extensions/v1beta1`과 같이 각각 다른 API 경로에서 복수의 API 버전을 지원한다. -리소스나 필드 수준보다는 API 수준에서 버전을 선택했는데, API가 명료하고, 시스템 리소스와 행위 관점에서 일관성있으며, 더 이상 사용되지 않는 API나 실험적인 API에 접근을 제어할 수 있도록 하기 위함이다. 스키마 변경에 대해서 JSON과 Protobuf 직렬화 스키마 모두 동일한 가이드라인을 따른다. 다음에 이어지는 설명 모두는 이 두 가지 형식에 모두 해당한다. +버전 관리는 API가 시스템 리소스와 동작에 대해 명확하고 일관된 보기를 +제공하고 수명 종료(end-of-life)와 실험적인 API에 대한 접근을 제어할 수 있도록 +리소스 또는 필드 수준이 아닌 API 수준에서 수행된다. -API 버전 규칙과 소프트웨어 버전 규칙은 간접적으로 연관되어 있음을 알아두자. -[API and release versioning proposal](https://git.k8s.io/community/contributors/design-proposals/release/versioning.md)에는 -API 버전 규칙과 소프트웨어 버전 규칙 간의 관계가 기술되어 있다. +JSON과 Protobuf 직렬화 스키마는 스키마 변경에 대한 동일한 지침을 따르며 아래의 모든 설명은 두 형식을 모두 포함한다. +참고로 API 버전 관리와 소프트웨어 버전 관리는 간접적으로만 연관이 있다. +[쿠버네티스 릴리스 버전 관리](https://git.k8s.io/community/contributors/design-proposals/release/versioning.md) +제안은 API 버전 관리와 소프트웨어 버전 관리 사이의 관계를 설명한다. -API 버전이 다른 경우는 안정성이나 기술 지원의 수준이 다르다는 것을 암시한다. -각각의 수준에 대한 조건은 [API Changes documentation](https://git.k8s.io/community/contributors/devel/sig-architecture/api_changes.md#alpha-beta-and-stable-versions)에서 상세히 다룬다. 요약하자면 다음과 같다. +API 버전이 다른 경우는 안정성이나 기술 지원의 수준이 다르다는 것을 암시한다. 각각의 수준에 대한 조건은 +[API 변경](https://git.k8s.io/community/contributors/devel/sig-architecture/api_changes.md#alpha-beta-and-stable-versions)에서 +상세히 다룬다. 요약하자면 다음과 같다. - 알파(Alpha) 수준: - 버전 이름에 `alpha`가 포함된다. (예: `v1alpha1`) @@ -102,32 +126,35 @@ API 버전이 다른 경우는 안정성이나 기술 지원의 수준이 다르 쿠버네티스 API를 보다 쉽게 확장하기 위해서, [*API 그룹*](https://git.k8s.io/community/contributors/design-proposals/api-machinery/api-group.md)을 구현했다. API 그룹은 REST 경로와 직렬화된 객체의 `apiVersion` 필드에 명시된다. -현재 다양한 API 그룹이 사용되고 있다. +클러스터에 다양한 API 그룹이 있다. -1. *핵심* 그룹 또는 *레거시 그룹* 이라고 하는 그룹은 REST 경로 `/api/v1`에서 `apiVersion: v1`을 사용한다. +1. *레거시* 그룹이라고도 하는 *핵심* 그룹은 REST 경로인 `/api/v1/` 에 있고, `apiVersion: v1`을 사용한다. 1. 이름이 있는 그룹은 REST 경로 `/apis/$GROUP_NAME/$VERSION`에 있으며 `apiVersion: $GROUP_NAME/$VERSION`을 사용한다 - (예: `apiVersion: batch/v1`). 지원되는 API 그룹 전체의 목록은 [Kubernetes API reference](/docs/reference/)에서 확인할 수 있다. + (예: `apiVersion: batch/v1`). 사용 가능한 API 그룹의 전체의 목록은 + [쿠버네티스 API 참조](/ko/docs/reference/)에 있다. -[Custom resources](/docs/concepts/api-extension/custom-resources/)로 API를 확장하는 경우에는 두 종류의 경로가 지원된다. +[사용자 지정 리소스](/ko/docs/concepts/extend-kubernetes/api-extension/custom-resources/)로 API를 확장하는 두 가지 방법이 있다. -1. [CustomResourceDefinition](/docs/tasks/access-kubernetes-api/extend-api-custom-resource-definitions/)은 아주 기본적인 - CRUD 요구를 갖는 사용자에게 적합하다. -1. 쿠버네티스 API 의미론의 전체 셋을 가지고, 사용자만의 apiserver를 만들고자하는 사용자는 - [aggregator](/docs/tasks/access-kubernetes-api/configure-aggregation-layer/)를 사용해서 클라이언트 입장에서 매끄럽게 동작하도록 - 만들 수 있다. +1. [커스텀리소스데피니션(CustomResourceDefinition)](/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/)은 + API 서버가 선택한 리소스 API를 제공하는 방법을 선언적으로 정의할 수 있다. +1. 또한, [자신의 확장 API 서버 구현](/docs/tasks/extend-kubernetes/setup-extension-api-server/)과 + [aggregator](/docs/tasks/extend-kubernetes/configure-aggregation-layer/)를 + 사용해서 클라이언트를 원활하게 만들 수 있다. ## API 그룹 활성화 또는 비활성화하기 -특정 리소스와 API 그룹은 기본적으로 활성화되어 있다. 이들은 apiserver에서 `--runtime-config`를 설정해서 활성화하거나 -비활성화 시킬 수 있다. `--runtime-config`는 쉼표로 분리된 값을 허용한다. 예를 들어서 batch/v1을 비활성화 시키려면 -`--runtime-config=batch/v1=false`와 같이 설정하고, batch/v2alpha1을 활성화 시키려면 `--runtime-config=batch/v2alpha1`을 -설정한다. 이 플래그는 apiserver의 런타임 설정에 쉼표로 분리된 키=값 쌍의 집합을 허용한다. +특정 리소스와 API 그룹은 기본적으로 활성화되어 있다. kube-apiserver에서 커맨드 라인 옵션으로 `--runtime-config` 를 +설정해서 활성화하거나 비활성화할 수 있다. -{{< note >}}그룹이나 리소스를 활성화 또는 비활성화 시키기 위해서는 apiserver와 controller-manager를 재시작해서 -`--runtime-config` 변경을 반영시켜야 한다. {{< /note >}} +`--runtime-config`는 쉼표로 분리된 값을 허용한다. 예를 들어서 batch/v1을 비활성화시키려면, +`--runtime-config=batch/v1=false`와 같이 설정하고, batch/v2alpha1을 활성화시키려면, `--runtime-config=batch/v2alpha1`을 +설정한다. 이 플래그는 API 서버의 런타임 설정에 쉼표로 분리된 키=값 쌍의 집합을 허용한다. + +{{< note >}}그룹이나 리소스를 활성화 또는 비활성화하려면 kube-apiserver와 +controller-manager를 재시작해서 `--runtime-config` 변경 사항을 반영해야 한다. {{< /note >}} ## extensions/v1beta1 그룹 내 특정 리소스 활성화하기 @@ -137,4 +164,19 @@ API 그룹은 REST 경로와 직렬화된 객체의 `apiVersion` 필드에 명 {{< note >}}개별 리소스의 활성화/비활성화는 레거시 문제로 `extensions/v1beta1` API 그룹에서만 지원된다. {{< /note >}} +## 지속성 +쿠버네티스는 API 리소스에 대한 직렬화된 상태를 {{< glossary_tooltip term_id="etcd" >}}에 +기록하고 저장한다. + + +## {{% heading "whatsnext" %}} + +[API 접근 제어하기](/docs/reference/access-authn-authz/controlling-access/)는 클러스터가 +API 접근에 대한 인증과 권한을 관리하는 방법을 설명한다. + +전체 API 규약은 +[API 규약](https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#api-conventions) +문서에 설명되어 있다. + +API 엔드포인트, 리소스 타입과 샘플은 [API 참조](/docs/reference/kubernetes-api/)에 설명되어 있다. diff --git a/content/ko/docs/concepts/overview/what-is-kubernetes.md b/content/ko/docs/concepts/overview/what-is-kubernetes.md index f94ab988a3..ad083dd49d 100644 --- a/content/ko/docs/concepts/overview/what-is-kubernetes.md +++ b/content/ko/docs/concepts/overview/what-is-kubernetes.md @@ -71,7 +71,7 @@ card: ## 쿠버네티스가 아닌 것 -쿠버네티스는 전통적인, 모든 것이 포함된 Platform as a Service(PaaS)가 아니다. 쿠버네티스는 하드웨어 수준보다는 컨테이너 수준에서 운영되기 때문에, PaaS가 일반적으로 제공하는 배포, 스케일링, 로드 밸런싱, 로깅 및 모니터링과 같은 기능에서 공통점이 있기도 하다. 하지만, 쿠버네티스는 모놀리식(monolithic)이 아니어서, 이런 기본 솔루션이 선택적이며 추가나 제거가 용이하다. 쿠버네티스는 개발자 플랫폼을 만드는 구성 요소를 제공하지만, 필요한 경우 사용자의 선택권과 유연성을 지켜준다. +쿠버네티스는 전통적인, 모든 것이 포함된 Platform as a Service(PaaS)가 아니다. 쿠버네티스는 하드웨어 수준보다는 컨테이너 수준에서 운영되기 때문에, PaaS가 일반적으로 제공하는 배포, 스케일링, 로드 밸런싱과 같은 기능을 제공하며, 사용자가 로깅, 모니터링 및 알림 솔루션을 통합할 수 있다. 하지만, 쿠버네티스는 모놀리식(monolithic)이 아니어서, 이런 기본 솔루션이 선택적이며 추가나 제거가 용이하다. 쿠버네티스는 개발자 플랫폼을 만드는 구성 요소를 제공하지만, 필요한 경우 사용자의 선택권과 유연성을 지켜준다. 쿠버네티스는: @@ -89,4 +89,3 @@ card: * [쿠버네티스 구성요소](/ko/docs/concepts/overview/components/) 살펴보기 * [시작하기](/ko/docs/setup/) 준비가 되었는가? - diff --git a/content/ko/docs/concepts/overview/working-with-objects/_index.md b/content/ko/docs/concepts/overview/working-with-objects/_index.md index a27acb856c..26aa4dc83b 100644 --- a/content/ko/docs/concepts/overview/working-with-objects/_index.md +++ b/content/ko/docs/concepts/overview/working-with-objects/_index.md @@ -1,4 +1,7 @@ --- title: "쿠버네티스 오브젝트로 작업하기" weight: 40 +description: > + 쿠버네티스 오브젝트는 쿠버네티스 시스템의 영구 엔티티이다. 쿠버네티스는 이러한 엔티티들을 사용하여 클러스터의 상태를 나타낸다. + 쿠버네티스 오브젝트 모델과 쿠버네티스 오브젝트를 사용하는 방법에 대해 학습한다. --- diff --git a/content/ko/docs/concepts/overview/working-with-objects/annotations.md b/content/ko/docs/concepts/overview/working-with-objects/annotations.md index aa9c29cb64..96db884a4f 100644 --- a/content/ko/docs/concepts/overview/working-with-objects/annotations.md +++ b/content/ko/docs/concepts/overview/working-with-objects/annotations.md @@ -51,13 +51,13 @@ weight: 50 * 경량 롤아웃 도구 메타데이터. 예: 구성 또는 체크포인트 * 책임자의 전화번호 또는 호출기 번호, 또는 팀 웹 사이트 같은 - 해당 정보를 찾을 수 있는 디렉토리 진입점. + 해당 정보를 찾을 수 있는 디렉터리 진입점. * 행동을 수정하거나 비표준 기능을 수행하기 위한 최종 사용자의 지시 사항. 어노테이션을 사용하는 대신, 이 유형의 정보를 -외부 데이터베이스 또는 디렉토리에 저장할 수 있지만, 이는 배포, 관리, 인트로스펙션(introspection) 등을 위한 +외부 데이터베이스 또는 디렉터리에 저장할 수 있지만, 이는 배포, 관리, 인트로스펙션(introspection) 등을 위한 공유 클라이언트 라이브러리와 도구 생성을 훨씬 더 어렵게 만들 수 있다. 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 be7db19bb5..8abdacb09d 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 @@ -8,7 +8,8 @@ kubectl과 대시보드와 같은 많은 도구들로 쿠버네티스 오브젝 공통 레이블 셋은 모든 도구들이 이해할 수 있는 공통의 방식으로 오브젝트를 식별하고 도구들이 상호 운용적으로 작동할 수 있도록 한다. -권장 레이블은 지원 도구 외에도 쿼리하는 방식으로 애플리케이션을 식별하게 한다. +권장 레이블은 지원 도구 외에도 쿼리하는 방식으로 +애플리케이션을 식별하게 한다. <!-- body --> @@ -18,22 +19,23 @@ kubectl과 대시보드와 같은 많은 도구들로 쿠버네티스 오브젝 애플리케이션에 포함된 정의는 유연하다. {{< note >}} -메타데이터들은 권장하는 레이블이다. 애플리케이션을 보다 쉽게 관리할 수 있지만 코어 도구에는 필요하지 않다. +메타데이터들은 권장하는 레이블이다. 애플리케이션을 보다 쉽게 관리할 수 있지만 +코어 도구에는 필요하지 않다. {{< /note >}} 공유 레이블과 주석에는 공통 접두사인 `app.kubernetes.io` 가 있다. 접두사가 없는 레이블은 사용자가 개인적으로 사용할 수 있다. 공유 접두사는 공유 레이블이 사용자 정의 레이블을 방해하지 않도록 한다. - ## 레이블 -레이블을 최대한 활용하려면 모든 리소스 오브젝트에 적용해야 한다. +레이블을 최대한 활용하려면 모든 리소스 오브젝트에 +적용해야 한다. | Key | Description | Example | Type | | ----------------------------------- | --------------------- | -------- | ---- | | `app.kubernetes.io/name` | 애플리케이션 이름 | `mysql` | 문자열 | -| `app.kubernetes.io/instance` | 애플리케이션의 인스턴스를 식별하는 고유한 이름 | `wordpress-abcxzy` | 문자열 | +| `app.kubernetes.io/instance` | 애플리케이션의 인스턴스를 식별하는 고유한 이름 | `mysql-abcxzy` | 문자열 | | `app.kubernetes.io/version` | 애플리케이션의 현재 버전 (예: a semantic version, revision hash 등.) | `5.7.21` | 문자열 | | `app.kubernetes.io/component` | 아키텍처 내 구성요소 | `database` | 문자열 | | `app.kubernetes.io/part-of` | 이 애플리케이션의 전체 이름 | `wordpress` | 문자열 | @@ -47,7 +49,7 @@ kind: StatefulSet metadata: labels: app.kubernetes.io/name: mysql - app.kubernetes.io/instance: wordpress-abcxzy + app.kubernetes.io/instance: mysql-abcxzy app.kubernetes.io/version: "5.7.21" app.kubernetes.io/component: database app.kubernetes.io/part-of: wordpress @@ -56,8 +58,9 @@ metadata: ## 애플리케이션과 애플리케이션 인스턴스 -애플리케이션은 때에 따라 쿠버네티스 클러스터의 동일한 네임스페이스에 한번 또는 그 이상 설치할 수 있다. -예를 들어 워드프레스는 다른 워드프레스가 설치되어있는 웹사이트에 한번 한번 또는 그 이상 설치할 수 있다. +애플리케이션은 때에 따라 쿠버네티스 클러스터의 동일한 네임스페이스에 +한번 또는 그 이상 설치할 수 있다. 예를 들어 워드프레스는 다른 워드프레스가 +설치되어있는 웹사이트에 한번 한번 또는 그 이상 설치할 수 있다. 애플리케이션의 이름과 인스턴스 이름은 별도로 기록된다. 예를 들어 워드프레스는 `app.kubernetes.io/name` 에 `wordpress` 를 가지며 인스턴스 이름으로는 @@ -97,7 +100,8 @@ metadata: ### 데이터베이스가 있는 웹 애플리케이션 -Helm을 이용해서 데이터베이스(MySQL)을 이용하는 웹 애플리케이션(WordPress)을 설치한 것과 같이 좀 더 복잡한 애플리케이션을 고려할 수 있다. +Helm을 이용해서 데이터베이스(MySQL)을 이용하는 웹 애플리케이션(WordPress)을 +설치한 것과 같이 좀 더 복잡한 애플리케이션을 고려할 수 있다. 다음 식별자는 이 애플리케이션을 배포하는데 사용하는 오브젝트의 시작을 보여준다. WordPress를 배포하는데 다음과 같이 `Deployment` 로 시작한다. diff --git a/content/ko/docs/concepts/overview/working-with-objects/field-selectors.md b/content/ko/docs/concepts/overview/working-with-objects/field-selectors.md index 06326befa8..cb16ce9d58 100644 --- a/content/ko/docs/concepts/overview/working-with-objects/field-selectors.md +++ b/content/ko/docs/concepts/overview/working-with-objects/field-selectors.md @@ -9,19 +9,14 @@ _필드 셀렉터_ 는 한 개 이상의 리소스 필드 값에 따라 [쿠버 * `metadata.namespace!=default` * `status.phase=Pending` -다음의 `kubectl` 커맨드는 [`status.phase`](/ko/docs/concepts/workloads/pods/pod-lifecycle/#pod-phase) 필드의 값이 `Running` 인 모든 파드를 선택한다. +다음의 `kubectl` 커맨드는 [`status.phase`](/ko/docs/concepts/workloads/pods/pod-lifecycle/#파드의-단계-phase) 필드의 값이 `Running` 인 모든 파드를 선택한다. ```shell kubectl get pods --field-selector status.phase=Running ``` {{< note >}} -필드 셀렉터는 본질적으로 리소스 *필터* 이다. 기본적으로 적용되는 셀렉터나 필드는 없으며, 이는 명시된 종류의 모든 리소스가 선택된다는 것을 의미한다. 따라서 다음의 `kubectl` 쿼리들은 동일하다. - -```shell -kubectl get pods -kubectl get pods --field-selector "" -``` +필드 셀렉터는 본질적으로 리소스 *필터* 이다. 기본적으로 적용되는 셀렉터나 필드는 없으며, 이는 명시된 종류의 모든 리소스가 선택된다는 것을 의미한다. 여기에 따라오는 `kubectl` 쿼리인 `kubectl get pods` 와 `kubectl get pods --field-selector ""` 는 동일하다. {{< /note >}} ## 사용 가능한 필드 @@ -53,7 +48,7 @@ kubectl get pods --field-selector=status.phase!=Running,spec.restartPolicy=Alway ## 여러 개의 리소스 종류 -필드 셀렉터를 여러 개의 리소스 종류에 걸쳐 사용할 수 있다. 다음의 `kubectl` 커맨드는 `default` 네임스페이스에 속해있지 않은 모든 스테이트풀 셋과 서비스를 선택한다. +필드 셀렉터를 여러 개의 리소스 종류에 걸쳐 사용할 수 있다. 다음의 `kubectl` 커맨드는 `default` 네임스페이스에 속해있지 않은 모든 스테이트풀셋(StatefulSet)과 서비스를 선택한다. ```shell kubectl get statefulsets,services --all-namespaces --field-selector metadata.namespace!=default diff --git a/content/ko/docs/concepts/overview/working-with-objects/kubernetes-objects.md b/content/ko/docs/concepts/overview/working-with-objects/kubernetes-objects.md index 1fe7183c29..73fa4ff4d0 100644 --- a/content/ko/docs/concepts/overview/working-with-objects/kubernetes-objects.md +++ b/content/ko/docs/concepts/overview/working-with-objects/kubernetes-objects.md @@ -44,7 +44,8 @@ spec에 3개의 애플리케이션 레플리카가 동작되도록 설정할 수 있다. 쿠버네티스 시스템은 그 디플로이먼트 spec을 읽어 spec에 일치되도록 상태를 업데이트하여 3개의 의도한 애플리케이션 인스턴스를 구동시킨다. 만약, 그 인스턴스들 중 어느 하나가 -어떤 문제로 인해 멈춘다면(상태 변화 발생), 쿠버네티스 시스템은 보정(이 경우에는 대체 인스턴스를 시작하여)을 통해 +어떤 문제로 인해 멈춘다면(상태 변화 발생), 쿠버네티스 시스템은 보정(이 +경우에는 대체 인스턴스를 시작하여)을 통해 spec과 status간의 차이에 대응한다. 오브젝트 명세, 상태, 그리고 메타데이터에 대한 추가 정보는, [Kubernetes API Conventions](https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md) 를 참조한다. @@ -91,6 +92,5 @@ deployment.apps/nginx-deployment created ## {{% heading "whatsnext" %}} * API 개념의 더 많은 설명은 [Kubernetes API 개요](/ko/docs/reference/using-api/api-overview/)를 본다. -* [파드(Pod)](/ko/docs/concepts/workloads/pods/pod-overview/)와 같이, 가장 중요하고 기본적인 쿠버네티스 오브젝트에 대해 배운다. +* [파드](/ko/docs/concepts/workloads/pods/pod-overview/)와 같이, 가장 중요하고 기본적인 쿠버네티스 오브젝트에 대해 배운다. * 쿠버네티스의 [컨트롤러](/ko/docs/concepts/architecture/controller/)에 대해 배운다. - diff --git a/content/ko/docs/concepts/overview/working-with-objects/labels.md b/content/ko/docs/concepts/overview/working-with-objects/labels.md index fe8b0ce8fb..ed896ce005 100644 --- a/content/ko/docs/concepts/overview/working-with-objects/labels.md +++ b/content/ko/docs/concepts/overview/working-with-objects/labels.md @@ -83,10 +83,11 @@ API는 현재 _일치성 기준_ 과 _집합성 기준_ 이라는 두 종류의 레이블 셀렉터는 쉼표로 구분된 다양한 _요구사항_ 에 따라 만들 수 있다. 다양한 요구사항이 있는 경우 쉼표 기호가 AND(`&&`) 연산자로 구분되는 역할을 하도록 해야 한다. 비어있거나 지정되지 않은 셀렉터는 상황에 따라 달라진다. -셀렉터를 사용하는 API 유형은 유효성과 의미를 문서화해야 한다. +셀렉터를 사용하는 API 유형은 유효성과 의미를 +문서화해야 한다. {{< note >}} -레플리카 셋과 같은 일부 API 유형에서 두 인스턴스의 레이블 셀렉터는 네임스페이스 내에서 겹치지 않아야 한다. 그렇지 않으면 컨트롤러는 상충하는 명령으로 보고, 얼마나 많은 복제본이 필요한지 알 수 없다. +레플리카셋(ReplicaSet)과 같은 일부 API 유형에서 두 인스턴스의 레이블 셀렉터는 네임스페이스 내에서 겹치지 않아야 한다. 그렇지 않으면 컨트롤러는 상충하는 명령으로 보고, 얼마나 많은 복제본이 필요한지 알 수 없다. {{< /note >}} {{< caution >}} diff --git a/content/ko/docs/concepts/overview/working-with-objects/names.md b/content/ko/docs/concepts/overview/working-with-objects/names.md index 0cb3e7656a..891ad4d07a 100644 --- a/content/ko/docs/concepts/overview/working-with-objects/names.md +++ b/content/ko/docs/concepts/overview/working-with-objects/names.md @@ -15,7 +15,6 @@ weight: 20 - <!-- body --> ## 이름 {#names} diff --git a/content/ko/docs/concepts/overview/working-with-objects/namespaces.md b/content/ko/docs/concepts/overview/working-with-objects/namespaces.md index d5eb45f21c..ec4df0668d 100644 --- a/content/ko/docs/concepts/overview/working-with-objects/namespaces.md +++ b/content/ko/docs/concepts/overview/working-with-objects/namespaces.md @@ -27,7 +27,7 @@ weight: 30 네임스페이스는 클러스터 자원을 ([리소스 쿼터](/ko/docs/concepts/policy/resource-quotas/)를 통해) 여러 사용자 사이에서 나누는 방법이다. -이후 버전의 쿠버네티스에서는 같은 네임스페이스의 오브젝트는 기본적으로 +이후 버전의 쿠버네티스에서는 같은 네임스페이스의 오브젝트는 기본적으로 동일한 접근 제어 정책을 갖게 된다. 동일한 소프트웨어의 다른 버전과 같이 약간 다른 리소스를 분리하기 위해 @@ -39,6 +39,10 @@ weight: 30 네임스페이스의 생성과 삭제는 [네임스페이스 관리자 가이드 문서](/docs/tasks/administer-cluster/namespaces/)에 기술되어 있다. +{{< note >}} + 쿠버네티스 시스템 네임스페이스용으로 예약되어 있으므로, `kube-` 접두사로 네임스페이스를 생성하지 않는다. +{{< /note >}} + ### 네임스페이스 조회 사용 중인 클러스터의 현재 네임스페이스를 나열할 수 있다. @@ -54,11 +58,12 @@ kube-public Active 1d kube-system Active 1d ``` -쿠버네티스는 처음에 세 개의 초기 네임스페이스를 갖는다. +쿠버네티스는 처음에 네 개의 초기 네임스페이스를 갖는다. * `default` 다른 네임스페이스가 없는 오브젝트를 위한 기본 네임스페이스 * `kube-system` 쿠버네티스 시스템에서 생성한 오브젝트를 위한 네임스페이스 * `kube-public` 이 네임스페이스는 자동으로 생성되며 모든 사용자(인증되지 않은 사용자 포함)가 읽기 권한으로 접근할 수 있다. 이 네임스페이스는 주로 전체 클러스터 중에 공개적으로 드러나서 읽을 수 있는 리소스를 위해 예약되어 있다. 이 네임스페이스의 공개적인 성격은 단지 관례이지 요구 사항은 아니다. + * `kube-node-lease` 클러스터가 스케일링될 때 노드 하트비트의 성능을 향상시키는 각 노드와 관련된 리스(lease) 오브젝트에 대한 네임스페이스 ### 요청에 네임스페이스 설정하기 @@ -114,6 +119,3 @@ kubectl api-resources --namespaced=false * [신규 네임스페이스 생성](/docs/tasks/administer-cluster/namespaces/#creating-a-new-namespace)에 대해 더 배우기. * [네임스페이스 삭제](/docs/tasks/administer-cluster/namespaces/#deleting-a-namespace)에 대해 더 배우기. - - - diff --git a/content/ko/docs/concepts/overview/working-with-objects/object-management.md b/content/ko/docs/concepts/overview/working-with-objects/object-management.md index 550cbe951c..590116af6f 100644 --- a/content/ko/docs/concepts/overview/working-with-objects/object-management.md +++ b/content/ko/docs/concepts/overview/working-with-objects/object-management.md @@ -7,7 +7,7 @@ weight: 15 <!-- overview --> `kubectl` 커맨드라인 툴은 쿠버네티스 오브젝트를 생성하고 관리하기 위한 몇 가지 상이한 방법을 지원한다. 이 문서는 여러가지 접근법에 대한 개요을 -제공한다. Kubectl로 오브젝트 관리하기에 대한 자세한 설명은 +제공한다. Kubectl로 오브젝트 관리하기에 대한 자세한 설명은 [Kubectl 서적](https://kubectl.docs.kubernetes.io)에서 확인한다. @@ -40,12 +40,6 @@ weight: 15 디플로이먼트 오브젝트를 생성하기 위해 nginx 컨테이너의 인스턴스를 구동시킨다. -```sh -kubectl run nginx --image nginx -``` - -다른 문법을 이용하여 동일한 작업을 수행한다. - ```sh kubectl create deployment nginx --image nginx ``` @@ -75,11 +69,11 @@ kubectl create deployment nginx --image nginx 참고한다. {{< warning >}} -명령형 `replace` 커맨드는 기존 spec을 새로 제공된 spec으로 바꾸고 -구성 파일에서 누락된 오브젝트의 모든 변경 사항을 삭제한다. -이 방법은 spec이 구성 파일과는 별개로 업데이트되는 리소스 유형에는 -사용하지 말아야한다. -예를 들어 `LoadBalancer` 유형의 서비스는 클러스터의 구성과 별도로 +명령형 `replace` 커맨드는 기존 spec을 새로 제공된 spec으로 바꾸고 +구성 파일에서 누락된 오브젝트의 모든 변경 사항을 삭제한다. +이 방법은 spec이 구성 파일과는 별개로 업데이트되는 리소스 유형에는 +사용하지 말아야한다. +예를 들어 `LoadBalancer` 유형의 서비스는 클러스터의 구성과 별도로 `externalIPs` 필드가 업데이트된다. {{< /warning >}} @@ -124,29 +118,28 @@ kubectl replace -f nginx.yaml 선언형 오브젝트 구성에 비해 단점은 다음과 같다. -- 명령형 오브젝트 구성은 디렉토리가 아닌, 파일에 대해 가장 효과가 있다. +- 명령형 오브젝트 구성은 디렉터리가 아닌, 파일에 대해 가장 효과가 있다. - 활성 오브젝트에 대한 업데이트는 구성 파일에 반영되어야 한다. 그렇지 않으면 다음 교체 중에 손실된다. - ## 선언형 오브젝트 구성 선언형 오브젝트 구성을 사용할 경우, 사용자는 로컬에 보관된 오브젝트 구성 파일을 대상으로 작동시키지만, 사용자는 파일에서 수행 할 작업을 정의하지 않는다. 생성, 업데이트, 그리고 삭제 작업은 `kubectl`에 의해 오브젝트 마다 자동으로 감지된다. 이를 통해 다른 오브젝트에 대해 -다른 조작이 필요할 수 있는 디렉토리에서 작업할 수 있다. +다른 조작이 필요할 수 있는 디렉터리에서 작업할 수 있다. {{< note >}} -선언형 오브젝트 구성은 변경 사항이 오브젝트 구성 파일에 -다시 병합되지 않더라도 다른 작성자가 작성한 변경 사항을 유지한다. +선언형 오브젝트 구성은 변경 사항이 오브젝트 구성 파일에 +다시 병합되지 않더라도 다른 작성자가 작성한 변경 사항을 유지한다. 이것은 전체 오브젝트 구성 변경을 위한 `replace` API를 -사용하는 대신, `patch` API를 사용하여 인지되는 차이만 +사용하는 대신, `patch` API를 사용하여 인지되는 차이만 작성하기 때문에 가능하다. {{< /note >}} ### 예시 -`configs` 디렉토리 내 모든 오브젝트 구성 파일을 처리하고 활성 오브젝트를 +`configs` 디렉터리 내 모든 오브젝트 구성 파일을 처리하고 활성 오브젝트를 생성 또는 패치한다. 먼저 어떠한 변경이 이루어지게 될지 알아보기 위해 `diff` 하고 나서 적용할 수 있다. @@ -155,7 +148,7 @@ kubectl diff -f configs/ kubectl apply -f configs/ ``` -재귀적으로 디렉토리를 처리한다. +재귀적으로 디렉터리를 처리한다. ```sh kubectl diff -R -f configs/ @@ -167,7 +160,7 @@ kubectl apply -R -f configs/ 명령형 오브젝트 구성에 비해 장점은 다음과 같다. - 활성 오브젝트에 직접 작성된 변경 사항은 구성 파일로 다시 병합되지 않더라도 유지된다. -- 선언형 오브젝트 구성은 디렉토리에서의 작업 및 오브젝트 별 작업 유형(생성, 패치, 삭제)의 자동 감지에 더 나은 지원을 제공한다. +- 선언형 오브젝트 구성은 디렉터리에서의 작업 및 오브젝트 별 작업 유형(생성, 패치, 삭제)의 자동 감지에 더 나은 지원을 제공한다. 명령형 오브젝트 구성에 비해 단점은 다음과 같다. @@ -178,6 +171,7 @@ kubectl apply -R -f configs/ ## {{% heading "whatsnext" %}} + - [명령형 커맨드를 이용한 쿠버네티스 오브젝트 관리하기](/ko/docs/tasks/manage-kubernetes-objects/imperative-command/) - [오브젝트 구성을 이용한 쿠버네티스 오브젝트 관리하기(명령형)](/ko/docs/tasks/manage-kubernetes-objects/imperative-config/) - [오브젝트 구성을 이용한 쿠버네티스 오브젝트 관리하기(선언형)](/ko/docs/tasks/manage-kubernetes-objects/declarative-config/) @@ -185,7 +179,3 @@ kubectl apply -R -f configs/ - [Kubectl 커맨드 참조](/docs/reference/generated/kubectl/kubectl-commands/) - [Kubectl 서적](https://kubectl.docs.kubernetes.io) - [쿠버네티스 API 참조](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/) - -{{< comment >}} -{{< /comment >}} - diff --git a/content/ko/docs/concepts/policy/_index.md b/content/ko/docs/concepts/policy/_index.md index ae03c565c1..425e725037 100644 --- a/content/ko/docs/concepts/policy/_index.md +++ b/content/ko/docs/concepts/policy/_index.md @@ -1,4 +1,6 @@ --- title: "정책" weight: 90 +description: > + 리소스의 그룹에 적용되도록 구성할 수 있는 정책 --- diff --git a/content/ko/docs/concepts/policy/limit-range.md b/content/ko/docs/concepts/policy/limit-range.md index e2bd0a10d3..84656375c0 100644 --- a/content/ko/docs/concepts/policy/limit-range.md +++ b/content/ko/docs/concepts/policy/limit-range.md @@ -24,11 +24,13 @@ _리밋레인지_ 는 다음과 같은 제약 조건을 제공한다. ## 리밋레인지 활성화 -많은 쿠버네티스 배포판에 리밋레인지 지원이 기본적으로 활성화되어 있다. apiserver `--enable-admission-plugins=` 플래그의 인수 중 하나로 `LimitRanger` 어드미션 컨트롤러가 있는 경우 활성화된다. +쿠버네티스 1.10 버전부터 리밋레인지 지원이 기본적으로 활성화되었다. -해당 네임스페이스에 리밋레인지 오브젝트가 있는 경우 특정 네임스페이스에 리밋레인지가 지정된다. +해당 네임스페이스에 리밋레인지 오브젝트가 있는 경우 +특정 네임스페이스에 리밋레인지가 지정된다. -리밋레인지 오브젝트의 이름은 유효한 [DNS 서브도메인 이름](/ko/docs/concepts/overview/working-with-objects/names/#dns-서브도메인-이름)이어야한다. +리밋레인지 오브젝트의 이름은 유효한 +[DNS 서브도메인 이름](/ko/docs/concepts/overview/working-with-objects/names/#dns-서브도메인-이름)이어야 한다. ### 리밋 레인지 개요 @@ -36,7 +38,8 @@ _리밋레인지_ 는 다음과 같은 제약 조건을 제공한다. - 사용자는 네임스페이스에서 파드, 컨테이너 및 퍼시스턴트볼륨클레임과 같은 리소스를 생성한다. - `LimitRanger` 어드미션 컨트롤러는 컴퓨팅 리소스 요청 사항을 설정하지 않은 모든 파드와 컨테이너에 대한 기본값과 제한을 지정하고 네임스페이스의 리밋레인지에 정의된 리소스의 최소, 최대 및 비율을 초과하지 않도록 사용량을 추적한다. - 리밋레인지 제약 조건을 위반하는 리소스(파드, 컨테이너, 퍼시스턴트볼륨클레임)를 생성하거나 업데이트하는 경우 HTTP 상태 코드 `403 FORBIDDEN` 및 위반된 제약 조건을 설명하는 메시지와 함께 API 서버에 대한 요청이 실패한다. -- `cpu`, `memory`와 같은 컴퓨팅 리소스의 네임스페이스에서 리밋레인지가 활성화된 경우 사용자는 해당 값에 대한 요청 또는 제한을 지정해야 한다. 그렇지 않으면 시스템에서 파드 생성이 거부될 수 있다. +- `cpu`, `memory`와 같은 컴퓨팅 리소스의 네임스페이스에서 리밋레인지가 활성화된 경우 사용자는 해당 값에 + 대한 요청 또는 제한을 지정해야 한다. 그렇지 않으면 시스템에서 파드 생성이 거부될 수 있다. - 리밋레인지 유효성 검사는 파드 실행 단계가 아닌 파드 어드미션 단계에서만 발생한다. 리밋 레인지를 사용하여 생성할 수 있는 정책의 예는 다음과 같다. @@ -58,12 +61,11 @@ _리밋레인지_ 는 다음과 같은 제약 조건을 제공한다. 제한의 사용에 대한 예시는 다음을 참조한다. -- [네임스페이스당 최소 및 최대 CPU 제약 조건을 설정하는 방법](/docs/tasks/administer-cluster/manage-resources/cpu-constraint-namespace/). -- [네임스페이스당 최소 및 최대 메모리 제약 조건을 설정하는 방법](/docs/tasks/administer-cluster/manage-resources/memory-constraint-namespace/). -- [네임스페이스당 기본 CPU 요청과 제한을 설정하는 방법](/docs/tasks/administer-cluster/manage-resources/cpu-default-namespace/). -- [네임스페이스당 기본 메모리 요청과 제한을 설정하는 방법](/docs/tasks/administer-cluster/manage-resources/memory-default-namespace/). +- [네임스페이스당 최소 및 최대 CPU 제약 조건을 설정하는 방법](/ko/docs/tasks/administer-cluster/manage-resources/cpu-constraint-namespace/). +- [네임스페이스당 최소 및 최대 메모리 제약 조건을 설정하는 방법](/ko/docs/tasks/administer-cluster/manage-resources/memory-constraint-namespace/). +- [네임스페이스당 기본 CPU 요청과 제한을 설정하는 방법](/ko/docs/tasks/administer-cluster/manage-resources/cpu-default-namespace/). +- [네임스페이스당 기본 메모리 요청과 제한을 설정하는 방법](/ko/docs/tasks/administer-cluster/manage-resources/memory-default-namespace/). - [네임스페이스당 최소 및 최대 스토리지 사용량을 설정하는 방법](/docs/tasks/administer-cluster/limit-storage-consumption/#limitrange-to-limit-requests-for-storage). -- [네임스페이스당 할당량을 설정하는 자세한 예시](/docs/tasks/administer-cluster/quota-memory-cpu-namespace/). - +- [네임스페이스당 할당량을 설정하는 자세한 예시](/ko/docs/tasks/administer-cluster/manage-resources/quota-memory-cpu-namespace/). diff --git a/content/ko/docs/concepts/policy/pod-security-policy.md b/content/ko/docs/concepts/policy/pod-security-policy.md index 57a115fc69..c0ccaea504 100644 --- a/content/ko/docs/concepts/policy/pod-security-policy.md +++ b/content/ko/docs/concepts/policy/pod-security-policy.md @@ -31,7 +31,7 @@ _Pod Security Policy_ 는 파드 명세의 보안 관련 측면을 제어하는 | 호스트 네트워킹과 포트의 사용 | [`hostNetwork`, `hostPorts`](#호스트-네임스페이스) | | 볼륨 유형의 사용 | [`volumes`](#볼륨-및-파일시스템) | | 호스트 파일시스템의 사용 | [`allowedHostPaths`](#볼륨-및-파일시스템) | -| FlexVolume 드라이버의 화이트리스트 | [`allowedFlexVolumes`](#flexvolume-드라이버) | +| 특정 FlexVolume 드라이버의 허용 | [`allowedFlexVolumes`](#flexvolume-드라이버) | | 파드 볼륨을 소유한 FSGroup 할당 | [`fsGroup`](#볼륨-및-파일시스템) | | 읽기 전용 루트 파일시스템 사용 필요 | [`readOnlyRootFilesystem`](#볼륨-및-파일시스템) | | 컨테이너의 사용자 및 그룹 ID | [`runAsUser`, `runAsGroup`, `supplementalGroups`](#사용자-및-그룹) | @@ -299,7 +299,7 @@ kubectl-user delete pod pause 약간 다르게 다시 시도해보자. ```shell -kubectl-user run pause --image=k8s.gcr.io/pause +kubectl-user create deployment pause --image=k8s.gcr.io/pause deployment "pause" created kubectl-user get pods @@ -398,13 +398,13 @@ podsecuritypolicy "example" deleted 동일한 노드에 있는 다른 파드의 네트워크 활동을 스누핑(snoop)하는 데 사용할 수 있다. -**HostPorts** - 호스트 네트워크 네임스페이스에 허용되는 포트 범위의 화이트리스트(whitelist)를 +**HostPorts** - 호스트 네트워크 네임스페이스에 허용되는 포트 범위의 목록을 제공한다. `min`과 `max`를 포함하여 `HostPortRange`의 목록으로 정의된다. 기본값은 허용하는 호스트 포트 없음(no allowed host ports)이다. ### 볼륨 및 파일시스템 -**Volumes** - 허용되는 볼륨 유형의 화이트리스트를 제공한다. 허용 가능한 값은 +**Volumes** - 허용되는 볼륨 유형의 목록을 제공한다. 허용 가능한 값은 볼륨을 생성할 때 정의된 볼륨 소스에 따른다. 볼륨 유형의 전체 목록은 [볼륨 유형들](/ko/docs/concepts/storage/volumes/#볼륨-유형들)에서 참고한다. 또한 `*`를 사용하여 모든 볼륨 유형을 @@ -435,7 +435,7 @@ podsecuritypolicy "example" deleted 유효성을 검사한다. - *RunAsAny* - 기본값은 제공되지 않는다. 어떠한 `fsGroup` ID의 지정도 허용한다. -**AllowedHostPaths** - hostPath 볼륨에서 사용할 수 있는 호스트 경로의 화이트리스트를 +**AllowedHostPaths** - hostPath 볼륨에서 사용할 수 있는 호스트 경로의 목록을 지정한다. 빈 목록은 사용되는 호스트 경로에 제한이 없음을 의미한다. 이는 단일 `pathPrefix` 필드가 있는 오브젝트 목록으로 정의되며, hostPath 볼륨은 허용된 접두사로 시작하는 경로를 마운트할 수 있으며 `readOnly` 필드는 @@ -455,7 +455,7 @@ allowedHostPaths: (다른 컨테이너들에 있는 데이터를 읽고, 시스템 서비스의 자격 증명을 어뷰징(abusing)하는 등)할 수 있도록 만드는 다양한 방법이 있다. 예를 들면, Kubelet과 같다. -쓰기 가능한 hostPath 디렉토리 볼륨을 사용하면, 컨테이너가 `pathPrefix` 외부의 +쓰기 가능한 hostPath 디렉터리 볼륨을 사용하면, 컨테이너가 `pathPrefix` 외부의 호스트 파일시스템에 대한 통행을 허용하는 방식으로 컨테이너의 파일시스템 쓰기(write)를 허용한다. 쿠버네티스 1.11 이상 버전에서 사용 가능한 `readOnly: true`는 지정된 `pathPrefix`에 대한 접근을 효과적으로 제한하기 위해 **모든** `allowedHostPaths`에서 사용해야 한다. @@ -466,7 +466,7 @@ allowedHostPaths: ### FlexVolume 드라이버 -flexvolume에서 사용할 수 있는 FlexVolume 드라이버의 화이트리스트를 지정한다. +flexvolume에서 사용할 수 있는 FlexVolume 드라이버의 목록을 지정한다. 빈 목록 또는 nil은 드라이버에 제한이 없음을 의미한다. [`volumes`](#볼륨-및-파일시스템) 필드에 `flexVolume` 볼륨 유형이 포함되어 있는지 확인한다. 그렇지 않으면 FlexVolume 드라이버가 허용되지 않는다. @@ -552,7 +552,7 @@ spec: 다음 필드는 대문자로 표기된 기능 이름 목록을 `CAP_` 접두사 없이 가져온다. -**AllowedCapabilities** - 컨테이너에 추가될 수 있는 기능의 화이트리스트를 +**AllowedCapabilities** - 컨테이너에 추가될 수 있는 기능의 목록을 제공한다. 기본적인 기능 셋은 암시적으로 허용된다. 비어있는 셋은 기본 셋을 넘어서는 추가 기능이 추가되지 않는 것을 의미한다. `*`는 모든 기능을 허용하는 데 사용할 수 있다. @@ -576,7 +576,7 @@ spec: ### AllowedProcMountTypes -`allowedProcMountTypes`는 허용된 ProcMountTypes의 화이트리스트이다. +`allowedProcMountTypes`는 허용된 ProcMountTypes의 목록이다. 비어 있거나 nil은 `DefaultProcMountType`만 사용할 수 있음을 나타낸다. `DefaultProcMount`는 /proc의 읽기 전용 및 마스킹(masking)된 경로에 컨테이너 런타임 @@ -592,7 +592,7 @@ spec: ### AppArmor 파드시큐리티폴리시의 어노테이션을 통해 제어된다. [AppArmor -문서](/docs/tutorials/clusters/apparmor/#podsecuritypolicy-annotations)를 참고하길 바란다. +문서](/ko/docs/tutorials/clusters/apparmor/#podsecuritypolicy-annotations)를 참고하길 바란다. ### Seccomp @@ -636,5 +636,3 @@ spec: 폴리시 권장 사항에 대해서는 [파드 보안 표준](/docs/concepts/security/pod-security-standards/)을 참조한다. API 세부 정보는 [파드 시큐리티 폴리시 레퍼런스](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podsecuritypolicy-v1beta1-policy) 참조한다. - - diff --git a/content/ko/docs/concepts/policy/resource-quotas.md b/content/ko/docs/concepts/policy/resource-quotas.md index 4aec897572..ca1af3adc2 100644 --- a/content/ko/docs/concepts/policy/resource-quotas.md +++ b/content/ko/docs/concepts/policy/resource-quotas.md @@ -33,7 +33,7 @@ weight: 10 - `cpu`, `memory`와 같은 컴퓨트 리소스에 대해 네임스페이스에서 쿼터가 활성화된 경우 사용자는 해당값에 대한 요청 또는 제한을 지정해야 한다. 그렇지 않으면 쿼터 시스템이 파드 생성을 거부할 수 있다. 힌트: 컴퓨트 리소스 요구 사항이 없는 파드를 기본값으로 설정하려면 `LimitRanger` 어드미션 컨트롤러를 사용하자. - 이 문제를 회피하는 방법에 대한 예제는 [연습](/docs/tasks/administer-cluster/quota-memory-cpu-namespace/)을 참고하길 바란다. + 이 문제를 회피하는 방법에 대한 예제는 [연습](/ko/docs/tasks/administer-cluster/manage-resources/quota-memory-cpu-namespace/)을 참고하길 바란다. `ResourceQuota` 오브젝트의 이름은 유효한 [DNS 서브도메인 이름](/ko/docs/concepts/overview/working-with-objects/names#dns-서브도메인-이름)이어야 한다. @@ -56,7 +56,8 @@ weight: 10 API 서버 `--enable-admission-plugins=` 플래그의 인수 중 하나로 `ResourceQuota`가 있는 경우 활성화된다. -해당 네임스페이스에 `ResourceQuota`가 있는 경우 특정 네임스페이스에 리소스 쿼터가 적용된다. +해당 네임스페이스에 `ResourceQuota`가 있는 경우 특정 네임스페이스에 +리소스 쿼터가 적용된다. ## 컴퓨트 리소스 쿼터 @@ -74,7 +75,7 @@ API 서버 `--enable-admission-plugins=` 플래그의 인수 중 하나로 ### 확장된 리소스에 대한 리소스 쿼터 위에서 언급한 리소스 외에도 릴리스 1.10에서는 -[확장된 리소스](/docs/concepts/configuration/manage-compute-resources-container/#extended-resources)에 대한 쿼터 지원이 추가되었다. +[확장된 리소스](/ko/docs/concepts/configuration/manage-resources-containers/#확장된-리소스)에 대한 쿼터 지원이 추가되었다. 확장된 리소스에는 오버커밋(overcommit)이 허용되지 않으므로 하나의 쿼터에서 동일한 확장된 리소스에 대한 `requests`와 `limits`을 모두 지정하는 것은 의미가 없다. 따라서 확장된 @@ -160,9 +161,10 @@ GPU 리소스를 다음과 같이 쿼터를 정의할 수 있다. | `services.nodeports` | 네임스페이스에 존재할 수 있는 노드 포트 유형의 총 서비스 수 | | `secrets` | 네임스페이스에 존재할 수 있는 총 시크릿 수 | -예를 들어, `pods` 쿼터는 터미널이 아닌 단일 네임스페이스에서 생성된 `pods` 수를 계산하고 최대값을 적용한다. -사용자가 작은 파드를 많이 생성하여 클러스터의 파드 IP 공급이 고갈되는 경우를 피하기 위해 -네임스페이스에 `pods` 쿼터를 설정할 수 있다. +예를 들어, `pods` 쿼터는 터미널이 아닌 단일 네임스페이스에서 생성된 `pods` 수를 +계산하고 최댓값을 적용한다. 사용자가 작은 파드를 많이 생성하여 클러스터의 파드 IP +공급이 고갈되는 경우를 피하기 위해 네임스페이스에 +`pods` 쿼터를 설정할 수 있다. ## 쿼터 범위 @@ -195,7 +197,7 @@ GPU 리소스를 다음과 같이 쿼터를 정의할 수 있다. {{< feature-state for_k8s_version="v1.12" state="beta" >}} -특정 [우선 순위](/docs/concepts/configuration/pod-priority-preemption/#pod-priority)로 파드를 생성할 수 있다. +특정 [우선 순위](/ko/docs/concepts/configuration/pod-priority-preemption/#파드-우선순위)로 파드를 생성할 수 있다. 쿼터 스펙의 `scopeSelector` 필드를 사용하여 파드의 우선 순위에 따라 파드의 시스템 리소스 사용을 제어할 수 있다. @@ -598,5 +600,3 @@ plugins: 자세한 내용은 [리소스쿼터 디자인 문서](https://git.k8s.io/community/contributors/design-proposals/resource-management/admission_control_resource_quota.md)를 참고하길 바란다. - - diff --git a/content/ko/docs/concepts/scheduling-eviction/_index.md b/content/ko/docs/concepts/scheduling-eviction/_index.md index d368e230d7..5cd57c3a29 100644 --- a/content/ko/docs/concepts/scheduling-eviction/_index.md +++ b/content/ko/docs/concepts/scheduling-eviction/_index.md @@ -1,4 +1,7 @@ --- title: "스케줄링과 축출(eviction)" weight: 90 +description: > + 쿠버네티스에서, 스케줄링은 kubelet이 파드를 실행할 수 있도록 파드가 노드와 일치하는지 확인하는 것을 말한다. + 축출은 리소스가 부족한 노드에서 하나 이상의 파드를 사전에 장애로 처리하는 프로세스이다. --- diff --git a/content/ko/docs/concepts/scheduling-eviction/assign-pod-node.md b/content/ko/docs/concepts/scheduling-eviction/assign-pod-node.md index a56dece692..4694533315 100644 --- a/content/ko/docs/concepts/scheduling-eviction/assign-pod-node.md +++ b/content/ko/docs/concepts/scheduling-eviction/assign-pod-node.md @@ -151,7 +151,7 @@ spec: 예시에서 연산자 `In` 이 사용되고 있는 것을 볼 수 있다. 새로운 노드 어피니티 구문은 다음의 연산자들을 지원한다. `In`, `NotIn`, `Exists`, `DoesNotExist`, `Gt`, `Lt`. `NotIn` 과 `DoesNotExist` 를 사용해서 안티-어피니티를 수행하거나, -특정 노드에서 파드를 쫓아내는 [노드 테인트(taint)](/docs/concepts/configuration/taint-and-toleration/)를 설정할 수 있다. +특정 노드에서 파드를 쫓아내는 [노드 테인트(taint)](/ko/docs/concepts/scheduling-eviction/taint-and-toleration/)를 설정할 수 있다. `nodeSelector` 와 `nodeAffinity` 를 모두 지정한다면 파드가 후보 노드에 스케줄 되기 위해서는 *둘 다* 반드시 만족해야 한다. @@ -206,13 +206,11 @@ spec: `preferredDuringSchedulingIgnoredDuringExecution` 이다. 파드 어피니티 규칙에 의하면 키 "security" 와 값 "S1"인 레이블이 있는 하나 이상의 이미 실행 중인 파드와 동일한 영역에 있는 경우에만 파드를 노드에 스케줄할 수 있다. (보다 정확하게는, 클러스터에 키 "security"와 값 "S1"인 레이블을 가지고 있는 실행 중인 파드가 있는 키 -`failure-domain.beta.kubernetes.io/zone` 와 값 V인 노드가 최소 하나 이상 있고, 노드 N이 키 -`failure-domain.beta.kubernetes.io/zone` 와 일부 값이 V인 레이블을 가진다면 파드는 노드 N에서 실행할 수 있다.) -파드 안티-어피니티 규칙에 의하면 노드가 이미 키 "security"와 값 "S2"인 레이블을 가진 파드를 -실행하고 있는 파드는 노드에 스케줄되는 것을 선호하지 않는다. -(만약 `topologyKey` 가 `failure-domain.beta.kubernetes.io/zone` 라면 노드가 키 -"security"와 값 "S2"를 레이블로 가진 파드와 -동일한 영역에 있는 경우, 노드에 파드를 예약할 수 없음을 의미한다.) +`failure-domain.beta.kubernetes.io/zone` 와 값 V인 노드가 최소 하나 이상 있고, +노드 N이 키 `failure-domain.beta.kubernetes.io/zone` 와 +일부 값이 V인 레이블을 가진다면 파드는 노드 N에서 실행할 수 있다.) +파드 안티-어피니티 규칙에 의하면 파드는 키 "security"와 값 "S2"인 레이블을 가진 파드와 +동일한 영역의 노드에 스케줄되지 않는다. [디자인 문서](https://git.k8s.io/community/contributors/design-proposals/scheduling/podaffinity.md)를 통해 `requiredDuringSchedulingIgnoredDuringExecution` 와 `preferredDuringSchedulingIgnoredDuringExecution` 의 파드 어피니티와 안티-어피니티에 대한 많은 예시를 맛볼 수 있다. @@ -222,10 +220,11 @@ spec: 원칙적으로, `topologyKey` 는 적법한 어느 레이블-키도 될 수 있다. 하지만, 성능과 보안상의 이유로 topologyKey에는 몇 가지 제약조건이 있다. -1. 어피니티와 `requiredDuringSchedulingIgnoredDuringExecution` 파드 안티-어피니티는 대해 -`topologyKey` 가 비어있는 것을 허용하지 않는다. -2. `requiredDuringSchedulingIgnoredDuringExecution` 파드 안티-어피니티에서 `topologyKey` 를 `kubernetes.io/hostname` 로 제한하기 위해 어드미션 컨트롤러 `LimitPodHardAntiAffinityTopology` 가 도입되었다. 사용자 지정 토폴로지를에 사용할 수 있도록 하려면, 어드미션 컨트롤러를 수정하거나 간단히 이를 비활성화 할 수 있다. -3. `preferredDuringSchedulingIgnoredDuringExecution` 파드 안티-어피니티는 `topologyKey` 가 비어있는 것을 허용하지 않는다. +1. 파드 어피니티에서 `requiredDuringSchedulingIgnoredDuringExecution` 와 `preferredDuringSchedulingIgnoredDuringExecution` 는 +`topologyKey` 의 빈 값을 허용하지 않는다. +2. 파드 안티-어피니티에서도 `requiredDuringSchedulingIgnoredDuringExecution` 와 `preferredDuringSchedulingIgnoredDuringExecution` 는 +`topologyKey` 의 빈 값을 허용하지 않는다. +3. `requiredDuringSchedulingIgnoredDuringExecution` 파드 안티-어피니티에서 `topologyKey` 를 `kubernetes.io/hostname` 로 제한하기 위해 어드미션 컨트롤러 `LimitPodHardAntiAffinityTopology` 가 도입되었다. 사용자 지정 토폴로지를 사용할 수 있도록 하려면, 어드미션 컨트롤러를 수정하거나 아니면 간단히 이를 비활성화해야 한다. 4. 위의 경우를 제외하고, `topologyKey` 는 적법한 어느 레이블-키도 가능하다. `labelSelector` 와 `topologyKey` 외에도 `labelSelector` 와 일치해야 하는 네임스페이스 목록 `namespaces` 를 @@ -388,7 +387,7 @@ spec: ## {{% heading "whatsnext" %}} -[테인트](/docs/concepts/configuration/taint-and-toleration/)는 노드가 특정 파드들을 *쫓아내게* 할 수 있다. +[테인트](/ko/docs/concepts/scheduling-eviction/taint-and-toleration/)는 노드가 특정 파드들을 *쫓아낼* 수 있다. [노드 어피니티](https://git.k8s.io/community/contributors/design-proposals/scheduling/nodeaffinity.md)와 [파드간 어피니티/안티-어피니티](https://git.k8s.io/community/contributors/design-proposals/scheduling/podaffinity.md)에 대한 디자인 문서에는 @@ -397,5 +396,3 @@ spec: 파드가 노드에 할당되면 kubelet은 파드를 실행하고 노드의 로컬 리소스를 할당한다. [토폴로지 매니저](/docs/tasks/administer-cluster/topology-manager/)는 노드 수준의 리소스 할당 결정에 참여할 수 있다. - - diff --git a/content/ko/docs/concepts/scheduling-eviction/kube-scheduler.md b/content/ko/docs/concepts/scheduling-eviction/kube-scheduler.md index 54373e2e2c..3c0a4c5110 100644 --- a/content/ko/docs/concepts/scheduling-eviction/kube-scheduler.md +++ b/content/ko/docs/concepts/scheduling-eviction/kube-scheduler.md @@ -28,7 +28,7 @@ weight: 10 ## kube-scheduler -[kube-scheduler](https://kubernetes.io/docs/reference/command-line-tools-reference/kube-scheduler/)는 +[kube-scheduler](/docs/reference/command-line-tools-reference/kube-scheduler/)는 쿠버네티스의 기본 스케줄러이며 {{< glossary_tooltip text="컨트롤 플레인" term_id="control-plane" >}}의 일부로 실행된다. kube-scheduler는 원하거나 필요에 따라 자체 스케줄링 컴포넌트를 @@ -89,10 +89,9 @@ _스코어링_ 단계에서 스케줄러는 목록에 남아있는 노드의 순 ## {{% heading "whatsnext" %}} -* [스케줄러 성능 튜닝](/ko/docs/concepts/scheduling/scheduler-perf-tuning/)에 대해 읽기 +* [스케줄러 성능 튜닝](/ko/docs/concepts/scheduling-eviction/scheduler-perf-tuning/)에 대해 읽기 * [파드 토폴로지 분배 제약 조건](/ko/docs/concepts/workloads/pods/pod-topology-spread-constraints/)에 대해 읽기 * kube-scheduler의 [레퍼런스 문서](/docs/reference/command-line-tools-reference/kube-scheduler/) 읽기 * [멀티 스케줄러 구성하기](/docs/tasks/administer-cluster/configure-multiple-schedulers/)에 대해 배우기 * [토폴로지 관리 정책](/docs/tasks/administer-cluster/topology-manager/)에 대해 배우기 -* [파드 오버헤드](/docs/concepts/configuration/pod-overhead/)에 대해 배우기 - +* [파드 오버헤드](/ko/docs/concepts/configuration/pod-overhead/)에 대해 배우기 diff --git a/content/ko/docs/concepts/scheduling-eviction/scheduler-perf-tuning.md b/content/ko/docs/concepts/scheduling-eviction/scheduler-perf-tuning.md index 52db313635..b564eda5fb 100644 --- a/content/ko/docs/concepts/scheduling-eviction/scheduler-perf-tuning.md +++ b/content/ko/docs/concepts/scheduling-eviction/scheduler-perf-tuning.md @@ -8,8 +8,8 @@ weight: 70 {{< feature-state for_k8s_version="1.14" state="beta" >}} -[kube-scheduler](/ko/docs/concepts/scheduling/kube-scheduler/#kube-scheduler) -는 쿠버네티스의 기본 스케줄러이다. 그것은 클러스터의 +[kube-scheduler](/ko/docs/concepts/scheduling-eviction/kube-scheduler/#kube-scheduler)는 +쿠버네티스의 기본 스케줄러이다. 그것은 클러스터의 노드에 파드를 배치하는 역할을 한다. 파드의 스케줄링 요건을 충족하는 @@ -19,7 +19,7 @@ weight: 70 높은 점수를 가진 노드를 선택한다. 이후 스케줄러는 _바인딩_ 이라는 프로세스로 API 서버에 해당 결정을 통지한다. -본 페이지에서는 상대적으로 큰 규모의 쿠버네티스 클러스터에 대한 성능 튜닝 +본 페이지에서는 상대적으로 큰 규모의 쿠버네티스 클러스터에 대한 성능 튜닝 최적화에 대해 설명한다. @@ -45,7 +45,7 @@ kube-scheduler 의 `percentageOfNodesToScore` 설정을 통해 값을 변경하려면, kube-scheduler 구성 파일(이 파일은 `/etc/kubernetes/config/kube-scheduler.yaml` 일 수 있다)을 편집한 다음 스케줄러를 재시작 한다. -이를 변경한 후에 다음을 실행해서 +이를 변경한 후에 다음을 실행해서 ```bash kubectl get componentstatuses ``` @@ -68,7 +68,7 @@ scheduler Healthy ok 정수 값(숫자)로 변환 한다. 스케줄링 중에 kube-scheduler가 구성된 비율을 초과 할만큼 충분히 실행 가능한 노드를 식별한 경우, kube-scheduler는 더 실행 가능한 노드를 찾는 검색을 중지하고 -[스코어링 단계](/ko/docs/concepts/scheduling/kube-scheduler/#kube-scheduler-implementation)를 진행한다. +[스코어링 단계](/ko/docs/concepts/scheduling-eviction/kube-scheduler/#kube-scheduler-implementation)를 진행한다. [스케줄러가 노드 탐색을 반복(iterate)하는 방법](#스케줄러가-노드-탐색을-반복-iterate-하는-방법) 은 이 프로세스를 자세히 설명한다. @@ -101,14 +101,15 @@ algorithmSource: percentageOfNodesToScore: 50 ``` + ### percentageOfNodesToScore 튜닝 -`percentageOfNodesToScore`는 1과 100 사이의 값이어야하며 -기본 값은 클러스터 크기에 따라 계산된다. 또한 50 노드로 하드 코딩된 -최소 값도 있다. +`percentageOfNodesToScore`는 1과 100 사이의 값이어야 하며 +기본값은 클러스터 크기에 따라 계산된다. 또한 50 노드로 하드 코딩된 +최솟값도 있다. -{{< note >}} 클러스터에서 적합한 노드가 50 미만인 경우, 스케줄러는 여전히 -모든 노드를 확인한다. 그 이유는 스케줄러가 탐색을 조기 중단하기에는 적합한 +{{< note >}} 클러스터에서 적합한 노드가 50 미만인 경우, 스케줄러는 여전히 +모든 노드를 확인한다. 그 이유는 스케줄러가 탐색을 조기 중단하기에는 적합한 노드의 수가 충분하지 않기 때문이다. 규모가 작은 클러스터에서는 `percentageOfNodesToScore` 에 낮은 값을 설정하면, @@ -119,10 +120,10 @@ percentageOfNodesToScore: 50 성능이 크게 향상되지 않는다. {{< /note >}} -이 값을 세팅할 때 중요하고 자세한 사항은, 클러스터에서 +이 값을 세팅할 때 중요하고 자세한 사항은, 클러스터에서 적은 수의 노드에 대해서만 적합성을 확인하면, 주어진 파드에 대해서 -일부 노드의 점수는 측정이되지 않는다는 것이다. 결과적으로, 주어진 파드를 실행하는데 -가장 높은 점수를 가질 가능성이 있는 노드가 점수 측정 단계로 조차 넘어가지 +일부 노드의 점수는 측정이되지 않는다는 것이다. 결과적으로, 주어진 파드를 실행하는데 +가장 높은 점수를 가질 가능성이 있는 노드가 점수 측정 단계로 조차 넘어가지 않을 수 있다. 이것은 파드의 이상적인 배치보다 낮은 결과를 초래할 것이다. `percentageOfNodesToScore` 를 매우 낮게 설정해서 kube-scheduler가 @@ -133,19 +134,19 @@ percentageOfNodesToScore: 50 ## 스케줄러가 노드 탐색을 반복(iterate)하는 방법 -이 섹션은 이 특징의 상세한 내부 방식을 이해하고 싶은 사람들을 +이 섹션은 이 특징의 상세한 내부 방식을 이해하고 싶은 사람들을 위해 작성되었다. -클러스터의 모든 노드가 파드 실행 대상으로 고려되어 공정한 기회를 +클러스터의 모든 노드가 파드 실행 대상으로 고려되어 공정한 기회를 가지도록, 스케줄러는 라운드 로빈(round robin) 방식으로 모든 노드에 대해서 탐색을 -반복한다. 모든 노드가 배열에 나열되어 있다고 생각해보자. 스케줄러는 배열의 -시작부터 시작하여 `percentageOfNodesToScore`에 명시된 충분한 수의 노드를 -찾을 때까지 적합성을 확인한다. 그 다음 파드에 대해서는, 스케줄러가 -이전 파드를 위한 노드 적합성 확인이 마무리된 지점인 노드 배열의 마지막 +반복한다. 모든 노드가 배열에 나열되어 있다고 생각해보자. 스케줄러는 배열의 +시작부터 시작하여 `percentageOfNodesToScore`에 명시된 충분한 수의 노드를 +찾을 때까지 적합성을 확인한다. 그 다음 파드에 대해서는, 스케줄러가 +이전 파드를 위한 노드 적합성 확인이 마무리된 지점인 노드 배열의 마지막 포인트부터 확인을 재개한다. -만약 노드들이 다중의 영역(zone)에 있다면, 다른 영역에 있는 노드들이 적합성 -확인의 대상이 되도록 스케줄러는 다양한 영역에 있는 노드에 대해서 +만약 노드들이 다중의 영역(zone)에 있다면, 다른 영역에 있는 노드들이 적합성 +확인의 대상이 되도록 스케줄러는 다양한 영역에 있는 노드에 대해서 탐색을 반복한다. 예제로, 2개의 영역에 있는 6개의 노드를 생각해보자. ``` @@ -160,5 +161,3 @@ percentageOfNodesToScore: 50 ``` 모든 노드를 검토한 후, 노드 1로 돌아간다. - - diff --git a/content/ko/docs/concepts/scheduling-eviction/taint-and-toleration.md b/content/ko/docs/concepts/scheduling-eviction/taint-and-toleration.md index 0d0a192ddd..a72b857d07 100644 --- a/content/ko/docs/concepts/scheduling-eviction/taint-and-toleration.md +++ b/content/ko/docs/concepts/scheduling-eviction/taint-and-toleration.md @@ -6,16 +6,17 @@ weight: 40 <!-- overview --> -[여기](/ko/docs/concepts/configuration/assign-pod-node/#어피니티-affinity-와-안티-어피니티-anti-affinity)에 설명된 노드 어피니티는 -노드 셋을 *끌어들이는* (기본 설정 또는 어려운 요구 사항) -*파드* 속성이다. 테인트는 그 반대로, *노드* 가 파드 셋을 -*제외* 할 수 있다. +[_노드 어피니티_](/ko/docs/concepts/scheduling-eviction/assign-pod-node/#어피니티-affinity-와-안티-어피니티-anti-affinity)는 +{{< glossary_tooltip text="노드" term_id="node" >}} 셋을 +(기본 설정 또는 어려운 요구 사항으로) *끌어들이는* {{< glossary_tooltip text="파드" term_id="pod" >}}의 속성이다. +_테인트_ 는 그 반대로, 노드가 파드 셋을 제외할 수 있다. + +_톨러레이션_ 은 파드에 적용되며, 파드를 일치하는 테인트가 있는 노드에 +스케줄되게 하지만 필수는 아니다. 테인트와 톨러레이션은 함께 작동하여 파드가 부적절한 노드에 스케줄되지 않게 한다. 하나 이상의 테인트가 노드에 적용된다. 이것은 노드가 테인트를 용인하지 않는 파드를 수용해서는 안 되는 것을 나타낸다. -톨러레이션은 파드에 적용되며, 파드를 일치하는 테인트가 있는 노드에 스케줄되게 -하지만 필수는 아니다. @@ -61,13 +62,13 @@ tolerations: {{< codenew file="pods/pod-with-toleration.yaml" >}} +지정하지 않으면 `operator` 의 기본값은 `Equal` 이다. + 톨러레이션은 키가 동일하고 이펙트가 동일한 경우, 테인트와 "일치"한다. 그리고 다음의 경우에도 마찬가지다. * `operator` 가 `Exists` 인 경우(이 경우 `value` 를 지정하지 않아야 함), 또는 * `operator` 는 `Equal` 이고 `value` 는 `value` 로 같다. -지정하지 않으면 `operator` 의 기본값은 `Equal` 이다. - {{< note >}} 두 가지 특별한 경우가 있다. @@ -170,7 +171,7 @@ tolerations: 사용자 정의 [어드미션 컨트롤러](/docs/reference/access-authn-authz/admission-controllers/)를 사용하여 톨러레이션를 적용하는 것이 가장 쉬운 방법이다. 예를 들어, [확장된 -리소스](/docs/concepts/configuration/manage-compute-resources-container/#extended-resources)를 +리소스](/ko/docs/concepts/configuration/manage-resources-containers/#확장된-리소스)를 사용하여 특별한 하드웨어를 나타내고, 확장된 리소스 이름으로 특별한 하드웨어 노드를 테인트시키고 [ExtendedResourceToleration](/docs/reference/access-authn-authz/admission-controllers/#extendedresourcetoleration) @@ -198,8 +199,7 @@ tolerations: * `tolerationSeconds` 가 지정된 테인트를 용인하는 파드는 지정된 시간 동안 바인딩된 상태로 유지된다. -덧붙여, 쿠버네티스 1.6 버전에서는 노드 문제를 나타내는 알파 지원이 -도입되었다. 다시 말해, 특정 조건이 참일 때 노드 컨트롤러는 자동으로 +노드 컨트롤러는 특정 조건이 참일 때 자동으로 노드를 테인트시킨다. 다음은 빌트인 테인트이다. * `node.kubernetes.io/not-ready`: 노드가 준비되지 않았다. 이는 NodeCondition @@ -221,10 +221,9 @@ tolerations: 관련 테인트를 제거할 수 있다. {{< note >}} -노드 문제로 인해 파드 축출의 기존 [비율 제한](/ko/docs/concepts/architecture/nodes/) -동작을 유지하기 위해, 시스템은 실제로 테인트를 비율-제한 방식으로 -추가한다. 이는 마스터가 노드에서 분할되는 등의 시나리오에서 -대규모 파드 축출을 방지한다. +콘트롤 플레인은 노드에 새 테인트를 추가하는 비율을 제한한다. +이 비율-제한은 많은 노드가 동시에 도달할 수 없을 때(예를 들어, 네트워크 중단으로) +트리거될 축출 개수를 관리한다. {{< /note >}} 이 기능을 `tolerationSeconds` 와 함께 사용하면, 파드에서 @@ -243,20 +242,15 @@ tolerations: tolerationSeconds: 6000 ``` -쿠버네티스는 사용자가 제공한 파드 구성에 이미 추가된 -`node.kubernetes.io/not-ready` 에 대한 톨러레이션이 없는 경우 -`tolerationSeconds=300` 으로 `node.kubernetes.io/not-ready` 에 대한 -톨러레이션을 자동으로 추가한다. -마찬가지로 사용자가 제공한 파드 구성에 이미 추가된 -`node.kubernetes.io/unreachable` 에 대한 톨러레이션이 없는 경우 -`tolerationSeconds=300` 으로 `node.kubernetes.io/unreachable` 에 대한 +{{< note >}} +쿠버네티스는 사용자나 컨트롤러에서 명시적으로 설정하지 않았다면, 자동으로 +`node.kubernetes.io/not-ready` 와 `node.kubernetes.io/unreachable` 에 대해 +`tolerationSeconds=300` 으로 톨러레이션을 추가한다. -자동으로 추가된 이 톨러레이션은 이러한 문제 중 하나가 -감지된 후 5분 동안 바인딩 상태로 남아있는 기본 파드 -동작이 유지되도록 한다. -[DefaultTolerationSecondsadmission controller](https://git.k8s.io/kubernetes/plugin/pkg/admission/defaulttolerationseconds) -어드미션 컨트롤러에 의해 두 개의 기본 톨러레이션이 추가된다. +자동으로 추가된 이 톨러레이션은 이러한 문제 중 하나가 감지된 후 5분 동안 +파드가 노드에 바인딩된 상태를 유지함을 의미한다. +{{< /note >}} [데몬셋](/ko/docs/concepts/workloads/controllers/daemonset/) 파드는 `tolerationSeconds` 가 없는 다음 테인트에 대해 `NoExecute` 톨러레이션를 가지고 생성된다. @@ -273,8 +267,7 @@ tolerations: 마찬가지로 스케줄러는 노드 컨디션을 확인하지 않는다. 대신 스케줄러는 테인트를 확인한다. 이렇게 하면 노드 컨디션이 노드에 스케줄된 내용에 영향을 미치지 않는다. 사용자는 적절한 파드 톨러레이션을 추가하여 노드의 일부 문제(노드 컨디션으로 표시)를 무시하도록 선택할 수 있다. 쿠버네티스 1.8 버전부터 데몬셋 컨트롤러는 다음의 `NoSchedule` 톨러레이션을 -모든 데몬에 자동으로 추가하여, 데몬셋이 중단되는 것을 -방지한다. +모든 데몬에 자동으로 추가하여, 데몬셋이 중단되는 것을 방지한다. * `node.kubernetes.io/memory-pressure` * `node.kubernetes.io/disk-pressure` @@ -284,3 +277,9 @@ tolerations: 이러한 톨러레이션을 추가하면 이전 버전과의 호환성이 보장된다. 데몬셋에 임의의 톨러레이션을 추가할 수도 있다. + + +## {{% heading "whatsnext" %}} + +* [리소스 부족 다루기](/docs/tasks/administer-cluster/out-of-resource/)와 어떻게 구성하는지에 대해 알아보기 +* [파드 우선순위](/ko/docs/concepts/configuration/pod-priority-preemption/)에 대해 알아보기 diff --git a/content/ko/docs/concepts/security/_index.md b/content/ko/docs/concepts/security/_index.md index 079e3dd8f8..d71d63c77a 100644 --- a/content/ko/docs/concepts/security/_index.md +++ b/content/ko/docs/concepts/security/_index.md @@ -1,4 +1,6 @@ --- title: "보안" weight: 81 +description: > + 클라우드 네이티브 워크로드를 안전하게 유지하기 위한 개념 --- diff --git a/content/ko/docs/concepts/security/overview.md b/content/ko/docs/concepts/security/overview.md index f988d1d5d9..bcbc22d915 100644 --- a/content/ko/docs/concepts/security/overview.md +++ b/content/ko/docs/concepts/security/overview.md @@ -1,59 +1,53 @@ --- title: 클라우드 네이티브 보안 개요 content_type: concept -weight: 1 +weight: 10 --- -{{< toc >}} - <!-- overview --> -쿠버네티스 보안(일반적인 보안)은 관련된 많은 부분이 상호작용하는 -방대한 주제다. 오늘날에는 웹 애플리케이션의 실행을 돕는 -수많은 시스템에 오픈소스 소프트웨어가 통합되어 있으며, -전체적인 보안에 대하여 생각할 수 있는 방법에 대한 통찰력을 도울 수 있는 -몇 가지 중요한 개념이 있다. 이 가이드는 클라우드 네이티브 보안과 관련된 -몇 가지 일반적인 개념에 대한 멘탈 모델(mental model)을 정의한다. 멘탈 모델은 완전히 임의적이며 -소프트웨어 스택을 보호할 위치를 생각하는데 도움이되는 경우에만 사용해야 -한다. +이 개요는 클라우드 네이티브 보안의 맥락에서 쿠버네티스 보안에 대한 생각의 모델을 정의한다. + +{{< warning >}} +이 컨테이너 보안 모델은 입증된 정보 보안 정책이 아닌 제안 사항을 제공한다. +{{< /warning >}} <!-- body --> ## 클라우드 네이티브 보안의 4C -계층적인 보안에 대해서 어떻게 생각할 수 있는지 이해하는 데 도움이 될 수 있는 다이어그램부터 살펴보자. + +보안은 계층으로 생각할 수 있다. 클라우드 네이티브 보안의 4C는 클라우드(Cloud), +클러스터(Cluster), 컨테이너(Container)와 코드(Code)이다. + {{< note >}} -이 계층화된 접근 방식은 보안에 대한 [심층 방어](https://en.wikipedia.org/wiki/Defense_in_depth_(computing)) -접근 방식을 강화하며, 소프트웨어 시스템의 보안을 위한 모범 사례로 -널리 알려져 있다. 4C는 클라우드(Cloud), 클러스터(Clusters), 컨테이너(Containers) 및 코드(Code)이다. +이 계층화된 접근 방식은 보안에 대한 [심층 방어](https://en.wikipedia.org/wiki/Defense_in_depth_(computing)) +컴퓨팅 접근 방식을 강화하며, 소프트웨어 시스템의 보안을 위한 모범 사례로 +널리 알려져 있다. {{< /note >}} {{< figure src="/images/docs/4c.png" title="클라우드 네이티브 보안의 4C" >}} - -위 그림에서 볼 수 있듯이, -4C는 각각의 사각형의 보안에 따라 다르다. 코드 -수준의 보안만 처리하여 클라우드, 컨테이너 및 코드의 열악한 보안 표준으로부터 -보호하는 것은 거의 불가능하다. 그러나 이런 영역들의 보안이 적절하게 -처리되고, 코드에 보안을 추가한다면 이미 강력한 기반이 더욱 -강화될 것이다. 이러한 관심 분야는 아래에서 더 자세히 설명한다. +클라우드 네이티브 보안 모델의 각 계층은 다음의 가장 바깥쪽 계층을 기반으로 한다. +코드 계층은 강력한 기본(클라우드, 클러스터, 컨테이너) 보안 계층의 이점을 제공한다. +코드 수준에서 보안을 처리하여 기본 계층의 열악한 보안 표준을 +보호할 수 없다. ## 클라우드 여러 면에서 클라우드(또는 공동 위치 서버, 또는 기업의 데이터 센터)는 쿠버네티스 클러스터 구성을 위한 [신뢰 컴퓨팅 기반(trusted computing base)](https://en.wikipedia.org/wiki/Trusted_computing_base) -이다. 이러한 구성 요소 자체가 취약하거나(또는 취약한 방법으로 구성된) -경우 이 기반 위에서 구축된 모든 구성 요소의 보안을 -실제로 보장할 방법이 없다. 각 클라우드 공급자는 그들의 환경에서 워크로드를 -안전하게 실행하는 방법에 대해 고객에게 광범위한 보안 권장 사항을 -제공한다. 모든 클라우드 공급자와 워크로드는 다르기 때문에 -클라우드 보안에 대한 권장 사항을 제공하는 것은 이 가이드의 범위를 벗어난다. 다음은 -알려진 클라우드 공급자의 보안 문서의 일부와 -쿠버네티스 클러스터를 구성하기 위한 인프라 -보안에 대한 일반적인 지침을 제공한다. +이다. 클라우드 계층이 취약하거나 취약한 방식으로 +구성된 경우 이 기반 위에서 구축된 구성 요소가 안전하다는 +보장은 없다. 각 클라우드 공급자는 해당 환경에서 워크로드를 안전하게 실행하기 +위한 보안 권장 사항을 제시한다. -### 클라우드 공급자 보안 표 +### 클라우드 공급자 보안 +자신의 하드웨어 또는 다른 클라우드 공급자에서 쿠버네티스 클러스터를 실행 중인 경우, +보안 모범 사례는 설명서를 참고한다. +다음은 인기있는 클라우드 공급자의 보안 문서 중 일부에 대한 링크이다. +{{< table caption="클라우드 공급자 보안" >}} IaaS 공급자 | 링크 | -------------------- | ------------ | @@ -64,42 +58,46 @@ IBM Cloud | https://www.ibm.com/cloud/security | Microsoft Azure | https://docs.microsoft.com/en-us/azure/security/azure-security | VMWare VSphere | https://www.vmware.com/security/hardening-guides.html | +{{< /table >}} -자체 하드웨어나 다른 클라우드 공급자를 사용하는 경우 보안에 대한 -모범 사례는 해당 문서를 참조한다. +### 인프라스트럭처 보안 {#infrastructure-security} -### 일반적인 인프라 지침 표 +쿠버네티스 클러스터에서 인프라 보안을 위한 제안은 다음과 같다. + +{{< table caption="인프라스트럭처 보안" >}} 쿠버네티스 인프라에서 고려할 영역 | 추천 | --------------------------------------------- | ------------ | -API 서버에 대한 네트워크 접근(마스터) | 이상적으로는 인터넷에서 쿠버네티스 마스터에 대한 모든 접근을 공개적으로 허용하지 않으며 클러스터를 관리하는데 필요한 IP 주소 집합으로 제한된 네트워크 접근 제어 목록(ACL)에 의해 제어되어야 한다. | -노드에 대한 네트워크 접근(워커 서버) | 노드는 마스터의 지정된 포트 연결_만_ 허용하고(네트워크 접근 제어 목록의 사용), NodePort와 LoadBalancer 유형의 쿠버네티스 서비스에 대한 연결을 허용하도록 구성해야 한다. 가능한 노드가 공용 인터넷에 완전히 노출되어서는 안된다. -클라우드 공급자 API에 대한 쿠버네티스 접근 | 각 클라우드 공급자는 쿠버네티스 마스터 및 노드에 서로 다른 권한을 부여해야 함으로써, 이런 권장 사항이 더 일반적이다. 관리해야 하는 리소스에 대한 [최소 권한의 원칙](https://en.wikipedia.org/wiki/Principle_of_least_privilege)을 따르는 클라우드 공급자의 접근 권한을 클러스터에 구성하는 것이 가장 좋다. AWS의 Kops에 대한 예제: https://github.com/kubernetes/kops/blob/master/docs/iam_roles.md#iam-roles -etcd에 대한 접근 | etcd (쿠버네티스의 데이터저장소)에 대한 접근은 마스터로만 제한되어야 한다. 구성에 따라 TLS를 통해 etcd를 사용해야 한다. 자세한 정보: https://github.com/etcd-io/etcd/tree/master/Documentation#security -etcd 암호화 | 가능한 모든 드라이브를 유휴 상태에서 암호화 하는 것이 좋은 방법이지만, etcd는 전체 클러스터(시크릿 포함)의 상태를 유지하고 있기에 디스크의 암호화는 유휴 상태에서 암호화 되어야 한다. +API 서버에 대한 네트워크 접근(컨트롤 플레인) | 쿠버네티스 컨트롤 플레인에 대한 모든 접근은 인터넷에서 공개적으로 허용되지 않으며 클러스터 관리에 필요한 IP 주소 집합으로 제한된 네트워크 접근 제어 목록에 의해 제어된다. | +노드에 대한 네트워크 접근(노드) | 지정된 포트의 컨트롤 플레인에서 _만_ (네트워크 접근 제어 목록을 통한) 연결을 허용하고 NodePort와 LoadBalancer 유형의 쿠버네티스 서비스에 대한 연결을 허용하도록 노드를 구성해야 한다. 가능하면 이러한 노드가 공용 인터넷에 완전히 노출되어서는 안된다. +클라우드 공급자 API에 대한 쿠버네티스 접근 | 각 클라우드 공급자는 쿠버네티스 컨트롤 플레인 및 노드에 서로 다른 권한 집합을 부여해야 한다. 관리해야하는 리소스에 대해 [최소 권한의 원칙](https://en.wikipedia.org/wiki/Principle_of_least_privilege)을 따르는 클라우드 공급자의 접근 권한을 클러스터에 구성하는 것이 가장 좋다. [Kops 설명서](https://github.com/kubernetes/kops/blob/master/docs/iam_roles.md#iam-roles)는 IAM 정책 및 역할에 대한 정보를 제공한다. +etcd에 대한 접근 | etcd(쿠버네티스의 데이터 저장소)에 대한 접근은 컨트롤 플레인으로만 제한되어야 한다. 구성에 따라 TLS를 통해 etcd를 사용해야 한다. 자세한 내용은 [etcd 문서](https://github.com/etcd-io/etcd/tree/master/Documentation)에서 확인할 수 있다. +etcd 암호화 | 가능한 한 모든 드라이브를 암호화하는 것이 좋은 방법이지만, etcd는 전체 클러스터(시크릿 포함)의 상태를 유지하고 있기에 특히 디스크는 암호화되어 있어야 한다. + +{{< /table >}} ## 클러스터 -이 섹션에서는 쿠버네티스의 워크로드 -보안을 위한 링크를 제공한다. 쿠버네티스 -보안에 영향을 미치는 다음 두 가지 영역이 있다. +쿠버네티스 보안에는 다음의 두 가지 영역이 있다. -* 클러스터를 구성하는 설정 가능한 컴포넌트의 보안 -* 클러스터에서 실행되는 컴포넌트의 보안 +* 설정 가능한 클러스터 컴포넌트의 보안 +* 클러스터에서 실행되는 애플리케이션의 보안 -### 클러스터_의_ 컴포넌트 -우발적이거나 악의적인 접근으로부터 클러스터를 보호하고, -모범 사례에 대한 정보를 채택하기 위해서는 +### 클러스터의 컴포넌트 {#cluster-components} + +우발적이거나 악의적인 접근으로부터 클러스터를 보호하고, +모범 사례에 대한 정보를 채택하기 위해서는 [클러스터 보안](/docs/tasks/administer-cluster/securing-a-cluster/)에 대한 조언을 읽고 따른다. -### 클러스터 _내_ 컴포넌트(애플리케이션) -애플리케이션의 공격 영역에 따라, 보안의 특정 측면에 -중점을 둘 수 있다. 예를 들어, 다른 리소스 체인에 중요한 서비스(서비스 A)와 -리소스 소진 공격에 취약한 별도의 작업 부하(서비스 B)를 실행하는 경우, -리소스 제한을 설정하지 않은 서비스 B에 의해 -서비스 A 또한 손상시킬 위험이 있다. 다음은 쿠버네티스에서 -실행 중인 워크로드를 보호할 때 고려해야 할 사항에 대한 링크 표이다. +### 클러스터 내 컴포넌트(애플리케이션) {#cluster-applications} + +애플리케이션의 공격 영역에 따라, 보안의 특정 측면에 +중점을 둘 수 있다. 예를 들어, 다른 리소스 체인에 중요한 서비스(서비스 A)와 +리소스 소진 공격에 취약한 별도의 작업 부하(서비스 B)를 실행하는 경우, +서비스 B의 리소스를 제한하지 않으면 +서비스 A가 손상될 위험이 높다. 다음은 쿠버네티스에서 +실행되는 워크로드를 보호하기 위한 보안 문제 및 권장 사항이 나와 있는 표이다. 워크로드 보안에서 고려할 영역 | 추천 | ------------------------------ | ------------ | @@ -111,52 +109,45 @@ RBAC 인증(쿠버네티스 API에 대한 접근) | https://kubernetes.io/docs/r 네트워크 정책 | https://kubernetes.io/ko/docs/concepts/services-networking/network-policies/ 쿠버네티스 인그레스를 위한 TLS | https://kubernetes.io/ko/docs/concepts/services-networking/ingress/#tls - - ## 컨테이너 -쿠버네티스에서 소프트웨어를 실행하려면, 소프트웨어는 컨테이너에 있어야 한다. 이로 인해, -쿠버네티스의 원시적인 워크로드 보안으로부터 이점을 얻기 위해서 -반드시 고려해야 할 보안 사항이 있다. 컨테이너 보안 -또한 이 가이드의 범위를 벗어나지만, 해당 주제에 대한 추가적인 설명을 위하여 -일반 권장사항 및 링크 표를 아래에 제공한다. +컨테이너 보안은 이 가이드의 범위를 벗어난다. 다음은 일반적인 권장사항과 +이 주제에 대한 링크이다. 컨테이너에서 고려할 영역 | 추천 | ------------------------------ | ------------ | -컨테이너 취약점 스캔 및 OS에 종속적인 보안 | 이미지 빌드 단계의 일부 또는 정기적으로 [CoreOS의 Clair](https://github.com/coreos/clair/)와 같은 도구를 사용해서 컨테이너에 알려진 취약점이 있는지 검사한다. -이미지 서명 및 시행 | 두 개의 다른 CNCF 프로젝트(TUF 와 Notary)는 컨테이너 이미지에 서명하고 컨테이너 내용에 대한 신뢰 시스템을 유지하는데 유용한 도구이다. 도커를 사용하는 경우 도커 엔진에 [도커 컨텐츠 신뢰](https://docs.docker.com/engine/security/trust/content_trust/)가 내장되어 있다. 시행 부분에서의 [IBM의 Portieris](https://github.com/IBM/portieris) 프로젝트는 쿠버네티스 다이나믹 어드미션 컨트롤러로 실행되는 도구로, 클러스터에서 허가하기 전에 Notary를 통해 이미지가 적절하게 서명되었는지 확인한다. +컨테이너 취약점 스캔 및 OS에 종속적인 보안 | 이미지 빌드 단계의 일부로 컨테이너에 알려진 취약점이 있는지 검사해야 한다. +이미지 서명 및 시행 | 컨테이너 이미지에 서명하여 컨테이너의 내용에 대한 신뢰 시스템을 유지한다. 권한있는 사용자의 비허용 | 컨테이너를 구성할 때 컨테이너의 목적을 수행하는데 필요한 최소 권한을 가진 사용자를 컨테이너 내에 만드는 방법에 대해서는 설명서를 참조한다. ## 코드 -마지막으로 애플리케이션의 코드 수준으로 내려가면, 가장 많은 제어를 할 수 있는 -주요 공격 영역 중 하나이다. 이런 코드 수준은 쿠버네티스의 범위 -밖이지만 몇가지 권장사항이 있다. +애플리케이션 코드는 가장 많은 제어를 할 수 있는 주요 공격 영역 중 하나이다. +애플리케이션 코드 보안은 쿠버네티스 보안 주제를 벗어나지만, +애플리케이션 코드를 보호하기 위한 권장 사항은 다음과 같다. -### 일반적인 코드 보안 지침표 +### 코드 보안 + +{{< table caption="코드 보안" >}} 코드에서 고려할 영역 | 추천 | ---------------------------------------------- | ------------ | -TLS를 통한 접근 | 코드가 TCP를 통해 통신해야 한다면, 클라이언트와 먼저 TLS 핸드 셰이크를 수행하는 것이 이상적이다. 몇 가지 경우를 제외하고, 기본 동작은 전송 중인 모든 것을 암호화하는 것이다. 한걸음 더 나아가, VPC의 "방화벽 뒤"에서도 서비스 간 네트워크 트래픽을 암호화하는 것이 좋다. 이것은 인증서를 가지고 있는 두 서비스의 양방향 검증을 [mTLS](https://en.wikipedia.org/wiki/Mutual_authentication)를 통해 수행할 수 있다. 이것을 수행하기 위해 쿠버네티스에는 [Linkerd](https://linkerd.io/) 및 [Istio](https://istio.io/)와 같은 수많은 도구가 있다. | +-------------------------| -------------- | +TLS를 통한 접근 | 코드가 TCP를 통해 통신해야 한다면, 미리 클라이언트와 TLS 핸드 셰이크를 수행한다. 몇 가지 경우를 제외하고, 전송 중인 모든 것을 암호화한다. 한 걸음 더 나아가, 서비스 간 네트워크 트래픽을 암호화하는 것이 좋다. 이것은 인증서를 가지고 있는 두 서비스의 양방향 검증을 [mTLS](https://en.wikipedia.org/wiki/Mutual_authentication)를 통해 수행할 수 있다. | 통신 포트 범위 제한 | 이 권장사항은 당연할 수도 있지만, 가능하면 통신이나 메트릭 수집에 꼭 필요한 서비스의 포트만 노출시켜야 한다. | -타사 종속성 보안 | 애플리케이션은 자체 코드베이스의 외부에 종속적인 경향이 있기 때문에, 코드의 종속성을 정기적으로 스캔하여 현재 알려진 취약점이 없는지 확인하는 것이 좋다. 각 언어에는 이런 검사를 자동으로 수행하는 도구를 가지고 있다. | +타사 종속성 보안 | 애플리케이션의 타사 라이브러리를 정기적으로 스캔하여 현재 알려진 취약점이 없는지 확인하는 것이 좋다. 각 언어에는 이런 검사를 자동으로 수행하는 도구를 가지고 있다. | 정적 코드 분석 | 대부분 언어에는 잠재적으로 안전하지 않은 코딩 방법에 대해 코드 스니펫을 분석할 수 있는 방법을 제공한다. 가능한 언제든지 일반적인 보안 오류에 대해 코드베이스를 스캔할 수 있는 자동화된 도구를 사용하여 검사를 한다. 도구는 다음에서 찾을 수 있다. https://owasp.org/www-community/Source_Code_Analysis_Tools | -동적 탐지 공격 | 일반적으로 서비스에서 발생할 수 있는 잘 알려진 공격 중 일부를 서비스에 테스트할 수 있는 자동화된 몇 가지 도구가 있다. 이런 잘 알려진 공격에는 SQL 인젝션, CSRF 및 XSS가 포함된다. 가장 널리 사용되는 동적 분석 도구는 OWASP Zed Attack 프록시다. https://owasp.org/www-project-zap/ | - - -## 강력한(robust) 자동화 - -위에서 언급한 대부분의 제안사항은 실제로 일련의 보안 검사의 일부로 코드를 -전달하는 파이프라인에 의해 자동화 될 수 있다. 소프트웨어 전달을 위한 -"지속적인 해킹(Continuous Hacking)"에 대한 접근 방식에 대해 알아 보려면, 자세한 설명을 제공하는 [이 기사](https://thenewstack.io/beyond-ci-cd-how-continuous-hacking-of-docker-containers-and-pipeline-driven-security-keeps-ygrene-secure/)를 참고한다. +동적 탐지 공격 | 잘 알려진 공격 중 일부를 서비스에 테스트할 수 있는 자동화된 몇 가지 도구가 있다. 여기에는 SQL 인젝션, CSRF 및 XSS가 포함된다. 가장 널리 사용되는 동적 분석 도구는 [OWASP Zed Attack 프록시](https://owasp.org/www-project-zap/)이다. | +{{< /table >}} ## {{% heading "whatsnext" %}} -* [파드에 대한 네트워크 정책](/ko/docs/concepts/services-networking/network-policies/) 알아보기 -* [클러스터 보안](/docs/tasks/administer-cluster/securing-a-cluster/)에 대해 알아보기 -* [API 접근 통제](/docs/reference/access-authn-authz/controlling-access/)에 대해 알아보기 -* 컨트롤 플레인에 대한 [전송 데이터 암호화](/docs/tasks/tls/managing-tls-in-a-cluster/) 알아보기 -* [Rest에서 데이터 암호화](/docs/tasks/administer-cluster/encrypt-data/) 알아보기 -* [쿠버네티스 시크릿](/docs/concepts/configuration/secret/)에 대해 알아보기 +쿠버네티스 보안 주제에 관련한 내용들을 배워보자. +* [파드 보안 표준](/docs/concepts/security/pod-security-standards/) +* [파드에 대한 네트워크 정책](/ko/docs/concepts/services-networking/network-policies/) +* [클러스터 보안](/docs/tasks/administer-cluster/securing-a-cluster/) +* [API 접근 통제](/docs/reference/access-authn-authz/controlling-access/) +* 컨트롤 플레인을 위한 [전송 데이터 암호화](/docs/tasks/tls/managing-tls-in-a-cluster/) +* [Rest에서 데이터 암호화](/docs/tasks/administer-cluster/encrypt-data/) +* [쿠버네티스 시크릿](/docs/concepts/configuration/secret/) diff --git a/content/ko/docs/concepts/services-networking/_index.md b/content/ko/docs/concepts/services-networking/_index.md index 101f141102..9cfcfd540b 100644 --- a/content/ko/docs/concepts/services-networking/_index.md +++ b/content/ko/docs/concepts/services-networking/_index.md @@ -1,4 +1,12 @@ --- title: "서비스, 로드밸런싱, 네트워킹" weight: 60 +description: > + 쿠버네티스의 네트워킹에 대한 개념과 리소스에 대해 설명한다. --- + +쿠버네티스 네트워킹은 다음의 네 가지 문제를 해결한다. +- 파드 내의 컨테이너는 루프백(loopback)을 통한 네트워킹을 사용하여 통신한다. +- 클러스터 네트워킹은 서로 다른 파드 간의 통신을 제공한다. +- 서비스 리소스를 사용하면 파드에서 실행 중인 애플리케이션을 클러스터 외부에서 접근할 수 있다. +- 또한 서비스를 사용하여 클러스터 내부에서 사용할 수 있는 서비스만 게시할 수 있다. diff --git a/content/ko/docs/concepts/services-networking/add-entries-to-pod-etc-hosts-with-host-aliases.md b/content/ko/docs/concepts/services-networking/add-entries-to-pod-etc-hosts-with-host-aliases.md index bc5560b5ba..be39f13f21 100644 --- a/content/ko/docs/concepts/services-networking/add-entries-to-pod-etc-hosts-with-host-aliases.md +++ b/content/ko/docs/concepts/services-networking/add-entries-to-pod-etc-hosts-with-host-aliases.md @@ -2,27 +2,28 @@ title: HostAliases로 파드의 /etc/hosts 항목 추가하기 content_type: concept weight: 60 +min-kubernetes-server-version: 1.7 --- -{{< toc >}} <!-- overview --> -파드의 /etc/hosts 파일에 항목을 추가하는 것은 DNS나 다른 방법들이 적용되지 않을 때 파드 수준의 호스트네임 해석을 제공한다. 1.7 버전에서는, 사용자들이 PodSpec의 HostAliases 항목을 사용하여 이러한 사용자 정의 항목들을 추가할 수 있다. -HostAliases를 사용하지 않은 수정은 권장하지 않는데, 이는 호스트 파일이 Kubelet에 의해 관리되고, 파드 생성/재시작 중에 덮어쓰여질 수 있기 때문이다. +파드의 `/etc/hosts` 파일에 항목을 추가하는 것은 DNS나 다른 방법들이 적용되지 않을 때 파드 수준의 호스트네임 해석을 제공한다. PodSpec의 HostAliases 항목을 사용하여 이러한 사용자 정의 항목들을 추가할 수 있다. + +HostAliases를 사용하지 않은 수정은 권장하지 않는데, 이는 호스트 파일이 kubelet에 의해 관리되고, 파드 생성/재시작 중에 덮어쓰여질 수 있기 때문이다. <!-- body --> ## 기본 호스트 파일 내용 -파드 IP가 할당된 Nginx 파드를 시작해보자. +파드 IP가 할당된 Nginx 파드를 시작한다. ```shell -kubectl run nginx --image nginx --generator=run-pod/v1 +kubectl run nginx --image nginx ``` -```shell +``` pod/nginx created ``` @@ -32,7 +33,7 @@ pod/nginx created kubectl get pods --output=wide ``` -```shell +``` NAME READY STATUS RESTARTS AGE IP NODE nginx 1/1 Running 0 13s 10.200.0.4 worker0 ``` @@ -43,7 +44,7 @@ nginx 1/1 Running 0 13s 10.200.0.4 worker0 kubectl exec nginx -- cat /etc/hosts ``` -```none +``` # Kubernetes-managed hosts file. 127.0.0.1 localhost ::1 localhost ip6-localhost ip6-loopback @@ -54,47 +55,47 @@ fe00::2 ip6-allrouters 10.200.0.4 nginx ``` -기본적으로, `hosts` 파일은 `localhost`와 자기 자신의 호스트네임과 같은 IPv4와 IPv6 +기본적으로, `hosts` 파일은 `localhost`와 자기 자신의 호스트네임과 같은 IPv4와 IPv6 상용구들만 포함하고 있다. -## HostAliases를 사용하여 추가 항목들 추가하기 - -기본 상용구 이외에, `foo.local`, `bar.local`이 `127.0.0.1`로, `foo.remote`, -`bar.remote`가 `10.1.2.3`로 해석될 수 있도록 추가 항목들을 `hosts` 파일에 추가할 수 있으며, -이는 `.spec.hostAliases` 항목에서 정의하여 -파드에 HostAliases를 추가하면 가능하다. +## hostAliases를 사용하여 추가 항목들 추가하기 +기본 상용구 이외에, 추가 항목들을 `hosts` 파일에 +추가할 수 있다. +예를 들어, `foo.local`, `bar.local`이 `127.0.0.1`로, +`foo.remote`, `bar.remote`가 `10.1.2.3`로 해석될 수 있도록, `.spec.hostAliases` 항목에서 정의하여 파드에 +HostAliases를 추가하면 가능하다. {{< codenew file="service/networking/hostaliases-pod.yaml" >}} -이 파드는 다음의 명령어를 통해 시작될 수 있다. +다음을 실행하여 해당 구성으로 파드를 실행할 수 있다. ```shell -kubectl apply -f hostaliases-pod.yaml +kubectl apply -f https://k8s.io/examples/service/networking/hostaliases-pod.yaml ``` -```shell +``` pod/hostaliases-pod created ``` -파드의 IP와 상태를 확인해보자. +파드의 세부 정보를 검토하여 IPv4 주소와 상태를 확인해보자. ```shell kubectl get pod --output=wide ``` -```shell +``` NAME READY STATUS RESTARTS AGE IP NODE hostaliases-pod 0/1 Completed 0 6s 10.200.0.5 worker0 ``` -`hosts` 파일 내용은 아래와 같을 것이다. +`hosts` 파일 내용은 아래와 같다. ```shell -kubectl exec hostaliases-pod -- cat /etc/hosts +kubectl logs hostaliases-pod ``` -```none +``` # Kubernetes-managed hosts file. 127.0.0.1 localhost ::1 localhost ip6-localhost ip6-loopback @@ -111,16 +112,16 @@ fe00::2 ip6-allrouters 가장 마지막에 추가 항목들이 정의되어 있는 것을 확인할 수 있다. -## 왜 Kubelet이 호스트 파일을 관리하는가? +## 왜 Kubelet이 호스트 파일을 관리하는가? {#why-does-kubelet-manage-the-hosts-file} -컨테이너가 이미 시작되고 난 후 Docker가 파일을 [수정](https://github.com/moby/moby/issues/17190) -하는 것을 방지하기 위해 Kubelet은 파드의 각 컨테이너의 `hosts` 파일을 -[관리](https://github.com/kubernetes/kubernetes/issues/14633) -한다. - -호스트 파일이 관리된다는 특성으로 인해, 컨테이너 재시작이나 파드 리스케줄 이벤트로 -`hosts` 파일이 Kubelet에 의해 다시 마운트될 때마다 사용자가 작성한 모든 내용이 -덮어쓰여진다. 따라서, 호스트 파일의 내용을 -직접 바꾸는 것은 권장하지 않는다. +컨테이너가 이미 시작되고 난 후 도커가 파일을 +[수정](https://github.com/moby/moby/issues/17190)하는 것을 방지하기 위해 +Kubelet은 파드의 각 컨테이너의 `hosts` 파일을 +[관리](https://github.com/kubernetes/kubernetes/issues/14633)한다. +{{< caution >}} +컨테이너 내부의 호스트 파일을 수동으로 변경하면 안된다. +호스트 파일을 수동으로 변경하면, +컨테이너가 종료되면 변경 사항이 손실된다. +{{< /caution >}} diff --git a/content/ko/docs/concepts/services-networking/connect-applications-service.md b/content/ko/docs/concepts/services-networking/connect-applications-service.md index 4649577399..1993fc860d 100644 --- a/content/ko/docs/concepts/services-networking/connect-applications-service.md +++ b/content/ko/docs/concepts/services-networking/connect-applications-service.md @@ -50,7 +50,7 @@ kubectl get pods -l run=my-nginx -o yaml | grep podIP 클러스터의 모든 노드로 ssh 접속하고 두 IP로 curl을 할수 있어야 한다. 컨테이너는 노드의 포트 80을 사용하지 *않으며* , 트래픽을 파드로 라우팅하는 특별한 NAT 규칙도 없다는 것을 참고한다. 이것은 동일한 containerPort를 사용해서 동일한 노드에서 여러 nginx 파드를 실행하고 IP를 사용해서 클러스터의 다른 파드나 노드에서 접근할 수 있다는 의미이다. 도커와 마찬가지로 포트는 여전히 호스트 노드의 인터페이스에 게시될 수 있지만, 네트워킹 모델로 인해 포트의 필요성이 크게 줄어든다. -만약 궁금하다면 [우리가 이것을 달성하는 방법](/docs/concepts/cluster-administration/networking/#how-to-achieve-this)을 자세히 읽어본다. +만약 궁금하다면 [우리가 이것을 달성하는 방법](/ko/docs/concepts/cluster-administration/networking/#쿠버네티스-네트워크-모델의-구현-방법)을 자세히 읽어본다. ## 서비스 생성하기 @@ -73,7 +73,7 @@ service/my-nginx exposed 이 사양은 `run: my-nginx` 레이블이 부착된 모든 파드에 TCP 포트 80을 대상으로 하는 서비스를 만들고 추상화된 서비스 포트에 노출시킨다 -(`targetPort` 는 컨테이너가 트래픽을 수신하는 포트, `port` 는 +(`targetPort` 는 컨테이너가 트래픽을 수신하는 포트, `port` 는 추상화된 서비스 포트로 다른 파드들이 서비스에 접속하기위해 사용하는 모든 포트일 수 있다). [서비스](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#service-v1-core)의 @@ -198,7 +198,7 @@ kube-dns ClusterIP 10.0.0.10 <none> 53/UDP,53/TCP 8m ``` 이 섹션의 나머지 부분에서는 수명이 긴 IP의 서비스(my-nginx)와 이 IP -에 이름을 할당한 DNS 서버가 있다고 가정한다. 여기서는 CoreDNS 클러스터 애드온(애플리케이션 이름 `kube-dns`)을 사용하므로, 표준 방법(예: `gethostbyname()`)을 사용해서 클러스터의 모든 파드에서 서비스와 통신할 수 있다. 만약 CoreDNS가 실행 중이 아니라면 [CoreDNS README](https://github.com/coredns/deployment/tree/master/kubernetes) 또는 [CoreDNS 설치](/docs/tasks/administer-cluster/coredns/#installing-coredns)를 참조해서 활성화 할 수 있다. 이것을 테스트하기 위해 다른 curl 애플리케이션을 실행한다. +에 이름을 할당한 DNS 서버가 있다고 가정한다. 여기서는 CoreDNS 클러스터 애드온(애플리케이션 이름 `kube-dns`)을 사용하므로, 표준 방법(예: `gethostbyname()`)을 사용해서 클러스터의 모든 파드에서 서비스와 통신할 수 있다. 만약 CoreDNS가 실행 중이 아니라면 [CoreDNS README](https://github.com/coredns/deployment/tree/master/kubernetes) 또는 [CoreDNS 설치](/ko/docs/tasks/administer-cluster/coredns/#coredns-설치)를 참조해서 활성화 할 수 있다. 이것을 테스트하기 위해 다른 curl 애플리케이션을 실행한다. ```shell kubectl run curl --image=radial/busyboxplus:curl -i --tty @@ -390,8 +390,8 @@ kubectl edit svc my-nginx kubectl get svc my-nginx ``` ``` -NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE -my-nginx ClusterIP 10.0.162.149 162.222.184.144 80/TCP,81/TCP,82/TCP 21s +NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE +my-nginx LoadBalancer 10.0.162.149 xx.xxx.xxx.xxx 8080:30163/TCP 21s ``` ``` curl https://<EXTERNAL-IP> -k @@ -422,5 +422,3 @@ LoadBalancer Ingress: a320587ffd19711e5a37606cf4a74574-1142138393.us-east-1.el * [서비스를 사용해서 클러스터 내 애플리케이션에 접근하기](/docs/tasks/access-application-cluster/service-access-application-cluster/)를 더 자세히 알아본다. * [서비스를 사용해서 프론트 엔드부터 백 엔드까지 연결하기](/docs/tasks/access-application-cluster/connecting-frontend-backend/)를 더 자세히 알아본다. * [외부 로드 밸런서를 생성하기](/docs/tasks/access-application-cluster/create-external-load-balancer/)를 더 자세히 알아본다. - - diff --git a/content/ko/docs/concepts/services-networking/dns-pod-service.md b/content/ko/docs/concepts/services-networking/dns-pod-service.md index 7550473fc2..3f5a05f4ee 100644 --- a/content/ko/docs/concepts/services-networking/dns-pod-service.md +++ b/content/ko/docs/concepts/services-networking/dns-pod-service.md @@ -3,9 +3,6 @@ title: 서비스 및 파드용 DNS content_type: concept weight: 20 --- - - - <!-- overview --> 이 페이지는 쿠버네티스의 DNS 지원에 대한 개요를 설명한다. @@ -14,26 +11,26 @@ weight: 20 ## 소개 -쿠버네티스 DNS는 클러스터의 서비스와 DNS 파드를 관리하며, -개별 컨테이너들이 DNS 네임을 해석할 때 +쿠버네티스 DNS는 클러스터의 서비스와 DNS 파드를 관리하며, +개별 컨테이너들이 DNS 네임을 해석할 때 DNS 서비스의 IP를 사용하도록 kubelets를 구성한다. ### DNS 네임이 할당되는 것들 -클러스터 내의 모든 서비스(DNS 서버 자신도 포함하여)에는 DNS 네임이 할당된다. -기본적으로 클라이언트 파드의 DNS 검색 리스트는 파드 자체의 네임스페이스와 -클러스터의 기본 도메인을 포함한다. +클러스터 내의 모든 서비스(DNS 서버 자신도 포함하여)에는 DNS 네임이 할당된다. +기본적으로 클라이언트 파드의 DNS 검색 리스트는 파드 자체의 네임스페이스와 +클러스터의 기본 도메인을 포함한다. 이 예시는 다음과 같다. -쿠버네티스 네임스페이스 `bar`에 `foo`라는 서비스가 있다. 네임스페이스 `bar`에서 running 상태인 파드는 -단순하게 `foo`를 조회하는 DNS 쿼리를 통해서 서비스 `foo`를 찾을 수 있다. -네임스페이스 `quux`에서 실행 중인 파드는 +쿠버네티스 네임스페이스 `bar`에 `foo`라는 서비스가 있다. 네임스페이스 `bar`에서 running 상태인 파드는 +단순하게 `foo`를 조회하는 DNS 쿼리를 통해서 서비스 `foo`를 찾을 수 있다. +네임스페이스 `quux`에서 실행 중인 파드는 `foo.bar`를 조회하는 DNS 쿼리를 통해서 이 서비스를 찾을 수 있다. -다음 절에서는 쿠버네티스 DNS에서 지원하는 레코드 유형과 레이아웃을 자세히 설명한다. -이 외에 동작하는 레이아웃, 네임 또는 쿼리는 구현 세부 정보로 간주하며 경고 없이 변경될 수 있다. +다음 절에서는 쿠버네티스 DNS에서 지원하는 레코드 유형과 레이아웃을 자세히 설명한다. +이 외에 동작하는 레이아웃, 네임 또는 쿼리는 구현 세부 정보로 간주하며 +경고 없이 변경될 수 있다. 최신 업데이트에 대한 자세한 설명은 다음 링크를 통해 참조할 수 있다. - [쿠버네티스 DNS 기반 서비스 디스커버리](https://github.com/kubernetes/dns/blob/master/docs/specification.md). ## 서비스 @@ -41,43 +38,50 @@ DNS 서비스의 IP를 사용하도록 kubelets를 구성한다. ### A/AAAA 레코드 "노멀"(헤드리스가 아닌) 서비스는 서비스 IP 계열에 따라 -`my-svc.my-namespace.svc.cluster-domain.example` +`my-svc.my-namespace.svc.cluster-domain.example` 형식의 이름을 가진 DNS A 또는 AAAA 레코드가 할당된다. 이는 서비스의 클러스터 IP로 해석된다. "헤드리스"(클러스터 IP가 없는) 서비스 또한 서비스 IP 계열에 따라 -`my-svc.my-namespace.svc.cluster-domain.example` -형식의 이름을 가진 DNS A 또는 AAAA 레코드가 할당된다. -노멀 서비스와는 다르게 이는 서비스에 의해 선택된 파드들의 IP 집합으로 해석된다. +`my-svc.my-namespace.svc.cluster-domain.example` +형식의 이름을 가진 DNS A 또는 AAAA 레코드가 할당된다. +노멀 서비스와는 다르게 이는 서비스에 의해 선택된 파드들의 IP 집합으로 해석된다. 클라이언트는 해석된 IP 집합에서 IP를 직접 선택하거나 표준 라운드로빈을 통해 선택할 수 있다. ### SRV 레코드 -SRV 레코드는 노멀 서비스 또는 -[헤드리스 서비스](/ko/docs/concepts/services-networking/service/#헤드리스-headless-서비스)에 -속하는 네임드 포트를 위해 만들어졌다. 각각의 네임드 포트에 대해서 SRV 레코드는 다음과 같은 형식을 가질 수 있다. +SRV 레코드는 노멀 서비스 또는 +[헤드리스 서비스](/ko/docs/concepts/services-networking/service/#헤드리스-headless-서비스)에 +속하는 네임드 포트를 위해 만들어졌다. 각각의 네임드 포트에 대해서 SRV 레코드는 다음과 같은 형식을 가질 수 있다. `_my-port-name._my-port-protocol.my-svc.my-namespace.svc.cluster-domain.example`. -정규 서비스의 경우, 이는 포트 번호와 도메인 네임으로 해석된다. +정규 서비스의 경우, 이는 포트 번호와 도메인 네임으로 해석된다. `my-svc.my-namespace.svc.cluster-domain.example`. -헤드리스 서비스의 경우, 서비스를 지원하는 각 파드에 대해 하나씩 복수 응답으로 해석되며 이 응답은 파드의 -포트 번호와 도메인 이름을 포함한다. +헤드리스 서비스의 경우, 서비스를 지원하는 각 파드에 대해 하나씩 복수 응답으로 해석되며 이 응답은 파드의 +포트 번호와 도메인 이름을 포함한다. `auto-generated-name.my-svc.my-namespace.svc.cluster-domain.example`. ## 파드 +### A/AAAA 레코드 + +디플로이먼트나 데몬셋으로 생성되는 파드는 다음과 같은 +DNS 주소를 갖게 된다. + +`pod-ip-address.deployment-name.my-namespace.svc.cluster-domain.example.` + ### 파드의 hostname 및 subdomain 필드 파드가 생성되면 hostname은 해당 파드의 `metadata.name` 값이 된다. -파드 스펙(Pod spec)에는 선택적 필드인 `hostname`이 있다. -이 필드는 파드의 호스트네임을 지정할 수 있다. -`hostname` 필드가 지정되면, 파드의 이름보다 파드의 호스트네임이 우선시된다. +파드 스펙(Pod spec)에는 선택적 필드인 `hostname`이 있다. +이 필드는 파드의 호스트네임을 지정할 수 있다. +`hostname` 필드가 지정되면, 파드의 이름보다 파드의 호스트네임이 우선시된다. 예를 들어 `hostname` 필드가 "`my-host`"로 설정된 파드는 호스트네임이 "`my-host`"로 설정된다. -또한, 파드 스펙에는 선택적 필드인 `subdomain`이 있다. 이 필드는 서브도메인을 지정할 수 있다. -예를 들어 "`my-namespace`" 네임스페이스에서, `hostname` 필드가 "`foo`"로 설정되고, -`subdomain` 필드가 "`bar`"로 설정된 파드는 전체 주소 도메인 네임(FQDN)을 가지게 된다. +또한, 파드 스펙에는 선택적 필드인 `subdomain`이 있다. 이 필드는 서브도메인을 지정할 수 있다. +예를 들어 "`my-namespace`" 네임스페이스에서, `hostname` 필드가 "`foo`"로 설정되고, +`subdomain` 필드가 "`bar`"로 설정된 파드는 전체 주소 도메인 네임(FQDN)을 가지게 된다. "`foo.bar.my-namespace.svc.cluster-domain.example`". 예시: @@ -129,59 +133,58 @@ spec: name: busybox ``` -파드와 동일한 네임스페이스 내에 같은 서브도메인 이름을 가진 헤드리스 서비스가 있다면, +파드와 동일한 네임스페이스 내에 같은 서브도메인 이름을 가진 헤드리스 서비스가 있다면, 클러스터의 DNS 서버는 파드의 전체 주소 호스트네임(fully qualified hostname)인 A 또는 AAAA 레코드를 반환한다. -예를 들어 호스트네임이 "`busybox-1`"이고, -서브도메인이 "`default-subdomain`"이고, -같은 네임스페이스 내 헤드리스 서비스의 이름이 "`default-subdomain`"이면, -파드는 다음과 같이 자기 자신의 FQDN을 얻게 된다. +예를 들어 호스트네임이 "`busybox-1`"이고, +서브도메인이 "`default-subdomain`"이고, +같은 네임스페이스 내 헤드리스 서비스의 이름이 "`default-subdomain`"이면, +파드는 다음과 같이 자기 자신의 FQDN을 얻게 된다. "`busybox-1.default-subdomain.my-namespace.svc.cluster-domain.example`". -DNS는 위 FQDN에 대해 파드의 IP를 가리키는 A 또는 AAAA 레코드를 제공한다. +DNS는 위 FQDN에 대해 파드의 IP를 가리키는 A 또는 AAAA 레코드를 제공한다. "`busybox1`"와 "`busybox2`" 파드 모두 각 파드를 구분 가능한 A 또는 AAAA 레코드를 가지고 있다. -엔드포인트 객체는 `hostname` 필드를 임의의 엔드포인트 IP 주소로 지정할 수 있다. +엔드포인트 객체는 `hostname` 필드를 +임의의 엔드포인트 IP 주소로 지정할 수 있다. {{< note >}} -A 또는 AAAA 레코드는 파드의 이름으로 생성되지 않기 때문에 -파드의 A 또는 AAAA 레코드를 생성하기 위해서는 `hostname` 필드를 작성해야 한다. -`hostname` 필드는 없고 `subdomain` 필드만 있는 파드는 파드의 IP 주소를 가리키는 헤드리스 서비스의 -A 또는 AAAA 레코드만 생성할 수 있다. -(`default-subdomain.my-namespace.svc.cluster-domain.example`) -또한 레코드를 가지기 위해서는 파드가 준비되어야 한다. -그렇지 않은 경우, 서비스에서 `publishNotReadyAddresses=True`가 활성화된다. +A 또는 AAAA 레코드는 파드의 이름으로 생성되지 않기 때문에 +파드의 A 또는 AAAA 레코드를 생성하기 위해서는 `hostname` 필드를 작성해야 한다. +`hostname` 필드는 없고 `subdomain` 필드만 있는 파드는 파드의 IP 주소를 가리키는 헤드리스 서비스의 +A 또는 AAAA 레코드만 생성할 수 있다. (`default-subdomain.my-namespace.svc.cluster-domain.example`) +또한 서비스에서 `publishNotReadyAddresses=True` 를 설정하지 않았다면, 파드가 준비 상태가 되어야 레코드를 가질 수 있다. {{< /note >}} ### 파드의 DNS 정책 -DNS 정책은 파드별로 설정할 수 있다. 현재 쿠버네티스는 다음과 같은 파드별 DNS 정책을 지원한다. +DNS 정책은 파드별로 설정할 수 있다. +현재 쿠버네티스는 다음과 같은 파드별 DNS 정책을 지원한다. 이 정책들은 파드 스펙의 `dnsPolicy` 필드에서 지정할 수 있다. -- "`Default`": 파드는 파드가 실행되고 있는 노드로부터 네임 해석 설정(the name resolution configuration)을 상속받는다. - 자세한 내용은 - [관련 논의](/docs/tasks/administer-cluster/dns-custom-nameservers/#inheriting-dns-from-the-node) - 에서 확인할 수 있다. -- "`ClusterFirst`": "`www.kubernetes.io`"와 같이 클러스터 도메인 suffix 구성과 - 일치하지 않는 DNS 쿼리는 노드에서 상속된 업스트림 네임서버로 전달된다. - 클러스터 관리자는 추가 스텁-도메인(stub-domain)과 업스트림 DNS 서버를 구축할 수 있다. - 그러한 경우 DNS 쿼리를 어떻게 처리하는지에 대한 자세한 내용은 - [관련 논의](/docs/tasks/administer-cluster/dns-custom-nameservers/#effects-on-pods) - 에서 확인할 수 있다. -- "`ClusterFirstWithHostNet`": hostNetwork에서 running 상태인 파드의 경우 DNS 정책인 +- "`Default`": 파드는 파드가 실행되고 있는 노드로부터 네임 해석 설정(the name resolution configuration)을 상속받는다. + 자세한 내용은 + [관련 논의](/ko/docs/tasks/administer-cluster/dns-custom-nameservers/)에서 + 확인할 수 있다. +- "`ClusterFirst`": "`www.kubernetes.io`"와 같이 클러스터 도메인 suffix 구성과 + 일치하지 않는 DNS 쿼리는 노드에서 상속된 업스트림 네임서버로 전달된다. + 클러스터 관리자는 추가 스텁-도메인(stub-domain)과 업스트림 DNS 서버를 구축할 수 있다. + 그러한 경우 DNS 쿼리를 어떻게 처리하는지에 대한 자세한 내용은 + [관련 논의](/ko/docs/tasks/administer-cluster/dns-custom-nameservers/)에서 + 확인할 수 있다. +- "`ClusterFirstWithHostNet`": hostNetwork에서 running 상태인 파드의 경우 DNS 정책인 "`ClusterFirstWithHostNet`"을 명시적으로 설정해야 한다. -- "`None`": 이 정책은 파드가 쿠버네티스 환경의 DNS 설정을 무시하도록 한다. +- "`None`": 이 정책은 파드가 쿠버네티스 환경의 DNS 설정을 무시하도록 한다. 모든 DNS 설정은 파드 스펙 내에 `dnsConfig`필드를 사용하여 제공해야 한다. - 아래 절인 - [파드의 DNS 설정](#pod-dns-config) - 에서 자세한 내용을 확인할 수 있다. + 아래 절인 [파드의 DNS 설정](#pod-dns-config)에서 + 자세한 내용을 확인할 수 있다. {{< note >}} -"Default"는 기본 DNS 정책이 아니다. `dnsPolicy`가 명시적으로 지정되어있지 않다면 +"Default"는 기본 DNS 정책이 아니다. `dnsPolicy`가 명시적으로 지정되어있지 않다면 “ClusterFirst”가 기본값으로 사용된다. {{< /note >}} -아래 예시는 `hostNetwork`필드가 `true`로 설정되어 있어서 -DNS 정책이 "`ClusterFirstWithHostNet`"으로 설정된 파드를 보여준다. +아래 예시는 `hostNetwork`필드가 `true`로 설정되어 있어서 +DNS 정책이 "`ClusterFirstWithHostNet`"으로 설정된 파드를 보여준다. ```yaml apiVersion: v1 @@ -206,30 +209,33 @@ spec: 사용자들은 파드의 DNS 설정을 통해서 직접 파드의 DNS를 세팅할 수 있다. -`dnsConfig` 필드는 선택적이고, `dnsPolicy` 세팅과 함께 동작한다. -이때, 파드의 `dnsPolicy`의 값이 "`None`"으로 설정되어 있어야 `dnsConfig` 필드를 지정할 수 있다. +`dnsConfig` 필드는 선택적이고, `dnsPolicy` 세팅과 함께 동작한다. +이때, 파드의 `dnsPolicy`의 값이 "`None`"으로 설정되어 있어야 +`dnsConfig` 필드를 지정할 수 있다. 사용자는 `dnsConfig` 필드에서 다음과 같은 속성들을 지정할 수 있다. -- `nameservers`: 파드의 DNS 서버가 사용할 IP 주소들의 목록이다. - 파드의 `dnsPolicy`가 "`None`" 으로 설정된 경우에는 - 적어도 하나의 IP 주소가 포함되어야 하며, +- `nameservers`: 파드의 DNS 서버가 사용할 IP 주소들의 목록이다. + 파드의 `dnsPolicy`가 "`None`" 으로 설정된 경우에는 + 적어도 하나의 IP 주소가 포함되어야 하며, 그렇지 않으면 이 속성은 생략할 수 있다. - `nameservers`에 나열된 서버는 지정된 DNS 정책을 통해 생성된 기본 네임 서버와 합쳐지며 중복되는 주소는 제거된다. -- `searches`: 파드의 호스트네임을 찾기 위한 DNS 검색 도메인의 목록이다. - 이 속성은 생략이 가능하며, - 값을 지정한 경우 나열된 검색 도메인은 지정된 DNS 정책을 통해 생성된 기본 검색 도메인에 합쳐진다. - 병합 시 중복되는 도메인은 제거되며, 쿠버네티스는 최대 6개의 검색 도메인을 허용하고 있다. -- `options`: `name` 속성(필수)과 `value` 속성(선택)을 가질 수 있는 객체들의 선택적 목록이다. - 이 속성의 내용은 지정된 DNS 정책에서 생성된 옵션으로 병합된다. - 이 속성의 내용은 지정된 DNS 정책을 통해 생성된 옵션으로 합쳐지며, + `nameservers`에 나열된 서버는 지정된 DNS 정책을 통해 생성된 기본 네임 서버와 합쳐지며 + 중복되는 주소는 제거된다. +- `searches`: 파드의 호스트네임을 찾기 위한 DNS 검색 도메인의 목록이다. + 이 속성은 생략이 가능하며, + 값을 지정한 경우 나열된 검색 도메인은 지정된 DNS 정책을 통해 생성된 기본 검색 도메인에 합쳐진다. + 병합 시 중복되는 도메인은 제거되며, + 쿠버네티스는 최대 6개의 검색 도메인을 허용하고 있다. +- `options`: `name` 속성(필수)과 `value` 속성(선택)을 가질 수 있는 객체들의 선택적 목록이다. + 이 속성의 내용은 지정된 DNS 정책에서 생성된 옵션으로 병합된다. + 이 속성의 내용은 지정된 DNS 정책을 통해 생성된 옵션으로 합쳐지며, 병합 시 중복되는 항목은 제거된다. - + 다음은 커스텀 DNS 세팅을 한 파드의 예시이다. {{< codenew file="service/networking/custom-dns.yaml" >}} -위에서 파드가 생성되면, +위에서 파드가 생성되면, 컨테이너 `test`의 `/etc/resolv.conf` 파일에는 다음과 같은 내용이 추가된다. ``` @@ -243,9 +249,7 @@ IPv6 셋업을 위해서 검색 경로와 네임 서버 셋업은 다음과 같 ```shell kubectl exec -it dns-example -- cat /etc/resolv.conf ``` - 출력은 다음과 같은 형식일 것이다. - ```shell nameserver fd00:79:30::a search default.svc.cluster-domain.example svc.cluster-domain.example cluster-domain.example @@ -267,9 +271,5 @@ options ndots:5 ## {{% heading "whatsnext" %}} -DNS 구성 관리에 대한 지침은 -[DNS 서비스 구성](/docs/tasks/administer-cluster/dns-custom-nameservers/) -에서 확인 할 수 있다. - - - +DNS 구성 관리에 대한 지침은 +[DNS 서비스 구성](/ko/docs/tasks/administer-cluster/dns-custom-nameservers/)에서 확인할 수 있다. diff --git a/content/ko/docs/concepts/services-networking/dual-stack.md b/content/ko/docs/concepts/services-networking/dual-stack.md index 11390c04d5..6efe70de75 100644 --- a/content/ko/docs/concepts/services-networking/dual-stack.md +++ b/content/ko/docs/concepts/services-networking/dual-stack.md @@ -39,7 +39,7 @@ IPv4/IPv6 이중 스택 쿠버네티스 클러스터를 활용하려면 다음 ## IPv4/IPv6 이중 스택 활성화 -IPv4/IPv6 이중 스택을 활성화 하려면, 클러스터의 관련 구성요소에 대해 `IPv6DualStack` [기능 게이트](/docs/reference/command-line-tools-reference/feature-gates/) 를 활성화 하고, 이중 스택 클러스터 네트워크 할당을 설정한다. +IPv4/IPv6 이중 스택을 활성화 하려면, 클러스터의 관련 구성요소에 대해 `IPv6DualStack` [기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/) 를 활성화 하고, 이중 스택 클러스터 네트워크 할당을 설정한다. * kube-apiserver: * `--feature-gates="IPv6DualStack=true"` @@ -47,7 +47,7 @@ IPv4/IPv6 이중 스택을 활성화 하려면, 클러스터의 관련 구성요 * `--feature-gates="IPv6DualStack=true"` * `--cluster-cidr=<IPv4 CIDR>,<IPv6 CIDR>` * `--service-cluster-ip-range=<IPv4 CIDR>,<IPv6 CIDR>` - * `--node-cidr-mask-size-ipv4|--node-cidr-mask-size-ipv6` IPv4의 기본값은 /24 이고 IPv6의 기본값은 /64이다. + * `--node-cidr-mask-size-ipv4|--node-cidr-mask-size-ipv6` IPv4의 기본값은 /24 이고 IPv6의 기본값은 /64 이다. * kubelet: * `--feature-gates="IPv6DualStack=true"` * kube-proxy: @@ -105,5 +105,3 @@ IPv6가 활성화된 외부 로드 밸런서를 지원하는 클라우드 공급 * [IPv4/IPv6 이중 스택 확인](/docs/tasks/network/validate-dual-stack) 네트워킹 - - diff --git a/content/ko/docs/concepts/services-networking/endpoint-slices.md b/content/ko/docs/concepts/services-networking/endpoint-slices.md index 2a2ffc45bf..d5f7a2abf3 100644 --- a/content/ko/docs/concepts/services-networking/endpoint-slices.md +++ b/content/ko/docs/concepts/services-networking/endpoint-slices.md @@ -41,7 +41,7 @@ term_id="selector" >}} 가 지정되면 EndpointSlice 서비스 셀렉터와 매치되는 모든 파드들을 포함하고 참조한다. 엔드포인트슬라이스는 고유한 서비스와 포트 조합을 통해 네트워크 엔드포인트를 그룹화 한다. EndpointSlice 오브젝트의 이름은 유효한 -[DNS 서브도메인 이름](/ko/docs/concepts/overview/working-with-objects/names/#dns-서브도메인-이름들)이어야 한다. +[DNS 서브도메인 이름](/ko/docs/concepts/overview/working-with-objects/names/#dns-서브도메인-이름)이어야 한다. 예를 들어, 여기에 `example` 쿠버네티스 서비스를 위한 EndpointSlice 리소스 샘플이 있다. @@ -152,7 +152,7 @@ text="kube-controller-manager" term_id="kube-controller-manager" >}} 플래그 필요한 새 엔드포인트로 채운다. 3. 추가할 새 엔드포인트가 여전히 남아있으면, 이전에 변경되지 않은 슬라이스에 엔드포인트를 맞추거나 새로운 것을 생성한다. - + 중요한 것은, 세 번째 단계는 엔드포인트슬라이스를 완벽하게 전부 배포하는 것보다 엔드포인트슬라이스 업데이트 제한을 우선시한다. 예를 들어, 추가할 새 엔드포인트가 10개이고 각각 5개의 공간을 사용할 수 있는 엔드포인트 공간이 있는 2개의 @@ -161,7 +161,7 @@ text="kube-controller-manager" term_id="kube-controller-manager" >}} 플래그 엔드포인트슬라이스를 생성하는 것이 여러 엔드포인트슬라이스를 업데이트하는 것 보다 더 선호된다. 각 노드에서 kube-proxy를 실행하고 엔드포인트슬라이스를 관찰하면, -엔드포인트슬라이스에 대한 모든 변경 사항이 클러스터의 모든 노드로 전송되기 +엔드포인트슬라이스에 대한 모든 변경 사항이 클러스터의 모든 노드로 전송되기 때문에 상대적으로 비용이 많이 소요된다. 이 방법은 여러 엔드포인트슬라이스가 가득 차지 않은 결과가 발생할지라도, 모든 노드에 전송해야 하는 변경 횟수를 의도적으로 제한하기 위한 것이다. @@ -179,6 +179,4 @@ text="kube-controller-manager" term_id="kube-controller-manager" >}} 플래그 * [엔드포인트슬라이스 활성화하기](/docs/tasks/administer-cluster/enabling-endpointslices) -* [애플리케이션을 서비스와 함께 연결하기](/ko/docs/concepts/services-networking/connect-applications-service/) 를 읽는다. - - +* [애플리케이션을 서비스와 함께 연결하기](/ko/docs/concepts/services-networking/connect-applications-service/)를 읽어보기 diff --git a/content/ko/docs/concepts/services-networking/ingress-controllers.md b/content/ko/docs/concepts/services-networking/ingress-controllers.md index 4600c32bcf..47d2687dee 100644 --- a/content/ko/docs/concepts/services-networking/ingress-controllers.md +++ b/content/ko/docs/concepts/services-networking/ingress-controllers.md @@ -9,12 +9,13 @@ weight: 40 인그레스 리소스가 작동하려면, 클러스터는 실행 중인 인그레스 컨트롤러가 반드시 필요하다. -kube-controller-manager 바이너리의 일부로 실행되는 컨트롤러의 다른 타입과 달리 인그레스 컨트롤러는 클러스터와 함께 자동으로 실행되지 않는다. +kube-controller-manager 바이너리의 일부로 실행되는 컨트롤러의 다른 타입과 달리 인그레스 컨트롤러는 +클러스터와 함께 자동으로 실행되지 않는다. 클러스터에 가장 적합한 인그레스 컨트롤러 구현을 선택하는데 이 페이지를 사용한다. 프로젝트로써 쿠버네티스는 현재 [GCE](https://git.k8s.io/ingress-gce/README.md) 와 [nginx](https://git.k8s.io/ingress-nginx/README.md) 컨트롤러를 지원하고 유지한다. - + <!-- body --> @@ -22,31 +23,42 @@ kube-controller-manager 바이너리의 일부로 실행되는 컨트롤러의 ## 추가 컨트롤러 * [AKS Application Gateway Ingress Controller](https://github.com/Azure/application-gateway-kubernetes-ingress) is an ingress controller that enables ingress to [AKS clusters](https://docs.microsoft.com/azure/aks/kubernetes-walkthrough-portal) using the [Azure Application Gateway](https://docs.microsoft.com/azure/application-gateway/overview). -* [Ambassador](https://www.getambassador.io/) API 게이트웨이는 [Datawire](https://www.datawire.io/)의 - [커뮤니티](https://www.getambassador.io/docs) 혹은 [상업적](https://www.getambassador.io/pro/) 지원을 제공하는 +* [Ambassador](https://www.getambassador.io/) API 게이트웨이는 [Datawire](https://www.datawire.io/)의 + [커뮤니티](https://www.getambassador.io/docs) 혹은 [상업적](https://www.getambassador.io/pro/) 지원을 제공하는 [Envoy](https://www.envoyproxy.io) 기반 인그레스 컨트롤러다. -* [AppsCode Inc.](https://appscode.com) 는 가장 널리 사용되는 [HAProxy](http://www.haproxy.org/) 기반 인그레스 컨트롤러인 [Voyager](https://appscode.com/products/voyager)에 대한 지원 및 유지 보수를 제공한다. +* [AppsCode Inc.](https://appscode.com) 는 가장 널리 사용되는 [HAProxy](http://www.haproxy.org/) 기반 인그레스 컨트롤러인 [Voyager](https://appscode.com/products/voyager)에 대한 지원 및 유지 보수를 제공한다. * [AWS ALB 인그레스 컨트롤러](https://github.com/kubernetes-sigs/aws-alb-ingress-controller)는 [AWS Application Load Balancer](https://aws.amazon.com/elasticloadbalancing/)를 사용하여 인그레스를 활성화한다. -* [Contour](https://projectcontour.io/)는 VMware에서 제공하고 지원하는 [Envoy](https://www.envoyproxy.io/) 기반 인그레스 컨트롤러다. +* [Contour](https://projectcontour.io/)는 [Envoy](https://www.envoyproxy.io/) 기반 인그레스 컨트롤러로 + VMware에서 제공하고 지원한다. * Citrix는 [베어메탈](https://github.com/citrix/citrix-k8s-ingress-controller/tree/master/deployment/baremetal)과 [클라우드](https://github.com/citrix/citrix-k8s-ingress-controller/tree/master/deployment) 배포를 위해 하드웨어 (MPX), 가상화 (VPX) 및 [무료 컨테이너화 (CPX) ADC](https://www.citrix.com/products/citrix-adc/cpx-express.html)를 위한 [인그레스 컨트롤러](https://github.com/citrix/citrix-k8s-ingress-controller)를 제공한다. -* F5 Networks는 [쿠버네티스를 위한 F5 BIG-IP 컨트롤러](http://clouddocs.f5.com/products/connectors/k8s-bigip-ctlr/latest)에 대한 [지원과 유지 보수](https://support.f5.com/csp/article/K86859508)를 제공한다. +* F5 Networks는 [쿠버네티스를 위한 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)는 [solo.io](https://www.solo.io)의 엔터프라이즈 지원과 함께 API 게이트웨이 기능을 제공하는 [Envoy](https://www.envoyproxy.io) 기반의 오픈 소스 인그레스 컨트롤러다. * [HAProxy 인그레스](https://haproxy-ingress.github.io)는 HAProxy를 위한 고도로 커스터마이징 가능한 커뮤니티 주도형 인그레스 컨트롤러다. * [HAProxy Technologies](https://www.haproxy.com/)는 [쿠버네티스를 위한 HAProxy 인그레스 컨트롤러](https://github.com/haproxytech/kubernetes-ingress)를 지원하고 유지 보수한다. [공식 문서](https://www.haproxy.com/documentation/hapee/1-9r1/traffic-management/kubernetes-ingress-controller/)를 통해 확인할 수 있다. -* [Istio](https://istio.io/)는 인그레스 컨트롤러 기반으로 - [인그레스 트래픽을 제어](https://istio.io/docs/tasks/traffic-management/ingress/). -* [Kong](https://konghq.com/)은 [쿠버네티스를 위한 Kong 인그레스 컨트롤러](https://github.com/Kong/kubernetes-ingress-controller)에 대한 [커뮤니티](https://discuss.konghq.com/c/kubernetes) 또는 [상업적](https://konghq.com/kong-enterprise/) 지원과 유지 보수를 제공한다. -* [NGINX, Inc.](https://www.nginx.com/) 는 [쿠버네티스를 위한 NGINX 인그레스 컨트롤러](https://www.nginx.com/products/nginx/kubernetes-ingress-controller)에 대한 지원과 유지 보수를 제공한다. -* 쿠버네티스 인그레스와 같이 사용 사례를 포함하는 서비스 구성을 위한 [Skipper](https://opensource.zalando.com/skipper/kubernetes/ingress-controller/) HTTP 라우터와 리버스 프록시는 사용자 정의 프록시를 빌드하기 위한 라이브러리로 설계되었다. -* [Traefik](https://github.com/containous/traefik)은 완벽한 기능([암호화](https://letsencrypt.org), secrets, http2, 웹 소켓)을 갖춘 인그레스 컨트롤러로, [Containous](https://containo.us/services)에서 상업적인 지원을 제공한다. +* [Istio](https://istio.io/)는 인그레스 컨트롤러 기반으로 + [인그레스 트래픽을 제어](https://istio.io/docs/tasks/traffic-management/ingress/). +* [Kong](https://konghq.com/)은 [쿠버네티스를 위한 Kong 인그레스 컨트롤러](https://github.com/Kong/kubernetes-ingress-controller)에 대한 + [커뮤니티](https://discuss.konghq.com/c/kubernetes) 또는 + [상업적](https://konghq.com/kong-enterprise/) 지원과 유지 보수를 제공한다. +* [NGINX, Inc.](https://www.nginx.com/)는 + [쿠버네티스를 위한 NGINX 인그레스 컨트롤러](https://www.nginx.com/products/nginx/kubernetes-ingress-controller)에 대한 지원과 유지 보수를 제공한다. +* [Skipper](https://opensource.zalando.com/skipper/kubernetes/ingress-controller/)는 쿠버네티스 인그레스와 같은 유스케이스를 포함하는 서비스 구성을 위한 HTTP 라우터와 리버스 프록시는 사용자 정의 프록시를 빌드하기 위한 라이브러리로 설계되었다. +* [Traefik](https://github.com/containous/traefik)은 + 모든 기능([Let's Encrypt](https://letsencrypt.org), secrets, http2, 웹 소켓)을 갖춘 인그레스 컨트롤러로, + [Containous](https://containo.us/services)에서 상업적인 지원을 제공한다. ## 여러 인그레스 컨트롤러 사용 -하나의 클러스터 내에 [여러 개의 인그레스 컨트롤러](https://git.k8s.io/ingress-nginx/docs/user-guide/multiple-ingress.md#multiple-ingress-controllers)를 배포할 수 있다. 인그레스를 생성할 때, 클러스터 내에 둘 이상의 인그레스 컨트롤러가 존재하는 경우 어떤 인그레스 컨트롤러를 사용해야하는지 표시해주는 적절한 [`ingress.class`](https://git.k8s.io/ingress-gce/docs/faq/README.md#how-do-i-run-multiple-ingress-controllers-in-the-same-cluster) 어노테이션을 각각의 인그레스에 달아야 한다. +하나의 클러스터 내에 [여러 개의 인그레스 컨트롤러](https://git.k8s.io/ingress-nginx/docs/user-guide/multiple-ingress.md#multiple-ingress-controllers)를 배포할 수 있다. +인그레스를 생성할 때, 클러스터 내에 둘 이상의 인그레스 컨트롤러가 존재하는 경우 +어떤 인그레스 컨트롤러를 사용해야 하는지 표시해주는 적절한 [`ingress.class`](https://git.k8s.io/ingress-gce/docs/faq/README.md#how-do-i-run-multiple-ingress-controllers-in-the-same-cluster) +어노테이션을 각각의 인그레스에 달아야 한다. 만약 클래스를 정의하지 않으면, 클라우드 제공자는 기본 인그레스 컨트롤러를 사용할 수 있다. -이상적으로는 모든 인그레스 컨트롤러가 이 사양을 충족해야하지만, 다양한 인그레스 컨트롤러는 약간 다르게 작동한다. +이상적으로는 모든 인그레스 컨트롤러가 이 사양을 충족해야 하지만, +다양한 인그레스 컨트롤러는 약간 다르게 작동한다. {{< note >}} 인그레스 컨트롤러의 설명서를 검토하여 선택 시 주의 사항을 이해해야한다. @@ -58,6 +70,4 @@ kube-controller-manager 바이너리의 일부로 실행되는 컨트롤러의 * [인그레스](/ko/docs/concepts/services-networking/ingress/)에 대해 자세히 알아보기. -* [NGINX 컨트롤러로 Minikube에서 Ingress를 설정하기](/docs/tasks/access-application-cluster/ingress-minikube). - - +* [NGINX 컨트롤러로 Minikube에서 인그레스를 설정하기](/docs/tasks/access-application-cluster/ingress-minikube). diff --git a/content/ko/docs/concepts/services-networking/ingress.md b/content/ko/docs/concepts/services-networking/ingress.md index 968274bc1c..23ab2d1ade 100644 --- a/content/ko/docs/concepts/services-networking/ingress.md +++ b/content/ko/docs/concepts/services-networking/ingress.md @@ -1,5 +1,5 @@ --- -title: 인그레스 +title: 인그레스(Ingress) content_type: concept weight: 40 --- @@ -15,11 +15,11 @@ weight: 40 이 가이드는 용어의 명확성을 위해 다음과 같이 정의한다. -노드(Node): 클러스터의 일부이며, 쿠버네티스에 속한 워커 머신. -클러스터(Cluster): 쿠버네티스에서 관리되는 컨테이너화 된 애플리케이션을 실행하는 노드 집합. 이 예시와 대부분의 일반적인 쿠버네티스 배포에서 클러스터에 속한 노드는 퍼블릭 인터넷의 일부가 아니다. -에지 라우터(Edge router): 클러스터에 방화벽 정책을 적용하는 라우터. 이것은 클라우드 공급자 또는 물리적 하드웨어의 일부에서 관리하는 게이트웨이일 수 있다. -클러스터 네트워크(Cluster network): 쿠버네티스 [네트워킹 모델](/docs/concepts/cluster-administration/networking/)에 따라 클러스터 내부에서 통신을 용이하게 하는 논리적 또는 물리적 링크 집합. -서비스(Service): {{< glossary_tooltip text="레이블" term_id="label" >}} 셀렉터를 사용해서 파드 집합을 식별하는 쿠버네티스 {{< glossary_tooltip term_id="service" >}}. 달리 언급하지 않으면 서비스는 클러스터 네트워크 내에서만 라우팅 가능한 가상 IP를 가지고 있다고 가정한다. +* 노드(Node): 클러스터의 일부이며, 쿠버네티스에 속한 워커 머신. +* 클러스터(Cluster): 쿠버네티스에서 관리되는 컨테이너화 된 애플리케이션을 실행하는 노드 집합. 이 예시와 대부분의 일반적인 쿠버네티스 배포에서 클러스터에 속한 노드는 퍼블릭 인터넷의 일부가 아니다. +* 에지 라우터(Edge router): 클러스터에 방화벽 정책을 적용하는 라우터. 이것은 클라우드 공급자 또는 물리적 하드웨어의 일부에서 관리하는 게이트웨이일 수 있다. +* 클러스터 네트워크(Cluster network): 쿠버네티스 [네트워킹 모델](/ko/docs/concepts/cluster-administration/networking/)에 따라 클러스터 내부에서 통신을 용이하게 하는 논리적 또는 물리적 링크 집합. +* 서비스: {{< glossary_tooltip text="레이블" term_id="label" >}} 셀렉터를 사용해서 파드 집합을 식별하는 쿠버네티스 {{< glossary_tooltip text="서비스" term_id="service" >}}. 달리 언급하지 않으면 서비스는 클러스터 네트워크 내에서만 라우팅 가능한 가상 IP를 가지고 있다고 가정한다. ## 인그레스란? @@ -79,8 +79,8 @@ spec: 다른 모든 쿠버네티스 리소스와 마찬가지로 인그레스에는 `apiVersion`, `kind`, 그리고 `metadata` 필드가 필요하다. 인그레스 오브젝트의 이름은 유효한 -[DNS 서브도메인 이름](/ko/docs/concepts/overview/working-with-objects/names/#dns-서브도메인-이름들)이어야 한다. -설정 파일의 작성에 대한 일반적인 내용은 [애플리케이션 배포하기](/docs/tasks/run-application/run-stateless-application-deployment/), [컨테이너 구성하기](/docs/tasks/configure-pod-container/configure-pod-configmap/), [리소스 관리하기](/docs/concepts/cluster-administration/manage-deployment/)를 참조한다. +[DNS 서브도메인 이름](/ko/docs/concepts/overview/working-with-objects/names/#dns-서브도메인-이름)이어야 한다. +설정 파일의 작성에 대한 일반적인 내용은 [애플리케이션 배포하기](/docs/tasks/run-application/run-stateless-application-deployment/), [컨테이너 구성하기](/docs/tasks/configure-pod-container/configure-pod-configmap/), [리소스 관리하기](/ko/docs/concepts/cluster-administration/manage-deployment/)를 참조한다. 인그레스는 종종 어노테이션을 이용해서 인그레스 컨트롤러에 따라 몇 가지 옵션을 구성하는데, 그 예시는 [재작성-타겟 어노테이션](https://github.com/kubernetes/ingress-nginx/blob/master/docs/examples/rewrite/README.md)이다. 다른 [인그레스 컨트롤러](/ko/docs/concepts/services-networking/ingress-controllers)는 다른 어노테이션을 지원한다. @@ -88,7 +88,7 @@ spec: 인그레스 [사양](https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status) 에는 로드 밸런서 또는 프록시 서버를 구성하는데 필요한 모든 정보가 있다. 가장 중요한 것은, -들어오는 요청과 일치하는 규칙 목록을 포함하는 것이다. 인그레스 리소스는 HTTP 트래픽을 +들어오는 요청과 일치하는 규칙 목록을 포함하는 것이다. 인그레스 리소스는 HTTP(S) 트래픽을 지시하는 규칙만 지원한다. ### 인그레스 규칙 @@ -134,8 +134,7 @@ spec: 요청은 _p_ 경로에 일치한다. {{< note >}} - 경로의 마지막 요소가 요청 경로에 있는 마지막 요소의 하위 문자열인 경우에는 일치하지 않는다(예시: - `/foo/bar` 와 `/foo/bar/baz` 와 일치하지만, `/foo/barbaz` 는 일치하지 않는다). + 경로의 마지막 요소가 요청 경로에 있는 마지막 요소의 하위 문자열인 경우에는 일치하지 않는다(예시: `/foo/bar` 와 `/foo/bar/baz` 와 일치하지만, `/foo/barbaz` 는 일치하지 않는다). {{< /note >}} #### 다중 일치 @@ -216,7 +215,7 @@ NAME HOSTS ADDRESS PORTS AGE test-ingress * 203.0.113.123 80 59s ``` -여기서 `203.0.113.123` 는 인그레스 컨트롤러가 인그레스를 충족시키기 위해 +여기서 `203.0.113.123` 는 인그레스 컨트롤러가 인그레스를 충족시키기 위해 할당한 IP 이다. {{< note >}} @@ -548,4 +547,3 @@ Events: * [인그레스] API](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#ingress-v1beta1-networking-k8s-io)에 대해 배우기 * [인그레스 컨트롤러](/ko/docs/concepts/services-networking/ingress-controllers/)에 대해 배우기 * [NGINX 컨트롤러로 Minikube에서 인그레스 구성하기](/docs/tasks/access-application-cluster/ingress-minikube) - diff --git a/content/ko/docs/concepts/services-networking/network-policies.md b/content/ko/docs/concepts/services-networking/network-policies.md index 55fde3a3be..adcf9f9e9a 100644 --- a/content/ko/docs/concepts/services-networking/network-policies.md +++ b/content/ko/docs/concepts/services-networking/network-policies.md @@ -9,28 +9,28 @@ weight: 50 <!-- overview --> 네트워크 정책은 {{< glossary_tooltip text="파드" term_id="pod">}} 그룹이 서로 간에 또는 다른 네트워크 엔드포인트와 통신할 수 있도록 허용하는 방법에 대한 명세이다. -`NetworkPolicy` 리소스는 {{< glossary_tooltip text="레이블" term_id="label">}}을 사용해서 파드를 선택하고 선택한 파드에 허용되는 트래픽을 지정하는 규칙을 정의한다. +`네트워크폴리시(NetworkPolicy)` 리소스는 {{< glossary_tooltip text="레이블" term_id="label">}}을 사용해서 파드를 선택하고 선택한 파드에 허용되는 트래픽을 지정하는 규칙을 정의한다. <!-- body --> ## 전제 조건 -네트워크 정책은 [네트워크 플러그인](/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/)으로 구현된다. 네트워크 정책을 사용하려면 NetworkPolicy를 지원하는 네트워킹 솔루션을 사용해야만 한다. 이를 구현하는 컨트롤러 없이 NetworkPolicy 리소스를 생성해도 아무런 효과가 없기 때문이다. +네트워크 정책은 [네트워크 플러그인](/ko/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/)으로 구현된다. 네트워크 정책을 사용하려면 네트워크폴리시를 지원하는 네트워킹 솔루션을 사용해야만 한다. 이를 구현하는 컨트롤러 없이 네트워크폴리시 리소스를 생성해도 아무런 효과가 없기 때문이다. ## 격리 및 격리되지 않은 파드 기본적으로, 파드는 격리되지 않는다. 이들은 모든 소스에서 오는 트래픽을 받아들인다. -파드는 파드를 선택한 NetworkPolicy에 의해서 격리된다. 네임스페이스에 특정 파드를 선택하는 NetworkPolicy가 있으면 해당 파드는 NetworkPolicy에서 허용하지 않는 모든 연결을 거부한다. (네임스페이스 내에서 어떠한 NetworkPolicy에도 선택 받지 않은 다른 파드들은 계속해서 모든 트래픽을 받아들인다.) +파드는 파드를 선택한 네트워크폴리시에 의해서 격리된다. 네임스페이스에 특정 파드를 선택하는 네트워크폴리시가 있으면 해당 파드는 네트워크폴리시에서 허용하지 않는 모든 연결을 거부한다. (네임스페이스 내에서 어떠한 네트워크폴리시에도 선택 받지 않은 다른 파드들은 계속해서 모든 트래픽을 받아들인다.) 네트워크 정책은 충돌하지 않으며, 추가된다. 만약 어떤 정책 또는 정책들이 파드를 선택하면, 해당 정책의 인그레스(수신)/이그레스(송신) 규칙을 통합하여 허용되는 범위로 파드가 제한된다. 따라서 평가 순서는 정책 결과에 영향을 미치지 않는다. -## NetworkPolicy 리소스 {#networkpolicy-resource} +## 네트워크폴리시 리소스 {#networkpolicy-resource} -리소스에 대한 전체 정의에 대한 참조는 [NetworkPolicy](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#networkpolicy-v1-networking-k8s-io) 를 본다. +리소스에 대한 전체 정의에 대한 참조는 [네트워크폴리시](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#networkpolicy-v1-networking-k8s-io) 를 본다. -NetworkPolicy 의 예시는 다음과 같다. +네트워크폴리시 의 예시는 다음과 같다. ```yaml apiVersion: networking.k8s.io/v1 @@ -73,23 +73,23 @@ spec: 선택한 네트워킹 솔루션이 네트워킹 정책을 지원하지 않으면 클러스터의 API 서버에 이를 POST 하더라도 효과가 없다. {{< /note >}} -__필수 필드들__: 다른 모든 쿠버네티스 설정과 마찬가지로 NetworkPolicy 에는 +__필수 필드들__: 다른 모든 쿠버네티스 설정과 마찬가지로 네트워크폴리시 에는 `apiVersion`, `kind`, 그리고 `metadata` 필드가 필요하다. 구성 파일 작업에 대한 일반적인 정보는 [컨피그 맵을 사용해서 컨테이너 구성하기](/docs/tasks/configure-pod-container/configure-pod-configmap/), 그리고 [오브젝트 관리](/ko/docs/concepts/overview/working-with-objects/object-management) 를 본다. -__spec__: NetworkPolicy [사양](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-architecture/api-conventions.md#spec-and-status)에는 지정된 네임스페이스에서 특정 네트워크 정책을 정의하는데 필요한 모든 정보가 있다. +__spec__: 네트워크폴리시 [사양](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-architecture/api-conventions.md#spec-and-status)에는 지정된 네임스페이스에서 특정 네트워크 정책을 정의하는데 필요한 모든 정보가 있다. -__podSelector__: 각 NetworkPolicy 에는 정책이 적용되는 파드 그룹을 선택하는 `podSelector` 가 포함된다. 예시 정책은 "role=db" 레이블이 있는 파드를 선택한다. 비어있는 `podSelector` 는 네임스페이스의 모든 파드를 선택한다. +__podSelector__: 각 네트워크폴리시에는 정책이 적용되는 파드 그룹을 선택하는 `podSelector` 가 포함된다. 예시 정책은 "role=db" 레이블이 있는 파드를 선택한다. 비어있는 `podSelector` 는 네임스페이스의 모든 파드를 선택한다. -__policyTypes__: 각 NetworkPolicy 에는 `Ingress`, `Egress` 또는 두 가지 모두를 포함할 수 있는 `policyTypes` 목록이 포함된다. `policyTypes` 필드는 선택한 파드에 대한 인그레스 트래픽 정책, 선택한 파드에 대한 이그레스 트래픽 정책 또는 두 가지 모두에 지정된 정책의 적용 여부를 나타낸다. 만약 NetworkPolicy에 `policyTypes` 가 지정되어 있지 않으면 기본적으로 `Ingress` 가 항상 설정되고, NetworkPolicy에 `Egress` 가 있으면 이그레스 규칙이 설정된다. +__policyTypes__: 각 네트워크폴리시에는 `Ingress`, `Egress` 또는 두 가지 모두를 포함할 수 있는 `policyTypes` 목록이 포함된다. `policyTypes` 필드는 선택한 파드에 대한 인그레스 트래픽 정책, 선택한 파드에 대한 이그레스 트래픽 정책 또는 두 가지 모두에 지정된 정책의 적용 여부를 나타낸다. 만약 네트워크폴리시에 `policyTypes` 가 지정되어 있지 않으면 기본적으로 `Ingress` 가 항상 설정되고, 네트워크폴리시에 `Egress` 가 있으면 이그레스 규칙이 설정된다. -__ingress__: 각 NetworkPolicy 에는 화이트리스트 `ingress` 규칙 목록이 포함될 수 있다. 각 규칙은 `from` 과 `ports` 부분과 모두 일치하는 트래픽을 허용한다. 예시 정책에는 단일 규칙이 포함되어있는데 첫 번째 포트는 `ipBlock` 을 통해 지정되고, 두 번째는 `namespaceSelector` 를 통해 그리고 세 번째는 `podSelector` 를 통해 세 가지 소스 중 하나의 단일 포트에서 발생하는 트래픽과 일치 시킨다. +__ingress__: 각 네트워크폴리시에는 화이트리스트 `ingress` 규칙 목록이 포함될 수 있다. 각 규칙은 `from` 과 `ports` 부분과 모두 일치하는 트래픽을 허용한다. 예시 정책에는 단일 규칙이 포함되어있는데 첫 번째 포트는 `ipBlock` 을 통해 지정되고, 두 번째는 `namespaceSelector` 를 통해 그리고 세 번째는 `podSelector` 를 통해 세 가지 소스 중 하나의 단일 포트에서 발생하는 트래픽과 일치 시킨다. -__egress__: 각 NetworkPolicy 에는 화이트리스트 `egress` 규칙이 포함될 수 있다. 각 규칙은 `to` 와 `ports` 부분과 모두 일치하는 트래픽을 허용한다. 예시 정책에는 단일 포트의 트래픽을 `10.0.0.0/24` 의 모든 대상과 일치시키는 단일 규칙을 포함하고 있다. +__egress__: 각 네트워크폴리시에는 화이트리스트 `egress` 규칙이 포함될 수 있다. 각 규칙은 `to` 와 `ports` 부분과 모두 일치하는 트래픽을 허용한다. 예시 정책에는 단일 포트의 트래픽을 `10.0.0.0/24` 의 모든 대상과 일치시키는 단일 규칙을 포함하고 있다. -따라서 예시의 NetworkPolicy는 다음과 같이 동작한다. +따라서 예시의 네트워크폴리시는 다음과 같이 동작한다. 1. 인그레스 및 이그레스 트래픽에 대해 "default" 네임스페이스에서 "role=db"인 파드를 격리한다(아직 격리되지 않은 경우). 2. (인그레스 규칙)은 "role=db" 레이블을 사용하는 "default" 네임스페이스의 모든 파드에 대해서 TCP 포트 6397로의 연결을 허용한다. 인그레스을 허용 할 대상은 다음과 같다. @@ -99,13 +99,13 @@ __egress__: 각 NetworkPolicy 에는 화이트리스트 `egress` 규칙이 포 * 172.17.0.0–172.17.0.255 와 172.17.2.0–172.17.255.255 의 범위를 가지는 IP 주소(예: 172.17.0.0/16 전체에서 172.17.1.0/24 를 제외) 3. (이그레스 규칙)은 "role=db" 레이블이 있는 "default" 네임스페이스의 모든 파드에서 TCP 포트 5978의 CIDR 10.0.0.0/24 로의 연결을 허용한다. -자세한 설명과 추가 예시는 [네트워크 정책 선언](/docs/tasks/administer-cluster/declare-network-policy/)을 본다. +자세한 설명과 추가 예시는 [네트워크 정책 선언](/ko/docs/tasks/administer-cluster/declare-network-policy/)을 본다. ## `to` 및 `from` 셀럭터의 동작 `ingress` `from` 부분 또는 `egress` `to` 부분에 지정할 수 있는 네 종류의 셀렉터가 있다. -__podSelector__: NetworkPolicy 을 통해서, 인그레스 소스 또는 이그레스 목적지로 허용되야 하는 동일한 네임스페이스에 있는 특정 파드들을 선택한다. +__podSelector__: 네트워크폴리시를 통해서, 인그레스 소스 또는 이그레스 목적지로 허용되야 하는 동일한 네임스페이스에 있는 특정 파드들을 선택한다. __namespaceSelector__: 모든 파드가 인그레스 소스 또는 이그레스를 대상으로 허용되어야 하는 특정 네임스페이스를 선택한다. @@ -146,15 +146,15 @@ __namespaceSelector__ *와* __podSelector__: `namespaceSelector` 와 `podSelecto __ipBlock__: 인그레스 소스 또는 이그레스 대상으로 허용할 IP CIDR 범위를 선택한다. 파드 IP는 임시적이고 예측할 수 없기에 클러스터 외부 IP이어야 한다. 클러스터 인그레스 및 이그레스 매커니즘은 종종 패킷의 소스 또는 대상 IP의 재작성을 -필요로 한다. 이러한 상황이 발생하는 경우, NetworkPolicy의 처리 전 또는 후에 +필요로 한다. 이러한 상황이 발생하는 경우, 네트워크폴리시의 처리 전 또는 후에 발생한 것인지 정의되지 않으며, 네트워크 플러그인, 클라우드 공급자, `서비스` 구현 등의 조합에 따라 동작이 다를 수 있다. -인그레스 사례에서의 의미는 실제 원본 소스 IP를 기준으로 들어오는 패킷을 -필터링할 수 있는 반면에 다른 경우에는 NetworkPolicy가 작동하는 +인그레스 사례에서의 의미는 실제 원본 소스 IP를 기준으로 들어오는 패킷을 +필터링할 수 있는 반면에 다른 경우에는 네트워크폴리시가 작동하는 "소스 IP"는 `LoadBalancer` 또는 파드가 속한 노드 등의 IP일 수 있다. -이그레스의 경우 파드에서 클러스터 외부 IP로 다시 작성된 `서비스` IP로의 연결은 +이그레스의 경우 파드에서 클러스터 외부 IP로 다시 작성된 `서비스` IP로의 연결은 `ipBlock` 기반의 정책의 적용을 받거나 받지 않을 수 있다는 것을 의미한다. ## 기본 정책 @@ -164,11 +164,11 @@ __ipBlock__: 인그레스 소스 또는 이그레스 대상으로 허용할 IP C ### 기본적으로 모든 인그레스 트래픽 거부 -모든 파드를 선택하지만 해당 파드에 대한 인그레스 트래픽은 허용하지 않는 NetworkPolicy를 생성해서 네임스페이스에 대한 "기본" 격리 정책을 생성할 수 있다. +모든 파드를 선택하지만 해당 파드에 대한 인그레스 트래픽은 허용하지 않는 네트워크폴리시를 생성해서 네임스페이스에 대한 "기본" 격리 정책을 생성할 수 있다. {{< codenew file="service/networking/network-policy-default-deny-ingress.yaml" >}} -이렇게 하면 다른 NetworkPolicy에서 선택하지 않은 파드도 여전히 격리된다. 이 정책은 기본 이그레스 격리 동작을 변경하지 않는다. +이렇게 하면 다른 네트워크폴리시에서 선택하지 않은 파드도 여전히 격리된다. 이 정책은 기본 이그레스 격리 동작을 변경하지 않는다. ### 기본적으로 모든 인그레스 트래픽 허용 @@ -178,11 +178,11 @@ __ipBlock__: 인그레스 소스 또는 이그레스 대상으로 허용할 IP C ### 기본적으로 모든 이그레스 트래픽 거부 -모든 파드를 선택하지만, 해당 파드의 이그레스 트래픽을 허용하지 않는 NetworkPolicy를 생성해서 네임스페이스에 대한 "기본" 이그레스 격리 정책을 생성할 수 있다. +모든 파드를 선택하지만, 해당 파드의 이그레스 트래픽을 허용하지 않는 네트워크폴리시를 생성해서 네임스페이스에 대한 "기본" 이그레스 격리 정책을 생성할 수 있다. {{< codenew file="service/networking/network-policy-default-deny-egress.yaml" >}} -이렇게 하면 다른 NetworkPolicy에서 선택하지 않은 파드조차도 이그레스 트래픽을 허용하지 않는다. 이 정책은 +이렇게 하면 다른 네트워크폴리시에서 선택하지 않은 파드조차도 이그레스 트래픽을 허용하지 않는다. 이 정책은 기본 인그레스 격리 정책을 변경하지 않는다. ### 기본적으로 모든 이그레스 트래픽 허용 @@ -193,21 +193,21 @@ __ipBlock__: 인그레스 소스 또는 이그레스 대상으로 허용할 IP C ### 기본적으로 모든 인그레스와 모든 이그레스 트래픽 거부 -해당 네임스페이스에 아래의 NetworkPolicy를 만들어 모든 인그레스와 이그레스 트래픽을 방지하는 네임스페이스에 대한 "기본" 정책을 만들 수 있다. +해당 네임스페이스에 아래의 네트워크폴리시를 만들어 모든 인그레스와 이그레스 트래픽을 방지하는 네임스페이스에 대한 "기본" 정책을 만들 수 있다. {{< codenew file="service/networking/network-policy-default-deny-all.yaml" >}} -이렇게 하면 다른 NetworkPolicy에서 선택하지 않은 파드도 인그레스 또는 이그레스 트래픽을 허용하지 않는다. +이렇게 하면 다른 네트워크폴리시에서 선택하지 않은 파드도 인그레스 또는 이그레스 트래픽을 허용하지 않는다. ## SCTP 지원 {{< feature-state for_k8s_version="v1.12" state="alpha" >}} -이 기능을 사용하려면 사용자(또는 클러스터 관리자가) API 서버에 `--feature-gates=SCTPSupport=true,…` 를 사용해서 `SCTPSupport` [기능 게이트](/docs/reference/command-line-tools-reference/feature-gates/)를 활성화 해야 한다. -기능 게이트가 활셩화 되면, NetworkPolicy의 `protocol` 필드를 `SCTP` 로 설정할 수 있다. +이 기능을 사용하려면 사용자(또는 클러스터 관리자가) API 서버에 `--feature-gates=SCTPSupport=true,…` 를 사용해서 `SCTPSupport` [기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)를 활성화 해야 한다. +기능 게이트가 활셩화 되면, 네트워크폴리시의 `protocol` 필드를 `SCTP` 로 설정할 수 있다. {{< note >}} -SCTP 프로토콜 NetworkPolicy을 지원하는 {{< glossary_tooltip text="CNI" term_id="cni" >}} 플러그인을 사용하고 있어야 한다. +SCTP 프로토콜 네트워크폴리시를 지원하는 {{< glossary_tooltip text="CNI" term_id="cni" >}} 플러그인을 사용하고 있어야 한다. {{< /note >}} @@ -217,7 +217,5 @@ SCTP 프로토콜 NetworkPolicy을 지원하는 {{< glossary_tooltip text="CNI" - 자세한 설명과 추가 예시는 - [네트워크 정책 선언](/docs/tasks/administer-cluster/declare-network-policy/)을 본다. -- NetworkPolicy 리소스에서 사용되는 일반적인 시나리오는 [레시피](https://github.com/ahmetb/kubernetes-network-policy-recipes)를 본다. - - + [네트워크 정책 선언](/ko/docs/tasks/administer-cluster/declare-network-policy/)을 본다. +- 네트워크폴리시 리소스에서 사용되는 일반적인 시나리오는 [레시피](https://github.com/ahmetb/kubernetes-network-policy-recipes)를 본다. diff --git a/content/ko/docs/concepts/services-networking/service-topology.md b/content/ko/docs/concepts/services-networking/service-topology.md index da419f76e4..567b998791 100644 --- a/content/ko/docs/concepts/services-networking/service-topology.md +++ b/content/ko/docs/concepts/services-networking/service-topology.md @@ -194,7 +194,7 @@ spec: ## {{% heading "whatsnext" %}} -* [서비스 토폴로지 활성화하기](/docs/tasks/administer-cluster/enabling-service-topology)를 읽는다. -* [서비스와 애플리케이션 연결하기](/ko/docs/concepts/services-networking/connect-applications-service/)를 읽는다. +* [서비스 토폴로지 활성화하기](/docs/tasks/administer-cluster/enabling-service-topology)를 읽어보기. +* [서비스와 애플리케이션 연결하기](/ko/docs/concepts/services-networking/connect-applications-service/)를 읽어보기. diff --git a/content/ko/docs/concepts/services-networking/service.md b/content/ko/docs/concepts/services-networking/service.md index e1e0d28c7c..429708e4bf 100644 --- a/content/ko/docs/concepts/services-networking/service.md +++ b/content/ko/docs/concepts/services-networking/service.md @@ -10,8 +10,6 @@ weight: 10 --- - - <!-- overview --> {{< glossary_definition term_id="service" length="short" >}} @@ -74,7 +72,7 @@ _서비스_ 로 들어가보자. 마찬가지로, 서비스 정의를 API 서버에 `POST`하여 새 인스턴스를 생성할 수 있다. 서비스 오브젝트의 이름은 유효한 -[DNS 서브도메인 이름](/ko/docs/concepts/overview/working-with-objects/names/#dns-서브도메인-이름들)이어야 한다. +[DNS 서브도메인 이름](/ko/docs/concepts/overview/working-with-objects/names/#dns-서브도메인-이름)이어야 한다. 예를 들어, 각각 TCP 포트 9376에서 수신하고 `app=MyApp` 레이블을 가지고 있는 파드 세트가 있다고 가정해 보자. @@ -170,7 +168,7 @@ subsets: ``` 엔드포인트 오브젝트의 이름은 유효한 -[DNS 서브도메인 이름](/ko/docs/concepts/overview/working-with-objects/names/#dns-서브도메인-이름들)이어야 한다. +[DNS 서브도메인 이름](/ko/docs/concepts/overview/working-with-objects/names/#dns-서브도메인-이름)이어야 한다. {{< note >}} 엔드포인트 IP는 루프백(loopback) (IPv4의 경우 127.0.0.0/8, IPv6의 경우 ::1/128), 또는 @@ -210,7 +208,7 @@ AppProtocol 필드는 각 서비스 포트에 사용될 애플리케이션 프 지정하는 방법을 제공한다. 알파 기능으로 이 필드는 기본적으로 활성화되어 있지 않다. 이 필드를 사용하려면, -[기능 게이트](/docs/reference/command-line-tools-reference/feature-gates/)에서 +[기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)에서 `ServiceAppProtocol` 을 활성화해야 한다. ## 가상 IP와 서비스 프록시 @@ -242,7 +240,8 @@ DNS 레코드를 구성하고, 라운드-로빈 이름 확인 방식을 추가와 제거를 감시한다. 각 서비스는 로컬 노드에서 포트(임의로 선택됨)를 연다. 이 "프록시 포트"에 대한 모든 연결은 (엔드포인트를 통해 보고된대로) 서비스의 백엔드 파드 중 하나로 -프록시된다. kube-proxy는 사용할 백엔드 파드를 결정할 때 서비스의 +프록시된다. +kube-proxy는 사용할 백엔드 파드를 결정할 때 서비스의 `SessionAffinity` 설정을 고려한다. 마지막으로, 유저-스페이스 프록시는 서비스의 @@ -273,7 +272,7 @@ kube-proxy가 iptables 모드에서 실행 중이고 선택된 첫 번째 파드 다르다. 해당 시나리오에서는, kube-proxy는 첫 번째 파드에 대한 연결이 실패했음을 감지하고 다른 백엔드 파드로 자동으로 재시도한다. -파드 [준비성 프로브(readiness probe)](/ko/docs/concepts/workloads/pods/pod-lifecycle/#container-probes)를 사용하여 +파드 [준비성 프로브(readiness probe)](/ko/docs/concepts/workloads/pods/pod-lifecycle/#컨테이너-프로브-probe)를 사용하여 백엔드 파드가 제대로 작동하는지 확인할 수 있으므로, iptables 모드의 kube-proxy는 정상으로 테스트된 백엔드만 볼 수 있다. 이렇게 하면 트래픽이 kube-proxy를 통해 실패한 것으로 알려진 파드로 전송되는 것을 막을 수 있다. @@ -419,7 +418,7 @@ DNS 만 사용하여 서비스의 클러스터 IP를 검색하는 경우, 이 ### DNS -[애드-온](/docs/concepts/cluster-administration/addons/)을 사용하여 쿠버네티스 +[애드-온](/ko/docs/concepts/cluster-administration/addons/)을 사용하여 쿠버네티스 클러스터의 DNS 서비스를 설정할 수(대개는 필수적임) 있다. CoreDNS와 같은, 클러스터-인식 DNS 서버는 새로운 서비스를 위해 쿠버네티스 API를 감시하고 @@ -497,15 +496,15 @@ API에서 `엔드포인트` 레코드를 생성하고, DNS 구성을 수정하 서비스를 외부에 노출시킨다. 외부 로드 밸런서가 라우팅되는 `NodePort`와 `ClusterIP` 서비스가 자동으로 생성된다. * [`ExternalName`](#externalname): 값과 함께 CNAME 레코드를 리턴하여, 서비스를 - `externalName` 필드의 컨텐츠 (예:`foo.bar.example.com`)에 - 맵핑한다. 어떤 종류의 프록시도 설정되어 있지 않다. + `externalName` 필드의 콘텐츠 (예:`foo.bar.example.com`)에 + 매핑한다. + 어떤 종류의 프록시도 설정되어 있지 않다. {{< note >}} `ExternalName` 유형을 사용하려면 kube-dns 버전 1.7 또는 CoreDNS 버전 1.7 이상이 필요하다. {{< /note >}} [인그레스](/ko/docs/concepts/services-networking/ingress/)를 사용하여 서비스를 노출시킬 수도 있다. 인그레스는 서비스 유형이 아니지만, 클러스터의 진입점 역할을 한다. 동일한 IP 주소로 여러 서비스를 노출시킬 수 있기 때문에 라우팅 규칙을 단일 리소스로 통합할 수 있다. - ### NodePort 유형 {#nodeport} `type` 필드를 `NodePort`로 설정하면, 쿠버네티스 컨트롤 플레인은 @@ -686,7 +685,7 @@ metadata: ```yaml [...] metadata: - annotations: + annotations: service.kubernetes.io/qcloud-loadbalancer-internal-subnetid: subnet-xxxxx [...] ``` @@ -1095,7 +1094,7 @@ IP 주소를 정리한다. 실제로 고정된 목적지로 라우팅되는 파드 IP 주소와 달리, 서비스 IP는 실제로 단일 호스트에서 응답하지 않는다. 대신에, kube-proxy는 -iptables (Linux의 패킷 처리 로직)를 필요에 따라 +iptables (리눅스의 패킷 처리 로직)를 필요에 따라 명백하게 리다이렉션되는 _가상_ IP 주소를 정의하기 위해 사용한다. 클라이언트가 VIP에 연결하면, 트래픽이 자동으로 적절한 엔드포인트로 전송된다. 환경 변수와 서비스 용 DNS는 실제로 서비스의 @@ -1177,7 +1176,7 @@ HTTP / HTTPS 서비스를 노출할 수도 있다. ### PROXY 프로토콜 -클라우드 공급자가 지원하는 경우에 (예: [AWS](/docs/concepts/cluster-administration/cloud-providers/#aws)), +클라우드 공급자가 지원하는 경우에 (예: [AWS](/ko/docs/concepts/cluster-administration/cloud-providers/#aws)), LoadBalancer 모드의 서비스를 사용하여 쿠버네티스 자체 외부에 로드 밸런서를 구성할 수 있으며, 이때 접두사가 [PROXY 프로토콜](https://www.haproxy.org/download/1.8/doc/proxy-protocol.txt) 인 연결을 전달하게 된다. @@ -1214,10 +1213,10 @@ PROXY TCP4 192.0.2.202 10.0.42.7 12345 7\r\n 클라우드 공급자의 로드 밸런서 구현이 프로토콜로서 SCTP를 지원하는 경우에만 LoadBalancer `유형`과 SCTP `프로토콜`을 사용하여 서비스를 생성할 수 있다. 그렇지 않으면, 서비스 생성 요청이 거부된다. 현재 클라우드 로드 밸런서 공급자 세트 (Azure, AWS, CloudStack, GCE, OpenStack)는 모두 SCTP에 대한 지원이 없다. {{< /warning >}} -##### Windows {#caveat-sctp-windows-os} +##### 윈도우 {#caveat-sctp-windows-os} {{< warning >}} -SCTP는 Windows 기반 노드를 지원하지 않는다. +SCTP는 윈도우 기반 노드를 지원하지 않는다. {{< /warning >}} ##### 유저스페이스 kube-proxy {#caveat-sctp-kube-proxy-userspace} @@ -1234,5 +1233,3 @@ kube-proxy는 유저스페이스 모드에 있을 때 SCTP 연결 관리를 지 * [서비스와 애플리케이션 연결](/ko/docs/concepts/services-networking/connect-applications-service/) 알아보기 * [인그레스](/ko/docs/concepts/services-networking/ingress/)에 대해 알아보기 * [엔드포인트슬라이스](/ko/docs/concepts/services-networking/endpoint-slices/)에 대해 알아보기 - - diff --git a/content/ko/docs/concepts/storage/_index.md b/content/ko/docs/concepts/storage/_index.md index 1e0fb99a5d..dc9ae5cd82 100644 --- a/content/ko/docs/concepts/storage/_index.md +++ b/content/ko/docs/concepts/storage/_index.md @@ -1,5 +1,6 @@ --- title: "스토리지" weight: 70 +description: > + 클러스터의 파드에 장기(long-term) 및 임시 스토리지를 모두 제공하는 방법 --- - diff --git a/content/ko/docs/concepts/storage/dynamic-provisioning.md b/content/ko/docs/concepts/storage/dynamic-provisioning.md index bf0b257dbf..87ce9c9d27 100644 --- a/content/ko/docs/concepts/storage/dynamic-provisioning.md +++ b/content/ko/docs/concepts/storage/dynamic-provisioning.md @@ -29,19 +29,19 @@ API 오브젝트를 기반으로 한다. 클러스터 관리자는 볼륨을 프 클러스터 관리자는 클러스터 내에서 사용자 정의 파라미터 집합을 사용해서 여러 가지 유형의 스토리지 (같거나 다른 스토리지 시스템들)를 정의하고 노출시킬 수 있다. 또한 이 디자인을 통해 최종 사용자는 -스토리지 프로비전 방식의 복잡성과 뉘앙스에 대해 걱정할 필요가 없다. 하지만, +스토리지 프로비전 방식의 복잡성과 뉘앙스에 대해 걱정할 필요가 없다. 하지만, 여전히 여러 스토리지 옵션들을 선택할 수 있다. -스토리지 클래스에 대한 자세한 정보는 -[여기](/docs/concepts/storage/storage-classes/)에서 찾을 수 있다. +스토리지 클래스에 대한 자세한 정보는 +[여기](/ko/docs/concepts/storage/storage-classes/)에서 찾을 수 있다. ## 동적 프로비저닝 활성화하기 -동적 프로비저닝을 활성화하려면 클러스터 관리자가 사용자를 위해 하나 이상의 StorageClass +동적 프로비저닝을 활성화하려면 클러스터 관리자가 사용자를 위해 하나 이상의 스토리지클래스(StorageClass) 오브젝트를 사전 생성해야 한다. -StorageClass 오브젝트는 동적 프로비저닝이 호출될 때 사용할 프로비저너와 +스토리지클래스 오브젝트는 동적 프로비저닝이 호출될 때 사용할 프로비저너와 해당 프로비저너에게 전달할 파라미터를 정의한다. -StorageClass 오브젝트의 이름은 유효한 +스토리지클래스 오브젝트의 이름은 유효한 [DNS 서브도메인 이름](/ko/docs/concepts/overview/working-with-objects/names/#dns-서브도메인-이름)이어야 한다. 다음 매니페스트는 표준 디스크와 같은 퍼시스턴트 디스크를 프로비전하는 @@ -117,7 +117,7 @@ spec: 작성하면, `DefaultStorageClass` 어드미션 컨트롤러가 디폴트 스토리지 클래스를 가리키는 `storageClassName` 필드를 자동으로 추가한다. -클러스터에는 최대 하나의 *default* 스토리지 클래스가 있을 수 있다. 그렇지 않은 경우 +클러스터에는 최대 하나의 *default* 스토리지 클래스가 있을 수 있다. 그렇지 않은 경우 `storageClassName` 을 명시적으로 지정하지 않은 `PersistentVolumeClaim` 을 생성할 수 없다. @@ -125,7 +125,6 @@ spec: [다중 영역](/ko/docs/setup/best-practices/multiple-zones/) 클러스터에서 파드는 한 지역 내 여러 영역에 걸쳐 분산될 수 있다. 파드가 예약된 영역에서 단일 영역 스토리지 백엔드를 -프로비전 해야 한다. [볼륨 바인딩 모드](/docs/concepts/storage/storage-classes/#volume-binding-mode)를 +프로비전해야 한다. [볼륨 바인딩 모드](/ko/docs/concepts/storage/storage-classes/#볼륨-바인딩-모드)를 설정해서 수행할 수 있다. - diff --git a/content/ko/docs/concepts/storage/persistent-volumes.md b/content/ko/docs/concepts/storage/persistent-volumes.md index 397041842b..c5a09d23e9 100644 --- a/content/ko/docs/concepts/storage/persistent-volumes.md +++ b/content/ko/docs/concepts/storage/persistent-volumes.md @@ -22,9 +22,9 @@ weight: 20 스토리지 관리는 컴퓨트 인스턴스 관리와는 별개의 문제다. 퍼시스턴트볼륨 서브시스템은 사용자 및 관리자에게 스토리지 사용 방법에서부터 스토리지가 제공되는 방법에 대한 세부 사항을 추상화하는 API를 제공한다. 이를 위해 퍼시스턴트볼륨 및 퍼시스턴트볼륨클레임이라는 두 가지 새로운 API 리소스를 소개한다. -_퍼시스턴트볼륨_ (PV)은 관리자가 프로비저닝하거나 [스토리지 클래스](/docs/concepts/storage/storage-classes/)를 사용하여 동적으로 프로비저닝한 클러스터의 스토리지이다. 노드가 클러스터 리소스인 것처럼 PV는 클러스터 리소스이다. PV는 Volumes와 같은 볼륨 플러그인이지만, PV를 사용하는 개별 파드와는 별개의 라이프사이클을 가진다. 이 API 오브젝트는 NFS, iSCSI 또는 클라우드 공급자별 스토리지 시스템 등 스토리지 구현에 대한 세부 정보를 담아낸다. +_퍼시스턴트볼륨_ (PV)은 관리자가 프로비저닝하거나 [스토리지 클래스](/ko/docs/concepts/storage/storage-classes/)를 사용하여 동적으로 프로비저닝한 클러스터의 스토리지이다. 노드가 클러스터 리소스인 것처럼 PV는 클러스터 리소스이다. PV는 Volumes와 같은 볼륨 플러그인이지만, PV를 사용하는 개별 파드와는 별개의 라이프사이클을 가진다. 이 API 오브젝트는 NFS, iSCSI 또는 클라우드 공급자별 스토리지 시스템 등 스토리지 구현에 대한 세부 정보를 담아낸다. -_퍼시스턴트볼륨클레임_ (PVC)은 사용자의 스토리지에 대한 요청이다. 파드와 비슷하다. 파드는 노드 리소스를 사용하고 PVC는 PV 리소스를 사용한다. 파드는 특정 수준의 리소스(CPU 및 메모리)를 요청할 수 있다. 클레임은 특정 크기 및 접근 모드를 요청할 수 있다(예: 한 번 읽기/쓰기 또는 여러 번 읽기 전용으로 마운트 할 수 있음). +_퍼시스턴트볼륨클레임_ (PVC)은 사용자의 스토리지에 대한 요청이다. 파드와 비슷하다. 파드는 노드 리소스를 사용하고 PVC는 PV 리소스를 사용한다. 파드는 특정 수준의 리소스(CPU 및 메모리)를 요청할 수 있다. 클레임은 특정 크기 및 접근 모드를 요청할 수 있다(예: ReadWriteOnce, ReadOnlyMany 또는 ReadWriteMany로 마운트 할 수 있음. [AccessModes](#접근-모드) 참고). 퍼시스턴트볼륨클레임을 사용하면 사용자가 추상화된 스토리지 리소스를 사용할 수 있지만, 다른 문제들 때문에 성능과 같은 다양한 속성을 가진 퍼시스턴트볼륨이 필요한 경우가 일반적이다. 클러스터 관리자는 사용자에게 해당 볼륨의 구현 방법에 대한 세부 정보를 제공하지 않고 단순히 크기와 접근 모드와는 다른 방식으로 다양한 퍼시스턴트볼륨을 제공할 수 있어야 한다. 이러한 요구에는 _스토리지클래스_ 리소스가 있다. @@ -47,7 +47,7 @@ PV를 프로비저닝 할 수 있는 두 가지 방법이 있다: 정적(static) 관리자가 생성한 정적 PV가 사용자의 퍼시스턴트볼륨클레임과 일치하지 않으면 클러스터는 PVC를 위해 특별히 볼륨을 동적으로 프로비저닝 하려고 시도할 수 있다. 이 프로비저닝은 스토리지클래스를 기반으로 한다. PVC는 -[스토리지 클래스](/docs/concepts/storage/storage-classes/)를 +[스토리지 클래스](/ko/docs/concepts/storage/storage-classes/)를 요청해야 하며 관리자는 동적 프로비저닝이 발생하도록 해당 클래스를 생성하고 구성해야 한다. `""` 클래스를 요청하는 클레임은 동적 프로비저닝을 효과적으로 비활성화한다. @@ -132,7 +132,7 @@ Events: <none> #### Delete(삭제) -`Delete` 반환 정책을 지원하는 볼륨 플러그인의 경우, 삭제는 쿠버네티스에서 퍼시스턴트볼륨 오브젝트와 외부 인프라(예: AWS EBS, GCE PD, Azure Disk 또는 Cinder 볼륨)의 관련 스토리지 자산을 모두 삭제한다. 동적으로 프로비저닝된 볼륨은 [스토리지클래스의 반환 정책](#반환-정책)을 상속하며 기본값은 `Delete`이다. 관리자는 사용자의 기대에 따라 스토리지클래스를 구성해야 한다. 그렇지 않으면 PV를 생성한 후 PV를 수정하거나 패치해야 한다. [퍼시스턴트볼륨의 반환 정책 변경](/docs/tasks/administer-cluster/change-pv-reclaim-policy/)을 참고하길 바란다. +`Delete` 반환 정책을 지원하는 볼륨 플러그인의 경우, 삭제는 쿠버네티스에서 퍼시스턴트볼륨 오브젝트와 외부 인프라(예: AWS EBS, GCE PD, Azure Disk 또는 Cinder 볼륨)의 관련 스토리지 자산을 모두 삭제한다. 동적으로 프로비저닝된 볼륨은 [스토리지클래스의 반환 정책](#반환-정책)을 상속하며 기본값은 `Delete`이다. 관리자는 사용자의 기대에 따라 스토리지클래스를 구성해야 한다. 그렇지 않으면 PV를 생성한 후 PV를 수정하거나 패치해야 한다. [퍼시스턴트볼륨의 반환 정책 변경](/ko/docs/tasks/administer-cluster/change-pv-reclaim-policy/)을 참고하길 바란다. #### Recycle(재활용) @@ -228,7 +228,7 @@ FlexVolume은 파드 재시작 시 크기를 조정할 수 있다. {{< feature-state for_k8s_version="v1.15" state="beta" >}} {{< note >}} -사용 중인 PVC 확장은 쿠버네티스 1.15 이후 버전에서는 베타로, 1.11 이후 버전에서는 알파로 제공된다. `ExpandInUsePersistentVolumes` 기능을 사용하도록 설정해야 한다. 베타 기능의 경우 여러 클러스터에서 자동으로 적용된다. 자세한 내용은 [기능 게이트](/docs/reference/command-line-tools-reference/feature-gates/) 문서를 참고한다. +사용 중인 PVC 확장은 쿠버네티스 1.15 이후 버전에서는 베타로, 1.11 이후 버전에서는 알파로 제공된다. `ExpandInUsePersistentVolumes` 기능을 사용하도록 설정해야 한다. 베타 기능의 경우 여러 클러스터에서 자동으로 적용된다. 자세한 내용은 [기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/) 문서를 참고한다. {{< /note >}} 이 경우 기존 PVC를 사용하는 파드 또는 디플로이먼트를 삭제하고 다시 만들 필요가 없다. @@ -244,7 +244,7 @@ FlexVolume의 크기 조정은 기본 드라이버가 크기 조정을 지원하 {{< /note >}} {{< note >}} -EBS 볼륨 확장은 시간이 많이 걸리는 작업이다. 또한 6시간마다 한 번의 수정을 할 수 있는 볼륨별 쿼터(quota)가 있다. +EBS 볼륨 확장은 시간이 많이 걸리는 작업이다. 또한 6시간마다 한 번의 수정을 할 수 있는 볼륨별 쿼터가 있다. {{< /note >}} @@ -277,7 +277,7 @@ EBS 볼륨 확장은 시간이 많이 걸리는 작업이다. 또한 6시간마 각 PV에는 스펙과 상태(볼륨의 명세와 상태)가 포함된다. 퍼시스턴트볼륨 오브젝트의 이름은 유효한 -[DNS 서브도메인 이름](/ko/docs/concepts/overview/working-with-objects/names/#dns-서브도메인-이름들)이어야 한다. +[DNS 서브도메인 이름](/ko/docs/concepts/overview/working-with-objects/names/#dns-서브도메인-이름)이어야 한다. ```yaml apiVersion: v1 @@ -376,7 +376,7 @@ CLI에서 접근 모드는 다음과 같이 약어로 표시된다. ### 클래스 PV는 `storageClassName` 속성을 -[스토리지클래스](/docs/concepts/storage/storage-classes/)의 +[스토리지클래스](/ko/docs/concepts/storage/storage-classes/)의 이름으로 설정하여 지정하는 클래스를 가질 수 있다. 특정 클래스의 PV는 해당 클래스를 요청하는 PVC에만 바인딩될 수 있다. `storageClassName`이 없는 PV에는 클래스가 없으며 특정 클래스를 요청하지 않는 PVC에만 @@ -449,8 +449,7 @@ CLI는 PV에 바인딩된 PVC의 이름을 표시한다. 각 PVC에는 스펙과 상태(클레임의 명세와 상태)가 포함된다. 퍼시스턴트볼륨클레임 오브젝트의 이름은 유효한 -[DNS 서브도메인 이름](/ko/docs/concepts/overview/working-with-objects/names/#dns-서브도메인-이름들)이어야 -한다. +[DNS 서브도메인 이름](/ko/docs/concepts/overview/working-with-objects/names/#dns-서브도메인-이름)이어야 한다. ```yaml apiVersion: v1 @@ -496,7 +495,7 @@ spec: ### 클래스 클레임은 `storageClassName` 속성을 사용하여 -[스토리지클래스](/docs/concepts/storage/storage-classes/)의 이름을 지정하여 +[스토리지클래스](/ko/docs/concepts/storage/storage-classes/)의 이름을 지정하여 특정 클래스를 요청할 수 있다. 요청된 클래스의 PV(PVC와 동일한 `storageClassName`을 갖는 PV)만 PVC에 바인딩될 수 있다. @@ -668,7 +667,7 @@ spec: {{< feature-state for_k8s_version="v1.17" state="beta" >}} -CSI 볼륨 플러그인만 지원하도록 볼륨 스냅샷 기능이 추가되었다. 자세한 내용은 [볼륨 스냅샷](/docs/concepts/storage/volume-snapshots/)을 참고한다. +CSI 볼륨 플러그인만 지원하도록 볼륨 스냅샷 기능이 추가되었다. 자세한 내용은 [볼륨 스냅샷](/ko/docs/concepts/storage/volume-snapshots/)을 참고한다. 볼륨 스냅샷 데이터 소스에서 볼륨 복원을 지원하려면 apiserver와 controller-manager에서 `VolumeSnapshotDataSource` 기능 게이트를 활성화한다. @@ -747,7 +746,7 @@ spec: * [퍼시스턴트볼륨 생성](/docs/tasks/configure-pod-container/configure-persistent-volume-storage/#create-a-persistentvolume)에 대해 자세히 알아보기 * [퍼시스턴트볼륨클레임 생성](/docs/tasks/configure-pod-container/configure-persistent-volume-storage/#create-a-persistentvolumeclaim)에 대해 자세히 알아보기 -* [퍼시스턴트 스토리지 설계 문서](https://git.k8s.io/community/contributors/design-proposals/storage/persistent-storage.md) 읽기 +* [퍼시스턴트 스토리지 설계 문서](https://git.k8s.io/community/contributors/design-proposals/storage/persistent-storage.md) 읽어보기 ### 참고 @@ -755,4 +754,3 @@ spec: * [PersistentVolumeSpec](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#persistentvolumespec-v1-core) * [퍼시스턴트볼륨클레임](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#persistentvolumeclaim-v1-core) * [PersistentVolumeClaimSpec](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#persistentvolumeclaimspec-v1-core) - diff --git a/content/ko/docs/concepts/storage/storage-classes.md b/content/ko/docs/concepts/storage/storage-classes.md index e73d886ef7..7df975db14 100644 --- a/content/ko/docs/concepts/storage/storage-classes.md +++ b/content/ko/docs/concepts/storage/storage-classes.md @@ -34,9 +34,9 @@ weight: 30 처음 생성할 때 클래스의 이름과 기타 파라미터를 설정하며, 일단 생성된 오브젝트는 업데이트할 수 없다. -관리자는 특정 클래스에 바인딩을 요청하지 않는 PVC에 대해서만 기본 +관리자는 특정 클래스에 바인딩을 요청하지 않는 PVC에 대해서만 기본 스토리지클래스를 지정할 수 있다. 자세한 내용은 -[퍼시스턴트볼륨클레임 섹션](/ko/docs/concepts/storage/persistent-volumes/#클래스-1)을 +[퍼시스턴트볼륨클레임 섹션](/ko/docs/concepts/storage/persistent-volumes/#퍼시스턴트볼륨클레임)을 본다. ```yaml @@ -162,12 +162,12 @@ CSI | 1.14 (alpha), 1.16 (beta) 클러스터 관리자는 `WaitForFirstConsumer` 모드를 지정해서 이 문제를 해결할 수 있는데 이 모드는 퍼시스턴트볼륨클레임을 사용하는 파드가 생성될 때까지 퍼시스턴트볼륨의 바인딩과 프로비저닝을 지연시킨다. 퍼시스턴트볼륨은 파드의 스케줄링 제약 조건에 의해 지정된 토폴로지에 -따라 선택되거나 프로비전된다. 여기에는 [리소스 -요구 사항](/docs/concepts/configuration/manage-compute-resources-container/), +따라 선택되거나 프로비전된다. 여기에는 +[리소스 요구 사항](/ko/docs/concepts/configuration/manage-resources-containers/), [노드 셀렉터](/ko/docs/concepts/scheduling-eviction/assign-pod-node/#노드-셀렉터-nodeselector), [파드 어피니티(affinity)와 안티-어피니티(anti-affinity)](/ko/docs/concepts/scheduling-eviction/assign-pod-node/#어피니티-affinity-와-안티-어피니티-anti-affinity) -그리고 [테인트(taint)와 톨러레이션(toleration)](/docs/concepts/configuration/taint-and-toleration/)이 포함된다. +그리고 [테인트(taint)와 톨러레이션(toleration)](/ko/docs/concepts/scheduling-eviction/taint-and-toleration/)이 포함된다. 다음 플러그인은 동적 프로비저닝과 `WaitForFirstConsumer` 를 지원한다. @@ -251,11 +251,11 @@ parameters: * `iopsPerGB`: `io1` 볼륨 전용이다. 1초당 GiB에 대한 I/O 작업 수이다. AWS 볼륨 플러그인은 요청된 볼륨 크기에 곱셈하여 볼륨의 IOPS를 계산하고 이를 20,000 IOPS로 제한한다(AWS에서 지원하는 최대값으로, - [AWS 문서](https://docs.aws.amazon.com/ko_kr/AWSEC2/latest/UserGuide/ebs-volume-types.html)를 본다). + [AWS 문서](https://docs.aws.amazon.com/ko_kr/AWSEC2/latest/UserGuide/ebs-volume-types.html)를 본다). 여기에는 문자열, 즉 `10` 이 아닌, `"10"` 이 필요하다. * `fsType`: fsType은 쿠버네티스에서 지원된다. 기본값: `"ext4"`. * `encrypted`: EBS 볼륨의 암호화 여부를 나타낸다. - 유효한 값은 `"ture"` 또는 `"false"` 이다. 여기에는 문자열, + 유효한 값은 `"ture"` 또는 `"false"` 이다. 여기에는 문자열, 즉 `true` 가 아닌, `"true"` 가 필요하다. * `kmsKeyId`: 선택 사항. 볼륨을 암호화할 때 사용할 키의 전체 Amazon 리소스 이름이다. 아무것도 제공되지 않지만, `encrypted` 가 true라면 @@ -348,7 +348,7 @@ parameters: * `secretNamespace`, `secretName` : Gluster REST 서비스와 통신할 때 사용할 사용자 암호가 포함된 시크릿 인스턴스를 식별한다. 이 파라미터는 선택 사항으로 `secretNamespace` 와 `secretName` 을 모두 생략하면 - 빈 암호가 사용된다. 제공된 시크릿은 `"kubernetes.io/glusterfs"` 유형이어야 + 빈 암호가 사용된다. 제공된 시크릿은 `"kubernetes.io/glusterfs"` 유형이어야 하며, 예를 들어 다음과 같이 생성한다. ``` @@ -664,7 +664,7 @@ parameters: [RBAC](/docs/reference/access-authn-authz/rbac/)과 [컨트롤러의 롤(role)들](/docs/reference/access-authn-authz/rbac/#controller-roles)을 모두 활성화한 경우, clusterrole `system:controller:persistent-volume-binder` -에 대한 `secret` 리소스에 `create` 권한을 추가한다. +에 대한 `secret` 리소스에 `create` 권한을 추가한다. 다중 테넌시 컨텍스트에서 `secretNamespace` 의 값을 명시적으로 설정하는 것을 권장하며, 그렇지 않으면 다른 사용자가 스토리지 계정 자격증명을 @@ -681,23 +681,23 @@ provisioner: kubernetes.io/portworx-volume parameters: repl: "1" snap_interval: "70" - io_priority: "high" + priority_io: "high" ``` * `fs`: 배치할 파일 시스템: `none/xfs/ext4` (기본값: `ext4`) * `block_size`: Kbytes 단위의 블록 크기(기본값: `32`). * `repl`: 레플리케이션 팩터 `1..3` (기본값: `1`)의 형태로 제공될 - 동기 레플리카의 수. 여기에는 문자열, + 동기 레플리카의 수. 여기에는 문자열, 즉 `0` 이 아닌, `"0"` 이 필요하다. -* `io_priority`: 볼륨이 고성능 또는 우선 순위가 낮은 스토리지에서 +* `priority_io`: 볼륨이 고성능 또는 우선 순위가 낮은 스토리지에서 생성될 것인지를 결정한다 `high/medium/low` (기본값: `low`). * `snap_interval`: 스냅샷을 트리거할 때의 시각/시간 간격(분). 스냅샷은 이전 스냅샷과의 차이에 따라 증분되며, 0은 스냅을 - 비활성화 한다(기본값: `0`). 여기에는 문자열, + 비활성화 한다(기본값: `0`). 여기에는 문자열, 즉 `70` 이 아닌, `"70"` 이 필요하다. * `aggregation_level`: 볼륨이 분배될 청크 수를 지정하며, 0은 집계되지 않은 - 볼륨을 나타낸다(기본값: `0`). 여기에는 문자열, + 볼륨을 나타낸다(기본값: `0`). 여기에는 문자열, 즉 `0` 이 아닌, `"0"` 이 필요하다. * `ephemeral`: 마운트 해제 후 볼륨을 정리해야 하는지 혹은 지속적이어야 하는지를 지정한다. `emptyDir` 에 대한 유스케이스는 이 값을 true로 @@ -815,5 +815,3 @@ volumeBindingMode: WaitForFirstConsumer 볼륨 바인딩을 지연시키면 스케줄러가 퍼시스턴트볼륨클레임에 적절한 퍼시스턴트볼륨을 선택할 때 파드의 모든 스케줄링 제약 조건을 고려할 수 있다. - - diff --git a/content/ko/docs/concepts/storage/storage-limits.md b/content/ko/docs/concepts/storage/storage-limits.md new file mode 100644 index 0000000000..302161dbd7 --- /dev/null +++ b/content/ko/docs/concepts/storage/storage-limits.md @@ -0,0 +1,75 @@ +--- +title: 노드 별 볼륨 한도 +content_type: concept +--- + +<!-- overview --> + +이 페이지는 다양한 클라우드 공급자들이 제공하는 노드에 연결할 수 있는 +최대 볼륨 수를 설명한다. + +Google, Amazon 그리고 Microsoft와 같은 클라우드 공급자는 일반적으로 노드에 +연결할 수 있는 볼륨 수에 제한이 있다. 쿠버네티스가 이러한 제한을 +준수하는 것은 중요하다. 그렇지 않으면, 노드에서 예약된 파드가 볼륨이 +연결될 때까지 멈추고 기다릴 수 있다. + + + +<!-- body --> + +## 쿠버네티스 기본 한도 + +쿠버네티스 스케줄러에는 노드에 연결될 수 있는 볼륨 수에 대한 +기본 한도가 있다. + +<table> + <tr><th>클라우드 서비스</th><th>노드 당 최대 볼륨</th></tr> + <tr><td><a href="https://aws.amazon.com/ebs/">Amazon Elastic Block Store (EBS)</a></td><td>39</td></tr> + <tr><td><a href="https://cloud.google.com/persistent-disk/">Google Persistent Disk</a></td><td>16</td></tr> + <tr><td><a href="https://azure.microsoft.com/ko-kr/services/storage/main-disks/">Microsoft Azure Disk Storage</a></td><td>16</td></tr> +</table> + +## 사용자 정의 한도 + +`KUBE_MAX_PD_VOLS` 환경 변수의 값을 설정한 후, +스케줄러를 시작하여 이러한 한도를 변경할 수 있다. +CSI 드라이버는 절차가 다를 수 있으므로, 한도를 사용자 정의하는 +방법에 대한 문서를 참고한다. + +기본 한도보다 높은 한도를 설정한 경우 주의한다. 클라우드 +공급자의 문서를 참조하여 노드가 실제로 사용자가 설정한 한도를 +지원할 수 있는지 확인한다. + +한도는 전체 클러스터에 적용되므로, 모든 노드에 영향을 준다. + +## 동적 볼륨 한도 + +{{< feature-state state="stable" for_k8s_version="v1.17" >}} + +다음 볼륨 유형에 대해 동적 볼륨 한도가 지원된다. + +- Amazon EBS +- Google Persistent Disk +- Azure Disk +- CSI + +인-트리(in-tree) 볼륨 플러그인으로 관리되는 볼륨의 경우, 쿠버네티스는 자동으로 노드 유형을 +결정하고 노드에 적절한 최대 볼륨 수를 적용한다. 예를 들면, 다음과 같다. + +* <a href="https://cloud.google.com/compute/">Google Compute Engine</a>에서는, +[노드 유형에 따라](https://cloud.google.com/compute/docs/disks/#pdnumberlimits) +최대 127개의 볼륨까지 +노드에 연결할 수 있다. + +* M5, C5, R5, T3와 Z1D 인스턴스 유형의 Amazon EBS 디스크의 경우, 쿠버네티스는 25개의 볼륨만 노드에 +연결할 수 있도록 허용한다. +<a href="https://aws.amazon.com/ec2/">Amazon Elastic Compute Cloud (EC2)</a>의 +다른 인스턴스 유형의 경우, 쿠버네티스는 노드에 39개의 볼륨을 연결할 수 있도록 허용한다. + +* Azure에서는, 노드 유형에 따라 최대 64개의 디스크를 노드에 연결할 수 있다. 더 자세한 내용은 [Azure의 가상 머신 크기](https://docs.microsoft.com/ko-kr/azure/virtual-machines/windows/sizes)를 참고한다. + +* CSI 스토리지 드라이버가 `NodeGetInfo` 를 사용해서 노드에 대한 최대 볼륨 수를 알린다면, {{< glossary_tooltip text="kube-scheduler" term_id="kube-scheduler" >}}는 그 한도를 따른다. + +자세한 내용은 [CSI 명세](https://github.com/container-storage-interface/spec/blob/master/spec.md#nodegetinfo)를 참고한다. + +* CSI 드라이버로 마이그레이션된 인-트리 플러그인으로 관리되는 볼륨의 경우, 최대 볼륨 수는 CSI 드라이버가 보고한 개수이다. diff --git a/content/ko/docs/concepts/storage/volume-pvc-datasource.md b/content/ko/docs/concepts/storage/volume-pvc-datasource.md index 8b8e1b484f..e6ff2caa38 100644 --- a/content/ko/docs/concepts/storage/volume-pvc-datasource.md +++ b/content/ko/docs/concepts/storage/volume-pvc-datasource.md @@ -6,8 +6,7 @@ weight: 30 <!-- overview --> -이 문서에서는 쿠버네티스의 기존 CSI 볼륨 복제의 개념을 설명한다. [볼륨] -(/ko/docs/concepts/storage/volumes)을 숙지하는 것을 추천한다. +이 문서에서는 쿠버네티스의 기존 CSI 볼륨 복제의 개념을 설명한다. [볼륨](/ko/docs/concepts/storage/volumes)을 숙지하는 것을 추천한다. diff --git a/content/ko/docs/concepts/storage/volume-snapshot-classes.md b/content/ko/docs/concepts/storage/volume-snapshot-classes.md index 801ff624bb..bdf1920567 100644 --- a/content/ko/docs/concepts/storage/volume-snapshot-classes.md +++ b/content/ko/docs/concepts/storage/volume-snapshot-classes.md @@ -6,9 +6,9 @@ weight: 30 <!-- overview --> -이 문서는 쿠버네티스의 `VolumeSnapshotClass` 개요를 설명한다. -[볼륨 스냅샷](/docs/concepts/storage/volume-snapshots/)과 -[스토리지 클래스](/docs/concepts/storage/storage-classes)의 숙지를 추천한다. +이 문서는 쿠버네티스의 볼륨스냅샷클래스(VolumeSnapshotClass) 개요를 설명한다. +[볼륨 스냅샷](/ko/docs/concepts/storage/volume-snapshots/)과 +[스토리지 클래스](/ko/docs/concepts/storage/storage-classes)의 숙지를 추천한다. @@ -17,49 +17,60 @@ weight: 30 ## 소개 -`StorageClass` 는 관리자가 볼륨을 프로비저닝할 때 제공하는 스토리지의 "클래스"를 -설명하는 방법을 제공하는 것처럼, `VolumeSnapshotClass` 는 볼륨 스냅샷을 +스토리지클래스(StorageClass)는 관리자가 볼륨을 프로비저닝할 때 제공하는 스토리지의 "클래스"를 +설명하는 방법을 제공하는 것처럼, 볼륨스냅샷클래스는 볼륨 스냅샷을 프로비저닝할 때 스토리지의 "클래스"를 설명하는 방법을 제공한다. ## VolumeSnapshotClass 리소스 -각 `VolumeSnapshotClass` 에는 클래스에 속하는 `VolumeSnapshot` 을 +각 볼륨스냅샷클래스에는 클래스에 속하는 볼륨스냅샷을 동적으로 프로비전 할 때 사용되는 `driver`, `deletionPolicy` 그리고 `parameters` 필드를 포함한다. -`VolumeSnapshotClass` 오브젝트의 이름은 중요하며, 사용자가 특정 -클래스를 요청할 수 있는 방법이다. 관리자는 `VolumeSnapshotClass` 오브젝트를 +볼륨스냅샷클래스 오브젝트의 이름은 중요하며, 사용자가 특정 +클래스를 요청할 수 있는 방법이다. 관리자는 볼륨스냅샷클래스 오브젝트를 처음 생성할 때 클래스의 이름과 기타 파라미터를 설정하고, 오브젝트가 생성된 이후에는 업데이트할 수 없다. -관리자는 특정 클래스의 바인딩을 요청하지 않는 VolumeSnapshots에만 -기본 `VolumeSnapshotClass` 를 지정할 수 있다. - ```yaml apiVersion: snapshot.storage.k8s.io/v1beta1 kind: VolumeSnapshotClass metadata: name: csi-hostpath-snapclass -driver: hostpath.csi.k8s.io +driver: hostpath.csi.k8s.io +deletionPolicy: Delete +parameters: +``` + +관리자는`snapshot.storage.kubernetes.io/is-default-class: "true"` 어노테이션을 추가하여 +바인딩할 특정 클래스를 요청하지 않는 볼륨스냅샷에 대한 +기본 볼륨스냅샷클래스를 지정할 수 있다. + +```yaml +apiVersion: snapshot.storage.k8s.io/v1beta1 +kind: VolumeSnapshotClass +metadata: + name: csi-hostpath-snapclass + annotations: + snapshot.storage.kubernetes.io/is-default-class: "true" +driver: hostpath.csi.k8s.io deletionPolicy: Delete parameters: ``` ### 드라이버 -볼륨 스냅샷 클래스에는 VolumeSnapshots의 프로비저닝에 사용되는 CSI 볼륨 플러그인을 +볼륨 스냅샷 클래스에는 볼륨스냅샷의 프로비저닝에 사용되는 CSI 볼륨 플러그인을 결정하는 드라이버를 가지고 있다. 이 필드는 반드시 지정해야한다. ### 삭제정책(DeletionPolicy) -볼륨 스냅샷 클래스는 삭제정책을 가지고 있다. 바인딩 된 `VolumeSnapshot` 오브젝트를 삭제할 때 `VolumeSnapshotContent` 의 상황을 구성할 수 있다. 볼륨 스냅삿의 삭제정책은 `Retain` 또는 `Delete` 일 수 있다. 이 필드는 반드시 지정해야 한다. +볼륨 스냅샷 클래스는 삭제정책을 가지고 있다. 바인딩된 볼륨스냅샷 오브젝트를 삭제할 때 VolumeSnapshotContent의 상황을 구성할 수 있다. 볼륨 스냅삿의 삭제정책은 `Retain` 또는 `Delete` 일 수 있다. 이 필드는 반드시 지정해야 한다. -삭제정책이 `Delete` 인 경우 기본 스토리지 스냅샷이 `VolumeSnapshotContent` 오브젝트와 함께 삭제된다. 삭제정책이 `Retain` 인 경우 기본 스냅샷과 `VolumeSnapshotContent` 모두 유지된다. +삭제정책이 `Delete` 인 경우 기본 스토리지 스냅샷이 VolumeSnapshotContent 오브젝트와 함께 삭제된다. 삭제정책이 `Retain` 인 경우 기본 스냅샷과 VolumeSnapshotContent 모두 유지된다. ## 파라미터 볼륨 스냅샷 클래스에는 볼륨 스냅샷 클래스에 속하는 볼륨 스냅샷을 설명하는 파라미터를 가지고 있다. `driver` 에 따라 다른 파라미터를 사용할 수 있다. - - diff --git a/content/ko/docs/concepts/storage/volume-snapshots.md b/content/ko/docs/concepts/storage/volume-snapshots.md index d2d85909e1..9aadbe3726 100644 --- a/content/ko/docs/concepts/storage/volume-snapshots.md +++ b/content/ko/docs/concepts/storage/volume-snapshots.md @@ -7,7 +7,7 @@ weight: 20 <!-- overview --> {{< feature-state for_k8s_version="v1.17" state="beta" >}} -쿠버네티스에서 스토리지 시스템 볼륨 스냅샷은 _VolumeSnapshot_ 을 나타낸다. 이 문서는 이미 쿠버네티스 [퍼시스턴트 볼륨](/docs/concepts/storage/persistent-volumes/)에 대해 잘 알고 있다고 가정한다. +쿠버네티스에서 스토리지 시스템 볼륨 스냅샷은 _VolumeSnapshot_ 을 나타낸다. 이 문서는 이미 쿠버네티스 [퍼시스턴트 볼륨](/ko/docs/concepts/storage/persistent-volumes/)에 대해 잘 알고 있다고 가정한다. @@ -41,11 +41,10 @@ API 리소스 `PersistentVolume` 및 `PersistentVolumeClaim` 가 사용자 및 스냅샷을 프로비저닝할 수 있는 방법에는 사전 프로비저닝 혹은 동적 프로비저닝의 두 가지가 있다: . #### 사전 프로비전 {#static} -클러스터 관리자는 많은 `VolumeSnapshotContents` 을 생성한다. 그들은 클러스터 사용자들이 사용 가능한 스토리지 시스템의 실제 볼륨 스냅샷 세부 정보를 제공한다. -이것은 쿠버네티스 API에 있고 사용 가능하다. +클러스터 관리자는 많은 `VolumeSnapshotContents` 을 생성한다. 그들은 클러스터 사용자들이 사용 가능한 스토리지 시스템의 실제 볼륨 스냅샷 세부 정보를 제공한다. 이것은 쿠버네티스 API에 있고 사용 가능하다. #### 동적 -사전 프로비저닝을 사용하는 대신 퍼시스턴트볼륨클레임에서 스냅샷을 동적으로 가져오도록 요청할 수 있다. [볼륨스냅샷클래스](/docs/concepts/storage/volume-snapshot-classes/)는 스냅샷 사용 시 스토리지 제공자의 특정 파라미터를 명세한다. +사전 프로비저닝을 사용하는 대신 퍼시스턴트볼륨클레임에서 스냅샷을 동적으로 가져오도록 요청할 수 있다. [볼륨스냅샷클래스](/ko/docs/concepts/storage/volume-snapshot-classes/)는 스냅샷 사용 시 스토리지 제공자의 특정 파라미터를 명세한다. ### 바인딩 @@ -83,7 +82,7 @@ spec: `persistentVolumeClaimName` 은 스냅샷을 위한 퍼시스턴트볼륨클레임 데이터 소스의 이름이다. 이 필드는 동적 프로비저닝 스냅샷이 필요하다. 볼륨 스냅샷은 `volumeSnapshotClassName` 속성을 사용하여 -[볼륨스냅샷클래스](/docs/concepts/storage/volume-snapshot-classes/)의 이름을 지정하여 +[볼륨스냅샷클래스](/ko/docs/concepts/storage/volume-snapshot-classes/)의 이름을 지정하여 특정 클래스를 요청할 수 있다. 아무것도 설정하지 않으면, 사용 가능한 경우 기본 클래스가 사용될 것이다. 사전 프로비저닝된 스냅샷의 경우, 다음 예와 같이 `volumeSnapshotContentName`을 스냅샷 소스로 지정해야 한다. 사전 프로비저닝된 스냅샷에는 `volumeSnapshotContentName` 소스 필드가 필요하다. @@ -146,6 +145,4 @@ spec: 스냅샷 데이터로 미리 채워진 새 볼륨을 프로비저닝할 수 있다. 보다 자세한 사항은 -[볼륨 스냅샷 및 스냅샷에서 볼륨 복원](/docs/concepts/storage/persistent-volumes/#volume-snapshot-and-restore-volume-from-snapshot-support)에서 확인할 수 있다. - - +[볼륨 스냅샷 및 스냅샷에서 볼륨 복원](/ko/docs/concepts/storage/persistent-volumes/#볼륨-스냅샷-및-스냅샷-지원에서-볼륨-복원)에서 확인할 수 있다. diff --git a/content/ko/docs/concepts/storage/volumes.md b/content/ko/docs/concepts/storage/volumes.md index a5a3e8aa23..c93cc5018e 100644 --- a/content/ko/docs/concepts/storage/volumes.md +++ b/content/ko/docs/concepts/storage/volumes.md @@ -23,7 +23,7 @@ kubelet은 컨테이너를 재시작시키지만, 컨테이너는 깨끗한 상 ## 배경 도커는 다소 느슨하고, 덜 관리되지만 -[볼륨](https://docs.docker.com/engine/admin/volumes/)이라는 +[볼륨](https://docs.docker.com/storage/)이라는 개념을 가지고 있다. 도커에서 볼륨은 단순한 디스크 내 디렉터리 또는 다른 컨테이너에 있는 디렉터리다. 수명은 관리되지 않으며 최근까지는 로컬 디스크 백업 볼륨만 있었다. 도커는 이제 볼륨 드라이버를 @@ -214,7 +214,7 @@ CephFS를 사용하기 위해선 먼저 Ceph 서버를 실행하고 공유를 {{< note >}} 전제 조건: 오픈스택 클라우드 공급자로 구성된 쿠버네티스. 클라우드 공급자 -구성에 대해서는 [오픈스택 클라우드 공급자](/docs/concepts/cluster-administration/cloud-providers/#openstack)를 참조한다. +구성에 대해서는 [오픈스택 클라우드 공급자](/ko/docs/concepts/cluster-administration/cloud-providers/#openstack)를 참조한다. {{< /note >}} `cinder` 는 오픈스택 Cinder 볼륨을 파드에 마운트하는 데 사용한다. @@ -451,15 +451,13 @@ spec: ``` #### 지역(Regional) 퍼시스턴트 디스크 -{{< feature-state for_k8s_version="v1.10" state="beta" >}} - [지역(Regional) 퍼시스턴트 디스크](https://cloud.google.com/compute/docs/disks/#repds) 기능을 사용하면 동일한 영역 내의 두 영역에서 사용할 수 있는 퍼시스턴트 디스크를 생성할 수 있다. 이 기능을 사용하려면 볼륨을 퍼시스턴트볼륨으로 프로비저닝 해야 한다. 파드에서 직접 볼륨을 참조하는 것은 지원되지 않는다. #### 지역(Regional) PD 퍼시스턴트볼륨을 수동으로 프로비저닝하기 -[GCE PD 용 StorageClass](/docs/concepts/storage/storage-classes/#gce) 를 사용해서 동적 프로비저닝이 가능하다. +[GCE PD용 스토리지클래스](/ko/docs/concepts/storage/storage-classes/#gce-pd)를 사용해서 동적 프로비저닝이 가능하다. PersistentVolume을 생성하기 전에 PD를 생성해야만 한다. ```shell -gcloud beta compute disks create --size=500GB my-data-disk +gcloud compute disks create --size=500GB my-data-disk --region us-central1 --replica-zones us-central1-a,us-central1-b ``` @@ -470,8 +468,6 @@ apiVersion: v1 kind: PersistentVolume metadata: name: test-volume - labels: - failure-domain.beta.kubernetes.io/zone: us-central1-a__us-central1-b spec: capacity: storage: 400Gi @@ -480,6 +476,15 @@ spec: gcePersistentDisk: pdName: my-data-disk fsType: ext4 + nodeAffinity: + required: + nodeSelectorTerms: + - matchExpressions: + - key: failure-domain.beta.kubernetes.io/zone + operator: In + values: + - us-central1-a + - us-central1-b ``` #### CSI 마이그레이션 @@ -574,12 +579,13 @@ glusterfs 볼륨에 데이터를 미리 채울 수 있으며, 파드간에 데 다음과 같은 이유로 이 유형의 볼륨 사용시 주의해야 한다. * 동일한 구성(파드템플릿으로 생성한 것과 같은)을 - 가진 파드는 노드에 있는 파일이 다르기 때문에 노드마다 다르게 동작할 수 있음 + 가진 파드는 노드에 있는 파일이 다르기 때문에 노드마다 다르게 동작할 수 있다. * 쿠버네티스가 계획한 대로 리소스 인식 스케줄링을 추가하면 `hostPath` 에서 - 사용되는 리소스를 설명할 수 없음 -* 기본 호스트에 생성된 파일 또는 디렉터리는 root만 쓸 수 있다. 프로세스를 - [특권 컨테이너](/docs/user-guide/security-context) 에서 루트로 실행하거나 - `hostPath` 볼륨에 쓸 수 있도록 호스트의 파일 권한을 수정해야 함 + 사용되는 리소스를 설명할 수 없다. +* 기본 호스트에 생성된 파일 또는 디렉터리는 root만 쓸 수 있다. + 프로세스를 [특권을 가진(privileged) 컨테이너](/docs/user-guide/security-context)에서 + 루트로 실행하거나 + `hostPath` 볼륨에 쓸 수 있도록 호스트의 파일 권한을 수정해야 한다. #### 파드 예시 @@ -714,7 +720,7 @@ spec: 로컬 볼륨을 사용할 때는 `volumeBindingMode` 가 `WaitForFirstConsumer` 로 설정된 스토리지클래스(StorageClass)를 생성하는 것을 권장한다. -[예시](/docs/concepts/storage/storage-classes/#local)를 본다. 볼륨 바인딩을 지연시키는 것은 +[예시](/ko/docs/concepts/storage/storage-classes/#local)를 본다. 볼륨 바인딩을 지연시키는 것은 퍼시스턴트볼륨클래임 바인딩 결정도 노드 리소스 요구사항, 노드 셀렉터, 파드 어피니티 그리고 파드 안티 어피니티와 같이 파드가 가질 수 있는 다른 노드 제약 조건으로 평가되도록 만든다. @@ -773,7 +779,7 @@ iSCSI 볼륨와 같은)를 "클레임" 할 수 있는 방법이다. 서비스 어카운트 토큰의 프로젝션은 쿠버네티스 1.11에 기능이 도입되었고 1.12에서 베타로 승격되었다. 1.11에서 이 기능을 활성화 하려면 `TokenRequestProjection` -[기능 게이트](/docs/reference/command-line-tools-reference/feature-gates/)를 +[기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)를 True로 명시적인 설정이 필요하다. #### 시크릿, downward API 그리고 configmap이 있는 파드 예시. @@ -1191,7 +1197,7 @@ spec: `subPathExpr` 필드를 사용해서 Downward API 환경 변수로부터 `subPath` 디렉터리 이름을 구성한다. -이 기능을 사용하려면 `VolumeSubpathEnvExpansion` [기능 게이트](/docs/reference/command-line-tools-reference/feature-gates/)를 활성화 해야 한다. 쿠버네티스 1.15에서는 시작 시 기본적으로 활성화되어 있다. +이 기능을 사용하려면 `VolumeSubpathEnvExpansion` [기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)를 활성화 해야 한다. 쿠버네티스 1.15에서는 시작 시 기본적으로 활성화되어 있다. `subPath` 와 `subPathExpr` 속성은 상호 배타적이다. 이 예제는 파드가 `subPathExpr` 을 사용해서 Downward API로부터 파드 이름을 사용해서 hostPath 볼륨 `/var/log/pods` 내에 `pod1` 디렉터리를 생성한다. 호스트 디렉터리 `/var/log/pods/pod1` 은 컨테이너의 `/logs` 에 마운트 된다. @@ -1473,4 +1479,3 @@ sudo systemctl restart docker ## {{% heading "whatsnext" %}} * [퍼시스턴트 볼륨과 함께 워드프레스와 MySQL 배포하기](/ko/docs/tutorials/stateful-application/mysql-wordpress-persistent-volume/)의 예시를 따른다. - diff --git a/content/ko/docs/concepts/workloads/_index.md b/content/ko/docs/concepts/workloads/_index.md index c704540b85..c898502b39 100644 --- a/content/ko/docs/concepts/workloads/_index.md +++ b/content/ko/docs/concepts/workloads/_index.md @@ -1,4 +1,6 @@ --- title: "워크로드" weight: 50 +description: > + 쿠버네티스에서 배포할 수 있는 가장 작은 컴퓨트 오브젝트인 파드와, 이를 실행하는 데 도움이 되는 하이-레벨(higher-level) 추상화 --- diff --git a/content/ko/docs/concepts/workloads/controllers/cron-jobs.md b/content/ko/docs/concepts/workloads/controllers/cron-jobs.md index fa005e77a1..44590ccdfc 100644 --- a/content/ko/docs/concepts/workloads/controllers/cron-jobs.md +++ b/content/ko/docs/concepts/workloads/controllers/cron-jobs.md @@ -10,19 +10,20 @@ weight: 80 _크론잡은_ 반복 일정에 따라 {{< glossary_tooltip term_id="job" text="잡" >}}을 만든다. -하나의 크론잡 객체는 _크론탭_ (크론 테이블) 파일의 한 줄과 같다. 크론잡은 잡을 [크론](https://en.wikipedia.org/wiki/Cron)형식으로 쓰여진 주어진 일정에 따라 주기적으로 동작시킨다. - +하나의 크론잡 오브젝트는 _크론탭_ (크론 테이블) 파일의 한 줄과 같다. +크론잡은 잡을 [크론](https://ko.wikipedia.org/wiki/Cron) 형식으로 쓰여진 주어진 일정에 따라 주기적으로 동작시킨다. {{< caution >}} 모든 **크론잡** `일정:` 시간은 {{< glossary_tooltip term_id="kube-controller-manager" text="kube-controller-manager" >}}의 시간대를 기준으로 한다. 컨트롤 플레인이 파드 또는 베어 컨테이너에서 kube-controller-manager를 실행하는 경우, -kube-controller-manager 컨테이너에 설정된 시간대는 크론잡 컨트롤러가 사용하는 시간대로 결정한다. +kube-controller-manager 컨테이너에 설정된 시간대는 +크론잡 컨트롤러가 사용하는 시간대로 결정한다. {{< /caution >}} -크론잡 리소스에 대한 매니페스트를 생성할때에는 제공하는 이름이 -유효한 [DNS 서브도메인 이름](/ko/docs/concepts/overview/working-with-objects/names/#dns-서브도메인-이름들)이어야 한다. +크론잡 리소스에 대한 매니페스트를 생성할 때에는 제공하는 이름이 +유효한 [DNS 서브도메인 이름](/ko/docs/concepts/overview/working-with-objects/names/#dns-서브도메인-이름)이어야 한다. 이름은 52자 이하여야 한다. 이는 크론잡 컨트롤러는 제공된 잡 이름에 11자를 자동으로 추가하고, 작업 이름의 최대 길이는 63자라는 제약 조건이 있기 때문이다. @@ -37,7 +38,7 @@ kube-controller-manager 컨테이너에 설정된 시간대는 크론잡 컨트 작업을 만드는데 유용하다. 또한 크론잡은 클러스터가 유휴 상태일 때 잡을 스케줄링하는 것과 같이 특정 시간 동안의 개별 작업을 스케줄할 수 있다. -### 예제 +### 예시 이 크론잡 매니페스트 예제는 현재 시간과 hello 메시지를 1분마다 출력한다. @@ -46,17 +47,17 @@ kube-controller-manager 컨테이너에 설정된 시간대는 크론잡 컨트 ([크론잡으로 자동화된 작업 실행하기](/docs/tasks/job/automated-tasks-with-cron-jobs/)는 이 예시를 더 자세히 설명한다.) -## 크론 잡의 한계 {#cron-job-limitations} +## 크론잡의 한계 {#cron-job-limitations} -크론 잡은 일정의 실행시간 마다 _약_ 한 번의 잡을 생성한다. "약" 이라고 하는 이유는 +크론잡은 일정의 실행시간 마다 _약_ 한 번의 잡 오브젝트를 생성한다. "약" 이라고 하는 이유는 특정 환경에서는 두 개의 잡이 만들어지거나, 잡이 생성되지 않기도 하기 때문이다. 보통 이렇게 하지 -않도록 해야겠지만, 완벽히 그럴 수 는 없다. 따라서 잡은 _멱등원_ 이 된다. +않도록 해야겠지만, 완벽히 그럴 수는 없다. 따라서 잡은 _멱등원_ 이 된다. 만약 `startingDeadlineSeconds` 가 큰 값으로 설정되거나, 설정되지 않고(디폴트 값), -`concurrencyPolicy` 가 `Allow`로 설정될 경우, 잡은 항상 적어도 한 번은 +`concurrencyPolicy` 가 `Allow` 로 설정될 경우, 잡은 항상 적어도 한 번은 실행될 것이다. -모든 크론 잡에 대해 크론잡 {{< glossary_tooltip term_id="controller" >}} 는 마지막 일정부터 지금까지 얼마나 많은 일정이 누락되었는지 확인한다. 만약 100회 이상의 일정이 누락되었다면, 잡을 실행하지 않고 아래와 같은 에러 로그를 남긴다. +모든 크론잡에 대해 크론잡 {{< glossary_tooltip term_id="controller" text="컨트롤러" >}} 는 마지막 일정부터 지금까지 얼마나 많은 일정이 누락되었는지 확인한다. 만약 100회 이상의 일정이 누락되었다면, 잡을 실행하지 않고 아래와 같은 에러 로그를 남긴다. ```` Cannot determine if job needs to be started. Too many missed start time (> 100). Set or decrease .spec.startingDeadlineSeconds or check clock skew. @@ -64,17 +65,17 @@ Cannot determine if job needs to be started. Too many missed start time (> 100). 중요한 것은 만약 `startingDeadlineSeconds` 필드가 설정이 되면(`nil` 이 아닌 값으로), 컨트롤러는 마지막 일정부터 지금까지 대신 `startingDeadlineSeconds` 값에서 몇 개의 잡이 누락되었는지 카운팅한다. 예를 들면, `startingDeadlineSeconds` 가 `200` 이면, 컨트롤러는 최근 200초 내 몇 개의 잡이 누락되었는지 카운팅한다. -크론잡은 정해진 일정에 잡 실행을 실패하면 놓쳤다고 카운팅된다. 예를 들면, `concurrencyPolicy` 가 `Forbid` 로 설정되었고, 크론 잡이 이전 일정이 스케줄되어 여전히 시도하고 있을 때, 그 때 누락되었다고 판단한다. +크론잡은 정해진 일정에 잡 실행을 실패하면 놓쳤다고 카운팅된다. 예를 들면, `concurrencyPolicy` 가 `Forbid` 로 설정되었고, 크론잡이 이전 일정이 스케줄되어 여전히 시도하고 있을 때, 그 때 누락되었다고 판단한다. 즉, 크론잡이 `08:30:00` 에 시작하여 매 분마다 새로운 잡을 실행하도록 설정이 되었고, -`startingDeadlineSeconds` 값이 설정되어 있지 않는다고 가정해보자. 만약 크론 잡 컨트롤러가 +`startingDeadlineSeconds` 값이 설정되어 있지 않는다고 가정해보자. 만약 크론잡 컨트롤러가 `08:29:00` 부터 `10:21:00` 까지 고장이 나면, 일정을 놓친 작업 수가 100개를 초과하여 잡이 실행되지 않을 것이다. -이 개념을 더 자세히 설명하자면, 크론 잡이 `08:30:00` 부터 매 분 실행되는 일정으로 설정되고, -`startingDeadlineSeconds` 이 200이라고 가정한다. 크론 잡 컨트롤러가 -전의 예시와 같이 고장났다고 하면 (`08:29:00` 부터 `10:21:00` 까지), 잡은 10:22:00 부터 시작될 것이다. 이 경우, 컨트롤러가 마지막 일정부터 지금까지가 아니라, 최근 200초 안에 얼마나 놓쳤는지 체크하기 때문이다. (여기서는 3번 놓쳤다고 체크함) +이 개념을 더 자세히 설명하자면, 크론잡이 `08:30:00` 부터 매 분 실행되는 일정으로 설정되고, +`startingDeadlineSeconds` 이 200이라고 가정한다. 크론잡 컨트롤러가 +전의 예시와 같이 고장났다고 하면 (`08:29:00` 부터 `10:21:00` 까지), 잡은 10:22:00 부터 시작될 것이다. 이 경우, 컨트롤러가 마지막 일정부터 지금까지가 아니라, 최근 200초 안에 얼마나 놓쳤는지 체크하기 때문이다. (여기서는 3번 놓쳤다고 체크함) -크론 잡은 오직 그 일정에 맞는 잡 생성에 책임이 있고, +크론잡은 오직 그 일정에 맞는 잡 생성에 책임이 있고, 잡은 그 잡이 대표하는 파드 관리에 책임이 있다. @@ -83,7 +84,5 @@ Cannot determine if job needs to be started. Too many missed start time (> 100). [크론 표현 포맷](https://ko.wikipedia.org/wiki/Cron)은 크론잡 `schedule` 필드의 포맷을 문서화 한다. -크론 잡 생성과 작업에 대한 지침과 크론잡 매니페스트의 -예는 [크론 잡으로 자동화된 작업 실행하기](/docs/tasks/job/automated-tasks-with-cron-jobs/)를 참조한다. - - +크론잡 생성과 작업에 대한 지침과 크론잡 매니페스트의 +예는 [크론잡으로 자동화된 작업 실행하기](/docs/tasks/job/automated-tasks-with-cron-jobs/)를 참조한다. diff --git a/content/ko/docs/concepts/workloads/controllers/daemonset.md b/content/ko/docs/concepts/workloads/controllers/daemonset.md index 83f3c428a3..c06a43edf6 100644 --- a/content/ko/docs/concepts/workloads/controllers/daemonset.md +++ b/content/ko/docs/concepts/workloads/controllers/daemonset.md @@ -6,18 +6,18 @@ weight: 50 <!-- overview --> -_데몬셋_ 은 모든(또는 일부) 노드가 파드의 사본을 실행하도록 한다. 노드가 클러스터에 추가되면 -파드도 추가된다. 노드가 클러스터에서 제거되면 해당 파드는 가비지(garbage)로 +_데몬셋_ 은 모든(또는 일부) 노드가 파드의 사본을 실행하도록 한다. 노드가 클러스터에 추가되면 +파드도 추가된다. 노드가 클러스터에서 제거되면 해당 파드는 가비지(garbage)로 수집된다. 데몬셋을 삭제하면 데몬셋이 생성한 파드들이 정리된다. 데몬셋의 일부 대표적인 용도는 다음과 같다. -- 각 노드에서 `glusterd`, `ceph` 와 같은 클러스터 스토리지 데몬의 실행. -- 모든 노드에서 `fluentd` 또는 `filebeat` 와 같은 로그 수집 데몬의 실행. -- 모든 노드에서 [Prometheus Node Exporter](https://github.com/prometheus/node_exporter), [Flowmill](https://github.com/Flowmill/flowmill-k8s/), [Sysdig Agent](https://docs.sysdig.com), `collectd`, [Dynatrace OneAgent](https://www.dynatrace.com/technologies/kubernetes-monitoring/), [AppDynamics Agent](https://docs.appdynamics.com/display/CLOUD/Container+Visibility+with+Kubernetes), [Datadog agent](https://docs.datadoghq.com/agent/kubernetes/daemonset_setup/), [New Relic agent](https://docs.newrelic.com/docs/integrations/kubernetes-integration/installation/kubernetes-installation-configuration), Ganglia `gmond` 또는 [Instana Agent](https://www.instana.com/supported-integrations/kubernetes-monitoring/) 또는 [Elastic Metricbeat](https://www.elastic.co/guide/en/beats/metricbeat/current/running-on-kubernetes.html)와 같은 노드 모니터링 데몬의 실행. +- 모든 노드에서 클러스터 스토리지 데몬 실행 +- 모든 노드에서 로그 수집 데몬 실행 +- 모든 노드에서 노드 모니터링 데몬 실행 단순한 케이스에서는, 각 데몬 유형의 처리를 위해서 모든 노드를 커버하는 하나의 데몬셋이 사용된다. -더 복잡한 구성에서는 단일 유형의 데몬에 여러 데몬셋을 사용할 수 있지만, +더 복잡한 구성에서는 단일 유형의 데몬에 여러 데몬셋을 사용할 수 있지만, 각기 다른 하드웨어 유형에 따라 서로 다른 플래그, 메모리, CPU 요구가 달라진다. @@ -42,20 +42,21 @@ kubectl apply -f https://k8s.io/examples/controllers/daemonset.yaml ### 필수 필드 다른 모든 쿠버네티스 설정과 마찬가지로 데몬셋에는 `apiVersion`, `kind` 그리고 `metadata` 필드가 필요하다. -일반적인 설정파일 작업에 대한 정보는 [애플리케이션 배포하기](/docs/tasks/run-application/run-stateless-application-deployment/), +일반적인 설정파일 작업에 대한 정보는 [애플리케이션 배포하기](/docs/user-guide/deploying-applications/), [컨테이너 구성하기](/ko/docs/tasks/) 그리고 [kubectl을 사용한 오브젝트 관리](/ko/docs/concepts/overview/working-with-objects/object-management/) 문서를 참고한다. 데몬셋 오브젝트의 이름은 유효한 -[DNS 서브도메인 이름](/ko/docs/concepts/overview/working-with-objects/names/#dns-서브도메인-이름들)이어야 한다. +[DNS 서브도메인 이름](/ko/docs/concepts/overview/working-with-objects/names/#dns-서브도메인-이름)이어야 한다. + 데몬셋에는 [`.spec`](https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status) 섹션도 필요하다. ### 파드 템플릿 `.spec.template` 는 `.spec` 의 필수 필드 중 하나이다. -`.spec.template` 는 [파드 템플릿](/ko/docs/concepts/workloads/pods/pod-overview/#pod-templates)이다. 이것은 중첩되어 있다는 점과 `apiVersion` 또는 `kind` 를 가지지 않는 것을 제외하면 [파드](/ko/docs/concepts/workloads/pods/pod/)와 정확히 같은 스키마를 가진다. +`.spec.template` 는 [파드 템플릿](/ko/docs/concepts/workloads/pods/pod-overview/#파드-템플릿)이다. 이것은 중첩되어 있다는 점과 `apiVersion` 또는 `kind` 를 가지지 않는 것을 제외하면 [파드](/ko/docs/concepts/workloads/pods/pod/)와 정확히 같은 스키마를 가진다. -데몬셋의 파드 템플릿에는 파드의 필수 필드 외에도 적절한 레이블이 명시되어야 +데몬셋의 파드 템플릿에는 파드의 필수 필드 외에도 적절한 레이블이 명시되어야 한다([파드 셀렉터](#파드-셀렉터)를 본다). 데몬셋의 파드 템플릿의 [`RestartPolicy`](/ko/docs/concepts/workloads/pods/pod-lifecycle/#재시작-정책)는 `Always` 를 가져야 하며, @@ -63,7 +64,7 @@ kubectl apply -f https://k8s.io/examples/controllers/daemonset.yaml ### 파드 셀렉터 -`.spec.selector` 필드는 파드 셀렉터이다. 이것은 +`.spec.selector` 필드는 파드 셀렉터이다. 이것은 [잡](/ko/docs/concepts/workloads/controllers/jobs-run-to-completion/)의 `.spec.selector` 와 같은 동작을 한다. 쿠버네티스 1.8 부터는 레이블이 `.spec.template` 와 일치하는 파드 셀렉터를 명시해야 한다. @@ -82,18 +83,18 @@ kubectl apply -f https://k8s.io/examples/controllers/daemonset.yaml 만약 `.spec.selector` 를 명시하면, 이것은 `.spec.template.metadata.labels` 와 일치해야 한다. 일치하지 않는 구성은 API에 의해 거부된다. -또한 일반적으로 다른 데몬셋이나 레플리카셋과 같은 다른 컨트롤러를 통해 직접적으로 -레이블이 셀렉터와 일치하는 다른 파드를 생성하지 않아야 한다. 그렇지 않으면 데몬셋 -{{< glossary_tooltip term_id="controller" >}} 는 해당 파드가 생성된 것으로 생각한다. 쿠버네티스는 이런 일을 하는 것을 -막지 못한다. 사용자가 이와 같은 일을 하게되는 한 가지 경우는 테스트를 목적으로 한 노드에서 다른 값을 가지는 파드들을 +또한 일반적으로 다른 데몬셋이나 레플리카셋과 같은 다른 컨트롤러를 통해 직접적으로 +레이블이 셀렉터와 일치하는 다른 파드를 생성하지 않아야 한다. 그렇지 않으면 데몬셋 +{{< glossary_tooltip term_id="controller" text="컨트롤러" >}}는 해당 파드가 생성된 것으로 생각한다. 쿠버네티스는 이런 일을 하는 것을 +막지 못한다. 사용자가 이와 같은 일을 하게 되는 한 가지 경우는 테스트를 목적으로 한 노드에서 다른 값을 가지는 파드들을 수동으로 생성하는 것이다. ### 오직 일부 노드에서만 파드 실행 -만약 `.spec.template.spec.nodeSelector` 를 명시하면 데몬셋 컨트롤러는 -[노드 셀렉터](/ko/docs/concepts/scheduling-eviction/assign-pod-node/#노드-셀렉터-nodeselector)와 -일치하는 노드에 파드를 생성한다. 마찬가지로 `.spec.template.spec.affinity` 를 명시하면 -데몬셋 컨트롤러는 [노트 어피니티](/ko/docs/concepts/scheduling-eviction/assign-pod-node/#노드-어피니티)와 일치하는 노드에 파드를 생성한다. +만약 `.spec.template.spec.nodeSelector` 를 명시하면 데몬셋 컨트롤러는 +[노드 셀렉터](/ko/docs/concepts/scheduling-eviction/assign-pod-node/#노드-셀렉터-nodeselector)와 +일치하는 노드에 파드를 생성한다. 마찬가지로 `.spec.template.spec.affinity` 를 명시하면 +데몬셋 컨트롤러는 [노드 어피니티](/ko/docs/concepts/scheduling-eviction/assign-pod-node/#노드-어피니티)와 일치하는 노드에 파드를 생성한다. 만약 둘 중 하나를 명시하지 않으면 데몬셋 컨트롤러는 모든 노드에서 파드를 생성한다. ## 데몬 파드가 스케줄 되는 방법 @@ -102,24 +103,24 @@ kubectl apply -f https://k8s.io/examples/controllers/daemonset.yaml {{< feature-state state="stable" for-kubernetes-version="1.17" >}} -데몬셋은 자격이 되는 모든 노드에서 파드 사본이 실행하도록 보장한다. 일반적으로 -쿠버네티스 스케줄러에 의해 파드가 실행되는 노드가 선택된다. 그러나 +데몬셋은 자격이 되는 모든 노드에서 파드 사본이 실행하도록 보장한다. 일반적으로 +쿠버네티스 스케줄러에 의해 파드가 실행되는 노드가 선택된다. 그러나 데몬셋 파드는 데몬셋 컨트롤러에 의해 생성되고 스케줄된다. 이에 대한 이슈를 소개한다. * 파드 동작의 불일치: 스케줄 되기 위해서 대기 중인 일반 파드는 `Pending` 상태로 생성된다. 그러나 데몬셋 파드는 `Pending` 상태로 생성되지 않는다. 이것은 사용자에게 혼란을 준다. - * [파드 선점](/docs/concepts/configuration/pod-priority-preemption/) - 은 기본 스케줄러에서 처리한다. 선점이 활성화되면 데몬셋 컨트롤러는 + * [파드 선점](/ko/docs/concepts/configuration/pod-priority-preemption/)은 + 기본 스케줄러에서 처리한다. 선점이 활성화되면 데몬셋 컨트롤러는 파드 우선순위와 선점을 고려하지 않고 스케줄 한다. -`ScheduleDaemonSetPods` 로 데몬셋 파드에 `.spec.nodeName` 용어 대신 -`NodeAffinity` 용어를 추가해서 데몬셋 컨트롤러 대신 기본 -스케줄러를 사용해서 데몬셋을 스케줄할 수 있다. 이후에 기본 -스케줄러를 사용해서 대상 호스트에 파드를 바인딩 한다. 만약 데몬셋 파드에 -이미 노드 선호도가 존재한다면 교체한다(대상 호스트를 선택하기 전에 원래 노드의 어피니티가 고려된다). 데몬셋 컨트롤러는 -데몬셋 파드를 만들거나 수정할 때만 이런 작업을 수행하며, +`ScheduleDaemonSetPods` 로 데몬셋 파드에 `.spec.nodeName` 용어 대신 +`NodeAffinity` 용어를 추가해서 데몬셋 컨트롤러 대신 기본 +스케줄러를 사용해서 데몬셋을 스케줄할 수 있다. 이후에 기본 +스케줄러를 사용해서 대상 호스트에 파드를 바인딩한다. 만약 데몬셋 파드에 +이미 노드 선호도가 존재한다면 교체한다(대상 호스트를 선택하기 전에 원래 노드의 어피니티가 고려된다). 데몬셋 컨트롤러는 +데몬셋 파드를 만들거나 수정할 때만 이런 작업을 수행하며, 데몬셋의 `spec.template` 은 변경되지 않는다. ```yaml @@ -133,29 +134,25 @@ nodeAffinity: - target-host-name ``` -또한, 데몬셋 파드에 `node.kubernetes.io/unschedulable:NoSchedule` 이 톨러레이션(toleration)으로 -자동으로 추가된다. 기본 스케줄러는 데몬셋 파드를 +또한, 데몬셋 파드에 `node.kubernetes.io/unschedulable:NoSchedule` 이 톨러레이션(toleration)으로 +자동으로 추가된다. 기본 스케줄러는 데몬셋 파드를 스케줄링시 `unschedulable` 노드를 무시한다. - ### 테인트(taints)와 톨러레이션(tolerations) -데몬 파드는 -[테인트와 톨러레이션](/docs/concepts/configuration/taint-and-toleration)을 존중하지만, -다음과 같이 관련 기능에 따라 자동적으로 데몬셋 파드에 +데몬 파드는 +[테인트와 톨러레이션](/ko/docs/concepts/scheduling-eviction/taint-and-toleration/)을 존중하지만, +다음과 같이 관련 기능에 따라 자동적으로 데몬셋 파드에 톨러레이션을 추가한다. -| 톨러레이션 키 | 영향 | 버전 | 설명 | +| 톨러레이션 키 | 영향 | 버전 | 설명 | | ---------------------------------------- | ---------- | ------- | ------------------------------------------------------------ | -| `node.kubernetes.io/not-ready` | NoExecute | 1.13+ | 네트워크 파티션과 같은 노드 문제가 발생해도 데몬셋 파드는 축출되지 않는다. | -| `node.kubernetes.io/unreachable` | NoExecute | 1.13+ | 네트워크 파티션과 같은 노드 문제가 발생해도 데몬셋 파드는 축출되지 않는다. | -| `node.kubernetes.io/disk-pressure` | NoSchedule | 1.8+ | | -| `node.kubernetes.io/memory-pressure` | NoSchedule | 1.8+ | | -| `node.kubernetes.io/unschedulable` | NoSchedule | 1.12+ | 데몬셋 파드는 기본 스케줄러의 스케줄할 수 없는(unschedulable) 속성을 극복한다. | -| `node.kubernetes.io/network-unavailable` | NoSchedule | 1.12+ | 호스트 네트워크를 사용하는 데몬셋 파드는 기본 스케줄러에 의해 이용할 수 없는 네트워크(network-unavailable) 속성을 극복한다. | - - - +| `node.kubernetes.io/not-ready` | NoExecute | 1.13+ | 네트워크 파티션과 같은 노드 문제가 발생해도 데몬셋 파드는 축출되지 않는다. | +| `node.kubernetes.io/unreachable` | NoExecute | 1.13+ | 네트워크 파티션과 같은 노드 문제가 발생해도 데몬셋 파드는 축출되지 않는다. | +| `node.kubernetes.io/disk-pressure` | NoSchedule | 1.8+ | | +| `node.kubernetes.io/memory-pressure` | NoSchedule | 1.8+ | | +| `node.kubernetes.io/unschedulable` | NoSchedule | 1.12+ | 데몬셋 파드는 기본 스케줄러의 스케줄할 수 없는(unschedulable) 속성을 극복한다. | +| `node.kubernetes.io/network-unavailable` | NoSchedule | 1.12+ | 호스트 네트워크를 사용하는 데몬셋 파드는 기본 스케줄러에 의해 이용할 수 없는 네트워크(network-unavailable) 속성을 극복한다. | ## 데몬 파드와 통신 @@ -164,7 +161,7 @@ nodeAffinity: - **푸시(Push)**: 데몬셋의 파드는 통계 데이터베이스와 같은 다른 서비스로 업데이트를 보내도록 구성되어있다. 그들은 클라이언트들을 가지지 않는다. - **노드IP와 알려진 포트**: 데몬셋의 파드는 `호스트 포트`를 사용할 수 있으며, 노드IP를 통해 파드에 접근할 수 있다. 클라이언트는 노드IP를 어떻게든지 알고 있으며, 관례에 따라 포트를 알고 있다. -- **DNS**: 동일한 파드 셀렉터로 [헤드리스 서비스](/ko/docs/concepts/services-networking/service/#헤드리스-headless-서비스)를 만들고, +- **DNS**: 동일한 파드 셀렉터로 [헤드리스 서비스](/ko/docs/concepts/services-networking/service/#헤드리스-headless-서비스)를 만들고, 그 다음에 `엔드포인트` 리소스를 사용해서 데몬셋을 찾거나 DNS에서 여러 A레코드를 검색한다. - **서비스**: 동일한 파드 셀렉터로 서비스를 생성하고, 서비스를 사용해서 @@ -172,58 +169,56 @@ nodeAffinity: ## 데몬셋 업데이트 -만약 노드 레이블이 변경되면, 데몬셋은 새로 일치하는 노드에 즉시 파드를 추가하고, 새로 +만약 노드 레이블이 변경되면, 데몬셋은 새로 일치하는 노드에 즉시 파드를 추가하고, 새로 일치하지 않는 노드에서 파드를 삭제한다. -사용자는 데몬셋이 생성하는 파드를 수정할 수 있다. 그러나 파드는 모든 -필드가 업데이트 되는 것을 허용하지 않는다. 또한 데몬셋 컨트롤러는 +사용자는 데몬셋이 생성하는 파드를 수정할 수 있다. 그러나 파드는 모든 +필드가 업데이트 되는 것을 허용하지 않는다. 또한 데몬셋 컨트롤러는 다음에 노드(동일한 이름으로)가 생성될 때 원본 템플릿을 사용한다. -사용자는 데몬셋을 삭제할 수 있다. 만약 `kubectl` 에서 `--cascade=false` 를 명시하면 -파드는 노드에 남게 된다. 이후에 동일한 셀렉터로 새 데몬셋을 생성하면, -새 데몬셋은 기존 파드를 채택한다. 만약 파드를 교체해야 하는 경우 데몬셋은 +사용자는 데몬셋을 삭제할 수 있다. 만약 `kubectl` 에서 `--cascade=false` 를 명시하면 +파드는 노드에 남게 된다. 이후에 동일한 셀렉터로 새 데몬셋을 생성하면, +새 데몬셋은 기존 파드를 채택한다. 만약 파드를 교체해야 하는 경우 데몬셋은 `updateStrategy` 에 따라 파드를 교체한다. -사용자는 데몬셋에서 [롤링 업데이트를 수행](/docs/tasks/manage-daemon/update-daemon-set/) 할 수 있다. +사용자는 데몬셋에서 [롤링 업데이트를 수행](/ko/docs/tasks/manage-daemon/update-daemon-set/)할 수 있다. ## 데몬셋의 대안 ### 초기화 스크립트 데몬 프로세스를 직접 노드에서 시작해서 실행하는 것도 당연히 가능하다. -(예: `init`, `upstartd` 또는 `systemd` 를 사용). 이 방법도 문제는 전혀 없다. 그러나 데몬셋을 통해 데몬 +(예: `init`, `upstartd` 또는 `systemd` 를 사용). 이 방법도 문제는 전혀 없다. 그러나 데몬셋을 통해 데몬 프로세스를 실행하면 몇 가지 이점 있다. - 애플리케이션과 동일한 방법으로 데몬을 모니터링하고 로그 관리를 할 수 있다. - 데몬 및 애플리케이션과 동일한 구성 언어와 도구(예: 파드 템플릿, `kubectl`). -- 리소스 제한이 있는 컨테이너에서 데몬을 실행하면 앱 컨테이너에서 +- 리소스 제한이 있는 컨테이너에서 데몬을 실행하면 앱 컨테이너에서 데몬간의 격리를 증가시킨다. 그러나 이것은 파드가 아닌 컨테이너에서 데몬을 실행해서 이루어진다 (예: 도커에서 직접적으로 시작). ### 베어(Bare) 파드 -직접적으로 파드를 실행할 특정한 노드를 명시해서 파드를 생성할 수 있다. 그러나 +직접적으로 파드를 실행할 특정한 노드를 명시해서 파드를 생성할 수 있다. 그러나 데몬셋은 노드 장애 또는 커널 업그레이드와 같이 변경사항이 많은 노드 유지보수의 경우를 비롯하여 -어떠한 이유로든 삭제되거나 종료된 파드를 교체한다. 따라서 개별 파드를 +어떠한 이유로든 삭제되거나 종료된 파드를 교체한다. 따라서 개별 파드를 생성하는 것보다는 데몬 셋을 사용해야 한다. ### 스태틱(static) 파드 -Kubelet이 감시하는 특정 디렉토리에 파일을 작성하는 파드를 생성할 수 있다. 이것을 -[스태틱 파드](/docs/tasks/configure-pod-container/static-pod/)라고 부른다. -데몬셋과는 다르게 스태틱 파드는 kubectl -또는 다른 쿠버네티스 API 클라이언트로 관리할 수 없다. 스태틱 파드는 API 서버에 의존하지 -않기 때문에 클러스터 부트스트랩(bootstraping)하는 경우에 유용하다. 또한 스태틱 파드는 향후에 사용 중단(deprecated)될 수 있다. +Kubelet이 감시하는 특정 디렉터리에 파일을 작성하는 파드를 생성할 수 있다. 이것을 +[스태틱 파드](/ko/docs/tasks/configure-pod-container/static-pod/)라고 부른다. +데몬셋과는 다르게 스태틱 파드는 kubectl +또는 다른 쿠버네티스 API 클라이언트로 관리할 수 없다. 스태틱 파드는 API 서버에 의존하지 +않기 때문에 클러스터 부트스트랩(bootstraping)하는 경우에 유용하다. 또한 스태틱 파드는 향후에 사용 중단될 수 있다. ### 디플로이먼트 -데몬셋은 파드를 생성한다는 점에서 [디플로이먼트](/ko/docs/concepts/workloads/controllers/deployment/)와 유사하고, -해당 파드에서는 프로세스가 종료되지 않을 것으로 +데몬셋은 파드를 생성한다는 점에서 [디플로이먼트](/ko/docs/concepts/workloads/controllers/deployment/)와 유사하고, +해당 파드에서는 프로세스가 종료되지 않을 것으로 예상한다(예: 웹 서버). -파드가 실행되는 호스트를 정확하게 제어하는 것보다 레플리카의 수를 스케일링 업 및 다운 하고, -업데이트 롤아웃이 더 중요한 프런트 엔드와 같은 것은 스테이트리스 서비스의 -디플로이먼트를 사용한다. 파드 사본이 항상 모든 호스트 또는 특정 호스트에서 실행되는 것이 중요하고, +파드가 실행되는 호스트를 정확하게 제어하는 것보다 레플리카의 수를 스케일링 업 및 다운 하고, +업데이트 롤아웃이 더 중요한 프런트 엔드와 같은 것은 스테이트리스 서비스의 +디플로이먼트를 사용한다. 파드 사본이 항상 모든 호스트 또는 특정 호스트에서 실행되는 것이 중요하고, 다른 파드의 실행 이전에 필요한 경우에는 데몬셋을 사용한다. - - diff --git a/content/ko/docs/concepts/workloads/controllers/deployment.md b/content/ko/docs/concepts/workloads/controllers/deployment.md index 96f41dc186..91b20304c7 100644 --- a/content/ko/docs/concepts/workloads/controllers/deployment.md +++ b/content/ko/docs/concepts/workloads/controllers/deployment.md @@ -1,4 +1,6 @@ --- + + title: 디플로이먼트 feature: title: 자동화된 롤아웃과 롤백 @@ -11,7 +13,7 @@ weight: 30 <!-- overview --> -_디플로이먼트_ 는 [파드](/ko/docs/concepts/workloads/pods/pod/)와 +_디플로이먼트_ 는 [파드](/ko/docs/concepts/workloads/pods/pod/)와 [레플리카셋](/ko/docs/concepts/workloads/controllers/replicaset/)에 대한 선언적 업데이트를 제공한다. 디플로이먼트에서 _의도하는 상태_ 를 설명하고, 디플로이먼트 {{< glossary_tooltip term_id="controller" >}} 는 현재 상태에서 의도하는 상태로 비율을 조정하며 변경한다. 새 레플리카셋을 생성하는 디플로이먼트를 정의하거나 기존 디플로이먼트를 제거하고, 모든 리소스를 새 디플로이먼트에 적용할 수 있다. @@ -53,16 +55,16 @@ _디플로이먼트_ 는 [파드](/ko/docs/concepts/workloads/pods/pod/)와 보다 정교한 선택 규칙의 적용이 가능하다. {{< note >}} - `.spec.selector.matchLabels` 필드는 {key,value}의 쌍으로 매핑되어있다. `matchLabels` 에 매핑된 - 단일 {key,value}은 `matchExpressions` 의 요소에 해당하며, 키 필드는 "key"에 그리고 연산자는 "In"에 대응되며 + `.spec.selector.matchLabels` 필드는 {key,value}의 쌍으로 매핑되어있다. `matchLabels` 에 매핑된 + 단일 {key,value}은 `matchExpressions` 의 요소에 해당하며, 키 필드는 "key"에 그리고 연산자는 "In"에 대응되며 값 배열은 "value"만 포함한다. 매칭을 위해서는 `matchLabels` 와 `matchExpressions` 의 모든 요건이 충족되어야 한다. {{< /note >}} * `template` 필드에는 다음 하위 필드가 포함되어있다. * 파드는 `.metadata.labels` 필드를 사용해서 `app: nginx` 라는 레이블을 붙인다. - * 파드 템플릿의 사양 또는 `.template.spec` 필드는 - 파드가 [도커 허브](https://hub.docker.com/)의 `nginx` 1.14.2 버전 이미지를 실행하는 + * 파드 템플릿의 사양 또는 `.template.spec` 필드는 + 파드가 [도커 허브](https://hub.docker.com/)의 `nginx` 1.14.2 버전 이미지를 실행하는 `nginx` 컨테이너 1개를 실행하는 것을 나타낸다. * 컨테이너 1개를 생성하고, `.spec.template.spec.containers[0].name` 필드를 사용해서 `nginx` 이름을 붙인다. @@ -72,7 +74,6 @@ _디플로이먼트_ 는 [파드](/ko/docs/concepts/workloads/pods/pod/)와 1. 다음 명령어를 실행해서 디플로이먼트를 생성한다. - ```shell kubectl apply -f https://k8s.io/examples/controllers/nginx-deployment.yaml ``` @@ -84,7 +85,7 @@ kubectl apply -f https://k8s.io/examples/controllers/nginx-deployment.yaml 2. `kubectl get deployments` 을 실행해서 디플로이먼트가 생성되었는지 확인한다. - + 만약 디플로이먼트가 여전히 생성 중이면, 다음과 유사하게 출력된다. ```shell NAME READY UP-TO-DATE AVAILABLE AGE @@ -145,7 +146,7 @@ kubectl apply -f https://k8s.io/examples/controllers/nginx-deployment.yaml 디플로이먼트에는 파드 템플릿 레이블과 적절한 셀렉터를 반드시 명시해야 한다 (이 예시에서는 `app: nginx`). -레이블 또는 셀렉터는 다른 컨트롤러(다른 디플로이먼트와 스테이트풀 셋 포함)와 겹치지 않아야 한다. 쿠버네티스는 겹치는 것을 막지 않으며, 만약 다중 컨트롤러가 겹치는 셀렉터를 가지는 경우 해당 컨트롤러의 충돌 또는 예기치 않은 동작을 야기할 수 있다. +레이블 또는 셀렉터는 다른 컨트롤러(다른 디플로이먼트와 스테이트풀셋(StatefulSet) 포함)와 겹치지 않아야 한다. 쿠버네티스는 겹치는 것을 막지 않으며, 만약 다중 컨트롤러가 겹치는 셀렉터를 가지는 경우 해당 컨트롤러의 충돌 또는 예기치 않은 동작을 야기할 수 있다. {{< /note >}} ### Pod-template-hash 레이블 @@ -156,13 +157,13 @@ kubectl apply -f https://k8s.io/examples/controllers/nginx-deployment.yaml `pod-template-hash` 레이블은 디플로이먼트 컨트롤러에 의해서 디플로이먼트가 생성 또는 채택한 모든 레플리카셋에 추가된다. -이 레이블은 디플로이먼트의 자식 레플리카셋이 겹치지 않도록 보장한다. 레플리카셋의 `PodTemplate` 을 해싱하고, 해시 결과를 레플리카셋 셀렉터, +이 레이블은 디플로이먼트의 자식 레플리카셋이 겹치지 않도록 보장한다. 레플리카셋의 `PodTemplate` 을 해싱하고, 해시 결과를 레플리카셋 셀렉터, 파드 템플릿 레이블 및 레플리카셋 이 가질 수 있는 기존의 모든 파드에 레이블 값으로 추가해서 사용하도록 생성한다. ## 디플로이먼트 업데이트 {{< note >}} -디플로이먼트의 파드 템플릿(즉, `.spec.template`)이 변경된 경우에만 디플로이먼트의 롤아웃이 트리거(trigger) 된다. +디플로이먼트의 파드 템플릿(즉, `.spec.template`)이 변경된 경우에만 디플로이먼트의 롤아웃이 트리거(trigger) 된다. 예를 들면 템플릿의 레이블이나 컨테이너 이미지가 업데이트된 경우이다. 디플로이먼트의 스케일링과 같은 다른 업데이트는 롤아웃을 트리거하지 말아야 한다. {{< /note >}} @@ -219,7 +220,7 @@ kubectl apply -f https://k8s.io/examples/controllers/nginx-deployment.yaml nginx-deployment 3/3 3 3 36s ``` -* `kubectl get rs` 를 실행해서 디플로이먼트가 새 레플리카셋을 생성해서 파드를 업데이트 했는지 볼 수 있고, +* `kubectl get rs` 를 실행해서 디플로이먼트가 새 레플리카셋을 생성해서 파드를 업데이트 했는지 볼 수 있고, 새 레플리카셋을 최대 3개의 레플리카로 스케일 업, 이전 레플리카셋을 0개의 레플리카로 스케일 다운한다. ```shell @@ -255,8 +256,8 @@ kubectl apply -f https://k8s.io/examples/controllers/nginx-deployment.yaml 또한 디플로이먼트는 의도한 파드 수 보다 더 많이 생성되는 파드의 수를 제한한다. 기본적으로, 의도한 파드의 수 기준 최대 125%까지만 추가 파드가 동작할 수 있도록 제한한다(최대 25% 까지). - 예를 들어, 위 디플로이먼트를 자세히 살펴보면 먼저 새로운 파드를 생성한 다음 - 이전 파드를 삭제하고, 새로운 파드를 만든 것을 볼 수 있다. 충분한 수의 새로운 파드가 나올 때까지 이전 파드를 죽이지 않으며, + 예를 들어, 위 디플로이먼트를 자세히 살펴보면 먼저 새로운 파드를 생성한 다음 + 이전 파드를 삭제하고, 새로운 파드를 만든 것을 볼 수 있다. 충분한 수의 새로운 파드가 나올 때까지 이전 파드를 죽이지 않으며, 충분한 수의 이전 파드들이 죽기 전까지 새로운 파드를 만들지 않는다. 이것은 최소 2개의 파드를 사용할 수 있게 하고, 최대 4개의 파드를 사용할 수 있게 한다. @@ -264,7 +265,7 @@ kubectl apply -f https://k8s.io/examples/controllers/nginx-deployment.yaml ```shell kubectl describe deployments ``` - 이와 유사하게 출력된다. + 이와 유사하게 출력된다. ``` Name: nginx-deployment Namespace: default @@ -303,48 +304,48 @@ kubectl apply -f https://k8s.io/examples/controllers/nginx-deployment.yaml Normal ScalingReplicaSet 19s deployment-controller Scaled up replica set nginx-deployment-1564180365 to 3 Normal ScalingReplicaSet 14s deployment-controller Scaled down replica set nginx-deployment-2035384211 to 0 ``` - 처음 디플로이먼트를 생성했을 때, 디플로이먼트가 레플리카셋(nginx-deployment-2035384211)을 생성해서 + 처음 디플로이먼트를 생성했을 때, 디플로이먼트가 레플리카셋(nginx-deployment-2035384211)을 생성해서 3개의 레플리카로 직접 스케일 업한 것을 볼 수 있다. - 디플로이먼트를 업데이트할 때 새 레플리카셋(nginx-deployment-1564180365)을 생성하고, 1개로 스케일 업한 다음 + 디플로이먼트를 업데이트할 때 새 레플리카셋(nginx-deployment-1564180365)을 생성하고, 1개로 스케일 업한 다음 이전 레플리카셋을 2개로 스케일 다운해서, 최소 2개의 파드를 사용할 수 있고 최대 4개의 파드가 항상 생성되어 있도록 하였다. 이후 지속해서 같은 롤링 업데이트 정책으로 새 레플리카셋은 스케일 업하고 이전 레플리카셋은 스케일 다운한다. 마지막으로 새로운 레플리카셋에 3개의 사용 가능한 레플리카가 구성되며, 이전 레플리카셋은 0개로 스케일 다운된다. ### 롤오버(일명 인-플라이트 다중 업데이트) -디플로이먼트 컨트롤러는 각 시간마다 새로운 디플로이먼트에서 레플리카셋이 -의도한 파드를 생성하고 띄우는 것을 주시한다. 만약 디플로이먼트가 업데이트되면, 기존 레플리카셋에서 +디플로이먼트 컨트롤러는 각 시간마다 새로운 디플로이먼트에서 레플리카셋이 +의도한 파드를 생성하고 띄우는 것을 주시한다. 만약 디플로이먼트가 업데이트되면, 기존 레플리카셋에서 `.spec.selector` 레이블과 일치하는 파드를 컨트롤 하지만, 템플릿과 `.spec.template` 이 불일치하면 스케일 다운이 된다. -결국 새로운 레플리카셋은 `.spec.replicas` 로 스케일되고, 모든 기존 레플리카 셋은 0개로 스케일된다. +결국 새로운 레플리카셋은 `.spec.replicas` 로 스케일되고, 모든 기존 레플리카셋은 0개로 스케일된다. -만약 기존 롤아웃이 진행되는 중에 디플로이먼트를 업데이트하는 경우 디플로이먼트가 업데이트에 따라 새 레플리카셋을 생성하고, +만약 기존 롤아웃이 진행되는 중에 디플로이먼트를 업데이트하는 경우 디플로이먼트가 업데이트에 따라 새 레플리카셋을 생성하고, 스케일 업하기 시작한다. 그리고 이전에 스케일 업 하던 레플리카셋에 롤오버 한다. --이것은 기존 레플리카셋 목록에 추가하고 스케일 다운을 할 것이다. 예를 들어 디플로이먼트로 `nginx:1.14.2` 레플리카를 5개 생성을 한다. -하지만 `nginx:1.14.2` 레플리카 3개가 생성되었을 때 디플로이먼트를 업데이트해서 `nginx:1.16.1` -레플리카 5개를 생성성하도록 업데이트를 한다고 가정한다. 이 경우 디플로이먼트는 즉시 생성된 3개의 -`nginx:1.14.2` 파드 3개를 죽이기 시작하고 `nginx:1.16.1` 파드를 생성하기 시작한다. -이것은 과정이 변경되기 전 `nginx:1.14.2` 레플리카 5개가 +하지만 `nginx:1.14.2` 레플리카 3개가 생성되었을 때 디플로이먼트를 업데이트해서 `nginx:1.16.1` +레플리카 5개를 생성성하도록 업데이트를 한다고 가정한다. 이 경우 디플로이먼트는 즉시 생성된 3개의 +`nginx:1.14.2` 파드 3개를 죽이기 시작하고 `nginx:1.16.1` 파드를 생성하기 시작한다. +이것은 과정이 변경되기 전 `nginx:1.14.2` 레플리카 5개가 생성되는 것을 기다리지 않는다. ### 레이블 셀렉터 업데이트 일반적으로 레이블 셀렉터를 업데이트 하는 것을 권장하지 않으며 셀렉터를 미리 계획하는 것을 권장한다. -어떤 경우든 레이블 셀렉터의 업데이트를 해야하는 경우 매우 주의하고, +어떤 경우든 레이블 셀렉터의 업데이트를 해야하는 경우 매우 주의하고, 모든 영향을 파악했는지 확인해야 한다. {{< note >}} API 버전 `apps/v1` 에서 디플로이먼트의 레이블 셀렉터는 생성 이후에는 변경할 수 없다. {{< /note >}} -* 셀렉터 추가 시 디플로이먼트의 사양에 있는 파드 템플릿 레이블도 새 레이블로 업데이트 해야한다. -그렇지 않으면 유효성 검사 오류가 반환된다. 이 변경은 겹치지 않는 변경으로 새 셀렉터가 -이전 셀렉터로 만든 레플리카셋과 파드를 선택하지 않게 되고, 그 결과로 모든 기존 레플리카셋은 고아가 되며, +* 셀렉터 추가 시 디플로이먼트의 사양에 있는 파드 템플릿 레이블도 새 레이블로 업데이트 해야한다. +그렇지 않으면 유효성 검사 오류가 반환된다. 이 변경은 겹치지 않는 변경으로 새 셀렉터가 +이전 셀렉터로 만든 레플리카셋과 파드를 선택하지 않게 되고, 그 결과로 모든 기존 레플리카셋은 고아가 되며, 새로운 레플리카셋을 생성하게 된다. * 셀렉터 업데이트는 기존 셀렉터 키 값을 변경하며, 결과적으로 추가와 동일한 동작을 한다. * 셀렉터 삭제는 디플로이먼트 셀렉터의 기존 키를 삭제하며 파드 템플릿 레이블의 변경을 필요로 하지 않는다. -기존 레플리카셋은 고아가 아니고, 새 레플리카셋은 생성되지 않는다. +기존 레플리카셋은 고아가 아니고, 새 레플리카셋은 생성되지 않는다. 그러나 제거된 레이블은 기존 파드와 레플리카셋에 여전히 존재한다는 점을 참고해야 한다. ## 디플로이먼트 롤백 @@ -354,11 +355,11 @@ API 버전 `apps/v1` 에서 디플로이먼트의 레이블 셀렉터는 생성 (이 사항은 수정 기록에 대한 상한 수정을 통해서 변경할 수 있다). {{< note >}} -디플로이먼트의 수정 버전은 디플로이먼트 롤아웃시 생성된다. 이는 디플로이먼트 파드 템플릿 -(`.spec.template`)이 변경되는 경우에만 새로운 수정 버전이 생성된다는 것을 의미한다. +디플로이먼트의 수정 버전은 디플로이먼트 롤아웃시 생성된다. 이는 디플로이먼트 파드 템플릿 +(`.spec.template`)이 변경되는 경우에만 새로운 수정 버전이 생성된다는 것을 의미한다. 예를 들어 템플릿의 레이블 또는 컨테이너 이미지를 업데이트 하는 경우. 디플로이먼트의 스케일링과 같은 다른 업데이트시 디플로이먼트 수정 버전은 생성되지 않으며 수동-스케일링 또는 자동-스케일링을 동시에 수행할 수 있다. -이는 이전 수정 버전으로 롤백을 하는 경우에 디플로이먼트 파드 템플릿 부분만 +이는 이전 수정 버전으로 롤백을 하는 경우에 디플로이먼트 파드 템플릿 부분만 롤백된다는 것을 의미한다. {{< /note >}} @@ -385,7 +386,7 @@ API 버전 `apps/v1` 에서 디플로이먼트의 레이블 셀렉터는 생성 Waiting for rollout to finish: 1 out of 3 new replicas have been updated... ``` -* Ctrl-C 를 눌러 위의 롤아웃 상태 보기를 중지한다. 고착된 롤아웃 상태에 대한 자세한 정보는 [이 것을 더 읽어본다](#디플로이먼트-상태). +* Ctrl-C 를 눌러 위의 롤아웃 상태 보기를 중지한다. 고착된 롤아웃 상태에 대한 자세한 정보는 [이 것을 더 읽어본다](#디플로이먼트-상태). * 이전 레플리카는 2개(`nginx-deployment-1564180365` 과 `nginx-deployment-2035384211`), 새 레플리카는 1개(nginx-deployment-3066724191)임을 알 수 있다. @@ -425,7 +426,7 @@ API 버전 `apps/v1` 에서 디플로이먼트의 레이블 셀렉터는 생성 kubectl describe deployment ``` - 이와 유사하게 출력된다. + 이와 유사하게 출력된다. ``` Name: nginx-deployment Namespace: default @@ -476,7 +477,7 @@ API 버전 `apps/v1` 에서 디플로이먼트의 레이블 셀렉터는 생성 ```shell kubectl rollout history deployment.v1.apps/nginx-deployment ``` - 이와 유사하게 출력된다. + 이와 유사하게 출력된다. ``` deployments "nginx-deployment" REVISION CHANGE-CAUSE @@ -496,7 +497,7 @@ API 버전 `apps/v1` 에서 디플로이먼트의 레이블 셀렉터는 생성 kubectl rollout history deployment.v1.apps/nginx-deployment --revision=2 ``` - 이와 유사하게 출력된다. + 이와 유사하게 출력된다. ``` deployments "nginx-deployment" revision 2 Labels: app=nginx @@ -521,7 +522,7 @@ API 버전 `apps/v1` 에서 디플로이먼트의 레이블 셀렉터는 생성 kubectl rollout undo deployment.v1.apps/nginx-deployment ``` - 이와 유사하게 출력된다. + 이와 유사하게 출력된다. ``` deployment.apps/nginx-deployment rolled back ``` @@ -531,14 +532,14 @@ API 버전 `apps/v1` 에서 디플로이먼트의 레이블 셀렉터는 생성 kubectl rollout undo deployment.v1.apps/nginx-deployment --to-revision=2 ``` - 이와 유사하게 출력된다. + 이와 유사하게 출력된다. ``` deployment.apps/nginx-deployment rolled back ``` 롤아웃 관련 명령에 대한 자세한 내용은 [`kubectl rollout`](/docs/reference/generated/kubectl/kubectl-commands#rollout)을 참조한다. - 이제 디플로이먼트가 이전 안정 수정 버전으로 롤백 된다. 버전 2로 롤백하기 위해 `DeploymentRollback` 이벤트가 + 이제 디플로이먼트가 이전 안정 수정 버전으로 롤백 된다. 버전 2로 롤백하기 위해 `DeploymentRollback` 이벤트가 디플로이먼트 컨트롤러에서 생성되는 것을 볼 수 있다. 2. 만약 롤백에 성공하고, 디플로이먼트가 예상대로 실행되는지 확인하려면 다음을 실행한다. @@ -546,7 +547,7 @@ API 버전 `apps/v1` 에서 디플로이먼트의 레이블 셀렉터는 생성 kubectl get deployment nginx-deployment ``` - 이와 유사하게 출력된다. + 이와 유사하게 출력된다. ``` NAME READY UP-TO-DATE AVAILABLE AGE nginx-deployment 3/3 3 3 30m @@ -555,7 +556,7 @@ API 버전 `apps/v1` 에서 디플로이먼트의 레이블 셀렉터는 생성 ```shell kubectl describe deployment nginx-deployment ``` - 이와 유사하게 출력된다. + 이와 유사하게 출력된다. ``` Name: nginx-deployment Namespace: default @@ -613,7 +614,7 @@ deployment.apps/nginx-deployment scaled ``` 가령 클러스터에서 [horizontal Pod autoscaling](/ko/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough/)를 설정 -한 경우 디플로이먼트에 대한 오토스케일러를 설정할 수 있다. 그리고 기존 파드의 CPU 사용률을 기준으로 +한 경우 디플로이먼트에 대한 오토스케일러를 설정할 수 있다. 그리고 기존 파드의 CPU 사용률을 기준으로 실행할 최소 파드 및 최대 파드의 수를 선택할 수 있다. ```shell @@ -627,7 +628,7 @@ deployment.apps/nginx-deployment scaled ### 비례적 스케일링(Proportional Scaling) 디플로이먼트 롤링업데이트는 여러 버전의 애플리케이션을 동시에 실행할 수 있도록 지원한다. -사용자 또는 오토스케일러가 롤아웃 중에 있는 디플로이먼트 롤링 업데이트를 스케일링 하는 경우(진행중 또는 일시 중지 중), +사용자 또는 오토스케일러가 롤아웃 중에 있는 디플로이먼트 롤링 업데이트를 스케일링 하는 경우(진행중 또는 일시 중지 중), 디플로이먼트 컨트롤러는 위험을 줄이기 위해 기존 활성화된 레플리카셋(파드와 레플리카셋)의 추가 레플리카의 균형을 조절 한다. 이것을 *proportional scaling* 라 부른다. @@ -654,7 +655,7 @@ deployment.apps/nginx-deployment scaled deployment.apps/nginx-deployment image updated ``` -* 이미지 업데이트는 레플리카셋 nginx-deployment-1989198191 으로 새로운 롤 아웃이 시작하지만, +* 이미지 업데이트는 레플리카셋 nginx-deployment-1989198191 으로 새로운 롤 아웃이 시작하지만, 위에서 언급한 `maxUnavailable` 의 요구 사항으로 인해 차단된다. 롤아웃 상태를 확인한다. ```shell kubectl get rs @@ -670,18 +671,18 @@ deployment.apps/nginx-deployment scaled 디플로이먼트 컨트롤러는 새로운 5개의 레플리카의 추가를 위한 위치를 결정해야 한다. 만약 비례적 스케일링을 사용하지 않으면 5개 모두 새 레플리카셋에 추가된다. 비례적 스케일링으로 추가 레플리카를 모든 레플리카셋에 걸쳐 분산할 수 있다. -비율이 높을수록 가장 많은 레플리카가 있는 레플리카셋으로 이동하고, 비율이 낮을 수록 적은 레플리카가 있는 레플리카 셋으로 이동한다. +비율이 높을수록 가장 많은 레플리카가 있는 레플리카셋으로 이동하고, 비율이 낮을 수록 적은 레플리카가 있는 레플리카셋으로 이동한다. 남은 것들은 대부분의 레플리카가 있는 레플리카셋에 추가된다. 0개의 레플리카가 있는 레플리카셋은 스케일 업 되지 않는다. 위의 예시에서 기존 레플리카셋에 3개의 레플리카가 추가되고, 2개의 레플리카는 새 레플리카에 추가된다. -결국 롤아웃 프로세스는 새 레플리카가 정상이라고 가정하면 모든 레플리카를 새 레플리카셋으로 이동시킨다. +결국 롤아웃 프로세스는 새 레플리카가 정상이라고 가정하면 모든 레플리카를 새 레플리카셋으로 이동시킨다. 이를 확인하려면 다음을 실행한다. ```shell kubectl get deploy ``` -이와 유사하게 출력된다. +이와 유사하게 출력된다. ``` NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE nginx-deployment 15 18 7 8 7m @@ -845,7 +846,7 @@ nginx-deployment-618515232 11 11 11 7m 쿠버네티스는 다음과 같은 특성을 가지게 되면 디플로이먼트를 _완료_ 로 표시한다. -* 디플로이먼트과 관련된 모든 레플리카가 지정된 최신 버전으로 업데이트 되었을 때. +* 디플로이먼트과 관련된 모든 레플리카가 지정된 최신 버전으로 업데이트 되었을 때. 즉, 요청한 모든 업데이트가 완료되었을 때. * 디플로이먼트와 관련한 모든 레플리카를 사용할 수 있을 때. * 디플로이먼트에 대해 이전 복제본이 실행되고 있지 않을 때. @@ -860,7 +861,12 @@ kubectl rollout status deployment.v1.apps/nginx-deployment ``` Waiting for rollout to finish: 2 of 3 updated replicas are available... deployment.apps/nginx-deployment successfully rolled out -$ echo $? +``` +그리고 `kubectl rollout` 의 종료 상태는 0(success)이다. +```shell +echo $? +``` +``` 0 ``` @@ -877,11 +883,11 @@ $ echo $? * 애플리케이션 런타임의 잘못된 구성 이 조건을 찾을 수 있는 한 가지 방법은 디플로이먼트 스펙에서 데드라인 파라미터를 지정하는 것이다 -([`.spec.progressDeadlineSeconds`](#진행-기한-시간-초)). `.spec.progressDeadlineSeconds` 는 -(디플로이먼트 상태에서) 디플로이먼트의 진행이 정지되었음을 나타내는 디플로이먼트 컨트롤러가 +([`.spec.progressDeadlineSeconds`](#진행-기한-시간-초)). `.spec.progressDeadlineSeconds` 는 +(디플로이먼트 상태에서) 디플로이먼트의 진행이 정지되었음을 나타내는 디플로이먼트 컨트롤러가 대기하는 시간(초)를 나타낸다. -다음 `kubectl` 명령어로 `progressDeadlineSeconds` 를 설정해서 컨트롤러가 +다음 `kubectl` 명령어로 `progressDeadlineSeconds` 를 설정해서 컨트롤러가 10분 후 디플로이먼트에 대한 진행 상태의 부족에 대한 리포트를 수행하게 한다. ```shell @@ -891,7 +897,7 @@ kubectl patch deployment.v1.apps/nginx-deployment -p '{"spec":{"progressDeadline ``` deployment.apps/nginx-deployment patched ``` -만약 데드라인을 넘어서면 디플로이먼트 컨트롤러는 디플로이먼트의 `.status.conditions` 속성에 다음의 +만약 데드라인을 넘어서면 디플로이먼트 컨트롤러는 디플로이먼트의 `.status.conditions` 속성에 다음의 디플로이먼트 컨디션(DeploymentCondition)을 추가한다. * Type=Progressing @@ -901,14 +907,14 @@ deployment.apps/nginx-deployment patched 컨디션 상태에 대한 자세한 내용은 [쿠버네티스 API 규칙](https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#typical-status-properties)을 참고한다. {{< note >}} -쿠버네티스는 `Reason=ProgressDeadlineExceeded` 과 같은 상태 조건을 -보고하는 것 이외에 정지된 디플로이먼트에 대해 조치를 취하지 않는다. 더 높은 수준의 오케스트레이터는 이를 활용할 수 있으며, +쿠버네티스는 `Reason=ProgressDeadlineExceeded` 과 같은 상태 조건을 +보고하는 것 이외에 정지된 디플로이먼트에 대해 조치를 취하지 않는다. 더 높은 수준의 오케스트레이터는 이를 활용할 수 있으며, 예를 들어 디플로이먼트를 이전 버전으로 롤백할 수 있다. {{< /note >}} {{< note >}} 만약 디플로이먼트를 일시 중지하면 쿠버네티스는 지정된 데드라인과 비교하여 진행 상황을 확인하지 않는다. -롤아웃 중에 디플로이먼트를 안전하게 일시 중지하고, 데드라인을 넘기도록 하는 조건을 트리거하지 않고 +롤아웃 중에 디플로이먼트를 안전하게 일시 중지하고, 데드라인을 넘기도록 하는 조건을 트리거하지 않고 재개할 수 있다. {{< /note >}} @@ -961,7 +967,7 @@ status: unavailableReplicas: 2 ``` -결국, 디플로이먼트 진행 데드라인을 넘어서면, 쿠버네티스는 진행 컨디션의 +결국, 디플로이먼트 진행 데드라인을 넘어서면, 쿠버네티스는 진행 컨디션의 상태와 이유를 업데이트한다. ``` @@ -973,9 +979,9 @@ Conditions: ReplicaFailure True FailedCreate ``` -디플로이먼트를 스케일 다운하거나, 실행 중인 다른 컨트롤러를 스케일 다운하거나, +디플로이먼트를 스케일 다운하거나, 실행 중인 다른 컨트롤러를 스케일 다운하거나, 네임스페이스에서 할당량을 늘려서 할당량이 부족한 문제를 해결할 수 있다. -만약 할당량 컨디션과 디플로이먼트 롤아웃이 완료되어 디플로이먼트 컨트롤러를 만족한다면 +만약 할당량 컨디션과 디플로이먼트 롤아웃이 완료되어 디플로이먼트 컨트롤러를 만족한다면 성공한 컨디션의 디플로이먼트 상태가 업데이트를 볼 수 있다(`Status=True` 와 `Reason=NewReplicaSetAvailable`). ``` @@ -987,9 +993,9 @@ Conditions: ``` `Type=Available` 과 `Status=True` 는 디플로이먼트가 최소한의 가용성을 가지고 있는 것을 의미한다. -최소한의 가용성은 디플로이먼트 계획에 명시된 파라미터에 의해 결정된다. `Type=Progressing` 과 `Status=True` 는 디플로이먼트가 +최소한의 가용성은 디플로이먼트 계획에 명시된 파라미터에 의해 결정된다. `Type=Progressing` 과 `Status=True` 는 디플로이먼트가 롤아웃 도중에 진행 중 이거나, 성공적으로 완료되었으며, 진행 중 최소한으로 필요한 새로운 레플리카를 이용 가능하다는 것이다. -(자세한 내용은 특정 조건의 이유를 참조한다. +(자세한 내용은 특정 조건의 이유를 참조한다. 이 경우 `Reason=NewReplicaSetAvailable` 는 배포가 완료되었음을 의미한다.) `kubectl rollout status` 를 사용해서 디플로이먼트의 진행이 실패되었는지 확인할 수 있다. @@ -1002,7 +1008,12 @@ kubectl rollout status deployment.v1.apps/nginx-deployment ``` Waiting for rollout to finish: 2 out of 3 new replicas have been updated... error: deployment "nginx" exceeded its progress deadline -$ echo $? +``` +그리고 `kubectl rollout` 의 종료 상태는 1(error를 의미함)이다. +```shell +echo $? +``` +``` 1 ``` @@ -1013,7 +1024,7 @@ $ echo $? ## 정책 초기화 -디플로이먼트의 `.spec.revisionHistoryLimit` 필드를 설정해서 +디플로이먼트의 `.spec.revisionHistoryLimit` 필드를 설정해서 디플로이먼트에서 유지해야 하는 이전 레플리카셋의 수를 명시할 수 있다. 나머지는 백그라운드에서 가비지-수집이 진행된다. 기본적으로 10으로 되어있다. @@ -1024,17 +1035,17 @@ $ echo $? ## 카나리 디플로이먼트 -만약 디플로이먼트를 이용해서 일부 사용자 또는 서버에 릴리즈를 롤아웃 하기 위해서는 -[리소스 관리](/docs/concepts/cluster-administration/manage-deployment/#canary-deployments)에 +만약 디플로이먼트를 이용해서 일부 사용자 또는 서버에 릴리즈를 롤아웃 하기 위해서는 +[리소스 관리](/ko/docs/concepts/cluster-administration/manage-deployment/#카나리-canary-디플로이먼트)에 설명된 카나리 패던에 따라 각 릴리스 마다 하나씩 여러 디플로이먼트를 생성할 수 있다. ## 디플로이먼트 사양 작성 다른 모든 쿠버네티스 설정과 마찬가지로 디플로이먼트에는 `.apiVersion`, `.kind` 그리고 `.metadata` 필드가 필요하다. -설정 파일 작업에 대한 일반적인 내용은 [애플리케이션 배포하기](/docs/tutorials/stateless-application/run-stateless-application-deployment/), +설정 파일 작업에 대한 일반적인 내용은 [애플리케이션 배포하기](/docs/tutorials/stateless-application/run-stateless-application-deployment/), 컨테이너 구성하기 그리고 [kubectl을 사용해서 리소스 관리하기](/ko/docs/concepts/overview/working-with-objects/object-management/) 문서를 참조한다. 디플로이먼트 오브젝트의 이름은 유효한 -[DNS 서브도메인 이름](/ko/docs/concepts/overview/working-with-objects/names/#dns-서브도메인-이름들)이어야 한다. +[DNS 서브도메인 이름](/ko/docs/concepts/overview/working-with-objects/names/#dns-서브도메인-이름)이어야 한다. 디플로이먼트에는 [`.spec` 섹션](https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status)도 필요하다. @@ -1048,7 +1059,7 @@ $ echo $? 파드에 필요한 필드 외에 디플로이먼트 파드 템플릿은 적절한 레이블과 적절한 재시작 정책을 명시해야 한다. 레이블의 경우 다른 컨트롤러와 겹치지 않도록 해야한다. 자세한 것은 [셀렉터](#셀렉터)를 참조한다. -[`.spec.template.spec.restartPolicy`](/ko/docs/concepts/workloads/pods/pod-lifecycle/#재시작-정책) 에는 오직 `Always` 만 허용되고, +[`.spec.template.spec.restartPolicy`](/ko/docs/concepts/workloads/pods/pod-lifecycle/#재시작-정책) 에는 오직 `Always` 만 허용되고, 명시되지 않으면 기본값이 된다. ### 레플리카 @@ -1057,15 +1068,14 @@ $ echo $? ### 셀렉터 -`.spec.selector` 는 디플로이먼트의 대상이 되는 파드에 대해 [레이블 셀렉터](/ko/docs/concepts/overview/working-with-objects/labels/)를 +`.spec.selector` 는 디플로이먼트의 대상이 되는 파드에 대해 [레이블 셀렉터](/ko/docs/concepts/overview/working-with-objects/labels/)를 지정하는 필수 필드이다. `.spec.selector` 는 `.spec.template.metadata.labels` 과 일치해야 하며, 그렇지 않으면 API에 의해 거부된다. API 버전 `apps/v1` 에서는 `.spec.selector` 와 `.metadata.labels` 이 설정되지 않으면 `.spec.template.metadata.labels` 은 기본 설정되지 않는다. 그래서 이것들은 명시적으로 설정되어야 한다. 또한 `apps/v1` 에서는 디플로이먼트를 생성한 후에는 `.spec.selector` 이 변경되지 않는 점을 참고한다. - -디플로이먼트는 템플릿의 `.spec.template` 와 다르거나 파드의 수가 `.spec.replicas` 를 초과할 경우 +디플로이먼트는 템플릿의 `.spec.template` 와 다르거나 파드의 수가 `.spec.replicas` 를 초과할 경우 셀렉터와 일치하는 레이블을 가진 파드를 종료할 수 있다. 파드의 수가 의도한 수량보다 적을 경우 `.spec.template` 에 맞는 새 파드를 띄운다. @@ -1075,7 +1085,7 @@ API 버전 `apps/v1` 에서는 `.spec.selector` 와 `.metadata.labels` 이 설 쿠버네티스는 이 일을 막지 않는다. {{< /note >}} -만약 셀렉터가 겹치는 컨트롤러가 어러 개 있는 경우, 컨트롤러는 서로 싸우고 +만약 셀렉터가 겹치는 컨트롤러가 어러 개 있는 경우, 컨트롤러는 서로 싸우고 올바르게 작동하지 않는다. ### 전략 @@ -1099,8 +1109,8 @@ API 버전 `apps/v1` 에서는 `.spec.selector` 와 `.metadata.labels` 이 설 #### 디플로이먼트 롤링 업데이트 -디플로이먼트는 `.spec.strategy.type==RollingUpdate` 이면 파드를 롤링 업데이트 -방식으로 업데이트 한다. `maxUnavailable` 와 `maxSurge` 를 명시해서 +디플로이먼트는 `.spec.strategy.type==RollingUpdate` 이면 파드를 롤링 업데이트 +방식으로 업데이트 한다. `maxUnavailable` 와 `maxSurge` 를 명시해서 롤링 업데이트 프로세스를 제어할 수 있다. ##### 최대 불가(Max Unavailable) @@ -1110,9 +1120,10 @@ API 버전 `apps/v1` 에서는 `.spec.selector` 와 `.metadata.labels` 이 설 절대 값은 반올림해서 백분율로 계산한다. 만약 `.spec.strategy.rollingUpdate.maxSurge` 가 0이면 값이 0이 될 수 없다. 기본 값은 25% 이다. -예를 들어 이 값을 30%로 설정하면 롤링업데이트 시작시 즉각 이전 레플리카셋의 크기를 -의도한 파드 중 70%를 스케일 다운할 수 있다. 새 파드가 준비되면 기존 레플리카셋을 스케일 다운할 수 있으며, -업데이트 중에 항상 사용가능한 전체 파드의 수는 의도한 파드의 수의 70%이상이 되도록 새 레플리카셋을 스케일을 업 할수 있다. +예를 들어 이 값을 30%로 설정하면 롤링업데이트 시작시 즉각 이전 레플리카셋의 크기를 +의도한 파드 중 70%를 스케일 다운할 수 있다. 새 파드가 준비되면 기존 레플리카셋을 스케일 다운할 수 있으며, +업데이트 중에 항상 사용 가능한 전체 파드의 수는 +의도한 파드의 수의 70% 이상이 되도록 새 레플리카셋을 스케일 업할 수 있다. ##### 최대 서지(Max Surge) @@ -1121,18 +1132,18 @@ API 버전 `apps/v1` 에서는 `.spec.selector` 와 `.metadata.labels` 이 설 `MaxUnavailable` 값이 0이면 이 값은 0이 될 수 없다. 절대 값은 반올림해서 백분율로 계산한다. 기본 값은 25% 이다. -예를 들어 이 값을 30%로 설정하면 롤링업데이트 시작시 새 레플리카셋의 크기를 즉시 조정해서 +예를 들어 이 값을 30%로 설정하면 롤링업데이트 시작시 새 레플리카셋의 크기를 즉시 조정해서 기존 및 새 파드의 전체 갯수를 의도한 파드의 130%를 넘지 않도록 한다. -기존 파드가 죽으면 새로운 래플리카셋은 스케일 업할 수 있으며, +기존 파드가 죽으면 새로운 래플리카셋은 스케일 업할 수 있으며, 업데이트하는 동안 항상 실행하는 총 파드의 수는 최대 의도한 파드의 수의 130%가 되도록 보장한다. ### 진행 기한 시간(초) -`.spec.progressDeadlineSeconds` 는 디플로어먼트가 표면적으로 `Type=Progressing`, `Status=False`의 -상태 그리고 리소스가 `Reason=ProgressDeadlineExceeded` 상태로 [진행 실패](#디플로이먼트-실패)를 보고하기 전에 +`.spec.progressDeadlineSeconds` 는 디플로어먼트가 표면적으로 `Type=Progressing`, `Status=False`의 +상태 그리고 리소스가 `Reason=ProgressDeadlineExceeded` 상태로 [진행 실패](#디플로이먼트-실패)를 보고하기 전에 디플로이먼트가 진행되는 것을 대기시키는 시간(초)를 명시하는 선택적 필드이다. 디플로이먼트 컨트롤러는 디플로이먼트를 계속 재시도 한다. 기본값은 600(초)이다. -미래에 자동화된 롤백이 구현된다면 디플로이먼트 컨트롤러는 상태를 관찰하고, +미래에 자동화된 롤백이 구현된다면 디플로이먼트 컨트롤러는 상태를 관찰하고, 그 즉시 디플로이먼트를 롤백할 것이다. 만약 명시된다면 이 필드는 `.spec.minReadySeconds` 보다 커야 한다. @@ -1153,7 +1164,7 @@ API 버전 `apps/v1` 에서는 `.spec.selector` 와 `.metadata.labels` 이 설 디플로이먼트의 수정 버전 기록은 자신이 컨트롤하는 레플리카셋에 저장된다. `.spec.revisionHistoryLimit` 은 롤백을 허용하기 위해 보존할 이전 레플리카셋의 수를 지정하는 선택적 필드이다. -이 이전 레플리카셋은 `etcd` 의 리소스를 소비하고, `kubectl get rs` 의 결과를 가득차게 만든다. 각 디플로이먼트의 구성은 디플로이먼트의 레플리카셋에 저장된다. 이전 레플리카셋이 삭제되면 해당 디플로이먼트 수정 버전으로 롤백할 수 있는 기능이 사라진다. 기본적으로 10개의 기존 레플리카셋이 유지되지만 이상적인 값은 새로운 디플로이먼트의 빈도와 안정성에 따라 달라진다. +이 이전 레플리카셋은 `etcd` 의 리소스를 소비하고, `kubectl get rs` 의 결과를 가득차게 만든다. 각 디플로이먼트의 구성은 디플로이먼트의 레플리카셋에 저장된다. 이전 레플리카셋이 삭제되면 해당 디플로이먼트 수정 버전으로 롤백할 수 있는 기능이 사라진다. 기본적으로 10개의 기존 레플리카셋이 유지되지만 이상적인 값은 새로운 디플로이먼트의 빈도와 안정성에 따라 달라진다. 더욱 구체적으로 이 필드를 0으로 설정하면 레플리카가 0이 되며 이전 레플리카셋이 정리된다. 이 경우, 새로운 디플로이먼트 롤아웃을 취소할 수 없다. 새로운 디플로이먼트 롤아웃은 수정 버전 이력이 정리되기 때문이다. @@ -1161,8 +1172,6 @@ API 버전 `apps/v1` 에서는 `.spec.selector` 와 `.metadata.labels` 이 설 ### 일시 정지 `.spec.paused` 는 디플로이먼트를 일시 중지나 재개하기 위한 선택적 부울 필드이다. -일시 중지 된 디플로이먼트와 일시 중지 되지 않은 디플로이먼트 사이의 유일한 차이점은 +일시 중지 된 디플로이먼트와 일시 중지 되지 않은 디플로이먼트 사이의 유일한 차이점은 일시 중지된 디플로이먼트는 PodTemplateSpec에 대한 변경 사항이 일시중지 된 경우 새 롤아웃을 트리거 하지 않는다. 디플로이먼트는 생성시 기본적으로 일시 중지되지 않는다. - - diff --git a/content/ko/docs/concepts/workloads/controllers/garbage-collection.md b/content/ko/docs/concepts/workloads/controllers/garbage-collection.md index f819614a6c..03083b86ed 100644 --- a/content/ko/docs/concepts/workloads/controllers/garbage-collection.md +++ b/content/ko/docs/concepts/workloads/controllers/garbage-collection.md @@ -1,7 +1,7 @@ --- title: 가비지(Garbage) 수집 content_type: concept -weight: 60 +weight: 70 --- <!-- overview --> @@ -10,8 +10,6 @@ weight: 60 소유자가 없는 오브젝트들을 삭제하는 역할을 한다. - - <!-- body --> ## 소유자(owner)와 종속(dependent) @@ -22,7 +20,7 @@ weight: 60 필드를 가지고 있다. 때때로, 쿠버네티스는 `ownerReference` 값을 자동적으로 설정한다. -예를 들어 레플리카셋을 만들 때 쿠버네티스는 레플리카셋에 있는 각 파드의 +예를 들어 레플리카셋을 만들 때 쿠버네티스는 레플리카셋에 있는 각 파드의 `ownerReference` 필드를 자동으로 설정한다. 1.8 에서는 쿠버네티스가 레플리케이션컨트롤러, 레플리카셋, 스테이트풀셋, 데몬셋, 디플로이먼트, 잡 그리고 크론잡에 의해서 생성되거나 차용된 오브젝트의 `ownerReference` 값을 @@ -35,7 +33,7 @@ weight: 60 {{< codenew file="controllers/replicaset.yaml" >}} -레플리카셋을 생성하고 파드의 메타데이터를 본다면, +레플리카셋을 생성하고 파드의 메타데이터를 본다면, OwnerReferences 필드를 찾을 수 있다. ```shell @@ -72,7 +70,7 @@ metadata: 오브젝트를 삭제할 때, 오브젝트의 종속 항목을 자동으로 삭제하는지의 여부를 지정할 수 있다. 종속 항목을 자동으로 삭제하는 것을 *캐스케이딩(cascading) -삭제* 라고 한다. *캐스케이딩 삭제* 에는 *백그라운드* 와 *포어그라운드* 2가지 모드가 있다. +삭제* 라고 한다. *캐스케이딩 삭제* 에는 *백그라운드* 와 *포어그라운드* 2가지 모드가 있다. 만약 종속 항목을 자동으로 삭제하지 않고 오브젝트를 삭제한다면, 종속 항목은 *분리됨(orphaned)* 이라고 한다. @@ -147,8 +145,8 @@ curl -X DELETE localhost:8080/apis/apps/v1/namespaces/default/replicasets/my-rep ``` kubectl도 캐스케이딩 삭제를 지원한다. -kubectl을 사용해서 종속 항목을 자동으로 삭제하려면 `--cascade` 를 true로 설정한다. 종속 항목을 -분리하기 위해서는 `--cascase` 를 false로 설정한다. `--cascade` 의 기본값은 +kubectl을 사용해서 종속 항목을 자동으로 삭제하려면 `--cascade` 를 true로 설정한다. 종속 항목을 +분리하기 위해서는 `--cascade` 를 false로 설정한다. `--cascade` 의 기본값은 true 이다. 여기에 레플리카셋의 종속 항목을 분리로 만드는 예시가 있다. @@ -170,14 +168,9 @@ kubectl delete replicaset my-repset --cascade=false - ## {{% heading "whatsnext" %}} [디자인 문서 1](https://git.k8s.io/community/contributors/design-proposals/api-machinery/garbage-collection.md) [디자인 문서 2](https://git.k8s.io/community/contributors/design-proposals/api-machinery/synchronous-garbage-collection.md) - - - - diff --git a/content/ko/docs/concepts/workloads/controllers/jobs-run-to-completion.md b/content/ko/docs/concepts/workloads/controllers/job.md similarity index 97% rename from content/ko/docs/concepts/workloads/controllers/jobs-run-to-completion.md rename to content/ko/docs/concepts/workloads/controllers/job.md index 4d6e93ded5..7b48a96c67 100644 --- a/content/ko/docs/concepts/workloads/controllers/jobs-run-to-completion.md +++ b/content/ko/docs/concepts/workloads/controllers/job.md @@ -111,7 +111,7 @@ kubectl logs $pods ## 잡 사양 작성하기 다른 쿠버네티스의 설정과 마찬가지로 잡에는 `apiVersion`, `kind` 그리고 `metadata` 필드가 필요하다. -잡의 이름은 유효한 [DNS 서브도메인 이름](/ko/docs/concepts/overview/working-with-objects/names/#dns-서브도메인-이름들)이어야 한다. +잡의 이름은 유효한 [DNS 서브도메인 이름](/ko/docs/concepts/overview/working-with-objects/names/#dns-서브도메인-이름)이어야 한다. 잡에는 [`.spec` 섹션](https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status)도 필요하다. @@ -175,8 +175,8 @@ _작업 큐_ 잡은 `.spec.completions` 를 설정하지 않은 상태로 두고 - _고정적인 완료 횟수(fixed completion count)_ 잡의 경우, 병렬로 실행 중인 파드의 수는 남은 완료 수를 초과하지 않는다. `.spec.parallelism` 의 더 큰 값은 사실상 무시된다. - _작업 큐_ 잡은 파드가 성공한 이후에 새로운 파드가 시작되지 않는다. 그러나 나머지 파드는 완료될 수 있다. -- 만약 잡 {{< glossary_tooltip term_id="controller" >}} 가 반응할 시간이 없는 경우 -- 만약 잡 컨트롤러가 어떤 이유(`리소스 쿼터` 의 부족, 권한 부족 등)로든 파드 생성에 실패한 경우, +- 만약 잡 {{< glossary_tooltip term_id="controller" text="컨트롤러" >}} 가 반응할 시간이 없는 경우 +- 만약 잡 컨트롤러가 어떤 이유(`ResourceQuota` 의 부족, 권한 부족 등)로든 파드 생성에 실패한 경우, 요청한 것보다 적은 수의 파드가 있을 수 있다. - 잡 컨트롤러는 동일한 잡에서 과도하게 실패한 이전 파드들로 인해 새로운 파드의 생성을 조절할 수 있다. - 파드가 정상적으로(gracefully) 종료되면, 중지하는데 시간이 소요된다. @@ -211,9 +211,9 @@ _작업 큐_ 잡은 `.spec.completions` 를 설정하지 않은 상태로 두고 이렇게 하려면 `.spec.backoffLimit` 에 잡을 실패로 간주하기 이전에 재시도할 횟수를 설정한다. 백오프 제한은 기본적으로 6으로 설정되어 있다. 잡과 관련한 실패한 파드는 최대 6분안에서 기하급수적으로 증가하는 백-오프 지연 (10초, 20초, 40초 ...) -한도가 되어 잡 컨트롤러에 의해 재생성 된다. 잡의 다음 상태 -확인 이전에 새로 실패한 파드가 표시되지 않으면 백 오프 -카운트가 재설정 된다. +한도가 되어 잡 컨트롤러에 의해 재생성된다. 잡의 파드가 삭제되거나 +해당 시간 동안 잡에 대한 다른 파드가 실패 없이 성공했을 때 백 오프 +카운트가 재설정된다. {{< note >}} 1.12 이전 버전의 쿠버네티스 버전에 대해 여전히 [#54870](https://github.com/kubernetes/kubernetes/issues/54870) 이슈가 있다. @@ -327,7 +327,7 @@ spec: 여기에는 전송할 이메일들, 렌더링할 프레임, 코드 변환이 필요한 파일, NoSQL 데이터베이스에서의 키 범위 스캔 등이 있다. -복잡한 시스템에는 여러개의 다른 작업 항목 집합이 있을 수 있다. 여기서는 사용자와 +복잡한 시스템에는 여러 개의 다른 작업 항목 집합이 있을 수 있다. 여기서는 사용자와 함께 관리하려는 하나의 작업 항목 집합 — *배치 잡* 을 고려하고 있다. 병렬 계산에는 몇몇 다른 패턴이 있으며 각각의 장단점이 있다. @@ -471,8 +471,6 @@ spec: 이 접근 방식의 장점은 전체 프로세스가 잡 오브젝트의 완료를 보장하면서도, 파드 생성과 작업 할당 방법을 완전히 제어하고 유지한다는 것이다. -## 크론 잡 {#cron-jobs} - -[`크론잡`](/ko/docs/concepts/workloads/controllers/cron-jobs/)을 사용해서 Unix 도구인 `cron`과 유사하게 지정된 시간/일자에 실행되는 잡을 생성할 수 있다. - +## 크론잡 {#cron-jobs} +[`CronJob`](/ko/docs/concepts/workloads/controllers/cron-jobs/)을 사용해서 Unix 도구인 `cron`과 유사하게 지정된 시간/일자에 실행되는 잡을 생성할 수 있다. diff --git a/content/ko/docs/concepts/workloads/controllers/replicaset.md b/content/ko/docs/concepts/workloads/controllers/replicaset.md index e99bb4f7c5..a23c3605cf 100644 --- a/content/ko/docs/concepts/workloads/controllers/replicaset.md +++ b/content/ko/docs/concepts/workloads/controllers/replicaset.md @@ -223,7 +223,7 @@ pod2 1/1 Running 0 36s API 버전에 대해서는 `frontend.yaml` 예제의 첫 번째 줄을 참고한다. 레플리카셋 오브젝트의 이름은 유효한 -[DNS 서브도메인 이름](/ko/docs/concepts/overview/working-with-objects/names/#dns-서브도메인-이름들)이어야 한다. +[DNS 서브도메인 이름](/ko/docs/concepts/overview/working-with-objects/names/#dns-서브도메인-이름)이어야 한다. 레플리카셋도 [`.spec` 섹션](https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status)이 필요하다. @@ -233,7 +233,7 @@ API 버전에 대해서는 `frontend.yaml` 예제의 첫 번째 줄을 참고한 우리는 `frontend.yaml` 예제에서 `tier: frontend`이라는 레이블을 하나 가지고 있다. 이 파드를 다른 컨트롤러가 취하지 않도록 다른 컨트롤러의 셀렉터와 겹치지 않도록 주의해야 한다. -템플릿의 [재시작 정책](/ko/docs/concepts/workloads/pods/pod-lifecycle/#restart-policy) 필드인 +템플릿의 [재시작 정책](/ko/docs/concepts/workloads/pods/pod-lifecycle/#재시작-정책) 필드인 `.spec.template.spec.restartPolicy`는 기본값인 `Always`만 허용된다. ### 파드 셀렉터 @@ -250,7 +250,7 @@ matchLabels: 그렇지 않으면 API에 의해 거부된다. {{< note >}} -2개의 레플리카셋이 동일한 `.spec.selector`필드를 지정한 반면, 다른 `.spec.template.metadata.labels`와 `.spec.template.spec` 필드를 명시한 경우, 각 레플리카 셋은 다른 레플리카 셋이 생성한 파드를 무시한다. +2개의 레플리카셋이 동일한 `.spec.selector`필드를 지정한 반면, 다른 `.spec.template.metadata.labels`와 `.spec.template.spec` 필드를 명시한 경우, 각 레플리카셋은 다른 레플리카셋이 생성한 파드를 무시한다. {{< /note >}} ### 레플리카 @@ -307,7 +307,7 @@ curl -X DELETE 'localhost:8080/apis/apps/v1/namespaces/default/replicasets/fron ### 레플리카셋을 Horizontal Pod Autoscaler 대상으로 설정 -레플리카 셋은 +레플리카셋은 [Horizontal Pod Autoscalers (HPA)](/ko/docs/tasks/run-application/horizontal-pod-autoscale/)의 대상이 될 수 있다. 즉, 레플리카셋은 HPA에 의해 오토스케일될 수 있다. 다음은 이전에 만든 예시에서 만든 레플리카셋을 대상으로 하는 HPA 예시이다. @@ -316,7 +316,7 @@ curl -X DELETE 'localhost:8080/apis/apps/v1/namespaces/default/replicasets/fron 이 매니페스트를 `hpa-rs.yaml`로 저장한 다음 쿠버네티스 클러스터에 적용하면 CPU 사용량에 따라 파드가 복제되는 -오토스케일 레플리카 셋 HPA가 생성된다. +오토스케일 레플리카셋 HPA가 생성된다. ```shell kubectl apply -f https://k8s.io/examples/controllers/hpa-rs.yaml @@ -346,7 +346,7 @@ kubectl autoscale rs frontend --max=10 --min=3 --cpu-percent=50 ### 잡 -스스로 종료되는 것이 예상되는 파드의 경우에는 레플리카셋 대신 [`잡`](/docs/concepts/jobs/run-to-completion-finite-workloads/)을 이용한다 +스스로 종료되는 것이 예상되는 파드의 경우에는 레플리카셋 대신 [`잡`](/ko/docs/concepts/workloads/controllers/job/)을 이용한다 (즉, 배치 잡). ### 데몬셋 @@ -361,5 +361,3 @@ kubectl autoscale rs frontend --max=10 --min=3 --cpu-percent=50 이 두 개의 용도는 동일하고, 유사하게 동작하며, 레플리케이션 컨트롤러가 [레이블 사용자 가이드](/ko/docs/concepts/overview/working-with-objects/labels/#레이블-셀렉터)에 설명된 설정-기반의 셀렉터의 요건을 지원하지 않는다는 점을 제외하면 유사하다. 따라서 레플리카셋이 레플리케이션 컨트롤러보다 선호된다. - - diff --git a/content/ko/docs/concepts/workloads/controllers/replicationcontroller.md b/content/ko/docs/concepts/workloads/controllers/replicationcontroller.md index 16146a45b6..c2414d9fdd 100644 --- a/content/ko/docs/concepts/workloads/controllers/replicationcontroller.md +++ b/content/ko/docs/concepts/workloads/controllers/replicationcontroller.md @@ -13,10 +13,10 @@ weight: 20 <!-- overview --> {{< note >}} -[`ReplicaSet`](/ko/docs/concepts/workloads/controllers/replicaset/) 을 구성하는 [`Deployment`](/ko/docs/concepts/workloads/controllers/deployment/) 가 현재 권장되는 레플리케이션 설정 방법이다. +[`ReplicaSet`](/ko/docs/concepts/workloads/controllers/replicaset/)을 구성하는 [`Deployment`](/ko/docs/concepts/workloads/controllers/deployment/)가 현재 권장하는 레플리케이션 설정 방법이다. {{< /note >}} -_레플리케이션 컨트롤러_ 는 언제든지 지정된 수의 파드 레플리카가 +_레플리케이션컨트롤러_ 는 언제든지 지정된 수의 파드 레플리카가 실행 중임을 보장한다. 다시 말하면, 레플리케이션 컨트롤러는 파드 또는 동일 종류의 파드의 셋이 항상 기동되고 사용 가능한지 확인한다. @@ -105,8 +105,8 @@ echo $pods nginx-3ntk0 nginx-4ok8v nginx-qrm3m ``` -여기서 셀렉터는 레플리케이션 컨트롤러(`kubectl describe` 의 출력에서 보인)의 셀렉터와 같고, -다른 형식의 파일인 `replication.yaml` 의 것과 동일하다. `--output=jsonpath` 옵션은 +여기서 셀렉터는 레플리케이션컨트롤러(`kubectl describe` 의 출력에서 보인)의 셀렉터와 같고, +다른 형식의 파일인 `replication.yaml` 의 것과 동일하다. `--output=jsonpath` 옵션은 반환된 목록의 각 파드에서 이름을 가져오는 표현식을 지정한다. @@ -114,7 +114,7 @@ nginx-3ntk0 nginx-4ok8v nginx-qrm3m 다른 모든 쿠버네티스 컨피그와 마찬가지로 레플리케이션 컨트롤러는 `apiVersion`, `kind`, `metadata` 와 같은 필드가 필요하다. 레플리케이션 컨트롤러 오브젝트의 이름은 유효한 -[DNS 서브도메인 이름](/ko/docs/concepts/overview/working-with-objects/names/#dns-서브도메인-이름들)이어야 한다. +[DNS 서브도메인 이름](/ko/docs/concepts/overview/working-with-objects/names/#dns-서브도메인-이름)이어야 한다. 컨피그 파일의 동작에 관련된 일반적인 정보는 다음을 참조하라 [쿠버네티스 오브젝트 관리 ](/ko/docs/concepts/overview/working-with-objects/object-management/). 레플리케이션 컨트롤러는 또한 [`.spec` section](https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status) 도 필요하다. @@ -123,7 +123,7 @@ nginx-3ntk0 nginx-4ok8v nginx-qrm3m `.spec.template` 는 오직 `.spec` 필드에서 요구되는 것이다. -`.spec.template` 는 [파드(Pod) 개요](/ko/docs/concepts/workloads/pods/pod-overview/#pod-templates) 이다. 정확하게 [파드](/ko/docs/concepts/workloads/pods/pod/) 스키마와 동일하나, 중첩되어 있고 `apiVersion` 혹은 `kind`를 갖지 않는다. +`.spec.template` 는 [파드 개요](/ko/docs/concepts/workloads/pods/pod-overview/#파드-템플릿) 이다. 정확하게 [파드](/ko/docs/concepts/workloads/pods/pod/) 스키마와 동일하나, 중첩되어 있고 `apiVersion` 혹은 `kind`를 갖지 않는다. 파드에 필요한 필드 외에도 레플리케이션 컨트롤러의 파드 템플릿은 적절한 레이블과 적절한 재시작 정책을 지정해야 한다. 레이블의 경우 다른 컨트롤러와 중첩되지 않도록 하라. [파드 셀렉터](#파드-셀렉터)를 참조하라. @@ -223,12 +223,12 @@ REST API나 go 클라이언트 라이브러리를 사용하는 경우 간단히 예를 들어, 서비스는 `tier in (frontend), environment in (prod)` 이 있는 모든 파드를 대상으로 할 수 있다. 이제 이 계층을 구성하는 10 개의 복제된 파드가 있다고 가정해 보자. 하지만 이 구성 요소의 새로운 버전을 '카나리' 하기를 원한다. 대량의 레플리카에 대해 `replicas` 를 9로 설정하고 `tier=frontend, environment=prod, track=stable` 레이블을 설정한 레플리케이션 컨트롤러와, 카나리에 `replicas` 가 1로 설정된 다른 레플리케이션 컨트롤러에 `tier=frontend, environment=prod, track=canary` 라는 레이블을 설정할 수 있다. 이제 이 서비스는 카나리와 카나리 이외의 파드 모두를 포함한다. 그러나 레플리케이션 컨트롤러를 별도로 조작하여 테스트하고 결과를 모니터링하는 등의 작업이 혼란스러울 수 있다. -### 서비스와 레플리케이션 컨트롤러 사용 +### 서비스와 레플리케이션컨트롤러 사용 -하나의 서비스 뒤에 여러 개의 레플리케이션 컨트롤러가 있을 수 있다. 예를 들어 일부 트래픽은 이전 버전으로 이동하고 일부는 새 버전으로 이동한다. +하나의 서비스 뒤에 여러 개의 레플리케이션컨트롤러가 있을 수 있다. +예를 들어 일부 트래픽은 이전 버전으로 이동하고 일부는 새 버전으로 이동한다. -레플리케이션 컨트롤러는 자체적으로 종료되지 않지만 서비스만큼 오래 지속될 것으로 기대되지는 않는다. 서비스는 여러 레플리케이션 컨트롤러에 의해 제어되는 파드로 구성될 수 있으며 서비스 라이프사이클 동안 (예를 들어 서비스를 실행하는 파드 업데이트 수행을 위해) -많은 레플리케이션 컨트롤러가 생성 및 제거될 것으로 예상된다. 서비스 자체와 클라이언트 모두 파드를 유지하는 레플리케이션 컨트롤러를 의식하지 않는 상태로 남아 있어야 한다. +레플리케이션컨트롤러는 자체적으로 종료되지 않지만, 서비스만큼 오래 지속될 것으로 기대되지는 않는다. 서비스는 여러 레플리케이션컨트롤러에 의해 제어되는 파드로 구성될 수 있으며, 서비스 라이프사이클 동안(예를 들어, 서비스를 실행하는 파드 업데이트 수행을 위해) 많은 레플리케이션컨트롤러가 생성 및 제거될 것으로 예상된다. 서비스 자체와 클라이언트 모두 파드를 유지하는 레플리케이션컨트롤러를 의식하지 않는 상태로 남아 있어야 한다. ## 레플리케이션을 위한 프로그램 작성 @@ -255,7 +255,7 @@ API 오브젝트에 대한 더 자세한 것은 [`레플리카셋`](/ko/docs/concepts/workloads/controllers/replicaset/)은 새로운 [집합성 기준 레이블 셀렉터](/ko/docs/concepts/overview/working-with-objects/labels/#집합성-기준-요건) 이다. 이것은 주로 [`디플로이먼트`](/ko/docs/concepts/workloads/controllers/deployment/) 에 의해 파드의 생성, 삭제 및 업데이트를 오케스트레이션 하는 메커니즘으로 사용된다. -사용자 지정 업데이트 조정이 필요하거나 업데이트가 필요하지 않은 경우가 아니면 레플리카 셋을 직접 사용하는 대신 디플로이먼트를 사용하는 것이 좋다. +사용자 지정 업데이트 조정이 필요하거나 업데이트가 필요하지 않은 경우가 아니면 레플리카셋을 직접 사용하는 대신 디플로이먼트를 사용하는 것이 좋다. ### 디플로이먼트 (권장되는) @@ -269,7 +269,7 @@ API 오브젝트에 대한 더 자세한 것은 ### 잡 자체적으로 제거될 것으로 예상되는 파드 (즉, 배치 잡)의 경우 -레플리케이션 컨트롤러 대신 [`잡`](/docs/concepts/jobs/run-to-completion-finite-workloads/)을 사용하라. +레플리케이션 컨트롤러 대신 [`잡`](/ko/docs/concepts/workloads/controllers/job/)을 사용하라. ### 데몬셋 @@ -280,6 +280,4 @@ API 오브젝트에 대한 더 자세한 것은 ## 더 자세한 정보는 -[스테이트리스 애플리케이션 레플리케이션 컨트롤러 실행하기](/docs/tutorials/stateless-application/run-stateless-ap-replication-controller/) 를 참조하라. - - +[스테이트리스 애플리케이션 레플리케이션 컨트롤러 실행하기](/docs/tutorials/stateless-application/run-stateless-ap-replication-controller/)를 참고한다. diff --git a/content/ko/docs/concepts/workloads/controllers/statefulset.md b/content/ko/docs/concepts/workloads/controllers/statefulset.md index 1779ea4f92..d588276b25 100644 --- a/content/ko/docs/concepts/workloads/controllers/statefulset.md +++ b/content/ko/docs/concepts/workloads/controllers/statefulset.md @@ -24,24 +24,25 @@ weight: 40 * 순차적인, 자동 롤링 업데이트. 위의 안정은 파드의 (재)스케줄링 전반에 걸친 지속성과 같은 의미이다. -만약 애플리케이션이 안정적인 식별자 또는 순차적인 배포, -삭제 또는 스케일링이 필요하지 않으면, 스테이트리스 레플리카 셋을 +만약 애플리케이션이 안정적인 식별자 또는 순차적인 배포, +삭제 또는 스케일링이 필요하지 않으면, 스테이트리스 레플리카셋(ReplicaSet)을 제공하는 워크로드 오브젝트를 사용해서 애플리케이션을 배포해야 한다. -[디플로이먼트](/ko/docs/concepts/workloads/controllers/deployment/) 또는 +[디플로이먼트](/ko/docs/concepts/workloads/controllers/deployment/) 또는 [레플리카셋](/ko/docs/concepts/workloads/controllers/replicaset/)과 같은 컨트롤러가 스테이트리스 요구에 더 적합할 수 있다. ## 제한사항 * 파드에 지정된 스토리지는 관리자에 의해 [퍼시스턴트 볼륨 프로비저너](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/staging/persistent-volume-provisioning/README.md)를 기반으로 하는 `storage class` 를 요청해서 프로비전하거나 사전에 프로비전이 되어야 한다. -* 스테이트풀셋을 삭제 또는 스케일 다운해도 스테이트풀셋과 연관된 볼륨이 *삭제되지 않는다*. 이는 일반적으로 스테이트풀셋과 연관된 모든 리소스를 자동으로 제거하는 것보다 더 중요한 데이터의 안전을 보장하기 위함이다. +* 스테이트풀셋을 삭제 또는 스케일 다운해도 스테이트풀셋과 연관된 볼륨이 *삭제되지 않는다*. 이는 일반적으로 스테이트풀셋과 연관된 모든 리소스를 자동으로 제거하는 것보다 더 중요한 데이터의 안전을 보장하기 위함이다. * 스테이트풀셋은 현재 파드의 네트워크 신원을 책임지고 있는 [헤드리스 서비스](/ko/docs/concepts/services-networking/service/#헤드리스-headless-서비스)가 필요하다. 사용자가 이 서비스를 생성할 책임이 있다. * 스테이트풀셋은 스테이트풀셋의 삭제 시 파드의 종료에 대해 어떠한 보증을 제공하지 않는다. 스테이트풀셋에서는 파드가 순차적이고 정상적으로 종료(graceful termination)되도록 하려면, 삭제 전 스테이트풀셋의 스케일을 0으로 축소할 수 있다. -* [롤링 업데이트](#롤링-업데이트)와 기본 +* [롤링 업데이트](#롤링-업데이트)와 기본 [파드 매니지먼트 폴리시](#파드-매니지먼트-폴리시) (`OrderedReady`)를 함께 사용시 [복구를 위한 수동 개입](#강제-롤백)이 필요한 파손 상태로 빠질 수 있다. ## 구성 요소 + 아래의 예시에서는 스테이트풀셋의 구성요소를 보여 준다. ```yaml @@ -100,9 +101,9 @@ spec: * 이름이 nginx라는 헤드리스 서비스는 네트워크 도메인을 컨트롤하는데 사용 한다. * 이름이 web인 스테이트풀셋은 3개의 nginx 컨테이너의 레플리카가 고유의 파드에서 구동될 것이라 지시하는 Spec을 갖는다. * volumeClaimTemplates은 퍼시스턴트 볼륨 프로비저너에서 프로비전한 [퍼시스턴트 볼륨](/ko/docs/concepts/storage/persistent-volumes/)을 사용해서 안정적인 스토리지를 제공한다. -스테이트풀셋 오브젝트의 이름은 유효한 -[DNS 서브도메인 이름](/ko/docs/concepts/overview/working-with-objects/names/#dns-서브도메인-이름들)이어야 한다. +스테이트풀셋 오브젝트의 이름은 유효한 +[DNS 서브도메인 이름](/ko/docs/concepts/overview/working-with-objects/names/#dns-서브도메인-이름)이어야 한다. ## 파드 셀렉터 @@ -110,9 +111,9 @@ spec: ## 파드 신원 -스테이트풀셋 파드는 순서, 안정적인 네트워크 신원 그리고 -안정적인 스토리지로 구성되는 고유한 신원을 가진다. 신원은 -파드가 어떤 노드에 있고, (재)스케줄과도 상관없이 파드에 붙어있다. +스테이트풀셋 파드는 순서, 안정적인 네트워크 신원 +그리고 안정적인 스토리지로 구성되는 고유한 신원을 가진다. +신원은 파드가 어떤 노드에 있고, (재)스케줄과도 상관없이 파드에 붙어있다. ### 순서 색인 @@ -121,23 +122,35 @@ N개의 레플리카가 있는 스테이트풀셋은 스테이트풀셋에 있 ### 안정적인 네트워크 신원 -스테이트풀셋의 각 파드는 스테이트풀셋의 이름과 파드의 순번에서 -호스트 이름을 얻는다. 호스트 이름을 구성하는 패턴은 -`$(statefulset name)-$(ordinal)` 이다. 위의 예시에서 생성된 3개 파드의 이름은 +스테이트풀셋의 각 파드는 스테이트풀셋의 이름과 파드의 순번에서 +호스트 이름을 얻는다. 호스트 이름을 구성하는 패턴은 +`$(statefulset name)-$(ordinal)` 이다. 위의 예시에서 생성된 3개 파드의 이름은 `web-0,web-1,web-2` 이다. -스테이트풀셋은 스테이트풀셋에 있는 파드의 도메인을 제어하기위해 +스테이트풀셋은 스테이트풀셋에 있는 파드의 도메인을 제어하기위해 [헤드리스 서비스](/ko/docs/concepts/services-networking/service/#헤드리스-headless-서비스)를 사용할 수 있다. -이 서비스가 관리하는 도메인은 `$(service name).$(namespace).svc.cluster.local` 의 형식을 가지며, +이 서비스가 관리하는 도메인은 `$(service name).$(namespace).svc.cluster.local` 의 형식을 가지며, 여기서 "cluster.local"은 클러스터 도메인이다. -각 파드는 생성되면 `$(podname).$(governing service domain)` 형식을 가지고 -일치되는 DNS 서브도메인을 가지며, 여기서 governing service는 +각 파드는 생성되면 `$(podname).$(governing service domain)` 형식을 가지고 +일치되는 DNS 서브도메인을 가지며, 여기서 거버닝 서비스(governing service)는 스테이트풀셋의 `serviceName` 필드에 의해 정의된다. +클러스터에서 DNS가 구성된 방식에 따라, 새로 실행된 파드의 DNS 이름을 +즉시 찾지 못할 수 있다. 이 동작은 클러스터의 다른 클라이언트가 +파드가 생성되기 전에 파드의 호스트 이름에 대한 쿼리를 이미 보낸 경우에 발생할 수 있다. +네거티브 캐싱(DNS에서 일반적)은 이전에 실패한 조회 결과가 +파드가 실행된 후에도 적어도 몇 초 동안 기억되고 재사용됨을 의미한다. + +파드를 생성한 후 즉시 파드를 검색해야 하는 경우, 몇 가지 옵션이 있다. + +- DNS 조회에 의존하지 않고 쿠버네티스 API를 직접(예를 들어 watch 사용) 쿼리한다. +- 쿠버네티스 DNS 공급자의 캐싱 시간(일반적으로 CoreDNS의 컨피그맵을 편집하는 것을 의미하며, 현재 30초 동안 캐시함)을 줄인다. + + [제한사항](#제한사항) 섹션에서 언급한 것처럼 사용자는 -파드의 네트워크 신원을 책임지는 +파드의 네트워크 신원을 책임지는 [헤드리스 서비스](/ko/docs/concepts/services-networking/service/#헤드리스-headless-서비스)를 생성할 책임이 있다. -여기 클러스터 도메인, 서비스 이름, 스테이트풀셋 이름을 선택을 하고, +여기 클러스터 도메인, 서비스 이름, 스테이트풀셋 이름을 선택을 하고, 그 선택이 스테이트풀셋 파드의 DNS이름에 어떻게 영향을 주는지에 대한 약간의 예시가 있다. 클러스터 도메인 | 서비스 (ns/이름) | 스테이트풀셋 (ns/이름) | 스테이트풀셋 도메인 | 파드 DNS | 파드 호스트 이름 | @@ -147,26 +160,26 @@ N개의 레플리카가 있는 스테이트풀셋은 스테이트풀셋에 있 kube.local | foo/nginx | foo/web | nginx.foo.svc.kube.local | web-{0..N-1}.nginx.foo.svc.kube.local | web-{0..N-1} | {{< note >}} -클러스터 도메인이 달리 [구성된 경우](/ko/docs/concepts/services-networking/dns-pod-service/)가 +클러스터 도메인이 달리 [구성된 경우](/ko/docs/concepts/services-networking/dns-pod-service/)가 아니라면 `cluster.local`로 설정된다. {{< /note >}} ### 안정된 스토리지 -쿠버네티스는 각 VolumeClaimTemplate마다 하나의 [퍼시스턴트 볼륨](/ko/docs/concepts/storage/persistent-volumes/)을 -생성한다. 위의 nginx 예시에서 각 파드는 `my-storage-class` 라는 스토리지 클래스와 -1 Gib의 프로비전된 스토리지를 가지는 단일 퍼시스턴트 볼륨을 받게된다. 만약 스토리지 클래스가 -명시되지 않은 경우 기본 스토리지 클래스를 사용된다. 파드가 노드에서 스케줄 혹은 재스케줄이되면 +쿠버네티스는 각 VolumeClaimTemplate마다 하나의 [퍼시스턴트 볼륨](/ko/docs/concepts/storage/persistent-volumes/)을 +생성한다. 위의 nginx 예시에서 각 파드는 `my-storage-class` 라는 스토리지 클래스와 +1 Gib의 프로비전된 스토리지를 가지는 단일 퍼시스턴트 볼륨을 받게 된다. 만약 스토리지 클래스가 +명시되지 않은 경우, 기본 스토리지 클래스가 사용된다. 파드가 노드에서 스케줄 혹은 재스케줄이 되면 파드의 `volumeMounts` 는 퍼시스턴트 볼륨 클레임과 관련된 퍼시스턴트 볼륨이 마운트 된다. -참고로, 파드 퍼시스턴트 볼륨 클레임과 관련된 퍼시스턴트 볼륨은 +참고로, 파드 퍼시스턴트 볼륨 클레임과 관련된 퍼시스턴트 볼륨은 파드 또는 스테이트풀셋이 삭제되더라도 삭제되지 않는다. 이것은 반드시 수동으로 해야한다. ### 파드 이름 레이블 스테이트풀셋 {{< glossary_tooltip term_id="controller" >}} -가 파드를 생성할 때 파드 이름으로 `statefulset.kubernetes.io/pod-name` -레이블이 추가된다. 이 레이블로 스테이트풀셋의 특정 파드에 서비스를 +가 파드를 생성할 때 파드 이름으로 `statefulset.kubernetes.io/pod-name` +레이블이 추가된다. 이 레이블로 스테이트풀셋의 특정 파드에 서비스를 연결할 수 있다. ## 디플로이먼트와 스케일링 보증 @@ -178,87 +191,87 @@ N개의 레플리카가 있는 스테이트풀셋은 스테이트풀셋에 있 스테이트풀셋은 `pod.Spec.TerminationGracePeriodSeconds` 을 0으로 명시해서는 안된다. 이 방법은 안전하지 않으며, 사용하지 않기를 강권한다. 자세한 설명은 [스테이트풀셋 파드 강제 삭제](/docs/tasks/run-application/force-delete-stateful-set-pod/)를 참고한다. -위의 nginx 예시가 생성될 때 web-0, web-1, web-2 순서로 3개 파드가 -배포된다. web-1은 web-0이 -[Running 및 Ready](/ko/docs/concepts/workloads/pods/pod-lifecycle/) 상태가 되기 전에는 배포되지 않으며, -web-2 도 web-1이 Running 및 Ready 상태가 되기 전에는 배포되지 않는다. 만약 web-1이 Running 및 Ready 상태가 된 이후, -web-2가 시작되기 전에 web-0이 실패하게 된다면, web-2는 web-0이 성공적으로 재시작이되고, +위의 nginx 예시가 생성될 때 web-0, web-1, web-2 순서로 3개 파드가 +배포된다. web-1은 web-0이 +[Running 및 Ready](/ko/docs/concepts/workloads/pods/pod-lifecycle/) 상태가 되기 전에는 배포되지 않으며, +web-2 도 web-1이 Running 및 Ready 상태가 되기 전에는 배포되지 않는다. 만약 web-1이 Running 및 Ready 상태가 된 이후, +web-2가 시작되기 전에 web-0이 실패하게 된다면, web-2는 web-0이 성공적으로 재시작이되고, Running 및 Ready 상태가 되기 전까지 시작되지 않는다. -만약 사용자가 배포된 예제의 스테이트풀셋을 `replicas=1` 으로 패치해서 -스케일한 경우 web-2가 먼저 종료된다. web-1은 web-2가 완전히 종료 및 삭제되기 -전까지 정지되지 않는다. 만약 web-2의 종료 및 완전히 중지되고, web-1이 종료되기 전에 -web-0이 실패할 경우 web-1은 web-0이 Running 및 Ready 상태가 +만약 사용자가 배포된 예제의 스테이트풀셋을 `replicas=1` 으로 패치해서 +스케일한 경우 web-2가 먼저 종료된다. web-1은 web-2가 완전히 종료 및 삭제되기 +전까지 정지되지 않는다. 만약 web-2의 종료 및 완전히 중지되고, web-1이 종료되기 전에 +web-0이 실패할 경우 web-1은 web-0이 Running 및 Ready 상태가 되기 전까지 종료되지 않는다. ### 파드 관리 정책 -쿠버네티스 1.7 및 이후에는 스테이트풀셋의 `.spec.podManagementPolicy` 필드를 +쿠버네티스 1.7 및 이후에는 스테이트풀셋의 `.spec.podManagementPolicy` 필드를 통해 고유성 및 신원 보증을 유지하면서 순차 보증을 완화한다. #### OrderedReady 파드 관리 -`OrderedReady` 파드 관리는 스테이트풀셋의 기본이다. +`OrderedReady` 파드 관리는 스테이트풀셋의 기본이다. 이것은 [위에서](#디플로이먼트와-스케일-보증) 설명한 행위를 구현한다. #### 병렬 파드 관리 -`병렬` 파드 관리는 스테이트풀셋 컨트롤러에게 모든 파드를 -병렬로 실행 또는 종료하게 한다. 그리고 다른 파드의 실행이나 +`병렬` 파드 관리는 스테이트풀셋 컨트롤러에게 모든 파드를 +병렬로 실행 또는 종료하게 한다. 그리고 다른 파드의 실행이나 종료에 앞서 파드가 Running 및 Ready 상태가 되거나 완전히 종료되기를 기다리지 않는다. -이 옵션은 오직 스케일링 작업에 대한 동작에만 영향을 미친다. 업데이트는 영향을 +이 옵션은 오직 스케일링 작업에 대한 동작에만 영향을 미친다. 업데이트는 영향을 받지 않는다. ## 업데이트 전략 -쿠버네티스 1.7 및 이후에는 스테이트풀셋의 `.spec.updateStrategy` 필드는 스테이트풀셋의 -파드에 대한 컨테이너, 레이블, 리소스의 요청/제한 그리고 주석에 대한 자동화된 롤링 업데이트를 +쿠버네티스 1.7 및 이후에는 스테이트풀셋의 `.spec.updateStrategy` 필드는 스테이트풀셋의 +파드에 대한 컨테이너, 레이블, 리소스의 요청/제한 그리고 주석에 대한 자동화된 롤링 업데이트를 구성하거나 비활성화 할 수 있다. ### 삭제 시(On Delete) -`OnDelete` 업데이트 전략은 레거시(1.6과 이전)의 행위를 구현한다. 이때 스테이트풀셋의 -`.spec.updateStrategy.type` 은 `OnDelete` 를 설정하며, 스테이트풀셋 컨트롤러는 -스테이트풀셋의 파드를 자동으로 업데이트하지 않는다. 사용자는 컨트롤러가 스테이트풀셋의 +`OnDelete` 업데이트 전략은 레거시(1.6과 이전)의 행위를 구현한다. 이때 스테이트풀셋의 +`.spec.updateStrategy.type` 은 `OnDelete` 를 설정하며, 스테이트풀셋 컨트롤러는 +스테이트풀셋의 파드를 자동으로 업데이트하지 않는다. 사용자는 컨트롤러가 스테이트풀셋의 `.spec.template`를 반영하는 수정된 새로운 파드를 생성하도록 수동으로 파드를 삭제해야 한다. ### 롤링 업데이트 -`롤링 업데이트` 의 업데이트 전략은 스테이트풀셋의 파드에 대한 롤링 업데이트를 -구현한다. 롤링 업데이트는 `.spec.updateStrategy` 가 지정되지 않으면 기본 전략이 된다. 스테이트풀셋에 `롤링 업데이트` 가 `.spec.updateStrategy.type` 에 설정되면 -스테이트풀셋 컨트롤러는 스테이트풀셋의 각 파드를 삭제 및 재생성을 한다. 이 과정에서 똑같이 -순차적으로 파드가 종료되고(가장 큰 수에서 작은 수까지), -각 파드의 업데이트는 한번에 하나씩 한다. 이전 버전을 업데이트하기 전까지 업데이트된 파드가 실행 및 준비될 +`롤링 업데이트` 의 업데이트 전략은 스테이트풀셋의 파드에 대한 롤링 업데이트를 +구현한다. 롤링 업데이트는 `.spec.updateStrategy` 가 지정되지 않으면 기본 전략이 된다. 스테이트풀셋에 `롤링 업데이트` 가 `.spec.updateStrategy.type` 에 설정되면 +스테이트풀셋 컨트롤러는 스테이트풀셋의 각 파드를 삭제 및 재생성을 한다. 이 과정에서 똑같이 +순차적으로 파드가 종료되고(가장 큰 수에서 작은 수까지), +각 파드의 업데이트는 한 번에 하나씩 한다. 이전 버전을 업데이트하기 전까지 업데이트된 파드가 실행 및 준비될 때까지 기다린다. #### 파티션(Partition) -`롤링 업데이트` 의 업데이트 전략은 `.spec.updateStrategy.rollingUpdate.partition` -를 명시해서 파티션 할 수 있다. 만약 파티션을 명시하면 스테이트풀셋의 `.spec.template` 가 +`롤링 업데이트` 의 업데이트 전략은 `.spec.updateStrategy.rollingUpdate.partition` +를 명시해서 파티션 할 수 있다. 만약 파티션을 명시하면 스테이트풀셋의 `.spec.template` 가 업데이트 될 때 부여된 수가 파티션보다 크거나 같은 모든 파드가 업데이트 된다. -파티션보다 작은 수를 가진 모든 파드는 업데이트 되지 않으며, +파티션보다 작은 수를 가진 모든 파드는 업데이트 되지 않으며, 삭제 된 경우라도 이전 버전에서 재생성된다. -만약 스테이트풀셋의 `.spec.updateStrategy.rollingUpdate.partition` 이 +만약 스테이트풀셋의 `.spec.updateStrategy.rollingUpdate.partition` 이 `.spec.replicas` 보다 큰 경우 `.spec.template` 의 업데이트는 해당 파드에 전달하지 않는다. -대부분의 케이스는 파티션을 사용할 필요가 없지만 업데이트를 준비하거나, +대부분의 케이스는 파티션을 사용할 필요가 없지만 업데이트를 준비하거나, 카나리의 롤 아웃 또는 단계적인 롤 아웃을 행하려는 경우에는 유용하다. #### 강제 롤백 -기본 [파드 관리 정책](#파드-관리-정책) (`OrderedReady`)과 -함께 [롤링 업데이트](#롤링-업데이트)를 사용할 경우 +기본 [파드 관리 정책](#파드-관리-정책) (`OrderedReady`)과 +함께 [롤링 업데이트](#롤링-업데이트)를 사용할 경우 직접 수동으로 복구를 해야하는 고장난 상태가 될 수 있다. -만약 파드 템플릿을 Running 및 Ready 상태가 되지 않는 구성으로 업데이트하는 -경우(예시: 잘못된 바이너리 또는 애플리케이션-레벨 구성 오류로 인한) +만약 파드 템플릿을 Running 및 Ready 상태가 되지 않는 구성으로 업데이트하는 +경우(예시: 잘못된 바이너리 또는 애플리케이션-레벨 구성 오류로 인한) 스테이트풀셋은 롤아웃을 중지하고 기다린다. 이 상태에서는 파드 템플릿을 올바른 구성으로 되돌리는 것으로 충분하지 않다. -[알려진 이슈](https://github.com/kubernetes/kubernetes/issues/67250)로 -인해 스테이트풀셋은 손상된 파드가 준비(절대 되지 않음)될 때까지 기다리며 -작동하는 구성으로 되돌아가는 시도를 하기 +[알려진 이슈](https://github.com/kubernetes/kubernetes/issues/67250)로 +인해 스테이트풀셋은 손상된 파드가 준비(절대 되지 않음)될 때까지 기다리며 +작동하는 구성으로 되돌아가는 시도를 하기 전까지 기다린다. -템플릿을 되돌린 이후에는 스테이트풀셋이 이미 잘못된 구성으로 +템플릿을 되돌린 이후에는 스테이트풀셋이 이미 잘못된 구성으로 실행하려고 시도한 모든 파드를 삭제해야 한다. 그러면 스테이트풀셋은 되돌린 템플릿을 사용해서 파드를 다시 생성하기 시작 한다. @@ -269,6 +282,3 @@ web-0이 실패할 경우 web-1은 web-0이 Running 및 Ready 상태가 * [스테이트풀 애플리케이션의 배포](/ko/docs/tutorials/stateful-application/basic-stateful-set/)의 예시를 따른다. * [카산드라와 스테이트풀셋 배포](/ko/docs/tutorials/stateful-application/cassandra/)의 예시를 따른다. * [레플리케이티드(replicated) 스테이트풀 애플리케이션 실행하기](/docs/tasks/run-application/run-replicated-stateful-application/)의 예시를 따른다. - - - diff --git a/content/ko/docs/concepts/workloads/controllers/ttlafterfinished.md b/content/ko/docs/concepts/workloads/controllers/ttlafterfinished.md index c095dd31c5..3d110ee6c6 100644 --- a/content/ko/docs/concepts/workloads/controllers/ttlafterfinished.md +++ b/content/ko/docs/concepts/workloads/controllers/ttlafterfinished.md @@ -1,7 +1,7 @@ --- title: 완료된 리소스를 위한 TTL 컨트롤러 content_type: concept -weight: 65 +weight: 70 --- <!-- overview --> @@ -10,12 +10,13 @@ weight: 65 TTL 컨트롤러는 실행이 완료된 리소스 오브젝트의 수명을 제한하는 TTL (time to live) 메커니즘을 제공한다. TTL 컨트롤러는 현재 -[잡(Job)](/ko/docs/concepts/workloads/controllers/jobs-run-to-completion/)만 +{{< glossary_tooltip text="잡(Job)" term_id="job" >}}만 처리하며, 파드와 커스텀 리소스와 같이 실행을 완료할 다른 리소스를 처리하도록 확장될 수 있다. -알파(Alpha) 고지 사항: 이 기능은 현재 알파이다, 그리고 kube-apiserver 와 kube-controller-manager 와 함께 -[기능 게이트](/docs/reference/command-line-tools-reference/feature-gates/) 로 `TTLAfterFinished` 를 활성화 할 수 있다. +알파(Alpha) 고지 사항: 이 기능은 현재 알파이고, +kube-apiserver와 kube-controller-manager와 함께 +[기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)로 `TTLAfterFinished` 를 활성화할 수 있다. @@ -28,7 +29,7 @@ TTL 컨트롤러는 실행이 완료된 리소스 오브젝트의 수명을 ## TTL 컨트롤러 현재의 TTL 컨트롤러는 잡만 지원한다. 클러스터 운영자는 -[예시](/ko/docs/concepts/workloads/controllers/jobs-run-to-completion/#완료된-잡을-자동으로-정리) +[예시](/ko/docs/concepts/workloads/controllers/job/#완료된-잡을-자동으로-정리) 와 같이 `.spec.ttlSecondsAfterFinished` 필드를 명시하여 완료된 잡(`완료` 또는 `실패`)을 자동으로 정리하기 위해 이 기능을 사용할 수 있다. 리소스의 작업이 완료된 TTL 초(sec) 후 (다른 말로는, TTL이 만료되었을 때), @@ -66,13 +67,13 @@ TTL 기간은, 예를 들어 잡의 `.spec.ttlSecondsAfterFinished` 필드는 ### 시간 차이(Skew) TTL 컨트롤러는 쿠버네티스 리소스에 -저장된 타임스탬프를 사용해서 TTL의 만료 여부를 결정하기 때문에, 이 기능은 클러스터 간의 +저장된 타임스탬프를 사용해서 TTL의 만료 여부를 결정하기 때문에, 이 기능은 클러스터 간의 시간 차이에 민감하며, 시간 차이에 의해서 TTL 컨트롤러가 잘못된 시간에 리소스 오브젝트를 정리하게 될 수 있다. 쿠버네티스에서는 시간 차이를 피하기 위해 모든 노드 ([#6159](https://github.com/kubernetes/kubernetes/issues/6159#issuecomment-93844058)를 본다) -에서 NTP를 실행해야 한다. 시계가 항상 정확한 것은 아니지만, 그 차이는 +에서 NTP를 실행해야 한다. 시계가 항상 정확한 것은 아니지만, 그 차이는 아주 작아야 한다. 0이 아닌 TTL을 설정할때는 이 위험에 대해 유의해야 한다. @@ -83,5 +84,3 @@ TTL 컨트롤러는 쿠버네티스 리소스에 [자동으로 잡 정리](/ko/docs/concepts/workloads/controllers/jobs-run-to-completion/#완료된-잡을-자동으로-정리) [디자인 문서](https://github.com/kubernetes/enhancements/blob/master/keps/sig-apps/0026-ttl-after-finish.md) - - diff --git a/content/ko/docs/concepts/workloads/pods/disruptions.md b/content/ko/docs/concepts/workloads/pods/disruptions.md index bd2f2023af..0e46b4bf5e 100644 --- a/content/ko/docs/concepts/workloads/pods/disruptions.md +++ b/content/ko/docs/concepts/workloads/pods/disruptions.md @@ -9,7 +9,7 @@ weight: 60 파드에서 발생하는 장애 유형을 이해하기 원하는 애플리케이션 소유자를 위한 것이다. -또한 클러스터의 업그레이드와 오토스케일링과 같은 +또한 클러스터의 업그레이드와 오토스케일링과 같은 클러스터의 자동화 작업을 하려는 관리자를 위한 것이다. @@ -19,7 +19,7 @@ weight: 60 ## 자발적 중단과 비자발적 중단 -파드는 누군가(사람 또는 컨트롤러)가 파괴하거나 +파드는 누군가(사람 또는 컨트롤러)가 파괴하거나 불가피한 하드웨어 오류 또는 시스템 소프트웨어 오류가 아니면 사라지지 않는다. 우리는 이런 불가피한 상황을 애플리케이션의 *비자발적 중단* 으로 부른다. @@ -33,7 +33,8 @@ weight: 60 - 노드의 [리소스 부족](/docs/tasks/administer-cluster/out-of-resource/)으로 파드가 축출됨 리소스 부족을 제외한 나머지 조건은 대부분의 사용자가 익숙할 것이다. -왜냐하면 그 조건은 쿠버네티스에 국한되지 않기 때문이다. +왜냐하면 +그 조건은 쿠버네티스에 국한되지 않기 때문이다. 우리는 다른 상황을 *자발적인 중단* 으로 부른다. 여기에는 애플리케이션 소유자의 작업과 클러스터 관리자의 작업이 모두 포함된다. @@ -46,19 +47,21 @@ weight: 60 클러스터 관리자의 작업: - 복구 또는 업그레이드를 위한 [노드 드레이닝](/docs/tasks/administer-cluster/safely-drain-node/). -- 클러스터의 스케일 축소를 위한 노드 드레이닝([클러스터 오토스케일링](/ko/docs/tasks/administer-cluster/cluster-management/#cluster-autoscaler)에 대해 알아보기). +- 클러스터의 스케일 축소를 위한 + 노드 드레이닝([클러스터 오토스케일링](/ko/docs/tasks/administer-cluster/cluster-management/#클러스터-오토스케일링)에 대해 알아보기 + ). - 노드에 다른 무언가를 추가하기 위해 파드를 제거. 위 작업은 클러스터 관리자가 직접 수행하거나 자동화를 통해 수행하며, 클러스터 호스팅 공급자에 의해서도 수행된다. -클러스터에 자발적인 중단을 일으킬 수 있는 어떤 원인이 있는지 +클러스터에 자발적인 중단을 일으킬 수 있는 어떤 원인이 있는지 클러스터 관리자에게 문의하거나 클라우드 공급자에게 문의하고, 배포 문서를 참조해서 확인해야 한다. 만약 자발적인 중단을 일으킬 수 있는 원인이 없다면 Pod Disruption Budget의 생성을 넘길 수 있다. {{< caution >}} 모든 자발적인 중단이 Pod Disruption Budget에 연관되는 것은 아니다. -예를 들어 디플로이먼트 또는 파드의 삭제는 Pod Disruption Budget를 무시한다. +예를 들어 디플로이먼트 또는 파드의 삭제는 Pod Disruption Budget을 무시한다. {{< /caution >}} ## 중단 다루기 @@ -66,48 +69,58 @@ weight: 60 비자발적인 중단으로 인한 영향을 경감하기 위한 몇 가지 방법은 다음과 같다. - 파드가 필요로 하는 [리소스를 요청](/docs/tasks/configure-pod-container/assign-cpu-ram-container)하는지 확인한다. -- 고가용성이 필요한 경우 애플리케이션을 복제한다. (복제된 [스테이트리스](/docs/tasks/run-application/run-stateless-application-deployment/) 및 [스테이트풀](/docs/tasks/run-application/run-replicated-stateful-application/)애플리케이션에 대해 알아보기.) -- 복제된 애플리케이션의 구동 시 훨씬 더 높은 가용성을 위해 랙 전체([안티-어피니티](/docs/user-guide/node-selection/#inter-pod-affinity-and-anti-affinity-beta-feature) 이용) 또는 -영역 간(또는 [다중 영역 클러스터](/ko/docs/setup/best-practices/multiple-zones/)를 이용한다.)에 -애플리케이션을 분산해야 한다. +- 고가용성이 필요한 경우 애플리케이션을 복제한다. + (복제된 [스테이트리스](/docs/tasks/run-application/run-stateless-application-deployment/) 및 + [스테이트풀](/docs/tasks/run-application/run-replicated-stateful-application/) 애플리케이션에 대해 알아보기.) +- 복제된 애플리케이션의 구동 시 훨씬 더 높은 가용성을 위해 랙 전체 + ([안티-어피니티](/ko/docs/concepts/scheduling-eviction/assign-pod-node/#파드간-어피니티와-안티-어피니티) 이용) + 또는 영역 간 + ([다중 영역 클러스터](/docs/setup/multiple-zones)를 이용한다면)에 + 애플리케이션을 분산해야 한다. 자발적 중단의 빈도는 다양하다. 기본적인 쿠버네티스 클러스터에서는 자발적인 운영 중단이 전혀 없다. 그러나 클러스터 관리자 또는 호스팅 공급자가 자발적 중단이 발생할 수 있는 일부 부가 서비스를 운영할 수 있다. 예를 들어 노드 소프트웨어의 업데이트를 출시하는 경우 자발적 중단이 발생할 수 있다. -또한 클러스터(노드) 오토스케일링의 일부 구현에서는 단편화를 제거하고 노드의 효율을 높이는 과정에서 자발적 중단을 야기할 수 있다. -클러스터 관리자 또는 호스팅 공급자는 예측 가능한 자발적 중단 수준에 대해 문서화해야 한다. +또한 클러스터(노드) 오토스케일링의 일부 구현에서는 +단편화를 제거하고 노드의 효율을 높이는 과정에서 자발적 중단을 야기할 수 있다. +클러스터 관리자 또는 호스팅 공급자는 +예측 가능한 자발적 중단 수준에 대해 문서화해야 한다. 쿠버네티스는 자주 발생하는 자발적 중단에도 고가용성 애플리케이션을 -실행 할 수 있는 기능을 제공한다. +실행 할 수 있는 기능을 제공한다. 우리는 이 기능을 *Disruption Budgets* 이라 부른다. + ## Disruption Budgets의 작동 방식 {{< feature-state for_k8s_version="v1.5" state="beta" >}} 애플리케이션 소유자는 각 애플리케이션에 대해 `PodDisruptionBudget` 오브젝트(PDB)를 만들 수 있다. -PDB는 자발적 중단으로 일시에 중지되는 복제된 애플리케이션 파드의 수를 제한한다. -예를 들어 정족수 기반의 애플리케이션이 +PDB는 자발적 중단으로 +일시에 중지되는 복제된 애플리케이션 파드의 수를 제한한다. +예를 들어 정족수 기반의 애플리케이션이 실행 중인 레플리카의 수가 정족수 이하로 떨어지지 않도록 한다. -웹 프런트 엔드는 부하를 처리하는 레플리카의 수가 +웹 프런트 엔드는 부하를 처리하는 레플리카의 수가 일정 비율 이하로 떨어지지 않도록 보장할 수 있다. -클러스터 관리자와 호스팅 공급자는 직접적으로 파드나 디플로이먼트를 제거하는 대신 -[Eviction API](/docs/tasks/administer-cluster/safely-drain-node/#the-eviction-api)로 -불리는 Pod Disruption Budgets를 준수하는 도구를 이용해야 한다. +클러스터 관리자와 호스팅 공급자는 직접적으로 파드나 디플로이먼트를 제거하는 대신 +[Eviction API](/docs/tasks/administer-cluster/safely-drain-node/#the-eviction-api)로 +불리는 Pod Disruption Budget을 준수하는 도구를 이용해야 한다. 예를 들어 `kubectl drain` 명령어나 Kubernetes-on-GCE 클러스터 업그레이드 스크립트(`cluster/gce/upgrade.sh`)이다. 클러스터 관리자가 노드를 비우고자 할 경우에는 `kubectl drain` 명령어를 사용한다. 해당 도구는 머신에 존재하는 모든 파드를 축출하려는 시도를 한다. -축출 요청은 일시적으로 거부될 수 있으며, 도구는 모든 파드가 종료되거나 +축출 요청은 일시적으로 거부될 수 있으며, +도구는 모든 파드가 종료되거나 설정 가능한 타임아웃이 도래할 때까지 주기적으로 모든 실패된 요청을 다시 시도한다. PDB는 애플리케이션이 필요로 하는 레플리카의 수에 상대적으로, 용인할 수 있는 레플리카의 수를 지정한다. 예를 들어 `.spec.replicas: 5` 의 값을 갖는 디플로이먼트는 어느 시점에든 5개의 파드를 가져야 한다. -만약 해당 디플로이먼트의 PDB가 특정 시점에 파드를 4개 허용한다면, Eviction API는 한 번에 2개의 파드가 아닌, 1개의 파드의 자발적인 중단을 허용한다. +만약 해당 디플로이먼트의 PDB가 특정 시점에 파드를 4개 허용한다면, +Eviction API는 한 번에 2개의 파드가 아닌, 1개의 파드의 자발적인 중단을 허용한다. -파드 그룹은 레이블 셀렉터를 사용해서 지정한 애플리케이션으로 구성되며 -애플리케이션 컨트롤러(디플로이먼트, 스테이트풀 셋 등)를 사용한 것과 같다. +파드 그룹은 레이블 셀렉터를 사용해서 지정한 애플리케이션으로 구성되며 +애플리케이션 컨트롤러(디플로이먼트, 스테이트풀셋 등)를 사용한 것과 같다. 파드의 "의도"하는 수량은 파드 컨트롤러의 `.spec.replicas` 를 기반으로 계산한다. 컨트롤러는 오브젝트의 `.metadata.ownerReferences` 를 사용해서 파드를 발견한다. @@ -116,7 +129,8 @@ PDB는 [비자발적 중단](#자발적-중단과-비자발적-중단)이 발생 버짓이 차감된다. 애플리케이션의 롤링 업그레이드로 파드가 삭제되거나 사용할 수 없는 경우 중단 버짓에 영향을 준다. -그러나 컨트롤러(디플로이먼트, 스테이트풀 셋과 같은)는 롤링 업데이트시 PDB의 제한을 받지 않는다. +그러나 컨트롤러(디플로이먼트, 스테이트풀셋과 같은)는 +롤링 업데이트시 PDB의 제한을 받지 않는다. 애플리케이션 업데이트 진행 중 발생하는 중단 처리는 컨트롤러 사양에 구성되어있다. ([디플로이먼트 업데이트](/ko/docs/concepts/workloads/controllers/deployment/#디플로이먼트-업데이트)에 대해 알아보기.) @@ -126,7 +140,7 @@ PDB는 [비자발적 중단](#자발적-중단과-비자발적-중단)이 발생 ## PDB 예시 `node-1` 부터 `node-3` 까지 3개의 노드가 있는 클러스터가 있다고 하자. -클러스터에는 여러 애플리케이션을 실행하고 있다. +클러스터에는 여러 애플리케이션을 실행하고 있다. 여러 애플리케이션 중 하나는 `pod-a`, `pod-b`, `pod-c` 로 부르는 3개의 레플리카가 있다. 여기에 `pod-x` 라고 부르는 PDB와 무관한 파드가 보인다. 초기에 파드는 다음과 같이 배치된다. @@ -135,7 +149,8 @@ PDB는 [비자발적 중단](#자발적-중단과-비자발적-중단)이 발생 | pod-a *available* | pod-b *available* | pod-c *available* | | pod-x *available* | | | -전체 3개 파드는 디플로이먼트의 일부분으로 전체적으로 항상 3개의 파드 중 최소 2개의 파드를 사용할 수 있도록 하는 PDB를 가지고 있다. +전체 3개 파드는 디플로이먼트의 일부분으로 +전체적으로 항상 3개의 파드 중 최소 2개의 파드를 사용할 수 있도록 하는 PDB를 가지고 있다. 예를 들어, 클러스터 관리자가 커널 버그를 수정하기위해 새 커널 버전으로 재부팅하려는 경우를 가정해보자. 클러스터 관리자는 첫째로 `node-1` 을 `kubectl drain` 명령어를 사용해서 비우려 한다. @@ -149,12 +164,12 @@ PDB는 [비자발적 중단](#자발적-중단과-비자발적-중단)이 발생 | pod-x *terminating* | | | 디플로이먼트는 한 개의 파드가 중지되는 것을 알게되고, `pod-d` 라는 대체 파드를 생성한다. -`node-1` 은 차단되어 있어 다른 노드에 위치한다. +`node-1` 은 차단되어 있어 다른 노드에 위치한다. 무언가가 `pod-x` 의 대체 파드로 `pod-y` 도 생성했다. -(참고: 스테이트풀 셋은 `pod-0`처럼 불릴, `pod-a`를 +(참고: 스테이트풀셋은 `pod-0` 처럼 불릴, `pod-a` 를 교체하기 전에 완전히 중지해야 하며, `pod-0` 로 불리지만, 다른 UID로 생성된다. -그렇지 않으면 이 예시는 스테이트풀 셋에도 적용된다.) +그렇지 않으면 이 예시는 스테이트풀셋에도 적용된다.) 이제 클러스터는 다음과 같은 상태이다. @@ -170,9 +185,9 @@ PDB는 [비자발적 중단](#자발적-중단과-비자발적-중단)이 발생 | | pod-b *available* | pod-c *available* | | | pod-d *starting* | pod-y | -이 시점에서 만약 성급한 클러스터 관리자가 `node-2` 또는 `node-3` 을 -비우려고 하는 경우 디플로이먼트에 available 상태의 파드가 2개 뿐이고, -PDB에 필요한 최소 파드는 2개이기 때문에 drain 명령이 차단된다. 약간의 시간이 지나면 `pod-d`가 available 상태가 된다. +이 시점에서 만약 성급한 클러스터 관리자가 `node-2` 또는 `node-3` 을 +비우려고 하는 경우 디플로이먼트에 available 상태의 파드가 2개 뿐이고, +PDB에 필요한 최소 파드는 2개이기 때문에 drain 명령이 차단된다. 약간의 시간이 지나면 `pod-d` 가 available 상태가 된다. 이제 클러스터는 다음과 같은 상태이다. @@ -182,13 +197,13 @@ PDB에 필요한 최소 파드는 2개이기 때문에 drain 명령이 차단된 | | pod-d *available* | pod-y | 이제 클러스터 관리자는 `node-2` 를 비우려고 한다. -drain 커멘드는 `pod-b`에서 `pod-d`와 같이 어떤 순서대로 두 파드를 축출하려 할 것이다. -drain 커멘드는 `pod-b`를 축출하는데 성공했다. -그러나 drain 커멘드가 `pod-d` 를 축출하려 하는 경우 +drain 커멘드는 `pod-b` 에서 `pod-d` 와 같이 어떤 순서대로 두 파드를 축출하려 할 것이다. +drain 커멘드는 `pod-b` 를 축출하는데 성공했다. +그러나 drain 커멘드가 `pod-d` 를 축출하려 하는 경우 디플로이먼트에 available 상태의 파드는 1개로 축출이 거부된다. -디플로이먼트는`pod-b` 를 대체할 `pod-e`라는 파드를 생성한다. -클러스터에 `pod-e` 를 스케줄하기 위한 충분한 리소스가 없기 때문에 +디플로이먼트는`pod-b` 를 대체할 `pod-e` 라는 파드를 생성한다. +클러스터에 `pod-e` 를 스케줄하기 위한 충분한 리소스가 없기 때문에 드레이닝 명령어는 차단된다. 클러스터는 다음 상태로 끝나게 된다. @@ -200,7 +215,7 @@ drain 커멘드는 `pod-b`를 축출하는데 성공했다. 이 시점에서 클러스터 관리자는 클러스터에 노드를 추가해서 업그레이드를 진행해야 한다. -쿠버네티스에 중단이 발생할 수 있는 비율을 어떻게 변화시키는지 +쿠버네티스에 중단이 발생할 수 있는 비율을 어떻게 변화시키는지 다음의 사례를 통해 알 수 있다. - 애플리케이션에 필요한 레플리카의 수 @@ -211,28 +226,29 @@ drain 커멘드는 `pod-b`를 축출하는데 성공했다. ## 클러스터 소유자와 애플리케이션 소유자의 역할 분리 -보통 클러스터 매니저와 애플리케이션 소유자는 +보통 클러스터 매니저와 애플리케이션 소유자는 서로에 대한 지식이 부족한 별도의 역할로 생각하는 것이 유용하다. -이와 같은 책임의 분리는 +이와 같은 책임의 분리는 다음의 시나리오에서 타당할 수 있다. - 쿠버네티스 클러스터를 공유하는 애플리케이션 팀이 많고, 자연스럽게 역할이 나누어진 경우 -- 타사 도구 또는 타사 서비스를 이용해서 클러스터 관리를 자동화 하는 경우 +- 타사 도구 또는 타사 서비스를 이용해서 + 클러스터 관리를 자동화 하는 경우 -Pod Disruption Budgets는 역할 분리에 따라 +Pod Disruption Budget은 역할 분리에 따라 역할에 맞는 인터페이스를 제공한다. 만약 조직에 역할 분리에 따른 책임의 분리가 없다면 -Pod Disruption Budgets를 사용할 필요가 없다. +Pod Disruption Budget을 사용할 필요가 없다. ## 클러스터에서 중단이 발생할 수 있는 작업을 하는 방법 -만약 클러스터 관리자라면, 그리고 클러스터 전체 노드에 노드 또는 시스템 소프트웨어 업그레이드와 같은 +만약 클러스터 관리자라면, 그리고 클러스터 전체 노드에 노드 또는 시스템 소프트웨어 업그레이드와 같은 중단이 발생할 수 있는 작업을 수행하는 경우 다음과 같은 옵션을 선택한다. - 업그레이드 하는 동안 다운타임을 허용한다. - 다른 레플리카 클러스터로 장애조치를 한다. - - 다운타임은 없지만, 노드 사본과 + - 다운타임은 없지만, 노드 사본과 전환 작업을 조정하기 위한 인력 비용이 많이 발생할 수 있다. - PDB를 이용해서 애플리케이션의 중단에 견디도록 작성한다. - 다운타임 없음 @@ -251,5 +267,3 @@ Pod Disruption Budgets를 사용할 필요가 없다. * [Pod Disruption Budget 설정하기](/docs/tasks/run-application/configure-pdb/)의 단계를 따라서 애플리케이션을 보호한다. * [노드 비우기](/docs/tasks/administer-cluster/safely-drain-node/)에 대해 자세히 알아보기 - - diff --git a/content/ko/docs/concepts/workloads/pods/ephemeral-containers.md b/content/ko/docs/concepts/workloads/pods/ephemeral-containers.md index 721405614c..20977e4e94 100644 --- a/content/ko/docs/concepts/workloads/pods/ephemeral-containers.md +++ b/content/ko/docs/concepts/workloads/pods/ephemeral-containers.md @@ -8,14 +8,15 @@ weight: 80 {{< feature-state state="alpha" for_k8s_version="v1.16" >}} -이 페이지는 임시 컨테이너에 대한 개요를 제공한다: 이 특별한 유형의 컨테이너는 -트러블 슈팅과 같은 사용자가 시작한 작업을 완료하기위해 기존 {{< glossary_tooltip term_id="pod" >}} 에서 -임시적으로 실행된다. 사용자는 애플리케이션 빌드보다는 서비스를 점검할 때 임시 +이 페이지는 임시 컨테이너에 대한 개요를 제공한다: 이 특별한 유형의 컨테이너는 +트러블 슈팅과 같은 사용자가 시작한 작업을 완료하기위해 기존 {{< glossary_tooltip text="파드" term_id="pod" >}} 에서 +임시적으로 실행된다. 사용자는 애플리케이션 빌드보다는 서비스를 점검할 때 임시 컨테이너를 사용한다. {{< warning >}} -임시 컨테이너는 초기 알파 상태이며, 프로덕션 클러스터에는 -적합하지 않다. [쿠버네티스 사용중단(deprecation) 정책](/docs/reference/using-api/deprecation-policy/)에 따라 +임시 컨테이너는 초기 알파 상태이며, +프로덕션 클러스터에는 적합하지 않다. +[쿠버네티스 사용 중단(deprecation) 정책](/docs/reference/using-api/deprecation-policy/)에 따라 이 알파 기능은 향후 크게 변경되거나, 완전히 제거될 수 있다. {{< /warning >}} @@ -25,23 +26,23 @@ weight: 80 ## 임시 컨테이너 이해하기 -{{< glossary_tooltip text="파드" term_id="pod" >}} 는 쿠버네티스 애플리케이션의 -기본 구성 요소이다. 파드는 일회용이고, 교체 가능한 것으로 의도되었기 +{{< glossary_tooltip text="파드" term_id="pod" >}} 는 쿠버네티스 애플리케이션의 +기본 구성 요소이다. 파드는 일회용이고, 교체 가능한 것으로 의도되었기 때문에, 사용자는 파드가 한번 생성되면, 컨테이너를 추가할 수 없다. -대신, 사용자는 보통 {{< glossary_tooltip text="디플로이먼트" term_id="deployment" >}} 를 +대신, 사용자는 보통 {{< glossary_tooltip text="디플로이먼트" term_id="deployment" >}} 를 사용해서 제어하는 방식으로 파드를 삭제하고 교체한다. -그러나 때때로 재현하기 어려운 버그의 문제 해결을 위해 -기존 파드의 상태를 검사해야할 수 있다. 이 경우 사용자는 -기존 파드에서 임시 컨테이너를 실행해서 상태를 검사하고, 임의의 명령을 +그러나 때때로 재현하기 어려운 버그의 문제 해결을 위해 +기존 파드의 상태를 검사해야 할 수 있다. 이 경우 사용자는 +기존 파드에서 임시 컨테이너를 실행해서 상태를 검사하고, 임의의 명령을 실행할 수 있다. ### 임시 컨테이너는 무엇인가? -임시 컨테이너는 리소스 또는 실행에 대한 보증이 없다는 점에서 -다른 컨테이너와 다르며, 결코 자동으로 재시작되지 않는다. 그래서 -애플리케이션을 만드는데 적합하지 않다. 임시 컨테이너는 -일반 컨테이너와 동일한 `ContainerSpec` 을 사용해서 명시하지만, 많은 필드가 +임시 컨테이너는 리소스 또는 실행에 대한 보증이 없다는 점에서 +다른 컨테이너와 다르며, 결코 자동으로 재시작되지 않는다. 그래서 +애플리케이션을 만드는데 적합하지 않다. 임시 컨테이너는 +일반 컨테이너와 동일한 `ContainerSpec` 을 사용해서 명시하지만, 많은 필드가 호환되지 않으며 임시 컨테이너에는 허용되지 않는다. - 임시 컨테이너는 포트를 가지지 않을 수 있으므로, `ports`, @@ -60,20 +61,20 @@ API에서 특별한 `ephemeralcontainers` 핸들러를 사용해서 만들어지 ## 임시 컨테이너의 사용 임시 컨테이너는 컨테이너가 충돌 되거나 또는 컨테이너 이미지에 -디버깅 도구가 포함되지 않은 이유로 `kubectl exec` 이 불충분할 때 +디버깅 도구가 포함되지 않은 이유로 `kubectl exec` 이 불충분할 때 대화형 문제 해결에 유용하다. 특히, [distroless 이미지](https://github.com/GoogleContainerTools/distroless) -를 사용하면 공격 표면(attack surface)과 버그 및 취약점의 노출을 줄이는 최소한의 -컨테이너 이미지를 배포할 수 있다. distroless 이미지는 쉘 또는 어떤 디버깅 도구를 -포함하지 않기 때문에, `kubectl exec` 만으로는 distroless +를 사용하면 공격 표면(attack surface)과 버그 및 취약점의 노출을 줄이는 최소한의 +컨테이너 이미지를 배포할 수 있다. distroless 이미지는 셸 또는 어떤 디버깅 도구를 +포함하지 않기 때문에, `kubectl exec` 만으로는 distroless 이미지의 문제 해결이 어렵다. -임시 컨테이너 사용시 [프로세스 네임스페이스 -공유](/docs/tasks/configure-pod-container/share-process-namespace/)를 +임시 컨테이너 사용 시 [프로세스 네임스페이스 +공유](/docs/tasks/configure-pod-container/share-process-namespace/)를 활성화하면 다른 컨테이너 안의 프로세스를 보는데 도움이 된다. -임시 컨테이너를 사용해서 문제를 해결하는 예시는 +임시 컨테이너를 사용해서 문제를 해결하는 예시는 [임시 디버깅 컨테이너로 디버깅하기] (/docs/tasks/debug-application-cluster/debug-running-pod/#debugging-with-ephemeral-debug-container)를 참조한다. @@ -81,17 +82,17 @@ API에서 특별한 `ephemeralcontainers` 핸들러를 사용해서 만들어지 {{< note >}} 이 섹션의 예시는 `EphemeralContainers` [기능 -게이트](/docs/reference/command-line-tools-reference/feature-gates/)를 +게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)의 활성화를 필요로 하고, 쿠버네티스 클라이언트와 서버는 v1.16 또는 이후의 버전이어야 한다. {{< /note >}} -이 섹션의 에시는 임시 컨테이너가 어떻게 API에 나타나는지 +이 섹션의 예시는 임시 컨테이너가 어떻게 API에 나타나는지 보여준다. 일반적으로 `kubectl alpha debug` 또는 -다른 `kubectl` [플러그인](/docs/tasks/extend-kubectl/kubectl-plugins/)을 +다른 `kubectl` [플러그인](/ko/docs/tasks/extend-kubectl/kubectl-plugins/)을 사용해서 API를 직접 호출하지 않고 이런 단계들을 자동화 한다. -임시 컨테이너는 파드의 `ephemeralcontainers` 하위 리소스를 -사용해서 생성되며, `kubectl --raw` 를 사용해서 보여준다. 먼저 +임시 컨테이너는 파드의 `ephemeralcontainers` 하위 리소스를 +사용해서 생성되며, `kubectl --raw` 를 사용해서 보여준다. 먼저 `EphemeralContainers` 목록으로 추가하는 임시 컨테이너를 명시한다. ```json @@ -187,5 +188,3 @@ Ephemeral Containers: ```shell kubectl attach -it example-pod -c debugger ``` - - diff --git a/content/ko/docs/concepts/workloads/pods/init-containers.md b/content/ko/docs/concepts/workloads/pods/init-containers.md index 0e1f614de3..8d0ca2008a 100644 --- a/content/ko/docs/concepts/workloads/pods/init-containers.md +++ b/content/ko/docs/concepts/workloads/pods/init-containers.md @@ -27,7 +27,7 @@ weight: 40 * 각 초기화 컨테이너는 다음 초기화 컨테이너가 시작되기 전에 성공적으로 완료되어야 한다. 만약 파드를 위한 초기화 컨테이너가 실패한다면, 쿠버네티스는 초기화 컨테이너가 성공할 때까지 파드를 -반복적으로 재시작한다. 그러나, 만약 파드의 `restartPolicy`을 절대 하지 않음(Never)으로 설정했다면, 파드는 재시작되지 않는다. +반복적으로 재시작한다. 그러나, 만약 파드의 `restartPolicy` 를 절대 하지 않음(Never)으로 설정했다면, 파드는 재시작되지 않는다. 컨테이너를 초기화 컨테이너로 지정하기 위해서는, 파드 스펙에 앱 `containers` 배열과 나란히 `initContainers` 필드를 @@ -62,8 +62,8 @@ weight: 40 다른 이미지로부터(`FROM`) 새로운 이미지를 만들 필요가 없다. * 애플리케이션 이미지 빌더와 디플로이어 역할은 독립적으로 동작될 수 있어서 공동의 단일 앱 이미지 형태로 빌드될 필요가 없다. -* 초기화 컨테이너는 앱 컨테이너와 다른 파일 시스템 뷰를 가지도록 Linux 네임스페이스를 사용한다. - 결과적으로, 초기화 컨테이너에는 앱 컨테이너가 가질 수 없는 +* 초기화 컨테이너는 앱 컨테이너와 다른 파일 시스템 뷰를 가지도록 리눅스 네임스페이스를 사용한다. + 결과적으로, 초기화 컨테이너에는 앱 컨테이너가 가질 수 없는 {{< glossary_tooltip text="시크릿" term_id="secret" >}}에 접근 권한이 주어질 수 있다. * 앱 컨테이너들은 병렬로 실행되는 반면, 초기화 컨테이너들은 어떠한 앱 컨테이너라도 시작되기 전에 실행 완료되어야 하므로, 초기화 컨테이너는 사전 조건들이 @@ -102,7 +102,7 @@ weight: 40 ### 사용 중인 초기화 컨테이너 쿠버네티스 1.5에 대한 다음의 yaml 파일은 두 개의 초기화 컨테이너를 포함한 간단한 파드에 대한 개요를 보여준다. -첫 번째는 `myservice`를 기다리고 두 번째는 `mydb`를 기다린다. 두 컨테이너들이 +첫 번째는 `myservice` 를 기다리고 두 번째는 `mydb` 를 기다린다. 두 컨테이너들이 완료되면, 파드가 시작될 것이다. ```yaml @@ -190,7 +190,7 @@ kubectl logs myapp-pod -c init-mydb # Inspect the second init container ``` `mydb` 및 `myservice` 서비스를 시작하고 나면, 초기화 컨테이너가 완료되고 -`myapp-pod`가 생성된 것을 볼 수 있다. +`myapp-pod` 가 생성된 것을 볼 수 있다. 여기에 이 서비스를 보이기 위해 사용할 수 있는 구성이 있다. @@ -217,7 +217,7 @@ spec: targetPort: 9377 ``` -`mydb`와 `myservice` 서비스 생성하기. +`mydb` 와 `myservice` 서비스 생성하기. ```shell kubectl apply -f services.yaml @@ -227,7 +227,7 @@ service/myservice created service/mydb created ``` -초기화 컨테이너들이 완료되는 것과 `myapp-pod` 파드가 Runnning 상태로 +초기화 컨테이너들이 완료되는 것과 `myapp-pod` 파드가 Running 상태로 변경되는 것을 볼 것이다. ```shell @@ -249,13 +249,13 @@ myapp-pod 1/1 Running 0 9m 각 초기화 컨테이너는 다음 컨테이너가 시작되기 전에 성공적으로 종료되어야 한다. 만약 런타임 문제나 실패 상태로 종료되는 문제로인하여 초기화 컨테이너의 시작이 -실패된다면, 초기화 컨테이너는 파드의 `restartPolicy`에 따라서 재시도 된다. 다만, -파드의 `restartPolicy`이 항상(Always)으로 설정된 경우, 해당 초기화 컨테이너는 -`restartPolicy`을 실패 시(OnFailure)로 사용한다. +실패된다면, 초기화 컨테이너는 파드의 `restartPolicy` 에 따라서 재시도 된다. 다만, +파드의 `restartPolicy` 가 항상(Always)으로 설정된 경우, 해당 초기화 컨테이너는 +`restartPolicy` 를 실패 시(OnFailure)로 사용한다. -파드는 모든 초기화 컨테이너가 성공되기 전까지 `Ready`될 수 없다. 초기화 컨테이너의 포트는 +파드는 모든 초기화 컨테이너가 성공되기 전까지 `Ready` 될 수 없다. 초기화 컨테이너의 포트는 서비스 하에 합쳐지지 않는다. 초기화 중인 파드는 `Pending` 상태이지만 -`Initialized`이 참이 되는 조건을 가져야 한다. +`Initialized` 가 참이 되는 조건을 가져야 한다. 만약 파드가 [재시작](#파드-재시작-이유)되었다면, 모든 초기화 컨테이너는 반드시 다시 실행된다. @@ -264,15 +264,16 @@ myapp-pod 1/1 Running 0 9m 초기화 컨테이너 이미지 필드를 변경하는 것은 파드를 재시작하는 것과 같다. 초기화 컨테이너는 재시작되거나, 재시도, 또는 재실행 될 수 있기 때문에, 초기화 컨테이너 -코드는 멱등성(indempotent)을 유지해야 한다. 특히, `EmptyDirs`에 있는 파일에 쓰기를 수행하는 코드는 +코드는 멱등성(idempotent)을 유지해야 한다. 특히, `EmptyDirs` 에 있는 파일에 쓰기를 수행하는 코드는 출력 파일이 이미 존재할 가능성에 대비해야 한다. 초기화 컨테이너는 앱 컨테이너의 필드를 모두 가지고 있다. 그러나, 쿠버네티스는 -`readinessProbe`가 사용되는 것을 금지한다. 초기화 컨테이너가 완료 상태와 준비성을 +`readinessProbe` 가 사용되는 것을 금지한다. 초기화 컨테이너가 완료 상태와 준비성을 구분해서 정의할 수 없기 때문이다. 이것은 유효성 검사 중에 시행된다. -초기화 컨테이너들이 실패를 영원히 지속하는 상황을 방지하기 위해서 -파드의 `activeDeadlineSeconds`와 컨테이너의 `livenessProbe`를 사용한다. +초기화 컨테이너들이 실패를 +영원히 지속하는 상황을 방지하기 위해서 +파드의 `activeDeadlineSeconds` 와 컨테이너의 `livenessProbe` 를 사용한다. 파드 내의 각 앱과 초기화 컨테이너의 이름은 유일해야 한다. 어떤 컨테이너가 다른 컨테이너와 같은 이름을 공유하는 경우 유효성 오류가 발생한다. @@ -310,7 +311,7 @@ myapp-pod 1/1 Running 0 9m 이미지의 변경은 앱 컨테이너만 재시작시킨다. * 파드 인프라스트럭처 컨테이너가 재시작되었다. 이는 일반적인 상황이 아니며 노드에 대해서 root 접근 권한을 가진 누군가에 의해서 수행됐을 것이다. -* 파드 내의 모든 컨테이너들이, 재시작을 강제하는 `restartPolicy`이 항상으로 설정되어 있는, +* 파드 내의 모든 컨테이너들이, 재시작을 강제하는 `restartPolicy` 가 항상(Always)으로 설정되어 있는, 동안 종료되었다. 그리고 초기화 컨테이너의 완료 기록이 가비지 수집 때문에 유실되었다. @@ -320,7 +321,5 @@ myapp-pod 1/1 Running 0 9m ## {{% heading "whatsnext" %}} -* [초기화 컨테이너를 가진 파드 생성하기](/docs/tasks/configure-pod-container/configure-pod-initialization/#create-a-pod-that-has-an-init-container) -* [초기화 컨테이너 디버깅](/docs/tasks/debug-application-cluster/debug-init-containers/) 알아보기 - - +* [초기화 컨테이너를 가진 파드 생성하기](/ko/docs/tasks/configure-pod-container/configure-pod-initialization/#초기화-컨테이너를-갖는-파드-생성) +* [초기화 컨테이너 디버깅](/ko/docs/tasks/debug-application-cluster/debug-init-containers/) 알아보기 diff --git a/content/ko/docs/concepts/workloads/pods/pod-lifecycle.md b/content/ko/docs/concepts/workloads/pods/pod-lifecycle.md index e8e384a4ab..379266e351 100644 --- a/content/ko/docs/concepts/workloads/pods/pod-lifecycle.md +++ b/content/ko/docs/concepts/workloads/pods/pod-lifecycle.md @@ -77,7 +77,7 @@ PodCondition 배열의 각 요소는 다음 여섯 가지 필드를 가질 수 컨테이너에서 [kubelet](/docs/admin/kubelet/)에 의해 주기적으로 수행되는 진단(diagnostic)이다. 진단을 수행하기 위해서, kubelet은 컨테이너에 의해서 구현된 -[핸들러](https://godoc.org/k8s.io/kubernetes/pkg/api/v1#Handler)를 호출한다. +[핸들러](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#handler-v1-core)를 호출한다. 핸들러에는 다음과 같이 세 가지 타입이 있다. * [ExecAction](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#execaction-v1-core) @@ -90,7 +90,7 @@ kubelet은 컨테이너에 의해서 구현된 * [HTTPGetAction](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#httpgetaction-v1-core) 은 지정한 포트 및 경로에서 컨테이너의 IP주소에 - 대한 HTTP Get 요청을 수행한다. 응답의 상태 코드가 200보다 크고 400보다 작으면 + 대한 HTTP Get 요청을 수행한다. 응답의 상태 코드가 200 이상 400 미만이면 진단이 성공한 것으로 간주한다. 각 probe는 다음 세 가지 결과 중 하나를 가진다. @@ -114,9 +114,9 @@ kubelet은 실행 중인 컨테이너들에 대해서 선택적으로 세 가지 지원하지 않는다면, 기본 상태는 `Success`이다. * `startupProbe`: 컨테이너 내의 애플리케이션이 시작되었는지를 나타낸다. - 스타트업 프로브(startup probe)가 주어진 경우, 성공할 때 까지 다른 나머지 프로브는 + 스타트업 프로브(startup probe)가 주어진 경우, 성공할 때 까지 다른 나머지 프로브는 활성화 되지 않는다. 만약 스타트업 프로브가 실패하면, kubelet이 컨테이너를 죽이고, - 컨테이너는 [재시작 정책](#재시작-정책)에 따라 처리된다. 컨테이너에 스타트업 + 컨테이너는 [재시작 정책](#재시작-정책)에 따라 처리된다. 컨테이너에 스타트업 프로브가 없는 경우, 기본 상태는 `Success`이다. ### 언제 활성 프로브를 사용해야 하는가? @@ -193,8 +193,7 @@ kubelet은 실행 중인 컨테이너들에 대해서 선택적으로 세 가지 ... ``` -* `Terminated`: 컨테이너가 실행이 완료되어 구동을 멈추었다는 뜻이다. 컨테이너가 성공적으로 작업을 완료했을 때나 어떤 이유에서 실패했을 때 이 상태가 된다. 원인과 종료 코드(exit code)가 컨테이너의 시작과 종료 시간과 함께 무조건 출력된다. - 컨테이너가 Terminated 상태가 되기 전에, `preStop` 훅이 (존재한다면) 실행된다. +* `Terminated`: 컨테이너가 실행이 완료되어 구동을 멈추었다는 뜻이다. 컨테이너가 성공적으로 작업을 완료했을 때나 어떤 이유에서 실패했을 때 이 상태가 된다. 원인과 종료 코드(exit code)가 컨테이너의 시작과 종료 시간과 함께 무조건 출력된다. 컨테이너가 Terminated 상태가 되기 전에, `preStop` 훅이 (존재한다면) 실행된다. ```yaml ... @@ -212,7 +211,7 @@ kubelet은 실행 중인 컨테이너들에 대해서 선택적으로 세 가지 애플리케이션은 추가 피드백 또는 신호를 PodStatus: _Pod readiness_ 와 같이 주입할 수 있다. 이를 사용하기 위해, 파드의 준비성을 평가하기 -위한 추가적인 조건들을 `PodSpec` 내의 `ReadinessGate` 필드를 통해서 지정할 수 있다. +위한 추가적인 조건들을 `PodSpec` 내의 `ReadinessGate` 필드를 통해서 지정할 수 있다. 준비성 게이트는 파드에 대한 `status.condition` 필드의 현재 상태에 따라 결정된다. 만약 쿠버네티스가 `status.conditions` 필드에서 해당하는 @@ -261,6 +260,9 @@ status: * 파드 내의 모든 컨테이너들이 준비 상태이다. * `ReadinessGates`에 지정된 모든 조건들이 `True` 이다. +파드의 컨테이너가 Ready 이나 적어도 한 개의 사용자 지정 조건이 빠졌거나 `False` 이면, +Kubelet은 파드의 상태를 `ContainerReady`로 설정한다. + ## 재시작 정책 PodSpec은 항상(Always), 실패 시(OnFailure), 절대 안 함(Never) 값으로 설정 가능한 `restartPolicy` 필드를 가지고 있다. @@ -404,4 +406,3 @@ spec: - diff --git a/content/ko/docs/concepts/workloads/pods/pod-overview.md b/content/ko/docs/concepts/workloads/pods/pod-overview.md index 5b2af22d73..bf52e77c2a 100644 --- a/content/ko/docs/concepts/workloads/pods/pod-overview.md +++ b/content/ko/docs/concepts/workloads/pods/pod-overview.md @@ -26,6 +26,7 @@ card: * **단일 컨테이너만 동작하는 파드**. "단일 컨테이너 당 한 개의 파드" 모델은 쿠버네티스 사용 사례 중 가장 흔하다. 이 경우, 한 개의 파드가 단일 컨테이너를 감싸고 있다고 생각할 수 있으며, 쿠버네티스는 컨테이너가 아닌 파드를 직접 관리한다고 볼 수 있다. * **함께 동작하는 작업이 필요한 다중 컨테이너가 동작하는 파드**. 아마 파드는 강하게 결합되어 있고 리소스 공유가 필요한 다중으로 함께 배치된 컨테이너로 구성되어 있을 것이다. 이렇게 함께 배치되어 설치된 컨테이너는 단일 결합 서비스 단위일 것이다. 한 컨테이너는 공유 볼륨에서 퍼블릭으로 파일들을 옮기고, 동시에 분리되어 있는 "사이드카" 컨테이너는 그 파일들을 업데이트 하거나 복구한다. 파드는 이 컨테이너와 저장소 리소스들을 한 개의 관리 가능한 요소로 묶는다. + 각각의 파드는 주어진 애플리케이션에서 단일 인스턴스로 동작하는 것을 말한다. 만약 애플리케이션을 수평적으로 스케일하기를 원하면(더 많은 인스턴스를 실행해서 더 많은 전체 리소스를 제공하는 것), 각 인스턴스 당 한 개씩 다중 파드를 사용해야 한다. 쿠버네티스에서는, 일반적으로 이것을 _복제_ 라고 한다. 복제된 파드는 일반적으로 워크로드 리소스와 해당 {{< glossary_tooltip text="_컨트롤러_" term_id="controller" >}}에 의해 그룹으로 생성과 관리된다. 쿠버네티스가 컨트롤러를 사용해서 워크로드의 확장과 복구를 구현하는 방법에 대한 자세한 내용은 [파드와 컨트롤러](#파드와-컨트롤러)를 참고한다. @@ -48,7 +49,7 @@ card: #### 저장소 -파드는 공유 저장소 집합인 {{< glossary_tooltip text="Volumes" term_id="volume" >}} 을 명시할 수 있다. 파드 내부의 모든 컨테이너는 공유 볼륨에 접근할 수 있고, 그 컨테이너끼리 데이터를 공유하는 것을 허용한다. 또한 볼륨은 컨테이너가 재시작되어야 하는 상황에도 파드 안의 데이터가 영구적으로 유지될 수 있게 한다. 쿠버네티스가 어떻게 파드 안의 공유 저장소를 사용하는지 보려면 [볼륨](/ko/docs/concepts/storage/volumes/)를 참고하길 바란다. +파드는 공유 저장소 집합인 {{< glossary_tooltip text="볼륨" term_id="volume" >}}을 명시할 수 있다. 파드 내부의 모든 컨테이너는 공유 볼륨에 접근할 수 있고, 그 컨테이너끼리 데이터를 공유하는 것을 허용한다. 또한 볼륨은 컨테이너가 재시작되어야 하는 상황에도 파드 안의 데이터가 영구적으로 유지될 수 있게 한다. 쿠버네티스가 어떻게 파드 안의 공유 저장소를 사용하는지 보려면 [볼륨](/ko/docs/concepts/storage/volumes/)을 참고하길 바란다. ## 파드 작업 @@ -64,13 +65,16 @@ card: 워크로드 리소스를 사용해서 여러 파드를 생성하고 관리할 수 있다. 리소스 컨트롤러는 파드 장애 발생 시 복제, 롤아웃, 자동 복구를 처리한다. 예를 들어, 노드에 장애가 발생하면, 컨트롤러는 해당 노드의 파드는 작동을 멈추고 교체용 파드를 생성한다는 것을 알게 된다. 스케줄러는 교체용 파드를 정상적인 노드에 배치하게 된다. +다음은 하나 이상의 파드를 관리하는 워크로드 리소스의 예이다. + * {{< glossary_tooltip text="디플로이먼트" term_id="deployment" >}} * {{< glossary_tooltip text="스테이트풀셋" term_id="statefulset" >}} * {{< glossary_tooltip text="데몬셋" term_id="daemonset" >}} + ## 파드 템플릿 -워크로드 리소스에 대한 컨트롤러는 파드 템플릿으로 파드를 생성하고 +{{< glossary_tooltip text="워크로드" term_id="workload" >}} 리소스에 대한 컨트롤러는 파드 템플릿으로 파드를 생성하고 사용자를 대신해서 이러한 파드를 관리한다. 파드템플릿은 파드를 생성하기 위한 명세이며 @@ -87,6 +91,7 @@ apiVersion: batch/v1 kind: Job metadata: name: hello +spec: template: # 이것이 파드 템플릿이다. spec: @@ -113,4 +118,3 @@ metadata: * 파드의 동작에 대해 더 알아보자. * [파드 종료](/ko/docs/concepts/workloads/pods/pod/#파드의-종료) * [파드 라이프사이클](/ko/docs/concepts/workloads/pods/pod-lifecycle/) - 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 d7cc7d545b..d92b18a1bf 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 @@ -18,10 +18,10 @@ weight: 50 ### 기능 게이트 활성화 -를 참조한다. {{< glossary_tooltip text="API 서버" term_id="kube-apiserver" >}} **와** -{{< glossary_tooltip text="스케줄러" term_id="kube-scheduler" >}}에 -대해 `EvenPodsSpread` -[기능 게이트](/docs/reference/command-line-tools-reference/feature-gates/)가 활성화되어야 한다. +를 참조한다. {{< glossary_tooltip text="API 서버" term_id="kube-apiserver" >}} **와** +{{< glossary_tooltip text="스케줄러" term_id="kube-scheduler" >}}에 대해 +`EvenPodsSpread` [기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)가 +활성화되어야 한다. ### 노드 레이블 @@ -160,6 +160,7 @@ spec: - 신규 파드와 같은 네임스페이스를 갖는 파드만이 매칭의 후보가 된다. - `topologySpreadConstraints[*].topologyKey` 가 없는 노드는 무시된다. 이것은 다음을 의미한다. + 1. 이러한 노드에 위치한 파드는 "maxSkew" 계산에 영향을 미치지 않는다. - 위의 예시에서, "node1"은 "zone" 레이블을 가지고 있지 않다고 가정하면, 파드 2개는 무시될 것이고, 이런 이유로 신규 파드는 "zoneA"로 스케줄된다. 2. 신규 파드는 이런 종류의 노드에 스케줄 될 기회가 없다. - 위의 예시에서, 레이블로 `{zone-typo: zoneC}` 를 가지는 "node5"가 클러스터에 편입한다고 가정하면, 레이블 키에 "zone"이 없기 때문에 무시하게 된다. @@ -191,13 +192,13 @@ spec: 토폴로지 분배 제약 조건은 다음과 같은 경우에만 파드에 적용된다. - `.spec.topologySpreadConstraints` 에는 어떠한 제약도 정의되어 있지 않는 경우. -- 서비스, 레플리케이션 컨트롤러, 레플리카 셋 또는 스테이트풀 셋에 속해있는 경우. +- 서비스, 레플리케이션컨트롤러(ReplicationController), 레플리카셋(ReplicaSet) 또는 스테이트풀셋(StatefulSet)에 속해있는 경우. 기본 제약 조건은 [스케줄링 프로파일](/docs/reference/scheduling/profiles)에서 `PodTopologySpread` 플러그인의 일부로 설정할 수 있다. 제약 조건은 `labelSelector` 가 비어 있어야 한다는 점을 제외하고, [위와 동일한 API](#api)로 제약 조건을 지정한다. 셀렉터는 파드가 속한 서비스, 레플리케이션 컨트롤러, -레플리카 셋 또는 스테이트풀 셋에서 계산한다. +레플리카셋 또는 스테이트풀셋에서 계산한다. 예시 구성은 다음과 같다. @@ -226,17 +227,16 @@ profiles: ## 파드어피니티(PodAffinity)/파드안티어피니티(PodAntiAffinity)와의 비교 쿠버네티스에서 "어피니티(Affinity)"와 관련된 지침은 파드가 -더 많이 채워지거나 더 많이 분산되는 방식으로 스케줄 되는 방법을 제어한다. +더 많이 채워지거나 더 많이 분산되는 방식으로 스케줄 되는 방법을 제어한다. - `PodAffinity` 는, 사용자가 자격이 충족되는 토폴로지 도메인에 원하는 수의 파드를 얼마든지 채울 수 있다. - `PodAntiAffinity` 로는, 단일 토폴로지 도메인에 단 하나의 파드만 스케줄 될 수 있다. -"EvenPodsSpread" 기능은 다양한 토폴로지 도메인에 파드를 균등하게 분배해서 -고 가용성 또는 비용 절감을 달성할 수 있는 유연한 옵션을 제공한다. 또한 워크로드의 롤링 업데이트와 -레플리카의 원활한 스케일링 아웃에 도움이 될 수 있다. -더 자세한 내용은 [모티베이션(Motivation)](https://github.com/kubernetes/enhancements/blob/master/keps/sig-scheduling/20190221-pod-topology-spread.md#motivation)를 참조한다. +"EvenPodsSpread" 기능은 다양한 토폴로지 도메인에 파드를 균등하게 분배해서 +고 가용성 또는 비용 절감을 달성할 수 있는 유연한 옵션을 제공한다. 또한 워크로드의 롤링 업데이트와 레플리카의 원활한 스케일링 아웃에 도움이 될 수 있다. +더 자세한 내용은 [모티베이션(Motivation)](https://github.com/kubernetes/enhancements/tree/master/keps/sig-scheduling/895-pod-topology-spread#motivation)를 참조한다. ## 알려진 제한사항 @@ -244,5 +244,3 @@ profiles: - 디플로이먼트를 스케일링 다운하면 그 결과로 파드의 분포가 불균형이 될 수 있다. - 파드와 일치하는 테인트(taint)가 된 노드가 존중된다. [이슈 80921](https://github.com/kubernetes/kubernetes/issues/80921)을 본다. - - diff --git a/content/ko/docs/concepts/workloads/pods/pod.md b/content/ko/docs/concepts/workloads/pods/pod.md index 9f7d06d091..e3464ff5cf 100644 --- a/content/ko/docs/concepts/workloads/pods/pod.md +++ b/content/ko/docs/concepts/workloads/pods/pod.md @@ -5,15 +5,21 @@ weight: 20 --- <!-- overview --> -_파드_ 는 쿠버네티스에서 생성되고 관리될 수 있는 배포 가능한 최소 컴퓨팅 단위이다. + +_파드_ 는 쿠버네티스에서 생성되고 관리될 수 있는 +배포 가능한 최소 컴퓨팅 단위이다. + <!-- body --> ## 파드는 무엇인가? -_파드_ 는 (고래 떼(pod of whales)나 콩꼬투리(pea pod)와 마찬가지로) 하나 이상의(도커 컨테이너 같은) 컨테이너 그룹이다. -이 그룹은 스토리지/네트워크를 공유하고, 해당 컨테이너를 구동하는 방식에 대한 명세를 갖는다. + +_파드_ 는 (고래 떼(pod of whales)나 콩꼬투리(pea pod)와 마찬가지로) 하나 이상의(도커 컨테이너 같은) +{{< glossary_tooltip text="컨테이너" term_id="container" >}} 그룹이다. +이 그룹은 스토리지/네트워크를 공유하고, +해당 컨테이너를 구동하는 방식에 대한 명세를 갖는다. 파드의 콘텐츠들은 항상 함께 배치되고 같이 스케줄되며, 공유 컨텍스트 내에서 구동된다. 파드는 애플리케이션에 특화된 "논리 호스트"를 모델로 하고 있다. 이것은 하나 또는 강하게 서로 결합되어 있는 여러 애플리케이션 컨테이너를 포함한다. @@ -23,7 +29,7 @@ _파드_ 는 (고래 떼(pod of whales)나 콩꼬투리(pea pod)와 마찬가지 쿠버네티스는 도커 이외에도 많은 컨테이너 런타임을 지원하지만, 도커는 가장 일반적으로 알려진 런타임이므로 도커 용어로 파드를 설명하는 것이 도움이 된다. -파드의 공유 컨텍스트는 Linux 네임 스페이스, 컨트롤 그룹(cgroup) 및 +파드의 공유 컨텍스트는 리눅스 네임스페이스, 컨트롤 그룹(cgroup) 및 도커 컨테이너를 격리하는 것과 같이 잠재적으로 다른 격리 요소들이다. 파드의 컨텍스트 내에서 개별 응용 프로그램은 추가적으로 하위 격리가 적용된다. @@ -47,9 +53,10 @@ _파드_ 는 (고래 떼(pod of whales)나 콩꼬투리(pea pod)와 마찬가지 개별 애플리케이션 컨테이너와 같이, 파드는 상대적으로 수명이 짧은 엔터티로 간주된다. [파드의 생애](/ko/docs/concepts/workloads/pods/pod-lifecycle/)에서 논의된 것과 같이, 파드가 만들어지고 고유한 ID(UID)가 할당되고, -재시작 정책에 따라서 종료 또는 삭제될 때 까지 노드에 스케줄된다. +재시작 정책에 따라서 종료 또는 삭제될 때 까지 노드에 스케줄된다. 노드가 종료되면 해당 노드로 스케줄 된 파드는 제한시간이 지나면 삭제되도록 스케줄된다. -해당 파드(UID로 정의된)는 새로운 노드에 "리스케줄(reschedule)" 되지 않는다. 대신, 동일한 파드로, +해당 파드(UID로 정의된)는 새로운 노드에 "리스케줄(reschedule)" 되지 않는다. +대신, 동일한 파드로, 원한다면 이름도 동일하게, 교체될 수 있지만, 새로운 UID가 부여된다. 더 자세한 내용은 [레플리케이션 컨트롤러](/ko/docs/concepts/workloads/controllers/replicationcontroller/)를 참조한다. @@ -59,6 +66,7 @@ UID를 포함한 해당 파드가 존재하는 한 그것도 존재한다는 것 동일한 대체품이 만들어 지더라도 관련된 것(예 : 볼륨) 또한 삭제되고 새로 만들어진다. {{< figure src="/images/docs/pod.svg" title="파드 다이어그램" width="50%" >}} + *파일 풀러(Puller)와 컨테이너 간 공유 스토리지로 퍼시스턴트 볼륨을 사용하는 웹 서버를 포함하는 멀티 컨테이너 파드.* @@ -70,7 +78,8 @@ UID를 포함한 해당 파드가 존재하는 한 그것도 존재한다는 것 파드는 그 구성 요소 집합보다 높은 수준의 추상화를 제공함으로써 애플리케이션 배포 및 관리를 단순화한다. 파드는 전개 단위, 수평 확장 및 복제를 한다. -공동 스케줄링, 공유 된 생애주기 (예 : 종료), 조정 된 복제, 자원 공유 및 종속성 관리는 +공동 스케줄링, +공유된 생애주기(예: 종료), 조정된 복제, 자원 공유 및 종속성 관리는 파드의 컨테이너에 대해 자동으로 처리된다. ### 리소스 공유 및 통신 @@ -80,10 +89,12 @@ UID를 포함한 해당 파드가 존재하는 한 그것도 존재한다는 것 파드의 모든 애플리케이션은 동일한 네트워크 네임스페이스(동일한 IP 및 포트 공간)를 사용하므로 서로를 찾고 통신하는데 `localhost`를 사용할 수 있다. 이 때문에 파드의 애플리케이션은 포트 사용을 조정 해야한다. -각 파드에는 다른 물리적 컴퓨터 및 파드들과 네트워크를 통해 통신할 수 있는 공유 네트워크 공간의 IP 주소가 있다. +각 파드에는 다른 물리적 컴퓨터 및 파드들과 +네트워크를 통해 통신할 수 있는 공유 네트워크 공간의 IP 주소가 있다. 호스트 이름은 파드 안에있는 애플리케이션 컨테이너의 파드 이름으로 설정된다. -더 자세한 내용은 [네트워킹의 더 자세한 내용](/docs/concepts/cluster-administration/networking/)을 참조한다. +더 자세한 내용은 +[네트워킹](/ko/docs/concepts/cluster-administration/networking/) 섹션을 참조한다. 파드는 파드 안의 애플리케이션 컨테이너를 정의하는 것 이외에도 공유 저장 볼륨의 집합을 지정한다. 볼륨은 컨테이너가 재시작되어도 데이터가 생존할 수 있도록 하고, @@ -104,14 +115,17 @@ UID를 포함한 해당 파드가 존재하는 한 그것도 존재한다는 것 일반적으로 하나의 파드는 동일한 애플리케이션의 여러 인스턴스를 실행하도록 사용하지 않는다. -더 자세한 설명을 보려면 [분산 시스템 툴킷: 복합 컨테이너를 위한 패턴] (https://kubernetes.io/blog/2015/06/the-distributed-system-toolkit-patterns)을 참조한다. +더 자세한 설명을 보려면 +[분산 시스템 툴킷: 복합 컨테이너를 위한 패턴](https://kubernetes.io/blog/2015/06/the-distributed-system-toolkit-patterns)을 +참조한다. ## 고려된 대안 _싱글 (도커)컨테이너에서 다중 프로그램을 실행하지 않는 이유는 무엇인가?_ 1. 투명도. 인프라에 파드 내의 컨테이너를 표시하면, - 인프라에서 프로세스 관리와 리소스 모니터링과 같은 기능을 제공할 수 있다. + 인프라에서 프로세스 관리와 리소스 모니터링과 같은 기능을 + 제공할 수 있다. 이 기능들은 사용자에게 편의를 제공한다. 1. 소프트웨어 의존성 분리. 각각의 컨테이너는 독립적으로 버전 관리, 재빌드, 재배포될 수 있다. @@ -129,19 +143,18 @@ _컨테이너의 어피니티(affinity) 기반 공동 스케줄링을 지원하 ## 파드의 내구성 (또는 결핍) -파드는 내구성이 강한 엔터티로 취급하지는 않는다. 파드는 스케줄링 실패, -노드 장애 또는 그 밖에 리소스가 부족해서, 또는 노드 정비를 위한 경우와 같이 축출(eviction)되는 상황에서는 살아남을 수 없을 것이다. +파드는 내구성이 강한 엔터티로 취급하지는 않는다. 파드는 스케줄링 실패, 노드 장애 또는 그 밖에 리소스가 부족해서, 또는 노드 정비를 위한 경우와 같이 축출(eviction)되는 상황에서는 살아남을 수 없을 것이다. 일반적으로 사용자는 파드를 직접 만들 필요가 없다. -싱글톤이라도 대부분 [디플로이먼트](/ko/docs/concepts/workloads/controllers/deployment/)와 같은 컨트롤러를 사용한다. +싱글톤이라도 대부분 [디플로이먼트(Deployment)](/ko/docs/concepts/workloads/controllers/deployment/)와 같은 컨트롤러를 사용한다. 컨트롤러는 클러스터 범위에서 복제와 롤아웃 관리 뿐 만 아니라 자가치료 기능도 제공한다. -[StatefulSet](/ko/docs/concepts/workloads/controllers/statefulset.md)과 같은 컨트롤러는 상태를 저장하는 파드에도 +[스테이트풀셋](/ko/docs/concepts/workloads/controllers/statefulset/)과 같은 +컨트롤러는 상태를 저장하는 파드에도 위와 같은 기능 제공을 할 수 있다. 사용자 지향적으로 선정된 API를 사용하는 것은 [Borg](https://research.google.com/pubs/pub43438.html), [Marathon](https://mesosphere.github.io/marathon/docs/rest-api.html), [Aurora](http://aurora.apache.org/documentation/latest/reference/configuration/#job-schema)와 [Tupperware](https://www.slideshare.net/Docker/aravindnarayanan-facebook140613153626phpapp02-37588997)를 비롯한 클러스터 스케줄링 시스템에서 비교적 일반적이다. - 파드는 아래와 같은 사항들을 용이하게 하기 위해 노출이 된다: * 스케줄러 및 컨트롤러 연결 가능 @@ -149,58 +162,45 @@ _컨테이너의 어피니티(affinity) 기반 공동 스케줄링을 지원하 * 부트스트랩과 같이 컨트롤러의 생애와 파드의 생애 분리 * 컨트롤러와 서비스의 분리 — 파드를 감시하는 엔드 포인트 컨트롤러 * 클러스터 레벨과 kubelet 레벨 기능의 깔끔한 구성 — Kubelet은 효과적인 "파드 컨트롤러" 이다. -* 계획된 삭제 또는 이미지 프리페칭과 같이 파드가 종료되기 전에 교체가 될 것이고, -삭제 전에는 확실히 교체되는 고가용성 애플리케이션. +* 계획된 삭제 또는 이미지 프리페칭과 같이 파드가 종료되기 전에 교체가 될 것이고, 삭제 전에는 확실히 교체되는 고가용성 애플리케이션. ## 파드의 종료 -파드는 클러스터의 노드에서 실행 중인 프로세스를 나타내므로 이러한 프로세스가 더 이상 필요하지 않을 때 (KILL 시그널로 강제로 죽여서 정리할 기회를 주지 않는 것과 대조적으로) 정상적으로 종료 되도록 허용하는 것이 중요하다. -사용자는 삭제를 요청할 수 있어야 하며, 프로세스가 종료 될 때 알 수 있어야 할 뿐 만 아니라, 삭제가 결국 완료되는 것을 확인 할 수 있어야 한다. -사용자가 파드를 삭제하도록 요청하면 시스템은 파드가 강제로 종료되기 전에 예정된 유예 기간을 기록하고 TERM 시그널이 각 컨테이너의 주 프로세스로 전송된다. -유예 기간이 만료되면 KILL 신호가 해당 프로세스로 전송되고 파드가 API 서버에서 삭제된다. 프로세스가 종료되기를 기다리는 동안 Kubelet 또는 컨테이너 관리자가 다시 시작되면 종료가 전체 유예 기간과 함께 재시도된다. +파드는 클러스터의 노드에서 실행 중인 프로세스를 나타내므로, 이러한 프로세스가 더 이상 필요하지 않을 때(KILL 시그널로 강제로 죽여서 정리할 기회를 주지 않는 것과 대조적으로) 정상적으로 종료 되도록 허용하는 것이 중요하다. 사용자는 삭제를 요청할 수 있어야 하며, 프로세스가 종료 될 때 알 수 있어야 할 뿐만 아니라, 삭제가 결국 완료되는 것을 확인할 수 있어야 한다. 사용자가 파드를 삭제하도록 요청하면, 시스템은 파드가 강제로 종료되기 전에 예정된 유예 기간을 기록하고, TERM 시그널이 각 컨테이너의 주 프로세스로 전송된다. 유예 기간이 만료되면, KILL 신호가 해당 프로세스로 전송되고, 파드가 API 서버에서 삭제된다. 프로세스가 종료되기를 기다리는 동안 Kubelet 또는 컨테이너 관리자가 다시 시작되면, 종료가 전체 유예 기간과 함께 재시도된다. 흐름 예시: 1. 사용자가 파드 삭제 명령을 내린다. (기본 유예 기간 30초) -1. API 서버 안의 파드는 유예 기간에 따라, 시간을 넘은 것(죽은)것으로 간주되는 파드가 업데이트 된다. +1. API 서버 안의 파드는 유예 기간에 따라, 시간을 넘은(죽은) 것으로 간주되는 파드가 업데이트된다. 1. 클라이언트 명령에서 파드는 "Terminating" 이라는 문구를 나타낸다. 1. (3번 단계와 동시에) Kubelet은 파드가 2번 단계에서 설정된 시간으로 인해 Terminating으로 표시되는 것을 확인하면 파드 종료 단계를 시작한다. 1. 파드의 컨테이너 중 하나에 [preStop hook](/ko/docs/concepts/containers/container-lifecycle-hooks/#hook-details)이 정의된 경우, 해당 컨테이너 내부에서 실행된다. 유예 기간이 만료된 후에도 `preStop` 훅이 계속 실행 중이면, 유예 기간을 짧게(2초)를 1회 연장해서 2번 단계를 실행한다. 1. 파드의 프로세스에 TERM 시그널이 전달된다. 파드의 모든 컨테이너가 TERM 시그널을 동시에 받기 때문에 컨테이너의 종료 순서가 중요한 경우에는 `preStop` 훅이 각각 필요할 수 있음을 알아두자. 만약 `preStop` 훅을 완료하는 데 더 오랜 시간이 필요한 경우 `terminationGracePeriodSeconds` 를 수정해야 한다. -1. (3번 단계와 동시에) 파드는 서비스를 위해 엔드포인트 목록에서 제거되며, 더 이상 레플리케이션 컨트롤러가 실행중인 파드로 고려하지 않는다. -느리게 종료되는 파드는 로드밸런서(서비스 프록시와 같은)의 로테이션에서 지워지기 때문에 트래픽을 계속 처리할 수 없다. +1. (3번 단계와 동시에) 파드는 서비스를 위해 엔드포인트 목록에서 제거되며, 더 이상 레플리케이션 컨트롤러가 실행 중인 파드로 고려하지 않는다. 느리게 종료되는 파드는 로드밸런서(서비스 프록시와 같은)의 로테이션에서 지워지기 때문에 트래픽을 계속 처리할 수 없다. 1. 유예 기간이 만료되면, 파드에서 실행중이던 모든 프로세스가 SIGKILL로 종료된다. 1. Kubelet은 유예기간 0(즉시 삭제)을 세팅하여 API 서버에서 파드 삭제를 끝낼 것이다. API 서버에서 사라진 파드는 클라이언트에게서 더 이상 보이지 않는다. -기본적으로 모든 삭제는 30초 이내에 끝이난다. `kubectl delete` 명령은 사용자가 기본 설정을 오버라이드 하고 자신이 원하는 값을 설정할 수 있게 해주는 `--grace-period=<seconds>` 옵션을 지원한다. `0`값은 파드를 [강제로 삭제한다](/ko/docs/concepts/workloads/pods/pod/#파드-강제-삭제). kubectl 버전 >= 1.5 에서는, 강제 삭제 수행을 위해서 반드시 `--grace-period=0`와 함께 추가 플래그인 `--force`를 지정해야 한다. +기본적으로 모든 삭제는 30초 이내에 끝이 난다. `kubectl delete` 명령은 사용자가 기본 설정을 오버라이드하고 자신이 원하는 값을 설정할 수 있게 해주는 `--grace-period=<seconds>` 옵션을 지원한다. `0` 값은 파드를 [강제로 삭제한다](/ko/docs/concepts/workloads/pods/pod/#파드-강제-삭제). +kubectl 1.5 버전 이상에서는, 강제 삭제 수행을 위해서 반드시 `--grace-period=0` 와 함께 추가 플래그인 `--force` 를 지정해야 한다. ### 파드 강제 삭제 -파드 강제 삭제는 클러스터 및 etcd에서 즉시 삭제하는 것으로 정의된다. 강제 삭제가 수행되면, API 서버는 kubelet에서 실행중이던 노드에서 파드가 종료되었다는 확인을 기다리지 않는다. -API에서 파드를 즉시 제거하므로 동일한 이름으로 새 파드를 만들 수 있다. -노드에서 즉시 종결되도록 설정된 파드에는 강제 삭제되기 전에 짧은 유예 기간이 주어진다. - -강제 삭제는 일부 파드의 경우 잠재적으로 위험 할 수 있으므로 주의해서 수행해야 한다. -스테이트풀셋 파드의 경우 [스테이트풀셋 파드 삭제](/docs/tasks/run-application/force-delete-stateful-set-pod/)에 대한 작업문서를 참조한다. +파드 강제 삭제는 클러스터 및 etcd에서 즉시 삭제하는 것으로 정의된다. 강제 삭제가 수행되면, API 서버는 kubelet에서 실행 중이던 노드에서 파드가 종료되었다는 확인을 기다리지 않는다. API에서 파드를 즉시 제거하므로 동일한 이름으로 새 파드를 만들 수 있다. 노드에서 즉시 종결되도록 설정된 파드에는 강제 삭제되기 전에 짧은 유예 기간이 주어진다. +강제 삭제는 일부 파드의 경우 잠재적으로 위험할 수 있으므로 주의해서 수행해야 한다. 스테이트풀셋 파드의 경우 [스테이트풀셋 파드 삭제](/docs/tasks/run-application/force-delete-stateful-set-pod/)에 대한 작업 문서를 참조한다. ## 파드 컨테이너의 특권(Privileged) 모드 -Kubernetes v1.1부터, 파드의 모든 컨테이너는 컨테이너 스펙의 `SecurityContext`의 `privileged` 플래그를 사용하여 특권 모드를 사용할 수 있다. 이것은 네트워크 스택을 조작하고 장치에 액세스하는 것과 같은 Linux 기능을 사용하려는 컨테이너에 유용하다. 컨테이너 내의 프로세스는 컨테이너 외부의 프로세스에서 사용할 수 있는 거의 동일한 권한을 갖는다. 특권 모드를 사용하면 네트워크 및 볼륨 플러그인을 kubelet에 컴파일 할 필요가 없는 별도의 파드로 쉽게 만들 수 있다. +파드의 모든 컨테이너는 컨테이너 스펙의 [시큐리티 콘텍스트(security context)](/docs/tasks/configure-pod-container/security-context/)의 `privileged` 플래그를 사용하여 특권 모드를 사용할 수 있다. 이것은 네트워크 스택을 조작하고 장치에 액세스하는 것과 같은 리눅스 기능을 사용하려는 컨테이너에 유용하다. 컨테이너 내의 프로세스는 컨테이너 외부의 프로세스에서 사용할 수 있는 거의 동일한 권한을 갖는다. 특권 모드를 사용하면 네트워크 및 볼륨 플러그인을 kubelet에 컴파일할 필요가 없는 별도의 파드로 쉽게 만들 수 있다. -마스터가 Kubernetes v1.1 이상에서 실행 중이고, 노드가 v1.1 보다 낮은 버전을 실행중인 경우 새 권한이 부여 된 파드는 api-server에 의해 승인되지만 시작되지는 않는다. 이것들은 pending 상태가 될 것이다. -사용자가 `kubectl describe pod FooPodName` 을 호출하면 사용자는 파드가 pending 상태에 있는 이유를 볼 수 있다. describe 명령 출력의 이벤트 테이블은 다음과 같다. -`Error validating pod "FooPodName"."FooPodNamespace" from api, ignoring: spec.containers[0].securityContext.privileged: forbidden '<*>(0xc2089d3248)true'` - -마스터가 v1.1보다 낮은 버전에서 실행중인 경우 특권을 갖는 파드를 만들 수 없다. 유저가 특권을 갖는 컨테이너가 있는 파드를 만들려고 하면 다음과 같은 오류가 발생한다. -`The Pod "FooPodName" is invalid. -spec.containers[0].securityContext.privileged: forbidden '<*>(0xc20b222db0)true'` +{{< note >}} +이와 같은 설정을 위해서는 컨테이너 런타임에서 반드시 특권 컨테이너 개념을 지원해야 한다. +{{< /note >}} ## API 오브젝트 -파드는 쿠버네티스 REST API에서 최상위 리소스이다. API 오브젝트에 더 자세한 정보는 아래 내용을 참조한다: +파드는 쿠버네티스 REST API에서 최상위 리소스이다. +API 오브젝트에 더 자세한 정보는 아래 내용을 참조한다: [파드 API 오브젝트](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#pod-v1-core). 파드 오브젝트에 대한 매니페스트를 생성할때는 지정된 이름이 유효한 -[DNS 서브도메인 이름](/ko/docs/concepts/overview/working-with-objects/names/#dns-서브도메인-이름들)인지 확인해야 한다. - - +[DNS 서브도메인 이름](/ko/docs/concepts/overview/working-with-objects/names/#dns-서브도메인-이름)인지 확인해야 한다. diff --git a/content/ko/docs/concepts/workloads/pods/podpreset.md b/content/ko/docs/concepts/workloads/pods/podpreset.md index 4b37e0c232..9793dbc52e 100644 --- a/content/ko/docs/concepts/workloads/pods/podpreset.md +++ b/content/ko/docs/concepts/workloads/pods/podpreset.md @@ -1,4 +1,6 @@ --- + + title: 파드 프리셋 content_type: concept weight: 50 @@ -25,6 +27,7 @@ weight: 50 제공하지는 않아도 되도록 한다. 이렇게 하면, 어떤 특정 서비스를 사용할 파드의 파드 템플릿 작성자는 해당 서비스에 대한 모든 세부 사항을 알 필요가 없다. + ## 클러스터에서 파드프리셋 활성화하기 {#enable-pod-preset} 클러스터에서 파드 프리셋을 사용하기 위해서는 다음 사항이 반드시 이행되어야 한다. diff --git a/content/ko/docs/contribute/_index.md b/content/ko/docs/contribute/_index.md index 9dd0b23cd3..714ae70f36 100644 --- a/content/ko/docs/contribute/_index.md +++ b/content/ko/docs/contribute/_index.md @@ -3,6 +3,7 @@ content_type: concept title: 쿠버네티스 문서에 기여하기 linktitle: 기여 main_menu: true +no_list: true weight: 80 card: name: contribute @@ -12,7 +13,7 @@ card: <!-- overview --> -이 웹사이트는 [쿠버네티스 SIG Docs](/docs/contribute/#get-involved-with-sig-docs)에 의해서 관리됩니다. +이 웹사이트는 [쿠버네티스 SIG Docs](/ko/docs/contribute/#sig-docs에-참여)에 의해서 관리됩니다. 쿠버네티스 문서 기여자들은 @@ -23,56 +24,73 @@ card: 쿠버네티스 문서는 새롭고 경험이 풍부한 모든 기여자의 개선을 환영합니다! - - <!-- body --> ## 시작하기 -누구든지 문서에 대한 이슈를 오픈 또는 풀 리퀘스트(PR)를 사용해서 [`kubernetes/website` GitHub 리포지터리](https://github.com/kubernetes/website)에 변경하는 기여를 할 수 있습니다. 당신이 쿠버네티스 커뮤니티에 효과적으로 기여하려면 [git](https://git-scm.com/)과 [GitHub](https://lab.github.com/)에 익숙해야 합니다. +누구든지 문서에 대한 이슈를 오픈 또는 풀 리퀘스트(PR)를 사용해서 +[`kubernetes/website` GitHub 리포지터리](https://github.com/kubernetes/website)에 +변경하는 기여를 할 수 있습니다. +쿠버네티스 커뮤니티에 효과적으로 기여하려면 +[git](https://git-scm.com/)과 +[GitHub](https://lab.github.com/)에 +익숙해야 합니다. 문서에 참여하려면 1. CNCF [Contributor License Agreement](https://github.com/kubernetes/community/blob/master/CLA.md)에 서명합니다. -2. [문서 리포지터리](https://github.com/kubernetes/website) 와 웹사이트의 [정적 사이트 생성기](https://gohugo.io)를 숙지합니다. -3. [풀 리퀘스트 열기](/docs/contribute/new-content/new-content/)와 [변경 검토](/docs/contribute/review/reviewing-prs/)의 기본 프로세스를 이해하도록 합니다. +1. [문서 리포지터리](https://github.com/kubernetes/website)와 웹사이트의 + [정적 사이트 생성기](https://gohugo.io)를 숙지합니다. +1. [풀 리퀘스트 열기](/ko/docs/contribute/new-content/new-content/)와 + [변경 검토](/ko/docs/contribute/review/reviewing-prs/)의 + 기본 프로세스를 이해하도록 합니다. 일부 작업에는 쿠버네티스 조직에서 더 많은 신뢰와 더 많은 접근이 필요할 수 있습니다. 역할과 권한에 대한 자세한 내용은 -[SIG Docs 참여](/ko/docs/contribute/participating/)를 봅니다. +[SIG Docs 참여](/ko/docs/contribute/participate/)를 봅니다. ## 첫 번째 기여 -- [기여 개요](/docs/contribute/new-content/overview/)를 읽고 기여할 수 있는 다양한 방법에 대해 알아봅니다. -- [kubernetes/website에 기여하기](https://github.com/kubernetes/website/contribute)를 참조하여 좋은 진입점이 되는 이슈를 찾을 수 있습니다. -- 기존 문서에 대해 [GitHub을 사용해서 풀 리퀘스트 열거나](/docs/contribute/new-content/new-content/#changes-using-github) GitHub에서의 이슈 제기에 대해 자세히 알아봅니다. -- 정확성과 언어에 대해 다른 쿠버네티스 커뮤니티 맴버의 [풀 리퀘스트 검토](/docs/contribute/review/reviewing-prs/)를 합니다. -- 쿠버네티스 [컨텐츠](/docs/contribute/style/content-guide/)와 [스타일 가이드](/docs/contribute/style/style-guide/)를 읽고 정보에 대한 코멘트를 남길 수 있습니다. -- [페이지 템플릿 사용](/docs/contribute/style/page-templates/)과 [휴고(Hugo) 단축코드(shortcodes)](/docs/contribute/style/hugo-shortcodes/)를 사용해서 큰 변경을 하는 방법에 대해 배워봅니다. +- [기여 개요](/ko/docs/contribute/new-content/overview/)를 읽고 + 기여할 수 있는 다양한 방법에 대해 알아봅니다. +- [kubernetes/website에 기여하기](https://github.com/kubernetes/website/contribute)를 + 참조하여 좋은 진입점이 되는 이슈를 찾을 수 있습니다. +- 기존 문서에 대해 [GitHub을 사용해서 풀 리퀘스트 열거나](/ko/docs/contribute/new-content/new-content/#github을-사용하여-변경하기) + GitHub에서의 이슈 제기에 대해 자세히 알아봅니다. +- 정확성과 언어에 대해 다른 쿠버네티스 커뮤니티 맴버의 + [풀 리퀘스트 검토](/ko/docs/contribute/review/reviewing-prs/)를 합니다. +- 쿠버네티스 [콘텐츠](/docs/contribute/style/content-guide/)와 + [스타일 가이드](/docs/contribute/style/style-guide/)를 읽고 정보에 대한 코멘트를 남길 수 있습니다. +- [페이지 콘텐츠 유형](/docs/contribute/style/page-content-types/)과 + [휴고(Hugo) 단축코드(shortcodes)](/docs/contribute/style/hugo-shortcodes/)에 대해 배워봅니다. ## 다음 단계 -- 리포지터리의 [로컬 복제본에서 작업](/docs/contribute/new-content/new-content/#fork-the-repo)하는 방법을 배워봅니다. +- 리포지터리의 [로컬 복제본에서 작업](/ko/docs/contribute/new-content/new-content/#fork-the-repo)하는 + 방법을 배워봅니다. - [릴리스된 기능](/docs/contribute/new-content/new-features/)을 문서화 합니다. -- [SIG Docs](/ko/docs/contribute/participating/)에 참여하고, [멤버 또는 검토자](/ko/docs/contribute/participating/#역할과-책임)가 되어봅니다. +- [SIG Docs](/ko/docs/contribute/participate/)에 참여하고, + [멤버 또는 검토자](/ko/docs/contribute/participate/roles-and-responsibilities/)가 되어봅니다. + - [현지화](/ko/docs/contribute/localization_ko/)를 시작하거나 도와줍니다. ## SIG Docs에 참여 -[SIG Docs](/ko/docs/contribute/participating/)는 쿠버네티스 문서와 웹 사이트를 게시하고 관리하는 기여자 그룹입니다. SIG Docs에 참여하는 것은 쿠버네티스 기여자(기능 개발 및 다른 여러가지)가 쿠버네티스 프로젝트에 가장 큰 영향을 미칠 수 있는 좋은 방법입니다. +[SIG Docs](/ko/docs/contribute/participate/)는 쿠버네티스 문서와 웹 사이트를 게시하고 +관리하는 기여자 그룹입니다. SIG Docs에 참여하는 것은 +쿠버네티스 기여자(기능 개발 및 다른 여러가지)가 쿠버네티스 프로젝트에 가장 큰 영향을 +미칠 수 있는 좋은 방법입니다. SIG Docs는 여러가지 방법으로 의견을 나누고 있습니다. -- [쿠버네티스 슬랙 인스턴스에서 `#sig-docs` 에 가입](http://slack.k8s.io/)을 하고, +- [쿠버네티스 슬랙 인스턴스에서 `#sig-docs` 에 가입](https://slack.k8s.io/)하고, 자신을 소개하세요! - 더 광범위한 토론이 이루어지고 공식적인 결정이 기록이 되는 [`kubernetes-sig-docs` 메일링 리스트에 가입](https://groups.google.com/forum/#!forum/kubernetes-sig-docs) 하세요. -- [주간 SIG Docs 화상 회의](https://github.com/kubernetes/community/tree/master/sig-docs)에 참여하세요. 회의는 항상 `#sig-docs` 에 발표되며 [쿠버네티스 커뮤니티 회의 일정](https://calendar.google.com/calendar/embed?src=cgnt364vd8s86hr2phapfjc6uk%40group.calendar.google.com&ctz=America/Los_Angeles)에 추가됩니다. [줌(Zoon) 클라이언트](https://zoom.us/download)를 다운로드 하거나 전화를 이용하여 전화 접속해야 합니다. +- [주간 SIG Docs 화상 회의](https://github.com/kubernetes/community/tree/master/sig-docs)에 참여하세요. 회의는 항상 `#sig-docs` 에 발표되며 [쿠버네티스 커뮤니티 회의 일정](https://calendar.google.com/calendar/embed?src=cgnt364vd8s86hr2phapfjc6uk%40group.calendar.google.com&ctz=America/Los_Angeles)에 추가됩니다. [줌(Zoom) 클라이언트](https://zoom.us/download)를 다운로드하거나 전화를 이용하여 전화 접속해야 합니다. ## 다른 기여 방법들 - [쿠버네티스 커뮤니티 사이트](/community/)를 방문하십시오. 트위터 또는 스택 오버플로우에 참여하고, 현지 쿠버네티스 모임과 이벤트 등에 대해 알아봅니다. - [기여자 치트시트](https://github.com/kubernetes/community/tree/master/contributors/guide/contributor-cheatsheet)를 읽고 쿠버네티스 기능 개발에 참여합니다. - [블로그 게시물 또는 사례 연구](/docs/contribute/new-content/blogs-case-studies/)를 제출합니다. - - diff --git a/content/ko/docs/contribute/advanced.md b/content/ko/docs/contribute/advanced.md index 3f30f6eff9..21337a785e 100644 --- a/content/ko/docs/contribute/advanced.md +++ b/content/ko/docs/contribute/advanced.md @@ -17,69 +17,10 @@ weight: 98 <!-- body --> -## 일주일 동안 PR 랭글러(Wrangler) 되기 - -SIG Docs [승인자](/ko/docs/contribute/participating/#승인자)는 리포지터리에 대해 1주일 정도씩 [PR을 조정(wrangling)](https://github.com/kubernetes/website/wiki/PR-Wranglers)하는 역할을 맡는다. - -PR 랭글러의 임무는 다음과 같다. - -- [스타일](/docs/contribute/style/style-guide/)과 [콘텐츠](/docs/contribute/style/content-guide/) 가이드를 준수하는지에 대해 [열린(open) 풀 리퀘스트](https://github.com/kubernetes/website/pulls)를 매일 리뷰한다. - - 가장 작은 PR(`size/XS`)을 먼저 리뷰한 다음, 가장 큰(`size/XXL`) PR까지 옮겨가며 리뷰를 반복한다. - - 가능한 한 많은 PR을 리뷰한다. -- 각 기여자가 CLA에 서명했는지 확인한다. - - 새로운 기여자가 [CLA](https://github.com/kubernetes/community/blob/master/CLA.md)에 서명하도록 도와준다. - - CLA에 서명하지 않은 기여자에게 CLA에 서명하도록 자동으로 알리려면 [이](https://github.com/zparnold/k8s-docs-pr-botherer) 스크립트를 사용한다. -- 제안된 변경 사항에 대한 피드백을 제공하고 다른 SIG의 멤버로부터의 기술 리뷰가 잘 진행되게 조율한다. - - 제안된 콘텐츠 변경에 대해 PR에 인라인 제안(inline suggestion)을 제공한다. - - 내용을 확인해야 하는 경우, PR에 코멘트를 달고 자세한 내용을 요청한다. - - 관련 `sig/` 레이블을 할당한다. - - 필요한 경우, 파일의 머리말(front matter)에 있는 `reviewers:` 블록의 리뷰어를 할당한다. - - PR의 리뷰 상태를 표시하기 위해 `Docs Review` 와 `Tech Review` 레이블을 할당한다. - - 아직 리뷰되지 않은 PR에 `Needs Doc Review` 나 `Needs Tech Review` 를 할당한다. - - 리뷰가 진행되었고, 병합하기 전에 추가 입력이나 조치가 필요한 PR에 `Doc Review: Open Issues` 나 `Tech Review: Open Issues` 를 할당한다. - - 병합할 수 있는 PR에 `/lgtm` 과 `/approve` 를 할당한다. -- PR이 준비가 되면 병합하거나, 수락해서는 안되는 PR을 닫는다. -- 새로운 이슈를 매일 심사하고 태그를 지정한다. SIG Docs가 메타데이터를 사용하는 방법에 대한 지침은 [이슈 심사 및 분류](/ko/docs/contribute/review/for-approvers/#이슈-심사와-분류)를 참고한다. - -## 랭글러에게 유용한 GitHub 쿼리 - -다음의 쿼리는 랭글러에게 도움이 된다. 이 쿼리들을 수행하여 작업한 후에는, 리뷰할 나머지 PR 목록은 -일반적으로 작다. 이 쿼리들은 특히 현지화 PR을 제외하고, `master` 브랜치만 포함한다(마지막 쿼리는 제외). - -- [CLA 서명 없음, 병합할 수 없음](https://github.com/kubernetes/website/pulls?q=is%3Aopen+is%3Apr+label%3A%22cncf-cla%3A+no%22+-label%3Ado-not-merge+label%3Alanguage%2Fen): - CLA에 서명하도록 기여자에게 상기시킨다. 봇과 사람이 이미 알렸다면, PR을 닫고 - CLA에 서명한 후 PR을 열 수 있음을 알린다. - **작성자가 CLA에 서명하지 않은 PR은 리뷰하지 않는다!** -- [LGTM 필요](https://github.com/kubernetes/website/pulls?utf8=%E2%9C%93&q=is%3Aopen+is%3Apr+-label%3Ado-not-merge+label%3Alanguage%2Fen+-label%3Algtm+): - 기술 리뷰가 필요한 경우, 봇이 제안한 리뷰어 중 한 명을 지정한다. 문서 리뷰나 - 교정이 필요한 경우, 변경 사항을 제안하거나 교정하는 커밋을 PR에 추가하여 진행한다. -- [LGTM 보유, 문서 승인 필요](https://github.com/kubernetes/website/pulls?q=is%3Aopen+is%3Apr+-label%3Ado-not-merge+label%3Alanguage%2Fen+label%3Algtm): - PR을 병합하기 위해 추가 변경이나 업데이트가 필요한지 여부를 결정한다. PR을 병합할 준비가 되었다고 생각되면, `/approve` 코멘트를 남긴다. -- [퀵윈(Quick Wins)](https://github.com/kubernetes/website/pulls?utf8=%E2%9C%93&q=is%3Apr+is%3Aopen+base%3Amaster+-label%3A%22do-not-merge%2Fwork-in-progress%22+-label%3A%22do-not-merge%2Fhold%22+label%3A%22cncf-cla%3A+yes%22+label%3A%22size%2FXS%22+label%3A%22language%2Fen%22+): 명확한 결격 사유가 없는 master에 대한 작은 PR인 경우. ([XS, S, M, L, XL, XXL] 크기의 PR을 작업할 때 크기 레이블에서 "XS"를 변경한다) -- [master 이외의 브랜치에 대한 PR](https://github.com/kubernetes/website/pulls?utf8=%E2%9C%93&q=is%3Aopen+is%3Apr+-label%3Ado-not-merge+label%3Alanguage%2Fen+-base%3Amaster): `dev-` 브랜치에 대한 것일 경우, 곧 출시될 예정인 릴리스이다. `/assign @<meister's_github-username>` 을 코멘트로 추가하여 [릴리스 마이스터](https://github.com/kubernetes/sig-release/tree/master/release-team)가 그것에 대해 알고 있는지 확인한다. 오래된 브랜치에 대한 PR인 경우, PR 작성자가 가장 적합한 브랜치를 대상으로 하고 있는지 여부를 파악할 수 있도록 도와준다. - -### 풀 리퀘스트를 종료하는 시기 - -리뷰와 승인은 PR 대기열을 최신 상태로 유지하는 도구 중 하나이다. 또 다른 도구는 종료(closure)이다. - -- CLA가 2주 동안 서명되지 않은 모든 PR을 닫는다. -PR 작성자는 CLA에 서명한 후 PR을 다시 열 수 있으므로, 이는 어떤 것도 CLA 서명없이 병합되지 않게 하는 위험이 적은 방법이다. - -- 작성자가 2주 이상 동안 코멘트나 피드백에 응답하지 않은 모든 PR을 닫는다. - -풀 리퀘스트를 닫는 것을 두려워하지 말자. 기여자는 진행 중인 작업을 쉽게 다시 열고 다시 시작할 수 있다. 종종 종료 통지는 작성자가 기여를 재개하고 끝내도록 자극하는 것이다. - -풀 리퀘스트를 닫으려면, PR에 `/close` 코멘트를 남긴다. - -{{< note >}} - -[`fejta-bot`](https://github.com/fejta-bot)이라는 자동화 서비스는 90일 동안 활동이 없으면 자동으로 이슈를 오래된 것으로 표시한 다음, 그 상태에서 추가로 30일 동안 활동이 없으면 종료한다. PR 랭글러는 14-30일 동안 활동이 없으면 이슈를 닫아야 한다. - -{{< /note >}} - ## 개선 제안 -SIG Docs [멤버](/ko/docs/contribute/participating/#멤버)는 개선을 제안할 수 있다. +SIG Docs [멤버](/ko/docs/contribute/participate/roles-and-responsibilities/#멤버)는 +개선을 제안할 수 있다. 한 동안 쿠버네티스 문서에 기여한 후에, [스타일 가이드](/docs/contribute/style/style-guide/), @@ -102,12 +43,12 @@ website 스타일, 풀 리퀘스트 리뷰와 병합 ## 쿠버네티스 릴리스를 위한 문서 조정 -SIG Docs [승인자](/ko/docs/contribute/participating/#승인자)는 쿠버네티스 -릴리스에 대한 문서를 조정할 수 있다. +SIG Docs [승인자](/ko/docs/contribute/participate/roles-and-responsibilities/#승인자)는 +쿠버네티스 릴리스에 대한 문서를 조정할 수 있다. 각 쿠버네티스 릴리스는 sig-release SIG(Special Interest Group)에 참여하는 사람들의 팀에 의해 조정된다. 특정 릴리스에 대한 릴리스 팀의 다른 구성원에는 -전체 릴리스 리드와 sig-pm, sig-testing 및 기타 담당자가 +전체 릴리스 리드와 sig-testing 및 기타 담당자가 포함된다. 쿠버네티스 릴리스 프로세스에 대한 자세한 내용은 [https://github.com/kubernetes/sig-release](https://github.com/kubernetes/sig-release)를 참고한다. @@ -133,8 +74,8 @@ SIG Docs [승인자](/ko/docs/contribute/participating/#승인자)는 쿠버네 ## 새로운 기여자 홍보대사로 봉사 -SIG Docs [승인자](/ko/docs/contribute/participating/#승인자)는 새로운 기여자 -홍보대사로 활동할 수 있다. +SIG Docs [승인자](/ko/docs/contribute/participate/roles-and-responsibilities/#승인자)는 +새로운 기여자 홍보대사로 활동할 수 있다. 새로운 기여자 홍보대사는 SIG-Docs에 기여한 새 기여자를 환영하고, 새 기여자에게 PR을 제안하고, 첫 몇 번의 PR 제출을 통해 @@ -152,12 +93,12 @@ SIG Docs [승인자](/ko/docs/contribute/participating/#승인자)는 새로운 ## 새로운 기여자 후원 -SIG Docs [리뷰어](/ko/docs/contribute/participating/#리뷰어)는 새로운 기여자를 -후원할 수 있다. +SIG Docs [리뷰어](/ko/docs/contribute/participate/roles-and-responsibilities/#리뷰어)는 +새로운 기여자를 후원할 수 있다. 새로운 기여자가 하나 이상의 쿠버네티스 리포지터리에 5개의 실질적인 풀 리퀘스트를 성공적으로 제출한 후에는 -쿠버네티스 조직의 [멤버십](/ko/docs/contribute/participating#멤버)을 +쿠버네티스 조직의 [멤버십](/ko/docs/contribute/participate/roles-and-responsibilities/#멤버)을 신청할 수 있다. 기여자의 멤버십은 이미 리뷰어인 두 명의 스폰서가 후원해야 한다. @@ -171,7 +112,8 @@ SIG Docs [리뷰어](/ko/docs/contribute/participating/#리뷰어)는 새로운 ## SIG 공동 의장으로 봉사 -SIG Docs [승인자](/ko/docs/contribute/participating/#승인자)는 SIG Docs의 공동 의장 역할을 할 수 있다. +SIG Docs [승인자](/ko/docs/contribute/participate/roles-and-responsibilities/#승인자)는 +SIG Docs의 공동 의장 역할을 할 수 있다. ### 전제 조건 @@ -180,7 +122,12 @@ SIG Docs [승인자](/ko/docs/contribute/participating/#승인자)는 SIG Docs - 6개월 이상 SIG Docs 승인자로 활동한다. - [쿠버네티스 문서 릴리스 주도](/ko/docs/contribute/advanced/#쿠버네티스-릴리스를-위한-문서-조정) 또는 두 개의 릴리스에서 섀도잉을 수행한다. - SIG Docs 워크플로와 툴링을 이해한다(git, Hugo, 현지화, 블로그 하위 프로젝트). -- [k/org의 팀](https://github.com/kubernetes/org/blob/master/config/kubernetes/sig-docs/teams.yaml), [k/community의 프로세스](https://github.com/kubernetes/community/tree/master/sig-docs), [k/test-infra](https://github.com/kubernetes/test-infra/)의 플러그인 및 [SIG 아키텍처](https://github.com/kubernetes/community/tree/master/sig-architecture)의 역할을 포함하여 다른 쿠버네티스 SIG와 리포지터리가 SIG Docs 워크플로에 미치는 영향을 이해한다. +- [k/org의 팀](https://github.com/kubernetes/org/blob/master/config/kubernetes/sig-docs/teams.yaml), + [k/community의 프로세스](https://github.com/kubernetes/community/tree/master/sig-docs), + [k/test-infra](https://github.com/kubernetes/test-infra/)의 플러그인 및 + [SIG 아키텍처](https://github.com/kubernetes/community/tree/master/sig-architecture)의 + 역할을 포함하여 다른 쿠버네티스 SIG와 리포지터리가 SIG Docs 워크플로에 미치는 + 영향을 이해한다. - 최소 6개월 동안 일주일에 5시간 이상(대부분 더)을 역할에 책임진다. ### 책임 @@ -244,5 +191,3 @@ SIG Docs [승인자](/ko/docs/contribute/participating/#승인자)는 SIG Docs 녹화를 중지하려면, Stop을 클릭한다. 비디오가 자동으로 유튜브에 업로드된다. - - diff --git a/content/ko/docs/contribute/localization_ko.md b/content/ko/docs/contribute/localization_ko.md index 76b22e5529..59cde62dea 100644 --- a/content/ko/docs/contribute/localization_ko.md +++ b/content/ko/docs/contribute/localization_ko.md @@ -187,7 +187,7 @@ API 오브젝트의 필드 이름, 파일 이름, 경로와 같은 내용은 독 ### 기능 게이트(feature gate) 한글화 방침 -쿠버네티스의 [기능 게이트](/docs/reference/command-line-tools-reference/feature-gates/)를 +쿠버네티스의 [기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)를 의미하는 용어는 한글화하지 않고 원문 형태를 유지한다. 기능 게이트의 예시는 다음과 같다. @@ -198,7 +198,7 @@ API 오브젝트의 필드 이름, 파일 이름, 경로와 같은 내용은 독 - ... 전체 기능 게이트 목록은 -[여기](/docs/reference/command-line-tools-reference/feature-gates/#feature-gates)를 참고한다. +[여기](/ko/docs/reference/command-line-tools-reference/feature-gates/#feature-gates)를 참고한다. {{% note %}} 단, 해당 원칙에는 예외가 있을 수 있으며, 이 경우에는 가능한 @@ -295,8 +295,6 @@ Daemon | 데몬 | DaemonSet | 데몬셋(DaemonSet) | API 오브젝트인 경우 Dashboard | 대시보드 | Data Plane | 데이터 플레인 | -Default Limit | 기본 상한 | -Default Request | 기본 요청량 | Deployment | 디플로이먼트(Deployment) | API 오브젝트인 경우 deprecated | 사용 중단(deprecated) | descriptor | 디스크립터, 식별자 | @@ -356,6 +354,7 @@ label | 레이블 | Lease | 리스(Lease) | API 오브젝트인 경우 lifecycle | 라이프사이클 | LimitRange | 리밋레인지(LimitRange) | API 오브젝트인 경우 +limit | 한도(limit) | 리소스의 개수나 용량을 한정하기 위한 수치로 사용된 경우 선택적으로 사용 (API 오브젝트의 속성으로 limit을 사용한 경우는 가능한 영문 유지) Linux | 리눅스 | load | 부하 | LocalSubjectAccessReview | 로컬서브젝트액세스리뷰(LocalSubjectAccessReview) | API 오브젝트인 경우 @@ -365,7 +364,6 @@ Lost | Lost | 클레임의 상태에 한함 Machine | 머신 | manifest | 매니페스트 | Master | 마스터 | -max limit/request ratio | 최대 상한/요청량 비율 | metadata | 메타데이터 | metric | 메트릭 | masquerading | 마스커레이딩 | @@ -418,8 +416,8 @@ ReplicaSet | 레플리카셋(ReplicaSet) | API 오브젝트인 경우 replicas | 레플리카 | ReplicationController | 레플리케이션컨트롤러(ReplicationController) | API 오브젝트인 경우 repository | 리포지터리 | +request | 요청(request) | 리소스의 개수나 용량에 대한 요청 수치를 표현하기 위해 사용된 경우 선택적으로 사용 (API 오브젝트 속성으로 request를 사용한 경우는 가능한 영문을 유지) resource | 리소스 | -Resource Limit | 리소스 상한 | ResourceQuota | 리소스쿼터(ResourceQuota) | API 오브젝트인 경우 return | 반환하다 | revision | 리비전 | diff --git a/content/ko/docs/contribute/new-content/open-a-pr.md b/content/ko/docs/contribute/new-content/open-a-pr.md index 6f01e04135..516c22bfea 100644 --- a/content/ko/docs/contribute/new-content/open-a-pr.md +++ b/content/ko/docs/contribute/new-content/open-a-pr.md @@ -1,6 +1,5 @@ --- title: 풀 리퀘스트 열기 -slug: new-content content_type: concept weight: 10 card: @@ -97,10 +96,12 @@ git에 익숙하거나, 변경 사항이 몇 줄보다 클 경우, ### 로컬 클론 생성 및 업스트림 설정 -3. 터미널 창에서, 포크를 클론한다. +3. 터미널 창에서, 포크를 클론하고 [Docsy Hugo 테마](https://github.com/google/docsy#readme)를 업데이트한다. ```bash git clone git@github.com/<github_username>/website + cd website + git submodule update --init --recursive --depth 1 ``` 4. 새 `website` 디렉터리로 이동한다. `kubernetes/website` 리포지터리를 `upstream` 원격으로 설정한다. @@ -217,21 +218,39 @@ git에 익숙하거나, 변경 사항이 몇 줄보다 클 경우, 변경 사항을 푸시하거나 풀 리퀘스트를 열기 전에 변경 사항을 로컬에서 미리 보는 것이 좋다. 미리보기를 사용하면 빌드 오류나 마크다운 형식 문제를 알아낼 수 있다. -website의 도커 이미지를 만들거나 Hugo를 로컬에서 실행할 수 있다. 도커 이미지 빌드는 느리지만 [Hugo 단축코드](/docs/contribute/style/hugo-shortcodes/)를 표시하므로, 디버깅에 유용할 수 있다. +website의 컨테이너 이미지를 만들거나 Hugo를 로컬에서 실행할 수 있다. 도커 이미지 빌드는 느리지만 [Hugo 단축코드](/docs/contribute/style/hugo-shortcodes/)를 표시하므로, 디버깅에 유용할 수 있다. {{< tabs name="tab_with_hugo" >}} {{% tab name="Hugo 컨테이너" %}} +{{< note >}} +아래 명령은 도커를 기본 컨테이너 엔진으로 사용한다. 이 동작을 무시하려면 `CONTAINER_ENGINE` 환경변수를 설정한다. +{{< /note >}} + 1. 로컬에서 이미지를 빌드한다. ```bash make docker-image + # docker 사용(기본값) + make container-image + + ### 또는 ### + + # podman 사용 + CONTAINER_ENGINE=podman make container-image ``` 2. 로컬에서 `kubernetes-hugo` 이미지를 빌드한 후, 사이트를 빌드하고 서비스한다. ```bash make docker-serve + # docker 사용(기본값) + make container-serve + + ### 또는 ### + + # podman 사용 + CONTAINER_ENGINE=podman make container-serve ``` 3. 웹 브라우저에서 `https://localhost:1313` 로 이동한다. Hugo는 @@ -245,18 +264,26 @@ website의 도커 이미지를 만들거나 Hugo를 로컬에서 실행할 수 또는, 컴퓨터에 `hugo` 명령을 설치하여 사용한다. -5. [`website/netlify.toml`](https://raw.githubusercontent.com/kubernetes/website/master/netlify.toml)에 지정된 [Hugo](https://gohugo.io/getting-started/installing/) 버전을 설치한다. +1. [`website/netlify.toml`](https://raw.githubusercontent.com/kubernetes/website/master/netlify.toml)에 지정된 [Hugo](https://gohugo.io/getting-started/installing/) 버전을 설치한다. -6. 터미널에서, 쿠버네티스 website 리포지터리로 이동하여 Hugo 서버를 시작한다. +2. website 리포지터리를 업데이트하지 않았다면, `website/themes/docsy` 디렉터리가 비어 있다. +테마의 로컬 복제본이 없으면 사이트를 빌드할 수 없다. website 테마를 업데이트하려면, 다음을 실행한다. + + ```bash + git submodule update --init --recursive --depth 1 + ``` + +3. 터미널에서, 쿠버네티스 website 리포지터리로 이동하여 Hugo 서버를 시작한다. ```bash cd <path_to_your_repo>/website - hugo server + hugo server --buildFuture ``` -7. 브라우저의 주소 표시줄에 `https://localhost:1313` 을 입력한다. +4. 웹 브라우저에서 `https://localhost:1313` 으로 이동한다. Hugo는 + 변경 사항을 보고 필요에 따라 사이트를 다시 구축한다. -8. 로컬의 Hugo 인스턴스를 중지하려면, 터미널로 돌아가서 `Ctrl+C` 를 입력하거나, +5. 로컬의 Hugo 인스턴스를 중지하려면, 터미널로 돌아가서 `Ctrl+C` 를 입력하거나,     터미널 창을 닫는다. {{% /tab %}} @@ -286,7 +313,7 @@ PR을 연 후, GitHub는 자동 테스트를 실행하고 [Netlify](https://www. - Netlify 빌드가 실패하면, 자세한 정보를 위해 **Details** 를 선택한다. - Netlify 빌드가 성공하면, **Details** 를 선택하면 변경 사항이 적용된 쿠버네티스 website의 커밋하기 직전의 버전(staged version)이 열린다. 리뷰어가 변경 사항을 확인하는 방법이다. -또한 GitHub는 리뷰어에게 도움을 주기 위해 PR에 레이블을 자동으로 할당한다. 필요한 경우 직접 추가할 수도 있다. 자세한 내용은 [이슈 레이블 추가와 제거](/docs/contribute/review/for-approvers/#adding-and-removing-issue-labels)를 참고한다. +또한 GitHub는 리뷰어에게 도움을 주기 위해 PR에 레이블을 자동으로 할당한다. 필요한 경우 직접 추가할 수도 있다. 자세한 내용은 [이슈 레이블 추가와 제거](/ko/docs/contribute/review/for-approvers/#이슈-레이블-추가와-제거)를 참고한다. ### 로컬에서 피드백 해결 @@ -408,7 +435,7 @@ PR에 여러 커밋이 있는 경우, PR을 병합하기 전에 해당 커밋을 git rebase -i HEAD~<number_of_commits_in_branch> ``` - 커밋을 스쿼시하는 것은 일종의 리베이스이다. git의 `-i` 스위치는 리베이스를 대화형으로 할 수 있게 한다. `HEAD~<number_of_commits_in_branch` 는 리베이스를 위해 살펴볼 커밋 수를 나타낸다. + 커밋을 스쿼시하는 것은 일종의 리베이스이다. git의 `-i` 스위치는 리베이스를 대화형으로 할 수 있게 한다. `HEAD~<number_of_commits_in_branch>` 는 리베이스를 위해 살펴볼 커밋 수를 나타낸다. 출력은 다음과 비슷하다. @@ -480,6 +507,4 @@ PR에 여러 커밋이 있는 경우, PR을 병합하기 전에 해당 커밋을 ## {{% heading "whatsnext" %}} -- 리뷰 프로세스에 대한 자세한 내용은 [리뷰하기](/ko/docs/contribute/reviewing/revewing-prs)를 읽어본다. - - +- 리뷰 프로세스에 대한 자세한 내용은 [리뷰하기](/ko/docs/contribute/review/reviewing-prs)를 읽어본다. diff --git a/content/ko/docs/contribute/new-content/overview.md b/content/ko/docs/contribute/new-content/overview.md index c17a557c6d..00dc7e0251 100644 --- a/content/ko/docs/contribute/new-content/overview.md +++ b/content/ko/docs/contribute/new-content/overview.md @@ -19,9 +19,13 @@ weight: 5 - 마크다운(Markdown)으로 쿠버네티스 문서를 작성하고 [Hugo](https://gohugo.io/)를 사용하여 쿠버네티스 사이트를 구축한다. - 소스는 [GitHub](https://github.com/kubernetes/website)에 있다. 쿠버네티스 문서는 `/content/ko/docs/` 에서 찾을 수 있다. 일부 참조 문서는 `update-imported-docs/` 디렉터리의 스크립트에서 자동으로 생성된다. -- [페이지 템플릿](/docs/contribute/style/page-templates/)은 Hugo에서 문서 콘텐츠의 프리젠테이션을 제어한다. -- 표준 Hugo 단축코드(shortcode) 이외에도 설명서에서 여러 [사용자 정의 Hugo 단축코드](/docs/contribute/style/hugo-shortcodes/)를 사용하여 콘텐츠 표시를 제어한다. -- 문서 소스는 `/content/` 에서 여러 언어로 제공된다. 각 언어는 [ISO 639-1 표준](https://www.loc.gov/standards/iso639-2/php/code_list.php)에 의해 결정된 2문자 코드가 있는 자체 폴더가 있다. 예를 들어, 한글 문서의 소스는 `/content/ko/docs/` 에 저장된다. +- [페이지 템플릿](/docs/contribute/style/page-content-types/)은 Hugo에서 문서 콘텐츠의 프리젠테이션을 제어한다. +- 표준 Hugo 단축코드(shortcode) 이외에도 설명서에서 여러 + [사용자 정의 Hugo 단축코드](/docs/contribute/style/hugo-shortcodes/)를 사용하여 콘텐츠 표시를 제어한다. +- 문서 소스는 `/content/` 에서 여러 언어로 제공된다. 각 + 언어는 [ISO 639-1 표준](https://www.loc.gov/standards/iso639-2/php/code_list.php)에 + 의해 결정된 2문자 코드가 있는 자체 폴더가 있다. 예를 들어, + 한글 문서의 소스는 `/content/ko/docs/` 에 저장된다. - 여러 언어로 문서화에 기여하거나 새로운 번역을 시작하는 방법에 대한 자세한 내용은 [현지화](/ko/docs/contribute/localization_ko/)를 참고한다. ## 시작하기 전에 {#before-you-begin} diff --git a/content/ko/docs/contribute/participate/_index.md b/content/ko/docs/contribute/participate/_index.md new file mode 100644 index 0000000000..f66c7f952b --- /dev/null +++ b/content/ko/docs/contribute/participate/_index.md @@ -0,0 +1,121 @@ +--- +title: SIG Docs에 참여하기 +content_type: concept +weight: 60 +card: + name: contribute + weight: 60 +--- + +<!-- overview --> + +SIG Docs는 쿠버네티스 프로젝트의 +[분과회(special interest group)](https://github.com/kubernetes/community/blob/master/sig-list.md) +중 하나로, 쿠버네티스 전반에 대한 문서를 작성하고, 업데이트하며 유지보수하는 일을 주로 수행한다. +분과회에 대한 보다 자세한 정보는 +[커뮤니티 GitHub 저장소 내 SIG Docs](https://github.com/kubernetes/community/tree/master/sig-docs) +를 참조한다. + +SIG Docs는 모든 컨트리뷰터의 콘텐츠와 리뷰를 환영한다. +누구나 풀 리퀘스트(PR)를 요청할 수 있고, +누구나 콘텐츠에 대해 이슈를 등록하거나 진행 중인 풀 리퀘스트에 코멘트를 등록할 수 있다. + +[멤버](/ko/docs/contribute/participate/roles-and-responsibilities/#멤버), +[리뷰어](/ko/docs/contribute/participate/roles-and-responsibilities/#리뷰어), 또는 +[승인자](/ko/docs/contribute/participate/roles-and-responsibilities/#승인자)가 될 수 있다. +이런 역할은 변경을 승인하고 커밋할 수 있도록 보다 많은 접근 권한과 이에 상응하는 책임이 수반된다. +쿠버네티스 커뮤니티 내에서 멤버십이 운영되는 방식에 대한 보다 많은 정보를 확인하려면 +[커뮤니티 멤버십](https://github.com/kubernetes/community/blob/master/community-membership.md) +문서를 확인한다. + +문서의 나머지에서는 대외적으로 쿠버네티스를 가장 잘 드러내는 수단 중 하나인 쿠버네티스 웹사이트와 +문서를 관리하는 책임을 가지는 SIG Docs에서, +이런 체계가 작동하는 특유의 방식에 대한 윤곽을 잡아보겠다. + +<!-- body --> + +## SIG Docs 의장 + +SIG Docs를 포함한 각 SIG는, 한 명 이상의 SIG 멤버가 의장 역할을 하도록 선정한다. 이들은 SIG Docs와 +다른 쿠버네티스 조직 간 연락책(point of contact)이 된다. 이들은 쿠버네티스 프로젝트 전반의 조직과 +그 안에서 SIG Docs가 어떻게 운영되는지에 대한 폭넓은 지식을 갖추어야한다. +현재 의장의 목록을 확인하려면 +[리더십](https://github.com/kubernetes/community/tree/master/sig-docs#leadership) +문서를 참조한다. + +## SIG Docs 팀과 자동화 + +SIG Docs의 자동화는 다음의 두 가지 메커니즘에 의존한다. +GitHub 팀과 OWNERS 파일이다. + +### GitHub 팀 + +GitHub의 SIG Docs [팀]에는 두 분류가 있다. + +- 승인자와 리더를 위한 `@sig-docs-{language}-owners` +- 리뷰어를 위한 `@sig-docs-{language}-reviewers` + +그룹의 전원과 의사소통하기 위해서 +각각 GitHub 코멘트에서 그룹의 `@name`으로 참조할 수 있다. + +가끔은 Prow와 GitHub 팀은 정확히 일치하지 않고 중복된다. +이슈, 풀 리퀘스트를 할당하고, PR 승인을 지원하기 위해서 +자동화 시스템이 `OWNERS` 파일의 정보를 활용한다. + +### OWNERS 파일과 전문(front-matter) + +쿠버네티스 프로젝트는 GitHub 이슈와 풀 리퀘스트 자동화와 관련해서 prow라고 부르는 자동화 툴을 사용한다. +[쿠버네티스 웹사이트 리포지터리](https://github.com/kubernetes/website)는 +다음의 두개의 [prow 플러그인](https://github.com/kubernetes/test-infra/tree/master/prow/plugins)을 +사용한다. + +- blunderbuss +- approve + +이 두 플러그인은 `kubernetes/website` GitHub 리포지터리 최상위 수준에 있는 +[OWNERS](https://github.com/kubernetes/website/blob/master/OWNERS)와 +[OWNERS_ALIASES](https://github.com/kubernetes/website/blob/master/OWNERS_ALIASES) +파일을 사용해서 +해당 리포지터리에 대해 prow가 작동하는 방식을 제어한다. + +OWNERS 파일은 SIG Docs 리뷰어와 승인자의 목록을 포함한다. OWNERS 파일은 하위 디렉터리에 있을 수 +있고, 해당 하위 디렉터리와 그 이하의 파일에 대해 리뷰어와 승인자 역할을 수행할 사람을 새로 지정할 수 있다. +일반적인 OWNERS 파일에 대한 보다 많은 정보는 +[OWNERS](https://github.com/kubernetes/community/blob/master/contributors/guide/owners.md) +문서를 참고한다. + +추가로, 개별 마크다운(Markdown) 파일 내 전문에 +리뷰어와 승인자를 개별 GitHub 사용자 이름이나 GitHub 그룹으로 열거할 수 있다. + +OWNERS 파일과 마크다운 파일 내 전문의 조합은 +자동화 시스템이 누구에게 기술적, 편집적 리뷰를 요청해야 할지를 +PR 소유자에게 조언하는데 활용된다. + +## 병합 작업 방식 + +풀 리퀘스트 요청이 콘텐츠를 발행하는데 사용하는 +브랜치에 병합되면, 해당 콘텐츠는 http://kubernetes.io 에 공개된다. 게시된 콘텐츠의 +품질을 높히기 위해 SIG Docs 승인자가 풀 리퀘스트를 병합하는 것을 제한한다. +작동 방식은 다음과 같다. + +- 풀 리퀘스트에 `lgtm` 과 `approve` 레이블이 있고, `hold` 레이블이 없고, + 모든 테스트를 통과하면 풀 리퀘스트는 자동으로 병합된다. +- 쿠버네티스 조직의 멤버와 SIG Docs 승인자들은 지정된 풀 리퀘스트의 + 자동 병합을 방지하기 위해 코멘트를 추가할 수 있다(코멘트에 `/hold` 추가 또는 + `/lgtm` 코멘트 보류). +- 모든 쿠버네티스 멤버는 코멘트에 `/lgtm` 을 추가해서 `lgtm` 레이블을 추가할 수 있다. +- SIG Docs 승인자들만이 코멘트에 `/approve` 를 + 추가해서 풀 리퀘스트를 병합할 수 있다. 일부 승인자들은 + [PR Wrangler](/ko/docs/contribute/advanced/#일주일-동안-pr-랭글러-wrangler-되기) 또는 [SIG Docs 의장](#sig-docs-의장)과 + 같은 특정 역할도 수행한다. + + + +## {{% heading "whatsnext" %}} + + +쿠버네티스 문서화에 기여하는 일에 대한 보다 많은 정보는 다음 문서를 참고한다. + +- [신규 콘텐츠 기여하기](/ko/docs/contribute/new-content/overview/) +- [콘텐츠 검토하기](/ko/docs/contribute/review/reviewing-prs/) +- [문서 스타일 가이드](/ko/docs/contribute/style/) diff --git a/content/ko/docs/contribute/participate/pr-wranglers.md b/content/ko/docs/contribute/participate/pr-wranglers.md new file mode 100644 index 0000000000..4581400ea3 --- /dev/null +++ b/content/ko/docs/contribute/participate/pr-wranglers.md @@ -0,0 +1,70 @@ +--- +title: PR 랭글러(PR Wrangler) +content_type: concept +weight: 20 +--- + +<!-- overview --> + +SIG Docs [승인자](/ko/docs/contribute/participating/roles-and-responsibilites/#승인자)는 리포지터리에 대해 일주일 동안 교대로 [풀 리퀘스트 관리](https://github.com/kubernetes/website/wiki/PR-Wranglers)를 수행한다. + +이 섹션은 PR 랭글러의 의무에 대해 다룬다. 좋은 리뷰 제공에 대한 자세한 내용은 [Reviewing changes](/ko/docs/contribute/review/)를 참고한다. + +<!-- body --> + +## 의무 + +PR 랭글러는 일주일 간 매일 다음의 일을 해야 한다. + +- 매일 새로 올라오는 이슈를 심사하고 태그를 지정한다. SIG Docs가 메타데이터를 사용하는 방법에 대한 지침은 [이슈 심사 및 분류](/docs/contribute/review/for-approvers/#triage-and-categorize-issues)를 참고한다. +- [스타일](/docs/contribute/style/style-guide/)과 [콘텐츠](/docs/contribute/style/content-guide/) 가이드를 준수하는지에 대해 [열린(open) 풀 리퀘스트](https://github.com/kubernetes/website/pulls)를 매일 리뷰한다. + - 가장 작은 PR(`size/XS`)부터 시작하고, 가장 큰(`size/XXL`) PR까지 리뷰한다. 가능한 한 많은 PR을 리뷰한다. +- PR 기여자들이 [CLA]()에 서명했는지 확인한다. + - CLA에 서명하지 않은 기여자에게 CLA에 서명하도록 알리려면 [이](https://github.com/zparnold/k8s-docs-pr-botherer) 스크립트를 사용한다. +- 제안된 변경 사항에 대한 피드백을 제공하고 다른 SIG의 멤버에게 기술 리뷰를 요청한다. + - 제안된 콘텐츠 변경에 대해 PR에 인라인 제안(inline suggestion)을 제공한다. + - 내용을 확인해야 하는 경우, PR에 코멘트를 달고 자세한 내용을 요청한다. + - 관련 `sig/` 레이블을 할당한다. + - 필요한 경우, 파일의 머리말(front matter)에 있는 `reviewers:` 블록의 리뷰어를 할당한다. +- PR을 병합하려면 승인을 위한 `approve` 코멘트를 사용한다. 준비가 되면 PR을 병합한다. + - 병합하기 전에 PR은 다른 멤버의 `/lgtm` 코멘트를 받아야 한다. + - [스타일 지침]을 충족하지 않지만 기술적으로는 정확한 PR은 수락하는 것을 고려한다. 스타일 문제를 해결하는 `good first issue` 레이블의 새로운 이슈를 올리면 된다. + +### 랭글러를 위해 도움이 되는 GitHub 쿼리 + +다음의 쿼리는 랭글러에게 도움이 된다. +이 쿼리들을 수행하여 작업한 후에는, 리뷰할 나머지 PR 목록은 일반적으로 작다. +이 쿼리들은 특히 현지화 PR을 제외한다. 모든 쿼리는 마지막 쿼리를 제외하고 메인 브렌치를 대상으로 한다. + +- [CLA 서명 없음, 병합할 수 없음](https://github.com/kubernetes/website/pulls?q=is%3Aopen+is%3Apr+label%3A%22cncf-cla%3A+no%22+-label%3Ado-not-merge+label%3Alanguage%2Fen): + CLA에 서명하도록 기여자에게 상기시킨다. 봇과 사람이 이미 알렸다면, PR을 닫고 + CLA에 서명한 후 PR을 열 수 있음을 알린다. + **작성자가 CLA에 서명하지 않은 PR은 리뷰하지 않는다!** +- [LGTM 필요](https://github.com/kubernetes/website/pulls?utf8=%E2%9C%93&q=is%3Aopen+is%3Apr+-label%3Ado-not-merge+label%3Alanguage%2Fen+-label%3Algtm+): + 멤버의 LGTM이 필요한 PR을 나열한다. PR에 기술 리뷰가 필요한 경우, 봇이 제안한 리뷰어 중 한 명을 + 지정한다. 콘텐츠에 대한 작업이 필요하다면, 제안하거나 인라인 피드백을 추가한다. +- [LGTM 보유, 문서 승인 필요](https://github.com/kubernetes/website/pulls?q=is%3Aopen+is%3Apr+-label%3Ado-not-merge+label%3Alanguage%2Fen+label%3Algtm): + 병합을 위해 `/approve` 코멘트가 필요한 PR을 나열한다. +- [퀵윈(Quick Wins)](https://github.com/kubernetes/website/pulls?utf8=%E2%9C%93&q=is%3Apr+is%3Aopen+base%3Amaster+-label%3A%22do-not-merge%2Fwork-in-progress%22+-label%3A%22do-not-merge%2Fhold%22+label%3A%22cncf-cla%3A+yes%22+label%3A%22size%2FXS%22+label%3A%22language%2Fen%22+): 명확한 결격 사유가 없는 메인 브랜치에 대한 PR을 나열한다. ([XS, S, M, L, XL, XXL] 크기의 PR을 작업할 때 크기 레이블에서 "XS"를 변경한다) +- [메인 브랜치이외의 브랜치에 대한 PR](https://github.com/kubernetes/website/pulls?utf8=%E2%9C%93&q=is%3Aopen+is%3Apr+-label%3Ado-not-merge+label%3Alanguage%2Fen+-base%3Amaster): `dev-` 브랜치에 대한 것일 경우, 곧 출시될 예정인 릴리스이다. `/assign @<meister's_github-username>` 을 사용하여 [문서 릴리스 관리자](https://github.com/kubernetes/sig-release/tree/master/release-team#kubernetes-release-team-roles)를 할당한다. 오래된 브랜치에 대한 PR인 경우, PR 작성자가 가장 적합한 브랜치를 대상으로 하고 있는지 여부를 파악할 수 있도록 도와준다. + +### 풀 리퀘스트를 종료하는 시기 + +리뷰와 승인은 PR 대기열을 최신 상태로 유지하는 도구 중 하나이다. 또 다른 도구는 종료(closure)이다. + +다음의 상황에서 PR을 닫는다. +- 작성자가 CLA에 2주 동안 서명하지 않았다. + + 작성자는 CLA에 서명한 후 PR을 다시 열 수 있다. 이는 어떤 것도 CLA 서명없이 병합되지 않게 하는 위험이 적은 방법이다. + +- 작성자가 2주 이상 동안 코멘트나 피드백에 응답하지 않았다. + +풀 리퀘스트를 닫는 것을 두려워하지 말자. 기여자는 진행 중인 작업을 쉽게 다시 열고 다시 시작할 수 있다. 종종 종료 통지는 작성자가 기여를 재개하고 끝내도록 자극하는 것이다. + +풀 리퀘스트를 닫으려면, PR에 `/close` 코멘트를 남긴다. + +{{< note >}} + +[`fejta-bot`](https://github.com/fejta-bot)이라는 봇은 90일 동안 활동이 없으면 이슈를 오래된 것(stale)으로 표시한다. 30일이 더 지나면 rotten으로 표시하고 종료한다. PR 랭글러는 14-30일 동안 활동이 없으면 이슈를 닫아야 한다. + +{{< /note >}} diff --git a/content/ko/docs/contribute/participate/roles-and-responsibilties.md b/content/ko/docs/contribute/participate/roles-and-responsibilties.md new file mode 100644 index 0000000000..252d07b332 --- /dev/null +++ b/content/ko/docs/contribute/participate/roles-and-responsibilties.md @@ -0,0 +1,234 @@ +--- +title: 역할과 책임 +content_type: concept +weight: 10 +--- + +<!-- overview --> + +누구나 쿠버네티스에 기여할 수 있다. SIG Docs에 대한 기여가 커짐에 따라, +커뮤니티의 다양한 멤버십을 신청할 수 있다. +이러한 역할을 통해 커뮤니티 내에서 더 많은 책임을 질 수 있다. +각 역할마다 많은 시간과 노력이 필요하다. 역할은 다음과 같다. + +- 모든 사람: 쿠버네티스 문서에 정기적으로 기여하는 기여자 +- 멤버: 이슈를 할당, 심사하고 풀 리퀘스트에 대한 구속력 없는 리뷰를 제공할 수 있다. +- 리뷰어: 문서의 풀 리퀘스트에 대한 리뷰를 리딩할 수 있으며 변경 사항에 대한 품질을 보증할 수 있다. +- 승인자: 문서에 대한 리뷰를 리딩하고 변경 사항을 병합할 수 있다 + +<!-- body --> + +## 모든 사람 + +GitHub 계정을 가진 누구나 쿠버네티스에 기여할 수 있다. SIG Docs는 모든 새로운 기여자를 환영한다! + +모든 사람은 다음의 작업을 할 수 있다. + +- [`kubernetes/website`](https://github.com/kubernetes/website)를 포함한 모든 + [쿠버네티스](https://github.com/kubernetes/) 리포지터리에서 + 이슈를 올린다. +- 풀 리퀘스트에 대해 구속력 없는 피드백을 제공한다. +- 현지화에 기여한다. +- [슬랙](http://slack.k8s.io/) 또는 + [SIG docs 메일링 리스트](https://groups.google.com/forum/#!forum/kubernetes-sig-docs)에 개선을 제안한다. + +[CLA에 서명](/ko/docs/contribute/new-content/overview/#sign-the-cla) 후에 누구나 다음을 할 수 있다. + +- 기존 콘텐츠를 개선하거나, 새 콘텐츠를 추가하거나, 블로그 게시물 또는 사례연구 작성을 위해 풀 리퀘스트를 연다. +- 다이어그램, 그래픽 자산 그리고 포함할 수 있는 스크린캐스트와 비디오를 제작한다. + +자세한 내용은 [새로운 콘텐츠 기여하기](/ko/docs/contribute/new-content/)를 참고한다. + +## 멤버 + +멤버는 `kubernetes/website` 에 여러 개의 풀 리퀘스트를 제출한 +사람이다. 멤버는 +[쿠버네티스 GitHub 조직](https://github.com/kubernetes)의 회원이다. + +멤버는 다음의 작업을 할 수 있다. + +- [모든 사람](#모든-사람)에 나열된 모든 것을 한다. +- 풀 리퀘스트에 `/lgtm` 코멘트를 사용하여 LGTM(looks good to me) 레이블을 추가한다. + + {{< note >}} + `/lgtm` 사용은 자동화를 트리거한다. 만약 구속력 없는 승인을 제공하려면, 단순히 "LGTM" 코멘트를 남기는 것도 좋다! + {{< /note >}} + +- `/hold` 코멘트를 사용하여 풀 리퀘스트에 대한 병합을 차단한다. +- `/assign` 코멘트를 사용하여 풀 리퀘스트에 리뷰어를 지정한다. +- 풀 리퀘스트에 구속력 없는 리뷰를 제공한다. +- 자동화를 사용하여 이슈를 심사하고 분류한다. +- 새로운 기능에 대한 문서를 작성한다. + +### 멤버 되기 + +최소 5개의 실질적인 풀 리퀘스트를 제출하고 다른 +[요구 사항](https://github.com/kubernetes/community/blob/master/community-membership.md#member)을 충족시킨 후, 다음의 단계를 따른다. + +1. 멤버십을 [후원](/docs/contribute/advanced#sponsor-a-new-contributor)해줄 두 명의 + [리뷰어](#리뷰어) 또는 [승인자](#승인자)를 + 찾는다. + + [슬랙의 #sig-docs 채널](https://kubernetes.slack.com) 또는 + [SIG Docs 메일링 리스트](https://groups.google.com/forum/#!forum/kubernetes-sig-docs)에서 후원을 요청한다. + + {{< note >}} + SIG Docs 멤버 개인에게 직접 email을 보내거나 + 슬랙 다이렉트 메시지를 보내지 않는다. 반드시 지원서를 제출하기 전에 후원을 요청해야 한다. + {{< /note >}} + +1. [`kubernetes/org`](https://github.com/kubernetes/org/) 리포지터리에 + GitHub 이슈를 등록한다. + **Organization Membership Request** 이슈 템플릿을 사용한다. + +1. 후원자에게 GitHub 이슈를 알린다. 다음 중 하나를 수행할 수 있다. + - 이슈에서 후원자의 GitHub 사용자 이름을 코멘트로 추가한다. (`@<GitHub-username>`) + - 슬랙 또는 이메일을 사용해 이슈 링크를 후원자에게 보낸다. + + 후원자는 `+1` 투표로 여러분의 요청을 승인할 것이다. 후원자가 요청을 승인하면, + 쿠버네티스 GitHub 관리자가 여러분을 멤버로 추가한다. + 축하한다! + + 만약 멤버십이 수락되지 않으면 피드백을 받게 될 것이다. 피드백의 내용을 해결한 후, 다시 지원하자. + +1. 여러분의 이메일 계정으로 수신된 쿠버네티스 GitHub 조직으로의 초대를 수락한다. + + {{< note >}} + GitHub은 초대를 여러분 계정의 기본 이메일 주소로 보낸다. + {{< /note >}} + +## 리뷰어 + +리뷰어는 열린 풀 리퀘스트를 리뷰할 책임이 있다. 멤버 피드백과는 달리, +여러분은 리뷰어의 피드백을 반드시 해결해야 한다. 리뷰어는 +[@kubernetes/sig-docs-{language}-reviews](https://github.com/orgs/kubernetes/teams?query=sig-docs) +GitHub 팀의 멤버이다. + +리뷰어는 다음의 작업을 수행할 수 있다. + +- [모든 사람](#모든-사람)과 [멤버](#멤버)에 나열된 모든 것을 수행한다. +- 풀 리퀘스트 리뷰와 구속력 있는 피드백을 제공한다. + + {{< note >}} + 구속력 없는 피드백을 제공하려면, 코멘트에 "선택 사항: "과 같은 문구를 접두어로 남긴다. + {{< /note >}} + +- 코드에서 사용자 화면 문자열 편집 +- 코드 코멘트 개선 + +여러분은 SIG DOcs 리뷰어이거나, 특정 주제 영역의 문서에 대한 리뷰어일 수 있다. + +### 풀 리퀘스트에 대한 리뷰어 할당 + +자동화 시스템은 모든 풀 리퀘스트에 대해 리뷰어를 할당한다. `/assign +[@_github_handle]` 코멘트를 남겨 특정 사람에게 리뷰를 요청할 수 +있다. + +지정된 리뷰어가 PR에 코멘트를 남기지 않는다면, 다른 리뷰어가 개입할 수 +있다. 필요에 따라 기술 리뷰어를 지정할 수도 있다. + +### `/lgtm` 사용하기 + +LGTM은 "Looks good to me"의 약자이며 풀 리퀘스트가 기술적으로 +정확하고 병합할 준비가 되었음을 나타낸다. 모든 PR은 리뷰어의 `/lgtm` 코멘트가 +필요하고 병합을 위해 승인자의 `/approve` 코멘트가 필요하다. + +리뷰어의 `/lgtm` 코멘트는 구속력 있고 자동화 시스템이 `lgtm` 레이블을 추가하도록 트리거한다. + +### 리뷰어 되기 + +[요건](https://github.com/kubernetes/community/blob/master/community-membership.md#reviewer)을 +충족하면, SIG Docs 리뷰어가 될 수 있다. 다른 SIG의 리뷰어는 SIG Docs의 리뷰어 자격에 +반드시 별도로 지원해야 한다. + +지원하려면, 다음을 수행한다. + +1. `kubernetes/website` 리포지터리 내 + [OWNERS_ALIASES](https://github.com/kubernetes/website/blob/master/OWNERS) 파일의 섹션에 + 여러분의 GitHub 사용자 이름을 추가하는 풀 리퀘스트를 연다. + + {{< note >}} + 자신을 추가할 위치가 확실하지 않으면, `sig-docs-ko-reviews` 에 추가한다. + {{< /note >}} + +1. PR을 하나 이상의 SIG-Docs 승인자(`sig-docs-{language}-owners` 에 + 나열된 사용자 이름)에게 지정한다. + +승인되면, SIG Docs 리더가 적당한 GitHub 팀에 여러분을 추가한다. 일단 추가되면, +[K8s-ci-robot](https://github.com/kubernetes/test-infra/tree/master/prow#bots-home)이 +새로운 풀 리퀘스트에서 리뷰어로 여러분을 할당하고 제안한다. + +## 승인자 + +승인자는 병합하기 위해 풀 리퀘스트를 리뷰하고 승인한다. 승인자는 +[@kubernetes/sig-docs-{language}-owners](https://github.com/orgs/kubernetes/teams/?query=sig-docs) +GitHub 팀의 멤버이다. + +승인자는 다음의 작업을 할 수 있다. + +- [모든 사람](#모든-사람), [멤버](#멤버) 그리고 [리뷰어](#리뷰어) 하위의 모든 목록을 할 수 있다. +- 코멘트에 `/approve` 를 사용해서 풀 리퀘스트를 승인하고, 병합해서 기여자의 컨텐츠를 게시한다. +- 스타일 가이드 개선을 제안한다. +- 문서 테스트 개선을 제안한다. +- 쿠버네티스 웹사이트 또는 다른 도구 개선을 제안한다. + +PR에 이미 `/lgtm` 이 있거나, 승인자도 `/lgtm` 코멘트를 남긴다면, +PR은 자동으로 병합된다. SIG Docs 승인자는 추가적인 기술 리뷰가 필요치 않는 변경에 대해서만 +`/lgtm` 을 남겨야 한다. + + +### 풀 리퀘스트 승인 + +승인자와 SIG Docs 리더는 website 리포지터리로 풀 리퀘스트를 병합할 수 있는 +유일한 사람들이다. 이것은 특정한 책임이 따른다. + +- 승인자는 PR들을 리포지터리에 병합하는 `/approve` 명령을 사용할 수 있다. + + {{< warning >}} + 부주의한 머지로 인해 사이트를 파괴할 수 있으므로, 머지할 때에 그 의미를 확인해야 한다. + {{< /warning >}} + +- 제안된 변경이 + [컨트리뷰션 가이드 라인](/docs/contribute/style/content-guide/#contributing-content)에 적합한지 확인한다. + + 질문이 생기거나 확실하지 않다면 자유롭게 + 추가 리뷰를 요청한다. + +- PR을 `/approve` 하기 전에 Netlify 테스트 결과를 검토한다. + + <img src="/images/docs/contribute/netlify-pass.png" width="75%" alt="승인 전에 반드시 Netlify 테스트를 통과해야 한다" /> + +- 승인 전에 PR에 대한 Netlify 프리뷰 페이지를 방문하여, 제대로 보이는지 확인한다. + +- 주간 로테이션을 위해 + [PR Wrangler 로테이션 스케줄](https://github.com/kubernetes/website/wiki/PR-Wranglers)에 + 참여한다. SIG Docs는 모든 승인자들이 이 로테이션에 참여할 것으로 기대한다. 자세한 내용은 + [PR 랭글러(PR wrangler)](/ko/docs/contribute/participating/pr-wranglers/)를 + 참고한다. + +## 승인자 되기 + +[요구 사항](https://github.com/kubernetes/community/blob/master/community-membership.md#approver)을 +충족하면 SIG Docs 승인자가 될 수 있다. +다른 SIG의 승인자는 SIG Docs의 승인자 자격에 대해 +별도로 신청해야 한다. + +지원하려면 다음을 수행한다. + +1. `kubernetes/website` 리포지터리 내 + [OWNERS_ALIASES](https://github.com/kubernetes/website/blob/master/OWNERS) + 파일의 섹션에 자신을 추가하는 풀 리퀘스트를 연다. + + {{< note >}} + 자신을 추가할 위치가 확실하지 않으면, `sig-docs-ko-owners` 에 추가한다. + {{< /note >}} + +2. PR에 한 명 이상의 현재 SIG Docs 승인자를 지정한다. + +승인되면, SIG Docs 리더가 적당한 GitHub 팀에 여러분을 추가한다. 일단 추가되면, +[@k8s-ci-robot](https://github.com/kubernetes/test-infra/tree/master/prow#bots-home)이 +새로운 풀 리퀘스트에서 승인자로 여러분을 할당하고 제안한다. + +## {{% heading "whatsnext" %}} + +- 모든 승인자가 교대로 수행하는 역할인 [PR 랭글러](/ko/docs/contribute/participating/pr-wranglers)에 대해 읽어보기 diff --git a/content/ko/docs/contribute/participating.md b/content/ko/docs/contribute/participating.md deleted file mode 100644 index 8f9cb0b5f6..0000000000 --- a/content/ko/docs/contribute/participating.md +++ /dev/null @@ -1,317 +0,0 @@ ---- -title: SIG Docs에 참여하기 -content_type: concept -weight: 60 -card: - name: contribute - weight: 60 ---- - -<!-- overview --> - -SIG Docs는 쿠버네티스 프로젝트의 -[분과회(special interest group)](https://github.com/kubernetes/community/blob/master/sig-list.md) -중 하나로, 쿠버네티스 전반에 대한 문서를 작성하고, 업데이트하며 유지보수하는 일을 주로 수행한다. -분과회에 대한 보다 자세한 정보는 -[커뮤니티 GitHub 저장소 내 SIG Docs](https://github.com/kubernetes/community/tree/master/sig-docs) -를 참조한다. - -SIG Docs는 모든 컨트리뷰터의 콘텐츠와 리뷰를 환영한다. -누구나 풀 리퀘스트(PR)를 요청할 수 있고, -누구나 콘텐츠에 대해 이슈를 등록하거나 진행 중인 풀 리퀘스트에 코멘트를 등록할 수 있다. - -[멤버](#멤버), [리뷰어](#리뷰어), 또는 [승인자](#승인자)가 될 수 있다. -이런 역할은 변경을 승인하고 커밋할 수 있도록 보다 많은 접근 권한과 이에 상응하는 책임이 수반된다. -쿠버네티스 커뮤니티 내에서 멤버십이 운영되는 방식에 대한 보다 많은 정보를 확인하려면 -[커뮤니티 멤버십](https://github.com/kubernetes/community/blob/master/community-membership.md) -문서를 확인한다. - -문서의 나머지에서는 대외적으로 쿠버네티스를 가장 잘 드러내는 수단 중 하나인 쿠버네티스 웹사이트와 -문서를 관리하는 책임을 가지는 SIG Docs에서, -이런 체계가 작동하는 특유의 방식에 대한 윤곽을 잡아보겠다. - - - -<!-- body --> - -## 역할과 책임 - -- **모든 사람** 은 쿠버네티스 문서에 기여할 수 있다. 기여시 [CLA에 서명](/docs/contribute/new-content/overview/#sign-the-cla))하고 GitHub 계정을 가지고 있어야 한다. -- 쿠버네티스 조직의 **멤버** 는 쿠버네티스 프로젝트에 시간과 노력을 투자한 기여자이다. 일반적으로 승인되는 변경이 되는 풀 리퀘스트를 연다. 멤버십 기준은 [커뮤니티 멤버십](https://github.com/kubernetes/community/blob/master/community-membership.md)을 참조한다. -- SIG Docs의 **리뷰어** 는 쿠버네티스 조직의 일원으로 - 문서 풀 리퀘스트에 관심을 표명했고, SIG Docs 승인자에 - 의해 GitHub 리포지터리에 있는 GitHub - 그룹과 `OWNER` 파일에 추가되었다. -- SIG Docs의 **승인자** 는 프로젝트에 대한 지속적인 헌신을 보여준 - 좋은 멤버이다. 승인자는 쿠버네티스 조직을 대신해서 - 풀 리퀘스트를 병합하고 컨텐츠를 게시할 수 있다. - 또한 승인자는 더 큰 쿠버네티스 커뮤니티의 SIG Docs를 대표할 수 있다. - 릴리즈 조정과 같은 SIG Docs 승인자의 일부 의무에는 - 상당한 시간 투입이 필요하다. - -## 모든 사람 - -누구나 다음 작업을 할 수 있다. - -- 문서를 포함한 쿠버네티스의 모든 부분에 대해 GitHub 이슈 열기. -- 풀 리퀘스트에 대한 구속력 없는 피드백 제공 -- 기존 컨텐츠를 현지화하는데 도움주는 것 -- [슬랙](http://slack.k8s.io/) 또는 [SIG docs 메일링 리스트](https://groups.google.com/forum/#!forum/kubernetes-sig-docs)에 개선할 아이디어를 제시한다. -- `/lgtm` Prow 명령 ("looks good to me" 의 줄임말)을 사용해서 병합을 위한 풀 리퀘스트의 변경을 추천한다. - {{< note >}} - 만약 쿠버네티스 조직의 멤버가 아니라면, `/lgtm` 을 사용하는 것은 자동화된 시스템에 아무런 영향을 주지 않는다. - {{< /note >}} - -[CLA에 서명](/docs/contribute/new-content/overview/#sign-the-cla)) 후에 누구나 다음을 할 수 있다. -- 기존 콘텐츠를 개선하거나, 새 콘텐츠를 추가하거나, 블로그 게시물 또는 사례연구 작성을 위해 풀 리퀘스트를 연다. - -## 멤버 - -멤버는 [멤버 기준](https://github.com/kubernetes/community/blob/master/community-membership.md#member)을 충족하는 쿠버네티스 프로젝트에 기여한 사람들이다. SIG Docs는 쿠버네티스 커뮤니티의 모든 멤버로부터 기여를 환경하며, -기술적 정확성에 대한 다른 SIG 멤버들의 검토를 수시로 요청한다. - -쿠버네티스 조직의 모든 멤버는 다음 작업을 할 수 있다. - -- [모든 사람](#모든-사람) 하위에 나열된 모든 것 -- 풀 리퀘스트 코멘트에 `/lgtm` 을 사용해서 LGTM(looks good to me) 레이블을 붙일 수 있다. -- 풀 리퀘스트에 이미 LGTM 과 승인 레이블이 있는 경우에 풀 리퀘스트가 병합되지 않도록 코멘트에 `/hold` 를 사용할 수 있다. -- 코멘트에 `/assgin` 을 사용해서 풀 리퀘스트에 리뷰어를 배정한다. - -### 멤버 되기 - -최소 5개의 실질적인 풀 리퀘스트를 성공적으로 제출한 경우, 쿠버네티스 조직의 -[멤버십](https://github.com/kubernetes/community/blob/master/community-membership.md#member)을 -요청할 수 있다. 다음의 단계를 따른다. - -1. 멤버십을 [후원](/docs/contribute/advanced#sponsor-a-new-contributor)해 줄 두 명의 리뷰어 또는 승인자를 - 찾는다. - - [쿠버네티스 Slack 인스턴스의 #sig-docs 채널](https://kubernetes.slack.com) 또는 - [SIG Docs 메일링 리스트](https://groups.google.com/forum/#!forum/kubernetes-sig-docs)에서 - 후원을 요청한다. - - {{< note >}} - SIG Docs 멤버 개인에게 직접 email을 보내거나 - Slack 다이렉트 메시지를 보내지 않는다. - {{< /note >}} - -2. `kubernetes/org` 리포지터리에 멤버십을 요청하는 GitHub 이슈를 등록한다. - [커뮤니티 멤버십](https://github.com/kubernetes/community/blob/master/community-membership.md) - 문서의 가이드라인을 따라서 양식을 채운다. - -3. 해당 GitHub 이슈에 후원자를 at-mentioning(`@<GitHub-username>`을 포함한 코멘트를 추가)하거나 - 링크를 직접 보내주어서 - 후원자가 해당 GitHub 이슈를 확인하고 `+1` 표를 줄 수 있도록 한다. - -4. 멤버십이 승인되면, 요청에 할당된 GitHub 관리자 팀 멤버가 승인되었음을 업데이트해주고 - 해당 GitHub 이슈를 종료한다. - 축하한다, 이제 멤버가 되었다! - -만약 멤버십 요청이 받아들여지지 않으면, -멤버십 위원회에서 재지원 전에 -필요한 정보나 단계를 알려준다. - -## 리뷰어 - -리뷰어는 -[@kubernetes/sig-docs-pr-reviews](https://github.com/orgs/kubernetes/teams/sig-docs-pr-reviews) -GitHub 그룹의 멤버이다. 리뷰어는 문서 풀 리퀘스트를 리뷰하고 제안받은 변경에 대한 피드백을 -제공한다. 리뷰어는 다음 작업을 수행할 수 있다. - -- [모든 사람](#모든-사람)과 [멤버](#멤버)에 나열된 모든 것을 수행 -- 새 기능의 문서화 -- 이슈 해결 및 분류 -- 풀 리퀘스트 리뷰와 구속력있는 피드백 제공 -- 다이어그램, 그래픽 자산과 포함가능한 스크린샷과 비디오를 생성 -- 코드에서 사용자 화면 문자열 편집 -- 코드 코멘트 개선 - -### 풀 리퀘스트에 대한 리뷰어 할당 - -자동화 시스템은 풀 리퀘스트에 대해 리뷰어를 할당하고, 사용자는 해당 풀 리퀘스트에 -`/assign [@_github_handle]` 코멘트를 남겨서 특정 리뷰어에게 리뷰를 요청할 수 있다. -풀 리퀘스트가 기술적으로 정확하고 더 변경이 필요하지 않다는 의미로, -리뷰어는 `/lgtm` 코멘트를 -해당 풀 리퀘스트에 추가할 수 있다. - -할당된 리뷰어가 내용을 아직 리뷰하지 않은 경우, -다른 리뷰어가 나설 수 있다. 추가로, 기술 리뷰어를 -할당해서 그들이 `/lgtm`을 주기를 기다릴 수도 있다. - -사소한 변경이나 기술적 리뷰가 필요한 PR의 경우, SIG Docs [승인자](#승인자)가 `/lgtm`을 줄 -수도 있다. - -리뷰어의 `/approve` 코멘트는 자동화 시스템에서 무시된다. - -### 리뷰어 되기 - -[요건](https://github.com/kubernetes/community/blob/master/community-membership.md#reviewer)을 -충족하면, SIG Docs 리뷰어가 될 수 있다. -다른 SIG의 리뷰어는 SIG Docs의 리뷰어 자격에 -반드시 별도로 지원해야 한다. - -지원하려면, `kubernetes/website` 저장소의 -[최상위 OWNERS 파일](https://github.com/kubernetes/website/blob/master/OWNERS) -내 `reviewers` 섹션에 자신을 추가하는 풀 리퀘스트를 연다. PR을 한 명 이상의 현재 SIG Docs -승인자에게 할당한다. - -풀 리퀘스트가 승인되면, 이제 SIG Docs 리뷰어가 된다. -[K8s-ci-robot](https://github.com/kubernetes/test-infra/tree/master/prow#bots-home)이 -새로운 풀 리퀘스트에 대한 리뷰어로 당신을 추천하게 된다. - -일단 승인되면, 현재 SIG Docs 승인자가 -[@kubernetes/sig-docs-pr-reviews](https://github.com/orgs/kubernetes/teams/sig-docs-pr-reviews) -GitHub 그룹에 당신을 추가하기를 요청한다. `kubernetes-website-admins` GitHub 그룹의 -멤버만이 신규 멤버를 GitHub 그룹에 추가할 수 있다. - -## 승인자 - -승인자는 -[@kubernetes/sig-docs-maintainers](https://github.com/orgs/kubernetes/teams/sig-docs-maintainers) -GitHub 그룹의 멤버이다. [SIG Docs 팀과 자동화](#sig-docs-팀과-자동화) 문서를 참조한다. - -승인자는 다음의 작업을 할 수 있다. - -- [모든 사람](#모든-사람), [멤버](#멤버) 그리고 [리뷰어](#리뷰어) 하위의 모든 목록을 할 수 있다. -- 코멘트에 `/approve` 를 사용해서 풀 리퀘스트를 승인하고, 병합해서 기여자의 컨텐츠를 게시한다. - 만약 승인자가 아닌 사람이 코멘트에 승인을 남기면 자동화 시스템에서 이를 무시한다. -- 쿠버네티스 릴리즈팀에 문서 담당자로 참여 -- 스타일 가이드 개선 제안 -- 문서 테스트 개선 제안 -- 쿠버네티스 웹사이트 또는 다른 도구 개선 제안 - -PR이 이미 `/lgtm`을 받았거나, 승인자가 `/lgtm`을 포함한 코멘트를 남긴 경우에는 -해당 PR이 자동으로 머지된다. SIG Docs 승인자는 추가적인 기술 리뷰가 필요하지 않은 변경에 대해서만 -`/lgtm`을 남겨야한다. - -### 승인자 되기 - -[요건](https://github.com/kubernetes/community/blob/master/community-membership.md#approver)을 -충족하면, SIG Docs 승인자가 될 수 있다. -다른 SIG의 승인자는 SIG Docs의 승인자 자격에 -반드시 별도로 지원해야 한다. - -지원하려면, `kubernetes/website` 저장소의 -[최상위 OWNERS 파일](https://github.com/kubernetes/website/blob/master/OWNERS) -내 `approvers` 섹션에 자신을 추가하는 풀 리퀘스트를 연다. PR을 한 명 이상의 현재 SIG Docs -승인자에게 할당한다. - -풀 리퀘스트가 승인되면, 이제 SIG Docs 승인자가 된다. -[K8s-ci-robot](https://github.com/kubernetes/test-infra/tree/master/prow#bots-home)이 -새로운 풀 리퀘스트에 대한 리뷰어로 당신을 추천하게 된다. - -일단 승인되면, 현재 SIG Docs 승인자가 -[@kubernetes/sig-docs-maintainers](https://github.com/orgs/kubernetes/teams/sig-docs-maintainers) -GitHub 그룹에 당신을 추가하기를 요청한다. `kubernetes-website-admins` GitHub 그룹의 -멤버만이 신규 멤버를 GitHub 그룹에 추가할 수 있다. - -### 승인자의 책임 - -승인자는 리뷰와 풀리퀘스트를 웹사이트 리포지터리에 머지하여 문서를 개선한다. 이 역할에는 추가적인 권한이 필요하므로, 승인자에게는 별도의 책임이 부여된다. - -- 승인자는 PR들을 리포에 머지하는 `/approve` 명령을 사용할 수 있다. - - 부주의한 머지로 인해 사이트를 파괴할 수 있으므로, 머지할 때에 그 의미를 확인해야 한다. - -- 제안된 변경이 [컨트리뷰션 가이드 라인](/docs/contribute/style/content-guide/#contributing-content)에 적합한지 확인한다. - - 질문이 생기거나 확실하지 않다면 자유롭게 추가 리뷰를 요청한다. - -- PR을 `/approve` 하기 전에 Netlify 테스트 결과를 검토한다. - - <img src="/images/docs/contribute/netlify-pass.png" width="75%" alt="승인 전에 반드시 Netlify 테스트를 통과해야 한다" /> - -- 승인 전에 PR에 대한 Netlify 프리뷰 페이지를 방문하여, 제대로 보이는지 확인한다. - -- 주간 로테이션을 위해 [PR Wrangler 로테이션 스케줄](https://github.com/kubernetes/website/wiki/PR-Wranglers)에 참여한다. SIG Docs는 모든 승인자들이 이 로테이션에 참여할 -것으로 기대한다. [일주일 간 PR Wrangler 되기](/docs/contribute/advanced#be-the-pr-wrangler-for-a-week) -문서를 참고한다. - -## SIG Docs 의장 - -SIG Docs를 포함한 각 SIG는, 한 명 이상의 SIG 멤버가 의장 역할을 하도록 선정한다. 이들은 SIG Docs와 -다른 쿠버네티스 조직 간 연락책(point of contact)이 된다. 이들은 쿠버네티스 프로젝트 전반의 조직과 -그 안에서 SIG Docs가 어떻게 운영되는지에 대한 폭넓은 지식을 갖추어야한다. -현재 의장의 목록을 확인하려면 -[리더십](https://github.com/kubernetes/community/tree/master/sig-docs#leadership) -문서를 참조한다. - -## SIG Docs 팀과 자동화 - -SIG Docs의 자동화는 다음의 두 가지 자동화 메커니즘에 의존한다. -GitHub 그룹과 OWNERS 파일이다. - -### GitHub 그룹 - -GitHub의 SIG Docs 그룹은 두 팀을 정의한다. - - - [@kubernetes/sig-docs-maintainers](https://github.com/orgs/kubernetes/teams/sig-docs-maintainers) - - [@kubernetes/sig-docs-pr-reviews](https://github.com/orgs/kubernetes/teams/sig-docs-pr-reviews) - -그룹의 전원과 의사소통하기 위해서 -각각 GitHub 코멘트에서 그룹의 `@name`으로 참조할 수 있다. - -이 팀은 중복되지만, 정확히 일치하지는 않으며, 이 그룹은 자동화 툴에서 사용된다. -이슈, 풀 리퀘스트를 할당하고, -PR 승인을 지원하기 위해서 자동화 시스템이 OWNERS 파일의 정보를 활용한다. - -### OWNERS 파일과 전문(front-matter) - -쿠버네티스 프로젝트는 GitHub 이슈와 풀 리퀘스트 자동화와 관련해서 prow라고 부르는 자동화 툴을 사용한다. -[쿠버네티스 웹사이트 리포지터리](https://github.com/kubernetes/website)는 -다음의 두개의 [prow 플러그인](https://github.com/kubernetes/test-infra/tree/master/prow/plugins)을 -사용한다. - -- blunderbuss -- approve - -이 두 플러그인은 `kubernetes/website` GitHub 리포지터리 최상위 수준에 있는 -[OWNERS](https://github.com/kubernetes/website/blob/master/OWNERS)와 -[OWNERS_ALIASES](https://github.com/kubernetes/website/blob/master/OWNERS_ALIASES) -파일을 사용해서 -해당 리포지터리에 대해 prow가 작동하는 방식을 제어한다. - -OWNERS 파일은 SIG Docs 리뷰어와 승인자의 목록을 포함한다. OWNERS 파일은 하위 디렉터리에 있을 수 -있고, 해당 하위 디렉터리와 그 이하의 파일에 대해 리뷰어와 승인자 역할을 수행할 사람을 새로 지정할 수 있다. -일반적인 OWNERS 파일에 대한 보다 많은 정보는 -[OWNERS](https://github.com/kubernetes/community/blob/master/contributors/guide/owners.md) -문서를 참고한다. - -추가로, 개별 마크다운(Markdown) 파일 내 전문에 -리뷰어와 승인자를 개별 GitHub 사용자 이름이나 GitHub 그룹으로 열거할 수 있다. - -OWNERS 파일과 마크다운 파일 내 전문의 조합은 -자동화 시스템이 누구에게 기술적, 편집적 리뷰를 요청해야 할지를 -PR 소유자에게 조언하는데 활용된다. - -## 병합 작업 방식 - -풀 리퀘스트 요청이 콘텐츠(현재 `master`)를 발행하는데 사용하는 -브랜치에 병합되면 그 내용이 전 세계에 공개된다. 게시된 콘텐츠의 -품질을 높히기 위해 SIG Docs 승인자가 풀 리퀘스트를 병합하는 것을 제한한다. -작동 방식은 다음과 같다. - -- 풀 리퀘스트에 `lgtm` 과 `approve` 레이블이 있고, `hold` 레이블이 없고, - 모든 테스트를 통과하면 풀 리퀘스트는 자동으로 병합된다. -- 쿠버네티스 조직의 멤버와 SIG Docs 승인자들은 지정된 풀 리퀘스트의 - 자동 병합을 방지하기 위해 코멘트를 추가할 수 있다(코멘트에 `/hold` 추가 또는 - `/lgtm` 코멘트 보류). -- 모든 쿠버네티스 멤버는 코멘트에 `/lgtm` 을 추가해서 `lgtm` 레이블을 추가할 수 있다. -- SIG Docs 승인자들만이 코멘트에 `/approve` 를 - 추가해서 풀 리퀘스트를 병합할 수 있다. 일부 승인자들은 - [PR Wrangler](/docs/contribute/advanced#be-the-pr-wrangler-for-a-week) 또는 [SIG Docs 의장](#sig-docs-의장)과 - 같은 특정 역할도 수행한다. - - - -## {{% heading "whatsnext" %}} - - -쿠버네티스 문서화에 기여하는 일에 대한 보다 많은 정보는 다음 문서를 참고한다. - -- [신규 컨텐츠 기여하기](/docs/contribute/overview/) -- [컨텐츠 검토하기](/docs/contribute/review/reviewing-prs) -- [문서 스타일 가이드](/docs/contribute/style/) - - - diff --git a/content/ko/docs/contribute/review/for-approvers.md b/content/ko/docs/contribute/review/for-approvers.md index 9b6c01d739..2e76e101be 100644 --- a/content/ko/docs/contribute/review/for-approvers.md +++ b/content/ko/docs/contribute/review/for-approvers.md @@ -8,7 +8,9 @@ weight: 20 <!-- overview --> -SIG Docs [리뷰어](/ko/docs/contribute/participating/#리뷰어)와 [승인자](/ko/docs/contribute/participating/#승인자)는 변경 사항을 리뷰할 때 몇 가지 추가 작업을 수행한다. +SIG Docs [리뷰어](/ko/docs/contribute/participate/roles-and-responsibilities/#리뷰어)와 +[승인자](/ko/docs/contribute/participate/roles-and-responsibilities/#승인자)는 변경 사항을 +리뷰할 때 몇 가지 추가 작업을 수행한다. 매주 특정 문서 승인자 역할의 지원자가 풀 리퀘스트를 심사하고 리뷰한다. 이 @@ -19,9 +21,6 @@ SIG Docs [리뷰어](/ko/docs/contribute/participating/#리뷰어)와 [승인자 로테이션 외에도, 봇은 영향을 받는 파일의 소유자를 기반으로 PR에 대한 리뷰어와 승인자를 할당한다. - - - <!-- body --> ## PR 리뷰 @@ -201,9 +200,9 @@ SIG Docs가 처리 방법을 문서화할 정도로 다음과 같은 유형의 ```none 이 이슈는 지원 요청과 비슷하지만 문서 관련 이슈와는 관련이 없는 것 같습니다. -[쿠버네티스 슬랙](http://slack.k8s.io/)의 +[쿠버네티스 슬랙](https://slack.k8s.io/)의 `#kubernetes-users` 채널에서 질문을 하시기 바랍니다. 또한, -[Stack Overflow](http://stackoverflow.com/questions/tagged/kubernetes)와 +[Stack Overflow](https://stackoverflow.com/questions/tagged/kubernetes)와 같은 리소스를 검색하여 유사한 질문에 대한 답변을 얻을 수도 있습니다. diff --git a/content/ko/docs/contribute/review/reviewing-prs.md b/content/ko/docs/contribute/review/reviewing-prs.md index b7416f505a..f0a164de00 100644 --- a/content/ko/docs/contribute/review/reviewing-prs.md +++ b/content/ko/docs/contribute/review/reviewing-prs.md @@ -16,10 +16,9 @@ weight: 10 리뷰하기 전에, 다음을 수행하는 것이 좋다. - 적합한 코멘트를 남길 수 있도록 [콘텐츠 가이드](/docs/contribute/style/content-guide/)와 -[스타일 가이드](/docs/contribute/style/style-guide/)를 읽는다. -- 쿠버네티스 문서화 커뮤니티의 다양한 [역할과 책임](/docs/contribute/participating/#roles-and-responsibilities)을 이해한다. - - + [스타일 가이드](/docs/contribute/style/style-guide/)를 읽는다. +- 쿠버네티스 문서화 커뮤니티의 다양한 + [역할과 책임](/ko/docs/contribute/participating/#역할과-책임)을 이해한다. <!-- body --> @@ -44,7 +43,7 @@ weight: 10 표시된다. 2. 다음 레이블 중 하나 또는 모두를 사용하여 열린 PR을 필터링한다. - - `cncf-cla: yes`(권장): CLA에 서명하지 않은 기여자가 제출한 PR은 병합할 수 없다. 자세한 내용은 [CLA 서명](/docs/contribute/new-content/overview/#sign-the-cla)을 참고한다. + - `cncf-cla: yes`(권장): CLA에 서명하지 않은 기여자가 제출한 PR은 병합할 수 없다. 자세한 내용은 [CLA 서명](/ko/docs/contribute/new-content/overview/#sign-the-cla)을 참고한다. - `language/en`(권장): 영어 문서에 대한 PR 전용 필터이다. - `size/<size>`: 특정 크기의 PR을 필터링한다. 새로 시작하는 사람이라면, 더 작은 PR로 시작한다. @@ -86,7 +85,7 @@ weight: 10 - 이 PR이 페이지 제목, slug/alias 또는 앵커(anchor) 링크를 변경 또는 제거하는가? 그렇다면, 이 PR의 결과로 끊어진 링크가 있는가? slug를 변경 없이 페이지 제목을 변경하는 등의 다른 옵션이 있는가? - PR이 새로운 페이지를 소개하는가? 그렇다면, - - 페이지가 올바른 [페이지 템플릿](/docs/contribute/style/page-templates/)과 연관된 Hugo 단축 코드를 사용하는가? + - 페이지가 올바른 [페이지 콘텐츠 타입](/docs/contribute/style/page-content-types/)과 연관된 Hugo 단축 코드를 사용하는가? - 섹션의 측면 탐색에 페이지가 올바르게 나타나는가? - 페이지가 [문서 홈](/ko/docs/home/) 목록에 나타나야 하는가? - 변경 사항이 Netlify 미리보기에 표시되는가? 목록, 코드 블록, 표, 메모 및 이미지에 특히 주의한다. @@ -94,5 +93,3 @@ weight: 10 ### 기타 오타나 공백과 같은 작은 이슈의 PR인 경우, 코멘트 앞에 `nit:` 를 추가한다. 이를 통해 문서의 저자는 이슈가 긴급하지 않다는 것을 알 수 있다. - - diff --git a/content/ko/docs/contribute/style/write-new-topic.md b/content/ko/docs/contribute/style/write-new-topic.md index 0c8ab86fbf..7441882615 100644 --- a/content/ko/docs/contribute/style/write-new-topic.md +++ b/content/ko/docs/contribute/style/write-new-topic.md @@ -10,7 +10,7 @@ weight: 20 ## {{% heading "prerequisites" %}} -[기여 시작하기](/docs/contribute/start/)에 설명된 대로 쿠버네티스 +[PR 열기](/ko/docs/contribute/new-content/open-a-pr/)에 설명된 대로 쿠버네티스 문서 저장소의 포크(fork)를 생성하자. @@ -28,22 +28,29 @@ weight: 20 튜토리얼 | 튜토리얼 페이지는 여러 쿠버네티스의 특징들을 하나로 묶어서 목적을 달성하는 방법을 보여준다. 튜토리얼은 독자들이 페이지를 읽을 때 실제로 할 수 있는 몇 가지 단계의 순서를 제공한다. 또는 관련 코드 일부에 대한 설명을 제공할 수도 있다. 예를 들어 튜토리얼은 코드 샘플의 연습을 제공할 수 있다. 튜토리얼에는 쿠버네티스의 특징에 대한 간략한 설명이 포함될 수 있지만 개별 기능에 대한 자세한 설명은 관련 개념 문서과 연결지어야 한다. {{< /table >}} -새 페이지에 대한 템플릿을 사용하자. 각 페이지 타입에 있는 -[템플릿](/docs/contribute/style/page-templates/) -은 문서를 작성할 때 사용할 수 있다. 템플릿을 사용하면 -지정된 타입의 문서 간에 일관성을 보장할 수 있다. +### 새 페이지 작성 + +작성하는 각각의 새 페이지에 대해 [콘텐츠 타입](/docs/contribute/style/page-content-types/)을 +사용하자. 문서 사이트는 새 콘텐츠 페이지를 작성하기 위한 템플리트 또는 +[Hugo archetypes](https://gohugo.io/content-management/archetypes/)을 +제공한다. 새로운 타입의 페이지를 작성하려면, 작성하려는 파일의 경로로 `hugo new` 를 +실행한다. 예를 들면, 다음과 같다. + +``` +hugo new docs/concepts/my-first-concept.md +``` ## 제목과 파일 이름 선택 검색 엔진에서 찾을 키워드가 있는 제목을 선택하자. 제목에 있는 단어를 하이픈으로 구분하여 사용하는 파일 이름을 만들자. 예를 들어 -[HTTP 프록시를 사용하여 쿠버네티스 API에 접근](/docs/tasks/access-kubernetes-api/http-proxy-access-api/) +[HTTP 프록시를 사용하여 쿠버네티스 API에 접근](/docs/tasks/extend-kubernetes/http-proxy-access-api/) 이라는 제목의 문서는 `http-proxy-access-api.md`라는 이름의 파일을 가진다. "쿠버네티스"가 이미 해당 주제의 URL에 있기 때문에 파일 이름에 "쿠버네티스" 를 넣을 필요가 없다. 예를 들면 다음과 같다. - /docs/tasks/access-kubernetes-api/http-proxy-access-api/ + /docs/tasks/extend-kubernetes/http-proxy-access-api/ ## 전문에 항목 제목 추가 @@ -56,30 +63,30 @@ YAML 블록이다. 여기 예시가 있다. title: HTTP 프록시를 사용하여 쿠버네티스 API에 접근 --- -## 디렉토리 선택 +## 디렉터리 선택 -페이지 타입에 따라 새로운 파일을 다음 중 하나의 하위 디렉토리에 넣자. +페이지 타입에 따라 새로운 파일을 다음 중 하나의 하위 디렉터리에 넣자. * /content/en/docs/tasks/ * /content/en/docs/tutorials/ * /content/en/docs/concepts/ -파일을 기존 하위 디렉토리에 넣거나 새 하위 디렉토리에 +파일을 기존 하위 디렉터리에 넣거나 새 하위 디렉터리에 넣을 수 있다. ## 목차에 항목 배치 -목차는 문서 소스의 디렉토리 구조를 사용하여 -동적으로 작성된다. `/content/en/docs/` 아래의 최상위 디렉토리는 최상위 레벨 탐색 기능을 -생성하고, 하위 디렉토리는 각각 목차에 항목을 +목차는 문서 소스의 디렉터리 구조를 사용하여 +동적으로 작성된다. `/content/en/docs/` 아래의 최상위 디렉터리는 최상위 레벨 탐색 기능을 +생성하고, 하위 디렉터리는 각각 목차에 항목을 갖는다. -각 하위 디렉토리에는 `_index.md` 파일이 있으며 이는 해당 하위 디렉토리의 컨텐츠에 대한 +각 하위 디렉터리에는 `_index.md` 파일이 있으며 이는 해당 하위 디렉터리의 컨텐츠에 대한 "홈" 페이지를 나타낸다. `_index.md`에는 템플릿이 필요없다. 그것은 -하위 디렉토리의 항목에 대한 개요 내용을 포함할 수 있다. +하위 디렉터리의 항목에 대한 개요 내용을 포함할 수 있다. -디렉토리의 다른 파일들은 기본적으로 알파벳순으로 정렬된다. 이것은 거의 -최적의 순서가 아니다. 하위 디렉토리에서 항목의 상대적 정렬을 제어하려면 +디렉터리의 다른 파일들은 기본적으로 알파벳순으로 정렬된다. 이것은 거의 +최적의 순서가 아니다. 하위 디렉터리에서 항목의 상대적 정렬을 제어하려면 `가중치:` 전문의 키를 정수로 설정하자. 일반적으로 우리는 나중에 항목을 추가하기 위해 10의 배수를 사용한다. 예를 들어 가중치가 `10`인 항목은 가중치가 `20`인 항목보다 우선한다. @@ -113,13 +120,13 @@ YAML 블록이다. 여기 예시가 있다. 샘플 YAML 파일을 포함시키려면 이 방법을 사용하자. YAML 파일과 같은 새로운 독립형 샘플 파일을 추가할 때 -`<LANG>/examples/` 의 하위 디렉토리 중 하나에 코드를 배치하자. 여기서 `<LANG>`은 +`<LANG>/examples/` 의 하위 디렉터리 중 하나에 코드를 배치하자. 여기서 `<LANG>`은 주제에 관한 언어이다. 문서 파일에서 `codenew` 단축 코드(shortcode)를 사용하자. ```none {{</* codenew file="<RELPATH>/my-example-yaml>" */>}} ``` -여기서 `<RELPATH>` 는 `examples` 디렉토리와 관련하여 포함될 +여기서 `<RELPATH>` 는 `examples` 디렉터리와 관련하여 포함될 파일의 경로이다. 다음 Hugo 단축 코드(shortcode)는 `/content/en/examples/pods/storage/gce-volume.yaml` 에 있는 YAML 파일을 참조한다. @@ -136,7 +143,7 @@ YAML 파일과 같은 새로운 독립형 샘플 파일을 추가할 때 ## 구성 파일에서 API 오브젝트를 작성하는 방법 표시 구성 파일을 기반으로 API 오브젝트를 생성하는 방법을 보여주려면 -`<LANG>/examples` 아래의 하위 디렉토리 중 하나에 +`<LANG>/examples` 아래의 하위 디렉터리 중 하나에 구성 파일을 배치하자. 문서에서 이 명령을 띄워보자. @@ -146,24 +153,23 @@ kubectl create -f https://k8s.io/examples/pods/storage/gce-volume.yaml ``` {{< note >}} -`<LANG>/examples` 디렉토리에 새 YAMl 파일을 추가할 때 파일이 +`<LANG>/examples` 디렉터리에 새 YAMl 파일을 추가할 때 파일이 `<LANG>/examples_test.go` 파일에도 포함되어 있는지 확인하자. 웹 사이트의 Travis CI 는 PR이 제출될 때 이 예제를 자동으로 실행하여 모든 예제가 테스트를 통과하도록 한다. {{< /note >}} 이 기술을 사용하는 문서의 예로 -[단일 인스턴스 스테이트풀 어플리케이션 실행](/docs/tutorials/stateful-application/run-stateful-application/)을 참조하자. +[단일 인스턴스 스테이트풀 어플리케이션 실행](/ko/docs/tasks/run-application/run-single-instance-stateful-application/)을 참조하자. ## 문서에 이미지 추가 -이미지 파일을 `/images` 디렉토리에 넣는다. 기본 +이미지 파일을 `/images` 디렉터리에 넣는다. 기본 이미지 형식은 SVG 이다. ## {{% heading "whatsnext" %}} -* [페이지 템플릿 사용](/docs/contribute/page-templates/))에 대해 알아보기. -* [풀 리퀘스트 작성](/docs/contribute/new-content/open-a-pr/)에 대해 알아보기. - +* [페이지 콘텐츠 타입 사용](/docs/contribute/style/page-content-types/)에 대해 알아보기. +* [풀 리퀘스트 작성](/ko/docs/contribute/new-content/new-content/)에 대해 알아보기. diff --git a/content/ko/docs/home/_index.md b/content/ko/docs/home/_index.md index 2432f8781c..20377994f1 100644 --- a/content/ko/docs/home/_index.md +++ b/content/ko/docs/home/_index.md @@ -43,7 +43,7 @@ cards: title: "교육" description: "공인 쿠버네티스 인증을 획득하고 클라우드 네이티브 프로젝트를 성공적으로 수행하세요!" button: "교육 보기" - button_path: "/training" + button_path: "/training" - name: reference title: 레퍼런스 정보 찾기 description: 용어, 커맨드 라인 구문, API 자원 종류, 그리고 설치 툴 문서를 살펴본다. @@ -54,9 +54,11 @@ cards: description: 이 프로젝트가 처음인 사람이든, 오래 활동한 사람이든 상관없이 누구나 기여할 수 있다. button: 문서에 기여하기 button_path: "/ko/docs/contribute" -- name: download - title: 쿠버네티스 내려받기 +- name: release-notes + title: 릴리스 노트 description: 쿠버네티스를 설치하거나 최신의 버전으로 업그레이드하는 경우, 현재 릴리스 노트를 참고한다. + button: "쿠버네티스 다운로드" + button_path: "/docs/setup/release/notes" - name: about title: 문서에 대하여 description: 이 웹사이트는 현재 버전과 이전 4개 버전의 쿠버네티스 문서를 포함한다. diff --git a/content/ko/docs/reference/command-line-tools-reference/_index.md b/content/ko/docs/reference/command-line-tools-reference/_index.md new file mode 100644 index 0000000000..0639d05b15 --- /dev/null +++ b/content/ko/docs/reference/command-line-tools-reference/_index.md @@ -0,0 +1,5 @@ +--- +title: 커맨드 라인 도구 레퍼런스 +weight: 60 +toc-hide: true +--- 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 new file mode 100644 index 0000000000..1e2796b484 --- /dev/null +++ b/content/ko/docs/reference/command-line-tools-reference/feature-gates.md @@ -0,0 +1,521 @@ +--- +weight: 10 +title: 기능 게이트 +content_type: concept +--- + +<!-- overview --> +이 페이지에는 관리자가 다른 쿠버네티스 컴포넌트에서 지정할 수 있는 다양한 +기능 게이트에 대한 개요가 포함되어 있다. + +기능의 단계(stage)에 대한 설명은 [기능 단계](#기능-단계)를 참고한다. + + +<!-- body --> +## 개요 + +기능 게이트는 쿠버네티스 기능을 설명하는 일련의 키=값 쌍이다. +각 쿠버네티스 컴포넌트에서 `--feature-gates` 커맨드 라인 플래그를 사용하여 +이러한 기능을 켜거나 끌 수 있다. + + +각 쿠버네티스 컴포넌트를 사용하면 해당 컴포넌트와 관련된 기능 게이트 집합을 +활성화 또는 비활성화할 수 있다. +모든 컴포넌트에 대한 전체 기능 게이트 집합을 보려면 `-h` 플래그를 사용한다. +kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 기능 쌍 목록에 지정된 `--feature-gates` 플래그를 사용한다. + +```shell +--feature-gates="...,DynamicKubeletConfig=true" +``` + +다음 표는 다른 쿠버네티스 컴포넌트에서 설정할 수 있는 기능 게이트를 +요약한 것이다. + +- "도입" 열에는 기능이 소개되거나 릴리스 단계가 변경될 때의 + 쿠버네티스 릴리스가 포함된다. +- "종료" 열이 비어 있지 않으면, 여전히 기능 게이트를 사용할 수 있는 마지막 + 쿠버네티스 릴리스가 포함된다. +- 기능이 알파 또는 베타 상태인 경우, + [알파/베타 기능 게이트 테이블](#알파-또는-베타-기능을-위한-기능-게이트)에서 나열된 기능을 찾을 수 있다. +- 기능이 안정된 경우 해당 기능에 대한 모든 단계를 + [GA(graduated)/사용 중단(deprecated) 기능 게이트 테이블](#GA-또는-사용-중단된-기능을-위한-기능-게이트)에 나열할 수 있다. +- [GA/사용 중단 기능 게이트 테이블](#GA-또는-사용-중단된-기능을-위한-기능-게이트)에는 + 사용 중단된 기능과 철회(withdrawn) 기능의 목록도 있다. + +### 알파 또는 베타 기능을 위한 기능 게이트 + +{{< table caption="알파 또는 베타 단계에 있는 기능을 위한 기능 게이트" >}} + +| 기능 | 디폴트 | 단계 | 도입 | 종료 | +|---------|---------|-------|-------|-------| +| `AnyVolumeDataSource` | `false` | 알파 | 1.18 | | +| `APIListChunking` | `false` | 알파 | 1.8 | 1.8 | +| `APIListChunking` | `true` | 베타 | 1.9 | | +| `APIPriorityAndFairness` | `false` | 알파 | 1.17 | | +| `APIResponseCompression` | `false` | 알파 | 1.7 | | +| `AppArmor` | `true` | 베타 | 1.4 | | +| `BalanceAttachedNodeVolumes` | `false` | 알파 | 1.11 | | +| `BoundServiceAccountTokenVolume` | `false` | 알파 | 1.13 | | +| `CPUManager` | `false` | 알파 | 1.8 | 1.9 | +| `CPUManager` | `true` | 베타 | 1.10 | | +| `CRIContainerLogRotation` | `false` | 알파 | 1.10 | 1.10 | +| `CRIContainerLogRotation` | `true` | 베타| 1.11 | | +| `CSIInlineVolume` | `false` | 알파 | 1.15 | 1.15 | +| `CSIInlineVolume` | `true` | 베타 | 1.16 | - | +| `CSIMigration` | `false` | 알파 | 1.14 | 1.16 | +| `CSIMigration` | `true` | 베타 | 1.17 | | +| `CSIMigrationAWS` | `false` | 알파 | 1.14 | | +| `CSIMigrationAWS` | `false` | 베타 | 1.17 | | +| `CSIMigrationAWSComplete` | `false` | 알파 | 1.17 | | +| `CSIMigrationAzureDisk` | `false` | 알파 | 1.15 | | +| `CSIMigrationAzureDiskComplete` | `false` | 알파 | 1.17 | | +| `CSIMigrationAzureFile` | `false` | 알파 | 1.15 | | +| `CSIMigrationAzureFileComplete` | `false` | 알파 | 1.17 | | +| `CSIMigrationGCE` | `false` | 알파 | 1.14 | 1.16 | +| `CSIMigrationGCE` | `false` | 베타 | 1.17 | | +| `CSIMigrationGCEComplete` | `false` | 알파 | 1.17 | | +| `CSIMigrationOpenStack` | `false` | 알파 | 1.14 | | +| `CSIMigrationOpenStackComplete` | `false` | 알파 | 1.17 | | +| `ConfigurableFSGroupPolicy` | `false` | 알파 | 1.18 | | +| `CustomCPUCFSQuotaPeriod` | `false` | 알파 | 1.12 | | +| `CustomResourceDefaulting` | `false` | 알파| 1.15 | 1.15 | +| `CustomResourceDefaulting` | `true` | 베타 | 1.16 | | +| `DevicePlugins` | `false` | 알파 | 1.8 | 1.9 | +| `DevicePlugins` | `true` | 베타 | 1.10 | | +| `DryRun` | `false` | 알파 | 1.12 | 1.12 | +| `DryRun` | `true` | 베타 | 1.13 | | +| `DynamicAuditing` | `false` | 알파 | 1.13 | | +| `DynamicKubeletConfig` | `false` | 알파 | 1.4 | 1.10 | +| `DynamicKubeletConfig` | `true` | 베타 | 1.11 | | +| `EndpointSlice` | `false` | 알파 | 1.16 | 1.16 | +| `EndpointSlice` | `false` | 베타 | 1.17 | | +| `EndpointSlice` | `true` | 베타 | 1.18 | | +| `EndpointSliceProxying` | `false` | 알파 | 1.18 | | +| `EphemeralContainers` | `false` | 알파 | 1.16 | | +| `ExpandCSIVolumes` | `false` | 알파 | 1.14 | 1.15 | +| `ExpandCSIVolumes` | `true` | 베타 | 1.16 | | +| `ExpandInUsePersistentVolumes` | `false` | 알파 | 1.11 | 1.14 | +| `ExpandInUsePersistentVolumes` | `true` | 베타 | 1.15 | | +| `ExpandPersistentVolumes` | `false` | 알파 | 1.8 | 1.10 | +| `ExpandPersistentVolumes` | `true` | 베타 | 1.11 | | +| `ExperimentalHostUserNamespaceDefaulting` | `false` | 베타 | 1.5 | | +| `EvenPodsSpread` | `false` | 알파 | 1.16 | 1.17 | +| `EvenPodsSpread` | `true` | 베타 | 1.18 | | +| `HPAScaleToZero` | `false` | 알파 | 1.16 | | +| `HugePageStorageMediumSize` | `false` | 알파 | 1.18 | | +| `HyperVContainer` | `false` | 알파 | 1.10 | | +| `ImmutableEphemeralVolumes` | `false` | 알파 | 1.18 | | +| `IPv6DualStack` | `false` | 알파 | 1.16 | | +| `KubeletPodResources` | `false` | 알파 | 1.13 | 1.14 | +| `KubeletPodResources` | `true` | 베타 | 1.15 | | +| `LegacyNodeRoleBehavior` | `true` | 알파 | 1.16 | | +| `LocalStorageCapacityIsolation` | `false` | 알파 | 1.7 | 1.9 | +| `LocalStorageCapacityIsolation` | `true` | 베타 | 1.10 | | +| `LocalStorageCapacityIsolationFSQuotaMonitoring` | `false` | 알파 | 1.15 | | +| `MountContainers` | `false` | 알파 | 1.9 | | +| `NodeDisruptionExclusion` | `false` | 알파 | 1.16 | | +| `NonPreemptingPriority` | `false` | 알파 | 1.15 | | +| `PodDisruptionBudget` | `false` | 알파 | 1.3 | 1.4 | +| `PodDisruptionBudget` | `true` | 베타 | 1.5 | | +| `PodOverhead` | `false` | 알파 | 1.16 | - | +| `ProcMountType` | `false` | 알파 | 1.12 | | +| `QOSReserved` | `false` | 알파 | 1.11 | | +| `RemainingItemCount` | `false` | 알파 | 1.15 | | +| `ResourceLimitsPriorityFunction` | `false` | 알파 | 1.9 | | +| `RotateKubeletClientCertificate` | `true` | 베타 | 1.8 | | +| `RotateKubeletServerCertificate` | `false` | 알파 | 1.7 | 1.11 | +| `RotateKubeletServerCertificate` | `true` | 베타 | 1.12 | | +| `RunAsGroup` | `true` | 베타 | 1.14 | | +| `RuntimeClass` | `false` | 알파 | 1.12 | 1.13 | +| `RuntimeClass` | `true` | 베타 | 1.14 | | +| `SCTPSupport` | `false` | 알파 | 1.12 | | +| `ServerSideApply` | `false` | 알파 | 1.14 | 1.15 | +| `ServerSideApply` | `true` | 베타 | 1.16 | | +| `ServiceAccountIssuerDiscovery` | `false` | Alpha | 1.18 | | +| `ServiceAppProtocol` | `false` | 알파 | 1.18 | | +| `ServiceNodeExclusion` | `false` | 알파 | 1.8 | | +| `ServiceTopology` | `false` | 알파 | 1.17 | | +| `StartupProbe` | `false` | 알파 | 1.16 | 1.17 | +| `StartupProbe` | `true` | 베타 | 1.18 | | +| `StorageVersionHash` | `false` | 알파 | 1.14 | 1.14 | +| `StorageVersionHash` | `true` | 베타 | 1.15 | | +| `StreamingProxyRedirects` | `false` | 베타 | 1.5 | 1.5 | +| `StreamingProxyRedirects` | `true` | 베타 | 1.6 | | +| `SupportNodePidsLimit` | `false` | 알파 | 1.14 | 1.14 | +| `SupportNodePidsLimit` | `true` | 베타 | 1.15 | | +| `SupportPodPidsLimit` | `false` | 알파 | 1.10 | 1.13 | +| `SupportPodPidsLimit` | `true` | 베타 | 1.14 | | +| `Sysctls` | `true` | 베타 | 1.11 | | +| `TokenRequest` | `false` | 알파 | 1.10 | 1.11 | +| `TokenRequest` | `true` | 베타 | 1.12 | | +| `TokenRequestProjection` | `false` | 알파 | 1.11 | 1.11 | +| `TokenRequestProjection` | `true` | 베타 | 1.12 | | +| `TTLAfterFinished` | `false` | 알파 | 1.12 | | +| `TopologyManager` | `false` | 알파 | 1.16 | | +| `ValidateProxyRedirects` | `false` | 알파 | 1.12 | 1.13 | +| `ValidateProxyRedirects` | `true` | 베타 | 1.14 | | +| `VolumeSnapshotDataSource` | `false` | 알파 | 1.12 | 1.16 | +| `VolumeSnapshotDataSource` | `true` | 베타 | 1.17 | - | +| `WindowsGMSA` | `false` | 알파 | 1.14 | | +| `WindowsGMSA` | `true` | 베타 | 1.16 | | +| `WinDSR` | `false` | 알파 | 1.14 | | +| `WinOverlay` | `false` | 알파 | 1.14 | | +{{< /table >}} + +### GA 또는 사용 중단된 기능을 위한 기능 게이트 + +{{< table caption="GA 또는 사용 중단 기능을 위한 기능 게이트" >}} + +| 기능 | 디폴트 | 단계 | 도입 | 종료 | +|---------|---------|-------|-------|-------| +| `Accelerators` | `false` | 알파 | 1.6 | 1.10 | +| `Accelerators` | - | 사용 중단 | 1.11 | - | +| `AdvancedAuditing` | `false` | 알파 | 1.7 | 1.7 | +| `AdvancedAuditing` | `true` | 베타 | 1.8 | 1.11 | +| `AdvancedAuditing` | `true` | GA | 1.12 | - | +| `AffinityInAnnotations` | `false` | 알파 | 1.6 | 1.7 | +| `AffinityInAnnotations` | - | 사용 중단 | 1.8 | - | +| `AllowExtTrafficLocalEndpoints` | `false` | 베타 | 1.4 | 1.6 | +| `AllowExtTrafficLocalEndpoints` | `true` | GA | 1.7 | - | +| `BlockVolume` | `false` | 알파 | 1.9 | 1.12 | +| `BlockVolume` | `true` | 베타 | 1.13 | 1.17 | +| `BlockVolume` | `true` | GA | 1.18 | - | +| `CSIBlockVolume` | `false` | 알파 | 1.11 | 1.13 | +| `CSIBlockVolume` | `true` | 베타 | 1.14 | 1.17 | +| `CSIBlockVolume` | `true` | GA | 1.18 | - | +| `CSIDriverRegistry` | `false` | 알파 | 1.12 | 1.13 | +| `CSIDriverRegistry` | `true` | 베타 | 1.14 | 1.17 | +| `CSIDriverRegistry` | `true` | GA | 1.18 | | +| `CSINodeInfo` | `false` | 알파 | 1.12 | 1.13 | +| `CSINodeInfo` | `true` | 베타 | 1.14 | 1.16 | +| `CSINodeInfo` | `true` | GA | 1.17 | | +| `AttachVolumeLimit` | `false` | 알파 | 1.11 | 1.11 | +| `AttachVolumeLimit` | `true` | 베타 | 1.12 | 1.16 | +| `AttachVolumeLimit` | `true` | GA | 1.17 | - | +| `CSIPersistentVolume` | `false` | 알파 | 1.9 | 1.9 | +| `CSIPersistentVolume` | `true` | 베타 | 1.10 | 1.12 | +| `CSIPersistentVolume` | `true` | GA | 1.13 | - | +| `CustomPodDNS` | `false` | 알파 | 1.9 | 1.9 | +| `CustomPodDNS` | `true` | 베타| 1.10 | 1.13 | +| `CustomPodDNS` | `true` | GA | 1.14 | - | +| `CustomResourcePublishOpenAPI` | `false` | 알파| 1.14 | 1.14 | +| `CustomResourcePublishOpenAPI` | `true` | 베타| 1.15 | 1.15 | +| `CustomResourcePublishOpenAPI` | `true` | GA | 1.16 | - | +| `CustomResourceSubresources` | `false` | 알파 | 1.10 | 1.10 | +| `CustomResourceSubresources` | `true` | 베타 | 1.11 | 1.15 | +| `CustomResourceSubresources` | `true` | GA | 1.16 | - | +| `CustomResourceValidation` | `false` | 알파 | 1.8 | 1.8 | +| `CustomResourceValidation` | `true` | 베타 | 1.9 | 1.15 | +| `CustomResourceValidation` | `true` | GA | 1.16 | - | +| `CustomResourceWebhookConversion` | `false` | 알파 | 1.13 | 1.14 | +| `CustomResourceWebhookConversion` | `true` | 베타 | 1.15 | 1.15 | +| `CustomResourceWebhookConversion` | `true` | GA | 1.16 | - | +| `DynamicProvisioningScheduling` | `false` | 알파 | 1.11 | 1.11 | +| `DynamicProvisioningScheduling` | - | 사용 중단| 1.12 | - | +| `DynamicVolumeProvisioning` | `true` | 알파 | 1.3 | 1.7 | +| `DynamicVolumeProvisioning` | `true` | GA | 1.8 | - | +| `EnableEquivalenceClassCache` | `false` | 알파 | 1.8 | 1.14 | +| `EnableEquivalenceClassCache` | - | 사용 중단 | 1.15 | - | +| `ExperimentalCriticalPodAnnotation` | `false` | 알파 | 1.5 | 1.12 | +| `ExperimentalCriticalPodAnnotation` | `false` | 사용 중단 | 1.13 | - | +| `GCERegionalPersistentDisk` | `true` | 베타 | 1.10 | 1.12 | +| `GCERegionalPersistentDisk` | `true` | GA | 1.13 | - | +| `HugePages` | `false` | 알파 | 1.8 | 1.9 | +| `HugePages` | `true` | 베타| 1.10 | 1.13 | +| `HugePages` | `true` | GA | 1.14 | - | +| `Initializers` | `false` | 알파 | 1.7 | 1.13 | +| `Initializers` | - | 사용 중단 | 1.14 | - | +| `KubeletConfigFile` | `false` | 알파 | 1.8 | 1.9 | +| `KubeletConfigFile` | - | 사용 중단 | 1.10 | - | +| `KubeletPluginsWatcher` | `false` | 알파 | 1.11 | 1.11 | +| `KubeletPluginsWatcher` | `true` | 베타 | 1.12 | 1.12 | +| `KubeletPluginsWatcher` | `true` | GA | 1.13 | - | +| `MountPropagation` | `false` | 알파 | 1.8 | 1.9 | +| `MountPropagation` | `true` | 베타 | 1.10 | 1.11 | +| `MountPropagation` | `true` | GA | 1.12 | - | +| `NodeLease` | `false` | 알파 | 1.12 | 1.13 | +| `NodeLease` | `true` | 베타 | 1.14 | 1.16 | +| `NodeLease` | `true` | GA | 1.17 | - | +| `PersistentLocalVolumes` | `false` | 알파 | 1.7 | 1.9 | +| `PersistentLocalVolumes` | `true` | 베타 | 1.10 | 1.13 | +| `PersistentLocalVolumes` | `true` | GA | 1.14 | - | +| `PodPriority` | `false` | 알파 | 1.8 | 1.10 | +| `PodPriority` | `true` | 베타 | 1.11 | 1.13 | +| `PodPriority` | `true` | GA | 1.14 | - | +| `PodReadinessGates` | `false` | 알파 | 1.11 | 1.11 | +| `PodReadinessGates` | `true` | 베타 | 1.12 | 1.13 | +| `PodReadinessGates` | `true` | GA | 1.14 | - | +| `PodShareProcessNamespace` | `false` | 알파 | 1.10 | 1.11 | +| `PodShareProcessNamespace` | `true` | 베타 | 1.12 | 1.16 | +| `PodShareProcessNamespace` | `true` | GA | 1.17 | - | +| `PVCProtection` | `false` | 알파 | 1.9 | 1.9 | +| `PVCProtection` | - | 사용 중단 | 1.10 | - | +| `RequestManagement` | `false` | 알파 | 1.15 | 1.16 | +| `ResourceQuotaScopeSelectors` | `false` | 알파 | 1.11 | 1.11 | +| `ResourceQuotaScopeSelectors` | `true` | 베타 | 1.12 | 1.16 | +| `ResourceQuotaScopeSelectors` | `true` | GA | 1.17 | - | +| `ScheduleDaemonSetPods` | `false` | 알파 | 1.11 | 1.11 | +| `ScheduleDaemonSetPods` | `true` | 베타 | 1.12 | 1.16 | +| `ScheduleDaemonSetPods` | `true` | GA | 1.17 | - | +| `ServiceLoadBalancerFinalizer` | `false` | 알파 | 1.15 | 1.15 | +| `ServiceLoadBalancerFinalizer` | `true` | 베타 | 1.16 | 1.16 | +| `ServiceLoadBalancerFinalizer` | `true` | GA | 1.17 | - | +| `StorageObjectInUseProtection` | `true` | 베타 | 1.10 | 1.10 | +| `StorageObjectInUseProtection` | `true` | GA | 1.11 | - | +| `SupportIPVSProxyMode` | `false` | 알파 | 1.8 | 1.8 | +| `SupportIPVSProxyMode` | `false` | 베타 | 1.9 | 1.9 | +| `SupportIPVSProxyMode` | `true` | 베타 | 1.10 | 1.10 | +| `SupportIPVSProxyMode` | `true` | GA | 1.11 | - | +| `TaintBasedEvictions` | `false` | 알파 | 1.6 | 1.12 | +| `TaintBasedEvictions` | `true` | 베타 | 1.13 | 1.17 | +| `TaintBasedEvictions` | `true` | GA | 1.18 | - | +| `TaintNodesByCondition` | `false` | 알파 | 1.8 | 1.11 | +| `TaintNodesByCondition` | `true` | 베타 | 1.12 | 1.16 | +| `TaintNodesByCondition` | `true` | GA | 1.17 | - | +| `VolumePVCDataSource` | `false` | 알파 | 1.15 | 1.15 | +| `VolumePVCDataSource` | `true` | 베타 | 1.16 | 1.17 | +| `VolumePVCDataSource` | `true` | GA | 1.18 | - | +| `VolumeScheduling` | `false` | 알파 | 1.9 | 1.9 | +| `VolumeScheduling` | `true` | 베타 | 1.10 | 1.12 | +| `VolumeScheduling` | `true` | GA | 1.13 | - | +| `VolumeSubpath` | `true` | GA | 1.13 | - | +| `VolumeSubpathEnvExpansion` | `false` | 알파 | 1.14 | 1.14 | +| `VolumeSubpathEnvExpansion` | `true` | 베타 | 1.15 | 1.16 | +| `VolumeSubpathEnvExpansion` | `true` | GA | 1.17 | - | +| `WatchBookmark` | `false` | 알파 | 1.15 | 1.15 | +| `WatchBookmark` | `true` | 베타 | 1.16 | 1.16 | +| `WatchBookmark` | `true` | GA | 1.17 | - | +| `WindowsGMSA` | `false` | 알파 | 1.14 | 1.15 | +| `WindowsGMSA` | `true` | 베타 | 1.16 | 1.17 | +| `WindowsGMSA` | `true` | GA | 1.18 | - | +| `WindowsRunAsUserName` | `false` | 알파 | 1.16 | 1.16 | +| `WindowsRunAsUserName` | `true` | 베타 | 1.17 | 1.17 | +| `WindowsRunAsUserName` | `true` | GA | 1.18 | - | +{{< /table >}} + +## 기능 사용 + +### 기능 단계 + +기능은 *알파*, *베타* 또는 *GA* 단계일 수 있다. +*알파* 기능은 다음을 의미한다. + +* 기본적으로 비활성화되어 있다. +* 버그가 있을 수 있다. 이 기능을 사용하면 버그에 노출될 수 있다. +* 기능에 대한 지원은 사전 통지없이 언제든지 중단될 수 있다. +* API는 이후 소프트웨어 릴리스에서 예고없이 호환되지 않는 방식으로 변경될 수 있다. +* 버그의 위험이 증가하고 장기 지원이 부족하여, 단기 테스트 + 클러스터에서만 사용하는 것이 좋다. + +*베타* 기능은 다음을 의미한다. + +* 기본적으로 활성화되어 있다. +* 이 기능은 잘 테스트되었다. 이 기능을 활성화하면 안전한 것으로 간주된다. +* 세부 내용은 변경될 수 있지만, 전체 기능에 대한 지원은 중단되지 않는다. +* 오브젝트의 스키마 및/또는 시맨틱은 후속 베타 또는 안정 릴리스에서 + 호환되지 않는 방식으로 변경될 수 있다. 이러한 상황이 발생하면, 다음 버전으로 마이그레이션하기 위한 + 지침을 제공한다. API 오브젝트를 삭제, 편집 및 재작성해야 + 할 수도 있다. 편집 과정에서 약간의 생각이 필요할 수 있다. + 해당 기능에 의존하는 애플리케이션의 경우 다운타임이 필요할 수 있다. +* 후속 릴리스에서 호환되지 않는 변경이 발생할 수 있으므로 + 업무상 중요하지 않은(non-business-critical) 용도로만 + 권장한다. 독립적으로 업그레이드할 수 있는 여러 클러스터가 있는 경우, 이 제한을 완화할 수 있다. + +{{< note >}} +*베타* 기능을 사용해 보고 의견을 보내주길 바란다! +베타 기간이 종료된 후에는, 더 많은 변경을 하는 것이 실용적이지 않을 수 있다. +{{< /note >}} + +*GA*(General Availability) 기능은 *안정* 기능이라고도 한다. 이 의미는 다음과 같다. + +* 이 기능은 항상 활성화되어 있다. 비활성화할 수 없다. +* 해당 기능 게이트는 더 이상 필요하지 않다. +* 여러 후속 버전의 릴리스된 소프트웨어에 안정적인 기능의 버전이 포함된다. + +## 기능 게이트 목록 {#feature-gates} + +각 기능 게이트는 특정 기능을 활성화/비활성화하도록 설계되었다. + +- `Accelerators`: 도커 사용 시 Nvidia GPU 지원 활성화한다. +- `AdvancedAuditing`: [고급 감사](/docs/tasks/debug-application-cluster/audit/#advanced-audit) 기능을 활성화한다. +- `AffinityInAnnotations`(*사용 중단됨*): [파드 어피니티 또는 안티-어피니티](/ko/docs/concepts/scheduling-eviction/assign-pod-node/#어피니티-affinity-와-안티-어피니티-anti-affinity) 설정을 활성화한다. +- `AllowExtTrafficLocalEndpoints`: 서비스가 외부 요청을 노드의 로컬 엔드포인트로 라우팅할 수 있도록 한다. +- `AnyVolumeDataSource`: {{< glossary_tooltip text="PVC" term_id="persistent-volume-claim" >}}의 + `DataSource` 로 모든 사용자 정의 리소스 사용을 활성화한다. +- `APIListChunking`: API 클라이언트가 API 서버에서 (`LIST` 또는 `GET`) 리소스를 청크(chunks)로 검색할 수 있도록 한다. +- `APIPriorityAndFairness`: 각 서버의 우선 순위와 공정성을 통해 동시 요청을 관리할 수 ​​있다. (`RequestManagement` 에서 이름이 변경됨) +- `APIResponseCompression`: `LIST` 또는 `GET` 요청에 대한 API 응답을 압축한다. +- `AppArmor`: 도커를 사용할 때 리눅스 노드에서 AppArmor 기반의 필수 접근 제어를 활성화한다. + 자세한 내용은 [AppArmor 튜토리얼](/ko/docs/tutorials/clusters/apparmor/)을 참고한다. +- `AttachVolumeLimit`: 볼륨 플러그인이 노드에 연결될 수 있는 볼륨 수에 + 대한 제한을 보고하도록 한다. + 자세한 내용은 [동적 볼륨 제한](/docs/concepts/storage/storage-limits/#dynamic-volume-limits)을 참고한다. +- `BalanceAttachedNodeVolumes`: 스케줄링 시 균형 잡힌 리소스 할당을 위해 고려할 노드의 볼륨 수를 + 포함한다. 스케줄러가 결정을 내리는 동안 CPU, 메모리 사용률 및 볼륨 수가 + 더 가까운 노드가 선호된다. +- `BlockVolume`: 파드에서 원시 블록 장치의 정의와 사용을 활성화한다. + 자세한 내용은 [원시 블록 볼륨 지원](/ko/docs/concepts/storage/persistent-volumes/#원시-블록-볼륨-지원)을 + 참고한다. +- `BoundServiceAccountTokenVolume`: ServiceAccountTokenVolumeProjection으로 구성된 프로젝션 볼륨을 사용하도록 서비스어카운트 볼륨을 + 마이그레이션한다. + 자세한 내용은 [서비스 어카운트 토큰 볼륨](https://git.k8s.io/community/contributors/design-proposals/storage/svcacct-token-volume-source.md)을 + 확인한다. +- `ConfigurableFSGroupPolicy`: 파드에 볼륨을 마운트할 때 fsGroups에 대한 볼륨 권한 변경 정책을 구성할 수 있다. 자세한 내용은 [파드에 대한 볼륨 권한 및 소유권 변경 정책 구성](/docs/tasks/configure-pod-container/security-context/#configure-volume-permission-and-ownership-change-policy-for-pods)을 참고한다. +- `CPUManager`: 컨테이너 수준의 CPU 어피니티 지원을 활성화한다. [CPU 관리 정책](/docs/tasks/administer-cluster/cpu-management-policies/)을 참고한다. +- `CRIContainerLogRotation`: cri 컨테이너 런타임에 컨테이너 로그 로테이션을 활성화한다. +- `CSIBlockVolume`: 외부 CSI 볼륨 드라이버가 블록 스토리지를 지원할 수 있게 한다. 자세한 내용은 [`csi` 원시 블록 볼륨 지원](/ko/docs/concepts/storage/volumes/#csi-원시-raw-블록-볼륨-지원) 문서를 참고한다. +- `CSIDriverRegistry`: csi.storage.k8s.io에서 CSIDriver API 오브젝트와 관련된 모든 로직을 활성화한다. +- `CSIInlineVolume`: 파드에 대한 CSI 인라인 볼륨 지원을 활성화한다. +- `CSIMigration`: shim 및 변환 로직을 통해 볼륨 작업을 인-트리 플러그인에서 사전 설치된 해당 CSI 플러그인으로 라우팅할 수 있다. +- `CSIMigrationAWS`: shim 및 변환 로직을 통해 볼륨 작업을 AWS-EBS 인-트리 플러그인에서 EBS CSI 플러그인으로 라우팅할 수 있다. 노드에 EBS CSI 플러그인이 설치와 구성이 되어 있지 않은 경우 인-트리 EBS 플러그인으로 폴백(falling back)을 지원한다. CSIMigration 기능 플래그가 필요하다. +- `CSIMigrationAWSComplete`: kubelet 및 볼륨 컨트롤러에서 EBS 인-트리 플러그인 등록을 중지하고 shim 및 변환 로직을 사용하여 볼륨 작업을 AWS-EBS 인-트리 플러그인에서 EBS CSI 플러그인으로 라우팅할 수 있다. 클러스터의 모든 노드에 CSIMigration과 CSIMigrationAWS 기능 플래그가 활성화되고 EBS CSI 플러그인이 설치 및 구성이 되어 있어야 한다. +- `CSIMigrationAzureDisk`: shim 및 변환 로직을 통해 볼륨 작업을 Azure-Disk 인-트리 플러그인에서 AzureDisk CSI 플러그인으로 라우팅할 수 있다. 노드에 AzureDisk CSI 플러그인이 설치와 구성이 되어 있지 않은 경우 인-트리 AzureDisk 플러그인으로 폴백을 지원한다. CSIMigration 기능 플래그가 필요하다. +- `CSIMigrationAzureDiskComplete`: kubelet 및 볼륨 컨트롤러에서 Azure-Disk 인-트리 플러그인 등록을 중지하고 shim 및 변환 로직을 사용하여 볼륨 작업을 Azure-Disk 인-트리 플러그인에서 AzureDisk CSI 플러그인으로 라우팅할 수 있다. 클러스터의 모든 노드에 CSIMigration과 CSIMigrationAzureDisk 기능 플래그가 활성화되고 AzureDisk CSI 플러그인이 설치 및 구성이 되어 있어야 한다. +- `CSIMigrationAzureFile`: shim 및 변환 로직을 통해 볼륨 작업을 Azure-File 인-트리 플러그인에서 AzureFile CSI 플러그인으로 라우팅할 수 있다. 노드에 AzureFile CSI 플러그인이 설치 및 구성이 되어 있지 않은 경우 인-트리 AzureFile 플러그인으로 폴백을 지원한다. CSIMigration 기능 플래그가 필요하다. +- `CSIMigrationAzureFileComplete`: kubelet 및 볼륨 컨트롤러에서 Azure 파일 인-트리 플러그인 등록을 중지하고 shim 및 변환 로직을 통해 볼륨 작업을 Azure 파일 인-트리 플러그인에서 AzureFile CSI 플러그인으로 라우팅할 수 있다. 클러스터의 모든 노드에 CSIMigration과 CSIMigrationAzureFile 기능 플래그가 활성화되고 AzureFile CSI 플러그인이 설치 및 구성이 되어 있어야 한다. +- `CSIMigrationGCE`: shim 및 변환 로직을 통해 볼륨 작업을 GCE-PD 인-트리 플러그인에서 PD CSI 플러그인으로 라우팅할 수 있다. 노드에 PD CSI 플러그인이 설치 및 구성이 되어 있지 않은 경우 인-트리 GCE 플러그인으로 폴백을 지원한다. CSIMigration 기능 플래그가 필요하다. +- `CSIMigrationGCEComplete`: kubelet 및 볼륨 컨트롤러에서 GCE-PD 인-트리 플러그인 등록을 중지하고 shim 및 변환 로직을 통해 볼륨 작업을 GCE-PD 인-트리 플러그인에서 PD CSI 플러그인으로 라우팅할 수 있다. CSIMigration과 CSIMigrationGCE 기능 플래그가 필요하다. +- `CSIMigrationOpenStack`: shim 및 변환 로직을 통해 볼륨 작업을 Cinder 인-트리 플러그인에서 Cinder CSI 플러그인으로 라우팅할 수 있다. 노드에 Cinder CSI 플러그인이 설치 및 구성이 되어 있지 않은 경우 인-트리 Cinder 플러그인으로 폴백을 지원한다. CSIMigration 기능 플래그가 필요하다. +- `CSIMigrationOpenStackComplete`: kubelet 및 볼륨 컨트롤러에서 Cinder 인-트리 플러그인 등록을 중지하고 shim 및 변환 로직이 Cinder 인-트리 플러그인에서 Cinder CSI 플러그인으로 볼륨 작업을 라우팅할 수 있도록 한다. 클러스터의 모든 노드에 CSIMigration과 CSIMigrationOpenStack 기능 플래그가 활성화되고 Cinder CSI 플러그인이 설치 및 구성이 되어 있어야 한다. +- `CSINodeInfo`: csi.storage.k8s.io에서 CSINodeInfo API 오브젝트와 관련된 모든 로직을 활성화한다. +- `CSIPersistentVolume`: [CSI (Container Storage Interface)](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/storage/container-storage-interface.md) + 호환 볼륨 플러그인을 통해 프로비저닝된 볼륨을 감지하고 + 마운트할 수 있다. + 자세한 내용은 [`csi` 볼륨 유형](/ko/docs/concepts/storage/volumes/#csi) 문서를 확인한다. +- `CustomCPUCFSQuotaPeriod`: 노드가 CPUCFSQuotaPeriod를 변경하도록 한다. +- `CustomPodDNS`: `dnsConfig` 속성을 사용하여 파드의 DNS 설정을 사용자 정의할 수 있다. + 자세한 내용은 [파드의 DNS 설정](/ko/docs/concepts/services-networking/dns-pod-service/#pod-dns-config)을 + 확인한다. +- `CustomResourceDefaulting`: OpenAPI v3 유효성 검사 스키마에서 기본값에 대한 CRD 지원을 활성화한다. +- `CustomResourcePublishOpenAPI`: CRD OpenAPI 사양을 게시할 수 있다. +- `CustomResourceSubresources`: [커스텀리소스데피니션](/ko/docs/concepts/extend-kubernetes/api-extension/custom-resources/)에서 + 생성된 리소스에서 `/status` 및 `/scale` 하위 리소스를 활성화한다. +- `CustomResourceValidation`: [커스텀리소스데피니션](/ko/docs/concepts/extend-kubernetes/api-extension/custom-resources/)에서 + 생성된 리소스에서 스키마 기반 유효성 검사를 활성화한다. +- `CustomResourceWebhookConversion`: [커스텀리소스데피니션](/ko/docs/concepts/extend-kubernetes/api-extension/custom-resources/)에서 + 생성된 리소스에 대해 웹 훅 기반의 변환을 활성화한다. + 실행 중인 파드 문제를 해결한다. +- `DevicePlugins`: 노드에서 [장치 플러그인](/ko/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins/) + 기반 리소스 프로비저닝을 활성화한다. +- `DryRun`: 서버 측의 [dry run](/docs/reference/using-api/api-concepts/#dry-run) 요청을 + 요청을 활성화하여 커밋하지 않고 유효성 검사, 병합 및 변화를 테스트할 수 있다. +- `DynamicAuditing`: [동적 감사](/docs/tasks/debug-application-cluster/audit/#dynamic-backend) 기능을 활성화한다. +- `DynamicKubeletConfig`: kubelet의 동적 구성을 활성화한다. [kubelet 재구성](/docs/tasks/administer-cluster/reconfigure-kubelet/)을 참고한다. +- `DynamicProvisioningScheduling`: 볼륨 스케줄을 인식하고 PV 프로비저닝을 처리하도록 기본 스케줄러를 확장한다. + 이 기능은 v1.12의 `VolumeScheduling` 기능으로 대체되었다. +- `DynamicVolumeProvisioning`(*사용 중단됨*): 파드에 퍼시스턴트 볼륨의 [동적 프로비저닝](/ko/docs/concepts/storage/dynamic-provisioning/)을 활성화한다. +- `EnableAggregatedDiscoveryTimeout` (*사용 중단됨*): 수집된 검색 호출에서 5초 시간 초과를 활성화한다. +- `EnableEquivalenceClassCache`: 스케줄러가 파드를 스케줄링할 때 노드의 동등성을 캐시할 수 있게 한다. +- `EphemeralContainers`: 파드를 실행하기 위한 {{< glossary_tooltip text="임시 컨테이너" + term_id="ephemeral-container" >}}를 추가할 수 있다. +- `EvenPodsSpread`: 토폴로지 도메인 간에 파드를 균등하게 스케줄링할 수 있다. [파드 토폴로지 분배 제약 조건](/ko/docs/concepts/workloads/pods/pod-topology-spread-constraints/)을 참고한다. +- `ExpandInUsePersistentVolumes`: 사용 중인 PVC를 확장할 수 있다. [사용 중인 퍼시스턴트볼륨클레임 크기 조정](/ko/docs/concepts/storage/persistent-volumes/#사용-중인-퍼시스턴트볼륨클레임-크기-조정)을 참고한다. +- `ExpandPersistentVolumes`: 퍼시스턴트 볼륨 확장을 활성화한다. [퍼시스턴트 볼륨 클레임 확장](/ko/docs/concepts/storage/persistent-volumes/#퍼시스턴트-볼륨-클레임-확장)을 참고한다. +- `ExperimentalCriticalPodAnnotation`: 특정 파드에 *critical* 로 어노테이션을 달아서 [스케줄링이 보장되도록](/docs/tasks/administer-cluster/guaranteed-scheduling-critical-addon-pods/) 한다. + 이 기능은 v1.13부터 파드 우선 순위 및 선점으로 인해 사용 중단되었다. +- `ExperimentalHostUserNamespaceDefaultingGate`: 사용자 네임스페이스를 호스트로 + 기본 활성화한다. 이것은 다른 호스트 네임스페이스, 호스트 마운트, + 권한이 있는 컨테이너 또는 특정 비-네임스페이스(non-namespaced) 기능(예: `MKNODE`, `SYS_MODULE` 등)을 + 사용하는 컨테이너를 위한 것이다. 도커 데몬에서 사용자 네임스페이스 + 재 매핑이 활성화된 경우에만 활성화해야 한다. +- `EndpointSlice`: 보다 스케일링 가능하고 확장 가능한 네트워크 엔드포인트에 대한 + 엔드포인트 슬라이스를 활성화한다. [엔드포인트 슬라이스 활성화](/docs/tasks/administer-cluster/enabling-endpointslices/)를 참고한다. +- `EndpointSliceProxying`: 이 기능 게이트가 활성화되면, kube-proxy는 + 엔드포인트슬라이스를 엔드포인트 대신 기본 데이터 소스로 사용하여 + 확장성과 성능을 향상시킨다. [엔드포인트 슬라이스 활성화](/docs/tasks/administer-cluster/enabling-endpointslices/)를 참고한다. +- `GCERegionalPersistentDisk`: GCE에서 지역 PD 기능을 활성화한다. +- `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) 기능을 활성화한다. +- `HPAScaleToZero`: 사용자 정의 또는 외부 메트릭을 사용할 때 `HorizontalPodAutoscaler` 리소스에 대해 `minReplicas` 를 0으로 설정한다. +- `ImmutableEphemeralVolumes`: 안정성과 성능 향상을 위해 개별 시크릿(Secret)과 컨피그맵(ConfigMap)을 변경할 수 없는(immutable) 것으로 표시할 수 있다. +- `KubeletConfigFile`: 구성 파일을 사용하여 지정된 파일에서 kubelet 구성을 로드할 수 있다. + 자세한 내용은 [구성 파일을 통해 kubelet 파라미터 설정](/docs/tasks/administer-cluster/kubelet-config-file/)을 참고한다. +- `KubeletPluginsWatcher`: kubelet이 [CSI 볼륨 드라이버](/ko/docs/concepts/storage/volumes/#csi)와 같은 + 플러그인을 검색할 수 있도록 프로브 기반 플러그인 감시자(watcher) 유틸리티를 사용한다. +- `KubeletPodResources`: kubelet의 파드 리소스 grpc 엔드포인트를 활성화한다. + 자세한 내용은 [장치 모니터링 지원](https://github.com/kubernetes/enhancements/blob/master/keps/sig-node/compute-device-assignment.md)을 참고한다. +- `LegacyNodeRoleBehavior`: 비활성화되면, 서비스 로드 밸런서 및 노드 중단의 레거시 동작은 기능별 레이블을 대신하여 `node-role.kubernetes.io/master` 레이블을 무시한다. +- `LocalStorageCapacityIsolation`: [로컬 임시 스토리지](/ko/docs/concepts/configuration/manage-resources-containers/)와 [emptyDir 볼륨](/ko/docs/concepts/storage/volumes/#emptydir)의 `sizeLimit` 속성을 사용할 수 있게 한다. +- `LocalStorageCapacityIsolationFSQuotaMonitoring`: [로컬 임시 스토리지](/ko/docs/concepts/configuration/manage-resources-containers/)에 대해 `LocalStorageCapacityIsolation`이 활성화되고 [emptyDir 볼륨](/ko/docs/concepts/storage/volumes/#emptydir)에 대한 백업 파일시스템이 프로젝트 쿼터를 지원하고 활성화된 경우, 프로젝트 쿼터를 사용하여 파일시스템 사용보다는 [emptyDir 볼륨](/ko/docs/concepts/storage/volumes/#emptydir) 스토리지 사용을 모니터링하여 성능과 정확성을 향상시킨다. +- `MountContainers`: 호스트의 유틸리티 컨테이너를 볼륨 마운터로 사용할 수 있다. +- `MountPropagation`: 한 컨테이너에서 다른 컨테이너 또는 파드로 마운트된 볼륨을 공유할 수 있다. + 자세한 내용은 [마운트 전파(propagation)](/ko/docs/concepts/storage/volumes/#마운트-전파-propagation)을 참고한다. +- `NodeDisruptionExclusion`: 영역(zone) 장애 시 노드가 제외되지 않도록 노드 레이블 `node.kubernetes.io/exclude-disruption` 사용을 활성화한다. +- `NodeLease`: 새로운 리스(Lease) API가 노드 상태 신호로 사용될 수 있는 노드 하트비트(heartbeats)를 보고할 수 있게 한다. +- `NonPreemptingPriority`: 프라이어리티클래스(PriorityClass)와 파드에 NonPreempting 옵션을 활성화한다. +- `PersistentLocalVolumes`: 파드에서 `local` 볼륨 유형의 사용을 활성화한다. + `local` 볼륨을 요청하는 경우 파드 어피니티를 지정해야 한다. +- `PodDisruptionBudget`: [PodDisruptionBudget](/docs/tasks/run-application/configure-pdb/) 기능을 활성화한다. +- `PodOverhead`: 파드 오버헤드를 판단하기 위해 [파드오버헤드(PodOverhead)](/ko/docs/concepts/configuration/pod-overhead/) 기능을 활성화한다. +- `PodPriority`: [우선 순위](/ko/docs/concepts/configuration/pod-priority-preemption/)를 기반으로 파드의 스케줄링 취소와 선점을 활성화한다. +- `PodReadinessGates`: 파드 준비성 평가를 확장하기 위해 + `PodReadinessGate` 필드 설정을 활성화한다. 자세한 내용은 [파드의 준비성 게이트](/ko/docs/concepts/workloads/pods/pod-lifecycle/#pod-readiness-gate)를 + 참고한다. +- `PodShareProcessNamespace`: 파드에서 실행되는 컨테이너 간에 단일 프로세스 네임스페이스를 + 공유하기 위해 파드에서 `shareProcessNamespace` 설정을 활성화한다. 자세한 내용은 + [파드의 컨테이너 간 프로세스 네임스페이스 공유](/docs/tasks/configure-pod-container/share-process-namespace/)에서 확인할 수 있다. +- `ProcMountType`: 컨테이너의 ProcMountType 제어를 활성화한다. +- `PVCProtection`: 파드에서 사용 중일 때 퍼시스턴트볼륨클레임(PVC)이 + 삭제되지 않도록 한다. +- `QOSReserved`: QoS 수준에서 리소스 예약을 허용하여 낮은 QoS 수준의 파드가 더 높은 QoS 수준에서 + 요청된 리소스로 파열되는 것을 방지한다(현재 메모리만 해당). +- `ResourceLimitsPriorityFunction`: 입력 파드의 CPU 및 메모리 한도 중 + 하나 이상을 만족하는 노드에 가능한 최저 점수 1을 할당하는 + 스케줄러 우선 순위 기능을 활성화한다. 의도는 동일한 점수를 가진 + 노드 사이의 관계를 끊는 것이다. +- `ResourceQuotaScopeSelectors`: 리소스 쿼터 범위 셀렉터를 활성화한다. +- `RotateKubeletClientCertificate`: kubelet에서 클라이언트 TLS 인증서의 로테이션을 활성화한다. + 자세한 내용은 [kubelet 구성](/docs/reference/command-line-tools-reference/kubelet-tls-bootstrapping/#kubelet-configuration)을 참고한다. +- `RotateKubeletServerCertificate`: kubelet에서 서버 TLS 인증서의 로테이션을 활성화한다. + 자세한 내용은 [kubelet 구성](/docs/reference/command-line-tools-reference/kubelet-tls-bootstrapping/#kubelet-configuration)을 참고한다. +- `RunAsGroup`: 컨테이너의 init 프로세스에 설정된 기본 그룹 ID 제어를 활성화한다. +- `RuntimeClass`: 컨테이너 런타임 구성을 선택하기 위해 [런타임클래스(RuntimeClass)](/ko/docs/concepts/containers/runtime-class/) 기능을 활성화한다. +- `ScheduleDaemonSetPods`: 데몬셋(DaemonSet) 컨트롤러 대신 기본 스케줄러로 데몬셋 파드를 스케줄링할 수 있다. +- `SCTPSupport`: SCTP를 `Service`, `Endpoint`, `NetworkPolicy` 및 `Pod` 정의에서 `protocol` 값으로 사용하는 것을 활성화한다. +- `ServerSideApply`: API 서버에서 [SSA(Sever Side Apply)](/docs/reference/using-api/api-concepts/#server-side-apply) 경로를 활성화한다. +- `ServiceAccountIssuerDiscovery`: API 서버에서 서비스 어카운트 발행자에 대해 OIDC 디스커버리 엔드포인트(발급자 및 JWKS URL)를 활성화한다. 자세한 내용은 [파드의 서비스 어카운트 구성](/docs/tasks/configure-pod-container/configure-service-account/#service-account-issuer-discovery)을 참고한다. +- `ServiceAppProtocol`: 서비스와 엔드포인트에서 `AppProtocol` 필드를 활성화한다. +- `ServiceLoadBalancerFinalizer`: 서비스 로드 밸런서에 대한 Finalizer 보호를 활성화한다. +- `ServiceNodeExclusion`: 클라우드 제공자가 생성한 로드 밸런서에서 노드를 제외할 수 있다. + "`alpha.service-controller.kubernetes.io/exclude-balancer`" 키 또는 `node.kubernetes.io/exclude-from-external-load-balancers` 로 레이블이 지정된 경우 노드를 제외할 수 있다. +- `ServiceTopology`: 서비스가 클러스터의 노드 토폴로지를 기반으로 트래픽을 라우팅할 수 있도록 한다. 자세한 내용은 [서비스토폴로지(ServiceTopology)](/ko/docs/concepts/services-networking/service-topology/)를 참고한다. +- `StartupProbe`: kubelet에서 [스타트업](/ko/docs/concepts/workloads/pods/pod-lifecycle/#언제-스타트업-프로브를-사용해야-하는가) 프로브를 활성화한다. +- `StorageObjectInUseProtection`: 퍼시스턴트볼륨 또는 퍼시스턴트볼륨클레임 오브젝트가 여전히 + 사용 중인 경우 삭제를 연기한다. +- `StorageVersionHash`: API 서버가 디스커버리에서 스토리지 버전 해시를 노출하도록 허용한다. +- `StreamingProxyRedirects`: 스트리밍 요청을 위해 백엔드(kubelet)에서 리디렉션을 + 가로채서 따르도록 API 서버에 지시한다. + 스트리밍 요청의 예로는 `exec`, `attach` 및 `port-forward` 요청이 있다. +- `SupportIPVSProxyMode`: IPVS를 사용하여 클러스터 내 서비스 로드 밸런싱을 제공한다. + 자세한 내용은 [서비스 프록시](/ko/docs/concepts/services-networking/service/#가상-ip와-서비스-프록시)를 참고한다. +- `SupportPodPidsLimit`: 파드의 PID 제한을 지원한다. +- `Sysctls`: 각 파드에 설정할 수 있는 네임스페이스 커널 파라미터(sysctl)를 지원한다. + 자세한 내용은 [sysctl](/docs/tasks/administer-cluster/sysctl-cluster/)을 참고한다. +- `TaintBasedEvictions`: 노드의 테인트(taint) 및 파드의 톨러레이션(toleration)을 기반으로 노드에서 파드를 축출할 수 있다. + 자세한 내용은 [테인트와 톨러레이션](/ko/docs/concepts/scheduling-eviction/taint-and-toleration/)을 참고한다. +- `TaintNodesByCondition`: [노드 컨디션](/ko/docs/concepts/architecture/nodes/#condition)을 기반으로 자동 테인트 노드를 활성화한다. +- `TokenRequest`: 서비스 어카운트 리소스에서 `TokenRequest` 엔드포인트를 활성화한다. +- `TokenRequestProjection`: [`projected` 볼륨](/ko/docs/concepts/storage/volumes/#projected)을 통해 서비스 어카운트 + 토큰을 파드에 주입할 수 있다. +- `TopologyManager`: 쿠버네티스의 다른 컴포넌트에 대한 세분화된 하드웨어 리소스 할당을 조정하는 메커니즘을 활성화한다. [노드의 토폴로지 관리 정책 제어](/docs/tasks/administer-cluster/topology-manager/)를 참고한다. +- `TTLAfterFinished`: [TTL 컨트롤러](/ko/docs/concepts/workloads/controllers/ttlafterfinished/)가 실행이 끝난 후 리소스를 정리하도록 허용한다. +- `VolumePVCDataSource`: 기존 PVC를 데이터 소스로 지정하는 기능을 지원한다. +- `VolumeScheduling`: 볼륨 토폴로지 인식 스케줄링을 활성화하고 + 퍼시스턴트볼륨클레임(PVC) 바인딩이 스케줄링 결정을 인식하도록 한다. 또한 + `PersistentLocalVolumes` 기능 게이트와 함께 사용될 때 + [`local`](/ko/docs/concepts/storage/volumes/#local) 볼륨 유형을 사용할 수 있다. +- `VolumeSnapshotDataSource`: 볼륨 스냅샷 데이터 소스 지원을 활성화한다. +- `VolumeSubpathEnvExpansion`: 환경 변수를 `subPath`로 확장하기 위해 `subPathExpr` 필드를 활성화한다. +- `WatchBookmark`: 감시자 북마크(watch bookmark) 이벤트 지원을 활성화한다. +- `WindowsGMSA`: 파드에서 컨테이너 런타임으로 GMSA 자격 증명 스펙을 전달할 수 있다. +- `WindowsRunAsUserName` : 기본 사용자가 아닌(non-default) 사용자로 윈도우 컨테이너에서 애플리케이션을 실행할 수 있도록 지원한다. + 자세한 내용은 [RunAsUserName 구성](/docs/tasks/configure-pod-container/configure-runasusername)을 참고한다. +- `WinDSR`: kube-proxy가 윈도우용 DSR 로드 밸런서를 생성할 수 있다. +- `WinOverlay`: kube-proxy가 윈도우용 오버레이 모드에서 실행될 수 있도록 한다. + + +## {{% heading "whatsnext" %}} + +* [사용 중단 정책](/docs/reference/using-api/deprecation-policy/)은 쿠버네티스에 대한 + 기능과 컴포넌트를 제거하는 프로젝트의 접근 방법을 설명한다. diff --git a/content/ko/docs/reference/glossary/aggregation-layer.md b/content/ko/docs/reference/glossary/aggregation-layer.md index 404257f20b..b09902c287 100644 --- a/content/ko/docs/reference/glossary/aggregation-layer.md +++ b/content/ko/docs/reference/glossary/aggregation-layer.md @@ -16,4 +16,4 @@ tags: <!--more--> -{{< glossary_tooltip text="쿠버네티스 API 서버" term_id="kube-apiserver" >}}에서 [추가 API 지원](/docs/tasks/access-kubernetes-api/configure-aggregation-layer/)을 구성하였으면, 쿠버네티스 API의 URL 경로를 "요구하는" `APIService` 오브젝트 추가할 수 있다. +{{< glossary_tooltip text="쿠버네티스 API 서버" term_id="kube-apiserver" >}}에서 [추가 API 지원](/docs/tasks/extend-kubernetes/configure-aggregation-layer/)을 구성하였으면, 쿠버네티스 API의 URL 경로를 "요구하는" `APIService` 오브젝트 추가할 수 있다. diff --git a/content/ko/docs/reference/glossary/cni.md b/content/ko/docs/reference/glossary/cni.md index a88ac5277a..28fc3602f3 100644 --- a/content/ko/docs/reference/glossary/cni.md +++ b/content/ko/docs/reference/glossary/cni.md @@ -2,17 +2,17 @@ title: 컨테이너 네트워크 인터페이스(Container network interface, CNI) id: cni date: 2018-05-25 -full_link: /docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/#cni +full_link: /ko/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/#cni short_description: > 컨테이너 네트워크 인터페이스(CNI) 플러그인은 appc/CNI 스팩을 따르는 네트워크 플러그인의 일종이다. -aka: +aka: tags: -- networking +- networking --- 컨테이너 네트워크 인터페이스(CNI) 플러그인은 appc/CNI 스팩을 따르는 네트워크 플러그인의 일종이다. -<!--more--> +<!--more--> -* 쿠버네티스와 CNI에 대한 정보는 [여기](/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/#cni)를 참고한다. -* 쿠버네티스와 CNI에 대한 정보는 ["네트워크 플러그인"](/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/#cni)에서 볼 수 있다. +* 쿠버네티스와 CNI에 대한 정보는 [여기](/ko/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/#cni)를 참고한다. +* 쿠버네티스와 CNI에 대한 정보는 ["네트워크 플러그인"](/ko/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/#cni)에서 볼 수 있다. diff --git a/content/ko/docs/reference/glossary/container-env-variables.md b/content/ko/docs/reference/glossary/container-env-variables.md index 7df679f358..ab538071a5 100755 --- a/content/ko/docs/reference/glossary/container-env-variables.md +++ b/content/ko/docs/reference/glossary/container-env-variables.md @@ -2,7 +2,7 @@ title: 컨테이너 환경 변수(Container Environment Variables) id: container-env-variables date: 2018-04-12 -full_link: /ko/docs/concepts/containers/container-environment-variables/ +full_link: /ko/docs/concepts/containers/container-environment/ short_description: > 컨테이너 환경 변수는 파드에서 동작 중인 컨테이너에 유용한 정보를 제공하기 위한 이름=값 쌍이다. diff --git a/content/ko/docs/reference/glossary/cronjob.md b/content/ko/docs/reference/glossary/cronjob.md index b0f8342b66..453bb6b652 100755 --- a/content/ko/docs/reference/glossary/cronjob.md +++ b/content/ko/docs/reference/glossary/cronjob.md @@ -11,9 +11,9 @@ tags: - core-object - workload --- - 주기적인 일정에 따라 실행되는 [잡](/ko/docs/concepts/workloads/controllers/jobs-run-to-completion/)을 관리. + 주기적인 일정에 따라 실행되는 [잡](/ko/docs/concepts/workloads/controllers/job/)을 관리. <!--more--> -*crontab* 파일의 라인과 유사하게, 크론잡 오브젝트는 [크론](https://en.wikipedia.org/wiki/Cron) 형식을 사용하여 일정을 지정한다. +*crontab* 파일의 라인과 유사하게, 크론잡 오브젝트는 [크론](https://ko.wikipedia.org/wiki/Cron) 형식을 사용하여 일정을 지정한다. diff --git a/content/ko/docs/reference/glossary/customresourcedefinition.md b/content/ko/docs/reference/glossary/customresourcedefinition.md index 3e680ca2bd..97ef81c1c8 100755 --- a/content/ko/docs/reference/glossary/customresourcedefinition.md +++ b/content/ko/docs/reference/glossary/customresourcedefinition.md @@ -2,7 +2,7 @@ title: 커스텀 리소스 데피니션(CustomResourceDefinition) id: CustomResourceDefinition date: 2018-04-12 -full_link: /docs/tasks/access-kubernetes-api/extend-api-custom-resource-definitions/ +full_link: /docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/ short_description: > 사용자 정의 서버를 완전히 새로 구축할 필요가 없도록 쿠버네티스 API 서버에 추가할 리소스를 정의하는 사용자 정의 코드. diff --git a/content/ko/docs/reference/glossary/device-plugin.md b/content/ko/docs/reference/glossary/device-plugin.md index 85fe177e6b..4d7ec8debe 100644 --- a/content/ko/docs/reference/glossary/device-plugin.md +++ b/content/ko/docs/reference/glossary/device-plugin.md @@ -24,6 +24,6 @@ tags: 장치 플러그인을 {{< glossary_tooltip term_id="daemonset" >}}으로 배포하거나, 각 대상 노드에 직접 장치 플러그인 소프트웨어를 설치할 수 있다. -[장치 플러그인](/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins/) +[장치 플러그인](/ko/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins/) 의 더 자세한 정보를 본다 diff --git a/content/ko/docs/reference/glossary/docker.md b/content/ko/docs/reference/glossary/docker.md index 64d264479d..4e0d7a305d 100755 --- a/content/ko/docs/reference/glossary/docker.md +++ b/content/ko/docs/reference/glossary/docker.md @@ -14,5 +14,5 @@ tags: <!--more--> -Docker는 Linux 커널의 리소스 격리 기능을 사용하며, 그 격리 기능의 예는 cgroups, 커널 네임스페이스, OverlayFS와 같은 조합 가능한 파일 시스템, 컨테이너가 단일 Linux 인스턴스에서 독립적으로 실행되게 하여 가상 머신(VM)을 시작하고 관리하는 오버헤드를 피할 수 있도록 하는 기타 기능 등이 있다. +Docker는 리눅스 커널의 리소스 격리 기능을 사용하며, 그 격리 기능의 예는 cgroups, 커널 네임스페이스, OverlayFS와 같은 조합 가능한 파일 시스템, 컨테이너가 단일 리눅스 인스턴스에서 독립적으로 실행되게 하여 가상 머신(VM)을 시작하고 관리하는 오버헤드를 피할 수 있도록 하는 기타 기능 등이 있다. diff --git a/content/ko/docs/reference/glossary/image.md b/content/ko/docs/reference/glossary/image.md index d7583343b8..adfe414d57 100755 --- a/content/ko/docs/reference/glossary/image.md +++ b/content/ko/docs/reference/glossary/image.md @@ -10,7 +10,7 @@ aka: tags: - fundamental --- - {{< glossary_tooltip term_id="container" >}}의 저장된 인스턴스이며, 애플리케이션 구동에 필요한 소프트웨어 집합을 가지고 있다. + {{< glossary_tooltip text="컨테이너" term_id="container" >}}의 저장된 인스턴스이며, 애플리케이션 구동에 필요한 소프트웨어 집합을 가지고 있다. <!--more--> diff --git a/content/ko/docs/reference/glossary/job.md b/content/ko/docs/reference/glossary/job.md index a2c5a83466..8f227f76ac 100755 --- a/content/ko/docs/reference/glossary/job.md +++ b/content/ko/docs/reference/glossary/job.md @@ -2,7 +2,7 @@ title: 잡(Job) id: job date: 2018-04-12 -full_link: /docs/concepts/workloads/controllers/jobs-run-to-completion +full_link: /docs/concepts/workloads/controllers/job short_description: > 완료를 목표로 실행되는 유한 또는 배치 작업. diff --git a/content/ko/docs/reference/glossary/minikube.md b/content/ko/docs/reference/glossary/minikube.md index 57267cddd4..f43966260e 100755 --- a/content/ko/docs/reference/glossary/minikube.md +++ b/content/ko/docs/reference/glossary/minikube.md @@ -17,5 +17,4 @@ tags: Minikube는 VM이나 사용자 컴퓨터에서 단일 노드 클러스터를 실행한다. Minikube를 사용하여 -[학습 환경에서 쿠버네티스 시도하기](/docs/setup/learning-environment/)를 할 수 있다. - +[학습 환경에서 쿠버네티스 시도하기](/ko/docs/setup/learning-environment/)를 할 수 있다. diff --git a/content/ko/docs/reference/glossary/statefulset.md b/content/ko/docs/reference/glossary/statefulset.md index afb2dd3ba9..54fc5d0526 100755 --- a/content/ko/docs/reference/glossary/statefulset.md +++ b/content/ko/docs/reference/glossary/statefulset.md @@ -1,12 +1,12 @@ --- -title: 스테이트풀 셋(StatefulSet) +title: 스테이트풀셋(StatefulSet) id: statefulset date: 2018-04-12 full_link: /ko/docs/concepts/workloads/controllers/statefulset/ short_description: > 내구성이 있는 스토리지와 파드별로 지속성 식별자를 사용해서 파드 집합의 디플로이먼트와 스케일링을 관리한다. -aka: +aka: tags: - fundamental - core-object @@ -15,7 +15,7 @@ tags: --- {{< glossary_tooltip text="파드" term_id="pod" >}} 집합의 디플로이먼트와 스케일링을 관리하며, 파드들의 *순서 및 고유성을 보장한다* . -<!--more--> +<!--more--> {{< glossary_tooltip text="디플로이먼트" term_id="deployment" >}}와 유사하게, 스테이트풀셋은 동일한 컨테이너 스펙을 기반으로 둔 파드들을 관리한다. 디플로이먼트와는 다르게, 스테이트풀셋은 각 파드의 독자성을 유지한다. 이 파드들은 동일한 스팩으로 생성되었지만, 서로 교체는 불가능하다. 다시 말해, 각각은 재스케줄링 간에도 지속적으로 유지되는 식별자를 가진다. diff --git a/content/ko/docs/reference/glossary/volume.md b/content/ko/docs/reference/glossary/volume.md index 24e37a3165..6aa9985eb0 100755 --- a/content/ko/docs/reference/glossary/volume.md +++ b/content/ko/docs/reference/glossary/volume.md @@ -4,18 +4,17 @@ id: volume date: 2018-04-12 full_link: /ko/docs/concepts/storage/volumes/ short_description: > - 데이터를 포함하고 있는 디렉토리이며, 파드의 컨테이너에서 접근 가능하다. + 데이터를 포함하고 있는 디렉터리이며, 파드의 컨테이너에서 접근 가능하다. -aka: +aka: tags: - core-object - fundamental --- - 데이터를 포함하고 있는 디렉토리이며, {{< glossary_tooltip term_id="pod" >}}의 {{< glossary_tooltip text="컨테이너" term_id="container" >}}에서 접근 가능하다. + 데이터를 포함하고 있는 디렉터리이며, {{< glossary_tooltip text="파드" term_id="pod" >}}의 {{< glossary_tooltip text="컨테이너" term_id="container" >}}에서 접근 가능하다. -<!--more--> +<!--more--> 쿠버네티스 볼륨은 그것을 포함하고 있는 파드만큼 오래 산다. 결과적으로, 볼륨은 파드 안에서 실행되는 모든 컨테이너 보다 오래 지속되며, 데이터는 컨테이너의 재시작 간에도 보존된다. -더 많은 정보는 [스토리지](https://kubernetes.io/ko/docs/concepts/storage/)를 본다. - +더 많은 정보는 [스토리지](/ko/docs/concepts/storage/)를 본다. diff --git a/content/ko/docs/reference/issues-security/security.md b/content/ko/docs/reference/issues-security/security.md index 986af01cf1..6db604665e 100644 --- a/content/ko/docs/reference/issues-security/security.md +++ b/content/ko/docs/reference/issues-security/security.md @@ -13,7 +13,7 @@ weight: 20 보안 및 주요 API 공지에 대한 이메일을 위해 [kubernetes-security-announce](https://groups.google.com/forum/#!forum/kubernetes-security-announce)) 그룹에 가입하세요. -[이 링크](https://groups.google.com/forum/feed/kubernetes-announce/msgs/rss_v2_0.xml?num=50)를 사용하여 RSS 피드를 구독할 수 있다. +[이 링크](https://groups.google.com/forum/feed/kubernetes-security-announce/msgs/rss_v2_0.xml?num=50)를 사용하여 RSS 피드를 구독할 수 있다. ## 취약점 보고 diff --git a/content/ko/docs/reference/kubectl/cheatsheet.md b/content/ko/docs/reference/kubectl/cheatsheet.md index bcf654b0bd..3446c11a06 100644 --- a/content/ko/docs/reference/kubectl/cheatsheet.md +++ b/content/ko/docs/reference/kubectl/cheatsheet.md @@ -162,6 +162,10 @@ kubectl get pv --sort-by=.spec.capacity.storage kubectl get pods --selector=app=cassandra -o \ jsonpath='{.items[*].metadata.labels.version}' +# 예를 들어 'ca.crt'와 같이 점이 있는 키값을 검색한다 +kubectl get configmap myconfig \ + -o jsonpath='{.data.ca\.crt}' + # 모든 워커 노드 조회 (셀렉터를 사용하여 'node-role.kubernetes.io/master' # 으로 명명된 라벨의 결과를 제외) kubectl get node --selector='!node-role.kubernetes.io/master' @@ -255,7 +259,7 @@ KUBE_EDITOR="nano" kubectl edit svc/docker-registry # 다른 편집기 사용 ## 리소스 스케일링 ```bash -kubectl scale --replicas=3 rs/foo # 'foo'라는 레플리카 셋을 3으로 스케일 +kubectl scale --replicas=3 rs/foo # 'foo'라는 레플리카셋을 3으로 스케일 kubectl scale --replicas=3 -f foo.yaml # "foo.yaml"에 지정된 리소스의 크기를 3으로 스케일 kubectl scale --current-replicas=2 --replicas=3 deployment/mysql # mysql이라는 디플로이먼트의 현재 크기가 2인 경우, mysql을 3으로 스케일 kubectl scale --replicas=5 rc/foo rc/bar rc/baz # 여러 개의 레플리케이션 컨트롤러 스케일 @@ -286,6 +290,11 @@ kubectl logs -f my-pod # 실시간 스트림 파드 kubectl logs -f my-pod -c my-container # 실시간 스트림 파드 로그(stdout, 멀티-컨테이너 경우) kubectl logs -f -l name=myLabel --all-containers # name이 myLabel인 모든 파드의 로그 스트리밍 (stdout) kubectl run -i --tty busybox --image=busybox -- sh # 대화형 셸로 파드를 실행 +kubectl run nginx --image=nginx -n +mynamespace # 특정 네임스페이스에서 nginx 파드 실행 +kubectl run nginx --image=nginx # nginx 파드를 실행하고 해당 스펙을 pod.yaml 파일에 기록 +--dry-run=client -o yaml > pod.yaml + kubectl attach my-pod -i # 실행중인 컨테이너에 연결 kubectl port-forward my-pod 5000:6000 # 로컬 머신의 5000번 포트를 리스닝하고, my-pod의 6000번 포트로 전달 kubectl exec my-pod -- ls / # 기존 파드에서 명령 실행(한 개 컨테이너 경우) @@ -310,7 +319,7 @@ kubectl taint nodes foo dedicated=special-user:NoSchedule ### 리소스 타입 -단축명, [API 그룹](/ko/docs/concepts/overview/kubernetes-api/#api-groups)과 함께 지원되는 모든 리소스 유형들, 그것들의 [네임스페이스](/ko/docs/concepts/overview/working-with-objects/namespaces)와 [종류(Kind)](/ko/docs/concepts/overview/working-with-objects/kubernetes-objects)를 나열: +단축명, [API 그룹](/ko/docs/concepts/overview/kubernetes-api/#api-그룹)과 함께 지원되는 모든 리소스 유형들, 그것들의 [네임스페이스](/ko/docs/concepts/overview/working-with-objects/namespaces)와 [종류(Kind)](/ko/docs/concepts/overview/working-with-objects/kubernetes-objects)를 나열: ```bash kubectl api-resources @@ -385,5 +394,3 @@ Kubectl 로그 상세 레벨(verbosity)은 `-v` 또는`--v` 플래그와 로그 * 재사용 스크립트에서 kubectl 사용 방법을 이해하기 위해 [kubectl 사용법](/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 d70eb8939a..6eab3cbafe 100644 --- a/content/ko/docs/reference/kubectl/overview.md +++ b/content/ko/docs/reference/kubectl/overview.md @@ -1,20 +1,19 @@ --- title: kubectl 개요 -content_template: templates/concept +content_type: concept weight: 20 card: name: reference weight: 20 --- -{{% capture overview %}} -Kubectl은 쿠버네티스 클러스터를 제어하기 위한 커맨드 라인 도구이다. `kubectl` 은 config 파일을 $HOME/.kube 에서 찾는다. KUBECONFIG 환경 변수를 설정하거나 [`--kubeconfig`](/ko/docs/concepts/configuration/organize-cluster-access-kubeconfig/) 플래그를 설정하여 다른 [kubeconfig](/ko/docs/concepts/configuration/organize-cluster-access-kubeconfig/) 파일을 지정할 수 있다. +<!-- overview --> +Kubectl은 쿠버네티스 클러스터를 제어하기 위한 커맨드 라인 도구이다. 구성을 위해, `kubectl` 은 config 파일을 $HOME/.kube 에서 찾는다. KUBECONFIG 환경 변수를 설정하거나 [`--kubeconfig`](/ko/docs/concepts/configuration/organize-cluster-access-kubeconfig/) 플래그를 설정하여 다른 [kubeconfig](/ko/docs/concepts/configuration/organize-cluster-access-kubeconfig/) 파일을 지정할 수 있다. 이 개요는 `kubectl` 구문을 다루고, 커맨드 동작을 설명하며, 일반적인 예제를 제공한다. 지원되는 모든 플래그 및 하위 명령을 포함한 각 명령에 대한 자세한 내용은 [kubectl](/docs/reference/generated/kubectl/kubectl-commands/) 참조 문서를 참고한다. 설치 방법에 대해서는 [kubectl 설치](/ko/docs/tasks/tools/install-kubectl/)를 참고한다. -{{% /capture %}} -{{% capture body %}} +<!-- body --> ## 구문 @@ -30,11 +29,11 @@ kubectl [command] [TYPE] [NAME] [flags] * `TYPE`: [리소스 타입](#리소스-타입)을 지정한다. 리소스 타입은 대소문자를 구분하지 않으며 단수형, 복수형 또는 약어 형식을 지정할 수 있다. 예를 들어, 다음의 명령은 동일한 출력 결과를 생성한다. - ```shell - kubectl get pod pod1 - kubectl get pods pod1 - kubectl get po pod1 - ``` + ```shell + kubectl get pod pod1 + kubectl get pods pod1 + kubectl get po pod1 + ``` * `NAME`: 리소스 이름을 지정한다. 이름은 대소문자를 구분한다. 이름을 생략하면, 모든 리소스에 대한 세부 사항이 표시된다. 예: `kubectl get pods` @@ -111,13 +110,13 @@ kubectl [command] [TYPE] [NAME] [flags] `version` | `kubectl version [--client] [flags]` | 클라이언트와 서버에서 실행 중인 쿠버네티스 버전을 표시한다. `wait` | <code>kubectl wait ([-f FILENAME] | resource.group/resource.name | resource.group [(-l label | --all)]) [--for=delete|--for condition=available] [options]</code> | 실험(experimental) 기능: 하나 이상의 리소스에서 특정 조건을 기다린다. -기억하기: 명령 동작에 대한 자세한 내용은 [kubectl](/docs/user-guide/kubectl/) 참조 문서를 참고한다. +명령 동작에 대한 자세한 내용을 배우려면 [kubectl](/docs/reference/kubectl/kubectl/) 참조 문서를 참고한다. ## 리소스 타입 다음 표에는 지원되는 모든 리소스 타입과 해당 약어가 나열되어 있다. -(이 출력은 `kubectl api-resources` 에서 확인할 수 있으며, 쿠버네티스 1.13.3 부터 일치한다.) +(이 출력은 `kubectl api-resources` 에서 확인할 수 있으며, 쿠버네티스 1.13.3 부터 일치했다.) | 리소스 이름 | 짧은 이름 | API 그룹 | 네임스페이스 | 리소스 종류 | |---|---|---|---|---| @@ -173,7 +172,7 @@ kubectl [command] [TYPE] [NAME] [flags] ## 출력 옵션 -특정 명령의 출력을 서식화하거나 정렬하는 방법에 대한 정보는 다음 섹션을 참고한다. 다양한 출력 옵션을 지원하는 명령에 대한 자세한 내용은 [kubectl](/docs/user-guide/kubectl/) 참조 문서를 참고한다. +특정 명령의 출력을 서식화하거나 정렬하는 방법에 대한 정보는 다음 섹션을 참고한다. 다양한 출력 옵션을 지원하는 명령에 대한 자세한 내용은 [kubectl](/docs/reference/kubectl/kubectl/) 참조 문서를 참고한다. ### 출력 서식화 @@ -232,9 +231,9 @@ kubectl get pods <pod-name> -o custom-columns-file=template.txt NAME RSRC metadata.name metadata.resourceVersion ``` -두 명령 중 하나를 실행한 결과는 다음과 같다. +두 명령 중 하나를 실행한 결과는 다음과 비슷하다. -```shell +``` NAME RSRC submit-queue 610995 ``` @@ -245,7 +244,7 @@ submit-queue 610995 이는 클라이언트가 출력할 수 있도록, 주어진 리소스에 대해 서버가 해당 리소스와 관련된 열과 행을 반환한다는 것을 의미한다. 이는 서버가 출력의 세부 사항을 캡슐화하도록 하여, 동일한 클러스터에 대해 사용된 클라이언트에서 사람이 읽을 수 있는 일관된 출력을 허용한다. -이 기능은 기본적으로 `kubectl` 1.11 이상에서 활성화되어 있다. 사용하지 않으려면, +이 기능은 기본적으로 활성화되어 있다. 사용하지 않으려면, `kubectl get` 명령에 `--server-print=false` 플래그를 추가한다. ##### 예제 @@ -256,9 +255,9 @@ submit-queue 610995 kubectl get pods <pod-name> --server-print=false ``` -출력 결과는 다음과 같다. +출력 결과는 다음과 비슷하다. -```shell +``` NAME AGE pod-name 1m ``` @@ -403,16 +402,20 @@ cat service.yaml | kubectl diff -f - # 어떤 언어로든 간단한 플러그인을 만들고 "kubectl-" 접두사로 # 시작하도록 실행 파일의 이름을 지정한다. cat ./kubectl-hello -#!/bin/bash +``` +```shell +#!/bin/sh # 이 플러그인은 "hello world"라는 단어를 출력한다 echo "hello world" - -# 작성한 플러그인을 실행 가능하게 한다 -sudo chmod +x ./kubectl-hello +``` +작성한 플러그인을 실행 가능하게 한다 +```bash +chmod a+x ./kubectl-hello # 그리고 PATH의 위치로 옮긴다 sudo mv ./kubectl-hello /usr/local/bin +sudo chown root:root /usr/local/bin # 이제 kubectl 플러그인을 만들고 "설치했다". # kubectl에서 플러그인을 일반 명령처럼 호출하여 플러그인을 사용할 수 있다 @@ -423,16 +426,18 @@ hello world ``` ```shell -# PATH에서 플러그인 파일을 간단히 삭제하여, 플러그인을 "제거"할 수 있다 +# 플러그인을 배치한 $PATH의 폴더에서 플러그인을 삭제하여, +# 플러그인을 "제거"할 수 있다 sudo rm /usr/local/bin/kubectl-hello ``` `kubectl` 에 사용할 수 있는 모든 플러그인을 보려면, -`kubectl plugin list` 하위 명령을 사용할 수 있다. +`kubectl plugin list` 하위 명령을 사용한다. ```shell kubectl plugin list ``` +출력 결과는 다음과 비슷하다. ``` The following kubectl-compatible plugins are available: @@ -440,11 +445,11 @@ The following kubectl-compatible plugins are available: /usr/local/bin/kubectl-foo /usr/local/bin/kubectl-bar ``` + +`kubectl plugin list` 는 또한 실행 가능하지 않거나, +다른 플러그인에 의해 차단된 플러그인에 대해 경고한다. 예를 들면 다음과 같다. ```shell -# 또한, 이 명령은 예를 들어 실행 불가능한 파일이거나, -# 다른 플러그인에 의해 가려진 플러그인에 대해 -# 경고할 수 있다 -sudo chmod -x /usr/local/bin/kubectl-foo +sudo chmod -x /usr/local/bin/kubectl-foo # 실행 권한 제거 kubectl plugin list ``` ``` @@ -463,6 +468,10 @@ error: one plugin warning was found ```shell cat ./kubectl-whoami +``` +다음 몇 가지 예는 이미 `kubectl-whoami` 에 +다음 내용이 있다고 가정한다. +```shell #!/bin/bash # 이 플러그인은 현재 선택된 컨텍스트를 기반으로 현재 사용자에 대한 @@ -470,7 +479,7 @@ cat ./kubectl-whoami kubectl config view --template='{{ range .contexts }}{{ if eq .name "'$(kubectl config current-context)'" }}Current user: {{ printf "%s\n" .context.user }}{{ end }}{{ end }}' ``` -위의 플러그인을 실행하면 KUBECONFIG 파일에서 현재 선택된 컨텍스트에 대한 +위의 플러그인을 실행하면 KUBECONFIG 파일에서 현재의 컨텍스트에 대한 사용자가 포함된 출력이 제공된다. ```shell @@ -484,12 +493,10 @@ kubectl whoami Current user: plugins-user ``` -플러그인에 대한 자세한 내용은 [cli plugin 예제](https://github.com/kubernetes/sample-cli-plugin)를 참고한다. -{{% /capture %}} -{{% capture whatsnext %}} +## {{% heading "whatsnext" %}} -[kubectl](/docs/reference/generated/kubectl/kubectl-commands/) 명령을 사용하여 시작한다. +* [kubectl](/docs/reference/generated/kubectl/kubectl-commands/) 명령을 사용하여 시작한다. -{{% /capture %}} +* 플러그인에 대한 자세한 내용은 [cli plugin 예제](https://github.com/kubernetes/sample-cli-plugin)를 참고한다. diff --git a/content/ko/docs/reference/setup-tools/_index.md b/content/ko/docs/reference/setup-tools/_index.md new file mode 100644 index 0000000000..268a280c50 --- /dev/null +++ b/content/ko/docs/reference/setup-tools/_index.md @@ -0,0 +1,6 @@ +--- +title: 설치 도구 레퍼런스 +weight: 50 +toc-hide: true +--- + diff --git a/content/ko/docs/reference/setup-tools/kubeadm/_index.md b/content/ko/docs/reference/setup-tools/kubeadm/_index.md new file mode 100644 index 0000000000..085b1e1ef9 --- /dev/null +++ b/content/ko/docs/reference/setup-tools/kubeadm/_index.md @@ -0,0 +1,6 @@ +--- +title: "Kubeadm" +weight: 10 +toc-hide: true +--- + diff --git a/content/ko/docs/reference/setup-tools/kubeadm/kubeadm.md b/content/ko/docs/reference/setup-tools/kubeadm/kubeadm.md new file mode 100644 index 0000000000..f011459dd6 --- /dev/null +++ b/content/ko/docs/reference/setup-tools/kubeadm/kubeadm.md @@ -0,0 +1,28 @@ +--- +title: kubeadm 개요 +weight: 10 +card: + name: reference + weight: 40 +--- +<img src="https://raw.githubusercontent.com/kubernetes/kubeadm/master/logos/stacked/color/kubeadm-stacked-color.png" align="right" width="150px">Kubeadm은 쿠버네티스 클러스터를 "빠른 경로"로 생성하기 위한 모범 사례인 `kubeadm init`과 `kubeadm join`을 제공하기 위해 구성된 도구이다. + +kubeadm은 최소 기능 클러스터(minimum viable cluster)를 시작하고 실행하는 데 필요한 작업을 수행한다. 설계상, 부트스트랩만 다루며, 머신을 프로비저닝하지는 않는다. 마찬가지로, 쿠버네티스 대시보드, 모니터링 솔루션 및 클라우드 별 애드온과 같은 다양한 기능을 갖춘 애드온을 설치하는 것은 범위에 포함되지 않는다. + +대신, kubeadm 위에 있는 더 높은 수준의 맞춤형 도구가 구축될 것으로 예상되며, 모든 배포의 기초로서 kubeadm을 사용하면 적합한 클러스터를 보다 쉽게 만들 수 있다. + +## 설치하는 방법 + +kubeadm을 설치하려면 [설치 가이드](/docs/setup/production-environment/tools/kubeadm/install-kubeadm)를 참조한다. + +## 다음 내용 + +* [kubeadm init](/docs/reference/setup-tools/kubeadm/kubeadm-init): 쿠버네티스 컨트롤 플레인 노드를 부트스트랩 함 +* [kubeadm join](/docs/reference/setup-tools/kubeadm/kubeadm-join): 쿠버네티스 워커 노드를 부트스트랩 후 클러스터에 결합시킴 +* [kubeadm upgrade](/docs/reference/setup-tools/kubeadm/kubeadm-upgrade): 쿠버네티스 클러스터를 최신 버전으로 업그레이드 +* [kubeadm config](/docs/reference/setup-tools/kubeadm/kubeadm-config): kubeadm v1.7.x이하의 버전을 사용하여 클러스터를 초기화한 경우, 클러스터를 설정하여 `kubeadm upgrade`하기 위해 사용 +* [kubeadm token](/docs/reference/setup-tools/kubeadm/kubeadm-token): `kubeadm join`을 위한 토큰 관리 +* [kubeadm reset](/docs/reference/setup-tools/kubeadm/kubeadm-reset): `kubeadm init`나 `kubeadm join`를 의한 호스트에 대해서 변경된 사항을 되돌림 +* [kubeadm version](/docs/reference/setup-tools/kubeadm/kubeadm-version): kubeadm 버전을 출력 +* [kubeadm alpha](/docs/reference/setup-tools/kubeadm/kubeadm-alpha): 커뮤니티의 피드백 수집을 위해서 기능 미리 보기를 제공 + diff --git a/content/ko/docs/reference/tools.md b/content/ko/docs/reference/tools.md index f9a9836bdc..ceac0a5101 100644 --- a/content/ko/docs/reference/tools.md +++ b/content/ko/docs/reference/tools.md @@ -12,7 +12,7 @@ content_type: concept <!-- body --> ## Kubectl -[`kubectl`](/docs/tasks/tools/install-kubectl/)은 쿠버네티스를 위한 커맨드라인 툴이며, 쿠버네티스 클러스터 매니저을 제어한다. +[`kubectl`](/ko/docs/tasks/tools/install-kubectl/)은 쿠버네티스를 위한 커맨드라인 툴이며, 쿠버네티스 클러스터 매니저을 제어한다. ## Kubeadm @@ -20,7 +20,7 @@ content_type: concept ## Minikube -[`minikube`](/ko/docs/tasks/tools/install-minikube/)는 개발과 테스팅 목적으로 하는 +[`minikube`](/ko/docs/tasks/tools/install-minikube/)는 개발과 테스팅 목적으로 하는 단일 노드 쿠버네티스 클러스터를 로컬 워크스테이션에서 쉽게 구동시키는 도구이다. @@ -51,4 +51,3 @@ Kompose의 용도 * 도커 컴포즈 파일을 쿠버네티스 오브젝트로 변환 * 로컬 도커 개발 환경에서 나의 애플리케이션을 쿠버네티스를 통해 관리하도록 이전 * V1 또는 V2 도커 컴포즈 `yaml` 파일 또는 [분산 애플리케이션 번들](https://docs.docker.com/compose/bundles/)을 변환 - diff --git a/content/ko/docs/reference/using-api/api-overview.md b/content/ko/docs/reference/using-api/api-overview.md index e7a0b8ce8d..d961283b99 100644 --- a/content/ko/docs/reference/using-api/api-overview.md +++ b/content/ko/docs/reference/using-api/api-overview.md @@ -78,12 +78,12 @@ API 버전의 차이는 수준의 안정성과 지원의 차이를 나타낸다. * *핵심* (또는 *레거시*라고 불리는) 그룹은 `apiVersion: v1`와 같이 `apiVersion` 필드에 명시되지 않고 REST 경로 `/api/v1`에 있다. * 이름이 있는 그룹은 REST 경로 `/apis/$GROUP_NAME/$VERSION`에 있으며 `apiVersion: $GROUP_NAME/$VERSION`을 사용한다 - (예를 들어 `apiVersion: batch/v1`). 지원되는 API 그룹 전체의 목록은 [쿠버네티스 API 참조 문서](/docs/reference/)에서 확인할 수 있다. + (예를 들어 `apiVersion: batch/v1`). 지원되는 API 그룹 전체의 목록은 [쿠버네티스 API 참조 문서](/ko/docs/reference/)에서 확인할 수 있다. -[사용자 정의 리소스](/docs/concepts/api-extension/custom-resources/)로 API를 확장하는 경우에는 다음 두 종류의 경로가 지원된다. +[사용자 정의 리소스](/ko/docs/concepts/extend-kubernetes/api-extension/custom-resources/)로 API를 확장하는 경우에는 다음 두 종류의 경로가 지원된다. - 기본적인 CRUD 요구에는 - [CustomResourceDefinition](/docs/tasks/access-kubernetes-api/extend-api-custom-resource-definitions/) + [커스텀리소스데피니션(CustomResourceDefinition)](/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/) - 쿠버네티스 API의 의미론적 전체 집합으로 사용자만의 Apiserver를 구현하려는 경우에는 [aggregator](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/api-machinery/aggregated-api-servers.md) @@ -109,6 +109,3 @@ API 버전의 차이는 수준의 안정성과 지원의 차이를 나타낸다. `--runtime-config=extensions/v1beta1/deployments=true,extensions/v1beta1/daemonsets=true` 를 입력한다. {{< note >}}개별 리소스의 활성화/비활성화는 레거시 문제로 `extensions/v1beta1` API 그룹에서만 지원된다. {{< /note >}} - - - diff --git a/content/ko/docs/reference/using-api/client-libraries.md b/content/ko/docs/reference/using-api/client-libraries.md index 4757354dca..a0a87e0837 100644 --- a/content/ko/docs/reference/using-api/client-libraries.md +++ b/content/ko/docs/reference/using-api/client-libraries.md @@ -16,7 +16,7 @@ API 호출 또는 요청/응답 타입을 직접 구현할 필요는 없다. 클라이언트 라이브러리는 대체로 인증과 같은 공통의 태스크를 처리한다. 대부분의 클라이언트 라이브러리들은 API 클라이언트가 쿠버네티스 클러스터 내부에서 동작하는 경우 인증 -또는 [kubeconfig 파일](/docs/tasks/access-application-cluster/authenticate-across-clusters-kubeconfig/) 포맷을 통해 +또는 [kubeconfig 파일](/ko/docs/tasks/access-application-cluster/configure-access-multiple-clusters/) 포맷을 통해 자격증명과 API 서버 주소를 읽을 수 있게 쿠버네티스 서비스 어카운트를 발견하고 사용할 수 있다. @@ -47,6 +47,7 @@ Machinery](https://github.com/kubernetes/community/tree/master/sig-api-machinery | Go | [github.com/ericchiang/k8s](https://github.com/ericchiang/k8s) | | Java (OSGi) | [bitbucket.org/amdatulabs/amdatu-kubernetes](https://bitbucket.org/amdatulabs/amdatu-kubernetes) | | Java (Fabric8, OSGi) | [github.com/fabric8io/kubernetes-client](https://github.com/fabric8io/kubernetes-client) | +| Java | [github.com/manusa/yakc](https://github.com/manusa/yakc) | | Lisp | [github.com/brendandburns/cl-k8s](https://github.com/brendandburns/cl-k8s) | | Lisp | [github.com/xh4/cube](https://github.com/xh4/cube) | | Node.js (TypeScript) | [github.com/Goyoo/node-k8s-client](https://github.com/Goyoo/node-k8s-client) | diff --git a/content/ko/docs/setup/_index.md b/content/ko/docs/setup/_index.md index 21cd279764..b09963d0e2 100644 --- a/content/ko/docs/setup/_index.md +++ b/content/ko/docs/setup/_index.md @@ -16,35 +16,20 @@ card: <!-- overview --> -본 섹션에서는 쿠버네티스를 구축하고 실행하는 여러가지 옵션을 다룬다. - -각각의 쿠버네티스 솔루션은 유지보수의 용이성, 보안, 제어, 가용 자원, 클러스터를 운영하고 관리하기 위해 필요한 전문성과 같은 제각각의 요구사항을 충족한다. - -쿠버네티스 클러스터를 로컬 머신에, 클라우드에, 온-프레미스 데이터센터에 배포할 수 있고, 아니면 매니지드 쿠버네티스 클러스터를 선택할 수도 있다. 넓은 범위의 클라우드 프로바이더에 걸치거나 베어 메탈 환경을 사용하는 커스텀 솔루션을 만들 수도 있다. - -더 간단하게 정리하면, 쿠버네티스 클러스터를 학습 환경과 운영 환경에 만들 수 있다. - +본 섹션에는 쿠버네티스를 설정하고 실행하는 다양한 방법이 나열되어 있다. +쿠버네티스를 설치할 때는 유지보수의 용이성, 보안, 제어, 사용 가능한 리소스, 그리고 +클러스터를 운영하고 관리하기 위해 필요한 전문성을 기반으로 설치 유형을 선택한다. +쿠버네티스 클러스터를 로컬 머신에, 클라우드에, 온-프레미스 데이터센터에 배포할 수 있고, 아니면 매니지드 쿠버네티스 클러스터를 선택할 수도 있다. 광범위한 클라우드 제공 업체 또는 베어 메탈 환경에 걸쳐 사용할 수 있는 맞춤형 솔루션도 있다. <!-- body --> ## 학습 환경 -쿠버네티스를 배우고 있다면, 쿠버네티스 커뮤니티에서 지원하는 도구나, 로컬 머신에서 쿠버네티스를 설치하기 위한 생태계 내의 도구와 같은 도커 기반의 솔루션을 사용하자. - -{{< table caption="쿠버네티스를 배포하기 위해 커뮤니티와 생태계에서 지원하는 도구를 나열한 로컬 머신 솔루션 표." >}} - -|커뮤니티 |생태계 | -| ------------ | -------- | -| [Minikube](/docs/setup/learning-environment/minikube/) | [Docker Desktop](https://www.docker.com/products/docker-desktop)| -| [kind (Kubernetes IN Docker)](/docs/setup/learning-environment/kind/) | [Minishift](https://docs.okd.io/latest/minishift/)| -| | [MicroK8s](https://microk8s.io/)| - +쿠버네티스를 배우고 있다면, 쿠버네티스 커뮤니티에서 지원하는 도구나, 로컬 머신에서 쿠버네티스를 설치하기 위한 생태계 내의 도구를 사용하자. ## 운영 환경 운영 환경을 위한 솔루션을 평가할 때에는, 쿠버네티스 클러스터 운영에 대한 어떤 측면(또는 _추상적인 개념_)을 스스로 관리하기를 원하는지, 제공자에게 넘기기를 원하는지 고려하자. [쿠버네티스 파트너](https://kubernetes.io/partners/#conformance)에는 [공인 쿠버네티스](https://github.com/cncf/k8s-conformance/#certified-kubernetes) 공급자 목록이 포함되어 있다. - - diff --git a/content/ko/docs/setup/best-practices/certificates.md b/content/ko/docs/setup/best-practices/certificates.md index 0ce3fe2270..42b94acf5e 100644 --- a/content/ko/docs/setup/best-practices/certificates.md +++ b/content/ko/docs/setup/best-practices/certificates.md @@ -26,17 +26,17 @@ weight: 40 * API 서버에서 etcd 간의 통신을 위한 클라이언트 인증서 * 컨트롤러 매니저와 API 서버 간의 통신을 위한 클라이언트 인증서/kubeconfig * 스케줄러와 API 서버간 통신을 위한 클라이언트 인증서/kubeconfig -* [front-proxy][proxy]를 위한 클라이언트와 서버 인증서 +* [front-proxy](/docs/tasks/extend-kubernetes/configure-aggregation-layer/)를 위한 클라이언트와 서버 인증서 {{< note >}} -`front-proxy` 인증서는 kube-proxy에서 [API 서버 확장](/docs/tasks/access-kubernetes-api/setup-extension-api-server/)을 지원할 때만 kube-proxy에서 필요하다. +`front-proxy` 인증서는 kube-proxy에서 [API 서버 확장](/docs/tasks/extend-kubernetes/setup-extension-api-server/)을 지원할 때만 kube-proxy에서 필요하다. {{< /note >}} etcd 역시 클라이언트와 피어 간에 상호 TLS 인증을 구현한다. ## 인증서를 저장하는 위치 -만약 쿠버네티스를 kubeadm으로 설치했다면 인증서는 `/etc/kubernets/pki`에 저장된다. 이 문서에 언급된 모든 파일 경로는 그 디렉토리에 상대적이다. +만약 쿠버네티스를 kubeadm으로 설치했다면 인증서는 `/etc/kubernets/pki`에 저장된다. 이 문서에 언급된 모든 파일 경로는 그 디렉터리에 상대적이다. ## 인증서 수동 설정 @@ -52,7 +52,7 @@ etcd 역시 클라이언트와 피어 간에 상호 TLS 인증을 구현한다. |------------------------|---------------------------|----------------------------------| | ca.crt,key | kubernetes-ca | 쿠버네티스 일반 CA | | etcd/ca.crt,key | etcd-ca | 모든 etcd 관련 기능을 위해서 | -| front-proxy-ca.crt,key | kubernetes-front-proxy-ca | [front-end proxy][proxy] 위해서 | +| front-proxy-ca.crt,key | kubernetes-front-proxy-ca | [front-end proxy](/docs/tasks/extend-kubernetes/configure-aggregation-layer/) 위해서 | 위의 CA외에도, 서비스 계정 관리를 위한 공개/개인 키 쌍인 `sa.key` 와 `sa.pub` 을 얻는 것이 필요하다. @@ -72,10 +72,10 @@ etcd 역시 클라이언트와 피어 간에 상호 TLS 인증을 구현한다. | kube-apiserver-kubelet-client | kubernetes-ca | system:masters | client | | | front-proxy-client | kubernetes-front-proxy-ca | | client | | -[1]: 클러스터에 접속한 다른 IP 또는 DNS 이름([kubeadm][kubeadm] 이 사용하는 로드 밸런서 안정 IP 또는 DNS 이름, `kubernetes`, `kubernetes.default`, `kubernetes.default.svc`, +[1]: 클러스터에 접속한 다른 IP 또는 DNS 이름([kubeadm](/docs/reference/setup-tools/kubeadm/kubeadm/) 이 사용하는 로드 밸런서 안정 IP 또는 DNS 이름, `kubernetes`, `kubernetes.default`, `kubernetes.default.svc`, `kubernetes.default.svc.cluster`, `kubernetes.default.svc.cluster.local`) -`kind`는 하나 이상의 [x509 키 사용][usage] 종류를 가진다. +`kind`는 하나 이상의 [x509 키 사용](https://godoc.org/k8s.io/api/certificates/v1beta1#KeyUsage) 종류를 가진다. | 종류 | 키 사용 | |--------|---------------------------------------------------------------------------------| @@ -97,7 +97,7 @@ kubeadm 사용자만 해당: ### 인증서 파일 경로 -인증서는 권고하는 파일 경로에 존재해야 한다([kubeadm][kubeadm]에서 사용되는 것처럼). 경로는 위치에 관계없이 주어진 파라미터를 사용하여 지정되야 한다. +인증서는 권고하는 파일 경로에 존재해야 한다([kubeadm](/docs/reference/setup-tools/kubeadm/kubeadm/)에서 사용되는 것처럼). 경로는 위치에 관계없이 주어진 파라미터를 사용하여 지정되야 한다. | 기본 CN | 권고되는 키 파일 경로 | 권고하는 인증서 파일 경로 | 명령어 | 키 파라미터 | 인증서 파라미터 | |------------------------------|------------------------------|-----------------------------|----------------|------------------------------|-------------------------------------------| @@ -158,8 +158,3 @@ KUBECONFIG=<filename> kubectl config use-context default-system | controller-manager.conf | kube-controller-manager | 반드시 매니페스트를 `manifests/kube-controller-manager.yaml`에 추가해야한다. | | scheduler.conf | kube-scheduler | 반드시 매니페스트를 `manifests/kube-scheduler.yaml`에 추가해야한다. | -[usage]: https://godoc.org/k8s.io/api/certificates/v1beta1#KeyUsage -[kubeadm]: /docs/reference/setup-tools/kubeadm/kubeadm/ -[proxy]: /docs/tasks/access-kubernetes-api/configure-aggregation-layer/ - - diff --git a/content/ko/docs/setup/best-practices/cluster-large.md b/content/ko/docs/setup/best-practices/cluster-large.md index df95e1dc5c..d29c8f49c2 100644 --- a/content/ko/docs/setup/best-practices/cluster-large.md +++ b/content/ko/docs/setup/best-practices/cluster-large.md @@ -12,9 +12,6 @@ weight: 20 * 전체 컨테이너 300000개 이하 * 노드 당 파드 100개 이하 -<br> - -{{< toc >}} ## 설치 @@ -112,7 +109,7 @@ AWS에서, 마스터 노드의 크기는 클러스터 시작 시에 설정된 [#22940](http://issue.k8s.io/22940) 참조). 힙스터에 리소스가 부족한 경우라면, 힙스터 메모리 요청량(상세내용은 해당 PR 참조)을 계산하는 공식을 적용해보자. -애드온 컨테이너가 리소스 상한에 걸리는 것을 탐지하는 방법에 대해서는 [컴퓨트 리소스의 트러블슈팅 섹션](/docs/concepts/configuration/manage-compute-resources-container/#troubleshooting)을 참고하라. +애드온 컨테이너가 리소스 상한에 걸리는 것을 탐지하는 방법에 대해서는 [컴퓨트 리소스의 트러블슈팅 섹션](/ko/docs/concepts/configuration/manage-resources-containers/#문제-해결)을 참고하라. [미래](http://issue.k8s.io/13048)에는 모든 클러스터 애드온의 리소스 상한을 클러스터 크기에 맞게 설정해주고 클러스터를 키우거나 줄일 때 동적으로 조절해줄 수 있기를 기대한다. 이런 기능들에 대한 PR은 언제든 환영한다. diff --git a/content/ko/docs/setup/best-practices/multiple-zones.md b/content/ko/docs/setup/best-practices/multiple-zones.md index 13bdaa04a9..2ccd3873a0 100644 --- a/content/ko/docs/setup/best-practices/multiple-zones.md +++ b/content/ko/docs/setup/best-practices/multiple-zones.md @@ -6,7 +6,7 @@ content_type: concept <!-- overview --> -이 페이지는 여러 영역에서 어떻게 클러스터를 구동하는지 설명한다. +이 페이지는 여러 영역에서 어떻게 클러스터를 구동하는지 설명한다. @@ -77,7 +77,7 @@ located in a single zone. Users that want a highly available control plane should follow the [high availability](/docs/admin/high-availability) instructions. ### Volume limitations -The following limitations are addressed with [topology-aware volume binding](/docs/concepts/storage/storage-classes/#volume-binding-mode). +The following limitations are addressed with [topology-aware volume binding](/ko/docs/concepts/storage/storage-classes/#볼륨-바인딩-모드). * StatefulSet volume zone spreading when using dynamic provisioning is currently not compatible with pod affinity or anti-affinity policies. @@ -396,5 +396,3 @@ KUBERNETES_PROVIDER=aws KUBE_USE_EXISTING_MASTER=true KUBE_AWS_ZONE=us-west-2c k KUBERNETES_PROVIDER=aws KUBE_USE_EXISTING_MASTER=true KUBE_AWS_ZONE=us-west-2b kubernetes/cluster/kube-down.sh KUBERNETES_PROVIDER=aws KUBE_AWS_ZONE=us-west-2a kubernetes/cluster/kube-down.sh ``` - - diff --git a/content/ko/docs/setup/best-practices/node-conformance.md b/content/ko/docs/setup/best-practices/node-conformance.md index 3aa27d96ea..d4579e2f89 100644 --- a/content/ko/docs/setup/best-practices/node-conformance.md +++ b/content/ko/docs/setup/best-practices/node-conformance.md @@ -3,7 +3,6 @@ title: 노드 구성 검증하기 weight: 30 --- -{{< toc >}} ## 노드 적합성 테스트 diff --git a/content/ko/docs/setup/learning-environment/minikube.md b/content/ko/docs/setup/learning-environment/minikube.md index e8d169af96..16ea2ad587 100644 --- a/content/ko/docs/setup/learning-environment/minikube.md +++ b/content/ko/docs/setup/learning-environment/minikube.md @@ -135,7 +135,7 @@ Minikube는 다음과 같은 쿠버네티스의 기능을 제공한다. -no body in request- ``` - 서비스나 클러스터가 더 이상 구동되지 않도록 하려면, 삭제한다. + 서비스나 클러스터가 더 이상 구동되지 않도록 하려면, 삭제한다. 7. `hello-minikube` 서비스 삭제 @@ -194,24 +194,24 @@ Minikube는 다음과 같은 쿠버네티스의 기능을 제공한다. 클러스터를 시작하기 위해서 `minikube start` 커멘드를 사용할 수 있다. 이 커멘드는 단일 노드 쿠버네티스 클러스터를 구동하는 가상 머신을 생성하고 구성한다. -이 커멘드는 또한 [kubectl](/docs/user-guide/kubectl-overview/)도 설정해서 클러스터와 통신할 수 있도록 한다. +이 커멘드는 또한 [kubectl](/ko/docs/reference/kubectl/overview/)도 설정해서 클러스터와 통신할 수 있도록 한다. {{< note >}} -웹 프록시 뒤에 있다면, `minikube start` 커맨드에 해당 정보를 전달해야 한다. +웹 프록시 뒤에 있다면, `minikube start` 커맨드에 해당 정보를 전달해야 한다. ```shell https_proxy=<my proxy> minikube start --docker-env http_proxy=<my proxy> --docker-env https_proxy=<my proxy> --docker-env no_proxy=192.168.99.0/24 ``` 불행하게도, 환경 변수 설정만으로는 되지 않는다. -Minikube는 또한 "minikube" 컨텍스트를 생성하고 이를 kubectl의 기본값으로 설정한다. -이 컨텍스트로 돌아오려면, 다음의 코멘드를 입력한다. `kubectl config use-context minikube`. +Minikube는 또한 "minikube" 콘텍스트를 생성하고 이를 kubectl의 기본값으로 설정한다. +이 콘텍스트로 돌아오려면, 다음의 코멘드를 입력한다. `kubectl config use-context minikube`. {{< /note >}} #### 쿠버네티스 버전 지정하기 -`minikube start` 코멘드에 `--kubernetes-version` 문자열을 -추가해서 Minikube에서 사용할 쿠버네티스 버전을 지정할 수 있다. +`minikube start` 코멘드에 `--kubernetes-version` 문자열을 +추가해서 Minikube에서 사용할 쿠버네티스 버전을 지정할 수 있다. 예를 들어 버전 {{< param "fullversion" >}}를 구동하려면, 다음과 같이 실행한다. ``` @@ -239,7 +239,7 @@ Minikube는 다음의 드라이버를 지원한다. * vmware ([드라이버 설치](https://minikube.sigs.k8s.io/docs/reference/drivers/vmware/)) (VMware unified driver) * parallels ([드라이버 설치](https://minikube.sigs.k8s.io/docs/reference/drivers/parallels/)) * none (쿠버네티스 컴포넌트를 가상 머신이 아닌 호스트 상에서 구동한다. 리눅스를 실행중이어야 하고, {{< glossary_tooltip term_id="docker" >}}가 설치되어야 한다.) - + {{< caution >}} `none` 드라이버를 사용한다면 일부 쿠버네티스 컴포넌트는 Minikube 환경 외부에 있는 부작용이 있는 권한을 가진 컨테이너로 실행된다. 이런 부작용은 개인용 워크스테이션에는 `none` 드라이버가 권장하지 않는 것을 의미 한다. {{< /caution >}} @@ -357,27 +357,34 @@ Minikube는 사용자가 쿠버네티스 컴포넌트를 다양한 값으로 설 ### 클러스터 중지 `minikube stop` 명령어는 클러스터를 중지하는데 사용할 수 있다. 이 명령어는 Minikube 가상 머신을 종료하지만, 모든 클러스터 상태와 데이터를 보존한다. -클러스터를 다시 시작하면 이전의 상태로 돌려줍니다. +클러스터를 다시 시작하면 이전의 상태로 돌려준다. ### 클러스터 삭제 `minikube delete` 명령은 클러스터를 삭제하는데 사용할 수 있다. 이 명령어는 Minikube 가상 머신을 종료하고 삭제한다. 어떤 데이터나 상태도 보존되지 않다. ### Minikube 업그레이드 -macOS를 사용하는 경우 기존에 설치된 Minikube를 업그레이드하려면 [Minikube 업그레이드](https://minikube.sigs.k8s.io/docs/start/macos/#upgrading-minikube)를 참조한다. +macOS를 사용하고 있고 [Brew 패키지 관리자](https://brew.sh/)가 설치되어 있다면 다음과 같이 실행한다. + +```shell +brew update +brew upgrade minikube +``` ## 클러스터와 상호 작용하기 ### Kubectl -`minikube start` 명령어는 Minikube로 부르는 [kubectl 컨텍스트](/docs/reference/generated/kubectl/kubectl-commands/#-em-set-context-em-)를 생성한다. -이 컨텍스트는 Minikube 클러스터와 통신하는 설정을 포함한다. +`minikube start` 명령어는 Minikube로 부르는 [kubectl 콘텍스트](/docs/reference/generated/kubectl/kubectl-commands/#-em-set-context-em-)를 생성한다. +이 콘텍스트는 Minikube 클러스터와 통신하는 설정을 포함한다. -Minikube는 이 컨텍스트를 자동적으로 기본으로 설정한다. 만약 미래에 이것을 바꾸고 싶다면 +Minikube는 이 콘텍스트를 자동적으로 기본으로 설정한다. 만약 미래에 이것을 바꾸고 싶다면 다음을 실행하자. -`kubectl config use-context minikube`을 실행하자. +`kubectl config use-context minikube` -혹은 `kubectl get pods --context=minikube`처럼 코멘드를 실행할때마다 매번 컨텍스트를 전달한다. +혹은 다음과 같이 커맨드를 실행할 때마다 매번 콘텍스트를 전달한다. + +`kubectl get pods --context=minikube` ### 대시보드 @@ -440,9 +447,9 @@ spec: | Driver | OS | HostFolder | VM | | --- | --- | --- | --- | -| VirtualBox | Linux | /home | /hosthome | +| VirtualBox | 리눅스 | /home | /hosthome | | VirtualBox | macOS | /Users | /Users | -| VirtualBox | Windows | C://Users | /c/Users | +| VirtualBox | 윈도우 | C://Users | /c/Users | | VMware Fusion | macOS | /Users | /mnt/hgfs/Users | | Xhyve | macOS | /Users | /Users | @@ -454,7 +461,7 @@ spec: ## 애드온 -Minikube에서 커스텀 애드온을 적절히 시작하고 재시작할 수 있으려면, +Minikube에서 커스텀 애드온을 적절히 시작하고 재시작할 수 있으려면, Minikube와 함께 시작하려는 애드온을 `~/.minikube/addons` 디렉터리에 두자. 폴더 내부의 애드온은 Minikube VM으로 이동되어 Minikube가 시작하거나 재시작될 때에 함께 실행된다. @@ -497,8 +504,8 @@ Minikube에 대한 더 자세한 정보는, [제안](https://git.k8s.io/communit * **개발 가이드**: 풀 리퀘스트를 보내는 방법에 대한 개요는 [기여하기](https://minikube.sigs.k8s.io/docs/contrib/)를 살펴보자. * **Minikube 빌드**: Minikube를 소스에서 빌드/테스트하는 방법은 [빌드 가이드](https://minikube.sigs.k8s.io/docs/contrib/building/)를 살펴보자. * **새 의존성 추가하기**: Minikube에 새 의존성을 추가하는 방법에 대해서는, [의존성 추가 가이드](https://minikube.sigs.k8s.io/docs/contrib/drivers/)를 보자. -* **새 애드온 추가하기**: Minikube에 새 애드온을 추가하는 방법에 대해서는, [애드온 추가 가이드](https://minikube.sigs.k8s.io/docs/contrib/addons/)를 보자. -* **MicroK8s**: 가상 머신을 사용하지 않으려는 Linux 사용자는 대안으로 [MicroK8s](https://microk8s.io/)를 고려할 수 있다. +* **새 애드온 추가하기**: Minikube에 새 애드온을 추가하는 방법에 대해서는, [애드온 추가 가이드](https://minikube.sigs.k8s.io/docs/contrib/addons/)를 보자. +* **MicroK8s**: 가상 머신을 사용하지 않으려는 리눅스 사용자는 대안으로 [MicroK8s](https://microk8s.io/)를 고려할 수 있다. ## 커뮤니티 diff --git a/content/ko/docs/setup/production-environment/container-runtimes.md b/content/ko/docs/setup/production-environment/container-runtimes.md index f14834ff25..39c2d07464 100644 --- a/content/ko/docs/setup/production-environment/container-runtimes.md +++ b/content/ko/docs/setup/production-environment/container-runtimes.md @@ -25,7 +25,7 @@ weight: 10 ### 적용 가능성 {{< note >}} -이 문서는 Linux에 CRI를 설치하는 사용자를 위해 작성되었다. +이 문서는 리눅스에 CRI를 설치하는 사용자를 위해 작성되었다. 다른 운영 체제의 경우, 해당 플랫폼과 관련된 문서를 찾아보자. {{< /note >}} @@ -34,7 +34,7 @@ weight: 10 ### Cgroup 드라이버 -Linux 배포판의 init 시스템이 systemd인 경우, init 프로세스는 +리눅스 배포판의 init 시스템이 systemd인 경우, init 프로세스는 root control group(`cgroup`)을 생성 및 사용하는 cgroup 관리자로 작동한다. Systemd는 cgroup과의 긴밀한 통합을 통해 프로세스당 cgroup을 할당한다. 컨테이너 런타임과 kubelet이 `cgroupfs`를 사용하도록 설정할 수 있다. @@ -62,7 +62,7 @@ kubelet을 재시작 하는 것은 에러를 해결할 수 없을 것이다. ## 도커 각 머신들에 대해서, 도커를 설치한다. -버전 19.03.8이 추천된다. 그러나 1.13.1, 17.03, 17.06, 17.09, 18.06 그리고 18.09도 동작하는 것으로 알려져 있다. +버전 19.03.11이 추천된다. 그러나 1.13.1, 17.03, 17.06, 17.09, 18.06 그리고 18.09도 동작하는 것으로 알려져 있다. 쿠버네티스 릴리스 노트를 통해서, 최신에 검증된 도커 버전의 지속적인 파악이 필요하다. 시스템에 도커를 설치하기 위해서 아래의 커맨드들을 사용한다. @@ -94,9 +94,9 @@ add-apt-repository \ ```shell # 도커 CE 설치. apt-get update && apt-get install -y \ - containerd.io=1.2.13-1 \ - docker-ce=5:19.03.8~3-0~ubuntu-$(lsb_release -cs) \ - docker-ce-cli=5:19.03.8~3-0~ubuntu-$(lsb_release -cs) + containerd.io=1.2.13-2 \ + docker-ce=5:19.03.11~3-0~ubuntu-$(lsb_release -cs) \ + docker-ce-cli=5:19.03.11~3-0~ubuntu-$(lsb_release -cs) ``` ```shell @@ -142,8 +142,8 @@ yum-config-manager --add-repo \ # 도커 CE 설치. yum update -y && yum install -y \ containerd.io-1.2.13 \ - docker-ce-19.03.8 \ - docker-ce-cli-19.03.8 + docker-ce-19.03.11 \ + docker-ce-cli-19.03.11 ``` ```shell @@ -180,6 +180,12 @@ systemctl restart docker {{< /tab >}} {{< /tabs >}} +부팅 시 도커 서비스를 시작하려면, 다음 명령을 실행한다. + +```shell +sudo systemctl enable docker +``` + 자세한 내용은 [공식 도커 설치 가이드](https://docs.docker.com/engine/installation/) 를 참고한다. diff --git a/content/ko/docs/setup/production-environment/tools/kops.md b/content/ko/docs/setup/production-environment/tools/kops.md index 29716b44e1..644ca5dae4 100644 --- a/content/ko/docs/setup/production-environment/tools/kops.md +++ b/content/ko/docs/setup/production-environment/tools/kops.md @@ -9,7 +9,7 @@ weight: 20 이곳 빠른 시작에서는 사용자가 얼마나 쉽게 AWS에 쿠버네티스 클러스터를 설치할 수 있는지 보여준다. [`kops`](https://github.com/kubernetes/kops)라는 이름의 툴을 이용할 것이다. -kops는 자동화된 프로비저닝 시스템인데, +kops는 자동화된 프로비저닝 시스템인데, * 완전 자동화된 설치 * DNS를 통해 클러스터들의 신원 확인 @@ -23,11 +23,11 @@ kops는 자동화된 프로비저닝 시스템인데, ## {{% heading "prerequisites" %}} -* [kubectl](/docs/tasks/tools/install-kubectl/)을 반드시 설치해야 한다. +* [kubectl](/ko/docs/tasks/tools/install-kubectl/)을 반드시 설치해야 한다. * 반드시 64-bit (AMD64 그리고 Intel 64)디바이스 아키텍쳐 위에서 `kops` 를 [설치](https://github.com/kubernetes/kops#installing) 한다. -* [AWS 계정](https://docs.aws.amazon.com/polly/latest/dg/setting-up.html)이 있고 [IAM 키](https://docs.aws.amazon.com/general/latest/gr/aws-sec-cred-types.html#access-keys-and-secret-access-keys)를 생성하고 [구성](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-configure.html#cli-quick-configuration) 해야 한다. +* [AWS 계정](https://docs.aws.amazon.com/polly/latest/dg/setting-up.html)이 있고 [IAM 키](https://docs.aws.amazon.com/general/latest/gr/aws-sec-cred-types.html#access-keys-and-secret-access-keys)를 생성하고 [구성](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-configure.html#cli-quick-configuration)해야 한다. IAM 사용자는 [적절한 권한](https://github.com/kubernetes/kops/blob/master/docs/getting_started/aws.md#setup-iam-user)이 필요하다. @@ -82,7 +82,7 @@ brew update && brew install kops ``` {{% /tab %}} -{{% tab name="Linux" %}} +{{% tab name="리눅스" %}} 최신 릴리즈를 다운로드 받는 명령어: @@ -127,7 +127,7 @@ brew update && brew install kops kops는 클러스터 내부와 외부 모두에서 검색을 위해 DNS을 사용하기에 클라이언트에서 쿠버네티스 API 서버에 연결할 수 있다. -이런 클러스터 이름에 kops는 명확한 견해을 가지는데: 반드시 유효한 DNS 이름이어야 한다. 이렇게 함으로써 +이런 클러스터 이름에 kops는 명확한 견해을 가지는데: 반드시 유효한 DNS 이름이어야 한다. 이렇게 함으로써 사용자는 클러스터를 헷갈리지 않을것이고, 동료들과 혼선없이 공유할 수 있으며, IP를 기억할 필요없이 접근할 수 있다. @@ -140,7 +140,7 @@ Route53 hosted zone은 서브도메인도 지원한다. 여러분의 hosted zone `example.com`하위에는 그렇지 않을 수 있다). `dev.example.com`을 hosted zone으로 사용하고 있다고 가정해보자. -보통 사용자는 [일반적인 방법](http://docs.aws.amazon.com/Route53/latest/DeveloperGuide/CreatingNewSubdomain.html) 에 따라 생성하거나 +보통 사용자는 [일반적인 방법](http://docs.aws.amazon.com/Route53/latest/DeveloperGuide/CreatingNewSubdomain.html) 에 따라 생성하거나 `aws route53 create-hosted-zone --name dev.example.com --caller-reference 1` 와 같은 커맨드를 이용한다. 그 후 도메인 내 레코드들을 확인할 수 있도록 상위 도메인내에 NS 레코드를 생성해야 한다. 여기서는, @@ -175,7 +175,7 @@ S3 버킷 이름으로 정하자. * `aws s3 mb s3://clusters.dev.example.com`를 이용해 S3 버킷을 생성한다. -* `export KOPS_STATE_STORE=s3://clusters.dev.example.com` 하면, kops는 이 위치를 기본값으로 인식할 것이다. +* `export KOPS_STATE_STORE=s3://clusters.dev.example.com` 하면, kops는 이 위치를 기본값으로 인식할 것이다. 이 부분을 bash profile등에 넣어두는것을 권장한다. @@ -185,7 +185,7 @@ S3 버킷 이름으로 정하자. `kops create cluster --zones=us-east-1c useast1.dev.example.com` -kops는 클러스터에 사용될 설정을 생성할것이다. 여기서 주의할 점은 실제 클러스트 리소스가 아닌 _설정_ +kops는 클러스터에 사용될 설정을 생성할것이다. 여기서 주의할 점은 실제 클러스트 리소스가 아닌 _설정_ 만을 생성한다는 것에 주의하자 - 이 부분은 다음 단계에서 `kops update cluster` 으로 구성해볼 것이다. 그 때 만들어진 설정을 점검하거나 변경할 수 있다. @@ -220,7 +220,7 @@ kops는 클러스터에 사용될 설정을 생성할것이다. 여기서 주의 ### 다른 애드온 탐험 -[애드온 리스트](/docs/concepts/cluster-administration/addons/) 에서 쿠버네티스 클러스터용 로깅, 모니터링, 네트워크 정책, 시각화 & 제어 등을 포함한 다른 애드온을 확인해본다. +[애드온 리스트](/ko/docs/concepts/cluster-administration/addons/) 에서 쿠버네티스 클러스터용 로깅, 모니터링, 네트워크 정책, 시각화 & 제어 등을 포함한 다른 애드온을 확인해본다. ## 정리하기 @@ -231,9 +231,7 @@ kops는 클러스터에 사용될 설정을 생성할것이다. 여기서 주의 ## {{% heading "whatsnext" %}} -* 쿠버네티스 [개념](/docs/concepts/) 과 [`kubectl`](/docs/user-guide/kubectl-overview/)에 대해 더 알아보기. +* 쿠버네티스 [개념](/ko/docs/concepts/) 과 [`kubectl`](/ko/docs/reference/kubectl/overview/)에 대해 더 알아보기. * 튜토리얼, 모범사례 및 고급 구성 옵션에 대한 `kops` [고급 사용법](https://kops.sigs.k8s.io/)에 대해 더 자세히 알아본다. * 슬랙(Slack)에서 `kops` 커뮤니티 토론을 할 수 있다: [커뮤니티 토론](https://github.com/kubernetes/kops#other-ways-to-communicate-with-the-contributors) * 문제를 해결하거나 이슈를 제기하여 `kops` 에 기여한다. [깃헙 이슈](https://github.com/kubernetes/kops/issues) - - diff --git a/content/ko/docs/setup/release/notes.md b/content/ko/docs/setup/release/notes.md index 270287b1b3..740d468acc 100644 --- a/content/ko/docs/setup/release/notes.md +++ b/content/ko/docs/setup/release/notes.md @@ -2,7 +2,7 @@ title: v1.18 릴리스 노트 weight: 10 card: - name: 다운로드 + name: release-notes weight: 20 anchors: - anchor: "#" @@ -62,12 +62,10 @@ card: ## v1.17.0 이후 체인지로그 -릴리스 노트의 전체 체인지로그는 이제 [https://relnotes.k8s.io][1]에서 사용자 정의 가능한 +릴리스 노트의 전체 체인지로그는 이제 [https://relnotes.k8s.io](https://relnotes.k8s.io/?releaseVersions=1.18.0)에서 사용자 정의 가능한 형식으로 호스팅된다. 확인하고 의견을 보내주기 바란다! -[1]: https://relnotes.k8s.io/?releaseVersions=1.18.0 - ## 새로운 소식 (주요 테마) ### 쿠버네티스 토폴로지 매니저가 베타로 전환 - 정렬! @@ -86,7 +84,7 @@ card: ### SIG CLI의 kubectl 디버그 소개 -SIG CLI는 이미 오랫동안 디버그 유틸리티의 필요성에 대해 논의하고 있었다. [임시(ephemeral) 컨테이너](https://kubernetes.io/ko/docs/concepts/workloads/pods/ephemeral-containers/)가 개발되면서, `kubectl exec` 위에 구축된 도구를 통해 개발자를 지원할 수 있는 방법이 더욱 분명해졌다. `kubectl debug` [커맨드](https://github.com/kubernetes/enhancements/blob/master/keps/sig-cli/20190805-kubectl-debug.md) 추가(알파이지만 피드백은 언제나 환영)로 개발자는 클러스터 내에서 파드를 쉽게 디버깅할 수 있다. 우리는 이 추가 기능이 매우 유용하다고 생각한다. 이 커맨드를 사용하면 검사하려는 파드 바로 옆에서 실행되는 임시 컨테이너를 만들 수 있고, 대화식 문제 해결을 위해 콘솔에 연결할 수도 있다. +SIG CLI는 이미 오랫동안 디버그 유틸리티의 필요성에 대해 논의하고 있었다. [임시(ephemeral) 컨테이너](/ko/docs/concepts/workloads/pods/ephemeral-containers/)가 개발되면서, `kubectl exec` 위에 구축된 도구를 통해 개발자를 지원할 수 있는 방법이 더욱 분명해졌다. `kubectl debug` [커맨드](https://github.com/kubernetes/enhancements/blob/master/keps/sig-cli/20190805-kubectl-debug.md) 추가(알파이지만 피드백은 언제나 환영)로 개발자는 클러스터 내에서 파드를 쉽게 디버깅할 수 있다. 우리는 이 추가 기능이 매우 유용하다고 생각한다. 이 커맨드를 사용하면 검사하려는 파드 바로 옆에서 실행되는 임시 컨테이너를 만들 수 있고, 대화식 문제 해결을 위해 콘솔에 연결할 수도 있다. ### 쿠버네티스를 위한 윈도우 CSI 지원 알파 소개 @@ -306,7 +304,7 @@ NodeLocal DNSCache는 dnsCache 파드를 데몬셋으로 실행하여 clusterDNS - Kube-proxy: iptables 프록시에 이중 스택 IPv4/IPv6 지원이 추가되었다. ([#82462](https://github.com/kubernetes/kubernetes/pull/82462), [@vllry](https://github.com/vllry)) [SIG 네트워크] - Kubeadm은 이제 kube-controller-manager에 대한 이중 스택 노드 cidr 마스크의 자동 계산을 지원한다. ([#85609](https://github.com/kubernetes/kubernetes/pull/85609), [@Arvinderpal](https://github.com/Arvinderpal)) [SIG 클러스터 라이프사이클] - Kubeadm: 잡(Job)을 배포하는 업그레이드된 헬스 체크를 추가한다. ([#81319](https://github.com/kubernetes/kubernetes/pull/81319), [@neolit123](https://github.com/neolit123)) [SIG 클러스터 라이프사이클] -- Kubeadm: 실험 기능 게이트 PublicKeysECDSA를 추가하여 "kubeadm init"에서 ECDSA 인증서가 있는 +- Kubeadm: 실험 기능 게이트 PublicKeysECDSA를 추가하여 "kubeadm init"에서 ECDSA 인증서가 있는 클러스터를 생성할 수 있게 한다. "kubeadm alpha certs renew"을 사용하여 기존 ECDSA 인증서의 갱신도 지원되지만, 즉시 또는 업그레이드 중에 RSA와 ECDSA 알고리즘간에 전환하지는 않는다. ([#86953](https://github.com/kubernetes/kubernetes/pull/86953), [@rojkov](https://github.com/rojkov)) [SIG API Machinery, Auth 및 클러스터 라이프사이클] - Kubeadm: JSON, YAML, Go 템플릿 및 JsonPath 형식으로 'kubeadm config images list' 커맨드의 구조화된 출력을 구현했다. ([#86810](https://github.com/kubernetes/kubernetes/pull/86810), [@bart0sh](https://github.com/bart0sh)) [SIG 클러스터 라이프사이클] - Kubeadm: kubeconfig 인증서 갱신 시, 내장된 CA를 디스크의 CA와 동기화된 상태로 유지한다. ([#88052](https://github.com/kubernetes/kubernetes/pull/88052), [@neolit123](https://github.com/neolit123)) [SIG 클러스터 라이프사이클] @@ -689,8 +687,8 @@ filename | sha512 hash - Add `rest_client_rate_limiter_duration_seconds` metric to component-base to track client side rate limiter latency in seconds. Broken down by verb and URL. ([#88134](https://github.com/kubernetes/kubernetes/pull/88134), [@jennybuckley](https://github.com/jennybuckley)) [SIG API Machinery, Cluster Lifecycle and Instrumentation] - Allow user to specify resource using --filename flag when invoking kubectl exec ([#88460](https://github.com/kubernetes/kubernetes/pull/88460), [@soltysh](https://github.com/soltysh)) [SIG CLI and Testing] -- Apiserver add a new flag --goaway-chance which is the fraction of requests that will be closed gracefully(GOAWAY) to prevent HTTP/2 clients from getting stuck on a single apiserver. - After the connection closed(received GOAWAY), the client's other in-flight requests won't be affected, and the client will reconnect. +- Apiserver add a new flag --goaway-chance which is the fraction of requests that will be closed gracefully(GOAWAY) to prevent HTTP/2 clients from getting stuck on a single apiserver. + After the connection closed(received GOAWAY), the client's other in-flight requests won't be affected, and the client will reconnect. The flag min value is 0 (off), max is .02 (1/50 requests); .001 (1/1000) is a recommended starting point. Clusters with single apiservers, or which don't use a load balancer, should NOT enable this. ([#88567](https://github.com/kubernetes/kubernetes/pull/88567), [@answer1991](https://github.com/answer1991)) [SIG API Machinery] - Azure: add support for single stack IPv6 ([#88448](https://github.com/kubernetes/kubernetes/pull/88448), [@aramase](https://github.com/aramase)) [SIG Cloud Provider] @@ -739,7 +737,7 @@ filename | sha512 hash - Kubelets perform fewer unnecessary pod status update operations on the API server. ([#88591](https://github.com/kubernetes/kubernetes/pull/88591), [@smarterclayton](https://github.com/smarterclayton)) [SIG Node and Scalability] - Plugin/PluginConfig and Policy APIs are mutually exclusive when running the scheduler ([#88864](https://github.com/kubernetes/kubernetes/pull/88864), [@alculquicondor](https://github.com/alculquicondor)) [SIG Scheduling] - Specifying PluginConfig for the same plugin more than once fails scheduler startup. - + Specifying extenders and configuring .ignoredResources for the NodeResourcesFit plugin fails ([#88870](https://github.com/kubernetes/kubernetes/pull/88870), [@alculquicondor](https://github.com/alculquicondor)) [SIG Scheduling] - Support TLS Server Name overrides in kubeconfig file and via --tls-server-name in kubectl ([#88769](https://github.com/kubernetes/kubernetes/pull/88769), [@deads2k](https://github.com/deads2k)) [SIG API Machinery, Auth and CLI] - Terminating a restartPolicy=Never pod no longer has a chance to report the pod succeeded when it actually failed. ([#88440](https://github.com/kubernetes/kubernetes/pull/88440), [@smarterclayton](https://github.com/smarterclayton)) [SIG Node and Testing] @@ -806,18 +804,18 @@ filename | sha512 hash If you are setting `--redirect-container-streaming=true`, then you must migrate off this configuration. The flag will no longer be able to be enabled starting in v1.20. If you are not setting the flag, no action is necessary. ([#88290](https://github.com/kubernetes/kubernetes/pull/88290), [@tallclair](https://github.com/tallclair)) [SIG API Machinery and Node] - Yes. - + Feature Name: Support using network resources (VNet, LB, IP, etc.) in different AAD Tenant and Subscription than those for the cluster. - + Changes in Pull Request: - + 1. Add properties `networkResourceTenantID` and `networkResourceSubscriptionID` in cloud provider auth config section, which indicates the location of network resources. 2. Add function `GetMultiTenantServicePrincipalToken` to fetch multi-tenant service principal token, which will be used by Azure VM/VMSS Clients in this feature. 3. Add function `GetNetworkResourceServicePrincipalToken` to fetch network resource service principal token, which will be used by Azure Network Resource (Load Balancer, Public IP, Route Table, Network Security Group and their sub level resources) Clients in this feature. 4. Related unit tests. - + None. - + User Documentation: In PR https://github.com/kubernetes-sigs/cloud-provider-azure/pull/301 ([#88384](https://github.com/kubernetes/kubernetes/pull/88384), [@bowen5](https://github.com/bowen5)) [SIG Cloud Provider] ## Changes by Kind @@ -833,8 +831,8 @@ filename | sha512 hash - Added support for multiple sizes huge pages on a container level ([#84051](https://github.com/kubernetes/kubernetes/pull/84051), [@bart0sh](https://github.com/bart0sh)) [SIG Apps, Node and Storage] - AppProtocol is a new field on Service and Endpoints resources, enabled with the ServiceAppProtocol feature gate. ([#88503](https://github.com/kubernetes/kubernetes/pull/88503), [@robscott](https://github.com/robscott)) [SIG Apps and Network] - Fixed missing validation of uniqueness of list items in lists with `x-kubernetes-list-type: map` or x-kubernetes-list-type: set` in CustomResources. ([#84920](https://github.com/kubernetes/kubernetes/pull/84920), [@sttts](https://github.com/sttts)) [SIG API Machinery] -- Introduces optional --detect-local flag to kube-proxy. - Currently the only supported value is "cluster-cidr", +- Introduces optional --detect-local flag to kube-proxy. + Currently the only supported value is "cluster-cidr", which is the default if not specified. ([#87748](https://github.com/kubernetes/kubernetes/pull/87748), [@satyasm](https://github.com/satyasm)) [SIG Cluster Lifecycle, Network and Scheduling] - Kube-scheduler can run more than one scheduling profile. Given a pod, the profile is selected by using its `.spec.SchedulerName`. ([#88285](https://github.com/kubernetes/kubernetes/pull/88285), [@alculquicondor](https://github.com/alculquicondor)) [SIG Apps, Scheduling and Testing] - Moving Windows RunAsUserName feature to GA ([#87790](https://github.com/kubernetes/kubernetes/pull/87790), [@marosset](https://github.com/marosset)) [SIG Apps and Windows] @@ -1048,9 +1046,9 @@ filename | sha512 hash - aggragation api will have alpha support for network proxy ([#87515](https://github.com/kubernetes/kubernetes/pull/87515), [@Sh4d1](https://github.com/Sh4d1)) [SIG API Machinery] - API request throttling (due to a high rate of requests) is now reported in client-go logs at log level 2. The messages are of the form - + Throttling request took 1.50705208s, request: GET:<URL> - + The presence of these messages, may indicate to the administrator the need to tune the cluster accordingly. ([#87740](https://github.com/kubernetes/kubernetes/pull/87740), [@jennybuckley](https://github.com/jennybuckley)) [SIG API Machinery] - kubeadm: reject a node joining the cluster if a node with the same name already exists ([#81056](https://github.com/kubernetes/kubernetes/pull/81056), [@neolit123](https://github.com/neolit123)) [SIG Cluster Lifecycle] - disableAvailabilitySetNodes is added to avoid VM list for VMSS clusters. It should only be used when vmType is "vmss" and all the nodes (including masters) are VMSS virtual machines. ([#87685](https://github.com/kubernetes/kubernetes/pull/87685), [@feiskyer](https://github.com/feiskyer)) [SIG Cloud Provider] @@ -1360,7 +1358,7 @@ filename | sha512 hash * Update Cluster Autoscaler to 1.17.0; changelog: https://github.com/kubernetes/autoscaler/releases/tag/cluster-autoscaler-1.17.0 ([#85610](https://github.com/kubernetes/kubernetes/pull/85610), [@losipiuk](https://github.com/losipiuk)) * Filter published OpenAPI schema by making nullable, required fields non-required in order to avoid kubectl to wrongly reject null values. ([#85722](https://github.com/kubernetes/kubernetes/pull/85722), [@sttts](https://github.com/sttts)) * kubectl set resources will no longer return an error if passed an empty change for a resource. ([#85490](https://github.com/kubernetes/kubernetes/pull/85490), [@sallyom](https://github.com/sallyom)) - * kubectl set subject will no longer return an error if passed an empty change for a resource. + * kubectl set subject will no longer return an error if passed an empty change for a resource. * kube-apiserver: fixed a conflict error encountered attempting to delete a pod with gracePeriodSeconds=0 and a resourceVersion precondition ([#85516](https://github.com/kubernetes/kubernetes/pull/85516), [@michaelgugino](https://github.com/michaelgugino)) * kubeadm: add a upgrade health check that deploys a Job ([#81319](https://github.com/kubernetes/kubernetes/pull/81319), [@neolit123](https://github.com/neolit123)) * kubeadm: make sure images are pre-pulled even if a tag did not change but their contents changed ([#85603](https://github.com/kubernetes/kubernetes/pull/85603), [@bart0sh](https://github.com/bart0sh)) diff --git a/content/ko/docs/tasks/_index.md b/content/ko/docs/tasks/_index.md index b9e161f26b..e6c80f32ed 100644 --- a/content/ko/docs/tasks/_index.md +++ b/content/ko/docs/tasks/_index.md @@ -5,80 +5,11 @@ weight: 50 content_type: concept --- -{{< toc >}} - <!-- overview --> -쿠버네티스 문서에서 이 섹션은 개별의 태스크를 수행하는 방법을 -보여준다. 한 태스크 페이지는 일반적으로 여러 단계로 이루어진 짧은 +쿠버네티스 문서에서 이 섹션은 개별의 태스크를 수행하는 방법을 +보여준다. 한 태스크 페이지는 일반적으로 여러 단계로 이루어진 짧은 시퀀스를 제공함으로써, 하나의 일을 수행하는 방법을 보여준다. - - -<!-- body --> - -## 웹 UI (대시보드) - -쿠버네티스 클러스터에서 컨테이너화 된 애플리케이션을 관리 및 모니터하는 것을 돕기 위해서 대시보드 웹 유저 인터페이스를 디플로이하고 접속한다. - -## kubectl 커맨드라인 사용하기 - -쿠버네티스 클러스터를 직접 관리하기 위해서 사용되는 `kubectl` 커맨드라인 툴을 설치 및 설정한다. - -## 파드 및 컨테이너 구성하기 - -파드 및 컨테이너에 대한 일반적인 구성 태스크를 수행한다. - -## 애플리케이션 동작시키기 - -롤링 업데이트, 파드에 정보 주입하기, 파드 수평적 오토스케일링 등, 일반적인 애플리케이션 관리 태스크를 수행한다. - -## 잡 동작시키기 - -병렬 프로세싱을 사용하는 잡을 동작시킨다. - -## 클러스터의 애플리케이션에 접근하기 - -클러스터 내에 있는 애플리케이션에 접근할 수 있도록 로드 밸런싱, 포트 포워딩, 방화벽 또는 DNS 구성 등을 구성한다. - -## 모니터링, 로깅, 디버깅 - -클러스터 문제를 해결하거나 컨테이너화 된 애플리케이션을 디버깅하기 위해서 모니터링과 로깅을 설정한다. - -## 쿠버네티스 API에 접근하기 - -쿠버네티스 API에 직접 접근하는 다양한 방법을 배운다. - -## TLS 사용하기 - -클러스터 루트 인증 기관(CA)을 신뢰 및 사용하도록 애플리케이션을 구성한다. - -## 클러스터 운영하기(administering) - -클러스터를 운영하기 위한 일반적인 태스크를 배운다. - -## 스테이트풀 애플리케이션 관리하기 - -스테이트풀 셋의 스케일링, 삭제하기, 디버깅을 포함하는 스테이트풀 애플리케이션 관리를 위한 일반적인 태스크를 수행한다. - -## 클러스터 데몬 - -롤링 업데이트를 수행과 같은, 데몬 셋 관리를 위한 일반적인 태스크를 수행한다. - -## GPU 관리하기 - -클러스터의 노드들에 의해서 리소스로 사용될 NVIDIA GPU들을 구성 및 스케줄한다. - -## HugePage 관리하기 - -클러스터에서 스케줄 가능한 리소스로서 Huge Page들을 구성 및 스케줄한다. - - - -## {{% heading "whatsnext" %}} - - -만약 태스크 페이지를 작성하고 싶다면, -[문서 풀 리퀘스트(Pull Request) 생성하기](/docs/home/contribute/create-pull-request/)를 참조한다. - - +만약 태스크 페이지를 작성하고 싶다면, +[문서 풀 리퀘스트(Pull Request) 생성하기](/ko/docs/contribute/new-content/new-content/)를 참조한다. diff --git a/content/ko/docs/tasks/access-application-cluster/_index.md b/content/ko/docs/tasks/access-application-cluster/_index.md index 4cb552677c..603b186517 100755 --- a/content/ko/docs/tasks/access-application-cluster/_index.md +++ b/content/ko/docs/tasks/access-application-cluster/_index.md @@ -1,5 +1,6 @@ --- title: "클러스터 내 어플리케이션 액세스" +description: 클러스터의 애플리케이션에 접근하기 위해 로드 밸런싱, 포트 포워딩, 방화벽 설정 또는 DNS 구성을 설정한다. weight: 60 --- diff --git a/content/ko/docs/tasks/access-application-cluster/access-cluster.md b/content/ko/docs/tasks/access-application-cluster/access-cluster.md index ded8f15aad..c28c51ea16 100644 --- a/content/ko/docs/tasks/access-application-cluster/access-cluster.md +++ b/content/ko/docs/tasks/access-application-cluster/access-cluster.md @@ -15,12 +15,12 @@ content_type: concept ## 처음이라면 kubectl을 사용하여 액세스 -최초로 쿠버네티스 API에 액세스할 때 우리는 +최초로 쿠버네티스 API에 액세스할 때 우리는 쿠버네티스 CLI인 `kubectl`을 사용하는 것을 추천한다. -클러스터에 액세스하려면 클러스터의 위치정보를 알아야 하고 클러스터에 접속하기 위한 -인증정보를 가져야 한다. 일반적으로 이는 당신이 -[Getting started guide](/ko/docs/setup/)를 다 진행했을 때 자동으로 구성되거나, +클러스터에 액세스하려면 클러스터의 위치정보를 알아야 하고 클러스터에 접속하기 위한 +인증정보를 가져야 한다. 일반적으로 이는 당신이 +[Getting started guide](/ko/docs/setup/)를 다 진행했을 때 자동으로 구성되거나, 다른 사람이 클러스터를 구성하고 당신에게 인증정보와 위치정보를 제공할 수도 있다. kubectl이 인지하는 위치정보와 인증정보는 다음 커맨드로 확인한다. @@ -29,13 +29,13 @@ kubectl이 인지하는 위치정보와 인증정보는 다음 커맨드로 확 kubectl config view ``` -많은 [예제들](/ko/docs/reference/kubectl/cheatsheet/)에서 kubectl을 사용하는 것을 소개하고 있으며 +많은 [예제들](/ko/docs/reference/kubectl/cheatsheet/)에서 kubectl을 사용하는 것을 소개하고 있으며 완전한 문서는 [kubectl manual](/docs/user-guide/kubectl-overview)에서 찾아볼 수 있다. ## REST API에 직접 액세스 -kubectl은 apiserver의 위치 파악과 인증을 처리한다. -만약 당신이 curl, wget 또는 웹브라우저와 같은 http 클라이언트로 +kubectl은 apiserver의 위치 파악과 인증을 처리한다. +만약 당신이 curl, wget 또는 웹브라우저와 같은 http 클라이언트로 REST API에 직접 액세스하려고 한다면 위치 파악과 인증을 하는 몇 가지 방법이 존재한다. - kubectl을 proxy 모드로 실행. @@ -51,8 +51,8 @@ REST API에 직접 액세스하려고 한다면 위치 파악과 인증을 하 ### kubectl proxy 사용 -다음 커맨드는 kubectl을 reverse proxy처럼 동작하는 모드를 실행한다. 이는 -apiserver의 위치지정과 인증을 처리한다. +다음 커맨드는 kubectl을 reverse proxy처럼 동작하는 모드를 실행한다. 이는 +apiserver의 위치지정과 인증을 처리한다. 다음과 같이 실행한다. ```shell @@ -61,7 +61,7 @@ kubectl proxy --port=8080 상세 내용은 [kubectl proxy](/docs/reference/generated/kubectl/kubectl-commands/#proxy)를 참조한다 -이후에 당신은 curl, wget, 웹브라우저로 다음과 같이 API를 탐색할 수 있다. localhost는 +이후에 당신은 curl, wget, 웹브라우저로 다음과 같이 API를 탐색할 수 있다. localhost는 IPv6 주소 [::1]로도 대체할 수 있다. ```shell @@ -142,22 +142,22 @@ curl $APISERVER/api --header "Authorization: Bearer $TOKEN" --insecure } ``` -위 예제에서는 `--insecure` flag를 사용했다. 이는 MITM 공격을 받을 수 있는 상태로 -두는 것이다. kubectl로 클러스터에 접속할 때 저장된 root 인증서와 클라이언트 인증서들을 +위 예제에서는 `--insecure` flag를 사용했다. 이는 MITM 공격을 받을 수 있는 상태로 +두는 것이다. kubectl로 클러스터에 접속할 때 저장된 root 인증서와 클라이언트 인증서들을 서버 접속에 사용한다. -(이들은 `~/.kube` 디렉토리에 설치된다.) -일반적으로 self-signed 인증서가 클러스터 인증서로 사용되므로 당신의 http 클라이언트가 +(이들은 `~/.kube` 디렉터리에 설치된다.) +일반적으로 self-signed 인증서가 클러스터 인증서로 사용되므로 당신의 http 클라이언트가 root 인증서를 사용하려면 특수한 설정을 필요로 할 것이다. -localhost에서 제공되거나 방화벽으로 보호되는 몇몇 클러스터들에서는 apiserver가 인증을 -요구하지 않지만 이는 표준이 아니다. +localhost에서 제공되거나 방화벽으로 보호되는 몇몇 클러스터들에서는 apiserver가 인증을 +요구하지 않지만 이는 표준이 아니다. [Configuring Access to the API](/docs/reference/access-authn-authz/controlling-access/) -는 클러스터 관리자가 이를 어떻게 구성할 수 있는지를 설명한다. +는 클러스터 관리자가 이를 어떻게 구성할 수 있는지를 설명한다. 이 방식들은 미래의 고가용성 지원과 충돌될 수 있다. ## API에 프로그래밍 방식으로 액세스 -쿠버네티스는 공식적으로 [Go](#go-클라이언트)와 [Python](#python-클라이언트) +쿠버네티스는 공식적으로 [Go](#go-클라이언트)와 [Python](#python-클라이언트) 클라이언트 라이브러리를 지원한다. ### Go 클라이언트 @@ -165,7 +165,7 @@ localhost에서 제공되거나 방화벽으로 보호되는 몇몇 클러스터 * 라이브러리를 취득하려면 `go get k8s.io/client-go@kubernetes-<kubernetes-version-number>` 커맨드를 실행한다. [INSTALL.md](https://github.com/kubernetes/client-go/blob/master/INSTALL.md#for-the-casual-user)에서 상세한 설치 방법을 알 수 있다. [https://github.com/kubernetes/client-go](https://github.com/kubernetes/client-go#compatibility-matrix)에서 어떤 버젼이 지원되는지 확인할 수 있다. * client-go 클라이언트 위에 애플리케이션을 작성하자. client-go는 자체적으로 API 오브젝트를 정의하므로 필요하다면 main 레포지터리보다는 client-go에서 API 정의들을 import하기를 바란다. 정확하게 `import "k8s.io/client-go/kubernetes"`로 import하는 것을 예로 들 수 있다. -Go 클라이언트는 apiserver의 위치지정과 인증에 kubectl CLI와 동일하게 [kubeconfig file](/docs/concepts/cluster-administration/authenticate-across-clusters-kubeconfig/)을 사용할 수 있다. +Go 클라이언트는 apiserver의 위치지정과 인증에 kubectl CLI와 동일하게 [kubeconfig file](/docs/concepts/cluster-administration/authenticate-across-clusters-kubeconfig/)을 사용할 수 있다. [예제](https://git.k8s.io/client-go/examples/out-of-cluster-client-configuration/main.go)를 참고한다. 만약 애플리케이션이 클러스터 내에 파드로 배포되었다면 [다음 장](#파드에서-api-액세스)을 참조하기를 바란다. @@ -174,7 +174,7 @@ Go 클라이언트는 apiserver의 위치지정과 인증에 kubectl CLI와 동 Python 클라이언트를 사용하려면 `pip install kubernetes` 커맨드를 실행한다. 설치 옵션에 대한 상세 사항은 [Python Client Library page](https://github.com/kubernetes-client/python)를 참조한다. -Python 클라이언트는 apiserver의 위치지정과 인증에 kubectl CLI와 동일하게 [kubeconfig file](/docs/concepts/cluster-administration/authenticate-across-clusters-kubeconfig/)을 사용할 수 있다. +Python 클라이언트는 apiserver의 위치지정과 인증에 kubectl CLI와 동일하게 [kubeconfig file](/docs/concepts/cluster-administration/authenticate-across-clusters-kubeconfig/)을 사용할 수 있다. [예제](https://github.com/kubernetes-client/python/tree/master/examples)를 참조한다. ### 다른 언어 @@ -184,44 +184,44 @@ Python 클라이언트는 apiserver의 위치지정과 인증에 kubectl CLI와 ## 파드에서 API 액세스 -파드에서 API를 접속한다면 apiserver의 +파드에서 API를 접속한다면 apiserver의 위치지정과 인증은 다소 다르다. -파드 내에서 apiserver의 위치를 지정하는데 추천하는 방식은 -`kubernetes.default.svc` DNS 네임을 사용하는 것이다. +파드 내에서 apiserver의 위치를 지정하는데 추천하는 방식은 +`kubernetes.default.svc` DNS 네임을 사용하는 것이다. 이 DNS 네임은 apiserver로 라우팅되는 서비스 IP로 resolve된다. -apiserver 인증에 추천되는 방식은 -[서비스 어카운트](/docs/tasks/configure-pod-container/configure-service-account/) -인증정보를 사용하는 것이다. kube-system에 의해 파드는 서비스 어카운트와 연계되며 -해당 서비스 어카운트의 인증정보(토큰)은 파드 내 각 컨테이너의 파일시스템 트리의 +apiserver 인증에 추천되는 방식은 +[서비스 어카운트](/docs/tasks/configure-pod-container/configure-service-account/) +인증정보를 사용하는 것이다. kube-system에 의해 파드는 서비스 어카운트와 연계되며 +해당 서비스 어카운트의 인증정보(토큰)은 파드 내 각 컨테이너의 파일시스템 트리의 `/var/run/secrets/kubernetes.io/serviceaccount/token`에 위치한다. -사용 가능한 경우, 인증서 번들은 각 컨테이너 내 파일시스템 트리의 -`/var/run/secrets/kubernetes.io/serviceaccount/ca.crt`에 위치하며 +사용 가능한 경우, 인증서 번들은 각 컨테이너 내 파일시스템 트리의 +`/var/run/secrets/kubernetes.io/serviceaccount/ca.crt`에 위치하며 apiserver의 인증서 제공을 검증하는데 사용되어야 한다. -마지막으로 네임스페이스 한정의 API 조작에 사용되는 기본 네임스페이스는 각 컨테이터 내의 +마지막으로 네임스페이스 한정의 API 조작에 사용되는 기본 네임스페이스는 각 컨테이터 내의 `/var/run/secrets/kubernetes.io/serviceaccount/namespace` 파일로 존재한다. 파드 내에서 API에 접근하는데 권장되는 방식은 다음과 같다. - - 파드의 sidecar 컨테이너 내에서 `kubectl proxy`를 실행하거나, - 컨테이너 내부에서 백그라운드 프로세스로 실행한다. - 이는 쿠버네티스 API를 파드의 localhost 인터페이스로 proxy하여 + - 파드의 sidecar 컨테이너 내에서 `kubectl proxy`를 실행하거나, + 컨테이너 내부에서 백그라운드 프로세스로 실행한다. + 이는 쿠버네티스 API를 파드의 localhost 인터페이스로 proxy하여 해당 파드의 컨테이너 내에 다른 프로세스가 API에 접속할 수 있게 해준다. - - Go 클라이언트 라이브러리를 이용하여 `rest.InClusterConfig()`와 `kubernetes.NewForConfig()` 함수들을 사용하도록 클라이언트를 만든다. + - Go 클라이언트 라이브러리를 이용하여 `rest.InClusterConfig()`와 `kubernetes.NewForConfig()` 함수들을 사용하도록 클라이언트를 만든다. 이는 apiserver의 위치지정과 인증을 처리한다. [예제](https://git.k8s.io/client-go/examples/in-cluster-client-configuration/main.go) 각각의 사례에서 apiserver와의 보안 통신에 파드의 인증정보가 사용된다. ## 클러스터에서 실행되는 서비스로 액세스 -이전 장은 쿠버네티스 API server 접속에 대한 내용을 다루었다. 이번 장은 -쿠버네티스 클러스터 상에서 실행되는 다른 서비스로의 연결을 다룰 것이다. 쿠버네티스에서 -[노드들](/ko/docs/concepts/architecture/nodes/), [파드들](/ko/docs/concepts/workloads/pods/pod/), [서비스들](/docs/user-guide/services)은 -모두 자신의 IP들을 가진다. 당신의 데스크탑 PC와 같은 클러스터 외부 장비에서는 -클러스터 상의 노드 IP들, 파드 IP들, 서비스 IP들로 라우팅되지 않아서 접근을 +이전 장은 쿠버네티스 API server 접속에 대한 내용을 다루었다. 이번 장은 +쿠버네티스 클러스터 상에서 실행되는 다른 서비스로의 연결을 다룰 것이다. 쿠버네티스에서 +[노드들](/ko/docs/concepts/architecture/nodes/), [파드들](/ko/docs/concepts/workloads/pods/pod/), [서비스들](/docs/user-guide/services)은 +모두 자신의 IP들을 가진다. 당신의 데스크탑 PC와 같은 클러스터 외부 장비에서는 +클러스터 상의 노드 IP들, 파드 IP들, 서비스 IP들로 라우팅되지 않아서 접근을 할 수 없을 것이다. ### 통신을 위한 방식들 @@ -229,33 +229,33 @@ apiserver의 인증서 제공을 검증하는데 사용되어야 한다. 클러스터 외부에서 노드들, 파드들, 서비스들에 접속하는 데는 몇 가지 선택지들이 있다. - 공인 IP를 통해 서비스에 액세스. - - 클러스터 외부에서 접근할 수 있도록 `NodePort` 또는 `LoadBalancer` 타입의 - 서비스를 사용한다. [서비스](/docs/user-guide/services)와 + - 클러스터 외부에서 접근할 수 있도록 `NodePort` 또는 `LoadBalancer` 타입의 + 서비스를 사용한다. [서비스](/docs/user-guide/services)와 [kubectl expose](/docs/reference/generated/kubectl/kubectl-commands/#expose) 문서를 참조한다. - - 당신의 클러스터 환경에 따라 회사 네트워크에만 서비스를 노출하거나 - 인터넷으로 노출할 수 있다. 이 경우 노출되는 서비스의 보안 여부를 고려해야 한다. + - 당신의 클러스터 환경에 따라 회사 네트워크에만 서비스를 노출하거나 + 인터넷으로 노출할 수 있다. 이 경우 노출되는 서비스의 보안 여부를 고려해야 한다. 해당 서비스는 자체적으로 인증을 수행하는가? - - 파드들은 서비스 뒤에 위치시킨다. 레플리카들의 집합에서 특정 파드 하나에 debugging 같은 목적으로 접근하려면 + - 파드들은 서비스 뒤에 위치시킨다. 레플리카들의 집합에서 특정 파드 하나에 debugging 같은 목적으로 접근하려면 해당 파드에 고유의 레이블을 붙이고 셀렉터에 해당 레이블을 선택한 신규 서비스를 생성한다. - - 대부분의 경우에는 애플리케이션 개발자가 노드 IP를 통해 직접 노드에 + - 대부분의 경우에는 애플리케이션 개발자가 노드 IP를 통해 직접 노드에 액세스할 필요는 없다. - Proxy Verb를 사용하여 서비스, 노드, 파드에 액세스. - - 원격 서비스에 액세스하기에 앞서 apiserver의 인증과 인가를 받아야 한다. - 서비스가 인터넷에 노출하기에 보안이 충분하지 않거나 노드 IP 상의 port에 + - 원격 서비스에 액세스하기에 앞서 apiserver의 인증과 인가를 받아야 한다. + 서비스가 인터넷에 노출하기에 보안이 충분하지 않거나 노드 IP 상의 port에 액세스를 취득하려고 하거나 debugging을 하려면 이를 사용한다. - 어떤 web 애플리케이션에서는 proxy가 문제를 일으킬 수 있다. - HTTP/HTTPS에서만 동작한다. - [여기](#수작업으로-apiserver-proxy-url들을-구축)에서 설명하고 있다. - 클러스터 내 노드 또는 파드에서 액세스. - - 파드를 Running시킨 다음 [kubectl exec](/docs/reference/generated/kubectl/kubectl-commands/#exec)를 사용하여 해당 파드의 셸로 접속한다. + - 파드를 Running시킨 다음 [kubectl exec](/docs/reference/generated/kubectl/kubectl-commands/#exec)를 사용하여 해당 파드의 셸로 접속한다. 해당 셸에서 다른 노드들, 파드들, 서비스들에 연결한다. - - 어떤 클러스터는 클러스터 내의 노드에 ssh 접속을 허용하기도 한다. 이런 클러스터에서는 - 클러스터 서비스에 액세스도 가능하다. 이는 비표준 방식으로 특정 클러스터에서는 동작하지만 + - 어떤 클러스터는 클러스터 내의 노드에 ssh 접속을 허용하기도 한다. 이런 클러스터에서는 + 클러스터 서비스에 액세스도 가능하다. 이는 비표준 방식으로 특정 클러스터에서는 동작하지만 다른 클러스터에서는 동작하지 않을 수 있다. 브라우저와 다른 도구들이 설치되지 않았거나 설치되었을 수 있다. 클러스터 DNS가 동작하지 않을 수도 있다. ### 빌트인 서비스들의 발견 -일반적으로 kube-system에 의해 클러스터 상에서 start되는 몇 가지 서비스들이 존재한다. +일반적으로 kube-system에 의해 클러스터 상에서 start되는 몇 가지 서비스들이 존재한다. `kubectl cluster-info` 커맨드로 이 서비스들의 리스트를 볼 수 있다. ```shell @@ -273,15 +273,15 @@ grafana is running at https://104.197.5.247/api/v1/namespaces/kube-system/servic heapster is running at https://104.197.5.247/api/v1/namespaces/kube-system/services/monitoring-heapster/proxy ``` -이는 각 서비스에 액세스하기 위한 proxy-verb URL을 보여준다. -예를 들어 위 클러스터는 클러스터 수준의 logging(Elasticsearch 사용)이 활성화되었으므로 적절한 인증을 통과하여 -`https://104.197.5.247/api/v1/namespaces/kube-system/services/elasticsearch-logging/proxy/`로 액세스할 수 있다. 예를 들어 kubectl proxy로 +이는 각 서비스에 액세스하기 위한 proxy-verb URL을 보여준다. +예를 들어 위 클러스터는 클러스터 수준의 logging(Elasticsearch 사용)이 활성화되었으므로 적절한 인증을 통과하여 +`https://104.197.5.247/api/v1/namespaces/kube-system/services/elasticsearch-logging/proxy/`로 액세스할 수 있다. 예를 들어 kubectl proxy로 `http://localhost:8080/api/v1/namespaces/kube-system/services/elasticsearch-logging/proxy/`를 통해 logging에 액세스할 수도 있다. -(인증을 통과하는 방법이나 kubectl proxy를 사용하는 것은 [쿠버네티스 API를 사용해서 클러스터에 접근하기](/docs/tasks/administer-cluster/access-cluster-api/)을 참조한다.) +(인증을 통과하는 방법이나 kubectl proxy를 사용하는 것은 [쿠버네티스 API를 사용해서 클러스터에 접근하기](/ko/docs/tasks/administer-cluster/access-cluster-api/)을 참조한다.) #### 수작업으로 apiserver proxy URL을 구축 -위에서 언급한 것처럼 서비스의 proxy URL을 검색하는데 `kubectl cluster-info` 커맨드를 사용할 수 있다. 서비스 endpoint, 접미사, 매개변수를 포함하는 proxy URL을 생성하려면 단순하게 해당 서비스에 +위에서 언급한 것처럼 서비스의 proxy URL을 검색하는데 `kubectl cluster-info` 커맨드를 사용할 수 있다. 서비스 endpoint, 접미사, 매개변수를 포함하는 proxy URL을 생성하려면 단순하게 해당 서비스에 `http://`*`kubernetes_master_address`*`/api/v1/namespaces/`*`namespace_name`*`/services/`*`service_name[:port_name]`*`/proxy` 형식의 proxy URL을 덧붙인다. 당신이 port에 이름을 지정하지 않았다면 URL에 *port_name* 을 지정할 필요는 없다. @@ -300,7 +300,7 @@ URL의 네임 부분에 지원되는 양식은 다음과 같다. * Elasticsearch 서비스 endpoint `_search?q=user:kimchy`에 액세스하려면 `http://104.197.5.247/api/v1/namespaces/kube-system/services/elasticsearch-logging/proxy/_search?q=user:kimchy`를 사용할 수 있다. * Elasticsearch 클러스터 상태 정보 `_cluster/health?pretty=true`에 액세스하려면 `https://104.197.5.247/api/v1/namespaces/kube-system/services/elasticsearch-logging/proxy/_cluster/health?pretty=true`를 사용할 수 있다. - + ```json { "cluster_name" : "kubernetes_logging", @@ -320,9 +320,9 @@ URL의 네임 부분에 지원되는 양식은 다음과 같다. 브라우저의 주소창에 apiserver proxy url을 넣을 수도 있다. 하지만 - - 웹브라우저는 일반적으로 토큰을 전달할 수 없으므로 basic (password) auth를 사용해야 할 것이다. basic auth를 수용할 수 있도록 apiserver를 구성할 수 있지만, + - 웹브라우저는 일반적으로 토큰을 전달할 수 없으므로 basic (password) auth를 사용해야 할 것이다. basic auth를 수용할 수 있도록 apiserver를 구성할 수 있지만, 당신의 클러스터가 basic auth를 수용할 수 있도록 구성되어 있지 않을 수도 있다. - - 몇몇 web app은 동작하지 않을 수도 있다. 특히 proxy path prefix를 인식하지 않는 방식으로 url을 + - 몇몇 web app은 동작하지 않을 수도 있다. 특히 proxy path prefix를 인식하지 않는 방식으로 url을 구성하는 client side javascript를 가진 web app은 동작하지 않을 수 있다. ## 요청 redirect @@ -373,7 +373,5 @@ redirect 기능은 deprecated되고 제거 되었다. 대신 (아래의) proxy - UDP/TCP 만 사용한다 - cloud provider마다 구현된 내용이 상이하다 -일반적으로 쿠버네티스 사용자들은 처음 두 타입이 아닌 다른 방식은 고려할 필요가 없지만 클러스터 관리자는 +일반적으로 쿠버네티스 사용자들은 처음 두 타입이 아닌 다른 방식은 고려할 필요가 없지만 클러스터 관리자는 나머지 타입을 적절하게 구성해줘야 한다. - - diff --git a/content/ko/docs/tasks/access-application-cluster/communicate-containers-same-pod-shared-volume.md b/content/ko/docs/tasks/access-application-cluster/communicate-containers-same-pod-shared-volume.md index 9c70cbe8b1..5a585eddd4 100644 --- a/content/ko/docs/tasks/access-application-cluster/communicate-containers-same-pod-shared-volume.md +++ b/content/ko/docs/tasks/access-application-cluster/communicate-containers-same-pod-shared-volume.md @@ -6,7 +6,7 @@ weight: 110 <!-- overview --> -이 페이지에서는 동일한 파드(Pod)에서 실행 중인 두 개의 컨테이너 간에 통신할 때에, 어떻게 볼륨(Volume)을 이용하는지 +이 페이지에서는 동일한 파드에서 실행 중인 두 개의 컨테이너 간에 통신할 때에, 어떻게 볼륨을 이용하는지 살펴본다. 컨테이너 간에 [프로세스 네임스페이스 공유하기](/docs/tasks/configure-pod-container/share-process-namespace/)를 통해 통신할 수 있는 방법을 참고하자. @@ -139,7 +139,7 @@ Debian 컨테이너에서 nginx 웹 서버가 호스팅하는 문서의 루트 * [모듈 구조를 위한 합성 컨테이너 구조](http://www.slideshare.net/Docker/slideshare-burns)에 관하여 더 공부한다. -* [파드에서 저장소로 볼룸을 사용하도록 구성하기](/docs/tasks/configure-pod-container/configure-volume-storage/)에 관하여 +* [파드에서 저장소로 볼룸을 사용하도록 구성하기](/ko/docs/tasks/configure-pod-container/configure-volume-storage/)에 관하여 확인한다. * [파드에서 컨테이너 간에 프로세스 네임스페이스를 공유하는 파드 구성하는 방법](/docs/tasks/configure-pod-container/share-process-namespace/)을 참고한다. @@ -147,8 +147,3 @@ Debian 컨테이너에서 nginx 웹 서버가 호스팅하는 문서의 루트 * [볼륨](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#volume-v1-core)을 확인한다. * [파드](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#pod-v1-core)을 확인한다. - - - - - diff --git a/content/ko/docs/tasks/access-application-cluster/configure-access-multiple-clusters.md b/content/ko/docs/tasks/access-application-cluster/configure-access-multiple-clusters.md index 4fa9a9492a..9f99c6acbd 100644 --- a/content/ko/docs/tasks/access-application-cluster/configure-access-multiple-clusters.md +++ b/content/ko/docs/tasks/access-application-cluster/configure-access-multiple-clusters.md @@ -10,14 +10,14 @@ card: <!-- overview --> -이 페이지에서는 구성 파일을 사용하여 다수의 클러스터에 접근할 수 있도록 -설정하는 방식을 보여준다. 클러스터, 사용자, 컨텍스트가 하나 이상의 -구성 파일에 정의된 다음 `kubectl config use-context` 커맨드를 +이 페이지에서는 구성 파일을 사용하여 다수의 클러스터에 접근할 수 있도록 +설정하는 방식을 보여준다. 클러스터, 사용자, 컨텍스트가 하나 이상의 +구성 파일에 정의된 다음 `kubectl config use-context` 커맨드를 사용하여 클러스터를 빠르게 변경할 수 있다. {{< note >}} -클러스터에 접근할 수 있도록 설정하는데 사용되는 파일은 종종 *kubeconfig file* 이라고 -불린다. 이는 구성 파일을 참조하는 일반적인 방식으로 `kubeconfig`라는 이름을 가진 파일이 +클러스터에 접근할 수 있도록 설정하는데 사용되는 파일은 종종 *kubeconfig file* 이라고 +불린다. 이는 구성 파일을 참조하는 일반적인 방식으로 `kubeconfig`라는 이름을 가진 파일이 반드시 존재해야 한다는 것을 의미하는 것은 아니다. {{< /note >}} @@ -26,7 +26,12 @@ card: ## {{% heading "prerequisites" %}} -{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}} +{{< include "task-tutorial-prereqs.md" >}} + +{{< glossary_tooltip text="kubectl" term_id="kubectl" >}}이 설치되었는지 확인하려면, +`kubectl version --client`을 실행한다. kubectl 버전은 클러스터의 API 서버 버전과 +[마이너 버전 하나 차이 이내](/ko/docs/setup/release/version-skew-policy/#kubectl)여야 +한다. @@ -34,14 +39,14 @@ card: ## 클러스터, 사용자, 컨텍스트 정의 -당신이 개발 작업을 위한 클러스터와 스크래치 작업을 위한 클러스터를 가지고 있다고 가정해보자. -`development` 클러스터에서는 프런트 엔드 개발자들이 `frontend`라는 네임스페이스에서 -작업을 하고 있고, 스토리지 개발자들은 `storage`라는 네임스페이스에서 작업을 하고 있다. -`scratch` 클러스터에서는 개발자들이 default 네임스페이스에서 개발하거나 필요에 따라 보조 -네임스페이스들을 생성하고 있다. development 클러스터에 접근하려면 인증서로 인증을 해야 하고, +당신이 개발 작업을 위한 클러스터와 스크래치 작업을 위한 클러스터를 가지고 있다고 가정해보자. +`development` 클러스터에서는 프런트 엔드 개발자들이 `frontend`라는 네임스페이스에서 +작업을 하고 있고, 스토리지 개발자들은 `storage`라는 네임스페이스에서 작업을 하고 있다. +`scratch` 클러스터에서는 개발자들이 default 네임스페이스에서 개발하거나 필요에 따라 보조 +네임스페이스들을 생성하고 있다. development 클러스터에 접근하려면 인증서로 인증을 해야 하고, scratch 클러스터에 접근하려면 사용자네임과 패스워드로 인증을 해야 한다. -`config-exercise`라는 디렉토리를 생성한다. `config-exercise` 디렉토리에 +`config-exercise`라는 디렉터리를 생성한다. `config-exercise` 디렉터리에 다음 내용을 가진 `config-demo`라는 파일을 생성한다. ```shell @@ -68,10 +73,10 @@ contexts: name: exp-scratch ``` -구성 파일은 클러스터들, 사용자들, 컨텍스트들을 기술한다. `config-demo` 파일은 두 클러스터들과 +구성 파일은 클러스터들, 사용자들, 컨텍스트들을 기술한다. `config-demo` 파일은 두 클러스터들과 두 사용자들, 세 컨텍스트들을 기술하기 위한 프레임워크를 가진다. -`config-exercise` 디렉토리로 이동한다. 그리고 다음 커맨드들을 실행하여 구성 파일에 클러스터의 +`config-exercise` 디렉터리로 이동한다. 그리고 다음 커맨드들을 실행하여 구성 파일에 클러스터의 세부사항들을 추가한다. ```shell @@ -100,7 +105,7 @@ kubectl config --kubeconfig=config-demo set-context dev-storage --cluster=develo kubectl config --kubeconfig=config-demo set-context exp-scratch --cluster=scratch --namespace=default --user=experimenter ``` -`config-demo` 파일을 열어서 세부사항들이 추가되었는지 확인한다. `config-demo` 파일을 열어보는 +`config-demo` 파일을 열어서 세부사항들이 추가되었는지 확인한다. `config-demo` 파일을 열어보는 것 대신에 `config view` 커맨드를 사용할 수도 있다. ```shell @@ -150,16 +155,16 @@ users: username: exp ``` -위 `fake-ca-file`, `fake-cert-file`, `fake-key-file`은 인증서 파일들의 실제 경로 이름을 위한 -플레이스홀더(placeholder)이다. +위 `fake-ca-file`, `fake-cert-file`, `fake-key-file`은 인증서 파일들의 실제 경로 이름을 위한 +플레이스홀더(placeholder)이다. 당신의 환경에 맞게 이들을 실제 인증서 경로로 변경해줘야 한다. -만약 당신이 인증서 파일들의 경로 대신에 여기에 포함된 base64로 인코딩된 데이터를 사용하려고 한다면 -이 경우 키에 `-data` 접미사를 추가해야 한다. 예를 들면 `certificate-authority-data`, +만약 당신이 인증서 파일들의 경로 대신에 여기에 포함된 base64로 인코딩된 데이터를 사용하려고 한다면 +이 경우 키에 `-data` 접미사를 추가해야 한다. 예를 들면 `certificate-authority-data`, `client-certificate-data`, `client-key-data` 같이 사용할 수 있다. -컨텍스트는 세 가지(클러스터, 사용자, 네임스페이스) 요소들로 이뤄진다. 예를 들어 -`dev-frontend` 컨텍스트는 "`development` 클러스터의 `frontend` 네임스페이스에 접근하는데 +컨텍스트는 세 가지(클러스터, 사용자, 네임스페이스) 요소들로 이뤄진다. 예를 들어 +`dev-frontend` 컨텍스트는 "`development` 클러스터의 `frontend` 네임스페이스에 접근하는데 `developer` 사용자 자격증명을 사용하라고 알려준다." 현재 컨텍스트를 설정한다. @@ -168,11 +173,11 @@ users: kubectl config --kubeconfig=config-demo use-context dev-frontend ``` -이제 당신이 `kubectl` 커맨드를 입력할 때마다 `dev-frontend` 컨텍스트에 명시된 클러스터와 -네임스페이스 상에서 동작하게 될 것이다. 그리고 커맨드는 `dev-frontend` 컨텍스트 내에 명시된 +이제 당신이 `kubectl` 커맨드를 입력할 때마다 `dev-frontend` 컨텍스트에 명시된 클러스터와 +네임스페이스 상에서 동작하게 될 것이다. 그리고 커맨드는 `dev-frontend` 컨텍스트 내에 명시된 사용자 자격증명을 사용할 것이다. -현재 컨텍스트에 관련된 구성 정보만을 보려면 +현재 컨텍스트에 관련된 구성 정보만을 보려면 `--minify` 플래그를 사용한다. ```shell @@ -212,8 +217,8 @@ users: kubectl config --kubeconfig=config-demo use-context exp-scratch ``` -이제 당신이 실행하는 모든 `kubectl` 커맨드는 `scratch` 클러스터의 -default 네임스페이스에 적용되며 `exp-scratch` 컨텍스트에 나열된 +이제 당신이 실행하는 모든 `kubectl` 커맨드는 `scratch` 클러스터의 +default 네임스페이스에 적용되며 `exp-scratch` 컨텍스트에 나열된 사용자의 자격증명을 사용할 것이다. 현재의 컨텍스트인 `exp-scratch`에 관련된 설정을 보자. @@ -222,7 +227,7 @@ default 네임스페이스에 적용되며 `exp-scratch` 컨텍스트에 나열 kubectl config --kubeconfig=config-demo view --minify ``` -마지막으로 당신이 `development` 클러스터의 `storage` 네임스페이스에서 +마지막으로 당신이 `development` 클러스터의 `storage` 네임스페이스에서 잠시 작업을 하려고 한다고 가정해보자. 현재 컨텍스트를 `dev-storage`로 변경한다. @@ -240,7 +245,7 @@ kubectl config --kubeconfig=config-demo view --minify ## 두 번째 구성 파일 생성 -`config-exercise` 디렉토리에서 다음 내용으로 `config-demo-2`라는 파일을 생성한다. +`config-exercise` 디렉터리에서 다음 내용으로 `config-demo-2`라는 파일을 생성한다. ```shell apiVersion: v1 @@ -259,43 +264,43 @@ contexts: ## KUBECONFIG 환경 변수 설정 -`KUBECONFIG`라는 환경 변수를 가지고 있는지 확인해보자. 만약 가지고 있다면, +`KUBECONFIG`라는 환경 변수를 가지고 있는지 확인해보자. 만약 가지고 있다면, 이후에 복원할 수 있도록 `KUBECONFIG` 환경 변수의 현재 값을 저장한다. 예: -### Linux +### 리눅스 ```shell export KUBECONFIG_SAVED=$KUBECONFIG ``` -### Windows PowerShell +### 윈도우 PowerShell ```shell $Env:KUBECONFIG_SAVED=$ENV:KUBECONFIG ``` -`KUBECONFIG` 환경 변수는 구성 파일들의 경로의 리스트이다. 이 리스트는 -Linux와 Mac에서는 콜론으로 구분되며 Windows에서는 세미콜론으로 구분된다. -`KUBECONFIG` 환경 변수를 가지고 있다면, 리스트에 포함된 구성 파일들에 +`KUBECONFIG` 환경 변수는 구성 파일들의 경로의 리스트이다. 이 리스트는 +리눅스와 Mac에서는 콜론으로 구분되며 윈도우에서는 세미콜론으로 구분된다. +`KUBECONFIG` 환경 변수를 가지고 있다면, 리스트에 포함된 구성 파일들에 익숙해지길 바란다. 다음 예와 같이 임시로 `KUBECONFIG` 환경 변수에 두 개의 경로들을 덧붙여보자. -### Linux +### 리눅스 ```shell export KUBECONFIG=$KUBECONFIG:config-demo:config-demo-2 ``` -### Windows PowerShell +### 윈도우 PowerShell ```shell $Env:KUBECONFIG=("config-demo;config-demo-2") ``` -`config-exercise` 디렉토리에서 다음 커맨드를 입력한다. +`config-exercise` 디렉터리에서 다음 커맨드를 입력한다. ```shell kubectl config view ``` -당신의 `KUBECONFIG` 환경 변수에 나열된 모든 파일들이 합쳐진 정보가 출력 결과로 -표시될 것이다. 특히, 합쳐진 정보가 `config-demo-2` 파일의 `dev-ramp-up` -컨텍스트와 `config-demo` 파일의 세 개의 컨텍스트들을 +당신의 `KUBECONFIG` 환경 변수에 나열된 모든 파일들이 합쳐진 정보가 출력 결과로 +표시될 것이다. 특히, 합쳐진 정보가 `config-demo-2` 파일의 `dev-ramp-up` +컨텍스트와 `config-demo` 파일의 세 개의 컨텍스트들을 가지고 있다는 것에 주목하길 바란다. ```shell @@ -322,36 +327,36 @@ contexts: name: exp-scratch ``` -kubeconfig 파일들을 어떻게 병합하는지에 대한 상세정보는 +kubeconfig 파일들을 어떻게 병합하는지에 대한 상세정보는 [kubeconfig 파일을 사용하여 클러스터 접근 구성하기](/ko/docs/concepts/configuration/organize-cluster-access-kubeconfig/)를 참조한다. -## $HOME/.kube 디렉토리 탐색 +## $HOME/.kube 디렉터리 탐색 -만약 당신이 이미 클러스터를 가지고 있고 `kubectl`을 사용하여 -해당 클러스터를 제어하고 있다면, 아마 `$HOME/.kube` 디렉토리에 `config`라는 +만약 당신이 이미 클러스터를 가지고 있고 `kubectl`을 사용하여 +해당 클러스터를 제어하고 있다면, 아마 `$HOME/.kube` 디렉터리에 `config`라는 파일을 가지고 있을 것이다. -`$HOME/.kube`로 가서 어떤 파일들이 존재하는지 보자. -보통 `config`라는 파일이 존재할 것이다. 해당 디렉토리 내에는 다른 구성 파일들도 있을 수 있다. +`$HOME/.kube`로 가서 어떤 파일들이 존재하는지 보자. +보통 `config`라는 파일이 존재할 것이다. 해당 디렉터리 내에는 다른 구성 파일들도 있을 수 있다. 간단하게 말하자면 당신은 이 파일들의 컨텐츠에 익숙해져야 한다. ## $HOME/.kube/config를 KUBECONFIG 환경 변수에 추가 -당신이 `$HOME/.kube/config` 파일을 가지고 있는데 `KUBECONFIG` +당신이 `$HOME/.kube/config` 파일을 가지고 있는데 `KUBECONFIG` 환경 변수에 나타나지 않는다면 `KUBECONFIG` 환경 변수에 추가해보자. 예: -### Linux +### 리눅스 ```shell export KUBECONFIG=$KUBECONFIG:$HOME/.kube/config ``` -### Windows Powershell +### 윈도우 Powershell ```shell $Env:KUBECONFIG="$Env:KUBECONFIG;$HOME\.kube\config" ``` -이제 `KUBECONFIG` 환경 변수에 리스트에 포함된 모든 파일들이 합쳐진 구성 정보를 보자. -config-exercise 디렉토리에서 다음 커맨드를 실행한다. +이제 `KUBECONFIG` 환경 변수에 리스트에 포함된 모든 파일들이 합쳐진 구성 정보를 보자. +config-exercise 디렉터리에서 다음 커맨드를 실행한다. ```shell kubectl config view @@ -361,12 +366,12 @@ kubectl config view `KUBECONFIG` 환경 변수를 원래 값으로 되돌려 놓자. 예를 들면:<br> -### Linux +### 리눅스 ```shell export KUBECONFIG=$KUBECONFIG_SAVED ``` -### Windows PowerShell +### 윈도우 PowerShell ```shell $Env:KUBECONFIG=$ENV:KUBECONFIG_SAVED ``` diff --git a/content/ko/docs/tasks/access-application-cluster/configure-dns-cluster.md b/content/ko/docs/tasks/access-application-cluster/configure-dns-cluster.md index eaace61131..5dde43a4f9 100644 --- a/content/ko/docs/tasks/access-application-cluster/configure-dns-cluster.md +++ b/content/ko/docs/tasks/access-application-cluster/configure-dns-cluster.md @@ -8,6 +8,4 @@ content_type: concept 쿠버네티스는 지원하는 모든 환경에서 기본으로 활성화된 DNS 클러스터 애드온을 제공한다. 쿠버네티스 1.11과 이후 버전에서는, CoreDNS가 권장되고 기본적으로 kubeadm과 함께 설치 된다. <!-- body --> -쿠버네티스 클러스터의 CoreDNS 설정에 대한 더 많은 정보는, [DNS 서비스 사용자화 하기](/docs/tasks/administer-cluster/dns-custom-nameservers/)을 본다. kube-dns와 함께 쿠버네티스 DNS를 사용하는 방법을 보여주는 예시는 [쿠버네티스 DNS 샘플 플러그인](https://github.com/kubernetes/examples/tree/master/staging/cluster-dns)을 본다. - - +쿠버네티스 클러스터의 CoreDNS 설정에 대한 더 많은 정보는, [DNS 서비스 사용자화 하기](/ko/docs/tasks/administer-cluster/dns-custom-nameservers/)을 본다. kube-dns와 함께 쿠버네티스 DNS를 사용하는 방법을 보여주는 예시는 [쿠버네티스 DNS 샘플 플러그인](https://github.com/kubernetes/examples/tree/master/staging/cluster-dns)을 본다. diff --git a/content/ko/docs/tasks/access-application-cluster/service-access-application-cluster.md b/content/ko/docs/tasks/access-application-cluster/service-access-application-cluster.md new file mode 100644 index 0000000000..7565152bf0 --- /dev/null +++ b/content/ko/docs/tasks/access-application-cluster/service-access-application-cluster.md @@ -0,0 +1,158 @@ +--- +title: 클러스터 내 애플리케이션에 접근하기 위해 서비스 사용하기 +content_type: tutorial +weight: 60 +--- + +<!-- overview --> + +이 문서는 외부 클라이언트가 클러스터에서 실행 중인 애플리케이션에 접근하기 +위해 사용하는 쿠버네티스 서비스 오브젝트를 생성하는 방법을 설명한다. 서비스는 +실행 중인 두 개의 인스턴스를 갖는 애플리케이션에 대한 로드 밸런싱을 제공한다. + + + + +## {{% heading "prerequisites" %}} + + +{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}} + + + + +## {{% heading "objectives" %}} + + +* Hello World 애플리케이션 인스턴스 두 개를 실행한다. +* 노드 포트를 노출하는 서비스 오브젝트를 생성한다. +* 실행 중인 애플리케이션에 접근하기 위해 서비스 오브젝트를 사용한다. + + + + +<!-- lessoncontent --> + +## 두 개의 파드에서 실행 중인 애플리케이션에 대한 서비스 생성하기 + +다음은 애플리케이션 디플로이먼트(Deployment) 설정 파일이다. + +{{< codenew file="service/access/hello-application.yaml" >}} + +1. 클러스터 내 Hello World 애플리케이션을 실행하자. + 위 파일을 사용하여 애플리케이션 디플로이먼트를 생성하자. + ```shell + kubectl apply -f https://k8s.io/examples/service/access/hello-application.yaml + ``` + 앞의 명령은 + [디플로이먼트](/ko/docs/concepts/workloads/controllers/deployment/) + 오브젝트와 연관된 + [레플리카셋(ReplicaSet)](/ko/docs/concepts/workloads/controllers/replicaset/) + 오브젝트를 생성한다. 레플리카셋은 두 개의 + [파드](/ko/docs/concepts/workloads/pods/pod/)를 갖고, + 각각은 Hello World 애플리케이션을 실행한다. + +1. 디플로이먼트에 대한 정보를 보여준다. + ```shell + kubectl get deployments hello-world + kubectl describe deployments hello-world + ``` + +1. 레플리카셋 오브젝트에 대한 정보를 보여준다. + ```shell + kubectl get replicasets + kubectl describe replicasets + ``` + +1. 디플로이먼트를 노출하는 서비스 오브젝트를 생성한다. + ```shell + kubectl expose deployment hello-world --type=NodePort --name=example-service + ``` + +1. 서비스에 대한 정보를 보여준다. + ```shell + kubectl describe services example-service + ``` + 결과는 아래와 같다. + ```shell + Name: example-service + Namespace: default + Labels: run=load-balancer-example + Annotations: <none> + Selector: run=load-balancer-example + Type: NodePort + IP: 10.32.0.16 + Port: <unset> 8080/TCP + TargetPort: 8080/TCP + NodePort: <unset> 31496/TCP + Endpoints: 10.200.1.4:8080,10.200.2.5:8080 + Session Affinity: None + Events: <none> + ``` + 서비스의 노드포트(NodePort) 값을 메모하자. 예를 들어, + 앞선 결과에서, 노드포트 값은 31496이다. + +1. Hello World 애플리케이션이 실행 중인 파드를 나열한다. + ```shell + kubectl get pods --selector="run=load-balancer-example" --output=wide + ``` + 결과는 아래와 같다. + ```shell + NAME READY STATUS ... IP NODE + hello-world-2895499144-bsbk5 1/1 Running ... 10.200.1.4 worker1 + hello-world-2895499144-m1pwt 1/1 Running ... 10.200.2.5 worker2 + ``` +1. Hello World 파드가 실행 중인 노드들 중 하나의 노드에 대해 공용 + IP 주소를 얻자. 이 주소를 얻는 방법은 어떻게 클러스터를 설치했는지에 + 따라 다르다. 예를 들어, Minikube를 사용하면, `kubectl cluster-info`를 + 실행하여 노드 주소를 알 수 있다. Google Compute Engine 인스턴스를 + 사용하면, `gcloud compute instances list` 명령어를 + 사용하여 노드들의 공용 주소를 알 수 + 있다. + +1. 선택한 노드에서 노드 포트에 대해 TCP 통신을 허용하도록 방화벽 규칙을 + 생성하자. 예를 들어, 서비스의 노드포트 값이 31568인 경우, + 31568 포트로 TCP 통신을 허용하도록 방화벽 규칙을 생성하자. 다른 + 클라우드 공급자는 방화벽 규칙을 설정하는 다른 방법을 제공한다. + +1. Hello World 애플리케이션 접근을 위해 노드 주소와 노드 포트를 사용하자. + ```shell + curl http://<public-node-ip>:<node-port> + ``` + `<public-node-ip>`는 노드의 공용 IP 주소이고, + `<node-port>`는 서비스의 노드포트 값이다. + 성공적인 요청에 대한 응답은 hello 메시지이다. + ```shell + Hello Kubernetes! + ``` + +## 서비스 설정 파일 사용하기 + +`kubectl expose`를 사용하는 대신, +[서비스 설정 파일](/ko/docs/concepts/services-networking/service/)을 사용해 +서비스를 생성할 수 있다. + + + + +## {{% heading "cleanup" %}} + + +서비스를 삭제하기 위해 다음 명령어를 입력하자. + + kubectl delete services example-service + +디플로이먼트, 레플리카셋, Hello World 애플리케이션이 실행 중인 파드를 +삭제하기 위해 다음 명령어를 입력하자. + + kubectl delete deployment hello-world + + + + +## {{% heading "whatsnext" %}} + + +[서비스와 애플리케이션 연결하기](/ko/docs/concepts/services-networking/connect-applications-service/)에 +대해 더 알아본다. + diff --git a/content/ko/docs/tasks/access-application-cluster/web-ui-dashboard.md b/content/ko/docs/tasks/access-application-cluster/web-ui-dashboard.md index bef17a789d..3aa05a92b0 100644 --- a/content/ko/docs/tasks/access-application-cluster/web-ui-dashboard.md +++ b/content/ko/docs/tasks/access-application-cluster/web-ui-dashboard.md @@ -61,7 +61,7 @@ Kubeconfig 인증 방법은 외부 아이덴티티 프로파이더 또는 x509 ## 컨테이너화 된 애플리케이션 배포 -대시보드를 이용하여 컨테이너화 된 애플리케이션을 디플로이먼트와 간단한 마법사를 통한 선택적인 서비스(Service) 로 생성하고 배포할 수 있다. 애플리케이션 세부 정보를 수동으로 지정할 수 있고, 또는 애플리케이션 구성을 포함한 YAML, JSON 파일을 업로드 할 수 있다. +대시보드를 이용하여 컨테이너화 된 애플리케이션을 디플로이먼트와 간단한 마법사를 통한 선택적인 서비스로 생성하고 배포할 수 있다. 애플리케이션 세부 정보를 수동으로 지정할 수 있고, 또는 애플리케이션 구성을 포함한 YAML, JSON 파일을 업로드 할 수 있다. 시작하는 페이지의 상위 오른쪽 코너에 있는 **CREATE** 버튼을 클릭한다. @@ -69,7 +69,7 @@ Kubeconfig 인증 방법은 외부 아이덴티티 프로파이더 또는 x509 배포 마법사는 다음 정보를 제공한다. -- **앱 이름** (필수): 애플리케이션 이름. [레이블](/ko/docs/concepts/overview/working-with-objects/labels/) 이름은 배포할 모든 디플로이먼트와 서비스(Service)에 추가되어야 한다. +- **앱 이름** (필수): 애플리케이션 이름. [레이블](/ko/docs/concepts/overview/working-with-objects/labels/) 이름은 배포할 모든 디플로이먼트와 서비스에 추가되어야 한다. 애플리케이션 이름은 선택된 쿠버네티스 [네임스페이스](/docs/tasks/administer-cluster/namespaces/) 안에서 유일해야 한다. 소문자로 시작해야하며, 소문자 또는 숫자로 끝나고, 소문자, 숫자 및 대쉬(-)만을 포함해야한다. 24 문자만을 제한한다. 처음과 끝의 스페이스는 무시된다. @@ -79,26 +79,30 @@ Kubeconfig 인증 방법은 외부 아이덴티티 프로파이더 또는 x509 클러스터에 의도한 파드의 수를 유지하기 위해서 [디플로이먼트](/ko/docs/concepts/workloads/controllers/deployment/)가 생성될 것이다. -- **서비스(Service)** (선택): 일부 애플리케이션의 경우, (예를 들어, 프론트엔드) 아마도 클러스터 바깥의 퍼블릭 IP 주소를 가진 (외부 서비스) 외부에 [서비스(Service)](/ko/docs/concepts/services-networking/service/)를 노출 시키고 싶을 수 있다. 외부 서비스들을 위해, 한개 또는 여러 개의 포트들을 열어 둘 필요가 있다. [이 곳](/docs/tasks/access-application-cluster/configure-cloud-provider-firewall/) 내용을 참고한다. +- **서비스** (선택): 일부 애플리케이션의 경우, (예를 들어, 프론트엔드) 아마도 클러스터 바깥의 퍼블릭 IP 주소를 가진 (외부 서비스) 외부에 [서비스](/ko/docs/concepts/services-networking/service/)를 노출 시키고 싶을 수 있다. - 클러스터 내부에서만 보고 싶은 어떤 서비스(Serivce)들이 있을 것인다. 이를 내부 서비스라고 한다. + {{< note >}} + 외부 서비스들을 위해, 한 개 또는 여러 개의 포트를 열어 둘 필요가 있다. + {{< /note >}} - 서비스(Service) 타입과는 무관하게, 서비스(Service) 생성을 선택해서 컨테이너의 (들어오는 패킷의) 포트를 리슨한다면, 두 개의 포트를 정의해야 한다. 서비스(Service)는 컨테이너가 바라보는 타겟 포트와 (들어오는 패킷의) 맵핑하는 포트가 만들어져야 할 것이다. 서비스(Service)는 배포된 파드에 라우팅 될 것이다. 지원하는 프로토콜은 TCP와 UDP이다. 서비스(Service)가 이용하는 내부 DNS 이름은 애플리케이션 이름으로 지정한 값이 될 것이다. + 클러스터 내부에서만 보고 싶은 어떤 서비스들이 있을 것이다. 이를 내부 서비스라고 한다. + + 서비스 타입과는 무관하게, 서비스 생성을 선택해서 컨테이너의 (들어오는 패킷의) 포트를 리슨한다면, 두 개의 포트를 정의해야 한다. 서비스는 컨테이너가 바라보는 타겟 포트와 (들어오는 패킷의) 맵핑하는 포트가 만들어져야 할 것이다. 서비스는 배포된 파드에 라우팅 될 것이다. 지원하는 프로토콜은 TCP와 UDP이다. 서비스가 이용하는 내부 DNS 이름은 애플리케이션 이름으로 지정한 값이 될 것이다. 만약 필요하다면, 더 많은 세팅을 지정할 수 있는 **자세한 옵션 보기** 섹션에서 확장할 수 있다. - **설명**: 입력하는 텍스트값은 디플로이먼트에 [어노테이션](/ko/docs/concepts/overview/working-with-objects/annotations/) 으로 추가될 것이고, 애플리케이션의 세부사항에 표시될 것이다. -- **레이블**: 애플리케이션에 사용되는 기본적인 [레이블](/ko/docs/concepts/overview/working-with-objects/labels/)은 애플리케이션 이름과 버전이다. 릴리스, 환경, 티어, 파티션, 그리고 릴리스 트랙과 같은 레이블을 디플로이먼트, 서비스(Service), 그리고 파드를 생성할 때 추가적으로 정의할 수 있다. +- **레이블**: 애플리케이션에 사용되는 기본적인 [레이블](/ko/docs/concepts/overview/working-with-objects/labels/)은 애플리케이션 이름과 버전이다. 릴리스, 환경, 티어, 파티션, 그리고 릴리스 트랙과 같은 레이블을 디플로이먼트, 서비스, 그리고 파드를 생성할 때 추가적으로 정의할 수 있다. 예를 들면: -```conf -release=1.0 -tier=frontend -environment=pod -track=stable -``` + ```conf + release=1.0 + tier=frontend + environment=pod + track=stable + ``` - **네임스페이스**: 쿠버네티스는 동일한 물리 클러스터를 바탕으로 여러 가상의 클러스터를 제공한다. 이러한 가상 클러스터들을 [네임스페이스](/docs/tasks/administer-cluster/namespaces/)라고 부른다. 논리적으로 명명된 그룹으로 리소스들을 분할 할 수 있다. @@ -115,17 +119,17 @@ track=stable - **CPU 요구 사항 (cores)** 와 **메모리 요구 사항 (MiB)**: 컨테이너를 위한 최소 [리소스 상한](/docs/tasks/configure-pod-container/limit-range/)을 정의할 수 있다. 기본적으로, 파드는 CPU와 메모리 상한을 두지 않고 동작한다. -- **커맨드 실행** 와 **커맨드 인수 실행**: 기본적으로, 컨테이너는 선택된 도커 이미지의 [기본 엔트리포인트 커맨드](/docs/tasks/inject-data-application/define-command-argument-container/)를 실행한다. 커맨드 옵션과 인자를 기본 옵션에 우선 적용하여 사용할 수 있다. +- **커맨드 실행** 와 **커맨드 인수 실행**: 기본적으로, 컨테이너는 선택된 도커 이미지의 [기본 엔트리포인트 커맨드](/ko/docs/tasks/inject-data-application/define-command-argument-container/)를 실행한다. 커맨드 옵션과 인자를 기본 옵션에 우선 적용하여 사용할 수 있다. -- **특권을 가진(privileged) 상태로 실행**: 다음 세팅은 호스트에서 루트 권한을 가진 프로세스들이 [특권을 가진 컨테이너](/docs/user-guide/pods/#privileged-mode-for-pod-containers)의 프로세스들과 동등한 지 아닌지 정의한다. 특권을 가진(privileged) 컨테이너는 네트워크 스택과 디바이스에 접근하는 것을 조작하도록 활용할 수 있다. +- **특권을 가진(privileged) 상태로 실행**: 다음 세팅은 호스트에서 루트 권한을 가진 프로세스들이 [특권을 가진 컨테이너](/ko/docs/concepts/workloads/pods/pod/#파드-컨테이너의-특권-privileged-모드)의 프로세스들과 동등한 지 아닌지 정의한다. 특권을 가진(privileged) 컨테이너는 네트워크 스택과 디바이스에 접근하는 것을 조작하도록 활용할 수 있다. -- **환경 변수**: 쿠버네티스 서비스(Service)를 [환경 변수](/docs/tasks/inject-data-application/environment-variable-expose-pod-information/)를 통해 노출한다. 환경 변수 또는 인자를 환경 변수들의 값으로 커맨드를 통해 구성할 수 있다. 애플리케이션들이 서비스(Service)를 찾는데 사용된다. 값들은 `$(VAR_NAME)` 구문을 사용하는 다른 변수들로 참조할 수 있다. +- **환경 변수**: 쿠버네티스 서비스를 [환경 변수](/docs/tasks/inject-data-application/environment-variable-expose-pod-information/)를 통해 노출한다. 환경 변수 또는 인자를 환경 변수들의 값으로 커맨드를 통해 구성할 수 있다. 애플리케이션들이 서비스를 찾는데 사용된다. 값들은 `$(VAR_NAME)` 구문을 사용하는 다른 변수들로 참조할 수 있다. ### YAML 또는 JSON 파일 업로드 -쿠버네티스는 선언적인 설정을 제공한다. 이 방식으로 모든 설정은 쿠버네티스 [API](/docs/concepts/overview/kubernetes-api/) 리소스 스키마를 이용하여 YAML 또는 JSON 설정 파일에 저장한다. +쿠버네티스는 선언적인 설정을 제공한다. 이 방식으로 모든 설정은 쿠버네티스 [API](/ko/docs/concepts/overview/kubernetes-api/) 리소스 스키마를 이용하여 YAML 또는 JSON 설정 파일에 저장한다. -배포 마법사를 통해 애플리케이션 세부사항들을 지정하는 대신, 애플리케이션을 YAML 또는 JSON 파일로 정의할 수 있고 대시보드를 이용해서 파일을 업로드할 수 있다. +배포 마법사를 통해 애플리케이션 세부사항들을 지정하는 대신, 애플리케이션을 YAML 또는 JSON 파일로 정의할 수 있고 대시보드를 이용해서 파일을 업로드할 수 있다. ## 대시보드 사용 다음 섹션들은 어떻게 제공하고 어떻게 사용할 수 있는지에 대한 쿠버네티스 대시보드 UI의 모습을 보여준다. @@ -140,12 +144,12 @@ track=stable 클러스터와 네임스페이스 관리자에게 대시보드는 노드, 네임스페이스 그리고 퍼시스턴트 볼륨과 세부사항들이 보여진다. 노드는 모든 노드를 통틀어 CPU와 메모리 사용량을 보여준다. 세부사항은 각 노드들에 대한 사용량, 사양, 상태, 할당된 리소스, 이벤트 그리고 노드에서 돌아가는 파드를 보여준다. #### 워크로드 -선택된 네임스페이스에서 구동되는 모든 애플리케이션을 보여준다. 애플리케이션의 워크로드 종류(예를 들어, 디플로이먼트, 레플리카 셋, 스테이트풀 셋 등)를 보여주고 각각의 워크로드 종류는 따로 보여진다. 리스트는 예를 들어 레플리카 셋에서 준비된 파드의 숫자 또는 파드의 현재 메모리 사용량과 같은 워크로드에 대한 실용적인 정보를 요약한다. +선택된 네임스페이스에서 구동되는 모든 애플리케이션을 보여준다. 애플리케이션의 워크로드 종류(예를 들어, 디플로이먼트, 레플리카셋(ReplicaSet), 스테이트풀셋(StatefulSet) 등)를 보여주고 각각의 워크로드 종류는 따로 보여진다. 리스트는 예를 들어 레플리카셋에서 준비된 파드의 숫자 또는 파드의 현재 메모리 사용량과 같은 워크로드에 대한 실용적인 정보를 요약한다. -워크로드에 대한 세부적인 것들은 상태와 사양 정보, 오프젝트들 간의 관계를 보여준다. 예를 들어, 레플리카 셋으로 관리하는 파드들 또는 새로운 레플리카 셋과 디플로이먼트를 위한 Horizontal Pod Autoscalers 이다. +워크로드에 대한 세부적인 것들은 상태와 사양 정보, 오프젝트들 간의 관계를 보여준다. 예를 들어, 레플리카셋으로 관리하는 파드들 또는 새로운 레플리카셋과 디플로이먼트를 위한 Horizontal Pod Autoscalers 이다. -#### 서비스(Service) -외부로 노출되는 서비스들과 클러스터 내에 발견되는 서비스들을 허용하는 쿠버네티스 리소스들을 보여준다. 이러한 이유로 서비스(Service)와 인그레스는 클러스터간의 연결을 위한 내부 엔드포인트들과 외부 사용자를 위한 외부 엔드포인트들에 의해 타게팅된 파드들을 보여준다. +#### 서비스 +외부로 노출되는 서비스들과 클러스터 내에 발견되는 서비스들을 허용하는 쿠버네티스 리소스들을 보여준다. 이러한 이유로 서비스와 인그레스는 클러스터간의 연결을 위한 내부 엔드포인트들과 외부 사용자를 위한 외부 엔드포인트들에 의해 타게팅된 파드들을 보여준다. #### 스토리지 스토리지는 애플리케이션이 데이터를 저장하기 위해 사용하는 퍼시턴트 볼륨 클레임 리소스들을 보여준다. @@ -163,7 +167,5 @@ track=stable ## {{% heading "whatsnext" %}} -더 많은 정보는 +더 많은 정보는 [쿠버네티스 대시보드 프로젝트 페이지](https://github.com/kubernetes/dashboard)를 참고한다. - - diff --git a/content/ko/docs/tasks/administer-cluster/_index.md b/content/ko/docs/tasks/administer-cluster/_index.md index 77ca3f2479..4913ccf73e 100755 --- a/content/ko/docs/tasks/administer-cluster/_index.md +++ b/content/ko/docs/tasks/administer-cluster/_index.md @@ -1,5 +1,6 @@ --- title: "클러스터 운영" +description: 클러스터를 운영하기 위한 공통 태스크를 배운다. weight: 20 --- diff --git a/content/ko/docs/tasks/administer-cluster/access-cluster-api.md b/content/ko/docs/tasks/administer-cluster/access-cluster-api.md new file mode 100644 index 0000000000..1b92c1283a --- /dev/null +++ b/content/ko/docs/tasks/administer-cluster/access-cluster-api.md @@ -0,0 +1,451 @@ +--- +title: 쿠버네티스 API를 사용하여 클러스터에 접근하기 +content_type: task +--- + +<!-- overview --> +이 페이지는 쿠버네티스 API를 사용하여 클러스터에 접근하는 방법을 보여준다. + + +## {{% heading "prerequisites" %}} + + +{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}} + + +<!-- steps --> + +## 쿠버네티스 API에 접근 + +### kubectl을 사용하여 처음으로 접근 + +쿠버네티스 API에 처음 접근하는 경우, 쿠버네티스 +커맨드 라인 도구인 `kubectl` 을 사용한다. + +클러스터에 접근하려면, 클러스터 위치를 알고 접근할 수 있는 자격 증명이 +있어야 한다. 일반적으로, [시작하기 가이드](/ko/docs/setup/)를 +통해 작업하거나, +다른 사람이 클러스터를 설정하고 자격 증명과 위치를 제공할 때 자동으로 설정된다. + +다음의 명령으로 kubectl이 알고 있는 위치와 자격 증명을 확인한다. + +```shell +kubectl config view +``` + +많은 [예제](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/)는 kubectl 사용에 대한 소개를 +제공한다. 전체 문서는 [kubectl 매뉴얼](/ko/docs/reference/kubectl/overview/)에 있다. + +### REST API에 직접 접근 + +kubectl은 API 서버 찾기와 인증을 처리한다. `curl` 이나 `wget` 과 같은 http 클라이언트 또는 브라우저를 사용하여 REST API에 +직접 접근하려는 경우, API 서버를 찾고 인증할 수 있는 여러 가지 방법이 있다. + + 1. 프록시 모드에서 kubectl을 실행한다(권장). 이 방법은 저장된 API 서버 위치를 사용하고 자체 서명된 인증서를 사용하여 API 서버의 ID를 확인하므로 권장한다. 이 방법을 사용하면 중간자(man-in-the-middle, MITM) 공격이 불가능하다. + 1. 또는, 위치와 자격 증명을 http 클라이언트에 직접 제공할 수 있다. 이 방법은 프록시를 혼란스럽게 하는 클라이언트 코드와 동작한다. 중간자 공격으로부터 보호하려면, 브라우저로 루트 인증서를 가져와야 한다. + + Go 또는 Python 클라이언트 라이브러리를 사용하면 프록시 모드에서 kubectl에 접근할 수 있다. + +#### kubectl 프록시 사용 + +다음 명령은 kubectl을 리버스 프록시로 작동하는 모드에서 실행한다. API +서버 찾기와 인증을 처리한다. + +다음과 같이 실행한다. + +```shell +kubectl proxy --port=8080 & +``` + +자세한 내용은 [kubectl 프록시](/docs/reference/generated/kubectl/kubectl-commands/#proxy)를 참고한다. + +그런 다음 curl, wget 또는 브라우저를 사용하여 API를 탐색할 수 있다. + +```shell +curl http://localhost:8080/api/ +``` + +출력은 다음과 비슷하다. + +```json +{ + "versions": [ + "v1" + ], + "serverAddressByClientCIDRs": [ + { + "clientCIDR": "0.0.0.0/0", + "serverAddress": "10.0.1.149:443" + } + ] +} +``` + +#### kubectl 프록시 없이 접근 + +다음과 같이 인증 토큰을 API 서버에 직접 전달하여 kubectl 프록시 +사용을 피할 수 있다. + +`grep/cut` 방식을 사용한다. + +```shell +# .KUBECONFIG에 여러 콘텍스트가 있을 수 있으므로, 가능한 모든 클러스터를 확인한다. +kubectl config view -o jsonpath='{"Cluster name\tServer\n"}{range .clusters[*]}{.name}{"\t"}{.cluster.server}{"\n"}{end}' + +# 위의 출력에서 상호 작용하려는 클러스터의 이름을 선택한다. +export CLUSTER_NAME="some_server_name" + +# 클러스터 이름을 참조하는 API 서버를 가리킨다. +APISERVER=$(kubectl config view -o jsonpath="{.clusters[?(@.name==\"$CLUSTER_NAME\")].cluster.server}") + +# 토큰 값을 얻는다 +TOKEN=$(kubectl get secrets -o jsonpath="{.items[?(@.metadata.annotations['kubernetes\.io/service-account\.name']=='default')].data.token}"|base64 --decode) + +# TOKEN으로 API 탐색 +curl -X GET $APISERVER/api --header "Authorization: Bearer $TOKEN" --insecure +``` + +출력은 다음과 비슷하다. + +```json +{ + "kind": "APIVersions", + "versions": [ + "v1" + ], + "serverAddressByClientCIDRs": [ + { + "clientCIDR": "0.0.0.0/0", + "serverAddress": "10.0.1.149:443" + } + ] +} +``` + +`jsonpath` 방식을 사용한다. + +```shell +APISERVER=$(kubectl config view --minify -o jsonpath='{.clusters[0].cluster.server}') +TOKEN=$(kubectl get secret $(kubectl get serviceaccount default -o jsonpath='{.secrets[0].name}') -o jsonpath='{.data.token}' | base64 --decode ) +curl $APISERVER/api --header "Authorization: Bearer $TOKEN" --insecure +{ + "kind": "APIVersions", + "versions": [ + "v1" + ], + "serverAddressByClientCIDRs": [ + { + "clientCIDR": "0.0.0.0/0", + "serverAddress": "10.0.1.149:443" + } + ] +} +``` + +위의 예는 `--insecure` 플래그를 사용한다. 이로 인해 MITM 공격이 +발생할 수 있다. kubectl이 클러스터에 접근하면 저장된 루트 인증서와 +클라이언트 인증서를 사용하여 서버에 접근한다. (`~/.kube` 디렉터리에 +설치된다.) 클러스터 인증서는 일반적으로 자체 서명되므로, +http 클라이언트가 루트 인증서를 사용하도록 하려면 특별한 구성이 +필요할 수 있다. + +일부 클러스터에서, API 서버는 인증이 필요하지 않다. +로컬 호스트에서 제공되거나, 방화벽으로 보호될 수 있다. 이에 대한 표준은 +없다. [API에 대한 접근 구성](/docs/reference/access-authn-authz/controlling-access/)은 +클러스터 관리자가 이를 구성하는 방법에 대해 설명한다. 이러한 접근 방식은 향후 +고 가용성 지원과 충돌할 수 있다. + +### API에 프로그래밍 방식으로 접근 + +쿠버네티스는 공식적으로 [Go](#go-client), [Python](#python-client), [Java](#java-client), [dotnet](#dotnet-client), [Javascript](#javascript-client) 및 [Haskell](#haskell-client) 용 클라이언트 라이브러리를 지원한다. 쿠버네티스 팀이 아닌 작성자가 제공하고 유지 관리하는 다른 클라이언트 라이브러리가 있다. 다른 언어에서 API에 접근하고 인증하는 방법에 대해서는 [클라이언트 라이브러리](/ko/docs/reference/using-api/client-libraries/)를 참고한다. + +#### Go 클라이언트 {#go-client} + +* 라이브러리를 얻으려면, 다음 명령을 실행한다. `go get k8s.io/client-go@kubernetes-<kubernetes-version-number>` 어떤 버전이 지원되는지를 확인하려면 [https://github.com/kubernetes/client-go/releases](https://github.com/kubernetes/client-go/releases)를 참고한다. +* client-go 클라이언트 위에 애플리케이션을 작성한다. + +{{< note >}} + +client-go는 자체 API 오브젝트를 정의하므로, 필요한 경우, 기본 리포지터리가 아닌 client-go에서 API 정의를 가져온다. 예를 들어, `import "k8s.io/client-go/kubernetes"` 가 맞다. + +{{< /note >}} + +Go 클라이언트는 kubectl CLI가 API 서버를 찾아 인증하기 위해 사용하는 것과 동일한 [kubeconfig 파일](/ko/docs/tasks/access-application-cluster/configure-access-multiple-clusters/)을 +사용할 수 있다. 이 [예제](https://git.k8s.io/client-go/examples/out-of-cluster-client-configuration/main.go)를 참고한다. + +```golang +import ( + "fmt" + "k8s.io/apimachinery/pkg/apis/meta/v1" + "k8s.io/client-go/kubernetes" + "k8s.io/client-go/tools/clientcmd" +) + +func main() { + // kubeconfig에서 현재 콘텍스트를 사용한다 + // path-to-kubeconfig -- 예를 들어, /root/.kube/config + config, _ := clientcmd.BuildConfigFromFlags("", "<path-to-kubeconfig>") + // clientset을 생성한다 + clientset, _ := kubernetes.NewForConfig(config) + // 파드를 나열하기 위해 API에 접근한다 + pods, _ := clientset.CoreV1().Pods("").List(v1.ListOptions{}) + fmt.Printf("There are %d pods in the cluster\n", len(pods.Items)) +} +``` + +애플리케이션이 클러스터에서 파드로 배치된 경우, [파드 내에서 API 접근](#accessing-the-api-from-within-a-pod)을 참고한다. + +#### Python 클라이언트 {#python-client} + +[Python 클라이언트](https://github.com/kubernetes-client/python)를 사용하려면, 다음 명령을 실행한다. `pip install kubernetes` 추가 설치 옵션은 [Python Client Library 페이지](https://github.com/kubernetes-client/python)를 참고한다. + +Python 클라이언트는 kubectl CLI가 API 서버를 찾아 인증하기 위해 사용하는 것과 동일한 [kubeconfig 파일](/ko/docs/tasks/access-application-cluster/configure-access-multiple-clusters/)을 +사용할 수 있다. 이 [예제](https://github.com/kubernetes-client/python/blob/master/examples/out_of_cluster_config.py)를 참고한다. + +```python +from kubernetes import client, config + +config.load_kube_config() + +v1=client.CoreV1Api() +print("Listing pods with their IPs:") +ret = v1.list_pod_for_all_namespaces(watch=False) +for i in ret.items: + print("%s\t%s\t%s" % (i.status.pod_ip, i.metadata.namespace, i.metadata.name)) +``` + +#### Java 클라이언트 {#java-client} + +* [Java 클라이언트](https://github.com/kubernetes-client/java)를 설치하려면, 다음을 실행한다. + +```shell +# java 라이브러리를 클론한다 +git clone --recursive https://github.com/kubernetes-client/java + +# 프로젝트 아티팩트, POM 등을 설치한다 +cd java +mvn install +``` + +어떤 버전이 지원되는지를 확인하려면 [https://github.com/kubernetes-client/java/releases](https://github.com/kubernetes-client/java/releases)를 참고한다. + +Java 클라이언트는 kubectl CLI가 API 서버를 찾아 인증하기 위해 사용하는 것과 동일한 [kubeconfig 파일](/ko/docs/tasks/access-application-cluster/configure-access-multiple-clusters/)을 +사용할 수 있다. 이 [예제](https://github.com/kubernetes-client/java/blob/master/examples/src/main/java/io/kubernetes/client/examples/KubeConfigFileClientExample.java)를 참고한다. + +```java +package io.kubernetes.client.examples; + +import io.kubernetes.client.ApiClient; +import io.kubernetes.client.ApiException; +import io.kubernetes.client.Configuration; +import io.kubernetes.client.apis.CoreV1Api; +import io.kubernetes.client.models.V1Pod; +import io.kubernetes.client.models.V1PodList; +import io.kubernetes.client.util.ClientBuilder; +import io.kubernetes.client.util.KubeConfig; +import java.io.FileReader; +import java.io.IOException; + +/** + * 쿠버네티스 클러스터 외부의 애플리케이션에서 Java API를 사용하는 방법에 대한 간단한 예 + * + * <p>이것을 실행하는 가장 쉬운 방법: mvn exec:java + * -Dexec.mainClass="io.kubernetes.client.examples.KubeConfigFileClientExample" + * + */ +public class KubeConfigFileClientExample { + public static void main(String[] args) throws IOException, ApiException { + + // KubeConfig의 파일 경로 + String kubeConfigPath = "~/.kube/config"; + + // 파일시스템에서 클러스터 외부 구성인 kubeconfig 로드 + ApiClient client = + ClientBuilder.kubeconfig(KubeConfig.loadKubeConfig(new FileReader(kubeConfigPath))).build(); + + // 전역 디폴트 api-client를 위에서 정의한 클러스터 내 클라이언트로 설정 + Configuration.setDefaultApiClient(client); + + // CoreV1Api는 전역 구성에서 디폴트 api-client를 로드 + CoreV1Api api = new CoreV1Api(); + + // CoreV1Api 클라이언트를 호출한다 + V1PodList list = api.listPodForAllNamespaces(null, null, null, null, null, null, null, null, null); + System.out.println("Listing all pods: "); + for (V1Pod item : list.getItems()) { + System.out.println(item.getMetadata().getName()); + } + } +} +``` + +#### dotnet 클라이언트 {#dotnet-client} + +[dotnet 클라이언트](https://github.com/kubernetes-client/csharp)를 사용하려면, 다음 명령을 실행한다. `dotnet add package KubernetesClient --version 1.6.1` 추가 설치 옵션은 [dotnet Client Library 페이지](https://github.com/kubernetes-client/csharp)를 참고한다. 어떤 버전이 지원되는지를 확인하려면 [https://github.com/kubernetes-client/csharp/releases](https://github.com/kubernetes-client/csharp/releases)를 참고한다. + +dotnet 클라이언트는 kubectl CLI가 API 서버를 찾아 인증하기 위해 사용하는 것과 동일한 [kubeconfig 파일](/ko/docs/tasks/access-application-cluster/configure-access-multiple-clusters/)을 +사용할 수 있다. 이 [예제](https://github.com/kubernetes-client/csharp/blob/master/examples/simple/PodList.cs)를 참고한다. + +```csharp +using System; +using k8s; + +namespace simple +{ + internal class PodList + { + private static void Main(string[] args) + { + var config = KubernetesClientConfiguration.BuildDefaultConfig(); + IKubernetes client = new Kubernetes(config); + Console.WriteLine("Starting Request!"); + + var list = client.ListNamespacedPod("default"); + foreach (var item in list.Items) + { + Console.WriteLine(item.Metadata.Name); + } + if (list.Items.Count == 0) + { + Console.WriteLine("Empty!"); + } + } + } +} +``` + +#### JavaScript 클라이언트 {#javascript-client} + +[JavaScript 클라이언트](https://github.com/kubernetes-client/javascript)를 설치하려면, 다음 명령을 실행한다. `npm install @kubernetes/client-node` 어떤 버전이 지원되는지를 확인하려면 [https://github.com/kubernetes-client/javascript/releases](https://github.com/kubernetes-client/javascript/releases)를 참고한다. + +JavaScript 클라이언트는 kubectl CLI가 API 서버를 찾아 인증하기 위해 사용하는 것과 동일한 [kubeconfig 파일](/ko/docs/tasks/access-application-cluster/configure-access-multiple-clusters/)을 +사용할 수 있다. 이 [예제](https://github.com/kubernetes-client/javascript/blob/master/examples/example.js)를 참고한다. + +```javascript +const k8s = require('@kubernetes/client-node'); + +const kc = new k8s.KubeConfig(); +kc.loadFromDefault(); + +const k8sApi = kc.makeApiClient(k8s.CoreV1Api); + +k8sApi.listNamespacedPod('default').then((res) => { + console.log(res.body); +}); +``` + +#### Haskell 클라이언트 {#haskell-client} + +어떤 버전이 지원되는지를 확인하려면 [https://github.com/kubernetes-client/haskell/releases](https://github.com/kubernetes-client/haskell/releases)를 참고한다. + +Haskell 클라이언트는 kubectl CLI가 API 서버를 찾아 인증하기 위해 사용하는 것과 동일한 [kubeconfig 파일](/ko/docs/tasks/access-application-cluster/configure-access-multiple-clusters/)을 +사용할 수 있다. 이 [예제](https://github.com/kubernetes-client/haskell/blob/master/kubernetes-client/example/App.hs)를 참고한다. + +```haskell +exampleWithKubeConfig :: IO () +exampleWithKubeConfig = do + oidcCache <- atomically $ newTVar $ Map.fromList [] + (mgr, kcfg) <- mkKubeClientConfig oidcCache $ KubeConfigFile "/path/to/kubeconfig" + dispatchMime + mgr + kcfg + (CoreV1.listPodForAllNamespaces (Accept MimeJSON)) + >>= print +``` + + +### 파드 내에서 API에 접근 {#accessing-the-api-from-within-a-pod} + +파드 내에서 API에 접근할 때, API 서버를 찾아 인증하는 것은 +위에서 설명한 외부 클라이언트 사례와 약간 다르다. + +파드에서 쿠버네티스 API를 사용하는 가장 쉬운 방법은 +공식 [클라이언트 라이브러리](/ko/docs/reference/using-api/client-libraries/) 중 하나를 사용하는 것이다. 이러한 +라이브러리는 API 서버를 자동으로 감지하고 인증할 수 있다. + +#### 공식 클라이언트 라이브러리 사용 + +파드 내에서, 쿠버네티스 API에 연결하는 권장 방법은 다음과 같다. + + - Go 클라이언트의 경우, 공식 [Go 클라이언트 라이브러리](https://github.com/kubernetes/client-go/)를 사용한다. + `rest.InClusterConfig()` 기능은 API 호스트 검색과 인증을 자동으로 처리한다. + [여기 예제](https://git.k8s.io/client-go/examples/in-cluster-client-configuration/main.go)를 참고한다. + + - Python 클라이언트의 경우, 공식 [Python 클라이언트 라이브러리](https://github.com/kubernetes-client/python/)를 사용한다. + `config.load_incluster_config()` 기능은 API 호스트 검색과 인증을 자동으로 처리한다. + [여기 예제](https://github.com/kubernetes-client/python/blob/master/examples/in_cluster_config.py)를 참고한다. + + - 사용할 수 있는 다른 라이브러리가 많이 있다. [클라이언트 라이브러리](/ko/docs/reference/using-api/client-libraries/) 페이지를 참고한다. + +각각의 경우, 파드의 서비스 어카운트 자격 증명은 API 서버와 +안전하게 통신하는 데 사용된다. + +#### REST API에 직접 접근 + +파드에서 실행되는 동안, 쿠버네티스 apiserver는 `default` 네임스페이스에서 `kubernetes`라는 +서비스를 통해 접근할 수 있다. 따라서, 파드는 `kubernetes.default.svc` +호스트 이름을 사용하여 API 서버를 쿼리할 수 있다. 공식 클라이언트 라이브러리는 +이를 자동으로 수행한다. + +API 서버를 인증하는 권장 방법은 [서비스 어카운트](/docs/user-guide/service-accounts) +자격 증명을 사용하는 것이다. 기본적으로, 파드는 +서비스 어카운트와 연결되어 있으며, 해당 서비스 어카운트에 대한 자격 증명(토큰)은 +해당 파드에 있는 각 컨테이너의 파일시스템 트리의 +`/var/run/secrets/kubernetes.io/serviceaccount/token` 에 있다. + +사용 가능한 경우, 인증서 번들은 각 컨테이너의 +파일시스템 트리의 `/var/run/secrets/kubernetes.io/serviceaccount/ca.crt` 에 배치되며, +API 서버의 제공 인증서를 확인하는 데 사용해야 한다. + +마지막으로, 네임스페이스가 지정된 API 작업에 사용되는 기본 네임스페이스는 각 컨테이너의 +`/var/run/secrets/kubernetes.io/serviceaccount/namespace` 에 있는 파일에 배치된다. + +#### kubectl 프록시 사용 + +공식 클라이언트 라이브러리 없이 API를 쿼리하려면, 파드에서 +새 사이드카 컨테이너의 [명령](/ko/docs/tasks/inject-data-application/define-command-argument-container/)으로 +`kubectl proxy` 를 실행할 수 있다. 이런 식으로, `kubectl proxy` 는 +API를 인증하고 이를 파드의 `localhost` 인터페이스에 노출시켜서, 파드의 +다른 컨테이너가 직접 사용할 수 있도록 한다. + +#### 프록시를 사용하지 않고 접근 + +인증 토큰을 API 서버에 직접 전달하여 kubectl 프록시 사용을 +피할 수 있다. 내부 인증서는 연결을 보호한다. + +```shell +# 내부 API 서버 호스트 이름을 가리킨다 +APISERVER=https://kubernetes.default.svc + +# ServiceAccount 토큰 경로 +SERVICEACCOUNT=/var/run/secrets/kubernetes.io/serviceaccount + +# 이 파드의 네임스페이스를 읽는다 +NAMESPACE=$(cat ${SERVICEACCOUNT}/namespace) + +# ServiceAccount 베어러 토큰을 읽는다 +TOKEN=$(cat ${SERVICEACCOUNT}/token) + +# 내부 인증 기관(CA)을 참조한다 +CACERT=${SERVICEACCOUNT}/ca.crt + +# TOKEN으로 API를 탐색한다 +curl --cacert ${CACERT} --header "Authorization: Bearer ${TOKEN}" -X GET ${APISERVER}/api +``` + +출력은 다음과 비슷하다. + +```json +{ + "kind": "APIVersions", + "versions": [ + "v1" + ], + "serverAddressByClientCIDRs": [ + { + "clientCIDR": "0.0.0.0/0", + "serverAddress": "10.0.1.149:443" + } + ] +} +``` diff --git a/content/ko/docs/tasks/administer-cluster/access-cluster-services.md b/content/ko/docs/tasks/administer-cluster/access-cluster-services.md new file mode 100644 index 0000000000..0b1cf9540f --- /dev/null +++ b/content/ko/docs/tasks/administer-cluster/access-cluster-services.md @@ -0,0 +1,134 @@ +--- +title: 클러스터에서 실행되는 서비스에 접근 +content_type: task +--- + +<!-- overview --> +이 페이지는 쿠버네티스 클러스터에서 실행되는 서비스에 연결하는 방법을 보여준다. + + +## {{% heading "prerequisites" %}} + + +{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}} + + +<!-- steps --> + +## 클러스터에서 실행되는 서비스에 접근 + +쿠버네티스에서, [노드](/ko/docs/concepts/architecture/nodes/), [파드](/ko/docs/concepts/workloads/pods/pod/) 및 [서비스](/ko/docs/concepts/services-networking/service/)는 모두 +고유한 IP를 가진다. 대부분의 경우, 클러스터의 노드 IP, 파드 IP 및 일부 서비스 IP는 라우팅할 수 +없으므로, 데스크톱 시스템과 같은 클러스터 외부 시스템에서 +도달할 수 없다. + +### 연결하는 방법 + +클러스터 외부에서 노드, 파드 및 서비스에 연결하기 위한 몇 가지 옵션이 있다. + + - 퍼블릭 IP를 통해 서비스에 접근한다. + - `NodePort` 또는 `LoadBalancer` 타입의 서비스를 사용하여 해당 서비스를 클러스터 외부에서 + 접근할 수 있게 한다. [서비스](/ko/docs/concepts/services-networking/service/)와 + [kubectl expose](/docs/reference/generated/kubectl/kubectl-commands/#expose) 문서를 참고한다. + - 클러스터 환경에 따라, 서비스는 단지 회사 네트워크에 노출되기도 하며, + 인터넷에 노출되는 경우도 있다. 노출되는 서비스가 안전한지 생각한다. + 자체 인증을 수행하는가? + - 서비스 뒤에 파드를 배치한다. 디버깅과 같은 목적으로 레플리카 집합에서 특정 파드에 접근하려면, + 파드에 고유한 레이블을 배치하고 이 레이블을 선택하는 새 서비스를 생성한다. + - 대부분의 경우, 애플리케이션 개발자가 nodeIP를 통해 노드에 직접 + 접근할 필요는 없다. + - 프록시 작업(Proxy Verb)을 사용하여 서비스, 노드 또는 파드에 접근한다. + - 원격 서비스에 접근하기 전에 apiserver 인증과 권한 부여를 수행한다. + 서비스가 인터넷에 노출되거나, 노드 IP의 포트에 접근하거나, 디버깅하기에 + 충분히 안전하지 않은 경우 사용한다. + - 프록시는 일부 웹 애플리케이션에 문제를 일으킬 수 있다. + - HTTP/HTTPS에서만 작동한다. + - [여기](#apiserver-프록시-url-수동-구성)에 설명되어 있다. + - 클러스터의 노드 또는 파드에서 접근한다. + - 파드를 실행한 다음, [kubectl exec](/docs/reference/generated/kubectl/kubectl-commands/#exec)를 사용하여 셸에 연결한다. + 해당 셸에서 다른 노드, 파드 및 서비스에 연결한다. + - 일부 클러스터는 클러스터의 노드로 ssh를 통해 접근하는 것을 허용한다. 거기에서 클러스터 서비스에 + 접근할 수 있다. 이것은 비표준 방법이며, 일부 클러스터에서는 작동하지만 다른 클러스터에서는 + 작동하지 않는다. 브라우저 및 기타 도구가 설치되거나 설치되지 않을 수 있다. 클러스터 DNS가 작동하지 않을 수도 있다. + +### 빌트인 서비스 검색 + +일반적으로, kube-system에 의해 클러스터에서 시작되는 몇 가지 서비스가 있다. `kubectl cluster-info` 명령을 +사용하여 이들의 목록을 얻는다. + +```shell +kubectl cluster-info +``` + +출력은 다음과 비슷하다. + +``` +Kubernetes master is running at https://104.197.5.247 +elasticsearch-logging is running at https://104.197.5.247/api/v1/namespaces/kube-system/services/elasticsearch-logging/proxy +kibana-logging is running at https://104.197.5.247/api/v1/namespaces/kube-system/services/kibana-logging/proxy +kube-dns is running at https://104.197.5.247/api/v1/namespaces/kube-system/services/kube-dns/proxy +grafana is running at https://104.197.5.247/api/v1/namespaces/kube-system/services/monitoring-grafana/proxy +heapster is running at https://104.197.5.247/api/v1/namespaces/kube-system/services/monitoring-heapster/proxy +``` + +각 서비스에 접근하기 위한 프록시-작업 URL이 표시된다. +예를 들어, 이 클러스터에는 `https://104.197.5.247/api/v1/namespaces/kube-system/services/elasticsearch-logging/proxy/` 로 +접근할 수 있는 (Elasticsearch를 사용한) 클러스터 수준 로깅이 활성화되어 있다. 적합한 자격 증명이 전달되는 경우나 kubectl proxy를 통해 도달할 수 있다. 예를 들어 다음의 URL에서 확인할 수 있다. +`http://localhost:8080/api/v1/namespaces/kube-system/services/elasticsearch-logging/proxy/`. + +{{< note >}} +자격 증명을 전달하거나 kubectl proxy를 사용하는 방법은 [쿠버네티스 API를 사용하여 클러스터에 접근하기](/ko/docs/tasks/administer-cluster/access-cluster-api/)를 참고한다. +{{< /note >}} + +#### apiserver 프록시 URL 수동 구성 + +위에서 언급한 것처럼, `kubectl cluster-info` 명령을 사용하여 서비스의 프록시 URL을 검색한다. 서비스 엔드포인트, 접미사 및 매개 변수를 포함하는 프록시 URL을 작성하려면, 단순히 서비스의 프록시 URL에 추가하면 된다. +`http://`*`kubernetes_master_address`*`/api/v1/namespaces/`*`namespace_name`*`/services/`*`[https:]service_name[:port_name]`*`/proxy` + +포트에 대한 이름을 지정하지 않은 경우, URL에 *port_name* 을 지정할 필요가 없다. + +##### 예제 + +* Elasticsearch 서비스 엔드포인트 `_search?q=user:kimchy` 에 접근하려면, 다음을 사용한다. + + ``` + http://104.197.5.247/api/v1/namespaces/kube-system/services/elasticsearch-logging/proxy/_search?q=user:kimchy + ``` + +* Elasticsearch 클러스터 상태 정보 `_cluster/health?pretty=true` 에 접근하려면, 다음을 사용한다. + + ``` + https://104.197.5.247/api/v1/namespaces/kube-system/services/elasticsearch-logging/proxy/_cluster/health?pretty=true + ``` + + 상태 정보는 다음과 비슷하다. + + ```json + { + "cluster_name" : "kubernetes_logging", + "status" : "yellow", + "timed_out" : false, + "number_of_nodes" : 1, + "number_of_data_nodes" : 1, + "active_primary_shards" : 5, + "active_shards" : 5, + "relocating_shards" : 0, + "initializing_shards" : 0, + "unassigned_shards" : 5 + } + ``` + +* *https* Elasticsearch 서비스 상태 정보 `_cluster/health?pretty=true` 에 접근하려면, 다음을 사용한다. + + ``` + https://104.197.5.247/api/v1/namespaces/kube-system/services/https:elasticsearch-logging/proxy/_cluster/health?pretty=true + ``` + +#### 웹 브라우저를 사용하여 클러스터에서 실행되는 서비스에 접근 + +브라우저의 주소 표시줄에 apiserver 프록시 URL을 넣을 수 있다. 그러나, + + - 웹 브라우저는 일반적으로 토큰을 전달할 수 없으므로, 기본 (비밀번호) 인증을 사용해야 할 수도 있다. Apiserver는 기본 인증을 수락하도록 구성할 수 있지만, + 클러스터는 기본 인증을 수락하도록 구성되지 않을 수 있다. + - 일부 웹 앱, 특히 프록시 경로 접두사를 인식하지 못하는 방식으로 URL을 구성하는 클라이언트 측 자바스크립트가 있는 + 웹 앱이 작동하지 않을 수 있다. diff --git a/content/ko/docs/tasks/administer-cluster/change-default-storage-class.md b/content/ko/docs/tasks/administer-cluster/change-default-storage-class.md new file mode 100644 index 0000000000..8fd7445fb7 --- /dev/null +++ b/content/ko/docs/tasks/administer-cluster/change-default-storage-class.md @@ -0,0 +1,101 @@ +--- +title: 기본 스토리지클래스(StorageClass) 변경하기 +content_type: task +--- + +<!-- overview --> +이 페이지는 특별한 요구사항이 없는 퍼시스턴트볼륨클레임(PersistentVolumeClaim)의 볼륨을 프로비저닝 +하는데 사용되는 기본 스토리지 클래스를 변경하는 방법을 보여준다. + + + +## {{% heading "prerequisites" %}} + + +{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}} + + + +<!-- steps --> + +## 왜 기본 스토리지 클래스를 변경하는가? + +설치 방법에 따라, 사용자의 쿠버네티스 클러스터는 기본으로 표시된 기존 +스토리지클래스와 함께 배포될 수 있다. 이 기본 스토리지클래스는 특정 +스토리지 클래스가 필요하지 않은 퍼시스턴트볼륨클레임에 대해 스토리지를 +동적으로 프로비저닝 하기 위해 사용된다. +더 자세한 내용은 [퍼시스턴트볼륨클레임 문서](/ko/docs/concepts/storage/persistent-volumes/#퍼시스턴트볼륨클레임)를 +보자. + +미리 설치된 기본 스토리지클래스가 사용자의 예상되는 워크로드에 적합하지 +않을수도 있다. 예를 들어, 너무 가격이 높은 스토리지를 프로비저닝 해야할 +수도 있다. 이런 경우에, 기본 스토리지 클래스를 변경하거나 완전히 비활성화 +하여 스토리지의 동적 프로비저닝을 방지할 수 있다. + +단순하게 기본 스토리지클래스를 삭제하는 경우, 사용자의 클러스터에서 구동중인 +애드온 매니저에 의해 자동으로 다시 생성될 수 있으므로 정상적으로 삭제가 되지 않을 수도 있다. 애드온 관리자 +및 개별 애드온을 비활성화 하는 방법에 대한 자세한 내용은 설치 문서를 참조하자. + +## 기본 스토리지클래스 변경하기 + +1. 사용자의 클러스터에 있는 스토리지클래스 목록을 조회한다. + + ```bash + kubectl get storageclass + ``` + + 결과는 아래와 유사하다. + + ```bash + NAME PROVISIONER AGE + standard (default) kubernetes.io/gce-pd 1d + gold kubernetes.io/gce-pd 1d + ``` + + 기본 스토리지클래스는 `(default)` 로 표시되어 있다. + +1. 기본 스토리지클래스를 기본값이 아닌 것으로 표시한다. + + 기본 스토리지클래스에는 + `storageclass.kubernetes.io/is-default-class` 의 값이 `true` 로 설정되어 있다. + 다른 값이거나 어노테이션이 없을 경우 `false` 로 처리된다. + + 스토리지클래스를 기본값이 아닌 것으로 표시하려면, 그 값을 `false` 로 변경해야 한다. + + ```bash + kubectl patch storageclass standard -p '{"metadata": {"annotations":{"storageclass.kubernetes.io/is-default-class":"false"}}}' + ``` + + 여기서 `standard` 는 사용자가 선택한 스토리지클래스의 이름이다. + +1. 스토리지클래스를 기본값으로 표시한다. + + 이전 과정과 유사하게, 어노테이션을 추가/설정 해야 한다. + `storageclass.kubernetes.io/is-default-class=true`. + + ```bash + kubectl patch storageclass gold -p '{"metadata": {"annotations":{"storageclass.kubernetes.io/is-default-class":"true"}}}' + ``` + + 최대 1개의 스토리지클래스를 기본값으로 표시할 수 있다는 것을 알아두자. 만약 + 2개 이상이 기본값으로 표시되면, 명시적으로 `storageClassName` 가 지정되지 않은 `PersistentVolumeClaim` 은 생성될 수 없다. + +1. 사용자가 선택한 스토리지클래스가 기본값으로 되어있는지 확인한다. + + ```bash + kubectl get storageclass + ``` + + 결과는 아래와 유사하다. + + ```bash + NAME PROVISIONER AGE + standard kubernetes.io/gce-pd 1d + gold (default) kubernetes.io/gce-pd 1d + ``` + + + +## {{% heading "whatsnext" %}} + +* [퍼시스턴트볼륨(PersistentVolume)](/ko/docs/concepts/storage/persistent-volumes/)에 대해 더 보기. diff --git a/content/ko/docs/tasks/administer-cluster/change-pv-reclaim-policy.md b/content/ko/docs/tasks/administer-cluster/change-pv-reclaim-policy.md new file mode 100644 index 0000000000..dfd9923113 --- /dev/null +++ b/content/ko/docs/tasks/administer-cluster/change-pv-reclaim-policy.md @@ -0,0 +1,97 @@ +--- +title: 퍼시스턴트볼륨 반환 정책 변경하기 +content_type: task +--- + +<!-- overview --> +이 페이지는 쿠버네티스 퍼시트턴트볼륨(PersistentVolume)의 반환 정책을 +변경하는 방법을 보여준다. + + +## {{% heading "prerequisites" %}} + + +{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}} + + + +<!-- steps --> + +## 왜 퍼시스턴트볼륨 반환 정책을 변경하는가? + +`PersistentVolumes` 은 "Retain(보존)", "Recycle(재활용)", "Delete(삭제)" 를 포함한 +다양한 반환 정책을 갖는다. 동적으로 프로비저닝 된 `PersistentVolumes` 의 경우 +기본 반환 정책은 "Delete" 이다. 이는 사용자가 해당 `PersistentVolumeClaim` 을 삭제하면, +동적으로 프로비저닝 된 볼륨이 자동적으로 삭제됨을 의미한다. +볼륨에 중요한 데이터가 포함된 경우, 이러한 자동 삭제는 부적절 할 수 있다. +이 경우에는, "Retain" 정책을 사용하는 것이 더 적합하다. +"Retain" 정책에서, 사용자가 `PersistentVolumeClaim` 을 삭제할 경우 해당하는 +`PersistentVolume` 은 삭제되지 않는다. +대신, `Released` 단계로 이동되어, 모든 데이터를 수동으로 복구할 수 있다. + +## 퍼시스턴트볼륨 반환 정책 변경하기 + +1. 사용자의 클러스터에서 퍼시스턴트볼륨을 조회한다. + + ```shell + kubectl get pv + ``` + + 결과는 아래와 같다. + + NAME CAPACITY ACCESSMODES RECLAIMPOLICY STATUS CLAIM STORAGECLASS REASON AGE + pvc-b6efd8da-b7b5-11e6-9d58-0ed433a7dd94 4Gi RWO Delete Bound default/claim1 manual 10s + pvc-b95650f8-b7b5-11e6-9d58-0ed433a7dd94 4Gi RWO Delete Bound default/claim2 manual 6s + pvc-bb3ca71d-b7b5-11e6-9d58-0ed433a7dd94 4Gi RWO Delete Bound default/claim3 manual 3s + + 이 목록은 동적으로 프로비저닝 된 볼륨을 쉽게 식별할 수 있도록 + 각 볼륨에 바인딩 되어 있는 퍼시스턴트볼륨클레임(PersistentVolumeClaim)의 이름도 포함한다. + +1. 사용자의 퍼시스턴트볼륨 중 하나를 선택한 후에 반환 정책을 변경한다. + + ```shell + kubectl patch pv <your-pv-name> -p '{"spec":{"persistentVolumeReclaimPolicy":"Retain"}}' + ``` + + `<your-pv-name>` 는 사용자가 선택한 퍼시스턴트볼륨의 이름이다. + + {{< note >}} + 윈도우에서는, 공백이 포함된 모든 JSONPath 템플릿에 _겹_ 따옴표를 사용해야 한다.(bash에 대해 위에서 표시된 홑 따옴표가 아니다.) 따라서 템플릿의 모든 표현식에서 홑 따옴표를 쓰거나, 이스케이프 처리된 겹 따옴표를 써야 한다. 예를 들면 다음과 같다. + +```cmd +kubectl patch pv <your-pv-name> -p "{\"spec\":{\"persistentVolumeReclaimPolicy\":\"Retain\"}}" +``` + + {{< /note >}} + +1. 선택한 PersistentVolume이 올바른 정책을 갖는지 확인한다. + + ```shell + kubectl get pv + ``` + + 결과는 아래와 같다. + + NAME CAPACITY ACCESSMODES RECLAIMPOLICY STATUS CLAIM STORAGECLASS REASON AGE + pvc-b6efd8da-b7b5-11e6-9d58-0ed433a7dd94 4Gi RWO Delete Bound default/claim1 manual 40s + pvc-b95650f8-b7b5-11e6-9d58-0ed433a7dd94 4Gi RWO Delete Bound default/claim2 manual 36s + pvc-bb3ca71d-b7b5-11e6-9d58-0ed433a7dd94 4Gi RWO Retain Bound default/claim3 manual 33s + + 위 결과에서, `default/claim3` 클레임과 바인딩 되어 있는 볼륨이 `Retain` 반환 정책을 + 갖는 것을 볼 수 있다. 사용자가 `default/claim3` 클레임을 삭제할 경우, + 볼륨은 자동으로 삭제 되지 않는다. + + + +## {{% heading "whatsnext" %}} + +* [퍼시스턴트볼륨](/ko/docs/concepts/storage/persistent-volumes/)에 대해 더 배워 보기. +* [퍼시스턴트볼륨클레임](/ko/docs/concepts/storage/persistent-volumes/#persistentvolumeclaims)에 대해 더 배워 보기. + +### Reference + +* [퍼시스턴트볼륨](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#persistentvolume-v1-core) +* [퍼시스턴트볼륨클레임](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#persistentvolumeclaim-v1-core) +* [PersistentVolumeSpec](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#persistentvolumeclaim-v1-core)의 `persistentVolumeReclaimPolicy` 필드에 대해 보기. + + diff --git a/content/ko/docs/tasks/administer-cluster/cluster-management.md b/content/ko/docs/tasks/administer-cluster/cluster-management.md index b84b42b7e1..440ece1531 100644 --- a/content/ko/docs/tasks/administer-cluster/cluster-management.md +++ b/content/ko/docs/tasks/administer-cluster/cluster-management.md @@ -5,9 +5,9 @@ content_type: concept <!-- overview --> -이 문서는 클러스터의 라이프사이클에 관련된 몇 가지 주제들을 설명한다. 신규 클러스터 생성, -클러스터의 마스터와 워커 노드들의 업그레이드, -노드 유지보수(예. 커널 업그레이드) 수행, 운영 중인 클러스터의 +이 문서는 클러스터의 라이프사이클에 관련된 몇 가지 주제들을 설명한다. 신규 클러스터 생성, +클러스터의 마스터와 워커 노드들의 업그레이드, +노드 유지보수(예. 커널 업그레이드) 수행, 운영 중인 클러스터의 쿠버네티스 API 버전 업그레이드. @@ -25,17 +25,17 @@ content_type: concept ### Azure Kubernetes Service (AKS) 클러스터 업그레이드 -Azure Kubernetes Service는 클러스터의 컨트롤 플레인과 노드를 손쉽게 셀프 서비스 업그레이드할 수 있게 해준다. 프로세스는 +Azure Kubernetes Service는 클러스터의 컨트롤 플레인과 노드를 손쉽게 셀프 서비스 업그레이드할 수 있게 해준다. 프로세스는 현재 사용자가 직접 시작하는 방식이며 [Azure AKS 문서](https://docs.microsoft.com/en-us/azure/aks/upgrade-cluster)에 설명되어 있다. ### Google Compute Engine 클러스터 업그레이드 -Google Compute Engine Open Source (GCE-OSS)는 마스터를 삭제하고 -재생성하는 방식으로 마스터 업그레이드를 지원한다. 하지만 업그레이드 간에 데이터를 보존하기 위해 +Google Compute Engine Open Source (GCE-OSS)는 마스터를 삭제하고 +재생성하는 방식으로 마스터 업그레이드를 지원한다. 하지만 업그레이드 간에 데이터를 보존하기 위해 동일한 Persistent Disk(PD)를 유지한다. -GCE의 노드 업그레이드는 [관리형 인스턴스 그룹](https://cloud.google.com/compute/docs/instance-groups/)을 사용하며, 각 노드는 -순차적으로 제거된 후에 신규 소프트웨어를 가지고 재생성된다. 해당 노드에서 동작하는 파드들은 +GCE의 노드 업그레이드는 [관리형 인스턴스 그룹](https://cloud.google.com/compute/docs/instance-groups/)을 사용하며, 각 노드는 +순차적으로 제거된 후에 신규 소프트웨어를 가지고 재생성된다. 해당 노드에서 동작하는 파드들은 레플리케이션 컨트롤러에 의해서 제어되거나, 롤 아웃 후에 수작업으로 재생성되어야 한다. open source Google Compute Engine(GCE) 클러스터 업그레이드는 `cluster/gce/upgrade.sh` 스크립트로 제어한다. @@ -81,7 +81,7 @@ Oracle은 당신이 고가용성의 관리형 쿠버네티스 컨트롤 플레 ## 클러스터 크기 재조정 -[노드 자가 등록 모드](/ko/docs/concepts/architecture/nodes/#노드에-대한-자체-등록)로 운영 중인 클러스터가 리소스가 부족하다면 쉽게 머신들을 더 추가할 수 있다. GCE나 Google Kubernetes Engine을 사용하고 있다면 노드들을 관리하는 인스턴스 그룹의 크기를 재조정하여 이를 수행할 수 있다. +[노드 자가 등록 모드](/ko/docs/concepts/architecture/nodes/#노드에-대한-자체-등록)로 운영 중인 클러스터가 리소스가 부족하다면 쉽게 머신들을 더 추가할 수 있다. GCE나 Google Kubernetes Engine을 사용하고 있다면 노드들을 관리하는 인스턴스 그룹의 크기를 재조정하여 이를 수행할 수 있다. [Google Cloud 콘솔 페이지](https://console.developers.google.com)를 사용한다면 `Compute > Compute Engine > Instance groups > your group > Edit group`에서 인스턴스들의 숫자를 고쳐서 이를 수행할 수 있으며 gcloud CLI를 사용한다면 다음 커맨드를 사용하여 이를 수행할 수 있다. ```shell @@ -99,23 +99,23 @@ Azure Kubernetes Service는 사용자가 CLI나 Azure 포털에서 클러스터 ### 클러스터 오토스케일링 -GCE나 Google Kubernetes Engine을 사용한다면, 파드가 필요로하는 리소스를 기반으로 클러스터의 크기를 자동으로 +GCE나 Google Kubernetes Engine을 사용한다면, 파드가 필요로하는 리소스를 기반으로 클러스터의 크기를 자동으로 재조정하도록 클러스터를 구성할 수 있다. -[컴퓨트 리소스](/docs/concepts/configuration/manage-compute-resources-container/)에 기술된 것처럼 사용자들은 파드에 얼마만큼의 CPU와 메모리를 할당할 것인지 예약할 수 있다. -이 정보는 쿠버네티스 스케줄러가 해당 파드를 어디에서 실행시킬 것인지를 결정할 때 사용된다. -여유 용량이 넉넉한 노드가 없다면 (또는 다른 파드 요구조건을 충족하지 못한다면) 해당 파드는 +[컴퓨트 리소스](/ko/docs/concepts/configuration/manage-resources-containers/)에 기술된 것처럼 사용자들은 파드에 얼마만큼의 CPU와 메모리를 할당할 것인지 예약할 수 있다. +이 정보는 쿠버네티스 스케줄러가 해당 파드를 어디에서 실행시킬 것인지를 결정할 때 사용된다. +여유 용량이 넉넉한 노드가 없다면 (또는 다른 파드 요구조건을 충족하지 못한다면) 해당 파드는 다른 파드들이 종료될 때까지 기다리거나 신규 노드가 추가될 때까지 기다린다. -Cluster autoscaler는 스케줄링될 수 없는 파드들을 검색하여 클러스터 내의 다른 노드들과 유사한 신규 노드를 +Cluster autoscaler는 스케줄링될 수 없는 파드들을 검색하여 클러스터 내의 다른 노드들과 유사한 신규 노드를 추가하는 것이 도움이 되는지를 체크한다. 만약 도움이 된다면 대기중인 파드들을 수용하기 위해 클러스터의 크기를 재조정한다. -Cluster autoscaler는 또한 하나 이상의 노드들이 장기간(10분, 하지만 미래에는 변경될 수 있다.)동안 +Cluster autoscaler는 또한 하나 이상의 노드들이 장기간(10분, 하지만 미래에는 변경될 수 있다.)동안 더 이상 필요하지 않다는 것을 확인했을 때 클러스터를 스케일 다운하기도 한다. Cluster autoscaler는 인스턴스 그룹(GCE)이나 노드 풀(Google Kubernetes Engine) 단위로 구성된다. -GCE를 사용한다면 kube-up.sh 스크립트로 클러스터를 생성할 때 Cluster autoscaler를 활성화할 수 있다. +GCE를 사용한다면 kube-up.sh 스크립트로 클러스터를 생성할 때 Cluster autoscaler를 활성화할 수 있다. cluster autoscaler를 구성하려면 다음 세 가지 환경 변수들을 설정해야 한다. * `KUBE_ENABLE_CLUSTER_AUTOSCALER` - true로 설정되면 cluster autoscaler를 활성화한다. @@ -128,8 +128,8 @@ cluster autoscaler를 구성하려면 다음 세 가지 환경 변수들을 설 KUBE_ENABLE_CLUSTER_AUTOSCALER=true KUBE_AUTOSCALER_MIN_NODES=3 KUBE_AUTOSCALER_MAX_NODES=10 NUM_NODES=5 ./cluster/kube-up.sh ``` -Google Kubernetes Engine에서는 클러스터 생성이나 업데이트, 또는 (오토스케일하려고 하는) 특정 노드 풀의 -생성 시기에 해당 `gcloud` 커맨드에 `--enable-autoscaling` `--minnodes` `--maxnodes` 플래그들을 +Google Kubernetes Engine에서는 클러스터 생성이나 업데이트, 또는 (오토스케일하려고 하는) 특정 노드 풀의 +생성 시기에 해당 `gcloud` 커맨드에 `--enable-autoscaling` `--minnodes` `--maxnodes` 플래그들을 전달하여 cluster autoscaler를 구성할 수 있다. 예제: @@ -144,17 +144,17 @@ gcloud container clusters update mytestcluster --enable-autoscaling --min-nodes= **Cluster autoscaler는 노드가 수작업으로 변경(예. kubectl을 통해 레이블을 추가)되는 경우를 예상하지 않는데, 동일한 인스턴스 그룹 내의 신규 노드들에 이 속성들이 전파되지 않을 것이기 때문이다.** -cluster autoscaler가 클러스터 스케일 여부와 언제 어떻게 클러스터 스케일하는지에 대한 상세 사항은 -autoscaler 프로젝트의 [FAQ](https://github.com/kubernetes/autoscaler/blob/master/cluster-autoscaler/FAQ.md) +cluster autoscaler가 클러스터 스케일 여부와 언제 어떻게 클러스터 스케일하는지에 대한 상세 사항은 +autoscaler 프로젝트의 [FAQ](https://github.com/kubernetes/autoscaler/blob/master/cluster-autoscaler/FAQ.md) 문서를 참조하기를 바란다. ## 노드 유지보수 -(커널 업그레이드, libc 업그레이드, 하드웨어 수리 등으로) 한 노드를 리부트해야하는데 다운타임이 짧다면, -Kubelet이 재시작할 때 해당 노드에 스케줄된 파드들을 재시작하려고 할 것이다. 만약 리부트가 길게 걸린다면 -(컨트롤러 관리자의 `--pod-eviction-timeout`으로 제어되는 기본 시간은 5분이다.) -노드 컨트롤러는 사용불가한 노드에 묶여져 있는 파드들을 종료 시킬 것이다. 만약 상응하는 -레플리카 셋 (또는 레플리케이션 컨트롤러)가 존재한다면, 해당 파드의 신규 복제본을 다른 노드에서 기동시킬 것이다. 따라서, 모든 파드들이 +(커널 업그레이드, libc 업그레이드, 하드웨어 수리 등으로) 한 노드를 리부트해야하는데 다운타임이 짧다면, +Kubelet이 재시작할 때 해당 노드에 스케줄된 파드들을 재시작하려고 할 것이다. 만약 리부트가 길게 걸린다면 +(컨트롤러 관리자의 `--pod-eviction-timeout`으로 제어되는 기본 시간은 5분이다.) +노드 컨트롤러는 사용불가한 노드에 묶여져 있는 파드들을 종료 시킬 것이다. 만약 상응하는 +레플리카셋(ReplicaSet) (또는 레플리케이션 컨트롤러)가 존재한다면, 해당 파드의 신규 복제본을 다른 노드에서 기동시킬 것이다. 따라서, 모든 파드들이 복제된 상황에서 모든 노드들이 동시에 다운되지 않는다고 가정했을 때, 별다른 조작없이 업데이트를 진행할 수 있다. 만약 업그레이드 과정을 상세하게 통제하기를 원한다면, 다음 워크플로우를 사용할 수 있다. @@ -167,9 +167,9 @@ kubectl drain $NODENAME 이렇게하면 파드가 종료되는 동안 신규 파드들이 해당 노드에 스케줄되는 것을 방지한다. -레플리카 셋의 파드들은 신규 노드에 스케줄되는 신규 파드로 교체될 것이다. 추가적으로 해당 파드가 한 서비스의 일부라면, 클라이언트들은 자동으로 신규 파드로 재전송될 것이다. +레플리카셋의 파드들은 신규 노드에 스케줄되는 신규 파드로 교체될 것이다. 추가적으로 해당 파드가 한 서비스의 일부라면, 클라이언트들은 자동으로 신규 파드로 재전송될 것이다. -레플리카 셋이 아닌 파드들은 직접 해당 파드의 새로운 복제본을 올려야 하며, 해당 파드가 한 서비스의 일부가 아니라면 클라이언트들을 신규 복제본으로 재전송해야 한다. +레플리카셋이 아닌 파드들은 직접 해당 파드의 새로운 복제본을 올려야 하며, 해당 파드가 한 서비스의 일부가 아니라면 클라이언트들을 신규 복제본으로 재전송해야 한다. 해당 노드에 유지보수 작업을 수행한다. @@ -179,8 +179,8 @@ kubectl drain $NODENAME kubectl uncordon $NODENAME ``` -해당 노드의 VM 인스턴스를 삭제하고 신규로 생성했다면, 신규로 스케줄 가능한 노드 리소스가 -자동으로 생성될 것이다.(당신이 노드 디스커버리를 지원하는 클라우드 제공자를 사용한다면; +해당 노드의 VM 인스턴스를 삭제하고 신규로 생성했다면, 신규로 스케줄 가능한 노드 리소스가 +자동으로 생성될 것이다.(당신이 노드 디스커버리를 지원하는 클라우드 제공자를 사용한다면; 이는 현재 Google Compute Engine만 지원되며 Google Compute Engine 상에서 kube-register를 사용하는 CoreOS를 포함하지는 않는다.) 상세 내용은 [노드](/ko/docs/concepts/architecture/nodes)를 참조하라. ## 고급 주제들 @@ -199,15 +199,15 @@ kubectl uncordon $NODENAME ### 클러스터에서 API 버전을 ON/OFF 하기 -특정 API 버전들은 API 서버가 올라오는 동안 `--runtime-config=api/<version>` 플래그를 전달하여 ON/OFF 시킬 수 있다. 예를 들어, v1 API를 OFF 시키려면, `--runtime-config=api/v1=false`를 -전달한다. runtime-config는 모든 API들과 레거시 API들을 각각 제어하는 api/all과 api/legacy 2가지 특수 키도 지원한다. -예를 들어, v1을 제외한 모든 API 버전들을 OFF하려면 `--runtime-config=api/all=false,api/v1=true`를 전달한다. +특정 API 버전들은 API 서버가 올라오는 동안 `--runtime-config=api/<version>` 플래그를 전달하여 ON/OFF 시킬 수 있다. 예를 들어, v1 API를 OFF 시키려면, `--runtime-config=api/v1=false`를 +전달한다. runtime-config는 모든 API들과 레거시 API들을 각각 제어하는 api/all과 api/legacy 2가지 특수 키도 지원한다. +예를 들어, v1을 제외한 모든 API 버전들을 OFF하려면 `--runtime-config=api/all=false,api/v1=true`를 전달한다. 이 플래그들을 위해 레거시 API들은 명확하게 사용중단된 API들이다.(예. `v1beta3`) ### 클러스터에서 스토리지 API 버전을 변경 클러스터 내에서 활성화된 쿠버네티스 리소스들의 클러스터의 내부 표현을 위해 디스크에 저장된 객체들은 특정 버전의 API를 사용하여 작성된다. -지원되는 API가 변경될 때, 이 객체들은 새로운 API로 재작성되어야 할 수도 있다. 이것이 실패하면 결과적으로 리소스들이 +지원되는 API가 변경될 때, 이 객체들은 새로운 API로 재작성되어야 할 수도 있다. 이것이 실패하면 결과적으로 리소스들이 쿠버네티스 API 서버에서 더 이상 해독되거나 사용할 수 없게 될 것이다. ### 구성 파일을 신규 API 버전으로 변경 @@ -219,5 +219,3 @@ kubectl convert -f pod.yaml --output-version v1 ``` 옵션에 대한 상세 정보는 [kubectl convert](/docs/reference/generated/kubectl/kubectl-commands#convert) 커맨드의 사용법을 참조하기를 바란다. - - diff --git a/content/ko/docs/tasks/administer-cluster/coredns.md b/content/ko/docs/tasks/administer-cluster/coredns.md new file mode 100644 index 0000000000..6f0caad9e4 --- /dev/null +++ b/content/ko/docs/tasks/administer-cluster/coredns.md @@ -0,0 +1,98 @@ +--- +title: 서비스 디스커버리를 위해 CoreDNS 사용하기 +min-kubernetes-server-version: v1.9 +content_type: task +--- + +<!-- overview --> +이 페이지는 CoreDNS 업그레이드 프로세스와 kube-dns 대신 CoreDNS를 설치하는 방법을 보여준다. + + +## {{% heading "prerequisites" %}} + +{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}} + + +<!-- steps --> + +## CoreDNS 소개 + +[CoreDNS](https://coredns.io)는 쿠버네티스 클러스터의 DNS 역할을 수행할 수 있는, 유연하고 확장 가능한 DNS 서버이다. +쿠버네티스와 동일하게, CoreDNS 프로젝트도 {{< glossary_tooltip text="CNCF" term_id="cncf" >}}가 관리한다. + +사용자는 기존 디플로이먼트인 kube-dns를 교체하거나, 클러스터를 배포하고 업그레이드하는 +kubeadm과 같은 툴을 사용하여 클러스터 안의 kube-dns 대신 CoreDNS를 사용할 수 있다. + +## CoreDNS 설치 + +Kube-dns의 배포나 교체에 관한 매뉴얼은 [CoreDNS GitHub 프로젝트](https://github.com/coredns/deployment/tree/master/kubernetes)에 +있는 문서를 확인하자. + +## CoreDNS로 이관하기 + +### Kubeadm을 사용해 기존 클러스터 업그레이드하기 + +쿠버네티스 버전 1.10 이상에서, `kube-dns` 를 사용하는 클러스터를 업그레이드하기 위하여 +`kubeadm` 을 사용할 때 CoreDNS로 이동할 수도 있다. 이 경우, `kubeadm` 은 +`kube-dns` 컨피그맵(ConfigMap)을 기반으로 패더레이션, 스텁 도메인(stub domain), 업스트림 네임 서버의 +설정을 유지하며 CoreDNS 설정("Corefile")을 생성한다. + +만약 kube-dns에서 CoreDNS로 이동하는 경우, 업그레이드 과정에서 기능 게이트의 `CoreDNS` 값을 `true` 로 설정해야 한다. +예를 들어, `v1.11.0` 로 업그레이드 하는 경우는 다음과 같다. +``` +kubeadm upgrade apply v1.11.0 --feature-gates=CoreDNS=true +``` + +쿠버네티스 1.13 이상에서 기능 게이트의 `CoreDNS` 항목은 제거되었으며, CoreDNS가 기본적으로 사용된다. +업그레이드된 클러스터에서 kube-dns를 사용하려는 경우, [여기](/docs/reference/setup-tools/kubeadm/kubeadm-init-phase#cmd-phase-addon)에 +설명된 지침 가이드를 참고하자. + +1.11 미만 버전일 경우 업그레이드 과정에서 만들어진 파일이 Corefile을 **덮어쓴다**. +**만약 컨피그맵을 사용자 정의한 경우, 기존의 컨피그맵을 저장해야 한다.** 새 컨피그맵이 +시작된 후에 변경 사항을 다시 적용해야 할 수도 있다. + +만약 쿠버네티스 1.11 이상 버전에서 CoreDNS를 사용하는 경우, 업그레이드 과정에서, +기존의 Corefile이 유지된다. + + +### Kubeadm을 사용해 CoreDNS가 아닌 kube-dns 설치하기 + +{{< note >}} +쿠버네티스 1.11 버전에서, CoreDNS는 GA(General Availability) 되었으며, +기본적으로 설치된다. +{{< /note >}} + +{{< warning >}} +쿠버네티스 1.18 버전에서, kubeadm을 통한 kube-dns는 사용 중단되었으며, 향후 버전에서 제거될 예정이다. +{{< /warning >}} + +1.13 보다 이전 버전에서 kube-dns를 설치하는경우, 기능 게이트의 `CoreDNS` +값을 `false` 로 변경해야 한다. + +``` +kubeadm init --feature-gates=CoreDNS=false +``` + +1.13 이후 버전에서는, [여기](/docs/reference/setup-tools/kubeadm/kubeadm-init-phase#cmd-phase-addon)에 설명된 지침 가이드를 참고하자. + +## CoreDNS 업그레이드하기 + +CoreDNS는 쿠버네티스 1.9 버전부터 사용할 수 있다. +쿠버네티스와 함께 제공되는 CoreDNS의 버전과 CoreDNS의 변경 사항은 [여기](https://github.com/coredns/deployment/blob/master/kubernetes/CoreDNS-k8s_version.md)에서 확인할 수 있다. + +CoreDNS는 사용자 정의 이미지를 사용하거나 CoreDNS만 업그레이드 하려는 경우에 수동으로 업그레이드할 수 있다. +업그레이드를 원활하게 수행하는 데 유용한 [가이드라인 및 연습](https://github.com/coredns/deployment/blob/master/kubernetes/Upgrading_CoreDNS.md)을 참고하자. + +## CoreDNS 튜닝하기 + +리소스 활용이 중요한 경우, CoreDNS 구성을 조정하는 것이 유용할 수 있다. +더 자세한 내용은 [CoreDNS 스케일링에 대한 설명서](https://github.com/coredns/deployment/blob/master/kubernetes/Scaling_CoreDNS.md)를 확인하자. + + + +## {{% heading "whatsnext" %}} + + +`Corefile` 을 수정하여 kube-dns 보다 더 많은 유스케이스를 지원하도록 +[CoreDNS](https://coredns.io)를 구성할 수 있다. +더 자세한 내용은 [CoreDNS 웹사이트](https://coredns.io/2017/05/08/custom-dns-entries-for-kubernetes/)을 확인하자. diff --git a/content/ko/docs/tasks/administer-cluster/declare-network-policy.md b/content/ko/docs/tasks/administer-cluster/declare-network-policy.md new file mode 100644 index 0000000000..58865f9443 --- /dev/null +++ b/content/ko/docs/tasks/administer-cluster/declare-network-policy.md @@ -0,0 +1,145 @@ +--- +title: 네트워크 폴리시(Network Policy) 선언하기 +min-kubernetes-server-version: v1.8 +content_type: task +--- +<!-- overview --> +이 문서는 사용자가 쿠버네티스 [네트워크폴리시 API](/ko/docs/concepts/services-networking/network-policies/)를 사용하여 파드(Pod)가 서로 통신하는 방법을 제어하는 네트워크 폴리시를 선언하는데 도움을 준다. + + +## {{% heading "prerequisites" %}} + + +{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}} + +네트워크 폴리시를 지원하는 네트워크 제공자를 구성하였는지 확인해야 한다. 다음과 같이 네트워크폴리시를 제공하는 많은 네트워크 제공자들이 있다. + +* [캘리코(Calico)](/ko/docs/tasks/administer-cluster/network-policy-provider/calico-network-policy/) +* [실리움(Cilium)](/ko/docs/tasks/administer-cluster/network-policy-provider/cilium-network-policy/) +* [Kube-router](/ko/docs/tasks/administer-cluster/network-policy-provider/kube-router-network-policy/) +* [로마나(Romana)](/ko/docs/tasks/administer-cluster/network-policy-provider/romana-network-policy/) +* [위브넷(Weave Net)](/ko/docs/tasks/administer-cluster/network-policy-provider/weave-network-policy/) + +{{< note >}} +위 목록은 추천순이나 선호도순이 아닌, 제품 이름의 알파벳 순으로 정렬되어 있다. 이 예제는 이러한 제공자 중 하나를 사용하는 쿠버네티스 클러스터에 유효하다. +{{< /note >}} + + +<!-- steps --> + +## `nginx` 디플로이먼트(Deployment)를 생성하고 서비스(Service)를 통해 노출하기 + +쿠버네티스 네트워크 폴리시가 어떻게 동작하는지 확인하기 위해서, `nginx` 디플로이먼트를 생성한다. + +```console +kubectl create deployment nginx --image=nginx +``` +```none +deployment.apps/nginx created +``` + +`nginx` 라는 이름의 서비스를 통해 디플로이먼트를 노출한다. + +```console +kubectl expose deployment nginx --port=80 +``` + +```none +service/nginx exposed +``` + +위 명령어들은 nginx 파드에 대한 디플로이먼트를 생성하고, `nginx` 라는 이름의 서비스를 통해 디플로이먼트를 노출한다. `nginx` 파드와 디플로이먼트는 `default` 네임스페이스(namespace)에 존재한다. + +```console +kubectl get svc,pod +``` + +```none +NAME CLUSTER-IP EXTERNAL-IP PORT(S) AGE +service/kubernetes 10.100.0.1 <none> 443/TCP 46m +service/nginx 10.100.0.16 <none> 80/TCP 33s + +NAME READY STATUS RESTARTS AGE +pod/nginx-701339712-e0qfq 1/1 Running 0 35s +``` + +## 다른 파드에서 접근하여 서비스 테스트하기 + +사용자는 다른 파드에서 새 `nginx` 서비스에 접근할 수 있어야 한다. `default` 네임스페이스에 있는 다른 파드에서 `nginx` 서비스에 접근하기 위하여, busybox 컨테이너를 생성한다. + +```console +kubectl run busybox --rm -ti --image=busybox -- /bin/sh +``` + +사용자 쉘에서, 다음의 명령을 실행한다. + +```shell +wget --spider --timeout=1 nginx +``` + +```none +Connecting to nginx (10.100.0.16:80) +remote file exists +``` + +## `nginx` 서비스에 대해 접근 제한하기 + +`access: true` 레이블을 가지고 있는 파드만 `nginx` 서비스에 접근할 수 있도록 하기 위하여, 다음과 같은 네트워크폴리시 오브젝트를 생성한다. + +{{< codenew file="service/networking/nginx-policy.yaml" >}} + +네트워크폴리시 오브젝트의 이름은 유효한 +[DNS 서브도메인 이름](/ko/docs/concepts/overview/working-with-objects/names#dns-subdomain-names)이어야 한다. + +{{< note >}} +네트워크폴리시는 정책이 적용되는 파드의 그룹을 선택하는 `podSelector` 를 포함한다. 사용자는 이 정책이 `app=nginx` 레이블을 갖는 파드를 선택하는 것을 볼 수 있다. 레이블은 `nginx` 디플로이먼트에 있는 파드에 자동으로 추가된다. 빈 `podSelector` 는 네임스페이스의 모든 파드를 선택한다. +{{< /note >}} + +## 서비스에 정책 할당하기 + +kubectl을 사용하여 위 `nginx-policy.yaml` 파일로부터 네트워크폴리시를 생성한다. + +```console +kubectl apply -f https://k8s.io/examples/service/networking/nginx-policy.yaml +``` + +```none +networkpolicy.networking.k8s.io/access-nginx created +``` + +## access 레이블이 정의되지 않은 서비스에 접근 테스트 +올바른 레이블이 없는 파드에서 `nginx` 서비스에 접근하려 할 경우, 요청 타임 아웃이 발생한다. + +```console +kubectl run busybox --rm -ti --image=busybox -- /bin/sh +``` + +사용자 쉘에서, 다음의 명령을 실행한다. + +```shell +wget --spider --timeout=1 nginx +``` + +```none +Connecting to nginx (10.100.0.16:80) +wget: download timed out +``` + +## 접근 레이블을 정의하고 다시 테스트 + +사용자는 요청이 허용되도록 하기 위하여 올바른 레이블을 갖는 파드를 생성한다. + +```console +kubectl run busybox --rm -ti --labels="access=true" --image=busybox -- /bin/sh +``` + +사용자 쉘에서, 다음의 명령을 실행한다. + +```shell +wget --spider --timeout=1 nginx +``` + +```none +Connecting to nginx (10.100.0.16:80) +remote file exists +``` diff --git a/content/ko/docs/tasks/administer-cluster/dns-custom-nameservers.md b/content/ko/docs/tasks/administer-cluster/dns-custom-nameservers.md new file mode 100644 index 0000000000..0e5a87bc82 --- /dev/null +++ b/content/ko/docs/tasks/administer-cluster/dns-custom-nameservers.md @@ -0,0 +1,261 @@ +--- +title: DNS 서비스 사용자 정의하기 +content_type: task +min-kubernetes-server-version: v1.12 +--- + +<!-- overview --> +이 페이지는 클러스터 안에서 사용자의 +DNS {{< glossary_tooltip text="파드(Pod)" term_id="pod" >}} 를 설정하고 +DNS 변환(DNS resolution) 절차를 사용자 정의하는 방법을 설명한다. + +## {{% heading "prerequisites" %}} + +{{< include "task-tutorial-prereqs.md" >}} + +클러스터는 CoreDNS 애드온을 구동하고 있어야 한다. +[CoreDNS로 이관하기](/ko/docs/tasks/administer-cluster/coredns/#coredns로-이관하기) +는 `kubeadm` 을 이용하여 `kube-dns` 로부터 이관하는 방법을 설명한다. + +{{% version-check %}} + +<!-- steps --> + +## 소개 + +DNS는 _애드온 관리자_ 인 [클러스터 애드온](http://releases.k8s.io/{{< param "githubbranch" >}}/cluster/addons/README.md)을 +사용하여 자동으로 시작되는 쿠버네티스 +내장 서비스이다. + +쿠버네티스 v1.12 부터, CoreDNS는 kube-dns를 대체하여 권장되는 DNS 서버이다. 만약 사용자의 클러스터가 원래 kube-dns를 사용하였을 경우, +CoreDNS 대신 `kube-dns` 를 계속 사용할 수도 있다. + +{{< note >}} +CoreDNS와 kube-dns 서비스 모두 `metadata.name` 필드에 `kube-dns` 로 이름이 지정된다. +이를 통해, 기존의 `kube-dns` 서비스 이름을 사용하여 클러스터 내부의 주소를 확인하는 워크로드에 대한 상호 운용성이 증가된다. `kube-dns` 로 서비스 이름을 사용하면, 해당 DNS 공급자가 어떤 공통 이름으로 실행되고 있는지에 대한 구현 세부 정보를 추상화한다. +{{< /note >}} + +CoreDNS를 디플로이먼트(Deployment)로 실행하고 있을 경우, 일반적으로 고정 IP 주소를 갖는 쿠버네티스 서비스로 노출된다. +Kubelet 은 `--cluster-dns=<dns-service-ip>` 플래그를 사용하여 DNS 확인자 정보를 각 컨테이너에 전달한다. + +DNS 이름에도 도메인이 필요하다. 사용자는 kubelet 에 있는 `--cluster-domain=<default-local-domain>` 플래그를 +통하여 로컬 도메인을 설정할 수 있다. + +DNS 서버는 정방향 조회(A 및 AAAA 레코드), 포트 조회(SRV 레코드), 역방향 IP 주소 조회(PTR 레코드) 등을 지원한다. +더 자세한 내용은 [서비스 및 파드용 DNS](/ko/docs/concepts/services-networking/dns-pod-service/)를 참고한다. + +만약 파드의 `dnsPolicy` 가 `default` 로 지정되어 있는 경우, +파드는 자신이 실행되는 노드의 이름 변환(name resolution) 구성을 상속한다. +파드의 DNS 변환도 노드와 동일하게 작동해야 한다. +그 외에는 [알려진 이슈](/docs/tasks/debug-application-cluster/dns-debugging-resolution/#known-issues)를 참고한다. + +만약 위와 같은 방식을 원하지 않거나, 파드를 위해 다른 DNS 설정이 필요한 경우, +사용자는 kubelet 의 `--resolv-conf` 플래그를 사용할 수 있다. +파드가 DNS를 상속받지 못하도록 하기 위해 이 플래그를 ""로 설정한다. +DNS 상속을 위해 `/etc/resolv.conf` 이외의 파일을 지정할 경우 유효한 파일 경로를 설정한다. + +## CoreDNS + +CoreDNS는 [dns 명세](https://github.com/kubernetes/dns/blob/master/docs/specification.md)를 준수하며 클러스터 DNS 역할을 할 수 있는, 범용적인 권한을 갖는 DNS 서버이다. + +### CoreDNS 컨피그맵(ConfigMap) 옵션 + +CoreDNS는 모듈형이자 플러그인이 가능한 DNS 서버이며, 각 플러그인들은 CoreDNS에 새로운 기능을 부가한다. +이는 CoreDNS 구성 파일인 [Corefile](https://coredns.io/2017/07/23/corefile-explained/)을 관리하여 구성할 수 있다. +클러스터 관리자는 CoreDNS Corefile에 대한 {{< glossary_tooltip text="컨피그맵" term_id="configmap" >}}을 수정하여 +해당 클러스터에 대한 DNS 서비스 검색 동작을 +변경할 수 있다. + +쿠버네티스에서 CoreDNS는 아래의 기본 Corefile 구성으로 설치된다. + +```yaml +apiVersion: v1 +kind: ConfigMap +metadata: + name: coredns + namespace: kube-system +data: + Corefile: | + .:53 { + errors + health { + lameduck 5s + } + ready + kubernetes cluster.local in-addr.arpa ip6.arpa { + pods insecure + fallthrough in-addr.arpa ip6.arpa + ttl 30 + } + prometheus :9153 + forward . /etc/resolv.conf + cache 30 + loop + reload + loadbalance + } +``` + +Corefile의 구성은 CoreDNS의 아래 [플러그인](https://coredns.io/plugins)을 포함한다. + +* [errors](https://coredns.io/plugins/errors/): 오류가 표준 출력(stdout)에 기록된다. +* [health](https://coredns.io/plugins/health/): CoreDNS의 상태(healthy)가 `http://localhost:8080/health` 에 기록된다. 이 확장 구문에서 `lameduck` 은 프로세스를 비정상 상태(unhealthy)로 만들고, 프로세스가 종료되기 전에 5초 동안 기다린다. +* [ready](https://coredns.io/plugins/ready/): 8181 포트의 HTTP 엔드포인트가, 모든 플러그인이 준비되었다는 신호를 보내면 200 OK 를 반환한다. +* [kubernetes](https://coredns.io/plugins/kubernetes/): CoreDNS가 쿠버네티스의 서비스 및 파드의 IP를 기반으로 DNS 쿼리에 대해 응답한다. 해당 플러그인에 대한 [세부 사항](https://coredns.io/plugins/kubernetes/)은 CoreDNS 웹사이트에서 확인할 수 있다. `ttl` 을 사용하면 응답에 대한 사용자 정의 TTL 을 지정할 수 있으며, 기본값은 5초이다. 허용되는 최소 TTL은 0초이며, 최대값은 3600초이다. 레코드가 캐싱되지 않도록 할 경우, TTL을 0으로 설정한다. + `pods insecure` 옵션은 _kube-dns_ 와의 하위 호환성을 위해 제공된다. `pods verified` 옵션을 사용하여, 일치하는 IP의 동일 네임스페이스(Namespace)에 파드가 존재하는 경우에만 A 레코드를 반환하게 할 수 있다. `pods disabled` 옵션은 파드 레코드를 사용하지 않을 경우 사용된다. +* [prometheus](https://coredns.io/plugins/metrics/): CoreDNS의 메트릭은 [프로메테우스](https://prometheus.io/) 형식(OpenMetrics 라고도 알려진)의 `http://localhost:9153/metrics` 에서 사용 가능하다. +* [forward](https://coredns.io/plugins/forward/): 쿠버네티스 클러스터 도메인에 없는 쿼리들은 모두 사전에 정의된 리졸버(/etc/resolv.conf)로 전달된다. +* [cache](https://coredns.io/plugins/cache/): 프론트 엔드 캐시를 활성화한다. +* [loop](https://coredns.io/plugins/loop/): 간단한 전달 루프(loop)를 감지하고, 루프가 발견되면 CoreDNS 프로세스를 중단(halt)한다. +* [reload](https://coredns.io/plugins/reload): 변경된 Corefile을 자동으로 다시 로드하도록 한다. 컨피그맵 설정을 변경한 후에 변경 사항이 적용되기 위하여 약 2분정도 소요된다. +* [loadbalance](https://coredns.io/plugins/loadbalance): 응답에 대하여 A, AAAA, MX 레코드의 순서를 무작위로 선정하는 라운드-로빈 DNS 로드밸런서이다. + +사용자는 컨피그맵을 변경하여 기본 CoreDNS 동작을 변경할 수 있다. + +### CoreDNS를 사용하는 스텁 도메인(Stub-domain)과 업스트림 네임서버(nameserver)의 설정 + +CoreDNS는 [포워드 플러그인](https://coredns.io/plugins/forward/)을 사용하여 스텁 도메인 및 업스트림 네임서버를 구성할 수 있다. + +#### 예시 +만약 클러스터 운영자가 10.150.0.1 에 위치한 [Consul](https://www.consul.io/) 도메인 서버를 가지고 있고, 모든 Consul 이름의 접미사가 .consul.local 인 경우, CoreDNS에서 이를 구성하기 위해 클러스터 관리자는 CoreDNS 컨피그맵에서 다음 구문을 생성한다. + +``` +consul.local:53 { + errors + cache 30 + forward . 10.150.0.1 + } +``` + +모든 비 클러스터의 DNS 조회가 172.16.0.1 의 특정 네임서버를 통과하도록 할 경우, `/etc/resolv.conf` 대신 `forward` 를 네임서버로 지정한다. + +``` +forward . 172.16.0.1 +``` + +기본 `Corefile` 구성에 따른 최종 컨피그맵은 다음과 같다. + +```yaml +apiVersion: v1 +kind: ConfigMap +metadata: + name: coredns + namespace: kube-system +data: + Corefile: | + .:53 { + errors + health + kubernetes cluster.local in-addr.arpa ip6.arpa { + pods insecure + fallthrough in-addr.arpa ip6.arpa + } + prometheus :9153 + forward . 172.16.0.1 + cache 30 + loop + reload + loadbalance + } + consul.local:53 { + errors + cache 30 + forward . 10.150.0.1 + } +``` + +`Kubeadm` 툴은 kube-dns 컨피그맵에서 동일한 설정의 CoreDNS 컨피그맵으로의 +자동 변환을 지원한다. + +{{< note >}} +kube-dns는 스텁 도메인 및 네임서버(예: ns.foo.com)에 대한 FQDN을 허용하지만 CoreDNS에서는 이 기능을 지원하지 않는다. +변환 과정에서, 모든 FQDN 네임서버는 CoreDNS 설정에서 생략된다. +{{< /note >}} + +## kube-dns에 대응되는 CoreDNS 설정 + +CoreDNS는 kube-dns 이상의 기능을 지원한다. +`StubDomains` 과 `upstreamNameservers` 를 지원하도록 생성된 kube-dns의 컨피그맵은 CoreDNS의 `forward` 플러그인으로 변환된다. +마찬가지로, kube-dns의 `Federations` 플러그인은 CoreDNS의 `federation` 플러그인으로 변환된다. + +### 예시 + +kube-dns에 대한 이 컨피그맵 예제는 federations, stubDomains 및 upstreamNameservers를 지정한다. + +```yaml +apiVersion: v1 +data: + federations: | + {"foo" : "foo.feddomain.com"} + stubDomains: | + {"abc.com" : ["1.2.3.4"], "my.cluster.local" : ["2.3.4.5"]} + upstreamNameservers: | + ["8.8.8.8", "8.8.4.4"] +kind: ConfigMap +``` + +CoreDNS에서는 동등한 설정으로 Corefile을 생성한다. + +* federations 에 대응하는 설정: +``` +federation cluster.local { + foo foo.feddomain.com +} +``` + +* stubDomains 에 대응하는 설정: +```yaml +abc.com:53 { + errors + cache 30 + forward . 1.2.3.4 +} +my.cluster.local:53 { + errors + cache 30 + forward . 2.3.4.5 +} +``` + +기본 플러그인으로 구성된 완전한 Corefile. + +``` +.:53 { + errors + health + kubernetes cluster.local in-addr.arpa ip6.arpa { + pods insecure + fallthrough in-addr.arpa ip6.arpa + } + federation cluster.local { + foo foo.feddomain.com + } + prometheus :9153 + forward . 8.8.8.8 8.8.4.4 + cache 30 +} +abc.com:53 { + errors + cache 30 + forward . 1.2.3.4 +} +my.cluster.local:53 { + errors + cache 30 + forward . 2.3.4.5 +} +``` + +## CoreDNS로의 이관 + +kube-dns에서 CoreDNS로 이관하기 위하여, +kube-dns를 CoreDNS로 교체하여 적용하는 방법에 대한 상세 정보는 +[블로그 기사](https://coredns.io/2018/05/21/migration-from-kube-dns-to-coredns/)를 참고한다. + +또한 공식적인 CoreDNS [배포 스크립트](https://github.com/coredns/deployment/blob/master/kubernetes/deploy.sh)를 +사용하여 이관할 수도 있다. + + +## {{% heading "whatsnext" %}} + +- [DNS 변환 디버깅하기](/docs/tasks/administer-cluster/dns-debugging-resolution/) 읽기 diff --git a/content/ko/docs/tasks/administer-cluster/extended-resource-node.md b/content/ko/docs/tasks/administer-cluster/extended-resource-node.md new file mode 100644 index 0000000000..c9aed07263 --- /dev/null +++ b/content/ko/docs/tasks/administer-cluster/extended-resource-node.md @@ -0,0 +1,206 @@ +--- +title: 노드에 대한 확장 리소스 알리기 +content_type: task +--- + + +<!-- overview --> + +이 페이지는 노드의 확장 리소스를 지정하는 방법을 보여준다. +확장 리소스를 통해 클러스터 관리자는 쿠버네티스에게 +알려지지 않은 노드-레벨 리소스를 알릴 수 있다. + + + + +## {{% heading "prerequisites" %}} + + +{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}} + + + + +<!-- steps --> + +## 노드의 이름을 확인한다 + +```shell +kubectl get nodes +``` + +이 연습에 사용할 노드 중 하나를 선택한다. + +## 노드 중 하나에 새로운 확장 리소스를 알린다 + +노드에서 새로운 확장 리소스를 알리려면, 쿠버네티스 API 서버에 +HTTP PATCH 요청을 보낸다. 예를 들어, 노드 중 하나에 4개의 동글(dongle)이 있다고 +가정한다. 다음은 노드에 4개의 동글 리소스를 알리는 PATCH 요청의 +예이다. + +```shell +PATCH /api/v1/nodes/<your-node-name>/status HTTP/1.1 +Accept: application/json +Content-Type: application/json-patch+json +Host: k8s-master:8080 + +[ + { + "op": "add", + "path": "/status/capacity/example.com~1dongle", + "value": "4" + } +] +``` + +참고로 쿠버네티스는 동글이 무엇인지 또는 동글이 무엇을 위한 것인지 알 필요가 없다. +위의 PATCH 요청은 노드에 동글이라고 하는 네 가지 항목이 있음을 +쿠버네티스에 알려준다. + +쿠버네티스 API 서버에 요청을 쉽게 보낼 수 있도록 프록시를 시작한다. + +```shell +kubectl proxy +``` + +다른 명령 창에서 HTTP PATCH 요청을 보낸다. +`<your-node-name>` 을 노드의 이름으로 바꾼다. + +```shell +curl --header "Content-Type: application/json-patch+json" \ +--request PATCH \ +--data '[{"op": "add", "path": "/status/capacity/example.com~1dongle", "value": "4"}]' \ +http://localhost:8001/api/v1/nodes/<your-node-name>/status +``` + +{{< note >}} +이전 요청에서 `~1` 은 패치 경로의 / 문자에 대한 +인코딩이다. JSON-Patch의 작업 경로값은 JSON-Pointer로 +해석된다. 자세한 내용은 [IETF RFC 6901](https://tools.ietf.org/html/rfc6901)의 +섹션 3을 참고한다. +{{< /note >}} + +출력은 노드가 4개의 동글 용량을 가졌음을 나타낸다. + +``` +"capacity": { + "cpu": "2", + "memory": "2049008Ki", + "example.com/dongle": "4", +``` + +노드의 정보를 확인한다. + +``` +kubectl describe node <your-node-name> +``` + +다시 한 번, 출력에 동글 리소스가 표시된다. + +```yaml +Capacity: + cpu: 2 + memory: 2049008Ki + example.com/dongle: 4 +``` + +이제, 애플리케이션 개발자는 특정 개수의 동글을 요청하는 파드를 +만들 수 있다. [컨테이너에 확장 리소스 할당하기](/docs/tasks/configure-pod-container/extended-resource/)를 +참고한다. + +## 토론 + +확장 리소스는 메모리 및 CPU 리소스와 비슷하다. 예를 들어, +노드에서 실행 중인 모든 컴포넌트가 공유할 특정 양의 메모리와 CPU가 +노드에 있는 것처럼, 노드에서 실행 중인 모든 컴포넌트가 +특정 동글을 공유할 수 있다. 또한 애플리케이션 개발자가 +특정 양의 메모리와 CPU를 요청하는 파드를 생성할 수 있는 것처럼, 특정 +동글을 요청하는 파드를 생성할 수 있다. + +확장 리소스는 쿠버네티스에게 불투명하다. 쿠버네티스는 그것들이 +무엇인지 전혀 모른다. 쿠버네티스는 노드에 특정 개수의 노드만 +있다는 것을 알고 있다. 확장 리소스는 정수로 알려야 +한다. 예를 들어, 노드는 4.5개의 동글이 아닌, 4개의 동글을 알릴 수 있다. + +### 스토리지 예제 + +노드에 800GiB의 특별한 종류의 디스크 스토리지가 있다고 가정한다. +example.com/special-storage와 같은 특별한 스토리지의 이름을 생성할 수 있다. +그런 다음 특정 크기, 100GiB의 청크로 알릴 수 있다. 이 경우, +노드에는 example.com/special-storage 유형의 8가지 리소스가 있다고 +알린다. + +```yaml +Capacity: + ... + example.com/special-storage: 8 +``` + +이 특별한 스토리지에 대한 임의 요청을 허용하려면, +1바이트 크기의 청크로 특별한 스토리지를 알릴 수 있다. 이 경우, example.com/special-storage 유형의 +800Gi 리소스를 알린다. + +```yaml +Capacity: + ... + example.com/special-storage: 800Gi +``` + +그런 다음 컨테이너는 최대 800Gi의 임의 바이트 수의 특별한 스토리지를 요청할 수 있다. + +## 정리 + +다음은 노드에서 동글 알림을 제거하는 PATCH 요청이다. + +``` +PATCH /api/v1/nodes/<your-node-name>/status HTTP/1.1 +Accept: application/json +Content-Type: application/json-patch+json +Host: k8s-master:8080 + +[ + { + "op": "remove", + "path": "/status/capacity/example.com~1dongle", + } +] +``` + +쿠버네티스 API 서버에 요청을 쉽게 보낼 수 있도록 프록시를 시작한다. + +```shell +kubectl proxy +``` + +다른 명령 창에서 HTTP PATCH 요청을 보낸다. +`<your-node-name>`을 노드의 이름으로 바꾼다. + +```shell +curl --header "Content-Type: application/json-patch+json" \ +--request PATCH \ +--data '[{"op": "remove", "path": "/status/capacity/example.com~1dongle"}]' \ +http://localhost:8001/api/v1/nodes/<your-node-name>/status +``` + +동글 알림이 제거되었는지 확인한다. + +``` +kubectl describe node <your-node-name> | grep dongle +``` + +(출력이 보이지 않아야 함) + + + + +## {{% heading "whatsnext" %}} + + +### 애플리케이션 개발자를 위한 문서 + +* [컨테이너에 확장 리소스 할당하기](/docs/tasks/configure-pod-container/extended-resource/) + +### 클러스터 관리자를 위한 문서 + +* [네임스페이스에 대한 메모리의 최소 및 최대 제약 조건 구성](/ko/docs/tasks/administer-cluster/manage-resources/memory-constraint-namespace/) +* [네임스페이스에 대한 CPU의 최소 및 최대 제약 조건 구성](/ko/docs/tasks/administer-cluster/manage-resources/cpu-constraint-namespace/) diff --git a/content/ko/docs/tasks/administer-cluster/kubeadm/adding-windows-nodes.md b/content/ko/docs/tasks/administer-cluster/kubeadm/adding-windows-nodes.md index 0388e2542b..2cf5a8b6e5 100644 --- a/content/ko/docs/tasks/administer-cluster/kubeadm/adding-windows-nodes.md +++ b/content/ko/docs/tasks/administer-cluster/kubeadm/adding-windows-nodes.md @@ -1,5 +1,5 @@ --- -title: Windows 노드 추가 +title: 윈도우 노드 추가 min-kubernetes-server-version: 1.17 content_type: tutorial weight: 30 @@ -9,7 +9,7 @@ weight: 30 {{< feature-state for_k8s_version="v1.18" state="beta" >}} -쿠버네티스를 사용하여 리눅스와 Windows 노드를 혼합하여 실행할 수 있으므로, 리눅스에서 실행되는 파드와 Windows에서 실행되는 파드를 혼합할 수 있다. 이 페이지는 Windows 노드를 클러스터에 등록하는 방법을 보여준다. +쿠버네티스를 사용하여 리눅스와 윈도우 노드를 혼합하여 실행할 수 있으므로, 리눅스에서 실행되는 파드와 윈도우에서 실행되는 파드를 혼합할 수 있다. 이 페이지는 윈도우 노드를 클러스터에 등록하는 방법을 보여준다. @@ -17,8 +17,8 @@ weight: 30 ## {{% heading "prerequisites" %}} {{< version-check >}} -* Windows 컨테이너를 호스팅하는 Windows 노드를 구성하려면 -[Windows Server 2019 라이선스](https://www.microsoft.com/en-us/cloud-platform/windows-server-pricing) 이상이 필요하다. +* 윈도우 컨테이너를 호스팅하는 윈도우 노드를 구성하려면 +[윈도우 서버 2019 라이선스](https://www.microsoft.com/en-us/cloud-platform/windows-server-pricing) 이상이 필요하다. VXLAN/오버레이 네트워킹을 사용하는 경우 [KB4489899](https://support.microsoft.com/help/4489899)도 설치되어 있어야 한다. * 컨트롤 플레인에 접근할 수 있는 리눅스 기반의 쿠버네티스 kubeadm 클러스터([kubeadm을 사용하여 단일 컨트롤 플레인 클러스터 생성](/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm/) 참고)가 필요하다. @@ -29,15 +29,15 @@ VXLAN/오버레이 네트워킹을 사용하는 경우 [KB4489899](https://suppo ## {{% heading "objectives" %}} -* 클러스터에 Windows 노드 등록 -* 리눅스 및 Windows의 파드와 서비스가 서로 통신할 수 있도록 네트워킹 구성 +* 클러스터에 윈도우 노드 등록 +* 리눅스 및 윈도우의 파드와 서비스가 서로 통신할 수 있도록 네트워킹 구성 <!-- lessoncontent --> -## 시작하기: 클러스터에 Windows 노드 추가 +## 시작하기: 클러스터에 윈도우 노드 추가 ### 네트워킹 구성 @@ -75,7 +75,7 @@ VXLAN/오버레이 네트워킹을 사용하는 경우 [KB4489899](https://suppo } ``` - {{< note >}}리눅스의 플란넬이 Windows의 플란넬과 상호 운용되도록 하려면 VNI를 4096으로, 포트를 4789로 설정해야 한다. 이 필드들에 대한 설명은 [VXLAN 문서](https://github.com/coreos/flannel/blob/master/Documentation/backends.md#vxlan)를 + {{< note >}}리눅스의 플란넬이 윈도우의 플란넬과 상호 운용되도록 하려면 VNI를 4096으로, 포트를 4789로 설정해야 한다. 이 필드들에 대한 설명은 [VXLAN 문서](https://github.com/coreos/flannel/blob/master/Documentation/backends.md#vxlan)를 참고한다.{{< /note >}} {{< note >}}L2Bridge/Host-gateway 모드를 대신 사용하려면 `Type` 의 값을 `"host-gw"` 로 변경하고 `VNI` 와 `Port` 를 생략한다.{{< /note >}} @@ -102,9 +102,9 @@ VXLAN/오버레이 네트워킹을 사용하는 경우 [KB4489899](https://suppo kube-system kube-flannel-ds-54954 1/1 Running 0 1m ``` -1. Windows 플란넬 및 kube-proxy 데몬셋 추가 +1. 윈도우 플란넬 및 kube-proxy 데몬셋 추가 - 이제 Windows 호환 버전의 플란넬과 kube-proxy를 추가할 수 있다. 호환 가능한 + 이제 윈도우 호환 버전의 플란넬과 kube-proxy를 추가할 수 있다. 호환 가능한 kube-proxy 버전을 얻으려면, 이미지의 태그를 대체해야 한다. 다음의 예시는 쿠버네티스 {{< param "fullversion" >}}의 사용법을 보여주지만, 사용자의 배포에 맞게 버전을 조정해야 한다. @@ -118,7 +118,7 @@ VXLAN/오버레이 네트워킹을 사용하는 경우 [KB4489899](https://suppo {{< /note >}} {{< note >}} -Windows 노드에서 이더넷이 아닌 다른 인터페이스(예: "Ethernet0 2")를 사용하는 경우, flannel-host-gw.yml이나 flannel-overlay.yml 파일에서 다음 라인을 수정한다. +윈도우 노드에서 이더넷이 아닌 다른 인터페이스(예: "Ethernet0 2")를 사용하는 경우, flannel-host-gw.yml이나 flannel-overlay.yml 파일에서 다음 라인을 수정한다. ```powershell wins cli process run --path /k/flannel/setup.exe --args "--mode=overlay --interface=Ethernet" @@ -134,14 +134,14 @@ curl -L https://github.com/kubernetes-sigs/sig-windows-tools/releases/latest/dow -### Windows 워커 노드 조인(joining) +### 윈도우 워커 노드 조인(joining) {{< note >}} `Containers` 기능을 설치하고 도커를 설치해야 한다. -[Windows Server에 Docker Engine - Enterprise 설치](https://docs.docker.com/ee/docker-ee/windows/docker-ee/#install-docker-engine---enterprise)에서 설치에 대한 내용을 참고할 수 있다. +[윈도우 서버에 Docker Engine - Enterprise 설치](https://docs.docker.com/ee/docker-ee/windows/docker-ee/#install-docker-engine---enterprise)에서 설치에 대한 내용을 참고할 수 있다. {{< /note >}} {{< note >}} -Windows 섹션의 모든 코드 스니펫(snippet)은 Windows 워커 노드의 +윈도우 섹션의 모든 코드 스니펫(snippet)은 윈도우 워커 노드의 높은 권한(관리자)이 있는 PowerShell 환경에서 실행해야 한다. {{< /note >}} @@ -160,7 +160,7 @@ Windows 섹션의 모든 코드 스니펫(snippet)은 Windows 워커 노드의 #### 설치 확인 -이제 다음을 실행하여 클러스터에서 Windows 노드를 볼 수 있다. +이제 다음을 실행하여 클러스터에서 윈도우 노드를 볼 수 있다. ```bash kubectl get nodes -o wide @@ -180,6 +180,6 @@ flannel 파드가 실행되면, 노드는 `Ready` 상태가 되고 워크로드 ## {{% heading "whatsnext" %}} -- [Windows kubeadm 노드 업그레이드](/ko/docs/tasks/administer-cluster/kubeadm/upgrading-windows-nodes) +- [윈도우 kubeadm 노드 업그레이드](/ko/docs/tasks/administer-cluster/kubeadm/upgrading-windows-nodes) diff --git a/content/ko/docs/tasks/administer-cluster/kubeadm/kubeadm-certs.md b/content/ko/docs/tasks/administer-cluster/kubeadm/kubeadm-certs.md index dc17eb9cdc..ac3ac3f695 100644 --- a/content/ko/docs/tasks/administer-cluster/kubeadm/kubeadm-certs.md +++ b/content/ko/docs/tasks/administer-cluster/kubeadm/kubeadm-certs.md @@ -10,15 +10,11 @@ weight: 10 [kubeadm](/docs/reference/setup-tools/kubeadm/kubeadm/)으로 생성된 클라이언트 인증서는 1년 후에 만료된다. 이 페이지는 kubeadm으로 인증서 갱신을 관리하는 방법을 설명한다. - - ## {{% heading "prerequisites" %}} [쿠버네티스의 PKI 인증서와 요구 조건](/ko/docs/setup/best-practices/certificates/)에 익숙해야 한다. - - <!-- steps --> ## 사용자 정의 인증서 사용 {#custom-certificates} @@ -153,33 +149,29 @@ HA 클러스터를 실행 중인 경우, 모든 컨트롤 플레인 노드에서 ### 서명자 설정 쿠버네티스 인증 기관(Certificate Authority)은 기본적으로 작동하지 않는다. -[cert-manager][cert-manager-issuer] 와 같은 외부 서명자를 설정하거나, 빌트인 서명자를 사용할 수 있다. +[cert-manager](https://docs.cert-manager.io/en/latest/tasks/issuers/setup-ca.html)와 같은 외부 서명자를 설정하거나, 빌트인 서명자를 사용할 수 있다. -빌트인 서명자는 [`kube-controller-manager`][kcm] 의 일부이다. +빌트인 서명자는 [`kube-controller-manager`](/docs/reference/command-line-tools-reference/kube-controller-manager/)의 일부이다. 빌트인 서명자를 활성화하려면, `--cluster-signing-cert-file` 와 `--cluster-signing-key-file` 플래그를 전달해야 한다. -새 클러스터를 생성하는 경우, kubeadm [구성 파일][config]을 사용할 수 있다. +새 클러스터를 생성하는 경우, kubeadm [구성 파일](https://godoc.org/k8s.io/kubernetes/cmd/kubeadm/app/apis/kubeadm/v1beta2)을 사용할 수 있다. - ```yaml - apiVersion: kubeadm.k8s.io/v1beta2 - kind: ClusterConfiguration - controllerManager: - extraArgs: - cluster-signing-cert-file: /etc/kubernetes/pki/ca.crt - cluster-signing-key-file: /etc/kubernetes/pki/ca.key - ``` - -[cert-manager-issuer]: https://docs.cert-manager.io/en/latest/tasks/issuers/setup-ca.html -[kcm]: /docs/reference/command-line-tools-reference/kube-controller-manager/ -[config]: https://godoc.org/k8s.io/kubernetes/cmd/kubeadm/app/apis/kubeadm/v1beta2 +```yaml +apiVersion: kubeadm.k8s.io/v1beta2 +kind: ClusterConfiguration +controllerManager: + extraArgs: + cluster-signing-cert-file: /etc/kubernetes/pki/ca.crt + cluster-signing-key-file: /etc/kubernetes/pki/ca.key +``` ### 인증서 서명 요청(CSR) 생성 `kubeadm alpha certs renew --use-api` 로 쿠버네티스 인증서 API에 대한 인증서 서명 요청을 만들 수 있다. -[cert-manager][cert-manager] 와 같은 외부 서명자를 설정하면, 인증서 서명 요청(CSR)이 자동으로 승인된다. -그렇지 않으면, [`kubectl certificate`][certs] 명령을 사용하여 인증서를 수동으로 승인해야 한다. +[cert-manager](https://github.com/jetstack/cert-manager)와 같은 외부 서명자를 설정하면, 인증서 서명 요청(CSR)이 자동으로 승인된다. +그렇지 않으면, [`kubectl certificate`](/ko/docs/setup/best-practices/certificates/) 명령을 사용하여 인증서를 수동으로 승인해야 한다. 다음의 kubeadm 명령은 승인할 인증서 이름을 출력한 다음, 승인이 발생하기를 차단하고 기다린다. ```shell @@ -195,7 +187,7 @@ sudo kubeadm alpha certs renew apiserver --use-api & 외부 서명자를 설정하면, 인증서 서명 요청(CSR)이 자동으로 승인된다. -그렇지 않으면, [`kubectl certificate`][certs] 명령을 사용하여 인증서를 수동으로 승인해야 한다. 예를 들어 다음과 같다. +그렇지 않으면, [`kubectl certificate`](/ko/docs/setup/best-practices/certificates/) 명령을 사용하여 인증서를 수동으로 승인해야 한다. 예를 들어 다음과 같다. ```shell kubectl certificate approve kubeadm-cert-kube-apiserver-ld526 @@ -227,18 +219,16 @@ CSR과 함께 제공되는 개인 키가 모두 출력된다. `kubeadm init` 과 마찬가지로 출력 디렉터리를 `--csr-dir` 플래그로 지정할 수 있다. CSR에는 인증서 이름, 도메인 및 IP가 포함되지만, 용도를 지정하지는 않는다. -인증서를 발행할 때 [올바른 인증서 용도][cert-table]를 지정하는 것은 CA의 책임이다. +인증서를 발행할 때 [올바른 인증서 용도](/ko/docs/setup/best-practices/certificates/#모든-인증서)를 지정하는 것은 CA의 책임이다. -* `openssl` 의 경우 [`openssl ca` command][openssl-ca] 명령으로 수행한다. -* `cfssl` 의 경우 [설정 파일에 용도][cfssl-usages]를 지정한다. +* `openssl` 의 경우 + [`openssl ca` 명령](https://superuser.com/questions/738612/openssl-ca-keyusage-extension)으로 수행한다. +* `cfssl` 의 경우 [설정 파일에 용도](https://github.com/cloudflare/cfssl/blob/master/doc/cmd/cfssl.txt#L170)를 지정한다. 선호하는 방법으로 인증서에 서명한 후, 인증서와 개인 키를 PKI 디렉터리(기본적으로 `/etc/kubernetes/pki`)에 복사해야 한다. -[cert-manager]: https://github.com/jetstack/cert-manager -[openssl-ca]: https://superuser.com/questions/738612/openssl-ca-keyusage-extension -[cfssl-usages]: https://github.com/cloudflare/cfssl/blob/master/doc/cmd/cfssl.txt#L170 -[certs]: /ko/docs/setup/best-practices/certificates/ -[cert-cas]: /ko/docs/setup/best-practices/certificates/#단일-루트-ca -[cert-table]: /ko/docs/setup/best-practices/certificates/#모든-인증서 +## 인증 기관(CA) 순환(rotation) {#certificate-authority-rotation} +Kubeadm은 CA 인증서의 순환이나 교체 기능을 기본적으로 지원하지 않는다. +CA의 수동 순환이나 교체에 대한 보다 상세한 정보는 [CA 인증서 수동 순환](/docs/tasks/tls/manual-rotation-of-ca-certificates/) 문서를 참조한다. diff --git a/content/ko/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade.md b/content/ko/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade.md index 452cfb1865..9e48ea900a 100644 --- a/content/ko/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade.md +++ b/content/ko/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade.md @@ -242,7 +242,7 @@ min-kubernetes-server-version: 1.18 - CNI 제공자 플러그인을 수동으로 업그레이드한다. CNI(컨테이너 네트워크 인터페이스) 제공자는 자체 업그레이드 지침을 따를 수 있다. - [애드온](/docs/concepts/cluster-administration/addons/) 페이지에서 + [애드온](/ko/docs/concepts/cluster-administration/addons/) 페이지에서 사용하는 CNI 제공자를 찾고 추가 업그레이드 단계가 필요한지 여부를 확인한다. CNI 제공자가 데몬셋(DaemonSet)으로 실행되는 경우 추가 컨트롤 플레인 노드에는 이 단계가 필요하지 않다. @@ -294,6 +294,7 @@ sudo kubeadm upgrade apply kubelet을 다시 시작한다. ```shell +sudo systemctl daemon-reload sudo systemctl restart kubelet ``` @@ -372,6 +373,7 @@ sudo systemctl restart kubelet - kubelet을 다시 시작한다. ```shell + sudo systemctl daemon-reload sudo systemctl restart kubelet ``` diff --git a/content/ko/docs/tasks/administer-cluster/kubeadm/upgrading-windows-nodes.md b/content/ko/docs/tasks/administer-cluster/kubeadm/upgrading-windows-nodes.md index 779e6fe86a..66adcb6a9d 100644 --- a/content/ko/docs/tasks/administer-cluster/kubeadm/upgrading-windows-nodes.md +++ b/content/ko/docs/tasks/administer-cluster/kubeadm/upgrading-windows-nodes.md @@ -1,5 +1,5 @@ --- -title: Windows 노드 업그레이드 +title: 윈도우 노드 업그레이드 min-kubernetes-server-version: 1.17 content_type: task weight: 40 @@ -9,7 +9,7 @@ weight: 40 {{< feature-state for_k8s_version="v1.18" state="beta" >}} -이 페이지는 [kubeadm으로 생성된](/ko/docs/tasks/administer-cluster/kubeadm/adding-windows-nodes) Windows 노드를 업그레이드하는 방법을 설명한다. +이 페이지는 [kubeadm으로 생성된](/ko/docs/tasks/administer-cluster/kubeadm/adding-windows-nodes) 윈도우 노드를 업그레이드하는 방법을 설명한다. @@ -18,7 +18,7 @@ weight: 40 {{< include "task-tutorial-prereqs.md" >}} {{< version-check >}} * [남은 kubeadm 클러스터를 업그레이드하는 프로세스](/ko/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade)에 -익숙해져야 한다. Windows 노드를 +익숙해져야 한다. 윈도우 노드를 업그레이드하기 전에 컨트롤 플레인 노드를 업그레이드해야 한다. @@ -30,7 +30,7 @@ weight: 40 ### kubeadm 업그레이드 -1. Windows 노드에서, kubeadm을 업그레이드한다. +1. 윈도우 노드에서, kubeadm을 업그레이드한다. ```powershell # replace {{< param "fullversion" >}} with your desired version @@ -56,7 +56,7 @@ weight: 40 ### kubelet 구성 업그레이드 -1. Windows 노드에서, 다음의 명령을 호출하여 새 kubelet 구성을 동기화한다. +1. 윈도우 노드에서, 다음의 명령을 호출하여 새 kubelet 구성을 동기화한다. ```powershell kubeadm upgrade node @@ -64,7 +64,7 @@ weight: 40 ### kubelet 업그레이드 -1. Windows 노드에서, kubelet을 업그레이드하고 다시 시작한다. +1. 윈도우 노드에서, kubelet을 업그레이드하고 다시 시작한다. ```powershell stop-service kubelet diff --git a/content/ko/docs/tasks/administer-cluster/manage-resources/cpu-constraint-namespace.md b/content/ko/docs/tasks/administer-cluster/manage-resources/cpu-constraint-namespace.md index 494a09418c..43160db786 100644 --- a/content/ko/docs/tasks/administer-cluster/manage-resources/cpu-constraint-namespace.md +++ b/content/ko/docs/tasks/administer-cluster/manage-resources/cpu-constraint-namespace.md @@ -265,7 +265,4 @@ kubectl delete namespace constraints-cpu-example * [컨테이너와 파드 CPU 리소스 할당](/docs/tasks/configure-pod-container/assign-cpu-resource/) -* [파드에 대한 서비스 품질(QoS) 구성](/docs/tasks/configure-pod-container/quality-service-pod/) - - - +* [파드에 대한 서비스 품질(QoS) 구성](/ko/docs/tasks/configure-pod-container/quality-service-pod/) diff --git a/content/ko/docs/tasks/administer-cluster/manage-resources/cpu-default-namespace.md b/content/ko/docs/tasks/administer-cluster/manage-resources/cpu-default-namespace.md index 769f0bfb09..ab77c226b0 100644 --- a/content/ko/docs/tasks/administer-cluster/manage-resources/cpu-default-namespace.md +++ b/content/ko/docs/tasks/administer-cluster/manage-resources/cpu-default-namespace.md @@ -188,6 +188,4 @@ kubectl delete namespace default-cpu-example * [컨테이너 및 파드 CPU 리소스 할당](/docs/tasks/configure-pod-container/assign-cpu-resource/) -* [파드에 대한 서비스 품질(QoS) 구성](/docs/tasks/configure-pod-container/quality-service-pod/) - - +* [파드에 대한 서비스 품질(QoS) 구성](/ko/docs/tasks/configure-pod-container/quality-service-pod/) diff --git a/content/ko/docs/tasks/administer-cluster/manage-resources/memory-constraint-namespace.md b/content/ko/docs/tasks/administer-cluster/manage-resources/memory-constraint-namespace.md index cf3cd826f6..19163fd7e7 100644 --- a/content/ko/docs/tasks/administer-cluster/manage-resources/memory-constraint-namespace.md +++ b/content/ko/docs/tasks/administer-cluster/manage-resources/memory-constraint-namespace.md @@ -265,6 +265,4 @@ kubectl delete namespace constraints-mem-example * [컨테이너 및 파드 CPU 리소스 할당](/docs/tasks/configure-pod-container/assign-cpu-resource/) -* [파드에 대한 서비스 품질(QoS) 구성](/docs/tasks/configure-pod-container/quality-service-pod/) - - +* [파드에 대한 서비스 품질(QoS) 구성](/ko/docs/tasks/configure-pod-container/quality-service-pod/) diff --git a/content/ko/docs/tasks/administer-cluster/manage-resources/memory-default-namespace.md b/content/ko/docs/tasks/administer-cluster/manage-resources/memory-default-namespace.md index c735bc1a72..a74d492e5a 100644 --- a/content/ko/docs/tasks/administer-cluster/manage-resources/memory-default-namespace.md +++ b/content/ko/docs/tasks/administer-cluster/manage-resources/memory-default-namespace.md @@ -196,6 +196,4 @@ kubectl delete namespace default-mem-example * [컨테이너 및 파드 CPU 리소스 할당](/docs/tasks/configure-pod-container/assign-cpu-resource/) -* [파드에 대한 서비스 품질(QoS) 구성](/docs/tasks/configure-pod-container/quality-service-pod/) - - +* [파드에 대한 서비스 품질(QoS) 구성](/ko/docs/tasks/configure-pod-container/quality-service-pod/) diff --git a/content/ko/docs/tasks/administer-cluster/manage-resources/quota-memory-cpu-namespace.md b/content/ko/docs/tasks/administer-cluster/manage-resources/quota-memory-cpu-namespace.md index ce16eaeef1..f17a387a5b 100644 --- a/content/ko/docs/tasks/administer-cluster/manage-resources/quota-memory-cpu-namespace.md +++ b/content/ko/docs/tasks/administer-cluster/manage-resources/quota-memory-cpu-namespace.md @@ -172,6 +172,4 @@ kubectl delete namespace quota-mem-cpu-example * [컨테이너 및 파드 CPU 리소스 할당](/docs/tasks/configure-pod-container/assign-cpu-resource/) -* [파드에 대한 서비스 품질(QoS) 구성](/docs/tasks/configure-pod-container/quality-service-pod/) - - +* [파드에 대한 서비스 품질(QoS) 구성](/ko/docs/tasks/configure-pod-container/quality-service-pod/) diff --git a/content/ko/docs/tasks/administer-cluster/manage-resources/quota-pod-namespace.md b/content/ko/docs/tasks/administer-cluster/manage-resources/quota-pod-namespace.md index a90d2263d3..9c4d787429 100644 --- a/content/ko/docs/tasks/administer-cluster/manage-resources/quota-pod-namespace.md +++ b/content/ko/docs/tasks/administer-cluster/manage-resources/quota-pod-namespace.md @@ -133,6 +133,4 @@ kubectl delete namespace quota-pod-example * [컨테이너 및 파드 CPU 리소스 할당](/docs/tasks/configure-pod-container/assign-cpu-resource/) -* [파드에 대한 서비스 품질(QoS) 구성](/docs/tasks/configure-pod-container/quality-service-pod/) - - +* [파드에 대한 서비스 품질(QoS) 구성](/ko/docs/tasks/configure-pod-container/quality-service-pod/) diff --git a/content/ko/docs/tasks/administer-cluster/network-policy-provider/calico-network-policy.md b/content/ko/docs/tasks/administer-cluster/network-policy-provider/calico-network-policy.md index 2d7f856e46..bee3c94069 100644 --- a/content/ko/docs/tasks/administer-cluster/network-policy-provider/calico-network-policy.md +++ b/content/ko/docs/tasks/administer-cluster/network-policy-provider/calico-network-policy.md @@ -1,5 +1,4 @@ --- -reviewers: title: 네트워크 폴리시로 캘리코(Calico) 사용하기 content_type: task weight: 10 @@ -50,6 +49,4 @@ Kubeadm을 이용해서 15분 이내에 지역 단일 호스트 캘리코 클러 ## {{% heading "whatsnext" %}} 클러스터가 동작하면, 쿠버네티스 네트워크 폴리시(NetworkPolicy)를 시도하기 위해 -[네트워크 폴리시 선언하기](/docs/tasks/administer-cluster/declare-network-policy/)를 따라 할 수 있다. - - +[네트워크 폴리시 선언하기](/ko/docs/tasks/administer-cluster/declare-network-policy/)를 따라 할 수 있다. diff --git a/content/ko/docs/tasks/administer-cluster/network-policy-provider/cilium-network-policy.md b/content/ko/docs/tasks/administer-cluster/network-policy-provider/cilium-network-policy.md index 5435bcf67a..f41b5cd716 100644 --- a/content/ko/docs/tasks/administer-cluster/network-policy-provider/cilium-network-policy.md +++ b/content/ko/docs/tasks/administer-cluster/network-policy-provider/cilium-network-policy.md @@ -48,7 +48,7 @@ Minikube에서 실리움의 데몬셋 구성과 적절한 RBAC 설정을 포함 간단한 ``올인원`` YAML 파일로 배포할 수 있다. ```shell -kubectl create -f https://raw.githubusercontent.com/cilium/cilium/v1.6/install/kubernetes/quick-install.yaml +kubectl create -f https://raw.githubusercontent.com/cilium/cilium/v1.8/install/kubernetes/quick-install.yaml ``` ``` configmap/cilium-config created @@ -102,9 +102,6 @@ cilium-6rxbd 1/1 Running 0 1m 클러스터가 동작하면, 실리움으로 쿠버네티스 네트워크 폴리시를 시도하기 위해 -[네트워크 폴리시 선언하기](/docs/tasks/administer-cluster/declare-network-policy/)를 따라 할 수 있다. +[네트워크 폴리시 선언하기](/ko/docs/tasks/administer-cluster/declare-network-policy/)를 따라 할 수 있다. 재미있게 즐기고, 질문이 있다면 [실리움 슬랙 채널](https://cilium.herokuapp.com/)을 이용하여 연락한다. - - - diff --git a/content/ko/docs/tasks/administer-cluster/network-policy-provider/kube-router-network-policy.md b/content/ko/docs/tasks/administer-cluster/network-policy-provider/kube-router-network-policy.md index 71a96ed8ee..4c16cb7385 100644 --- a/content/ko/docs/tasks/administer-cluster/network-policy-provider/kube-router-network-policy.md +++ b/content/ko/docs/tasks/administer-cluster/network-policy-provider/kube-router-network-policy.md @@ -1,10 +1,11 @@ --- -reviewers: title: 네트워크 폴리시로 큐브 라우터(Kube-router) 사용하기 content_type: task weight: 30 --- + + <!-- overview --> 이 페이지는 네트워크 폴리시(NetworkPolicy)로 [큐브 라우터(Kube-router)](https://github.com/cloudnativelabs/kube-router)를 사용하는 방법을 살펴본다. @@ -21,7 +22,4 @@ weight: 30 ## {{% heading "whatsnext" %}} -큐브 라우터 애드온을 설치한 후에는, 쿠버네티스 네트워크 폴리시를 시도하기 위해 [네트워크 폴리시 선언하기](/docs/tasks/administer-cluster/declare-network-policy/)를 따라 할 수 있다. - - - +큐브 라우터 애드온을 설치한 후에는, 쿠버네티스 네트워크 폴리시를 시도하기 위해 [네트워크 폴리시 선언하기](/ko/docs/tasks/administer-cluster/declare-network-policy/)를 따라 할 수 있다. diff --git a/content/ko/docs/tasks/administer-cluster/network-policy-provider/romana-network-policy.md b/content/ko/docs/tasks/administer-cluster/network-policy-provider/romana-network-policy.md index dceaf495fc..d59cdd3e15 100644 --- a/content/ko/docs/tasks/administer-cluster/network-policy-provider/romana-network-policy.md +++ b/content/ko/docs/tasks/administer-cluster/network-policy-provider/romana-network-policy.md @@ -1,10 +1,11 @@ --- -reviewers: title: 네트워크 폴리시로 로마나(Romana) content_type: task weight: 40 --- + + <!-- overview --> 이 페이지는 네트워크 폴리시(NetworkPolicy)로 로마나(Romana)를 사용하는 방법을 살펴본다. @@ -37,8 +38,4 @@ Kubeadm을 위한 [컨테이너화된 설치 안내서](https://github.com/roman ## {{% heading "whatsnext" %}} -로마나를 설치한 후에는, 쿠버네티스 네트워크 폴리시를 시도하기 위해 [네트워크 폴리시 선언하기](/docs/tasks/administer-cluster/declare-network-policy/)를 따라 할 수 있다. - - - - +로마나를 설치한 후에는, 쿠버네티스 네트워크 폴리시를 시도하기 위해 [네트워크 폴리시 선언하기](/ko/docs/tasks/administer-cluster/declare-network-policy/)를 따라 할 수 있다. diff --git a/content/ko/docs/tasks/administer-cluster/network-policy-provider/weave-network-policy.md b/content/ko/docs/tasks/administer-cluster/network-policy-provider/weave-network-policy.md index d5fef95e75..3aea719c56 100644 --- a/content/ko/docs/tasks/administer-cluster/network-policy-provider/weave-network-policy.md +++ b/content/ko/docs/tasks/administer-cluster/network-policy-provider/weave-network-policy.md @@ -1,5 +1,4 @@ --- -reviewers: title: 네트워크 폴리시로 위브넷(Weave Net) 사용하기 content_type: task weight: 50 @@ -53,8 +52,4 @@ weave-net-pmw8w 2/2 Running 0 9d ## {{% heading "whatsnext" %}} -위브넷 애드온을 설치하고 나서, 쿠버네티스 네트워크 폴리시를 시도하기 위해 [네트워크 폴리시 선언하기](/docs/tasks/administer-cluster/declare-network-policy/)를 따라 할 수 있다. 질문이 있으면 [슬랙 #weave-community 이나 Weave 유저그룹](https://github.com/weaveworks/weave#getting-help)에 연락한다. - - - - +위브넷 애드온을 설치하고 나서, 쿠버네티스 네트워크 폴리시를 시도하기 위해 [네트워크 폴리시 선언하기](/ko/docs/tasks/administer-cluster/declare-network-policy/)를 따라 할 수 있다. 질문이 있으면 [슬랙 #weave-community 이나 Weave 유저그룹](https://github.com/weaveworks/weave#getting-help)에 연락한다. diff --git a/content/ko/docs/tasks/configure-pod-container/_index.md b/content/ko/docs/tasks/configure-pod-container/_index.md index 560261ecad..e43910867f 100644 --- a/content/ko/docs/tasks/configure-pod-container/_index.md +++ b/content/ko/docs/tasks/configure-pod-container/_index.md @@ -1,4 +1,5 @@ --- title: "파드와 컨테이너 설정" +description: 파드와 컨테이너에 대한 공통 구성 태스크들을 수행한다. weight: 20 --- diff --git a/content/ko/docs/tasks/configure-pod-container/assign-memory-resource.md b/content/ko/docs/tasks/configure-pod-container/assign-memory-resource.md index 06e8f645b2..980d71d9b5 100644 --- a/content/ko/docs/tasks/configure-pod-container/assign-memory-resource.md +++ b/content/ko/docs/tasks/configure-pod-container/assign-memory-resource.md @@ -25,7 +25,8 @@ weight: 10 서비스 실행이 필요하다. 이미 실행중인 metrics-server가 있다면 다음 단계를 건너뛸 수 있다. -Minikube를 사용 중이라면, 다음 명령어를 실행해 metric-server를 활성화 할 수 있다. +Minikube를 사용 중이라면, 다음 명령어를 실행해 metric-server를 +활성화할 수 있다. ```shell minikube addons enable metrics-server @@ -52,7 +53,8 @@ v1beta1.metrics.k8s.io ## 네임스페이스 생성 -이 예제에서 생성할 자원과 클러스터 내 나머지를 분리하기 위해 네임스페이스를 생성한다. +이 예제에서 생성할 자원과 클러스터 내 나머지를 분리하기 위해 +네임스페이스를 생성한다. ```shell kubectl create namespace mem-example @@ -110,8 +112,9 @@ resources: kubectl top pod memory-demo --namespace=mem-example ``` -출력은 파드가 약 150MiB 해당하는 약 162,900,000 바이트 메모리를 사용하는 것을 보여준다. -이는 파드의 100 MiB 요청 보다 많으나 파드의 200 MiB 상한보다는 적다. +출력은 파드가 약 150 MiB 해당하는 약 162,900,000 바이트 메모리를 사용하는 것을 보여준다. +이는 파드의 100 MiB 요청 보다 많으나 +파드의 200 MiB 상한보다는 적다. ``` NAME CPU(cores) MEMORY(bytes) @@ -138,7 +141,7 @@ kubectl delete pod memory-demo --namespace=mem-example {{< codenew file="pods/resource/memory-request-limit-2.yaml" >}} -구성 파일의 'args' 섹션에서 컨테이너가 +구성 파일의 `args` 섹션에서 컨테이너가 100 MiB 상한을 훨씬 초과하는 250 MiB의 메모리를 할당하려는 것을 볼 수 있다. 파드 생성: @@ -242,7 +245,8 @@ kubectl delete pod memory-demo-2 --namespace=mem-example 이 예제에서는 메모리 요청량이 너무 커 클러스터 내 모든 노드의 용량을 초과하는 파드를 생성한다. 다음은 클러스터 내 모든 노드의 용량을 초과할 수 있는 1000 GiB 메모리 요청을 포함하는 -컨테이너를 갖는 파드의 구성 파일이다. +컨테이너를 갖는 +파드의 구성 파일이다. {{< codenew file="pods/resource/memory-request-limit-3.yaml" >}} @@ -302,8 +306,7 @@ kubectl delete pod memory-demo-3 --namespace=mem-example 컨테이너에 메모리 상한을 지정하지 않으면 다음 중 하나가 적용된다. * 컨테이너가 사용할 수 있는 메모리 상한은 없다. 컨테이너가 -실행 중인 노드에서 사용 가능한 모든 메모리를 사용하여 OOM Killer가 실행 될 수 있다. 또한 메모리 부족으로 인한 종료 시 메모리 상한이 -없는 컨테이너가 종료될 가능성이 크다. +실행 중인 노드에서 사용 가능한 모든 메모리를 사용하여 OOM Killer가 실행될 수 있다. 또한 메모리 부족으로 인한 종료 시 메모리 상한이 없는 컨테이너가 종료될 가능성이 크다. * 기본 메모리 상한을 갖는 네임스페이스 내에서 실행중인 컨테이너는 자동으로 기본 메모리 상한이 할당된다. 클러스터 관리자들은 @@ -337,22 +340,20 @@ kubectl delete namespace mem-example * [CPU 리소스를 컨테이너와 파드에 할당](/docs/tasks/configure-pod-container/assign-cpu-resource/) -* [파드에 서비스 품질 설정](/docs/tasks/configure-pod-container/quality-service-pod/) +* [파드에 서비스 품질 설정](/ko/docs/tasks/configure-pod-container/quality-service-pod/) ### 클러스터 관리자들을 위한 -* [네임스페이스에 기본 메모리 요청량 및 상한을 구성](/docs/tasks/administer-cluster/memory-default-namespace/) +* [네임스페이스에 기본 메모리 요청량 및 상한을 구성](/ko/docs/tasks/administer-cluster/manage-resources/memory-default-namespace/) -* [네임스페이스에 기본 CPU 요청량 및 상한을 구성](/docs/tasks/administer-cluster/cpu-default-namespace/) +* [네임스페이스에 기본 CPU 요청량 및 상한을 구성](/ko/docs/tasks/administer-cluster/manage-resources/cpu-default-namespace/) -* [네임스페이스에 최소 및 최대 메모리 제약 조건 구성](/docs/tasks/administer-cluster/memory-constraint-namespace/) +* [네임스페이스에 최소 및 최대 메모리 제약 조건 구성](/ko/docs/tasks/administer-cluster/manage-resources/memory-constraint-namespace/) -* [네임스페이스에 최소 및 최대 CPU 제약 조건 구성](/docs/tasks/administer-cluster/cpu-constraint-namespace/) +* [네임스페이스에 최소 및 최대 CPU 제약 조건 구성](/ko/docs/tasks/administer-cluster/manage-resources/cpu-constraint-namespace/) -* [네임스페이스에 메모리 및 CPU 할당량 구성](/docs/tasks/administer-cluster/quota-memory-cpu-namespace/) - -* [네임스페이스에 파드 할당량 구성](/docs/tasks/administer-cluster/quota-pod-namespace/) - -* [API 오브젝트에 할당량 구성 ](/docs/tasks/administer-cluster/quota-api-object/) +* [네임스페이스에 메모리 및 CPU 할당량 구성](/ko/docs/tasks/administer-cluster/manage-resources/quota-memory-cpu-namespace/) +* [네임스페이스에 파드 할당량 구성](/ko/docs/tasks/administer-cluster/manage-resources/quota-pod-namespace/) +* [API 오브젝트에 할당량 구성](/docs/tasks/administer-cluster/quota-api-object/) diff --git a/content/ko/docs/tasks/configure-pod-container/assign-pods-nodes-using-node-affinity.md b/content/ko/docs/tasks/configure-pod-container/assign-pods-nodes-using-node-affinity.md index bc1446946d..5ad8b72d52 100644 --- a/content/ko/docs/tasks/configure-pod-container/assign-pods-nodes-using-node-affinity.md +++ b/content/ko/docs/tasks/configure-pod-container/assign-pods-nodes-using-node-affinity.md @@ -117,6 +117,5 @@ weight: 120 ## {{% heading "whatsnext" %}} -[노드 어피니티](/ko/docs/concepts/scheduling-eviction/assign-pod-node/#node-affinity)에 +[노드 어피니티](/ko/docs/concepts/scheduling-eviction/assign-pod-node/#노드-어피니티)에 대해 더 알아보기. - diff --git a/content/ko/docs/tasks/configure-pod-container/configure-pod-initialization.md b/content/ko/docs/tasks/configure-pod-container/configure-pod-initialization.md index 2e6356b896..ee7d5a9f82 100644 --- a/content/ko/docs/tasks/configure-pod-container/configure-pod-initialization.md +++ b/content/ko/docs/tasks/configure-pod-container/configure-pod-initialization.md @@ -1,22 +1,23 @@ --- title: 초기화 컨테이너에 대한 구성 -content_template: templates/task +content_type: task weight: 130 --- -{{% capture overview %}} +<!-- overview --> 이 페이지는 애플리케이션 실행 전에 파드를 초기화하기 위해 어떻게 초기화 컨테이너를 구성해야 하는지 보여준다. -{{% /capture %}} -{{% capture prerequisites %}} + +## {{% heading "prerequisites" %}} + {{< include "task-tutorial-prereqs.md" >}} {{< version-check >}} -{{% /capture %}} -{{% capture steps %}} + +<!-- steps --> ## 초기화 컨테이너를 갖는 파드 생성 @@ -78,14 +79,13 @@ init-demo 파드 내 실행 중인 nginx 컨테이너의 셸을 실행한다. <p>Kubernetes is open source giving you the freedom to take advantage ...</p> ... -{{% /capture %}} -{{% capture whatsnext %}} + +## {{% heading "whatsnext" %}} + * [같은 파드 내 실행 중인 컨테이너들간 통신](/ko/docs/tasks/access-application-cluster/communicate-containers-same-pod-shared-volume/)에 대해 배우기. * [초기화 컨테이너](/ko/docs/concepts/workloads/pods/init-containers/)에 대해 배우기. * [볼륨](/ko/docs/concepts/storage/volumes/)에 대해 배우기. -* [초기화 컨테이너 디버깅](/docs/tasks/debug-application-cluster/debug-init-containers/)에 대해 배우기. - -{{% /capture %}} +* [초기화 컨테이너 디버깅](/ko/docs/tasks/debug-application-cluster/debug-init-containers/)에 대해 배우기. diff --git a/content/ko/docs/tasks/configure-pod-container/pull-image-private-registry.md b/content/ko/docs/tasks/configure-pod-container/pull-image-private-registry.md index 662b7528bc..939919b2e6 100644 --- a/content/ko/docs/tasks/configure-pod-container/pull-image-private-registry.md +++ b/content/ko/docs/tasks/configure-pod-container/pull-image-private-registry.md @@ -7,7 +7,7 @@ weight: 100 <!-- overview --> 이 페이지는 프라이빗 도커 레지스트리나 리포지터리로부터 이미지를 받아오기 위해 시크릿(Secret)을 -사용하는 파드(Pod)를 생성하는 방법을 보여준다. +사용하는 파드를 생성하는 방법을 보여준다. diff --git a/content/ko/docs/tasks/configure-pod-container/static-pod.md b/content/ko/docs/tasks/configure-pod-container/static-pod.md new file mode 100644 index 0000000000..8eb1c0a68f --- /dev/null +++ b/content/ko/docs/tasks/configure-pod-container/static-pod.md @@ -0,0 +1,238 @@ +--- + + +title: 스태틱(static) 파드 생성하기 +weight: 170 +content_template: task +--- + +<!-- overview --> + + +*스태틱 파드* 는 {{< glossary_tooltip text="API 서버" term_id="kube-apiserver" >}} +없이 특정 노드에 있는 kubelet 데몬에 의해 +직접 관리된다. +컨트롤 플레인에 의해 관리되는 파드(예를 들어 {{< glossary_tooltip text="디플로이먼트(Deployment)" term_id="deployment" >}})와는 달리, +kubelet 이 각각의 스태틱 파드를 감시한다. +(만약 충돌이 날 경우 다시 구동한다.) + +스태틱 파드는 항상 특정 노드에 있는 하나의 {{< glossary_tooltip term_id="kubelet" >}}에 매여 있다. + +Kubelet 은 각각의 스태틱 파드에 대하여 쿠버네티스 API 서버에서 {{< glossary_tooltip text="미러 파드(mirror pod)" term_id="mirror-pod" >}}를 +생성하려고 자동으로 시도한다. +즉, 노드에서 구동되는 파드는 API 서버에 의해서 볼 수 있지만, +API 서버에서 제어될 수는 없다. + +{{< note >}} +만약 클러스터로 구성된 쿠버네티스를 구동하고 있고, 스태틱 파드를 사용하여 +모든 노드에서 파드를 구동하고 있다면, +스태틱 파드를 사용하는 대신 {{< glossary_tooltip text="데몬셋(DaemonSet)" term_id="daemonset" >}} +을 사용하는 것이 바람직하다. +{{< /note >}} + + + +## {{% heading "prerequisites" %}} + + +{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}} + +이 페이지는 파드를 실행하기 위해 {{< glossary_tooltip term_id="docker" >}}를 사용하며, +노드에서 Fedora 운영 체제를 구동하고 있다고 가정한다. +다른 배포판이나 쿠버네티스 설치 지침과는 다소 상이할 수 있다. + + + + + +<!-- steps --> + +## 스태틱 파드 생성하기 {#static-pod-creation} + +[파일 시스템이 호스팅하는 구성 파일](/ko/docs/tasks/configure-pod-container/static-pod/#configuration-files)이나 [웹이 호스팅하는 구성 파일](/ko/docs/tasks/configure-pod-container/static-pod/#pods-created-via-http)을 사용하여 스태틱 파드를 구성할 수 있다. + +### 파일시스템이 호스팅 하는 스태틱 파드 매니페스트 {#configuration-files} + +매니페스트는 특정 디렉터리에 있는 JSON 이나 YAML 형식의 표준 파드 정의이다. [kubelet 구성 파일](/docs/tasks/administer-cluster/kubelet-config-file)의 `staticPodPath: <the directory>` 필드를 사용하자. 이 디렉터리를 정기적으로 스캔하여, 디렉터리 안의 YAML/JSON 파일이 생성되거나 삭제되었을 때 스태틱 파드를 생성하거나 삭제한다. +Kubelet 이 특정 디렉터리를 스캔할 때 점(.)으로 시작하는 단어를 무시한다는 점을 유의하자. + +예를 들어, 다음은 스태틱 파드로 간단한 웹 서버를 구동하는 방법을 보여준다. + +1. 스태틱 파드를 실행할 노드를 선택한다. 이 예제에서는 `my-model` 이다. + + ```shell + ssh my-node1 + ``` + +2. `/etc/kubelet.d` 와 같은 디렉터리를 선택하고 웹 서버 파드의 정의를 해당 위치에, 예를 들어 `/etc/kubelet.d/static-web.yaml` 에 배치한다. + + ```shell + # kubelet 이 동작하고 있는 노드에서 이 명령을 수행한다. + mkdir /etc/kubelet.d/ + cat <<EOF >/etc/kubelet.d/static-web.yaml + apiVersion: v1 + kind: Pod + metadata: + name: static-web + labels: + role: myrole + spec: + containers: + - name: web + image: nginx + ports: + - name: web + containerPort: 80 + protocol: TCP + EOF + ``` + +3. 노드에서 kubelet 실행 시에 `--pod-manifest-path=/etc/kubelet.d/` 와 같이 인자를 제공하여 해당 디렉터리를 사용하도록 구성한다. Fedora 의 경우 이 줄을 포함하기 위하여 `/etc/kubernetes/kubelet` 파일을 다음과 같이 수정한다. + + ``` + KUBELET_ARGS="--cluster-dns=10.254.0.10 --cluster-domain=kube.local --pod-manifest-path=/etc/kubelet.d/" + ``` + 혹은 [kubelet 구성 파일](/docs/tasks/administer-cluster/kubelet-config-file)에 `staticPodPath: <the directory>` 필드를 추가한다. + +4. kubelet을 재시작한다. Fedora의 경우 아래와 같이 수행한다. + + ```shell + # kubelet 이 동작하고 있는 노드에서 이 명령을 수행한다. + systemctl restart kubelet + ``` + +### 웹이 호스팅 하는 스태틱 파드 매니페스트 {#pods-created-via-http} + +Kubelet은 `--manifest-url=<URL>` 의 인수로 지정된 파일을 주기적으로 다운로드하여 +해당 파일을 파드의 정의가 포함된 JSON/YAML 파일로 해석한다. +[파일시스템이 호스팅 하는 매니페스트](#configuration-files) 의 작동 방식과 +유사하게 kubelet은 스케줄에 맞춰 매니페스트 파일을 다시 가져온다. 스태틱 파드의 목록에 +변경된 부분이 있을 경우, kubelet 은 이를 적용한다. + +이 방법을 사용하기 위하여 다음을 수행한다. + +1. kubelet 에게 파일의 URL을 전달하기 위하여 YAML 파일을 생성하고 이를 웹 서버에 저장한다. + + ```yaml + apiVersion: v1 + kind: Pod + metadata: + name: static-web + labels: + role: myrole + spec: + containers: + - name: web + image: nginx + ports: + - name: web + containerPort: 80 + protocol: TCP + ``` + +2. 선택한 노드에서 `--manifest-url=<manifest-url>` 을 실행하여 웹 메니페스트를 사용하도록 kubelet을 구성한다. Fedora 의 경우 이 줄을 포함하기 위하여 `/etc/kubernetes/kubelet` 파일을 수정한다. + + ``` + KUBELET_ARGS="--cluster-dns=10.254.0.10 --cluster-domain=kube.local --manifest-url=<manifest-url>" + ``` + +3. Kubelet을 재시작한다. Fedora의 경우 아래와 같이 수행한다. + + ```shell + # kubelet 이 동작하고 있는 노드에서 이 명령을 수행한다. + systemctl restart kubelet + ``` + +## 스태틱 파드 행동 관찰하기 {#behavior-of-static-pods} + +Kubelet 을 시작하면, 정의된 모든 스태틱 파드가 자동으로 시작된다. +스태틱 파드를 정의하고, kubelet을 재시작했으므로, 새로운 스태틱 +파드가 이미 실행 중이어야 한다. + +(노드에서) 구동되고 있는 (스태틱 파드를 포함한) 컨테이너들을 볼 수 있다. +```shell +# kubelet 이 동작하고 있는 노드에서 이 명령을 수행한다. +docker ps +``` + +결과는 다음과 유사하다. + +``` +CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES +f6d05272b57e nginx:latest "nginx" 8 minutes ago Up 8 minutes k8s_web.6f802af4_static-web-fk-node1_default_67e24ed9466ba55986d120c867395f3c_378e5f3c +``` + +API 서버에서 미러 파드를 볼 수 있다. + +```shell +kubectl get pods +``` +``` +NAME READY STATUS RESTARTS AGE +static-web-my-node1 1/1 Running 0 2m +``` + +{{< note >}} +Kubelet에 API 서버에서 미러 파드를 생성할 수 있는 권한이 있는지 미리 확인해야 한다. 그렇지 않을 경우 API 서버에 의해서 생성 요청이 거부된다. +[파드시큐리티폴리시(PodSecurityPolicy)](/ko/docs/concepts/policy/pod-security-policy/) 에 대해 보기. +{{< /note >}} + + +스태틱 파드에 있는 {{< glossary_tooltip term_id="label" text="레이블" >}} 은 +미러 파드로 전파된다. {{< glossary_tooltip term_id="selector" text="셀렉터" >}} 등을 +통하여 이러한 레이블을 사용할 수 있다. + +만약 API 서버로부터 미러 파드를 지우기 위하여 `kubectl` 을 사용하려 해도, +kubelet 은 스태틱 파드를 지우지 _않는다._ + +```shell +kubectl delete pod static-web-my-node1 +``` +``` +pod "static-web-my-node1" deleted +``` +파드가 여전히 구동 중인 것을 볼 수 있다. +```shell +kubectl get pods +``` +``` +NAME READY STATUS RESTARTS AGE +static-web-my-node1 1/1 Running 0 12s +``` + +kubelet 이 구동 중인 노드로 돌아가서 도커 컨테이너를 수동으로 +중지할 수 있다. +일정 시간이 지나면, kubelet이 파드를 자동으로 인식하고 다시 시작하는 +것을 볼 수 있다. + +```shell +# kubelet 이 동작하고 있는 노드에서 이 명령을 수행한다. +docker stop f6d05272b57e # 예제를 수행하는 사용자의 컨테이너 ID로 변경한다. +sleep 20 +docker ps +``` +``` +CONTAINER ID IMAGE COMMAND CREATED ... +5b920cbaf8b1 nginx:latest "nginx -g 'daemon of 2 seconds ago ... +``` + +## 스태틱 파드의 동적 추가 및 제거 + +실행 중인 kubelet 은 주기적으로, 설정된 디렉터리(예제에서는 `/etc/kubelet.d`)에서 변경 사항을 스캔하고, 이 디렉터리에 새로운 파일이 생성되거나 삭제될 경우, 파드를 생성/삭제 한다. + +```shell +# 예제를 수행하는 사용자가 파일시스템이 호스팅하는 스태틱 파드 설정을 사용한다고 가정한다. +# kubelet 이 동작하고 있는 노드에서 이 명령을 수행한다. +# +mv /etc/kubelet.d/static-web.yaml /tmp +sleep 20 +docker ps +# 구동 중인 nginx 컨테이너가 없는 것을 확인한다. +mv /tmp/static-web.yaml /etc/kubelet.d/ +sleep 20 +docker ps +``` +``` +CONTAINER ID IMAGE COMMAND CREATED ... +e7a62e3427f1 nginx:latest "nginx -g 'daemon of 27 seconds ago +``` diff --git a/content/ko/docs/tasks/debug-application-cluster/_index.md b/content/ko/docs/tasks/debug-application-cluster/_index.md index 0613fed1ef..d0bda0ea0f 100755 --- a/content/ko/docs/tasks/debug-application-cluster/_index.md +++ b/content/ko/docs/tasks/debug-application-cluster/_index.md @@ -1,5 +1,6 @@ --- title: "모니터링, 로깅, 그리고 디버깅" +description: 모니터링 및 로깅을 설정하여 클러스터 문제를 해결하거나, 컨테이너화된 애플리케이션을 디버깅한다. weight: 80 --- diff --git a/content/ko/docs/tasks/debug-application-cluster/debug-init-containers.md b/content/ko/docs/tasks/debug-application-cluster/debug-init-containers.md new file mode 100644 index 0000000000..dc774b9ce3 --- /dev/null +++ b/content/ko/docs/tasks/debug-application-cluster/debug-init-containers.md @@ -0,0 +1,125 @@ +--- +title: 초기화 컨테이너(Init Containers) 디버그하기 +content_type: task +--- + +<!-- overview --> + +이 페이지는 초기화 컨테이너의 실행과 관련된 문제를 +조사하는 방법에 대해 보여준다. 아래 예제의 커맨드 라인은 파드(Pod)를 `<pod-name>` 으로, +초기화 컨테이너를 `<init-container-1>` 과 +`<init-container-2>` 로 표시한다. + + + +## {{% heading "prerequisites" %}} + + +{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}} + +* 사용자는 [초기화 컨테이너](/ko/docs/concepts/workloads/pods/init-containers/)의 + 기본 사항에 익숙해야 한다. +* 사용자는 [초기화 컨테이너를 구성](/ko/docs/tasks/configure-pod-container/configure-pod-initialization/#초기화-컨테이너를-갖는-파드-생성)해야 한다. + + + +<!-- steps --> + +## 초기화 컨테이너의 상태 체크하기 + +사용자 파드의 상태를 표시한다. + +```shell +kubectl get pod <pod-name> +``` + +예를 들어, `Init:1/2` 상태는 두 개의 초기화 컨테이너 중 +하나가 성공적으로 완료되었음을 나타낸다. + +``` +NAME READY STATUS RESTARTS AGE +<pod-name> 0/1 Init:1/2 0 7s +``` + +상태값과 그 의미에 대한 추가 예제는 +[파드 상태 이해하기](#파드의-상태-이해하기)를 참조한다. + +## 초기화 컨테이너에 대한 상세 정보 조회하기 + +초기화 컨테이너의 실행에 대한 상세 정보를 확인한다. + +```shell +kubectl describe pod <pod-name> +``` + +예를 들어, 2개의 초기화 컨테이너가 있는 파드는 다음과 같이 표시될 수 있다. + +``` +Init Containers: + <init-container-1>: + Container ID: ... + ... + State: Terminated + Reason: Completed + Exit Code: 0 + Started: ... + Finished: ... + Ready: True + Restart Count: 0 + ... + <init-container-2>: + Container ID: ... + ... + State: Waiting + Reason: CrashLoopBackOff + Last State: Terminated + Reason: Error + Exit Code: 1 + Started: ... + Finished: ... + Ready: False + Restart Count: 3 + ... +``` + +파드 스펙의 `status.initContainerStatuses` 필드를 읽어서 +프로그래밍 방식으로 초기화 컨테이너의 상태를 조회할 수도 있다. + + +```shell +kubectl get pod nginx --template '{{.status.initContainerStatuses}}' +``` + + +이 명령은 원시 JSON 방식으로 위와 동일한 정보를 반환한다. + +## 초기화 컨테이너의 로그 조회하기 + +초기화 컨테이너의 로그를 확인하기 위해 +파드의 이름과 초기화 컨테이너의 이름을 같이 전달한다. + +```shell +kubectl logs <pod-name> -c <init-container-2> +``` + +셸 스크립트를 실행하는 초기화 컨테이너는, 초기화 컨테이너가 +실행될 때 명령어를 출력한다. 예를 들어, 스크립트의 시작 부분에 +`set -x` 를 추가하고 실행하여 Bash에서 명령어를 출력할 수 있도록 수행할 수 있다. + + + +<!-- discussion --> + +## 파드의 상태 이해하기 + +`Init:` 으로 시작하는 파드 상태는 초기화 컨테이너의 +실행 상태를 요약한다. 아래 표는 초기화 컨테이너를 디버깅하는 +동안 사용자가 확인할 수 있는 몇 가지 상태값의 예이다. + +상태 | 의미 +------ | ------- +`Init:N/M` | 파드가 `M` 개의 초기화 컨테이너를 갖고 있으며, 현재까지 `N` 개가 완료. +`Init:Error` | 초기화 컨테이너 실행 실패. +`Init:CrashLoopBackOff` | 초기화 컨테이너가 반복적으로 실행 실패. +`Pending` | 파드가 아직 초기화 컨테이너를 실행하지 않음. +`PodInitializing` or `Running` | 파드가 이미 초기화 컨테이너 실행을 완료. diff --git a/content/ko/docs/tasks/debug-application-cluster/determine-reason-pod-failure.md b/content/ko/docs/tasks/debug-application-cluster/determine-reason-pod-failure.md index b59e62f067..3c8df08ede 100644 --- a/content/ko/docs/tasks/debug-application-cluster/determine-reason-pod-failure.md +++ b/content/ko/docs/tasks/debug-application-cluster/determine-reason-pod-failure.md @@ -1,37 +1,38 @@ --- title: 파드 실패의 원인 검증하기 -content_template: templates/task +content_type: task --- -{{% capture overview %}} +<!-- overview --> -이 페이지는 컨테이너 종료 메시지를 읽고 쓰는 +이 페이지는 컨테이너 종료 메시지를 읽고 쓰는 방법을 보여준다. -종료 메시지는 컨테이너가 치명적인 이벤트에 대한 정보를, +종료 메시지는 컨테이너가 치명적인 이벤트에 대한 정보를, 대시보드나 모니터링 소프트웨어 도구와 같이 -쉽게 조회 및 표시할 수 있는 위치에 +쉽게 조회 및 표시할 수 있는 위치에 기록하는 방법을 제공한다. -대부분의 경우에 종료 메시지에 넣는 정보는 -일반 +대부분의 경우에 종료 메시지에 넣는 정보는 +일반 [쿠버네티스 로그](/ko/docs/concepts/cluster-administration/logging/)에도 쓰여져야 한다. -{{% /capture %}} -{{% capture prerequisites %}} + +## {{% heading "prerequisites" %}} + {{< include "task-tutorial-prereqs.md" >}} {{< version-check >}} -{{% /capture %}} -{{% capture steps %}} + +<!-- steps --> ## 종료 메시지 읽기 및 쓰기 이 예제에서는, 하나의 컨테이너를 실행하는 파드를 생성한다. -하단의 설정 파일은 컨테이너가 시작될 때 수행하는 +하단의 설정 파일은 컨테이너가 시작될 때 수행하는 명령어를 지정한다. {{< codenew file="debug/termination.yaml" >}} @@ -40,8 +41,8 @@ content_template: templates/task kubectl apply -f https://k8s.io/examples/debug/termination.yaml - YAML 파일에 있는 `cmd` 와 `args` 필드에서 컨테이너가 10초 간 잠든 뒤에 - "Sleep expired" 문자열을 `/dev/termination-log` 파일에 기록하는 + YAML 파일에 있는 `cmd` 와 `args` 필드에서 컨테이너가 10초 간 잠든 뒤에 + "Sleep expired" 문자열을 `/dev/termination-log` 파일에 기록하는 것을 확인할 수 있다. 컨테이너는 "Sleep expired" 메시지를 기록한 후에 종료된다. @@ -69,20 +70,25 @@ content_template: templates/task Sleep expired ... -1. 종료 메시지만을 포함하는 출력 결과를 보기 +1. 종료 메시지만을 포함하는 출력 결과를 보기 위해서는 Go 템플릿을 사용한다. kubectl get pod termination-demo -o go-template="{{range .status.containerStatuses}}{{.lastState.terminated.message}}{{end}}" ## 종료 메시지 사용자 정의하기 -쿠버네티스는 컨테이너의 `terminationMessagePath` 필드에 지정된 -종료 메시지 파일에서 종료 메시지를 검색하며, 이 필드의 기본값은 -`/dev/termination-log` 이다. 이 필드를 사용자 정의 함으로써 -쿠버네티스가 종료 메시지를 검색할 때 다른 파일을 사용하도록 조정할 수 있다. +쿠버네티스는 컨테이너의 `terminationMessagePath` 필드에 지정된 +종료 메시지 파일에서 종료 메시지를 검색하며, 이 필드의 기본값은 +`/dev/termination-log` 이다. 이 필드를 사용자 정의 함으로써 +쿠버네티스가 종료 메시지를 검색할 때 다른 파일을 사용하도록 조정할 수 있다. 쿠버네티스는 지정된 파일의 내용을 사용하여 컨테이너의 성공 및 실패에 대한 상태 메시지를 채운다. -다음의 예제에서 컨테이너는, 쿠버네티스가 조회할 수 있도록 +종료 메시지는 assertion failure 메세지처럼 간결한 최종 상태로 생성된다. +kubelet은 4096 바이트보다 긴 메시지를 자른다. 모든 컨테이너의 총 메시지 길이는 +12KiB로 제한된다. 기본 종료 메시지 경로는 `/dev/termination-log`이다. +파드가 시작된 후에는 종료 메시지 경로를 설정할 수 없다. + +다음의 예제에서 컨테이너는, 쿠버네티스가 조회할 수 있도록 `/tmp/my-log` 파일에 종료 메시지를 기록한다. ```yaml @@ -97,21 +103,20 @@ spec: terminationMessagePath: "/tmp/my-log" ``` -또한 사용자는 추가적인 사용자 정의를 위해 컨테이너의 `terminationMessagePolicy` -필드를 설정할 수 있다. 이 필드의 기본 값은 `File` 이며, -이는 오직 종료 메시지 파일에서만 종료 메시지가 조회되는 것을 의미한다. -`terminationMessagePolicy` 필드의 값을 "`FallbackToLogsOnError` 으로 -설정함으로써, 종료 메시지 파일이 비어 있고 컨테이너가 오류와 함께 종료 되었을 경우 -쿠버네티스가 컨테이너 로그 출력의 마지막 청크를 사용하도록 지시할 수 있다. +또한 사용자는 추가적인 사용자 정의를 위해 컨테이너의 `terminationMessagePolicy` +필드를 설정할 수 있다. 이 필드의 기본 값은 `File` 이며, +이는 오직 종료 메시지 파일에서만 종료 메시지가 조회되는 것을 의미한다. +`terminationMessagePolicy` 필드의 값을 "`FallbackToLogsOnError` 으로 +설정함으로써, 종료 메시지 파일이 비어 있고 컨테이너가 오류와 함께 종료 되었을 경우 +쿠버네티스가 컨테이너 로그 출력의 마지막 청크를 사용하도록 지시할 수 있다. 로그 출력은 2048 바이트나 80 행 중 더 작은 값으로 제한된다. -{{% /capture %}} -{{% capture whatsnext %}} + +## {{% heading "whatsnext" %}} + * [컨테이너](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#container-v1-core) 에 있는 `terminationMessagePath` 에 대해 읽어보기. -* [로그 검색](/docs/concepts/cluster-administration/logging/)에 대해 배워보기. +* [로그 검색](/ko/docs/concepts/cluster-administration/logging/)에 대해 배워보기. * [Go 템플릿](https://golang.org/pkg/text/template/)에 대해 배워보기. - -{{% /capture %}} diff --git a/content/ko/docs/tasks/debug-application-cluster/resource-metrics-pipeline.md b/content/ko/docs/tasks/debug-application-cluster/resource-metrics-pipeline.md index d52a6127be..ee6991ef30 100644 --- a/content/ko/docs/tasks/debug-application-cluster/resource-metrics-pipeline.md +++ b/content/ko/docs/tasks/debug-application-cluster/resource-metrics-pipeline.md @@ -5,10 +5,10 @@ content_type: concept <!-- overview --> -컨테이너 CPU 및 메모리 사용량과 같은 리소스 사용량 메트릭은 -쿠버네티스의 메트릭 API를 통해 사용할 수 있다. 이 메트릭은 -`kubectl top` 커맨드 사용과 같이 사용자가 직접적으로 액세스하거나, -Horizontal Pod Autoscaler 같은 클러스터의 컨트롤러에서 결정을 내릴 때 사용될 수 있다. +컨테이너 CPU 및 메모리 사용량과 같은 리소스 사용량 메트릭은 +쿠버네티스의 메트릭 API를 통해 사용할 수 있다. 이 메트릭은 +`kubectl top` 커맨드 사용과 같이 사용자가 직접적으로 액세스하거나, +Horizontal Pod Autoscaler 같은 클러스터의 컨트롤러에서 결정을 내릴 때 사용될 수 있다. @@ -17,9 +17,9 @@ Horizontal Pod Autoscaler 같은 클러스터의 컨트롤러에서 결정을 ## 메트릭 API -메트릭 API를 통해 주어진 노드나 파드에서 현재 사용중인 -리소스의 양을 알 수 있다. 이 API는 메트릭 값을 저장하지 -않으므로 지정된 노드에서 10분 전에 사용된 리소스의 양을 +메트릭 API를 통해 주어진 노드나 파드에서 현재 사용중인 +리소스의 양을 알 수 있다. 이 API는 메트릭 값을 저장하지 +않으므로 지정된 노드에서 10분 전에 사용된 리소스의 양을 가져오는 것과 같은 일을 할 수는 없다. 이 API와 다른 API는 차이가 없다. @@ -27,7 +27,7 @@ Horizontal Pod Autoscaler 같은 클러스터의 컨트롤러에서 결정을 - 다른 쿠버네티스 API의 엔드포인트와 같이 `/apis/metrics.k8s.io/` 하위 경로에서 발견될 수 있다 - 동일한 보안, 확장성 및 신뢰성 보장을 제공한다 -[k8s.io/metrics](https://github.com/kubernetes/metrics/blob/master/pkg/apis/metrics/v1beta1/types.go) +[k8s.io/metrics](https://github.com/kubernetes/metrics/blob/master/pkg/apis/metrics/v1beta1/types.go) 리포지터리에서 이 API를 정의하고 있다. 여기에서 이 API에 대한 더 상세한 정보를 찾을 수 있다. {{< note >}} @@ -38,7 +38,7 @@ Horizontal Pod Autoscaler 같은 클러스터의 컨트롤러에서 결정을 ### CPU -CPU는 일정 기간 동안 [CPU 코어](https://kubernetes.io/docs/concepts/configuration/manage-compute-resources-container/#meaning-of-cpu)에서 평균 사용량으로 리포트된다. 이 값은 커널(리눅스와 윈도우 커널 모두)에서 제공하는 누적 CPU 카운터보다 높은 비율을 적용해서 얻는다. kubelet은 비율 계산에 사용할 윈도우를 선택한다. +CPU는 일정 기간 동안 [CPU 코어](/ko/docs/concepts/configuration/manage-resources-containers/#cpu의-의미)에서 평균 사용량으로 리포트된다. 이 값은 커널(리눅스와 윈도우 커널 모두)에서 제공하는 누적 CPU 카운터보다 높은 비율을 적용해서 얻는다. kubelet은 비율 계산에 사용할 윈도우를 선택한다. ### 메모리 @@ -47,15 +47,13 @@ CPU는 일정 기간 동안 [CPU 코어](https://kubernetes.io/docs/concepts/con ## 메트릭 서버 [메트릭 서버](https://github.com/kubernetes-incubator/metrics-server)는 클러스터 전역에서 리소스 사용량 데이터를 집계한다. -`kube-up.sh` 스크립트에 의해 생성된 클러스터에는 기본적으로 메트릭 서버가 -디플로이먼트 오브젝트로 배포된다. 만약 다른 쿠버네티스 설치 메커니즘을 사용한다면, 제공된 +`kube-up.sh` 스크립트에 의해 생성된 클러스터에는 기본적으로 메트릭 서버가 +디플로이먼트 오브젝트로 배포된다. 만약 다른 쿠버네티스 설치 메커니즘을 사용한다면, 제공된 [디플로이먼트 components.yaml](https://github.com/kubernetes-sigs/metrics-server/releases) 파일을 사용하여 메트릭 서버를 배포할 수 있다. 메트릭 서버는 각 노드에서 [Kubelet](/docs/admin/kubelet/)에 의해 노출된 Summary API에서 메트릭을 수집한다. -메트릭 서버는 [쿠버네티스 aggregator](/docs/concepts/api-extension/apiserver-aggregation/)를 +메트릭 서버는 [쿠버네티스 aggregator](/ko/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation/)를 통해 메인 API 서버에 등록된다. [설계 문서](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/instrumentation/metrics-server.md)에서 메트릭 서버에 대해 자세하게 배울 수 있다. - - diff --git a/content/ko/docs/tasks/debug-application-cluster/resource-usage-monitoring.md b/content/ko/docs/tasks/debug-application-cluster/resource-usage-monitoring.md index 9677ccd1b9..34c51ad860 100644 --- a/content/ko/docs/tasks/debug-application-cluster/resource-usage-monitoring.md +++ b/content/ko/docs/tasks/debug-application-cluster/resource-usage-monitoring.md @@ -18,15 +18,11 @@ title: 리소스 모니터링 도구 <!-- body --> -쿠버네티스에서 애플리케이션 모니터링은 단일 모니터링 솔루션에 의존하지 않는다. -신규 클러스터에서는, [리소스 메트릭](#리소스-메트릭-파이프라인) 또는 [완전한 -메트릭 파이프라인](#완전한-메트릭-파이프라인) 파이프라인으로 모니터링 통계를 -수집할 수 있다. +쿠버네티스에서 애플리케이션 모니터링은 단일 모니터링 솔루션에 의존하지 않는다. 신규 클러스터에서는, [리소스 메트릭](#리소스-메트릭-파이프라인) 또는 [완전한 메트릭](#완전한-메트릭-파이프라인) 파이프라인으로 모니터링 통계를 수집할 수 있다. ## 리소스 메트릭 파이프라인 -리소스 메트릭 파이프라인은 -[Horizontal Pod Autoscaler](/ko/docs/tasks/run-application/horizontal-pod-autoscale) +리소스 메트릭 파이프라인은 [Horizontal Pod Autoscaler](/ko/docs/tasks/run-application/horizontal-pod-autoscale) 컨트롤러와 같은 클러스터 구성요소나 `kubectl top` 유틸리티에 관련되어 있는 메트릭들로 제한된 집합을 제공한다. 이 메트릭은 경량의 단기 인메모리 저장소인 [metrics-server](https://github.com/kubernetes-incubator/metrics-server)에 diff --git a/content/ko/docs/tasks/extend-kubectl/kubectl-plugins.md b/content/ko/docs/tasks/extend-kubectl/kubectl-plugins.md index e299d4db51..d3b06d2703 100644 --- a/content/ko/docs/tasks/extend-kubectl/kubectl-plugins.md +++ b/content/ko/docs/tasks/extend-kubectl/kubectl-plugins.md @@ -1,23 +1,24 @@ --- title: 플러그인으로 kubectl 확장 -description: kubectl 플러그인을 사용하면, 새로운 하위 명령을 추가하여 kubectl 명령의 기능을 확장할 수 있다. -content_template: templates/task +description: kubectl 플러그인을 작성하고 설치해서 kubectl을 확장한다. +content_type: task --- -{{% capture overview %}} +<!-- overview --> 이 가이드는 [kubectl](/docs/reference/kubectl/kubectl/) 확장을 설치하고 작성하는 방법을 보여준다. 핵심 `kubectl` 명령을 쿠버네티스 클러스터와 상호 작용하기 위한 필수 구성 요소로 생각함으로써, 클러스터 관리자는 플러그인을 이러한 구성 요소를 활용하여 보다 복잡한 동작을 만드는 수단으로 생각할 수 있다. 플러그인은 새로운 하위 명령으로 `kubectl` 을 확장하고, 주요 배포판에 포함되지 않은 `kubectl` 의 새로운 사용자 정의 기능을 허용한다. -{{% /capture %}} -{{% capture prerequisites %}} + +## {{% heading "prerequisites" %}} + 동작하는 `kubectl` 바이너리가 설치되어 있어야 한다. -{{% /capture %}} -{{% capture steps %}} + +<!-- steps --> ## kubectl 플러그인 설치 @@ -372,9 +373,10 @@ kubectl 플러그인의 배포 패키지를 컴파일된 패키지를 사용 가능하게 하거나, Krew를 사용하면 설치가 더 쉬워진다. -{{% /capture %}} -{{% capture whatsnext %}} + +## {{% heading "whatsnext" %}} + * Go로 작성된 플러그인의 [자세한 예제](https://github.com/kubernetes/sample-cli-plugin)에 대해서는 @@ -383,4 +385,4 @@ kubectl 플러그인의 배포 패키지를 [SIG CLI 팀](https://github.com/kubernetes/community/tree/master/sig-cli)에 문의한다. * kubectl 플러그인 패키지 관리자인 [Krew](https://krew.dev/)에 대해 읽어본다. -{{% /capture %}} + diff --git a/content/ko/docs/tasks/inject-data-application/_index.md b/content/ko/docs/tasks/inject-data-application/_index.md index e7ae5375f4..c5bddeca7e 100644 --- a/content/ko/docs/tasks/inject-data-application/_index.md +++ b/content/ko/docs/tasks/inject-data-application/_index.md @@ -1,5 +1,5 @@ --- title: "애플리케이션에 데이터 주입하기" +description: 워크로드를 실행하는 파드에 대한 구성과 기타 데이터를 지정한다. weight: 30 - ---- \ No newline at end of file +--- diff --git a/content/ko/docs/tasks/inject-data-application/define-command-argument-container.md b/content/ko/docs/tasks/inject-data-application/define-command-argument-container.md index 8f821c7cf5..68ee4726a5 100644 --- a/content/ko/docs/tasks/inject-data-application/define-command-argument-container.md +++ b/content/ko/docs/tasks/inject-data-application/define-command-argument-container.md @@ -30,9 +30,9 @@ weight: 10 파일에 `args` 필드를 포함시킨다. 정의한 커맨드와 인자들은 파드가 생성되고 난 이후에는 변경될 수 없다. -구성 파일 안에서 정의하는 커맨드와 인자들은 컨테이너 이미지가 -제공하는 기본 커맨드와 인자들보다 우선시 된다. 만약 인자들을 -정의하고 커맨드를 정의하지 않는다면, 기본 커맨드가 새로운 인자와 +구성 파일 안에서 정의하는 커맨드와 인자들은 컨테이너 이미지가 +제공하는 기본 커맨드와 인자들보다 우선시 된다. 만약 인자들을 +정의하고 커맨드를 정의하지 않는다면, 기본 커맨드가 새로운 인자와 함께 사용된다. {{< note >}} @@ -103,7 +103,7 @@ args: ["$(MESSAGE)"] ## 셸 안에서 커맨드 실행하기 일부 경우들에서는 커맨드를 셸 안에서 실행해야할 필요가 있다. 예를 들어, 실행할 커맨드가 -서로 연결되어 있는 여러 개의 커맨드들로 구성되어 있거나, 셸 스크립트일 수도 있다. 셸 안에서 +서로 연결되어 있는 여러 개의 커맨드들로 구성되어 있거나, 셸 스크립트일 수도 있다. 셸 안에서 커맨드를 실행하려고 한다면, 이런 방식으로 감싸주면 된다. ```shell @@ -122,18 +122,18 @@ args: ["-c", "while true; do echo hello; sleep 10;done"] 기본 Entrypoint와 Cmd 값을 덮어쓰려고 한다면, 아래의 규칙들이 적용된다. -* 만약 컨테이너를 위한 `command` 값이나 `args` 값을 제공하지 않는다면, 도커 이미지 안에 +* 만약 컨테이너를 위한 `command` 값이나 `args` 값을 제공하지 않는다면, 도커 이미지 안에 제공되는 기본 값들이 사용된다. -* 만약 컨테이너를 위한 `command` 값을 제공하고, `args` 값을 제공하지 않는다면, -제공된 `command` 값만이 사용된다. 도커 이미지 안에 정의된 기본 EntryPoint 값과 기본 +* 만약 컨테이너를 위한 `command` 값을 제공하고, `args` 값을 제공하지 않는다면, +제공된 `command` 값만이 사용된다. 도커 이미지 안에 정의된 기본 EntryPoint 값과 기본 Cmd 값은 덮어쓰여진다. -* 만약 컨테이너를 위한 `args` 값만 제공한다면, 도커 이미지 안에 정의된 기본 EntryPoint +* 만약 컨테이너를 위한 `args` 값만 제공한다면, 도커 이미지 안에 정의된 기본 EntryPoint 값이 정의한 `args` 값들과 함께 실행된다. -* `command` 값과 `args` 값을 동시에 정의한다면, 도커 이미지 안에 정의된 기본 -EntryPoint 값과 기본 Cmd 값이 덮어쓰여진다. `command`가 `args` 값과 함께 +* `command` 값과 `args` 값을 동시에 정의한다면, 도커 이미지 안에 정의된 기본 +EntryPoint 값과 기본 Cmd 값이 덮어쓰여진다. `command`가 `args` 값과 함께 실행된다. 여기 몇 가지 예시들이 있다. @@ -154,7 +154,3 @@ EntryPoint 값과 기본 Cmd 값이 덮어쓰여진다. `command`가 `args` 값 * [파드와 컨테이너를 구성하는 방법](/ko/docs/tasks/)에 대해 더 알아본다. * [컨테이너 안에서 커맨드를 실행하는 방법](/docs/tasks/debug-application-cluster/get-shell-running-container/)에 대해 더 알아본다. * [컨테이너](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#container-v1-core)를 확인한다. - - - - diff --git a/content/ko/docs/tasks/inject-data-application/define-environment-variable-container.md b/content/ko/docs/tasks/inject-data-application/define-environment-variable-container.md index 21fcf9e9c2..c7057c1887 100644 --- a/content/ko/docs/tasks/inject-data-application/define-environment-variable-container.md +++ b/content/ko/docs/tasks/inject-data-application/define-environment-variable-container.md @@ -30,7 +30,7 @@ weight: 20 이 예제에서, 한 개의 컨테이너를 실행하는 파드를 생성한다. 파드를 위한 구성 파일은 `DEMO_GREETING` 이라는 이름과 `"Hello from the environment"`이라는 -값을 가지는 환경 변수를 정의한다. 다음은 파드를 위한 구성 파일 +값을 가지는 환경 변수를 정의한다. 다음은 파드를 위한 구성 매니페스트 예시이다. {{< codenew file="pods/inject/envars.yaml" >}} @@ -63,7 +63,8 @@ weight: 20 1. 셸 안에서, 환경 변수를 나열하기 위해 `printenv` 커맨드를 실행한다. ```shell - root@envar-demo:/# printenv + # 컨테이너 내 셸에서 다음을 실행한다. + printenv ``` 출력은 아래와 비슷할 것이다. @@ -81,12 +82,24 @@ weight: 20 {{< note >}} `env` 나 `envFrom` 필드를 이용해 설정된 환경 변수들은 컨테이너 이미지 -안에서 명시된 어떠한 환경 변수들보다 더 우선시된다. +안에서 명시된 모든 환경 변수들을 오버라이딩한다. +{{< /note >}} + +{{< note >}} +환경 변수는 서로를 참조할 수 있으며 사이클이 가능하다. +사용하기 전에 순서에 주의한다. {{< /note >}} ## 설정 안에서 환경 변수 사용하기 -파드의 구성 파일 안에서 정의한 환경 변수는 파드의 컨테이너를 위해 설정하는 커맨드들과 인자들과 같이, 구성 파일 안의 다른 곳에서 사용할 수 있다. 아래의 구성 파일 예시에서, `GREETING`, `HONORIFIC`, 그리고 `NAME` 환경 변수들이 각각 `Warm greetings to`, `The Most honorable`, 그리고 `Kubernetes`로 설정되어 있다. 이들 환경 변수들은 이후 `env-print-demo` 컨테이너에 전달되어 CLI 인자에서 사용된다. +파드의 구성 파일 안에서 정의한 환경 변수는 +파드의 컨테이너를 위해 설정하는 커맨드와 인자들과 같이, +구성 파일 안의 다른 곳에서 사용할 수 있다. +아래의 구성 파일 예시에서, `GREETING`, `HONORIFIC`, 그리고 +`NAME` 환경 변수들이 각각 `Warm greetings to`, `The Most honorable`, +그리고 `Kubernetes`로 설정되어 있다. 이 환경 변수들은 +이후 `env-print-demo` 컨테이너에 전달되어 CLI 인자에서 +사용된다. ```yaml apiVersion: v1 diff --git a/content/ko/docs/tasks/manage-daemon/_index.md b/content/ko/docs/tasks/manage-daemon/_index.md index 58b87271c9..1ff595ef61 100644 --- a/content/ko/docs/tasks/manage-daemon/_index.md +++ b/content/ko/docs/tasks/manage-daemon/_index.md @@ -1,4 +1,5 @@ --- title: "클러스터 데몬 관리" +description: 롤링 업데이트 수행과 같은 데몬셋 관리를 위한 일반적인 작업을 수행한다. weight: 130 --- diff --git a/content/ko/docs/tasks/manage-daemon/rollback-daemon-set.md b/content/ko/docs/tasks/manage-daemon/rollback-daemon-set.md index a1c3ba02dc..0c79ae8d66 100644 --- a/content/ko/docs/tasks/manage-daemon/rollback-daemon-set.md +++ b/content/ko/docs/tasks/manage-daemon/rollback-daemon-set.md @@ -1,27 +1,23 @@ --- title: 데몬셋(DaemonSet)에서 롤백 수행 -content_template: templates/task +content_type: task weight: 20 +min-kubernetes-server-version: 1.7 --- -{{% capture overview %}} +<!-- overview --> -이 페이지는 데몬셋에서 롤백을 수행하는 방법을 보여준다. - -{{% /capture %}} +이 페이지는 {{< glossary_tooltip text="데몬셋" term_id="daemonset" >}}에서 롤백을 수행하는 방법을 보여준다. -{{% capture prerequisites %}} +## {{% heading "prerequisites" %}} -* 데몬셋 롤아웃 기록과 데몬셋 롤백 기능은 - 쿠버네티스 버전 1.7 이상의 `kubectl` 에서만 지원된다. -* [데몬셋에서 롤링 업데이트를 - 수행](/ko/docs/tasks/manage-daemon/update-daemon-set/)하는 방법을 알고 있어야 한다. +{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}} -{{% /capture %}} +[데몬셋에서 롤링 업데이트를 + 수행](/ko/docs/tasks/manage-daemon/update-daemon-set/)하는 방법을 이미 알고 있어야 한다. - -{{% capture steps %}} +<!-- steps --> ## 데몬셋에서 롤백 수행 @@ -37,7 +33,7 @@ kubectl rollout history daemonset <daemonset-name> 이 명령은 데몬셋 리비전 목록을 반환한다. -```shell +``` daemonsets "<daemonset-name>" REVISION CHANGE-CAUSE 1 ... @@ -57,17 +53,17 @@ kubectl rollout history daemonset <daemonset-name> --revision=1 이 명령은 해당 리비전의 세부 사항을 반환한다. -```shell +``` daemonsets "<daemonset-name>" with revision #1 Pod Template: Labels: foo=bar Containers: app: - Image: ... - Port: ... - Environment: ... - Mounts: ... -Volumes: ... + Image: ... + Port: ... + Environment: ... + Mounts: ... +Volumes: ... ``` ### 2단계: 특정 리비전으로 롤백 @@ -79,16 +75,19 @@ kubectl rollout undo daemonset <daemonset-name> --to-revision=<revision> 성공하면, 명령은 다음을 반환한다. -```shell +``` daemonset "<daemonset-name>" rolled back ``` -`--to-revision` 플래그를 지정하지 않은 경우, 마지막 리비전이 선택된다. +{{< note >}} +`--to-revision` 플래그를 지정하지 않은 경우, kubectl은 가장 최신의 리비전을 선택한다. +{{< /note >}} ### 3단계: 데몬셋 롤백 진행 상황 확인 `kubectl rollout undo daemonset` 은 서버에 데몬셋 롤백을 시작하도록 -지시한다. 실제 롤백은 서버 측에서 비동기적으로 수행된다. +지시한다. 실제 롤백은 클러스터 {{< glossary_tooltip term_id="control-plane" text="컨트롤 플레인" >}} +내에서 비동기적으로 수행된다. 롤백 진행 상황을 보려면 다음의 명령을 수행한다. @@ -98,21 +97,17 @@ kubectl rollout status ds/<daemonset-name> 롤백이 완료되면, 출력 결과는 다음과 비슷하다. -```shell +``` daemonset "<daemonset-name>" successfully rolled out ``` -{{% /capture %}} - -{{% capture discussion %}} +<!-- discussion --> ## 데몬셋 리비전의 이해 이전 `kubectl rollout history` 단계에서, 데몬셋 리비전 목록을 -얻었다. 각 리비전은 `ControllerRevision` 이라는 리소스에 저장된다. -`ControllerRevision` 은 쿠버네티스 릴리스 1.7 이상에서만 사용할 수 있는 -리소스이다. +얻었다. 각 리비전은 ControllerRevision이라는 리소스에 저장된다. 각 리비전에 저장된 내용을 보려면, 데몬셋 리비전 원시 리소스를 찾는다. @@ -121,30 +116,29 @@ daemonset "<daemonset-name>" successfully rolled out kubectl get controllerrevision -l <daemonset-selector-key>=<daemonset-selector-value> ``` -이 명령은 `ControllerRevisions` 의 목록을 반환한다. +이 명령은 ControllerRevision의 목록을 반환한다. -```shell +``` NAME CONTROLLER REVISION AGE <daemonset-name>-<revision-hash> DaemonSet/<daemonset-name> 1 1h <daemonset-name>-<revision-hash> DaemonSet/<daemonset-name> 2 1h ``` -각 `ControllerRevision` 은 데몬셋 리비전의 어노테이션과 템플릿을 -저장한다. ControllerRevision 오브젝트의 이름은 유효한 -[DNS 서브도메인 이름](/ko/docs/concepts/overview/working-with-objects/names/#dns-서브도메인-이름)이어야 한다. +각 ControllerRevision은 데몬셋 리비전의 어노테이션과 템플릿을 +저장한다. -`kubectl rollout undo` 는 특정 `ControllerRevision` 을 가져와 데몬셋 -템플릿을 `ControllerRevision` 에 저장된 템플릿으로 바꾼다. +`kubectl rollout undo` 는 특정 ControllerRevision을 가져와 데몬셋 +템플릿을 ControllerRevision에 저장된 템플릿으로 바꾼다. `kubectl rollout undo` 는 `kubectl edit` 또는 `kubectl apply` 와 같은 다른 명령을 통해 데몬셋 템플릿을 이전 리비전으로 업데이트하는 것과 같다. {{< note >}} 데몬셋 리비전은 롤 포워드만 한다. 즉, 롤백이 -완료된 후, 롤백될 `ControllerRevision` 의 +완료된 후, 롤백될 ControllerRevision의 리비전 번호(`.revision` 필드)가 증가한다. 예를 들어, 시스템에 리비전 1과 2가 있고, 리비전 2에서 리비전 1으로 롤백하면, -`ControllerRevision` 은 `.revision: 1` 에서 `.revision: 3` 이 된다. +ControllerRevision은 `.revision: 1` 에서 `.revision: 3` 이 된다. {{< /note >}} ## 문제 해결 @@ -152,4 +146,5 @@ NAME CONTROLLER REVISION AGE * [데몬셋 롤링 업데이트 문제 해결](/ko/docs/tasks/manage-daemon/update-daemon-set/#문제-해결)을 참고한다. -{{% /capture %}} + + diff --git a/content/ko/docs/tasks/manage-daemon/update-daemon-set.md b/content/ko/docs/tasks/manage-daemon/update-daemon-set.md index 78ff272042..925f174206 100644 --- a/content/ko/docs/tasks/manage-daemon/update-daemon-set.md +++ b/content/ko/docs/tasks/manage-daemon/update-daemon-set.md @@ -1,24 +1,27 @@ --- title: 데몬셋(DaemonSet)에서 롤링 업데이트 수행 -content_template: templates/task +content_type: task weight: 10 --- -{{% capture overview %}} + + +<!-- overview --> 이 페이지는 데몬셋에서 롤링 업데이트를 수행하는 방법을 보여준다. -{{% /capture %}} -{{% capture prerequisites %}} + +## {{% heading "prerequisites" %}} * 데몬셋 롤링 업데이트 기능은 쿠버네티스 버전 1.6 이상에서만 지원된다. -{{% /capture %}} -{{% capture steps %}} + + +<!-- steps --> ## 데몬셋 업데이트 전략 @@ -188,13 +191,14 @@ kubectl get pods -l name=fluentd-elasticsearch -o wide -n kube-system kubectl delete ds fluentd-elasticsearch -n kube-system ``` -{{% /capture %}} -{{% capture whatsnext %}} + +## {{% heading "whatsnext" %}} + * [태스크: 데몬셋에서 롤백 수행](/ko/docs/tasks/manage-daemon/rollback-daemon-set/)을 참고한다. * [개념: 기존 데몬셋 파드를 채택하기 위한 데몬셋 생성](/ko/docs/concepts/workloads/controllers/daemonset/)을 참고한다. -{{% /capture %}} + diff --git a/content/ko/docs/tasks/manage-gpus/scheduling-gpus.md b/content/ko/docs/tasks/manage-gpus/scheduling-gpus.md index 01d6d8331e..78c5dc2cbd 100644 --- a/content/ko/docs/tasks/manage-gpus/scheduling-gpus.md +++ b/content/ko/docs/tasks/manage-gpus/scheduling-gpus.md @@ -1,10 +1,11 @@ --- - - content_type: concept title: GPU 스케줄링 +description: 클러스터의 노드별로 리소스로 사용할 GPU를 구성하고 스케줄링한다. --- + + <!-- overview --> {{< feature-state state="beta" for_k8s_version="v1.10" >}} @@ -98,7 +99,7 @@ kubectl create -f https://raw.githubusercontent.com/RadeonOpenCompute/k8s-device - Kubelet은 자신의 컨테이너 런타임으로 도커를 사용해야 한다. - 도커는 runc 대신 `nvidia-container-runtime` 이 [기본 런타임](https://github.com/NVIDIA/k8s-device-plugin#preparing-your-gpu-nodes)으로 설정되어야 한다. -- NVIDIA 드라이버의 버전은 조건 ~= 361.93 을 만족해야 한다. +- NVIDIA 드라이버의 버전은 조건 ~= 384.81을 만족해야 한다. 클러스터가 실행 중이고 위의 요구 사항이 만족된 후, NVIDIA 디바이스 플러그인을 배치하기 위해서는 아래 명령어를 실행한다. @@ -140,7 +141,7 @@ Google은 GKE에서 NVIDIA GPU 사용에 대한 자체 [설명서](https://cloud 만약 클러스터의 노드들이 서로 다른 타입의 GPU를 가지고 있다면, 사용자는 파드를 적합한 노드에 스케줄 하기 위해서 -[노드 레이블과 노드 셀렉터](/docs/tasks/configure-pod-container/assign-pods-nodes/)를 사용할 수 있다. +[노드 레이블과 노드 셀렉터](/ko/docs/tasks/configure-pod-container/assign-pods-nodes/)를 사용할 수 있다. 예를 들면, @@ -215,5 +216,3 @@ spec: 이것은 파드가 사용자가 지정한 GPU 타입을 가진 노드에 스케줄 되도록 만든다. - - diff --git a/content/ko/docs/tasks/manage-hugepages/scheduling-hugepages.md b/content/ko/docs/tasks/manage-hugepages/scheduling-hugepages.md index c48a11ab56..515b9c2cdd 100644 --- a/content/ko/docs/tasks/manage-hugepages/scheduling-hugepages.md +++ b/content/ko/docs/tasks/manage-hugepages/scheduling-hugepages.md @@ -1,18 +1,17 @@ --- title: HugePages 관리 -content_template: templates/task +content_type: task +description: 클러스터에서 huge page를 스케줄할 수 있는 리소스로 구성하고 관리한다. --- -{{% capture overview %}} +<!-- overview --> {{< feature-state state="stable" >}} -쿠버네티스는 **GA** 기능으로 파드의 애플리케이션에 미리 할당된 -huge page의 할당과 사용을 지원한다. 이 페이지에서는 사용자가 -huge page를 사용하는 방법과 현재의 제약 사항에 대해 설명한다. +쿠버네티스는 파드의 애플리케이션에 미리 할당된 +huge page의 할당과 사용을 지원한다. 이 페이지에서는 사용자가 huge page를 사용하는 방법에 대해 설명한다. -{{% /capture %}} +## {{% heading "prerequisites" %}} -{{% capture prerequisites %}} 1. 쿠버네티스 노드는 노드에 대한 huge page 용량을 보고하기 위해 huge page를 미리 할당해야 한다. 노드는 여러 크기의 huge page를 미리 할당할 수 @@ -21,9 +20,9 @@ huge page를 사용하는 방법과 현재의 제약 사항에 대해 설명한 노드는 모든 huge page 리소스를 스케줄 가능한 리소스로 자동 검색하고 보고한다. -{{% /capture %}} -{{% capture steps %}} + +<!-- steps --> ## API @@ -116,11 +115,4 @@ glossary_tooltip text="kubelet" term_id="kubelet" >}} 및 {{< glossary_tooltip text="kube-apiserver" term_id="kube-apiserver" >}} (`--feature-gates=HugePageStorageMediumSize=true`)의 `HugePageStorageMediumSize` [기능 -게이트](/docs/reference/command-line-tools-reference/feature-gates/)를 사용하여 활성화할 수 있다. - -## 향후 버전 - -- NUMA 지역성(locality)은 서비스 품질(QoS)의 기능으로 보장할 예정이다. -- 리밋레인지(LimitRange)를 지원할 예정이다. - -{{% /capture %}} +게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)를 사용하여 활성화할 수 있다. diff --git a/content/ko/docs/tasks/manage-kubernetes-objects/_index.md b/content/ko/docs/tasks/manage-kubernetes-objects/_index.md index 3c6566741c..ebb3c90272 100644 --- a/content/ko/docs/tasks/manage-kubernetes-objects/_index.md +++ b/content/ko/docs/tasks/manage-kubernetes-objects/_index.md @@ -1,4 +1,5 @@ --- title: "쿠버네티스 오브젝트 관리" +description: 쿠버네티스 API와 상호 작용하기 위한 선언적이고 명령적인 패러다임 weight: 25 --- diff --git a/content/ko/docs/tasks/manage-kubernetes-objects/declarative-config.md b/content/ko/docs/tasks/manage-kubernetes-objects/declarative-config.md index 7c81129176..f3b15d3206 100644 --- a/content/ko/docs/tasks/manage-kubernetes-objects/declarative-config.md +++ b/content/ko/docs/tasks/manage-kubernetes-objects/declarative-config.md @@ -16,7 +16,7 @@ weight: 10 ## {{% heading "prerequisites" %}} -[`kubectl`](/docs/tasks/tools/install-kubectl/)를 설치한다. +[`kubectl`](/ko/docs/tasks/tools/install-kubectl/)를 설치한다. {{< include "task-tutorial-prereqs.md" >}} {{< version-check >}} @@ -65,7 +65,7 @@ weight: 10 kubectl apply -f <디렉터리>/ ``` -이것은  각 오브젝트에 대해 `kubectl.kubernetes.io/last-applied-configuration: '{...}'` +이것은 각 오브젝트에 대해 `kubectl.kubernetes.io/last-applied-configuration: '{...}'` 어노테이션을 설정한다. 해당 어노테이션은 오브젝트를 생성하기 위해 사용했던 오브젝트 구성 파일의 내용을 포함한다.  @@ -78,9 +78,11 @@ kubectl apply -f <디렉터리>/ {{< codenew file="application/simple_deployment.yaml" >}} 생성될 오브젝트를 출력하려면 `kubectl diff`를 실행한다.  + ```shell kubectl diff -f https://k8s.io/examples/application/simple_deployment.yaml ``` + {{< note >}} `diff`는 `kube-apiserver`의 활성화가 필요한 [서버사이드 dry-run](/docs/reference/using-api/api-concepts/#dry-run)을 사용한다. @@ -1000,8 +1002,8 @@ template: ## {{% heading "whatsnext" %}} + * [명령형 커맨드 사용하여 쿠버네티스 오브젝트 관리하기](/ko/docs/tasks/manage-kubernetes-objects/imperative-command/) * [구성 파일 사용하여 쿠버네티스 오브젝트 관리하기](/ko/docs/tasks/manage-kubernetes-objects/imperative-config/) * [Kubectl 명령어 참조](/docs/reference/generated/kubectl/kubectl/) * [쿠버네티스 API 참조](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/) - diff --git a/content/ko/docs/tasks/manage-kubernetes-objects/imperative-command.md b/content/ko/docs/tasks/manage-kubernetes-objects/imperative-command.md index 47089a10dc..ac7690a325 100644 --- a/content/ko/docs/tasks/manage-kubernetes-objects/imperative-command.md +++ b/content/ko/docs/tasks/manage-kubernetes-objects/imperative-command.md @@ -12,7 +12,7 @@ weight: 30 ## {{% heading "prerequisites" %}} -[`kubectl`](/docs/tasks/tools/install-kubectl/)을 설치한다. +[`kubectl`](/ko/docs/tasks/tools/install-kubectl/)을 설치한다. {{< include "task-tutorial-prereqs.md" >}} {{< version-check >}} @@ -164,8 +164,8 @@ kubectl create --edit -f /tmp/srv.yaml ## {{% heading "whatsnext" %}} + * [오브젝트 구성을 이용하여 쿠버네티스 관리하기(명령형)](/ko/docs/tasks/manage-kubernetes-objects/imperative-config/) * [오브젝트 구성을 이용하여 쿠버네티스 관리하기(선언형)](/ko/docs/tasks/manage-kubernetes-objects/declarative-config/) * [Kubectl 커맨드 참조](/docs/reference/generated/kubectl/kubectl/) * [쿠버네티스 API 참조](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/) - diff --git a/content/ko/docs/tasks/manage-kubernetes-objects/imperative-config.md b/content/ko/docs/tasks/manage-kubernetes-objects/imperative-config.md index ca6d1de04d..49691c341b 100644 --- a/content/ko/docs/tasks/manage-kubernetes-objects/imperative-config.md +++ b/content/ko/docs/tasks/manage-kubernetes-objects/imperative-config.md @@ -13,7 +13,7 @@ weight: 40 ## {{% heading "prerequisites" %}} -[`kubectl`](/docs/tasks/tools/install-kubectl/)을 설치한다. +[`kubectl`](/ko/docs/tasks/tools/install-kubectl/)을 설치한다. {{< include "task-tutorial-prereqs.md" >}} {{< version-check >}} @@ -147,8 +147,8 @@ template: ## {{% heading "whatsnext" %}} + * [명령형 커맨드를 이용한 쿠버네티스 오브젝트 관리하기](/ko/docs/tasks/manage-kubernetes-objects/imperative-command/) * [오브젝트 구성을 이용하여 쿠버네티스 오브젝트 관리하기 (선언형)](/ko/docs/tasks/manage-kubernetes-objects/declarative-config/) * [Kubectl 커멘드 참조](/docs/reference/generated/kubectl/kubectl/) * [쿠버네티스 API 참조](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/) - diff --git a/content/ko/docs/tasks/manage-kubernetes-objects/kustomization.md b/content/ko/docs/tasks/manage-kubernetes-objects/kustomization.md index 20435a4881..6a45b5a73b 100644 --- a/content/ko/docs/tasks/manage-kubernetes-objects/kustomization.md +++ b/content/ko/docs/tasks/manage-kubernetes-objects/kustomization.md @@ -6,12 +6,12 @@ weight: 20 <!-- overview --> -[Kustomize](https://github.com/kubernetes-sigs/kustomize)는 -[kustomization 파일](https://github.com/kubernetes-sigs/kustomize/blob/master/docs/glossary.md#kustomization)을 +[Kustomize](https://github.com/kubernetes-sigs/kustomize)는 +[kustomization 파일](https://github.com/kubernetes-sigs/kustomize/blob/master/docs/glossary.md#kustomization)을 통해 쿠버네티스 오브젝트를 사용자가 원하는 대로 변경하는(customize) 독립형 도구이다. -1.14 이후로, kubectl도 -kustomization 파일을 사용한 쿠버네티스 오브젝트의 관리를 지원한다. +1.14 이후로, kubectl도 +kustomization 파일을 사용한 쿠버네티스 오브젝트의 관리를 지원한다. kustomization 파일을 포함하는 디렉터리 내의 리소스를 보려면 다음 명령어를 실행한다. ```shell @@ -29,7 +29,7 @@ kubectl apply -k <kustomization_directory> ## {{% heading "prerequisites" %}} -[`kubectl`](/docs/tasks/tools/install-kubectl/)을 설치한다. +[`kubectl`](/ko/docs/tasks/tools/install-kubectl/)을 설치한다. {{< include "task-tutorial-prereqs.md" >}} {{< version-check >}} @@ -47,7 +47,7 @@ Kustomize는 쿠버네티스 구성을 사용자 정의화하는 도구이다. ### 리소스 생성 -컨피그 맵과 시크릿은 파드같은 다른 쿠버네티스 오브젝트에서 사용되는 설정이나 민감한 데이터를 가지고 있다. +컨피그 맵과 시크릿은 파드같은 다른 쿠버네티스 오브젝트에서 사용되는 설정이나 민감한 데이터를 가지고 있다. 컨피그 맵이나 시크릿의 실질적인 소스는 일반적으로 `.properties` 파일이나 ssh key 파일과 같은 것들은 클러스터 외부에 있다. Kustomize는 시크릿과 컨피그 맵을 파일이나 문자열에서 생성하는 `secretGenerator`와 `configMapGenerator`를 가지고 있다. @@ -207,7 +207,7 @@ metadata: ### 교차 편집 필드 설정 -프로젝트 내 모든 쿠버네티스 리소스에 교차 편집 필드를 설정하는 것은 꽤나 일반적이다. +프로젝트 내 모든 쿠버네티스 리소스에 교차 편집 필드를 설정하는 것은 꽤나 일반적이다. 교차 편집 필드를 설정하는 몇 가지 사용 사례는 다음과 같다. * 모든 리소스에 동일한 네임스페이스를 설정 @@ -283,13 +283,13 @@ spec: ### 리소스 구성과 사용자 정의 -프로젝트 내 리소스의 집합을 구성하여 이들을 동일한 파일이나 디렉터리 내에서 -관리하는 것은 일반적이다. +프로젝트 내 리소스의 집합을 구성하여 이들을 동일한 파일이나 디렉터리 내에서 +관리하는 것은 일반적이다. Kustomize는 서로 다른 파일들로 리소스를 구성하고 패치나 다른 사용자 정의를 이들에 적용하는 것을 제공한다. #### 구성 -Kustomize는 서로 다른 리소스들의 구성을 지원한다. `kustomization.yaml` 파일 내 `resources` 필드는 구성 내에 포함하려는 리소스들의 리스트를 정의한다. `resources` 리스트 내에 리소스의 구성 파일의 경로를 설정한다. +Kustomize는 서로 다른 리소스들의 구성을 지원한다. `kustomization.yaml` 파일 내 `resources` 필드는 구성 내에 포함하려는 리소스들의 리스트를 정의한다. `resources` 리스트 내에 리소스의 구성 파일의 경로를 설정한다. 다음 예제는 디플로이먼트와 서비스로 구성된 NGINX 애플리케이션이다. ```shell @@ -344,7 +344,7 @@ EOF #### 사용자 정의 -패치는 리소스에 다른 사용자 정의를 적용하는 데 사용할 수 있다. Kustomize는 +패치는 리소스에 다른 사용자 정의를 적용하는 데 사용할 수 있다. Kustomize는 `patchesStrategicMerge`와 `patchesJson6902`를 통해 서로 다른 패치 메커니즘을 지원한다. `patchesStrategicMerge`는 파일 경로들의 리스트이다. 각각의 파일은 [전략적 병합 패치](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-api-machinery/strategic-merge-patch.md)로 분석될 수 있어야 한다. 패치 내부의 네임은 반드시 이미 읽혀진 리소스 네임과 일치해야 한다. 한 가지 일을 하는 작은 패치가 권장된다. 예를 들기 위해 디플로이먼트 레플리카 숫자를 증가시키는 하나의 패치와 메모리 상한을 설정하는 다른 패치를 생성한다. ```shell @@ -432,10 +432,10 @@ spec: - containerPort: 80 ``` -모든 리소스 또는 필드가 전략적 병합 패치를 지원하는 것은 아니다. 임의의 리소스 내 임의의 필드의 수정을 지원하기 위해, -Kustomize는 `patchesJson6902`를 통한 [JSON 패치](https://tools.ietf.org/html/rfc6902) 적용을 제공한다. -Json 패치의 정확한 리소스를 찾기 위해, 해당 리소스의 group, version, kind, name이 -`kustomization.yaml` 내에 명시될 필요가 있다. 예를 들면, `patchesJson6902`를 통해 +모든 리소스 또는 필드가 전략적 병합 패치를 지원하는 것은 아니다. 임의의 리소스 내 임의의 필드의 수정을 지원하기 위해, +Kustomize는 `patchesJson6902`를 통한 [JSON 패치](https://tools.ietf.org/html/rfc6902) 적용을 제공한다. +Json 패치의 정확한 리소스를 찾기 위해, 해당 리소스의 group, version, kind, name이 +`kustomization.yaml` 내에 명시될 필요가 있다. 예를 들면, `patchesJson6902`를 통해 디플로이먼트 오브젝트의 레플리카 개수를 증가시킬 수 있다. ```shell @@ -508,7 +508,7 @@ spec: - containerPort: 80 ``` -패치 기능에 추가로 Kustomize는 패치를 생성하지 않고 컨테이너 이미지를 사용자 정의하거나 다른 오브젝트의 필드 값을 컨테이너에 주입하는 +패치 기능에 추가로 Kustomize는 패치를 생성하지 않고 컨테이너 이미지를 사용자 정의하거나 다른 오브젝트의 필드 값을 컨테이너에 주입하는 기능도 제공한다. 예를 들어 `kustomization.yaml`의 `images` 필드에 신규 이미지를 지정하여 컨테이너에서 사용되는 이미지를 변경할 수 있다. ```shell @@ -566,9 +566,9 @@ spec: - containerPort: 80 ``` -가끔, 파드 내에서 실행되는 애플리케이션이 다른 오브젝트의 설정 값을 사용해야 할 수도 있다. 예를 들어, -디플로이먼트 오브젝트의 파드는 Env 또는 커맨드 인수로 해당 서비스 네임을 읽어야 한다고 하자. -`kustomization.yaml` 파일에 `namePrefix` 또는 `nameSuffix`가 추가되면 서비스 네임이 변경될 수 있다. +가끔, 파드 내에서 실행되는 애플리케이션이 다른 오브젝트의 설정 값을 사용해야 할 수도 있다. 예를 들어, +디플로이먼트 오브젝트의 파드는 Env 또는 커맨드 인수로 해당 서비스 네임을 읽어야 한다고 하자. +`kustomization.yaml` 파일에 `namePrefix` 또는 `nameSuffix`가 추가되면 서비스 네임이 변경될 수 있다. 커맨드 인수 내에 서비스 네임을 하드 코딩하는 것을 권장하지 않는다. 이 용도에서 Kustomize는 `vars`를 통해 containers에 서비스 네임을 삽입할 수 있다. ```shell @@ -655,11 +655,11 @@ spec: ## Base와 Overlay -Kustomize는 **base**와 **overlay**의 개념을 가지고 있다. **base**는 `kustomization.yaml`과 함께 사용되는 디렉터리다. 이는 -사용자 정의와 관련된 리소스들의 집합을 포함한다. `kustomization.yaml`의 내부에 표시되는 base는 로컬 디렉터리이거나 원격 리포지터리의 디렉터리가 -될 수 있다. **overlay**는 `kustomization.yaml`이 있는 디렉터리로 -다른 kustomization 디렉터리들을 `bases`로 참조한다. **base**는 overlay에 대해서 알지 못하며 여러 overlay들에서 사용될 수 있다. -한 overlay는 다수의 base들을 가질 수 있고, base들에서 모든 리소스를 구성할 수 있으며, +Kustomize는 **base**와 **overlay**의 개념을 가지고 있다. **base**는 `kustomization.yaml`과 함께 사용되는 디렉터리다. 이는 +사용자 정의와 관련된 리소스들의 집합을 포함한다. `kustomization.yaml`의 내부에 표시되는 base는 로컬 디렉터리이거나 원격 리포지터리의 디렉터리가 +될 수 있다. **overlay**는 `kustomization.yaml`이 있는 디렉터리로 +다른 kustomization 디렉터리들을 `bases`로 참조한다. **base**는 overlay에 대해서 알지 못하며 여러 overlay들에서 사용될 수 있다. +한 overlay는 다수의 base들을 가질 수 있고, base들에서 모든 리소스를 구성할 수 있으며, 이들의 위에 사용자 정의도 가질 수 있다. 다음은 base에 대한 예이다. @@ -711,7 +711,7 @@ resources: EOF ``` -이 base는 다수의 overlay에서 사용될 수 있다. 다른 `namePrefix` 또는 다른 교차 편집 필드들을 +이 base는 다수의 overlay에서 사용될 수 있다. 다른 `namePrefix` 또는 다른 교차 편집 필드들을 서로 다른 overlay에 추가할 수 있다. 다음 예제는 동일한 base를 사용하는 두 overlay들이다. ```shell @@ -732,7 +732,7 @@ EOF ## Kustomize를 이용하여 오브젝트를 적용/확인/삭제하는 방법 -`kustomization.yaml`에서 관리되는 리소스를 인식하려면 `kubectl` 명령어에 `--kustomize` 나 `-k`를 사용한다. +`kustomization.yaml`에서 관리되는 리소스를 인식하려면 `kubectl` 명령어에 `--kustomize` 나 `-k`를 사용한다. `-k`는 다음과 같이 kustomization 디렉터리를 가리키고 있어야 한다는 것을 주의한다. ```shell @@ -835,5 +835,3 @@ deployment.apps "dev-my-nginx" deleted * [Kubectl Book](https://kubectl.docs.kubernetes.io) * [Kubectl Command Reference](/docs/reference/generated/kubectl/kubectl/) * [Kubernetes API Reference](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/) - - diff --git a/content/ko/docs/tasks/network/_index.md b/content/ko/docs/tasks/network/_index.md index 26317241ec..e7ab0fae52 100644 --- a/content/ko/docs/tasks/network/_index.md +++ b/content/ko/docs/tasks/network/_index.md @@ -1,4 +1,5 @@ --- -title: "네트워크" +title: "네트워킹" +description: 클러스터에 대한 네트워킹 설정 방법에 대해 배운다. weight: 160 --- diff --git a/content/ko/docs/tasks/network/validate-dual-stack.md b/content/ko/docs/tasks/network/validate-dual-stack.md index 0bbb20b99d..5364e7bebb 100644 --- a/content/ko/docs/tasks/network/validate-dual-stack.md +++ b/content/ko/docs/tasks/network/validate-dual-stack.md @@ -12,7 +12,7 @@ content_type: task * 이중 스택 네트워킹을 위한 제공자 지원 (클라우드 제공자 또는 기타 제공자들은 라우팅 가능한 IPv4/IPv6 네트워크 인터페이스를 제공하는 쿠버네티스 노드들을 제공해야 한다.) -* 이중 스택을 지원하는 [네트워크 플러그인](/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/) (예. Kubenet 또는 Calico) +* 이중 스택을 지원하는 [네트워크 플러그인](/ko/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/) (예. Kubenet 또는 Calico) * IPVS 모드로 구동되는 Kube-proxy * [이중 스택 활성화](/ko/docs/concepts/services-networking/dual-stack/) 클러스터 @@ -155,5 +155,3 @@ my-service ClusterIP fe80:20d::d06b <none> 80/TCP 9s NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE my-service ClusterIP fe80:20d::d06b 2001:db8:f100:4002::9d37:c0d7 80:31868/TCP 30s ``` - - diff --git a/content/ko/docs/tasks/run-application/_index.md b/content/ko/docs/tasks/run-application/_index.md index 203d2eb39c..13039181be 100644 --- a/content/ko/docs/tasks/run-application/_index.md +++ b/content/ko/docs/tasks/run-application/_index.md @@ -1,4 +1,5 @@ --- title: "애플리케이션 실행" +description: 스테이트리스와 스테이트풀 애플리케이션 모두를 실행하고 관리한다. weight: 40 --- diff --git a/content/ko/docs/tasks/run-application/delete-stateful-set.md b/content/ko/docs/tasks/run-application/delete-stateful-set.md new file mode 100644 index 0000000000..4c50079dc3 --- /dev/null +++ b/content/ko/docs/tasks/run-application/delete-stateful-set.md @@ -0,0 +1,84 @@ +--- +title: 스테이트풀셋(StatefulSet) 삭제하기 +content_type: task +weight: 60 +--- + +<!-- overview --> + +이 작업은 {{< glossary_tooltip term_id="StatefulSet"text="스테이트풀셋">}}을 삭제하는 방법을 설명한다. + + + +## {{% heading "prerequisites" %}} + + +* 이 작업은 클러스터에 스테이트풀셋으로 표시되는 애플리케이션이 있다고 가정한다. + + + +<!-- steps --> + +## 스테이트풀셋 삭제 + +쿠버네티스에서 다른 리소스를 삭제하는 것과 같은 방식으로 스테이트풀셋을 삭제할 수 있다. `kubectl delete` 명령어를 사용하고 파일 또는 이름으로 스테이트풀셋을 지정하자. + +```shell +kubectl delete -f <file.yaml> +``` + +```shell +kubectl delete statefulsets <statefulset-name> +``` + +스테이트풀셋 자체를 삭제한 후 연결된 헤드리스 서비스는 별도로 삭제해야 할 수도 있다. + +```shell +kubectl delete service <service-name> +``` + +kubectl을 통해 스테이트풀셋을 삭제하면 0으로 스케일이 낮아지고, 스테이트풀셋에 포함된 모든 파드가 삭제된다. +파드가 아닌 스테이트풀셋만 삭제하려면, `--cascade=false` 를 사용한다. + +```shell +kubectl delete -f <file.yaml> --cascade=false +``` + +`kubectl delete` 에 `--cascade=false` 를 사용함으로써, 스테이트풀셋 객체가 삭제 된 후에도 스테이트풀셋에 의해 관리된 파드는 남게 된다. 만약 파드가 `app=myapp` 레이블을 갖고 있다면, 다음과 같이 파드를 삭제할 수 있다. + +```shell +kubectl delete pods -l app=myapp +``` + +### 퍼시스턴트볼륨(PersistentVolume) + +스테이트풀셋의 파드들을 삭제하는 것이 연결된 볼륨을 삭제하는 것은 아니다. 이것은 볼륨을 삭제하기 전에 볼륨에서 데이터를 복사할 수 있는 기회를 준다. 파드들이 [terminating 상태](/ko/docs/concepts/workloads/pods/pod/#파드의-종료)가 된 후 PVC를 삭제하는 것은 스토리지클래스(StorageClass) 와 반환 정책에 따라 백업 퍼시스턴트볼륨이 삭제될 수도 있다. 클레임 삭제 후 볼륨에 접근할 수 있다고 가정하면 안된다. + +{{< note >}} +PVC를 삭제할 때 데이터 손실될 수 있음에 주의하자. +{{< /note >}} + +### 스테이트풀셋의 완벽한 삭제 + +연결된 파드를 포함해서 스테이트풀셋의 모든 것을 간단히 삭제하기 위해 다음과 같이 일련의 명령을 실행 한다. + +```shell +grace=$(kubectl get pods <stateful-set-pod> --template '{{.spec.terminationGracePeriodSeconds}}') +kubectl delete statefulset -l app=myapp +sleep $grace +kubectl delete pvc -l app=myapp + +``` + +위의 예에서 파드에는 `app=myapp` 라는 레이블이 있다. 사용자에게 적절한 레이블로 대체하자. + +### 스테이트풀셋 파드의 강제 삭제 + +스테이트풀셋의 일부 파드가 오랫동안 'Terminating' 또는 'Unknown' 상태에 있는 경우, apiserver에 수동적으로 개입하여 파드를 강제 삭제할 수도 있다. 이것은 잠재적으로 위험한 작업이다. 자세한 설명은 [스테이트풀셋 파드 강제 삭제하기](/docs/tasks/run-application/force-delete-stateful-set-pod/)를 참고한다. + + + +## {{% heading "whatsnext" %}} + + +[스테이트풀셋 파드 강제 삭제하기](/docs/tasks/run-application/force-delete-stateful-set-pod/)에 대해 더 알아보기. diff --git a/content/ko/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough.md b/content/ko/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough.md index fdf1f75411..ee5db9d3f2 100644 --- a/content/ko/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough.md +++ b/content/ko/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough.md @@ -8,7 +8,7 @@ weight: 100 Horizontal Pod Autoscaler는 CPU 사용량(또는 베타 지원의 다른 애플리케이션 지원 메트릭)을 관찰하여 -레플리케이션 컨트롤러, 디플로이먼트, 레플리카 셋 또는 스테이트풀 셋의 파드 개수를 자동으로 스케일한다. +레플리케이션 컨트롤러, 디플로이먼트, 레플리카셋(ReplicaSet) 또는 스테이트풀셋(StatefulSet)의 파드 개수를 자동으로 스케일한다. 이 문서는 php-apache 서버를 대상으로 Horizontal Pod Autoscaler를 동작해보는 예제이다. Horizontal Pod Autoscaler 동작과 관련된 더 많은 정보를 위해서는 [Horizontal Pod Autoscaler 사용자 가이드](/ko/docs/tasks/run-application/horizontal-pod-autoscale/)를 참고하기 바란다. diff --git a/content/ko/docs/tasks/run-application/horizontal-pod-autoscale.md b/content/ko/docs/tasks/run-application/horizontal-pod-autoscale.md index c242695165..4afcb6927d 100644 --- a/content/ko/docs/tasks/run-application/horizontal-pod-autoscale.md +++ b/content/ko/docs/tasks/run-application/horizontal-pod-autoscale.md @@ -9,13 +9,17 @@ content_type: concept weight: 90 --- + + + + <!-- overview --> Horizontal Pod Autoscaler는 CPU 사용량 (또는 [사용자 정의 메트릭](https://git.k8s.io/community/contributors/design-proposals/instrumentation/custom-metrics-api.md), 아니면 다른 애플리케이션 지원 메트릭)을 관찰하여 레플리케이션 -컨트롤러, 디플로이먼트, 레플리카 셋 또는 스테이트풀 셋의 파드 개수를 자동으로 스케일한다. Horizontal -Pod Autoscaler는 크기를 조정할 수 없는 오브젝트(예: 데몬 셋)에는 적용되지 않는다. +컨트롤러(ReplicationController), 디플로이먼트(Deployment), 레플리카셋(ReplicaSet) 또는 스테이트풀셋(StatefulSet)의 파드 개수를 자동으로 스케일한다. Horizontal +Pod Autoscaler는 크기를 조정할 수 없는 오브젝트(예: 데몬셋(DaemonSet))에는 적용되지 않는다. Horizontal Pod Autoscaler는 쿠버네티스 API 리소스 및 컨트롤러로 구현된다. 리소스는 컨트롤러의 동작을 결정한다. @@ -160,11 +164,7 @@ HPA가 여전히 확장할 수 있음을 의미한다. 마지막으로, HPA가 목표를 스케일하기 직전에 스케일 권장 사항이 기록된다. 컨트롤러는 구성 가능한 창(window) 내에서 가장 높은 권장 -사항을 선택하도록 해당 창 내의 모든 권장 사항을 고려한다. 이 값은 -`--horizontal-pod-autoscaler-downscale-stabilization` 플래그 또는 HPA 오브젝트 -동작 `behavior.scaleDown.stabilizationWindowSeconds` ([구성가능한 -스케일링 동작 지원](#구성가능한-스케일링-동작-지원)을 본다)을 -사용하여 설정할 수 있고, 기본 값은 5분이다. +사항을 선택하도록 해당 창 내의 모든 권장 사항을 고려한다. 이 값은 `--horizontal-pod-autoscaler-downscale-stabilization` 플래그를 사용하여 설정할 수 있고, 기본값은 5분이다. 즉, 스케일 다운이 점진적으로 발생하여 급격히 변동하는 메트릭 값의 영향을 완만하게 한다. @@ -179,9 +179,9 @@ CPU에 대한 오토스케일링 지원만 포함하는 안정된 버전은 새로운 필드는 `autoscaling/v1`로 작업할 때 어노테이션으로 보존된다. HorizontalPodAutoscaler API 오브젝트 생성시 지정된 이름이 유효한 -[DNS 서브도메인 이름](/ko/docs/concepts/overview/working-with-objects/names/#dns-서브도메인-이름들)인지 확인해야 한다. +[DNS 서브도메인 이름](/ko/docs/concepts/overview/working-with-objects/names/#dns-서브도메인-이름)인지 확인해야 한다. API 오브젝트에 대한 자세한 내용은 -[HorizontalPodAutoscaler 오브젝트](https://git.k8s.io/community/contributors/design-proposals/autoscaling/horizontal-pod-autoscaler.md#horizontalpodautoscaler-object)에서 찾을 수 있다. +[HorizontalPodAutoscaler 오브젝트](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#horizontalpodautoscaler-v1-autoscaling)에서 찾을 수 있다. ## kubectl에서 Horizontal Pod Autoscaler 지원 @@ -199,9 +199,9 @@ Horizontal Pod Autoscaler는 모든 API 리소스와 마찬가지로 `kubectl` ## 롤링 업데이트 중 오토스케일링 -현재 쿠버네티스에서는 기본 레플리카 셋를 관리하는 디플로이먼트 오브젝트를 사용하여 롤링 업데이트를 수행할 수 있다. +현재 쿠버네티스에서는 기본 레플리카셋를 관리하는 디플로이먼트 오브젝트를 사용하여 롤링 업데이트를 수행할 수 있다. Horizontal Pod Autoscaler는 후자의 방법을 지원한다. Horizontal Pod Autoscaler는 디플로이먼트 오브젝트에 바인딩되고, -디플로이먼트 오브젝트를 위한 크기를 설정하며, 디플로이먼트는 기본 레플리카 셋의 크기를 결정한다. +디플로이먼트 오브젝트를 위한 크기를 설정하며, 디플로이먼트는 기본 레플리카셋의 크기를 결정한다. Horizontal Pod Autoscaler는 레플리케이션 컨트롤러를 직접 조작하는 롤링 업데이트에서 작동하지 않는다. 즉, Horizontal Pod Autoscaler를 레플리케이션 컨트롤러에 바인딩하고 롤링 업데이트를 수행할 수 없다. (예 : `kubectl rolling-update`) @@ -229,15 +229,10 @@ v1.12부터는 새로운 알고리즘 업데이트가 업스케일 지연에 대 이러한 파라미터 값을 조정할 때 클러스터 운영자는 가능한 결과를 알아야 한다. 지연(쿨-다운) 값이 너무 길면, Horizontal Pod Autoscaler가 워크로드 변경에 반응하지 않는다는 불만이 있을 수 있다. 그러나 지연 값을 -너무 짧게 설정하면, 레플리카 셋의 크기가 평소와 같이 계속 스래싱될 수 +너무 짧게 설정하면, 레플리카셋의 크기가 평소와 같이 계속 스래싱될 수 있다. {{< /note >}} -v1.17 부터 v2beta2 API 필드에서 `behavior.scaleDown.stabilizationWindowSeconds` -를 설정하여 다운스케일 안정화 창을 HPA별로 설정할 수 있다. -[구성가능한 스케일링 -동작 지원](#구성가능한-스케일링-동작-지원)을 본다. - ## 멀티 메트릭을 위한 지원 Kubernetes 1.6은 멀티 메트릭을 기반으로 스케일링을 지원한다. `autoscaling/v2beta2` API @@ -265,7 +260,7 @@ Horizontal Pod Autoscaler 컨트롤러에서는 더 이상 스케일 할 사용 기본적으로 HorizontalPodAutoscaler 컨트롤러는 일련의 API에서 메트릭을 검색한다. 이러한 API에 접속하려면 클러스터 관리자는 다음을 확인해야 한다. -* [API 집합 레이어](/docs/tasks/access-kubernetes-api/configure-aggregation-layer/) 활성화 +* [API 애그리게이션 레이어](/docs/tasks/extend-kubernetes/configure-aggregation-layer/) 활성화 * 해당 API 등록: @@ -444,4 +439,3 @@ behavior: * 디자인 문서: [Horizontal Pod Autoscaling](https://git.k8s.io/community/contributors/design-proposals/autoscaling/horizontal-pod-autoscaler.md). * kubectl 오토스케일 커맨드: [kubectl autoscale](/docs/reference/generated/kubectl/kubectl-commands/#autoscale). * [Horizontal Pod Autoscaler](/ko/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough/)의 사용 예제. - diff --git a/content/ko/docs/tasks/run-application/run-single-instance-stateful-application.md b/content/ko/docs/tasks/run-application/run-single-instance-stateful-application.md index 37ed18a70a..8642c374af 100644 --- a/content/ko/docs/tasks/run-application/run-single-instance-stateful-application.md +++ b/content/ko/docs/tasks/run-application/run-single-instance-stateful-application.md @@ -1,37 +1,39 @@ --- title: 단일 인스턴스 스테이트풀 애플리케이션 실행하기 -content_template: templates/tutorial +content_type: tutorial weight: 20 --- -{{% capture overview %}} +<!-- overview --> 이 페이지에서는 쿠버네티스 클러스터에서 퍼시스턴트볼륨(PersistentVolume)과 디플로이먼트(Deployment)를 사용하여, 단일 인스턴스 스테이트풀 애플리케이션을 실행하는 방법을 보인다. 해당 애플리케이션은 MySQL이다. -{{% /capture %}} -{{% capture objectives %}} + +## {{% heading "objectives" %}} + * 사용자 환경의 디스크를 참조하는 퍼시스턴트볼륨 생성하기 * MySQL 디플로이먼트 생성하기 * 알려진 DNS 이름으로 클러스터의 다른 파드에 MySQL 서비스 노출하기 -{{% /capture %}} -{{% capture prerequisites %}} + +## {{% heading "prerequisites" %}} * {{< include "task-tutorial-prereqs.md" >}} {{< version-check >}} * {{< include "default-storage-class-prereqs.md" >}} -{{% /capture %}} -{{% capture lessoncontent %}} + + +<!-- lessoncontent --> ## MySQL 배포하기 @@ -180,10 +182,11 @@ kubectl delete pv mysql-pv-volume 일부 동적 프로비저너(EBS 와 PD와 같은)는 퍼시스턴트볼륨을 삭제할 때에 기본 리소스도 해제한다. -{{% /capture %}} -{{% capture whatsnext %}} + +## {{% heading "whatsnext" %}} + * [디플로이먼트 오브젝트](/ko/docs/concepts/workloads/controllers/deployment/)에 대해 더 배워 보기 @@ -193,4 +196,6 @@ kubectl delete pv mysql-pv-volume * [볼륨](/ko/docs/concepts/storage/volumes/)과 [퍼시스턴트 볼륨](/ko/docs/concepts/storage/persistent-volumes/) -{{% /capture %}} + + + diff --git a/content/ko/docs/tasks/tls/_index.md b/content/ko/docs/tasks/tls/_index.md new file mode 100644 index 0000000000..291b4b3eb1 --- /dev/null +++ b/content/ko/docs/tasks/tls/_index.md @@ -0,0 +1,6 @@ +--- +title: "TLS" +description: TLS(Transport Layer Security)를 사용하여 클러스터 내 트래픽을 보호하는 방법을 이해한다. +weight: 100 +--- + diff --git a/content/ko/docs/tasks/tls/certificate-rotation.md b/content/ko/docs/tasks/tls/certificate-rotation.md new file mode 100644 index 0000000000..7f7422411c --- /dev/null +++ b/content/ko/docs/tasks/tls/certificate-rotation.md @@ -0,0 +1,83 @@ +--- + + + +title: Kubelet의 인증서 갱신 구성 +content_type: task +--- + +<!-- overview --> +이 페이지는 kubelet에 대한 인증서 갱신을 활성화하고 구성하는 방법을 보여준다. + + +{{< feature-state for_k8s_version="v1.8" state="beta" >}} + +## {{% heading "prerequisites" %}} + + +* 쿠버네티스 1.8.0 버전 혹은 그 이상의 버전이 요구됨 + + + +<!-- steps --> + +## 개요 + +kubelet은 쿠버네티스 API 인증을 위해 인증서를 사용한다. +기본적으로 이러한 인증서는 1년 만기로 발급되므로 +너무 자주 갱신할 필요는 없다. + +쿠버네티스 1.8은 [kubelet 인증서 +갱신](/docs/reference/command-line-tools-reference/kubelet-tls-bootstrapping/)을 포함하며, +이 기능은 현재 인증서의 만료 시한이 임박한 경우, +새로운 키를 자동으로 생성하고 쿠버네티스 API에서 새로운 인증서를 요청하는 베타 기능이다. +새로운 인증서를 사용할 수 있게 되면 +쿠버네티스 API에 대한 연결을 인증하는데 사용된다. + +## 클라이언트 인증서 갱신 활성화하기 + +`kubelet` 프로세스는 현재 사용 중인 인증서의 만료 시한이 다가옴에 따라 +kubelet이 자동으로 새 인증서를 요청할지 여부를 제어하는 +`--rotate-certificates` 인자를 허용한다. +인증서 갱신은 베타 기능이므로 기능 플래그는 +`--feature-gates = RotateKubeletClientCertificate=true` 를 사용하여 활성화해야 한다. + + +`kube-controller-manager` 프로세스는 얼마나 오랜 기간 인증서가 유효한지를 제어하는 +`--experimental-cluster-signing-duration` 인자를 +허용한다. + +## 인증서 갱신 구성에 대한 이해 + +kubelet이 시작할 때 부트 스트랩 (`--bootstrap-kubeconfig` 플래그를 사용) +을 구성하면 초기 인증서를 사용하여 쿠버네티스 API에 연결하고 +인증서 서명 요청을 발행한다. +다음을 사용하여 인증서 서명 요청 상태를 볼 수 있다. + +```sh +kubectl get csr +``` + +초기에 노드의 kubelet에서 인증서 서명 요청은 `Pending` 상태이다. +인증서 서명 요청이 특정 기준을 충족하면 컨트롤러 관리자가 +자동으로 승인한 후 상태가 `Approved` 가 된다. +다음으로, 컨트롤러 관리자는 +`--experimental-cluster-signing-duration` 파라미터에 의해 지정된 기간 동안 +발행된 인증서에 서명하고 +서명된 인증서는 인증서 서명 요청에 첨부된다. + +kubelet은 쿠버네티스 API로 서명된 인증서를 가져와서 +`--cert-dir`에 지정된 위치에 디스크에 기록한다. +그런 다음 kubelet은 쿠버네티스 API에 연결해서 새로운 인증서를 사용한다. + +서명된 인증서의 만료가 다가오면 kubelet은 쿠버네티스 API를 사용하여 +새로운 인증서 서명 요청을 자동으로 발행한다. +또한, 컨트롤러 관리자는 인증서 요청을 자동으로 승인하고 +서명된 인증서를 인증서 서명 요청에 첨부한다. +kubelet은 쿠버네티스 API로 서명된 새로운 인증서를 가져와서 디스크에 쓴다. +그런 다음 새로운 인증서를 사용한 재연결을 위해서 +가지고 있는 쿠버네티스 API로의 연결을 업데이트 한다. + + + + diff --git a/content/ko/docs/tasks/tools/_index.md b/content/ko/docs/tasks/tools/_index.md index 799bc028f6..bcfcd12e4e 100755 --- a/content/ko/docs/tasks/tools/_index.md +++ b/content/ko/docs/tasks/tools/_index.md @@ -1,5 +1,6 @@ --- title: "도구 설치" +description: 컴퓨터에서 쿠버네티스 도구를 설정한다. weight: 10 --- diff --git a/content/ko/docs/tasks/tools/install-kubectl.md b/content/ko/docs/tasks/tools/install-kubectl.md index 4b498f27ef..e4c8011614 100644 --- a/content/ko/docs/tasks/tools/install-kubectl.md +++ b/content/ko/docs/tasks/tools/install-kubectl.md @@ -111,34 +111,34 @@ kubectl version --client 1. 최신 릴리스를 다운로드한다. - ``` - curl -LO "https://storage.googleapis.com/kubernetes-release/release/$(curl -s https://storage.googleapis.com/kubernetes-release/release/stable.txt)/bin/darwin/amd64/kubectl" + ```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 -s https://storage.googleapis.com/kubernetes-release/release/stable.txt)` 명령 부분을 특정 버전으로 바꾼다. + + 예를 들어, macOS에서 버전 {{< param "fullversion" >}}을 다운로드하려면, 다음을 입력한다. + ```bash + curl -LO https://storage.googleapis.com/kubernetes-release/release/{{< param "fullversion" >}}/bin/darwin/amd64/kubectl ``` - 특정 버전을 다운로드하려면, `$(curl -s https://storage.googleapis.com/kubernetes-release/release/stable.txt)` 명령 부분을 특정 버전으로 바꾼다. + kubectl 바이너리를 실행 가능하게 만든다. - 예를 들어, macOS에서 버전 {{< param "fullversion" >}}을 다운로드하려면, 다음을 입력한다. - ``` - curl -LO https://storage.googleapis.com/kubernetes-release/release/{{< param "fullversion" >}}/bin/darwin/amd64/kubectl - ``` - -2. kubectl 바이너리를 실행 가능하게 만든다. - - ``` - chmod +x ./kubectl - ``` + ```bash + chmod +x ./kubectl + ``` 3. 바이너리를 PATH가 설정된 디렉터리로 옮긴다. - ``` - sudo mv ./kubectl /usr/local/bin/kubectl - ``` + ```bash + sudo mv ./kubectl /usr/local/bin/kubectl + ``` 4. 설치한 버전이 최신 버전인지 확인한다. - ``` - kubectl version --client - ``` + ```bash + kubectl version --client + ``` ### macOS에서 Homebrew를 사용하여 설치 @@ -146,21 +146,21 @@ macOS에서 [Homebrew](https://brew.sh/) 패키지 관리자를 사용하는 경 1. 설치 명령을 실행한다. - ``` - brew install kubectl - ``` + ```bash + brew install kubectl + ``` - 또는 + 또는 - ``` - brew install kubernetes-cli - ``` + ```bash + brew install kubernetes-cli + ``` 2. 설치한 버전이 최신 버전인지 확인한다. - ``` - kubectl version --client - ``` + ```bash + kubectl version --client + ``` ### macOS에서 Macports를 사용하여 설치 @@ -168,117 +168,123 @@ macOS에서 [Macports](https://macports.org/) 패키지 관리자를 사용하 1. 설치 명령을 실행한다. - ``` - sudo port selfupdate - sudo port install kubectl - ``` + ```bash + sudo port selfupdate + sudo port install kubectl + ``` 2. 설치한 버전이 최신 버전인지 확인한다. - ``` - kubectl version --client - ``` + ```bash + kubectl version --client + ``` -## Windows에 kubectl 설치 +## 윈도우에 kubectl 설치 -### Windows에서 curl을 사용하여 kubectl 바이너리 설치 +### 윈도우에서 curl을 사용하여 kubectl 바이너리 설치 1. [이 링크](https://storage.googleapis.com/kubernetes-release/release/{{< param "fullversion" >}}/bin/windows/amd64/kubectl.exe)에서 최신 릴리스 {{< param "fullversion" >}}을 다운로드한다. - 또는 `curl` 을 설치한 경우, 다음 명령을 사용한다. + 또는 `curl` 을 설치한 경우, 다음 명령을 사용한다. - ``` - curl -LO https://storage.googleapis.com/kubernetes-release/release/{{< param "fullversion" >}}/bin/windows/amd64/kubectl.exe - ``` + ```bash + curl -LO https://storage.googleapis.com/kubernetes-release/release/{{< param "fullversion" >}}/bin/windows/amd64/kubectl.exe + ``` - 최신의 안정 버전(예: 스크립팅을 위한)을 찾으려면, [https://storage.googleapis.com/kubernetes-release/release/stable.txt](https://storage.googleapis.com/kubernetes-release/release/stable.txt)를 참고한다. + 최신의 안정 버전(예: 스크립팅을 위한)을 찾으려면, [https://storage.googleapis.com/kubernetes-release/release/stable.txt](https://storage.googleapis.com/kubernetes-release/release/stable.txt)를 참고한다. 2. 바이너리를 PATH가 설정된 디렉터리에 추가한다. 3. `kubectl` 의 버전이 다운로드한 버전과 같은지 확인한다. - ``` - kubectl version --client - ``` + ```bash + kubectl version --client + ``` {{< note >}} -[Windows용 도커 데스크톱](https://docs.docker.com/docker-for-windows/#kubernetes)은 자체 버전의 `kubectl` 을 PATH에 추가한다. +[윈도우용 도커 데스크톱](https://docs.docker.com/docker-for-windows/#kubernetes)은 자체 버전의 `kubectl` 을 PATH에 추가한다. 도커 데스크톱을 이전에 설치한 경우, 도커 데스크톱 설치 프로그램에서 추가한 PATH 항목 앞에 PATH 항목을 배치하거나 도커 데스크톱의 `kubectl` 을 제거해야 할 수도 있다. {{< /note >}} ### PSGallery에서 Powershell로 설치 -Windows에서 [Powershell Gallery](https://www.powershellgallery.com/) 패키지 관리자를 사용하는 경우, Powershell로 kubectl을 설치하고 업데이트할 수 있다. +윈도우에서 [Powershell Gallery](https://www.powershellgallery.com/) 패키지 관리자를 사용하는 경우, Powershell로 kubectl을 설치하고 업데이트할 수 있다. 1. 설치 명령을 실행한다(`DownloadLocation` 을 지정해야 한다). - ``` - Install-Script -Name install-kubectl -Scope CurrentUser -Force - install-kubectl.ps1 [-DownloadLocation <path>] - ``` + ```powershell + Install-Script -Name install-kubectl -Scope CurrentUser -Force + install-kubectl.ps1 [-DownloadLocation <path>] + ``` -{{< note >}}`DownloadLocation` 을 지정하지 않으면, `kubectl` 은 사용자의 임시 디렉터리에 설치된다.{{< /note >}} + {{< note >}} + `DownloadLocation` 을 지정하지 않으면, `kubectl` 은 사용자의 임시 디렉터리에 설치된다. + {{< /note >}} 설치 프로그램은 `$HOME/.kube` 를 생성하고 구성 파일을 작성하도록 지시한다. 2. 설치한 버전이 최신 버전인지 확인한다. - ``` - kubectl version --client - ``` + ```powershell + kubectl version --client + ``` {{< note >}} 설치 업데이트는 1 단계에서 나열한 두 명령을 다시 실행하여 수행한다. {{< /note >}} -### Chocolatey 또는 Scoop을 사용하여 Windows에 설치 +### Chocolatey 또는 Scoop을 사용하여 윈도우에 설치 -1. Windows에 kubectl을 설치하기 위해서 [Chocolatey](https://chocolatey.org) 패키지 관리자나 [Scoop](https://scoop.sh) 커맨드 라인 설치 프로그램을 사용할 수 있다. - -{{< tabs name="kubectl_win_install" >}} -{{% tab name="choco" %}} +1. 윈도우에 kubectl을 설치하기 위해서 [Chocolatey](https://chocolatey.org) 패키지 관리자나 [Scoop](https://scoop.sh) 커맨드 라인 설치 프로그램을 사용할 수 있다. + {{< tabs name="kubectl_win_install" >}} + {{% tab name="choco" %}} + ```powershell choco install kubernetes-cli - -{{% /tab %}} -{{% tab name="scoop" %}} - + ``` + {{% /tab %}} + {{% tab name="scoop" %}} + ```powershell scoop install kubectl - -{{% /tab %}} -{{< /tabs >}} + ``` + {{% /tab %}} + {{< /tabs >}} 2. 설치한 버전이 최신 버전인지 확인한다. - ``` - kubectl version --client - ``` + ```powershell + kubectl version --client + ``` -3. 홈 디렉토리로 이동한다. +3. 홈 디렉터리로 이동한다. + + ```powershell + # cmd.exe를 사용한다면, 다음을 실행한다. cd %USERPROFILE% + cd ~ + ``` - ``` - cd %USERPROFILE% - ``` 4. `.kube` 디렉터리를 생성한다. - ``` - mkdir .kube - ``` + ```powershell + mkdir .kube + ``` 5. 금방 생성한 `.kube` 디렉터리로 이동한다. - ``` - cd .kube - ``` + ```powershell + cd .kube + ``` 6. 원격 쿠버네티스 클러스터를 사용하도록 kubectl을 구성한다. - ``` - New-Item config -type file - ``` + ```powershell + New-Item config -type file + ``` -{{< note >}}메모장과 같은 텍스트 편집기를 선택하여 구성 파일을 편집한다.{{< /note >}} +{{< note >}} +메모장과 같은 텍스트 편집기를 선택하여 구성 파일을 편집한다. +{{< /note >}} ## Google Cloud SDK의 일부로 다운로드 @@ -288,15 +294,15 @@ kubectl을 Google Cloud SDK의 일부로 설치할 수 있다. 2. `kubectl` 설치 명령을 실행한다. - ``` - gcloud components install kubectl - ``` + ```shell + gcloud components install kubectl + ``` 3. 설치한 버전이 최신 버전인지 확인한다. - ``` - kubectl version --client - ``` + ```shell + kubectl version --client + ``` ## kubectl 구성 확인 @@ -312,7 +318,7 @@ URL 응답이 표시되면, kubectl이 클러스터에 접근하도록 올바르 다음과 비슷한 메시지가 표시되면, kubectl이 올바르게 구성되지 않았거나 쿠버네티스 클러스터에 연결할 수 없다. -```shell +``` The connection to the server <server-name:port> was refused - did you specify the right host or port? ``` @@ -350,7 +356,7 @@ bash-completion은 많은 패키지 관리자에 의해 제공된다([여기](ht 확인하려면, 셸을 다시 로드하고 `type _init_completion` 을 실행한다. 명령이 성공하면, 이미 설정된 상태이고, 그렇지 않으면 `~/.bashrc` 파일에 다음을 추가한다. -```shell +```bash source /usr/share/bash-completion/bash_completion ``` @@ -362,17 +368,17 @@ source /usr/share/bash-completion/bash_completion - `~/.bashrc` 파일에서 완성 스크립트를 소싱한다. - ```shell - echo 'source <(kubectl completion bash)' >>~/.bashrc - ``` + ```bash + echo 'source <(kubectl completion bash)' >>~/.bashrc + ``` - 완성 스크립트를 `/etc/bash_completion.d` 디렉터리에 추가한다. - ```shell - kubectl completion bash >/etc/bash_completion.d/kubectl - ``` + ```bash + kubectl completion bash >/etc/bash_completion.d/kubectl + ``` kubectl에 대한 앨리어스(alias)가 있는 경우, 해당 앨리어스로 작업하도록 셸 완성을 확장할 수 있다. -```shell +```bash echo 'alias k=kubectl' >>~/.bashrc echo 'complete -F __start_kubectl k' >>~/.bashrc ``` @@ -403,19 +409,19 @@ bash-completion에는 v1과 v2 두 가지 버전이 있다. v1은 Bash 3.2(macOS 여기의 지침에서는 Bash 4.1 이상을 사용한다고 가정한다. 다음을 실행하여 Bash 버전을 확인할 수 있다. -```shell +```bash echo $BASH_VERSION ``` 너무 오래된 버전인 경우, Homebrew를 사용하여 설치/업그레이드할 수 있다. -```shell +```bash brew install bash ``` 셸을 다시 로드하고 원하는 버전을 사용 중인지 확인한다. -```shell +```bash echo $BASH_VERSION $SHELL ``` @@ -429,13 +435,13 @@ Homebrew는 보통 `/usr/local/bin/bash` 에 설치한다. bash-completion v2가 이미 설치되어 있는지 `type_init_completion` 으로 확인할 수 있다. 그렇지 않은 경우, Homebrew로 설치할 수 있다. -```shell +```bash brew install bash-completion@2 ``` 이 명령의 출력에 명시된 바와 같이, `~/.bash_profile` 파일에 다음을 추가한다. -```shell +```bash export BASH_COMPLETION_COMPAT_DIR="/usr/local/etc/bash_completion.d" [[ -r "/usr/local/etc/profile.d/bash_completion.sh" ]] && . "/usr/local/etc/profile.d/bash_completion.sh" ``` @@ -448,29 +454,29 @@ export BASH_COMPLETION_COMPAT_DIR="/usr/local/etc/bash_completion.d" - 완성 스크립트를 `~/.bash_profile` 파일에서 소싱한다. - ```shell + ```bash echo 'source <(kubectl completion bash)' >>~/.bash_profile ``` - 완성 스크립트를 `/usr/local/etc/bash_completion.d` 디렉터리에 추가한다. - ```shell + ```bash kubectl completion bash >/usr/local/etc/bash_completion.d/kubectl ``` - kubectl에 대한 앨리어스가 있는 경우, 해당 앨리어스로 작업하기 위해 셸 완성을 확장할 수 있다. - ```shell + ```bash echo 'alias k=kubectl' >>~/.bash_profile echo 'complete -F __start_kubectl k' >>~/.bash_profile ``` - Homebrew로 kubectl을 설치한 경우([위](#macos에서-homebrew를-사용하여-설치)의 설명을 참고), kubectl 완성 스크립트는 이미 `/usr/local/etc/bash_completion.d/kubectl` 에 있어야 한다. 이 경우, 아무 것도 할 필요가 없다. - {{< note >}} - bash-completion v2의 Homebrew 설치는 `BASH_COMPLETION_COMPAT_DIR` 디렉터리의 모든 파일을 소싱하므로, 후자의 두 가지 방법이 적용된다. - {{< /note >}} + {{< note >}} + bash-completion v2의 Homebrew 설치는 `BASH_COMPLETION_COMPAT_DIR` 디렉터리의 모든 파일을 소싱하므로, 후자의 두 가지 방법이 적용된다. + {{< /note >}} 어쨌든, 셸을 다시 로드 한 후에, kubectl 완성이 작동해야 한다. {{% /tab %}} @@ -481,13 +487,13 @@ Zsh용 kubectl 완성 스크립트는 `kubectl completion zsh` 명령으로 생 모든 셸 세션에서 사용하려면, `~/.zshrc` 파일에 다음을 추가한다. -```shell +```zsh source <(kubectl completion zsh) ``` kubectl에 대한 앨리어스가 있는 경우, 해당 앨리어스로 작업하도록 셸 완성을 확장할 수 있다. -```shell +```zsh echo 'alias k=kubectl' >>~/.zshrc echo 'complete -F __start_kubectl k' >>~/.zshrc ``` @@ -496,16 +502,13 @@ echo 'complete -F __start_kubectl k' >>~/.zshrc `complete:13: command not found: compdef` 와 같은 오류가 발생하면, `~/.zshrc` 파일의 시작 부분에 다음을 추가한다. -```shell +```zsh autoload -Uz compinit compinit ``` {{% /tab %}} {{< /tabs >}} - - - ## {{% heading "whatsnext" %}} * [Minikube 설치](/ko/docs/tasks/tools/install-minikube/) @@ -513,4 +516,3 @@ compinit * [애플리케이션을 시작하고 노출하는 방법에 대해 배운다.](/docs/tasks/access-application-cluster/service-access-application-cluster/) * 직접 생성하지 않은 클러스터에 접근해야하는 경우, [클러스터 접근 공유 문서](/ko/docs/tasks/access-application-cluster/configure-access-multiple-clusters/)를 참고한다. * [kubectl 레퍼런스 문서](/docs/reference/kubectl/kubectl/) 읽기 - diff --git a/content/ko/docs/tasks/tools/install-minikube.md b/content/ko/docs/tasks/tools/install-minikube.md index 386d606769..04c4ca64a6 100644 --- a/content/ko/docs/tasks/tools/install-minikube.md +++ b/content/ko/docs/tasks/tools/install-minikube.md @@ -65,7 +65,7 @@ Hyper-V Requirements: A hypervisor has been detected. Features required for ### kubectl 설치 -kubectl이 설치되었는지 확인한다. kubectl은 [kubectl 설치하고 설정하기](/docs/tasks/tools/install-kubectl/#install-kubectl-on-linux)의 요령을 따라서 설치할 수 있다. +kubectl이 설치되었는지 확인한다. kubectl은 [kubectl 설치하고 설정하기](/ko/docs/tasks/tools/install-kubectl/#리눅스에-kubectl-설치)의 요령을 따라서 설치할 수 있다. ## 하이퍼바이저(hypervisor) 설치 @@ -76,7 +76,7 @@ kubectl이 설치되었는지 확인한다. kubectl은 [kubectl 설치하고 설 • [VirtualBox](https://www.virtualbox.org/wiki/Downloads) Minikube는 쿠버네티스 컴포넌트를 VM이 아닌 호스트에서도 동작하도록 `--driver=none` 옵션도 지원한다. -이 드라이버를 사용하려면 [도커](https://www.docker.com/products/docker-desktop) 와 Linux 환경이 필요하지만, 하이퍼바이저는 필요하지 않다. +이 드라이버를 사용하려면 [도커](https://www.docker.com/products/docker-desktop)와 리눅스 환경이 필요하지만, 하이퍼바이저는 필요하지 않다. 데비안(Debian) 또는 파생된 배포판에서 `none` 드라이버를 사용하는 경우, Minikube에서는 동작하지 않는 스냅 패키지 대신 도커용 `.deb` 패키지를 사용한다. @@ -119,7 +119,7 @@ sudo install minikube /usr/local/bin/ ### Homebrew를 이용해서 Minikube 설치하기 -또 다른 대안으로 Linux [Homebrew](https://docs.brew.sh/Homebrew-on-Linux)를 이용해서 Minikube를 설치할 수 있다. +또 다른 대안으로 리눅스 [Homebrew](https://docs.brew.sh/Homebrew-on-Linux)를 이용해서 Minikube를 설치할 수 있다. ```shell brew install minikube @@ -129,7 +129,7 @@ brew install minikube {{% tab name="맥OS" %}} ### kubectl 설치 -kubectl이 설치되었는지 확인한다. kubectl은 [kubectl 설치하고 설정하기](/docs/tasks/tools/install-kubectl/#install-kubectl-on-macos)의 요령을 따라서 설치할 수 있다. +kubectl이 설치되었는지 확인한다. kubectl은 [kubectl 설치하고 설정하기](/ko/docs/tasks/tools/install-kubectl/#macos에-kubectl-설치)의 요령을 따라서 설치할 수 있다. ### 하이퍼바이저(hypervisor) 설치 @@ -162,10 +162,10 @@ sudo mv minikube /usr/local/bin ``` {{% /tab %}} -{{% tab name="Windows" %}} +{{% tab name="윈도우" %}} ### kubectl 설치하기 -kubectl이 설치되었는지 확인한다. kubectl은 [kubectl 설치하고 설정하기](/docs/tasks/tools/install-kubectl/#install-kubectl-on-windows)의 요령을 따라서 설치할 수 있다. +kubectl이 설치되었는지 확인한다. kubectl은 [kubectl 설치하고 설정하기](/ko/docs/tasks/tools/install-kubectl/#windows에-kubectl-설치)의 요령을 따라서 설치할 수 있다. ### 하이퍼바이저(hypervisor) 설치하기 @@ -200,17 +200,20 @@ Minikube 설치를 마친 후, 현재 CLI 세션을 닫고 재시작한다. Mini {{% /tab %}} {{< /tabs >}} - ## 설치 확인 하이퍼바이저와 Minikube의 성공적인 설치를 확인하려면, 다음 명령어를 실행해서 로컬 쿠버네티스 클러스터를 시작할 수 있다. {{< note >}} -`minikube start` 시 `--driver` 를 설정하려면, 아래에 `<driver_name>` 로 소문자로 언급된 곳에 설치된 하이퍼바이저의 이름을 입력한다. `--driver` 값의 전체 목록은 [VM driver 문서에서 지정하기](https://kubernetes.io/docs/setup/learning-environment/minikube/#specifying-the-vm-driver)에서 확인할 수 있다. +`minikube start` 시 `--driver` 를 설정하려면, 아래에 `<driver_name>` 로 소문자로 언급된 곳에 설치된 하이퍼바이저의 이름을 입력한다. `--driver` 값의 전체 목록은 [VM driver 지정하기 문서](/ko/docs/setup/learning-environment/minikube/#vm-드라이버-지정하기)에서 확인할 수 있다. {{< /note >}} +{{< caution >}} +KVM을 사용할 때 Debian과 다른 시스템에서 libvirt의 기본 QEMU URI는 `qemu:///session`이고, Minikube의 기본 QEMU URI는 `qemu:///system`이다. 시스템이 이런 환경이라면, `--kvm-qemu-uri qemu:///session`을 `minikube start`에 전달해야 한다. +{{< /caution >}} + ```shell minikube start --driver=<driver_name> ``` @@ -256,4 +259,4 @@ minikube delete ## {{% heading "whatsnext" %}} -* [Minikube로 로컬에서 쿠버네티스 실행하기](/docs/setup/minikube/) +* [Minikube로 로컬에서 쿠버네티스 실행하기](/ko/docs/setup/learning-environment/minikube/) diff --git a/content/ko/docs/tutorials/_index.md b/content/ko/docs/tutorials/_index.md index 7a3ca934e0..a0dfb80ca1 100644 --- a/content/ko/docs/tutorials/_index.md +++ b/content/ko/docs/tutorials/_index.md @@ -1,6 +1,7 @@ --- title: 튜토리얼 main_menu: true +no_list: true weight: 60 content_type: concept --- @@ -14,8 +15,6 @@ content_type: concept 각 튜토리얼을 따라하기 전에, 나중에 참조할 수 있도록 [표준 용어집](/ko/docs/reference/glossary/) 페이지를 북마크하기를 권한다. - - <!-- body --> ## 기초 @@ -64,14 +63,8 @@ content_type: concept * [소스 IP 주소 이용하기](/ko/docs/tutorials/services/source-ip/) - - ## {{% heading "whatsnext" %}} - -튜토리얼을 작성하고 싶다면, -튜토리얼 페이지 유형과 튜토리얼 템플릿에 대한 정보가 있는 -[Using Page Templates](/docs/home/contribute/page-templates/) +튜토리얼을 작성하고 싶다면, 튜토리얼 페이지 유형에 대한 정보가 있는 +[콘텐츠 페이지 유형](/docs/contribute/style/page-content-types/) 페이지를 참조한다. - - diff --git a/content/ko/docs/tutorials/clusters/apparmor.md b/content/ko/docs/tutorials/clusters/apparmor.md index a168b521e1..803b58594c 100644 --- a/content/ko/docs/tutorials/clusters/apparmor.md +++ b/content/ko/docs/tutorials/clusters/apparmor.md @@ -1,9 +1,10 @@ --- -reviewers: title: AppArmor content_type: tutorial --- + + <!-- overview --> {{< feature-state for_k8s_version="v1.4" state="beta" >}} @@ -13,7 +14,7 @@ AppArmor는 표준 리눅스 사용자와 그룹 기반의 권한을 보완하 프로그램을 제한하는 리눅스 커널 보안 모듈이다. AppArmor는 임의의 애플리케이션에 대해서 잠재적인 공격 범위를 줄이고 더욱 심층적인 방어를 제공하도록 구성할 수 있다. 이 기능은 특정 프로그램이나 컨테이너에서 필요한 리눅스 기능, 네트워크 사용, 파일 권한 등에 대한 -접근 허용 목록 조정한 프로파일로 구성한다. 각 프로파일은 +접근을 허용하는 프로파일로 구성한다. 각 프로파일은 허용하지 않은 리소스 접근을 차단하는 *강제(enforcing)* 모드 또는 위반만을 보고하는 *불평(complain)* 모드로 실행할 수 있다. @@ -29,7 +30,7 @@ AppArmor를 이용하면 컨테이너가 수행할 수 있는 작업을 제한 * 노드에 프로파일을 어떻게 적재하는지 예시를 본다. -* 파드(Pod)에 프로파일을 어떻게 강제 적용하는지 배운다. +* 파드에 프로파일을 어떻게 강제 적용하는지 배운다. * 프로파일이 적재되었는지 확인하는 방법을 배운다. * 프로파일을 위반하는 경우를 살펴본다. * 프로파일을 적재할 수 없을 경우를 살펴본다. diff --git a/content/ko/docs/tutorials/configuration/configure-redis-using-configmap.md b/content/ko/docs/tutorials/configuration/configure-redis-using-configmap.md index 340ea6431f..bb28639e83 100644 --- a/content/ko/docs/tutorials/configuration/configure-redis-using-configmap.md +++ b/content/ko/docs/tutorials/configuration/configure-redis-using-configmap.md @@ -15,7 +15,7 @@ content_type: tutorial * 다음을 포함하는 `kustomization.yaml` 파일을 생성한다. * 컨피그 맵 생성자 * 컨피그 맵을 사용하는 파드 리소스 -* `kubectl apply -k ./`를 실행하여 작업한 디렉토리를 적용한다. +* `kubectl apply -k ./`를 실행하여 작업한 디렉터리를 적용한다. * 구성이 잘 적용되었는지 확인한다. @@ -65,7 +65,7 @@ resources: EOF ``` -컨피그 맵과 파드 개체를 생성하도록 kustomization 디렉토리를 적용한다. +컨피그 맵과 파드 개체를 생성하도록 kustomization 디렉터리를 적용한다. ```shell kubectl apply -k . @@ -90,7 +90,7 @@ pod/redis 1/1 Running 0 52s `kubectl exec`를 사용해 파드 속에서 `redis-cli` 툴을 실행해 본다. ```shell -kubectl exec -it redis redis-cli +kubectl exec -it redis -- redis-cli 127.0.0.1:6379> CONFIG GET maxmemory 1) "maxmemory" 2) "2097152" diff --git a/content/ko/docs/tutorials/hello-minikube.md b/content/ko/docs/tutorials/hello-minikube.md index d579a7b7d6..9d71638252 100644 --- a/content/ko/docs/tutorials/hello-minikube.md +++ b/content/ko/docs/tutorials/hello-minikube.md @@ -97,6 +97,7 @@ Katacode는 무료로 브라우저에서 쿠버네티스 환경을 제공한다. ```shell kubectl get pods ``` + 다음과 유사하게 출력된다. ``` @@ -117,7 +118,7 @@ Katacode는 무료로 브라우저에서 쿠버네티스 환경을 제공한다. ``` {{< note >}} - `kubectl` 명령어에 관해 자세히 알기 원하면 [kubectl 개요](/docs/user-guide/kubectl-overview/)을 살펴보자. + `kubectl` 명령어에 관해 자세히 알기 원하면 [kubectl 개요](/ko/docs/reference/kubectl/overview/)을 살펴보자. {{< /note >}} ## 서비스 만들기 diff --git a/content/ko/docs/tutorials/kubernetes-basics/expose/expose-intro.html b/content/ko/docs/tutorials/kubernetes-basics/expose/expose-intro.html index aed0258cf6..6726fdd6e0 100644 --- a/content/ko/docs/tutorials/kubernetes-basics/expose/expose-intro.html +++ b/content/ko/docs/tutorials/kubernetes-basics/expose/expose-intro.html @@ -28,7 +28,7 @@ weight: 10 <div class="col-md-8"> <h3>쿠버네티스 서비스들에 대한 개요</h3> - <p>쿠버네티스 <a href="/ko/docs/concepts/workloads/pods/pod-overview/">파드들</a> 은 언젠가는 죽게된다. 실제 파드들은 <a href="/ko/docs/concepts/workloads/pods/pod-lifecycle/">생명주기</a>를 갖는다. 워커 노드가 죽으면, 노드 상에서 동작하는 파드들 또한 종료된다. <a href="/ko/docs/concepts/workloads/controllers/replicaset/">레플리카 셋</a>은 여러분의 애플리케이션이 지속적으로 동작할 수 있도록 새로운 파드들의 생성을 통해 동적으로 클러스터를 미리 지정해 둔 상태로 되돌려 줄 수도 있다. 또 다른 예시로서, 3개의 복제본을 갖는 이미지 처리용 백엔드를 고려해 보자. 그 복제본들은 교체 가능한 상태이다. 그래서 프론트엔드 시스템은 하나의 파드가 소멸되어 재생성이 되더라도, 백엔드 복제본들에 의한 영향을 받아서는 안된다. 즉, 동일 노드 상의 파드들이라 할지라도, 쿠버네티스 클러스터 내 각 파드는 유일한 IP 주소를 가지며, 여러분의 애플리케이션들이 지속적으로 기능할 수 있도록 파드들 속에서 발생하는 변화에 대해 자동으로 조정해 줄 방법이 있어야 한다.</p> + <p>쿠버네티스 <a href="/ko/docs/concepts/workloads/pods/pod-overview/">파드들</a> 은 언젠가는 죽게된다. 실제 파드들은 <a href="/ko/docs/concepts/workloads/pods/pod-lifecycle/">생명주기</a>를 갖는다. 워커 노드가 죽으면, 노드 상에서 동작하는 파드들 또한 종료된다. <a href="/ko/docs/concepts/workloads/controllers/replicaset/">레플리카셋(ReplicaSet)</a>은 여러분의 애플리케이션이 지속적으로 동작할 수 있도록 새로운 파드들의 생성을 통해 동적으로 클러스터를 미리 지정해 둔 상태로 되돌려 줄 수도 있다. 또 다른 예시로서, 3개의 복제본을 갖는 이미지 처리용 백엔드를 고려해 보자. 그 복제본들은 교체 가능한 상태이다. 그래서 프론트엔드 시스템은 하나의 파드가 소멸되어 재생성이 되더라도, 백엔드 복제본들에 의한 영향을 받아서는 안된다. 즉, 동일 노드 상의 파드들이라 할지라도, 쿠버네티스 클러스터 내 각 파드는 유일한 IP 주소를 가지며, 여러분의 애플리케이션들이 지속적으로 기능할 수 있도록 파드들 속에서 발생하는 변화에 대해 자동으로 조정해 줄 방법이 있어야 한다.</p> <p>쿠버네티스에서 서비스는 하나의 논리적인 파드 셋과 그 파드들에 접근할 수 있는 정책을 정의하는 추상적 개념이다. 서비스는 종속적인 파드들 사이를 느슨하게 결합되도록 해준다. 서비스는 모든 쿠버네티스 오브젝트들과 같이 YAML <a href="/ko/docs/concepts/configuration/overview/#일반적인-구성-팁">(보다 선호하는)</a> 또는 JSON을 이용하여 정의된다. 서비스가 대상으로 하는 파드 셋은 보통 <i>LabelSelector</i>에 의해 결정된다 (여러분이 왜 스펙에 <code>selector</code>가 포함되지 않은 서비스를 필요로 하게 될 수도 있는지에 대해 아래에서 확인해 보자).</p> @@ -80,7 +80,7 @@ weight: 10 <li>태그들을 이용하는 객체들에 대한 분류</li> </ul> </div> - + </div> <br> diff --git a/content/ko/docs/tutorials/kubernetes-basics/scale/scale-intro.html b/content/ko/docs/tutorials/kubernetes-basics/scale/scale-intro.html index e411c4f8ab..9790c1f31e 100644 --- a/content/ko/docs/tutorials/kubernetes-basics/scale/scale-intro.html +++ b/content/ko/docs/tutorials/kubernetes-basics/scale/scale-intro.html @@ -30,7 +30,7 @@ weight: 10 <p>지난 모듈에서 <a href="/ko/docs/concepts/workloads/controllers/deployment/"> 디플로이먼트</a>를 만들고, <a href="/docs/concepts/services-networking/service/">서비스</a>를 통해서 디플로이먼트를 외부에 노출시켜 봤다. 해당 디플로이먼트는 애플리케이션을 구동하기 위해 단 - 하나의 파드(Pod)만을 생성했었다. 트래픽이 증가하면, 사용자 요청에 맞추어 애플리케이션의 규모를 + 하나의 파드만을 생성했었다. 트래픽이 증가하면, 사용자 요청에 맞추어 애플리케이션의 규모를 조정할 필요가 있다.</p> <p>디플로이먼트의 복제 수를 변경하면 <b>스케일링</b>이 수행된다</p> @@ -44,7 +44,7 @@ weight: 10 </ul> </div> <div class="content__box content__box_fill"> - <p><i> kubectl run 명령에 --replicas 파라미터를 사용해서 처음부터 복수의 인스턴스로 구동되는 + <p><i> kubectl create deployment 명령에 --replicas 파라미터를 사용해서 처음부터 복수의 인스턴스로 구동되는 디플로이먼트를 만들 수도 있다 </i></p> </div> </div> diff --git a/content/ko/docs/tutorials/services/source-ip.md b/content/ko/docs/tutorials/services/source-ip.md index 4917fa5042..ae9e5abf03 100644 --- a/content/ko/docs/tutorials/services/source-ip.md +++ b/content/ko/docs/tutorials/services/source-ip.md @@ -226,7 +226,7 @@ client_address=10.240.0.3 다른 노드로 트래픽 전달하지 않는다. 이 방법은 원본 소스 IP 주소를 보존한다. 만약 로컬 엔드 포인트가 없다면, 그 노드로 보내진 패킷은 버려지므로 -패킷 처리 규칙에서 정확한 소스 IP 임을 신뢰할 수 있으므로, +패킷 처리 규칙에서 정확한 소스 IP 임을 신뢰할 수 있으므로, 패킷을 엔드포인트까지 전달할 수 있다. 다음과 같이 `service.spec.externalTrafficPolicy` 필드를 설정하자. @@ -249,7 +249,7 @@ for node in $NODES; do curl --connect-timeout 1 -s $node:$NODEPORT | grep -i cli client_address=104.132.1.79 ``` -엔드포인트 파드가 실행 중인 노드에서 *올바른* 클라이언트 IP 주소인 +엔드포인트 파드가 실행 중인 노드에서 *올바른* 클라이언트 IP 주소인 딱 한 종류의 응답만 수신한다. 어떻게 이렇게 되었는가: @@ -319,7 +319,7 @@ client_address=10.240.0.5 그러나 구글 클라우드 엔진/GCE 에서 실행 중이라면 동일한 `service.spec.externalTrafficPolicy` 필드를 `Local`로 설정하면 서비스 엔드포인트가 *없는* 노드는 고의로 헬스 체크에 실패하여 -강제로 로드밸런싱 트래픽을 받을 수 있는 노드 목록에서 +강제로 로드밸런싱 트래픽을 받을 수 있는 노드 목록에서 자신을 스스로 제거한다. 시각적으로: @@ -447,6 +447,4 @@ kubectl delete deployment source-ip-app ## {{% heading "whatsnext" %}} * [서비스를 통한 애플리케이션 연결하기](/ko/docs/concepts/services-networking/connect-applications-service/)에 더 자세히 본다. -* 어떻게 [외부 로드밸런서 생성](https://kubernetes.io/docs/tasks/access-application-cluster/create-external-load-balancer/)하는지 본다. - - +* 어떻게 [외부 로드밸런서 생성](/docs/tasks/access-application-cluster/create-external-load-balancer/)하는지 본다. diff --git a/content/ko/docs/tutorials/stateful-application/basic-stateful-set.md b/content/ko/docs/tutorials/stateful-application/basic-stateful-set.md index 10e7aa7683..c7d57d8633 100644 --- a/content/ko/docs/tutorials/stateful-application/basic-stateful-set.md +++ b/content/ko/docs/tutorials/stateful-application/basic-stateful-set.md @@ -6,9 +6,9 @@ weight: 10 --- <!-- overview --> -이 튜토리얼은 스테이트풀셋([StatefulSets](/ko/docs/concepts/workloads/controllers/statefulset/))을 이용하여 -애플리케이션을 관리하는 방법을 소개한다. 어떻게 스테이트풀셋의 파드(Pod)을 생성하고 삭제하며 -스케일링하고 업데이트하는지 시연한다. +이 튜토리얼은 {{< glossary_tooltip text="스테이트풀셋(StatefulSet)" term_id="statefulset" >}}을 이용하여 +애플리케이션을 관리하는 방법을 소개한다. +어떻게 스테이트풀셋의 파드를 생성하고, 삭제하며, 스케일링하고, 업데이트하는지 시연한다. ## {{% heading "prerequisites" %}} @@ -22,13 +22,14 @@ weight: 10 * [퍼시스턴트볼륨(PersistentVolumes)](/ko/docs/concepts/storage/persistent-volumes/) * [퍼시턴트볼륨 프로비저닝](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/staging/persistent-volume-provisioning/) * [스테이트풀셋](/ko/docs/concepts/workloads/controllers/statefulset/) -* [kubectl CLI](/docs/user-guide/kubectl/) +* [kubectl](/docs/reference/kubectl/kubectl/) 커맨드 라인 도구 +{{< note >}} 이 튜토리얼은 클러스터가 퍼시스턴스볼륨을 동적으로 프로비저닝 하도록 설정되었다고 가정한다. 만약 클러스터가 이렇게 설정되어 있지 않다면, 튜토리얼 시작 전에 수동으로 2개의 1 GiB 볼륨을 프로비저닝해야 한다. - +{{< /note >}} ## {{% heading "objectives" %}} @@ -46,7 +47,6 @@ weight: 10 * 스테이트풀셋은 어떻게 스케일링하는지 * 스테이트풀셋의 파드는 어떻게 업데이트하는지 - <!-- lessoncontent --> ## 스테이트풀셋 생성하기 @@ -74,20 +74,24 @@ kubectl get pods -w -l app=nginx ```shell kubectl apply -f web.yaml +``` +``` service/nginx created statefulset.apps/web created ``` 상기 명령어는 [NGINX](https://www.nginx.com) 웹 서버를 -실행하는 2개의 파드를 생성한다. `nginx` 서비스와 -`web` 스테이트풀셋이 성공적으로 생성되었는지 알아보자. +실행하는 2개의 파드를 생성한다. `nginx` 서비스의 정보를 가져온다. ```shell kubectl get service nginx NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE nginx ClusterIP None <none> 80/TCP 12s - +``` +그리고 `web` 스테이트풀셋 정보를 가져와서 모두 성공적으로 생성되었는지 확인한다. +```shell kubectl get statefulset web +``` NAME DESIRED CURRENT AGE web 2 1 20s ``` @@ -101,6 +105,8 @@ N개의 레플리카를 가진 스테이트풀셋은 배포 시에 ```shell kubectl get pods -w -l app=nginx +``` +``` NAME READY STATUS RESTARTS AGE web-0 0/1 Pending 0 0s web-0 0/1 Pending 0 0s @@ -112,8 +118,8 @@ web-1 0/1 ContainerCreating 0 0s web-1 1/1 Running 0 18s ``` -`web-1` 파드는 `web-0` 파드가 [Running과 Ready](/ko/docs/concepts/workloads/pods/pod-lifecycle/) 상태가 되기 전에 -시작하지 않음을 주의하자. +참고로 `web-1` 파드는 `web-0` 파드가 _Running_ ([파드의 단계](/ko/docs/concepts/workloads/pods/pod-lifecycle/#파드의-단계-phase) 참고) +및 _Ready_ ([파드의 조건](/ko/docs/concepts/workloads/pods/pod-lifecycle/#파드의-조건-condition)에서 `type` 참고) 상태가 되기 전에 시작하지 않음을 주의하자. ## 스테이트풀셋 안에 파드 @@ -125,16 +131,17 @@ web-1 1/1 Running 0 18s ```shell kubectl get pods -l app=nginx +``` +``` NAME READY STATUS RESTARTS AGE web-0 1/1 Running 0 1m web-1 1/1 Running 0 1m - ``` [스테이트풀셋](/ko/docs/concepts/workloads/controllers/statefulset/) 개념에서 언급했듯 스테이트풀셋의 파드는 끈끈하고 고유한 정체성을 가진다. -이 정체성은 스테이트풀 컨트롤러에서 각 파드에 주어지는 -고유한 순번에 기인한다. 파드의 이름의 형식은 +이 정체성은 스테이트풀셋 {{< glossary_tooltip text="컨트롤러" term_id="controller" >}}에서 +각 파드에 주어지는 고유한 순번에 기인한다. 파드의 이름의 형식은 `<스테이트풀셋 이름>-<순번>` 이다. 앞서 `web` 스테이트풀셋은 2개의 레플리카를 가졌으므로 `web-0` 과 `web-1` 2개 파드를 생성한다. @@ -145,7 +152,9 @@ web-1 1/1 Running 0 1m [`kubectl exec`](/docs/reference/generated/kubectl/kubectl-commands/#exec)를 이용하자. ```shell -for i in 0 1; do kubectl exec web-$i -- sh -c 'hostname'; done +for i in 0 1; do kubectl exec "web-$i" -- sh -c 'hostname'; done +``` +``` web-0 web-1 ``` @@ -157,7 +166,14 @@ web-1 ```shell kubectl run -i --tty --image busybox:1.28 dns-test --restart=Never --rm +``` +위 명령으로 새로운 셸을 시작한다. 새 셸에서 다음을 실행한다. +```shell +# dns-test 컨테이너 셸에서 다음을 실행한다. nslookup web-0.nginx +``` +출력 결과는 다음과 비슷하다. +``` Server: 10.0.0.10 Address 1: 10.0.0.10 kube-dns.kube-system.svc.cluster.local @@ -172,6 +188,8 @@ Name: web-1.nginx Address 1: 10.244.2.6 ``` +(이제 `exit` 명령으로 컨테이너 셸에서 종료한다.) + 헤드리스 서비스의 CNAME은 SRV 레코드를 지칭한다 (Running과 Ready 상태의 각 파드마다 1개). SRV 레코드는 파드의 IP 주소를 포함한 A 레코드 엔트리를 지칭한다. @@ -196,6 +214,8 @@ pod "web-1" deleted ```shell kubectl get pod -w -l app=nginx +``` +``` NAME READY STATUS RESTARTS AGE web-0 0/1 ContainerCreating 0 0s NAME READY STATUS RESTARTS AGE @@ -207,15 +227,27 @@ web-1 1/1 Running 0 34s ``` 파드의 호스트네임과 클러스터 내부 DNS 엔트리를 보기 위해 -`kubectl exec`과 `kubectl run`을 이용하자. +`kubectl exec`과 `kubectl run`을 이용하자. 먼저, 파드의 호스트네임을 확인한다. ```shell for i in 0 1; do kubectl exec web-$i -- sh -c 'hostname'; done +``` +``` web-0 web-1 - +``` +그리고 다음을 실행한다. +``` kubectl run -i --tty --image busybox:1.28 dns-test --restart=Never --rm /bin/sh +``` +이 명령으로 새로운 셸이 시작된다. +새 셸에서 다음을 실행한다. +```shell +# dns-test 컨테이너 셸에서 이것을 실행한다. nslookup web-0.nginx +``` +출력 결과는 다음과 비슷하다. +``` Server: 10.0.0.10 Address 1: 10.0.0.10 kube-dns.kube-system.svc.cluster.local @@ -230,6 +262,8 @@ Name: web-1.nginx Address 1: 10.244.2.8 ``` +(이제 `exit` 명령으로 컨테이너 셸을 종료한다.) + 파드의 순번, 호스트네임, SRV 레코드와 A 레코드이름은 변경되지 않지만 파드의 IP 주소는 변경될 수 있다. 이는 튜토리얼에서 사용하는 클러스터나 다른 클러스터에도 동일하다. 따라서 다른 애플리케이션이 IP 주소로 @@ -255,12 +289,20 @@ Running과 Ready 상태의 모든 파드들을 ```shell kubectl get pvc -l app=nginx +``` +출력 결과는 다음과 비슷하다. +``` NAME STATUS VOLUME CAPACITY ACCESSMODES AGE www-web-0 Bound pvc-15c268c7-b507-11e6-932f-42010a800002 1Gi RWO 48s www-web-1 Bound pvc-15c79307-b507-11e6-932f-42010a800002 1Gi RWO 48s ``` -스테이트풀셋 컨트롤러는 2개의 [퍼시스턴트볼륨](/ko/docs/concepts/storage/persistent-volumes/)에 -묶인 2개의 퍼시스턴트볼륨클레임을 생성했다. 본 튜토리얼에서 사용되는 클러스터는 퍼시스턴트볼륨을 동적으로 + +스테이트풀셋 컨트롤러는 2개의 +{{< glossary_tooltip text="퍼시스턴트볼륨" term_id="persistent-volume" >}}에 +묶인 2개의 +{{< glossary_tooltip text="퍼시스턴트볼륨클레임" term_id="persistent-volume-claim" >}}을 생성했다. + +본 튜토리얼에서 사용되는 클러스터는 퍼시스턴트볼륨을 동적으로 프로비저닝하도록 설정되었으므로 생성된 퍼시스턴트볼륨도 자동으로 묶인다. NGINX 웹서버는 기본 색인 파일로 @@ -272,23 +314,23 @@ NGINX 웹서버는 기본 색인 파일로 NGINX 웹서버가 해당 호스트네임을 제공하는지 확인해보자. ```shell -for i in 0 1; do kubectl exec web-$i -- sh -c 'echo $(hostname) > /usr/share/nginx/html/index.html'; done +for i in 0 1; do kubectl exec "web-$i" -- sh -c 'echo $(hostname) > /usr/share/nginx/html/index.html'; done -for i in 0 1; do kubectl exec -it web-$i -- curl localhost; done +for i in 0 1; do kubectl exec -it "web-$i" -- curl localhost; done +``` +``` web-0 web-1 ``` {{< note >}} -위에 curl 명령어로 403 Forbidden 아닌 응답을 보려면 -`volumeMounts`로 마운트된 디렉터리의 퍼미션을 수정해야 한다 +위에 curl 명령어로 **403 Forbidden** 아닌 응답을 보려면 +다음을 실행해서 `volumeMounts`로 마운트된 디렉터리의 퍼미션을 수정해야 한다 ([hostPath 볼륨을 사용할 때에 버그](https://github.com/kubernetes/kubernetes/issues/2630)로 인함). -```shell -for i in 0 1; do kubectl exec web-$i -- chmod 755 /usr/share/nginx/html; done -``` +`for i in 0 1; do kubectl exec web-$i -- chmod 755 /usr/share/nginx/html; done` -위에 curl 명령을 재시도하기 전에 +위에 `curl` 명령을 재시도하기 전에 위 명령을 실행해야 한다. {{< /note >}} 첫째 터미널에서 스테이트풀셋의 파드를 감시하자. @@ -301,6 +343,8 @@ kubectl get pod -w -l app=nginx ```shell kubectl delete pod -l app=nginx +``` +``` pod "web-0" deleted pod "web-1" deleted ``` @@ -309,6 +353,8 @@ pod "web-1" deleted ```shell kubectl get pod -w -l app=nginx +``` +``` NAME READY STATUS RESTARTS AGE web-0 0/1 ContainerCreating 0 0s NAME READY STATUS RESTARTS AGE @@ -322,7 +368,9 @@ web-1 1/1 Running 0 34s 웹서버에서 자신의 호스트네임을 계속 제공하는지 확인하자. ``` -for i in 0 1; do kubectl exec -it web-$i -- curl localhost; done +for i in 0 1; do kubectl exec -i -t "web-$i" -- curl http://localhost/; done +``` +``` web-0 web-1 ``` @@ -334,6 +382,7 @@ web-1 각각의 퍼시스턴트볼륨은 적절하게 마운트된다. ## 스테이트풀셋 스케일링 + 스테이트풀셋을 스케일링하는 것은 레플리카 개수를 늘리거나 줄이는 것을 의미한다. 이것은 `replicas` 필드를 갱신하여 이뤄진다. [`kubectl scale`](/docs/reference/generated/kubectl/kubectl-commands/#scale)이나 [`kubectl patch`](/docs/reference/generated/kubectl/kubectl-commands/#patch)을 @@ -352,6 +401,8 @@ kubectl get pods -w -l app=nginx ```shell kubectl scale sts web --replicas=5 +``` +``` statefulset.apps/web scaled ``` @@ -360,6 +411,8 @@ statefulset.apps/web scaled ```shell kubectl get pods -w -l app=nginx +``` +``` NAME READY STATUS RESTARTS AGE web-0 1/1 Running 0 2h web-1 1/1 Running 0 2h @@ -392,18 +445,22 @@ web-4 1/1 Running 0 19s kubectl get pods -w -l app=nginx ``` -다른 터미널에서 `kubectl patch`으로 스테이트풀셋을 뒤로 - 3개의 레플리카로 스케일링하자. +다른 터미널에서 `kubectl patch`으로 스테이트풀셋을 다시 +3개의 레플리카로 스케일링하자. ```shell kubectl patch sts web -p '{"spec":{"replicas":3}}' +``` +``` statefulset.apps/web patched ``` `web-4`와 `web-3`이 Terminating으로 전환되기까지 기다리자. -``` +```shell kubectl get pods -w -l app=nginx +``` +``` NAME READY STATUS RESTARTS AGE web-0 1/1 Running 0 3h web-1 1/1 Running 0 3h @@ -428,6 +485,8 @@ web-3 1/1 Terminating 0 42s ```shell kubectl get pvc -l app=nginx +``` +``` NAME STATUS VOLUME CAPACITY ACCESSMODES AGE www-web-0 Bound pvc-15c268c7-b507-11e6-932f-42010a800002 1Gi RWO 13h www-web-1 Bound pvc-15c79307-b507-11e6-932f-42010a800002 1Gi RWO 13h @@ -459,6 +518,8 @@ www-web-4 Bound pvc-e11bb5f8-b508-11e6-932f-42010a800002 1Gi RWO ```shell kubectl patch statefulset web -p '{"spec":{"updateStrategy":{"type":"RollingUpdate"}}}' +``` +``` statefulset.apps/web patched ``` @@ -467,13 +528,18 @@ statefulset.apps/web patched ```shell kubectl patch statefulset web --type='json' -p='[{"op": "replace", "path": "/spec/template/spec/containers/0/image", "value":"gcr.io/google_containers/nginx-slim:0.8"}]' +``` +``` statefulset.apps/web patched ``` 다른 터미널창에서 스테이트풀셋의 파드를 감시하자. ```shell -kubectl get po -l app=nginx -w +kubectl get pod -l app=nginx -w +``` +출력 결과는 다음과 비슷하다. +``` NAME READY STATUS RESTARTS AGE web-0 1/1 Running 0 7m web-1 1/1 Running 0 7m @@ -512,17 +578,20 @@ web-0 1/1 Running 0 10s 이 스테이트풀셋 컨트롤러는 각 파드를 종료시키고 다음 파드를 업데이트하기 전에 그것이 Running과 Ready 상태로 전환될 때까지 기다린다. 알아둘 것은 비록 스테이트풀셋 컨트롤러에서 이전 파드가 Running과 Ready 상태가 되기까지 -다음 파드를 업데이트하지 않아도 현재 버전으로 파드를 업데이트하다 실패하면 복원한다는 것이다. +다음 파드를 업데이트하지 않아도 현재 버전으로 파드를 업데이트하다 실패하면 +복원한다는 것이다. + 업데이트를 이미 받은 파드는 업데이트된 버전으로 복원되고 아직 업데이트를 받지 못한 파드는 -이전 버전으로 복원한다. -이런 식으로 컨트롤러는 간헐적인 오류가 발생해도 +이전 버전으로 복원한다. 이런 식으로 컨트롤러는 간헐적인 오류가 발생해도 애플리케이션을 계속 건강하게 유지하고 업데이트도 일관되게 유지하려 한다. 컨테이너 이미지를 살펴보기 위해 파드를 가져오자. ```shell -for p in 0 1 2; do kubectl get po web-$p --template '{{range $i, $c := .spec.containers}}{{$c.image}}{{end}}'; echo; done +for p in 0 1 2; do kubectl get pod "web-$p" --template '{{range $i, $c := .spec.containers}}{{$c.image}}{{end}}'; echo; done +``` +``` k8s.gcr.io/nginx-slim:0.8 k8s.gcr.io/nginx-slim:0.8 k8s.gcr.io/nginx-slim:0.8 @@ -531,10 +600,13 @@ k8s.gcr.io/nginx-slim:0.8 스테이트풀셋의 모든 파드가 지금은 이전 컨테이너 이미지를 실행 중이이다. -**팁** 롤링 업데이트 상황을 살펴보기 위해 `kubectl rollout status sts/<name>` +{{< note >}} +스테이트풀셋의 롤링 업데이트 상황을 살펴보기 위해 `kubectl rollout status sts/<name>` 명령어도 사용할 수 있다. +{{< /note >}} #### 단계적으로 업데이트 하기 {#staging-an-update} + `RollingUpdate` 업데이트 전략의 파라미터인 `partition`를 이용하여 스테이트풀셋의 단계적으로 업데이트할 수 있다. 단계적 업데이트는 스테이트풀셋의 모든 파드를 현재 버전으로 유지하면서 @@ -544,6 +616,8 @@ k8s.gcr.io/nginx-slim:0.8 ```shell kubectl patch statefulset web -p '{"spec":{"updateStrategy":{"type":"RollingUpdate","rollingUpdate":{"partition":3}}}}' +``` +``` statefulset.apps/web patched ``` @@ -551,20 +625,26 @@ statefulset.apps/web patched ```shell kubectl patch statefulset web --type='json' -p='[{"op": "replace", "path": "/spec/template/spec/containers/0/image", "value":"k8s.gcr.io/nginx-slim:0.7"}]' +``` +``` statefulset.apps/web patched ``` 스테이트풀셋의 파드를 삭제하자. ```shell -kubectl delete po web-2 +kubectl delete pod web-2 +``` +``` pod "web-2" deleted ``` 파드가 Running과 Ready 상태가 되기까지 기다리자. ```shell -kubectl get po -l app=nginx -w +kubectl get pod -l app=nginx -w +``` +``` NAME READY STATUS RESTARTS AGE web-0 1/1 Running 0 4m web-1 1/1 Running 0 4m @@ -572,12 +652,13 @@ web-2 0/1 ContainerCreating 0 11s web-2 1/1 Running 0 18s ``` -파드의 컨테이너를 가져오자. +파드의 컨테이너 이미지를 가져오자. ```shell -kubectl get po web-2 --template '{{range $i, $c := .spec.containers}}{{$c.image}}{{end}}' +kubectl get pod web-2 --template '{{range $i, $c := .spec.containers}}{{$c.image}}{{end}}' +``` +``` k8s.gcr.io/nginx-slim:0.8 - ``` 비록 업데이트 전략이 `RollingUpdate`이지만 스테이트풀셋은 @@ -586,6 +667,7 @@ k8s.gcr.io/nginx-slim:0.8 `파티션`보다 작기 때문이다. #### 카나리(Canary) 롤링 아웃 + [위에서](#staging-an-update) 지정한 `partition`값을 차감시키면 변경사항을 테스트하기 위해 카나리 롤아웃을 할 수 있다. @@ -593,13 +675,17 @@ k8s.gcr.io/nginx-slim:0.8 ```shell kubectl patch statefulset web -p '{"spec":{"updateStrategy":{"type":"RollingUpdate","rollingUpdate":{"partition":2}}}}' +``` +``` statefulset.apps/web patched ``` `web-2` 파드가 Running과 Ready 상태가 되기까지 기다리자. ```shell -kubectl get po -l app=nginx -w +kubectl get pod -l app=nginx -w +``` +``` NAME READY STATUS RESTARTS AGE web-0 1/1 Running 0 4m web-1 1/1 Running 0 4m @@ -611,6 +697,8 @@ web-2 1/1 Running 0 18s ```shell kubectl get po web-2 --template '{{range $i, $c := .spec.containers}}{{$c.image}}{{end}}' +``` +``` k8s.gcr.io/nginx-slim:0.7 ``` @@ -622,14 +710,19 @@ k8s.gcr.io/nginx-slim:0.7 `web-1` 파드를 삭제하자. ```shell -kubectl delete po web-1 +kubectl delete pod web-1 +``` +``` pod "web-1" deleted ``` `web-1` 파드가 Running과 Ready 상태가 되기까지 기다리자. ```shell -kubectl get po -l app=nginx -w +kubectl get pod -l app=nginx -w +``` +출력 결과는 다음과 비슷하다. +``` NAME READY STATUS RESTARTS AGE web-0 1/1 Running 0 6m web-1 0/1 Terminating 0 6m @@ -643,12 +736,13 @@ web-1 0/1 ContainerCreating 0 0s web-1 1/1 Running 0 18s ``` -`web-1` 파드의 컨테이너를 가져오자. +`web-1` 파드의 컨테이너 이미지를 가져오자. ```shell -kubectl get po web-1 --template '{{range $i, $c := .spec.containers}}{{$c.image}}{{end}}' +kubectl get pod web-1 --template '{{range $i, $c := .spec.containers}}{{$c.image}}{{end}}' +``` +``` k8s.gcr.io/nginx-slim:0.8 - ``` `web-1` 는 원래 환경설정으로 복원되었는데 @@ -658,6 +752,7 @@ k8s.gcr.io/nginx-slim:0.8 종료되어 원래 환경설정으로 복원된다. #### 단계적 롤아웃 + [카나리 롤아웃](#카나리-canary-롤링-아웃)에서 했던 방법과 비슷하게 분할된 롤링 업데이트를 이용하여 단계적 롤아웃(e.g. 선형, 기하 또는 지수적 롤아웃)을 수행할 수 있다. 단계적 롤아웃을 수행하려면 @@ -668,13 +763,18 @@ partition은 현재 `2`이다. partition을 `0`으로 바꾸자. ```shell kubectl patch statefulset web -p '{"spec":{"updateStrategy":{"type":"RollingUpdate","rollingUpdate":{"partition":0}}}}' +``` +``` statefulset.apps/web patched ``` 스테이트풀셋의 모든 파드가 Running과 Ready 상태가 되기까지 기다리자. ```shell -kubectl get po -l app=nginx -w +kubectl get pod -l app=nginx -w +``` +출력 결과는 다음과 비슷하다. +``` NAME READY STATUS RESTARTS AGE web-0 1/1 Running 0 3m web-1 0/1 ContainerCreating 0 11s @@ -692,17 +792,19 @@ web-0 0/1 ContainerCreating 0 0s web-0 1/1 Running 0 3s ``` -파드의 컨테이너를 가져오자. +스테이트풀셋에 있는 파드의 컨테이너 이미지 상세 정보를 가져오자. ```shell -for p in 0 1 2; do kubectl get po web-$p --template '{{range $i, $c := .spec.containers}}{{$c.image}}{{end}}'; echo; done +for p in 0 1 2; do kubectl get pod "web-$p" --template '{{range $i, $c := .spec.containers}}{{$c.image}}{{end}}'; echo; done +``` +``` k8s.gcr.io/nginx-slim:0.7 k8s.gcr.io/nginx-slim:0.7 k8s.gcr.io/nginx-slim:0.7 ``` -`partition`을 `0`으로 이동하여 스테이트풀셋 컨트롤러에서 계속해서 +`partition`을 `0`으로 이동하여 스테이트풀셋에서 계속해서 업데이트 처리를 하도록 허용하였다. ### 삭제 시 동작 @@ -733,6 +835,8 @@ kubectl get pods -w -l app=nginx ```shell kubectl delete statefulset web --cascade=false +``` +``` statefulset.apps "web" deleted ``` @@ -740,6 +844,8 @@ statefulset.apps "web" deleted ```shell kubectl get pods -l app=nginx +``` +``` NAME READY STATUS RESTARTS AGE web-0 1/1 Running 0 6m web-1 1/1 Running 0 7m @@ -751,6 +857,8 @@ web-2 1/1 Running 0 5m ```shell kubectl delete pod web-0 +``` +``` pod "web-0" deleted ``` @@ -758,6 +866,8 @@ pod "web-0" deleted ```shell kubectl get pods -l app=nginx +``` +``` NAME READY STATUS RESTARTS AGE web-1 1/1 Running 0 10m web-2 1/1 Running 0 7m @@ -777,17 +887,21 @@ kubectl get pods -w -l app=nginx ```shell kubectl apply -f web.yaml +``` +``` statefulset.apps/web created service/nginx unchanged ``` 이 에러는 무시하자. 이것은 다만 해당 서비스가 있더라도 -nginx 헤드리스 서비스를 생성하려고 했음을 뜻한다. +_nginx_ 헤드리스 서비스를 생성하려고 했음을 뜻한다. 첫째 터미널에서 실행 중인 `kubectl get` 명령어의 출력을 살펴보자. ```shell kubectl get pods -w -l app=nginx +``` +``` NAME READY STATUS RESTARTS AGE web-1 1/1 Running 0 16m web-2 1/1 Running 0 2m @@ -813,7 +927,9 @@ web-2 0/1 Terminating 0 3m 다른 관점으로 살펴보자. ```shell -for i in 0 1; do kubectl exec -it web-$i -- curl localhost; done +for i in 0 1; do kubectl exec -i -t "web-$i" -- curl http://localhost/; done +``` +``` web-0 web-1 ``` @@ -837,6 +953,8 @@ kubectl get pods -w -l app=nginx ```shell kubectl delete statefulset web +``` +``` statefulset.apps "web" deleted ``` 첫째 터미널에서 실행 중인 `kubectl get` 명령어의 출력을 살펴보고 @@ -844,6 +962,8 @@ statefulset.apps "web" deleted ```shell kubectl get pods -w -l app=nginx +``` +``` NAME READY STATUS RESTARTS AGE web-0 1/1 Running 0 11m web-1 1/1 Running 0 27m @@ -864,12 +984,17 @@ web-1 0/1 Terminating 0 29m 스테이트풀 컨트롤러는 이전 파드가 완전히 종료되기까지 기다린다. -스테이트풀셋과 그 파드를 종속적으로 삭제하는 중에 연관된 헤드리스 서비스를 -삭제하지 않음을 주의하자. +{{< note >}} +종속적 삭제는 파드와 함께 스테이트풀셋을 제거하지만, +스테이트풀셋과 관련된 헤드리스 서비스를 삭제하지 않는다. 꼭 `nginx` 서비스를 수동으로 삭제해라. +{{< /note >}} + ```shell kubectl delete service nginx +``` +``` service "nginx" deleted ``` @@ -877,6 +1002,8 @@ service "nginx" deleted ```shell kubectl apply -f web.yaml +``` +``` service/nginx created statefulset.apps/web created ``` @@ -885,22 +1012,30 @@ statefulset.apps/web created `index.html` 파일 내용을 검색하자. ```shell -for i in 0 1; do kubectl exec -it web-$i -- curl localhost; done +for i in 0 1; do kubectl exec -i -t "web-$i" -- curl http://localhost/; done +``` +``` web-0 web-1 ``` 스테이트풀셋과 그 내부의 모든 파드를 삭제했지만 퍼시스턴트볼륨이 마운트된 채로 -다시 생성되고 `web-0`과 `web-1`은 여전히 +다시 생성되고 `web-0`과 `web-1`은 계속 각 호스트네임을 제공한다. -최종적으로 `web` 스테이트풀셋과`nginx` 서비스를 삭제한다. +최종적으로 `web` 스테이트풀셋을 삭제한다. ```shell kubectl delete service nginx +``` +``` service "nginx" deleted - +``` +그리고 `nginx` 서비스를 삭제한다. +```shell kubectl delete statefulset web +``` +``` statefulset "web" deleted ``` @@ -934,13 +1069,15 @@ statefulset "web" deleted 터미널에서 스테이트풀셋의 파드를 감시하자. ```shell -kubectl get po -l app=nginx -w +kubectl get pod -l app=nginx -w ``` 다른 터미널에서 매니페스트 안에 스테이트풀셋과 서비스를 생성하자. ```shell kubectl apply -f web-parallel.yaml +``` +``` service/nginx created statefulset.apps/web created ``` @@ -948,7 +1085,9 @@ statefulset.apps/web created 첫째 터미널에서 실행했던 `kubectl get` 명령어의 출력을 살펴보자. ```shell -kubectl get po -l app=nginx -w +kubectl get pod -l app=nginx -w +``` +``` NAME READY STATUS RESTARTS AGE web-0 0/1 Pending 0 0s web-0 0/1 Pending 0 0s @@ -967,12 +1106,14 @@ web-1 1/1 Running 0 10s ```shell kubectl scale statefulset/web --replicas=4 +``` +``` statefulset.apps/web scaled ``` `kubectl get` 명령어를 실행 중인 터미널의 출력을 살펴보자. -```shell +``` web-3 0/1 Pending 0 0s web-3 0/1 Pending 0 0s web-3 0/1 Pending 0 7s @@ -982,18 +1123,24 @@ web-3 1/1 Running 0 26s ``` -스테이트풀 컨트롤러는 두 개의 새 파드를 시작하였다. +스테이트풀셋은 두 개의 새 파드를 시작하였다. 두 번째 것을 런칭하기 위해 먼저 런칭한 것이 Running과 Ready 상태가 될 때까지 기다리지 않는다. -이 터미널을 열어 놓고 다른 터미널에서 `web` 스테이트풀셋을 삭제하자. +## {{% heading "cleanup" %}} + +정리의 일환으로 `kubectl` 명령을 실행할 준비가 된 두 개의 터미널이 열려 +있어야 한다. ```shell kubectl delete sts web +# sts는 statefulset의 약자이다. ``` -다시 한번 다른 터미널에서 실행 중인 `kubectl get`명령의 출력을 확인해보자. - +`kubectl get` 명령으로 해당 파드가 삭제된 것을 확인할 수 있다. ```shell +kubectl get pod -l app=nginx -w +``` +``` web-3 1/1 Terminating 0 9m web-2 1/1 Terminating 0 9m web-3 1/1 Terminating 0 9m @@ -1019,7 +1166,7 @@ web-3 0/1 Terminating 0 9m web-3 0/1 Terminating 0 9m ``` -스테이트풀 컨트롤러는 모든 파드를 동시에 삭제한다. 파드를 삭제하기 전에 +삭제하는 동안, 스테이트풀셋은 모든 파드를 동시에 삭제한다. 해당 파드를 삭제하기 전에 그 파드의 순서상 후계자를 기다리지 않는다. `kubectl get` 명령어가 실행된 터미널을 닫고 @@ -1030,12 +1177,11 @@ kubectl delete svc nginx ``` -## {{% heading "cleanup" %}} - +{{< note >}} 이 튜토리얼에서 사용된 퍼시턴트볼륨을 위한 -퍼시스턴트 스토리지 미디어를 삭제해야 한다. +퍼시스턴트 스토리지 미디어도 삭제해야 한다. + + 모든 스토리지를 반환하도록 환경, 스토리지 설정과 프로비저닝 방법에 따른 단계를 따르자. - - - +{{< /note >}} diff --git a/content/ko/docs/tutorials/stateful-application/cassandra.md b/content/ko/docs/tutorials/stateful-application/cassandra.md index f67516cb80..ea6b3063cc 100644 --- a/content/ko/docs/tutorials/stateful-application/cassandra.md +++ b/content/ko/docs/tutorials/stateful-application/cassandra.md @@ -1,10 +1,11 @@ --- title: "예시: 카산드라를 스테이트풀셋으로 배포하기" -reviewers: content_type: tutorial weight: 30 --- + + <!-- overview --> 이 튜토리얼은 쿠버네티스에서 [아파치 카산드라](http://cassandra.apache.org/)를 실행하는 방법을 소개한다. 데이터베이스인 카산드라는 데이터 내구성을 제공하기 위해 퍼시스턴트 스토리지가 필요하다(애플리케이션 _상태_). 이 예제에서 사용자 지정 카산드라 시드 공급자는 카산드라가 클러스터에 가입할 때 카산드라가 인스턴스를 검색할 수 있도록 한다. @@ -24,7 +25,6 @@ weight: 30 {{< /note >}} - ## {{% heading "objectives" %}} * 카산드라 헤드리스 {{< glossary_tooltip text="Service" term_id="service" >}}를 생성하고 검증한다. @@ -36,18 +36,9 @@ weight: 30 ## {{% heading "prerequisites" %}} -이 튜토리얼을 완료하려면, [파드](/ko/docs/concepts/workloads/pods/pod/), [서비스](/ko/docs/concepts/services-networking/service/), [스테이트풀셋](/ko/docs/concepts/workloads/controllers/statefulset/)의 기본 개념에 친숙해야한다. 추가로 +{{< include "task-tutorial-prereqs.md" >}} -* *kubectl* 커맨드라인 도구를 [설치와 설정](/docs/tasks/tools/install-kubectl/)하자. - -* [`cassandra-service.yaml`](/examples/application/cassandra/cassandra-service.yaml)와 - [`cassandra-statefulset.yaml`](/examples/application/cassandra/cassandra-statefulset.yaml)를 다운로드한다. - -* 실행 중인 쿠버네티스 클러스터를 소유 - -{{< note >}} -아직 클러스터가 없다면 [설치](/ko/docs/setup/)를 읽도록 하자. -{{< /note >}} +이 튜토리얼을 완료하려면 {{< glossary_tooltip text="파드" term_id="pod" >}}, {{< glossary_tooltip text="서비스" term_id="service" >}}, {{< glossary_tooltip text="스테이트풀셋" term_id="StatefulSet" >}}에 대한 기본 지식이 있어야 한다. ### 추가적인 Minikube 설정 요령 @@ -274,7 +265,6 @@ kubectl apply -f cassandra-statefulset.yaml - ## {{% heading "whatsnext" %}} @@ -283,3 +273,4 @@ kubectl apply -f cassandra-statefulset.yaml * 커스텀 [시드 제공자 설정](https://git.k8s.io/examples/cassandra/java/README.md)를 살펴본다. + diff --git a/content/ko/docs/tutorials/stateful-application/mysql-wordpress-persistent-volume.md b/content/ko/docs/tutorials/stateful-application/mysql-wordpress-persistent-volume.md index d4891dbe39..1e0aefd4a3 100644 --- a/content/ko/docs/tutorials/stateful-application/mysql-wordpress-persistent-volume.md +++ b/content/ko/docs/tutorials/stateful-application/mysql-wordpress-persistent-volume.md @@ -1,6 +1,5 @@ --- title: "예시: WordPress와 MySQL을 퍼시스턴트 볼륨에 배포하기" -reviewers: content_type: tutorial weight: 20 card: @@ -9,6 +8,8 @@ card: title: "스테이트풀셋 예시: Wordpress와 퍼시스턴트 볼륨" --- + + <!-- overview --> 이 튜토리얼은 WordPress 사이트와 MySQL 데이터베이스를 Minikube를 이용하여 어떻게 배포하는지 보여준다. 애플리케이션 둘 다 퍼시스턴트 볼륨과 퍼시스턴트볼륨클레임을 데이터를 저장하기 위해 사용한다. @@ -189,8 +190,8 @@ kubectl apply -k ./ 응답은 아래와 비슷해야 한다. ``` - NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE - wordpress ClusterIP 10.0.0.89 <pending> 80:32406/TCP 4m + NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE + wordpress LoadBalancer 10.0.0.89 <pending> 80:32406/TCP 4m ``` {{< note >}} @@ -236,7 +237,7 @@ kubectl apply -k ./ * [인트로스펙션과 디버깅](/docs/tasks/debug-application-cluster/debug-application-introspection/)를 알아보자. -* [잡](/ko/docs/concepts/workloads/controllers/jobs-run-to-completion/)를 알아보자. +* [잡](/ko/docs/concepts/workloads/controllers/job/)를 알아보자. * [포트 포워딩](/ko/docs/tasks/access-application-cluster/port-forward-access-application-cluster/)를 알아보자. * 어떻게 [컨테이너에서 셸을 사용하는지](/docs/tasks/debug-application-cluster/get-shell-running-container/)를 알아보자. diff --git a/content/ko/docs/tutorials/stateful-application/zookeeper.md b/content/ko/docs/tutorials/stateful-application/zookeeper.md index 11120ca54d..490f6ff18d 100644 --- a/content/ko/docs/tutorials/stateful-application/zookeeper.md +++ b/content/ko/docs/tutorials/stateful-application/zookeeper.md @@ -43,7 +43,7 @@ weight: 40 - 어떻게 지속적해서 컨피그맵을 이용해서 앙상블을 설정하는가. - 어떻게 ZooKeeper 서버 디플로이먼트를 앙상블 안에서 퍼뜨리는가. - 어떻게 파드디스룹션버짓을 이용하여 계획된 점검 기간 동안 서비스 가용성을 보장하는가. - + <!-- lessoncontent --> @@ -132,7 +132,7 @@ zk-2 1/1 Running 0 40s for i in 0 1 2; do kubectl exec zk-$i -- hostname; done ``` -스테이트풀셋 컨트롤러는 각 순번 인덱스에 기초하여 각 파드에 고유한 호스트네임을 부여한다. 각 호스트네임은 `<스테이트풀셋 이름>-<순번 인덱스>` 형식을 취한다. `zk` 스테이트풀셋의 `replicas` 필드는 `3`으로 설정되었기 때문에, 그 스테이트풀셋 컨트롤러는 3개 파드의 호스트네임을 `zk-0`, `zk-1`, +스테이트풀셋 컨트롤러는 각 순번 인덱스에 기초하여 각 파드에 고유한 호스트네임을 부여한다. 각 호스트네임은 `<스테이트풀셋 이름>-<순번 인덱스>` 형식을 취한다. `zk` 스테이트풀셋의 `replicas` 필드는 `3`으로 설정되었기 때문에, 그 스테이트풀셋 컨트롤러는 3개 파드의 호스트네임을 `zk-0`, `zk-1`, `zk-2`로 정한다. ```shell @@ -183,9 +183,9 @@ ZooKeeper는 그것의 애플리케이션 환경설정을 `zoo.cfg` 파일에 kubectl exec zk-0 -- cat /opt/zookeeper/conf/zoo.cfg ``` -아래 파일의 `server.1`, `server.2`, `server.3` 속성에서 -`1`, `2`, `3`은 ZooKeeper 서버의 `myid` 파일에 구분자와 -연관된다. +아래 파일의 `server.1`, `server.2`, `server.3` 속성에서 +`1`, `2`, `3`은 ZooKeeper 서버의 `myid` 파일에 구분자와 +연관된다. 이들은 `zk` 스테이트풀셋의 파드의 FQDNS을 설정한다. ```shell @@ -302,7 +302,7 @@ ZooKeeper는 모든 항목을 내구성있는 WAL에 커밋하고 메모리 상 복제된 상태 머신을 이루는 합의 프로토콜에서 이용하는 일반적인 기법이다. -[`kubectl delete`](/docs/reference/generated/kubectl/kubectl-commands/#delete) 명령을 이용하여 +[`kubectl delete`](/docs/reference/generated/kubectl/kubectl-commands/#delete) 명령을 이용하여 `zk` 스테이트풀셋을 삭제하자. ```shell @@ -448,7 +448,7 @@ ZooKeeper의 서버 디렉터리에 마운트한다. [리더 선출 촉진](#리더-선출-촉진)과 [합의 달성](#합의-달성) 섹션에서 알렸듯이, ZooKeeper 앙상블에 서버는 리더 선출과 쿼럼을 구성하기 위한 일관된 설정이 필요하다. -또한 Zab 프로토콜의 일관된 설정도 +또한 Zab 프로토콜의 일관된 설정도 네트워크에 걸쳐 올바르게 동작하기 위해서 필요하다. 이 예시에서는 메니페스트에 구성을 직접 포함시켜서 일관된 구성을 달성한다. @@ -496,7 +496,7 @@ ZooKeeper는 [Log4j](http://logging.apache.org/log4j/2.x/)를 이용하며 kubectl exec zk-0 cat /usr/etc/zookeeper/log4j.properties ``` -아래 로깅 구성은 ZooKeeper가 모든 로그를 +아래 로깅 구성은 ZooKeeper가 모든 로그를 표준 출력 스트림으로 처리하게 한다. ```shell @@ -544,7 +544,7 @@ kubectl logs zk-0 --tail 20 쿠버네티스는 더 강력하지만 조금 복잡한 로그 통합을 [스택드라이버](/docs/tasks/debug-application-cluster/logging-stackdriver/)와 -[Elasticsearch와 Kibana](/docs/tasks/debug-application-cluster/logging-elasticsearch-kibana/)를 지원한다. +[Elasticsearch와 Kibana](/ko/docs/tasks/debug-application-cluster/logging-elasticsearch-kibana/)를 지원한다. 클러스터 수준의 로그 적재(ship)와 통합을 위해서는 로그 순환과 적재를 위해 [사이드카](https://kubernetes.io/blog/2015/06/the-distributed-system-toolkit-patterns) 컨테이너를 배포하는 것을 고려한다. @@ -564,7 +564,7 @@ securityContext: fsGroup: 1000 ``` -파드 컨테이너에서 UID 1000은 ZooKeeper 사용자이며, GID 1000은 +파드 컨테이너에서 UID 1000은 ZooKeeper 사용자이며, GID 1000은 ZooKeeper의 그룹에 해당한다. `zk-0` 파드에서 프로세스 정보를 얻어오자. @@ -866,7 +866,7 @@ kubernetes-node-2g2d kubectl get nodes ``` -[`kubectl cordon`](/docs/reference/generated/kubectl/kubectl-commands/#cordon)을 이용하여 +[`kubectl cordon`](/docs/reference/generated/kubectl/kubectl-commands/#cordon)을 이용하여 클러스터 내에 4개 노드를 제외하고 다른 모든 노드를 통제해보자. ```shell @@ -1093,5 +1093,3 @@ node "kubernetes-node-ixsl" uncordoned 퍼시스턴트 스토리지 미디어를 삭제하자. 귀하의 환경과 스토리지 구성과 프로비저닝 방법에서 필요한 절차를 따라서 모든 스토리지가 재확보되도록 하자. - - diff --git a/content/ko/docs/tutorials/stateless-application/expose-external-ip-address.md b/content/ko/docs/tutorials/stateless-application/expose-external-ip-address.md index 291cceba26..719c998366 100644 --- a/content/ko/docs/tutorials/stateless-application/expose-external-ip-address.md +++ b/content/ko/docs/tutorials/stateless-application/expose-external-ip-address.md @@ -15,7 +15,7 @@ weight: 10 ## {{% heading "prerequisites" %}} - * [kubectl](/docs/tasks/tools/install-kubectl/)을 설치한다. + * [kubectl](/ko/docs/tasks/tools/install-kubectl/)을 설치한다. * Google Kubernetes Engine 또는 Amazon Web Services와 같은 클라우드 공급자를 사용하여 쿠버네티스 클러스터를 생성한다. @@ -52,10 +52,10 @@ kubectl apply -f https://k8s.io/examples/service/load-balancer-example.yaml 위의 명령어는 - [디플로이먼트](/ko/docs/concepts/workloads/controllers/deployment/) + [디플로이먼트(Deployment)](/ko/docs/concepts/workloads/controllers/deployment/) 오브젝트와 관련된 - [레플리카 셋](/ko/docs/concepts/workloads/controllers/replicaset/) - 오브젝트를 생성한다. 레플리카 셋은 다섯 개의 + [레플리카셋(ReplicaSet)](/ko/docs/concepts/workloads/controllers/replicaset/) + 오브젝트를 생성한다. 레플리카셋은 다섯 개의 [파드](/ko/docs/concepts/workloads/pods/pod/)가 있으며, 각 파드는 Hello World 애플리케이션을 실행한다. @@ -64,7 +64,7 @@ kubectl apply -f https://k8s.io/examples/service/load-balancer-example.yaml kubectl get deployments hello-world kubectl describe deployments hello-world -1. 레플리카 셋 오브젝트에 대한 정보를 확인한다. +1. 레플리카셋 오브젝트에 대한 정보를 확인한다. kubectl get replicasets kubectl describe replicasets @@ -84,7 +84,7 @@ kubectl apply -f https://k8s.io/examples/service/load-balancer-example.yaml {{< note >}} - `type=LoadBalancer` 서비스는 이 예시에서 다루지 않은 외부 클라우드 공급자가 지원하며, 자세한 내용은 [이 페이지](/ko/docs/concepts/services-networking/service/#loadbalancer를 참조한다. + `type=LoadBalancer` 서비스는 이 예시에서 다루지 않은 외부 클라우드 공급자가 지원하며, 자세한 내용은 [이 페이지](/ko/docs/concepts/services-networking/service/#loadbalancer)를 참조한다. {{< /note >}} @@ -160,7 +160,7 @@ kubectl apply -f https://k8s.io/examples/service/load-balancer-example.yaml kubectl delete services my-service -Hello World 애플리케이션을 실행 중인 디플로이먼트, 레플리카 셋, 파드를 삭제하려면, +Hello World 애플리케이션을 실행 중인 디플로이먼트, 레플리카셋, 파드를 삭제하려면, 아래의 명령어를 입력한다. kubectl delete deployment hello-world @@ -173,4 +173,3 @@ Hello World 애플리케이션을 실행 중인 디플로이먼트, 레플리카 [애플리케이션과 서비스 연결하기](/ko/docs/concepts/services-networking/connect-applications-service/)에 대해 더 배워 본다. - diff --git a/content/ko/docs/tutorials/stateless-application/guestbook-logs-metrics-with-elk.md b/content/ko/docs/tutorials/stateless-application/guestbook-logs-metrics-with-elk.md index b37497b9bf..9d5cf7713b 100644 --- a/content/ko/docs/tutorials/stateless-application/guestbook-logs-metrics-with-elk.md +++ b/content/ko/docs/tutorials/stateless-application/guestbook-logs-metrics-with-elk.md @@ -1,6 +1,5 @@ --- title: "예제: PHP / Redis 방명록 예제에 로깅과 메트릭 추가" -reviewers: content_type: tutorial weight: 21 card: @@ -403,7 +402,6 @@ kubectl scale --replicas=3 deployment/frontend ## {{% heading "whatsnext" %}} * [리소스 모니터링 도구](/ko/docs/tasks/debug-application-cluster/resource-usage-monitoring/)를 공부한다. -* [로깅 아키텍처](/docs/concepts/cluster-administration/logging/)를 더 읽어본다. +* [로깅 아키텍처](/ko/docs/concepts/cluster-administration/logging/)를 더 읽어본다. * [애플리케이션 검사 및 디버깅](/ko/docs/tasks/debug-application-cluster/)을 더 읽어본다. * [애플리케이션 문제 해결](/ko/docs/tasks/debug-application-cluster/resource-usage-monitoring/)을 더 읽어본다. - diff --git a/content/ko/docs/tutorials/stateless-application/guestbook.md b/content/ko/docs/tutorials/stateless-application/guestbook.md index bf91733f9b..cce67800a6 100644 --- a/content/ko/docs/tutorials/stateless-application/guestbook.md +++ b/content/ko/docs/tutorials/stateless-application/guestbook.md @@ -47,7 +47,7 @@ card: {{< codenew file="application/guestbook/redis-master-deployment.yaml" >}} -1. 매니페스트 파일을 다운로드한 디렉토리에서 터미널 창을 시작한다. +1. 매니페스트 파일을 다운로드한 디렉터리에서 터미널 창을 시작한다. 1. `redis-master-deployment.yaml` 파일을 통해 Redis 마스터의 디플로이먼트에 적용한다. ```shell @@ -218,7 +218,7 @@ Google Compute Engine 또는 Google Kubernetes Engine과 같은 일부 클라우 1. 서비스의 목록을 질의하여 프론트엔드 서비스가 실행 중인지 확인한다. ```shell - kubectl get services + kubectl get services ``` 결과는 아래와 같은 형태로 나타난다. @@ -320,7 +320,7 @@ Google Compute Engine 또는 Google Kubernetes Engine과 같은 일부 클라우 redis-slave-2005841000-fpvqc 1/1 Running 0 1h redis-slave-2005841000-phfv9 1/1 Running 0 1h ``` - + ## {{% heading "cleanup" %}} @@ -346,7 +346,7 @@ Google Compute Engine 또는 Google Kubernetes Engine과 같은 일부 클라우 deployment.apps "frontend" deleted service "frontend" deleted ``` - + 1. 파드의 목록을 질의하여 실행 중인 파드가 없는지 확인한다. ```shell @@ -367,6 +367,4 @@ Google Compute Engine 또는 Google Kubernetes Engine과 같은 일부 클라우 * [쿠버네티스 기초](/ko/docs/tutorials/kubernetes-basics/) 튜토리얼을 완료 * [MySQL과 Wordpress을 위한 퍼시스턴트 볼륨](/ko/docs/tutorials/stateful-application/mysql-wordpress-persistent-volume/#visit-your-new-wordpress-blog)을 사용하여 블로그 생성하는데 쿠버네티스 이용하기 * [애플리케이션 접속](/ko/docs/concepts/services-networking/connect-applications-service/)에 대해 더 알아보기 -* [자원 관리](/docs/concepts/cluster-administration/manage-deployment/#using-labels-effectively)에 대해 더 알아보기 - - +* [자원 관리](/ko/docs/concepts/cluster-administration/manage-deployment/#효과적인-레이블-사용)에 대해 더 알아보기 diff --git a/content/ko/examples/service/access/hello-application.yaml b/content/ko/examples/service/access/hello-application.yaml new file mode 100644 index 0000000000..1cf41313c5 --- /dev/null +++ b/content/ko/examples/service/access/hello-application.yaml @@ -0,0 +1,20 @@ +apiVersion: apps/v1 +kind: Deployment +metadata: + name: hello-world +spec: + selector: + matchLabels: + run: load-balancer-example + replicas: 2 + template: + metadata: + labels: + run: load-balancer-example + spec: + containers: + - name: hello-world + image: gcr.io/google-samples/node-hello:1.0 + ports: + - containerPort: 8080 + protocol: TCP diff --git a/content/ko/examples/service/networking/nginx-policy.yaml b/content/ko/examples/service/networking/nginx-policy.yaml new file mode 100644 index 0000000000..89ee988692 --- /dev/null +++ b/content/ko/examples/service/networking/nginx-policy.yaml @@ -0,0 +1,13 @@ +apiVersion: networking.k8s.io/v1 +kind: NetworkPolicy +metadata: + name: access-nginx +spec: + podSelector: + matchLabels: + app: nginx + ingress: + - from: + - podSelector: + matchLabels: + access: "true" diff --git a/content/ko/partners/_index.html b/content/ko/partners/_index.html index 2ac7e6945c..3bd6a375f2 100644 --- a/content/ko/partners/_index.html +++ b/content/ko/partners/_index.html @@ -7,79 +7,90 @@ cid: partners --- <section id="users"> - <main class="main-section"> - <h5>쿠버네티스는 파트너와 협력하여 다양하게 보완하는 플랫폼을 지원하는 강력하고 활기찬 코드베이스를 만들어갑니다.</h5> - <div class="col-container"> - <div class="col-nav"> - <center> - <h5> - <b>공인 쿠버네티스 서비스 공급자(Kubernetes Certified Service Providers, KCSP)</b> - </h5> - <br>기업들이 쿠버네티스를 성공적으로 채택하도록 도와주는 풍부한 경험을 가진 노련한 서비스 공급자입니다. - <br><br><br> - <button id="kcsp" class="button" onClick="updateSrc(this.id)">KCSP 파트너 보기</button> - <br><br><a href="https://www.cncf.io/certification/kcsp/">KCSP</a>에 관심이 있으신가요? - </center> - </div> - <div class="col-nav"> - <center> - <h5> - <b>공인 쿠버네티스 배포, 호스트된 플랫폼 그리고 설치 프로그램</b> - </h5>소프트웨어 적합성은 모든 벤더의 쿠버네티스 버전이 필요한 API를 지원하도록 보장합니다. - <br><br><br> - <button id="conformance" class="button" onClick="updateSrc(this.id)">적합한 파트너 보기</button> - <br><br><a href="https://www.cncf.io/certification/software-conformance/">공인 쿠버네티스</a>에 관심이 있으신가요? - </center> - </div> - <div class="col-nav"> - <center> - <h5><b>쿠버네티스 교육 파트너(Kubernetes Training Partners, KTP)</b></h5> - <br>클라우드 네이티브 기술 교육 경험이 풍부하고 노련한 교육 공급자입니다. - <br><br><br><br> - <button id="ktp" class="button" onClick="updateSrc(this.id)">KTP 파트너 보기</button> - <br><br><a href="https://www.cncf.io/certification/training/">KTP</a>에 관심이 있으신가요? - </center> - </div> - </div> -<script src="https://code.jquery.com/jquery-3.3.1.min.js" integrity="sha256-FgpCb/KJQlLNfOu91ta32o/NMZxltwRo8QtmkMRdAu8=" crossorigin="anonymous"></script> -<script type="text/javascript"> + <main class="main-section"> + <h5>쿠버네티스는 파트너와 협력하여 다양하게 보완하는 플랫폼을 지원하는 강력하고 활기찬 코드베이스를 만들어갑니다.</h5> + <div class="col-container"> + <div class="col-nav"> + <center> + <h5> + <b>공인 쿠버네티스 서비스 공급자(Kubernetes Certified Service Providers, KCSP)</b> + </h5> + <br>기업들이 쿠버네티스를 성공적으로 채택하도록 도와주는 풍부한 경험을 가진 노련한 서비스 공급자입니다. + <br><br><br> + <button id="kcsp" class="button" onClick="updateSrc(this.id)">KCSP 파트너 보기</button> + <br><br><a href="https://www.cncf.io/certification/kcsp/">KCSP</a>에 + 관심이 있으신가요? + </center> + </div> + <div class="col-nav"> + <center> + <h5> + <b>공인 쿠버네티스 배포, 호스트된 플랫폼 그리고 설치 프로그램</b> + </h5>소프트웨어 적합성은 모든 벤더의 쿠버네티스 버전이 필요한 API를 지원하도록 보장합니다. + <br><br><br> + <button id="conformance" class="button" onClick="updateSrc(this.id)">적합한 파트너 보기</button> + <br><br><a href="https://www.cncf.io/certification/software-conformance/">공인 쿠버네티스</a>에 + 관심이 있으신가요? + </center> + </div> + <div class="col-nav"> + <center> + <h5> + <b>쿠버네티스 교육 파트너(Kubernetes Training Partners, KTP)</b> + </h5> + <br>클라우드 네이티브 기술 교육 경험이 풍부하고 노련한 교육 공급자입니다. + <br><br><br> + <button id="ktp" class="button" onClick="updateSrc(this.id)">KTP 파트너 보기</button> + <br><br><a href="https://www.cncf.io/certification/training/">KTP</a>에 + 관심이 있으신가요? + </center> + </div> + </div> + <script crossorigin="anonymous" integrity="sha256-FgpCb/KJQlLNfOu91ta32o/NMZxltwRo8QtmkMRdAu8=" src="https://code.jquery.com/jquery-3.3.1.min.js"></script> + <script type="text/javascript"> - var defaultLink = "https://landscape.cncf.io/category=kubernetes-certified-service-provider&format=card-mode&grouping=category&embed=yes"; - var firstLink = "https://landscape.cncf.io/category=certified-kubernetes-distribution,certified-kubernetes-hosted,certified-kubernetes-installer&format=card-mode&grouping=category&embed=yes"; + var defaultLink = "https://landscape.cncf.io/category=kubernetes-certified-service-provider&format=card-mode&grouping=category&embed=yes"; + var firstLink = "https://landscape.cncf.io/category=certified-kubernetes-distribution,certified-kubernetes-hosted,certified-kubernetes-installer&format=card-mode&grouping=category&embed=yes"; var secondLink = "https://landscape.cncf.io/category=kubernetes-training-partner&format=card-mode&grouping=category&embed=yes"; function updateSrc(buttonId) { - if (buttonId == "kcsp") { - $("#landscape").attr("src",defaultLink); - window.location.hash = "#kcsp"; + if (buttonId == "kcsp") { + $("#landscape").attr("src", defaultLink); + window.location.hash = "#kcsp"; } if (buttonId == "conformance") { - $("#landscape").attr("src",firstLink); - window.location.hash = "#conformance"; + $("#landscape").attr("src", firstLink); + window.location.hash = "#conformance"; } if (buttonId == "ktp") { - $("#landscape").attr("src",secondLink); - window.location.hash = "#ktp"; + $("#landscape").attr("src", secondLink); + window.location.hash = "#ktp"; } } // Automatically load the correct iframe based on the URL fragment - document.addEventListener('DOMContentLoaded', function() { + document.addEventListener("DOMContentLoaded", function() { var showContent = "kcsp"; if (window.location.hash) { - console.log('hash is:', window.location.hash.substring(1)); - showContent = window.location.hash.substring(1); + console.log("hash is:", window + .location + .hash + .substring(1)); + showContent = window + .location + .hash + .substring(1); } updateSrc(showContent); }); -</script> -<body> - <div id="frameHolder"> - <iframe id="landscape" title="CNCF Landscape" frameBorder="0" scrolling="no" style="width: 1px; min-width: 100%" src=""></iframe> - <script src="https://landscape.cncf.io/iframeResizer.js"></script> - </div> -</body> - </main> + </script> + <body> + <div id="frameHolder"> + <iframe frameborder="0" id="landscape" scrolling="no" src="" style="width: 1px; min-width: 100%" title="CNCF Landscape"></iframe> + <script src="https://landscape.cncf.io/iframeResizer.js"></script> + </div> + </body> + </main> </section> <style> diff --git a/content/no/_index.html b/content/no/_index.html index 2fd2ca258a..512747ac67 100644 --- a/content/no/_index.html +++ b/content/no/_index.html @@ -4,7 +4,6 @@ abstract: "Automatisert kontainer-deployment og -administrasjon" cid: home --- -{{< deprecationwarning >}} {{< blocks/section id="oceanNodes" >}} {{% blocks/feature image="flower" %}} @@ -60,4 +59,4 @@ Litt tekst. {{< blocks/kubernetes-features >}} -{{< blocks/case-studies >}} +{{< blocks/case-studies >}} \ No newline at end of file diff --git a/content/pl/docs/concepts/_index.md b/content/pl/docs/concepts/_index.md index f1eb3cd621..ec7abd87ce 100644 --- a/content/pl/docs/concepts/_index.md +++ b/content/pl/docs/concepts/_index.md @@ -41,7 +41,7 @@ Kubernetes zawiera także obiekty abstrakcyjne wyższego poziomu, zbudowane z ob * [DaemonSet](/docs/concepts/workloads/controllers/daemonset/) * [StatefulSet](/docs/concepts/workloads/controllers/statefulset/) * [ReplicaSet](/docs/concepts/workloads/controllers/replicaset/) - * [Job](/docs/concepts/workloads/controllers/jobs-run-to-completion/) + * [Job](/docs/concepts/workloads/controllers/job/) ## Warstwa sterowania (*Kubernetes Control Plane*) {#warstwa-sterowania} @@ -65,7 +65,7 @@ Węzły klastra to maszyny (wirtualne, fizyczne i in.), na których uruchamiane Jeśli chcesz dodać stronę z nowym pojęciem, odwiedź -[Jak używać szablonu strony](/docs/home/contribute/page-templates/) -aby dowiedzieć się o tworzeniu stron opisujących pojęcia i o dostępnych szablonach. +[Page Content Types](/docs/contribute/style/page-content-types/#concept), +aby dowiedzieć się o tworzeniu stron opisujących pojęcia. diff --git a/content/pl/docs/concepts/overview/kubernetes-api.md b/content/pl/docs/concepts/overview/kubernetes-api.md index 9126c6cfa3..e13a77196f 100644 --- a/content/pl/docs/concepts/overview/kubernetes-api.md +++ b/content/pl/docs/concepts/overview/kubernetes-api.md @@ -9,17 +9,13 @@ card: <!-- overview --> -Ogólne reguły dotyczące API opisane są w dokumentacji [API conventions](https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md). +Sercem {{< glossary_tooltip text="warstwy sterowania" term_id="control-plane" >}} Kubernetes +jest {{< glossary_tooltip text="serwer API" term_id="kube-apiserver" >}}. Serwer udostępnia +API poprzez HTTP, umożliwiając wzajemną komunikację pomiędzy użytkownikami, częściami składowymi klastra i komponentami zewnętrznymi. -Punkty dostępowe *(endpoints)* API, typy zasobów oraz przykłady są dostępne w [API Reference](/docs/reference). +API Kubernetes pozwala na sprawdzanie i zmianę stanu obiektów (przykładowo: pody, _Namespaces_, _ConfigMaps_, _Events_). -Zdalny dostęp do API omówiono w dokumentacji [Controlling API Access](/docs/reference/access-authn-authz/controlling-access/). - -API Kubernetes to także podstawa deklaratywnego schematu konfiguracji dla systemu. Obiekty API mogą być tworzone, zmieniane, kasowane i odpytywane sa pomocą narzędzia linii poleceń [kubectl](/docs/reference/kubectl/overview/). - -Kubernetes przechowuje także swój serializowany stan (obecnie w [etcd](https://coreos.com/docs/distributed-configuration/getting-started-with-etcd/)) w postaci obiektów API. - -Kubernetes jako taki składa się z wielu elementów składowych, które komunikują się ze sobą poprzez swoje API. +Punkt dostępowe _(endpoints)_ API, typy zasobów i przykłady opisane są w [API Reference](/docs/reference/kubernetes-api/). @@ -28,48 +24,76 @@ Kubernetes jako taki składa się z wielu elementów składowych, które komunik ## Zmiany w API -Z naszego doświadczenia wynika, że każdy system, który odniósł sukces, musi się nieustająco rozwijać w miarę zmieniających się potrzeb. Dlatego oczekujemy, że API też będzie się zmieniało i rozrastało. W dłuższym horyzoncie nie planujemy jednak żadnych zmian, które mogą być niezgodne z istniejącymi klientami. W ogólności, nowe zasoby i pola definiujące zasoby API są dodawane stosunkowo często. Usuwanie zasobów lub pól jest regulowane przez [API deprecation policy](/docs/reference/using-api/deprecation-policy/). +Jednym z wymagań, które odnoszą się do każdego systemu, który odniósł sukces, jest zdolność do rozwoju i ewolucji w miarę pojawiających się i zmieniających potrzeb. +Dlatego Kubernetes został zaprojektowany tak, aby umożliwić ciągły rozwój i zmiany w API. +Celem projektu Kubernetes jest _zachowanie_ zgodności z istniejącymi klientami i utrzymanie tej zgodności +przez odpowiednio długi czas, pozwalający innym projektom na stopniowe dostosowanie. -Definicja zmiany zgodnej (kompatybilnej) oraz metody wprowadzania zmian w API opisano w szczegółach w [API change document](https://git.k8s.io/community/contributors/devel/sig-architecture/api_changes.md). +W skrócie, nowe zasoby API i nowe pola dla konkretnych zasobów mogą być dodawane stosunkowo często. +Usunięcie zasobów lub pól wymaga stosowania +[API deprecation policy](/docs/reference/using-api/deprecation-policy/). -## Definicje OpenAPI i Swagger +Szczegółowe objaśnienia, jak wygląda zmiana, która zachowuje zgodność i jak zmieniać API, znajdują się w dokumencie +[API changes](https://git.k8s.io/community/contributors/devel/sig-architecture/api_changes.md#readme). -Pełne szczegóły API są udokumentowane zgodnie z [OpenAPI](https://www.openapis.org/). +## Specyfikacja OpenAPI {#api-specification} -Począwszy od Kubernetes w wersji 1.10, serwer Kubernetes API dostarcza specyfikację OpenAPI poprzez punkt końcowy `/openapi/v2`. -Wymagany format określa się w nagłówkach HTTP: +Pełną specyfikację API udokumentowano za pomocą [OpenAPI](https://www.openapis.org/). -Nagłówek | Dopuszczalne wartości ------- | --------------- -Accept | `application/json`, `application/com.github.proto-openapi.spec.v2@v1.0+protobuf` (domyślnie content-type to `application/json` dla `*/*` lub pominięcie tego nagłówka) -Accept-Encoding | `gzip` (pominięcie nagłówka jest dozwolone) +Serwer API Kubernetes API udostępnia specyfikację OpenAPI poprzez ścieżkę `/openapi/v2`. +Aby wybrać format odpowiedzi, użyj nagłówków żądania zgodnie z: -W wersjach wcześniejszych niż 1.14, punkty końcowe określone przez ich format (`/swagger.json`, `/swagger-2.0.0.json`, `/swagger-2.0.0.pb-v1`, `/swagger-2.0.0.pb-v1.gz`) udostępniały specyfikację OpenAPI zgodnie z tymi formatami. Te punkty końcowe były stopniowo wycofywane i ostatecznie usunięte w wersji 1.14 Kubernetes. - -**Przykłady pobierania specyfikacji OpenAPI**: - -Przed 1.10 | Kubernetes 1.10 i nowszy ------------ | ----------------------------- -GET /swagger.json | GET /openapi/v2 **Accept**: application/json -GET /swagger-2.0.0.pb-v1 | GET /openapi/v2 **Accept**: application/com.github.proto-openapi.spec.v2@v1.0+protobuf -GET /swagger-2.0.0.pb-v1.gz | GET /openapi/v2 **Accept**: application/com.github.proto-openapi.spec.v2@v1.0+protobuf **Accept-Encoding**: gzip +<table> + <thead> + <tr> + <th>Nagłówek</th> + <th style="min-width: 50%;">Dopuszczalne wartości</th> + <th>Uwagi</th> + </tr> + </thead> + <tbody> + <tr> + <td><code>Accept-Encoding</code></td> + <td><code>gzip</code></td> + <td><em>pominięcie tego nagłówka jest dozwolone</em></td> + </tr> + <tr> + <td rowspan="3"><code>Accept</code></td> + <td><code>application/com.github.proto-openapi.spec.v2@v1.0+protobuf</code></td> + <td><em>głównie do celu komunikacji wewnątrz klastra</em></td> + </tr> + <tr> + <td><code>application/json</code></td> + <td><em>domyślne</em></td> + </tr> + <tr> + <td><code>*</code></td> + <td><em>udostępnia </em><code>application/json</code></td> + </tr> + </tbody> + <caption>Dozwolone nagłówki żądań dla zapytania OpenAPI v2</caption> +</table> W Kubernetes zaimplementowany jest alternatywny format serializacji na potrzeby API oparty o Protobuf, który jest przede wszystkim przeznaczony na potrzeby wewnętrznej komunikacji w klastrze i opisany w [design proposal](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/api-machinery/protobuf.md). Pliki IDL dla każdego ze schematów można znaleźć w pakietach Go, które definiują obiekty API. -Przed wersją 1.14, apiserver Kubernetes udostępniał też specyfikację API [Swagger v1.2](http://swagger.io/) poprzez `/swaggerapi`. -Ten punkt końcowy został skierowany do wycofania i ostatecznie usunięty w wersji Kubernetes 1.14. - ## Obsługa wersji API -Aby ułatwić usuwanie poszczególnych pól lub restrukturyzację reprezentacji zasobów, Kubernetes obsługuje równocześnie wiele wersji API, każde poprzez osobną ścieżkę API, na przykład: `/api/v1` lub +Aby ułatwić usuwanie poszczególnych pól lub restrukturyzację reprezentacji zasobów, Kubernetes obsługuje +równocześnie wiele wersji API, każde poprzez osobną ścieżkę API, na przykład: `/api/v1` lub `/apis/extensions/v1beta1`. -Zdecydowaliśmy się na rozdział wersji na poziomie całego API, a nie na poziomie poszczególnych zasobów lub pól, aby być pewnym, że API odzwierciedla w sposób przejrzysty i spójny zasoby systemowe i ich zachowania i pozwala na kontrolowany dostęp do tych API, które są w fazie wycofywania lub fazie eksperymentalnej. Schematy serializacji JSON i Protobuf stosują się do tych samych reguł wprowadzania zmian schematów — cały opis poniżej odnosi się do obydwu z nich. +Zdecydowaliśmy się na rozdział wersji na poziomie całego API, a nie na poziomie poszczególnych zasobów lub pól, aby być pewnym, +że API odzwierciedla w sposób przejrzysty i spójny zasoby systemowe i ich zachowania i pozwala +na kontrolowany dostęp do tych API, które są w fazie wycofywania lub fazie eksperymentalnej. -Należy mieć na uwadze, że wersje API i wersje oprogramowania są powiązane ze sobą w sposób niebezpośredni. [API and release -versioning proposal](https://git.k8s.io/community/contributors/design-proposals/release/versioning.md) opisuje związki pomiędzy zarządzaniem wersjami API i oprogramowania. +Schematy serializacji JSON i Protobuf stosują się do tych samych reguł wprowadzania zmian schematów — cały opis poniżej odnosi się do obydwu z nich. -Różne wersje API oznaczają inną stabilność i poziom wsparcia. Kryteria dla każdego z tych poziomów opisano szczegółowo w [API Changes documentation](https://git.k8s.io/community/contributors/devel/sig-architecture/api_changes.md#alpha-beta-and-stable-versions). Podsumowanie zamieszczono poniżej poniżej: +Należy mieć na uwadze, że wersje API i wersje oprogramowania są powiązane ze sobą w sposób niebezpośredni. Proponowany +[Kubernetes Release Versioning](https://git.k8s.io/community/contributors/design-proposals/release/versioning.md) opisuje związki pomiędzy zarządzaniem wersjami API i oprogramowania. + +Różne wersje API oznaczają inną stabilność i poziom wsparcia. Kryteria dla każdego z tych poziomów opisano szczegółowo +w [API Changes documentation](https://git.k8s.io/community/contributors/devel/sig-architecture/api_changes.md#alpha-beta-and-stable-versions). +Podsumowanie zamieszczono poniżej: - Poziom Alfa: - Nazwa wersji zawiera słowo `alpha` (np. `v1alpha1`). @@ -81,8 +105,11 @@ Różne wersje API oznaczają inną stabilność i poziom wsparcia. Kryteria dla - Nazwa wersji zawiera słowo `beta` (np. `v2beta3`). - Oprogramowanie jest dobrze przetestowane. Włączenie tej funkcjonalności uznaje się za bezpieczne. Funkcjonalność domyślnie włączona. - Wsparcie dla funkcjonalności będzie utrzymywane, choć może zmieniać się w niektórych szczegółach. - - Schemat lub semantyka obiektu może się zmienić w sposób niezgodny z poprzednimi wersjami w następnych wydaniach beta lub stabilnych. Jeśli taka zmiana będzie miała miejsce, dostarczymy instrukcję migracji do kolejnej wersji. Możemy wymagać skasowania, zmiany i odtworzenia obiektów API. Proces zmiany może wymagać dodatkowych wstępnych analiz. W czasie wprowadzania zmian mogą wystąpić przerwy w dostępności aplikacji, które z tej funkcjonalności korzystają. - - Rekomendowane tylko dla zastosowań niekrytycznych dla biznesu ze względu na potencjalnie niezgodne zmiany w kolejnych wersjach oprogramowania. Jeśli masz wiele klastrów, które mogą być aktualizowane niezależnie, można to ograniczenie pominąć. + - Schemat lub semantyka obiektu może się zmienić w sposób niezgodny z poprzednimi wersjami w następnych wydaniach beta lub stabilnych. Jeśli taka zmiana będzie miała miejsce, + dostarczymy instrukcję migracji do kolejnej wersji. Możemy wymagać skasowania, zmiany i odtworzenia obiektów API. + Proces zmiany może wymagać dodatkowych wstępnych analiz. W czasie wprowadzania zmian mogą wystąpić przerwy w dostępności aplikacji, które z tej funkcjonalności korzystają. + - Rekomendowane tylko dla zastosowań niekrytycznych dla biznesu ze względu na potencjalnie niezgodne zmiany w kolejnych wersjach oprogramowania. + Jeśli masz wiele klastrów, które mogą być aktualizowane niezależnie, można to ograniczenie pominąć. - **Testuj nasze funkcjonalności w fazie beta i zgłaszaj swoje uwagi! Po wyjściu z fazy beta, możemy nie mieć już możliwości — ze względów praktycznych — wprowadzać w nich żadnych zmian.** - Poziom Stabilny: - Nazwa wersji jest w postaci `vX`, gdzie `X` jest liczbą naturalną. @@ -111,18 +138,35 @@ API może być rozbudowane na dwa sposoby przy użyciu [custom resources](/docs/ ## Włączanie i wyłączanie grup API Określone zasoby i grupy API są włączone domyślnie. Włączanie i wyłączanie odbywa się poprzez ustawienie `--runtime-config` -w apiserwerze. `--runtime-config` przyjmuje wartości oddzielane przecinkami. Przykładowo, aby wyłączyć batch/v1, należy ustawić +w kube-apiserver. + +`--runtime-config` przyjmuje wartości oddzielane przecinkami. Przykładowo, aby wyłączyć batch/v1, należy ustawić `--runtime-config=batch/v1=false`, aby włączyć batch/v2alpha1, należy ustawić `--runtime-config=batch/v2alpha1`. -Ta opcja przyjmuje rozdzielony przecinkami zbiór par klucz=wartość, który opisuje konfigurację wykonawczą apiserwera. +Ta opcja przyjmuje rozdzielony przecinkami zbiór par klucz=wartość, który opisuje konfigurację wykonawczą serwera API. -{{< note >}}Włączenie lub wyłączenie grup lub zasobów wymaga restartu apiserver i controller-manager, aby zmiany w `--runtime-config` zostały wprowadzone.{{< /note >}} +{{< note >}}Włączenie lub wyłączenie grup lub zasobów wymaga restartu kube-apiserver i kube-controller-manager, +aby zmiany w `--runtime-config` zostały wprowadzone.{{< /note >}} -## Jak włączać dostęp do grup zasobów extensions/v1beta1 +## Dostęp do grup zasobów _extensions/v1beta1_ -DaemonSets, Deployments, HorizontalPodAutoscalers, Ingresses, Jobs i ReplicaSets znajdują się w grupie API `extensions/v1beta1` i są domyślnie włączone. +DaemonSets, Deployments, HorizontalPodAutoscalers, Ingresses, Jobs i ReplicaSets znajdują się w grupie API `extensions/v1beta1` i są domyślnie wyłączone. Przykładowo: aby włączyć deployments i daemonsets, ustaw `--runtime-config=extensions/v1beta1/deployments=true,extensions/v1beta1/daemonsets=true`. {{< note >}}Włączanie i wyłączanie pojedynczych zasobów możliwe jest jedynie w ramach grupy API `extensions/v1beta1` z przyczyn historycznych{{< /note >}} +## Trwałość +Kubernetes przechowuje swój stan w postaci serializowanej jako zasoby API zapisywane w +{{< glossary_tooltip term_id="etcd" >}}. + + +## {{% heading "whatsnext" %}} + +[Controlling API Access](/docs/reference/access-authn-authz/controlling-access/) opisuje +sposoby, jakimi klaster zarządza dostępem do API. + +Ogólne wytyczne dotyczące API opisano w +[API conventions](https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#api-conventions). + +Punkty dostępowe API _(endpoints)_, typy zasobów i przykłady zamieszczono w [API Reference](/docs/reference/kubernetes-api/). diff --git a/content/pl/docs/concepts/overview/what-is-kubernetes.md b/content/pl/docs/concepts/overview/what-is-kubernetes.md index fcb8f7714c..861476a561 100644 --- a/content/pl/docs/concepts/overview/what-is-kubernetes.md +++ b/content/pl/docs/concepts/overview/what-is-kubernetes.md @@ -73,7 +73,7 @@ Kubernetes pozwala składować i zarządzać informacjami poufnymi, takimi jak h ## Czym Kubernetes nie jest -Kubernetes nie jest tradycyjnym, zawierającym wszystko systemem PaaS *(Platform as a Service)*. Ponieważ Kubernetes działa w warstwie kontenerów, a nie sprzętu, posiada różne funkcjonalności ogólnego zastosowania, wspólne dla innych rozwiązań PaaS, takie jak: instalacje *(deployments)*, skalowanie, balansowanie ruchu, logowanie i monitoring. Co ważne, Kubernetes nie jest monolitem i te domyślnie dostępne rozwiązania są opcjonalne i działają jako wtyczki. Kubernetes dostarcza elementy, z których może być zbudowana platforma deweloperska, ale pozostawia użytkownikowi wybór i elastyczność tam, gdzie jest to ważne. +Kubernetes nie jest tradycyjnym, zawierającym wszystko systemem PaaS *(Platform as a Service)*. Ponieważ Kubernetes działa w warstwie kontenerów, a nie sprzętu, posiada różne funkcjonalności ogólnego zastosowania, wspólne dla innych rozwiązań PaaS, takie jak: instalacje *(deployments)*, skalowanie i balansowanie ruchu, umożliwiając użytkownikom integrację rozwiązań służących do logowania, monitoringu i ostrzegania. Co ważne, Kubernetes nie jest monolitem i domyślnie dostępne rozwiązania są opcjonalne i działają jako wtyczki. Kubernetes dostarcza elementy, z których może być zbudowana platforma deweloperska, ale pozostawia użytkownikowi wybór i elastyczność tam, gdzie jest to ważne. Kubernetes: diff --git a/content/pl/docs/tutorials/_index.md b/content/pl/docs/tutorials/_index.md index 19e4bf8d24..0f9d7ac723 100644 --- a/content/pl/docs/tutorials/_index.md +++ b/content/pl/docs/tutorials/_index.md @@ -69,8 +69,8 @@ Przed zapoznaniem się z samouczkami warto stworzyć zakładkę do ## {{% heading "whatsnext" %}} -Jeśli chciałbyś napisać nowy samouczek, zajrzyj na stronę -[Jak używać szablonów stron](/docs/home/contribute/page-templates/) -gdzie znajdziesz dodatkowe informacje na temat stron i szablonów samouczków. +Jeśli chciałbyś napisać nowy samouczek, odwiedź +[Content Page Types](/docs/contribute/style/page-content-types/), +gdzie znajdziesz dodatkowe informacje o tym typie strony. diff --git a/content/pt/_index.html b/content/pt/_index.html index 62cfd340d4..8f1fbd9658 100644 --- a/content/pt/_index.html +++ b/content/pt/_index.html @@ -4,7 +4,6 @@ abstract: "Implantação, dimensionamento e gerenciamento automatizado de contê cid: home --- -{{< deprecationwarning >}} {{< blocks/section id="oceanNodes" >}} {{% blocks/feature image="flower" %}} @@ -59,4 +58,4 @@ O Kubernetes é Open Source, o que te oferece a liberdade de utilizá-lo em seu {{< blocks/kubernetes-features >}} -{{< blocks/case-studies >}} +{{< blocks/case-studies >}} \ No newline at end of file diff --git a/content/pt/docs/concepts/_index.md b/content/pt/docs/concepts/_index.md new file mode 100644 index 0000000000..62b2457c71 --- /dev/null +++ b/content/pt/docs/concepts/_index.md @@ -0,0 +1,16 @@ +--- +title: Conceitos +main_menu: true +content_type: concept +weight: 40 +--- + +<!-- overview --> + +A seção de Conceitos irá te ajudar a aprender mais sobre as partes do ecossistema Kubernetes e as abstrações que o Kubernetes usa para representar seu {{< glossary_tooltip text="cluster" term_id="cluster" length="all" >}}. + +Ela irá lhe ajudar a obter um entendimento mais profundo sobre como o Kubernetes funciona. + + + +<!-- body --> diff --git a/content/pt/docs/reference/glossary/cluster.md b/content/pt/docs/reference/glossary/cluster.md new file mode 100644 index 0000000000..49e8ae15d6 --- /dev/null +++ b/content/pt/docs/reference/glossary/cluster.md @@ -0,0 +1,18 @@ +--- +title: Cluster +id: cluster +date: 2020-08-03 +full_link: +short_description: > + Um conjunto de servidores de processamento, também chamados de nós, que executam aplicações containerizadas. Todo cluster possui ao menos um servidor de processamento (worker node). + +aka: +tags: +- fundamental +- operation +--- +Um conjunto de servidores de processamento, chamados {{< glossary_tooltip text="nós" term_id="node" >}}, que executam aplicações containerizadas. Todo cluster possui ao menos um servidor de processamento (_worker node_). + +<!--more--> +O servidor de processamento hospeda os {{< glossary_tooltip text="Pods" term_id="pod" >}} que são componentes de uma aplicação. O {{< glossary_tooltip text="ambiente de gerenciamento" term_id="control-plane" >}} gerencia os nós de processamento e os Pods no cluster. Em ambientes de produção, o ambiente de gerenciamento geralmente executa em múltiplos computadores e um cluster geralmente executa em múltiplos nós (_nodes_) , provendo tolerância a falhas e alta disponibilidade. + diff --git a/content/pt/docs/reference/glossary/control-plane.md b/content/pt/docs/reference/glossary/control-plane.md index 4befb3bb05..0465d5a2b8 100644 --- a/content/pt/docs/reference/glossary/control-plane.md +++ b/content/pt/docs/reference/glossary/control-plane.md @@ -1,5 +1,5 @@ --- -title: Control Plane +title: Ambiente de gerenciamento id: control-plane date: 2020-04-19 full_link: diff --git a/content/pt/docs/reference/glossary/node.md b/content/pt/docs/reference/glossary/node.md index 37c88c0343..536748f134 100755 --- a/content/pt/docs/reference/glossary/node.md +++ b/content/pt/docs/reference/glossary/node.md @@ -1,17 +1,17 @@ --- -title: Node +title: Nó id: node date: 2020-04-19 full_link: /docs/concepts/architecture/nodes/ short_description: > - Um Node é uma máquina de trabalho no Kubernetes. + Um Nó é uma máquina de trabalho no Kubernetes. aka: tags: - fundamental --- - Um Node é uma máquina de trabalho no Kubernetes. + Um Nó é uma máquina de trabalho no Kubernetes. <!--more--> -Um Node pode ser uma máquina virtual ou física, dependendo do cluster. Possui daemons ou serviços locais necessários para executar {{< glossary_tooltip text="Pods" term_id="pod" >}} e é gerenciado pelo {{< glossary_tooltip text="plano de controle" term_id="control-plane" >}}. Os daemons em um Node incluem {{< glossary_tooltip text="kubelet" term_id="kubelet" >}}, {{< glossary_tooltip text="kube-proxy" term_id="kube-proxy" >}} e um contêiner runtime implementando o {{< glossary_tooltip text="CRI" term_id="cri" >}} como por exemplo o {{< glossary_tooltip term_id="docker" >}}. \ No newline at end of file +Um Nó pode ser uma máquina virtual ou física, dependendo do cluster. Possui daemons ou serviços locais necessários para executar {{< glossary_tooltip text="Pods" term_id="pod" >}} e é gerenciado pelo {{< glossary_tooltip text="ambiente de gerenciamento" term_id="control-plane" >}}. Os daemons em um Node incluem {{< glossary_tooltip text="kubelet" term_id="kubelet" >}}, {{< glossary_tooltip text="kube-proxy" term_id="kube-proxy" >}} e um contêiner runtime implementando o {{< glossary_tooltip text="CRI" term_id="cri" >}} como por exemplo o {{< glossary_tooltip term_id="docker" >}}. \ No newline at end of file diff --git a/content/pt/docs/setup/_index.md b/content/pt/docs/setup/_index.md new file mode 100644 index 0000000000..a63307026f --- /dev/null +++ b/content/pt/docs/setup/_index.md @@ -0,0 +1,40 @@ +--- +no_issue: true +title: Instalação +main_menu: true +weight: 30 +content_type: concept +--- + +<!-- overview --> + +Essa seção lista as diferentes formas de instalar e executar o Kubernetes. Quando você realiza a instalação de um cluster Kubernetes, deve decidir o tipo de instalação baseado em critérios como facilidade de manutenção, segurança, controle, quantidade de recursos disponíveis e a experiência necessária para gerenciar e operar o cluster. + +Você pode criar um cluster Kubernetes em uma máquina local, na nuvem, em um datacenter on-premises ou ainda escolher uma oferta de um cluster Kubernetes gerenciado pelo seu provedor de computação em nuvem. + +Existem ainda diversos outros tipos de soluções customizadas, que você pode se deparar ao buscar formas de instalação e gerenciamento de seu cluster. + +<!-- body --> + +## Ambientes de aprendizado + +Se você está aprendendo ou pretende aprender mais sobre o Kubernetes, use ferramentas suportadas pela comunidade, ou ferramentas no ecossistema que te permitam criar um cluster Kubernetes em sua máquina virtual. + +Temos como exemplo aqui o [Minikube](/docs/tasks/tools/install-minikube/) e o [KinD](https://kind.sigs.k8s.io/docs/user/quick-start/) + + +## Ambientes de produção + +Ao analisar uma solução para um ambiente de produção, devem ser considerados quais aspectos de operação de um cluster Kubernetes você deseja gerenciar, ou então delegar ao seu provedor. + +Temos diversas opções para esse provisionamento, desde o uso de uma ferramenta de deployment de um cluster tal qual o [Kubeadm](/docs/setup/production-environment/tools/kubeadm/install-kubeadm/) ou o [Kubespray](/docs/setup/production-environment/tools/kubespray/) quando se trata de um cluster local, ou ainda o uso de um cluster gerenciado por seu provedor de nuvem. + +Para a escolha do melhor ambiente e da melhor forma para fazer essa instalação, você deve considerar: + +* Se você deseja se preocupar com a gestão de backup da sua estrutura do ambiente de gerenciamento +* Se você deseja ter um cluster mais atualizado, com novas funcionalidades, ou se deseja seguir a versão suportada pelo fornecedor +* Se você deseja ter um cluster com um alto nível de serviço, ou com auto provisionamento de alta disponibilidade +* Quanto você deseja pagar por essa produção + + + diff --git a/content/pt/docs/tasks/_index.md b/content/pt/docs/tasks/_index.md new file mode 100644 index 0000000000..d36248475c --- /dev/null +++ b/content/pt/docs/tasks/_index.md @@ -0,0 +1,15 @@ +--- +title: Tarefas +main_menu: true +weight: 50 +content_type: concept +--- + +<!-- overview --> + +Essa seção da documentação contém páginas que mostram como executar tarefas individuais. + +Essas tarefas são organizadas em uma curta sequência de etapas e passos que te auxiliam a entender conceitos básicos. + +Se você desejar adicionar uma tarefa, verifique como +[criar um Pull Request para a documentação](/docs/contribute/new-content/open-a-pr/). diff --git a/content/pt/docs/tutorials/_index.md b/content/pt/docs/tutorials/_index.md new file mode 100644 index 0000000000..85941bc187 --- /dev/null +++ b/content/pt/docs/tutorials/_index.md @@ -0,0 +1,68 @@ +--- +title: Tutoriais +main_menu: true +no_list: true +weight: 60 +content_type: concept +--- + +<!-- overview --> + +Essa seção da documentação contém tutoriais (em inglês). Um tutorial mostra como realizar um objetivo mais complexo que uma simples [tarefa](/docs/tasks/). Eles podem ser divididos em diversas seções, cada uma com uma sequência de passos e etapas a serem seguidos. + +Antes de iniciar um tutorial, é interessante que vocẽ salve a página de [Glossário](/pt/docs/reference/glossary/) para futuras referências. + + +<!-- body --> + +## Básicos + +* [Kubernetes básico](/docs/tutorials/kubernetes-basics/) é um tutorial interativo que auxilia no entendimento do ecossistema Kubernetes, bem como te permite testar algumas funcionalidades básicas do Kubernetes. + +* [Introdução ao Kubernetes (edX)](https://www.edx.org/course/introduction-kubernetes-linuxfoundationx-lfs158x#) é um curso gratuíto da edX que te guia no entendimento do Kubernetes, seus conceitos, bem como na execução de tarefas mais simples. + +* [Hello Minikube](/docs/tutorials/hello-minikube/) é um "Hello World" que te permite testar rapidamente o Kubernetes em sua estação com o uso do Minikube + +## Configuração + +* [Configurando o Redis usando um ConfigMap](/docs/tutorials/configuration/configure-redis-using-configmap/) + +## Aplicações stateless + +* [Expondo um Endereço de IP externo para acessar uma aplicação no Cluster](/docs/tutorials/stateless-application/expose-external-ip-address/) + +* [Exemplo: Implantando a aplicação de Livro de Visitas (Guestbook) em PHP com Redis](/docs/tutorials/stateless-application/guestbook/) + +## Aplicações stateful + +* [Básicos sobre StatefulSet](/docs/tutorials/stateful-application/basic-stateful-set/) + +* [Exemplo: WordPress e MySQL com Volumes Persistentes](/docs/tutorials/stateful-application/mysql-wordpress-persistent-volume/) + +* [Exemplo: Implantando Cassandra com Stateful Sets](/docs/tutorials/stateful-application/cassandra/) + +* [Executando ZooKeeper no Kubernetes](/docs/tutorials/stateful-application/zookeeper/) + +## Pipelines de CI/CD + +* [Configurando um Pipeline CI/CD com Kubernetes Parte 1: Visão Geral](https://www.linux.com/blog/learn/chapter/Intro-to-Kubernetes/2017/5/set-cicd-pipeline-kubernetes-part-1-overview) + +* [Configurando um Pipeline CI/CD com um Pod Jenkins no Kubernetes (Parte 2)](https://www.linux.com/blog/learn/chapter/Intro-to-Kubernetes/2017/6/set-cicd-pipeline-jenkins-pod-kubernetes-part-2) + +* [Executando e escalando um aplicativo distribuído de palavras cruzadas com CI/CD no Kubernetes (Parte 3)](https://www.linux.com/blog/learn/chapter/intro-to-kubernetes/2017/6/run-and-scale-distributed-crossword-puzzle-app-cicd-kubernetes-part-3) + +* [Configurando um CI/CD para um aplicativo distribuído de palavras cruzadas no Kubernetes (Parte 4)](https://www.linux.com/blog/learn/chapter/intro-to-kubernetes/2017/6/set-cicd-distributed-crossword-puzzle-app-kubernetes-part-4) + +## Clusters + +* [AppArmor](/docs/tutorials/clusters/apparmor/) + +## Serviços / "Services" + +* [Usando IP de origem](/docs/tutorials/services/source-ip/) + +## {{% heading "whatsnext" %}} + +Se você desejar escrever um tutorial, veja a página +[Utilizando templates](/docs/home/contribute/page-templates/) +para informações sobre o tipo de página e o formato a ser utilizado. diff --git a/content/ru/_index.html b/content/ru/_index.html index fc38ae6c02..7298da03f4 100644 --- a/content/ru/_index.html +++ b/content/ru/_index.html @@ -4,8 +4,6 @@ abstract: "Автоматизированное развёртывание, ма cid: home --- -{{< deprecationwarning >}} - {{< blocks/section id="oceanNodes" >}} {{% blocks/feature image="flower" %}} ### [Kubernetes (K8s)]({{< relref "/docs/concepts/overview/what-is-kubernetes" >}}) - это открытое программное обеспечение для автоматизации развёртывания, масштабирования и управления контейнеризированными приложениями. @@ -43,7 +41,6 @@ Kubernetes — это проект с открытым исходным кодо <button id="desktopShowVideoButton" onclick="kub.showVideo()">Смотреть видео</button> <br> <br> - <br> <a href="https://events.linuxfoundation.org/events/kubecon-cloudnativecon-europe-2020/" button id="desktopKCButton">Посетите KubeCon в Амстердаме, с 30 марта по 2 апреля 2020</a> <br> <br> @@ -59,4 +56,4 @@ Kubernetes — это проект с открытым исходным кодо {{< blocks/kubernetes-features >}} -{{< blocks/case-studies >}} +{{< blocks/case-studies >}} \ No newline at end of file diff --git a/content/ru/docs/concepts/architecture/_index.md b/content/ru/docs/concepts/architecture/_index.md new file mode 100755 index 0000000000..eb68a67e53 --- /dev/null +++ b/content/ru/docs/concepts/architecture/_index.md @@ -0,0 +1,5 @@ +--- +title: "Кластерная Архитектура" +weight: 30 +--- + diff --git a/content/ru/docs/concepts/architecture/nodes.md b/content/ru/docs/concepts/architecture/nodes.md new file mode 100644 index 0000000000..7c10f75e1b --- /dev/null +++ b/content/ru/docs/concepts/architecture/nodes.md @@ -0,0 +1,340 @@ +--- +reviewers: +- caesarxuchao +- dchen1107 +title: Узлы +content_template: concept +weight: 10 +--- + +<!-- overview --> + +Kubernetes запускает ваши приложения, помещая контейнеры в Поды для запуска на Узлах (_Nodes_). +В зависимости от кластера, узел может быть виртуальной или физической машиной. Каждый узел +содержит сервисы, необходимые для запуска +{{< glossary_tooltip text="Подов" term_id="pod" >}}, управляемых +{{< glossary_tooltip text="плоскостью управления" term_id="control-plane" >}}. + +Обычно у вас есть несколько узлов в кластере; однако в среде обучения или среде +с ограниченными ресурсами у вас может быть только один. + +[Компоненты](/ru/docs/concepts/overview/components/##компоненты-узла) на узле включают +{{< glossary_tooltip text="kubelet" term_id="kubelet" >}}, +{{< glossary_tooltip text="среду выполнения контейнера" term_id="container-runtime" >}} и +{{< glossary_tooltip text="kube-proxy" term_id="kube-proxy" >}}. + +<!-- body --> + +## Управление + +Существует два основных способа добавления Узлов в {{< glossary_tooltip text="API сервер" term_id="kube-apiserver" >}}: + +1. Kubelet на узле саморегистрируется в плоскости управления +2. Вы или другой пользователь вручную добавляете объект Узла + +После того, как вы создадите объект Узла или kubelet на узле самозарегистируется, +плоскость управления проверяет, является ли новый объект Узла валидным (правильным). Например, если вы +попробуете создать Узел при помощи следующего JSON манифеста: + +```json +{ + "kind": "Node", + "apiVersion": "v1", + "metadata": { + "name": "10.240.79.157", + "labels": { + "name": "my-first-k8s-node" + } + } +} +``` + +Kubernetes создает внутри себя объект Узла (представление). Kubernetes проверяет, +что kubelet зарегистрировался на API сервере, который совпадает с значением поля `metadata.name` Узла. +Если узел здоров (если все необходимые сервисы запущены), +он имеет право на запуск Пода. В противном случае, этот узел игнорируется для любой активности кластера +до тех пор, пока он не станет здоровым. + +{{< note >}} +Kubernetes сохраняет объект для невалидного Узла и продолжает проверять, становится ли он здоровым. + +Вы или {{< glossary_tooltip term_id="controller" text="контроллер">}} должны явно удалить объект Узла, чтобы +остановить проверку доступности узла. +{{< /note >}} + +Имя объекта Узла дожно быть валидным +[именем поддомена DNS](/ru/docs/concepts/overview/working-with-objects/names#имена-поддоменов-dns). + +### Саморегистрация Узлов + +Когда kubelet флаг `--register-node` имеет значение _true_ (по умолчанию), то kubelet будет пытаться +зарегистрировать себя на API сервере. Это наиболее предпочтительная модель, используемая большиством дистрибутивов. + +Для саморегистрации kubelet запускается со следующими опциями: + + - `--kubeconfig` - Путь к учетным данным для аутентификации на API сервере. + - `--cloud-provider` - Как общаться с {{< glossary_tooltip text="облачным провайдером" term_id="cloud-provider" >}}, чтобы прочитать метаданные о себе. + - `--register-node` - Автоматически зарегистрироваться на API сервере. + - `--register-with-taints` - Зарегистрировать узел с приведенным списком {{< glossary_tooltip text="ограничений (taints)" term_id="taint" >}} (разделенных запятыми `<key>=<value>:<effect>`). + + Ничего не делает, если `register-node` - _false_. + - `--node-ip` - IP-адрес узла. + - `--node-labels` - {{< glossary_tooltip text="Метки" term_id="label" >}} для добавления при регистрации узла в кластере (смотрите ограничения для меток, установленные [плагином согласования (admission plugin) NodeRestriction](/docs/reference/access-authn-authz/admission-controllers/#noderestriction)). + - `--node-status-update-frequency` - Указывает, как часто kubelet отправляет статус узла мастеру. + +Когда [режим авторизации Узла](/docs/reference/access-authn-authz/node/) и +[плагин согласования NodeRestriction](/docs/reference/access-authn-authz/admission-controllers/#noderestriction) включены, +kubelet'ы имеют право только создавать/изменять свой собственный ресурс Узла. + +### Ручное администрирование узла + +Вы можете создавать и изменять объекты узла используя +{{< glossary_tooltip text="kubectl" term_id="kubectl" >}}. + +Когда вы хотите создать объекты Узла вручную, установите kubelet флаг `--register-node=false`. + +Вы можете изменять объекты Узла независимо от настройки `--register-node`. +Например, вы можете установить метки на существующем Узле или пометить его неназначаемым. + +Вы можете использовать метки на Узлах в сочетании с селекторами узла на Подах для управления планированием. +Например, вы можете ограничить Под иметь право на запуск только на группе доступных узлов. + +Маркировка узла как неназначаемого предотвращает размещение планировщиком новых подов на этом Узле, +но не влияет на существующие Поды на Узле. Это полезно в качестве +подготовительного шага перед перезагрузкой узла или другим обслуживанием. + +Чтобы отметить Узел неназначемым, выполните: + +```shell +kubectl cordon $NODENAME +``` + +{{< note >}} +Поды, являющиеся частью {{< glossary_tooltip term_id="daemonset" >}} допускают +запуск на неназначаемом Узле. DaemonSets обычно обеспечивает локальные сервисы узла, +которые должны запускаться на Узле, даже если узел вытесняется для запуска приложений. +{{< /note >}} + +## Статус Узла + +Статус узла содержит следующие данные: + +* [Адреса (Addresses)](#адреса) +* [Условия (Conditions)](#условие) +* [Емкость и Выделяемые ресурсы (Capacity and Allocatable)](#емкость) +* [Информация (Info)](#информация) + +Вы можете использовать `kubectl` для просмотра статуса Узла и других деталей: + +```shell +kubectl describe node <insert-node-name-here> +``` + +Каждая секция из вывода команды описана ниже. + +### Адреса (Addresses) + +Использование этих полей варьируется в зависимости от вашего облачного провайдера или конфигурации физических серверов (_bare metal_). + +* HostName: Имя хоста, сообщаемое ядром узла. Может быть переопределено через kubelet `--hostname-override` параметр. +* ExternalIP: Обычно, IP адрес узла, который является внешне маршрутизируемым (доступен за пределами кластера). +* InternalIP: Обычно, IP адрес узла, который маршрутизируется только внутри кластера. + +### Условия (Conditions) {#условие} + +Поле `conditions` описывает статус всех `Running` узлов. Примеры условий включают в себя: + +{{< table caption = "Условия узла и описание того, когда применяется каждое условие." >}} +| Условие Узла | Описание | +|----------------------|-------------| +| `Ready` | `True` если узел здоров и готов принять поды, `False` если узел нездоров и не принимает поды, и `Unknown` если контроллер узла не получал информацию от узла в течение последнего периода `node-monitor-grace-period` (по умолчанию 40 секунд) | +| `DiskPressure` | `True` если присутствует давление на размер диска - то есть, если емкость диска мала; иначе `False` | +| `MemoryPressure` | `True` если существует давление на память узла - то есть, если памяти на узле мало; иначе `False` | +| `PIDPressure` | `True` если существует давление на процессы - то есть, если на узле слишком много процессов; иначе `False` | +| `NetworkUnavailable` | `True` если сеть для узла настроена некорректно, иначе `False` | +{{< /table >}} + +{{< note >}} +Если вы используете инструменты командной строки для вывода сведений об блокированном узле, +то Условие включает `SchedulingDisabled`. `SchedulingDisabled` не является Условием в Kubernetes API; +вместо этого блокированные узлы помечены как Неназначемые в их спецификации. +{{< /note >}} + +Состояние узла представлено в виде JSON объекта. Например, следующая структура описывает здоровый узел: + +```json +"conditions": [ + { + "type": "Ready", + "status": "True", + "reason": "KubeletReady", + "message": "kubelet is posting ready status", + "lastHeartbeatTime": "2019-06-05T18:38:35Z", + "lastTransitionTime": "2019-06-05T11:41:27Z" + } +] +``` + +Если значение параметра Status для условия Ready остается `Unknown` или `False` +дольше чем период `pod-eviction-timeout`(аргумент, переданный в +{{< glossary_tooltip text="kube-controller-manager" term_id="kube-controller-manager" >}}), то все Поды +на узле планируются к удалению контроллером узла. По умолчанию таймаут выселения **пять минут**. +В некоторых случаях, когда узел недоступен, API сервер не может связаться с kubelet на узле. +Решение об удалении подов не может быть передано в kubelet до тех пор, пока связь с API сервером не будет восстановлена. +В то же время поды, которые запланированы к удалению, могут продолжать работать на отделенном узле. + +Контроллер узла не будет принудительно удалять поды до тех пор, пока не будет подтверждено, +что они перестали работать в кластере. Вы можете видеть, что поды, которые могут работать на недоступном узле, +находятся в состоянии `Terminating` или `Unknown`. В тех случаях, когда Kubernetes не может сделать вывод +из основной инфраструктуры о том, что узел окончательно покинул кластер, администратору кластера может потребоваться +удалить объект узла вручную. Удаление объекта узла из Kubernetes приводит к удалению всех объектов Подов, запущенных +на узле, с API сервера и освобождает их имена. + +Контроллер жизненного цикла узла автоматически создает +[ограничения (taints)](/docs/concepts/scheduling-eviction/taint-and-toleration/), которые представляют собой условия. +Планировщик учитывает ограничения Узла при назначении Пода на Узел. +Поды так же могут иметь допуски (tolerations), что позволяет им сопротивляться ограничениям Узла. + +Смотрите раздел [Ограничить Узлы по Условию](/docs/concepts/configuration/taint-and-toleration/#taint-nodes-by-condition) +для дополнительной информации. + +### Емкость и Выделяемые ресурсы (Capacity and Allocatable) {#емкость} + +Описывает ресурсы, доступные на узле: CPU, память и максимальное количество подов, +которые могут быть запланированы на узле. + +Поля в блоке capasity указывают общее количество ресурсов, которые есть на Узле. +Блок allocatable указывает количество ресурсовна Узле, +которые доступны для использования обычными Подами. + +Вы можете прочитать больше о емкости и выделяемых ресурсах, изучая, как [зарезервировать вычислительные ресурсы](/docs/tasks/administer-cluster/reserve-compute-resources/#node-allocatable) на Узле. + +### Информация (Info) + +Описывает общую информацию об узле, такую как версия ядра, версия Kubernetes (версии kubelet и kube-proxy), версия Docker (если используется) и название ОС. +Эта информация соберается Kubelet'ом на узле. + +### Контроллер узла + +{{< glossary_tooltip text="Контроллер " term_id="controller" >}} узла является компонентом +плоскости управления Kubernetes, который управляет различными аспектами узлов. + +Контроллер узла играет различные роли в жизни узла. Первая - назначение CIDR-блока узлу +при его регистрации (если включено назначение CIDR). + +Вторая - поддержание в актуальном состоянии внутреннего списка узлов контроллера узла +согласно списку доступных машин облачного провайдера. При работе в облачной среде всякий раз, +когда узел неисправен, контроллер узла запрашивает облачного провайдера, доступна ли +виртуальная машина для этого узла. Если нет, то контроллер узла удаляет узел из +своего списка узлов. + +Третья - это мониторинг работоспособности узлов. Контроллер узла +отвечает за обновление условия NodeReady для NodeStatus на +ConditionUnknown, когда узел становится недоступным (т.е. контроллер узла +по какой-то причине перестает получать сердцебиения (heartbeats) от узла, +например, из-за того, что узел упал), и затем позже выселяет все поды с узла +(используя мягкое (graceful) завершение) если узел продолжает быть недоступным. +(По умолчанию таймауты составляют 40 секунд, чтобы начать сообщать `ConditionUnknown`, +и 5 минут после, чтобы начать выселять поды.) Контроллер узла проверяет состояние каждого узла +каждые `--node-monitor-period` секунд. + +#### Сердцебиения + +Сердцебиения, посылаемые узлами Kubernetes, помогают определить доступность узла. + +Существует две формы сердцебиений: обновление `NodeStatus` и +[Lease объект](/docs/reference/generated/kubernetes-api/{{< latest-version >}}/#lease-v1-coordination-k8s-io). +Каждый узел имеет связанный с ним Lease объект в `kube-node-lease` +{{< glossary_tooltip term_id="namespace" text="namespace">}}. +Lease - это легковестный ресурс, который улучшает производительность +сердцебиений узла при масштабировании кластера. + +Kubelet отвечает за создание и обновление `NodeStatus` и Lease объекта. + +- Kubelet обновляет `NodeStatus` либо когда происходит изменение статуса, + либо если в течение настронного интервала обновления не было. По умолчанию + интервал для обновлений `NodeStatus` составляет 5 минут (намного больше, + чем 40-секундный стандартный таймаут для недоступных узлов). +- Kubelet созадет и затем обновляет свой Lease объект каждый 10 секунд + (интервал обновления по умолчанию). Lease обновления происходят независимо от + `NodeStatus` обновлений. Если обновление Lease завершается неудачно, + kubelet повторяет попытку с экспоненциальным откатом, начинающимся с 200 миллисекунд и ограниченным 7 секундами. + +#### Надежность + +В большинстве случаев контроллер узла ограничивает скорость выселения +до `--node-eviction-rate` (по умолчанию 0,1) в секунду, что означает, +что он не выселяет поды с узлов быстрее чем c 1 узела в 10 секунд. + +Поведение выселения узла изменяется, когда узел в текущей зоне доступности +становится нездоровым. Контроллер узла проверяет, какой процент узлов в зоне +нездоров (NodeReady условие в значении ConditionUnknown или ConditiononFalse) +в одно и то же время. Если доля нездоровых узлов не меньше +`--unhealthy-zone-threshold` (по умолчанию 0.55), то скорость выселения уменьшается: +если кластер небольшой (т.е. количество узлов меньше или равно +`--large-cluster-size-threshold` - по умолчанию, 50), то выселения прекращаются, +в противном случае скорость выселения снижается до +`--secondary-node-eviction-rate` (по умолчанию, 0.01) в секунду. Причина, по которой +эти политики реализуются для каждой зоны доступности, заключается в том, +что одна зона доступности может стать отделенной от мастера, в то время как другие +остаются подключенными. Если ваш кластер не охватывает несколько зон доступности +облачного провайдера, то существует только одна зона доступности (весь кластер). + +Основная причина разнесения ваших узлов по зонам доступности заключается в том, +что приложения могут быть перенесены в здоровые зоны, когда одна из зон полностью +становится недоступной. Поэтому, если все узлы в зоне нездоровы, то контроллер узла +выселяет поды с нормальной скоростью `--node-eviction-rate`. Крайний случай - когда все зоны +полностью нездоровы (т.е. в кластере нет здоровых узлов). В таком случае +контроллер узла предполагает, что существует некоторая проблема с подключением к мастеру, +и останавеливает все выселения, пока какое-нибудь подключение не будет восстановлено. + +Контроллер узла также отвечает за выселение подов, запущенных на узлах с +`NoExecute` ограничениями, за исключением тех подов, которые сопротивляются этим ограничениям. +Контроллер узла так же добавляет {{< glossary_tooltip text="ограничения" term_id="taint" >}} +соотвествующие проблемам узла, таким как узел недоступен или не готов. Это означает, +что планировщик не будет размещать поды на нездоровых узлах. + +{{< caution >}} +`kubectl cordon` помечает узел как 'неназначемый', что имеет побочный эфект от контроллера сервисов, +удаляющего узел из любых списков целей LoadBalancer узла, на которые он ранее имел право, +эффектино убирая входящий трафик балансировщика нагрузки с блокированного узла(ов). +{{< /caution >}} + +### Емкость узла + +Объекты узла отслеживают информацию о емкости ресурсов узла (например, +объем доступной памяти и количество CPU). +Узлы, которые [самостоятельно зарегистировались](#саморегистрация-узлов) сообщают +о свое емкости во время регистрации. Если вы [вручную](#ручное-администрирование-узла) +добавляете узел, то вам нужно задать информацию о емкости узла при его добавлении. + +{{< glossary_tooltip text="Планировщик" term_id="kube-scheduler" >}} Kubernetes гарантирует, +что для всех Подов на Узле достаточно ресурсов. Планировщик проверяет, +что сумма requests от контейнеров на узле не превышает емкость узла. +Эта сумма requests включает все контейнеры, управляемые kubelet, +но исключает любые контейнеры, запущенные непосредственно средой выполнения контейнера, +а также исключает любые процессы, запущенные вне контроля kubelet. + +{{< note >}} +Если вы явно хотите зарезервировать ресурсы для процессов, не связанныз с Подами, смотрите раздел +[зарезервировать ресурсы для системных демонов](/docs/tasks/administer-cluster/reserve-compute-resources/#system-reserved). +{{< /note >}} + +## Топология узла + +{{< feature-state state="alpha" for_k8s_version="v1.16" >}} + +Если вы включили `TopologyManager` +[feature gate](/docs/reference/command-line-tools-reference/feature-gates/), то kubelet +может использовать подсказки топологии при принятии решений о выделении ресурсов. +Смотрите [Контроль Политик Управления Топологией на Узле](/docs/tasks/administer-cluster/topology-manager/) +для дополнительной информации. + +## {{% heading "whatsnext" %}} + +* Подробнее про[компоненты](/ru/docs/concepts/overview/components/#компоненты-узла) из которых состоит узел. +* Подробнее про [Определение API для Узла](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#node-v1-core). +* Подробнее про [Узлы](https://git.k8s.io/community/contributors/design-proposals/architecture/architecture.md#the-kubernetes-node) + of the architecture design document. +* Подробнее про [ограничения и допуски](/docs/concepts/configuration/taint-and-toleration/). +* Подробнее про [автомаштабирование кластера](/docs/tasks/administer-cluster/cluster-management/#cluster-autoscaling). diff --git a/content/ru/docs/home/supported-doc-versions.md b/content/ru/docs/home/supported-doc-versions.md index fc7dd13762..66bde1b9fc 100644 --- a/content/ru/docs/home/supported-doc-versions.md +++ b/content/ru/docs/home/supported-doc-versions.md @@ -20,7 +20,7 @@ card: Текущая версия: [{{< param "version" >}}](/). -##Предыдущие версии +## Предыдущие версии {{< versions-other >}} diff --git a/content/ru/docs/reference/glossary/cloud-provider.md b/content/ru/docs/reference/glossary/cloud-provider.md new file mode 100755 index 0000000000..55414a63ee --- /dev/null +++ b/content/ru/docs/reference/glossary/cloud-provider.md @@ -0,0 +1,32 @@ +--- +title: Облачный Провайдер (Cloud Provider) +id: cloud-provider +date: 2018-04-12 +full_link: /docs/concepts/cluster-administration/cloud-providers +short_description: > + Организация, которая предлагает платформу облачных вычислений. + +aka: +- Поставщик Облачных Услуг (Cloud Service Provider) +tags: +- community +--- + Бизнес или другая организация, которая предлагает платформу облачных вычислений. + +<!--more--> + +Облачные Провайдеры, иногда называемые Поставщиками Облачных Услуг (Cloud Service Provider, CSPs), +предлагают облачные вычислительные платформы или услуги. + +Многие облачные провайдеры предлагают управляемую инфраструктуру (также называемую +Инфраструктура как Услуга (Infrastructure as a Service) или IaaS). +С управляемой инфраструктурой облачный провайдер отвечает за +сервера, хранилище и сеть, в то время как вы управляете слоями поверх этого, +такими как запуск Kubernetes кластера. + +Вы также можете найти Kubernetes в качестве управляемого сервиса; иногда его называют +Платформа как Услуга (Platform as a Service) или PaaS. С упарвляемым Kubernetes +ваш облачный провайдер отвечает за +{{< glossary_tooltip term_id="control-plane" text="плоскость управления" >}} Kubernetes, а также за +{{< glossary_tooltip term_id="node" text="узлы" >}} и инфраструктуру, на которую они полагаются: +сеть, хранилище и, возможно, другие элементы, такие как балансировщики нагрузки. diff --git a/content/ru/docs/reference/glossary/controller.md b/content/ru/docs/reference/glossary/controller.md new file mode 100755 index 0000000000..c1efc41d1b --- /dev/null +++ b/content/ru/docs/reference/glossary/controller.md @@ -0,0 +1,29 @@ +--- +title: Контроллер (Controller) +id: controller +date: 2018-04-12 +full_link: /docs/concepts/architecture/controller/ +short_description: > + Управляющий цикл который отслеживает общее состояние кластера через API-сервер и вносит изменения пытаясь приветси текушее состояние к желаемому состоянию. + +aka: +tags: +- architecture +- fundamental +--- +Контроллеры в Kubernetes - управляющие циклы, которые отслеживают состояние вашего +{{< glossary_tooltip term_id="cluster" text="кластера">}}, затем вносят или запрашивают +изменения там, где это необходимо. +Каждый контроллер пытается привести текущее состояние кластера ближе к желаемому состоянию. + +<!--more--> + +Контроллеры отсллеживают общее состояние вашего кластера через +{{< glossary_tooltip text="API-сервер" term_id="kube-apiserver" >}} (часть +{{< glossary_tooltip text="плоскости управления" term_id="control-plane" >}}). + +Некоторые контроллеры также работают внутри плоскости управления, обеспечивая +управляющие циклы, которые являются ядром для операций Kubernetes. Например: +контроллер развертывания (deployment controller), контроллер daemonset (daemonset controller), +контроллер пространства имен (namespace controller) и контроллер постоянных томов (persistent volume +controller) (и другие) работают с {{< glossary_tooltip term_id="kube-controller-manager" >}}. diff --git a/content/ru/docs/reference/kubectl/kubectl.md b/content/ru/docs/reference/kubectl/kubectl.md index 071d927b07..ce01d0b8ab 100644 --- a/content/ru/docs/reference/kubectl/kubectl.md +++ b/content/ru/docs/reference/kubectl/kubectl.md @@ -1,6 +1,6 @@ --- title: kubectl -content_template: templates/tool-reference +content_type: tool-reference weight: 28 --- @@ -22,497 +22,496 @@ kubectl [flags] <table style="width: 100%; table-layout: fixed;"> - <colgroup> - <col span="1" style="width: 10px;" /> - <col span="1" /> - </colgroup> - <tbody> - - <tr> - <td colspan="2">--add-dir-header</td> - </tr> - <tr> - <td></td><td style="line-height: 130%; word-wrap: break-word;">Если true, добавляет директорию файла в заголовок</td> - </tr> - - <tr> - <td colspan="2">--alsologtostderr</td> - </tr> - <tr> - <td></td><td style="line-height: 130%; word-wrap: break-word;">Логировать в стандартный поток ошибок, а также в файлы</td> - </tr> - - <tr> - <td colspan="2">--application-metrics-count-limit int     По умолчанию: 100</td> - </tr> - <tr> - <td></td><td style="line-height: 130%; word-wrap: break-word;">Максимальное количество сохраняемых метрик приложения (на каждый контейнер)</td> - </tr> - - <tr> - <td colspan="2">--as string</td> - </tr> - <tr> - <td></td><td style="line-height: 130%; word-wrap: break-word;">Имя пользователя, от которого будет выполняться операция</td> - </tr> - - <tr> - <td colspan="2">--as-group stringArray</td> - </tr> - <tr> - <td></td><td style="line-height: 130%; word-wrap: break-word;">Группа, от которой будет выполняться операция, этот флаг можно использовать неоднократно, чтобы указать несколько групп.</td> - </tr> - - <tr> - <td colspan="2">--azure-container-registry-config string</td> - </tr> - <tr> - <td></td><td style="line-height: 130%; word-wrap: break-word;">Путь к файлу, который содержит информацию с конфигурацией реестра контейнера Azure.</td> - </tr> - - <tr> - <td colspan="2">--boot-id-file string     По умолчанию: "/proc/sys/kernel/random/boot_id"</td> - </tr> - <tr> - <td></td><td style="line-height: 130%; word-wrap: break-word;">Разделенный запятыми список файлов для проверки boot-id. Используйте первый существующий.</td> - </tr> - - <tr> - <td colspan="2">--cache-dir string     По умолчанию: "$HOME/.kube/http-cache"</td> - </tr> - <tr> - <td></td><td style="line-height: 130%; word-wrap: break-word;">Директория HTTP-кеша по умолчанию</td> - </tr> - - <tr> - <td colspan="2">--certificate-authority string</td> - </tr> - <tr> - <td></td><td style="line-height: 130%; word-wrap: break-word;">Путь к файлу сертификата для центра сертификации</td> - </tr> - - <tr> - <td colspan="2">--client-certificate string</td> - </tr> - <tr> - <td></td><td style="line-height: 130%; word-wrap: break-word;">Путь к файлу клиентского сертификата для TLS</td> - </tr> - - <tr> - <td colspan="2">--client-key string</td> - </tr> - <tr> - <td></td><td style="line-height: 130%; word-wrap: break-word;">Путь к файлу клиентского ключа для TLS</td> - </tr> - - <tr> - <td colspan="2">--cloud-provider-gce-l7lb-src-cidrs cidrs     По умолчанию: 130.211.0.0/22,35.191.0.0/16</td> - </tr> - <tr> - <td></td><td style="line-height: 130%; word-wrap: break-word;">Открыть CIDR в брандмауэре GCE для прокси трафика L7 LB и проверки работоспособности</td> - </tr> - - <tr> - <td colspan="2">--cloud-provider-gce-lb-src-cidrs cidrs     По умолчанию: 130.211.0.0/22,209.85.152.0/22,209.85.204.0/22,35.191.0.0/16</td> - </tr> - <tr> - <td></td><td style="line-height: 130%; word-wrap: break-word;">Открыть CIDR в брандмауэре GCE для прокси трафика L4 LB и проверки работоспособности</td> - </tr> - - <tr> - <td colspan="2">--cluster string</td> - </tr> - <tr> - <td></td><td style="line-height: 130%; word-wrap: break-word;">Имя используемого кластера kubeconfig</td> - </tr> - - <tr> - <td colspan="2">--container-hints string     По умолчанию: "/etc/cadvisor/container_hints.json"</td> - </tr> - <tr> - <td></td><td style="line-height: 130%; word-wrap: break-word;">Путь к файлу подсказок контейнера</td> - </tr> - - <tr> - <td colspan="2">--containerd string     По умолчанию: "/run/containerd/containerd.sock"</td> - </tr> - <tr> - <td></td><td style="line-height: 130%; word-wrap: break-word;">Конечная точка containerd</td> - </tr> - - <tr> - <td colspan="2">--containerd-namespace string     По умолчанию: "k8s.io"</td> - </tr> - <tr> - <td></td><td style="line-height: 130%; word-wrap: break-word;">Пространство имени containerd</td> - </tr> - - <tr> - <td colspan="2">--context string</td> - </tr> - <tr> - <td></td><td style="line-height: 130%; word-wrap: break-word;">Имя контекста kubeconfig</td> - </tr> - - <tr> - <td colspan="2">--default-not-ready-toleration-seconds int     По умолчанию: 300</td> - </tr> - <tr> - <td></td><td style="line-height: 130%; word-wrap: break-word;">Указывает tolerationSeconds для допущения notReady:NoExecute, которое по умолчанию добавляется к каждому поду, у которого нет установлено такое допущение.</td> - </tr> - - <tr> - <td colspan="2">--default-unreachable-toleration-seconds int     По умолчанию: 300</td> - </tr> - <tr> - <td></td><td style="line-height: 130%; word-wrap: break-word;">Указывает tolerationSeconds для допущения unreachable:NoExecute, которое по умолчанию добавляется к каждому поду, у которого нет установлено такое допущение.</td> - </tr> - - <tr> - <td colspan="2">--disable-root-cgroup-stats</td> - </tr> - <tr> - <td></td><td style="line-height: 130%; word-wrap: break-word;">Отключить сбор статистики корневой группы (Cgroup)</td> - </tr> - - <tr> - <td colspan="2">--docker string     По умолчанию: "unix:///var/run/docker.sock"</td> - </tr> - <tr> - <td></td><td style="line-height: 130%; word-wrap: break-word;">docker endpoint</td> - </tr> - - <tr> - <td colspan="2">--docker-env-metadata-whitelist string</td> - </tr> - <tr> - <td></td><td style="line-height: 130%; word-wrap: break-word;">Список ключей переменных окружения, разделенный запятыми, которые необходимо собрать для Docker-контейнеров</td> - </tr> - - <tr> - <td colspan="2">--docker-only</td> - </tr> - <tr> - <td></td><td style="line-height: 130%; word-wrap: break-word;">В дополнение к корневой статистике уведомлять только о Docker-контейнерах</td> - </tr> - - <tr> - <td colspan="2">--docker-root string     По умолчанию: "/var/lib/docker"</td> - </tr> - <tr> - <td></td><td style="line-height: 130%; word-wrap: break-word;">УСТАРЕЛО: корень docker считывается из информации docker (запасной вариант, по умолчанию: /var/lib/docker)</td> - </tr> - - <tr> - <td colspan="2">--docker-tls</td> - </tr> - <tr> - <td></td><td style="line-height: 130%; word-wrap: break-word;">Использовать TLS для подключения к Docker</td> - </tr> - - <tr> - <td colspan="2">--docker-tls-ca string     По умолчанию: "ca.pem"</td> - </tr> - <tr> - <td></td><td style="line-height: 130%; word-wrap: break-word;">Путь к доверенному CA</td> - </tr> - - <tr> - <td colspan="2">--docker-tls-cert string     По умолчанию: "cert.pem"</td> - </tr> - <tr> - <td></td><td style="line-height: 130%; word-wrap: break-word;">путь к клиентскому сертификату</td> - </tr> - - <tr> - <td colspan="2">--docker-tls-key string     По умолчанию: "key.pem"</td> - </tr> - <tr> - <td></td><td style="line-height: 130%; word-wrap: break-word;">Путь к приватному ключу</td> - </tr> - - <tr> - <td colspan="2">--enable-load-reader</td> - </tr> - <tr> - <td></td><td style="line-height: 130%; word-wrap: break-word;">Включить считыватель нагрузки процессора</td> - </tr> - - <tr> - <td colspan="2">--event-storage-age-limit string     По умолчанию: "default=0"</td> - </tr> - <tr> - <td></td><td style="line-height: 130%; word-wrap: break-word;">Максимальный период времени для хранения события (по каждому типу). Значение флага — список из ключей и значений, разделенные запятыми, где ключи — это типы событий (например: создание, oom) либо "default", а значение — длительность. По умолчанию флаг применяется ко всем неуказанным типам событий</td> - </tr> - - <tr> - <td colspan="2">--event-storage-event-limit string     По умолчанию: "default=0"</td> - </tr> - <tr> - <td></td><td style="line-height: 130%; word-wrap: break-word;">Максимальное количество событий для хранения (по каждому типу). Значение флага — список из ключей и значений, разделенные запятыми, где ключи — это типы событий (например: создание, oom) либо "default", а значение — целое число. По умолчанию флаг применяется ко всем неуказанным типам событий</td> - </tr> - - <tr> - <td colspan="2">--global-housekeeping-interval duration     По умолчанию: 1m0s</td> - </tr> - <tr> - <td></td><td style="line-height: 130%; word-wrap: break-word;">Интервал между глобальными служебными операциями (housekeepings)</td> - </tr> - - <tr> - <td colspan="2">-h, --help</td> - </tr> - <tr> - <td></td><td style="line-height: 130%; word-wrap: break-word;">Получить справочную информацию по команде kubectl</td> - </tr> - - <tr> - <td colspan="2">--housekeeping-interval duration     По умолчанию: 10s</td> - </tr> - <tr> - <td></td><td style="line-height: 130%; word-wrap: break-word;">Интервал между служебными операциями (housekeepings) контейнера</td> - </tr> - - <tr> - <td colspan="2">--insecure-skip-tls-verify</td> - </tr> - <tr> - <td></td><td style="line-height: 130%; word-wrap: break-word;">Если true, значит сертификат сервера не будет проверятся на достоверность. Это сделает подключения через HTTPS небезопасными.</td> - </tr> - - <tr> - <td colspan="2">--kubeconfig string</td> - </tr> - <tr> - <td></td><td style="line-height: 130%; word-wrap: break-word;">Путь к файлу kubeconfig для использования в CLI-запросах.</td> - </tr> - - <tr> - <td colspan="2">--log-backtrace-at traceLocation     По умолчанию: :0</td> - </tr> - <tr> - <td></td><td style="line-height: 130%; word-wrap: break-word;">При логировании указанной строки (file:N), сгенерировать трассировку стека</td> - </tr> - - <tr> - <td colspan="2">--log-cadvisor-usage</td> - </tr> - <tr> - <td></td><td style="line-height: 130%; word-wrap: break-word;">Записывать ли в журнал использование контейнера cAdvisor</td> - </tr> - - <tr> - <td colspan="2">--log-dir string</td> - </tr> - <tr> - <td></td><td style="line-height: 130%; word-wrap: break-word;">Если указан, хранить лог-файлы в этой директории.</td> - </tr> - - <tr> - <td colspan="2">--log-file string</td> - </tr> - <tr> - <td></td><td style="line-height: 130%; word-wrap: break-word;">Если указан, использовать этот лог-файл</td> - </tr> - - <tr> - <td colspan="2">--log-file-max-size uint     По умолчанию: 1800</td> - </tr> - <tr> - <td></td><td style="line-height: 130%; word-wrap: break-word;">Установить максимальный размер файла лог-файла (в Мб). Если значение равно 0, максимальный размер файла не ограничен.</td> - </tr> - - <tr> - <td colspan="2">--log-flush-frequency duration     По умолчанию: 5s</td> - </tr> - <tr> - <td></td><td style="line-height: 130%; word-wrap: break-word;">Максимальное количество секунд между очисткой лог-файлов</td> - </tr> - - <tr> - <td colspan="2">--logtostderr     По умолчанию: true</td> - </tr> - <tr> - <td></td><td style="line-height: 130%; word-wrap: break-word;">Логировать в стандартный поток ошибок вместо сохранения логов в файлы</td> - </tr> - - <tr> - <td colspan="2">--machine-id-file string     По умолчанию: "/etc/machine-id,/var/lib/dbus/machine-id"</td> - </tr> - <tr> - <td></td><td style="line-height: 130%; word-wrap: break-word;">Список файлов, разделенных запятыми, для проверки machine-id. Используйте первый существующий.</td> - </tr> - - <tr> - <td colspan="2">--match-server-version</td> - </tr> - <tr> - <td></td><td style="line-height: 130%; word-wrap: break-word;">Убедиться, что версия сервера соответствует версии клиента</td> - </tr> - - <tr> - <td colspan="2">-n, --namespace string</td> - </tr> - <tr> - <td></td><td style="line-height: 130%; word-wrap: break-word;">Указать область пространства имен для данного запроса CLI</td> - </tr> - - <tr> - <td colspan="2">--password string</td> - </tr> - <tr> - <td></td><td style="line-height: 130%; word-wrap: break-word;">Пароль для базовой аутентификации на API-сервере</td> - </tr> - - <tr> - <td colspan="2">--profile string     По умолчанию: "none"</td> - </tr> - <tr> - <td></td><td style="line-height: 130%; word-wrap: break-word;">Имя профиля. Может быть одним из перечисленных значений: none|cpu|heap|goroutine|threadcreate|block|mutex</td> - </tr> - - <tr> - <td colspan="2">--profile-output string     По умолчанию: "profile.pprof"</td> - </tr> - <tr> - <td></td><td style="line-height: 130%; word-wrap: break-word;">Имя файла для записи профиля.</td> - </tr> - - <tr> - <td colspan="2">--request-timeout string     По умолчанию: "0"</td> - </tr> - <tr> - <td></td><td style="line-height: 130%; word-wrap: break-word;">Время ожидания перед тем, как перестать ожидать ответ от сервера. Значения должны содержать соответствующую единицу времени (например, 1s, 2m, 3h). Нулевое значение означает, что у запросов нет тайм-аута. -.</td> - </tr> - - <tr> - <td colspan="2">-s, --server string</td> - </tr> - <tr> - <td></td><td style="line-height: 130%; word-wrap: break-word;">Адрес и порт API-сервера Kubernetes</td> - </tr> - - <tr> - <td colspan="2">--skip-headers</td> - </tr> - <tr> - <td></td><td style="line-height: 130%; word-wrap: break-word;">Если true, не отображать заголовки в сообщениях лога.</td> - </tr> - - <tr> - <td colspan="2">--skip-log-headers</td> - </tr> - <tr> - <td></td><td style="line-height: 130%; word-wrap: break-word;">Если true, не отображать заголовки при открытии лог-файлов.</td> - </tr> - - <tr> - <td colspan="2">--stderrthreshold severity     По умолчанию: 2</td> - </tr> - <tr> - <td></td><td style="line-height: 130%; word-wrap: break-word;">Логи указанного уровня серьёзности или выше выводить в поток stderr</td> - </tr> - - <tr> - <td colspan="2">--storage-driver-buffer-duration duration     По умолчанию: 1m0s</td> - </tr> - <tr> - <td></td><td style="line-height: 130%; word-wrap: break-word;">Буферизировать запись в драйвере хранилища в течение указанного времени, и сохранять в файловом хранилище в виде одной транзакции</td> - </tr> - - <tr> - <td colspan="2">--storage-driver-db string     По умолчанию: "cadvisor"</td> - </tr> - <tr> - <td></td><td style="line-height: 130%; word-wrap: break-word;">Имя базы данных</td> - </tr> - - <tr> - <td colspan="2">--storage-driver-host string     По умолчанию: "localhost:8086"</td> - </tr> - <tr> - <td></td><td style="line-height: 130%; word-wrap: break-word;">Хост и порт базы данных, записанный в формате host:port</td> - </tr> - - <tr> - <td colspan="2">--storage-driver-password string     По умолчанию: "root"</td> - </tr> - <tr> - <td></td><td style="line-height: 130%; word-wrap: break-word;">Пароль к базе данных</td> - </tr> - - <tr> - <td colspan="2">--storage-driver-secure</td> - </tr> - <tr> - <td></td><td style="line-height: 130%; word-wrap: break-word;">Использовать безопасное соединение с базой данных</td> - </tr> - - <tr> - <td colspan="2">--storage-driver-table string     По умолчанию: "stats"</td> - </tr> - <tr> - <td></td><td style="line-height: 130%; word-wrap: break-word;">Имя таблицы</td> - </tr> - - <tr> - <td colspan="2">--storage-driver-user string     По умолчанию: "root"</td> - </tr> - <tr> - <td></td><td style="line-height: 130%; word-wrap: break-word;">Имя пользователя базы данных</td> - </tr> - - <tr> - <td colspan="2">--token string</td> - </tr> - <tr> - <td></td><td style="line-height: 130%; word-wrap: break-word;">Аутентификационный (bearer) токен для аутентификации на API-сервере</td> - </tr> - - <tr> - <td colspan="2">--update-machine-info-interval duration     По умолчанию: 5m0s</td> - </tr> - <tr> - <td></td><td style="line-height: 130%; word-wrap: break-word;">Интервал между обновлениями информации о машине.</td> - </tr> - - <tr> - <td colspan="2">--user string</td> - </tr> - <tr> - <td></td><td style="line-height: 130%; word-wrap: break-word;">Имя пользователя для kubeconfig</td> - </tr> - - <tr> - <td colspan="2">--username string</td> - </tr> - <tr> - <td></td><td style="line-height: 130%; word-wrap: break-word;">Имя пользователя для базовой аутентификации на API-сервере</td> - </tr> - - <tr> - <td colspan="2">-v, --v Level</td> - </tr> - <tr> - <td></td><td style="line-height: 130%; word-wrap: break-word;">Номер уровня серьёзности логирования</td> - </tr> - - <tr> - <td colspan="2">--version version[=true]</td> - </tr> - <tr> - <td></td><td style="line-height: 130%; word-wrap: break-word;">Вывод версии команды</td> - </tr> - - <tr> - <td colspan="2">--vmodule moduleSpec</td> - </tr> - <tr> - <td></td><td style="line-height: 130%; word-wrap: break-word;">Список, разделённый запятыми, в виде настроек pattern=N для фильтрации лог-файлов</td> - </tr> - - </tbody> +<colgroup> +<col span="1" style="width: 10px;" /> +<col span="1" /> +</colgroup> +<tbody> + +<tr> +<td colspan="2">--add-dir-header</td> +</tr> +<tr> +<td></td><td style="line-height: 130%; word-wrap: break-word;">Если true, добавляет директорию файла в заголовок</td> +</tr> + +<tr> +<td colspan="2">--alsologtostderr</td> +</tr> +<tr> +<td></td><td style="line-height: 130%; word-wrap: break-word;">Логировать в стандартный поток ошибок, а также в файлы</td> +</tr> + +<tr> +<td colspan="2">--application-metrics-count-limit int     По умолчанию: 100</td> +</tr> +<tr> +<td></td><td style="line-height: 130%; word-wrap: break-word;">Максимальное количество сохраняемых метрик приложения (на каждый контейнер)</td> +</tr> + +<tr> +<td colspan="2">--as string</td> +</tr> +<tr> +<td></td><td style="line-height: 130%; word-wrap: break-word;">Имя пользователя, от которого будет выполняться операция</td> +</tr> + +<tr> +<td colspan="2">--as-group stringArray</td> +</tr> +<tr> +<td></td><td style="line-height: 130%; word-wrap: break-word;">Группа, от которой будет выполняться операция, этот флаг можно использовать неоднократно, чтобы указать несколько групп.</td> +</tr> + +<tr> +<td colspan="2">--azure-container-registry-config string</td> +</tr> +<tr> +<td></td><td style="line-height: 130%; word-wrap: break-word;">Путь к файлу, который содержит информацию с конфигурацией реестра контейнера Azure.</td> +</tr> + +<tr> +<td colspan="2">--boot-id-file string     По умолчанию: "/proc/sys/kernel/random/boot_id"</td> +</tr> +<tr> +<td></td><td style="line-height: 130%; word-wrap: break-word;">Разделенный запятыми список файлов для проверки boot-id. Используйте первый существующий.</td> +</tr> + +<tr> +<td colspan="2">--cache-dir string     По умолчанию: "$HOME/.kube/http-cache"</td> +</tr> +<tr> +<td></td><td style="line-height: 130%; word-wrap: break-word;">Директория HTTP-кеша по умолчанию</td> +</tr> + +<tr> +<td colspan="2">--certificate-authority string</td> +</tr> +<tr> +<td></td><td style="line-height: 130%; word-wrap: break-word;">Путь к файлу сертификата для центра сертификации</td> +</tr> + +<tr> +<td colspan="2">--client-certificate string</td> +</tr> +<tr> +<td></td><td style="line-height: 130%; word-wrap: break-word;">Путь к файлу клиентского сертификата для TLS</td> +</tr> + +<tr> +<td colspan="2">--client-key string</td> +</tr> +<tr> +<td></td><td style="line-height: 130%; word-wrap: break-word;">Путь к файлу клиентского ключа для TLS</td> +</tr> + +<tr> +<td colspan="2">--cloud-provider-gce-l7lb-src-cidrs cidrs     По умолчанию: 130.211.0.0/22,35.191.0.0/16</td> +</tr> +<tr> +<td></td><td style="line-height: 130%; word-wrap: break-word;">Открыть CIDR в брандмауэре GCE для прокси трафика L7 LB и проверки работоспособности</td> +</tr> + +<tr> +<td colspan="2">--cloud-provider-gce-lb-src-cidrs cidrs     По умолчанию: 130.211.0.0/22,209.85.152.0/22,209.85.204.0/22,35.191.0.0/16</td> +</tr> +<tr> +<td></td><td style="line-height: 130%; word-wrap: break-word;">Открыть CIDR в брандмауэре GCE для прокси трафика L4 LB и проверки работоспособности</td> +</tr> + +<tr> +<td colspan="2">--cluster string</td> +</tr> +<tr> +<td></td><td style="line-height: 130%; word-wrap: break-word;">Имя используемого кластера kubeconfig</td> +</tr> + +<tr> +<td colspan="2">--container-hints string     По умолчанию: "/etc/cadvisor/container_hints.json"</td> +</tr> +<tr> +<td></td><td style="line-height: 130%; word-wrap: break-word;">Путь к файлу подсказок контейнера</td> +</tr> + +<tr> +<td colspan="2">--containerd string     По умолчанию: "/run/containerd/containerd.sock"</td> +</tr> +<tr> +<td></td><td style="line-height: 130%; word-wrap: break-word;">Конечная точка containerd</td> +</tr> + +<tr> +<td colspan="2">--containerd-namespace string     По умолчанию: "k8s.io"</td> +</tr> +<tr> +<td></td><td style="line-height: 130%; word-wrap: break-word;">Пространство имени containerd</td> +</tr> + +<tr> +<td colspan="2">--context string</td> +</tr> +<tr> +<td></td><td style="line-height: 130%; word-wrap: break-word;">Имя контекста kubeconfig</td> +</tr> + +<tr> +<td colspan="2">--default-not-ready-toleration-seconds int     По умолчанию: 300</td> +</tr> +<tr> +<td></td><td style="line-height: 130%; word-wrap: break-word;">Указывает tolerationSeconds для допущения notReady:NoExecute, которое по умолчанию добавляется к каждому поду, у которого нет установлено такое допущение.</td> +</tr> + +<tr> +<td colspan="2">--default-unreachable-toleration-seconds int     По умолчанию: 300</td> +</tr> +<tr> +<td></td><td style="line-height: 130%; word-wrap: break-word;">Указывает tolerationSeconds для допущения unreachable:NoExecute, которое по умолчанию добавляется к каждому поду, у которого нет установлено такое допущение.</td> +</tr> + +<tr> +<td colspan="2">--disable-root-cgroup-stats</td> +</tr> +<tr> +<td></td><td style="line-height: 130%; word-wrap: break-word;">Отключить сбор статистики корневой группы (Cgroup)</td> +</tr> + +<tr> +<td colspan="2">--docker string     По умолчанию: "unix:///var/run/docker.sock"</td> +</tr> +<tr> +<td></td><td style="line-height: 130%; word-wrap: break-word;">docker endpoint</td> +</tr> + +<tr> +<td colspan="2">--docker-env-metadata-whitelist string</td> +</tr> +<tr> +<td></td><td style="line-height: 130%; word-wrap: break-word;">Список ключей переменных окружения, разделенный запятыми, которые необходимо собрать для Docker-контейнеров</td> +</tr> + +<tr> +<td colspan="2">--docker-only</td> +</tr> +<tr> +<td></td><td style="line-height: 130%; word-wrap: break-word;">В дополнение к корневой статистике уведомлять только о Docker-контейнерах</td> +</tr> + +<tr> +<td colspan="2">--docker-root string     По умолчанию: "/var/lib/docker"</td> +</tr> +<tr> +<td></td><td style="line-height: 130%; word-wrap: break-word;">УСТАРЕЛО: корень docker считывается из информации docker (запасной вариант, по умолчанию: /var/lib/docker)</td> +</tr> + +<tr> +<td colspan="2">--docker-tls</td> +</tr> +<tr> +<td></td><td style="line-height: 130%; word-wrap: break-word;">Использовать TLS для подключения к Docker</td> +</tr> + +<tr> +<td colspan="2">--docker-tls-ca string     По умолчанию: "ca.pem"</td> +</tr> +<tr> +<td></td><td style="line-height: 130%; word-wrap: break-word;">Путь к доверенному CA</td> +</tr> + +<tr> +<td colspan="2">--docker-tls-cert string     По умолчанию: "cert.pem"</td> +</tr> +<tr> +<td></td><td style="line-height: 130%; word-wrap: break-word;">путь к клиентскому сертификату</td> +</tr> + +<tr> +<td colspan="2">--docker-tls-key string     По умолчанию: "key.pem"</td> +</tr> +<tr> +<td></td><td style="line-height: 130%; word-wrap: break-word;">Путь к приватному ключу</td> +</tr> + +<tr> +<td colspan="2">--enable-load-reader</td> +</tr> +<tr> +<td></td><td style="line-height: 130%; word-wrap: break-word;">Включить считыватель нагрузки процессора</td> +</tr> + +<tr> +<td colspan="2">--event-storage-age-limit string     По умолчанию: "default=0"</td> +</tr> +<tr> +<td></td><td style="line-height: 130%; word-wrap: break-word;">Максимальный период времени для хранения события (по каждому типу). Значение флага — список из ключей и значений, разделенные запятыми, где ключи — это типы событий (например: создание, oom) либо "default", а значение — длительность. По умолчанию флаг применяется ко всем неуказанным типам событий</td> +</tr> + +<tr> +<td colspan="2">--event-storage-event-limit string     По умолчанию: "default=0"</td> +</tr> +<tr> +<td></td><td style="line-height: 130%; word-wrap: break-word;">Максимальное количество событий для хранения (по каждому типу). Значение флага — список из ключей и значений, разделенные запятыми, где ключи — это типы событий (например: создание, oom) либо "default", а значение — целое число. По умолчанию флаг применяется ко всем неуказанным типам событий</td> +</tr> + +<tr> +<td colspan="2">--global-housekeeping-interval duration     По умолчанию: 1m0s</td> +</tr> +<tr> +<td></td><td style="line-height: 130%; word-wrap: break-word;">Интервал между глобальными служебными операциями (housekeepings)</td> +</tr> + +<tr> +<td colspan="2">-h, --help</td> +</tr> +<tr> +<td></td><td style="line-height: 130%; word-wrap: break-word;">Получить справочную информацию по команде kubectl</td> +</tr> + +<tr> +<td colspan="2">--housekeeping-interval duration     По умолчанию: 10s</td> +</tr> +<tr> +<td></td><td style="line-height: 130%; word-wrap: break-word;">Интервал между служебными операциями (housekeepings) контейнера</td> +</tr> + +<tr> +<td colspan="2">--insecure-skip-tls-verify</td> +</tr> +<tr> +<td></td><td style="line-height: 130%; word-wrap: break-word;">Если true, значит сертификат сервера не будет проверятся на достоверность. Это сделает подключения через HTTPS небезопасными.</td> +</tr> + +<tr> +<td colspan="2">--kubeconfig string</td> +</tr> +<tr> +<td></td><td style="line-height: 130%; word-wrap: break-word;">Путь к файлу kubeconfig для использования в CLI-запросах.</td> +</tr> + +<tr> +<td colspan="2">--log-backtrace-at traceLocation     По умолчанию: :0</td> +</tr> +<tr> +<td></td><td style="line-height: 130%; word-wrap: break-word;">При логировании указанной строки (file:N), сгенерировать трассировку стека</td> +</tr> + +<tr> +<td colspan="2">--log-cadvisor-usage</td> +</tr> +<tr> +<td></td><td style="line-height: 130%; word-wrap: break-word;">Записывать ли в журнал использование контейнера cAdvisor</td> +</tr> + +<tr> +<td colspan="2">--log-dir string</td> +</tr> +<tr> +<td></td><td style="line-height: 130%; word-wrap: break-word;">Если указан, хранить лог-файлы в этой директории.</td> +</tr> + +<tr> +<td colspan="2">--log-file string</td> +</tr> +<tr> +<td></td><td style="line-height: 130%; word-wrap: break-word;">Если указан, использовать этот лог-файл</td> +</tr> + +<tr> +<td colspan="2">--log-file-max-size uint     По умолчанию: 1800</td> +</tr> +<tr> +<td></td><td style="line-height: 130%; word-wrap: break-word;">Установить максимальный размер файла лог-файла (в Мб). Если значение равно 0, максимальный размер файла не ограничен.</td> +</tr> + +<tr> +<td colspan="2">--log-flush-frequency duration     По умолчанию: 5s</td> +</tr> +<tr> +<td></td><td style="line-height: 130%; word-wrap: break-word;">Максимальное количество секунд между очисткой лог-файлов</td> +</tr> + +<tr> +<td colspan="2">--logtostderr     По умолчанию: true</td> +</tr> +<tr> +<td></td><td style="line-height: 130%; word-wrap: break-word;">Логировать в стандартный поток ошибок вместо сохранения логов в файлы</td> +</tr> + +<tr> +<td colspan="2">--machine-id-file string     По умолчанию: "/etc/machine-id,/var/lib/dbus/machine-id"</td> +</tr> +<tr> +<td></td><td style="line-height: 130%; word-wrap: break-word;">Список файлов, разделенных запятыми, для проверки machine-id. Используйте первый существующий.</td> +</tr> + +<tr> +<td colspan="2">--match-server-version</td> +</tr> +<tr> +<td></td><td style="line-height: 130%; word-wrap: break-word;">Убедиться, что версия сервера соответствует версии клиента</td> +</tr> + +<tr> +<td colspan="2">-n, --namespace string</td> +</tr> +<tr> +<td></td><td style="line-height: 130%; word-wrap: break-word;">Указать область пространства имен для данного запроса CLI</td> +</tr> + +<tr> +<td colspan="2">--password string</td> +</tr> +<tr> +<td></td><td style="line-height: 130%; word-wrap: break-word;">Пароль для базовой аутентификации на API-сервере</td> +</tr> + +<tr> +<td colspan="2">--profile string     По умолчанию: "none"</td> +</tr> +<tr> +<td></td><td style="line-height: 130%; word-wrap: break-word;">Имя профиля. Может быть одним из перечисленных значений: none|cpu|heap|goroutine|threadcreate|block|mutex</td> +</tr> + +<tr> +<td colspan="2">--profile-output string     По умолчанию: "profile.pprof"</td> +</tr> +<tr> +<td></td><td style="line-height: 130%; word-wrap: break-word;">Имя файла для записи профиля.</td> +</tr> + +<tr> +<td colspan="2">--request-timeout string     По умолчанию: "0"</td> +</tr> +<tr> +<td></td><td style="line-height: 130%; word-wrap: break-word;">Время ожидания перед тем, как перестать ожидать ответ от сервера. Значения должны содержать соответствующую единицу времени (например, 1s, 2m, 3h). Нулевое значение означает, что у запросов нет тайм-аута.</td> +</tr> + +<tr> +<td colspan="2">-s, --server string</td> +</tr> +<tr> +<td></td><td style="line-height: 130%; word-wrap: break-word;">Адрес и порт API-сервера Kubernetes</td> +</tr> + +<tr> +<td colspan="2">--skip-headers</td> +</tr> +<tr> +<td></td><td style="line-height: 130%; word-wrap: break-word;">Если true, не отображать заголовки в сообщениях лога.</td> +</tr> + +<tr> +<td colspan="2">--skip-log-headers</td> +</tr> +<tr> +<td></td><td style="line-height: 130%; word-wrap: break-word;">Если true, не отображать заголовки при открытии лог-файлов.</td> +</tr> + +<tr> +<td colspan="2">--stderrthreshold severity     По умолчанию: 2</td> +</tr> +<tr> +<td></td><td style="line-height: 130%; word-wrap: break-word;">Логи указанного уровня серьёзности или выше выводить в поток stderr</td> +</tr> + +<tr> +<td colspan="2">--storage-driver-buffer-duration duration     По умолчанию: 1m0s</td> +</tr> +<tr> +<td></td><td style="line-height: 130%; word-wrap: break-word;">Буферизировать запись в драйвере хранилища в течение указанного времени, и сохранять в файловом хранилище в виде одной транзакции</td> +</tr> + +<tr> +<td colspan="2">--storage-driver-db string     По умолчанию: "cadvisor"</td> +</tr> +<tr> +<td></td><td style="line-height: 130%; word-wrap: break-word;">Имя базы данных</td> +</tr> + +<tr> +<td colspan="2">--storage-driver-host string     По умолчанию: "localhost:8086"</td> +</tr> +<tr> +<td></td><td style="line-height: 130%; word-wrap: break-word;">Хост и порт базы данных, записанный в формате host:port</td> +</tr> + +<tr> +<td colspan="2">--storage-driver-password string     По умолчанию: "root"</td> +</tr> +<tr> +<td></td><td style="line-height: 130%; word-wrap: break-word;">Пароль к базе данных</td> +</tr> + +<tr> +<td colspan="2">--storage-driver-secure</td> +</tr> +<tr> +<td></td><td style="line-height: 130%; word-wrap: break-word;">Использовать безопасное соединение с базой данных</td> +</tr> + +<tr> +<td colspan="2">--storage-driver-table string     По умолчанию: "stats"</td> +</tr> +<tr> +<td></td><td style="line-height: 130%; word-wrap: break-word;">Имя таблицы</td> +</tr> + +<tr> +<td colspan="2">--storage-driver-user string     По умолчанию: "root"</td> +</tr> +<tr> +<td></td><td style="line-height: 130%; word-wrap: break-word;">Имя пользователя базы данных</td> +</tr> + +<tr> +<td colspan="2">--token string</td> +</tr> +<tr> +<td></td><td style="line-height: 130%; word-wrap: break-word;">Аутентификационный (bearer) токен для аутентификации на API-сервере</td> +</tr> + +<tr> +<td colspan="2">--update-machine-info-interval duration     По умолчанию: 5m0s</td> +</tr> +<tr> +<td></td><td style="line-height: 130%; word-wrap: break-word;">Интервал между обновлениями информации о машине.</td> +</tr> + +<tr> +<td colspan="2">--user string</td> +</tr> +<tr> +<td></td><td style="line-height: 130%; word-wrap: break-word;">Имя пользователя для kubeconfig</td> +</tr> + +<tr> +<td colspan="2">--username string</td> +</tr> +<tr> +<td></td><td style="line-height: 130%; word-wrap: break-word;">Имя пользователя для базовой аутентификации на API-сервере</td> +</tr> + +<tr> +<td colspan="2">-v, --v Level</td> +</tr> +<tr> +<td></td><td style="line-height: 130%; word-wrap: break-word;">Номер уровня серьёзности логирования</td> +</tr> + +<tr> +<td colspan="2">--version version[=true]</td> +</tr> +<tr> +<td></td><td style="line-height: 130%; word-wrap: break-word;">Вывод версии команды</td> +</tr> + +<tr> +<td colspan="2">--vmodule moduleSpec</td> +</tr> +<tr> +<td></td><td style="line-height: 130%; word-wrap: break-word;">Список, разделённый запятыми, в виде настроек pattern=N для фильтрации лог-файлов</td> +</tr> + +</tbody> </table> diff --git a/content/ru/docs/tasks/configure-pod-container/assign-cpu-resource.md b/content/ru/docs/tasks/configure-pod-container/assign-cpu-resource.md new file mode 100644 index 0000000000..c94a1ba15e --- /dev/null +++ b/content/ru/docs/tasks/configure-pod-container/assign-cpu-resource.md @@ -0,0 +1,266 @@ +--- +title: Задание ресурсов CPU для контейнеров и Pod'ов +content_type: task +weight: 20 +--- + +<!-- overview --> + +На этой странице показывается, как настроить *запрос* CPU и *лимит* CPU +для контейнера. Контейнер не сможет использовать больше ресурсов CPU, +чем для него ограничено. Если в системе есть свободное время CPU, +контейнеру гарантируется выдача запрошенных им ресурсов CPU. + +## {{% heading "prerequisites" %}} + + +{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}} + +На кластере должен быть хотя бы 1 доступный для работы CPU, чтобы запускать учебные примеры. + +Для некоторых шагов с этой страницы понадобится запущенный +[сервер метрик](https://github.com/kubernetes-incubator/metrics-server) +на вашем кластере. Если сервер метрик уже запущен, следующие шаги можно пропустить. + +Если вы используете {{< glossary_tooltip term_id="minikube" >}}, выполните следующую команду, +чтобы запустить сервер метрик: + +```shell +minikube addons enable metrics-server +``` + +Проверим, работает ли сервер метрик (или другой провайдер API ресурсов метрик, +`metrics.k8s.io`), выполните команду: + +```shell +kubectl get apiservices +``` + +Если API ресурсов метрик доступно, в выводе будет присутствовать +ссылка на `metrics.k8s.io`. + + +``` +NAME +v1beta1.metrics.k8s.io +``` + + + + +<!-- steps --> + +## Создание пространства имён + +Создадим {{< glossary_tooltip term_id="namespace" >}}, чтобы создаваемые в этом упражнении +ресурсы были изолированы от остального кластера. + +```shell +kubectl create namespace cpu-example +``` + +## Установка запроса CPU и лимита CPU + +Чтобы установить запрос CPU для контейнера, подключите поле `resources:requests` +в манифест ресурсов контейнера. Для установки ограничения по CPU подключите `resources:limits`. + +В этом упражнении мы создадим Pod, имеющий один контейнер. Зададим для контейнера запрос в +0.5 CPU и лимит в 1 CPU. Конфигурационный файл для такого Pod'а: + +{{< codenew file="pods/resource/cpu-request-limit.yaml" >}} + +Раздел `args` конфигурационного файла содержит аргументы для контейнера в момент старта. +Аргумент `-cpus "2"` говорит контейнеру попытаться использовать 2 CPU. + +Создадим Pod: + +```shell +kubectl apply -f https://k8s.io/examples/pods/resource/cpu-request-limit.yaml --namespace=cpu-example +``` + +Удостоверимся, что Pod запущен: + +```shell +kubectl get pod cpu-demo --namespace=cpu-example +``` + +Посмотрим детальную информацию о Pod'е: + +```shell +kubectl get pod cpu-demo --output=yaml --namespace=cpu-example +``` + +В выводе видно, что Pod имеет один контейнер с запросом в 500 милли-CPU и с ограничением в 1 CPU. + +```yaml +resources: + limits: + cpu: "1" + requests: + cpu: 500m +``` + +Запустим `kubectl top`, чтобы получить метрики Pod'a: + +```shell +kubectl top pod cpu-demo --namespace=cpu-example +``` + +В этом варианте вывода Pod'ом использовано 974 милли-CPU, что лишь чуть меньше +заданного в конфигурации Pod'a ограничения в 1 CPU. + +``` +NAME CPU(cores) MEMORY(bytes) +cpu-demo 974m <something> +``` + +Напомним, что установкой параметра `-cpu "2"` для контейнера было задано попытаться использовать 2 CPU, +однако в конфигурации присутствует ограничение всего в 1 CPU. Использование контейнером CPU было отрегулировано, +поскольку он попытался занять больше ресурсов, чем ему позволено. + +{{< note >}} +Другое возможное объяснение для выделения менее 1.0 CPU в отсутствии на ноде достаточного количества +свободных CPU ресурсов. Напомним, что в начальных условиях для этого упражнения было наличие у кластера +хотя бы 1 CPU, доступного для использования. Если контейнер запущен на ноде, имеющей в своём распоряжении всего 1 CPU, +контейнер не сможет использовать более 1 CPU независимо от заданных для него ограничений. +{{< /note >}} + +Удалим Pod: + +```shell +kubectl delete pod cpu-demo --namespace=cpu-example +``` + +## Единицы измерения CPU + +Ресурсы CPU измеряются в *CPU* единицах. Один CPU, в Kubernetes, соответствует: + +* 1 AWS vCPU +* 1 GCP Core +* 1 Azure vCore +* 1 гипертрединговое ядро на физическом процессоре Intel с Гипертредингом + +Дробные значения возможны. Контейнер, запрашивающий 0.5 CPU, получит вполовину меньше ресурсов, +чем контейнер, запрашивающий 1 CPU. Можно использовать окончание m для обозначения милли. Например, +100m CPU, 100 milliCPU и 0.1 CPU обозначают одно и то же. Точность выше 1m не поддерживается. + +CPU всегда запрашивается в абсолютных величинах, не в относиительных; 0.1 будет одинаковой частью от CPU +для одноядерного, двухъядерного или 48-ядерного процессора. + +## Запрос ресурсов CPU больше доступного на ноде + +Запросы и лимиты CPU устанавливаются для контейнеров, но также полезно рассматривать и Pod +имеющим эти характеристики. Запросом CPU для Pod'а является сумма запросов CPU всех его контейнеров. +Аналогично и лимит CPU для Pod'а - сумма всех ограничений CPU у его контейнеров. + +Планирование Pod'а основано на запросах. Pod попадает в расписание запуска на ноде лишь в случае +достаточного количества доступных ресурсов CPU на ноде, чтобы удовлетворить запрос CPU Pod'а. + +В этом упражнении мы создадим Pod с запросом CPU, превышающим мощности любой ноды в вашем кластере. +Ниже представлен конфигурационный файл для Pod'а с одним контейнером. Контейнер запрашивает 100 CPU, +что почти наверняка превышет имеющиеся мощности любой ноды в кластере. + +{{< codenew file="pods/resource/cpu-request-limit-2.yaml" >}} + +Создадим Pod: + +```shell +kubectl apply -f https://k8s.io/examples/pods/resource/cpu-request-limit-2.yaml --namespace=cpu-example +``` + +Проверим статус Pod'а: + +```shell +kubectl get pod cpu-demo-2 --namespace=cpu-example +``` + +Вывод показывает Pending статус у Pod'а. То есть Pod не запланирован к запуску +ни на одной ноде и будет оставаться в статусе Pending постоянно: + + +``` +NAME READY STATUS RESTARTS AGE +cpu-demo-2 0/1 Pending 0 7m +``` + +Посмотрим подробную информацию о Pod'е, включающую в себя события: + + +```shell +kubectl describe pod cpu-demo-2 --namespace=cpu-example +``` + +В выводе отражено, что контейнер не может быть запланирован из-за нехватки ресурсов +CPU на нодах: + + +``` +Events: + Reason Message + ------ ------- + FailedScheduling No nodes are available that match all of the following predicates:: Insufficient cpu (3). +``` + +Удалим Pod: + +```shell +kubectl delete pod cpu-demo-2 --namespace=cpu-example +``` + +## Если ограничения на CPU не заданы + +Если ограничения на использование контейнером CPU не установлены, возможны следующие варианты: + +* У контейнера отсутствует верхняя граница количества CPU доступных ему ресурсов. В таком случае +он может занять все ресурсы CPU, доступные на ноде, на которой он запущен. + +* Контейнер запущен в пространстве имён, в котором задана стандартная величина ограничения +ресурсов CPU. Тогда контейнеру автоматически присваивается это ограничение. Администраторы +кластера могут использовать [LimitRange](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#limitrange-v1-core/), +чтобы задать стандартную величину ограничения ресурсов CPU. + +## Мотивация для использования запросов и лимитов CPU + +Вы можете распоряжаться ресурсами CPU на нодах вашего кластера эффективнее, если для +запущенных контейнеров установлены запросы и ограничения на использование ресурсов CPU. +Задание небольшого запроса CPU даёт Pod'у хорошие шансы быть запланированным. Установка +лимита на ресурсы CPU, большего, чем запрос, позволяет достичь 2 вещей: + +* При увеличении нагрузки Pod может задействовать дополнительные ресурсы CPU. +* Количество ресурсов CPU, которые Pod может задействовать при повышении нагрузки, ограничено +некоторой разумной величиной. + +## Очистка + +Удалим созданное для этого упражнения пространство имён: + +```shell +kubectl delete namespace cpu-example +``` + + + +## {{% heading "whatsnext" %}} + + +### Для разработчиков приложений + +* [Assign Memory Resources to Containers and Pods](/docs/tasks/configure-pod-container/assign-memory-resource/) + +* [Configure Quality of Service for Pods](/docs/tasks/configure-pod-container/quality-service-pod/) + +### Для администраторов кластера + +* [Configure Default Memory Requests and Limits for a Namespace](/docs/tasks/administer-cluster/memory-default-namespace/) + +* [Configure Default CPU Requests and Limits for a Namespace](/docs/tasks/administer-cluster/cpu-default-namespace/) + +* [Configure Minimum and Maximum Memory Constraints for a Namespace](/docs/tasks/administer-cluster/memory-constraint-namespace/) + +* [Configure Minimum and Maximum CPU Constraints for a Namespace](/docs/tasks/administer-cluster/cpu-constraint-namespace/) + +* [Configure Memory and CPU Quotas for a Namespace](/docs/tasks/administer-cluster/quota-memory-cpu-namespace/) + +* [Configure a Pod Quota for a Namespace](/docs/tasks/administer-cluster/quota-pod-namespace/) + +* [Configure Quotas for API Objects](/docs/tasks/administer-cluster/quota-api-object/) \ No newline at end of file diff --git a/content/ru/docs/tasks/configure-pod-container/assign-memory-resource.md b/content/ru/docs/tasks/configure-pod-container/assign-memory-resource.md new file mode 100644 index 0000000000..826aa6c577 --- /dev/null +++ b/content/ru/docs/tasks/configure-pod-container/assign-memory-resource.md @@ -0,0 +1,352 @@ +--- +title: Задание ресурсов памяти для контейнеров и Pod'ов +content_type: task +weight: 10 +--- + +<!-- overview --> + +На этой странице рассказывается, как настраивать *запрос* памяти и её *лимит* для контейнеров. Контейнеру гарантируется столько памяти, сколько он запросит, но не больше установленных ограничений. + +## {{% heading "prerequisites" %}} + +{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}} + +Каждая нода вашего кластера должна располагать хотя бы 300 Мб памяти. + +Некоторые операции на этой странице предполагают работу +[сервера метрик](https://github.com/kubernetes-incubator/metrics-server) +на вашем кластере. Если сервер метрик у вас уже запущен, следующие действия +можно пропустить. + +Если вы используете Minikube, выполните следующую команду, чтобы запустить +сервер метрик: + +```shell +minikube addons enable metrics-server +``` + +Чтобы проверить работу сервера меток или другого провайдера API ресурсов метрик + (`metrics.k8s.io`), запустите команду: + +```shell +kubectl get apiservices +``` + +Если API ресурсов метрики доступно, в выводе команды будет содержаться +ссылка на `metrics.k8s.io`. + +```shell +NAME +v1beta1.metrics.k8s.io +``` + +<!-- steps --> + +## Создание пространства имён + +Создадим пространство имён, чтобы ресурсы, которыми будем пользоваться в данном упражнении, +были изолированы от остального кластера: + +```shell +kubectl create namespace mem-example +``` + +## Установка запроса памяти и лимита памяти + +Для установки запроса памяти контейнеру подключите поле `resources:requests` в манифест ресурсов контейнера. +Для ограничений по памяти - добавьте `resources:limits`. + +В этом упражнении создаётся Pod, содержащий один контейнер. +Зададим контейнеру запрос памяти в 100 Мб и её ограничение в 200 Мб. Конфигурационный файл для Pod'а: + +{{< codenew file="pods/resource/memory-request-limit.yaml" >}} + +Раздел `args` конфигурационного файла содержит аргументы для контейнера в момент старта. +Аргументы `"--vm-bytes", "150M"` указывают контейнеру попытаться занять 150 Мб памяти. + +Создадим Pod: + +```shell +kubectl apply -f https://k8s.io/examples/pods/resource/memory-request-limit.yaml --namespace=mem-example +``` + +Убедимся, что контейнер Pod'a запущен: + +```shell +kubectl get pod memory-demo --namespace=mem-example +``` + +Посмотрим подробную информацию о Pod'е: + +```shell +kubectl get pod memory-demo --output=yaml --namespace=mem-example +``` + +В выводе мы видим, что для контейнера в Pod'е зарезервировано 100 Мб памяти и выставлено 200 Мб ограничения. + + +```yaml +... +resources: + limits: + memory: 200Mi + requests: + memory: 100Mi +... +``` + +Запустим `kubectl top`, чтобы получить метрики Pod'a: + +```shell +kubectl top pod memory-demo --namespace=mem-example +``` + +Вывод команды показывает, что Pod использовал примерно 162900000 байт памяти - и это около 150 Мб. +Данная величина больше установленного запроса в 100 Мб, но укладывается в имеющееся ограничение на 200 Мб. + +``` +NAME CPU(cores) MEMORY(bytes) +memory-demo <something> 162856960 +``` + +Удалим Pod: + +```shell +kubectl delete pod memory-demo --namespace=mem-example +``` + +## Превышение контейнером лимита памяти + +Контейнер может превысить величину запроса памяти, если нода имеет достаточно ресурсов памяти. +Но превышение заданного ограничения памяти не допускается. Если контейнер запрашивает +больше памяти, чем ему разрешено использовать, то он становится кандидатом на удаление. +Если превышение лимита памяти продолжится, контейнер удаляется. +Если удалённый контейнер может быть перезапущен, то kubelet перезапускает его, как и в случае +любой другой неполадки в работе. + +В этом упражнении создадим Pod, который попытается занять больше памяти, чем для него ограничено. +Ниже представлен конфигурационный файл для Pod'a с одним контейнером, имеющим 50 Мб +на запрос памяти и 100 Мб лимита памяти: + +{{< codenew file="pods/resource/memory-request-limit-2.yaml" >}} + +В разделе `args` можно увидеть, что контейнер будет пытаться занять +250 Мб - и это значительно превышает лимит в 100 Мб. + +Создадим Pod: + +```shell +kubectl apply -f https://k8s.io/examples/pods/resource/memory-request-limit-2.yaml --namespace=mem-example +``` + +Посмотрим подробную информацию о Pod'е: + +```shell +kubectl get pod memory-demo-2 --namespace=mem-example +``` + +В этот момент контейнер уже либо запущен, либо убит. +Будем повторять предыдущую команду, пока контейнер не окажется убитым: + +```shell +NAME READY STATUS RESTARTS AGE +memory-demo-2 0/1 OOMKilled 1 24s +``` + +Посмотрим ещё более подробный вид статуса контейнера: + +```shell +kubectl get pod memory-demo-2 --output=yaml --namespace=mem-example +``` + +В выводе показано, что контейнер был убит по причине недостатка памяти (OOM): + +```shell +lastState: + terminated: + containerID: docker://65183c1877aaec2e8427bc95609cc52677a454b56fcb24340dbd22917c23b10f + exitCode: 137 + finishedAt: 2017-06-20T20:52:19Z + reason: OOMKilled + startedAt: null +``` + +В данном упражнении контейнер может быть перезапущен, поэтому kubelet стартует его. +Выполните следующую команду несколько раз, чтобы увидеть, как контейнер раз за разом +убивается и запускается снова: + +```shell +kubectl get pod memory-demo-2 --namespace=mem-example +``` + +Вывод показывает, что контейнер убит, перезапущен, снова убит, перезапущен, и т.д.: + +``` +kubectl get pod memory-demo-2 --namespace=mem-example +NAME READY STATUS RESTARTS AGE +memory-demo-2 0/1 OOMKilled 1 37s +``` +``` + +kubectl get pod memory-demo-2 --namespace=mem-example +NAME READY STATUS RESTARTS AGE +memory-demo-2 1/1 Running 2 40s +``` + +Посмотрим подробную информацию об истории Pod'a: + +``` +kubectl describe pod memory-demo-2 --namespace=mem-example +``` + +Вывод показывает, что контейнер постоянно запускается и падает: + +``` +... Normal Created Created container with id 66a3a20aa7980e61be4922780bf9d24d1a1d8b7395c09861225b0eba1b1f8511 +... Warning BackOff Back-off restarting failed container +``` + +Посмотрим детальную информацию о нодах на кластере: + +``` +kubectl describe nodes +``` + +В выводе содержится запись о том, что контейнер убивается по причине нехватки памяти: + +``` +Warning OOMKilling Memory cgroup out of memory: Kill process 4481 (stress) score 1994 or sacrifice child +``` + +Удалим Pod: + +```shell +kubectl delete pod memory-demo-2 --namespace=mem-example +``` + +## Установка слишком большого для нод запроса памяти + +Запросы и ограничения памяти связаны с контейнерами, но полезно также рассматривать +эти параметры и для Pod'а. Запросом памяти для Pod'a будет сумма всех запросов памяти +контейнеров, имеющихся в Pod'е. Также и лимитом памяти будет сумма всех ограничений, +установленных для контейнеров. + +Планирование Pod'a основано на запросах. Pod запускается на ноде лишь в случае, если нода +может удовлетворить запрос памяти Pod'a. + +В данном упражнении мы создадим Pod, чей запрос памяти будет превышать ёмкость любой ноды +в кластере. Ниже представлен конфигурационный файл для Pod'a с одним контейнером, +имеющим запрос памяти в 1000 Гб (что наверняка превышает ёмкость любой имеющейся ноды): + +{{< codenew file="pods/resource/memory-request-limit-3.yaml" >}} + +Создадим Pod: + +```shell +kubectl apply -f https://k8s.io/examples/pods/resource/memory-request-limit-3.yaml --namespace=mem-example +``` + +Проверим статус Pod'a: + +```shell +kubectl get pod memory-demo-3 --namespace=mem-example +``` + +Вывод показывает, что Pod имеет статус PENDING. Это значит, что он не запланирован ни на одной ноде, +и такой статус будет сохраняться всё время: + +``` +kubectl get pod memory-demo-3 --namespace=mem-example +NAME READY STATUS RESTARTS AGE +memory-demo-3 0/1 Pending 0 25s +``` + +Посмотрим подробную информацию о Pod'е, включающую события: + +```shell +kubectl describe pod memory-demo-3 --namespace=mem-example +``` + +Вывод показывает невозможность запуска контейнера из-за нехватки памяти на нодах: + +```shell +Events: + ... Reason Message + ------ ------- + ... FailedScheduling No nodes are available that match all of the following predicates:: Insufficient memory (3). +``` + +Удалим Pod: + +```shell +kubectl delete pod memory-demo-3 --namespace=mem-example +``` + +## Единицы измерения памяти + +Ресурсы памяти измеряются в байтах. Их можно задавать просто целым числом либо +целым числом с одним из следующих окончаний: E, P, T, G, M, K, Ei, Pi, Ti, Gi, Mi, Ki. +Например, представленные здесь варианты задают приблизительно одну и ту же величину: + +```shell +128974848, 129e6, 129M , 123Mi +``` + +## Если лимит памяти не задан + +Если вы не задали ограничение памяти для контейнера, возможны следующие варианты: + +* У контейнера отсутствует верхняя граница для памяти, которую он может использовать. +Такой контейнер может занять всю память, доступную на ноде, где он запущен, что, в свою очередь, может вызвать OOM Killer. +Также контейнеры без ограничений по ресурсам имеют более высокие шансы быть убитыми в случае вызова OOM Kill. + +* Контейнер запущен в пространстве имён, в котором настроена величина ограничений по умолчанию. +Тогда контейнеру автоматически присваивается это стандартное значение лимита. +Администраторы кластера могут использовать +[LimitRange](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#limitrange-v1-core) +для задания стандартной величины ограничений по памяти. + +## Мотивация для использования запросов и ограничений памяти + +При помощи задания величины запросов и лимитов памяти для контейнеров, +запущенных на вашем кластере, можно эффективно распоряжаться имеющимися на нодах ресурсами. +Задание Pod'у небольшого запроса памяти даёт хорошие шансы для него быть запланированным. +Ограничение памяти, превышающее величину запроса памяти, позволяет достичь 2 вещей: + +* Pod может иметь всплески активности, в течение которых ему может потребоваться дополнительная память. + +* Величина памяти, доступная Pod'у при повышении активности, ограничена некоторой разумной величиной. + +## Очистка + +Удалим пространство имён. Эта операция удалит все Pod'ы, созданные в рамках данного упражнения: + +```shell +kubectl delete namespace mem-example +``` + +## {{% heading "whatsnext" %}} + + +### Для разработчиков приложений + +* [Assign CPU Resources to Containers and Pods](/docs/tasks/configure-pod-container/assign-cpu-resource/) + +* [Configure Quality of Service for Pods](/docs/tasks/configure-pod-container/quality-service-pod/) + +### Для администраторов кластера + +* [Configure Default Memory Requests and Limits for a Namespace](/docs/tasks/administer-cluster/memory-default-namespace/) + +* [Configure Default CPU Requests and Limits for a Namespace](/docs/tasks/administer-cluster/cpu-default-namespace/) + +* [Configure Minimum and Maximum Memory Constraints for a Namespace](/docs/tasks/administer-cluster/memory-constraint-namespace/) + +* [Configure Minimum and Maximum CPU Constraints for a Namespace](/docs/tasks/administer-cluster/cpu-constraint-namespace/) + +* [Configure Memory and CPU Quotas for a Namespace](/docs/tasks/administer-cluster/quota-memory-cpu-namespace/) + +* [Configure a Pod Quota for a Namespace](/docs/tasks/administer-cluster/quota-pod-namespace/) + +* [Configure Quotas for API Objects](/docs/tasks/administer-cluster/quota-api-object/) \ No newline at end of file diff --git a/content/ru/docs/tutorials/hello-minikube.md b/content/ru/docs/tutorials/hello-minikube.md index acd92cc3f4..2888f1660f 100644 --- a/content/ru/docs/tutorials/hello-minikube.md +++ b/content/ru/docs/tutorials/hello-minikube.md @@ -74,7 +74,7 @@ Katacoda предоставляет бесплатную, встроенную 1. Используйте команду `kubectl create` для создание деплоймента для управления подом. Под запускает контейнер на основе предоставленного Docker образа. ```shell - kubectl create deployment hello-node --image=gcr.io/hello-minikube-zero-install/hello-node + kubectl create deployment hello-node --image=k8s.gcr.io/echoserver:1.4 ``` 2. Посмотреть информацию о Deployment: diff --git a/content/ru/examples/pods/resource/cpu-request-limit-2.yaml b/content/ru/examples/pods/resource/cpu-request-limit-2.yaml new file mode 100644 index 0000000000..f505c77fbb --- /dev/null +++ b/content/ru/examples/pods/resource/cpu-request-limit-2.yaml @@ -0,0 +1,17 @@ +apiVersion: v1 +kind: Pod +metadata: + name: cpu-demo-2 + namespace: cpu-example +spec: + containers: + - name: cpu-demo-ctr-2 + image: vish/stress + resources: + limits: + cpu: "100" + requests: + cpu: "100" + args: + - -cpus + - "2" diff --git a/content/ru/examples/pods/resource/cpu-request-limit.yaml b/content/ru/examples/pods/resource/cpu-request-limit.yaml new file mode 100644 index 0000000000..2cc0b2cf4f --- /dev/null +++ b/content/ru/examples/pods/resource/cpu-request-limit.yaml @@ -0,0 +1,17 @@ +apiVersion: v1 +kind: Pod +metadata: + name: cpu-demo + namespace: cpu-example +spec: + containers: + - name: cpu-demo-ctr + image: vish/stress + resources: + limits: + cpu: "1" + requests: + cpu: "0.5" + args: + - -cpus + - "2" diff --git a/content/ru/examples/pods/resource/memory-request-limit-2.yaml b/content/ru/examples/pods/resource/memory-request-limit-2.yaml new file mode 100644 index 0000000000..99032c4fc2 --- /dev/null +++ b/content/ru/examples/pods/resource/memory-request-limit-2.yaml @@ -0,0 +1,16 @@ +apiVersion: v1 +kind: Pod +metadata: + name: memory-demo-2 + namespace: mem-example +spec: + containers: + - name: memory-demo-2-ctr + image: polinux/stress + resources: + requests: + memory: "50Mi" + limits: + memory: "100Mi" + command: ["stress"] + args: ["--vm", "1", "--vm-bytes", "250M", "--vm-hang", "1"] diff --git a/content/ru/examples/pods/resource/memory-request-limit-3.yaml b/content/ru/examples/pods/resource/memory-request-limit-3.yaml new file mode 100644 index 0000000000..9f089c4a7a --- /dev/null +++ b/content/ru/examples/pods/resource/memory-request-limit-3.yaml @@ -0,0 +1,16 @@ +apiVersion: v1 +kind: Pod +metadata: + name: memory-demo-3 + namespace: mem-example +spec: + containers: + - name: memory-demo-3-ctr + image: polinux/stress + resources: + limits: + memory: "1000Gi" + requests: + memory: "1000Gi" + command: ["stress"] + args: ["--vm", "1", "--vm-bytes", "150M", "--vm-hang", "1"] diff --git a/content/ru/examples/pods/resource/memory-request-limit.yaml b/content/ru/examples/pods/resource/memory-request-limit.yaml new file mode 100644 index 0000000000..985b1308d9 --- /dev/null +++ b/content/ru/examples/pods/resource/memory-request-limit.yaml @@ -0,0 +1,16 @@ +apiVersion: v1 +kind: Pod +metadata: + name: memory-demo + namespace: mem-example +spec: + containers: + - name: memory-demo-ctr + image: polinux/stress + resources: + limits: + memory: "200Mi" + requests: + memory: "100Mi" + command: ["stress"] + args: ["--vm", "1", "--vm-bytes", "150M", "--vm-hang", "1"] diff --git a/content/uk/_index.html b/content/uk/_index.html index 3a0a04e1da..4bef7023f6 100644 --- a/content/uk/_index.html +++ b/content/uk/_index.html @@ -62,7 +62,6 @@ Kubernetes - проект з відкритим вихідним кодом. В <button id="desktopShowVideoButton" onclick="kub.showVideo()">Переглянути відео</button> <br> <br> - <br> <a href="https://events.linuxfoundation.org/events/kubecon-cloudnativecon-europe-2020/" button id="desktopKCButton">Відвідати KubeCon в Амстердамі, 30.03-02.04 2020</a> <br> <br> diff --git a/content/zh/_index.html b/content/zh/_index.html index 1b0ff01700..71688a2e67 100644 --- a/content/zh/_index.html +++ b/content/zh/_index.html @@ -4,7 +4,6 @@ abstract: "自动化的容器部署、扩展和管理" cid: home --- -{{< deprecationwarning >}} {{< blocks/section id="oceanNodes" >}} {{% blocks/feature image="flower" %}} @@ -68,7 +67,6 @@ Kubernetes 是开源系统，可以自由地部署在企业内部，私有云、 <button id="desktopShowVideoButton" onclick="kub.showVideo()">Watch Video</button> <br> <br> - <br> <!-- <a href="https://www.lfasiallc.com/events/kubecon-cloudnativecon-china-2018/" button id="desktopKCButton">Attend KubeCon in Shanghai on Nov. 13-15, 2018</a> --> <a href="https://www.lfasiallc.com/events/kubecon-cloudnativecon-china-2018/" button id="desktopKCButton">参加11月13日到15日的上海 KubeCon</a> <br> @@ -86,4 +84,4 @@ Kubernetes 是开源系统，可以自由地部署在企业内部，私有云、 {{< blocks/kubernetes-features >}} -{{< blocks/case-studies >}} +{{< blocks/case-studies >}} \ No newline at end of file diff --git a/content/zh/blog/_posts/2016-08-00-Stateful-Applications-Using-Kubernetes-Datera.md b/content/zh/blog/_posts/2016-08-00-Stateful-Applications-Using-Kubernetes-Datera.md new file mode 100644 index 0000000000..8941ce5a54 --- /dev/null +++ b/content/zh/blog/_posts/2016-08-00-Stateful-Applications-Using-Kubernetes-Datera.md @@ -0,0 +1,696 @@ +--- +title: " 使用 Kubernetes Pet Sets 和 Datera Elastic Data Fabric 的 FlexVolume 扩展有状态的应用程序 " +date: 2016-08-29 +slug: stateful-applications-using-kubernetes-datera +url: /zh/blog/2016/08/Stateful-Applications-Using-Kubernetes-Datera +--- +<!-- +--- +title: " Scaling Stateful Applications using Kubernetes Pet Sets and FlexVolumes with Datera Elastic Data Fabric " +date: 2016-08-29 +slug: stateful-applications-using-kubernetes-datera +url: /blog/2016/08/Stateful-Applications-Using-Kubernetes-Datera +--- +---> + +<!-- +_Editor’s note: today’s guest post is by Shailesh Mittal, Software Architect and Ashok Rajagopalan, Sr Director Product at Datera Inc, talking about Stateful Application provisioning with Kubernetes on Datera Elastic Data Fabric._ +---> +_编者注：今天的邀请帖子来自 Datera 公司的软件架构师 Shailesh Mittal 和高级产品总监 Ashok Rajagopalan，介绍在 Datera Elastic Data Fabric 上用 Kubernetes 配置状态应用程序。_ + +<!-- +**Introduction** + +Persistent volumes in Kubernetes are foundational as customers move beyond stateless workloads to run stateful applications. While Kubernetes has supported stateful applications such as MySQL, Kafka, Cassandra, and Couchbase for a while, the introduction of Pet Sets has significantly improved this support. In particular, the procedure to sequence the provisioning and startup, the ability to scale and associate durably by [Pet Sets](/docs/user-guide/petset/) has provided the ability to automate to scale the “Pets” (applications that require consistent handling and durable placement). +---> +**简介** + +用户从无状态工作负载转移到运行有状态应用程序，Kubernetes 中的持久卷是基础。虽然 Kubernetes 早已支持有状态的应用程序，比如 MySQL、Kafka、Cassandra 和 Couchbase，但是 Pet Sets 的引入明显改善了情况。特别是，[Pet Sets](/docs/user-guide/petset/) 具有持续扩展和关联的能力，在配置和启动的顺序过程中，可以自动缩放“Pets”（需要连续处理和持久放置的应用程序）。 + +<!-- +Datera, elastic block storage for cloud deployments, has [seamlessly integrated with Kubernetes](http://datera.io/blog-library/8/19/datera-simplifies-stateful-containers-on-kubernetes-13) through the [FlexVolume](/docs/user-guide/volumes/#flexvolume) framework. Based on the first principles of containers, Datera allows application resource provisioning to be decoupled from the underlying physical infrastructure. This brings clean contracts (aka, no dependency or direct knowledge of the underlying physical infrastructure), declarative formats, and eventually portability to stateful applications. +---> +Datera 是用于云部署的弹性块存储，可以通过 [FlexVolume](/docs/user-guide/volumes/#flexvolume) 框架与 [Kubernetes 无缝集成](http://datera.io/blog-library/8/19/datera-simplifies-stateful-containers-on-kubernetes-13)。基于容器的基本原则，Datera 允许应用程序的资源配置与底层物理基础架构分离，为有状态的应用程序提供简洁的协议（也就是说，不依赖底层物理基础结构及其相关内容）、声明式格式和最后移植的能力。 + +<!-- +While Kubernetes allows for great flexibility to define the underlying application infrastructure through yaml configurations, Datera allows for that configuration to be passed to the storage infrastructure to provide persistence. Through the notion of Datera AppTemplates, in a Kubernetes environment, stateful applications can be automated to scale. +---> +Kubernetes 可以通过 yaml 配置来灵活定义底层应用程序基础架构，而 Datera 可以将该配置传递给存储基础结构以提供持久性。通过 Datera AppTemplates 声明，在 Kubernetes 环境中，有状态的应用程序可以自动扩展。 + + + + +<!-- +**Deploying Persistent Storage** + + + +Persistent storage is defined using the Kubernetes [PersistentVolume](/docs/user-guide/persistent-volumes/#persistent-volumes) subsystem. PersistentVolumes are volume plugins and define volumes that live independently of the lifecycle of the pod that is using it. They are implemented as NFS, iSCSI, or by cloud provider specific storage system. Datera has developed a volume plugin for PersistentVolumes that can provision iSCSI block storage on the Datera Data Fabric for Kubernetes pods. +---> +**部署永久性存储** + + + +永久性存储是通过 Kubernetes 的子系统 [PersistentVolume](/docs/user-guide/persistent-volumes/#persistent-volumes) 定义的。PersistentVolumes 是卷插件，它定义的卷的生命周期和使用它的 Pod 相互独立。PersistentVolumes 由 NFS、iSCSI 或云提供商的特定存储系统实现。Datera 开发了用于 PersistentVolumes 的卷插件，可以在 Datera Data Fabric 上为 Kubernetes 的 Pod 配置 iSCSI 块存储。 + + +<!-- +The Datera volume plugin gets invoked by kubelets on minion nodes and relays the calls to the Datera Data Fabric over its REST API. Below is a sample deployment of a PersistentVolume with the Datera plugin: +---> +Datera 卷插件从 minion nodes 上的 kubelet 调用，并通过 REST API 回传到 Datera Data Fabric。以下是带有 Datera 插件的 PersistentVolume 的部署示例： + + + ``` + apiVersion: v1 + + kind: PersistentVolume + + metadata: + + name: pv-datera-0 + + spec: + + capacity: + + storage: 100Gi + + accessModes: + + - ReadWriteOnce + + persistentVolumeReclaimPolicy: Retain + + flexVolume: + + driver: "datera/iscsi" + + fsType: "xfs" + + options: + + volumeID: "kube-pv-datera-0" + + size: “100" + + replica: "3" + + backstoreServer: "[tlx170.tlx.daterainc.com](http://tlx170.tlx.daterainc.com/):7717” + ``` + + +<!-- +This manifest defines a PersistentVolume of 100 GB to be provisioned in the Datera Data Fabric, should a pod request the persistent storage. +---> +为 Pod 申请 PersistentVolume，要按照以下清单在 Datera Data Fabric 中配置 100 GB 的 PersistentVolume。 + + + + ``` +[root@tlx241 /]# kubectl get pv + +NAME CAPACITY ACCESSMODES STATUS CLAIM REASON AGE + +pv-datera-0 100Gi RWO Available 8s + +pv-datera-1 100Gi RWO Available 2s + +pv-datera-2 100Gi RWO Available 7s + +pv-datera-3 100Gi RWO Available 4s + ``` + + +<!-- +**Configuration** + + + +The Datera PersistenceVolume plugin is installed on all minion nodes. When a pod lands on a minion node with a valid claim bound to the persistent storage provisioned earlier, the Datera plugin forwards the request to create the volume on the Datera Data Fabric. All the options that are specified in the PersistentVolume manifest are sent to the plugin upon the provisioning request. +---> +**配置** + + + +Datera PersistenceVolume 插件安装在所有 minion node 上。minion node 的声明是绑定到之前设置的永久性存储上的，当 Pod 进入具备有效声明的 minion node 上时，Datera 插件会转发请求，从而在 Datera Data Fabric 上创建卷。根据配置请求，PersistentVolume 清单中所有指定的选项都将发送到插件。 + +<!-- +Once a volume is provisioned in the Datera Data Fabric, volumes are presented as an iSCSI block device to the minion node, and kubelet mounts this device for the containers (in the pod) to access it. +---> +在 Datera Data Fabric 中配置的卷会作为 iSCSI 块设备呈现给 minion node，并且 kubelet 将该设备安装到容器（在 Pod 中）进行访问。 + + ![](https://lh4.googleusercontent.com/ILlUm1HrWhGa8uTt97dQ786Gn20FHFZkavfucz05NHv6moZWiGDG7GlELM6o4CSzANWvZckoAVug5o4jMg17a-PbrfD1FRbDPeUCIc8fKVmVBNUsUPshWanXYkBa3gIJy5BnhLmZ) + + +<!-- +**Using Persistent Storage** + + + +Kubernetes PersistentVolumes are used along with a pod using PersistentVolume Claims. Once a claim is defined, it is bound to a PersistentVolume matching the claim’s specification. A typical claim for the PersistentVolume defined above would look like below: +---> +**使用永久性存储** + + + +Kubernetes PersistentVolumes 与具备 PersistentVolume Claims 的 Pod 一起使用。定义声明后，会被绑定到与声明规范匹配的 PersistentVolume 上。上面提到的定义 PersistentVolume 的典型声明如下所示： + + + + ``` +kind: PersistentVolumeClaim + +apiVersion: v1 + +metadata: + + name: pv-claim-test-petset-0 + +spec: + + accessModes: + + - ReadWriteOnce + + resources: + + requests: + + storage: 100Gi + ``` + + +<!-- +When this claim is defined and it is bound to a PersistentVolume, resources can be used with the pod specification: +---> +定义这个声明并将其绑定到 PersistentVolume 时，资源与 Pod 规范可以一起使用： + + + + ``` +[root@tlx241 /]# kubectl get pv + +NAME CAPACITY ACCESSMODES STATUS CLAIM REASON AGE + +pv-datera-0 100Gi RWO Bound default/pv-claim-test-petset-0 6m + +pv-datera-1 100Gi RWO Bound default/pv-claim-test-petset-1 6m + +pv-datera-2 100Gi RWO Available 7s + +pv-datera-3 100Gi RWO Available 4s + + +[root@tlx241 /]# kubectl get pvc + +NAME STATUS VOLUME CAPACITY ACCESSMODES AGE + +pv-claim-test-petset-0 Bound pv-datera-0 0 3m + +pv-claim-test-petset-1 Bound pv-datera-1 0 3m + ``` + + +<!-- +A pod can use a PersistentVolume Claim like below: +---> +Pod 可以使用 PersistentVolume 声明，如下所示： + + + ``` +apiVersion: v1 + +kind: Pod + +metadata: + + name: kube-pv-demo + +spec: + + containers: + + - name: data-pv-demo + + image: nginx + + volumeMounts: + + - name: test-kube-pv1 + + mountPath: /data + + ports: + + - containerPort: 80 + + volumes: + + - name: test-kube-pv1 + + persistentVolumeClaim: + + claimName: pv-claim-test-petset-0 + ``` + + +<!-- +The result is a pod using a PersistentVolume Claim as a volume. It in-turn sends the request to the Datera volume plugin to provision storage in the Datera Data Fabric. +---> +程序的结果是 Pod 将 PersistentVolume Claim 作为卷。依次将请求发送到 Datera 卷插件，然后在 Datera Data Fabric 中配置存储。 + + + + ``` +[root@tlx241 /]# kubectl describe pods kube-pv-demo + +Name: kube-pv-demo + +Namespace: default + +Node: tlx243/172.19.1.243 + +Start Time: Sun, 14 Aug 2016 19:17:31 -0700 + +Labels: \<none\> + +Status: Running + +IP: 10.40.0.3 + +Controllers: \<none\> + +Containers: + + data-pv-demo: + + Container ID: [docker://ae2a50c25e03143d0dd721cafdcc6543fac85a301531110e938a8e0433f74447](about:blank) + + Image: nginx + + Image ID: [docker://sha256:0d409d33b27e47423b049f7f863faa08655a8c901749c2b25b93ca67d01a470d](about:blank) + + Port: 80/TCP + + State: Running + + Started: Sun, 14 Aug 2016 19:17:34 -0700 + + Ready: True + + Restart Count: 0 + + Environment Variables: \<none\> + +Conditions: + + Type Status + + Initialized True + + Ready True + + PodScheduled True + +Volumes: + + test-kube-pv1: + + Type: PersistentVolumeClaim (a reference to a PersistentVolumeClaim in the same namespace) + + ClaimName: pv-claim-test-petset-0 + + ReadOnly: false + + default-token-q3eva: + + Type: Secret (a volume populated by a Secret) + + SecretName: default-token-q3eva + + QoS Tier: BestEffort + +Events: + + FirstSeen LastSeen Count From SubobjectPath Type Reason Message + + --------- -------- ----- ---- ------------- -------- ------ ------- + + 43s 43s 1 {default-scheduler } Normal Scheduled Successfully assigned kube-pv-demo to tlx243 + + 42s 42s 1 {kubelet tlx243} spec.containers{data-pv-demo} Normal Pulling pulling image "nginx" + + 40s 40s 1 {kubelet tlx243} spec.containers{data-pv-demo} Normal Pulled Successfully pulled image "nginx" + + 40s 40s 1 {kubelet tlx243} spec.containers{data-pv-demo} Normal Created Created container with docker id ae2a50c25e03 + + 40s 40s 1 {kubelet tlx243} spec.containers{data-pv-demo} Normal Started Started container with docker id ae2a50c25e03 + ``` + + +<!-- +The persistent volume is presented as iSCSI device at minion node (tlx243 in this case): +---> +永久卷在 minion node（在本例中为 tlx243）中显示为 iSCSI 设备： + + + ``` +[root@tlx243 ~]# lsscsi + +[0:2:0:0] disk SMC SMC2208 3.24 /dev/sda + +[11:0:0:0] disk DATERA IBLOCK 4.0 /dev/sdb + + +[root@tlx243 datera~iscsi]# mount ``` grep sdb + +/dev/sdb on /var/lib/kubelet/pods/6b99bd2a-628e-11e6-8463-0cc47ab41442/volumes/datera~iscsi/pv-datera-0 type xfs (rw,relatime,attr2,inode64,noquota) + ``` + + +<!-- +Containers running in the pod see this device mounted at /data as specified in the manifest: +---> +在 Pod 中运行的容器按照清单中将设备安装在 /data 上： + + + ``` +[root@tlx241 /]# kubectl exec kube-pv-demo -c data-pv-demo -it bash + +root@kube-pv-demo:/# mount ``` grep data + +/dev/sdb on /data type xfs (rw,relatime,attr2,inode64,noquota) + ``` + + + +<!-- +**Using Pet Sets** + + + +Typically, pods are treated as stateless units, so if one of them is unhealthy or gets superseded, Kubernetes just disposes it. In contrast, a PetSet is a group of stateful pods that has a stronger notion of identity. The goal of a PetSet is to decouple this dependency by assigning identities to individual instances of an application that are not anchored to the underlying physical infrastructure. +---> +**使用 Pet Sets** + + + +通常，Pod 被视为无状态单元，因此，如果其中之一状态异常或被取代，Kubernetes 会将其丢弃。相反，PetSet 是一组有状态的 Pod，具有更强的身份概念。PetSet 可以将标识分配给应用程序的各个实例，这些应用程序没有与底层物理结构连接，PetSet 可以消除这种依赖性。 + + + +<!-- +A PetSet requires {0..n-1} Pets. Each Pet has a deterministic name, PetSetName-Ordinal, and a unique identity. Each Pet has at most one pod, and each PetSet has at most one Pet with a given identity. A PetSet ensures that a specified number of “pets” with unique identities are running at any given time. The identity of a Pet is comprised of: + +- a stable hostname, available in DNS +- an ordinal index +- stable storage: linked to the ordinal & hostname + + +A typical PetSet definition using a PersistentVolume Claim looks like below: +---> +每个 PetSet 需要{0..n-1}个 Pet。每个 Pet 都有一个确定的名字、PetSetName-Ordinal 和唯一的身份。每个 Pet 最多有一个 Pod，每个 PetSet 最多包含一个给定身份的 Pet。要确保每个 PetSet 在任何特定时间运行时，具有唯一标识的“pet”的数量都是确定的。Pet 的身份标识包括以下几点： + +- 一个稳定的主机名，可以在 DNS 中使用 +- 一个序号索引 +- 稳定的存储：链接到序号和主机名 + + +使用 PersistentVolume Claim 定义 PetSet 的典型例子如下所示： + + + ``` +# A headless service to create DNS records + +apiVersion: v1 + +kind: Service + +metadata: + + name: test-service + + labels: + + app: nginx + +spec: + + ports: + + - port: 80 + + name: web + + clusterIP: None + + selector: + + app: nginx + +--- + +apiVersion: apps/v1alpha1 + +kind: PetSet + +metadata: + + name: test-petset + +spec: + + serviceName: "test-service" + + replicas: 2 + + template: + + metadata: + + labels: + + app: nginx + + annotations: + + [pod.alpha.kubernetes.io/initialized:](http://pod.alpha.kubernetes.io/initialized:) "true" + + spec: + + terminationGracePeriodSeconds: 0 + + containers: + + - name: nginx + + image: [gcr.io/google\_containers/nginx-slim:0.8](http://gcr.io/google_containers/nginx-slim:0.8) + + ports: + + - containerPort: 80 + + name: web + + volumeMounts: + + - name: pv-claim + + mountPath: /data + + volumeClaimTemplates: + + - metadata: + + name: pv-claim + + annotations: + + [volume.alpha.kubernetes.io/storage-class:](http://volume.alpha.kubernetes.io/storage-class:) anything + + spec: + + accessModes: ["ReadWriteOnce"] + + resources: + + requests: + + storage: 100Gi + ``` + + +<!-- +We have the following PersistentVolume Claims available: +---> +我们提供以下 PersistentVolume Claim： + + + ``` +[root@tlx241 /]# kubectl get pvc + +NAME STATUS VOLUME CAPACITY ACCESSMODES AGE + +pv-claim-test-petset-0 Bound pv-datera-0 0 41m + +pv-claim-test-petset-1 Bound pv-datera-1 0 41m + +pv-claim-test-petset-2 Bound pv-datera-2 0 5s + +pv-claim-test-petset-3 Bound pv-datera-3 0 2s + ``` + + +<!-- +When this PetSet is provisioned, two pods get instantiated: +---> +配置 PetSet 时，将实例化两个 Pod： + + + ``` +[root@tlx241 /]# kubectl get pods + +NAMESPACE NAME READY STATUS RESTARTS AGE + +default test-petset-0 1/1 Running 0 7s + +default test-petset-1 1/1 Running 0 3s + ``` + + +<!-- +Here is how the PetSet test-petset instantiated earlier looks like: +---> +以下是一个 PetSet：test-petset 实例化之前的样子： + + + + ``` +[root@tlx241 /]# kubectl describe petset test-petset + +Name: test-petset + +Namespace: default + +Image(s): [gcr.io/google\_containers/nginx-slim:0.8](http://gcr.io/google_containers/nginx-slim:0.8) + +Selector: app=nginx + +Labels: app=nginx + +Replicas: 2 current / 2 desired + +Annotations: \<none\> + +CreationTimestamp: Sun, 14 Aug 2016 19:46:30 -0700 + +Pods Status: 2 Running / 0 Waiting / 0 Succeeded / 0 Failed + +No volumes. + +No events. + ``` + + +<!-- +Once a PetSet is instantiated, such as test-petset below, upon increasing the number of replicas (i.e. the number of pods started with that PetSet), more pods get instantiated and more PersistentVolume Claims get bound to new pods: +---> +一旦实例化 PetSet（例如下面的 test-petset），随着副本数（从 PetSet 的初始 Pod 数量算起）的增加，实例化的 Pod 将变得更多，并且更多的 PersistentVolume Claim 会绑定到新的 Pod 上： + + + ``` +[root@tlx241 /]# kubectl patch petset test-petset -p'{"spec":{"replicas":"3"}}' + +"test-petset” patched + + +[root@tlx241 /]# kubectl describe petset test-petset + +Name: test-petset + +Namespace: default + +Image(s): [gcr.io/google\_containers/nginx-slim:0.8](http://gcr.io/google_containers/nginx-slim:0.8) + +Selector: app=nginx + +Labels: app=nginx + +Replicas: 3 current / 3 desired + +Annotations: \<none\> + +CreationTimestamp: Sun, 14 Aug 2016 19:46:30 -0700 + +Pods Status: 3 Running / 0 Waiting / 0 Succeeded / 0 Failed + +No volumes. + +No events. + + +[root@tlx241 /]# kubectl get pods + +NAME READY STATUS RESTARTS AGE + +test-petset-0 1/1 Running 0 29m + +test-petset-1 1/1 Running 0 28m + +test-petset-2 1/1 Running 0 9s + ``` + + +<!-- +Now the PetSet is running 3 pods after patch application. +---> +现在，应用修补程序后，PetSet 正在运行3个 Pod。 + + + +<!-- +When the above PetSet definition is patched to have one more replica, it introduces one more pod in the system. This in turn results in one more volume getting provisioned on the Datera Data Fabric. So volumes get dynamically provisioned and attached to a pod upon the PetSet scaling up. +---> +当上述 PetSet 定义修补完成，会产生另一个副本，PetSet 将在系统中引入另一个 pod。反之，这会导致在 Datera Data Fabric 上配置更多的卷。因此，在 PetSet 进行扩展时，要配置动态卷并将其附加到 Pod 上。 + + +<!-- +To support the notion of durability and consistency, if a pod moves from one minion to another, volumes do get attached (mounted) to the new minion node and detached (unmounted) from the old minion to maintain persistent access to the data. +---> +为了平衡持久性和一致性的概念，如果 Pod 从一个 Minion 转移到另一个，卷确实会附加（安装）到新的 minion node 上，并与旧的 Minion 分离（卸载），从而实现对数据的持久访问。 + + + +<!-- +**Conclusion** + + + +This demonstrates Kubernetes with Pet Sets orchestrating stateful and stateless workloads. While the Kubernetes community is working on expanding the FlexVolume framework’s capabilities, we are excited that this solution makes it possible for Kubernetes to be run more widely in the datacenters. +---> +**结论** + + + +本文展示了具备 Pet Sets 的 Kubernetes 协调有状态和无状态工作负载。当 Kubernetes 社区致力于扩展 FlexVolume 框架的功能时，我们很高兴这个解决方案使 Kubernetes 能够在数据中心广泛运行。 + + +<!-- +Join and contribute: Kubernetes [Storage SIG](https://groups.google.com/forum/#!forum/kubernetes-sig-storage). +---> +加入我们并作出贡献：Kubernetes [Storage SIG](https://groups.google.com/forum/#!forum/kubernetes-sig-storage). + + + +<!-- +- [Download Kubernetes](http://get.k8s.io/) +- Get involved with the Kubernetes project on [GitHub](https://github.com/kubernetes/kubernetes) +- Post questions (or answer questions) on [Stack Overflow](http://stackoverflow.com/questions/tagged/kubernetes) +- Connect with the community on the [k8s Slack](http://slack.k8s.io/) +- Follow us on Twitter [@Kubernetesio](https://twitter.com/kubernetesio) for latest updates +---> +- [下载 Kubernetes](http://get.k8s.io/) +- 参与 Kubernetes 项目 [GitHub](https://github.com/kubernetes/kubernetes) +- 发布问题（或者回答问题） [Stack Overflow](http://stackoverflow.com/questions/tagged/kubernetes) +- 联系社区 [k8s Slack](http://slack.k8s.io/) +- 在 Twitter 上关注我们 [@Kubernetesio](https://twitter.com/kubernetesio) for latest updates diff --git a/content/zh/blog/_posts/2018-01-00-Kubernetes-V19-Beta-Windows-Support.md b/content/zh/blog/_posts/2018-01-00-Kubernetes-V19-Beta-Windows-Support.md new file mode 100644 index 0000000000..3567bb17f2 --- /dev/null +++ b/content/zh/blog/_posts/2018-01-00-Kubernetes-V19-Beta-Windows-Support.md @@ -0,0 +1,144 @@ +--- +title: Kubernetes 1.9 对 Windows Server 容器提供 Beta 版本支持 +date: 2018-01-09 +slug: kubernetes-v19-beta-windows-support +url: /blog/2018/01/Kubernetes-V19-Beta-Windows-Support +--- +<!-- +--- +title: Kubernetes v1.9 releases beta support for Windows Server Containers +date: 2018-01-09 +slug: kubernetes-v19-beta-windows-support +url: /blog/2018/01/Kubernetes-V19-Beta-Windows-Support +--- +---> + +<!-- +With the release of Kubernetes v1.9, our mission of ensuring Kubernetes works well everywhere and for everyone takes a great step forward. We’ve advanced support for Windows Server to beta along with continued feature and functional advancements on both the Kubernetes and Windows platforms. SIG-Windows has been working since March of 2016 to open the door for many Windows-specific applications and workloads to run on Kubernetes, significantly expanding the implementation scenarios and the enterprise reach of Kubernetes. +---> +随着 Kubernetes v1.9 的发布，我们确保所有人在任何地方都能正常运行 Kubernetes 的使命前进了一大步。我们的 Beta 版本对 Windows Server 的支持进行了升级，并且在 Kubernetes 和 Windows 平台上都提供了持续的功能改进。为了在 Kubernetes 上运行许多特定于 Windows 的应用程序和工作负载，SIG-Windows 自2016年3月以来一直在努力，大大扩展了 Kubernetes 的实现场景和企业适用范围。 + +<!-- +Enterprises of all sizes have made significant investments in .NET and Windows based applications. Many enterprise portfolios today contain .NET and Windows, with Gartner claiming that [80%](http://www.gartner.com/document/3446217) of enterprise apps run on Windows. According to StackOverflow Insights, 40% of professional developers use the .NET programming languages (including .NET Core). +---> +各种规模的企业都在 .NET 和基于 Windows 的应用程序上进行了大量投资。如今许多企业产品组合都包含 .NET 和 Windows，Gartner 声称 [80%](http://www.gartner.com/document/3446217) 的企业应用都在 Windows 上运行。根据 StackOverflow Insights，40% 的专业开发人员使用 .NET 编程语言（包括 .NET Core）。 + +<!-- +But why is all this information important? It means that enterprises have both legacy and new born-in-the-cloud (microservice) applications that utilize a wide array of programming frameworks. There is a big push in the industry to modernize existing/legacy applications to containers, using an approach similar to “lift and shift”. Modernizing existing applications into containers also provides added flexibility for new functionality to be introduced in additional Windows or Linux containers. Containers are becoming the de facto standard for packaging, deploying, and managing both existing and microservice applications. IT organizations are looking for an easier and homogenous way to orchestrate and manage containers across their Linux and Windows environments. Kubernetes v1.9 now offers beta support for Windows Server containers, making it the clear choice for orchestrating containers of any kind. +---> +但为什么这些信息都很重要？这意味着企业既有传统的，也有新生的云（microservice）应用程序，利用了大量的编程框架。业界正在大力推动将现有/遗留应用程序现代化到容器中，使用类似于“提升和转移”的方法。同时，也能灵活地向其他 Windows 或 Linux 容器引入新功能。容器正在成为打包、部署和管理现有程序和微服务应用程序的业界标准。IT 组织正在寻找一种更简单且一致的方法来跨 Linux 和 Windows 环境进行协调和管理容器。Kubernetes v1.9 现在对 Windows Server 容器提供了 Beta 版本支持，使之成为策划任何类型容器的明确选择。 + + + +<!-- +### Features +Alpha support for Windows Server containers in Kubernetes was great for proof-of-concept projects and visualizing the road map for support of Windows in Kubernetes. The alpha release had significant drawbacks, however, and lacked many features, especially in networking. SIG-Windows, Microsoft, Cloudbase Solutions, Apprenda, and other community members banded together to create a comprehensive beta release, enabling Kubernetes users to start evaluating and using Windows. +---> +### 特点 +Kubernetes 中对 Windows Server 容器的 Alpha 支持是非常有用的，尤其是对于概念项目和可视化 Kubernetes 中 Windows 支持的路线图。然而，Alpha 版本有明显的缺点，并且缺少许多特性，特别是在网络方面。SIG Windows、Microsoft、Cloudbase Solutions、Apprenda 和其他社区成员联合创建了一个全面的 Beta 版本，使 Kubernetes 用户能够开始评估和使用 Windows。 + +<!-- +Some key feature improvements for Windows Server containers on Kubernetes include: + +- Improved support for pods! Multiple Windows Server containers in a pod can now share the network namespace using network compartments in Windows Server. This feature brings the concept of a pod to parity with Linux-based containers +- Reduced network complexity by using a single network endpoint per pod +- Kernel-Based load-balancing using the Virtual Filtering Platform (VFP) Hyper-v Switch Extension (analogous to Linux iptables) +- Container Runtime Interface (CRI) pod and node level statistics. Windows Server containers can now be profiled for Horizontal Pod Autoscaling using performance metrics gathered from the pod and the node +---> +Kubernetes 对 Windows 服务器容器的一些关键功能改进包括： + +- 改进了对 Pod 的支持！Pod 中多个 Windows Server 容器现在可以使用 Windows Server 中的网络隔离专区共享网络命名空间。此功能中 Pod 的概念相当于基于 Linux 的容器 +- 可通过每个 Pod 使用单个网络端点来降低网络复杂性 +- 可以使用 Virtual Filtering Platform（VFP）的 Hyper-v Switch Extension（类似于 Linux iptables）达到基于内核的负载平衡 +- 具备 Container Runtime Interface（CRI）的 Pod 和 Node 级别的统计信息。可以使用从 Pod 和节点收集的性能指标配置 Windows Server 容器的 Horizontal Pod Autoscaling +<!-- +- Support for kubeadm commands to add Windows Server nodes to a Kubernetes environment. Kubeadm simplifies the provisioning of a Kubernetes cluster, and with the support for Windows Server, you can use a single tool to deploy Kubernetes in your infrastructure +- Support for ConfigMaps, Secrets, and Volumes. These are key features that allow you to separate, and in some cases secure, the configuration of the containers from the implementation +The crown jewels of Kubernetes 1.9 Windows support, however, are the networking enhancements. With the release of Windows Server 1709, Microsoft has enabled key networking capabilities in the operating system and the Windows Host Networking Service (HNS) that paved the way to produce a number of CNI plugins that work with Windows Server containers in Kubernetes. The Layer-3 routed and network overlay plugins that are supported with Kubernetes 1.9 are listed below: +---> +- 支持 kubeadm 命令将 Windows Server 的 Node 添加到 Kubernetes 环境。Kubeadm 简化了 Kubernetes 集群的配置，通过对 Windows Server 的支持，您可以在您的基础配置中使用单一的工具部署 Kubernetes +- 支持 ConfigMaps, Secrets, 和 Volumes。这些是非常关键的特性，您可以将容器的配置从实施体系中分离出来，并且在大部分情况下是安全的 +然而，kubernetes 1.9 windows 支持的最大亮点是网络增强。随着 Windows 服务器 1709 的发布，微软在操作系统和 Windows Host Networking Service（HNS）中启用了关键的网络功能，这为创造大量与 Kubernetes 中的 Windows 服务器容器一起工作的 CNI 插件铺平了道路。Kubernetes 1.9 支持的第三层路由和网络覆盖插件如下所示： + +<!-- +1. Upstream L3 Routing - IP routes configured in upstream ToR +2. Host-Gateway - IP routes configured on each host +3. Open vSwitch (OVS) & Open Virtual Network (OVN) with Overlay - Supports STT and Geneve tunneling types +You can read more about each of their [configuration, setup, and runtime capabilities](/docs/getting-started-guides/windows/) to make an informed selection for your networking stack in Kubernetes. +---> +1. 上游 L3 路由 - 上游 ToR 中配置的 IP 路由 +2. Host-Gateway - 在每个主机上配置的 IP 路由 +3. 具有 Overlay 的 Open vSwitch（OVS）和 Open Virtual Network（OVN） - 支持 STT 和 Geneve 的 tunneling 类型 +您可以阅读更多有关 [配置、设置和运行时功能](/docs/getting-started-guides/windows/) 的信息，以便在 Kubernetes 中为您的网络堆栈做出明智的选择。 + +<!-- +Even though you have to continue running the Kubernetes Control Plane and Master Components in Linux, you are now able to introduce Windows Server as a Node in Kubernetes. As a community, this is a huge milestone and achievement. We will now start seeing .NET, .NET Core, ASP.NET, IIS, Windows Services, Windows executables and many more windows-based applications in Kubernetes. +---> +如果您需要继续在 Linux 中运行 Kubernetes Control Plane 和 Master Components，现在也可以将 Windows Server 作为 Kubernetes 中的一个节点引入。对一个社区来说，这是一个巨大的里程碑和成就。现在，我们将会在 Kubernetes 中看到 .NET，.NET Core，ASP.NET，IIS，Windows 服务，Windows 可执行文件以及更多基于 Windows 的应用程序。 + +<!-- +### What’s coming next +A lot of work went into this beta release, but the community realizes there are more areas of investment needed before we can release Windows support as GA (General Availability) for production workloads. Some keys areas of focus for the first two quarters of 2018 include: +---> +### 接下来还会有什么 +这个 Beta 版本进行了大量工作，但是社区意识到在将 Windows 支持作为生产工作负载发布为 GA（General Availability）之前，我们需要更多领域的投资。2018年前两个季度的重点关注领域包括： + +<!-- +1. Continue to make progress in the area of networking. Additional CNI plugins are under development and nearing completion +- Overlay - win-overlay (vxlan or IP-in-IP encapsulation using Flannel)  +- Win-l2bridge (host-gateway)  +- OVN using cloud networking - without overlays +- Support for Kubernetes network policies in ovn-kubernetes +- Support for Hyper-V Isolation +- Support for StatefulSet functionality for stateful applications +- Produce installation artifacts and documentation that work on any infrastructure and across many public cloud providers like Microsoft Azure, Google Cloud, and Amazon AWS +- Continuous Integration/Continuous Delivery (CI/CD) infrastructure for SIG-Windows +- Scalability and Performance testing +Even though we have not committed to a timeline for GA, SIG-Windows estimates a GA release in the first half of 2018. +---> +1. 继续在网络领域取得更多进展。其他 CNI 插件正在开发中，并且即将完成 +- Overlay - win-Overlay（vxlan 或 IP-in-IP 使用 Flannel 封装） +- Win-l2bridge（host-gateway） +- 使用云网络的 OVN - 不再依赖 Overlay +- 在 ovn-Kubernetes 中支持 Kubernetes 网络策略 +- 支持 Hyper-V Isolation +- 支持有状态应用程序的 StatefulSet 功能 +- 生成适用于任何基础架构以及跨多公共云提供商（例如 Microsoft Azure，Google Cloud 和 Amazon AWS）的安装工具和文档 +- SIG-Windows 的 Continuous Integration/Continuous Delivery（CI/CD）基础结构 +- 可伸缩性和性能测试 +尽管我们尚未承诺正式版的具体时间线，但估计 SIG-Windows 将于2018年上半年正式发布。 + + + +<!-- +### Get Involved +As we continue to make progress towards General Availability of this feature in Kubernetes, we welcome you to get involved, contribute code, provide feedback, deploy Windows Server containers to your Kubernetes cluster, or simply join our community. +---> +### 加入我们 +随着我们在 Kubernetes 的普遍可用性方向不断取得进展，我们欢迎您参与进来，贡献代码、提供反馈，将 Windows 服务器容器部署到 Kubernetes 集群，或者干脆加入我们的社区。 + +<!-- +- If you want to get started on deploying Windows Server containers in Kubernetes, read our getting started guide at [/docs/getting-started-guides/windows/](/docs/getting-started-guides/windows/) +- We meet every other Tuesday at 12:30 Eastern Standard Time (EST) at [https://zoom.us/my/sigwindows](https://zoom.us/my/sigwindows). All our meetings are recorded on youtube and referenced at [https://www.youtube.com/playlist?list=PL69nYSiGNLP2OH9InCcNkWNu2bl-gmIU4](https://www.youtube.com/playlist?list=PL69nYSiGNLP2OH9InCcNkWNu2bl-gmIU4) +- Chat with us on Slack at [https://kubernetes.slack.com/messages/sig-windows](https://kubernetes.slack.com/messages/sig-windows) +- Find us on GitHub at [https://github.com/kubernetes/community/tree/master/sig-windows](https://github.com/kubernetes/community/tree/master/sig-windows) +---> +- 如果你想要开始在 Kubernetes 中部署 Windows Server 容器，请阅读我们的开始导览 [/docs/getting-started-guides/windows/](/docs/getting-started-guides/windows/) +- 我们每隔一个星期二在美国东部标准时间（EST）的12:30在 [https://zoom.us/my/sigwindows](https://zoom.us/my/sigwindows) 开会。所有会议内容都记录在 Youtube 并附上了参考材料 [https://www.youtube.com/playlist?list=PL69nYSiGNLP2OH9InCcNkWNu2bl-gmIU4](https://www.youtube.com/playlist?list=PL69nYSiGNLP2OH9InCcNkWNu2bl-gmIU4) +- 通过 Slack 联系我们 [https://kubernetes.slack.com/messages/sig-windows](https://kubernetes.slack.com/messages/sig-windows) +- 在 Github 上找到我们 [https://github.com/kubernetes/community/tree/master/sig-windows](https://github.com/kubernetes/community/tree/master/sig-windows) + + + +<!-- +Thank you, + +Michael Michael (@michmike77) +SIG-Windows Lead +Senior Director of Product Management, Apprenda +---> +谢谢大家， + +Michael Michael (@michmike77) +SIG-Windows 领导人 +Apprenda 产品管理高级总监 diff --git a/content/zh/blog/_posts/2018-10-01-health-checking-grpc.md b/content/zh/blog/_posts/2018-10-01-health-checking-grpc.md new file mode 100644 index 0000000000..f80633cf8a --- /dev/null +++ b/content/zh/blog/_posts/2018-10-01-health-checking-grpc.md @@ -0,0 +1,168 @@ +--- +layout: blog +title: '在 Kubernetes 上对 gRPC 服务器进行健康检查' +date: 2018-10-01 +--- +<!-- +--- +layout: blog +title: 'Health checking gRPC servers on Kubernetes' +date: 2018-10-01 +--- +---> + +<!-- +**Author**: [Ahmet Alp Balkan](https://twitter.com/ahmetb) (Google) +---> +**作者**： [Ahmet Alp Balkan](https://twitter.com/ahmetb) (Google) + +<!-- +[gRPC](https://grpc.io) is on its way to becoming the lingua franca for +communication between cloud-native microservices. If you are deploying gRPC +applications to Kubernetes today, you may be wondering about the best way to +configure health checks. In this article, we will talk about +[grpc-health-probe](https://github.com/grpc-ecosystem/grpc-health-probe/), a +Kubernetes-native way to health check gRPC apps. +---> +[gRPC](https://grpc.io) 将成为本地云微服务间进行通信的通用语言。如果您现在将 gRPC 应用程序部署到 Kubernetes，您可能会想要了解配置健康检查的最佳方法。在本文中，我们将介绍 [grpc-health-probe](https://github.com/grpc-ecosystem/grpc-health-probe/)，这是 Kubernetes 原生的健康检查 gRPC 应用程序的方法。 + +<!-- +If you're unfamiliar, Kubernetes [health +checks](/docs/tasks/configure-pod-container/configure-liveness-readiness-probes/) +(liveness and readiness probes) is what's keeping your applications available +while you're sleeping. They detect unresponsive pods, mark them unhealthy, and +cause these pods to be restarted or rescheduled. +---> +如果您不熟悉，Kubernetes的 [健康检查](/docs/tasks/configure-pod-container/configure-liveness-readiness-probes/)（存活探针和就绪探针）可以使您的应用程序在睡眠时保持可用状态。当检测到没有回应的 Pod 时，会将其标记为不健康，并使这些 Pod 重新启动或重新安排。 + +<!-- +Kubernetes [does not +support](https://github.com/kubernetes/kubernetes/issues/21493) gRPC health +checks natively. This leaves the gRPC developers with the following three +approaches when they deploy to Kubernetes: + +[![options for health checking grpc on kubernetes today](/images/blog/2019-09-30-health-checking-grpc/options.png)](/images/blog/2019-09-30-health-checking-grpc/options.png) +---> +Kubernetes 原本 [不支持](https://github.com/kubernetes/kubernetes/issues/21493) gRPC 健康检查。gRPC 的开发人员在 Kubernetes 中部署时可以采用以下三种方法： + +[![当前在 kubernetes 上进行 gRPC 健康检查的选项](/images/blog/2019-09-30-health-checking-grpc/options.png)](/images/blog/2019-09-30-health-checking-grpc/options.png) + + +<!-- +1. **httpGet probe:** Cannot be natively used with gRPC. You need to refactor + your app to serve both gRPC and HTTP/1.1 protocols (on different port + numbers). +2. **tcpSocket probe:** Opening a socket to gRPC server is not meaningful, + since it cannot read the response body. +3. **exec probe:** This invokes a program in a container's ecosystem + periodically. In the case of gRPC, this means you implement a health RPC + yourself, then write and ship a client tool with your container. + +Can we do better? Absolutely. +---> +1. **httpGet prob：** 不能与 gRPC 一起使用。您需要重构您的应用程序，必须同时支持 gRPC 和 HTTP/1.1 协议（在不同的端口号上）。 +2. **tcpSocket probe：** 打开 gRPC 服务器的 Socket 是没有意义的，因为它无法读取响应主体。 +3. **exec probe：** 将定期调用容器生态系统中的程序。对于 gRPC，这意味着您要自己实现健康 RPC，然后使用容器编写并交付客户端工具。 + +我们可以做得更好吗？这是肯定的。 + +<!-- +## Introducing “grpc-health-probe” + +To standardize the "exec probe" approach mentioned above, we need: + +- a **standard** health check "protocol" that can be implemented in any gRPC + server easily. +- a **standard** health check "tool" that can query the health protocol easily. +---> +## 介绍 “grpc-health-probe” + +为了使上述 "exec probe" 方法标准化，我们需要： + +- 可以在任何 gRPC 服务器中轻松实现的 **标准** 健康检查 "协议" 。 +- 一种 **标准** 健康检查 "工具" ，可以轻松查询健康协议。 + +<!-- +Thankfully, gRPC has a [standard health checking +protocol](https://github.com/grpc/grpc/blob/v1.15.0/doc/health-checking.md). It +can be used easily from any language. Generated code and the utilities for +setting the health status are shipped in nearly all language implementations of +gRPC. +---> +幸运的是，gRPC 具有 [标准的健康检查协议](https://github.com/grpc/grpc/blob/v1.15.0/doc/health-checking.md)。可以用任何语言轻松调用它。几乎所有实现 gRPC 的语言都附带了生成的代码和用于设置健康状态的实用程序。 + +<!-- +If you +[implement](https://github.com/grpc/grpc/blob/v1.15.0/src/proto/grpc/health/v1/health.proto) +this health check protocol in your gRPC apps, you can then use a standard/common +tool to invoke this `Check()` method to determine server status. +---> +如果您在 gRPC 应用程序中 [实现](https://github.com/grpc/grpc/blob/v1.15.0/src/proto/grpc/health/v1/health.proto) 此健康检查协议，那么可以使用标准或通用工具调用 `Check()` 方法来确定服务器状态。 + +<!-- +The next thing you need is the "standard tool", and it's the +[**grpc-health-probe**](https://github.com/grpc-ecosystem/grpc-health-probe/). +---> +接下来您需要的是 "标准工具" [**grpc-health-probe**](https://github.com/grpc-ecosystem/grpc-health-probe/)。 + +<a href='/images/blog/2019-09-30-health-checking-grpc/grpc_health_probe.png'> + <img width="768" title='grpc-health-probe on kubernetes' + src='/images/blog/2019-09-30-health-checking-grpc/grpc_health_probe.png'/> +</a> + +<!-- +With this tool, you can use the same health check configuration in all your gRPC +applications. This approach requires you to: +---> +使用此工具，您可以在所有 gRPC 应用程序中使用相同的健康检查配置。这种方法有以下要求： + +<!-- +1. Find the gRPC "health" module in your favorite language and start using it + (example [Go library](https://godoc.org/github.com/grpc/grpc-go/health)). +2. Ship the + [grpc_health_probe](https://github.com/grpc-ecosystem/grpc-health-probe/) + binary in your container. +3. [Configure](https://github.com/grpc-ecosystem/grpc-health-probe/tree/1329d682b4232c102600b5e7886df8ffdcaf9e26#example-grpc-health-checking-on-kubernetes) + Kubernetes "exec" probe to invoke the "grpc_health_probe" tool in the + container. +---> +1. 用您喜欢的语言找到 gRPC 的 "健康" 模块并开始使用它（例如 [Go 库](https://godoc.org/github.com/grpc/grpc-go/health)）。 +2. 将二进制文件 [grpc_health_probe](https://github.com/grpc-ecosystem/grpc-health-probe/) 送到容器中。 +3. [配置](https://github.com/grpc-ecosystem/grpc-health-probe/tree/1329d682b4232c102600b5e7886df8ffdcaf9e26#example-grpc-health-checking-on-kubernetes) Kubernetes 的 "exec" 检查模块来调用容器中的 "grpc_health_probe" 工具。 + +<!-- +In this case, executing "grpc_health_probe" will call your gRPC server over +`localhost`, since they are in the same pod. +---> +在这种情况下，执行 "grpc_health_probe" 将通过 `localhost` 调用您的 gRPC 服务器，因为它们位于同一个容器中。 + +<!-- +## What's next + +**grpc-health-probe** project is still in its early days and it needs your +feedback. It supports a variety of features like communicating with TLS servers +and configurable connection/RPC timeouts. +---> +## 下一步工作 + +**grpc-health-probe** 项目仍处于初期阶段，需要您的反馈。它支持多种功能，例如与 TLS 服务器通信和配置延时连接/RPC。 + +<!-- +If you are running a gRPC server on Kubernetes today, try using the gRPC Health +Protocol and try the grpc-health-probe in your deployments, and [give +feedback](https://github.com/grpc-ecosystem/grpc-health-probe/). +---> +如果您最近要在 Kubernetes 上运行 gRPC 服务器，请尝试使用 gRPC Health Protocol，并在您的 Deployment 中尝试 grpc-health-probe，然后 [进行反馈](https://github.com/grpc-ecosystem/grpc-health-probe/)。 + +<!-- +## Further reading + +- Protocol: [GRPC Health Checking Protocol](https://github.com/grpc/grpc/blob/v1.15.0/doc/health-checking.md) ([health.proto](https://github.com/grpc/grpc/blob/v1.15.0/src/proto/grpc/health/v1/health.proto)) +- Documentation: [Kubernetes liveness and readiness probes](/docs/tasks/configure-pod-container/configure-liveness-readiness-probes/) +- Article: [Advanced Kubernetes Health Check Patterns](https://ahmet.im/blog/advanced-kubernetes-health-checks/) +---> +## 更多内容 + +- 协议： [GRPC Health Checking Protocol](https://github.com/grpc/grpc/blob/v1.15.0/doc/health-checking.md) ([health.proto](https://github.com/grpc/grpc/blob/v1.15.0/src/proto/grpc/health/v1/health.proto)) +- 文档： [Kubernetes 存活和就绪探针](/docs/tasks/configure-pod-container/configure-liveness-readiness-probes/) +- 文章： [升级版 Kubernetes 健康检查模式](https://ahmet.im/blog/advanced-kubernetes-health-checks/) diff --git a/content/zh/blog/_posts/2019-08-06-OPA-Gatekeeper-Policy-and-Governance-for-Kubernetes.md b/content/zh/blog/_posts/2019-08-06-OPA-Gatekeeper-Policy-and-Governance-for-Kubernetes.md new file mode 100644 index 0000000000..58ee778b84 --- /dev/null +++ b/content/zh/blog/_posts/2019-08-06-OPA-Gatekeeper-Policy-and-Governance-for-Kubernetes.md @@ -0,0 +1,290 @@ +--- +layout: blog +title: "OPA Gatekeeper：Kubernetes 的策略和管理" +date: 2019-08-06 +slug: OPA-Gatekeeper-Policy-and-Governance-for-Kubernetes +--- +<!-- +--- +layout: blog +title: "OPA Gatekeeper: Policy and Governance for Kubernetes" +date: 2019-08-06 +slug: OPA-Gatekeeper-Policy-and-Governance-for-Kubernetes +--- +---> + +<!-- +**Authors:** Rita Zhang (Microsoft), Max Smythe (Google), Craig Hooper (Commonwealth Bank AU), Tim Hinrichs (Styra), Lachie Evenson (Microsoft), Torin Sandall (Styra) +---> +**作者：** Rita Zhang (Microsoft), Max Smythe (Google), Craig Hooper (Commonwealth Bank AU), Tim Hinrichs (Styra), Lachie Evenson (Microsoft), Torin Sandall (Styra) + +<!-- +The [Open Policy Agent Gatekeeper](https://github.com/open-policy-agent/gatekeeper) project can be leveraged to help enforce policies and strengthen governance in your Kubernetes environment. In this post, we will walk through the goals, history, and current state of the project. +---> +可以从项目 [Open Policy Agent Gatekeeper](https://github.com/open-policy-agent/gatekeeper) 中获得帮助，在 Kubernetes 环境下实施策略并加强治理。在本文中，我们将逐步介绍该项目的目标，历史和当前状态。 + +<!-- +The following recordings from the Kubecon EU 2019 sessions are a great starting place in working with Gatekeeper: + +* [Intro: Open Policy Agent Gatekeeper](https://youtu.be/Yup1FUc2Qn0) +* [Deep Dive: Open Policy Agent](https://youtu.be/n94_FNhuzy4) +---> +以下是 Kubecon EU 2019 会议的录音，帮助我们更好地开展与 Gatekeeper 合作： + +* [简介：开放策略代理 Gatekeeper](https://youtu.be/Yup1FUc2Qn0) +* [深入研究：开放策略代理](https://youtu.be/n94_FNhuzy4) + +<!-- +## Motivations + +If your organization has been operating Kubernetes, you probably have been looking for ways to control what end-users can do on the cluster and ways to ensure that clusters are in compliance with company policies. These policies may be there to meet governance and legal requirements or to enforce best practices and organizational conventions. With Kubernetes, how do you ensure compliance without sacrificing development agility and operational independence? +---> +## 出发点 + +如果您所在的组织一直在使用 Kubernetes，您可能一直在寻找如何控制终端用户在集群上的行为，以及如何确保集群符合公司政策。这些策略可能需要满足管理和法律要求，或者符合最佳执行方法和组织惯例。使用 Kubernetes，如何在不牺牲开发敏捷性和运营独立性的前提下确保合规性？ + +<!-- +For example, you can enforce policies like: + +* All images must be from approved repositories +* All ingress hostnames must be globally unique +* All pods must have resource limits +* All namespaces must have a label that lists a point-of-contact +---> +例如，您可以执行以下策略： + +* 所有镜像必须来自获得批准的存储库 +* 所有入口主机名必须是全局唯一的 +* 所有 Pod 必须有资源限制 +* 所有命名空间都必须具有列出联系的标签 + +<!-- +Kubernetes allows decoupling policy decisions from the API server by means of [admission controller webhooks](https://kubernetes.io/docs/reference/access-authn-authz/extensible-admission-controllers/) to intercept admission requests before they are persisted as objects in Kubernetes. [Gatekeeper](https://github.com/open-policy-agent/gatekeeper) was created to enable users to customize admission control via configuration, not code and to bring awareness of the cluster’s state, not just the single object under evaluation at admission time. Gatekeeper is a customizable admission webhook for Kubernetes that enforces policies executed by the [Open Policy Agent (OPA)](https://www.openpolicyagent.org), a policy engine for Cloud Native environments hosted by CNCF. +---> +在接收请求被持久化为 Kubernetes 中的对象之前，Kubernetes 允许通过 [admission controller webhooks](https://kubernetes.io/docs/reference/access-authn-authz/extensible-admission-controllers/) 将策略决策与 API 服务器分离，从而拦截这些请求。[Gatekeeper](https://github.com/open-policy-agent/gatekeeper) 创建的目的是使用户能够通过配置（而不是代码）自定义控制许可，并使用户了解群集的状态，而不仅仅是针对评估状态的单个对象，在这些对象准许加入的时候。Gatekeeper 是 Kubernetes 的一个可定制的许可 webhook ，它由 [Open Policy Agent (OPA)](https://www.openpolicyagent.org) 强制执行， OPA 是 Cloud Native 环境下的策略引擎，由 CNCF 主办。 + +<!-- +## Evolution + +Before we dive into the current state of Gatekeeper, let’s take a look at how the Gatekeeper project has evolved. +---> +## 发展 + +在深入了解 Gatekeeper 的当前情况之前，让我们看一下 Gatekeeper 项目是如何发展的。 + +<!-- +* Gatekeeper v1.0 - Uses OPA as the admission controller with the kube-mgmt sidecar enforcing configmap-based policies. It provides validating and mutating admission control. Donated by Styra. +* Gatekeeper v2.0 - Uses Kubernetes policy controller as the admission controller with OPA and kube-mgmt sidecars enforcing configmap-based policies. It provides validating and mutating admission control and audit functionality. Donated by Microsoft. + * Gatekeeper v3.0 - The admission controller is integrated with the [OPA Constraint Framework](https://github.com/open-policy-agent/frameworks/tree/master/constraint) to enforce CRD-based policies and allow declaratively configured policies to be reliably shareable. Built with kubebuilder, it provides validating and, eventually, mutating (to be implemented) admission control and audit functionality. This enables the creation of policy templates for [Rego](https://www.openpolicyagent.org/docs/latest/how-do-i-write-policies/) policies, creation of policies as CRDs, and storage of audit results on policy CRDs. This project is a collaboration between Google, Microsoft, Red Hat, and Styra. +---> +* Gatekeeper v1.0 - 使用 OPA 作为带有 kube-mgmt sidecar 的许可控制器，用来强制执行基于 configmap 的策略。这种方法实现了验证和转换许可控制。贡献方：Styra +* Gatekeeper v2.0 - 使用 Kubernetes 策略控制器作为许可控制器，OPA 和 kube-mgmt sidecar 实施基于 configmap 的策略。这种方法实现了验证和转换准入控制和审核功能。贡献方：Microsoft + * Gatekeeper v3.0 - 准入控制器与 [OPA Constraint Framework](https://github.com/open-policy-agent/frameworks/tree/master/constraint) 集成在一起，用来实施基于 CRD 的策略，并可以可靠地共享已完成声明配置的策略。使用 kubebuilder 进行构建，实现了验证以及最终转换（待完成）为许可控制和审核功能。这样就可以为 [Rego](https://www.openpolicyagent.org/docs/latest/how-do-i-write-policies/) 策略创建策略模板，将策略创建为 CRD 并存储审核结果到策略 CRD 上。该项目是 Google，Microsoft，Red Hat 和 Styra 合作完成的。 + +![](/images/blog/2019-08-06-opa-gatekeeper/v3.png) + +<!-- +## Gatekeeper v3.0 Features + +Now let’s take a closer look at the current state of Gatekeeper and how you can leverage all the latest features. Consider an organization that wants to ensure all objects in a cluster have departmental information provided as part of the object’s labels. How can you do this with Gatekeeper? +---> +## Gatekeeper v3.0 的功能 + +现在我们详细看一下 Gatekeeper 当前的状态，以及如何利用所有最新的功能。假设一个组织希望确保集群中的所有对象都有 department 信息，这些信息是对象标签的一部分。如何利用 Gatekeeper 完成这项需求？ + +<!-- +### Validating Admission Control + +Once all the Gatekeeper components have been [installed](https://github.com/open-policy-agent/gatekeeper) in your cluster, the API server will trigger the Gatekeeper admission webhook to process the admission request whenever a resource in the cluster is created, updated, or deleted. + +During the validation process, Gatekeeper acts as a bridge between the API server and OPA. The API server will enforce all policies executed by OPA. +---> +### 验证许可控制 + +在集群中所有 Gatekeeper 组件都 [安装](https://github.com/open-policy-agent/gatekeeper) 完成之后，只要集群中的资源进行创建、更新或删除，API 服务器将触发 Gatekeeper 准入 webhook 来处理准入请求。 + +在验证过程中，Gatekeeper 充当 API 服务器和 OPA 之间的桥梁。API 服务器将强制实施 OPA 执行的所有策略。 + +<!-- +### Policies and Constraints + +With the integration of the OPA Constraint Framework, a Constraint is a declaration that its author wants a system to meet a given set of requirements. Each Constraint is written with Rego, a declarative query language used by OPA to enumerate instances of data that violate the expected state of the system. All Constraints are evaluated as a logical AND. If one Constraint is not satisfied, then the whole request is rejected. +---> +### 策略与 Constraint + +结合 OPA Constraint Framework，Constraint 是一个声明，表示作者希望系统满足给定的一系列要求。Constraint 都使用 Rego 编写，Rego 是声明性查询语言，OPA 用 Rego 来枚举违背系统预期状态的数据实例。所有 Constraint 都遵循逻辑 AND。假使有一个 Constraint 不满足，那么整个请求都将被拒绝。 + +<!-- +Before defining a Constraint, you need to create a Constraint Template that allows people to declare new Constraints. Each template describes both the Rego logic that enforces the Constraint and the schema for the Constraint, which includes the schema of the CRD and the parameters that can be passed into a Constraint, much like arguments to a function. + +For example, here is a Constraint template CRD that requires certain labels to be present on an arbitrary object. +---> +在定义 Constraint 之前，您需要创建一个 Constraint Template，允许大家声明新的 Constraint。每个模板都描述了强制执行 Constraint 的 Rego 逻辑和 Constraint 的模式，其中包括 CRD 的模式和传递到 enforces 中的参数，就像函数的参数一样。 + +例如，以下是一个 Constraint 模板 CRD，它的请求是在任意对象上显示某些标签。 + +```yaml +apiVersion: templates.gatekeeper.sh/v1beta1 +kind: ConstraintTemplate +metadata: + name: k8srequiredlabels +spec: + crd: + spec: + names: + kind: K8sRequiredLabels + listKind: K8sRequiredLabelsList + plural: k8srequiredlabels + singular: k8srequiredlabels + validation: + # Schema for the `parameters` field + openAPIV3Schema: + properties: + labels: + type: array + items: string + targets: + - target: admission.k8s.gatekeeper.sh + rego: | + package k8srequiredlabels + + deny[{"msg": msg, "details": {"missing_labels": missing}}] { + provided := {label | input.review.object.metadata.labels[label]} + required := {label | label := input.parameters.labels[_]} + missing := required - provided + count(missing) > 0 + msg := sprintf("you must provide labels: %v", [missing]) + } +``` + +<!-- +Once a Constraint template has been deployed in the cluster, an admin can now create individual Constraint CRDs as defined by the Constraint template. For example, here is a Constraint CRD that requires the label `hr` to be present on all namespaces. +---> +在集群中部署了 Constraint 模板后，管理员现在可以创建由 Constraint 模板定义的单个 Constraint CRD。例如，这里以下是一个 Constraint CRD，要求标签 `hr` 出现在所有命名空间上。 + +```yaml +apiVersion: constraints.gatekeeper.sh/v1beta1 +kind: K8sRequiredLabels +metadata: + name: ns-must-have-hr +spec: + match: + kinds: + - apiGroups: [""] + kinds: ["Namespace"] + parameters: + labels: ["hr"] +``` + +<!-- +Similarly, another Constraint CRD that requires the label `finance` to be present on all namespaces can easily be created from the same Constraint template. +---> +类似地，可以从同一个 Constraint 模板轻松地创建另一个 Constraint CRD，该 Constraint CRD 要求所有命名空间上都有 `finance` 标签。 + +```yaml +apiVersion: constraints.gatekeeper.sh/v1beta1 +kind: K8sRequiredLabels +metadata: + name: ns-must-have-finance +spec: + match: + kinds: + - apiGroups: [""] + kinds: ["Namespace"] + parameters: + labels: ["finance"] +``` + +<!-- +As you can see, with the Constraint framework, we can reliably share Regos via the Constraint templates, define the scope of enforcement with the match field, and provide user-defined parameters to the Constraints to create customized behavior for each Constraint. +---> +如您所见，使用 Constraint framework，我们可以通过 Constraint 模板可靠地共享 rego，使用匹配字段定义执行范围，并为 Constraint 提供用户定义的参数，从而为每个 Constraint 创建自定义行为。 + +<!-- +### Audit + +The audit functionality enables periodic evaluations of replicated resources against the Constraints enforced in the cluster to detect pre-existing misconfigurations. Gatekeeper stores audit results as `violations` listed in the `status` field of the relevant Constraint. ---> +### 审核 + +根据群集中强制执行的 Constraint，审核功能可定期评估复制的资源，并检测先前存在的错误配置。Gatekeeper 将审核结果存储为 `violations`，在相关 Constraint 的 `status` 字段中列出。 + +```yaml +apiVersion: constraints.gatekeeper.sh/v1beta1 +kind: K8sRequiredLabels +metadata: + name: ns-must-have-hr +spec: + match: + kinds: + - apiGroups: [""] + kinds: ["Namespace"] + parameters: + labels: ["hr"] +status: + auditTimestamp: "2019-08-06T01:46:13Z" + byPod: + - enforced: true + id: gatekeeper-controller-manager-0 + violations: + - enforcementAction: deny + kind: Namespace + message: 'you must provide labels: {"hr"}' + name: default + - enforcementAction: deny + kind: Namespace + message: 'you must provide labels: {"hr"}' + name: gatekeeper-system + - enforcementAction: deny + kind: Namespace + message: 'you must provide labels: {"hr"}' + name: kube-public + - enforcementAction: deny + kind: Namespace + message: 'you must provide labels: {"hr"}' + name: kube-system +``` + +<!-- +### Data Replication + +Audit requires replication of Kubernetes resources into OPA before they can be evaluated against the enforced Constraints. Data replication is also required by Constraints that need access to objects in the cluster other than the object under evaluation. For example, a Constraint that enforces uniqueness of ingress hostname must have access to all other ingresses in the cluster. +---> +### 数据复制 + +审核要求将 Kubernetes 复制到 OPA 中，然后才能根据强制的 Constraint 对其进行评估。数据复制同样也需要 Constraint，这些 Constraint 需要访问集群中除评估对象之外的对象。例如，一个 Constraint 要强制确定入口主机名的唯一性，就必须有权访问集群中的所有其他入口。 + +<!-- +To configure Kubernetes data to be replicated, create a sync config resource with the resources to be replicated into OPA. For example, the below configuration replicates all namespace and pod resources to OPA. +---> +对 Kubernetes 数据进行复制，请使用复制到 OPA 中的资源创建 sync config 资源。例如，下面的配置将所有命名空间和 Pod 资源复制到 OPA。 + +```yaml +apiVersion: config.gatekeeper.sh/v1alpha1 +kind: Config +metadata: + name: config + namespace: "gatekeeper-system" +spec: + sync: + syncOnly: + - group: "" + version: "v1" + kind: "Namespace" + - group: "" + version: "v1" + kind: "Pod" +``` + +<!-- +## Planned for Future + +The community behind the Gatekeeper project will be focusing on providing mutating admission control to support mutation scenarios (for example: annotate objects automatically with departmental information when creating a new resource), support external data to inject context external to the cluster into the admission decisions, support dry run to see impact of a policy on existing resources in the cluster before enforcing it, and more audit functionalities. +---> +## 未来计划 + +Gatekeeper 项目背后的社区将专注于提供转换许可控制，可以用来支持转换方案（例如：在创建新资源时使用 department 信息自动注释对象），支持外部数据以将集群外部环境加入到许可决策中，支持试运行以便在执行策略之前了解策略对集群中现有资源的影响，还有更多的审核功能。 + +<!-- +If you are interested in learning more about the project, check out the [Gatekeeper](https://github.com/open-policy-agent/gatekeeper) repo. If you are interested in helping define the direction of Gatekeeper, join the [#kubernetes-policy](https://openpolicyagent.slack.com/messages/CDTN970AX) channel on OPA Slack, and join our [weekly meetings](https://docs.google.com/document/d/1A1-Q-1OMw3QODs1wT6eqfLTagcGmgzAJAjJihiO3T48/edit) to discuss development, issues, use cases, etc. +---> +如果您有兴趣了解更多有关该项目的信息，请查看 [Gatekeeper](https://github.com/open-policy-agent/gatekeeper) 存储库。如果您有兴趣帮助确定 Gatekeeper 的方向，请加入 [#kubernetes-policy](https://openpolicyagent.slack.com/messages/CDTN970AX) OPA Slack 频道，并加入我们的 [周会](https://docs.google.com/document/d/1A1-Q-1OMw3QODs1wT6eqfLTagcGmgzAJAjJihiO3T48/edit) 一同讨论开发、任务、用例等。 diff --git a/content/zh/blog/_posts/2020-03-25-kubernetes-1.18-release-announcement.md b/content/zh/blog/_posts/2020-03-25-kubernetes-1.18-release-announcement.md new file mode 100644 index 0000000000..5c0eb0bfbe --- /dev/null +++ b/content/zh/blog/_posts/2020-03-25-kubernetes-1.18-release-announcement.md @@ -0,0 +1,305 @@ +--- +layout: blog +title: 'Kubernetes 1.18: Fit & Finish' +date: 2020-03-25 +slug: kubernetes-1-18-release-announcement +--- + +<!-- +**Authors:** [Kubernetes 1.18 Release Team](https://github.com/kubernetes/sig-release/blob/master/releases/release-1.18/release_team.md) +--> +**作者:** [Kubernetes 1.18 发布团队](https://github.com/kubernetes/sig-release/blob/master/releases/release-1.18/release_team.md) + +<!-- +We're pleased to announce the delivery of Kubernetes 1.18, our first release of 2020! Kubernetes 1.18 consists of 38 enhancements: 15 enhancements are moving to stable, 11 enhancements in beta, and 12 enhancements in alpha. +--> +我们很高兴宣布 Kubernetes 1.18 版本的交付，这是我们 2020 年的第一版！ Kubernetes 1.18 包含 38 个增强功能：15 项增强功能已转为稳定版，11 项增强功能处于 beta 阶段，12 项增强功能处于 alpha 阶段。 + +<!-- +Kubernetes 1.18 is a "fit and finish" release. Significant work has gone into improving beta and stable features to ensure users have a better experience. An equal effort has gone into adding new developments and exciting new features that promise to enhance the user experience even more. +--> +Kubernetes 1.18 是一个近乎 “完美” 的版本。 为了改善 beta 和稳定的特性，已进行了大量工作，以确保用户获得更好的体验。 我们在增强现有功能的同时也增加了令人兴奋的新特性，这些有望进一步增强用户体验。 +<!-- +Having almost as many enhancements in alpha, beta, and stable is a great achievement. It shows the tremendous effort made by the community on improving the reliability of Kubernetes as well as continuing to expand its existing functionality. +--> +对 alpha，beta 和稳定版进行几乎同等程度的增强是一项伟大的成就。 它展现了社区在提高 Kubernetes 的可靠性以及继续扩展其现有功能方面所做的巨大努力。 + + +<!-- +## Major Themes +--> +## 主要内容 + +<!-- +### Kubernetes Topology Manager Moves to Beta - Align Up! +--> +### Kubernetes 拓扑管理器（Topology Manager）进入 Beta 阶段 - 对齐！ + +<!-- +A beta feature of Kubernetes in release 1.18, the [Topology Manager feature](https://github.com/nolancon/website/blob/f4200307260ea3234540ef13ed80de325e1a7267/content/en/docs/tasks/administer-cluster/topology-manager.md) enables NUMA alignment of CPU and devices (such as SR-IOV VFs) that will allow your workload to run in an environment optimized for low-latency. Prior to the introduction of the Topology Manager, the CPU and Device Manager would make resource allocation decisions independent of each other. This could result in undesirable allocations on multi-socket systems, causing degraded performance on latency critical applications. +--> +Kubernetes 在 1.18 版中的 Beta 阶段功能 [拓扑管理器特性](https://github.com/nolancon/website/blob/f4200307260ea3234540ef13ed80de325e1a7267/content/en/docs/tasks/administer-cluster/topology-manager.md) 启用 CPU 和设备（例如 SR-IOV VF）的 NUMA 对齐，这将使您的工作负载在针对低延迟而优化的环境中运行。在引入拓扑管理器之前，CPU 和设备管理器将做出彼此独立的资源分配决策。 这可能会导致在多处理器系统上非预期的资源分配结果，从而导致对延迟敏感的应用程序的性能下降。 + +<!-- +### Serverside Apply Introduces Beta 2 +--> +### Serverside Apply 推出Beta 2 + +<!-- +Server-side Apply was promoted to Beta in 1.16, but is now introducing a second Beta in 1.18. This new version will track and manage changes to fields of all new Kubernetes objects, allowing you to know what changed your resources and when. +--> +Serverside Apply 在1.16 中进入 Beta 阶段，但现在在 1.18 中进入了第二个 Beta 阶段。 这个新版本将跟踪和管理所有新 Kubernetes 对象的字段更改，从而使您知道什么更改了资源以及何时发生了更改。 + + +<!-- +### Extending Ingress with and replacing a deprecated annotation with IngressClass +--> +### 使用 IngressClass 扩展 Ingress 并用 IngressClass 替换已弃用的注释 + +<!-- +In Kubernetes 1.18, there are two significant additions to Ingress: A new `pathType` field and a new `IngressClass` resource. The `pathType` field allows specifying how paths should be matched. In addition to the default `ImplementationSpecific` type, there are new `Exact` and `Prefix` path types. +--> +在 Kubernetes 1.18 中，Ingress 有两个重要的补充：一个新的 `pathType` 字段和一个新的 `IngressClass` 资源。`pathType` 字段允许指定路径的匹配方式。 除了默认的`ImplementationSpecific`类型外，还有新的 `Exact`和`Prefix` 路径类型。 + +<!-- +The `IngressClass` resource is used to describe a type of Ingress within a Kubernetes cluster. Ingresses can specify the class they are associated with by using a new `ingressClassName` field on Ingresses. This new resource and field replace the deprecated `kubernetes.io/ingress.class` annotation. +--> +`IngressClass` 资源用于描述 Kubernetes 集群中 Ingress 的类型。 Ingress 对象可以通过在Ingress 资源类型上使用新的`ingressClassName` 字段来指定与它们关联的类。 这个新的资源和字段替换了不再建议使用的 `kubernetes.io/ingress.class` 注解。 + +<!-- +### SIG-CLI introduces kubectl alpha debug +--> +### SIG-CLI 引入了 kubectl alpha debug + +<!-- +SIG-CLI was debating the need for a debug utility for quite some time already. With the development of [ephemeral containers](https://kubernetes.io/docs/concepts/workloads/pods/ephemeral-containers/), it became more obvious how we can support developers with tooling built on top of `kubectl exec`. The addition of the [`kubectl alpha debug` command](https://github.com/kubernetes/enhancements/blob/master/keps/sig-cli/20190805-kubectl-debug.md) (it is alpha but your feedback is more than welcome), allows developers to easily debug their Pods inside the cluster. We think this addition is invaluable. This command allows one to create a temporary container which runs next to the Pod one is trying to examine, but also attaches to the console for interactive troubleshooting. +--> +SIG-CLI 一直在争论着调试工具的必要性。随着 [临时容器](https://kubernetes.io/docs/concepts/workloads/pods/ephemeral-containers/) 的发展，我们如何使用基于 `kubectl exec` 的工具来支持开发人员的必要性变得越来越明显。 [`kubectl alpha debug` 命令](https://github.com/kubernetes/enhancements/blob/master/keps/sig-cli/20190805-kubectl-debug.md) 的增加，（由于是 alpha 阶段，非常欢迎您反馈意见），使开发人员可以轻松地在集群中调试 Pod。我们认为这个功能的价值非常高。 此命令允许创建一个临时容器，该容器在要尝试检查的 Pod 旁边运行，并且还附加到控制台以进行交互式故障排除。 + +<!-- +### Introducing Windows CSI support alpha for Kubernetes +--> +### 为 Kubernetes 引入 Windows CSI 支持（Alpha） + +<!-- +The alpha version of CSI Proxy for Windows is being released with Kubernetes 1.18. CSI proxy enables CSI Drivers on Windows by allowing containers in Windows to perform privileged storage operations. +--> +用于 Windows 的 CSI 代理的 Alpha 版本随 Kubernetes 1.18 一起发布。 CSI 代理通过允许Windows 中的容器执行特权存储操作来启用 Windows 上的 CSI 驱动程序。 + +<!-- +## Other Updates +--> +## 其它更新 + +<!-- +### Graduated to Stable 💯 +--> +### 毕业转为稳定版 + +<!-- +- [Taint Based Eviction](https://github.com/kubernetes/enhancements/issues/166) +- [`kubectl diff`](https://github.com/kubernetes/enhancements/issues/491) +- [CSI Block storage support](https://github.com/kubernetes/enhancements/issues/565) +- [API Server dry run](https://github.com/kubernetes/enhancements/issues/576) +- [Pass Pod information in CSI calls](https://github.com/kubernetes/enhancements/issues/603) +- [Support Out-of-Tree vSphere Cloud Provider](https://github.com/kubernetes/enhancements/issues/670) +- [Support GMSA for Windows workloads](https://github.com/kubernetes/enhancements/issues/689) +- [Skip attach for non-attachable CSI volumes](https://github.com/kubernetes/enhancements/issues/770) +- [PVC cloning](https://github.com/kubernetes/enhancements/issues/989) +- [Moving kubectl package code to staging](https://github.com/kubernetes/enhancements/issues/1020) +- [RunAsUserName for Windows](https://github.com/kubernetes/enhancements/issues/1043) +- [AppProtocol for Services and Endpoints](https://github.com/kubernetes/enhancements/issues/1507) +- [Extending Hugepage Feature](https://github.com/kubernetes/enhancements/issues/1539) +- [client-go signature refactor to standardize options and context handling](https://github.com/kubernetes/enhancements/issues/1601) +- [Node-local DNS cache](https://github.com/kubernetes/enhancements/issues/1024) +--> +- [基于污点的逐出操作](https://github.com/kubernetes/enhancements/issues/166) +- [`kubectl diff`](https://github.com/kubernetes/enhancements/issues/491) +- [CSI 块存储支持](https://github.com/kubernetes/enhancements/issues/565) +- [API 服务器 dry run](https://github.com/kubernetes/enhancements/issues/576) +- [在 CSI 调用中传递 Pod 信息](https://github.com/kubernetes/enhancements/issues/603) +- [支持树外 vSphere 云驱动](https://github.com/kubernetes/enhancements/issues/670) +- [对 Windows 负载支持 GMSA](https://github.com/kubernetes/enhancements/issues/689) +- [对不可挂载的CSI卷跳过挂载](https://github.com/kubernetes/enhancements/issues/770) +- [PVC 克隆](https://github.com/kubernetes/enhancements/issues/989) +- [移动 kubectl 包代码到 staging](https://github.com/kubernetes/enhancements/issues/1020) +- [Windows 的 RunAsUserName](https://github.com/kubernetes/enhancements/issues/1043) +- [服务和端点的 AppProtocol](https://github.com/kubernetes/enhancements/issues/1507) +- [扩展 Hugepage 特性](https://github.com/kubernetes/enhancements/issues/1539) +- [client-go signature refactor to standardize options and context handling](https://github.com/kubernetes/enhancements/issues/1601) +- [Node-local DNS cache](https://github.com/kubernetes/enhancements/issues/1024) + + +<!-- +### Major Changes +--> +### 主要变化 + +<!-- +- [EndpointSlice API](https://github.com/kubernetes/enhancements/issues/752) +- [Moving kubectl package code to staging](https://github.com/kubernetes/enhancements/issues/1020) +- [CertificateSigningRequest API](https://github.com/kubernetes/enhancements/issues/1513) +- [Extending Hugepage Feature](https://github.com/kubernetes/enhancements/issues/1539) +- [client-go signature refactor to standardize options and context handling](https://github.com/kubernetes/enhancements/issues/1601) +--> +- [EndpointSlice API](https://github.com/kubernetes/enhancements/issues/752) +- [Moving kubectl package code to staging](https://github.com/kubernetes/enhancements/issues/1020) +- [CertificateSigningRequest API](https://github.com/kubernetes/enhancements/issues/1513) +- [Extending Hugepage Feature](https://github.com/kubernetes/enhancements/issues/1539) +- [client-go 的调用规范重构来标准化选项和管理上下文](https://github.com/kubernetes/enhancements/issues/1601) + + +<!-- +### Release Notes +--> +### 发布说明 + +<!-- +Check out the full details of the Kubernetes 1.18 release in our [release notes](https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG/CHANGELOG-1.18.md). +--> +在我们的 [发布文档](https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG/CHANGELOG-1.18.md)中查看 Kubernetes 1.18 发行版的完整详细信息。 + + +<!-- +### Availability +--> +### 下载安装 + +<!-- +Kubernetes 1.18 is available for download on [GitHub](https://github.com/kubernetes/kubernetes/releases/tag/v1.18.0). To get started with Kubernetes, check out these [interactive tutorials](https://kubernetes.io/docs/tutorials/) or run local Kubernetes clusters using Docker container “nodes” with [kind](https://kind.sigs.k8s.io/). You can also easily install 1.18 using [kubeadm](https://kubernetes.io/docs/setup/independent/create-cluster-kubeadm/). +--> +Kubernetes 1.18 可以在 [GitHub](https://github.com/kubernetes/kubernetes/releases/tag/v1.18.0) 上下载。 要开始使用Kubernetes，请查看这些 [交互教程](https://kubernetes.io/docs/tutorials/) 或通过[kind](https://kind.sigs.k8s.io/) 使用 Docker 容器运行本地 kubernetes 集群。您还可以使用[kubeadm](https://kubernetes.io/docs/setup/independent/create-cluster-kubeadm/)轻松安装 1.18。 + +<!-- +### Release Team +--> +### 发布团队 + +<!-- +This release is made possible through the efforts of hundreds of individuals who contributed both technical and non-technical content. Special thanks to the [release team](https://github.com/kubernetes/sig-release/blob/master/releases/release-1.18/release_team.md) led by Jorge Alarcon Ochoa, Site Reliability Engineer at Searchable AI. The 34 release team members coordinated many aspects of the release, from documentation to testing, validation, and feature completeness. +--> +通过数百位贡献了技术和非技术内容的个人的努力，使本次发行成为可能。 特别感谢由 Searchable AI 的网站可靠性工程师 Jorge Alarcon Ochoa 领导的[发布团队](https://github.com/kubernetes/sig-release/blob/master/releases/release-1.18/release_team.md)。 34 位发布团队成员协调了发布的各个方面，从文档到测试、验证和功能完整性。 + +<!-- +As the Kubernetes community has grown, our release process represents an amazing demonstration of collaboration in open source software development. Kubernetes continues to gain new users at a rapid pace. This growth creates a positive feedback cycle where more contributors commit code creating a more vibrant ecosystem. Kubernetes has had over [40,000 individual contributors](https://k8s.devstats.cncf.io/d/24/overall-project-statistics?orgId=1) to date and an active community of more than 3,000 people. +--> +随着 Kubernetes 社区的发展壮大，我们的发布过程很好地展示了开源软件开发中的协作。 Kubernetes 继续快速获取新用户。 这种增长创造了一个积极的反馈回路，其中有更多的贡献者提交了代码，从而创建了更加活跃的生态系统。 迄今为止，Kubernetes 已有 [40,000 独立贡献者](https://k8s.devstats.cncf.io/d/24/overall-project-statistics?orgId=1) 和一个超过3000人的活跃社区。 + +<!-- +### Release Logo +--> +### 发布 logo + +<!-- +![Kubernetes 1.18 Release Logo](/images/blog/2020-03-25-kubernetes-1.18-release-announcement/release-logo.png) +--> +![Kubernetes 1.18 发布图标](/images/blog/2020-03-25-kubernetes-1.18-release-announcement/release-logo.png) + +<!-- +#### Why the LHC? +--> +#### 为什么是 LHC + +<!-- +The LHC is the world’s largest and most powerful particle accelerator. It is the result of the collaboration of thousands of scientists from around the world, all for the advancement of science. In a similar manner, Kubernetes has been a project that has united thousands of contributors from hundreds of organizations – all to work towards the same goal of improving cloud computing in all aspects! "A Bit Quarky" as the release name is meant to remind us that unconventional ideas can bring about great change and keeping an open mind to diversity will lead help us innovate. +--> +LHC 是世界上最大，功能最强大的粒子加速器。，是来自世界各地成千上万科学家合作的结果。所有这些合作都是为了促进科学的发展。以类似的方式，Kubernetes 已经成为一个聚集了来自数百个组织的数千名贡献者–所有人都朝着在各个方面改善云计算的相同目标努力的项目！ 发布名称“ A Bit Quarky” 的意思是提醒我们，非常规的想法可以带来巨大的变化，对开放性保持开放态度将有助于我们进行创新。 + + +<!-- +#### About the designer +--> +#### 关于设计者 + +<!-- +Maru Lango is a designer currently based in Mexico City. While her area of expertise is Product Design, she also enjoys branding, illustration and visual experiments using CSS + JS and contributing to diversity efforts within the tech and design communities. You may find her in most social media as @marulango or check her website: https://marulango.com +--> +Maru Lango 是目前居住在墨西哥城的设计师。她的专长是产品设计，她还喜欢使用 CSS + JS 进行品牌、插图和视觉实验，为技术和设计社区的多样性做贡献。您可能会在大多数社交媒体上以 @marulango 的身份找到她，或查看她的网站： https://marulango.com + +<!-- +### User Highlights +--> +### 高光用户 + +<!-- +- Ericsson is using Kubernetes and other cloud native technology to deliver a [highly demanding 5G network](https://www.cncf.io/case-study/ericsson/) that resulted in up to 90 percent CI/CD savings. +- Zendesk is using Kubernetes to [run around 70% of its existing applications](https://www.cncf.io/case-study/zendesk/). It’s also building all new applications to also run on Kubernetes, which has brought time savings, greater flexibility, and increased velocity to its application development. +- LifeMiles has [reduced infrastructure spending by 50%](https://www.cncf.io/case-study/lifemiles/) because of its move to Kubernetes. It has also allowed them to double its available resource capacity. +--> +- 爱立信正在使用 Kubernetes 和其他云原生技术来交付[高标准的 5G 网络](https://www.cncf.io/case-study/ericsson/)，这可以在 CI/CD 上节省多达 90％ 的支出。 +- Zendesk 正在使用 Kubernetes [运行其现有应用程序的约 70％](https://www.cncf.io/case-study/zendesk/)。它还正在使所构建的所有新应用都可以在 Kubernetes 上运行，从而节省时间、提高灵活性并加快其应用程序开发的速度。 +- LifeMiles 因迁移到 Kubernetes 而[降低了 50% 的基础设施开支](https://www.cncf.io/case-study/lifemiles/)。Kubernetes 还使他们可以将其可用资源容量增加一倍。 + +<!-- +### Ecosystem Updates +--> +### 生态系统更新 + +<!-- +- The CNCF published the results of its [annual survey](https://www.cncf.io/blog/2020/03/04/2019-cncf-survey-results-are-here-deployments-are-growing-in-size-and-speed-as-cloud-native-adoption-becomes-mainstream/) showing that Kubernetes usage in production is skyrocketing. The survey found that 78% of respondents are using Kubernetes in production compared to 58% last year. +- The “Introduction to Kubernetes” course hosted by the CNCF [surpassed 100,000 registrations](https://www.cncf.io/announcement/2020/01/28/cloud-native-computing-foundation-announces-introduction-to-kubernetes-course-surpasses-100000-registrations/). +--> +- CNCF发布了[年度调查](https://www.cncf.io/blog/2020/03/04/2019-cncf-survey-results-are-here-deployments-are-growing-in-size-and-speed-as-cloud-native-adoption-becomes-mainstream/) 的结果，表明 Kubernetes 在生产中的使用正在飞速增长。调查发现，有78％的受访者在生产中使用Kubernetes，而去年这一比例为 58％。 +- CNCF 举办的 “Kubernetes入门” 课程有[超过 100,000 人注册](https://www.cncf.io/announcement/2020/01/28/cloud-native-computing-foundation-announces-introduction-to-kubernetes-course-surpasses-100000-registrations/)。 + +<!-- +### Project Velocity +--> +### 项目速度 + +<!-- +The CNCF has continued refining DevStats, an ambitious project to visualize the myriad contributions that go into the project. [K8s DevStats](https://k8s.devstats.cncf.io/d/12/dashboards?orgId=1) illustrates the breakdown of contributions from major company contributors, as well as an impressive set of preconfigured reports on everything from individual contributors to pull request lifecycle times. +--> +CNCF 继续完善 DevStats。这是一个雄心勃勃的项目，旨在对项目中的无数贡献数据进行可视化展示。[K8s DevStats](https://k8s.devstats.cncf.io/d/12/dashboards?orgId=1) 展示了主要公司贡献者的贡献细目，以及一系列令人印象深刻的预定义的报告，涉及从贡献者个人的各方面到 PR 生命周期的各个方面。 + +<!-- +This past quarter, 641 different companies and over 6,409 individuals contributed to Kubernetes. [Check out DevStats](https://k8s.devstats.cncf.io/d/11/companies-contributing-in-repository-groups?orgId=1&var-period=m&var-repogroup_name=All) to learn more about the overall velocity of the Kubernetes project and community. +--> +在过去的一个季度中，641 家不同的公司和超过 6,409 个个人为 Kubernetes 作出贡献。 [查看 DevStats](https://k8s.devstats.cncf.io/d/11/companies-contributing-in-repository-groups?orgId=1&var-period=m&var-repogroup_name=All) 以了解有关 Kubernetes 项目和社区发展速度的信息。 + +<!-- +### Event Update +--> +### 活动信息 + +<!-- +Kubecon + CloudNativeCon EU 2020 is being pushed back – for the more most up-to-date information, please check the [Novel Coronavirus Update page](https://events.linuxfoundation.org/kubecon-cloudnativecon-europe/attend/novel-coronavirus-update/). +--> +Kubecon + CloudNativeCon EU 2020 已经推迟 - 有关最新信息，请查看[新型肺炎发布页面](https://events.linuxfoundation.org/kubecon-cloudnativecon-europe/attend/novel-coronavirus-update/)。 + +<!-- +### Upcoming Release Webinar +--> +### 即将到来的发布的线上会议 + +<!-- +Join members of the Kubernetes 1.18 release team on April 23rd, 2020 to learn about the major features in this release including kubectl debug, Topography Manager, Ingress to V1 graduation, and client-go. Register here: https://www.cncf.io/webinars/kubernetes-1-18/. +--> +在 2020 年 4 月 23 日，和 Kubernetes 1.18 版本团队一起了解此版本的主要功能，包括 kubectl debug、拓扑管理器、Ingress 毕业为 V1 版本以及 client-go。 在此处注册：https://www.cncf.io/webinars/kubernetes-1-18/ 。 + +<!-- +### Get Involved +--> +### 如何参与 + +<!-- +The simplest way to get involved with Kubernetes is by joining one of the many [Special Interest Groups](https://github.com/kubernetes/community/blob/master/sig-list.md) (SIGs) that align with your interests. Have something you’d like to broadcast to the Kubernetes community? Share your voice at our weekly [community meeting](https://github.com/kubernetes/community/tree/master/communication), and through the channels below. Thank you for your continued feedback and support. +--> +参与 Kubernetes 的最简单方法是加入众多与您的兴趣相关的 [特别兴趣小组](https://github.com/kubernetes/community/blob/master/sig-list.md) (SIGs) 之一。 您有什么想向 Kubernetes 社区发布的内容吗？ 参与我们的每周 [社区会议](https://github.com/kubernetes/community/tree/master/communication)，并通过以下渠道分享您的声音。 感谢您一直以来的反馈和支持。 + +<!-- +- Follow us on Twitter [@Kubernetesio](https://twitter.com/kubernetesio) for latest updates +- Join the community discussion on [Discuss](https://discuss.kubernetes.io/) +- Join the community on [Slack](http://slack.k8s.io/) +- Post questions (or answer questions) on [Stack Overflow](http://stackoverflow.com/questions/tagged/kubernetes) +- Share your Kubernetes [story](https://docs.google.com/a/linuxfoundation.org/forms/d/e/1FAIpQLScuI7Ye3VQHQTwBASrgkjQDSS5TP0g3AXfFhwSM9YpHgxRKFA/viewform) +- Read more about what’s happening with Kubernetes on the [blog](https://kubernetes.io/blog/) +- Learn more about the [Kubernetes Release Team](https://github.com/kubernetes/sig-release/tree/master/release-team) +--> +- 在 Twitter 上关注我们 [@Kubernetesio](https://twitter.com/kubernetesio)，了解最新动态 +- 在 [Discuss](https://discuss.kubernetes.io/) 上参与社区讨论 +- 加入 [Slack](http://slack.k8s.io/) 上的社区 +- 在[Stack Overflow](http://stackoverflow.com/questions/tagged/kubernetes)提问（或回答） +- 分享您的 Kubernetes [故事](https://docs.google.com/a/linuxfoundation.org/forms/d/e/1FAIpQLScuI7Ye3VQHQTwBASrgkjQDSS5TP0g3AXfFhwSM9YpHgxRKFA/viewform) +- 通过 [blog](https://kubernetes.io/blog/)了解更多关于 Kubernetes 的新鲜事 +- 了解更多关于 [Kubernetes 发布团队](https://github.com/kubernetes/sig-release/tree/master/release-team) 的信息 diff --git a/content/zh/docs/concepts/_index.md b/content/zh/docs/concepts/_index.md index 90e2d6b4f1..5a83afcdf0 100644 --- a/content/zh/docs/concepts/_index.md +++ b/content/zh/docs/concepts/_index.md @@ -19,136 +19,3 @@ The Concepts section helps you learn about the parts of the Kubernetes system an --> 概念部分可以帮助你了解 Kubernetes 的各个组成部分以及 Kubernetes 用来表示集群的一些抽象概念，并帮助你更加深入的理解 Kubernetes 是如何工作的。 - - - -<!-- body --> - -<!-- -## Overview ---> - -## 概述 - -<!-- -To work with Kubernetes, you use *Kubernetes API objects* to describe your cluster's *desired state*: what applications or other workloads you want to run, what container images they use, the number of replicas, what network and disk resources you want to make available, and more. You set your desired state by creating objects using the Kubernetes API, typically via the command-line interface, `kubectl`. You can also use the Kubernetes API directly to interact with the cluster and set or modify your desired state. ---> - -要使用 Kubernetes，你需要用 *Kubernetes API 对象* 来描述集群的 *预期状态（desired state）* ：包括你需要运行的应用或者负载，它们使用的镜像、副本数，以及所需网络和磁盘资源等等。你可以使用命令行工具 `kubectl` 来调用 Kubernetes API 创建对象，通过所创建的这些对象来配置预期状态。你也可以直接调用 Kubernetes API 和集群进行交互，设置或者修改预期状态。 - -<!-- -Once you've set your desired state, the *Kubernetes Control Plane* makes the cluster's current state match the desired state via the Pod Lifecycle Event Generator ([PLEG](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/node/pod-lifecycle-event-generator.md)). To do so, Kubernetes performs a variety of tasks automatically--such as starting or restarting containers, scaling the number of replicas of a given application, and more. The Kubernetes Control Plane consists of a collection of processes running on your cluster: ---> - -一旦你设置了你所需的目标状态，*Kubernetes 控制面（control plane）* 会通过 Pod 生命周期事件生成器([PLEG](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/node/pod-lifecycle-event-generator.md))，促成集群的当前状态符合其预期状态。为此，Kubernetes 会自动执行各类任务，比如运行或者重启容器、调整给定应用的副本数等等。Kubernetes 控制面由一组运行在集群上的进程组成： - -<!-- -* The **Kubernetes Master** is a collection of three processes that run on a single node in your cluster, which is designated as the master node. Those processes are: [kube-apiserver](/docs/admin/kube-apiserver/), [kube-controller-manager](/docs/admin/kube-controller-manager/) and [kube-scheduler](/docs/admin/kube-scheduler/). -* Each individual non-master node in your cluster runs two processes: - * **[kubelet](/docs/admin/kubelet/)**, which communicates with the Kubernetes Master. - * **[kube-proxy](/docs/admin/kube-proxy/)**, a network proxy which reflects Kubernetes networking services on each node. ---> - -* **Kubernetes 主控组件（Master）** 包含三个进程，都运行在集群中的某个节点上，主控组件通常这个节点被称为 master 节点。这些进程包括：[kube-apiserver](/docs/admin/kube-apiserver/)、[kube-controller-manager](/docs/admin/kube-controller-manager/) 和 [kube-scheduler](/docs/admin/kube-scheduler/)。 -* 集群中的每个非 master 节点都运行两个进程： - * **[kubelet](/docs/admin/kubelet/)**，和 master 节点进行通信。 - * **[kube-proxy](/docs/admin/kube-proxy/)**，一种网络代理，将 Kubernetes 的网络服务代理到每个节点上。 - -<!-- -## Kubernetes Objects ---> - -## Kubernetes 对象 - -<!-- -Kubernetes contains a number of abstractions that represent the state of your system: deployed containerized applications and workloads, their associated network and disk resources, and other information about what your cluster is doing. These abstractions are represented by objects in the Kubernetes API. See [Understanding Kubernetes Objects](/docs/concepts/overview/working-with-objects/kubernetes-objects/) for more details. ---> - -Kubernetes 包含若干用来表示系统状态的抽象层，包括：已部署的容器化应用和负载、与它们相关的网络和磁盘资源以及有关集群正在运行的其他操作的信息。这些抽象使用 Kubernetes API 对象来表示。有关更多详细信息，请参阅[了解 Kubernetes 对象](/docs/concepts/overview/working-with-objects/kubernetes-objects/)。 - -<!-- -The basic Kubernetes objects include: ---> - -基本的 Kubernetes 对象包括： - -* [Pod](/docs/concepts/workloads/pods/pod-overview/) -* [Service](/docs/concepts/services-networking/service/) -* [Volume](/docs/concepts/storage/volumes/) -* [Namespace](/docs/concepts/overview/working-with-objects/namespaces/) - -<!-- -Kubernetes also contains higher-level abstractions that rely on [Controllers](/docs/concepts/architecture/controller/) to build upon the basic objects, and provide additional functionality and convenience features. These include: ---> - -Kubernetes 也包含大量的被称作 [Controller](/docs/concepts/architecture/controller/) 的高级抽象。控制器基于基本对象构建并提供额外的功能和方便使用的特性。具体包括： - -* [Deployment](/docs/concepts/workloads/controllers/deployment/) -* [DaemonSet](/docs/concepts/workloads/controllers/daemonset/) -* [StatefulSet](/docs/concepts/workloads/controllers/statefulset/) -* [ReplicaSet](/docs/concepts/workloads/controllers/replicaset/) -* [Job](/docs/concepts/workloads/controllers/jobs-run-to-completion/) - -<!-- -## Kubernetes Control Plane ---> - -## Kubernetes 控制面 - -<!-- -The various parts of the Kubernetes Control Plane, such as the Kubernetes Master and kubelet processes, govern how Kubernetes communicates with your cluster. The Control Plane maintains a record of all of the Kubernetes Objects in the system, and runs continuous control loops to manage those objects' state. At any given time, the Control Plane's control loops will respond to changes in the cluster and work to make the actual state of all the objects in the system match the desired state that you provided. ---> - -关于 Kubernetes 控制平面的各个部分，（如 Kubernetes 主控组件和 kubelet 进程），管理着 Kubernetes 如何与你的集群进行通信。控制平面维护着系统中所有的 Kubernetes 对象的状态记录，并且通过连续的控制循环来管理这些对象的状态。在任意的给定时间点，控制面的控制环都能响应集群中的变化，并且让系统中所有对象的实际状态与你提供的预期状态相匹配。 - -<!-- -For example, when you use the Kubernetes API to create a Deployment, you provide a new desired state for the system. The Kubernetes Control Plane records that object creation, and carries out your instructions by starting the required applications and scheduling them to cluster nodes--thus making the cluster's actual state match the desired state. ---> - -比如， 当你通过 Kubernetes API 创建一个 Deployment 对象，你就为系统增加了一个新的目标状态。Kubernetes 控制平面记录着对象的创建，并启动必要的应用然后将它们调度至集群某个节点上来执行你的指令，以此来保持集群的实际状态和目标状态的匹配。 - -<!-- -### Kubernetes Master ---> - -### Kubernetes Master 节点 - -<!-- -The Kubernetes master is responsible for maintaining the desired state for your cluster. When you interact with Kubernetes, such as by using the `kubectl` command-line interface, you're communicating with your cluster's Kubernetes master. ---> - -Kubernetes master 节点负责维护集群的目标状态。当你要与 Kubernetes 通信时，使用如 `kubectl` 的命令行工具，就可以直接与 Kubernetes master 节点进行通信。 - -<!-- -> The "master" refers to a collection of processes managing the cluster state. Typically all these processes run on a single node in the cluster, and this node is also referred to as the master. The master can also be replicated for availability and redundancy. ---> - -> "master" 是指管理集群状态的一组进程的集合。通常这些进程都跑在集群中一个单独的节点上，并且这个节点被称为 master 节点。master 节点也可以扩展副本数，来获取更好的可用性及冗余。 - -<!-- -### Kubernetes Nodes ---> - -### Kubernetes Node 节点 - -<!-- -The nodes in a cluster are the machines (VMs, physical servers, etc) that run your applications and cloud workflows. The Kubernetes master controls each node; you'll rarely interact with nodes directly. ---> - -集群中的 node 节点（虚拟机、物理机等等）都是用来运行你的应用和云工作流的机器。Kubernetes master 节点控制所有 node 节点；你很少需要和 node 节点进行直接通信。 - - - - -## {{% heading "whatsnext" %}} - - -<!-- -If you would like to write a concept page, see -[Using Page Templates](/docs/home/contribute/page-templates/) -for information about the concept page type and the concept template. ---> - -如果你想编写一个概念页面，请参阅[使用页面模板](/docs/home/contribute/page-templates/)获取更多有关概念页面类型和概念模板的信息。 - - diff --git a/content/zh/docs/concepts/architecture/_index.md b/content/zh/docs/concepts/architecture/_index.md index a68ed48a45..5e707ed397 100755 --- a/content/zh/docs/concepts/architecture/_index.md +++ b/content/zh/docs/concepts/architecture/_index.md @@ -1,4 +1,6 @@ --- title: "Kubernetes 架构" weight: 30 +description: > + Kubernetes 背后的架构概念。 --- diff --git a/content/zh/docs/concepts/architecture/control-plane-node-communication.md b/content/zh/docs/concepts/architecture/control-plane-node-communication.md new file mode 100644 index 0000000000..23ae4e3919 --- /dev/null +++ b/content/zh/docs/concepts/architecture/control-plane-node-communication.md @@ -0,0 +1,172 @@ +--- +title: 控制面到节点通信 +content_type: concept +weight: 20 +--- + +<!-- +title: Control Plane-Node Communication +content_type: concept +weight: 20 +aliases: +- master-node-communication +--> + +<!-- overview --> + +<!-- +This document catalogs the communication paths between the control plane (really the apiserver) and the Kubernetes cluster. The intent is to allow users to customize their installation to harden the network configuration such that the cluster can be run on an untrusted network (or on fully public IPs on a cloud provider). +--> +本文列举控制面节点（确切说是 API 服务器）和 Kubernetes 集群之间的通信路径。 +目的是为了让用户能够自定义他们的安装，以实现对网络配置的加固，使得集群能够在不可信的网络上 +（或者在一个云服务商完全公开的 IP 上）运行。 + +<!-- body --> +<!-- +## Node to Control Plane +Kubernetes has a "hub-and-spoke" API pattern. All API usage from nodes (or the pods they run) terminate at the apiserver (none of the other control plane components are designed to expose remote services). The apiserver is configured to listen for remote connections on a secure HTTPS port (typically 443) with one or more forms of client [authentication](/docs/reference/access-authn-authz/authentication/) enabled. +One or more forms of [authorization](/docs/reference/access-authn-authz/authorization/) should be enabled, especially if [anonymous requests](/docs/reference/access-authn-authz/authentication/#anonymous-requests) or [service account tokens](/docs/reference/access-authn-authz/authentication/#service-account-tokens) are allowed. +--> +## 节点到控制面 + +Kubernetes 采用的是中心辐射型（Hub-and-Spoke）API 模式。 +所有从集群（或所运行的 Pods）发出的 API 调用都终止于 apiserver（其它控制面组件都没有被设计为可暴露远程服务）。 +apiserver 被配置为在一个安全的 HTTPS 端口（443）上监听远程连接请求， +并启用一种或多种形式的客户端[身份认证](/zh/docs/reference/access-authn-authz/authentication/)机制。 +一种或多种客户端[鉴权机制](/zh/docs/reference/access-authn-authz/authorization/)应该被启用， +特别是在允许使用[匿名请求](/zh/docs/reference/access-authn-autha/authentication/#anonymous-requests) +或[服务账号令牌](/zh/docs/reference/access-authn-authz/authentication/#service-account-tokens)的时候。 + +<!-- +Nodes should be provisioned with the public root certificate for the cluster such that they can connect securely to the apiserver along with valid client credentials. For example, on a default GKE deployment, the client credentials provided to the kubelet are in the form of a client certificate. See [kubelet TLS bootstrapping](/docs/reference/command-line-tools-reference/kubelet-tls-bootstrapping/) for automated provisioning of kubelet client certificates. +--> +应该使用集群的公共根证书开通节点，这样它们就能够基于有效的客户端凭据安全地连接 apiserver。 +例如：在一个默认的 GCE 部署中，客户端凭据以客户端证书的形式提供给 kubelet。 +请查看 [kubelet TLS 启动引导](/zh/docs/reference/command-line-tools-reference/kubelet-tls-bootstrapping/) +以了解如何自动提供 kubelet 客户端证书。 + +<!-- +Pods that wish to connect to the apiserver can do so securely by leveraging a service account so that Kubernetes will automatically inject the public root certificate and a valid bearer token into the pod when it is instantiated. +The `kubernetes` service (in all namespaces) is configured with a virtual IP address that is redirected (via kube-proxy) to the HTTPS endpoint on the apiserver. + +The control plane components also communicate with the cluster apiserver over the secure port. +--> +想要连接到 apiserver 的 Pod 可以使用服务账号安全地进行连接。 +当 Pod 被实例化时，Kubernetes 自动把公共根证书和一个有效的持有者令牌注入到 Pod 里。 +`kubernetes` 服务（位于所有名字空间中）配置了一个虚拟 IP 地址，用于（通过 kube-proxy）转发 +请求到 apiserver 的 HTTPS 末端。 + +控制面组件也通过安全端口与集群的 apiserver 通信。 + +<!-- +As a result, the default operating mode for connections from the nodes and pods running on the nodes to the control plane is secured by default and can run over untrusted and/or public networks. +--> +这样，从集群节点和节点上运行的 Pod 到控制面的连接的缺省操作模式即是安全的，能够在不可信的网络或公网上运行。 + +<!-- +## Control Plane to node + +There are two primary communication paths from the control plane (apiserver) to the nodes. The first is from the apiserver to the kubelet process which runs on each node in the cluster. The second is from the apiserver to any node, pod, or service through the apiserver's proxy functionality. +--> +## 控制面到节点 + +从控制面（apiserver）到节点有两种主要的通信路径。 +第一种是从 apiserver 到集群中每个节点上运行的 kubelet 进程。 +第二种是从 apiserver 通过它的代理功能连接到任何节点、Pod 或者服务。 + +<!-- +### apiserver to kubelet + +The connections from the apiserver to the kubelet are used for: + +* Fetching logs for pods. +* Attaching (through kubectl) to running pods. +* Providing the kubelet's port-forwarding functionality. + +These connections terminate at the kubelet's HTTPS endpoint. By default, the apiserver does not verify the kubelet's serving certificate, which makes the connection subject to man-in-the-middle attacks, and **unsafe** to run over untrusted and/or public networks. +--> +### API 服务器到 kubelet + +从 apiserver 到 kubelet 的连接用于： + +* 获取 Pod 日志 +* 挂接（通过 kubectl）到运行中的 Pod +* 提供 kubelet 的端口转发功能。 + +这些连接终止于 kubelet 的 HTTPS 末端。 +默认情况下，apiserver 不检查 kubelet 的服务证书。这使得此类连接容易受到中间人攻击， +在非受信网络或公开网络上运行也是 **不安全的**。 + +<!-- +To verify this connection, use the `--kubelet-certificate-authority` flag to provide the apiserver with a root certificate bundle to use to verify the kubelet's serving certificate. + +If that is not possible, use [SSH tunneling](/docs/concepts/architecture/master-node-communication/#ssh-tunnels) between the apiserver and kubelet if required to avoid connecting over an +untrusted or public network. + +Finally, [Kubelet authentication and/or authorization](/docs/admin/kubelet-authentication-authorization/) should be enabled to secure the kubelet API. +--> + +为了对这个连接进行认证，使用 `--kubelet-certificate-authority` 标志给 apiserver +提供一个根证书包，用于 kubelet 的服务证书。 + +如果无法实现这点，又要求避免在非受信网络或公共网络上进行连接，可在 apiserver 和 +kubelet 之间使用 [SSH 隧道](#ssh-tunnels)。 + +最后，应该启用 [Kubelet 用户认证和/或鉴权](/zh/docs/reference/command-line-tools-reference/kubelet-authentication-authorization/) +来保护 kubelet API。 + +<!-- +### apiserver to nodes, pods, and services + +The connections from the apiserver to a node, pod, or service default to plain HTTP connections and are therefore neither authenticated nor encrypted. They can be run over a secure HTTPS connection by prefixing `https:` to the node, pod, or service name in the API URL, but they will not validate the certificate provided by the HTTPS endpoint nor provide client credentials so while the connection will be encrypted, it will not provide any guarantees of integrity. These connections **are not currently safe** to run over untrusted and/or public networks. +--> + +### apiserver 到节点、Pod 和服务 + +从 apiserver 到节点、Pod 或服务的连接默认为纯 HTTP 方式，因此既没有认证，也没有加密。 +这些连接可通过给 API URL 中的节点、Pod 或服务名称添加前缀 `https:` 来运行在安全的 HTTPS 连接上。 +不过这些连接既不会验证 HTTPS 末端提供的证书，也不会提供客户端证书。 +因此，虽然连接是加密的，仍无法提供任何完整性保证。 +这些连接 **目前还不能安全地** 在非受信网络或公共网络上运行。 + +<!-- +### SSH tunnels + +Kubernetes supports SSH tunnels to protect the control plane to nodes communication paths. In this configuration, the apiserver initiates an SSH tunnel to each node in the cluster (connecting to the ssh server listening on port 22) and passes all traffic destined for a kubelet, node, pod, or service through the tunnel. +This tunnel ensures that the traffic is not exposed outside of the network in which the nodes are running. + +SSH tunnels are currently deprecated so you shouldn't opt to use them unless you know what you are doing. The Konnectivity service is a replacement for this communication channel. +--> + +### SSH 隧道 {#ssh-tunnels} + +Kubernetes 支持使用 SSH 隧道来保护从控制面到节点的通信路径。在这种配置下，apiserver +建立一个到集群中各节点的 SSH 隧道（连接到在 22 端口监听的 SSH 服务） +并通过这个隧道传输所有到 kubelet、节点、Pod 或服务的请求。 +这一隧道保证通信不会被暴露到集群节点所运行的网络之外。 + +SSH 隧道目前已被废弃。除非你了解个中细节，否则不应使用。 +Konnectivity 服务是对此通信通道的替代品。 + +<!-- +### Konnectivity service + +{{< feature-state for_k8s_version="v1.18" state="beta" >}} + +As a replacement to the SSH tunnels, the Konnectivity service provides TCP level proxy for the control plane to cluster communication. The Konnectivity service consists of two parts: the Konnectivity server and the Konnectivity agents, running in the control plane network and the nodes network respectively. The Konnectivity agents initiate connections to the Konnectivity server and maintain the network connections. +After enabling the Konnectivity service, all control plane to nodes traffic goes through these connections. + +Follow the [Konnectivity service task](/docs/tasks/extend-kubernetes/setup-konnectivity/) to set up the Konnectivity service in your cluster. +--> + +### Konnectivity 服务 + +{{< feature-state for_k8s_version="v1.18" state="beta" >}} + +作为 SSH 隧道的替代方案，Konnectivity 服务提供 TCP 层的代理，以便支持从控制面到集群的通信。 +Konnectivity 服务包含两个部分：Konnectivity 服务器和 Konnectivity 代理，分别运行在 +控制面网络和节点网络中。Konnectivity 代理建立并维持到 Konnectivity 服务器的网络连接。 +启用 Konnectivity 服务之后，所有控制面到节点的通信都通过这些连接传输。 + +请浏览 [Konnectivity 服务任务](/zh/docs/tasks/extend-kubernetes/setup-konnectivity/) +在你的集群中配置 Konnectivity 服务。 diff --git a/content/zh/docs/concepts/architecture/controller.md b/content/zh/docs/concepts/architecture/controller.md index 2d2b4e4317..f7d86e3fec 100644 --- a/content/zh/docs/concepts/architecture/controller.md +++ b/content/zh/docs/concepts/architecture/controller.md @@ -16,18 +16,16 @@ about your *desired state*. The actual room temperature is the *current state*. The thermostat acts to bring the current state closer to the desired state, by turning equipment on or off. --> - -在机器人技术和自动化中，控制环是一个控制系统状态的不终止的循环。 +在机器人技术和自动化领域，控制回路（Control Loop）是一个非终止回路，用于调节系统状态。 这是一个控制环的例子：房间里的温度自动调节器。 -当你设置了温度，告诉了温度自动调节器你的*期望状态*。房间的实际温度是*当前状态*。通过对设备的开关控制，温度自动调节器让其当前状态接近期望状态。 +当你设置了温度，告诉了温度自动调节器你的*期望状态（Desired State）*。 +房间的实际温度是*当前状态（Current State）*。 +通过对设备的开关控制，温度自动调节器让其当前状态接近期望状态。 {{< glossary_definition term_id="controller" length="short">}} - - - <!-- body --> <!-- ## Controller pattern @@ -51,12 +49,18 @@ detail. --> ## 控制器模式 {#controller-pattern} -一个控制器至少追踪一种类型的 Kubernetes 资源。这些[对象](/docs/concepts/overview/working-with-objects/kubernetes-objects/)有一个代表期望状态的指定字段。控制器负责确保其追踪的资源对象的当前状态接近期望状态。 +一个控制器至少追踪一种类型的 Kubernetes 资源。这些 +[对象](/zh/docs/concepts/overview/working-with-objects/kubernetes-objects/) +有一个代表期望状态的 `spec` 字段。 +该资源的控制器负责确保其当前状态接近期望状态。 -控制器可能会自行执行操作；在 Kubernetes 中更常见的是一个控制器会发送信息给 {{< glossary_tooltip text="API 服务器" term_id="kube-apiserver" >}}，这会有副作用。看下面这个例子。 +控制器可能会自行执行操作；在 Kubernetes 中更常见的是一个控制器会发送信息给 +{{< glossary_tooltip text="API 服务器" term_id="kube-apiserver" >}}，这会有副作用。 +具体可参看后文的例子。 {{< comment >}} -一些内置的控制器，比如命名空间控制器，针对没有指定命名空间的对象。为了简单起见，这篇文章没有详细介绍这些细节。 +一些内置的控制器，比如名字空间控制器，针对没有指定 `spec` 的对象。 +为了简单起见，本文没有详细介绍这些细节。 {{< /comment >}} <!-- @@ -87,15 +91,19 @@ and eventually the work is done. ### 通过 API 服务器来控制 {#control-via-API-server} -{{< glossary_tooltip term_id="job" >}} 控制器是一个 Kubernetes 内置控制器的例子。内置控制器通过和集群 API 服务器交互来管理状态。 +{{< glossary_tooltip text="Job" term_id="job" >}} 控制器是一个 Kubernetes 内置控制器的例子。 +内置控制器通过和集群 API 服务器交互来管理状态。 -Job 是一种 Kubernetes 资源，它运行一个 {{< glossary_tooltip term_id="pod" >}}，或者可能是多个 Pod，来执行一个任务然后停止。 +Job 是一种 Kubernetes 资源，它运行一个或者多个 {{< glossary_tooltip term_id="pod" >}}， +来执行一个任务然后停止。 +（一旦[被调度了](/zh/docs/concepts/scheduling-eviction/)，对 `kubelet` 来说 Pod +对象就会变成了期望状态的一部分）。 -（一旦[被调度了](/docs/concepts/scheduling/)），对 kubelet 来说 Pod 对象就会变成了期望状态的一部分。 - -在集群中，当 Job 控制器拿到新任务时，它会保证一组 Node 节点上的 kubelet 可以运行正确数量的 Pod 来完成工作。 +在集群中，当 Job 控制器拿到新任务时，它会保证一组 Node 节点上的 `kubelet` +可以运行正确数量的 Pod 来完成工作。 Job 控制器不会自己运行任何的 Pod 或者容器。Job 控制器是通知 API 服务器来创建或者移除 Pod。 -{{< glossary_tooltip text="控制平面" term_id="control-plane" >}}中的其它组件根据新的消息而反应（调度新的 Pod 并且运行它）并且最终完成工作。 +{{< glossary_tooltip text="控制面" term_id="control-plane" >}}中的其它组件 +根据新的消息作出反应（调度并运行新 Pod）并且最终完成工作。 <!-- After you create a new Job, the desired state is for that Job to be completed. @@ -110,7 +118,6 @@ updates that Job object to mark it `Finished`. (This is a bit like how some thermostats turn a light off to indicate that your room is now at the temperature you set). --> - 创建新 Job 后，所期望的状态就是完成这个 Job。Job 控制器会让 Job 的当前状态不断接近期望状态：创建为 Job 要完成工作所需要的 Pod，使 Job 的状态接近完成。 控制器也会更新配置对象。例如：一旦 Job 的工作完成了，Job 控制器会更新 Job 对象的状态为 `Finished`。 @@ -145,7 +152,8 @@ nodes in your cluster. See 和外部状态交互的控制器从 API 服务器获取到它想要的状态，然后直接和外部系统进行通信并使当前状态更接近期望状态。 -（实际上有一个控制器可以水平地扩展集群中的节点。请看[集群自动扩缩容](/docs/tasks/administer-cluster/cluster-management/#cluster-autoscaling)）。 +（实际上有一个控制器可以水平地扩展集群中的节点。请参阅 +[集群自动扩缩容](/zh/docs/tasks/administer-cluster/cluster-management/#cluster-autoscaling)）。 <!-- ## Desired versus current state {#desired-vs-current} @@ -160,12 +168,11 @@ potentially, your cluster never reaches a stable state. As long as the controllers for your cluster are running and able to make useful changes, it doesn't matter if the overall state is or is not stable. --> - ## 期望状态与当前状态 {#desired-vs-current} Kubernetes 采用了系统的云原生视图，并且可以处理持续的变化。 -在任务执行时，集群随时都可能被修改，并且控制环会自动的修复故障。这意味着很可能集群永远不会达到稳定状态。 +在任务执行时，集群随时都可能被修改，并且控制回路会自动修复故障。这意味着很可能集群永远不会达到稳定状态。 只要集群中控制器的在运行并且进行有效的修改，整体状态的稳定与否是无关紧要的。 @@ -181,12 +188,17 @@ It's useful to have simple controllers rather than one, monolithic set of contro loops that are interlinked. Controllers can fail, so Kubernetes is designed to allow for that. -For example: a controller for Jobs tracks Job objects (to discover -new work) and Pod object (to run the Jobs, and then to see when the work is -finished). In this case something else creates the Jobs, whereas the Job -controller creates Pods. +--> +## 设计 {#design} -{{< note >}} +作为设计原则之一，Kubernetes 使用了很多控制器，每个控制器管理集群状态的一个特定方面。 +最常见的一个特定的控制器使用一种类型的资源作为它的期望状态， +控制器管理控制另外一种类型的资源向它的期望状态演化。 + +使用简单的控制器而不是一组相互连接的单体控制回路是很有用的。 +控制器会失败，所以 Kubernetes 的设计正是考虑到了这一点。 + +<!-- There can be several controllers that create or update the same kind of object. Behind the scenes, Kubernetes controllers make sure that they only pay attention to the resources linked to their controlling resource. @@ -195,21 +207,14 @@ For example, you can have Deployments and Jobs; these both create Pods. The Job controller does not delete the Pods that your Deployment created, because there is information ({{< glossary_tooltip term_id="label" text="labels" >}}) the controllers can use to tell those Pods apart. -{{< /note >}} --> - -## 设计 {#design} - -作为设计的一个原则，Kubernetes 使用了很多控制器，每个控制器管理集群状态的一个特定方面。最常见的一个特定的控制器使用一种类型的资源作为它的期望状态，控制器管理控制另外一种类型的资源向它的期望状态发展。 - -使用简单的控制器而不是一组相互连接的单体控制环是很有用的。控制器会失败，所以 Kubernetes 的设计是考虑到了这一点。 - -例如：为 Job 追踪 Job 对象（发现新工作）和 Pod 对象（运行 Job，并且等工作完成）的控制器。在本例中，其它东西创建作业，而作业控制器创建 Pod。 - {{< note >}} -可以有多个控制器来创建或者更新相同类型的对象。在这之后，Kubernetes 控制器确保他们只关心和它们控制资源相关联的资源。 +可以有多个控制器来创建或者更新相同类型的对象。 +在后台，Kubernetes 控制器确保它们只关心与其控制资源相关联的资源。 -例如，你可以有 Deployments 和 Jobs；它们都可以创建 Pod。Job 控制器不删除 Deployment 创建的 Pod，因为有信息({{< glossary_tooltip term_id="label" text="标签" >}})让控制器可以区分这些 Pod。 +例如，你可以创建 Deployment 和 Job；它们都可以创建 Pod。 +Job 控制器不会删除 Deployment 所创建的 Pod，因为有信息 +（{{< glossary_tooltip term_id="label" text="标签" >}}）让控制器可以区分这些 Pod。 {{< /note >}} <!-- @@ -229,27 +234,30 @@ Or, if you want, you can write a new controller yourself. You can run your own controller as a set of Pods, or externally to Kubernetes. What fits best will depend on what that particular controller does. +--> +## 运行控制器的方式 {#running-controllers} +Kubernetes 内置一组控制器，运行在 {{< glossary_tooltip term_id="kube-controller-manager" >}} 内。 +这些内置的控制器提供了重要的核心功能。 + +Deployment 控制器和 Job 控制器是 Kubernetes 内置控制器的典型例子。 +Kubernetes 允许你运行一个稳定的控制平面，这样即使某些内置控制器失败了， +控制平面的其他部分会接替它们的工作。 + +你会遇到某些控制器运行在控制面之外，用以扩展 Kubernetes。 +或者，如果你愿意，你也可以自己编写新控制器。 +你可以以一组 Pod 来运行你的控制器，或者运行在 Kubernetes 之外。 +最合适的方案取决于控制器所要执行的功能是什么。 + +## {{% heading "whatsnext" %}} +<!-- * Read about the [Kubernetes control plane](/docs/concepts/#kubernetes-control-plane) * Discover some of the basic [Kubernetes objects](/docs/concepts/#kubernetes-objects) * Learn more about the [Kubernetes API](/docs/concepts/overview/kubernetes-api/) * If you want to write your own controller, see [Extension Patterns](/docs/concepts/extend-kubernetes/extend-cluster/#extension-patterns) in Extending Kubernetes. --> - -## 运行控制器的方式 {#running-controllers} - -Kubernetes 自带有一组内置的控制器，运行在 {{< glossary_tooltip term_id="kube-controller-manager" >}} 内。这些内置的控制器提供了重要的核心功能。 - -Deployment 控制器和 Job 控制器是 Kubernetes 内置控制器的典型例子。Kubernetes 运行一个弹性的控制平面，所以如果任意内置控制器失败了，控制平面的另外一部分会接替它的工作。 - -你会发现控制平面外面运行的控制器，扩展了 Kubernetes 的能力。或者，如果你愿意，你也可以写一个新控制器。你可以以一组 Pod 来运行你的控制器，或者运行在 Kubernetes 外面。什么是最合适的控制器，这将取决于特定控制器的功能。 - - - -## {{% heading "whatsnext" %}} - -* 请阅读 [Kubernetes 控制平面](/docs/concepts/#kubernetes-control-plane) -* 了解一些基本的 [Kubernetes 对象](/docs/concepts/#kubernetes-objects) -* 学习更多的 [Kubernetes API](/docs/concepts/overview/kubernetes-api/) -* 如果你想写自己的控制器，请看 Kubernetes 的[扩展模式](/docs/concepts/extend-kubernetes/extend-cluster/#extension-patterns)。 +* 阅读 [Kubernetes 控制面](/zh/docs/concepts/#kubernetes-control-plane) +* 了解 [Kubernetes 对象](/zh/docs/concepts/#kubernetes-objects) 的一些基本知识 +* 进一步学习 [Kubernetes API](/zh/docs/concepts/overview/kubernetes-api/) +* 如果你想编写自己的控制器，请看 Kubernetes 的[扩展模式](/zh/docs/concepts/extend-kubernetes/extend-cluster/#extension-patterns)。 diff --git a/content/zh/docs/concepts/architecture/master-node-communication.md b/content/zh/docs/concepts/architecture/master-node-communication.md deleted file mode 100644 index d0357fb3cb..0000000000 --- a/content/zh/docs/concepts/architecture/master-node-communication.md +++ /dev/null @@ -1,69 +0,0 @@ ---- -approvers: -- dchen1107 -- liggitt - -title: Master 节点通信 ---- - -{{< toc >}} - - -## 概览 - - -本文对 Master 节点（确切说是 apiserver）和 Kubernetes 集群之间的通信路径进行了分类。目的是为了让用户能够自定义他们的安装，对网络配置进行加固，使得集群能够在不可信的网络上（或者在一个云服务商完全公共的 IP 上）运行。 - - -## Cluster -> Master - - -所有从集群到 master 的通信路径都终止于 apiserver（其它 master 组件没有被设计为可暴露远程服务）。在一个典型的部署中，apiserver 被配置为在一个安全的 HTTPS 端口（443）上监听远程连接并启用一种或多种形式的客户端[身份认证](/docs/admin/authentication/)机制。一种或多种客户端[身份认证](/docs/admin/authentication/)机制应该被启用，特别是在允许使用 [匿名请求](/docs/admin/authentication/#anonymous-requests) 或 [service account tokens](/docs/admin/authentication/#service-account-tokens) 的时候。 - - -应该使用集群的公共根证书开通节点，如此它们就能够基于有效的客户端凭据安全的连接 apiserver。例如：在一个默认的 GCE 部署中，客户端凭据以客户端证书的形式提供给 kubelet。请查看 [kubelet TLS bootstrapping](/docs/admin/kubelet-tls-bootstrapping/) 获取如何自动提供 kubelet 客户端证书。 - - -想要连接到 apiserver 的 Pods 可以使用一个 service account 安全的进行连接。这种情况下，当 Pods 被实例化时 Kubernetes 将自动的把公共根证书和一个有效的不记名令牌注入到 pod 里。`kubernetes` service （所有 namespaces 中）都配置了一个虚拟 IP 地址，用于转发（通过 kube-proxy）请求到 apiserver 的 HTTPS endpoint。 - - -Master 组件通过非安全（没有加密或认证）端口和集群的 apiserver 通信。这个端口通常只在 master 节点的 localhost 接口暴露，这样，所有在相同机器上运行的 master 组件就能和集群的 apiserver 通信。一段时间以后，master 组件将变为使用带身份认证和权限验证的安全端口（查看[#13598](https://github.com/kubernetes/kubernetes/issues/13598)）。 - - -这样的结果使得从集群（在节点上运行的 nodes 和 pods）到 master 的缺省连接操作模式默认被保护，能够在不可信或公网中运行。 - - -## Master -> Cluster - - -从 master（apiserver）到集群有两种主要的通信路径。第一种是从 apiserver 到集群中每个节点上运行的 kubelet 进程。第二种是从 apiserver 通过它的代理功能到任何 node、pod 或者 service。 - - -## apiserver -> kubelet - - -从 apiserver 到 kubelet 的连接用于获取 pods 日志、连接（通过 kubectl）运行中的 pods，以及使用 kubelet 的端口转发功能。这些连接终止于 kubelet 的 HTTPS endpoint。 - - -默认的，apiserver 不会验证 kubelet 的服务证书，这会导致连接遭到中间人攻击，因而在不可信或公共网络上是不安全的。 - - -为了对这个连接进行认证，请使用 `--kubelet-certificate-authority` 标记给 apiserver 提供一个根证书捆绑，用于 kubelet 的服务证书。 - - -如果这样不可能，又要求避免在不可信的或公共的网络上进行连接，请在 apiserver 和 kubelet 之间使用 [SSH 隧道](/docs/tasks/access-application-cluster/port-forward-access-application-cluster/)。 - - -最后，应该启用 [Kubelet 用户认证和/或权限认证](/docs/admin/kubelet-authentication-authorization/)来保护 kubelet API。 - - -## apiserver -> nodes, pods, and services - - -从 apiserver 到 node、pod 或者 service 的连接默认为纯 HTTP 方式，因此既没有认证，也没有加密。他们能够通过给 API URL 中的 node、pod 或 service 名称添加前缀 `https:` 来运行在安全的 HTTPS 连接上。但他们即不会认证 HTTPS endpoint 提供的证书，也不会提供客户端证书。这样虽然连接是加密的，但它不会提供任何完整性保证。这些连接**目前还不能安全的**在不可信的或公共的网络上运行。 - - -## SSH 隧道 - - -[Google Kubernetes Engine](https://cloud.google.com/kubernetes-engine/docs/) 使用 SSH 隧道保护 Master -> Cluster 通信路径。在这种配置下，apiserver 发起一个到集群中每个节点的 SSH 隧道（连接到在 22 端口监听的 ssh 服务）并通过这个隧道传输所有到 kubelet、node、pod 或者 service 的流量。这个隧道保证流量不会在集群运行的私有 GCE 网络之外暴露。 diff --git a/content/zh/docs/concepts/architecture/nodes.md b/content/zh/docs/concepts/architecture/nodes.md index 4ad6f81c64..ac6d1f3e95 100644 --- a/content/zh/docs/concepts/architecture/nodes.md +++ b/content/zh/docs/concepts/architecture/nodes.md @@ -4,211 +4,68 @@ content_type: concept weight: 10 --- <!-- ---- reviewers: - caesarxuchao - dchen1107 title: Nodes content_type: concept weight: 10 ---- --> <!-- overview --> <!-- -A node is a worker machine in Kubernetes, previously known as a `minion`. A node -may be a VM or physical machine, depending on the cluster. Each node contains -the services necessary to run [pods](/docs/concepts/workloads/pods/pod/) and is managed by the master -components. The services on a node include the [container runtime](/docs/concepts/overview/components/#node-components), kubelet and kube-proxy. See -[The Kubernetes Node](https://git.k8s.io/community/contributors/design-proposals/architecture/architecture.md#the-kubernetes-node) section in the -architecture design doc for more details. +Kubernetes runs your workload by placing containers into Pods to run on _Nodes_. +A node may be a virtual or physical machine, depending on the cluster. Each node +contains the services necessary to run +{{< glossary_tooltip text="Pods" term_id="pod" >}}, managed by the +{{< glossary_tooltip text="control plane" term_id="control-plane" >}}. + +Typically you have several nodes in a cluster; in a learning or resource-limited +environment, you might have just one. + +The [components](/docs/concepts/overview/components/#node-components) on a node include the +{{< glossary_tooltip text="kubelet" term_id="kubelet" >}}, a +{{< glossary_tooltip text="container runtime" term_id="container-runtime" >}}, and the +{{< glossary_tooltip text="kube-proxy" term_id="kube-proxy" >}}. --> -在 Kubernetes 中，节点（Node）是执行工作的机器，以前叫做 `minion`。根据你的集群环境，节点可以是一个虚拟机或者物理机器。每个节点都包含用于运行 [pods](/docs/concepts/workloads/pods/pod/) 的必要服务，并由主控组件管理。节点上的服务包括 [容器运行时](/docs/concepts/overview/components/#node-components)、kubelet 和 kube-proxy。查阅架构设计文档中 [Kubernetes 节点](https://git.k8s.io/community/contributors/design-proposals/architecture/architecture.md#the-kubernetes-node) 一节获取更多细节。 - - +Kubernetes 通过将容器放入在节点（Node）上运行的 Pod 中来执行你的工作负载。 +节点可以是一个虚拟机或者物理机器，取决于所在的集群配置。每个节点都包含用于运行 +{{< glossary_tooltip text="Pod" term_id="pod" >}} 所需要的服务，这些服务由 +{{< glossary_tooltip text="控制面" term_id="control-plane" >}}负责管理。 +通常集群中会有若干个节点；而在一个学习用或者资源受限的环境中，你的集群中也可能 +只有一个节点。 +节点上的[组件](/zh/docs/concepts/overview/components/#node-components)包括 +{{< glossary_tooltip text="kubelet" term_id="kubelet" >}}、 +{{< glossary_tooltip text="容器运行时" term_id="container-runtime" >}}以及 +{{< glossary_tooltip text="kube-proxy" term_id="kube-proxy" >}}。 <!-- body --> - -<!-- -## Node Status ---> -## 节点状态 - -<!-- -A node's status contains the following information: - -* [Addresses](#addresses) -* [Conditions](#condition) -* [Capacity and Allocatable](#capacity) -* [Info](#info) ---> -一个节点的状态包含以下信息: - -* [地址](#addresses) -* [条件](#condition) -* [容量与可分配](#capacity) -* [信息](#info) - - -<!-- -Node status and other details about a node can be displayed using below command: ---> -可以使用以下命令显示节点状态和有关节点的其他详细信息： -```shell -kubectl describe node <insert-node-name-here> -``` -<!-- -Each section is described in detail below. ---> -下面对每个章节进行详细描述。 - -<!-- -### Addresses ---> -### 地址 - -<!-- -The usage of these fields varies depending on your cloud provider or bare metal configuration. ---> -这些字段组合的用法取决于你的云服务商或者裸机配置。 - -<!-- -* HostName: The as reported by the node's kernel. Can be overridden via the kubelet `--hostname-override` parameter. -* ExternalIP: Typically the IP address of the node that is externally routable (available from outside the cluster). -* InternalIP: Typichostnameally the IP address of the node that is routable only within the cluster. ---> -* HostName：由节点的内核指定。可以通过 kubelet 的 `--hostname-override` 参数覆盖。 -* ExternalIP：通常是可以外部路由的节点 IP 地址（从集群外可访问）。 -* InternalIP：通常是仅可在集群内部路由的节点 IP 地址。 - - -<!-- -### Conditions {#condition} ---> -### 条件 {#condition} - -<!-- -The `conditions` field describes the status of all `Running` nodes. Examples of conditions include: ---> -`conditions` 字段描述了所有 `Running` 节点的状态。条件的示例包括： - -<!-- -| Node Condition | Description | -|----------------|-------------| -| `OutOfDisk` | `True` if there is insufficient free space on the node for adding new pods, otherwise `False` | -| `Ready` | `True` if the node is healthy and ready to accept pods, `False` if the node is not healthy and is not accepting pods, and `Unknown` if the node controller has not heard from the node in the last `node-monitor-grace-period` (default is 40 seconds) | -| `MemoryPressure` | `True` if pressure exists on the node memory -- that is, if the node memory is low; otherwise `False` | -| `PIDPressure` | `True` if pressure exists on the processes -- that is, if there are too many processes on the node; otherwise `False` | -| `DiskPressure` | `True` if pressure exists on the disk size -- that is, if the disk capacity is low; otherwise `False` | -| `NetworkUnavailable` | `True` if the network for the node is not correctly configured, otherwise `False` | ---> -| 节点条件 | 描述 | -|----------------|-------------| -| `OutOfDisk` | `True` 表示节点的空闲空间不足以用于添加新 pods, 否则为 `False` | -| `Ready` | 表示节点是健康的并已经准备好接受 pods；`False` 表示节点不健康而且不能接受 pods；`Unknown` 表示节点控制器在最近 40 秒内没有收到节点的消息 | -| `MemoryPressure` | `True` 表示节点存在内存压力 -- 即节点内存用量低，否则为 `False` | -| `PIDPressure` | `True` 表示节点存在进程压力 -- 即进程过多；否则为 `False` | -| `DiskPressure` | `True` 表示节点存在磁盘压力 -- 即磁盘可用量低，否则为 `False` | -| `NetworkUnavailable` | `True` 表示节点网络配置不正确；否则为 `False` | - -<!-- -The node condition is represented as a JSON object. For example, the following response describes a healthy node. ---> -节点条件使用一个 JSON 对象表示。例如，下面的响应描述了一个健康的节点。 - -```json -"conditions": [ - { - "type": "Ready", - "status": "True", - "reason": "KubeletReady", - "message": "kubelet is posting ready status", - "lastHeartbeatTime": "2019-06-05T18:38:35Z", - "lastTransitionTime": "2019-06-05T11:41:27Z" - } -] -``` - -<!-- -If the Status of the Ready condition remains `Unknown` or `False` for longer than the `pod-eviction-timeout`, an argument is passed to the [kube-controller-manager](/docs/admin/kube-controller-manager/) and all the Pods on the node are scheduled for deletion by the Node Controller. The default eviction timeout duration is **five minutes**. In some cases when the node is unreachable, the apiserver is unable to communicate with the kubelet on the node. The decision to delete the pods cannot be communicated to the kubelet until communication with the apiserver is re-established. In the meantime, the pods that are scheduled for deletion may continue to run on the partitioned node. ---> -如果 Ready 条件处于状态 `Unknown` 或者 `False` 的时间超过了 `pod-eviction-timeout`（一个传递给 [kube-controller-manager](/docs/admin/kube-controller-manager/) 的参数），节点上的所有 Pods 都会被节点控制器计划删除。默认的删除超时时长为**5 分钟**。某些情况下，当节点不可访问时，apiserver 不能和其上的 kubelet 通信。删除 pods 的决定不能传达给 kubelet，直到它重新建立和 apiserver 的连接为止。与此同时，被计划删除的 pods 可能会继续在分区节点上运行。 - - -<!-- -In versions of Kubernetes prior to 1.5, the node controller would [force delete](/docs/concepts/workloads/pods/pod/#force-deletion-of-pods) -these unreachable pods from the apiserver. However, in 1.5 and higher, the node controller does not force delete pods until it is -confirmed that they have stopped running in the cluster. You can see the pods that might be running on an unreachable node as being in -the `Terminating` or `Unknown` state. In cases where Kubernetes cannot deduce from the underlying infrastructure if a node has -permanently left a cluster, the cluster administrator may need to delete the node object by hand. Deleting the node object from -Kubernetes causes all the Pod objects running on the node to be deleted from the apiserver, and frees up their names. ---> -在 1.5 版本之前的 Kubernetes 里，节点控制器会将不能访问的 pods 从 apiserver 中[强制删除](/docs/concepts/workloads/pods/pod/#force-deletion-of-pods)。但在 1.5 或更高的版本里，在节点控制器确认这些 pods 已经在集群停止运行前不会强制删除它们。你可以看到这些处于 `Terminating` 或者 `Unknown` 状态的 pods 可能在无法访问的节点上运行。为了防止 kubernetes 不能从底层基础设施中推断出一个节点是否已经永久的离开了集群，集群管理员可能需要手动删除这个节点对象。从 Kubernetes 删除节点对象将导致 apiserver 删除节点上所有运行的 Pod 对象并释放它们的名字。 - - -<!-- -The node lifecycle controller automatically creates -[taints](/docs/concepts/configuration/taint-and-toleration/) that represent conditions. -When the scheduler is assigning a Pod to a Node, the scheduler takes the Node's taints -into account, except for any taints that the Pod tolerates. ---> -节点生命周期控制器会自动创建代表条件的[污点](/docs/concepts/configuration/taint-and-toleration/)。 -当调度器将 Pod 分配给节点时，调度器会考虑节点上的污点，但是 Pod 可以容忍的污点除外。 - -<!-- -### Capacity and Allocatable {#capacity} ---> -### 容量与可分配 {#capacity} - -<!-- -Describes the resources available on the node: CPU, memory and the maximum -number of pods that can be scheduled onto the node. ---> -描述节点上的可用资源：CPU、内存和可以调度到节点上的 pods 的最大数量。 - -<!-- -The fields in the capacity block indicate the total amount of resources that a -Node has. The allocatable block indicates the amount of resources on a -Node that is available to be consumed by normal Pods. ---> -capacity 块中的字段指示节点拥有的资源总量。allocatable 块指示节点上可供普通 Pod 消耗的资源量。 - -<!-- -You may read more about capacity and allocatable resources while learning how -to [reserve compute resources](/docs/tasks/administer-cluster/reserve-compute-resources/#node-allocatable) on a Node. ---> -可以在学习如何在节点上[保留计算资源](/docs/tasks/administer-cluster/reserve-compute-resources/#node-allocatable)的同时阅读有关容量和可分配资源的更多信息。 - -<!-- -### Info ---> -### 信息 - -<!-- -Describes general information about the node, such as kernel version, Kubernetes version (kubelet and kube-proxy version), Docker version (if used), and OS name. -This information is gathered by Kubelet from the node. ---> -关于节点的通用信息，例如内核版本、Kubernetes 版本（kubelet 和 kube-proxy 版本）、Docker 版本（如果使用了）和操作系统名称。这些信息由 kubelet 从节点上搜集而来。 - <!-- ## Management ---> -## 管理 -<!-- -Unlike [pods](/docs/concepts/workloads/pods/pod/) and [services](/docs/concepts/services-networking/service/), -a node is not inherently created by Kubernetes: it is created externally by cloud -providers like Google Compute Engine, or it exists in your pool of physical or virtual -machines. So when Kubernetes creates a node, it creates -an object that represents the node. After creation, Kubernetes -checks whether the node is valid or not. For example, if you try to create -a node from the following content: ---> -与 [pods](/docs/concepts/workloads/pods/pod/) 和 [services](/docs/concepts/services-networking/service/) 不同，节点并不是在 Kubernetes 内部创建的：它是被外部的云服务商创建，例如 Google Compute Engine 或者你的集群中的物理或者虚拟机。这意味着当 Kubernetes 创建一个节点时，它其实仅仅创建了一个对象来代表这个节点。创建以后，Kubernetes 将检查这个节点是否可用。例如，如果你尝试使用如下内容创建一个节点： +There are two main ways to have Nodes added to the {{< glossary_tooltip text="API server" term_id="kube-apiserver" >}}: +1. The kubelet on a node self-registers to the control plane +2. You, or another human user, manually add a Node object + +After you create a Node object, or the kubelet on a node self-registers, the +control plane checks whether the new Node object is valid. For example, if you +try to create a Node from the following JSON manifest: +--> +## 管理 {#management} + +向 {{< glossary_tooltip text="API 服务器" term_id="kube-apiserver" +>}}添加节点的方式主要有两种： + +1. 节点上的 `kubelet` 向控制面执行自注册； +2. 你，或者别的什么人，手动添加一个 Node 对象。 + +在你创建了 Node 对象或者节点上的 `kubelet` 执行了自注册操作之后， +控制面会检查新的 Node 对象是否合法。例如，如果你使用下面的 JSON +对象来创建 Node 对象： ```json { @@ -224,41 +81,336 @@ a node from the following content: ``` <!-- -Kubernetes creates a node object internally (the representation), and -validates the node by health checking based on the `metadata.name` field. If the node is valid -- that is, if all necessary -services are running -- it is eligible to run a pod. Otherwise, it is -ignored for any cluster activity until it becomes valid. +Kubernetes creates a Node object internally (the representation). Kubernetes checks +that a kubelet has registered to the API server that matches the `metadata.name` +field of the Node. If the node is healthy (if all necessary services are running), +it is eligible to run a Pod. Otherwise, that node is ignored for any cluster activity +until it becomes healthy. --> -Kubernetes 会在内部创一个 Node 对象（用以表示节点），并基于 `metadata.name` 字段执行健康检查，对节点进行验证。如果节点可用，意即所有必要服务都已运行，它就符合了运行一个 pod 的条件；否则它将被所有的集群动作忽略直到变为可用。 +Kubernetes 会在内部创建一个 Node 对象作为节点的表示。Kubernetes 检查 `kubelet` +向 API 服务器注册节点时使用的 `metadata.name` 字段是否匹配。 +如果节点是健康的（即所有必要的服务都在运行中），则该节点可以用来运行 Pod。 +否则，直到该节点变为健康之前，所有的集群活动都会忽略该节点。 -{{< note >}} <!-- -Kubernetes keeps the object for the invalid node and keeps checking to see whether it becomes valid. -You must explicitly delete the Node object to stop this process.--> Kubernetes 保留无效节点的对象，并继续检查它是否有效。必须显式删除 Node 对象以停止此过程。 +Kubernetes keeps the object for the invalid Node and continues checking to see whether +it becomes healthy. +You, or a {{< glossary_tooltip term_id="controller" text="controller">}}, must explicitly +delete the Node object to stop that health checking. +--> +{{< note >}} +Kubernetes 会一直保存着非法节点对应的对象，并持续检查该节点是否已经 +变得健康。 +你，或者某个{{< glossary_tooltip term_id="controller" text="控制器">}}必需显式地 +删除该 Node 对象以停止健康检查操作。 {{< /note >}} <!-- -Currently, there are three components that interact with the Kubernetes node -interface: node controller, kubelet, and kubectl. +The name of a Node object must be a valid +[DNS subdomain name](/docs/concepts/overview/working-with-objects/names#dns-subdomain-names). --> -当前，有 3 个组件同 Kubernetes 节点接口交互：节点控制器、kubelet 和 kubectl。 +Node 对象的名称必须是合法的 +[DNS 子域名](/zh/docs/concepts/overview/working-with-objects/names#dns-subdomain-names)。 + +<!-- +### Self-registration of Nodes + +When the kubelet flag `-register-node` is true (the default), the kubelet will attempt to +register itself with the API server. This is the preferred pattern, used by most distros. + +For self-registration, the kubelet is started with the following options: +--> +### 节点自注册 + +当 kubelet 标志 `--register-node` 为 true（默认）时，它会尝试向 API 服务注册自己。 +这是首选模式，被绝大多数发行版选用。 + +对于自注册模式，kubelet 使用下列参数启动： + +<!-- + - `--kubeconfig` - Path to credentials to authenticate itself to the API server. + - `--cloud-provider` - How to talk to a {{< glossary_tooltip text="cloud provider" term_id="cloud-provider" >}} to read metadata about itself. + - `--register-node` - Automatically register with the API server. + - `--register-with-taints` - Register the node with the given list of {{< glossary_tooltip text="taints" term_id="taint" >}} (comma separated `<key>=<value>:<effect>`). + + No-op if `register-node` is false. + - `--node-ip` - IP address of the node. + - `--node-labels` - {{< glossary_tooltip text="Labels" term_id="label" >}} to add when registering the node in the cluster (see label restrictions enforced by the [NodeRestriction admission plugin](/docs/reference/access-authn-authz/admission-controllers/#noderestriction)). + - `--node-status-update-frequency` - Specifies how often kubelet posts node status to master. +--> + - `--kubeconfig` - 用于向 API 服务器表明身份的凭据路径。 + - `--cloud-provider` - 与某{{< glossary_tooltip text="云驱动" term_id="cloud-provider" >}} + 进行通信以读取与自身相关的元数据的方式。 + - `--register-node` - 自动向 API 服务注册。 + - `--register-with-taints` - 使用所给的污点列表（逗号分隔的 `<key>=<value>:<effect>`）注册节点。 + 当 `register-node` 为 false 时无效。 + - `--node-ip` - 节点 IP 地址。 + - `--node-labels` - 在集群中注册节点时要添加的 + {{< glossary_tooltip text="标签" term_id="label" >}}。 + （参见 [NodeRestriction 准入控制插件](/zh/docs/reference/access-authn-authz/admission-controllers/#noderestriction)所实施的标签限制）。 + - `--node-status-update-frequency` - 指定 kubelet 向控制面发送状态的频率。 + +<!-- +When the [Node authorization mode](/docs/reference/access-authn-authz/node/) and +[NodeRestriction admission plugin](/docs/reference/access-authn-authz/admission-controllers/#noderestriction) are enabled, +kubelets are only authorized to create/modify their own Node resource. +--> +启用[节点授权模式](/zh/docs/reference/access-authn-authz/node/)和 +[NodeRestriction 准入插件](/zh/docs/reference/access-authn-authz/admission-controllers/#noderestriction) +时，仅授权 `kubelet` 创建或修改其自己的节点资源。 + +<!-- +### Manual Node administration + +You can create and modify Node objects using +{{< glossary_tooltip text="kubectl" term_id="kubectl" >}}. + +When you want to create Node objects manually, set the kubelet flag `--register-node=false`. + +You can modify Node objects regardless of the setting of `--register-node`. +For example, you can set labels on an existing Node, or mark it unschedulable. +--> +#### 手动节点管理 + +你可以使用 {{< glossary_tooltip text="kubectl" term_id="kubectl" >}} +来创建和修改 Node 对象。 + +如果你希望手动创建节点对象时，请设置 kubelet 标志 `--register-node=false`。 + +你可以修改 Node 对象（忽略 `--register-node` 设置）。 +例如，修改节点上的标签或标记其为不可调度。 + +<!-- +You can use labels on Nodes in conjunction with node selectors on Pods to control +scheduling. For example, you can to constrain a Pod to only be eligible to run on +a subset of the available nodes. + +Marking a node as unschedulable prevents the scheduler from placing new pods onto +that Node, but does not affect existing Pods on the Node. This is useful as a +preparatory step before a node reboot or other maintenance. + +To mark a Node unschedulable, run: +--> +你可以结合使用节点上的标签和 Pod 上的选择算符来控制调度。 +例如，你可以限制某 Pod 只能在符合要求的节点子集上运行。 + +如果标记节点为不可调度（unschedulable），将阻止新 Pod 调度到该节点之上，但不会 +影响任何已经在其上的 Pod。 +这是重启节点或者执行其他维护操作之前的一个有用的准备步骤。 + +要标记一个节点为不可调度，执行以下命令： + +```shell +kubectl cordon $NODENAME +``` + +<!-- +Pods that are part of a {{< glossary_tooltip term_id="daemonset" >}} tolerate +being run on an unschedulable Node. DaemonSets typically provide node-local services +that should run on the Node even if it is being drained of workload applications. +--> +{{< note >}} +被 {{< glossary_tooltip term_id="daemonset" text="DaemonSet" >}} 控制器创建的 Pod +能够容忍节点的不可调度属性。 +DaemonSet 通常提供节点本地的服务，即使节点上的负载应用已经被腾空，这些服务也仍需 +运行在节点之上。 +{{< /note >}} + +<!-- +## Node Status + +A node's status contains the following information: + +* [Addresses](#addresses) +* [Conditions](#condition) +* [Capacity and Allocatable](#capacity) +* [Info](#info) +--> +## 节点状态 {#node-status} + +一个节点的状态包含以下信息: + +* [地址](#addresses) +* [状况](#condition) +* [容量与可分配](#capacity) +* [信息](#info) + +<!-- +You can use `kubectl` to view a Node's status and other details: +--> +你可以使用 `kubectl` 来查看节点状态和其他细节信息： + +```shell +kubectl describe node <节点名称> +``` + +<!-- Each section is described in detail below. --> +下面对每个部分进行详细描述。 + +<!-- +### Addresses + +The usage of these fields varies depending on your cloud provider or bare metal configuration. +--> +### 地址 {#addresses} + +这些字段的用法取决于你的云服务商或者物理机配置。 + +<!-- +* HostName: The as reported by the node's kernel. Can be overridden via the kubelet `-hostname-override` parameter. +* ExternalIP: Typically the IP address of the node that is externally routable (available from outside the cluster). +* InternalIP: Typichostnameally the IP address of the node that is routable only within the cluster. +--> +* HostName：由节点的内核设置。可以通过 kubelet 的 `--hostname-override` 参数覆盖。 +* ExternalIP：通常是节点的可外部路由（从集群外可访问）的 IP 地址。 +* InternalIP：通常是节点的仅可在集群内部路由的 IP 地址。 + +<!-- +### Conditions {#condition} + +The `conditions` field describes the status of all `Running` nodes. Examples of conditions include: +--> +### 状况 {#condition} + +`conditions` 字段描述了所有 `Running` 节点的状态。状况的示例包括： + +<!-- +{{< table caption = "Node conditions, and a description of when each condition applies." >}} +| Node Condition | Description | +|----------------|-------------| +| `Ready` | `True` if the node is healthy and ready to accept pods, `False` if the node is not healthy and is not accepting pods, and `Unknown` if the node controller has not heard from the node in the last `node-monitor-grace-period` (default is 40 seconds) | +| `DiskPressure` | `True` if there is insufficient free space on the node for adding new pods, otherwise `False` | +| `MemoryPressure` | `True` if pressure exists on the node memory - that is, if the node memory is low; otherwise `False` | +| `PIDPressure` | `True` if pressure exists on the processes - that is, if there are too many processes on the node; otherwise `False` | +| `NetworkUnavailable` | `True` if the network for the node is not correctly configured, otherwise `False` | +--> +{{< table caption = "节点状况及每种状况适用场景的描述" >}} +| 节点状况 | 描述 | +|----------------|-------------| +| `Ready` | 如节点是健康的并已经准备好接收 Pod 则为 `True`；`False` 表示节点不健康而且不能接收 Pod；`Unknown` 表示节点控制器在最近 `node-monitor-grace-period` 期间（默认 40 秒）没有收到节点的消息 | +| `DiskPressure` | `True` 表示节点的空闲空间不足以用于添加新 Pod, 否则为 `False` | +| `MemoryPressure` | `True` 表示节点存在内存压力，即节点内存可用量低，否则为 `False` | +| `PIDPressure` | `True` 表示节点存在进程压力，即节点上进程过多；否则为 `False` | +| `NetworkUnavailable` | `True` 表示节点网络配置不正确；否则为 `False` | + +<!-- +If you use command-line tools to print details of a cordoned Node, the Condition includes +`SchedulingDisabled`. `SchedulingDisabled` is not a Condition in the Kubernetes API; instead, +cordoned nodes are marked Unschedulable in their spec. +--> +{{< note >}} +如果使用命令行工具来打印已保护（Cordoned）节点的细节，其中的 Condition 字段可能 +包括 `SchedulingDisabled`。`SchedulingDisabled` 不是 Kubernetes API 中定义的 +Condition，被保护起来的节点在其规约中被标记为不可调度（Unschedulable）。 +{{< /note >}} + +<!-- +The node condition is represented as a JSON object. For example, the following response describes a healthy node. +--> +节点条件使用 JSON 对象表示。例如，下面的响应描述了一个健康的节点。 + +```json +"conditions": [ + { + "type": "Ready", + "status": "True", + "reason": "KubeletReady", + "message": "kubelet is posting ready status", + "lastHeartbeatTime": "2019-06-05T18:38:35Z", + "lastTransitionTime": "2019-06-05T11:41:27Z" + } +] +``` + +<!-- +If the Status of the Ready condition remains `Unknown` or `False` for longer than the `pod-eviction-timeout`, an argument is passed to the {{< glossary_tooltip text="kube-controller-manager" term_id="kube-controller-manager" >}}), all the Pods on the node are scheduled for deletion by the Node Controller. The default eviction timeout duration is **five minutes**. In some cases when the node is unreachable, the apiserver is unable to communicate with the kubelet on the node. The decision to delete the pods cannot be communicated to the kubelet until communication with the API server is re-established. In the meantime, the pods that are scheduled for deletion may continue to run on the partitioned node. +--> +如果 Ready 条件处于 `Unknown` 或者 `False` 状态的时间超过了 `pod-eviction-timeout` 值， +（一个传递给 {{< glossary_tooltip text="kube-controller-manager" term_id="kube-controller-manager" >}} 的参数）， +节点上的所有 Pod 都会被节点控制器计划删除。默认的逐出超时时长为 **5 分钟**。 +某些情况下，当节点不可达时，API 服务器不能和其上的 kubelet 通信。 +删除 Pod 的决定不能传达给 kubelet，直到它重新建立和 API 服务器的连接为止。 +与此同时，被计划删除的 Pod 可能会继续在游离的节点上运行。 + +<!-- +The node controller does not force delete pods until it is confirmed that they have stopped +running in the cluster. You can see the pods that might be running on an unreachable node as +being in the `Terminating` or `Unknown` state. In cases where Kubernetes cannot deduce from the +underlying infrastructure if a node has permanently left a cluster, the cluster administrator +may need to delete the node object by hand. Deleting the node object from Kubernetes causes +all the Pod objects running on the node to be deleted from the API server, and frees up their +names. +--> +节点控制器在确认 Pod 在集群中已经停止运行前，不会强制删除它们。 +你可以看到这些可能在无法访问的节点上运行的 Pod 处于 `Terminating` 或者 `Unknown` 状态。 +如果 kubernetes 不能基于下层基础设施推断出某节点是否已经永久离开了集群， +集群管理员可能需要手动删除该节点对象。 +从 Kubernetes 删除节点对象将导致 API 服务器删除节点上所有运行的 Pod 对象并释放它们的名字。 + +<!-- +The node lifecycle controller automatically creates +[taints](/docs/concepts/scheduling-eviction/taint-and-toleration/) that represent conditions. +The scheduler takes the Node's taints into consideration when assigning a Pod to a Node. +Pods can also have tolerations which let them tolerate a Node's taints. +--> +节点生命周期控制器会自动创建代表状况的 +[污点](/zh/docs/concepts/scheduling-eviction/taint-and-toleration/)。 +当调度器将 Pod 指派给某节点时，会考虑节点上的污点。 +Pod 则可以通过容忍度（Toleration）表达所能容忍的污点。 + +<!-- +### Capacity and Allocatable {#capacity} + +Describes the resources available on the node: CPU, memory and the maximum +number of pods that can be scheduled onto the node. +--> +### 容量与可分配 {#capacity} + +描述节点上的可用资源：CPU、内存和可以调度到节点上的 Pod 的个数上限。 + +<!-- +The fields in the capacity block indicate the total amount of resources that a +Node has. The allocatable block indicates the amount of resources on a +Node that is available to be consumed by normal Pods. +--> +`capacity` 块中的字段标示节点拥有的资源总量。 +`allocatable` 块指示节点上可供普通 Pod 消耗的资源量。 + +<!-- +You may read more about capacity and allocatable resources while learning how +to [reserve compute resources](/docs/tasks/administer-cluster/reserve-compute-resources/#node-allocatable) on a Node. +--> +可以在学习如何在节点上[预留计算资源](/zh/docs/tasks/administer-cluster/reserve-compute-resources/#node-allocatable) +的时了解有关容量和可分配资源的更多信息。 + +<!-- +### Info + +Describes general information about the node, such as kernel version, Kubernetes version (kubelet and kube-proxy version), Docker version (if used), and OS name. +This information is gathered by Kubelet from the node. +--> + +### 信息 {#info} + +关于节点的一般性信息，例如内核版本、Kubernetes 版本（`kubelet` 和 `kube-proxy` 版本）、 +Docker 版本（如果使用了）和操作系统名称。这些信息由 `kubelet` 从节点上搜集而来。 <!-- ### Node Controller ---> -### 节点控制器 -<!-- -The node controller is a Kubernetes master component which manages various -aspects of nodes. ---> -节点控制器是一个 Kubernetes master 组件，管理节点的方方面面。 +The node {{< glossary_tooltip text="controller" term_id="controller" >}} is a +Kubernetes control plane component that manages various aspects of nodes. -<!-- The node controller has multiple roles in a node's life. The first is assigning a CIDR block to the node when it is registered (if CIDR assignment is turned on). --> -节点控制器在节点的生命周期中扮演了多个角色。第一个是当节点注册时为它分配一个 CIDR block（如果打开了 CIDR 分配）。 +### 节点控制器 {#node-controller} + +节点{{< glossary_tooltip text="控制器" term_id="controller" >}}是 +Kubernetes 控制面组件，管理节点的方方面面。 + +节点控制器在节点的生命周期中扮演多个角色。 +第一个是当节点注册时为它分配一个 CIDR 区段（如果启用了 CIDR 分配）。 <!-- The second is keeping the node controller's internal list of nodes up to date with @@ -267,7 +419,9 @@ environment, whenever a node is unhealthy, the node controller asks the cloud provider if the VM for that node is still available. If not, the node controller deletes the node from its list of nodes. --> -第二个是使用云服务商提供了可用节点列表保持节点控制器内部的节点列表更新。如果在云环境下运行，任何时候当一个节点不健康时节点控制器将询问云服务节点的虚拟机是否可用。如果不可用，节点控制器会将这个节点从它的节点列表删除。 +第二个是保持节点控制器内的节点列表与云服务商所提供的可用机器列表同步。 +如果在云环境下运行，只要某节点不健康，节点控制器就会询问云服务是否节点的虚拟机仍可用。 +如果不可用，节点控制器会将该节点从它的节点列表删除。 <!-- The third is monitoring the nodes' health. The node controller is @@ -277,16 +431,18 @@ receiving heartbeats for some reason, e.g. due to the node being down), and then all the pods from the node (using graceful termination) if the node continues to be unreachable. (The default timeouts are 40s to start reporting ConditionUnknown and 5m after that to start evicting pods.) The node controller -checks the state of each node every `--node-monitor-period` seconds. +checks the state of each node every `-node-monitor-period` seconds. --> -第三个是监控节点的健康情况。节点控制器负责在节点不能访问时（也即是节点控制器因为某些原因没有收到心跳，例如节点宕机）将它的 NodeStatus 的 NodeReady 状态更新为 ConditionUnknown。后续如果节点持续不可访问，节点控制器将删除节点上的所有 pods（使用优雅终止）。（默认情况下 40s 开始报告 ConditionUnknown，在那之后 5m 开始删除 pods。）节点控制器每隔 `--node-monitor-period` 秒检查每个节点的状态。 +第三个是监控节点的健康情况。节点控制器负责在节点不可达 +（即，节点控制器因为某些原因没有收到心跳，例如节点宕机）时， +将节点状态的 `NodeReady` 状况更新为 "`Unknown`"。 +如果节点接下来持续处于不可达状态，节点控制器将逐出节点上的所有 Pod（使用体面终止）。 +默认情况下 40 秒后开始报告 "`Unknown`"，在那之后 5 分钟开始逐出 Pod。 +节点控制器每隔 `--node-monitor-period` 秒检查每个节点的状态。 <!-- #### Heartbeats ---> -#### 心跳机制 -<!-- Heartbeats, sent by Kubernetes nodes, help determine the availability of a node. There are two forms of heartbeats: updates of `NodeStatus` and the [Lease object](/docs/reference/generated/kubernetes-api/{{< latest-version >}}/#lease-v1-coordination-k8s-io). @@ -295,16 +451,20 @@ Each Node has an associated Lease object in the `kube-node-lease` Lease is a lightweight resource, which improves the performance of the node heartbeats as the cluster scales. --> -Kubernetes 节点发送的心跳有助于确定节点的可用性。 -心跳有两种形式：`NodeStatus` 和 [`Lease` 对象](/docs/reference/generated/kubernetes-api/{{< latest-version >}}/#lease-v1-coordination-k8s-io)。 -每个节点在 `kube-node-lease`{{< glossary_tooltip term_id="namespace" text="命名空间">}} 中都有一个关联的 `Lease` 对象。 -`Lease` 是一种轻量级的资源，可在集群扩展时提高节点心跳机制的性能。 +#### 心跳机制 {#heartbeats} + +Kubernetes 节点发送的心跳（Heartbeats）有助于确定节点的可用性。 +心跳有两种形式：`NodeStatus` 和 [`Lease` 对象] +(/docs/reference/generated/kubernetes-api/{{< latest-version >}}/#lease-v1-coordination-k8s-io)。 +每个节点在 `kube-node-lease`{{< glossary_tooltip term_id="namespace" text="名字空间">}} +中都有一个与之关联的 `Lease` 对象。 +`Lease` 是一种轻量级的资源，可在集群规模扩大时提高节点心跳机制的性能。 <!-- The kubelet is responsible for creating and updating the `NodeStatus` and a Lease object. --> -kubelet 负责创建和更新 `NodeStatus` 和 `Lease` 对象。 +`kubelet` 负责创建和更新 `NodeStatus` 和 `Lease` 对象。 <!-- - The kubelet updates the `NodeStatus` either when there is change in status, @@ -313,227 +473,165 @@ kubelet 负责创建和更新 `NodeStatus` 和 `Lease` 对象。 timeout for unreachable nodes). - The kubelet creates and then updates its Lease object every 10 seconds (the default update interval). Lease updates occur independently from the - `NodeStatus` updates. + `NodeStatus` updates. If the Lease update fails, the kubelet retries with + exponential backoff starting at 200 milliseconds and capped at 7 seconds. + --> -- 当状态发生变化时，或者在配置的时间间隔内没有更新时，kubelet 会更新 `NodeStatus`。 -`NodeStatus` 更新的默认间隔为 5 分钟（比无法访问的节点的 40 秒默认超时时间长很多）。 -- kubelet 会每 10 秒（默认更新间隔时间）创建并更新其 `Lease` 对象。`Lease` 更新独立于 `NodeStatus` 更新而发生。 +- 当状态发生变化时，或者在配置的时间间隔内没有更新事件时，kubelet 会更新 `NodeStatus`。 + `NodeStatus` 更新的默认间隔为 5 分钟（比不可达节点的 40 秒默认超时时间长很多）。 +- `kubelet` 会每 10 秒（默认更新间隔时间）创建并更新其 `Lease` 对象。 + `Lease` 更新独立于 `NodeStatus` 更新而发生。 + 如果 `Lease` 的更新操作失败，`kubelet` 会采用指数回退机制，从 200 毫秒开始 + 重试，最长重试间隔为 7 秒钟。 <!-- #### Reliability ---> -#### 可靠性 -<!-- -In Kubernetes 1.4, we updated the logic of the node controller to better handle -cases when a large number of nodes have problems with reaching the master -(e.g. because the master has networking problem). Starting with 1.4, the node -controller looks at the state of all nodes in the cluster when making a -decision about pod eviction. ---> -在 Kubernetes 1.4 中我们更新了节点控制器逻辑以更好地处理大批量节点访问 master 出问题的情况（例如 master 的网络出了问题）。从 1.4 开始，节点控制器在决定删除 pod 之前会检查集群中所有节点的状态。 - -<!-- In most cases, node controller limits the eviction rate to -`--node-eviction-rate` (default 0.1) per second, meaning it won't evict pods +`-node-eviction-rate` (default 0.1) per second, meaning it won't evict pods from more than 1 node per 10 seconds. --> -大部分情况下，节点控制器把驱逐频率限制在每秒 `--node-eviction-rate` 个（默认为 0.1）。这表示它每 10 秒钟内至多从一个节点驱逐 Pods。 +#### 可靠性 {#reliability} + +大部分情况下，节点控制器把逐出速率限制在每秒 `--node-eviction-rate` 个（默认为 0.1）。 +这表示它每 10 秒钟内至多从一个节点驱逐 Pod。 <!-- The node eviction behavior changes when a node in a given availability zone becomes unhealthy. The node controller checks what percentage of nodes in the zone are unhealthy (NodeReady condition is ConditionUnknown or ConditionFalse) at the same time. If the fraction of unhealthy nodes is at least -`--unhealthy-zone-threshold` (default 0.55) then the eviction rate is reduced: +`-unhealthy-zone-threshold` (default 0.55) then the eviction rate is reduced: if the cluster is small (i.e. has less than or equal to -`--large-cluster-size-threshold` nodes - default 50) then evictions are +`-large-cluster-size-threshold` nodes - default 50) then evictions are stopped, otherwise the eviction rate is reduced to -`--secondary-node-eviction-rate` (default 0.01) per second. The reason these +`-secondary-node-eviction-rate` (default 0.01) per second. The reason these policies are implemented per availability zone is because one availability zone might become partitioned from the master while the others remain connected. If your cluster does not span multiple cloud provider availability zones, then there is only one availability zone (the whole cluster). --> -当一个可用区域中的节点变为不健康时，它的驱逐行为将发生改变。节点控制器会同时检查可用区域中不健康（NodeReady 状态为 ConditionUnknown 或 ConditionFalse）的节点的百分比。如果不健康节点的部分超过 `--unhealthy-zone-threshold` （默认为 0.55），驱逐速率将会减小：如果集群较小（意即小于等于 `--large-cluster-size-threshold` 个 节点 - 默认为 50），驱逐操作将会停止，否则驱逐速率将降为每秒 `--secondary-node-eviction-rate` 个（默认为 0.01）。在单个可用区域实施这些策略的原因是当一个可用区域可能从 master 分区时其它的仍然保持连接。如果你的集群没有跨越云服务商的多个可用区域，那就只有一个可用区域整个集群）。 +当一个可用区域（Availability Zone）中的节点变为不健康时，节点的驱逐行为将发生改变。 +节点控制器会同时检查可用区域中不健康（NodeReady 状况为 Unknown 或 False） +的节点的百分比。如果不健康节点的比例超过 `--unhealthy-zone-threshold` （默认为 0.55）， +驱逐速率将会降低：如果集群较小（意即小于等于 `--large-cluster-size-threshold` +个节点 - 默认为 50），驱逐操作将会停止，否则驱逐速率将降为每秒 +`--secondary-node-eviction-rate` 个（默认为 0.01）。 +在单个可用区域实施这些策略的原因是当一个可用区域可能从控制面脱离时其它可用区域 +可能仍然保持连接。 +如果你的集群没有跨越云服务商的多个可用区域，那（整个集群）就只有一个可用区域。 <!-- A key reason for spreading your nodes across availability zones is so that the workload can be shifted to healthy zones when one entire zone goes down. Therefore, if all nodes in a zone are unhealthy then node controller evicts at -the normal rate `--node-eviction-rate`. The corner case is when all zones are +the normal rate `-node-eviction-rate`. The corner case is when all zones are completely unhealthy (i.e. there are no healthy nodes in the cluster). In such case, the node controller assumes that there's some problem with master connectivity and stops all evictions until some connectivity is restored. --> -在多个可用区域分布你的节点的一个关键原因是当整个可用区域故障时，工作负载可以转移到健康的可用区域。因此，如果一个可用区域中的所有节点都不健康时，节点控制器会以正常的速率 `--node-eviction-rate` 进行驱逐操作。在所有的可用区域都不健康（也即集群中没有健康节点）的极端情况下，节点控制器将假设 master 的连接出了某些问题，它将停止所有驱逐动作直到一些连接恢复。 +跨多个可用区域部署你的节点的一个关键原因是当某个可用区域整体出现故障时， +工作负载可以转移到健康的可用区域。 +因此，如果一个可用区域中的所有节点都不健康时，节点控制器会以正常的速率 +`--node-eviction-rate` 进行驱逐操作。 +在所有的可用区域都不健康（也即集群中没有健康节点）的极端情况下， +节点控制器将假设控制面节点的连接出了某些问题， +它将停止所有驱逐动作直到一些连接恢复。 <!-- -Starting in Kubernetes 1.6, the NodeController is also responsible for evicting -pods that are running on nodes with `NoExecute` taints, when the pods do not tolerate -the taints. Additionally, as an alpha feature that is disabled by default, the -NodeController is responsible for adding taints corresponding to node problems like -node unreachable or not ready. See [this documentation](/docs/concepts/configuration/taint-and-toleration/) -for details about `NoExecute` taints and the alpha feature. +The Node Controller is also responsible for evicting pods running on nodes with +`NoExecute` taints, unless the pods do not tolerate the taints. +The Node Controller also adds {{< glossary_tooltip text="taints" term_id="taint" >}} +corresponding to node problems like node unreachable or not ready. This means +that the scheduler won't place Pods onto unhealthy nodes. --> -从 Kubernetes 1.6 开始，NodeController 还负责驱逐运行在拥有 `NoExecute` 污点的节点上的 pods，如果这些 pods 没有容忍这些污点。此外，作为一个默认禁用的 alpha 特性，NodeController 还负责根据节点故障（例如节点不可访问或没有 ready）添加污点。请查看[这个文档](/docs/concepts/configuration/assign-pod-node/#taints-and-tolerations-beta-feature)了解关于 `NoExecute` 污点和这个 alpha 特性。 - +节点控制器还负责驱逐运行在拥有 `NoExecute` 污点的节点上的 Pod， +除非这些 Pod 能够容忍此污点。 +节点控制器还负责根据节点故障（例如节点不可访问或没有就绪）为其添加 +{{< glossary_tooltip text="污点" term_id="taint" >}}。 +这意味着调度器不会将 Pod 调度到不健康的节点上。 <!-- -Starting in version 1.8, the node controller can be made responsible for creating taints that represent -Node conditions. This is an alpha feature of version 1.8. +`kubectl cordon` marks a node as 'unschedulable', which has the side effect of the service +controller removing the node from any LoadBalancer node target lists it was previously +eligible for, effectively removing incoming load balancer traffic from the cordoned node(s). --> -从版本 1.8 开始，可以使节点控制器负责创建代表节点条件的污点。这是版本 1.8 的 Alpha 功能。 - -<!-- -### Self-Registration of Nodes ---> -### 节点自注册 - -<!-- -When the kubelet flag `--register-node` is true (the default), the kubelet will attempt to -register itself with the API server. This is the preferred pattern, used by most distros. ---> -当 kubelet 标志 `--register-node` 为 true （默认）时，它会尝试向 API 服务注册自己。这是首选模式，被绝大多数发行版选用。 - -<!-- -For self-registration, the kubelet is started with the following options: ---> - 对于自注册模式，kubelet 使用下列参数启动： - -<!-- - - `--kubeconfig` - Path to credentials to authenticate itself to the apiserver. - - `--cloud-provider` - How to talk to a cloud provider to read metadata about itself. - - `--register-node` - Automatically register with the API server. - - `--register-with-taints` - Register the node with the given list of taints (comma separated `<key>=<value>:<effect>`). No-op if `register-node` is false. - - `--node-ip` - IP address of the node. - - `--node-labels` - Labels to add when registering the node in the cluster (see label restrictions enforced by the [NodeRestriction admission plugin](/docs/reference/access-authn-authz/admission-controllers/#noderestriction) in 1.13+). - - `--node-status-update-frequency` - Specifies how often kubelet posts node status to master. ---> - - `--kubeconfig` - 用于向 apiserver 验证自己的凭据路径。 - - `--cloud-provider` - 如何从云服务商读取关于自己的元数据。 - - `--register-node` - 自动向 API 服务注册。 - - `--register-with-taints` - 使用 taints 列表（逗号分隔的 `<key>=<value>:<effect>`）注册节点。当 `register-node` 为 false 时无效。 - - `--node-ip` - 节点 IP 地址。 - - `--node-labels` - 在集群中注册节点时要添加的标签（请参阅 [NodeRestriction 准入插件](/docs/reference/access-authn-authz/admission-controllers/#noderestriction) 在 1.13+ 中实施的标签限制）。 - - `--node-status-update-frequency` - 指定 kubelet 向 master 发送状态的频率。 - -<!-- -When the [Node authorization mode](/docs/reference/access-authn-authz/node/) and -[NodeRestriction admission plugin](/docs/reference/access-authn-authz/admission-controllers/#noderestriction) are enabled, -kubelets are only authorized to create/modify their own Node resource. ---> -启用[节点授权模式](/docs/reference/access-authn-authz/node/) 和 [NodeRestriction 准入插件](/docs/reference/access-authn-authz/admission-controllers/#noderestriction)时，仅授权小组件创建或修改其自己的节点资源。 - -<!-- -#### Manual Node Administration ---> -#### 手动节点管理 - -<!-- -A cluster administrator can create and modify node objects. ---> -集群管理员可以创建及修改节点对象。 - -<!-- -If the administrator wishes to create node objects manually, set the kubelet flag -`--register-node=false`. ---> -如果管理员希望手动创建节点对象，请设置 kubelet 标记 `--register-node=false`。 - -<!-- -The administrator can modify node resources (regardless of the setting of `--register-node`). -Modifications include setting labels on the node and marking it unschedulable. ---> -管理员可以修改节点资源（忽略 `--register-node` 设置）。修改包括在节点上设置 labels 及标记它为不可调度。 - -<!-- -Labels on nodes can be used in conjunction with node selectors on pods to control scheduling, -e.g. to constrain a pod to only be eligible to run on a subset of the nodes. ---> -节点上的 labels 可以和 pods 的节点 selectors 一起使用来控制调度，例如限制一个 pod 只能在一个符合要求的节点子集上运行。 - -<!-- -Marking a node as unschedulable prevents new pods from being scheduled to that -node, but does not affect any existing pods on the node. This is useful as a -preparatory step before a node reboot, etc. For example, to mark a node -unschedulable, run this command: ---> -标记一个节点为不可调度的将防止新建 pods 调度到那个节点之上，但不会影响任何已经在它之上的 pods。这是重启节点等操作之前的一个有用的准备步骤。例如，标记一个节点为不可调度的，执行以下命令： - - -```shell -kubectl cordon $NODENAME -``` - -{{< note >}} -<!-- -Pods created by a DaemonSet controller bypass the Kubernetes scheduler -and do not respect the unschedulable attribute on a node. This assumes that daemons belong on -the machine even if it is being drained of applications while it prepares for a reboot ---> -请注意，被 daemonSet 控制器创建的 pods 将忽略 Kubernetes 调度器，且不会遵照节点上不可调度的属性。这个假设基于守护程序属于节点机器，即使在准备重启而隔离应用的时候。 -{{< /note >}} +{{< caution>}} +`kubectl cordon` 会将节点标记为“不可调度（Unschedulable）”。 +此操作的副作用是，服务控制器会将该节点从负载均衡器中之前的目标节点列表中移除， +从而使得来自负载均衡器的网络请求不会到达被保护起来的节点。 +{{< /caution>}} <!-- ### Node capacity + +Node objects track information about the Node's resource capacity (for example: the amount +of memory available, and the number of CPUs). +Nodes that [self register](#self-registration-of-nodes) report their capacity during +registration. If you [manually](#manual-node-administration) add a Node, then +you need to set the node's capacity information when you add it. --> -### 节点容量 +### 节点容量 {#node-capacity} + +Node 对象会跟踪节点上资源的容量（例如可用内存和 CPU 数量）。 +通过[自注册](#self-registration-of-nodes)机制生成的 Node 对象会在注册期间报告自身容量。 +如果你[手动](#manual-node-administration)添加了 Node，你就需要在添加节点时 +手动设置节点容量。 <!-- -The capacity of the node (number of cpus and amount of memory) is part of the node object. -Normally, nodes register themselves and report their capacity when creating the node object. If -you are doing [manual node administration](#manual-node-administration), then you need to set node -capacity when adding a node. +The Kubernetes {{< glossary_tooltip text="scheduler" term_id="kube-scheduler" >}} ensures that +there are enough resources for all the pods on a node. The scheduler checks that the sum +of the requests of containers on the node is no greater than the node capacity. +The sum of requests includes all containers started by the kubelet, but excludes any +containers started directly by the container runtime, and also excludes any +process running outside of the kubelet's control. --> -节点的容量（cpu 数量和内存容量）是节点对象的一部分。通常情况下，在创建节点对象时，它们会注册自己并报告自己的容量。如果你正在执行[手动节点管理](#manual-node-administration)，那么你需要在添加节点时手动设置节点容量。 - -<!-- -The Kubernetes scheduler ensures that there are enough resources for all the pods on a node. It -checks that the sum of the requests of containers on the node is no greater than the node capacity. It -includes all containers started by the kubelet, but not containers started directly by the [container runtime](/docs/concepts/overview/components/#node-components) nor any process running outside of the containers. ---> -Kubernetes 调度器保证一个节点上有足够的资源供其上的所有 pods 使用。它会检查节点上所有容器要求的总和不会超过节点的容量。这包括由 kubelet 启动的所有容器，但不包括由 [container runtime](/docs/concepts/overview/components/#node-components) 直接启动的容器，也不包括在容器外部运行的任何进程。 +Kubernetes {{< glossary_tooltip text="调度器" term_id="kube-scheduler" >}}保证节点上 +有足够的资源供其上的所有 Pod 使用。它会检查节点上所有容器的请求的总和不会超过节点的容量。 +总的请求包括由 kubelet 启动的所有容器，但不包括由容器运行时直接启动的容器， +也不包括不受 `kubelet` 控制的其他进程。 <!-- If you want to explicitly reserve resources for non-Pod processes, follow this tutorial to [reserve resources for system daemons](/docs/tasks/administer-cluster/reserve-compute-resources/#system-reserved). --> -如果要为非 Pod 进程显式保留资源。请按照本教程[为系统守护程序保留资源](/docs/tasks/administer-cluster/reserve-compute-resources/#system-reserved)。 +{{< note >}} +如果要为非 Pod 进程显式保留资源。请参考 +[为系统守护进程预留资源](/zh/docs/tasks/administer-cluster/reserve-compute-resources/#system-reserved)。 +{{< /note >}} <!-- ## Node topology --> -## 节点拓扑 +## 节点拓扑 {#node-topology} -{{< feature-state state="alpha" >}} +{{< feature-state state="alpha" for_k8s_version="v1.16" >}} <!-- If you have enabled the `TopologyManager` [feature gate](/docs/reference/command-line-tools-reference/feature-gates/), then the kubelet can use topology hints when making resource assignment decisions. +See [Control Topology Management Policies on a Node](/docs/tasks/administer-cluster/topology-manager/) +for more information. --> -如果启用了 `TopologyManager` [功能开关](/docs/reference/command-line-tools-reference/feature-gates/)，则 kubelet 可以在做出资源分配决策时使用拓扑提示。 - -<!-- -## API Object ---> -## API 对象 - -<!-- -Node is a top-level resource in the Kubernetes REST API. More details about the -API object can be found at: -[Node API object](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#node-v1-core). ---> -节点是 Kubernetes REST API 的顶级资源。更多关于 API 对象的细节可以在这里找到：[节点 API 对象](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#node-v1-core)。 - +如果启用了 `TopologyManager` [特性门控](/zh/docs/reference/command-line-tools-reference/feature-gates/)， +`kubelet` 可以在作出资源分配决策时使用拓扑提示。 +参考[控制节点上拓扑管理策略](/zh/docs/tasks/administer-cluster/topology-manager/) +了解详细信息。 ## {{% heading "whatsnext" %}} <!-- -* Read about [node components](https://kubernetes.io/docs/concepts/overview/components/#node-components) -* Read about node-level topology: [Control Topology Management Policies on a node](/docs/tasks/administer-cluster/topology-manager/) +* Learn about the [components](/docs/concepts/overview/components/#node-components) that make up a node. +* Read the [API definition for Node](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#node-v1-core). +* Read the [Node](https://git.k8s.io/community/contributors/design-proposals/architecture/architecture.md#the-kubernetes-node) + section of the architecture design document. +* Read about [taints and tolerations](/docs/concepts/scheduling-eviction/taint-and-toleration/). +* Read about [cluster autoscaling](/docs/tasks/administer-cluster/cluster-management/#cluster-autoscaling). --> -* 了解有关[节点组件](https://kubernetes.io/docs/concepts/overview/components/#node-components)的信息。 -* 阅读有关节点级拓扑的信息：[控制节点上的拓扑管理策略](/docs/tasks/administer-cluster/topology-manager/)。 +* 了解有关节点[组件](/zh/docs/concepts/overview/components/#node-components) +* 阅读[节点的 API 定义](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#node-v1-core) +* 阅读架构设计文档中有关[节点](https://git.k8s.io/community/contributors/design-proposals/architecture/architecture.md#the-kubernetes-node)的章节 +* 了解[污点和容忍度](/zh/docs/concepts/scheduling-eviction/taint-and-toleration/) +* 了解[集群自动扩缩](/zh/docs/tasks/administer-cluster/cluster-management/#cluster-autoscaling) diff --git a/content/zh/docs/concepts/cluster-administration/_index.md b/content/zh/docs/concepts/cluster-administration/_index.md index f901bc55f1..f0525696c3 100644 --- a/content/zh/docs/concepts/cluster-administration/_index.md +++ b/content/zh/docs/concepts/cluster-administration/_index.md @@ -1,4 +1,136 @@ --- -title: "计算、存储和网络扩展" -weight: 30 +title: 集群管理 +weight: 100 +content_type: concept +description: > + 关于创建和管理 Kubernetes 集群的底层细节。 +no_list: true --- + +<!-- +title: Cluster Administration +reviewers: +- davidopp +- lavalamp +weight: 100 +content_type: concept +description: > + Lower-level detail relevant to creating or administering a Kubernetes cluster. +no_list: true +--> + +<!-- overview --> +<!-- +The cluster administration overview is for anyone creating or administering a Kubernetes cluster. +It assumes some familiarity with core Kubernetes [concepts](/docs/concepts/). +--> +集群管理概述面向任何创建和管理 Kubernetes 集群的读者人群。 +我们假设你对一些核心的 Kubernetes [概念](/zh/docs/concepts/)大概了解。 + + +<!-- body --> +<!-- +## Planning a cluster + +See the guides in [Setup](/docs/setup/) for examples of how to plan, set up, and configure Kubernetes clusters. The solutions listed in this article are called *distros*. + +Not all distros are actively maintained. Choose distros which have been tested with a recent version of Kubernetes. + +Before choosing a guide, here are some considerations: +--> +## 规划集群 + +查阅[安装](/zh/docs/setup/)中的指导，获取如何规划、建立以及配置 Kubernetes 集群的示例。本文所列的文章称为*发行版* 。 + +{{< note >}} +并非所有发行版都是被积极维护的。 +请选择使用最近 Kubernetes 版本测试过的发行版。 +{{< /note >}} + +在选择一个指南前，有一些因素需要考虑： + +<!-- +- Do you just want to try out Kubernetes on your computer, or do you want to build a high-availability, multi-node cluster? Choose distros best suited for your needs. +- Will you be using **a hosted Kubernetes cluster**, such as [Google Kubernetes Engine](https://cloud.google.com/kubernetes-engine/), or **hosting your own cluster**? +- Will your cluster be **on-premises**, or **in the cloud (IaaS)**? Kubernetes does not directly support hybrid clusters. Instead, you can set up multiple clusters. +- **If you are configuring Kubernetes on-premises**, consider which [networking model](/docs/concepts/cluster-administration/networking/) fits best. +- Will you be running Kubernetes on **"bare metal" hardware** or on **virtual machines (VMs)**? +- Do you **just want to run a cluster**, or do you expect to do **active development of Kubernetes project code**? If the + latter, choose an actively-developed distro. Some distros only use binary releases, but + offer a greater variety of choices. +- Familiarize yourself with the [components](/docs/concepts/overview/components/) needed to run a cluster. +--> +- 你是打算在你的计算机上尝试 Kubernetes，还是要构建一个高可用的多节点集群？请选择最适合你需求的发行版。 +- 您正在使用类似 [Google Kubernetes Engine](https://cloud.google.com/kubernetes-engine/) 这样的**被托管的 Kubernetes 集群**, 还是**管理您自己的集群**？ +- 你的集群是在**本地**还是**云（IaaS）**上？Kubernetes 不能直接支持混合集群。作为代替，你可以建立多个集群。 +- **如果你在本地配置 Kubernetes**，需要考虑哪种[网络模型](/zh/docs/concepts/cluster-administration/networking/)最适合。 +- 你的 Kubernetes 在**裸金属硬件**上还是**虚拟机（VMs）**上运行？ +- 你**只想运行一个集群**，还是打算**参与开发 Kubernetes 项目代码**？如果是后者，请选择一个处于开发状态的发行版。某些发行版只提供二进制发布版，但提供更多的选择。 +- 让你自己熟悉运行一个集群所需的[组件](/zh/docs/concepts/overview/components/)。 + +<!-- +## Managing a cluster + +* [Managing a cluster](/docs/tasks/administer-cluster/cluster-management/) describes several topics related to the lifecycle of a cluster: creating a new cluster, upgrading your cluster’s master and worker nodes, performing node maintenance (e.g. kernel upgrades), and upgrading the Kubernetes API version of a running cluster. + +* Learn how to [manage nodes](/docs/concepts/nodes/node/). + +* Learn how to set up and manage the [resource quota](/docs/concepts/policy/resource-quotas/) for shared clusters. +--> +## 管理集群 + +* [管理集群](/zh/docs/tasks/administer-cluster/cluster-management/)叙述了和集群生命周期相关的几个主题： +创建新集群、升级集群的控制节点和工作节点、执行节点维护（例如内核升级）以及升级运行中的集群的 Kubernetes API 版本。 + +* 学习如何[管理节点](/zh/docs/concepts/architecture/nodes/)。 + +* 学习如何设定和管理集群共享的[资源配额](/zh/docs/concepts/policy/resource-quotas/) 。 + +<!-- +## Securing a cluster + +* [Certificates](/docs/concepts/cluster-administration/certificates/) describes the steps to generate certificates using different tool chains. +* [Kubernetes Container Environment](/docs/concepts/containers/container-environment/) describes the environment for Kubelet managed containers on a Kubernetes node. +* [Controlling Access to the Kubernetes API](/docs/reference/access-authn-authz/controlling-access/) describes how to set up permissions for users and service accounts. +* [Authenticating](/docs/reference/access-authn-authz/authentication/) explains authentication in Kubernetes, including the various authentication options. +* [Authorization](/docs/reference/access-authn-authz/authorization/) is separate from authentication, and controls how HTTP calls are handled. +* [Using Admission Controllers](/docs/reference/access-authn-authz/admission-controllers/) explains plug-ins which intercepts requests to the Kubernetes API server after authentication and authorization. +* [Using Sysctls in a Kubernetes Cluster](/docs/concepts/cluster-administration/sysctl-cluster/) describes to an administrator how to use the `sysctl` command-line tool to set kernel parameters . +* [Auditing](/docs/tasks/debug-application-cluster/audit/) describes how to interact with Kubernetes' audit logs. +--> +## 保护集群 + +* [证书](/zh/docs/concepts/cluster-administration/certificates/)节描述了使用不同的工具链生成证书的步骤。 +* [Kubernetes 容器环境](/zh/docs/concepts/containers/container-environment/)描述了 Kubernetes 节点上由 Kubelet 管理的容器的环境。 +* [控制到 Kubernetes API 的访问](/zh/docs/reference/access-authn-authz/controlling-access/)描述了如何为用户和 service accounts 建立权限许可。 +* [认证](/zh/docs/reference/access-authn-authz/authentication/)节阐述了 Kubernetes 中的身份认证功能，包括许多认证选项。 +* [鉴权](/zh/docs/reference/access-authn-authz/authorization/)从认证中分离出来，用于控制如何处理 HTTP 请求。 +* [使用准入控制器](/zh/docs/reference/access-authn-authz/admission-controllers) 阐述了在认证和授权之后拦截到 Kubernetes API 服务的请求的插件。 +* [在 Kubernetes 集群中使用 Sysctls](/zh/docs/tasks/administer-cluster/sysctl-cluster/) 描述了管理员如何使用 `sysctl` 命令行工具来设置内核参数。 +* [审计](/zh/docs/tasks/debug-application-cluster/audit/)描述了如何与 Kubernetes 的审计日志交互。 + +<!-- +### Securing the kubelet + +* [Master-Node communication](/docs/concepts/architecture/master-node-communication/) +* [TLS bootstrapping](/docs/reference/command-line-tools-reference/kubelet-tls-bootstrapping/) +* [Kubelet authentication/authorization](/docs/admin/kubelet-authentication-authorization/) +--> +### 保护 kubelet + +* [主控节点通信](/zh/docs/concepts/architecture/control-plane-node-communication/) +* [TLS 引导](/zh/docs/reference/command-line-tools-reference/kubelet-tls-bootstrapping/) +* [Kubelet 认证/授权](/zh/docs/reference/command-line-tools-reference/kubelet-authentication-authorization/) + +<!-- +## Optional Cluster Services + +* [DNS Integration](/docs/concepts/services-networking/dns-pod-service/) describes how to resolve a DNS name directly to a Kubernetes service. +* [Logging and Monitoring Cluster Activity](/docs/concepts/cluster-administration/logging/) explains how logging in Kubernetes works and how to implement it. +--> + +## 可选集群服务 + +* [DNS 集成](/zh/docs/concepts/services-networking/dns-pod-service/)描述了如何将一个 DNS 名解析到一个 Kubernetes service。 +* [记录和监控集群活动](/zh/docs/concepts/cluster-administration/logging/)阐述了 Kubernetes 的日志如何工作以及怎样实现。 + diff --git a/content/zh/docs/concepts/cluster-administration/addons.md b/content/zh/docs/concepts/cluster-administration/addons.md index 10eb8adb08..c0291a480d 100644 --- a/content/zh/docs/concepts/cluster-administration/addons.md +++ b/content/zh/docs/concepts/cluster-administration/addons.md @@ -1,12 +1,10 @@ --- - title: 安装扩展（Addons） content_type: concept --- <!-- overview --> - <!-- Add-ons extend the functionality of Kubernetes. @@ -14,15 +12,11 @@ This page lists some of the available add-ons and links to their respective inst Add-ons in each section are sorted alphabetically - the ordering does not imply any preferential status. --> - Add-ons 扩展了 Kubernetes 的功能。 本文列举了一些可用的 add-ons 以及到它们各自安装说明的链接。 -每个 add-ons 按字母顺序排序 - 顺序不代表任何优先地位。 - - - +每个 Add-ons 按字母顺序排序 - 顺序不代表任何优先地位。 <!-- body --> @@ -45,33 +39,50 @@ Add-ons 扩展了 Kubernetes 的功能。 * [Romana](http://romana.io) is a Layer 3 networking solution for pod networks that also supports the [NetworkPolicy API](/docs/concepts/services-networking/network-policies/). Kubeadm add-on installation details available [here](https://github.com/romana/romana/tree/master/containerize). * [Weave Net](https://www.weave.works/docs/net/latest/kube-addon/) provides networking and network policy, will carry on working on both sides of a network partition, and does not require an external database. --> - ## 网络和网络策略 * [ACI](https://www.github.com/noironetworks/aci-containers) 通过 Cisco ACI 提供集成的容器网络和安全网络。 -* [Calico](https://docs.projectcalico.org/v3.11/getting-started/kubernetes/installation/calico) 是一个安全的 L3 网络和网络策略提供者。 +* [Calico](https://docs.projectcalico.org/v3.11/getting-started/kubernetes/installation/calico) + 是一个安全的 L3 网络和网络策略驱动。 * [Canal](https://github.com/tigera/canal/tree/master/k8s-install) 结合 Flannel 和 Calico，提供网络和网络策略。 -* [Cilium](https://github.com/cilium/cilium) 是一个 L3 网络和网络策略插件，能够透明的实施 HTTP/API/L7 策略。同时支持路由（routing）和叠加/封装（overlay/encapsulation）模式。 -* [CNI-Genie](https://github.com/Huawei-PaaS/CNI-Genie) 使 Kubernetes 无缝连接到一种 CNI 插件，例如：Flannel、Calico、Canal、Romana 或者 Weave。 -* [Contiv](http://contiv.github.io) 为多种用例提供可配置网络（使用 BGP 的原生 L3，使用 vxlan 的 overlay，经典 L2 和 Cisco-SDN/ACI）和丰富的策略框架。Contiv 项目完全[开源](http://github.com/contiv)。[安装工具](http://github.com/contiv/install)同时提供基于和不基于 kubeadm 的安装选项。 -* 基于 [Tungsten Fabric](https://tungsten.io) 的 [Contrail](http://www.juniper.net/us/en/products-services/sdn/contrail/contrail-networking/)，是一个开源的多云网络虚拟化和策略管理平台，Contrail 和 Tungsten Fabric 与业务流程系统（例如 Kubernetes、OpenShift、OpenStack和Mesos）集成在一起，并为虚拟机、容器或 Pod 以及裸机工作负载提供了隔离模式。 -* [Flannel](https://github.com/coreos/flannel/blob/master/Documentation/kube-flannel.yml) 是一个可以用于 Kubernetes 的 overlay 网络提供者。 +* [Cilium](https://github.com/cilium/cilium) 是一个 L3 网络和网络策略插件，能够透明的实施 HTTP/API/L7 策略。 + 同时支持路由（routing）和覆盖/封装（overlay/encapsulation）模式。 +* [CNI-Genie](https://github.com/Huawei-PaaS/CNI-Genie) 使 Kubernetes 无缝连接到一种 CNI 插件， + 例如：Flannel、Calico、Canal、Romana 或者 Weave。 +* [Contiv](https://contiv.github.io) 为多种用例提供可配置网络（使用 BGP 的原生 L3，使用 vxlan 的覆盖网络， + 经典 L2 和 Cisco-SDN/ACI）和丰富的策略框架。Contiv 项目完全[开源](https://github.com/contiv)。 + [安装工具](https://github.com/contiv/install)同时提供基于和不基于 kubeadm 的安装选项。 +* 基于 [Tungsten Fabric](https://tungsten.io) 的 + [Contrail](https://www.juniper.net/us/en/products-services/sdn/contrail/contrail-networking/) + 是一个开源的多云网络虚拟化和策略管理平台，Contrail 和 Tungsten Fabric 与业务流程系统 + （例如 Kubernetes、OpenShift、OpenStack和Mesos）集成在一起， + 为虚拟机、容器或 Pod 以及裸机工作负载提供了隔离模式。 +* [Flannel](https://github.com/coreos/flannel/blob/master/Documentation/kube-flannel.yml) + 是一个可以用于 Kubernetes 的 overlay 网络提供者。 * [Knitter](https://github.com/ZTE/Knitter/) 是为 kubernetes 提供复合网络解决方案的网络组件。 -* [Multus](https://github.com/Intel-Corp/multus-cni) 是一个多插件，可在 Kubernetes 中提供多种网络支持，以支持所有 CNI 插件（例如 Calico，Cilium，Contiv，Flannel），而且包含了在 Kubernetes 中基于 SRIOV、DPDK、OVS-DPDK 和 VPP 的工作负载。 -* [NSX-T](https://docs.vmware.com/en/VMware-NSX-T/2.0/nsxt_20_ncp_kubernetes.pdf) 容器插件（ NCP ）提供了 VMware NSX-T 与容器协调器（例如 Kubernetes）之间的集成，以及 NSX-T 与基于容器的 CaaS / PaaS 平台（例如关键容器服务（PKS）和 OpenShift）之间的集成。 -* [Nuage](https://github.com/nuagenetworks/nuage-kubernetes/blob/v5.1.1-1/docs/kubernetes-1-installation.rst) 是一个 SDN 平台，可在 Kubernetes Pods 和非 Kubernetes 环境之间提供基于策略的联网，并具有可视化和安全监控。 -* [Romana](http://romana.io) 是一个 pod 网络的层 3 解决方案，并且支持 [NetworkPolicy API](/docs/concepts/services-networking/network-policies/)。Kubeadm add-on 安装细节可以在[这里](https://github.com/romana/romana/tree/master/containerize)找到。 -* [Weave Net](https://www.weave.works/docs/net/latest/kube-addon/) 提供了在网络分组两端参与工作的网络和网络策略，并且不需要额外的数据库。 +* [Multus](https://github.com/Intel-Corp/multus-cni) 是一个多插件，可在 Kubernetes 中提供多种网络支持， + 以支持所有 CNI 插件（例如 Calico，Cilium，Contiv，Flannel）， + 而且包含了在 Kubernetes 中基于 SRIOV、DPDK、OVS-DPDK 和 VPP 的工作负载。 +* [NSX-T](https://docs.vmware.com/en/VMware-NSX-T/2.0/nsxt_20_ncp_kubernetes.pdf) 容器插件（NCP） + 提供了 VMware NSX-T 与容器协调器（例如 Kubernetes）之间的集成，以及 NSX-T 与基于容器的 + CaaS / PaaS 平台（例如关键容器服务（PKS）和 OpenShift）之间的集成。 +* [Nuage](https://github.com/nuagenetworks/nuage-kubernetes/blob/v5.1.1-1/docs/kubernetes-1-installation.rst) + 是一个 SDN 平台，可在 Kubernetes Pods 和非 Kubernetes 环境之间提供基于策略的联网，并具有可视化和安全监控。 +* [Romana](https://romana.io) 是一个 pod 网络的第三层解决方案，并支持[ + NetworkPolicy API](/zh/docs/concepts/services-networking/network-policies/)。 + Kubeadm add-on 安装细节可以在[这里](https://github.com/romana/romana/tree/master/containerize)找到。 +* [Weave Net](https://www.weave.works/docs/net/latest/kube-addon/) + 提供在网络分组两端参与工作的网络和网络策略，并且不需要额外的数据库。 <!-- ## Service Discovery * [CoreDNS](https://coredns.io) is a flexible, extensible DNS server which can be [installed](https://github.com/coredns/deployment/tree/master/kubernetes) as the in-cluster DNS for pods. --> - ## 服务发现 -* [CoreDNS](https://coredns.io) 是一种灵活的，可扩展的 DNS 服务器，可以[安装](https://github.com/coredns/deployment/tree/master/kubernetes)为集群内的 Pod 提供 DNS 服务。 +* [CoreDNS](https://coredns.io) 是一种灵活的，可扩展的 DNS 服务器，可以 + [安装](https://github.com/coredns/deployment/tree/master/kubernetes)为集群内的 Pod 提供 DNS 服务。 <!-- ## Visualization & Control @@ -79,22 +90,22 @@ Add-ons 扩展了 Kubernetes 的功能。 * [Dashboard](https://github.com/kubernetes/dashboard#kubernetes-dashboard) is a dashboard web interface for Kubernetes. * [Weave Scope](https://www.weave.works/documentation/scope-latest-installing/#k8s) is a tool for graphically visualizing your containers, pods, services etc. Use it in conjunction with a [Weave Cloud account](https://cloud.weave.works/) or host the UI yourself. --> - ## 可视化管理 - -* [Dashboard](https://github.com/kubernetes/dashboard#kubernetes-dashboard) 是一个 Kubernetes 的 web 控制台界面。 -* [Weave Scope](https://www.weave.works/documentation/scope-latest-installing/#k8s) 是一个图形化工具，用于查看你的 containers、 pods、services 等。 请和一个 [Weave Cloud account](https://cloud.weave.works/) 一起使用，或者自己运行 UI。 +* [Dashboard](https://github.com/kubernetes/dashboard#kubernetes-dashboard) 是一个 Kubernetes 的 Web 控制台界面。 +* [Weave Scope](https://www.weave.works/documentation/scope-latest-installing/#k8s) 是一个图形化工具， + 用于查看你的容器、Pod、服务等。请和一个 [Weave Cloud 账号](https://cloud.weave.works/) 一起使用， + 或者自己运行 UI。 <!-- ## Infrastructure * [KubeVirt](https://kubevirt.io/user-guide/#/installation/installation) is an add-on to run virtual machines on Kubernetes. Usually run on bare-metal clusters. --> - ## 基础设施 -* [KubeVirt](https://kubevirt.io/user-guide/#/installation/installation) 是可以让 Kubernetes 运行虚拟机的 add-ons。通常运行在裸机群集上。 +* [KubeVirt](https://kubevirt.io/user-guide/#/installation/installation) 是可以让 Kubernetes + 运行虚拟机的 add-ons。通常运行在裸机集群上。 <!-- ## Legacy Add-ons @@ -103,7 +114,6 @@ There are several other add-ons documented in the deprecated [cluster/addons](ht Well-maintained ones should be linked to here. PRs welcome! --> - ## 遗留 Add-ons 还有一些其它 add-ons 归档在已废弃的 [cluster/addons](https://git.k8s.io/kubernetes/cluster/addons) 路径中。 diff --git a/content/zh/docs/concepts/cluster-administration/certificates.md b/content/zh/docs/concepts/cluster-administration/certificates.md index 9c7e0a9174..75efede893 100644 --- a/content/zh/docs/concepts/cluster-administration/certificates.md +++ b/content/zh/docs/concepts/cluster-administration/certificates.md @@ -1,11 +1,13 @@ --- -cn-approvers: -- lichuqiang title: 证书 content_type: concept weight: 20 --- - +<!-- +title: Certificates +content_type: concept +weight: 20 +--> <!-- overview --> @@ -13,13 +15,9 @@ weight: 20 When using client certificate authentication, you can generate certificates manually through `easyrsa`, `openssl` or `cfssl`. --> - 当使用客户端证书进行认证时，用户可以使用现有部署脚本，或者通过 `easyrsa`、`openssl` 或 `cfssl` 手动生成证书。 - - - <!-- body --> ### easyrsa @@ -27,7 +25,6 @@ manually through `easyrsa`, `openssl` or `cfssl`. <!-- **easyrsa** can manually generate certificates for your cluster. --> - 使用 **easyrsa** 能够手动地为集群生成证书。 <!-- @@ -67,22 +64,30 @@ manually through `easyrsa`, `openssl` or `cfssl`. --tls-private-key-file=/yourdirectory/server.key --> -1. 下载、解压并初始化 easyrsa3 的补丁版本。 +1. 下载、解压并初始化 easyrsa3 的补丁版本。 - curl -LO https://storage.googleapis.com/kubernetes-release/easy-rsa/easy-rsa.tar.gz - tar xzf easy-rsa.tar.gz - cd easy-rsa-master/easyrsa3 - ./easyrsa init-pki -1. 生成 CA（通过 `--batch` 参数设置自动模式。 通过 `--req-cn` 设置默认使用的 CN） + ``` + curl -LO https://storage.googleapis.com/kubernetes-release/easy-rsa/easy-rsa.tar.gz + tar xzf easy-rsa.tar.gz + cd easy-rsa-master/easyrsa3 + ./easyrsa init-pki + ``` - ./easyrsa --batch "--req-cn=${MASTER_IP}@`date +%s`" build-ca nopass -1. 生成服务器证书和密钥。 - 参数 `--subject-alt-name` 设置了访问 API 服务器时可能使用的 IP 和 DNS 名称。 `MASTER_CLUSTER_IP` - 通常为 `--service-cluster-ip-range` 参数中指定的服务 CIDR 的 首个 IP 地址，`--service-cluster-ip-range` 同时用于 - API 服务器和控制器管理器组件。 `--days` 参数用于设置证书的有效期限。 - 下面的示例还假设用户使用 `cluster.local` 作为默认的 DNS 域名。 +1. 生成 CA（通过 `--batch` 参数设置自动模式。 通过 `--req-cn` 设置默认使用的 CN） - ./easyrsa --subject-alt-name="IP:${MASTER_IP},"\ + ``` + ./easyrsa --batch "--req-cn=${MASTER_IP}@`date +%s`" build-ca nopass + ``` + +1. 生成服务器证书和密钥。 + 参数 `--subject-alt-name` 设置了访问 API 服务器时可能使用的 IP 和 DNS 名称。 + `MASTER_CLUSTER_IP` 通常为 `--service-cluster-ip-range` 参数中指定的服务 CIDR 的 首个 IP 地址， + `--service-cluster-ip-range` 同时用于 API 服务器和控制器管理器组件。 + `--days` 参数用于设置证书的有效期限。 + 下面的示例还假设用户使用 `cluster.local` 作为默认的 DNS 域名。 + + ``` + ./easyrsa --subject-alt-name="IP:${MASTER_IP},"\ "IP:${MASTER_CLUSTER_IP},"\ "DNS:kubernetes,"\ "DNS:kubernetes.default,"\ @@ -91,12 +96,17 @@ manually through `easyrsa`, `openssl` or `cfssl`. "DNS:kubernetes.default.svc.cluster.local" \ --days=10000 \ build-server-full server nopass -1. 拷贝 `pki/ca.crt`、 `pki/issued/server.crt` 和 `pki/private/server.key` 至您的目录。 -1. 填充并在 API 服务器的启动参数中添加以下参数： + ``` - --client-ca-file=/yourdirectory/ca.crt - --tls-cert-file=/yourdirectory/server.crt - --tls-private-key-file=/yourdirectory/server.key +1. 拷贝 `pki/ca.crt`、`pki/issued/server.crt` 和 `pki/private/server.key` 至您的目录。 + +1. 填充并在 API 服务器的启动参数中添加以下参数： + + ``` + --client-ca-file=/yourdirectory/ca.crt + --tls-cert-file=/yourdirectory/server.crt + --tls-private-key-file=/yourdirectory/server.key + ``` ### openssl @@ -168,69 +178,87 @@ manually through `easyrsa`, `openssl` or `cfssl`. 使用 **openssl** 能够手动地为集群生成证书。 -1. 生成密钥位数为 2048 的 ca.key： +1. 生成密钥位数为 2048 的 ca.key： - openssl genrsa -out ca.key 2048 -1. 依据 ca.key 生成 ca.crt （使用 -days 参数来设置证书有效时间）： + ``` + openssl genrsa -out ca.key 2048 + ``` - openssl req -x509 -new -nodes -key ca.key -subj "/CN=${MASTER_IP}" -days 10000 -out ca.crt -1. 生成密钥位数为 2048 的 server.key： +1. 依据 ca.key 生成 ca.crt （使用 -days 参数来设置证书有效时间）： - openssl genrsa -out server.key 2048 -1. 创建用于生成证书签名请求（CSR）的配置文件。 - 确保在将其保存至文件（如 `csr.conf`）之前将尖括号标记的值（如 `<MASTER_IP>`） - 替换为你想使用的真实值。 注意：`MASTER_CLUSTER_IP` 是前面小节中描述的 API 服务器的服务集群 IP - (service cluster IP)。 下面的示例也假设用户使用 `cluster.local` 作为默认的 DNS 域名。 + ``` + openssl req -x509 -new -nodes -key ca.key -subj "/CN=${MASTER_IP}" -days 10000 -out ca.crt + ``` - [ req ] - default_bits = 2048 - prompt = no - default_md = sha256 - req_extensions = req_ext - distinguished_name = dn +1. 生成密钥位数为 2048 的 server.key： - [ dn ] - C = <country> - ST = <state> - L = <city> - O = <organization> - OU = <organization unit> - CN = <MASTER_IP> + ``` + openssl genrsa -out server.key 2048 + ``` +1. 创建用于生成证书签名请求（CSR）的配置文件。 + 确保在将其保存至文件（如 `csr.conf`）之前将尖括号标记的值（如 `<MASTER_IP>`） + 替换为你想使用的真实值。 注意：`MASTER_CLUSTER_IP` 是前面小节中描述的 API 服务器的服务集群 IP + (service cluster IP)。 下面的示例也假设用户使用 `cluster.local` 作为默认的 DNS 域名。 - [ req_ext ] - subjectAltName = @alt_names + ``` + [ req ] + default_bits = 2048 + prompt = no + default_md = sha256 + req_extensions = req_ext + distinguished_name = dn - [ alt_names ] - DNS.1 = kubernetes - DNS.2 = kubernetes.default - DNS.3 = kubernetes.default.svc - DNS.4 = kubernetes.default.svc.cluster - DNS.5 = kubernetes.default.svc.cluster.local - IP.1 = <MASTER_IP> - IP.2 = <MASTER_CLUSTER_IP> + [ dn ] + C = <国家> + ST = <州/省> + L = <市> + O = <组织> + OU = <部门> + CN = <MASTER_IP> - [ v3_ext ] - authorityKeyIdentifier=keyid,issuer:always - basicConstraints=CA:FALSE - keyUsage=keyEncipherment,dataEncipherment - extendedKeyUsage=serverAuth,clientAuth - subjectAltName=@alt_names -1. 基于配置文件生成证书签名请求： + [ req_ext ] + subjectAltName = @alt_names - openssl req -new -key server.key -out server.csr -config csr.conf -1. 使用 ca.key、ca.crt 和 server.csr 生成服务器证书： + [ alt_names ] + DNS.1 = kubernetes + DNS.2 = kubernetes.default + DNS.3 = kubernetes.default.svc + DNS.4 = kubernetes.default.svc.cluster + DNS.5 = kubernetes.default.svc.cluster.local + IP.1 = <MASTER_IP> + IP.2 = <MASTER_CLUSTER_IP> - openssl x509 -req -in server.csr -CA ca.crt -CAkey ca.key \ - -CAcreateserial -out server.crt -days 10000 \ - -extensions v3_ext -extfile csr.conf -1. 查看证书： + [ v3_ext ] + authorityKeyIdentifier=keyid,issuer:always + basicConstraints=CA:FALSE + keyUsage=keyEncipherment,dataEncipherment + extendedKeyUsage=serverAuth,clientAuth + subjectAltName=@alt_names + ``` - openssl x509 -noout -text -in ./server.crt +1. 基于配置文件生成证书签名请求： + + ``` + openssl req -new -key server.key -out server.csr -config csr.conf + ``` + +1. 使用 ca.key、ca.crt 和 server.csr 生成服务器证书： + + ``` + openssl x509 -req -in server.csr -CA ca.crt -CAkey ca.key \ + -CAcreateserial -out server.crt -days 10000 \ + -extensions v3_ext -extfile csr.conf + ``` + +1. 查看证书： + + ``` + openssl x509 -noout -text -in ./server.crt + ``` <!-- Finally, add the same parameters into the API server start parameters. --> - 最后，添加同样的参数到 API 服务器的启动参数中。 ### cfssl @@ -238,8 +266,7 @@ Finally, add the same parameters into the API server start parameters. <!-- **cfssl** is another tool for certificate generation. --> - -**cfssl** 是另一种用来生成证书的工具。 +**cfssl** 是用来生成证书的另一种工具。 <!-- 1. Download, unpack and prepare the command line tools as shown below. @@ -337,97 +364,115 @@ Finally, add the same parameters into the API server start parameters. --config=ca-config.json -profile=kubernetes \ server-csr.json | ../cfssljson -bare server --> +1. 按如下所示的方式下载、解压并准备命令行工具。 + 注意：你可能需要基于硬件架构和你所使用的 cfssl 版本对示例命令进行修改。 -1. 按如下所示的方式下载、解压并准备命令行工具。 - 注意：你可能需要基于硬件架构和你所使用的 cfssl 版本对示例命令进行修改。 + ``` + curl -L https://pkg.cfssl.org/R1.2/cfssl_linux-amd64 -o cfssl + chmod +x cfssl + curl -L https://pkg.cfssl.org/R1.2/cfssljson_linux-amd64 -o cfssljson + chmod +x cfssljson + curl -L https://pkg.cfssl.org/R1.2/cfssl-certinfo_linux-amd64 -o cfssl-certinfo + chmod +x cfssl-certinfo + ``` - curl -L https://pkg.cfssl.org/R1.2/cfssl_linux-amd64 -o cfssl - chmod +x cfssl - curl -L https://pkg.cfssl.org/R1.2/cfssljson_linux-amd64 -o cfssljson - chmod +x cfssljson - curl -L https://pkg.cfssl.org/R1.2/cfssl-certinfo_linux-amd64 -o cfssl-certinfo - chmod +x cfssl-certinfo -1. 创建目录来存放物料，并初始化 cfssl： +1. 创建目录来存放物料，并初始化 cfssl： - mkdir cert - cd cert - ../cfssl print-defaults config > config.json - ../cfssl print-defaults csr > csr.json -1. 创建用来生成 CA 文件的 JSON 配置文件，例如 `ca-config.json`： + ``` + mkdir cert + cd cert + ../cfssl print-defaults config > config.json + ../cfssl print-defaults csr > csr.json + ``` - { - "signing": { - "default": { - "expiry": "8760h" - }, - "profiles": { - "kubernetes": { - "usages": [ - "signing", - "key encipherment", - "server auth", - "client auth" - ], - "expiry": "8760h" - } - } - } - } -1. 创建用来生成 CA 证书签名请求（CSR）的 JSON 配置文件，例如 `ca-csr.json`。 - 确保将尖括号标记的值替换为你想使用的真实值。 +1. 创建用来生成 CA 文件的 JSON 配置文件，例如 `ca-config.json`： - { - "CN": "kubernetes", - "key": { - "algo": "rsa", - "size": 2048 - }, - "names":[{ - "C": "<country>", - "ST": "<state>", - "L": "<city>", - "O": "<organization>", - "OU": "<organization unit>" - }] - } -1. 生成 CA 密钥（`ca-key.pem`）和证书（`ca.pem`）： + ``` + { + "signing": { + "default": { + "expiry": "8760h" + }, + "profiles": { + "kubernetes": { + "usages": [ + "signing", + "key encipherment", + "server auth", + "client auth" + ], + "expiry": "8760h" + } + } + } + } + ``` - ../cfssl gencert -initca ca-csr.json | ../cfssljson -bare ca -1. 按如下所示的方式创建用来为 API 服务器生成密钥和证书的 JSON 配置文件。 - 确保将尖括号标记的值替换为你想使用的真实值。 `MASTER_CLUSTER_IP` 是前面小节中描述的 - API 服务器的服务集群 IP。 下面的示例也假设用户使用 `cluster.local` 作为默认的 DNS 域名。 +1. 创建用来生成 CA 证书签名请求（CSR）的 JSON 配置文件，例如 `ca-csr.json`。 + 确保将尖括号标记的值替换为你想使用的真实值。 - { - "CN": "kubernetes", - "hosts": [ - "127.0.0.1", - "<MASTER_IP>", - "<MASTER_CLUSTER_IP>", - "kubernetes", - "kubernetes.default", - "kubernetes.default.svc", - "kubernetes.default.svc.cluster", - "kubernetes.default.svc.cluster.local" - ], - "key": { - "algo": "rsa", - "size": 2048 - }, - "names": [{ - "C": "<country>", - "ST": "<state>", - "L": "<city>", - "O": "<organization>", - "OU": "<organization unit>" - }] - } -1. 为 API 服务器生成密钥和证书，生成的秘钥和证书分别默认保存在文件 `server-key.pem` - 和 `server.pem` 中： + ``` + { + "CN": "kubernetes", + "key": { + "algo": "rsa", + "size": 2048 + }, + "names":[{ + "C": "<country>", + "ST": "<state>", + "L": "<city>", + "O": "<organization>", + "OU": "<organization unit>" + }] + } + ``` - ../cfssl gencert -ca=ca.pem -ca-key=ca-key.pem \ +1. 生成 CA 密钥（`ca-key.pem`）和证书（`ca.pem`）： + + ``` + ../cfssl gencert -initca ca-csr.json | ../cfssljson -bare ca + ``` + +1. 按如下所示的方式创建用来为 API 服务器生成密钥和证书的 JSON 配置文件。 + 确保将尖括号标记的值替换为你想使用的真实值。 `MASTER_CLUSTER_IP` 是前面小节中描述的 + API 服务器的服务集群 IP。 下面的示例也假设用户使用 `cluster.local` 作为默认的 DNS 域名。 + + ``` + { + "CN": "kubernetes", + "hosts": [ + "127.0.0.1", + "<MASTER_IP>", + "<MASTER_CLUSTER_IP>", + "kubernetes", + "kubernetes.default", + "kubernetes.default.svc", + "kubernetes.default.svc.cluster", + "kubernetes.default.svc.cluster.local" + ], + "key": { + "algo": "rsa", + "size": 2048 + }, + "names": [{ + "C": "<country>", + "ST": "<state>", + "L": "<city>", + "O": "<organization>", + "OU": "<organization unit>" + }] + } + ``` + +1. 为 API 服务器生成密钥和证书，生成的秘钥和证书分别默认保存在文件 `server-key.pem` + 和 `server.pem` 中： + + ``` + ../cfssl gencert -ca=ca.pem -ca-key=ca-key.pem \ --config=ca-config.json -profile=kubernetes \ server-csr.json | ../cfssljson -bare server - + ``` <!-- ## Distributing Self-Signed CA Certificate @@ -439,7 +484,6 @@ refresh the local list for valid certificates. On each client, perform the following operations: --> - ## 分发自签名 CA 证书 客户端节点可能拒绝承认自签名 CA 证书有效。 @@ -467,10 +511,9 @@ You can use the `certificates.k8s.io` API to provision x509 certificates to use for authentication as documented [here](/docs/tasks/tls/managing-tls-in-a-cluster). --> - ## 证书 API -您可以按照[这里](/docs/tasks/tls/managing-tls-in-a-cluster)记录的方式， +您可以按照[这里](/zh/docs/tasks/tls/managing-tls-in-a-cluster)记录的方式， 使用 `certificates.k8s.io` API 来准备 x509 证书，用于认证。 diff --git a/content/zh/docs/concepts/cluster-administration/cloud-providers.md b/content/zh/docs/concepts/cluster-administration/cloud-providers.md index f568c57304..b463f1eb1f 100644 --- a/content/zh/docs/concepts/cluster-administration/cloud-providers.md +++ b/content/zh/docs/concepts/cluster-administration/cloud-providers.md @@ -5,11 +5,9 @@ weight: 30 --- <!-- ---- title: Cloud Providers content_type: concept weight: 30 ---- --> <!-- overview --> @@ -28,7 +26,8 @@ kubeadm has configuration options to specify configuration information for cloud in-tree cloud provider can be configured using kubeadm as shown below: --> ### kubeadm -[kubeadm](/docs/reference/setup-tools/kubeadm/kubeadm/) 是创建 kubernetes 集群的一种流行选择。 + +[kubeadm](/zh/docs/reference/setup-tools/kubeadm/kubeadm/) 是创建 kubernetes 集群的一种流行选择。 kubeadm 通过提供配置选项来指定云驱动的配置信息。例如，一个典型的适用于“树内”云驱动的 kubeadm 配置如下： ```yaml @@ -68,9 +67,14 @@ for the [kube-apiserver](/docs/admin/kube-apiserver/), [kube-controller-manager] For all external cloud providers, please follow the instructions on the individual repositories, which are listed under their headings below, or one may view [the list of all repositories](https://github.com/kubernetes?q=cloud-provider-&type=&language=) --> - -“树内”的云驱动通常需要在命令行中为 [kube-apiserver](/docs/admin/kube-apiserver/)、[kube-controller-manager](/docs/admin/kube-controller-manager/) 和 [kubelet](/docs/admin/kubelet/) 指定 `--cloud-provider` 和 `--cloud-config`。在 `--cloud-config` 中为每个供应商指定的文件的内容也同样需要写在下面。 -对于所有外部云驱动，请遵循独立云存储库的说明，或浏览[所有版本库清单](https://github.com/kubernetes?q=cloud-provider-&type=&language=) +“树内”的云驱动通常需要在命令行中为 +[kube-apiserver](/zh/docs/reference/command-line-tools-reference/kube-apiserver/)、 +[kube-controller-manager](/zh/docs/reference/command-line-tools-reference/kube-controller-manager/) 和 +[kubelet](/zh/docs/reference/command-line-tools-reference/kubelet/) 指定 +`--cloud-provider` 和 `--cloud-config`。 +在 `--cloud-config` 中为每个供应商指定的文件内容的文档也可参见本文后文。 +对于所有外部云驱动，请遵循各自仓库的说明，或浏览 +[所有仓库清单](https://github.com/kubernetes?q=cloud-provider-&type=&language=) <!-- ## AWS @@ -79,8 +83,8 @@ be used when running Kubernetes on Amazon Web Services. If you wish to use the external cloud provider, its repository is [kubernetes/cloud-provider-aws](https://github.com/kubernetes/cloud-provider-aws#readme) --> - # AWS + 本节介绍在 Amazon Web Services 上运行 Kubernetes 时可以使用的所有配置。 如果希望使用此外部云驱动，其代码库位于 [kubernetes/cloud-provider-aws](https://github.com/kubernetes/cloud-provider-aws#readme) @@ -100,7 +104,9 @@ to use specific features in AWS by configuring the annotations as shown below. --> ### 负载均衡器 -用户可以通过配置注解（annotations）来设置 [外部负载均衡器](/docs/tasks/access-application-cluster/create-external-load-balancer/)，以在 AWS 中使用特定功能，如下所示： +用户可以通过配置注解（annotations）来设置 +[外部负载均衡器](/zh/docs/tasks/access-application-cluster/create-external-load-balancer/)， +以在 AWS 中使用特定功能，如下所示： ```yaml apiVersion: v1 @@ -125,7 +131,6 @@ spec: <!-- Different settings can be applied to a load balancer service in AWS using _annotations_. The following describes the annotations supported on AWS ELBs: --> - 可以使用 _注解_ 将不同的设置应用于 AWS 中的负载均衡器服务。下面描述了 AWS ELB 所支持的注解： <!-- @@ -152,8 +157,15 @@ Different settings can be applied to a load balancer service in AWS using _annot * `service.beta.kubernetes.io/aws-load-balancer-access-log-s3-bucket-name`：用于指定访问日志的 S3 桶名称。 * `service.beta.kubernetes.io/aws-load-balancer-access-log-s3-bucket-prefix`：用于指定访问日志的 S3 桶前缀。 * `service.beta.kubernetes.io/aws-load-balancer-additional-resource-tags`：用于在服务中指定一个逗号分隔的键值对列表，它将作为附加标签被记录在 ELB 中。例如： `"Key1=Val1,Key2=Val2,KeyNoVal1=,KeyNoVal2"`。 -* `service.beta.kubernetes.io/aws-load-balancer-backend-protocol`：用于在服务中指定监听器后端（pod）所使用的协议。如果指定 `http`（默认）或 `https`，将创建一个终止连接和解析头的 HTTPS 监听器。 如果设置为 `ssl` 或 `tcp`，将会使用 “原生的” SSL 监听器。如果设置为 `http`且不使用 `aws-load-balancer-ssl-cert`，将使用 HTTP 监听器。 -* `service.beta.kubernetes.io/aws-load-balancer-ssl-cert`：用于在服务中请求安全监听器，其值为合法的证书 ARN（Amazon Resource Name）。更多内容，请参考 [ELB 监听器配置](http://docs.aws.amazon.com/ElasticLoadBalancing/latest/DeveloperGuide/elb-listener-config.html)。证书 ARN 是 IAM（身份和访问管理）或 CM（证书管理）类型的 ARN，例如 `arn:aws:acm:us-east-1:123456789012:certificate/12345678-1234-1234-1234-123456789012`。 +* `service.beta.kubernetes.io/aws-load-balancer-backend-protocol`：用于在服务中指定监听器后端（pod）所使用的协议。 + 如果指定 `http`（默认）或 `https`，将创建一个终止连接和解析头的 HTTPS 监听器。 + 如果设置为 `ssl` 或 `tcp`，将会使用 “原生的” SSL 监听器。 + 如果设置为 `http` 且不使用 `aws-load-balancer-ssl-cert`，将使用 HTTP 监听器。 +* `service.beta.kubernetes.io/aws-load-balancer-ssl-cert`：用于在服务中请求安全监听器，其值为合法的 + 证书 ARN（Amazon Resource Name）。更多内容请参考 + [ELB 监听器配置](https://docs.aws.amazon.com/ElasticLoadBalancing/latest/DeveloperGuide/elb-listener-config.html)。 + 证书 ARN 是 IAM（身份和访问管理）或 CM（证书管理）类型的 ARN，例如 + `arn:aws:acm:us-east-1:123456789012:certificate/12345678-1234-1234-1234-123456789012`。 * `service.beta.kubernetes.io/aws-load-balancer-connection-draining-enabled`：用于在服务中启用或禁用连接耗尽（connection draining）。 * `service.beta.kubernetes.io/aws-load-balancer-connection-draining-timeout`：用于在服务中指定连接耗尽超时时间。 * `service.beta.kubernetes.io/aws-load-balancer-connection-idle-timeout`：用于在服务中指定空闲连接超时时间。 @@ -166,7 +178,6 @@ Different settings can be applied to a load balancer service in AWS using _annot <!-- The information for the annotations for AWS is taken from the comments on [aws.go](https://github.com/kubernetes/cloud-provider-aws/blob/master/pkg/cloudprovider/providers/aws/aws.go) --> - AWS 相关的注解信息取自 [aws.go](https://github.com/kubernetes/cloud-provider-aws/blob/master/pkg/cloudprovider/providers/aws/aws.go) 文件的注释。 ## Azure @@ -182,7 +193,6 @@ If you wish to use the external cloud provider, its repository is [kubernetes/cl The Azure cloud provider uses the hostname of the node (as determined by the kubelet or overridden with `--hostname-override`) as the name of the Kubernetes Node object. Note that the Kubernetes Node name must match the Azure VM name. --> - ### 节点名称 云驱动 Azure 使用节点的主机名（由 kubelet 决定，或者用 `--hostname-override` 覆盖）作为 Kubernetes 节点对象的名称。 @@ -202,7 +212,6 @@ If you wish to use the external cloud provider, its repository is [apache/clouds The CloudStack cloud provider uses the hostname of the node (as determined by the kubelet or overridden with `--hostname-override`) as the name of the Kubernetes Node object. Note that the Kubernetes Node name must match the CloudStack VM name. --> - ### 节点名称 云驱动 CloudStack 使用节点的主机名（由 kubelet 决定，或者用 `--hostname-override` 覆盖）作为 Kubernetes 节点对象的名称。 @@ -212,7 +221,6 @@ Note that the Kubernetes Node name must match the CloudStack VM name. <!-- If you wish to use the external cloud provider, its repository is [kubernetes/cloud-provider-gcp](https://github.com/kubernetes/cloud-provider-gcp#readme) --> - 如果希望使用此外部云驱动，其代码库位于 [kubernetes/cloud-provider-gcp](https://github.com/kubernetes/cloud-provider-gcp#readme) <!-- @@ -221,7 +229,6 @@ If you wish to use the external cloud provider, its repository is [kubernetes/cl The GCE cloud provider uses the hostname of the node (as determined by the kubelet or overridden with `--hostname-override`) as the name of the Kubernetes Node object. Note that the first segment of the Kubernetes Node name must match the GCE instance name (e.g. a Node named `kubernetes-node-2.c.my-proj.internal` must correspond to an instance named `kubernetes-node-2`). --> - ### 节点名称 GCE 云驱动使用节点的主机名（由 kubelet 确定，或者用 `--hostname-override` 覆盖）作为 Kubernetes 节点对象的名称。 @@ -244,7 +251,6 @@ If you wish to use the external cloud provider, its repository is [kubernetes/cl The OpenStack cloud provider uses the instance name (as determined from OpenStack metadata) as the name of the Kubernetes Node object. Note that the instance name must be a valid Kubernetes Node name in order for the kubelet to successfully register its Node object. --> - ### 节点名称 OpenStack 云驱动使用实例名（由 OpenStack 元数据确定）作为 Kubernetes 节点对象的名称。 @@ -286,12 +292,12 @@ a future release. As of the "Queens" release, OpenStack will no longer expose th Identity V2 API. § Load Balancing V1 API support was removed in Kubernetes 1.9. --> +† 块存储 V1 版本的 API 被弃用，从 Kubernetes 1.9 版本开始加入了块存储 V3 版本 API。 -† Block Storage V1 版本的 API 被弃用，从 Kubernetes 1.9 版本开始加入了 Block Storage V3 版本 API。 +‡ 身份认证 V2 API 支持已被弃用，将在未来的版本中从供应商中移除。 + 从 “Queens” 版本开始，OpenStack 将不再支持身份认证 V2 版本的 API。 -‡ Identity V2 API 支持已被弃用，将在未来的版本中从供应商中移除。从 “Queens” 版本开始，OpenStack 将不再支持 Identity V2 版本的 API。 - -§ Kubernetes 1.9 中取消了对 V1 版本 Load Balancing API 的支持。 +§ Kubernetes 1.9 中取消了对 V1 版本负载均衡 API 的支持。 <!-- Service discovery is achieved by listing the service catalog managed by @@ -301,19 +307,19 @@ OpenStack services other than Keystone are not available and simply disclaim support for impacted features. Certain features are also enabled or disabled based on the list of extensions published by Neutron in the underlying cloud. --> - 服务发现是通过使用供应商配置中提供的 `auth-url` 所列出 OpenStack 身份认证（Keystone）管理的服务目录来实现的。 当除 Keystone 外的 OpenStack 服务不可用时，供应商将优雅地降低功能，并简单地放弃对受影响特性的支持。 某些功能还可以根据 Neutron 在底层云中发布的扩展列表启用或禁用。 ### cloud.conf + <!-- Kubernetes knows how to interact with OpenStack via the file cloud.conf. It is the file that will provide Kubernetes with credentials and location for the OpenStack auth endpoint. You can create a cloud.conf file by specifying the following details in it --> - -Kubernetes 知道如何通过 cloud.conf 文件与 OpenStack 交互。该文件将为 Kubernetes 提供 OpenStack 验证端点的凭据和位置。 +Kubernetes 知道如何通过 cloud.conf 文件与 OpenStack 交互。 +该文件将为 Kubernetes 提供 OpenStack 验证端点的凭据和位置。 用户可在创建 cloud.conf 文件时指定以下信息： <!-- @@ -325,7 +331,8 @@ load balancer: --> #### 典型配置 -下面是一个典型配置的例子，它涉及到最常设置的值。它将供应商指向 OpenStack 云的 Keystone 端点，提供如何使用它进行身份验证的细节，并配置负载均衡器: +下面是一个典型配置的例子，它涉及到最常设置的值。它将供应商指向 OpenStack 云的 Keystone 端点， +提供如何使用它进行身份验证的细节，并配置负载均衡器: ```yaml [Global] @@ -344,7 +351,6 @@ These configuration options for the OpenStack provider pertain to its global configuration and should appear in the `[Global]` section of the `cloud.conf` file: --> - ##### 全局配置 这些配置选项属于 OpenStack 驱动的全局配置，并且应该出现在 `cloud.conf` 文件中的 `[global]` 部分: @@ -377,22 +383,26 @@ file: * `ca-file` (Optional): Used to specify the path to your custom CA file. --> -* `auth-url` (必需): 用于认证的 keystone API 的 URL。在 OpenStack 控制面板中，这可以在“访问和安全（Access and Security）> API 访问（API Access）> 凭证（Credentials）”中找到。 +* `auth-url` (必需): 用于认证的 Keystone API 的 URL。在 OpenStack 控制面板中， + 这可以在“访问和安全（Access and Security）> API 访问（API Access）> 凭证（Credentials）”中找到。 * `username` (必需): 指 keystone 中一个有效用户的用户名。 * `password` (必需): 指 keystone 中一个有效用户的密码。 * `tenant-id` (必需): 用于指定要创建资源的租户 ID。 * `tenant-name` (可选): 用于指定要在其中创建资源的租户的名称。 -* `trust-id` (可选): 用于指定用于授权的信任的标识符。信任表示用户（委托人）将角色委托给另一个用户(受托人)的授权，并可选的允许受托人模仿委托人。可用的信任可以在 Keystone API 的 `/v3/OS-TRUST/trusts` 端点下找到。 +* `trust-id` (可选): 用于指定用于授权的信任的标识符。信任表示用户（委托人） + 将角色委托给另一个用户(受托人)的授权，并可选的允许受托人模仿委托人。 + 可用的信任可以在 Keystone API 的 `/v3/OS-TRUST/trusts` 端点下找到。 * `domain-id` (可选): 用于指定用户所属域的 ID。 * `domain-name` (可选): 用于指定用户所属域的名称。 -* `region` (可选): 用于指定在多区域 OpenStack 云上运行时使用的区域标识符。区域是 OpenStack 部署的一般性划分。虽然区域没有严格的地理含义，但部署可以使用地理名称表示区域标识符，如 `us-east`。可用区域位于 Keystone API 的 `/v3/regions` 端点之下。 +* `region` (可选): 用于指定在多区域 OpenStack 云上运行时使用的区域标识符。 + 区域是 OpenStack 部署的一般性划分。虽然区域没有严格的地理含义，但部署可以使用地理名称表示区域标识符， + 如 `us-east`。可用区域位于 Keystone API 的 `/v3/regions` 端点之下。 * `ca-file` (可选): 用于指定自定义 CA 文件的路径。 <!-- When using Keystone V3 - which changes tenant to project - the `tenant-id` value is automatically mapped to the project construct in the API. --> - 当使用 Keystone V3 时(它将tenant更改为project)，`tenant-id` 值会自动映射到 API 中的项目。 <!-- @@ -401,7 +411,6 @@ These configuration options for the OpenStack provider pertain to the load balancer and should appear in the `[LoadBalancer]` section of the `cloud.conf` file: --> - #### 负载均衡器 这些配置选项属于 OpenStack 驱动的全局配置，并且应该出现在 `cloud.conf` 文件中的 `[LoadBalancer]` 部分: @@ -447,24 +456,34 @@ file: * `node-security-group` (Optional): ID of the security group to manage. --> -* `lb-version` (可选): 用于覆盖自动版本检测。有效值为 `v1` 或 `v2`。如果没有提供值，则自动选择底层 OpenStack 云所支持的最高版本。 -* `use-octavia` (可选): 用于确定是否查找和使用 Octavia LBaaS V2 服务目录端点。有效值是 `true` 或 `false`。 -如果指定了“true”，并且无法找到 Octaiva LBaaS V2 入口，则提供者将退回并尝试寻找一个 Neutron LBaaS V2 端点。默认值是 `false`。 +* `lb-version` (可选): 用于覆盖自动版本检测。有效值为 `v1` 或 `v2`。 + 如果没有提供值，则自动选择底层 OpenStack 云所支持的最高版本。 +* `use-octavia` (可选): 用于确定是否查找和使用 Octavia LBaaS V2 服务目录端点。 + 有效值是 `true` 或 `false`。 + 如果指定了“true”，并且无法找到 Octaiva LBaaS V2 入口，则提供者将退回并尝试寻找一个 + Neutron LBaaS V2 端点。默认值是 `false`。 * `subnet-id` (可选): 用于指定要在其上创建负载均衡器的子网的 ID。 -可以在 “Network > Networks” 上找到。 -单击相应的网络以获得其子网。 + 可以在 “Network > Networks” 上找到。 + 单击相应的网络以获得其子网。 * `floating-network-id` (可选): 如果指定，将为负载均衡器创建一个浮动 IP。 -* `lb-method` (可选): 用于指定将负载分配到负载均衡器池成员的算法。值可以是 `ROUND_ROBIN`、`LEAST_CONNECTIONS` 或 `SOURCE_IP`。如果没有指定，默认行为是 `ROUND_ROBIN`。 -* `lb-provider` (可选): 用于指定负载均衡器的提供程序。如果没有指定，将使用在 Neutron 中配置的默认提供者服务。 -* `create-monitor` (可选): 指定是否为 Neutron 负载均衡器创建健康监视器。有效值是 `true` 和 `false`。 -默认为 `false`。当指定 `true` 时，还必须设置 `monitor-delay`、`monitor-timeout` 和 `monitor-max-retries`。 +* `lb-method` (可选): 用于指定将负载分配到负载均衡器池成员的算法。 + 值可以是 `ROUND_ROBIN`、`LEAST_CONNECTIONS` 或 `SOURCE_IP`。 + 如果没有指定，默认行为是 `ROUND_ROBIN`。 +* `lb-provider` (可选): 用于指定负载均衡器的提供程序。 + 如果没有指定，将使用在 Neutron 中配置的默认提供者服务。 +* `create-monitor` (可选): 指定是否为 Neutron 负载均衡器创建健康监视器。 + 有效值是 `true` 和 `false`。 + 默认为 `false`。当指定 `true` 时，还必须设置 `monitor-delay`、`monitor-timeout` 和 `monitor-max-retries`。 * `monitor-delay` (可选): 向负载均衡器的成员发送探测之间的时间间隔。 -确保您指定了一个有效的时间单位。 -有效时间单位为 `ns`、`us` (或 `µs`)、`ms`、`s`、`m`、`h`。 -* `monitor-timeout` (可选): 在超时之前，监视器等待 ping 响应的最长时间。该值必须小于延迟值。确保您指定了一个有效的时间单位。有效时间单位为 `ns`、 `us` (或 `µs`)、`ms`、`s`、`m`、 `h`。 + 确保您指定了一个有效的时间单位。 + 有效时间单位为 `ns`、`us` (或 `µs`)、`ms`、`s`、`m`、`h`。 +* `monitor-timeout` (可选): 在超时之前，监视器等待 ping 响应的最长时间。 + 该值必须小于延迟值。确保您指定了一个有效的时间单位。 + 有效时间单位为 `ns`、`us` (或 `µs`)、`ms`、`s`、`m`、`h`。 * `monitor-max-retries` (可选): 在将负载均衡器成员的状态更改为非活动之前，允许 ping 失败的次数。 -必须是 1 到 10 之间的数字。 -* `manage-security-groups` (可选): 确定负载均衡器是否应自动管理安全组规则。有效值是 `true` 和 `false`。默认为 `false`。当指定 `true` 时，还必须提供 `node-security-group`。 + 必须是 1 到 10 之间的数字。 +* `manage-security-groups` (可选): 确定负载均衡器是否应自动管理安全组规则。 + 有效值是 `true` 和 `false`。默认为 `false`。当指定 `true` 时，还必须提供 `node-security-group`。 * `node-security-group` (可选): 要管理的安全组的 ID。 <!-- @@ -472,7 +491,6 @@ file: These configuration options for the OpenStack provider pertain to block storage and should appear in the `[BlockStorage]` section of the `cloud.conf` file: --> - ##### 块存储 这些配置选项属于 OpenStack 驱动的全局配置，并且应该出现在 `cloud.conf` 文件中的 `[BlockStorage]` 部分： @@ -498,12 +516,15 @@ and should appear in the `[BlockStorage]` section of the `cloud.conf` file: attached to the node, default is 256 for cinder. --> -* `bs-version` (可选): 指所使用的块存储 API 版本。其合法值为 `v1`、`v2`、`v3`和 `auto`。 `auto` 为默认值，将使用底层 Openstack 所支持的块存储 API 的最新版本。 -* `trust-device-path` (可选): 在大多数情况下，块设备名称由 Cinder 提供（例如：`/dev/vda`）不可信任。此布尔值切换此行为。将其设置为 `true` 将导致信任 Cinder 提供的块设备名称。默认值 `false` 会根据设备序列号和 `/dev/disk/by-id` 映射发现设备路径，推荐这种方法。 +* `bs-version` (可选): 指所使用的块存储 API 版本。其合法值为 `v1`、`v2`、`v3`和 `auto`。 + `auto` 为默认值，将使用底层 Openstack 所支持的块存储 API 的最新版本。 +* `trust-device-path` (可选): 在大多数情况下，块设备名称由 Cinder 提供（例如：`/dev/vda`）不可信任。 + 此布尔值切换此行为。将其设置为 `true` 将导致信任 Cinder 提供的块设备名称。 + 默认值 `false` 会根据设备序列号和 `/dev/disk/by-id` 映射发现设备路径，推荐这种方法。 * `ignore-volume-az` (可选): 用于在附加 Cinder 卷时影响可用区使用。 -当 Nova 和 Cinder 有不同的可用区域时，应该将其设置为 `true`。 -最常见的情况是，有许多 Nova 可用区，但只有一个 Cinder 可用区。 -默认值是 `false`，以保持在早期版本中使用的行为，但是将来可能会更改。 + 当 Nova 和 Cinder 有不同的可用区域时，应该将其设置为 `true`。 + 最常见的情况是，有许多 Nova 可用区，但只有一个 Cinder 可用区。 + 默认值是 `false`，以保持在早期版本中使用的行为，但是将来可能会更改。 * `node-volume-attach-limit` (可选): 可连接到节点的最大卷数，对于 Cinder 默认为 256。 <!-- @@ -519,17 +540,19 @@ returned on attempting volume detachment. To workaround this issue it is possible to force the use of Cinder API version 2 by adding this to the cloud provider configuration: --> +如果在 OpenStack 上部署 Kubernetes <= 1.8 的版本，同时使用路径而不是端口来区分端点（Endpoints）， +那么可能需要显式设置 `bs-version` 参数。 +基于路径的端点形如 `http://foo.bar/volume`，而基于端口的的端点形如 `http://foo.bar:xxx`。 -如果在 OpenStack 上部署 Kubernetes <= 1.8 的版本，同时使用路径而不是端口来区分端点（Endpoints），那么可能需要显式设置 `bs-version` 参数。 基于路径的端点形如 `http://foo.bar/volume`，而基于端口的的端点形如 -`http://foo.bar:xxx`。 - -在使用基于路径的端点，并且 Kubernetes 使用较旧的自动检索逻辑的环境中，尝试卷卸载（Detachment）会返回 `BS API version autodetection failed.` 错误。为了解决这个问题，可以通过添加以下内容到云驱动配置中，来强制使用 Cinder API V2 版本。 - +在使用基于路径的端点，并且 Kubernetes 使用较旧的自动检索逻辑的环境中， +尝试卷卸载（Detachment）会返回 `BS API version autodetection failed.` 错误。 +为了解决这个问题，可以通过添加以下内容到云驱动配置中，来强制使用 Cinder API V2 版本。 ```yaml [BlockStorage] bs-version=v2 ``` + <!-- ##### Metadata These configuration options for the OpenStack provider pertain to metadata and @@ -553,19 +576,22 @@ should appear in the `[Metadata]` section of the `cloud.conf` file: both configuration drive and metadata service though and only one or the other may be available which is why the default is to check both. --> - ##### 元数据 这些配置选项属于 OpenStack 提供程序的全局配置，并且应该出现在 `cloud.conf` 文件中的 `[Metadata]` 部分： * `search-order` (可选): 此配置键影响提供者检索与其运行的实例相关的元数据的方式。 -`configDrive，metadataService` 的默认值导致供应商首先从配置驱动器中检索与实例相关的元数据（如果可用的话），然后检索元数据服务。 -他们的替代值： + `configDrive，metadataService` 的默认值导致供应商首先从配置驱动器中检索与实例相关的元数据（如果可用的话）， + 然后检索元数据服务。 + 他们的替代值： + * `configDrive` - 仅从配置驱动器检索实例元数据。 * `metadataService` - 仅从元数据服务检索实例元数据。 * `metadataService,configDrive` - 如果可用，首先从元数据服务检索实例元数据，然后从配置驱动器检索。 -影响这种行为可能是可取的，因为配置驱动器上的元数据可能会随着时间的推移而变得陈旧，而元数据服务总是提供最新的数据视图。并不是所有的 OpenStack 云都同时提供配置驱动和元数据服务，可能只有一个或另一个可用，这就是为什么默认情况下要同时检查两个。 + 影响这种行为可能是可取的，因为配置驱动器上的元数据可能会随着时间的推移而变得陈旧， + 而元数据服务总是提供最新的数据视图。并不是所有的 OpenStack 云都同时提供配置驱动和元数据服务， + 可能只有一个或另一个可用，这就是为什么默认情况下要同时检查两个。 <!-- ##### Route @@ -578,20 +604,20 @@ Kubernetes network plugin and should appear in the `[Route]` section of the the `extraroutes` extension then use `router-id` to specify a router to add routes to. The router chosen must span the private networks containing your cluster nodes (typically there is only one node network, and this value should be - the default router for the node network). This value is required to use [kubenet] + the default router for the node network). This value is required to use + [kubenet](/docs/concepts/cluster-administration/network-plugins/#kubenet) on OpenStack. - -[kubenet]: /docs/concepts/cluster-administration/network-plugins/#kubenet --> ##### 路由 这些配置选项属于 OpenStack 驱动为 Kubernetes 网络插件 [kubenet] 提供的设置，并且应该出现在 `cloud.conf` 文件中的 `[Route]` 部分: -* `router-id` (可选)：如果底层云的 Neutron 部署支持 `extraroutes` 扩展，则使用 `router-id` 指定要添加路由的路由器。选择的路由器必须跨越包含集群节点的私有网络（通常只有一个节点网络，这个值应该是节点网络的默认路由器）。在 OpenStack 上使用 [kubenet] 时需要这个值。 - -[kubenet]: /docs/concepts/cluster-administration/network-plugins/#kubenet - +* `router-id` (可选)：如果底层云的 Neutron 部署支持 `extraroutes` 扩展， + 则使用 `router-id` 指定要添加路由的路由器。 + 选择的路由器必须跨越包含集群节点的私有网络（通常只有一个节点网络，这个值应该是节点网络的默认路由器）。 + 在 OpenStack 上使用 [kubenet](/zh/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/#kubenet) + 时需要这个值。 ## OVirt @@ -616,10 +642,13 @@ OVirt 云驱动使用节点的主机名（由 kubelet 确定，或者用 `--host The Photon cloud provider uses the hostname of the node (as determined by the kubelet or overridden with `--hostname-override`) as the name of the Kubernetes Node object. Note that the Kubernetes Node name must match the Photon VM name (or if `overrideIP` is set to true in the `--cloud-config`, the Kubernetes Node name must match the Photon VM IP address). --> + ### 节点名称 -Photon 云驱动使用节点的主机名（由 kubelet 决定，或者用 `--hostname-override` 覆盖）作为 Kubernetes 节点对象的名称。 -注意，Kubernetes 节点名必须与 Photon VM名匹配（或者，如果在 `--cloud-config` 中将 `overrideIP` 设置为 `true`，则 Kubernetes 节点名必须与 Photon VM IP 地址匹配）。 +Photon 云驱动使用节点的主机名（由 kubelet 决定，或者用 `--hostname-override` 覆盖） +作为 Kubernetes 节点对象的名称。 +注意，Kubernetes 节点名必须与 Photon VM名匹配（或者，如果在 `--cloud-config` 中将 +`overrideIP` 设置为 `true`，则 Kubernetes 节点名必须与 Photon VM IP 地址匹配）。 ## VSphere @@ -645,45 +674,54 @@ The name of the Kubernetes Node object is the private IP address of the IBM Clou --> ### 计算节点 -通过使用 IBM Cloud Kubernetes Service 驱动，您可以在单个区域或跨区域的多个区（Region）中创建虚拟和物理（裸金属）节点的集群。 +通过使用 IBM Cloud Kubernetes Service 驱动，您可以在单个区域或跨区域的多个区（Region） +中创建虚拟和物理（裸金属）节点的集群。 有关更多信息，请参见[规划您的集群和工作节点设置](https://cloud.ibm.com/docs/containers?topic=containers-plan_clusters#plan_clusters)。 Kubernetes 节点对象的名称是 IBM Cloud Kubernetes Services 工作节点实例的私有IP地址。 <!-- ### Networking + The IBM Cloud Kubernetes Service provider provides VLANs for quality network performance and network isolation for nodes. You can set up custom firewalls and Calico network policies to add an extra layer of security for your cluster, or connect your cluster to your on-prem data center via VPN. For more information, see [Planning in-cluster and private networking](https://cloud.ibm.com/docs/containers?topic=containers-cs_network_cluster#cs_network_cluster). To expose apps to the public or within the cluster, you can leverage NodePort, LoadBalancer, or Ingress services. You can also customize the Ingress application load balancer with annotations. For more information, see [Planning to expose your apps with external networking](https://cloud.ibm.com/docs/containers?topic=containers-cs_network_planning#cs_network_planning). --> ### 网络 -IBM Cloud Kubernetes Services 驱动提供 VLAN，用于提供高质量的网络性能和节点间的网络隔离。您可以设置自定义防火墙和 Calico 网络策略来为您的集群添加额外的安全层，或者通过 VPN 将您的集群连接到自有数据中心。有关更多信息，请参见[规划集群内和私有网络](https://cloud.ibm.com/docs/containers?topic=containers-cs_network_cluster#cs_network_cluster)。 +IBM Cloud Kubernetes Services 驱动提供 VLAN，用于提供高质量的网络性能和节点间的网络隔离。 +您可以设置自定义防火墙和 Calico 网络策略来为您的集群添加额外的安全层，或者通过 VPN +将您的集群连接到自有数据中心。 +有关更多信息，请参见[规划集群内和私有网络](https://cloud.ibm.com/docs/containers?topic=containers-cs_network_cluster#cs_network_cluster)。 -要向公众或集群内部公开应用程序，您可以利用 NodePort、LoadBalancer 或 Ingress 服务。您还可以使用注释自定义 Ingress 应用程序负载均衡器。有关更多信息，请参见[计划使用外部网络公开您的应用程序](https://cloud.ibm.com/docs/containers?topic=containers-cs_network_planning#cs_network_planning)。 +要向公众或集群内部公开应用程序，您可以利用 NodePort、LoadBalancer 或 Ingress 服务。 +您还可以使用注释自定义 Ingress 应用程序负载均衡器。 +有关更多信息，请参见[计划使用外部网络公开您的应用程序](https://cloud.ibm.com/docs/containers?topic=containers-cs_network_planning#cs_network_planning)。 <!-- ### Storage + The IBM Cloud Kubernetes Service provider leverages Kubernetes-native persistent volumes to enable users to mount file, block, and cloud object storage to their apps. You can also use database-as-a-service and third-party add-ons for persistent storage of your data. For more information, see [Planning highly available persistent storage](https://cloud.ibm.com/docs/containers?topic=containers-storage_planning#storage_planning). --> ### 存储 -IBM Cloud Kubernetes Services 驱动利用 Kubernetes 原生的持久卷，使用户能够将文件、块和云对象存储装载到他们的应用程序中。还可以使用 database-as-a-service 和第三方附加组件来持久存储数据。有关更多信息，请参见[规划高可用性持久存储](https://cloud.ibm.com/docs/containers?topic=containers-storage_planning#storage_planning)。 +IBM Cloud Kubernetes Services 驱动利用 Kubernetes 原生的持久卷，使用户能够将文件、块和云对象存储 +装载到他们的应用程序中。还可以使用 database-as-a-service 和第三方附加组件来持久存储数据。 +有关更多信息，请参见[规划高可用性持久存储](https://cloud.ibm.com/docs/containers?topic=containers-storage_planning#storage_planning)。 <!-- ## Baidu Cloud Container Engine - ### Node Name The Baidu cloud provider uses the private IP address of the node (as determined by the kubelet or overridden with `--hostname-override`) as the name of the Kubernetes Node object. Note that the Kubernetes Node name must match the Baidu VM private IP. --> - ## 百度云容器引擎 ### 节点名称 -Baidu 云驱动使用节点的私有 IP 地址（由 kubelet 确定，或者用 `--hostname-override` 覆盖）作为 Kubernetes 节点对象的名称。 +Baidu 云驱动使用节点的私有 IP 地址（由 kubelet 确定，或者用 `--hostname-override` 覆盖） +作为 Kubernetes 节点对象的名称。 注意 Kubernetes 节点名必须匹配百度 VM 的私有 IP。 diff --git a/content/zh/docs/concepts/cluster-administration/cluster-administration-overview.md b/content/zh/docs/concepts/cluster-administration/cluster-administration-overview.md deleted file mode 100644 index 76462847fd..0000000000 --- a/content/zh/docs/concepts/cluster-administration/cluster-administration-overview.md +++ /dev/null @@ -1,145 +0,0 @@ ---- -title: 集群管理概述 -content_type: concept -weight: 10 ---- - -<!-- overview --> - -<!-- -The cluster administration overview is for anyone creating or administering a Kubernetes cluster. -It assumes some familiarity with core Kubernetes [concepts](/docs/concepts/). ---> - -集群管理概述面向任何创建和管理 Kubernetes 集群的读者人群。 -我们假设你对[用户指南](/docs/user-guide/)中的概念大概了解。 - - -<!-- body --> - -<!-- -## Planning a cluster - -See the guides in [Setup](/docs/setup/) for examples of how to plan, set up, and configure Kubernetes clusters. The solutions listed in this article are called *distros*. - -Before choosing a guide, here are some considerations: ---> - -## 规划集群 - -查阅 [安装](/docs/setup/) 中的指导，获取如何规划、建立以及配置 Kubernetes 集群的示例。本文所列的文章称为*发行版* 。 - -在选择一个指南前，有一些因素需要考虑： - -<!-- - - Do you just want to try out Kubernetes on your computer, or do you want to build a high-availability, multi-node cluster? Choose distros best suited for your needs. - - **If you are designing for high-availability**, learn about configuring [clusters in multiple zones](/docs/concepts/cluster-administration/federation/). - - Will you be using **a hosted Kubernetes cluster**, such as [Google Kubernetes Engine](https://cloud.google.com/kubernetes-engine/), or **hosting your own cluster**? - - Will your cluster be **on-premises**, or **in the cloud (IaaS)**? Kubernetes does not directly support hybrid clusters. Instead, you can set up multiple clusters. - - **If you are configuring Kubernetes on-premises**, consider which [networking model](/docs/concepts/cluster-administration/networking/) fits best. - - Will you be running Kubernetes on **"bare metal" hardware** or on **virtual machines (VMs)**? - - Do you **just want to run a cluster**, or do you expect to do **active development of Kubernetes project code**? If the - latter, choose an actively-developed distro. Some distros only use binary releases, but - offer a greater variety of choices. - - Familiarize yourself with the [components](/docs/admin/cluster-components/) needed to run a cluster. ---> - - - 你是打算在你的电脑上尝试 Kubernetes，还是要构建一个高可用的多节点集群？请选择最适合你需求的发行版。 - - **如果你正在设计一个高可用集群**，请了解[在多个 zones 中配置集群](/docs/concepts/cluster-administration/federation/)。 - - 您正在使用 类似 [Google Kubernetes Engine](https://cloud.google.com/kubernetes-engine/) 这样的**被托管的Kubernetes集群**, 还是**管理您自己的集群**? - - 你的集群是在**本地**还是 **云（IaaS）** 上？ Kubernetes 不能直接支持混合集群。作为代替，你可以建立多个集群。 - - **如果你在本地配置 Kubernetes**，需要考虑哪种[网络模型](/docs/concepts/cluster-administration/networking/)最适合。 - - 你的 Kubernetes 在 **裸金属硬件** 还是 **虚拟机（VMs）** 上运行？ - - 你**只想运行一个集群**，还是打算**活动开发 Kubernetes 项目代码**？如果是后者，请选择一个活动开发的发行版。某些发行版只提供二进制发布版，但提供更多的选择。 - - 让你自己熟悉运行一个集群所需的[组件](/docs/admin/cluster-components) 。 - -<!-- -Note: Not all distros are actively maintained. Choose distros which have been tested with a recent version of Kubernetes. ---> - -请注意：不是所有的发行版都被积极维护着。请选择测试过最近版本的 Kubernetes 的发行版。 - -<!-- -## Managing a cluster - -* [Managing a cluster](/docs/tasks/administer-cluster/cluster-management/) describes several topics related to the lifecycle of a cluster: creating a new cluster, upgrading your cluster’s master and worker nodes, performing node maintenance (e.g. kernel upgrades), and upgrading the Kubernetes API version of a running cluster. - -* Learn how to [manage nodes](/docs/concepts/nodes/node/). - -* Learn how to set up and manage the [resource quota](/docs/concepts/policy/resource-quotas/) for shared clusters. ---> - -## 管理集群 - -* [管理集群](/docs/concepts/cluster-administration/cluster-management/)叙述了和集群生命周期相关的几个主题：创建一个新集群、升级集群的 master 和 worker 节点、执行节点维护（例如内核升级）以及升级活动集群的 Kubernetes API 版本。 - -* 学习如何 [管理节点](/docs/concepts/nodes/node/). - -* 学习如何设定和管理集群共享的 [资源配额](/docs/concepts/policy/resource-quotas/) 。 - -<!-- -## Securing a cluster - -* [Certificates](/docs/concepts/cluster-administration/certificates/) describes the steps to generate certificates using different tool chains. - -* [Kubernetes Container Environment](/docs/concepts/containers/container-environment-variables/) describes the environment for Kubelet managed containers on a Kubernetes node. - -* [Controlling Access to the Kubernetes API](/docs/reference/access-authn-authz/controlling-access/) describes how to set up permissions for users and service accounts. - -* [Authenticating](/docs/reference/access-authn-authz/authentication/) explains authentication in Kubernetes, including the various authentication options. - -* [Authorization](/docs/reference/access-authn-authz/authorization/) is separate from authentication, and controls how HTTP calls are handled. - -* [Using Admission Controllers](/docs/reference/access-authn-authz/admission-controllers/) explains plug-ins which intercepts requests to the Kubernetes API server after authentication and authorization. - -* [Using Sysctls in a Kubernetes Cluster](/docs/concepts/cluster-administration/sysctl-cluster/) describes to an administrator how to use the `sysctl` command-line tool to set kernel parameters . - -* [Auditing](/docs/tasks/debug-application-cluster/audit/) describes how to interact with Kubernetes' audit logs. ---> - -## 集群安全 - -* [Certificates](/docs/concepts/cluster-administration/certificates/) 描述了使用不同的工具链生成证书的步骤。 - -* [Kubernetes 容器环境](/docs/concepts/containers/container-environment-variables/) 描述了 Kubernetes 节点上由 Kubelet 管理的容器的环境。 - -* [控制到 Kubernetes API 的访问](/docs/reference/access-authn-authz/controlling-access/)描述了如何为用户和 service accounts 建立权限许可。 - -* [用户认证](/docs/reference/access-authn-authz/authentication/)阐述了 Kubernetes 中的认证功能，包括许多认证选项。 - -* [授权](/docs/admin/authorization)从认证中分离出来，用于控制如何处理 HTTP 请求。 - -* [使用 Admission Controllers](/docs/admin/admission-controllers) 阐述了在认证和授权之后拦截到 Kubernetes API 服务的请求的插件。 - -* [在 Kubernetes Cluster 中使用 Sysctls](/docs/concepts/cluster-administration/sysctl-cluster/) 描述了管理员如何使用 `sysctl` 命令行工具来设置内核参数。 - -* [审计](/docs/tasks/debug-application-cluster/audit/)描述了如何与 Kubernetes 的审计日志交互。 - -<!-- -### Securing the kubelet - * [Master-Node communication](/docs/concepts/architecture/master-node-communication/) - * [TLS bootstrapping](/docs/reference/command-line-tools-reference/kubelet-tls-bootstrapping/) - * [Kubelet authentication/authorization](/docs/admin/kubelet-authentication-authorization/) ---> - -### 保护 kubelet - - * [Master 节点通信](/docs/concepts/cluster-administration/master-node-communication/) - * [TLS 引导](/docs/reference/command-line-tools-reference/kubelet-tls-bootstrapping/) - * [Kubelet 认证/授权](/docs/admin/kubelet-authentication-authorization/) - -<!-- -## Optional Cluster Services - -* [DNS Integration](/docs/concepts/services-networking/dns-pod-service/) describes how to resolve a DNS name directly to a Kubernetes service. - -* [Logging and Monitoring Cluster Activity](/docs/concepts/cluster-administration/logging/) explains how logging in Kubernetes works and how to implement it. ---> - -## 可选集群服务 - -* [DNS 与 SkyDNS 集成](/docs/concepts/services-networking/dns-pod-service/)描述了如何将一个 DNS 名解析到一个 Kubernetes service。 - -* [记录和监控集群活动](/docs/concepts/cluster-administration/logging/)阐述了 Kubernetes 的日志如何工作以及怎样实现。 - - diff --git a/content/zh/docs/concepts/cluster-administration/federation.md b/content/zh/docs/concepts/cluster-administration/federation.md deleted file mode 100644 index e0f86e8823..0000000000 --- a/content/zh/docs/concepts/cluster-administration/federation.md +++ /dev/null @@ -1,118 +0,0 @@ ---- -title: 联邦 -content_type: concept ---- - -<!-- overview --> -本页面阐明了为何以及如何使用联邦创建Kubernetes集群。 - - -<!-- body --> -## 为何使用联邦 - -联邦可以使多个集群的管理简单化。它提供了两个主要构件模块： - - * 跨集群同步资源：联邦能够让资源在多个集群中同步。例如，你可以确保在多个集群中存在同样的部署。 - * 跨集群发现：联邦能够在所有集群的后端自动配置DNS服务和负载均衡。例如，通过多个集群的后端，你可以确保全局的VIP或DNS记录可用。 - -联邦技术的其他应用场景： - -* 高可用性：通过跨集群分摊负载，自动配置DNS服务和负载均衡，联邦将集群失败所带来的影响降到最低。 -* 避免供应商锁定：跨集群使迁移应用程序变得更容易，联邦服务避免了供应商锁定。 - - -只有在多个集群的场景下联邦服务才是有帮助的。这里列出了一些你会使用多个集群的原因： - -* 降低延迟：在多个区域含有集群，可使用离用户最近的集群来服务用户，从而最大限度降低延迟。 -* 故障隔离：对于故障隔离，也许有多个小的集群比有一个大的集群要更好一些（例如：一个云供应商的不同可用域里有多个集群）。详细信息请参阅[多集群指南](/docs/admin/multi-cluster)。 -* 可伸缩性：对于单个kubernetes集群是有伸缩性限制的（但对于大多数用户来说并非如此。更多细节参考[Kubernetes扩展和性能目标](https://git.k8s.io/community/sig-scalability/goals.md)）。 -* [混合云](#混合云的能力)：可以有多个集群，它们分别拥有不同的云供应商或者本地数据中心。 - -### 注意事项 - -虽然联邦有很多吸引人的场景，但这里还是有一些需要关注的事项： - -* 增加网络的带宽和损耗：联邦控制面会监控所有的集群，来确保集群的当前状态与预期一致。那么当这些集群运行在一个或者多个云提供者的不同区域中，则会带来重大的网络损耗。 -* 降低集群的隔离：当联邦控制面中存在一个故障时，会影响所有的集群。把联邦控制面的逻辑降到最小可以缓解这个问题。 无论何时，它都是kubernetes集群里控制面的代表。设计和实现也使其变得更安全,避免多集群运行中断。 -* 完整性：联邦项目相对较新，还不是很成熟。不是所有资源都可用，且很多资源才刚刚开始。[Issue 38893](https://github.com/kubernetes/kubernetes/issues/38893) 列举了一些团队正忙于解决的系统已知问题。 - -### 混合云的能力 - -Kubernetes集群里的联邦包括运行在不同云供应商上的集群（例如，谷歌云、亚马逊），和本地部署的集群（例如，OpenStack）。只需在适当的云供应商和/或位置创建所需的所有集群，并将每个集群的API endpoint和凭据注册到您的联邦API服务中（详情参考[联邦管理指南](/docs/admin/federation/)）。 - -在此之后，您的[API资源](#api资源)就可以跨越不同的集群和云供应商。 - -## 建立联邦 - -若要能联合多个集群，首先需要建立一个联邦控制面。参照[安装指南](/docs/tutorials/federation/set-up-cluster-federation-kubefed/) 建立联邦控制面。 - -## API资源 - -控制面建立完成后，就可以开始创建联邦API资源了。 -以下指南详细介绍了一些资源： - -* [Cluster](/docs/tasks/administer-federation/cluster/) -* [ConfigMap](/docs/tasks/administer-federation/configmap/) -* [DaemonSets](/docs/tasks/administer-federation/daemonset/) -* [Deployment](/docs/tasks/administer-federation/deployment/) -* [Events](/docs/tasks/administer-federation/events/) -* [Ingress](/docs/tasks/administer-federation/ingress/) -* [Namespaces](/docs/tasks/administer-federation/namespaces/) -* [ReplicaSets](/docs/tasks/administer-federation/replicaset/) -* [Secrets](/docs/tasks/administer-federation/secret/) -* [Services](/docs/concepts/cluster-administration/federation-service-discovery/) - -[API参考文档](/docs/reference/federation/)列举了联邦API服务支持的所有资源。 - -## 级联删除 - -Kubernetes1.6版本支持联邦资源级联删除。使用级联删除，即当删除联邦控制面的一个资源时，也删除了所有底层集群中的相应资源。 - -当使用REST API时，级联删除功能不是默认开启的。若使用REST API从联邦控制面删除一个资源时，要开启级联删除功能，即需配置选项 `DeleteOptions.orphanDependents=false`。使用`kubectl delete`使级联删除功能默认开启。使用`kubectl delete --cascade=false`禁用级联删除功能。 - -注意：Kubernetes1.5版本开始支持联邦资源子集的级联删除。 - -## 单个集群的范围 - -对于IaaS供应商如谷歌计算引擎或亚马逊网络服务，一个虚拟机存在于一个[域](https://cloud.google.com/compute/docs/zones)或[可用域](http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-regions-availability-zones.html)中。 -我们建议一个Kubernetes集群里的所有虚机应该在相同的可用域里，因为： - - - 与单一的全局Kubernetes集群对比，该方式有较少的单点故障。 - - 与跨可用域的集群对比，该方式更容易推断单区域集群的可用性属性。 - - 当Kubernetes开发者设计一个系统(例如，对延迟、带宽或相关故障进行假设)，他们也会假设所有的机器都在一个单一的数据中心，或者以其他方式紧密相连。 - -每个可用区域里包含多个集群当然是可以的，但是总的来说我们认为集群数越少越好。 -偏爱较少集群数的原因是： - - - 在某些情况下，在一个集群里有更多的节点，可以改进Pods的装箱问题（更少的资源碎片）。 - - 减少操作开销（尽管随着OPS工具和流程的成熟而降低了这块的优势）。 - - 为每个集群的固定资源花费降低开销，例如，使用apiserver的虚拟机（但是在全体集群开销中，中小型集群的开销占比要小的多）。 - -多集群的原因包括： - - - 严格的安全性策略要求隔离一类工作与另一类工作（但是，请参见下面的集群分割）。 - - 测试集群或其他集群软件直至最优的新Kubernetes版本发布。 - -## 选择合适的集群数 - -Kubernetes集群数量选择也许是一个相对静止的选择，因为对其重新审核的情况很少。相比之下，一个集群中的节点数和一个服务中的pods数可能会根据负载和增长频繁变化。 - -选择集群的数量，首先，需要决定哪些区域对于将要运行在Kubernetes上的服务，可以有足够的时间到达所有的终端用户（如果使用内容分发网络，则不需要考虑CDN-hosted内容的延迟需求）。法律问题也可能影响这一点。例如，拥有全球客户群的公司可能会对于在美国、欧盟、亚太和南非地区拥有集群起到决定权。使用`R`代表区域的数量。 - -其次，决定有多少集群在同一时间不可用，而一些仍然可用。使用`U`代表不可用的数量。如果不确定，最好选择1。 - -如果允许负载均衡在集群故障发生时将通信引导到任何区域，那么至少需要较大的`R`或`U + 1`集群。若非如此（例如，若要在集群故障发生时确保所有用户的低延迟），则需要`R * (U + 1)`集群(在每一个`R`区域里都有`U + 1`)。在任何情况下，尝试将每个集群放在不同的区域中。 - -最后，如果你的集群需求超过一个Kubernetes集群推荐的最大节点数，那么你可能需要更多的集群。Kubernetes1.3版本支持多达1000个节点的集群规模。 - - - -## {{% heading "whatsnext" %}} - -* 进一步学习[联邦提案](https://github.com/kubernetes/community/blob/{{< param "githubbranch" >}}/contributors/design-proposals/multicluster/federation.md)。 -* 集群联邦参考该[配置指导](/docs/tutorials/federation/set-up-cluster-federation-kubefed/)。 -* 查看[Kubecon2016浅谈联邦](https://www.youtube.com/watch?v=pq9lbkmxpS8) - - - - diff --git a/content/zh/docs/concepts/cluster-administration/kubelet-garbage-collection.md b/content/zh/docs/concepts/cluster-administration/kubelet-garbage-collection.md index d9ffdaeb01..5bc6c0b8d4 100644 --- a/content/zh/docs/concepts/cluster-administration/kubelet-garbage-collection.md +++ b/content/zh/docs/concepts/cluster-administration/kubelet-garbage-collection.md @@ -5,110 +5,86 @@ weight: 70 --- <!-- ---- title: Configuring kubelet Garbage Collection content_type: concept weight: 70 ---- --> <!-- overview --> -垃圾回收是 kubelet 的一个有用功能，它将清理未使用的镜像和容器。 - <!-- Garbage collection is a helpful function of kubelet that will clean up unused images and unused containers. ---> - -Kubelet 将每分钟对容器执行一次垃圾回收，每五分钟对镜像执行一次垃圾回收。 - -<!-- Kubelet will perform garbage collection for containers every minute and garbage collection for images every five minutes. ---> -不建议使用外部垃圾收集工具，因为这些工具可能会删除原本期望存在的容器进而破坏 kubelet 的行为。 - -<!-- External garbage collection tools are not recommended as these tools can potentially break the behavior of kubelet by removing containers expected to exist. --> +垃圾回收是 kubelet 的一个有用功能，它将清理未使用的镜像和容器。 +Kubelet 将每分钟对容器执行一次垃圾回收，每五分钟对镜像执行一次垃圾回收。 - +不建议使用外部垃圾收集工具，因为这些工具可能会删除原本期望存在的容器进而破坏 kubelet 的行为。 <!-- body --> -## 镜像回收 - <!-- ## Image Collection + +Kubernetes manages lifecycle of all images through imageManager, with the cooperation +of cadvisor. + +The policy for garbage collecting images takes two factors into consideration: +`HighThresholdPercent` and `LowThresholdPercent`. Disk usage above the high threshold +will trigger garbage collection. The garbage collection will delete least recently used +images until the low threshold has been met. --> +## 镜像回收 {#image-collection} Kubernetes 借助于 cadvisor 通过 imageManager 来管理所有镜像的生命周期。 -<!-- -Kubernetes manages lifecycle of all images through imageManager, with the cooperation -of cadvisor. ---> - 镜像垃圾回收策略只考虑两个因素：`HighThresholdPercent` 和 `LowThresholdPercent`。 - -<!-- -The policy for garbage collecting images takes two factors into consideration: -`HighThresholdPercent` and `LowThresholdPercent`. ---> - 磁盘使用率超过上限阈值（HighThresholdPercent）将触发垃圾回收。 - -<!-- -Disk usage above the high threshold will trigger garbage collection. ---> - 垃圾回收将删除最近最少使用的镜像，直到磁盘使用率满足下限阈值（LowThresholdPercent）。 -<!-- -The garbage collection will delete least recently used images until the low -threshold has been met. ---> - -## 容器回收 - <!-- ## Container Collection ---> -容器垃圾回收策略考虑三个用户定义变量。`MinAge` 是容器可以被执行垃圾回收的最小生命周期。`MaxPerPodContainer` 是每个 pod 内允许存在的死亡容器的最大数量。 -`MaxContainers` 是全部死亡容器的最大数量。可以分别独立地通过将 `MinAge` 设置为 0，以及将 `MaxPerPodContainer` 和 `MaxContainers` 设置为小于 0 来禁用这些变量。 -<!-- The policy for garbage collecting containers considers three user-defined variables. `MinAge` is the minimum age at which a container can be garbage collected. `MaxPerPodContainer` is the maximum number of dead containers every single pod (UID, container name) pair is allowed to have. `MaxContainers` is the maximum number of total dead containers. These variables can be individually disabled by setting `MinAge` to zero and setting `MaxPerPodContainer` and `MaxContainers` respectively to less than zero. --> +## 容器回收 {#container-collection} -Kubelet 将处理无法辨识的、已删除的以及超出前面提到的参数所设置范围的容器。最老的容器通常会先被移除。 -`MaxPerPodContainer` 和 `MaxContainer` 在某些场景下可能会存在冲突，例如在保证每个 pod 内死亡容器的最大数量（`MaxPerPodContainer`）的条件下可能会超过允许存在的全部死亡容器的最大数量（`MaxContainer`）。 -`MaxPerPodContainer` 在这种情况下会被进行调整：最坏的情况是将 `MaxPerPodContainer` 降级为 1，并驱逐最老的容器。 -此外，pod 内已经被删除的容器一旦年龄超过 `MinAge` 就会被清理。 +容器垃圾回收策略考虑三个用户定义变量。 +`MinAge` 是容器可以被执行垃圾回收的最小生命周期。 +`MaxPerPodContainer` 是每个 pod 内允许存在的死亡容器的最大数量。 +`MaxContainers` 是全部死亡容器的最大数量。 +可以分别独立地通过将 `MinAge` 设置为 0，以及将 `MaxPerPodContainer` 和 `MaxContainers` +设置为小于 0 来禁用这些变量。 <!-- Kubelet will act on containers that are unidentified, deleted, or outside of the boundaries set by the previously mentioned flags. The oldest containers will generally be removed first. `MaxPerPodContainer` and `MaxContainer` may potentially conflict with each other in situations where retaining the maximum number of containers per pod (`MaxPerPodContainer`) would go outside the allowable range of global dead containers (`MaxContainers`). `MaxPerPodContainer` would be adjusted in this situation: A worst case scenario would be to downgrade `MaxPerPodContainer` to 1 and evict the oldest containers. Additionally, containers owned by pods that have been deleted are removed once they are older than `MinAge`. --> - -不被 kubelet 管理的容器不受容器垃圾回收的约束。 +`kubelet` 将处理无法辨识的、已删除的以及超出前面提到的参数所设置范围的容器。 +最老的容器通常会先被移除。 +`MaxPerPodContainer` 和 `MaxContainer` 在某些场景下可能会存在冲突， +例如在保证每个 pod 内死亡容器的最大数量（`MaxPerPodContainer`）的条件下可能会超过 +允许存在的全部死亡容器的最大数量（`MaxContainer`）。 +`MaxPerPodContainer` 在这种情况下会被进行调整： +最坏的情况是将 `MaxPerPodContainer` 降级为 1，并驱逐最老的容器。 +此外，pod 内已经被删除的容器一旦年龄超过 `MinAge` 就会被清理。 <!-- Containers that are not managed by kubelet are not subject to container garbage collection. --> - -## 用户配置 +不被 kubelet 管理的容器不受容器垃圾回收的约束。 <!-- ## User Configuration ---> -用户可以使用以下 kubelet 参数调整相关阈值来优化镜像垃圾回收： - -<!-- Users can adjust the following thresholds to tune image garbage collection with the following kubelet flags : --> +## 用户配置 {#user-configuration} + +用户可以使用以下 kubelet 参数调整相关阈值来优化镜像垃圾回收： <!-- 1. `image-gc-high-threshold`, the percent of disk usage which triggers image garbage collection. @@ -119,14 +95,12 @@ to free. Default is 80%. --> 1. `image-gc-high-threshold`，触发镜像垃圾回收的磁盘使用率百分比。默认值为 85%。 - 2. `image-gc-low-threshold`，镜像垃圾回收试图释放资源后达到的磁盘使用率百分比。默认值为 80%。 -我们还允许用户通过以下 kubelet 参数自定义垃圾收集策略： - <!-- We also allow users to customize garbage collection policy through the following kubelet flags: --> +我们还允许用户通过以下 kubelet 参数自定义垃圾收集策略： <!-- 1. `minimum-container-ttl-duration`, minimum age for a finished container before it is @@ -139,12 +113,13 @@ per container. Default is 1. Default is -1, which means there is no global limit. --> -1. `minimum-container-ttl-duration`，完成的容器在被垃圾回收之前的最小年龄，默认是 0 分钟，这意味着每个完成的容器都会被执行垃圾回收。 +1. `minimum-container-ttl-duration`，完成的容器在被垃圾回收之前的最小年龄，默认是 0 分钟。 + 这意味着每个完成的容器都会被执行垃圾回收。 2. `maximum-dead-containers-per-container`，每个容器要保留的旧实例的最大数量。默认值为 1。 -3. `maximum-dead-containers`，要全局保留的旧容器实例的最大数量。默认值是 -1，这意味着没有全局限制。 - +3. `maximum-dead-containers`，要全局保留的旧容器实例的最大数量。 + 默认值是 -1，意味着没有全局限制。 <!-- Containers can potentially be garbage collected before their usefulness has expired. These containers @@ -152,45 +127,29 @@ can contain logs and other data that can be useful for troubleshooting. A suffic `maximum-dead-containers-per-container` is highly recommended to allow at least 1 dead container to be retained per expected container. A larger value for `maximum-dead-containers` is also recommended for a similar reason. ---> +See [this issue](https://github.com/kubernetes/kubernetes/issues/13287) for more details. +--> 容器可能会在其效用过期之前被垃圾回收。这些容器可能包含日志和其他对故障诊断有用的数据。 强烈建议为 `maximum-dead-containers-per-container` 设置一个足够大的值，以便每个预期容器至少保留一个死亡容器。 由于同样的原因，`maximum-dead-containers` 也建议使用一个足够大的值。 -查阅 [这个问题](https://github.com/kubernetes/kubernetes/issues/13287) 获取更多细节。 - -<!-- -See [this issue](https://github.com/kubernetes/kubernetes/issues/13287) for more details. ---> - -## 弃用 +查阅[这个 Issue](https://github.com/kubernetes/kubernetes/issues/13287) 获取更多细节。 <!-- ## Deprecation + +Some kubelet Garbage Collection features in this doc will be replaced by kubelet eviction in the future. + +Including: --> +## 弃用 {#deprecation} 这篇文档中的一些 kubelet 垃圾收集（Garbage Collection）功能将在未来被 kubelet 驱逐回收（eviction）所替代。 -<!-- -Some kubelet Garbage Collection features in this doc will be replaced by kubelet eviction in the future. ---> - 包括: -| 现存参数 | 新参数 | 解释 | -| ------------- | -------- | --------- | -| `--image-gc-high-threshold` | `--eviction-hard` 或 `--eviction-soft` | 现存的驱逐回收信号可以触发镜像垃圾回收 | -| `--image-gc-low-threshold` | `--eviction-minimum-reclaim` | 驱逐回收实现相同行为 | -| `--maximum-dead-containers` | | 一旦旧日志存储在容器上下文之外，就会被弃用 | -| `--maximum-dead-containers-per-container` | | 一旦旧日志存储在容器上下文之外，就会被弃用 | -| `--minimum-container-ttl-duration` | | 一旦旧日志存储在容器上下文之外，就会被弃用 | -| `--low-diskspace-threshold-mb` | `--eviction-hard` or `eviction-soft` | 驱逐回收将磁盘阈值泛化到其他资源 | -| `--outofdisk-transition-frequency` | `--eviction-pressure-transition-period` | 驱逐回收将磁盘压力转换到其他资源 | - <!-- -Including: - | Existing Flag | New Flag | Rationale | | ------------- | -------- | --------- | | `--image-gc-high-threshold` | `--eviction-hard` or `--eviction-soft` | existing eviction signals can trigger image garbage collection | @@ -201,16 +160,21 @@ Including: | `--low-diskspace-threshold-mb` | `--eviction-hard` or `eviction-soft` | eviction generalizes disk thresholds to other resources | | `--outofdisk-transition-frequency` | `--eviction-pressure-transition-period` | eviction generalizes disk pressure transition to other resources | --> - - +| 现存参数 | 新参数 | 解释 | +| ------------- | -------- | --------- | +| `--image-gc-high-threshold` | `--eviction-hard` 或 `--eviction-soft` | 现存的驱逐回收信号可以触发镜像垃圾回收 | +| `--image-gc-low-threshold` | `--eviction-minimum-reclaim` | 驱逐回收实现相同行为 | +| `--maximum-dead-containers` | | 一旦旧日志存储在容器上下文之外，就会被弃用 | +| `--maximum-dead-containers-per-container` | | 一旦旧日志存储在容器上下文之外，就会被弃用 | +| `--minimum-container-ttl-duration` | | 一旦旧日志存储在容器上下文之外，就会被弃用 | +| `--low-diskspace-threshold-mb` | `--eviction-hard` or `eviction-soft` | 驱逐回收将磁盘阈值泛化到其他资源 | +| `--outofdisk-transition-frequency` | `--eviction-pressure-transition-period` | 驱逐回收将磁盘压力转换到其他资源 | ## {{% heading "whatsnext" %}} - -查阅 [配置驱逐回收资源的策略](/docs/tasks/administer-cluster/out-of-resource/) 获取更多细节。 - <!-- See [Configuring Out Of Resource Handling](/docs/tasks/administer-cluster/out-of-resource/) for more details. --> +查阅[配置资源不足情况的处理](/zh/docs/tasks/administer-cluster/out-of-resource/)了解更多细节。 diff --git a/content/zh/docs/concepts/cluster-administration/logging.md b/content/zh/docs/concepts/cluster-administration/logging.md index 349f408109..e0a47b8c84 100755 --- a/content/zh/docs/concepts/cluster-administration/logging.md +++ b/content/zh/docs/concepts/cluster-administration/logging.md @@ -1,25 +1,33 @@ --- -reviewers: -- piosz -- x13n title: 日志架构 content_type: concept weight: 60 --- - +<!-- +reviewers: +- piosz +- x13n +title: Logging Architecture +content_type: concept +weight: 60 +--> <!-- overview --> <!-- Application and systems logs can help you understand what is happening inside your cluster. The logs are particularly useful for debugging problems and monitoring cluster activity. Most modern applications have some kind of logging mechanism; as such, most container engines are likewise designed to support some kind of logging. The easiest and most embraced logging method for containerized applications is to write to the standard output and standard error streams. --> -应用和系统日志可以让您了解集群内部的运行状况。日志对调试问题和监控集群活动非常有用。大部分现代化应用都有某种日志记录机制；同样地，大多数容器引擎也被设计成支持某种日志记录机制。针对容器化应用，最简单且受欢迎的日志记录方式就是写入标准输出和标准错误流。 +应用和系统日志可以让你了解集群内部的运行状况。日志对调试问题和监控集群活动非常有用。 +大部分现代化应用都有某种日志记录机制；同样地，大多数容器引擎也被设计成支持某种日志记录机制。 +针对容器化应用，最简单且受欢迎的日志记录方式就是写入标准输出和标准错误流。 <!-- However, the native functionality provided by a container engine or runtime is usually not enough for a complete logging solution. For example, if a container crashes, a pod is evicted, or a node dies, you'll usually still want to access your application's logs. As such, logs should have a separate storage and lifecycle independent of nodes, pods, or containers. This concept is called _cluster-level-logging_. Cluster-level logging requires a separate backend to store, analyze, and query logs. Kubernetes provides no native storage solution for log data, but you can integrate many existing logging solutions into your Kubernetes cluster. --> -但是，由容器引擎或 runtime 提供的原生功能通常不足以满足完整的日志记录方案。例如，如果发生容器崩溃、pod 被逐出或节点宕机等情况，您仍然想访问到应用日志。因此，日志应该具有独立的存储和生命周期，与节点、pod 或容器的生命周期相独立。这个概念叫 _集群级的日志_ 。集群级日志方案需要一个独立的后台来存储、分析和查询日志。Kubernetes 没有为日志数据提供原生存储方案，但是您可以集成许多现有的日志解决方案到 Kubernetes 集群中。 - - +但是，由容器引擎或运行时提供的原生功能通常不足以满足完整的日志记录方案。 +例如，如果发生容器崩溃、Pod 被逐出或节点宕机等情况，你仍然想访问到应用日志。 +因此，日志应该具有独立的存储和生命周期，与节点、Pod 或容器的生命周期相独立。 +这个概念叫 _集群级的日志_ 。集群级日志方案需要一个独立的后台来存储、分析和查询日志。 +Kubernetes 没有为日志数据提供原生存储方案，但是你可以集成许多现有的日志解决方案到 Kubernetes 集群中。 <!-- body --> @@ -29,7 +37,8 @@ a logging backend is present inside or outside of your cluster. If you're not interested in having cluster-level logging, you might still find the description of how logs are stored and handled on the node to be useful. --> -集群级日志架构假定在集群内部或者外部有一个日志后台。如果您对集群级日志不感兴趣，您仍会发现关于如何在节点上存储和处理日志的描述对您是有用的。 +集群级日志架构假定在集群内部或者外部有一个日志后台。 +如果你对集群级日志不感兴趣，你仍会发现关于如何在节点上存储和处理日志的描述对你是有用的。 <!-- ## Basic logging in Kubernetes @@ -41,15 +50,16 @@ a container that writes some text to standard output once per second. --> ## Kubernetes 中的基本日志记录 -本节，您会看到一个kubernetes 中生成基本日志的例子，该例子中数据被写入到标准输出。 -这里通过一个特定的 [pod 规约](/examples/debug/counter-pod.yaml) 演示创建一个容器，并令该容器每秒钟向标准输出写入数据。 +本节，你会看到一个kubernetes 中生成基本日志的例子，该例子中数据被写入到标准输出。 +这里通过一个特定的 [Pod 规约](/examples/debug/counter-pod.yaml) 演示创建一个容器， +并令该容器每秒钟向标准输出写入数据。 {{< codenew file="debug/counter-pod.yaml" >}} <!-- To run this pod, use the following command: --> -用下面的命令运行 pod： +用下面的命令运行 Pod： ```shell kubectl apply -f https://k8s.io/examples/debug/counter-pod.yaml @@ -72,6 +82,7 @@ To fetch the logs, use the `kubectl logs` command, as follows: ```shell kubectl logs counter ``` + <!-- The output is: --> @@ -87,8 +98,8 @@ The output is: <!-- You can use `kubectl logs` to retrieve logs from a previous instantiation of a container with `--previous` flag, in case the container has crashed. If your pod has multiple containers, you should specify which container's logs you want to access by appending a container name to the command. See the [`kubectl logs` documentation](/docs/reference/generated/kubectl/kubectl-commands#logs) for more details. --> -一旦发生容器崩溃，您可以使用命令 `kubectl logs` 和参数 `--previous` 检索之前的容器日志。 -如果 pod 中有多个容器，您应该向该命令附加一个容器名以访问对应容器的日志。 +一旦发生容器崩溃，你可以使用命令 `kubectl logs` 和参数 `--previous` 检索之前的容器日志。 +如果 pod 中有多个容器，你应该向该命令附加一个容器名以访问对应容器的日志。 详见 [`kubectl logs` 文档](/docs/reference/generated/kubectl/kubectl-commands#logs)。 <!-- @@ -104,23 +115,23 @@ You can use `kubectl logs` to retrieve logs from a previous instantiation of a c Everything a containerized application writes to `stdout` and `stderr` is handled and redirected somewhere by a container engine. For example, the Docker container engine redirects those two streams to [a logging driver](https://docs.docker.com/engine/admin/logging/overview), which is configured in Kubernetes to write to a file in json format. --> 容器化应用写入 `stdout` 和 `stderr` 的任何数据，都会被容器引擎捕获并被重定向到某个位置。 -例如，Docker 容器引擎将这两个输出流重定向到某个 [日志驱动](https://docs.docker.com/engine/admin/logging/overview) ， -该日志驱动在 Kubernetes 中配置为以 json 格式写入文件。 +例如，Docker 容器引擎将这两个输出流重定向到某个 +[日志驱动](https://docs.docker.com/engine/admin/logging/overview) ， +该日志驱动在 Kubernetes 中配置为以 JSON 格式写入文件。 <!-- -{{< note >}} The Docker json logging driver treats each line as a separate message. When using the Docker logging driver, there is no direct support for multi-line messages. You need to handle multi-line messages at the logging agent level or higher. -{{< /note >}} --> {{< note >}} -Docker json 日志驱动将日志的每一行当作一条独立的消息。该日志驱动不直接支持多行消息。您需要在日志代理级别或更高级别处理多行消息。 +Docker JSON 日志驱动将日志的每一行当作一条独立的消息。 +该日志驱动不直接支持多行消息。你需要在日志代理级别或更高级别处理多行消息。 {{< /note >}} <!-- By default, if a container restarts, the kubelet keeps one terminated container with its logs. If a pod is evicted from the node, all corresponding containers are also evicted, along with their logs. --> 默认情况下，如果容器重启，kubelet 会保留被终止的容器日志。 -如果 pod 在工作节点被驱逐，该 pod 中所有的容器也会被驱逐，包括容器日志。 +如果 Pod 在工作节点被驱逐，该 Pod 中所有的容器也会被驱逐，包括容器日志。 <!-- An important consideration in node-level logging is implementing log rotation, @@ -137,8 +148,9 @@ default rotation is configured to take place when log file exceeds 10MB. --> 节点级日志记录中，需要重点考虑实现日志的轮转，以此来保证日志不会消耗节点上所有的可用空间。 Kubernetes 当前并不负责轮转日志，而是通过部署工具建立一个解决问题的方案。 -例如，在 Kubernetes 集群中，用 `kube-up.sh` 部署一个每小时运行的工具 [`logrotate`](https://linux.die.net/man/8/logrotate)。 -您也可以设置容器 runtime 来自动地轮转应用日志，比如使用 Docker 的 `log-opt` 选项。 +例如，在 Kubernetes 集群中，用 `kube-up.sh` 部署一个每小时运行的工具 +[`logrotate`](https://linux.die.net/man/8/logrotate)。 +你也可以设置容器 runtime 来自动地轮转应用日志，比如使用 Docker 的 `log-opt` 选项。 在 `kube-up.sh` 脚本中，使用后一种方式来处理 GCP 上的 COS 镜像，而使用前一种方式来处理其他环境。 这两种方式，默认日志超过 10MB 大小时都会触发日志轮转。 @@ -146,8 +158,9 @@ Kubernetes 当前并不负责轮转日志，而是通过部署工具建立一个 As an example, you can find detailed information about how `kube-up.sh` sets up logging for COS image on GCP in the corresponding [script][cosConfigureHelper]. --> -例如，您可以找到关于 `kube-up.sh` 为 GCP 环境的 COS 镜像设置日志的详细信息， -相应的脚本在 [这里][cosConfigureHelper]。 +例如，你可以找到关于 `kube-up.sh` 为 GCP 环境的 COS 镜像设置日志的详细信息， +相应的脚本在 +[这里](https://github.com/kubernetes/kubernetes/blob/{{< param "githubbranch" >}}/cluster/gce/gci/configure-helper.sh) <!-- When you run [`kubectl logs`](/docs/reference/generated/kubectl/kubectl-commands#logs) as in @@ -157,7 +170,6 @@ reads directly from the log file, returning the contents in the response. 当运行 [`kubectl logs`](/docs/reference/generated/kubectl/kubectl-commands#logs) 时， 节点上的 kubelet 处理该请求并直接读取日志文件，同时在响应中返回日志文件内容。 -{{< note >}} <!-- Currently, if some external system has performed the rotation, only the contents of the latest log file will be available through @@ -165,12 +177,12 @@ only the contents of the latest log file will be available through the rotation and there are two files, one 10MB in size and one empty, `kubectl logs` will return an empty response. --> +{{< note >}} 当前，如果有其他系统机制执行日志轮转，那么 `kubectl logs` 仅可查询到最新的日志内容。 -比如，一个 10MB 大小的文件，通过`logrotate` 执行轮转后生成两个文件，一个 10MB 大小，一个为空，所以 `kubectl logs` 将返回空。 +比如，一个 10MB 大小的文件，通过`logrotate` 执行轮转后生成两个文件，一个 10MB 大小， +一个为空，所以 `kubectl logs` 将返回空。 {{< /note >}} -[cosConfigureHelper]: https://github.com/kubernetes/kubernetes/blob/{{< param "githubbranch" >}}/cluster/gce/gci/configure-helper.sh - <!-- ### System component logs @@ -186,7 +198,7 @@ that do not run in a container. For example: * The kubelet and container runtime, for example Docker, do not run in containers. --> * 在容器中运行的 kube-scheduler 和 kube-proxy。 -* 不在容器中运行的 kubelet 和容器运行时（例如 Docker。 +* 不在容器中运行的 kubelet 和容器运行时（例如 Docker）。 <!-- On machines with systemd, the kubelet and container runtime write to journald. If @@ -198,8 +210,9 @@ components in the [development docs on logging](https://github.com/kubernetes/co --> 在使用 systemd 机制的服务器上，kubelet 和容器 runtime 写入日志到 journald。 如果没有 systemd，他们写入日志到 `/var/log` 目录的 `.log` 文件。 -容器中的系统组件通常将日志写到 `/var/log` 目录，绕过了默认的日志机制。他们使用 [klog][klog] 日志库。 -您可以在[日志开发文档](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-instrumentation/logging.md)找到这些组件的日志告警级别协议。 +容器中的系统组件通常将日志写到 `/var/log` 目录，绕过了默认的日志机制。他们使用 +[klog](https://github.com/kubernetes/klog) 日志库。 +你可以在[日志开发文档](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-instrumentation/logging.md)找到这些组件的日志告警级别协议。 <!-- Similarly to the container logs, system component logs in the `/var/log` @@ -208,23 +221,21 @@ the `kube-up.sh` script, those logs are configured to be rotated by the `logrotate` tool daily or once the size exceeds 100MB. --> 和容器日志类似，`/var/log` 目录中的系统组件日志也应该被轮转。 -通过脚本 `kube-up.sh` 启动的 Kubernetes 集群中，日志被工具 `logrotate` 执行每日轮转，或者日志大小超过 100MB 时触发轮转。 - -[klog]: https://github.com/kubernetes/klog +通过脚本 `kube-up.sh` 启动的 Kubernetes 集群中，日志被工具 `logrotate` 执行每日轮转， +或者日志大小超过 100MB 时触发轮转。 <!-- ## Cluster-level logging architectures ---> -## 集群级日志架构 -<!-- While Kubernetes does not provide a native solution for cluster-level logging, there are several common approaches you can consider. Here are some options: * Use a node-level logging agent that runs on every node. * Include a dedicated sidecar container for logging in an application pod. * Push logs directly to a backend from within an application. --> -虽然Kubernetes没有为集群级日志记录提供原生的解决方案，但您可以考虑几种常见的方法。以下是一些选项： +## 集群级日志架构 + +虽然Kubernetes没有为集群级日志记录提供原生的解决方案，但你可以考虑几种常见的方法。以下是一些选项： * 使用在每个节点上运行的节点级日志记录代理。 * 在应用程序的 pod 中，包含专门记录日志的 sidecar 容器。 @@ -242,35 +253,41 @@ While Kubernetes does not provide a native solution for cluster-level logging, t <!-- You can implement cluster-level logging by including a _node-level logging agent_ on each node. The logging agent is a dedicated tool that exposes logs or pushes logs to a backend. Commonly, the logging agent is a container that has access to a directory with log files from all of the application containers on that node. --> -您可以通过在每个节点上使用 _节点级的日志记录代理_ 来实现群集级日志记录。日志记录代理是一种用于暴露日志或将日志推送到后端的专用工具。通常，日志记录代理程序是一个容器，它可以访问包含该节点上所有应用程序容器的日志文件的目录。 +你可以通过在每个节点上使用 _节点级的日志记录代理_ 来实现群集级日志记录。 +日志记录代理是一种用于暴露日志或将日志推送到后端的专用工具。 +通常，日志记录代理程序是一个容器，它可以访问包含该节点上所有应用程序容器的日志文件的目录。 <!-- Because the logging agent must run on every node, it's common to implement it as either a DaemonSet replica, a manifest pod, or a dedicated native process on the node. However the latter two approaches are deprecated and highly discouraged. --> -由于日志记录代理必须在每个节点上运行，它可以用 DaemonSet 副本，Pod 或 本机进程来实现。然而，后两种方法被弃用并且非常不别推荐。 +由于日志记录代理必须在每个节点上运行，它可以用 DaemonSet 副本，Pod 或 本机进程来实现。 +然而，后两种方法被弃用并且非常不别推荐。 <!-- Using a node-level logging agent is the most common and encouraged approach for a Kubernetes cluster, because it creates only one agent per node, and it doesn't require any changes to the applications running on the node. However, node-level logging _only works for applications' standard output and standard error_. --> -对于 Kubernetes 集群来说，使用节点级的日志代理是最常用和被推荐的方式，因为在每个节点上仅创建一个代理，并且不需要对节点上的应用做修改。 +对于 Kubernetes 集群来说，使用节点级的日志代理是最常用和被推荐的方式， +因为在每个节点上仅创建一个代理，并且不需要对节点上的应用做修改。 但是，节点级的日志 _仅适用于应用程序的标准输出和标准错误输出_。 <!-- Kubernetes doesn't specify a logging agent, but two optional logging agents are packaged with the Kubernetes release: [Stackdriver Logging](/docs/user-guide/logging/stackdriver) for use with Google Cloud Platform, and [Elasticsearch](/docs/user-guide/logging/elasticsearch). You can find more information and instructions in the dedicated documents. Both use [fluentd](http://www.fluentd.org/) with custom configuration as an agent on the node. --> Kubernetes 并不指定日志代理，但是有两个可选的日志代理与 Kubernetes 发行版一起发布。 -[Stackdriver 日志](/docs/user-guide/logging/stackdriver) 适用于 Google Cloud Platform，和 [Elasticsearch](/docs/user-guide/logging/elasticsearch)。 -您可以在专门的文档中找到更多的信息和说明。两者都使用 [fluentd](http://www.fluentd.org/) 与自定义配置作为节点上的代理。 +[Stackdriver 日志](/zh/docs/tasks/debug-application-cluster/logging-stackdriver/) +适用于 Google Cloud Platform，和 +[Elasticsearch](/zh/docs/tasks/debug-application-cluster/logging-elasticsearch-kibana/)。 +你可以在专门的文档中找到更多的信息和说明。 +两者都使用 [fluentd](https://www.fluentd.org/) 与自定义配置作为节点上的代理。 <!-- ### Using a sidecar container with the logging agent + +You can use a sidecar container in one of the following ways: --> ### 使用 sidecar 容器和日志代理 -<!-- -You can use a sidecar container in one of the following ways: ---> -您可以通过以下方式之一使用 sidecar 容器： +你可以通过以下方式之一使用 sidecar 容器： <!-- * The sidecar container streams application logs to its own `stdout`. @@ -281,10 +298,7 @@ You can use a sidecar container in one of the following ways: <!-- #### Streaming sidecar container ---> -#### 传输数据流的 sidecar 容器 -<!-- ![Sidecar container with a streaming container](/images/docs/user-guide/logging/logging-with-streaming-sidecar.png) By having your sidecar containers stream to their own `stdout` and `stderr` @@ -293,8 +307,14 @@ already run on each node. The sidecar containers read logs from a file, a socket or the journald. Each individual sidecar container prints log to its own `stdout` or `stderr` stream. --> -利用 sidecar 容器向自己的 `stdout` 和 `stderr` 传输流的方式，您就可以利用每个节点上的 kubelet 和日志代理来处理日志。 -sidecar 容器从文件，socket 或 journald 读取日志。每个 sidecar 容器打印其自己的 `stdout` 和 `stderr` 流。 +#### 传输数据流的 sidecar 容器 + +![数据流容器的 Sidecar 容器](/images/docs/user-guide/logging/logging-with-streaming-sidecar.png) + +利用 sidecar 容器向自己的 `stdout` 和 `stderr` 传输流的方式， +你就可以利用每个节点上的 kubelet 和日志代理来处理日志。 +sidecar 容器从文件、套接字或 journald 读取日志。 +每个 sidecar 容器打印其自己的 `stdout` 和 `stderr` 流。 <!-- This approach allows you to separate several log streams from different @@ -304,7 +324,8 @@ is minimal, so it's hardly a significant overhead. Additionally, because `stdout` and `stderr` are handled by the kubelet, you can use built-in tools like `kubectl logs`. --> -这种方法允许您将日志流从应用程序的不同部分分离开，其中一些可能缺乏对写入 `stdout` 或 `stderr` 的支持。重定向日志背后的逻辑是最小的，因此它的开销几乎可以忽略不计。 +这种方法允许你将日志流从应用程序的不同部分分离开，其中一些可能缺乏对写入 +`stdout` 或 `stderr` 的支持。重定向日志背后的逻辑是最小的，因此它的开销几乎可以忽略不计。 另外，因为 `stdout`、`stderr` 由 kubelet 处理，你可以使用内置的工具 `kubectl logs`。 <!-- @@ -323,14 +344,14 @@ the container. Instead, you could introduce two sidecar containers. Each sidecar container could tail a particular log file from a shared volume and then redirect the logs to its own `stdout` stream. --> -在同一个日志流中有两种不同格式的日志条目，这有点混乱，即使您试图重定向它们到容器的 `stdout` 流。 -取而代之的是，您可以引入两个 sidecar 容器。 +在同一个日志流中有两种不同格式的日志条目，这有点混乱，即使你试图重定向它们到容器的 `stdout` 流。 +取而代之的是，你可以引入两个 sidecar 容器。 每一个 sidecar 容器可以从共享卷跟踪特定的日志文件，并重定向文件内容到各自的 `stdout` 流。 <!-- Here's a configuration file for a pod that has two sidecar containers: --> -这是运行两个 sidecar 容器的 pod 文件。 +这是运行两个 sidecar 容器的 Pod 文件。 {{< codenew file="admin/logging/two-files-counter-pod-streaming-sidecar.yaml" >}} @@ -338,7 +359,7 @@ Here's a configuration file for a pod that has two sidecar containers: Now when you run this pod, you can access each log stream separately by running the following commands: --> -现在当您运行这个 pod 时，您可以分别地访问每一个日志流，运行如下命令： +现在当你运行这个 Pod 时，你可以分别地访问每一个日志流，运行如下命令： ```shell kubectl logs counter count-log-1 @@ -365,7 +386,7 @@ The node-level agent installed in your cluster picks up those log streams automatically without any further configuration. If you like, you can configure the agent to parse log lines depending on the source container. --> -集群中安装的节点级代理会自动获取这些日志流，而无需进一步配置。如果您愿意，您可以配置代理程序来解析源容器的日志行。 +集群中安装的节点级代理会自动获取这些日志流，而无需进一步配置。如果你愿意，你可以配置代理程序来解析源容器的日志行。 <!-- Note, that despite low CPU and memory usage (order of couple of millicores @@ -377,7 +398,7 @@ container approach. --> 注意，尽管 CPU 和内存使用率都很低（以多个 cpu millicores 指标排序或者按内存的兆字节排序）， 向文件写日志然后输出到 `stdout` 流仍然会成倍地增加磁盘使用率。 -如果您的应用向单一文件写日志，通常最好设置 `/dev/stdout` 作为目标路径，而不是使用流式的 sidecar 容器方式。 +如果你的应用向单一文件写日志，通常最好设置 `/dev/stdout` 作为目标路径，而不是使用流式的 sidecar 容器方式。 <!-- Sidecar containers can also be used to rotate log files that cannot be @@ -404,7 +425,8 @@ If the node-level logging agent is not flexible enough for your situation, you can create a sidecar container with a separate logging agent that you have configured specifically to run with your application. --> -如果节点级日志记录代理程序对于你的场景来说不够灵活，您可以创建一个带有单独日志记录代理程序的 sidecar 容器，将代理程序专门配置为与您的应用程序一起运行。 +如果节点级日志记录代理程序对于你的场景来说不够灵活，你可以创建一个带有单独日志记录代理程序的 +sidecar 容器，将代理程序专门配置为与你的应用程序一起运行。 <!-- {{< note >}} @@ -415,7 +437,8 @@ by the kubelet. {{< /note >}} --> {{< note >}} -在 sidecar 容器中使用日志代理会导致严重的资源损耗。此外，您不能使用 `kubectl logs` 命令访问日志，因为日志并没有被 kubelet 管理。 +在 sidecar 容器中使用日志代理会导致严重的资源损耗。 +此外，你不能使用 `kubectl logs` 命令访问日志，因为日志并没有被 kubelet 管理。 {{< /note >}} <!-- @@ -424,9 +447,11 @@ which uses fluentd as a logging agent. Here are two configuration files that you can use to implement this approach. The first file contains a [ConfigMap](/docs/tasks/configure-pod-container/configure-pod-configmap/) to configure fluentd. --> -例如，您可以使用 [Stackdriver](/docs/tasks/debug-application-cluster/logging-stackdriver/)，它使用fluentd作为日志记录代理。 +例如，你可以使用 [Stackdriver](/zh/docs/tasks/debug-application-cluster/logging-stackdriver/)， +它使用 fluentd 作为日志记录代理。 以下是两个可用于实现此方法的配置文件。 -第一个文件包含配置 fluentd 的[ConfigMap](/docs/tasks/configure-pod-container/configure-pod-configmap/)。 +第一个文件包含配置 fluentd 的 +[ConfigMap](/zh/docs/tasks/configure-pod-container/configure-pod-configmap/)。 {{< codenew file="admin/logging/fluentd-sidecar-config.yaml" >}} @@ -438,28 +463,29 @@ information about configuring fluentd, see the {{< /note >}} --> {{< note >}} -配置fluentd超出了本文的范围。要知道更多的关于如何配置fluentd，请参考[fluentd 官方文档](http://docs.fluentd.org/). +配置 fluentd 超出了本文的范围。要进一步了解如何配置 fluentd， +请参考 [fluentd 官方文档](https://docs.fluentd.org/). {{< /note >}} <!-- The second file describes a pod that has a sidecar container running fluentd. The pod mounts a volume where fluentd can pick up its configuration data. --> -第二个文件描述了运行 fluentd sidecar 容器的 pod 。flutend 通过 pod 的挂载卷获取它的配置数据。 +第二个文件描述了运行 fluentd sidecar 容器的 Pod 。flutend 通过 Pod 的挂载卷获取它的配置数据。 {{< codenew file="admin/logging/two-files-counter-pod-agent-sidecar.yaml" >}} <!-- After some time you can find log messages in the Stackdriver interface. --> -一段时间后，您可以在 Stackdriver 界面看到日志消息。 +一段时间后，你可以在 Stackdriver 界面看到日志消息。 <!-- Remember, that this is just an example and you can actually replace fluentd with any logging agent, reading from any source inside an application container. --> -记住，这只是一个例子，事实上您可以用任何一个日志代理替换 fluentd ，并从应用容器中读取任何资源。 +记住，这只是一个例子，事实上你可以用任何一个日志代理替换 fluentd ，并从应用容器中读取任何资源。 <!-- ### Exposing logs directly from the application @@ -476,6 +502,7 @@ You can implement cluster-level logging by exposing or pushing logs directly fro every application; however, the implementation for such a logging mechanism is outside the scope of Kubernetes. --> -通过暴露或推送每个应用的日志，您可以实现集群级日志记录；然而，这种日志记录机制的实现已超出 Kubernetes 的范围。 +通过暴露或推送每个应用的日志，你可以实现集群级日志记录； +然而，这种日志记录机制的实现已超出 Kubernetes 的范围。 diff --git a/content/zh/docs/concepts/cluster-administration/manage-deployment.md b/content/zh/docs/concepts/cluster-administration/manage-deployment.md index 55caa7b8d7..cc2224db49 100644 --- a/content/zh/docs/concepts/cluster-administration/manage-deployment.md +++ b/content/zh/docs/concepts/cluster-administration/manage-deployment.md @@ -9,21 +9,24 @@ weight: 40 <!-- You've deployed your application and exposed it via a service. Now what? Kubernetes provides a number of tools to help you manage your application deployment, including scaling and updating. Among the features that we will discuss in more depth are [configuration files](/docs/concepts/configuration/overview/) and [labels](/docs/concepts/overview/working-with-objects/labels/). --> -您已经部署了应用并通过服务暴露它。然后呢？Kubernetes 提供了一些工具来帮助管理您的应用部署，包括缩扩容和更新。我们将更深入讨论的特性包括[配置文件](/docs/concepts/configuration/overview/)和[标签](/docs/concepts/overview/working-with-objects/labels/)。 - - - +你已经部署了应用并通过服务暴露它。然后呢？ +Kubernetes 提供了一些工具来帮助管理你的应用部署，包括扩缩容和更新。 +我们将更深入讨论的特性包括 +[配置文件](/zh/docs/concepts/configuration/overview/)和 +[标签](/zh/docs/concepts/overview/working-with-objects/labels/)。 <!-- body --> <!-- ## Organizing resource configurations -Many applications require multiple resources to be created, such as a Deployment and a Service. Management of multiple resources can be simplified by grouping them together in the same file (separated by `---` in YAML). For example: +Many applications require multiple resources to be created, such as a Deployment and a Service. Management of multiple resources can be simplified by grouping them together in the same file (separated by in YAML). For example: --> ## 组织资源配置 -许多应用需要创建多个资源，例如 Deployment 和 Service。可以通过将多个资源组合在同一个文件中（在 YAML 中以 `---` 分隔）来简化对它们的管理。例如： +许多应用需要创建多个资源，例如 Deployment 和 Service。 +可以通过将多个资源组合在同一个文件中（在 YAML 中以 `---` 分隔） +来简化对它们的管理。例如： {{< codenew file="application/nginx-app.yaml" >}} @@ -36,7 +39,7 @@ Multiple resources can be created the same way as a single resource: kubectl apply -f https://k8s.io/examples/application/nginx-app.yaml ``` -```shell +``` service/my-nginx-svc created deployment.apps/my-nginx created ``` @@ -44,7 +47,9 @@ deployment.apps/my-nginx created <!-- The resources will be created in the order they appear in the file. Therefore, it's best to specify the service first, since that will ensure the scheduler can spread the pods associated with the service as they are created by the controller(s), such as Deployment. --> -资源将按照它们在文件中的顺序创建。因此，最好先指定服务，这样在控制器（例如 Deployment）创建 Pod 时能够确保调度器可以将与服务关联的多个 Pod 分散到不同节点。 +资源将按照它们在文件中的顺序创建。 +因此，最好先指定服务，这样在控制器（例如 Deployment）创建 Pod 时能够 +确保调度器可以将与服务关联的多个 Pod 分散到不同节点。 <!-- `kubectl apply` also accepts multiple `-f` arguments: @@ -71,9 +76,11 @@ It is a recommended practice to put resources related to the same microservice o A URL can also be specified as a configuration source, which is handy for deploying directly from configuration files checked into github: --> -`kubectl` 将读取任何后缀为 `.yaml`，`.yml` 或者 `.json` 的文件。 +`kubectl` 将读取任何后缀为 `.yaml`、`.yml` 或者 `.json` 的文件。 -建议的做法是，将同一个微服务或同一应用层相关的资源放到同一个文件中，将同一个应用相关的所有文件按组存放到同一个目录中。如果应用的各层使用 DNS 相互绑定，那么您可以简单地将堆栈的所有组件一起部署。 +建议的做法是，将同一个微服务或同一应用层相关的资源放到同一个文件中， +将同一个应用相关的所有文件按组存放到同一个目录中。 +如果应用的各层使用 DNS 相互绑定，那么你可以简单地将堆栈的所有组件一起部署。 还可以使用 URL 作为配置源，便于直接使用已经提交到 Github 上的配置文件进行部署： @@ -81,7 +88,7 @@ A URL can also be specified as a configuration source, which is handy for deploy kubectl apply -f https://raw.githubusercontent.com/kubernetes/website/master/content/zh/examples/application/nginx/nginx-deployment.yaml ``` -```shell +``` deployment.apps/my-nginx created ``` @@ -92,13 +99,15 @@ Resource creation isn't the only operation that `kubectl` can perform in bulk. I --> ## kubectl 中的批量操作 -资源创建并不是 `kubectl` 可以批量执行的唯一操作。`kubectl` 还可以从配置文件中提取资源名，以便执行其他操作，特别是删除您之前创建的资源： +资源创建并不是 `kubectl` 可以批量执行的唯一操作。 +`kubectl` 还可以从配置文件中提取资源名，以便执行其他操作， +特别是删除你之前创建的资源： ```shell kubectl delete -f https://k8s.io/examples/application/nginx-app.yaml ``` -```shell +``` deployment.apps "my-nginx" deleted service "my-nginx-svc" deleted ``` @@ -115,13 +124,14 @@ kubectl delete deployments/my-nginx services/my-nginx-svc <!-- For larger numbers of resources, you'll find it easier to specify the selector (label query) specified using `-l` or `--selector`, to filter resources by their labels: --> -对于资源数目较大的情况，您会发现使用 `-l` 或 `--selector` 指定的筛选器（标签查询）能很容易根据标签筛选资源： +对于资源数目较大的情况，你会发现使用 `-l` 或 `--selector` +指定筛选器（标签查询）能很容易根据标签筛选资源： ```shell kubectl delete deployment,services -l app=nginx ``` -```shell +``` deployment.apps "my-nginx" deleted service "my-nginx-svc" deleted ``` @@ -129,13 +139,14 @@ service "my-nginx-svc" deleted <!-- Because `kubectl` outputs resource names in the same syntax it accepts, it's easy to chain operations using `$()` or `xargs`: --> -由于 `kubectl` 用来输出资源名称的语法与其所接受的资源名称语法相同，所以很容易使用 `$()` 或 `xargs` 进行链式操作： +由于 `kubectl` 用来输出资源名称的语法与其所接受的资源名称语法相同， +所以很容易使用 `$()` 或 `xargs` 进行链式操作： ```shell kubectl get $(kubectl create -f docs/concepts/cluster-administration/nginx/ -o name | grep service) ``` -```shell +``` NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE my-nginx-svc LoadBalancer 10.0.0.208 <pending> 80/TCP 0s ``` @@ -144,17 +155,21 @@ my-nginx-svc LoadBalancer 10.0.0.208 <pending> 80/TCP 0s With the above commands, we first create resources under `examples/application/nginx/` and print the resources created with `-o name` output format (print each resource as resource/name). Then we `grep` only the "service", and then print it with `kubectl get`. --> -上面的命令中，我们首先使用 `examples/application/nginx/` 下的配置文件创建资源，并使用 `-o name` 的输出格式（以"资源/名称"的形式打印每个资源）打印所创建的资源。然后，我们通过 `grep` 来过滤 "service"，最后再打印 `kubectl get` 的内容。 +上面的命令中，我们首先使用 `examples/application/nginx/` 下的配置文件创建资源， +并使用 `-o name` 的输出格式（以"资源/名称"的形式打印每个资源）打印所创建的资源。 +然后，我们通过 `grep` 来过滤 "service"，最后再打印 `kubectl get` 的内容。 <!-- If you happen to organize your resources across several subdirectories within a particular directory, you can recursively perform the operations on the subdirectories also, by specifying `--recursive` or `-R` alongside the `--filename,-f` flag. --> -如果您碰巧在某个路径下的多个子路径中组织资源，那么也可以递归地在所有子路径上执行操作，方法是在 `--filename,-f` 后面指定 `--recursive` 或者 `-R`。 +如果你碰巧在某个路径下的多个子路径中组织资源，那么也可以递归地在所有子路径上 +执行操作，方法是在 `--filename,-f` 后面指定 `--recursive` 或者 `-R`。 <!-- For instance, assume there is a directory `project/k8s/development` that holds all of the manifests needed for the development environment, organized by resource type: --> -例如，假设有一个目录路径为 `project/k8s/development`，它保存开发环境所需的所有清单，并按资源类型组织： +例如，假设有一个目录路径为 `project/k8s/development`，它保存开发环境所需的 +所有清单，并按资源类型组织： ``` project/k8s/development @@ -176,20 +191,20 @@ By default, performing a bulk operation on `project/k8s/development` will stop a kubectl apply -f project/k8s/development ``` -```shell +``` error: you must provide one or more resources by argument or filename (.json|.yaml|.yml|stdin) ``` <!-- Instead, specify the `--recursive` or `-R` flag with the `--filename,-f` flag as such: --> -然而，在 `--filename,-f` 后面标明 `--recursive` 或者 `-R` 之后： +正确的做法是，在 `--filename,-f` 后面标明 `--recursive` 或者 `-R` 之后： ```shell kubectl apply -f project/k8s/development --recursive ``` -```shell +``` configmap/my-config created deployment.apps/my-deployment created persistentvolumeclaim/my-pvc created @@ -200,7 +215,8 @@ The `--recursive` flag works with any operation that accepts the `--filename,-f` The `--recursive` flag also works when multiple `-f` arguments are provided: --> -`--recursive` 可以用于接受 `--filename,-f` 参数的任何操作，例如：`kubectl {create,get,delete,describe,rollout}` 等。 +`--recursive` 可以用于接受 `--filename,-f` 参数的任何操作，例如： +`kubectl {create,get,delete,describe,rollout}` 等。 有多个 `-f` 参数出现的时候，`--recursive` 参数也能正常工作： @@ -208,7 +224,7 @@ The `--recursive` flag also works when multiple `-f` arguments are provided: kubectl apply -f project/k8s/namespaces -f project/k8s/development --recursive ``` -```shell +``` namespace/development created namespace/staging created configmap/my-config created @@ -219,7 +235,8 @@ persistentvolumeclaim/my-pvc created <!-- If you're interested in learning more about `kubectl`, go ahead and read [kubectl Overview](/docs/reference/kubectl/overview/). --> -如果您有兴趣学习更多关于 `kubectl` 的内容，请阅读 [kubectl 概述](/docs/reference/kubectl/overview/)。 +如果你有兴趣进一步学习关于 `kubectl` 的内容，请阅读 +[kubectl 概述](/zh/docs/reference/kubectl/overview/)。 <!-- ## Using labels effectively @@ -228,7 +245,8 @@ The examples we've used so far apply at most a single label to any resource. The --> ## 有效地使用标签 -到目前为止我们使用的示例中的资源最多使用了一个标签。在许多情况下，应使用多个标签来区分集合。 +到目前为止我们使用的示例中的资源最多使用了一个标签。 +在许多情况下，应使用多个标签来区分集合。 <!-- For instance, different applications would use different values for the `app` label, but a multi-tier application, such as the [guestbook example](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/guestbook/), would additionally need to distinguish each tier. The frontend could carry the following labels: @@ -254,9 +272,7 @@ Redis 的主节点和从节点会有不同的 `tier` 标签，甚至还有一个 role: master ``` -<!-- -and - --> +<!-- and --> 以及 ```yaml @@ -276,7 +292,7 @@ kubectl apply -f examples/guestbook/all-in-one/guestbook-all-in-one.yaml kubectl get pods -Lapp -Ltier -Lrole ``` -```shell +``` NAME READY STATUS RESTARTS AGE APP TIER ROLE guestbook-fe-4nlpb 1/1 Running 0 1m guestbook frontend <none> guestbook-fe-ght6d 1/1 Running 0 1m guestbook frontend <none> @@ -291,7 +307,8 @@ my-nginx-o0ef1 1/1 Running 0 29m nginx ```shell kubectl get pods -lapp=guestbook,role=slave ``` -```shell + +``` NAME READY STATUS RESTARTS AGE guestbook-redis-slave-2q2yf 1/1 Running 0 3m guestbook-redis-slave-qgazl 1/1 Running 0 3m @@ -299,20 +316,22 @@ guestbook-redis-slave-qgazl 1/1 Running 0 3m <!-- ## Canary deployments - --> -## 金丝雀部署 -<!-- Another scenario where multiple labels are needed is to distinguish deployments of different releases or configurations of the same component. It is common practice to deploy a *canary* of a new application release (specified via image tag in the pod template) side by side with the previous release so that the new release can receive live production traffic before fully rolling it out. --> -另一个需要多标签的场景是用来区分同一组件的不同版本或者不同配置的多个部署。常见的做法是部署一个使用*金丝雀发布*来部署新应用版本（在 pod 模板中通过镜像标签指定），保持新旧版本应用同时运行，这样，新版本在完全发布之前也可以接收实时的生产流量。 +## 金丝雀部署（Canary Deployments） {#canary-deployments} + +另一个需要多标签的场景是用来区分同一组件的不同版本或者不同配置的多个部署。 +常见的做法是部署一个使用*金丝雀发布*来部署新应用版本 +（在 Pod 模板中通过镜像标签指定），保持新旧版本应用同时运行。 +这样，新版本在完全发布之前也可以接收实时的生产流量。 <!-- For instance, you can use a `track` label to differentiate different releases. The primary, stable release would have a `track` label with value as `stable`: --> -例如，您可以使用 `track` 标签来区分不同的版本。 +例如，你可以使用 `track` 标签来区分不同的版本。 主要稳定的发行版将有一个 `track` 标签，其值为 `stable`： @@ -331,7 +350,8 @@ The primary, stable release would have a `track` label with value as `stable`: <!-- and then you can create a new release of the guestbook frontend that carries the `track` label with different value (i.e. `canary`), so that two sets of pods would not overlap: --> -然后，您可以创建 guestbook 前端的新版本，让这些版本的 `track` 标签带有不同的值（即 `canary`），以便两组 pod 不会重叠： +然后，你可以创建 guestbook 前端的新版本，让这些版本的 `track` 标签带有不同的值 +（即 `canary`），以便两组 Pod 不会重叠： ```yaml name: frontend-canary @@ -360,7 +380,7 @@ The frontend service would span both sets of replicas by selecting the common su You can tweak the number of replicas of the stable and canary releases to determine the ratio of each release that will receive live production traffic (in this case, 3:1). Once you're confident, you can update the stable track to the new application release and remove the canary one. --> -您可以调整 `stable` 和 `canary` 版本的副本数量，以确定每个版本将接收实时生产流量的比例(在本例中为 3:1)。一旦有信心，您就可以将新版本应用的 `track` 标签的值从 `canary` 替换为 `stable`，并且将老版本应用删除。 +你可以调整 `stable` 和 `canary` 版本的副本数量，以确定每个版本将接收实时生产流量的比例(在本例中为 3:1)。一旦有信心，你就可以将新版本应用的 `track` 标签的值从 `canary` 替换为 `stable`，并且将老版本应用删除。 <!-- For a more concrete example, check the [tutorial of deploying Ghost](https://github.com/kelseyhightower/talks/tree/master/kubecon-eu-2016/demo#deploy-a-canary). @@ -373,16 +393,17 @@ For a more concrete example, check the [tutorial of deploying Ghost](https://git Sometimes existing pods and other resources need to be relabeled before creating new resources. This can be done with `kubectl label`. For example, if you want to label all your nginx pods as frontend tier, simply run: --> -## 更新标签 +## 更新标签 {#updating-labels} -有时，现有的 pod 和其它资源需要在创建新资源之前重新标记。这可以用 `kubectl label` 完成。 +有时，现有的 pod 和其它资源需要在创建新资源之前重新标记。 +这可以用 `kubectl label` 完成。 例如，如果想要将所有 nginx pod 标记为前端层，只需运行： ```shell kubectl label pods -l app=nginx tier=fe ``` -```shell +``` pod/my-nginx-2035384211-j5fhi labeled pod/my-nginx-2035384211-u2c7e labeled pod/my-nginx-2035384211-u3t6x labeled @@ -392,12 +413,14 @@ pod/my-nginx-2035384211-u3t6x labeled This first filters all pods with the label "app=nginx", and then labels them with the "tier=fe". To see the pods you just labeled, run: --> -首先用标签 "app=nginx" 过滤所有的 pod，然后用 "tier=fe" 标记它们。想要查看您刚才标记的 pod，请运行： +首先用标签 "app=nginx" 过滤所有的 Pod，然后用 "tier=fe" 标记它们。 +想要查看你刚才标记的 Pod，请运行： ```shell kubectl get pods -l app=nginx -L tier ``` -```shell + +``` NAME READY STATUS RESTARTS AGE TIER my-nginx-2035384211-j5fhi 1/1 Running 0 23m fe my-nginx-2035384211-u2c7e 1/1 Running 0 23m fe @@ -409,18 +432,22 @@ This outputs all "app=nginx" pods, with an additional label column of pods' tier For more information, please see [labels](/docs/concepts/overview/working-with-objects/labels/) and [kubectl label](/docs/reference/generated/kubectl/kubectl-commands/#label). --> -这将输出所有 "app=nginx" 的 pod，并有一个额外的描述 pod 的 tier 的标签列（用参数 `-L` 或者 `--label-columns` 标明）。 +这将输出所有 "app=nginx" 的 Pod，并有一个额外的描述 Pod 的 tier 的标签列 +（用参数 `-L` 或者 `--label-columns` 标明）。 -想要了解更多信息，请参考 [标签](/docs/concepts/overview/working-with-objects/labels/) 和 [kubectl label](/docs/reference/generated/kubectl/kubectl-commands/#label)。 +想要了解更多信息，请参考 +[标签](/zh/docs/concepts/overview/working-with-objects/labels/) 和 +[`kubectl label`](/docs/reference/generated/kubectl/kubectl-commands/#label) +命令文档。 <!-- ## Updating annotations Sometimes you would want to attach annotations to resources. Annotations are arbitrary non-identifying metadata for retrieval by API clients such as tools, libraries, etc. This can be done with `kubectl annotate`. For example: --> -## 更新注解 +## 更新注解 {#updating-annotations} -有时，您可能希望将注解附加到资源中。注解是 API 客户端（如工具、库等）用于检索的任意非标识元数据。这可以通过 `kubectl annotate` 来完成。例如： +有时，你可能希望将注解附加到资源中。注解是 API 客户端（如工具、库等）用于检索的任意非标识元数据。这可以通过 `kubectl annotate` 来完成。例如： ```shell kubectl annotate pods my-nginx-v4-9gw19 description='my frontend running nginx' @@ -438,33 +465,38 @@ metadata: <!-- For more information, please see [annotations](/docs/concepts/overview/working-with-objects/annotations/) and [kubectl annotate](/docs/reference/generated/kubectl/kubectl-commands/#annotate) document. --> -想要了解更多信息，请参考 [注解](/docs/concepts/overview/working-with-objects/annotations/) 和 [kubectl annotate](/docs/reference/generated/kubectl/kubectl-commands/#annotate) 文档。 +想要了解更多信息，请参考 +[注解](/zh/docs/concepts/overview/working-with-objects/annotations/)和 +[`kubectl annotate`](/docs/reference/generated/kubectl/kubectl-commands/#annotate) +命令文档。 <!-- ## Scaling your application When load on your application grows or shrinks, it's easy to scale with `kubectl`. For instance, to decrease the number of nginx replicas from 3 to 1, do: --> -## 缩扩您的应用 +## 扩缩你的应用 -当应用上的负载增长或收缩时，使用 `kubectl` 能够轻松实现规模的缩扩。例如，要将 nginx 副本的数量从 3 减少到 1，请执行以下操作： +当应用上的负载增长或收缩时，使用 `kubectl` 能够轻松实现规模的扩缩。 +例如，要将 nginx 副本的数量从 3 减少到 1，请执行以下操作： ```shell kubectl scale deployment/my-nginx --replicas=1 ``` -```shell + +``` deployment.extensions/my-nginx scaled ``` <!-- Now you only have one pod managed by the deployment. --> -现在，您的 deployment 管理的 pod 只有一个了。 +现在，你的 Deployment 管理的 Pod 只有一个了。 ```shell kubectl get pods -l app=nginx ``` -```shell +``` NAME READY STATUS RESTARTS AGE my-nginx-2035384211-j5fhi 1/1 Running 0 30m ``` @@ -477,7 +509,8 @@ To have the system automatically choose the number of nginx replicas as needed, ```shell kubectl autoscale deployment/my-nginx --min=1 --max=3 ``` -```shell + +``` horizontalpodautoscaler.autoscaling/my-nginx autoscaled ``` @@ -486,9 +519,12 @@ Now your nginx replicas will be scaled up and down as needed, automatically. For more information, please see [kubectl scale](/docs/reference/generated/kubectl/kubectl-commands/#scale), [kubectl autoscale](/docs/reference/generated/kubectl/kubectl-commands/#autoscale) and [horizontal pod autoscaler](/docs/tasks/run-application/horizontal-pod-autoscale/) document. --> -现在，您的 nginx 副本将根据需要自动地增加或者减少。 +现在，你的 nginx 副本将根据需要自动地增加或者减少。 -想要了解更多信息，请参考 [kubectl scale](/docs/reference/generated/kubectl/kubectl-commands/#scale), [kubectl autoscale](/docs/reference/generated/kubectl/kubectl-commands/#autoscale) 和 [pod 水平自动伸缩](/docs/tasks/run-application/horizontal-pod-autoscale/) 文档。 +想要了解更多信息，请参考 +[kubectl scale](/docs/reference/generated/kubectl/kubectl-commands/#scale)命令文档、 +[kubectl autoscale](/docs/reference/generated/kubectl/kubectl-commands/#autoscale) 命令文档和 +[水平 Pod 自动伸缩](/zh/docs/tasks/run-application/horizontal-pod-autoscale/) 文档。 <!-- ## In-place updates of resources @@ -497,7 +533,7 @@ Sometimes it's necessary to make narrow, non-disruptive updates to resources you --> ## 就地更新资源 -有时，有必要对您所创建的资源进行小范围、无干扰地更新。 +有时，有必要对你所创建的资源进行小范围、无干扰地更新。 ### kubectl apply @@ -506,12 +542,15 @@ It is suggested to maintain a set of configuration files in source control (see so that they can be maintained and versioned along with the code for the resources they configure. Then, you can use [`kubectl apply`](/docs/reference/generated/kubectl/kubectl-commands/#apply) to push your configuration changes to the cluster. --> -建议在源代码管理中维护一组配置文件（参见[配置即代码](http://martinfowler.com/bliki/InfrastructureAsCode.html)），这样，它们就可以和应用代码一样进行维护和版本管理。然后，您可以用 [`kubectl apply`](/docs/reference/generated/kubectl/kubectl-commands/#apply) 将配置变更应用到集群中。 +建议在源代码管理中维护一组配置文件 +（参见[配置即代码](https://martinfowler.com/bliki/InfrastructureAsCode.html)）， +这样，它们就可以和应用代码一样进行维护和版本管理。 +然后，你可以用 [`kubectl apply`](/docs/reference/generated/kubectl/kubectl-commands/#apply) 将配置变更应用到集群中。 <!-- This command will compare the version of the configuration that you're pushing with the previous version and apply the changes you've made, without overwriting any automated changes to properties you haven't specified. --> -这个命令将会把推送的版本与以前的版本进行比较，并应用您所做的更改，但是不会自动覆盖任何你没有指定更改的属性。 +这个命令将会把推送的版本与以前的版本进行比较，并应用你所做的更改，但是不会自动覆盖任何你没有指定更改的属性。 ```shell kubectl apply -f https://k8s.io/examples/application/nginx/nginx-deployment.yaml @@ -534,9 +573,7 @@ All subsequent calls to `kubectl apply`, and other commands that modify the conf 所有后续调用 `kubectl apply` 以及其它修改配置的命令，如 `kubectl replace` 和 `kubectl edit`，都将更新注解，并允许随后调用的 `kubectl apply` 使用三方差异进行检查和执行删除。 <!-- -{{< note >}} To use apply, always create resource initially with either `kubectl apply` or `kubectl create --save-config`. -{{< /note >}} --> {{< note >}} 想要使用 apply，请始终使用 `kubectl apply` 或 `kubectl create --save-config` 创建资源。 @@ -547,7 +584,7 @@ To use apply, always create resource initially with either `kubectl apply` or `k <!-- Alternatively, you may also update resources with `kubectl edit`: --> -或者，您也可以使用 `kubectl edit` 更新资源： +或者，你也可以使用 `kubectl edit` 更新资源： ```shell kubectl edit deployment/my-nginx @@ -569,13 +606,12 @@ deployment.apps/my-nginx configured rm /tmp/nginx.yaml ``` - <!-- This allows you to do more significant changes more easily. Note that you can specify the editor with your `EDITOR` or `KUBE_EDITOR` environment variables. For more information, please see [kubectl edit](/docs/reference/generated/kubectl/kubectl-commands/#edit) document. --> -这使您可以更加容易地进行更重大的更改。请注意，可以使用 `EDITOR` 或 `KUBE_EDITOR` 环境变量来指定编辑器。 +这使你可以更加容易地进行更重大的更改。请注意，可以使用 `EDITOR` 或 `KUBE_EDITOR` 环境变量来指定编辑器。 想要了解更多信息，请参考 [kubectl edit](/docs/reference/generated/kubectl/kubectl-commands/#edit) 文档。 @@ -588,8 +624,8 @@ JSON merge patch, and strategic merge patch. See and [kubectl patch](/docs/reference/generated/kubectl/kubectl-commands/#patch). --> -您可以使用 `kubectl patch` 来更新 API 对象。此命令支持 JSON patch，JSON merge patch，以及 strategic merge patch。 请参考 -[使用 kubectl patch 更新 API 对象](/docs/tasks/run-application/update-api-object-kubectl-patch/) +你可以使用 `kubectl patch` 来更新 API 对象。此命令支持 JSON patch，JSON merge patch，以及 strategic merge patch。 请参考 +[使用 kubectl patch 更新 API 对象](/zh/docs/tasks/run-application/update-api-object-kubectl-patch/) 和 [kubectl patch](/docs/reference/generated/kubectl/kubectl-commands/#patch). @@ -598,14 +634,15 @@ and In some cases, you may need to update resource fields that cannot be updated once initialized, or you may just want to make a recursive change immediately, such as to fix broken pods created by a Deployment. To change such fields, use `replace --force`, which deletes and re-creates the resource. In this case, you can simply modify your original configuration file: --> -## 破坏性的更新 +## 破坏性的更新 {#disruptive-updates} -在某些情况下，您可能需要更新某些初始化后无法更新的资源字段，或者您可能只想立即进行递归更改，例如修复 Deployment 创建的不正常的 Pod。若要更改这些字段，请使用 `replace --force`，它将删除并重新创建资源。在这种情况下，您可以简单地修改原始配置文件： +在某些情况下，你可能需要更新某些初始化后无法更新的资源字段，或者你可能只想立即进行递归更改，例如修复 Deployment 创建的不正常的 Pod。若要更改这些字段，请使用 `replace --force`，它将删除并重新创建资源。在这种情况下，你可以简单地修改原始配置文件： ```shell kubectl replace -f https://k8s.io/examples/application/nginx/nginx-deployment.yaml --force ``` -```shell + +``` deployment.apps/my-nginx deleted deployment.apps/my-nginx replaced ``` @@ -618,29 +655,30 @@ deployment.apps/my-nginx replaced <!-- At some point, you'll eventually need to update your deployed application, typically by specifying a new image or image tag, as in the canary deployment scenario above. `kubectl` supports several update operations, each of which is applicable to different scenarios. --> -在某些时候，您最终需要更新已部署的应用，通常都是通过指定新的镜像或镜像标签，如上面的金丝雀发布的场景中所示。`kubectl` 支持几种更新操作，每种更新操作都适用于不同的场景。 +在某些时候，你最终需要更新已部署的应用，通常都是通过指定新的镜像或镜像标签，如上面的金丝雀发布的场景中所示。`kubectl` 支持几种更新操作，每种更新操作都适用于不同的场景。 <!-- We'll guide you through how to create and update applications with Deployments. --> -我们将指导您通过 Deployment 如何创建和更新应用。 +我们将指导你通过 Deployment 如何创建和更新应用。 <!-- -Let's say you were running version 1.7.9 of nginx: +Let's say you were running version 1.14.2 of nginx: --> -假设您正运行的是 1.7.9 版本的 nginx： +假设你正运行的是 1.14.2 版本的 nginx： ```shell -kubectl create deployment my-nginx --image=nginx:1.7.9 +kubectl create deployment my-nginx --image=nginx:1.14.2 +``` ``` -```shell deployment.apps/my-nginx created ``` <!-- -To update to version 1.9.1, simply change `.spec.template.spec.containers[0].image` from `nginx:1.7.9` to `nginx:1.9.1`, with the kubectl commands we learned above. +To update to version 1.16.1, simply change `.spec.template.spec.containers[0].image` from `nginx:1.14.2` to `nginx:1.16.1`, with the kubectl commands we learned above. --> -要更新到 1.9.1 版本，只需使用我们前面学到的 kubectl 命令将 `.spec.template.spec.containers[0].image` 从 `nginx:1.7.9` 修改为 `nginx:1.9.1`。 +要更新到 1.16.1 版本，只需使用我们前面学到的 kubectl 命令将 +`.spec.template.spec.containers[0].image` 从 `nginx:1.14.2` 修改为 `nginx:1.16.1`。 ```shell kubectl edit deployment/my-nginx @@ -649,18 +687,16 @@ kubectl edit deployment/my-nginx <!-- That's it! The Deployment will declaratively update the deployed nginx application progressively behind the scene. It ensures that only a certain number of old replicas may be down while they are being updated, and only a certain number of new replicas may be created above the desired number of pods. To learn more details about it, visit [Deployment page](/docs/concepts/workloads/controllers/deployment/). --> -没错，就是这样！Deployment 将在后台逐步更新已经部署的 nginx 应用。它确保在更新过程中，只有一定数量的旧副本被开闭，并且只有一定基于所需 pod 数量的新副本被创建。想要了解更多细节，请参考 [Deployment](/docs/concepts/workloads/controllers/deployment/)。 - - +没错，就是这样！Deployment 将在后台逐步更新已经部署的 nginx 应用。 +它确保在更新过程中，只有一定数量的旧副本被开闭，并且只有一定基于所需 Pod 数量的新副本被创建。 +想要了解更多细节，请参考 [Deployment](/zh/docs/concepts/workloads/controllers/deployment/)。 ## {{% heading "whatsnext" %}} - <!-- - [Learn about how to use `kubectl` for application introspection and debugging.](/docs/tasks/debug-application-cluster/debug-application-introspection/) - [Configuration Best Practices and Tips](/docs/concepts/configuration/overview/) --> -- [学习怎么样使用 `kubectl` 观察和调试应用](/docs/tasks/debug-application-cluster/debug-application-introspection/) -- [配置最佳实践和技巧](/docs/concepts/configuration/overview/) - +- 学习[如何使用 `kubectl` 观察和调试应用](/zh/docs/tasks/debug-application-cluster/debug-application-introspection/) +- 阅读[配置最佳实践和技巧](/zh/docs/concepts/configuration/overview/) diff --git a/content/zh/docs/concepts/cluster-administration/monitoring.md b/content/zh/docs/concepts/cluster-administration/monitoring.md index 5025857051..afd8d12b64 100644 --- a/content/zh/docs/concepts/cluster-administration/monitoring.md +++ b/content/zh/docs/concepts/cluster-administration/monitoring.md @@ -2,6 +2,8 @@ title: Kubernetes 控制面的指标 content_type: concept weight: 60 +aliases: +- controller-metrics.md --- <!-- overview --> @@ -11,12 +13,11 @@ System component metrics can give a better look into what is happening inside th Metrics in Kubernetes control plane are emitted in [prometheus format](https://prometheus.io/docs/instrumenting/exposition_formats/) and are human readable. --> - 系统组件的指标可以让我们更好的看清系统内部究竟发生了什么，尤其对于构建仪表盘和告警都非常有用。 -Kubernetes 控制面板中的指标是以 [prometheus](https://prometheus.io/docs/instrumenting/exposition_formats/) 格式发出的，而且是易于阅读的。 - - +Kubernetes 控制面板中的指标是以 +[prometheus](https://prometheus.io/docs/instrumenting/exposition_formats/) +格式发出的，而且是易于阅读的。 <!-- body --> @@ -24,15 +25,14 @@ Kubernetes 控制面板中的指标是以 [prometheus](https://prometheus.io/doc ## Metrics in Kubernetes 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. --> - ## Kubernetes 的指标 -在大多数情况下，指标在 HTTP 服务器的 `/metrics` 端点使用，对于默认情况下不暴露端点的组件，可以使用 `--bind-address` 参数启用。 +在大多数情况下，指标在 HTTP 服务器的 `/metrics` 端点使用。 +对于默认情况下不暴露端点的组件，可以使用 `--bind-address` 参数启用。 <!-- Examples of those components: --> - 举例下面这些组件： * {{< glossary_tooltip term_id="kube-controller-manager" text="kube-controller-manager" >}} @@ -50,12 +50,16 @@ Note that {{< glossary_tooltip term_id="kubelet" text="kubelet" >}} also exposes 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: --> +在生产环境中，你可能需要配置 [Prometheus 服务器](https://prometheus.io/) +或其他指标收集器来定期收集这些指标，并使它们在某种时间序列数据库中可用。 -在生产环境中，你可能需要配置 [Prometheus Server](https://prometheus.io/) 或其他指标收集器来定期收集这些指标，并使它们在某种时间序列数据库中可用。 +请注意 {{< glossary_tooltip term_id="kubelet" text="kubelet" >}} 同样在 +`/metrics/cadvisor`、`/metrics/resource` 和 `/metrics/probes` 等端点提供性能指标。 +这些指标的生命周期并不相同。 -请注意 {{< glossary_tooltip term_id="kubelet" text="kubelet" >}} 同样在 `/metrics/cadvisor`、`/metrics/resource` 和 `/metrics/probes` 等端点提供性能指标。这些指标的生命周期并不相同。 - -如果你的集群还使用了 {{< glossary_tooltip term_id="rbac" text="RBAC" >}} ，那读取指标数据的时候，还需要通过具有 ClusterRole 的用户、组或者 ServiceAccount 来进行授权，才有权限访问 `/metrics` 。 +如果你的集群还使用了 {{< glossary_tooltip term_id="rbac" text="RBAC" >}}， +那读取指标数据的时候，还需要通过具有 ClusterRole 的用户、组或者 ServiceAccount 来进行授权， +才有权限访问 `/metrics` 。 举例： @@ -79,7 +83,6 @@ Alpha metrics have no stability guarantees; as such they can be modified or dele Stable metrics can be guaranteed to not change; Specifically, stability means: --> - ## 指标的生命周期 内测版指标 → 稳定版指标 → 弃用指标 → 隐藏指标 → 删除 @@ -101,8 +104,8 @@ Deprecated metric signal that the metric will eventually be deleted; to find whi Before deprecation: --> - -弃用指标表明这个指标最终将会被删除，要想查找是哪个版本，你需要检查其注释，注释中包括该指标从哪个 kubernetes 版本被弃用。 +弃用指标表明这个指标最终将会被删除，要想查找是哪个版本，你需要检查其注释， +注释中包括该指标从哪个 kubernetes 版本被弃用。 指标弃用前： @@ -112,10 +115,7 @@ Before deprecation: some_counter 0 ``` -<!-- -After deprecation: ---> - +<!-- After deprecation: --> 指标弃用后： ``` @@ -129,8 +129,8 @@ Once a metric is hidden then by default the metrics is not published for scrapin Once a metric is deleted, the metric is not published. You cannot change this using an override. --> - -一个指标一旦被隐藏，默认这个指标是不会发布来被抓取的。如果你想要使用这个隐藏指标，你需要覆盖相关集群组件的配置。 +一个指标一旦被隐藏，默认这个指标是不会发布来被抓取的。 +如果你想要使用这个隐藏指标，你需要覆盖相关集群组件的配置。 一个指标一旦被删除，那这个指标就不会被发布，您也不可以通过覆盖配置来进行更改。 @@ -145,14 +145,17 @@ The flag can only take the previous minor version as it's value. All metrics hid Take metric `A` as an example, here assumed that `A` is deprecated in 1.n. According to metrics deprecated policy, we can reach the following conclusion: --> - ## 显示隐藏指标 -综上所述，管理员可以通过在运行可执行文件时添加一些特定的参数来开启一些隐藏的指标。当管理员错过了之前版本的的一些已弃用的指标时，这个可被视作是一个后门。 +综上所述，管理员可以通过在运行可执行文件时添加一些特定的参数来开启一些隐藏的指标。 +当管理员错过了之前版本的的一些已弃用的指标时，这个可被视作是一个后门。 -`show-hidden-metrics-for-version` 参数可以指定一个版本，用来显示这个版本中被隐藏的指标。这个版本号形式是x.y，x 是主要版本号，y 是次要版本号。补丁版本并不是必须的，尽管在一些补丁版本中也会有一些指标会被弃用，因为指标弃用策略主要是针对次要版本。 +`show-hidden-metrics-for-version` 参数可以指定一个版本，用来显示这个版本中被隐藏的指标。 +这个版本号形式是x.y，x 是主要版本号，y 是次要版本号。补丁版本并不是必须的， +尽管在一些补丁版本中也会有一些指标会被弃用，因为指标弃用策略主要是针对次要版本。 -这个参数只能使用上一版本作为其值，如果管理员将上一版本设置为 `show-hidden-metrics-for-version` 的值，那么就会显示上一版本所有被隐藏的指标，太老的版本是不允许的，因为这不符合指标弃用策略。 +这个参数只能使用上一版本作为其值，如果管理员将上一版本设置为 `show-hidden-metrics-for-version` 的值， +那么就会显示上一版本所有被隐藏的指标，太老的版本是不允许的，因为这不符合指标弃用策略。 以指标 `A` 为例，这里假设 `A` 指标在 1.n 版本中被弃用，根据指标弃用策略，我们可以得出以下结论： @@ -168,7 +171,9 @@ If you're upgrading from release `1.12` to `1.13`, but still depend on a metric * 在 `1.n+1` 版本中，这个指标默认被隐藏，你可以通过设置参数 `show-hidden-metrics-for-version=1.n` 来使它可以被发出. * 在 `1.n+2` 版本中，这个指标就被从代码库中删除，也不会再有后门了. -如果你想要从 `1.12` 版本升级到 `1.13` ，但仍然需要依赖指标 `A` ，你可以通过命令行设置隐藏指标 `--show-hidden-metrics=1.12` ，但是在升级到 `1.14`时就必须要删除这个指标的依赖，因为这个版本中这个指标已经被删除了。 +如果你想要从 `1.12` 版本升级到 `1.13` ，但仍然需要依赖指标 `A` ， +你可以通过命令行设置隐藏指标 `--show-hidden-metrics=1.12`， +但是在升级到 `1.14`时就必须要删除这个指标的依赖，因为这个版本中这个指标已经被删除了。 <!-- ## Component metrics @@ -185,7 +190,6 @@ These metrics can be used to monitor health of persistent volume operations. For example, for GCE these metrics are called: --> - ## 组件指标 ### kube-controller-manager 指标 @@ -205,11 +209,8 @@ cloudprovider_gce_api_request_duration_seconds { request = "detach_disk"} cloudprovider_gce_api_request_duration_seconds { request = "list_disk"} ``` - - ## {{% 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) @@ -218,6 +219,6 @@ cloudprovider_gce_api_request_duration_seconds { request = "list_disk"} * 了解有关 [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://kubernetes.io/docs/reference/using-api/deprecation-policy/#deprecating-a-feature-or-behavior ) +* 了解有关 [Kubernetes 指标弃用策略](/zh/docs/reference/using-api/deprecation-policy/#deprecating-a-feature-or-behavior ) diff --git a/content/zh/docs/concepts/cluster-administration/networking.md b/content/zh/docs/concepts/cluster-administration/networking.md index 0b4a329207..fdc5efd0a0 100644 --- a/content/zh/docs/concepts/cluster-administration/networking.md +++ b/content/zh/docs/concepts/cluster-administration/networking.md @@ -13,20 +13,19 @@ understand exactly how it is expected to work. There are 4 distinct networking problems to address: 1. Highly-coupled container-to-container communications: this is solved by - [pods](/docs/concepts/workloads/pods/pod/) and `localhost` communications. + {{< glossary_tooltip text="Pods" term_id="pod" >}} and `localhost` communications. 2. Pod-to-Pod communications: this is the primary focus of this document. 3. Pod-to-Service communications: this is covered by [services](/docs/concepts/services-networking/service/). 4. External-to-Service communications: this is covered by [services](/docs/concepts/services-networking/service/). --> -集群网络系统是 Kubernetes 的核心部分，但是想要准确了解它的工作原理可是个不小的挑战。下面列出的是网络系统的的四个主要问题： +集群网络系统是 Kubernetes 的核心部分，但是想要准确了解它的工作原理可是个不小的挑战。 +下面列出的是网络系统的的四个主要问题： -1. 高度耦合的容器间通信：这个已经被 [pods](/docs/concepts/workloads/pods/pod) 和 `localhost` 通信解决了。 +1. 高度耦合的容器间通信：这个已经被 {{< glossary_tooltip text="Pods" term_id="pod" >}} + 和 `localhost` 通信解决了。 2. Pod 间通信：这个是本文档的重点要讲述的。 -3. Pod 和 Service 间通信：这个已经在 [services](/docs/concepts/services-networking/service/) 里讲述过了。 -4. 外部和 Service 间通信：这个也已经在 [services](/docs/concepts/services-networking/service/) 讲述过了。 - - - +3. Pod 和服务间通信：这个已经在[服务](/zh/docs/concepts/services-networking/service/) 里讲述过了。 +4. 外部和服务间通信：这也已经在[服务](/zh/docs/concepts/services-networking/service/) 讲述过了。 <!-- body --> @@ -42,9 +41,13 @@ insert dynamic port numbers into configuration blocks, services have to know how to find each other, etc. Rather than deal with this, Kubernetes takes a different approach. --> -Kubernetes 的宗旨就是在应用之间共享机器。通常来说，共享机器需要两个应用之间不能使用相同的端口，但是在多个应用开发者之间去大规模地协调端口是件很困难的事情，尤其是还要让用户暴露在他们控制范围之外的集群级别的问题上。 +Kubernetes 的宗旨就是在应用之间共享机器。 +通常来说，共享机器需要两个应用之间不能使用相同的端口，但是在多个应用开发者之间 +去大规模地协调端口是件很困难的事情，尤其是还要让用户暴露在他们控制范围之外的集群级别的问题上。 -动态分配端口也会给系统带来很多复杂度 - 每个应用都需要设置一个端口的参数，而 API 服务器还需要知道如何将动态端口数值插入到配置模块中，服务也需要知道如何找到对方等等。与其去解决这些问题，Kubernetes 选择了其他不同的方法。 +动态分配端口也会给系统带来很多复杂度 - 每个应用都需要设置一个端口的参数， +而 API 服务器还需要知道如何将动态端口数值插入到配置模块中，服务也需要知道如何找到对方等等。 +与其去解决这些问题，Kubernetes 选择了其他不同的方法。 <!-- ## The Kubernetes network model @@ -68,7 +71,24 @@ Linux): * pods in the host network of a node can communicate with all pods on all nodes without NAT +--> +## Kubernetes 网络模型 {#the-kubernetes-network-model} +每一个 `Pod` 都有它自己的IP地址，这就意味着你不需要显式地在每个 `Pod` 之间创建链接， +你几乎不需要处理容器端口到主机端口之间的映射。 +这将创建一个干净的、向后兼容的模型，在这个模型里，从端口分配、命名、服务发现、 +负载均衡、应用配置和迁移的角度来看，`Pod` 可以被视作虚拟机或者物理主机。 + +Kubernetes 对所有网络设施的实施，都需要满足以下的基本要求（除非有设置一些特定的网络分段策略）： + +* 节点上的 Pod 可以不通过 NAT 和其他任何节点上的 Pod 通信 +* 节点上的代理（比如：系统守护进程、kubelet） 可以和节点上的所有Pod通信 + +备注：仅针对那些支持 `Pods` 在主机网络中运行的平台(比如：Linux) ： + +* 那些运行在节点的主机网络里的 Pod 可以不通过 NAT 和所有节点上的 Pod 通信 + +<!-- This model is not only less complex overall, but it is principally compatible with the desire for Kubernetes to enable low-friction porting of apps from VMs to containers. If your job previously ran in a VM, your VM had an IP and could @@ -79,24 +99,15 @@ share their network namespaces - including their IP address. This means that containers within a `Pod` can all reach each other's ports on `localhost`. This also means that containers within a `Pod` must coordinate port usage, but this is no different from processes in a VM. This is called the "IP-per-pod" model. - --> -## Kubernetes 网络模型 +这个模型不仅不复杂，而且还和 Kubernetes 的实现廉价的从虚拟机向容器迁移的初衷相兼容， +如果你的工作开始是在虚拟机中运行的，你的虚拟机有一个 IP ， +这样就可以和其他的虚拟机进行通信，这是基本相同的模型。 -每一个 `Pod` 都有它自己的IP地址，这就意味着你不需要显式地在每个 `Pod` 之间创建链接，你几乎不需要处理容器端口到主机端口之间的映射。这将创建一个干净的、向后兼容的模型，在这个模型里，从端口分配、命名、服务发现、负载均衡、应用配置和迁移的角度来看，`Pod` 可以被视作虚拟机或者物理主机。 - -Kubernetes 对所有网络设施的实施，都需要满足以下的基本要求（除非有设置一些特定的网络分段策略）： - - * 节点上的 pods 可以不通过 NAT 和其他任何节点上的 pods 通信 - * 节点上的代理（比如：系统守护进程、kubelet） 可以和节点上的所有pods通信 - -备注：仅针对那些支持 `Pods` 在主机网络中运行的平台(比如：Linux) ： - - * 那些运行在节点的主机网络里的 pods 可以不通过 NAT 和所有节点上的 pods 通信 - -这个模型不仅不复杂，而且还和 Kubernetes 的实现廉价的从虚拟机向容器迁移的初衷相兼容，如果你的工作开始是在虚拟机中运行的，你的虚拟机有一个 IP ，这样就可以和其他的虚拟机进行通信，这是基本相同的模型。 - -Kubernetes 的 IP 地址存在于 `Pod` 范围内 - 容器分享他们的网络命名空间 - 包括他们的 IP 地址。这就意味着 `Pod` 内的容器都可以通过 `localhost` 到达各个端口。这也意味着 `Pod` 内的容器都需要相互协调端口的使用，但是这和虚拟机中的进程似乎没有什么不同，这也被称为“一个 pod 一个 IP” 模型。 +Kubernetes 的 IP 地址存在于 `Pod` 范围内 - 容器分享它们的网络命名空间 - 包括它们的 IP 地址。 +这就意味着 `Pod` 内的容器都可以通过 `localhost` 到达各个端口。 +这也意味着 `Pod` 内的容器都需要相互协调端口的使用，但是这和虚拟机中的进程似乎没有什么不同， +这也被称为“一个 Pod 一个 IP” 模型。 <!-- How this is implemented is a detail of the particular container runtime in use. @@ -108,7 +119,9 @@ blind to the existence or non-existence of host ports. --> 如何实现这一点是正在使用的容器运行时的特定信息。 -也可以在 `node` 本身通过端口去请求你的 `Pod` （称之为主机端口），但这是一个很特殊的操作。转发方式如何实现也是容器运行时的细节。`Pod` 自己并不知道这些主机端口是否存在。 +也可以在 `node` 本身通过端口去请求你的 `Pod` （称之为主机端口）， +但这是一个很特殊的操作。转发方式如何实现也是容器运行时的细节。 +`Pod` 自己并不知道这些主机端口是否存在。 <!-- ## How to implement the Kubernetes networking model @@ -122,9 +135,10 @@ imply any preferential status. --> ## 如何实现 Kubernetes 的网络模型 -有很多种方式可以实现这种网络模型，本文档并不是对各种实现技术的详细研究，但是希望可以作为对各种技术的详细介绍，并且成为你研究的起点。 +有很多种方式可以实现这种网络模型，本文档并不是对各种实现技术的详细研究， +但是希望可以作为对各种技术的详细介绍，并且成为你研究的起点。 -接下来的网络技术是按照首字母排序，并无其他任何含义。 +接下来的网络技术是按照首字母排序，顺序本身并无其他意义。 <!-- ### ACI @@ -132,7 +146,10 @@ imply any preferential status. [Cisco Application Centric Infrastructure](https://www.cisco.com/c/en/us/solutions/data-center-virtualization/application-centric-infrastructure/index.html) offers an integrated overlay and underlay SDN solution that supports containers, virtual machines, and bare metal servers. [ACI](https://www.github.com/noironetworks/aci-containers) provides container networking integration for ACI. An overview of the integration is provided [here](https://www.cisco.com/c/dam/en/us/solutions/collateral/data-center-virtualization/application-centric-infrastructure/solution-overview-c22-739493.pdf). --> ### ACI -[Cisco Application Centric Infrastructure](https://www.cisco.com/c/en/us/solutions/data-center-virtualization/application-centric-infrastructure/index.html) 提供了一个集成覆盖和底层 SDN 解决方案来支持容器、虚拟机和其他裸机服务器。[ACI](https://www.github.com/noironetworks/aci-containers) 为ACI提供了容器网络集成。点击[这里](https://www.cisco.com/c/dam/en/us/solutions/collateral/data-center-virtualization/application-centric-infrastructure/solution-overview-c22-739493.pdf)查看概述 +[Cisco Application Centric Infrastructure](https://www.cisco.com/c/en/us/solutions/data-center-virtualization/application-centric-infrastructure/index.html) +提供了一个集成覆盖网络和底层 SDN 的解决方案来支持容器、虚拟机和其他裸机服务器。 +[ACI](https://www.github.com/noironetworks/aci-containers) 为 ACI 提供了容器网络集成。 +点击[这里](https://www.cisco.com/c/dam/en/us/solutions/collateral/data-center-virtualization/application-centric-infrastructure/solution-overview-c22-739493.pdf)查看概述。 <!-- ### Antrea @@ -142,12 +159,16 @@ Thanks to the "programmable" characteristic of Open vSwitch, Antrea is able to i --> ### Antrea -[Antrea](https://github.com/vmware-tanzu/antrea) 项目是一个开源的，旨在成为 Kubernetes 原生的网络解决方案。它利用 Open vSwitch 作为网络数据平面。Open vSwitch 是一个高性能可编程的虚拟交换机，支持 Linux 和 Windows 平台。Open vSwitch 使 Antrea 能够以高性能和高效的方式实现 Kubernetes 的网络策略。借助 Open vSwitch 可编程的特性， Antrea 能够在 Open vSwitch 之上实现广泛的网络，安全功能和服务。 +[Antrea](https://github.com/vmware-tanzu/antrea) 项目是一个开源的联网解决方案，旨在成为 +Kubernetes 原生的网络解决方案。它利用 Open vSwitch 作为网络数据平面。 +Open vSwitch 是一个高性能可编程的虚拟交换机，支持 Linux 和 Windows 平台。 +Open vSwitch 使 Antrea 能够以高性能和高效的方式实现 Kubernetes 的网络策略。 +借助 Open vSwitch 可编程的特性，Antrea 能够在 Open vSwitch 之上实现广泛的联网、安全功能和服务。 <!-- ### AOS from Apstra -[AOS](http://www.apstra.com/products/aos/) is an Intent-Based Networking system that creates and manages complex datacenter environments from a simple integrated platform. AOS leverages a highly scalable distributed design to eliminate network outages while minimizing costs. +[AOS](https://www.apstra.com/products/aos/) is an Intent-Based Networking system that creates and manages complex datacenter environments from a simple integrated platform. AOS leverages a highly scalable distributed design to eliminate network outages while minimizing costs. The AOS Reference Design currently supports Layer-3 connected hosts that eliminate legacy Layer-2 switching problems. These Layer-3 hosts can be Linux servers (Debian, Ubuntu, CentOS) that create BGP neighbor relationships directly with the top of rack switches (TORs). AOS automates the routing adjacencies and then provides fine grained control over the route health injections (RHI) that are common in a Kubernetes deployment. @@ -155,19 +176,27 @@ AOS has a rich set of REST API endpoints that enable Kubernetes to quickly chang AOS supports the use of common vendor equipment from manufacturers including Cisco, Arista, Dell, Mellanox, HPE, and a large number of white-box systems and open network operating systems like Microsoft SONiC, Dell OPX, and Cumulus Linux. -Details on how the AOS system works can be accessed here: http://www.apstra.com/products/how-it-works/ +Details on how the AOS system works can be accessed here: https://www.apstra.com/products/how-it-works/ --> -### Apstra 中的 AOS +### Apstra 的 AOS -[AOS](http://www.apstra.com/products/aos/) 是一个基于意图的网络系统，可以通过一个简单的集成平台创建和管理复杂的数据中心环境。AOS 利用高度可扩展的分布式设计来消除网络中断，同时将成本降至最低。 +[AOS](https://www.apstra.com/products/aos/) 是一个基于意图的网络系统， +可以通过一个简单的集成平台创建和管理复杂的数据中心环境。 +AOS 利用高度可扩展的分布式设计来消除网络中断，同时将成本降至最低。 -AOS 参考设计当前支持三层连接的主机，这些主机消除了旧的两层连接的交换问题。这些三层连接的主机可以是 Linux（Debian、Ubuntu、CentOS）系统，它们直接在机架式交换机（TOR）的顶部创建 BGP 邻居关系。AOS 自动执行路由邻接，然后提供对 Kubernetes 部署中常见的路由运行状况注入（RHI）的精细控制。 +AOS 参考设计当前支持三层连接的主机，这些主机消除了旧的两层连接的交换问题。 +这些三层连接的主机可以是 Linux（Debian、Ubuntu、CentOS）系统， +它们直接在机架式交换机（TOR）的顶部创建 BGP 邻居关系。 +AOS 自动执行路由邻接，然后提供对 Kubernetes 部署中常见的路由运行状况注入（RHI）的精细控制。 -AOS 具有一组丰富的 REST API 端点，这些端点使 Kubernetes 能够根据应用程序需求快速更改网络策略。进一步的增强功能将用于网络设计的 AOS Graph 模型与工作负载供应集成在一起，从而为私有云和公共云提供端到端管理系统。 +AOS 具有一组丰富的 REST API 端点，这些端点使 Kubernetes 能够根据应用程序需求快速更改网络策略。 +进一步的增强功能将用于网络设计的 AOS Graph 模型与工作负载供应集成在一起， +从而为私有云和公共云提供端到端管理系统。 -AOS 支持使用包括 Cisco、Arista、Dell、Mellanox、HPE 在内的制造商提供的通用供应商设备，以及大量白盒系统和开放网络操作系统，例如 Microsoft SONiC、Dell OPX 和 Cumulus Linux 。 +AOS 支持使用包括 Cisco、Arista、Dell、Mellanox、HPE 在内的制造商提供的通用供应商设备， +以及大量白盒系统和开放网络操作系统，例如 Microsoft SONiC、Dell OPX 和 Cumulus Linux 。 -想要更详细地了解 AOS 系统是如何工作的可以点击这里： http://www.apstra.com/products/how-it-works/ +想要更详细地了解 AOS 系统是如何工作的可以点击这里：https://www.apstra.com/products/how-it-works/ <!-- ### AWS VPC CNI for Kubernetes @@ -180,11 +209,18 @@ Additionally, the CNI can be run alongside [Calico for network policy enforcemen --> ### Kubernetes 的 AWS VPC CNI -[AWS VPC CNI](https://github.com/aws/amazon-vpc-cni-k8s) 为 Kubernetes 集群提供了集成的 AWS 虚拟私有云（VPC）网络。该 CNI 插件提供了高吞吐量和可用性，低延迟以及最小的网络抖动。此外，用户可以使用现有的 AWS VPC 网络和安全最佳实践来构建 Kubernetes 集群。这包括使用 VPC 流日志，VPC 路由策略和安全组进行网络流量隔离的功能。 +[AWS VPC CNI](https://github.com/aws/amazon-vpc-cni-k8s) 为 Kubernetes 集群提供了集成的 +AWS 虚拟私有云（VPC）网络。该 CNI 插件提供了高吞吐量和可用性，低延迟以及最小的网络抖动。 +此外，用户可以使用现有的 AWS VPC 网络和安全最佳实践来构建 Kubernetes 集群。 +这包括使用 VPC 流日志、VPC 路由策略和安全组进行网络流量隔离的功能。 -使用该 CNI 插件，可使 Kubernetes Pods 在 Pod 中拥有与在 VPC 网络上相同的 IP 地址。CNI 将 AWS 弹性网络接口（ENI）分配给每个 Kubernetes 节点，并将每个 ENI 的辅助 IP 范围用于该节点上的 Pod 。CNI 包含用于 ENI 和 IP 地址的预分配的控件，以便加快 Pod 的启动时间，并且能够支持多达2000个节点的大型集群。 +使用该 CNI 插件，可使 Kubernetes Pod 拥有与在 VPC 网络上相同的 IP 地址。 +CNI 将 AWS 弹性网络接口（ENI）分配给每个 Kubernetes 节点，并将每个 ENI 的辅助 IP 范围用于该节点上的 Pod 。 +CNI 包含用于 ENI 和 IP 地址的预分配的控件，以便加快 Pod 的启动时间，并且能够支持多达2000个节点的大型集群。 -此外，CNI可以与[用于执行网络策略的 Calico](https://docs.aws.amazon.com/eks/latest/userguide/calico.html)一起运行。 AWS VPC CNI项目是开源的，查看 [GitHub 上的文档](https://github.com/aws/amazon-vpc-cni-k8s)。 +此外，CNI 可以与 +[用于执行网络策略的 Calico](https://docs.aws.amazon.com/eks/latest/userguide/calico.html)一起运行。 +AWS VPC CNI 项目是开源的，请查看 [GitHub 上的文档](https://github.com/aws/amazon-vpc-cni-k8s)。 <!-- ### Azure CNI for Kubernetes @@ -194,9 +230,16 @@ Azure CNI is available natively in the [Azure Kubernetes Service (AKS)] (https:/ --> ### Kubernetes 的 Azure CNI -[Azure CNI](https://docs.microsoft.com/en-us/azure/virtual-network/container-networking-overview) 是一个[开源插件](https://github.com/Azure/azure-container-networking/blob/master/docs/cni.md)，将 Kubernetes Pods 和 Azure 虚拟网络（也称为 VNet）集成在一起，可提供与 VN 相当的网络性能。Pod 可以通过 Express Route 或者 站点到站点的 VPN 来连接到对等的 VNet ，也可以从这些网络来直接访问 Pod。Pod 可以访问受服务端点或者受保护链接的 Azure 服务，比如存储和 SQL。你可以使用 VNet 安全策略和路由来筛选 Pod 流量。该插件通过利用在 Kubernetes 节点的网络接口上预分配的辅助 IP 池将 VNet 分配给 Pod 。 +[Azure CNI](https://docs.microsoft.com/en-us/azure/virtual-network/container-networking-overview) +是一个[开源插件](https://github.com/Azure/azure-container-networking/blob/master/docs/cni.md)， +将 Kubernetes Pods 和 Azure 虚拟网络（也称为 VNet）集成在一起，可提供与 VM 相当的网络性能。 +Pod 可以通过 Express Route 或者 站点到站点的 VPN 来连接到对等的 VNet ， +也可以从这些网络来直接访问 Pod。Pod 可以访问受服务端点或者受保护链接的 Azure 服务，比如存储和 SQL。 +你可以使用 VNet 安全策略和路由来筛选 Pod 流量。 +该插件通过利用在 Kubernetes 节点的网络接口上预分配的辅助 IP 池将 VNet 分配给 Pod 。 -Azure CNI 可以在 [Azure Kubernetes Service (AKS)](https://docs.microsoft.com/en-us/azure/aks/configure-azure-cni) 中获得。 +Azure CNI 可以在 +[Azure Kubernetes Service (AKS)](https://docs.microsoft.com/en-us/azure/aks/configure-azure-cni) 中获得。 <!-- ### Big Cloud Fabric from Big Switch Networks @@ -205,15 +248,24 @@ Azure CNI 可以在 [Azure Kubernetes Service (AKS)](https://docs.microsoft.com/ With the help of the Big Cloud Fabric's virtual pod multi-tenant architecture, container orchestration systems such as Kubernetes, RedHat OpenShift, Mesosphere DC/OS & Docker Swarm will be natively integrated alongside with VM orchestration systems such as VMware, OpenStack & Nutanix. Customers will be able to securely inter-connect any number of these clusters and enable inter-tenant communication between them if needed. -BCF was recognized by Gartner as a visionary in the latest [Magic Quadrant](http://go.bigswitch.com/17GatedDocuments-MagicQuadrantforDataCenterNetworking_Reg.html). One of the BCF Kubernetes on-premises deployments (which includes Kubernetes, DC/OS & VMware running on multiple DCs across different geographic regions) is also referenced [here](https://portworx.com/architects-corner-kubernetes-satya-komala-nio/). +BCF was recognized by Gartner as a visionary in the latest [Magic Quadrant](https://go.bigswitch.com/17GatedDocuments-MagicQuadrantforDataCenterNetworking_Reg.html). One of the BCF Kubernetes on-premises deployments (which includes Kubernetes, DC/OS & VMware running on multiple DCs across different geographic regions) is also referenced [here](https://portworx.com/architects-corner-kubernetes-satya-komala-nio/). --> ### Big Switch Networks 的 Big Cloud Fabric -[Big Cloud Fabric](https://www.bigswitch.com/container-network-automation) 是一个基于云原生的网络架构，旨在在私有云或者本地环境中运行 Kubernetes。它使用统一的物理和虚拟 SDN，Big Cloud Fabric 解决了固有的容器网络问题，比如负载均衡、可见性、故障排除、安全策略和容器流量监控。 +[Big Cloud Fabric](https://www.bigswitch.com/container-network-automation) 是一个基于云原生的网络架构， +旨在在私有云或者本地环境中运行 Kubernetes。 +它使用统一的物理和虚拟 SDN，Big Cloud Fabric 解决了固有的容器网络问题， +比如负载均衡、可见性、故障排除、安全策略和容器流量监控。 -在 Big Cloud Fabric 的虚拟 Pod 多租户架构的帮助下，容器编排系统（比如 Kubernetes、RedHat OpenShift、Mesosphere DC/OS 和 Docker Swarm）将于VM本地编排系统（比如 VMware、OpenStack 和 Nutanix）进行本地集成。客户将能够安全地互联任意数量的这些集群，并且在需要时启用他们之间的租户间通信。 +在 Big Cloud Fabric 的虚拟 Pod 多租户架构的帮助下，容器编排系统 +（比如 Kubernetes、RedHat OpenShift、Mesosphere DC/OS 和 Docker Swarm） +将与 VM 本地编排系统（比如 VMware、OpenStack 和 Nutanix）进行本地集成。 +客户将能够安全地互联任意数量的这些集群，并且在需要时启用他们之间的租户间通信。 -在最新的 [Magic Quadrant](http://go.bigswitch.com/17GatedDocuments-MagicQuadrantforDataCenterNetworking_Reg.html) 上，BCF 被 Gartner 认为是非常有远见的。而 BCF 的一条关于 Kubernetes 的本地部署（其中包括 Kubernetes、DC/OS 和在不同地理区域的多个 DC 上运行的 VMware）也在[这里](https://portworx.com/architects-corner-kubernetes-satya-komala-nio/)被引用。 +在最新的 [Magic Quadrant](https://go.bigswitch.com/17GatedDocuments-MagicQuadrantforDataCenterNetworking_Reg.html) 上， +BCF 被 Gartner 认为是非常有远见的。 +而 BCF 的一条关于 Kubernetes 的本地部署（其中包括 Kubernetes、DC/OS 和在不同地理区域的多个 +DC 上运行的 VMware）也在[这里](https://portworx.com/architects-corner-kubernetes-satya-komala-nio/)被引用。 <!-- ### Cilium @@ -226,20 +278,31 @@ addressing, and it can be used in combination with other CNI plugins. --> ### Cilium -[Cilium](https://github.com/cilium/cilium) 是一个开源软件，用于提供并透明保护应用容器间的网络连接。Cilium 支持 L7/HTTP ，可以在 L3-L7 上通过使用与网络分离的基于身份的安全模型寻址来实施网络策略，并且可以与其他 CNI 插件结合使用。 +[Cilium](https://github.com/cilium/cilium) 是一个开源软件，用于提供并透明保护应用容器间的网络连接。 +Cilium 支持 L7/HTTP，可以在 L3-L7 上通过使用与网络分离的基于身份的安全模型寻址来实施网络策略， +并且可以与其他 CNI 插件结合使用。 <!-- ### CNI-Genie from Huawei -[CNI-Genie](https://github.com/Huawei-PaaS/CNI-Genie) is a CNI plugin that enables Kubernetes to [simultaneously have access to different implementations](https://github.com/Huawei-PaaS/CNI-Genie/blob/master/docs/multiple-cni-plugins/README.md#what-cni-genie-feature-1-multiple-cni-plugins-enables) of the [Kubernetes network model](https://github.com/kubernetes/website/blob/master/content/en/docs/concepts/cluster-administration/networking.md#the-kubernetes-network-model) in runtime. This includes any implementation that runs as a [CNI plugin](https://github.com/containernetworking/cni#3rd-party-plugins), such as [Flannel](https://github.com/coreos/flannel#flannel), [Calico](http://docs.projectcalico.org/), [Romana](http://romana.io), [Weave-net](https://www.weave.works/products/weave-net/). +[CNI-Genie](https://github.com/Huawei-PaaS/CNI-Genie) is a CNI plugin that enables Kubernetes to [simultaneously have access to different implementations](https://github.com/Huawei-PaaS/CNI-Genie/blob/master/docs/multiple-cni-plugins/README.md#what-cni-genie-feature-1-multiple-cni-plugins-enables) of the [Kubernetes network model](https://github.com/kubernetes/website/blob/master/content/en/docs/concepts/cluster-administration/networking.md#the-kubernetes-network-model) in runtime. This includes any implementation that runs as a [CNI plugin](https://github.com/containernetworking/cni#3rd-party-plugins), such as [Flannel](https://github.com/coreos/flannel#flannel), [Calico](https://docs.projectcalico.org/), [Romana](https://romana.io), [Weave-net](https://www.weave.works/products/weave-net/). CNI-Genie also supports [assigning multiple IP addresses to a pod](https://github.com/Huawei-PaaS/CNI-Genie/blob/master/docs/multiple-ips/README.md#feature-2-extension-cni-genie-multiple-ip-addresses-per-pod), each from a different CNI plugin. --> ### 华为的 CNI-Genie -[CNI-Genie](https://github.com/Huawei-PaaS/CNI-Genie) 是一个 CNI 插件，可以让 Kubernetes 在运行时允许不同的 [Kubernetes 的网络模型](https://github.com/kubernetes/website/blob/master/content/en/docs/concepts/cluster-administration/networking.md#the-kubernetes-network-model)的[实现同时被访问](https://github.com/Huawei-PaaS/CNI-Genie/blob/master/docs/multiple-cni-plugins/README.md#what-cni-genie-feature-1-multiple-cni-plugins-enables)。这包括以 [CNI 插件](https://github.com/containernetworking/cni#3rd-party-plugins)运行的任何实现，比如 [Flannel](https://github.com/coreos/flannel#flannel)、[Calico](http://docs.projectcalico.org/)、[Romana](http://romana.io)、[Weave-net](https://www.weave.works/products/weave-net/)。 +[CNI-Genie](https://github.com/Huawei-PaaS/CNI-Genie) 是一个 CNI 插件， +可以让 Kubernetes 在运行时使用不同的[网络模型](#the-kubernetes-network-model)的 +[实现同时被访问](https://github.com/Huawei-PaaS/CNI-Genie/blob/master/docs/multiple-cni-plugins/README.md#what-cni-genie-feature-1-multiple-cni-plugins-enables)。 +这包括以 +[CNI 插件](https://github.com/containernetworking/cni#3rd-party-plugins)运行的任何实现，比如 +[Flannel](https://github.com/coreos/flannel#flannel)、 +[Calico](https://docs.projectcalico.org/)、 +[Romana](https://romana.io)、 +[Weave-net](https://www.weave.works/products/weave-net/)。 -CNI-Genie 还支持[将多个 IP 地址分配给 Pod](https://github.com/Huawei-PaaS/CNI-Genie/blob/master/docs/multiple-ips/README.md#feature-2-extension-cni-genie-multi-ip-addresses-per-pod)，每个都来自不同的 CNI 插件。 +CNI-Genie 还支持[将多个 IP 地址分配给 Pod](https://github.com/Huawei-PaaS/CNI-Genie/blob/master/docs/multiple-ips/README.md#feature-2-extension-cni-genie-multi-ip-addresses-per-pod)， +每个都来自不同的 CNI 插件。 <!-- ### cni-ipvlan-vpc-k8s @@ -260,28 +323,41 @@ network complexity required to deploy Kubernetes at scale within AWS. --> ### cni-ipvlan-vpc-k8s -[cni-ipvlan-vpc-k8s](https://github.com/lyft/cni-ipvlan-vpc-k8s) 包含了一组 CNI 和 IPAM 插件来提供一个简单的、本地主机、低延迟、高吞吐量以及通过使用 Amazon 弹性网络接口（ENI）并使用 Linux 内核的 IPv2 驱动程序以 L2 模式将 AWS 管理的 IP 绑定到 Pod 中，在 Amazon Virtual Private Cloud（VPC）环境中为 Kubernetes 兼容的网络堆栈。 +[cni-ipvlan-vpc-k8s](https://github.com/lyft/cni-ipvlan-vpc-k8s) +包含了一组 CNI 和 IPAM 插件来提供一个简单的、本地主机、低延迟、高吞吐量 +以及通过使用 Amazon 弹性网络接口（ENI）并使用 Linux 内核的 IPv2 驱动程序 +以 L2 模式将 AWS 管理的 IP 绑定到 Pod 中， +在 Amazon Virtual Private Cloud（VPC）环境中为 Kubernetes 兼容的网络堆栈。 -这些插件旨在直接在 VPC 中进行配置和部署，Kubelets 先启动，然后根据需要进行自我配置和扩展它们的 IP 使用率，而无需经常建议复杂的管理覆盖网络， BGP ，禁用源/目标检查，或调整 VPC 路由表以向每个主机提供每个实例子网的复杂性（每个 VPC 限制为50-100个条目）。简而言之， cni-ipvlan-vpc-k8s 大大降低了在 AWS 中大规模部署 Kubernetes 所需的网络复杂性。 +这些插件旨在直接在 VPC 中进行配置和部署，Kubelets 先启动， +然后根据需要进行自我配置和扩展它们的 IP 使用率，而无需经常建议复杂的管理 +覆盖网络、BGP、禁用源/目标检查或调整 VPC 路由表以向每个主机提供每个实例子网的 +复杂性（每个 VPC 限制为50-100个条目）。 +简而言之，cni-ipvlan-vpc-k8s 大大降低了在 AWS 中大规模部署 Kubernetes 所需的网络复杂性。 <!-- ### Contiv -[Contiv](https://github.com/contiv/netplugin) provides configurable networking (native l3 using BGP, overlay using vxlan, classic l2, or Cisco-SDN/ACI) for various use cases. [Contiv](http://contiv.io) is all open sourced. +[Contiv](https://github.com/contiv/netplugin) provides configurable networking (native l3 using BGP, overlay using vxlan, classic l2, or Cisco-SDN/ACI) for various use cases. [Contiv](https://contiv.io) is all open sourced. --> ### Contiv -[Contiv](https://github.com/contiv/netplugin) 为各种使用情况提供了一个可配置网络（使用了 BGP 的本地 l3 ，使用 vxlan 的覆盖，经典 l2 或 Cisco-SDN/ACI）。[Contiv](http://contiv.io) 是完全开源的。 +[Contiv](https://github.com/contiv/netplugin) +为各种使用情况提供了一个可配置网络（使用了 BGP 的本地 L3， +使用 vxlan 、经典 L2 或 Cisco-SDN/ACI 的覆盖网络）。 +[Contiv](https://contiv.io) 是完全开源的。 <!-- -### Contrail / Tungsten Fabric +### Contrail/Tungsten Fabric -[Contrail](http://www.juniper.net/us/en/products-services/sdn/contrail/contrail-networking/), based on [Tungsten Fabric](https://tungsten.io), is a truly open, multi-cloud network virtualization and policy management platform. Contrail and Tungsten Fabric are integrated with various orchestration systems such as Kubernetes, OpenShift, OpenStack and Mesos, and provide different isolation modes for virtual machines, containers/pods and bare metal workloads. +[Contrail](https://www.juniper.net/us/en/products-services/sdn/contrail/contrail-networking/), based on [Tungsten Fabric](https://tungsten.io), is a truly open, multi-cloud network virtualization and policy management platform. Contrail and Tungsten Fabric are integrated with various orchestration systems such as Kubernetes, OpenShift, OpenStack and Mesos, and provide different isolation modes for virtual machines, containers/pods and bare metal workloads. --> +### Contrail/Tungsten Fabric -### Contrail / Tungsten Fabric - -[Contrail](http://www.juniper.net/us/en/products-services/sdn/contrail/contrail-networking/) 是基于 [Tungsten Fabric](https://tungsten.io) 的，真正开放的，多云网络虚拟化和策略管理平台。Contrail 和 Tungsten Fabric 与各种编排系统集成在一起，例如 Kubernetes，OpenShift，OpenStack 和 Mesos，并为虚拟机、容器或 Pods 以及裸机工作负载提供了不同的隔离模式。 +[Contrail](https://www.juniper.net/us/en/products-services/sdn/contrail/contrail-networking/) +是基于 [Tungsten Fabric](https://tungsten.io) 的，真正开放的多云网络虚拟化和策略管理平台。 +Contrail 和 Tungsten Fabric 与各种编排系统集成在一起，例如 Kubernetes、OpenShift、OpenStack 和 Mesos， +并为虚拟机、容器或 Pods 以及裸机工作负载提供了不同的隔离模式。 <!-- ### DANM @@ -298,15 +374,16 @@ With this toolset DANM is able to provide multiple separated network interfaces, --> ### DANM -[DANM](https://github.com/nokia/danm) 是一个针对在 Kubernetes 集群中运行的电信工作负载的网络解决方案。它由以下几个组件构成： +[DANM](https://github.com/nokia/danm) 是一个针对在 Kubernetes 集群中运行的电信工作负载的网络解决方案。 +它由以下几个组件构成： - * 能够配置具有高级功能的 IPVLAN 接口的 CNI 插件 - * 一个内置的 IPAM 模块，能够管理多个、群集内的、不连续的 L3 网络，并按请求提供动态、静态或无 IP 分配方案 - * CNI 元插件能够通过自己的 CNI 或通过将任务授权给其他任何流行的 CNI 解决方案（例如 SRI-OV 或 Flannel）来实现将多个网络接口连接到容器 - * Kubernetes 控制器能够集中管理所有 Kubernetes 主机的 VxLAN 和 VLAN 接口 - * 另一个 Kubernetes 控制器扩展了 Kubernetes 的基于服务的服务发现概念，以在 Pod 的所有网络接口上工作 +* 能够配置具有高级功能的 IPVLAN 接口的 CNI 插件 +* 一个内置的 IPAM 模块，能够管理多个、群集内的、不连续的 L3 网络，并按请求提供动态、静态或无 IP 分配方案 +* CNI 元插件能够通过自己的 CNI 或通过将任务授权给其他任何流行的 CNI 解决方案（例如 SRI-OV 或 Flannel）来实现将多个网络接口连接到容器 +* Kubernetes 控制器能够集中管理所有 Kubernetes 主机的 VxLAN 和 VLAN 接口 +* 另一个 Kubernetes 控制器扩展了 Kubernetes 的基于服务的服务发现概念，以在 Pod 的所有网络接口上工作 -通过这个工具集，DANM 可以提供多个分离的网络接口，可以为 pods 使用不同的网络后端和高级 IPAM 功能。 +通过这个工具集，DANM 可以提供多个分离的网络接口，可以为 Pod 使用不同的网络后端和高级 IPAM 功能。 <!-- ### Flannel @@ -317,7 +394,8 @@ people have reported success with Flannel and Kubernetes. --> ### Flannel -[Flannel](https://github.com/coreos/flannel#flannel) 是一个非常简单的能够满足 Kubernetes 所需要的重叠网络。已经有许多人报告了使用 Flannel 和 Kubernetes 的成功案例。 +[Flannel](https://github.com/coreos/flannel#flannel) 是一个非常简单的能够满足 +Kubernetes 所需要的覆盖网络。已经有许多人报告了使用 Flannel 和 Kubernetes 的成功案例。 <!-- ### Google Compute Engine (GCE) @@ -328,7 +406,7 @@ assign each VM a subnet (default is `/24` - 254 IPs). Any traffic bound for tha subnet will be routed directly to the VM by the GCE network fabric. This is in addition to the "main" IP address assigned to the VM, which is NAT'ed for outbound internet access. A linux bridge (called `cbr0`) is configured to exist -on that subnet, and is passed to docker's `--bridge` flag. +on that subnet, and is passed to docker's `-bridge` flag. Docker is started with: @@ -365,7 +443,11 @@ traffic to the internet. --> ### Google Compute Engine (GCE) -对于 Google Compute Engine 的集群配置脚本，[advanced routing](https://cloud.google.com/vpc/docs/routes) 用于为每个虚机分配一个子网（默认是 `/24` - 254个 IP），绑定到该子网的任何流量都将通过 GCE 网络结构直接路由到虚机。这是除了分配给虚机的“主要” IP 地址之外的一个补充，该 IP 地址经过 NAT 转换以用于访问外网。linux网桥（称为“cbr0”）被配置为存在于该子网中，并被传递到 docker 的 --bridge 参数上。 +对于 Google Compute Engine 的集群配置脚本， +[高级路由器](https://cloud.google.com/vpc/docs/routes) 用于为每个虚机分配一个子网（默认是 `/24` - 254个 IP）， +绑定到该子网的任何流量都将通过 GCE 网络结构直接路由到虚机。 +这是除了分配给虚机的“主” IP 地址之外的一个补充，该 IP 地址经过 NAT 转换以用于访问外网。 +Linux 网桥（称为“cbr0”）被配置为存在于该子网中，并被传递到 Docker 的 --bridge 参数上。 Docker 会以这样的参数启动： @@ -373,11 +455,14 @@ Docker 会以这样的参数启动： DOCKER_OPTS="--bridge=cbr0 --iptables=false --ip-masq=false" ``` -这个网桥是由 Kubelet（由 --network-plugin=kubenet 参数控制）根据节点的 .spec.podCIDR 参数创建的。 +这个网桥是由 Kubelet（由 --network-plugin=kubenet 参数控制）根据节点的 `.spec.podCIDR` 参数创建的。 -Docker 将会从 `cbr-cidr` 块分配 IP 。容器之间可以通过 cbr0 网桥相互访问，也可以访问节点。这些 IP 都可以在 GCE 的网络中被路由。 - -而 GCE 本身并不知道这些 IP，所以不会对访问外网的流量进行 NAT，为了实现此目的，使用了 iptables 规则来伪装（又称为 SNAT，使数据包看起来好像是来自“节点”本身），将通信绑定到 GCE 项目网络（10.0.0.0/8）之外的 IP。 +Docker 将会从 `cbr-cidr` 块分配 IP。 +容器之间可以通过 `cbr0` 网桥相互访问，也可以访问节点。 +这些 IP 都可以在 GCE 的网络中被路由。 +而 GCE 本身并不知道这些 IP，所以不会对访问外网的流量进行 NAT。 +为了实现此目的，使用了 `iptables` 规则来伪装（又称为 SNAT，使数据包看起来好像是来自“节点”本身）， +将通信绑定到 GCE 项目网络（10.0.0.0/8）之外的 IP。 ```shell iptables -t nat -A POSTROUTING ! -d 10.0.0.0/8 -o eth0 -j MASQUERADE @@ -389,7 +474,7 @@ iptables -t nat -A POSTROUTING ! -d 10.0.0.0/8 -o eth0 -j MASQUERADE sysctl net.ipv4.ip_forward=1 ``` -所有这些的结果是所有 `Pods` 都可以互相访问，并且可以将流量发送到互联网。 +所有这些的结果是所有 Pod 都可以互相访问，并且可以将流量发送到互联网。 <!-- ### Jaguar @@ -402,11 +487,14 @@ sysctl net.ipv4.ip_forward=1 --> ### Jaguar -[Jaguar](https://gitlab.com/sdnlab/jaguar) 是一个基于 OpenDaylight 的 Kubernetes 网络开源解决方案。Jaguar 使用 vxlan 提供覆盖网络，而 Jaguar CNIPlugin 为每个 Pod 提供一个 IP 地址。 +[Jaguar](https://gitlab.com/sdnlab/jaguar) 是一个基于 OpenDaylight 的 Kubernetes 网络开源解决方案。 +Jaguar 使用 vxlan 提供覆盖网络，而 Jaguar CNIPlugin 为每个 Pod 提供一个 IP 地址。 ### k-vswitch -[k-vswitch](https://github.com/k-vswitch/k-vswitch) 是一个基于 [Open vSwitch](https://www.openvswitch.org/) 的简易 Kubernetes 网络插件。它利用 Open vSwitch 中现有的功能来提供强大的网络插件，该插件易于操作，高效且安全。 +[k-vswitch](https://github.com/k-vswitch/k-vswitch) 是一个基于 +[Open vSwitch](https://www.openvswitch.org/) 的简易 Kubernetes 网络插件。 +它利用 Open vSwitch 中现有的功能来提供强大的网络插件，该插件易于操作，高效且安全。 <!-- ### Knitter @@ -417,23 +505,29 @@ sysctl net.ipv4.ip_forward=1 [Kube-OVN](https://github.com/alauda/kube-ovn) is an OVN-based kubernetes network fabric for enterprises. With the help of OVN/OVS, it provides some advanced overlay network features like subnet, QoS, static IP allocation, traffic mirroring, gateway, openflow-based network policy and service proxy. --> - ### Knitter -[Knitter](https://github.com/ZTE/Knitter/) 是一个支持 Kubernetes 中实现多个网络系统的解决方案。它提供了租户管理和网络管理的功能。除了多个网络平面外，Knitter 还包括一组端到端的 NFV 容器网络解决方案，例如为应用程序保留 IP 地址，IP 地址迁移等。 +[Knitter](https://github.com/ZTE/Knitter/) 是一个支持 Kubernetes 中实现多个网络系统的解决方案。 +它提供了租户管理和网络管理的功能。除了多个网络平面外，Knitter 还包括一组端到端的 NFV 容器网络解决方案， +例如为应用程序保留 IP 地址、IP 地址迁移等。 ### Kube-OVN -[Kube-OVN](https://github.com/alauda/kube-ovn) 是一个基于 OVN 的用于企业的 Kubernetes 网络架构。借助于 OVN/OVS ，它提供了一些高级覆盖网络功能，例如子网、QoS、静态 IP 分配、流量镜像、网关、基于开放流的网络策略和服务代理。 +[Kube-OVN](https://github.com/alauda/kube-ovn) 是一个基于 OVN 的用于企业的 Kubernetes 网络架构。 +借助于 OVN/OVS ，它提供了一些高级覆盖网络功能，例如子网、QoS、静态 IP 分配、流量镜像、网关、 +基于 openflow 的网络策略和服务代理。 <!-- ### Kube-router -[Kube-router](https://github.com/cloudnativelabs/kube-router) is a purpose-built networking solution for Kubernetes that aims to provide high performance and operational simplicity. Kube-router provides a Linux [LVS/IPVS](http://www.linuxvirtualserver.org/software/ipvs.html)-based service proxy, a Linux kernel forwarding-based pod-to-pod networking solution with no overlays, and iptables/ipset-based network policy enforcer. +[Kube-router](https://github.com/cloudnativelabs/kube-router) is a purpose-built networking solution for Kubernetes that aims to provide high performance and operational simplicity. Kube-router provides a Linux [LVS/IPVS](https://www.linuxvirtualserver.org/software/ipvs.html)-based service proxy, a Linux kernel forwarding-based pod-to-pod networking solution with no overlays, and iptables/ipset-based network policy enforcer. --> ### Kube-router -[Kube-router](https://github.com/cloudnativelabs/kube-router) 是 Kubernetes 的专用网络解决方案，旨在提供高性能和易操作性。 Kube-router 提供了一个基于 Linux [LVS/IPVS](http://www.linuxvirtualserver.org/software/ipvs.html) 的服务代理，一个基于 Linux 内核转发的无覆盖 Pod-to-Pod 网络解决方案，和基于 iptables/ipset 的网络策略执行器。 +[Kube-router](https://github.com/cloudnativelabs/kube-router) 是 Kubernetes 的专用网络解决方案， +旨在提供高性能和易操作性。 +Kube-router 提供了一个基于 Linux [LVS/IPVS](https://www.linuxvirtualserver.org/software/ipvs.html) +的服务代理、一个基于 Linux 内核转发的无覆盖 Pod-to-Pod 网络解决方案和基于 iptables/ipset 的网络策略执行器。 <!-- ### L2 networks and linux bridging @@ -445,14 +539,17 @@ work, but has not been thoroughly tested. If you use this technique and perfect the process, please let us know. Follow the "With Linux Bridge devices" section of [this very nice -tutorial](http://blog.oddbit.com/2014/08/11/four-ways-to-connect-a-docker/) from +tutorial](https://blog.oddbit.com/2014/08/11/four-ways-to-connect-a-docker/) from Lars Kellogg-Stedman. --> ### L2 networks and linux bridging -如果你具有一个“哑”的L2网络，例如“裸机”环境中的简单交换机，则应该能够执行与上述 GCE 设置类似的操作。请注意，这些说明仅是非常简单的尝试过-似乎可行，但尚未经过全面测试。如果您使用此技术并完善了流程，请告诉我们。 +如果你具有一个“哑”的L2网络，例如“裸机”环境中的简单交换机，则应该能够执行与上述 GCE 设置类似的操作。 +请注意，这些说明仅是非常简单的尝试过-似乎可行，但尚未经过全面测试。 +如果您使用此技术并完善了流程，请告诉我们。 -根据 Lars Kellogg-Stedman 的这份非常不错的“Linux 网桥设备”[使用说明](http://blog.oddbit.com/2014/08/11/four-ways-to-connect-a-docker/)来进行操作。 +根据 Lars Kellogg-Stedman 的这份非常不错的“Linux 网桥设备” +[使用说明](https://blog.oddbit.com/2014/08/11/four-ways-to-connect-a-docker/)来进行操作。 <!-- ### Multus (a Multi Network plugin) @@ -463,9 +560,23 @@ Multus supports all [reference plugins](https://github.com/containernetworking/p --> ### Multus (a Multi Network plugin) -[Multus](https://github.com/Intel-Corp/multus-cni) 是一个多 CNI 插件，使用 Kubernetes 中基于 CRD 的网络对象来支持实现 Kubernetes 多网络系统。 +[Multus](https://github.com/Intel-Corp/multus-cni) 是一个多 CNI 插件， +使用 Kubernetes 中基于 CRD 的网络对象来支持实现 Kubernetes 多网络系统。 -Multus 支持所有[参考插件]（https://github.com/containernetworking/plugins）（比如： [Flannel](https://github.com/containernetworking/plugins/tree/master/plugins/meta/flannel)、[DHCP](https://github.com/containernetworking/plugins/tree/master/plugins/ipam/dhcp)、[Macvlan](https://github.com/containernetworking/plugins/tree/master/plugins/main/macvlan) ），来实现 CNI 规范和第三方插件（比如： [Calico](https://github.com/projectcalico/cni-plugin)、[Weave](https://github.com/weaveworks/weave)、[Cilium](https://github.com/cilium/cilium)、[Contiv](https://github.com/contiv/netplugin)）。除此之外， Multus 还支持 [SRIOV](https://github.com/hustcat/sriov-cni)、[DPDK](https://github.com/Intel-Corp/sriov-cni)、[OVS-DPDK & VPP](https://github.com/intel/vhost-user-net-plugin) 的工作负载，以及 Kubernetes 中基于云的本机应用程序和基于 NFV 的应用程序。 +Multus 支持所有[参考插件](https://github.com/containernetworking/plugins)（比如： +[Flannel](https://github.com/containernetworking/plugins/tree/master/plugins/meta/flannel)、 +[DHCP](https://github.com/containernetworking/plugins/tree/master/plugins/ipam/dhcp)、 +[Macvlan](https://github.com/containernetworking/plugins/tree/master/plugins/main/macvlan) ） +来实现 CNI 规范和第三方插件（比如： +[Calico](https://github.com/projectcalico/cni-plugin)、 +[Weave](https://github.com/weaveworks/weave)、 +[Cilium](https://github.com/cilium/cilium)、 +[Contiv](https://github.com/contiv/netplugin)）。 +除此之外， Multus 还支持 +[SRIOV](https://github.com/hustcat/sriov-cni)、 +[DPDK](https://github.com/Intel-Corp/sriov-cni)、 +[OVS-DPDK & VPP](https://github.com/intel/vhost-user-net-plugin) 的工作负载， +以及 Kubernetes 中基于云的本机应用程序和基于 NFV 的应用程序。 <!-- ### NSX-T @@ -476,22 +587,29 @@ Multus 支持所有[参考插件]（https://github.com/containernetworking/plugi --> ### NSX-T -[VMware NSX-T](https://docs.vmware.com/en/VMware-NSX-T/index.html) 是一个网络虚拟化的安全平台。 NSX-T 可以为多云及多系统管理程序环境提供网络虚拟化，并专注于具有异构端点和技术堆栈的新兴应用程序框架和体系结构。除了 vSphere 管理程序之外，这些环境还包括其他虚拟机管理程序，例如 KVM，容器和裸机。 +[VMware NSX-T](https://docs.vmware.com/en/VMware-NSX-T/index.html) 是一个网络虚拟化和安全平台。 +NSX-T 可以为多云及多系统管理程序环境提供网络虚拟化，并专注于具有异构端点和技术堆栈的新兴应用程序框架和体系结构。 +除了 vSphere 管理程序之外，这些环境还包括其他虚拟机管理程序，例如 KVM、容器和裸机。 -[NSX-T Container Plug-in (NCP)](https://docs.vmware.com/en/VMware-NSX-T/2.0/nsxt_20_ncp_kubernetes.pdf) 提供了 NSX-T 与容器协调器（例如 Kubernetes）之间的结合， 以及 NSX-T 与基于容器的 CaaS/PaaS 平台（例如 Pivotal Container Service（PKS） 和 OpenShift ）之间的集成。 +[NSX-T Container Plug-in (NCP)](https://docs.vmware.com/en/VMware-NSX-T/2.0/nsxt_20_ncp_kubernetes.pdf) +提供了 NSX-T 与容器协调器（例如 Kubernetes）之间的结合， +以及 NSX-T 与基于容器的 CaaS/PaaS 平台（例如 Pivotal Container Service（PKS）和 OpenShift）之间的集成。 <!-- ### Nuage Networks VCS (Virtualized Cloud Services) -[Nuage](http://www.nuagenetworks.net) provides a highly scalable policy-based Software-Defined Networking (SDN) platform. Nuage uses the open source Open vSwitch for the data plane along with a feature rich SDN Controller built on open standards. +[Nuage](https://www.nuagenetworks.net) provides a highly scalable policy-based Software-Defined Networking (SDN) platform. Nuage uses the open source Open vSwitch for the data plane along with a feature rich SDN Controller built on open standards. The Nuage platform uses overlays to provide seamless policy-based networking between Kubernetes Pods and non-Kubernetes environments (VMs and bare metal servers). Nuage's policy abstraction model is designed with applications in mind and makes it easy to declare fine-grained policies for applications.The platform's real-time analytics engine enables visibility and security monitoring for Kubernetes applications. --> ### Nuage Networks VCS (Virtualized Cloud Services) -[Nuage](http://www.nuagenetworks.net) 提供了一个高度可扩展的基于策略的软件定义网络（SDN）平台，Nuage 使用开源的 Open vSwitch 作为数据平面，以及基于开放标准构建具有丰富功能的 SDN 控制器。 +[Nuage](https://www.nuagenetworks.net) 提供了一个高度可扩展的基于策略的软件定义网络（SDN）平台。 +Nuage 使用开源的 Open vSwitch 作为数据平面，以及基于开放标准构建具有丰富功能的 SDN 控制器。 -Nuage 平台使用覆盖层在 Kubernetes Pod 和非 Kubernetes 环境（VM 和裸机服务器）之间提供基于策略的无缝联网。Nuage 的策略抽象模型在设计时就考虑到了应用程序，并且可以轻松声明应用程序的细粒度策略。该平台的实时分析引擎可为 Kubernetes 应用程序提供可见性和安全性监控。 +Nuage 平台使用覆盖层在 Kubernetes Pod 和非 Kubernetes 环境（VM 和裸机服务器）之间提供基于策略的无缝联网。 +Nuage 的策略抽象模型在设计时就考虑到了应用程序，并且可以轻松声明应用程序的细粒度策略。 +该平台的实时分析引擎可为 Kubernetes 应用程序提供可见性和安全性监控。 <!-- ### OpenVSwitch @@ -510,37 +628,47 @@ at [ovn-kubernetes](https://github.com/openvswitch/ovn-kubernetes). --> ### OpenVSwitch -[OpenVSwitch](https://www.openvswitch.org/) 是一个较为成熟的解决方案，但同时也增加了构建覆盖网络的复杂性，这也得到了几个网络系统的“大商店”的拥护。 +[OpenVSwitch](https://www.openvswitch.org/) 是一个较为成熟的解决方案，但同时也增加了构建覆盖网络的复杂性。 +这也得到了几个网络系统的“大商店”的拥护。 ### OVN (开放式虚拟网络) -OVN 是一个由 Open vSwitch 社区开发的开源的网络虚拟化解决方案。它允许创建逻辑交换器，逻辑路由，状态 ACL，负载均衡等等来建立不同的虚拟网络拓扑。该项目有一个特定的Kubernetes插件和文档 [ovn-kubernetes](https://github.com/openvswitch/ovn-kubernetes)。 +OVN 是一个由 Open vSwitch 社区开发的开源的网络虚拟化解决方案。 +它允许创建逻辑交换器、逻辑路由、状态 ACL、负载均衡等等来建立不同的虚拟网络拓扑。 +该项目有一个特定的Kubernetes插件和文档 [ovn-kubernetes](https://github.com/openvswitch/ovn-kubernetes)。 <!-- ### Project Calico -[Project Calico](http://docs.projectcalico.org/) is an open source container networking provider and network policy engine. +[Project Calico](https://docs.projectcalico.org/) is an open source container networking provider and network policy engine. Calico provides a highly scalable networking and network policy solution for connecting Kubernetes pods based on the same IP networking principles as the internet, for both Linux (open source) and Windows (proprietary - available from [Tigera](https://www.tigera.io/essentials/)). Calico can be deployed without encapsulation or overlays to provide high-performance, high-scale data center networking. Calico also provides fine-grained, intent based network security policy for Kubernetes pods via its distributed firewall. Calico can also be run in policy enforcement mode in conjunction with other networking solutions such as Flannel, aka [canal](https://github.com/tigera/canal), or native GCE, AWS or Azure networking. --> -### Project Calico +### Calico 项目 {#project-calico} -[Project Calico](http://docs.projectcalico.org/) 是一个开源的容器网络提供者和网络策略引擎。 +[Calico 项目](https://docs.projectcalico.org/) 是一个开源的容器网络提供者和网络策略引擎。 -Calico 提供了高度可扩展的网络和网络解决方案，使用基于与 Internet 相同的 IP 网络原理来连接 Kubernetes Pod，适用于 Linux （开放源代码）和 Windows（专有-可从 [Tigera](https//www.tigera.io/essentials/) 获得。可以无需封装或覆盖即可部署 Calico，以提供高性能，高可扩的数据中心网络。Calico 还通过其分布式防火墙为 Kubernetes Pod 提供了基于意图的细粒度网络安全策略。 +Calico 提供了高度可扩展的网络和网络解决方案，使用基于与 Internet 相同的 IP 网络原理来连接 Kubernetes Pod， +适用于 Linux （开放源代码）和 Windows（专有-可从 [Tigera](https://www.tigera.io/essentials/) 获得。 +可以无需封装或覆盖即可部署 Calico，以提供高性能，高可扩的数据中心网络。 +Calico 还通过其分布式防火墙为 Kubernetes Pod 提供了基于意图的细粒度网络安全策略。 -Calico 还可以和其他的网络解决方案（比如 Flannel、[canal](https://github.com/tigera/canal) 或本机 GCE、AWS、Azure 等）一起以策略实施模式运行。 +Calico 还可以和其他的网络解决方案（比如 Flannel、[canal](https://github.com/tigera/canal) +或原生 GCE、AWS、Azure 网络等）一起以策略实施模式运行。 <!-- ### Romana -[Romana](http://romana.io) is an open source network and security automation solution that lets you deploy Kubernetes without an overlay network. Romana supports Kubernetes [Network Policy](/docs/concepts/services-networking/network-policies/) to provide isolation across network namespaces. +[Romana](https://romana.io) is an open source network and security automation solution that lets you deploy Kubernetes without an overlay network. Romana supports Kubernetes [Network Policy](/docs/concepts/services-networking/network-policies/) to provide isolation across network namespaces. --> ### Romana -[Romana](http://romana.io) 是一个开源网络和安全自动化解决方案。它可以让你在没有覆盖网络的情况下部署 Kubernetes。Romana 支持 Kubernetes [网络策略](/docs/concepts/services-networking/network-policies/)，来提供跨网络命名空间的隔离。 +[Romana](https://romana.io) 是一个开源网络和安全自动化解决方案。 +它可以让你在没有覆盖网络的情况下部署 Kubernetes。 +Romana 支持 Kubernetes [网络策略](/zh/docs/concepts/services-networking/network-policies/)， +来提供跨网络命名空间的隔离。 <!-- ### Weave Net from Weaveworks @@ -553,19 +681,20 @@ to run, and in both cases, the network provides one IP address per pod - as is s --> ### Weaveworks 的 Weave Net -[Weave Net](https://www.weave.works/products/weave-net/) 是 Kubernetes 及其托管应用程序的弹性和易于使用的网络系统。Weave Net 可以作为 [CNI plug-in](https://www.weave.works/docs/net/latest/cni-plugin/) 运行或者独立运行。在这两种运行方式里，都不需要任何配置或额外的代码即可运行，并且在两种情况下，网络都为每个 Pod 提供一个 IP 地址-这是 Kubernetes 的标准配置。 - - +[Weave Net](https://www.weave.works/products/weave-net/) 是 Kubernetes 及其 +托管应用程序的弹性且易于使用的网络系统。 +Weave Net 可以作为 [CNI 插件](https://www.weave.works/docs/net/latest/cni-plugin/) 运行或者独立运行。 +在这两种运行方式里，都不需要任何配置或额外的代码即可运行，并且在两种情况下， +网络都为每个 Pod 提供一个 IP 地址 -- 这是 Kubernetes 的标准配置。 ## {{% heading "whatsnext" %}} - <!-- The early design of the networking model and its rationale, and some future plans are described in more detail in the [networking design document](https://git.k8s.io/community/contributors/design-proposals/network/networking.md). --> -网络模型的早期设计、运行原理以及未来的一些计划，都在 [networking design -document](https://git.k8s.io/community/contributors/design-proposals/network/networking.md) 文档里进行了更详细的描述。 - +网络模型的早期设计、运行原理以及未来的一些计划，都在 +[联网设计文档](https://git.k8s.io/community/contributors/design-proposals/network/networking.md) +里有更详细的描述。 diff --git a/content/zh/docs/concepts/cluster-administration/proxies.md b/content/zh/docs/concepts/cluster-administration/proxies.md index 5b1941d4ae..808d8b31ec 100644 --- a/content/zh/docs/concepts/cluster-administration/proxies.md +++ b/content/zh/docs/concepts/cluster-administration/proxies.md @@ -1,19 +1,42 @@ --- title: Kubernetes 中的代理 content_type: concept +weight: 90 --- +<!-- +title: Proxies in Kubernetes +content_type: concept +weight: 90 +--> <!-- overview --> +<!-- +This page explains proxies used with Kubernetes. +--> 本文讲述了 Kubernetes 中所使用的代理。 - <!-- body --> -## 代理 +<!-- +## Proxies + +There are several different proxies you may encounter when using Kubernetes: +--> +## 代理 {#proxies} 用户在使用 Kubernetes 的过程中可能遇到几种不同的代理（proxy）： -1. [kubectl proxy](/docs/tasks/access-application-cluster/access-cluster/#directly-accessing-the-rest-api)： +<!-- +1. The [kubectl proxy](/docs/tasks/access-application-cluster/access-cluster/#directly-accessing-the-rest-api): + + - runs on a user's desktop or in a pod + - proxies from a localhost address to the Kubernetes apiserver + - client to proxy uses HTTP + - proxy to apiserver uses HTTPS + - locates apiserver + - adds authentication headers +--> +1. [kubectl proxy](/zh/docs/tasks/access-application-cluster/access-cluster/#directly-accessing-the-rest-api)： - 运行在用户的桌面或 pod 中 - 从本机地址到 Kubernetes apiserver 的代理 @@ -22,7 +45,18 @@ content_type: concept - 指向 apiserver - 添加认证头信息 -1. [apiserver proxy](/docs/tasks/access-application-cluster/access-cluster/#discovering-builtin-services)： +<!-- +1. The [apiserver proxy](/docs/tasks/access-application-cluster/access-cluster/#discovering-builtin-services): + + - is a bastion built into the apiserver + - connects a user outside of the cluster to cluster IPs which otherwise might not be reachable + - runs in the apiserver processes + - client to proxy uses HTTPS (or http if apiserver so configured) + - proxy to target may use HTTP or HTTPS as chosen by proxy using available information + - can be used to reach a Node, Pod, or Service + - does load balancing when used to reach a Service +--> +2. [apiserver proxy](/zh/docs/tasks/access-application-cluster/access-cluster/#discovering-builtin-services)： - 是一个建立在 apiserver 内部的“堡垒” - 将集群外部的用户与群集 IP 相连接，这些IP是无法通过其他方式访问的 @@ -32,31 +66,66 @@ content_type: concept - 可以用来访问 Node、 Pod 或 Service - 当用来访问 Service 时，会进行负载均衡 -1. [kube proxy](/docs/concepts/services-networking/service/#ips-and-vips)： +<!-- +1. The [kube proxy](/docs/concepts/services-networking/service/#ips-and-vips): + + - runs on each node + - proxies UDP, TCP and SCTP + - does not understand HTTP + - provides load balancing + - is just used to reach services +--> +3. [kube proxy](/zh/docs/concepts/services-networking/service/#ips-and-vips)： - 在每个节点上运行 - - 代理 UDP 和 TCP + - 代理 UDP、TCP 和 SCTP - 不支持 HTTP - 提供负载均衡能力 - 只用来访问 Service -1. apiserver 之前的代理/负载均衡器： +<!-- +1. A Proxy/Load-balancer in front of apiserver(s): - - 在不同集群间的存在形式和实现不同 (如 nginx) - - 位于所有客户端和一个或多个 apiserver 之间 - - 存在多个 apiserver 时，扮演负载均衡器的角色 + - existence and implementation varies from cluster to cluster (e.g. nginx) + - sits between all clients and one or more apiservers + - acts as load balancer if there are several apiservers. +--> +4. apiserver 之前的代理/负载均衡器： -1. 外部服务的云负载均衡器： + - 在不同集群中的存在形式和实现不同 (如 nginx) + - 位于所有客户端和一个或多个 API 服务器之间 + - 存在多个 API 服务器时，扮演负载均衡器的角色 - - 由一些云供应商提供 (如AWS ELB、 Google Cloud Load Balancer) - - Kubernetes service 为 `LoadBalancer` 类型时自动创建 - - 只使用 UDP/TCP 协议 - - 不同云供应商的实现不同。 +<!-- +1. Cloud Load Balancers on external services: + + - are provided by some cloud providers (e.g. AWS ELB, Google Cloud Load Balancer) + - are created automatically when the Kubernetes service has type `LoadBalancer` + - usually supports UDP/TCP only + - SCTP support is up to the load balancer implementation of the cloud provider + - implementation varies by cloud provider. +--> +5. 外部服务的云负载均衡器： + + - 由一些云供应商提供 (如 AWS ELB、Google Cloud Load Balancer) + - Kubernetes 服务类型为 `LoadBalancer` 时自动创建 + - 通常仅支持 UDP/TCP 协议 + - SCTP 支持取决于云供应商的负载均衡器实现 + - 不同云供应商的云负载均衡器实现不同 + +<!-- +Kubernetes users will typically not need to worry about anything other than the first two types. The cluster admin +will typically ensure that the latter types are setup correctly. +--> Kubernetes 用户通常只需要关心前两种类型的代理，集群管理员通常需要确保后面几种类型的代理设置正确。 +<!-- +## Requesting redirects + +Proxies have replaced redirect capabilities. Redirects have been deprecated. +--> ## 请求重定向 -代理已经取代重定向功能，重定向已被弃用。 - +代理已经取代重定向功能，重定向功能已被弃用。 diff --git a/content/zh/docs/concepts/configuration/configmap.md b/content/zh/docs/concepts/configuration/configmap.md index 7448e77208..d1aa8fa01a 100644 --- a/content/zh/docs/concepts/configuration/configmap.md +++ b/content/zh/docs/concepts/configuration/configmap.md @@ -19,7 +19,6 @@ ConfigMap 并不提供保密或者加密功能。如果你想存储的数据是 {{< /caution >}} - <!-- body --> <!-- ## Motivation @@ -59,9 +58,11 @@ The name of a ConfigMap must be a valid --> ## ConfigMap 对象 -ConfigMap 是一个 API [对象](/docs/concepts/overview/working-with-objects/kubernetes-objects/)，让你可以存储其他对象所需要使用的配置。和其他 Kubernetes 对象都有一个 `spec` 不同的是，ConfigMap 使用 `data` 块来存储元素（键名）和它们的值。 +ConfigMap 是一个 API [对象](/zh/docs/concepts/overview/working-with-objects/kubernetes-objects/)， +让你可以存储其他对象所需要使用的配置。 +和其他 Kubernetes 对象都有一个 `spec` 不同的是，ConfigMap 使用 `data` 块来存储元素（键名）和它们的值。 -ConfigMap 的名字必须是一个合法的 [DNS 子域名](/docs/concepts/overview/working-with-objects/names#dns-subdomain-names)。 +ConfigMap 的名字必须是一个合法的 [DNS 子域名](/zh/docs/concepts/overview/working-with-objects/names#dns-subdomain-names)。 <!-- ## ConfigMaps and Pods @@ -87,7 +88,7 @@ metadata: name: game-demo data: # 类属性键；每一个键都映射到一个简单的值 - player_initial_lives: 3 + player_initial_lives: "3" ui_properties_file_name: "user-interface.properties" # # 类文件键 @@ -216,15 +217,14 @@ ConfigMap 最常见的用法是为同一命名空间里某 Pod 中运行的容 ## {{% heading "whatsnext" %}} - <!-- * Read about [Secrets](/docs/concepts/configuration/secret/). * Read [Configure a Pod to Use a ConfigMap](/docs/tasks/configure-pod-container/configure-pod-configmap/). * Read [The Twelve-Factor App](https://12factor.net/) to understand the motivation for separating code from configuration. --> -* 阅读 [Secret](/docs/concepts/configuration/secret/)。 -* 阅读 [配置 Pod 来使用 ConfigMap](/docs/tasks/configure-pod-container/configure-pod-configmap/)。 +* 阅读 [Secret](/zh/docs/concepts/configuration/secret/)。 +* 阅读 [配置 Pod 来使用 ConfigMap](/zh/docs/tasks/configure-pod-container/configure-pod-configmap/)。 * 阅读 [Twelve-Factor 应用](https://12factor.net/) 来了解将代码和配置分开的动机。 diff --git a/content/zh/docs/concepts/configuration/manage-compute-resources-container.md b/content/zh/docs/concepts/configuration/manage-compute-resources-container.md deleted file mode 100644 index 776b977736..0000000000 --- a/content/zh/docs/concepts/configuration/manage-compute-resources-container.md +++ /dev/null @@ -1,972 +0,0 @@ ---- -title: 为容器管理计算资源 -content_type: concept -weight: 20 -feature: - title: 自动装箱 - description: > - 根据资源需求和其他约束自动放置容器，同时不会牺牲可用性，将任务关键工作负载和尽力服务工作负载进行混合放置，以提高资源利用率并节省更多资源。 ---- - -<!-- ---- -title: Managing Compute Resources for Containers -content_type: concept -weight: 20 -feature: - title: Automatic binpacking - description: > - Automatically places containers based on their resource requirements and other constraints, while not sacrificing availability. Mix critical and best-effort workloads in order to drive up utilization and save even more resources. ---- ---> - -<!-- overview --> - -<!-- -When you specify a [Pod](/docs/concepts/workloads/pods/pod/), you can optionally specify how -much CPU and memory (RAM) each Container needs. When Containers have resource -requests specified, the scheduler can make better decisions about which nodes to -place Pods on. And when Containers have their limits specified, contention for -resources on a node can be handled in a specified manner. For more details about -the difference between requests and limits, see -[Resource QoS](https://git.k8s.io/community/contributors/design-proposals/node/resource-qos.md). ---> -当您定义 [Pod](/docs/user-guide/pods) 的时候可以选择为每个容器指定需要的 CPU 和内存（RAM）大小。当为容器指定了资源请求后，调度器就能够更好的判断出将容器调度到哪个节点上。如果您还为容器指定了资源限制，Kubernetes 就可以按照指定的方式来处理节点上的资源竞争。关于资源请求和限制的不同点和更多资料请参考 [Resource QoS](https://git.k8s.io/community/contributors/design-proposals/resource-qos.md)。 - - - - -<!-- body --> - -<!-- -## Resource types -*CPU* and *memory* are each a *resource type*. A resource type has a base unit. -CPU is specified in units of cores, and memory is specified in units of bytes. - -If you're using Kubernetes v1.14 or newer, you can specify _huge page_ resources. -Huge pages are a Linux-specific feature where the node kernel allocates blocks of memory -that are much larger than the default page size. - -For example, on a system where the default page size is 4KiB, you could specify a limit, -`hugepages-2Mi: 80Mi`. If the container tries allocating over 40 2MiB huge pages (a -total of 80 MiB), that allocation fails. - -{{< note >}} -You cannot overcommit `hugepages-*` resources. -This is different from the `memory` and `cpu` resources. -{{< /note >}} - -CPU and memory are collectively referred to as *compute resources*, or just -*resources*. Compute -resources are measurable quantities that can be requested, allocated, and -consumed. They are distinct from -[API resources](/docs/concepts/overview/kubernetes-api/). API resources, such as Pods and -[Services](/docs/concepts/services-networking/service/) are objects that can be read and modified -through the Kubernetes API server. ---> - -## 资源类型 - -*CPU* 和*内存*都是*资源类型*。资源类型具有基本单位。CPU 的单位是核心数，内存的单位是字节。 - -如果您使用的是 Kubernetes v1.14 或更高版本，则可以指定巨页资源。巨页是 Linux 特有的功能，节点内核在其中分配的内存块比默认页大小大得多。 - -例如，在默认页面大小为 4KiB 的系统上，您可以指定一个限制，`hugepages-2Mi: 80Mi`。如果容器尝试分配 40 个 2MiB 大页面（总共 80 MiB ），则分配失败。 - -{{< note >}} -您不能过量使用`hugepages- *`资源。 -这与`memory`和`cpu`资源不同。 -{{< /note >}} - -CPU和内存统称为*计算资源*，也可以称为*资源*。计算资源的数量是可以被请求、分配、消耗和可测量的。它们与 [API 资源](/docs/concepts/overview/kubernetes-api/) 不同。 API 资源（如 Pod 和 [Service](/docs/concepts/services-networking/service/)）是可通过 Kubernetes API server 读取和修改的对象。 - -<!-- -## Resource requests and limits of Pod and Container - -Each Container of a Pod can specify one or more of the following: - -* `spec.containers[].resources.limits.cpu` -* `spec.containers[].resources.limits.memory` -* `spec.containers[].resources.requests.cpu` -* `spec.containers[].resources.requests.memory` -Although requests and limits can only be specified on individual Containers, it -is convenient to talk about Pod resource requests and limits. A -*Pod resource request/limit* for a particular resource type is the sum of the -resource requests/limits of that type for each Container in the Pod. ---> - -## Pod 和 容器的资源请求和限制 - -Pod 中的每个容器都可以指定以下的一个或者多个值： - -- `spec.containers[].resources.limits.cpu` -- `spec.containers[].resources.limits.memory` -- `spec.containers[].resources.requests.cpu` -- `spec.containers[].resources.requests.memory` - -尽管只能在个别容器上指定请求和限制，但是我们可以方便地计算出 Pod 资源请求和限制。特定资源类型的Pod 资源请求/限制是 Pod 中每个容器的该类型的资源请求/限制的总和。 - -<!-- -## Meaning of CPU - -Limits and requests for CPU resources are measured in *cpu* units. -One cpu, in Kubernetes, is equivalent to: - -- 1 AWS vCPU -- 1 GCP Core -- 1 Azure vCore -- 1 IBM vCPU -- 1 *Hyperthread* on a bare-metal Intel processor with Hyperthreading -Fractional requests are allowed. A Container with -`spec.containers[].resources.requests.cpu` of `0.5` is guaranteed half as much -CPU as one that asks for 1 CPU. The expression `0.1` is equivalent to the -expression `100m`, which can be read as "one hundred millicpu". Some people say -"one hundred millicores", and this is understood to mean the same thing. A -request with a decimal point, like `0.1`, is converted to `100m` by the API, and -precision finer than `1m` is not allowed. For this reason, the form `100m` might -be preferred. -CPU is always requested as an absolute quantity, never as a relative quantity; -0.1 is the same amount of CPU on a single-core, dual-core, or 48-core machine. ---> - -## CPU 的含义 - -CPU 资源的限制和请求以 *cpu* 为单位。 - -Kubernetes 中的一个 cpu 等于： - -- 1 AWS vCPU -- 1 GCP Core -- 1 Azure vCore -- 1 *Hyperthread* 在带有超线程的裸机 Intel 处理器上 - -允许浮点数请求。具有 `spec.containers[].resources.requests.cpu` 为 0.5 的容器保证了一半 CPU 要求 1 CPU的一半。表达式 `0.1` 等价于表达式 `100m`，可以看作 “100 millicpu”。有些人说成是“一百毫 cpu”，其实说的是同样的事情。具有小数点（如 `0.1`）的请求由 API 转换为`100m`，精度不超过 `1m`。因此，可能会优先选择 `100m` 的形式。 - -CPU 总是要用绝对数量，不可以使用相对数量；0.1 的 CPU 在单核、双核、48核的机器中的意义是一样的。 - -<!-- -## Meaning of memory -Limits and requests for `memory` are measured in bytes. You can express memory as -a plain integer or as a fixed-point integer using one of these suffixes: -E, P, T, G, M, K. You can also use the power-of-two equivalents: Ei, Pi, Ti, Gi, -Mi, Ki. For example, the following represent roughly the same value: ---> - -## 内存的含义 - -内存的限制和请求以字节为单位。您可以使用以下后缀之一作为平均整数或定点整数表示内存：E，P，T，G，M，K。您还可以使用两个字母的等效的幂数：Ei，Pi，Ti ，Gi，Mi，Ki。例如，以下代表大致相同的值： - -```shell -128974848, 129e6, 129M, 123Mi -``` - -<!-- -Here's an example. -The following Pod has two Containers. Each Container has a request of 0.25 cpu -and 64MiB (2<sup>26</sup> bytes) of memory. Each Container has a limit of 0.5 -cpu and 128MiB of memory. You can say the Pod has a request of 0.5 cpu and 128 -MiB of memory, and a limit of 1 cpu and 256MiB of memory. ---> - -下面是个例子。 - -以下 Pod 有两个容器。每个容器的请求为 0.25 cpu 和 64MiB（2<sup>26</sup> 字节）内存，每个容器的限制为 0.5 cpu 和 128MiB 内存。您可以说该 Pod 请求 0.5 cpu 和 128 MiB 的内存，限制为 1 cpu 和 256MiB 的内存。 - -```yaml -apiVersion: v1 -kind: Pod -metadata: - name: frontend -spec: - containers: - - name: db - image: mysql - env: - - name: MYSQL_ROOT_PASSWORD - value: "password" - resources: - requests: - memory: "64Mi" - cpu: "250m" - limits: - memory: "128Mi" - cpu: "500m" - - name: wp - image: wordpress - resources: - requests: - memory: "64Mi" - cpu: "250m" - limits: - memory: "128Mi" - cpu: "500m" -``` - -<!-- -## How Pods with resource requests are scheduled -When you create a Pod, the Kubernetes scheduler selects a node for the Pod to -run on. Each node has a maximum capacity for each of the resource types: the -amount of CPU and memory it can provide for Pods. The scheduler ensures that, -for each resource type, the sum of the resource requests of the scheduled -Containers is less than the capacity of the node. Note that although actual memory -or CPU resource usage on nodes is very low, the scheduler still refuses to place -a Pod on a node if the capacity check fails. This protects against a resource -shortage on a node when resource usage later increases, for example, during a -daily peak in request rate. ---> - -## 具有资源请求的 Pod 如何调度 - -当您创建一个 Pod 时，Kubernetes 调度程序将为 Pod 选择一个节点。每个节点具有每种资源类型的最大容量：可为 Pod 提供的 CPU 和内存量。调度程序确保对于每种资源类型，调度的容器的资源请求的总和小于节点的容量。请注意，尽管节点上的实际内存或 CPU 资源使用量非常低，但如果容量检查失败，则调度程序仍然拒绝在该节点上放置 Pod。当资源使用量稍后增加时，例如在请求率的每日峰值期间，这可以防止节点上的资源短缺。 - -<!-- -## How Pods with resource limits are run - -When the kubelet starts a Container of a Pod, it passes the CPU and memory limits -to the container runtime. - -When using Docker: ---> - -## 具有资源限制的 Pod 如何运行 - -当 kubelet 启动一个 Pod 的容器时，它会将 CPU 和内存限制传递到容器运行时。 - -当使用 Docker 时： - -<!-- -- The `spec.containers[].resources.requests.cpu` is converted to its core value, - which is potentially fractional, and multiplied by 1024. The greater of this number - or 2 is used as the value of the - [`--cpu-shares`](https://docs.docker.com/engine/reference/run/#cpu-share-constraint) - flag in the `docker run` command. - -- The `spec.containers[].resources.limits.cpu` is converted to its millicore value and - multiplied by 100. The resulting value is the total amount of CPU time that a container can use - every 100ms. A container cannot use more than its share of CPU time during this interval. ---> - -- `spec.containers[].resources.requests.cpu` 先被转换为可能是小数的 core 值，再乘以 1024，这个数字和 2 的较大者用作 `docker run` 命令中的[ `--cpu-shares`](https://docs.docker.com/engine/reference/run/#/cpu-share-constraint) 标志的值。 - -- `spec.containers[].resources.limits.cpu` 先被转换为 millicore 值，再乘以 100，结果就是每 100ms 内 container 可以使用的 CPU 总时间。在此时间间隔（100ms）内，一个 container 使用的 CPU 时间不会超过它被分配的时间。 - -<!-- - {{< note >}} - The default quota period is 100ms. The minimum resolution of CPU quota is 1ms. - {{</ note >}} ---> - - {{< note >}} - 默认的配额（quota）周期为 100 毫秒。 CPU配额的最小精度为 1 毫秒。 - {{</ note >}} - -<!-- -- The `spec.containers[].resources.limits.memory` is converted to an integer, and - used as the value of the - [`--memory`](https://docs.docker.com/engine/reference/run/#/user-memory-constraints) - flag in the `docker run` command. ---> - -- `spec.containers[].resources.limits.memory` 被转换为整型，作为 `docker run` 命令中的 [`--memory`](https://docs.docker.com/engine/reference/run/#/user-memory-constraints) 标志的值。 - -<!-- -If a Container exceeds its memory limit, it might be terminated. If it is -restartable, the kubelet will restart it, as with any other type of runtime -failure. - -If a Container exceeds its memory request, it is likely that its Pod will -be evicted whenever the node runs out of memory. - -A Container might or might not be allowed to exceed its CPU limit for extended -periods of time. However, it will not be killed for excessive CPU usage. - -To determine whether a Container cannot be scheduled or is being killed due to -resource limits, see the -[Troubleshooting](#troubleshooting) section. ---> - -如果容器超过其内存限制，则可能会被终止。如果可重新启动，则与所有其他类型的运行时故障一样，kubelet 将重新启动它。 - -如果一个容器超过其内存请求，那么当节点内存不足时，它的 Pod 可能被逐出。 - -容器可能被允许也可能不被允许超过其 CPU 限制时间。但是，由于 CPU 使用率过高，不会被杀死。 - -要确定容器是否由于资源限制而无法安排或被杀死，请参阅[疑难解答](#troubleshooting) 部分。 - -<!-- -## Monitoring compute resource usage - -The resource usage of a Pod is reported as part of the Pod status. - -If optional [tools for monitoring](/docs/tasks/debug-application-cluster/resource-usage-monitoring/) -are available in your cluster, then Pod resource usage can be retrieved either -from the [Metrics API](/docs/tasks/debug-application-cluster/resource-metrics-pipeline/#the-metrics-api) -directly or from your monitoring tools. ---> - -## 监控计算资源使用 - -Pod 的资源使用情况被报告为 Pod 状态的一部分。 - -如果为集群配置了可选 [监控工具](/docs/tasks/debug-application-cluster/resource-usage-monitoring/)，则可以直接从 -[指标 API](/docs/tasks/debug-application-cluster/resource-metrics-pipeline/#the-metrics-api) 或者监控工具检索 Pod 资源的使用情况。 - -<!-- -## Troubleshooting - -### My Pods are pending with event message failedScheduling - -If the scheduler cannot find any node where a Pod can fit, the Pod remains -unscheduled until a place can be found. An event is produced each time the -scheduler fails to find a place for the Pod, like this: ---> - -## 疑难解答 - -### 我的 Pod 处于 pending 状态且事件信息显示 failedScheduling - -如果调度器找不到任何该 Pod 可以匹配的节点，则该 Pod 将保持不可调度状态，直到找到一个可以被调度到的位置。每当调度器找不到 Pod 可以调度的地方时，会产生一个事件，如下所示： - -```shell -kubectl describe pod frontend | grep -A 3 Events -``` -``` -Events: - FirstSeen LastSeen Count From Subobject PathReason Message - 36s 5s 6 {scheduler } FailedScheduling Failed for reason PodExceedsFreeCPU and possibly others -``` - -<!-- -In the preceding example, the Pod named "frontend" fails to be scheduled due to -insufficient CPU resource on the node. Similar error messages can also suggest -failure due to insufficient memory (PodExceedsFreeMemory). In general, if a Pod -is pending with a message of this type, there are several things to try: -- Add more nodes to the cluster. -- Terminate unneeded Pods to make room for pending Pods. -- Check that the Pod is not larger than all the nodes. For example, if all the - nodes have a capacity of `cpu: 1`, then a Pod with a request of `cpu: 1.1` will - never be scheduled. -You can check node capacities and amounts allocated with the -`kubectl describe nodes` command. For example: ---> - -在上述示例中，由于节点上的 CPU 资源不足，名为 “frontend” 的 Pod 将无法调度。由于内存不足（PodExceedsFreeMemory），类似的错误消息也可能会导致失败。一般来说，如果有这种类型的消息而处于 pending 状态，您可以尝试如下几件事情： - -- 向集群添加更多节点。 -- 终止不需要的 Pod，为待处理的 Pod 腾出空间。 -- 检查 Pod 所需的资源是否大于所有节点的资源。 例如，如果全部节点的容量为`cpu：1`，那么一个请求为 `cpu：1.1`的 Pod 永远不会被调度。 - -您可以使用 `kubectl describe nodes` 命令检查节点容量和分配的数量。 例如： - - -```shell -kubectl describe nodes e2e-test-node-pool-4lw4 -``` -``` -Name: e2e-test-node-pool-4lw4 -[ ... lines removed for clarity ...] -Capacity: - cpu: 2 - memory: 7679792Ki - pods: 110 -Allocatable: - cpu: 1800m - memory: 7474992Ki - pods: 110 -[ ... lines removed for clarity ...] -Non-terminated Pods: (5 in total) - Namespace Name CPU Requests CPU Limits Memory Requests Memory Limits - --------- ---- ------------ ---------- --------------- ------------- - kube-system fluentd-gcp-v1.38-28bv1 100m (5%) 0 (0%) 200Mi (2%) 200Mi (2%) - kube-system kube-dns-3297075139-61lj3 260m (13%) 0 (0%) 100Mi (1%) 170Mi (2%) - kube-system kube-proxy-e2e-test-... 100m (5%) 0 (0%) 0 (0%) 0 (0%) - kube-system monitoring-influxdb-grafana-v4-z1m12 200m (10%) 200m (10%) 600Mi (8%) 600Mi (8%) - kube-system node-problem-detector-v0.1-fj7m3 20m (1%) 200m (10%) 20Mi (0%) 100Mi (1%) -Allocated resources: - (Total limits may be over 100 percent, i.e., overcommitted.) - CPU Requests CPU Limits Memory Requests Memory Limits - ------------ ---------- --------------- ------------- - 680m (34%) 400m (20%) 920Mi (12%) 1070Mi (14%) -``` - -<!-- -In the preceding output, you can see that if a Pod requests more than 1120m -CPUs or 6.23Gi of memory, it will not fit on the node. - -By looking at the `Pods` section, you can see which Pods are taking up space on -the node. - -The amount of resources available to Pods is less than the node capacity, because -system daemons use a portion of the available resources. The `allocatable` field -[NodeStatus](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#nodestatus-v1-core) -gives the amount of resources that are available to Pods. For more information, see -[Node Allocatable Resources](https://git.k8s.io/community/contributors/design-proposals/node/node-allocatable.md). -The [resource quota](/docs/concepts/policy/resource-quotas/) feature can be configured -to limit the total amount of resources that can be consumed. If used in conjunction -with namespaces, it can prevent one team from hogging all the resources. ---> - -在上面的输出中，您可以看到如果 Pod 请求超过 1120m CPU 或者 6.23Gi 内存，节点将无法满足。 - -通过查看 `Pods` 部分，您将看到哪些 Pod 占用的节点上的资源。 - -Pod 可用的资源量小于节点容量，因为系统守护程序使用一部分可用资源。 -[NodeStatus](/docs/resources-reference/{{< param "version" >}}/#nodestatus-v1-core) 的 `allocatable` 字段给出了可用于 Pod 的资源量。 -有关更多信息，请参阅 [节点可分配资源](https://git.k8s.io/community/contributors/design-proposals/node-allocatable.md)。 - -可以将 [资源配额](/docs/concepts/policy/resource-quotas/) 功能配置为限制可以使用的资源总量。如果与 namespace 配合一起使用，就可以防止一个团队占用所有资源。 - -<!-- -### My Container is terminated -Your Container might get terminated because it is resource-starved. To check -whether a Container is being killed because it is hitting a resource limit, call -`kubectl describe pod` on the Pod of interest: ---> - -## 我的容器被终止了 - -您的容器可能因为资源枯竭而被终止了。要查看容器是否因为遇到资源限制而被杀死，请在相关的 Pod 上调用 `kubectl describe pod`： - -```shell -kubectl describe pod simmemleak-hra99 -``` -``` -Name: simmemleak-hra99 -Namespace: default -Image(s): saadali/simmemleak -Node: kubernetes-node-tf0f/10.240.216.66 -Labels: name=simmemleak -Status: Running -Reason: -Message: -IP: 10.244.2.75 -Replication Controllers: simmemleak (1/1 replicas created) -Containers: - simmemleak: - Image: saadali/simmemleak - Limits: - cpu: 100m - memory: 50Mi - State: Running - Started: Tue, 07 Jul 2015 12:54:41 -0700 - Last Termination State: Terminated - Exit Code: 1 - Started: Fri, 07 Jul 2015 12:54:30 -0700 - Finished: Fri, 07 Jul 2015 12:54:33 -0700 - Ready: False - Restart Count: 5 -Conditions: - Type Status - Ready False -Events: - FirstSeen LastSeen Count From SubobjectPath Reason Message - Tue, 07 Jul 2015 12:53:51 -0700 Tue, 07 Jul 2015 12:53:51 -0700 1 {scheduler } scheduled Successfully assigned simmemleak-hra99 to kubernetes-node-tf0f - Tue, 07 Jul 2015 12:53:51 -0700 Tue, 07 Jul 2015 12:53:51 -0700 1 {kubelet kubernetes-node-tf0f} implicitly required container POD pulled Pod container image "k8s.gcr.io/pause:0.8.0" already present on machine - Tue, 07 Jul 2015 12:53:51 -0700 Tue, 07 Jul 2015 12:53:51 -0700 1 {kubelet kubernetes-node-tf0f} implicitly required container POD created Created with docker id 6a41280f516d - Tue, 07 Jul 2015 12:53:51 -0700 Tue, 07 Jul 2015 12:53:51 -0700 1 {kubelet kubernetes-node-tf0f} implicitly required container POD started Started with docker id 6a41280f516d - Tue, 07 Jul 2015 12:53:51 -0700 Tue, 07 Jul 2015 12:53:51 -0700 1 {kubelet kubernetes-node-tf0f} spec.containers{simmemleak} created Created with docker id 87348f12526a -``` - -<!-- -In the preceding example, the `Restart Count: 5` indicates that the `simmemleak` -Container in the Pod was terminated and restarted five times. - -You can call `kubectl get pod` with the `-o go-template=...` option to fetch the status -of previously terminated Containers: ---> - -在上面的例子中，`Restart Count: 5` 意味着 Pod 中的 `simmemleak` 容器被终止并重启了五次。 - -您可以使用 `kubectl get pod` 命令加上 `-o go-template=...` 选项来获取之前终止容器的状态。 - - -```shell -kubectl get pod -o go-template='{{range.status.containerStatuses}}{{"Container Name: "}}{{.name}}{{"\r\nLastState: "}}{{.lastState}}{{end}}' simmemleak-hra99 -``` -``` -Container Name: simmemleak -LastState: map[terminated:map[exitCode:137 reason:OOM Killed startedAt:2015-07-07T20:58:43Z finishedAt:2015-07-07T20:58:43Z containerID:docker://0e4095bba1feccdfe7ef9fb6ebffe972b4b14285d5acdec6f0d3ae8a22fad8b2]] -``` - -<!-- -You can see that the Container was terminated because of `reason:OOM Killed`, where `OOM` stands for Out Of Memory. ---> - -您可以看到容器因为 `reason:OOM killed` 被终止，`OOM` 表示 Out Of Memory。 - -<!-- -## Local ephemeral storage -{{< feature-state state="beta" >}} - -Kubernetes version 1.8 introduces a new resource, _ephemeral-storage_ for managing local ephemeral storage. In each Kubernetes node, kubelet's root directory (/var/lib/kubelet by default) and log directory (/var/log) are stored on the root partition of the node. This partition is also shared and consumed by Pods via emptyDir volumes, container logs, image layers and container writable layers. - -This partition is “ephemeral” and applications cannot expect any performance SLAs (Disk IOPS for example) from this partition. Local ephemeral storage management only applies for the root partition; the optional partition for image layer and writable layer is out of scope. - -{{< note >}} -If an optional runtime partition is used, root partition will not hold any image layer or writable layers. -{{< /note >}} ---> - -## 本地临时存储 - -Kubernetes版本1.8引入了新资源_ephemeral-storage_，用于管理本地临时存储。 -在每个Kubernetes节点中，kubelet的根目录（默认为 /var/lib/kubelet）和日志目录（ /var/log ）存储在节点的根分区上。 -Pods还通过emptyDir卷，容器日志，镜像层和容器可写层共享和使用此分区。 - -该分区是“临时”分区，应用程序无法从该分区获得任何性能SLA（例如磁盘IOPS）。 本地临时存储管理仅适用于根分区。 图像层和可写层的可选分区超出范围。 - -{{< note >}} -如果使用可选的运行时分区，则根分区将不保存任何镜像层或可写层。 -{{< /note >}} - -<!-- -### Requests and limits setting for local ephemeral storage -Each Container of a Pod can specify one or more of the following: ---> - -### 本地临时存储的请求和限制设置 -Pod 的每个容器可以指定以下一项或多项： - -* `spec.containers[].resources.limits.ephemeral-storage` -* `spec.containers[].resources.requests.ephemeral-storage` - -<!-- -Limits and requests for `ephemeral-storage` are measured in bytes. You can express storage as -a plain integer or as a fixed-point integer using one of these suffixes: -E, P, T, G, M, K. You can also use the power-of-two equivalents: Ei, Pi, Ti, Gi, -Mi, Ki. For example, the following represent roughly the same value: ---> - -对“临时存储”的限制和请求以字节为单位。您可以使用以下后缀之一将存储表示为纯整数或小数形式：E，P，T，G，M，K。您还可以使用2的幂次方：Ei，Pi，Ti，Gi，Mi，Ki。例如，以下内容表示的值其实大致相同： - -```shell -128974848, 129e6, 129M, 123Mi -``` - -<!-- -For example, the following Pod has two Containers. Each Container has a request of 2GiB of local ephemeral storage. Each Container has a limit of 4GiB of local ephemeral storage. Therefore, the Pod has a request of 4GiB of local ephemeral storage, and a limit of 8GiB of storage. ---> - -例如，以下Pod具有两个容器。每个容器都有一个2GiB的本地临时存储请求。每个容器的本地临时存储限制为4GiB。因此，该Pod要求本地临时存储空间为4GiB，存储空间限制为8GiB。 - -```yaml -apiVersion: v1 -kind: Pod -metadata: - name: frontend -spec: - containers: - - name: db - image: mysql - env: - - name: MYSQL_ROOT_PASSWORD - value: "password" - resources: - requests: - ephemeral-storage: "2Gi" - limits: - ephemeral-storage: "4Gi" - - name: wp - image: wordpress - resources: - requests: - ephemeral-storage: "2Gi" - limits: - ephemeral-storage: "4Gi" -``` - -<!-- -### How Pods with ephemeral-storage requests are scheduled - -When you create a Pod, the Kubernetes scheduler selects a node for the Pod to -run on. Each node has a maximum amount of local ephemeral storage it can provide for Pods. For more information, see ["Node Allocatable"](/docs/tasks/administer-cluster/reserve-compute-resources/#node-allocatable). - -The scheduler ensures that the sum of the resource requests of the scheduled Containers is less than the capacity of the node. ---> - -### 如何调度临时存储请求的 Pod - -创建Pod时，Kubernetes调度程序会选择一个节点来运行Pod。每个节点都可以为Pod提供最大数量的本地临时存储。 -有关更多信息，请参见[节点可分配](/docs/tasks/administer-cluster/reserve-compute-resources/#node-allocatable)。 - -调度程序会确保调度的容器的资源请求的总和小于节点的容量。 - -<!-- -### How Pods with ephemeral-storage limits run - -For container-level isolation, if a Container's writable layer and logs usage exceeds its storage limit, the Pod will be evicted. For pod-level isolation, if the sum of the local ephemeral storage usage from all containers and also the Pod's emptyDir volumes exceeds the limit, the Pod will be evicted. ---> - -### 具有临时存储限制的 Pod 如何运行 - -对于容器级隔离，如果容器的可写层和日志使用量超出其存储限制，则将驱逐Pod。对于 pod 级别的隔离，如果来自所有容器的本地临时存储使用量以及 Pod 的 emptyDir 卷的总和超过限制，则将驱逐Pod。 - -<!-- -### Monitoring ephemeral-storage consumption - -When local ephemeral storage is used, it is monitored on an ongoing -basis by the kubelet. The monitoring is performed by scanning each -emptyDir volume, log directories, and writable layers on a periodic -basis. Starting with Kubernetes 1.15, emptyDir volumes (but not log -directories or writable layers) may, at the cluster operator's option, -be managed by use of [project -quotas](http://xfs.org/docs/xfsdocs-xml-dev/XFS_User_Guide/tmp/en-US/html/xfs-quotas.html). -Project quotas were originally implemented in XFS, and have more -recently been ported to ext4fs. Project quotas can be used for both -monitoring and enforcement; as of Kubernetes 1.15, they are available -as alpha functionality for monitoring only. ---> - -### 监控临时存储消耗 - -使用本地临时存储时，kubelet 会持续对本地临时存储时进行监视。 -通过定期扫描，来监视每个 emptyDir 卷，日志目录和可写层。 -从Kubernetes 1.15开始，作为集群操作员的一个选项，可以通过[项目配额](http://xfs.org/docs/xfsdocs-xml-dev/XFS_User_Guide/tmp/en-US/html/xfs-quotas.html) 来管理 emptyDir 卷（但是不包括日志目录或可写层）。 -项目配额最初是在XFS中实现的，最近又被移植到ext4fs中。 项目配额可用于监视和执行； 从Kubernetes 1.15开始，它们可用作Alpha功能仅用于监视。 - -<!-- -Quotas are faster and more accurate than directory scanning. When a -directory is assigned to a project, all files created under a -directory are created in that project, and the kernel merely has to -keep track of how many blocks are in use by files in that project. If -a file is created and deleted, but with an open file descriptor, it -continues to consume space. This space will be tracked by the quota, -but will not be seen by a directory scan. ---> - -配额比目录扫描更快，更准确。 -将目录分配给项目时，在该目录下创建的所有文件都将在该项目中创建，内核仅需跟踪该项目中的文件正在使用多少块。 -如果创建并删除了文件，但是文件描述符已打开，它将继续占用空间。 该空间将由配额跟踪，但目录扫描不会检查。 - -<!-- -Kubernetes uses project IDs starting from 1048576. The IDs in use are -registered in `/etc/projects` and `/etc/projid`. If project IDs in -this range are used for other purposes on the system, those project -IDs must be registered in `/etc/projects` and `/etc/projid` to prevent -Kubernetes from using them. ---> - -Kubernetes使用从1048576开始的项目ID。正在使用的ID注册于 `/etc/projects` 和 `/etc/projid`。 -如果此范围内的项目ID用于系统上的其他目的，则这些项目ID必须在 `/etc/projects` 和 `/etc/projid` 中注册，以防止Kubernetes使用它们。 - -<!-- -To enable use of project quotas, the cluster operator must do the -following: - -* Enable the `LocalStorageCapacityIsolationFSQuotaMonitoring=true` - feature gate in the kubelet configuration. This defaults to `false` - in Kubernetes 1.15, so must be explicitly set to `true`. - -* Ensure that the root partition (or optional runtime partition) is - built with project quotas enabled. All XFS filesystems support - project quotas, but ext4 filesystems must be built specially. - -* Ensure that the root partition (or optional runtime partition) is - mounted with project quotas enabled. ---> - -要启用项目配额，集群操作员必须执行以下操作： - -* 在kubelet配置中启用 `LocalStorageCapacityIsolationFSQuotaMonitoring = true` 功能。 在Kubernetes 1.15中默认为 false，因此必须显式设置为 true。 - -* 确保根分区（或可选的运行时分区）是在启用项目配额的情况下构建的。 所有 XFS 文件系统都支持项目配额，但是 ext4 文件系统必须专门构建。 - -* 确保在启用了项目配额的情况下挂载了根分区（或可选的运行时分区）。 - -<!-- -#### Building and mounting filesystems with project quotas enabled - -XFS filesystems require no special action when building; they are -automatically built with project quotas enabled. - -Ext4fs filesystems must be built with quotas enabled, then they must -be enabled in the filesystem: ---> - -#### 在启用项目配额的情况下构建和挂载文件系统 - -XFS文件系统在构建时不需要任何特殊操作; 它们是在启用项目配额的情况下自动构建的。 - -Ext4fs文件系统必须在启用了配额的情况下构建，然后必须在文件系统中启用它们： - -``` -% sudo mkfs.ext4 other_ext4fs_args... -E quotatype=prjquota /dev/block_device -% sudo tune2fs -O project -Q prjquota /dev/block_device - -``` - -<!-- -To mount the filesystem, both ext4fs and XFS require the `prjquota` -option set in `/etc/fstab`: ---> - -要挂载文件系统，ext4fs 和 XFS 都需要在 `/etc/fstab` 中设置 `prjquota` 选项： - -``` -/dev/block_device /var/kubernetes_data defaults,prjquota 0 0 -``` - - -<!-- -## Extended resources - -Extended resources are fully-qualified resource names outside the -`kubernetes.io` domain. They allow cluster operators to advertise and users to -consume the non-Kubernetes-built-in resources. - -There are two steps required to use Extended Resources. First, the cluster -operator must advertise an Extended Resource. Second, users must request the -Extended Resource in Pods. ---> - -## 拓展资源 - -拓展资源是 `kubernetes.io` 域名之外的标准资源名称。它们允许集群管理员做分发，而且用户可以使用非Kubernetes内置资源。 -使用扩展资源需要两个步骤。 首先，集群管理员必须分发拓展资源。 其次，用户必须在 Pod 中请求拓展资源。 - -```shell -curl --header "Content-Type: application/json-patch+json" \ ---request PATCH \ ---data '[{"op": "add", "path": "/status/capacity/example.com~1foo", "value": "5"}]' \ -http://k8s-master:8080/api/v1/nodes/k8s-node-1/status -``` - -<!-- -### Managing extended resources - -#### Node-level extended resources - -Node-level extended resources are tied to nodes. ---> - -### 管理拓展资源 - -#### 节点级拓展资源 - -节点级拓展资源绑定到节点。 - -<!-- -##### Device plugin managed resources -See [Device -Plugin](/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins/) -for how to advertise device plugin managed resources on each node. ---> - -##### 设备插件托管资源 - -有关如何在每个节点上分发设备插件托管资源的信息，请参阅[设备插件](/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins/)。 - -<!-- -##### Other resources -To advertise a new node-level extended resource, the cluster operator can -submit a `PATCH` HTTP request to the API server to specify the available -quantity in the `status.capacity` for a node in the cluster. After this -operation, the node's `status.capacity` will include a new resource. The -`status.allocatable` field is updated automatically with the new resource -asynchronously by the kubelet. Note that because the scheduler uses the node -`status.allocatable` value when evaluating Pod fitness, there may be a short -delay between patching the node capacity with a new resource and the first Pod -that requests the resource to be scheduled on that node. ---> - -##### 其他资源 -为了发布新的节点级拓展资源，集群操作员可以向API服务器提交 `PATCH` HTTP 请求， -以在 `status.capacity` 中为集群中的节点指定可用数量。 -完成此操作后，节点的 `status.capacity` 将包含新资源。 -由kubelet异步使用新资源自动更新 `status.allocatable` 字段。 -请注意，由于调度程序在评估Pod适合性时使用节点的状态 `status.allocatable` 值， -因此在用新资源修补节点容量和请求在该节点上调度资源的第一个Pod之间可能会有短暂的延迟。 - -<!-- -**Example:** - -Here is an example showing how to use `curl` to form an HTTP request that -advertises five "example.com/foo" resources on node `k8s-node-1` whose master -is `k8s-master`. ---> - -**示例:** - -这是一个示例，显示了如何使用 `curl` 进行HTTP请求，该请求在主节点为 `k8s-master` 的子节点 `k8s-node-1` -上通告五个 `example.com/foo` 资源。 - -```shell -curl --header "Content-Type: application/json-patch+json" \ ---request PATCH \ ---data '[{"op": "add", "path": "/status/capacity/example.com~1foo", "value": "5"}]' \ -http://k8s-master:8080/api/v1/nodes/k8s-node-1/status -``` - -{{< note >}} - -<!-- -In the preceding request, `~1` is the encoding for the character `/` -in the patch path. The operation path value in JSON-Patch is interpreted as a -JSON-Pointer. For more details, see ---> - -在前面的请求中，`~1` 是 Patch 路径中字符 `/` 的编码。 JSON-Patch中的操作路径值被解释为JSON-Pointer。 -有关更多详细信息，请参见 -[IETF RFC 6901, section 3](https://tools.ietf.org/html/rfc6901#section-3). -{{< /note >}} - -<!-- -#### Cluster-level extended resources - -Cluster-level extended resources are not tied to nodes. They are usually managed -by scheduler extenders, which handle the resource consumption and resource quota. - -You can specify the extended resources that are handled by scheduler extenders -in [scheduler policy -configuration](https://github.com/kubernetes/kubernetes/blob/release-1.10/pkg/scheduler/api/v1/types.go#L31). ---> - -#### 集群级扩展资源 - -群集级扩展资源不绑定到节点。 它们通常由调度程序扩展程序管理，这些程序处理资源消耗和资源配额。 - -您可以在[调度程序策略配置](https://github.com/kubernetes/kubernetes/blob/release-1.10/pkg/scheduler/api/v1/types.go#L31)中指定由调度程序扩展程序处理的扩展资源。 - -<!-- -**Example:** - -The following configuration for a scheduler policy indicates that the -cluster-level extended resource "example.com/foo" is handled by the scheduler -extender. - -- The scheduler sends a Pod to the scheduler extender only if the Pod requests - "example.com/foo". -- The `ignoredByScheduler` field specifies that the scheduler does not check - the "example.com/foo" resource in its `PodFitsResources` predicate. ---> - -**示例:** - -通过调度程序策略的以下配置，指示群集级扩展资源 "example.com/foo" 由调度程序扩展程序处理。 - -- 仅当Pod请求 "example.com/foo" 时，调度程序才会将 Pod 发送到调度程序扩展程序。 -- `ignoredByScheduler` 字段指定调度程序不在其 `PodFitsResources` 字段中检查 "example.com/foo" 资源。 - -```json -{ - "kind": "Policy", - "apiVersion": "v1", - "extenders": [ - { - "urlPrefix":"<extender-endpoint>", - "bindVerb": "bind", - "managedResources": [ - { - "name": "example.com/foo", - "ignoredByScheduler": true - } - ] - } - ] -} -``` - -<!-- -### Consuming extended resources - -Users can consume extended resources in Pod specs just like CPU and memory. -The scheduler takes care of the resource accounting so that no more than the -available amount is simultaneously allocated to Pods. - -The API server restricts quantities of extended resources to whole numbers. -Examples of _valid_ quantities are `3`, `3000m` and `3Ki`. Examples of -_invalid_ quantities are `0.5` and `1500m`. ---> - -### 消耗扩展资源 - -就像 CPU 和内存一样，用户可以使用 Pod 的扩展资源。 -调度程序负责核算资源，因此不会同时将过多的可用资源分配给 Pod。 - -{{< note >}} - -<!-- -Extended resources replace Opaque Integer Resources. -Users can use any domain name prefix other than `kubernetes.io` which is reserved. ---> - -扩展资源取代了 Opaque 整数资源。 用户可以使用保留字 `kubernetes.io` 以外的任何域名前缀。 - -{{< /note >}} - -<!-- -To consume an extended resource in a Pod, include the resource name as a key -in the `spec.containers[].resources.limits` map in the container spec. ---> - -要在Pod中使用扩展资源，请在容器规范的 `spec.containers[].resources.limits` 映射中包含资源名称作为键。 - -{{< note >}} - -<!-- -Extended resources cannot be overcommitted, so request and limit -must be equal if both are present in a container spec. ---> - -扩展资源不能过量使用，因此如果容器规范中存在请求和限制，则它们必须一致。 - -{{< /note >}} - -<!-- -A Pod is scheduled only if all of the resource requests are satisfied, including -CPU, memory and any extended resources. The Pod remains in the `PENDING` state -as long as the resource request cannot be satisfied. - -**Example:** - -The Pod below requests 2 CPUs and 1 "example.com/foo" (an extended resource). ---> - -仅当满足所有资源请求(包括 CPU ，内存和任何扩展资源)时，才能调度 Pod。 只要资源请求无法满足，则 Pod 保持在 `PENDING` 状态。 - -**示例:** - -下面的 Pod 请求2个 CPU 和1个"example.com/foo"(扩展资源)。 - -```yaml -apiVersion: v1 -kind: Pod -metadata: - name: my-pod -spec: - containers: - - name: my-container - image: myimage - resources: - requests: - cpu: 2 - example.com/foo: 1 - limits: - example.com/foo: 1 -``` - - - - -## {{% heading "whatsnext" %}} - - -<!-- -* Get hands-on experience [assigning Memory resources to Containers and Pods](/docs/tasks/configure-pod-container/assign-memory-resource/). - -* Get hands-on experience [assigning CPU resources to Containers and Pods](/docs/tasks/configure-pod-container/assign-cpu-resource/). - -* [Container API](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#container-v1-core) - -* [ResourceRequirements](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#resourcerequirements-v1-core) ---> - -* 获取将 [分配内存资源给容器和 Pod ](/docs/tasks/configure-pod-container/assign-memory-resource/) 的实践经验 - -* 获取将 [分配 CPU 资源给容器和 Pod ](/docs/tasks/configure-pod-container/assign-cpu-resource/) 的实践经验 - -* [容器](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#container-v1-core) - -* [资源需求](/docs/resources-reference/{{< param "version" >}}/#resourcerequirements-v1-core) - - diff --git a/content/zh/docs/concepts/configuration/manage-resources-containers.md b/content/zh/docs/concepts/configuration/manage-resources-containers.md new file mode 100644 index 0000000000..ef14f7608d --- /dev/null +++ b/content/zh/docs/concepts/configuration/manage-resources-containers.md @@ -0,0 +1,1305 @@ +--- +title: 为容器管理资源 +content_type: concept +weight: 40 +feature: + title: 自动装箱 + description: > + 根据资源需求和其他约束自动放置容器，同时避免影响可用性。将关键性工作负载和尽力而为性质的服务工作负载进行混合放置，以提高资源利用率并节省更多资源。 +--- + +<!-- +title: Managing Resources for Containers +content_type: concept +weight: 40 +feature: + title: Automatic binpacking + description: > + Automatically places containers based on their resource requirements and other constraints, while not sacrificing availability. Mix critical and best-effort workloads in order to drive up utilization and save even more resources. +--> + +<!-- overview --> + +<!-- +When you specify a {{< glossary_tooltip term_id="pod" >}}, you can optionally specify how +much of each resource a {{< glossary_tooltip text="Container" term_id="container" >}} needs. +The most common resources to specify are CPU and memory (RAM); there are others. + +When you specify the resource _request_ for Containers in a Pod, the scheduler uses this +information to decide which node to place the Pod on. When you specify a resource _limit_ +for a Container, the kubelet enforces those limits so that the running container is not +allowed to use more of that resource than the limit you set. The kubelet also reserves +at least the _request_ amount of that system resource specifically for that container +to use. +--> + +当你定义 {{< glossary_tooltip text="Pod" term_id="pod" >}} 时可以选择性地为每个 +{{< glossary_tooltip text="容器" term_id="container" >}}设定所需要的资源数量。 +最常见的可设定资源是 CPU 和内存（RAM）大小；此外还有其他类型的资源。 + +当你为 Pod 中的 Container 指定了资源 __请求__ 时，调度器就利用该信息决定将 Pod 调度到哪个节点上。 +当你还为 Container 指定了资源 __约束__ 时，kubelet 就可以确保运行的容器不会使用超出所设约束的资源。 +kubelet 还会为容器预留所 __请求__ 数量的系统资源，供其使用。 + +<!-- body --> + +<!-- +## Requests and limits + +If the node where a Pod is running has enough of a resource available, it's possible (and +allowed) for a container to use more resource than its `request` for that resource specifies. +However, a container is not allowed to use more than its resource `limit`. + +For example, if you set a `memory` request of 256 MiB for a container, and that container is in +a Pod scheduled to a Node with 8GiB of memory and no other Pods, then the container can try to use +more RAM. +--> + +## 请求和约束 {#requests-and-limits} + +如果 Pod 运行所在的节点具有足够的可用资源，容器可能（且可以）使用超出对应资源 +`request` 属性所设置的资源量。不过，容器不可以使用超出其资源 `limit` +属性所设置的资源量。 + +例如，如果你将容器的 `memory` 的请求量设置为 256 MiB，而该容器所处的 Pod +被调度到一个具有 8 GiB 内存的节点上，并且该节点上没有其他 Pods +运行，那么该容器就可以尝试使用更多的内存。 + +<!-- +If you set a `memory` limit of 4GiB for that Container, the kubelet (and +{{< glossary_tooltip text="container runtime" term_id="container-runtime" >}}) enforce the limit. +The runtime prevents the container from using more than the configured resource limit. For example: +when a process in the container tries to consume more than the allowed amount of memory, +the system kernel terminates the process that attempted the allocation, with an out of memory +(OOM) error. + +Limits can be implemented either reactively (the system intervenes once it sees a violation) +or by enforcement (the system prevents the container from ever exceeding the limit). Different +runtimes can have different ways to implement the same restrictions. +--> + +如果你将某容器的 `memory` 约束设置为 4 GiB，kubelet （和 +{{< glossary_tooltip text="容器运行时" term_id="container-runtime" >}}） +就会确保该约束生效。 +容器运行时会禁止容器使用超出所设置资源约束的资源。 +例如：当容器中进程尝试使用超出所允许内存量的资源时，系统内核会将尝试申请内存的进程终止， +并引发内存不足（OOM）错误。 + +约束值可以以被动方式来实现（系统会在发现违例时进行干预），或者通过强制生效的方式实现 +（系统会避免容器用量超出约束值）。不同的容器运行时采用不同方式来实现相同的限制。 + +<!-- +## Resource types + +*CPU* and *memory* are each a *resource type*. A resource type has a base unit. +CPU represents compute processing and is specified in units of [Kubernetes CPUs](#meaning-of-cpu). +Memory is specified in units of bytes. +If you're using Kubernetes v1.14 or newer, you can specify _huge page_ resources. +Huge pages are a Linux-specific feature where the node kernel allocates blocks of memory +that are much larger than the default page size. + +For example, on a system where the default page size is 4KiB, you could specify a limit, +`hugepages-2Mi: 80Mi`. If the container tries allocating over 40 2MiB huge pages (a +total of 80 MiB), that allocation fails. +--> +## 资源类型 {#resource-types} + +*CPU* 和*内存*都是*资源类型*。每种资源类型具有其基本单位。 +CPU 表达的是计算处理能力，其单位是 [Kubernetes CPUs](#meaning-of-cpu)。 +内存的单位是字节。 +如果你使用的是 Kubernetes v1.14 或更高版本，则可以指定巨页（Huge Page）资源。 +巨页是 Linux 特有的功能，节点内核在其中分配的内存块比默认页大小大得多。 + +例如，在默认页面大小为 4KiB 的系统上，您可以指定约束 `hugepages-2Mi: 80Mi`。 +如果容器尝试分配 40 个 2MiB 大小的巨页（总共 80 MiB ），则分配请求会失败。 + +<!-- +{{< note >}} +You cannot overcommit `hugepages-*` resources. +This is different from the `memory` and `cpu` resources. +{{< /note >}} + +CPU and memory are collectively referred to as *compute resources*, or just +*resources*. Compute +resources are measurable quantities that can be requested, allocated, and +consumed. They are distinct from +[API resources](/docs/concepts/overview/kubernetes-api/). API resources, such as Pods and +[Services](/docs/concepts/services-networking/service/) are objects that can be read and modified +through the Kubernetes API server. +--> + + +{{< note >}} +您不能过量使用 `hugepages- * `资源。 +这与 `memory` 和 `cpu` 资源不同。 +{{< /note >}} + +CPU 和内存统称为*计算资源*，或简称为*资源*。 +计算资源的数量是可测量的，可以被请求、被分配、被消耗。 +它们与 [API 资源](/zh/docs/concepts/overview/kubernetes-api/) 不同。 +API 资源（如 Pod 和 [Service](/zh/docs/concepts/services-networking/service/)）是可通过 +Kubernetes API 服务器读取和修改的对象。 + +<!-- +## Resource requests and limits of Pod and Container + +Each Container of a Pod can specify one or more of the following: + +* `spec.containers[].resources.limits.cpu` +* `spec.containers[].resources.limits.memory` +* `spec.containers[].resources.limits.hugepages-<size>` +* `spec.containers[].resources.requests.cpu` +* `spec.containers[].resources.requests.memory` +* `spec.containers[].resources.requests.hugepages-<size>` + +Although requests and limits can only be specified on individual Containers, it +is convenient to talk about Pod resource requests and limits. A +*Pod resource request/limit* for a particular resource type is the sum of the +resource requests/limits of that type for each Container in the Pod. +--> + +## Pod 和 容器的资源请求和约束 + +Pod 中的每个容器都可以指定以下的一个或者多个值： + +- `spec.containers[].resources.limits.cpu` +- `spec.containers[].resources.limits.memory` +- `spec.containers[].resources.limits.hugepages-<size>` +- `spec.containers[].resources.requests.cpu` +- `spec.containers[].resources.requests.memory` +- `spec.containers[].resources.requests.hugepages-<size>` + +尽管请求和限制值只能在单个容器上指定，我们仍可方便地计算出 Pod 的资源请求和约束。 +Pod 对特定资源类型的请求/约束值是 Pod 中各容器对该类型资源的请求/约束值的总和。 + +<!-- +## Resource units in Kubernetes + +### Meaning of CPU + +Limits and requests for CPU resources are measured in *cpu* units. +One cpu, in Kubernetes, is equivalent to **1 vCPU/Core** for cloud providers and **1 hyperthread** on bare-metal Intel processors. + +Fractional requests are allowed. A Container with +`spec.containers[].resources.requests.cpu` of `0.5` is guaranteed half as much +CPU as one that asks for 1 CPU. The expression `0.1` is equivalent to the +expression `100m`, which can be read as "one hundred millicpu". Some people say +"one hundred millicores", and this is understood to mean the same thing. A +request with a decimal point, like `0.1`, is converted to `100m` by the API, and +precision finer than `1m` is not allowed. For this reason, the form `100m` might +be preferred. +CPU is always requested as an absolute quantity, never as a relative quantity; +0.1 is the same amount of CPU on a single-core, dual-core, or 48-core machine. +--> + +## CPU 的含义 {#meaning-of-cpu} + +CPU 资源的约束和请求以 *cpu* 为单位。 + +Kubernetes 中的一个 cpu 等于云平台上的 **1 个 vCPU/核**和裸机 Intel +处理器上的 **1 个超线程 **。 + +你也可以表达带小数 CPU 的请求。`spec.containers[].resources.requests.cpu` 为 0.5 +的 Container 肯定能够获得请求 1 CPU 的容器的一半 CPU 资源。表达式 `0.1` 等价于表达式 `100m`， +可以看作 “100 millicpu”。有些人说成是“一百毫 cpu”，其实说的是同样的事情。 +具有小数点（如 `0.1`）的请求由 API 转换为 `100m`；最大精度是 `1m`。 +因此，或许你应该优先考虑使用 `100m` 的形式。 + +CPU 总是按绝对数量来请求的，不可以使用相对数量； +0.1 的 CPU 在单核、双核、48 核的机器上的意义是一样的。 + +<!-- +## Meaning of memory + +Limits and requests for `memory` are measured in bytes. You can express memory as +a plain integer or as a fixed-point integer using one of these suffixes: +E, P, T, G, M, K. You can also use the power-of-two equivalents: Ei, Pi, Ti, Gi, +Mi, Ki. For example, the following represent roughly the same value: +--> +## 内存的含义 {#meaning-of-memory} + +内存的约束和请求以字节为单位。你可以使用以下后缀之一以一般整数或定点整数形式来表示内存： +E、P、T、G、M、K。你也可以使用对应的 2 的幂数：Ei、Pi、Ti、Gi、Mi、Ki。 +例如，以下表达式所代表的是大致相同的值： + +```shell +128974848、129e6、129M、123Mi +``` + +<!-- +Here's an example. +The following Pod has two Containers. Each Container has a request of 0.25 cpu +and 64MiB (2<sup>26</sup> bytes) of memory. Each Container has a limit of 0.5 +cpu and 128MiB of memory. You can say the Pod has a request of 0.5 cpu and 128 +MiB of memory, and a limit of 1 cpu and 256MiB of memory. +--> + +下面是个例子。 + +以下 Pod 有两个 Container。每个 Container 的请求为 0.25 cpu 和 64MiB（2<sup>26</sup> 字节）内存， +每个容器的资源约束为 0.5 cpu 和 128MiB 内存。 +你可以认为该 Pod 的资源请求为 0.5 cpu 和 128 MiB 内存，资源限制为 1 cpu 和 256MiB 内存。 + +```yaml +apiVersion: v1 +kind: Pod +metadata: + name: frontend +spec: + containers: + - name: app + image: images.my-company.example/app:v4 + env: + - name: MYSQL_ROOT_PASSWORD + value: "password" + resources: + requests: + memory: "64Mi" + cpu: "250m" + limits: + memory: "128Mi" + cpu: "500m" + - name: log-aggregator + image: images.my-company.example/log-aggregator:v6 + resources: + requests: + memory: "64Mi" + cpu: "250m" + limits: + memory: "128Mi" + cpu: "500m" +``` + +<!-- +## How Pods with resource requests are scheduled +When you create a Pod, the Kubernetes scheduler selects a node for the Pod to +run on. Each node has a maximum capacity for each of the resource types: the +amount of CPU and memory it can provide for Pods. The scheduler ensures that, +for each resource type, the sum of the resource requests of the scheduled +Containers is less than the capacity of the node. Note that although actual memory +or CPU resource usage on nodes is very low, the scheduler still refuses to place +a Pod on a node if the capacity check fails. This protects against a resource +shortage on a node when resource usage later increases, for example, during a +daily peak in request rate. +--> + +## 带资源请求的 Pod 如何调度 + +当你创建一个 Pod 时，Kubernetes 调度程序将为 Pod 选择一个节点。 +每个节点对每种资源类型都有一个容量上限：可为 Pod 提供的 CPU 和内存量。 +调度程序确保对于每种资源类型，所调度的容器的资源请求的总和小于节点的容量。 +请注意，尽管节点上的实际内存或 CPU 资源使用量非常低，如果容量检查失败， +调度程序仍会拒绝在该节点上放置 Pod。 +当稍后节点上资源用量增加，例如到达请求率的每日峰值区间时，节点上也不会出现资源不足的问题。 + +<!-- +## How Pods with resource limits are run + +When the kubelet starts a Container of a Pod, it passes the CPU and memory limits +to the container runtime. + +When using Docker: +--> + +## 带资源约束的 Pod 如何运行 + +当 kubelet 启动 Pod 中的 Container 时，它会将 CPU 和内存约束信息传递给容器运行时。 + +当使用 Docker 时： + +<!-- +- The `spec.containers[].resources.requests.cpu` is converted to its core value, + which is potentially fractional, and multiplied by 1024. The greater of this number + or 2 is used as the value of the + [`--cpu-shares`](https://docs.docker.com/engine/reference/run/#cpu-share-constraint) + flag in the `docker run` command. + +- The `spec.containers[].resources.limits.cpu` is converted to its millicore value and + multiplied by 100. The resulting value is the total amount of CPU time that a container can use + every 100ms. A container cannot use more than its share of CPU time during this interval. + + {{< note >}} + The default quota period is 100ms. The minimum resolution of CPU quota is 1ms. + {{</ note >}} + +- The `spec.containers[].resources.limits.memory` is converted to an integer, and + used as the value of the + [`--memory`](https://docs.docker.com/engine/reference/run/#/user-memory-constraints) + flag in the `docker run` command. +--> + +- `spec.containers[].resources.requests.cpu` 先被转换为可能是小数的基础值，再乘以 1024。 + 这个数值和 2 的较大者用作 `docker run` 命令中的 + [`--cpu-shares`](https://docs.docker.com/engine/reference/run/#/cpu-share-constraint) + 标志的值。 +- `spec.containers[].resources.limits.cpu` 先被转换为 millicore 值，再乘以 100。 + 其结果就是每 100 毫秒内容器可以使用的 CPU 时间总量。在此期间（100ms），容器所使用的 CPU + 时间不会超过它被分配的时间。 + + {{< note >}} + 默认的配额（quota）周期为 100 毫秒。 CPU配额的最小精度为 1 毫秒。 + {{</ note >}} + +- `spec.containers[].resources.limits.memory` 被转换为整数值，作为 `docker run` 命令中的 + [`--memory`](https://docs.docker.com/engine/reference/run/#/user-memory-constraints) + 参数值。 + +<!-- +If a Container exceeds its memory limit, it might be terminated. If it is +restartable, the kubelet will restart it, as with any other type of runtime +failure. + +If a Container exceeds its memory request, it is likely that its Pod will +be evicted whenever the node runs out of memory. + +A Container might or might not be allowed to exceed its CPU limit for extended +periods of time. However, it will not be killed for excessive CPU usage. + +To determine whether a Container cannot be scheduled or is being killed due to +resource limits, see the +[Troubleshooting](#troubleshooting) section. +--> + +如果 Container 超过其内存限制，则可能会被终止。如果容器可重新启动，则与所有其他类型的 +运行时失效一样，kubelet 将重新启动容器。 + +如果一个 Container 内存用量超过其内存请求值，那么当节点内存不足时，容器所处的 Pod 可能被逐出。 + +每个 Container 可能被允许也可能不被允许使用超过其 CPU 约束的处理时间。 +但是，容器不会由于 CPU 使用率过高而被杀死。 + +要确定 Container 是否会由于资源约束而无法调度或被杀死，请参阅[疑难解答](#troubleshooting) 部分。 + +<!-- +## Monitoring compute & memory resource usage + +The resource usage of a Pod is reported as part of the Pod status. + +If optional [tools for monitoring](/docs/tasks/debug-application-cluster/resource-usage-monitoring/) +are available in your cluster, then Pod resource usage can be retrieved either +from the [Metrics API](/docs/tasks/debug-application-cluster/resource-metrics-pipeline/#the-metrics-api) +directly or from your monitoring tools. +--> + +## 监控计算和内存资源用量 + +Pod 的资源使用情况是作为 Pod 状态的一部分来报告的。 + +如果为集群配置了可选的 +[监控工具](/zh/docs/tasks/debug-application-cluster/resource-usage-monitoring/)， +则可以直接从 +[指标 API](/zh/docs/tasks/debug-application-cluster/resource-metrics-pipeline/#the-metrics-api) +或者监控工具获得 Pod 的资源使用情况。 + +<!-- +## Local ephemeral storage + +Nodes have local ephemeral storage, backed by +locally-attached writeable devices or, sometimes, by RAM. +"Ephemeral" means that there is no long-term guarantee about durability. + +Pods use ephemeral local storage for scratch space, caching, and for logs. +The kubelet can provide scratch space to Pods using local ephemeral storage to +mount [`emptyDir`](https://kubernetes.io/docs/concepts/storage/volumes/#emptydir) + {{< glossary_tooltip term_id="volume" text="volumes" >}} into containers. +--> +## 本地临时存储 {#local-ephemeral-storage} + +<!-- feature gate LocalStorageCapacityIsolation --> +{{< feature-state for_k8s_version="v1.10" state="beta" >}} + +节点通常还可以具有本地的临时性存储，由本地挂接的可写入设备或者有时也用 RAM +来提供支持。 +“临时（Ephemeral）”意味着对所存储的数据不提供长期可用性的保证。 + +Pods 通常可以使用临时性本地存储来实现缓冲区、保存日志等功能。 +kubelet 可以为使用本地临时存储的 Pods 提供这种存储空间，允许后者使用 +[`emptyDir`](/zh/docs/concepts/storage/volumes/#emptydir) 类型的 +{{< glossary_tooltip term_id="volume" text="卷" >}}将其挂载到容器中。 + +<!-- +The kubelet also uses this kind of storage to hold +[node-level container logs](/docs/concepts/cluster-administration/logging/#logging-at-the-node-level), +container images, and the writable layers of running containers. + +{{< caution >}} +If a node fails, the data in its ephemeral storage can be lost. +Your applications cannot expect any performance SLAs (disk IOPS for example) +from local ephemeral storage. +{{< /caution >}} + +As a beta feature, Kubernetes lets you track, reserve and limit the amount +of ephemeral local storage a Pod can consume. +--> + +kubelet 也使用此类存储来保存 +[节点层面的容器日志](/zh/docs/concepts/cluster-administration/logging/#logging-at-the-node-level)， +容器镜像文件、以及运行中容器的可写入层。 + +{{< caution >}} +如果节点失效，存储在临时性存储中的数据会丢失。 +你的应用不能对本地临时性存储的性能 SLA（例如磁盘 IOPS）作任何假定。 +{{< /caution >}} + +作为一种 beta 阶段功能特性，Kubernetes 允许你跟踪、预留和限制 Pod +可消耗的临时性本地存储数量。 + +<!-- +### Configurations for local ephemeral storage + +Kubernetes supports two ways to configure local ephemeral storage on a node: + +In this configuration, you place all different kinds of ephemeral local data +(`emptyDir` volumes, writeable layers, container images, logs) into one filesystem. +The most effective way to configure the kubelet means dedicating this filesystem +to Kubernetes (kubelet) data. + +The kubelet also writes +[node-level container logs](/docs/concepts/cluster-administration/logging/#logging-at-the-node-level) +and treats these similarly to ephemeral local storage. +--> + +### 本地临时性存储的配置 + +Kubernetes 有两种方式支持节点上配置本地临时性存储： + +{{< tabs name="local_storage_configurations" >}} +{{% tab name="单一文件系统" %}} +采用这种配置时，你会把所有类型的临时性本地数据（包括 `emptyDir` +卷、可写入容器层、容器镜像、日志等）放到同一个文件系统中。 +作为最有效的 kubelet 配置方式，这意味着该文件系统是专门提供给 Kubernetes +（kubelet）来保存数据的。 + +kubelet 也会生成 +[节点层面的容器日志](/zh/docs/concepts/cluster-administration/logging/#logging-at-the-node-level)， +并按临时性本地存储的方式对待之。 + +<!-- +The kubelet writes logs to files inside its configured log directory (`/var/log` +by default); and has a base directory for other locally stored data +(`/var/lib/kubelet` by default). + +Typically, both `/var/lib/kubelet` and `/var/log` are on the system root filesystem, +and the kubelet is designed with that layout in mind. + +Your node can have as many other filesystems, not used for Kubernetes, +as you like. +--> + +kubelet 会将日志写入到所配置的日志目录（默认为 `/var/log`）下的文件中； +还会针对其他本地存储的数据使用同一个基础目录（默认为 `/var/lib/kubelet`）。 + +通常，`/var/lib/kubelet` 和 `/var/log` 都是在系统的根文件系统中。kubelet +的设计也考虑到这一点。 + +你的集群节点当然可以包含其他的、并非用于 Kubernetes 的很多文件系统。 +{{% /tab %}} + +<!-- +You have a filesystem on the node that you're using for ephemeral data that +comes from running Pods: logs, and `emptyDir` volumes. You can use this filesystem +for other data (for example: system logs not related to Kubernetes); it can even +be the root filesystem. + +The kubelet also writes +[node-level container logs](/docs/concepts/cluster-administration/logging/#logging-at-the-node-level) +into the first filesystem, and treats these similarly to ephemeral local storage. + +You also use a separate filesystem, backed by a different logical storage device. +In this configuration, the directory where you tell the kubelet to place +container image layers and writeable layers is on this second filesystem. + +The first filesystem does not hold any image layers or writeable layers. + +Your node can have as many other filesystems, not used for Kubernetes, +as you like. +--> + +{{% tab name="双文件系统" %}} + +你使用节点上的某个文件系统来保存运行 Pods 时产生的临时性数据：日志和 +`emptyDir` 卷等。你可以使用这个文件系统来保存其他数据（例如：与 Kubernetes +无关的其他系统日志）；这个文件系统还可以是根文件系统。 + +kubelet 也将 +[节点层面的容器日志](/zh/docs/concepts/cluster-administration/logging/#logging-at-the-node-level) +写入到第一个文件系统中，并按临时性本地存储的方式对待之。 + +同时你使用另一个由不同逻辑存储设备支持的文件系统。在这种配置下，你会告诉 +kubelet 将容器镜像层和可写层保存到这第二个文件系统上的某个目录中。 + +第一个文件系统中不包含任何镜像层和可写层数据。 + +当然，你的集群节点上还可以有很多其他与 Kubernetes 没有关联的文件系统。 +{{% /tab %}} +{{< /tabs >}} + +<!-- +The kubelet can measure how much local storage it is using. It does this provided +that: + +- the `LocalStorageCapacityIsolation` + [feature gate](/docs/reference/command-line-tools-reference/feature-gates/) + is enabled (the feature is on by default), and +- you have set up the node using one of the supported configurations + for local ephemeral storage. + +If you have a different configuration, then the kubelet does not apply resource +limits for ephemeral local storage. + +{{< note >}} +The kubelet tracks `tmpfs` emptyDir volumes as container memory use, rather +than as local ephemeral storage. +{{< /note >}} +--> + +kubelet 能够度量其本地存储的用量。实现度量机制的前提是： + +- `LocalStorageCapacityIsolation` [特性门控](/zh/docs/reference/command-line-tools-reference/feature-gates/)被启用（默认状态），并且 +- 你已经对节点进行了配置，使之使用所支持的本地临时性储存配置方式之一 + +如果你的节点配置不同于以上预期，kubelet 就无法对临时性本地存储的资源约束实施限制。 + +{{< note >}} +kubelet 会将 `tmpfs` emptyDir 卷的用量当作容器内存用量，而不是本地临时性存储来统计。 +{{< /note >}} + +<!-- +### Setting requests and limits for local ephemeral storage + +You can use _ephemeral-storage_ for managing local ephemeral storage. Each Container of a Pod can specify one or more of the following: + +* `spec.containers[].resources.limits.ephemeral-storage` +* `spec.containers[].resources.requests.ephemeral-storage` + +Limits and requests for `ephemeral-storage` are measured in bytes. You can express storage as +a plain integer or as a fixed-point integer using one of these suffixes: +E, P, T, G, M, K. You can also use the power-of-two equivalents: Ei, Pi, Ti, Gi, +Mi, Ki. For example, the following represent roughly the same value: + +```shell +128974848, 129e6, 129M, 123Mi +``` +--> + +### 为本地临时性存储设置请求和约束值 + +你可以使用_ephemeral-storage_来管理本地临时性存储。 +Pod 中的每个 Container 可以设置以下属性： + +* `spec.containers[].resources.limits.ephemeral-storage` +* `spec.containers[].resources.requests.ephemeral-storage` + +`ephemeral-storage` 的请求和约束值是按字节计量的。你可以使用一般整数或者定点整数 +加上下面的后缀来表达存储量：E、P、T、G、M、K。 +你也可以使用对应的 2 的幂级数来表达：Ei、Pi、Ti、Gi、Mi、Ki。 +例如，下面的表达式所表达的大致是同一个值： + +```shell +128974848, 129e6, 129M, 123Mi +``` + +<!-- +In the following example, the Pod has two Containers. Each Container has a request of 2GiB of local ephemeral storage. Each Container has a limit of 4GiB of local ephemeral storage. Therefore, the Pod has a request of 4GiB of local ephemeral storage, and a limit of 8GiB of local ephemeral storage. +--> + +在下面的例子中，Pod 包含两个 Container。每个 Container 请求 2 GiB 大小的本地临时性存储。 +每个 Container 都设置了 4 GiB 作为其本地临时性存储的约束值。 +因此，整个 Pod 的本地临时性存储请求是 4 GiB，且其本地临时性存储的约束为 8 GiB。 + +```yaml +apiVersion: v1 +kind: Pod +metadata: + name: frontend +spec: + containers: + - name: app + image: images.my-company.example/app:v4 + resources: + requests: + ephemeral-storage: "2Gi" + limits: + ephemeral-storage: "4Gi" + - name: log-aggregator + image: images.my-company.example/log-aggregator:v6 + resources: + requests: + ephemeral-storage: "2Gi" + limits: + ephemeral-storage: "4Gi" +``` + +<!-- +### How Pods with ephemeral-storage requests are scheduled + +When you create a Pod, the Kubernetes scheduler selects a node for the Pod to +run on. Each node has a maximum amount of local ephemeral storage it can provide for Pods. For more information, see [Node Allocatable](/docs/tasks/administer-cluster/reserve-compute-resources/#node-allocatable). + +The scheduler ensures that the sum of the resource requests of the scheduled Containers is less than the capacity of the node. +--> + +### 带 ephemeral-storage 的 Pods 的调度行为 + +当你创建一个 Pod 时，Kubernetes 调度器会为 Pod 选择一个节点来运行之。 +每个节点都有一个本地临时性存储的上限，是其可提供给 Pods 使用的总量。 +欲了解更多信息，可参考 +[节点可分配资源](/zh/docs/tasks/administer-cluster/reserve-compute-resources/#node-allocatable) +节。 + +调度器会确保所调度的 Containers 的资源请求总和不会超出节点的资源容量。 + +<!-- +### Ephemeral storage consumption management {#resource-emphemeralstorage-consumption} + +If the kubelet is managing local ephemeral storage as a resource, then the +kubelet measures storage use in: + +- `emptyDir` volumes, except _tmpfs_ `emptyDir` volumes +- directories holding node-level logs +- writeable container layers + +If a Pod is using more ephemeral storage than you allow it to, the kubelet +sets an eviction signal that triggers Pod eviction. + +For container-level isolation, if a Container's writable layer and log +usage exceeds its storage limit, the kubelet marks the Pod for eviction. + +For pod-level isolation the kubelet works out an overall Pod storage limit by +summing the limits for the containers in that Pod. In this case, if the sum of +the local ephemeral storage usage from all containers and also the Pod's `emptyDir` +volumes exceeds the overall Pod storage limit, then the kubelet also marks the Pod +for eviction. + +--> + +### 临时性存储消耗的管理 {#resource-emphemeralstorage-consumption} + +如果 kubelet 将本地临时性存储作为资源来管理，则 kubelet 会度量以下各处的存储用量： + +- `emptyDir` 卷，除了 _tmpfs_ `emptyDir` 卷 +- 保存节点层面日志的目录 +- 可写入的容器镜像层 + +如果某 Pod 的临时存储用量超出了你所允许的范围，kubelet +会向其发出逐出（eviction）信号，触发该 Pod 被逐出所在节点。 + +就容器层面的隔离而言，如果某容器的可写入镜像层和日志用量超出其存储约束， +kubelet 也会将所在的 Pod 标记为逐出候选。 + +就 Pod 层面的隔离而言，kubelet 会将 Pod 中所有容器的约束值相加，得到 Pod +存储约束的总值。如果所有容器的本地临时性存储用量总和加上 Pod 的 `emptyDir` +卷的用量超出 Pod 存储约束值，kubelet 也会将该 Pod 标记为逐出候选。 + +<!-- +{{< caution >}} +If the kubelet is not measuring local ephemeral storage, then a Pod +that exceeds its local storage limit will not be evicted for breaching +local storage resource limits. + +However, if the filesystem space for writeable container layers, node-level logs, +or `emptyDir` volumes falls low, the node +{{< glossary_tooltip text="taints" term_id="taint" >}} itself as short on local storage +and this taint triggers eviction for any Pods that don't specifically tolerate the taint. + +See the supported [configurations](#configurations-for-local-ephemeral-storage) +for ephemeral local storage. +{{< /caution >}} +--> + +{{< caution >}} +如果 kubelet 没有度量本地临时性存储的用量，即使 Pod +的本地存储用量超出其约束值也不会被逐出。 + +不过，如果用于可写入容器镜像层、节点层面日志或者 `emptyDir` 卷的文件系统中可用空间太少， +节点会为自身设置本地存储不足的{{< glossary_tooltip text="污点" term_id="taint" >}} 标签。 +这一污点会触发对那些无法容忍该污点的 Pods 的逐出操作。 + +关于临时性本地存储的配置信息，请参考[这里](#configurations-for-local-ephemeral-storage) +{{< /caution >}} + +<!-- +The kubelet supports different ways to measure Pod storage use: + +The kubelet performs regular, schedules checks that scan each +`emptyDir` volume, container log directory, and writeable container layer. + +The scan measures how much space is used. + +{{< note >}} +In this mode, the kubelet does not track open file descriptors +for deleted files. + +If you (or a container) create a file inside an `emptyDir` volume, +something then opens that file, and you delete the file while it is +still open, then the inode for the deleted file stays until you close +that file but the kubelet does not categorize the space as in use. +{{< /note >}} +--> + +kubelet 支持使用不同方式来度量 Pod 的存储用量： + +{{< tabs name="resource-emphemeralstorage-measurement" >}} +{{% tab name="周期性扫描" %}} +kubelet 按预定周期执行扫描操作，检查 `emptyDir` 卷、容器日志目录以及可写入容器镜像层。 + +这一扫描会度量存储空间用量。 + +{{< note >}} +在这种模式下，kubelet 并不检查已删除文件所对应的、仍处于打开状态的文件描述符。 + +如果你（或者容器）在 `emptyDir` 卷中创建了一个文件，写入一些内容之后再次打开 +该文件并执行了删除操作，所删除文件对应的 inode 仍然存在，直到你关闭该文件为止。 +kubelet 不会将该文件所占用的空间视为已使用空间。 +{{< /note >}} + +{{% /tab %}} + +<!-- +Project quotas are an operating-system level feature for managing +storage use on filesystems. With Kubernetes, you can enable project +quotas for monitoring storage use. Make sure that the filesystem +backing the `emptyDir` volumes, on the node, provides project quota support. +For example, XFS and ext4fs offer project quotas. + +{{< note >}} +Project quotas let you monitor storage use; they do not enforce limits. +{{< /note >}} +--> + +{{% tab name="文件系统项目配额" %}} + +{{< feature-state for_k8s_version="v1.15" state="alpha" >}} + +项目配额（Project Quota）是一个操作系统层的功能特性，用来管理文件系统中的存储用量。 +在 Kubernetes 中，你可以启用项目配额以监视存储用量。 +你需要确保节点上为 `emptyDir` 提供存储的文件系统支持项目配额。 +例如，XFS 和 ext4fs 文件系统都支持项目配额。 + +{{< note >}} +项目配额可以帮你监视存储用量，但无法对存储约束执行限制。 +{{< /note >}} + +<!-- +Kubernetes uses project IDs starting from `1048576`. The IDs in use are +registered in `/etc/projects` and `/etc/projid`. If project IDs in +this range are used for other purposes on the system, those project +IDs must be registered in `/etc/projects` and `/etc/projid` so that +Kubernetes does not use them. + +Quotas are faster and more accurate than directory scanning. When a +directory is assigned to a project, all files created under a +directory are created in that project, and the kernel merely has to +keep track of how many blocks are in use by files in that project. +If a file is created and deleted, but has an open file descriptor, +it continues to consume space. Quota tracking records that space accurately +whereas directory scans overlook the storage used by deleted files. +--> + +Kubernetes 所使用的项目 ID 始于 `1048576`。 +所使用的 IDs 会注册在 `/etc/projects` 和 `/etc/projid` 文件中。 +如果该范围中的项目 ID 已经在系统中被用于其他目的，则已占用的项目 IDs +也必须注册到 `/etc/projects` 和 `/etc/projid` 中，这样 Kubernetes +才不会使用它们。 + +配额方式与目录扫描方式相比速度更快，结果更精确。当某个目录被分配给某个项目时， +该目录下所创建的所有文件都属于该项目，内核只需要跟踪该项目中的文件所使用的存储块个数。 +如果某文件被创建后又被删除，但对应文件描述符仍处于打开状态， +该文件会继续耗用存储空间。配额跟踪技术能够精确第记录对应存储空间的状态， +而目录扫描方式会忽略被删除文件所占用的空间。 + +<!-- +If you want to use project quotas, you should: + +* Enable the `LocalStorageCapacityIsolationFSQuotaMonitoring=true` + [feature gate](/docs/reference/command-line-tools-reference/feature-gates/) + in the kubelet configuration. + +* Ensure that the the root filesystem (or optional runtime filesystem) + has project quotas enabled. All XFS filesystems support project quotas. + For ext4 filesystems, you need to enable the project quota tracking feature + while the filesystem is not mounted. + ```bash + # For ext4, with /dev/block-device not mounted + sudo tune2fs -O project -Q prjquota /dev/block-device + ``` + +* Ensure that the root filesystem (or optional runtime filesystem) is + mounted with project quotas enabled. For both XFS and ext4fs, the + mount option is named `prjquota`. +--> + +如果你希望使用项目配额，你需要： + +* 在 kubelet 配置中启用 `LocalStorageCapacityIsolationFSQuotaMonitoring=true` + [特性门控](/zh/docs/reference/command-line-tools-reference/feature-gates/)。 + +* 确保根文件系统（或者可选的运行时文件系统）启用了项目配额。所有 XFS + 文件系统都支持项目配额。 + 对 extf 文件系统而言，你需要在文件系统尚未被挂载时启用项目配额跟踪特性： + + ```bash + # 对 ext4 而言，在 /dev/block-device 尚未被挂载时执行下面操作 + sudo tune2fs -O project -Q prjquota /dev/block-device + ``` + +* 确保根文件系统（或者可选的运行时文件系统）在挂载时项目配额特性是被启用了的。 + 对于 XFS 和 ext4fs 而言，对应的挂载选项称作 `prjquota`。 + +{{% /tab %}} +{{< /tabs >}} + +<!-- +## Extended resources + +Extended resources are fully-qualified resource names outside the +`kubernetes.io` domain. They allow cluster operators to advertise and users to +consume the non-Kubernetes-built-in resources. + +There are two steps required to use Extended Resources. First, the cluster +operator must advertise an Extended Resource. Second, users must request the +Extended Resource in Pods. +--> + +## 扩展资源（Extended Resources） {#extended-resources} + +扩展资源是 `kubernetes.io` 域名之外的标准资源名称。 +它们使得集群管理员能够颁布非 Kubernetes 内置资源，而用户可以使用他们。 + +使用扩展资源需要两个步骤。首先，集群管理员必须颁布扩展资源。 +其次，用户必须在 Pod 中请求扩展资源。 + +<!-- +### Managing extended resources + +#### Node-level extended resources + +Node-level extended resources are tied to nodes. + +##### Device plugin managed resources +See [Device +Plugin](/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins/) +for how to advertise device plugin managed resources on each node. +--> + +### 管理扩展资源 + +#### 节点级扩展资源 + +节点级扩展资源绑定到节点。 + +##### 设备插件管理的资源 + +有关如何颁布在各节点上由设备插件所管理的资源，请参阅 +[设备插件](/zh/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins/)。 + +<!-- +##### Other resources +To advertise a new node-level extended resource, the cluster operator can +submit a `PATCH` HTTP request to the API server to specify the available +quantity in the `status.capacity` for a node in the cluster. After this +operation, the node's `status.capacity` will include a new resource. The +`status.allocatable` field is updated automatically with the new resource +asynchronously by the kubelet. Note that because the scheduler uses the node +`status.allocatable` value when evaluating Pod fitness, there may be a short +delay between patching the node capacity with a new resource and the first Pod +that requests the resource to be scheduled on that node. +--> + +##### 其他资源 + +为了颁布新的节点级扩展资源，集群操作员可以向 API 服务器提交 `PATCH` HTTP 请求， +以在集群中节点的 `status.capacity` 中为其配置可用数量。 +完成此操作后，节点的 `status.capacity` 字段中将包含新资源。 +kubelet 会异步地对 `status.allocatable` 字段执行自动更新操作，使之包含新资源。 +请注意，由于调度器在评估 Pod 是否适合在某节点上执行时会使用节点的 `status.allocatable` 值， +在更新节点容量使之包含新资源之后和请求该资源的第一个 Pod 被调度到该节点之间， +可能会有短暂的延迟。 + +<!-- +**Example:** + +Here is an example showing how to use `curl` to form an HTTP request that +advertises five "example.com/foo" resources on node `k8s-node-1` whose master +is `k8s-master`. +--> + +**示例：** + +这是一个示例，显示了如何使用 `curl` 构造 HTTP 请求，公告主节点为 `k8s-master` +的节点 `k8s-node-1` 上存在五个 `example.com/foo` 资源。 + +```shell +curl --header "Content-Type: application/json-patch+json" \ +--request PATCH \ +--data '[{"op": "add", "path": "/status/capacity/example.com~1foo", "value": "5"}]' \ +http://k8s-master:8080/api/v1/nodes/k8s-node-1/status +``` + +<!-- +{{< note >}} +In the preceding request, `~1` is the encoding for the character `/` +in the patch path. The operation path value in JSON-Patch is interpreted as a +JSON-Pointer. For more details, see +{{< /note >}} +--> + +{{< note >}} +在前面的请求中，`~1` 是在 patch 路径中对字符 `/` 的编码。 +JSON-Patch 中的操作路径的值被视为 JSON-Pointer 类型。 +有关更多详细信息，请参见 +[IETF RFC 6901 第 3 节](https://tools.ietf.org/html/rfc6901#section-3)。 +{{< /note >}} + +<!-- +#### Cluster-level extended resources + +Cluster-level extended resources are not tied to nodes. They are usually managed +by scheduler extenders, which handle the resource consumption and resource quota. + +You can specify the extended resources that are handled by scheduler extenders +in [scheduler policy +configuration](https://github.com/kubernetes/kubernetes/blob/release-1.10/pkg/scheduler/api/v1/types.go#L31). +--> + +#### 集群层面的扩展资源 + +集群层面的扩展资源并不绑定到具体节点。 +它们通常由调度器扩展程序（Scheduler Extenders）管理，这些程序处理资源消耗和资源配额。 + +您可以在[调度器策略配置](https://github.com/kubernetes/kubernetes/blob/release-1.10/pkg/scheduler/api/v1/types.go#L31)中指定由调度器扩展程序处理的扩展资源。 + +<!-- +**Example:** + +The following configuration for a scheduler policy indicates that the +cluster-level extended resource "example.com/foo" is handled by the scheduler +extender. + +- The scheduler sends a Pod to the scheduler extender only if the Pod requests + "example.com/foo". +- The `ignoredByScheduler` field specifies that the scheduler does not check + the "example.com/foo" resource in its `PodFitsResources` predicate. +--> + +**示例：** + +下面的调度器策略配置标明集群层扩展资源 "example.com/foo" 由调度器扩展程序处理。 + +- 仅当 Pod 请求 "example.com/foo" 时，调度器才会将 Pod 发送到调度器扩展程序。 +- `ignoredByScheduler` 字段指定调度器不要在其 `PodFitsResources` 断言中检查 + "example.com/foo" 资源。 + +```json +{ + "kind": "Policy", + "apiVersion": "v1", + "extenders": [ + { + "urlPrefix":"<extender-endpoint>", + "bindVerb": "bind", + "managedResources": [ + { + "name": "example.com/foo", + "ignoredByScheduler": true + } + ] + } + ] +} +``` + +<!-- +### Consuming extended resources + +Users can consume extended resources in Pod specs just like CPU and memory. +The scheduler takes care of the resource accounting so that no more than the +available amount is simultaneously allocated to Pods. + +The API server restricts quantities of extended resources to whole numbers. +Examples of _valid_ quantities are `3`, `3000m` and `3Ki`. Examples of +_invalid_ quantities are `0.5` and `1500m`. +--> + +### 使用扩展资源 + +就像 CPU 和内存一样，用户可以在 Pod 的规约中使用扩展资源。 +调度器负责资源的核算，确保同时分配给 Pod 的资源总量不会超过可用数量。 + +<!-- +{{< note >}} +Extended resources replace Opaque Integer Resources. +Users can use any domain name prefix other than `kubernetes.io` which is reserved. +{{< /note >}} +--> + +{{< note >}} +扩展资源取代了非透明整数资源（Opaque Integer Resources，OIR）。 +用户可以使用 `kubernetes.io` （保留）以外的任何域名前缀。 +{{< /note >}} + +<!-- +To consume an extended resource in a Pod, include the resource name as a key +in the `spec.containers[].resources.limits` map in the container spec. + +{{< note >}} +Extended resources cannot be overcommitted, so request and limit +must be equal if both are present in a container spec. +{{< /note >}} +--> + +要在 Pod 中使用扩展资源，请在容器规范的 `spec.containers[].resources.limits` +映射中包含资源名称作为键。 + +{{< note >}} +扩展资源不能过量使用，因此如果容器规范中同时存在请求和约束，则它们的取值必须相同。 +{{< /note >}} + +<!-- +A Pod is scheduled only if all of the resource requests are satisfied, including +CPU, memory and any extended resources. The Pod remains in the `PENDING` state +as long as the resource request cannot be satisfied. + +**Example:** + +The Pod below requests 2 CPUs and 1 "example.com/foo" (an extended resource). +--> + +仅当所有资源请求（包括 CPU、内存和任何扩展资源）都被满足时，Pod 才能被调度。 +在资源请求无法满足时，Pod 会保持在 `PENDING` 状态。 + +**示例：** + +下面的 Pod 请求 2 个 CPU 和 1 个 "example.com/foo"（扩展资源）。 + +```yaml +apiVersion: v1 +kind: Pod +metadata: + name: my-pod +spec: + containers: + - name: my-container + image: myimage + resources: + requests: + cpu: 2 + example.com/foo: 1 + limits: + example.com/foo: 1 +``` + +<!-- +## Troubleshooting + +### My Pods are pending with event message failedScheduling + +If the scheduler cannot find any node where a Pod can fit, the Pod remains +unscheduled until a place can be found. An event is produced each time the +scheduler fails to find a place for the Pod, like this: +--> + +## 疑难解答 + +### 我的 Pod 处于悬决状态且事件信息显示 failedScheduling + +如果调度器找不到该 Pod 可以匹配的任何节点，则该 Pod 将保持未被调度状态， +直到找到一个可以被调度到的位置。每当调度器找不到 Pod 可以调度的地方时， +会产生一个事件，如下所示： + +```shell +kubectl describe pod frontend | grep -A 3 Events +``` +``` +Events: + FirstSeen LastSeen Count From Subobject PathReason Message + 36s 5s 6 {scheduler} FailedScheduling Failed for reason PodExceedsFreeCPU and possibly others +``` + +<!-- +In the preceding example, the Pod named "frontend" fails to be scheduled due to +insufficient CPU resource on the node. Similar error messages can also suggest +failure due to insufficient memory (PodExceedsFreeMemory). In general, if a Pod +is pending with a message of this type, there are several things to try: +- Add more nodes to the cluster. +- Terminate unneeded Pods to make room for pending Pods. +- Check that the Pod is not larger than all the nodes. For example, if all the + nodes have a capacity of `cpu: 1`, then a Pod with a request of `cpu: 1.1` will + never be scheduled. +You can check node capacities and amounts allocated with the +`kubectl describe nodes` command. For example: +--> + +在上述示例中，由于节点上的 CPU 资源不足，名为 “frontend” 的 Pod 无法被调度。 +由于内存不足（PodExceedsFreeMemory）而导致失败时，也有类似的错误消息。 +一般来说，如果 Pod 处于悬决状态且有这种类型的消息时，你可以尝试如下几件事情： + +- 向集群添加更多节点。 +- 终止不需要的 Pod，为悬决的 Pod 腾出空间。 +- 检查 Pod 所需的资源是否超出所有节点的资源容量。例如，如果所有节点的容量都是`cpu：1`， + 那么一个请求为 `cpu: 1.1` 的 Pod 永远不会被调度。 + +您可以使用 `kubectl describe nodes` 命令检查节点容量和已分配的资源数量。 例如： + +```shell +kubectl describe nodes e2e-test-node-pool-4lw4 +``` +``` +Name: e2e-test-node-pool-4lw4 +[ ... 这里忽略了若干行以便阅读 ...] +Capacity: + cpu: 2 + memory: 7679792Ki + pods: 110 +Allocatable: + cpu: 1800m + memory: 7474992Ki + pods: 110 +[ ... 这里忽略了若干行以便阅读 ...] +Non-terminated Pods: (5 in total) + Namespace Name CPU Requests CPU Limits Memory Requests Memory Limits + --------- ---- ------------ ---------- --------------- ------------- + kube-system fluentd-gcp-v1.38-28bv1 100m (5%) 0 (0%) 200Mi (2%) 200Mi (2%) + kube-system kube-dns-3297075139-61lj3 260m (13%) 0 (0%) 100Mi (1%) 170Mi (2%) + kube-system kube-proxy-e2e-test-... 100m (5%) 0 (0%) 0 (0%) 0 (0%) + kube-system monitoring-influxdb-grafana-v4-z1m12 200m (10%) 200m (10%) 600Mi (8%) 600Mi (8%) + kube-system node-problem-detector-v0.1-fj7m3 20m (1%) 200m (10%) 20Mi (0%) 100Mi (1%) +Allocated resources: + (Total limits may be over 100 percent, i.e., overcommitted.) + CPU Requests CPU Limits Memory Requests Memory Limits + ------------ ---------- --------------- ------------- + 680m (34%) 400m (20%) 920Mi (12%) 1070Mi (14%) +``` + +<!-- +In the preceding output, you can see that if a Pod requests more than 1120m +CPUs or 6.23Gi of memory, it will not fit on the node. + +By looking at the `Pods` section, you can see which Pods are taking up space on +the node. + +The amount of resources available to Pods is less than the node capacity, because +system daemons use a portion of the available resources. The `allocatable` field +[NodeStatus](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#nodestatus-v1-core) +gives the amount of resources that are available to Pods. For more information, see +[Node Allocatable Resources](https://git.k8s.io/community/contributors/design-proposals/node/node-allocatable.md). +The [resource quota](/docs/concepts/policy/resource-quotas/) feature can be configured +to limit the total amount of resources that can be consumed. If used in conjunction +with namespaces, it can prevent one team from hogging all the resources. +--> + +在上面的输出中，你可以看到如果 Pod 请求超过 1120m CPU 或者 6.23Gi 内存，节点将无法满足。 + +通过查看 `Pods` 部分，您将看到哪些 Pod 占用了节点上的资源。 + +可供 Pod 使用的资源量小于节点容量，因为系统守护程序也会使用一部分可用资源。 +[NodeStatus](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#nodestatus-v1-core) +的 `allocatable` 字段给出了可用于 Pod 的资源量。 +有关更多信息，请参阅 [节点可分配资源](https://git.k8s.io/community/contributors/design-proposals/node-allocatable.md)。 + +可以配置 [资源配额](/zh/docs/concepts/policy/resource-quotas/) 功能特性以限制可以使用的资源总量。 +如果与名字空间配合一起使用，就可以防止一个团队占用所有资源。 + +<!-- +### My Container is terminated +Your Container might get terminated because it is resource-starved. To check +whether a Container is being killed because it is hitting a resource limit, call +`kubectl describe pod` on the Pod of interest: +--> + +### 我的容器被终止了 + +你的容器可能因为资源紧张而被终止。要查看容器是否因为遇到资源限制而被杀死， +请针对相关的 Pod 执行 `kubectl describe pod`： + +```shell +kubectl describe pod simmemleak-hra99 +``` + +``` +Name: simmemleak-hra99 +Namespace: default +Image(s): saadali/simmemleak +Node: kubernetes-node-tf0f/10.240.216.66 +Labels: name=simmemleak +Status: Running +Reason: +Message: +IP: 10.244.2.75 +Replication Controllers: simmemleak (1/1 replicas created) +Containers: + simmemleak: + Image: saadali/simmemleak + Limits: + cpu: 100m + memory: 50Mi + State: Running + Started: Tue, 07 Jul 2015 12:54:41 -0700 + Last Termination State: Terminated + Exit Code: 1 + Started: Fri, 07 Jul 2015 12:54:30 -0700 + Finished: Fri, 07 Jul 2015 12:54:33 -0700 + Ready: False + Restart Count: 5 +Conditions: + Type Status + Ready False +Events: + FirstSeen LastSeen Count From SubobjectPath Reason Message + Tue, 07 Jul 2015 12:53:51 -0700 Tue, 07 Jul 2015 12:53:51 -0700 1 {scheduler } scheduled Successfully assigned simmemleak-hra99 to kubernetes-node-tf0f + Tue, 07 Jul 2015 12:53:51 -0700 Tue, 07 Jul 2015 12:53:51 -0700 1 {kubelet kubernetes-node-tf0f} implicitly required container POD pulled Pod container image "k8s.gcr.io/pause:0.8.0" already present on machine + Tue, 07 Jul 2015 12:53:51 -0700 Tue, 07 Jul 2015 12:53:51 -0700 1 {kubelet kubernetes-node-tf0f} implicitly required container POD created Created with docker id 6a41280f516d + Tue, 07 Jul 2015 12:53:51 -0700 Tue, 07 Jul 2015 12:53:51 -0700 1 {kubelet kubernetes-node-tf0f} implicitly required container POD started Started with docker id 6a41280f516d + Tue, 07 Jul 2015 12:53:51 -0700 Tue, 07 Jul 2015 12:53:51 -0700 1 {kubelet kubernetes-node-tf0f} spec.containers{simmemleak} created Created with docker id 87348f12526a +``` + +<!-- +In the preceding example, the `Restart Count: 5` indicates that the `simmemleak` +Container in the Pod was terminated and restarted five times. + +You can call `kubectl get pod` with the `-o go-template=...` option to fetch the status +of previously terminated Containers: +--> + +在上面的例子中，`Restart Count: 5` 意味着 Pod 中的 `simmemleak` 容器被终止并重启了五次。 + +你可以使用 `kubectl get pod` 命令加上 `-o go-template=...` 选项来获取之前终止容器的状态。 + +```shell +kubectl get pod -o go-template='{{range.status.containerStatuses}}{{"Container Name: "}}{{.name}}{{"\r\nLastState: "}}{{.lastState}}{{end}}' simmemleak-hra99 +``` +``` +Container Name: simmemleak +LastState: map[terminated:map[exitCode:137 reason:OOM Killed startedAt:2015-07-07T20:58:43Z finishedAt:2015-07-07T20:58:43Z containerID:docker://0e4095bba1feccdfe7ef9fb6ebffe972b4b14285d5acdec6f0d3ae8a22fad8b2]] +``` + +<!-- +You can see that the Container was terminated because of `reason:OOM Killed`, where `OOM` stands for Out Of Memory. +--> + +你可以看到容器因为 `reason:OOM killed` 而被终止，`OOM` 表示内存不足（Out Of Memory）。 + +## {{% heading "whatsnext" %}} + +<!-- +* Get hands-on experience [assigning Memory resources to Containers and Pods](/docs/tasks/configure-pod-container/assign-memory-resource/). + +* Get hands-on experience [assigning CPU resources to Containers and Pods](/docs/tasks/configure-pod-container/assign-cpu-resource/). + +* For more details about the difference between requests and limits, see + [Resource QoS](https://git.k8s.io/community/contributors/design-proposals/node/resource-qos.md). + +* Read the [Container](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#container-v1-core) API reference + +* Read the [ResourceRequirements](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#resourcerequirements-v1-core) API reference + +* Read about [project quotas](http://xfs.org/docs/xfsdocs-xml-dev/XFS_User_Guide/tmp/en-US/html/xfs-quotas.html) in XFS +--> + +* 获取将 [分配内存资源给容器和 Pod ](/zh/docs/tasks/configure-pod-container/assign-memory-resource/) 的实践经验 +* 获取将 [分配 CPU 资源给容器和 Pod ](/zh/docs/tasks/configure-pod-container/assign-cpu-resource/) 的实践经验 +* 关于请求和约束之间的区别，细节信息可参见[资源服务质量](https://git.k8s.io/community/contributors/design-proposals/node/resource-qos.md) +* 阅读 API 参考文档中 [Container](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#container-v1-core) 部分。 +* 阅读 API 参考文档中 [ResourceRequirements](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#resourcerequirements-v1-core) 部分。 +* 阅读 XFS 中关于 [项目配额](https://xfs.org/docs/xfsdocs-xml-dev/XFS_User_Guide/tmp/en-US/html/xfs-quotas.html) 的文档。 + diff --git a/content/zh/docs/concepts/configuration/organize-cluster-access-kubeconfig.md b/content/zh/docs/concepts/configuration/organize-cluster-access-kubeconfig.md index c44ad088a9..db4176391a 100644 --- a/content/zh/docs/concepts/configuration/organize-cluster-access-kubeconfig.md +++ b/content/zh/docs/concepts/configuration/organize-cluster-access-kubeconfig.md @@ -4,12 +4,10 @@ content_type: concept weight: 60 --- <!-- ---- title: Organizing Cluster Access Using kubeconfig Files content_type: concept weight: 60 ---- ----> +--> <!-- overview --> @@ -18,7 +16,7 @@ Use kubeconfig files to organize information about clusters, users, namespaces, authentication mechanisms. The `kubectl` command-line tool uses kubeconfig files to find the information it needs to choose a cluster and communicate with the API server of a cluster. ----> +--> 使用 kubeconfig 文件来组织有关集群、用户、命名空间和身份认证机制的信息。`kubectl` 命令行工具使用 kubeconfig 文件来查找选择集群所需的信息，并与集群的 API 服务器进行通信。 <!-- @@ -27,7 +25,7 @@ A file that is used to configure access to clusters is called a *kubeconfig file*. This is a generic way of referring to configuration files. It does not mean that there is a file named `kubeconfig`. {{< /note >}} ----> +--> {{< note >}} 用于配置集群访问的文件称为 *kubeconfig 文件*。这是引用配置文件的通用方法。这并不意味着有一个名为 `kubeconfig` 的文件 {{< /note >}} @@ -36,37 +34,37 @@ It does not mean that there is a file named `kubeconfig`. By default, `kubectl` looks for a file named `config` in the `$HOME/.kube` directory. You can specify other kubeconfig files by setting the `KUBECONFIG` environment variable or by setting the -[`--kubeconfig`](/docs/reference/generated/kubectl/kubectl/) flag. ----> -默认情况下，`kubectl` 在 `$HOME/.kube` 目录下查找名为 `config` 的文件。您可以通过设置 `KUBECONFIG` 环境变量或者设置[`--kubeconfig`](/docs/reference/generated/kubectl/kubectl/)参数来指定其他 kubeconfig 文件。 +[`-kubeconfig`](/docs/reference/generated/kubectl/kubectl/) flag. +--> +默认情况下，`kubectl` 在 `$HOME/.kube` 目录下查找名为 `config` 的文件。 +您可以通过设置 `KUBECONFIG` 环境变量或者设置 +[`--kubeconfig`](/docs/reference/generated/kubectl/kubectl/)参数来指定其他 kubeconfig 文件。 <!-- For step-by-step instructions on creating and specifying kubeconfig files, see [Configure Access to Multiple Clusters](/docs/tasks/access-application-cluster/configure-access-multiple-clusters). ----> -有关创建和指定 kubeconfig 文件的分步说明，请参阅[配置对多集群的访问](/docs/tasks/access-application-cluster/configure-access-multiple-clusters)。 - - - +--> +有关创建和指定 kubeconfig 文件的分步说明，请参阅 +[配置对多集群的访问](/zh/docs/tasks/access-application-cluster/configure-access-multiple-clusters)。 <!-- body --> <!-- ## Supporting multiple clusters, users, and authentication mechanisms ----> +--> ## 支持多集群、用户和身份认证机制 <!-- Suppose you have several clusters, and your users and components authenticate in a variety of ways. For example: ----> +--> 假设您有多个集群，并且您的用户和组件以多种方式进行身份认证。比如： <!-- - A running kubelet might authenticate using certificates. - A user might authenticate using tokens. - Administrators might have sets of certificates that they provide to individual users. ----> +--> - 正在运行的 kubelet 可能使用证书在进行认证。 - 用户可能通过令牌进行认证。 - 管理员可能拥有多个证书集合提供给各用户。 @@ -75,12 +73,12 @@ in a variety of ways. For example: With kubeconfig files, you can organize your clusters, users, and namespaces. You can also define contexts to quickly and easily switch between clusters and namespaces. ----> +--> 使用 kubeconfig 文件，您可以组织集群、用户和命名空间。您还可以定义上下文，以便在集群和命名空间之间快速轻松地切换。 <!-- ## Context ----> +--> ## 上下文（Context） <!-- @@ -88,12 +86,12 @@ A *context* element in a kubeconfig file is used to group access parameters under a convenient name. Each context has three parameters: cluster, namespace, and user. By default, the `kubectl` command-line tool uses parameters from the *current context* to communicate with the cluster. ----> +--> 通过 kubeconfig 文件中的 *context* 元素，使用简便的名称来对访问参数进行分组。每个上下文都有三个参数：cluster、namespace 和 user。默认情况下，`kubectl` 命令行工具使用 *当前上下文* 中的参数与集群进行通信。 <!-- To choose the current context: ----> +--> 选择当前上下文 ``` kubectl config use-context @@ -101,7 +99,7 @@ kubectl config use-context <!-- ## The KUBECONFIG environment variable ----> +--> ## KUBECONFIG 环境变量 <!-- @@ -110,25 +108,29 @@ For Linux and Mac, the list is colon-delimited. For Windows, the list is semicolon-delimited. The `KUBECONFIG` environment variable is not required. If the `KUBECONFIG` environment variable doesn't exist, `kubectl` uses the default kubeconfig file, `$HOME/.kube/config`. ----> -`KUBECONFIG` 环境变量包含一个 kubeconfig 文件列表。对于 Linux 和 Mac，列表以冒号分隔。对于 Windows，列表以分号分隔。`KUBECONFIG` 环境变量不是必要的。如果 `KUBECONFIG` 环境变量不存在，`kubectl` 使用默认的 kubeconfig 文件，`$HOME/.kube/config`。 +--> +`KUBECONFIG` 环境变量包含一个 kubeconfig 文件列表。 +对于 Linux 和 Mac，列表以冒号分隔。对于 Windows，列表以分号分隔。 +`KUBECONFIG` 环境变量不是必要的。 +如果 `KUBECONFIG` 环境变量不存在，`kubectl` 使用默认的 kubeconfig 文件，`$HOME/.kube/config`。 <!-- If the `KUBECONFIG` environment variable does exist, `kubectl` uses an effective configuration that is the result of merging the files listed in the `KUBECONFIG` environment variable. ----> +--> 如果 `KUBECONFIG` 环境变量存在，`kubectl` 使用 `KUBECONFIG` 环境变量中列举的文件合并后的有效配置。 <!-- ## Merging kubeconfig files ----> +--> ## 合并 kubeconfig 文件 <!-- To see your configuration, enter this command: ----> +--> 要查看配置，输入以下命令： + ```shell kubectl config view ``` @@ -136,16 +138,16 @@ kubectl config view <!-- As described previously, the output might be from a single kubeconfig file, or it might be the result of merging several kubeconfig files. ----> +--> 如前所述，输出可能来自 kubeconfig 文件，也可能是合并多个 kubeconfig 文件的结果。 <!-- Here are the rules that `kubectl` uses when it merges kubeconfig files: ----> +--> 以下是 `kubectl` 在合并 kubeconfig 文件时使用的规则。 <!-- -1. If the `--kubeconfig` flag is set, use only the specified file. Do not merge. +1. If the `-kubeconfig` flag is set, use only the specified file. Do not merge. Only one instance of this flag is allowed. Otherwise, if the `KUBECONFIG` environment variable is set, use it as a @@ -160,7 +162,7 @@ Here are the rules that `kubectl` uses when it merges kubeconfig files: Example: Preserve the context of the first file to set `current-context`. Example: If two files specify a `red-user`, use only values from the first file's `red-user`. Even if the second file has non-conflicting entries under `red-user`, discard them. ----> +--> 1. 如果设置了 `--kubeconfig` 参数，则仅使用指定的文件。不进行合并。此参数只能使用一次。 否则，如果设置了 `KUBECONFIG` 环境变量，将它用作应合并的文件列表。根据以下规则合并 `KUBECONFIG` 环境变量中列出的文件： @@ -173,20 +175,21 @@ Here are the rules that `kubectl` uses when it merges kubeconfig files: <!-- For an example of setting the `KUBECONFIG` environment variable, see [Setting the KUBECONFIG environment variable](/docs/tasks/access-application-cluster/configure-access-multiple-clusters/#set-the-kubeconfig-environment-variable). ----> - 有关设置 `KUBECONFIG` 环境变量的示例，请参阅[设置 KUBECONFIG 环境变量](/docs/tasks/access-application-cluster/configure-access-multiple-clusters/#set-the-kubeconfig-environment-variable)。 +--> + 有关设置 `KUBECONFIG` 环境变量的示例，请参阅 + [设置 KUBECONFIG 环境变量](/zh/docs/tasks/access-application-cluster/configure-access-multiple-clusters/#set-the-kubeconfig-environment-variable)。 <!-- Otherwise, use the default kubeconfig file, `$HOME/.kube/config`, with no merging. ----> +--> 否则，使用默认的 kubeconfig 文件， `$HOME/.kube/config`，不进行合并。 <!-- 1. Determine the context to use based on the first hit in this chain: - 1. Use the `--context` command-line flag if it exists. + 1. Use the `-context` command-line flag if it exists. 2. Use the `current-context` from the merged kubeconfig files. ----> +--> 1. 根据此链中的第一个匹配确定要使用的上下文。 1. 如果存在，使用 `--context` 命令行参数。 @@ -194,7 +197,7 @@ Here are the rules that `kubectl` uses when it merges kubeconfig files: <!-- An empty context is allowed at this point. ----> +--> 这种场景下允许空上下文。 <!-- @@ -204,7 +207,7 @@ Here are the rules that `kubectl` uses when it merges kubeconfig files: 1. Use a command-line flag if it exists: `--user` or `--cluster`. 2. If the context is non-empty, take the user or cluster from the context. ----> +--> 1. 确定集群和用户。此时，可能有也可能没有上下文。根据此链中的第一个匹配确定集群和用户，这将运行两次：一次用于用户，一次用于集群。 1. 如果存在，使用命令行参数：`--user` 或者 `--cluster`。 @@ -212,7 +215,7 @@ Here are the rules that `kubectl` uses when it merges kubeconfig files: <!-- The user and cluster can be empty at this point. ----> +--> 这种场景下用户和集群可以为空。 <!-- @@ -223,7 +226,7 @@ Here are the rules that `kubectl` uses when it merges kubeconfig files: 1. Use command line flags if they exist: `--server`, `--certificate-authority`, `--insecure-skip-tls-verify`. 2. If any cluster information attributes exist from the merged kubeconfig files, use them. 3. If there is no server location, fail. ----> +--> 1. 确定要使用的实际集群信息。此时，可能有也可能没有集群信息。基于此链构建每个集群信息；第一个匹配项会被采用： 1. 如果存在：`--server`、`--certificate-authority` 和 `--insecure-skip-tls-verify`，使用命令行参数。 @@ -238,7 +241,7 @@ Here are the rules that `kubectl` uses when it merges kubeconfig files: 1. Use command line flags if they exist: `--client-certificate`, `--client-key`, `--username`, `--password`, `--token`. 2. Use the `user` fields from the merged kubeconfig files. 3. If there are two conflicting techniques, fail. ----> +--> 2. 确定要使用的实际用户信息。使用与集群信息相同的规则构建用户信息，但每个用户只允许一种身份认证技术： 1. 如果存在：`--client-certificate`、`--client-key`、`--username`、`--password` 和 `--token`，使用命令行参数。 @@ -248,12 +251,12 @@ Here are the rules that `kubectl` uses when it merges kubeconfig files: <!-- 3. For any information still missing, use default values and potentially prompt for authentication information. ----> +--> 3. 对于仍然缺失的任何信息，使用其对应的默认值，并可能提示输入身份认证信息。 <!-- ## File references ----> +--> ## 文件引用 <!-- @@ -261,21 +264,17 @@ File and path references in a kubeconfig file are relative to the location of th File references on the command line are relative to the current working directory. In `$HOME/.kube/config`, relative paths are stored relatively, and absolute paths are stored absolutely. ----> -kubeconfig 文件中的文件和路径引用是相对于 kubeconfig 文件的位置。命令行上的文件引用是相当对于当前工作目录的。在 `$HOME/.kube/config` 中，相对路径按相对路径存储，绝对路径按绝对路径存储。 - - - +--> +kubeconfig 文件中的文件和路径引用是相对于 kubeconfig 文件的位置。 +命令行上的文件引用是相当对于当前工作目录的。 +在 `$HOME/.kube/config` 中，相对路径按相对路径存储，绝对路径按绝对路径存储。 ## {{% heading "whatsnext" %}} - <!-- * [Configure Access to Multiple Clusters](/docs/tasks/access-application-cluster/configure-access-multiple-clusters/) * [`kubectl config`](/docs/reference/generated/kubectl/kubectl-commands#config) ---> -* [配置对多集群的访问](/docs/tasks/access-application-cluster/configure-access-multiple-clusters/) +* [配置对多集群的访问](/zh/docs/tasks/access-application-cluster/configure-access-multiple-clusters/) * [`kubectl config`](/docs/reference/generated/kubectl/kubectl-commands#config) - - diff --git a/content/zh/docs/concepts/configuration/overview.md b/content/zh/docs/concepts/configuration/overview.md index da540c0a89..e3cb9ce89b 100644 --- a/content/zh/docs/concepts/configuration/overview.md +++ b/content/zh/docs/concepts/configuration/overview.md @@ -1,18 +1,12 @@ --- -reviewers: -- mikedanese title: 配置最佳实践 content_type: concept weight: 10 --- <!-- ---- -reviewers: -- mikedanese title: Configuration Best Practices content_type: concept weight: 10 ---- --> <!-- overview --> @@ -24,9 +18,8 @@ This document highlights and consolidates configuration best practices that are <!-- This is a living document. If you think of something that is not on this list but might be useful to others, please don't hesitate to file an issue or submit a PR. --> -这是一份活文件。 -如果您认为某些内容不在此列表中但可能对其他人有用，请不要犹豫，提交问题或提交 PR。 - +这是一份不断改进的文件。 +如果您认为某些内容缺失但可能对其他人有用，请不要犹豫，提交 Issue 或提交 PR。 <!-- body --> <!-- @@ -83,15 +76,19 @@ This is a living document. If you think of something that is not on this list bu <!-- - Don't use naked Pods (that is, Pods not bound to a [ReplicaSet](/docs/concepts/workloads/controllers/replicaset/) or [Deployment](/docs/concepts/workloads/controllers/deployment/)) if you can avoid it. Naked Pods will not be rescheduled in the event of a node failure. --> -- 如果您能避免，不要使用 naked Pods（即，Pod 未绑定到[ReplicaSet](/docs/concepts/workloads/controllers/replicaset/) 或[Deployment](/docs/concepts/workloads/controllers/deployment/)）。 - 如果节点发生故障，将不会重新安排 Naked Pods。 +- 如果可能，不要使用独立的 Pods（即，未绑定到 +[ReplicaSet](/zh/docs/concepts/workloads/controllers/replicaset/) 或 +[Deployment](/zh/docs/concepts/workloads/controllers/deployment/) 的 Pod）。 + 如果节点发生故障，将不会重新调度独立的 Pods。 <!-- A Deployment, which both creates a ReplicaSet to ensure that the desired number of Pods is always available, and specifies a strategy to replace Pods (such as [RollingUpdate](/docs/concepts/workloads/controllers/deployment/#rolling-update-deployment)), is almost always preferable to creating Pods directly, except for some explicit [`restartPolicy: Never`](/docs/concepts/workloads/pods/pod-lifecycle/#restart-policy) scenarios. A [Job](/docs/concepts/workloads/controllers/jobs-run-to-completion/) may also be appropriate. --> - Deployment，它创建一个 ReplicaSet 以确保所需数量的 Pod 始终可用，并指定替换 Pod 的策略(例如 [RollingUpdate](/docs/concepts/workloads/controllers/deployment/#rolling-update-deployment))，除了一些显式的[`restartPolicy: Never`](/docs/concepts/workloads/pods/pod-lifecycle/#restart-policy)场景之外，几乎总是优先考虑直接创建 Pod。 -[Job](/docs/concepts/workloads/controllers/jobs-run-to-completion/) 也可能是合适的。 - +Deployment 会创建一个 ReplicaSet 以确保所需数量的 Pod 始终可用，并指定替换 Pod 的策略 +（例如 [RollingUpdate](/zh/docs/concepts/workloads/controllers/deployment/#rolling-update-deployment))， +除了一些显式的[`restartPolicy: Never`](/zh/docs/concepts/workloads/pods/pod-lifecycle/#restart-policy) +场景之外，几乎总是优先考虑直接创建 Pod。 +[Job](/zh/docs/concepts/workloads/controllers/job/) 也可能是合适的。 <!-- ## Services @@ -101,9 +98,10 @@ This is a living document. If you think of something that is not on this list bu <!-- - Create a [Service](/docs/concepts/services-networking/service/) before its corresponding backend workloads (Deployments or ReplicaSets), and before any workloads that need to access it. When Kubernetes starts a container, it provides environment variables pointing to all the Services which were running when the container was started. For example, if a Service named `foo` exists, all containers will get the following variables in their initial environment: --> -- 在其相应的后端工作负载（Deployment 或 ReplicaSet）之前，以及在需要访问它的任何工作负载之前创建[服务](/docs/concepts/services-networking/service/)。 - 当 Kubernetes 启动容器时，它提供指向启动容器时正在运行的所有服务的环境变量。 - 例如，如果存在名为`foo`当服务，则所有容器将在其初始环境中获取以下变量。 +- 在创建相应的后端工作负载（Deployment 或 ReplicaSet），以及在需要访问它的任何工作负载之前创建 + [服务](/zh/docs/concepts/services-networking/service/)。 + 当 Kubernetes 启动容器时，它提供指向启动容器时正在运行的所有服务的环境变量。 + 例如，如果存在名为 `foo` 的服务，则所有容器将在其初始环境中获得以下变量。 ```shell FOO_SERVICE_HOST=<the host the Service is running on> @@ -113,43 +111,51 @@ This is a living document. If you think of something that is not on this list bu <!-- *This does imply an ordering requirement* - any `Service` that a `Pod` wants to access must be created before the `Pod` itself, or else the environment variables will not be populated. DNS does not have this restriction. --> - *这确实意味着订购要求* - 必须在`Pod`本身之前创建`Pod`想要访问的任何`Service`，否则将不会填充环境变量。 - DNS没有此限制。 + *这确实意味着在顺序上的要求* - 必须在 `Pod` 本身被创建之前创建 `Pod` 想要访问的任何 `Service`， + 否则将环境变量不会生效。DNS 没有此限制。 <!-- - An optional (though strongly recommended) [cluster add-on](/docs/concepts/cluster-administration/addons/) is a DNS server. The DNS server watches the Kubernetes API for new `Services` and creates a set of DNS records for each. If DNS has been enabled throughout the cluster then all `Pods` should be able to do name resolution of `Services` automatically. --> -- 一个可选（尽管强烈推荐）[cluster add-on](/docs/concepts/cluster-administration/addons/)是 DNS 服务器。DNS 服务器为新的`Services`监视 Kubernetes API，并为每个创建一组 DNS 记录。 - 如果在整个集群中启用了 DNS，则所有`Pods`应该能够自动对`Services`进行名称解析。 +- 一个可选（尽管强烈推荐）的[集群插件](/zh/docs/concepts/cluster-administration/addons/) + 是 DNS 服务器。DNS 服务器为新的 `Services` 监视 Kubernetes API，并为每个创建一组 DNS 记录。 + 如果在整个集群中启用了 DNS，则所有 `Pods` 应该能够自动对 `Services` 进行名称解析。 <!-- - Don't specify a `hostPort` for a Pod unless it is absolutely necessary. When you bind a Pod to a `hostPort`, it limits the number of places the Pod can be scheduled, because each <`hostIP`, `hostPort`, `protocol`> combination must be unique. If you don't specify the `hostIP` and `protocol` explicitly, Kubernetes will use `0.0.0.0` as the default `hostIP` and `TCP` as the default `protocol`. --> -- 除非绝对必要，否则不要为 Pod 指定`hostPort`。 - 将 Pod 绑定到`hostPort`时，它会限制 Pod 可以调度的位置数，因为每个<`hostIP`, `hostPort`, `protocol`>组合必须是唯一的。如果您没有明确指定`hostIP`和`protocol`，Kubernetes将使用`0.0.0.0`作为默认`hostIP`和`TCP`作为默认`protocol`。 +- 除非绝对必要，否则不要为 Pod 指定 `hostPort`。 + 将 Pod 绑定到`hostPort`时，它会限制 Pod 可以调度的位置数，因为每个 + `<hostIP, hostPort, protocol>`组合必须是唯一的。 + 如果您没有明确指定 `hostIP` 和 `protocol`，Kubernetes 将使用 `0.0.0.0` 作为默认 + `hostIP` 和 `TCP` 作为默认 `protocol`。 <!-- If you only need access to the port for debugging purposes, you can use the [apiserver proxy](/docs/tasks/access-application-cluster/access-cluster/#manually-constructing-apiserver-proxy-urls) or [`kubectl port-forward`](/docs/tasks/access-application-cluster/port-forward-access-application-cluster/). --> - 如果您只需要访问端口以进行调试，则可以使用[apiserver proxy](/docs/tasks/access-application-cluster/access-cluster/#manually-constructing-apiserver-proxy-urls)或[`kubectl port-forward`](/docs/tasks/access-application-cluster/port-forward-access-application-cluster/)。 + 如果您只需要访问端口以进行调试，则可以使用 + [apiserver proxy](/zh/docs/tasks/access-application-cluster/access-cluster/#manually-constructing-apiserver-proxy-urls)或 + [`kubectl port-forward`](/zh/docs/tasks/access-application-cluster/port-forward-access-application-cluster/)。 <!-- If you explicitly need to expose a Pod's port on the node, consider using a [NodePort](/docs/concepts/services-networking/service/#nodeport) Service before resorting to `hostPort`. --> - 如果您明确需要在节点上公开 Pod 的端口，请在使用`hostPort`之前考虑使用[NodePort](/docs/concepts/services-networking/service/#nodeport) 服务。 + 如果您明确需要在节点上公开 Pod 的端口，请在使用 `hostPort` 之前考虑使用 + [NodePort](/zh/docs/concepts/services-networking/service/#nodeport) 服务。 <!-- - Avoid using `hostNetwork`, for the same reasons as `hostPort`. --> -- 避免使用`hostNetwork`，原因与`hostPort`相同。 +- 避免使用 `hostNetwork`，原因与 `hostPort` 相同。 <!-- - Use [headless Services](/docs/concepts/services-networking/service/#headless- services) (which have a `ClusterIP` of `None`) for easy service discovery when you don't need `kube-proxy` load balancing. --> -- 当您不需要`kube-proxy`负载平衡时，使用 [无头服务](/docs/concepts/services-networking/service/#headless- -services) (具有`None`的`ClusterIP`)以便于服务发现。 +- 当您不需要 `kube-proxy` 负载均衡时，使用 + [无头服务](/zh/docs/concepts/services-networking/service/#headless-services) + (`ClusterIP` 被设置为 `None`)以便于服务发现。 <!-- ## Using Labels @@ -159,29 +165,33 @@ services) (具有`None`的`ClusterIP`)以便于服务发现。 <!-- - Define and use [labels](/docs/concepts/overview/working-with-objects/labels/) that identify __semantic attributes__ of your application or Deployment, such as `{ app: myapp, tier: frontend, phase: test, deployment: v3 }`. You can use these labels to select the appropriate Pods for other resources; for example, a Service that selects all `tier: frontend` Pods, or all `phase: test` components of `app: myapp`. See the [guestbook](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/guestbook/) app for examples of this approach. --> -- 定义并使用[标签](/docs/concepts/overview/working-with-objects/labels/)来识别应用程序或部署的__semantic attributes__，例如`{ app: myapp, tier: frontend, phase: test, deployment: v3 }`。 - 您可以使用这些标签为其他资源选择合适的 Pod；例如，一个选择所有`tier: frontend` Pod 的服务，或者`app: myapp`的所有`phase: test`组件。 - 有关此方法的示例，请参阅[留言板](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/guestbook/) 。 +- 定义并使用[标签](/zh/docs/concepts/overview/working-with-objects/labels/)来识别应用程序 + 或 Deployment 的 __语义属性__，例如`{ app: myapp, tier: frontend, phase: test, deployment: v3 }`。 + 你可以使用这些标签为其他资源选择合适的 Pod； + 例如，一个选择所有 `tier: frontend` Pod 的服务，或者 `app: myapp` 的所有 `phase: test` 组件。 + 有关此方法的示例，请参阅[guestbook](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/guestbook/) 。 <!-- A Service can be made to span multiple Deployments by omitting release-specific labels from its selector. [Deployments](/docs/concepts/workloads/controllers/deployment/) make it easy to update a running service without downtime. --> -通过从选择器中省略特定发行版的标签，可以使服务跨越多个部署。 -[部署](/docs/concepts/workloads/controllers/deployment/)可以在不停机的情况下轻松更新正在运行的服务。 +通过从选择器中省略特定发行版的标签，可以使服务跨越多个 Deployment。 +[Deployment](/zh/docs/concepts/workloads/controllers/deployment/) 可以在不停机的情况下轻松更新正在运行的服务。 <!-- A desired state of an object is described by a Deployment, and if changes to that spec are _applied_, the deployment controller changes the actual state to the desired state at a controlled rate. --> -部署描述了对象的期望状态，并且如果对该规范的更改是_applied_，则部署控制器以受控速率将实际状态改变为期望状态。 +Deployment 描述了对象的期望状态，并且如果对该规范的更改被成功应用， +则 Deployment 控制器以受控速率将实际状态改变为期望状态。 <!-- - You can manipulate labels for debugging. Because Kubernetes controllers (such as ReplicaSet) and Services match to Pods using selector labels, removing the relevant labels from a Pod will stop it from being considered by a controller or from being served traffic by a Service. If you remove the labels of an existing Pod, its controller will create a new Pod to take its place. This is a useful way to debug a previously "live" Pod in a "quarantine" environment. To interactively remove or add labels, use [`kubectl label`](/docs/reference/generated/kubectl/kubectl-commands#label). --> - 您可以操纵标签进行调试。 -- 由于 Kubernetes 控制器（例如 ReplicaSet）和服务使用选择器标签与 Pod 匹配，因此从 Pod 中删除相关标签将阻止其被控制器考虑或由服务提供服务流量。 + 由于 Kubernetes 控制器（例如 ReplicaSet）和服务使用选择器标签来匹配 Pod， + 从 Pod 中删除相关标签将阻止其被控制器考虑或由服务提供服务流量。 如果删除现有 Pod 的标签，其控制器将创建一个新的 Pod 来取代它。 - 这是在"隔离"环境中调试先前"实时"Pod 的有用方法。 - 要以交互方式删除或添加标签，请使用[`kubectl label`](/docs/reference/generated/kubectl/kubectl-commands#label)。 + 这是在"隔离"环境中调试先前"活跃"的 Pod 的有用方法。 + 要以交互方式删除或添加标签，请使用 [`kubectl label`](/docs/reference/generated/kubectl/kubectl-commands#label)。 <!-- ## Container Images @@ -191,38 +201,29 @@ A desired state of an object is described by a Deployment, and if changes to tha <!-- The [imagePullPolicy](/docs/concepts/containers/images/#updating-images) and the tag of the image affect when the [kubelet](/docs/admin/kubelet/) attempts to pull the specified image. --> -当 [kubelet](/docs/admin/kubelet/)尝试拉取指定的镜像时，[imagePullPolicy](/docs/concepts/containers/images/#升级镜像)和镜像标签会生效。 +[imagePullPolicy](/zh/docs/concepts/containers/images/#updating-images)和镜像标签会影响 +[kubelet](/zh/docs/reference/command-line-tools-reference/kubelet/) 何时尝试拉取指定的镜像。 <!-- - `imagePullPolicy: IfNotPresent`: the image is pulled only if it is not already present locally. ---> -- `imagePullPolicy: IfNotPresent`：仅当镜像在本地不存在时镜像才被拉取。 - -<!-- - `imagePullPolicy: Always`: the image is pulled every time the pod is started. ---> -- `imagePullPolicy: Always`：每次启动 pod 的时候都会拉取镜像。 - -<!-- - `imagePullPolicy` is omitted and either the image tag is `:latest` or it is omitted: `Always` is applied. ---> -- `imagePullPolicy` 省略时，镜像标签为 `:latest` 或不存在，使用 `Always` 值。 - -<!-- - `imagePullPolicy` is omitted and the image tag is present but not `:latest`: `IfNotPresent` is applied. ---> -- `imagePullPolicy` 省略时，指定镜像标签并且不是 `:latest`，使用 `IfNotPresent` 值。 - -<!-- - `imagePullPolicy: Never`: the image is assumed to exist locally. No attempt is made to pull the image. --> +- `imagePullPolicy: IfNotPresent`：仅当镜像在本地不存在时才被拉取。 +- `imagePullPolicy: Always`：每次启动 Pod 的时候都会拉取镜像。 +- `imagePullPolicy` 省略时，镜像标签为 `:latest` 或不存在，使用 `Always` 值。 +- `imagePullPolicy` 省略时，指定镜像标签并且不是 `:latest`，使用 `IfNotPresent` 值。 - `imagePullPolicy: Never`：假设镜像已经存在本地，不会尝试拉取镜像。 <!-- To make sure the container always uses the same version of the image, you can specify its [digest](https://docs.docker.com/engine/reference/commandline/pull/#pull-an-image-by-digest-immutable-identifier), for example `sha256:45b23dee08af5e43a7fea6c4cf9c25ccf269ee113168c19722f87876677c5cb2`. The digest uniquely identifies a specific version of the image, so it is never updated by Kubernetes unless you change the digest value. --> {{< note >}} -要确保容器始终使用相同版本的镜像，你可以指定其 [摘要](https://docs.docker.com/engine/reference/commandline/pull/#pull-an-image-by-digest-immutable-identifier), 例如`sha256:45b23dee08af5e43a7fea6c4cf9c25ccf269ee113168c19722f87876677c5cb2`。 +要确保容器始终使用相同版本的镜像，你可以指定其 +[摘要](https://docs.docker.com/engine/reference/commandline/pull/#pull-an-image-by-digest-immutable-identifier)， +例如 `sha256:45b23dee08af5e43a7fea6c4cf9c25ccf269ee113168c19722f87876677c5cb2`。 摘要唯一地标识出镜像的指定版本，因此除非您更改摘要值，否则 Kubernetes 永远不会更新它。 {{< /note >}} @@ -230,15 +231,15 @@ To make sure the container always uses the same version of the image, you can sp You should avoid using the `:latest` tag when deploying containers in production as it is harder to track which version of the image is running and more difficult to roll back properly. --> {{< note >}} -在生产中部署容器时应避免使用 `:latest` 标记，因为更难跟踪正在运行的镜像版本，并且更难以正确回滚。 +在生产中部署容器时应避免使用 `:latest` 标记，因为这样更难跟踪正在运行的镜像版本，并且更难以正确回滚。 {{< /note >}} <!-- The caching semantics of the underlying image provider make even `imagePullPolicy: Always` efficient. With Docker, for example, if the image already exists, the pull attempt is fast because all image layers are cached and no image download is needed. --> {{< note >}} -底层镜像提供程序的缓存语义甚至使 `imagePullPolicy: Always`变得高效。 -例如，对于 Docker，如果镜像已经存在，则拉取尝试很快，因为镜像层都被缓存并且不需要镜像下载。 +底层镜像驱动程序的缓存语义能够使即便 `imagePullPolicy: Always` 的配置也很高效。 +例如，对于 Docker，如果镜像已经存在，则拉取尝试很快，因为镜像层都被缓存并且不需要下载。 {{< /note >}} <!-- @@ -249,19 +250,20 @@ The caching semantics of the underlying image provider make even `imagePullPolic <!-- - Use `kubectl apply -f <directory>`. This looks for Kubernetes configuration in all `.yaml`, `.yml`, and `.json` files in `<directory>` and passes it to `apply`. --> -- 使用`kubectl apply -f <directory>`。 - 它在`<directory>`中的所有`.yaml`，`.yml`和`.json`文件中查找 Kubernetes 配置，并将其传递给`apply`。 +- 使用 `kubectl apply -f <directory>`。 + 它在 `<directory>` 中的所有` .yaml`、`.yml` 和 `.json` 文件中查找 Kubernetes 配置，并将其传递给 `apply`。 <!-- - Use label selectors for `get` and `delete` operations instead of specific object names. See the sections on [label selectors](/docs/concepts/overview/working-with-objects/labels/#label-selectors) and [using labels effectively](/docs/concepts/cluster-administration/manage-deployment/#using-labels-effectively). --> -- 使用标签选择器进行`get`和`delete`操作，而不是特定的对象名称。 -- 请参阅[标签选择器](/docs/concepts/overview/working-with-objects/labels/#label-selectors)和[有效使用标签](/docs/concepts/cluster-administration/manage-deployment/#using-labels-effectively)部分。 +- 使用标签选择器进行 `get` 和 `delete` 操作，而不是特定的对象名称。 +- 请参阅[标签选择器](/zh/docs/concepts/overview/working-with-objects/labels/#label-selectors)和 + [有效使用标签](/zh/docs/concepts/cluster-administration/manage-deployment/#using-labels-effectively)部分。 <!-- - Use `kubectl run` and `kubectl expose` to quickly create single-container Deployments and Services. See [Use a Service to Access an Application in a Cluster](/docs/tasks/access-application-cluster/service-access-application-cluster/) for an example. --> - 使用`kubectl run`和`kubectl expose`来快速创建单容器部署和服务。 - 有关示例，请参阅[使用服务访问集群中的应用程序](/docs/tasks/access-application-cluster/service-access-application-cluster/)。 + 有关示例，请参阅[使用服务访问集群中的应用程序](/zh/docs/tasks/access-application-cluster/service-access-application-cluster/)。 diff --git a/content/zh/docs/concepts/configuration/pod-overhead.md b/content/zh/docs/concepts/configuration/pod-overhead.md index 3c81b3607a..4f785b152e 100644 --- a/content/zh/docs/concepts/configuration/pod-overhead.md +++ b/content/zh/docs/concepts/configuration/pod-overhead.md @@ -18,9 +18,6 @@ on top of the container requests & limits. 在节点上运行 Pod 时，Pod 本身占用大量系统资源。这些资源是运行 Pod 内容器所需资源的附加资源。 _POD 开销_ 是一个特性，用于计算 Pod 基础设施在容器请求和限制之上消耗的资源。 - - - <!-- body --> <!-- @@ -36,8 +33,8 @@ time according to the overhead associated with the Pod's [RuntimeClass](/docs/concepts/containers/runtime-class/). --> -在 Kubernetes 中，Pod 的开销是根据与 Pod 的 [RuntimeClass](/docs/concepts/containers/runtime-class/) 相关联的开销在 -[准入](/docs/reference/access-authn-authz/extensible-admission-controllers/#what-are-admission-webhooks) 时设置的。 +在 Kubernetes 中，Pod 的开销是根据与 Pod 的 [RuntimeClass](/zh/docs/concepts/containers/runtime-class/) 相关联的开销在 +[准入](/zh/docs/reference/access-authn-authz/extensible-admission-controllers/#what-are-admission-webhooks) 时设置的。 <!-- When Pod Overhead is enabled, the overhead is considered in addition to the sum of container @@ -56,7 +53,8 @@ You need to make sure that the `PodOverhead` [feature gate](/docs/reference/command-line-tools-reference/feature-gates/) is enabled (it is on by default as of 1.18) across your cluster, and a `RuntimeClass` is utilized which defines the `overhead` field. --> -您需要确保在集群中启用了 `PodOverhead` [特性门](/docs/reference/command-line-tools-reference/feature-gates/)（在 1.18 默认是开启的），以及一个用于定义 `overhead` 字段的 `RuntimeClass`。 +您需要确保在集群中启用了 `PodOverhead` [特性门控](/zh/docs/reference/command-line-tools-reference/feature-gates/) +（在 1.18 默认是开启的），以及一个用于定义 `overhead` 字段的 `RuntimeClass`。 <!-- ## Usage example @@ -68,7 +66,9 @@ To use the PodOverhead feature, you need a RuntimeClass that defines the `overhe an example, you could use the following RuntimeClass definition with a virtualizing container runtime that uses around 120MiB per Pod for the virtual machine and the guest OS: --> -要使用 PodOverhead 特性，需要一个定义 `overhead` 字段的 RuntimeClass. 作为例子，可以在虚拟机和来宾操作系统中通过一个虚拟化容器运行时来定义 RuntimeClass 如下，其中每个 Pod 大约使用 120MiB: +要使用 PodOverhead 特性，需要一个定义 `overhead` 字段的 RuntimeClass。 +作为例子，可以在虚拟机和寄宿操作系统中通过一个虚拟化容器运行时来定义 +RuntimeClass 如下，其中每个 Pod 大约使用 120MiB: ```yaml --- @@ -123,8 +123,9 @@ updates the workload's PodSpec to include the `overhead` as described in the Run the Pod will be rejected. In the given example, since only the RuntimeClass name is specified, the admission controller mutates the Pod to include an `overhead`. --> -在准入阶段 RuntimeClass [准入控制器](https://kubernetes.io/docs/reference/access-authn-authz/admission-controllers/) 更新工作负载的 PodSpec 以包含 - RuntimeClass 中定义的 `overhead`. 如果 PodSpec 中该字段已定义，该 Pod 将会被拒绝。在这个例子中，由于只指定了 RuntimeClass 名称，所以准入控制器更新了 Pod, 包含了一个 `overhead`. +在准入阶段 RuntimeClass [准入控制器](/zh/docs/reference/access-authn-authz/admission-controllers/) 更新工作负载的 PodSpec 以包含 + RuntimeClass 中定义的 `overhead`. 如果 PodSpec 中该字段已定义，该 Pod 将会被拒绝。 +在这个例子中，由于只指定了 RuntimeClass 名称，所以准入控制器更新了 Pod, 包含了一个 `overhead`. <!-- After the RuntimeClass admission controller, you can check the updated PodSpec: @@ -298,12 +299,8 @@ from source in the meantime. 在 [kube-state-metrics](https://github.com/kubernetes/kube-state-metrics) 中可以通过 `kube_pod_overhead` 指标来协助确定何时使用 PodOverhead 以及协助观察以一个既定开销运行的工作负载的稳定性。 该特性在 kube-state-metrics 的 1.9 发行版本中不可用，不过预计将在后续版本中发布。在此之前，用户需要从源代码构建 kube-state-metrics. - - ## {{% heading "whatsnext" %}} - -* [RuntimeClass](/docs/concepts/containers/runtime-class/) +* [RuntimeClass](/zh/docs/concepts/containers/runtime-class/) * [PodOverhead 设计](https://github.com/kubernetes/enhancements/blob/master/keps/sig-node/20190226-pod-overhead.md) - diff --git a/content/zh/docs/concepts/configuration/resource-bin-packing.md b/content/zh/docs/concepts/configuration/resource-bin-packing.md index b43257f47f..dd4584c989 100644 --- a/content/zh/docs/concepts/configuration/resource-bin-packing.md +++ b/content/zh/docs/concepts/configuration/resource-bin-packing.md @@ -1,22 +1,12 @@ --- -reviewers: -- bsalamat -- k82cn -- ahg-g -title: 扩展资源的资源箱打包 +title: 扩展资源的资源装箱 content_type: concept -weight: 10 +weight: 50 --- <!-- ---- -reviewers: -- bsalamat -- k82cn -- ahg-g title: Resource Bin Packing for Extended Resources content_type: concept -weight: 10 ---- +weight: 50 --> <!-- overview --> @@ -26,46 +16,48 @@ weight: 10 <!-- The kube-scheduler can be configured to enable bin packing of resources along with extended resources using `RequestedToCapacityRatioResourceAllocation` priority function. Priority functions can be used to fine-tune the kube-scheduler as per custom needs. --> -可以将 kube-scheduler 配置为使用 `RequestedToCapacityRatioResourceAllocation` 优先级函数启用资源箱打包以及扩展资源。 + +使用 `RequestedToCapacityRatioResourceAllocation` 优先级函数，可以将 kube-scheduler +配置为支持包含扩展资源在内的资源装箱操作。 优先级函数可用于根据自定义需求微调 kube-scheduler 。 - - <!-- body --> <!-- ## Enabling Bin Packing using RequestedToCapacityRatioResourceAllocation ---> -## 使用 RequestedToCapacityRatioResourceAllocation 启用装箱 -<!-- Before Kubernetes 1.15, Kube-scheduler used to allow scoring nodes based on the request to capacity ratio of primary resources like CPU and Memory. Kubernetes 1.16 added a new parameter to the priority function that allows the users to specify the resources along with weights for each resource to score nodes based on the request to capacity ratio. This allows users to bin pack extended resources by using appropriate parameters improves the utilization of scarce resources in large clusters. The behavior of the `RequestedToCapacityRatioResourceAllocation` priority function can be controlled by a configuration option called `requestedToCapacityRatioArguments`. This argument consists of two parameters `shape` and `resources`. Shape allows the user to tune the function as least requested or most requested based on `utilization` and `score` values. Resources consists of `name` which specifies the resource to be considered during scoring and `weight` specify the weight of each resource. --> -在 Kubernetes 1.15 之前，Kube-scheduler 用于允许根据主要资源，如 CPU 和内存对容量之比的请求对节点进行评分。 -Kubernetes 1.16 在优先级函数中添加了一个新参数，该参数允许用户指定资源以及每个资源的权重，以便根据容量之比的请求为节点评分。 -这允许用户通过使用适当的参数来打包扩展资源，从而提高了大型集群中稀缺资源的利用率。 -`RequestedToCapacityRatioResourceAllocation` 优先级函数的行为可以通过名为 `requestedToCapacityRatioArguments` 的配置选项进行控制。 -这个论证由两个参数 `shape` 和 `resources` 组成。 -Shape 允许用户根据 `utilization` 和 `score` 值将功能调整为要求最少或要求最高的功能。 -资源由 `name` 和 `weight` 组成，`name` 指定评分时要考虑的资源，`weight` 指定每种资源的权重。 + +## 使用 RequestedToCapacityRatioResourceAllocation 启用装箱 + +在 Kubernetes 1.15 之前，Kube-scheduler 通常允许根据对主要资源（如 CPU 和内存）的请求数量和可用容量 +之比率对节点评分。 +Kubernetes 1.16 在优先级函数中添加了一个新参数，该参数允许用户指定资源以及每类资源的权重， +以便根据请求数量与可用容量之比率为节点评分。 +这就使得用户可以通过使用适当的参数来对扩展资源执行装箱操作，从而提高了大型集群中稀缺资源的利用率。 +`RequestedToCapacityRatioResourceAllocation` 优先级函数的行为可以通过名为 +`requestedToCapacityRatioArguments` 的配置选项进行控制。 +该标志由两个参数 `shape` 和 `resources` 组成。 +shape 允许用户根据 `utilization` 和 `score` 值将函数调整为最少请求（least requested）或 +最多请求（most requested）计算。 +resources 由 `name` 和 `weight` 组成，`name` 指定评分时要考虑的资源，`weight` 指定每种资源的权重。 <!-- Below is an example configuration that sets `requestedToCapacityRatioArguments` to bin packing behavior for extended resources `intel.com/foo` and `intel.com/bar` --> -以下是一个配置示例，该配置将 `requestedToCapacityRatioArguments` 设置为扩展资源 `intel.com/foo` 和 `intel.com/bar` 的装箱行为 + +以下是一个配置示例，该配置将 `requestedToCapacityRatioArguments` 设置为对扩展资源 +`intel.com/foo` 和 `intel.com/bar` 的装箱行为 ```json { "kind" : "Policy", "apiVersion" : "v1", - ... - "priorities" : [ - ... - { "name": "RequestedToCapacityRatioPriority", "weight": 2, @@ -89,16 +81,17 @@ Below is an example configuration that sets `requestedToCapacityRatioArguments` <!-- **This feature is disabled by default** --> -**默认情况下禁用此功能** + +**默认情况下此功能处于被禁用状态** <!-- ### Tuning RequestedToCapacityRatioResourceAllocation Priority Function ---> -### 调整 RequestedToCapacityRatioResourceAllocation 优先级函数 -<!-- `shape` is used to specify the behavior of the `RequestedToCapacityRatioPriority` function. --> + +### 调整 RequestedToCapacityRatioResourceAllocation 优先级函数 + `shape` 用于指定 `RequestedToCapacityRatioPriority` 函数的行为。 ```yaml @@ -109,8 +102,9 @@ Below is an example configuration that sets `requestedToCapacityRatioArguments` <!-- The above arguments give the node a score of 0 if utilization is 0% and 10 for utilization 100%, thus enabling bin packing behavior. To enable least requested the score value must be reversed as follows. --> -上面的参数在利用率为 0% 时给节点评分为0，在利用率为 100% 时给节点评分为10，因此启用了装箱行为。 -要启用最少请求，必须按如下方式反转得分值。 + +上面的参数在 utilization 为 0% 时给节点评分为 0，在 utilization 为 100% 时给节点评分为 10， +因此启用了装箱行为。要启用最少请求（least requested）模式，必须按如下方式反转得分值。 ```yaml {"utilization": 0, "score": 100}, @@ -124,9 +118,9 @@ The above arguments give the node a score of 0 if utilization is 0% and 10 for u ``` yaml "resources": [ - {"name": "CPU", "weight": 1}, - {"name": "Memory", "weight": 1} - ] + {"name": "CPU", "weight": 1}, + {"name": "Memory", "weight": 1} +] ``` <!-- @@ -136,66 +130,65 @@ It can be used to add extended resources as follows: ```yaml "resources": [ - {"name": "intel.com/foo", "weight": 5}, - {"name": "CPU", "weight": 3}, - {"name": "Memory", "weight": 1} - ] + {"name": "intel.com/foo", "weight": 5}, + {"name": "CPU", "weight": 3}, + {"name": "Memory", "weight": 1} +] ``` <!-- The weight parameter is optional and is set to 1 if not specified. Also, the weight cannot be set to a negative value. --> -weight 参数是可选的，如果未指定，则设置为1。 -同样， weight 不能设置为负值。 +weight 参数是可选的，如果未指定，则设置为 1。 +同时，weight 不能设置为负值。 <!-- ### How the RequestedToCapacityRatioResourceAllocation Priority Function Scores Nodes ---> -### RequestedToCapacityRatioResourceAllocation 优先级函数如何对节点评分 -<!-- This section is intended for those who want to understand the internal details of this feature. Below is an example of how the node score is calculated for a given set of values. --> -本部分适用于希望了解此功能的内部细节的人员。 -以下是如何针对给定的一组值计算节点得分的示例。 + +### RequestedToCapacityRatioResourceAllocation 优先级函数如何对节点评分 + +本节适用于希望了解此功能的内部细节的人员。 +以下是如何针对给定的一组值来计算节点得分的示例。 ``` -Requested Resources +请求的资源 -intel.com/foo : 2 +intel.com/foo: 2 Memory: 256MB CPU: 2 -Resource Weights +资源权重 -intel.com/foo : 5 +intel.com/foo: 5 Memory: 1 CPU: 3 FunctionShapePoint {{0, 0}, {100, 10}} -Node 1 Spec +节点 Node 1 配置 -Available: -intel.com/foo : 4 -Memory : 1 GB -CPU: 8 +可用： + intel.com/foo : 4 + Memory : 1 GB + CPU: 8 -Used: -intel.com/foo: 1 -Memory: 256MB -CPU: 1 +已用： + intel.com/foo: 1 + Memory: 256MB + CPU: 1 - -Node Score: +节点得分： intel.com/foo = resourceScoringFunction((2+1),4) - = (100 - ((4-3)*100/4) - = (100 - 25) - = 75 - = rawScoringFunction(75) + = (100 - ((4-3)*100/4) + = (100 - 25) + = 75 + = rawScoringFunction(75) = 7 Memory = resourceScoringFunction((256+256),1024) @@ -214,27 +207,25 @@ NodeScore = (7 * 5) + (5 * 1) + (3 * 3) / (5 + 1 + 3) = 5 -Node 2 Spec +节点 Node 2 配置 -Available: -intel.com/foo: 8 -Memory: 1GB -CPU: 8 +可用： + intel.com/foo: 8 + Memory: 1GB + CPU: 8 -Used: +已用： + intel.com/foo: 2 + Memory: 512MB + CPU: 6 -intel.com/foo: 2 -Memory: 512MB -CPU: 6 - - -Node Score: +节点得分： intel.com/foo = resourceScoringFunction((2+2),8) - = (100 - ((8-4)*100/8) - = (100 - 25) - = 50 - = rawScoringFunction(50) + = (100 - ((8-4)*100/8) + = (100 - 25) + = 50 + = rawScoringFunction(50) = 5 Memory = resourceScoringFunction((256+512),1024) @@ -251,8 +242,5 @@ CPU = resourceScoringFunction((2+6),8) NodeScore = (5 * 5) + (7 * 1) + (10 * 3) / (5 + 1 + 3) = 7 - ``` - - diff --git a/content/zh/docs/concepts/configuration/secret.md b/content/zh/docs/concepts/configuration/secret.md index 4556f72dcd..47b0e983ff 100644 --- a/content/zh/docs/concepts/configuration/secret.md +++ b/content/zh/docs/concepts/configuration/secret.md @@ -1,9 +1,24 @@ --- title: Secret content_type: concept -weight: 50 +feature: + title: Secret 和配置管理 + description: > + 部署和更新 Secrets 和应用程序的配置而不必重新构建容器镜像，且 + 不必将软件堆栈配置中的秘密信息暴露出来。 +weight: 30 --- - +<!-- +reviewers: +- mikedanese +title: Secrets +content_type: concept +feature: + title: Secret and configuration management + description: > + Deploy and update secrets and application configuration without rebuilding your image and without exposing secrets in your stack configuration. +weight: 30 +--> <!-- overview --> @@ -14,12 +29,10 @@ is safer and more flexible than putting it verbatim in a {{< glossary_tooltip term_id="pod" >}} definition or in a {{< glossary_tooltip text="container image" term_id="image" >}}. See [Secrets design document](https://git.k8s.io/community/contributors/design-proposals/auth/secrets.md) for more information. --> -`Secret` 对象类型用来保存敏感信息，例如密码、OAuth 令牌和 ssh key。 +`Secret` 对象类型用来保存敏感信息，例如密码、OAuth 令牌和 SSH 密钥。 将这些信息放在 `secret` 中比放在 {{< glossary_tooltip term_id="pod" >}} 的定义或者 {{< glossary_tooltip text="容器镜像" term_id="image" >}} 中来说更加安全和灵活。 参阅 [Secret 设计文档](https://git.k8s.io/community/contributors/design-proposals/auth/secrets.md) 获取更多详细信息。 - - <!-- body --> <!-- @@ -27,26 +40,33 @@ is safer and more flexible than putting it verbatim in a A Secret is an object that contains a small amount of sensitive data such as a password, a token, or a key. Such information might otherwise be put in a -Pod specification or in an image; putting it in a Secret object allows for -more control over how it is used, and reduces the risk of accidental exposure. ---> +Pod specification or in an image. Users can create secrets and the system +also creates some secrets. +--> ## Secret 概览 -Secret 是一种包含少量敏感信息例如密码、token 或 key 的对象。这样的信息可能会被放在 Pod spec 中或者镜像中；将其放在一个 secret 对象中可以更好地控制它的用途，并降低意外暴露的风险。 +Secret 是一种包含少量敏感信息例如密码、令牌或密钥的对象。 +这样的信息可能会被放在 Pod 规约中或者镜像中。 +用户可以创建 Secret，同时系统也创建了一些 Secret。 <!-- -Users can create secrets, and the system also creates some secrets. +To use a secret, a Pod needs to reference the secret. +A secret can be used with a Pod in three ways: -To use a secret, a pod needs to reference the secret. -A secret can be used with a pod in two ways: as files in a +- As [files](#using-secrets-as-files-from-a-pod) in a {{< glossary_tooltip text="volume" term_id="volume" >}} mounted on one or more of -its containers, or used by kubelet when pulling images for the pod. +its containers. +- As [container environment variable](#using-secrets-as-environment-variables). +- By the [kubelet when pulling images](#using-imagepullsecrets) for the Pod. --> +要使用 Secret，Pod 需要引用 Secret。 +Pod 可以用三种方式之一来使用 Secret： -用户可以创建 secret，同时系统也创建了一些 secret。 - -要使用 secret，pod 需要引用 secret。Pod 可以用两种方式使用 secret：作为 {{< glossary_tooltip text="volume" term_id="volume" >}} 中的文件被挂载到 pod 中的一个或者多个容器里，或者当 kubelet 为 pod 拉取镜像时使用。 +- 作为挂载到一个或多个容器上的 {{< glossary_tooltip text="卷" term_id="volume" >}} + 中的[文件](#using-secrets-as-files-from-a-pod)。 +- 作为[容器的环境变量](#using-secrets-as-environment-variables) +- 由 [kubelet 在为 Pod 拉取镜像时使用](#using-imagepullsecrets) <!-- ### Built-in Secrets @@ -57,93 +77,136 @@ Kubernetes automatically creates secrets which contain credentials for accessing the API and it automatically modifies your pods to use this type of secret. --> +### 内置 Secret -### 内置 secret +#### 服务账号使用 API 凭证自动创建和附加 Secret -#### Service Account 使用 API 凭证自动创建和附加 secret - -Kubernetes 自动创建包含访问 API 凭据的 secret，并自动修改您的 pod 以使用此类型的 secret。 +Kubernetes 自动创建包含访问 API 凭据的 Secret，并自动修改你的 Pod 以使用此类型的 Secret。 <!-- The automatic creation and use of API credentials can be disabled or overridden -if desired. However, if all you need to do is securely access the apiserver, +if desired. However, if all you need to do is securely access the API server, this is the recommended workflow. -See the [Service Account](/docs/tasks/configure-pod-container/configure-service-account/) documentation for more -information on how Service Accounts work. +See the [Service Account](/docs/tasks/configure-pod-container/configure-service-account/) +documentation for more information on how Service Accounts work. --> +如果需要，可以禁用或覆盖自动创建和使用 API 凭据。 +但是，如果您需要的只是安全地访问 API 服务器，我们推荐这样的工作流程。 -如果需要，可以禁用或覆盖自动创建和使用 API 凭据。但是，如果您需要的只是安全地访问 apiserver，我们推荐这样的工作流程。 - -参阅 [Service Account](/docs/tasks/configure-pod-container/configure-service-account/) 文档获取关于 Service Account 如何工作的更多信息。 +参阅[服务账号](/zh/docs/tasks/configure-pod-container/configure-service-account/) +文档了解关于服务账号如何工作的更多信息。 <!-- ### Creating your own Secrets #### Creating a Secret Using kubectl create secret -Say that some pods need to access a database. The -username and password that the pods should use is in the files -`./username.txt` and `./password.txt` on your local machine. +Secrets can contain user credentials required by Pods to access a database. +For example, a database connection string +consists of a username and password. You can store the username in a file `./username.txt` +and the password in a file `./password.txt` on your local machine. --> ### 创建您自己的 Secret -#### 使用 kubectl 创建 Secret +#### 使用 `kubectl` 创建 Secret -假设有些 pod 需要访问数据库。这些 pod 需要使用的用户名和密码在您本地机器的 `./username.txt` 和 `./password.txt` 文件里。 +Secret 中可以包含 Pod 访问数据库时需要的用户凭证信息。 +例如，某个数据库连接字符串可能包含用户名和密码。 +你可以将用户名和密码保存在本地机器的 `./username.txt` 和 `./password.txt` 文件里。 ```shell -# Create files needed for rest of example. +# 创建本例中要使用的文件 echo -n 'admin' > ./username.txt echo -n '1f2d1e2e67df' > ./password.txt ``` <!-- -The `kubectl create secret` command -packages these files into a Secret and creates -the object on the Apiserver. +The `kubectl create secret` command packages these files into a Secret and creates +the object on the API Server. +The name of a Secret object must be a valid +[DNS subdomain name](/docs/concepts/overview/working-with-objects/names#dns-subdomain-names). --> `kubectl create secret` 命令将这些文件打包到一个 Secret 中并在 API server 中创建了一个对象。 - +Secret 对象的名称必须是合法的 [DNS 子域名](/zh/docs/concepts/overview/working-with-objects/names#dns-subdomain-names)。 ```shell kubectl create secret generic db-user-pass --from-file=./username.txt --from-file=./password.txt ``` + +输出类似于： + ``` secret "db-user-pass" created ``` -{{< note >}} <!-- -Special characters such as `$`, `\*`, and `!` require escaping. -If the password you are using has special characters, you need to escape them using the `\\` character. For example, if your actual password is `S!B\*d$zDsb`, you should execute the command this way: - kubectl create secret generic dev-db-secret --from-literal=username=devuser --from-literal=password=S\\!B\\\\*d\\$zDsb - You do not need to escape special characters in passwords from files (`--from-file`). +Default key name is the filename. You may optionally set the key name using `[--from-file=[key=]source]`. +--> +默认的键名是文件名。你也可以使用 `[--from-file=[key=]source]` 参数来设置键名。 + +```shell +kubectl create secret generic db-user-pass \ + --from-file=username=./username.txt \ + --from-file=password=./password.txt +``` + +<!-- +Special characters such as `$`, `\`, `*`, `=`, and `!` will be interpreted by your [shell](https://en.wikipedia.org/wiki/Shell_(computing)) and require escaping. +In most shells, the easiest way to escape the password is to surround it with single quotes (`'`). +For example, if your actual password is `S!B\*d$zDsb=`, you should execute the command this way: + +``` +kubectl create secret generic dev-db-secret \ + --from-literal=username=devuser \ + --from-literal=password='S!B\*d$zDsb=' +``` + +You do not need to escape special characters in passwords from files (`--from-file`). --> +{{< note >}} +特殊字符（例如 `$`、`*`、`*`、`=` 和 `!`）可能会被你的 +[Shell](https://en.wikipedia.org/wiki/Shell_(computing)) 解析，因此需要转义。 +在大多数 Shell 中，对密码进行转义的最简单方式是使用单引号（`'`）将其扩起来。 +例如，如果您的实际密码是 `S!B\*d$zDsb=` ，则应通过以下方式执行命令： +``` +kubectl create secret generic dev-db-secret \ + --from-literal=username=devuser \ + --from-literal=password='S!B\*d$zDsb=' +``` -特殊字符（例如 `$`, `\*` 和 `!` ）需要转义。 -如果您使用的密码具有特殊字符，则需要使用 `\\` 字符对其进行转义。 例如，如果您的实际密码是 `S!B\*d$zDsb` ，则应通过以下方式执行命令： - kubectl create secret generic dev-db-secret --from-literal=username=devuser --from-literal=password=S\\!B\\\\*d\\$zDsb -您无需从文件中转义密码中的特殊字符（ `--from-file` ）。 +您无需对文件中保存（`--from-file`）的密码中的特殊字符执行转义操作。 {{< /note >}} <!-- You can check that the secret was created like this: --> -您可以这样检查刚创建的 secret： +您可以这样检查刚创建的 Secret： ```shell kubectl get secrets ``` + +其输出类似于： + ``` NAME TYPE DATA AGE db-user-pass Opaque 2 51s ``` + +<!-- +You can view a description of the secret: +--> +你可以查看 Secret 的描述： + ```shell kubectl describe secrets/db-user-pass ``` + +其输出类似于： + ``` Name: db-user-pass Namespace: default @@ -158,53 +221,69 @@ password.txt: 12 bytes username.txt: 5 bytes ``` -{{< note >}} - <!-- `kubectl get` and `kubectl describe` avoid showing the contents of a secret by default. This is to protect the secret from being exposed accidentally to an onlooker, or from being stored in a terminal log. --> - +{{< note >}} +默认情况下，`kubectl get` 和 `kubectl describe` 避免显示密码的内容。 +这是为了防止机密被意外地暴露给旁观者或存储在终端日志中。 {{< /note >}} -默认情况下，`kubectl get` 和 `kubectl describe` 避免显示密码的内容。 这是为了防止机密被意外地暴露给旁观者或存储在终端日志中。 - <!-- -See [decoding a secret](#decoding-a-secret) for how to see the contents of a secret. +See [decoding secret](#decoding-secret) for how to see the contents of a secret. --> - -请参阅 [解码 secret](#解码-secret) 了解如何查看它们的内容。 +请参阅[解码 Secret](#decoding-secret) 了解如何查看 Secret 的内容。 <!-- #### Creating a Secret Manually -You can also create a Secret in a file first, in json or yaml format, -and then create that object. The -[Secret](/docs/reference/generated/kubernetes-api/v1.12/#secret-v1-core) contains two maps: -data and stringData. The data field is used to store arbitrary data, encoded using +You can also create a Secret in a file first, in JSON or YAML format, +and then create that object. +The name of a Secret object must be a valid +[DNS subdomain name](/docs/concepts/overview/working-with-objects/names#dns-subdomain-names). +The [Secret](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#secret-v1-core) +contains two maps: +`data` and `stringData`. The `data` field is used to store arbitrary data, encoded using base64. The stringData field is provided for convenience, and allows you to provide secret data as unencoded strings. --> - #### 手动创建 Secret -您也可以先以 json 或 yaml 格式在文件中创建一个 secret 对象，然后创建该对象。 -[密码](/docs/reference/generated/kubernetes-api/v1.12/#secret-v1-core)包含两种类型，数据和字符串数据。 -数据字段用于存储使用 base64 编码的任意数据。 提供 stringData 字段是为了方便起见，它允许您将机密数据作为未编码的字符串提供。 +您也可以先以 JSON 或 YAML 格式文件创建一个 Secret，然后创建该对象。 +Secret 对象的名称必须是合法的 [DNS 子域名](/zh/docs/concepts/overview/working-with-objects/names#dns-subdomain-names)。 +[Secret](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#secret-v1-core) +包含两个映射：`data` 和 `stringData`。 +`data` 字段用于存储使用 base64 编码的任意数据。 +提供 `stringData` 字段是为了方便，允许您用未编码的字符串提供机密数据。 <!-- For example, to store two strings in a Secret using the data field, convert them to base64 as follows: --> - -例如，要使用数据字段将两个字符串存储在 Secret 中，请按如下所示将它们转换为 base64： +例如，要使用 `data` 字段将两个字符串存储在 Secret 中，请按如下所示将它们转换为 base64： ```shell echo -n 'admin' | base64 +``` + +<!-- The output is similar to: --> +输出类似于： + +``` YWRtaW4= +``` + +```shell echo -n '1f2d1e2e67df' | base64 +``` + +<!-- The output is similar to: --> +输出类似于： + +``` MWYyZDFlMmU2N2Rm ``` @@ -212,7 +291,7 @@ MWYyZDFlMmU2N2Rm Write a Secret that looks like this: --> -现在可以像这样写一个 secret 对象： +现在可以像这样写一个 Secret 对象： ```yaml apiVersion: v1 @@ -228,12 +307,15 @@ data: <!-- Now create the Secret using [`kubectl apply`](/docs/reference/generated/kubectl/kubectl-commands#apply): --> - -使用 [`kubectl apply`](/docs/reference/generated/kubectl/kubectl-commands#apply) 创建 secret： +使用 [`kubectl apply`](/docs/reference/generated/kubectl/kubectl-commands#apply) 创建 Secret 对象： ```shell kubectl apply -f ./secret.yaml ``` + +<!--The output is similar to: --> +输出类似于： + ``` secret "mysecret" created ``` @@ -249,11 +331,12 @@ parts of that configuration file during your deployment process. If your application uses the following configuration file: --> - -对于某些情况，您可能希望改用 stringData 字段。此字段允许您将非 base64 编码的字符串直接放入 Secret 中， +在某些情况下，你可能希望改用 stringData 字段。 +此字段允许您将非 base64 编码的字符串直接放入 Secret 中， 并且在创建或更新 Secret 时将为您编码该字符串。 -下面的一个实践示例提供了一个参考，您正在部署使用密钥存储配置文件的应用程序，并希望在部署过程中填补齐配置文件的部分内容。 +下面的一个实践示例提供了一个参考。 +你正在部署使用 Secret 存储配置文件的应用程序，并希望在部署过程中填齐配置文件的部分内容。 如果您的应用程序使用以下配置文件： @@ -263,9 +346,7 @@ username: "user" password: "password" ``` -<!-- -You could store this in a Secret using the following: ---> +<!-- You could store this in a Secret using the following: --> 您可以使用以下方法将其存储在Secret中： @@ -293,6 +374,7 @@ retrieving Secrets. For example, if you run the following command: 然后，您的部署工具可以在执行 `kubectl apply` 之前替换模板的 `{{username}}` 和 `{{password}}` 变量。 stringData 是只写的便利字段。检索 Secrets 时永远不会被输出。例如，如果您运行以下命令： + ```shell kubectl get secret mysecret -o yaml ``` @@ -300,8 +382,7 @@ kubectl get secret mysecret -o yaml <!-- The output will be similar to: --> - -输出将类似于： +输出类似于： ```yaml apiVersion: v1 @@ -322,7 +403,8 @@ If a field is specified in both data and stringData, the value from stringData is used. For example, the following Secret definition: --> -如果在 data 和 stringData 中都指定了字段，则使用 stringData 中的值。例如，以下是 Secret 定义： +如果在 data 和 stringData 中都指定了某一字段，则使用 stringData 中的值。 +例如，以下是 Secret 定义： ```yaml apiVersion: v1 @@ -339,7 +421,6 @@ stringData: <!-- Results in the following secret: --> - secret 中的生成结果： ```yaml @@ -359,45 +440,56 @@ data: <!-- Where `YWRtaW5pc3RyYXRvcg==` decodes to `administrator`. --> - -`YWRtaW5pc3RyYXRvcg==` 转换成了 `administrator`。 +其中的 `YWRtaW5pc3RyYXRvcg==` 解码后即是 `administrator`。 <!-- The keys of data and stringData must consist of alphanumeric characters, '-', '_' or '.'. -**Encoding Note:** The serialized JSON and YAML values of secret data are +The serialized JSON and YAML values of secret data are encoded as base64 strings. Newlines are not valid within these strings and must be omitted. When using the `base64` utility on Darwin/macOS users should avoid using the `-b` option to split long lines. Conversely Linux users *should* add the option `-w 0` to `base64` commands or the pipeline `base64 | tr -d '\n'` if `-w` option is not available. --> +data 和 stringData 的键必须由字母数字字符 '-', '\_' 或者 '.' 组成。 -data 和 stringData 的键必须由字母数字字符 '-', '_' 或者 '.' 组成。 - -** 编码注意：** 秘密数据的序列化 JSON 和 YAML 值被编码为 base64 字符串。换行符在这些字符串中无效，因此必须省略。在 Darwin/macOS 上使用 `base64` 实用程序时，用户应避免使用 `-b` 选项来分隔长行。相反，Linux用户 *应该* 在 `base64` 命令中添加选项 `-w 0` ，或者，如果 `-w` 选项不可用的情况下，执行 `base64 | tr -d '\n'`。 +{{< note >}} +Secret 数据在序列化为 JSON 和 YAML 时，其值被编码为 base64 字符串。 +换行符在这些字符串中是非法的，因此必须省略。 +在 Darwin/macOS 上使用 `base64` 实用程序时，用户应避免使用 `-b` 选项来分隔长行。 +相反，Linux用户 *应该* 在 `base64` 命令中添加选项 `-w 0` ， +或者，如果 `-w` 选项不可用的情况下，执行 `base64 | tr -d '\n'`。 +{{< /note >}} <!-- #### Creating a Secret from Generator -Kubectl supports [managing objects using Kustomize](/docs/tasks/manage-kubernetes-objects/kustomization/) -since 1.14. With this new feature, -you can also create a Secret from generators and then apply it to create the object on -the Apiserver. The generators -should be specified in a `kustomization.yaml` inside a directory. -For example, to generate a Secret from files `./username.txt` and `./password.txt` +Since Kubernetes v1.14, `kubectl` supports [managing objects using Kustomize](/docs/tasks/manage-kubernetes-objects/kustomization/). Kustomize provides resource Generators to +create Secrets and ConfigMaps. The Kustomize generators should be specified in a +`kustomization.yaml` file inside a directory. After generating the Secret, +you can create the Secret on the API server with `kubectl apply`. --> - #### 从生成器创建 Secret -Kubectl 从 1.14 版本开始支持 [使用 Kustomize 管理对象](/docs/tasks/manage-kubernetes-objects/kustomization/) -使用此新功能，您还可以从生成器创建一个 Secret，然后将其应用于在 Apiserver 上创建对象。 -生成器应在目录内的 `kustomization.yaml` 中指定。 -例如，从文件 `./username.txt` 和 `./password.txt` 生成一个 Secret。 +Kubectl 从 1.14 版本开始支持[使用 Kustomize 管理对象](/zh/docs/tasks/manage-kubernetes-objects/kustomization/)。 +Kustomize 提供资源生成器创建 Secret 和 ConfigMaps。 +Kustomize 生成器要在当前目录内的 `kustomization.yaml` 中指定。 +生成 Secret 之后，使用 `kubectl apply` 在 API 服务器上创建对象。 + +<!-- +#### Generating a Secret from files + +You can generate a Secret by defining a `secretGenerator` from the +files ./username.txt and ./password.txt: +--> +#### 从文件生成 Secret {#generating-a-secret-from-files} + +你可以通过定义基于文件 `./username.txt` 和 `./password.txt` 的 +`secretGenerator` 来生成一个 Secret。 ```shell -# Create a kustomization.yaml file with SecretGenerator cat <<EOF >./kustomization.yaml secretGenerator: - name: db-user-pass @@ -408,24 +500,34 @@ EOF ``` <!-- -Apply the kustomization directory to create the Secret object. +Apply the directory, containing the `kustomization.yaml`, to create the Secret. --> - -应用 kustomization 目录创建 Secret 对象。 +应用包含 `kustomization.yaml` 目录以创建 Secret 对象。 ```shell -$ kubectl apply -k . +kubectl apply -k . +``` + +<!-- The output is similar to: --> +输出类似于： + +``` secret/db-user-pass-96mffmfh4k created ``` <!-- You can check that the secret was created like this: --> - -您可以检查 secret 是否是这样创建的： +您可以检查 Secret 是否创建成功： ```shell -$ kubectl get secrets +kubectl get secrets +``` + +<!-- The output is similar to: --> +输出类似于： + +``` NAME TYPE DATA AGE db-user-pass-96mffmfh4k Opaque 2 51s @@ -444,15 +546,18 @@ username.txt: 5 bytes ``` <!-- -For example, to generate a Secret from literals `username=admin` and `password=secret`, -you can specify the secret generator in `kustomization.yaml` as ---> +#### Generating a Secret from string literals -例如，要从文字 `username=admin` 和 `password=secret` 生成秘密，可以在 `kustomization.yaml` 中将秘密生成器指定为 +You can create a Secret by defining a `secretGenerator` +from literals `username=admin` and `password=secret`: +--> +#### 基于字符串值来创建 Secret {#generating-a-secret-from-string-literals} + +你可以通过定义使用字符串值 `username=admin` 和 `password=secret` +的 `secretGenerator` 来创建 Secret。 ```shell -# Create a kustomization.yaml file with SecretGenerator -$ cat <<EOF >./kustomization.yaml +cat <<EOF >./kustomization.yaml secretGenerator: - name: db-user-pass literals: @@ -460,36 +565,57 @@ secretGenerator: - password=secret EOF ``` -Apply the kustomization directory to create the Secret object. +<!-- +Apply the directory, containing the `kustomization.yaml`, to create the Secret. +--> +应用包含 `kustomization.yaml` 目录以创建 Secret 对象。 + ```shell -$ kubectl apply -k . -secret/db-user-pass-dddghtt9b5 created +kubectl apply -k . ``` -{{< note >}} <!-- -The generated Secrets name has a suffix appended by hashing the contents. This ensures that a new -Secret is generated each time the contents is modified. +The output is similar to: +--> +输出类似于： + +``` +secret/db-user-pass-dddghtt9b5 created +``` + +<!-- +When a Secret is generated, the Secret name is created by hashing +the Secret data and appending this value to the name. This ensures that +a new Secret is generated each time the data is modified. --> -通过对内容进行序列化后，生成一个后缀作为 Secrets 的名称。这样可以确保每次修改内容时都会生成一个新的 Secret。 - +{{< note >}} +Secret 被创建时，Secret 的名称是通过为 Secret 数据计算哈希值得到一个字符串， +并将该字符串添加到名称之后得到的。这会确保数据被修改后，会有新的 Secret +对象被生成。 {{< /note >}} <!-- #### Decoding a Secret -Secrets can be retrieved via the `kubectl get secret` command. For example, to retrieve the secret created in the previous section: +Secrets can be retrieved via the `kubectl get secret`. +For example, to retrieve the secret created in the previous section: --> -#### 解码 Secret +#### 解码 Secret {#decoding-secret} -可以使用 `kubectl get secret` 命令获取 secret。例如，获取在上一节中创建的 secret： +可以使用 `kubectl get secret` 命令获取 Secret。例如，获取在上一节中创建的 secret： ```shell kubectl get secret mysecret -o yaml ``` -``` + +<!-- +The output is similar to: +--> +输出类似于： + +```yaml apiVersion: v1 kind: Secret metadata: @@ -508,11 +634,15 @@ data: Decode the password field: --> -解码密码字段： +解码 `password` 字段： ```shell echo 'MWYyZDFlMmU2N2Rm' | base64 --decode ``` + +<!-- The output is similar to:--> +输出类似于： + ``` 1f2d1e2e67df ``` @@ -522,10 +652,9 @@ echo 'MWYyZDFlMmU2N2Rm' | base64 --decode An existing secret may be edited with the following command: --> - #### 编辑 Secret -可以通过下面的命令编辑一个已经存在的 secret 。 +可以通过下面的命令可以编辑一个已经存在的 secret 。 ```shell kubectl edit secrets mysecret @@ -534,8 +663,7 @@ kubectl edit secrets mysecret <!-- This will open the default configured editor and allow for updating the base64 encoded secret values in the `data` field: --> - -这将打开默认配置的编辑器，并允许更新 `data` 字段中的 base64 编码的 secret： +这将打开默认配置的编辑器，并允许更新 `data` 字段中的 base64 编码的 Secret 值： ``` # Please edit the object below. Lines beginning with a '#' will be ignored, @@ -572,8 +700,8 @@ systems on your behalf. ## 使用 Secret Secret 可以作为数据卷被挂载，或作为{{< glossary_tooltip text="环境变量" term_id="container-env-variables" >}} -暴露出来以供 pod 中的容器使用。它们也可以被系统的其他部分使用，而不直接暴露在 pod 内。 -例如，它们可以保存凭据，系统的其他部分应该用它来代表您与外部系统进行交互。 +暴露出来以供 Pod 中的容器使用。它们也可以被系统的其他部分使用，而不直接暴露在 Pod 内。 +例如，它们可以保存凭据，系统的其他部分将用它来代表你与外部系统进行交互。 <!-- ### Using Secrets as Files from a Pod @@ -588,16 +716,20 @@ To consume a Secret in a volume in a Pod: This is an example of a pod that mounts a secret in a volume: --> -### 在 Pod 中使用 Secret 文件 +### 在 Pod 中使用 Secret 文件 {#using-secrets-as-files-from-a-pod} -在 Pod 中的 volume 里使用 Secret： +在 Pod 中使用存放在卷中的 Secret： -1. 创建一个 secret 或者使用已有的 secret。多个 pod 可以引用同一个 secret。 -1. 修改您的 pod 的定义在 `spec.volumes[]` 下增加一个 volume。可以给这个 volume 随意命名，它的 `spec.volumes[].secret.secretName` 必须等于 secret 对象的名字。 -1. 将 `spec.containers[].volumeMounts[]` 加到需要用到该 secret 的容器中。指定 `spec.containers[].volumeMounts[].readOnly = true` 和 `spec.containers[].volumeMounts[].mountPath` 为您想要该 secret 出现的尚未使用的目录。 -1. 修改您的镜像并且／或者命令行让程序从该目录下寻找文件。Secret 的 `data` 映射中的每一个键都成为了 `mountPath` 下的一个文件名。 +1. 创建一个 Secret 或者使用已有的 Secret。多个 Pod 可以引用同一个 Secret。 +1. 修改你的 Pod 定义，在 `spec.volumes[]` 下增加一个卷。可以给这个卷随意命名， + 它的 `spec.volumes[].secret.secretName` 必须是 Secret 对象的名字。 +1. 将 `spec.containers[].volumeMounts[]` 加到需要用到该 Secret 的容器中。 + 指定 `spec.containers[].volumeMounts[].readOnly = true` 和 + `spec.containers[].volumeMounts[].mountPath` 为你想要该 Secret 出现的尚未使用的目录。 +1. 修改你的镜像并且／或者命令行，让程序从该目录下寻找文件。 + Secret 的 `data` 映射中的每一个键都对应 `mountPath` 下的一个文件名。 -这是一个在 pod 中使用 volume 挂在 secret 的例子： +这是一个在 Pod 中使用存放在挂载卷中 Secret 的例子： ```yaml apiVersion: v1 @@ -626,21 +758,22 @@ own `volumeMounts` block, but only one `.spec.volumes` is needed per secret. You can package many files into one secret, or use many secrets, whichever is convenient. -**Projection of secret keys to specific paths** +#### Projection of Secret keys to specific paths We can also control the paths within the volume where Secret keys are projected. You can use `.spec.volumes[].secret.items` field to change target path of each key: --> +您想要用的每个 Secret 都需要在 `spec.volumes` 中引用。 -您想要用的每个 secret 都需要在 `spec.volumes` 中指明。 +如果 Pod 中有多个容器，每个容器都需要自己的 `volumeMounts` 配置块， +但是每个 Secret 只需要一个 `spec.volumes`。 -如果 pod 中有多个容器，每个容器都需要自己的 `volumeMounts` 配置块，但是每个 secret 只需要一个 `spec.volumes`。 +您可以打包多个文件到一个 Secret 中，或者使用的多个 Secret，怎样方便就怎样来。 -您可以打包多个文件到一个 secret 中，或者使用的多个 secret，怎样方便就怎样来。 +#### 将 Secret 键名映射到特定路径 -**向特性路径映射 secret 密钥** - -我们还可以控制 Secret key 映射在 volume 中的路径。您可以使用 `spec.volumes[].secret.items` 字段修改每个 key 的目标路径： +我们还可以控制 Secret 键名在存储卷中映射的的路径。 +你可以使用 `spec.volumes[].secret.items` 字段修改每个键对应的目标路径： ```yaml apiVersion: v1 @@ -674,7 +807,7 @@ If `.spec.volumes[].secret.items` is used, only keys specified in `items` are pr To consume all keys from the secret, all of them must be listed in the `items` field. All listed keys must exist in the corresponding secret. Otherwise, the volume is not created. -**Secret files permissions** +#### Secret files permissions You can also specify the permission mode bits files part of a secret will have. If you don't specify any, `0644` is used by default. You can specify a default @@ -682,17 +815,19 @@ mode for the whole secret volume and override per key if needed. For example, you can specify a default mode like this: --> - 将会发生什么呢： -- `username` secret 存储在 `/etc/foo/my-group/my-username` 文件中而不是 `/etc/foo/username` 中。 -- `password` secret 没有被映射 +- `username` Secret 存储在 `/etc/foo/my-group/my-username` 文件中而不是 `/etc/foo/username` 中。 +- `password` Secret 没有被映射 -如果使用了 `spec.volumes[].secret.items`，只有在 `items` 中指定的 key 被映射。要使用 secret 中所有的 key，所有这些都必须列在 `items` 字段中。所有列出的密钥必须存在于相应的 secret 中。否则，不会创建卷。 +如果使用了 `spec.volumes[].secret.items`，只有在 `items` 中指定的键会被映射。 +要使用 Secret 中所有键，就必须将它们都列在 `items` 字段中。 +所有列出的键名必须存在于相应的 Secret 中。否则，不会创建卷。 -**Secret 文件权限** +#### Secret 文件权限 -您还可以指定 secret 将拥有的权限模式位文件。如果不指定，默认使用 `0644`。您可以为整个保密卷指定默认模式，如果需要，可以覆盖每个密钥。 +你还可以指定 Secret 将拥有的权限模式位。如果不指定，默认使用 `0644`。 +你可以为整个 Secret 卷指定默认模式；如果需要，可以为每个密钥设定重载值。 例如，您可以指定如下默认模式： @@ -722,16 +857,67 @@ secret volume mount will have permission `0400`. Note that the JSON spec doesn't support octal notation, so use the value 256 for 0400 permissions. If you use yaml instead of json for the pod, you can use octal notation to specify permissions in a more natural way. +--> +之后，Secret 将被挂载到 `/etc/foo` 目录，而所有通过该 Secret 卷挂载 +所创建的文件的权限都是 `0400`。 +请注意，JSON 规范不支持八进制符号，因此使用 256 值作为 0400 权限。 +如果你使用 YAML 而不是 JSON，则可以使用八进制符号以更自然的方式指定权限。 + +<!-- +Note if you `kubectl exec` into the Pod, you need to follow the symlink to find +the expected file mode. For example, + +Check the secrets file mode on the pod. +--> +注意，如果你通过 `kubectl exec` 进入到 Pod 中，你需要沿着符号链接来找到 +所期望的文件模式。例如，下面命令检查 Secret 文件的访问模式： + +```shell +kubectl exec mypod -it sh + +cd /etc/foo +ls -l +``` + +<!-- +The output is similar to this: +--> +输出类似于： + +``` +total 0 +lrwxrwxrwx 1 root root 15 May 18 00:18 password -> ..data/password +lrwxrwxrwx 1 root root 15 May 18 00:18 username -> ..data/username +``` + +<!-- +Follow the symlink to find the correct file mode. +--> +沿着符号链接，可以查看文件的访问模式： + +```shell +cd /etc/foo/..data +ls -l +``` + +<!-- +The output is similar to this: +--> +输出类似于： + +``` +total 8 +-r-------- 1 root root 12 May 18 00:18 password +-r-------- 1 root root 5 May 18 00:18 username +``` + +<!-- You can also use mapping, as in the previous example, and specify different permission for different files like this: --> -然后，secret 将被挂载到 `/etc/foo` 目录，所有通过该 secret volume 挂载创建的文件的权限都是 `0400`。 - -请注意，JSON 规范不支持八进制符号，因此使用 256 值作为 0400 权限。如果您使用 yaml 而不是 json 作为 pod，则可以使用八进制符号以更自然的方式指定权限。 - -您还可以使用映射，如上一个示例，并为不同的文件指定不同的权限，如下所示： +你还可以使用映射，如上一个示例，并为不同的文件指定不同的权限，如下所示： ```yaml apiVersion: v1 @@ -758,30 +944,36 @@ spec: <!-- In this case, the file resulting in `/etc/foo/my-group/my-username` will have permission value of `0777`. Owing to JSON limitations, you must specify the mode -in decimal notation. +in decimal notation, `511`. Note that this permission value might be displayed in decimal notation if you read it later. -**Consuming Secret Values from Volumes** +#### Consuming Secret Values from Volumes Inside the container that mounts a secret volume, the secret keys appear as files and the secret values are base-64 decoded and stored inside these files. This is the result of commands executed inside the container from the example above: --> +在这里，位于 `/etc/foo/my-group/my-username` 的文件的权限值为 `0777`。 +由于 JSON 限制，必须以十进制格式指定模式，即 `511`。 -在这种情况下，导致 `/etc/foo/my-group/my-username` 的文件的权限值为 `0777`。由于 JSON 限制，必须以十进制格式指定模式。 +请注意，如果稍后读取此权限值，可能会以十进制格式显示。 -请注意，如果稍后阅读此权限值可能会以十进制格式显示。 +#### 使用来自卷中的 Secret 值 {#consuming-secret-values-from-volumes} -**从 Volume 中消费 secret 值** - -在挂载的 secret volume 的容器内，secret key 将作为文件，并且 secret 的值使用 base-64 解码并存储在这些文件中。这是在上面的示例容器内执行的命令的结果： +在挂载了 Secret 卷的容器内，Secret 键名显示为文件名，并且 Secret 的值 +使用 base-64 解码后存储在这些文件中。 +这是在上面的示例容器内执行的命令的结果： ```shell ls /etc/foo/ ``` + +<!-- The output is similar to: --> +输出类似于： + ``` username password @@ -790,14 +982,21 @@ password ```shell cat /etc/foo/username ``` + +<!-- The output is similar to: --> +输出类似于： + ``` admin ``` - ```shell cat /etc/foo/password ``` + +<!-- The output is similar to: --> +输出类似于： + ``` 1f2d1e2e67df ``` @@ -805,15 +1004,12 @@ cat /etc/foo/password <!-- The program in a container is responsible for reading the secrets from the files. - -**Mounted Secrets are updated automatically** --> - 容器中的程序负责从文件中读取 secret。 -**挂载的 secret 被自动更新** - <!-- +#### Mounted Secrets are updated automatically + When a secret being already consumed in a volume is updated, projected keys are eventually updated as well. Kubelet is checking whether the mounted secret is fresh on every periodic sync. However, it is using its local cache for getting the current value of the Secret. @@ -827,23 +1023,29 @@ when new keys are projected to the Pod can be as long as kubelet sync period + c propagation delay, where cache propagation delay depends on the chosen cache type (it equals to watch propagation delay, ttl of cache, or zero corespondingly). --> -当已经在 volume 中被消费的 secret 被更新时，被映射的 key 也将被更新。Kubelet 在周期性同步时检查被挂载的 secret 是不是最新的。但是，它正在使用其本地缓存来获取 Secret 的当前值。 +#### 挂载的 Secret 会被自动更新 -缓存的类型可以使用 (`ConfigMapAndSecretChangeDetectionStrategy` 中的 [KubeletConfiguration 结构](https://github.com/kubernetes/kubernetes/blob/{{< param "docsbranch" >}}/staging/src/k8s.io/kubelet/config/v1beta1/types.go)). -它可以通过基于 ttl 的 watch(默认)传播，也可以将所有请求直接重定向到直接kube-apiserver。 -结果，从更新密钥到将新密钥投射到 Pod 的那一刻的总延迟可能与 kubelet 同步周期 + 缓存传播延迟一样长，其中缓存传播延迟取决于所选的缓存类型。 -(它等于观察传播延迟，缓存的 ttl 或相应为 0) +当已经存储于卷中被使用的 Secret 被更新时，被映射的键也将终将被更新。 +组件 kubelet 在周期性同步时检查被挂载的 Secret 是不是最新的。 +但是，它会使用其本地缓存的数值作为 Secret 的当前值。 -{{< note >}} +缓存的类型可以使用 [KubeletConfiguration 结构](https://github.com/kubernetes/kubernetes/blob/{{< param "docsbranch" >}}/staging/src/k8s.io/kubelet/config/v1beta1/types.go) +中的 `ConfigMapAndSecretChangeDetectionStrategy` 字段来配置。 +它可以通过 watch 操作来传播（默认），基于 TTL 来刷新，也可以 +将所有请求直接重定向到 API 服务器。 +因此，从 Secret 被更新到将新 Secret 被投射到 Pod 的那一刻的总延迟可能与 +kubelet 同步周期 + 缓存传播延迟一样长，其中缓存传播延迟取决于所选的缓存类型。 +对应于不同的缓存类型，该延迟或者等于 watch 传播延迟，或者等于缓存的 TTL， +或者为 0。 <!-- A container using a Secret as a [subPath](/docs/concepts/storage/volumes#using-subpath) volume mount will not receive Secret updates. --> - -使用 Secret 作为[子路径](/docs/concepts/storage/volumes#using-subpath)卷安装的容器将不会收到 Secret 更新。 - +{{< note >}} +使用 Secret 作为[子路径](/zh/docs/concepts/storage/volumes#using-subpath)卷挂载的容器 +不会收到 Secret 更新。 {{< /note >}} {{< feature-state for_k8s_version="v1.18" state="alpha" >}} @@ -854,8 +1056,10 @@ individual Secrets and ConfigMaps as immutable. For clusters that extensively us (at least tens of thousands of unique Secret to Pod mounts), preventing changes to their data has the following advantages: --> -Kubernetes 的 alpha 特性 _不可变的 Secret 和 ConfigMap_ 提供了一个设置各个 Secret 和 ConfigMap 为不可变的选项。 -对于大量使用 Secret 的集群（至少有成千上万各不相同的 Secret 供 Pod 挂载），禁止变更它们的数据有下列好处： +Kubernetes 的 alpha 特性 _不可变的 Secret 和 ConfigMap_ 提供了一种可选配置， +可以设置各个 Secret 和 ConfigMap 为不可变的。 +对于大量使用 Secret 的集群（至少有成千上万各不相同的 Secret 供 Pod 挂载）， +禁止变更它们的数据有下列好处： <!-- - protects you from accidental (or unwanted) updates that could cause applications outages @@ -863,14 +1067,17 @@ Kubernetes 的 alpha 特性 _不可变的 Secret 和 ConfigMap_ 提供了一个 closing watches for secrets marked as immutable. --> - 防止意外（或非预期的）更新导致应用程序中断 -- 通过将 Secret 标记为不可变来关闭 kube-apiserver 对其的监视，以显著地降低 kube-apiserver 的负载来提升集群性能。 +- 通过将 Secret 标记为不可变来关闭 kube-apiserver 对其的监视，从而显著降低 + kube-apiserver 的负载，提升集群性能。 <!-- To use this feature, enable the `ImmutableEmphemeralVolumes` [feature gate](/docs/reference/command-line-tools-reference/feature-gates/) and set your Secret or ConfigMap `immutable` field to `true`. For example: --> -使用这个特性需要启用 `ImmutableEmphemeralVolumes` [特性开关](/docs/reference/command-line-tools-reference/feature-gates/) 并将 Secret 或 ConfigMap 的 `immutable` 字段设置为 `true`. 例如： +使用这个特性需要启用 `ImmutableEmphemeralVolumes` +[特性开关](/zh/docs/reference/command-line-tools-reference/feature-gates/) +并将 Secret 或 ConfigMap 的 `immutable` 字段设置为 `true`. 例如： ```yaml apiVersion: v1 @@ -890,7 +1097,7 @@ these pods. --> {{< note >}} 一旦一个 Secret 或 ConfigMap 被标记为不可变，撤销此操作或者更改 `data` 字段的内容都是 _不_ 可能的。 -只能删除并重新创建这个 Secret. 现有的 Pod 将维持对已删除 Secret 的挂载点 - 建议重新创建这些 pod. +只能删除并重新创建这个 Secret。现有的 Pod 将维持对已删除 Secret 的挂载点 - 建议重新创建这些 Pod。 {{< /note >}} <!-- @@ -906,15 +1113,17 @@ in a pod: This is an example of a pod that uses secrets from environment variables: --> -#### Secret 作为环境变量 +#### 以环境变量的形式使用 Secrets {#using-secrets-as-environment-variables} -将 secret 作为 pod 中的{{< glossary_tooltip text="环境变量" term_id="container-env-variables" >}}使用： +将 Secret 作为 Pod 中的{{< glossary_tooltip text="环境变量" term_id="container-env-variables" >}}使用： -1. 创建一个 secret 或者使用一个已存在的 secret。多个 pod 可以引用同一个 secret。 -1. 修改 Pod 定义，为每个要使用 secret 的容器添加对应 secret key 的环境变量。消费secret key 的环境变量应填充 secret 的名称，并键入 `env[x].valueFrom.secretKeyRef`。 -1. 修改镜像并／或者命令行，以便程序在指定的环境变量中查找值。 +1. 创建一个 Secret 或者使用一个已存在的 Secret。多个 Pod 可以引用同一个 Secret。 +1. 修改 Pod 定义，为每个要使用 Secret 的容器添加对应 Secret 键的环境变量。 + 使用 Secret 键的环境变量应在 `env[x].valueFrom.secretKeyRef` 中指定 + 要包含的 Secret 名称和键名。 +1. 更改镜像并／或者命令行，以便程序在指定的环境变量中查找值。 -这是一个使用 Secret 作为环境变量的示例： +这是一个使用来自环境变量中的 Secret 值的 Pod 示例： ```yaml apiVersion: v1 @@ -946,19 +1155,29 @@ Inside a container that consumes a secret in an environment variables, the secre normal environment variables containing the base-64 decoded values of the secret data. This is the result of commands executed inside the container from the example above: --> -**消费环境变量里的 Secret 值** +#### 使用来自环境变量的 Secret 值 {#consuming-secret-values-from-environment-variables} -在一个消耗环境变量 secret 的容器中，secret key 作为包含 secret 数据的 base-64 解码值的常规环境变量。这是从上面的示例在容器内执行的命令的结果： +在一个以环境变量形式使用 Secret 的容器中，Secret 键表现为常规的环境变量，其中 +包含 Secret 数据的 base-64 解码值。这是从上面的示例在容器内执行的命令的结果： ```shell echo $SECRET_USERNAME ``` + +<!-- The output is similar to: --> +输出类似于： + ``` admin ``` + ```shell echo $SECRET_PASSWORD ``` + +<!-- The output is similar to: --> +输出类似于： + ``` 1f2d1e2e67df ``` @@ -966,22 +1185,26 @@ echo $SECRET_PASSWORD <!-- ### Using imagePullSecrets -An imagePullSecret is a way to pass a secret that contains a Docker (or other) image registry -password to the Kubelet so it can pull a private image on behalf of your Pod. +The `imagePullSecrets` field is a list of references to secrets in the same namespace. +You can use an `imagePullSecrets` to pass a secret that contains a Docker (or other) image registry +password to the kubelet. The kubelet uses this information to pull a private image on behalf of your Pod. +See the [PodSpec API](/docs/reference/generated/kubernetes-api/{{< latest-version >}}/#podspec-v1-core) for more information about the `imagePullSecrets` field. -**Manually specifying an imagePullSecret** - -Use of imagePullSecrets is described in the [images documentation](/docs/concepts/containers/images/#specifying-imagepullsecrets-on-a-pod) +#### Manually specifying an imagePullSecret +You can learn how to specify `ImagePullSecrets` from the [container images documentation](/docs/concepts/containers/images/#specifying-imagepullsecrets-on-a-pod). --> +#### 使用 imagePullSecret {#using-imagepullsecrets} -#### 使用 imagePullSecret +`imagePullSecrets` 字段中包含一个列表，列举对同一名字空间中的 Secret 的引用。 +你可以使用 `imagePullSecrets` 将包含 Docker（或其他）镜像仓库密码的 Secret 传递给 +kubelet。kubelet 使用此信息来替你的 Pod 拉取私有镜像。 +关于 `imagePullSecrets` 字段的更多信息，请参考 [PodSpec API](/docs/reference/generated/kubernetes-api/{{< latest-version >}}/#podspec-v1-core) 文档。 -imagePullSecret 是将包含 Docker（或其他）镜像注册表密码的 secret 传递给 Kubelet 的一种方式，因此可以代表您的 pod 拉取私有镜像。 +#### 手动指定 imagePullSecret -**手动指定 imagePullSecret** - -imagePullSecret 的使用在 [镜像文档](/docs/concepts/containers/images/#specifying-imagepullsecrets-on-a-pod) 中说明。 +你可以阅读[容器镜像文档](/zh/docs/concepts/containers/images/#specifying-imagepullsecrets-on-a-pod) +以了解如何设置 `imagePullSecrets`。 <!-- ### Arranging for imagePullSecrets to be Automatically Attached @@ -993,10 +1216,13 @@ field set to that of the service account. See [Add ImagePullSecrets to a service account](/docs/tasks/configure-pod-container/configure-service-account/#add-imagepullsecrets-to-a-service-account) for a detailed explanation of that process. --> +#### 设置自动附加 imagePullSecrets -### 安排 imagePullSecrets 自动附加 - -您可以手动创建 imagePullSecret，并从 serviceAccount 引用它。使用该 serviceAccount 创建的任何 pod 和默认使用该 serviceAccount 的 pod 将会将其的 imagePullSecret 字段设置为服务帐户的 imagePullSecret 字段。有关该过程的详细说明，请参阅 [将 ImagePullSecrets 添加到服务帐户](/docs/tasks/configure-pod-container/configure-service-account/#adding-imagepullsecrets-to-a-service-account)。 +您可以手动创建 `imagePullSecret`，并在 ServiceAccount 中引用它。 +使用该 ServiceAccount 创建的任何 Pod 和默认使用该 ServiceAccount 的 +Pod 将会将其的 imagePullSecret 字段设置为服务帐户的 imagePullSecret 值。 +有关该过程的详细说明，请参阅 +[将 ImagePullSecrets 添加到服务帐户](/zh/docs/tasks/configure-pod-container/configure-service-account/#adding-imagepullsecrets-to-a-service-account)。 <!-- ### Automatic Mounting of Manually Created Secrets @@ -1008,7 +1234,10 @@ See [Injecting Information into Pods Using a PodPreset](/docs/tasks/inject-data- #### 自动挂载手动创建的 Secret -手动创建的 secret（例如包含用于访问 github 帐户的令牌）可以根据其服务帐户自动附加到 pod。请参阅 [使用 PodPreset 向 Pod 中注入信息](/docs/tasks/run-application/podpreset/) 以获取该进程的详细说明。 +手动创建的 Secret（例如包含用于访问 GitHub 帐户令牌的 Secret）可以 +根据其服务帐户自动附加到 Pod。 +请参阅[使用 PodPreset 向 Pod 中注入信息](/zh/docs/tasks/inject-data-application/podpreset/) +以获取该过程的详细说明。 <!-- ## Details @@ -1016,20 +1245,21 @@ See [Injecting Information into Pods Using a PodPreset](/docs/tasks/inject-data- ### Restrictions Secret volume sources are validated to ensure that the specified object -reference actually points to an object of type `Secret`. Therefore, a secret +reference actually points to an object of type Secret. Therefore, a secret needs to be created before any pods that depend on it. Secret API objects reside in a {{< glossary_tooltip text="namespace" term_id="namespace" >}}. They can only be referenced by pods in that same namespace. --> +## 详细说明 {#details} -## 详细 +### 限制 {#restrictions} -### 限制 +Kubernetes 会验证 Secret 作为卷来源时所给的对象引用确实指向一个类型为 +Secret 的对象。因此，Secret 需要先于任何依赖于它的 Pod 创建。 -验证 secret volume 来源确保指定的对象引用实际上指向一个类型为 Secret 的对象。因此，需要在依赖于它的任何 pod 之前创建一个 secret。 - -Secret API 对象驻留在命名空间中。它们只能由同一命名空间中的 pod 引用。 +Secret API 对象处于某{{< glossary_tooltip text="名字空间" term_id="namespace" >}} +中。它们只能由同一命名空间中的 Pod 引用。 <!-- Individual secrets are limited to 1MiB in size. This is to discourage creation @@ -1043,10 +1273,14 @@ controller. It does not include pods created via the kubelets `--manifest-url` flag, its `--config` flag, or its REST API (these are not common ways to create pods.) --> +每个 Secret 的大小限制为 1MB。这是为了防止创建非常大的 Secret 导致 API 服务器 +和 kubelet 的内存耗尽。然而，创建过多较小的 Secret 也可能耗尽内存。 +更全面得限制 Secret 内存用量的功能还在计划中。 -每个 secret 的大小限制为 1MB。这是为了防止创建非常大的 secret 会耗尽 apiserver 和 kubelet 的内存。然而，创建许多较小的 secret 也可能耗尽内存。更全面得限制 secret 对内存使用的功能还在计划中。 - -Kubelet 仅支持从 API server 获取的 Pod 使用 secret。这包括使用 kubectl 创建的任何 pod，或间接通过 replication controller 创建的 pod。它不包括通过 kubelet `--manifest-url` 标志，其 `--config` 标志或其 REST API 创建的 pod（这些不是创建 pod 的常用方法）。 +kubelet 仅支持从 API 服务器获得的 Pod 使用 Secret。 +这包括使用 `kubectl` 创建的所有 Pod，以及间接通过副本控制器创建的 Pod。 +它不包括通过 kubelet `--manifest-url` 标志，`--config` 标志或其 REST API +创建的 Pod（这些不是创建 Pod 的常用方法）。 <!-- Secrets must be created before they are consumed in pods as environment @@ -1063,16 +1297,24 @@ reason is `InvalidVariableNames` and the message will contain the list of invalid keys that were skipped. The example shows a pod which refers to the default/mysecret that contains 2 invalid keys, 1badkey and 2alsobad. --> +以环境变量形式在 Pod 中使用 Secret 之前必须先创建 +Secret，除非该环境变量被标记为可选的。 +Pod 中引用不存在的 Secret 时将无法启动。 -必须先创建 secret，除非将它们标记为可选项，否则必须在将其作为环境变量在 pod 中使用之前创建 secret。对不存在的 secret 的引用将阻止其启动。 +使用 `secretKeyRef` 时，如果引用了指定 Secret 不存在的键，对应的 Pod 也无法启动。 -使用 `secretKeyRef` ，引用指定的 secret 中的不存在的 key ，这会阻止 pod 的启动。 - -对于通过 `envFrom` 填充环境变量的 secret，这些环境变量具有被认为是无效环境变量名称的 key 将跳过这些键。该 pod 将被允许启动。将会有一个事件，其原因是 `InvalidVariableNames`，该消息将包含被跳过的无效键的列表。该示例显示一个 pod，它指的是包含2个无效键，1badkey 和 2alsobad 的默认/mysecret ConfigMap。 +对于通过 `envFrom` 填充环境变量的 Secret，如果 Secret 中包含的键名无法作为 +合法的环境变量名称，对应的键会被跳过，该 Pod 将被允许启动。 +不过这时会产生一个事件，其原因为 `InvalidVariableNames`，其消息中包含被跳过的无效键的列表。 +下面的示例显示一个 Pod，它引用了包含 2 个无效键 1badkey 和 2alsobad。 ```shell kubectl get events ``` + +<!--The output is similar to:--> +输出类似于： + ``` LASTSEEN FIRSTSEEN COUNT NAME KIND SUBOBJECT TYPE REASON 0s 0s 1 dapi-test-pod Pod Warning InvalidEnvironmentVariableNames kubelet, 127.0.0.1 Keys [1badkey, 2alsobad] from the EnvFrom secret default/mysecret were skipped since they are considered invalid environment variable names. @@ -1090,46 +1332,110 @@ reason it is not started yet. Once the secret is fetched, the kubelet will create and mount a volume containing it. None of the pod's containers will start until all the pod's volumes are mounted. --> -### Secret 与 Pod 生命周期的联系 +### Secret 与 Pod 生命周期的关系 -通过 API 创建 Pod 时，不会检查应用的 secret 是否存在。一旦 Pod 被调度，kubelet 就会尝试获取该 secret 的值。如果获取不到该 secret，或者暂时无法与 API server 建立连接，kubelet 将会定期重试。Kubelet 将会报告关于 pod 的事件，并解释它无法启动的原因。一旦获取到 secret，kubelet 将创建并装载一个包含它的卷。在所有 pod 的卷被挂载之前，都不会启动 pod 的容器。 +通过 API 创建 Pod 时，不会检查引用的 Secret 是否存在。一旦 Pod 被调度，kubelet +就会尝试获取该 Secret 的值。如果获取不到该 Secret，或者暂时无法与 API 服务器建立连接， +kubelet 将会定期重试。kubelet 将会报告关于 Pod 的事件，并解释它无法启动的原因。 +一旦获取到 Secret，kubelet 将创建并挂载一个包含它的卷。在 Pod 的所有卷被挂载之前， +Pod 中的容器不会启动。 <!-- ## Use cases -### Use-Case: Pod with ssh keys +### Use-Case: As container environment variables -Create a kustomization.yaml with SecretGenerator containing some ssh keys: --> - ## 使用案例 -### 使用案例：包含 ssh 密钥的 pod -创建一个包含 ssh key 的 secret： +### 案例：以环境变量的形式使用 Secret + +<!-- Create a secret --> +创建一个 Secret 定义： + +```yaml +apiVersion: v1 +kind: Secret +metadata: + name: mysecret +type: Opaque +data: + USER_NAME: YWRtaW4= + PASSWORD: MWYyZDFlMmU2N2Rm +``` + +<!-- Create the Secret: --> +生成 Secret 对象： ```shell -kubectl create secret generic ssh-key-secret --from-file=ssh-privatekey=/path/to/.ssh/id_rsa --from-file=ssh-publickey=/path/to/.ssh/id_rsa.pub +kubectl apply -f mysecret.yaml ``` +<!-- +Use `envFrom` to define all of the Secret’s data as container environment variables. The key from the Secret becomes the environment variable name in the Pod. +--> +使用 `envFrom` 将 Secret 的所有数据定义为容器的环境变量。 +Secret 中的键名称为 Pod 中的环境变量名称： + +```yaml +apiVersion: v1 +kind: Pod +metadata: + name: secret-test-pod +spec: + containers: + - name: test-container + image: k8s.gcr.io/busybox + command: [ "/bin/sh", "-c", "env" ] + envFrom: + - secretRef: + name: mysecret + restartPolicy: Never +``` + +<!-- +### Use-Case: Pod with ssh keys + +Create a secret containing some ssh keys: +--> +### 案例：包含 SSH 密钥的 Pod + +创建一个包含 SSH 密钥的 Secret： + +```shell +kubectl create secret generic ssh-key-secret \ + --from-file=ssh-privatekey=/path/to/.ssh/id_rsa \ + --from-file=ssh-publickey=/path/to/.ssh/id_rsa.pub +``` + +<!-- The output is similar to: --> +输出类似于： + ``` secret "ssh-key-secret" created ``` -{{< caution >}} +<!-- +You can also create a `kustomization.yaml` with a `secretGenerator` field containing ssh keys. +--> +你也可以创建一个带有包含 SSH 密钥的 `secretGenerator` 字段的 +`kustomization.yaml` 文件。 + <!-- Think carefully before sending your own ssh keys: other users of the cluster may have access to the secret. Use a service account which you want to be accessible to all the users with whom you share the Kubernetes cluster, and can revoke if they are compromised. --> - -发送自己的 ssh 密钥之前要仔细思考：集群的其他用户可能有权访问该密钥。使用您想要共享 Kubernetes 群集的所有用户可以访问的服务帐户，如果它们遭到入侵，可以撤销。 +{{< caution >}} +发送自己的 SSH 密钥之前要仔细思考：集群的其他用户可能有权访问该密钥。 +你可以使用一个服务帐户，分享给 Kubernetes 集群中合适的用户，这些用户是你要分享的。 +如果服务账号遭到侵犯，可以将其收回。 {{< /caution >}} - <!-- Now we can create a pod which references the secret with the ssh key and consumes it in a volume: --> -现在我们可以创建一个使用 ssh 密钥引用 secret 的 pod，并在一个卷中使用它： +现在我们可以创建一个 Pod，令其引用包含 SSH 密钥的 Secret，并通过存储卷来使用它： ```yaml apiVersion: v1 @@ -1155,10 +1461,9 @@ spec: <!-- When the container's command runs, the pieces of the key will be available in: --> +容器中的命令运行时，密钥的片段可以在以下目录找到： -当容器中的命令运行时，密钥的片段将可在以下目录： - -```shell +``` /etc/secret-volume/ssh-publickey /etc/secret-volume/ssh-privatekey ``` @@ -1166,7 +1471,7 @@ When the container's command runs, the pieces of the key will be available in: <!-- The container is then free to use the secret data to establish an ssh connection. --> -然后容器可以自由使用密钥数据建立一个 ssh 连接。 +然后容器可以自由使用 Secret 数据建立一个 SSH 连接。 <!-- ### Use-Case: Pods with prod / test credentials @@ -1175,43 +1480,61 @@ This example illustrates a pod which consumes a secret containing prod credentials and another pod which consumes a secret with test environment credentials. -Make the kustomization.yaml with SecretGenerator +You can create a `kustomization.yaml` with a `secretGenerator` field or run +`kubectl create secret`. + --> -### 使用案例：包含 prod/test 凭据的 pod +### 案例：包含生产/测试凭据的 Pod -下面的例子说明一个 pod 消费一个包含 prod 凭据的 secret，另一个 pod 使用测试环境凭据消费 secret。 +下面的例子展示的是两个 Pod。 +一个 Pod 使用包含生产环境凭据的 Secret，另一个 Pod 使用包含测试环境凭据的 Secret。 -通过秘钥生成器制作 kustomization.yaml +你可以创建一个带有 `secretGenerator` 字段的 `kustomization.yaml` +文件，或者执行 `kubectl create secret`： ```shell -kubectl create secret generic prod-db-secret --from-literal=username=produser --from-literal=password=Y4nys7f11 +kubectl create secret generic prod-db-secret \ + --from-literal=username=produser \ + --from-literal=password=Y4nys7f11 ``` + +<!--The output is similar to:--> +输出类似于： + ``` secret "prod-db-secret" created ``` ```shell -kubectl create secret generic test-db-secret --from-literal=username=testuser --from-literal=password=iluvtests +kubectl create secret generic test-db-secret \ + --from-literal=username=testuser \ + --from-literal=password=iluvtests ``` + +<!--The output is similar to:--> +输出类似于： + ``` secret "test-db-secret" created ``` -{{< note >}} -<!-- -Special characters such as `$`, `\*`, and `!` require escaping. -If the password you are using has special characters, you need to escape them using the `\\` character. For example, if your actual password is `S!B\*d$zDsb`, you should execute the command this way: ---> - -特殊字符（例如 `$`, `\*`, 和 `!`）需要转义。 如果您使用的密码具有特殊字符，则需要使用 `\\` 字符对其进行转义。 例如，如果您的实际密码是 `S!B\*d$zDsb`，则应通过以下方式执行命令： - -```shell -kubectl create secret generic dev-db-secret --from-literal=username=devuser --from-literal=password=S\\!B\\\*d\\$zDsb -``` <!-- +Special characters such as `$`, `\`, `*`, `=`, and `!` will be interpreted by your [shell](https://en.wikipedia.org/wiki/Shell_(computing)) and require escaping. +In most shells, the easiest way to escape the password is to surround it with single quotes (`'`). +For example, if your actual password is `S!B\*d$zDsb=`, you should execute the command this way: You do not need to escape special characters in passwords from files (`--from-file`). --> -您无需从文件中转义密码中的特殊字符（ `--from-file` ）。 +{{< note >}} +特殊字符（例如 `$`、`\`、`*`、`=` 和 `!`）会被你的 +[Shell](https://en.wikipedia.org/wiki/Shell_(computing))解释，因此需要转义。 +在大多数 Shell 中，对密码进行转义的最简单方式是用单引号（`'`）将其括起来。 +例如，如果您的实际密码是 `S!B\*d$zDsb`，则应通过以下方式执行命令： + +```shell +kubectl create secret generic dev-db-secret --from-literal=username=devuser --from-literal=password='S!B\*d$zDsb=' +``` + +您无需对文件中的密码（`--from-file`）中的特殊字符进行转义。 {{< /note >}} <!-- @@ -1266,8 +1589,7 @@ EOF <!-- Add the pods to the same kustomization.yaml --> - -加入 Pod 到同样的 kustomization.yaml 文件 +将 Pod 添加到同一个 kustomization.yaml 文件 ```shell $ cat <<EOF >> kustomization.yaml @@ -1279,7 +1601,7 @@ EOF <!-- Apply all those objects on the Apiserver by --> -部署所有的对象通过下面的命令 +通过下面的命令应用所有对象 ```shell kubectl apply -k . @@ -1288,9 +1610,9 @@ kubectl apply -k . <!-- Both containers will have the following files present on their filesystems with the values for each container's environment: --> -这两个容器将在其文件系统上显示以下文件，其中包含每个容器环境的值： +两个容器都会在其文件系统上存在以下文件，其中包含容器对应的环境的值： -```shell +``` /etc/secret-volume/username /etc/secret-volume/password ``` @@ -1300,13 +1622,21 @@ Note how the specs for the two pods differ only in one field; this facilitates creating pods with different capabilities from a common pod config template. You could further simplify the base pod specification by using two Service Accounts: -one called, say, `prod-user` with the `prod-db-secret`, and one called, say, -`test-user` with the `test-db-secret`. Then, the pod spec can be shortened to, for example: + +1. `prod-user` with the `prod-db-secret` +1. `test-user` with the `test-db-secret` + +The Pod specification is shortened to: --> +请注意，两个 Pod 的规约配置中仅有一个字段不同；这有助于使用共同的 Pod 配置模板创建 +具有不同能力的 Pod。 -请注意，两个 pod 的 spec 配置中仅有一个字段有所不同；这有助于使用普通的 pod 配置模板创建具有不同功能的 pod。 +您可以使用两个服务账号进一步简化基本的 Pod 规约： -您可以使用两个 service account 进一步简化基本 pod spec：一个名为 `prod-user` 拥有 `prod-db-secret` ，另一个称为 `test-user` 拥有 `test-db-secret` 。然后，pod spec 可以缩短为，例如： +1. 名为 `prod-user` 的服务账号拥有 `prod-db-secret` +1. 名为 `test-user` 的服务账号拥有 `test-db-secret` + +然后，Pod 规约可以缩短为： ```yaml apiVersion: v1 @@ -1325,12 +1655,15 @@ spec: <!-- ### Use-case: Dotfiles in secret volume -In order to make piece of data 'hidden' (i.e., in a file whose name begins with a dot character), simply -make that key begin with a dot. For example, when the following secret is mounted into a volume: ---> -### 使用案例：Secret 卷中以点号开头的文件 +You can make your data "hidden" by defining a key that begins with a dot. +This key represents a dotfile or "hidden" file. For example, when the following secret +is mounted into a volume, `secret-volume`: -为了将数据“隐藏”起来（即文件名以点号开头的文件），简单地说让该键以一个点开始。例如，当如下 secret 被挂载到卷中： +--> +### 案例：Secret 卷中以句点号开头的文件 + +你可以通过定义以句点开头的键名，将数据“隐藏”起来。 +例如，当如下 Secret 被挂载到 `secret-volume` 卷中： ```yaml apiVersion: v1 @@ -1364,20 +1697,20 @@ spec: <!-- -The `secret-volume` will contain a single file, called `.secret-file`, and +The volume will contain a single file, called `.secret-file`, and the `dotfile-test-container` will have this file present at the path `/etc/secret-volume/.secret-file`. --> -`Secret-volume` 将包含一个单独的文件，叫做 `.secret-file`，`dotfile-test-container` 的 `/etc/secret-volume/.secret-file` 路径下将有该文件。 - -{{< note >}} +卷中将包含唯一的叫做 `.secret-file` 的文件。 +容器 `dotfile-test-container` 中，该文件处于 `/etc/secret-volume/.secret-file` 路径下。 <!-- Files beginning with dot characters are hidden from the output of `ls -l`; you must use `ls -la` to see them when listing directory contents. --> - -以点号开头的文件在 `ls -l` 的输出中被隐藏起来了；列出目录内容时，必须使用 `ls -la` 才能查看它们。 +{{< note >}} +以点号开头的文件在 `ls -l` 的输出中会被隐藏起来； +列出目录内容时，必须使用 `ls -la` 才能看到它们。 {{< /note >}} <!-- @@ -1388,10 +1721,10 @@ logic, and then sign some messages with an HMAC. Because it has complex application logic, there might be an unnoticed remote file reading exploit in the server, which could expose the private key to an attacker. --> - -### 使用案例：Secret 仅对 pod 中的一个容器可见 - -考虑以下一个需要处理 HTTP 请求的程序，执行一些复杂的业务逻辑，然后使用 HMAC 签署一些消息。因为它具有复杂的应用程序逻辑，所以在服务器中可能会出现一个未被注意的远程文件读取漏洞，这可能会将私钥暴露给攻击者。 +### 案例：Secret 仅对 Pod 中的一个容器可见 {#secret-visible-to-only-one-container} +考虑一个需要处理 HTTP 请求、执行一些复杂的业务逻辑，然后使用 HMAC 签署一些消息的应用。 +因为应用程序逻辑复杂，服务器中可能会存在一个未被注意的远程文件读取漏洞， +可能会将私钥暴露给攻击者。 <!-- This could be divided into two processes in two containers: a frontend container @@ -1403,10 +1736,12 @@ With this partitioned approach, an attacker now has to trick the application server into doing something rather arbitrary, which may be harder than getting it to read a file. --> +解决的办法可以是将应用分为两个进程，分别运行在两个容器中： +前端容器，用于处理用户交互和业务逻辑，但无法看到私钥； +签名容器，可以看到私钥，响应来自前端（例如通过本地主机网络）的简单签名请求。 -这可以在两个容器中分为两个进程：前端容器，用于处理用户交互和业务逻辑，但无法看到私钥；以及可以看到私钥的签名者容器，并且响应来自前端的简单签名请求（例如通过本地主机网络）。 - -使用这种分割方法，攻击者现在必须欺骗应用程序服务器才能进行任意的操作，这可能比使其读取文件更难。 +使用这种分割方法，攻击者现在必须欺骗应用程序服务器才能进行任意的操作， +这可能比使其读取文件更难。 <!-- TODO: explain how to do this while still using automation. --> @@ -1420,12 +1755,13 @@ limited using [authorization policies]( /docs/reference/access-authn-authz/authorization/) such as [RBAC]( /docs/reference/access-authn-authz/rbac/). --> - -## 最佳实践 +## 最佳实践 {#best-practices} ### 客户端使用 Secret API -当部署与 secret API 交互的应用程序时，应使用 [授权策略](/docs/reference/access-authn-authz/authorization/)， 例如 [RBAC](/docs/reference/access-authn-authz/rbac/) 来限制访问。 +当部署与 Secret API 交互的应用程序时，应使用 +[鉴权策略](/zh/docs/reference/access-authn-authz/authorization/)， +例如 [RBAC](/zh/docs/reference/access-authn-authz/rbac/)，来限制访问。 <!-- Secrets often hold values that span a spectrum of importance, many of which can @@ -1441,9 +1777,15 @@ the clients to inspect the values of all secrets that are in that namespace. The privileged, system-level components. --> -Secret 中的值对于不同的环境来说重要性可能不同，例如对于 Kubernetes 集群内部（例如 service account 令牌）和集群外部来说就不一样。即使一个应用程序可以理解其期望的与之交互的 secret 有多大的能力，但是同一命名空间中的其他应用程序却可能不这样认为。 +Secret 中的值对于不同的环境来说重要性可能不同。 +很多 Secret 都可能导致 Kubernetes 集群内部的权限越界（例如服务账号令牌） +甚至逃逸到集群外部。 +即使某一个应用程序可以就所交互的 Secret 的能力作出正确抉择，但是同一命名空间中 +的其他应用程序却可能不这样做。 -由于这些原因，在命名空间中 `watch` 和 `list` secret 的请求是非常强大的功能，应该避免这样的行为，因为列出 secret 可以让客户端检查所有 secret 是否在该命名空间中。在群集中 `watch` 和 `list` 所有 secret 的能力应该只保留给最有特权的系统级组件。 +由于这些原因，在命名空间中 `watch` 和 `list` Secret 的请求是非常强大的能力， +是应该避免的行为。列出 Secret 的操作可以让客户端检查该命名空间中存在的所有 Secret。 +在群集中 `watch` 和 `list` 所有 Secret 的能力应该只保留给特权最高的系统级组件。 <!-- Applications that need to access the secrets API should perform `get` requests on @@ -1459,17 +1801,18 @@ https://github.com/kubernetes/community/blob/master/contributors/design-proposal to let clients `watch` individual resources has also been proposed, and will likely be available in future releases of Kubernetes. --> +需要访问 Secret API 的应用程序应该针对所需要的 Secret 执行 `get` 请求。 +这样，管理员就能限制对所有 Secret 的访问，同时为应用所需要的 +[实例设置访问允许清单](/zh/docs/reference/access-authn-authz/rbac/#referring-to-resources) 。 -需要访问 secrets API 的应用程序应该根据他们需要的 secret 执行 `get` 请求。这允许管理员限制对所有 secret 的访问， -同时设置 [白名单访问](/docs/reference/access-authn-authz/rbac/#referring-to-resources) 应用程序需要的各个实例。 - -为了提高循环获取的性能，客户端可以设计引用 secret 的资源，然后 `watch` 资源，在引用更改时重新请求 secret。 -此外，还提出了一种 [”批量监控“ API](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/bulk_watch.md) 来让客户端 `watch` 每个资源，该功能可能会在将来的 Kubernetes 版本中提供。 +为了获得高于轮询操作的性能，客户端设计资源时，可以引用 Secret，然后对资源执行 `watch` +操作，在引用更改时重新检索 Secret。 +此外，社区还存在一种 [“批量监控” API](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/bulk_watch.md) +的提案，允许客户端 `watch` 独立的资源，该功能可能会在将来的 Kubernetes 版本中提供。 <!-- ## Security Properties - ### Protections Because `secret` objects can be created independently of the `pods` that use @@ -1478,12 +1821,13 @@ creating, viewing, and editing pods. The system can also take additional precautions with `secret` objects, such as avoiding writing them to disk where possible. --> +## 安全属性 {#security-properties} -## 安全属性 +### 保护 {#protections} -### 保护 - -因为 `secret` 对象可以独立于使用它们的 `pod` 而创建，所以在创建、查看和编辑 pod 的流程中 secret 被暴露的风险较小。系统还可以对 `secret` 对象采取额外的预防措施，例如避免将其写入到磁盘中可能的位置。 +因为 Secret 对象可以独立于使用它们的 Pod 而创建，所以在创建、查看和编辑 Pod 的流程中 +Secret 被暴露的风险较小。系统还可以对 Secret 对象采取额外的预防性保护措施， +例如，在可能的情况下避免将其写到磁盘。 <!-- A secret is only sent to a node if a pod on that node requires it. @@ -1495,10 +1839,13 @@ There may be secrets for several pods on the same node. However, only the secrets that a pod requests are potentially visible within its containers. Therefore, one Pod does not have access to the secrets of another Pod. --> +只有当某节点上的 Pod 需要用到某 Secret 时，该 Secret 才会被发送到该节点上。 +Secret 不会被写入磁盘，而是被 kubelet 存储在 tmpfs 中。 +一旦依赖于它的 Pod 被删除，Secret 数据的本地副本就被删除。 -只有当节点上的 pod 需要用到该 secret 时，该 secret 才会被发送到该节点上。它不会被写入磁盘，而是存储在 tmpfs 中。一旦依赖于它的 pod 被删除，它就被删除。 - -同一节点上的很多个 pod 可能拥有多个 secret。但是，只有 pod 请求的 secret 在其容器中才是可见的。因此，一个 pod 不能访问另一个 Pod 的 secret。 +同一节点上的很多个 Pod 可能拥有多个 Secret。 +但是，只有 Pod 所请求的 Secret 在其容器中才是可见的。 +因此，一个 Pod 不能访问另一个 Pod 的 Secret。 <!-- There may be several containers in a pod. However, each container in a pod has @@ -1506,14 +1853,17 @@ to request the secret volume in its `volumeMounts` for it to be visible within the container. This can be used to construct useful [security partitions at the Pod level](#use-case-secret-visible-to-one-container-in-a-pod). -On most Kubernetes-project-maintained distributions, communication between user +On most Kubernetes distributions, communication between users to the apiserver, and from apiserver to the kubelets, is protected by SSL/TLS. Secrets are protected when transmitted over these channels. --> -Pod 中有多个容器。但是，pod 中的每个容器必须请求其挂载卷中的 secret 卷才能在容器内可见。 -这可以用于 [在 Pod 级别构建安全分区](#使用案例secret-仅对-pod-中的一个容器可见)。 +同一个 Pod 中可能有多个容器。但是，Pod 中的每个容器必须通过 `volumeeMounts` +请求挂载 Secret 卷才能使卷中的 Secret 对容器可见。 +这一实现可以用于在 Pod 级别[构建安全分区](#secret-visible-to-only-one-container)。 -在大多数 Kubernetes 项目维护的发行版中，用户与 API server 之间的通信以及从 API server 到 kubelet 的通信都受到 SSL/TLS 的保护。通过这些通道传输时，secret 受到保护。 +在大多数 Kubernetes 发行版中，用户与 API 服务器之间的通信以及 +从 API 服务器到 kubelet 的通信都受到 SSL/TLS 的保护。 +通过这些通道传输时，Secret 受到保护。 {{< feature-state for_k8s_version="v1.13" state="beta" >}} @@ -1521,7 +1871,8 @@ Pod 中有多个容器。但是，pod 中的每个容器必须请求其挂载卷 You can enable [encryption at rest](/docs/tasks/administer-cluster/encrypt-data/) for secret data, so that the secrets are not stored in the clear into {{< glossary_tooltip term_id="etcd" >}}. --> -你可以为 secret 数据开启[静态加密](/docs/tasks/administer-cluster/encrypt-data/)，这样秘密信息就不会以明文形式存储到{{< glossary_tooltip term_id="etcd" >}}。 +你可以为 Secret 数据开启[静态加密](/zh/docs/tasks/administer-cluster/encrypt-data/)， +这样 Secret 数据就不会以明文形式存储到{{< glossary_tooltip term_id="etcd" >}} 中。 <!-- ### Risks @@ -1547,21 +1898,17 @@ for secret data, so that the secrets are not stored in the clear into {{< glossa nodes that actually require them, to restrict the impact of a root exploit on a single node. --> - - ### 风险 -- API server 的 secret 数据以纯文本的方式存储在 etcd 中，因此： - - 管理员应该为集群数据开启静态加密(需求 v1.13 或者更新)。 - - 管理员应该限制 admin 用户访问 etcd； - - API server 中的 secret 数据位于 etcd 使用的磁盘上；管理员可能希望在不再使用时擦除/粉碎 etcd 使用的磁盘 +- API 服务器上的 Secret 数据以纯文本的方式存储在 etcd 中，因此： + - 管理员应该为集群数据开启静态加密（要求 v1.13 或者更高版本）。 + - 管理员应该限制只有 admin 用户能访问 etcd； + - API 服务器中的 Secret 数据位于 etcd 使用的磁盘上；管理员可能希望在不再使用时擦除/粉碎 etcd 使用的磁盘 - 如果 etcd 运行在集群内，管理员应该确保 etcd 之间的通信使用 SSL/TLS 进行加密。 -- 如果您将 secret 数据编码为 base64 的清单（JSON 或 YAML）文件，共享该文件或将其检入代码库，这样的话该密码将会被泄露。 Base64 编码不是一种加密方式，一样也是纯文本。 -- 应用程序在从卷中读取 secret 后仍然需要保护 secret 的值，例如不会意外记录或发送给不信任方。 -- 可以创建和使用 secret 的 pod 的用户也可以看到该 secret 的值。即使 API server 策略不允许用户读取 secret 对象，用户也可以运行暴露 secret 的 pod。 -- 目前，任何节点的 root 用户都可以通过模拟 kubelet 来读取 API server 中的任何 secret。只有向实际需要它们的节点发送 secret 才能限制单个节点的根漏洞的影响，该功能还在计划中。 - -## {{% heading "whatsnext" %}} - - +- 如果您将 Secret 数据编码为 base64 的清单（JSON 或 YAML）文件，共享该文件或将其检入代码库，该密码将会被泄露。 Base64 编码不是一种加密方式，应该视同纯文本。 +- 应用程序在从卷中读取 Secret 后仍然需要保护 Secret 的值，例如不会意外将其写入日志或发送给不信任方。 +- 可以创建使用 Secret 的 Pod 的用户也可以看到该 Secret 的值。即使 API 服务器策略不允许用户读取 Secret 对象，用户也可以运行 Pod 导致 Secret 暴露。 +- 目前，任何节点的 root 用户都可以通过模拟 kubelet 来读取 API 服务器中的任何 Secret。 + 仅向实际需要 Secret 的节点发送 Secret 数据才能限制节点的 root 账号漏洞的影响， + 该功能还在计划中。 diff --git a/content/zh/docs/concepts/containers/container-environment-variables.md b/content/zh/docs/concepts/containers/container-environment-variables.md deleted file mode 100644 index 5f797a856c..0000000000 --- a/content/zh/docs/concepts/containers/container-environment-variables.md +++ /dev/null @@ -1,63 +0,0 @@ ---- -approvers: -- mikedanese -- thockin -title: 容器环境变量 -content_type: concept ---- - -<!-- overview --> - -本文介绍容器环境中对容器可用的资源。 - - - -{{< toc >}} - -<!-- body --> - -## 容器环境 - -Kubernetes 容器环境为容器提供了几类重要的资源： - -* 一个文件系统，其中包含一个[镜像](/docs/concepts/containers/images/)和一个或多个[卷](/docs/concepts/storage/volumes/)。 -* 容器本身相关的信息。 -* 集群中其他对象相关的信息。 - -### 容器信息 - -容器的 *hostname* 是容器所在的 Pod 名称。 可以通过 `hostname` 命令或调用 libc 中的 -[`gethostname`](http://man7.org/linux/man-pages/man2/gethostname.2.html) -函数来获取。 - -Pod 名称和名字空间可以通过 -[downward API](/docs/tasks/inject-data-application/downward-api-volume-expose-pod-information/) 以环境变量方式访问。 - -与 Docker 镜像中静态指定的环境变量一样，Pod 中用户定义的环境变量也可用于容器。 - -### 集群信息 - -容器创建时运行的所有服务的列表都会作为环境变量提供给容器。 -这些环境变量与 Docker 链接语法相匹配。 - -对一个名为 *foo* ，映射到名为 *bar* 的容器端口的服务， -会定义如下变量： - -```shell -FOO_SERVICE_HOST=<服务所在的主机地址> -FOO_SERVICE_PORT=<服务所启用的端口> -``` - -服务具有专用 IP 地址，如果启用了 [DNS 插件](http://releases.k8s.io/{{< param "githubbranch" >}}/cluster/addons/dns/)，还可以在容器中通过 DNS 进行访问。 - - - -## {{% heading "whatsnext" %}} - - -* 查看[容器生命周期挂钩（hooks）](/docs/concepts/containers/container-lifecycle-hooks/)了解更多。 -* 获取[为容器生命周期事件附加处理程序](/docs/tasks/configure-pod-container/attach-handler-lifecycle-event/)的实践经验。 - - - - diff --git a/content/zh/docs/concepts/containers/container-environment.md b/content/zh/docs/concepts/containers/container-environment.md index 777f746f67..543260c95a 100644 --- a/content/zh/docs/concepts/containers/container-environment.md +++ b/content/zh/docs/concepts/containers/container-environment.md @@ -3,6 +3,14 @@ title: 容器环境 content_type: concept weight: 20 --- +<!-- +reviewers: +- mikedanese +- thockin +title: Container Environment +content_type: concept +weight: 20 +--> <!-- overview --> @@ -11,9 +19,6 @@ This page describes the resources available to Containers in the Container envir --> 本页描述了在容器环境里容器可用的资源。 - - - <!-- body --> <!-- @@ -25,13 +30,14 @@ The Kubernetes Container environment provides several important resources to Con * Information about the Container itself. * Information about other objects in the cluster. --> -## 容器环境 +## 容器环境 {#container-environment} Kubernetes 的容器环境给容器提供了几个重要的资源： -* 文件系统，其中包含一个[镜像](/docs/concepts/containers/images/) 和一个或多个的[卷](/docs/concepts/storage/volumes/)。 -* 容器自身的信息。 -* 集群中其他对象的信息。 +* 文件系统，其中包含一个[镜像](/zh/docs/concepts/containers/images/) + 和一个或多个的[卷](/zh/docs/concepts/storage/volumes/) +* 容器自身的信息 +* 集群中其他对象的信息 <!-- ### Container information @@ -49,9 +55,12 @@ as are any environment variables specified statically in the Docker image. --> ### 容器信息 -容器的 *hostname* 是它所运行在的 pod 的名称。它可以通过 `hostname` 命令或者调用 libc 中的 [`gethostname`](http://man7.org/linux/man-pages/man2/gethostname.2.html) 函数来获取。 +容器的 *hostname* 是它所运行在的 pod 的名称。它可以通过 `hostname` 命令或者调用 libc 中的 +[`gethostname`](https://man7.org/linux/man-pages/man2/gethostname.2.html) 函数来获取。 -Pod 名称和命名空间可以通过 [downward API](/docs/tasks/inject-data-application/downward-api-volume-expose-pod-information/) 使用环境变量。 +Pod 名称和命名空间可以通过 +[下行 API](/zh/docs/tasks/inject-data-application/downward-api-volume-expose-pod-information/) +转换为环境变量。 Pod 定义中的用户所定义的环境变量也可在容器中使用，就像在 Docker 镜像中静态指定的任何环境变量一样。 @@ -79,19 +88,18 @@ FOO_SERVICE_PORT=<the port the service is running on> Services have dedicated IP addresses and are available to the Container via DNS, if [DNS addon](http://releases.k8s.io/{{< param "githubbranch" >}}/cluster/addons/dns/) is enabled.  --> -Service 具有专用的 IP 地址。如果启用了 [DNS插件](http://releases.k8s.io/{{< param "githubbranch" >}}/cluster/addons/dns/)，就可以在容器中通过 DNS 来访问。 - - +服务具有专用的 IP 地址。如果启用了 +[DNS插件](https://releases.k8s.io/{{< param "githubbranch" >}}/cluster/addons/dns/)， +可以在容器中通过 DNS 来访问服务。 ## {{% heading "whatsnext" %}} - <!-- * Learn more about [Container lifecycle hooks](/docs/concepts/containers/container-lifecycle-hooks/). * Get hands-on experience [attaching handlers to Container lifecycle events](/docs/tasks/configure-pod-container/attach-handler-lifecycle-event/). --> -* 学习更多有关[容器生命周期钩子](/docs/concepts/containers/container-lifecycle-hooks/)的知识。 -* 动手获得经验[将处理程序附加到容器生命周期事件](/docs/tasks/configure-pod-container/attach-handler-lifecycle-event/)。 +* 学习更多有关[容器生命周期回调](/zh/docs/concepts/containers/container-lifecycle-hooks/)的知识 +* 动手[为容器生命周期事件添加处理程序](/zh/docs/tasks/configure-pod-container/attach-handler-lifecycle-event/) diff --git a/content/zh/docs/concepts/containers/container-lifecycle-hooks.md b/content/zh/docs/concepts/containers/container-lifecycle-hooks.md index 14063a4003..0408e7650f 100644 --- a/content/zh/docs/concepts/containers/container-lifecycle-hooks.md +++ b/content/zh/docs/concepts/containers/container-lifecycle-hooks.md @@ -1,12 +1,8 @@ --- -reviewers: -- mikedanese -- thockin -title: 容器生命周期钩子 +title: 容器生命周期回调 content_type: concept weight: 30 --- - <!-- reviewers: - mikedanese @@ -16,45 +12,38 @@ content_type: concept weight: 30 --> - <!-- overview --> <!-- This page describes how kubelet managed Containers can use the Container lifecycle hook framework to run code triggered by events during their management lifecycle. --> -这个页面描述了 kubelet 管理的容器如何使用容器生命周期钩子框架来运行在其管理生命周期中由事件触发的代码。 - - - +这个页面描述了 kubelet 管理的容器如何使用容器生命周期回调框架， +藉由其管理生命周期中的事件触发，运行指定代码。 <!-- body --> <!-- ## Overview ---> -## 概述 - -<!-- Analogous to many programming language frameworks that have component lifecycle hooks, such as Angular, Kubernetes provides Containers with lifecycle hooks. The hooks enable Containers to be aware of events in their management lifecycle and run code implemented in a handler when the corresponding lifecycle hook is executed. --> -类似于许多具有生命周期钩子组件的编程语言框架，例如 Angular、Kubernetes 为容器提供了生命周期钩子。 -钩子使容器能够了解其管理生命周期中的事件，并在执行相应的生命周期钩子时运行在处理程序中实现的代码。 +## 概述 + +类似于许多具有生命周期回调组件的编程语言框架，例如 Angular、Kubernetes 为容器提供了生命周期回调。 +回调使容器能够了解其管理生命周期中的事件，并在执行相应的生命周期回调时运行在处理程序中实现的代码。 <!-- ## Container hooks ---> -## 容器钩子 - -<!-- There are two hooks that are exposed to Containers: --> -有两个钩子暴露在容器中: +## 容器回调 + +有两个回调暴露给容器： `PostStart` @@ -63,8 +52,8 @@ This hook executes immediately after a container is created. However, there is no guarantee that the hook will execute before the container ENTRYPOINT. No parameters are passed to the handler. --> -这个钩子在创建容器之后立即执行。 -但是，不能保证钩子会在容器入口点之前执行。 +这个回调在创建容器之后立即执行。 +但是，不能保证回调会在容器入口点（ENTRYPOINT）之前执行。 没有参数传递给处理程序。 `PreStop` @@ -75,29 +64,29 @@ It is blocking, meaning it is synchronous, so it must complete before the call to delete the container can be sent. No parameters are passed to the handler. --> - -在容器终止之前是否立即调用此钩子，取决于 API 的请求或者管理事件，类似活动探针故障、资源抢占、资源竞争等等。 如果容器已经完全处于终止或者完成状态，则对 preStop 钩子的调用将失败。 -它是阻塞的，同时也是同步的，因此它必须在删除容器的调用之前完成。 +在容器因 API 请求或者管理事件（诸如存活态探针失败、资源抢占、资源竞争等）而被终止之前， +此回调会被调用。 +如果容器已经处于终止或者完成状态，则对 preStop 回调的调用将失败。 +此调用是阻塞的，也是同步调用，因此必须在删除容器的调用之前完成。 没有参数传递给处理程序。 <!-- A more detailed description of the termination behavior can be found in -[Termination of Pods](/docs/concepts/workloads/pods/pod/#termination-of-pods). +[Termination of Pods](/docs/concepts/workloads/pods/pod-lifecycle/#pod-termination). --> -有关终止行为的更详细描述，请参见[终止 Pod](/docs/concepts/workloads/pods/pod/#termination-of-pods)。 +有关终止行为的更详细描述，请参见 +[终止 Pod](/zh/docs/concepts/workloads/pods/pod-lifecycle/#termination-of-pods)。 <!-- ### Hook handler implementations ---> -### 钩子处理程序的实现 - -<!-- Containers can access a hook by implementing and registering a handler for that hook. There are two types of hook handlers that can be implemented for Containers: --> -容器可以通过实现和注册该钩子的处理程序来访问该钩子。 -针对容器，有两种类型的钩子处理程序可供实现： +### 回调处理程序的实现 + +容器可以通过实现和注册该回调的处理程序来访问该回调。 +针对容器，有两种类型的回调处理程序可供实现： <!-- * Exec - Executes a specific command, such as `pre-stop.sh`, inside the cgroups and namespaces of the Container. @@ -105,21 +94,19 @@ Resources consumed by the command are counted against the Container. * HTTP - Executes an HTTP request against a specific endpoint on the Container. --> -* Exec - 执行一个特定的命令，例如 `pre-stop.sh`，在容器的 cgroups 和名称空间中。 -命令所消耗的资源根据容器进行计算。 +* Exec - 在容器的 cgroups 和名称空间中执行特定的命令（例如 `pre-stop.sh`）。 + 命令所消耗的资源计入容器的资源消耗。 * HTTP - 对容器上的特定端点执行 HTTP 请求。 <!-- ### Hook handler execution ---> -### 钩子处理程序执行 - -<!-- When a Container lifecycle management hook is called, the Kubernetes management system executes the handler in the Container registered for that hook.  --> -当调用容器生命周期管理钩子时，Kubernetes 管理系统在为该钩子注册的容器中执行处理程序。 +### 回调处理程序执行 + +当调用容器生命周期管理回调时，Kubernetes 管理系统在注册了回调的容器中执行处理程序。 <!-- Hook handler calls are synchronous within the context of the Pod containing the Container. @@ -128,9 +115,9 @@ the Container ENTRYPOINT and hook fire asynchronously. However, if the hook takes too long to run or hangs, the Container cannot reach a `running` state. --> -钩子处理程序调用在包含容器的 Pod 上下文中是同步的。 -这意味着对于 `PostStart` 钩子，容器入口点和钩子异步触发。 -但是，如果钩子运行或挂起的时间太长，则容器无法达到 `running` 状态。 +回调处理程序调用在包含容器的 Pod 上下文中是同步的。 +这意味着对于 `PostStart` 回调，容器入口点和回调异步触发。 +但是，如果回调运行或挂起的时间太长，则容器无法达到 `running` 状态。 <!-- The behavior is similar for a `PreStop` hook. @@ -139,32 +126,31 @@ the Pod phase stays in a `Terminating` state and is killed after `terminationGra If a `PostStart` or `PreStop` hook fails, it kills the Container. --> -行为与 `PreStop` 钩子的行为类似。 -如果钩子在执行过程中挂起，Pod 阶段将保持在 `Terminating` 状态，并在 Pod 结束的 `terminationGracePeriodSeconds` 之后被杀死。 -如果 `PostStart` 或 `PreStop` 钩子失败，它会杀死容器。 +行为与 `PreStop` 回调的行为类似。 +如果回调在执行过程中挂起，Pod 阶段将保持在 `Terminating` 状态， +并在 Pod 结束的 `terminationGracePeriodSeconds` 之后被杀死。 +如果 `PostStart` 或 `PreStop` 回调失败，它会杀死容器。 <!-- Users should make their hook handlers as lightweight as possible. There are cases, however, when long running commands make sense, such as when saving state prior to stopping a Container. --> -用户应该使他们的钩子处理程序尽可能的轻量级。 +用户应该使他们的回调处理程序尽可能的轻量级。 但也需要考虑长时间运行的命令也很有用的情况，比如在停止容器之前保存状态。 <!-- ### Hook delivery guarantees ---> -### 钩子寄送保证 - -<!-- Hook delivery is intended to be *at least once*, which means that a hook may be called multiple times for any given event, such as for `PostStart` or `PreStop`. It is up to the hook implementation to handle this correctly. --> -钩子的寄送应该是 *至少一次*，这意味着对于任何给定的事件，例如 `PostStart` 或 `PreStop`，钩子可以被调用多次。 -如何正确处理，是钩子实现所要考虑的问题。 +### 回调寄送保证 + +回调的寄送应该是 *至少一次*，这意味着对于任何给定的事件，例如 `PostStart` 或 `PreStop`，回调可以被调用多次。 +如何正确处理，是回调实现所要考虑的问题。 <!-- Generally, only single deliveries are made. @@ -175,17 +161,13 @@ For instance, if a kubelet restarts in the middle of sending a hook, the hook might be resent after the kubelet comes back up. --> 通常情况下，只会进行单次寄送。 -例如，如果 HTTP 钩子接收器宕机，无法接收流量，则不会尝试重新发送。 +例如，如果 HTTP 回调接收器宕机，无法接收流量，则不会尝试重新发送。 然而，偶尔也会发生重复寄送的可能。 -例如，如果 kubelet 在发送钩子的过程中重新启动，钩子可能会在 kubelet 恢复后重新发送。 +例如，如果 kubelet 在发送回调的过程中重新启动，回调可能会在 kubelet 恢复后重新发送。 <!-- ### Debugging Hook handlers ---> -### 调试钩子处理程序 - -<!-- The logs for a Hook handler are not exposed in Pod events. If a handler fails for some reason, it broadcasts an event. For `PostStart`, this is the `FailedPostStartHook` event, @@ -193,7 +175,9 @@ and for `PreStop`, this is the `FailedPreStopHook` event. You can see these events by running `kubectl describe pod <pod_name>`. Here is some example output of events from running this command: --> -钩子处理程序的日志不会在 Pod 事件中公开。 +### 调试回调处理程序 + +回调处理程序的日志不会在 Pod 事件中公开。 如果处理程序由于某种原因失败，它将播放一个事件。 对于 `PostStart`，这是 `FailedPostStartHook` 事件，对于 `PreStop`，这是 `FailedPreStopHook` 事件。 您可以通过运行 `kubectl describe pod <pod_name>` 命令来查看这些事件。 @@ -214,18 +198,14 @@ Events: 1m 22s 2 {kubelet gke-test-cluster-default-pool-a07e5d30-siqd} spec.containers{main} Warning FailedPostStartHook ``` - - ## {{% heading "whatsnext" %}} - <!-- -* Learn more about the [Container environment](/docs/concepts/containers/container-environment-variables/). +* Learn more about the [Container environment](/docs/concepts/containers/container-environment/). * Get hands-on experience [attaching handlers to Container lifecycle events](/docs/tasks/configure-pod-container/attach-handler-lifecycle-event/). --> -* 了解更多关于[容器环境](/docs/concepts/containers/container-environment-variables/)。 -* 获取实践经验[将处理程序附加到容器生命周期事件](/docs/tasks/configure-pod-container/attach-handler-lifecycle-event/)。 - +* 进一步了解[容器环境](/zh/docs/concepts/containers/container-environment/) +* 动手实践，[为容器生命周期事件添加处理程序](/zh/docs/tasks/configure-pod-container/attach-handler-lifecycle-event/) diff --git a/content/zh/docs/concepts/containers/images.md b/content/zh/docs/concepts/containers/images.md index cde48800a3..8622ff532e 100644 --- a/content/zh/docs/concepts/containers/images.md +++ b/content/zh/docs/concepts/containers/images.md @@ -33,7 +33,7 @@ The `image` property of a container supports the same syntax as the `docker` com <!-- ## Updating Images --> -## 升级镜像 +## 更新镜像 {#updating-images} <!-- The default pull policy is `IfNotPresent` which causes the Kubelet to skip diff --git a/content/zh/docs/concepts/containers/overview.md b/content/zh/docs/concepts/containers/overview.md index 15c881bd51..713cc4e7ac 100644 --- a/content/zh/docs/concepts/containers/overview.md +++ b/content/zh/docs/concepts/containers/overview.md @@ -46,7 +46,7 @@ the change, then recreate the container to start from the updated image. <!-- ## Container runtimes --> -##容器运行时 +## 容器运行时 {{< glossary_definition term_id="container-runtime" length="all" >}} diff --git a/content/zh/docs/concepts/containers/runtime-class.md b/content/zh/docs/concepts/containers/runtime-class.md index 693e156cc3..4e1178670b 100644 --- a/content/zh/docs/concepts/containers/runtime-class.md +++ b/content/zh/docs/concepts/containers/runtime-class.md @@ -1,11 +1,16 @@ --- -reviewers: -- tallclair -- dchen1107 title: 容器运行时类(Runtime Class) content_type: concept weight: 20 --- +<!-- +reviewers: +- tallclair +- dchen1107 +title: Runtime Class +content_type: concept +weight: 20 +--> <!-- overview --> @@ -13,26 +18,19 @@ weight: 20 <!-- This page describes the RuntimeClass resource and runtime selection mechanism. ---> -本页面描述了 RuntimeClass 资源和运行时的选择机制。 -<!-- RuntimeClass is a feature for selecting the container runtime configuration. The container runtime configuration is used to run a Pod's containers. --> +本页面描述了 RuntimeClass 资源和运行时的选择机制。 + RuntimeClass 是一个用于选择容器运行时配置的特性，容器运行时配置用于运行 Pod 中的容器。 - - - <!-- body --> <!-- ## Motivation - --> -## 动机 -<!-- You can set a different RuntimeClass between different Pods to provide a balance of performance versus security. For example, if part of your workload deserves a high level of information security assurance, you might choose to schedule those Pods so @@ -40,37 +38,37 @@ that they run in a container runtime that uses hardware virtualization. You'd th benefit from the extra isolation of the alternative runtime, at the expense of some additional overhead. --> -您可以在不同的 pod 之间设置不同的 RuntimeClass，以提供性能与安全性之间的平衡。 -例如，如果您的部分工作负载需要高级别的信息安全保证，那么您可以选择性地调度这些 pod， -使它们在使用硬件虚拟化的容器运行时中运行。 -然后，您将从可选运行时的额外隔离中获益，代价是一些额外的开销。 +## 动机 {#motivation} + +你可以在不同的 Pod 设置不同的 RuntimeClass，以提供性能与安全性之间的平衡。 +例如，如果你的部分工作负载需要高级别的信息安全保证，你可以决定在调度这些 Pod +时尽量使它们在使用硬件虚拟化的容器运行时中运行。 +这样，你将从这些不同运行时所提供的额外隔离中获益，代价是一些额外的开销。 <!-- You can also use RuntimeClass to run different Pods with the same container runtime but with different settings. --> -您还可以使用 RuntimeClass 运行具有相同容器运行时但具有不同设置的pod。 +你还可以使用 RuntimeClass 运行具有相同容器运行时但具有不同设置的 Pod。 <!-- ## Setup ---> -## 设置 -<!-- Ensure the RuntimeClass feature gate is enabled (it is by default). See [Feature Gates](/docs/reference/command-line-tools-reference/feature-gates/) for an explanation of enabling feature gates. The `RuntimeClass` feature gate must be enabled on apiservers _and_ kubelets. --> +## 设置 {#setup} + 确保 RuntimeClass 特性开关处于开启状态（默认为开启状态）。 -关于特性开关的详细介绍，请查阅 -[Feature Gates](/docs/reference/command-line-tools-reference/feature-gates/)。 -`RuntimeClass` 特性开关必须在 apiserver 和 kubelet 同时开启。 +关于特性开关的详细介绍，请参阅 +[特性门控](/zh/docs/reference/command-line-tools-reference/feature-gates/)。 +`RuntimeClass` 特性开关必须在 API 服务器和 kubelet 端同时开启。 <!-- 1. Configure the CRI implementation on nodes (runtime dependent) 2. Create the corresponding RuntimeClass resources --> - 1. 在节点上配置 CRI 的实现（取决于所选用的运行时） 2. 创建相应的 RuntimeClass 资源 @@ -87,11 +85,12 @@ CRI implementation for how to configure. RuntimeClass 的配置依赖于 运行时接口（CRI）的实现。 根据你使用的 CRI 实现，查阅相关的文档（[下方](#cri-configuration)）来了解如何配置。 -{{< note >}} <!-- RuntimeClass assumes a homogeneous node configuration across the cluster by default (which means that all nodes are configured the same way with respect to container runtimes). To support -heterogenous node configurations, see [Scheduling](#scheduling) below.--> +heterogenous node configurations, see [Scheduling](#scheduling) below. +--> +{{< note >}} RuntimeClass 假设集群中的节点配置是同构的（换言之，所有的节点在容器运行时方面的配置是相同的）。 如果需要支持异构节点，配置方法请参阅下面的 [调度](#scheduling)。 {{< /note >}} @@ -105,13 +104,12 @@ handler 必须符合 DNS-1123 命名规范（字母、数字、或 `-`）。 <!-- ### 2. Create the corresponding RuntimeClass resources ---> -### 2. 创建相应的 RuntimeClass 资源 -<!-- The configurations setup in step 1 should each have an associated `handler` name, which identifies the configuration. For each handler, create a corresponding RuntimeClass object. --> +### 2. 创建相应的 RuntimeClass 资源 + 在上面步骤 1 中，每个配置都需要有一个用于标识配置的 `handler`。 针对每个 handler 需要创建一个 RuntimeClass 对象。 @@ -123,31 +121,32 @@ RuntimeClass 资源当前只有两个重要的字段：RuntimeClass 名 (`metada 对象定义如下所示： ```yaml -apiVersion: node.k8s.io/v1beta1 # RuntimeClass is defined in the node.k8s.io API group +apiVersion: node.k8s.io/v1beta1 # RuntimeClass 定义于 node.k8s.io API 组 kind: RuntimeClass metadata: - name: myclass # The name the RuntimeClass will be referenced by - # RuntimeClass is a non-namespaced resource -handler: myconfiguration # The name of the corresponding CRI configuration + name: myclass # 用来引用 RuntimeClass 的名字 + # RuntimeClass 是一个集群层面的资源 +handler: myconfiguration # 对应的 CRI 配置的名称 ``` -{{< note >}} <!-- It is recommended that RuntimeClass write operations (create/update/patch/delete) be restricted to the cluster administrator. This is typically the default. See [Authorization -Overview](/docs/reference/access-authn-authz/authorization/) for more details.-->建议将 RuntimeClass 写操作（create、update、patch 和 delete）限定于集群管理员使用。 -通常这是默认配置。参阅[授权概述](/docs/reference/access-authn-authz/authorization/)了解更多信息。 +Overview](/docs/reference/access-authn-authz/authorization/) for more details. +--> +{{< note >}} +建议将 RuntimeClass 写操作（create、update、patch 和 delete）限定于集群管理员使用。 +通常这是默认配置。参阅[授权概述](/zh/docs/reference/access-authn-authz/authorization/)了解更多信息。 {{< /note >}} <!-- ## Usage ---> -## 使用说明 -<!-- Once RuntimeClasses are configured for the cluster, using them is very simple. Specify a `runtimeClassName` in the Pod spec. For example: --> +## 使用说明 {#usage} + 一旦完成集群中 RuntimeClasses 的配置，使用起来非常方便。 在 Pod spec 中指定 `runtimeClassName` 即可。例如: @@ -168,9 +167,11 @@ RuntimeClass does not exist, or the CRI cannot run the corresponding handler, th corresponding [event](/docs/tasks/debug-application-cluster/debug-application-introspection/) for an error message. --> -这一设置会告诉 Kubelet 使用所指的 RuntimeClass 来运行该 pod。 -如果所指的 RuntimeClass 不存在或者 CRI 无法运行相应的 handler，那么 pod 将会进入 `Failed` 终止[阶段](/docs/concepts/workloads/pods/pod-lifecycle/#pod-phase)。 -你可以查看相应的[事件](/docs/tasks/debug-application-cluster/debug-application-introspection/)，获取出错信息。 +这一设置会告诉 kubelet 使用所指的 RuntimeClass 来运行该 pod。 +如果所指的 RuntimeClass 不存在或者 CRI 无法运行相应的 handler， +那么 pod 将会进入 `Failed` 终止[阶段](/zh/docs/concepts/workloads/pods/pod-lifecycle/#pod-phase)。 +你可以查看相应的[事件](/zh/docs/tasks/debug-application-cluster/debug-application-introspection/)， +获取出错信息。 <!-- If no `runtimeClassName` is specified, the default RuntimeHandler will be used, which is equivalent @@ -180,20 +181,20 @@ to the behavior when the RuntimeClass feature is disabled. <!-- ### CRI Configuration - --> -### CRI 配置 -<!-- For more details on setting up CRI runtimes, see [CRI installation](/docs/setup/production-environment/container-runtimes/). --> -关于如何安装 CRI 运行时，请查阅 [CRI 安装](/docs/setup/production-environment/container-runtimes/)。 +### CRI 配置 {#cri-configuration} + +关于如何安装 CRI 运行时，请查阅 +[CRI 安装](/zh/docs/setup/production-environment/container-runtimes/)。 #### dockershim <!-- Kubernetes built-in dockershim CRI does not support runtime handlers. --> -Kubernetes 内置 dockershim CRI 不支持配置运行时 handler。 +Kubernetes 内置的 dockershim CRI 不支持配置运行时 handler。 #### [containerd](https://containerd.io/) @@ -223,8 +224,9 @@ handlers are configured under the [crio.runtime table](https://github.com/kubernetes-sigs/cri-o/blob/master/docs/crio.conf.5.md#crioruntime-table): --> 通过 cri-o 的 `/etc/crio/crio.conf` 配置文件来配置运行时 handler。 -handler 需要配置在 [crio.runtime 表](https://github.com/kubernetes-sigs/cri-o/blob/master/docs/crio.conf.5.md#crioruntime-table) -下方： +handler 需要配置在 +[crio.runtime 表](https://github.com/kubernetes-sigs/cri-o/blob/master/docs/crio.conf.5.md#crioruntime-table) +下面： ``` [crio.runtime.runtimes.${HANDLER_NAME}] @@ -232,16 +234,14 @@ handler 需要配置在 [crio.runtime 表](https://github.com/kubernetes-sigs/cr ``` <!-- -See cri-o's config documentation for more details: -https://github.com/kubernetes-sigs/cri-o/blob/master/cmd/crio/config.go +See CRI-O's [config documentation](https://raw.githubusercontent.com/cri-o/cri-o/9f11d1d/docs/crio.conf.5.md) for more details. --> -更详细信息，请查阅 containerd 配置文档： -https://github.com/kubernetes-sigs/cri-o/blob/master/cmd/crio/config.go +更详细信息，请查阅 CRI-O [配置文档](https://raw.githubusercontent.com/cri-o/cri-o/9f11d1d/docs/crio.conf.5.md)。 <!-- ## Scheduling --> -## 调度 +## 调度 {#scheduling} {{< feature-state for_k8s_version="v1.16" state="beta" >}} @@ -253,7 +253,9 @@ the [RuntimeClass admission controller][] enabled (the default, as of 1.16). --> 在 Kubernetes v1.16 版本里，RuntimeClass 特性引入了 `scheduling` 字段来支持异构集群。 通过该字段，可以确保 pod 被调度到支持指定运行时的节点上。 -该调度支持，需要确保 [RuntimeClass admission controller][] 处于开启状态（1.16 版本默认开启）。 +该调度支持，需要确保 +[RuntimeClass 准入控制器](/zh/docs/reference/access-authn-authz/admission-controllers/#runtimeclass) +处于开启状态（1.16 版本默认开启）。 <!-- To ensure pods land on nodes supporting a specific RuntimeClass, that set of nodes should have a @@ -280,14 +282,12 @@ To learn more about configuring the node selector and tolerations, see [Assignin Nodes](/docs/concepts/configuration/assign-pod-node/). --> 更多有关 node selector 和 tolerations 的配置信息，请查阅 -[Assigning Pods to Nodes](/docs/concepts/configuration/assign-pod-node/)。 - -[RuntimeClass admission controller]: /docs/reference/access-authn-authz/admission-controllers/ +[将 Pod 分派到节点](/zh/docs/concepts/scheduling-eviction/assign-pod-node/)。 <!-- ### Pod Overhead --> -### Pod 开销 +### Pod 开销 {#pod-overhead} {{< feature-state for_k8s_version="v1.18" state="beta" >}} @@ -298,19 +298,20 @@ To use Pod overhead, you must have the PodOverhead [feature gate](/docs/referenc enabled (it is on by default). --> 你可以指定与运行 Pod 相关的 _开销_ 资源。声明开销即允许集群（包括调度器）在决策 Pod 和资源时将其考虑在内。 -若要使用 Pod 开销特性，你必须确保 PodOverhead [特性开关](/docs/reference/command-line-tools-reference/feature-gates/) 处于开启状态（默认为启用状态）。 +若要使用 Pod 开销特性，你必须确保 PodOverhead +[特性门控](/zh/docs/reference/command-line-tools-reference/feature-gates/) +处于启用状态（默认为启用状态）。 <!-- Pod overhead is defined in RuntimeClass through the `Overhead` fields. Through the use of these fields, you can specify the overhead of running pods utilizing this RuntimeClass and ensure these overheads are accounted for in Kubernetes. --> -Pod 开销通过 RuntimeClass 的 `overhead` 字段定义。通过使用这些字段，你可以指定使用该 RuntimeClass 运行 Pod 时的开销并确保 Kubernetes 将这些开销计算在内。 - +Pod 开销通过 RuntimeClass 的 `overhead` 字段定义。 +通过使用这些字段，你可以指定使用该 RuntimeClass 运行 Pod 时的开销并确保 Kubernetes 将这些开销计算在内。 ## {{% heading "whatsnext" %}} - <!-- - [RuntimeClass Design](https://github.com/kubernetes/enhancements/blob/master/keps/sig-node/runtime-class.md) - [RuntimeClass Scheduling Design](https://github.com/kubernetes/enhancements/blob/master/keps/sig-node/runtime-class-scheduling.md) @@ -319,7 +320,7 @@ Pod 开销通过 RuntimeClass 的 `overhead` 字段定义。通过使用这些 --> - [RuntimeClass 设计](https://github.com/kubernetes/enhancements/blob/master/keps/sig-node/runtime-class.md) - [RuntimeClass 调度设计](https://github.com/kubernetes/enhancements/blob/master/keps/sig-node/runtime-class-scheduling.md) -- 阅读关于 [Pod 开销](/docs/concepts/configuration/pod-overhead/) 的概念 +- 阅读关于 [Pod 开销](/zh/docs/concepts/configuration/pod-overhead/) 的概念 - [PodOverhead 特性设计](https://github.com/kubernetes/enhancements/blob/master/keps/sig-node/20190226-pod-overhead.md) diff --git a/content/zh/docs/concepts/example-concept-template.md b/content/zh/docs/concepts/example-concept-template.md deleted file mode 100644 index c88d280c9c..0000000000 --- a/content/zh/docs/concepts/example-concept-template.md +++ /dev/null @@ -1,76 +0,0 @@ ---- -title: 概念模板示例 -content_type: concept -toc_hide: true ---- - -<!-- ---- -title: Example Concept Template -content_type: concept -toc_hide: true ---- ---> - -<!-- overview --> - -<!-- -Be sure to also [create an entry in the table of contents](/docs/home/contribute/write-new-topic/#creating-an-entry-in-the-table-of-contents) for your new document. ---> - -{{< note >}} -确保您的新文档也可以[在目录中创建一个条目](/docs/home/contribute/write-new-topic/#creating-an-entry-in-the-table-of-contents)。 -{{< /note >}} - -<!-- -This page explains ... ---> - -本页解释了 ... - - - -<!-- body --> - -<!-- -## Understanding ... ---> -## 了解 ... - -<!-- -Kubernetes provides ... ---> -Kubernetes 提供 ... - -<!-- -## Using ... ---> -## 使用 ... - -<!-- -To use ... ---> -使用 ... - - - -## {{% heading "whatsnext" %}} - - - -<!-- -**[Optional Section]** ---> -**[可选章节]** - - -<!-- -* Learn more about [Writing a New Topic](/docs/home/contribute/write-new-topic/). -* See [Using Page Templates - Concept template](/docs/home/contribute/page-templates/#concept_template) for how to use this template. ---> -* 了解有关[撰写新主题](/docs/home/contribute/write-new-topic/)的更多信息。 -* 有关如何使用此模板的信息，请参阅[使用页面模板 - 概念模板](/docs/home/contribute/page-templates/#concept_template)。 - - - - diff --git a/content/zh/docs/concepts/extend-kubernetes/_index.md b/content/zh/docs/concepts/extend-kubernetes/_index.md index c52f4624e6..e79067baad 100644 --- a/content/zh/docs/concepts/extend-kubernetes/_index.md +++ b/content/zh/docs/concepts/extend-kubernetes/_index.md @@ -1,4 +1,454 @@ --- title: 扩展 Kubernetes -weight: 40 +weight: 110 +description: 改变你的 Kubernetes 集群的行为的若干方法。 +content_type: concept +no_list: true --- +<!-- +title: Extending Kubernetes +weight: 110 +description: Different ways to change the behavior of your Kubernetes cluster. +reviewers: +- erictune +- lavalamp +- cheftako +- chenopis +content_type: concept +no_list: true +--> + +<!-- overview --> + +<!-- +Kubernetes is highly configurable and extensible. As a result, +there is rarely a need to fork or submit patches to the Kubernetes +project code. + +This guide describes the options for customizing a Kubernetes +cluster. It is aimed at {{< glossary_tooltip text="cluster operators" term_id="cluster-operator" >}} who want to +understand how to adapt their Kubernetes cluster to the needs of +their work environment. Developers who are prospective {{< glossary_tooltip text="Platform Developers" term_id="platform-developer" >}} or Kubernetes Project {{< glossary_tooltip text="Contributors" term_id="contributor" >}} will also find it +useful as an introduction to what extension points and patterns +exist, and their trade-offs and limitations. +--> +Kubernetes 是高度可配置且可扩展的。因此，大多数情况下，你不需要 +派生自己的 Kubernetes 副本或者向项目代码提交补丁。 + +本指南描述定制 Kubernetes 的可选方式。主要针对的读者是希望了解如何针对自身工作环境 +需要来调整 Kubernetes 的{{< glossary_tooltip text="集群管理者" term_id="cluster-operator" >}}。 +对于那些充当{{< glossary_tooltip text="平台开发人员" term_id="platform-developer" >}} +的开发人员或 Kubernetes 项目的{{< glossary_tooltip text="贡献者" term_id="contributor" >}} +而言，他们也会在本指南中找到有用的介绍信息，了解系统中存在哪些扩展点和扩展模式， +以及它们所附带的各种权衡和约束等等。 + +<!-- body --> + +<!-- +## Overview + +Customization approaches can be broadly divided into *configuration*, which only involves changing flags, local configuration files, or API resources; and *extensions*, which involve running additional programs or services. This document is primarily about extensions. +--> +## 概述 {#overview} + +定制化的方法主要可分为 *配置（Configuration）* 和 *扩展（Extensions）* 两种。 +前者主要涉及改变参数标志、本地配置文件或者 API 资源； +后者则需要额外运行一些程序或服务。 +本文主要关注扩展。 + +<!-- +## Configuration + +*Configuration files* and *flags* are documented in the Reference section of the online documentation, under each binary: + +* [kubelet](/docs/reference/command-line-tools-reference/kubelet/) +* [kube-apiserver](/docs/reference/command-line-tools-reference/kube-apiserver/) +* [kube-controller-manager](/docs/reference/command-line-tools-reference/kube-controller-manager/) +* [kube-scheduler](/docs/reference/command-line-tools-reference/kube-scheduler/). +--> + +## Configuration + +*配置文件*和*参数标志*的说明位于在线文档的参考章节，按可执行文件组织： + +* [kubelet](/zh/docs/reference/command-line-tools-reference/kubelet/) +* [kube-apiserver](/zh/docs/reference/command-line-tools-reference/kube-apiserver/) +* [kube-controller-manager](/zh/docs/reference/command-line-tools-reference/kube-controller-manager/) +* [kube-scheduler](/zh/docs/reference/command-line-tools-reference/kube-scheduler/). + +<!-- +Flags and configuration files may not always be changeable in a hosted Kubernetes service or a distribution with managed installation. When they are changeable, they are usually only changeable by the cluster administrator. Also, they are subject to change in future Kubernetes versions, and setting them may require restarting processes. For those reasons, they should be used only when there are no other options. +--> +在托管的 Kubernetes 服务中或者受控安装的发行版本中，参数标志和配置文件不总是可以 +修改的。即使它们是可修改的，通常其修改权限也仅限于集群管理员。 +此外，这些内容在将来的 Kubernetes 版本中很可能发生变化，设置新参数或配置文件可能 +需要重启进程。 +有鉴于此，通常应该在没有其他替代方案时才应考虑更改参数标志和配置文件。 + +<!-- +*Built-in Policy APIs*, such as [ResourceQuota](/docs/concepts/policy/resource-quotas/), [PodSecurityPolicies](/docs/concepts/policy/pod-security-policy/), [NetworkPolicy](/docs/concepts/services-networking/network-policies/) and Role-based Access Control ([RBAC](/docs/reference/access-authn-authz/rbac/)), are built-in Kubernetes APIs. APIs are typically used with hosted Kubernetes services and with managed Kubernetes installations. They are declarative and use the same conventions as other Kubernetes resources like pods, so new cluster configuration can be repeatable and be managed the same way as applications. And, where they are stable, they enjoy a [defined support policy](/docs/reference/deprecation-policy/) like other Kubernetes APIs. For these reasons, they are preferred over *configuration files* and *flags* where suitable. +--> +*内置的策略 API*，例如[ResourceQuota](/zh/docs/concepts/policy/resource-quotas/)、 +[PodSecurityPolicies](/zh/docs/concepts/policy/pod-security-policy/)、 +[NetworkPolicy](/zh/docs/concepts/services-networking/network-policies/) +和基于角色的访问控制（[RBAC](/zh/docs/reference/access-authn-authz/rbac/)）等等 +都是内置的 Kubernetes API。 +API 通常用于托管的 Kubernetes 服务和受控的 Kubernetes 安装环境中。 +这些 API 是声明式的，与 Pod 这类其他 Kubernetes 资源遵从相同的约定，所以 +新的集群配置是可复用的，并且可以当作应用程序来管理。 +此外，对于稳定版本的 API 而言，它们与其他 Kubernetes API 一样，采纳的是 +一种[预定义的支持策略](/zh/docs/reference/using-api/deprecation-policy/)。 +出于以上原因，在条件允许的情况下，基于 API 的方案应该优先于*配置文件*和*参数标志*。 + +<!-- +## Extensions + +Extensions are software components that extend and deeply integrate with Kubernetes. +They adapt it to support new types and new kinds of hardware. + +Most cluster administrators will use a hosted or distribution +instance of Kubernetes. As a result, most Kubernetes users will not need to +install extensions and fewer will need to author new ones. +--> +## 扩展 {#extensions} + +扩展（Extensions）是一些扩充 Kubernetes 能力并与之深度集成的软件组件。 +它们调整 Kubernetes 的工作方式使之支持新的类型和新的硬件种类。 + +大多数集群管理员会使用一种托管的 Kubernetes 服务或者其某种发行版本。 +因此，大多数 Kubernetes 用户不需要安装扩展， +至于需要自己编写新的扩展的情况就更少了。 + +<!-- +## Extension Patterns + +Kubernetes is designed to be automated by writing client programs. Any +program that reads and/or writes to the Kubernetes API can provide useful +automation. *Automation* can run on the cluster or off it. By following +the guidance in this doc you can write highly available and robust automation. +Automation generally works with any Kubernetes cluster, including hosted +clusters and managed installations. +--> +## 扩展模式 {#extension-patterns} + +Kubernetes 从设计上即支持通过编写客户端程序来将其操作自动化。 +任何能够对 Kubernetes API 发出读写指令的程序都可以提供有用的自动化能力。 +*自动化组件*可以运行在集群上，也可以运行在集群之外。 +通过遵从本文中的指南，你可以编写高度可用的、运行稳定的自动化组件。 +自动化组件通常可以用于所有 Kubernetes 集群，包括托管的集群和受控的安装环境。 + +<!-- +There is a specific pattern for writing client programs that work well with +Kubernetes called the *Controller* pattern. Controllers typically read an +object's `.spec`, possibly do things, and then update the object's `.status`. + +A controller is a client of Kubernetes. When Kubernetes is the client and +calls out to a remote service, it is called a *Webhook*. The remote service +is called a *Webhook Backend*. Like Controllers, Webhooks do add a point of +failure. +--> +编写客户端程序有一种特殊的*Controller（控制器）*模式，能够与 Kubernetes 很好地 +协同工作。控制器通常会读取某个对象的 `.spec`，或许还会执行一些操作，之后更新 +对象的 `.status`。 + +控制器是 Kubernetes 的客户端。当 Kubernetes 充当客户端，调用某远程服务时，对应 +的远程组件称作*Webhook*。 远程服务称作*Webhook 后端*。 +与控制器模式相似，Webhook 也会在整个架构中引入新的失效点（Point of Failure）。 + +<!-- +In the webhook model, Kubernetes makes a network request to a remote service. +In the *Binary Plugin* model, Kubernetes executes a binary (program). +Binary plugins are used by the kubelet (e.g. [Flex Volume +Plugins](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-storage/flexvolume.md) +and [Network +Plugins](/docs/concepts/cluster-administration/network-plugins/)) +and by kubectl. + +Below is a diagram showing how the extension points interact with the +Kubernetes control plane. +--> +在 Webhook 模式中，Kubernetes 向远程服务发起网络请求。 +在*可执行文件插件（Binary Plugin）*模式中，Kubernetes 执行某个可执行文件（程序）。 +可执行文件插件在 kubelet （例如， +[FlexVolume 插件](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-storage/flexvolume.md) +和[网络插件](/zh/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/)） +和 kubectl 中使用。 + +下面的示意图中展示了这些扩展点如何与 Kubernetes 控制面交互。 + +<img src="https://docs.google.com/drawings/d/e/2PACX-1vQBRWyXLVUlQPlp7BvxvV9S1mxyXSM6rAc_cbLANvKlu6kCCf-kGTporTMIeG5GZtUdxXz1xowN7RmL/pub?w=960&h=720"> + +<!-- image source drawing https://docs.google.com/drawings/d/1muJ7Oxuj_7Gtv7HV9-2zJbOnkQJnjxq-v1ym_kZfB-4/edit?ts=5a01e054 --> + +<!-- +## Extension Points + +This diagram shows the extension points in a Kubernetes system. +--> +## 扩展点 {#extension-points} + +此示意图显示的是 Kubernetes 系统中的扩展点。 + +<img src="https://docs.google.com/drawings/d/e/2PACX-1vSH5ZWUO2jH9f34YHenhnCd14baEb4vT-pzfxeFC7NzdNqRDgdz4DDAVqArtH4onOGqh0bhwMX0zGBb/pub?w=425&h=809"> + +<!-- image source diagrams: https://docs.google.com/drawings/d/1k2YdJgNTtNfW7_A8moIIkij-DmVgEhNrn3y2OODwqQQ/view --> + +<!-- +1. Users often interact with the Kubernetes API using `kubectl`. [Kubectl plugins](/docs/tasks/extend-kubectl/kubectl-plugins/) extend the kubectl binary. They only affect the individual user's local environment, and so cannot enforce site-wide policies. +2. The apiserver handles all requests. Several types of extension points in the apiserver allow authenticating requests, or blocking them based on their content, editing content, and handling deletion. These are described in the [API Access Extensions](/docs/concepts/overview/extending#api-access-extensions) section. +3. The apiserver serves various kinds of *resources*. *Built-in resource kinds*, like `pods`, are defined by the Kubernetes project and can't be changed. You can also add resources that you define, or that other projects have defined, called *Custom Resources*, as explained in the [Custom Resources](/docs/concepts/overview/extending#user-defined-types) section. Custom Resources are often used with API Access Extensions. +4. The Kubernetes scheduler decides which nodes to place pods on. There are several ways to extend scheduling. These are described in the [Scheduler Extensions](/docs/concepts/overview/extending#scheduler-extensions) section. +5. Much of the behavior of Kubernetes is implemented by programs called Controllers which are clients of the API-Server. Controllers are often used in conjunction with Custom Resources. +6. The kubelet runs on servers, and helps pods appear like virtual servers with their own IPs on the cluster network. [Network Plugins](/docs/concepts/overview/extending#network-plugins) allow for different implementations of pod networking. +7. The kubelet also mounts and unmounts volumes for containers. New types of storage can be supported via [Storage Plugins](/docs/concepts/overview/extending#storage-plugins). + +If you are unsure where to start, this flowchart can help. Note that some solutions may involve several types of extensions. +--> +1. 用户通常使用 `kubectl` 与 Kubernetes API 交互。 + [kubectl 插件](/zh/docs/tasks/extend-kubectl/kubectl-plugins/)能够扩展 kubectl 程序的行为。 + 这些插件只会影响到每个用户的本地环境，因此无法用来强制实施整个站点范围的策略。 + +2. API 服务器处理所有请求。API 服务器中的几种扩展点能够使用户对请求执行身份认证、 + 基于其内容阻止请求、编辑请求内容、处理删除操作等等。 + 这些扩展点在 [API 访问扩展](#api-access-extensions) + 节详述。 + +3. API 服务器向外提供不同类型的*资源（resources）*。 + *内置的资源类型*，如 `pods`，是由 Kubernetes 项目所定义的，无法改变。 + 你也可以添加自己定义的或者其他项目所定义的称作*自定义资源（Custom Resources）* + 的资源，正如[自定义资源](#user-defined-types)节所描述的那样。 + 自定义资源通常与 API 访问扩展点结合使用。 + +4. Kubernetes 调度器负责决定 Pod 要放置到哪些节点上执行。 + 有几种方式来扩展调度行为。这些方法将在 + [调度器扩展](#scheduler-extensions)节中展开。 + +5. Kubernetes 中的很多行为都是通过称为控制器（Controllers）的程序来实现的，这些程序也都是 API 服务器 + 的客户端。控制器常常与自定义资源结合使用。 + +6. 组件 kubelet 运行在各个节点上，帮助 Pod 展现为虚拟的服务器并在集群网络中拥有自己的 IP。 + [网络插件](#network-plugins)使得 Kubernetes 能够采用 + 不同实现技术来连接 Pod 网络。 + +7. 组件 kubelet 也会为容器增加或解除存储卷的挂载。 + 通过[存储插件](#storage-plugins)，可以支持新的存储类型。 + +如果你无法确定从何处入手，下面的流程图可能对你有些帮助。 +注意，某些方案可能需要同时采用几种类型的扩展。 + +<img src="https://docs.google.com/drawings/d/e/2PACX-1vRWXNNIVWFDqzDY0CsKZJY3AR8sDeFDXItdc5awYxVH8s0OLherMlEPVUpxPIB1CSUu7GPk7B2fEnzM/pub?w=1440&h=1080"> + +<!-- image source drawing: https://docs.google.com/drawings/d/1sdviU6lDz4BpnzJNHfNpQrqI9F19QZ07KnhnxVrp2yg/edit --> + +<!-- +## API Extensions +### User-Defined Types + +Consider adding a Custom Resource to Kubernetes if you want to define new controllers, application configuration objects or other declarative APIs, and to manage them using Kubernetes tools, such as `kubectl`. + +Do not use a Custom Resource as data storage for application, user, or monitoring data. + +For more about Custom Resources, see the [Custom Resources concept guide](/docs/concepts/extend-kubernetes/api-extension/custom-resources/). +--> +## API 扩展 {#api-extensions} + +### 用户定义的类型 {#user-defined-types} + +如果你想要定义新的控制器、应用配置对象或者其他声明式 API，并且使用 Kubernetes +工具（如 `kubectl`）来管理它们，可以考虑向 Kubernetes 添加自定义资源。 + +不要使用自定义资源来充当应用、用户或者监控数据的数据存储。 + +关于自定义资源的更多信息，可参见[自定义资源概念指南](/zh/docs/concepts/extend-kubernetes/api-extension/custom-resources/)。 + +<!-- +### Combining New APIs with Automation + +The combination of a custom resource API and a control loop is called the [Operator pattern](/docs/concepts/extend-kubernetes/operator/). The Operator pattern is used to manage specific, usually stateful, applications. These custom APIs and control loops can also be used to control other resources, such as storage or policies. +--> +### 结合使用新 API 与自动化组件 {#combinding-new-apis-with-automation} + +自定义资源 API 与控制回路的组合称作 +[Operator 模式](/zh/docs/concepts/extend-kubernetes/operator/)。 +Operator 模式用来管理特定的、通常是有状态的应用。 +这些自定义 API 和控制回路也可用来控制其他资源，如存储或策略。 + +<!-- +### Changing Built-in Resources + +When you extend the Kubernetes API by adding custom resources, the added resources always fall into a new API Groups. You cannot replace or change existing API groups. +Adding an API does not directly let you affect the behavior of existing APIs (e.g. Pods), but API Access Extensions do. +--> +### 更改内置资源 {#changing-built-in-resources} + +当你通过添加自定义资源来扩展 Kubernetes 时，所添加的资源通常会被放在一个新的 +API 组中。你不可以替换或更改现有的 API 组。 +添加新的 API 不会直接让你影响现有 API （如 Pods）的行为，不过 API +访问扩展能够实现这点。 + +<!-- +### API Access Extensions + +When a request reaches the Kubernetes API Server, it is first Authenticated, then Authorized, then subject to various types of Admission Control. See [Controlling Access to the Kubernetes API](/docs/reference/access-authn-authz/controlling-access/) for more on this flow. + +Each of these steps offers extension points. + +Kubernetes has several built-in authentication methods that it supports. It can also sit behind an authenticating proxy, and it can send a token from an Authorization header to a remote service for verification (a webhook). All of these methods are covered in the [Authentication documentation](/docs/reference/access-authn-authz/authentication/). +--> +### API 访问扩展 {#api-access-extensions} + +当请求到达 Kubernetes API 服务器时，首先要经过身份认证，之后是鉴权操作， +再之后要经过若干类型的准入控制器的检查。 +参见[控制 Kubernetes API 访问](/zh/docs/reference/access-authn-authz/controlling-access/) +以了解此流程的细节。 + +这些步骤中都存在扩展点。 + +Kubernetes 提供若干内置的身份认证方法。 +它也可以运行在某中身份认证代理的后面，并且可以将来自鉴权头部的令牌发送到 +某个远程服务（Webhook）来执行验证操作。 +所有这些方法都在[身份认证文档](/zh/docs/reference/access-authn-authz/authentication/) +中详细论述。 + +<!-- +### Authentication + +[Authentication](/docs/reference/access-authn-authz/authentication/) maps headers or certificates in all requests to a username for the client making the request. + +Kubernetes provides several built-in authentication methods, and an [Authentication webhook](/docs/reference/access-authn-authz/authentication/#webhook-token-authentication) method if those don't meet your needs. +--> +### 身份认证 {#authentication} + +[身份认证](/zh/docs/reference/access-authn-authz/authentication/)负责将所有请求中 +的头部或证书映射到发出该请求的客户端的用户名。 + +Kubernetes 提供若干种内置的认证方法，以及 +[认证 Webhook](/zh/docs/reference/access-authn-authz/authentication/#webhook-token-authentication) +方法以备内置方法无法满足你的要求。 + +<!-- +### Authorization + +[Authorization](/docs/reference/access-authn-authz/webhook/) determines whether specific users can read, write, and do other operations on API resources. It just works at the level of whole resources - it doesn't discriminate based on arbitrary object fields. If the built-in authorization options don't meet your needs, and [Authorization webhook](/docs/reference/access-authn-authz/webhook/) allows calling out to user-provided code to make an authorization decision. +--> +### 鉴权 {#authorization} + +[鉴权](/zh/docs/reference/access-authn-authz/webhook/)操作负责确定特定的用户 +是否可以读、写 API 资源或对其执行其他操作。 +此操作仅在整个资源集合的层面进行。 +换言之，它不会基于对象的特定字段作出不同的判决。 +如果内置的鉴权选项无法满足你的需要，你可以使用 +[鉴权 Webhook](/zh/docs/reference/access-authn-authz/webhook/)来调用用户提供 +的代码，执行定制的鉴权操作。 + +<!-- +### Dynamic Admission Control + +After a request is authorized, if it is a write operation, it also goes through [Admission Control](/docs/reference/access-authn-authz/admission-controllers/) steps. In addition to the built-in steps, there are several extensions: + +* The [Image Policy webhook](/docs/reference/access-authn-authz/admission-controllers/#imagepolicywebhook) restricts what images can be run in containers. +* To make arbitrary admission control decisions, a general [Admission webhook](/docs/reference/access-authn-authz/extensible-admission-controllers/#admission-webhooks) can be used. Admission Webhooks can reject creations or updates. +--> +### 动态准入控制 {#dynamic-admission-control} + +请求的鉴权操作结束之后，如果请求的是写操作，还会经过 +[准入控制](/zh/docs/reference/access-authn-authz/admission-controllers/)处理步骤。 +除了内置的处理步骤，还存在一些扩展点： + +* [Image Policy webhook](/zh/docs/reference/access-authn-authz/admission-controllers/#imagepolicywebhook) + 能够限制容器中可以运行哪些镜像。 +* 为了执行任意的准入控制，可以使用一种通用的 + [Admission webhook](/zh/docs/reference/access-authn-authz/extensible-admission-controllers/#admission-webhooks) + 机制。这类 Webhook 可以拒绝对象创建或更新请求。 + +<!-- +## Infrastructure Extensions + +### Storage Plugins + +[Flex Volumes](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/storage/flexvolume-deployment.md +) allow users to mount volume types without built-in support by having the +Kubelet call a Binary Plugin to mount the volume. +--> +## 基础设施扩展 {#infrastructure-extensions} + +### 存储插件 {#storage-plugins} + +[FlexVolumes](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/storage/flexvolume-deployment.md +) +卷可以让用户挂载无需内建支持的卷类型，kubelet 会调用可执行文件插件 +来挂载对应的存储卷。 + +<!-- +### Device Plugins + +Device plugins allow a node to discover new Node resources (in addition to the +builtin ones like cpu and memory) via a [Device +Plugin](/docs/concepts/cluster-administration/device-plugins/). + +### Network Plugins + +Different networking fabrics can be supported via node-level [Network Plugins](/docs/admin/network-plugins/). +--> +### 设备插件 {#device-plugins} + +使用[设备插件](/zh/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins/)， +节点能够发现新的节点资源（除了内置的类似 CPU 和内存这类资源）。 + +### 网络插件 {#network-plugins} + +通过节点层面的[网络插件](/zh/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/)，可以支持 +不同的网络设施。 + +<!-- +### Scheduler Extensions + +The scheduler is a special type of controller that watches pods, and assigns +pods to nodes. The default scheduler can be replaced entirely, while +continuing to use other Kubernetes components, or [multiple +schedulers](/docs/tasks/administer-cluster/configure-multiple-schedulers/) +can run at the same time. + +This is a significant undertaking, and almost all Kubernetes users find they +do not need to modify the scheduler. + +The scheduler also supports a +[webhook](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/scheduling/scheduler_extender.md) +that permits a webhook backend (scheduler extension) to filter and prioritize +the nodes chosen for a pod. +--> +### 调度器扩展 {#scheduler-extensions} + +调度器是一种特殊的控制器，负责监视 Pod 变化并将 Pod 分派给节点。 +默认的调度器可以被整体替换掉，同时继续使用其他 Kubernetes 组件。 +或者也可以在同一时刻使用 +[多个调度器](/zh/docs/tasks/administer-cluster/configure-multiple-schedulers/)。 + +这是一项非同小可的任务，几乎绝大多数 Kubernetes +用户都会发现其实他们不需要修改调度器。 + +调度器也支持一种 [webhook](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/scheduling/scheduler_extender.md)， +允许使用某种 Webhook 后端（调度器扩展）来为 Pod +可选的节点执行过滤和优先排序操作。 + + +## {{% heading "whatsnext" %}} + +<!-- +* Learn more about [Custom Resources](/docs/concepts/extend-kubernetes/api-extension/custom-resources/) +* Learn about [Dynamic admission control](/docs/reference/access-authn-authz/extensible-admission-controllers/) +* Learn more about Infrastructure extensions + * [Network Plugins](/docs/concepts/cluster-administration/network-plugins/) + * [Device Plugins](/docs/concepts/cluster-administration/device-plugins/) +* Learn about [kubectl plugins](/docs/tasks/extend-kubectl/kubectl-plugins/) +* Learn about the [Operator pattern](/docs/concepts/extend-kubernetes/operator/) +--> +* 进一步了解[自定义资源](/zh/docs/concepts/extend-kubernetes/api-extension/custom-resources/) +* 了解[动态准入控制](/zh/docs/reference/access-authn-authz/extensible-admission-controllers/) +* 进一步了解基础设施扩展 + * [网络插件](/zh/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/) + * [设备插件](/zh/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins/) +* 了解 [kubectl 插件](/zh/docs/tasks/extend-kubectl/kubectl-plugins/) +* 了解 [Operator 模式](/zh/docs/concepts/extend-kubernetes/operator/) + + diff --git a/content/zh/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation.md b/content/zh/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation.md index acac52ab5f..d91546feb6 100644 --- a/content/zh/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation.md +++ b/content/zh/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation.md @@ -1,7 +1,7 @@ --- title: 通过聚合层扩展 Kubernetes API content_type: concept -weight: 10 +weight: 20 --- <!-- --- @@ -11,7 +11,7 @@ reviewers: - cheftako - chenopis content_type: concept -weight: 10 +weight: 20 --- --> @@ -20,57 +20,77 @@ weight: 10 <!-- The aggregation layer allows Kubernetes to be extended with additional APIs, beyond what is offered by the core Kubernetes APIs. --> -聚合层允许 Kubernetes 通过额外的 API 进行扩展，而不局限于 Kubernetes 核心 API 提供的功能。 +使用聚合层（Aggregation Layer），用户可以通过额外的 API 扩展 Kubernetes， +而不局限于 Kubernetes 核心 API 提供的功能。 +<!-- +The additional APIs can either be ready-made solutions such as [service-catalog](/docs/concepts/extend-kubernetes/service-catalog/), or APIs that you develop yourself. +The aggregation layer is different from [Custom Resources](/docs/concepts/extend-kubernetes/api-extension/custom-resources/), which are a way to make the {{< glossary_tooltip term_id="kube-apiserver" text="kube-apiserver" >}} recognise new kinds of object. +--> +这里的附加 API 可以是[服务目录](/zh/docs/concepts/extend-kubernetes/service-catalog/) +这类已经成熟的解决方案，也可以是你自己开发的 API。 + +聚合层不同于 +[自定义资源（Custom Resources）](/zh/docs/concepts/extend-kubernetes/api-extension/custom-resources/)。 +后者的目的是让 {{< glossary_tooltip term_id="kube-apiserver" text="kube-apiserver" >}} +能够认识新的对象类别（Kind）。 <!-- body --> <!-- -## Overview +## Aggregation layer -The aggregation layer enables installing additional Kubernetes-style APIs in your cluster. These can either be pre-built, existing 3rd party solutions, such as [service-catalog](https://github.com/kubernetes-incubator/service-catalog/blob/master/README.md), or user-created APIs like [apiserver-builder](https://github.com/kubernetes-incubator/apiserver-builder/blob/master/README.md), which can get you started. ---> -## 概述 - -聚合层使您的集群可以安装其他 Kubernetes 风格的 API。这些 API 可以是预编译的、第三方的解决方案提供的例如[service-catalog](https://github.com/kubernetes-incubator/service-catalog/blob/master/README.md)、或者用户创建的类似[apiserver-builder](https://github.com/kubernetes-incubator/apiserver-builder/blob/master/README.md)一样的API可以帮助你上手。 - -<!-- The aggregation layer runs in-process with the kube-apiserver. Until an extension resource is registered, the aggregation layer will do nothing. To register an API, users must add an APIService object, which "claims" the URL path in the Kubernetes API. At that point, the aggregation layer will proxy anything sent to that API path (e.g. /apis/myextension.mycompany.io/v1/…) to the registered APIService. --> -聚合层在 kube-apiserver 进程内运行。在扩展资源注册之前，聚合层不做任何事情。要注册 API，用户必须添加一个 APIService 对象，用它来申领 Kubernetes API 中的 URL 路径。自此以后，聚合层将会把发给该 API 路径的所有内容（例如 /apis/myextension.mycompany.io/v1/…）代理到已注册的 APIService。 +## 聚合层 {#aggregation-layer} + +聚合层在 kube-apiserver 进程内运行。在扩展资源注册之前，聚合层不做任何事情。 +要注册 API，用户必须添加一个 APIService 对象，用它来“申领” Kubernetes API 中的 URL 路径。 +自此以后，聚合层将会把发给该 API 路径的所有内容（例如 `/apis/myextension.mycompany.io/v1/…`） +转发到已注册的 APIService。 <!-- -Ordinarily, the APIService will be implemented by an *extension-apiserver* in a pod running in the cluster. This extension-apiserver will normally need to be paired with one or more controllers if active management of the added resources is needed. As a result, the apiserver-builder will actually provide a skeleton for both. As another example, when the service-catalog is installed, it provides both the extension-apiserver and controller for the services it provides. +The most common way to implement the APIService is to run an *extension API server* in Pod(s) that run in your cluster. If you're using the extension API server to manage resources in your cluster, the extension API server (also written as "extension-apiserver") is typically paired with one or more {{< glossary_tooltip text="controllers" term_id="controller" >}}. The apiserver-builder library provides a skeleton for both extension API servers and the associated controller(s). --> -正常情况下，APIService 会实现为运行于集群中某 Pod 内的 extension-apiserver。如果需要对增加的资源进行动态管理，extension-apiserver 经常需要和一个或多个控制器一起使用。因此，apiserver-builder 同时提供用来管理新资源的 API 框架和控制器框架。另外一个例子，当安装了 service-catalog 时，它会为自己提供的服务提供 extension-apiserver 和控制器。 +APIService 的最常见实现方式是在集群中某 Pod 内运行 *扩展 API 服务器*。 +如果你在使用扩展 API 服务器来管理集群中的资源，该扩展 API 服务器（也被写成“extension-apiserver”） +一般需要和一个或多个{{< glossary_tooltip text="控制器" term_id="controller" >}}一起使用。 +apiserver-builder 库同时提供构造扩展 API 服务器和控制器框架代码。 + <!-- -Extension-apiservers should have low latency connections to and from the kube-apiserver. -In particular, discovery requests are required to round-trip from the kube-apiserver in five seconds or less. -If your deployment cannot achieve this, you should consider how to change it. For now, setting the -`EnableAggregatedDiscoveryTimeout=false` feature gate on the kube-apiserver -will disable the timeout restriction. It will be removed in a future release. +### Response latency + +Extension API servers should have low latency networking to and from the kube-apiserver. +Discovery requests are required to round-trip from the kube-apiserver in five seconds or less. + +If your extension API server cannot achieve that latency requirement, consider making changes that let you meet it. You can also set the +`EnableAggregatedDiscoveryTimeout=false` [feature gate](/docs/reference/command-line-tools-reference/feature-gates/) on the kube-apiserver +to disable the timeout restriction. This deprecated feature gate will be removed in a future release. --> +### 反应延迟 {#response-latency} -extension-apiserver 与 kube-apiserver 之间的连接应具有低延迟。 -特别是，发现请求需要在五秒钟或更短的时间内从 kube-apiserver 往返。 -如果您的部署无法实现此目的，则应考虑如何进行更改。目前，在 kube-apiserver 上设置 `EnableAggregatedDiscoveryTimeout=false` 功能开关将禁用超时限制。它将在将来的版本中被删除。 - +扩展 API 服务器与 kube-apiserver 之间需要存在低延迟的网络连接。 +发现请求需要在五秒钟或更短的时间内完成到 kube-apiserver 的往返。 +如果你的扩展 API 服务器无法满足这一延迟要求，应考虑如何更改配置已满足需要。 +你也可以为 kube-apiserver 设置 `EnableAggregatedDiscoveryTimeout=false` +[特性门控](/zh/docs/reference/command-line-tools-reference/feature-gates/) +来禁用超时限制。此特性门控已经废弃，将在未来版本中被删除。 ## {{% heading "whatsnext" %}} - <!-- * To get the aggregator working in your environment, [configure the aggregation layer](/docs/tasks/access-kubernetes-api/configure-aggregation-layer/). * Then, [setup an extension api-server](/docs/tasks/access-kubernetes-api/setup-extension-api-server/) to work with the aggregation layer. * Also, learn how to [extend the Kubernetes API using Custom Resource Definitions](/docs/tasks/access-kubernetes-api/extend-api-custom-resource-definitions/). +* Read the specification for [APIService](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#apiservice-v1-apiregistration-k8s-io) --> -* 阅读[配置聚合层](/docs/tasks/access-kubernetes-api/configure-aggregation-layer/) 文档，了解如何在自己的环境中启用聚合器（aggregator）。 -* 然后[安装扩展的 api-server](/docs/tasks/access-kubernetes-api/setup-extension-api-server/) 来开始使用聚合层。 -* 也可以学习怎样 [使用自定义资源定义扩展 Kubernetes API](/docs/tasks/access-kubernetes-api/extend-api-custom-resource-definitions/)。 - - - +* 阅读[配置聚合层](/zh/docs/tasks/extend-kubernetes/configure-aggregation-layer/) 文档， + 了解如何在自己的环境中启用聚合器。 +* 接下来，了解[安装扩展 API 服务器](/zh/docs/tasks/extend-kubernetes/setup-extension-api-server/)， + 开始使用聚合层。 +* 也可以学习怎样[使用自定义资源定义扩展 Kubernetes API](/zh/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/)。 +* 阅读 [APIService](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#apiservice-v1-apiregistration-k8s-io) 的规范 diff --git a/content/zh/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins.md b/content/zh/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins.md index ce02f811f2..964c5dc392 100644 --- a/content/zh/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins.md +++ b/content/zh/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins.md @@ -19,11 +19,9 @@ The targeted devices include GPUs, high-performance NICs, FPGAs, InfiniBand adap and other similar computing resources that may require vendor specific initialization and setup. --> -Kubernetes 提供了一个[设备插件框架](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/resource-management/device-plugin.md)，您可以用来将系统硬件资源发布到 {{< glossary_tooltip term_id="kubelet" >}}。 - -供应商可以实现设备插件，由您手动部署或作为 {{< glossary_tooltip term_id="daemonset" >}} 来部署，而不必定制 Kubernetes 本身的代码。目标设备包括 GPU、高性能 NIC、FPGA、InfiniBand 适配器以及其他类似的、可能需要特定于供应商的初始化和设置的计算资源。 - +Kubernetes 提供了一个[设备插件框架](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/resource-management/device-plugin.md)，你可以用来将系统硬件资源发布到 {{< glossary_tooltip term_id="kubelet" >}}。 +供应商可以实现设备插件，由你手动部署或作为 {{< glossary_tooltip term_id="daemonset" >}} 来部署，而不必定制 Kubernetes 本身的代码。目标设备包括 GPU、高性能 NIC、FPGA、InfiniBand 适配器以及其他类似的、可能需要特定于供应商的初始化和设置的计算资源。 <!-- body --> @@ -32,7 +30,7 @@ Kubernetes 提供了一个[设备插件框架](https://github.com/kubernetes/com <!-- The kubelet exports a `Registration` gRPC service: --> -kubelet 输出了一个 `Registration` 的 gRPC 服务： +`kubelet` 提供了一个 `Registration` 的 gRPC 服务： ```gRPC service Registration { @@ -47,7 +45,7 @@ During the registration, the device plugin needs to send: * The name of its Unix socket. * The Device Plugin API version against which it was built. * The `ResourceName` it wants to advertise. Here `ResourceName` needs to follow the - [extended resource naming scheme](/docs/concepts/configuration/manage-compute-resources-container/#extended-resources) + [extended resource naming scheme](/docs/concepts/configuration/manage-resources-container/#extended-resources) as `vendor-domain/resourcetype`. (For example, an NVIDIA GPU is advertised as `nvidia.com/gpu`.) @@ -60,9 +58,11 @@ to advertise that the node has 2 “Foo” devices installed and available. --> 设备插件可以通过此 gRPC 服务在 kubelet 进行注册。在注册期间，设备插件需要发送下面几样内容： - * 设备插件的 Unix 套接字。 - * 设备插件的 API 版本。 - * `ResourceName` 是需要公布的。这里 `ResourceName` 需要遵循[扩展资源命名方案](/docs/concepts/configuration/manage-compute-resources-container/#extended-resources)，类似于 `vendor-domain/resourcetype`。（比如 NVIDIA GPU 就被公布为 `nvidia.com/gpu`。） +* 设备插件的 Unix 套接字。 +* 设备插件的 API 版本。 +* `ResourceName` 是需要公布的。这里 `ResourceName` 需要遵循 + [扩展资源命名方案](/zh/docs/concepts/configuration/manage-resources-container/#extended-resources)， + 类似于 `vendor-domain/resourcetype`。（比如 NVIDIA GPU 就被公布为 `nvidia.com/gpu`。） 成功注册后，设备插件就向 kubelet 发送他所管理的设备列表，然后 kubelet 负责将这些资源发布到 API 服务器，作为 kubelet 节点状态更新的一部分。 @@ -76,16 +76,17 @@ specification as they request other types of resources, with the following limit * Extended resources are only supported as integer resources and cannot be overcommitted. * Devices cannot be shared among Containers. --> -然后用户需要去请求其他类型的资源的时候，就可以在[Container](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#container-v1-core)规范请求这类设备，但是有以下的限制： +然后用户需要请求其他类型的资源的时候，就可以在 +[Container](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#container-v1-core) +规范请求这类设备，但是有以下的限制： - * 扩展资源仅可作为整数资源使用，并且不能被过量使用 - * 设备不能在容器之间共享 +* 扩展资源仅可作为整数资源使用，并且不能被过量使用 +* 设备不能在容器之间共享 <!-- Suppose a Kubernetes cluster is running a device plugin that advertises resource `hardware-vendor.example/foo` on certain nodes. Here is an example of a pod requesting this resource to run a demo workload: --> - 假设 Kubernetes 集群正在运行一个设备插件，该插件在一些节点上公布的资源为 `hardware-vendor.example/foo`。 下面就是一个 Pod 示例，请求此资源以运行某演示负载： @@ -125,8 +126,8 @@ The general workflow of a device plugin includes the following steps: 设备插件的常规工作流程包括以下几个步骤： - * 初始化。在这个阶段，设备插件将执行供应商特定的初始化和设置，以确保设备处于就绪状态。 - * 插件使用主机路径 `/var/lib/kubelet/device-plugins/` 下的 Unix socket 启动一个 gRPC 服务，该服务实现以下接口： +* 初始化。在这个阶段，设备插件将执行供应商特定的初始化和设置，以确保设备处于就绪状态。 +* 插件使用主机路径 `/var/lib/kubelet/device-plugins/` 下的 Unix socket 启动一个 gRPC 服务，该服务实现以下接口： ```gRPC service DevicePlugin { @@ -154,9 +155,12 @@ If the operations succeed, the device plugin returns an `AllocateResponse` that runtime configurations for accessing the allocated devices. The kubelet passes this information to the container runtime. --> - - * 插件通过 Unix socket 在主机路径 `/var/lib/kubelet/device-plugins/kubelet.sock` 处向 kubelet 注册自身。 - * 成功注册自身后，设备插件将以服务模式运行，在此期间，它将持续监控设备运行状况，并在设备状态发生任何变化时向 kubelet 报告。它还负责响应 `Allocate` gRPC 请求。在`Allocate`期间，设备插件可能还会做一些设备特定的准备；例如 GPU 清理或 QRNG 初始化。如果操作成功，则设备插件将返回 `AllocateResponse`，其中包含用于访问被分配的设备容器运行时的配置。kubelet 将此信息传递到容器运行时。 +* 插件通过 Unix socket 在主机路径 `/var/lib/kubelet/device-plugins/kubelet.sock` 处向 kubelet 注册自身。 +* 成功注册自身后，设备插件将以服务模式运行，在此期间，它将持续监控设备运行状况， + 并在设备状态发生任何变化时向 kubelet 报告。它还负责响应 `Allocate` gRPC 请求。 + 在 `Allocate` 期间，设备插件可能还会做一些设备特定的准备；例如 GPU 清理或 QRNG 初始化。 + 如果操作成功，则设备插件将返回 `AllocateResponse`，其中包含用于访问被分配的设备容器运行时的配置。 + kubelet 将此信息传递到容器运行时。 <!-- ### Handling kubelet restarts @@ -168,7 +172,10 @@ of its Unix socket and re-register itself upon such an event. --> ### 处理 kubelet 重启 -设备插件应能监测到 kubelet 重启，并且向新的 kubelet 实例来重新注册自己。在当前实现中，当 kubelet 重启的时候，新的 kubelet 实例会删除 `/var/lib/kubelet/device-plugins` 下所有已经存在的 Unix sockets。设备插件需要能够监控到它的 Unix socket 被删除，并且当发生此类事件时重新注册自己。 +设备插件应能监测到 kubelet 重启，并且向新的 kubelet 实例来重新注册自己。 +在当前实现中，当 kubelet 重启的时候，新的 kubelet 实例会删除 `/var/lib/kubelet/device-plugins` +下所有已经存在的 Unix sockets。 +设备插件需要能够监控到它的 Unix socket 被删除，并且当发生此类事件时重新注册自己。 <!-- ## Device plugin deployment @@ -190,9 +197,13 @@ Pod onto Nodes, to restart the daemon Pod after failure, and to help automate up 你可以将你的设备插件作为节点操作系统的软件包来部署、作为 DaemonSet 来部署或者手动部署。 -规范目录 `/var/lib/kubelet/device-plugins` 是需要特权访问的，所以设备插件必须要在被授权的安全的上下文中运行。如果你将设备插件部署为 DaemonSet，`/var/lib/kubelet/device-plugins` 目录必须要在插件的 [PodSpec](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podspec-v1-core) 中声明作为 {{< glossary_tooltip term_id="volume" >}} 被 mount 到插件中。 +规范目录 `/var/lib/kubelet/device-plugins` 是需要特权访问的，所以设备插件必须要在被授权的安全的上下文中运行。 +如果你将设备插件部署为 DaemonSet，`/var/lib/kubelet/device-plugins` 目录必须要在插件的 +[PodSpec](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podspec-v1-core) +中声明作为 {{< glossary_tooltip term_id="volume" >}} 被 mount 到插件中。 -如果你选择 DaemonSet 方法，你可以通过 Kubernetes 进行以下操作：将设备插件的 Pod 放置在节点上，在出现故障后重新启动 daemon Pod，来进行自动进行升级。 +如果你选择 DaemonSet 方法，你可以通过 Kubernetes 进行以下操作： +将设备插件的 Pod 放置在节点上，在出现故障后重新启动守护进程 Pod，来进行自动升级。 <!-- ## API compatibility @@ -210,12 +221,15 @@ ensure the continuous functioning of the device allocations during the upgrade. --> ## API 兼容性 -Kubernetes 设备插件支持还处于 beta 版本。所以在稳定版本出来之前 API 会以不兼容的方式进行更改。作为一个项目，Kubernetes 建议设备插件开发者： +Kubernetes 设备插件支持还处于 beta 版本。所以在稳定版本出来之前 API 会以不兼容的方式进行更改。 +作为一个项目，Kubernetes 建议设备插件开发者： * 注意未来版本的更改 * 支持多个版本的设备插件 API，以实现向后/向前兼容性。 -如果你启用 DevicePlugins 功能，并在需要升级到 Kubernetes 版本来获得较新的设备插件 API 版本的节点上运行设备插件，请在升级这些节点之前先升级设备插件以支持这两个版本。采用该方法将确保升级期间设备分配的连续运行。 +如果你启用 DevicePlugins 功能，并在需要升级到 Kubernetes 版本来获得较新的设备插件 API +版本的节点上运行设备插件，请在升级这些节点之前先升级设备插件以支持这两个版本。 +采用该方法将确保升级期间设备分配的连续运行。 <!-- ## Monitoring Device Plugin Resources @@ -233,7 +247,11 @@ identifying containers using `pod`, `namespace`, and `container` prometheus labe {{< feature-state for_k8s_version="v1.15" state="beta" >}} -为了监控设备插件提供的资源，监控代理程序需要能够发现节点上正在使用的设备，并获取元数据来描述哪个指标与容器相关联。设备监控代理暴露给 [Prometheus](https://prometheus.io/) 的指标应该遵循 [Kubernetes Instrumentation Guidelines](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-instrumentation/instrumentation.md)，使用 `pod`、`namespace` 和 `container` 标签来标识容器。 +为了监控设备插件提供的资源，监控代理程序需要能够发现节点上正在使用的设备， +并获取元数据来描述哪个指标与容器相关联。 +设备监控代理暴露给 [Prometheus](https://prometheus.io/) 的指标应该遵循 +[Kubernetes Instrumentation Guidelines](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-instrumentation/instrumentation.md)， +使用 `pod`、`namespace` 和 `container` 标签来标识容器。 <!-- The kubelet provides a gRPC service to enable discovery of in-use devices, and to provide metadata @@ -260,9 +278,18 @@ DaemonSet, `/var/lib/kubelet/pod-resources` must be mounted as a Support for the "PodResources service" requires `KubeletPodResources` [feature gate](/docs/reference/command-line-tools-reference/feature-gates/) to be enabled. It is enabled by default starting with Kubernetes 1.15. --> -gRPC 服务通过 `/var/lib/kubelet/pod-resources/kubelet.sock` 的 UNIX 套接字来提供服务。设备插件资源的监控代理程序可以部署为守护进程或者 DaemonSet。规范的路径 `/var/lib/kubelet/pod-resources` 需要特权来进入，所以监控代理程序必须要在获得授权的安全的上下文中运行。如果设备监控代理以 DaemonSet 形式运行，必须要在插件的 [PodSpec](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podspec-v1-core) 中声明将 `/var/lib/kubelet/pod-resources` 目录以 {{< glossary_tooltip term_id="volume" >}} 形式被 mount 到容器中。 +gRPC 服务通过 `/var/lib/kubelet/pod-resources/kubelet.sock` 的 UNIX 套接字来提供服务。 +设备插件资源的监控代理程序可以部署为守护进程或者 DaemonSet。 +规范的路径 `/var/lib/kubelet/pod-resources` 需要特权来进入， +所以监控代理程序必须要在获得授权的安全的上下文中运行。 +如果设备监控代理以 DaemonSet 形式运行，必须要在插件的 +[PodSpec](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podspec-v1-core) +中声明将 `/var/lib/kubelet/pod-resources` 目录以 +{{< glossary_tooltip text="卷" term_id="volume" >}}的形式被挂载到容器中。 -对“PodResources 服务”的支持要求启用 `KubeletPodResources` [特性门控](/docs/reference/command-line-tools-reference/feature-gates/)。从 Kubernetes 1.15 开始默认启用。 +对“PodResources 服务”的支持要求启用 `KubeletPodResources` +[特性门控](/zh/docs/reference/command-line-tools-reference/feature-gates/)。 +从 Kubernetes 1.15 开始默认启用。 <!-- ## Device Plugin integration with the Topology Manager @@ -275,7 +302,8 @@ The Topology Manager is a Kubelet component that allows resources to be co-ordin {{< feature-state for_k8s_version="v1.17" state="alpha" >}} -拓扑管理器是 Kubelet 的一个组件，它允许以拓扑对齐方式来调度资源。为了做到这一点，设备插件 API 进行了扩展来包括一个 `TopologyInfo` 结构体。 +拓扑管理器是 Kubelet 的一个组件，它允许以拓扑对齐方式来调度资源。 +为了做到这一点，设备插件 API 进行了扩展来包括一个 `TopologyInfo` 结构体。 ```gRPC message TopologyInfo { @@ -298,9 +326,11 @@ An example `TopologyInfo` struct populated for a device by a Device Plugin: pluginapi.Device{ID: "25102017", Health: pluginapi.Healthy, Topology:&pluginapi.TopologyInfo{Nodes: []*pluginapi.NUMANode{&pluginapi.NUMANode{ID: 0,},}}} ``` --> -设备插件希望拓扑管理器可以将填充的 TopologyInfo 结构体作为设备注册的一部分以及设备 ID 和设备的运行状况发送回去。然后设备管理器将使用此信息来咨询拓扑管理器并做出资源分配决策。 +设备插件希望拓扑管理器可以将填充的 TopologyInfo 结构体作为设备注册的一部分以及设备 ID +和设备的运行状况发送回去。然后设备管理器将使用此信息来咨询拓扑管理器并做出资源分配决策。 -`TopologyInfo` 支持定义 `nodes` 字段，允许为 `nil`（默认）或者是一个 NUMA nodes 的列表。这样就可以使设备插件可以跨越 NUMA nodes 去发布。 +`TopologyInfo` 支持定义 `nodes` 字段，允许为 `nil`（默认）或者是一个 NUMA 节点的列表。 +这样就可以使设备插件可以跨越 NUMA 节点去发布。 下面是一个由设备插件为设备填充 `TopologyInfo` 结构体的示例： @@ -322,36 +352,34 @@ Here are some examples of device plugin implementations: * The [RDMA device plugin](https://github.com/hustcat/k8s-rdma-device-plugin) * The [Solarflare device plugin](https://github.com/vikaschoudhary16/sfc-device-plugin) * The [SR-IOV Network device plugin](https://github.com/intel/sriov-network-device-plugin) -* The [Xilinx FPGA device plugins](https://github.com/Xilinx/FPGA_as_a_Service/tree/master/k8s-fpga-device-plugin/trunk) for Xilinx FPGA devices +* The [Xilinx FPGA device plugins](https://github.com/Xilinx/FPGA_as_a_Service/tree/master/k8s-fpga-device-plugin) for Xilinx FPGA devices --> ## 设备插件示例 {#examples} 下面是一些设备插件实现的示例： -* [AMD GPU device plugin](https://github.com/RadeonOpenCompute/k8s-device-plugin) -* [Intel device plugins](https://github.com/intel/intel-device-plugins-for-kubernetes) 支持 Intel GPU、FPGA 和 QuickAssist 设备 -* [KubeVirt device plugins](https://github.com/kubevirt/kubernetes-device-plugins) 用于硬件辅助的虚拟化 -* The [NVIDIA GPU device plugin](https://github.com/NVIDIA/k8s-device-plugin) - * 需要 [nvidia-docker](https://github.com/NVIDIA/nvidia-docker) 2.0，允许运行 Docker 容器的时候开启 GPU。 -* [NVIDIA GPU device plugin for Container-Optimized OS](https://github.com/GoogleCloudPlatform/container-engine-accelerators/tree/master/cmd/nvidia_gpu) -* [RDMA device plugin](https://github.com/hustcat/k8s-rdma-device-plugin) -* [Solarflare device plugin](https://github.com/vikaschoudhary16/sfc-device-plugin) -* [SR-IOV Network device plugin](https://github.com/intel/sriov-network-device-plugin) -* [Xilinx FPGA device plugins](https://github.com/Xilinx/FPGA_as_a_Service/tree/master/k8s-fpga-device-plugin/trunk) - +* [AMD GPU 设备插件](https://github.com/RadeonOpenCompute/k8s-device-plugin) +* [Intel 设备插件](https://github.com/intel/intel-device-plugins-for-kubernetes) 支持 Intel GPU、FPGA 和 QuickAssist 设备 +* [KubeVirt 设备插件](https://github.com/kubevirt/kubernetes-device-plugins) 用于硬件辅助的虚拟化 +* The [NVIDIA GPU 设备插件](https://github.com/NVIDIA/k8s-device-plugin) + * 需要 [nvidia-docker](https://github.com/NVIDIA/nvidia-docker) 2.0，以允许运行 Docker 容器的时候启用 GPU。 +* [为 Container-Optimized OS 所提供的 NVIDIA GPU 设备插件](https://github.com/GoogleCloudPlatform/container-engine-accelerators/tree/master/cmd/nvidia_gpu) +* [RDMA 设备插件](https://github.com/hustcat/k8s-rdma-device-plugin) +* [Solarflare 设备插件](https://github.com/vikaschoudhary16/sfc-device-plugin) +* [SR-IOV 网络设备插件](https://github.com/intel/sriov-network-device-plugin) +* [Xilinx FPGA 设备插件](https://github.com/Xilinx/FPGA_as_a_Service/tree/master/k8s-fpga-device-plugin) ## {{% heading "whatsnext" %}} - <!-- * Learn about [scheduling GPU resources](/docs/tasks/manage-gpus/scheduling-gpus/) using device plugins * Learn about [advertising extended resources](/docs/tasks/administer-cluster/extended-resource-node/) on a node * Read about using [hardware acceleration for TLS ingress](https://kubernetes.io/blog/2019/04/24/hardware-accelerated-ssl/tls-termination-in-ingress-controllers-using-kubernetes-device-plugins-and-runtimeclass/) with Kubernetes * Learn about the [Topology Manager] (/docs/tasks/adminster-cluster/topology-manager/) --> -* 查看 [调度 GPU 资源](/docs/tasks/manage-gpus/scheduling-gpus/) 来学习使用设备插件 -* 查看在 node 上如何[广告扩展资源](/docs/tasks/administer-cluster/extended-resource-node/) -* 阅读如何在 Kubernetes 中如何使用 [TLS 入口的硬件加速](https://kubernetes.io/blog/2019/04/24/hardware-accelerated-ssl/tls-termination-in-ingress-controllers-using-kubernetes-device-plugins-and-runtimeclass/) -* 学习 [Topology Manager] (/docs/tasks/adminster-cluster/topology-manager/) +* 查看[调度 GPU 资源](/zh/docs/tasks/manage-gpus/scheduling-gpus/) 来学习使用设备插件 +* 查看在上如何[公布节点上的扩展资源](/docs/tasks/administer-cluster/extended-resource-node/) +* 阅读如何在 Kubernetes 中使用 [TLS Ingress 的硬件加速](https://kubernetes.io/blog/2019/04/24/hardware-accelerated-ssl/tls-termination-in-ingress-controllers-using-kubernetes-device-plugins-and-runtimeclass/) +* 学习[拓扑管理器](/zh/docs/tasks/adminster-cluster/topology-manager/) diff --git a/content/zh/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins.md b/content/zh/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins.md index a6fe50363a..7ad8153077 100644 --- a/content/zh/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins.md +++ b/content/zh/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins.md @@ -14,9 +14,9 @@ weight: 10 {{< feature-state state="alpha" >}} <!-- -{{< warning >}}Alpha features change rapidly. {{< /warning >}} +{{< caution >}}Alpha features can change rapidly. {{< /caution >}} --> -{{< warning >}}Alpha 特性迅速变化。{{< /warning >}} +{{< caution >}}Alpha 特性可能很快会变化。{{< /caution >}} <!-- Network plugins in Kubernetes come in a few flavors: @@ -36,7 +36,7 @@ Kubernetes中的网络插件有几种类型： <!-- ## Installation -The kubelet has a single default network plugin, and a default network common to the entire cluster. It probes for plugins when it starts up, remembers what it found, and executes the selected plugin at appropriate times in the pod lifecycle (this is only true for Docker, as rkt manages its own CNI plugins). There are two Kubelet command line parameters to keep in mind when using plugins: +The kubelet has a single default network plugin, and a default network common to the entire cluster. It probes for plugins when it starts up, remembers what it finds, and executes the selected plugin at appropriate times in the pod lifecycle (this is only true for Docker, as rkt manages its own CNI plugins). There are two Kubelet command line parameters to keep in mind when using plugins: * `cni-bin-dir`: Kubelet probes this directory for plugins on startup * `network-plugin`: The network plugin to use from `cni-bin-dir`. It must match the name reported by a plugin probed from the plugin directory. For CNI plugins, this is simply "cni". @@ -71,7 +71,7 @@ iptables 代理显然依赖于 iptables，插件可能需要确保 iptables 能 The CNI plugin is selected by passing Kubelet the `--network-plugin=cni` command-line option. Kubelet reads a file from `--cni-conf-dir` (default `/etc/cni/net.d`) and uses the CNI configuration from that file to set up each pod's network. The CNI configuration file must match the [CNI specification](https://github.com/containernetworking/cni/blob/master/SPEC.md#network-configuration), and any required CNI plugins referenced by the configuration must be present in `--cni-bin-dir` (default `/opt/cni/bin`). -If there are multiple CNI configuration files in the directory, the first one in lexicographic order of file name is used. +If there are multiple CNI configuration files in the directory, the kubelet uses the configuration file that comes first by name in lexicographic order. In addition to the CNI plugin specified by the configuration file, Kubernetes requires the standard CNI [`lo`](https://github.com/containernetworking/plugins/blob/master/plugins/main/loopback/loopback.go) plugin, at minimum version 0.2.0 --> @@ -81,7 +81,7 @@ In addition to the CNI plugin specified by the configuration file, Kubernetes re Kubelet 从 `--cni-conf-dir` （默认是 `/etc/cni/net.d`） 读取文件并使用该文件中的 CNI 配置来设置每个 pod 的网络。 CNI 配置文件必须与 [CNI 规约](https://github.com/containernetworking/cni/blob/master/SPEC.md#network-configuration)匹配，并且配置引用的任何所需的 CNI 插件都必须存在于 `--cni-bin-dir`（默认是 `/opt/cni/bin`）。 -如果这个目录中有多个 CNI 配置文件，则使用按文件名的字典顺序排列的第一个配置文件。 +如果这个目录中有多个 CNI 配置文件，kubelet 将会使用按文件名的字典顺序排列的第一个作为配置文件。 除了配置文件指定的 CNI 插件外，Kubernetes 还需要标准的 CNI [`lo`](https://github.com/containernetworking/plugins/blob/master/plugins/main/loopback/loopback.go) 插件，最低版本是0.2.0。 @@ -134,20 +134,24 @@ CNI 网络插件支持 `hostPort`。 您可以使用官方 [portmap](https://git <!-- #### Support traffic shaping +**Experimental Feature** + The CNI networking plugin also supports pod ingress and egress traffic shaping. You can use the official [bandwidth](https://github.com/containernetworking/plugins/tree/master/plugins/meta/bandwidth) plugin offered by the CNI plugin team or use your own plugin with bandwidth control functionality. -If you want to enable traffic shaping support, you must add a `bandwidth` plugin to your CNI configuration file -(default `/etc/cni/net.d`). +If you want to enable traffic shaping support, you must add the `bandwidth` plugin to your CNI configuration file +(default `/etc/cni/net.d`) and ensure that the binary is included in your CNI bin dir (default `/opt/cni/bin`). --> #### 支持流量整形 +**实验功能** + CNI 网络插件还支持 pod 入口和出口流量整形。 您可以使用 CNI 插件团队提供的 [bandwidth](https://github.com/containernetworking/plugins/tree/master/plugins/meta/bandwidth) 插件， 也可以使用您自己的具有带宽控制功能的插件。 如果您想要启用流量整形支持，你必须将 `bandwidth` 插件添加到 CNI 配置文件 -（默认是 `/etc/cni/net.d`）。 +（默认是 `/etc/cni/net.d`）并保证该可执行文件包含在您的 CNI 的 bin 文件夹内 (默认为 `/opt/cni/bin`)。 ```json { diff --git a/content/zh/docs/concepts/extend-kubernetes/extend-cluster.md b/content/zh/docs/concepts/extend-kubernetes/extend-cluster.md index 58e6154f6a..4c2c7cbc53 100644 --- a/content/zh/docs/concepts/extend-kubernetes/extend-cluster.md +++ b/content/zh/docs/concepts/extend-kubernetes/extend-cluster.md @@ -23,19 +23,23 @@ Kubernetes is highly configurable and extensible. As a result, there is rarely a need to fork or submit patches to the Kubernetes project code. -This guide describes the options for customizing a Kubernetes -cluster. It is aimed at {{< glossary_tooltip text="cluster operators" term_id="cluster-operator" >}} who want to -understand how to adapt their Kubernetes cluster to the needs of -their work environment. Developers who are prospective {{< glossary_tooltip text="Platform Developers" term_id="platform-developer" >}} or Kubernetes Project {{< glossary_tooltip text="Contributors" term_id="contributor" >}} will also find it -useful as an introduction to what extension points and patterns -exist, and their trade-offs and limitations. +This guide describes the options for customizing a Kubernetes cluster. It is +aimed at {{< glossary_tooltip text="cluster operators" term_id="cluster-operator" >}} +who want to understand how to adapt their +Kubernetes cluster to the needs of their work environment. Developers who are prospective +{{< glossary_tooltip text="Platform Developers" term_id="platform-developer" >}} +or Kubernetes Project {{< glossary_tooltip text="Contributors" term_id="contributor" >}} +will also find it useful as an introduction to what extension points and +patterns exist, and their trade-offs and limitations. --> Kubernetes 是高度可配置和可扩展的。因此，极少需要分发或提交补丁代码给 Kubernetes 项目。 -本文档介绍自定义 Kubernetes 集群的选项。本文档的目标读者 {{< glossary_tooltip text="cluster operators" term_id="cluster-operator" >}} 是希望了解如何使 Kubernetes 集群满足其业务环境需求的集群运维人员。Kubernetes 项目的贡献者 {{< glossary_tooltip text="Contributors" term_id="contributor" >}} 或潜在的平台开发人员 {{< glossary_tooltip text="Platform Developers" term_id="platform-developer" >}} 也可以从本文找到有用的信息，如对已存在扩展点和模式的介绍，以及它们的权衡和限制。 - - - +本文档介绍自定义 Kubernetes 集群的选项。本文档的目标读者包括希望了解如何使 +Kubernetes 集群满足其业务环境需求的 +{{< glossary_tooltip text="集群运维人员" term_id="cluster-operator" >}}、 +Kubernetes 项目的{{< glossary_tooltip text="贡献者" term_id="contributor" >}}。 +或潜在的{{< glossary_tooltip text="平台开发人员" term_id="platform-developer" >}} +也可以从本文找到有用的信息，如对已存在扩展点和模式的介绍，以及它们的权衡和限制。 <!-- body --> @@ -46,27 +50,28 @@ Customization approaches can be broadly divided into *configuration*, which only --> ## 概述 -定制方法可以大致分为 *配置* 和 *扩展* 。*配置* 只涉及更改标志参数、本地配置文件或 API 资源；*扩展* 涉及运行额外的程序或服务。本文档主要内容是关于扩展。 +定制方法可以大致分为 *配置（Configuration）* 和 *扩展（Extension）* 。 +*配置* 只涉及更改标志参数、本地配置文件或 API 资源； +*扩展* 涉及运行额外的程序或服务。本文档主要内容是关于扩展。 <!-- ## Configuration ---> -## 配置 -<!-- *Configuration files* and *flags* are documented in the Reference section of the online documentation, under each binary: -* [kubelet](/docs/admin/kubelet/) -* [kube-apiserver](/docs/admin/kube-apiserver/) -* [kube-controller-manager](/docs/admin/kube-controller-manager/) -* [kube-scheduler](/docs/admin/kube-scheduler/). +* [kubelet](/docs/reference/command-line-tools-reference/kubelet/) +* [kube-apiserver](/docs/reference/command-line-tools-reference/kube-apiserver/) +* [kube-controller-manager](/docs/reference/command-line-tools-reference/kube-controller-manager/) +* [kube-scheduler](/docs/reference/command-line-tools-reference/kube-scheduler/). --> -关于 *配置文件* 和 *标志* 的说明文档位于在线文档的参考部分，按照二进制组件各自描述： +## 配置 {#configuration} -* [kubelet](/docs/admin/kubelet/) -* [kube-apiserver](/docs/admin/kube-apiserver/) -* [kube-controller-manager](/docs/admin/kube-controller-manager/) -* [kube-scheduler](/docs/admin/kube-scheduler/). +关于 *配置文件* 和 *标志* 的说明文档位于在线文档的"参考"部分，按照可执行文件组织： + +* [kubelet](/zh/docs/reference/command-line-tools-reference/kubelet/) +* [kube-apiserver](/zh/docs/reference/command-line-tools-reference/kube-apiserver/) +* [kube-controller-manager](/zh/docs/reference/command-line-tools-reference/kube-controller-manager/) +* [kube-scheduler](/zh/docs/reference/command-line-tools-reference/kube-scheduler/). <!-- Flags and configuration files may not always be changeable in a hosted Kubernetes service or a distribution with managed installation. When they are changeable, they are usually only changeable by the cluster administrator. Also, they are subject to change in future Kubernetes versions, and setting them may require restarting processes. For those reasons, they should be used only when there are no other options. @@ -74,10 +79,18 @@ Flags and configuration files may not always be changeable in a hosted Kubernete 在托管的 Kubernetes 服务或受控安装的 Kubernetes 版本中，标志和配置文件可能并不总是可以更改的。而且当它们可以进行更改时，它们通常只能由集群管理员进行更改。此外，标志和配置文件在未来的 Kubernetes 版本中可能会发生变化，并且更改设置后它们可能需要重新启动进程。出于这些原因，只有在没有其他选择的情况下才使用它们。 <!-- -*Built-in Policy APIs*, such as [ResourceQuota](/docs/concepts/policy/resource-quotas/), [PodSecurityPolicies](/docs/concepts/policy/pod-security-policy/), [NetworkPolicy](/docs/concepts/services-networking/network-policies/) and Role-based Access Control ([RBAC](/docs/reference/access-authn-authz/rbac/)), are built-in Kubernetes APIs. APIs are typically used with hosted Kubernetes services and with managed Kubernetes installations. They are declarative and use the same conventions as other Kubernetes resources like pods, so new cluster configuration can be repeatable and be managed the same way as applications. And, where they are stable, they enjoy a [defined support policy](/docs/reference/deprecation-policy/) like other Kubernetes APIs. For these reasons, they are preferred over *configuration files* and *flags* where suitable. +*Built-in Policy APIs*, such as [ResourceQuota](/docs/concepts/policy/resource-quotas/), [PodSecurityPolicies](/docs/concepts/policy/pod-security-policy/), [NetworkPolicy](/docs/concepts/services-networking/network-policies/) and Role-based Access Control ([RBAC](/docs/reference/access-authn-authz/rbac/)), are built-in Kubernetes APIs. APIs are typically used with hosted Kubernetes services and with managed Kubernetes installations. They are declarative and use the same conventions as other Kubernetes resources like pods, so new cluster configuration can be repeatable and be managed the same way as applications. And, where they are stable, they enjoy a [defined support policy](/docs/reference/using-api/deprecation-policy/) like other Kubernetes APIs. For these reasons, they are preferred over *configuration files* and *flags* where suitable. --> -*内置策略 API* ，例如 [ResourceQuota](/docs/concepts/policy/resource-quotas/)、[PodSecurityPolicy](/docs/concepts/policy/pod-security-policy/)、[NetworkPolicy](/docs/concepts/services-networking/network-policies/) 和基于角色的权限控制 ([RBAC](/docs/reference/access-authn-authz/rbac/))，是内置的 Kubernetes API。API 通常与托管的 Kubernetes 服务和受控的 Kubernetes 安装一起使用。 -它们是声明性的，并使用与其他 Kubernetes 资源（如 Pod ）相同的约定，所以新的集群配置可以重复使用，并以与应用程序相同的方式进行管理。而且，当他们变稳定后，他们和其他 Kubernetes API 一样享受[定义支持政策](/docs/reference/deprecation-policy/)。出于这些原因，在合适的情况下它们优先于 *配置文件* 和 *标志* 被使用。 +*内置策略 API* ，例如 [ResourceQuota](/zh/docs/concepts/policy/resource-quotas/)、 +[PodSecurityPolicy](/zh/docs/concepts/policy/pod-security-policy/)、 +[NetworkPolicy](/zh/docs/concepts/services-networking/network-policies/) +和基于角色的权限控制 ([RBAC](/zh/docs/reference/access-authn-authz/rbac/))， +是内置的 Kubernetes API。API 通常与托管的 Kubernetes 服务和受控的 Kubernetes 安装一起使用。 +它们是声明性的，并使用与其他 Kubernetes 资源（如 Pod ）相同的约定，所以新的集群配置可以重复使用， +并以与应用程序相同的方式进行管理。 +而且，当它们变稳定后，也遵循和其他 Kubernetes API 一样的 +[支持政策](/zh/docs/reference/using-api/deprecation-policy/)。 +出于这些原因，在合适的情况下它们优先于 *配置文件* 和 *标志* 被使用。 <!-- ## Extensions @@ -89,16 +102,17 @@ Most cluster administrators will use a hosted or distribution instance of Kubernetes. As a result, most Kubernetes users will need to install extensions and fewer will need to author new ones. --> -## 扩展程序 +## 扩展程序 {#extension} 扩展程序是指对 Kubernetes 进行扩展和深度集成的软件组件。它们适合用于支持新的类型和新型硬件。 -大多数集群管理员会使用托管的或统一分发的 Kubernetes 实例。因此，大多数 Kubernetes 用户需要安装扩展程序，而且还有少部分用户甚至需要编写新的扩展程序。 +大多数集群管理员会使用托管的或统一分发的 Kubernetes 实例。 +因此，大多数 Kubernetes 用户需要安装扩展程序，而且还有少部分用户甚至需要编写新的扩展程序。 <!-- ## Extension Patterns --> -## 扩展模式 +## 扩展模式 {#extension-patterns} <!-- Kubernetes is designed to be automated by writing client programs. Any @@ -108,7 +122,10 @@ the guidance in this doc you can write highly available and robust automation. Automation generally works with any Kubernetes cluster, including hosted clusters and managed installations. --> -Kubernetes 的设计是通过编写客户端程序来实现自动化的。任何读和（或）写 Kubernetes API 的程序都可以提供有用的自动化工作。*自动化* 程序可以运行在集群之中或之外。按照本文档的指导，您可以编写出高可用的和健壮的自动化程序。自动化程序通常适用于任何 Kubernetes 集群，包括托管集群和受管理安装的集群。 +Kubernetes 的设计是通过编写客户端程序来实现自动化的。 +任何读和（或）写 Kubernetes API 的程序都可以提供有用的自动化工作。 +*自动化* 程序可以运行在集群之中或之外。按照本文档的指导，你可以编写出高可用的和健壮的自动化程序。 +自动化程序通常适用于任何 Kubernetes 集群，包括托管集群和受管理安装的集群。 <!-- There is a specific pattern for writing client programs that work well with @@ -120,9 +137,12 @@ calls out to a remote service, it is called a *Webhook*. The remote service is called a *Webhook Backend*. Like Controllers, Webhooks do add a point of failure. --> -*控制器* 模式是编写适合 Kubernetes 的客户端程序的一种特定模式。控制器通常读取一个对象的 `.spec` 字段，可能做出一些处理，然后更新对象的 `.status` 字段。 +*控制器（Controller）* 模式是编写适合 Kubernetes 的客户端程序的一种特定模式。 +控制器通常读取一个对象的 `.spec` 字段，可能做出一些处理，然后更新对象的 `.status` 字段。 -一个控制器是 Kubernetes 的一个客户端。而当 Kubernetes 作为客户端调用远程服务时，它被称为 *Webhook* ，远程服务称为 *Webhook* 后端。 和控制器类似，Webhooks 增加了一个失败点。 +一个控制器是 Kubernetes 的一个客户端。 +当 Kubernetes 作为客户端调用远程服务时，它被称为 *Webhook* ， +远程服务称为 *Webhook* 后端。 和控制器类似，Webhooks 增加了一个失败点。 <!-- In the webhook model, Kubernetes makes a network request to a remote service. @@ -133,7 +153,12 @@ and [Network Plugins](/docs/concepts/cluster-administration/network-plugins/)) and by kubectl. --> -在 webhook 模型里，Kubernetes 向远程服务发送一个网络请求。在 *二进制插件* 模型里，Kubernetes 执行一个二进制（程序）。二进制插件被 kubelet（如 [Flex 卷插件](https://github.com/kubernetes/community/blob/master/contributors/devel/flexvolume.md)和[网络插件](/docs/concepts/cluster-administration/network-plugins/))和 kubectl 所使用。 +在 webhook 模型里，Kubernetes 向远程服务发送一个网络请求。 +在 *可执行文件插件* 模型里，Kubernetes 执行一个可执行文件（程序）。 +可执行文件插件被 kubelet（如 +[Flex 卷插件](https://github.com/kubernetes/community/blob/master/contributors/devel/flexvolume.md)和 +[网络插件](/zh/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/)和 +`kubectl` 所使用。 <!-- Below is a diagram showing how the extensions points interact with the @@ -152,7 +177,7 @@ This diagram shows the extension points in a Kubernetes system. <img src="https://docs.google.com/drawings/d/e/2PACX-1vSH5ZWUO2jH9f34YHenhnCd14baEb4vT-pzfxeFC7NzdNqRDgdz4DDAVqArtH4onOGqh0bhwMX0zGBb/pub?w=425&h=809"> --> -## 扩展点 +## 扩展点 {#extension-points} 下图显示了 Kubernetes 系统的扩展点。 @@ -162,27 +187,38 @@ This diagram shows the extension points in a Kubernetes system. <!-- 1. Users often interact with the Kubernetes API using `kubectl`. [Kubectl plugins](/docs/tasks/extend-kubectl/kubectl-plugins/) extend the kubectl binary. They only affect the individual user's local environment, and so cannot enforce site-wide policies. -2. The apiserver handles all requests. Several types of extension points in the apiserver allow authenticating requests, or blocking them based on their content, editing content, and handling deletion. These are described in the [API Access Extensions](/docs/concepts/overview/extending#api-access-extensions) section. -3. The apiserver serves various kinds of *resources*. *Built-in resource kinds*, like `pods`, are defined by the Kubernetes project and can't be changed. You can also add resources that you define, or that other projects have defined, called *Custom Resources*, as explained in the [Custom Resources](/docs/concepts/overview/extending#user-defined-types) section. Custom Resources are often used with API Access Extensions. +2. The apiserver handles all requests. Several types of extension points in the apiserver allow authenticating requests, or blocking them based on their content, editing content, and handling deletion. These are described in the [API Access Extensions](/docs/concepts/extend-kubernetes/#api-access-extensions) section. +3. The apiserver serves various kinds of *resources*. *Built-in resource kinds*, like `pods`, are defined by the Kubernetes project and can't be changed. You can also add resources that you define, or that other projects have defined, called *Custom Resources*, as explained in the [Custom Resources](/docs/concepts/extend-kubernetes/#user-defined-types) section. Custom Resources are often used with API Access Extensions. 4. The Kubernetes scheduler decides which nodes to place pods on. There are several ways to extend scheduling. These are described in the [Scheduler Extensions](/docs/concepts/overview/extending#scheduler-extensions) section. 5. Much of the behavior of Kubernetes is implemented by programs called Controllers which are clients of the API-Server. Controllers are often used in conjunction with Custom Resources. 6. The kubelet runs on servers, and helps pods appear like virtual servers with their own IPs on the cluster network. [Network Plugins](/docs/concepts/overview/extending#network-plugins) allow for different implementations of pod networking. 7. The kubelet also mounts and unmounts volumes for containers. New types of storage can be supported via [Storage Plugins](/docs/concepts/overview/extending#storage-plugins). --> -1. 用户通常使用 `kubectl` 与 Kubernetes API 进行交互。[kubectl 插件](/docs/tasks/extend-kubectl/kubectl-plugins/)扩展了 kubectl 二进制程序。它们只影响个人用户的本地环境，因此不能执行站点范围的策略。 -2. apiserver 处理所有请求。apiserver 中的几种类型的扩展点允许对请求进行身份认证或根据其内容对其进行阻止、编辑内容以及处理删除操作。这些内容在[API 访问扩展](/docs/concepts/overview/extending#api-access-extensions)小节中描述。 -3. apiserver 提供各种 *资源* 。 *内置的资源种类* ，如 `pods`，由 Kubernetes 项目定义，不能更改。您还可以添加您自己定义的资源或其他项目已定义的资源，称为 自定义资源，如[自定义资源](/docs/concepts/overview/extending#user-defined-types)部分所述。自定义资源通常与 API 访问扩展一起使用。 -4. Kubernetes 调度器决定将 Pod 放置到哪个节点。有几种方法可以扩展调度器。这些内容在 [Scheduler Extensions](/docs/concepts/overview/extending#scheduler-extensions) 小节中描述。 -5. Kubernetes 的大部分行为都是由称为控制器的程序实现的，这些程序是 API-Server 的客户端。控制器通常与自定义资源一起使用。 -6. kubelet 在主机上运行，并帮助 pod 看起来就像在集群网络上拥有自己的 IP 的虚拟服务器。[网络插件](/docs/concepts/overview/extending#network-plugins)让您可以实现不同的 pod 网络。 -7. kubelet 也挂载和卸载容器的卷。新的存储类型可以通过[存储插件](/docs/concepts/overview/extending#storage-plugins)支持。 +1. 用户通常使用 `kubectl` 与 Kubernetes API 进行交互。 + [kubectl 插件](/zh/docs/tasks/extend-kubectl/kubectl-plugins/)扩展了 kubectl 可执行文件。 + 它们只影响个人用户的本地环境，因此不能执行站点范围的策略。 +2. API 服务器处理所有请求。API 服务器中的几种类型的扩展点允许对请求进行身份认证或根据其内容对其进行阻止、 + 编辑内容以及处理删除操作。这些内容在 + [API 访问扩展](/zh/docs/concepts/extend-kubernetes/#api-access-extensions)小节中描述。 +3. API 服务器提供各种 *资源（Resource）* 。 *内置的资源种类（Resource Kinds）* ，如 `pods`， + 由 Kubernetes 项目定义，不能更改。你还可以添加你自己定义的资源或其他项目已定义的资源， + 称为 *自定义资源（Custom Resource）*，如[自定义资源](/zh/docs/concepts/extend-kubernetes/#user-defined-types) + 部分所述。自定义资源通常与 API 访问扩展一起使用。 +4. Kubernetes 调度器决定将 Pod 放置到哪个节点。有几种方法可以扩展调度器。 + 这些内容在[调度器扩展](/zh/docs/concepts/extend-kubernetes/#scheduler-extensions) + 小节中描述。 +5. Kubernetes 的大部分行为都是由称为控制器（Controllers）的程序实现的，这些程序是 API 服务器的客户端。 + 控制器通常与自定义资源一起使用。 +6. `kubelet` 在主机上运行，并帮助 Pod 看起来就像在集群网络上拥有自己的 IP 的虚拟服务器。 + [网络插件](/zh/docs/concepts/extend-kubernetes/#network-plugins/)让你可以实现不同的 pod 网络。 +7. `kubelet` 也负责为容器挂载和卸载卷。新的存储类型可以通过 + [存储插件](/zh/docs/concepts/extend-kubernetes/#storage-plugins/)支持。 <!-- If you are unsure where to start, this flowchart can help. Note that some solutions may involve several types of extensions. --> - -如果您不确定从哪里开始扩展，此流程图可以提供帮助。请注意，某些解决方案可能涉及多种类型的扩展。 +如果你不确定从哪里开始扩展，下面流程图可以提供一些帮助。请注意，某些解决方案可能涉及多种类型的扩展。 <img src="https://docs.google.com/drawings/d/e/2PACX-1vRWXNNIVWFDqzDY0CsKZJY3AR8sDeFDXItdc5awYxVH8s0OLherMlEPVUpxPIB1CSUu7GPk7B2fEnzM/pub?w=1440&h=1080"> @@ -198,14 +234,16 @@ Do not use a Custom Resource as data storage for application, user, or monitorin For more about Custom Resources, see the [Custom Resources concept guide](/docs/concepts/api-extension/custom-resources/). --> -## API 扩展 -### 用户自定义类型 +## API 扩展 {#api-extensions} -如果您想定义新的控制器、应用程序配置对象或其他声明式 API，并使用 Kubernetes 工具（如 `kubectl`）管理它们，请考虑为 Kubernetes 添加一个自定义资源。 +### 用户自定义类型 {#user-defined-types} + +如果你想定义新的控制器、应用程序配置对象或其他声明式 API，并使用 Kubernetes 工具（如 `kubectl`）管理它们，请考虑为 Kubernetes 添加一个自定义资源。 不要使用自定义资源作为应用、用户或者监控数据的数据存储。 -有关自定义资源的更多信息，请查看[自定义资源概念指南](/docs/concepts/api-extension/custom-resources/)。 +有关自定义资源的更多信息，请查看 +[自定义资源概念指南](/zh/docs/concepts/extend-kubernetes/api-extension/custom-resources/)。 <!-- ### Combining New APIs with Automation @@ -214,7 +252,10 @@ The combination of a custom resource API and a control loop is called the [Opera --> ### 将新的 API 与自动化相结合 -自定义资源 API 和控制循环的组合称为 [操作者模式](/docs/concepts/extend-kubernetes/operator/)。操作者模式用于管理特定的，通常是有状态的应用程序。这些自定义 API 和控制循环还可用于控制其他资源，例如存储或策略。 +自定义资源 API 和控制循环的组合称为 +[操作者（Operator）模式](/zh/docs/concepts/extend-kubernetes/operator/)。 +操作者模式用于管理特定的，通常是有状态的应用程序。 +这些自定义 API 和控制循环还可用于控制其他资源，例如存储或策略。 <!-- ### Changing Built-in Resources @@ -224,7 +265,9 @@ Adding an API does not directly let you affect the behavior of existing APIs (e. --> ### 改变内置资源 -当您通过添加自定义资源来扩展 Kubernetes API 时，添加的资源始终属于新的 API 组。您不能替换或更改已有的 API 组。添加 API 不会直接影响现有 API（例如 Pod ）的行为，但是 API 访问扩展可以。 +当你通过添加自定义资源来扩展 Kubernetes API 时，添加的资源始终属于新的 API 组。 +你不能替换或更改已有的 API 组。 +添加 API 不会直接影响现有 API（例如 Pod ）的行为，但是 API 访问扩展可以。 <!-- ### API Access Extensions @@ -235,13 +278,17 @@ Each of these steps offers extension points. Kubernetes has several built-in authentication methods that it supports. It can also sit behind an authenticating proxy, and it can send a token from an Authorization header to a remote service for verification (a webhook). All of these methods are covered in the [Authentication documentation](/docs/reference/access-authn-authz/authentication/). --> -### API 访问扩展 +### API 访问扩展 {#api-access-extensions} -当请求到达 Kubernetes API Server 时，它首先被要求进行用户认证，然后要进行授权检查，接着受到各种类型的准入控制的检查。有关此流程的更多信息，请参阅 [Kubernetes API访问控制](/docs/reference/access-authn-authz/controlling-access/)。 +当请求到达 Kubernetes API Server 时，它首先被要求进行用户认证，然后要进行授权检查， +接着受到各种类型的准入控制的检查。有关此流程的更多信息，请参阅 +[Kubernetes API 访问控制](/zh/docs/reference/access-authn-authz/controlling-access/)。 上述每个步骤都提供了扩展点。 -Kubernetes 有几个它支持的内置认证方法。它还可以位于身份验证代理之后，并将授权 header 中的令牌发送给远程服务进行验证（webhook）。所有这些方法都在[身份验证文档](/docs/reference/access-authn-authz/authentication/)中介绍。 +Kubernetes 有几个它支持的内置认证方法。它还可以位于身份验证代理之后，并将 Authorziation 头部 +中的令牌发送给远程服务（webhook）进行验证。所有这些方法都在 +[身份验证文档](/zh/docs/reference/access-authn-authz/authentication/)中介绍。 <!-- ### Authentication @@ -250,20 +297,26 @@ Kubernetes 有几个它支持的内置认证方法。它还可以位于身份验 Kubernetes provides several built-in authentication methods, and an [Authentication webhook](/docs/reference/access-authn-authz/authentication/#webhook-token-authentication) method if those don't meet your needs. --> -### 身份认证 +### 身份认证 {#authentication} -[身份认证](/docs/reference/access-authn-authz/authentication/)将所有请求中的 header 或证书映射为发出请求的客户端的用户名。 +[身份认证](/zh/docs/reference/access-authn-authz/authentication/) +将所有请求中的头部字段或证书映射为发出请求的客户端的用户名。 -Kubernetes 提供了几种内置的身份认证方法，如果这些方法不符合您的需求，可以使用[身份认证 webhook](/docs/reference/access-authn-authz/authentication/#webhook-token-authentication) 方法。 +Kubernetes 提供了几种内置的身份认证方法，如果这些方法不符合你的需求，可以使用 +[身份认证 Webhook](/zh/docs/reference/access-authn-authz/authentication/#webhook-token-authentication) 方法。 <!-- ### Authorization [Authorization](/docs/reference/access-authn-authz/webhook/) determines whether specific users can read, write, and do other operations on API resources. It just works at the level of whole resources -- it doesn't discriminate based on arbitrary object fields. If the built-in authorization options don't meet your needs, and [Authorization webhook](/docs/reference/access-authn-authz/webhook/) allows calling out to user-provided code to make an authorization decision. --> -### 授权 +### 鉴权 {#authorization} -[授权](/docs/reference/access-authn-authz/webhook/)决定特定用户是否可以对 API 资源执行读取、写入以及其他操作。它只是在整个资源的层面上工作 -- 它不基于任意的对象字段进行区分。如果内置授权选项不能满足您的需求，[授权 webhook](/docs/reference/access-authn-authz/webhook/) 允许调用用户提供的代码来作出授权决定。 +[鉴权组件](/zh/docs/reference/access-authn-authz/authorization/)决定特定用户是否可以对 +API 资源执行读取、写入以及其他操作。它只是在整个资源的层面上工作 -- +它不基于任意的对象字段进行区分。如果内置授权选项不能满足你的需求， +[鉴权 Webhook](/zh/docs/reference/access-authn-authz/webhook/) +允许调用用户提供的代码来作出授权决定。 <!-- ### Dynamic Admission Control @@ -275,10 +328,15 @@ After a request is authorized, if it is a write operation, it also goes through --> ### 动态准入控制 -在请求被授权之后，如果是写入操作，它还将进入[准入控制](/docs/reference/access-authn-authz/admission-controllers/)步骤。除了内置的步骤之外，还有几个扩展： +在请求被授权之后，如果是写入操作，它还将进入 +[准入控制](/zh/docs/reference/access-authn-authz/admission-controllers/) +步骤。除了内置的步骤之外，还有几个扩展： -* [镜像策略 webhook](/docs/reference/access-authn-authz/admission-controllers/#imagepolicywebhook) 限制了哪些镜像可以在容器中运行。 -* 为了进行灵活的准入控制决策，可以使用通用的 [Admission webhook](/docs/reference/access-authn-authz/extensible-admission-controllers/#admission-webhooks)。Admission Webhooks 可以拒绝创建或更新操作。 +* [镜像策略 Webhook](/zh/docs/reference/access-authn-authz/admission-controllers/#imagepolicywebhook) + 限制哪些镜像可以在容器中运行。 +* 为了进行灵活的准入控制决策，可以使用通用的 + [准入 Webhook](/zh/docs/reference/access-authn-authz/extensible-admission-controllers/#admission-webhooks)。 + 准入 Webhooks 可以拒绝创建或更新操作。 <!-- ## Infrastructure Extensions @@ -292,11 +350,11 @@ Kubelet call a Binary Plugin to mount the volume. --> ## 基础设施扩展 - ### 存储插件 [Flex Volumes](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/storage/flexvolume-deployment.md -) 允许用户挂载无内置插件支持的卷类型，它通过 Kubelet 调用一个二进制插件来挂载卷。 +) +允许用户挂载无内置插件支持的卷类型，它通过 Kubelet 调用一个可执行文件插件来挂载卷。 <!-- ### Device Plugins @@ -305,18 +363,22 @@ Device plugins allow a node to discover new Node resources (in addition to the builtin ones like cpu and memory) via a [Device Plugin](/docs/concepts/cluster-administration/device-plugins/). --> -### 设备插件 +### 设备插件 {#device-plugins} -设备插件允许节点通过[设备插件](/docs/concepts/cluster-administration/device-plugins/)发现新的节点资源（除了内置的 CPU 和内存之外）。 +设备插件允许节点通过 +[设备插件](/zh/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins/). +发现新的节点资源（除了内置的 CPU 和内存之外）。 <!-- ### Network Plugins Different networking fabrics can be supported via node-level [Network Plugins](/docs/admin/network-plugins/). --> -### 网络插件 +### 网络插件 {#network-plugins} -不同的网络结构可以通过节点级的[网络插件](/docs/admin/network-plugins/)支持。 +不同的网络结构可以通过节点级的 +[网络插件](/zh/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/) +得到支持。 <!-- ### Scheduler Extensions @@ -335,20 +397,20 @@ The scheduler also supports a that permits a webhook backend (scheduler extension) to filter and prioritize the nodes chosen for a pod. --> -### 调度器扩展 - -调度器是一种特殊类型的控制器，用于监视 pod 并将其分配到节点。默认的调度器可以完全被替换，而继续使用其他 Kubernetes 组件，或者可以同时运行[多个调度器](/docs/tasks/administer-cluster/configure-multiple-schedulers/)。 - -这是一个重要的任务，几乎所有的 Kubernetes 用户都发现他们不需要修改调度器。 - -调度器也支持 [webhook](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/scheduling/scheduler_extender.md)，它允许一个 webhook 后端（调度器扩展程序）为 pod 筛选节点和确定节点的优先级。 +### 调度器扩展 {#scheduler-extensions} +调度器是一种特殊类型的控制器，用于监视 pod 并将其分配到节点。 +默认的调度器可以完全被替换，而继续使用其他 Kubernetes 组件，或者可以同时运行 +[多个调度器](/zh/docs/tasks/administer-cluster/configure-multiple-schedulers/)。 +这是一个不太轻松的任务，几乎所有的 Kubernetes 用户都会意识到他们并不需要修改调度器。 +调度器也支持 +[Webhook](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/scheduling/scheduler_extender.md)， +它允许使用一个 Webhook 后端（调度器扩展程序）为 Pod 筛选节点和确定节点的优先级。 ## {{% heading "whatsnext" %}} - <!-- * Learn more about [Custom Resources](/docs/concepts/api-extension/custom-resources/) * Learn about [Dynamic admission control](/docs/reference/access-authn-authz/extensible-admission-controllers/) @@ -358,12 +420,12 @@ the nodes chosen for a pod. * Learn about [kubectl plugins](/docs/tasks/extend-kubectl/kubectl-plugins/) * Learn about the [Operator pattern](/docs/concepts/extend-kubernetes/operator/) --> -* 详细了解[自定义资源](/docs/concepts/api-extension/custom-resources/) -* 了解[动态准入控制](/docs/reference/access-authn-authz/extensible-admission-controllers/) +* 详细了解[自定义资源](/zh/docs/concepts/extend-kubernetes/api-extension/custom-resources/) +* 了解[动态准入控制](/zh/docs/reference/access-authn-authz/extensible-admission-controllers/) * 详细了解基础设施扩展 - * [网络插件](/docs/concepts/cluster-administration/network-plugins/) - * [设备插件](/docs/concepts/cluster-administration/device-plugins/) -* 了解 [kubectl 插件](/docs/tasks/extend-kubectl/kubectl-plugins/) -* 了解[操作者模式](/docs/concepts/extend-kubernetes/operator/) + * [网络插件](/zh/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/) + * [设备插件](/zh/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins/) +* 了解 [kubectl 插件](/zh/docs/tasks/extend-kubectl/kubectl-plugins/) +* 了解[操作者模式](/zh/docs/concepts/extend-kubernetes/operator/) diff --git a/content/zh/docs/concepts/extend-kubernetes/operator.md b/content/zh/docs/concepts/extend-kubernetes/operator.md index c34a54676e..5cf55cbb8c 100644 --- a/content/zh/docs/concepts/extend-kubernetes/operator.md +++ b/content/zh/docs/concepts/extend-kubernetes/operator.md @@ -5,11 +5,9 @@ weight: 30 --- <!-- ---- title: Operator pattern content_type: concept weight: 30 ---- --> <!-- overview --> @@ -21,9 +19,9 @@ to manage applications and their components. Operators follow Kubernetes principles, notably the [control loop](/docs/concepts/#kubernetes-control-plane). --> -Operator 是 Kubernetes 的扩展软件，它利用[自定义资源](/docs/concepts/extend-kubernetes/api-extension/custom-resources/)管理应用及其组件。 -Operator 遵循 Kubernetes 的理念，特别是在[控制回路](/docs/concepts/#kubernetes-control-plane)方面。 - +Operator 是 Kubernetes 的扩展软件，它利用 +[自定义资源](/zh/docs/concepts/extend-kubernetes/api-extension/custom-resources/)管理应用及其组件。 +Operator 遵循 Kubernetes 的理念，特别是在[控制回路](/zh/docs/concepts/#kubernetes-control-plane)方面。 <!-- body --> @@ -40,7 +38,6 @@ People who run workloads on Kubernetes often like to use automation to take care of repeatable tasks. The Operator pattern captures how you can write code to automate a task beyond what Kubernetes itself provides. --> - ## 初衷 Operator 模式旨在捕获（正在管理一个或一组服务的）运维人员的关键目标。 @@ -62,14 +59,14 @@ of Kubernetes itself. Operators are clients of the Kubernetes API that act as controllers for a [Custom Resource](/docs/concepts/api-extension/custom-resources/). --> - ## Kubernetes 上的 Operator Kubernetes 为自动化而生。无需任何修改，您即可以从 Kubernetes 核心中获得许多内置的自动化功能。 您可以使用 Kubernetes 自动化部署和运行工作负载， *甚至* 可以自动化 Kubernetes 自身。 Kubernetes {{< glossary_tooltip text="控制器" term_id="controller" >}} 使您无需修改 Kubernetes 自身的代码，即可以扩展集群的行为。 -Operator 是 Kubernetes API 的客户端，充当[自定义资源](/docs/concepts/api-extension/custom-resources/)的控制器。 +Operator 是 Kubernetes API 的客户端，充当 +[自定义资源](/zh/docs/concepts/extend-kubernetes/api-extension/custom-resources/)的控制器。 <!-- ## An example Operator {#example} @@ -86,7 +83,6 @@ Some of the things that you can use an operator to automate include: * choosing a leader for a distributed application without an internal member election process --> - ## Operator 示例 {#example} 使用 Operator 可以自动化的事情包括： @@ -147,7 +143,6 @@ The Controller will normally run outside of the much as you would run any containerized application. For example, you can run the controller in your cluster as a Deployment. --> - ## 部署 Operator 部署 Operator 最常见的方法是将自定义资源及其关联的控制器添加到您的集群中。跟运行容器化应用一样，Controller 通常会运行在 {{< glossary_tooltip text="控制平面" term_id="control-plane" >}} 之外。例如，您可以在集群中将控制器作为 Deployment 运行。 @@ -198,13 +193,11 @@ that can act as a [client for the Kubernetes API](/docs/reference/using-api/clie 如果生态系统中没可以实现您目标的 Operator，您可以自己编写代码。在[接下来](#what-s-next)一节中，您会找到编写自己的云原生 Operator 需要的库和工具的链接。 -您还可以使用任何支持 [Kubernetes API 客户端](/docs/reference/using-api/client-libraries/)的语言或运行时来实现 Operator（即控制器）。 - - +您还可以使用任何支持 [Kubernetes API 客户端](/zh/docs/reference/using-api/client-libraries/) +的语言或运行时来实现 Operator（即控制器）。 ## {{% heading "whatsnext" %}} - <!-- * Learn more about [Custom Resources](/docs/concepts/extend-kubernetes/api-extension/custom-resources/) * Find ready-made operators on [OperatorHub.io](https://operatorhub.io/) to suit your use case @@ -219,7 +212,7 @@ that can act as a [client for the Kubernetes API](/docs/reference/using-api/clie * Read an [article](https://cloud.google.com/blog/products/containers-kubernetes/best-practices-for-building-kubernetes-operators-and-stateful-apps) from Google Cloud about best practices for building Operators --> -* 详细了解[自定义资源](/docs/concepts/extend-kubernetes/api-extension/custom-resources/) +* 详细了解[自定义资源](/zh/docs/concepts/extend-kubernetes/api-extension/custom-resources/) * 在 [OperatorHub.io](https://operatorhub.io/) 上找到现成的、适合您的 Operator * 借助已有的工具来编写您自己的 Operator，例如： * [KUDO](https://kudo.dev/) (Kubernetes 通用声明式 Operator) @@ -228,6 +221,7 @@ that can act as a [client for the Kubernetes API](/docs/reference/using-api/clie * [Operator 框架](https://github.com/operator-framework/getting-started) * [发布](https://operatorhub.io/)您的 Operator，让别人也可以使用 * 阅读 [CoreOS 原文](https://coreos.com/blog/introducing-operators.html)，其介绍了 Operator 介绍 -* 阅读这篇来自谷歌云的关于构建 Operator 最佳实践的[文章](https://cloud.google.com/blog/products/containers-kubernetes/best-practices-for-building-kubernetes-operators-and-stateful-apps) +* 阅读这篇来自谷歌云的关于构建 Operator 最佳实践的 + [文章](https://cloud.google.com/blog/products/containers-kubernetes/best-practices-for-building-kubernetes-operators-and-stateful-apps) diff --git a/content/zh/docs/concepts/extend-kubernetes/service-catalog.md b/content/zh/docs/concepts/extend-kubernetes/service-catalog.md index 0ee381052c..29b12f6bea 100644 --- a/content/zh/docs/concepts/extend-kubernetes/service-catalog.md +++ b/content/zh/docs/concepts/extend-kubernetes/service-catalog.md @@ -1,22 +1,18 @@ --- title: 服务目录 -reviewers: -- chenopis content_type: concept weight: 40 --- <!-- ---- title: Service Catalog reviewers: - chenopis content_type: concept weight: 40 ---- --> <!-- overview --> -{{< glossary_definition term_id="service-catalog" length="all" prepend="" >}} +{{< glossary_definition term_id="service-catalog" length="all" prepend="服务目录（Service Catalog）是" >}} <!-- A service broker, as defined by the [Open service broker API spec](https://github.com/openservicebrokerapi/servicebroker/blob/v2.13/spec.md), is an endpoint for a set of managed services offered and maintained by a third-party, which could be a cloud provider such as AWS, GCP, or Azure. @@ -24,13 +20,12 @@ Some examples of managed services are Microsoft Azure Cloud Queue, Amazon Simple Using Service Catalog, a {{< glossary_tooltip text="cluster operator" term_id="cluster-operator" >}} can browse the list of managed services offered by a service broker, provision an instance of a managed service, and bind with it to make it available to an application in the Kubernetes cluster. --> -服务代理是由[开放服务代理 API 规范](https://github.com/openservicebrokerapi/servicebroker/blob/v2.13/spec.md)定义的一组托管服务的终结点，由第三方提供并维护，其中的第三方可以是 AWS，GCP 或 Azure 等云服务提供商。 -托管服务的一些示例是 Microsoft Azure Cloud Queue，Amazon Simple Queue Service 和 Google Cloud Pub/Sub，但它们是可以使用应用程序的任何软件产品。 - -使用服务目录，集群操作者可以浏览其提供的托管服务列表，提供托管服务实例并与之绑定，以使其可以被 Kubernetes 集群中的应用程序使用。 - - +服务代理（Service Broker）是由[Open Service Broker API 规范](https://github.com/openservicebrokerapi/servicebroker/blob/v2.13/spec.md)定义的一组托管服务的端点，这些服务由第三方提供并维护，其中的第三方可以是 AWS、GCP 或 Azure 等云服务提供商。 +托管服务的一些示例是 Microsoft Azure Cloud Queue、Amazon Simple Queue Service 和 Google Cloud Pub/Sub，但它们可以是应用程序能够使用的任何软件交付物。 +使用服务目录，{{< glossary_tooltip text="集群操作员" term_id="cluster-operator" >}} +可以浏览某服务代理所提供的托管服务列表，供应托管服务实例并与之绑定， +以使其可以被 Kubernetes 集群中的应用程序使用。 <!-- body --> <!-- @@ -46,11 +41,15 @@ The application can simply use it as a service. --> ## 示例用例 -应用开发者希望使用消息队列作为其在 Kubernetes 集群中运行的应用程序的一部分。 -但是，它们不想承受建立这种服务的开销，也不想自行管理。幸运的是，有一家云服务提供商通过它们的服务代理将消息队列作为托管服务提供。 +{{< glossary_tooltip text="应用开发人员" term_id="application-developer" >}}， +希望使用消息队列，作为其在 Kubernetes 集群中运行的应用程序的一部分。 +但是，他们不想承受构造这种服务的开销，也不想自行管理。 +幸运的是，有一家云服务提供商通过其服务代理以托管服务的形式提供消息队列服务。 -集群运维人员可以设置服务目录并使用它与云服务提供商的服务代理 通信，以此提供消息队列服务的实例并使其对 Kubernetes 中的应用程序可用。 -因此，应用开发者可以不用关心消息队列的实现细节，也不用对其进行管理。它们的应用程序可以简单的将其作为服务使用。 +集群操作员可以设置服务目录并使用它与云服务提供商的服务代理通信，进而部署消息队列服务的实例 +并使其对 Kubernetes 中的应用程序可用。 +应用开发者于是可以不关心消息队列的实现细节，也不用对其进行管理。 +他们的应用程序可以简单的将其作为服务使用。 <!-- ## Architecture @@ -59,18 +58,20 @@ Service Catalog uses the [Open service broker API](https://github.com/openservic It is implemented as an extension API server and a controller, using etcd for storage. It also uses the [aggregation layer](/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation/) available in Kubernetes 1.7+ to present its API. -<br> - ![Service Catalog Architecture](/images/docs/service-catalog-architecture.svg) --> -## 架构 -服务目录使用[开放服务代理 API](https://github.com/openservicebrokerapi/servicebroker) 与服务代理进行通信，并作为 Kubernetes API Server 的中介，以便协商首要规定并获取应用程序使用托管服务的必要凭据。 +## 架构 {#architecture} -它被实现为一个扩展 API 服务和一个控制器管理器，使用 Etcd 作为存储。它还使用了 Kubernetes 1.7+ 版本中提供的 [aggregation layer](/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation/) 来呈现其 API。 +服务目录使用[Open Service Broker API](https://github.com/openservicebrokerapi/servicebroker) +与服务代理进行通信，并作为 Kubernetes API 服务器的中介，以便协商启动部署和获取 +应用程序使用托管服务时必须的凭据。 -<br> +服务目录实现为一个扩展 API 服务器和一个控制器，使用 Etcd 提供存储。 +它还使用了 Kubernetes 1.7 之后版本中提供的 +[聚合层](/zh/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation/) +来呈现其 API。 -![Service Catalog Architecture](/images/docs/service-catalog-architecture.svg) +![服务目录架构](/images/docs/service-catalog-architecture.svg) <!-- ### API Resources @@ -89,11 +90,11 @@ When a new `ServiceInstance` resource is created, the Service Catalog controller These are created by cluster operators who want their applications to make use of a `ServiceInstance`. Upon creation, the Service Catalog controller creates a Kubernetes `Secret` containing connection details and credentials for the Service Instance, which can be mounted into Pods. --> -## API 资源 +## API 资源 {#api-resources} 服务目录安装 `servicecatalog.k8s.io` API 并提供以下 Kubernetes 资源： -* `ClusterServiceBroker`：服务目录的集群内代表，封装了它的服务连接细节。集群运维人员创建和管理这些资源，并希望使用该代理服务在集群中提供新类型的托管服务。 +* `ClusterServiceBroker`：服务目录的集群内表现形式，封装了其服务连接细节。集群运维人员创建和管理这些资源，并希望使用该代理服务在集群中提供新类型的托管服务。 * `ClusterServiceClass`：由特定服务代理提供的托管服务。当新的 `ClusterServiceBroker` 资源被添加到集群时，服务目录控制器将连接到服务代理以获取可用的托管服务列表。然后为每个托管服务创建对应的新 `ClusterServiceClass` 资源。 * `ClusterServicePlan`：托管服务的特定产品。例如托管服务可能有不同的计划可用，如免费版本和付费版本，或者可能有不同的配置选项，例如使用 SSD 存储或拥有更多资源。与 `ClusterServiceClass` 类似，当一个新的 `ClusterServiceBroker` 被添加到集群时，服务目录会为每个托管服务的每个可用服务计划创建对应的新 `ClusterServicePlan` 资源。 * `ServiceInstance`：`ClusterServiceClass` 提供的示例。由集群运维人员创建，以使托管服务的特定实例可供一个或多个集群内应用程序使用。当创建一个新的 `ServiceInstance` 资源时，服务目录控制器将连接到相应的服务代理并指示它调配服务实例。 @@ -107,11 +108,11 @@ Service Catalog supports these methods of authentication: * Basic (username/password) * [OAuth 2.0 Bearer Token](https://tools.ietf.org/html/rfc6750) --> -### 认证 +### 认证 {#authentication} 服务目录支持这些认证方法： -* 基础认证（用户名/密码） +* 基本认证（用户名/密码） * [OAuth 2.0 不记名令牌](https://tools.ietf.org/html/rfc6750) <!-- @@ -126,7 +127,7 @@ A cluster operator can use Service Catalog API Resources to provision managed se --> ## 使用方式 -集群运维人员可以使用服务目录 API 资源来提供托管服务并使其在 Kubernetes 集群内可用。涉及的步骤有： +集群运维人员可以使用服务目录 API 资源来供应托管服务并使其在 Kubernetes 集群内可用。涉及的步骤有： 1. 列出服务代理提供的托管服务和服务计划。 2. 配置托管服务的新实例。 @@ -153,7 +154,28 @@ spec: # with the service broker, such as bearer token info or a caBundle for TLS. ##### ``` +--> +### 列出托管服务和服务计划 +首先，集群运维人员在 `servicecatalog.k8s.io` 组内创建一个 `ClusterServiceBroker` 资源。此资源包含访问服务代理终结点所需的 URL 和连接详细信息。 + +这是一个 `ClusterServiceBroker` 资源的例子： + +```yaml +apiVersion: servicecatalog.k8s.io/v1beta1 +kind: ClusterServiceBroker +metadata: + name: cloud-broker +spec: + # 指向服务代理的末端。(这里的 URL 是无法使用的) + url: https://servicebroker.somecloudprovider.com/v1alpha1/projects/service-catalog/brokers/default + ##### + # 这里可以添加额外的用来与服务代理通信的属性值, + # 例如持有者令牌信息或者 TLS 的 CA 包 + ##### +``` + +<!-- The following is a sequence diagram illustrating the steps involved in listing managed services and Plans available from a service broker: ![List Services](/images/docs/service-catalog-list.svg) @@ -161,7 +183,18 @@ The following is a sequence diagram illustrating the steps involved in listing m 1. Once the `ClusterServiceBroker` resource is added to Service Catalog, it triggers a call to the external service broker for a list of available services. 1. The service broker returns a list of available managed services and a list of Service Plans, which are cached locally as `ClusterServiceClass` and `ClusterServicePlan` resources respectively. 1. A cluster operator can then get the list of available managed services using the following command: +--> +下面的时序图展示了从服务代理列出可用托管服务和计划所涉及的各个步骤： +![列举服务](/images/docs/service-catalog-list.svg) + +1. 一旦 `ClusterServiceBroker` 资源被添加到了服务目录之后，将会触发一个到外部服务代理的 + 调用，以列举所有可用服务； +1. 服务代理返回可用的托管服务和服务计划列表，这些列表将本地缓存在 `ClusterServiceClass` + 和 `ClusterServicePlan` 资源中。 +1. 集群运维人员接下来可以使用以下命令获取可用托管服务的列表： + +<!-- kubectl get clusterserviceclasses -o=custom-columns=SERVICE\ NAME:.metadata.name,EXTERNAL\ NAME:.spec.externalName It should output a list of service names with a format similar to: @@ -180,51 +213,34 @@ The following is a sequence diagram illustrating the steps involved in listing m 86064792-7ea2-467b-af93-ac9694d96d52 service-plan-name ... ... --> -### 列出托管服务和服务计划 -首先，集群运维人员在 `servicecatalog.k8s.io` 组内创建一个 `ClusterServiceBroker` 资源。此资源包含访问服务代理终结点所需的 URL 和连接详细信息。 + ```shell + kubectl get clusterserviceclasses \ + -o=custom-columns=SERVICE\ NAME:.metadata.name,EXTERNAL\ NAME:.spec.externalName + ``` -这是一个 `ClusterServiceBroker` 资源的例子： + 它应该输出一个和以下格式类似的服务名称列表： -```yaml -apiVersion: servicecatalog.k8s.io/v1beta1 -kind: ClusterServiceBroker -metadata: - name: cloud-broker -spec: - # Points to the endpoint of a service broker. (This example is not a working URL.) - url: https://servicebroker.somecloudprovider.com/v1alpha1/projects/service-catalog/brokers/default - ##### - # Additional values can be added here, which may be used to communicate - # with the service broker, such as bearer token info or a caBundle for TLS. - ##### -``` + ``` + SERVICE NAME EXTERNAL NAME + 4f6e6cf6-ffdd-425f-a2c7-3c9258ad2468 cloud-provider-service + ... ... + ``` -下面的顺序图展示了从一个服务代理列出可用托管服务和计划所有涉及的步骤： + 他们还可以使用以下命令查看可用的服务计划： -![List Services](/images/docs/service-catalog-list.svg) - -1. 一旦 `ClusterServiceBroker` 资源被添加到了服务目录之后，将会触发一个到外部服务代理的 List Services 调用。 -1. 服务代理返回可用的托管服务和服务计划列表，这些列表将本地缓存在 `ClusterServiceClass` 和 `ClusterServicePlan` 资源中。 -1. 然后集群运维人员可以使用以下命令获取可用托管服务的列表： - - kubectl get clusterserviceclasses -o=custom-columns=SERVICE\ NAME:.metadata.name,EXTERNAL\ NAME:.spec.externalName - - 它应该输出一个和以下格式类似的服务名称列表： - - SERVICE NAME EXTERNAL NAME - 4f6e6cf6-ffdd-425f-a2c7-3c9258ad2468 cloud-provider-service - ... ... - - 他们还可以使用以下命令查看可用的服务计划： - - kubectl get clusterserviceplans -o=custom-columns=PLAN\ NAME:.metadata.name,EXTERNAL\ NAME:.spec.externalName + ```shell + kubectl get clusterserviceplans \ + -o=custom-columns=PLAN\ NAME:.metadata.name,EXTERNAL\ NAME:.spec.externalName + ``` 它应该输出一个和以下格式类似的服务计划列表： - PLAN NAME EXTERNAL NAME - 86064792-7ea2-467b-af93-ac9694d96d52 service-plan-name - ... ... + ``` + PLAN NAME EXTERNAL NAME + 86064792-7ea2-467b-af93-ac9694d96d52 service-plan-name + ... ... + ``` <!-- ### Provisioning a new instance @@ -248,20 +264,12 @@ spec: # which may be used by the service broker. ##### ``` - -The following sequence diagram illustrates the steps involved in provisioning a new instance of a managed service: - -![Provision a Service](/images/docs/service-catalog-provision.svg) - -1. When the `ServiceInstance` resource is created, Service Catalog initiates a call to the external service broker to provision an instance of the service. -1. The service broker creates a new instance of the managed service and returns an HTTP response. -1. A cluster operator can then check the status of the instance to see if it is ready. --> -### 配置一个新实例 +### 供应一个新实例 集群运维人员 可以通过创建一个 `ServiceInstance` 资源来启动一个新实例的配置。 -这是一个 `ServiceInstance` 资源的例子： +下面是一个 `ServiceInstance` 资源的例子： ```yaml apiVersion: servicecatalog.k8s.io/v1beta1 @@ -270,22 +278,31 @@ metadata: name: cloud-queue-instance namespace: cloud-apps spec: - # References one of the previously returned services + # 引用之前返回的服务之一 clusterServiceClassExternalName: cloud-provider-service clusterServicePlanExternalName: service-plan-name ##### - # Additional parameters can be added here, - # which may be used by the service broker. + # 这里可添加额外的参数，供服务代理使用 ##### ``` -以下顺序图展示了配置托管服务新实例所涉及的步骤： +<!-- +The following sequence diagram illustrates the steps involved in provisioning a new instance of a managed service: ![Provision a Service](/images/docs/service-catalog-provision.svg) -1. 当创建 `ServiceInstance` 资源时，服务目录将启动一个到外部服务代理的配置实例调用。 +1. When the `ServiceInstance` resource is created, Service Catalog initiates a call to the external service broker to provision an instance of the service. +1. The service broker creates a new instance of the managed service and returns an HTTP response. +1. A cluster operator can then check the status of the instance to see if it is ready. +--> +以下时序图展示了配置托管服务新实例所涉及的步骤： + +![供应服务](/images/docs/service-catalog-provision.svg) + +1. 创建 `ServiceInstance` 资源时，服务目录将启动一个到外部服务代理的调用， + 请求供应一个实例。 1. 服务代理创建一个托管服务的新实例并返回 HTTP 响应。 -1. 然后集群运维人员可以检查实例的状态是否就绪。 +1. 接下来，集群运维人员可以检查实例的状态是否就绪。 <!-- ### Binding to a managed service @@ -308,14 +325,6 @@ spec: # service account parameters, which may be used by the service broker. ##### ``` - -The following sequence diagram illustrates the steps involved in binding to a managed service instance: - -![Bind to a managed service](/images/docs/service-catalog-bind.svg) - -1. After the `ServiceBinding` is created, Service Catalog makes a call to the external service broker requesting the information necessary to bind with the service instance. -1. The service broker enables the application permissions/roles for the appropriate service account. -1. The service broker returns the information necessary to connect and access the managed service instance. This is provider and service-specific so the information returned may differ between Service Providers and their managed services. --> ### 绑定到托管服务 @@ -333,15 +342,23 @@ spec: instanceRef: name: cloud-queue-instance ##### - # Additional information can be added here, such as a secretName or - # service account parameters, which may be used by the service broker. + # 这里可以添加供服务代理使用的额外信息，例如 Secret 名称或者服务账号参数， ##### ``` -以下顺序图展示了绑定到托管服务实例的步骤： +<!-- +The following sequence diagram illustrates the steps involved in binding to a managed service instance: ![Bind to a managed service](/images/docs/service-catalog-bind.svg) +1. After the `ServiceBinding` is created, Service Catalog makes a call to the external service broker requesting the information necessary to bind with the service instance. +1. The service broker enables the application permissions/roles for the appropriate service account. +1. The service broker returns the information necessary to connect and access the managed service instance. This is provider and service-specific so the information returned may differ between Service Providers and their managed services. +--> +以下顺序图展示了绑定到托管服务实例的步骤： + +![绑定到托管服务](/images/docs/service-catalog-bind.svg) + 1. 在创建 `ServiceBinding` 之后，服务目录调用外部服务代理，请求绑定服务实例所需的信息。 1. 服务代理为相应服务账户启用应用权限/角色。 1. 服务代理返回连接和访问托管服务示例所需的信息。这是由提供商和服务特定的，故返回的信息可能因服务提供商和其托管服务而有所不同。 @@ -362,7 +379,7 @@ These pieces of information are stored in secrets that the application in the cl <br> -![Map connection credentials](/images/docs/service-catalog-map.svg) +![映射连接凭据](/images/docs/service-catalog-map.svg) <!-- #### Pod configuration File @@ -370,42 +387,14 @@ These pieces of information are stored in secrets that the application in the cl One method to perform this mapping is to use a declarative Pod configuration. The following example describes how to map service account credentials into the application. A key called `sa-key` is stored in a volume named `provider-cloud-key`, and the application mounts this volume at `/var/secrets/provider/key.json`. The environment variable `PROVIDER_APPLICATION_CREDENTIALS` is mapped from the value of the mounted file. - -```yaml -... - spec: - volumes: - - name: provider-cloud-key - secret: - secretName: sa-key - containers: -... - volumeMounts: - - name: provider-cloud-key - mountPath: /var/secrets/provider - env: - - name: PROVIDER_APPLICATION_CREDENTIALS - value: "/var/secrets/provider/key.json" -``` - -The following example describes how to map secret values into application environment variables. In this example, the messaging queue topic name is mapped from a secret named `provider-queue-credentials` with a key named `topic` to the environment variable `TOPIC`. - - -```yaml -... - env: - - name: "TOPIC" - valueFrom: - secretKeyRef: - name: provider-queue-credentials - key: topic -``` --> #### Pod 配置文件 执行此映射的一种方法是使用声明式 Pod 配置。 -以下示例描述了如何将服务账户凭据映射到应用程序中。名为 `sa-key` 的密钥保存在一个名为 `provider-cloud-key` 的卷中，应用程序会将该卷挂载在 `/var/secrets/provider/key.json` 路径下。环境变量 `PROVIDER_APPLICATION_CREDENTIALS` 将映射为挂载文件的路径。 +以下示例描述了如何将服务账户凭据映射到应用程序中。名为 `sa-key` 的密钥保存在一个名为 +`provider-cloud-key` 的卷中，应用程序会将该卷挂载在 `/var/secrets/provider/key.json` +路径下。环境变量 `PROVIDER_APPLICATION_CREDENTIALS` 将映射为挂载文件的路径。 ```yaml ... @@ -424,8 +413,12 @@ The following example describes how to map secret values into application enviro value: "/var/secrets/provider/key.json" ``` -以下示例描述了如何将 secret 值映射为应用程序的环境变量。在这个示例中，消息队列的主题名从 secret `provider-queue-credentials` 中名为 `topic` 的 key 项映射到环境变量 `TOPIC` 中。 - +<!-- +The following example describes how to map secret values into application environment variables. In this example, the messaging queue topic name is mapped from a secret named `provider-queue-credentials` with a key named `topic` to the environment variable `TOPIC`. +--> +以下示例描述了如何将 Secret 值映射为应用程序的环境变量。 +在这个示例中，消息队列的主题名从 Secret `provider-queue-credentials` 中名为 +`topic` 的主键映射到环境变量 `TOPIC` 中。 ```yaml ... @@ -437,9 +430,6 @@ The following example describes how to map secret values into application enviro key: topic ``` - - - ## {{% heading "whatsnext" %}} <!-- @@ -448,11 +438,12 @@ The following example describes how to map secret values into application enviro * Explore the [kubernetes-incubator/service-catalog](https://github.com/kubernetes-incubator/service-catalog) project. * View [svc-cat.io](https://svc-cat.io/docs/). --> -* 如果您熟悉{{< glossary_tooltip text="Helm Charts" term_id="helm-chart" >}}，您可以[使用 Helm 将服务目录](/docs/tasks/service-catalog/install-service-catalog-using-helm/)安装到 Kubernetes 集群中。或者，您可以[使用 SC 工具安装服务目录](/docs/tasks/service-catalog/install-service-catalog-using-sc/)。 -* 查看[服务代理示例](https://github.com/openservicebrokerapi/servicebroker/blob/master/gettingStarted.md#sample-service-brokers)。 -* 浏览 [kubernetes-incubator/service-catalog](https://github.com/kubernetes-incubator/service-catalog) 项目。 -* 查看 [svc-cat.io](https://svc-cat.io/docs/)。 - - +* 如果你熟悉 {{< glossary_tooltip text="Helm Charts" term_id="helm-chart" >}}， + 可以[使用 Helm 安装服务目录](/zh/docs/tasks/service-catalog/install-service-catalog-using-helm/) + 到 Kubernetes 集群中。或者，你可以 + [使用 SC 工具安装服务目录](/zh/docs/tasks/service-catalog/install-service-catalog-using-sc/)。 +* 查看[服务代理示例](https://github.com/openservicebrokerapi/servicebroker/blob/master/gettingStarted.md#sample-service-brokers) +* 浏览 [kubernetes-incubator/service-catalog](https://github.com/kubernetes-incubator/service-catalog) 项目 +* 查看 [svc-cat.io](https://svc-cat.io/docs/) diff --git a/content/zh/docs/concepts/overview/components.md b/content/zh/docs/concepts/overview/components.md index f05be27399..a8cc964c64 100644 --- a/content/zh/docs/concepts/overview/components.md +++ b/content/zh/docs/concepts/overview/components.md @@ -1,27 +1,30 @@ --- title: Kubernetes 组件 content_type: concept +description: > + Kubernetes 集群由代表控制平面的组件和一组称为节点的机器组成。 weight: 20 -card: +card: name: concepts weight: 20 --- <!-- ---- reviewers: - lavalamp title: Kubernetes Components content_type: concept +description: > + A Kubernetes cluster consists of the components that represent the control plane + and a set of machines called nodes weight: 20 -card: +card: name: concepts weight: 20 ---- --> <!-- When you deploy Kubernetes, you get a cluster. -{{< glossary_definition term_id="cluster" length="all" prepend="A Kubernetes cluster consists of">}} +{< glossary_definition term_id="cluster" length="all" prepend="A Kubernetes cluster consists of">}} This document outlines the various components you need to have a complete and working Kubernetes cluster. @@ -38,28 +41,29 @@ Here's the diagram of a Kubernetes cluster with all the components tied together 这张图表展示了包含所有相互关联组件的 Kubernetes 集群。 -![Components of Kubernetes](/images/docs/components-of-kubernetes.png) - - +![Kubernetes 组件](/images/docs/components-of-kubernetes.png) <!-- body --> -<!-- -## Control Plane Components ---> -## 控制平面组件（Control Plane Components） -<!-- +<!-- +## Control Plane Components + The Control Plane's components make global decisions about the cluster (for example, scheduling), as well as detecting and responding to cluster events (for example, starting up a new {{< glossary_tooltip text="pod" term_id="pod">}} when a deployment's `replicas` field is unsatisfied). --> +## 控制平面组件（Control Plane Components） + 控制平面的组件对集群做出全局决策(比如调度)，以及检测和响应集群事件（例如，当不满足部署的 `replicas` 字段时，启动新的 {{< glossary_tooltip text="pod" term_id="pod">}}）。 -<!-- +<!-- Control Plane components can be run on any machine in the cluster. However, for simplicity, set up scripts typically start all Control Plane components on the same machine, and do not run user containers on this machine. See [Building High-Availability Clusters](/docs/admin/high-availability/) for an example multi-master-VM setup. --> -控制平面组件可以在集群中的任何节点上运行。然而，为了简单起见，设置脚本通常会在同一个计算机上启动所有控制平面组件，并且不会在此计算机上运行用户容器。请参阅[构建高可用性集群](/docs/admin/high-availability/)中对于多主机 VM 的设置示例。 +控制平面组件可以在集群中的任何节点上运行。 +然而，为了简单起见，设置脚本通常会在同一个计算机上启动所有控制平面组件，并且不会在此计算机上运行用户容器。 +请参阅[构建高可用性集群](/zh/docs/setup/production-environment/tools/kubeadm/high-availability/) +中对于多主机 VM 的设置示例。 ### kube-apiserver @@ -95,47 +99,46 @@ These controllers include: <!-- ### cloud-controller-manager + +{{< glossary_definition term_id="cloud-controller-manager" length="short" >}} + +The cloud-controller-manager only runs controllers that are specific to your cloud provider. +If you are running Kubernetes on your own premises, or in a learning environment inside your +own PC, the cluster does not have a cloud controller manager. + +As with the kube-controller-manager, the cloud-controller-manager combines several logically +independent control loops into a single binary that you run as a single process. You can +scale horizontally (run more than one copy) to improve performance or to help tolerate failures. + +The following controllers can have cloud provider dependencies: + + * Node controller: For checking the cloud provider to determine if a node has been deleted in the cloud after it stops responding + * Route controller: For setting up routes in the underlying cloud infrastructure + * Service controller: For creating, updating and deleting cloud provider load balancers --> -### 云控制器管理器-(cloud-controller-manager) +### cloud-controller-manager -<!-- -[cloud-controller-manager](/docs/tasks/administer-cluster/running-cloud-controller/) runs controllers that interact with the underlying cloud providers. The cloud-controller-manager binary is an alpha feature introduced in Kubernetes release 1.6. ---> -[cloud-controller-manager](/docs/tasks/administer-cluster/running-cloud-controller/) 运行与基础云提供商交互的控制器。cloud-controller-manager 二进制文件是 Kubernetes 1.6 版本中引入的 alpha 功能。 +`cloud-controller-manager` 进运行特定于云平台的控制回路。 +如果你在自己的环境中运行 Kubernetes，或者在本地计算机中运行学习环境， +所部属的环境中不需要云控制器管理器。 -<!-- -cloud-controller-manager runs cloud-provider-specific controller loops only. You must disable these controller loops in the kube-controller-manager. You can disable the controller loops by setting the `--cloud-provider` flag to `external` when starting the kube-controller-manager. ---> -cloud-controller-manager 仅运行云提供商特定的控制器循环。您必须在 kube-controller-manager 中禁用这些控制器循环，您可以通过在启动 kube-controller-manager 时将 `--cloud-provider` 参数设置为 `external` 来禁用控制器循环。 +与 `kube-controller-manager` 类似，`cloud-controller-manager` 将若干逻辑上独立的 +控制回路组合到同一个可执行文件中，供你以同一进程的方式运行。 +你可以对其执行水平扩容（运行不止一个副本）以提升性能或者增强容错能力。 -<!-- -cloud-controller-manager allows the cloud vendor's code and the Kubernetes code to evolve independently of each other. In prior releases, the core Kubernetes code was dependent upon cloud-provider-specific code for functionality. In future releases, code specific to cloud vendors should be maintained by the cloud vendor themselves, and linked to cloud-controller-manager while running Kubernetes. ---> -cloud-controller-manager 允许云供应商的代码和 Kubernetes 代码彼此独立地发展。在以前的版本中，核心的 Kubernetes 代码依赖于特定云提供商的代码来实现功能。在将来的版本中，云供应商专有的代码应由云供应商自己维护，并与运行 Kubernetes 的云控制器管理器相关联。 +下面的控制器都包含对云平台驱动的依赖： -<!-- -The following controllers have cloud provider dependencies: - - * Node Controller: For checking the cloud provider to determine if a node has been deleted in the cloud after it stops responding - * Route Controller: For setting up routes in the underlying cloud infrastructure - * Service Controller: For creating, updating and deleting cloud provider load balancers - * Volume Controller: For creating, attaching, and mounting volumes, and interacting with the cloud provider to orchestrate volumes ---> -以下控制器具有云提供商依赖性: - - * 节点控制器（Node Controller）: 用于检查云提供商以确定节点是否在云中停止响应后被删除 + * 节点控制器（Node Controller）: 用于在节点终止响应后检查云提供商以确定节点是否已被删除 * 路由控制器（Route Controller）: 用于在底层云基础架构中设置路由 * 服务控制器（Service Controller）: 用于创建、更新和删除云提供商负载均衡器 - * 数据卷控制器（Volume Controller）: 用于创建、附加和装载卷、并与云提供商进行交互以编排卷 <!-- ## Node Components ---> -## Node 组件 -<!-- Node components run on every node, maintaining running pods and providing the Kubernetes runtime environment. --> +## Node 组件 {#node-components} + 节点组件在每个节点上运行，维护运行的 Pod 并提供 Kubernetes 运行环境。 ### kubelet @@ -149,88 +152,93 @@ Node components run on every node, maintaining running pods and providing the Ku <!-- ### Container Runtime --> -### 容器运行环境(Container Runtime) +### 容器运行时（Container Runtime） {#container-runtime} {{< glossary_definition term_id="container-runtime" length="all" >}} <!-- ## Addons ---> -## 插件(Addons) -<!-- Addons use Kubernetes resources ({{< glossary_tooltip term_id="daemonset" >}}, {{< glossary_tooltip term_id="deployment" >}}, etc) to implement cluster features. Because these are providing cluster-level features, namespaced resources for addons belong within the `kube-system` namespace. --> -插件使用 Kubernetes 资源 ({{< glossary_tooltip term_id="daemonset" >}}, -{{< glossary_tooltip term_id="deployment" >}}等) 实现集群功能。因为这些提供集群级别的功能，所以插件的命名空间资源属于 `kube-system` 命名空间。 +## 插件（Addons） {#addons} + +插件使用 Kubernetes 资源（{{< glossary_tooltip text="DaemonSet" term_id="daemonset" >}}、 +{{< glossary_tooltip text="Deployment" term_id="deployment" >}}等）实现集群功能。 +因为这些插件提供集群级别的功能，插件中命名空间域的资源属于 `kube-system` 命名空间。 <!-- Selected addons are described below; for an extended list of available addons, please see [Addons](/docs/concepts/cluster-administration/addons/). --> -所选的插件如下所述：有关可用插件的扩展列表，请参见[插件 (Addons)](/docs/concepts/cluster-administration/addons/)。 - -### DNS +下面描述众多插件中的几种。有关可用插件的完整列表，请参见 +[插件（Addons）](/zh/docs/concepts/cluster-administration/addons/)。 <!-- +### DNS + While the other addons are not strictly required, all Kubernetes clusters should have [cluster DNS](/docs/concepts/services-networking/dns-pod-service/), as many examples rely on it. Cluster DNS is a DNS server, in addition to the other DNS server(s) in your environment, which serves DNS records for Kubernetes services. Containers started by Kubernetes automatically include this DNS server in their DNS searches. --> -尽管并非严格要求其他附加组件，但所有示例都依赖[集群 DNS](/docs/concepts/services-networking/dns-pod-service/)，因此所有 Kubernetes 集群都应具有 DNS。 +### DNS {#dns} -除了您环境中的其他 DNS 服务器之外，集群 DNS 还是一个 DNS 服务器，它为 Kubernetes 服务提供 DNS 记录。 +尽管其他插件都并非严格意义上的必需组件，但几乎所有 Kubernetes 集群都应该 +有[集群 DNS](/zh/docs/concepts/services-networking/dns-pod-service/)， +因为很多示例都需要 DNS 服务。 -Cluster DNS 是一个 DNS 服务器，和您部署环境中的其他 DNS 服务器一起工作，为 Kubernetes 服务提供DNS记录。 +集群 DNS 是一个 DNS 服务器，和环境中的其他 DNS 服务器一起工作，它为 Kubernetes 服务提供 DNS 记录。 -Kubernetes 启动的容器自动将 DNS 服务器包含在 DNS 搜索中。 +Kubernetes 启动的容器自动将此 DNS 服务器包含在其 DNS 搜索列表中。 <!-- ### Web UI (Dashboard) ---> -### 用户界面(Dashboard) -<!-- [Dashboard](/docs/tasks/access-application-cluster/web-ui-dashboard/) is a general purpose, web-based UI for Kubernetes clusters. It allows users to manage and troubleshoot applications running in the cluster, as well as the cluster itself. --> -[Dashboard](/docs/tasks/access-application-cluster/web-ui-dashboard/) 是 Kubernetes 集群的通用基于 Web 的 UI。它使用户可以管理集群中运行的应用程序以及集群本身并进行故障排除。 +### Web 界面（仪表盘） + +[Dashboard](/zh/docs/tasks/access-application-cluster/web-ui-dashboard/) 是K +ubernetes 集群的通用的、基于 Web 的用户界面。 +它使用户可以管理集群中运行的应用程序以及集群本身并进行故障排除。 <!-- ### Container Resource Monitoring ---> -### 容器资源监控 -<!-- [Container Resource Monitoring](/docs/tasks/debug-application-cluster/resource-usage-monitoring/) records generic time-series metrics about containers in a central database, and provides a UI for browsing that data. --> -[容器资源监控](/docs/tasks/debug-application-cluster/resource-usage-monitoring/)将关于容器的一些常见的时间序列度量值保存到一个集中的数据库中，并提供用于浏览这些数据的界面。 +### 容器资源监控 + +[容器资源监控](/zh/docs/tasks/debug-application-cluster/resource-usage-monitoring/) +将关于容器的一些常见的时间序列度量值保存到一个集中的数据库中，并提供用于浏览这些数据的界面。 <!-- ### Cluster-level Logging ---> -### 集群层面日志 -<!-- A [Cluster-level logging](/docs/concepts/cluster-administration/logging/) mechanism is responsible for saving container logs to a central log store with search/browsing interface. --> -[集群层面日志](/docs/concepts/cluster-administration/logging/) 机制负责将容器的日志数据保存到一个集中的日志存储中，该存储能够提供搜索和浏览接口。 +### 集群层面日志 +[集群层面日志](/zh/docs/concepts/cluster-administration/logging/) 机制负责将容器的日志数据 +保存到一个集中的日志存储中，该存储能够提供搜索和浏览接口。 ## {{% heading "whatsnext" %}} <!-- * Learn about [Nodes](/docs/concepts/architecture/nodes/) +* Learn about [Controllers](/docs/concepts/architecture/controller/) * Learn about [kube-scheduler](/docs/concepts/scheduling/kube-scheduler/) * Read etcd's official [documentation](https://etcd.io/docs/) --> -* 进一步了解 [Nodes](/docs/concepts/architecture/nodes/) -* 进一步了解 [kube-scheduler](/docs/concepts/scheduling/kube-scheduler/) +* 进一步了解[节点](/zh/docs/concepts/architecture/nodes/) +* 进一步了解[控制器](/zh/docs/concepts/architecture/controller/) +* 进一步了解 [kube-scheduler](/zh/docs/concepts/scheduling-eviction/kube-scheduler/) * 阅读 etcd 官方[文档](https://etcd.io/docs/) diff --git a/content/zh/docs/concepts/overview/kubernetes-api.md b/content/zh/docs/concepts/overview/kubernetes-api.md index 9a40a3b74b..99d65a572f 100644 --- a/content/zh/docs/concepts/overview/kubernetes-api.md +++ b/content/zh/docs/concepts/overview/kubernetes-api.md @@ -2,6 +2,8 @@ title: Kubernetes API content_type: concept weight: 30 +description: > + Kubernetes API 使你可以查询和操纵 Kubernetes 中对象的状态。Kubernetes 控制平面的核心是 API 服务器和它暴露的 HTTP API。 用户、集群的不同部分以及外部组件都通过 API 服务器相互通信。 card: name: concepts weight: 30 @@ -10,135 +12,186 @@ card: <!-- overview --> <!-- -Overall API conventions are described in the [API conventions doc](https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md). +The core of Kubernetes' {{< glossary_tooltip text="control plane" term_id="control-plane" >}} +is the {{< glossary_tooltip text="API server" term_id="kube-apiserver" >}}. The API server +exposes an HTTP API that lets end users, different parts of your cluster, and external components +communicate with one another. -API endpoints, resource types and samples are described in [API Reference](/docs/reference). +The Kubernetes API lets you query and manipulate the state of objects in the Kubernetes API +(for example: Pods, Namespaces, ConfigMaps, and Events). -Remote access to the API is discussed in the [Controlling API Access doc](/docs/reference/access-authn-authz/controlling-access/). - -The Kubernetes API also serves as the foundation for the declarative configuration schema for the system. The [kubectl](/docs/reference/kubectl/overview/) command-line tool can be used to create, update, delete, and get API objects. - -Kubernetes also stores its serialized state (currently in [etcd](https://coreos.com/docs/distributed-configuration/getting-started-with-etcd/)) in terms of the API resources. - -Kubernetes itself is decomposed into multiple components, which interact through its API. +API endpoints, resource types and samples are described in the [API Reference](/docs/reference/kubernetes-api/). --> -[API协议文档](https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md)描述了主系统和API概念。 - -[API参考文档](/docs/reference)描述了API整体规范。 - -[访问文档](/docs/admin/accessing-the-api)讨论了通过远程访问API的相关问题。 - -Kubernetes API是系统描述性配置的基础。 [Kubectl](/docs/user-guide/kubectl/) 命令行工具被用于创建、更新、删除、获取API对象。 - -Kubernetes 通过API资源存储自己序列化状态(现在存储在[etcd](https://coreos.com/docs/distributed-configuration/getting-started-with-etcd/))。 - -Kubernetes 被分成多个组件，各部分通过API相互交互。 - +Kubernetes {{< glossary_tooltip text="控制面" term_id="control-plane" >}} +的核心是 {{< glossary_tooltip text="API 服务器" term_id="kube-apiserver" >}}。 +API 服务器负责提供 HTTP API，以供用户、集群中的不同部分和集群外部组件相互通信。 +Kubernetes API 使你可以查询和操纵 Kubernetes API +中对象（例如：Pod、Namespace、ConfigMap 和 Event）的状态。 +API 末端、资源类型以及示例都在[API 参考](/zh/docs/reference/kubernetes-api/)中描述。 <!-- body --> <!-- ## API changes -In our experience, any system that is successful needs to grow and change as new use cases emerge or existing ones change. Therefore, we expect the Kubernetes API to continuously change and grow. However, we intend to not break compatibility with existing clients, for an extended period of time. In general, new API resources and new resource fields can be expected to be added frequently. Elimination of resources or fields will require following the [API deprecation policy](/docs/reference/using-api/deprecation-policy/). +Any system that is successful needs to grow and change as new use cases emerge or existing ones change. +Therefore, Kubernetes has design features to allow the Kubernetes API to continuously change and grow. +The Kubernetes project aims to _not_ break compatibility with existing clients, and to maintain that +compatibility for a length of time so that other projects have an opportunity to adapt. -What constitutes a compatible change and how to change the API are detailed by the [API change document](https://git.k8s.io/community/contributors/devel/sig-architecture/api_changes.md). +In general, new API resources and new resource fields can be added often and frequently. +Elimination of resources or fields requires following the +[API deprecation policy](/docs/reference/using-api/deprecation-policy/). + +What constitutes a compatible change, and how to change the API, are detailed in +[API changes](https://git.k8s.io/community/contributors/devel/sig-architecture/api_changes.md#readme). --> -## API 变更 +## API 变更 {#api-changes} -根据经验，任何成功的系统都需要随着新的用例出现或现有用例发生变化的情况下，进行相应的进化与调整。因此，我们希望Kubernetes API也可以保持持续的进化和调整。同时，在较长一段时间内，我们也希望与现有客户端版本保持良好的向下兼容性。一般情况下，增加新的API资源和资源字段不会导致向下兼容性问题发生；但如果是需要删除一个已有的资源或者字段，那么必须通过[API废弃流程](/docs/reference/deprecation-policy/)来进行。 +任何成功的系统都要随着新的使用案例的出现和现有案例的变化来成长和变化。 +为此，Kubernetes 的功能特性设计考虑了让 Kubernetes API 能够持续变更和成长的因素。 +Kubernetes 项目的目标是 _不要_ 引发现有客户端的兼容性问题，并在一定的时期内 +维持这种兼容性，以便其他项目有机会作出适应性变更。 -参考[API变更文档](https://git.k8s.io/community/contributors/devel/sig-architecture/api_changes.md)，了解兼容性变更的要素以及如何变更API的流程。 +一般而言，新的 API 资源和新的资源字段可以被频繁地添加进来。 +删除资源或者字段则要遵从 +[API 废弃策略](/zh/docs/reference/using-api/deprecation-policy/)。 + +关于什么是兼容性的变更，如何变更 API 等详细信息，可参考 +[API 变更](https://git.k8s.io/community/contributors/devel/sig-architecture/api_changes.md#readme)。 <!-- -## OpenAPI and Swagger definitions +## OpenAPI specification {#api-specification} Complete API details are documented using [OpenAPI](https://www.openapis.org/). -Starting with Kubernetes 1.10, the Kubernetes API server serves an OpenAPI spec via the `/openapi/v2` endpoint. -The requested format is specified by setting HTTP headers: +The Kubernetes API server serves an OpenAPI spec via the `/openapi/v2` endpoint. +You can request the response format using request headers as follows: --> -## OpenAPI 和 API Swagger 定义 +## OpenAPI 规范 {#api-specification} -完整的 API 详细文档使用 [OpenAPI](https://www.openapis.org/)生成. +完整的 API 细节是用 [OpenAPI](https://www.openapis.org/) 来表述的。 -随着 Kubernetes 1.10 版本的正式启用，Kubernetes API 服务通过 `/openapi/v2` 接口提供 OpenAPI 规范。 -通过设置 HTTP 标头的规定了请求的结构。 - -Header | Possible Values ------- | --------------- -Accept | `application/json`, `application/com.github.proto-openapi.spec.v2@v1.0+protobuf` (the default content-type is `application/json` for `*/*` or not passing this header) -Accept-Encoding | `gzip` (not passing this header is acceptable) +Kubernetes API 服务器通过 `/openapi/v2` 末端提供 OpenAPI 规范。 +你可以按照下表所给的请求头部，指定响应的格式： <!-- -Prior to 1.14, format-separated endpoints (`/swagger.json`, `/swagger-2.0.0.json`, `/swagger-2.0.0.pb-v1`, `/swagger-2.0.0.pb-v1.gz`) -serve the OpenAPI spec in different formats. These endpoints are deprecated, and are removed in Kubernetes 1.14. - -**Examples of getting OpenAPI spec**: - -Before 1.10 | Starting with Kubernetes 1.10 +<table> + <thead> + <tr> + <th>Header</th> + <th style="min-width: 50%;">Possible values</th> + <th>Notes</th> + </tr> + </thead> + <tbody> + <tr> + <td><code>Accept-Encoding</code></td> + <td><code>gzip</code></td> + <td><em>not supplying this header is also acceptable</em></td> + </tr> + <tr> + <td rowspan="3"><code>Accept</code></td> + <td><code>application/com.github.proto-openapi.spec.v2@v1.0+protobuf</code></td> + <td><em>mainly for intra-cluster use</em></td> + </tr> + <tr> + <td><code>application/json</code></td> + <td><em>default</em></td> + </tr> + <tr> + <td><code>*</code></td> + <td><em>serves </em><code>application/json</code></td> + </tr> + </tbody> + <caption>Valid request header values for OpenAPI v2 queries</caption> +</table> --> - -在1.14版本之前，区分结构的接口通过(`/swagger.json`, `/swagger-2.0.0.json`, `/swagger-2.0.0.pb-v1`, `/swagger-2.0.0.pb-v1.gz`) -提供不同格式的 OpenAPI 规范。但是这些接口已经被废弃，并且已经在 Kubernetes 1.14 中被删除。 - -**获取 OpenAPI 规范的例子**: - -1.10 之前 | 从 1.10 开始 ------------ | ----------------------------- -GET /swagger.json | GET /openapi/v2 **Accept**: application/json -GET /swagger-2.0.0.pb-v1 | GET /openapi/v2 **Accept**: application/com.github.proto-openapi.spec.v2@v1.0+protobuf -GET /swagger-2.0.0.pb-v1.gz | GET /openapi/v2 **Accept**: application/com.github.proto-openapi.spec.v2@v1.0+protobuf **Accept-Encoding**: gzip +<table> + <thead> + <tr> + <th>头部</th> + <th style="min-width: 50%;">可选值</th> + <th>说明</th> + </tr> + </thead> + <tbody> + <tr> + <td><code>Accept-Encoding</code></td> + <td><code>gzip</code></td> + <td><em>不指定此头部也是可以的</em></td> + </tr> + <tr> + <td rowspan="3"><code>Accept</code></td> + <td><code>application/com.github.proto-openapi.spec.v2@v1.0+protobuf</code></td> + <td><em>主要用于集群内部</em></td> + </tr> + <tr> + <td><code>application/json</code></td> + <td><em>默认值</em></td> + </tr> + <tr> + <td><code>*</code></td> + <td><em>提供</em><code>application/json</code></td> + </tr> + </tbody> + <caption>OpenAPI v2 查询请求的合法头部值</caption> +</table> <!-- Kubernetes implements an alternative Protobuf based serialization format for the API that is primarily intended for intra-cluster communication, documented in the [design proposal](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/api-machinery/protobuf.md) and the IDL files for each schema are located in the Go packages that define the API objects. - -Prior to 1.14, the Kubernetes apiserver also exposes an API that can be used to retrieve -the [Swagger v1.2](http://swagger.io/) Kubernetes API spec at `/swaggerapi`. -This endpoint is deprecated, and will be removed in Kubernetes 1.14. --> - -Kubernetes实现了另一种基于Protobuf的序列化格式，该格式主要用于集群内通信，并在[设计方案](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/api-machinery/protobuf.md)中进行了说明，每个模式的IDL文件位于定义API对象的Go软件包中。 -在 1.14 版本之前， Kubernetes apiserver 也提供 API 服务用于返回 -[Swagger v1.2](http://swagger.io/) Kubernetes API 规范通过 `/swaggerapi` 接口. -但是这个接口已经被废弃，并且在 Kubernetes 1.14 中已经被移除。 +Kubernetes 为 API 实现了一种基于 Protobuf 的序列化格式，主要用于集群内部的通信。 +相关文档位于[设计提案](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/api-machinery/protobuf.md)。 +每种 Schema 对应的 IDL 位于定义 API 对象的 Go 包中。 <!-- ## API versioning To make it easier to eliminate fields or restructure resource representations, Kubernetes supports multiple API versions, each at a different API path, such as `/api/v1` or -`/apis/extensions/v1beta1`. +`/apis/rbac.authorization.k8s.io/v1alpha1`. --> +## API 版本 {#api-versioning} -## API 版本 - -为了使删除字段或者重构资源表示更加容易，Kubernetes 支持 -多个API版本。每一个版本都在不同API路径下，例如 `/api/v1` 或者 -`/apis/extensions/v1beta1`。 +为了简化删除字段或者重构资源表示等工作，Kubernetes 支持多个 API 版本， +每一个版本都在不同 API 路径下，例如 `/api/v1` 或 +`/apis/rbac.authorization.k8s.io/v1alpha1`。 <!-- -We chose to version at the API level rather than at the resource or field level to ensure that the API presents a clear, consistent view of system resources and behavior, and to enable controlling access to end-of-life and/or experimental APIs. The JSON and Protobuf serialization schemas follow the same guidelines for schema changes - all descriptions below cover both formats. +Versioning is done at the API level rather than at the resource or field level to ensure that the +API presents a clear, consistent view of system resources and behavior, and to enable controlling +access to end-of-life and/or experimental APIs. -Note that API versioning and Software versioning are only indirectly related. The [API and release -versioning proposal](https://git.k8s.io/community/contributors/design-proposals/release/versioning.md) describes the relationship between API versioning and -software versioning. +The JSON and Protobuf serialization schemas follow the same guidelines for schema changes - all descriptions below cover both formats. --> +版本化是在 API 级别而不是在资源或字段级别进行的，目的是为了确保 API +为系统资源和行为提供清晰、一致的视图，并能够控制对已废止的和/或实验性 API 的访问。 -我们选择在API级别进行版本化，而不是在资源或字段级别进行版本化，以确保API提供清晰，一致的系统资源和行为视图，并控制对已废止的API和/或实验性API的访问。 JSON和Protobuf序列化模式遵循架构更改的相同准则 - 下面的所有描述都同时适用于这两种格式。 - -请注意，API版本控制和软件版本控制只有间接相关性。 - [API和发行版本建议](https://git.k8s.io/community/contributors/design-proposals/release/versioning.md) 描述了API版本与软件版本之间的关系。 +JSON 和 Protobuf 序列化模式遵循 schema 更改的相同准则 - 下面的所有描述都同时适用于这两种格式。 <!-- +Note that API versioning and Software versioning are only indirectly related. The +[Kubernetes Release Versioning](https://git.k8s.io/community/contributors/design-proposals/release/versioning.md) +proposal describes the relationship between API versioning and software versioning. + Different API versions imply different levels of stability and support. The criteria for each level are described -in more detail in the [API Changes documentation](https://git.k8s.io/community/contributors/devel/sig-architecture/api_changes.md#alpha-beta-and-stable-versions). They are summarized here: +in more detail in the +[API Changes](https://git.k8s.io/community/contributors/devel/sig-architecture/api_changes.md#alpha-beta-and-stable-versions) +documentation. They are summarized here: --> +请注意，API 版本控制和软件版本控制只有间接相关性。 +[Kubernetes 发行版本提案](https://git.k8s.io/community/contributors/design-proposals/release/versioning.md) +中描述了 API 版本与软件版本之间的关系。 -不同的API版本名称意味着不同级别的软件稳定性和支持程度。 每个级别的标准在[API变更文档](https://git.k8s.io/community/contributors/devel/sig-architecture/api_changes.md#alpha-beta-and-stable-versions)中有更详细的描述。 内容主要概括如下： +不同的 API 版本名称意味着不同级别的软件稳定性和支持程度。 +每个级别的判定标准在 +[API 变更文档](https://git.k8s.io/community/contributors/devel/sig-architecture/api_changes.md#alpha-beta-and-stable-versions) +中有更详细的描述。 +这些标准主要概括如下： <!-- - Alpha level: @@ -147,6 +200,15 @@ in more detail in the [API Changes documentation](https://git.k8s.io/community/c - Support for feature may be dropped at any time without notice. - The API may change in incompatible ways in a later software release without notice. - Recommended for use only in short-lived testing clusters, due to increased risk of bugs and lack of long-term support. +--> +- Alpha 级别： + - 版本名称包含 `alpha`（例如：`v1alpha1`） + - API 可能是有缺陷的。启用该功能可能会带来问题，默认情况是禁用的 + - 对相关功能的支持可能在没有通知的情况下随时终止 + - API 可能在将来的软件发布中出现不兼容性的变更，此类变更不会另行通知 + - 由于缺陷风险较高且缺乏长期支持，推荐仅在短暂的集群测试中使用 + +<!-- - Beta level: - The version names contain `beta` (e.g. `v2beta3`). - Code is well tested. Enabling the feature is considered safe. Enabled by default. @@ -157,118 +219,127 @@ in more detail in the [API Changes documentation](https://git.k8s.io/community/c - Recommended for only non-business-critical uses because of potential for incompatible changes in subsequent releases. If you have multiple clusters which can be upgraded independently, you may be able to relax this restriction. - **Please do try our beta features and give feedback on them! Once they exit beta, it may not be practical for us to make more changes.** +--> +- Beta 级别： + - 版本名称包含 `beta`（例如：`v2beta3`） + - 代码已经充分测试过。启用该功能被认为是安全的，功能默认已启用。 + - 所支持的功能作为一个整体不会被删除，尽管细节可能会发生变更。 + - 对象的模式和/或语义可能会在后续的 beta 发行版或稳定版中以不兼容的方式进行更改。 + 发生这种情况时，我们将提供如何迁移到新版本的说明。 + 迁移操作可能需要删除、编辑和重新创建 API 对象。 + 执行编辑操作时可能需要动些脑筋。 + 迁移过程中可能需要停用依赖该功能的应用程序。 + - 建议仅用于非业务关键性用途，因为后续版本中可能存在不兼容的更改。 + 如果你有多个可以独立升级的集群，则可以放宽此限制。 + - **请尝试我们的 beta 版本功能并且给出反馈！一旦它们结束 beta 阶段，进一步变更可能就不太现实了。** +<!-- - Stable level: - The version name is `vX` where `X` is an integer. - Stable versions of features will appear in released software for many subsequent versions. --> -- Alpha 测试版本： - - 版本名称包含了 **`alpha`** (例如：**`v1alpha1`**)。 - - 可能是有缺陷的。启用该功能可能会带来隐含的问题，默认情况是关闭的。 - - 支持的功能可能在没有通知的情况下随时删除。 - - API的更改可能会带来兼容性问题，但是在后续的软件发布中不会有任何通知。 - - 由于bugs风险的增加和缺乏长期的支持，推荐在短暂的集群测试中使用。 -- Beta 测试版本： - - 版本名称包含了 **`beta`** (例如: **`v2beta3`**)。 - - 代码已经测试过。启用该功能被认为是安全的，功能默认已启用。 - - 所有已支持的功能不会被删除，细节可能会发生变化。 - - 对象的模式和/或语义可能会在后续的beta测试版或稳定版中以不兼容的方式进行更改。 发生这种情况时，我们将提供迁移到下一个版本的说明。 这可能需要删除、编辑和重新创建API对象。执行编辑操作时需要谨慎行事，这可能需要停用依赖该功能的应用程序。 - - 建议仅用于非业务关键型用途，因为后续版本中可能存在不兼容的更改。 如果您有多个可以独立升级的集群，则可以放宽此限制。 - - **请尝试我们的 beta 版本功能并且给出反馈！一旦他们退出 beta 测试版，我们可能不会做出更多的改变。** -- 稳定版本： - - 版本名称是 **`vX`**，其中 **`X`** 是整数。 +- 稳定级别： + - 版本名称是 `vX`，其中 `X` 是整数。 - 功能的稳定版本将出现在许多后续版本的发行软件中。 <!-- ## API groups -To make it easier to extend the Kubernetes API, we implemented [*API groups*](https://git.k8s.io/community/contributors/design-proposals/api-machinery/api-group.md). +To make it easier to extend the Kubernetes API, Kubernetes implemented [*API groups*](https://git.k8s.io/community/contributors/design-proposals/api-machinery/api-group.md). The API group is specified in a REST path and in the `apiVersion` field of a serialized object. --> +## API 组 {#api-groups} -## API 组 - -为了更容易地扩展Kubernetes API，我们实现了[*`API组`*](https://git.k8s.io/community/contributors/design-proposals/api-machinery/api-group.md)。 -API组在REST路径和序列化对象的 **`apiVersion`** 字段中指定。 +为了更容易地扩展 Kubernetes API，Kubernetes 实现了 +[*`API组`*](https://git.k8s.io/community/contributors/design-proposals/api-machinery/api-group.md)。 +API 组在 REST 路径和序列化对象的 `apiVersion` 字段中指定。 <!-- -Currently there are several API groups in use: +There are several API groups in a cluster: -1. The *core* group, often referred to as the *legacy group*, is at the REST path `/api/v1` and uses `apiVersion: v1`. +1. The *core* group, also referred to as the *legacy* group, is at the REST path `/api/v1` and uses `apiVersion: v1`. -1. The named groups are at REST path `/apis/$GROUP_NAME/$VERSION`, and use `apiVersion: $GROUP_NAME/$VERSION` - (e.g. `apiVersion: batch/v1`). Full list of supported API groups can be seen in [Kubernetes API reference](/docs/reference/). +1. *Named* groups are at REST path `/apis/$GROUP_NAME/$VERSION`, and use `apiVersion: $GROUP_NAME/$VERSION` + (e.g. `apiVersion: batch/v1`). The Kubernetes [API reference](/docs/reference/kubernetes-api/) has a + full list of available API groups. --> +集群中存在若干 API 组： -目前有几个API组正在使用中： +1. *核心（Core）*组，通常被称为 *遗留（Legacy）* 组，位于 REST 路径 `/api/v1`， + 使用 `apiVersion: v1`。 -1. 核心组（通常被称为遗留组）位于REST路径 `/api/v1` 并使用 `apiVersion：v1`。 - -1. 指定的组位于REST路径 `/apis/$GROUP_NAME/$VERSION`，并使用 `apiVersion：$GROUP_NAME/$VERSION` - （例如 `apiVersion：batch/v1`）。 在[Kubernetes API参考](/docs/reference/)中可以看到支持的API组的完整列表。 +1. *命名（Named）* 组 REST 路径 `/apis/$GROUP_NAME/$VERSION`，使用 + `apiVersion: $GROUP_NAME/$VERSION`（例如 `apiVersion: batch/v1`）。 + [Kubernetes API 参考](/zh/docs/reference/kubernetes-api/)中枚举了可用的 API 组的完整列表。 <!-- -There are two supported paths to extending the API with [custom resources](/docs/concepts/api-extension/custom-resources/): +There are two paths to extending the API with [custom resources](/docs/concepts/extend-kubernetes/api-extension/custom-resources/): -1. [CustomResourceDefinition](/docs/tasks/access-kubernetes-api/extend-api-custom-resource-definitions/) - is for users with very basic CRUD needs. -1. Users needing the full set of Kubernetes API semantics can implement their own apiserver - and use the [aggregator](/docs/tasks/access-kubernetes-api/configure-aggregation-layer/) +1. [CustomResourceDefinition](/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/) + lets you declaratively define how the API server should provide your chosen resource API. +1. You can also [implement your own extension API server](/docs/tasks/extend-kubernetes/setup-extension-api-server/) + and use the [aggregator](/docs/tasks/extend-kubernetes/configure-aggregation-layer/) to make it seamless for clients. --> +有两种途径来扩展 Kubernetes API 以支持 +[自定义资源](/zh/docs/concepts/extend-kubernetes/api-extension/custom-resources/)： -社区支持使用以下两种方式来提供自定义资源对API进行扩展[自定义资源](/docs/concepts/api-extension/custom-resources/)： +1. 使用 [CustomResourceDefinition](/zh/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/)， + 你可以用声明式方式来定义 API 如何提供你所选择的资源 API。 -1. [CustomResourceDefinition](/docs/tasks/access-kubernetes-api/extend-api-custom-resource-definitions/) - 适用于具有非常基本的CRUD需求的用户。 - -1. 需要全套Kubernetes API语义的用户可以实现自己的apiserver， - 并使用[聚合器](/docs/tasks/access-kubernetes-api/configure-aggregation-layer/) +1. 你也可以选择[实现自己的扩展 API 服务器](/zh/docs/tasks/extend-kubernetes/setup-extension-api-server/) + 并使用[聚合器](/zh/docs/tasks/extend-kubernetes/configure-aggregation-layer/) 为客户提供无缝的服务。 <!-- ## Enabling or disabling API groups -Certain resources and API groups are enabled by default. They can be enabled or disabled by setting `--runtime-config` -on apiserver. `--runtime-config` accepts comma separated values. For example: to disable batch/v1, set -`--runtime-config=batch/v1=false`, to enable batch/v2alpha1, set `--runtime-config=batch/v2alpha1`. +Certain resources and API groups are enabled by default. They can be enabled or disabled by setting `-runtime-config` +on apiserver. `-runtime-config` accepts comma separated values. For example: to disable batch/v1, set +`-runtime-config=batch/v1=false`, to enable batch/v2alpha1, set `-runtime-config=batch/v2alpha1`. The flag accepts comma separated set of key=value pairs describing runtime configuration of the apiserver. Enabling or disabling groups or resources requires restarting apiserver and controller-manager -to pick up the `--runtime-config` changes. +to pick up the `-runtime-config` changes. --> +## 启用或禁用 API 组 {#enabling-or-disabling-api-groups} -## 启用 API 组 - -某些资源和API组默认情况下处于启用状态。 可以通过在apiserver上设置 `--runtime-config` 来启用或禁用它们。 +某些资源和 API 组默认情况下处于启用状态。可以通过为 `kube-apiserver` +设置 `--runtime-config` 命令行选项来启用或禁用它们。 `--runtime-config` 接受逗号分隔的值。 -例如：要禁用batch/v1，请设置 `--runtime-config=batch/v1=false`，以启用batch/v2alpha1，请设置`--runtime-config=batch/v2alpha1`。 -该标志接受描述apiserver的运行时配置的逗号分隔的一组键值对。 +例如：要禁用 `batch/v1`，设置 `--runtime-config=batch/v1=false`； +要启用 `batch/v2alpha1`，设置`--runtime-config=batch/v2alpha1`。 +该标志接受逗号分隔的一组"key=value"键值对，用以描述 API 服务器的运行时配置。 {{< note >}} - -启用或禁用组或资源需要重新启动apiserver和控制器管理器来使得 `--runtime-config` 更改生效。 - +启用或禁用组或资源需要重新启动 `kube-apiserver` 和 `kube-controller-manager` +来使得 `--runtime-config` 更改生效。 {{< /note >}} <!-- -## Enabling specific resources in the extensions/v1beta1 group +## Persistence -DaemonSets, Deployments, StatefulSet, NetworkPolicies, PodSecurityPolicies and ReplicaSets in the `extensions/v1beta1` API group are disabled by default. -For example: to enable deployments and daemonsets, set -`--runtime-config=extensions/v1beta1/deployments=true,extensions/v1beta1/daemonsets=true`. - -Individual resource enablement/disablement is only supported in the `extensions/v1beta1` API group for legacy reasons. +Kubernetes stores its serialized state in terms of the API resources by writing them into +{{< glossary_tooltip term_id="etcd" >}}. --> +## 持久性 {#persistence} -## 启用 extensions/v1beta1 组中资源 +Kubernetes 也将其 API 资源的序列化状态保存起来，写入到 {{< glossary_tooltip term_id="etcd" >}}。 -在 `extensions/v1beta1` API 组中，DaemonSets，Deployments，StatefulSet, NetworkPolicies, PodSecurityPolicies 和 ReplicaSets 是默认禁用的。 -例如：要启用 deployments 和 daemonsets，请设置 `--runtime-config=extensions/v1beta1/deployments=true,extensions/v1beta1/daemonsets=true`。 +## {{% heading "whatsnext" %}} -{{< note >}} +<!-- +[Controlling API Access](/docs/reference/access-authn-authz/controlling-access/) describes +how the cluster manages authentication and authorization for API access. -出于遗留原因，仅在 `extensions / v1beta1` API 组中支持各个资源的启用/禁用。 +Overall API conventions are described in the +[API conventions](https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#api-conventions) +document. -{{< /note >}} +API endpoints, resource types and samples are described in the [API Reference](/docs/reference/kubernetes-api/). +--> +* [控制 API 访问](/zh/docs/reference/access-authn-authz/controlling-access/) + 描述了集群如何为 API 访问管理身份认证和权限判定； +* 总体的 API 约定描述位于 [API 约定](https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md)中； +* API 末端、资源类型和示例等均在 [API 参考文档](/zh/docs/reference/kubernetes-api/)中描述 diff --git a/content/zh/docs/concepts/overview/what-is-kubernetes.md b/content/zh/docs/concepts/overview/what-is-kubernetes.md index d4c9bfc47b..4aab8132f1 100644 --- a/content/zh/docs/concepts/overview/what-is-kubernetes.md +++ b/content/zh/docs/concepts/overview/what-is-kubernetes.md @@ -1,6 +1,8 @@ --- title: Kubernetes 是什么？ content_type: concept +description: > + Kubernetes 是一个可移植的，可扩展的开源平台，用于管理容器化的工作负载和服务，方便了声明式配置和自动化。它拥有一个庞大且快速增长的生态系统。Kubernetes 的服务，支持和工具广泛可用。 weight: 10 card: name: concepts @@ -74,7 +76,7 @@ Each VM is a full machine running all the components, including its own operatin 每个 VM 是一台完整的计算机，在虚拟化硬件之上运行所有组件，包括其自己的操作系统。 <!-- -**Container deployment era:** +**Container deployment era:** Containers are similar to VMs, but they have relaxed isolation properties to share the Operating System (OS) among the applications. Therefore, containers are considered lightweight. Similar to a VM, a container has its own filesystem, CPU, memory, process space, and more. As they are decoupled from the underlying infrastructure, they are portable across clouds and OS distributions. --> **容器部署时代：** @@ -214,4 +216,4 @@ Kubernetes： * Ready to [Get Started](/docs/setup/)? --> * 查阅 [Kubernetes 组件](/zh/docs/concepts/overview/components/) -* 开始 [Kubernetes 入门](/zh/docs/setup/)? \ No newline at end of file +* 开始 [Kubernetes 入门](/zh/docs/setup/)? diff --git a/content/zh/docs/concepts/overview/working-with-objects/_index.md b/content/zh/docs/concepts/overview/working-with-objects/_index.md index 5a57415cc2..a327b880d8 100644 --- a/content/zh/docs/concepts/overview/working-with-objects/_index.md +++ b/content/zh/docs/concepts/overview/working-with-objects/_index.md @@ -1,4 +1,6 @@ --- title: "使用 Kubernetes 对象" weight: 40 +description: > + Kubernetes 对象是 Kubernetes 系统中的持久性实体。Kubernetes 使用这些实体表示您的集群状态。了解 Kubernetes 对象模型以及如何使用这些对象。 --- diff --git a/content/zh/docs/concepts/overview/working-with-objects/annotations.md b/content/zh/docs/concepts/overview/working-with-objects/annotations.md index 8e8b0f3f5b..f342a92113 100644 --- a/content/zh/docs/concepts/overview/working-with-objects/annotations.md +++ b/content/zh/docs/concepts/overview/working-with-objects/annotations.md @@ -5,46 +5,39 @@ weight: 50 --- <!-- ---- title: Annotations content_type: concept weight: 50 ---- --> <!-- overview --> -你可以使用 Kubernetes 注解为对象附加任意的非标识的元数据。客户端程序（例如工具和库）能够获取这些元数据信息。 <!-- You can use Kubernetes annotations to attach arbitrary non-identifying metadata to objects. Clients such as tools and libraries can retrieve this metadata. --> - +你可以使用 Kubernetes 注解为对象附加任意的非标识的元数据。客户端程序（例如工具和库）能够获取这些元数据信息。 <!-- body --> -## 为对象附加元数据 <!-- ## Attaching metadata to objects ---> -您可以使用标签或注解将元数据附加到 Kubernetes 对象。 -标签可以用来选择对象和查找满足某些条件的对象集合。 相反，注解不用于标识和选择对象。 -注解中的元数据，可以很小，也可以很大，可以是结构化的，也可以是非结构化的，能够包含标签不允许的字符。 - -<!-- You can use either labels or annotations to attach metadata to Kubernetes objects. Labels can be used to select objects and to find collections of objects that satisfy certain conditions. In contrast, annotations are not used to identify and select objects. The metadata in an annotation can be small or large, structured or unstructured, and can include characters not permitted by labels. ---> - -注解和标签一样，是键/值对: -<!-- Annotations, like labels, are key/value maps: --> +## 为对象附加元数据 + +你可以使用标签或注解将元数据附加到 Kubernetes 对象。 +标签可以用来选择对象和查找满足某些条件的对象集合。 相反，注解不用于标识和选择对象。 +注解中的元数据，可以很小，也可以很大，可以是结构化的，也可以是非结构化的，能够包含标签不允许的字符。 + +注解和标签一样，是键/值对: ```json "metadata": { @@ -55,75 +48,63 @@ Annotations, like labels, are key/value maps: } ``` -以下是一些例子，用来说明哪些信息可以使用注解来记录: <!-- Here are some examples of information that could be recorded in annotations: --> - -* 由声明性配置所管理的字段。 - 将这些字段附加为注解，能够将它们与客户端或服务端设置的默认值、自动生成的字段以及通过自动调整大小或自动伸缩系统设置的字段区分开来。 +以下是一些例子，用来说明哪些信息可以使用注解来记录: <!-- * Fields managed by a declarative configuration layer. Attaching these fields as annotations distinguishes them from default values set by clients or servers, and from auto-generated fields and fields set by auto-sizing or auto-scaling systems. ---> -* 构建、发布或镜像信息（如时间戳、发布 ID、Git 分支、PR 数量、镜像哈希、仓库地址）。 - -<!-- * Build, release, or image information like timestamps, release IDs, git branch, PR numbers, image hashes, and registry address. ---> -* 指向日志记录、监控、分析或审计仓库的指针。 - -<!-- * Pointers to logging, monitoring, analytics, or audit repositories. --> -* 可用于调试目的的客户端库或工具信息：例如，名称、版本和构建信息。 +* 由声明性配置所管理的字段。 + 将这些字段附加为注解，能够将它们与客户端或服务端设置的默认值、 + 自动生成的字段以及通过自动调整大小或自动伸缩系统设置的字段区分开来。 +* 构建、发布或镜像信息（如时间戳、发布 ID、Git 分支、PR 数量、镜像哈希、仓库地址）。 +* 指向日志记录、监控、分析或审计仓库的指针。 + <!-- * Client library or tool information that can be used for debugging purposes: for example, name, version, and build information. ---> -* 用户或者工具/系统的来源信息，例如来自其他生态系统组件的相关对象的 URL。 - -<!-- * User or tool/system provenance information, such as URLs of related objects from other ecosystem components. ---> -* 推出的轻量级工具的元数据信息：例如，配置或检查点。 - -<!-- * Lightweight rollout tool metadata: for example, config or checkpoints. ---> -* 负责人员的电话或呼机号码，或指定在何处可以找到该信息的目录条目，如团队网站。 - -<!-- * Phone or pager numbers of persons responsible, or directory entries that specify where that information can be found, such as a team web site. ---> - -从用户到最终运行的指令，以修改行为或使用非标准功能。 -<!-- * Directives from the end-user to the implementations to modify behavior or engage non-standard features. --> +* 可用于调试目的的客户端库或工具信息：例如，名称、版本和构建信息。 + +* 用户或者工具/系统的来源信息，例如来自其他生态系统组件的相关对象的 URL。 + +* 轻量级上线工具的元数据信息：例如，配置或检查点。 + +* 负责人员的电话或呼机号码，或指定在何处可以找到该信息的目录条目，如团队网站。 + +* 从用户到最终运行的指令，以修改行为或使用非标准功能。 -您可以将这类信息存储在外部数据库或目录中而不使用注解，但这样做就使得开发人员很难生成用于部署、管理、自检的客户端共享库和工具。 <!-- Instead of using annotations, you could store this type of information in an external database or directory, but that would make it much harder to produce shared client libraries and tools for deployment, management, introspection, and the like. --> +你可以将这类信息存储在外部数据库或目录中而不使用注解， +但这样做就使得开发人员很难生成用于部署、管理、自检的客户端共享库和工具。 <!-- ## Syntax and character set @@ -132,22 +113,28 @@ _Annotations_ are key/value pairs. Valid annotation keys have two segments: an o If the prefix is omitted, the annotation Key is presumed to be private to the user. Automated system components (e.g. `kube-scheduler`, `kube-controller-manager`, `kube-apiserver`, `kubectl`, or other third-party automation) which add annotations to end-user objects must specify a prefix. --> - ## 语法和字符集 -_注解_ 存储的形式是键/值对。有效的注解键分为两部分：可选的前缀和名称，以斜杠（`/`）分隔。 名称段是必需项，并且必须在63个字符以内，以字母数字字符（`[a-z0-9A-Z]`）开头和结尾，并允许使用破折号（`-`），下划线（`_`），点（`.`）和字母数字。 前缀是可选的。 如果指定，则前缀必须是DNS子域：一系列由点（`.`）分隔的DNS标签，总计不超过253个字符，后跟斜杠（`/`）。 -如果省略前缀，则假定注释键对用户是私有的。 由系统组件添加的注释（例如，`kube-scheduler`，`kube-controller-manager`，`kube-apiserver`，`kubectl` 或其他第三方组件），必须为终端用户添加注释前缀。 + +_注解（Annotations）_ 存储的形式是键/值对。有效的注解键分为两部分： +可选的前缀和名称，以斜杠（`/`）分隔。 +名称段是必需项，并且必须在63个字符以内，以字母数字字符（`[a-z0-9A-Z]`）开头和结尾， +并允许使用破折号（`-`），下划线（`_`），点（`.`）和字母数字。 +前缀是可选的。如果指定，则前缀必须是DNS子域：一系列由点（`.`）分隔的DNS标签， +总计不超过253个字符，后跟斜杠（`/`）。 +如果省略前缀，则假定注释键对用户是私有的。 由系统组件添加的注释 +（例如，`kube-scheduler`，`kube-controller-manager`，`kube-apiserver`，`kubectl` +或其他第三方组件），必须为终端用户添加注释前缀。 <!-- The `kubernetes.io/` and `k8s.io/` prefixes are reserved for Kubernetes core components. For example, here’s the configuration file for a Pod that has the annotation `imageregistry: https://hub.docker.com/` : --> +`kubernetes.io/` 和 `k8s.io/` 前缀是为Kubernetes核心组件保留的。 -`kubernetes.io /` 和 `k8s.io /` 前缀是为Kubernetes核心组件保留的。 +例如，这是Pod的配置文件，其注释为 `imageregistry: https://hub.docker.com/`： -例如，这是Pod的配置文件，其注释为 `imageregistry：https：// hub.docker.com /` ： ```yaml - apiVersion: v1 kind: Pod metadata: @@ -160,15 +147,12 @@ spec: image: nginx:1.7.9 ports: - containerPort: 80 - ``` - - ## {{% heading "whatsnext" %}} -进一步了解[标签和选择器](/docs/concepts/overview/working-with-objects/labels/)。 <!-- -Learn more about [Labels and Selectors](/docs/concepts/overview/working-with-objects/labels/). +* Learn more about [Labels and Selectors](/docs/concepts/overview/working-with-objects/labels/). --> +* 进一步了解[标签和选择算符](/zh/docs/concepts/overview/working-with-objects/labels/)。 diff --git a/content/zh/docs/concepts/overview/working-with-objects/common-labels.md b/content/zh/docs/concepts/overview/working-with-objects/common-labels.md index be60e6f10f..4132291df2 100644 --- a/content/zh/docs/concepts/overview/working-with-objects/common-labels.md +++ b/content/zh/docs/concepts/overview/working-with-objects/common-labels.md @@ -64,7 +64,7 @@ on every resource object. | Key | Description | Example | Type | | ----------------------------------- | --------------------- | -------- | ---- | | `app.kubernetes.io/name` | The name of the application | `mysql` | string | -| `app.kubernetes.io/instance` | A unique name identifying the instance of an application | `wordpress-abcxzy` | string | +| `app.kubernetes.io/instance` | A unique name identifying the instance of an application | `mysql-abcxzy` | string | | `app.kubernetes.io/version` | The current version of the application (e.g., a semantic version, revision hash, etc.) | `5.7.21` | string | | `app.kubernetes.io/component` | The component within the architecture | `database` | string | | `app.kubernetes.io/part-of` | The name of a higher level application this one is part of | `wordpress` | string | @@ -73,7 +73,7 @@ on every resource object. | 键 | 描述 | 示例 | 类型 | | ----------------------------------- | --------------------- | -------- | ---- | | `app.kubernetes.io/name` | 应用程序的名称 | `mysql` | 字符串 | -| `app.kubernetes.io/instance` | 用于唯一确定应用实例的名称 | `wordpress-abcxzy` | 字符串 | +| `app.kubernetes.io/instance` | 用于唯一确定应用实例的名称 | `mysql-abcxzy` | 字符串 | | `app.kubernetes.io/version` | 应用程序的当前版本（例如，语义版本，修订版哈希等） | `5.7.21` | 字符串 | | `app.kubernetes.io/component` | 架构中的组件 | `database` | 字符串 | | `app.kubernetes.io/part-of` | 此级别的更高级别应用程序的名称 | `wordpress` | 字符串 | @@ -89,7 +89,7 @@ kind: StatefulSet metadata: labels: app.kubernetes.io/name: mysql - app.kubernetes.io/instance: wordpress-abcxzy + app.kubernetes.io/instance: mysql-abcxzy app.kubernetes.io/version: "5.7.21" app.kubernetes.io/component: database app.kubernetes.io/part-of: wordpress diff --git a/content/zh/docs/concepts/overview/working-with-objects/field-selectors.md b/content/zh/docs/concepts/overview/working-with-objects/field-selectors.md index a7bb9b1794..5184fb0b38 100644 --- a/content/zh/docs/concepts/overview/working-with-objects/field-selectors.md +++ b/content/zh/docs/concepts/overview/working-with-objects/field-selectors.md @@ -3,16 +3,15 @@ title: 字段选择器 weight: 60 --- <!-- ---- title: Field Selectors weight: 60 ---- --> <!-- _Field selectors_ let you [select Kubernetes resources](/docs/concepts/overview/working-with-objects/kubernetes-objects) based on the value of one or more resource fields. Here are some example field selector queries: --> -_字段选择器_（_Field selectors_）允许您根据一个或多个资源字段的值[筛选 Kubernetes 资源](/docs/concepts/overview/working-with-objects/kubernetes-objects)。 +_字段选择器（Field selectors_）允许你根据一个或多个资源字段的值 +[筛选 Kubernetes 资源](/zh/docs/concepts/overview/working-with-objects/kubernetes-objects)。 下面是一些使用字段选择器查询的例子： * `metadata.name=my-service` @@ -22,18 +21,18 @@ _字段选择器_（_Field selectors_）允许您根据一个或多个资源字 <!-- This `kubectl` command selects all Pods for which the value of the [`status.phase`](/docs/concepts/workloads/pods/pod-lifecycle/#pod-phase) field is `Running`: --> -下面这个 `kubectl` 命令将筛选出 [`status.phase`](/docs/concepts/workloads/pods/pod-lifecycle/#pod-phase) 字段值为 `Running` 的所有 Pod： - +下面这个 `kubectl` 命令将筛选出 [`status.phase`](/zh/docs/concepts/workloads/pods/pod-lifecycle/#pod-phase) +字段值为 `Running` 的所有 Pod： ```shell kubectl get pods --field-selector status.phase=Running ``` - -{{< note >}} <!-- Field selectors are essentially resource *filters*. By default, no selectors/filters are applied, meaning that all resources of the specified type are selected. This makes the following `kubectl` queries equivalent: --> -字段选择器本质上是资源*过滤器*。默认情况下，字段选择器/过滤器是未被应用的，这意味着指定类型的所有资源都会被筛选出来。 +{{< note >}} +字段选择器本质上是资源*过滤器（Filters）*。默认情况下，字段选择器/过滤器是未被应用的， +这意味着指定类型的所有资源都会被筛选出来。 这使得以下的两个 `kubectl` 查询是等价的： ```shell @@ -44,30 +43,32 @@ kubectl get pods --field-selector "" <!-- ## Supported fields ---> -## 支持的字段 -<!-- Supported field selectors vary by Kubernetes resource type. All resource types support the `metadata.name` and `metadata.namespace` fields. Using unsupported field selectors produces an error. For example: --> -不同的 Kubernetes 资源类型支持不同的字段选择器。所有资源类型都支持 `metadata.name` 和 `metadata.namespace` 字段。使用不被支持的字段选择器会产生错误，例如： +## 支持的字段 {#supported-fields} + +不同的 Kubernetes 资源类型支持不同的字段选择器。 +所有资源类型都支持 `metadata.name` 和 `metadata.namespace` 字段。 +使用不被支持的字段选择器会产生错误。例如： ```shell kubectl get ingress --field-selector foo.bar=baz ``` + ``` Error from server (BadRequest): Unable to find "ingresses" that match label selector "", field selector "foo.bar=baz": "foo.bar" is not a known field selector: only "metadata.name", "metadata.namespace" ``` <!-- ## Supported operators ---> -## 支持的运算符 -<!-- You can use the `=`, `==`, and `!=` operators with field selectors (`=` and `==` mean the same thing). This `kubectl` command, for example, selects all Kubernetes Services that aren't in the `default` namespace: --> -您可以使用 `=`、`==`和 `!=` 对字段选择器进行运算（`=` 和 `==` 的意义是相同的）。例如，下面这个 `kubectl` 命令将筛选所有不属于 `default` 命名空间的 Kubernetes Service： +## 支持的操作符 {#supported-operators} + +你可在字段选择器中使用 `=`、`==`和 `!=` （`=` 和 `==` 的意义是相同的）操作符。 +例如，下面这个 `kubectl` 命令将筛选所有不属于 `default` 命名空间的 Kubernetes 服务： ```shell kubectl get services --all-namespaces --field-selector metadata.namespace!=default @@ -75,13 +76,15 @@ kubectl get services --all-namespaces --field-selector metadata.namespace!=defa <!-- ## Chained selectors ---> -## 链式选择器 -<!-- As with [label](/docs/concepts/overview/working-with-objects/labels) and other selectors, field selectors can be chained together as a comma-separated list. This `kubectl` command selects all Pods for which the `status.phase` does not equal `Running` and the `spec.restartPolicy` field equals `Always`: --> -同[标签](/docs/concepts/overview/working-with-objects/labels)和其他选择器一样，字段选择器可以通过使用逗号分隔的列表组成一个选择链。下面这个 `kubectl` 命令将筛选 `status.phase` 字段不等于 `Running` 同时 `spec.restartPolicy` 字段等于 `Always` 的所有 Pod： +## 链式选择器 {#chained-selectors} + +同[标签](/zh/docs/concepts/overview/working-with-objects/labels/)和其他选择器一样， +字段选择器可以通过使用逗号分隔的列表组成一个选择链。 +下面这个 `kubectl` 命令将筛选 `status.phase` 字段不等于 `Running` 同时 +`spec.restartPolicy` 字段等于 `Always` 的所有 Pod： ```shell kubectl get pods --field-selector=status.phase!=Running,spec.restartPolicy=Always @@ -89,13 +92,13 @@ kubectl get pods --field-selector=status.phase!=Running,spec.restartPolicy=Alway <!-- ## Multiple resource types ---> -## 多种资源类型 -<!-- You use field selectors across multiple resource types. This `kubectl` command selects all Statefulsets and Services that are not in the `default` namespace: --> -您能够跨多种资源类型来使用字段选择器。下面这个 `kubectl` 命令将筛选出所有不在 `default` 命名空间中的 StatefulSet 和 Service： +## 多种资源类型 {#multiple-resource-types} + +你能够跨多种资源类型来使用字段选择器。 +下面这个 `kubectl` 命令将筛选出所有不在 `default` 命名空间中的 StatefulSet 和 Service： ```shell kubectl get statefulsets,services --all-namespaces --field-selector metadata.namespace!=default diff --git a/content/zh/docs/concepts/overview/working-with-objects/kubernetes-objects.md b/content/zh/docs/concepts/overview/working-with-objects/kubernetes-objects.md index f340841e19..fe47dad14c 100644 --- a/content/zh/docs/concepts/overview/working-with-objects/kubernetes-objects.md +++ b/content/zh/docs/concepts/overview/working-with-objects/kubernetes-objects.md @@ -3,7 +3,7 @@ title: 理解 Kubernetes 对象 content_type: concept weight: 10 card: - name: 概念 + name: concepts weight: 40 --- @@ -33,51 +33,82 @@ This page explains how Kubernetes objects are represented in the Kubernetes API, * The resources available to those applications * The policies around how those applications behave, such as restart policies, upgrades, and fault-tolerance --> - ## 理解 Kubernetes 对象 -在 Kubernetes 系统中，*Kubernetes 对象* 是持久化的实体。Kubernetes 使用这些实体去表示整个集群的状态。特别地，它们描述了如下信息： +在 Kubernetes 系统中，*Kubernetes 对象* 是持久化的实体。 +Kubernetes 使用这些实体去表示整个集群的状态。特别地，它们描述了如下信息： -* 哪些容器化应用在运行（以及在哪个 Node 上） +* 哪些容器化应用在运行（以及在哪些节点上） * 可以被应用使用的资源 * 关于应用运行时表现的策略，比如重启策略、升级策略，以及容错策略 <!-- -A Kubernetes object is a "record of intent"--once you create the object, the Kubernetes system will constantly work to ensure that object exists. By creating an object, you're effectively telling the Kubernetes system what you want your cluster's workload to look like; this is your cluster's *desired state*. +A Kubernetes object is a "record of intent" - once you create the object, the Kubernetes system will constantly work to ensure that object exists. By creating an object, you're effectively telling the Kubernetes system what you want your cluster's workload to look like; this is your cluster's *desired state*. -To work with Kubernetes objects--whether to create, modify, or delete them--you'll need to use the [Kubernetes API](/docs/concepts/overview/kubernetes-api/). When you use the `kubectl` command-line interface, for example, the CLI makes the necessary Kubernetes API calls for you. You can also use the Kubernetes API directly in your own programs using one of the [Client Libraries](/docs/reference/using-api/client-libraries/). +To work with Kubernetes objects - whether to create, modify, or delete them - you'll need to use the [Kubernetes API](/docs/concepts/overview/kubernetes-api/). When you use the `kubectl` command-line interface, for example, the CLI makes the necessary Kubernetes API calls for you. You can also use the Kubernetes API directly in your own programs using one of the [Client Libraries](/docs/reference/using-api/client-libraries/). --> +Kubernetes 对象是 “目标性记录” —— 一旦创建对象，Kubernetes 系统将持续工作以确保对象存在。 +通过创建对象，本质上是在告知 Kubernetes 系统，所需要的集群工作负载看起来是什么样子的， +这就是 Kubernetes 集群的 **期望状态（Desired State）**。 -Kubernetes 对象是 “目标性记录” —— 一旦创建对象，Kubernetes 系统将持续工作以确保对象存在。通过创建对象，本质上是在告知 Kubernetes 系统，所需要的集群工作负载看起来是什么样子的，这就是 Kubernetes 集群的 **期望状态（Desired State）**。 - -操作 Kubernetes 对象 —— 无论是创建、修改，或者删除 —— 需要使用 [Kubernetes API](https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md)。比如，当使用 `kubectl` 命令行接口时，CLI 会执行必要的 Kubernetes API 调用，也可以在程序中使用 [客户端库](/docs/reference/using-api/client-libraries/) 直接调用 Kubernetes API。 +操作 Kubernetes 对象 —— 无论是创建、修改，或者删除 —— 需要使用 +[Kubernetes API](/zh/docs/concepts/overview/kubernetes-api)。 +比如，当使用 `kubectl` 命令行接口时，CLI 会执行必要的 Kubernetes API 调用， +也可以在程序中使用 +[客户端库](/zh/docs/reference/using-api/client-libraries/)直接调用 Kubernetes API。 <!-- ### Object Spec and Status -Every Kubernetes object includes two nested object fields that govern the object's configuration: the object *spec* and the object *status*. The *spec*, which you must provide, describes your desired state for the object--the characteristics that you want the object to have. The *status* describes the *actual state* of the object, and is supplied and updated by the Kubernetes system. At any given time, the Kubernetes Control Plane actively manages an object's actual state to match the desired state you supplied. +Almost every Kubernetes object includes two nested object fields that govern +the object's configuration: the object *`spec`* and the object *`status`*. +For objects that have a `spec`, you have to set this when you create the object, +providing a description of the characteristics you want the resource to have: +its _desired state_. --> +### 对象规约（Spec）与状态（Status） {#object-spec-and-status} -### 对象规约（Spec）与状态（Status） - -每个 Kubernetes 对象包含两个嵌套的对象字段，它们负责管理对象的配置：对象 *spec* 和 对象 *status* 。 -*spec* 是必需的，它描述了对象的 *期望状态（Desired State）* —— 希望对象所具有的特征。 -*status* 描述了对象的 *实际状态（Actual State）* ，它是由 Kubernetes 系统提供和更新的。在任何时刻，Kubernetes 控制面一直努力地管理着对象的实际状态以与期望状态相匹配。 +几乎每个 Kubernetes 对象包含两个嵌套的对象字段，它们负责管理对象的配置： +对象 *`spec`（规约）* 和 对象 *`status`（状态）* 。 +对于具有 `spec` 的对象，你必须在创建对象时设置其内容，描述你希望对象所具有的特征： +*期望状态（Desired State）* 。 <!-- -For example, a Kubernetes Deployment is an object that can represent an application running on your cluster. When you create the Deployment, you might set the Deployment spec to specify that you want three replicas of the application to be running. The Kubernetes system reads the Deployment spec and starts three instances of your desired application--updating the status to match your spec. If any of those instances should fail (a status change), the Kubernetes system responds to the difference between spec and status by making a correction--in this case, starting a replacement instance. +The `status` describes the _current state_ of the object, supplied and updated +by the Kubernetes system and its components. The Kubernetes +{{< glossary_tooltip text="control plane" term_id="control-plane" >}} continually +and actively manages every object's actual state to match the desired state you +supplied. --> +`status` 描述了对象的 _当前状态（Current State）_，它是由 Kubernetes 系统和组件 +设置并更新的。在任何时刻，Kubernetes +{{< glossary_tooltip text="控制面" term_id="control-plane" >}} +都一直积极地管理着对象的实际状态，以使之与期望状态相匹配。 -例如，Kubernetes Deployment 对象能够表示运行在集群中的应用。 -当创建 Deployment 时，可能需要设置 Deployment 的规约，以指定该应用需要有 3 个副本在运行。 -Kubernetes 系统读取 Deployment 规约，并启动我们所期望的该应用的 3 个实例 —— 更新状态以与规约相匹配。 -如果那些实例中有失败的（一种状态变更），Kubernetes 系统通过修正来响应规约和状态之间的不一致 —— 这种情况，会启动一个新的实例来替换。 +<!-- +For example: in Kubernetes, a Deployment is an object that can represent an +application running on your cluster. When you create the Deployment, you +might set the Deployment `spec` to specify that you want three replicas of +the application to be running. The Kubernetes system reads the Deployment +spec and starts three instances of your desired application-updating +the status to match your spec. If any of those instances should fail +(a status change), the Kubernetes system responds to the difference +between spec and status by making a correction-in this case, starting +a replacement instance. +--> +例如，Kubernetes 中的 Deployment 对象能够表示运行在集群中的应用。 +当创建 Deployment 时，可能需要设置 Deployment 的 `spec`，以指定该应用需要有 3 个副本运行。 +Kubernetes 系统读取 Deployment 规约，并启动我们所期望的应用的 3 个实例 +—— 更新状态以与规约相匹配。 +如果这些实例中有的失败了（一种状态变更），Kubernetes 系统通过执行修正操作 +来响应规约和状态间的不一致 —— 在这里意味着它会启动一个新的实例来替换。 <!-- For more information on the object spec, status, and metadata, see the [Kubernetes API Conventions](https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md). --> -关于对象 spec、status 和 metadata 的更多信息，查看 [Kubernetes API 约定](https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md)。 +关于对象 spec、status 和 metadata 的更多信息，可参阅 +[Kubernetes API 约定](https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md)。 <!-- ### Describing a Kubernetes Object @@ -86,11 +117,12 @@ When you create an object in Kubernetes, you must provide the object spec that d Here's an example `.yaml` file that shows the required fields and object spec for a Kubernetes Deployment: --> - ### 描述 Kubernetes 对象 -当创建 Kubernetes 对象时，必须提供对象的规约，用来描述该对象的期望状态，以及关于对象的一些基本信息（例如名称）。 -当使用 Kubernetes API 创建对象时（或者直接创建，或者基于`kubectl`），API 请求必须在请求体中包含 JSON 格式的信息。 +创建 Kubernetes 对象时，必须提供对象的规约，用来描述该对象的期望状态， +以及关于对象的一些基本信息（例如名称）。 +当使用 Kubernetes API 创建对象时（或者直接创建，或者基于`kubectl`）， +API 请求必须在请求体中包含 JSON 格式的信息。 **大多数情况下，需要在 .yaml 文件中为 `kubectl` 提供这些信息**。 `kubectl` 在发起 API 请求时，将这些信息转换成 JSON 格式。 @@ -103,8 +135,7 @@ One way to create a Deployment using a `.yaml` file like the one above is to use [`kubectl apply`](/docs/reference/generated/kubectl/kubectl-commands#apply) command in the `kubectl` command-line interface, passing the `.yaml` file as an argument. Here's an example: --> - -使用类似于上面的 `.yaml` 文件来创建 Deployment，一种方式是使用 `kubectl` 命令行接口（CLI）中的 +使用类似于上面的 `.yaml` 文件来创建 Deployment的一种方式是使用 `kubectl` 命令行接口（CLI）中的 [`kubectl apply`](/docs/reference/generated/kubectl/kubectl-commands#apply) 命令， 将 `.yaml` 文件作为参数。下面是一个示例： @@ -115,10 +146,9 @@ kubectl apply -f https://k8s.io/examples/application/deployment.yaml --record <!-- The output is similar to this: --> - 输出类似如下这样： -```shell +``` deployment.apps/nginx-deployment created ``` @@ -131,14 +161,13 @@ In the `.yaml` file for the Kubernetes object you want to create, you'll need to * `kind` - What kind of object you want to create * `metadata` - Data that helps uniquely identify the object, including a `name` string, `UID`, and optional `namespace` --> - -### 必需字段 +### 必需字段 {#required-fields} 在想要创建的 Kubernetes 对象对应的 `.yaml` 文件中，需要配置如下的字段： * `apiVersion` - 创建该对象所使用的 Kubernetes API 的版本 -* `kind` - 想要创建的对象的类型 -* `metadata` - 帮助识别对象唯一性的数据，包括一个 `name` 字符串、UID 和可选的 `namespace` +* `kind` - 想要创建的对象的类别 +* `metadata` - 帮助唯一性标识对象的一些数据，包括一个 `name` 字符串、UID 和可选的 `namespace` <!-- You'll also need to provide the object `spec` field. The precise format of the object `spec` is different for every Kubernetes object, and contains nested fields specific to that object. The [Kubernetes API Reference](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/) can help you find the spec format for all of the objects you can create using Kubernetes. @@ -147,13 +176,15 @@ For example, the `spec` format for a `Pod` can be found and the `spec` format for a `Deployment` can be found [here](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#deploymentspec-v1-apps). --> - -您也需要提供对象的 `spec` 字段。对象 `spec` 的精确格式对每个 Kubernetes 对象来说是不同的，包含了特定于该对象的嵌套字段。[Kubernetes API 参考](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/)能够帮助我们找到任何我们想创建的对象的 spec 格式。 +你也需要提供对象的 `spec` 字段。 +对象 `spec` 的精确格式对每个 Kubernetes 对象来说是不同的，包含了特定于该对象的嵌套字段。 +[Kubernetes API 参考](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/) +能够帮助我们找到任何我们想创建的对象的 spec 格式。 例如，可以从 -[这里](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podspec-v1-core) +[core/v1 PodSpec](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podspec-v1-core) 查看 `Pod` 的 `spec` 格式， 并且可以从 -[这里](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#deploymentspec-v1-apps) +[apps/v1 DeploymentSpec](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#deploymentspec-v1-apps) 查看 `Deployment` 的 `spec` 格式。 @@ -164,9 +195,7 @@ and the `spec` format for a `Deployment` can be found * Learn about the most important basic Kubernetes objects, such as [Pod](/docs/concepts/workloads/pods/pod-overview/). * Learn about [controllers](/docs/concepts/architecture/controller/) in Kubernetes --> -* [Kubernetes API 概述](/docs/reference/using-api/api-overview/) 提供关于 API 概念的进一步阐述 -* 了解最重要的 Kubernetes 基本对象，例如 [Pod](/docs/concepts/workloads/pods/pod-overview/)。 -* 了解 Kubernetes 中的[控制器](/docs/concepts/architecture/controller/)。 - - +* [Kubernetes API 概述](/zh/docs/reference/using-api/api-overview/) 提供关于 API 概念的进一步阐述 +* 了解最重要的 Kubernetes 基本对象，例如 [Pod](/zh/docs/concepts/workloads/pods/) +* 了解 Kubernetes 中的[控制器](/zh/docs/concepts/architecture/controller/) diff --git a/content/zh/docs/concepts/overview/working-with-objects/labels.md b/content/zh/docs/concepts/overview/working-with-objects/labels.md index 718ad4fc93..941cdaccb2 100644 --- a/content/zh/docs/concepts/overview/working-with-objects/labels.md +++ b/content/zh/docs/concepts/overview/working-with-objects/labels.md @@ -1,26 +1,26 @@ --- -title: 标签和选择器 +title: 标签和选择算符 content_type: concept weight: 40 --- <!-- ---- reviewers: - mikedanese title: Labels and Selectors content_type: concept weight: 40 ---- --> + <!-- overview --> <!-- _Labels_ are key/value pairs that are attached to objects, such as pods. Labels are intended to be used to specify identifying attributes of objects that are meaningful and relevant to users, but do not directly imply semantics to the core system. -Labels can be used to organize and to select subsets of objects. Labels can be attached to objects at creation time and subsequently added and modified at any time. +Labels can be used to organize and to select subsets of objects. +Labels can be attached to objects at creation time and subsequently added and modified at any time. Each object can have a set of key/value labels defined. Each Key must be unique for a given object. --> -_标签_ 是附加到 Kubernetes 对象（比如 Pods）上的键值对。 +_标签（Labels）_ 是附加到 Kubernetes 对象（比如 Pods）上的键值对。 标签旨在用于指定对用户有意义且相关的对象的标识属性，但不直接对核心系统有语义含义。 标签可以用于组织和选择对象的子集。标签可以在创建时附加到对象，随后可以随时添加和修改。 每个对象都可以定义一组键/值标签。每个键对于给定对象必须是唯一的。 @@ -35,116 +35,135 @@ _标签_ 是附加到 Kubernetes 对象（比如 Pods）上的键值对。 ``` <!-- -We'll eventually index and reverse-index labels for efficient queries and watches, use them to sort and group in UIs and CLIs, etc. We don't want to pollute labels with non-identifying, especially large and/or structured, data. Non-identifying information should be recorded using [annotations](/docs/concepts/overview/working-with-objects/annotations/). +Labels allow for efficient queries and watches and are ideal for use in UIs +and CLIs. Non-identifying information should be recorded using +[annotations](/docs/concepts/overview/working-with-objects/annotations/). --> - -我们最终将标签索引和反向索引，用于高效查询和监视，使用它们在 UI 和 CLI 中进行排序和分组等。我们不希望将非标识性的、尤其是大型或结构化数据用作标签，给后者带来污染。应使用 [注解](/docs/concepts/overview/working-with-objects/annotations/) 记录非识别信息 - - - +标签能够支持高效的查询和监听操作，对于用户界面和命令行是很理想的。 +应使用[注解](/zh/docs/concepts/overview/working-with-objects/annotations/) 记录非识别信息。 <!-- body --> <!-- ## Motivation ---> -## 动机 - -<!-- Labels enable users to map their own organizational structures onto system objects in a loosely coupled fashion, without requiring clients to store these mappings. --> +## 动机 + 标签使用户能够以松散耦合的方式将他们自己的组织结构映射到系统对象，而无需客户端存储这些映射。 <!-- Service deployments and batch processing pipelines are often multi-dimensional entities (e.g., multiple partitions or deployments, multiple release tracks, multiple tiers, multiple micro-services per tier). Management often requires cross-cutting operations, which breaks encapsulation of strictly hierarchical representations, especially rigid hierarchies determined by the infrastructure rather than by users. ---> -服务部署和批处理流水线通常是多维实体（例如，多个分区或部署、多个发行序列、多个层，每层多个微服务）。管理通常需要交叉操作，这打破了严格的层次表示的封装，特别是由基础设施而不是用户确定的严格的层次结构。 -<!-- Example labels: --> +服务部署和批处理流水线通常是多维实体（例如，多个分区或部署、多个发行序列、多个层，每层多个微服务）。 +管理通常需要交叉操作，这打破了严格的层次表示的封装，特别是由基础设施而不是用户确定的严格的层次结构。 + 示例标签： - * `"release" : "stable"`, `"release" : "canary"` - * `"environment" : "dev"`, `"environment" : "qa"`, `"environment" : "production"` - * `"tier" : "frontend"`, `"tier" : "backend"`, `"tier" : "cache"` - * `"partition" : "customerA"`, `"partition" : "customerB"` - * `"track" : "daily"`, `"track" : "weekly"` +* `"release" : "stable"`, `"release" : "canary"` +* `"environment" : "dev"`, `"environment" : "qa"`, `"environment" : "production"` +* `"tier" : "frontend"`, `"tier" : "backend"`, `"tier" : "cache"` +* `"partition" : "customerA"`, `"partition" : "customerB"` +* `"track" : "daily"`, `"track" : "weekly"` <!-- -These are just examples of commonly used labels; you are free to develop your own conventions. Keep in mind that label Key must be unique for a given object. +These are just examples of commonly used labels; +you are free to develop your own conventions. +Keep in mind that label Key must be unique for a given object. --> -这些只是常用标签的例子; 您可以任意制定自己的约定。请记住，对于给定对象标签的键必须是唯一的。 +这些只是常用标签的例子; 你可以任意制定自己的约定。请记住，对于给定对象标签的键必须是唯一的。 <!-- ## Syntax and character set + +_Labels_ are key/value pairs. Valid label keys have two segments: an optional prefix and name, separated by a slash (`/`). The name segment is required and must be 63 characters or less, beginning and ending with an alphanumeric character (`[a-z0-9A-Z]`) with dashes (`-`), underscores (`_`), dots (`.`), and alphanumerics between. The prefix is optional. If specified, the prefix must be a DNS subdomain: a series of DNS labels separated by dots (`.`), not longer than 253 characters in total, followed by a slash (`/`). + +If the prefix is omitted, the label Key is presumed to be private to the user. Automated system components (e.g. `kube-scheduler`, `kube-controller-manager`, `kube-apiserver`, `kubectl`, or other third-party automation) which add labels to end-user objects must specify a prefix. + +The `kubernetes.io/` prefix is reserved for Kubernetes core components. --> ## 语法和字符集 +_标签_ 是键值对。有效的标签键有两个段：可选的前缀和名称，用斜杠（`/`）分隔。 +名称段是必需的，必须小于等于 63 个字符，以字母数字字符（`[a-z0-9A-Z]`）开头和结尾， +带有破折号（`-`），下划线（`_`），点（ `.`）和之间的字母数字。 +前缀是可选的。如果指定，前缀必须是 DNS 子域：由点（`.`）分隔的一系列 DNS 标签，总共不超过 253 个字符， +后跟斜杠（`/`）。 -<!-- -_Labels_ are key/value pairs. Valid label keys have two segments: an optional prefix and name, separated by a slash (`/`). The name segment is required and must be 63 characters or less, beginning and ending with an alphanumeric character (`[a-z0-9A-Z]`) with dashes (`-`), underscores (`_`), dots (`.`), and alphanumerics between. The prefix is optional. If specified, the prefix must be a DNS subdomain: a series of DNS labels separated by dots (`.`), not longer than 253 characters in total, followed by a slash (`/`). -If the prefix is omitted, the label Key is presumed to be private to the user. Automated system components (e.g. `kube-scheduler`, `kube-controller-manager`, `kube-apiserver`, `kubectl`, or other third-party automation) which add labels to end-user objects must specify a prefix. The `kubernetes.io/` prefix is reserved for Kubernetes core components. ---> -_标签_ 是键值对。有效的标签键有两个段：可选的前缀和名称，用斜杠（`/`）分隔。名称段是必需的，必须小于等于 63 个字符，以字母数字字符（`[a-z0-9A-Z]`）开头和结尾，带有破折号（`-`），下划线（`_`），点（ `.`）和之间的字母数字。前缀是可选的。如果指定，前缀必须是 DNS 子域：由点（`.`）分隔的一系列 DNS 标签，总共不超过 253 个字符，后跟斜杠（`/`）。 -如果省略前缀，则假定标签键对用户是私有的。 向最终用户对象添加标签的自动系统组件（例如 `kube-scheduler`，`kube-controller-manager`，`kube-apiserver`，`kubectl` 或其他第三方自动化）必须指定前缀。`kubernetes.io/` 前缀是为 Kubernetes 核心组件保留的。 +如果省略前缀，则假定标签键对用户是私有的。 +向最终用户对象添加标签的自动系统组件（例如 `kube-scheduler`、`kube-controller-manager`、 +`kube-apiserver`、`kubectl` 或其他第三方自动化工具）必须指定前缀。 + +`kubernetes.io/` 前缀是为 Kubernetes 核心组件保留的。 <!-- Valid label values must be 63 characters or less and must be empty or begin and end with an alphanumeric character (`[a-z0-9A-Z]`) with dashes (`-`), underscores (`_`), dots (`.`), and alphanumerics between. --> -有效标签值必须为 63 个字符或更少，并且必须为空或以字母数字字符（`[a-z0-9A-Z]`）开头和结尾，中间可以包含破折号（`-`）、下划线（`_`）、点（`.`）和字母或数字。 +有效标签值必须为 63 个字符或更少，并且必须为空或以字母数字字符（`[a-z0-9A-Z]`）开头和结尾， +中间可以包含破折号（`-`）、下划线（`_`）、点（`.`）和字母或数字。 <!-- ## Label selectors ---> -## 标签选择器 -<!-- Unlike [names and UIDs](/docs/user-guide/identifiers), labels do not provide uniqueness. In general, we expect many objects to carry the same label(s). --> -与 [名称和 UID](/docs/user-guide/identifiers) 不同，标签不提供唯一性。通常，我们希望许多对象携带相同的标签。 +## 标签选择算符 {#label-selectors} + +与[名称和 UID](/zh/docs/concepts/overview/working-with-objects/names/) 不同， +标签不支持唯一性。通常，我们希望许多对象携带相同的标签。 <!-- Via a _label selector_, the client/user can identify a set of objects. The label selector is the core grouping primitive in Kubernetes. --> -通过 _标签选择器_，客户端/用户可以识别一组对象。标签选择器是 Kubernetes 中的核心分组原语。 +通过 _标签选择算符_，客户端/用户可以识别一组对象。标签选择算符是 Kubernetes 中的核心分组原语。 <!-- The API currently supports two types of selectors: _equality-based_ and _set-based_. A label selector can be made of multiple _requirements_ which are comma-separated. In the case of multiple requirements, all must be satisfied so the comma separator acts as a logical _AND_ (`&&`) operator. --> -API 目前支持两种类型的选择器：_基于相等性的_ 和 _基于集合的_。 -标签选择器可以由逗号分隔的多个 _需求_ 组成。在多个需求的情况下，必须满足所有要求，因此逗号分隔符充当逻辑 _与_（`&&`）运算符。 +API 目前支持两种类型的选择算符：_基于等值的_ 和 _基于集合的_。 +标签选择算符可以由逗号分隔的多个 _需求_ 组成。 +在多个需求的情况下，必须满足所有要求，因此逗号分隔符充当逻辑 _与_（`&&`）运算符。 <!-- -An empty label selector (that is, one with zero requirements) selects every object in the collection. +The semantics of empty or non-specified selectors are dependent on the context, +and API types that use selectors should document the validity and meaning of +them. --> -空标签选择器（即，需求为零的选择器）选择集合中的每个对象。 +空标签选择算符或者未指定的选择算符的语义取决于上下文， +支持使用选择算符的 API 类别应该将算符的合法性和含义用文档记录下来。 <!-- -A null label selector (which is only possible for optional selector fields) selects no objects. +For some API types, such as ReplicaSets, the label selectors of two instances must not overlap within a namespace, or the controller can see that as conflicting instructions and fail to determine how many replicas should be present. --> -null 值的标签选择器（仅可用于可选选择器字段）不选择任何对象 {{< note >}} -<!-- -**Note**: the label selectors of two controllers must not overlap within a namespace, otherwise they will fight with each other. ---> -**注意**：两个控制器的标签选择器不得在命名空间内重叠，否则它们将互相冲突。 +对于某些 API 类别（例如 ReplicaSet）而言，两个实例的标签选择算符不得在命名空间内重叠， +否则它们的控制器将互相冲突，无法确定应该存在的副本个数。 {{< /note >}} <!-- -### _Equality-based_ requirement +For both equality-based and set-based conditions there is no logical _OR_ (`||`) operator. Ensure your filter statements are structured accordingly. --> -### _基于相等性的_ 需求 - +{{< caution >}} +对于基于等值的和基于集合的条件而言，不存在逻辑或（`||`）操作符。 +你要确保你的过滤语句按合适的方式组织。 +{{< /caution >}} <!-- +### _Equality-based_ requirement + _Equality-_ or _inequality-based_ requirements allow filtering by label keys and values. Matching objects must satisfy all of the specified label constraints, though they may have additional labels as well. Three kinds of operators are admitted `=`,`==`,`!=`. The first two represent _equality_ (and are simply synonyms), while the latter represents _inequality_. For example: --> -_基于相等性_ 或 _不相等_ 的需求允许按标签键和值进行过滤。匹配对象必须满足所有指定的标签约束，尽管它们也可能具有其他标签。 -可接受的运算符有`=`、`==` 和 `！=` 三种。 前两个表示 _相等_（并且只是同义词），而后者表示 _不相等_。 例如： +### _基于等值的_ 需求 + +_基于等值_ 或 _基于不等值_ 的需求允许按标签键和值进行过滤。 +匹配对象必须满足所有指定的标签约束，尽管它们也可能具有其他标签。 +可接受的运算符有`=`、`==` 和 `！=` 三种。 +前两个表示 _相等_（并且只是同义词），而后者表示 _不相等_。例如： ``` environment = production @@ -165,7 +184,8 @@ One usage scenario for equality-based label requirement is for Pods to specify node selection criteria. For example, the sample Pod below selects nodes with the label "`accelerator=nvidia-tesla-p100`". --> -基于相等性的标签要求的一种使用场景是 Pods 要指定节点选择标准。例如，下面的示例 Pod 选择带有标签 "`accelerator=nvidia-tesla-p100`"。 +基于等值的标签要求的一种使用场景是 Pod 要指定节点选择标准。 +例如，下面的示例 Pod 选择带有标签 "`accelerator=nvidia-tesla-p100`"。 ```yaml apiVersion: v1 @@ -185,13 +205,13 @@ spec: <!-- ### _Set-based_ requirement + +_Set-based_ label requirements allow filtering keys according to a set of values. Three kinds of operators are supported: `in`,`notin` and `exists` (only the key identifier). For example: --> ### _基于集合_ 的需求 -<!-- -_Set-based_ label requirements allow filtering keys according to a set of values. Three kinds of operators are supported: `in`,`notin` and `exists` (only the key identifier). For example: ---> -_基于集合_ 的标签需求允许您通过一组值来过滤键。支持三种操作符：`in`,`notin` and `exists` (只可以用在键标识符上)。例如： +_基于集合_ 的标签需求允许你通过一组值来过滤键。 +支持三种操作符：`in`、`notin` 和 `exists` (只可以用在键标识符上)。例如： ``` environment in (production, qa) @@ -202,38 +222,24 @@ partition <!-- The first example selects all resources with key equal to `environment` and value equal to `production` or `qa`. +The second example selects all resources with key equal to `tier` and values other than `frontend` and `backend`, and all resources with no labels with the `tier` key. +The third example selects all resources including a label with key `partition`; no values are checked. +The fourth example selects all resources without a label with key `partition`; no values are checked. +Similarly the comma separator acts as an _AND_ operator. So filtering resources with a `partition` key (no matter the value) and with `environment` different than  `qa` can be achieved using `partition,environment notin (qa)`. --> 第一个示例选择了所有键等于 `environment` 并且值等于 `production` 或者 `qa` 的资源。 - -<!-- -The second example selects all resources with key equal to `tier` and values other than `frontend` and `backend`, and all resources with no labels with the `tier` key. ---> - 第二个示例选择了所有键等于 `tier` 并且值不等于 `frontend` 或者 `backend` 的资源，以及所有没有 `tier` 键标签的资源。 - -<!-- -The third example selects all resources including a label with key `partition`; no values are checked. ----> - 第三个示例选择了所有包含了有 `partition` 标签的资源；没有校验它的值。 - -<!-- -The fourth example selects all resources without a label with key `partition`; no values are checked. ---> - 第四个示例选择了所有没有 `partition` 标签的资源；没有校验它的值。 - -<!-- -Similarly the comma separator acts as an _AND_ operator. So filtering resources with a `partition` key (no matter the value) and with `environment` different than  `qa` can be achieved using `partition,environment notin (qa)`. ---> -类似地，逗号分隔符充当 _AND_ 运算符。因此，使用 `partition` 键（无论为何值）和 `environment` 不同于 `qa` 来过滤资源可以使用 `partition，environment notin（qa)` 来实现。 +类似地，逗号分隔符充当 _与_ 运算符。因此，使用 `partition` 键（无论为何值）和 +`environment` 不同于 `qa` 来过滤资源可以使用 `partition, environment notin（qa)` 来实现。 <!-- The _set-based_ label selector is a general form of equality since `environment=production` is equivalent to `environment in (production)`; similarly for `!=` and `notin`. --> - -_基于集合_ 的标签选择器是相等标签选择器的一般形式，因为 `environment = production` 等同于 `environment in（production）`;`！=` 和 `notin` 也是类似的。 +_基于集合_ 的标签选择算符是相等标签选择算符的一般形式，因为 `environment=production` +等同于 `environment in（production`；`!=` 和 `notin` 也是类似的。 <!-- _Set-based_ requirements can be mixed with _equality-based_ requirements. For example: `partition in (customerA, customerB),environment!=qa`. @@ -244,38 +250,37 @@ _基于集合_ 的要求可以与基于 _相等_ 的要求混合使用。例如 <!-- ### LIST and WATCH filtering + +LIST and WATCH operations may specify label selectors to filter the sets of objects returned using a query parameter. Both requirements are permitted (presented here as they would appear in a URL query string): --> ### LIST 和 WATCH 过滤 -<!-- -LIST and WATCH operations may specify label selectors to filter the sets of objects returned using a query parameter. Both requirements are permitted (presented here as they would appear in a URL query string): ---> -LIST and WATCH 操作可以使用查询参数指定标签选择器过滤一组对象。两种需求都是允许的。（这里显示的是它们出现在 URL 查询字符串中） +LIST and WATCH 操作可以使用查询参数指定标签选择算符过滤一组对象。 +两种需求都是允许的。（这里显示的是它们出现在 URL 查询字符串中） <!-- - * _equality-based_ requirements: `?labelSelector=environment%3Dproduction,tier%3Dfrontend` - * _set-based_ requirements: `?labelSelector=environment+in+%28production%2Cqa%29%2Ctier+in+%28frontend%29` +* _equality-based_ requirements: `?labelSelector=environment%3Dproduction,tier%3Dfrontend` +* _set-based_ requirements: `?labelSelector=environment+in+%28production%2Cqa%29%2Ctier+in+%28frontend%29` --> - * _基于相等性_ 的需求: `?labelSelector=environment%3Dproduction,tier%3Dfrontend` - * _基于集合_ 的需求: `?labelSelector=environment+in+%28production%2Cqa%29%2Ctier+in+%28frontend%29` +* _基于等值_ 的需求: `?labelSelector=environment%3Dproduction,tier%3Dfrontend` +* _基于集合_ 的需求: `?labelSelector=environment+in+%28production%2Cqa%29%2Ctier+in+%28frontend%29` <!-- Both label selector styles can be used to list or watch resources via a REST client. For example, targeting `apiserver` with `kubectl` and using _equality-based_ one may write: --> -两种标签选择器都可以通过 REST 客户端用于 list 或者 watch 资源。例如，使用 `kubectl` 定位 `apiserver`，可以使用 _基于相等性_ 的标签选择器可以这么写： +两种标签选择算符都可以通过 REST 客户端用于 list 或者 watch 资源。 +例如，使用 `kubectl` 定位 `apiserver`，可以使用 _基于等值_ 的标签选择算符可以这么写： ```shell -$ kubectl get pods -l environment=production,tier=frontend +kubectl get pods -l environment=production,tier=frontend ``` -<!-- -or using _set-based_ requirements: ---> +<!-- or using _set-based_ requirements: --> 或者使用 _基于集合的_ 需求： ```shell -$ kubectl get pods -l 'environment in (production),tier in (frontend)' +kubectl get pods -l 'environment in (production),tier in (frontend)' ``` <!-- @@ -284,26 +289,30 @@ As already mentioned _set-based_ requirements are more expressive.  For instanc 正如刚才提到的，_基于集合_ 的需求更具有表达力。例如，它们可以实现值的 _或_ 操作： ```shell -$ kubectl get pods -l 'environment in (production, qa)' +kubectl get pods -l 'environment in (production, qa)' ``` -<!-- -or restricting negative matching via _exists_ operator: ---> +<!-- or restricting negative matching via _exists_ operator: --> 或者通过 _exists_ 运算符限制不匹配： ```shell -$ kubectl get pods -l 'environment,environment notin (frontend)' +kubectl get pods -l 'environment,environment notin (frontend)' ``` <!-- ### Set references in API objects -Some Kubernetes objects, such as [`services`](/docs/user-guide/services) and [`replicationcontrollers`](/docs/user-guide/replication-controller), also use label selectors to specify sets of other resources, such as [pods](/docs/user-guide/pods). +Some Kubernetes objects, such as [`services`](/docs/concepts/services-networking/service/) +and [`replicationcontrollers`](/docs/concepts/workloads/controllers/replicationcontroller/), +also use label selectors to specify sets of other resources, such as +[pods](/docs/concepts/workloads/pods/). --> ### 在 API 对象上设置引用 -一些 Kubernetes 对象，例如 [`services`](/docs/user-guide/services) 和 [`replicationcontrollers`](/docs/user-guide/replication-controller) ，也使用了标签选择器去指定了其他资源的集合，例如 [pods](/docs/user-guide/pods)。 +一些 Kubernetes 对象，例如 [`services`](/zh/docs/concepts/services-networking/service/) +和 [`replicationcontrollers`](/zh/docs/concepts/workloads/controllers/replicationcontroller/) ， +也使用了标签选择算符去指定了其他资源的集合，例如 +[pods](/zh/docs/concepts/workloads/pods/)。 <!-- #### Service and ReplicationController @@ -314,9 +323,9 @@ Labels selectors for both objects are defined in `json` or `yaml` files using ma --> #### Service 和 ReplicationController -一个 `Service` 指向的一组 pods 是由标签选择器定义的。同样，一个 `ReplicationController` 应该管理的 pods 的数量也是由标签选择器定义的。 +一个 `Service` 指向的一组 pods 是由标签选择算符定义的。同样，一个 `ReplicationController` 应该管理的 pods 的数量也是由标签选择算符定义的。 -两个对象的标签选择器都是在 `json` 或者 `yaml` 文件中使用映射定义的，并且只支持 _基于相等性_ 需求的选择器： +两个对象的标签选择算符都是在 `json` 或者 `yaml` 文件中使用映射定义的，并且只支持 _基于等值_ 需求的选择算符： ```json "selector": { @@ -324,9 +333,7 @@ Labels selectors for both objects are defined in `json` or `yaml` files using ma } ``` -<!-- -or ---> +<!-- or --> 或者 ```yaml @@ -337,7 +344,7 @@ selector: <!--- this selector (respectively in `json` or `yaml` format) is equivalent to `component=redis` or `component in (redis)`. --> -这个选择器(分别在 `json` 或者 `yaml` 格式中) 等价于 `component=redis` 或 `component in (redis)` 。 +这个选择算符(分别在 `json` 或者 `yaml` 格式中) 等价于 `component=redis` 或 `component in (redis)` 。 <!-- #### Resources that support set-based requirements @@ -346,7 +353,11 @@ Newer resources, such as [`Job`](/docs/concepts/jobs/run-to-completion-finite-wo --> #### 支持基于集合需求的资源 -比较新的资源，例如 [`Job`](/docs/concepts/jobs/run-to-completion-finite-workloads/)、[`Deployment`](/docs/concepts/workloads/controllers/deployment/)、[`Replica Set`](/docs/concepts/workloads/controllers/replicaset/) 和[`Daemon Set`](/docs/concepts/workloads/controllers/daemonset/) ,也支持 _基于集合的_ 需求。 +比较新的资源，例如 [`Job`](/zh/docs/concepts/workloads/controllers/job/)、 +[`Deployment`](/zh/docs/concepts/workloads/controllers/deployment/)、 +[`Replica Set`](/zh/docs/concepts/workloads/controllers/replicaset/) 和 +[`DaemonSet`](/zh/docs/concepts/workloads/controllers/daemonset/) ， +也支持 _基于集合的_ 需求。 ```yaml selector: @@ -358,21 +369,26 @@ selector: ``` <!-- -`matchLabels` is a map of `{key,value}` pairs. A single `{key,value}` in the `matchLabels` map is equivalent to an element of `matchExpressions`, whose `key` field is "key", the `operator` is "In", and the `values` array contains only "value". `matchExpressions` is a list of pod selector requirements. Valid operators include In, NotIn, Exists, and DoesNotExist. The values set must be non-empty in the case of In and NotIn. All of the requirements, from both `matchLabels` and `matchExpressions` are ANDed together -- they must all be satisfied in order to match. +`matchLabels` is a map of `{key,value}` pairs. A single `{key,value}` in the `matchLabels` map is equivalent to an element of `matchExpressions`, whose `key` field is "key", the `operator` is "In", and the `values` array contains only "value". `matchExpressions` is a list of pod selector requirements. Valid operators include In, NotIn, Exists, and DoesNotExist. The values set must be non-empty in the case of In and NotIn. All of the requirements, from both `matchLabels` and `matchExpressions` are ANDed together - they must all be satisfied in order to match. --> -`matchLabels` 是由 `{key，value}` 对组成的映射。`matchLabels` 映射中的单个 `{key，value }` 等同于 `matchExpressions` 的元素，其 `key`字段为 "key"，`operator` 为 "In"，而 `values` 数组仅包含 "value"。`matchExpressions` 是 pod 选择器要求的列表。有效的运算符包括 In，NotIn，Exists 和 DoesNotExist。在 In 和 NotIn 的情况下，设置的值必须是非空的。来自 `matchLabels` 和 `matchExpressions` 的所有要求都是合在一起 -- 它们必须都满足才能匹配。 +`matchLabels` 是由 `{key,value}` 对组成的映射。 +`matchLabels` 映射中的单个 `{key,value }` 等同于 `matchExpressions` 的元素， +其 `key` 字段为 "key"，`operator` 为 "In"，而 `values` 数组仅包含 "value"。 +`matchExpressions` 是 Pod 选择算符需求的列表。 +有效的运算符包括 `In`、`NotIn`、`Exists` 和 `DoesNotExist`。 +在 `In` 和 `NotIn` 的情况下，设置的值必须是非空的。 +来自 `matchLabels` 和 `matchExpressions` 的所有要求都按逻辑与的关系组合到一起 +-- 它们必须都满足才能匹配。 <!-- #### Selecting sets of nodes ---> -#### 选择节点集 -<!-- One use case for selecting over labels is to constrain the set of nodes onto which a pod can schedule. See the documentation on [node selection](/docs/concepts/configuration/assign-pod-node/) for more information. --> -通过标签进行选择的一个用例是确定节点集，方便 pod 调度。 -有关更多信息，请参阅 [选择节点](/docs/concepts/configuration/assign-pod-node/) 上的文档。 +#### 选择节点集 +通过标签进行选择的一个用例是确定节点集，方便 Pod 调度。 +有关更多信息，请参阅[选择节点](/zh/docs/concepts/scheduling-eviction/assign-pod-node/)文档。 diff --git a/content/zh/docs/concepts/overview/working-with-objects/names.md b/content/zh/docs/concepts/overview/working-with-objects/names.md index e7b7da5afd..303a7e541d 100644 --- a/content/zh/docs/concepts/overview/working-with-objects/names.md +++ b/content/zh/docs/concepts/overview/working-with-objects/names.md @@ -1,5 +1,5 @@ --- -title: 对象名称和IDs +title: 对象名称和 IDs content_type: concept weight: 20 --- @@ -13,46 +13,32 @@ Every Kubernetes object also has a [_UID_](#uids) that is unique across your who For example, you can only have one Pod named `myapp-1234` within the same [namespace](/docs/concepts/overview/working-with-objects/namespaces/), but you can have one Pod and one Deployment that are each named `myapp-1234`. --> -集群中的每一个对象都一个[_名称_](#名称) 来标识在同类资源中的唯一性。 +集群中的每一个对象都一个[_名称_](#names) 来标识在同类资源中的唯一性。 每个 Kubernetes 对象也有一个[_UID_](#uids) 来标识在整个集群中的唯一性。 -比如，在同一个[namespace](/docs/concepts/overview/working-with-objects/namespaces/)中只能命名一个名为 `myapp-1234` 的 Pod, 但是可以命名一个 Pod 和一个 Deployment 同为 `myapp-1234`. +比如，在同一个[名字空间](/zh/docs/concepts/overview/working-with-objects/namespaces/) +中有一个名为 `myapp-1234` 的 Pod, 但是可以命名一个 Pod 和一个 Deployment 同为 `myapp-1234`. <!-- For non-unique user-provided attributes, Kubernetes provides [labels](/docs/user-guide/labels) and [annotations](/docs/concepts/overview/working-with-objects/annotations/). - -See the [identifiers design doc](https://git.k8s.io/community/contributors/design-proposals/architecture/identifiers.md) for the precise syntax rules for Names and - - - - - - -. --> - -对于非唯一的用户提供的属性，Kubernetes 提供了[标签](/docs/user-guide/labels)和[注释](/docs/concepts/overview/working-with-objects/annotations/)。 - -有关名称和 UID 的精确语法规则，请参见[标识符设计文档](https://git.k8s.io/community/contributors/design-proposals/architecture/identifiers.md)。 - - - +对于用户提供的非唯一性的属性，Kubernetes 提供了 +[标签（Labels）](/zh/docs/concepts/working-with-objects/labels)和 +[注解（Annotation）](/zh/docs/concepts/overview/working-with-objects/annotations/)机制。 <!-- body --> <!-- ## Names --> - -## 名称 +## 名称 {#names} {{< glossary_definition term_id="name" length="all" >}} <!-- Below are three types of commonly used name constraints for resources. --> - 以下是比较常见的三种资源命名约束。 <!-- @@ -68,9 +54,11 @@ This means the name must: - end with an alphanumeric character --> -### DNS 子域名 +### DNS 子域名 {#dns-subdomain-names} -某些资源类型需要一个 name 来作为一个 DNS 子域名，见定义 [RFC 1123](https://tools.ietf.org/html/rfc1123)。也就是命名必须满足如下规则： +很多资源类型需要可以用作 DNS 子域名的名称。 +DNS 子域名的定义可参见 [RFC 1123](https://tools.ietf.org/html/rfc1123)。 +这一要求意味着名称必须满足如下规则： - 不能超过253个字符 - 只能包含字母数字，以及'-' 和 '.' @@ -89,10 +77,10 @@ This means the name must: - start with an alphanumeric character - end with an alphanumeric character --> +### DNS 标签名 {#dns-label-names} -### DNS 标签名称 - -某些资源类型需要其名称遵循 DNS 标签的标准，见[RFC 1123](https://tools.ietf.org/html/rfc1123)。也就是命名必须满足如下规则： +某些资源类型需要其名称遵循 [RFC 1123](https://tools.ietf.org/html/rfc1123) +所定义的 DNS 标签标准。也就是命名必须满足如下规则： - 最多63个字符 - 只能包含字母数字，以及'-' @@ -100,19 +88,20 @@ This means the name must: - 须以字母数字结尾 <!-- +### Path Segment Names + Some resource types require their names to be able to be safely encoded as a path segment. In other words, the name may not be "." or ".." and the name may not contain "/" or "%". --> +### 路径分段名称 {#path-segment-names} -### Path 部分名称 - -一些用与 Path 部分的资源类型要求名称能被安全的 encode。换句话说，其名称不能含有这些字符 "."、".."、"/"或"%"。 +某些资源类型要求名称能被安全地用作路径中的片段。 +换句话说，其名称不能是 `.`、`..`，也不可以包含 `/` 或 `%` 这些字符。 <!-- Here’s an example manifest for a Pod named `nginx-demo`. --> - 下面是一个名为`nginx-demo`的 Pod 的配置清单： ```yaml @@ -127,16 +116,14 @@ spec: ports: - containerPort: 80 ``` -{{< note >}} + <!-- Some resource types have additional restrictions on their names. --> - -某些资源类型可能有其相应的附加命名约束。 - +{{< note >}} +某些资源类型可能具有额外的命名约束。 {{< /note >}} - ## UIDs {{< glossary_definition term_id="uid" length="all" >}} @@ -145,18 +132,16 @@ Some resource types have additional restrictions on their names. Kubernetes UIDs are universally unique identifiers (also known as UUIDs). UUIDs are standardized as ISO/IEC 9834-8 and as ITU-T X.667. --> -Kubernetes UIDs 是通用的唯一标识符 (也叫 UUIDs). +Kubernetes UIDs 是全局唯一标识符（也叫 UUIDs）。 UUIDs 是标准化的，见 ISO/IEC 9834-8 和 ITU-T X.667. - - ## {{% heading "whatsnext" %}} <!-- * Read about [labels](/docs/concepts/overview/working-with-objects/labels/) in Kubernetes. * See the [Identifiers and Names in Kubernetes](https://git.k8s.io/community/contributors/design-proposals/architecture/identifiers.md) design document. --> -* 阅读关于 Kubernetes [labels](/docs/concepts/overview/working-with-objects/labels/)。 -* 更多参见 [Kubernetes 标识符和名称设计文档](https://git.k8s.io/community/contributors/design-proposals/architecture/identifiers.md). +* 进一步了解 Kubernetes [标签](/zh/docs/concepts/overview/working-with-objects/labels/) +* 参阅 [Kubernetes 标识符和名称](https://git.k8s.io/community/contributors/design-proposals/architecture/identifiers.md)的设计文档 diff --git a/content/zh/docs/concepts/overview/working-with-objects/namespaces.md b/content/zh/docs/concepts/overview/working-with-objects/namespaces.md index a6456f6400..e40ff89abf 100644 --- a/content/zh/docs/concepts/overview/working-with-objects/namespaces.md +++ b/content/zh/docs/concepts/overview/working-with-objects/namespaces.md @@ -1,10 +1,9 @@ --- -title: 命名空间 +title: 名字空间 content_type: concept weight: 30 --- <!-- ---- reviewers: - derekwaynecarr - mikedanese @@ -12,7 +11,6 @@ reviewers: title: Namespaces content_type: concept weight: 30 ---- --> <!-- overview --> @@ -22,16 +20,14 @@ Kubernetes supports multiple virtual clusters backed by the same physical cluste These virtual clusters are called namespaces. --> Kubernetes 支持多个虚拟集群，它们底层依赖于同一个物理集群。 -这些虚拟集群被称为命名空间。 - - +这些虚拟集群被称为名字空间。 <!-- body --> <!-- ## When to Use Multiple Namespaces --> -## 何时使用多个命名空间 +## 何时使用多个名字空间 <!-- Namespaces are intended for use in environments with many users spread across multiple @@ -39,53 +35,59 @@ teams, or projects. For clusters with a few to tens of users, you should not need to create or think about namespaces at all. Start using namespaces when you need the features they provide. --> -命名空间适用于存在很多跨多个团队或项目的用户的场景。对于只有几到几十个用户的集群，根本不需要创建或考虑命名空间。当需要名称空间提供的功能时，请开始使用它们。 +名字空间适用于存在很多跨多个团队或项目的用户的场景。对于只有几到几十个用户的集群，根本不需要创建或考虑名字空间。当需要名称空间提供的功能时，请开始使用它们。 <!-- Namespaces provide a scope for names. Names of resources need to be unique within a namespace, but not across namespaces. Namespaces can not be nested inside one another and each Kubernetes resource can only be in one namespace. --> -命名空间为名称提供了一个范围。资源的名称需要在命名空间内是唯一的，但不能跨命名空间。命名空间不能相互嵌套，每个 Kubernetes 资源只能在一个命名空间中。 +名字空间为名称提供了一个范围。资源的名称需要在名字空间内是唯一的，但不能跨名字空间。 +名字空间不能相互嵌套，每个 Kubernetes 资源只能在一个名字空间中。 <!-- Namespaces are a way to divide cluster resources between multiple users (via [resource quota](/docs/concepts/policy/resource-quotas/)). ---> -命名空间是在多个用户之间划分集群资源的一种方法（通过[资源配额](/docs/concepts/policy/resource-quotas/)）。 -<!-- In future versions of Kubernetes, objects in the same namespace will have the same access control policies by default. --> -在 Kubernetes 未来版本中，相同命名空间中的对象默认将具有相同的访问控制策略。 +名字空间是在多个用户之间划分集群资源的一种方法（通过[资源配额](/zh/docs/concepts/policy/resource-quotas/)）。 +在 Kubernetes 未来版本中，相同名字空间中的对象默认将具有相同的访问控制策略。 <!-- It is not necessary to use multiple namespaces just to separate slightly different -resources, such as different versions of the same software: use [labels](/docs/user-guide/labels) to distinguish +resources, such as different versions of the same software: use +[labels](/docs/concepts/overview/working-with-objects/labels/) to distinguish resources within the same namespace. --> -不需要使用多个命名空间来分隔轻微不同的资源，例如同一软件的不同版本：使用 [labels](/docs/user-guide/labels) 来区分同一命名空间中的不同资源。 +不需要使用多个名字空间来分隔轻微不同的资源，例如同一软件的不同版本： +使用[标签](/zh/docs/concepts/overview/working-with-objects/labels)来区分同一名字空间中的不同资源。 <!-- ## Working with Namespaces + +Creation and deletion of namespaces are described in the [Admin Guide documentation +for namespaces](/docs/tasks/administer-cluster/namespaces/). --> -## 使用命名空间 +## 使用名字空间 + +名字空间的创建和删除在[名字空间的管理指南文档](/zh/docs/tasks/administer-cluster/namespaces/)描述。 <!-- -Creation and deletion of namespaces are described in the [Admin Guide documentation -for namespaces](/docs/admin/namespaces). +Avoid creating namespace with prefix `kube-`, since it is reserved for Kubernetes system namespaces. --> -命名空间的创建和删除已在[命名空间的管理指南文档](/docs/admin/namespaces)中进行了描述。 +{{< note >}} +避免使用前缀 `kube-` 创建名字空间，因为它是为 Kubernetes 系统名字空间保留的。 +{{< /note >}} <!-- ### Viewing namespaces ---> -### 查看命名空间 -<!-- You can list the current namespaces in a cluster using: --> -您可以使用以下命令列出集群中现存的命名空间： +### 查看名字空间 + +你可以使用以下命令列出集群中现存的名字空间： ```shell kubectl get namespace @@ -93,74 +95,72 @@ kubectl get namespace ``` NAME STATUS AGE default Active 1d +kube-node-lease Active 1d kube-system Active 1d kube-public Active 1d ``` <!-- -Kubernetes starts with three initial namespaces: ---> -Kubernetes 会创建三个初始命名空间： +Kubernetes starts with four initial namespaces: - <!-- - * `default` The default namespace for objects with no other namespace - --> - * `default` 没有指明使用其它命名空间的对象所使用的默认命名空间 - <!-- - * `kube-system` The namespace for objects created by the Kubernetes system - --> - * `kube-system` Kubernetes 系统创建对象所使用的命名空间 - <!-- - * `kube-public` This namespace is created automatically and is readable by all users (including those not authenticated). This namespace is mostly reserved for cluster usage, in case that some resources should be visible and readable publicly throughout the whole cluster. The public aspect of this namespace is only a convention, not a requirement. - --> - * `kube-public` 这个命名空间是自动创建的，所有用户（包括未经过身份验证的用户）都可以读取它。这个命名空间主要用于集群使用，以防某些资源在整个集群中应该是可见和可读的。这个命名空间的公共方面只是一种约定，而不是要求。 +* `default` The default namespace for objects with no other namespace +* `kube-system` The namespace for objects created by the Kubernetes system +* `kube-public` This namespace is created automatically and is readable by all users (including those not authenticated). This namespace is mostly reserved for cluster usage, in case that some resources should be visible and readable publicly throughout the whole cluster. The public aspect of this namespace is only a convention, not a requirement. +* `kube-node-lease` This namespace for the lease objects associated with each node which improves the performance of the node heartbeats as the cluster scales. +--> +Kubernetes 会创建三个初始名字空间： + +* `default` 没有指明使用其它名字空间的对象所使用的默认名字空间 +* `kube-system` Kubernetes 系统创建对象所使用的名字空间 +* `kube-public` 这个名字空间是自动创建的，所有用户（包括未经过身份验证的用户）都可以读取它。 + 这个名字空间主要用于集群使用，以防某些资源在整个集群中应该是可见和可读的。 + 这个名字空间的公共方面只是一种约定，而不是要求。 +* `kube-node-lease` 此名字空间用于与哥哥节点相关的租期（Lease）对象； + 此对象的设计使得集群规模很大时节点心跳检测性能得到提升。 <!-- ### Setting the namespace for a request ---> -### 为请求设置命名空间 -<!-- -To set the namespace for a current request, use the `--namespace` flag. ---> -要为当前请求设置命名空间，请使用 `--namespace` 参数。 +To set the namespace for a current request, use the `-namespace` flag. -<!-- For example: --> +### 为请求设置名字空间 + +要为当前请求设置名字空间，请使用 `--namespace` 参数。 + 例如： ```shell -kubectl run nginx --image=nginx --namespace=<insert-namespace-name-here> -kubectl get pods --namespace=<insert-namespace-name-here> +kubectl run nginx --image=nginx --namespace=<名字空间名称> +kubectl get pods --namespace=<名字空间名称> ``` <!-- ### Setting the namespace preference ---> -### 设置命名空间首选项 -<!-- You can permanently save the namespace for all subsequent kubectl commands in that context. --> -您可以永久保存该上下文中所有后续 kubectl 命令使用的命名空间。 +### 设置名字空间偏好 + +你可以永久保存名字空间，以用于对应上下文中所有后续 kubectl 命令。 ```shell -kubectl config set-context --current --namespace=<insert-namespace-name-here> -# Validate it +kubectl config set-context --current --namespace=<名字空间名称> +# 验证之 kubectl config view | grep namespace: ``` <!-- ## Namespaces and DNS ---> -## 命名空间和 DNS -<!-- When you create a [Service](/docs/user-guide/services), it creates a corresponding [DNS entry](/docs/concepts/services-networking/dns-pod-service/). --> -当您创建一个 [Service](/docs/user-guide/services) 时，Kubernetes 会创建一个相应的 [DNS 条目](/docs/concepts/services-networking/dns-pod-service/)。 +## 名字空间和 DNS + +当你创建一个[服务](/zh/docs/concepts/services-networking/service/) 时， +Kubernetes 会创建一个相应的 [DNS 条目](/zh/docs/concepts/services-networking/dns-pod-service/)。 <!-- This entry is of the form `<service-name>.<namespace-name>.svc.cluster.local`, which means @@ -169,44 +169,44 @@ is local to a namespace. This is useful for using the same configuration across multiple namespaces such as Development, Staging and Production. If you want to reach across namespaces, you need to use the fully qualified domain name (FQDN). --> -该条目的形式是 `<service-name>.<namespace-name>.svc.cluster.local`，这意味着如果容器只使用 `<service-name>`，它将被解析到本地命名空间的服务。这对于跨多个命名空间（如开发、分级和生产）使用相同的配置非常有用。如果您希望跨命名空间访问，则需要使用完全限定域名（FQDN）。 +该条目的形式是 `<服务名称>.<名字空间名称>.svc.cluster.local`，这意味着如果容器只使用 +`<服务名称>`，它将被解析到本地名字空间的服务。这对于跨多个名字空间（如开发、分级和生产） +使用相同的配置非常有用。如果你希望跨名字空间访问，则需要使用完全限定域名（FQDN）。 <!-- ## Not All Objects are in a Namespace --> -## 并非所有对象都在命名空间中 +## 并非所有对象都在名字空间中 <!-- Most Kubernetes resources (e.g. pods, services, replication controllers, and others) are in some namespaces. However namespace resources are not themselves in a namespace. -And low-level resources, such as [nodes](/docs/admin/node) and +And low-level resources, such as [nodes](/docs/concepts/architecture/nodes/) and persistentVolumes, are not in any namespace. --> -大多数 kubernetes 资源（例如 Pod、Service、副本控制器等）都位于某些命名空间中。但是命名空间资源本身并不在命名空间中。而且底层资源，例如 [nodes](/docs/admin/node) 和持久化卷不属于任何命名空间。 +大多数 kubernetes 资源（例如 Pod、Service、副本控制器等）都位于某些名字空间中。 +但是名字空间资源本身并不在名字空间中。而且底层资源，例如 +[节点](/zh/docs/concepts/architecture/nodes/) 和持久化卷不属于任何名字空间。 <!-- To see which Kubernetes resources are and aren't in a namespace: --> -查看哪些 Kubernetes 资源在命名空间中，哪些不在命名空间中： +查看哪些 Kubernetes 资源在名字空间中，哪些不在名字空间中： ```shell -# In a namespace +# 位于名字空间中的资源 kubectl api-resources --namespaced=true -# Not in a namespace +# 不在名字空间中的资源 kubectl api-resources --namespaced=false ``` - - ## {{% heading "whatsnext" %}} <!-- * Learn more about [creating a new namespace](/docs/tasks/administer-cluster/namespaces/#creating-a-new-namespace). * Learn more about [deleting a namespace](/docs/tasks/administer-cluster/namespaces/#deleting-a-namespace). --> -* 进一步了解[建立新的命名空间](/docs/tasks/administer-cluster/namespaces/#creating-a-new-namespace)。 -* 进一步了解[删除命名空间](/docs/tasks/administer-cluster/namespaces/#deleting-a-namespace)。 - - +* 进一步了解[建立新的名字空间](/zh/docs/tasks/administer-cluster/namespaces/#creating-a-new-namespace)。 +* 进一步了解[删除名字空间](/zh/docs/tasks/administer-cluster/namespaces/#deleting-a-namespace)。 diff --git a/content/zh/docs/concepts/policy/limit-range.md b/content/zh/docs/concepts/policy/limit-range.md index 34d97b3995..8412d9e80c 100644 --- a/content/zh/docs/concepts/policy/limit-range.md +++ b/content/zh/docs/concepts/policy/limit-range.md @@ -7,17 +7,15 @@ weight: 10 <!-- overview --> <!-- -By default, containers run with unbounded [compute resources](/docs/user-guide/compute-resources) on a Kubernetes cluster. -With resource quotas, cluster administrators can restrict resource consumption and creation on a namespace basis. +By default, containers run with unbounded [compute resources](/docs/concepts/configuration/manage-resources-containers/) on a Kubernetes cluster. +With resource quotas, cluster administrators can restrict resource consumption and creation on a {{< glossary_tooltip text="namespace" term_id="namespace" >}} basis. Within a namespace, a Pod or Container can consume as much CPU and memory as defined by the namespace's resource quota. There is a concern that one Pod or Container could monopolize all available resources. A LimitRange is a policy to constrain resource allocations (to Pods or Containers) in a namespace. --> - -默认情况下， Kubernetes 集群上的容器运行使用的[计算资源](/docs/user-guide/compute-resources) 没有限制。 -使用资源配额，集群管理员可以以命名空间为单位，限制其资源的使用与创建。 -在命名空间中，一个 Pod 或 Container 最多能够使用命名空间的资源配额所定义的 CPU 和内存用量。有人担心，一个 Pod 或 Container 会垄断所有可用的资源。LimitRange 是在命名空间内限制资源分配（给多个 Pod 或 Container）的策略对象。 - - - +默认情况下， Kubernetes 集群上的容器运行使用的[计算资源](/zh/docs/concepts/configuration/manage-resources-containers/)没有限制。 +使用资源配额，集群管理员可以以{{< glossary_tooltip text="名字空间" term_id="namespace" >}}为单位，限制其资源的使用与创建。 +在命名空间中，一个 Pod 或 Container 最多能够使用命名空间的资源配额所定义的 CPU 和内存用量。 +有人担心，一个 Pod 或 Container 会垄断所有可用的资源。 +LimitRange 是在命名空间内限制资源分配（给多个 Pod 或 Container）的策略对象。 <!-- body --> @@ -30,7 +28,7 @@ A _LimitRange_ provides constraints that can: - Set default request/limit for compute resources in a namespace and automatically inject them to Containers at runtime. --> -一个 _LimitRange_ 对象提供的限制能够做到： +一个 _LimitRange（限制范围）_ 对象提供的限制能够做到： - 在一个命名空间中实施对每个 Pod 或 Container 最小和最大的资源使用量的限制。 - 在一个命名空间中实施对每个 PersistentVolumeClaim 能申请的最小和最大的存储空间大小的限制。 @@ -39,39 +37,27 @@ A _LimitRange_ provides constraints that can: <!-- ## Enabling LimitRange ---> +LimitRange support has been enabled by default since Kubernetes 1.10. + +LimitRange support is enabled by default for many Kubernetes distributions. +--> ## 启用 LimitRange -<!-- -LimitRange support is enabled by default for many Kubernetes distributions. It is -enabled when the apiserver `--enable-admission-plugins=` flag has `LimitRanger` admission controller as -one of its arguments. ---> +对 LimitRange 的支持自 Kubernetes 1.10 版本默认启用。 -对 LimitRange 的支持默认在多数 Kubernetes 发行版中启用。当 apiserver 的 `--enable-admission-plugins` 标志的参数包含 `LimitRanger` 准入控制器时即启用。 - -<!-- -A LimitRange is enforced in a particular namespace when there is a -LimitRange object in that namespace. ---> - -当一个命名空间中有 LimitRange 时，实施该 LimitRange 所定义的限制。 +LimitRange 支持在很多 Kubernetes 发行版本中也是默认启用的。 <!-- The name of a LimitRange object must be a valid [DNS subdomain name](/docs/concepts/overview/working-with-objects/names#dns-subdomain-names). --> - -LimitRange 的名称必须是合法的 [DNS 子域名](/docs/concepts/overview/working-with-objects/names#dns-subdomain-names)。 +LimitRange 的名称必须是合法的 +[DNS 子域名](/zh/docs/concepts/overview/working-with-objects/names#dns-subdomain-names)。 <!-- ### Overview of Limit Range ---> -### 限制范围总览 - -<!-- - The administrator creates one `LimitRange` in one namespace. - Users create resources like Pods, Containers, and PersistentVolumeClaims in the namespace. - The `LimitRanger` admission controller enforces defaults and limits for all Pods and Containers that do not set compute resource requirements and tracks usage to ensure it does not exceed resource minimum, maximum and ratio defined in any LimitRange present in the namespace. @@ -80,12 +66,16 @@ LimitRange 的名称必须是合法的 [DNS 子域名](/docs/concepts/overview/w requests or limits for those values. Otherwise, the system may reject Pod creation. - LimitRange validations occurs only at Pod Admission stage, not on Running Pods. --> +### 限制范围总览 - 管理员在一个命名空间内创建一个 `LimitRange` 对象。 - 用户在命名空间内创建 Pod ，Container 和 PersistentVolumeClaim 等资源。 -- `LimitRanger` 准入控制器对所有没有设置计算资源需求的 Pod 和 Container 设置默认值与限制值，并跟踪其使用量以保证没有超出命名空间中存在的任意 LimitRange 对象中的最小、最大资源使用量以及使用量比值。 -- 若创建或更新资源（Pod, Container, PersistentVolumeClaim）违反了 LimitRange 的约束，向 API 服务器的请求会失败，并返回 HTTP 状态码 `403 FORBIDDEN` 与描述哪一项约束被违反的消息。 -- 若命名空间中的 LimitRange 启用了对 `cpu` 和 `memory` 的限制，用户必须指定这些值的需求使用量与限制使用量。否则，系统将会拒绝创建 Pod。 +- `LimitRanger` 准入控制器对所有没有设置计算资源需求的 Pod 和 Container 设置默认值与限制值， + 并跟踪其使用量以保证没有超出命名空间中存在的任意 LimitRange 对象中的最小、最大资源使用量以及使用量比值。 +- 若创建或更新资源（Pod、 Container、PersistentVolumeClaim）违反了 LimitRange 的约束， + 向 API 服务器的请求会失败，并返回 HTTP 状态码 `403 FORBIDDEN` 与描述哪一项约束被违反的消息。 +- 若命名空间中的 LimitRange 启用了对 `cpu` 和 `memory` 的限制， + 用户必须指定这些值的需求使用量与限制使用量。否则，系统将会拒绝创建 Pod。 - LimitRange 的验证仅在 Pod 准入阶段进行，不对正在运行的 Pod 进行验证。 <!-- @@ -94,32 +84,35 @@ Examples of policies that could be created using limit range are: - In a 2 node cluster with a capacity of 8 GiB RAM and 16 cores, constrain Pods in a namespace to request 100m of CPU with a max limit of 500m for CPU and request 200Mi for Memory with a max limit of 600Mi for Memory. - Define default CPU limit and request to 150m and memory default request to 300Mi for Containers started with no cpu and memory requests in their specs. --> +能够使用限制范围创建的策略示例有： -能够使用限制范围创建策略的例子有： - -- 在一个有两个节点，8 GiB 内存与16个核的集群中，限制一个命名空间的 Pod 申请 100m 单位，最大 500m 单位的 CPU，以及申请 200Mi，最大 600Mi 的内存。 -- 为 spec 中没有 cpu 和内存需求值的 Container 定义默认 CPU 限制值与需求值 150m，内存默认需求值 300Mi。 +- 在一个有两个节点，8 GiB 内存与16个核的集群中，限制一个命名空间的 Pod 申请 + 100m 单位，最大 500m 单位的 CPU，以及申请 200Mi，最大 600Mi 的内存。 +- 为 spec 中没有 cpu 和内存需求值的 Container 定义默认 CPU 限制值与需求值 + 150m，内存默认需求值 300Mi。 <!-- In the case where the total limits of the namespace is less than the sum of the limits of the Pods/Containers, there may be contention for resources. In this case, the Containers or Pods will not be created. --> - -在命名空间的总限制值小于 Pod 或 Container 的限制值的总和的情况下，可能会产生资源竞争。在这种情况下，将不会创建 Container 或 Pod。 +在命名空间的总限制值小于 Pod 或 Container 的限制值的总和的情况下，可能会产生资源竞争。 +在这种情况下，将不会创建 Container 或 Pod。 <!-- Neither contention nor changes to a LimitRange will affect already created resources. --> - 竞争和对 LimitRange 的改变都不会影响任何已经创建了的资源。 +## {{% heading "whatsnext" %}} + <!-- -## Examples +See [LimitRanger design doc](https://git.k8s.io/community/contributors/design-proposals/resource-management/admission_control_limit_range.md) for more information. --> - -## 示例 +参阅 [LimitRanger 设计文档](https://git.k8s.io/community/contributors/design-proposals/resource-management/admission_control_limit_range.md)获取更多信息。 <!-- +For examples on using limits, see: + - See [how to configure minimum and maximum CPU constraints per namespace](/docs/tasks/administer-cluster/manage-resources/cpu-constraint-namespace/). - See [how to configure minimum and maximum Memory constraints per namespace](/docs/tasks/administer-cluster/manage-resources/memory-constraint-namespace/). - See [how to configure default CPU Requests and Limits per namespace](/docs/tasks/administer-cluster/manage-resources/cpu-default-namespace/). @@ -127,23 +120,12 @@ Neither contention nor changes to a LimitRange will affect already created resou - Check [how to configure minimum and maximum Storage consumption per namespace](/docs/tasks/administer-cluster/limit-storage-consumption/#limitrange-to-limit-requests-for-storage). - See a [detailed example on configuring quota per namespace](/docs/tasks/administer-cluster/quota-memory-cpu-namespace/). --> +关于使用限值的例子，可参看 -- 查看[如何配置每个命名空间最小和最大的 CPU 约束](/docs/tasks/administer-cluster/manage-resources/cpu-constraint-namespace/)。 -- 查看[如何配置每个命名空间最小和最大的内存约束](/docs/tasks/administer-cluster/manage-resources/memory-constraint-namespace/)。 -- 查看[如何配置每个命名空间默认的 CPU 申请值和限制值](/docs/tasks/administer-cluster/manage-resources/cpu-default-namespace/)。 -- 查看[如何配置每个命名空间默认的内存申请值和限制值](/docs/tasks/administer-cluster/manage-resources/memory-default-namespace/)。 -- 查看[如何配置每个命名空间最小和最大存储使用量](/docs/tasks/administer-cluster/limit-storage-consumption/#limitrange-to-limit-requests-for-storage)。 -- 查看[配置每个命名空间的配额的详细例子](/docs/tasks/administer-cluster/quota-memory-cpu-namespace/)。 - - - -## {{% heading "whatsnext" %}} - - -<!-- -See [LimitRanger design doc](https://git.k8s.io/community/contributors/design-proposals/resource-management/admission_control_limit_range.md) for more information. ---> - -查看 [LimitRanger 设计文档](https://git.k8s.io/community/contributors/design-proposals/resource-management/admission_control_limit_range.md)获取更多信息。 - +- [如何配置每个命名空间最小和最大的 CPU 约束](/zh/docs/tasks/administer-cluster/manage-resources/cpu-constraint-namespace/)。 +- [如何配置每个命名空间最小和最大的内存约束](/zh/docs/tasks/administer-cluster/manage-resources/memory-constraint-namespace/)。 +- [如何配置每个命名空间默认的 CPU 申请值和限制值](/zh/docs/tasks/administer-cluster/manage-resources/cpu-default-namespace/)。 +- [如何配置每个命名空间默认的内存申请值和限制值](/zh/docs/tasks/administer-cluster/manage-resources/memory-default-namespace/)。 +- [如何配置每个命名空间最小和最大存储使用量](/zh/docs/tasks/administer-cluster/limit-storage-consumption/#limitrange-to-limit-requests-for-storage)。 +- [配置每个命名空间的配额的详细例子](/zh/docs/tasks/administer-cluster/manage-resources/quota-memory-cpu-namespace/)。 diff --git a/content/zh/docs/concepts/policy/pod-security-policy.md b/content/zh/docs/concepts/policy/pod-security-policy.md index 1573ff7af2..3c24f027b0 100644 --- a/content/zh/docs/concepts/policy/pod-security-policy.md +++ b/content/zh/docs/concepts/policy/pod-security-policy.md @@ -1,43 +1,81 @@ --- -approvers: -- pweil- title: Pod 安全策略 +content_type: concept +weight: 20 --- +<!-- +reviewers: +- pweil- +- tallclair +title: Pod Security Policies +content_type: concept +weight: 20 +--> +{{< feature-state state="beta" >}} -`PodSecurityPolicy` 类型的对象能够控制，是否可以向 Pod 发送请求，该 Pod 能够影响被应用到 Pod 和容器的 `SecurityContext`。 -查看 [Pod 安全策略建议](https://git.k8s.io/community/contributors/design-proposals/security-context-constraints.md) 获取更多信息。 - -{{< toc >}} - +<!-- +Pod Security Policies enable fine-grained authorization of pod creation and +updates. +--> +Pod 安全策略使得对 Pod 创建和更新进行细粒度的权限控制成为可能。 +<!-- +## What is a Pod Security Policy? +A _Pod Security Policy_ is a cluster-level resource that controls security +sensitive aspects of the pod specification. The [PodSecurityPolicy](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podsecuritypolicy-v1beta1-policy) objects +define a set of conditions that a pod must run with in order to be accepted into +the system, as well as defaults for the related fields. They allow an +administrator to control the following: +--> ## 什么是 Pod 安全策略？ -_Pod 安全策略_ 是集群级别的资源，它能够控制 Pod 运行的行为，以及它具有访问什么的能力。 -`PodSecurityPolicy` 对象定义了一组条件，指示 Pod 必须按系统所能接受的顺序运行。 -它们允许管理员控制如下方面： - - - -| 控制面 | 字段名称 | -| ------------------------------------------------------------- | --------------------------------- | -| 已授权容器的运行 | `privileged` | -| 为容器添加默认的一组能力 | `defaultAddCapabilities` | -| 为容器去掉某些能力 | `requiredDropCapabilities` | -| 容器能够请求添加某些能力 | `allowedCapabilities` | -| 控制卷类型的使用 | [`volumes`](#controlling-volumes) | -| 主机网络的使用 | [`hostNetwork`](#host-network) | -| 主机端口的使用 | `hostPorts` | -| 主机 PID namespace 的使用 | `hostPID` | -| 主机 IPC namespace 的使用 | `hostIPC` | -| 主机路径的使用 | [`allowedHostPaths`](#allowed-host-paths) | -| 容器的 SELinux 上下文 | [`seLinux`](#selinux) | -| 用户 ID | [`runAsUser`](#runasuser) | -| 配置允许的补充组 | [`supplementalGroups`](#supplementalgroups) | -| 分配拥有 Pod 数据卷的 FSGroup | [`fsGroup`](#fsgroup) | -| 必须使用一个只读的 root 文件系统 | `readOnlyRootFilesystem` | +_Pod 安全策略（Pod Security Policy）_ 是集群级别的资源，它能够控制 Pod 规约 +中与安全性相关的各个方面。 +[PodSecurityPolicy](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podsecuritypolicy-v1beta1-policy) +对象定义了一组 Pod 运行时必须遵循的条件及相关字段的默认值，只有 Pod 满足这些条件 +才会被系统接受。 +Pod 安全策略允许管理员控制如下方面： +<!-- +| Control Aspect | Field Names | +| ----------------------------------------------------| ----------------------------------------- | +| Running of privileged containers | [`privileged`](#privileged) | +| Usage of host namespaces | [`hostPID`, `hostIPC`](#host-namespaces) | +| Usage of host networking and ports | [`hostNetwork`, `hostPorts`](#host-namespaces) | +| Usage of volume types | [`volumes`](#volumes-and-file-systems) | +| Usage of the host filesystem | [`allowedHostPaths`](#volumes-and-file-systems) | +| Allow specific FlexVolume drivers | [`allowedFlexVolumes`](#flexvolume-drivers) | +| Allocating an FSGroup that owns the pod's volumes | [`fsGroup`](#volumes-and-file-systems) | +| Requiring the use of a read only root file system | [`readOnlyRootFilesystem`](#volumes-and-file-systems) | +| The user and group IDs of the container | [`runAsUser`, `runAsGroup`, `supplementalGroups`](#users-and-groups) | +| Restricting escalation to root privileges | [`allowPrivilegeEscalation`, `defaultAllowPrivilegeEscalation`](#privilege-escalation) | +| Linux capabilities | [`defaultAddCapabilities`, `requiredDropCapabilities`, `allowedCapabilities`](#capabilities) | +| The SELinux context of the container | [`seLinux`](#selinux) | +| The Allowed Proc Mount types for the container | [`allowedProcMountTypes`](#allowedprocmounttypes) | +| The AppArmor profile used by containers | [annotations](#apparmor) | +| The seccomp profile used by containers | [annotations](#seccomp) | +| The sysctl profile used by containers | [`forbiddenSysctls`,`allowedUnsafeSysctls`](#sysctl) | +--> +| 控制的角度 | 字段名称 | +| ----------------------------------- | --------------------------------- | +| 运行特权容器 | [`privileged`](#privileged) | +| 使用宿主名字空间 | [`hostPID`、`hostIPC`](#host-namespaces) | +| 使用宿主的网络和端口 | [`hostNetwork`, `hostPorts`](#host-namespaces) | +| 控制卷类型的使用 | [`volumes`](#volumes-and-file-systems) | +| 使用宿主文件系统 | [`allowedHostPaths`](#volumes-and-file-systems) | +| 允许使用特定的 FlexVolume 驱动 | [`allowedFlexVolumes`](#flexvolume-drivers) | +| 分配拥有 Pod 卷的 FSGroup 账号 | [`fsGroup`](#volumes-and-file-systems) | +| 以只读方式访问根文件系统 | [`readOnlyRootFilesystem`](#volumes-and-file-systems) | +| 设置容器的用户和组 ID | [`runAsUser`, `runAsGroup`, `supplementalGroups`](#users-and-groups) | +| 限制 roo 账号特权级提升 | [`allowPrivilegeEscalation`, `defaultAllowPrivilegeEscalation`](#privilege-escalation) | +| Linux 权能字（Capabilities） | [`defaultAddCapabilities`, `requiredDropCapabilities`, `allowedCapabilities`](#capabilities) | +| 设置容器的 SELinux 上下文 | [`seLinux`](#selinux) | +| 指定容器可以挂载的 proc 类型 | [`allowedProcMountTypes`](#allowedprocmounttypes) | +| 指定容器使用的 AppArmor 模版 | [annotations](#apparmor) | +| 指定容器使用的 seccomp 模版 | [annotations](#seccomp) | +| 指定容器使用的 sysctl 模版 | [`forbiddenSysctls`,`allowedUnsafeSysctls`](#sysctl) | _Pod 安全策略_ 由设置和策略组成，它们能够控制 Pod 访问的安全特征。这些设置分为如下三类： @@ -46,180 +84,1142 @@ _Pod 安全策略_ 由设置和策略组成，它们能够控制 Pod 访问的 - *基于被允许的值集合控制* ：这种类型的字段会与这组值进行对比，以确认值被允许。 - *基于策略控制* ：设置项通过一种策略提供的机制来生成该值，这种机制能够确保指定的值落在被允许的这组值中。 +<!-- +## Enabling Pod Security Policies +Pod security policy control is implemented as an optional (but recommended) +[admission +controller](/docs/reference/access-authn-authz/admission-controllers/#podsecuritypolicy). PodSecurityPolicies +are enforced by [enabling the admission +controller](/docs/reference/access-authn-authz/admission-controllers/#how-do-i-turn-on-an-admission-control-plug-in), +but doing so without authorizing any policies **will prevent any pods from being +created** in the cluster. +--> +## 启用 Pod 安全策略 -### RunAsUser +Pod 安全策略实现为一种可选（但是建议启用）的 +[准入控制器](/zh/docs/reference/access-authn-authz/admission-controllers/#podsecuritypolicy)。 +[启用了准入控制器](/zh/docs/reference/access-authn-authz/admission-controllers/#how-do-i-turn-on-an-admission-control-plug-in) +即可强制实施 Pod 安全策略，不过如果没有授权认可策略之前即启用 +准入控制器 **将导致集群中无法创建任何 Pod**。 +<!-- +Since the pod security policy API (`policy/v1beta1/podsecuritypolicy`) is +enabled independently of the admission controller, for existing clusters it is +recommended that policies are added and authorized before enabling the admission +controller. +--> +由于 Pod 安全策略 API（`policy/v1beta1/podsecuritypolicy`）是独立于准入控制器 +来启用的，对于现有集群而言，建议在启用准入控制器之前先添加策略并对其授权。 +<!-- +## Authorizing Policies -- *MustRunAs* - 必须配置一个 `range`。使用该范围内的第一个值作为默认值。验证是否不在配置的该范围内。 -- *MustRunAsNonRoot* - 要求提交的 Pod 具有非零 `runAsUser` 值，或在镜像中定义了 `USER` 环境变量。不提供默认值。 -- *RunAsAny* - 没有提供默认值。允许指定任何 `runAsUser` 。 +When a PodSecurityPolicy resource is created, it does nothing. In order to use +it, the requesting user or target pod's [service +account](/docs/tasks/configure-pod-container/configure-service-account/) must be +authorized to use the policy, by allowing the `use` verb on the policy. +--> +## 授权策略 {#authorizing-policies} +PodSecurityPolicy 资源被创建时，并不执行任何操作。为了使用该资源，需要对 +发出请求的用户或者目标 Pod 的 +[服务账号](/zh/docs/tasks/configure-pod-container/configure-service-account/) +授权，通过允许其对策略执行 `use` 动词允许其使用该策略。 +<!-- +Most Kubernetes pods are not created directly by users. Instead, they are +typically created indirectly as part of a +[Deployment](/docs/concepts/workloads/controllers/deployment/), +[ReplicaSet](/docs/concepts/workloads/controllers/replicaset/), or other +templated controller via the controller manager. Granting the controller access +to the policy would grant access for *all* pods created by that controller, +so the preferred method for authorizing policies is to grant access to the +pod's service account (see [example](#run-another-pod)). +--> +大多数 Kubernetes Pod 不是由用户直接创建的。相反，这些 Pod 是由 +[Deployment](/zh/docs/concepts/workloads/controllers/deployment/)、 +[ReplicaSet](/zh/docs/concepts/workloads/controllers/replicaset/) +或者经由控制器管理器模版化的控制器创建。 +赋予控制器访问策略的权限意味着对应控制器所创建的 *所有* Pod 都可访问策略。 +因此，对策略进行授权的优先方案是为 Pod 的服务账号授予访问权限 +（参见[示例](#run-another-pod)）。 -### SELinux +<!-- +### Via RBAC -- *MustRunAs* - 如果没有使用预分配的值，必须配置 `seLinuxOptions`。默认使用 `seLinuxOptions`。验证 `seLinuxOptions`。 -- *RunAsAny* - 没有提供默认值。允许任意指定的 `seLinuxOptions` ID。 +[RBAC](/docs/reference/access-authn-authz/rbac/) is a standard Kubernetes +authorization mode, and can easily be used to authorize use of policies. +First, a `Role` or `ClusterRole` needs to grant access to `use` the desired +policies. The rules to grant access look like this: +```yaml +apiVersion: rbac.authorization.k8s.io/v1 +kind: ClusterRole +metadata: + name: <role name> +rules: +- apiGroups: ['policy'] + resources: ['podsecuritypolicies'] + verbs: ['use'] + resourceNames: + - <list of policies to authorize> +``` +--> +### 通过 RBAC 授权 {#via-rbac} -### SupplementalGroups +[RBAC](/zh/docs/reference/access-authn-authz/rbac/) 是一种标准的 Kubernetes +鉴权模式，可以很容易地用来授权策略访问。 -- *MustRunAs* - 至少需要指定一个范围。默认使用第一个范围的最小值。验证所有范围的值。 -- *RunAsAny* - 没有提供默认值。允许任意指定的 `supplementalGroups` ID。 +首先，某 `Role` 或 `ClusterRole` 需要获得使用 `use` 访问目标策略的权限。 +访问授权的规则看起来像这样： +```yaml +apiVersion: rbac.authorization.k8s.io/v1 +kind: ClusterRole +metadata: + name: <Role 名称> +rules: +- apiGroups: ['policy'] + resources: ['podsecuritypolicies'] + verbs: ['use'] + resourceNames: + - <要授权的策略列表> +``` +<!-- +Then the `(Cluster)Role` is bound to the authorized user(s): -### FSGroup +```yaml +apiVersion: rbac.authorization.k8s.io/v1 +kind: ClusterRoleBinding +metadata: + name: <binding name> +roleRef: + kind: ClusterRole + name: <role name> + apiGroup: rbac.authorization.k8s.io +subjects: +# Authorize specific service accounts: +- kind: ServiceAccount + name: <authorized service account name> + namespace: <authorized pod namespace> +# Authorize specific users (not recommended): +- kind: User + apiGroup: rbac.authorization.k8s.io + name: <authorized user name> +``` +--> +接下来将该 `Role`（或 `ClusterRole`）绑定到授权的用户： -- *MustRunAs* - 至少需要指定一个范围。默认使用第一个范围的最小值。验证在第一个范围内的第一个 ID。 -- *RunAsAny* - 没有提供默认值。允许任意指定的 `fsGroup` ID。 +```yaml +apiVersion: rbac.authorization.k8s.io/v1 +kind: ClusterRoleBinding +metadata: + name: <绑定名称> +roleRef: + kind: ClusterRole + name: <角色名称> + apiGroup: rbac.authorization.k8s.io +subjects: +# 授权特定的服务账号 +- kind: ServiceAccount + name: <要授权的服务账号名称> + namespace: <authorized pod namespace> +# 授权特定的用户（不建议这样操作） +- kind: User + apiGroup: rbac.authorization.k8s.io + name: <要授权的用户名> +``` +<!-- +If a `RoleBinding` (not a `ClusterRoleBinding`) is used, it will only grant +usage for pods being run in the same namespace as the binding. This can be +paired with system groups to grant access to all pods run in the namespace: +```yaml +# Authorize all service accounts in a namespace: +- kind: Group + apiGroup: rbac.authorization.k8s.io + name: system:serviceaccounts +# Or equivalently, all authenticated users in a namespace: +- kind: Group + apiGroup: rbac.authorization.k8s.io + name: system:authenticated +``` +--> +如果使用的是 `RoleBinding`（而不是 `ClusterRoleBinding`），授权仅限于 +与该 `RoleBinding` 处于同一名字空间中的 Pods。 +可以考虑将这种授权模式和系统组结合，对名字空间中的所有 Pod 授予访问权限。 +```yaml +# 授权该某名字空间中所有服务账号 +- kind: Group + apiGroup: rbac.authorization.k8s.io + name: system:serviceaccounts +# 或者与之等价，授权给某名字空间中所有被认证过的用户 +- kind: Group + apiGroup: rbac.authorization.k8s.io + name: system:authenticated +``` -### 控制卷 +<!-- +For more examples of RBAC bindings, see [Role Binding +Examples](/docs/reference/access-authn-authz/rbac#role-binding-examples). +For a complete example of authorizing a PodSecurityPolicy, see +[below](#example). +--> +参阅[角色绑定示例](/zh/docs/reference/access-authn-authz/rbac#role-binding-examples) +查看 RBAC 绑定的更多实例。 +参阅[下文](#example)，查看对 PodSecurityPolicy 进行授权的完整示例。 -通过设置 PSP 卷字段，能够控制具体卷类型的使用。当创建一个卷的时候，与该字段相关的已定义卷可以允许设置如下值： +<!-- +### Troubleshooting -1. azureFile -1. azureDisk -1. flocker -1. flexVolume -1. hostPath -1. emptyDir -1. gcePersistentDisk -1. awsElasticBlockStore -1. gitRepo -1. secret -1. nfs -1. iscsi -1. glusterfs -1. persistentVolumeClaim -1. rbd -1. cinder -1. cephFS -1. downwardAPI -1. fc -1. configMap -1. vsphereVolume -1. quobyte -1. projected -1. portworxVolume -1. scaleIO -1. storageos -1. \* (allow all volumes) +- The [Controller Manager](/docs/reference/command-line-tools-reference/kube-controller-manager/) must be run +against [the secured API port](/docs/reference/access-authn-authz/controlling-access/), +and must not have superuser permissions. Otherwise requests would bypass +authentication and authorization modules, all PodSecurityPolicy objects would be +allowed, and users would be able to create privileged containers. For more details +on configuring Controller Manager authorization, see +[Controller Roles](/docs/reference/access-authn-authz/rbac/#controller-roles). +--> +### 故障排查 {#troubleshooting} +- [控制器管理器组件](/zh/docs/reference/command-line-tools-reference/kube-controller-manager/) + 必须运行在 + [安全的 API 端口](/zh/docs/reference/access-authn-authz/controlling-access/)， + 并且一定不能具有超级用户权限。 + 否则其请求会绕过身份认证和鉴权模块控制，从而导致所有 PodSecurityPolicy 对象 + 都被启用，用户亦能创建特权容器。 + 关于配置控制器管理器鉴权相关的详细信息，可参阅 + [控制器角色](/zh/docs/reference/access-authn-authz/rbac/#controller-roles)。 +<!-- +## Policy Order -对新的 PSP，推荐允许的卷的最小集合包括：configMap、downwardAPI、emptyDir、persistentVolumeClaim、secret 和 projected。 +In addition to restricting pod creation and update, pod security policies can +also be used to provide default values for many of the fields that it +controls. When multiple policies are available, the pod security policy +controller selects policies according to the following criteria: +--> +## 策略顺序 {#policy-order} +除了限制 Pod 创建与更新，Pod 安全策略也可用来为其所控制的很多字段 +设置默认值。当存在多个策略对象时，Pod 安全策略控制器依据以下条件选择 +策略： +<!-- +1. PodSecurityPolicies which allow the pod as-is, without changing defaults or + mutating the pod, are preferred. The order of these non-mutating + PodSecurityPolicies doesn't matter. +2. If the pod must be defaulted or mutated, the first PodSecurityPolicy + (ordered by name) to allow the pod is selected. +--> +1. 优先考虑中允许 Pod 不经修改地创建或更新的 PodSecurityPolicy，这些策略 + 不会更改 Pod 字段的默认值或者其他配置。 + 这类非更改性质的 PodSecurityPolicy 对象之间的顺序无关紧要。 +2. 如果必须要为 Pod 设置默认值或者其他配置，（按名称顺序）选择第一个允许 + Pod 操作的 PodSecurityPolicy 对象。 -### 主机网络 - - *HostPorts* ， 默认为 `empty`。`HostPortRange` 列表通过 `min`(包含) and `max`(包含) 来定义，指定了被允许的主机端口。 +<!-- +During update operations (during which mutations to pod specs are disallowed) +only non-mutating PodSecurityPolicies are used to validate the pod. +--> +{{< note >}} +在更新操作期间（这时不允许更改 Pod 规约），仅使用非更改性质的 +PodSecurityPolicy 来对 Pod 执行验证操作。 +{{< /note >}} -### 允许的主机路径 - - *AllowedHostPaths* 是一个被允许的主机路径前缀的白名单。空值表示所有的主机路径都可以使用。 +<!-- +## Example +_This example assumes you have a running cluster with the PodSecurityPolicy +admission controller enabled and you have cluster admin privileges._ +--> +## 示例 {#example} +_本示例假定你已经有一个启动了 PodSecurityPolicy 准入控制器的集群并且 +你拥有集群管理员特权。_ -## 许可 +<!-- +### Set up -包含 `PodSecurityPolicy` 的 _许可控制_，允许控制集群资源的创建和修改，基于这些资源在集群范围内被许可的能力。 +Set up a namespace and a service account to act as for this example. We'll use +this service account to mock a non-admin user. +--> +### 配置 {#set-up} -许可使用如下的方式为 Pod 创建最终的安全上下文： -1. 检索所有可用的 PSP。 -1. 生成在请求中没有指定的安全上下文设置的字段值。 -1. 基于可用的策略，验证最终的设置。 +为运行此示例，配置一个名字空间和一个服务账号。我们将用这个服务账号来 +模拟一个非管理员账号的用户。 -如果某个策略能够匹配上，该 Pod 就被接受。如果请求与 PSP 不匹配，则 Pod 被拒绝。 +```shell +kubectl create namespace psp-example +kubectl create serviceaccount -n psp-example fake-user +kubectl create rolebinding -n psp-example fake-editor --clusterrole=edit --serviceaccount=psp-example:fake-user +``` -Pod 必须基于 PSP 验证每个字段。 +<!-- +To make it clear which user we're acting as and save some typing, create 2 +aliases: +--> +创建两个别名，以更清晰地展示我们所使用的用户账号，同时减少一些键盘输入： +```shell +alias kubectl-admin='kubectl -n psp-example' +alias kubectl-user='kubectl --as=system:serviceaccount:psp-example:fake-user -n psp-example' +``` <!-- ### Create a policy and a pod Define the example PodSecurityPolicy object in a file. This is a policy that simply prevents the creation of privileged pods. - -{{< codenew file="policy/example-psp.yaml" >}} - -And create it with kubectl: - -```shell -kubectl-admin create -f example-psp.yaml -``` +The name of a PodSecurityPolicy object must be a valid +[DNS subdomain name](/docs/concepts/overview/working-with-objects/names#dns-subdomain-names). --> - ### 创建一个策略和一个 Pod -在一个文件中定义 PodSecurityPolicy 对象实例。这里的策略只是用来禁止创建有特权 -要求的 Pods。 +在一个文件中定一个示例的 PodSecurityPolicy 对象。 +这里的策略只是用来禁止创建有特权要求的 Pods。 +PodSecurityPolicy 对象的名称必须是合法的 +[DNS 子域名](/zh/docs/concepts/overview/working-with-objects/names#dns-subdomain-names)。 {{< codenew file="policy/example-psp.yaml" >}} +<!-- And create it with kubectl: --> 使用 kubectl 执行创建操作： ```shell kubectl-admin create -f example-psp.yaml ``` -## 获取 Pod 安全策略列表 - -获取已存在策略列表，使用 `kubectl get`： +<!-- +Now, as the unprivileged user, try to create a simple pod: +--> +现在，作为一个非特权用户，尝试创建一个简单的 Pod： ```shell -$ kubectl get psp -NAME PRIV CAPS SELINUX RUNASUSER FSGROUP SUPGROUP READONLYROOTFS VOLUMES -permissive false [] RunAsAny RunAsAny RunAsAny RunAsAny false [*] -privileged true [] RunAsAny RunAsAny RunAsAny RunAsAny false [*] -restricted false [] RunAsAny MustRunAsNonRoot RunAsAny RunAsAny false [emptyDir secret downwardAPI configMap persistentVolumeClaim projected] +kubectl-user create -f- <<EOF +apiVersion: v1 +kind: Pod +metadata: + name: pause +spec: + containers: + - name: pause + image: k8s.gcr.io/pause +EOF +Error from server (Forbidden): error when creating "STDIN": pods "pause" is forbidden: unable to validate against any pod security policy: [] ``` - - -## 修改 Pod 安全策略 - -通过交互方式修改策略，使用 `kubectl edit`： +<!-- +**What happened?** Although the PodSecurityPolicy was created, neither the +pod's service account nor `fake-user` have permission to use the new policy: +--> +**发生了什么？** 尽管 PodSecurityPolicy 被创建，Pod 的服务账号或者 +`fake-user` 用户都没有使用该策略的权限。 ```shell -$ kubectl edit psp permissive +kubectl-user auth can-i use podsecuritypolicy/example ``` +``` +no +``` +<!-- +Create the rolebinding to grant `fake-user` the `use` verb on the example +policy: +--> +创建角色绑定，赋予 `fake-user` 使用 `use` 访问示例策略的权限： - -该命令将打开一个默认文本编辑器，在这里能够修改策略。 - - - -## 删除 Pod 安全策略 - -一旦不再需要一个策略，很容易通过 `kubectl` 删除它： +<!-- +This is not the recommended way! See the [next section](#run-another-pod) +for the preferred approach. +--> +{{< note >}} +不建议使用这种方法！ +欲了解优先考虑的方法，请参见[下节](#run-another-pod)。 +{{< /note >}} ```shell -$ kubectl delete psp permissive -podsecuritypolicy "permissive" deleted +kubectl-admin create role psp:unprivileged \ + --verb=use \ + --resource=podsecuritypolicy \ + --resource-name=example ``` +输出： + +``` +role "psp:unprivileged" created +``` + +```shell +kubectl-admin create rolebinding fake-user:psp:unprivileged \ + --role=psp:unprivileged \ + --serviceaccount=psp-example:fake-user +``` + +输出： + +``` +rolebinding "fake-user:psp:unprivileged" created +``` + +```shell +kubectl-user auth can-i use podsecuritypolicy/example +``` + +输出： + +``` +yes +``` + +<!-- +Now retry creating the pod: +--> +现在重试创建 Pod： + +```shell +kubectl-user create -f- <<EOF +apiVersion: v1 +kind: Pod +metadata: + name: pause +spec: + containers: + - name: pause + image: k8s.gcr.io/pause +EOF +``` + +输出： + +``` +pod "pause" created +``` + +<!-- +It works as expected! But any attempts to create a privileged pod should still +be denied: +--> +此次尝试不出所料地成功了！ +不过任何创建特权 Pod 的尝试还是会被拒绝： + +```shell +kubectl-user create -f- <<EOF +apiVersion: v1 +kind: Pod +metadata: + name: privileged +spec: + containers: + - name: pause + image: k8s.gcr.io/pause + securityContext: + privileged: true +EOF +``` + +输出为： + +``` +Error from server (Forbidden): error when creating "STDIN": pods "privileged" is forbidden: unable to validate against any pod security policy: [spec.containers[0].securityContext.privileged: Invalid value: true: Privileged containers are not allowed] +``` + +<!-- +Delete the pod before moving on: +--> +继续此例之前先删除该 Pod： + +```shell +kubectl-user delete pod pause +``` + +<!-- +### Run another pod + +Let's try that again, slightly differently: +--> +### 运行另一个 Pod {#run-another-pod} + +我们再试一次，稍微有些不同： + +```shell +kubectl-user create deployment pause --image=k8s.gcr.io/pause +``` + +输出为： + +``` +deployment "pause" created +``` + +```shell +kubectl-user get pods +``` + +输出为： + +``` +No resources found. +``` + +```shell +kubectl-user get events | head -n 2 +``` + +输出为： +``` +LASTSEEN FIRSTSEEN COUNT NAME KIND SUBOBJECT TYPE REASON SOURCE MESSAGE +1m 2m 15 pause-7774d79b5 ReplicaSet Warning FailedCreate replicaset-controller Error creating: pods "pause-7774d79b5-" is forbidden: no providers available to validate pod request +``` + +<!-- +**What happened?** We already bound the `psp:unprivileged` role for our `fake-user`, +why are we getting the error `Error creating: pods "pause-7774d79b5-" is +forbidden: no providers available to validate pod request`? The answer lies in +the source - `replicaset-controller`. Fake-user successfully created the +deployment (which successfully created a replicaset), but when the replicaset +went to create the pod it was not authorized to use the example +podsecuritypolicy. +--> +**发生了什么？** 我们已经为用户 `fake-user` 绑定了 `psp:unprivileged` 角色， +为什么还会收到错误 `Error creating: pods "pause-7774d79b5-" is +forbidden: no providers available to validate pod request +（创建错误：pods "pause-7774d79b5" 被禁止：没有可用来验证 pod 请求的驱动）`？ +答案在于源文件 - `replicaset-controller`。 +`fake-user` 用户成功地创建了 Deployment，而后者也成功地创建了 ReplicaSet， +不过当 ReplicaSet 创建 Pod 时，发现未被授权使用示例 PodSecurityPolicy 资源。 + +<!-- +In order to fix this, bind the `psp:unprivileged` role to the pod's service +account instead. In this case (since we didn't specify it) the service account +is `default`: +--> +为了修复这一问题，将 `psp:unprivileged` 角色绑定到 Pod 的服务账号。 +在这里，因为我们没有给出服务账号名称，默认的服务账号是 `default`。 + +```shell +kubectl-admin create rolebinding default:psp:unprivileged \ + --role=psp:unprivileged \ + --serviceaccount=psp-example:default +``` + +输出为： + +``` +rolebinding "default:psp:unprivileged" created +``` + +<!-- +Now if you give it a minute to retry, the replicaset-controller should +eventually succeed in creating the pod: +--> +现在如果你给 ReplicaSet 控制器一分钟的时间来重试，该控制器最终将能够 +成功地创建 Pod： + +```shell +kubectl-user get pods --watch +``` + +输出类似于： + +``` +NAME READY STATUS RESTARTS AGE +pause-7774d79b5-qrgcb 0/1 Pending 0 1s +pause-7774d79b5-qrgcb 0/1 Pending 0 1s +pause-7774d79b5-qrgcb 0/1 ContainerCreating 0 1s +pause-7774d79b5-qrgcb 1/1 Running 0 2s +``` + +<!-- +### Clean up + +Delete the namespace to clean up most of the example resources: +--> +### 清理 {#clean-up} + +删除名字空间即可清理大部分示例资源： + +```shell +kubectl-admin delete ns psp-example +``` + +输出类似于： + +``` +namespace "psp-example" deleted +``` + +<!-- +Note that `PodSecurityPolicy` resources are not namespaced, and must be cleaned +up separately: +--> +注意 `PodSecurityPolicy` 资源不是名字空间域的资源，必须单独清理： + +```shell +kubectl-admin delete psp example +``` + +输出类似于： +``` +podsecuritypolicy "example" deleted +``` + +<!-- +### Example Policies + +This is the least restrictive policy you can create, equivalent to not using the +pod security policy admission controller: +--> +### 示例策略 {#example-policies} + +下面是一个你可以创建的约束性非常弱的策略，其效果等价于没有使用 Pod 安全 +策略准入控制器： + +{{< codenew file="policy/privileged-psp.yaml" >}} + +<!-- +This is an example of a restrictive policy that requires users to run as an +unprivileged user, blocks possible escalations to root, and requires use of +several security mechanisms. +--> +下面是一个具有约束性的策略，要求用户以非特权账号运行，禁止可能的向 root 权限 +的升级，同时要求使用若干安全机制。 + +{{< codenew file="policy/restricted-psp.yaml" >}} + +<!-- +See [Pod Security Standards](/docs/concepts/security/pod-security-standards/#policy-instantiation) for more examples. +--> +更多的示例可参考 +[Pod 安全标准](/zh/docs/concepts/security/pod-security-standards/#policy-instantiation)。 + +<!-- +## Policy Reference + +### Privileged + +**Privileged** - determines if any container in a pod can enable privileged mode. +By default a container is not allowed to access any devices on the host, but a +"privileged" container is given access to all devices on the host. This allows +the container nearly all the same access as processes running on the host. +This is useful for containers that want to use linux capabilities like +manipulating the network stack and accessing devices. +--> +## 策略参考 {#policy-reference} + +### Privileged + +**Privileged** - 决定是否 Pod 中的某容器可以启用特权模式。 +默认情况下，容器是不可以访问宿主上的任何设备的，不过一个“privileged（特权的）” +容器则被授权访问宿主上所有设备。 +这种容器几乎享有宿主上运行的进程的所有访问权限。 +对于需要使用 Linux 权能字（如操控网络堆栈和访问设备）的容器而言是有用的。 + +<!-- +### Host namespaces + +**HostPID** - Controls whether the pod containers can share the host process ID +namespace. Note that when paired with ptrace this can be used to escalate +privileges outside of the container (ptrace is forbidden by default). + +**HostIPC** - Controls whether the pod containers can share the host IPC +namespace. + +**HostNetwork** - Controls whether the pod may use the node network +namespace. Doing so gives the pod access to the loopback device, services +listening on localhost, and could be used to snoop on network activity of other +pods on the same node. + +**HostPorts** - Provides a list of ranges of allowable ports in the host +network namespace. Defined as a list of `HostPortRange`, with `min`(inclusive) +and `max`(inclusive). Defaults to no allowed host ports. +--> +### 宿主名字空间 {#host-namespaces} + +**HostPID** - 控制 Pod 中容器是否可以共享宿主上的进程 ID 空间。 +注意，如果与 `ptrace` 相结合，这种授权可能被利用，导致向容器外的特权逃逸 +（默认情况下 `ptrace` 是被禁止的）。 + +**HostIPC** - 控制 Pod 容器是否可共享宿主上的 IPC 名字空间。 + +**HostNetwork** - 控制是否 Pod 可以使用节点的网络名字空间。 +此类授权将允许 Pod 访问本地回路（loopback）设备、在本地主机（localhost） +上监听的服务、还可能用来监听同一节点上其他 Pod 的网络活动。 + +**HostPorts** -提供可以在宿主网络名字空间中可使用的端口范围列表。 +该属性定义为一组 `HostPortRange` 对象的列表，每个对象中包含 +`min`（含）与 `max`（含）值的设置。 +默认不允许访问宿主端口。 + +<!-- +### Volumes and file systems + +**Volumes** - Provides a list of allowed volume types. The allowable values +correspond to the volume sources that are defined when creating a volume. For +the complete list of volume types, see [Types of +Volumes](/docs/concepts/storage/volumes/#types-of-volumes). Additionally, `*` +may be used to allow all volume types. + +The **recommended minimum set** of allowed volumes for new PSPs are: +--> +### 卷和文件系统 {#volumes-and-file-systems} + +**Volumes** - 提供一组被允许的卷类型列表。可被允许的值对应于创建卷时可以 +设置的卷来源。卷类型的完整列表可参见 +[卷类型](/zh/docs/concepts/storage/volumes/#types-of-volumes)。 +此外， `*` 可以用来允许所有卷类型。 + +对于新的 Pod 安全策略设置而言，建议设置的卷类型的*最小列表*包含： + +- configMap +- downwardAPI +- emptyDir +- persistentVolumeClaim +- secret +- projected + +<!-- +PodSecurityPolicy does not limit the types of `PersistentVolume` objects that +may be referenced by a `PersistentVolumeClaim`, and hostPath type +`PersistentVolumes` do not support read-only access mode. Only trusted users +should be granted permission to create `PersistentVolume` objects. +--> +{{< warning >}} +PodSecurityPolicy 并不限制可以被 `PersistentVolumeClaim` 所引用的 +`PersistentVolume` 对象的类型。 +此外 `hostPath` 类型的 `PersistentVolume` 不支持只读访问模式。 +应该仅赋予受信用户创建 `PersistentVolume` 对象的访问权限。 +{{< /warning >}} + +<!-- +**FSGroup** - Controls the supplemental group applied to some volumes. + +- *MustRunAs* - Requires at least one `range` to be specified. Uses the +minimum value of the first range as the default. Validates against all ranges. +- *MayRunAs* - Requires at least one `range` to be specified. Allows +`FSGroups` to be left unset without providing a default. Validates against +all ranges if `FSGroups` is set. +- *RunAsAny* - No default provided. Allows any `fsGroup` ID to be specified. +--> +**FSGroup** - 控制应用到某些卷上的附加用户组。 + + - *MustRunAs* - 要求至少指定一个 `range`。 + 使用范围中的最小值作为默认值。所有 range 值都会被用来执行验证。 + - *MayRunAs* - 要求至少指定一个 `range`。 + 允许不设置 `FSGroups`，且无默认值。 + 如果 `FSGroup` 被设置，则所有 range 值都会被用来执行验证检查。 + - *RunAsAny* - 不提供默认值。允许设置任意 `fsGroup` ID 值。 + +<!-- +**AllowedHostPaths** - This specifies a list of host paths that are allowed +to be used by hostPath volumes. An empty list means there is no restriction on +host paths used. This is defined as a list of objects with a single `pathPrefix` +field, which allows hostPath volumes to mount a path that begins with an +allowed prefix, and a `readOnly` field indicating it must be mounted read-only. +For example: +--> +**AllowedHostPaths** - 设置一组宿主文件目录，这些目录项可以在 `hostPath` 卷中 +使用。列表为空意味着对所使用的宿主目录没有限制。 +此选项定义包含一个对象列表，表中对象包含 `pathPrefix` 字段，用来表示允许 +`hostPath` 卷挂载以所指定前缀开头的路径。 +对象中还包含一个 `readOnly` 字段，用来表示对应的卷必须以只读方式挂载。 +例如： + +<!-- +```yaml +allowedHostPaths: + # This allows "/foo", "/foo/", "/foo/bar" etc., but + # disallows "/fool", "/etc/foo" etc. + # "/foo/../" is never valid. + - pathPrefix: "/foo" + readOnly: true # only allow read-only mounts +``` +--> +```yaml +allowedHostPaths: + # 下面的设置允许 "/foo"、"/foo/"、"/foo/bar" 等路径，但禁止 + # "/fool"、"/etc/foo" 这些路径。 + # "/foo/../" 总会被当作非法路径。 + - pathPrefix: "/foo" + readOnly: true # 仅允许只读模式挂载 +``` + +<!-- +There are many ways a container with unrestricted access to the host +filesystem can escalate privileges, including reading data from other +containers, and abusing the credentials of system services, such as Kubelet. + +Writeable hostPath directory volumes allow containers to write +to the filesystem in ways that let them traverse the host filesystem outside the `pathPrefix`. +`readOnly: true`, available in Kubernetes 1.11+, must be used on **all** `allowedHostPaths` +to effectively limit access to the specified `pathPrefix`. +--> + +{{< warning >}} +容器如果对宿主文件系统拥有不受限制的访问权限，就可以有很多种方式提升自己的特权， +包括读取其他容器中的数据、滥用系统服务（如 `kubelet`）`的凭据信息等。 + +由可写入的目录所构造的 `hostPath` 卷能够允许容器写入数据到宿主文件系统， +并且在写入时避开 `pathPrefix` 所设置的目录限制。 +`readOnly: true` 这一设置在 Kubernetes 1.11 版本之后可用。 +必须针对 `allowedHostPaths` 中的 *所有* 条目设置此属性才能有效地限制容器 +只能访问 `pathPrefix` 所指定的目录。 +{{< /warning >}} + +**ReadOnlyRootFilesystem** - 要求容器必须以只读方式挂载根文件系统来运行 +（即不允许存在可写入层）。 + +<!-- +### FlexVolume drivers + +This specifies a list of FlexVolume drivers that are allowed to be used +by flexvolume. An empty list or nil means there is no restriction on the drivers. +Please make sure [`volumes`](#volumes-and-file-systems) field contains the +`flexVolume` volume type; no FlexVolume driver is allowed otherwise. + +For example: +--> +### FlexVolume 驱动 {#flexvolume-drivers} + +此配置指定一个可以被 FlexVolume 卷使用的驱动程序的列表。 +空的列表或者 nil 值意味着对驱动没有任何限制。 +请确保[`volumes`](#volumes-and-file-systems) 字段包含了 `flexVolume` 卷类型， +否则所有 FlexVolume 驱动都被禁止。 + +<!-- +```yaml +apiVersion: policy/v1beta1 +kind: PodSecurityPolicy +metadata: + name: allow-flex-volumes +spec: + # ... other spec fields + volumes: + - flexVolume + allowedFlexVolumes: + - driver: example/lvm + - driver: example/cifs +``` +--> + +```yaml +apiVersion: policy/v1beta1 +kind: PodSecurityPolicy +metadata: + name: allow-flex-volumes +spec: + # spec d的其他字段 + volumes: + - flexVolume + allowedFlexVolumes: + - driver: example/lvm + - driver: example/cifs +``` + +<!-- +### Users and groups + +**RunAsUser** - Controls which user ID the containers are run with. + +- *MustRunAs* - Requires at least one `range` to be specified. Uses the +minimum value of the first range as the default. Validates against all ranges. +- *MustRunAsNonRoot* - Requires that the pod be submitted with a non-zero +`runAsUser` or have the `USER` directive defined (using a numeric UID) in the +image. Pods which have specified neither `runAsNonRoot` nor `runAsUser` settings +will be mutated to set `runAsNonRoot=true`, thus requiring a defined non-zero +numeric `USER` directive in the container. No default provided. Setting +`allowPrivilegeEscalation=false` is strongly recommended with this strategy. +- *RunAsAny* - No default provided. Allows any `runAsUser` to be specified. +--> +### 用户和组 {#users-and-groups} + +**RunAsUser** - 控制使用哪个用户 ID 来运行容器。 + + - *MustRunAs* - 必须配置一个 `range`。使用该范围内的第一个值作为默认值。 + 所有 range 值都被用于验证检查。 +- *MustRunAsNonRoot* - 要求提交的 Pod 具有非零 `runAsUser` 值，或在镜像中 + （使用 UID 数值）定义了 `USER` 环境变量。 + 如果 Pod 既没有设置 `runAsNonRoot`，也没有设置 `runAsUser`，则该 Pod 会被 + 修改以设置 `runAsNonRoot=true`，从而要求容器通过 `USER` 指令给出非零的数值形式 + 的用户 ID。此配置没有默认值。采用此配置时，强烈建议设置 + `allowPrivilegeEscalation=false`。 +- *RunAsAny* - 没有提供默认值。允许指定任何 `runAsUser` 配置。 + +<!-- +**RunAsGroup** - Controls which primary group ID the containers are run with. + + - *MustRunAs* - Requires at least one `range` to be specified. Uses the + minimum value of the first range as the default. + Validates against all ranges. + - *MayRunAs* - Does not require that RunAsGroup be specified. However, when RunAsGroup +is specified, they have to fall in the defined range. + - *RunAsAny* - No default provided. Allows any `runAsGroup` to be specified. +--> +**RunAsGroup** - 控制运行容器时使用的主用户组 ID。 + + - *MustRunAs* - 要求至少指定一个 `range` 值。第一个 range + 中的最小值作为默认值。所有 range 值都被用来执行验证检查。 + - *MayRunAs* - 不要求设置 `RunAsGroup`。 + 不过，如果指定了 `RunAsGroup` 被设置，所设置值必须处于所定义的范围内。 + - *RunAsAny* - 未指定默认值。允许 `runAsGroup` 设置任何值。 + +<!-- +**SupplementalGroups** - Controls which group IDs containers add. + + - *MustRunAs* - Requires at least one `range` to be specified. Uses the +minimum value of the first range as the default. Validates against all ranges. + - *MayRunAs* - Requires at least one `range` to be specified. Allows +`supplementalGroups` to be left unset without providing a default. +Validates against all ranges if `supplementalGroups` is set. + - *RunAsAny* - No default provided. Allows any `supplementalGroups` to be +specified. +--> +**SupplementalGroups** - 控制容器可以添加的组 ID。 + + - *MustRunAs* - 要求至少指定一个 `range` 值。 + 第一个 range 中的最小值用作默认值。 + 所有 range 值都被用来执行验证检查。 + - *MayRunAs* - 要求至少指定一个 `range` 值。 + 允许不指定 `supplementalGroups` 且不设置默认值。 + 如果 `supplementalGroups` 被设置，则所有 range 值都被用来执行验证检查。 + - *RunAsAny* - 未指定默认值。允许为 `supplementalGroups` 设置任何值。 + +<!-- +### Privilege Escalation + +These options control the `allowPrivilegeEscalation` container option. This bool +directly controls whether the +[`no_new_privs`](https://www.kernel.org/doc/Documentation/prctl/no_new_privs.txt) +flag gets set on the container process. This flag will prevent `setuid` binaries +from changing the effective user ID, and prevent files from enabling extra +capabilities (e.g. it will prevent the use of the `ping` tool). This behavior is +required to effectively enforce `MustRunAsNonRoot`. +--> +### 特权提升 {#privilege-escalation} + +这一组选项控制容器的`allowPrivilegeEscalation` 属性。该属性直接决定是否为 +容器进程设置 +[`no_new_privs`](https://www.kernel.org/doc/Documentation/prctl/no_new_privs.txt) +参数。此参数会禁止 `setuid` 属性的可执行文件更改有效用户 ID（EUID），并且 +禁止启用额外权能的文件。例如，`no_new_privs` 会禁止使用 `ping` 工具。 +如果想有效地实施 `MustRunAsNonRoot` 控制，需要配置这一选项。 + +<!-- +**AllowPrivilegeEscalation** - Gates whether or not a user is allowed to set the +security context of a container to `allowPrivilegeEscalation=true`. This +defaults to allowed so as to not break setuid binaries. Setting it to `false` +ensures that no child process of a container can gain more privileges than its parent. +--> +**AllowPrivilegeEscalation** - 决定是否用户可以将容器的安全上下文设置为 +`allowPrivilegeEscalation=true`。默认设置下，这样做是允许的，目的是避免 +造成现有的 `setuid` 应用无法运行。将此选项设置为 `false` 可以确保容器的所有 +子进程都无法获得比父进程更多的特权。 + +<!-- +**DefaultAllowPrivilegeEscalation** - Sets the default for the +`allowPrivilegeEscalation` option. The default behavior without this is to allow +privilege escalation so as to not break setuid binaries. If that behavior is not +desired, this field can be used to default to disallow, while still permitting +pods to request `allowPrivilegeEscalation` explicitly. +--> +**DefaultAllowPrivilegeEscalation** - 为 `allowPrivilegeEscalation` 选项设置 +默认值。不设置此选项时的默认行为是允许特权提升，以便运行 setuid 程序。 +如果不希望运行 setuid 程序，可以使用此字段将选项的默认值设置为禁止，同时 +仍然允许 Pod 显式地请求 `allowPrivilegeEscalation`。 + +<!-- +### Capabilities + +Linux capabilities provide a finer grained breakdown of the privileges +traditionally associated with the superuser. Some of these capabilities can be +used to escalate privileges or for container breakout, and may be restricted by +the PodSecurityPolicy. For more details on Linux capabilities, see +[capabilities(7)](http://man7.org/linux/man-pages/man7/capabilities.7.html). + +The following fields take a list of capabilities, specified as the capability +name in ALL_CAPS without the `CAP\_` prefix. +--> +### 权能字 {#capabilities} + +Linux 权能字（Capabilities）将传统上与超级用户相关联的特权作了细粒度的分解。 +其中某些权能字可以用来提升特权，打破容器边界，可以通过 PodSecurityPolicy +来限制。关于 Linux 权能字的更多细节，可参阅 +[capabilities(7)](http://man7.org/linux/man-pages/man7/capabilities.7.html)。 + +下列字段都可以配置为权能字的列表。表中的每一项都是 `ALL_CAPS` 中的一个权能字 +名称，只是需要去掉 `CAP_` 前缀。 + +<!-- +**AllowedCapabilities** - Provides a list of capabilities that are allowed to be added +to a container. The default set of capabilities are implicitly allowed. The +empty set means that no additional capabilities may be added beyond the default +set. `*` can be used to allow all capabilities. +--> +**AllowedCapabilities** - 给出可以被添加到容器的权能字列表。 +默认的权能字集合是被隐式允许的那些。空集合意味着只能使用默认权能字集合， +不允许添加额外的权能字。`*` 可以用来设置允许所有权能字。 + +<!-- +**RequiredDropCapabilities** - The capabilities which must be dropped from +containers. These capabilities are removed from the default set, and must not be +added. Capabilities listed in `RequiredDropCapabilities` must not be included in +`AllowedCapabilities` or `DefaultAddCapabilities`. +--> +**RequiredDropCapabilities** - 必须从容器中去除的权能字。 +所给的权能字会从默认权能字集合中去除，并且一定不可以添加。 +`RequiredDropCapabilities` 中列举的权能字不能出现在 +`AllowedCapabilities` 或 `DefaultAddCapabilities` 所给的列表中。 + +<!-- +**DefaultAddCapabilities** - The capabilities which are added to containers by +default, in addition to the runtime defaults. See the [Docker +documentation](https://docs.docker.com/engine/reference/run/#runtime-privilege-and-linux-capabilities) +for the default list of capabilities when using the Docker runtime. +--> +**DefaultAddCapabilities** - 默认添加到容器的权能字集合。 +这一集合是作为容器运行时所设值的补充。 +关于使用 Docker 容器运行引擎时默认的权能字列表，可参阅 +[Docker 文档](https://docs.docker.com/engine/reference/run/#runtime-privilege-and-linux-capabilities)。 + +<!-- +### SELinux + +- *MustRunAs* - Requires `seLinuxOptions` to be configured. Uses +`seLinuxOptions` as the default. Validates against `seLinuxOptions`. +- *RunAsAny* - No default provided. Allows any `seLinuxOptions` to be +specified. +--> +### SELinux + +- *MustRunAs* - 要求必须配置 `seLinuxOptions`。默认使用 `seLinuxOptions`。 + 针对 `seLinuxOptions` 所给值执行验证检查。 +- *RunAsAny* - 没有提供默认值。允许任意指定的 `seLinuxOptions` 选项。 + +<!-- +### AllowedProcMountTypes + +`allowedProcMountTypes` is a list of allowed ProcMountTypes. +Empty or nil indicates that only the `DefaultProcMountType` may be used. + +`DefaultProcMount` uses the container runtime defaults for readonly and masked +paths for /proc. Most container runtimes mask certain paths in /proc to avoid +accidental security exposure of special devices or information. This is denoted +as the string `Default`. + +The only other ProcMountType is `UnmaskedProcMount`, which bypasses the +default masking behavior of the container runtime and ensures the newly +created /proc the container stays intact with no modifications. This is +denoted as the string `Unmasked`. +--> +### AllowedProcMountTypes + +`allowedProcMountTypes` 是一组可以允许的 proc 挂载类型列表。 +空表或者 nil 值表示只能使用 `DefaultProcMountType`。 + +`DefaultProcMount` 使用容器运行时的默认值设置来决定 `/proc` 的只读挂载模式 +和路径屏蔽。大多数容器运行时都会屏蔽 `/proc` 下面的某些路径以避免特殊设备或 +信息被不小心暴露给容器。这一配置使所有 `Default` 字符串值来表示。 + +此外唯一的ProcMountType 是 `UnmaskedProcMount`，意味着即将绕过容器运行时的 +路径屏蔽行为，确保新创建的 `/proc` 不会被容器修改。此配置用字符串 +`Unmasked` 来表示。 + +<!-- +### AppArmor + +Controlled via annotations on the PodSecurityPolicy. Refer to the [AppArmor +documentation](/docs/tutorials/clusters/apparmor/#podsecuritypolicy-annotations). +--> +### AppArmor + +通过 PodSecurityPolicy 上的注解来控制。 +详情请参阅 +[AppArmor 文档](/zh/docs/tutorials/clusters/apparmor/#podsecuritypolicy-annotations)。 -## 启用 Pod 安全策略 +<!-- +### Seccomp -为了能够在集群中使用 Pod 安全策略，必须确保满足如下条件： +The use of seccomp profiles in pods can be controlled via annotations on the +PodSecurityPolicy. Seccomp is an alpha feature in Kubernetes. +**seccomp.security.alpha.kubernetes.io/defaultProfileName** - Annotation that +specifies the default seccomp profile to apply to containers. Possible values +are: +--> +### Seccomp +Pod 对 seccomp 模版的使用可以通过在 PodSecurityPolicy 上设置注解来控制。 +Seccomp 是 Kubernetes 的一项 alpha 阶段特性。 -1. 已经启用 API 类型 `extensions/v1beta1/podsecuritypolicy`（仅对 1.6 之前的版本） -1. 已经启用许可控制器 `PodSecurityPolicy` -1. 已经定义了自己的策略 +**seccomp.security.alpha.kubernetes.io/defaultProfileName** - 注解用来 +指定为容器配置默认的 seccomp 模版。可选值为： +<!-- +- `unconfined` - Seccomp is not applied to the container processes (this is the + default in Kubernetes), if no alternative is provided. +- `runtime/default` - The default container runtime profile is used. +- `docker/default` - The Docker default seccomp profile is used. Deprecated as of + Kubernetes 1.11. Use `runtime/default` instead. +- `localhost/<path>` - Specify a profile as a file on the node located at + `<seccomp_root>/<path>`, where `<seccomp_root>` is defined via the + `-seccomp-profile-root` flag on the Kubelet. +--> +- `unconfined` - 如果没有指定其他替代方案，Seccomp 不会被应用到容器进程上 + （Kubernets 中的默认设置）。 +- `runtime/default` - 使用默认的容器运行时模版。 +- `docker/default` - 使用 Docker 的默认 seccomp 模版。自 1.11 版本废弃。 + 应改为使用 `runtime/default`。 +- `localhost/<路径名>` - 指定节点上路径 `<seccomp_root>/<路径名>` 下的一个 + 文件作为其模版。其中 `<seccomp_root>` 是通过 `kubelet` 的标志 + `--seccomp-profile-root` 来指定的。 +<!-- +**seccomp.security.alpha.kubernetes.io/allowedProfileNames** - Annotation that +specifies which values are allowed for the pod seccomp annotations. Specified as +a comma-delimited list of allowed values. Possible values are those listed +above, plus `*` to allow all profiles. Absence of this annotation means that the +default cannot be changed. +--> +**seccomp.security.alpha.kubernetes.io/allowedProfileNames** - 指定可以为 +Pod seccomp 注解配置的值的注解。取值为一个可用值的列表。 +表中每项可以是上述各值之一，还可以是 `*`，用来表示允许所有的模版。 +如果没有设置此注解，意味着默认的 seccomp 模版是不可更改的。 -## 使用 RBAC +<!-- +### Sysctl -在 Kubernetes 1.5 或更新版本，可以使用 PodSecurityPolicy 来控制，对基于用户角色和组的已授权容器的访问。访问不同的 PodSecurityPolicy 对象，可以基于认证来控制。基于 Deployment、ReplicaSet 等创建的 Pod，限制访问 PodSecurityPolicy 对象，[Controller Manager](/docs/admin/kube-controller-manager/) 必须基于安全 API 端口运行，并且不能够具有超级用户权限。 +By default, all safe sysctls are allowed. +--> +### Sysctl + +默认情况下，所有的安全的 sysctl 都是被允许的。 + +<!-- +- `forbiddenSysctls` - excludes specific sysctls. You can forbid a combination of safe and unsafe sysctls in the list. To forbid setting any sysctls, use `*` on its own. +- `allowedUnsafeSysctls` - allows specific sysctls that had been disallowed by the default list, so long as these are not listed in `forbiddenSysctls`. +--> +- `forbiddenSysctls` - 用来排除某些特定的 sysctl。 + 你可以在此列表中禁止一些安全的或者不安全的 sysctl。 + 此选项设置为 `*` 意味着禁止设置所有 sysctl。 +- `allowedUnsafeSysctls` - 用来启用那些被默认列表所禁用的 sysctl， + 前提是所启用的 sysctl 没有被列在 `forbiddenSysctls` 中。 + +参阅 [Sysctl 文档](/zh/docs/tasks/administer-cluster/sysctl-cluster/#podsecuritypolicy)。 + +## {{% heading "whatsnext" %}} + +<!-- +- See [Pod Security Standards](/docs/concepts/security/pod-security-standards/) for policy recommendations. + +- Refer to [Pod Security Policy Reference](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podsecuritypolicy-v1beta1-policy) for the api details. +--> +- 参阅[Pod 安全标准](/zh/docs/concepts/security/pod-security-standards/) + 了解策略建议。 +- 阅读 [Pod 安全策略参考](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podsecuritypolicy-v1beta1-policy)了解 API 细节。 -PodSecurityPolicy 认证使用所有可用的策略，包括创建 Pod 的用户，Pod 上指定的服务账户（Service Account）。当 Pod 基于 Deployment、ReplicaSet 创建时，它是创建 Pod 的 Controller Manager，所以如果基于非安全 API 端口运行，允许所有的 PodSecurityPolicy 对象，并且不能够有效地实现细分权限。用户访问给定的 PSP 策略有效，仅当是直接部署 Pod 的情况。更多详情，查看 [PodSecurityPolicy RBAC 示例](https://git.k8s.io/kubernetes/examples/podsecuritypolicy/rbac/README.md)，当直接部署 Pod 时，应用 PodSecurityPolicy 控制基于角色和组的已授权容器的访问 。 diff --git a/content/zh/docs/concepts/policy/resource-quotas.md b/content/zh/docs/concepts/policy/resource-quotas.md index 25e92ac78d..73234a7cf3 100644 --- a/content/zh/docs/concepts/policy/resource-quotas.md +++ b/content/zh/docs/concepts/policy/resource-quotas.md @@ -1,19 +1,15 @@ --- -approvers: -- derekwaynecarr title: 资源配额 content_type: concept weight: 10 --- <!-- ---- reviewers: - derekwaynecarr title: Resource Quotas content_type: concept weight: 10 ---- --> <!-- overview --> @@ -21,17 +17,13 @@ weight: 10 <!-- When several users or teams share a cluster with a fixed number of nodes, there is a concern that one team could use more than its fair share of resources. + +Resource quotas are a tool for administrators to address this concern. --> 当多个用户或团队共享具有固定节点数目的集群时，人们会担心有人使用超过其基于公平原则所分配到的资源量。 -<!-- -Resource quotas are a tool for administrators to address this concern. ---> 资源配额是帮助管理员解决这一问题的工具。 - - - <!-- body --> <!-- @@ -40,7 +32,8 @@ aggregate resource consumption per namespace. It can limit the quantity of obje be created in a namespace by type, as well as the total amount of compute resources that may be consumed by resources in that project. --> -资源配额，通过 `ResourceQuota` 对象来定义，对每个命名空间的资源消耗总量提供限制。它可以限制命名空间中某种类型的对象的总数目上限，也可以限制命令空间中的 Pod 可以使用的计算资源的总上限。 +资源配额，通过 `ResourceQuota` 对象来定义，对每个命名空间的资源消耗总量提供限制。 +它可以限制命名空间中某种类型的对象的总数目上限，也可以限制命令空间中的 Pod 可以使用的计算资源的总上限。 <!-- Resource quotas work like this: @@ -60,13 +53,26 @@ Resource quotas work like this: the `LimitRanger` admission controller to force defaults for pods that make no compute resource requirements. See the [walkthrough](/docs/tasks/administer-cluster/quota-memory-cpu-namespace/) for an example of how to avoid this problem. --> -- 不同的团队可以在不同的命名空间下工作，目前这是非约束性的，在未来的版本中可能会通过 ACL (Access Control List 访问控制列表) 来实现强制性约束。 +- 不同的团队可以在不同的命名空间下工作，目前这是非约束性的，在未来的版本中可能会通过 + ACL (Access Control List 访问控制列表) 来实现强制性约束。 - 集群管理员可以为每个命名空间创建一个或多个资源配额对象。 -- 当用户在命名空间下创建资源（如 Pod、Service 等）时，Kubernetes 的配额系统会跟踪集群的资源使用情况，以确保使用的资源用量不超过资源配额中定义的硬性资源限额。 -- 如果资源创建或者更新请求违反了配额约束，那么该请求会报错（HTTP 403 FORBIDDEN），并在消息中给出有可能违反的约束。 -- 如果命名空间下的计算资源 （如 `cpu` 和 `memory`）的配额被启用，则用户必须为这些资源设定请求值（request）和约束值（limit），否则配额系统将拒绝 Pod 的创建。 +- 当用户在命名空间下创建资源（如 Pod、Service 等）时，Kubernetes 的配额系统会 + 跟踪集群的资源使用情况，以确保使用的资源用量不超过资源配额中定义的硬性资源限额。 +- 如果资源创建或者更新请求违反了配额约束，那么该请求会报错（HTTP 403 FORBIDDEN）， + 并在消息中给出有可能违反的约束。 +- 如果命名空间下的计算资源 （如 `cpu` 和 `memory`）的配额被启用，则用户必须为 + 这些资源设定请求值（request）和约束值（limit），否则配额系统将拒绝 Pod 的创建。 提示: 可使用 `LimitRanger` 准入控制器来为没有设置计算资源需求的 Pod 设置默认值。 - 若想避免这类问题，请参考[演练](/docs/tasks/administer-cluster/quota-memory-cpu-namespace/)中的示例。 + + 若想避免这类问题，请参考 + [演练](/zh/docs/tasks/administer-cluster/manage-resources/quota-memory-cpu-namespace/)示例。 + +<!-- +The name of a `ResourceQuota` object must be a valid +[DNS subdomain name](/docs/concepts/overview/working-with-objects/names#dns-subdomain-names). +--> +ResourceQuota 对象的名称必须时合法的 +[DNS 子域名](/zh/docs/concepts/overview/working-with-objects/names#dns-subdomain-names)。 <!-- Examples of policies that could be created using namespaces and quotas are: @@ -79,31 +85,31 @@ Examples of policies that could be created using namespaces and quotas are: - Limit the "testing" namespace to using 1 core and 1GiB RAM. Let the "production" namespace use any amount. --> -- 在具有 32 GiB 内存和 16 核 CPU 资源的集群中，允许 A 团队使用 20 GiB 内存 和 10 核的 CPU 资源，允许 B 团队使用 10 GiB 内存和 4 核的 CPU 资源，并且预留 2 GiB 内存和 2 核的 CPU 资源供将来分配。 +- 在具有 32 GiB 内存和 16 核 CPU 资源的集群中，允许 A 团队使用 20 GiB 内存 和 10 核的 CPU 资源， + 允许 B 团队使用 10 GiB 内存和 4 核的 CPU 资源，并且预留 2 GiB 内存和 2 核的 CPU 资源供将来分配。 - 限制 "testing" 命名空间使用 1 核 CPU 资源和 1GiB 内存。允许 "production" 命名空间使用任意数量。 <!-- In the case where the total capacity of the cluster is less than the sum of the quotas of the namespaces, there may be contention for resources. This is handled on a first-come-first-served basis. + +Neither contention nor changes to quota will affect already created resources. --> 在集群容量小于各命名空间配额总和的情况下，可能存在资源竞争。资源竞争时，Kubernetes 系统会遵循先到先得的原则。 -<!-- -Neither contention nor changes to quota will affect already created resources. ---> 不管是资源竞争还是配额的修改，都不会影响已经创建的资源使用对象。 <!-- ## Enabling Resource Quota + +Resource Quota support is enabled by default for many Kubernetes distributions. It is +enabled when the apiserver `-enable-admission-plugins=` flag has `ResourceQuota` as +one of its arguments. --> ## 启用资源配额 -<!-- -Resource Quota support is enabled by default for many Kubernetes distributions. It is -enabled when the apiserver `--enable-admission-plugins=` flag has `ResourceQuota` as -one of its arguments. ---> -资源配额的支持在很多 Kubernetes 版本中是默认开启的。当 apiserver `--enable-admission-plugins=` 参数中包含 `ResourceQuota` 时，资源配额会被启用。 +资源配额的支持在很多 Kubernetes 版本中是默认开启的。当 apiserver `--enable-admission-plugins=` +参数中包含 `ResourceQuota` 时，资源配额会被启用。 <!-- A resource quota is enforced in a particular namespace when there is a @@ -113,13 +119,14 @@ A resource quota is enforced in a particular namespace when there is a <!-- ## Compute Resource Quota + +You can limit the total sum of [compute resources](/docs/concepts/configuration/manage-resources-containers/) that can be requested in a given namespace. --> ## 计算资源配额 -<!-- -You can limit the total sum of [compute resources](/docs/user-guide/compute-resources) that can be requested in a given namespace. ---> -用户可以对给定命名空间下的可被请求的[计算资源](/docs/user-guide/compute-resources)总量进行限制。 +用户可以对给定命名空间下的可被请求的 +[计算资源](/zh/docs/concepts/configuration/manage-resources-containers/) +总量进行限制。 <!-- The following resource types are supported: @@ -128,14 +135,14 @@ The following resource types are supported: <!-- | Resource Name | Description | -| --------------------- | ----------------------------------------------------------- | +| --------------------- | --------------------------------------------------------- | | `limits.cpu` | Across all pods in a non-terminal state, the sum of CPU limits cannot exceed this value. | | `limits.memory` | Across all pods in a non-terminal state, the sum of memory limits cannot exceed this value. | | `requests.cpu` | Across all pods in a non-terminal state, the sum of CPU requests cannot exceed this value. | | `requests.memory` | Across all pods in a non-terminal state, the sum of memory requests cannot exceed this value. | --> | 资源名称 | 描述 | -| --------------------- | ----------------------------------------------------------- | +| --------------------- | --------------------------------------------- | | `limits.cpu` | 所有非终止状态的 Pod，其 CPU 限额总量不能超过该值。 | | `limits.memory` | 所有非终止状态的 Pod，其内存限额总量不能超过该值。 | | `requests.cpu` | 所有非终止状态的 Pod，其 CPU 需求总量不能超过该值。 | @@ -143,21 +150,23 @@ The following resource types are supported: <!-- ### Resource Quota For Extended Resources ---> -### 扩展资源的资源配额 -<!-- In addition to the resources mentioned above, in release 1.10, quota support for [extended resources](/docs/concepts/configuration/manage-compute-resources-container/#extended-resources) is added. --> -除上述资源外，在 Kubernetes 1.10 版本中，还添加了对[扩展资源](/docs/concepts/configuration/manage-compute-resources-container/#extended-resources)的支持。 +### 扩展资源的资源配额 + +除上述资源外，在 Kubernetes 1.10 版本中，还添加了对 +[扩展资源](/zh/docs/concepts/configuration/manage-resources-containers/#extended-resources) +的支持。 <!-- As overcommit is not allowed for extended resources, it makes no sense to specify both `requests` and `limits` for the same extended resource in a quota. So for extended resources, only quota items with prefix `requests.` is allowed for now. --> -由于扩展资源不可超量分配，因此没有必要在配额中为同一扩展资源同时指定 `requests` 和 `limits`。对于扩展资源而言，目前仅允许使用前缀为 `requests.` 的配额项。 +由于扩展资源不可超量分配，因此没有必要在配额中为同一扩展资源同时指定 `requests` 和 `limits`。 +对于扩展资源而言，目前仅允许使用前缀为 `requests.` 的配额项。 <!-- Take the GPU resource as an example, if the resource name is `nvidia.com/gpu`, and you want to @@ -174,22 +183,20 @@ See [Viewing and Setting Quotas](#viewing-and-setting-quotas) for more detail in <!-- ## Storage Resource Quota + +You can limit the total sum of [storage resources](/docs/concepts/storage/persistent-volumes/) that can be requested in a given namespace. + +In addition, you can limit consumption of storage resources based on associated storage-class. --> ## 存储资源配额 -<!-- -You can limit the total sum of [storage resources](/docs/concepts/storage/persistent-volumes/) that can be requested in a given namespace. ---> -用户可以对给定命名空间下的[存储资源](/docs/user-guide/persistent-volumes)总量进行限制。 +用户可以对给定命名空间下的[存储资源](/zh/docs/concepts/storage/persistent-volumes/)总量进行限制。 -<!-- -In addition, you can limit consumption of storage resources based on associated storage-class. ---> 此外，还可以根据相关的存储类（Storage Class）来限制存储资源的消耗。 <!-- | Resource Name | Description | -| --------------------- | ----------------------------------------------------------- | +| --------------------- | --------------------------------------------------------- | | `requests.storage` | Across all persistent volume claims, the sum of storage requests cannot exceed this value. | | `persistentvolumeclaims` | The total number of [persistent volume claims](/docs/concepts/storage/persistent-volumes/#persistentvolumeclaims) that can exist in the namespace. | | `<storage-class-name>.storageclass.storage.k8s.io/requests.storage` | Across all persistent volume claims associated with the storage-class-name, the sum of storage requests cannot exceed this value. | @@ -198,9 +205,9 @@ In addition, you can limit consumption of storage resources based on associated | 资源名称 | 描述 | | --------------------- | ----------------------------------------------------------- | | `requests.storage` | 所有 PVC，存储资源的需求总量不能超过该值。 | -| `persistentvolumeclaims` | 在该命名空间中所允许的 [PVC](/docs/user-guide/persistent-volumes/#persistentvolumeclaims) 总量。 | +| `persistentvolumeclaims` | 在该命名空间中所允许的 [PVC](/zh/docs/concepts/storage/persistent-volumes/#persistentvolumeclaims) 总量。 | | `<storage-class-name>.storageclass.storage.k8s.io/requests.storage` | 在所有与 storage-class-name 相关的持久卷声明中，存储请求的总和不能超过该值。 | -| `<storage-class-name>.storageclass.storage.k8s.io/persistentvolumeclaims` | 在与 storage-class-name 相关的所有持久卷声明中，命名空间中可以存在的[持久卷声明](/docs/concepts/storage/persistent-volumes/#persistentvolumeclaims)总数。 | +| `<storage-class-name>.storageclass.storage.k8s.io/persistentvolumeclaims` | 在与 storage-class-name 相关的所有持久卷声明中，命名空间中可以存在的[持久卷申领](/zh/docs/concepts/storage/persistent-volumes/#persistentvolumeclaims)总数。 | <!-- For example, if an operator wants to quota storage with `gold` storage class separate from `bronze` storage class, the operator can @@ -229,12 +236,11 @@ In release 1.8, quota support for local ephemeral storage is added as an alpha f <!-- ## Object Count Quota + +The 1.9 release added support to quota all standard namespaced resource types using the following syntax: --> ## 对象数量配额 -<!-- -The 1.9 release added support to quota all standard namespaced resource types using the following syntax: ---> Kubernetes 1.9 版本增加了使用以下语法对所有标准的、命名空间域的资源类型进行配额设置的支持。 * `count/<resource>.<group>` @@ -263,7 +269,6 @@ For example, to create a quota on a `widgets` custom resource in the `example.co Kubernetes 1.15 版本增加了对使用相同语法来约束自定义资源的支持。 例如，要对 `example.com` API 组中的自定义资源 `widgets` 设置配额，请使用 `count/widgets.example.com`。 - <!-- When using `count/*` resource quota, an object is charged against the quota if it exists in server storage. These types of quotas are useful to protect against exhaustion of storage resources. For example, you may @@ -278,18 +283,17 @@ a poorly configured cronjob creating too many jobs in a namespace causing a deni <!-- Prior to the 1.9 release, it was possible to do generic object count quota on a limited set of resources. In addition, it is possible to further constrain quota for particular resources by their type. + +The following types are supported: --> 在 Kubernetes 1.9 版本之前，可以在有限的一组资源上实施一般性的对象数量配额。 此外，还可以进一步按资源的类型设置其配额。 -<!-- -The following types are supported: ---> 支持以下类型： <!-- | Resource Name | Description | -| ------------------------------- | ------------------------------------------------- | +| ----------------------------|--------------------------------------------- | | `configmaps` | The total number of config maps that can exist in the namespace. | | `persistentvolumeclaims` | The total number of [persistent volume claims](/docs/concepts/storage/persistent-volumes/#persistentvolumeclaims) that can exist in the namespace. | | `pods` | The total number of pods in a non-terminal state that can exist in the namespace. A pod is in a terminal state if `.status.phase in (Failed, Succeeded)` is true. | @@ -303,10 +307,10 @@ The following types are supported: | 资源名称 | 描述 | | ------------------------------- | ------------------------------------------------- | | `configmaps` | 在该命名空间中允许存在的 ConfigMap 总数上限。 | -| `persistentvolumeclaims` | 在该命名空间中允许存在的 [PVC](/docs/user-guide/persistent-volumes/#persistentvolumeclaims) 的总数上限。 | +| `persistentvolumeclaims` | 在该命名空间中允许存在的 [PVC](/zh/docs/concepts/storage/persistent-volumes/#persistentvolumeclaims) 的总数上限。 | | `pods` | 在该命名空间中允许存在的非终止状态的 pod 总数上限。Pod 终止状态等价于 Pod 的 `.status.phase in (Failed, Succeeded)` = true | | `replicationcontrollers` | 在该命名空间中允许存在的 RC 总数上限。 | -| `resourcequotas` | 在该命名空间中允许存在的[资源配额](/docs/admin/admission-controllers/#resourcequota)总数上限。 | +| `resourcequotas` | 在该命名空间中允许存在的资源配额总数上限。 | | `services` | 在该命名空间中允许存在的 Service 总数上限。 | | `services.loadbalancers` | 在该命名空间中允许存在的 LoadBalancer 类型的服务总数上限。 | | `services.nodeports` | 在该命名空间中允许存在的 NodePort 类型的服务总数上限。 | @@ -318,18 +322,19 @@ created in a single namespace that are not terminal. You might want to set a `po quota on a namespace to avoid the case where a user creates many small pods and exhausts the cluster's supply of Pod IPs. --> -例如，`pods` 配额统计某个命名空间中所创建的、非终止状态的 `Pod` 个数并确保其不超过某上限值。用户可能希望在某命名空间中设置 `pods` 配额，以避免有用户创建很多小的 Pod，从而耗尽集群所能提供的 Pod IP 地址。 +例如，`pods` 配额统计某个命名空间中所创建的、非终止状态的 `Pod` 个数并确保其不超过某上限值。 +用户可能希望在某命名空间中设置 `pods` 配额，以避免有用户创建很多小的 Pod，从而耗尽集群所能提供的 Pod IP 地址。 <!-- ## Quota Scopes ---> -## 配额作用域 -<!-- Each quota can have an associated set of scopes. A quota will only measure usage for a resource if it matches the intersection of enumerated scopes. --> -每个配额都有一组相关的作用域（scope），配额只会对作用域内的资源生效。配额机制仅统计所列举的作用域的交集中的资源用量。 +## 配额作用域 {#quota-scopes} + +每个配额都有一组相关的作用域（scope），配额只会对作用域内的资源生效。 +配额机制仅统计所列举的作用域的交集中的资源用量。 <!-- When a scope is added to the quota, it limits the number of resources it supports to those that pertain to the scope. @@ -340,7 +345,7 @@ Resources specified on the quota outside of the allowed set results in a validat <!-- | Scope | Description | -| ----- | ----------- | +| ----- | ------------ | | `Terminating` | Match pods where `.spec.activeDeadlineSeconds >= 0` | | `NotTerminating` | Match pods where `.spec.activeDeadlineSeconds is nil` | | `BestEffort` | Match pods that have best effort quality of service. | @@ -355,12 +360,11 @@ Resources specified on the quota outside of the allowed set results in a validat <!-- The `BestEffort` scope restricts a quota to tracking the following resource: `pods` + +The `Terminating`, `NotTerminating`, and `NotBestEffort` scopes restrict a quota to tracking the following resources: --> `BestEffort` 作用域限制配额跟踪以下资源：`pods` -<!-- -The `Terminating`, `NotTerminating`, and `NotBestEffort` scopes restrict a quota to tracking the following resources: ---> `Terminating`、`NotTerminating` 和 `NotBestEffort` 这三种作用域限制配额跟踪以下资源： * `cpu` @@ -383,18 +387,17 @@ Pods can be created at a specific [priority](/docs/concepts/configuration/pod-pr You can control a pod's consumption of system resources based on a pod's priority, by using the `scopeSelector` field in the quota spec. --> -Pod 可以创建为特定的[优先级](/docs/concepts/configuration/pod-priority-preemption/#pod-priority)。 +Pod 可以创建为特定的[优先级](/zh/docs/concepts/configuration/pod-priority-preemption/#pod-priority)。 通过使用配额规约中的 `scopeSelector` 字段，用户可以根据 Pod 的优先级控制其系统资源消耗。 <!-- A quota is matched and consumed only if `scopeSelector` in the quota spec selects the pod. ---> -仅当配额规范中的 `scopeSelector` 字段选择到某 Pod 时，配额机制才会匹配和计量 Pod 的资源消耗。 -<!-- This example creates a quota object and matches it with pods at specific priorities. The example works as follows: --> +仅当配额规范中的 `scopeSelector` 字段选择到某 Pod 时，配额机制才会匹配和计量 Pod 的资源消耗。 + 本示例创建一个配额对象，并将其与具有特定优先级的 Pod 进行匹配。 该示例的工作方式如下： @@ -405,9 +408,7 @@ works as follows: - 集群中的 Pod 可取三个优先级类之一，即 "low"、"medium"、"high"。 - 为每个优先级创建一个配额对象。 -<!-- -Save the following YAML to a file `quota.yml`. ---> +<!-- Save the following YAML to a file `quota.yml`. --> 将以下 YAML 保存到文件 `quota.yml` 中。 ```yaml @@ -467,7 +468,7 @@ Apply the YAML using `kubectl create`. kubectl create -f ./quota.yml ``` -```shell +``` resourcequota/pods-high created resourcequota/pods-medium created resourcequota/pods-low created @@ -482,7 +483,7 @@ Verify that `Used` quota is `0` using `kubectl describe quota`. kubectl describe quota ``` -```shell +``` Name: pods-high Namespace: default Resource Used Hard @@ -557,7 +558,7 @@ the other two quotas are unchanged. kubectl describe quota ``` -```shell +``` Name: pods-high Namespace: default Resource Used Hard @@ -597,13 +598,12 @@ pods 0 10 <!-- ## Requests vs Limits ---> -## 请求与限制 -<!-- When allocating compute resources, each container may specify a request and a limit value for either CPU or memory. The quota can be configured to quota either value. --> +## 请求与限制 {#requests-vs-limits} + 分配计算资源时，每个容器可以为 CPU 或内存指定请求和约束。 配额可以针对二者之一进行设置。 @@ -612,16 +612,16 @@ If the quota has a value specified for `requests.cpu` or `requests.memory`, then container makes an explicit request for those resources. If the quota has a value specified for `limits.cpu` or `limits.memory`, then it requires that every incoming container specifies an explicit limit for those resources. --> -如果配额中指定了 `requests.cpu` 或 `requests.memory` 的值，则它要求每个容器都显式给出对这些资源的请求。同理，如果配额中指定了 `limits.cpu` 或 `limits.memory` 的值，那么它要求每个容器都显式设定对应资源的限制。 +如果配额中指定了 `requests.cpu` 或 `requests.memory` 的值，则它要求每个容器都显式给出对这些资源的请求。 +同理，如果配额中指定了 `limits.cpu` 或 `limits.memory` 的值，那么它要求每个容器都显式设定对应资源的限制。 <!-- ## Viewing and Setting Quotas + +Kubectl supports creating, updating, and viewing quotas: --> ## 查看和设置配额 {#viewing-and-setting-quotas} -<!-- -Kubectl supports creating, updating, and viewing quotas: ---> Kubectl 支持创建、更新和查看配额： ```shell @@ -674,7 +674,7 @@ kubectl create -f ./object-counts.yaml --namespace=myspace kubectl get quota --namespace=myspace ``` -```shell +``` NAME AGE compute-resources 30s object-counts 32s @@ -684,7 +684,7 @@ object-counts 32s kubectl describe quota compute-resources --namespace=myspace ``` -```shell +``` Name: compute-resources Namespace: myspace Resource Used Hard @@ -700,7 +700,7 @@ requests.nvidia.com/gpu 0 4 kubectl describe quota object-counts --namespace=myspace ``` -```shell +``` Name: object-counts Namespace: myspace Resource Used Hard @@ -736,7 +736,7 @@ kubectl create deployment nginx --image=nginx --namespace=myspace kubectl describe quota --namespace=myspace ``` -```shell +``` Name: test Namespace: myspace Resource Used Hard @@ -749,27 +749,26 @@ count/secrets 1 4 <!-- ## Quota and Cluster Capacity ---> -## 配额和集群容量 -<!-- `ResourceQuotas` are independent of the cluster capacity. They are expressed in absolute units. So, if you add nodes to your cluster, this does *not* automatically give each namespace the ability to consume more resources. --> -资源配额与集群资源总量是完全独立的。它们通过绝对的单位来配置。所以，为集群添加节点时，资源配额*不会*自动赋予每个命名空间消耗更多资源的能力。 +## 配额和集群容量 {#quota-and-cluster-capacity} + +资源配额与集群资源总量是完全独立的。它们通过绝对的单位来配置。 +所以，为集群添加节点时，资源配额*不会*自动赋予每个命名空间消耗更多资源的能力。 <!-- Sometimes more complex policies may be desired, such as: ---> -有时可能需要资源配额支持更复杂的策略，比如： -<!-- - Proportionally divide total cluster resources among several teams. - Allow each tenant to grow resource usage as needed, but have a generous limit to prevent accidental resource exhaustion. - Detect demand from one namespace, add nodes, and increase quota. --> +有时可能需要资源配额支持更复杂的策略，比如： + - 在几个团队中按比例划分总的集群资源。 - 允许每个租户根据需要增加资源使用量，但要有足够的限制以防止资源意外耗尽。 - 探测某个命名空间的需求，添加物理节点并扩大资源配额值。 @@ -779,7 +778,8 @@ Such policies could be implemented using `ResourceQuotas` as building blocks, by writing a "controller" that watches the quota usage and adjusts the quota hard limits of each namespace according to other signals. --> -这些策略可以通过将资源配额作为一个组成模块、手动编写一个控制器来监控资源使用情况，并结合其他信号调整命名空间上的硬性资源配额来实现。 +这些策略可以通过将资源配额作为一个组成模块、手动编写一个控制器来监控资源使用情况， +并结合其他信号调整命名空间上的硬性资源配额来实现。 <!-- Note that resource quota divides up aggregate cluster resources, but it creates no @@ -789,21 +789,22 @@ restrictions around nodes: pods from several namespaces may run on the same node <!-- ## Limit Priority Class consumption by default + +It may be desired that pods at a particular priority, eg. "cluster-services", should be allowed in a namespace, if and only if, a matching quota object exists. --> ## 默认情况下限制特定优先级的资源消耗 -<!-- -It may be desired that pods at a particular priority, eg. "cluster-services", should be allowed in a namespace, if and only if, a matching quota object exists. ---> -有时候可能希望当且仅当某名字空间中存在匹配的配额对象时，才可以创建特定优先级（例如 "cluster-services"）的 Pod。 +有时候可能希望当且仅当某名字空间中存在匹配的配额对象时，才可以创建特定优先级 +（例如 "cluster-services"）的 Pod。 <!-- With this mechanism, operators will be able to restrict usage of certain high priority classes to a limited number of namespaces and not every namespace will be able to consume these priority classes by default. --> -通过这种机制，操作人员能够将限制某些高优先级类仅出现在有限数量的命名空间中，而并非每个命名空间默认情况下都能够使用这些优先级类。 +通过这种机制，操作人员能够将限制某些高优先级类仅出现在有限数量的命名空间中， +而并非每个命名空间默认情况下都能够使用这些优先级类。 <!-- -To enforce this, kube-apiserver flag `--admission-control-config-file` should be used to pass path to the following configuration file: +To enforce this, kube-apiserver flag `-admission-control-config-file` should be used to pass path to the following configuration file: --> 要实现此目的，应使用 kube-apiserver 标志 `--admission-control-config-file` 传递如下配置文件的路径： @@ -820,26 +821,26 @@ plugins: limitedResources: - resource: pods matchScopes: - - scopeName: PriorityClass + - scopeName: PriorityClass operator: In values: ["cluster-services"] ``` {{% /tab %}} {{% tab name="apiserver.k8s.io/v1alpha1" %}} ```yaml -# 在 Kubernetes 1.17 中已不被推荐使用，请使用 apiserver.config.k8s.io/v1 +# 在 Kubernetes 1.17 中已不推荐使用，请使用 apiserver.config.k8s.io/v1 apiVersion: apiserver.k8s.io/v1alpha1 kind: AdmissionConfiguration plugins: - name: "ResourceQuota" configuration: - # 在 Kubernetes 1.17 中已不被推荐使用，请使用 apiserver.config.k8s.io/v1, ResourceQuotaConfiguration + # 在 Kubernetes 1.17 中已不推荐使用，请使用 apiserver.config.k8s.io/v1, ResourceQuotaConfiguration apiVersion: resourcequota.admission.k8s.io/v1beta1 kind: Configuration limitedResources: - resource: pods matchScopes: - - scopeName: PriorityClass + - scopeName: PriorityClass operator: In values: ["cluster-services"] ``` @@ -848,12 +849,11 @@ plugins: <!-- Now, "cluster-services" pods will be allowed in only those namespaces where a quota object with a matching `scopeSelector` is present. + +For example: --> 现在，仅当命名空间中存在匹配的 `scopeSelector` 的配额对象时，才允许使用 "cluster-services" Pod。 -<!-- -For example: ---> 示例： ```yaml @@ -867,26 +867,22 @@ For example: <!-- See [LimitedResources](https://github.com/kubernetes/kubernetes/pull/36765) and [Quota support for priority class design doc](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/scheduling/pod-priority-resourcequota.md) for more information. --> -有关更多信息，请参见 [LimitedResources](https://github.com/kubernetes/kubernetes/pull/36765) 和[优先级类配额支持的设计文档](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/scheduling/pod-priority-resourcequota.md)。 +有关更多信息，请参见 [LimitedResources](https://github.com/kubernetes/kubernetes/pull/36765) 和 +[优先级类配额支持的设计文档](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/scheduling/pod-priority-resourcequota.md)。 <!-- ## Example + +See a [detailed example for how to use resource quota](/docs/tasks/administer-cluster/quota-api-object/). --> ## 示例 -<!-- -See a [detailed example for how to use resource quota](/docs/tasks/administer-cluster/quota-api-object/). ---> -查看[如何使用资源配额的详细示例](/docs/tasks/administer-cluster/quota-api-object/)。 - - +查看[如何使用资源配额的详细示例](/zh/docs/tasks/administer-cluster/quota-api-object/)。 ## {{% heading "whatsnext" %}} - <!-- -See [ResourceQuota design doc](https://git.k8s.io/community/contributors/design-proposals/resource-management/admission_control_resource_quota.md) for more information. +- See [ResourceQuota design doc](https://git.k8s.io/community/contributors/design-proposals/resource-management/admission_control_resource_quota.md) for more information. --> -查看[资源配额设计文档](https://git.k8s.io/community/contributors/design-proposals/resource-management/admission_control_resource_quota.md)了解更多信息。 - - +- 查看[资源配额设计文档](https://git.k8s.io/community/contributors/design-proposals/resource-management/admission_control_resource_quota.md) + 了解更多信息。 diff --git a/content/zh/docs/concepts/configuration/assign-pod-node.md b/content/zh/docs/concepts/scheduling-eviction/assign-pod-node.md similarity index 87% rename from content/zh/docs/concepts/configuration/assign-pod-node.md rename to content/zh/docs/concepts/scheduling-eviction/assign-pod-node.md index 92d26f57cf..29dec9c016 100644 --- a/content/zh/docs/concepts/configuration/assign-pod-node.md +++ b/content/zh/docs/concepts/scheduling-eviction/assign-pod-node.md @@ -5,18 +5,11 @@ weight: 50 --- <!-- ---- -reviewers: -- davidopp -- kevin-wangzefeng -- bsalamat title: Assigning Pods to Nodes content_type: concept weight: 50 ---- --> - <!-- overview --> <!-- @@ -26,14 +19,12 @@ There are several ways to do this, and the recommended approaches all use [label selectors](/docs/concepts/overview/working-with-objects/labels/) to make the selection. Generally such constraints are unnecessary, as the scheduler will automatically do a reasonable placement (e.g. spread your pods across nodes, not place the pod on a node with insufficient free resources, etc.) -but there are some circumstances where you may want more control on a node where a pod lands, e.g. to ensure +but there are some circumstances where you may want more control on a node where a pod lands, for example to ensure that a pod ends up on a machine with an SSD attached to it, or to co-locate pods from two different services that communicate a lot into the same availability zone. --> -你可以约束一个 {{< glossary_tooltip text="Pod" term_id="pod" >}} 只能在特定的 {{< glossary_tooltip text="Node(s)" term_id="node" >}} 上运行，或者优先运行在特定的节点上。有几种方法可以实现这点，推荐的方法都是用[标签选择器](/docs/concepts/overview/working-with-objects/labels/)来进行选择。通常这样的约束不是必须的，因为调度器将自动进行合理的放置（比如，将 pod 分散到节点上，而不是将 pod 放置在可用资源不足的节点上等等），但在某些情况下，你可以需要更多控制 pod 停靠的节点，例如，确保 pod 最终落在连接了 SSD 的机器上，或者将来自两个不同的服务且有大量通信的 pod 放置在同一个可用区。 - - +你可以约束一个 {{< glossary_tooltip text="Pod" term_id="pod" >}} 只能在特定的 {{< glossary_tooltip text="Node(s)" term_id="node" >}} 上运行，或者优先运行在特定的节点上。有几种方法可以实现这点，推荐的方法都是用[标签选择器](/zh/docs/concepts/overview/working-with-objects/labels/)来进行选择。通常这样的约束不是必须的，因为调度器将自动进行合理的放置（比如，将 pod 分散到节点上，而不是将 pod 放置在可用资源不足的节点上等等），但在某些情况下，你可以需要更多控制 pod 停靠的节点，例如，确保 pod 最终落在连接了 SSD 的机器上，或者将来自两个不同的服务且有大量通信的 pod 放置在同一个可用区。 <!-- body --> @@ -46,7 +37,8 @@ to run on a node, the node must have each of the indicated key-value pairs as la additional labels as well). The most common usage is one key-value pair. --> -`nodeSelector` 是节点选择约束的最简单推荐形式。`nodeSelector` 是 PodSpec 的一个字段。它指定键值对的映射。为了使 pod 可以在节点上运行，节点必须具有每个指定的键值对作为标签（它也可以具有其他标签）。最常用的是一对键值对。 +`nodeSelector` 是节点选择约束的最简单推荐形式。`nodeSelector` 是 PodSpec 的一个字段。 +它包含键值对的映射。为了使 pod 可以在某个节点上运行，该节点的标签中必须包含这里的每个键值对（它也可以具有其他标签）。最常见的用法的是一对键值对。 <!-- Let's walk through an example of how to use `nodeSelector`. @@ -63,38 +55,40 @@ Let's walk through an example of how to use `nodeSelector`. <!-- This example assumes that you have a basic understanding of Kubernetes pods and that you have [set up a Kubernetes cluster](/docs/setup/). --> - -本示例假设你已基本了解 Kubernetes 的 pod 并且已经[建立一个 Kubernetes 集群](/docs/setup/)。 +本示例假设你已基本了解 Kubernetes 的 Pod 并且已经[建立一个 Kubernetes 集群](/zh/docs/setup/)。 <!-- ### Step One: Attach label to the node --> - -### 步骤一：添加标签到节点 +### 步骤一：添加标签到节点 {#attach-labels-to-node} <!-- Run `kubectl get nodes` to get the names of your cluster's nodes. Pick out the one that you want to add a label to, and then run `kubectl label nodes <node-name> <label-key>=<label-value>` to add a label to the node you've chosen. For example, if my node name is 'kubernetes-foo-node-1.c.a-robinson.internal' and my desired label is 'disktype=ssd', then I can run `kubectl label nodes kubernetes-foo-node-1.c.a-robinson.internal disktype=ssd`. --> -执行 `kubectl get nodes` 命令获取集群的节点名称。选择一个你要增加标签的节点，然后执行 `kubectl label nodes <node-name> <label-key>=<label-value>` 命令将标签添加到你所选择的节点上。例如，如果你的节点名称为 'kubernetes-foo-node-1.c.a-robinson.internal' 并且想要的标签是 'disktype=ssd'，则可以执行 `kubectl label nodes kubernetes-foo-node-1.c.a-robinson.internal disktype=ssd` 命令。 +执行 `kubectl get nodes` 命令获取集群的节点名称。 +选择一个你要增加标签的节点，然后执行 `kubectl label nodes <node-name> <label-key>=<label-value>` +命令将标签添加到你所选择的节点上。 +例如，如果你的节点名称为 'kubernetes-foo-node-1.c.a-robinson.internal' +并且想要的标签是 'disktype=ssd'，则可以执行 +`kubectl label nodes kubernetes-foo-node-1.c.a-robinson.internal disktype=ssd` 命令。 <!-- -You can verify that it worked by re-running `kubectl get nodes --show-labels` and checking that the node now has a label. You can also use `kubectl describe node "nodename"` to see the full list of labels of the given node. +You can verify that it worked by re-running `kubectl get nodes -show-labels` and checking that the node now has a label. You can also use `kubectl describe node "nodename"` to see the full list of labels of the given node. --> - -你可以通过重新运行 `kubectl get nodes --show-labels` 并且查看节点当前具有了一个标签来验证它是否有效。你也可以使用 `kubectl describe node "nodename"` 命令查看指定节点的标签完整列表。 +你可以通过重新运行 `kubectl get nodes --show-labels`，查看节点当前具有了所指定的标签来验证它是否有效。 +你也可以使用 `kubectl describe node "nodename"` 命令查看指定节点的标签完整列表。 <!-- ### Step Two: Add a nodeSelector field to your pod configuration --> - -### 步骤二：添加 nodeSelector 字段到 pod 配置中 +### 步骤二：添加 nodeSelector 字段到 Pod 配置中 <!-- Take whatever pod config file you want to run, and add a nodeSelector section to it, like this. For example, if this is my pod config: --> - -拿任意一个你想运行的 pod 的配置文件，并且在其中添加一个 nodeSelector 部分。例如，如果下面是我的 pod 配置： +选择任何一个你想运行的 Pod 的配置文件，并且在其中添加一个 nodeSelector 部分。 +例如，如果下面是我的 pod 配置： ```yaml apiVersion: v1 @@ -123,32 +117,30 @@ the Pod will get scheduled on the node that you attached the label to. You can verify that it worked by running `kubectl get pods -o wide` and looking at the "NODE" that the Pod was assigned to. --> - -当你之后运行 `kubectl apply -f https://k8s.io/examples/pods/pod-nginx.yaml` 命令，pod 将会调度到将标签添加到的节点上。你可以通过运行 `kubectl get pods -o wide` 并查看分配给 pod 的 “NODE” 来验证其是否有效。 +当你之后运行 `kubectl apply -f https://k8s.io/examples/pods/pod-nginx.yaml` 命令， +Pod 将会调度到将标签添加到的节点上。你可以通过运行 `kubectl get pods -o wide` 并查看分配给 pod 的 “NODE” 来验证其是否有效。 <!-- ## Interlude: built-in node labels {#built-in-node-labels} --> -## 插曲：内置的节点标签 {#内置的节点标签} +## 插曲：内置的节点标签 {#built-in-node-labels} <!-- In addition to labels you [attach](#step-one-attach-label-to-the-node), nodes come pre-populated with a standard set of labels. These labels are --> +除了你[附加](#attach-labels-to-node)的标签外，节点还预先填充了一组标准标签。这些标签是 -除了你[附加](#添加标签到节点)的标签外，节点还预先填充了一组标准标签。这些标签是 - -* [`kubernetes.io/hostname`](/docs/reference/kubernetes-api/labels-annotations-taints/#kubernetes-io-hostname) -* [`failure-domain.beta.kubernetes.io/zone`](/docs/reference/kubernetes-api/labels-annotations-taints/#failure-domainbetakubernetesiozone) -* [`failure-domain.beta.kubernetes.io/region`](/docs/reference/kubernetes-api/labels-annotations-taints/#failure-domainbetakubernetesioregion) -* [`topology.kubernetes.io/zone`](/docs/reference/kubernetes-api/labels-annotations-taints/#topologykubernetesiozone) -* [`topology.kubernetes.io/region`](/docs/reference/kubernetes-api/labels-annotations-taints/#topologykubernetesiozone) -* [`beta.kubernetes.io/instance-type`](/docs/reference/kubernetes-api/labels-annotations-taints/#beta-kubernetes-io-instance-type) -* [`node.kubernetes.io/instance-type`](/docs/reference/kubernetes-api/labels-annotations-taints/#nodekubernetesioinstance-type) -* [`kubernetes.io/os`](/docs/reference/kubernetes-api/labels-annotations-taints/#kubernetes-io-os) -* [`kubernetes.io/arch`](/docs/reference/kubernetes-api/labels-annotations-taints/#kubernetes-io-arch) - +* [`kubernetes.io/hostname`](/zh/docs/reference/kubernetes-api/labels-annotations-taints/#kubernetes-io-hostname) +* [`failure-domain.beta.kubernetes.io/zone`](/zh/docs/reference/kubernetes-api/labels-annotations-taints/#failure-domainbetakubernetesiozone) +* [`failure-domain.beta.kubernetes.io/region`](/zh/docs/reference/kubernetes-api/labels-annotations-taints/#failure-domainbetakubernetesioregion) +* [`topology.kubernetes.io/zone`](/zh/docs/reference/kubernetes-api/labels-annotations-taints/#topologykubernetesiozone) +* [`topology.kubernetes.io/region`](/zh/docs/reference/kubernetes-api/labels-annotations-taints/#topologykubernetesiozone) +* [`beta.kubernetes.io/instance-type`](/zh/docs/reference/kubernetes-api/labels-annotations-taints/#beta-kubernetes-io-instance-type) +* [`node.kubernetes.io/instance-type`](/zh/docs/reference/kubernetes-api/labels-annotations-taints/#nodekubernetesioinstance-type) +* [`kubernetes.io/os`](/zh/docs/reference/kubernetes-api/labels-annotations-taints/#kubernetes-io-os) +* [`kubernetes.io/arch`](/zh/docs/reference/kubernetes-api/labels-annotations-taints/#kubernetes-io-arch) {{< note >}} <!-- @@ -190,7 +182,8 @@ For example, `example.com.node-restriction.kubernetes.io/fips=true` or `example. --> 1. 检查是否在使用 Kubernetes v1.11+，以便 NodeRestriction 功能可用。 -2. 确保你在使用[节点授权](/docs/reference/access-authn-authz/node/)并且已经_启用_ [NodeRestriction 准入插件](/docs/reference/access-authn-authz/admission-controllers/#noderestriction)。 +2. 确保你在使用[节点授权](/zh/docs/reference/access-authn-authz/node/)并且已经_启用_ + [NodeRestriction 准入插件](/zh/docs/reference/access-authn-authz/admission-controllers/#noderestriction)。 3. 将 `node-restriction.kubernetes.io/` 前缀下的标签添加到 Node 对象，然后在节点选择器中使用这些标签。例如，`example.com.node-restriction.kubernetes.io/fips=true` 或 `example.com.node-restriction.kubernetes.io/pci-dss=true`。 <!-- @@ -289,10 +282,13 @@ value is `another-node-label-value` should be preferred. <!-- You can see the operator `In` being used in the example. The new node affinity syntax supports the following operators: `In`, `NotIn`, `Exists`, `DoesNotExist`, `Gt`, `Lt`. You can use `NotIn` and `DoesNotExist` to achieve node anti-affinity behavior, or use -[node taints](/docs/concepts/configuration/taint-and-toleration/) to repel pods from specific nodes. +[node taints](/docs/concepts/scheduling-eviction/taint-and-toleration/) to repel pods from specific nodes. --> -你可以在上面的例子中看到 `In` 操作符的使用。新的节点亲和语法支持下面的操作符： `In`，`NotIn`，`Exists`，`DoesNotExist`，`Gt`，`Lt`。你可以使用 `NotIn` 和 `DoesNotExist` 来实现节点反亲和行为，或者使用[节点污点](/docs/concepts/configuration/taint-and-toleration/)将 pod 从特定节点中驱逐。 +你可以在上面的例子中看到 `In` 操作符的使用。新的节点亲和语法支持下面的操作符： +`In`，`NotIn`，`Exists`，`DoesNotExist`，`Gt`，`Lt`。 +你可以使用 `NotIn` 和 `DoesNotExist` 来实现节点反亲和行为，或者使用 +[节点污点](/zh/docs/concepts/scheduling-eviction/taint-and-toleration/)将 pod 从特定节点中驱逐。 <!-- If you specify both `nodeSelector` and `nodeAffinity`, *both* must be satisfied for the pod @@ -343,7 +339,7 @@ key for the node label that the system uses to denote such a topology domain, e. in the section [Interlude: built-in node labels](#built-in-node-labels). --> -pod 间亲和与反亲和使你可以*基于已经在节点上运行的 pod 的标签*来约束 pod 可以调度到的节点，而不是基于节点上的标签。规则的格式为“如果 X 节点上已经运行了一个或多个 满足规则 Y 的pod，则这个 pod 应该（或者在非亲和的情况下不应该）运行在 X 节点”。Y 表示一个具有可选的关联命令空间列表的 LabelSelector；与节点不同，因为 pod 是命名空间限定的（因此 pod 上的标签也是命名空间限定的），因此作用于 pod 标签的标签选择器必须指定选择器应用在哪个命名空间。从概念上讲，X 是一个拓扑域，如节点，机架，云供应商地区，云供应商区域等。你可以使用 `topologyKey` 来表示它，`topologyKey` 是节点标签的键以便系统用来表示这样的拓扑域。请参阅上面[插曲：内置的节点标签](#内置的节点标签)部分中列出的标签键。 +pod 间亲和与反亲和使你可以*基于已经在节点上运行的 pod 的标签*来约束 pod 可以调度到的节点，而不是基于节点上的标签。规则的格式为“如果 X 节点上已经运行了一个或多个 满足规则 Y 的pod，则这个 pod 应该（或者在非亲和的情况下不应该）运行在 X 节点”。Y 表示一个具有可选的关联命令空间列表的 LabelSelector；与节点不同，因为 pod 是命名空间限定的（因此 pod 上的标签也是命名空间限定的），因此作用于 pod 标签的标签选择器必须指定选择器应用在哪个命名空间。从概念上讲，X 是一个拓扑域，如节点，机架，云供应商地区，云供应商区域等。你可以使用 `topologyKey` 来表示它，`topologyKey` 是节点标签的键以便系统用来表示这样的拓扑域。请参阅上面[插曲：内置的节点标签](#built-in-node-labels)部分中列出的标签键。 {{< note >}} <!-- @@ -578,10 +574,12 @@ As you can see, all the 3 replicas of the `web-server` are automatically co-loca ``` kubectl get pods -o wide ``` + <!-- The output is similar to this: --> 输出类似于如下内容： + ``` NAME READY STATUS RESTARTS AGE IP NODE redis-cache-1450370735-6dzlj 1/1 Running 0 8m 10.192.4.2 kube-node-3 @@ -604,8 +602,10 @@ no two instances are located on the same host. See [ZooKeeper tutorial](/docs/tutorials/stateful-application/zookeeper/#tolerating-node-failure) for an example of a StatefulSet configured with anti-affinity for high availability, using the same technique. --> - -上面的例子使用 `PodAntiAffinity` 规则和 `topologyKey: "kubernetes.io/hostname"` 来部署 redis 集群以便在同一主机上没有两个实例。参阅 [ZooKeeper 教程](/docs/tutorials/stateful-application/zookeeper/#tolerating-node-failure)，以获取配置反亲和来达到高可用性的 StatefulSet 的样例（使用了相同的技巧）。 +上面的例子使用 `PodAntiAffinity` 规则和 `topologyKey: "kubernetes.io/hostname"` +来部署 redis 集群以便在同一主机上没有两个实例。 +参阅 [ZooKeeper 教程](/zh/docs/tutorials/stateful-application/zookeeper/#tolerating-node-failure)， +以获取配置反亲和来达到高可用性的 StatefulSet 的样例（使用了相同的技巧）。 ## nodeName @@ -617,13 +617,11 @@ kubelet running on the named node tries to run the pod. Thus, if `nodeName` is provided in the PodSpec, it takes precedence over the above methods for node selection. --> - `nodeName` 是节点选择约束的最简单方法，但是由于其自身限制，通常不使用它。`nodeName` 是 PodSpec 的一个字段。如果它不为空，调度器将忽略 pod，并且运行在它指定节点上的 kubelet 进程尝试运行该 pod。因此，如果 `nodeName` 在 PodSpec 中指定了，则它优先于上面的节点选择方法。 <!-- Some of the limitations of using `nodeName` to select nodes are: --> - 使用 `nodeName` 来选择节点的一些限制： <!-- @@ -635,7 +633,6 @@ Some of the limitations of using `nodeName` to select nodes are: - Node names in cloud environments are not always predictable or stable. --> - - 如果指定的节点不存在， - 如果指定的节点没有资源来容纳 pod，pod 将会调度失败并且其原因将显示为，比如 OutOfmemory 或 OutOfcpu。 - 云环境中的节点名称并非总是可预测或稳定的。 @@ -643,7 +640,6 @@ Some of the limitations of using `nodeName` to select nodes are: <!-- Here is an example of a pod config file using the `nodeName` field: --> - 下面的是使用 `nodeName` 字段的 pod 配置文件的例子： ```yaml @@ -664,16 +660,13 @@ The above pod will run on the node kube-01. 上面的 pod 将运行在 kube-01 节点上。 - - ## {{% heading "whatsnext" %}} - <!-- -[Taints](/docs/concepts/configuration/taint-and-toleration/) allow a Node to *repel* a set of Pods. +[Taints](/docs/concepts/scheduling-eviction/taint-and-toleration/) allow a Node to *repel* a set of Pods. --> -[污点](/docs/concepts/configuration/taint-and-toleration/)允许节点*排斥*一组 pod。 +[污点](/zh/docs/concepts/scheduling-eviction/taint-and-toleration/)允许节点*排斥*一组 pod。 <!-- The design documents for @@ -681,7 +674,8 @@ The design documents for and for [inter-pod affinity/anti-affinity](https://git.k8s.io/community/contributors/design-proposals/scheduling/podaffinity.md) contain extra background information about these features. --> -[节点亲和](https://git.k8s.io/community/contributors/design-proposals/scheduling/nodeaffinity.md)与 [pod 间亲和/反亲和](https://git.k8s.io/community/contributors/design-proposals/scheduling/podaffinity.md)的设计文档包含这些功能的其他背景信息。 +[节点亲和](https://git.k8s.io/community/contributors/design-proposals/scheduling/nodeaffinity.md)与 +[pod 间亲和/反亲和](https://git.k8s.io/community/contributors/design-proposals/scheduling/podaffinity.md)的设计文档包含这些功能的其他背景信息。 <!-- Once a Pod is assigned to a Node, the kubelet runs the Pod and allocates node-local resources. @@ -689,6 +683,7 @@ The [topology manager](/docs/tasks/administer-cluster/topology-manager/) can tak resource allocation decisions. --> -一旦 pod 分配给 节点，kubelet 应用将运行该 pod 并且分配节点本地资源。[拓扑管理](/docs/tasks/administer-cluster/topology-manager/) - +一旦 Pod 分配给 节点，kubelet 应用将运行该 pod 并且分配节点本地资源。 +[拓扑管理器](/zh/docs/tasks/administer-cluster/topology-manager/) +可以参与到节点级别的资源分配决定中。 diff --git a/content/zh/docs/concepts/scheduling-eviction/scheduler-perf-tuning.md b/content/zh/docs/concepts/scheduling-eviction/scheduler-perf-tuning.md index b38314d989..0efa384a27 100644 --- a/content/zh/docs/concepts/scheduling-eviction/scheduler-perf-tuning.md +++ b/content/zh/docs/concepts/scheduling-eviction/scheduler-perf-tuning.md @@ -4,13 +4,11 @@ content_type: concept weight: 70 --- <!-- ---- reviewers: - bsalamat title: Scheduler Performance Tuning content_type: concept weight: 70 ---- --> <!-- overview --> @@ -22,7 +20,9 @@ weight: 70 is the Kubernetes default scheduler. It is responsible for placement of Pods on Nodes in a cluster. --> -作为 kubernetes 集群的默认调度器，[kube-scheduler](/docs/concepts/scheduling-eviction/kube-scheduler/#kube-scheduler) 主要负责将 Pod 调度到集群的 Node 上。 +作为 kubernetes 集群的默认调度器， +[kube-scheduler](/zh/docs/concepts/scheduling-eviction/kube-scheduler/#kube-scheduler) +主要负责将 Pod 调度到集群的 Node 上。 <!-- Nodes in a cluster that meet the scheduling requirements of a Pod are @@ -32,7 +32,10 @@ picking a Node with the highest score among the feasible ones to run the Pod. The scheduler then notifies the API server about this decision in a process called _Binding_. --> -在一个集群中，满足一个 Pod 调度请求的所有 Node 称之为 _可调度_ Node。调度器先在集群中找到一个 Pod 的可调度 Node，然后根据一系列函数对这些可调度 Node打分，之后选出其中得分最高的 Node 来运行 Pod。最后，调度器将这个调度决定告知 kube-apiserver，这个过程叫做 _绑定_。 +在一个集群中，满足一个 Pod 调度请求的所有 Node 称之为 _可调度_ Node。 +调度器先在集群中找到一个 Pod 的可调度 Node，然后根据一系列函数对这些可调度 Node 打分， +之后选出其中得分最高的 Node 来运行 Pod。 +最后，调度器将这个调度决定告知 kube-apiserver，这个过程叫做 _绑定（Binding）_。 <!-- This page explains performance tuning optimizations that are relevant for @@ -40,8 +43,6 @@ large Kubernetes clusters. --> 这篇文章将会介绍一些在大规模 Kubernetes 集群下调度器性能优化的方式。 - - <!-- body --> <!-- @@ -55,7 +56,8 @@ a threshold for scheduling nodes in your cluster. --> 在大规模集群中，你可以调节调度器的表现来平衡调度的延迟（新 Pod 快速就位）和精度（调度器很少做出糟糕的放置决策）。 -你可以通过设置 kube-scheduler 的 `percentageOfNodesToScore` 来配置这个调优设置。这个 KubeSchedulerConfiguration 设置决定了调度集群中节点的阈值。 +你可以通过设置 kube-scheduler 的 `percentageOfNodesToScore` 来配置这个调优设置。 +这个 KubeSchedulerConfiguration 设置决定了调度集群中节点的阈值。 <!-- ### Setting the threshold @@ -117,8 +119,11 @@ enough feasible nodes to exceed the configured percentage, the kube-scheduler stops searching for more feasible nodes and moves on to the [scoring phase](/docs/concepts/scheduling-eviction/kube-scheduler/#kube-scheduler-implementation). --> -你可以使用整个集群节点总数的百分比作为阈值来指定需要多少节点就足够。 kube-scheduler 会将它转换为节点数的整数值。在调度期间，如果 -kube-scheduler 已确认的可调度节点数足以超过了配置的百分比数量，kube-scheduler 将停止继续查找可调度节点并继续进行 [打分阶段](/docs/concepts/scheduling-eviction/kube-scheduler/#kube-scheduler-implementation)。 +你可以使用整个集群节点总数的百分比作为阈值来指定需要多少节点就足够。 +kube-scheduler 会将它转换为节点数的整数值。在调度期间，如果 +kube-scheduler 已确认的可调度节点数足以超过了配置的百分比数量， +kube-scheduler 将停止继续查找可调度节点并继续进行 +[打分阶段](/zh/docs/concepts/scheduling-eviction/kube-scheduler/#kube-scheduler-implementation)。 <!-- [How the scheduler iterates over Nodes](#how-the-scheduler-iterates-over-nodes) @@ -228,7 +233,7 @@ prefer to run the Pod on any Node as long as it is feasible. <!-- ### How the scheduler iterates over Nodes --> -### 调度器做调度选择的时候如何覆盖所有的 Node +### 调度器做调度选择的时候如何覆盖所有的 Node {#how-the-scheduler-iterates-over-nodes} <!-- This section is intended for those who want to understand the internal details diff --git a/content/zh/docs/concepts/configuration/taint-and-toleration.md b/content/zh/docs/concepts/scheduling-eviction/taint-and-toleration.md similarity index 52% rename from content/zh/docs/concepts/configuration/taint-and-toleration.md rename to content/zh/docs/concepts/scheduling-eviction/taint-and-toleration.md index 5e72941c25..1635c410d2 100755 --- a/content/zh/docs/concepts/configuration/taint-and-toleration.md +++ b/content/zh/docs/concepts/scheduling-eviction/taint-and-toleration.md @@ -1,45 +1,48 @@ --- -title: Taint 和 Toleration +title: 污点和容忍度 content_type: concept weight: 40 --- - <!-- overview --> <!-- Node affinity, described [here](/docs/concepts/configuration/assign-pod-node/#node-affinity-beta-feature), -is a property of *pods* that *attracts* them to a set of nodes (either as a -preference or a hard requirement). Taints are the opposite -- they allow a -*node* to *repel* a set of pods. +is a property of {{< glossary_tooltip text="Pods" term_id="pod" >}} that *attracts* them to +a set of {{< glossary_tooltip text="nodes" term_id="node" >}} (either as a preference or a +hard requirement). Taints are the opposite -they allow a node to repel a set of pods. --> -节点亲和性（详见[这里](/docs/concepts/configuration/assign-pod-node/#node-affinity-beta-feature)），是 *pod* 的一种属性（偏好或硬性要求），它使 *pod* 被吸引到一类特定的节点。Taint 则相反，它使 *节点* 能够 *排斥* 一类特定的 pod。 +节点亲和性（详见[这里](/zh/docs/concepts/scheduling-eviction/assign-pod-node/#affinity-and-anti-affinity)） +是 {{< glossary_tooltip text="Pod" term_id="pod" >}} 的一种属性，它使 Pod +被吸引到一类特定的{{< glossary_tooltip text="节点" term_id="node" >}}。 +这可能出于一种偏好，也可能是硬性要求。 +Taint（污点）则相反，它使节点能够排斥一类特定的 Pod。 <!-- +_Tolerations_ are applied to pods, and allow (but do not require) the pods to schedule +onto nodes with matching taints. + Taints and tolerations work together to ensure that pods are not scheduled onto inappropriate nodes. One or more taints are applied to a node; this marks that the node should not accept any pods that do not tolerate the taints. -Tolerations are applied to pods, and allow (but do not require) the pods to schedule -onto nodes with matching taints. --> -Taint 和 toleration 相互配合，可以用来避免 pod 被分配到不合适的节点上。每个节点上都可以应用一个或多个 taint ，这表示对于那些不能容忍这些 taint 的 pod，是不会被该节点接受的。如果将 toleration 应用于 pod 上，则表示这些 pod 可以（但不要求）被调度到具有匹配 taint 的节点上。 - +容忍度（Tolerations）是应用于 Pod 上的，允许（但并不要求）Pod +调度到带有与之匹配的污点的节点上。 +污点和容忍度（Toleration）相互配合，可以用来避免 Pod 被分配到不合适的节点上。 +每个节点上都可以应用一个或多个污点，这表示对于那些不能容忍这些污点的 Pod，是不会被该节点接受的。 <!-- body --> <!-- - ## Concepts - --> - ## 概念 <!-- You add a taint to a node using [kubectl taint](/docs/reference/generated/kubectl/kubectl-commands#taint). For example, --> -您可以使用命令 [kubectl taint](/docs/reference/generated/kubectl/kubectl-commands#taint) 给节点增加一个 taint。比如， +您可以使用命令 [kubectl taint](/docs/reference/generated/kubectl/kubectl-commands#taint) 给节点增加一个污点。比如， ```shell kubectl taint nodes node1 key=value:NoSchedule @@ -48,16 +51,25 @@ kubectl taint nodes node1 key=value:NoSchedule <!-- places a taint on node `node1`. The taint has key `key`, value `value`, and taint effect `NoSchedule`. This means that no pod will be able to schedule onto `node1` unless it has a matching toleration. -You specify a toleration for a pod in the PodSpec. Both of the following tolerations "match" the -taint created by the `kubectl taint` line above, and thus a pod with either toleration would be able -to schedule onto `node1`: ---> -给节点 `node1` 增加一个 taint，它的 key 是 `key`，value 是 `value`，effect 是 `NoSchedule`。这表示只有拥有和这个 taint 相匹配的 toleration 的 pod 才能够被分配到 `node1` 这个节点。您可以在 PodSpec 中定义 pod 的 toleration。下面两个 toleration 均与上面例子中使用 `kubectl taint` 命令创建的 taint 相匹配，因此如果一个 pod 拥有其中的任何一个 toleration 都能够被分配到 `node1` ： -<!-- +```shell +kubectl taint nodes node1 key:NoSchedule +``` + To remove the taint added by the command above, you can run: +```shell +kubectl taint nodes node1 key:NoSchedule- +``` --> -想删除上述命令添加的 taint ，您可以运行： +给节点 `node1` 增加一个污点，它的键名是 `key`，键值是 `value`，效果是 `NoSchedule`。 +这表示只有拥有和这个污点相匹配的容忍度的 Pod 才能够被分配到 `node1` 这个节点。 + +```shell +kubectl taint nodes node1 key:NoSchedule- +``` + +若要移除上述命令所添加的污点，你可以执行： + ```shell kubectl taint nodes node1 key:NoSchedule- ``` @@ -67,9 +79,9 @@ You specify a toleration for a pod in the PodSpec. Both of the following tolerat taint created by the `kubectl taint` line above, and thus a pod with either toleration would be able to schedule onto `node1`: --> - -您可以在 PodSpec 中为容器设定容忍标签。以下两个容忍标签都与上面的 `kubectl taint` 创建的污点“匹配”， -因此具有任一容忍标签的Pod都可以将其调度到 `node1` 上： +您可以在 PodSpec 中定义 Pod 的容忍度。 +下面两个容忍度均与上面例子中使用 `kubectl taint` 命令创建的污点相匹配， +因此如果一个 Pod 拥有其中的任何一个容忍度都能够被分配到 `node1` ： ```yaml tolerations: @@ -86,55 +98,55 @@ tolerations: effect: "NoSchedule" ``` +<!-- +Here’s an example of a pod that uses tolerations: +--> +这里是一个使用了容忍度的 Pod： + +{{< codenew file="pods/pod-with-toleration.yaml" >}} + +<!-- +The default value for `operator` is `Equal`. +--> +`operator` 的默认值是 `Equal`。 + <!-- A toleration "matches" a taint if the keys are the same and the effects are the same, and: * the `operator` is `Exists` (in which case no `value` should be specified), or * the `operator` is `Equal` and the `value`s are equal - -`Operator` defaults to `Equal` if not specified. --> -一个 toleration 和一个 taint 相“匹配”是指它们有一样的 key 和 effect ，并且： +一个容忍度和一个污点相“匹配”是指它们有一样的键名和效果，并且： -* 如果 `operator` 是 `Exists` （此时 toleration 不能指定 `value`），或者 +* 如果 `operator` 是 `Exists` （此时容忍度不能指定 `value`），或者 * 如果 `operator` 是 `Equal` ，则它们的 `value` 应该相等 -{{< note >}} <!-- There are two special cases: -* An empty `key` with operator `Exists` matches all keys, values and effects which means this +An empty `key` with operator `Exists` matches all keys, values and effects which means this will tolerate everything. ---> +An empty `effect` matches all effects with key `key`. +--> +{{< note >}} 存在两种特殊情况： -* 如果一个 toleration 的 `key` 为空且 operator 为 `Exists`，表示这个 toleration 与任意的 key 、value 和 effect 都匹配，即这个 toleration 能容忍任意 taint。 +如果一个容忍度的 `key` 为空且 operator 为 `Exists`， +表示这个容忍度与任意的 key 、value 和 effect 都匹配，即这个容忍度能容忍任意 taint。 -```yaml -tolerations: -- operator: "Exists" -``` - -<!-- -* An empty `effect` matches all effects with key `key`. ---> -* 如果一个 toleration 的 `effect` 为空，则 `key` 值与之相同的相匹配 taint 的 `effect` 可以是任意值。 - -```yaml -tolerations: -- key: "key" - operator: "Exists" -``` +如果 `effect` 为空，则可以与所有键名 `key` 的效果相匹配。 {{< /note >}} <!-- The above example used `effect` of `NoSchedule`. Alternatively, you can use `effect` of `PreferNoSchedule`. -This is a "preference" or "soft" version of `NoSchedule` -- the system will *try* to avoid placing a +This is a "preference" or "soft" version of `NoSchedule` - the system will *try* to avoid placing a pod that does not tolerate the taint on the node, but it is not required. The third kind of `effect` is `NoExecute`, described later. --> -上述例子使用到的 `effect` 的一个值 `NoSchedule`，您也可以使用另外一个值 `PreferNoSchedule`。这是“优化”或“软”版本的 `NoSchedule` ——系统会 *尽量* 避免将 pod 调度到存在其不能容忍 taint 的节点上，但这不是强制的。`effect` 的值还可以设置为 `NoExecute`，下文会详细描述这个值。 +上述例子使用到的 `effect` 的一个值 `NoSchedule`，您也可以使用另外一个值 `PreferNoSchedule`。 +这是“优化”或“软”版本的 `NoSchedule` —— 系统会 *尽量* 避免将 Pod 调度到存在其不能容忍污点的节点上， +但这不是强制的。`effect` 的值还可以设置为 `NoExecute`，下文会详细描述这个值。 <!-- You can put multiple taints on the same node and multiple tolerations on the same pod. @@ -142,7 +154,10 @@ The way Kubernetes processes multiple taints and tolerations is like a filter: s with all of a node's taints, then ignore the ones for which the pod has a matching toleration; the remaining un-ignored taints have the indicated effects on the pod. In particular, --> -您可以给一个节点添加多个 taint ，也可以给一个 pod 添加多个 toleration。Kubernetes 处理多个 taint 和 toleration 的过程就像一个过滤器：从一个节点的所有 taint 开始遍历，过滤掉那些 pod 中存在与之相匹配的 toleration 的 taint。余下未被过滤的 taint 的 effect 值决定了 pod 是否会被分配到该节点，特别是以下情况： +您可以给一个节点添加多个污点，也可以给一个 Pod 添加多个容忍度设置。 +Kubernetes 处理多个污点和容忍度的过程就像一个过滤器：从一个节点的所有污点开始遍历， +过滤掉那些 Pod 中存在与之相匹配的容忍度的污点。余下未被过滤的污点的 effect 值决定了 +Pod 是否会被分配到该节点，特别是以下情况： <!-- @@ -154,14 +169,19 @@ effect `PreferNoSchedule` then Kubernetes will *try* to not schedule the pod ont the node (if it is already running on the node), and will not be scheduled onto the node (if it is not yet running on the node). --> -* 如果未被过滤的 taint 中存在一个以上 effect 值为 `NoSchedule` 的 taint，则 Kubernetes 不会将 pod 分配到该节点。 -* 如果未被过滤的 taint 中不存在 effect 值为 `NoSchedule` 的 taint，但是存在 effect 值为 `PreferNoSchedule` 的 taint，则 Kubernetes 会 *尝试* 将 pod 分配到该节点。 -* 如果未被过滤的 taint 中存在一个以上 effect 值为 `NoExecute` 的 taint，则 Kubernetes 不会将 pod 分配到该节点（如果 pod 还未在节点上运行），或者将 pod 从该节点驱逐（如果 pod 已经在节点上运行）。 +* 如果未被过滤的污点中存在至少一个 effect 值为 `NoSchedule` 的污点， + 则 Kubernetes 不会将 Pod 分配到该节点。 +* 如果未被过滤的污点中不存在 effect 值为 `NoSchedule` 的污点， + 但是存在 effect 值为 `PreferNoSchedule` 的污点， + 则 Kubernetes 会 *尝试* 将 Pod 分配到该节点。 +* 如果未被过滤的污点中存在至少一个 effect 值为 `NoExecute` 的污点， + 则 Kubernetes 不会将 Pod 分配到该节点（如果 Pod 还未在节点上运行）， + 或者将 Pod 从该节点驱逐（如果 Pod 已经在节点上运行）。 <!-- For example, imagine you taint a node like this --> -例如，假设您给一个节点添加了如下的 taint +例如，假设您给一个节点添加了如下污点 ```shell kubectl taint nodes node1 key1=value1:NoSchedule @@ -172,7 +192,7 @@ kubectl taint nodes node1 key2=value2:NoSchedule <!-- And a pod has two tolerations: --> -然后存在一个 pod，它有两个 toleration： +假定有一个 Pod，它有两个容忍度： ```yaml tolerations: @@ -192,7 +212,9 @@ toleration matching the third taint. But it will be able to continue running if already running on the node when the taint is added, because the third taint is the only one of the three that is not tolerated by the pod. --> -在这个例子中，上述 pod 不会被分配到上述节点，因为其没有 toleration 和第三个 taint 相匹配。但是如果在给节点添加上述 taint 之前，该 pod 已经在上述节点运行，那么它还可以继续运行在该节点上，因为第三个 taint 是三个 taint 中唯一不能被这个 pod 容忍的。 +在这种情况下，上述 Pod 不会被分配到上述节点，因为其没有容忍度和第三个污点相匹配。 +但是如果在给节点添加上述污点之前，该 Pod 已经在上述节点运行， +那么它还可以继续运行在该节点上，因为第三个污点是三个污点中唯一不能被这个 Pod 容忍的。 <!-- Normally, if a taint with effect `NoExecute` is added to a node, then any pods that do @@ -201,7 +223,12 @@ taint will never be evicted. However, a toleration with `NoExecute` effect can s an optional `tolerationSeconds` field that dictates how long the pod will stay bound to the node after the taint is added. For example, --> -通常情况下，如果给一个节点添加了一个 effect 值为 `NoExecute` 的 taint，则任何不能忍受这个 taint 的 pod 都会马上被驱逐，任何可以忍受这个 taint 的 pod 都不会被驱逐。但是，如果 pod 存在一个 effect 值为 `NoExecute` 的 toleration 指定了可选属性 `tolerationSeconds` 的值，则表示在给节点添加了上述 taint 之后，pod 还能继续在节点上运行的时间。例如， +通常情况下，如果给一个节点添加了一个 effect 值为 `NoExecute` 的污点， +则任何不能忍受这个污点的 Pod 都会马上被驱逐， +任何可以忍受这个污点的 Pod 都不会被驱逐。 +但是，如果 Pod 存在一个 effect 值为 `NoExecute` 的容忍度指定了可选属性 +`tolerationSeconds` 的值，则表示在给节点添加了上述污点之后， +Pod 还能继续在节点上运行的时间。例如， ```yaml tolerations: @@ -217,24 +244,22 @@ means that if this pod is running and a matching taint is added to the node, the the pod will stay bound to the node for 3600 seconds, and then be evicted. If the taint is removed before that time, the pod will not be evicted. --> -这表示如果这个 pod 正在运行，然后一个匹配的 taint 被添加到其所在的节点，那么 pod 还将继续在节点上运行 3600 秒，然后被驱逐。如果在此之前上述 taint 被删除了，则 pod 不会被驱逐。 +这表示如果这个 Pod 正在运行，同时一个匹配的污点被添加到其所在的节点， +那么 Pod 还将继续在节点上运行 3600 秒，然后被驱逐。 +如果在此之前上述污点被删除了，则 Pod 不会被驱逐。 <!-- - ## Example Use Cases - --> - ## 使用例子 <!-- Taints and tolerations are a flexible way to steer pods *away* from nodes or evict pods that shouldn't be running. A few of the use cases are --> -通过 taint 和 toleration，可以灵活地让 pod *避开* 某些节点或者将 pod 从某些节点驱逐。下面是几个使用例子： +通过污点和容忍度，可以灵活地让 Pod *避开* 某些节点或者将 Pod 从某些节点驱逐。下面是几个使用例子： <!-- - * **Dedicated Nodes**: If you want to dedicate a set of nodes for exclusive use by a particular set of users, you can add a taint to those nodes (say, `kubectl taint nodes nodename dedicated=groupName:NoSchedule`) and then add a corresponding @@ -247,11 +272,16 @@ to the taint to the same set of nodes (e.g. `dedicated=groupName`), and the admi controller should additionally add a node affinity to require that the pods can only schedule onto nodes labeled with `dedicated=groupName`. --> -* **专用节点**：如果您想将某些节点专门分配给特定的一组用户使用，您可以给这些节点添加一个 taint（即， - `kubectl taint nodes nodename dedicated=groupName:NoSchedule`），然后给这组用户的 pod 添加一个相对应的 toleration（通过编写一个自定义的 [admission controller](/docs/admin/admission-controllers/)，很容易就能做到）。拥有上述 toleration 的 pod 就能够被分配到上述专用节点，同时也能够被分配到集群中的其它节点。如果您希望这些 pod 只能被分配到上述专用节点，那么您还需要给这些专用节点另外添加一个和上述 taint 类似的 label （例如：`dedicated=groupName`），同时 还要在上述 admission controller 中给 pod 增加节点亲和性要求上述 pod 只能被分配到添加了 `dedicated=groupName` 标签的节点上。 +* **专用节点**：如果您想将某些节点专门分配给特定的一组用户使用，您可以给这些节点添加一个污点（即， + `kubectl taint nodes nodename dedicated=groupName:NoSchedule`）， + 然后给这组用户的 Pod 添加一个相对应的 toleration（通过编写一个自定义的 + [准入控制器](/zh/docs/reference/access-authn-authz/admission-controllers/)，很容易就能做到）。 + 拥有上述容忍度的 Pod 就能够被分配到上述专用节点，同时也能够被分配到集群中的其它节点。 + 如果您希望这些 Pod 只能被分配到上述专用节点，那么您还需要给这些专用节点另外添加一个和上述 + 污点类似的 label （例如：`dedicated=groupName`），同时 还要在上述准入控制器中给 Pod + 增加节点亲和性要求上述 Pod 只能被分配到添加了 `dedicated=groupName` 标签的节点上。 <!-- - * **Nodes with Special Hardware**: In a cluster where a small subset of nodes have specialized hardware (for example GPUs), it is desirable to keep pods that don't need the specialized hardware off of those nodes, thus leaving room for later-arriving pods that do need the @@ -274,27 +304,39 @@ on the special hardware nodes. This will make sure that these special hardware nodes are dedicated for pods requesting such hardware and you don't have to manually add tolerations to your pods. --> -* **配备了特殊硬件的节点**：在部分节点配备了特殊硬件（比如 GPU）的集群中，我们希望不需要这类硬件的 pod 不要被分配到这些特殊节点，以便为后继需要这类硬件的 pod 保留资源。要达到这个目的，可以先给配备了特殊硬件的节点添加 taint（例如 `kubectl taint nodes nodename special=true:NoSchedule` or `kubectl taint nodes nodename special=true:PreferNoSchedule`)，然后给使用了这类特殊硬件的 pod 添加一个相匹配的 toleration。和专用节点的例子类似，添加这个 toleration 的最简单的方法是使用自定义 [admission controller](/docs/reference/access-authn-authz/admission-controllers/)。比如，我们推荐使用 [Extended Resources](/docs/concepts/configuration/manage-compute-resources-container/#extended-resources) 来表示特殊硬件，给配置了特殊硬件的节点添加 taint 时包含 extended resource 名称，然后运行一个 [ExtendedResourceToleration](/docs/reference/access-authn-authz/admission-controllers/#extendedresourcetoleration) admission controller。此时，因为节点已经被 taint 了，没有对应 toleration 的 Pod 会被调度到这些节点。但当你创建一个使用了 extended resource 的 Pod 时，`ExtendedResourceToleration` admission controller 会自动给 Pod 加上正确的 toleration ，这样 Pod 就会被自动调度到这些配置了特殊硬件件的节点上。这样就能够确保这些配置了特殊硬件的节点专门用于运行 需要使用这些硬件的 Pod，并且您无需手动给这些 Pod 添加 toleration。 +* **配备了特殊硬件的节点**：在部分节点配备了特殊硬件（比如 GPU）的集群中， + 我们希望不需要这类硬件的 Pod 不要被分配到这些特殊节点，以便为后继需要这类硬件的 Pod 保留资源。 + 要达到这个目的，可以先给配备了特殊硬件的节点添加 taint + （例如 `kubectl taint nodes nodename special=true:NoSchedule` 或 + `kubectl taint nodes nodename special=true:PreferNoSchedule`)， + 然后给使用了这类特殊硬件的 Pod 添加一个相匹配的 toleration。 + 和专用节点的例子类似，添加这个容忍度的最简单的方法是使用自定义 + [准入控制器](/zh/docs/reference/access-authn-authz/admission-controllers/)。 + 比如，我们推荐使用[扩展资源](/zh/docs/concepts/configuration/manage-resources-containers/#extended-resources) + 来表示特殊硬件，给配置了特殊硬件的节点添加污点时包含扩展资源名称， + 然后运行一个 [ExtendedResourceToleration](/zh/docs/reference/access-authn-authz/admission-controllers/#extendedresourcetoleration) + 准入控制器。此时，因为节点已经被设置污点了，没有对应容忍度的 Pod + 会被调度到这些节点。但当你创建一个使用了扩展资源的 Pod 时， + `ExtendedResourceToleration` 准入控制器会自动给 Pod 加上正确的容忍度， + 这样 Pod 就会被自动调度到这些配置了特殊硬件件的节点上。 + 这样就能够确保这些配置了特殊硬件的节点专门用于运行需要使用这些硬件的 Pod， + 并且您无需手动给这些 Pod 添加容忍度。 <!-- - * **Taint based Evictions**: A per-pod-configurable eviction behavior when there are node problems, which is described in the next section. --> -* **基于 taint 的驱逐**: 这是在每个 pod 中配置的在节点出现问题时的驱逐行为，接下来的章节会描述这个特性 +* **基于污点的驱逐**: 这是在每个 Pod 中配置的在节点出现问题时的驱逐行为，接下来的章节会描述这个特性。 <!-- - ## Taint based Evictions - --> - -## 基于 taint 的驱逐 +## 基于污点的驱逐 {#taint-based-evictions} {{< feature-state for_k8s_version="v1.18" state="stable" >}} <!-- -Earlier we mentioned the `NoExecute` taint effect, which affects pods that are already +The `NoExecute` taint effect, which affects pods that are already running on the node as follows * pods that do not tolerate the taint are evicted immediately @@ -303,16 +345,17 @@ running on the node as follows * pods that tolerate the taint with a specified `tolerationSeconds` remain bound for the specified amount of time --> - 前文我们提到过 taint 的 effect 值 `NoExecute` ，它会影响已经在节点上运行的 pod +前文提到过污点的 effect 值 `NoExecute`会影响已经在节点上运行的 Pod - * 如果 pod 不能忍受 effect 值为 `NoExecute` 的 taint，那么 pod 将马上被驱逐 - * 如果 pod 能够忍受 effect 值为 `NoExecute` 的 taint，但是在 toleration 定义中没有指定 `tolerationSeconds`，则 pod 还会一直在这个节点上运行。 - * 如果 pod 能够忍受 effect 值为 `NoExecute` 的 taint，而且指定了 `tolerationSeconds`，则 pod 还能在这个节点上继续运行这个指定的时间长度。 + * 如果 Pod 不能忍受 effect 值为 `NoExecute` 的污点，那么 Pod 将马上被驱逐 + * 如果 Pod 能够忍受 effect 值为 `NoExecute` 的污点，但是在容忍度定义中没有指定 + `tolerationSeconds`，则 Pod 还会一直在这个节点上运行。 + * 如果 Pod 能够忍受 effect 值为 `NoExecute` 的污点，而且指定了 `tolerationSeconds`， + 则 Pod 还能在这个节点上继续运行这个指定的时间长度。 <!-- -In addition, Kubernetes 1.6 introduced alpha support for representing node -problems. In other words, the node controller automatically taints a node when -certain condition is true. The following taints are built in: +The node controller automatically taints a node when certain conditions are +true. The following taints are built in: * `node.kubernetes.io/not-ready`: Node is not ready. This corresponds to the NodeCondition `Ready` being "`False`". @@ -328,40 +371,46 @@ certain condition is true. The following taints are built in: as unusable. After a controller from the cloud-controller-manager initializes this node, the kubelet removes this taint. --> - 此外，Kubernetes 1.6 已经支持（alpha阶段）节点问题的表示。换句话说，当某种条件为真时，node controller会自动给节点添加一个 taint。当前内置的 taint 包括： +当某种条件为真时，节点控制器会自动给节点添加一个污点。当前内置的污点包括： * `node.kubernetes.io/not-ready`：节点未准备好。这相当于节点状态 `Ready` 的值为 "`False`"。 - * `node.kubernetes.io/unreachable`：node controller 访问不到节点. 这相当于节点状态 `Ready` 的值为 "`Unknown`"。 + * `node.kubernetes.io/unreachable`：节点控制器访问不到节点. 这相当于节点状态 `Ready` 的值为 "`Unknown`"。 * `node.kubernetes.io/out-of-disk`：节点磁盘耗尽。 * `node.kubernetes.io/memory-pressure`：节点存在内存压力。 * `node.kubernetes.io/disk-pressure`：节点存在磁盘压力。 * `node.kubernetes.io/network-unavailable`：节点网络不可用。 * `node.kubernetes.io/unschedulable`: 节点不可调度。 - * `node.cloudprovider.kubernetes.io/uninitialized`：如果 kubelet 启动时指定了一个 "外部" cloud provider，它将给当前节点添加一个 taint 将其标志为不可用。在 cloud-controller-manager 的一个 controller 初始化这个节点后，kubelet 将删除这个 taint。 + * `node.cloudprovider.kubernetes.io/uninitialized`：如果 kubelet 启动时指定了一个 "外部" 云平台驱动， + 它将给当前节点添加一个污点将其标志为不可用。在 cloud-controller-manager + 的一个控制器初始化这个节点后，kubelet 将删除这个污点。 <!-- In case a node is to be evicted, the node controller or the kubelet adds relevant taints with `NoExecute` effect. If the fault condition returns to normal the kubelet or node controller can remove the relevant taint(s). --> -在节点被驱逐时，节点控制器或者 kubelet 会添加带有 `NoExecute` 效应的相关污点。如果异常状态恢复正常，kubelet 或节点控制器能够移除相关的污点。 +在节点被驱逐时，节点控制器或者 kubelet 会添加带有 `NoExecute` 效应的相关污点。 +如果异常状态恢复正常，kubelet 或节点控制器能够移除相关的污点。 - -{{< note >}} <!-- To maintain the existing [rate limiting](/docs/concepts/architecture/nodes/) behavior of pod evictions due to node problems, the system actually adds the taints in a rate-limited way. This prevents massive pod evictions in scenarios such as the master becoming partitioned from the nodes. --> -为了保证由于节点问题引起的 pod 驱逐[rate limiting](/docs/concepts/architecture/nodes/)行为正常，系统实际上会以 rate-limited 的方式添加 taint。在像 master 和 node 通讯中断等场景下，这避免了 pod 被大量驱逐。 +{{< note >}} +为了保证由于节点问题引起的 Pod 驱逐 +[速率限制](/zh/docs/concepts/architecture/nodes/)行为正常， +系统实际上会以限定速率的方式添加污点。在像主控节点与工作节点间通信中断等场景下， +这样做可以避免 Pod 被大量驱逐。 {{< /note >}} <!-- This feature, in combination with `tolerationSeconds`, allows a pod to specify how long it should stay bound to a node that has one or both of these problems. --> -使用这个功能特性，结合 `tolerationSeconds`，pod 就可以指定当节点出现一个或全部上述问题时还将在这个节点上运行多长的时间。 +使用这个功能特性，结合 `tolerationSeconds`，Pod 就可以指定当节点出现一个 +或全部上述问题时还将在这个节点上运行多长的时间。 <!-- For example, an application with a lot of local state might want to stay @@ -369,7 +418,8 @@ bound to node for a long time in the event of network partition, in the hope that the partition will recover and thus the pod eviction can be avoided. The toleration the pod would use in that case would look like --> -比如，一个使用了很多本地状态的应用程序在网络断开时，仍然希望停留在当前节点上运行一段较长的时间，愿意等待网络恢复以避免被驱逐。在这种情况下，pod 的 toleration 可能是下面这样的： +比如，一个使用了很多本地状态的应用程序在网络断开时，仍然希望停留在当前节点上运行一段较长的时间， +愿意等待网络恢复以避免被驱逐。在这种情况下，Pod 的容忍度可能是下面这样的： ```yaml tolerations: @@ -389,17 +439,23 @@ Likewise it adds a toleration for unless the pod configuration provided by the user already has a toleration for `node.kubernetes.io/unreachable`. --> -注意，Kubernetes 会自动给 pod 添加一个 key 为 `node.kubernetes.io/not-ready` 的 toleration 并配置 `tolerationSeconds=300`，除非用户提供的 pod 配置中已经已存在了 key 为 `node.kubernetes.io/not-ready` 的 toleration。同样，Kubernetes 会给 pod 添加一个 key 为 `node.kubernetes.io/unreachable` 的 toleration 并配置 `tolerationSeconds=300`，除非用户提供的 pod 配置中已经已存在了 key 为 `node.kubernetes.io/unreachable` 的 toleration。 + +{{< note >}} +Kubernetes 会自动给 Pod 添加一个 key 为 `node.kubernetes.io/not-ready` 的容忍度 +并配置 `tolerationSeconds=300`，除非用户提供的 Pod 配置中已经已存在了 key 为 +`node.kubernetes.io/not-ready` 的容忍度。 + +同样，Kubernetes 会给 Pod 添加一个 key 为 `node.kubernetes.io/unreachable` 的容忍度 +并配置 `tolerationSeconds=300`，除非用户提供的 Pod 配置中已经已存在了 key 为 +`node.kubernetes.io/unreachable` 的容忍度。 +{{< /note >}} <!-- -These automatically-added tolerations ensure that -the default pod behavior of remaining bound for 5 minutes after one of these -problems is detected is maintained. -The two default tolerations are added by the [DefaultTolerationSeconds -admission controller](https://git.k8s.io/kubernetes/plugin/pkg/admission/defaulttolerationseconds). +These automatically-added tolerations mean that Pods remain bound to +Nodes for 5 minutes after one of these problems is detected. --> -这种自动添加 toleration 机制保证了在其中一种问题被检测到时 pod 默认能够继续停留在当前节点运行 5 分钟。这两个默认 toleration 是由 [DefaultTolerationSeconds -admission controller](https://git.k8s.io/kubernetes/plugin/pkg/admission/defaulttolerationseconds)添加的。 +这种自动添加的容忍度意味着在其中一种问题被检测到时 Pod +默认能够继续停留在当前节点运行 5 分钟。 <!-- [DaemonSet](/docs/concepts/workloads/controllers/daemonset/) pods are created with @@ -410,24 +466,25 @@ admission controller](https://git.k8s.io/kubernetes/plugin/pkg/admission/default This ensures that DaemonSet pods are never evicted due to these problems. --> -[DaemonSet](/docs/concepts/workloads/controllers/daemonset/) 中的 pod 被创建时，针对以下 taint 自动添加的 `NoExecute` 的 toleration 将不会指定 `tolerationSeconds`： +[DaemonSet](/zh/docs/concepts/workloads/controllers/daemonset/) 中的 Pod 被创建时， +针对以下污点自动添加的 `NoExecute` 的容忍度将不会指定 `tolerationSeconds`： * `node.kubernetes.io/unreachable` * `node.kubernetes.io/not-ready` -这保证了出现上述问题时 DaemonSet 中的 pod 永远不会被驱逐。 +这保证了出现上述问题时 DaemonSet 中的 Pod 永远不会被驱逐。 <!-- ## Taint Nodes by Condition --> - -## 基于节点状态添加 taint +## 基于节点状态添加污点 <!-- -The node lifecycle controller automatically creates taints corresponding to Node conditions with `NoSchedule` effect. +The node lifecycle controller automatically creates taints corresponding to +Node conditions with `NoSchedule` effect. Similarly the scheduler does not check Node conditions; instead the scheduler checks taints. This assures that Node conditions don't affect what's scheduled onto the Node. The user can choose to ignore some of the Node's problems (represented as Node conditions) by adding appropriate Pod tolerations. -Starting in Kubernetes 1.8, the DaemonSet controller automatically adds the +The DaemonSet controller automatically adds the following `NoSchedule` tolerations to all daemons, to prevent DaemonSets from breaking. @@ -438,19 +495,31 @@ breaking. * `node.kubernetes.io/network-unavailable` (*host network only*) --> Node 生命周期控制器会自动创建与 Node 条件相对应的带有 `NoSchedule` 效应的污点。 -同样，调度器不检查节点条件，而是检查节点污点。这确保了节点条件不会影响调度到节点上的内容。用户可以通过添加适当的 Pod 容忍度来选择忽略某些 Node 的问题(表示为 Node 的调度条件)。 +同样，调度器不检查节点条件，而是检查节点污点。这确保了节点条件不会影响调度到节点上的内容。 +用户可以通过添加适当的 Pod 容忍度来选择忽略某些 Node 的问题(表示为 Node 的调度条件)。 -自 Kubernetes 1.8 起， DaemonSet 控制器自动为所有守护进程添加如下 `NoSchedule` toleration 以防 DaemonSet 崩溃： +DaemonSet 控制器自动为所有守护进程添加如下 `NoSchedule` 容忍度以防 DaemonSet 崩溃： * `node.kubernetes.io/memory-pressure` * `node.kubernetes.io/disk-pressure` - * `node.kubernetes.io/out-of-disk` (*只适合 critical pod*) + * `node.kubernetes.io/out-of-disk` (*只适合关键 Pod*) * `node.kubernetes.io/unschedulable` (1.10 或更高版本) - * `node.kubernetes.io/network-unavailable` (*只适合 host network*) + * `node.kubernetes.io/network-unavailable` (*只适合主机网络配置*) <!-- Adding these tolerations ensures backward compatibility. You can also add arbitrary tolerations to DaemonSets. --> -添加上述 toleration 确保了向后兼容，您也可以选择自由的向 DaemonSet 添加 toleration。 +添加上述容忍度确保了向后兼容，您也可以选择自由向 DaemonSet 添加容忍度。 + +## {{% heading "whatsnext" %}} + +<!-- +* Read about [out of resource handling](/docs/tasks/administer-cluster/out-of-resource/) and how you can configure it +* Read about [pod priority](/docs/concepts/configuration/pod-priority-preemption/) +--> +* 阅读[资源耗尽的处理](/zh/docs/tasks/administer-cluster/out-of-resource/)，以及如何配置其行为 +* 阅读 [Pod 优先级](/zh/docs/concepts/configuration/pod-priority-preemption/) + + diff --git a/content/zh/docs/concepts/services-networking/connect-applications-service.md b/content/zh/docs/concepts/services-networking/connect-applications-service.md index d49d61294b..25bebe4d01 100644 --- a/content/zh/docs/concepts/services-networking/connect-applications-service.md +++ b/content/zh/docs/concepts/services-networking/connect-applications-service.md @@ -1,10 +1,9 @@ --- -title: 应用连接到 Service +title: 使用 Service 连接到应用 content_type: concept weight: 30 --- - <!-- overview --> <!-- @@ -24,8 +23,6 @@ This guide uses a simple nginx server to demonstrate proof of concept. The same 既然有了一个持续运行、可复制的应用，我们就能够将它暴露到网络上。 在讨论 Kubernetes 网络连接的方式之前，非常值得与 Docker 中 “正常” 方式的网络进行对比。 - - 默认情况下，Docker 使用私有主机网络连接，只能与同在一台机器上的容器进行通信。 为了实现容器的跨节点通信，必须在机器自己的 IP 上为这些容器分配端口，为容器进行端口转发或者代理。 @@ -35,10 +32,8 @@ Kubernetes 假设 Pod 可与其它 Pod 通信，不管它们在哪个主机上 这表明了在 Pod 内的容器都能够连接到本地的每个端口，集群中的所有 Pod 不需要通过 NAT 转换就能够互相看到。 文档的剩余部分将详述如何在一个网络模型之上运行可靠的服务。 -该指南使用一个简单的 Nginx server 来演示并证明谈到的概念。同样的原则也体现在一个更加完整的 [Jenkins CI 应用](http://kubernetes.io/blog/2015/07/strong-simple-ssl-for-kubernetes.html) 中。 - - - +该指南使用一个简单的 Nginx server 来演示并证明谈到的概念。同样的原则也体现在一个更加完整的 +[Jenkins CI 应用](https://kubernetes.io/blog/2015/07/strong-simple-ssl-for-kubernetes.html) 中。 <!-- body --> @@ -48,7 +43,6 @@ Kubernetes 假设 Pod 可与其它 Pod 通信，不管它们在哪个主机上 We did this in a previous example, but let's do it once again and focus on the networking perspective. Create an nginx Pod, and note that it has a container port specification: --> - ## 在集群中暴露 Pod 我们在之前的示例中已经做过，然而再让我重试一次，这次聚焦在网络连接的视角。 @@ -75,7 +69,6 @@ my-nginx-3800858182-kna2y 1/1 Running 0 13s 10.244.2.5 <!-- Check your pods' IPs: --> - 检查 Pod 的 IP 地址： ```shell @@ -89,14 +82,12 @@ You should be able to ssh into any node in your cluster and curl both IPs. Note You can read more about [how we achieve this](/docs/concepts/cluster-administration/networking/#how-to-achieve-this) if you're curious. --> - 应该能够通过 ssh 登录到集群中的任何一个节点上，使用 curl 也能调通所有 IP 地址。 需要注意的是，容器不会使用该节点上的 80 端口，也不会使用任何特定的 NAT 规则去路由流量到 Pod 上。 这意味着可以在同一个节点上运行多个 Pod，使用相同的容器端口，并且可以从集群中任何其他的 Pod 或节点上使用 IP 的方式访问到它们。 像 Docker 一样，端口能够被发布到主机节点的接口上，但是出于网络模型的原因应该从根本上减少这种用法。 -如果对此好奇，可以获取更多关于 [如何实现网络模型](/docs/concepts/cluster-administration/networking/#how-to-achieve-this) 的内容。 - +如果对此好奇，可以获取更多关于 [如何实现网络模型](/zh/docs/concepts/cluster-administration/networking/#how-to-achieve-this) 的内容。 <!-- ## Creating a Service @@ -107,7 +98,6 @@ A Kubernetes Service is an abstraction which defines a logical set of Pods runni You can create a Service for your 2 nginx replicas with `kubectl expose`: --> - ## 创建 Service 我们有 Pod 在一个扁平的、集群范围的地址空间中运行 Nginx 服务，可以直接连接到这些 Pod，但如果某个节点死掉了会发生什么呢？ @@ -145,9 +135,11 @@ View [Service](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/ API object to see the list of supported fields in service definition. Check your Service: --> - -上述规约将创建一个 Service，对应具有标签 `run: my-nginx` 的 Pod，目标 TCP 端口 80，并且在一个抽象的 Service 端口（`targetPort`：容器接收流量的端口；`port`：抽象的 Service 端口，可以使任何其它 Pod 访问该 Service 的端口）上暴露。 -查看 [Service API 对象](/docs/api-reference/{{< param "version" >}}/#service-v1-core) 了解 Service 定义支持的字段列表。 +上述规约将创建一个 Service，对应具有标签 `run: my-nginx` 的 Pod，目标 TCP 端口 80， +并且在一个抽象的 Service 端口（`targetPort`：容器接收流量的端口；`port`：抽象的 Service +端口，可以使任何其它 Pod 访问该 Service 的端口）上暴露。 +查看 [Service API 对象](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#service-v1-core) +了解 Service 定义支持的字段列表。 查看你的 Service 资源: ```shell @@ -167,7 +159,6 @@ matching the Service's selector will automatically get added to the endpoints. Check the endpoints, and note that the IPs are the same as the Pods created in the first step: --> - 正如前面所提到的，一个 Service 由一组 backend Pod 组成。这些 Pod 通过 `endpoints` 暴露出来。 Service Selector 将持续评估，结果被 POST 到一个名称为 `my-nginx` 的 Endpoint 对象上。 当 Pod 终止后，它会自动从 Endpoint 中移除，新的能够匹配上 Service Selector 的 Pod 将自动地被添加到 Endpoint 中。 @@ -206,7 +197,8 @@ about the [service proxy](/docs/concepts/services-networking/service/#virtual-ip 现在，能够从集群中任意节点上使用 curl 命令请求 Nginx Service `<CLUSTER-IP>:<PORT>` 。 注意 Service IP 完全是虚拟的，它从来没有走过网络，如果对它如何工作的原理感到好奇， -可以阅读更多关于 [服务代理](/docs/user-guide/services/#virtual-ips-and-service-proxies) 的内容。 +可以进一步阅读[服务代理](/zh/docs/concepts/services-networking/service/#virtual-ips-and-service-proxies) +的内容。 <!-- ## Accessing the Service @@ -219,22 +211,19 @@ and DNS. The former works out of the box while the latter requires the ## 访问 Service Kubernetes支持两种查找服务的主要模式: 环境变量和DNS。 前者开箱即用，而后者则需要[CoreDNS集群插件] -[CoreDNS 集群插件](http://releases.k8s.io/{{< param "githubbranch" >}}/cluster/addons/dns/coredns). - -{{< note >}} +[CoreDNS 集群插件](https://releases.k8s.io/{{< param "githubbranch" >}}/cluster/addons/dns/coredns). <!-- If the service environment variables are not desired (because possible clashing with expected program ones, too many variables to process, only using DNS, etc) you can disable this mode by setting the `enableServiceLinks` flag to `false` on the [pod spec](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#pod-v1-core). --> - +{{< note >}} 如果不需要服务环境变量（因为可能与预期的程序冲突，可能要处理的变量太多，或者仅使用DNS等），则可以通过在 -[pod spec](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#pod-v1-core)上将 `enableServiceLinks` 标志设置为 `false` 来禁用此模式。 - +[pod spec](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#pod-v1-core) +上将 `enableServiceLinks` 标志设置为 `false` 来禁用此模式。 {{< /note >}} - <!-- ### Environment Variables @@ -324,9 +313,10 @@ The rest of this section will assume you have a Service with a long lived IP cluster addon), so you can talk to the Service from any pod in your cluster using standard methods (e.g. gethostbyname). Let's run another curl application to test this: --> - -如果没有在运行，可以 [启用它](http://releases.k8s.io/{{< param "githubbranch" >}}/cluster/addons/dns/kube-dns/README.md#how-do-i-configure-it)。 -本段剩余的内容，将假设已经有一个 Service，它具有一个长久存在的 IP（my-nginx），一个为该 IP 指派名称的 DNS 服务器（kube-dns 集群插件），所以可以通过标准做法，使在集群中的任何 Pod 都能与该 Service 通信（例如：gethostbyname）。 +如果没有在运行，可以[启用它](https://releases.k8s.io/{{< param "githubbranch" >}}/cluster/addons/dns/kube-dns/README.md#how-do-i-configure-it)。 +本段剩余的内容，将假设已经有一个 Service，它具有一个长久存在的 IP（my-nginx）， +一个为该 IP 指派名称的 DNS 服务器（kube-dns 集群插件），所以可以通过标准做法， +使在集群中的任何 Pod 都能与该 Service 通信（例如：gethostbyname）。 让我们运行另一个 curl 应用来进行测试： ```shell @@ -370,9 +360,10 @@ You can acquire all these from the [nginx https example](https://github.com/kube * https 自签名证书（除非已经有了一个识别身份的证书） * 使用证书配置的 Nginx server -* 使证书可以访问 Pod 的[秘钥](/docs/user-guide/secrets) +* 使证书可以访问 Pod 的 [Secret](/zh/docs/concepts/configuration/secret/) -可以从 [Nginx https 示例](https://github.com/kubernetes/kubernetes/tree/{{< param "githubbranch" >}}/examples/https-nginx/) 获取所有上述内容，简明示例如下： +可以从 [Nginx https 示例](https://github.com/kubernetes/kubernetes/tree/{{< param "githubbranch" >}}/examples/https-nginx/) +获取所有上述内容，简明示例如下： ```shell make keys KEY=/tmp/nginx.key CERT=/tmp/nginx.crt @@ -456,7 +447,8 @@ Noteworthy points about the nginx-secure-app manifest: 关于 nginx-secure-app manifest 值得注意的点如下： - 它在相同的文件中包含了 Deployment 和 Service 的规格 -- [Nginx server](https://github.com/kubernetes/kubernetes/tree/{{< param "githubbranch" >}}/examples/https-nginx/default.conf) 处理 80 端口上的 http 流量，以及 443 端口上的 https 流量，Nginx Service 暴露了这两个端口。 +- [Nginx 服务器](https://github.com/kubernetes/kubernetes/tree/{{< param "githubbranch" >}}/examples/https-nginx/default.conf) + 处理 80 端口上的 http 流量，以及 443 端口上的 https 流量，Nginx Service 暴露了这两个端口。 - 每个容器访问挂载在 /etc/nginx/ssl 卷上的秘钥。这需要在 Nginx server 启动之前安装好。 ```shell @@ -483,7 +475,8 @@ so we have to tell curl to ignore the CName mismatch. By creating a Service we l Let's test this from a pod (the same secret is being reused for simplicity, the pod only needs nginx.crt to access the Service): --> -注意最后一步我们是如何提供 `-k` 参数执行 curl命令的，这是因为在证书生成时，我们不知道任何关于运行 Nginx 的 Pod 的信息，所以不得不在执行 curl 命令时忽略 CName 不匹配的情况。 +注意最后一步我们是如何提供 `-k` 参数执行 curl命令的，这是因为在证书生成时， +我们不知道任何关于运行 Nginx 的 Pod 的信息，所以不得不在执行 curl 命令时忽略 CName 不匹配的情况。 通过创建 Service，我们连接了在证书中的 CName 与在 Service 查询时被 Pod使用的实际 DNS 名字。 让我们从一个 Pod 来测试（为了简化使用同一个秘钥，Pod 仅需要使用 nginx.crt 去访问 Service）： @@ -513,15 +506,18 @@ LoadBalancers. The Service created in the last section already used `NodePort`, so your nginx HTTPS replica is ready to serve traffic on the internet if your node has a public IP. --> - ## 暴露 Service 对我们应用的某些部分，可能希望将 Service 暴露在一个外部 IP 地址上。 Kubernetes 支持两种实现方式：NodePort 和 LoadBalancer。 -在上一段创建的 Service 使用了 `NodePort`，因此 Nginx https 副本已经就绪，如果使用一个公网 IP，能够处理 Internet 上的流量。 +在上一段创建的 Service 使用了 `NodePort`，因此 Nginx https 副本已经就绪， +如果使用一个公网 IP，能够处理 Internet 上的流量。 ```shell kubectl get svc my-nginx -o yaml | grep nodePort -C 5 +``` + +``` uid: 07191fb3-f61a-11e5-8ae5-42010af00002 spec: clusterIP: 10.0.162.149 @@ -539,8 +535,12 @@ spec: selector: run: my-nginx ``` + ```shell kubectl get nodes -o yaml | grep ExternalIP -C 1 +``` + +``` - address: 104.197.41.11 type: ExternalIP allocatable: @@ -549,8 +549,14 @@ kubectl get nodes -o yaml | grep ExternalIP -C 1 type: ExternalIP allocatable: ... +``` -$ curl https://<EXTERNAL-IP>:<NODE-PORT> -k +```shell +curl https://<EXTERNAL-IP>:<NODE-PORT> -k +``` + +输出类似于： +``` ... <h1>Welcome to nginx!</h1> ``` @@ -593,24 +599,22 @@ see it. You'll see something like this: ```shell kubectl describe service my-nginx +``` + +``` ... LoadBalancer Ingress: a320587ffd19711e5a37606cf4a74574-1142138393.us-east-1.elb.amazonaws.com ... ``` - - ## {{% heading "whatsnext" %}} - <!-- -Kubernetes also supports Federated Services, which can span multiple -clusters and cloud providers, to provide increased availability, -better fault tolerance and greater scalability for your services. See -the [Federated Services User Guide](/docs/concepts/cluster-administration/federation-service-discovery/) -for further information. +* Learn more about [Using a Service to Access an Application in a Cluster](/docs/tasks/access-application-cluster/service-access-application-cluster/) +* Learn more about [Connecting a Front End to a Back End Using a Service](/docs/tasks/access-application-cluster/connecting-frontend-backend/) +* Learn more about [Creating an External Load Balancer](/docs/tasks/access-application-cluster/create-external-load-balancer/) --> - -Kubernetes 也支持联合 Service，能够跨多个集群和云提供商，为 Service 提供逐步增强的可用性、更优的容错、更好的可伸缩性。 -查看 [联合 Service 用户指南](/docs/concepts/cluster-administration/federation-service-discovery/) 获取更进一步信息。 +* 进一步了解如何[使用 Service 访问集群中的应用](/zh/docs/tasks/access-application-cluster/service-access-application-cluster/) +* 进一步了解如何[使用 Service 将前端连接到后端](/zh/docs/tasks/access-application-cluster/connecting-frontend-backend/) +* 进一步了解如何[创建外部负载均衡器](/zh/docs/tasks/access-application-cluster/create-external-load-balancer/) diff --git a/content/zh/docs/concepts/services-networking/dns-pod-service.md b/content/zh/docs/concepts/services-networking/dns-pod-service.md index bbdda7e18a..48453424da 100644 --- a/content/zh/docs/concepts/services-networking/dns-pod-service.md +++ b/content/zh/docs/concepts/services-networking/dns-pod-service.md @@ -8,8 +8,7 @@ weight: 20 <!-- This page provides an overview of DNS support by Kubernetes. --> -该页面概述了Kubernetes对DNS的支持。 - +本页面提供 Kubernetes 对 DNS 的支持的概述。 <!-- body --> @@ -47,28 +46,25 @@ For more up-to-date specification, see ## 怎样获取 DNS 名字? 在集群中定义的每个 Service（包括 DNS 服务器自身）都会被指派一个 DNS 名称。 -默认，一个客户端 Pod 的 DNS 搜索列表将包含该 Pod 自己的 Namespace 和集群默认域。 -通过如下示例可以很好地说明： +默认，一个客户端 Pod 的 DNS 搜索列表将包含该 Pod 自己的名字空间和集群默认域。 +如下示例是一个很好的说明： -假设在 Kubernetes 集群的 Namespace `bar` 中，定义了一个Service `foo`。 -运行在Namespace `bar` 中的一个 Pod，可以简单地通过 DNS 查询 `foo` 来找到该 Service。 -运行在 Namespace `quux` 中的一个 Pod 可以通过 DNS 查询 `foo.bar` 找到该 Service。 +假设在 Kubernetes 集群的名字空间 `bar` 中，定义了一个服务 `foo`。 +运行在名字空间 `bar` 中的 Pod 可以简单地通过 DNS 查询 `foo` 来找到该服务。 +运行在名字空间 `quux` 中的 Pod 可以通过 DNS 查询 `foo.bar` 找到该服务。 -以下各节详细介绍了受支持的记录类型和支持的布局。 其中代码部分的布局，名称或查询命令均被视为实现细节，如有更改，恕不另行通知。 +以下各节详细介绍了受支持的记录类型和支持的布局。 +其它布局、名称或者查询即使碰巧可以工作，也应视为实现细节， +将来很可能被更改而且不会因此出现警告。 有关最新规范请查看 -[Kubernetes 基于 DNS 的服务发现](https://github.com/kubernetes/dns/blob/master/docs/specification.md). - -## 支持的 DNS 模式 - -下面各段详细说明支持的记录类型和布局。 -如果任何其它的布局、名称或查询，碰巧也能够使用，这就需要研究下它们的实现细节，以免后续修改它们又不能使用了。 +[Kubernetes 基于 DNS 的服务发现](https://github.com/kubernetes/dns/blob/master/docs/specification.md)。 <!-- ## Services -### A records +### A/AAAA records -"Normal" (not headless) Services are assigned a DNS A record for a name of the +"Normal" (not headless) Services are assigned a DNS A or AAAA record for a name of the form `my-svc.my-namespace.svc.cluster-domain.example`. This resolves to the cluster IP of the Service. @@ -79,16 +75,19 @@ Clients are expected to consume the set or else use standard round-robin selection from the set. --> -### Service +### 服务 {#services} -#### A 记录 +#### A/AAAA 记录 -“正常” Service（除了 Headless Service）会以 `my-svc.my-namespace.svc.cluster-domain.example` 这种名字的形式被指派一个 DNS A 记录。 -这会解析成该 Service 的 Cluster IP。 +“普通” 服务（除了无头服务）会以 `my-svc.my-namespace.svc.cluster-domain.example` +这种名字的形式被分配一个 DNS A 或 AAAA 记录，取决于服务的 IP 协议族。 +该名称会解析成对应服务的集群 IP。 -“Headless” Service（没有Cluster IP）也会以 `my-svc.my-namespace.svc.cluster-domain.example` 这种名字的形式被指派一个 DNS A 记录。 -不像正常 Service，它会解析成该 Service 选择的一组 Pod 的 IP。 -希望客户端能够使用这一组 IP，否则就使用标准的 round-robin 策略从这一组 IP 中进行选择。 +“无头（Headless）” 服务（没有集群 IP）也会以 +`my-svc.my-namespace.svc.cluster-domain.example` 这种名字的形式被指派一个 DNS A 或 AAAA 记录， +具体取决于服务的 IP 协议族。 +与普通服务不同，这一记录会被解析成对应服务所选择的 Pod 集合的 IP。 +客户端要能够使用这组 IP，或者使用标准的轮转策略从这组 IP 中进行选择。 <!-- ### SRV records @@ -103,19 +102,33 @@ For a headless service, this resolves to multiple answers, one for each pod that is backing the service, and contains the port number and the domain name of the pod of the form `auto-generated-name.my-svc.my-namespace.svc.cluster-domain.example`. --> +#### SRV 记录 {#srv-records} -#### SRV 记录 - -命名端口需要创建 SRV 记录，这些端口是正常 Service或 [Headless -Services](/docs/concepts/services-networking/service/#headless-services) 的一部分。 +Kubernetes 会为命名端口创建 SRV 记录，这些端口是普通服务或 +[无头服务](/zh/docs/concepts/services-networking/service/#headless-services)的一部分。 对每个命名端口，SRV 记录具有 `_my-port-name._my-port-protocol.my-svc.my-namespace.svc.cluster-domain.example` 这种形式。 -对普通 Service，这会被解析成端口号和 CNAME：`my-svc.my-namespace.svc.cluster-domain.example`。 -对 Headless Service，这会被解析成多个结果，Service 对应的每个 backend Pod 各一个， -包含 `auto-generated-name.my-svc.my-namespace.svc.cluster-domain.example` 这种形式 Pod 的端口号和 CNAME。 - +对普通服务，该记录会被解析成端口号和域名：`my-svc.my-namespace.svc.cluster-domain.example`。 +对无头服务，该记录会被解析成多个结果，服务对应的每个后端 Pod 各一个； +其中包含 Pod 端口号和形为 `auto-generated-name.my-svc.my-namespace.svc.cluster-domain.example` +的域名。 ## Pods +<!-- +### A/AAAA records + +Any pods created by a Deployment or DaemonSet have the following +DNS resolution available: + +`pod-ip-address.deployment-name.my-namespace.svc.cluster-domain.example.` +--> +### A/AAAA 记录 + +经由 Deployment 或者 DaemonSet 所创建的所有 Pods 都会有如下 DNS +解析项与之对应： + +`pod-ip-address.deployment-name.my-namespace.svc.cluster-domain.example.` + <!-- ### Pod's hostname and subdomain fields @@ -134,15 +147,22 @@ domain name (FQDN) "`foo.bar.my-namespace.svc.cluster-domain.example`". Example: --> -### Pod的 hostname 和 subdomain 字段 +### Pod 的 hostname 和 subdomain 字段 -当前，创建 Pod 后，它的主机名是该 Pod 的 `metadata.name` 值。 +当前，创建 Pod 时其主机名取自 Pod 的 `metadata.name` 值。 -PodSpec 有一个可选的 `hostname` 字段，可以用来指定 Pod 的主机名。当这个字段被设置时，它将优先于 Pod 的名字成为该 Pod 的主机名。举个例子，给定一个 `hostname` 设置为 "`my-host`" 的 Pod，该 Pod 的主机名将被设置为 "`my-host`"。 +Pod 规约中包含一个可选的 `hostname` 字段，可以用来指定 Pod 的主机名。 +当这个字段被设置时，它将优先于 Pod 的名字成为该 Pod 的主机名。 +举个例子，给定一个 `hostname` 设置为 "`my-host`" 的 Pod， +该 Pod 的主机名将被设置为 "`my-host`"。 -PodSpec 还有一个可选的 `subdomain` 字段，可以用来指定 Pod 的子域名。举个例子，一个 Pod 的 `hostname` 设置为 “`foo`”，`subdomain` 设置为 “`bar`”，在 namespace “`my-namespace`” 中对应的完全限定域名（FQDN）为 “`foo.bar.my-namespace.svc.cluster-domain.example`”。 +Pod 规约还有一个可选的 `subdomain` 字段，可以用来指定 Pod 的子域名。 +举个例子，某 Pod 的 `hostname` 设置为 “`foo`”，`subdomain` 设置为 “`bar`”， +在名字空间 “`my-namespace`” 中对应的完全限定域名（FQDN）为 +“`foo.bar.my-namespace.svc.cluster-domain.example`”。 + +示例： -实例: ```yaml apiVersion: v1 kind: Service @@ -153,7 +173,7 @@ spec: name: busybox clusterIP: None ports: - - name: foo # Actually, no port is needed. + - name: foo # 实际上不需要指定端口号 port: 1234 targetPort: 1234 --- @@ -192,30 +212,29 @@ spec: <!-- If there exists a headless service in the same namespace as the pod and with -the same name as the subdomain, the cluster's KubeDNS Server also returns an A +the same name as the subdomain, the cluster's DNS Server also returns an A or AAAA record for the Pod's fully qualified hostname. For example, given a Pod with the hostname set to "`busybox-1`" and the subdomain set to "`default-subdomain`", and a headless Service named "`default-subdomain`" in the same namespace, the pod will see its own FQDN as "`busybox-1.default-subdomain.my-namespace.svc.cluster-domain.example`". DNS serves an -A record at that name, pointing to the Pod's IP. Both pods "`busybox1`" and -"`busybox2`" can have their distinct A records. +A or AAAA record at that name, pointing to the Pod's IP. Both pods "`busybox1`" and +"`busybox2`" can have their distinct A or AAAA records. --> - -如果 Headless Service 与 Pod 在同一个 Namespace 中，它们具有相同的子域名，集群的 KubeDNS 服务器也会为该 Pod 的完整合法主机名返回 A 记录。 -例如，在同一个 Namespace 中，给定一个主机名为 “busybox-1” 的 Pod，子域名设置为 “default-subdomain”，名称为 “default-subdomain” 的 Headless Service ，Pod 将看到自己的 FQDN 为 “busybox-1.default-subdomain.my-namespace.svc.cluster.local”。 -DNS 会为那个名字提供一个 A 记录，指向该 Pod 的 IP。 -“busybox1” 和 “busybox2” 这两个 Pod 分别具有它们自己的 A 记录。 - +如果某无头服务与某 Pod 在同一个名字空间中，且它们具有相同的子域名， +集群的 DNS 服务器也会为该 Pod 的全限定主机名返回 A 记录或 AAAA 记录。 +例如，在同一个名字空间中，给定一个主机名为 “busybox-1”、 +子域名设置为 “default-subdomain” 的 Pod，和一个名称为 “`default-subdomain`” +的无头服务，Pod 将看到自己的 FQDN 为 +"`busybox-1.default-subdomain.my-namespace.svc.cluster-domain.example`"。 +DNS 会为此名字提供一个 A 记录或 AAAA 记录，指向该 Pod 的 IP。 +“`busybox1`” 和 “`busybox2`” 这两个 Pod 分别具有它们自己的 A 或 AAAA 记录。 <!-- The Endpoints object can specify the `hostname` for any endpoint addresses, along with its IP. --> - -端点对象可以为任何端点地址及其 IP 指定 `hostname`。 - -{{< note >}} +Endpoints 对象可以为任何端点地址及其 IP 指定 `hostname`。 <!-- Because A records are not created for Pod names, `hostname` is required for the Pod's A @@ -224,11 +243,15 @@ A record for the headless service (`default-subdomain.my-namespace.svc.cluster-d pointing to the Pod's IP address. Also, Pod needs to become ready in order to have a record unless `publishNotReadyAddresses=True` is set on the Service. --> +{{< note >}} +因为没有为 Pod 名称创建 A 记录或 AAAA 记录，所以要创建 Pod 的 A 记录 +或 AAAA 记录需要 `hostname`。 -因为没有为 Pod 名称创建A记录，所以要创建 Pod 的 A 记录需要 `hostname` 。 - -没有 `hostname` 但带有 `subdomain` 的 Pod 只会为指向Pod的IP地址的 headless 服务创建 A 记录(`default-subdomain.my-namespace.svc.cluster-domain.example`)。 -另外，除非在服务上设置了 `publishNotReadyAddresses=True`，否则 Pod 需要准备好 A 记录。 +没有设置 `hostname` 但设置了 `subdomain` 的 Pod 只会为 +无头服务创建 A 或 AAAA 记录（`default-subdomain.my-namespace.svc.cluster-domain.example`） +指向 Pod 的 IP 地址。 +另外，除非在服务上设置了 `publishNotReadyAddresses=True`，否则只有 Pod 进入就绪状态 +才会有与之对应的记录。 {{< /note >}} <!-- @@ -256,30 +279,32 @@ following pod-specific DNS policies. These policies are specified in the See [Pod's DNS config](#pod-s-dns-config) subsection below. --> -- "`Default`": Pod从运行所在的节点继承名称解析配置。 - 参考 [相关讨论](/docs/tasks/administer-cluster/dns-custom-nameservers/#inheriting-dns-from-the-node) 获取更多信息。 -- "`ClusterFirst`": 与配置的群集域后缀不匹配的任何DNS查询(例如 “www.kubernetes.io” )都将转发到从节点继承的上游名称服务器。 群集管理员可能配置了额外的存根域和上游DNS服务器。 - See [相关讨论](/docs/tasks/administer-cluster/dns-custom-nameservers/#impacts-on-pods) 获取如何 DNS 的查询和处理信息的相关资料。 -- "`ClusterFirstWithHostNet`": 对于与 hostNetwork 一起运行的 Pod，应显式设置其DNS策略 "`ClusterFirstWithHostNet`"。 -- "`None`": 它允许 Pod 忽略 Kubernetes 环境中的 DN S设置。 应该使用 Pod Spec 中的 `dnsConfig` 字段提供所有 DNS 设置。 - -{{< note >}} +- "`Default`": Pod 从运行所在的节点继承名称解析配置。 + 参考[相关讨论](/zh/docs/tasks/administer-cluster/dns-custom-nameservers/#inheriting-dns-from-the-node) 获取更多信息。 +- "`ClusterFirst`": 与配置的集群域后缀不匹配的任何 DNS 查询（例如 “www.kubernetes.io”） + 都将转发到从节点继承的上游名称服务器。集群管理员可能配置了额外的存根域和上游 DNS 服务器。 + 参阅[相关讨论](/zh/docs/tasks/administer-cluster/dns-custom-nameservers/#impacts-on-pods) + 了解在这些场景中如何处理 DNS 查询的信息。 +- "`ClusterFirstWithHostNet`"：对于以 hostNetwork 方式运行的 Pod，应显式设置其 DNS 策略 + "`ClusterFirstWithHostNet`"。 +- "`None`": 此设置允许 Pod 忽略 Kubernetes 环境中的 DNS 设置。Pod 会使用其 `dnsConfig` 字段 + 所提供的 DNS 设置。 + 参见 [Pod 的 DNS 配置](#pod-dns-config)节。 <!-- "Default" is not the default DNS policy. If `dnsPolicy` is not explicitly specified, then “ClusterFirst” is used. --> - -"Default" 不是默认的 DNS 策略。 如果未明确指定 `dnsPolicy`，则使用 “ClusterFirst”。 +{{< note >}} +"`Default`" 不是默认的 DNS 策略。如果未明确指定 `dnsPolicy`，则使用 "`ClusterFirst`"。 {{< /note >}} - <!-- The example below shows a Pod with its DNS policy set to "`ClusterFirstWithHostNet`" because it has `hostNetwork` set to `true`. --> - -下面的示例显示了一个Pod，其DNS策略设置为 "`ClusterFirstWithHostNet`"，因为它已将 `hostNetwork` 设置为 `true`。 +下面的示例显示了一个 Pod，其 DNS 策略设置为 "`ClusterFirstWithHostNet`"， +因为它已将 `hostNetwork` 设置为 `true`。 ```yaml apiVersion: v1 @@ -311,8 +336,7 @@ to be specified. Below are the properties a user can specify in the `dnsConfig` field: --> - -### Pod 的 DNS 设定 +### Pod 的 DNS 配置 {#pod-dns-config} Pod 的 DNS 配置可让用户对 Pod 的 DNS 设置进行更多控制。 @@ -339,18 +363,23 @@ Pod 的 DNS 配置可让用户对 Pod 的 DNS 设置进行更多控制。 Duplicate entries are removed. --> -- `nameservers`: 将用作于 Pod 的 DNS 服务器的 IP 地址列表。最多可以指定3个 IP 地址。 当 Pod 的 `dnsPolicy` 设置为 "`None`" 时，列表必须至少包含一个IP地址，否则此属性是可选的。列出的服务器将合并到从指定的 DNS 策略生成的基本名称服务器，并删除重复的地址。 -- `searches`: 用于在 Pod 中查找主机名的 DNS 搜索域的列表。此属性是可选的。指定后，提供的列表将合并到根据所选 DNS 策略生成的基本搜索域名中。 - 重复的域名将被删除。 -   Kubernetes最多允许6个搜索域。 -- `options`: 对象的可选列表，其中每个对象可能具有 `name` 属性（必需）和 `value` 属性（可选）。 此属性中的内容将合并到从指定的 DNS 策略生成的选项。 - 重复的条目将被删除。 +- `nameservers`：将用作于 Pod 的 DNS 服务器的 IP 地址列表。 + 最多可以指定 3 个 IP 地址。当 Pod 的 `dnsPolicy` 设置为 "`None`" 时， + 列表必须至少包含一个 IP 地址，否则此属性是可选的。 + 所列出的服务器将合并到从指定的 DNS 策略生成的基本名称服务器，并删除重复的地址。 + +- `searches`：用于在 Pod 中查找主机名的 DNS 搜索域的列表。此属性是可选的。 + 指定此属性时，所提供的列表将合并到根据所选 DNS 策略生成的基本搜索域名中。 + 重复的域名将被删除。Kubernetes 最多允许 6 个搜索域。 + +- `options`：可选的对象列表，其中每个对象可能具有 `name` 属性（必需）和 `value` 属性（可选）。 + 此属性中的内容将合并到从指定的 DNS 策略生成的选项。 + 重复的条目将被删除。 <!-- The following is an example Pod with custom DNS settings: --> - -以下是具有自定义DNS设置的Pod示例： +以下是具有自定义 DNS 设置的 Pod 示例： {{< codenew file="service/networking/custom-dns.yaml" >}} @@ -358,8 +387,7 @@ The following is an example Pod with custom DNS settings: When the Pod above is created, the container `test` gets the following contents in its `/etc/resolv.conf` file: --> - -创建上面的Pod后，容器 `test` 会在其 `/etc/resolv.conf` 文件中获取以下内容： +创建上面的 Pod 后，容器 `test` 会在其 `/etc/resolv.conf` 文件中获取以下内容： ``` nameserver 1.2.3.4 @@ -367,12 +395,10 @@ search ns1.svc.cluster-domain.example my.dns.search.suffix options ndots:2 edns0 ``` - - <!-- For IPv6 setup, search path and name server should be setup like this: --> -对于IPv6设置，搜索路径和名称服务器应按以下方式设置： +对于 IPv6 设置，搜索路径和名称服务器应按以下方式设置： ```shell kubectl exec -it dns-example -- cat /etc/resolv.conf @@ -381,8 +407,9 @@ kubectl exec -it dns-example -- cat /etc/resolv.conf <!-- The output is similar to this: --> -有以下输出： -```shell +输出类似于 + +``` nameserver fd00:79:30::a search default.svc.cluster-domain.example svc.cluster-domain.example cluster-domain.example options ndots:5 @@ -393,29 +420,22 @@ options ndots:5 The availability of Pod DNS Config and DNS Policy "`None`" is shown as below. --> +### 功能的可用性 -### 可用功能 +Pod DNS 配置和 DNS 策略 "`None`" 的可用版本对应如下所示。 -Pod DNS 配置和 DNS 策略 "`None`" 的版本对应如下所示。 - -| k8s version | Feature support | +| k8s 版本 | 特性支持 | | :---------: |:-----------:| -| 1.14 | Stable | -| 1.10 | Beta (on by default)| +| 1.14 | 稳定 | +| 1.10 | Beta（默认启用） | | 1.9 | Alpha | - - ## {{% heading "whatsnext" %}} - <!-- For guidance on administering DNS configurations, check [Configure DNS Service](/docs/tasks/administer-cluster/dns-custom-nameservers/) --> - 有关管理 DNS 配置的指导，请查看 -[配置 DNS 服务](/docs/tasks/administer-cluster/dns-custom-nameservers/) - - +[配置 DNS 服务](/zh/docs/tasks/administer-cluster/dns-custom-nameservers/) diff --git a/content/zh/docs/concepts/services-networking/dual-stack.md b/content/zh/docs/concepts/services-networking/dual-stack.md index 4fe0dad18c..f1bfba435f 100644 --- a/content/zh/docs/concepts/services-networking/dual-stack.md +++ b/content/zh/docs/concepts/services-networking/dual-stack.md @@ -3,26 +3,19 @@ title: IPv4/IPv6 双协议栈 feature: title: IPv4/IPv6 双协议栈 description: > - Allocation of IPv4 and IPv6 addresses to Pods and Services - + 为 Pod 和 Service 分配 IPv4 和 IPv6 地址 content_type: concept weight: 70 --- + <!-- ---- -reviewers: -- lachie83 -- khenidak -- aramase title: IPv4/IPv6 dual-stack feature: title: IPv4/IPv6 dual-stack description: > Allocation of IPv4 and IPv6 addresses to Pods and Services - content_type: concept weight: 70 ---- --> <!-- overview --> @@ -32,14 +25,15 @@ weight: 70 <!-- IPv4/IPv6 dual-stack enables the allocation of both IPv4 and IPv6 addresses to {{< glossary_tooltip text="Pods" term_id="pod" >}} and {{< glossary_tooltip text="Services" term_id="service" >}}. --> -IPv4/IPv6 双协议栈能够将 IPv4 和 IPv6 地址分配给 {{< glossary_tooltip text="Pods" term_id="pod" >}} 和 {{< glossary_tooltip text="Services" term_id="service" >}}。 +IPv4/IPv6 双协议栈能够将 IPv4 和 IPv6 地址分配给 +{{< glossary_tooltip text="Pod" term_id="pod" >}} 和 +{{< glossary_tooltip text="Service" term_id="service" >}}。 <!-- If you enable IPv4/IPv6 dual-stack networking for your Kubernetes cluster, the cluster will support the simultaneous assignment of both IPv4 and IPv6 addresses. --> -如果你为 Kubernetes 集群启用了 IPv4/IPv6 双协议栈网络，则该集群将支持同时分配 IPv4 和 IPv6 地址。 - - +如果你为 Kubernetes 集群启用了 IPv4/IPv6 双协议栈网络， +则该集群将支持同时分配 IPv4 和 IPv6 地址。 <!-- body --> @@ -89,7 +83,9 @@ The following prerequisites are needed in order to utilize IPv4/IPv6 dual-stack <!-- To enable IPv4/IPv6 dual-stack, enable the `IPv6DualStack` [feature gate](/docs/reference/command-line-tools-reference/feature-gates/) for the relevant components of your cluster, and set dual-stack cluster network assignments: --> -要启用 IPv4/IPv6 双协议栈，为集群的相关组件启用 `IPv6DualStack` [特性门控](/docs/reference/command-line-tools-reference/feature-gates/)，并且设置双协议栈的集群网络分配： +要启用 IPv4/IPv6 双协议栈，为集群的相关组件启用 `IPv6DualStack` +[特性门控](/zh/docs/reference/command-line-tools-reference/feature-gates/)， +并且设置双协议栈的集群网络分配： * kube-apiserver: * `--feature-gates="IPv6DualStack=true"` @@ -113,13 +109,20 @@ To enable IPv4/IPv6 dual-stack, enable the `IPv6DualStack` [feature gate](/docs/ If your cluster has IPv4/IPv6 dual-stack networking enabled, you can create {{< glossary_tooltip text="Services" term_id="service" >}} with either an IPv4 or an IPv6 address. You can choose the address family for the Service's cluster IP by setting a field, `.spec.ipFamily`, on that Service. You can only set this field when creating a new Service. Setting the `.spec.ipFamily` field is optional and should only be used if you plan to enable IPv4 and IPv6 {{< glossary_tooltip text="Services" term_id="service" >}} and {{< glossary_tooltip text="Ingresses" term_id="ingress" >}} on your cluster. The configuration of this field not a requirement for [egress](#egress-traffic) traffic. --> -如果你的集群启用了 IPv4/IPv6 双协议栈网络，则可以使用 IPv4 或 IPv6 地址来创建 {{< glossary_tooltip text="Services" term_id="service" >}}。你可以通过设置服务的 `.spec.ipFamily` 字段来选择服务的集群 IP 的地址族。你只能在创建新服务时设置该字段。`.spec.ipFamily` 字段的设置是可选的，并且仅当你计划在集群上启用 IPv4 和 IPv6 的 {{< glossary_tooltip text="Services" term_id="service" >}} 和 {{< glossary_tooltip text="Ingresses" term_id="ingress" >}}。对于[出口](#出口流量)流量，该字段的配置不是必须的。 +如果你的集群启用了 IPv4/IPv6 双协议栈网络，则可以使用 IPv4 或 IPv6 地址来创建 +{{< glossary_tooltip text="Service" term_id="service" >}}。 +你可以通过设置服务的 `.spec.ipFamily` 字段来选择服务的集群 IP 的地址族。 +你只能在创建新服务时设置该字段。`.spec.ipFamily` 字段的设置是可选的， +并且仅当你计划在集群上启用 IPv4 和 IPv6 的 {{< glossary_tooltip text="Service" term_id="service" >}} +和 {{< glossary_tooltip text="Ingress" term_id="ingress" >}}。 +对于[出口](#出口流量)流量，该字段的配置不是必须的。 <!-- -The default address family for your cluster is the address family of the first service cluster IP range configured via the `--service-cluster-ip-range` flag to the kube-controller-manager. +The default address family for your cluster is the address family of the first service cluster IP range configured via the `-service-cluster-ip-range` flag to the kube-controller-manager. --> {{< note >}} -集群的默认地址族是第一个服务集群 IP 范围的地址族，该地址范围通过 kube-controller-manager 上的 `--service-cluster-ip-range` 标志设置。 +集群的默认地址族是第一个服务集群 IP 范围的地址族，该地址范围通过 +`kube-controller-manager` 上的 `--service-cluster-ip-range` 标志设置。 {{< /note >}} <!-- @@ -158,12 +161,13 @@ For comparison, the following Service specification will be assigned an IPV4 add <!-- ### Type LoadBalancer --> -### 负载均衡器类型 +### LoadBalancer 类型 <!-- On cloud providers which support IPv6 enabled external load balancers, setting the `type` field to `LoadBalancer` in additional to setting `ipFamily` field to `IPv6` provisions a cloud load balancer for your Service. --> -在支持启用了 IPv6 的外部服务均衡器的云驱动上，除了将 `ipFamily` 字段设置为 `IPv6`，将 `type` 字段设置为 `LoadBalancer`，为你的服务提供云负载均衡。 +在支持启用了 IPv6 的外部服务均衡器的云驱动上，除了将 `ipFamily` 字段设置为 `IPv6`， +将 `type` 字段设置为 `LoadBalancer`，为你的服务提供云负载均衡。 <!-- ## Egress Traffic @@ -173,7 +177,12 @@ On cloud providers which support IPv6 enabled external load balancers, setting t <!-- The use of publicly routable and non-publicly routable IPv6 address blocks is acceptable provided the underlying {{< glossary_tooltip text="CNI" term_id="cni" >}} provider is able to implement the transport. If you have a Pod that uses non-publicly routable IPv6 and want that Pod to reach off-cluster destinations (eg. the public Internet), you must set up IP masquerading for the egress traffic and any replies. The [ip-masq-agent](https://github.com/kubernetes-incubator/ip-masq-agent) is dual-stack aware, so you can use ip-masq-agent for IP masquerading on dual-stack clusters. --> -公共路由和非公共路由的 IPv6 地址块的使用是可以的。提供底层 {{< glossary_tooltip text="CNI" term_id="cni" >}} 的提供程序可以实现这种传输。如果你拥有使用非公共路由 IPv6 地址的 Pod，并且希望该 Pod 到达集群外目的（比如，公共网络），你必须为出口流量和任何响应消息设置 IP 伪装。[ip-masq-agent](https://github.com/kubernetes-incubator/ip-masq-agent) 可以感知双栈，所以你可以在双栈集群中使用 ip-masq-agent 来进行 IP 伪装。 +公共路由和非公共路由的 IPv6 地址块的使用是可以的。提供底层 +{{< glossary_tooltip text="CNI" term_id="cni" >}} 的提供程序可以实现这种传输。 +如果你拥有使用非公共路由 IPv6 地址的 Pod，并且希望该 Pod 到达集群外目的 +（比如，公共网络），你必须为出口流量和任何响应消息设置 IP 伪装。 +[ip-masq-agent](https://github.com/kubernetes-incubator/ip-masq-agent) 可以感知双栈， +所以你可以在双栈集群中使用 ip-masq-agent 来进行 IP 伪装。 <!-- ## Known Issues @@ -181,19 +190,15 @@ The use of publicly routable and non-publicly routable IPv6 address blocks is ac ## 已知问题 <!-- - * Kubenet forces IPv4,IPv6 positional reporting of IPs (--cluster-cidr) + * Kubenet forces IPv4,IPv6 positional reporting of IPs (-cluster-cidr) --> - * Kubenet 强制 IPv4，IPv6 的 IPs 位置报告 (--cluster-cidr) - - + * Kubenet 强制 IPv4，IPv6 的 IPs 位置报告 (`--cluster-cidr`) ## {{% heading "whatsnext" %}} - <!-- * [Validate IPv4/IPv6 dual-stack](/docs/tasks/network/validate-dual-stack) networking --> -* [验证 IPv4/IPv6 双协议栈](/docs/tasks/network/validate-dual-stack)网络 - +* [验证 IPv4/IPv6 双协议栈](/zh/docs/tasks/network/validate-dual-stack)网络 diff --git a/content/zh/docs/concepts/services-networking/endpoint-slices.md b/content/zh/docs/concepts/services-networking/endpoint-slices.md index 8a71b19b3c..d788da3d7d 100644 --- a/content/zh/docs/concepts/services-networking/endpoint-slices.md +++ b/content/zh/docs/concepts/services-networking/endpoint-slices.md @@ -1,9 +1,7 @@ --- -reviewers: -- freehan -title: Endpoint Slices +title: 端点切片（Endpoint Slices） feature: - title: Endpoint Slices + title: 端点切片 description: > Kubernetes 集群中网络端点的可扩展跟踪。 @@ -12,9 +10,6 @@ weight: 10 --- <!-- ---- -reviewers: -- freehan title: Endpoint Slices feature: title: Endpoint Slices @@ -23,7 +18,6 @@ feature: content_type: concept weight: 10 ---- --> <!-- overview --> @@ -35,9 +29,8 @@ _Endpoint Slices_ provide a simple way to track network endpoints within a Kubernetes cluster. They offer a more scalable and extensible alternative to Endpoints. --> -_Endpoint Slices_ 提供了一种简单的方法来跟踪 Kubernetes 集群中的网络端点（network endpoints）。它们为 Endpoints 提供了一种可伸缩和可拓展的替代方案。 - - +_端点切片（Endpoint Slices）_ 提供了一种简单的方法来跟踪 Kubernetes 集群中的网络端点 +（network endpoints）。它们为 Endpoints 提供了一种可伸缩和可拓展的替代方案。 <!-- body --> @@ -55,7 +48,9 @@ Kubernetes Service. --> ## Endpoint Slice 资源 {#endpointslice-resource} -在 Kubernetes 中，`EndpointSlice` 包含对一组网络端点的引用。指定选择器后，EndpointSlice 控制器会自动为 Kubernetes 服务创建 EndpointSlice。这些 EndpointSlice 将包含对与服务选择器匹配的所有 Pod 的引用。EndpointSlice 通过唯一的服务和端口组合将网络端点组织在一起。 +在 Kubernetes 中，`EndpointSlice` 包含对一组网络端点的引用。 +指定选择器后，EndpointSlice 控制器会自动为 Kubernetes 服务创建 EndpointSlice。 +这些 EndpointSlice 将包含对与服务选择器匹配的所有 Pod 的引用。EndpointSlice 通过唯一的服务和端口组合将网络端点组织在一起。 例如，这里是 Kubernetes服务 `example` 的示例 EndpointSlice 资源。 @@ -90,7 +85,14 @@ with Endpoints and Services and have similar performance. Endpoint Slices can act as the source of truth for kube-proxy when it comes to how to route internal traffic. When enabled, they should provide a performance improvement for services with large numbers of endpoints. +--> +默认情况下，由 EndpointSlice 控制器管理的 Endpoint Slice 将有不超过 100 个端点。 +低于此比例时，Endpoint Slices 应与 Endpoints 和服务进行 1:1 映射，并具有相似的性能。 +当涉及如何路由内部流量时，Endpoint Slices 可以充当 kube-proxy 的真实来源。 +启用该功能后，在服务的 endpoints 规模庞大时会有可观的性能提升。 + +<!-- ## Address Types EndpointSlices support three address types: @@ -98,7 +100,16 @@ EndpointSlices support three address types: * IPv4 * IPv6 * FQDN (Fully Qualified Domain Name) +--> +## 地址类型 +EndpointSlice 支持三种地址类型： + +* IPv4 +* IPv6 +* FQDN (完全合格的域名) + +<!-- ## Motivation The Endpoints API has provided a simple and straightforward way of @@ -114,38 +125,25 @@ significant amounts of network traffic and processing when Endpoints changed. Endpoint Slices help you mitigate those issues as well as provide an extensible platform for additional features such as topological routing. --> - -默认情况下，由 EndpointSlice 控制器管理的 Endpoint Slice 将有不超过 100 个 endpoints。低于此比例时，Endpoint Slices 应与 Endpoints 和服务进行 1：1 映射，并具有相似的性能。 - -当涉及如何路由内部流量时，Endpoint Slices 可以充当 kube-proxy 的真实来源。启用该功能后，在服务的 endpoints 规模庞大时会有可观的性能提升。 - -<!-- -## Address Types ---> -## 地址类型 - -EndpointSlice 支持三种地址类型： - -* IPv4 -* IPv6 -* FQDN (完全合格的域名) - ## 动机 -Endpoints API 提供了一种简单明了的方法在 Kubernetes 中跟踪网络端点。不幸的是，随着 Kubernetes 集群与服务的增长，该 API 的局限性变得更加明显。最值得注意的是，这包含了扩展到更多网络端点的挑战。 +Endpoints API 提供了一种简单明了的方法在 Kubernetes 中跟踪网络端点。 +不幸的是，随着 Kubernetes 集群与服务的增长，该 API 的局限性变得更加明显。 +最值得注意的是，这包含了扩展到更多网络端点的挑战。 -由于服务的所有网络端点都存储在单个 Endpoints 资源中，因此这些资源可能会变得很大。这影响了 Kubernetes 组件（尤其是主控制平面）的性能，并在 Endpoints 发生更改时导致大量网络流量和处理。Endpoint Slices 可帮助您缓解这些问题并提供可扩展的 +由于服务的所有网络端点都存储在单个 Endpoints 资源中， +因此这些资源可能会变得很大。 +这影响了 Kubernetes 组件（尤其是主控制平面）的性能，并在 Endpoints +发生更改时导致大量网络流量和处理。 +Endpoint Slices 可帮助您缓解这些问题并提供可扩展的 附加特性（例如拓扑路由）平台。 - - ## {{% heading "whatsnext" %}} - <!-- * [Enabling Endpoint Slices](/docs/tasks/administer-cluster/enabling-endpoint-slices) * Read [Connecting Applications with Services](/docs/concepts/services-networking/connect-applications-service/) --> -* [启用 Endpoint Slices](/docs/tasks/administer-cluster/enabling-endpoint-slices) -* 阅读 [Connecting Applications with Services](/docs/concepts/services-networking/connect-applications-service/) +* [启用端点切片](/zh/docs/tasks/administer-cluster/enabling-endpointslices) +* 阅读[使用服务链接应用](/zh/docs/concepts/services-networking/connect-applications-service/) diff --git a/content/zh/docs/concepts/services-networking/ingress-controllers.md b/content/zh/docs/concepts/services-networking/ingress-controllers.md index 46d166d9d9..4071ea6189 100644 --- a/content/zh/docs/concepts/services-networking/ingress-controllers.md +++ b/content/zh/docs/concepts/services-networking/ingress-controllers.md @@ -1,134 +1,155 @@ ---- -title: Ingress 控制器 -content_type: concept -weight: 40 ---- - -<!-- ---- -title: Ingress Controllers -reviewers: -content_type: concept -weight: 40 ---- ---> - -<!-- overview --> - -<!-- -In order for the Ingress resource to work, the cluster must have an ingress controller running. - -Unlike other types of controllers which run as part of the `kube-controller-manager` binary, Ingress controllers -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. - ---> - -为了让 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) 控制器。 - - - -<!-- body --> - -<!-- -## Additional controllers ---> -## 其他控制器 - -<!-- -* [AKS Application Gateway Ingress Controller](https://github.com/Azure/application-gateway-kubernetes-ingress) is an ingress controller that enables ingress to [AKS clusters](https://docs.microsoft.com/azure/aks/kubernetes-walkthrough-portal) using 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 with [community](https://www.getambassador.io/docs) or - [commercial](https://www.getambassador.io/pro/) support from [Datawire](https://www.datawire.io/). -* [AppsCode Inc.](https://appscode.com) offers support and maintenance for the most widely used [HAProxy](http://www.haproxy.org/) based ingress controller [Voyager](https://appscode.com/products/voyager). -* [AWS ALB Ingress Controller](https://github.com/kubernetes-sigs/aws-alb-ingress-controller) enables ingress using the [AWS Application Load Balancer](https://aws.amazon.com/elasticloadbalancing/). -* [Contour](https://projectcontour.io/) is an [Envoy](https://www.envoyproxy.io/) based ingress controller - provided and supported by VMware. -* Citrix provides an [Ingress Controller](https://github.com/citrix/citrix-k8s-ingress-controller) for its hardware (MPX), virtualized (VPX) and [free containerized (CPX) ADC](https://www.citrix.com/products/citrix-adc/cpx-express.html) for [baremetal](https://github.com/citrix/citrix-k8s-ingress-controller/tree/master/deployment/baremetal) and [cloud](https://github.com/citrix/citrix-k8s-ingress-controller/tree/master/deployment) deployments. -* F5 Networks provides [support and maintenance](https://support.f5.com/csp/article/K86859508) - for the [F5 BIG-IP Controller for Kubernetes](http://clouddocs.f5.com/products/connectors/k8s-bigip-ctlr/latest). -* [Gloo](https://gloo.solo.io) is an open-source ingress controller based on [Envoy](https://www.envoyproxy.io) which offers API Gateway functionality with enterprise support from [solo.io](https://www.solo.io). -* [HAProxy Ingress](https://haproxy-ingress.github.io) is a highly customizable community-driven ingress controller for HAProxy. -* [HAProxy Technologies](https://www.haproxy.com/) offers support and maintenance for the [HAProxy Ingress Controller for Kubernetes](https://github.com/haproxytech/kubernetes-ingress). See the [official documentation](https://www.haproxy.com/documentation/hapee/1-9r1/traffic-management/kubernetes-ingress-controller/). -* [Istio](https://istio.io/) based ingress controller - [Control Ingress Traffic](https://istio.io/docs/tasks/traffic-management/ingress/). -* [Kong](https://konghq.com/) offers [community](https://discuss.konghq.com/c/kubernetes) or - [commercial](https://konghq.com/kong-enterprise/) support and maintenance for the - [Kong Ingress Controller for Kubernetes](https://github.com/Kong/kubernetes-ingress-controller). -* [NGINX, Inc.](https://www.nginx.com/) offers support and maintenance for the - [NGINX Ingress Controller for Kubernetes](https://www.nginx.com/products/nginx/kubernetes-ingress-controller). -* [Skipper](https://opensource.zalando.com/skipper/kubernetes/ingress-controller/) HTTP router and reverse proxy for service composition, including use cases like Kubernetes Ingress, designed as a library to build your custom proxy -* [Traefik](https://github.com/containous/traefik) is a fully featured ingress controller - ([Let's Encrypt](https://letsencrypt.org), secrets, http2, websocket), and it also comes with commercial - support by [Containous](https://containo.us/services). ---> -* [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](http://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/containous/traefik) 是一个全功能的 ingress 控制器 - （[Let's Encrypt](https://letsencrypt.org)，secrets，http2，websocket），并且它也有来自 [Containous](https://containo.us/services) 的商业支持。 - -<!-- -## Using multiple Ingress controllers ---> -## 使用多个 Ingress 控制器 - -<!-- -You may deploy [any number of ingress controllers](https://git.k8s.io/ingress-nginx/docs/user-guide/multiple-ingress.md#multiple-ingress-controllers) -within a cluster. When you create an ingress, you should annotate each ingress with the appropriate -[`ingress.class`](https://git.k8s.io/ingress-gce/docs/faq/README.md#how-do-i-run-multiple-ingress-controllers-in-the-same-cluster) -to indicate which ingress controller should be used if more than one exists within your cluster. - -If you do not define a class, your cloud provider may use a default ingress controller. - -Ideally, all ingress controllers should fulfill this specification, but the various ingress -controllers operate slightly differently. ---> - -你可以在集群中部署[任意数量的 ingress 控制器](https://git.k8s.io/ingress-nginx/docs/user-guide/multiple-ingress.md#multiple-ingress-controllers)。 -创建 ingress 时，应该使用适当的 [`ingress.class`](https://git.k8s.io/ingress-gce/docs/faq/README.md#how-do-i-run-multiple-ingress-controllers-in-the-same-cluster) 注解每个 ingress -以表明在集群中如果有多个 ingress 控制器时，应该使用哪个 ingress 控制器。 - -如果不定义 `ingress.class`，云提供商可能使用默认的 ingress 控制器。 - -理想情况下，所有 ingress 控制器都应满足此规范，但各种 ingress 控制器的操作略有不同。 - -<!-- -Make sure you review your ingress controller's documentation to understand the caveats of choosing it. ---> -{{< note >}} -确保您查看了 ingress 控制器的文档，以了解选择它的注意事项。 -{{< /note >}} - - - +--- +title: Ingress 控制器 +content_type: concept +weight: 40 +--- + +<!-- +title: Ingress Controllers +content_type: concept +weight: 40 +--> + +<!-- overview --> + +<!-- +In order for the Ingress resource to work, the cluster must have an ingress controller running. + +Unlike other types of controllers which run as part of the `kube-controller-manager` binary, Ingress controllers +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. +--> +为了让 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) 控制器。 + +<!-- body --> + +<!-- +## Additional controllers +--> +## 其他控制器 + +<!-- +* [AKS Application Gateway Ingress Controller](https://github.com/Azure/application-gateway-kubernetes-ingress) is an ingress controller that enables ingress to [AKS clusters](https://docs.microsoft.com/azure/aks/kubernetes-walkthrough-portal) using 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 with [community](https://www.getambassador.io/docs) or + [commercial](https://www.getambassador.io/pro/) support from [Datawire](https://www.datawire.io/). +* [AppsCode Inc.](https://appscode.com) offers support and maintenance for the most widely used [HAProxy](http://www.haproxy.org/) based ingress controller [Voyager](https://appscode.com/products/voyager). +* [AWS ALB Ingress Controller](https://github.com/kubernetes-sigs/aws-alb-ingress-controller) enables ingress using the [AWS Application Load Balancer](https://aws.amazon.com/elasticloadbalancing/). +* [Contour](https://projectcontour.io/) is an [Envoy](https://www.envoyproxy.io/) based ingress controller + provided and supported by VMware. +--> +* [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 provides an [Ingress Controller](https://github.com/citrix/citrix-k8s-ingress-controller) for its hardware (MPX), virtualized (VPX) and [free containerized (CPX) ADC](https://www.citrix.com/products/citrix-adc/cpx-express.html) for [baremetal](https://github.com/citrix/citrix-k8s-ingress-controller/tree/master/deployment/baremetal) and [cloud](https://github.com/citrix/citrix-k8s-ingress-controller/tree/master/deployment) deployments. +* F5 Networks provides [support and maintenance](https://support.f5.com/csp/article/K86859508) + for the [F5 BIG-IP Controller for Kubernetes](http://clouddocs.f5.com/products/connectors/k8s-bigip-ctlr/latest). +* [Gloo](https://gloo.solo.io) is an open-source ingress controller based on [Envoy](https://www.envoyproxy.io) which offers API Gateway functionality with enterprise support from [solo.io](https://www.solo.io). +* [HAProxy Ingress](https://haproxy-ingress.github.io) is a highly customizable community-driven ingress controller for HAProxy. +* [HAProxy Technologies](https://www.haproxy.com/) offers support and maintenance for the [HAProxy Ingress Controller for Kubernetes](https://github.com/haproxytech/kubernetes-ingress). See the [official documentation](https://www.haproxy.com/documentation/hapee/1-9r1/traffic-management/kubernetes-ingress-controller/). +* [Istio](https://istio.io/) based ingress controller + [Control Ingress Traffic](https://istio.io/docs/tasks/traffic-management/ingress/). +--> +* 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/) offers [community](https://discuss.konghq.com/c/kubernetes) or + [commercial](https://konghq.com/kong-enterprise/) support and maintenance for the + [Kong Ingress Controller for Kubernetes](https://github.com/Kong/kubernetes-ingress-controller). +* [NGINX, Inc.](https://www.nginx.com/) offers support and maintenance for the + [NGINX Ingress Controller for Kubernetes](https://www.nginx.com/products/nginx/kubernetes-ingress-controller). +* [Skipper](https://opensource.zalando.com/skipper/kubernetes/ingress-controller/) HTTP router and reverse proxy for service composition, including use cases like Kubernetes Ingress, designed as a library to build your custom proxy +* [Traefik](https://github.com/containous/traefik) is a fully featured ingress controller + ([Let's Encrypt](https://letsencrypt.org), secrets, http2, websocket), and it also comes with commercial + support by [Containous](https://containo.us/services). +--> +* [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/containous/traefik) 是一个全功能的 ingress 控制器 + （[Let's Encrypt](https://letsencrypt.org)，secrets，http2，websocket）， + 并且它也有来自 [Containous](https://containo.us/services) 的商业支持。 + +<!-- +## Using multiple Ingress controllers +--> +## 使用多个 Ingress 控制器 + +<!-- +You may deploy [any number of ingress controllers](https://git.k8s.io/ingress-nginx/docs/user-guide/multiple-ingress.md#multiple-ingress-controllers) +within a cluster. When you create an ingress, you should annotate each ingress with the appropriate +[`ingress.class`](https://git.k8s.io/ingress-gce/docs/faq/README.md#how-do-i-run-multiple-ingress-controllers-in-the-same-cluster) +to indicate which ingress controller should be used if more than one exists within your cluster. + +If you do not define a class, your cloud provider may use a default ingress controller. + +Ideally, all ingress controllers should fulfill this specification, but the various ingress +controllers operate slightly differently. +--> + +你可以在集群中部署[任意数量的 ingress 控制器](https://git.k8s.io/ingress-nginx/docs/user-guide/multiple-ingress.md#multiple-ingress-controllers)。 +创建 ingress 时，应该使用适当的 +[`ingress.class`](https://git.k8s.io/ingress-gce/docs/faq/README.md#how-do-i-run-multiple-ingress-controllers-in-the-same-cluster) +注解每个 Ingress 以表明在集群中如果有多个 Ingress 控制器时，应该使用哪个 Ingress 控制器。 + +如果不定义 `ingress.class`，云提供商可能使用默认的 Ingress 控制器。 + +理想情况下，所有 Ingress 控制器都应满足此规范，但各种 Ingress 控制器的操作略有不同。 + +<!-- +Make sure you review your ingress controller's documentation to understand the caveats of choosing it. +--> +{{< note >}} +确保您查看了 ingress 控制器的文档，以了解选择它的注意事项。 +{{< /note >}} + ## {{% heading "whatsnext" %}} - -<!-- -* Learn more about [Ingress](/docs/concepts/services-networking/ingress/). -* [Set up Ingress on Minikube with the NGINX Controller](/docs/tasks/access-application-cluster/ingress-minikube). ---> -* 进一步了解 [Ingress](/docs/concepts/services-networking/ingress/)。 -* [在 Minikube 上使用 NGINX 控制器安装 Ingress](/docs/tasks/access-application-cluster/ingress-minikube)。 - + +<!-- +* Learn more about [Ingress](/docs/concepts/services-networking/ingress/). +* [Set up Ingress on Minikube with the NGINX Controller](/docs/tasks/access-application-cluster/ingress-minikube). +--> +* 进一步了解 [Ingress](/zh/docs/concepts/services-networking/ingress/)。 +* [在 Minikube 上使用 NGINX 控制器安装 Ingress](/zh/docs/tasks/access-application-cluster/ingress-minikube)。 + diff --git a/content/zh/docs/concepts/services-networking/ingress.md b/content/zh/docs/concepts/services-networking/ingress.md index 24b2acd5dc..254f04cba2 100644 --- a/content/zh/docs/concepts/services-networking/ingress.md +++ b/content/zh/docs/concepts/services-networking/ingress.md @@ -4,13 +4,9 @@ content_type: concept weight: 40 --- <!-- ---- -reviewers: -- bprashanth title: Ingress content_type: concept weight: 40 ---- --> <!-- overview --> @@ -23,7 +19,7 @@ weight: 40 <!-- ## Terminology --> -## 专用术语 +## 术语 <!-- For clarity, this guide defines the following terms: @@ -38,10 +34,14 @@ For clarity, this guide defines the following terms: * Service: A Kubernetes {{< glossary_tooltip term_id="service" >}} that identifies a set of Pods using {{< glossary_tooltip text="label" term_id="label" >}} selectors. Unless mentioned otherwise, Services are assumed to have virtual IPs only routable within the cluster network. --> * 节点（Node）: Kubernetes 集群中其中一台工作机器，是集群的一部分。 -* 集群（Cluster）: 一组运行程序（这些程序是容器化的，被 Kubernetes 管理的）的节点。 在此示例中，和在大多数常见的Kubernetes部署方案，集群中的节点都不会是公共网络。 -* 边缘路由器（Edge router）: 在集群中强制性执行防火墙策略的路由器（router）。可以是由云提供商管理的网关，也可以是物理硬件。 -* 集群网络（Cluster network）: 一组逻辑或物理的链接，根据 Kubernetes [网络模型](/docs/concepts/cluster-administration/networking/) 在集群内实现通信。 -* 服务（Service）：Kubernetes {{< glossary_tooltip term_id="service" >}} 使用 {{< glossary_tooltip text="标签" term_id="label" >}} 选择器（selectors）标识的一组 Pod。除非另有说明，否则假定服务只具有在集群网络中可路由的虚拟 IP。 +* 集群（Cluster）: 一组运行由 Kubernetes 管理的容器化应用程序的节点。 + 在此示例和在大多数常见的 Kubernetes 部署环境中，集群中的节点都不在公共网络中。 +* 边缘路由器（Edge router）: 在集群中强制执行防火墙策略的路由器（router）。可以是由云提供商管理的网关，也可以是物理硬件。 +* 集群网络（Cluster network）: 一组逻辑的或物理的连接，根据 Kubernetes + [网络模型](/zh/docs/concepts/cluster-administration/networking/) 在集群内实现通信。 +* 服务（Service）：Kubernetes {{< glossary_tooltip text="服务" term_id="service" >}}使用 + {{< glossary_tooltip text="标签" term_id="label" >}} 选择算符（selectors）标识的一组 Pod。 + 除非另有说明，否则假定服务只具有在集群网络中可路由的虚拟 IP。 <!-- ## What is Ingress? @@ -54,7 +54,8 @@ For clarity, this guide defines the following terms: Traffic routing is controlled by rules defined on the Ingress resource. --> -[Ingress](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#ingress-v1beta1-networking-k8s-io) 公开了从集群外部到集群内 {{< link text="services" url="/docs/concepts/services-networking/service/" >}} 的 HTTP 和 HTTPS 路由。 +[Ingress](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#ingress-v1beta1-networking-k8s-io) +公开了从集群外部到集群内[服务](/zh/docs/concepts/services-networking/service/)的 HTTP 和 HTTPS 路由。 流量路由由 Ingress 资源上定义的规则控制。 ```none @@ -68,7 +69,9 @@ Traffic routing is controlled by rules defined on the Ingress resource. <!-- An Ingress may be configured to give Services externally-reachable URLs, load balance traffic, terminate SSL / TLS, and offer name based virtual hosting. An [Ingress controller](/docs/concepts/services-networking/ingress-controllers) is responsible for fulfilling the Ingress, usually with a load balancer, though it may also configure your edge router or additional frontends to help handle the traffic. --> -可以将 Ingress 配置为提供服务外部可访问的 URL、负载均衡流量、终止 SSL / TLS，以及提供基于名称的虚拟主机。[Ingress 控制器](/docs/concepts/services-networking/ingress-controllers) 通常负责通过负载均衡器来实现 Ingress，尽管它也可以配置边缘路由器或其他前端来帮助处理流量。 +可以将 Ingress 配置为服务提供外部可访问的 URL、负载均衡流量、终止 SSL/TLS，以及提供基于名称的虚拟主机等能力。 +[Ingress 控制器](/zh/docs/concepts/services-networking/ingress-controllers) +通常负责通过负载均衡器来实现 Ingress，尽管它也可以配置边缘路由器或其他前端来帮助处理流量。 <!-- An Ingress does not expose arbitrary ports or protocols. Exposing services other than HTTP and HTTPS to the internet typically @@ -76,23 +79,27 @@ uses a service of type [Service.Type=NodePort](/docs/concepts/services-networkin [Service.Type=LoadBalancer](/docs/concepts/services-networking/service/#loadbalancer). --> Ingress 不会公开任意端口或协议。 -将 HTTP 和 HTTPS 以外的服务公开到 Internet 时，通常使用 [Service.Type=NodePort](/docs/concepts/services-networking/service/#nodeport) 或者 [Service.Type=LoadBalancer](/docs/concepts/services-networking/service/#loadbalancer) 类型的服务。 +将 HTTP 和 HTTPS 以外的服务公开到 Internet 时，通常使用 +[Service.Type=NodePort](/zh/docs/concepts/services-networking/service/#nodeport) +或 [Service.Type=LoadBalancer](/zh/docs/concepts/services-networking/service/#loadbalancer) +类型的服务。 <!-- ## Prerequisites + +You must have an [ingress controller](/docs/concepts/services-networking/ingress-controllers) to satisfy an Ingress. Only creating an Ingress resource has no effect. --> ## 环境准备 -<!-- -You must have an [ingress controller](/docs/concepts/services-networking/ingress-controllers) to satisfy an Ingress. Only creating an Ingress resource has no effect. ---> -您必须具有 [ingress 控制器](/docs/concepts/services-networking/ingress-controllers) 才能满足 Ingress 的要求。仅创建 Ingress 资源无效。 +你必须具有 [Ingress 控制器](/zh/docs/concepts/services-networking/ingress-controllers) 才能满足 Ingress 的要求。 +仅创建 Ingress 资源本身没有任何效果。 <!-- You may need to deploy an Ingress controller such as [ingress-nginx](https://kubernetes.github.io/ingress-nginx/deploy/). You can choose from a number of [Ingress controllers](/docs/concepts/services-networking/ingress-controllers). --> -您可能需要部署 Ingress 控制器，例如 [ingress-nginx](https://kubernetes.github.io/ingress-nginx/deploy/)。您可以从许多[Ingress 控制器](/docs/concepts/services-networking/ingress-controllers) 中进行选择。 +你可能需要部署 Ingress 控制器，例如 [ingress-nginx](https://kubernetes.github.io/ingress-nginx/deploy/)。 +你可以从许多 [Ingress 控制器](/zh/docs/concepts/services-networking/ingress-controllers) 中进行选择。 <!-- Ideally, all Ingress controllers should fit the reference specification. In reality, the various Ingress @@ -109,12 +116,11 @@ Make sure you review your Ingress controller's documentation to understand the c <!-- ## The Ingress Resource + +A minimal Ingress resource example: --> ## Ingress 资源 -<!-- -A minimal Ingress resource example: ---> 一个最小的 Ingress 资源示例： ```yaml @@ -146,10 +152,14 @@ Different [Ingress controller](/docs/concepts/services-networking/ingress-contro your choice of Ingress controller to learn which annotations are supported. --> 与所有其他 Kubernetes 资源一样，Ingress 需要使用 `apiVersion`、`kind` 和 `metadata` 字段。 - Ingress 对象的命名必须是合法的 [DNS 子域名名称](/docs/concepts/overview/working-with-objects/names#dns-subdomain-names)。 - 有关使用配置文件的一般信息，请参见[部署应用](/docs/tasks/run-application/run-stateless-application-deployment/)、 [配置容器](/docs/tasks/configure-pod-container/configure-pod-configmap/)、[管理资源](/docs/concepts/cluster-administration/manage-deployment/)。 - Ingress 经常使用注解（annotations）来配置一些选项，具体取决于 Ingress 控制器，例如 [rewrite-target annotation](https://github.com/kubernetes/ingress-nginx/blob/master/docs/examples/rewrite/README.md)。 - 不同的 [Ingress 控制器](/docs/concepts/services-networking/ingress-controllers) 支持不同的注解（annotations）。查看文档以供您选择 Ingress 控制器，以了解支持哪些注解（annotations）。 + Ingress 对象的命名必须是合法的 [DNS 子域名名称](/zh/docs/concepts/overview/working-with-objects/names#dns-subdomain-names)。 + 有关使用配置文件的一般信息，请参见[部署应用](/zh/docs/tasks/run-application/run-stateless-application-deployment/)、 +[配置容器](/zh/docs/tasks/configure-pod-container/configure-pod-configmap/)、 +[管理资源](/zh/docs/concepts/cluster-administration/manage-deployment/)。 + Ingress 经常使用注解（annotations）来配置一些选项，具体取决于 Ingress 控制器，例如 +[重写目标注解](https://github.com/kubernetes/ingress-nginx/blob/master/docs/examples/rewrite/README.md)。 + 不同的 [Ingress 控制器](/zh/docs/concepts/services-networking/ingress-controllers) +支持不同的注解。查看文档以供您选择 Ingress 控制器，以了解支持哪些注解。 <!-- The Ingress [spec](https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status) @@ -157,12 +167,15 @@ has all the information needed to configure a load balancer or proxy server. Mos contains a list of rules matched against all incoming requests. Ingress resource only supports rules for directing HTTP traffic. --> -Ingress [规范](https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status) 具有配置负载均衡器或者代理服务器所需的所有信息。最重要的是，它包含与所有传入请求匹配的规则列表。Ingress 资源仅支持用于定向 HTTP 流量的规则。 +Ingress [规约](https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status) +提供了配置负载均衡器或者代理服务器所需的所有信息。 +最重要的是，其中包含与所有传入请求匹配的规则列表。 +Ingress 资源仅支持用于转发 HTTP 流量的规则。 <!-- ### Ingress rules --> -### Ingress 规则 +### Ingress 规则 {#ingress-rules} <!-- Each HTTP rule contains the following information: @@ -180,43 +193,46 @@ Each HTTP rule contains the following information: [Service doc](/docs/concepts/services-networking/service/). HTTP (and HTTPS) requests to the Ingress that matches the host and path of the rule are sent to the listed backend. --> -* 可选主机。在此示例中，未指定主机，因此该规则适用于通过指定 IP 地址的所有入站 HTTP 通信。如果提供了主机（例如 foo.bar.com），则规则适用于该主机。 -* 路径列表（例如，`/testpath`）,每个路径都有一个由 `serviceName` 和 `servicePort` 定义的关联后端。在负载均衡器将流量定向到引用的服务之前，主机和路径都必须匹配传入请求的内容。 -* 后端是 [Service 文档](/docs/concepts/services-networking/service/)中所述的服务和端口名称的组合。与规则的主机和路径匹配的对 Ingress 的 HTTP（和 HTTPS ）请求将发送到列出的后端。 +* 可选主机。在此示例中，未指定主机，因此该规则适用于通过指定 IP 地址的所有入站 HTTP 通信。 + 如果提供了主机（例如 foo.bar.com），则规则适用于该主机。 +* 路径列表（例如，`/testpath`）,每个路径都有一个由 `serviceName` 和 `servicePort` 定义的关联后端。 + 在负载均衡器将流量定向到引用的服务之前，主机和路径都必须匹配传入请求的内容。 +* 后端是 [Service 文档](/zh/docs/concepts/services-networking/service/)中所述的服务和端口名称的组合。 + 与规则的主机和路径匹配的对 Ingress 的 HTTP（和 HTTPS ）请求将发送到列出的后端。 <!-- A default backend is often configured in an Ingress controller to service any requests that do not match a path in the spec. --> -通常在 Ingress 控制器中配置默认后端，以服务任何不符合规范中路径的请求。 +通常在 Ingress 控制器中会配置默认后端，以服务任何不符合规范中路径的请求。 <!-- ### Default Backend ---> -### 默认后端 -<!-- An Ingress with no rules sends all traffic to a single default backend. The default backend is typically a configuration option of the [Ingress controller](/docs/concepts/services-networking/ingress-controllers) and is not specified in your Ingress resources. --> -没有规则的 Ingress 将所有流量发送到单个默认后端。默认后端通常是 [Ingress 控制器](/docs/concepts/services-networking/ingress-controllers)的配置选项，并且未在 Ingress 资源中指定。 +### 默认后端 + +没有规则的 Ingress 将所有流量发送到同一个默认后端。 +默认后端通常是 [Ingress 控制器](/zh/docs/concepts/services-networking/ingress-controllers) +的配置选项，并且未在 Ingress 资源中指定。 <!-- If none of the hosts or paths match the HTTP request in the Ingress objects, the traffic is routed to your default backend. --> -如果没有主机或路径与 Ingress 对象中的 HTTP 请求匹配，则流量将路由到您的默认后端。 +如果主机或路径都没有与 Ingress 对象中的 HTTP 请求匹配，则流量将路由到默认后端。 <!-- ### Path Types - --> -### 路径类型 -<!-- Each path in an Ingress has a corresponding path type. There are three supported path types: - --> -Ingress 中的每个路径都有对应的路径类型。支持三种类型： +--> +### 路径类型 {#path-types} + +Ingress 中的每个路径都有对应的路径类型。当前支持的路径类型有三种： <!-- * _`ImplementationSpecific`_ (default): With this path type, matching is up to @@ -234,14 +250,19 @@ Ingress 中的每个路径都有对应的路径类型。支持三种类型： last element in request path, it is not a match (for example: `/foo/bar` matches`/foo/bar/baz`, but does not match `/foo/barbaz`). --> -* _`ImplementationSpecific`_ （默认）：对于这种类型，匹配取决于 IngressClass. 具体实现可以将其作为单独的 `pathType` 处理或者与 `Prefix` 或 `Exact` 类型作相同处理。 +* _`ImplementationSpecific`_ （默认）：对于这种类型，匹配取决于 IngressClass。 + 具体实现可以将其作为单独的 `pathType` 处理或者与 `Prefix` 或 `Exact` 类型作相同处理。 -* _`Exact`_：精确匹配 URL 路径且对大小写敏感。 +* _`Exact`_：精确匹配 URL 路径，且对大小写敏感。 -* _`Prefix`_：基于以 `/` 分割的 URL 路径前缀匹配。匹配对大小写敏感，并且对路径中的元素逐个完成。路径元素指的是由 `/` 分隔符分割的路径中的标签列表。如果每个 _p_ 都是请求路径 _p_ 的元素前缀，则请求与路径 _p_ 匹配。 - {{< note >}} - 如果路径的最后一个元素是请求路径中最后一个元素的子字符串，则不会匹配（例如：`/foo/bar` 匹配 `/foo/bar/baz`, 但不匹配 `/foo/barbaz`）。 - {{< /note >}} +* _`Prefix`_：基于以 `/` 分隔的 URL 路径前缀匹配。匹配对大小写敏感，并且对路径中的元素逐个完成。 + 路径元素指的是由 `/` 分隔符分隔的路径中的标签列表。 + 如果每个 _p_ 都是请求路径 _p_ 的元素前缀，则请求与路径 _p_ 匹配。 + + {{< note >}} + 如果路径的最后一个元素是请求路径中最后一个元素的子字符串，则不会匹配 + （例如：`/foo/bar` 匹配 `/foo/bar/baz`, 但不匹配 `/foo/barbaz`）。 + {{< /note >}} <!-- #### Multiple Matches @@ -250,22 +271,25 @@ cases precedence will be given first to the longest matching path. If two paths are still equally matched, precedence will be given to paths with an exact path type over prefix path type. --> -#### 多重匹配 +#### 多重匹配 {#multiple-matches} -在某些情况下，Ingress 中的多条路径会匹配同一个请求。这种情况下最长的匹配路径优先。如果仍然有两条同等的匹配路径，则精确路径类型优先于前缀路径类型。 +在某些情况下，Ingress 中的多条路径会匹配同一个请求。 +这种情况下最长的匹配路径优先。 +如果仍然有两条同等的匹配路径，则精确路径类型优先于前缀路径类型。 <!-- ## Ingress Class - --> -## Ingress 类 -<!-- Ingresses can be implemented by different controllers, often with different configuration. Each Ingress should specify a class, a reference to an IngressClass resource that contains additional configuration including the name of the controller that should implement the class. - --> -Ingress 可以由不同的控制器实现，通常使用不同的配置。每个 Ingress 应当指定一个类，一个对 IngressClass 资源的引用，该资源包含额外的配置，其中包括应当实现该类的控制器名称。 +--> +## Ingress 类 {#ingress-class} + +Ingress 可以由不同的控制器实现，通常使用不同的配置。 +每个 Ingress 应当指定一个类，也就是一个对 IngressClass 资源的引用。 +IngressClass 资源包含额外的配置，其中包括应当实现该类的控制器名称。 ```yaml apiVersion: networking.k8s.io/v1beta1 @@ -284,21 +308,21 @@ spec: IngressClass resources contain an optional parameters field. This can be used to reference additional configuration for this class. --> -IngressClass 资源包含一个可选的参数字段。可用于引用该类的额外配置。 +IngressClass 资源包含一个可选的参数字段，可用于为该类引用额外配置。 <!-- ### Deprecated Annotation - --> -### 废弃的注解 -<!-- Before the IngressClass resource and `ingressClassName` field were added in Kubernetes 1.18, Ingress classes were specified with a `kubernetes.io/ingress.class` annotation on the Ingress. This annotation was never formally defined, but was widely supported by Ingress controllers. - --> -在 IngressClass 资源和 `ingressClassName` 字段被引入 Kubernetes 1.18 之前，Ingress 类是通过 Ingress 中的一个 -`kubernetes.io/ingress.class` 注解来指定的。这个注解从未被正式定义过，但是得到了 Ingress 控制器的广泛支持。 +--> +### 废弃的注解 + +在 Kubernetes 1.18 版本引入 IngressClass 资源和 `ingressClassName` 字段之前， +Ingress 类是通过 Ingress 中的一个 `kubernetes.io/ingress.class` 注解来指定的。 +这个注解从未被正式定义过，但是得到了 Ingress 控制器的广泛支持。 <!-- The newer `ingressClassName` field on Ingresses is a replacement for that @@ -306,22 +330,26 @@ annotation, but is not a direct equivalent. While the annotation was generally used to reference the name of the Ingress controller that should implement the Ingress, the field is a reference to an IngressClass resource that contains additional Ingress configuration, including the name of the Ingress controller. - --> -Ingress 中新的 `ingressClassName` 字段是该注解的替代品，但并非完全等价。该注解通常用于引用实现该 Ingress 的控制器的名称， -而这个新的字段则是对一个包含额外 Ingress 配置的 IngressClass 资源的引用，包括 Ingress 控制器的名称。 +--> +Ingress 中新的 `ingressClassName` 字段是该注解的替代品，但并非完全等价。 +该注解通常用于引用实现该 Ingress 的控制器的名称， +而这个新的字段则是对一个包含额外 Ingress 配置的 IngressClass 资源的引用， +包括 Ingress 控制器的名称。 <!-- ### Default Ingress Class - --> -### 默认 Ingress 类 -<!-- You can mark a particular IngressClass as default for your cluster. Setting the `ingressclass.kubernetes.io/is-default-class` annotation to `true` on an IngressClass resource will ensure that new Ingresses without an `ingressClassName` field specified will be assigned this default IngressClass. - --> -您可以将一个特定的 IngressClass 标记为集群默认项。将一个 IngressClass 资源的 `ingressclass.kubernetes.io/is-default-class` 注解设置为 `true` 将确保新的未指定 `ingressClassName` 字段的 Ingress 能够分配为这个默认的 IngressClass. +--> +### 默认 Ingress 类 {#default-ingress-class} + +您可以将一个特定的 IngressClass 标记为集群默认选项。 +将一个 IngressClass 资源的 `ingressclass.kubernetes.io/is-default-class` 注解设置为 +`true` 将确保新的未指定 `ingressClassName` 字段的 Ingress 能够分配为这个默认的 +IngressClass. <!-- If you have more than one IngressClass marked as the default for your cluster, @@ -330,26 +358,26 @@ an `ingressClassName` specified. You can resolve this by ensuring that at most 1 IngressClasess are marked as default in your cluster. --> {{< caution >}} -如果集群中有多个 IngressClass 被标记为默认，准入控制器将阻止创建新的未指定 `ingressClassName` 字段的 Ingress 对象。 +如果集群中有多个 IngressClass 被标记为默认，准入控制器将阻止创建新的未指定 `ingressClassName` +的 Ingress 对象。 解决这个问题只需确保集群中最多只能有一个 IngressClass 被标记为默认。 {{< /caution >}} <!-- ## Types of Ingress ---> -## Ingress 类型 -<!-- ### Single Service Ingress ---> -### 单服务 Ingress -<!-- There are existing Kubernetes concepts that allow you to expose a single Service (see [alternatives](#alternatives)). You can also do this with an Ingress by specifying a *default backend* with no rules. --> -现有的 Kubernetes 概念允许您暴露单个 Service (查看[替代方案](#alternatives))，您也可以通过指定无规则的 *默认后端* 来对 Ingress 进行此操作。 +## Ingress 类型 {#types-of-ingress} + +### 单服务 Ingress {#single-service-ingress} + +现有的 Kubernetes 概念允许您暴露单个 Service (查看[替代方案](#alternatives))。 +你也可以通过指定无规则的 *默认后端* 来对 Ingress 进行此操作。 {{< codenew file="service/networking/ingress.yaml" >}} @@ -379,19 +407,19 @@ Ingress controllers and load balancers may take a minute or two to allocate an I Until that time, you often see the address listed as `<pending>`. --> {{< note >}} -入口控制器和负载平衡器可能需要一两分钟才能分配IP地址。 在此之前，您通常会看到地址字段的值被设定为 `<pending>`。 +入口控制器和负载平衡器可能需要一两分钟才能分配 IP 地址。在此之前，您通常会看到地址字段的值被设定为 +`<pending>`。 {{< /note >}} <!-- ### Simple fanout ---> -### 简单分列 -<!-- A fanout configuration routes traffic from a single IP address to more than one Service, based on the HTTP URI being requested. An Ingress allows you to keep the number of load balancers down to a minimum. For example, a setup like: --> +### 简单分列 + 一个分列配置根据请求的 HTTP URI 将流量从单个 IP 地址路由到多个服务。 Ingress 允许您将负载均衡器的数量降至最低。例如，这样的设置： @@ -403,7 +431,7 @@ foo.bar.com -> 178.91.123.132 -> / foo service1:4200 <!-- would require an Ingress such as: --> -将需要一个 Ingress，例如： +将需要一个如下所示的 Ingress： ```yaml apiVersion: networking.k8s.io/v1beta1 @@ -430,7 +458,7 @@ spec: <!-- When you create the Ingress with `kubectl apply -f`: --> -当您使用 `kubectl apply -f` 创建 Ingress 时： +当你使用 `kubectl apply -f` 创建 Ingress 时： ```shell kubectl describe ingress simple-fanout-example @@ -461,9 +489,8 @@ that satisfies the Ingress, as long as the Services (`service1`, `service2`) exi When it has done so, you can see the address of the load balancer at the Address field. --> - Ingress 控制器将提供实现特定的负载均衡器来满足 Ingress，只要 Service (`service1`，`service2`) 存在。 -当它这样做了，您会在地址栏看到负载均衡器的地址。 +当它这样做了，你会在地址字段看到负载均衡器的地址。 <!-- Depending on the [Ingress controller](/docs/concepts/services-networking/ingress-controllers) @@ -471,19 +498,18 @@ you are using, you may need to create a default-http-backend [Service](/docs/concepts/services-networking/service/). --> {{< note >}} -根据您使用的 [Ingress 控制器](/docs/concepts/services-networking/ingress-controllers)，您可能需要创建默认 HTTP 后端 [Service](/docs/concepts/services-networking/service/)。 +取决于你使用的 [Ingress 控制器](/zh/docs/concepts/services-networking/ingress-controllers)， +你可能需要创建默认 HTTP 后端[服务](/zh/docs/concepts/services-networking/service/)。 {{< /note >}} - <!-- ### Name based virtual hosting + +Name-based virtual hosts support routing HTTP traffic to multiple host names at the same IP address. --> ### 基于名称的虚拟托管 -<!-- -Name-based virtual hosts support routing HTTP traffic to multiple host names at the same IP address. ---> -基于名称的虚拟主机支持将 HTTP 流量路由到同一 IP 地址上的多个主机名。 +基于名称的虚拟主机支持将针对多个主机名的 HTTP 流量路由到同一 IP 地址上。 ```none foo.bar.com --| |-> foo.bar.com service1:80 @@ -491,12 +517,12 @@ foo.bar.com --| |-> foo.bar.com service1:80 bar.foo.com --| |-> bar.foo.com service2:80 ``` - <!-- The following Ingress tells the backing load balancer to route requests based on the [Host header](https://tools.ietf.org/html/rfc7230#section-5.4). --> -以下 Ingress 让后台负载均衡器基于[主机 header](https://tools.ietf.org/html/rfc7230#section-5.4) 路由请求。 +以下 Ingress 让后台负载均衡器基于[host 头部字段](https://tools.ietf.org/html/rfc7230#section-5.4) +来路由请求。 ```yaml apiVersion: networking.k8s.io/v1beta1 @@ -524,7 +550,8 @@ If you create an Ingress resource without any hosts defined in the rules, then a web traffic to the IP address of your Ingress controller can be matched without a name based virtual host being required. --> -如果您创建的 Ingress 资源没有规则中定义的任何主机，则可以匹配到您 Ingress 控制器 IP 地址的任何网络流量，而无需基于名称的虚拟主机。 +如果您创建的 Ingress 资源没有规则中定义的任何主机，则可以匹配指向 Ingress 控制器 IP 地址 +的任何网络流量，而无需基于名称的虚拟主机。 <!-- For example, the following Ingress resource will route traffic @@ -532,7 +559,9 @@ requested for `first.bar.com` to `service1`, `second.foo.com` to `service2`, and to the IP address without a hostname defined in request (that is, without a request header being presented) to `service3`. --> -例如，以下 Ingress 资源会将 `first.bar.com` 请求的流量路由到 `service1`，将 `second.foo.com` 请求的流量路由到 `service2`，而没有在请求中定义主机名的 IP 地址的流量路由（即，不提供请求标头）到 `service3`。 +例如，以下 Ingress 资源会将 `first.bar.com` 请求的流量路由到 `service1`， +将 `second.foo.com` 请求的流量路由到 `service2`， +而没有在请求中定义主机名的 IP 地址的流量路由（即，不提供请求标头）到 `service3`。 ```yaml apiVersion: networking.k8s.io/v1beta1 @@ -562,11 +591,7 @@ spec: <!-- ### TLS ---> -### TLS - -<!-- You can secure an Ingress by specifying a {{< glossary_tooltip term_id="secret" >}} that contains a TLS private key and certificate. Currently the Ingress only supports a single TLS port, 443, and assumes TLS termination. If the TLS @@ -576,12 +601,16 @@ SNI TLS extension (provided the Ingress controller supports SNI). The TLS secret must contain keys named `tls.crt` and `tls.key` that contain the certificate and private key to use for TLS. For example: --> +### TLS -您可以通过指定包含 TLS 私钥和证书的 secret {{< glossary_tooltip term_id="secret" >}} 来加密 Ingress。 +你可以通过设定包含 TLS 私钥和证书的{{< glossary_tooltip text="Secret" term_id="secret" >}} +来保护 Ingress。 目前，Ingress 只支持单个 TLS 端口 443，并假定 TLS 终止。 -如果 Ingress 中的 TLS 配置部分指定了不同的主机，那么它们将根据通过 SNI TLS 扩展指定的主机名（如果 Ingress 控制器支持 SNI）在同一端口上进行复用。 -TLS Secret 必须包含名为 `tls.crt` 和 `tls.key` 的密钥，这些密钥包含用于 TLS 的证书和私钥，例如： +如果 Ingress 中的 TLS 配置部分指定了不同的主机，那么它们将根据通过 SNI TLS 扩展指定的主机名 +（如果 Ingress 控制器支持 SNI）在同一端口上进行复用。 +TLS Secret 必须包含名为 `tls.crt` 和 `tls.key` 的键名。 +这些数据包含用于 TLS 的证书和私钥。例如： ```yaml apiVersion: v1 @@ -601,7 +630,9 @@ secure the channel from the client to the load balancer using TLS. You need to m sure the TLS secret you created came from a certificate that contains a Common Name (CN), also known as a Fully Qualified Domain Name (FQDN) for `sslexample.foo.com`. --> -在 Ingress 中引用此 Secret 将会告诉 Ingress 控制器使用 TLS 加密从客户端到负载均衡器的通道。您需要确保创建的 TLS secret 来自包含 `sslexample.foo.com` 的公用名称（CN）的证书，也被称为全限定域名（FQDN）。 +在 Ingress 中引用此 Secret 将会告诉 Ingress 控制器使用 TLS 加密从客户端到负载均衡器的通道。 +你需要确保创建的 TLS Secret 来自包含 `sslexample.foo.com` 的公用名称（CN）的证书。 +这里的公共名称也被称为全限定域名（FQDN）。 ```yaml apiVersion: networking.k8s.io/v1beta1 @@ -631,17 +662,15 @@ controllers. Please refer to documentation on platform specific Ingress controller to understand how TLS works in your environment. --> {{< note >}} -各种 Ingress 控制器所支持的 TLS 功能之间存在差异。请参阅有关文件 +各种 Ingress 控制器所支持的 TLS 功能之间存在差异。请参阅有关 [nginx](https://kubernetes.github.io/ingress-nginx/user-guide/tls/)、 -[GCE](https://git.k8s.io/ingress-gce/README.md#frontend-https) 或者任何其他平台特定的 Ingress 控制器，以了解 TLS 如何在您的环境中工作。 +[GCE](https://git.k8s.io/ingress-gce/README.md#frontend-https) +或者任何其他平台特定的 Ingress 控制器的文档，以了解 TLS 如何在你的环境中工作。 {{< /note >}} <!-- ### Loadbalancing ---> -### 负载均衡 -<!-- An Ingress controller is bootstrapped with some load balancing policy settings that it applies to all Ingress, such as the load balancing algorithm, backend weight scheme, and others. More advanced load balancing concepts @@ -649,32 +678,36 @@ weight scheme, and others. More advanced load balancing concepts Ingress. You can instead get these features through the load balancer used for a Service. --> +### 负载均衡 -Ingress 控制器使用一些适用于所有 Ingress 的负载均衡策略设置进行自举，例如负载均衡算法、后端权重方案和其他等。更高级的负载均衡概念（例如，持久会话、动态权重）尚未通过 Ingress 公开。您可以通过用于服务的负载均衡器来获取这些功能。 +Ingress 控制器启动引导时使用一些适用于所有 Ingress 的负载均衡策略设置， +例如负载均衡算法、后端权重方案和其他等。 +更高级的负载均衡概念（例如持久会话、动态权重）尚未通过 Ingress 公开。 +你可以通过用于服务的负载均衡器来获取这些功能。 <!-- It's also worth noting that even though health checks are not exposed directly through the Ingress, there exist parallel concepts in Kubernetes such as -[readiness probes](/docs/tasks/configure-pod-container/configure-liveness-readiness-probes/) +[readiness probes](/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/) that allow you to achieve the same end result. Please review the controller specific documentation to see how they handle health checks ( [nginx](https://git.k8s.io/ingress-nginx/README.md), [GCE](https://git.k8s.io/ingress-gce/README.md#health-checks)). --> -值得注意的是，即使健康检查不是通过 Ingress 直接暴露的，但是在 Kubernetes 中存在并行概念，比如 [就绪检查](/docs/tasks/configure-pod-container/configure-liveness-readiness-probes/)，它允许您实现相同的最终结果。 -请检查控制器特殊说明文档，以了解他们是怎样处理健康检查的 ( +值得注意的是，即使健康检查不是通过 Ingress 直接暴露的，在 Kubernetes +中存在并行概念，比如[就绪检查](/zh/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/) +允许你实现相同的目的。 +请检查特定控制器的说明文档，以了解它们是怎样处理健康检查的 ( [nginx](https://git.k8s.io/ingress-nginx/README.md)， [GCE](https://git.k8s.io/ingress-gce/README.md#health-checks))。 - <!-- ## Updating an Ingress + +To update an existing Ingress to add a new Host, you can update it by editing the resource: --> ## 更新 Ingress -<!-- -To update an existing Ingress to add a new Host, you can update it by editing the resource: ---> 要更新现有的 Ingress 以添加新的 Host，可以通过编辑资源来对其进行更新： ```shell @@ -707,8 +740,7 @@ kubectl edit ingress test This pops up an editor with the existing configuration in YAML format. Modify it to include the new Host: --> - -这将弹出具有 YAML 格式的现有配置的编辑器。 +这一命令将打开编辑器，允许你以 YAML 格式编辑现有配置。 修改它来增加新的主机： ```yaml @@ -770,45 +802,42 @@ Events: <!-- You can achieve the same outcome by invoking `kubectl replace -f` on a modified Ingress YAML file. --> -您可以通过 `kubectl replace -f` 命令调用修改后的 Ingress yaml 文件来获得同样的结果。 +你也可以通过 `kubectl replace -f` 命令调用修改后的 Ingress yaml 文件来获得同样的结果。 <!-- ## Failing across availability zones ---> -## 跨可用区失败 -<!-- Techniques for spreading traffic across failure domains differs between cloud providers. Please check the documentation of the relevant [Ingress controller](/docs/concepts/services-networking/ingress-controllers) for details. You can also refer to the [federation documentation](https://github.com/kubernetes-sigs/federation-v2) for details on deploying Ingress in a federated cluster. --> +## 跨可用区失败 {#failing-across-availability-zones} -用于跨故障域传播流量的技术在云提供商之间是不同的。详情请查阅相关 Ingress 控制器的文档。 -请查看相关[ Ingress 控制器](/docs/concepts/services-networking/ingress-controllers) 的文档以了解详细信息。 -您还可以参考[联邦文档](https://github.com/kubernetes-sigs/federation-v2)，以获取有关在联合集群中部署 Ingress 的详细信息。 - +不同的云厂商使用不同的技术来实现跨故障域的流量分布。详情请查阅相关 Ingress 控制器的文档。 +请查看相关[ Ingress 控制器](/zh/docs/concepts/services-networking/ingress-controllers) 的文档以了解详细信息。 +你还可以参考[联邦文档](https://github.com/kubernetes-sigs/federation-v2)，以获取有关在联合集群中部署 Ingress 的详细信息。 <!-- ## Future Work ---> -## 未来工作 -<!-- Track [SIG Network](https://github.com/kubernetes/community/tree/master/sig-network) for more details on the evolution of Ingress and related resources. You may also track the [Ingress repository](https://github.com/kubernetes/ingress/tree/master) for more details on the evolution of various Ingress controllers. --> -跟踪 [SIG 网络](https://github.com/kubernetes/community/tree/master/sig-network)以获得有关 Ingress 和相关资源演变的更多细节。您还可以跟踪 [Ingress 仓库](https://github.com/kubernetes/ingress/tree/master)以获取有关各种 Ingress 控制器的更多细节。 +## 未来工作 +跟踪 [SIG Network](https://github.com/kubernetes/community/tree/master/sig-network) +的活动以获得有关 Ingress 和相关资源演变的更多细节。 +你还可以跟踪 [Ingress 仓库](https://github.com/kubernetes/ingress/tree/master) +以获取有关各种 Ingress 控制器的更多细节。 <!-- ## Alternatives ---> -## 替代方案 -<!-- You can expose a Service in multiple ways that don't directly involve the Ingress resource: --> +## 替代方案 {#alternatives} + 不直接使用 Ingress 资源，也有多种方法暴露 Service： <!-- @@ -818,8 +847,6 @@ You can expose a Service in multiple ways that don't directly involve the Ingres * 使用 [Service.Type=LoadBalancer](/docs/concepts/services-networking/service/#loadbalancer) * 使用 [Service.Type=NodePort](/docs/concepts/services-networking/service/#nodeport) - - ## {{% heading "whatsnext" %}} <!-- @@ -827,7 +854,7 @@ You can expose a Service in multiple ways that don't directly involve the Ingres * Learn about [Ingress Controllers](/docs/concepts/services-networking/ingress-controllers/) * [Set up Ingress on Minikube with the NGINX Controller](/docs/tasks/access-application-cluster/ingress-minikube) --> -* 了解更多 [Ingress API](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#ingress-v1beta1-networking-k8s-io) -* 了解更多 [Ingress 控制器](/docs/concepts/services-networking/ingress-controllers/) -* [使用 NGINX 控制器在 Minikube 上安装 Ingress](/docs/tasks/access-application-cluster/ingress-minikube) +* 进一步了解 [Ingress API](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#ingress-v1beta1-networking-k8s-io) +* 进一步了解 [Ingress 控制器](/zh/docs/concepts/services-networking/ingress-controllers/) +* [使用 NGINX 控制器在 Minikube 上安装 Ingress](/zh/docs/tasks/access-application-cluster/ingress-minikube) diff --git a/content/zh/docs/concepts/services-networking/network-policies.md b/content/zh/docs/concepts/services-networking/network-policies.md index 2ad44866c6..784455922a 100644 --- a/content/zh/docs/concepts/services-networking/network-policies.md +++ b/content/zh/docs/concepts/services-networking/network-policies.md @@ -5,16 +5,10 @@ weight: 50 --- <!-- ---- -reviewers: -- thockin -- caseydavenport -- danwinship title: Network Policies content_type: concept weight: 50 ---- - --> +--> {{< toc >}} @@ -30,8 +24,6 @@ NetworkPolicy resources use {{< glossary_tooltip text="labels" term_id="label">} NetworkPolicy 资源使用 {{< glossary_tooltip text="标签" term_id="label">}} 选择 Pod，并定义选定 Pod 所允许的通信规则。 - - <!-- body --> <!-- @@ -42,7 +34,9 @@ Network policies are implemented by the [network plugin](/docs/concepts/extend-k ## 前提 -网络策略通过[网络插件](/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/)来实现。要使用网络策略，用户必须使用支持 NetworkPolicy 的网络解决方案。创建一个资源对象，而没有控制器来使它生效的话，是没有任何作用的。 +网络策略通过[网络插件](/zh/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/) +来实现。要使用网络策略，用户必须使用支持 NetworkPolicy 的网络解决方案。 +创建一个资源对象，而没有控制器来使它生效的话，是没有任何作用的。 <!-- ## Isolated and Non-isolated Pods @@ -53,14 +47,17 @@ Pods become isolated by having a NetworkPolicy that selects them. Once there is Network policies do not conflict; they are additive. If any policy or policies select a pod, the pod is restricted to what is allowed by the union of those policies' ingress/egress rules. Thus, order of evaluation does not affect the policy result. --> - ## 隔离和非隔离的 Pod 默认情况下，Pod 是非隔离的，它们接受任何来源的流量。 -Pod 可以通过相关的网络策略进行隔离。一旦命名空间中有网络策略选择了特定的 Pod，该 Pod 会拒绝网络策略所不允许的连接。 (命名空间下其他未被网络策略所选择的 Pod 会继续接收所有的流量) +Pod 可以通过相关的网络策略进行隔离。一旦命名空间中有网络策略选择了特定的 Pod， +该 Pod 会拒绝网络策略所不允许的连接。 +（命名空间下其他未被网络策略所选择的 Pod 会继续接收所有的流量） -网络策略不会冲突，它们是附加的。如果任何一个或多个策略选择了一个 Pod, 则该 Pod 受限于这些策略的 ingress/egress 规则的并集。因此评估的顺序并不会影响策略的结果。 +网络策略不会冲突，它们是累积的。 +如果任何一个或多个策略选择了一个 Pod, 则该 Pod 受限于这些策略的 +ingress/egress 规则的并集。因此评估的顺序并不会影响策略的结果。 <!-- ## The NetworkPolicy resource {#networkpolicy-resource} @@ -72,7 +69,7 @@ An example NetworkPolicy might look like this: ## NetworkPolicy 资源 {#networkpolicy-resource} -查看 [网络策略](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#networkpolicy-v1-networking-k8s-io) 来了解完整的资源定义。 +查看 [NetworkPolicy](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#networkpolicy-v1-networking-k8s-io) 来了解完整的资源定义。 下面是一个 NetworkPolicy 的示例: @@ -138,8 +135,9 @@ __ingress__: Each NetworkPolicy may include a list of whitelist `ingress` rules. __egress__: Each NetworkPolicy may include a list of whitelist `egress` rules. Each rule allows traffic which matches both the `to` and `ports` sections. The example policy contains a single rule, which matches traffic on a single port to any destination in `10.0.0.0/24`. --> -__必填字段__: 与所有其他的 Kubernetes 配置一样，NetworkPolicy 需要 `apiVersion`、 `kind` 和 `metadata` 字段。 关于配置文件操作的一般信息，请参考 [使用 ConfigMap 配置容器](/docs/tasks/configure-pod-container/configure-pod-configmap/), -和 [对象管理](/docs/concepts/overview/working-with-objects/object-management)。 +__必填字段__: 与所有其他的 Kubernetes 配置一样，NetworkPolicy 需要 `apiVersion`、`kind` 和 `metadata` 字段。 + 关于配置文件操作的一般信息，请参考 [使用 ConfigMap 配置容器](/zh/docs/tasks/configure-pod-container/configure-pod-configmap/), + 和[对象管理](/zh/docs/concepts/overview/working-with-objects/object-management)。 __spec__: NetworkPolicy [规约](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-architecture/api-conventions.md#spec-and-status) 中包含了在一个命名空间中定义特定网络策略所需的所有信息。 @@ -175,7 +173,7 @@ See the [Declare Network Policy](/docs/tasks/administer-cluster/declare-network- * IP 地址范围为 172.17.0.0–172.17.0.255 和 172.17.2.0–172.17.255.255（即，除了 172.17.1.0/24 之外的所有 172.17.0.0/16） 3. （Egress 规则）允许从带有 "role=db" 标签的命名空间下的任何 Pod 到 CIDR 10.0.0.0/24 下 5978 TCP 端口的连接。 -查看 [声明网络策略](/docs/getting-started-guides/network-policy/walkthrough) 来进行更多的示例演练。 +查看[声明网络策略](/zh/docs/tasks/administer-cluster/declare-network-policy/) 来进行更多的示例演练。 <!-- ## Behavior of `to` and `from` selectors @@ -362,7 +360,9 @@ This ensures that even pods that aren't selected by any other NetworkPolicy will To use this feature, you (or your cluster administrator) will need to enable the `SCTPSupport` [feature gate](/docs/reference/command-line-tools-reference/feature-gates/) for the API server with `--feature-gates=SCTPSupport=true,…`. When the feature gate is enabled, you can set the `protocol` field of a NetworkPolicy to `SCTP`. --> -要启用此特性，你（或你的集群管理员）需要通过为 API server 指定 `--feature-gates=SCTPSupport=true,…` 来启用 `SCTPSupport` [特性开关](/docs/reference/command-line-tools-reference/feature-gates/)。启用该特性开关后，用户可以将 NetworkPolicy 的 `protocol` 字段设置为 `SCTP`。 +要启用此特性，你（或你的集群管理员）需要通过为 API server 指定 `--feature-gates=SCTPSupport=true,…` +来启用 `SCTPSupport` [特性门控](/zh/docs/reference/command-line-tools-reference/feature-gates/)。 +启用该特性开关后，用户可以将 NetworkPolicy 的 `protocol` 字段设置为 `SCTP`。 <!-- You must be using a {{< glossary_tooltip text="CNI" term_id="cni" >}} plugin that supports SCTP protocol NetworkPolicies. @@ -371,20 +371,16 @@ You must be using a {{< glossary_tooltip text="CNI" term_id="cni" >}} plugin tha 必须使用支持 SCTP 协议网络策略的 {{< glossary_tooltip text="CNI" term_id="cni" >}} 插件。 {{< /note >}} - - - ## {{% heading "whatsnext" %}} - <!-- - See the [Declare Network Policy](/docs/tasks/administer-cluster/declare-network-policy/) walkthrough for further examples. - See more [recipes](https://github.com/ahmetb/kubernetes-network-policy-recipes) for common scenarios enabled by the NetworkPolicy resource. --> -- 查看 [声明网络策略](/docs/tasks/administer-cluster/declare-network-policy/) +- 查看 [声明网络策略](/zh/docs/tasks/administer-cluster/declare-network-policy/) 来进行更多的示例演练 -- 有关 NetworkPolicy 资源启用的常见场景的更多信息，请参见 [指南](https://github.com/ahmetb/kubernetes-network-policy-recipes)。 - +- 有关 NetworkPolicy 资源启用的常见场景的更多信息，请参见 + [此指南](https://github.com/ahmetb/kubernetes-network-policy-recipes)。 diff --git a/content/zh/docs/concepts/services-networking/service.md b/content/zh/docs/concepts/services-networking/service.md index b4636869d3..294738085d 100644 --- a/content/zh/docs/concepts/services-networking/service.md +++ b/content/zh/docs/concepts/services-networking/service.md @@ -1,29 +1,24 @@ --- -reviewers: -- bprashanth -title: Services +title: 服务 feature: title: 服务发现与负载均衡 description: > - 无需修改您的应用程序即可使用陌生的服务发现机制。Kubernetes 为容器提供了自己的 IP 地址和一个 DNS 名称，并且可以在它们之间实现负载平衡。 + 无需修改您的应用程序即可使用陌生的服务发现机制。Kubernetes 为容器提供了自己的 IP 地址和一个 DNS 名称，并且可以在它们之间实现负载均衡。 content_type: concept weight: 10 --- <!-- ---- -reviewers: -- bprashanth title: Services feature: title: Service discovery and load balancing description: > - No need to modify your application to use an unfamiliar service discovery mechanism. Kubernetes gives containers their own IP addresses and a single DNS name for a set of containers, and can load-balance across them. + No need to modify your application to use an unfamiliar service discovery mechanism. + Kubernetes gives containers their own IP addresses and a single DNS name for a set of containers, and can load-balance across them. content_type: concept weight: 10 ---- --> <!-- overview --> @@ -35,10 +30,9 @@ With Kubernetes you don't need to modify your application to use an unfamiliar s Kubernetes gives Pods their own IP addresses and a single DNS name for a set of Pods, and can load-balance across them. --> -使用Kubernetes，您无需修改应用程序即可使用不熟悉的服务发现机制。 -Kubernetes为Pods提供自己的IP地址和一组Pod的单个DNS名称，并且可以在它们之间进行负载平衡。 - - +使用 Kubernetes，您无需修改应用程序即可使用不熟悉的服务发现机制。 +Kubernetes 为 Pods 提供自己的 IP 地址，并为一组 Pod 提供相同的 DNS 名， +并且可以在它们之间进行负载平衡。 <!-- body --> @@ -64,19 +58,21 @@ Enter _Services_. ## 动机 -Kubernetes {{< glossary_tooltip term_id="pod" text="Pods" >}} 是有生命周期的。他们可以被创建，而且销毁不会再启动。 -如果您使用 {{<glossary_tooltip term_id ="deployment">}} 来运行您的应用程序，则它可以动态创建和销毁 Pod。 +Kubernetes {{< glossary_tooltip term_id="pod" text="Pod" >}} 是有生命周期的。 +它们可以被创建，而且销毁之后不会再启动。 +如果您使用 {{< glossary_tooltip text="Deployment" term_id="deployment">}} +来运行您的应用程序，则它可以动态创建和销毁 Pod。 每个 Pod 都有自己的 IP 地址，但是在 Deployment 中，在同一时刻运行的 Pod 集合可能与稍后运行该应用程序的 Pod 集合不同。 -这导致了一个问题： 如果一组 Pod（称为“后端”）为群集内的其他 Pod（称为“前端”）提供功能，那么前端如何找出并跟踪要连接的 IP 地址，以便前端可以使用工作量的后端部分？ +这导致了一个问题： 如果一组 Pod（称为“后端”）为群集内的其他 Pod（称为“前端”）提供功能， +那么前端如何找出并跟踪要连接的 IP 地址，以便前端可以使用工作量的后端部分？ 进入 _Services_。 <!-- ## Service resources {#service-resource} --> - ## Service 资源 {#service-resource} <!-- @@ -87,10 +83,9 @@ by a {{< glossary_tooltip text="selector" term_id="selector" >}} (see [below](#services-without-selectors) for why you might want a Service _without_ a selector). --> - -Kubernetes `Service` 定义了这样一种抽象：逻辑上的一组 `Pod`，一种可以访问它们的策略 —— 通常称为微服务。 -这一组 `Pod` 能够被 `Service` 访问到，通常是通过 {{< glossary_tooltip text="selector" term_id="selector" >}} -（查看[下面](#services-without-selectors)了解，为什么你可能需要没有 selector 的 `Service`）实现的。 +Kubernetes Service 定义了这样一种抽象：逻辑上的一组 Pod，一种可以访问它们的策略 —— 通常称为微服务。 +这一组 Pod 能够被 Service 访问到，通常是通过 {{< glossary_tooltip text="选择算符" term_id="selector" >}} +（查看[下面](#services-without-selectors)了解，为什么你可能需要没有 selector 的 Service）实现的。 <!-- For example, consider a stateless image-processing backend which is running with @@ -101,10 +96,11 @@ track of the set of backends themselves. The Service abstraction enables this decoupling. --> - -举个例子，考虑一个图片处理 backend，它运行了3个副本。这些副本是可互换的 —— frontend 不需要关心它们调用了哪个 backend 副本。 -然而组成这一组 backend 程序的 `Pod` 实际上可能会发生变化，frontend 客户端不应该也没必要知道，而且也不需要跟踪这一组 backend 的状态。 -`Service` 定义的抽象能够解耦这种关联。 +举个例子，考虑一个图片处理后端，它运行了 3 个副本。这些副本是可互换的 —— +前端不需要关心它们调用了哪个后端副本。 +然而组成这一组后端程序的 Pod 实际上可能会发生变化， +前端客户端不应该也没必要知道，而且也不需要跟踪这一组后端的状态。 +Service 定义的抽象能够解耦这种关联。 <!-- ### Cloud-native service discovery @@ -118,9 +114,11 @@ balancer in between your application and the backend Pods. --> ### 云原生服务发现 -如果您想要在应用程序中使用 Kubernetes 接口进行服务发现，则可以查询 {{< glossary_tooltip text="API server" term_id="kube-apiserver" >}} 的 endpoint 资源，只要服务中的Pod集合发生更改，端点就会更新。 +如果您想要在应用程序中使用 Kubernetes API 进行服务发现，则可以查询 +{{< glossary_tooltip text="API 服务器" term_id="kube-apiserver" >}} +的 Endpoints 资源，只要服务中的 Pod 集合发生更改，Endpoints 就会被更新。 -对于非本机应用程序，Kubernetes提供了在应用程序和后端Pod之间放置网络端口或负载均衡器的方法。 +对于非本机应用程序，Kubernetes 提供了在应用程序和后端 Pod 之间放置网络端口或负载均衡器的方法。 <!-- ## Defining a Service @@ -135,10 +133,10 @@ and carry a label `app=MyApp`: ## 定义 Service -一个 `Service` 在 Kubernetes 中是一个 REST 对象，和 `Pod` 类似。 -像所有的 REST 对象一样， `Service` 定义可以基于 `POST` 方式，请求 API server 创建新的实例。 +Service 在 Kubernetes 中是一个 REST 对象，和 Pod 类似。 +像所有的 REST 对象一样，Service 定义可以基于 `POST` 方式，请求 API server 创建新的实例。 -例如，假定有一组 `Pod`，它们对外暴露了 9376 端口，同时还被打上 `app=MyApp` 标签。 +例如，假定有一组 Pod，它们对外暴露了 9376 端口，同时还被打上 `app=MyApp` 标签。 ```yaml apiVersion: v1 @@ -166,20 +164,20 @@ The controller for the Service selector continuously scans for Pods that match its selector, and then POSTs any updates to an Endpoint object also named “my-service”. --> - -上述配置创建一个名称为 "my-service" 的 `Service` 对象，它会将请求代理到使用 TCP 端口 9376，并且具有标签 `"app=MyApp"` 的 `Pod` 上。 -Kubernetes 为该服务分配一个 IP 地址（有时称为 "集群IP" ），该 IP 地址由服务代理使用。 +上述配置创建一个名称为 "my-service" 的 Service 对象，它会将请求代理到使用 +TCP 端口 9376，并且具有标签 `"app=MyApp"` 的 Pod 上。 +Kubernetes 为该服务分配一个 IP 地址（有时称为 "集群IP"），该 IP 地址由服务代理使用。 (请参见下面的 [VIP 和 Service 代理](#virtual-ips-and-service-proxies)). -服务选择器的控制器不断扫描与其选择器匹配的 Pod，然后将所有更新发布到也称为 “my-service” 的Endpoint对象。 - -{{< note >}} +服务选择算符的控制器不断扫描与其选择器匹配的 Pod，然后将所有更新发布到也称为 +“my-service” 的 Endpoint 对象。 <!-- A Service can map _any_ incoming `port` to a `targetPort`. By default and for convenience, the `targetPort` is set to the same value as the `port` field. --> -需要注意的是， `Service` 能够将一个接收 `port` 映射到任意的 `targetPort`。 +{{< note >}} +需要注意的是，Service 能够将一个接收 `port` 映射到任意的 `targetPort`。 默认情况下，`targetPort` 将被设置为与 `port` 字段相同的值。 {{< /note >}} @@ -199,13 +197,12 @@ As many Services need to expose more than one port, Kubernetes supports multiple port definitions on a Service object. Each port definition can have the same `protocol`, or a different one. --> - -Pod中的端口定义具有名称字段，您可以在服务的 `targetTarget` 属性中引用这些名称。 +Pod 中的端口定义是有名字的，你可以在服务的 `targetTarget` 属性中引用这些名称。 即使服务中使用单个配置的名称混合使用 Pod，并且通过不同的端口号提供相同的网络协议，此功能也可以使用。 这为部署和发展服务提供了很大的灵活性。 例如，您可以更改Pods在新版本的后端软件中公开的端口号，而不会破坏客户端。 -服务的默认协议是TCP。 您还可以使用任何其他 [受支持的协议](#protocol-support)。 +服务的默认协议是TCP。 您还可以使用任何其他[受支持的协议](#protocol-support)。 由于许多服务需要公开多个端口，因此 Kubernetes 在服务对象上支持多个端口定义。 每个端口定义可以具有相同的 `protocol`，也可以具有不同的协议。 @@ -227,8 +224,7 @@ For example: In any of these scenarios you can define a Service _without_ a Pod selector. For example: --> - -### 没有 selector 的 Service +### 没有选择算符的 Service {#services-without-selectors} 服务最常见的是抽象化对 Kubernetes Pod 的访问，但是它们也可以抽象化其他种类的后端。 实例: @@ -237,7 +233,7 @@ For example: * 希望服务指向另一个 {{< glossary_tooltip term_id="namespace" >}} 中或其它集群中的服务。 * 您正在将工作负载迁移到 Kubernetes。 在评估该方法时，您仅在 Kubernetes 中运行一部分后端。 -在任何这些场景中，都能够定义没有 selector 的 `Service`。 +在任何这些场景中，都能够定义没有选择算符的 Service。 实例: ```yaml @@ -257,8 +253,8 @@ Because this Service has no selector, the corresponding Endpoint object is *not* created automatically. You can manually map the Service to the network address and port where it's running, by adding an Endpoint object manually: --> - -由于此服务没有选择器，因此 *不会* 自动创建相应的 Endpoint 对象。 您可以通过手动添加 Endpoint 对象，将服务手动映射到运行该服务的网络地址和端口： +由于此服务没有选择算符，因此 *不会* 自动创建相应的 Endpoint 对象。 +您可以通过手动添加 Endpoint 对象，将服务手动映射到运行该服务的网络地址和端口： ```yaml apiVersion: v1 @@ -272,8 +268,6 @@ subsets: - port: 9376 ``` -{{< note >}} - <!-- The endpoint IPs _must not_ be: loopback (127.0.0.0/8 for IPv4, ::1/128 for IPv6), or link-local (169.254.0.0/16 and 224.0.0.0/24 for IPv4, fe80::/64 for IPv6). @@ -282,9 +276,11 @@ Endpoint IP addresses cannot be the cluster IPs of other Kubernetes Services, because {{< glossary_tooltip term_id="kube-proxy" >}} doesn't support virtual IPs as a destination. --> - -端点 IPs _必须不可以_ : 环回( IPv4 的 127.0.0.0/8 , IPv6 的 ::1/128 ）或本地链接（IPv4 的 169.254.0.0/16 和 224.0.0.0/24，IPv6 的 fe80::/64)。 -端点 IP 地址不能是其他 Kubernetes Services 的群集 IP，因为 {{<glossary_tooltip term_id ="kube-proxy">}} 不支持将虚拟 IP 作为目标。 +{{< note >}} +端点 IPs _必须不可以_ 是：本地回路（IPv4 的 `127.0.0.0/8`, IPv6 的 `::1/128`）或 +本地链接（IPv4 的 `169.254.0.0/16` 和 `224.0.0.0/24`，IPv6 的 `fe80::/64`)。 +端点 IP 地址不能是其他 Kubernetes 服务的集群 IP，因为 +{{< glossary_tooltip term_id ="kube-proxy">}} 不支持将虚拟 IP 作为目标。 {{< /note >}} <!-- @@ -292,23 +288,22 @@ Accessing a Service without a selector works the same as if it had a selector. In the example above, traffic is routed to the single endpoint defined in the YAML: `192.0.2.42:9376` (TCP). --> - -访问没有 selector 的 `Service`，与有 selector 的 `Service` 的原理相同。 -请求将被路由到用户定义的 Endpoint， YAML中为: `192.0.2.42:9376` (TCP)。 +访问没有选择算符的 Service，与有选择算符的 Service 的原理相同。 +请求将被路由到用户定义的 Endpoint，YAML 中为：`192.0.2.42:9376`（TCP）。 <!-- An ExternalName Service is a special case of Service that does not have selectors and uses DNS names instead. For more information, see the [ExternalName](#externalname) section later in this document. --> - -ExternalName `Service` 是 `Service` 的特例，它没有 selector，也没有使用 DNS 名称代替。 +ExternalName Service 是 Service 的特例，它没有选择算符，但是使用 DNS 名称。 有关更多信息，请参阅本文档后面的[`ExternalName`](#externalname)。 <!-- ### Endpoint Slices --> ### Endpoint 切片 + {{< feature-state for_k8s_version="v1.16" state="alpha" >}} <!-- @@ -324,9 +319,30 @@ described in detail in [Endpoint Slices](/docs/concepts/services-networking/endp --> Endpoint 切片是一种 API 资源，可以为 Endpoint 提供更可扩展的替代方案。 尽管从概念上讲与 Endpoint 非常相似，但 Endpoint 切片允许跨多个资源分布网络端点。 -默认情况下，一旦到达100个 Endpoint，该 Endpoint 切片将被视为“已满”，届时将创建其他 Endpoint 切片来存储任何其他 Endpoint。 +默认情况下，一旦到达100个 Endpoint，该 Endpoint 切片将被视为“已满”， +届时将创建其他 Endpoint 切片来存储任何其他 Endpoint。 -Endpoint 切片提供了附加的属性和功能，这些属性和功能在 [Endpoint 切片](/docs/concepts/services-networking/endpoint-slices/)中进行了详细描述。 +Endpoint 切片提供了附加的属性和功能，这些属性和功能在 +[Endpoint 切片](/zh/docs/concepts/services-networking/endpoint-slices/)中有详细描述。 + +<!-- +### Application protocol + +The AppProtocol field provides a way to specify an application protocol to be +used for each Service port. + +As an alpha feature, this field is not enabled by default. To use this field, +enable the `ServiceAppProtocol` [feature +gate](/docs/reference/command-line-tools-reference/feature-gates/). +--> +### 应用程序协议 + +{{< feature-state for_k8s_version="v1.18" state="alpha" >}} + +`appProtocol` 字段提供了一种为每个 Service 端口指定应用程序协议的方式。 + +作为一个 alpha 特性，该字段默认未启用。要使用该字段，请启用 `ServiceAppProtocol` +[特性门控](/zh/docs/reference/command-line-tools-reference/feature-gates/)。 <!-- ## Virtual IPs and service proxies @@ -338,7 +354,9 @@ than [`ExternalName`](#externalname). ## VIP 和 Service 代理 {#virtual-ips-and-service-proxies} -在 Kubernetes 集群中，每个 Node 运行一个 `kube-proxy` 进程。`kube-proxy` 负责为 `Service` 实现了一种 VIP（虚拟 IP）的形式，而不是 [`ExternalName`](#externalname) 的形式。 +在 Kubernetes 集群中，每个 Node 运行一个 `kube-proxy` 进程。 +`kube-proxy` 负责为 Service 实现了一种 VIP（虚拟 IP）的形式，而不是 +[`ExternalName`](#externalname) 的形式。 <!-- ### Why not use round-robin DNS? @@ -382,9 +400,9 @@ Kubernetes v1.8 added ipvs proxy mode. ### 版本兼容性 -从Kubernetes v1.0开始，您已经可以使用 [用户空间代理模式](#proxy-mode-userspace)。 -Kubernetes v1.1添加了 iptables 模式代理，在 Kubernetes v1.2 中，kube-proxy 的 iptables 模式成为默认设置。 -Kubernetes v1.8添加了 ipvs 代理模式。 +从 Kubernetes v1.0 开始，您已经可以使用 [用户空间代理模式](#proxy-mode-userspace)。 +Kubernetes v1.1 添加了 iptables 模式代理，在 Kubernetes v1.2 中，kube-proxy 的 iptables 模式成为默认设置。 +Kubernetes v1.8 添加了 ipvs 代理模式。 <!-- ### User space proxy mode {#proxy-mode-userspace} @@ -404,19 +422,17 @@ By default, kube-proxy in userspace mode chooses a backend via a round-robin alg ![Services overview diagram for userspace proxy](/images/docs/services-userspace-overview.svg) --> - ### userspace 代理模式 {#proxy-mode-userspace} -这种模式，kube-proxy 会监视 Kubernetes master 对 `Service` 对象和 `Endpoints` 对象的添加和移除。 -对每个 `Service`，它会在本地 Node 上打开一个端口（随机选择）。 -任何连接到“代理端口”的请求，都会被代理到 `Service` 的backend `Pods` 中的某个上面（如 `Endpoints` 所报告的一样）。 -使用哪个 backend `Pod`，是 kube-proxy 基于 `SessionAffinity` 来确定的。 +这种模式，kube-proxy 会监视 Kubernetes 主控节点对 Service 对象和 Endpoints 对象的添加和移除操作。 +对每个 Service，它会在本地 Node 上打开一个端口（随机选择）。 +任何连接到“代理端口”的请求，都会被代理到 Service 的后端 `Pods` 中的某个上面（如 `Endpoints` 所报告的一样）。 +使用哪个后端 Pod，是 kube-proxy 基于 `SessionAffinity` 来确定的。 -最后，它配置 iptables 规则，捕获到达该 `Service` 的 `clusterIP`（是虚拟 IP）和 `Port` 的请求，并重定向到代理端口，代理端口再代理请求到 backend `Pod`。 +最后，它配置 iptables 规则，捕获到达该 Service 的 `clusterIP`（是虚拟 IP） +和 `Port` 的请求，并重定向到代理端口，代理端口再代理请求到后端Pod。 -默认情况下，用户空间模式下的kube-proxy通过循环算法选择后端。 - -默认的策略是，通过 round-robin 算法来选择 backend `Pod`。 +默认情况下，用户空间模式下的 kube-proxy 通过轮转算法选择后端。 ![userspace代理模式下Service概览图](/images/docs/services-userspace-overview.svg) @@ -450,18 +466,24 @@ having traffic sent via kube-proxy to a Pod that's known to have failed. --> ### iptables 代理模式 {#proxy-mode-iptables} -这种模式，kube-proxy 会监视 Kubernetes 控制节点对 `Service` 对象和 `Endpoints` 对象的添加和移除。 -对每个 `Service`，它会配置 iptables 规则，从而捕获到达该 `Service` 的 `clusterIP` 和端口的请求，进而将请求重定向到 `Service` 的一组 backend 中的某个上面。 -对于每个 `Endpoints` 对象，它也会配置 iptables 规则，这个规则会选择一个 backend 组合。 +这种模式，`kube-proxy` 会监视 Kubernetes 控制节点对 Service 对象和 Endpoints 对象的添加和移除。 +对每个 Service，它会配置 iptables 规则，从而捕获到达该 Service 的 `clusterIP` +和端口的请求，进而将请求重定向到 Service 的一组后端中的某个 Pod 上面。 +对于每个 Endpoints 对象，它也会配置 iptables 规则，这个规则会选择一个后端组合。 -默认的策略是，kube-proxy 在 iptables 模式下随机选择一个 backend。 +默认的策略是，kube-proxy 在 iptables 模式下随机选择一个后端。 -使用 iptables 处理流量具有较低的系统开销，因为流量由 Linux netfilter 处理，而无需在用户空间和内核空间之间切换。 这种方法也可能更可靠。 +使用 iptables 处理流量具有较低的系统开销，因为流量由 Linux netfilter 处理， +而无需在用户空间和内核空间之间切换。 这种方法也可能更可靠。 -如果 kube-proxy 在 iptables 模式下运行，并且所选的第一个 Pod 没有响应，则连接失败。 这与用户空间模式不同：在这种情况下，kube-proxy 将检测到与第一个 Pod 的连接已失败，并会自动使用其他后端 Pod 重试。 +如果 kube-proxy 在 iptables 模式下运行，并且所选的第一个 Pod 没有响应， +则连接失败。 +这与用户空间模式不同：在这种情况下，kube-proxy 将检测到与第一个 Pod 的连接已失败， +并会自动使用其他后端 Pod 重试。 -您可以使用 Pod [ readiness 探测器](/docs/concepts/workloads/pods/pod-lifecycle/#container-probes) -验证后端 Pod 可以正常工作，以便 iptables 模式下的 kube-proxy 仅看到测试正常的后端。 这样做意味着您避免将流量通过 kube-proxy 发送到已知已失败的Pod。 +您可以使用 Pod [就绪探测器](/zh/docs/concepts/workloads/pods/pod-lifecycle/#container-probes) +验证后端 Pod 可以正常工作，以便 iptables 模式下的 kube-proxy 仅看到测试正常的后端。 +这样做意味着您避免将流量通过 kube-proxy 发送到已知已失败的Pod。 ![iptables代理模式下Service概览图](/images/docs/services-iptables-overview.svg) @@ -493,10 +515,14 @@ these are: --> 在 `ipvs` 模式下，kube-proxy监视Kubernetes服务和端点，调用 `netlink` 接口相应地创建 IPVS 规则， -并定期将 IPVS 规则与 Kubernetes 服务和端点同步。 该控制循环可确保　IPVS　状态与所需状态匹配。 访问服务时，IPVS　将流量定向到后端Pod之一。 +并定期将 IPVS 规则与 Kubernetes 服务和端点同步。 该控制循环可确保IPVS +状态与所需状态匹配。访问服务时，IPVS 将流量定向到后端Pod之一。 -IPVS代理模式基于类似于 iptables 模式的 netfilter 挂钩函数，但是使用哈希表作为基础数据结构，并且在内核空间中工作。 -这意味着，与 iptables 模式下的 kube-proxy 相比，IPVS 模式下的 kube-proxy 重定向通信的延迟要短，并且在同步代理规则时具有更好的性能。与其他代理模式相比，IPVS 模式还支持更高的网络流量吞吐量。 +IPVS代理模式基于类似于 iptables 模式的 netfilter 挂钩函数， +但是使用哈希表作为基础数据结构，并且在内核空间中工作。 +这意味着，与 iptables 模式下的 kube-proxy 相比，IPVS 模式下的 kube-proxy +重定向通信的延迟要短，并且在同步代理规则时具有更好的性能。 +与其他代理模式相比，IPVS 模式还支持更高的网络流量吞吐量。 IPVS提供了更多选项来平衡后端Pod的流量。 这些是： @@ -507,8 +533,6 @@ IPVS提供了更多选项来平衡后端Pod的流量。 这些是： - `sed`: shortest expected delay - `nq`: never queue -{{< note >}} - <!-- To run kube-proxy in IPVS mode, you must make the IPVS Linux available on the node before you starting kube-proxy. @@ -517,12 +541,11 @@ When kube-proxy starts in IPVS proxy mode, it verifies whether IPVS kernel modules are available. If the IPVS kernel modules are not detected, then kube-proxy falls back to running in iptables proxy mode. --> - +{{< note >}} 要在 IPVS 模式下运行 kube-proxy，必须在启动 kube-proxy 之前使 IPVS Linux 在节点上可用。 当 kube-proxy 以 IPVS 代理模式启动时，它将验证 IPVS 内核模块是否可用。 如果未检测到 IPVS 内核模块，则 kube-proxy 将退回到以 iptables 代理模式运行。 - {{< /note >}} <!-- @@ -543,10 +566,15 @@ You can also set the maximum session sticky time by setting ![IPVS代理的 Services 概述图](/images/docs/services-ipvs-overview.svg) -在这些代理模型中，绑定到服务IP的流量：在客户端不了解Kubernetes或服务或Pod的任何信息的情况下，将Port代理到适当的后端。 -如果要确保每次都将来自特定客户端的连接传递到同一Pod，则可以通过将 `service.spec.sessionAffinity` 设置为 "ClientIP" (默认值是 "None")，来基于客户端的IP地址选择会话关联。 +在这些代理模型中，绑定到服务IP的流量： +在客户端不了解Kubernetes或服务或Pod的任何信息的情况下，将Port代理到适当的后端。 +如果要确保每次都将来自特定客户端的连接传递到同一 Pod， +则可以通过将 `service.spec.sessionAffinity` 设置为 "ClientIP" +（默认值是 "None"），来基于客户端的 IP 地址选择会话关联。 -您还可以通过适当设置 `service.spec.sessionAffinityConfig.clientIP.timeoutSeconds` 来设置最大会话停留时间。 （默认值为 10800 秒，即 3 小时）。 +您还可以通过适当设置 `service.spec.sessionAffinityConfig.clientIP.timeoutSeconds` +来设置最大会话停留时间。 +（默认值为 10800 秒，即 3 小时）。 <!-- ## Multi-Port Services @@ -557,12 +585,12 @@ When using multiple ports for a Service, you must give all of your ports names so that these are unambiguous. For example: --> - ## 多端口 Service 对于某些服务，您需要公开多个端口。 -Kubernetes允许您在Service对象上配置多个端口定义。 +Kubernetes 允许您在 Service 对象上配置多个端口定义。 为服务使用多个端口时，必须提供所有端口名称，以使它们无歧义。 + 例如： ```yaml @@ -584,8 +612,6 @@ spec: targetPort: 9377 ``` -{{< note >}} - <!-- As with Kubernetes {{< glossary_tooltip term_id="name" text="names">}} in general, names for ports must only contain lowercase alphanumeric characters and `-`. Port names must @@ -593,8 +619,9 @@ also start and end with an alphanumeric character. For example, the names `123-abc` and `web` are valid, but `123_abc` and `-web` are not. --> - -与一般的Kubernetes名称一样，端口名称只能包含 小写字母数字字符 和 `-`。 端口名称还必须以字母数字字符开头和结尾。 +{{< note >}} +与一般的Kubernetes名称一样，端口名称只能包含小写字母数字字符 和 `-`。 +端口名称还必须以字母数字字符开头和结尾。 例如，名称 `123-abc` 和 `web` 有效，但是 `123_abc` 和 `-web` 无效。 {{< /note >}} @@ -618,8 +645,9 @@ server will return a 422 HTTP status code to indicate that there's a problem. 在 `Service` 创建的请求中，可以通过设置 `spec.clusterIP` 字段来指定自己的集群 IP 地址。 比如，希望替换一个已经已存在的 DNS 条目，或者遗留系统已经配置了一个固定的 IP 且很难重新配置。 -用户选择的 IP 地址必须合法，并且这个 IP 地址在 `service-cluster-ip-range` CIDR 范围内，这对 API Server 来说是通过一个标识来指定的。 -如果 IP 地址不合法，API Server 会返回 HTTP 状态码 422，表示值不合法。 +用户选择的 IP 地址必须合法，并且这个 IP 地址在 `service-cluster-ip-range` CIDR 范围内， +这对 API 服务器来说是通过一个标识来指定的。 +如果 IP 地址不合法，API 服务器会返回 HTTP 状态码 422，表示值不合法。 <!-- ## Discovering services @@ -627,10 +655,9 @@ server will return a 422 HTTP status code to indicate that there's a problem. Kubernetes supports 2 primary modes of finding a Service - environment variables and DNS. --> +## 服务发现 {#discovering-services} -## 服务发现 - -Kubernetes 支持2种基本的服务发现模式 —— 环境变量和 DNS。 +Kubernetes 支持两种基本的服务发现模式 —— 环境变量和 DNS。 <!-- ### Environment variables @@ -646,13 +673,16 @@ For example, the Service `"redis-master"` which exposes TCP port 6379 and has be allocated cluster IP address 10.0.0.11, produces the following environment variables: --> - ### 环境变量 -当 `Pod` 运行在 `Node` 上，kubelet 会为每个活跃的 `Service` 添加一组环境变量。 -它同时支持 [Docker links兼容](https://docs.docker.com/userguide/dockerlinks/) 变量（查看 [makeLinkVariables](http://releases.k8s.io/{{< param "githubbranch" >}}/pkg/kubelet/envvars/envvars.go#L49)）、简单的 `{SVCNAME}_SERVICE_HOST` 和 `{SVCNAME}_SERVICE_PORT` 变量，这里 `Service` 的名称需大写，横线被转换成下划线。 +当 Pod 运行在 `Node` 上，kubelet 会为每个活跃的 Service 添加一组环境变量。 +它同时支持 [Docker links兼容](https://docs.docker.com/userguide/dockerlinks/) 变量 +（查看 [makeLinkVariables](https://releases.k8s.io/{{< param "githubbranch" >}}/pkg/kubelet/envvars/envvars.go#L49)）、 +简单的 `{SVCNAME}_SERVICE_HOST` 和 `{SVCNAME}_SERVICE_PORT` 变量。 +这里 Service 的名称需大写，横线被转换成下划线。 -举个例子，一个名称为 `"redis-master"` 的 Service 暴露了 TCP 端口 6379，同时给它分配了 Cluster IP 地址 10.0.0.11，这个 Service 生成了如下环境变量： +举个例子，一个名称为 `"redis-master"` 的 Service 暴露了 TCP 端口 6379， +同时给它分配了 Cluster IP 地址 10.0.0.11，这个 Service 生成了如下环境变量： ```shell REDIS_MASTER_SERVICE_HOST=10.0.0.11 @@ -664,8 +694,6 @@ REDIS_MASTER_PORT_6379_TCP_PORT=6379 REDIS_MASTER_PORT_6379_TCP_ADDR=10.0.0.11 ``` -{{< note >}} - <!-- When you have a Pod that needs to access a Service, and you are using the environment variable method to publish the port and cluster IP to the client @@ -675,12 +703,12 @@ Otherwise, those client Pods won't have their environment variables populated. If you only use DNS to discover the cluster IP for a Service, you don't need to worry about this ordering issue. --> +{{< note >}} +当您具有需要访问服务的Pod时，并且您正在使用环境变量方法将端口和群集 IP 发布到客户端 +Pod 时，必须在客户端 Pod 出现 *之前* 创建服务。 +否则，这些客户端 Pod 将不会设定其环境变量。 -当您具有需要访问服务的Pod时，并且您正在使用环境变量方法将端口和群集IP发布到客户端Pod时，必须在客户端Pod出现 *之前* 创建服务。 -否则，这些客户端Pod将不会设定其环境变量。 - -如果仅使用DNS查找服务的群集IP，则无需担心此设定问题。 - +如果仅使用 DNS 查找服务的群集 IP，则无需担心此设定问题。 {{< /note >}} ### DNS @@ -712,29 +740,31 @@ The Kubernetes DNS server is the only way to access `ExternalName` Services. You can find more information about `ExternalName` resolution in [DNS Pods and Services](/docs/concepts/services-networking/dns-pod-service/). --> +您可以（几乎总是应该）使用[附加组件](/zh/docs/concepts/cluster-administration/addons/) +为 Kubernetes 集群设置 DNS 服务。 -您可以（几乎总是应该）使用[附加组件](/docs/concepts/cluster-administration/addons/)为Kubernetes集群设置DNS服务。 - -支持群集的DNS服务器（例如CoreDNS）监视 Kubernetes API 中的新服务，并为每个服务创建一组 DNS 记录。 +支持群集的 DNS 服务器（例如 CoreDNS）监视 Kubernetes API 中的新服务，并为每个服务创建一组 DNS 记录。 如果在整个群集中都启用了 DNS，则所有 Pod 都应该能够通过其 DNS 名称自动解析服务。 例如，如果您在 Kubernetes 命名空间 `"my-ns"` 中有一个名为 `"my-service"` 的服务， 则控制平面和DNS服务共同为 `"my-service.my-ns"` 创建 DNS 记录。 -`"my-ns"` 命名空间中的Pod应该能够通过简单地对 `my-service` 进行名称查找来找到它（ `"my-service.my-ns"` 也可以工作）。 +`"my-ns"` 命名空间中的 Pod 应该能够通过简单地对 `my-service` 进行名称查找来找到它 +（`"my-service.my-ns"` 也可以工作）。 -其他命名空间中的Pod必须将名称限定为 `my-service.my-ns` 。 这些名称将解析为为服务分配的群集IP。 +其他命名空间中的Pod必须将名称限定为 `my-service.my-ns`。这些名称将解析为为服务分配的群集 IP。 Kubernetes 还支持命名端口的 DNS SRV（服务）记录。 -如果 `"my-service.my-ns"` 服务具有名为 `"http"`　的端口，且协议设置为`TCP`， -则可以对 `_http._tcp.my-service.my-ns` 执行DNS SRV查询查询以发现该端口号, `"http"`以及IP地址。 +如果 `"my-service.my-ns"` 服务具有名为 `"http"`　的端口，且协议设置为 TCP， +则可以对 `_http._tcp.my-service.my-ns` 执行 DNS SRV 查询查询以发现该端口号, +`"http"` 以及 IP 地址。 Kubernetes DNS 服务器是唯一的一种能够访问 `ExternalName` 类型的 Service 的方式。 -更多关于 `ExternalName` 信息可以查看[DNS Pod 和 Service](/docs/concepts/services-networking/dns-pod-service/)。 +更多关于 `ExternalName` 信息可以查看 +[DNS Pod 和 Service](/zh/docs/concepts/services-networking/dns-pod-service/)。 -## Headless Services +## Headless Services {#headless-services} <!-- - Sometimes you don't need load-balancing and a single Service IP. In this case, you can create what are termed “headless” Services, by explicitly specifying `"None"` for the cluster IP (`.spec.clusterIP`). @@ -747,26 +777,28 @@ these Services, and there is no load balancing or proxying done by the platform for them. How DNS is automatically configured depends on whether the Service has selectors defined: --> - 有时不需要或不想要负载均衡，以及单独的 Service IP。 -遇到这种情况，可以通过指定 Cluster IP（`spec.clusterIP`）的值为 `"None"` 来创建 `Headless` Service。 +遇到这种情况，可以通过指定 Cluster IP（`spec.clusterIP`）的值为 `"None"` +来创建 `Headless` Service。 -您可以使用 headless Service 与其他服务发现机制进行接口，而不必与 Kubernetes 的实现捆绑在一起。 +您可以使用无头 Service 与其他服务发现机制进行接口，而不必与 Kubernetes 的实现捆绑在一起。 -对这 headless `Service` 并不会分配 Cluster IP，kube-proxy 不会处理它们，而且平台也不会为它们进行负载均衡和路由。 -DNS 如何实现自动配置，依赖于 `Service` 是否定义了 selector。 +对这无头 Service 并不会分配 Cluster IP，kube-proxy 不会处理它们， +而且平台也不会为它们进行负载均衡和路由。 +DNS 如何实现自动配置，依赖于 Service 是否定义了选择算符。 <!-- ### With selectors For headless Services that define selectors, the endpoints controller creates `Endpoints` records in the API, and modifies the DNS configuration to return -records (addresses) that point directly to the `Pods` backing the `Service`. +records (addresses) that point directly to the `Pods` backing the Service. --> -### 配置 Selector +### 带选择算符的服务 -对定义了 selector 的 Headless Service，Endpoint 控制器在 API 中创建了 `Endpoints` 记录，并且修改 DNS 配置返回 A 记录（地址），通过这个地址直接到达 `Service` 的后端 `Pod` 上。 +对定义了选择算符的无头服务，Endpoint 控制器在 API 中创建了 Endpoints 记录， +并且修改 DNS 配置返回 A 记录（地址），通过这个地址直接到达 Service 的后端 Pod 上。 <!-- ### Without selectors @@ -780,9 +812,9 @@ either: other types. --> -### 不配置 Selector +### 无选择算符的服务 -对没有定义 selector 的 Headless Service，Endpoint 控制器不会创建 `Endpoints` 记录。 +对没有定义选择算符的无头服务，Endpoint 控制器不会创建 `Endpoints` 记录。 然而 DNS 系统会查找和配置，无论是： * `ExternalName` 类型 Service 的 CNAME 记录 @@ -820,26 +852,31 @@ The default is `ClusterIP`. You can also use [Ingress](/docs/concepts/services-networking/ingress/) to expose your Service. Ingress is not a Service type, but it acts as the entry point for your cluster. It lets you consolidate your routing rules into a single resource as it can expose multiple services under the same IP address. --> - ## 发布服务 —— 服务类型 {#publishing-services-service-types} -对一些应用（如 Frontend）的某些部分，可能希望通过外部Kubernetes 集群外部IP 地址暴露 Service。 +对一些应用（如前端）的某些部分，可能希望通过外部 Kubernetes 集群外部 IP 地址暴露 Service。 Kubernetes `ServiceTypes` 允许指定一个需要的类型的 Service，默认是 `ClusterIP` 类型。 `Type` 的取值以及行为如下： * `ClusterIP`：通过集群的内部 IP 暴露服务，选择该值，服务只能够在集群内部可以访问，这也是默认的 `ServiceType`。 - * [`NodePort`](#nodeport)：通过每个 Node 上的 IP 和静态端口（`NodePort`）暴露服务。`NodePort` 服务会路由到 `ClusterIP` 服务，这个 `ClusterIP` 服务会自动创建。通过请求 `<NodeIP>:<NodePort>`，可以从集群的外部访问一个 `NodePort` 服务。 - * [`LoadBalancer`](#loadbalancer)：使用云提供商的负载局衡器，可以向外部暴露服务。外部的负载均衡器可以路由到 `NodePort` 服务和 `ClusterIP` 服务。 - * [`ExternalName`](#externalname)：通过返回 `CNAME` 和它的值，可以将服务映射到 `externalName` 字段的内容（例如， `foo.bar.example.com`）。 + * [`NodePort`](#nodeport)：通过每个 Node 上的 IP 和静态端口（`NodePort`）暴露服务。 + `NodePort` 服务会路由到 `ClusterIP` 服务，这个 `ClusterIP` 服务会自动创建。 + 通过请求 `<NodeIP>:<NodePort>`，可以从集群的外部访问一个 `NodePort` 服务。 + * [`LoadBalancer`](#loadbalancer)：使用云提供商的负载局衡器，可以向外部暴露服务。 + 外部的负载均衡器可以路由到 `NodePort` 服务和 `ClusterIP` 服务。 + * [`ExternalName`](#externalname)：通过返回 `CNAME` 和它的值，可以将服务映射到 `externalName` + 字段的内容（例如， `foo.bar.example.com`）。 没有任何类型代理被创建。 + {{< note >}} 您需要 CoreDNS 1.7 或更高版本才能使用 `ExternalName` 类型。 {{< /note >}} -您也可以使用 [Ingress](/docs/concepts/services-networking/ingress/) 来暴露自己的服务。 -Ingress 不是服务类型，但它充当集群的入口点。 它可以将路由规则整合到一个资源中，因为它可以在同一IP地址下公开多个服务。 +您也可以使用 [Ingress](/zh/docs/concepts/services-networking/ingress/) 来暴露自己的服务。 +Ingress 不是服务类型，但它充当集群的入口点。 +它可以将路由规则整合到一个资源中，因为它可以在同一IP地址下公开多个服务。 <!-- ### Type NodePort {#nodeport} @@ -849,10 +886,23 @@ allocates a port from a range specified by `--service-node-port-range` flag (def Each node proxies that port (the same port number on every Node) into your Service. Your Service reports the allocated port in its `.spec.ports[*].nodePort` field. - If you want to specify particular IP(s) to proxy the port, you can set the `--nodeport-addresses` flag in kube-proxy to particular IP block(s); this is supported since Kubernetes v1.10. This flag takes a comma-delimited list of IP blocks (e.g. 10.0.0.0/8, 192.0.2.0/25) to specify IP address ranges that kube-proxy should consider as local to this node. +--> +### NodePort 类型 {#nodeport} + +如果将 `type` 字段设置为 `NodePort`，则 Kubernetes 控制平面将在 `--service-node-port-range` 标志指定的范围内分配端口（默认值：30000-32767）。 +每个节点将那个端口（每个节点上的相同端口号）代理到您的服务中。 +您的服务在其 `.spec.ports[*].nodePort` 字段中要求分配的端口。 + +如果您想指定特定的 IP 代理端口，则可以将 kube-proxy 中的 `--nodeport-addresses` +标志设置为特定的 IP 块。从 Kubernetes v1.10 开始支持此功能。 + +该标志采用逗号分隔的 IP 块列表（例如，`10.0.0.0/8`、`192.0.2.0/25`）来指定 +kube-proxy 应该认为是此节点本地的 IP 地址范围。 + +<!-- For example, if you start kube-proxy with the `--nodeport-addresses=127.0.0.0/8` flag, kube-proxy only selects the loopback interface for NodePort Services. The default for `--nodeport-addresses` is an empty list. This means that kube-proxy should consider all available network interfaces for NodePort. (That's also compatible with earlier Kubernetes releases). If you want a specific port number, you can specify a value in the `nodePort` @@ -861,36 +911,50 @@ the API transaction failed. This means that you need to take care about possible port collisions yourself. You also have to use a valid port number, one that's inside the range configured for NodePort use. +--> +例如，如果您使用 `--nodeport-addresses=127.0.0.0/8` 标志启动 kube-proxy，则 kube-proxy 仅选择 NodePort Services 的环回接口。 +`--nodeport-addresses` 的默认值是一个空列表。 +这意味着 kube-proxy 应该考虑 NodePort 的所有可用网络接口。 +（这也与早期的 Kubernetes 版本兼容）。 +如果需要特定的端口号，则可以在 `nodePort` 字段中指定一个值。控制平面将为您分配该端口或向API报告事务失败。 +这意味着您需要自己注意可能发生的端口冲突。您还必须使用有效的端口号，该端口号在配置用于NodePort的范围内。 + +<!-- Using a NodePort gives you the freedom to set up your own load balancing solution, to configure environments that are not fully supported by Kubernetes, or even to just expose one or more nodes' IPs directly. Note that this Service is visible as `<NodeIP>:spec.ports[*].nodePort` -and `.spec.clusterIP:spec.ports[*].port`. (If the `--nodeport-addresses` flag in kube-proxy is set, <NodeIP> would be filtered NodeIP(s).) +and `.spec.clusterIP:spec.ports[*].port`. (If the `-nodeport-addresses` flag in kube-proxy is set, <NodeIP> would be filtered NodeIP(s).) + +For example: --> - -### NodePort 类型 - -如果将 `type` 字段设置为 `NodePort`，则 Kubernetes 控制平面将在 `--service-node-port-range` 标志指定的范围内分配端口（默认值：30000-32767）。 -每个节点将那个端口（每个节点上的相同端口号）代理到您的服务中。 -您的服务在其 `.spec.ports[*].nodePort` 字段中要求分配的端口。 - -如果您想指定特定的IP代理端口，则可以将 kube-proxy 中的 `--nodeport-addresses` 标志设置为特定的IP块。从Kubernetes v1.10开始支持此功能。 - -该标志采用逗号分隔的IP块列表（例如10.0.0.0/8、192.0.2.0/25）来指定 kube-proxy 应该认为是此节点本地的IP地址范围。 - -例如，如果您使用 `--nodeport-addresses=127.0.0.0/8` 标志启动 kube-proxy，则 kube-proxy 仅选择 NodePort Services 的环回接口。 -`--nodeport-addresses` 的默认值是一个空列表。 -这意味着 kube-proxy 应该考虑 NodePort 的所有可用网络接口。 （这也与早期的Kubernetes版本兼容）。 - -如果需要特定的端口号，则可以在 `nodePort` 字段中指定一个值。 控制平面将为您分配该端口或向API报告事务失败。 -这意味着您需要自己注意可能发生的端口冲突。 您还必须使用有效的端口号，该端口号在配置用于NodePort的范围内。 - -使用 NodePort 可以让您自由设置自己的负载平衡解决方案，配置 Kubernetes 不完全支持的环境，甚至直接暴露一个或多个节点的IP。 +使用 NodePort 可以让您自由设置自己的负载平衡解决方案，配置 Kubernetes 不完全支持的环境， +甚至直接暴露一个或多个节点的 IP。 需要注意的是，Service 能够通过 `<NodeIP>:spec.ports[*].nodePort` 和 `spec.clusterIp:spec.ports[*].port` 而对外可见。 +例如： + +```yaml +apiVersion: v1 +kind: Service +metadata: + name: my-service +spec: + type: NodePort + selector: + app: MyApp + ports: + # 默认情况下，为了方便起见，`targetPort` 被设置为与 `port` 字段相同的值。 + - port: 80 + targetPort: 80 + # 可选字段 + # 默认情况下，为了方便起见，Kubernetes 控制平面会从某个范围内分配一个端口号（默认：30000-32767） + nodePort: 30007 +``` + <!-- ### Type LoadBalancer {#loadbalancer} @@ -901,10 +965,13 @@ information about the provisioned balancer is published in the Service's `.status.loadBalancer` field. For example: --> -### LoadBalancer 类型 +### LoadBalancer 类型 {#loadbalancer} + +在使用支持外部负载均衡器的云提供商的服务时，设置 `type` 的值为 `"LoadBalancer"`， +将为 Service 提供负载均衡器。 +负载均衡器是异步创建的，关于被提供的负载均衡器的信息将会通过 Service 的 +`status.loadBalancer` 字段发布出去。 -使用支持外部负载均衡器的云提供商的服务，设置 `type` 的值为 `"LoadBalancer"`，将为 `Service` 提供负载均衡器。 -负载均衡器是异步创建的，关于被提供的负载均衡器的信息将会通过 `Service` 的 `status.loadBalancer` 字段被发布出去。 实例: ```yaml @@ -937,23 +1004,21 @@ the loadBalancer is set up with an ephemeral IP address. If you specify a `loadB but your cloud provider does not support the feature, the `loadbalancerIP` field that you set is ignored. --> - -来自外部负载均衡器的流量将直接打到 backend `Pod` 上，不过实际它们是如何工作的，这要依赖于云提供商。 +来自外部负载均衡器的流量将直接重定向到后端 Pod 上，不过实际它们是如何工作的，这要依赖于云提供商。 在这些情况下，将根据用户设置的 `loadBalancerIP` 来创建负载均衡器。 某些云提供商允许设置 `loadBalancerIP`。如果没有设置 `loadBalancerIP`，将会给负载均衡器指派一个临时 IP。 如果设置了 `loadBalancerIP`，但云提供商并不支持这种特性，那么设置的 `loadBalancerIP` 值将会被忽略掉。 -{{< note >}} - <!-- If you're using SCTP, see the [caveat](#caveat-sctp-loadbalancer-service-type) below about the `LoadBalancer` Service type. --> -如果您使用的是 SCTP，请参阅下面有关 `LoadBalancer` 服务类型的 [caveat](#caveat-sctp-loadbalancer-service-type)。 +{{< note >}} +如果您使用的是 SCTP，请参阅下面有关 `LoadBalancer` 服务类型的 +[注意事项](#caveat-sctp-loadbalancer-service-type)。 {{< /note >}} -{{< note >}} <!-- On **Azure**, if you want to use a user-specified public type `loadBalancerIP`, you first need to create a static type public IP address resource. This public IP address resource should @@ -962,16 +1027,19 @@ For example, `MC_myResourceGroup_myAKSCluster_eastus`. Specify the assigned IP address as loadBalancerIP. Ensure that you have updated the securityGroupName in the cloud provider configuration file. For information about troubleshooting `CreatingLoadBalancerFailed` permission issues see, [Use a static IP address with the Azure Kubernetes Service (AKS) load balancer](https://docs.microsoft.com/en-us/azure/aks/static-ip) or [CreatingLoadBalancerFailed on AKS cluster with advanced networking](https://github.com/Azure/AKS/issues/357). --> +{{< note >}} 在 **Azure** 上，如果要使用用户指定的公共类型 `loadBalancerIP` ，则首先需要创建静态类型的公共IP地址资源。 此公共IP地址资源应与群集中其他自动创建的资源位于同一资源组中。 例如，`MC_myResourceGroup_myAKSCluster_eastus`。 -将分配的IP地址指定为loadBalancerIP。 确保您已更新云提供程序配置文件中的securityGroupName。 +将分配的IP地址指定为 loadBalancerIP。 确保您已更新云提供程序配置文件中的 securityGroupName。 有关对 `CreatingLoadBalancerFailed` 权限问题进行故障排除的信息， -请参阅 [与Azure Kubernetes服务（AKS）负载平衡器一起使用静态IP地址](https://docs.microsoft.com/en-us/azure/aks/static-ip)或[通过高级网络在AKS群集上创建LoadBalancerFailed](https://github.com/Azure/AKS/issues/357)。 +请参阅 [与Azure Kubernetes服务（AKS）负载平衡器一起使用静态IP地址](https://docs.microsoft.com/en-us/azure/aks/static-ip) +或[通过高级网络在AKS群集上创建LoadBalancerFailed](https://github.com/Azure/AKS/issues/357)。 {{< /note >}} <!-- #### Internal load balancer + In a mixed environment it is sometimes necessary to route traffic from Services inside the same (virtual) network address block. @@ -980,12 +1048,11 @@ In a split-horizon DNS environment you would need two Services to be able to rou You can achieve this by adding one the following annotations to a Service. The annotation to add depends on the cloud Service provider you're using. --> - #### 内部负载均衡器 在混合环境中，有时有必要在同一(虚拟)网络地址块内路由来自服务的流量。 -在水平分割 DNS 环境中，您需要两个服务才能将内部和外部流量都路由到您的 endpoints。 +在水平分割 DNS 环境中，您需要两个服务才能将内部和外部流量都路由到您的端点（Endpoints）。 您可以通过向服务添加以下注释之一来实现此目的。 要添加的注释取决于您使用的云服务提供商。 @@ -1010,7 +1077,7 @@ Use `cloud.google.com/load-balancer-type: "internal"` for masters with version 1 For more information, see the [docs](https://cloud.google.com/kubernetes-engine/docs/internal-load-balancing). --> 将 `cloud.google.com/load-balancer-type: "internal"` 节点用于版本1.7.0至1.7.3的主服务器。 -有关更多信息，请参见 [文档](https://cloud.google.com/kubernetes-engine/docs/internal-load-balancing). +有关更多信息，请参见[文档](https://cloud.google.com/kubernetes-engine/docs/internal-load-balancing)。 {{% /tab %}} {{% tab name="AWS" %}} ```yaml @@ -1032,6 +1099,16 @@ metadata: [...] ``` {{% /tab %}} +{{% tab name="IBM Cloud" %}} +```yaml +[...] +metadata: + name: my-service + annotations: + service.kubernetes.io/ibm-load-balancer-cloud-provider-ip-type: "private" +[...] +``` +{{% /tab %}} {{% tab name="OpenStack" %}} ```yaml [...] @@ -1102,10 +1179,10 @@ modifying the headers. In a mixed-use environment where some ports are secured and others are left unencrypted, you can use the following annotations: --> - 第二个注释指定 Pod 使用哪种协议。 对于 HTTPS 和 SSL，ELB 希望 Pod 使用证书通过加密连接对自己进行身份验证。 -HTTP 和 HTTPS 选择第7层代理：ELB 终止与用户的连接，解析标头，并在转发请求时向 `X-Forwarded-For` 标头注入用户的 IP 地址（Pod 仅在连接的另一端看到 ELB 的 IP 地址）。 +HTTP 和 HTTPS 选择第7层代理：ELB 终止与用户的连接，解析标头，并在转发请求时向 +`X-Forwarded-For` 标头注入用户的 IP 地址（Pod 仅在连接的另一端看到 ELB 的 IP 地址）。 TCP 和 SSL 选择第4层代理：ELB 转发流量而不修改报头。 @@ -1128,8 +1205,11 @@ From Kubernetes v1.9 onwards you can use [predefined AWS SSL policies](http://do To see which policies are available for use, you can use the `aws` command line tool: --> -从Kubernetes v1.9起可以使用 [预定义的 AWS SSL 策略](http://docs.aws.amazon.com/elasticloadbalancing/latest/classic/elb-security-policy-table.html) 为您的服务使用HTTPS或SSL侦听器。 +从 Kubernetes v1.9 起可以使用 +[预定义的 AWS SSL 策略](https://docs.aws.amazon.com/elasticloadbalancing/latest/classic/elb-security-policy-table.html) +为您的服务使用 HTTPS 或 SSL 侦听器。 要查看可以使用哪些策略，可以使用 `aws` 命令行工具： + ```bash aws elb describe-load-balancer-policies --query 'PolicyDescriptions[].PolicyName' ``` @@ -1139,10 +1219,8 @@ You can then specify any one of those policies using the "`service.beta.kubernetes.io/aws-load-balancer-ssl-negotiation-policy`" annotation; for example: --> - -然后，您可以使用 -"`service.beta.kubernetes.io/aws-load-balancer-ssl-negotiation-policy`" -注解; 例如： +然后，您可以使用 "`service.beta.kubernetes.io/aws-load-balancer-ssl-negotiation-policy`" 注解; +例如： ```yaml metadata: @@ -1158,10 +1236,9 @@ To enable [PROXY protocol](https://www.haproxy.org/download/1.8/doc/proxy-protoc support for clusters running on AWS, you can use the following service annotation: --> +#### AWS 上的 PROXY 协议支持 -#### AWS上的PROXY协议支持 - -为了支持在AWS上运行的集群，启用 [PROXY协议](https://www.haproxy.org/download/1.8/doc/proxy-protocol.txt), +为了支持在 AWS 上运行的集群，启用 [PROXY 协议](https://www.haproxy.org/download/1.8/doc/proxy-protocol.txt)。 您可以使用以下服务注释： ```yaml @@ -1175,17 +1252,28 @@ annotation: Since version 1.3.0, the use of this annotation applies to all ports proxied by the ELB and cannot be configured otherwise. --> - -从1.3.0版开始，此注释的使用适用于 ELB 代理的所有端口，并且不能进行其他配置。 +从 1.3.0 版开始，此注释的使用适用于 ELB 代理的所有端口，并且不能进行其他配置。 <!-- ### External IPs + If there are external IPs that route to one or more cluster nodes, Kubernetes services can be exposed on those `externalIPs`. Traffic that ingresses into the cluster with the external IP (as destination IP), on the service port, will be routed to one of the service endpoints. `externalIPs` are not managed by Kubernetes and are the responsibility of the cluster administrator. In the `ServiceSpec`, `externalIPs` can be specified along with any of the `ServiceTypes`. In the example below, "`my-service`" can be accessed by clients on "`80.11.12.10:80`"" (`externalIP:port`) +--> +### 外部 IP + +如果有一些外部 IP 地址能够路由到一个或多个集群节点，Kubernetes 服务可以在这些 +`externalIPs` 上暴露出来。 +通过外部 IP 进入集群的入站请求，如果指向的是服务的端口，会被路由到服务的末端之一。 +`externalIPs` 不受 Kubernets 管理；它们由集群管理员管理。 +在服务规约中，`externalIPs` 可以和 `ServiceTypes` 一起指定。 +在上面的例子中，客户端可以通过 "`80.11.12.10:80`" (`externalIP:port`) 访问 "`my-service`" +服务。 + ```yaml kind: Service apiVersion: v1 @@ -1202,7 +1290,6 @@ spec: externalIPs: - 80.11.12.10 ``` ---> <!-- #### ELB Access Logs on AWS @@ -1223,18 +1310,20 @@ stored. The annotation `service.beta.kubernetes.io/aws-load-balancer-access-log-s3-bucket-prefix` specifies the logical hierarchy you created for your Amazon S3 bucket. --> +#### AWS 上的 ELB 访问日志 -#### AWS上的ELB访问日志 - -有几个注释可用于管理AWS上ELB服务的访问日志。 +有几个注释可用于管理 AWS 上 ELB 服务的访问日志。 注释 `service.beta.kubernetes.io/aws-load-balancer-access-log-enabled` 控制是否启用访问日志。 -注解 `service.beta.kubernetes.io/aws-load-balancer-access-log-emit-interval` 控制发布访问日志的时间间隔（以分钟为单位）。 您可以指定5分钟或60分钟的间隔。 +注解 `service.beta.kubernetes.io/aws-load-balancer-access-log-emit-interval` +控制发布访问日志的时间间隔（以分钟为单位）。您可以指定 5 分钟或 60 分钟的间隔。 -注释 `service.beta.kubernetes.io/aws-load-balancer-access-log-s3-bucket-name` 控制存储负载均衡器访问日志的Amazon S3存储桶的名称。 +注释 `service.beta.kubernetes.io/aws-load-balancer-access-log-s3-bucket-name` +控制存储负载均衡器访问日志的 Amazon S3 存储桶的名称。 -注释 `service.beta.kubernetes.io/aws-load-balancer-access-log-s3-bucket-prefix` 指定为Amazon S3存储桶创建的逻辑层次结构。 +注释 `service.beta.kubernetes.io/aws-load-balancer-access-log-s3-bucket-prefix` +指定为 Amazon S3 存储桶创建的逻辑层次结构。 ```yaml metadata: @@ -1259,11 +1348,12 @@ to the value of `"true"`. The annotation `service.beta.kubernetes.io/aws-load-balancer-connection-draining-timeout` can also be used to set maximum time, in seconds, to keep the existing connections open before deregistering the instances. --> +#### AWS 上的连接排空 -#### AWS上的连接排空 - -可以将注释 `service.beta.kubernetes.io/aws-load-balancer-connection-draining-enabled` 设置为 `"true"` 的值来管理 ELB 的连接消耗。 -注释 `service.beta.kubernetes.io/aws-load-balancer-connection-draining-timeout` 也可以用于设置最大时间（以秒为单位），以保持现有连接在注销实例之前保持打开状态。 +可以将注解 `service.beta.kubernetes.io/aws-load-balancer-connection-draining-enabled` +设置为 `"true"` 来管理 ELB 的连接排空。 +注释 `service.beta.kubernetes.io/aws-load-balancer-connection-draining-timeout` +也可以用于设置最大时间（以秒为单位），以保持现有连接在注销实例之前保持打开状态。 ```yaml metadata: @@ -1278,53 +1368,57 @@ also be used to set maximum time, in seconds, to keep the existing connections o There are other annotations to manage Classic Elastic Load Balancers that are described below. --> - -#### 其他ELB注释 +#### 其他 ELB 注解 还有其他一些注释，用于管理经典弹性负载均衡器，如下所述。 + ```yaml metadata: name: my-service annotations: service.beta.kubernetes.io/aws-load-balancer-connection-idle-timeout: "60" - # The time, in seconds, that the connection is allowed to be idle (no data has been sent over the connection) before it is closed by the load balancer + # 按秒计的时间，表示负载均衡器关闭连接之前连接可以保持空闲 + # （连接上无数据传输）的时间长度 service.beta.kubernetes.io/aws-load-balancer-cross-zone-load-balancing-enabled: "true" - # Specifies whether cross-zone load balancing is enabled for the load balancer + # 指定该负载均衡器上是否启用跨区的负载均衡能力 service.beta.kubernetes.io/aws-load-balancer-additional-resource-tags: "environment=prod,owner=devops" - # A comma-separated list of key-value pairs which will be recorded as - # additional tags in the ELB. + # 逗号分隔列表值，每一项都是一个键-值耦对，会作为额外的标签记录于 ELB 中 service.beta.kubernetes.io/aws-load-balancer-healthcheck-healthy-threshold: "" - # The number of successive successful health checks required for a backend to - # be considered healthy for traffic. Defaults to 2, must be between 2 and 10 + # 将某后端视为健康、可接收请求之前需要达到的连续成功健康检查次数。 + # 默认为 2，必须介于 2 和 10 之间 service.beta.kubernetes.io/aws-load-balancer-healthcheck-unhealthy-threshold: "3" - # The number of unsuccessful health checks required for a backend to be - # considered unhealthy for traffic. Defaults to 6, must be between 2 and 10 + # 将某后端视为不健康、不可接收请求之前需要达到的连续不成功健康检查次数。 + # 默认为 6，必须介于 2 和 10 之间 service.beta.kubernetes.io/aws-load-balancer-healthcheck-interval: "20" - # The approximate interval, in seconds, between health checks of an - # individual instance. Defaults to 10, must be between 5 and 300 + # 对每个实例进行健康检查时，连续两次检查之间的大致间隔秒数 + # 默认为 10，必须介于 5 和 300 之间 + service.beta.kubernetes.io/aws-load-balancer-healthcheck-timeout: "5" - # The amount of time, in seconds, during which no response means a failed - # health check. This value must be less than the service.beta.kubernetes.io/aws-load-balancer-healthcheck-interval - # value. Defaults to 5, must be between 2 and 60 + # 时长秒数，在此期间没有响应意味着健康检查失败 + # 此值必须小于 service.beta.kubernetes.io/aws-load-balancer-healthcheck-interval + # 默认值为 5，必须介于 2 和 60 之间 service.beta.kubernetes.io/aws-load-balancer-extra-security-groups: "sg-53fae93f,sg-42efd82e" - # A list of additional security groups to be added to the ELB + # 要添加到 ELB 上的额外安全组列表 ``` <!-- #### Network Load Balancer support on AWS {#aws-nlb-support} --> +#### AWS 上负载均衡器支持 {#aws-nlb-support} {{< feature-state for_k8s_version="v1.15" state="beta" >}} <!-- To use a Network Load Balancer on AWS, use the annotation `service.beta.kubernetes.io/aws-load-balancer-type` with the value set to `nlb`. --> +要在 AWS 上使用网络负载均衡器，可以使用注解 +`service.beta.kubernetes.io/aws-load-balancer-type`，将其取值设为 `nlb`。 ```yaml metadata: @@ -1333,14 +1427,16 @@ To use a Network Load Balancer on AWS, use the annotation `service.beta.kubernet service.beta.kubernetes.io/aws-load-balancer-type: "nlb" ``` -{{< note >}} - <!-- NLB only works with certain instance classes; see the [AWS documentation](http://docs.aws.amazon.com/elasticloadbalancing/latest/network/target-group-register-targets.html#register-deregister-targets) on Elastic Load Balancing for a list of supported instance types. --> -NLB 仅适用于某些实例类。 有关受支持的实例类型的列表，请参见 Elastic Load Balancing 上的 [AWS文档](http://docs.aws.amazon.com/elasticloadbalancing/latest/network/target-group-register-targets.html#register-deregister-targets)。 +{{< note >}} +NLB 仅适用于某些实例类。有关受支持的实例类型的列表， +请参见 +[AWS文档](https://docs.aws.amazon.com/elasticloadbalancing/latest/network/target-group-register-targets.html#register-deregister-targets) +中关于所支持的实例类型的 Elastic Load Balancing 说明。 {{< /note >}} <!-- @@ -1354,9 +1450,18 @@ propagated to the end Pods, but this could result in uneven distribution of traffic. Nodes without any Pods for a particular LoadBalancer Service will fail the NLB Target Group's health check on the auto-assigned `.spec.healthCheckNodePort` and not receive any traffic. +--> +与经典弹性负载平衡器不同，网络负载平衡器（NLB）将客户端的 IP 地址转发到该节点。 +如果服务的 `.spec.externalTrafficPolicy` 设置为 `Cluster` ，则客户端的IP地址不会传达到最终的 Pod。 +通过将 `.spec.externalTrafficPolicy` 设置为 `Local`，客户端IP地址将传播到最终的 Pod， +但这可能导致流量分配不均。 +没有针对特定 LoadBalancer 服务的任何 Pod 的节点将无法通过自动分配的 +`.spec.healthCheckNodePort` 进行 NLB 目标组的运行状况检查，并且不会收到任何流量。 + +<!-- In order to achieve even traffic, either use a DaemonSet, or specify a -[pod anti-affinity](/docs/concepts/configuration/assign-pod-node/#affinity-and-anti-affinity) +[pod anti-affinity](/docs/concepts/scheduling-eviction/assign-pod-node/#affinity-and-anti-affinity) to not locate on the same node. You can also use NLB Services with the [internal load balancer](/docs/concepts/services-networking/service/#internal-load-balancer) @@ -1366,20 +1471,18 @@ In order for client traffic to reach instances behind an NLB, the Node security groups are modified with the following IP rules: --> -与经典弹性负载平衡器不同，网络负载平衡器（NLB）将客户端的 IP 地址转发到该节点。 如果服务的 `.spec.externalTrafficPolicy` 设置为 `Cluster` ，则客户端的IP地址不会传达到终端 Pod。 +为了获得均衡流量，请使用 DaemonSet 或指定 +[Pod 反亲和性](/zh/docs/concepts/scheduling-eviction/assign-pod-node/#affinity-and-anti-affinity) +使其不在同一节点上。 -通过将 `.spec.externalTrafficPolicy` 设置为 `Local`，客户端IP地址将传播到终端 Pod，但这可能导致流量分配不均。 -没有针对特定 LoadBalancer 服务的任何 Pod 的节点将无法通过自动分配的 `.spec.healthCheckNodePort` 进行 NLB 目标组的运行状况检查，并且不会收到任何流量。 - -为了获得平均流量，请使用DaemonSet或指定 [pod anti-affinity](/docs/concepts/configuration/assign-pod-node/#affinity-and-anti-affinity)使其不在同一节点上。 - -您还可以将NLB服务与 [内部负载平衡器](/docs/concepts/services-networking/service/#internal-load-balancer)批注一起使用。 +你还可以将 NLB 服务与[内部负载平衡器](/zh/docs/concepts/services-networking/service/#internal-load-balancer) +注解一起使用。 为了使客户端流量能够到达 NLB 后面的实例，使用以下 IP 规则修改了节点安全组： | Rule | Protocol | Port(s) | IpRange(s) | IpRange Description | |------|----------|---------|------------|---------------------| -| Health Check | TCP | NodePort(s) (`.spec.healthCheckNodePort` for `.spec.externalTrafficPolicy = Local`) | VPC CIDR | kubernetes.io/rule/nlb/health=\<loadBalancerName\> | +| Health Check | TCP | NodePort(s) (`.spec.healthCheckNodePort` for `.spec.externalTrafficPolicy=Local`) | VPC CIDR | kubernetes.io/rule/nlb/health=\<loadBalancerName\> | | Client Traffic | TCP | NodePort(s) | `.spec.loadBalancerSourceRanges` (defaults to `0.0.0.0/0`) | kubernetes.io/rule/nlb/client=\<loadBalancerName\> | | MTU Discovery | ICMP | 3,4 | `.spec.loadBalancerSourceRanges` (defaults to `0.0.0.0/0`) | kubernetes.io/rule/nlb/mtu=\<loadBalancerName\> | @@ -1387,7 +1490,6 @@ groups are modified with the following IP rules: In order to limit which client IP's can access the Network Load Balancer, specify `loadBalancerSourceRanges`. --> - 为了限制哪些客户端IP可以访问网络负载平衡器，请指定 `loadBalancerSourceRanges`。 ```yaml @@ -1396,15 +1498,13 @@ spec: - "143.231.0.0/16" ``` -{{< note >}} - <!-- If `.spec.loadBalancerSourceRanges` is not set, Kubernetes allows traffic from `0.0.0.0/0` to the Node Security Group(s). If nodes have public IP addresses, be aware that non-NLB traffic can also reach all instances in those modified security groups. --> - +{{< note >}} 如果未设置 `.spec.loadBalancerSourceRanges` ，则 Kubernetes 允许从 `0.0.0.0/0` 到节点安全组的流量。 如果节点具有公共 IP 地址，请注意，非 NLB 流量也可以到达那些修改后的安全组中的所有实例。 {{< /note >}} @@ -1419,7 +1519,7 @@ This Service definition, for example, maps the `my-service` Service in the `prod` namespace to `my.database.example.com`: --> -### 类型ExternalName {#externalname} +### ExternalName 类型 {#externalname} 类型为 ExternalName 的服务将服务映射到 DNS 名称，而不是典型的选择器，例如 `my-service` 或者 `cassandra`。 您可以使用 `spec.externalName` 参数指定这些服务。 @@ -1436,15 +1536,15 @@ spec: type: ExternalName externalName: my.database.example.com ``` -{{< note >}} <!-- ExternalName accepts an IPv4 address string, but as a DNS names comprised of digits, not as an IP address. ExternalNames that resemble IPv4 addresses are not resolved by CoreDNS or ingress-nginx because ExternalName is intended to specify a canonical DNS name. To hardcode an IP address, consider using [headless Services](#headless-services). --> - -ExternalName 接受 IPv4 地址字符串，但作为包含数字的 DNS 名称，而不是 IP 地址。 类似于 IPv4 地址的外部名称不能由 CoreDNS 或 ingress-nginx 解析，因为外部名称旨在指定规范的 DNS 名称。 +{{< note >}} +ExternalName 服务接受 IPv4 地址字符串，但作为包含数字的 DNS 名称，而不是 IP 地址。 +类似于 IPv4 地址的外部名称不能由 CoreDNS 或 ingress-nginx 解析，因为外部名称旨在指定规范的 DNS 名称。 要对 IP 地址进行硬编码，请考虑使用 [headless Services](#headless-services)。 {{< /note >}} @@ -1457,17 +1557,18 @@ forwarding. Should you later decide to move your database into your cluster, you can start its Pods, add appropriate selectors or endpoints, and change the Service's `type`. --> - -当查找主机 `my-service.prod.svc.cluster.local` 时，群集DNS服务返回 `CNAME` 记录，其值为 `my.database.example.com`。 +当查找主机 `my-service.prod.svc.cluster.local` 时，集群 DNS 服务返回 `CNAME` 记录， +其值为 `my.database.example.com`。 访问 `my-service` 的方式与其他服务的方式相同，但主要区别在于重定向发生在 DNS 级别，而不是通过代理或转发。 -如果以后您决定将数据库移到群集中，则可以启动其 Pod，添加适当的选择器或端点以及更改服务的`类型`。 +如果以后您决定将数据库移到群集中，则可以启动其 Pod，添加适当的选择器或端点以及更改服务的 `type`。 -{{< note >}} <!-- This section is indebted to the [Kubernetes Tips - Part 1](https://akomljen.com/kubernetes-tips-part-1/) blog post from [Alen Komljen](https://akomljen.com/). --> -本部分感谢 [Alen Komljen](https://akomljen.com/)的 [Kubernetes Tips - Part1](https://akomljen.com/kubernetes-tips-part-1/) 博客文章。 +{{< note >}} +本部分感谢 [Alen Komljen](https://akomljen.com/)的 +[Kubernetes Tips - Part1](https://akomljen.com/kubernetes-tips-part-1/) 博客文章。 {{< /note >}} <!-- @@ -1481,14 +1582,13 @@ of the cluster administrator. In the Service spec, `externalIPs` can be specified along with any of the `ServiceTypes`. In the example below, "`my-service`" can be accessed by clients on "`80.11.12.10:80`" (`externalIP:port`) --> +### 外部 IP {#external-ips} -### 外部 IP - -如果外部的 IP 路由到集群中一个或多个 Node 上，Kubernetes `Service` 会被暴露给这些 `externalIPs`。 -通过外部 IP（作为目的 IP 地址）进入到集群，打到 `Service` 的端口上的流量，将会被路由到 `Service` 的 Endpoint 上。 +如果外部的 IP 路由到集群中一个或多个 Node 上，Kubernetes Service 会被暴露给这些 externalIPs。 +通过外部 IP（作为目的 IP 地址）进入到集群，打到 Service 的端口上的流量，将会被路由到 Service 的 Endpoint 上。 `externalIPs` 不会被 Kubernetes 管理，它属于集群管理员的职责范畴。 -根据 `Service` 的规定，`externalIPs` 可以同任意的 `ServiceType` 来一起指定。 +根据 Service 的规定，`externalIPs` 可以同任意的 `ServiceType` 来一起指定。 在上面的例子中，`my-service` 可以在 "`80.11.12.10:80`"(`externalIP:port`) 上被客户端访问。 ```yaml @@ -1528,19 +1628,18 @@ previous. This is not strictly required on all cloud providers (e.g. Google Com not need to allocate a `NodePort` to make `LoadBalancer` work, but AWS does) but the current API requires it. --> - ## 不足之处 -为 VIP 使用 userspace 代理，将只适合小型到中型规模的集群，不能够扩展到上千 `Service` 的大型集群。 -查看 [最初设计方案](http://issue.k8s.io/1107) 获取更多细节。 +为 VIP 使用用户空间代理，将只适合小型到中型规模的集群，不能够扩展到上千 Service 的大型集群。 +查看[最初设计方案](https://issue.k8s.io/1107) 获取更多细节。 -使用 userspace 代理，隐藏了访问 `Service` 的数据包的源 IP 地址。 +使用用户空间代理，隐藏了访问 Service 的数据包的源 IP 地址。 这使得一些类型的防火墙无法起作用。 iptables 代理不会隐藏 Kubernetes 集群内部的 IP 地址，但却要求客户端请求必须通过一个负载均衡器或 Node 端口。 `Type` 字段支持嵌套功能 —— 每一层需要添加到上一层里面。 -不会严格要求所有云提供商（例如，GCE 就没必要为了使一个 `LoadBalancer` 能工作而分配一个 `NodePort`，但是 AWS 需要 ），但当前 API 是强制要求的。 - +不会严格要求所有云提供商（例如，GCE 就没必要为了使一个 `LoadBalancer` +能工作而分配一个 `NodePort`，但是 AWS 需要 ），但当前 API 是强制要求的。 <!-- ## Virtual IP implementation {#the-gory-details-of-virtual-ips} @@ -1549,10 +1648,9 @@ The previous information should be sufficient for many people who just want to use Services. However, there is a lot going on behind the scenes that may be worth understanding. --> - ## 虚拟IP实施 {#the-gory-details-of-virtual-ips} -对很多想使用 `Service` 的人来说，前面的信息应该足够了。 +对很多想使用 Service 的人来说，前面的信息应该足够了。 然而，有很多内部原理性的内容，还是值去理解的。 <!-- @@ -1561,7 +1659,7 @@ worth understanding. One of the primary philosophies of Kubernetes is that you should not be exposed to situations that could cause your actions to fail through no fault of your own. For the design of the Service resource, this means not making -you choose your own port number for a if that choice might collide with +you choose your own port number if that choice might collide with someone else's choice. That is an isolation failure. In order to allow you to choose a port number for your Services, we must @@ -1576,24 +1674,29 @@ fail with a message indicating an IP address could not be allocated. In the control plane, a background controller is responsible for creating that map (needed to support migrating from older versions of Kubernetes that used -in-memory locking). Kubernetes also uses controllers to checking for invalid +in-memory locking). Kubernetes also uses controllers to check for invalid assignments (eg due to administrator intervention) and for cleaning up allocated IP addresses that are no longer used by any Services. - --> - ### 避免冲突 Kubernetes 最主要的哲学之一，是用户不应该暴露那些能够导致他们操作失败、但又不是他们的过错的场景。 -这种场景下，让我们来看一下网络端口 —— 用户不应该必须选择一个端口号，而且该端口还有可能与其他用户的冲突。 -这就是说，在彼此隔离状态下仍然会出现失败。 +对于 Service 资源的设计，这意味着如果用户的选择有可能与他人冲突，那就不要让用户自行选择端口号。 +这是一个隔离性的失败。 -为了使用户能够为他们的 `Service` 选择一个端口号，我们必须确保不能有2个 `Service` 发生冲突。 -我们可以通过为每个 `Service` 分配它们自己的 IP 地址来实现。 +为了使用户能够为他们的 Service 选择一个端口号，我们必须确保不能有2个 Service 发生冲突。 +Kubernetes 通过为每个 Service 分配它们自己的 IP 地址来实现。 -为了保证每个 `Service` 被分配到一个唯一的 IP，需要一个内部的分配器能够原子地更新 etcd 中的一个全局分配映射表，这个更新操作要先于创建每一个 `Service`。 -为了使 `Service` 能够获取到 IP，这个映射表对象必须在注册中心存在，否则创建 `Service` 将会失败，指示一个 IP 不能被分配。 -一个后台 Controller 的职责是创建映射表（从 Kubernetes 的旧版本迁移过来，旧版本中是通过在内存中加锁的方式实现），并检查由于管理员干预和清除任意 IP 造成的不合理分配，这些 IP 被分配了但当前没有 `Service` 使用它们。 +为了保证每个 Service 被分配到一个唯一的 IP，需要一个内部的分配器能够原子地更新 +{{< glossary_tooltip term_id="etcd" >}} 中的一个全局分配映射表， +这个更新操作要先于创建每一个 Service。 +为了使 Service 能够获取到 IP，这个映射表对象必须在注册中心存在， +否则创建 Service 将会失败，指示一个 IP 不能被分配。 + +在控制平面中，一个后台 Controller 的职责是创建映射表 +（需要支持从使用了内存锁的 Kubernetes 的旧版本迁移过来）。 +同时 Kubernetes 会通过控制器检查不合理的分配（如管理员干预导致的） +以及清理已被分配但不再被任何 Service 使用的 IP 地址。 <!-- ### Service IP addresses {#ips-and-vips} @@ -1609,17 +1712,16 @@ terms of the Service's virtual IP address (and port). kube-proxy supports three proxy modes—userspace, iptables and IPVS—which each operate slightly differently. --> - ### Service IP 地址 {#ips-and-vips} -不像 `Pod` 的 IP 地址，它实际路由到一个固定的目的地，`Service` 的 IP 实际上不能通过单个主机来进行应答。 +不像 Pod 的 IP 地址，它实际路由到一个固定的目的地，Service 的 IP 实际上不能通过单个主机来进行应答。 相反，我们使用 `iptables`（Linux 中的数据包处理逻辑）来定义一个虚拟IP地址（VIP），它可以根据需要透明地进行重定向。 当客户端连接到 VIP 时，它们的流量会自动地传输到一个合适的 Endpoint。 -环境变量和 DNS，实际上会根据 `Service` 的 VIP 和端口来进行填充。 +环境变量和 DNS，实际上会根据 Service 的 VIP 和端口来进行填充。 kube-proxy支持三种代理模式: 用户空间，iptables和IPVS；它们各自的操作略有不同。 -#### Userspace +#### Userspace {#userspace} <!-- As an example, consider the image processing application described above. @@ -1640,18 +1742,15 @@ of which Pods they are actually accessing. --> 作为一个例子，考虑前面提到的图片处理应用程序。 -当创建 backend `Service` 时，Kubernetes master 会给它指派一个虚拟 IP 地址，比如 10.0.0.1。 -假设 `Service` 的端口是 1234，该 `Service` 会被集群中所有的 `kube-proxy` 实例观察到。 -当代理看到一个新的 `Service`， 它会打开一个新的端口，建立一个从该 VIP 重定向到新端口的 iptables，并开始接收请求连接。 +当创建后端 Service 时，Kubernetes master 会给它指派一个虚拟 IP 地址，比如 10.0.0.1。 +假设 Service 的端口是 1234，该 Service 会被集群中所有的 `kube-proxy` 实例观察到。 +当代理看到一个新的 Service， 它会打开一个新的端口，建立一个从该 VIP 重定向到新端口的 iptables，并开始接收请求连接。 +当一个客户端连接到一个 VIP，iptables 规则开始起作用，它会重定向该数据包到 "服务代理" 的端口。 +"服务代理" 选择一个后端，并将客户端的流量代理到后端上。 - -当一个客户端连接到一个 VIP，iptables 规则开始起作用，它会重定向该数据包到 `Service代理` 的端口。 -`Service代理` 选择一个 backend，并将客户端的流量代理到 backend 上。 - -这意味着 `Service` 的所有者能够选择任何他们想使用的端口，而不存在冲突的风险。 -客户端可以简单地连接到一个 IP 和端口，而不需要知道实际访问了哪些 `Pod`。 - +这意味着 Service 的所有者能够选择任何他们想使用的端口，而不存在冲突的风险。 +客户端可以简单地连接到一个 IP 和端口，而不需要知道实际访问了哪些 Pod。 #### iptables @@ -1675,16 +1774,18 @@ address. This same basic flow executes when traffic comes in through a node-port or through a load-balancer, though in those cases the client IP does get altered. --> - 再次考虑前面提到的图片处理应用程序。 -当创建 backend `Service` 时，Kubernetes 控制面板会给它指派一个虚拟 IP 地址，比如 10.0.0.1。 -假设 `Service` 的端口是 1234，该 `Service` 会被集群中所有的 `kube-proxy` 实例观察到。 -当代理看到一个新的 `Service`， 它会配置一系列的 iptables 规则，从 VIP 重定向到 per-`Service` 规则。 -该 per-`Service` 规则连接到 per-`Endpoint` 规则，该 per-`Endpoint` 规则会重定向（目标 NAT）到 backend。 +当创建后端 Service 时，Kubernetes 控制面板会给它指派一个虚拟 IP 地址，比如 10.0.0.1。 +假设 Service 的端口是 1234，该 Service 会被集群中所有的 `kube-proxy` 实例观察到。 +当代理看到一个新的 Service， 它会配置一系列的 iptables 规则，从 VIP 重定向到每个 Service 规则。 +该特定于服务的规则连接到特定于 Endpoint 的规则，而后者会重定向（目标地址转译）到后端。 -当一个客户端连接到一个 VIP，iptables 规则开始起作用。一个 backend 会被选择（或者根据会话亲和性，或者随机），数据包被重定向到这个 backend。 -不像 userspace 代理，数据包从来不拷贝到用户空间，kube-proxy 不是必须为该 VIP 工作而运行，并且客户端 IP 是不可更改的。 -当流量打到 Node 的端口上，或通过负载均衡器，会执行相同的基本流程，但是在那些案例中客户端 IP 是可以更改的。 +当客户端连接到一个 VIP，iptables 规则开始起作用。一个后端会被选择（或者根据会话亲和性，或者随机）， +数据包被重定向到这个后端。 +不像用户空间代理，数据包从来不拷贝到用户空间，kube-proxy 不是必须为该 VIP 工作而运行， +并且客户端 IP 是不可更改的。 +当流量打到 Node 的端口上，或通过负载均衡器，会执行相同的基本流程， +但是在那些案例中客户端 IP 是可以更改的。 #### IPVS @@ -1692,21 +1793,20 @@ through a load-balancer, though in those cases the client IP does get altered. iptables operations slow down dramatically in large scale cluster e.g 10,000 Services. IPVS is designed for load balancing and based on in-kernel hash tables. So you can achieve performance consistency in large number of Services from IPVS-based kube-proxy. Meanwhile, IPVS-based kube-proxy has more sophisticated load balancing algorithms (least conns, locality, weighted, persistence). --> - -在大规模集群（例如10,000个服务）中，iptables 操作会显着降低速度。 IPVS 专为负载平衡而设计，并基于内核内哈希表。 +在大规模集群（例如 10000 个服务）中，iptables 操作会显着降低速度。 IPVS 专为负载平衡而设计，并基于内核内哈希表。 因此，您可以通过基于 IPVS 的 kube-proxy 在大量服务中实现性能一致性。 同时，基于 IPVS 的 kube-proxy 具有更复杂的负载平衡算法（最小连接，局部性，加权，持久性）。 -## API Object +## API 对象 <!-- Service is a top-level resource in the Kubernetes REST API. You can find more details about the API object at: [Service API object](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#service-v1-core). --> -Service 是Kubernetes REST API中的顶级资源。 您可以在以下位置找到有关API对象的更多详细信息： +Service 是 Kubernetes REST API 中的顶级资源。您可以在以下位置找到有关A PI 对象的更多详细信息： [Service 对象 API](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#service-v1-core). -## Supported protocols {#protocol-support} +## 受支持的协议 {#protocol-support} ### TCP @@ -1715,7 +1815,7 @@ Service 是Kubernetes REST API中的顶级资源。 您可以在以下位置找 <!-- You can use TCP for any kind of Service, and it's the default network protocol. --> -您可以将TCP用于任何类型的服务，这是默认的网络协议。 +您可以将 TCP 用于任何类型的服务，这是默认的网络协议。 ### UDP @@ -1725,7 +1825,7 @@ You can use TCP for any kind of Service, and it's the default network protocol. You can use UDP for most Services. For type=LoadBalancer Services, UDP support depends on the cloud provider offering this facility. --> -您可以将UDP用于大多数服务。 对于 type=LoadBalancer 服务，对 UDP 的支持取决于提供此功能的云提供商。 +您可以将 UDP 用于大多数服务。 对于 type=LoadBalancer 服务，对 UDP 的支持取决于提供此功能的云提供商。 ### HTTP @@ -1738,13 +1838,12 @@ of the Service. --> 如果您的云提供商支持它，则可以在 LoadBalancer 模式下使用服务来设置外部 HTTP/HTTPS 反向代理，并将其转发到该服务的 Endpoints。 -{{< note >}} - <!-- You can also use {{< glossary_tooltip term_id="ingress" >}} in place of Service to expose HTTP / HTTPS Services. --> -您还可以使用 {{< glossary_tooltip term_id="ingress" >}} 代替 Service 来公开HTTP / HTTPS服务。 +{{< note >}} +您还可以使用 {{< glossary_tooltip text="Ingres" term_id="ingress" >}} 代替 Service 来公开 HTTP/HTTPS 服务。 {{< /note >}} <!-- @@ -1764,12 +1863,13 @@ The load balancer will send an initial series of octets describing the incoming connection, similar to this example --> -如果您的云提供商支持它(例如, [AWS](/docs/concepts/cluster-administration/cloud-providers/#aws))， -则可以在 LoadBalancer 模式下使用 Service 在 Kubernetes 本身之外配置负载均衡器，该负载均衡器将转发前缀为 [PROXY协议][PROXY protocol](https://www.haproxy.org/download/1.8/doc/proxy-protocol.txt) 的连接。 +如果您的云提供商支持它（例如, [AWS](/zh/docs/concepts/cluster-administration/cloud-providers/#aws)）， +则可以在 LoadBalancer 模式下使用 Service 在 Kubernetes 本身之外配置负载均衡器， +该负载均衡器将转发前缀为 [PROXY协议](https://www.haproxy.org/download/1.8/doc/proxy-protocol.txt) +的连接。 负载平衡器将发送一系列初始字节，描述传入的连接，类似于此示例 - ``` PROXY TCP4 192.0.2.202 10.0.42.7 12345 7\r\n ``` @@ -1784,16 +1884,17 @@ followed by the data from the client. {{< feature-state for_k8s_version="v1.12" state="alpha" >}} <!-- -Kubernetes supports SCTP as a `protocol` value in Service, Endpoint, NetworkPolicy and Pod definitions as an alpha feature. To enable this feature, the cluster administrator needs to enable the `SCTPSupport` feature gate on the apiserver, for example, `--feature-gates=SCTPSupport=true,…`. +Kubernetes supports SCTP as a `protocol` value in Service, Endpoint, NetworkPolicy and Pod definitions as an alpha feature. To enable this feature, the cluster administrator needs to enable the `SCTPSupport` feature gate on the apiserver, for example, `-feature-gates=SCTPSupport=true,…`. When the feature gate is enabled, you can set the `protocol` field of a Service, Endpoint, NetworkPolicy or Pod to `SCTP`. Kubernetes sets up the network accordingly for the SCTP associations, just like it does for TCP connections. --> -Kubernetes 支持 SCTP 作为 Service，Endpoint，NetworkPolicy 和 Pod 定义中的 `协议` 值作为alpha功能。 -要启用此功能，集群管理员需要在apiserver上启用 `SCTPSupport` 功能门，例如 `--feature-gates = SCTPSupport = true，…`。 +作为一种 alpha 功能，Kubernetes 支持 SCTP 作为 Service、Endpoint、NetworkPolicy 和 Pod 定义中的 `protocol` 值。 +要启用此功能，集群管理员需要在 API 服务器上启用 `SCTPSupport` 特性门控， +例如 `--feature-gates=SCTPSupport=true,...`。 -启用功能门后，您可以将服务，端点，NetworkPolicy或Pod的 `protocol` 字段设置为 `SCTP`。 -Kubernetes相应地为 SCTP 关联设置网络，就像为 TCP 连接一样。 +启用特性门控后，你可以将 Service、Endpoints、NetworkPolicy 或 Pod 的 `protocol` 字段设置为 `SCTP`。 +Kubernetes 相应地为 SCTP 关联设置网络，就像为 TCP 连接所做的一样。 <!-- #### Warnings {#caveat-sctp-overview} @@ -1805,14 +1906,13 @@ Kubernetes相应地为 SCTP 关联设置网络，就像为 TCP 连接一样。 ##### 支持多宿主SCTP关联 {#caveat-sctp-multihomed} -{{< warning >}} - <!-- The support of multihomed SCTP associations requires that the CNI plugin can support the assignment of multiple interfaces and IP addresses to a Pod. NAT for multihomed SCTP associations requires special logic in the corresponding kernel modules. --> -对多宿主 SCTP 关联的支持要求CNI插件可以支持将多个接口和 IP 地址分配给 Pod。 +{{< warning >}} +对多宿主 SCTP 关联的支持要求 CNI 插件可以支持将多个接口和 IP 地址分配给 Pod。 用于多宿主 SCTP 关联的 NAT 在相应的内核模块中需要特殊的逻辑。 {{< /warning >}} @@ -1821,31 +1921,32 @@ NAT for multihomed SCTP associations requires special logic in the corresponding --> ##### Service 类型为 LoadBalancer 的服务 {#caveat-sctp-loadbalancer-service-type} -{{< warning >}} <!-- You can only create a Service with `type` LoadBalancer plus `protocol` SCTP if the cloud provider's load balancer implementation supports SCTP as a protocol. Otherwise, the Service creation request is rejected. The current set of cloud load balancer providers (Azure, AWS, CloudStack, GCE, OpenStack) all lack support for SCTP. --> -如果云提供商的负载平衡器实现支持将 SCTP 作为协议，则只能使用 `类型` LoadBalancer 加上 `协议` SCTP 创建服务。 否则，服务创建请求将被拒绝。 当前的云负载平衡器提供商（Azure，AWS，CloudStack，GCE，OpenStack）都缺乏对 SCTP 的支持。 + +{{< warning >}} +如果云提供商的负载平衡器实现支持将 SCTP 作为协议，则只能使用 `type` LoadBalancer 加上 +`protocol` SCTP 创建服务。否则，服务创建请求将被拒绝。 +当前的云负载平衡器提供商（Azure、AWS、CloudStack、GCE、OpenStack）都缺乏对 SCTP 的支持。 {{< /warning >}} ##### Windows {#caveat-sctp-windows-os} -{{< warning >}} - <!-- SCTP is not supported on Windows based nodes. --> -基于Windows的节点不支持SCTP。 +{{< warning >}} +基于 Windows 的节点不支持 SCTP。 {{< /warning >}} -##### Userspace kube-proxy {#caveat-sctp-kube-proxy-userspace} - -{{< warning >}} +##### 用户空间 kube-proxy {#caveat-sctp-kube-proxy-userspace} <!-- The kube-proxy does not support the management of SCTP associations when it is in userspace mode. --> +{{< warning >}} 当 kube-proxy 处于用户空间模式时，它不支持 SCTP 关联的管理。 {{< /warning >}} @@ -1864,27 +1965,23 @@ which encompass the current ClusterIP, NodePort, and LoadBalancer modes and more --> ## 未来工作 -未来我们能预见到，代理策略可能会变得比简单的 round-robin 均衡策略有更多细微的差别，比如 master 选举或分片。 -我们也能想到，某些 `Service` 将具有 “真正” 的负载均衡器，这种情况下 VIP 将简化数据包的传输。 - -Kubernetes 项目打算为 L7（HTTP）`Service` 改进我们对它的支持。 - -Kubernetes 项目打算为 `Service` 实现更加灵活的请求进入模式，这些 `Service` 包含当前 `ClusterIP`、`NodePort` 和 `LoadBalancer` 模式，或者更多。 - +未来我们能预见到，代理策略可能会变得比简单的轮转均衡策略有更多细微的差别，比如主控节点选举或分片。 +我们也能想到，某些 Service 将具有 “真正” 的负载均衡器，这种情况下 VIP 将简化数据包的传输。 +Kubernetes 项目打算为 L7（HTTP）服务改进支持。 +Kubernetes 项目打算为 Service 实现更加灵活的请求进入模式， +这些模式包含当前的 `ClusterIP`、`NodePort` 和 `LoadBalancer` 模式，或者更多。 ## {{% heading "whatsnext" %}} - <!-- * Read [Connecting Applications with Services](/docs/concepts/services-networking/connect-applications-service/) * Read about [Ingress](/docs/concepts/services-networking/ingress/) * Read about [Endpoint Slices](/docs/concepts/services-networking/endpoint-slices/) --> -* 阅读 [Connecting Applications with Services](/docs/concepts/services-networking/connect-applications-service/) -* 阅读 [Ingress](/docs/concepts/services-networking/ingress/) -* 阅读 [Endpoint Slices](/docs/concepts/services-networking/endpoint-slices/) - +* 阅读[使用服务访问应用](/zh/docs/concepts/services-networking/connect-applications-service/) +* 阅读了解 [Ingress](/zh/docs/concepts/services-networking/ingress/) +* 阅读了解 [端点切片](/zh/docs/concepts/services-networking/endpoint-slices/) diff --git a/content/zh/docs/concepts/storage/dynamic-provisioning.md b/content/zh/docs/concepts/storage/dynamic-provisioning.md index 56ae59f48a..d2e8cff8e5 100644 --- a/content/zh/docs/concepts/storage/dynamic-provisioning.md +++ b/content/zh/docs/concepts/storage/dynamic-provisioning.md @@ -4,16 +4,9 @@ content_type: concept weight: 40 --- <!-- ---- -reviewers: -- saad-ali -- jsafrane -- thockin -- msau42 title: Dynamic Volume Provisioning content_type: concept weight: 40 ---- --> <!-- overview --> @@ -29,11 +22,9 @@ automatically provisions storage when it is requested by users. --> 动态卷供应允许按需创建存储卷。 如果没有动态供应，集群管理员必须手动地联系他们的云或存储提供商来创建新的存储卷， -然后在 Kubernetes 集群创建 [`PersistentVolume` 对象](/docs/concepts/storage/persistent-volumes/)来表示这些卷。 +然后在 Kubernetes 集群创建 [`PersistentVolume` 对象](/zh/docs/concepts/storage/persistent-volumes/)来表示这些卷。 动态供应功能消除了集群管理员预先配置存储的需要。 相反，它在用户请求时自动供应存储。 - - <!-- body --> <!-- @@ -66,12 +57,12 @@ have the ability to select from multiple storage options. More information on storage classes can be found [here](/docs/concepts/storage/storage-classes/). --> -点击[这里](/docs/concepts/storage/storage-classes/)查阅有关存储类的更多信息。 +点击[这里](/zh/docs/concepts/storage/storage-classes/)查阅有关存储类的更多信息。 <!-- ## Enabling Dynamic Provisioning --> -## 启用动态卷供应 +## 启用动态卷供应 {#enabling-dynamic-provisioning} <!-- To enable dynamic provisioning, a cluster administrator needs to pre-create @@ -176,7 +167,7 @@ can enable this behavior by: is enabled on the API server. --> - 标记一个 `StorageClass` 为 *默认*； -- 确保 [`DefaultStorageClass` 准入控制器](/docs/reference/access-authn-authz/admission-controllers/#defaultstorageclass)在 API 服务端被启用。 +- 确保 [`DefaultStorageClass` 准入控制器](/zh/docs/reference/access-authn-authz/admission-controllers/#defaultstorageclass)在 API 服务端被启用。 <!-- An administrator can mark a specific `StorageClass` as default by adding the @@ -208,8 +199,7 @@ Zones in a Region. Single-Zone storage backends should be provisioned in the Zon Pods are scheduled. This can be accomplished by setting the [Volume Binding Mode](/docs/concepts/storage/storage-classes/#volume-binding-mode). --> -在[多区域](/docs/setup/multiple-zones)集群中，Pod 可以被分散到多个区域。 +在[多区域](/zh/docs/setup/best-practices/multiple-zones/)集群中，Pod 可以被分散到多个区域。 单区域存储后端应该被供应到 Pod 被调度到的区域。 -这可以通过设置[卷绑定模式](/docs/concepts/storage/storage-classes/#volume-binding-mode)来实现。 - +这可以通过设置[卷绑定模式](/zh/docs/concepts/storage/storage-classes/#volume-binding-mode)来实现。 diff --git a/content/zh/docs/concepts/storage/storage-classes.md b/content/zh/docs/concepts/storage/storage-classes.md index 1e68f8b2a7..b2d98c25aa 100644 --- a/content/zh/docs/concepts/storage/storage-classes.md +++ b/content/zh/docs/concepts/storage/storage-classes.md @@ -1,14 +1,15 @@ --- -reviewers: -- jsafrane -- saad-ali -- thockin -- msau42 -title: Storage Classes +title: 存储类 content_type: concept weight: 30 --- +<!-- +title: Storage Classes +content_type: concept +weight: 30 +--> + <!-- overview --> <!-- @@ -16,10 +17,8 @@ This document describes the concept of a StorageClass in Kubernetes. Familiarity with [volumes](/docs/concepts/storage/volumes/) and [persistent volumes](/docs/concepts/storage/persistent-volumes) is suggested. --> -本文描述了 Kubernetes 中 StorageClass 的概念。建议先熟悉 [卷](/docs/concepts/storage/volumes/) 和 -[持久卷](/docs/concepts/storage/persistent-volumes) 的概念。 - - +本文描述了 Kubernetes 中 StorageClass 的概念。建议先熟悉 [卷](/zh/docs/concepts/storage/volumes/) 和 +[持久卷](/zh/docs/concepts/storage/persistent-volumes) 的概念。 <!-- body --> @@ -63,11 +62,12 @@ StorageClass 对象的命名很重要，用户使用这个命名来请求生成 <!-- Administrators can specify a default StorageClass just for PVCs that don't request any particular class to bind to: see the -[PersistentVolumeClaim section](/docs/concepts/storage/persistent-volumes/#class-1) +[PersistentVolumeClaim section](/docs/concepts/storage/persistent-volumes/#persistentvolumeclaims) for details. --> 管理员可以为没有申请绑定到特定 StorageClass 的 PVC 指定一个默认的存储类 ： -更多详情请参阅 [PersistentVolumeClaim 章节](/docs/concepts/storage/persistent-volumes/#class-1)。 +更多详情请参阅 +[PersistentVolumeClaim 章节](/zh/docs/concepts/storage/persistent-volumes/#persistentvolumeclaims)。 ```yaml apiVersion: storage.k8s.io/v1 @@ -134,7 +134,8 @@ the specification. Some external provisioners are listed under the repository [kubernetes-incubator/external-storage](https://github.com/kubernetes-incubator/external-storage). --> 您不限于指定此处列出的 "内置" 分配器（其名称前缀为 "kubernetes.io" 并打包在 Kubernetes 中）。 -您还可以运行和指定外部分配器，这些独立的程序遵循由 Kubernetes 定义的 [规范](https://git.k8s.io/community/contributors/design-proposals/storage/volume-provisioning.md)。 +您还可以运行和指定外部分配器，这些独立的程序遵循由 Kubernetes 定义的 +[规范](https://git.k8s.io/community/contributors/design-proposals/storage/volume-provisioning.md)。 外部供应商的作者完全可以自由决定他们的代码保存于何处、打包方式、运行方式、使用的插件（包括 Flex）等。 代码仓库 [kubernetes-sigs/sig-storage-lib-external-provisioner](https://github.com/kubernetes-sigs/sig-storage-lib-external-provisioner) 包含一个用于为外部分配器编写功能实现的类库。可以通过下面的代码仓库，查看外部分配器列表。 @@ -182,7 +183,6 @@ allows the users to resize the volume by editing the corresponding PVC object. The following types of volumes support volume expansion, when the underlying Storage Class has the field `allowVolumeExpansion` set to true. --> - PersistentVolume 可以配置为可扩展。将此功能设置为 `true` 时，允许用户通过编辑相应的 PVC 对象来调整卷大小。 当基础存储类的 `allowVolumeExpansion` 字段设置为 true 时，以下类型的卷支持卷扩展。 @@ -207,10 +207,10 @@ Volume type | Required Kubernetes version {{< /table >}} -{{< note >}} <!-- You can only use the volume expansion feature to grow a Volume, not to shrink it. --> +{{< note >}} 此功能仅可用于扩容卷，不能用于缩小卷。 {{< /note >}} @@ -240,7 +240,7 @@ the class or PV, so mount of the PV will simply fail if one is invalid. The `volumeBindingMode` field controls when [volume binding and dynamic provisioning](/docs/concepts/storage/persistent-volumes/#provisioning) should occur. --> -`volumeBindingMode` 字段控制了 [卷绑定和动态分配](/docs/concepts/storage/persistent-volumes/#provisioning) +`volumeBindingMode` 字段控制了[卷绑定和动态分配](/zh/docs/concepts/storage/persistent-volumes/#provisioning) 应该发生在什么时候。 <!-- @@ -266,10 +266,11 @@ and [taints and tolerations](/docs/concepts/configuration/taint-and-toleration). --> 集群管理员可以通过指定 `WaitForFirstConsumer` 模式来解决此问题。 该模式将延迟 PersistentVolume 的绑定和分配，直到使用该 PersistentVolumeClaim 的 Pod 被创建。 -PersistentVolume 会根据 Pod 调度约束指定的拓扑来选择或分配。这些包括但不限于 [资源需求](/docs/concepts/configuration/manage-compute-resources-container)， -[节点筛选器](/docs/concepts/configuration/assign-pod-node/#nodeselector)， -[pod 亲和性和互斥性](/docs/concepts/configuration/assign-pod-node/#affinity-and-anti-affinity), -以及 [污点和容忍度](/docs/concepts/configuration/taint-and-toleration). +PersistentVolume 会根据 Pod 调度约束指定的拓扑来选择或分配。这些包括但不限于 +[资源需求](/zh/docs/concepts/configuration/manage-resources-containers/)、 +[节点筛选器](/zh/docs/concepts/scheduling-eviction/assign-pod-node/#nodeselector)、 +[pod 亲和性和互斥性](/zh/docs/concepts/scheduling-eviction/assign-pod-node/#affinity-and-anti-affinity)、 +以及[污点和容忍度](/zh/docs/concepts/scheduling-eviction/taint-and-toleration/)。 <!-- The following plugins support `WaitForFirstConsumer` with dynamic provisioning: @@ -302,14 +303,13 @@ The following plugins support `WaitForFirstConsumer` with pre-created Persistent and pre-created PVs, but you'll need to look at the documentation for a specific CSI driver to see its supported topology keys and examples. --> - -动态配置和预先创建的 PV 也支持 [CSI卷](/docs/concepts/storage/volumes/#csi)， +动态配置和预先创建的 PV 也支持 [CSI卷](/zh/docs/concepts/storage/volumes/#csi)， 但是您需要查看特定 CSI 驱动程序的文档以查看其支持的拓扑键名和例子。 <!-- ### Allowed Topologies --> -### 允许的拓扑结构 +### 允许的拓扑结构 {#allowed-topologies} {{< feature-state for_k8s_version="v1.12" state="beta" >}} <!-- @@ -402,14 +402,22 @@ parameters: encrypting the volume. If none is supplied but `encrypted` is true, a key is generated by AWS. See AWS docs for valid ARN value. --> -* `type`：`io1`，`gp2`，`sc1`，`st1`。详细信息参见 [AWS 文档](http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/EBSVolumeTypes.html)。默认值：`gp2`。 -* `zone`(弃用)：AWS 区域。如果没有指定 `zone` 和 `zones`，通常卷会在 Kubernetes 集群节点所在的活动区域中轮询调度分配。`zone` 和 `zones` 参数不能同时使用。 -* `zones`(弃用)：以逗号分隔的 AWS 区域列表。如果没有指定 `zone` 和 `zones`，通常卷会在 Kubernetes 集群节点所在的活动区域中轮询调度分配。`zone`和`zones`参数不能同时使用。 -* `iopsPerGB`：只适用于 `io1` 卷。每 GiB 每秒 I/O 操作。AWS 卷插件将其与请求卷的大小相乘以计算 IOPS 的容量，并将其限制在 20 000 IOPS（AWS 支持的最高值，请参阅 [AWS 文档](http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/EBSVolumeTypes.html)。 +* `type`：`io1`，`gp2`，`sc1`，`st1`。详细信息参见 + [AWS 文档](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/EBSVolumeTypes.html)。默认值：`gp2`。 +* `zone`(弃用)：AWS 区域。如果没有指定 `zone` 和 `zones`， + 通常卷会在 Kubernetes 集群节点所在的活动区域中轮询调度分配。`zone` 和 `zones` 参数不能同时使用。 +* `zones`(弃用)：以逗号分隔的 AWS 区域列表。 + 如果没有指定 `zone` 和 `zones`，通常卷会在 Kubernetes 集群节点所在的活动区域中轮询调度分配。`zone`和`zones`参数不能同时使用。 +* `iopsPerGB`：只适用于 `io1` 卷。每 GiB 每秒 I/O 操作。 + AWS 卷插件将其与请求卷的大小相乘以计算 IOPS 的容量， + 并将其限制在 20000 IOPS（AWS 支持的最高值，请参阅 + [AWS 文档](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/EBSVolumeTypes.html)。 这里需要输入一个字符串，即 `"10"`，而不是 `10`。 * `fsType`：受 Kubernetes 支持的文件类型。默认值：`"ext4"`。 -* `encrypted`：指定 EBS 卷是否应该被加密。合法值为 `"true"` 或者 `"false"`。这里需要输入字符串，即 `"true"`, 而非 `true`。 -* `kmsKeyId`：可选。加密卷时使用密钥的完整 Amazon 资源名称。如果没有提供，但 `encrypted` 值为 true，AWS 生成一个密钥。关于有效的 ARN 值，请参阅 AWS 文档。 +* `encrypted`：指定 EBS 卷是否应该被加密。合法值为 `"true"` 或者 `"false"`。 + 这里需要输入字符串，即 `"true"`, 而非 `true`。 +* `kmsKeyId`：可选。加密卷时使用密钥的完整 Amazon 资源名称。 + 如果没有提供，但 `encrypted` 值为 true，AWS 生成一个密钥。关于有效的 ARN 值，请参阅 AWS 文档。 {{< note >}} <!-- @@ -445,8 +453,12 @@ parameters: * `replication-type`: `none` or `regional-pd`. Default: `none`. --> * `type`：`pd-standard` 或者 `pd-ssd`。默认：`pd-standard` -* `zone`(弃用)：GCE 区域。如果没有指定 `zone` 和 `zones`，通常卷会在 Kubernetes 集群节点所在的活动区域中轮询调度分配。`zone` 和 `zones` 参数不能同时使用。 -* `zones`(弃用)：逗号分隔的 GCE 区域列表。如果没有指定 `zone` 和 `zones`，通常卷会在 Kubernetes 集群节点所在的活动区域中轮询调度（round-robin）分配。`zone` 和 `zones` 参数不能同时使用。 +* `zone`(弃用)：GCE 区域。如果没有指定 `zone` 和 `zones`，通常 + 卷会在 Kubernetes 集群节点所在的活动区域中轮询调度分配。 + `zone` 和 `zones` 参数不能同时使用。 +* `zones`(弃用)：逗号分隔的 GCE 区域列表。如果没有指定 `zone` 和 `zones`， + 通常卷会在 Kubernetes 集群节点所在的活动区域中轮询调度（round-robin）分配。 + `zone` 和 `zones` 参数不能同时使用。 * `fstype`: `ext4` 或 `xfs`。 默认: `ext4`。宿主机操作系统必须支持所定义的文件系统类型。 * `replication-type`：`none` 或者 `regional-pd`。默认值：`none`。 @@ -465,14 +477,18 @@ specified, Kubernetes will arbitrarily choose among the specified zones. If the `zones` parameter is omitted, Kubernetes will arbitrarily choose among zones managed by the cluster. --> -如果 `replication-type` 设置为 `regional-pd`，会分配一个 [区域性持久化磁盘（Regional Persistent Disk）](https://cloud.google.com/compute/docs/disks/#repds)。在这种情况下，用户必须使用 `zones` 而非 `zone` 来指定期望的复制区域（zone）。如果指定来两个特定的区域，区域性持久化磁盘会在这两个区域里分配。如果指定了多于两个的区域，Kubernetes 会选择其中任意两个区域。如果省略了 `zones` 参数，Kubernetes 会在集群管理的区域中任意选择。 - -{{< note >}} +如果 `replication-type` 设置为 `regional-pd`，会分配一个 +[区域性持久化磁盘（Regional Persistent Disk）](https://cloud.google.com/compute/docs/disks/#repds)。 +在这种情况下，用户必须使用 `zones` 而非 `zone` 来指定期望的复制区域（zone）。 +如果指定来两个特定的区域，区域性持久化磁盘会在这两个区域里分配。 +如果指定了多于两个的区域，Kubernetes 会选择其中任意两个区域。 +如果省略了 `zones` 参数，Kubernetes 会在集群管理的区域中任意选择。 <!-- `zone` and `zones` parameters are deprecated and replaced with [allowedTopologies](#allowed-topologies) --> +{{< note >}} `zone` 和 `zones` 已被弃用并被 [allowedTopologies](#allowed-topologies) 取代。 {{< /note >}} @@ -516,11 +532,14 @@ parameters: --> * `resturl`：分配 gluster 卷的需求的 Gluster REST 服务/Heketi 服务 url。 通用格式应该是 `IPaddress:Port`，这是 GlusterFS 动态分配器的必需参数。 - 如果 Heketi 服务在 openshift/kubernetes 中安装并暴露为可路由服务，则可以使用类似于 + 如果 Heketi 服务在 OpenShift/kubernetes 中安装并暴露为可路由服务，则可以使用类似于 `http://heketi-storage-project.cloudapps.mystorage.com` 的格式，其中 fqdn 是可解析的 heketi 服务网址。 -* `restauthenabled`：Gluster REST 服务身份验证布尔值，用于启用对 REST 服务器的身份验证。如果此值为 'true'，则必须填写 `restuser` 和 `restuserkey` 或 `secretNamespace` + `secretName`。此选项已弃用，当在指定 `restuser`，`restuserkey`，`secretName` 或 `secretNamespace` 时，身份验证被启用。 +* `restauthenabled`：Gluster REST 服务身份验证布尔值，用于启用对 REST 服务器的身份验证。 + 如果此值为 'true'，则必须填写 `restuser` 和 `restuserkey` 或 `secretNamespace` + `secretName`。 + 此选项已弃用，当在指定 `restuser`、`restuserkey`、`secretName` 或 `secretNamespace` 时，身份验证被启用。 * `restuser`：在 Gluster 可信池中有权创建卷的 Gluster REST服务/Heketi 用户。 -* `restuserkey`：Gluster REST 服务/Heketi 用户的密码将被用于对 REST 服务器进行身份验证。此参数已弃用，取而代之的是 `secretNamespace` + `secretName`。 +* `restuserkey`：Gluster REST 服务/Heketi 用户的密码将被用于对 REST 服务器进行身份验证。 + 此参数已弃用，取而代之的是 `secretNamespace` + `secretName`。 <!-- * `secretNamespace`, `secretName` : Identification of Secret instance that @@ -539,7 +558,8 @@ parameters: [glusterfs-provisioning-secret.yaml](https://github.com/kubernetes/examples/tree/master/staging/persistent-volume-provisioning/glusterfs/glusterfs-secret.yaml). --> * `secretNamespace`，`secretName`：Secret 实例的标识，包含与 Gluster REST 服务交互时使用的用户密码。 - 这些参数是可选的，`secretNamespace` 和 `secretName` 都省略时使用空密码。所提供的 Secret 必须将类型设置为 "kubernetes.io/glusterfs"，例如以这种方式创建： + 这些参数是可选的，`secretNamespace` 和 `secretName` 都省略时使用空密码。 + 所提供的 Secret 必须将类型设置为 "kubernetes.io/glusterfs"，例如以这种方式创建： ``` kubectl create secret generic heketi-secret \ @@ -547,7 +567,7 @@ parameters: --namespace=default ``` - secret 的例子可以在 [glusterfs-provisioning-secret.yaml](https://github.com/kubernetes/examples/tree/master/staging/persistent-volume-provisioning/glusterfs/glusterfs-secret.yaml) 中找到。 + Secret 的例子可以在 [glusterfs-provisioning-secret.yaml](https://github.com/kubernetes/examples/tree/master/staging/persistent-volume-provisioning/glusterfs/glusterfs-secret.yaml) 中找到。 <!-- * `clusterid`: `630372ccdc720a92c681fb928f27b53f` is the ID of the cluster @@ -561,9 +581,12 @@ parameters: specified, the volume will be provisioned with a value between 2000-2147483647 which are defaults for gidMin and gidMax respectively. --> -* `clusterid`：`630372ccdc720a92c681fb928f27b53f` 是集群的 ID，当分配卷时，Heketi 将会使用这个文件。它也可以是一个 clusterid 列表，例如： +* `clusterid`：`630372ccdc720a92c681fb928f27b53f` 是集群的 ID，当分配卷时， + Heketi 将会使用这个文件。它也可以是一个 clusterid 列表，例如： `"8452344e2becec931ece4e33c4674e4e,42982310de6c63381718ccfa6d8cf397"`。这个是可选参数。 -* `gidMin`，`gidMax`：storage class GID 范围的最小值和最大值。在此范围（gidMin-gidMax）内的唯一值（GID）将用于动态分配卷。这些是可选的值。如果不指定，卷将被分配一个 2000-2147483647 之间的值，这是 gidMin 和 gidMax 的默认值。 +* `gidMin`，`gidMax`：storage class GID 范围的最小值和最大值。 + 在此范围（gidMin-gidMax）内的唯一值（GID）将用于动态分配卷。这些是可选的值。 + 如果不指定，卷将被分配一个 2000-2147483647 之间的值，这是 gidMin 和 gidMax 的默认值。 <!-- * `volumetype` : The volume type and its parameters can be configured with this @@ -587,17 +610,17 @@ parameters: deleted when the persistent volume claim is deleted. --> * `volumetype`：卷的类型及其参数可以用这个可选值进行配置。如果未声明卷类型，则由分配器决定卷的类型。 + 例如： - 例如： - 'Replica volume': `volumetype: replicate:3` 其中 '3' 是 replica 数量. - 'Disperse/EC volume': `volumetype: disperse:4:2` 其中 '4' 是数据，'2' 是冗余数量. - 'Distribute volume': `volumetype: none` + * 'Replica volume': `volumetype: replicate:3` 其中 '3' 是 replica 数量. + * 'Disperse/EC volume': `volumetype: disperse:4:2` 其中 '4' 是数据，'2' 是冗余数量. + * 'Distribute volume': `volumetype: none` - 有关可用的卷类型和管理选项，请参阅 [管理指南](https://access.redhat.com/documentation/en-US/Red_Hat_Storage/3.1/html/Administration_Guide/part-Overview.html)。 + 有关可用的卷类型和管理选项，请参阅 [管理指南](https://access.redhat.com/documentation/en-US/Red_Hat_Storage/3.1/html/Administration_Guide/part-Overview.html)。 - 更多相关的参考信息，请参阅 [如何配置 Heketi](https://github.com/heketi/heketi/wiki/Setting-up-the-topology)。 + 更多相关的参考信息，请参阅 [如何配置 Heketi](https://github.com/heketi/heketi/wiki/Setting-up-the-topology)。 - 当动态分配持久卷时，Gluster 插件自动创建名为 `gluster-dynamic-<claimname>` 的端点和 headless service。在 PVC 被删除时动态端点和 headless service 会自动被删除。 + 当动态分配持久卷时，Gluster 插件自动创建名为 `gluster-dynamic-<claimname>` 的端点和 headless service。在 PVC 被删除时动态端点和 headless service 会自动被删除。 ### OpenStack Cinder @@ -674,7 +697,11 @@ OpenStack 的内部驱动程序已经被弃用。请使用 [OpenStack 的外部 specified in the vSphere config file used to initialize the vSphere Cloud Provider. --> - `datastore`：用户也可以在 StorageClass 中指定数据存储。卷将在 storage class 中指定的数据存储上创建，在这种情况下是 `VSANDatastore`。该字段是可选的。如果未指定数据存储，则将在用于初始化 vSphere Cloud Provider 的 vSphere 配置文件中指定的数据存储上创建该卷。 + `datastore`：用户也可以在 StorageClass 中指定数据存储。 + 卷将在 storage class 中指定的数据存储上创建，在这种情况下是 `VSANDatastore`。 + 该字段是可选的。 + 如果未指定数据存储，则将在用于初始化 vSphere Cloud Provider 的 vSphere + 配置文件中指定的数据存储上创建该卷。 <!-- 3. Storage Policy Management inside kubernetes @@ -697,7 +724,10 @@ OpenStack 的内部驱动程序已经被弃用。请使用 [OpenStack 的外部 --> * 使用现有的 vCenter SPBM 策略 - vSphere 用于存储管理的最重要特性之一是基于策略的管理。基于存储策略的管理（SPBM）是一个存储策略框架，提供单一的统一控制平面的跨越广泛的数据服务和存储解决方案。 SPBM 使能 vSphere 管理员克服先期的存储配置挑战，如容量规划，差异化服务等级和管理容量空间。 + vSphere 用于存储管理的最重要特性之一是基于策略的管理。 + 基于存储策略的管理（SPBM）是一个存储策略框架，提供单一的统一控制平面的 + 跨越广泛的数据服务和存储解决方案。 + SPBM 使能 vSphere 管理员克服先期的存储配置挑战，如容量规划，差异化服务等级和管理容量空间。 SPBM 策略可以在 StorageClass 中使用 `storagePolicyName` 参数声明。 @@ -719,7 +749,10 @@ OpenStack 的内部驱动程序已经被弃用。请使用 [OpenStack 的外部 --> * Kubernetes 内的 Virtual SAN 策略支持 - Vsphere Infrastructure（VI）管理员将能够在动态卷配置期间指定自定义 Virtual SAN 存储功能。您现在可以定义存储需求，例如性能和可用性，当动态卷供分配时会以存储功能的形式提供。存储功能需求会转换为 Virtual SAN 策略，然后当 persistent volume（虚拟磁盘）在创建时，会将其推送到 Virtual SAN 层。虚拟磁盘分布在 Virtual SAN 数据存储中以满足要求。 + Vsphere Infrastructure（VI）管理员将能够在动态卷配置期间指定自定义 Virtual SAN + 存储功能。您现在可以定义存储需求，例如性能和可用性，当动态卷供分配时会以存储功能的形式提供。 + 存储功能需求会转换为 Virtual SAN 策略，然后当持久卷（虚拟磁盘）在创建时， + 会将其推送到 Virtual SAN 层。虚拟磁盘分布在 Virtual SAN 数据存储中以满足要求。 更多有关 persistent volume 管理的存储策略的详细信息， 您可以参考 [基于存储策略的动态分配卷管理](https://vmware.github.io/vsphere-storage-for-kubernetes/documentation/policy-based-mgmt.html)。 @@ -955,7 +988,8 @@ parameters: * `kind`：可能的值是 `shared`（默认）、`dedicated` 和 `managed`。 当 `kind` 的值是 `shared` 时，所有非托管磁盘都在集群的同一个资源组中的几个共享存储帐户中创建。 当 `kind` 的值是 `dedicated` 时，将为在集群的同一个资源组中新的非托管磁盘创建新的专用存储帐户。 -* `resourceGroup`: 指定要创建 Azure 磁盘所属的资源组。必须是已存在的资源组名称。若未指定资源组，磁盘会默认放入与当前 Kubernetes 集群相同的资源组中。 +* `resourceGroup`: 指定要创建 Azure 磁盘所属的资源组。必须是已存在的资源组名称。 + 若未指定资源组，磁盘会默认放入与当前 Kubernetes 集群相同的资源组中。 <!-- - Premium VM can attach both Standard_LRS and Premium_LRS disks, while Standard VM can only attach Standard_LRS disks. @@ -1015,7 +1049,8 @@ mounting credentials. If the cluster has enabled both add the `create` permission of resource `secret` for clusterrole `system:controller:persistent-volume-binder`. --> -在存储分配期间，为挂载凭证创建一个名为 `secretName` 的 secret。如果集群同时启用了 [RBAC](/docs/admin/authorization/rbac/) 和 [Controller Roles](/docs/admin/authorization/rbac/#controller-roles)， +在存储分配期间，为挂载凭证创建一个名为 `secretName` 的 Secret。如果集群同时启用了 +[RBAC](/zh/docs/reference/access-authn-authz/rbac/) 和 [控制器角色](/zh/docs/reference/access-authn-authz/rbac/#controller-roles)， 为 `system:controller:persistent-volume-binder` 的 clusterrole 添加 `secret` 资源的 `create` 权限。 <!-- @@ -1040,7 +1075,7 @@ provisioner: kubernetes.io/portworx-volume parameters: repl: "1" snap_interval: "70" - io_priority: "high" + priority_io: "high" ``` @@ -1050,7 +1085,7 @@ parameters: * `repl`: number of synchronous replicas to be provided in the form of replication factor `1..3` (default: `1`) A string is expected here i.e. `"1"` and not `1`. -* `io_priority`: determines whether the volume will be created from higher +* `priority_io`: determines whether the volume will be created from higher performance or a lower priority storage `high/medium/low` (default: `low`). * `snap_interval`: clock/time interval in minutes for when to trigger snapshots. Snapshots are incremental based on difference with the prior snapshot, 0 @@ -1075,7 +1110,8 @@ parameters: * `aggregation_level`：指定卷分配到的块数量，0 表示一个非聚合卷（默认：`0`）。 这里需要填写字符串，即，是 `"0"` 而不是 `0`。 * `ephemeral`：指定卷在卸载后进行清理还是持久化。 `emptyDir` 的使用场景可以将这个值设置为 true ， - `persistent volumes` 的使用场景可以将这个值设置为 false（例如 Cassandra 这样的数据库）`true/false`（默认为 `false`）。这里需要填写字符串，即，是 `"true"` 而不是 `true`。 + `persistent volumes` 的使用场景可以将这个值设置为 false（例如 Cassandra 这样的数据库） + `true/false`（默认为 `false`）。这里需要填写字符串，即，是 `"true"` 而不是 `true`。 ### ScaleIO @@ -1136,8 +1172,8 @@ secret 必须用 `kubernetes.io/scaleio` 类型创建，并与引用它的 PVC ```shell kubectl create secret generic sio-secret --type="kubernetes.io/scaleio" \ ---from-literal=username=sioadmin --from-literal=password=d2NABDNjMA== \ ---namespace=default + --from-literal=username=sioadmin --from-literal=password=d2NABDNjMA== \ + --namespace=default ``` ### StorageOS diff --git a/content/zh/docs/concepts/storage/volume-pvc-datasource.md b/content/zh/docs/concepts/storage/volume-pvc-datasource.md index 755fa2588d..96838d402e 100644 --- a/content/zh/docs/concepts/storage/volume-pvc-datasource.md +++ b/content/zh/docs/concepts/storage/volume-pvc-datasource.md @@ -5,16 +5,9 @@ weight: 30 --- <!-- ---- -reviewers: -- jsafrane -- saad-ali -- thockin -- msau42 title: CSI Volume Cloning content_type: concept weight: 30 ---- --> <!-- overview --> @@ -22,42 +15,40 @@ weight: 30 <!-- This document describes the concept of cloning existing CSI Volumes in Kubernetes. Familiarity with [Volumes](/docs/concepts/storage/volumes) is suggested. --> - -本文档介绍 Kubernetes 中克隆现有 CSI 卷的概念。阅读前建议先熟悉[卷](/docs/concepts/storage/volumes)。 - - - +本文档介绍 Kubernetes 中克隆现有 CSI 卷的概念。阅读前建议先熟悉[卷](/zh/docs/concepts/storage/volumes)。 <!-- body --> <!-- ## Introduction + +The {{< glossary_tooltip text="CSI" term_id="csi" >}} Volume Cloning feature adds support for specifying existing {{< glossary_tooltip text="PVC" term_id="persistent-volume-claim" >}}s in the `dataSource` field to indicate a user would like to clone a {{< glossary_tooltip term_id="volume" >}}. --> ## 介绍 -<!-- -The {{< glossary_tooltip text="CSI" term_id="csi" >}} Volume Cloning feature adds support for specifying existing {{< glossary_tooltip text="PVC" term_id="persistent-volume-claim" >}}s in the `dataSource` field to indicate a user would like to clone a {{< glossary_tooltip term_id="volume" >}}. ---> - -{{< glossary_tooltip text="CSI" term_id="csi" >}} 卷克隆功能增加了通过在 `dataSource` 字段中指定存在的 {{< glossary_tooltip text="PVC" term_id="persistent-volume-claim" >}}s，来表示用户想要克隆的 {{< glossary_tooltip term_id="volume" >}}。 +{{< glossary_tooltip text="CSI" term_id="csi" >}} 卷克隆功能增加了通过在 +`dataSource` 字段中指定存在的 +{{< glossary_tooltip text="PVC" term_id="persistent-volume-claim" >}}， +来表示用户想要克隆的 {{< glossary_tooltip term_id="volume" >}}。 <!-- A Clone is defined as a duplicate of an existing Kubernetes Volume that can be consumed as any standard Volume would be. The only difference is that upon provisioning, rather than creating a "new" empty Volume, the back end device creates an exact duplicate of the specified Volume. --> -克隆，意思是为已有的 Kubernetes 卷创建副本，它可以像任何其它标准卷一样被使用。唯一的区别就是配置后，后端设备将创建指定完全相同的副本，而不是创建一个“新的”空卷。 +克隆，意思是为已有的 Kubernetes 卷创建副本，它可以像任何其它标准卷一样被使用。 +唯一的区别就是配置后，后端设备将创建指定完全相同的副本，而不是创建一个“新的”空卷。 <!-- The implementation of cloning, from the perspective of the Kubernetes API, simply adds the ability to specify an existing PVC as a dataSource during new PVC creation. The source PVC must be bound and available (not in use). ---> -从 Kubernetes API 的角度看，克隆的实现只是在创建新的 PVC 时，增加了指定一个现有 PVC 作为数据源的能力。源 PVC 必须是 bound 状态且可用的（不在使用中）。 - -<!-- Users need to be aware of the following when using this feature: --> +从 Kubernetes API 的角度看，克隆的实现只是在创建新的 PVC 时， +增加了指定一个现有 PVC 作为数据源的能力。源 PVC 必须是 bound +状态且可用的（不在使用中）。 + 用户在使用该功能时，需要注意以下事项： <!-- @@ -78,18 +69,15 @@ Users need to be aware of the following when using this feature: * 仅在同一存储类中支持克隆。 - 目标卷必须和源卷具有相同的存储类 - 可以使用默认的存储类并且 storageClassName 字段在规格中忽略了 -* 克隆只能在两个使用相同 VolumeMode 设置的卷中进行（如果请求克隆一个块存储模式的卷，源卷必须也是块存储模式）。 - +* 克隆只能在两个使用相同 VolumeMode 设置的卷中进行 + （如果请求克隆一个块存储模式的卷，源卷必须也是块存储模式）。 <!-- ## Provisioning ---> -## 供应 - -<!-- Clones are provisioned just like any other PVC with the exception of adding a dataSource that references an existing PVC in the same namespace. --> +## 供应 克隆卷与其他任何 PVC 一样配置，除了需要增加 dataSource 来引用同一命名空间中现有的 PVC。 @@ -112,7 +100,8 @@ spec: ``` <!-- -You must specify a capacity value for `spec.resources.requests.storage`, and the value you specify must be the same or larger than the capacity of the source volume. +You must specify a capacity value for `spec.resources.requests.storage`, +and the value you specify must be the same or larger than the capacity of the source volume. --> {{< note >}} @@ -127,14 +116,14 @@ The result is a new PVC with the name `clone-of-pvc-1` that has the exact same c <!-- ## Usage + +Upon availability of the new PVC, the cloned PVC is consumed the same as other PVC. It's also expected at this point that the newly created PVC is an independent object. It can be consumed, cloned, snapshotted, or deleted independently and without consideration for it's original dataSource PVC. This also implies that the source is not linked in any way to the newly created clone, it may also be modified or deleted without affecting the newly created clone. --> ## 用法 -<!-- -Upon availability of the new PVC, the cloned PVC is consumed the same as other PVC. It's also expected at this point that the newly created PVC is an independent object. It can be consumed, cloned, snapshotted, or deleted independently and without consideration for it's original dataSource PVC. This also implies that the source is not linked in any way to the newly created clone, it may also be modified or deleted without affecting the newly created clone. ---> - -一旦新的 PVC 可用，被克隆的 PVC 项其他 PVC 一样被使用。可以预期的是，新创建的 PVC 是一个独立的对象。可以独立使用，克隆，快照或删除它，而不需要考虑它的原始数据源 PVC。这也意味着，源没有以任何方式链接到新创建的 PVC，它也可以被修改或删除，而不会影响到新创建的克隆。 - +一旦新的 PVC 可用，被克隆的 PVC 像其他 PVC 一样被使用。 +可以预期的是，新创建的 PVC 是一个独立的对象。 +可以独立使用、克隆、快照或删除它，而不需要考虑它的原始数据源 PVC。 +这也意味着，源没有以任何方式链接到新创建的 PVC，它也可以被修改或删除，而不会影响到新创建的克隆。 diff --git a/content/zh/docs/concepts/storage/volume-snapshots.md b/content/zh/docs/concepts/storage/volume-snapshots.md index f729f4b923..aaa68a342d 100644 --- a/content/zh/docs/concepts/storage/volume-snapshots.md +++ b/content/zh/docs/concepts/storage/volume-snapshots.md @@ -5,18 +5,9 @@ weight: 20 --- <!-- ---- -reviewers: -- saad-ali -- thockin -- msau42 -- jingxu97 -- xing-yang -- yuxiangqian title: Volume Snapshots content_type: concept weight: 20 ---- --> <!-- overview --> @@ -26,9 +17,8 @@ weight: 20 <!-- In Kubernetes, a _VolumeSnapshot_ represents a snapshot of a volume on a storage system. This document assumes that you are already familiar with Kubernetes [persistent volumes](/docs/concepts/storage/persistent-volumes/). --> -在 Kubernetes 中，卷快照是一个存储系统上卷的快照，本文假设你已经熟悉了 Kubernetes 的 [持久卷](/docs/concepts/storage/persistent-volumes/)。 - - +在 Kubernetes 中，卷快照是一个存储系统上卷的快照，本文假设你已经熟悉了 Kubernetes +的 [持久卷](/zh/docs/concepts/storage/persistent-volumes/)。 <!-- body --> @@ -108,7 +98,9 @@ Instead of using a pre-existing snapshot, you can request that a snapshot to be --> #### 动态的 {#dynamic} -可以从 `PersistentVolumeClaim` 中动态获取快照，而不用使用已经存在的快照。在获取快照时，[卷快照类](/docs/concepts/storage/volume-snapshot-classes/)指定要用的特定于存储提供程序的参数。 +可以从 `PersistentVolumeClaim` 中动态获取快照，而不用使用已经存在的快照。 +在获取快照时，[卷快照类](/zh/docs/concepts/storage/volume-snapshot-classes/) +指定要用的特定于存储提供程序的参数。 <!-- ### Binding @@ -181,12 +173,14 @@ using the attribute `volumeSnapshotClassName`. If nothing is set, then the defau --> `persistentVolumeClaimName` 是 `PersistentVolumeClaim` 数据源对快照的名称。这个字段是动态配置快照中的必填字段。 -卷快照可以通过指定 [VolumeSnapshotClass](/docs/concepts/storage/volume-snapshot-classes/) 使用 `volumeSnapshotClassName` 属性来请求特定类。如果没有设置，那么使用默认类（如果有）。 +卷快照可以通过指定 [VolumeSnapshotClass](/zh/docs/concepts/storage/volume-snapshot-classes/) +使用 `volumeSnapshotClassName` 属性来请求特定类。如果没有设置，那么使用默认类（如果有）。 <!-- For pre-provisioned snapshots, you need to specify a `volumeSnapshotContentName` as the source for the snapshot as shown in the following example. The `volumeSnapshotContentName` source field is required for pre-provisioned snapshots. --> -如下面例子所示，对于预配置的快照，需要给快照指定 `volumeSnapshotContentName` 来作为源。对于预配置的快照 `source` 中的`volumeSnapshotContentName` 字段是必填的。 +如下面例子所示，对于预配置的快照，需要给快照指定 `volumeSnapshotContentName` 来作为源。 +对于预配置的快照 `source` 中的`volumeSnapshotContentName` 字段是必填的。 ``` apiVersion: snapshot.storage.k8s.io/v1beta1 @@ -266,6 +260,5 @@ the *dataSource* field in the `PersistentVolumeClaim` object. For more details, see [Volume Snapshot and Restore Volume from Snapshot](/docs/concepts/storage/persistent-volumes/#volume-snapshot-and-restore-volume-from-snapshot-support). --> -更多详细信息，请参阅 [卷快照和从快照还原卷](/docs/concepts/storage/persistent-volumes/#volume-snapshot-and-restore-volume-from-snapshot-support)。 - +更多详细信息，请参阅 [卷快照和从快照还原卷](/zh/docs/concepts/storage/persistent-volumes/#volume-snapshot-and-restore-volume-from-snapshot-support)。 diff --git a/content/zh/docs/concepts/storage/volumes.md b/content/zh/docs/concepts/storage/volumes.md index 731f73d53f..262798346f 100644 --- a/content/zh/docs/concepts/storage/volumes.md +++ b/content/zh/docs/concepts/storage/volumes.md @@ -1,14 +1,15 @@ --- -reviewers: -- jsafrane -- saad-ali -- thockin -- msau42 -title: Volumes +title: 卷 content_type: concept weight: 10 --- +<!-- +title: Volumes +content_type: concept +weight: 10 +--> + <!-- overview --> <!-- @@ -28,11 +29,7 @@ Kubernetes 抽象出 `Volume` 对象来解决这两个问题。 <!-- Familiarity with [Pods](/docs/user-guide/pods) is suggested. --> - -阅读本文前建议您熟悉一下 [Pods](/docs/user-guide/pods)。 - - - +阅读本文前建议您熟悉一下 [Pods](/zh/docs/concepts/workloads/pods)。 <!-- body --> @@ -54,7 +51,8 @@ parameters to volumes). Docker 也有 [Volume](https://docs.docker.com/storage/) 的概念，但对它只有少量且松散的管理。 在 Docker 中，Volume 是磁盘上或者另外一个容器内的一个目录。 直到最近，Docker 才支持对基于本地磁盘的 Volume 的生存期进行管理。 -虽然 Docker 现在也能提供 Volume 驱动程序，但是目前功能还非常有限（例如，截至 Docker 1.7，每个容器只允许有一个 Volume 驱动程序，并且无法将参数传递给卷）。 +虽然 Docker 现在也能提供 Volume 驱动程序，但是目前功能还非常有限 +（例如，截至 Docker 1.7，每个容器只允许有一个 Volume 驱动程序，并且无法将参数传递给卷）。 <!-- A Kubernetes volume, on the other hand, has an explicit lifetime - the same as @@ -64,10 +62,10 @@ Pod ceases to exist, the volume will cease to exist, too. Perhaps more importantly than this, Kubernetes supports many types of volumes, and a Pod can use any number of them simultaneously. --> - 另一方面，Kubernetes 卷具有明确的生命周期——与包裹它的 Pod 相同。 因此，卷比 Pod 中运行的任何容器的存活期都长，在容器重新启动时数据也会得到保留。 -当然，当一个 Pod 不再存在时，卷也将不再存在。也许更重要的是，Kubernetes 可以支持许多类型的卷，Pod 也能同时使用任意数量的卷。 +当然，当一个 Pod 不再存在时，卷也将不再存在。 +也许更重要的是，Kubernetes 可以支持许多类型的卷，Pod 也能同时使用任意数量的卷。 <!-- At its core, a volume is just a directory, possibly with some data in it, which @@ -75,7 +73,6 @@ is accessible to the Containers in a Pod. How that directory comes to be, the medium that backs it, and the contents of it are determined by the particular volume type used. --> - 卷的核心是包含一些数据的目录，Pod 中的容器可以访问该目录。 特定的卷类型可以决定这个目录如何形成的，并能决定它支持何种介质，以及目录中存放什么内容。 @@ -87,7 +84,6 @@ field) and where to mount those into Containers (the `.spec.containers.volumeMounts` field). --> - 使用卷时, Pod 声明中需要提供卷的类型 (`.spec.volumes` 字段)和卷挂载的位置 (`.spec.containers.volumeMounts` 字段). <!-- @@ -99,9 +95,9 @@ the image. Volumes can not mount onto other volumes or have hard links to other volumes. Each Container in the Pod must independently specify where to mount each volume. --> - 容器中的进程能看到由它们的 Docker 镜像和卷组成的文件系统视图。 -[Docker 镜像](https://docs.docker.com/userguide/dockerimages/) 位于文件系统层次结构的根部，并且任何 Volume 都挂载在镜像内的指定路径上。 +[Docker 镜像](https://docs.docker.com/userguide/dockerimages/) +位于文件系统层次结构的根部，并且任何 Volume 都挂载在镜像内的指定路径上。 卷不能挂载到其他卷，也不能与其他卷有硬链接。 Pod 中的每个容器必须独立地指定每个卷的挂载位置。 @@ -110,7 +106,6 @@ Pod 中的每个容器必须独立地指定每个卷的挂载位置。 Kubernetes supports several types of Volumes: --> - ## Volume 的类型 Kubernetes 支持下列类型的卷： @@ -161,19 +156,15 @@ volume are preserved and the volume is merely unmounted. This means that an EBS volume can be pre-populated with data, and that data can be "handed off" between Pods. --> - -`awsElasticBlockStore` 卷将 Amazon Web服务（AWS）[EBS 卷](http://aws.amazon.com/ebs/) 挂载到您的 Pod 中。 +`awsElasticBlockStore` 卷将 Amazon Web服务（AWS）[EBS 卷](https://aws.amazon.com/ebs/) 挂载到您的 Pod 中。 与 `emptyDir` 在删除 Pod 时会被删除不同，EBS 卷的内容在删除 Pod 时会被保留，卷只是被卸载掉了。 这意味着 EBS 卷可以预先填充数据，并且可以在 Pod 之间传递数据。 -{{< caution >}} - <!-- You must create an EBS volume using `aws ec2 create-volume` or the AWS API before you can use it. --> - +{{< caution >}} 您在使用 EBS 卷之前必须先创建它，可以使用 `aws ec2 create-volume` 命令进行创建；也可以使用 AWS API 进行创建。 - {{< /caution >}} <!-- @@ -183,7 +174,6 @@ There are some restrictions when using an `awsElasticBlockStore` volume: * those instances need to be in the same region and availability-zone as the EBS volume * EBS only supports a single EC2 instance mounting a volume --> - 使用 `awsElasticBlockStore` 卷时有一些限制： * Pod 正在运行的节点必须是 AWS EC2 实例。 @@ -195,7 +185,6 @@ There are some restrictions when using an `awsElasticBlockStore` volume: Before you can use an EBS volume with a Pod, you need to create it. --> - #### 创建 EBS 卷 在将 EBS 卷用到 Pod 上之前，您首先要创建它。 @@ -208,13 +197,11 @@ aws ec2 create-volume --availability-zone=eu-west-1a --size=10 --volume-type=gp2 Make sure the zone matches the zone you brought up your cluster in. (And also check that the size and EBS volume type are suitable for your use!) --> - 确保该区域与您的群集所在的区域相匹配。（也要检查卷的大小和 EBS 卷类型都适合您的用途！） <!-- #### AWS EBS Example configuration --> - #### AWS EBS 配置示例 ```yaml @@ -276,7 +263,6 @@ into a Pod. More details can be found [here](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/staging/volumes/azure_file/README.md). --> - `azureFile` 用来在 Pod 上挂载 Microsoft Azure 文件卷（File Volume） (SMB 2.1 和 3.0)。 更多详情请参考[这里](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/staging/volumes/azure_file/README.md)。 @@ -295,7 +281,6 @@ Driver](https://github.com/kubernetes-sigs/azurefile-csi-driver) must be installed on the cluster and the `CSIMigration` and `CSIMigrationAzureFile` Alpha features must be enabled. --> - 启用azureFile的CSI迁移功能后，它会将所有插件操作从现有的内建插件填添加file.csi.azure.com容器存储接口（CSI）驱动程序中。 为了使用此功能，必须在群集上安装 [Azure文件CSI驱动程序](https://github.com/kubernetes-sigs/azurefile-csi-driver)， 并且 `CSIMigration` 和 `CSIMigrationAzureFile` Alpha功能 必须启用。 @@ -310,37 +295,32 @@ unmounted. This means that a CephFS volume can be pre-populated with data, and that data can be "handed off" between Pods. CephFS can be mounted by multiple writers simultaneously. --> - -`cephfs` 允许您将现存的 CephFS 卷挂载到 Pod 中。不像 `emptyDir` 那样会在删除 Pod 的同时也会被删除，`cephfs` 卷的内容在删除 Pod 时会被保留，卷只是被卸载掉了。 +`cephfs` 允许您将现存的 CephFS 卷挂载到 Pod 中。 +不像 `emptyDir` 那样会在删除 Pod 的同时也会被删除，`cephfs` 卷的内容在删除 Pod 时会被保留，卷只是被卸载掉了。 这意味着 CephFS 卷可以被预先填充数据，并且这些数据可以在 Pod 之间"传递"。CephFS 卷可同时被多个写者挂载。 - -{{< caution >}} - <!-- You must have your own Ceph server running with the share exported before you can use it. --> - +{{< caution >}} 在您使用 Ceph 卷之前，您的 Ceph 服务器必须正常运行并且要使用的 share 被导出（exported）。 {{< /caution >}} <!-- See the [CephFS example](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/volumes/cephfs/) for more details. --> - 更多信息请参考 [CephFS 示例](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/volumes/cephfs/)。 ### cinder {#cinder} -{{< note >}} - <!-- Prerequisite: Kubernetes with OpenStack Cloud Provider configured. For cloudprovider configuration please refer [cloud provider openstack](https://kubernetes.io/docs/concepts/cluster-administration/cloud-providers/#openstack). --> - -先决条件：配置了OpenStack Cloud Provider 的 Kubernetes。 有关 cloudprovider 配置，请参考 [cloud provider openstack](https://kubernetes.io/docs/concepts/cluster-administration/cloud-providers/#openstack)。 - +{{< note >}} +先决条件：配置了OpenStack Cloud Provider 的 Kubernetes。 +有关 cloudprovider 配置，请参考 +[cloud provider openstack](/zh/docs/concepts/cluster-administration/cloud-providers/#openstack)。 {{< /note >}} <!-- @@ -348,7 +328,6 @@ configuration please refer [cloud provider openstack](https://kubernetes.io/docs #### Cinder Volume Example configuration --> - `cinder` 用于将 OpenStack Cinder 卷安装到 Pod 中。 #### Cinder Volume示例配置 @@ -402,8 +381,7 @@ provides a way to inject configuration data into Pods. The data stored in a `ConfigMap` object can be referenced in a volume of type `configMap` and then consumed by containerized applications running in a Pod. --> - -[`configMap`](/docs/tasks/configure-pod-container/configure-pod-configmap/) 资源提供了向 Pod 注入配置数据的方法。 +[`configMap`](/zh/docs/tasks/configure-pod-container/configure-pod-configmap/) 资源提供了向 Pod 注入配置数据的方法。 `ConfigMap` 对象中存储的数据可以被 `configMap` 类型的卷引用，然后被应用到 Pod 中运行的容器化应用。 <!-- @@ -445,23 +423,22 @@ its `log_level` entry are mounted into the Pod at path "`/etc/config/log_level`" Note that this path is derived from the volume's `mountPath` and the `path` keyed with `log_level`. --> - `log-config` ConfigMap 是以卷的形式挂载的， 存储在 `log_level` 条目中的所有内容都被挂载到 Pod 的 "`/etc/config/log_level`" 路径下。 请注意，这个路径来源于 Volume 的 `mountPath` 和 `log_level` 键对应的 `path`。 -{{< caution >}} <!-- You must create a [ConfigMap](/docs/tasks/configure-pod-container/configure-pod-configmap/) before you can use it. --> -在使用 [ConfigMap](/docs/tasks/configure-pod-container/configure-pod-configmap/) 之前您首先要创建它。 +{{< caution >}} +在使用 [ConfigMap](/zh/docs/tasks/configure-pod-container/configure-pod-configmap/) 之前您首先要创建它。 {{< /caution >}} -{{< note >}} <!-- A Container using a ConfigMap as a [subPath](#using-subpath) volume mount will not receive ConfigMap updates. --> +{{< note >}} 容器以 [subPath](#using-subpath) 卷挂载方式使用 ConfigMap 时，将无法接收 ConfigMap 的更新。 {{< /note >}} @@ -475,20 +452,18 @@ It mounts a directory and writes the requested data in plain text files. `downwardAPI` 卷用于使 downward API 数据对应用程序可用。 这种卷类型挂载一个目录并在纯文本文件中写入请求的数据。 -{{< note >}} - <!-- A Container using Downward API as a [subPath](#using-subpath) volume mount will not receive Downward API updates. --> - +{{< note >}} 容器以挂载 [subPath](#using-subpath) 卷的方式使用 downwardAPI 时，将不能接收到它的更新。 {{< /note >}} <!-- See the [`downwardAPI` volume example](/docs/tasks/inject-data-application/downward-api-volume-expose-pod-information/) for more details. --> -更多详细信息请参考 [`downwardAPI` 卷示例](/docs/tasks/inject-data-application/downward-api-volume-expose-pod-information/)。 +更多详细信息请参考 [`downwardAPI` 卷示例](/zh/docs/tasks/inject-data-application/downward-api-volume-expose-pod-information/)。 ### emptyDir {#emptydir} @@ -506,11 +481,10 @@ any reason, the data in the `emptyDir` is deleted forever. 尽管 Pod 中的容器挂载 `emptyDir` 卷的路径可能相同也可能不同，但是这些容器都可以读写 `emptyDir` 卷中相同的文件。 当 Pod 因为某些原因被从节点上删除时，`emptyDir` 卷中的数据也会永久删除。 -{{< note >}} - <!-- A Container crashing does *NOT* remove a Pod from a node, so the data in an `emptyDir` volume is safe across Container crashes. --> +{{< note >}} 容器崩溃并不会导致 Pod 被从节点上移除，因此容器崩溃时 `emptyDir` 卷中的数据是安全的。 {{< /note >}} @@ -522,14 +496,12 @@ Some uses for an `emptyDir` are: * holding files that a content-manager Container fetches while a webserver Container serves the data --> - `emptyDir` 的一些用途： * 缓存空间，例如基于磁盘的归并排序。 * 为耗时较长的计算任务提供检查点，以便任务能方便地从崩溃前状态恢复执行。 * 在 Web 服务器容器服务数据时，保存内容管理器容器获取的文件。 - <!-- By default, `emptyDir` volumes are stored on whatever medium is backing the node - that might be disk or SSD or network storage, depending on your @@ -539,7 +511,6 @@ While tmpfs is very fast, be aware that unlike disks, tmpfs is cleared on node reboot and any files you write will count against your Container's memory limit. --> - 默认情况下， `emptyDir` 卷存储在支持该节点所使用的介质上；这里的介质可以是磁盘或 SSD 或网络存储，这取决于您的环境。 但是，您可以将 `emptyDir.medium` 字段设置为 `"Memory"`，以告诉 Kubernetes 为您安装 tmpfs（基于 RAM 的文件系统）。 虽然 tmpfs 速度非常快，但是要注意它与磁盘不同。 @@ -548,7 +519,6 @@ tmpfs 在节点重启时会被清除，并且您所写入的所有文件都会 <!-- #### Example Pod --> - #### Pod 示例 ```yaml @@ -576,24 +546,22 @@ You can specify single or multiple target World Wide Names using the parameter `targetWWNs` in your volume configuration. If multiple WWNs are specified, targetWWNs expect that those WWNs are from multi-path connections. --> - ### fc (光纤通道) {#fc} `fc` 卷允许将现有的光纤通道卷挂载到 Pod 中。 可以使用卷配置中的参数 `targetWWNs` 来指定单个或多个目标 WWN。 如果指定多个 WWN，targetWWNs 期望这些 WWN 来自多路径连接。 -{{< caution >}} <!-- You must configure FC SAN Zoning to allocate and mask those LUNs (volumes) to the target WWNs beforehand so that Kubernetes hosts can access them. --> +{{< caution >}} 您必须配置 FC SAN Zoning，以便预先向目标 WWN 分配和屏蔽这些 LUN（卷），这样 Kubernetes 主机才可以访问它们。 {{< /caution >}} <!-- See the [FC example](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/staging/volumes/fibre_channel) for more details. --> - 更多详情请参考 [FC 示例](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/staging/volumes/fibre_channel)。 <!-- @@ -615,17 +583,15 @@ CLI or by using the Flocker API. If the dataset already exists it will be reattached by Flocker to the node that the Pod is scheduled. This means data can be "handed off" between Pods as required. --> - `flocker` 卷允许将一个 Flocker 数据集挂载到 Pod 中。 如果数据集在 Flocker 中不存在，则需要首先使用 Flocker CLI 或 Flocker API 创建数据集。 如果数据集已经存在，那么 Flocker 将把它重新附加到 Pod 被调度的节点。 这意味着数据可以根据需要在 Pod 之间 "传递"。 - -{{< caution >}} <!-- You must have your own Flocker installation running before you can use it. --> +{{< caution >}} 您在使用 Flocker 之前必须先安装运行自己的 Flocker。 {{< /caution >}} @@ -651,10 +617,10 @@ pre-populated with data, and that data can be "handed off" between Pods. 不像 `emptyDir` 那样会在删除 Pod 的同时也会被删除，持久盘卷的内容在删除 Pod 时会被保留，卷只是被卸载掉了。 这意味着持久盘卷可以被预先填充数据，并且这些数据可以在 Pod 之间"传递"。 -{{< caution >}} <!-- You must create a PD using `gcloud` or the GCE API or UI before you can use it. --> +{{< caution >}} 您在使用 PD 前，必须使用 `gcloud` 或者 GCE API 或 UI 创建它。 {{< /caution >}} @@ -664,7 +630,6 @@ There are some restrictions when using a `gcePersistentDisk`: * the nodes on which Pods are running must be GCE VMs * those VMs need to be in the same GCE project and zone as the PD --> - 使用 `gcePersistentDisk` 时有一些限制： * 运行 Pod 的节点必须是 GCE VM @@ -677,7 +642,6 @@ and then serve it in parallel from as many Pods as you need. Unfortunately, PDs can only be mounted by a single consumer in read-write mode - no simultaneous writers allowed. --> - PD 的一个特点是它们可以同时被多个消费者以只读方式挂载。 这意味着您可以用数据集预先填充 PD，然后根据需要并行地在尽可能多的 Pod 中提供该数据集。 不幸的是，PD 只能由单个使用者以读写模式挂载——即不允许同时写入。 @@ -686,7 +650,6 @@ PD 的一个特点是它们可以同时被多个消费者以只读方式挂载 Using a PD on a Pod controlled by a ReplicationController will fail unless the PD is read-only or the replica count is 0 or 1. --> - 在由 ReplicationController 所管理的 Pod 上使用 PD 将会失败，除非 PD 是只读模式或者副本的数量是 0 或 1。 <!-- @@ -694,7 +657,6 @@ the PD is read-only or the replica count is 0 or 1. Before you can use a GCE PD with a Pod, you need to create it. --> - #### 创建持久盘（PD） 在 Pod 中使用 GCE 持久盘之前，您首先要创建它。 @@ -706,7 +668,6 @@ gcloud compute disks create --size=500GB --zone=us-central1-a my-data-disk <!-- #### Example Pod --> - #### Pod 示例 ```yaml @@ -731,7 +692,6 @@ spec: <!-- #### Regional Persistent Disks --> - #### 区域持久盘（Regional Persistent Disks） {{< feature-state for_k8s_version="v1.10" state="beta" >}} @@ -739,19 +699,18 @@ spec: <!-- The [Regional Persistent Disks](https://cloud.google.com/compute/docs/disks/#repds) feature allows the creation of Persistent Disks that are available in two zones within the same region. In order to use this feature, the volume must be provisioned as a PersistentVolume; referencing the volume directly from a pod is not supported. --> - [区域持久盘](https://cloud.google.com/compute/docs/disks/#repds) 功能允许您创建能在同一区域的两个可用区中使用的持久盘。 要使用这个功能，必须以持久盘的方式提供卷；Pod 不支持直接引用这种卷。 <!-- #### Manually provisioning a Regional PD PersistentVolume + Dynamic provisioning is possible using a [StorageClass for GCE PD](/docs/concepts/storage/storage-classes/#gce). Before creating a PersistentVolume, you must create the PD: --> - #### 手动供应基于区域 PD 的 PersistentVolume -使用 [为 GCE PD 定义的存储类](/docs/concepts/storage/storage-classes/#gce) 也可以动态供应。 +使用 [为 GCE PD 定义的存储类](/zh/docs/concepts/storage/storage-classes/#gce) 也可以动态供应。 在创建 PersistentVolume 之前，您首先要创建 PD。 ```shell @@ -798,7 +757,6 @@ Driver](https://github.com/kubernetes-sigs/gcp-compute-persistent-disk-csi-drive must be installed on the cluster and the `CSIMigration` and `CSIMigrationGCE` Alpha features must be enabled. --> - 启用 GCE PD 的 CSI 迁移功能后，它会将所有插件操作从现有的内建插件填添加 `pd.csi.storage.gke.io` 容器存储接口（ CSI ）驱动程序中。 为了使用此功能，必须在群集上安装 [GCE PD CSI驱动程序](https://github.com/kubernetes-sigs/gcp-compute-persistent-disk-csi-driver)， 并且 `CSIMigration` 和 `CSIMigrationGCE` Alpha功能 必须启用。 @@ -810,10 +768,10 @@ Alpha features must be enabled. ### gitRepo (已弃用) -{{< warning >}} <!-- The gitRepo volume type is deprecated. To provision a container with a git repo, mount an [EmptyDir](#emptydir) into an InitContainer that clones the repo using git, then mount the [EmptyDir](#emptydir) into the Pod's container. --> +{{< warning >}} gitRepo 卷类型已经被废弃。如果需要在容器中提供 git 仓库，请将一个 [EmptyDir](#emptydir) 卷挂载到 InitContainer 中，使用 git 命令完成仓库的克隆操作，然后将 [EmptyDir](#emptydir) 卷挂载到 Pod 的容器中。 {{< /warning >}} @@ -862,22 +820,20 @@ means that a glusterfs volume can be pre-populated with data, and that data can be "handed off" between Pods. GlusterFS can be mounted by multiple writers simultaneously. --> - -`glusterfs` 卷能将 [Glusterfs](http://www.gluster.org) (一个开源的网络文件系统) 挂载到您的 Pod 中。 +`glusterfs` 卷能将 [Glusterfs](https://www.gluster.org) (一个开源的网络文件系统) 挂载到您的 Pod 中。 不像 `emptyDir` 那样会在删除 Pod 的同时也会被删除，`glusterfs` 卷的内容在删除 Pod 时会被保存，卷只是被卸载掉了。 这意味着 `glusterfs` 卷可以被预先填充数据，并且这些数据可以在 Pod 之间"传递"。GlusterFS 可以被多个写者同时挂载。 -{{< caution >}} <!-- You must have your own GlusterFS installation running before you can use it. --> +{{< caution >}} 在使用前您必须先安装运行自己的 GlusterFS。 {{< /caution >}} <!-- See the [GlusterFS example](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/volumes/glusterfs) for more details. --> - 更多详情请参考 [GlusterFS 示例](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/volumes/glusterfs)。 ### hostPath {#hostpath} @@ -959,12 +915,13 @@ Watch out when using this type of volume, because: * 具有相同配置（例如从 podTemplate 创建）的多个 Pod 会由于节点上文件的不同而在不同节点上有不同的行为。 * 当 Kubernetes 按照计划添加资源感知的调度时，这类调度机制将无法考虑由 `hostPath` 使用的资源。 -* 基础主机上创建的文件或目录只能由 root 用户写入。您需要在 [特权容器](/docs/user-guide/security-context) 中以 root 身份运行进程，或者修改主机上的文件权限以便容器能够写入 `hostPath` 卷。 +* 基础主机上创建的文件或目录只能由 root 用户写入。您需要在 +[特权容器](/zh/docs/tasks/configure-pod-container/security-context/) +中以 root 身份运行进程，或者修改主机上的文件权限以便容器能够写入 `hostPath` 卷。 <!-- #### Example Pod --> - #### Pod 示例 ```yaml @@ -988,9 +945,16 @@ spec: type: Directory ``` +<!-- +It should be noted that the `FileOrCreate` mode does not create the parent +directory of the file. If the parent directory of the mounted file does not +exist, the pod fails to start. To ensure that this mode works, you can try to +mount directories and files separately, as shown below. +--> {{< caution >}} -<!-- It should be noted that the `FileOrCreate` mode does not create the parent directory of the file. If the parent directory of the mounted file does not exist, the pod fails to start. To ensure that this mode works, you can try to mount directories and files separately, as shown below. --> -应当注意,`FileOrCreate` 类型不会负责创建文件的父目录。如果挂载挂载文件的父目录不存在，pod 启动会失败。为了确保这种 `type` 能够工作，可以尝试把文件和它对应的目录分开挂载，如下所示： +应当注意,`FileOrCreate` 类型不会负责创建文件的父目录。 +如果挂载挂载文件的父目录不存在，pod 启动会失败。 +为了确保这种 `type` 能够工作，可以尝试把文件和它对应的目录分开挂载，如下所示： {{< /caution >}} #### FileOrCreate pod 示例 @@ -1035,10 +999,10 @@ that data can be "handed off" between Pods. 不像 `emptyDir` 那样会在删除 Pod 的同时也会被删除，持久盘 卷的内容在删除 Pod 时会被保存，卷只是被卸载掉了。 这意味着 `iscsi` 卷可以被预先填充数据，并且这些数据可以在 Pod 之间"传递"。 -{{< caution >}} <!-- You must have your own iSCSI server running with the volume created before you can use it. --> +{{< caution >}} 在您使用 iSCSI 卷之前，您必须拥有自己的 iSCSI 服务器，并在上面创建卷。 {{< /caution >}} @@ -1049,14 +1013,12 @@ and then serve it in parallel from as many Pods as you need. Unfortunately, iSCSI volumes can only be mounted by a single consumer in read-write mode - no simultaneous writers allowed. --> - iSCSI 的一个特点是它可以同时被多个用户以只读方式挂载。 这意味着您可以用数据集预先填充卷，然后根据需要在尽可能多的 Pod 上提供它。不幸的是，iSCSI 卷只能由单个使用者以读写模式挂载——不允许同时写入。 <!-- See the [iSCSI example](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/volumes/iscsi) for more details. --> - 更多详情请参考 [iSCSI 示例](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/volumes/iscsi)。 <!-- @@ -1067,11 +1029,13 @@ See the [iSCSI example](https://github.com/kubernetes/examples/tree/{{< param "g {{< feature-state for_k8s_version="v1.14" state="stable" >}} -{{< note >}} -<!--The alpha PersistentVolume NodeAffinity annotation has been deprecated +<!-- +The alpha PersistentVolume NodeAffinity annotation has been deprecated and will be removed in a future release. Existing PersistentVolumes using this annotation must be updated by the user to use the new PersistentVolume -`NodeAffinity` field.--> +`NodeAffinity` field. +--> +{{< note >}} alpha 版本的 PersistentVolume NodeAffinity 注释已被取消，将在将来的版本中废弃。 用户必须更新现有的使用该注解的 PersistentVolume，以使用新的 PersistentVolume `NodeAffinity` 字段。 {{< /note >}} @@ -1094,7 +1058,8 @@ portable manner without manually scheduling Pods to nodes, as the system is awar of the volume's node constraints by looking at the node affinity on the PersistentVolume. --> -相比 `hostPath` 卷，`local` 卷可以以持久和可移植的方式使用，而无需手动将 Pod 调度到节点，因为系统通过查看 PersistentVolume 所属节点的亲和性配置，就能了解卷的节点约束。 +相比 `hostPath` 卷，`local` 卷可以以持久和可移植的方式使用，而无需手动将 Pod +调度到节点，因为系统通过查看 PersistentVolume 所属节点的亲和性配置，就能了解卷的节点约束。 <!-- However, local volumes are still subject to the availability of the underlying @@ -1107,7 +1072,6 @@ durability characteristics of the underlying disk. The following is an example of PersistentVolume spec using a `local` volume and `nodeAffinity`: --> - 然而，`local` 卷仍然取决于底层节点的可用性，并不是适合所有应用程序。 如果节点变得不健康，那么`local` 卷也将变得不可访问，并且使用它的 Pod 将不能运行。 使用 `local` 卷的应用程序必须能够容忍这种可用性的降低，以及因底层磁盘的耐用性特征而带来的潜在的数据丢失风险。 @@ -1145,7 +1109,6 @@ PersistentVolume `nodeAffinity` is required when using local volumes. It enables the Kubernetes scheduler to correctly schedule Pods using local volumes to the correct node. --> - 使用 `local` 卷时，需要使用 PersistentVolume 对象的 `nodeAffinity` 字段。 它使 Kubernetes 调度器能够将使用 `local` 卷的 Pod 正确地调度到合适的节点。 @@ -1154,8 +1117,8 @@ PersistentVolume `volumeMode` can now be set to "Block" (instead of the default value "Filesystem") to expose the local volume as a raw block device. The `volumeMode` field requires `BlockVolume` Alpha feature gate to be enabled. --> - -现在，可以将 PersistentVolume 对象的 `volumeMode` 字段设置为 "Block"（而不是默认值 "Filesystem"），以将 `local` 卷作为原始块设备暴露出来。 +现在，可以将 PersistentVolume 对象的 `volumeMode` 字段设置为 "Block" +（而不是默认值 "Filesystem"），以将 `local` 卷作为原始块设备暴露出来。 `volumeMode` 字段需要启用 Alpha 功能 `BlockVolume`。 <!-- @@ -1168,8 +1131,9 @@ selectors, Pod affinity, and Pod anti-affinity. --> 当使用 `local` 卷时，建议创建一个 StorageClass，将 `volumeBindingMode` 设置为 `WaitForFirstConsumer`。 -请参考 [示例](/docs/concepts/storage/storage-classes/#local)。 -延迟卷绑定操作可以确保 Kubernetes 在为 PersistentVolumeClaim 作出绑定决策时，会评估 Pod 可能具有的其他节点约束，例如：如节点资源需求、节点选择器、Pod 亲和性和 Pod 反亲和性。 +请参考[示例](/zh/docs/concepts/storage/storage-classes/#local)。 +延迟卷绑定操作可以确保 Kubernetes 在为 PersistentVolumeClaim 作出绑定决策时， +会评估 Pod 可能具有的其他节点约束，例如：如节点资源需求、节点选择器、Pod 亲和性和 Pod 反亲和性。 <!-- An external static provisioner can be run separately for improved management of @@ -1178,18 +1142,17 @@ provisioning yet. For an example on how to run an external local provisioner, see the [local volume provisioner user guide](https://github.com/kubernetes-sigs/sig-storage-local-static-provisioner). --> - 您可以在 Kubernetes 之外单独运行静态驱动以改进对 local 卷的生命周期管理。 请注意，此驱动不支持动态配置。 有关如何运行外部 `local` 卷驱动的示例，请参考 [local 卷驱动用户指南](https://github.com/kubernetes-sigs/sig-storage-local-static-provisioner)。 -{{< note >}} <!-- The local PersistentVolume requires manual cleanup and deletion by the user if the external static provisioner is not used to manage the volume lifecycle. --> +{{< note >}} 如果不使用外部静态驱动来管理卷的生命周期，则用户需要手动清理和删除 local 类型的持久卷。 {{< /note >}} @@ -1203,22 +1166,20 @@ unmounted. This means that an NFS volume can be pre-populated with data, and that data can be "handed off" between Pods. NFS can be mounted by multiple writers simultaneously. --> - `nfs` 卷能将 NFS (网络文件系统) 挂载到您的 Pod 中。 不像 `emptyDir` 那样会在删除 Pod 的同时也会被删除，`nfs` 卷的内容在删除 Pod 时会被保存，卷只是被卸载掉了。 这意味着 `nfs` 卷可以被预先填充数据，并且这些数据可以在 Pod 之间"传递"。 -{{< caution >}} <!-- You must have your own NFS server running with the share exported before you can use it. --> +{{< caution >}} 在您使用 NFS 卷之前，必须运行自己的 NFS 服务器并将目标 share 导出备用。 {{< /caution >}} <!-- See the [NFS example](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/staging/volumes/nfs) for more details. --> - 要了解更多详情请参考 [NFS 示例](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/staging/volumes/nfs)。 ### persistentVolumeClaim {#persistentvolumeclaim} @@ -1229,7 +1190,7 @@ A `persistentVolumeClaim` volume is used to mount a way for users to "claim" durable storage (such as a GCE PersistentDisk or an iSCSI volume) without knowing the details of the particular cloud environment. --> -`persistentVolumeClaim` 卷用来将[持久卷](/docs/concepts/storage/persistent-volumes/)（PersistentVolume）挂载到 Pod 中。 +`persistentVolumeClaim` 卷用来将[持久卷](/zh/docs/concepts/storage/persistent-volumes/)（PersistentVolume）挂载到 Pod 中。 持久卷是用户在不知道特定云环境细节的情况下"申领"持久存储（例如 GCE PersistentDisk 或者 iSCSI 卷）的一种方法。 <!-- @@ -1237,7 +1198,7 @@ See the [PersistentVolumes example](/docs/concepts/storage/persistent-volumes/) details. --> -更多详情请参考[持久卷示例](/docs/concepts/storage/persistent-volumes/) +更多详情请参考[持久卷示例](/zh/docs/concepts/storage/persistent-volumes/) ### projected {#projected} @@ -1273,7 +1234,8 @@ True. --> 服务帐户令牌的映射是 Kubernetes 1.11 版本中引入的一个功能，并在 1.12 版本中被提升为 Beta 功能。 -若要在 1.11 版本中启用此特性，需要显式设置 `TokenRequestProjection` [功能开关](/docs/reference/command-line-tools-reference/feature-gates/) 为 True。 +若要在 1.11 版本中启用此特性，需要显式设置 `TokenRequestProjection` +[功能开关](/zh/docs/reference/command-line-tools-reference/feature-gates/) 为 True。 <!-- #### Example Pod with a secret, a downward API, and a configmap. @@ -1500,16 +1462,14 @@ More details and examples can be found [here](https://github.com/kubernetes/exam A `quobyte` volume allows an existing [Quobyte](http://www.quobyte.com) volume to be mounted into your Pod. --> +`quobyte` 卷允许将现有的 [Quobyte](https://www.quobyte.com) 卷挂载到您的 Pod 中。 -`quobyte` 卷允许将现有的 [Quobyte](http://www.quobyte.com) 卷挂载到您的 Pod 中。 - -{{< caution >}} <!-- You must have your own Quobyte setup running with the volumes created before you can use it. --> +{{< caution >}} 在使用 Quobyte 卷之前，您首先要进行安装并创建好卷。 - {{< /caution >}} <!-- @@ -1517,7 +1477,6 @@ Quobyte supports the {{< glossary_tooltip text="Container Storage Interface" ter CSI is the recommended plugin to use Quobyte volumes inside Kubernetes. Quobyte's GitHub project has [instructions](https://github.com/quobyte/quobyte-csi#quobyte-csi) for deploying Quobyte using CSI, along with examples. --> - Quobyte 支持{{< glossary_tooltip text="容器存储接口" term_id="csi" >}}。 推荐使用 CSI 插件以在 Kubernetes 中使用 Quobyte 卷。 Quobyte 的 GitHub 项目具有[说明](https://github.com/quobyte/quobyte-csi#quobyte-csi)以及使用示例来部署 CSI 的 Quobyte。 @@ -1532,16 +1491,14 @@ a `rbd` volume are preserved and the volume is merely unmounted. This means that a RBD volume can be pre-populated with data, and that data can be "handed off" between Pods. --> - -`rbd` 卷允许将 [Rados 块设备](http://ceph.com/docs/master/rbd/rbd/) 卷挂载到您的 Pod 中. +`rbd` 卷允许将 [Rados 块设备](https://ceph.com/docs/master/rbd/rbd/) 卷挂载到您的 Pod 中. 不像 `emptyDir` 那样会在删除 Pod 的同时也会被删除，`rbd` 卷的内容在删除 Pod 时会被保存，卷只是被卸载掉了。 这意味着 `rbd` 卷可以被预先填充数据，并且这些数据可以在 Pod 之间"传递"。 - -{{< caution >}} <!-- You must have your own Ceph installation running before you can use RBD. --> +{{< caution >}} 在使用 RBD 之前，您必须安装运行 Ceph。 {{< /caution >}} @@ -1574,18 +1531,17 @@ volumes (or it can dynamically provision new volumes for persistent volume claim ScaleIO 是基于软件的存储平台，可以使用现有硬件来创建可伸缩的、共享的而且是网络化的块存储集群。 `scaleIO` 卷插件允许部署的 Pod 访问现有的 ScaleIO 卷（或者它可以动态地为持久卷申领提供新的卷，参见[ScaleIO 持久卷](/docs/concepts/storage/persistent-volumes/#scaleio))。 -{{< caution >}} <!-- You must have an existing ScaleIO cluster already setup and running with the volumes created before you can use them. --> +{{< caution >}} 在使用前，您必须有个安装完毕且运行正常的 ScaleIO 集群，并且创建好了存储卷。 {{< /caution >}} <!-- The following is an example of Pod configuration with ScaleIO: --> - 下面是配置了 ScaleIO 的 Pod 示例： ```yaml @@ -1632,26 +1588,25 @@ non-volatile storage. `secret` 卷用来给 Pod 传递敏感信息，例如密码。您可以将 secret 存储在 Kubernetes API 服务器上，然后以文件的形式挂在到 Pod 中，无需直接与 Kubernetes 耦合。 `secret` 卷由 tmpfs（基于 RAM 的文件系统）提供存储，因此它们永远不会被写入非易失性（持久化的）存储器。 -{{< caution >}} <!-- You must create a secret in the Kubernetes API before you can use it. --> +{{< caution >}} 使用前您必须在 Kubernetes API 中创建 secret。 {{< /caution >}} -{{< note >}} <!-- A Container using a Secret as a [subPath](#using-subpath) volume mount will not receive Secret updates. --> +{{< note >}} 容器以 [subPath](#using-subpath) 卷的方式挂载 Secret 时，它将感知不到 Secret 的更新。 {{< /note >}} <!-- Secrets are described in more detail [here](/docs/user-guide/secrets). --> - -Secret 的更多详情请参考[这里](/docs/user-guide/secrets)。 +Secret 的更多详情请参考[这里](/zh/docs/concepts/configuration/secret/)。 ### storageOS {#storageos} @@ -1659,7 +1614,6 @@ Secret 的更多详情请参考[这里](/docs/user-guide/secrets)。 A `storageos` volume allows an existing [StorageOS](https://www.storageos.com) volume to be mounted into your Pod. --> - `storageos` 卷允许将现有的 [StorageOS](https://www.storageos.com) 卷挂载到您的 Pod 中。 <!-- @@ -1668,7 +1622,6 @@ or attached storage accessible from any node within the Kubernetes cluster. Data can be replicated to protect against node failure. Thin provisioning and compression can improve utilization and reduce cost. --> - StorageOS 在 Kubernetes 环境中以容器的形式运行，这使得应用能够从 Kubernetes 集群中的任何节点访问本地或关联的存储。 为应对节点失效状况，可以复制数据。 若需提高利用率和降低成本，可以考虑瘦配置（Thin Provisioning）和数据压缩。 @@ -1679,23 +1632,20 @@ At its core, StorageOS provides block storage to Containers, accessible via a fi The StorageOS Container requires 64-bit Linux and has no additional dependencies. A free developer license is available. --> - 作为其核心能力之一，StorageOS 为容器提供了可以通过文件系统访问的块存储。 StorageOS 容器需要 64 位的 Linux，并且没有其他的依赖关系。 StorageOS 提供免费的开发者授权许可。 -{{< caution >}} <!-- You must run the StorageOS Container on each node that wants to access StorageOS volumes or that will contribute storage capacity to the pool. For installation instructions, consult the [StorageOS documentation](https://docs.storageos.com). --> - +{{< caution >}} 您必须在每个希望访问 StorageOS 卷的或者将向存储资源池贡献存储容量的节点上运行 StorageOS 容器。 有关安装说明，请参阅 [StorageOS 文档](https://docs.storageos.com)。 - {{< /caution >}} ```yaml @@ -1735,27 +1685,27 @@ For more information including Dynamic Provisioning and Persistent Volume Claims ### vsphereVolume {#vspherevolume} -{{< note >}} <!-- Prerequisite: Kubernetes with vSphere Cloud Provider configured. For cloudprovider configuration please refer [vSphere getting started guide](https://vmware.github.io/vsphere-storage-for-kubernetes/documentation/). --> -前提条件：配备了 vSphere 云驱动的 Kubernetes。云驱动的配置方法请参考 [vSphere 使用指南](https://vmware.github.io/vsphere-storage-for-kubernetes/documentation/)。 +{{< note >}} +前提条件：配备了 vSphere 云驱动的 Kubernetes。云驱动的配置方法请参考 +[vSphere 使用指南](https://vmware.github.io/vsphere-storage-for-kubernetes/documentation/)。 {{< /note >}} <!-- A `vsphereVolume` is used to mount a vSphere VMDK Volume into your Pod. The contents of a volume are preserved when it is unmounted. It supports both VMFS and VSAN datastore. --> - `vsphereVolume` 用来将 vSphere VMDK 卷挂载到您的 Pod 中。 在卸载卷时，卷的内容会被保留。 vSphereVolume 卷类型支持 VMFS 和 VSAN 数据仓库。 -{{< caution >}} <!-- You must create VMDK using one of the following methods before using with Pod. --> +{{< caution >}} 在挂载到 Pod 之前，您必须用下列方式之一创建 VMDK。 {{< /caution >}} @@ -1764,7 +1714,6 @@ You must create VMDK using one of the following methods before using with Pod. Choose one of the following methods to create a VMDK. --> - #### 创建 VMDK 卷 选择下列方式之一创建 VMDK。 @@ -1793,7 +1742,6 @@ vmware-vdiskmanager -c -t 0 -s 40GB -a lsilogic myDisk.vmdk <!-- #### vSphere VMDK Example configuration --> - #### vSphere VMDK 配置示例 ```yaml @@ -1819,7 +1767,6 @@ spec: <!-- More examples can be found [here](https://github.com/kubernetes/examples/tree/master/staging/volumes/vsphere). --> - 更多示例可以在[这里](https://github.com/kubernetes/examples/tree/master/staging/volumes/vsphere)找到。 <!-- @@ -1828,8 +1775,7 @@ More examples can be found [here](https://github.com/kubernetes/examples/tree/ma Sometimes, it is useful to share one volume for multiple uses in a single Pod. The `volumeMounts.subPath` property can be used to specify a sub-path inside the referenced volume instead of its root. --> - -## 使用 subPath +## 使用 subPath {#using-path} 有时，在单个 Pod 中共享卷以供多方使用是很有用的。 `volumeMounts.subPath` 属性可用于指定所引用的卷内的子路径，而不是其根路径。 @@ -1838,7 +1784,6 @@ property can be used to specify a sub-path inside the referenced volume instead Here is an example of a Pod with a LAMP stack (Linux Apache Mysql PHP) using a single, shared volume. The HTML contents are mapped to its `html` folder, and the databases will be stored in its `mysql` folder: --> - 下面是一个使用同一共享卷的、内含 LAMP 栈（Linux Apache Mysql PHP）的 Pod 的示例。 HTML 内容被映射到卷的 `html` 文件夹，数据库将被存储在卷的 `mysql` 文件夹中： @@ -1878,13 +1823,11 @@ spec: {{< feature-state for_k8s_version="v1.15" state="beta" >}} - <!-- Use the `subPathExpr` field to construct `subPath` directory names from Downward API environment variables. Before you use this feature, you must enable the `VolumeSubpathEnvExpansion` feature gate. The `subPath` and `subPathExpr` properties are mutually exclusive. --> - 使用 `subPathExpr` 字段从 Downward API 环境变量构造 `subPath` 目录名。 在使用此特性之前，必须启用 `VolumeSubpathEnvExpansion` 功能开关。 `subPath` 和 `subPathExpr` 属性是互斥的。 @@ -1892,8 +1835,8 @@ The `subPath` and `subPathExpr` properties are mutually exclusive. <!-- In this example, a Pod uses `subPathExpr` to create a directory `pod1` within the hostPath volume `/var/log/pods`, using the pod name from the Downward API. The host directory `/var/log/pods/pod1` is mounted at `/logs` in the container. --> - -在这个示例中，Pod 基于 Downward API 中的 Pod 名称，使用 `subPathExpr` 在 hostPath 卷 `/var/log/pods` 中创建目录 `pod1`。 +在这个示例中，Pod 基于 Downward API 中的 Pod 名称，使用 `subPathExpr` +在 hostPath 卷 `/var/log/pods` 中创建目录 `pod1`。 主机目录 `/var/log/pods/pod1` 挂载到了容器的 `/logs` 中。 ```yaml @@ -1932,7 +1875,6 @@ medium of the filesystem holding the kubelet root dir (typically `hostPath` volume can consume, and no isolation between Containers or between Pods. --> - ## 资源 `emptyDir` 卷的存储介质（磁盘、SSD 等）是由保存 kubelet 根目录（通常是 `/var/lib/kubelet`）的文件系统的介质确定。 @@ -1944,8 +1886,10 @@ request a certain amount of space using a [resource](/docs/user-guide/compute-re specification, and to select the type of media to use, for clusters that have several media types. --> - -将来，我们希望 `emptyDir` 卷和 `hostPath` 卷能够使用 [resource](/docs/user-guide/computeresources) 规范来请求一定量的空间，并且能够为具有多种介质类型的集群选择要使用的介质类型。 +将来，我们希望 `emptyDir` 卷和 `hostPath` 卷能够使用 +[resource](/zh/docs/concepts/configuration/manage-compute-resources-containers/) +规约来请求一定量的空间， +并且能够为具有多种介质类型的集群选择要使用的介质类型。 <!-- ## Out-of-Tree Volume Plugins @@ -1967,7 +1911,8 @@ Kubernetes API. This meant that adding a new storage system to Kubernetes (a volume plugin) required checking code into the core Kubernetes code repository. --> -在引入 CSI 和 FlexVolume 之前，所有卷插件（如上面列出的卷类型）都是 "in-tree" 的，这意味着它们是与 Kubernetes 的核心组件一同构建、链接、编译和交付的，并且这些插件都扩展了 Kubernetes 的核心 API。 +在引入 CSI 和 FlexVolume 之前，所有卷插件（如上面列出的卷类型）都是 "in-tree" 的， +这意味着它们是与 Kubernetes 的核心组件一同构建、链接、编译和交付的，并且这些插件都扩展了 Kubernetes 的核心 API。 这意味着向 Kubernetes 添加新的存储系统（卷插件）需要将代码合并到 Kubernetes 核心代码库中。 <!-- @@ -2007,25 +1952,22 @@ Kubernetes v1.10, and is GA in Kubernetes v1.13. CSI 的支持在 Kubernetes v1.9 中作为 alpha 特性引入，在 Kubernetes v1.10 中转为 beta 特性，并在 Kubernetes v1.13 正式 GA。 -{{< note >}} <!-- Support for CSI spec versions 0.2 and 0.3 are deprecated in Kubernetes v1.13 and will be removed in a future release. --> +{{< note >}} +Kubernetes v1.13中不支持 CSI 规范版本0.2和0.3，并将在以后的版本中删除。 {{< /note >}} -Kubernetes v1.13中不支持 CSI 规范版本0.2和0.3，并将在以后的版本中删除。 - -{{< note >}} <!-- CSI drivers may not be compatible across all Kubernetes releases. Please check the specific CSI driver's documentation for supported deployments steps for each Kubernetes release and a compatibility matrix. --> - +{{< note >}} CSI驱动程序可能并非在所有Kubernetes版本中都兼容。 请查看特定CSI驱动程序的文档，以获取每个 Kubernetes 版本所支持的部署步骤以及兼容性列表。 - {{< /note >}} <!-- @@ -2065,7 +2007,6 @@ persistent volume: The value is passed as `volume_id` on all calls to the CSI volume driver when referencing the volume. --> - - `volumeHandle`：唯一标识卷的字符串值。 该值必须与CSI 驱动程序在 `CreateVolumeResponse` 的 `volume_id` 字段中返回的值相对应；接口定义在 [CSI spec](https://github.com/container-storageinterface/spec/blob/master/spec.md#createvolume) 中。 在所有对 CSI 卷驱动程序的调用中，引用该 CSI 卷时都使用此值作为 `volume_id` 参数。 @@ -2076,7 +2017,6 @@ persistent volume: passed to the CSI driver via the `readonly` field in the `ControllerPublishVolumeRequest`. --> - - `readOnly`：一个可选的布尔值，指示通过 `ControllerPublished` 关联该卷时是否设置该卷为只读。 默认值是 false。 该值通过 `ControllerPublishVolumeRequest` 中的 `readonly` 字段传递给 CSI 驱动程序。 @@ -2090,7 +2030,6 @@ persistent volume: `ControllerPublishVolumeRequest`, `NodeStageVolumeRequest`, and `NodePublishVolumeRequest`. --> - - `fsType`：如果 PV 的 `VolumeMode` 为 `Filesystem`，那么此字段指定挂载卷时应该使用的文件系统。 如果卷尚未格式化，并且支持格式化，此值将用于格式化卷。 此值可以通过 `ControllerPublishVolumeRequest`、`NodeStageVolumeRequest` 和 @@ -2117,7 +2056,6 @@ persistent volume: optional, and may be empty if no secret is required. If the secret object contains more than one secret, all secrets are passed. --> - - `controllerPublishSecretRef`：对包含敏感信息的 secret 对象的引用；该敏感信息会被传递给 CSI 驱动来完成 CSI `ControllerPublishVolume` 和 `ControllerUnpublishVolume` 调用。 此字段是可选的；在不需要 secret 时可以是空的。 如果 secret 对象包含多个 secret，则所有的 secret 都会被传递。 @@ -2129,7 +2067,6 @@ persistent volume: is required. If the secret object contains more than one secret, all secrets are passed. --> - - `nodeStageSecretRef`：对包含敏感信息的 secret 对象的引用，以传递给 CSI 驱动来完成 CSI `NodeStageVolume` 调用。 此字段是可选的，如果不需要 secret，则可能是空的。 如果 secret 对象包含多个 secret，则传递所有 secret。 @@ -2141,7 +2078,6 @@ persistent volume: secret is required. If the secret object contains more than one secret, all secrets are passed. --> - - `nodePublishSecretRef`：对包含敏感信息的 secret 对象的引用，以传递给 CSI 驱动来完成 CSI ``NodePublishVolume` 调用。 此字段是可选的，如果不需要 secret，则可能是空的。 如果 secret 对象包含多个 secret，则传递所有 secret。 @@ -2149,6 +2085,7 @@ persistent volume: <!-- #### CSI raw block volume support --> + #### CSI 原始块卷支持 {{< feature-state for_k8s_version="v1.14" state="beta" >}} @@ -2178,8 +2115,7 @@ CSI块卷支持功能已启用，但默认情况下启用。必须为此功能 Learn how to [setup your PV/PVC with raw block volume support](/docs/concepts/storage/persistent-volumes/#raw-block-volume-support). --> - -学习怎样[安装您的带有块卷支持的 PV/PVC](/docs/concepts/storage/persistent-volumes/#raw-block-volume-support)。 +学习怎样[安装您的带有块卷支持的 PV/PVC](/zh/docs/concepts/storage/persistent-volumes/#raw-block-volume-support)。 <!-- #### CSI ephemeral volumes @@ -2239,7 +2175,7 @@ documentation](https://kubernetes-csi.github.io/docs/) #### Migrating to CSI drivers from in-tree plugins --> -＃开发人员资源 +# 开发人员资源 有关如何开发 CSI 驱动程序的更多信息，请参考[kubernetes-csi文档](https://kubernetes-csi.github.io/docs/) #### 从 in-tree 插件迁移到 CSI 驱动程序 @@ -2277,7 +2213,6 @@ plugin path on each node (and in some cases master). Pods interact with FlexVolume drivers through the `flexvolume` in-tree plugin. More details can be found [here](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-storage/flexvolume.md). --> - FlexVolume 是一个自 1.2 版本（在 CSI 之前）以来在 Kubernetes 中一直存在的 out-of-tree 插件接口。 它使用基于 exec 的模型来与驱动程序对接。 用户必须在每个节点（在某些情况下是主节点）上的预定义卷插件路径中安装 FlexVolume 驱动程序可执行文件。 @@ -2356,8 +2291,6 @@ Its values are: 该模式等同于 [Linux 内核文档](https://www.kernel.org/doc/Documentation/filesystems/sharedsubtree.txt) 中描述的 `rshared` 挂载传播选项。 - -{{< caution >}} <!-- `Bidirectional` mount propagation can be dangerous. It can damage the host operating system and therefore it is allowed only in privileged @@ -2365,12 +2298,11 @@ Containers. Familiarity with Linux kernel behavior is strongly recommended. In addition, any volume mounts created by Containers in Pods must be destroyed (unmounted) by the Containers on termination. --> - +{{< caution >}} `Bidirectional` 形式的挂载传播可能比较危险。 它可以破坏主机操作系统，因此它只被允许在特权容器中使用。 强烈建议您熟悉 Linux 内核行为。 此外，由 Pod 中的容器创建的任何卷挂载必须在终止时由容器销毁（卸载）。 - {{< /caution >}} <!-- @@ -2412,4 +2344,3 @@ sudo systemctl restart docker * 参考[使用持久卷部署 WordPress 和 MySQL](/zh/docs/tutorials/stateful-application/mysql-wordpress-persistent-volume/) 示例。 - diff --git a/content/zh/docs/concepts/workloads/controllers/cron-jobs.md b/content/zh/docs/concepts/workloads/controllers/cron-jobs.md index bda7bb3dc1..f6a5eefa9c 100644 --- a/content/zh/docs/concepts/workloads/controllers/cron-jobs.md +++ b/content/zh/docs/concepts/workloads/controllers/cron-jobs.md @@ -5,15 +5,9 @@ weight: 80 --- <!-- ---- -reviewers: -- erictune -- soltysh -- janetkuo title: CronJob content_type: concept weight: 80 ---- --> <!-- overview --> @@ -26,10 +20,11 @@ A _Cron Job_ creates [Jobs](/docs/concepts/workloads/controllers/jobs-run-to-com One CronJob object is like one line of a _crontab_ (cron table) file. It runs a job periodically on a given schedule, written in [Cron](https://en.wikipedia.org/wiki/Cron) format. --> +_Cron Job_ 创建基于时间调度的 [Jobs](/zh/docs/concepts/workloads/controllers/jobs-run-to-completion/)。 -_Cron Job_ 创建基于时间调度的 [Jobs](/docs/concepts/workloads/controllers/jobs-run-to-completion/)。 - -一个 CronJob 对象就像 _crontab_ (cron table) 文件中的一行。它用 [Cron](https://en.wikipedia.org/wiki/Cron) 格式进行编写，并周期性地在给定的调度时间执行 Job。 +一个 CronJob 对象就像 _crontab_ (cron table) 文件中的一行。 +它用 [Cron](https://en.wikipedia.org/wiki/Cron) 格式进行编写， +并周期性地在给定的调度时间执行 Job。 <!-- All **CronJob** `schedule:` times are based on the timezone of the @@ -40,44 +35,66 @@ that the cron job controller uses. --> {{< caution >}} -所有 **CronJob** 的 `schedule:` 时间都是基于初始 Job 的主控节点的时区。 +所有 **CronJob** 的 `schedule:` 时间都是基于 +{{< glossary_tooltip term_id="kube-controller-manager" text="kube-controller-manager" >}}. +的时区。 -如果你的控制平面在 Pod 或是裸容器中运行了主控程序 (kube-controller-manager)， -那么为该容器设置的时区将会决定定时任务的控制器所使用的时区。 +如果你的控制平面在 Pod 或是裸容器中运行了 kube-controller-manager， +那么为该容器所设置的时区将会决定 Cron Job 的控制器所使用的时区。 {{< /caution >}} <!-- When creating the manifest for a CronJob resource, make sure the name you provide -is no longer than 52 characters. This is because the CronJob controller will automatically +is a valid [DNS subdomain name](/docs/concepts/overview/working-with-objects/names#dns-subdomain-names). +The name must be no longer than 52 characters. This is because the CronJob controller will automatically append 11 characters to the job name provided and there is a constraint that the maximum length of a Job name is no more than 63 characters. --> -为 CronJob 资源创建清单时，请确保创建的名称不超过 52 个字符。这是因为 CronJob 控制器将自动在提供的作业名称后附加 11 个字符，并且存在一个限制，即作业名称的最大长度不能超过 63 个字符。 - - -<!-- -For instructions on creating and working with cron jobs, and for an example of a spec file for a cron job, see [Running automated tasks with cron jobs](/docs/tasks/job/automated-tasks-with-cron-jobs). ---> - -有关创建和使用 CronJob 的说明及规范文件的示例，请参见[使用 CronJob 运行自动化任务](/docs/tasks/job/automated-tasks-with-cron-jobs)。 - - - - +为 CronJob 资源创建清单时，请确保所提供的名称是一个合法的 +[DNS 子域名](/zh/docs/concepts/overview/working-with-objects/names#dns-subdomain-names). +名称不能超过 52 个字符。 +这是因为 CronJob 控制器将自动在提供的 Job 名称后附加 11 个字符，并且存在一个限制， +即 Job 名称的最大长度不能超过 63 个字符。 <!-- body --> <!-- -## Cron Job Limitations +## CronJob + +CronJobs are useful for creating periodic and recurring tasks, like running backups or +sending emails. CronJobs can also schedule individual tasks for a specific time, such as +scheduling a Job for when your cluster is likely to be idle. +--> +## CronJob + +CronJobs 对于创建周期性的、反复重复的任务很有用，例如执行数据备份或者发送邮件。 +CronJobs 也可以用来计划在指定时间来执行的独立任务，例如计划当集群看起来很空闲时 +执行某个 Job。 + +<!-- +### Example + +This example CronJob manifest prints the current time and a hello message every minute: +--> +### 示例 + +下面的 CronJob 示例清单会在每分钟打印出当前时间和问候消息： + +{{< codenew file="application/job/cronjob.yaml" >}} + +[使用 CronJob 运行自动化任务](/zh/docs/tasks/job/automated-tasks-with-cron-jobs/) +一文会为你详细讲解此例。 + +<!-- +## CronJob Limitations A cron job creates a job object _about_ once per execution time of its schedule. We say "about" because there are certain circumstances where two jobs might be created, or no job might be created. We attempt to make these rare, but do not completely prevent them. Therefore, jobs should be _idempotent_. --> +## CronJob 限制 {#cron-job-limitations} -## CronJob 限制 - -CronJob 创建 Job 对象，每个 Job 的执行次数大约为一次。 +CronJob 根据其计划编排，在每次该执行任务的时候大约会创建一个 Job。 我们之所以说 "大约"，是因为在某些情况下，可能会创建两个 Job，或者不会创建任何 Job。 我们试图使这些情况尽量少发生，但不能完全杜绝。因此，Job 应该是 _幂等的_。 @@ -86,14 +103,15 @@ If `startingDeadlineSeconds` is set to a large value or left unset (the default) and if `concurrencyPolicy` is set to `Allow`, the jobs will always run at least once. --> - -如果 `startingDeadlineSeconds` 设置为很大的数值或未设置（默认），并且 `concurrencyPolicy` 设置为 `Allow`，则作业将始终至少运行一次。 +如果 `startingDeadlineSeconds` 设置为很大的数值或未设置（默认），并且 +`concurrencyPolicy` 设置为 `Allow`，则作业将始终至少运行一次。 <!-- For every CronJob, the CronJob {{< glossary_tooltip term_id="controller" >}} checks how many schedules it missed in the duration from its last scheduled time until now. If there are more than 100 missed schedules, then it does not start the job and logs the error --> - -对于每个 CronJob，CronJob {{< glossary_tooltip term_text="控制器" term_id="controller" >}} 检查从上一次调度的时间点到现在所错过了调度次数。如果错过的调度次数超过 100 次，那么它就不会启动这个任务，并记录这个错误: +对于每个 CronJob，CronJob {{< glossary_tooltip term_text="控制器" term_id="controller" >}} +检查从上一次调度的时间点到现在所错过了调度次数。如果错过的调度次数超过 100 次， +那么它就不会启动这个任务，并记录这个错误: ```` Cannot determine if job needs to be started. Too many missed start time (> 100). Set or decrease .spec.startingDeadlineSeconds or check clock skew. @@ -102,22 +120,24 @@ Cannot determine if job needs to be started. Too many missed start time (> 100). <!-- It is important to note that if the `startingDeadlineSeconds` field is set (not `nil`), the controller counts how many missed jobs occurred from the value of `startingDeadlineSeconds` until now rather than from the last scheduled time until now. For example, if `startingDeadlineSeconds` is `200`, the controller counts how many missed jobs occurred in the last 200 seconds. --> - -需要注意的是，如果 `startingDeadlineSeconds` 字段非空，则控制器会统计从 `startingDeadlineSeconds` 设置的值到现在而不是从上一个计划时间到现在错过了多少次 Job。例如，如果 `startingDeadlineSeconds` 是 `200`，则控制器会统计在过去 200 秒中错过了多少次 Job。 +需要注意的是，如果 `startingDeadlineSeconds` 字段非空，则控制器会统计从 +`startingDeadlineSeconds` 设置的值到现在而不是从上一个计划时间到现在错过了多少次 Job。 +例如，如果 `startingDeadlineSeconds` 是 `200`，则控制器会统计在过去 200 秒中错过了多少次 Job。 <!-- A CronJob is counted as missed if it has failed to be created at its scheduled time. For example, If `concurrencyPolicy` is set to `Forbid` and a CronJob was attempted to be scheduled when there was a previous schedule still running, then it would count as missed. --> - -如果未能在调度时间内创建 CronJob，则计为错过。例如，如果 `concurrencyPolicy` 被设置为 `Forbid`，并且当前有一个调度仍在运行的情况下，试图调度的 CronJob 将被计算为错过。 +如果未能在调度时间内创建 CronJob，则计为错过。 +例如，如果 `concurrencyPolicy` 被设置为 `Forbid`，并且当前有一个调度仍在运行的情况下， +试图调度的 CronJob 将被计算为错过。 <!-- For example, suppose a CronJob is set to schedule a new Job every one minute beginning at `08:30:00`, and its `startingDeadlineSeconds` field is not set. If the CronJob controller happens to be down from `08:29:00` to `10:21:00`, the job will not start as the number of missed jobs which missed their schedule is greater than 100. --> - -例如，假设一个 CronJob 被设置为 `08:30:00` 准时开始，它的 `startingDeadlineSeconds` 字段被设置为 10，如果在 `08:29:00` 时将 CronJob 控制器的时间改为 `08:42:00`，Job 将不会启动。 +例如，假设一个 CronJob 被设置为 `08:30:00` 准时开始，它的 `startingDeadlineSeconds` +字段被设置为 10，如果在 `08:29:00` 时将 CronJob 控制器的时间改为 `08:42:00`，Job 将不会启动。 如果觉得晚些开始比没有启动好，那请设置一个较长的 `startingDeadlineSeconds`。 <!-- @@ -125,7 +145,12 @@ To illustrate this concept further, suppose a CronJob is set to schedule a new J `startingDeadlineSeconds` is set to 200 seconds. If the CronJob controller happens to be down for the same period as the previous example (`08:29:00` to `10:21:00`,) the Job will still start at 10:22:00. This happens as the controller now checks how many missed schedules happened in the last 200 seconds (ie, 3 missed schedules), rather than from the last scheduled time until now. --> -为了进一步阐述这个概念，假设将 CronJob 设置为从 `08:30:00` 开始每隔一分钟创建一个新的 Job，并将其 `startingDeadlineSeconds` 字段设置为 200 秒。 如果 CronJob 控制器恰好在与上一个示例相同的时间段（`08:29:00` 到 `10:21:00`）停机，则 Job 仍将从 `10:22:00` 开始。造成这种情况的原因是控制器现在检查在最近 200 秒（即 3 个错过的调度）中发生了多少次错过的 Job 调度，而不是从现在为止的最后一个调度时间开始。 +为了进一步阐述这个概念，假设将 CronJob 设置为从 `08:30:00` 开始每隔一分钟创建一个新的 Job， +并将其 `startingDeadlineSeconds` 字段设置为 200 秒。 +如果 CronJob 控制器恰好在与上一个示例相同的时间段（`08:29:00` 到 `10:21:00`）终止运行， +则 Job 仍将从 `10:22:00` 开始。 +造成这种情况的原因是控制器现在检查在最近 200 秒（即 3 个错过的调度）中发生了多少次错过的 +Job 调度，而不是从现在为止的最后一个调度时间开始。 <!-- The CronJob is only responsible for creating Jobs that match its schedule, and @@ -133,5 +158,15 @@ the Job in turn is responsible for the management of the Pods it represents. --> CronJob 仅负责创建与其调度时间相匹配的 Job，而 Job 又负责管理其代表的 Pod。 +## {{% heading "whatsnext" %}} +<!-- +[Cron expression format](https://en.wikipedia.org/wiki/Cron) +documents the format of CronJob `schedule` fields. + +For instructions on creating and working with cron jobs, and for an example of a spec file for a cron job, see [Running automated tasks with cron jobs](/docs/tasks/job/automated-tasks-with-cron-jobs). +--> + +* 进一步了解 [Cron 表达式的格式](https://en.wikipedia.org/wiki/Cron)，学习设置 CronJob `schedule` 字段 +* 有关创建和使用 CronJob 的说明及示例规约文件，请参见 + [使用 CronJob 运行自动化任务](/zh/docs/tasks/job/automated-tasks-with-cron-jobs/)。 - diff --git a/content/zh/docs/concepts/workloads/controllers/daemonset.md b/content/zh/docs/concepts/workloads/controllers/daemonset.md index edcbc29399..c9b58f7bd5 100644 --- a/content/zh/docs/concepts/workloads/controllers/daemonset.md +++ b/content/zh/docs/concepts/workloads/controllers/daemonset.md @@ -5,17 +5,9 @@ weight: 50 --- <!-- ---- -reviewers: -- enisoc -- erictune -- foxish -- janetkuo -- kow3ns title: DaemonSet content_type: concept weight: 50 ---- ---> <!-- overview --> @@ -25,35 +17,32 @@ A _DaemonSet_ ensures that all (or some) Nodes run a copy of a Pod. As nodes ar cluster, Pods are added to them. As nodes are removed from the cluster, those Pods are garbage collected. Deleting a DaemonSet will clean up the Pods it created. ---> -_DaemonSet_ 确保全部（或者某些）节点上运行一个 Pod 的副本。当有节点加入集群时， -也会为他们新增一个 Pod 。当有节点从集群移除时，这些 Pod 也会被回收。删除 DaemonSet 将会删除它创建的所有 Pod。 +_DaemonSet_ 确保全部（或者某些）节点上运行一个 Pod 的副本。 +当有节点加入集群时， 也会为他们新增一个 Pod 。 +当有节点从集群移除时，这些 Pod 也会被回收。删除 DaemonSet 将会删除它创建的所有 Pod。 <!-- Some typical uses of a DaemonSet are: -- running a cluster storage daemon, such as `glusterd`, `ceph`, on each node. -- running a logs collection daemon on every node, such as `fluentd` or `logstash`. -- running a node monitoring daemon on every node, such as [Prometheus Node Exporter](https://github.com/prometheus/node_exporter), [Flowmill](https://github.com/Flowmill/flowmill-k8s/), [Sysdig Agent](https://docs.sysdig.com), `collectd`, [Dynatrace OneAgent](https://www.dynatrace.com/technologies/kubernetes-monitoring/), [AppDynamics Agent](https://docs.appdynamics.com/display/CLOUD/Container+Visibility+with+Kubernetes), [Datadog agent](https://docs.datadoghq.com/agent/kubernetes/daemonset_setup/), [New Relic agent](https://docs.newrelic.com/docs/integrations/kubernetes-integration/installation/kubernetes-installation-configuration), Ganglia `gmond` or [Instana Agent](https://www.instana.com/supported-integrations/kubernetes-monitoring/). +- running a cluster storage daemon on every node +- running a logs collection daemon on every node +- running a node monitoring daemon on every node --> DaemonSet 的一些典型用法： -- 在每个节点上运行集群存储 DaemonSet，例如 `glusterd`、`ceph`。 -- 在每个节点上运行日志收集 DaemonSet，例如 `fluentd`、`logstash`。 -- 在每个节点上运行监控 DaemonSet，例如 [Prometheus Node Exporter](https://github.com/prometheus/node_exporter)、[Flowmill](https://github.com/Flowmill/flowmill-k8s/)、[Sysdig 代理](https://docs.sysdig.com)、`collectd`、[Dynatrace OneAgent](https://www.dynatrace.com/technologies/kubernetes-monitoring/)、[AppDynamics 代理](https://docs.appdynamics.com/display/CLOUD/Container+Visibility+with+Kubernetes)、[Datadog 代理](https://docs.datadoghq.com/agent/kubernetes/daemonset_setup/)、[New Relic 代理](https://docs.newrelic.com/docs/integrations/kubernetes-integration/installation/kubernetes-installation-configuration)、Ganglia `gmond` 或者 [Instana 代理](https://www.instana.com/supported-integrations/kubernetes-monitoring/)。 +- 在每个节点上运行集群存守护进程 +- 在每个节点上运行日志收集守护进程 +- 在每个节点上运行监控守护进程 <!-- In a simple case, one DaemonSet, covering all nodes, would be used for each type of daemon. A more complex setup might use multiple DaemonSets for a single type of daemon, but with different flags and/or different memory and cpu requests for different hardware types. --> -一个简单的用法是在所有的节点上都启动一个 DaemonSet，将被作为每种类型的 daemon 使用。 - -一个稍微复杂的用法是单独对每种 daemon 类型使用多个 DaemonSet，但具有不同的标志， +一种简单的用法是为每种类型的守护进程在所有的节点上都启动一个 DaemonSet。 +一个稍微复杂的用法是为同一种守护进程部署多个 DaemonSet；每个具有不同的标志， 并且对不同硬件类型具有不同的内存、CPU 要求。 - - - <!-- body --> <!-- @@ -68,14 +57,16 @@ different flags and/or different memory and cpu requests for different hardware <!-- You can describe a DaemonSet in a YAML file. For example, the `daemonset.yaml` file below describes a DaemonSet that runs the fluentd-elasticsearch Docker image: --> -您可以在 YAML 文件中描述 DaemonSet。例如，下面的 daemonset.yaml 文件描述了一个运行 fluentd-elasticsearch Docker 镜像的 DaemonSet： +你可以在 YAML 文件中描述 DaemonSet。 +例如，下面的 daemonset.yaml 文件描述了一个运行 fluentd-elasticsearch Docker 镜像的 DaemonSet： {{< codenew file="controllers/daemonset.yaml" >}} <!-- -* Create a DaemonSet based on the YAML file: +Create a DaemonSet based on the YAML file: --> -* 基于 YAML 文件创建 DaemonSet: +基于 YAML 文件创建 DaemonSet: + ``` kubectl apply -f https://k8s.io/examples/controllers/daemonset.yaml ``` @@ -84,22 +75,32 @@ kubectl apply -f https://k8s.io/examples/controllers/daemonset.yaml ### Required Fields As with all other Kubernetes config, a DaemonSet needs `apiVersion`, `kind`, and `metadata` fields. For -general information about working with config files, see [deploying applications](/docs/user-guide/deploying-applications/), +general information about working with config files, see + [running stateless applications](/docs/tasks/run-application/run-stateless-application-deployment/), [configuring containers](/docs/tasks/), and [object management using kubectl](/docs/concepts/overview/working-with-objects/object-management/) documents. +The name of a DaemonSet object must be a valid +[DNS subdomain name](/docs/concepts/overview/working-with-objects/names#dns-subdomain-names). + A DaemonSet also needs a [`.spec`](https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status) section. --> ### 必需字段 -和其它所有 Kubernetes 配置一样，DaemonSet 需要 `apiVersion`、`kind` 和 `metadata` 字段。有关配置文件的基本信息，详见文档 [部署应用](/docs/user-guide/deploying-applications/)、[配置容器](/docs/tasks/) 和 [使用 kubectl 进行对象管理](/docs/concepts/overview/object-management-kubectl/overview/)。 + +和所有其他 Kubernetes 配置一样，DaemonSet 需要 `apiVersion`、`kind` 和 `metadata` 字段。 +有关配置文件的基本信息，参见 +[部署应用](/zh/docs/tasks/run-application/run-stateless-application-deployment/)、 +[配置容器](/zh/docs/tasks/)和 +[使用 kubectl 进行对象管理](/zh/docs/concepts/overview/working-with-objects/object-management/) +文档。 + +DaemonSet 对象的名称必须是一个合法的 +[DNS 子域名](/zh/docs/concepts/overview/working-with-objects/names#dns-subdomain-names)。 DaemonSet 也需要一个 [`.spec`](https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status) 配置段。 <!-- ### Pod Template ---> -### Pod 模板 -<!-- The `.spec.template` is one of the required fields in `.spec`. The `.spec.template` is a [pod template](/docs/concepts/workloads/pods/pod-overview/#pod-templates). It has exactly the same schema as a [Pod](/docs/concepts/workloads/pods/pod/), except it is nested and does not have an `apiVersion` or `kind`. @@ -110,20 +111,23 @@ labels (see [pod selector](#pod-selector)). A Pod Template in a DaemonSet must have a [`RestartPolicy`](/docs/concepts/workloads/pods/pod-lifecycle/#restart-policy) equal to `Always`, or be unspecified, which defaults to `Always`. --> +### Pod 模板 {#pod-template} + `.spec` 中唯一必需的字段是 `.spec.template`。 -`.spec.template` 是一个 [Pod 模板](/docs/concepts/workloads/pods/pod-overview/#pod-templates)。除了它是嵌套的，而且不具有 `apiVersion` 或 `kind` 字段，它与 [Pod](/docs/concepts/workloads/pods/pod/) 具有相同的 schema。 +`.spec.template` 是一个 [Pod 模板](/zh/docs/concepts/workloads/pods/#pod-templates)。 +除了它是嵌套的，因而不具有 `apiVersion` 或 `kind` 字段之外，它与 +{{< glossary_tooltip text="Pod" term_id="pod" >}} 具有相同的 schema。 -除了 Pod 必需字段外，在 DaemonSet 中的 Pod 模板必须指定合理的标签（查看 [Pod Selector](#pod-selector)）。 +除了 Pod 必需字段外，在 DaemonSet 中的 Pod 模板必须指定合理的标签（查看 [Pod 选择算符](#pod-selector)）。 -在 DaemonSet 中的 Pod 模板必须具有一个值为 `Always` 的 [`RestartPolicy`](/docs/user-guide/pod-states)，或者未指定它的值，默认是 `Always`。 +在 DaemonSet 中的 Pod 模板必须具有一个值为 `Always` 的 +[`RestartPolicy`](/zh/docs/concepts/workloads/pods/pod-lifecycle/#restart-policy)。 +当该值未指定时，默认是 `Always`。 <!-- ### Pod Selector ---> -### Pod Selector {#pod-selector} -<!-- The `.spec.selector` field is a pod selector. It works the same as the `.spec.selector` of a [Job](/docs/concepts/jobs/run-to-completion-finite-workloads/). @@ -133,33 +137,42 @@ defaulting was not compatible with `kubectl apply`. Also, once a DaemonSet is cr its `.spec.selector` can not be mutated. Mutating the pod selector can lead to the unintentional orphaning of Pods, and it was found to be confusing to users. --> -`.spec.selector` 字段表示 Pod Selector，它与 [Job](/docs/concepts/jobs/run-to-completion-finite-workloads/) 的 `.spec.selector` 的作用是相同的。 +### Pod 选择算符 {#pod-selector} -从 Kubernetes 1.8 开始，您必须指定与 `.spec.template` 的标签匹配的 pod selector。当不配置时，pod selector 将不再有默认值。selector 默认与 `kubectl apply` 不兼容。 此外，一旦创建了 DaemonSet，它的 `.spec.selector` 就不能修改。修改 pod selector 可能导致 Pod 意外悬浮，并且这对用户来说是困惑的。 +`.spec.selector` 字段表示 Pod 选择算符，它与 +[Job](/zh/docs/concepts/workloads/controllers/job/) 的 `.spec.selector` 的作用是相同的。 + +从 Kubernetes 1.8 开始，您必须指定与 `.spec.template` 的标签匹配的 Pod 选择算符。 +用户不指定 Pod 选择算符时，该字段不再有默认值。 +选择算符的默认值生成结果与 `kubectl apply` 不兼容。 +此外，一旦创建了 DaemonSet，它的 `.spec.selector` 就不能修改。 +修改 Pod 选择算符可能导致 Pod 意外悬浮，并且这对用户来说是费解的。 <!-- The `.spec.selector` is an object consisting of two fields: --> -`spec.selector` 表示一个对象，它由如下两个字段组成： +`spec.selector` 是一个对象，如下两个字段组成： <!-- * `matchLabels` - works the same as the `.spec.selector` of a [ReplicationController](/docs/concepts/workloads/controllers/replicationcontroller/). * `matchExpressions` - allows to build more sophisticated selectors by specifying key, list of values and an operator that relates the key and values. --> -* `matchLabels` - 与 [ReplicationController](/docs/concepts/workloads/controllers/replicationcontroller/) 的 `.spec.selector` 的作用相同。 -* `matchExpressions` - 允许构建更加复杂的 Selector，可以通过指定 key、value 列表 -，以及与 key 和 value 列表相关的操作符。 +* `matchLabels` - 与 [ReplicationController](/zh/docs/concepts/workloads/controllers/replicationcontroller/) + 的 `.spec.selector` 的作用相同。 +* `matchExpressions` - 允许构建更加复杂的选择器，可以通过指定 key、value + 列表以及将 key 和 value 列表关联起来的 operator。 <!-- When the two are specified the result is ANDed. --> -当上述两个字段都指定时，结果表示的是 AND 关系。 +当上述两个字段都指定时，结果会按逻辑与（AND）操作处理。 <!-- If the `.spec.selector` is specified, it must match the `.spec.template.metadata.labels`. Config with these not matching will be rejected by the API. --> -如果指定了 `.spec.selector`，必须与 `.spec.template.metadata.labels` 相匹配。如果与它们配置的不匹配，则会被 API 拒绝。 +如果指定了 `.spec.selector`，必须与 `.spec.template.metadata.labels` 相匹配。 +如果与后者不匹配，则 DeamonSet 会被 API 拒绝。 <!-- Also you should not normally create any Pods whose labels match this selector, either directly, via @@ -168,20 +181,24 @@ another DaemonSet, or via another workload resource such as ReplicaSet. Otherwi Kubernetes will not stop you from doing this. One case where you might want to do this is manually create a Pod with a different value on a node for testing. --> -另外，通常不应直接通过另一个 DaemonSet 或另一个工作负载资源（例如 ReplicaSet）来创建其标签与该选择器匹配的任何 Pod。否则，DaemonSet {{< glossary_tooltip term_text="控制器" term_id="controller" >}}会认为这些 Pod 是由它创建的。Kubernetes 不会阻止你这样做。您可能要执行此操作的一种情况是，手动在节点上创建具有不同值的 Pod 进行测试。 +另外，通常不应直接通过另一个 DaemonSet 或另一个工作负载资源（例如 ReplicaSet） +来创建其标签与该选择器匹配的任何 Pod。否则，DaemonSet +{{< glossary_tooltip term_text="控制器" term_id="controller" >}} +会认为这些 Pod 是由它创建的。 +Kubernetes 不会阻止你这样做。 +你可能要执行此操作的一种情况是，手动在节点上创建具有不同值的 Pod 进行测试。 <!-- ### Running Pods on Only Some Nodes ---> -### 仅在某些节点上运行 Pod -<!-- If you specify a `.spec.template.spec.nodeSelector`, then the DaemonSet controller will create Pods on nodes which match that [node selector](/docs/concepts/configuration/assign-pod-node/). Likewise if you specify a `.spec.template.spec.affinity`, then DaemonSet controller will create Pods on nodes which match that [node affinity](/docs/concepts/configuration/assign-pod-node/). If you do not specify either, then the DaemonSet controller will create Pods on all nodes. --> +### 仅在某些节点上运行 Pod + 如果指定了 `.spec.template.spec.nodeSelector`，DaemonSet Controller 将在能够与 [Node Selector](/docs/concepts/configuration/assign-pod-node/) 匹配的节点上创建 Pod。类似这种情况，可以指定 `.spec.template.spec.affinity`，然后 DaemonSet Controller 将在能够与 [node Affinity](/docs/concepts/configuration/assign-pod-node/) 匹配的节点上创建 Pod。 如果根本就没有指定，则 DaemonSet Controller 将在所有节点上创建 Pod。 @@ -192,7 +209,7 @@ If you do not specify either, then the DaemonSet controller will create Pods on --> ## 如何调度 Daemon Pods -### 通过默认 scheduler 调度 +### 通过默认调度器调度 {{< feature-state state="stable" for-kubernetes-version="1.17" >}} @@ -209,10 +226,15 @@ That introduces the following issues: is handled by default scheduler. When preemption is enabled, the DaemonSet controller will make scheduling decisions without considering pod priority and preemption. --> -DaemonSet 确保所有符合条件的节点都运行该 Pod 的一个副本。通常，运行 Pod 的节点由 Kubernetes 调度器抉择。不过，DaemonSet pods 由 DaemonSet 控制器创建和调度。这将引入以下问题： +DaemonSet 确保所有符合条件的节点都运行该 Pod 的一个副本。 +通常，运行 Pod 的节点由 Kubernetes 调度器选择。 +不过，DaemonSet pods 由 DaemonSet 控制器创建和调度。这就带来了以下问题： - * Pod 行为的不一致性：等待调度的正常 Pod 已被创建并处于 `Pending` 状态，但 DaemonSet pods 未在 `Pending` 状态下创建。 这使用户感到困惑。 - * [Pod preemption](/docs/concepts/configuration/pod-priority-preemption/)由默认 scheduler 处理。 启用抢占后，DaemonSet 控制器将在不考虑 pod 优先级和抢占的情况下制定调度决策。 +* Pod 行为的不一致性：正常 Pod 在被创建后等待调度时处于 `Pending` 状态， + DaemonSet Pods 创建后不会处于 `Pending` 状态下。这使用户感到困惑。 +* [Pod 抢占](/zh/docs/concepts/configuration/pod-priority-preemption/) + 由默认调度器处理。启用抢占后，DaemonSet 控制器将在不考虑 Pod 优先级和抢占 + 的情况下制定调度决策。 <!-- `ScheduleDaemonSetPods` allows you to schedule DaemonSets using the default @@ -223,7 +245,12 @@ the DaemonSet pod already exists, it is replaced. The DaemonSet controller only performs these operations when creating or modifying DaemonSet pods, and no changes are made to the `spec.template` of the DaemonSet. --> -`ScheduleDaemonSetPods` 允许您使用默认调度器而不是 DaemonSet 控制器来调度 DaemonSets，方法是将 `NodeAffinity` 添加到 DaemonSet pods，而不是 `.spec.nodeName`。 然后使用默认调度器将 pod 绑定到目标主机。 如果 DaemonSet pod 的亲和节点已存在，则替换它。 DaemonSet 控制器仅在创建或修改 DaemonSet pods 时执行这些操作，并且不对 DaemonSet 的 `spec.template` 进行任何更改。 +`ScheduleDaemonSetPods` 允许您使用默认调度器而不是 DaemonSet 控制器来调度 DaemonSets， +方法是将 `NodeAffinity` 条件而不是 `.spec.nodeName` 条件添加到 DaemonSet Pods。 +默认调度器接下来将 Pod 绑定到目标主机。 +如果 DaemonSet Pod 的节点亲和性配置已存在，则被替换。 +DaemonSet 控制器仅在创建或修改 DaemonSet Pod 时执行这些操作， +并且不回更改 DaemonSet 的 `spec.template`。 ```yaml nodeAffinity: @@ -241,7 +268,8 @@ In addition, `node.kubernetes.io/unschedulable:NoSchedule` toleration is added automatically to DaemonSet Pods. The default scheduler ignores `unschedulable` Nodes when scheduling DaemonSet Pods. --> -此外，系统会自动添加 `node.kubernetes.io/unschedulable：NoSchedule` 容忍度到 DaemonSet Pods。 在调度 DaemonSet Pod 时，默认调度器会忽略 `unschedulable` 节点。 +此外，系统会自动添加 `node.kubernetes.io/unschedulable：NoSchedule` 容忍度到 +DaemonSet Pods。在调度 DaemonSet Pod 时，默认调度器会忽略 `unschedulable` 节点。 <!-- ### Taints and Tolerations @@ -251,25 +279,23 @@ Although Daemon Pods respect the following tolerations are added to DaemonSet Pods automatically according to the related features. --> -### 污点和容忍度 +### 污点和容忍度 {#taint-and-toleration} -尽管 Daemon Pods 遵循[污点和容忍度](/docs/concepts/configuration/taint-and-toleration) 规则，根据相关特性，会自动将以下容忍度添加到 DaemonSet Pods 中。 +尽管 Daemon Pods 遵循[污点和容忍度](/zh/docs/concepts/scheduling-eviction/taint-and-toleration) +规则，根据相关特性，控制器会自动将以下容忍度添加到 DaemonSet Pod： -| 容忍度关键词 | 影响 | 版本 | 描述 | +| 容忍度键名 | 效果 | 版本 | 描述 | | ---------------------------------------- | ---------- | ------- | ------------------------------------------------------------ | -| `node.kubernetes.io/not-ready` | NoExecute | 1.13+ | DaemonSet pods will not be evicted when there are node problems such as a network partition. | -| `node.kubernetes.io/unreachable` | NoExecute | 1.13+ | DaemonSet pods will not be evicted when there are node problems such as a network partition. | -| `node.kubernetes.io/disk-pressure` | NoSchedule | 1.8+ | | -| `node.kubernetes.io/memory-pressure` | NoSchedule | 1.8+ | | -| `node.kubernetes.io/unschedulable` | NoSchedule | 1.12+ | DaemonSet pods tolerate unschedulable attributes by default scheduler. | -| `node.kubernetes.io/network-unavailable` | NoSchedule | 1.12+ | DaemonSet pods, who uses host network, tolerate network-unavailable attributes by default scheduler. | - - +| `node.kubernetes.io/not-ready` | NoExecute | 1.13+ | 当出现类似网络断开的情况导致节点问题时，DaemonSet Pod 不会被逐出。 | +| `node.kubernetes.io/unreachable` | NoExecute | 1.13+ | 当出现类似于网络断开的情况导致节点问题时，DaemonSet Pod 不会被逐出。 | +| `node.kubernetes.io/disk-pressure` | NoSchedule | 1.8+ | | +| `node.kubernetes.io/memory-pressure` | NoSchedule | 1.8+ | | +| `node.kubernetes.io/unschedulable` | NoSchedule | 1.12+ | DaemonSet Pod 能够容忍默认调度器所设置的 `unschedulable` 属性. | +| `node.kubernetes.io/network-unavailable` | NoSchedule | 1.12+ | DaemonSet 在使用宿主网络时，能够容忍默认调度器所设置的 `network-unavailable` 属性。 | <!-- ## Communicating with Daemon Pods --> -## 与 Daemon Pods 通信 <!-- Some possible patterns for communicating with Pods in a DaemonSet are: @@ -283,19 +309,26 @@ Some possible patterns for communicating with Pods in a DaemonSet are: - **Service**: Create a service with the same Pod selector, and use the service to reach a daemon on a random node. (No way to reach specific node.) --> +## 与 Daemon Pods 通信 + 与 DaemonSet 中的 Pod 进行通信的几种可能模式如下： -- **Push**：将 DaemonSet 中的 Pod 配置为将更新发送到另一个 Service，例如统计数据库。 -- **NodeIP 和已知端口**：DaemonSet 中的 Pod 可以使用 `hostPort`，从而可以通过节点 IP 访问到 Pod。客户端能通过某种方法获取节点 IP 列表，并且基于此也可以获取到相应的端口。 -- **DNS**：创建具有相同 Pod Selector 的 [Headless Service](/docs/concepts/services-networking/service/#headless-services)，然后通过使用 `endpoints` 资源或从 DNS 中检索到多个 A 记录来发现 DaemonSet。 -- **Service**：创建具有相同 Pod Selector 的 Service，并使用该 Service 随机访问到某个节点上的 daemon（没有办法访问到特定节点）。 +- **Push**：配置 DaemonSet 中的 Pod，将更新发送到另一个服务，例如统计数据库。 + 这些服务没有客户端。 + +- **NodeIP 和已知端口**：DaemonSet 中的 Pod 可以使用 `hostPort`，从而可以通过节点 IP + 访问到 Pod。客户端能通过某种方法获取节点 IP 列表，并且基于此也可以获取到相应的端口。 + +- **DNS**：创建具有相同 Pod 选择算符的 + [无头服务](/zh/docs/concepts/services-networking/service/#headless-services)， + 通过使用 `endpoints` 资源或从 DNS 中检索到多个 A 记录来发现 DaemonSet。 + +- **Service**：创建具有相同 Pod 选择算符的服务，并使用该服务随机访问到某个节点上的 + 守护进程（没有办法访问到特定节点）。 <!-- ## Updating a DaemonSet ---> -## 更新 DaemonSet -<!-- If node labels are changed, the DaemonSet will promptly add Pods to newly matching nodes and delete Pods from newly not-matching nodes. @@ -303,28 +336,35 @@ You can modify the Pods that a DaemonSet creates. However, Pods do not allow al fields to be updated. Also, the DaemonSet controller will use the original template the next time a node (even with the same name) is created. --> -如果修改了节点标签，DaemonSet 将立刻向新匹配上的节点添加 Pod，同时删除不能够匹配的节点上的 Pod。 +## 更新 DaemonSet -您可以修改 DaemonSet 创建的 Pod。然而，不允许对 Pod 的所有字段进行更新。当下次 -节点（即使具有相同的名称）被创建时，DaemonSet Controller 还会使用最初的模板。 +如果节点的标签被修改，DaemonSet 将立刻向新匹配上的节点添加 Pod， +同时删除不匹配的节点上的 Pod。 + +你可以修改 DaemonSet 创建的 Pod。不过并非 Pod 的所有字段都可更新。 +下次当某节点（即使具有相同的名称）被创建时，DaemonSet 控制器还会使用最初的模板。 <!-- -You can delete a DaemonSet. If you specify `--cascade=false` with `kubectl`, then the Pods +You can delete a DaemonSet. If you specify `-cascade=false` with `kubectl`, then the Pods will be left on the nodes. If you subsequently create a new DaemonSet with the same selector, the new DaemonSet adopts the existing Pods. If any Pods need replacing the DaemonSet replaces them according to its `updateStrategy`. You can [perform a rolling update](/docs/tasks/manage-daemon/update-daemon-set/) on a DaemonSet. --> -您可以删除一个 DaemonSet。如果使用 `kubectl` 并指定 `--cascade=false` 选项，则 Pod 将被保留在节点上。然后可以创建具有不同模板的新 DaemonSet。具有不同模板的新 DaemonSet 将能够通过标签匹配并识别所有已经存在的 Pod。 -如果有任何 Pod 需要替换，则 DaemonSet 根据它的 `updateStrategy` 来替换。 +您可以删除一个 DaemonSet。如果使用 `kubectl` 并指定 `--cascade=false` 选项， +则 Pod 将被保留在节点上。接下来如果创建使用相同选择算符的新 DaemonSet， +新的 DaemonSet 会收养已有的 Pod。 +如果有 Pod 需要被替换，DaemonSet 会根据其 `updateStrategy` 来替换。 + +你可以对 DaemonSet [执行滚动更新](/zh/docs/tasks/manage-daemon/update-daemon-set/)操作。 <!-- ## Alternatives to DaemonSet ### Init Scripts --> -## DaemonSet 的可替代选择 +## DaemonSet 的替代方案 ### init 脚本 @@ -339,13 +379,16 @@ running such processes via a DaemonSet: containers. However, this can also be accomplished by running the daemons in a container but not in a Pod (e.g. start directly via Docker). --> -我们很可能希望直接在一个节点上启动 daemon 进程（例如，使用 `init`、`upstartd`、或 `systemd`）。这非常好，但基于 DaemonSet 来运行这些进程有如下一些好处： +直接在节点上启动守护进程（例如使用 `init`、`upstartd` 或 `systemd`）的做法当然是可行的。 +不过，基于 DaemonSet 来运行这些进程有如下一些好处： -- 像对待应用程序一样，具备为 daemon 提供监控和管理日志的能力。 +- 像所运行的其他应用一样，DaemonSet 具备为守护进程提供监控和日志管理的能力。 -- 为 daemon 和应用程序使用相同的配置语言和工具（如 Pod 模板、`kubectl`）。 +- 为守护进程和应用所使用的配置语言和工具（如 Pod 模板、`kubectl`）是相同的。 -- 在资源受限的容器中运行 daemon，能够增加 daemon 和应用容器的隔离性。然而，这也实现了在容器中运行 daemon，但却不能在 Pod 中运行（例如，直接基于 Docker 启动）。 +- 在资源受限的容器中运行守护进程能够增加守护进程和应用容器的隔离性。 + 然而，这一点也可以通过在容器中运行守护进程但却不在 Pod 中运行之来实现。 + 例如，直接基于 Docker 启动。 <!-- ### Bare Pods @@ -357,21 +400,27 @@ use a DaemonSet rather than creating individual Pods. --> ### 裸 Pod -可能要直接创建 Pod，同时指定其运行在特定的节点上。然而，DaemonSet 替换了由于任何原因被删除或终止的 Pod，例如节点失败、例行节点维护、内核升级。由于这个原因，我们应该使用 DaemonSet 而不是单独创建 Pod。 +直接创建 Pod并指定其运行在特定的节点上也是可以的。 +然而，DaemonSet 能够替换由于任何原因（例如节点失败、例行节点维护、内核升级） +而被删除或终止的 Pod。 +由于这个原因，你应该使用 DaemonSet 而不是单独创建 Pod。 <!-- ### Static Pods It is possible to create Pods by writing a file to a certain directory watched by Kubelet. These -are called [static pods](/docs/concepts/cluster-administration/static-pod/). +are called [static pods](/docs/tasks/configure-pod-container/static-pod/). Unlike DaemonSet, static Pods cannot be managed with kubectl or other Kubernetes API clients. Static Pods do not depend on the apiserver, making them useful in cluster bootstrapping cases. Also, static Pods may be deprecated in the future. --> ### 静态 Pod -可能需要通过在一个指定目录下编写文件来创建 Pod，该目录受 Kubelet 所监视。这些 Pod 被称为 [静态 Pod](/docs/concepts/cluster-administration/static-pod/)。 -不像 DaemonSet，静态 Pod 不受 kubectl 和其它 Kubernetes API 客户端管理。静态 Pod 不依赖于 apiserver，这使得它们在集群启动的情况下非常有用。而且，未来静态 Pod 可能会被废弃掉。 +通过在一个指定的、受 `kubelet` 监视的目录下编写文件来创建 Pod 也是可行的。 +这类 Pod 被称为[静态 Pod](/zh/docs/tasks/configure-pod-container/static-pod/)。 +不像 DaemonSet，静态 Pod 不受 `kubectl` 和其它 Kubernetes API 客户端管理。 +静态 Pod 不依赖于 API 服务器，这使得它们在启动引导新集群的情况下非常有用。 +此外，静态 Pod 在将来可能会被废弃。 <!-- ### Deployments @@ -387,8 +436,10 @@ all or certain hosts, and when it needs to start before other Pods. --> ### Deployments -DaemonSet 与 [Deployments](/docs/concepts/workloads/controllers/deployment/) 非常类似，它们都能创建 Pod，这些 Pod 对应的进程都不希望被终止掉（例如，Web 服务器、存储服务器）。 -为无状态的 Service 使用 Deployments，比如前端 Frontend 服务，实现对副本的数量进行扩缩容、平滑升级，比基于精确控制 Pod 运行在某个主机上要重要得多。 -需要 Pod 副本总是运行在全部或特定主机上，并需要先于其他 Pod 启动，当这被认为非常重要时，应该使用 Daemon Controller。 - +DaemonSet 与 [Deployments](/zh/docs/concepts/workloads/controllers/deployment/) 非常类似， +它们都能创建 Pod，并且 Pod 中的进程都不希望被终止（例如，Web 服务器、存储服务器）。 +建议为无状态的服务使用 Deployments，比如前端服务。 +对这些服务而言，对副本的数量进行扩缩容、平滑升级，比精确控制 Pod 运行在某个主机上要重要得多。 +当需要 Pod 副本总是运行在全部或特定主机上，并需要它们先于其他 Pod 启动时， +应该使用 DaemonSet。 diff --git a/content/zh/docs/concepts/workloads/controllers/deployment.md b/content/zh/docs/concepts/workloads/controllers/deployment.md index ffeb5c550a..007eaf9771 100644 --- a/content/zh/docs/concepts/workloads/controllers/deployment.md +++ b/content/zh/docs/concepts/workloads/controllers/deployment.md @@ -44,11 +44,6 @@ Do not manage ReplicaSets owned by a Deployment. Consider opening an issue in th <!-- body --> -You describe a _desired state_ in a Deployment, and the Deployment controller changes the actual state to the desired state at a controlled rate. You can define Deployments to create new ReplicaSets, or to remove existing Deployments and adopt all their resources with new Deployments. - ---> -描述 Deployment 中的 _desired state_，并且 Deployment 控制器以受控速率更改实际状态，以达到期望状态。可以定义 Deployments 以创建新的 ReplicaSets ，或删除现有 Deployments ，并通过新的 Deployments 使用其所有资源。 - <!-- ## Use Case @@ -109,7 +104,7 @@ The following are typical use cases for Deployments: * [Clean up older ReplicaSets](#clean-up-policy) that you don't need anymore. --> -* [清理较旧的 ReplicaSets ](#clean-up-policy) ，那些不在需要的。 +* [清理较旧的 ReplicaSets ](#clean-up-policy) ，那些不再需要的。 <!-- ## Creating a Deployment @@ -149,16 +144,16 @@ The following is an example of a Deployment. It creates a ReplicaSet to bring up * `selector` 字段定义 Deployment 如何查找要管理的 Pods。 在这种情况下，只需选择在 Pod 模板（`app: nginx`）中定义的标签。但是，更复杂的选择规则是可能的，只要 Pod 模板本身满足规则。 -{{< note >}} + {{< note >}} -<!-- - The `matchLabels` field is a map of {key,value} pairs. A single {key,value} in the `matchLabels` map + <!-- + The `matchLabels` field is a map of {key,value} pairs. A single {key,value} in the `matchLabels` map is equivalent to an element of `matchExpressions`, whose key field is "key" the operator is "In", and the values array contains only "value". All of the requirements, from both `matchLabels` and `matchExpressions`, must be satisfied in order to match. ---> + --> `matchLabels` 字段是 {key,value} 的映射。单个 {key,value}在 `matchLabels` 映射中的值等效于 `matchExpressions` 的元素，其键字段是“key”，运算符为“In”，值数组仅包含“value”。所有要求，从 `matchLabels` 和 `matchExpressions`，必须满足才能匹配。 -{{< /note >}} + {{< /note >}} <!-- * The `template` field contains the following sub-fields: @@ -170,43 +165,43 @@ The following is an example of a Deployment. It creates a ReplicaSet to bring up --> * Pod 标记为`app: nginx`，使用`labels`字段。 -<!-- - * The Pod template's specification, or `.template.spec` field, indicates that - the Pods run one container, `nginx`, which runs the `nginx` - [Docker Hub](https://hub.docker.com/) image at version 1.7.9. ---> + <!-- + * The Pod template's specification, or `.template.spec` field, indicates that + the Pods run one container, `nginx`, which runs the `nginx` + [Docker Hub](https://hub.docker.com/) image at version 1.7.9. + --> * Pod 模板规范或 `.template.spec` 字段指示 Pods 运行一个容器， `nginx`，运行 `nginx` [Docker Hub](https://hub.docker.com/)版本1.7.9的镜像 。 -<!-- - * Create one container and name it `nginx` using the `name` field. ---> + <!-- + * Create one container and name it `nginx` using the `name` field. + --> * 创建一个容器并使用`name`字段将其命名为 `nginx`。 <!-- Follow the steps given below to create the above Deployment: --> - 按照以下步骤创建上述 Deployment ： +按照以下步骤创建上述 Deployment ： <!-- Before you begin, make sure your Kubernetes cluster is up and running. --> - 开始之前，请确保的 Kubernetes 集群已启动并运行。 +开始之前，请确保的 Kubernetes 集群已启动并运行。 <!-- 1. Create the Deployment by running the following command: --> - 1. 通过运行以下命令创建 Deployment ： +1. 通过运行以下命令创建 Deployment ： -{{< note >}} -<!-- - You may specify the `--record` flag to write the command executed in the resource annotation `kubernetes.io/change-cause`. It is useful for future introspection. ---> + {{< note >}} + <!-- + You may specify the `--record` flag to write the command executed in the resource annotation `kubernetes.io/change-cause`. It is useful for future introspection. + --> 可以指定 `--record` 标志来写入在资源注释`kubernetes.io/change-cause`中执行的命令。它对以后的检查是有用的。 -<!-- - For example, to see the commands executed in each Deployment revision. ---> + <!-- + For example, to see the commands executed in each Deployment revision. + --> 例如，查看在每个 Deployment 修改中执行的命令。 -{{< /note >}} + {{< /note >}} ```shell kubectl apply -f https://k8s.io/examples/controllers/nginx-deployment.yaml @@ -215,42 +210,42 @@ The following is an example of a Deployment. It creates a ReplicaSet to bring up <!-- 2. Run `kubectl get deployments` to check if the Deployment was created. If the Deployment is still being created, the output is similar to the following: --> - 2. 运行 `kubectl get deployments` 以检查 Deployment 是否已创建。如果仍在创建 Deployment ，则输出以下内容： +2. 运行 `kubectl get deployments` 以检查 Deployment 是否已创建。如果仍在创建 Deployment ，则输出以下内容： ```shell NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE nginx-deployment 3 0 0 0 1s ``` -<!-- - When you inspect the Deployments in your cluster, the following fields are displayed: ---> + <!-- + When you inspect the Deployments in your cluster, the following fields are displayed: + --> 检查集群中的 Deployments 时，将显示以下字段： -<!-- - * `NAME` lists the names of the Deployments in the cluster. - * `DESIRED` displays the desired number of _replicas_ of the application, which you define when you create the Deployment. This is the _desired state_. - * `CURRENT` displays how many replicas are currently running. - * `UP-TO-DATE` displays the number of replicas that have been updated to achieve the desired state. - * `AVAILABLE` displays how many replicas of the application are available to your users. - * `AGE` displays the amount of time that the application has been running. ---> - * `NAME` 列出了集群中 Deployments 的名称。 - * `DESIRED` 显示应用程序的所需 _副本_ 数，在创建 Deployment 时定义这些副本。这是 _期望状态_。 - * `CURRENT`显示当前正在运行的副本数。 - * `UP-TO-DATE`显示已更新以实现期望状态的副本数。 - * `AVAILABLE`显示应用程序可供用户使用的副本数。 - * `AGE` 显示应用程序运行的时间量。 + <!-- + * `NAME` lists the names of the Deployments in the cluster. + * `DESIRED` displays the desired number of _replicas_ of the application, which you define when you create the Deployment. This is the _desired state_. + * `CURRENT` displays how many replicas are currently running. + * `UP-TO-DATE` displays the number of replicas that have been updated to achieve the desired state. + * `AVAILABLE` displays how many replicas of the application are available to your users. + * `AGE` displays the amount of time that the application has been running. + --> + * `NAME` 列出了集群中 Deployments 的名称。 + * `DESIRED` 显示应用程序的所需 _副本_ 数，在创建 Deployment 时定义这些副本。这是 _期望状态_。 + * `CURRENT`显示当前正在运行的副本数。 + * `UP-TO-DATE`显示已更新以实现期望状态的副本数。 + * `AVAILABLE`显示应用程序可供用户使用的副本数。 + * `AGE` 显示应用程序运行的时间量。 -<!-- - Notice how the number of desired replicas is 3 according to `.spec.replicas` field. ---> + <!-- + Notice how the number of desired replicas is 3 according to `.spec.replicas` field. + --> 请注意，根据`.spec.replicas`副本字段，所需副本的数量为 3。 <!-- 3. To see the Deployment rollout status, run `kubectl rollout status deployment.v1.apps/nginx-deployment`. The output is similar to this: --> - 3. 要查看 Deployment 展开状态，运行 `kubectl rollout status deployment.v1.apps/nginx-deployment`。输出： +3. 要查看 Deployment 展开状态，运行 `kubectl rollout status deployment.v1.apps/nginx-deployment`。输出： ```shell Waiting for rollout to finish: 2 out of 3 new replicas have been updated... @@ -260,36 +255,36 @@ The following is an example of a Deployment. It creates a ReplicaSet to bring up <!-- 4. Run the `kubectl get deployments` again a few seconds later. The output is similar to this: --> - 4. 几秒钟后再次运行 `kubectl get deployments`。输出： +4. 几秒钟后再次运行 `kubectl get deployments`。输出： ```shell NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE nginx-deployment 3 3 3 3 18s ``` -<!-- - Notice that the Deployment has created all three replicas, and all replicas are up-to-date (they contain the latest Pod template) and available. ---> + <!-- + Notice that the Deployment has created all three replicas, and all replicas are up-to-date (they contain the latest Pod template) and available. + --> 请注意， Deployment 已创建所有三个副本，并且所有副本都是最新的（它们包含最新的 Pod 模板）并且可用。 <!-- 5. To see the ReplicaSet (`rs`) created by the Deployment, run `kubectl get rs`. The output is similar to this: --> - 5. 要查看 Deployment 创建的 ReplicaSet （`rs`），运行 `kubectl get rs`。输出： +5. 要查看 Deployment 创建的 ReplicaSet （`rs`），运行 `kubectl get rs`。输出： ```shell NAME DESIRED CURRENT READY AGE nginx-deployment-75675f5897 3 3 3 18s ``` -<!-- - Notice that the name of the ReplicaSet is always formatted as `[DEPLOYMENT-NAME]-[RANDOM-STRING]`. The random string is - randomly generated and uses the pod-template-hash as a seed. ---> + <!-- + Notice that the name of the ReplicaSet is always formatted as `[DEPLOYMENT-NAME]-[RANDOM-STRING]`. The random string is + randomly generated and uses the pod-template-hash as a seed. + --> 请注意， ReplicaSet 的名称始终被格式化为`[DEPLOYMENT-NAME]-[RANDOM-STRING]`。随机字符串是随机生成并使用 pod-template-hash 作为种子。 <!-- 6. To see the labels automatically generated for each Pod, run `kubectl get pods --show-labels`. The following output is returned: --> - 6. 要查看每个 Pod 自动生成的标签，运行 `kubectl get pods --show-labels`。返回以下输出： +6. 要查看每个 Pod 自动生成的标签，运行 `kubectl get pods --show-labels`。返回以下输出： ```shell NAME READY STATUS RESTARTS AGE LABELS @@ -298,9 +293,9 @@ The following is an example of a Deployment. It creates a ReplicaSet to bring up nginx-deployment-75675f5897-qqcnn 1/1 Running 0 18s app=nginx,pod-template-hash=3123191453 ``` -<!-- - The created ReplicaSet ensures that there are three `nginx` Pods. ---> + <!-- + The created ReplicaSet ensures that there are three `nginx` Pods. + --> 创建的复制集可确保有三个 `nginx` Pods。 {{< note >}} @@ -355,33 +350,33 @@ is changed, for example if the labels or container images of the template are up <!-- 1. Let's update the nginx Pods to use the `nginx:1.9.1` image instead of the `nginx:1.7.9` image. --> - 1. 让我们更新 nginx Pods，以使用 `nginx:1.9.1` 镜像 ，而不是 `nginx:1.7.9` 镜像 。 +1. 让我们更新 nginx Pods，以使用 `nginx:1.9.1` 镜像 ，而不是 `nginx:1.7.9` 镜像 。 ```shell kubectl --record deployment.apps/nginx-deployment set image deployment.v1.apps/nginx-deployment nginx=nginx:1.9.1 ``` -<!-- - The output is similar to this: ---> + <!-- + The output is similar to this: + --> 输出： ```shell deployment.apps/nginx-deployment image updated ``` -<!-- - Alternatively, you can `edit` the Deployment and change `.spec.template.spec.containers[0].image` from `nginx:1.7.9` to `nginx:1.9.1`: ---> + <!-- + Alternatively, you can `edit` the Deployment and change `.spec.template.spec.containers[0].image` from `nginx:1.7.9` to `nginx:1.9.1`: + --> 或者，可以 `edit` Deployment 并将 `.spec.template.spec.containers[0].image` 从 `nginx:1.7.9` 更改至 `nginx:1.9.1`。 ```shell kubectl edit deployment.v1.apps/nginx-deployment ``` -<!-- - The output is similar to this: ---> + <!-- + The output is similar to this: + --> 输出： @@ -392,23 +387,23 @@ is changed, for example if the labels or container images of the template are up <!-- 2. To see the rollout status, run: --> - 2. 要查看展开状态，运行： +2. 要查看展开状态，运行： ```shell kubectl rollout status deployment.v1.apps/nginx-deployment ``` -<!-- - The output is similar to this: ---> + <!-- + The output is similar to this: + --> 输出： ```shell Waiting for rollout to finish: 2 out of 3 new replicas have been updated... ``` -<!-- - or ---> + <!-- + or + --> 或者 ```shell @@ -442,9 +437,9 @@ up to 3 replicas, as well as scaling down the old ReplicaSet to 0 replicas. kubectl get rs ``` -<!-- - The output is similar to this: ---> + <!-- + The output is similar to this: + --> 输出： ```shell @@ -462,10 +457,10 @@ up to 3 replicas, as well as scaling down the old ReplicaSet to 0 replicas. kubectl get pods ``` -<!-- - The output is similar to this: ---> -输出： + <!-- + The output is similar to this: + --> + 输出： ```shell NAME READY STATUS RESTARTS AGE @@ -474,29 +469,29 @@ up to 3 replicas, as well as scaling down the old ReplicaSet to 0 replicas. nginx-deployment-1564180365-z9gth 1/1 Running 0 14s ``` -<!-- - Next time you want to update these Pods, you only need to update the Deployment's Pod template again. ---> + <!-- + Next time you want to update these Pods, you only need to update the Deployment's Pod template again. + --> 下次要更新这些 Pods 时，只需再次更新 Deployment Pod 模板。 -<!-- - Deployment ensures that only a certain number of Pods are down while they are being updated. By default, - it ensures that at least 75% of the desired number of Pods are up (25% max unavailable). ---> + <!-- + Deployment ensures that only a certain number of Pods are down while they are being updated. By default, + it ensures that at least 75% of the desired number of Pods are up (25% max unavailable). + --> Deployment 可确保在更新时仅关闭一定数量的 Pods。默认情况下，它确保至少 75%所需 Pods 运行（25%最大不可用）。 -<!-- - Deployment also ensures that only a certain number of Pods are created above the desired number of Pods. - By default, it ensures that at most 25% of the desired number of Pods are up (25% max surge). ---> + <!-- + Deployment also ensures that only a certain number of Pods are created above the desired number of Pods. + By default, it ensures that at most 25% of the desired number of Pods are up (25% max surge). + --> Deployment 还确保仅创建一定数量的 Pods 高于期望的 Pods 数。默认情况下，它可确保最多增加 25% 期望 Pods 数（25%最大增量）。 - <!-- - For example, if you look at the above Deployment closely, you will see that it first created a new Pod, - then deleted some old Pods, and created new ones. It does not kill old Pods until a sufficient number of - new Pods have come up, and does not create new Pods until a sufficient number of old Pods have been killed. - It makes sure that at least 2 Pods are available and that at max 4 Pods in total are available. ---> + <!-- + For example, if you look at the above Deployment closely, you will see that it first created a new Pod, + then deleted some old Pods, and created new ones. It does not kill old Pods until a sufficient number of + new Pods have come up, and does not create new Pods until a sufficient number of old Pods have been killed. + It makes sure that at least 2 Pods are available and that at max 4 Pods in total are available. + --> 例如，如果仔细查看上述 Deployment ，将看到它首先创建了一个新的 Pod，然后删除了一些旧的 Pods，并创建了新的 Pods。它不会杀死老 Pods，直到有足够的数量新的 Pods 已经出现，并没有创造新的 Pods，直到足够数量的旧 Pods 被杀死。它确保至少 2 个 Pods 可用，并且总共最多 4 个 Pods 可用。 <!-- @@ -506,9 +501,9 @@ up to 3 replicas, as well as scaling down the old ReplicaSet to 0 replicas. ```shell kubectl describe deployments ``` -<!-- - The output is similar to this: ---> + <!-- + The output is similar to this: + --> 输出： ```shell @@ -550,14 +545,14 @@ up to 3 replicas, as well as scaling down the old ReplicaSet to 0 replicas. Normal ScalingReplicaSet 14s deployment-controller Scaled down replica set nginx-deployment-2035384211 to 0 ``` -<!-- - Here you see that when you first created the Deployment, it created a ReplicaSet (nginx-deployment-2035384211) - and scaled it up to 3 replicas directly. When you updated the Deployment, it created a new ReplicaSet - (nginx-deployment-1564180365) and scaled it up to 1 and then scaled down the old ReplicaSet to 2, so that at - least 2 Pods were available and at most 4 Pods were created at all times. It then continued scaling up and down - the new and the old ReplicaSet, with the same rolling update strategy. Finally, you'll have 3 available replicas - in the new ReplicaSet, and the old ReplicaSet is scaled down to 0. ---> + <!-- + Here you see that when you first created the Deployment, it created a ReplicaSet (nginx-deployment-2035384211) + and scaled it up to 3 replicas directly. When you updated the Deployment, it created a new ReplicaSet + (nginx-deployment-1564180365) and scaled it up to 1 and then scaled down the old ReplicaSet to 2, so that at + least 2 Pods were available and at most 4 Pods were created at all times. It then continued scaling up and down + the new and the old ReplicaSet, with the same rolling update strategy. Finally, you'll have 3 available replicas + in the new ReplicaSet, and the old ReplicaSet is scaled down to 0. + --> 可以看到，当第一次创建 Deployment 时，它创建了一个 ReplicaSet （nginx-deployment-2035384211）并将其直接扩展至 3 个副本。更新 Deployment 时，它创建了一个新的 ReplicaSet （nginx-deployment-1564180365），并将其扩展为 1，然后将旧 ReplicaSet 缩小到 2，以便至少有 2 个 Pod 可用，并且最多创建 4 个 Pod。然后，它继续向上和向下扩展新的和旧的 ReplicaSet ，具有相同的滚动更新策略。最后，将有 3 个可用的副本在新的 ReplicaSet 中，旧 ReplicaSet 将缩小到 0。 <!-- @@ -655,9 +650,9 @@ rolled back. kubectl set image deployment.v1.apps/nginx-deployment nginx=nginx:1.91 --record=true ``` -<!-- - The output is similar to this: ---> + <!-- + The output is similar to this: + --> 输出： ```shell @@ -673,9 +668,9 @@ rolled back. kubectl rollout status deployment.v1.apps/nginx-deployment ``` -<!-- - The output is similar to this: ---> + <!-- + The output is similar to this: + --> 输出： ```shell @@ -699,9 +694,9 @@ rolled back. kubectl get rs ``` -<!-- - The output is similar to this: ---> + <!-- + The output is similar to this: + --> 输出： ```shell @@ -720,9 +715,9 @@ rolled back. kubectl get pods ``` -<!-- - The output is similar to this: ---> + <!-- + The output is similar to this: + --> 输出： ```shell @@ -733,14 +728,14 @@ rolled back. nginx-deployment-3066724191-08mng 0/1 ImagePullBackOff 0 6s ``` -{{< note >}} -<!-- - The Deployment controller stops the bad rollout automatically, and stops scaling up the new - ReplicaSet. This depends on the rollingUpdate parameters (`maxUnavailable` specifically) that you have specified. - Kubernetes by default sets the value to 25%. ---> - Deployment 控制器自动停止不良展开，并停止向上扩展新的 ReplicaSet 。这取决于指定的滚动更新参数（具体为 `maxUnavailable`）。默认情况下，Kubernetes 将值设置为 25%。 -{{< /note >}} + {{< note >}} + <!-- + The Deployment controller stops the bad rollout automatically, and stops scaling up the new + ReplicaSet. This depends on the rollingUpdate parameters (`maxUnavailable` specifically) that you have specified. + Kubernetes by default sets the value to 25%. + --> + Deployment 控制器自动停止不良展开，并停止向上扩展新的 ReplicaSet 。这取决于指定的滚动更新参数（具体为 `maxUnavailable`）。默认情况下，Kubernetes 将值设置为 25%。 + {{< /note >}} <!-- * Get the description of the Deployment: @@ -750,9 +745,9 @@ rolled back. kubectl describe deployment ``` -<!-- - The output is similar to this: ---> + <!-- + The output is similar to this: + --> 输出： ```shell @@ -795,10 +790,10 @@ rolled back. 13s 13s 1 {deployment-controller } Normal ScalingReplicaSet Scaled up replica set nginx-deployment-3066724191 to 1 ``` -<!-- - To fix this, you need to rollback to a previous revision of Deployment that is stable. ---> - 要解决此问题，需要回滚到以前稳定的 Deployment 版本。 + <!-- + To fix this, you need to rollback to a previous revision of Deployment that is stable. + --> + 要解决此问题，需要回滚到以前稳定的 Deployment 版本。 <!-- ### Checking Rollout History of a Deployment @@ -813,14 +808,14 @@ rolled back. <!-- 1. First, check the revisions of this Deployment: --> - 1. 首先，检查 Deployment 修改历史： +1. 首先，检查 Deployment 修改历史： ```shell kubectl rollout history deployment.v1.apps/nginx-deployment ``` -<!-- - The output is similar to this: ---> + <!-- + The output is similar to this: + --> 输出： ```shell @@ -831,16 +826,16 @@ rolled back. 3 kubectl set image deployment.v1.apps/nginx-deployment nginx=nginx:1.91 --record=true ``` -<!-- - `CHANGE-CAUSE` is copied from the Deployment annotation `kubernetes.io/change-cause` to its revisions upon creation. You can specify the`CHANGE-CAUSE` message by: ---> + <!-- + `CHANGE-CAUSE` is copied from the Deployment annotation `kubernetes.io/change-cause` to its revisions upon creation. You can specify the`CHANGE-CAUSE` message by: + --> `CHANGE-CAUSE` 从 Deployment 注释 `kubernetes.io/change-cause` 创建时复制到其修改版。可以通过以下条件指定 `CHANGE-CAUSE` 消息： -<!-- - * Annotating the Deployment with `kubectl annotate deployment.v1.apps/nginx-deployment kubernetes.io/change-cause="image updated to 1.9.1"` - * Append the `--record` flag to save the `kubectl` command that is making changes to the resource. - * Manually editing the manifest of the resource. ---> + <!-- + * Annotating the Deployment with `kubectl annotate deployment.v1.apps/nginx-deployment kubernetes.io/change-cause="image updated to 1.9.1"` + * Append the `--record` flag to save the `kubectl` command that is making changes to the resource. + * Manually editing the manifest of the resource. + --> * 使用 `kubectl annotate deployment.v1.apps/nginx-deployment kubernetes.io/change-cause="image updated to 1.9.1"` Deployment 对 Deployment 进行分号。 * 追加 `--record` 以保存正在更改资源的 `kubectl` 命令。 * 手动编辑资源的清单。 @@ -848,15 +843,15 @@ rolled back. <!-- 2. To see the details of each revision, run: --> - 2. 查看修改历史的详细信息，运行： +2. 查看修改历史的详细信息，运行： ```shell kubectl rollout history deployment.v1.apps/nginx-deployment --revision=2 ``` -<!-- - The output is similar to this: ---> + <!-- + The output is similar to this: + --> 输出： ```shell @@ -886,61 +881,61 @@ Follow the steps given below to rollback the Deployment from the current version <!-- 1. Now you've decided to undo the current rollout and rollback to the previous revision: --> - 1. 现在已决定撤消当前展开并回滚到以前的版本： +1. 现在已决定撤消当前展开并回滚到以前的版本： ```shell kubectl rollout undo deployment.v1.apps/nginx-deployment ``` -<!-- - The output is similar to this: ---> + <!-- + The output is similar to this: + --> 输出： ```shell deployment.apps/nginx-deployment ``` -<!-- - Alternatively, you can rollback to a specific revision by specifying it with `--to-revision`: ---> + <!-- + Alternatively, you can rollback to a specific revision by specifying it with `--to-revision`: + --> 或者，可以通过使用 `--to-revision` 来回滚到特定修改版本： ```shell kubectl rollout undo deployment.v1.apps/nginx-deployment --to-revision=2 ``` -<!-- - The output is similar to this: ---> + <!-- + The output is similar to this: + --> 输出： ```shell deployment.apps/nginx-deployment ``` -<!-- - For more details about rollout related commands, read [`kubectl rollout`](/docs/reference/generated/kubectl/kubectl-commands#rollout). ---> + <!-- + For more details about rollout related commands, read [`kubectl rollout`](/docs/reference/generated/kubectl/kubectl-commands#rollout). + --> 更多有关回滚相关指令，请参考 [`kubectl rollout`](/docs/reference/generated/kubectl/kubectl-commands#rollout). -<!-- - The Deployment is now rolled back to a previous stable revision. As you can see, a `DeploymentRollback` event - for rolling back to revision 2 is generated from Deployment controller. ---> + <!-- + The Deployment is now rolled back to a previous stable revision. As you can see, a `DeploymentRollback` event + for rolling back to revision 2 is generated from Deployment controller. + --> 现在， Deployment 将回滚到以前的稳定版本。如所见， Deployment 回滚事件回滚到修改版 2 是从 Deployment 控制器生成的。 <!-- 2. Check if the rollback was successful and the Deployment is running as expected, run: --> - 2. 检查回滚是否成功、 Deployment 是否正在运行，运行： +2. 检查回滚是否成功、 Deployment 是否正在运行，运行： ```shell kubectl get deployment nginx-deployment ``` -<!-- - The output is similar to this: ---> + <!-- + The output is similar to this: + --> 输出： ```shell @@ -951,15 +946,15 @@ Follow the steps given below to rollback the Deployment from the current version <!-- 3. Get the description of the Deployment: --> - 3. 获取 Deployment 描述信息： +3. 获取 Deployment 描述信息： ```shell kubectl describe deployment nginx-deployment ``` -<!-- - The output is similar to this: ---> + <!-- + The output is similar to this: + --> 输出： ```shell @@ -1077,9 +1072,9 @@ ReplicaSets (ReplicaSets with Pods) in order to mitigate risk. This is called *p kubectl get deploy ``` -<!-- - The output is similar to this: ---> + <!-- + The output is similar to this: + --> 输出： ```shell @@ -1095,9 +1090,9 @@ ReplicaSets (ReplicaSets with Pods) in order to mitigate risk. This is called *p kubectl set image deployment.v1.apps/nginx-deployment nginx=nginx:sometag ``` -<!-- - The output is similar to this: ---> + <!-- + The output is similar to this: + --> 输出： ```shell @@ -1112,9 +1107,9 @@ ReplicaSets (ReplicaSets with Pods) in order to mitigate risk. This is called *p ```shell kubectl get rs ``` -<!-- - The output is similar to this: ---> + <!-- + The output is similar to this: + --> 输出： ```shell @@ -1195,9 +1190,9 @@ apply multiple fixes in between pausing and resuming without triggering unnecess ```shell kubectl get deploy ``` -<!-- - The output is similar to this: ---> + <!-- + The output is similar to this: + --> 输出： ```shell @@ -1205,18 +1200,17 @@ apply multiple fixes in between pausing and resuming without triggering unnecess nginx 3 3 3 3 1m ``` -<!-- - Get the rollout status: ---> + <!-- + Get the rollout status: + --> 获取 Deployment 状态： ```shell kubectl get rs ``` - -<!-- - The output is similar to this: ---> + <!-- + The output is similar to this: + --> 输出： ```shell @@ -1224,18 +1218,18 @@ apply multiple fixes in between pausing and resuming without triggering unnecess nginx-2142116321 3 3 3 1m ``` -<!-- - * Pause by running the following command: ---> -使用如下指令中断运行： + <!-- + * Pause by running the following command: + --> + 使用如下指令中断运行： ```shell kubectl rollout pause deployment.v1.apps/nginx-deployment ``` -<!-- - The output is similar to this: ---> + <!-- + The output is similar to this: + --> 输出： ```shell @@ -1251,9 +1245,9 @@ apply multiple fixes in between pausing and resuming without triggering unnecess kubectl set image deployment.v1.apps/nginx-deployment nginx=nginx:1.9.1 ``` -<!-- - The output is similar to this: ---> + <!-- + The output is similar to this: + --> 输出： ```shell @@ -1269,9 +1263,9 @@ apply multiple fixes in between pausing and resuming without triggering unnecess kubectl rollout history deployment.v1.apps/nginx-deployment ``` -<!-- - The output is similar to this: ---> + <!-- + The output is similar to this: + --> 输出： ```shell @@ -1289,9 +1283,9 @@ apply multiple fixes in between pausing and resuming without triggering unnecess kubectl get rs ``` -<!-- - The output is similar to this: ---> + <!-- + The output is similar to this: + --> 输出： ```shell @@ -1308,19 +1302,19 @@ apply multiple fixes in between pausing and resuming without triggering unnecess kubectl set resources deployment.v1.apps/nginx-deployment -c=nginx --limits=cpu=200m,memory=512Mi ``` -<!-- - The output is similar to this: ---> + <!-- + The output is similar to this: + --> 输出： ```shell deployment.apps/nginx-deployment resource requirements updated ``` -<!-- - The initial state of the Deployment prior to pausing it will continue its function, but new updates to - the Deployment will not have any effect as long as the Deployment is paused. ---> + <!-- + The initial state of the Deployment prior to pausing it will continue its function, but new updates to + the Deployment will not have any effect as long as the Deployment is paused. + --> 暂停 Deployment 之前的初始状态将继续其功能，但新的更新只要暂停 Deployment ， Deployment 就不会产生任何效果。 <!-- @@ -1332,9 +1326,9 @@ apply multiple fixes in between pausing and resuming without triggering unnecess kubectl rollout resume deployment.v1.apps/nginx-deployment ``` -<!-- - The output is similar to this: ---> + <!-- + The output is similar to this: + --> 输出： ```shell @@ -1349,9 +1343,9 @@ apply multiple fixes in between pausing and resuming without triggering unnecess kubectl get rs -w ``` -<!-- - The output is similar to this: ---> + <!-- + The output is similar to this: + --> 输出： ```shell @@ -1381,9 +1375,9 @@ apply multiple fixes in between pausing and resuming without triggering unnecess kubectl get rs ``` -<!-- - The output is similar to this: ---> + <!-- + The output is similar to this: + --> 输出： ```shell @@ -1392,198 +1386,6 @@ apply multiple fixes in between pausing and resuming without triggering unnecess nginx-3926361531 3 3 3 28s ``` -<!-- - You can pause a Deployment before triggering one or more updates and then resume it. This allows you to -apply multiple fixes in between pausing and resuming without triggering unnecessary rollouts. ---> -可以在触发一个或多个更新之前暂停 Deployment ，然后继续它。这允许在暂停和恢复之间应用多个修补程序，而不会触发不必要的 Deployment 。 - -<!-- - * For example, with a Deployment that was just created: - Get the Deployment details: ---> -* 例如，对于一个刚刚创建的 Deployment ： - 获取 Deployment 信息： - ```shell - kubectl get deploy - ``` -<!-- - The output is similar to this: ---> - 输出： - ``` - NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE - nginx 3 3 3 3 1m - ``` - -<!-- - Get the rollout status: ---> - 获取 Deployment 状态： - ```shell - kubectl get rs - ``` - -<!-- - The output is similar to this: ---> - 输出： - ``` - NAME DESIRED CURRENT READY AGE - nginx-2142116321 3 3 3 1m - ``` - -<!-- - * Pause by running the following command: ---> -使用如下指令中断运行： - ```shell - kubectl rollout pause deployment.v1.apps/nginx-deployment - ``` - -<!-- - The output is similar to this: ---> - 输出： - ``` - deployment.apps/nginx-deployment paused - ``` - -<!-- - * Then update the image of the Deployment: ---> -* 然后更新 Deployment 镜像： - ```shell - kubectl set image deployment.v1.apps/nginx-deployment nginx=nginx:1.9.1 - ``` - -<!-- - The output is similar to this: ---> - 输出： - ``` - deployment.apps/nginx-deployment image updated - ``` - -<!-- - * Notice that no new rollout started: ---> -* 注意没有新的展开： - ```shell - kubectl rollout history deployment.v1.apps/nginx-deployment - ``` - -<!-- - The output is similar to this: ---> - 输出： - ``` - deployments "nginx" - REVISION CHANGE-CAUSE - 1 <none> - ``` - -<!-- - * Get the rollout status to ensure that the Deployment is updates successfully: ---> -* 获取展开状态确保 Deployment 更新已经成功： - ```shell - kubectl get rs - ``` - -<!-- - The output is similar to this: ---> - 输出： - ``` - NAME DESIRED CURRENT READY AGE - nginx-2142116321 3 3 3 2m - ``` - -<!-- - * You can make as many updates as you wish, for example, update the resources that will be used: ---> -* 更新是很容易的，例如，可以这样更新使用到的资源： - ```shell - kubectl set resources deployment.v1.apps/nginx-deployment -c=nginx --limits=cpu=200m,memory=512Mi - ``` - -<!-- - The output is similar to this: ---> - 输出： - ``` - deployment.apps/nginx-deployment resource requirements updated - ``` - -<!-- - The initial state of the Deployment prior to pausing it will continue its function, but new updates to - the Deployment will not have any effect as long as the Deployment is paused. ---> - 暂停 Deployment 之前的初始状态将继续其功能，但新的更新只要暂停 Deployment ， Deployment 就不会产生任何效果。 - -<!-- - * Eventually, resume the Deployment and observe a new ReplicaSet coming up with all the new updates: ---> -* 最后，恢复 Deployment 并观察新的 ReplicaSet ，并更新所有新的更新： - ```shell - kubectl rollout resume deployment.v1.apps/nginx-deployment - ``` - -<!-- - The output is similar to this: ---> - 输出： - ``` - deployment.apps/nginx-deployment resumed - ``` -<!-- - * Watch the status of the rollout until it's done. ---> -* 观察展开的状态，直到完成。 - ```shell - kubectl get rs -w - ``` - -<!-- - The output is similar to this: ---> - 输出： - ``` - NAME DESIRED CURRENT READY AGE - nginx-2142116321 2 2 2 2m - nginx-3926361531 2 2 0 6s - nginx-3926361531 2 2 1 18s - nginx-2142116321 1 2 2 2m - nginx-2142116321 1 2 2 2m - nginx-3926361531 3 2 1 18s - nginx-3926361531 3 2 1 18s - nginx-2142116321 1 1 1 2m - nginx-3926361531 3 3 1 18s - nginx-3926361531 3 3 2 19s - nginx-2142116321 0 1 1 2m - nginx-2142116321 0 1 1 2m - nginx-2142116321 0 0 0 2m - nginx-3926361531 3 3 3 20s - ``` - -<!-- - * Get the status of the latest rollout: ---> -* 获取最近展开的状态： - ```shell - kubectl get rs - ``` - -<!-- - The output is similar to this: ---> - 输出： - ``` - NAME DESIRED CURRENT READY AGE - nginx-2142116321 0 0 0 2m - nginx-3926361531 3 3 3 28s - ``` {{< note >}} <!-- You cannot rollback a paused Deployment until you resume it. diff --git a/content/zh/docs/concepts/workloads/controllers/garbage-collection.md b/content/zh/docs/concepts/workloads/controllers/garbage-collection.md index 7e7802999e..0c34eda433 100644 --- a/content/zh/docs/concepts/workloads/controllers/garbage-collection.md +++ b/content/zh/docs/concepts/workloads/controllers/garbage-collection.md @@ -1,15 +1,13 @@ --- title: 垃圾收集 content_type: concept -weight: 60 +weight: 70 --- <!-- ---- title: Garbage Collection content_type: concept -weight: 60 ---- +weight: 70 --> <!-- overview --> @@ -18,11 +16,7 @@ weight: 60 The role of the Kubernetes garbage collector is to delete certain objects that once had an owner, but no longer have an owner. --> - -Kubernetes 垃圾收集器的作用是删除某些曾经拥有所有者（owner）但现在不再拥有所有者的对象。 - - - +Kubernetes 垃圾收集器的作用是删除某些曾经拥有属主（Owner）但现在不再拥有属主的对象。 <!-- body --> @@ -41,24 +35,29 @@ automatically sets the value of `ownerReference` for objects created or adopted by ReplicationController, ReplicaSet, StatefulSet, DaemonSet, Deployment, Job and CronJob. +--> +## 属主和附属 {#owners-and-dependents} + +某些 Kubernetes 对象是其它一些对象的属主。 +例如，一个 ReplicaSet 是一组 Pod 的属主。 +具有属主的对象被称为是属主的 *附属* 。 +每个附属对象具有一个指向其所属对象的 `metadata.ownerReferences` 字段。 + +有时，Kubernetes 会自动设置 `ownerReference` 的值。 +例如，当创建一个 ReplicaSet 时，Kubernetes 自动设置 ReplicaSet 中每个 Pod 的 `ownerReference` 字段值。 +在 Kubernetes 1.8 版本，Kubernetes 会自动为某些对象设置 `ownerReference` 的值。 +这些对象是由 ReplicationController、ReplicaSet、StatefulSet、DaemonSet、Deployment、 +Job 和 CronJob 所创建或管理的。 + +<!-- You can also specify relationships between owners and dependents by manually setting the `ownerReference` field. Here's a configuration file for a ReplicaSet that has three Pods: --> +你也可以通过手动设置 `ownerReference` 的值，来指定属主和附属之间的关系。 -## 所有者和附属 - -某些 Kubernetes 对象是其它一些对象的所有者。例如，一个 ReplicaSet 是一组 Pod 的所有者。 -具有所有者的对象被称为是所有者的 *附属* 。 -每个附属对象具有一个指向其所属对象的 `metadata.ownerReferences` 字段。 - -有时，Kubernetes 会自动设置 `ownerReference` 的值。 -例如，当创建一个 ReplicaSet 时，Kubernetes 自动设置 ReplicaSet 中每个 Pod 的 `ownerReference` 字段值。 -在 Kubernetes 1.8 版本，Kubernetes 会自动为某些对象设置 `ownerReference` 的值，这些对象是由 ReplicationController、ReplicaSet、StatefulSet、DaemonSet、Deployment、Job 和 CronJob 所创建或管理。 -也可以通过手动设置 `ownerReference` 的值，来指定所有者和附属之间的关系。 - -这里有一个配置文件，表示一个具有 3 个 Pod 的 ReplicaSet： +下面的配置文件中包含一个具有 3 个 Pod 的 ReplicaSet： {{< codenew file="controllers/replicaset.yaml" >}} @@ -66,8 +65,7 @@ Here's a configuration file for a ReplicaSet that has three Pods: If you create the ReplicaSet and then view the Pod metadata, you can see OwnerReferences field: --> - -如果创建该 ReplicaSet，然后查看 Pod 的 metadata 字段，能够看到 OwnerReferences 字段： +如果你创建该 ReplicaSet，然后查看 Pod 的 metadata 字段，能够看到 OwnerReferences 字段： ```shell kubectl apply -f https://k8s.io/examples/controllers/replicaset.yaml @@ -77,8 +75,7 @@ kubectl get pods --output=yaml <!-- The output shows that the Pod owner is a ReplicaSet named `my-repset`: --> - -输出显示了 Pod 的所有者是名为 my-repset 的 ReplicaSet： +输出显示了 Pod 的属主是名为 my-repset 的 ReplicaSet： ```yaml apiVersion: v1 @@ -103,9 +100,9 @@ and owners that are cluster-scoped. namespace-scoped owners. --> {{< note >}} -根据设计，kubernetes 不允许跨命名空间指定所有者。这意味着： -1）命名空间范围的附属只能在相同的命名空间中指定所有者，并且只能指定集群范围的所有者。 -2）集群范围的附属只能指定集群范围的所有者，不能指定命名空间范围的。 +根据设计，kubernetes 不允许跨命名空间指定属主。这意味着： +1）命名空间范围的附属只能指定同一的命名空间中的或者集群范围的属主。 +2）集群范围的附属只能指定集群范围的属主，不能指定命名空间范围的属主。 {{< /note >}} <!-- @@ -119,21 +116,17 @@ If you delete an object without deleting its dependents automatically, the dependents are said to be *orphaned*. --> -## 控制垃圾收集器删除附属者 +## 控制垃圾收集器删除附属 -当删除对象时，可以指定该对象的附属者是否也自动删除掉。 -自动删除 Dependent 也称为 *级联删除* 。 -Kubernetes 中有两种 *级联删除* 的模式：*background* 模式和 *foreground* 模式。 - -如果删除对象时，不自动删除它的附属者，这些附属者被称作是原对象的 *orphaned* 。 +当你删除对象时，可以指定该对象的附属是否也自动删除。 +自动删除附属的行为也称为 *级联删除（Cascading Deletion）* 。 +Kubernetes 中有两种 *级联删除* 模式：*后台（Background）* 模式和 *前台（Foreground）* 模式。 +如果删除对象时，不自动删除它的附属，这些附属被称作 *孤立对象（Orphaned）* 。 <!-- ### Foreground cascading deletion ---> -### 显式级联删除 -<!-- In *foreground cascading deletion*, the root object first enters a "deletion in progress" state. In the "deletion in progress" state, the following things are true: @@ -142,11 +135,14 @@ the following things are true: * The object's `deletionTimestamp` is set * The object's `metadata.finalizers` contains the value "foregroundDeletion". --> -在 *显式级联删除* 模式下，根对象首先进入 `deletion in progress` 状态。在 `deletion in progress` 状态会有如下的情况： +### 前台级联删除 + +在 *前台级联删除* 模式下，根对象首先进入 `deletion in progress` 状态。 +在 `deletion in progress` 状态，会有如下的情况： * 对象仍然可以通过 REST API 可见。 - * 会设置对象的 `deletionTimestamp` 字段。 - * 对象的 `metadata.finalizers` 字段包含了值 `foregroundDeletion`。 + * 对象的 `deletionTimestamp` 字段被设置。 + * 对象的 `metadata.finalizers` 字段包含值 `foregroundDeletion`。 <!-- Once the "deletion in progress" state is set, the garbage @@ -155,7 +151,8 @@ collector deletes the object's dependents. Once the garbage collector has delete the owner object. --> 一旦对象被设置为 `deletion in progress` 状态，垃圾收集器会删除对象的所有附属。 -垃圾收集器在删除了所有 `Blocking` 状态的附属（对象的 `ownerReference.blockOwnerDeletion=true`）之后，它会删除拥有者对象。 +垃圾收集器在删除了所有有阻塞能力的附属（对象的 `ownerReference.blockOwnerDeletion=true`） +之后，删除属主对象。 <!-- Note that in the "foregroundDeletion", only dependents with @@ -167,11 +164,15 @@ unauthorized dependents cannot delay deletion of an owner object. If an object's `ownerReferences` field is set by a controller (such as Deployment or ReplicaSet), blockOwnerDeletion is set automatically and you do not need to manually modify this field. --> -注意，在 `foregroundDeletion` 模式下，只有设置了 `ownerReference.blockOwnerDeletion` 值的附属者才能阻止删除拥有者对象。 -在 Kubernetes 1.7 版本中将增加[准入控制器](/docs/reference/access-authn-authz/admission-controllers/#ownerreferencespermissionenforcement)，基于拥有者对象上的删除权限来控制用户去设置 `blockOwnerDeletion` 的值为 true，所以未授权的附属者不能够延迟拥有者对象的删除。 - -如果一个对象的 `ownerReferences` 字段被一个 Controller（例如 Deployment 或 ReplicaSet）设置，`blockOwnerDeletion` 会被自动设置，不需要手动修改这个字段。 +注意，在 `foregroundDeletion` 模式下，只有设置了 `ownerReference.blockOwnerDeletion` +值的附属才能阻止删除属主对象。 +在 Kubernetes 1.7 版本增加了 +[准入控制器](/zh/docs/reference/access-authn-authz/admission-controllers/#ownerreferencespermissionenforcement)， +基于属主对象上的删除权限来控制用户设置 `blockOwnerDeletion` 的值为 True， +这样未经授权的附属不能够阻止属主对象的删除。 +如果一个对象的 `ownerReferences` 字段被一个控制器（例如 Deployment 或 ReplicaSet）设置， +`blockOwnerDeletion` 也会被自动设置，你不需要手动修改这个字段。 <!-- ### Background cascading deletion @@ -180,9 +181,10 @@ In *background cascading deletion*, Kubernetes deletes the owner object immediately and the garbage collector then deletes the dependents in the background. --> -### 隐式级联删除 +### 后台级联删除 -在 *隐式级联删除* 模式下，Kubernetes 会立即删除拥有者对象，然后垃圾收集器会在后台删除这些附属值。 +在 *后台级联删除* 模式下，Kubernetes 会立即删除属主对象，之后垃圾收集器 +会在后台删除其附属对象。 <!-- ### Setting the cascading deletion policy @@ -190,27 +192,16 @@ the background. To control the cascading deletion policy, set the `propagationPolicy` field on the `deleteOptions` argument when deleting an Object. Possible values include "Orphan", "Foreground", or "Background". - -Prior to Kubernetes 1.9, the default garbage collection policy for many controller resources was `orphan`. -This included ReplicationController, ReplicaSet, StatefulSet, DaemonSet, and -Deployment. For kinds in the `extensions/v1beta1`, `apps/v1beta1`, and `apps/v1beta2` group versions, unless you -specify otherwise, dependent objects are orphaned by default. In Kubernetes 1.9, for all kinds in the `apps/v1` -group version, dependent objects are deleted by default. - --> - ### 设置级联删除策略 -通过为拥有者对象设置 `deleteOptions.propagationPolicy` 字段，可以控制级联删除策略。 -可能的取值包括：`orphan`、`Foreground` 或者 `Background`。 - -对很多 Controller 资源，包括 ReplicationController、ReplicaSet、StatefulSet、DaemonSet 和 Deployment，默认的垃圾收集策略是 `orphan`。 -因此，对于使用 `extensions/v1beta1`、`apps/v1beta1` 和 `apps/v1beta2` 组版本中的 `Kind`,除非指定其它的垃圾收集策略，否则所有附属对象默认使用的都是 `orphan` 策略。 +通过为属主对象设置 `deleteOptions.propagationPolicy` 字段，可以控制级联删除策略。 +可能的取值包括：`Orphan`、`Foreground` 或者 `Background`。 <!-- Here's an example that deletes dependents in background: --> -下面是一个在 `Background` 中删除 Dependent 对象的示例： +下面是一个在后台删除附属对象的示例： ```shell kubectl proxy --port=8080 @@ -223,7 +214,7 @@ curl -X DELETE localhost:8080/apis/apps/v1/namespaces/default/replicasets/my-rep Here's an example that deletes dependents in foreground: --> -下面是一个在 `Foreground` 中删除附属对象的示例： +下面是一个在前台中删除附属对象的示例： ```shell kubectl proxy --port=8080 @@ -235,8 +226,7 @@ curl -X DELETE localhost:8080/apis/apps/v1/namespaces/default/replicasets/my-rep <!-- Here's an example that orphans dependents: --> - -这里是一个 `Orphan` 附属的示例： +下面是一个令附属成为孤立对象的示例： ```shell kubectl proxy --port=8080 @@ -247,17 +237,18 @@ curl -X DELETE localhost:8080/apis/apps/v1/namespaces/default/replicasets/my-rep <!-- kubectl also supports cascading deletion. -To delete dependents automatically using kubectl, set `--cascade` to true. To -orphan dependents, set `--cascade` to false. The default value for `--cascade` +To delete dependents automatically using kubectl, set `-cascade` to true. To +orphan dependents, set `-cascade` to false. The default value for `-cascade` is true. Here's an example that orphans the dependents of a ReplicaSet: --> +`kubectl` 命令也支持级联删除。 +通过设置 `--cascade` 为 `true`，可以使用 kubectl 自动删除附属对象。 +设置 `--cascade` 为 `false`，会使附属对象成为孤立附属对象。 +`--cascade` 的默认值是 true。 -kubectl 也支持级联删除。 -通过设置 `--cascade` 为 `true`，可以使用 kubectl 自动删除附属对象。设置 `--cascade` 为 `false`，会使附属对象成为孤儿附属对象。`--cascade` 的默认值是 true。 - -下面是一个例子，使一个 ReplicaSet 的附属对象成为孤儿附属： +下面是一个例子，使一个 ReplicaSet 的附属对象成为孤立附属： ```shell kubectl delete replicaset my-repset --cascade=false @@ -271,40 +262,30 @@ to delete not only the ReplicaSets created, but also their Pods. If this type of is not used, only the ReplicaSets will be deleted, and the Pods will be orphaned. See [kubeadm/#149](https://github.com/kubernetes/kubeadm/issues/149#issuecomment-284766613) for more information. --> +### Deployment 的附加说明 -### Deployment 的其他说明 +在 1.7 之前的版本中，当在 Deployment 中使用级联删除时，你 *必须*使用 +`propagationPolicy:Foreground` 模式以便在删除所创建的 ReplicaSet 的同时，还删除其 Pod。 +如果不使用这种类型的 `propagationPolicy`，将只删除 ReplicaSet，而 Pod 被孤立。 -在 1.7 之前的版本中，当在 Deployment 中使用级联删除时，您必须*使用* `propagationPolicy:Foreground` 模式。这样不仅删除所创建的 ReplicaSet，还删除其 Pod。如果不使用这种类型的 `propagationPolicy`，则将只删除 ReplicaSet，而 Pod 被孤立。 - -更多信息，请参考 [kubeadm/#149](https://github.com/kubernetes/kubeadm/issues/149#issuecomment-284766613)。 +有关信息请参考 [kubeadm/#149](https://github.com/kubernetes/kubeadm/issues/149#issuecomment-284766613)。 <!-- ## Known issues Tracked at [#26120](https://github.com/kubernetes/kubernetes/issues/26120) --> - ## 已知的问题 跟踪 [#26120](https://github.com/kubernetes/kubernetes/issues/26120) - - - ## {{% heading "whatsnext" %}} - - <!-- [Design Doc 1](https://git.k8s.io/community/contributors/design-proposals/api-machinery/garbage-collection.md) [Design Doc 2](https://git.k8s.io/community/contributors/design-proposals/api-machinery/synchronous-garbage-collection.md) --> -[设计文档 1](https://git.k8s.io/community/contributors/design-proposals/api-machinery/garbage-collection.md) - -[设计文档 2](https://git.k8s.io/community/contributors/design-proposals/api-machinery/synchronous-garbage-collection.md) - - - - +* [设计文档 1](https://git.k8s.io/community/contributors/design-proposals/api-machinery/garbage-collection.md) +* [设计文档 2](https://git.k8s.io/community/contributors/design-proposals/api-machinery/synchronous-garbage-collection.md) diff --git a/content/zh/docs/concepts/workloads/controllers/job.md b/content/zh/docs/concepts/workloads/controllers/job.md new file mode 100644 index 0000000000..3156ff6a53 --- /dev/null +++ b/content/zh/docs/concepts/workloads/controllers/job.md @@ -0,0 +1,861 @@ +--- +title: Jobs +content_type: concept +feature: + title: 批量执行 + description: > + 除了服务之外，Kubernetes 还可以管理你的批处理和 CI 工作负载，在期望时替换掉失效的容器。 +weight: 60 +--- +<!-- +reviewers: +- erictune +- soltysh +title: Jobs +content_type: concept +feature: + title: Batch execution + description: > + In addition to services, Kubernetes can manage your batch and CI workloads, replacing containers that fail, if desired. +weight: 60 +--> + +<!-- overview --> +<!-- +A Job creates one or more Pods and ensures that a specified number of them successfully terminate. +As pods successfully complete, the Job tracks the successful completions. When a specified number +of successful completions is reached, the task (ie, Job) is complete. Deleting a Job will clean up +the Pods it created. + +A simple case is to create one Job object in order to reliably run one Pod to completion. +The Job object will start a new Pod if the first Pod fails or is deleted (for example +due to a node hardware failure or a node reboot). + +You can also use a Job to run multiple Pods in parallel. +--> +Job 会创建一个或者多个 Pods，并确保指定数量的 Pods 成功终止。 +随着 Pods 成功结束，Job 跟踪记录成功完成的 Pods 个数。 +当数量达到指定的成功个数阈值时，任务（即 Job）结束。 +删除 Job 的操作会清除所创建的全部 Pods。 + +一种简单的使用场景下，你会创建一个 Job 对象以便以一种可靠的方式运行某 Pod 直到完成。 +当第一个 Pod 失败或者被删除（比如因为节点硬件失效或者重启）时，Job +对象会启动一个新的 Pod。 + +你也可以使用 Job 以并行的方式运行多个 Pod。 + +<!-- body --> +<!-- +## Running an example Job + +Here is an example Job config. It computes π to 2000 places and prints it out. +It takes around 10s to complete. +--> +## 运行示例 Job {#running-an-example-job} + +下面是一个 Job 配置示例。它负责计算 π 到小数点后 2000 位，并将结果打印出来。 +此计算大约需要 10 秒钟完成。 + +{{< codenew file="controllers/job.yaml" >}} + +<!--You can run the example with this command:--> +你可以使用下面的命令来运行此示例： + +```shell +kubectl apply -f https://kubernetes.io/examples/controllers/job.yaml +``` + +输出类似于： + +``` +job.batch/pi created +``` + +<!-- Check on the status of the Job with `kubectl`: --> +使用 `kubectl` 来检查 Job 的状态： + +```shell +kubectl describe jobs/pi +``` + +输出类似于： + +``` +Name: pi +Namespace: default +Selector: controller-uid=c9948307-e56d-4b5d-8302-ae2d7b7da67c +Labels: controller-uid=c9948307-e56d-4b5d-8302-ae2d7b7da67c + job-name=pi +Annotations: kubectl.kubernetes.io/last-applied-configuration: + {"apiVersion":"batch/v1","kind":"Job","metadata":{"annotations":{},"name":"pi","namespace":"default"},"spec":{"backoffLimit":4,"template":... +Parallelism: 1 +Completions: 1 +Start Time: Mon, 02 Dec 2019 15:20:11 +0200 +Completed At: Mon, 02 Dec 2019 15:21:16 +0200 +Duration: 65s +Pods Statuses: 0 Running / 1 Succeeded / 0 Failed +Pod Template: + Labels: controller-uid=c9948307-e56d-4b5d-8302-ae2d7b7da67c + job-name=pi + Containers: + pi: + Image: perl + Port: <none> + Host Port: <none> + Command: + perl + -Mbignum=bpi + -wle + print bpi(2000) + Environment: <none> + Mounts: <none> + Volumes: <none> +Events: + Type Reason Age From Message + ---- ------ ---- ---- ------- + Normal SuccessfulCreate 14m job-controller Created pod: pi-5rwd7 +``` + +<!-- +To view completed Pods of a Job, use `kubectl get pods`. + +To list all the Pods that belong to a Job in a machine readable form, you can use a command like this: +--> +要查看 Job 对应的已完成的 Pods，可以执行 `kubectl get pods`。 + +要以机器可读的方式列举隶属于某 Job 的全部 Pods，你可以使用类似下面这条命令： + +```shell +pods=$(kubectl get pods --selector=job-name=pi --output=jsonpath='{.items[*].metadata.name}') +echo $pods +``` + +输出类似于： + +``` +pi-5rwd7 +``` + +<!-- +Here, the selector is the same as the selector for the Job. The `-output=jsonpath` option specifies an expression +that just gets the name from each Pod in the returned list. + +View the standard output of one of the pods: +--> +这里，选择算符与 Job 的选择算符相同。`--output=jsonpath` 选项给出了一个表达式， +用来从返回的列表中提取每个 Pod 的 name 字段。 + +查看其中一个 Pod 的标准输出： + +```shell +kubectl logs $pods +``` + +<!--The output is similar to this:--> +输出类似于： + +``` +3.1415926535897932384626433832795028841971693993751058209749445923078164062862089986280348253421170679821480865132823066470938446095505822317253594081284811174502841027019385211055596446229489549303819644288109756659334461284756482337867831652712019091456485669234603486104543266482133936072602491412737245870066063155881748815209209628292540917153643678925903600113305305488204665213841469519415116094330572703657595919530921861173819326117931051185480744623799627495673518857527248912279381830119491298336733624406566430860213949463952247371907021798609437027705392171762931767523846748184676694051320005681271452635608277857713427577896091736371787214684409012249534301465495853710507922796892589235420199561121290219608640344181598136297747713099605187072113499999983729780499510597317328160963185950244594553469083026425223082533446850352619311881710100031378387528865875332083814206171776691473035982534904287554687311595628638823537875937519577818577805321712268066130019278766111959092164201989380952572010654858632788659361533818279682303019520353018529689957736225994138912497217752834791315155748572424541506959508295331168617278558890750983817546374649393192550604009277016711390098488240128583616035637076601047101819429555961989467678374494482553797747268471040475346462080466842590694912933136770289891521047521620569660240580381501935112533824300355876402474964732639141992726042699227967823547816360093417216412199245863150302861829745557067498385054945885869269956909272107975093029553211653449872027559602364806654991198818347977535663698074265425278625518184175746728909777727938000816470600161452491921732172147723501414419735685481613611573525521334757418494684385233239073941433345477624168625189835694855620992192221842725502542568876717904946016534668049886272327917860857843838279679766814541009538837863609506800642251252051173929848960841284886269456042419652850222106611863067442786220391949450471237137869609563643719172874677646575739624138908658326459958133904780275901 +``` +<!-- +## Writing a Job spec + +As with all other Kubernetes config, a Job needs `apiVersion`, `kind`, and `metadata` fields. +Its name must be a valid [DNS subdomain name](/docs/concepts/overview/working-with-objects/names#dns-subdomain-names). + +A Job also needs a [`.spec` section](https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status). +--> +## 编写 Job 规约 + +与 Kubernetes 中其他资源的配置类似，Job 也需要 `apiVersion`、`kind` 和 `metadata` 字段。 +Job 的名字必须时合法的 [DNS 子域名](/zh/docs/concepts/overview/working-with-objects/names#dns-subdomain-names)。 + +Job 配置还需要一个[`.spec` 节](https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status)。 + +<!-- +### Pod Template + +The `.spec.template` is the only required field of the `.spec`. + +The `.spec.template` is a [pod template](/docs/concepts/workloads/pods/#pod-templates). It has exactly the same schema as a {{< glossary_tooltip text="Pod" term_id="pod" >}}, except it is nested and does not have an `apiVersion` or `kind`. + +In addition to required fields for a Pod, a pod template in a Job must specify appropriate +labels (see [pod selector](#pod-selector)) and an appropriate restart policy. + +Only a [`RestartPolicy`](/docs/concepts/workloads/pods/pod-lifecycle/#restart-policy) equal to `Never` or `OnFailure` is allowed. +--> +### Pod 模版 + +Job 的 `.spec` 中只有 `.spec.template` 是必需的字段。 + +字段 `.spec.template` 的值是一个 [Pod 模版](/zh/docs/concepts/workloads/pods/#pod-templates)。 +其定义规范与 {{< glossary_tooltip text="Pod" term_id="pod" >}} +完全相同，只是其中不再需要 `apiVersion` 或 `kind` 字段。 + +除了作为 Pod 所必需的字段之外，Job 中的 Pod 模版必需设置合适的标签 +（参见[Pod 选择算符](#pod-selector)）和合适的重启策略。 + +Job 中 Pod 的 [`RestartPolicy`](/zh/docs/concepts/workloads/pods/pod-lifecycle/#restart-policy) +只能设置为 `Never` 或 `OnFailure` 之一。 + +<!-- +### Pod selector + +The `.spec.selector` field is optional. In almost all cases you should not specify it. +See section [specifying your own pod selector](#specifying-your-own-pod-selector). +--> +### Pod 选择算符 {#pod-selector} + +字段 `.spec.selector` 是可选的。在绝大多数场合，你都不需要为其赋值。 +参阅[设置自己的 Pod 选择算符](#specifying-your-own-pod-selector). + +<!-- +### Parallel execution for Jobs {#parallel-jobs} + +There are three main types of task suitable to run as a Job: +--> +### Job 的并行执行 {#parallel-jobs} + +适合以 Job 形式来运行的任务主要有三种： +<!-- +1. Non-parallel Jobs + - normally, only one Pod is started, unless the Pod fails. + - the Job is complete as soon as its Pod terminates successfully. +1. Parallel Jobs with a *fixed completion count*: + - specify a non-zero positive value for `.spec.completions`. + - the Job represents the overall task, and is complete when there is one successful Pod for each value in the range 1 to `.spec.completions`. + - **not implemented yet:** Each Pod is passed a different index in the range 1 to `.spec.completions`. +1. Parallel Jobs with a *work queue*: + - do not specify `.spec.completions`, default to `.spec.parallelism`. + - the Pods must coordinate amongst themselves or an external service to determine what each should work on. For example, a Pod might fetch a batch of up to N items from the work queue. + - each Pod is independently capable of determining whether or not all its peers are done, and thus that the entire Job is done. + - when _any_ Pod from the Job terminates with success, no new Pods are created. + - once at least one Pod has terminated with success and all Pods are terminated, then the Job is completed with success. + - once any Pod has exited with success, no other Pod should still be doing any work for this task or writing any output. They should all be in the process of exiting. +--> +1. 非并行 Job + - 通常只启动一个 Pod，除非该 Pod 失败 + - 当 Pod 成功终止时，立即视 Job 为完成状态 +1. 具有 *确定完成计数* 的并行 Job + - `.spec.completions` 字段设置为非 0 的正数值 + - Job 用来代表整个任务，当对应于 1 和 `.spec.completions` 之间的每个整数都存在 + 一个成功的 Pod 时，Job 被视为完成 + - **尚未实现**：每个 Pod 收到一个介于 1 和 `spec.completions` 之间的不同索引值 +1. 带 *工作队列* 的并行 Job + - 不设置 `spec.completions`，默认值为 `.spec.parallelism` + - 多个 Pod 之间必须相互协调，或者借助外部服务确定每个 Pod 要处理哪个工作条目。 + 例如，任一 Pod 都可以从工作队列中取走最多 N 个工作条目。 + - 每个 Pod 都可以独立确定是否其它 Pod 都已完成，进而确定 Job 是否完成 + - 当 Job 中 _任何_ Pod 成功终止，不再创建新 Pod + - 一旦至少 1 个 Pod 成功完成，并且所有 Pod 都已终止，即可宣告 Job 成功完成 + - 一旦任何 Pod 成功退出，任何其它 Pod 都不应再对此任务执行任何操作或生成任何输出。 + 所有 Pod 都应启动退出过程。 + +<!-- +For a _non-parallel_ Job, you can leave both `.spec.completions` and `.spec.parallelism` unset. When both are +unset, both are defaulted to 1. + +For a _fixed completion count_ Job, you should set `.spec.completions` to the number of completions needed. +You can set `.spec.parallelism`, or leave it unset and it will default to 1. + +For a _work queue_ Job, you must leave `.spec.completions` unset, and set `.spec.parallelism` to +a non-negative integer. + +For more information about how to make use of the different types of job, see the [job patterns](#job-patterns) section. +--> +对于 _非并行_ 的 Job，你可以不设置 `spec.completions` 和 `spec.parallelism`。 +这两个属性都不设置时，均取默认值 1。 + +对于 _确定完成计数_ 类型的 Job，你应该设置 `.spec.completions` 为所需要的完成个数。 +你可以设置 `.spec.parallelism`，也可以不设置。其默认值为 1。 + +对于一个 _工作队列_ Job，你不可以设置 `.spec.completions`，但要将`.spec.parallelism` +设置为一个非负整数。 + +关于如何利用不同类型的 Job 的更多信息，请参见 [Job 模式](#job-patterns)一节。 + +<!-- +#### Controlling parallelism + +The requested parallelism (`.spec.parallelism`) can be set to any non-negative value. +If it is unspecified, it defaults to 1. +If it is specified as 0, then the Job is effectively paused until it is increased. + +Actual parallelism (number of pods running at any instant) may be more or less than requested +parallelism, for a variety of reasons: +--> +#### 控制并行性 {#controlling-parallelism} + +并行性请求（`.spec.parallelism`）可以设置为任何非负整数。 +如果未设置，则默认为 1。 +如果设置为 0，则 Job 相当于启动之后便被暂停，直到此值被增加。 + +实际并行性（在任意时刻运行状态的 Pods 个数）可能比并行性请求略大或略小， +原因如下： + +<!-- +- For _fixed completion count_ Jobs, the actual number of pods running in parallel will not exceed the number of + remaining completions. Higher values of `.spec.parallelism` are effectively ignored. +- For _work queue_ Jobs, no new Pods are started after any Pod has succeeded - remaining Pods are allowed to complete, however. +- If the Job {{< glossary_tooltip term_id="controller" >}} has not had time to react. +- If the Job controller failed to create Pods for any reason (lack of `ResourceQuota`, lack of permission, etc.), + then there may be fewer pods than requested. +- The Job controller may throttle new Pod creation due to excessive previous pod failures in the same Job. +- When a Pod is gracefully shut down, it takes time to stop. +--> +- 对于 _确定完成计数_ Job，实际上并行执行的 Pods 个数不会超出剩余的完成数。 + 如果 `.spec.parallelism` 值较高，会被忽略。 +- 对于 _工作队列_ Job，有任何 Job 成功结束之后，不会有新的 Pod 启动。 + 不过，剩下的 Pods 允许执行完毕。 +- 如果 Job {{< glossary_tooltip text="控制器" term_id="controller" >}} 没有来得及作出响应，或者 +- 如果 Job 控制器因为任何原因（例如，缺少 `ResourceQuota` 或者没有权限）无法创建 Pods。 + Pods 个数可能比请求的数目小。 +- Job 控制器可能会因为之前同一 Job 中 Pod 失效次数过多而压制新 Pod 的创建。 +- 当 Pod 处于体面终止进程中，需要一定时间才能停止。 + +<!-- +## Handling Pod and container failures + +A container in a Pod may fail for a number of reasons, such as because the process in it exited with +a non-zero exit code, or the container was killed for exceeding a memory limit, etc. If this +happens, and the `.spec.template.spec.restartPolicy = "OnFailure"`, then the Pod stays +on the node, but the container is re-run. Therefore, your program needs to handle the case when it is +restarted locally, or else specify `.spec.template.spec.restartPolicy = "Never"`. +See [pod lifecycle](/docs/concepts/workloads/pods/pod-lifecycle/#example-states) for more information on `restartPolicy`. +--> + +## 处理 Pod 和容器失效 + +Pod 中的容器可能因为多种不同原因失效，例如因为其中的进程退出时返回值非零， +或者容器因为超出内存约束而被杀死等等。 +如果发生这类事件，并且 `.spec.template.spec.restartPolicy = "OnFailure"`， +Pod 则继续留在当前节点，但容器会被重新运行。 +因此，你的程序需要能够处理在本地被重启的情况，或者要设置 +`.spec.template.spec.restartPolicy = "Never"`。 +关于 `restartPolicy` 的更多信息，可参阅 +[Pod 生命周期](/zh/docs/concepts/workloads/pods/pod-lifecycle/#example-states)。 + +<!-- +An entire Pod can also fail, for a number of reasons, such as when the pod is kicked off the node +(node is upgraded, rebooted, deleted, etc.), or if a container of the Pod fails and the +`.spec.template.spec.restartPolicy = "Never"`. When a Pod fails, then the Job controller +starts a new Pod. This means that your application needs to handle the case when it is restarted in a new +pod. In particular, it needs to handle temporary files, locks, incomplete output and the like +caused by previous runs. +--> +整个 Pod 也可能会失败，且原因各不相同。 +例如，当 Pod 启动时，节点失效（被升级、被重启、被删除等）或者其中的容器失败而 +`.spec.template.spec.restartPolicy = "Never"`。 +当 Pod 失败时，Job 控制器会启动一个新的 Pod。 +这意味着，你的应用需要处理在一个新 Pod 中被重启的情况。 +尤其是应用需要处理之前运行所触碰或产生的临时文件、锁、不完整的输出等问题。 + +<!-- +Note that even if you specify `.spec.parallelism = 1` and `.spec.completions = 1` and +`.spec.template.spec.restartPolicy = "Never"`, the same program may +sometimes be started twice. + +If you do specify `.spec.parallelism` and `.spec.completions` both greater than 1, then there may be +multiple pods running at once. Therefore, your pods must also be tolerant of concurrency. +--> +注意，即使你将 `.spec.parallelism` 设置为 1，且将 `.spec.completions` 设置为 +1，并且 `.spec.template.spec.restartPolicy` 设置为 "Never"，同一程序仍然有可能被启动两次。 + +如果你确实将 `.spec.parallelism` 和 `.spec.completions` 都设置为比 1 大的值， +那就有可能同时出现多个 Pod 运行的情况。 +为此，你的 Pod 也必须能够处理并发性问题。 + +<!-- +### Pod backoff failure policy + +There are situations where you want to fail a Job after some amount of retries +due to a logical error in configuration etc. +To do so, set `.spec.backoffLimit` to specify the number of retries before +considering a Job as failed. The back-off limit is set by default to 6. Failed +Pods associated with the Job are recreated by the Job controller with an +exponential back-off delay (10s, 20s, 40s ...) capped at six minutes. The +back-off count is reset when a Job's Pod is deleted or successful without any +other Pods for the Job failing around that time. +--> +### Pod 回退失效策略 + +在有些情形下，你可能希望 Job 在经历若干次重试之后直接进入失败状态，因为这很 +可能意味着遇到了配置错误。 +为了实现这点，可以将 `.spec.backoffLimit` 设置为视 Job 为失败之前的重试次数。 +失效回退的限制值默认为 6。 +与 Job 相关的失效的 Pod 会被 Job 控制器重建，并且以指数型回退计算重试延迟 +（从 10 秒、20 秒到 40 秒，最多 6 分钟）。 +当 Job 的 Pod 被删除时，或者 Pod 成功时没有其它 Pod 处于失败状态，失效回退的次数也会被重置（为 0）。 + +<!-- +If your job has `restartPolicy = "OnFailure"`, keep in mind that your container running the Job +will be terminated once the job backoff limit has been reached. This can make debugging the Job's executable more difficult. We suggest setting +`restartPolicy = "Never"` when debugging the Job or using a logging system to ensure output +from failed Jobs is not lost inadvertently. +--> +{{< note >}} +如果你的 Job 的 `restartPolicy` 被设置为 "OnFailure"，就要注意运行该 Job 的容器 +会在 Job 到达失效回退次数上限时自动被终止。 +这会使得调试 Job 中可执行文件的工作变得非常棘手。 +我们建议在调试 Job 时将 `restartPolicy` 设置为 "Never"， +或者使用日志系统来确保失效 Jobs 的输出不会意外遗失。 +{{< /note >}} + +<!-- +## Job termination and cleanup + +When a Job completes, no more Pods are created, but the Pods are not deleted either. Keeping them around +allows you to still view the logs of completed pods to check for errors, warnings, or other diagnostic output. +The job object also remains after it is completed so that you can view its status. It is up to the user to delete +old jobs after noting their status. Delete the job with `kubectl` (e.g. `kubectl delete jobs/pi` or `kubectl delete -f ./job.yaml`). When you delete the job using `kubectl`, all the pods it created are deleted too. +--> +## Job 终止与清理 + +Job 完成时不会再创建新的 Pod，不过已有的 Pod 也不会被删除。 +保留这些 Pod 使得你可以查看已完成的 Pod 的日志输出，以便检查错误、警告 +或者其它诊断性输出。 +Job 完成时 Job 对象也一样被保留下来，这样你就可以查看它的状态。 +在查看了 Job 状态之后删除老的 Job 的操作留给了用户自己。 +你可以使用 `kubectl` 来删除 Job（例如，`kubectl delete jobs/pi` +或者 `kubectl delete -f ./job.yaml`）。 +当使用 `kubectl` 来删除 Job 时，该 Job 所创建的 Pods 也会被删除。 + +<!-- +By default, a Job will run uninterrupted unless a Pod fails (`restartPolicy=Never`) or a Container exits in error (`restartPolicy=OnFailure`), at which point the Job defers to the +`.spec.backoffLimit` described above. Once `.spec.backoffLimit` has been reached the Job will be marked as failed and any running Pods will be terminated. + +Another way to terminate a Job is by setting an active deadline. +Do this by setting the `.spec.activeDeadlineSeconds` field of the Job to a number of seconds. +The `activeDeadlineSeconds` applies to the duration of the job, no matter how many Pods are created. +Once a Job reaches `activeDeadlineSeconds`, all of its running Pods are terminated and the Job status will become `type: Failed` with `reason: DeadlineExceeded`. +--> +默认情况下，Job 会持续运行，除非某个 Pod 失败（`restartPolicy=Never`） +或者某个容器出错退出（`restartPolicy=OnFailure`）。 +这时，Job 基于前述的 `spec.backoffLimit` 来决定是否以及如何重试。 +一旦重试次数到达 `.spec.backoffLimit` 所设的上限，Job 会被标记为失败， +其中运行的 Pods 都会被终止。 + +终止 Job 的另一种方式是设置一个活跃期限。 +你可以为 Job 的 `.spec.activeDeadlineSeconds` 设置一个秒数值。 +该值适用于 Job 的整个生命期，无论 Job 创建了多少个 Pod。 +一旦 Job 运行时间达到 `activeDeadlineSeconds` 秒，其所有运行中的 Pod +都会被终止，并且 Job 的状态更新为 `type: Failed` +及 `reason: DeadlineExceeded`。 + +<!-- +Note that a Job's `.spec.activeDeadlineSeconds` takes precedence over its `.spec.backoffLimit`. Therefore, a Job that is retrying one or more failed Pods will not deploy additional Pods once it reaches the time limit specified by `activeDeadlineSeconds`, even if the `backoffLimit` is not yet reached. + +Example: +--> +注意 Job 的 `.spec.activeDeadlineSeconds` 优先级高于其 `.spec.backoffLimit` 设置。 +因此，如果一个 Job 正在重试一个或多个失效的 Pod，该 Job 一旦到达 +`activeDeadlineSeconds` 所设的时限即不再部署额外的 Pod，即使其重试次数还未 +达到 `backoffLimit` 所设的限制。 + +例如： + +```yaml +apiVersion: batch/v1 +kind: Job +metadata: + name: pi-with-timeout +spec: + backoffLimit: 5 + activeDeadlineSeconds: 100 + template: + spec: + containers: + - name: pi + image: perl + command: ["perl", "-Mbignum=bpi", "-wle", "print bpi(2000)"] + restartPolicy: Never +``` +<!-- +Note that both the Job spec and the [Pod template spec](/docs/concepts/workloads/pods/init-containers/#detailed-behavior) within the Job have an `activeDeadlineSeconds` field. Ensure that you set this field at the proper level. + +Keep in mind that the `restartPolicy` applies to the Pod, and not to the Job itself: there is no automatic Job restart once the Job status is `type: Failed`. +That is, the Job termination mechanisms activated with `.spec.activeDeadlineSeconds` and `.spec.backoffLimit` result in a permanent Job failure that requires manual intervention to resolve. +--> +注意 Job 规约和 Job 中的 +[Pod 模版规约](/zh/docs/concepts/workloads/pods/init-containers/#detailed-behavior) +都有 `activeDeadlineSeconds` 字段。 +请确保你在合适的层次设置正确的字段。 + +还要注意的是，`restartPolicy` 对应的是 Pod，而不是 Job 本身： +一旦 Job 状态变为 `type: Failed`，就不会再发生 Job 重启的动作。 +换言之，由 `.spec.activeDeadlineSeconds` 和 `.spec.backoffLimit` 所触发的 Job 终结机制 +都会导致 Job 永久性的失败，而这类状态都需要手工干预才能解决。 + +<!-- +## Clean up finished jobs automatically + +Finished Jobs are usually no longer needed in the system. Keeping them around in +the system will put pressure on the API server. If the Jobs are managed directly +by a higher level controller, such as +[CronJobs](/docs/concepts/workloads/controllers/cron-jobs/), the Jobs can be +cleaned up by CronJobs based on the specified capacity-based cleanup policy. + +### TTL mechanism for finished Jobs +--> +## 自动清理完成的 Job {#clean-up-finished-jobs-automatically} + +完成的 Job 通常不需要留存在系统中。在系统中一直保留它们会给 API +服务器带来额外的压力。 +如果 Job 由某种更高级别的控制器来管理，例如 +[CronJobs](/zh/docs/concepts/workloads/controllers/cron-jobs/)， +则 Job 可以被 CronJob 基于特定的根据容量裁定的清理策略清理掉。 + +### 已完成 Job 的 TTL 机制 {#ttl-mechanisms-for-finished-jobs} + +{{< feature-state for_k8s_version="v1.12" state="alpha" >}} + +<!-- +Another way to clean up finished Jobs (either `Complete` or `Failed`) +automatically is to use a TTL mechanism provided by a +[TTL controller](/docs/concepts/workloads/controllers/ttlafterfinished/) for +finished resources, by specifying the `.spec.ttlSecondsAfterFinished` field of +the Job. + +When the TTL controller cleans up the Job, it will delete the Job cascadingly, +i.e. delete its dependent objects, such as Pods, together with the Job. Note +that when the Job is deleted, its lifecycle guarantees, such as finalizers, will +be honored. + +For example: +--> +自动清理已完成 Job （状态为 `Complete` 或 `Failed`）的另一种方式是使用由 +[TTL 控制器](/zh/docs/concepts/workloads/controllers/ttlafterfinished/)所提供 +的 TTL 机制。 +通过设置 Job 的 `.spec.ttlSecondsAfterFinished` 字段，可以让该控制器清理掉 +已结束的资源。 + +TTL 控制器清理 Job 时，会级联式地删除 Job 对象。 +换言之，它会删除所有依赖的对象，包括 Pod 及 Job 本身。 +注意，当 Job 被删除时，系统会考虑其生命周期保障，例如其 Finalizers。 + +例如： + +```yaml +apiVersion: batch/v1 +kind: Job +metadata: + name: pi-with-ttl +spec: + ttlSecondsAfterFinished: 100 + template: + spec: + containers: + - name: pi + image: perl + command: ["perl", "-Mbignum=bpi", "-wle", "print bpi(2000)"] + restartPolicy: Never +``` + +<!-- +The Job `pi-with-ttl` will be eligible to be automatically deleted, `100` +seconds after it finishes. + +If the field is set to `0`, the Job will be eligible to be automatically deleted +immediately after it finishes. If the field is unset, this Job won't be cleaned +up by the TTL controller after it finishes. + +Note that this TTL mechanism is alpha, with feature gate `TTLAfterFinished`. For +more information, see the documentation for +[TTL controller](/docs/concepts/workloads/controllers/ttlafterfinished/) for +finished resources. +--> +Job `pi-with-ttl` 在结束 100 秒之后，可以成为被自动删除的标的。 + +如果该字段设置为 `0`，Job 在结束之后立即成为可被自动删除的对象。 +如果该字段没有设置，Job 不会在结束之后被 TTL 控制器自动清除。 + +注意这种 TTL 机制仍然是一种 Alpha 状态的功能特性，需要配合 `TTLAfterFinished` +特性门控使用。有关详细信息，可参考 +[TTL 控制器](/zh/docs/concepts/workloads/controllers/ttlafterfinished/)的文档。 + +<!-- +## Job patterns + +The Job object can be used to support reliable parallel execution of Pods. The Job object is not +designed to support closely-communicating parallel processes, as commonly found in scientific +computing. It does support parallel processing of a set of independent but related *work items*. +These might be emails to be sent, frames to be rendered, files to be transcoded, ranges of keys in a +NoSQL database to scan, and so on. +--> +## Job 模式 {#job-patterns} + +Job 对象可以用来支持多个 Pod 的可靠的并发执行。 +Job 对象不是设计用来支持相互通信的并行进程的，后者一般在科学计算中应用较多。 +Job 的确能够支持对一组相互独立而又有所关联的 *工作条目* 的并行处理。 +这类工作条目可能是要发送的电子邮件、要渲染的视频帧、要编解码的文件、NoSQL +数据库中要扫描的主键范围等等。 + +<!-- +In a complex system, there may be multiple different sets of work items. Here we are just +considering one set of work items that the user wants to manage together — a *batch job*. + +There are several different patterns for parallel computation, each with strengths and weaknesses. +The tradeoffs are: +--> +在一个复杂系统中，可能存在多个不同的工作条目集合。这里我们仅考虑用户希望一起管理的 +工作条目集合之一 — *批处理作业*。 + +并行计算的模式有好多种，每种都有自己的强项和弱点。这里要权衡的因素有： + +<!-- +- One Job object for each work item, vs. a single Job object for all work items. The latter is + better for large numbers of work items. The former creates some overhead for the user and for the + system to manage large numbers of Job objects. +- Number of pods created equals number of work items, vs. each Pod can process multiple work items. + The former typically requires less modification to existing code and containers. The latter + is better for large numbers of work items, for similar reasons to the previous bullet. +- Several approaches use a work queue. This requires running a queue service, + and modifications to the existing program or container to make it use the work queue. + Other approaches are easier to adapt to an existing containerised application. +--> +- 每个工作条目对应一个 Job 或者所有工作条目对应同一 Job 对象。 + 后者更适合处理大量工作条目的场景； + 前者会给用户带来一些额外的负担，而且需要系统管理大量的 Job 对象。 +- 创建与工作条目相等的 Pod 或者令每个 Pod 可以处理多个工作条目。 + 前者通常不需要对现有代码和容器做较大改动； + 后者则更适合工作条目数量较大的场合，原因同上。 +- 有几种技术都会用到工作队列。这意味着需要运行一个队列服务，并修改现有程序或容器 + 使之能够利用该工作队列。 + 与之比较，其他方案在修改现有容器化应用以适应需求方面可能更容易一些。 + +<!-- +The tradeoffs are summarized here, with columns 2 to 4 corresponding to the above tradeoffs. +The pattern names are also links to examples and more detailed description. +--> +下面是对这些权衡的汇总，列 2 到 4 对应上面的权衡比较。 +模式的名称对应了相关示例和更详细描述的链接。 + +| 模式 | 单个 Job 对象 | Pods 数少于工作条目数？ | 直接使用应用无需修改? | 在 Kube 1.1 上可用？| +| ----- |:-------------:|:-----------------------:|:---------------------:|:-------------------:| +| [Job 模版扩展](/zh/docs/tasks/job/parallel-processing-expansion/) | | | ✓ | ✓ | +| [每工作条目一 Pod 的队列](/zh/docs/tasks/job/coarse-parallel-processing-work-queue/) | ✓ | | 有时 | ✓ | +| [Pod 数量可变的队列](/zh/docs/tasks/job/fine-parallel-processing-work-queue/) | ✓ | ✓ | | ✓ | +| 静态工作分派的单个 Job | ✓ | | ✓ | | + +<!-- +When you specify completions with `.spec.completions`, each Pod created by the Job controller +has an identical [`spec`](https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status). This means that +all pods for a task will have the same command line and the same +image, the same volumes, and (almost) the same environment variables. These patterns +are different ways to arrange for pods to work on different things. + +This table shows the required settings for `.spec.parallelism` and `.spec.completions` for each of the patterns. +Here, `W` is the number of work items. +--> +当你使用 `.spec.completions` 来设置完成数时，Job 控制器所创建的每个 Pod +使用完全相同的 [`spec`](https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status)。 +这意味着任务的所有 Pod 都有相同的命令行，都使用相同的镜像和数据卷，甚至连 +环境变量都（几乎）相同。 +这些模式是让每个 Pod 执行不同工作的几种不同形式。 + +下表显示的是每种模式下 `.spec.parallelism` 和 `.spec.completions` 所需要的设置。 +其中，`W` 表示的是工作条目的个数。 + +| 模式 | `.spec.completions` | `.spec.parallelism` | +| ----- |:-------------------:|:--------------------:| +| [Job 模版扩展](/zh/docs/tasks/job/parallel-processing-expansion/) | 1 | 应该为 1 | +| [每工作条目一 Pod 的队列](/zh/docs/tasks/job/coarse-parallel-processing-work-queue/) | W | 任意值 | +| [Pod 个数可变的队列](/zh/docs/tasks/job/fine-parallel-processing-work-queue/) | 1 | 任意值 | +| 基于静态工作分派的单一 Job | W | 任意值 | + +<!-- +## Advanced usage + +### Specifying your own Pod selector {#specifying-your-own-pod-selector} + +Normally, when you create a Job object, you do not specify `.spec.selector`. +The system defaulting logic adds this field when the Job is created. +It picks a selector value that will not overlap with any other jobs. + +However, in some cases, you might need to override this automatically set selector. +To do this, you can specify the `.spec.selector` of the Job. +--> +## 高级用法 {#advanced-usage} + +### 指定你自己的 Pod 选择算符 {#specifying-your-own-pod-selector} + +通常，当你创建一个 Job 对象时，你不会设置 `.spec.selector`。 +系统的默认值填充逻辑会在创建 Job 时添加此字段。 +它会选择一个不会与任何其他 Job 重叠的选择算符设置。 + +不过，有些场合下，你可能需要重载这个自动设置的选择算符。 +为了实现这点，你可以手动设置 Job 的 `spec.selector` 字段。 + +<!-- +Be very careful when doing this. If you specify a label selector which is not +unique to the pods of that Job, and which matches unrelated Pods, then pods of the unrelated +job may be deleted, or this Job may count other Pods as completing it, or one or both +Jobs may refuse to create Pods or run to completion. If a non-unique selector is +chosen, then other controllers (e.g. ReplicationController) and their Pods may behave +in unpredictable ways too. Kubernetes will not stop you from making a mistake when +specifying `.spec.selector`. +--> +做这个操作时请务必小心。 +如果你所设定的标签选择算符并不唯一针对 Job 对应的 Pod 集合，甚或该算符还能匹配 +其他无关的 Pod，这些无关的 Job 的 Pod 可能会被删除。 +或者当前 Job 会将另外一些 Pod 当作是完成自身工作的 Pods， +又或者两个 Job 之一或者二者同时都拒绝创建 Pod，无法运行至完成状态。 +如果所设置的算符不具有唯一性，其他控制器（如 RC 副本控制器）及其所管理的 Pod +集合可能会变得行为不可预测。 +Kubernetes 不会在你设置 `.spec.selector` 时尝试阻止你犯这类错误。 + +<!-- +Here is an example of a case when you might want to use this feature. + +Say Job `old` is already running. You want existing Pods +to keep running, but you want the rest of the Pods it creates +to use a different pod template and for the Job to have a new name. +You cannot update the Job because these fields are not updatable. +Therefore, you delete Job `old` but _leave its pods +running_, using `kubectl delete jobs/old -cascade=false`. +Before deleting it, you make a note of what selector it uses: +--> +下面是一个示例场景，在这种场景下你可能会使用刚刚讲述的特性。 + +假定名为 `old` 的 Job 已经处于运行状态。 +你希望已有的 Pod 继续运行，但你希望 Job 接下来要创建的其他 Pod +使用一个不同的 Pod 模版，甚至希望 Job 的名字也发生变化。 +你无法更新现有的 Job，因为这些字段都是不可更新的。 +因此，你会删除 `old` Job，但 _允许该 Job 的 Pod 集合继续运行_。 +这是通过 `kubectl delete jobs/old --cascade=false` 实现的。 +在删除之前，我们先记下该 Job 所使用的选择算符。 + +```shell +kubectl get job old -o yaml +``` + +输出类似于： + +``` +kind: Job +metadata: + name: old + ... +spec: + selector: + matchLabels: + controller-uid: a8f3d00d-c6d2-11e5-9f87-42010af00002 + ... +``` + +<!-- +Then you create a new Job with name `new` and you explicitly specify the same selector. +Since the existing Pods have label `controller-uid=a8f3d00d-c6d2-11e5-9f87-42010af00002`, +they are controlled by Job `new` as well. + +You need to specify `manualSelector: true` in the new Job since you are not using +the selector that the system normally generates for you automatically. +--> +接下来你会创建名为 `new` 的新 Job，并显式地为其设置相同的选择算符。 +由于现有 Pod 都具有标签 `controller-uid=a8f3d00d-c6d2-11e5-9f87-42010af00002`， +它们也会被名为 `new` 的 Job 所控制。 + +你需要在新 Job 中设置 `manualSelector: true`，因为你并未使用系统通常自动为你 +生成的选择算符。 + +``` +kind: Job +metadata: + name: new + ... +spec: + manualSelector: true + selector: + matchLabels: + controller-uid: a8f3d00d-c6d2-11e5-9f87-42010af00002 + ... +``` + +<!-- +The new Job itself will have a different uid from `a8f3d00d-c6d2-11e5-9f87-42010af00002`. Setting +`manualSelector: true` tells the system to that you know what you are doing and to allow this +mismatch. +--> +新的 Job 自身会有一个不同于 `a8f3d00d-c6d2-11e5-9f87-42010af00002` 的唯一 ID。 +设置 `manualSelector: true` 是在告诉系统你知道自己在干什么并要求系统允许这种不匹配 +的存在。 + +<!-- +## Alternatives + +### Bare Pods + +When the node that a Pod is running on reboots or fails, the pod is terminated +and will not be restarted. However, a Job will create new Pods to replace terminated ones. +For this reason, we recommend that you use a Job rather than a bare Pod, even if your application +requires only a single Pod. +--> +## 替代方案 {#alternatives} + +### 裸 Pod {#bare-pods} + +当 Pod 运行所在的节点重启或者失败，Pod 会被终止并且不会被重启。 +Job 会重新创建新的 Pod 来替代已终止的 Pod。 +因为这个原因，我们建议你使用 Job 而不是独立的裸 Pod， +即使你的应用仅需要一个 Pod。 + +<!-- +### Replication Controller + +Jobs are complementary to [Replication Controllers](/docs/user-guide/replication-controller). +A Replication Controller manages Pods which are not expected to terminate (e.g. web servers), and a Job +manages Pods that are expected to terminate (e.g. batch tasks). + +As discussed in [Pod Lifecycle](/docs/concepts/workloads/pods/pod-lifecycle/), `Job` is *only* appropriate +for pods with `RestartPolicy` equal to `OnFailure` or `Never`. +(Note: If `RestartPolicy` is not set, the default value is `Always`.) +--> +### 副本控制器 {#replication-controller} + +Job 与[副本控制器](/docs/user-guide/replication-controller)是彼此互补的。 +副本控制器管理的是那些不希望被终止的 Pod （例如，Web 服务器）， +Job 管理的是那些希望被终止的 Pod（例如，批处理作业）。 + +正如在 [Pod 生命期](/zh/docs/concepts/workloads/pods/pod-lifecycle/) 中讨论的， +`Job` 仅适合于 `restartPolicy` 设置为 `OnFailure` 或 `Never` 的 Pod。 +注意：如果 `restartPolicy` 未设置，其默认值是 `Always`。 + +<!-- +### Single Job starts controller Pod + +Another pattern is for a single Job to create a Pod which then creates other Pods, acting as a sort +of custom controller for those Pods. This allows the most flexibility, but may be somewhat +complicated to get started with and offers less integration with Kubernetes. +--> +### 单个 Job 启动控制器 Pod + +另一种模式是用唯一的 Job 来创建 Pod，而该 Pod 负责启动其他 Pod，因此扮演了一种 +后启动 Pod 的控制器的角色。 +这种模式的灵活性更高，但是有时候可能会把事情搞得很复杂，很难入门， +并且与 Kubernetes 的集成度很低。 + +<!-- +One example of this pattern would be a Job which starts a Pod which runs a script that in turn +starts a Spark master controller (see [spark example](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/staging/spark/README.md)), runs a spark +driver, and then cleans up. + +An advantage of this approach is that the overall process gets the completion guarantee of a Job +object, but maintains complete control over what Pods are created and how work is assigned to them. +--> +这种模式的实例之一是用 Job 来启动一个运行脚本的 Pod，脚本负责启动 Spark +主控制器（参见 [Spark 示例](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/staging/spark/README.md)）， +运行 Spark 驱动，之后完成清理工作。 + +这种方法的优点之一是整个过程得到了 Job 对象的完成保障， +同时维持了对创建哪些 Pod、如何向其分派工作的完全控制能力， + +<!-- +## Cron Jobs {#cron-jobs} + +You can use a [`CronJob`](/docs/concepts/workloads/controllers/cron-jobs/) to create a Job that will run at specified times/dates, similar to the Unix tool `cron`. +--> +## Cron Jobs {#cron-jobs} + +你可以使用 [`CronJob`](/zh/docs/concepts/workloads/controllers/cron-jobs/) +创建一个在指定时间/日期运行的 Job，类似于 UNIX 系统上的 `cron` 工具。 + diff --git a/content/zh/docs/concepts/workloads/controllers/replicaset.md b/content/zh/docs/concepts/workloads/controllers/replicaset.md index 962b7dfc0b..76e06b6490 100644 --- a/content/zh/docs/concepts/workloads/controllers/replicaset.md +++ b/content/zh/docs/concepts/workloads/controllers/replicaset.md @@ -1,8 +1,4 @@ --- -reviewers: -- Kashomon -- bprashanth -- madhusudancs title: ReplicaSet content_type: concept weight: 10 @@ -11,19 +7,59 @@ weight: 10 <!-- overview --> <!-- -ReplicaSet is the next-generation Replication Controller. The only difference -between a _ReplicaSet_ and a -[_Replication Controller_](/docs/concepts/workloads/controllers/replicationcontroller/) right now is -the selector support. ReplicaSet supports the new set-based selector requirements -as described in the [labels user guide](/docs/concepts/overview/working-with-objects/labels/#label-selectors) -whereas a Replication Controller only supports equality-based selector requirements. +A ReplicaSet's purpose is to maintain a stable set of replica Pods running at any given time. As such, it is often +used to guarantee the availability of a specified number of identical Pods. --> -ReplicaSet 是下一代的 Replication Controller。 _ReplicaSet_ 和 [_Replication Controller_](/docs/concepts/workloads/controllers/replicationcontroller/) 的唯一区别是选择器的支持。ReplicaSet 支持新的基于集合的选择器需求，这在[标签用户指南](/docs/concepts/overview/working-with-objects/labels/#label-selectors)中有描述。而 Replication Controller 仅支持基于相等选择器的需求。 - - +ReplicaSet 的目的是维护一组在任何时候都处于运行状态的 Pod 副本的稳定集合。 +因此，它通常用来保证给定数量的、完全相同的 Pod 的可用性。 <!-- body --> +<!-- +## How a ReplicaSet works + +A ReplicaSet is defined with fields, including a selector that specifies how +to identify Pods it can acquire, a number of replicas indicating how many Pods +it should be maintaining, and a pod template specifying the data of new Pods +it should create to meet the number of replicas criteria. A ReplicaSet then +fulfills its purpose by creating and deleting Pods as needed to reach the +desired number. When a ReplicaSet needs to create new Pods, it uses its Pod +template. +--> +## ReplicaSet 的工作原理 {#how-a-replicaset-works} + +RepicaSet 是通过一组字段来定义的，包括一个用来识别可获得的 Pod +的集合的选择算符，一个用来标明应该维护的副本个数的数值，一个用来指定应该创建新 Pod +以满足副本个数条件时要使用的 Pod 模板等等。每个 ReplicaSet 都通过根据需要创建和 +删除 Pod 以使得副本个数达到期望值，进而实现其存在价值。当 ReplicaSet 需要创建 +新的 Pod 时，会使用所提供的 Pod 模板。 + +<!-- +A ReplicaSet is linked to its Pods via the Pods' +[metadata.ownerReferences](/docs/concepts/workloads/controllers/garbage-collection/#owners-and-dependents) +field, which specifies what resource the current object is owned by. All Pods +acquired by a ReplicaSet have their owning ReplicaSet's identifying +information within their ownerReferences field. It's through this link that +the ReplicaSet knows of the state of the Pods it is maintaining and plans +accordingly. +--> +ReplicaSet 通过 Pod 上的 +[metadata.ownerReferences](/zh/docs/concepts/workloads/controllers/garbage-collection/#owners-and-dependents) +字段连接到附属 Pod，该字段给出当前对象的属主资源。 +ReplicaSet 所获得的 Pod 都在其 ownerReferences 字段中包含了属主 ReplicaSet +的标识信息。正是通过这一连接，ReplicaSet 知道它所维护的 Pod 集合的状态， +并据此计划其操作行为。 + +<!-- +A ReplicaSet identifies new Pods to acquire by using its selector. If there is +a Pod that has no OwnerReference or the OwnerReference is not a {{< +glossary_tooltip term_id="controller" >}} and it matches a ReplicaSet's +selector, it will be immediately acquired by said ReplicaSet. +--> +ReplicaSet 使用其选择算符来辨识要获得的 Pod 集合。如果某个 Pod 没有 +OwnerReference 或者其 OwnerReference 不是一个 +{{< glossary_tooltip text="控制器" term_id="controller" >}}，且其匹配到 +某 ReplicaSet 的选择算符，则该 Pod 立即被此 ReplicaSet 获得。 <!-- ## How to use a ReplicaSet @@ -43,8 +79,7 @@ creation, deletion and updates. When you use Deployments you don't have to worry about managing the ReplicaSets that they create. Deployments own and manage their ReplicaSets. --> - -## 怎样使用 ReplicaSet +## 怎样使用 ReplicaSet {#how-to-use-a-replicaset} 大多数支持 Replication Controllers 的[`kubectl`](/docs/user-guide/kubectl/)命令也支持 ReplicaSets。但[`rolling-update`](/docs/reference/generated/kubectl/kubectl-commands#rolling-update) 命令是个例外。如果您想要滚动更新功能请考虑使用 Deployment。[`rolling-update`](/docs/reference/generated/kubectl/kubectl-commands#rolling-update) 命令是必需的，而 Deployment 是声明性的，因此我们建议通过 [`rollout`](/docs/reference/generated/kubectl/kubectl-commands#rollout)命令使用 Deployment。 diff --git a/content/zh/docs/concepts/workloads/controllers/replicationcontroller.md b/content/zh/docs/concepts/workloads/controllers/replicationcontroller.md index e5b8b0941a..b719c0661f 100644 --- a/content/zh/docs/concepts/workloads/controllers/replicationcontroller.md +++ b/content/zh/docs/concepts/workloads/controllers/replicationcontroller.md @@ -31,7 +31,8 @@ weight: 20 A [`Deployment`](/docs/concepts/workloads/controllers/deployment/) that configures a [`ReplicaSet`](/docs/concepts/workloads/controllers/replicaset/) is now the recommended way to set up replication. --> {{< note >}} -现在推荐使用配置 [`ReplicaSet`](/docs/concepts/workloads/controllers/replicaset/) 的 [`Deployment`](/docs/concepts/workloads/controllers/deployment/) 来建立副本管理机制。 +现在推荐使用配置 [`ReplicaSet`](/zh/docs/concepts/workloads/controllers/replicaset/) 的 +[`Deployment`](/zh/docs/concepts/workloads/controllers/deployment/) 来建立副本管理机制。 {{< /note >}} <!-- @@ -39,19 +40,14 @@ A _ReplicationController_ ensures that a specified number of pod replicas are ru time. In other words, a ReplicationController makes sure that a pod or a homogeneous set of pods is always up and available. --> -_ReplicationController_ 确保在任何时候都有特定数量的 pod 副本处于运行状态。 -换句话说，ReplicationController 确保一个 pod 或一组同类的 pod 总是可用的。 - - +_ReplicationController_ 确保在任何时候都有特定数量的 Pod 副本处于运行状态。 +换句话说，ReplicationController 确保一个 Pod 或一组同类的 Pod 总是可用的。 <!-- body --> <!-- ## How a ReplicationController Works ---> -## ReplicationController 如何工作 -<!-- If there are too many pods, the ReplicationController terminates the extra pods. If there are too few, the ReplicationController starts more pods. Unlike manually created pods, the pods maintained by a ReplicationController are automatically replaced if they fail, are deleted, or are terminated. @@ -61,11 +57,13 @@ only a single pod. A ReplicationController is similar to a process supervisor, but instead of supervising individual processes on a single node, the ReplicationController supervises multiple pods across multiple nodes. --> -当 pod 数量过多时，ReplicationController 会终止多余的 pod。当 pod 数量太少时，ReplicationController 将会启动新的 pod。 -与手动创建的 pod 不同，由 ReplicationController 创建的 pod 在失败、被删除或被终止时会被自动替换。 -例如，在中断性维护（如内核升级）之后，您的 pod 会在节点上重新创建。 -因此，即使您的应用程序只需要一个 pod，您也应该使用 ReplicationController 创建 Pod。 -ReplicationController 类似于进程管理器，但是 ReplicationController 不是监控单个节点上的单个进程，而是监控跨多个节点的多个 pod。 +## ReplicationController 如何工作 + +当 Pod 数量过多时，ReplicationController 会终止多余的 Pod。当 Pod 数量太少时，ReplicationController 将会启动新的 Pod。 +与手动创建的 Pod 不同，由 ReplicationController 创建的 Pod 在失败、被删除或被终止时会被自动替换。 +例如，在中断性维护（如内核升级）之后，你的 Pod 会在节点上重新创建。 +因此，即使你的应用程序只需要一个 Pod，你也应该使用 ReplicationController 创建 Pod。 +ReplicationController 类似于进程管理器，但是 ReplicationController 不是监控单个节点上的单个进程，而是监控跨多个节点的多个 Pod。 <!-- ReplicationController is often abbreviated to "rc" in discussion, and as a shortcut in @@ -87,7 +85,7 @@ This example ReplicationController config runs three copies of the nginx web ser --> ## 运行一个示例 ReplicationController -这个示例 ReplicationController 配置运行 nginx web 服务器的三个副本。 +这个示例 ReplicationController 配置运行 nginx Web 服务器的三个副本。 {{< codenew file="controllers/replication.yaml" >}} @@ -143,19 +141,20 @@ A little later, the same command may show: 在这里，创建了三个 Pod，但没有一个 Pod 正在运行，这可能是因为正在拉取镜像。 稍后，相同的命令可能会显示： -```shell +``` Pods Status: 3 Running / 0 Waiting / 0 Succeeded / 0 Failed ``` <!-- To list all the pods that belong to the ReplicationController in a machine readable form, you can use a command like this: --> -要以机器可读的形式列出属于 ReplicationController 的所有 pod，可以使用如下命令： +要以机器可读的形式列出属于 ReplicationController 的所有 Pod，可以使用如下命令： ```shell pods=$(kubectl get pods --selector=app=nginx --output=jsonpath={.items..metadata.name}) echo $pods ``` + ``` nginx-3ntk0 nginx-4ok8v nginx-qrm3m ``` @@ -165,8 +164,8 @@ Here, the selector is the same as the selector for the ReplicationController (se `kubectl describe` output), and in a different form in `replication.yaml`. The `--output=jsonpath` option specifies an expression that just gets the name from each pod in the returned list. --> -这里，选择器与 ReplicationController 的选择器相同（参见 `kubectl describe` 输出），并以不同的形式出现在 `replication.yaml` 中。 -`--output=jsonpath` 选项指定了一个表达式，只从返回列表中的每个 pod 中获取名称。 +这里，选择算符与 ReplicationController 的选择算符相同（参见 `kubectl describe` 输出），并以不同的形式出现在 `replication.yaml` 中。 +`--output=jsonpath` 选项指定了一个表达式，只从返回列表中的每个 Pod 中获取名称。 <!-- ## Writing a ReplicationController Spec @@ -179,23 +178,23 @@ A ReplicationController also needs a [`.spec` section](https://git.k8s.io/commun ## 编写一个 ReplicationController Spec 与所有其它 Kubernetes 配置一样，ReplicationController 需要 `apiVersion`、`kind` 和 `metadata` 字段。 -有关使用配置文件的常规信息，参考[对象管理](/docs/concepts/overview/working-with-objects/object-management/)。 +有关使用配置文件的常规信息，参考[对象管理](/zh/docs/concepts/overview/working-with-objects/object-management/)。 ReplicationController 也需要一个 [`.spec` 部分](https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status)。 <!-- ### Pod Template ---> -### Pod 模板 -<!-- The `.spec.template` is the only required field of the `.spec`. The `.spec.template` is a [pod template](/docs/concepts/workloads/pods/pod-overview/#pod-templates). It has exactly the same schema as a [pod](/docs/concepts/workloads/pods/pod/), except it is nested and does not have an `apiVersion` or `kind`. --> +### Pod 模板 {#pod-template} + `.spec.template` 是 `.spec` 的唯一必需字段。 -`.spec.template` 是一个 [pod 模板](/docs/concepts/workloads/pods/pod-overview/#pod-templates)。它的模式与 [pod](/docs/concepts/workloads/pods/pod/) 完全相同，只是它是嵌套的，没有 `apiVersion` 或 `kind` 属性。 +`.spec.template` 是一个 [Pod 模板](/zh/docs/concepts/workloads/pods/#pod-templates)。 +它的模式与 [Pod](/zh/docs/concepts/workloads/pods/) 完全相同，只是它是嵌套的，没有 `apiVersion` 或 `kind` 属性。 <!-- In addition to required fields for a Pod, a pod template in a ReplicationController must specify appropriate @@ -206,13 +205,13 @@ Only a [`.spec.template.spec.restartPolicy`](/docs/concepts/workloads/pods/pod-l For local container restarts, ReplicationControllers delegate to an agent on the node, for example the [Kubelet](/docs/admin/kubelet/) or Docker. --> -除了 Pod 所需的字段外，ReplicationController 中的 pod 模板必须指定适当的标签和适当的重新启动策略。 -对于标签，请确保不与其他控制器重叠。参考 [pod 选择器](#pod-selector)。 +除了 Pod 所需的字段外，ReplicationController 中的 Pod 模板必须指定适当的标签和适当的重新启动策略。 +对于标签，请确保不与其他控制器重叠。参考 [Pod 选择算符](#pod-selector)。 -只允许 [`.spec.template.spec.restartPolicy`](/docs/concepts/workloads/pods/pod-lifecycle/#restart-policy) 等于 `Always`，如果没有指定，这是默认值。 +只允许 [`.spec.template.spec.restartPolicy`](/zh/docs/concepts/workloads/pods/pod-lifecycle/#restart-policy) 等于 `Always`，如果没有指定，这是默认值。 对于本地容器重启，ReplicationController 委托给节点上的代理， -例如 [Kubelet](/docs/admin/kubelet/) 或 Docker。 +例如 [Kubelet](/docs/reference/command-line-toolls-reference/kubelet/) 或 Docker。 <!-- ### Labels on the ReplicationController @@ -225,23 +224,22 @@ different, and the `.metadata.labels` do not affect the behavior of the Replicat ### ReplicationController 上的标签 ReplicationController 本身可以有标签 （`.metadata.labels`）。 -通常，您可以将这些设置为 `.spec.template.metadata.labels`； +通常，你可以将这些设置为 `.spec.template.metadata.labels`； 如果没有指定 `.metadata.labels` 那么它默认为 `.spec.template.metadata.labels`。 但是，Kubernetes 允许它们是不同的，`.metadata.labels` 不会影响 ReplicationController 的行为。 <!-- ### Pod Selector ---> -### Pod 选择器 {#pod-selector} -<!-- The `.spec.selector` field is a [label selector](/docs/concepts/overview/working-with-objects/labels/#label-selectors). A ReplicationController manages all the pods with labels that match the selector. It does not distinguish between pods that it created or deleted and pods that another person or process created or deleted. This allows the ReplicationController to be replaced without affecting the running pods. --> -`.spec.selector` 字段是一个[标签选择器](/docs/concepts/overview/working-with-objects/labels/#label-selectors)。 -ReplicationController 管理标签与选择器匹配的所有 Pod。 +### Pod 选择算符 {#pod-selector} + +`.spec.selector` 字段是一个[标签选择算符](/zh/docs/concepts/overview/working-with-objects/labels/#label-selectors)。 +ReplicationController 管理标签与选择算符匹配的所有 Pod。 它不区分它创建或删除的 Pod 和其他人或进程创建或删除的 Pod。 这允许在不影响正在运行的 Pod 的情况下替换 ReplicationController。 @@ -262,10 +260,11 @@ from doing this. If you do end up with multiple controllers that have overlapping selectors, you will have to manage the deletion yourself (see [below](#working-with-replicationcontrollers)). --> -另外，通常不应直接使用另一个 ReplicationController 或另一个控制器（例如 Job）来创建其标签与该选择器匹配的任何 Pod。如果这样做，ReplicationController 会认为它创建了这些 Pod。 +另外，通常不应直接使用另一个 ReplicationController 或另一个控制器（例如 Job） +来创建其标签与该选择算符匹配的任何 Pod。如果这样做，ReplicationController 会认为它创建了这些 Pod。 Kubernetes 并没有阻止你这样做。 -如果您的确创建了多个控制器并且其选择器之间存在重叠，那么您将不得不自己管理删除操作（参考[后文](#working-with-replicationcontrollers)）。 +如果你的确创建了多个控制器并且其选择算符之间存在重叠，那么你将不得不自己管理删除操作（参考[后文](#working-with-replicationcontrollers)）。 <!-- ### Multiple Replicas @@ -280,16 +279,13 @@ If you do not specify `.spec.replicas`, then it defaults to 1. ### 多个副本 你可以通过设置 `.spec.replicas` 来指定应该同时运行多少个 Pod。 -在任何时候，处于运行状态的 Pod 个数都可能高于或者低于设定值。例如，副本个数刚刚被增加或减少时，或者一个 pod 处于优雅终止过程中而其替代副本已经提前开始创建时。 +在任何时候，处于运行状态的 Pod 个数都可能高于或者低于设定值。例如，副本个数刚刚被增加或减少时，或者一个 Pod 处于优雅终止过程中而其替代副本已经提前开始创建时。 如果你没有指定 `.spec.replicas` ，那么它默认是 1。 <!-- ## Working with ReplicationControllers ---> -## 使用 ReplicationController {#working-with-replicationcontrollers} -<!-- ### Deleting a ReplicationController and its Pods To delete a ReplicationController and all its pods, use [`kubectl @@ -300,31 +296,33 @@ command is interrupted, it can be restarted. When using the REST API or go client library, you need to do the steps explicitly (scale replicas to 0, wait for pod deletions, then delete the ReplicationController). --> +## 使用 ReplicationController {#working-with-replicationcontrollers} + ### 删除一个 ReplicationController 以及它的 Pod -要删除一个 ReplicationController 以及它的 Pod，使用 [`kubectl delete`](/docs/reference/generated/kubectl/kubectl-commands#delete)。 +要删除一个 ReplicationController 以及它的 Pod，使用 +[`kubectl delete`](/docs/reference/generated/kubectl/kubectl-commands#delete)。 kubectl 将 ReplicationController 缩放为 0 并等待以便在删除 ReplicationController 本身之前删除每个 Pod。 如果这个 kubectl 命令被中断，可以重新启动它。 -当使用 REST API 或 go 客户端库时，您需要明确地执行这些步骤（缩放副本为 0、 等待 Pod 删除，之后删除 ReplicationController 资源）。 +当使用 REST API 或 go 客户端库时，你需要明确地执行这些步骤（缩放副本为 0、 等待 Pod 删除，之后删除 ReplicationController 资源）。 <!-- ### Deleting just a ReplicationController ---> -### 只删除 ReplicationController -<!-- You can delete a ReplicationController without affecting any of its pods. Using kubectl, specify the `--cascade=false` option to [`kubectl delete`](/docs/reference/generated/kubectl/kubectl-commands#delete). When using the REST API or go client library, simply delete the ReplicationController object. --> -你可以删除一个 ReplicationController 而不影响它的任何 pod。 +### 只删除 ReplicationController -使用 kubectl ，为 [`kubectl delete`](/docs/reference/generated/kubectl/kubectl-commands#delete) 指定 `--cascade=false` 选项。 +你可以删除一个 ReplicationController 而不影响它的任何 Pod。 -当使用 REST API 或 go 客户端库时， 只需删除 ReplicationController 对象。 +使用 kubectl，为 [`kubectl delete`](/docs/reference/generated/kubectl/kubectl-commands#delete) 指定 `--cascade=false` 选项。 + +当使用 REST API 或 go 客户端库时，只需删除 ReplicationController 对象。 <!-- Once the original is deleted, you can create a new ReplicationController to replace it. As long @@ -342,10 +340,10 @@ To update pods to a new spec in a controlled way, use a [rolling update](#rollin Pods may be removed from a ReplicationController's target set by changing their labels. This technique may be used to remove pods from service for debugging, data recovery, etc. Pods that are removed in this way will be replaced automatically (assuming that the number of replicas is not also changed). --> -### 从 ReplicationController 中隔离 pod +### 从 ReplicationController 中隔离 Pod -通过更改 Pod 的标签，可以从 ReplicationController 的目标中删除 pod。 -此技术可用于从服务中删除 pod 以进行调试、数据恢复等。以这种方式删除的 pod 将自动替换（假设复制副本的数量也没有更改）。 +通过更改 Pod 的标签，可以从 ReplicationController 的目标中删除 Pod。 +此技术可用于从服务中删除 Pod 以进行调试、数据恢复等。以这种方式删除的 Pod 将自动替换（假设复制副本的数量也没有更改）。 <!-- ## Common usage patterns @@ -357,31 +355,32 @@ Pods may be removed from a ReplicationController's target set by changing their As mentioned above, whether you have 1 pod you want to keep running, or 1000, a ReplicationController will ensure that the specified number of pods exists, even in the event of node failure or pod termination (for example, due to an action by another control agent). --> -### 重新调度 +### 重新调度 {#rescheduling} -如上所述，无论您想要继续运行 1 个 pod 还是 1000 个 Pod，一个 ReplicationController 都将确保存在指定数量的 pod，即使在节点故障或 pod 终止(例如，由于另一个控制代理的操作)的情况下也是如此。 +如上所述，无论你想要继续运行 1 个 Pod 还是 1000 个 Pod，一个 ReplicationController 都将确保存在指定数量的 Pod，即使在节点故障或 Pod 终止(例如，由于另一个控制代理的操作)的情况下也是如此。 <!-- ### Scaling The ReplicationController makes it easy to scale the number of replicas up or down, either manually or by an auto-scaling control agent, by simply updating the `replicas` field. --> -### 扩缩容 +### 扩缩容 {#scaling} 通过简单地更新 `replicas` 字段，ReplicationController 可以方便地横向扩容或缩容副本的数量，或手动或通过自动缩放控制代理。 <!-- ### Rolling updates ---> -### 滚动更新 {#rolling-updates} -<!-- The ReplicationController is designed to facilitate rolling updates to a service by replacing pods one-by-one. As explained in [#1353](http://issue.k8s.io/1353), the recommended approach is to create a new ReplicationController with 1 replica, scale the new (+1) and old (-1) controllers one by one, and then delete the old controller after it reaches 0 replicas. This predictably updates the set of pods regardless of unexpected failures. --> -ReplicationController 的设计目的是通过逐个替换 pod 以方便滚动更新服务。 +### 滚动更新 {#rolling-updates} -如 [#1353](http://issue.k8s.io/1353) PR 中所述，建议的方法是使用 1 个副本创建一个新的 ReplicationController，逐个缩放新的（+1）和旧的（-1）控制器，然后在旧的控制器达到 0 个副本后将其删除。这一方法能够实现可控的 Pod 集合更新，即使存在意外失效的状况。 +ReplicationController 的设计目的是通过逐个替换 Pod 以方便滚动更新服务。 + +如 [#1353](https://issue.k8s.io/1353) PR 中所述，建议的方法是使用 1 个副本创建一个新的 ReplicationController， +逐个扩容新的（+1）和缩容旧的（-1）控制器，然后在旧的控制器达到 0 个副本后将其删除。 +这一方法能够实现可控的 Pod 集合更新，即使存在意外失效的状况。 <!-- Ideally, the rolling update controller would take application readiness into account, and would ensure that a sufficient number of pods were productively serving at any given time. @@ -393,26 +392,29 @@ Rolling update is implemented in the client tool --> 理想情况下，滚动更新控制器将考虑应用程序的就绪情况，并确保在任何给定时间都有足够数量的 Pod 有效地提供服务。 -这两个 ReplicationController 将需要创建至少具有一个不同标签的 pod，比如 pod 主要容器的镜像标签，因为通常是镜像更新触发滚动更新。 +这两个 ReplicationController 将需要创建至少具有一个不同标签的 Pod，比如 Pod 主要容器的镜像标签，因为通常是镜像更新触发滚动更新。 -滚动更新是在客户端工具 [`kubectl rolling-update`](/docs/reference/generated/kubectl/kubectl-commands#rolling-update) 中实现的。 访问 [`kubectl rolling-update` 任务](/docs/tasks/run-application/rolling-update-replication-controller/)以获得更多的具体示例。 +滚动更新是在客户端工具 [`kubectl rolling-update`](/docs/reference/generated/kubectl/kubectl-commands#rolling-update) +中实现的。访问 [`kubectl rolling-update` 任务](/zh/docs/tasks/run-application/rolling-update-replication-controller/)以获得更多的具体示例。 <!-- ### Multiple release tracks ---> -### 多个版本跟踪 -<!-- In addition to running multiple releases of an application while a rolling update is in progress, it's common to run multiple releases for an extended period of time, or even continuously, using multiple release tracks. The tracks would be differentiated by labels. For instance, a service might target all pods with `tier in (frontend), environment in (prod)`. Now say you have 10 replicated pods that make up this tier. But you want to be able to 'canary' a new version of this component. You could set up a ReplicationController with `replicas` set to 9 for the bulk of the replicas, with labels `tier=frontend, environment=prod, track=stable`, and another ReplicationController with `replicas` set to 1 for the canary, with labels `tier=frontend, environment=prod, track=canary`. Now the service is covering both the canary and non-canary pods. But you can mess with the ReplicationControllers separately to test things out, monitor the results, etc. --> +### 多个版本跟踪 + 除了在滚动更新过程中运行应用程序的多个版本之外，通常还会使用多个版本跟踪来长时间，甚至持续运行多个版本。这些跟踪将根据标签加以区分。 -例如，一个服务可能把具有 `tier in (frontend), environment in (prod)` 的所有 pod 作为目标。 -现在假设您有 10 个副本的 pod 组成了这个层。但是你希望能够 `canary` （`金丝雀`）发布这个组件的新版本。 -您可以为大部分副本设置一个 ReplicationController，其中 `replicas` 设置为 9，标签为 `tier=frontend, environment=prod, track=stable` 而为 `canary` 设置另一个 ReplicationController，其中 `replicas` 设置为 1，标签为 `tier=frontend, environment=prod, track=canary`。 -现在这个服务覆盖了 `canary` 和非 `canary` Pod。但您可以单独处理 ReplicationController，以测试、监控结果等。 +例如，一个服务可能把具有 `tier in (frontend), environment in (prod)` 的所有 Pod 作为目标。 +现在假设你有 10 个副本的 Pod 组成了这个层。但是你希望能够 `canary` （`金丝雀`）发布这个组件的新版本。 +你可以为大部分副本设置一个 ReplicationController，其中 `replicas` 设置为 9， +标签为 `tier=frontend, environment=prod, track=stable` 而为 `canary` +设置另一个 ReplicationController，其中 `replicas` 设置为 1， +标签为 `tier=frontend, environment=prod, track=canary`。 +现在这个服务覆盖了 `canary` 和非 `canary` Pod。但你可以单独处理 ReplicationController，以测试、监控结果等。 <!-- ### Using ReplicationControllers with Services @@ -427,7 +429,8 @@ A ReplicationController will never terminate on its own, but it isn't expected t 多个 ReplicationController 可以位于一个服务的后面，例如，一部分流量流向旧版本，一部分流量流向新版本。 一个 ReplicationController 永远不会自行终止，但它不会像服务那样长时间存活。 -服务可以由多个 ReplicationController 控制的 Pod 组成，并且在服务的生命周期内（例如，为了执行 pod 更新而运行服务），可以创建和销毁许多 ReplicationController。 +服务可以由多个 ReplicationController 控制的 Pod 组成，并且在服务的生命周期内 +（例如，为了执行 Pod 更新而运行服务），可以创建和销毁许多 ReplicationController。 服务本身和它们的客户端都应该忽略负责维护服务 Pod 的 ReplicationController 的存在。 <!-- @@ -439,31 +442,35 @@ Pods created by a ReplicationController are intended to be fungible and semantic 由 ReplicationController 创建的 Pod 是可替换的，语义上是相同的，尽管随着时间的推移，它们的配置可能会变得异构。 这显然适合于多副本的无状态服务器，但是 ReplicationController 也可以用于维护主选、分片和工作池应用程序的可用性。 -这样的应用程序应该使用动态的工作分配机制，例如 [RabbitMQ 工作队列](https://www.rabbitmq.com/tutorials/tutorial-two-python.html)，而不是静态的或者一次性定制每个 pod 的配置，这被认为是一种反模式。 -执行的任何 pod 定制，例如资源的垂直自动调整大小(例如，cpu 或内存)，都应该由另一个在线控制器进程执行，这与 ReplicationController 本身没什么不同。 +这样的应用程序应该使用动态的工作分配机制，例如 +[RabbitMQ 工作队列](https://www.rabbitmq.com/tutorials/tutorial-two-python.html)， +而不是静态的或者一次性定制每个 Pod 的配置，这被认为是一种反模式。 +执行的任何 Pod 定制，例如资源的垂直自动调整大小（例如，CPU 或内存）， +都应该由另一个在线控制器进程执行，这与 ReplicationController 本身没什么不同。 <!-- ## Responsibilities of the ReplicationController + +The ReplicationController simply ensures that the desired number of pods matches its label selector and are operational. Currently, only terminated pods are excluded from its count. In the future, [readiness](http://issue.k8s.io/620) and other information available from the system may be taken into account, we may add more controls over the replacement policy, and we plan to emit events that could be used by external clients to implement arbitrarily sophisticated replacement and/or scale-down policies. --> ## ReplicationController 的职责 -<!-- -The ReplicationController simply ensures that the desired number of pods matches its label selector and are operational. Currently, only terminated pods are excluded from its count. In the future, [readiness](http://issue.k8s.io/620) and other information available from the system may be taken into account, we may add more controls over the replacement policy, and we plan to emit events that could be used by external clients to implement arbitrarily sophisticated replacement and/or scale-down policies. ---> -ReplicationController 只需确保所需的 pod 数量与其标签选择器匹配，并且是可操作的。 -目前，它的计数中只排除终止的 pod。 -未来，可能会考虑系统提供的[就绪状态](http://issue.k8s.io/620)和其他信息，我们可能会对替换策略添加更多控制，我们计划发出事件，这些事件可以被外部客户端用来实现任意复杂的替换和/或缩减策略。 +ReplicationController 只需确保所需的 Pod 数量与其标签选择算符匹配，并且是可操作的。 +目前，它的计数中只排除终止的 Pod。 +未来，可能会考虑系统提供的[就绪状态](https://issue.k8s.io/620)和其他信息， +我们可能会对替换策略添加更多控制， +我们计划发出事件，这些事件可以被外部客户端用来实现任意复杂的替换和/或缩减策略。 <!-- The ReplicationController is forever constrained to this narrow responsibility. It itself will not perform readiness nor liveness probes. Rather than performing auto-scaling, it is intended to be controlled by an external auto-scaler (as discussed in [#492](http://issue.k8s.io/492)), which would change its `replicas` field. We will not add scheduling policies (for example, [spreading](http://issue.k8s.io/367#issuecomment-48428019)) to the ReplicationController. Nor should it verify that the pods controlled match the currently specified template, as that would obstruct auto-sizing and other automated processes. Similarly, completion deadlines, ordering dependencies, configuration expansion, and other features belong elsewhere. We even plan to factor out the mechanism for bulk pod creation ([#170](http://issue.k8s.io/170)). --> ReplicationController 永远被限制在这个狭隘的职责范围内。 它本身既不执行就绪态探测，也不执行活跃性探测。 -它不负责执行自动缩放，而是由外部自动缩放器控制（如 [#492](http://issue.k8s.io/492) 中所述），后者负责更改其 `replicas` 字段值。 -我们不会向 ReplicationController 添加调度策略(例如，[spreading](http://issue.k8s.io/367#issuecomment-48428019))。 -它也不应该验证所控制的 pod 是否与当前指定的模板匹配，因为这会阻碍自动调整大小和其他自动化过程。 +它不负责执行自动缩放，而是由外部自动缩放器控制（如 [#492](https://issue.k8s.io/492) 中所述），后者负责更改其 `replicas` 字段值。 +我们不会向 ReplicationController 添加调度策略(例如，[spreading](https://issue.k8s.io/367#issuecomment-48428019))。 +它也不应该验证所控制的 Pod 是否与当前指定的模板匹配，因为这会阻碍自动调整大小和其他自动化过程。 类似地，完成期限、整理依赖关系、配置扩展和其他特性也属于其他地方。 -我们甚至计划考虑批量创建 pod 的机制（查阅 [#170](http://issue.k8s.io/170)）。 +我们甚至计划考虑批量创建 Pod 的机制（查阅 [#170](https://issue.k8s.io/170)）。 <!-- The ReplicationController is intended to be a composable building-block primitive. We expect higher-level APIs and/or tools to be built on top of it and other complementary primitives for user convenience in the future. The "macro" operations currently supported by kubectl (run, scale, rolling-update) are proof-of-concept examples of this. For instance, we could imagine something like [Asgard](http://techblog.netflix.com/2012/06/asgard-web-based-cloud-management-and.html) managing ReplicationControllers, auto-scalers, services, scheduling policies, canaries, etc. @@ -471,7 +478,8 @@ The ReplicationController is intended to be a composable building-block primitiv ReplicationController 旨在成为可组合的构建基元。 我们希望在它和其他补充原语的基础上构建更高级别的 API 或者工具，以便于将来的用户使用。 kubectl 目前支持的 "macro" 操作（运行、缩放、滚动更新）就是这方面的概念示例。 -例如，我们可以想象类似于 [Asgard](http://techblog.netflix.com/2012/06/asgaard-web-based-cloud-management-and.html) 的东西管理 ReplicationController、自动定标器、服务、调度策略、 canary 等。 +例如，我们可以想象类似于 [Asgard](https://techblog.netflix.com/2012/06/asgaard-web-based-cloud-management-and.html) +的东西管理 ReplicationController、自动定标器、服务、调度策略、金丝雀发布等。 <!-- ## API Object @@ -488,21 +496,20 @@ API object can be found at: <!-- ## Alternatives to ReplicationController ---> -## ReplicationController 的替代方案 - -<!-- ### ReplicaSet [`ReplicaSet`](/docs/concepts/workloads/controllers/replicaset/) is the next-generation ReplicationController that supports the new [set-based label selector](/docs/concepts/overview/working-with-objects/labels/#set-based-requirement). -It’s mainly used by [`Deployment`](/docs/concepts/workloads/controllers/deployment/) as a mechanism to orchestrate pod creation, deletion and updates. +It’s mainly used by [`Deployment`](/docs/concepts/workloads/controllers/deployment/) as a mechanism to orchestrate Pod creation, deletion and updates. Note that we recommend using Deployments instead of directly using Replica Sets, unless you require custom update orchestration or don’t require updates at all. --> +## ReplicationController 的替代方案 + ### ReplicaSet -[`ReplicaSet`](/docs/concepts/workloads/controllers/replicaset/) 是下一代 ReplicationController ，支持新的[基于集合的标签选择器](/docs/concepts/overview/working-with-objects/labels/#set-based-requirement)。 -它主要被 [`Deployment`](/docs/concepts/workloads/controllers/deployment/) 用来作为一种编排 pod 创建、删除及更新的机制。 -请注意，我们推荐使用 Deployment 而不是直接使用 ReplicaSet，除非您需要自定义更新编排或根本不需要更新。 +[`ReplicaSet`](/zh/docs/concepts/workloads/controllers/replicaset/) 是下一代 ReplicationController， +支持新的[基于集合的标签选择算符](/zh/docs/concepts/overview/working-with-objects/labels/#set-based-requirement)。 +它主要被 [`Deployment`](/zh/docs/concepts/workloads/controllers/deployment/) 用来作为一种编排 Pod 创建、删除及更新的机制。 +请注意，我们推荐使用 Deployment 而不是直接使用 ReplicaSet，除非你需要自定义更新编排或根本不需要更新。 <!-- ### Deployment (Recommended) @@ -513,8 +520,10 @@ because unlike `kubectl rolling-update`, they are declarative, server-side, and --> ### Deployment （推荐） -[`Deployment`](/docs/concepts/workloads/controllers/deployment/) 是一种更高级别的 API 对象，它以类似于 `kubectl rolling-update` 的方式更新其底层 ReplicaSet 及其 Pod。 -如果您想要这种滚动更新功能，那么推荐使用 Deployment，因为与 `kubectl rolling-update` 不同，它们是声明式的、服务端的，并且具有其它特性。 +[`Deployment`](/zh/docs/concepts/workloads/controllers/deployment/) 是一种更高级别的 API 对象， +它以类似于 `kubectl rolling-update` 的方式更新其底层 ReplicaSet 及其 Pod。 +如果你想要这种滚动更新功能，那么推荐使用 Deployment，因为与 `kubectl rolling-update` 不同， +它们是声明式的、服务端的，并且具有其它特性。 <!-- ### Bare Pods @@ -523,20 +532,21 @@ Unlike in the case where a user directly created pods, a ReplicationController r --> ### 裸 Pod -与用户直接创建 pod 的情况不同，ReplicationController 能够替换因某些原因被删除或被终止的 pod ，例如在节点故障或中断节点维护的情况下，例如内核升级。 -因此，我们建议您使用 ReplicationController，即使您的应用程序只需要一个 pod。 -可以将其看作类似于进程管理器，它只管理跨多个节点的多个 pod ，而不是单个节点上的单个进程。 +与用户直接创建 Pod 的情况不同，ReplicationController 能够替换因某些原因被删除或被终止的 Pod ，例如在节点故障或中断节点维护的情况下，例如内核升级。 +因此，我们建议你使用 ReplicationController，即使你的应用程序只需要一个 Pod。 +可以将其看作类似于进程管理器，它只管理跨多个节点的多个 Pod ，而不是单个节点上的单个进程。 ReplicationController 将本地容器重启委托给节点上的某个代理(例如，Kubelet 或 Docker)。 <!-- ### Job -Use a [`Job`](/docs/concepts/jobs/run-to-completion-finite-workloads/) instead of a ReplicationController for pods that are expected to terminate on their own +Use a [`Job`](/docs/concepts/jobs/run-to-completion-finite-workloads/) instead of a ReplicationController for Pods that are expected to terminate on their own (that is, batch jobs). --> ### Job -对于预期会自行终止的 pod (即批处理任务)，使用 [`Job`](/docs/concepts/jobs/run-to-completion-finite-workloads/) 而不是 ReplicationController。 +对于预期会自行终止的 Pod (即批处理任务)，使用 +[`Job`](/docs/concepts/workloads/controllers/job/) 而不是 ReplicationController。 <!-- ### DaemonSet @@ -548,8 +558,11 @@ safe to terminate when the machine is otherwise ready to be rebooted/shutdown. --> ### DaemonSet -对于提供机器级功能（例如机器监控或机器日志记录）的 pod ，使用 [`DaemonSet`](/docs/concepts/workloads/controllers/daemonset/) 而不是 ReplicationController。 -这些 pod 的生命期与机器的生命期绑定：它们需要在其他 pod 启动之前在机器上运行，并且在机器准备重新启动或者关闭时安全地终止。 +对于提供机器级功能（例如机器监控或机器日志记录）的 Pod， +使用 [`DaemonSet`](/zh/docs/concepts/workloads/controllers/daemonset/) 而不是 +ReplicationController。 +这些 Pod 的生命期与机器的生命期绑定：它们需要在其他 Pod 启动之前在机器上运行， +并且在机器准备重新启动或者关闭时安全地终止。 <!-- ## For more information @@ -558,6 +571,5 @@ Read [Run Stateless AP Replication Controller](/docs/tutorials/stateless-applica --> ## 更多信息 -请阅读[运行无状态的 Replication Controller](/docs/tutorials/stateless-application/run-stateless-ap-replication-controller/)。 - +请阅读[运行无状态的 ReplicationController](/zh/docs/tasks/run-application/run-stateless-application-deployment/)。 diff --git a/content/zh/docs/concepts/workloads/controllers/statefulset.md b/content/zh/docs/concepts/workloads/controllers/statefulset.md index 3a27b68dd8..955774f469 100644 --- a/content/zh/docs/concepts/workloads/controllers/statefulset.md +++ b/content/zh/docs/concepts/workloads/controllers/statefulset.md @@ -5,18 +5,9 @@ weight: 40 --- <!-- ---- -reviewers: -- enisoc -- erictune -- foxish -- janetkuo -- kow3ns -- smarterclayton title: StatefulSets content_type: concept weight: 40 ---- --> <!-- overview --> @@ -24,23 +15,20 @@ weight: 40 <!-- StatefulSet is the workload API object used to manage stateful applications. --> - StatefulSet 是用来管理有状态应用的工作负载 API 对象。 {{< glossary_definition term_id="statefulset" length="all" >}} - <!-- body --> <!-- ## Using StatefulSets ---> -## 使用 StatefulSets -<!-- StatefulSets are valuable for applications that require one or more of the following. --> +## 使用 StatefulSets + StatefulSets 对于需要满足以下一个或多个需求的应用程序很有价值： <!-- @@ -62,12 +50,12 @@ that provides a set of stateless replicas. [Deployment](/docs/concepts/workloads/controllers/deployment/) or [ReplicaSet](/docs/concepts/workloads/controllers/replicaset/) may be better suited to your stateless needs. --> -在上面，稳定意味着 Pod 调度或重调度的整个过程是有持久性的。如果应用程序不需要任何稳定的标识符或有序的部署、删除或伸缩，则应该使用由一组无状态的副本控制器提供的工作负载来部署应用程序，比如 [Deployment](/docs/concepts/workloads/controllers/deployment/) 或者 [ReplicaSet](/docs/concepts/workloads/controllers/replicaset/) 可能更适用于您的无状态应用部署需要。 +在上面，稳定意味着 Pod 调度或重调度的整个过程是有持久性的。如果应用程序不需要任何稳定的标识符或有序的部署、删除或伸缩，则应该使用由一组无状态的副本控制器提供的工作负载来部署应用程序，比如 [Deployment](/zh/docs/concepts/workloads/controllers/deployment/) 或者 [ReplicaSet](/zh/docs/concepts/workloads/controllers/replicaset/) 可能更适用于您的无状态应用部署需要。 <!-- ## Limitations --> -## 限制 +## 限制 {#limitations} <!-- * The storage for a given Pod must either be provisioned by a [PersistentVolume Provisioner](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/staging/persistent-volume-provisioning/README.md) based on the requested `storage class`, or pre-provisioned by an admin. @@ -81,7 +69,7 @@ that provides a set of stateless replicas. --> * 给定 Pod 的存储必须由 [PersistentVolume 驱动](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/staging/persistent-volume-provisioning/README.md) 基于所请求的 `storage class` 来提供，或者由管理员预先提供。 * 删除或者收缩 StatefulSet 并*不会*删除它关联的存储卷。这样做是为了保证数据安全，它通常比自动清除 StatefulSet 所有相关的资源更有价值。 -* StatefulSet 当前需要 [headless 服务](/docs/concepts/services-networking/service/#headless-services) 来负责 Pod 的网络标识。您需要负责创建此服务。 +* StatefulSet 当前需要[无头服务](/zh/docs/concepts/services-networking/service/#headless-services) 来负责 Pod 的网络标识。您需要负责创建此服务。 * 当删除 StatefulSets 时，StatefulSet 不提供任何终止 Pod 的保证。为了实现 StatefulSet 中的 Pod 可以有序和优雅的终止，可以在删除之前将 StatefulSet 缩放为 0。 * 在默认 [Pod 管理策略](#pod-management-policies)(`OrderedReady`) 时使用 [滚动更新](#rolling-updates)，可能进入需要 [人工干预](#forced-rollback) 才能修复的损坏状态。 @@ -89,7 +77,7 @@ that provides a set of stateless replicas. ## Components The example below demonstrates the components of a StatefulSet. --> -## 组件 +## 组件 {#components} 下面的示例演示了 StatefulSet 的组件。 @@ -151,12 +139,13 @@ spec: --> * 名为 `nginx` 的 Headless Service 用来控制网络域名。 * 名为 `web` 的 StatefulSet 有一个 Spec，它表明将在独立的 3 个 Pod 副本中启动 nginx 容器。 -* `volumeClaimTemplates` 将通过 PersistentVolumes 驱动提供的 [PersistentVolumes](/docs/concepts/storage/persistent-volumes/) 来提供稳定的存储。 +* `volumeClaimTemplates` 将通过 PersistentVolumes 驱动提供的 + [PersistentVolumes](/zh/docs/concepts/storage/persistent-volumes/) 来提供稳定的存储。 <!-- ## Pod Selector --> -## Pod 选择器 {#pod-selector} +## Pod 选择算符 {#pod-selector} <!-- You must set the `.spec.selector` field of a StatefulSet to match the labels of its `.spec.template.metadata.labels`. Prior to Kubernetes 1.8, the `.spec.selector` field was defaulted when omitted. In 1.8 and later versions, failing to specify a matching Pod Selector will result in a validation error during StatefulSet creation. @@ -165,33 +154,28 @@ You must set the `.spec.selector` field of a StatefulSet to match the labels of <!-- ## Pod Identity ---> -## Pod 标识 -<!-- StatefulSet Pods have a unique identity that is comprised of an ordinal, a stable network identity, and stable storage. The identity sticks to the Pod, regardless of which node it's (re)scheduled on. --> +## Pod 标识 {#pod-identity} + StatefulSet Pod 具有唯一的标识，该标识包括顺序标识、稳定的网络标识和稳定的存储。该标识和 Pod 是绑定的，不管它被调度在哪个节点上。 <!-- ### Ordinal Index ---> -### 有序索引 -<!-- For a StatefulSet with N replicas, each Pod in the StatefulSet will be assigned an integer ordinal, from 0 up through N-1, that is unique over the Set. --> +### 有序索引 {#ordinal-index} + 对于具有 N 个副本的 StatefulSet，StatefulSet 中的每个 Pod 将被分配一个整数序号，从 0 到 N-1，该序号在 StatefulSet 上是唯一的。 <!-- ### Stable Network ID ---> -### 稳定的网络 ID -<!-- Each Pod in a StatefulSet derives its hostname from the name of the StatefulSet and the ordinal of the Pod. The pattern for the constructed hostname is `$(statefulset name)-$(ordinal)`. The example above will create three Pods @@ -204,20 +188,24 @@ As each Pod is created, it gets a matching DNS subdomain, taking the form: `$(podname).$(governing service domain)`, where the governing service is defined by the `serviceName` field on the StatefulSet. --> -StatefulSet 中的每个 Pod 根据 StatefulSet 的名称和 Pod 的序号派生出它的主机名。组合主机名的格式为`$(StatefulSet 名称)-$(序号)`。上例将会创建三个名称分别为 `web-0、web-1、web-2` 的 Pod。 -StatefulSet 可以使用 [headless 服务](/docs/concepts/services-networking/service/#headless-services) 控制它的 Pod 的网络域。管理域的这个服务的格式为： +### 稳定的网络 ID {#stable-network-id} + +StatefulSet 中的每个 Pod 根据 StatefulSet 的名称和 Pod 的序号派生出它的主机名。 +组合主机名的格式为`$(StatefulSet 名称)-$(序号)`。上例将会创建三个名称分别为 `web-0、web-1、web-2` 的 Pod。 +StatefulSet 可以使用 [headless 服务](/zh/docs/concepts/services-networking/service/#headless-services) +控制它的 Pod 的网络域。管理域的这个服务的格式为： `$(服务名称).$(命名空间).svc.cluster.local`，其中 `cluster.local` 是集群域。 -一旦每个 Pod 创建成功，就会得到一个匹配的 DNS 子域，格式为：`$(pod 名称).$(所属服务的 DNS 域名)`，其中所属服务由 StatefulSet 的 `serviceName` 域来设定。 +一旦每个 Pod 创建成功，就会得到一个匹配的 DNS 子域，格式为： +`$(pod 名称).$(所属服务的 DNS 域名)`，其中所属服务由 StatefulSet 的 `serviceName` 域来设定。 <!-- Here are some examples of choices for Cluster Domain, Service name, StatefulSet name, and how that affects the DNS names for the StatefulSet's Pods. --> - 下面给出一些选择集群域、服务名、StatefulSet 名、及其怎样影响 StatefulSet 的 Pod 上的 DNS 名称的示例： -Cluster Domain | Service (ns/name) | StatefulSet (ns/name) | StatefulSet Domain | Pod DNS | Pod Hostname | --------------- | ----------------- | ----------------- | -------------- | ------- | ------------ | +集群域名 | 服务（名字空间/名字）| StatefulSet（名字空间/名字） | StatefulSet 域名 | Pod DNS | Pod 主机名 | +-------------- | -------------------- | ---------------------------- | ---------------- | ------- | ------------ | cluster.local | default/nginx | default/web | nginx.default.svc.cluster.local | web-{0..N-1}.nginx.default.svc.cluster.local | web-{0..N-1} | cluster.local | foo/nginx | foo/web | nginx.foo.svc.cluster.local | web-{0..N-1}.nginx.foo.svc.cluster.local | web-{0..N-1} | kube.local | foo/nginx | foo/web | nginx.foo.svc.kube.local | web-{0..N-1}.nginx.foo.svc.kube.local | web-{0..N-1} | @@ -227,15 +215,12 @@ Cluster Domain will be set to `cluster.local` unless [otherwise configured](/docs/concepts/services-networking/dns-pod-service/#how-it-works). --> {{< note >}} -集群域会被设置为 `cluster.local`，除非有[其他配置](/docs/concepts/services-networking/dns-pod-service/)。 +集群域会被设置为 `cluster.local`，除非有[其他配置](/zh/docs/concepts/services-networking/dns-pod-service/)。 {{< /note >}} <!-- ### Stable Storage ---> -### 稳定的存储 -<!-- Kubernetes creates one [PersistentVolume](/docs/concepts/storage/persistent-volumes/) for each VolumeClaimTemplate. In the nginx example above, each Pod will receive a single PersistentVolume with a StorageClass of `my-storage-class` and 1 Gib of provisioned storage. If no StorageClass @@ -245,32 +230,38 @@ PersistentVolume Claims. Note that, the PersistentVolumes associated with the Pods' PersistentVolume Claims are not deleted when the Pods, or StatefulSet are deleted. This must be done manually. --> -Kubernetes 为每个 VolumeClaimTemplate 创建一个 [PersistentVolume](/docs/concepts/storage/persistent-volumes/)。在上面的 nginx 示例中，每个 Pod 将会得到基于 StorageClass `my-storage-class` 提供的 1 Gib 的 PersistentVolume。如果没有声明 StorageClass，就会使用默认的 StorageClass。当一个 Pod 被调度（重新调度）到节点上时，它的 `volumeMounts` 会挂载与其 PersistentVolumeClaims 相关联的 PersistentVolume。请注意，当 Pod 或者 StatefulSet 被删除时，与 PersistentVolumeClaims 相关联的 PersistentVolume 并不会被删除。要删除它必须通过手动方式来完成。 +### 稳定的存储 {#stable-storage} + +Kubernetes 为每个 VolumeClaimTemplate 创建一个 [PersistentVolume](/zh/docs/concepts/storage/persistent-volumes/)。 +在上面的 nginx 示例中，每个 Pod 将会得到基于 StorageClass `my-storage-class` 提供的 +1 Gib 的 PersistentVolume。如果没有声明 StorageClass，就会使用默认的 StorageClass。 +当一个 Pod 被调度（重新调度）到节点上时，它的 `volumeMounts` 会挂载与其 +PersistentVolumeClaims 相关联的 PersistentVolume。 +请注意，当 Pod 或者 StatefulSet 被删除时，与 PersistentVolumeClaims 相关联的 +PersistentVolume 并不会被删除。要删除它必须通过手动方式来完成。 <!-- ### Pod Name Label ---> -### Pod 名称标签 -<!-- When the StatefulSet {{< glossary_tooltip term_id="controller" >}} creates a Pod, it adds a label, `statefulset.kubernetes.io/pod-name`, that is set to the name of the Pod. This label allows you to attach a Service to a specific Pod in the StatefulSet. --> +### Pod 名称标签 {#pod-name-label} + 当 StatefulSet {{< glossary_tooltip term_id="controller" >}} 创建 Pod 时，它会添加一个标签 `statefulset.kubernetes.io/pod-name`，该标签设置为 Pod 名称。这个标签允许您给 StatefulSet 中的特定 Pod 绑定一个 Service。 <!-- ## Deployment and Scaling Guarantees ---> -## 部署和扩缩保证 -<!-- * For a StatefulSet with N replicas, when Pods are being deployed, they are created sequentially, in order from {0..N-1}. * When Pods are being deleted, they are terminated in reverse order, from {N-1..0}. * Before a scaling operation is applied to a Pod, all of its predecessors must be Running and Ready. * Before a Pod is terminated, all of its successors must be completely shutdown. --> +## 部署和扩缩保证 {#deployment-and-scaling-guarantees} + * 对于包含 N 个 副本的 StatefulSet，当部署 Pod 时，它们是依次创建的，顺序为 `0..N-1`。 * 当删除 Pod 时，它们是逆序终止的，顺序为 `N-1..0`。 * 在将缩放操作应用到 Pod 之前，它前面的所有 Pod 必须是 Running 和 Ready 状态。 @@ -279,8 +270,9 @@ the StatefulSet. <!-- The StatefulSet should not specify a `pod.Spec.TerminationGracePeriodSeconds` of 0. This practice is unsafe and strongly discouraged. For further explanation, please refer to [force deleting StatefulSet Pods](/docs/tasks/run-application/force-delete-stateful-set-pod/). --> - -StatefulSet 不应将 `pod.Spec.TerminationGracePeriodSeconds` 设置为 0。这种做法是不安全的，要强烈阻止。更多的解释请参考 [强制删除 StatefulSet Pod](/docs/tasks/run-application/force-delete-stateful-set-pod/)。 +StatefulSet 不应将 `pod.Spec.TerminationGracePeriodSeconds` 设置为 0。 +这种做法是不安全的，要强烈阻止。更多的解释请参考 +[强制删除 StatefulSet Pod](/zh/docs/tasks/run-application/force-delete-stateful-set-pod/)。 <!-- When the nginx example above is created, three Pods will be deployed in the order @@ -290,8 +282,12 @@ web-1 is Running and Ready. If web-0 should fail, after web-1 is Running and Rea web-2 is launched, web-2 will not be launched until web-0 is successfully relaunched and becomes Running and Ready. --> - -在上面的 nginx 示例被创建后，会按照 web-0、web-1、web-2 的顺序部署三个 Pod。在 web-0 进入 [Running 和 Ready](/docs/user-guide/pod-states/) 状态前不会部署 web-1。在 web-1 进入 Running 和 Ready 状态前不会部署 web-2。如果 web-1 已经处于 Running 和 Ready 状态，而 web-2 尚未部署，在此期间发生了 web-0 运行失败，那么 web-2 将不会被部署，要等到 web-0 部署完成并进入 Running 和 Ready 状态后，才会部署 web-2。 +在上面的 nginx 示例被创建后，会按照 web-0、web-1、web-2 的顺序部署三个 Pod。 +在 web-0 进入 [Running 和 Ready](/zh/docs/concepts/workloads/pods/pod-lifecycle/) +状态前不会部署 web-1。在 web-1 进入 Running 和 Ready 状态前不会部署 web-2。 +如果 web-1 已经处于 Running 和 Ready 状态，而 web-2 尚未部署，在此期间发生了 +web-0 运行失败，那么 web-2 将不会被部署，要等到 web-0 部署完成并进入 Running 和 +Ready 状态后，才会部署 web-2。 <!-- If a user were to scale the deployed example by patching the StatefulSet such that @@ -305,72 +301,65 @@ until web-0 is Running and Ready. <!-- ### Pod Management Policies ---> -### Pod 管理策略 {#pod-management-policies} -<!-- In Kubernetes 1.7 and later, StatefulSet allows you to relax its ordering guarantees while preserving its uniqueness and identity guarantees via its `.spec.podManagementPolicy` field. --> +### Pod 管理策略 {#pod-management-policies} + 在 Kubernetes 1.7 及以后的版本中，StatefulSet 允许您不要求其排序保证，同时通过它的 `.spec.podManagementPolicy` 域保持其唯一性和身份保证。 在 Kubernetes 1.7 及以后的版本中，StatefulSet 允许您放宽其排序保证，同时通过它的 `.spec.podManagementPolicy` 域保持其唯一性和身份保证。 <!-- #### OrderedReady Pod Management ---> -#### OrderedReady Pod 管理 -<!-- `OrderedReady` pod management is the default for StatefulSets. It implements the behavior described [above](#deployment-and-scaling-guarantees). --> +#### OrderedReady Pod 管理 + `OrderedReady` Pod 管理是 StatefulSet 的默认设置。它实现了[上面](#deployment-and-scaling-guarantees)描述的功能。 <!-- #### Parallel Pod Management ---> -#### Parallel Pod 管理 -<!-- `Parallel` pod management tells the StatefulSet controller to launch or terminate all Pods in parallel, and to not wait for Pods to become Running and Ready or completely terminated prior to launching or terminating another Pod. --> -`Parallel` Pod 管理让 StatefulSet 控制器并行的启动或终止所有的 Pod，启动或者终止其他 Pod 前，无需等待 Pod 进入 Running 和 ready 或者完全停止状态。 +#### 并行 Pod 管理 {#parallel-pod-management} + +`Parallel` Pod 管理让 StatefulSet 控制器并行的启动或终止所有的 Pod， +启动或者终止其他 Pod 前，无需等待 Pod 进入 Running 和 ready 或者完全停止状态。 <!-- ## Update Strategies ---> -## 更新策略 -<!-- In Kubernetes 1.7 and later, StatefulSet's `.spec.updateStrategy` field allows you to configure and disable automated rolling updates for containers, labels, resource request/limits, and annotations for the Pods in a StatefulSet. --> +## 更新策略 {#update-strategies} + 在 Kubernetes 1.7 及以后的版本中，StatefulSet 的 `.spec.updateStrategy` 字段让您可以配置和禁用掉自动滚动更新 Pod 的容器、标签、资源请求或限制、以及注解。 <!-- ### On Delete ---> -### 关于删除策略 -<!-- The `OnDelete` update strategy implements the legacy (1.6 and prior) behavior. When a StatefulSet's `.spec.updateStrategy.type` is set to `OnDelete`, the StatefulSet controller will not automatically update the Pods in a StatefulSet. Users must manually delete Pods to cause the controller to create new Pods that reflect modifications made to a StatefulSet's `.spec.template`. --> +### 关于删除策略 {#on-delete} + `OnDelete` 更新策略实现了 1.6 及以前版本的历史遗留行为。当 StatefulSet 的 `.spec.updateStrategy.type` 设置为 `OnDelete` 时，它的控制器将不会自动更新 StatefulSet 中的 Pod。用户必须手动删除 Pod 以便让控制器创建新的 Pod，以此来对 StatefulSet 的 `.spec.template` 的变动作出反应。 <!-- ### Rolling Updates ---> -### 滚动更新 {#rolling-updates} -<!-- The `RollingUpdate` update strategy implements automated, rolling update for the Pods in a StatefulSet. It is the default strategy when `.spec.updateStrategy` is left unspecified. When a StatefulSet's `.spec.updateStrategy.type` is set to `RollingUpdate`, the StatefulSet controller will delete and recreate each Pod in the StatefulSet. It will proceed @@ -378,16 +367,15 @@ in the same order as Pod termination (from the largest ordinal to the smallest), each Pod one at a time. It will wait until an updated Pod is Running and Ready prior to updating its predecessor. --> +### 滚动更新 {#rolling-updates} + `RollingUpdate` 更新策略对 StatefulSet 中的 Pod 执行自动的滚动更新。在没有声明 `.spec.updateStrategy` 时，`RollingUpdate` 是默认配置。 当 StatefulSet 的 `.spec.updateStrategy.type` 被设置为 `RollingUpdate` 时，StatefulSet 控制器会删除和重建 StatefulSet 中的每个 Pod。 它将按照与 Pod 终止相同的顺序（从最大序号到最小序号）进行，每次更新一个 Pod。它会等到被更新的 Pod 进入 Running 和 Ready 状态，然后再更新其前身。 <!-- #### Partitions ---> -#### 分区 -<!-- The `RollingUpdate` update strategy can be partitioned, by specifying a `.spec.updateStrategy.rollingUpdate.partition`. If a partition is specified, all Pods with an ordinal that is greater than or equal to the partition will be updated when the StatefulSet's @@ -398,15 +386,14 @@ updates to its `.spec.template` will not be propagated to its Pods. In most cases you will not need to use a partition, but they are useful if you want to stage an update, roll out a canary, or perform a phased roll out. --> +#### 分区 {#partitions} + 通过声明 `.spec.updateStrategy.rollingUpdate.partition` 的方式，`RollingUpdate` 更新策略可以实现分区。如果声明了一个分区，当 StatefulSet 的 `.spec.template` 被更新时，所有序号大于等于该分区序号的 Pod 都会被更新。所有序号小于该分区序号的 Pod 都不会被更新，并且，即使他们被删除也会依据之前的版本进行重建。如果 StatefulSet 的 `.spec.updateStrategy.rollingUpdate.partition` 大于它的 `.spec.replicas`，对它的 `.spec.template` 的更新将不会传递到它的 Pod。 在大多数情况下，您不需要使用分区，但如果您希望进行阶段更新、执行金丝雀或执行分阶段展开，则这些分区会非常有用。 <!-- #### Forced Rollback ---> -#### 强制回滚 {#forced-rollback} -<!-- When using [Rolling Updates](#rolling-updates) with the default [Pod Management Policy](#pod-management-policies) (`OrderedReady`), it's possible to get into a broken state that requires manual intervention to repair. @@ -414,7 +401,14 @@ it's possible to get into a broken state that requires manual intervention to re If you update the Pod template to a configuration that never becomes Running and Ready (for example, due to a bad binary or application-level configuration error), StatefulSet will stop the rollout and wait. +--> +#### 强制回滚 {#forced-rollback} +在默认 [Pod 管理策略](#pod-management-policies)(`OrderedReady`) 时使用 [滚动更新](#rolling-updates) ，可能进入需要人工干预才能修复的损坏状态。 + +如果更新后 Pod 模板配置进入无法运行或就绪的状态（例如，由于错误的二进制文件或应用程序级配置错误），StatefulSet 将停止回滚并等待。 + +<!-- In this state, it's not enough to revert the Pod template to a good configuration. Due to a [known issue](https://github.com/kubernetes/kubernetes/issues/67250), StatefulSet will continue to wait for the broken Pod to become Ready @@ -425,27 +419,24 @@ After reverting the template, you must also delete any Pods that StatefulSet had already attempted to run with the bad configuration. StatefulSet will then begin to recreate the Pods using the reverted template. --> -在默认 [Pod 管理策略](#pod-management-policies)(`OrderedReady`) 时使用 [滚动更新](#rolling-updates) ，可能进入需要人工干预才能修复的损坏状态。 - -如果更新后 Pod 模板配置进入无法运行或就绪的状态（例如，由于错误的二进制文件或应用程序级配置错误），StatefulSet 将停止回滚并等待。 - -在这种状态下，仅将 Pod 模板还原为正确的配置是不够的。由于[已知问题](https://github.com/kubernetes/kubernetes/issues/67250)，StatefulSet 将继续等待损坏状态的 Pod 准备就绪（永远不会发生），然后再尝试将其恢复为正常工作配置。 - -恢复模板后，还必须删除 StatefulSet 尝试使用错误的配置来运行的 Pod。这样，StatefulSet 才会开始使用被还原的模板来重新创建 Pod。 +在这种状态下，仅将 Pod 模板还原为正确的配置是不够的。由于 +[已知问题](https://github.com/kubernetes/kubernetes/issues/67250)，StatefulSet +将继续等待损坏状态的 Pod 准备就绪（永远不会发生），然后再尝试将其恢复为正常工作配置。 +恢复模板后，还必须删除 StatefulSet 尝试使用错误的配置来运行的 Pod。这样， +StatefulSet 才会开始使用被还原的模板来重新创建 Pod。 ## {{% heading "whatsnext" %}} - <!-- * Follow an example of [deploying a stateful application](/docs/tutorials/stateful-application/basic-stateful-set/). * Follow an example of [deploying Cassandra with Stateful Sets](/docs/tutorials/stateful-application/cassandra/). * Follow an example of [running a replicated stateful application](/docs/tasks/run-application/run-replicated-stateful-application/). --> -* 示例一：[部署有状态应用](/docs/tutorials/stateful-application/basic-stateful-set/)。 -* 示例二：[使用 StatefulSet 部署 Cassandra](/docs/tutorials/stateful-application/cassandra/)。 -* 示例三：[运行多副本的有状态应用程序](/docs/tasks/run-application/run-replicated-stateful-application/)。 +* 示例一：[部署有状态应用](/zh/docs/tutorials/stateful-application/basic-stateful-set/)。 +* 示例二：[使用 StatefulSet 部署 Cassandra](/zh/docs/tutorials/stateful-application/cassandra/)。 +* 示例三：[运行多副本的有状态应用程序](/zh/docs/tasks/run-application/run-replicated-stateful-application/)。 diff --git a/content/zh/docs/concepts/workloads/controllers/ttlafterfinished.md b/content/zh/docs/concepts/workloads/controllers/ttlafterfinished.md index 344363c5dd..3b2ddc60c7 100644 --- a/content/zh/docs/concepts/workloads/controllers/ttlafterfinished.md +++ b/content/zh/docs/concepts/workloads/controllers/ttlafterfinished.md @@ -4,13 +4,9 @@ content_type: concept weight: 65 --- <!-- ---- -reviewers: -- janetkuo title: TTL Controller for Finished Resources content_type: concept weight: 65 ---- --> <!-- overview --> @@ -20,36 +16,41 @@ weight: 65 <!-- The TTL controller provides a TTL mechanism to limit the lifetime of resource objects that have finished execution. TTL controller only handles -[Jobs](/docs/concepts/workloads/controllers/jobs-run-to-completion/) for -now, and may be expanded to handle other resources that will finish execution, +{{< glossary_tooltip text="Jobs" term_id="job" >}} for now, +and may be expanded to handle other resources that will finish execution, such as Pods and custom resources. --> -TTL 控制器提供了一种 TTL 机制来限制已完成执行的资源对象的生命周期。TTL 控制器目前只处理 [Job](/docs/concepts/workloads/controllers/jobs-run-to-completion/)，可能以后会扩展以处理将完成执行的其他资源，例如 Pod 和自定义资源。 +TTL 控制器提供了一种 TTL 机制来限制已完成执行的资源对象的生命周期。 +TTL 控制器目前只处理 {{< glossary_tooltip text="Job" term_id="job" >}}， +可能以后会扩展以处理将完成执行的其他资源，例如 Pod 和自定义资源。 <!-- Alpha Disclaimer: this feature is currently alpha, and can be enabled with both kube-apiserver and kube-controller-manager [feature gate](/docs/reference/command-line-tools-reference/feature-gates/) `TTLAfterFinished`. --> -Alpha 免责声明：此功能目前是 alpha 版，并且可以通过 kube-apiserver 和 kube-controller-manager [特性开关](/docs/reference/command-line-tools-reference/feature-gates/) `TTLAfterFinished` 启用。 - - - +Alpha 免责声明：此功能目前是 alpha 版，并且可以通过 `kube-apiserver` 和 +`kube-controller-manager` 上的 +[特性门控](/zh/docs/reference/command-line-tools-reference/feature-gates/) +`TTLAfterFinished` 启用。 <!-- body --> <!-- ## TTL Controller ---> -## TTL 控制器 -<!-- The TTL controller only supports Jobs for now. A cluster operator can use this feature to clean up finished Jobs (either `Complete` or `Failed`) automatically by specifying the `.spec.ttlSecondsAfterFinished` field of a Job, as in this -[example](/docs/concepts/workloads/controllers/jobs-run-to-completion/#clean-up-finished-jobs-automatically). +[example](/docs/concepts/workloads/controllers/job/#clean-up-finished-jobs-automatically). --> -TTL 控制器现在只支持 Job。集群操作员可以通过指定 Job 的 `.spec.ttlSecondsAfterFinished` 字段来自动清理已结束的作业（`Complete` 或 `Failed`），如下所示的[示例](/docs/concepts/workloads/controllers/jobs-run-to-completion/#clean-up-finished-jobs-automatically)。 +## TTL 控制器 + +TTL 控制器现在只支持 Job。集群操作员可以通过指定 Job 的 `.spec.ttlSecondsAfterFinished` +字段来自动清理已结束的作业（`Complete` 或 `Failed`），如 +[示例](/zh/docs/concepts/workloads/controllers/jobs-run-to-completion/#clean-up-finished-jobs-automatically) +所示。 + <!-- The TTL controller will assume that a resource is eligible to be cleaned up TTL seconds after the resource has finished, in other words, when the TTL has expired. When the @@ -57,7 +58,9 @@ TTL controller cleans up a resource, it will delete it cascadingly, i.e. delete its dependent objects together with it. Note that when the resource is deleted, its lifecycle guarantees, such as finalizers, will be honored. --> -TTL 控制器假设资源能在执行完成后的 TTL 秒内被清理，也就是当 TTL 过期后。当 TTL 控制器清理资源时，它将做级联删除操作，如删除资源对象的同时也删除其依赖对象。注意，当资源被删除时，由该资源的生命周期保证其终结器（finalizers）等被执行。 +TTL 控制器假设资源能在执行完成后的 TTL 秒内被清理，也就是当 TTL 过期后。 +当 TTL 控制器清理资源时，它将做级联删除操作，即删除资源对象的同时也删除其依赖对象。 +注意，当资源被删除时，由该资源的生命周期保证其终结器（Finalizers）等被执行。 <!-- The TTL seconds can be set at any time. Here are some examples for setting the @@ -68,8 +71,7 @@ The TTL seconds can be set at any time. Here are some examples for setting the <!-- * Specify this field in the resource manifest, so that a Job can be cleaned up automatically some time after it finishes. -* Set this field of existing, already finished resources, to adopt this new - feature. +* Set this field of existing, already finished resources, to adopt this new feature. * Use a [mutating admission webhook](/docs/reference/access-authn-authz/extensible-admission-controllers/#admission-webhooks) to set this field dynamically at resource creation time. Cluster administrators can @@ -80,41 +82,44 @@ The TTL seconds can be set at any time. Here are some examples for setting the different TTL values based on resource status, labels, etc. --> * 在资源清单（manifest）中指定此字段，以便 Job 在完成后的某个时间被自动清除。 -* 将此字段设置为存在的、已完成的资源，以采用此新功能。 -* 在创建资源时使用 [mutating admission webhook](/docs/reference/access-authn-authz/extensible-admission-controllers/#admission-webhooks) 动态设置该字段。集群管理员可以使用它对完成的资源强制执行 TTL 策略。 -* 使用 [mutating admission webhook](/docs/reference/access-authn-authz/extensible-admission-controllers/#admission-webhooks) 在资源完成后动态设置该字段，并根据资源状态、标签等选择不同的 TTL 值。 +* 将此字段设置为现有的、已完成的资源，以采用此新功能。 +* 在创建资源时使用 [mutating admission webhook](/zh/docs/reference/access-authn-authz/extensible-admission-controllers/#admission-webhooks) + 动态设置该字段。集群管理员可以使用它对完成的资源强制执行 TTL 策略。 +* 使用 [mutating admission webhook](/zh/docs/reference/access-authn-authz/extensible-admission-controllers/#admission-webhooks) + 在资源完成后动态设置该字段，并根据资源状态、标签等选择不同的 TTL 值。 <!-- ## Caveat ---> -## 警告 -<!-- ### Updating TTL Seconds ---> -### 更新 TTL 秒 -<!-- Note that the TTL period, e.g. `.spec.ttlSecondsAfterFinished` field of Jobs, can be modified after the resource is created or has finished. However, once the Job becomes eligible to be deleted (when the TTL has expired), the system won't guarantee that the Jobs will be kept, even if an update to extend the TTL returns a successful API response. --> -请注意，在创建资源或已经执行结束后，仍可以修改其 TTL 周期，例如 Job 的 `.spec.ttlSecondsAfterFinished` 字段。但是，一旦 Job 变为可被删除状态（当其 TTL 已过期时），即使您通过 API 扩展其 TTL 时长得到了成功的响应，系统也不保证 Job 将被保留。 +## 警告 + +### 更新 TTL 秒 + +请注意，在创建资源或已经执行结束后，仍可以修改其 TTL 周期，例如 Job 的 +`.spec.ttlSecondsAfterFinished` 字段。 +但是一旦 Job 变为可被删除状态（当其 TTL 已过期时），即使您通过 API 增加其 TTL +时长得到了成功的响应，系统也不保证 Job 将被保留。 <!-- ### Time Skew ---> -### 时间偏差 -<!-- Because TTL controller uses timestamps stored in the Kubernetes resources to determine whether the TTL has expired or not, this feature is sensitive to time skew in the cluster, which may cause TTL controller to clean up resource objects at the wrong time. --> -由于 TTL 控制器使用存储在 Kubernetes 资源中的时间戳来确定 TTL 是否已过期，因此该功能对集群中的时间偏差很敏感，这可能导致 TTL 控制器在错误的时间清理资源对象。 +### 时间偏差 {#time-skew} + +由于 TTL 控制器使用存储在 Kubernetes 资源中的时间戳来确定 TTL 是否已过期， +因此该功能对集群中的时间偏差很敏感，这可能导致 TTL 控制器在错误的时间清理资源对象。 <!-- In Kubernetes, it's required to run NTP on all nodes @@ -122,21 +127,17 @@ In Kubernetes, it's required to run NTP on all nodes to avoid time skew. Clocks aren't always correct, but the difference should be very small. Please be aware of this risk when setting a non-zero TTL. --> -在 Kubernetes 中，需要在所有节点上运行 NTP（参见 [#6159](https://github.com/kubernetes/kubernetes/issues/6159#issuecomment-93844058)）以避免时间偏差。时钟并不总是如此正确，但差异应该很小。设置非零 TTL 时请注意避免这种风险。 - - +在 Kubernetes 中，需要在所有节点上运行 NTP（参见 +[#6159](https://github.com/kubernetes/kubernetes/issues/6159#issuecomment-93844058)） +以避免时间偏差。时钟并不总是如此正确，但差异应该很小。 +设置非零 TTL 时请注意避免这种风险。 ## {{% heading "whatsnext" %}} - <!-- -[Clean up Jobs automatically](/docs/concepts/workloads/controllers/jobs-run-to-completion/#clean-up-finished-jobs-automatically) +* [Clean up Jobs automatically](/docs/concepts/workloads/controllers/jobs-run-to-completion/#clean-up-finished-jobs-automatically) +* [Design doc](https://github.com/kubernetes/enhancements/blob/master/keps/sig-apps/0026-ttl-after-finish.md) --> -[自动清理 Job](/docs/concepts/workloads/controllers/jobs-run-to-completion/#clean-up-finished-jobs-automatically) - -<!-- -[Design doc](https://github.com/kubernetes/enhancements/blob/master/keps/sig-apps/0026-ttl-after-finish.md) ---> -[设计文档](https://github.com/kubernetes/enhancements/blob/master/keps/sig-apps/0026-ttl-after-finish.md) - +* [自动清理 Job](/zh/docs/concepts/workloads/controllers/job/#clean-up-finished-jobs-automatically) +* [设计文档](https://github.com/kubernetes/enhancements/blob/master/keps/sig-apps/0026-ttl-after-finish.md) diff --git a/content/zh/docs/concepts/workloads/pods/_index.md b/content/zh/docs/concepts/workloads/pods/_index.md index db1df2566a..ac5806e3f0 100644 --- a/content/zh/docs/concepts/workloads/pods/_index.md +++ b/content/zh/docs/concepts/workloads/pods/_index.md @@ -1,4 +1,524 @@ --- title: "Pods" +content_type: concept weight: 10 +no_list: true +card: + name: concepts + weight: 60 --- +<!-- +reviewers: +- erictune +title: Pods +content_type: concept +weight: 10 +no_list: true +card: + name: concepts + weight: 60 +--> + +<!-- overview --> + +<!-- +_Pods_ are the smallest deployable units of computing that you can create and manage in Kubernetes. + +A _Pod_ (as in a pod of whales or pea pod) is a group of one or more +{{< glossary_tooltip text="containers" term_id="container" >}} +with shared storage/network resources, and a specification +for how to run the containers. A Pod's contents are always co-located and +co-scheduled, and run in a shared context. A Pod models an +application-specific "logical host": it contains one or more application +containers which are relatively tightly coupled. +In non-cloud contexts, applications executed on the same physical or virtual machine are analogous to cloud applications executed on the same logical host. +--> +_Pod_ 是可以在 Kubernetes 中创建和管理的、最小的可部署的计算单元。 + +_Pod_ （就像在鲸鱼荚或者豌豆荚中）是一组（一个或多个） +{{< glossary_tooltip text="容器" term_id="container" >}}； +这些容器共享存储、网络、以及怎样运行这些容器的声明。 +Pod 中的内容总是并置（colocated）的并且一同调度，在共享的上下文中运行。 +Pod 所建模的是特定于应用的“逻辑主机”，其中包含一个或多个应用容器， +这些容器是相对紧密的耦合在一起的。 +在非云环境中，在相同的物理机或虚拟机上运行的应用类似于 +在同一逻辑主机上运行的云应用。 + +<!-- +As well as application containers, a Pod can contain +[init containers](/docs/concepts/workloads/pods/init-containers/) that run +during Pod startup. You can also inject +[ephemeral containers](/docs/concepts/workloads/pods/ephemeral-containers/) +for debugging if your cluster offers this. +--> +除了应用容器，Pod 还可以包含在 Pod 启动期间运行的 +[Init 容器](/zh/docs/concepts/workloads/pods/init-containers/)。 +你也可以在集群中支持[临时性容器](/zh/docs/concepts/workloads/pods/ephemeral-containers/) +的情况外，为调试的目的注入临时性容器。 + +<!-- body --> + +## 什么是 Pod？ {#what-is-a-pod} + +<!-- +While Kubernetes supports more +{{< glossary_tooltip text="container runtimes" term_id="container-runtime" >}} +than just Docker, [Docker](https://www.docker.com/) is the most commonly known +runtime, and it helps to describe Pods using some terminology from Docker. +--> +{{< note >}} +除了 Docker 之外，Kubernetes 支持 +很多其他{{< glossary_tooltip text="容器运行时" term_id="container-runtime" >}}， +[Docker](https://www.docker.com/) 是最有名的运行时， +使用 Docker 的术语来描述 Pod 会很有帮助。 +{{< /note >}} + +<!-- +The shared context of a Pod is a set of Linux namespaces, cgroups, and +potentially other facets of isolation - the same things that isolate a Docker +container. Within a Pod's context, the individual applications may have +further sub-isolations applied. + +In terms of Docker concepts, a Pod is similar to a group of Docker containers +with shared namespaces and shared filesystem volumes. +--> +Pod 的共享上下文包括一组 Linux 名字空间、控制组（cgroup）和可能一些其他的隔离 +方面，即用来隔离 Docker 容器的技术。 +在 Pod 的上下文中，每个独立的应用可能会进一步实施隔离。 + +就 Docker 概念的术语而言，Pod 类似于共享名字空间和文件系统卷的一组 Docker +容器。 + +<!-- +## Using Pods + +Usually you don't need to create Pods directly, even singleton Pods. +Instead, create them using workload resources such as {{< glossary_tooltip text="Deployment" +term_id="deployment" >}} or {{< glossary_tooltip text="Job" term_id="job" >}}. +If your Pods need to track state, consider the +{{< glossary_tooltip text="StatefulSet" term_id="statefulset" >}} resource. + +Pods in a Kubernetes cluster are used in two main ways: +--> +## 使用 Pod {#using-pods} + +通常你不需要直接创建 Pod，甚至单实例 Pod。 +相反，你会使用诸如 +{{< glossary_tooltip text="Deployment" term_id="deployment" >}} 或 +{{< glossary_tooltip text="Job" term_id="job" >}} 这类工作负载资源 +来创建 Pod。如果 Pod 需要跟踪状态， +可以考虑 {{< glossary_tooltip text="StatefulSet" term_id="statefulset" >}} +资源。 + +Kubernetes 集群中的 Pod 主要有两种用法： + +<!-- +* **Pods that run a single container**. The "one-container-per-Pod" model is the + most common Kubernetes use case; in this case, you can think of a Pod as a + wrapper around a single container; Kubernetes manages Pods rather than managing + the containers directly. +* **Pods that run multiple containers that need to work together**. A Pod can + encapsulate an application composed of multiple co-located containers that are + tightly coupled and need to share resources. These co-located containers + form a single cohesive unit of service—for example, one container serving data + stored in a shared volume to the public, while a separate _sidecar_ container + refreshes or updates those files. + The Pod wraps these containers, storage resources, and an ephemeral network + identity together as a single unit. + + Grouping multiple co-located and co-managed containers in a single Pod is a + relatively advanced use case. You should use this pattern only in specific + instances in which your containers are tightly coupled. +--> +* **运行单个容器的 Pod**。"每个 Pod 一个容器"模型是最常见的 Kubernetes 用例； + 在这种情况下，可以将 Pod 看作单个容器的包装器，并且 Kubernetes 直接管理 Pod，而不是容器。 +* **运行多个协同工作的容器的 Pod**。 + Pod 可能封装由多个紧密耦合且需要共享资源的共处容器组成的应用程序。 + 这些位于同一位置的容器可能形成单个内聚的服务单元 —— 一个容器将文件从共享卷提供给公众， + 而另一个单独的“挂斗”（sidecar）容器则刷新或更新这些文件。 + Pod 将这些容器和存储资源打包为一个可管理的实体。 + + {{< note >}} + 将多个并置、同管的容器组织到一个 Pod 中是一种相对高级的使用场景。 + 只有在一些场景中，容器之间紧密关联时你才应该使用这种模式。 + {{< /note >}} + +<!-- +Each Pod is meant to run a single instance of a given application. If you want to +scale your application horizontally (to provide more overall resources by running +more instances), you should use multiple Pods, one for each instance. In +Kubernetes, this is typically referred to as _replication_. +Replicated Pods are usually created and managed as a group by a workload resource +and its {{< glossary_tooltip text="controller" term_id="controller" >}}. + +See [Pods and controllers](#pods-and-controllers) for more information on how +Kubernetes uses workload resources, and their controllers, to implement application +scaling and auto-healing. +--> + +每个 Pod 都旨在运行给定应用程序的单个实例。如果希望横向扩展应用程序（例如，运行多个实例 +以提供更多的资源），则应该使用多个 Pod，每个实例使用一个 Pod。 +在 Kubernetes 中，这通常被称为 _副本（Replication）_。 +通常使用一种工作负载资源及其{{< glossary_tooltip text="控制器" term_id="controller" >}} +来创建和管理一组 Pod 副本。 + +参见 [Pod 和控制器](#pods-and-controllers)以了解 Kubernetes +如何使用工作负载资源及其控制器以实现应用的扩缩和自动修复。 + +<!-- +### How Pods manage multiple containers + +Pods are designed to support multiple cooperating processes (as containers) that form +a cohesive unit of service. The containers in a Pod are automatically co-located and +co-scheduled on the same physical or virtual machine in the cluster. The containers +can share resources and dependencies, communicate with one another, and coordinate +when and how they are terminated. +--> +### Pod 怎样管理多个容器 + +Pod 被设计成支持形成内聚服务单元的多个协作过程（形式为容器）。 +Pod 中的容器被自动安排到集群中的同一物理机或虚拟机上，并可以一起进行调度。 +容器之间可以共享资源和依赖、彼此通信、协调何时以及何种方式终止自身。 + +<!-- +For example, you might have a container that +acts as a web server for files in a shared volume, and a separate "sidecar" container +that updates those files from a remote source, as in the following diagram: +--> + +例如，你可能有一个容器，为共享卷中的文件提供 Web 服务器支持，以及一个单独的 +“sidecar（挂斗）”容器负责从远端更新这些文件，如下图所示： + +{{< figure src="/images/docs/pod.svg" alt="example pod diagram" width="50%" >}} + +<!-- +Some Pods have {{< glossary_tooltip text="init containers" term_id="init-container" >}} +as well as {{< glossary_tooltip text="app containers" term_id="app-container" >}}. +Init containers run and complete before the app containers are started. + +Pods natively provide two kinds of shared resources for their constituent containers: +[networking](#pod-networking) and [storage](#pod-storage). +--> +有些 Pod 具有 {{< glossary_tooltip text="Init 容器" term_id="init-container" >}} 和 +{{< glossary_tooltip text="应用容器" term_id="app-container" >}}。 +Init 容器会在启动应用容器之前运行并完成。 + +Pod 天生地为其成员容器提供了两种共享资源：[网络](#pod-networking)和 +[存储](#pod-storage)。 + +<!-- +## Working with Pods + +You'll rarely create individual Pods directly in Kubernetes—even singleton Pods. This +is because Pods are designed as relatively ephemeral, disposable entities. When +a Pod gets created (directly by you, or indirectly by a +{{< glossary_tooltip text="controller" term_id="controller" >}}), the new Pod is +scheduled to run on a {{< glossary_tooltip term_id="node" >}} in your cluster. +The Pod remains on that node until the Pod finishes execution, the Pod object is deleted, +the Pod is *evicted* for lack of resources, or the node fails. +--> +## 使用 Pod {#working-with-pods} + +你很少在 Kubernetes 中直接创建一个个的 Pod，甚至是单实例（Singleton）的 Pod。 +这是因为 Pod 被设计成了相对临时性的、用后即抛的一次性实体。 +当 Pod 由你或者间接地由 {{< glossary_tooltip text="控制器" term_id="controller" >}} +创建时，它被调度在集群中的{{< glossary_tooltip text="节点" term_id="node" >}}上运行。 +Pod 会保持在该节点上运行，直到 Pod 结束执行、Pod 对象被删除、Pod 因资源不足而被 +*驱逐* 或者节点失效为止。 + +<!-- +Restarting a container in a Pod should not be confused with restarting a Pod. A Pod +is not a process, but an environment for running container(s). A Pod persists until +it is deleted. +--> +{{< note >}} +重启 Pod 中的容器不应与重启 Pod 混淆。 +Pod 不是进程，而是容器运行的环境。 +在被删除之前，Pod 会一直存在。 +{{< /note >}} + +<!-- +When you create the manifest for a Pod object, make sure the name specified is a valid +[DNS subdomain name](/docs/concepts/overview/working-with-objects/names#dns-subdomain-names). +--> +当你为 Pod 对象创建清单时，要确保所指定的 Pod 名称是合法的 +[DNS 子域名](/zh/docs/concepts/overview/working-with-objects/names#dns-subdomain-names)。 + +<!-- +### Pods and controllers + +You can use workload resources to create and manage multiple Pods for you. A controller +for the resource handles replication and rollout and automatic healing in case of +Pod failure. For example, if a Node fails, a controller notices that Pods on that +Node have stopped working and creates a replacement Pod. The scheduler places the +replacement Pod onto a healthy Node. + +Here are some examples of workload resources that manage one or more Pods: +--> +### Pod 和控制器 {#pods-and-controllers} + +你可以使用工作负载资源来创建和管理多个 Pod。 +资源的控制器能够处理副本的管理、上线，并在 Pod 失效时提供自愈能力。 +例如，如果一个节点失败，控制器注意到该节点上的 Pod 已经停止工作， +就可以创建替换性的 Pod。调度器会将替身 Pod 调度到一个健康的节点执行。 + +下面是一些管理一个或者多个 Pod 的工作负载资源的示例： + +* {{< glossary_tooltip text="Deployment" term_id="deployment" >}} +* {{< glossary_tooltip text="StatefulSet" term_id="statefulset" >}} +* {{< glossary_tooltip text="DaemonSet" term_id="daemonset" >}} + +<!-- +### Pod templates + +Controllers for {{< glossary_tooltip text="workload" term_id="workload" >}} resources create Pods +from a _pod template_ and manage those Pods on your behalf. + +PodTemplates are specifications for creating Pods, and are included in workload resources such as +[Deployments](/docs/concepts/workloads/controllers/deployment/), +[Jobs](/docs/concepts/jobs/run-to-completion-finite-workloads/), and +[DaemonSets](/docs/concepts/workloads/controllers/daemonset/). +--> +### Pod 模版 {#pod-templates} + +{{< glossary_tooltip text="负载" term_id="workload" >}}资源的控制器通常使用 _Pod 模板（Pod Template）_ +来替你创建 Pod 并管理它们。 + +Pod 模板是包含在工作负载对象中的规范，用来创建 Pod。这类负载资源包括 +[Deployment](/zh/docs/concepts/workloads/controllers/deployment/)、 +[Job](/zh/docs/concepts/workloads/containers/job/) 和 +[DaemonSets](/zh/docs/concepts/workloads/controllers/daemonset/)等。 + +<!-- +Each controller for a workload resource uses the `PodTemplate` inside the workload +object to make actual Pods. The `PodTemplate` is part of the desired state of whatever +workload resource you used to run your app. + +The sample below is a manifest for a simple Job with a `template` that starts one +container. The container in that Pod prints a message then pauses. +--> +工作负载的控制器会使用负载对象中的 `PodTemplate` 来生成实际的 Pod。 +`PodTemplate` 是你用来运行应用时指定的负载资源的目标状态的一部分。 + +下面的示例是一个简单的 Job 的清单，其中的 `template` 指示启动一个容器。 +该 Pod 中的容器会打印一条消息之后暂停。 + +```yaml +apiVersion: batch/v1 +kind: Job +metadata: + name: hello +spec: + template: + # 这里是 Pod 模版 + spec: + containers: + - name: hello + image: busybox + command: ['sh', '-c', 'echo "Hello, Kubernetes!" && sleep 3600'] + restartPolicy: OnFailure + # 以上为 Pod 模版 +``` + +<!-- +Modifying the pod template or switching to a new pod template has no effect on the +Pods that already exist. Pods do not receive template updates directly. Instead, +a new Pod is created to match the revised pod template. + +For example, the deployment controller ensures that the running Pods match the current +pod template for each Deployment object. If the template is updated, the Deployment has +to remove the existing Pods and create new Pods based on the updated template. Each workload +resource implements its own rules for handling changes to the Pod template. +--> +修改 Pod 模版或者切换到新的 Pod 模版都不会对已经存在的 Pod 起作用。 +Pod 不会直接收到模版的更新。相反， +新的 Pod 会被创建出来，与更改后的 Pod 模版匹配。 + +例如，Deployment 控制器针对每个 Deployment 对象确保运行中的 Pod 与当前的 Pod +模版匹配。如果模版被更新，则 Deployment 必须删除现有的 Pod，基于更新后的模版 +创建新的 Pod。每个工作负载资源都实现了自己的规则，用来处理对 Pod 模版的更新。 + +<!-- +On Nodes, the {{< glossary_tooltip term_id="kubelet" text="kubelet" >}} does not +directly observe or manage any of the details around pod templates and updates; those +details are abstracted away. That abstraction and separation of concerns simplifies +system semantics, and makes it feasible to extend the cluster's behavior without +changing existing code. +--> +在节点上，{{< glossary_tooltip term_id="kubelet" text="kubelet" >}}并不直接监测 +或管理与 Pod 模版相关的细节或模版的更新，这些细节都被抽象出来。 +这种抽象和关注点分离简化了整个系统的语义，并且使得用户可以在不改变现有代码的 +前提下就能扩展集群的行为。 + +<!-- +## Resource sharing and communication + +Pods enable data sharing and communication among their constituent +containters. +--> +### 资源共享和通信 {#resource-sharing-and-communication} + +Pod 使它的成员容器间能够进行数据共享和通信。 + +<!-- +### Storage in Pods {#pod-storage} + +A Pod can specify a set of shared storage +{{< glossary_tooltip text="volumes" term_id="volume" >}}. All containers +in the Pod can access the shared volumes, allowing those containers to +share data. Volumes also allow persistent data in a Pod to survive +in case one of the containers within needs to be restarted. See +[Storage](/docs/concepts/storage/) for more information on how +Kubernetes implements shared storage and makes it available to Pods. +--> +### Pod 中的存储 {#pod-storage} + +一个 Pod 可以设置一组共享的存储{{< glossary_tooltip text="卷" term_id="volume" >}}。 +Pod 中的所有容器都可以访问该共享卷，从而允许这些容器共享数据。 +卷还允许 Pod 中的持久数据保留下来，即使其中的容器需要重新启动。 +有关 Kubernetes 如何在 Pod 中实现共享存储并将其提供给 Pod 的更多信息， +请参考[卷](/zh/docs/concepts/storage/)。 + +<!-- +### Pod networking + +Each Pod is assigned a unique IP address for each address family. Every +container in a Pod shares the network namespace, including the IP address and +network ports. Inside a Pod (and **only** then), the containers that belong to the Pod +can communicate with one another using `localhost`. When containers in a Pod communicate +with entities *outside the Pod*, +they must coordinate how they use the shared network resources (such as ports). +--> +### Pod 联网 {#pod-networking} + +每个 Pod 都在每个地址族中获得一个唯一的 IP 地址。 +Pod 中的每个容器共享网络名字空间，包括 IP 地址和网络端口。 +*Pod 内* 的容器可以使用 `localhost` 互相通信。 +当 Pod 中的容器与 *Pod 之外* 的实体通信时，它们必须协调如何使用共享的网络资源 +（例如端口）。 + +<!-- +Within a Pod, containers share an IP address and port space, and +can find each other via `localhost`. The containers in a Pod can also communicate +with each other using standard inter-process communications like SystemV semaphores +or POSIX shared memory. Containers in different Pods have distinct IP addresses +and can not communicate by IPC without +[special configuration](/docs/concepts/policy/pod-security-policy/). +Containers that want to interact with a container running in a different Pod can +use IP networking to comunicate. +--> +在同一个 Pod 内，所有容器共享一个 IP 地址和端口空间，并且可以通过 `localhost` 发现对方。 +他们也能通过如 SystemV 信号量或 POSIX 共享内存这类标准的进程间通信方式互相通信。 +不同 Pod 中的容器的 IP 地址互不相同，没有 +[特殊配置](/zh/docs/concepts/policy/pod-security-policy/) 就不能使用 IPC 进行通信。 +如果某容器希望与运行于其他 Pod 中的容器通信，可以通过 IP 联网的方式实现。 + +<!-- +Containers within the Pod see the system hostname as being the same as the configured +`name` for the Pod. There's more about this in the [networking](/docs/concepts/cluster-administration/networking/) +section. +--> +Pod 中的容器所看到的系统主机名与为 Pod 配置的 `name` 属性值相同。 +[网络](/zh/docs/concepts/cluster-administration/networking/)部分提供了更多有关此内容的信息。 + +<!-- +## Privileged mode for containers + +Any container in a Pod can enable privileged mode, using the `privileged` flag on +the [security context](/docs/tasks/configure-pod-container/security-context/) of the container spec. This is useful for containers that want to use operating system administrative capabilities such as manipulating the network stack or accessing hardware devices. +Processes within a privileged container get almost the same privileges that are available to processes outside a container. +--> +## 容器的特权模式 {#rivileged-mode-for-containers} + +Pod 中的任何容器都可以使用容器规约中的 +[安全性上下文](/zh/docs/tasks/configure-pod-container/security-context/)中的 +`privileged` 参数启用特权模式。 +这对于想要使用使用操作系统管理权能（Capabilities，如操纵网络堆栈和访问设备） +的容器很有用。 +容器内的进程几乎可以获得与容器外的进程相同的特权。 + +<!-- +Your {< glossary_tooltip text="container runtime" term_id="container-runtime" >}} must support the concept of a privileged container for this setting to be relevant. +--> +{{< note >}} +你的{{< glossary_tooltip text="容器运行时" term_id="container-runtime" >}}必须支持 +特权容器的概念才能使用这一配置。 +{{< /note >}} + +<!-- +## Static Pods + +_Static Pods_ are managed directly by the kubelet daemon on a specific node, +without the {{< glossary_tooltip text="API server" term_id="kube-apiserver" >}} +observing them. +Whereas most Pods are managed by the control plane (for example, a +{{< glossary_tooltip text="Deployment" term_id="deployment" >}}), for static +Pods, the kubelet directly supervises each static Pod (and restarts it if it fails). +--> +## 静态 Pod {#static-pods} + +_静态 Pod（Static Pod）_ 直接由特定节点上的 `kubelet` 守护进程管理， +不需要{{< glossary_tooltip text="API 服务器" term_id="kube-apiserver" >}}看到它们。 +尽管大多数 Pod 都是通过控制面（例如，{{< glossary_tooltip text="Deployment" term_id="deployment" >}}） +来管理的，对于静态 Pod 而言，`kubelet` 直接监控每个 Pod，并在其失效时重启之。 + +<!-- +Static Pods are always bound to one {{< glossary_tooltip term_id="kubelet" >}} on a specific node. +The main use for static Pods is to run a self-hosted control plane: in other words, +using the kubelet to supervise the individual [control plane components](/docs/concepts/overview/components/#control-plane-components). + +The kubelet automatically tries to create a {{< glossary_tooltip text="mirror Pod" term_id="mirror-pod" >}} +on the Kubernetes API server for each static Pod. +This means that the Pods running on a node are visible on the API server, +but cannot be controlled from there. +--> +静态 Pod 通常绑定到某个节点上的 {{< glossary_tooltip text="kubelet" term_id="kubelet" >}}。 +其主要用途是运行自托管的控制面。 +在自托管场景中，使用 `kubelet` 来管理各个独立的 +[控制面组件](/zh/docs/concepts/overview/components/#control-plane-components)。 + +`kubelet` 自动尝试为每个静态 Pod 在 Kubernetes API 服务器上创建一个 +{{< glossary_tooltip text="镜像 Pod" term_id="mirror-pod" >}}。 +这意味着在节点上运行的 Pod 在 API 服务器上是可见的，但不可以通过 API +服务器来控制。 + +## {{% heading "whatsnext" %}} + +<!-- +* Learn about the [lifecycle of a Pod](/docs/concepts/workloads/pods/pod-lifecycle/). +* Learn about [PodPresets](/docs/concepts/workloads/pods/podpreset/). +* Lean about [RuntimeClass](/docs/concepts/containers/runtime-class/) and how you can use it to + configure different Pods with different container runtime configurations. +* Read about [Pod topology spread constraints](/docs/concepts/workloads/pods/pod-topology-spread-constraints/). +* Read about [PodDisruptionBudget](https://kubernetes.io/docs/concepts/workloads/pods/disruptions/) and how you can use it to manage application availability during disruptions. +* Pod is a top-level resource in the Kubernetes REST API. + The [Pod](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#pod-v1-core) + object definition describes the object in detail. +* [The Distributed System Toolkit: Patterns for Composite Containers](https://kubernetes.io/blog/2015/06/the-distributed-system-toolkit-patterns) explains common layouts for Pods with more than one container. +-- +* 了解 [Pod 生命周期](/zh/docs/concepts/workloads/pods/pod-lifecycle/) +* 了解 [PodPresets](/zh/docs/concepts/workloads/pods/podpreset/) +* 了解 [RuntimeClass](/zh/docs/concepts/containers/runtime-class/)，以及如何使用它 + 来配置不同的 Pod 使用不同的容器运行时配置 +* 了解 [Pod 拓扑分布约束](/zh/docs/concepts/workloads/pods/pod-topology-spread-constraints/) +* 了解 [PodDisruptionBudget](/zh/docs/concepts/workloads/pods/disruptions/)，以及你 + 如何可以利用它在出现干扰因素时管理应用的可用性 +* Pod 在 Kubernetes REST API 中是一个顶层资源； + [Pod](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#pod-v1-core) + 对象的定义中包含了更多的细节信息。 +* 博客 [The Distributed System Toolkit: Patterns for Composite Containers](https://kubernetes.io/blog/2015/06/the-distributed-system-toolkit-patterns) 中解释了在同一 Pod 中包含多个容器时的几种常见布局。 + +<!-- +To understand the context for why Kubernetes wraps a common Pod API in other resources (such as {{< glossary_tooltip text="StatefulSets" term_id="statefulset" >}} or {{< glossary_tooltip text="Deployments" term_id="deployment" >}}, you can read about the prior art, including: +--> +要了解为什么 Kubernetes 会在其他资源 +（如 {{< glossary_tooltip text="StatefulSet" term_id="statefulset" >}} +或 {{< glossary_tooltip text="Deployment" term_id="deployment" >}}） +封装通用的 Pod API，相关的背景信息可以在前人的研究中找到。具体包括： + + * [Aurora](http://aurora.apache.org/documentation/latest/reference/configuration/#job-schema) + * [Borg](https://research.google.com/pubs/pub43438.html) + * [Marathon](https://mesosphere.github.io/marathon/docs/rest-api.html) + * [Omega](https://research.google/pubs/pub41684/) + * [Tupperware](https://engineering.fb.com/data-center-engineering/tupperware/). + diff --git a/content/zh/docs/concepts/workloads/pods/disruptions.md b/content/zh/docs/concepts/workloads/pods/disruptions.md index 7c53f556bd..304f3703d5 100644 --- a/content/zh/docs/concepts/workloads/pods/disruptions.md +++ b/content/zh/docs/concepts/workloads/pods/disruptions.md @@ -1,19 +1,13 @@ --- -title: 干扰 +title: 干扰（Disruptions） content_type: concept weight: 60 --- <!-- ---- -reviewers: -- erictune -- foxish -- davidopp title: Disruptions content_type: concept weight: 60 ---- --> <!-- overview --> @@ -22,31 +16,23 @@ This guide is for application owners who want to build highly available applications, and thus need to understand what types of Disruptions can happen to Pods. --> - 本指南针对的是希望构建高可用性应用程序的应用所有者，他们有必要了解可能发生在 pod 上的干扰类型。 <!-- It is also for Cluster Administrators who want to perform automated cluster actions, like upgrading and autoscaling clusters. --> - 文档同样适用于想要执行自动化集群操作（例如升级和自动扩展集群）的集群管理员。 - - - <!-- body --> <!-- ## Voluntary and Involuntary Disruptions ---> -## 自愿干扰和非自愿干扰 - -<!-- Pods do not disappear until someone (a person or a controller) destroys them, or there is an unavoidable hardware or system software error. --> +## 自愿干扰和非自愿干扰 {#voluntary-and-involuntary-disruptions} Pod 不会消失，除非有人（用户或控制器）将其销毁，或者出现了不可避免的硬件或软件系统错误。 @@ -54,8 +40,7 @@ Pod 不会消失，除非有人（用户或控制器）将其销毁，或者出 We call these unavoidable cases *involuntary disruptions* to an application. Examples are: --> - -我们把这些不可避免的情况称为应用的*非自愿干扰*。例如： +我们把这些不可避免的情况称为应用的*非自愿干扰（Involuntary Disruptions）*。例如： <!-- - a hardware failure of the physical machine backing the node @@ -71,14 +56,13 @@ an application. Examples are: - 云提供商或虚拟机管理程序中的故障导致的虚拟机消失 - 内核错误 - 节点由于集群网络隔离从集群中消失 -- 由于节点[资源不足](/docs/tasks/administer-cluster/out-of-resource/)导致 pod 被驱逐。 +- 由于节点[资源不足](/zh/docs/tasks/administer-cluster/out-of-resource/)导致 pod 被驱逐。 <!-- Except for the out-of-resources condition, all these conditions should be familiar to most users; they are not specific to Kubernetes. --> - 除了资源不足的情况，大多数用户应该都熟悉这些情况；它们不是特定于 Kubernetes 的。 <!-- @@ -86,8 +70,8 @@ We call other cases *voluntary disruptions*. These include both actions initiated by the application owner and those initiated by a Cluster Administrator. Typical application owner actions include: --> - -我们称其他情况为*自愿干扰*。包括由应用程序所有者发起的操作和由集群管理员发起的操作。典型的应用程序所有者的 +我们称其他情况为*自愿干扰（Voluntary Disruptions）*。 +包括由应用程序所有者发起的操作和由集群管理员发起的操作。典型的应用程序所有者的操 作包括： <!-- @@ -95,34 +79,29 @@ Administrator. Typical application owner actions include: - updating a deployment's pod template causing a restart - directly deleting a pod (e.g. by accident) --> - -- 删除 deployment 或其他管理 pod 的控制器 -- 更新了 deployment 的 pod 模板导致 pod 重启 -- 直接删除 pod（例如，因为误操作） +- 删除 Deployment 或其他管理 Pod 的控制器 +- 更新了 Deployment 的 Pod 模板导致 Pod 重启 +- 直接删除 Pod（例如，因为误操作） <!-- Cluster Administrator actions include: ---> -集群管理员操作包括： - -<!-- - [Draining a node](/docs/tasks/administer-cluster/safely-drain-node/) for repair or upgrade. - Draining a node from a cluster to scale the cluster down (learn about [Cluster Autoscaling](/docs/tasks/administer-cluster/cluster-management/#cluster-autoscaler) ). - Removing a pod from a node to permit something else to fit on that node. --> +集群管理员操作包括： -- [排空（drain）节点](/docs/tasks/administer-cluster/safely-drain-node/)进行修复或升级。 -- 从集群中排空节点以缩小集群（了解[集群自动扩缩](/docs/tasks/administer-cluster/cluster-management/#cluster-autoscaler)）。 -- 从节点中移除一个 pod，以允许其他 pod 使用该节点。 +- [排空（drain）节点](/zh/docs/tasks/administer-cluster/safely-drain-node/)进行修复或升级。 +- 从集群中排空节点以缩小集群（了解[集群自动扩缩](/zh/docs/tasks/administer-cluster/cluster-management/#cluster-autoscaler)）。 +- 从节点中移除一个 Pod，以允许其他 Pod 使用该节点。 <!-- These actions might be taken directly by the cluster administrator, or by automation run by the cluster administrator, or by your cluster hosting provider. --> - 这些操作可能由集群管理员直接执行，也可能由集群管理员所使用的自动化工具执行，或者由集群托管提供商自动执行。 <!-- @@ -130,29 +109,24 @@ Ask your cluster administrator or consult your cloud provider or distribution do to determine if any sources of voluntary disruptions are enabled for your cluster. If none are enabled, you can skip creating Pod Disruption Budgets. --> - -咨询集群管理员或联系云提供商，或者查询发布文档，以确定是否为集群启用了任何资源干扰源。如果没有启用，可以不用创建 Pod Disruption Budgets（Pod 干扰预算） - -{{< caution >}} +咨询集群管理员或联系云提供商，或者查询发布文档，以确定是否为集群启用了任何资源干扰源。 +如果没有启用，可以不用创建 Pod Disruption Budgets（Pod 干扰预算） <!-- Not all voluntary disruptions are constrained by Pod Disruption Budgets. For example, deleting deployments or pods bypasses Pod Disruption Budgets. --> - -并非所有的自愿干扰都会受到 pod 干扰预算的限制。例如，删除 deployment 或 pod 的删除操作就会跳过 pod 干扰预算检查。 - +{{< caution >}} +并非所有的自愿干扰都会受到 Pod 干扰预算的限制。 +例如，删除 Peployment 或 Pod 的删除操作就会跳过 Pod 干扰预算检查。 {{< /caution >}} <!-- ## Dealing with Disruptions ---> -## 处理干扰 - -<!-- Here are some ways to mitigate involuntary disruptions: --> +## 处理干扰 以下是减轻非自愿干扰的一些方法： @@ -167,10 +141,13 @@ spread applications across racks (using or across zones (if using a [multi-zone cluster](/docs/setup/multiple-zones).) --> - -- 确保 pod[请求所需资源](/docs/tasks/configure-pod-container/assign-cpu-ram-container)。 -- 如果需要更高的可用性，请复制应用程序。（了解有关运行多副本的[无状态](/docs/tasks/run-application/run-stateless-application-deployment/)和[有状态](/docs/tasks/run-application/run-replicated-stateful-application/)应用程序的信息。） -- 为了在运行复制应用程序时获得更高的可用性，请跨机架（使用[反亲和性](/docs/user-guide/node-selection/#inter-pod-affinity-and-anti-affinity-beta-feature)）或跨区域（如果使用[多区域集群](/docs/setup/multiple-zones)）扩展应用程序。 +- 确保 Pod 在请求中给出[所需资源](/zh/docs/tasks/configure-pod-container/assign-memory-resource/)。 +- 如果需要更高的可用性，请复制应用程序。 + （了解有关运行多副本的[无状态](/zh/docs/tasks/run-application/run-stateless-application-deployment/) + 和[有状态](/zh/docs/tasks/run-application/run-replicated-stateful-application/)应用程序的信息。） +- 为了在运行复制应用程序时获得更高的可用性，请跨机架（使用 + [反亲和性](/zh/docs/concepts/scheduling-eviction/assign-pod-node/)）或跨区域 + （如果使用[多区域集群](/zh/docs/setup/best-practices/multiple-zones/)）扩展应用程序。 <!-- The frequency of voluntary disruptions varies. On a basic Kubernetes cluster, there are @@ -181,7 +158,6 @@ of cluster (node) autoscaling may cause voluntary disruptions to defragment and Your cluster administrator or hosting provider should have documented what level of voluntary disruptions, if any, to expect. --> - 自愿干扰的频率各不相同。在一个基本的 Kubernetes 集群中，根本没有自愿干扰。然而，集群管理 或托管提供商可能运行一些可能导致自愿干扰的额外服务。例如，节点软 更新可能导致自愿干扰。另外，集群（节点）自动缩放的某些 @@ -193,16 +169,15 @@ Kubernetes offers features to help run highly available applications at the same time as frequent voluntary disruptions. We call this set of features *Disruption Budgets*. --> - -Kubernetes 提供特性来满足在出现频繁自愿干扰的同时运行高可用的应用程序。我们称这些特性为*干扰预算* +Kubernetes 提供特性来满足在出现频繁自愿干扰的同时运行高可用的应用程序。我们称这些特性为 +*干扰预算（Disruption Budget）*。 <!-- -## How Disruption Budgets Work ---> +## Pod disruption budgets -## 干扰预算工作原理 +Kubernetes offers features to help you run highly available applications even when you +introduce frequent voluntary disruptions. -<!-- An Application Owner can create a `PodDisruptionBudget` object (PDB) for each application. A PDB limits the number of pods of a replicated application that are down simultaneously from voluntary disruptions. For example, a quorum-based application would @@ -211,9 +186,16 @@ number needed for a quorum. A web front end might want to ensure that the number of replicas serving load never falls below a certain percentage of the total. --> +## 干扰预算 -应用程序所有者可以为每个应用程序创建 `PodDisruptionBudget` 对象（PDB）。PDB 将限制在同一时间因自愿干扰导致的复制应用程序中宕机的 pod 数量。例如，基于定额的应用程序希望确保运行的副本数 -永远不会低于仲裁所需的数量。Web 前端可能希望确保提供负载的副本数量永远不会低于总数的某个百分比。 +{{< feature-state for_k8s_version="v1.5" state="beta" >}} + +即使你会经常引入自愿性干扰，Kubernetes 也能够支持你运行高度可用的应用。 + +应用程序所有者可以为每个应用程序创建 `PodDisruptionBudget` 对象（PDB）。 +PDB 将限制在同一时间因自愿干扰导致的复制应用程序中宕机的 pod 数量。 +例如，基于票选机制的应用程序希望确保运行的副本数永远不会低于仲裁所需的数量。 +Web 前端可能希望确保提供负载的副本数量永远不会低于总数的某个百分比。 <!-- Cluster managers and hosting providers should use tools which @@ -221,18 +203,21 @@ respect Pod Disruption Budgets by calling the [Eviction API](/docs/tasks/adminis instead of directly deleting pods or deployments. Examples are the `kubectl drain` command and the Kubernetes-on-GCE cluster upgrade script (`cluster/gce/upgrade.sh`). --> - -集群管理员和托管提供商应该使用遵循 Pod Disruption Budgets 的接口（通过调用[驱逐 API](/docs/tasks/administer-cluster/safely-drain-node/#the-eviction-api)），而不是直接删除 pod 或 deployment。示例包括 `kubectl drain` 命令和 Kubernetes-on-GCE 集群升级脚本（`cluster/gce/upgrade.sh`）。 +集群管理员和托管提供商应该使用遵循 Pod Disruption Budgets 的接口 +（通过调用[Eviction API](/zh/docs/tasks/administer-cluster/safely-drain-node/#the-eviction-api)）， +而不是直接删除 Pod 或 Deployment。 <!-- -When a cluster administrator wants to drain a node -they use the `kubectl drain` command. That tool tries to evict all -the pods on the machine. The eviction request may be temporarily rejected, +For example, the `kubectl drain` subcommand lets you mark a node as going out of +service. When you run `kubectl drain`, the tool tries to evict all of the Pods on +the Node you'are taking out of service. The eviction request may be temporarily rejected, and the tool periodically retries all failed requests until all pods are terminated, or until a configurable timeout is reached. --> - -当集群管理员想排空一个节点时，可以使用 `kubectl drain` 命令。该命令试图驱逐机器上的所有 pod。驱逐请求可能会暂时被拒绝，且该工具定时重试失败的请求直到所有的 pod 都被终止，或者达到配置的超时时间。 +例如，`kubectl drain` 命令可以用来标记某个节点即将停止服务。 +运行 `kubectl drain` 命令时，工具会尝试驱逐机器上的所有 Pod。 +`kubectl` 所提交的驱逐请求可能会暂时被拒绝，所以该工具会定时重试失败的请求， +直到所有的 Pod 都被终止，或者达到配置的超时时间。 <!-- A PDB specifies the number of replicas that an application can tolerate having, relative to how @@ -240,64 +225,66 @@ many it is intended to have. For example, a Deployment which has a `.spec.repli supposed to have 5 pods at any given time. If its PDB allows for there to be 4 at a time, then the Eviction API will allow voluntary disruption of one, but not two pods, at a time. --> - -PDB 指定应用程序可以容忍的副本数量（相当于应该有多少副本）。例如，具有 `.spec.replicas: 5` 的 deployment 在任何时间都应该有 5 个 pod。如果 PDB 允许其在某一时刻有 4 个副本，那么驱逐 API 将允许同一时刻仅有一个而不是两个 pod 自愿干扰。 +PDB 指定应用程序可以容忍的副本数量（相当于应该有多少副本）。 +例如，具有 `.spec.replicas: 5` 的 Deployment 在任何时间都应该有 5 个 Pod。 +如果 PDB 允许其在某一时刻有 4 个副本，那么驱逐 API 将允许同一时刻仅有一个而不是两个 Pod 自愿干扰。 <!-- The group of pods that comprise the application is specified using a label selector, the same as the one used by the application's controller (deployment, stateful-set, etc). --> - -使用标签选择器来指定构成应用程序的一组 pod，这与应用程序的控制器（deployment，stateful-set 等）选择 pod 的逻辑一样。 +使用标签选择器来指定构成应用程序的一组 Pod，这与应用程序的控制器（Deployment，StatefulSet 等） +选择 Pod 的逻辑一样。 <!-- The "intended" number of pods is computed from the `.spec.replicas` of the pods controller. The controller is discovered from the pods using the `.metadata.ownerReferences` of the object. --> - -Pod 控制器的 `.spec.replicas` 计算“预期的” pod 数量。根据 pod 对象的 `.metadata.ownerReferences` 字段来发现控制器。 +Pod 控制器的 `.spec.replicas` 计算“预期的” Pod 数量。 +根据 Pod 对象的 `.metadata.ownerReferences` 字段来发现控制器。 <!-- PDBs cannot prevent [involuntary disruptions](#voluntary-and-involuntary-disruptions) from occurring, but they do count against the budget. --> - PDB 不能阻止[非自愿干扰](#voluntary-and-involuntary-disruptions)的发生，但是确实会计入 -算。 +预算。 <!-- Pods which are deleted or unavailable due to a rolling upgrade to an application do count against the disruption budget, but controllers (like deployment and stateful-set) -are not limited by PDBs when doing rolling upgrades -- the handling of failures -during application updates is configured in the controller spec. -(Learn about [updating a deployment](/docs/concepts/workloads/controllers/deployment/#updating-a-deployment).) +are not limited by PDBs when doing rolling upgrades - the handling of failures +during application updates is configured in spec for the specific workload resource. --> - -由于应用程序的滚动升级而被删除或不可用的 pod 确实会计入干扰预算，但是控制器（如 deployment 和 stateful-set）在进行滚动升级时不受 PDB -的限制。应用程序更新期间的故障处理是在控制器的 spec 中配置的。（了解[更新 deployment](/docs/concepts/workloads/controllers/deployment/#updating-a-deployment)。） +由于应用程序的滚动升级而被删除或不可用的 Pod 确实会计入干扰预算， +但是控制器（如 Deployment 和 StatefulSet）在进行滚动升级时不受 PDB +的限制。应用程序更新期间的故障处理方式是在对应的工作负载资源的 `spec` 中配置的。 <!-- -When a pod is evicted using the eviction API, it is gracefully terminated (see -`terminationGracePeriodSeconds` in [PodSpec](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podspec-v1-core).) +When a pod is evicted using the eviction API, it is gracefully +[terminated](/docs/concepts/workloads/pods/pod-lifecycle/#pod-termination), +hornoring the +`terminationGracePeriodSeconds` setting in its [PodSpec](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podspec-v1-core).) --> - -当使用驱逐 API 驱逐 pod 时，pod 会被优雅地终止（参考 [PodSpec](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podspec-v1-core) 中的 `terminationGracePeriodSeconds`）。 +当使用驱逐 API 驱逐 Pod 时，Pod 会被体面地 +[终止](/docs/concepts/workloads/pods/pod-lifecycle/#pod-termination)，期间会 +参考 [PodSpec](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podspec-v1-core) +中的 `terminationGracePeriodSeconds` 配置值。 <!-- ## PDB Example ---> -## PDB 例子 - -<!-- Consider a cluster with 3 nodes, `node-1` through `node-3`. The cluster is running several applications. One of them has 3 replicas initially called `pod-a`, `pod-b`, and `pod-c`. Another, unrelated pod without a PDB, called `pod-x`, is also shown. Initially, the pods are laid out as follows: --> +## PDB 例子 {#pdb-example} -假设集群有 3 个节点，`node-1` 到 `node-3`。集群上运行了一些应用。其中一个应用有 3 个副本，分别是 `pod-a`，`pod-b` 和 `pod-c`。另外，还有一个不带 PDB 的无关 pod `pod-x` 也同样显示。最初，所有的 pod 分布如下： - +假设集群有 3 个节点，`node-1` 到 `node-3`。集群上运行了一些应用。 +其中一个应用有 3 个副本，分别是 `pod-a`，`pod-b` 和 `pod-c`。 +另外，还有一个不带 PDB 的无关 pod `pod-x` 也同样显示出来。 +最初，所有的 Pod 分布如下： | node-1 | node-2 | node-3 | |:--------------------:|:-------------------:|:------------------:| @@ -308,8 +295,7 @@ Initially, the pods are laid out as follows: All 3 pods are part of a deployment, and they collectively have a PDB which requires there be at least 2 of the 3 pods to be available at all times. --> - -3 个 pod 都是 deployment 的一部分，并且共同拥有同一个 PDB，要求 3 个 pod 中至少有 2 个 pod 始终处于可用状态。 +3 个 Pod 都是 deployment 的一部分，并且共同拥有同一个 PDB，要求 3 个 Pod 中至少有 2 个 Pod 始终处于可用状态。 <!-- For example, assume the cluster administrator wants to reboot into a new kernel version to fix a bug in the kernel. @@ -319,7 +305,10 @@ Both pods go into the `terminating` state at the same time. This puts the cluster in this state: --> -例如，假设集群管理员想要重启系统，升级内核版本来修复内核中的 bug。集群管理员首先使用 `kubectl drain` 命令尝试排空 `node-1` 节点。命令尝试驱逐 `pod-a` 和 `pod-x`。操作立即就成功了。两个 pod 同时进入 `terminating` 状态。这时的集群处于下面的状态： +例如，假设集群管理员想要重启系统，升级内核版本来修复内核中的权限。 +集群管理员首先使用 `kubectl drain` 命令尝试排空 `node-1` 节点。 +命令尝试驱逐 `pod-a` 和 `pod-x`。操作立即就成功了。 +两个 Pod 同时进入 `terminating` 状态。这时的集群处于下面的状态： | node-1 *draining* | node-2 | node-3 | |:--------------------:|:-------------------:|:------------------:| @@ -331,21 +320,21 @@ The deployment notices that one of the pods is terminating, so it creates a repl called `pod-d`. Since `node-1` is cordoned, it lands on another node. Something has also created `pod-y` as a replacement for `pod-x`. --> - -Deployment 控制器观察到其中一个 pod 正在终止，因此它创建了一个替代 pod `pod-d`。由于 `node-1` 被封锁（cordon），`pod-d` 落在另一个节点上。同样其他控制器也创建了 `pod-y` 作为 `pod-x` 的替代品。 +Deployment 控制器观察到其中一个 Pod 正在终止，因此它创建了一个替代 Pod `pod-d`。 +由于 `node-1` 被封锁（cordon），`pod-d` 落在另一个节点上。 +同样其他控制器也创建了 `pod-y` 作为 `pod-x` 的替代品。 <!-- (Note: for a StatefulSet, `pod-a`, which would be called something like `pod-0`, would need to terminate completely before its replacement, which is also called `pod-0` but has a different UID, could be created. Otherwise, the example applies to a StatefulSet as well.) --> - -（注意：对于 StatefulSet 来说，`pod-a`（也称为 `pod-0`）需要在替换 pod 创建之前完全终止，替代它的也称为 `pod-0`，但是具有不同的 UID。反之，样例也适用于 StatefulSet。） +（注意：对于 StatefulSet 来说，`pod-a`（也称为 `pod-0`）需要在替换 Pod 创建之前完全终止， +替代它的也称为 `pod-0`，但是具有不同的 UID。除此之外，此示例也适用于 StatefulSet。） <!-- Now the cluster is in this state: --> - 当前集群的状态如下： | node-1 *draining* | node-2 | node-3 | @@ -356,8 +345,7 @@ Now the cluster is in this state: <!-- At some point, the pods terminate, and the cluster looks like this: --> - -在某一时刻，pod 被终止，集群如下所示： +在某一时刻，Pod 被终止，集群如下所示： | node-1 *drained* | node-2 | node-3 | |:--------------------:|:-------------------:|:------------------:| @@ -369,13 +357,13 @@ At this point, if an impatient cluster administrator tries to drain `node-2` or `node-3`, the drain command will block, because there are only 2 available pods for the deployment, and its PDB requires at least 2. After some time passes, `pod-d` becomes available. --> - -此时，如果一个急躁的集群管理员试图排空（drain）`node-2` 或 `node-3`，drain 命令将被阻塞，因为对于 deployment 来说只有 2 个可用的 pod，并且它的 PDB 至少需要 2 个。经过一段时间，`pod-d` 变得可用。 +此时，如果一个急躁的集群管理员试图排空（drain）`node-2` 或 `node-3`，drain 命令将被阻塞， +因为对于 Deployment 来说只有 2 个可用的 Pod，并且它的 PDB 至少需要 2 个。 +经过一段时间，`pod-d` 变得可用。 <!-- The cluster state now looks like this: --> - 集群状态如下所示： | node-1 *drained* | node-2 | node-3 | @@ -390,8 +378,10 @@ The drain command will try to evict the two pods in some order, say But, when it tries to evict `pod-d`, it will be refused because that would leave only one pod available for the deployment. --> - -现在，集群管理员试图排空（drain）`node-2`。drain 命令将尝试按照某种顺序驱逐两个 pod，假设先是 `pod-b`，然后是 `pod-d`。命令成功驱逐 `pod-b`，但是当它尝试驱逐 `pod-d`时将被拒绝，因为对于 deployment 来说只剩一个可用的 pod 了。 +现在，集群管理员试图排空（drain）`node-2`。 +drain 命令将尝试按照某种顺序驱逐两个 Pod，假设先是 `pod-b`，然后是 `pod-d`。 +命令成功驱逐 `pod-b`，但是当它尝试驱逐 `pod-d`时将被拒绝，因为对于 +Deployment 来说只剩一个可用的 Pod 了。 <!-- The deployment creates a replacement for `pod-b` called `pod-e`. @@ -399,8 +389,8 @@ Because there are not enough resources in the cluster to schedule `pod-e` the drain will again block. The cluster may end up in this state: --> - -Deployment 创建 `pod-b` 的替代 pod `pod-e`。因为集群中没有足够的资源来调度 `pod-e`，drain 命令再次阻塞。集群最终将是下面这种状态： +Deployment 创建 `pod-b` 的替代 Pod `pod-e`。 +因为集群中没有足够的资源来调度 `pod-e`，drain 命令再次阻塞。集群最终将是下面这种状态： | node-1 *drained* | node-2 | node-3 | *no node* | |:--------------------:|:-------------------:|:------------------:|:------------------:| @@ -411,14 +401,12 @@ Deployment 创建 `pod-b` 的替代 pod `pod-e`。因为集群中没有足够的 At this point, the cluster administrator needs to add a node back to the cluster to proceed with the upgrade. --> - 此时，集群管理员需要增加一个节点到集群中以继续升级操作。 <!-- You can see how Kubernetes varies the rate at which disruptions can happen, according to: --> - 可以看到 Kubernetes 如何改变干扰发生的速率，根据： <!-- @@ -428,7 +416,6 @@ can happen, according to: - the type of controller - the cluster's resource capacity --> - - 应用程序需要多少个副本 - 优雅关闭应用实例需要多长时间 - 启动应用新实例需要多长时间 @@ -437,16 +424,13 @@ can happen, according to: <!-- ## Separating Cluster Owner and Application Owner Roles ---> -## 分离集群所有者和应用所有者角色 - -<!-- Often, it is useful to think of the Cluster Manager and Application Owner as separate roles with limited knowledge of each other. This separation of responsibilities may make sense in these scenarios: --> +## 分离集群所有者和应用所有者角色 通常，将集群管理者和应用所有者视为彼此了解有限的独立角色是很有用的。这种责任分离在下面这些场景下是有意义的： @@ -455,7 +439,6 @@ may make sense in these scenarios: there is natural specialization of roles - when third-party tools or services are used to automate cluster management --> - - 当有许多应用程序团队共用一个 Kubernetes 集群，并且有自然的专业角色 - 当第三方工具或服务用于集群自动化管理 @@ -463,30 +446,24 @@ may make sense in these scenarios: Pod Disruption Budgets support this separation of roles by providing an interface between the roles. --> - Pod 干扰预算通过在角色之间提供接口来支持这种分离。 <!-- If you do not have such a separation of responsibilities in your organization, you may not need to use Pod Disruption Budgets. --> - 如果你的组织中没有这样的责任分离，则可能不需要使用 Pod 干扰预算。 <!-- ## How to perform Disruptive Actions on your Cluster ---> -## 如何在集群上执行干扰操作 - -<!-- If you are a Cluster Administrator, and you need to perform a disruptive action on all the nodes in your cluster, such as a node or system software upgrade, here are some options: --> +## 如何在集群上执行干扰性操作 如果你是集群管理员，并且需要对集群中的所有节点执行干扰操作，例如节点或系统软件升级，则可以使用以下选项 - <!-- - Accept downtime during the upgrade. - Failover to another complete replica cluster. @@ -509,25 +486,18 @@ the nodes in your cluster, such as a node or system software upgrade, here are s - 最小的资源重复。 - 允许更多的集群管理自动化。 - 编写可容忍干扰的应用程序是棘手的，但对于支持容忍自愿干扰所做的工作，和支持自动扩缩和容忍非 - 愿干扰所做工作相比，有大量的重叠 - - - + 自愿干扰所做工作相比，有大量的重叠 ## {{% heading "whatsnext" %}} - <!-- * Follow steps to protect your application by [configuring a Pod Disruption Budget](/docs/tasks/run-application/configure-pdb/). ---> - -* 参考[配置 Pod 干扰预算](/docs/tasks/run-application/configure-pdb/)中的方法来保护你的 -用。 - -<!-- * Learn more about [draining nodes](/docs/tasks/administer-cluster/safely-drain-node/) +* Learn about [updating a deployment](/docs/concepts/workloads/controllers/deployment/#updating-a-deployment) + including steps to maintain its availability during the rollout. --> - -* 了解更多关于[排空节点](/docs/tasks/administer-cluster/safely-drain-node/)的信息。 - +* 参考[配置 Pod 干扰预算](/zh/docs/tasks/run-application/configure-pdb/)中的方法来保护你的应用。 +* 进一步了解[排空节点](/zh/docs/tasks/administer-cluster/safely-drain-node/)的信息。 +* 了解[更新 Deployment](/zh/docs/concepts/workloads/controllers/deployment/#updating-a-deployment) + 的过程，包括如何在其进程中维持应用的可用性 diff --git a/content/zh/docs/concepts/workloads/pods/ephemeral-containers.md b/content/zh/docs/concepts/workloads/pods/ephemeral-containers.md index 7e9a894d8d..430a1d3c55 100644 --- a/content/zh/docs/concepts/workloads/pods/ephemeral-containers.md +++ b/content/zh/docs/concepts/workloads/pods/ephemeral-containers.md @@ -5,14 +5,9 @@ weight: 80 --- <!-- ---- -reviewers: -- verb -- yujuhong title: Ephemeral Containers content_type: concept weight: 80 ---- --> <!-- overview --> @@ -21,12 +16,13 @@ weight: 80 <!-- This page provides an overview of ephemeral containers: a special type of container -that runs temporarily in an existing {{< glossary_tooltip term_id="pod" >}} to accomplish user-initiated actions such -as troubleshooting. You use ephemeral containers to inspect services rather than -to build applications. +that runs temporarily in an existing {{< glossary_tooltip term_id="pod" >}} to +accomplish user-initiated actions such as troubleshooting. You use ephemeral +containers to inspect services rather than to build applications. --> - -此页面概述了临时容器：一种特殊的容器，该容器在现有 {{< glossary_tooltip term_id="pod" >}} 中临时运行，为了完成用户启动的操作，例如故障排查。使用临时容器来检查服务，而不是构建应用程序。 +本页面概述了临时容器：一种特殊的容器，该容器在现有 {{< glossary_tooltip text="Pod" term_id="pod" >}} +中临时运行，以便完成用户发起的操作，例如故障排查。 +你会使用临时容器来检查服务，而不是用它来构建应用程序。 <!-- Ephemeral containers are in early alpha state and are not suitable for production @@ -35,30 +31,30 @@ when targeting the namespaces of a container. In accordance with the [Kubernetes Deprecation Policy](/docs/reference/using-api/deprecation-policy/), this alpha feature could change significantly in the future or be removed entirely. --> - {{< warning >}} -临时容器处于早期的 alpha 阶段，不适用于生产环境集群。应该预料到临时容器在某些情况下不起作用，例如在定位容器的命名空间时。根据 [Kubernetes 弃用政策](/docs/reference/using-api/deprecation-policy/)，该 alpha 功能将来可能发生重大变化或完全删除。 +临时容器处于早期的 alpha 阶段，不适用于生产环境集群。 +应该预料到临时容器在某些情况下不起作用，例如在定位容器的命名空间时。 +根据 [Kubernetes 弃用政策](/zh/docs/reference/using-api/deprecation-policy/)， +此 alpha 功能将来可能发生重大变化或被完全删除。 {{< /warning >}} - - <!-- body --> <!-- ## Understanding ephemeral containers ---> -## 了解临时容器 - -<!-- {{< glossary_tooltip text="Pods" term_id="pod" >}} are the fundamental building block of Kubernetes applications. Since Pods are intended to be disposable and replaceable, you cannot add a container to a Pod once it has been created. Instead, you usually delete and replace Pods in a controlled fashion using {{< glossary_tooltip text="deployments" term_id="deployment" >}}. --> +## 了解临时容器 -{{< glossary_tooltip text="Pods" term_id="pod" >}} 是 Kubernetes 应用程序的基本构建块。由于 pod 是一次性且可替换的，因此一旦 Pod 创建，就无法将容器加入到 Pod 中。取而代之的是，通常使用 {{< glossary_tooltip text="deployments" term_id="deployment" >}} 以受控的方式来删除并替换 Pod。 +{{< glossary_tooltip text="Pod" term_id="pod" >}} 是 Kubernetes 应用程序的基本构建块。 +由于 Pod 是一次性且可替换的，因此一旦 Pod 创建，就无法将容器加入到 Pod 中。 +取而代之的是，通常使用 {{< glossary_tooltip text="Deployment" term_id="deployment" >}} +以受控的方式来删除并替换 Pod。 <!-- Sometimes it's necessary to inspect the state of an existing Pod, however, for @@ -66,24 +62,23 @@ example to troubleshoot a hard-to-reproduce bug. In these cases you can run an ephemeral container in an existing Pod to inspect its state and run arbitrary commands. --> - -有时有必要检查现有 Pod 的状态，例如，对于难以复现的故障进行排查。在这些场景中，可以在现有 Pod 中运行临时容器来检查其状态并运行任意命令。 +有时有必要检查现有 Pod 的状态。例如，对于难以复现的故障进行排查。 +在这些场景中，可以在现有 Pod 中运行临时容器来检查其状态并运行任意命令。 <!-- ### What is an ephemeral container? ---> -### 什么是临时容器？ - -<!-- Ephemeral containers differ from other containers in that they lack guarantees for resources or execution, and they will never be automatically restarted, so they are not appropriate for building applications. Ephemeral containers are described using the same `ContainerSpec` as regular containers, but many fields are incompatible and disallowed for ephemeral containers. --> +### 什么是临时容器？ -临时容器与其他容器的不同之处在于，它们缺少对资源或执行的保证，并且永远不会自动重启，因此不适用于构建应用程序。临时容器使用与常规容器相同的 `ContainerSpec` 段进行描述，但许多字段是不相容且不允许的。 +临时容器与其他容器的不同之处在于，它们缺少对资源或执行的保证，并且永远不会自动重启， +因此不适用于构建应用程序。 +临时容器使用与常规容器相同的 `ContainerSpec` 节来描述，但许多字段是不兼容和不允许的。 <!-- - Ephemeral containers may not have ports, so fields such as `ports`, @@ -92,39 +87,39 @@ are incompatible and disallowed for ephemeral containers. - For a complete list of allowed fields, see the [EphemeralContainer reference documentation](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#ephemeralcontainer-v1-core). --> +- 临时容器没有端口配置，因此像 `ports`，`livenessProbe`，`readinessProbe` + 这样的字段是不允许的。 -- 临时容器没有端口配置，因此像 `ports`，`livenessProbe`，`readinessProbe` 这样的字段是不允许的。 - Pod 资源分配是不可变的，因此 `resources` 配置是不允许的。 -- 有关允许字段的完整列表，请参见[临时容器参考文档](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#ephemeralcontainer-v1-core)。 + +- 有关允许字段的完整列表，请参见 + [EphemeralContainer 参考文档](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#ephemeralcontainer-v1-core)。 <!-- Ephemeral containers are created using a special `ephemeralcontainers` handler in the API rather than by adding them directly to `pod.spec`, so it's not possible to add an ephemeral container using `kubectl edit`. --> - -临时容器是使用 API 中的一种特殊的 `ephemeralcontainers` 处理器进行创建的，而不是直接添加到 `pod.spec` 段，因此无法使用 `kubectl edit` 来添加一个临时容器。 +临时容器是使用 API 中的一种特殊的 `ephemeralcontainers` 处理器进行创建的， +而不是直接添加到 `pod.spec` 段，因此无法使用 `kubectl edit` 来添加一个临时容器。 <!-- Like regular containers, you may not change or remove an ephemeral container after you have added it to a Pod. --> - 与常规容器一样，将临时容器添加到 Pod 后，将不能更改或删除临时容器。 <!-- ## Uses for ephemeral containers ---> -## 临时容器的用途 - -<!-- Ephemeral containers are useful for interactive troubleshooting when `kubectl exec` is insufficient because a container has crashed or a container image doesn't include debugging utilities. --> +## 临时容器的用途 -当由于容器崩溃或容器镜像不包含调试实用程序而导致 `kubectl exec` 无用时，临时容器对于交互式故障排查很有用。 +当由于容器崩溃或容器镜像不包含调试工具而导致 `kubectl exec` 无用时， +临时容器对于交互式故障排查很有用。 <!-- In particular, [distroless images](https://github.com/GoogleContainerTools/distroless) @@ -133,31 +128,32 @@ and exposure to bugs and vulnerabilities. Since distroless images do not include shell or any debugging utilities, it's difficult to troubleshoot distroless images using `kubectl exec` alone. --> - -尤其是，[distroless 镜像](https://github.com/GoogleContainerTools/distroless)能够使得部署最小的容器镜像，从而减少攻击面并减少故障和漏洞的暴露。由于 distroless 镜像不包含 shell 或任何的调试工具，因此很难单独使用 `kubectl exec` 命令进行故障排查。 +尤其是，[distroless 镜像](https://github.com/GoogleContainerTools/distroless) +允许用户部署最小的容器镜像，从而减少攻击面并减少故障和漏洞的暴露。 +由于 distroless 镜像不包含 Shell 或任何的调试工具，因此很难单独使用 +`kubectl exec` 命令进行故障排查。 <!-- When using ephemeral containers, it's helpful to enable [process namespace sharing](/docs/tasks/configure-pod-container/share-process-namespace/) so you can view processes in other containers. --> - -使用临时容器时，启用[进程命名空间共享](/docs/tasks/configure-pod-container/share-process-namespace/)很有帮助，可以查看其他容器中的进程。 +使用临时容器时，启用[进程名字空间共享](/zh/docs/tasks/configure-pod-container/share-process-namespace/) +很有帮助，可以查看其他容器中的进程。 <!-- ### Examples ---> -### 示例 - -<!-- The examples in this section require the `EphemeralContainers` [feature gate](/docs/reference/command-line-tools-reference/feature-gates/) to be enabled, and Kubernetes client and server version v1.16 or later. --> +### 示例 {{< note >}} -本节中的示例要求启用 `EphemeralContainers` [特性](/docs/reference/command-line-tools-reference/feature-gates/)，并且 kubernetes 客户端和服务端版本要求为 v1.16 或更高版本。 +本节中的示例要求启用 `EphemeralContainers` +[特性门控](/zh/docs/reference/command-line-tools-reference/feature-gates/)， +并且 kubernetes 客户端和服务端版本要求为 v1.16 或更高版本。 {{< /note >}} <!-- @@ -165,16 +161,17 @@ The examples in this section demonstrate how ephemeral containers appear in the API. You would normally use a `kubectl` plugin for troubleshooting that automates these steps. --> - -本节中的示例演示了临时容器如何出现在 API 中。 通常，您可以使用 `kubectl` 插件进行故障排查，从而自动化执行这些步骤。 +本节中的示例演示了临时容器如何出现在 API 中。 +通常，你可以使用 `kubectl` 插件进行故障排查，从而自动化执行这些步骤。 <!-- Ephemeral containers are created using the `ephemeralcontainers` subresource -of Pod, which can be demonstrated using `kubectl --raw`. First describe +of Pod, which can be demonstrated using `kubectl -raw`. First describe the ephemeral container to add as an `EphemeralContainers` list: --> - -临时容器是使用 Pod 的 `ephemeralcontainers` 子资源创建的，可以使用 `kubectl --raw` 命令进行显示。首先描述临时容器被添加为一个 `EphemeralContainers` 列表： +临时容器是使用 Pod 的 `ephemeralcontainers` 子资源创建的，可以使用 +`kubectl --raw` 命令进行显示。 +首先描述临时容器被添加为一个 `EphemeralContainers` 列表： ```json { @@ -200,7 +197,6 @@ the ephemeral container to add as an `EphemeralContainers` list: <!-- To update the ephemeral containers of the already running `example-pod`: --> - 使用如下命令更新已运行的临时容器 `example-pod`： ```shell @@ -210,7 +206,6 @@ kubectl replace --raw /api/v1/namespaces/default/pods/example-pod/ephemeralconta <!-- This will return the new list of ephemeral containers: --> - 这将返回临时容器的新列表： ```json @@ -247,13 +242,14 @@ This will return the new list of ephemeral containers: <!-- You can view the state of the newly created ephemeral container using `kubectl describe`: --> - 可以使用以下命令查看新创建的临时容器的状态： ```shell kubectl describe pod example-pod ``` +输出为： + ``` ... Ephemeral Containers: @@ -277,7 +273,6 @@ Ephemeral Containers: <!-- You can attach to the new ephemeral container using `kubectl attach`: --> - 可以使用以下命令连接到新的临时容器： ```shell @@ -288,22 +283,16 @@ kubectl attach -it example-pod -c debugger If process namespace sharing is enabled, you can see processes from all the containers in that Pod. For example, after attaching, you run `ps` in the debugger container: --> - 如果启用了进程命名空间共享，则可以查看该 Pod 所有容器中的进程。 例如，运行上述 `attach` 操作后，在调试器容器中运行 `ps` 操作： -<!-- -# Run this in a shell inside the "debugger" ephemeral container -# 在 "debugger" 临时容器内中运行此 shell 命令 -The output is similar to: - ---> - ```shell # 在 "debugger" 临时容器内中运行此 shell 命令 ps auxww ``` + 运行命令后，输出类似于： + ``` PID USER TIME COMMAND 1 root 0:00 /pause @@ -321,4 +310,3 @@ PID USER TIME COMMAND 29 root 0:00 ps auxww ``` - diff --git a/content/zh/docs/concepts/workloads/pods/init-containers.md b/content/zh/docs/concepts/workloads/pods/init-containers.md index 0600c36b30..956b0518c2 100644 --- a/content/zh/docs/concepts/workloads/pods/init-containers.md +++ b/content/zh/docs/concepts/workloads/pods/init-containers.md @@ -12,30 +12,26 @@ This page provides an overview of init containers: specialized containers that r Init containers can contain utilities or setup scripts not present in an app image. --> -本页提供了 Init 容器的概览，它是一种专用的容器，在{{< glossary_tooltip text="Pod" term_id="pod" >}}内的应用容器启动之前运行，并包括一些应用镜像中不存在的实用工具和安装脚本。 - - +本页提供了 Init 容器的概览，它是一种特殊容器，在 {{< glossary_tooltip text="Pod" term_id="pod" >}} +内的应用容器启动之前运行，可以包括一些应用镜像中不存在的实用工具和安装脚本。 <!-- You can specify init containers in the Pod specification alongside the `containers` array (which describes app containers). --> -你可以在Pod的规格信息中与containers数组同级的位置指定 Init 容器。 -<!-- body --> +你可以在 Pod 的规约中与用来描述应用容器的 `containers` 数组平行的位置指定 +Init 容器。 +<!-- body --> <!-- ## Understanding init containers A {{< glossary_tooltip text="Pod" term_id="pod" >}} can have multiple containers running apps within it, but it can also have one or more init containers, which are run before the app containers are started. - --> - ## 理解 Init 容器 - - -{{< glossary_tooltip text="Pod" term_id="pod" >}} 可以包含多个容器，应用运行在这些容器里面，同时 Pod 也可以有一个或多个先于应用容器启动的 Init 容器。 - +每个 {{< glossary_tooltip text="Pod" term_id="pod" >}} 中可以包含多个容器， +应用运行在这些容器里面，同时 Pod 也可以有一个或多个先于应用容器启动的 Init 容器。 <!-- Init containers are exactly like regular containers, except: @@ -47,37 +43,40 @@ Init 容器与普通的容器非常像，除了如下两点： * 它们总是运行到完成。 * 每个都必须在下一个启动之前成功完成。 - <!-- If a Pod's init container fails, Kubernetes repeatedly restarts the Pod until the init container succeeds. However, if the Pod has a `restartPolicy` of Never, Kubernetes does not restart the Pod. --> -如果 Pod 的 Init 容器失败，Kubernetes 会不断地重启该 Pod，直到 Init 容器成功为止。然而，如果 Pod 对应的 `restartPolicy` 值为 Never，它不会重新启动。 - +如果 Pod 的 Init 容器失败，Kubernetes 会不断地重启该 Pod，直到 Init 容器成功为止。 +然而，如果 Pod 对应的 `restartPolicy` 值为 Never，Kubernetes 不会重新启动 Pod。 <!-- To specify an init container for a Pod, add the `initContainers` field into the Pod specification, as an array of objects of type [Container](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#container-v1-core), alongside the app `containers` array. The status of the init containers is returned in `.status.initContainerStatuses` field as an array of the container statuses (similar to the `.status.containerStatuses` field). --> -指定容器为 Init 容器，需要在 Pod 的 spec 中添加 `initContainers` 字段， 该字段內以[Container](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#container-v1-core) 类型对象数组的形式组织，和应用的 `containers` 数组同级相邻。 -Init 容器的状态在 `status.initContainerStatuses` 字段中以容器状态数组的格式返回（类似 `status.containerStatuses` 字段）。 - +为 Pod 设置 Init 容器需要在 Pod 的 `spec` 中添加 `initContainers` 字段， +该字段以 [Container](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#container-v1-core) +类型对象数组的形式组织，和应用的 `containers` 数组同级相邻。 +Init 容器的状态在 `status.initContainerStatuses` 字段中以容器状态数组的格式返回 +（类似 `status.containerStatuses` 字段）。 <!-- ### Differences from regular containers Init containers support all the fields and features of app containers, including resource limits, volumes, and security settings. However, the resource requests and limits for an init container are handled differently, as documented in [Resources](#resources). -Also, init containers do not support readiness probes because they must run to completion before the Pod can be ready. +Also, init containers do not support `lifecycle`, `livenessProbe`, `readinessProbe`, or `startupProbe` because they must run to completion before the Pod can be ready. If you specify multiple init containers for a Pod, Kubelet runs each init container sequentially. Each init container must succeed before the next can run. When all of the init containers have run to completion, Kubelet initializes the application containers for the Pod and runs them as usual. --> - ### 与普通容器的不同之处 -Init 容器支持应用容器的全部字段和特性，包括资源限制、数据卷和安全设置。 然而，Init 容器对资源请求和限制的处理稍有不同，在下面 [资源](#资源) 处有说明。 +Init 容器支持应用容器的全部字段和特性，包括资源限制、数据卷和安全设置。 +然而，Init 容器对资源请求和限制的处理稍有不同，在下面[资源](#resources)节有说明。 -同时 Init 容器不支持 Readiness Probe，因为它们必须在 Pod 就绪之前运行完成。 - -如果为一个 Pod 指定了多个 Init 容器，这些容器会按顺序逐个运行。每个 Init 容器必须运行成功，下一个才能够运行。当所有的 Init 容器运行完成时，Kubernetes 才会为 Pod 初始化应用容器并像平常一样运行。 +同时 Init 容器不支持 `lifecycle`、`livenessProbe`、`readinessProbe` 和 `startupProbe`， +因为它们必须在 Pod 就绪之前运行完成。 +如果为一个 Pod 指定了多个 Init 容器，这些容器会按顺序逐个运行。 +每个 Init 容器必须运行成功，下一个才能够运行。当所有的 Init 容器运行完成时， +Kubernetes 才会为 Pod 初始化应用容器并像平常一样运行。 <!-- ## Using init containers @@ -88,16 +87,24 @@ Because init containers have separate images from app containers, they have some * Init containers can run with a different view of the filesystem than app containers in the same Pod. Consequently, they can be given access to {{< glossary_tooltip text="Secrets" term_id="secret" >}} that app containers cannot access. * Because init containers run to completion before any app containers start, init containers offer a mechanism to block or delay app container startup until a set of preconditions are met. Once preconditions are met, all of the app containers in a Pod can start in parallel. --> -## Init 容器能做什么？ +## 使用 Init 容器 因为 Init 容器具有与应用容器分离的单独镜像，其启动相关代码具有如下优势： -* Init 容器可以包含一些安装过程中应用容器中不存在的实用工具或个性化代码。例如，没有必要仅为了在安装过程中使用类似 `sed`、 `awk`、 `python` 或 `dig` 这样的工具而去`FROM` 一个镜像来生成一个新的镜像。 -* Init 容器可以安全地运行这些工具，避免这些工具导致应用镜像的安全性降低。 -* 应用镜像的创建者和部署者可以各自独立工作，而没有必要联合构建一个单独的应用镜像。 -* Init 容器能以不同于Pod内应用容器的文件系统视图运行。因此，Init容器可具有访问 {{< glossary_tooltip text="Secrets" term_id="secret" >}} 的权限，而应用容器不能够访问。 -* 由于 Init 容器必须在应用容器启动之前运行完成，因此 Init 容器提供了一种机制来阻塞或延迟应用容器的启动，直到满足了一组先决条件。一旦前置条件满足，Pod内的所有的应用容器会并行启动。 +* Init 容器可以包含一些安装过程中应用容器中不存在的实用工具或个性化代码。 + 例如，没有必要仅为了在安装过程中使用类似 `sed`、`awk`、`python` 或 `dig` + 这样的工具而去 `FROM` 一个镜像来生成一个新的镜像。 +* Init 容器可以安全地运行这些工具，避免这些工具导致应用镜像的安全性降低。 + +* 应用镜像的创建者和部署者可以各自独立工作，而没有必要联合构建一个单独的应用镜像。 + +* Init 容器能以不同于 Pod 内应用容器的文件系统视图运行。因此，Init 容器可以访问 + 应用容器不能访问的 {{< glossary_tooltip text="Secret" term_id="secret" >}} 的权限。 + +* 由于 Init 容器必须在应用容器启动之前运行完成，因此 Init 容器 + 提供了一种机制来阻塞或延迟应用容器的启动，直到满足了一组先决条件。 + 一旦前置条件满足，Pod 内的所有的应用容器会并行启动。 <!-- ### Examples @@ -118,28 +125,34 @@ Here are some ideas for how to use init containers: * Clone a Git repository into a {{< glossary_tooltip text="Volume" term_id="volume" >}} * Place values into a configuration file and run a template tool to dynamically generate a configuration file for the main app container. For example, place the `POD_IP` value in a configuration and generate the main app configuration file using Jinja. - --> - -### 示例 +### 示例 {#examples} 下面是一些如何使用 Init 容器的想法： * 等待一个 Service 完成创建，通过类似如下 shell 命令： - for i in {1..100}; do sleep 1; if dig myservice; then exit 0; fi; exit 1 + ```shell + for i in {1..100}; do sleep 1; if dig myservice; then exit 0; fi; exit 1 + ``` * 注册这个 Pod 到远程服务器，通过在命令中调用 API，类似如下： - curl -X POST http://$MANAGEMENT_SERVICE_HOST:$MANAGEMENT_SERVICE_PORT/register -d 'instance=$(<POD_NAME>)&ip=$(<POD_IP>)' + ```shell + curl -X POST http://$MANAGEMENT_SERVICE_HOST:$MANAGEMENT_SERVICE_PORT/register \ + -d 'instance=$(<POD_NAME>)&ip=$(<POD_IP>)' + ``` * 在启动应用容器之前等一段时间，使用类似命令： - sleep 60 + ```shell + sleep 60 + ``` -* 克隆 Git 仓库到 {{< glossary_tooltip text="Volume" term_id="volume" >}}。 -* 将配置值放到配置文件中，运行模板工具为主应用容器动态地生成配置文件。例如，在配置文件中存放 POD_IP 值，并使用 Jinja 生成主应用配置文件。 +* 克隆 Git 仓库到{{< glossary_tooltip text="卷" term_id="volume" >}}中。 +* 将配置值放到配置文件中，运行模板工具为主应用容器动态地生成配置文件。 + 例如，在配置文件中存放 `POD_IP` 值，并使用 Jinja 生成主应用配置文件。 <!-- #### Init containers in use @@ -162,9 +175,10 @@ And check on its status with: ```shell ``` --> -### 使用 Init 容器 +### 使用 Init 容器的情况 -下面的例子定义了一个具有 2 个 Init 容器的简单 Pod。 第一个等待 `myservice` 启动，第二个等待 `mydb` 启动。 一旦这两个 Init容器 都启动完成，Pod 将启动`spec`区域中的应用容器。 +下面的例子定义了一个具有 2 个 Init 容器的简单 Pod。 第一个等待 `myservice` 启动， +第二个等待 `mydb` 启动。 一旦这两个 Init容器 都启动完成，Pod 将启动 `spec` 节中的应用容器。 ```yaml apiVersion: v1 @@ -211,24 +225,26 @@ spec: targetPort: 9377 ``` - 要启动这个 Pod，可以执行如下命令： -``` +```shell kubectl apply -f myapp.yaml ``` +输出为： + ``` pod/myapp-pod created ``` - - 要检查其状态： -``` + +```shell kubectl get -f myapp.yaml ``` +输出类似于： + ``` NAME READY STATUS RESTARTS AGE myapp-pod 0/1 Init:0/2 0 6m @@ -236,10 +252,12 @@ myapp-pod 0/1 Init:0/2 0 6m 如需更详细的信息： -``` +```shell kubectl describe -f myapp.yaml ``` +输出类似于： + ``` Name: myapp-pod Namespace: default @@ -275,11 +293,11 @@ Events: 13s 13s 1 {kubelet 172.17.4.201} spec.initContainers{init-myservice} Normal Started Started container with docker id 5ced34a04634 ``` -如需查看Pod内 Init 容器的日志，请执行: +如需查看 Pod 内 Init 容器的日志，请执行： -``` -$ kubectl logs myapp-pod -c init-myservice # Inspect the first init container -$ kubectl logs myapp-pod -c init-mydb # Inspect the second init container +```shell +kubectl logs myapp-pod -c init-myservice # 查看第一个 Init 容器 +kubectl logs myapp-pod -c init-mydb # 查看第二个 Init 容器 ``` <!-- @@ -287,12 +305,11 @@ At this point, those init containers will be waiting to discover Services named Here's a configuration you can use to make those Services appear: --> - -在这一刻，Init 容器将会等待至发现名称为`mydb`和`myservice`的 Service。 +在这一刻，Init 容器将会等待至发现名称为 `mydb` 和 `myservice` 的 Service。 如下为创建这些 Service 的配置文件： -``` +```yaml --- apiVersion: v1 kind: Service @@ -315,75 +332,90 @@ spec: targetPort: 9377 ``` - -创建`mydb`和`myservice`的 service 命令： +创建 `mydb` 和 `myservice` 服务的命令： ```shell -$ kubectl create -f services.yaml +kubectl create -f services.yaml ``` +输出类似于： + ``` service "myservice" created service "mydb" created ``` -这样你将能看到这些 Init容器 执行完毕，随后`my-app`的Pod转移进入 Running 状态： +这样你将能看到这些 Init 容器执行完毕，随后 `my-app` 的 Pod 进入 `Running` 状态： + ```shell $ kubectl get -f myapp.yaml ``` -```shell + +``` NAME READY STATUS RESTARTS AGE myapp-pod 1/1 Running 0 9m ``` -一旦我们启动了 `mydb` 和 `myservice` 这两个 Service，我们能够看到 Init 容器完成，并且 `myapp-pod` 被创建： - +一旦我们启动了 `mydb` 和 `myservice` 这两个服务，我们能够看到 Init 容器完成， +并且 `myapp-pod` 被创建。 <!-- This simple example should provide some inspiration for you to create your own init containers. [What's next](#what-s-next) contains a link to a more detailed example. --> -这个简单的例子应该能为你创建自己的 Init 容器提供一些启发。 [What's next](#what-s-next) 部分提供了更详细例子的链接。 - +这个简单例子应该能为你创建自己的 Init 容器提供一些启发。 +[接下来](#what-s-next)节提供了更详细例子的链接。 <!-- +## Detailed behavior + During the startup of a Pod, each init container starts in order, after the network and volumes are initialized. Each container must exit successfully before the next container starts. If a container fails to start due to the runtime or exits with failure, it is retried according to the Pod `restartPolicy`. However, if the Pod `restartPolicy` is set to Always, the init containers use `restartPolicy` OnFailure. A Pod cannot be `Ready` until all init containers have succeeded. The ports on an init container are not aggregated under a Service. A Pod that is initializing is in the `Pending` state but should have a condition `Initializing` set to true. -If the Pod [restarts](#pod-restart-reasons), or is restarted, all init containers must execute again. +If the Pod [restarts](#pod-restart-reasons), or is restarted, all init containers must execute again. +--> +## 具体行为 {#detailed-behavior} +在 Pod 启动过程中，每个 Init 容器在网络和数据卷初始化之后会按顺序启动。 +每个 Init 容器成功退出后才会启动下一个 Init 容器。 +如果它们因为容器运行时的原因无法启动，或以错误状态退出，它会根据 Pod 的 `restartPolicy` 策略进行重试。 +然而，如果 Pod 的 `restartPolicy` 设置为 "Always"，Init 容器失败时会使用 `restartPolicy` +的 "OnFailure" 策略。 + +在所有的 Init 容器没有成功之前，Pod 将不会变成 `Ready` 状态。 +Init 容器的端口将不会在 Service 中进行聚集。正在初始化中的 Pod 处于 `Pending` 状态， +但会将状况 `Initializing` 设置为 true。 + +如果 Pod [重启](#pod-restart-reasons)，所有 Init 容器必须重新执行。 + +<!-- Changes to the init container spec are limited to the container image field. Altering an init container image field is equivalent to restarting the Pod. Because init containers can be restarted, retried, or re-executed, init container code should be idempotent. In particular, code that writes to files on `EmptyDirs` should be prepared for the possibility that an output file already exists. Init containers have all of the fields of an app container. However, Kubernetes prohibits `readinessProbe` from being used because init containers cannot define readiness distinct from completion. This is enforced during validation. +--> +对 Init 容器规约的修改仅限于容器的 `image` 字段。 +更改 Init 容器的 `image` 字段，等同于重启该 Pod。 +因为 Init 容器可能会被重启、重试或者重新执行，所以 Init 容器的代码应该是幂等的。 +特别地，基于 `emptyDirs` 写文件的代码，应该对输出文件可能已经存在做好准备。 + +Init 容器具有应用容器的所有字段。然而 Kubernetes 禁止使用 `readinessProbe`， +因为 Init 容器不能定义不同于完成态（Completion）的就绪态（Readiness）。 +Kubernetes 会在校验时强制执行此检查。 + +<!-- Use `activeDeadlineSeconds` on the Pod and `livenessProbe` on the container to prevent init containers from failing forever. The active deadline includes init containers. The name of each app and init container in a Pod must be unique; avalidation error is thrown for any container sharing a name with another. - --> +在 Pod 上使用 `activeDeadlineSeconds` 和在容器上使用 `livenessProbe` 可以避免 +Init 容器一直重复失败。`activeDeadlineSeconds` 时间包含了 Init 容器启动的时间。 -## 具体行为 - -在 Pod 启动过程中，每个Init 容器在网络和数据卷初始化之后会按顺序启动。每个 Init容器 成功退出后才会启动下一个 Init容器。 如果因为运行或退出时失败引发容器启动失败，它会根据 Pod 的 `restartPolicy` 策略进行重试。 -然而，如果 Pod 的 `restartPolicy` 设置为 Always，Init 容器失败时会使用 `restartPolicy` 的 OnFailure 策略。 - -在所有的 Init 容器没有成功之前，Pod 将不会变成 `Ready` 状态。 Init 容器的端口将不会在 Service 中进行聚集。 正在初始化中的 Pod 处于 `Pending` 状态，但会将条件 `Initializing` 设置为 true。 - -如果 Pod [重启](#pod-restart-reasons)，所有 Init 容器必须重新执行。 - -对 Init 容器 spec 的修改仅限于容器的 image 字段。 更改 Init 容器的 image 字段，等同于重启该 Pod。 - -因为 Init 容器可能会被重启、重试或者重新执行，所以 Init 容器的代码应该是幂等的。 特别地，基于 `EmptyDirs` 写文件的代码，应该对输出文件可能已经存在做好准备。 - -Init 容器具有应用容器的所有字段。 然而 Kubernetes 禁止使用 `readinessProbe`，因为 Init 容器不能定义不同于完成（completion）的就绪（readiness）。 这一点会在校验时强制执行。 - -在 Pod 上使用 `activeDeadlineSeconds`和在容器上使用 `livenessProbe` 可以避免 Init 容器一直重复失败。 `activeDeadlineSeconds` 时间包含了 Init 容器启动的时间。 - -在 Pod 中的每个应用容器和 Init 容器的名称必须唯一；与任何其它容器共享同一个名称，会在校验时抛出错误。 - +在 Pod 中的每个应用容器和 Init 容器的名称必须唯一； +与任何其它容器共享同一个名称，会在校验时抛出错误。 <!-- ### Resources @@ -398,51 +430,48 @@ Given the ordering and execution for init containers, the following rules for re Quota and limits are applied based on the effective Pod request and limit. Pod level control groups (cgroups) are based on the effective Pod request and limit, the same as the scheduler. --> +### 资源 {#resources} -### 资源 - -给定Init 容器的执行顺序下，资源使用适用于如下规则： +在给定的 Init 容器执行顺序下，资源使用适用于如下规则： * 所有 Init 容器上定义的任何特定资源的 limit 或 request 的最大值，作为 Pod *有效初始 request/limit* * Pod 对资源的 *有效 limit/request* 是如下两者的较大者： * 所有应用容器对某个资源的 limit/request 之和 * 对某个资源的有效初始 limit/request -* 基于有效 limit/request 完成调度，这意味着 Init 容器能够为初始化过程预留资源，这些资源在 Pod 生命周期过程中并没有被使用。 +* 基于有效 limit/request 完成调度，这意味着 Init 容器能够为初始化过程预留资源， + 这些资源在 Pod 生命周期过程中并没有被使用。 * Pod 的 *有效 QoS 层* ，与 Init 容器和应用容器的一样。 配额和限制适用于有效 Pod的 limit/request。 Pod 级别的 cgroups 是基于有效 Pod 的 limit/request，和调度器相同。 - <!-- ### Pod restart reasons A Pod can restart, causing re-execution of init containers, for the following reasons: * A user updates the Pod specification, causing the init container image to change. Any changes to the init container image restarts the Pod. App container image changes only restart the app container. * The Pod infrastructure container is restarted. This is uncommon and would have to be done by someone with root access to nodes. * All containers in a Pod are terminated while `restartPolicy` is set to Always, forcing a restart, and the init container completion record has been lost due to garbage collection. - - --> -### Pod 重启的原因 - -Pod重启导致 Init 容器重新执行，主要有如下几个原因： - -* 用户更新 Pod 的 Spec 导致 Init 容器镜像发生改变。Init 容器镜像的变更会引起 Pod 重启. 应用容器镜像的变更仅会重启应用容器。 -* Pod 的基础设施容器 (译者注：如 pause 容器) 被重启。 这种情况不多见，必须由具备 root 权限访问 Node 的人员来完成。 -* 当 `restartPolicy` 设置为 Always，Pod 中所有容器会终止而强制重启，由于垃圾收集导致 Init 容器的完成记录丢失。 +### Pod 重启的原因 {#pod-restart-reasons} +Pod 重启会导致 Init 容器重新执行，主要有如下几个原因： +* 用户更新 Pod 的规约导致 Init 容器镜像发生改变。Init 容器镜像的变更会引起 Pod 重启。 + 应用容器镜像的变更仅会重启应用容器。 +* Pod 的基础设施容器 (译者注：如 `pause` 容器) 被重启。这种情况不多见， + 必须由具备 root 权限访问节点的人员来完成。 +* 当 `restartPolicy` 设置为 "`Always`"，Pod 中所有容器会终止而强制重启。 + 由于垃圾收集机制的原因，Init 容器的完成记录将会丢失。 ## {{% heading "whatsnext" %}} - <!-- * Read about [creating a Pod that has an init container](/docs/tasks/configure-pod-container/configure-pod-initialization/#create-a-pod-that-has-an-init-container) * Learn how to [debug init containers](/docs/tasks/debug-application-cluster/debug-init-containers/) --> -* 阅读[创建包含 Init 容器的 Pod](/docs/tasks/configure-pod-container/configure-pod-initialization/#create-a-pod-that-has-an-init-container) -* 学习如何[调测 Init 容器](/docs/tasks/debug-application-cluster/debug-init-containers/) +* 阅读[创建包含 Init 容器的 Pod](/zh/docs/tasks/configure-pod-container/configure-pod-initialization/#create-a-pod-that-has-an-init-container) +* 学习如何[调试 Init 容器](/zh/docs/tasks/debug-application-cluster/debug-init-containers/) diff --git a/content/zh/docs/concepts/workloads/pods/pod-lifecycle.md b/content/zh/docs/concepts/workloads/pods/pod-lifecycle.md index 767c18bdd2..3cbca2f16d 100644 --- a/content/zh/docs/concepts/workloads/pods/pod-lifecycle.md +++ b/content/zh/docs/concepts/workloads/pods/pod-lifecycle.md @@ -1,180 +1,853 @@ --- title: Pod 的生命周期 content_type: concept +weight: 30 --- +<!-- +title: Pod Lifecycle +content_type: concept +weight: 30 +--> <!-- overview --> -{{< comment >}}Updated: 4/14/2015{{< /comment >}} -{{< comment >}}Edited and moved to Concepts section: 2/2/17{{< /comment >}} +<!-- +This page describes the lifecycle of a Pod. Pods follow a defined lifecycle, starting +in the `Pending` [phase](#pod-phase), moving through `Running` if at least one +of its primary containers starts OK, and then through either the `Succeeded` or +`Failed` phases depending on whether any container in the Pod terminated in failure. -该页面将描述 Pod 的生命周期。 +Whilst a Pod is running, the kubelet is able to restart containers to handle some +kind of faults. Within a Pod, Kubernetes tracks different container +[states](#container-states) and handles +--> +本页面讲述 Pod 的生命周期。 +Pod 遵循一个预定义的生命周期，起始于 `Pending` [阶段](#pod-phase)，如果至少 +其中有一个主要容器正常启动，则进入 `Running`，之后取决于 Pod 中是否有容器以 +失败状态结束而进入 `Succeeded` 或者 `Failed` 阶段。 +在 Pod 运行期间，`kubelet` 能够重启容器以处理一些失效场景。 +在 Pod 内部，Kubernetes 跟踪不同容器的[状态](#container-states) +并处理可能出现的状况。 +<!-- +In the Kubernetes API, Pods have both a specification and an actual status. The +status for a Pod object consists of a set of [Pod conditions](#pod-conditions). +You can also inject [custom readiness information](#pod-readiness-gate) into the +condition data for a Pod, if that is useful to your application. + +Pods are only [scheduled](/docs/concepts/scheduling-eviction/) once in their lifetime. +Once a Pod is scheduled (assigned) to a Node, the Pod runs on that Node until it stops +or is [terminated](#pod-termination). +--> +在 Kubernetes API 中，Pod 包含规约部分和实际状态部分。 +Pod 对象的状态包含了一组 [Pod 状况（Conditions）](#pod-conditions)。 +如果应用需要的话，你也可以向其中注入[自定义的就绪性信息](#pod-readiness-gate)。 + +Pod 在其生命周期中只会被[调度](/zh/docs/concepts/scheduling-eviction/)一次。 +一旦 Pod 被调度（分派）到某个节点，Pod 会一直在该节点运行，直到 Pod 停止或者 +被[终止](#pod-termination)。 <!-- body --> +<!-- +## Pod lifetime + +Like individual application containers, Pods are considered to be relatively +ephemeral (rather than durable) entities. Pods are created, assigned a unique +ID ([UID](/docs/concepts/overview/working-with-objects/names/#uids)), and scheduled +to nodes where they remain until termination (according to restart policy) or +deletion. +If a {{< glossary_tooltip term_id="node" >}} dies, the Pods scheduled to that node +are [scheduled for deletion](#pod-garbage-collection) after a timeout period. +--> +## Pod 生命期 {#pod-lifetime} + +和一个个独立的应用容器一样，Pod 也被认为是相对临时性（而不是长期存在）的实体。 +Pod 会被创建、赋予一个唯一的 +ID（[UID](/zh/docs/concepts/overview/working-with-objects/names/#uids)）， +并被调度到节点，并在终止（根据重启策略）或删除之前一直运行在该节点。 + +如果一个{{< glossary_tooltip text="节点" term_id="node" >}}死掉了，调度到该节点 +的 Pod 也被计划在给定超时期限结束后[删除](#pod-garbage-collection)。 + +<!-- +Pods do not, by themselves, self-heal. If a Pod is scheduled to a +{{< glossary_tooltip text="node" term_id="node" >}} that then fails, +or if the scheduling operation itself fails, the Pod is deleted; likewise, a Pod won't +survive an eviction due to a lack of resources or Node maintenance. Kubernetes uses a +higher-level abstraction, called a +{{< glossary_tooltip term_id="controller" text="controller" >}}, that handles the work of +managing the relatively disposable Pod instances. +--> +Pod 自身不具有自愈能力。如果 Pod 被调度到某{{< glossary_tooltip text="节点" term_id="node" >}} +而该节点之后失效，或者调度操作本身失效，Pod 会被删除；与此类似，Pod 无法在节点资源 +耗尽或者节点维护期间继续存活。Kubernetes 使用一种高级抽象，称作 +{{< glossary_tooltip term_id="controller" text="控制器" >}}，来管理这些相对而言 +可随时丢弃的 Pod 实例。 + +<!-- +A given Pod (as defined by a UID) is never "rescheduled" to a different node; instead, +that Pod can be replaced by a new, near-identical Pod, with even the same name i +desired, but with a different UID. + +When something is said to have the same lifetime as a Pod, such as a +{{< glossary_tooltip term_id="volume" text="volume" >}}, +that means that the thing exists as long as that specific Pod (with that exact UID) +exists. If that Pod is deleted for any reason, and even if an identical replacement +is created, the related thing (a volume, in this example) is also destroyed and +created anew. +--> +任何给定的 Pod （由 UID 定义）从不会被“重新调度（rescheduled）”到不同的节点； +相反，这一 Pod 可以被一个新的、几乎完全相同的 Pod 替换掉。 +如果需要，新 Pod 的名字可以不变，但是其 UID 会不同。 + +如果某物声称其生命期与某 Pod 相同，例如存储{{< glossary_tooltip term_id="volume" text="卷" >}}， +这就意味着该对象在此 Pod （UID 亦相同）存在期间也一直存在。 +如果 Pod 因为任何原因被删除，甚至某完全相同的替代 Pod 被创建时， +这个相关的对象（例如这里的卷）也会被删除并重建。 + +{{< figure src="/images/docs/pod.svg" title="Pod 结构图例" width="50%" >}} + +*一个包含多个容器的 Pod 中包含一个用来拉取文件的程序和一个 Web 服务器， +均使用持久卷作为容器间共享的存储。* + +<!-- ## Pod phase -Pod 的 `status` 定义在 [PodStatus](/docs/resources-reference/v1.7/#podstatus-v1-core) 对象中，其中有一个 `phase` 字段。 +A Pod's `status` field is a +[PodStatus](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podstatus-v1-core) +object, which has a `phase` field. -Pod 的运行阶段（phase）是 Pod 在其生命周期中的简单宏观概述。该阶段并不是对容器或 Pod 的综合汇总，也不是为了做为综合状态机。 +The phase of a Pod is a simple, high-level summary of where the Pod is in its +lifecycle. The phase is not intended to be a comprehensive rollup of observations +of container or Pod state, nor is it intended to be a comprehensive state machine. -Pod 相位的数量和含义是严格指定的。除了本文档中列举的内容外，不应该再假定 Pod 有其他的 `phase` 值。 +The number and meanings of Pod phase values are tightly guarded. +Other than what is documented here, nothing should be assumed about Pods that +have a given `phase` value. + +Here are the possible values for `phase`: +--> +## Pod 阶段 {#pod-phase} + +Pod 的 `status` 字段是一个 +[PodStatus](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podstatus-v1-core) +对象，其中包含一个 `phase` 字段。 + +Pod 的阶段（Phase）是 Pod 在其生命周期中所处位置的简单宏观概述。 +该阶段并不是对容器或 Pod 状态的综合汇总，也不是为了成为完整的状态机。 + +Pod 阶段的数量和含义是严格定义的。 +除了本文档中列举的内容外，不应该再假定 Pod 有其他的 `phase` 值。 下面是 `phase` 可能的值： -- 挂起（Pending）：Pod 已被 Kubernetes 系统接受，但有一个或者多个容器镜像尚未创建。等待时间包括调度 Pod 的时间和通过网络下载镜像的时间，这可能需要花点时间。 -- 运行中（Running）：该 Pod 已经绑定到了一个节点上，Pod 中所有的容器都已被创建。至少有一个容器正在运行，或者正处于启动或重启状态。 -- 成功（Succeeded）：Pod 中的所有容器都被成功终止，并且不会再重启。 -- 失败（Failed）：Pod 中的所有容器都已终止了，并且至少有一个容器是因为失败终止。也就是说，容器以非0状态退出或者被系统终止。 -- 未知（Unknown）：因为某些原因无法取得 Pod 的状态，通常是因为与 Pod 所在主机通信失败。 - -## Pod 状态 - -Pod 有一个 PodStatus 对象，其中包含一个 [PodCondition](/docs/resources-reference/v1.7/#podcondition-v1-core) 数组。 PodCondition 数组的每个元素都有一个 `type` 字段和一个 `status` 字段。`type` 字段是字符串，可能的值有 PodScheduled、Ready、Initialized 和 Unschedulable。`status` 字段是一个字符串，可能的值有 True、False 和 Unknown。 - -## 容器探针 - -[探针](/docs/resources-reference/v1.7/#probe-v1-core) 是由 [kubelet](/docs/admin/kubelet/) 对容器执行的定期诊断。要执行诊断，kubelet 调用由容器实现的 [Handler](https://godoc.org/k8s.io/kubernetes/pkg/api/v1#Handler)。有三种类型的处理程序： - -- [ExecAction](/docs/resources-reference/v1.7/#execaction-v1-core)：在容器内执行指定命令。如果命令退出时返回码为 0 则认为诊断成功。 -- [TCPSocketAction](/docs/resources-reference/v1.7/#tcpsocketaction-v1-core)：对指定端口上的容器的 IP 地址进行 TCP 检查。如果端口打开，则诊断被认为是成功的。 -- [HTTPGetAction](/docs/resources-reference/v1.7/#httpgetaction-v1-core)：对指定的端口和路径上的容器的 IP 地址执行 HTTP Get 请求。如果响应的状态码大于等于200 且小于 400，则诊断被认为是成功的。 - -每次探测都将获得以下三种结果之一： - -- 成功：容器通过了诊断。 -- 失败：容器未通过诊断。 -- 未知：诊断失败，因此不会采取任何行动。 - -Kubelet 可以选择是否执行在容器上运行的三种探针执行和做出反应： - -- `livenessProbe`：指示容器是否正在运行。如果存活探测失败，则 kubelet 会杀死容器，并且容器将受到其 [重启策略](/docs/concepts/workloads/pods/pod-lifecycle/#restart-policy) 的影响。如果容器不提供存活探针，则默认状态为 `Success`。 -- `readinessProbe`：指示容器是否准备好服务请求。如果就绪探测失败，端点控制器将从与 Pod 匹配的所有 Service 的端点中删除该 Pod 的 IP 地址。初始延迟之前的就绪状态默认为 `Failure`。如果容器不提供就绪探针，则默认状态为 `Success`。 -- `startupProbe`: 指示容器中的应用是否已经启动。如果提供了启动探测(startup probe)，则禁用所有其他探测，直到它成功为止。如果启动探测失败，kubelet 将杀死容器，容器服从其重启策略进行重启。如果容器没有提供启动探测，则默认状态为成功`Success`。 - -### 该什么时候使用存活（liveness）和就绪（readiness）探针? - -如果容器中的进程能够在遇到问题或不健康的情况下自行崩溃，则不一定需要存活探针; kubelet 将根据 Pod 的`restartPolicy` 自动执行正确的操作。 - -如果您希望容器在探测失败时被杀死并重新启动，那么请指定一个存活探针，并指定`restartPolicy` 为 Always 或 OnFailure。 - -如果要仅在探测成功时才开始向 Pod 发送流量，请指定就绪探针。在这种情况下，就绪探针可能与存活探针相同，但是 spec 中的就绪探针的存在意味着 Pod 将在没有接收到任何流量的情况下启动，并且只有在探针探测成功后才开始接收流量。 - -如果您希望容器能够自行维护，您可以指定一个就绪探针，该探针检查与存活探针不同的端点。 - -请注意，如果您只想在 Pod 被删除时能够排除请求，则不一定需要使用就绪探针；在删除 Pod 时，Pod 会自动将自身置于未完成状态，无论就绪探针是否存在。当等待 Pod 中的容器停止时，Pod 仍处于未完成状态。 - -## Pod 和容器状态 - -有关 Pod 容器状态的详细信息，请参阅 [PodStatus](/docs/resources-reference/v1.7/#podstatus-v1-core) 和 [ContainerStatus](/docs/resources-reference/v1.7/#containerstatus-v1-core)。请注意，报告的 Pod 状态信息取决于当前的 [ContainerState](/docs/resources-reference/v1.7/#containerstatus-v1-core)。 - -## 重启策略 - -PodSpec 中有一个 `restartPolicy` 字段，可能的值为 Always、OnFailure 和 Never。默认为 Always。 `restartPolicy` 适用于 Pod 中的所有容器。`restartPolicy` 仅指通过同一节点上的 kubelet 重新启动容器。失败的容器由 kubelet 以五分钟为上限的指数退避延迟（10秒，20秒，40秒...）重新启动，并在成功执行十分钟后重置。如 [Pod 文档](/docs/user-guide/pods/#durability-of-pods-or-lack-thereof) 中所述，一旦绑定到一个节点，Pod 将永远不会重新绑定到另一个节点。 - -## Pod 的生命 - -一般来说，Pod 不会消失，直到人为销毁他们。这可能是一个人或控制器。这个规则的唯一例外是成功或失败的 `phase` 超过一段时间（由 master 确定）的Pod将过期并被自动销毁。 - -有三种可用的控制器： - -- 使用 [Job](/docs/concepts/jobs/run-to-completion-finite-workloads/) 运行预期会终止的 Pod，例如批量计算。Job 仅适用于重启策略为 `OnFailure` 或 `Never` 的 Pod。 - - -- 对预期不会终止的 Pod 使用 [ReplicationController](/docs/concepts/workloads/controllers/replicationcontroller/)、[ReplicaSet](/docs/concepts/workloads/controllers/replicaset/) 和 [Deployment](/docs/concepts/workloads/controllers/deployment/) ，例如 Web 服务器。 ReplicationController 仅适用于具有 `restartPolicy` 为 Always 的 Pod。 -- 提供特定于机器的系统服务，使用 [DaemonSet](/docs/concepts/workloads/controllers/daemonset/) 为每台机器运行一个 Pod 。 - -所有这三种类型的控制器都包含一个 PodTemplate。建议创建适当的控制器，让它们来创建 Pod，而不是直接自己创建 Pod。这是因为单独的 Pod 在机器故障的情况下没有办法自动复原，而控制器却可以。 - -如果节点死亡或与集群的其余部分断开连接，则 Kubernetes 将应用一个策略将丢失节点上的所有 Pod 的 `phase` 设置为 Failed。 - -## 示例 - -### 高级 liveness 探针示例 - -存活探针由 kubelet 来执行，因此所有的请求都在 kubelet 的网络命名空间中进行。 +<!-- +Value | Description +`Pending` | The Pod has been accepted by the Kubernetes cluster, but one or more of the containers has not been set up and made ready to run. This includes time a Pod spends waiting to bescheduled as well as the time spent downloading container images over the network. +`Running` | The Pod has been bound to a node, and all of the containers have been created. At least one container is still running, or is in the process of starting or restarting. +`Succeeded` | All containers in the Pod have terminated in success, and will not be restarted. +`Failed` | All containers in the Pod have terminated, and at least one container has terminated in failure. That is, the container either exited with non-zero status or was terminated by the system. +`Unknown` | For some reason the state of the Pod could not be obtained. This phase typically occurs due to an error in communicating with the node where the Pod should be running. +--> +取值 | 描述 +:-----|:----------- +`Pending`（悬决）| Pod 已被 Kubernetes 系统接受，但有一个或者多个容器尚未创建亦未运行。此阶段包括等待 Pod 被调度的时间和通过网络下载镜像的时间， +`Running`（运行中） | Pod 已经绑定到了某个节点，Pod 中所有的容器都已被创建。至少有一个容器仍在运行，或者正处于启动或重启状态。 +`Succeeded`（成功） | Pod 中的所有容器都已成功终止，并且不会再重启。 +`Failed`（失败） | Pod 中的所有容器都已终止，并且至少有一个容器是因为失败终止。也就是说，容器以非 0 状态退出或者被系统终止。 +`Unknown`（未知） | 因为某些原因无法取得 Pod 的状态。这种情况通常是因为与 Pod 所在主机通信失败。 <!-- - # when "host" is not defined, "PodIP" will be used - # host: my-host - # when "scheme" is not defined, "HTTP" scheme will be used. Only "HTTP" and "HTTPS" are allowed - # scheme: HTTPS +If a node dies or is disconnected from the rest of the cluster, Kubernetes +applies a policy for setting the `phase` of all Pods on the lost node to Failed. --> +如果某节点死掉或者与集群中其他节点失联，Kubernetes +会实施一种策略，将失去的节点上运行的所有 Pod 的 `phase` 设置为 `Failed`。 + +<!-- +## Container states + +As well as the [phase](#pod-phase) of the Pod overall, Kubernetes tracks the state of +each container inside a Pod. You can use +[container lifecycle hooks](/docs/concepts/containers/container-lifecycle-hooks/) to +trigger events to run at certain points in a container's lifecycle. + +Once the {{< glossary_tooltip text="scheduler" term_id="kube-scheduler" >}} +assigns a Pod to a Node, the kubelet starts creating containers for that Pod +using a {{< glossary_tooltip text="container runtime" term_id="container-runtime" >}}. +There are three possible container states: `Waiting`, `Running`, and `Terminated`. +--> +## 容器状态 {#container-states} + +Kubernetes 会跟踪 Pod 中每个容器的状态，就像它跟踪 Pod 总体上的[阶段](#pod-phase)一样。 +你可以使用[容器生命周期回调](/zh/docs/concepts/containers/container-lifecycle-hooks/) +来在容器生命周期中的特定时间点触发事件。 + +一旦{{< glossary_tooltip text="调度器" term_id="kube-scheduler" >}}将 Pod +分派给某个节点，`kubelet` 就通过 +{{< glossary_tooltip text="容器运行时" term_id="container-runtime" >}} +开始为 Pod 创建容器。 +容器的状态有三种：`Waiting`（等待）、`Running`（运行中）和 +`Terminated`（已终止）。 + +<!-- +To the check state of a Pod's containers, you can use +`kubectl describe pod <name-of-pod>`. The output shows the state for each container +within that Pod. + +Each state has a specific meaning: +--> +要检查 Pod 中容器的状态，你可以使用 `kubectl describe pod <pod 名称>`。 +其输出中包含 Pod 中每个容器的状态。 + +每种状态都有特定的含义： + +<!-- +### `Waiting` {#container-state-waiting} + +If a container is not in either the `Running` or `Terminated` state, it `Waiting`. +A container in the `Waiting` state is still running the operations it requires in +order to complete start up: for example, pulling the container image from a container +image registry, or applying {{< glossary_tooltip text="Secret" term_id="secret" >}} +data. +When you use `kubectl` to query a Pod with a container that is `Waiting`, you also see +a Reason field to summarize why the container is in that state. +--> +### `Waiting` （等待） {#container-state-waiting} + +如果容器并不处在 `Running` 或 `Terminated` 状态之一，它就处在 `Waiting` 状态。 +处于 `Waiting` 状态的容器仍在运行它完成启动所需要的操作：例如，从某个容器镜像 +仓库拉取容器镜像，或者向容器应用 {{< glossary_tooltip text="Secret" term_id="secret" >}} +数据等等。 +当你使用 `kubectl` 来查询包含 `Waiting` 状态的容器的 Pod 时，你也会看到一个 +Reason 字段，其中给出了容器处于等待状态的原因。 + +<!-- +### `Running` {#container-state-running} + +The `Running` status indicates that a container is executing without issues. If there +was a `postStart` hook configured, it has already executed and executed. When you use +`kubectl` to query a Pod with a container that is `Running`, you also see information +about when the container entered the `Running` state. +--> +### `Running`（运行中） {#container-state-running} + +`Running` 状态表明容器正在执行状态并且没有问题发生。 +如果配置了 `postStart` 回调，那么该回调已经执行完成。 +如果你使用 `kubectl` 来查询包含 `Running` 状态的容器的 Pod 时，你也会看到 +关于容器进入 `Running` 状态的信息。 + +<!-- +### `Terminated` {#container-state-terminated} + +A container in the `Terminated` state has begin execution and has then either run to +completion or has failed for some reason. When you use `kubectl` to query a Pod with +a container that is `Terminated`, you see a reason, and exit code, and the start and +finish time for that container's period of execution. + +If a container has a `preStop` hook configured, that runs before the container enters +the `Terminated` state. +--> +### `Terminated`（已终止） {#container-state-terminated} + +处于 `Terminated` 状态的容器已经开始执行并且或者正常结束或者因为某些原因失败。 +如果你使用 `kubectl` 来查询包含 `Terminated` 状态的容器的 Pod 时，你会看到 +容器进入此状态的原因、退出代码以及容器执行期间的起止时间。 + +如果容器配置了 `preStop` 回调，则该回调会在容器进入 `Terminated` +状态之前执行。 + +<!-- +## Container restart policy {#restart-policy} + +The `spec` of a Pod has a `restartPolicy` field with possible values Always, OnFailure, +and Never. The default value is Always. + +The `restartPolicy` applies to all containers in the Pod. `restartPolicy` only +refers to restarts of the containers by the kubelet on the same node. After containers +in a Pod exit, the kubelet restarts them with an exponential back-off delay (10s, 20s, +40s, …), that is capped at five minutes. Once a container has executed with no problems +for 10 minutes without any problems, the kubelet resets the restart backoff timer for +that container. +--> +## 容器重启策略 {#restart-policy} + +Pod 的 `spec` 中包含一个 `restartPolicy` 字段，其可能取值包括 +Always、OnFailure 和 Never。默认值是 Always。 + +`restartPolicy` 适用于 Pod 中的所有容器。`restartPolicy` 仅针对同一节点上 +`kubelet` 的容器重启动作。当 Pod 中的容器退出时，`kubelet` 会按指数回退 +方式计算重启的延迟（10s、20s、40s、...），其最长延迟为 5 分钟。 +一旦某容器执行了 10 分钟并且没有出现问题，`kubelet` 对该容器的重启回退计时器执行 +重置操作。 + +<!-- +## Pod conditions + +A Pod has a PodStatus, which has an array of +[PodConditions](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podcondition-v1-core) +through which the Pod has or has not passed: +--> +## Pod 状况 {#pod-conditions} + +Pod 有一个 PodStatus 对象，其中包含一个 +[PodConditions](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podcondition-v1-core) +数组。Pod 可能通过也可能未通过其中的一些状况测试。 + +<!-- +* `PodScheduled`: the Pod has been scheduled to a node. +* `ContainersReady`: all containers in the Pod are ready. +* `Initialized`: all [init containers](/docs/concepts/workloads/pods/init-containers/) + have started successfully. +* `Ready`: the Pod is able to serve requests and should be added to the load + balancing pools of all matching Services. +--> +* `PodScheduled`：Pod 已经被调度到某节点； +* `ContainersReady`：Pod 中所有容器都已就绪； +* `Initialized`：所有的 [Init 容器](/zh/docs/concepts/workloads/pods/init-containers/) + 都已成功启动； +* `Ready`：Pod 可以为请求提供服务，并且应该被添加到对应服务的负载均衡池中。 + +<!-- +Field name | Description +`type` | Name of this Pod condition. +`status` | Indicates whether that condition is applicable, with possible values "`True`", "`False`", or "`Unknown`". +`lastProbeTime` | Timestamp of when the Pod condition was last probed. +`lastTransitionTime` | Timestamp for when the Pod last transitioned from one status to another. +`reason` | Machine-readable, UpperCamelCase text indicating the reason for the condition's last transition. +`message` | Human-readable message indicating details about the last status transition. +--> +字段名称 | 描述 +:--------------------|:----------- +`type` | Pod 状况的名称 +`status` | 表明该状况是否适用，可能的取值有 "`True`", "`False`" 或 "`Unknown`" +`lastProbeTime` | 上次探测 Pod 状况时的时间戳 +`lastTransitionTime` | Pod 上次从一种状态转换到另一种状态时的时间戳 +`reason` | 机器可读的、驼峰编码（UpperCamelCase）的文字，表述上次状况变化的原因 +`message` | 人类可读的消息，给出上次状态转换的详细信息 + +<!-- +### Pod readiness {#pod-readiness-gate} + +Your application can inject extra feedback or signals into PodStatus: +_Pod readiness_. To use this, set `readinessGates` in the Pod's `spec` to +specify a list of additional conditions that the kubelet evaluates for Pod readiness. +--> +### Pod 就绪态 {#pod-readiness-gate} + +{{< feature-state for_k8s_version="v1.14" state="stable" >}} + +你的应用可以向 PodStatus 中注入额外的反馈或者信号：_Pod Readiness（Pod 就绪态）_。 +要使用这一特性，可以设置 Pod 规约中的 `readinessGates` 列表，为 kubelet +提供一组额外的状况供其评估 Pod 就绪态时使用。 + +<!-- +Readiness gates are determined by the current state of `status.condition` +fields for the Pod. If Kubernetes cannot find such a condition in the +`status.conditions` field of a Pod, the status of the condition +is defaulted to "`False`". + +Here is an example: +--> +就绪态门控基于 Pod 的 `status.conditions` 字段的当前值来做决定。 +如果 Kubernetes 无法在 `status.conditions` 字段中找到某状况，则该状况的 +状态值默认为 "`False`"。 + +这里是一个例子： ```yaml -apiVersion: v1 kind: Pod -metadata: - labels: - test: liveness - name: liveness-http +... spec: - containers: - - args: - - /server - image: k8s.gcr.io/liveness - livenessProbe: - httpGet: - # 当没有定义 "host" 时，使用 "PodIP" - # host: my-host - # 当没有定义 "scheme" 时，使用 "HTTP" scheme 只允许 "HTTP" 和 "HTTPS" - # scheme: HTTPS - path: /healthz - port: 8080 - httpHeaders: - - name: X-Custom-Header - value: Awesome - initialDelaySeconds: 15 - timeoutSeconds: 1 - name: liveness + readinessGates: + - conditionType: "www.example.com/feature-1" +status: + conditions: + - type: Ready # 内置的 Pod 状况 + status: "False" + lastProbeTime: null + lastTransitionTime: 2018-01-01T00:00:00Z + - type: "www.example.com/feature-1" # 额外的 Pod 状况 + status: "False" + lastProbeTime: null + lastTransitionTime: 2018-01-01T00:00:00Z + containerStatuses: + - containerID: docker://abcd... + ready: true +... ``` -### 状态示例 - -- Pod 中只有一个容器并且正在运行。容器成功退出。 - - 记录完成事件。 - - 如果 `restartPolicy` 为： - - Always：重启容器；Pod `phase` 仍为 Running。 - - OnFailure：Pod `phase` 变成 Succeeded。 - - Never：Pod `phase` 变成 Succeeded。 -- Pod 中只有一个容器并且正在运行。容器退出失败。 - - 记录失败事件。 - - 如果 `restartPolicy` 为： - - Always：重启容器；Pod `phase` 仍为 Running。 - - OnFailure：重启容器；Pod `phase` 仍为 Running。 - - Never：Pod `phase` 变成 Failed。 -- Pod 中有两个容器并且正在运行。有一个容器退出失败。 - - 记录失败事件。 - - 如果 restartPolicy 为： - - Always：重启容器；Pod `phase` 仍为 Running。 - - OnFailure：重启容器；Pod `phase` 仍为 Running。 - - Never：不重启容器；Pod `phase` 仍为 Running。 - - 如果有一个容器没有处于运行状态，并且两个容器退出： - - 记录失败事件。 - - 如果 `restartPolicy` 为： - - Always：重启容器；Pod `phase` 仍为 Running。 - - OnFailure：重启容器；Pod `phase` 仍为 Running。 - - Never：Pod `phase` 变成 Failed。 -- Pod 中只有一个容器并处于运行状态。容器运行时内存超出限制： - - 容器以失败状态终止。 - - 记录 OOM 事件。 - - 如果 `restartPolicy` 为： - - Always：重启容器；Pod `phase` 仍为 Running。 - - OnFailure：重启容器；Pod `phase` 仍为 Running。 - - Never: 记录失败事件；Pod `phase` 仍为 Failed。 -- Pod 正在运行，磁盘故障： - - 杀掉所有容器。 - - 记录适当事件。 - - Pod `phase` 变成 Failed。 - - 如果使用控制器来运行，Pod 将在别处重建。 -- Pod 正在运行，其节点被分段。 - - 节点控制器等待直到超时。 - - 节点控制器将 Pod `phase` 设置为 Failed。 - - 如果是用控制器来运行，Pod 将在别处重建。 - - +<!-- +The Pod conditions you add must have names that meet the Kubernetes [label key format](/docs/concepts/overview/working-with-objects/labels/#syntax-and-character-set). +--> +你所添加的 Pod 状况名称必须满足 Kubernetes +[标签键名格式](/zh/docs/concepts/overview/working-with-objects/labels/#syntax-and-character-set)。 +<!-- +### Status for Pod readiness {#pod-readiness-status} + +The `kubectl patch` command does not support patching object status. +To set these `status.conditions` for the pod, applications and +{{< glossary_tooltip term_id="operator-pattern" text="operators">}} should use +the `PATCH` action. +You can use a [Kubernetes client library](/docs/reference/using-api/client-libraries/) to +write code that sets custom Pod conditions for Pod readiness. +--> +### Pod 就绪态的状态 {#pod-readiness-status} + +命令 `kubectl patch` 不支持修改对象的状态。 +如果需要设置 Pod 的 `status.conditions`，应用或者 +{{< glossary_tooltip term_id="operator-pattern" text="Operators">}} +需要使用 `PATCH` 操作。 +你可以使用 [Kubernetes 客户端库](/zh/docs/reference/using-api/client-libraries/) +之一来编写代码，针对 Pod 就绪态设置定制的 Pod 状况。 + +<!-- +For a Pod that uses custom conditions, that Pod is evaluated to be ready **only** +when both the following statements apply: + +* All containers in the Pod are ready. +* All conditions specified in `readinessGates` are `True`. + +When a Pod's containers are Ready but at least one custom condition is missing or +`False`, the kubelet sets the Pod's [condition](#pod-conditions) to `ContainersReady`. +--> +对于使用定制状况的 Pod 而言，只有当下面的陈述都适用时，该 Pod 才会被评估为就绪： + +* Pod 中所有容器都已就绪； +* `readinessGates` 中的所有状况都为 `True` 值。 + +当 Pod 的容器都已就绪，但至少一个定制状况没有取值或者取值为 `False`， +`kubelet` 将 Pod 的[状况](#pod-conditions)设置为 `ContainersReady`。 + +<!-- +## Container probes + +A [Probe](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#probe-v1-core) is a diagnostic +performed periodically by the [kubelet](/docs/admin/kubelet/) +on a Container. To perform a diagnostic, +the kubelet calls a +[Handler](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#handler-v1-core) implemented by +the container. There are three types of handlers: +--> +## 容器探针 {#container-probes} + +[探针](/zh/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#probe-v1-core) +是由 [kubelet](/zh/docs/reference/command-line-tools-reference/kubelet/) 对容器执行的定期诊断。 +要执行诊断，kubelet 调用由容器实现的 +[Handler](/zh/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#handler-v1-core) +（处理程序）。有三种类型的处理程序： + +<!-- +* [ExecAction](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#execaction-v1-core): + Executes a specified command inside the container. The diagnostic + is considered successful if the command exits with a status code of 0. + +* [TCPSocketAction](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#tcpsocketaction-v1-core): + Performs a TCP check against the Pod's IP address on + a specified port. The diagnostic is considered successful if the port is open. + +* [HTTPGetAction](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#httpgetaction-v1-core): + Performs an HTTP `GET` request against the Pod's IP + address on a specified port and path. The diagnostic is considered successful + if the response has a status code greater than or equal to 200 and less than 400. +--> +- [ExecAction](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#execaction-v1-core)： + 在容器内执行指定命令。如果命令退出时返回码为 0 则认为诊断成功。 + +- [TCPSocketAction](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#tcpsocketaction-v1-core)： + 对容器的 IP 地址上的指定端口执行 TCP 检查。如果端口打开，则诊断被认为是成功的。 + +- [HTTPGetAction](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#httpgetaction-v1-core)： + 对容器的 IP 地址上指定端口和路径执行 HTTP Get 请求。如果响应的状态码大于等于 200 + 且小于 400，则诊断被认为是成功的。 + +<!-- +Each probe has one of three results: + +* `Success`: The container passed the diagnostic. +* `Failure`: The container failed the diagnostic. +* `Unknown`: The diagnostic failed, so no action should be taken. +--> +每次探测都将获得以下三种结果之一： + +- `Success`（成功）：容器通过了诊断。 +- `Failure`（失败）：容器未通过诊断。 +- `Unknown`（未知）：诊断失败，因此不会采取任何行动。 + +<!-- +The kubelet can optionally perform and react to three kinds of probes on running +containers: +--> +针对运行中的容器，`kubelet` 可以选择是否执行以下三种探针，以及如何针对探测结果作出反应： + +<!-- +* `livenessProbe`: Indicates whether the container is running. If + the liveness probe fails, the kubelet kills the container, and the container + is subjected to its [restart policy](#restart-policy). If a Container does not + provide a liveness probe, the default state is `Success`. + +* `readinessProbe`: Indicates whether the container is ready to respond to requests. + If the readiness probe fails, the endpoints controller removes the Pod's IP + address from the endpoints of all Services that match the Pod. The default + state of readiness before the initial delay is `Failure`. If a Container does + not provide a readiness probe, the default state is `Success`. + +* `startupProbe`: Indicates whether the application within the container is started. + All other probes are disabled if a startup probe is provided, until it succeeds. + If the startup probe fails, the kubelet kills the container, and the container + is subjected to its [restart policy](#restart-policy). If a Container does not + provide a startup probe, the default state is `Success`. +--> +- `livenessProbe`：指示容器是否正在运行。如果存活态探测失败，则 kubelet 会杀死容器， + 并且容器将根据其[重启策略](#restart-policy)决定未来。如果容器不提供存活探针， + 则默认状态为 `Success`。 + +- `readinessProbe`：指示容器是否准备好为请求提供服务。如果就绪态探测失败， + 端点控制器将从与 Pod 匹配的所有服务的端点列表中删除该 Pod 的 IP 地址。 + 初始延迟之前的就绪态的状态值默认为 `Failure`。 + 如果容器不提供就绪态探针，则默认状态为 `Success`。 + +- `startupProbe`: 指示容器中的应用是否已经启动。如果提供了启动探针，则所有其他探针都会被 + 禁用，直到此探针成功为止。如果启动探测失败，`kubelet` 将杀死容器，而容器依其 + [重启策略](#restart-policy)进行重启。 + 如果容器没有提供启动探测，则默认状态为 `Success`。 + +<!-- +For more information about how to set up a liveness, readiness, or startup probe, +see [Configure Liveness, Readiness and Startup Probes](/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/). +--> +如欲了解如何设置存活态、就绪态和启动探针的进一步细节，可以参阅 +[配置存活态、就绪态和启动探针](/zh/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/)。 + +<!-- +### When should you use a liveness probe? +--> +### 何时该使用存活态探针? {#when-should-you-use-a-liveness-probe} + +{{< feature-state for_k8s_version="v1.0" state="stable" >}} + +<!-- +If the process in your container is able to crash on its own whenever it +encounters an issue or becomes unhealthy, you do not necessarily need a liveness +probe; the kubelet will automatically perform the correct action in accordance +with the Pod's `restartPolicy`. + +If you'd like your container to be killed and restarted if a probe fails, then +specify a liveness probe, and specify a `restartPolicy` of Always or OnFailure. +--> +如果容器中的进程能够在遇到问题或不健康的情况下自行崩溃，则不一定需要存活态探针; +`kubelet` 将根据 Pod 的`restartPolicy` 自动执行修复操作。 + +如果你希望容器在探测失败时被杀死并重新启动，那么请指定一个存活态探针， +并指定`restartPolicy` 为 "`Always`" 或 "`OnFailure`"。 + +<!-- +### When should you use a readiness probe? +--> +### 何时该使用就绪态探针? {#when-should-you-use-a-readiness-probe} + +{{< feature-state for_k8s_version="v1.0" state="stable" >}} + +<!-- +If you'd like to start sending traffic to a Pod only when a probe succeeds, +specify a readiness probe. In this case, the readiness probe might be the same +as the liveness probe, but the existence of the readiness probe in the spec means +that the Pod will start without receiving any traffic and only start receiving +traffic after the probe starts succeeding. +If your container needs to work on loading large data, configuration files, or +migrations during startup, specify a readiness probe. +--> +如果要仅在探测成功时才开始向 Pod 发送请求流量，请指定就绪态探针。 +在这种情况下，就绪态探针可能与存活态探针相同，但是规约中的就绪态探针的存在意味着 +Pod 将在启动阶段不接收任何数据，并且只有在探针探测成功后才开始接收数据。 + +如果你的容器需要加载大规模的数据、配置文件或者在启动期间执行迁移操作，可以添加一个 +就绪态探针。 + +<!-- +If you want your container to be able to take itself down for maintenance, you +can specify a readiness probe that checks an endpoint specific to readiness that +is different from the liveness probe. +--> +如果你希望容器能够自行进入维护状态，也可以指定一个就绪态探针，检查某个特定于 +就绪态的因此不同于存活态探测的端点。 + +<!-- +If you just want to be able to drain requests when the Pod is deleted, you do not +necessarily need a readiness probe; on deletion, the Pod automatically puts itself +into an unready state regardless of whether the readiness probe exists. +The Pod remains in the unready state while it waits for the containers in the Pod +to stop. +--> +{{< note >}} +请注意，如果你只是想在 Pod 被删除时能够排空请求，则不一定需要使用就绪态探针； +在删除 Pod 时，Pod 会自动将自身置于未就绪状态，无论就绪态探针是否存在。 +等待 Pod 中的容器停止期间，Pod 会一直处于未就绪状态。 +{{< /note >}} + +<!-- +### When should you use a startup probe? +--> +### 何时该使用启动探针？ {#when-should-you-use-a-startup-probe} + +{{< feature-state for_k8s_version="v1.16" state="alpha" >}} + +<!-- +Startup probes are useful for Pods that have containers that take a long time to +come into service. Rather than set a long liveness interval, you can configure +a separate configuration for probing the container as it starts up, allowing +a time longer than the liveness interval would allow. +--> +对于所包含的容器需要较长时间才能启动就绪的 Pod 而言，启动探针是有用的。 +你不再需要配置一个较长的存活态探测时间间隔，只需要设置另一个独立的配置选定， +对启动期间的容器执行探测，从而允许使用远远超出存活态时间间隔所允许的时长。 + +<!-- +If your container usually starts in more than +`initialDelaySeconds + failureThreshold × periodSeconds`, you should specify a +startup probe that checks the same endpoint as the liveness probe. The default for +`periodSeconds` is 30s. You should then set its `failureThreshold` high enough to +allow the container to start, without changing the default values of the liveness +probe. This helps to protect against deadlocks. +--> +如果你的容器启动时间通常超出 `initialDelaySeconds + failureThreshold × periodSeconds` +总值，你应该设置一个启动探测，对存活态探针所使用的同一端点执行检查。 +`periodSeconds` 的默认值是 30 秒。你应该将其 `failureThreshold` 设置得足够高， +以便容器有充足的时间完成启动，并且避免更改存活态探针所使用的默认值。 +这一设置有助于减少死锁状况的发生。 + +<!-- +## Termination of Pods {#pod-termination} + +Because Pods represent processes running on nodes in the cluster, it is important to +allow those processes to gracefully terminate when they are no longer needed (rather +than being abruptly stopped with a `KILL` signal and having no chance to clean up). +--> +## Pod 的终止 {#pod-termination} + +由于 Pod 所代表的是在集群中节点上运行的进程，当不再需要这些进程时允许其体面地 +终止是很重要的。一般不应武断地使用 `KILL` 信号终止它们，导致这些进程没有机会 +完成清理操作。 + +<!-- +The design aim is for you to be able to request deletion and know when processes +terminate, but also be able to ensure that deletes eventually complete. +When you request deletion of a Pod, the cluster records and tracks the intended grace period +before the Pod is allowed to be forcefully killed. With that forceful shutdown tracking in +place, the {< glossary_tooltip text="kubelet" term_id="kubelet" >}} attempts graceful +shutdown. +--> +设计的目标是令你能够请求删除进程，并且知道进程何时被终止，同时也能够确保删除 +操作终将完成。当你请求删除某个 Pod 时，集群会记录并跟踪 Pod 的体面终止周期， +而不是直接强制地杀死 Pod。在存在强制关闭设施的前提下， +{{< glossary_tooltip text="kubelet" term_id="kubelet" >}} 会尝试体面地终止 +Pod。 + +<!-- +Typically, the container runtime sends a a TERM signal is sent to the main process in each +container. Once the grace period has expired, the KILL signal is sent to any remainig +processes, and the Pod is then deleted from the +{{< glossary_tooltip text="API Server" term_id="kube-apiserver" >}}. If the kubelet or the +container runtime's management service is restarted while waiting for processes to terminate, the +cluster retries from the start including the full original grace period. +--> +通常情况下，容器运行时会发送一个 TERM 信号到每个容器中的主进程。 +一旦超出了体面终止限期，容器运行时会向所有剩余进程发送 KILL 信号，之后 +Pod 就会被从 {{< glossary_tooltip text="API 服务器" term_id="kube-apiserver" >}} +上移除。如果 `kubelet` 或者容器运行时的管理服务在等待进程终止期间被重启， +集群会从头开始重试，赋予 Pod 完整的体面终止限期。 + +<!-- +An example flow: + +1. You use the `kubectl` tool to manually delete a specific Pod, with the default grace period + (30 seconds). +1. The Pod in the API server is updated with the time beyond which the Pod is considered "dead" + along with the grace period. + If you use `kubectl describe` to check on the Pod you're deleting, that Pod shows up as + "Terminating". + On the node where the Pod is running: as soon as the kubelet sees that a Pod has been marked + as terminating (a graceful shutdown duration has been set), the kubelet begins the local Pod + shutdown process. + + 1. If one of the Pod's containers has defined a `preStop` + [hook](/docs/concepts/containers/container-lifecycle-hooks/#hook-details), the kubelet + runs that hook inside of the container. If the `preStop` hook is still running after the + grace period expires, the kubelet requests a small, one-off grace period extension of 2 + seconds. + If the `preStop` hook needs longer to complete than the default grace period allows, + you must modify `terminationGracePeriodSeconds` to suit this. + 1. The kubelet triggers the container runtime to send a TERM signal to process 1 inside each + container. + The containers in the Pod receive the TERM signal at different times and in an arbitrary + order. If the order of shutdowns matters, consider using a `preStop` hook to synchronize. +--> +下面是一个例子： + +1. 你使用 `kubectl` 工具手动删除某个特定的 Pod，而该 Pod 的体面终止限期是默认值（30 秒）。 + +2. API 服务器中的 Pod 对象被更新，记录涵盖体面终止限期在内 Pod + 的最终死期，超出所计算时间点则认为 Pod 已死（dead）。 + 如果你使用 `kubectl describe` 来查验你正在删除的 Pod，该 Pod 会显示为 + "Terminating" （正在终止）。 + 在 Pod 运行所在的节点上：`kubelet` 一旦看到 Pod + 被标记为正在终止（已经设置了体面终止限期），`kubelet` 即开始本地的 Pod 关闭过程。 + + 1. 如果 Pod 中的容器之一定义了 `preStop` + [回调](/zh/docs/concepts/containers/container-lifecycle-hooks/#hook-details)， + `kubelet` 开始在容器内运行该回调逻辑。如果超出体面终止限期时，`preStop` 回调逻辑 + 仍在运行，`kubelet` 会请求给予该 Pod 的宽限期一次性增加 2 秒钟。 + + {{< note >}} + 如果 `preStop` 回调所需要的时间长于默认的体面终止限期，你必须修改 + `terminationGracePeriodSeconds` 属性值来使其正常工作。 + {{< /note >}} + + 1. `kubelet` 接下来触发容器运行时发送 TERM 信号给每个容器中的进程 1。 + + {{< note >}} + Pod 中的容器会在不同时刻收到 TERM 信号，接收顺序也是不确定的。 + 如果关闭的顺序很重要，可以考虑使用 `preStop` 回调逻辑来协调。 + {{< /note >}} + +<!-- +1. At the same time as the kubelet is starting graceful shutdown, the control plane removes that + shutting-down Pod from Endpoints (and, if enabled, EndpointSlice) objects where these represent + a {{< glossary_tooltip term_id="service" text="Service" >}} with a configured + {{< glossary_tooltip text="selector" term_id="selector" >}}. + {{< glossary_tooltip text="ReplicaSets" term_id="replica-set" >}} and other workload resources + no longer treat the shutting-down Pod as a valid, in-service replica. Pods that shut down slowly + cannot continue to serve traffic as load balancers (like the service proxy) remove the Pod from + the list of endpoints as soon as the termination grace period _begins_. +--> +3. 与此同时，`kubelet` 启动体面关闭逻辑，控制面会将 Pod 从对应的端点列表（以及端点切片列表， + 如果启用了的话）中移除，过滤条件是 Pod 被对应的 + {{< glossary_tooltip term_id="service" text="服务" >}}以某 + {{< glossary_tooltip text="选择算符" term_id="selector" >}}选定。 + {{< glossary_tooltip text="ReplicaSets" term_id="replica-set" >}}和其他工作负载资源 + 不再将关闭进程中的 Pod 视为合法的、能够提供服务的副本。关闭动作很慢的 Pod + 也无法继续处理请求数据，因为负载均衡器（例如服务代理）已经在终止宽限期开始的时候 + 将其从端点列表中移除。 + +<!-- +1. When the grace period expires, the kubelet triggers forcible shutdown. The container runtime sends + `SIGKILL` to any processes still running in any container in the Pod. + The kubelet also cleans up a hidden `pause` container if that container runtime uses one. +1. The kubelet triggers forcible removal of Pod object from the API server, by setting grace period + to 0 (immediate deletion). +1. The API server deletes the Pod's API object, which is then no longer visible from any client. +--> +4. 超出终止宽限期线时，`kubelet` 会触发强制关闭过程。容器运行时会向 Pod 中所有容器内 + 仍在运行的进程发送 `SIGKILL` 信号。 + `kubelet` 也会清理隐藏的 `pause` 容器，如果容器运行时使用了这种容器的话。 + +5. `kubelet` 触发强制从 API 服务器上删除 Pod 对象的逻辑，并将体面终止限期设置为 0 + （这意味着马上删除）。 + +6. API 服务器删除 Pod 的 API 对象，从任何客户端都无法再看到该对象。 + +<!-- +### Forced Pod termination {#pod-termination-forced} + +Forced deletions can be potentially disruptiove for some workloads and their Pods. + +By default, all deletes are graceful within 30 seconds. The `kubectl delete` command supports +the `-grace-period=<seconds>` option which allows you to override the default and specify your +own value. +--> +### 强制终止 Pod {#pod-termination-forced} + +{{< caution >}} +对于某些工作负载及其 Pod 而言，强制删除很可能会带来某种破坏。 +{{< /caution >}} + +默认情况下，所有的删除操作都会附有 30 秒钟的宽限期限。 +`kubectl delete` 命令支持 `--grace-period=<seconds>` 选项，允许你重载默认值， +设定自己希望的期限值。 + +<!-- +Setting the grace period to `0` forcibly and immediately deletes the Pod from the API +server. If the pod was still running on a node, that forcible deletion triggers the kubelet to +begin immediate cleanup. +--> +将宽限期限强制设置为 `0` 意味着立即从 API 服务器删除 Pod。 +如果 Pod 仍然运行于某节点上，强制删除操作会触发 `kubelet` 立即执行清理操作。 + +<!-- +You must specify an additional flag `--force` along with `--grace-period=0` in order to perform force deletions. +--> +{{< note >}} +你必须在设置 `--grace-period=0` 的同时额外设置 `--force` +参数才能发起强制删除请求。 +{{< /note >}} + +<!-- +When a force deletion is performed, the API server does not wait for confirmation +from the kubelet that the Pod has been terminated on the node it was running on. It +removes the Pod in the API immediately so a new Pod can be created with the same +name. On the node, Pods that are set to terminate immediately will still be given +a small grace period before being force killed. + +If you need to force-delete Pods that are part of a StatefulSet, refer to the task +documentation for +[deleting Pods from a StatefulSet](/docs/tasks/run-application/force-delete-stateful-set-pod/). +--> +执行强制删除操作时，API 服务器不再等待来自 `kubelet` 的、关于 Pod +已经在原来运行的节点上终止执行的确认消息。 +API 服务器直接删除 Pod 对象，这样新的与之同名的 Pod 即可以被创建。 +在节点侧，被设置为立即终止的 Pod 仍然会在被强行杀死之前获得一点点的宽限时间。 + +如果你需要强制删除 StatefulSet 的 Pod，请参阅 +[从 StatefulSet 中删除 Pod](/zh/docs/tasks/run-application/force-delete-stateful-set-pod/) +的任务文档。 + +<!-- +### Garbage collection of failed Pods {#pod-garbage-collection} + +For failed Pods, the API objects remain in the cluster's API until a human or +{{< glossary_tooltip term_id="controller" text="controller" >}} process +explicitly removes them. + +The control plane cleans up terminated Pods (with a phase of `Succeeded` or +`Failed`), when the number of Pods exceeds the configured threshold +(determined by `terminated-pod-gc-threshold` in the kube-controller-manager). +This avoids a resource leak as Pods are created and terminated over time. +--> +### 失效 Pod 的垃圾收集 {#pod-garbage-collection} + +对于已失败的 Pod 而言，对应的 API 对象仍然会保留在集群的 API 服务器上，直到 +用户或者{{< glossary_tooltip term_id="controller" text="控制器" >}}进程显式地 +将其删除。 + +控制面组件会在 Pod 个数超出所配置的阈值 +（根据 `kube-controller-manager` 的 `terminated-pod-gc-threshold` 设置）时 +删除已终止的 Pod（阶段值为 `Succeeded` 或 `Failed`）。 +这一行为会避免随着时间演进不断创建和终止 Pod 而引起的资源泄露问题。 + +## {{% heading "whatsnext" %}} + +<!-- +* Get hands-on experience + [attaching handlers to Container lifecycle events](/docs/tasks/configure-pod-container/attach-handler-lifecycle-event/). + +* Get hands-on experience + [configuring Liveness, Readiness and Startup Probes](/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/). + +* Learn more about [container lifecycle hooks](/docs/concepts/containers/container-lifecycle-hooks/). + +* For detailed information about Pod / Container status in the API, see [PodStatus](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podstatus-v1-core) +and +[ContainerStatus](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#containerstatus-v1-core). +--> + +* 动手实践[为容器生命周期时间关联处理程序](/zh/docs/tasks/configure-pod-container/attach-handler-lifecycle-event/)。 +* 动手实践[配置存活态、就绪态和启动探针](/zh/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/)。 +* 进一步了解[容器生命周期回调](/zh/docs/concepts/containers/container-lifecycle-hooks/)。 +* 关于 API 中定义的有关 Pod/容器的详细规范信息， + 可参阅 [PodStatus](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podstatus-v1-core) + 和 [ContainerStatus](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#containerstatus-v1-core)。 diff --git a/content/zh/docs/concepts/workloads/pods/pod-overview.md b/content/zh/docs/concepts/workloads/pods/pod-overview.md deleted file mode 100644 index d9c8423450..0000000000 --- a/content/zh/docs/concepts/workloads/pods/pod-overview.md +++ /dev/null @@ -1,265 +0,0 @@ ---- -title: Pod 概览 -content_type: concept -weight: 10 -card: - name: 概念 - weight: 60 ---- - -<!-- ---- -reviewers: -- erictune -title: Pod Overview -content_type: concept -weight: 10 -card: - name: concepts - weight: 60 ---- ---> - -<!-- -This page provides an overview of `Pod`, the smallest deployable object in the Kubernetes object model. ---> -<!-- overview --> -本节提供了 `Pod` 的概览信息，`Pod` 是最小可部署的 Kubernetes 对象模型。 - - - -<!-- body --> - -<!-- -## Understanding Pods ---> -## 理解 Pod - -<!-- -A *Pod* is the basic execution unit of a Kubernetes application--the smallest and simplest unit in the Kubernetes object model that you create or deploy. A Pod represents processes running on your {{< glossary_tooltip term_id="cluster" >}}. ---> -*Pod* 是 Kubernetes 应用程序的基本执行单元，即它是 Kubernetes 对象模型中创建或部署的最小和最简单的单元。Pod 表示在 {{< glossary_tooltip term_id="cluster" >}} 上运行的进程。 - -<!-- -A Pod encapsulates an application's container (or, in some cases, multiple containers), storage resources, a unique network IP, and options that govern how the container(s) should run. A Pod represents a unit of deployment: *a single instance of an application in Kubernetes*, which might consist of either a single {{< glossary_tooltip text="container" term_id="container" >}} or a small number of containers that are tightly coupled and that share resources. ---> -Pod 封装了应用程序容器（或者在某些情况下封装多个容器）、存储资源、唯一网络 IP 以及控制容器应该如何运行的选项。 -Pod 表示部署单元：*Kubernetes 中应用程序的单个实例*，它可能由单个 {{< glossary_tooltip text="容器" term_id="container" >}} 或少量紧密耦合并共享资源的容器组成。 - -<!-- -[Docker](https://www.docker.com) is the most common container runtime used in a Kubernetes Pod, but Pods support other [container runtimes](/docs/setup/production-environment/container-runtimes/) as well. ---> -[Docker](https://www.docker.com) 是 Kubernetes Pod 中最常用的容器运行时，但 Pod 也能支持其他的[容器运行时](/docs/setup/production-environment/container-runtimes/)。 - - -<!-- -Pods in a Kubernetes cluster can be used in two main ways: ---> -Kubernetes 集群中的 Pod 可被用于以下两个主要用途： - -<!-- -* **Pods that run a single container**. The "one-container-per-Pod" model is the most common Kubernetes use case; in this case, you can think of a Pod as a wrapper around a single container, and Kubernetes manages the Pods rather than the containers directly. -* **Pods that run multiple containers that need to work together**. A Pod might encapsulate an application composed of multiple co-located containers that are tightly coupled and need to share resources. These co-located containers might form a single cohesive unit of service--one container serving files from a shared volume to the public, while a separate "sidecar" container refreshes or updates those files. The Pod wraps these containers and storage resources together as a single manageable entity. -The [Kubernetes Blog](https://kubernetes.io/blog) has some additional information on Pod use cases. For more information, see: ---> - -* **运行单个容器的 Pod**。"每个 Pod 一个容器"模型是最常见的 Kubernetes 用例；在这种情况下，可以将 Pod 看作单个容器的包装器，并且 Kubernetes 直接管理 Pod，而不是容器。 -* **运行多个协同工作的容器的 Pod**。 -Pod 可能封装由多个紧密耦合且需要共享资源的共处容器组成的应用程序。 -这些位于同一位置的容器可能形成单个内聚的服务单元 —— 一个容器将文件从共享卷提供给公众，而另一个单独的“挂斗”（sidecar）容器则刷新或更新这些文件。 -Pod 将这些容器和存储资源打包为一个可管理的实体。 -[Kubernetes 博客](https://kubernetes.io/blog) 上有一些其他的 Pod 用例信息。更多信息请参考： - -<!-- - * [The Distributed System Toolkit: Patterns for Composite Containers](https://kubernetes.io/blog/2015/06/the-distributed-system-toolkit-patterns) - * [Container Design Patterns](https://kubernetes.io/blog/2016/06/container-design-patterns) ---> - * [分布式系统工具包：容器组合的模式](https://kubernetes.io/blog/2015/06/the-distributed-system-toolkit-patterns) - * [容器设计模式](https://kubernetes.io/blog/2016/06/container-design-patterns) - -<!-- -Each Pod is meant to run a single instance of a given application. If you want to scale your application horizontally (e.g., run multiple instances), you should use multiple Pods, one for each instance. In Kubernetes, this is generally referred to as _replication_. Replicated Pods are usually created and managed as a group by an abstraction called a Controller. See [Pods and Controllers](#pods-and-controllers) for more information. ---> - -每个 Pod 表示运行给定应用程序的单个实例。如果希望横向扩展应用程序（例如，运行多个实例），则应该使用多个 Pod，每个应用实例使用一个 Pod 。在 Kubernetes 中，这通常被称为 _副本_。通常使用一个称为控制器的抽象来创建和管理一组副本 Pod。更多信息请参见 [Pod 和控制器](#pods-and-controllers)。 - -<!-- -### How Pods manage multiple Containers ---> -### Pod 怎样管理多个容器 - -<!-- -Pods are designed to support multiple cooperating processes (as containers) that form a cohesive unit of service. The containers in a Pod are automatically co-located and co-scheduled on the same physical or virtual machine in the cluster. The containers can share resources and dependencies, communicate with one another, and coordinate when and how they are terminated. ---> -Pod 被设计成支持形成内聚服务单元的多个协作过程（作为容器）。 -Pod 中的容器被自动的安排到集群中的同一物理或虚拟机上，并可以一起进行调度。 -容器可以共享资源和依赖、彼此通信、协调何时以及何种方式终止它们。 - -<!-- -Note that grouping multiple co-located and co-managed containers in a single Pod is a relatively advanced use case. You should use this pattern only in specific instances in which your containers are tightly coupled. For example, you might have a container that acts as a web server for files in a shared volume, and a separate "sidecar" container that updates those files from a remote source, as in the following diagram: ---> - -注意，在单个 Pod 中将多个并置和共同管理的容器分组是一个相对高级的使用方式。 -只在容器紧密耦合的特定实例中使用此模式。 -例如，您可能有一个充当共享卷中文件的 Web 服务器的容器，以及一个单独的 sidecar 容器，该容器从远端更新这些文件，如下图所示： - - -{{< figure src="/images/docs/pod.svg" alt="Pod 图例" width="50%" >}} - - -<!-- -Some Pods have {{< glossary_tooltip text="init containers" term_id="init-container" >}} as well as {{< glossary_tooltip text="app containers" term_id="app-container" >}}. Init containers run and complete before the app containers are started. ---> -有些 Pod 具有 {{< glossary_tooltip text="初始容器" term_id="init-container" >}} 和 {{< glossary_tooltip text="应用容器" term_id="app-container" >}}。初始容器会在启动应用容器之前运行并完成。 - -<!-- -Pods provide two kinds of shared resources for their constituent containers: *networking* and *storage*. ---> - -Pod 为其组成容器提供了两种共享资源：*网络* 和 *存储*。 - -<!-- -#### Networking ---> -#### 网络 - -<!-- -Each Pod is assigned a unique IP address. Every container in a Pod shares the network namespace, including the IP address and network ports. Containers *inside a Pod* can communicate with one another using `localhost`. When containers in a Pod communicate with entities *outside the Pod*, they must coordinate how they use the shared network resources (such as ports). ---> -每个 Pod 分配一个唯一的 IP 地址。 -Pod 中的每个容器共享网络命名空间，包括 IP 地址和网络端口。 -*Pod 内的容器* 可以使用 `localhost` 互相通信。 -当 Pod 中的容器与 *Pod 之外* 的实体通信时，它们必须协调如何使用共享的网络资源（例如端口）。 - -<!-- -#### Storage ---> -#### 存储 - -<!-- -A Pod can specify a set of shared storage {{< glossary_tooltip text="Volumes" term_id="volume" >}}. All containers in the Pod can access the shared volumes, allowing those containers to share data. Volumes also allow persistent data in a Pod to survive in case one of the containers within needs to be restarted. See [Volumes](/docs/concepts/storage/volumes/) for more information on how Kubernetes implements shared storage in a Pod. ---> -一个 Pod 可以指定一组共享存储{{< glossary_tooltip text="卷" term_id="volume" >}}。 -Pod 中的所有容器都可以访问共享卷，允许这些容器共享数据。 -卷还允许 Pod 中的持久数据保留下来，以防其中的容器需要重新启动。 -有关 Kubernetes 如何在 Pod 中实现共享存储的更多信息，请参考[卷](/docs/concepts/storage/volumes/)。 - -<!-- -## Working with Pods ---> -## 使用 Pod - -<!-- -You'll rarely create individual Pods directly in Kubernetes--even singleton Pods. This is because Pods are designed as relatively ephemeral, disposable entities. When a Pod gets created (directly by you, or indirectly by a Controller), it is scheduled to run on a {{< glossary_tooltip term_id="node" >}} in your cluster. The Pod remains on that Node until the process is terminated, the pod object is deleted, the Pod is *evicted* for lack of resources, or the Node fails. ---> -你很少在 Kubernetes 中直接创建单独的 Pod，甚至是单个存在的 Pod。 -这是因为 Pod 被设计成了相对短暂的一次性的实体。 -当 Pod 由您创建或者间接地由控制器创建时，它被调度在集群中的 {{< glossary_tooltip term_id="node" >}} 上运行。 -Pod 会保持在该节点上运行，直到进程被终止、Pod 对象被删除、Pod 因资源不足而被 *驱逐* 或者节点失效为止。 - -<!-- -Restarting a container in a Pod should not be confused with restarting the Pod. The Pod itself does not run, but is an environment the containers run in and persists until it is deleted. ---> -{{< note >}} -重启 Pod 中的容器不应与重启 Pod 混淆。Pod 本身不运行，而是作为容器运行的环境，并且一直保持到被删除为止。 -{{< /note >}} - -<!-- -Pods do not, by themselves, self-heal. If a Pod is scheduled to a Node that fails, or if the scheduling operation itself fails, the Pod is deleted; likewise, a Pod won't survive an eviction due to a lack of resources or Node maintenance. Kubernetes uses a higher-level abstraction, called a *Controller*, that handles the work of managing the relatively disposable Pod instances. Thus, while it is possible to use Pod directly, it's far more common in Kubernetes to manage your pods using a Controller. See [Pods and Controllers](#pods-and-controllers) for more information on how Kubernetes uses Controllers to implement Pod scaling and healing. ---> - -Pod 本身并不能自愈。 -如果 Pod 被调度到失败的节点，或者如果调度操作本身失败，则删除该 Pod；同样，由于缺乏资源或进行节点维护，Pod 在被驱逐后将不再生存。 -Kubernetes 使用了一个更高级的称为 *控制器* 的抽象，由它处理相对可丢弃的 Pod 实例的管理工作。 -因此，虽然可以直接使用 Pod，但在 Kubernetes 中，更为常见的是使用控制器管理 Pod。 -有关 Kubernetes 如何使用控制器实现 Pod 伸缩和愈合的更多信息，请参考 [Pod 和控制器](#pods-and-controllers)。 - -<!-- -### Pods and Controllers ---> -### Pod 和控制器 {#pods-and-controllers} - -<!-- -A Controller can create and manage multiple Pods for you, handling replication and rollout and providing self-healing capabilities at cluster scope. For example, if a Node fails, the Controller might automatically replace the Pod by scheduling an identical replacement on a different Node. ---> -控制器可以为您创建和管理多个 Pod，管理副本和上线，并在集群范围内提供自修复能力。 -例如，如果一个节点失败，控制器可以在不同的节点上调度一样的替身来自动替换 Pod。 - -<!-- -Some examples of Controllers that contain one or more pods include: ---> -包含一个或多个 Pod 的控制器一些示例包括： - -<!-- -* [Deployment](/docs/concepts/workloads/controllers/deployment/) -* [StatefulSet](/docs/concepts/workloads/controllers/statefulset/) -* [DaemonSet](/docs/concepts/workloads/controllers/daemonset/) ---> -* [Deployment](/docs/concepts/workloads/controllers/deployment/) -* [StatefulSet](/docs/concepts/workloads/controllers/statefulset/) -* [DaemonSet](/docs/concepts/workloads/controllers/daemonset/) - -<!-- -In general, Controllers use a Pod Template that you provide to create the Pods for which it is responsible. ---> -控制器通常使用您提供的 Pod 模板来创建它所负责的 Pod。 - -<!-- -## Pod Templates ---> -## Pod 模板 - -<!-- -Pod templates are pod specifications which are included in other objects, such as -[Replication Controllers](/docs/concepts/workloads/controllers/replicationcontroller/), [Jobs](/docs/concepts/jobs/run-to-completion-finite-workloads/), and -[DaemonSets](/docs/concepts/workloads/controllers/daemonset/). Controllers use Pod Templates to make actual pods. -The sample below is a simple manifest for a Pod which contains a container that prints -a message. ---> -Pod 模板是包含在其他对象中的 Pod 规范，例如 -[Replication Controllers](/docs/concepts/workloads/controllers/replicationcontroller/)、 [Jobs](/docs/concepts/jobs/run-to-completion-finite-workloads/) 和 -[DaemonSets](/docs/concepts/workloads/controllers/daemonset/)。 -控制器使用 Pod 模板来制作实际使用的 Pod。 -下面的示例是一个简单的 Pod 清单，它包含一个打印消息的容器。 - -```yaml -apiVersion: v1 -kind: Pod -metadata: - name: myapp-pod - labels: - app: myapp -spec: - containers: - - name: myapp-container - image: busybox - command: ['sh', '-c', 'echo Hello Kubernetes! && sleep 3600'] -``` - -<!-- -Rather than specifying the current desired state of all replicas, pod templates are like cookie cutters. Once a cookie has been cut, the cookie has no relationship to the cutter. There is no "quantum entanglement". Subsequent changes to the template or even switching to a new template has no direct effect on the pods already created. Similarly, pods created by a replication controller may subsequently be updated directly. This is in deliberate contrast to pods, which do specify the current desired state of all containers belonging to the pod. This approach radically simplifies system semantics and increases the flexibility of the primitive. ---> - -Pod 模板就像饼干切割器，而不是指定所有副本的当前期望状态。 -一旦饼干被切掉，饼干就与切割器没有关系。 -没有“量子纠缠”。 -随后对模板的更改或甚至切换到新的模板对已经创建的 Pod 没有直接影响。 -类似地，由副本控制器创建的 Pod 随后可以被直接更新。 -这与 Pod 形成有意的对比，Pod 指定了属于 Pod 的所有容器的当前期望状态。 -这种方法从根本上简化了系统语义，增加了原语的灵活性。 - - - -<!-- -* Learn more about [Pods](/docs/concepts/workloads/pods/pod/) -* Learn more about Pod behavior: - * [Pod Termination](/docs/concepts/workloads/pods/pod/#termination-of-pods) - * [Pod Lifecycle](/docs/concepts/workloads/pods/pod-lifecycle/) ---> -## {{% heading "whatsnext" %}} - -* 详细了解 [Pod](/docs/concepts/workloads/pods/pod/) -* 了解有关 Pod 行为的更多信息： - * [Pod 的终止](/docs/concepts/workloads/pods/pod/#termination-of-pods) - * [Pod 的生命周期](/docs/concepts/workloads/pods/pod-lifecycle/) - diff --git a/content/zh/docs/concepts/workloads/pods/pod-topology-spread-constraints.md b/content/zh/docs/concepts/workloads/pods/pod-topology-spread-constraints.md index 826ca5bd78..4e7a2c5536 100644 --- a/content/zh/docs/concepts/workloads/pods/pod-topology-spread-constraints.md +++ b/content/zh/docs/concepts/workloads/pods/pod-topology-spread-constraints.md @@ -5,13 +5,9 @@ weight: 50 --- <!-- - title: Pod Topology Spread Constraints content_type: concept weight: 50 - ---- - --> <!-- overview --> @@ -24,20 +20,16 @@ You can use _topology spread constraints_ to control how {{< glossary_tooltip te 可以使用*拓扑扩展约束*来控制 {{< glossary_tooltip text="Pods" term_id="Pod" >}} 在集群内故障域（例如地区，区域，节点和其他用户自定义拓扑域）之间的分布。这可以帮助实现高可用以及提升资源利用率。 - - <!-- body --> <!-- ## Prerequisites --> - ## 先决条件 <!-- ### Enable Feature Gate --> - ### 启用功能 <!-- @@ -48,24 +40,24 @@ for an explanation of enabling feature gates. The `EvenPodsSpread` feature gate {{< glossary_tooltip text="scheduler" term_id="kube-scheduler" >}}. --> -确保 `EvenPodsSpread` 功能已开启（在 1.16 版本中该功能默认关闭）。阅读[功能选项](/docs/reference/command-line-tools-reference/feature-gates/)了解如何开启该功能。`EvenPodsSpread` 必须在 {{< glossary_tooltip text="API Server" term_id="kube-apiserver" >}} **和** {{< glossary_tooltip text="scheduler" term_id="kube-scheduler" >}} 中都要开启。 +确保 `EvenPodsSpread` 功能已开启（在 1.16 版本中该功能默认关闭）。 +阅读[特性门控](/zh/docs/reference/command-line-tools-reference/feature-gates/)了解如何开启该功能。 +`EvenPodsSpread` 必须在 {{< glossary_tooltip text="API 服务器" term_id="kube-apiserver" >}} **和** +{{< glossary_tooltip text="调度器" term_id="kube-scheduler" >}} 中都开启。 <!-- ### Node Labels --> - ### 节点标签 <!-- Topology spread constraints rely on node labels to identify the topology domain(s) that each Node is in. For example, a Node might have labels: `node=node1,zone=us-east-1a,region=us-east-1` --> - 拓扑扩展约束依赖于节点标签来标识每个节点所在的拓扑域。例如，一个节点可能具有标签：`node=node1,zone=us-east-1a,region=us-east-1` <!-- Suppose you have a 4-node cluster with the following labels: --> - 假设你拥有一个具有以下标签的 4 节点集群： ``` @@ -79,7 +71,6 @@ node4 Ready <none> 2m43s v1.16.0 node=node4,zone=zoneB <!-- Then the cluster is logically viewed as below: --> - 然后从逻辑上看集群如下： ``` @@ -93,13 +84,11 @@ Then the cluster is logically viewed as below: <!-- Instead of manually applying labels, you can also reuse the [well-known labels](/docs/reference/kubernetes-api/labels-annotations-taints/) that are created and populated automatically on most clusters. --> - -可以复用在大多数集群上自动创建和填充的[知名标签](/docs/reference/kubernetes-api/labels-annotations-taints/)，而不是手动添加标签。 +可以复用在大多数集群上自动创建和填充的[常用标签](/zh/docs/reference/kubernetes-api/labels-annotations-taints/)，而不是手动添加标签。 <!-- ## Spread Constraints for Pods --> - ## Pod 的拓扑约束 ### API @@ -107,7 +96,6 @@ Instead of manually applying labels, you can also reuse the [well-known labels]( <!-- The field `pod.spec.topologySpreadConstraints` is introduced in 1.16 as below: --> - `pod.spec.topologySpreadConstraints` 字段定义如下所示： ```yaml @@ -126,7 +114,6 @@ spec: <!-- You can define one or multiple `topologySpreadConstraint` to instruct the kube-scheduler how to place each incoming Pod in relation to the existing Pods across your cluster. The fields are: --> - 可以定义一个或多个 `topologySpreadConstraint` 来指示 kube-scheduler 如何将每个传入的 Pod 根据与现有的 Pod 的关联关系在集群中部署。字段包括： <!-- @@ -143,23 +130,20 @@ You can define one or multiple `topologySpreadConstraint` to instruct the kube-s - **whenUnsatisfiable** 指示如果 pod 不满足扩展约束时如何处理： - `DoNotSchedule`（默认）告诉调度器不用进行调度。 - `ScheduleAnyway` 告诉调度器在对最小化倾斜的节点进行优先级排序时仍对其进行调度。 -- **labelSelector** 用于查找匹配的 pod。匹配此标签的 pod 将被统计，以确定相应拓扑域中 pod 的数量。有关详细信息，请参考[标签选择器](/docs/concepts/overview/working-with-objects/labels/#label-selectors)。 +- **labelSelector** 用于查找匹配的 pod。匹配此标签的 pod 将被统计，以确定相应拓扑域中 pod 的数量。 + 有关详细信息，请参考[标签选择算符](/zh/docs/concepts/overview/working-with-objects/labels/#label-selectors)。 <!-- You can read more about this field by running `kubectl explain Pod.spec.topologySpreadConstraints`. --> - 执行 `kubectl explain Pod.spec.topologySpreadConstraints` 命令了解更多关于 topologySpreadConstraints 的信息。 <!-- ### Example: One TopologySpreadConstraint ---> -### 例子：单个拓扑扩展约束 - -<!-- Suppose you have a 4-node cluster where 3 Pods labeled `foo:bar` are located in node1, node2 and node3 respectively (`P` represents Pod): --> +### 例子：单个拓扑扩展约束 假设你拥有一个 4 节点集群，其中标记为 `foo:bar` 的 3 个 pod 分别位于 node1，node2 和 node3 中（`P` 表示 pod）： @@ -176,7 +160,6 @@ Suppose you have a 4-node cluster where 3 Pods labeled `foo:bar` are located in <!-- If we want an incoming Pod to be evenly spread with existing Pods across zones, the spec can be given as: --> - 如果希望传入的 pod 均匀散布在现有的 pod 区域，则可以指定字段如下： {{< codenew file="pods/topology-spread-constraints/one-constraint.yaml" >}} @@ -184,14 +167,15 @@ If we want an incoming Pod to be evenly spread with existing Pods across zones, <!-- `topologyKey: zone` implies the even distribution will only be applied to the nodes which have label pair "zone:<any value>" present. `whenUnsatisfiable: DoNotSchedule` tells the scheduler to let it stay pending if the incoming Pod can’t satisfy the constraint. --> - -`topologyKey: zone` 意味着均匀分布将只应用于存在标签对为 "zone:<any value>" 的节点上。`whenUnsatisfiable: DoNotSchedule` 告诉调度器，如果传入的 pod 不满足约束，则让它保持挂起状态。 +`topologyKey: zone` 意味着均匀分布将只应用于存在标签对为 "zone:<any value>" 的节点上。 +`whenUnsatisfiable: DoNotSchedule` 告诉调度器，如果传入的 pod 不满足约束，则让它保持悬决状态。 <!-- -If the scheduler placed this incoming Pod into "zoneA", the Pods distribution would become [3, 1], hence the actual skew is 2 (3 - 1) - which violates `maxSkew: 1`. In this example, the incoming Pod can only be placed onto "zoneB": +If the scheduler placed this incoming Pod into "zoneA", the Pods distribution would become [3, 1], +hence the actual skew is 2 (3 - 1) - which violates `maxSkew: 1`. In this example, the incoming Pod can only be placed onto "zoneB": --> - -如果调度器将传入的 pod 放入 "zoneA"，pod 分布将变为 [3, 1]，因此实际的倾斜为 2（3 - 1）。这违反了 `maxSkew: 1`。此示例中，传入的 pod 只能放置在 "zoneB" 上： +如果调度器将传入的 pod 放入 "zoneA"，pod 分布将变为 [3, 1]，因此实际的倾斜为 2（3 - 1）。 +这违反了 `maxSkew: 1`。此示例中，传入的 pod 只能放置在 "zoneB" 上： ``` +---------------+---------------+ +---------------+---------------+ @@ -206,7 +190,6 @@ If the scheduler placed this incoming Pod into "zoneA", the Pods distribution wo <!-- You can tweak the Pod spec to meet various kinds of requirements: --> - 可以调整 pod 规格以满足各种要求： <!-- @@ -214,22 +197,25 @@ You can tweak the Pod spec to meet various kinds of requirements: - Change `topologyKey` to "node" so as to distribute the Pods evenly across nodes instead of zones. In the above example, if `maxSkew` remains "1", the incoming Pod can only be placed onto "node4". - Change `whenUnsatisfiable: DoNotSchedule` to `whenUnsatisfiable: ScheduleAnyway` to ensure the incoming Pod to be always schedulable (suppose other scheduling APIs are satisfied). However, it’s preferred to be placed onto the topology domain which has fewer matching Pods. (Be aware that this preferability is jointly normalized with other internal scheduling priorities like resource usage ratio, etc.) --> - - 将 `maxSkew` 更改为更大的值，比如 "2"，这样传入的 pod 也可以放在 "zoneA" 上。 -- 将 `topologyKey` 更改为 "node"，以便将 pod 均匀分布在节点上而不是区域中。在上面的例子中，如果 `maxSkew` 保持为 "1"，那么传入的 pod 只能放在 "node4" 上。 -- 将 `whenUnsatisfiable: DoNotSchedule` 更改为 `whenUnsatisfiable: ScheduleAnyway`，以确保传入的 pod 始终可以调度（假设满足其他的调度 API）。但是，最好将其放置在具有较少匹配 pod 的拓扑域中。（请注意，此优先性与其他内部调度优先级（如资源使用率等）一起进行标准化。） +- 将 `topologyKey` 更改为 "node"，以便将 pod 均匀分布在节点上而不是区域中。 + 在上面的例子中，如果 `maxSkew` 保持为 "1"，那么传入的 pod 只能放在 "node4" 上。 +- 将 `whenUnsatisfiable: DoNotSchedule` 更改为 `whenUnsatisfiable: ScheduleAnyway`， + 以确保传入的 Pod 始终可以调度（假设满足其他的调度 API）。 + 但是，最好将其放置在具有较少匹配 Pod 的拓扑域中。 + （请注意，此优先性与其他内部调度优先级（如资源使用率等）一起进行标准化。） <!-- ### Example: Multiple TopologySpreadConstraints --> - ### 例子：多个拓扑扩展约束 <!-- This builds upon the previous example. Suppose you have a 4-node cluster where 3 Pods labeled `foo:bar` are located in node1, node2 and node3 respectively (`P` represents Pod): --> -下面的例子建立在前面例子的基础上。假设你拥有一个 4 节点集群，其中 3 个标记为 `foo:bar` 的 pod 分别位于 node1，node2 和 node3 上（`P` 表示 pod）： +下面的例子建立在前面例子的基础上。假设你拥有一个 4 节点集群，其中 3 个标记为 `foo:bar` 的 +Pod 分别位于 node1，node2 和 node3 上（`P` 表示 Pod）： ``` +---------------+---------------+ @@ -244,7 +230,6 @@ This builds upon the previous example. Suppose you have a 4-node cluster where 3 <!-- You can use 2 TopologySpreadConstraints to control the Pods spreading on both zone and node: --> - 可以使用 2 个拓扑扩展约束来控制 pod 在 区域和节点两个维度上进行分布： {{< codenew file="pods/topology-spread-constraints/two-constraints.yaml" >}} @@ -252,13 +237,12 @@ You can use 2 TopologySpreadConstraints to control the Pods spreading on both zo <!-- In this case, to match the first constraint, the incoming Pod can only be placed onto "zoneB"; while in terms of the second constraint, the incoming Pod can only be placed onto "node4". Then the results of 2 constraints are ANDed, so the only viable option is to place on "node4". --> - -在这种情况下，为了匹配第一个约束，传入的 pod 只能放置在 "zoneB" 中；而在第二个约束中，传入的 pod 只能放置在 "node4" 上。然后两个约束的结果加在一起，因此唯一可行的选择是放置在 "node4" 上。 +在这种情况下，为了匹配第一个约束，传入的 pod 只能放置在 "zoneB" 中；而在第二个约束中， +传入的 Pod 只能放置在 "node4" 上。然后两个约束的结果加在一起，因此唯一可行的选择是放置在 "node4" 上。 <!-- Multiple constraints can lead to conflicts. Suppose you have a 3-node cluster across 2 zones: --> - 多个约束可能导致冲突。假设有一个跨越 2 个区域的 3 节点集群： ``` @@ -274,58 +258,53 @@ Multiple constraints can lead to conflicts. Suppose you have a 3-node cluster ac <!-- If you apply "two-constraints.yaml" to this cluster, you will notice "mypod" stays in `Pending` state. This is because: to satisfy the first constraint, "mypod" can only be put to "zoneB"; while in terms of the second constraint, "mypod" can only put to "node2". Then a joint result of "zoneB" and "node2" returns nothing. --> - -如果对集群应用 "two-constraints.yaml"，会发现 "mypod" 处于 `Pending` 状态。这是因为：为了满足第一个约束，"mypod" 只能放在 "zoneB" 中，而第二个约束要求 "mypod" 只能放在 "node2" 上。pod 调度无法满足两种约束。 +如果对集群应用 "two-constraints.yaml"，会发现 "mypod" 处于 `Pending` 状态。 +这是因为：为了满足第一个约束，"mypod" 只能放在 "zoneB" 中，而第二个约束要求 +"mypod" 只能放在 "node2" 上。pod 调度无法满足两种约束。 <!-- To overcome this situation, you can either increase the `maxSkew` or modify one of the constraints to use `whenUnsatisfiable: ScheduleAnyway`. --> - -为了克服这种情况，可以增加 `maxSkew` 或修改其中一个约束，让其使用 `whenUnsatisfiable: ScheduleAnyway`。 +为了克服这种情况，可以增加 `maxSkew` 或修改其中一个约束，让其使用 +`whenUnsatisfiable: ScheduleAnyway`。 <!-- ### Conventions ---> -### 约定 - -<!-- There are some implicit conventions worth noting here: --> +### 约定 这里有一些值得注意的隐式约定： <!-- - Only the Pods holding the same namespace as the incoming Pod can be matching candidates. ---> - -- 只有与传入 pod 具有相同命名空间的 pod 才能作为匹配候选者。 - -<!-- - Nodes without `topologySpreadConstraints[*].topologyKey` present will be bypassed. It implies that: 1. the Pods located on those nodes do not impact `maxSkew` calculation - in the above example, suppose "node1" does not have label "zone", then the 2 Pods will be disregarded, hence the incomingPod will be scheduled into "zoneA". 2. the incoming Pod has no chances to be scheduled onto this kind of nodes - in the above example, suppose a "node5" carrying label `{zone-typo: zoneC}` joins the cluster, it will be bypassed due to the absence of label key "zone". --> - +- 只有与传入 pod 具有相同命名空间的 pod 才能作为匹配候选者。 - 没有 `topologySpreadConstraints[*].topologyKey` 的节点将被忽略。这意味着： - 1. 位于这些节点上的 pod 不影响 `maxSkew` 的计算。在上面的例子中，假设 "node1" 没有标签 "zone"，那么 2 个 pod 将被忽略，因此传入的 pod 将被调度到 "zoneA" 中。 - 2. 传入的 pod 没有机会被调度到这类节点上。在上面的例子中，假设一个带有标签 `{zone-typo: zoneC}` 的 "node5" 加入到集群，它将由于没有标签键 "zone" 而被忽略。 + 1. 位于这些节点上的 pod 不影响 `maxSkew` 的计算。 + 在上面的例子中，假设 "node1" 没有标签 "zone"，那么 2 个 Pod 将被忽略， + 因此传入的 Pod 将被调度到 "zoneA" 中。 + 2. 传入的 Pod 没有机会被调度到这类节点上。 + 在上面的例子中，假设一个带有标签 `{zone-typo: zoneC}` 的 "node5" 加入到集群， + 它将由于没有标签键 "zone" 而被忽略。 <!-- - Be aware of what will happen if the incomingPod’s `topologySpreadConstraints[*].labelSelector` doesn’t match its own labels. In the above example, if we remove the incoming Pod’s labels, it can still be placed onto "zoneB" since the constraints are still satisfied. However, after the placement, the degree of imbalance of the cluster remains unchanged - it’s still zoneA having 2 Pods which hold label {foo:bar}, and zoneB having 1 Pod which holds label {foo:bar}. So if this is not what you expect, we recommend the workload’s `topologySpreadConstraints[*].labelSelector` to match its own labels. --> - -注意，如果传入 pod 的 `topologySpreadConstraints[*].labelSelector` 与自身的标签不匹配，将会发生什么。在上面的例子中，如果移除传入 pod 的标签，pod 仍然可以调度到 "zoneB"，因为约束仍然满足。然而，在调度之后，集群的不平衡程度保持不变。zoneA 仍然有 2 个带有 {foo:bar} 标签的 pod，zoneB 有 1 个带有 {foo:bar} 标签的 pod。因此，如果这不是你所期望的，建议工作负载的 `topologySpreadConstraints[*].labelSelector` 与其自身的标签匹配。 +注意，如果传入 Pod 的 `topologySpreadConstraints[*].labelSelector` 与自身的标签不匹配，将会发生什么。 +在上面的例子中，如果移除传入 Pod 的标签，Pod 仍然可以调度到 "zoneB"，因为约束仍然满足。 +然而，在调度之后，集群的不平衡程度保持不变。zoneA 仍然有 2 个带有 {foo:bar} 标签的 Pod， +zoneB 有 1 个带有 {foo:bar} 标签的 Pod。 +因此，如果这不是你所期望的，建议工作负载的 `topologySpreadConstraints[*].labelSelector` +与其自身的标签匹配。 <!-- - If the incoming Pod has `spec.nodeSelector` or `spec.affinity.nodeAffinity` defined, nodes not matching them will be bypassed. ---> - -<!-- Suppose you have a 5-node cluster ranging from zoneA to zoneC: ---> - -<!-- and you know that "zoneC" must be excluded. In this case, you can compose the yaml as below, so that "mypod" will be placed onto "zoneB" instead of "zoneC". Similarly `spec.nodeSelector` is also respected. --> @@ -349,14 +328,11 @@ There are some implicit conventions worth noting here: <!-- ## Comparison with PodAffinity/PodAntiAffinity ---> -## 与 PodAffinity/PodAntiAffinity 相比较 - -<!-- In Kubernetes, directives related to "Affinity" control how Pods are scheduled - more packed or more scattered. --> +## 与 PodAffinity/PodAntiAffinity 相比较 在 Kubernetes 中，与 "Affinity" 相关的指令控制 pod 的调度方式（更密集或更分散）。 @@ -366,7 +342,6 @@ topology domain(s) - For `PodAntiAffinity`, only one Pod can be scheduled into a single topology domain. --> - - 对于 `PodAffinity`，可以尝试将任意数量的 pod 打包到符合条件的拓扑域中。 - 对于 `PodAntiAffinity`，只能将一个 pod 调度到单个拓扑域中。 @@ -376,26 +351,24 @@ topology domains - to achieve high availability or cost-saving. This can also he workloads and scaling out replicas smoothly. See [Motivation](https://github.com/kubernetes/enhancements/blob/master/keps/sig-scheduling/20190221-pod-topology-spread.md#motivation) for more details. --> - -"EvenPodsSpread" 功能提供灵活的选项来将 pod 均匀分布到不同的拓扑域中，以实现高可用性或节省成本。这也有助于滚动更新工作负载和平滑扩展副本。有关详细信息，请参考[动机](https://github.com/kubernetes/enhancements/blob/master/keps/sig-scheduling/20190221-pod-topology-spread.md#motivation)。 +"EvenPodsSpread" 功能提供灵活的选项来将 pod 均匀分布到不同的拓扑域中，以实现高可用性或节省成本。 +这也有助于滚动更新工作负载和平滑扩展副本。 +有关详细信息，请参考[动机](https://github.com/kubernetes/enhancements/blob/master/keps/sig-scheduling/20190221-pod-topology-spread.md#motivation)。 <!-- ## Known Limitations + +As of 1.16, at which this feature is Alpha, there are some known limitations: --> ## 已知局限性 -<!-- -As of 1.16, at which this feature is Alpha, there are some known limitations: ---> - 1.16 版本（此功能为 alpha）存在下面的一些限制： <!-- - Scaling down a `Deployment` may result in imbalanced Pods distribution. - Pods matched on tainted nodes are respected. See [Issue 80921](https://github.com/kubernetes/kubernetes/issues/80921) --> - - `Deployment` 的缩容可能导致 pod 分布不平衡。 - pod 匹配到污点节点是允许的。参考 [Issue 80921](https://github.com/kubernetes/kubernetes/issues/80921)。 diff --git a/content/zh/docs/concepts/workloads/pods/pod.md b/content/zh/docs/concepts/workloads/pods/pod.md deleted file mode 100644 index b0a0486280..0000000000 --- a/content/zh/docs/concepts/workloads/pods/pod.md +++ /dev/null @@ -1,387 +0,0 @@ ---- -title: Pods -content_type: concept -weight: 20 ---- - -<!-- -reviewers: -title: Pods -content_type: concept -weight: 20 ---> - -<!-- overview --> - -<!-- -_Pods_ are the smallest deployable units of computing that can be created and -managed in Kubernetes. ---> - -_Pod_ 是可以在 Kubernetes 中创建和管理的、最小的可部署的计算单元。 - - - - -<!-- body --> - -<!-- -## What is a Pod? ---> -## Pod 是什么？ - -<!-- -A _Pod_ (as in a pod of whales or pea pod) is a group of one or more -{{< glossary_tooltip text="containers" term_id="container" >}} (such as -Docker containers), with shared storage/network, and a specification -for how to run the containers. A Pod's contents are always co-located and -co-scheduled, and run in a shared context. A Pod models an -application-specific "logical host" - it contains one or more application -containers which are relatively tightly coupled — in a pre-container -world, being executed on the same physical or virtual machine would mean being -executed on the same logical host. ---> -_Pod_ （就像在鲸鱼荚或者豌豆荚中）是一组（一个或多个）{{< glossary_tooltip text="容器" term_id="container" >}}（例如 Docker 容器），这些容器共享存储、网络、以及怎样运行这些容器的声明。Pod 中的内容总是并置（colocated）的并且一同调度，在共享的上下文中运行。 -Pod 所建模的是特定于应用的“逻辑主机”，其中包含一个或多个应用容器，这些容器是相对紧密的耦合在一起 — 在容器出现之前，在相同的物理机或虚拟机上运行意味着在相同的逻辑主机上运行。 - -<!-- -While Kubernetes supports more container runtimes than just Docker, Docker is -the most commonly known runtime, and it helps to describe Pods in Docker terms. ---> -虽然 Kubernetes 支持多种容器运行时，但 Docker 是最常见的一种运行时，它有助于使用 Docker 术语来描述 Pod。 - -<!-- -The shared context of a Pod is a set of Linux namespaces, cgroups, and -potentially other facets of isolation - the same things that isolate a Docker -container. Within a Pod's context, the individual applications may have -further sub-isolations applied. ---> -Pod 的共享上下文是一组 Linux 命名空间、cgroups、以及其他潜在的资源隔离相关的因素，这些相同的东西也隔离了 Docker 容器。在 Pod 的上下文中，单个应用程序可能还会应用进一步的子隔离。 - -<!-- -Containers within a Pod share an IP address and port space, and -can find each other via `localhost`. They can also communicate with each -other using standard inter-process communications like SystemV semaphores or -POSIX shared memory. Containers in different Pods have distinct IP addresses -and can not communicate by IPC without -[special configuration](/docs/concepts/policy/pod-security-policy/). -These containers usually communicate with each other via Pod IP addresses. - -Applications within a Pod also have access to shared {{< glossary_tooltip text="volumes" term_id="volume" >}}, which are defined -as part of a Pod and are made available to be mounted into each application's -filesystem. ---> -Pod 中的所有容器共享一个 IP 地址和端口空间，并且可以通过 `localhost` 互相发现。他们也能通过标准的进程间通信（如 SystemV 信号量或 POSIX 共享内存）方式进行互相通信。不同 Pod 中的容器的 IP 地址互不相同，没有 [特殊配置](/docs/concepts/policy/pod-security-policy/) 就不能使用 IPC 进行通信。这些容器之间经常通过 Pod IP 地址进行通信。 - -Pod 中的应用也能访问共享 {{< glossary_tooltip text="卷" term_id="volume" >}}，共享卷是 Pod 定义的一部分，可被用来挂载到每个应用的文件系统上。 - -<!-- -In terms of [Docker](https://www.docker.com/) constructs, a Pod is modelled as -a group of Docker containers with shared namespaces and shared filesystem -volumes. ---> -在 [Docker](https://www.docker.com/) 体系的术语中，Pod 被建模为一组具有共享命名空间和共享文件系统[卷](/docs/concepts/storage/volumes/) 的 Docker 容器。 - -<!-- -Like individual application containers, Pods are considered to be relatively -ephemeral (rather than durable) entities. As discussed in -[pod lifecycle](/docs/concepts/workloads/pods/pod-lifecycle/), Pods are created, assigned a unique ID (UID), and -scheduled to nodes where they remain until termination (according to restart -policy) or deletion. If a {{< glossary_tooltip term_id="node" >}} dies, the Pods scheduled to that node are -scheduled for deletion, after a timeout period. A given Pod (as defined by a UID) is not -"rescheduled" to a new node; instead, it can be replaced by an identical Pod, -with even the same name if desired, but with a new UID (see [replication -controller](/docs/concepts/workloads/controllers/replicationcontroller/) for more details). ---> -与单个应用程序容器一样，Pod 被认为是相对短暂的（而不是持久的）实体。如 [Pod 的生命周期](/docs/concepts/workloads/pods/pod-lifecycle/) 所讨论的那样：Pod 被创建、给它指定一个唯一 ID （UID）、被调度到节点、在节点上存续直到终止（取决于重启策略）或被删除。如果 {{< glossary_tooltip term_id="node" >}} 宕机，调度到该节点上的 Pod 会在一个超时周期后被安排删除。给定 Pod （由 UID 定义）不会重新调度到新节点；相反，它会被一个完全相同的 Pod 替换掉，如果需要甚至连 Pod 名称都可以一样，除了 UID 是新的(更多信息请查阅 [副本控制器（replication -controller）](/docs/concepts/workloads/controllers/replicationcontroller/)。 - -<!-- -When something is said to have the same lifetime as a Pod, such as a volume, -that means that it exists as long as that Pod (with that UID) exists. If that -Pod is deleted for any reason, even if an identical replacement is created, the -related thing (e.g. volume) is also destroyed and created anew. ---> -当某些东西被说成与 Pod（如卷）具有相同的生命周期时，这表明只要 Pod（具有该 UID）存在，它就存在。如果出于任何原因删除了该 Pod，即使创建了相同的 Pod，相关的内容（例如卷）也会被销毁并重新创建。 - -{{< figure src="/images/docs/pod.svg" title="Pod diagram" width="50%" >}} - -<!-- -*A multi-container Pod that contains a file puller and a -web server that uses a persistent volume for shared storage between the containers.* ---> - -*一个多容器 Pod，其中包含一个文件拉取器和一个 Web 服务器，该 Web 服务器使用持久卷在容器之间共享存储* - -<!-- -## Motivation for pods ---> -## 设计 Pod 的目的 - -<!-- -### Management ---> -### 管理 - -<!-- -Pods are a model of the pattern of multiple cooperating processes which form a -cohesive unit of service. They simplify application deployment and management -by providing a higher-level abstraction than the set of their constituent -applications. Pods serve as unit of deployment, horizontal scaling, and -replication. Colocation (co-scheduling), shared fate (e.g. termination), -coordinated replication, resource sharing, and dependency management are -handled automatically for containers in a Pod. ---> -Pod 是形成内聚服务单元的多个协作过程模式的模型。它们提供了一个比它们的应用组成集合更高级的抽象，从而简化了应用的部署和管理。Pod 可以用作部署、水平扩展和制作副本的最小单元。在 Pod 中，系统自动处理多个容器的在并置运行（协同调度）、生命期共享（例如，终止），协同复制、资源共享和依赖项管理。 - -<!-- -### Resource sharing and communication ---> -### 资源共享和通信 - -<!-- -Pods enable data sharing and communication among their constituents. ---> -Pod 使它的组成容器间能够进行数据共享和通信。 - -<!-- -The applications in a Pod all use the same network namespace (same IP and port -space), and can thus "find" each other and communicate using `localhost`. -Because of this, applications in a Pod must coordinate their usage of ports. -Each Pod has an IP address in a flat shared networking space that has full -communication with other physical computers and Pods across the network. ---> -Pod 中的应用都使用相同的网络命名空间（相同 IP 和 端口空间），而且能够互相“发现”并使用 `localhost` 进行通信。因此，在 Pod 中的应用必须协调它们的端口使用情况。每个 Pod 在扁平的共享网络空间中具有一个 IP 地址，该空间通过网络与其他物理计算机和 Pod 进行全面通信。 - -<!-- -Containers within the Pod see the system hostname as being the same as the configured -`name` for the Pod. There's more about this in the [networking](/docs/concepts/cluster-administration/networking/) -section. ---> -Pod 中的容器获取的系统主机名与为 Pod 配置的 `name` 相同。[网络](/docs/concepts/cluster-administration/networking/) 部分提供了更多有关此内容的信息。 - -<!-- -In addition to defining the application containers that run in the Pod, the Pod -specifies a set of shared storage volumes. Volumes enable data to survive -container restarts and to be shared among the applications within the Pod. ---> -Pod 除了定义了 Pod 中运行的应用程序容器之外，Pod 还指定了一组共享存储卷。该共享存储卷能使数据在容器重新启动后继续保留，并能在 Pod 内的应用程序之间共享。 - -<!-- -## Uses of pods ---> -## 使用 Pod - -<!-- -Pods can be used to host vertically integrated application stacks (e.g. LAMP), -but their primary motivation is to support co-located, co-managed helper -programs, such as: - -* content management systems, file and data loaders, local cache managers, etc. -* log and checkpoint backup, compression, rotation, snapshotting, etc. -* data change watchers, log tailers, logging and monitoring adapters, event publishers, etc. -* proxies, bridges, and adapters -* controllers, managers, configurators, and updaters ---> -Pod 可以用于托管垂直集成的应用程序栈（例如，LAMP），但最主要的目的是支持位于同一位置的、共同管理的工具程序，例如： - -* 内容管理系统、文件和数据加载器、本地缓存管理器等。 -* 日志和检查点备份、压缩、旋转、快照等。 -* 数据更改监视器、日志跟踪器、日志和监视适配器、事件发布器等。 -* 代理、桥接器和适配器 -* 控制器、管理器、配置器和更新器 - - -<!-- -Individual Pods are not intended to run multiple instances of the same -application, in general. ---> -通常，不会用单个 Pod 来运行同一应用程序的多个实例。 - -<!-- -For a longer explanation, see [The Distributed System ToolKit: Patterns for -Composite -Containers](https://kubernetes.io/blog/2015/06/the-distributed-system-toolkit-patterns). ---> -有关详细说明，请参考 [分布式系统工具包：组合容器的模式](https://kubernetes.io/blog/2015/06/the-distributed-system-toolkit-patterns)。 - -<!-- -## Alternatives considered ---> -## 可考虑的备选方案 - -<!-- -_Why not just run multiple programs in a single (Docker) container?_ - -1. Transparency. Making the containers within the Pod visible to the - infrastructure enables the infrastructure to provide services to those - containers, such as process management and resource monitoring. This - facilitates a number of conveniences for users. -1. Decoupling software dependencies. The individual containers may be - versioned, rebuilt and redeployed independently. Kubernetes may even support - live updates of individual containers someday. -1. Ease of use. Users don't need to run their own process managers, worry about - signal and exit-code propagation, etc. -1. Efficiency. Because the infrastructure takes on more responsibility, - containers can be lighter weight. ---> -_为什么不在单个（Docker）容器中运行多个程序？_ - -1. 透明度。Pod 内的容器对基础设施可见，使得基础设施能够向这些容器提供服务，例如流程管理和资源监控。这为用户提供了许多便利。 -1. 解耦软件依赖关系。可以独立地对单个容器进行版本控制、重新构建和重新部署。Kubernetes 有一天甚至可能支持单个容器的实时更新。 -1. 易用性。用户不需要运行他们自己的进程管理器、也不用担心信号和退出代码传播等。 -1. 效率。因为基础结构承担了更多的责任，所以容器可以变得更加轻量化。 - -<!-- -_Why not support affinity-based co-scheduling of containers?_ ---> -_为什么不支持基于亲和性的容器协同调度？_ - -<!-- -That approach would provide co-location, but would not provide most of the -benefits of Pods, such as resource sharing, IPC, guaranteed fate sharing, and -simplified management. ---> -这种处理方法尽管可以提供同址，但不能提供 Pod 的大部分好处，如资源共享、IPC、有保证的命运共享和简化的管理。 - -<!-- -## Durability of pods (or lack thereof) ---> -## Pod 的持久性（或稀缺性） - -<!-- -Pods aren't intended to be treated as durable entities. They won't survive scheduling failures, node failures, or other evictions, such as due to lack of resources, or in the case of node maintenance. ---> -不得将 Pod 视为持久实体。它们无法在调度失败、节点故障或其他驱逐策略（例如由于缺乏资源或在节点维护的情况下）中生存。 - -<!-- -In general, users shouldn't need to create Pods directly. They should almost -always use controllers even for singletons, for example, -[Deployments](/docs/concepts/workloads/controllers/deployment/). -Controllers provide self-healing with a cluster scope, as well as replication -and rollout management. -Controllers like [StatefulSet](/docs/concepts/workloads/controllers/statefulset.md) -can also provide support to stateful Pods. ---> -一般来说，用户不需要直接创建 Pod。他们几乎都是使用控制器进行创建，即使对于单例的 Pod 创建也一样使用控制器，例如 [Deployments](/docs/concepts/workloads/controllers/deployment/)。 -控制器提供集群范围的自修复以及副本数和滚动管理。 -像 [StatefulSet](/docs/concepts/workloads/controllers/statefulset.md) 这样的控制器还可以提供支持有状态的 Pod。 - -<!-- -The use of collective APIs as the primary user-facing primitive is relatively common among cluster scheduling systems, including [Borg](https://research.google.com/pubs/pub43438.html), [Marathon](https://mesosphere.github.io/marathon/docs/rest-api.html), [Aurora](http://aurora.apache.org/documentation/latest/reference/configuration/#job-schema), and [Tupperware](https://www.slideshare.net/Docker/aravindnarayanan-facebook140613153626phpapp02-37588997). ---> - -在集群调度系统中，使用 API 合集作为面向用户的主要原语是比较常见的，包括 [Borg](https://research.google.com/pubs/pub43438.html)、[Marathon](https://mesosphere.github.io/marathon/docs/rest-api.html)、[Aurora](http://aurora.apache.org/documentation/latest/reference/configuration/#job-schema)、和 [Tupperware](https://www.slideshare.net/Docker/aravindnarayanan-facebook140613153626phpapp02-37588997)。 - -<!-- -Pod is exposed as a primitive in order to facilitate: ---> -Pod 暴露为原语是为了便于： - -<!-- -* scheduler and controller pluggability -* support for pod-level operations without the need to "proxy" them via controller APIs -* decoupling of Pod lifetime from controller lifetime, such as for bootstrapping -* decoupling of controllers and services — the endpoint controller just watches Pods -* clean composition of Kubelet-level functionality with cluster-level functionality — Kubelet is effectively the "pod controller" -* high-availability applications, which will expect Pods to be replaced in advance of their termination and certainly in advance of deletion, such as in the case of planned evictions or image prefetching. ---> -* 调度器和控制器可插拔性 -* 支持 Pod 级别的操作，而不需要通过控制器 API "代理" 它们 -* Pod 生命与控制器生命的解耦，如自举 -* 控制器和服务的解耦 — 端点控制器只监视 Pod -* kubelet 级别的功能与集群级别功能的清晰组合 — kubelet 实际上是 "Pod 控制器" -* 高可用性应用程序期望在 Pod 终止之前并且肯定要在 Pod 被删除之前替换 Pod，例如在计划驱逐或镜像预先拉取的情况下。 - -<!-- -## Termination of Pods ---> -## Pod 的终止 - -<!-- -Because Pods represent running processes on nodes in the cluster, it is important to allow those processes to gracefully terminate when they are no longer needed (vs being violently killed with a KILL signal and having no chance to clean up). Users should be able to request deletion and know when processes terminate, but also be able to ensure that deletes eventually complete. When a user requests deletion of a Pod, the system records the intended grace period before the Pod is allowed to be forcefully killed, and a TERM signal is sent to the main process in each container. Once the grace period has expired, the KILL signal is sent to those processes, and the Pod is then deleted from the API server. If the Kubelet or the container manager is restarted while waiting for processes to terminate, the termination will be retried with the full grace period. ---> -因为 Pod 代表在集群中的节点上运行的进程，所以当不再需要这些进程时（与被 KILL 信号粗暴地杀死并且没有机会清理相比），允许这些进程优雅地终止是非常重要的。 -用户应该能够请求删除并且知道进程何时终止，但是也能够确保删除最终完成。当用户请求删除 Pod 时，系统会记录在允许强制删除 Pod 之前所期望的宽限期，并向每个容器中的主进程发送 TERM 信号。一旦过了宽限期，KILL 信号就发送到这些进程，然后就从 API 服务器上删除 Pod。如果 Kubelet 或容器管理器在等待进程终止时发生重启，则终止操作将以完整的宽限期进行重试。 - - -<!-- -An example flow: ---> -流程示例： - -<!-- -1. User sends command to delete Pod, with default grace period (30s) -1. The Pod in the API server is updated with the time beyond which the Pod is considered "dead" along with the grace period. -1. Pod shows up as "Terminating" when listed in client commands -1. (simultaneous with 3) When the Kubelet sees that a Pod has been marked as terminating because the time in 2 has been set, it begins the Pod shutdown process. - 1. If one of the Pod's containers has defined a [preStop hook](/docs/concepts/containers/container-lifecycle-hooks/#hook-details), it is invoked inside of the container. If the `preStop` hook is still running after the grace period expires, step 2 is then invoked with a small (2 second) extended grace period. - 1. The container is sent the TERM signal. Note that not all containers in the Pod will receive the TERM signal at the same time and may each require a `preStop` hook if the order in which they shut down matters. -1. (simultaneous with 3) Pod is removed from endpoints list for service, and are no longer considered part of the set of running Pods for replication controllers. Pods that shutdown slowly cannot continue to serve traffic as load balancers (like the service proxy) remove them from their rotations. -1. When the grace period expires, any processes still running in the Pod are killed with SIGKILL. -1. The Kubelet will finish deleting the Pod on the API server by setting grace period 0 (immediate deletion). The Pod disappears from the API and is no longer visible from the client. ---> -1. 用户发送命令删除 Pod，使用的是默认的宽限期（30秒） -1. API 服务器中的 Pod 会随着宽限期规定的时间进行更新，过了这个时间 Pod 就会被认为已 "死亡"。 -1. 当使用客户端命令查询 Pod 状态时，Pod 显示为 "Terminating"。 -1. （和第 3 步同步进行）当 Kubelet 看到 Pod 由于步骤 2 中设置的时间而被标记为 terminating 状态时，它就开始执行关闭 Pod 流程。 - 1. 如果 Pod 定义了 [preStop 钩子](/docs/concepts/containers/container-lifecycle-hooks/#hook-details)，就在 Pod 内部调用它。如果宽限期结束了，但是 `preStop` 钩子还在运行，那么就用小的（2 秒）扩展宽限期调用步骤 2。 - 1. 给 Pod 内的进程发送 TERM 信号。请注意，并不是所有 Pod 中的容器都会同时收到 TERM 信号，如果它们关闭的顺序很重要，则每个容器可能都需要一个 `preStop` 钩子。 -1. （和第 3 步同步进行）从服务的端点列表中删除 Pod，Pod 也不再被视为副本控制器的运行状态的 Pod 集的一部分。因为负载均衡器（如服务代理）会将其从轮换中删除，所以缓慢关闭的 Pod 无法继续为流量提供服务。 -1. 当宽限期到期时，仍在 Pod 中运行的所有进程都会被 SIGKILL 信号杀死。 -1. kubelet 将通过设置宽限期为 0 （立即删除）来完成在 API 服务器上删除 Pod 的操作。该 Pod 从 API 服务器中消失，并且在客户端中不再可见。 - - -<!-- -By default, all deletes are graceful within 30 seconds. The `kubectl delete` command supports the `--grace-period=<seconds>` option which allows a user to override the default and specify their own value. The value `0` [force deletes](/docs/concepts/workloads/pods/pod/#force-deletion-of-pods) the Pod. -You must specify an additional flag `--force` along with `--grace-period=0` in order to perform force deletions. ---> -默认情况下，所有删除操作宽限期是 30 秒。`kubectl delete` 命令支持 `--grace-period=<seconds>` 选项，允许用户覆盖默认值并声明他们自己的宽限期。设置为 `0` 会[强制删除](/docs/concepts/workloads/pods/pod/#force-deletion-of-pods) Pod。您必须指定一个附加标志 `--force` 和 `--grace-period=0` 才能执行强制删除操作。 - -<!-- -### Force deletion of pods ---> -### Pod 的强制删除 - -<!-- -Force deletion of a Pod is defined as deletion of a Pod from the cluster state and etcd immediately. When a force deletion is performed, the API server does not wait for confirmation from the kubelet that the Pod has been terminated on the node it was running on. It removes the Pod in the API immediately so a new Pod can be created with the same name. On the node, Pods that are set to terminate immediately will still be given a small grace period before being force killed. ---> -强制删除 Pod 被定义为从集群状态与 etcd 中立即删除 Pod。当执行强制删除时，API 服务器并不会等待 kubelet 的确认信息，该 Pod 已在所运行的节点上被终止了。强制执行删除操作会从 API 服务器中立即清除 Pod， 因此可以用相同的名称创建一个新的 Pod。在节点上，设置为立即终止的 Pod 还是会在被强制删除前设置一个小的宽限期。 - -<!-- -Force deletions can be potentially dangerous for some Pods and should be performed with caution. In case of StatefulSet Pods, please refer to the task documentation for [deleting Pods from a StatefulSet](/docs/tasks/run-application/force-delete-stateful-set-pod/). ---> -强制删除对某些 Pod 可能具有潜在危险，因此应该谨慎地执行。对于 StatefulSet 管理的 Pod，请参考 [从 StatefulSet 中删除 Pod](/docs/tasks/run-application/force-delete-stateful-set-pod/) 的任务文档。 - -<!-- -## Privileged mode for pod containers ---> -## Pod 容器的特权模式 - -<!-- -Any container in a Pod can enable privileged mode, using the `privileged` flag on the [security context](/docs/tasks/configure-pod-container/security-context/) of the container spec. This is useful for containers that want to use Linux capabilities like manipulating the network stack and accessing devices. Processes within the container get almost the same privileges that are available to processes outside a container. With privileged mode, it should be easier to write network and volume plugins as separate Pods that don't need to be compiled into the kubelet. ---> -Pod 中的任何容器都可以使用容器规范 [security context](/docs/tasks/configure-pod-container/security-context/) 上的 `privileged` 参数启用特权模式。这对于想要使用 Linux 功能（如操纵网络堆栈和访问设备）的容器很有用。容器内的进程几乎可以获得与容器外的进程相同的特权。使用特权模式，将网络和卷插件编写为不需要编译到 kubelet 中的独立的 Pod 应该更容易。 - -<!-- -Your container runtime must support the concept of a privileged container for this setting to be relevant. ---> - -{{< note >}} -您的容器运行时必须支持特权容器模式才能使用此设置。 -{{< /note >}} - -<!-- -## API Object ---> -## API 对象 - -<!-- -Pod is a top-level resource in the Kubernetes REST API. -The [Pod API object](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#pod-v1-core) definition -describes the object in detail. ---> -Pod 是 Kubernetes REST API 中的顶级资源。 -[Pod API 对象](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#pod-v1-core)定义详细描述了该 Pod 对象。 - - diff --git a/content/zh/docs/concepts/workloads/pods/podpreset.md b/content/zh/docs/concepts/workloads/pods/podpreset.md index 69b052b868..f4e0f85675 100644 --- a/content/zh/docs/concepts/workloads/pods/podpreset.md +++ b/content/zh/docs/concepts/workloads/pods/podpreset.md @@ -5,13 +5,9 @@ weight: 50 --- <!-- ---- -reviewers: -- jessfraz title: Pod Preset content_type: concept weight: 50 ---- --> <!-- @@ -20,9 +16,10 @@ certain information into pods at creation time. The information can include secrets, volumes, volume mounts, and environment variables. --> <!-- overview --> -本文提供了 PodPreset 的概述。 在 Pod 创建时，用户可以使用 PodPreset 对象将特定信息注入 Pod 中，这些信息可以包括 secret、 卷、卷挂载和环境变量。 +{{< feature-state for_k8s_version="v1.6" state="alpha" >}} +本文提供了 PodPreset 的概述。 在 Pod 创建时，用户可以使用 PodPreset 对象将特定信息注入 Pod 中，这些信息可以包括 Secret、卷、卷挂载和环境变量。 <!-- body --> @@ -38,7 +35,8 @@ You use [label selectors](/docs/concepts/overview/working-with-objects/labels/#l to specify the Pods to which a given Pod Preset applies. --> `Pod Preset` 是一种 API 资源，在 Pod 创建时，用户可以用它将额外的运行时需求信息注入 Pod。 -使用[标签选择器（label selector）](/docs/concepts/overview/working-with-objects/labels/#label-selectors)来指定 Pod Preset 所适用的 Pod。 +使用[标签选择算符](/zh/docs/concepts/overview/working-with-objects/labels/#label-selectors) +来指定 Pod Preset 所适用的 Pod。 <!-- Using a Pod Preset allows pod template authors to not have to explicitly provide @@ -50,10 +48,39 @@ specific service do not need to know all the details about that service. 这样，使用特定服务的 Pod 模板编写者不需要了解该服务的所有细节。 <!-- -For more information about the background, see the [design proposal for PodPreset](https://git.k8s.io/community/contributors/design-proposals/service-catalog/pod-preset.md). ---> +## Enable PodPreset in your cluster {#enable-pod-preset} -了解更多的相关背景信息，请参考 [ PodPreset 设计提案](https://git.k8s.io/community/contributors/design-proposals/service-catalog/pod-preset.md)。 +In order to use Pod Presets in your cluster you must ensure the following: +--> +## 在你的集群中启用 Pod Preset {#enable-pod-preset} + +为了在集群中使用 Pod Preset，必须确保以下几点： + +<!-- +1. You have enabled the API type `settings.k8s.io/v1alpha1/podpreset`. For + example, this can be done by including `settings.k8s.io/v1alpha1=true` in + the `--runtime-config` option for the API server. In minikube add this flag + `--extra-config=apiserver.runtime-config=settings.k8s.io/v1alpha1=true` while + starting the cluster. +1. You have enabled the admission controller `PodPreset`. One way to doing this + is to include `PodPreset` in the `--enable-admission-plugins` option value specified + for the API server. In minikube add this flag + + ```shell + --extra-config=apiserver.enable-admission-plugins=NamespaceLifecycle,LimitRanger,ServiceAccount,DefaultStorageClass,DefaultTolerationSeconds,NodeRestriction,MutatingAdmissionWebhook,ValidatingAdmissionWebhook,ResourceQuota,PodPreset + ``` + + while starting the cluster. +--> +1. 已启用 API 类型 `settings.k8s.io/v1alpha1/podpreset`。 例如，这可以通过在 API 服务器的 `--runtime-config` + 配置项中包含 `settings.k8s.io/v1alpha1=true` 来实现。 + 在 minikube 部署的集群中，启动集群时添加此参数 `--extra-config=apiserver.runtime-config=settings.k8s.io/v1alpha1=true`。 +1. 已启用准入控制器 `PodPreset`。 启用的一种方式是在 API 服务器的 `--enable-admission-plugins` + 配置项中包含 `PodPreset` 。在 minikube 部署的集群中，启动集群时添加以下参数： + + ```shell + --extra-config=apiserver.enable-admission-plugins=NamespaceLifecycle,LimitRanger,ServiceAccount,DefaultStorageClass,DefaultTolerationSeconds,NodeRestriction,MutatingAdmissionWebhook,ValidatingAdmissionWebhook,ResourceQuota,PodPreset + ``` <!-- ## How It Works @@ -62,7 +89,6 @@ Kubernetes provides an admission controller (`PodPreset`) which, when enabled, applies Pod Presets to incoming pod creation requests. When a pod creation request occurs, the system does the following: --> - ## PodPreset 如何工作 Kubernetes 提供了准入控制器 (`PodPreset`)，该控制器被启用时，会将 Pod Preset @@ -87,7 +113,7 @@ Kubernetes 提供了准入控制器 (`PodPreset`)，该控制器被启用时， 1. 尝试合并 `PodPreset` 中定义的各种资源，并注入要创建的 Pod。 1. 发生错误时抛出事件，该事件记录了 pod 信息合并错误，同时在 _不注入_ `PodPreset` 信息的情况下创建 Pod。 1. 为改动的 Pod spec 添加注解，来表明它被 `PodPreset` 所修改。 注解形如： -`podpreset.admission.kubernetes.io/podpreset-<pod-preset name>": "<resource version>"`。 + `podpreset.admission.kubernetes.io/podpreset-<pod-preset 名称>": "<资源版本>"`。 <!-- Each Pod can be matched by zero or more Pod Presets; and each `PodPreset` can be @@ -100,77 +126,37 @@ the Pod; for changes to `Volume`, Kubernetes modifies the Pod Spec. 一个 Pod 可能不与任何 Pod Preset 匹配，也可能匹配多个 Pod Preset。 同时，一个 `PodPreset` 可能不应用于任何 Pod，也可能应用于多个 Pod。 当 `PodPreset` 应用于一个或多个 Pod 时，Kubernetes 修改 pod spec。 对于 `Env`、 `EnvFrom` 和 `VolumeMounts` 的改动， Kubernetes 修改 pod -中所有容器的规格，对于卷的改动，Kubernetes 修改 Pod spec。 +中所有容器的规格，对于卷的改动，Kubernetes 会修改 Pod 规约。 <!-- A Pod Preset is capable of modifying the following fields in a Pod spec when appropriate: - The `.spec.containers` field. -- The `initContainers` field (requires Kubernetes version 1.14.0 or later). +- The `initContainers` field --> {{< note >}} 适当时候，Pod Preset 可以修改 Pod 规范中的以下字段： - `.spec.containers` 字段 -- `initContainers` 字段 (需要 Kubernetes 1.14.0 或更高版本)。 +- `initContainers` 字段 {{< /note >}} <!-- ### Disable Pod Preset for a Specific Pod ---> -### 为特定 Pod 禁用 Pod Preset -<!-- There may be instances where you wish for a Pod to not be altered by any Pod Preset mutations. In these cases, you can add an annotation in the Pod Spec of the form: `podpreset.admission.kubernetes.io/exclude: "true"`. --> -在一些情况下，用户不希望 Pod 被 Pod Preset 所改动，这时，用户可以在 Pod spec 中添加形如 `podpreset.admission.kubernetes.io/exclude: "true"` 的注解。 - -<!-- -## Enable Pod Preset ---> -## 启用 Pod Preset - -<!-- -In order to use Pod Presets in your cluster you must ensure the following: ---> -为了在集群中使用 Pod Preset，必须确保以下几点： - -<!-- -1. You have enabled the API type `settings.k8s.io/v1alpha1/podpreset`. For - example, this can be done by including `settings.k8s.io/v1alpha1=true` in - the `--runtime-config` option for the API server. In minikube add this flag - `--extra-config=apiserver.runtime-config=settings.k8s.io/v1alpha1=true` while - starting the cluster. -1. You have enabled the admission controller `PodPreset`. One way to doing this - is to include `PodPreset` in the `--enable-admission-plugins` option value specified - for the API server. In minikube add this flag - - ```shell - --extra-config=apiserver.enable-admission-plugins=NamespaceLifecycle,LimitRanger,ServiceAccount,DefaultStorageClass,DefaultTolerationSeconds,NodeRestriction,MutatingAdmissionWebhook,ValidatingAdmissionWebhook,ResourceQuota,PodPreset - ``` - - while starting the cluster. -1. You have defined your Pod Presets by creating `PodPreset` objects in the - namespace you will use. ---> - -1. 已启用 API 类型 `settings.k8s.io/v1alpha1/podpreset`。 例如，这可以通过在 API 服务器的 `--runtime-config` 配置项中包含 `settings.k8s.io/v1alpha1=true` 来实现。在 minikube 部署的集群中，启动集群时添加此参数 `--extra-config=apiserver.runtime-config=settings.k8s.io/v1alpha1=true`。 -1. 已启用准入控制器 `PodPreset`。 启用的一种方式是在 API 服务器的 `--enable-admission-plugins` 配置项中包含 `PodPreset` 。在 minikube 部署的集群中，启动集群时添加以下参数： - - ```shell - --extra-config=apiserver.enable-admission-plugins=NamespaceLifecycle,LimitRanger,ServiceAccount,DefaultStorageClass,DefaultTolerationSeconds,NodeRestriction,MutatingAdmissionWebhook,ValidatingAdmissionWebhook,ResourceQuota,PodPreset - ``` - -1. 已经通过在相应的命名空间中创建 `PodPreset` 对象，定义了 Pod Preset。 - - +### 为特定 Pod 禁用 Pod Preset +在一些情况下，用户不希望 Pod 被 Pod Preset 所改动，这时，用户可以在 Pod +的 `.spec` 中添加形如 `podpreset.admission.kubernetes.io/exclude: "true"` 的注解。 ## {{% heading "whatsnext" %}} <!-- * [Injecting data into a Pod using PodPreset](/docs/tasks/inject-data-application/podpreset/) +* For more information about the background, see the [design proposal for PodPreset](https://git.k8s.io/community/contributors/design-proposals/service-catalog/pod-preset.md). --> -* [使用 PodPreset 将信息注入 Pod](/docs/tasks/inject-data-application/podpreset/) - +* 参考[使用 PodPreset 将信息注入 Pod](/zh/docs/tasks/inject-data-application/podpreset/)。 +* 若要更多地了解背景知识，请参阅 [PodPreset 的设计提案](https://git.k8s.io/community/contributors/design-proposals/service-catalog/pod-preset.md)。 diff --git a/content/zh/docs/contribute/_index.md b/content/zh/docs/contribute/_index.md index d826160593..0acea1e84a 100644 --- a/content/zh/docs/contribute/_index.md +++ b/content/zh/docs/contribute/_index.md @@ -1,191 +1,9 @@ --- -content_type: concept -title: 为 Kubernetes 文档做贡献 -linktitle: 贡献 -main_menu: true -weight: 80 +title: 贡献新内容 +weight: 20 --- <!-- ---- -content_type: concept -title: Contribute to Kubernetes docs -linktitle: Contribute -main_menu: true -weight: 80 ---- +title: Contributing new content +weight: 20 --> - -<!-- overview --> - -<!-- -If you would like to help contribute to the Kubernetes documentation or website, -we're happy to have your help! Anyone can contribute, whether you're new to the -project or you've been around a long time, and whether you self-identify as a -developer, an end user, or someone who just can't stand seeing typos. ---> - -如果你想帮助对 Kubernetes 文档或网站做出贡献，我们很高兴得到你的帮助！ -任何人都可以做出贡献，无论你刚参与项目还是参与了很长时间，无论你是开发人员还是用户，或是无法忍受看到拼写错误的人。 - -<!-- -For more ways to get involved in the Kubernetes community or to learn about us, -also visit the [Kubernetes community site](/community/). ---> - -更多途径参与 Kubernetes 社区或了解我们，请访问 [Kubernetes 社区网站](/community/)。 - -<!-- -Looking for the [style guide](/docs/contribute/style/style-guide/) or the -[Kubernetes Community site](/community/)? ---> - -查找 [样式指南](/docs/contribute/style/style-guide/) 或者 [Kubernetes 社区网站](/community/)？ - - - -<!-- body --> - -<!-- -## Types of contributor ---> - -## 贡献者类型 - -<!-- -- A _member_ of the Kubernetes organization has [signed the CLA](/docs/contribute/start#sign-the-cla) - and contributed some time and effort to the project. See - [Community membership](https://github.com/kubernetes/community/blob/master/community-membership.md) - for specific criteria for membership. ---> - -- [签署了 CLA](/docs/contribute/start#sign-the-cla)并为项目贡献了时间和精力的 Kubernetes 组织的_成员_。 - 参见 [社区成员](https://github.com/kubernetes/community/blob/master/community-membership.md) 中对于成员资格的具体标准。 - -<!-- -- A SIG Docs _reviewer_ is a member of the Kubernetes organization who has - expressed interest in reviewing documentation pull requests and who has been - added to the appropriate Github group and `OWNERS` files in the Github - repository, by a SIG Docs Approver. ---> - -- SIG Docs 的_评审者_是对评审文档 PR 感兴趣，并被 SIG Docs 审批者添加到 Github 群组并在 Github 仓库中 `OWNERS` 文件的 Kubernetes 组织的成员。 - -<!-- -- A SIG Docs _approver_ is a member in good standing who has shown a continued - commitment to the project and is granted the ability to merge pull requests - and thus to publish content on behalf of the Kubernetes organization. - Approvers can also represent SIG Docs in the larger Kubernetes community. - Some of the duties of a SIG Docs approver, such as coordinating a release, - require a significant time commitment. ---> - -- SIG Docs 的_审批者_是对项目持续贡献，并被授予合并 PR 权限和代表 Kubernetes 组织发布内容的成员。 - 批准人也可以在更广泛的 Kubernetes 社区中代表 SIG Docs 团队。 - SIG Docs审批者的一些职责，如协调发布版本，需要大量的时间投入。 - -<!-- -## Ways to contribute ---> - -## 贡献途径 - -<!-- -This list is divided into things anyone can do, things Kubernetes organization -members can do, and things that require a higher level of access and familiarity -with SIG Docs processes. Contributing consistently over time can help you -understand some of the tooling and organizational decisions that have already -been made. ---> - -以下列表将工作分成了：任何人都可以做的工作、Kubernetes 组织成员可以做的工作，和熟悉 SIG Docs 流程并且有更高访问权限才能做的工作。 -持续的贡献可以帮助你理解已有的工具和组织决策。 - -<!-- -This is not an exhaustive list of ways you can contribute to the Kubernetes -documentation, but it should help you get started. ---> - -你对 Kubernetes 文档可以做出的贡献不仅限于列表列出的条目，但它可以帮助你开动起来。 - -<!-- -- [Anyone](/docs/contribute/start/) - - File actionable bugs ---> - -- [任何人](/docs/contribute/start/) - - 登记记录可修正的错误 - -<!-- -- [Member](/docs/contribute/start/) - - Improve existing docs - - Bring up ideas for improvement on Slack or SIG docs mailing list - - Improve docs accessibility - - Provide non-binding feedback on PRs - - Write a blog post or case study ---> - -- [成员](/docs/contribute/start/) - - 完善已有文档 - - 在 Slack 或 SIG Docs 邮件列表中提出改进意见 - - 提升文档的易用性 - - 对 PR 提出无约束的反馈 - - 编写博文和案例分析 - -<!-- -- [Reviewer](/docs/contribute/intermediate/) - - Document new features - - Triage and categorize issues - - Review PRs - - Create diagrams, graphics assets, and embeddable screencasts / videos - - Localization - - Contribute to other repos as a docs representative - - Edit user-facing strings in code - - Improve code comments, Godoc ---> - -- [评审者](/docs/contribute/intermediate/) - - 为新功能特性编写文档 - - 对 issue 进行筛选和分类 - - 评审 PR - - 创建图表、图形分析和嵌入式的屏幕/视频 - - 本地化 - - 作为 docs 小组的代表为其他项目仓库做贡献 - - 在代码中编辑面向用户的字符串 - - 改进代码注释和 Godoc - -<!-- -- [Approver](/docs/contribute/advanced/) - - Publish contributor content by approving and merging PRs - - Participate in a Kubernetes release team as a docs representative - - Propose improvements to the style guide - - Propose improvements to docs tests - - Propose improvements to the Kubernetes website or other tooling ---> - -- [审批者](/docs/contribute/advanced/) - - 通过批准和合并 PR 发布贡献成果 - - 作为 docs 团队的代表参与 Kubernetes 发布团队 - - 对样式指南提出改进建议 - - 对文档测试提出改进建议 - - 对 Kubernetes 网站或其他工具提出改进建议 - -<!-- -## Additional ways to contribute ---> - -## 其他贡献途径 - -<!-- -- To contribute to the Kubernetes community through online forums like Twitter or Stack Overflow, or learn about local meetups and Kubernetes events, visit the [Kubernetes community site](/community/). ---> - -- 如果您要通过 Twitter 或 Stack Overflow 等在线论坛为社区做贡献，或了解本地会议及 Kubernetes 事件，请查看 [Kubernetes 社区网站](/community/). - -<!-- -- To contribute to feature development, read the [contributor cheatsheet](https://github.com/kubernetes/community/tree/master/contributors/guide/contributor-cheatsheet) to get started. ---> - -- 如果您要开发新的特性，请阅读 [contributor cheatsheet](https://github.com/kubernetes/community/tree/master/contributors/guide/contributor-cheatsheet). - - diff --git a/content/zh/docs/contribute/advanced.md b/content/zh/docs/contribute/advanced.md index a01c6c632d..f3b3aab9af 100644 --- a/content/zh/docs/contribute/advanced.md +++ b/content/zh/docs/contribute/advanced.md @@ -2,166 +2,44 @@ title: 高级贡献 slug: advanced content_type: concept -weight: 30 +weight: 98 --- <!-- ---- title: Advanced contributing slug: advanced content_type: concept -weight: 30 ---- +weight: 98 --> <!-- overview --> <!-- -This page assumes that you've read and mastered the -[Start contributing](/docs/contribute/start/) and -[Intermediate contributing](/docs/contribute/intermediate/) topics and are ready +This page assumes that you understand how to +[contribute to new content](/docs/contribute/new-content/overview) and +[review others' work](/docs/contribute/review/reviewing-prs/), and are ready to learn about more ways to contribute. You need to use the Git command line client and other tools for some of these tasks. --> -如果你已经阅读并掌握[开始贡献](/docs/contribute/start/)和[中级贡献](/docs/contribute/intermediate/)，并准备了解更多贡献的途径，请阅读此文。您需要使用 Git 命令行工具和其他工具做这些工作。 - +如果你已经了解如何[贡献新内容](/zh/docs/contribute/new-content/overview/)和 +[评阅他人工作](/zh/docs/contribute/review/reviewing-prs/)，并准备了解更多贡献的途径， +请阅读此文。您需要使用 Git 命令行工具和其他工具做这些工作。 <!-- body --> -<!-- -## Be the PR Wrangler for a week ---> -## 做一周的 PR 管理者 - -<!-- -SIG Docs [approvers](/docs/contribute/participating/#approvers) take regular turns as the PR wrangler for the repository and are added to the [PR Wrangler rotation scheduler](https://github.com/kubernetes/website/wiki/PR-Wranglers#2019-schedule-q1q2) for weekly rotations. ---> -SIG Docs 的 [approvers](/docs/contribute/participating/#approvers) 可以成为 PR 管理者。SIG Docs approvers 会每周轮换地加入到 [PR 管理者轮换日程](https://github.com/kubernetes/website/wiki/PR-Wranglers#2019-schedule-q1q2)中。 - -<!-- -The PR wrangler’s duties include: ---> -PR 管理者的工作职责包括： - -<!-- -- Review [open pull requests](https://github.com/kubernetes/website/pulls) daily for quality and adherence to the [style guide](/docs/contribute/style/style-guide/). - - Review the smallest PRs (`size/XS`) first, then iterate towards the largest (`size/XXL`). - - Review as many PRs as you can. -- Ensure that the CLA is signed by each contributor. - - Help new contributors sign the [CLA](https://github.com/kubernetes/community/blob/master/CLA.md). - - Use [this](https://github.com/zparnold/k8s-docs-pr-botherer) script to automatically remind contributors that haven’t signed the CLA to sign the CLA. -- Provide feedback on proposed changes and help facilitate technical reviews from members of other SIGs. - - Provide inline suggestions on the PR for the proposed content changes. - - If you need to verify content, comment on the PR and request more details. - - Assign relevant `sig/` label(s). - - If needed, assign reviewers from the `reviewers:` block in the file's front matter. - - Assign `Docs Review` and `Tech Review` labels to indicate the PR's review status. - - Assign `Needs Doc Review` or `Needs Tech Review` for PRs that haven't yet been reviewed. - - Assign `Doc Review: Open Issues` or `Tech Review: Open Issues` for PRs that have been reviewed and require further input or action before merging. - - Assign `/lgtm` and `/approve` labels to PRs that can be merged. -- Merge PRs when they are ready, or close PRs that shouldn’t be accepted. -- Triage and tag incoming issues daily. See [Intermediate contributing](/docs/contribute/intermediate/) for guidelines on how SIG Docs uses metadata. ---> -- 每天检查[悬决的 PR](https://github.com/kubernetes/website/pulls) 的质量并确保它们遵守[风格指南]](/docs/contribute/style/style-guide/)。 - - 首先查看最小的 PR（`size/XS`），然后逐渐扩展到最大的 PR（`size/XXL`）。 - - 尽可能多地审阅 PR。 -- 确保每个贡献者完成 CLA 签署。 - - 指导新的贡献者签署 [CLA](https://github.com/kubernetes/community/blob/master/CLA.md)。 - - 使用[此脚本](https://github.com/zparnold/k8s-docs-pr-botherer)自动提醒尚未签署 CLA 的贡献者签署 CLA。 -- 针对所建议的更改提供反馈，并帮助协调其他 SIG 成员进行技术审核。 - - 为 PR 所建议的内容更改提供在线反馈。 - - 如果您需要验证内容，请在 PR 上发表评论并要求贡献者提供更多细节。 - - 设置相关的 `sig/` 标签。 - - 如果需要，请从文件开头的 `reviewers:` 块中指定审阅者。 - - 设置 `Docs Review` 和 `Tech Review` 标签以标示 PR 的审阅状态。 - - 为尚未审阅的 PR 设置 `Needs Doc Review` 或者 `Needs Tech Review` 标签。 - - 为已审阅的但在合并前需要更多信息的或采取措施的 PR 设置 `Doc Review: Open Issues` 或者 `Tech Review: Open Issues` 标签。 - - 为可以合并的 PR 添加 `/lgtm` 和 `/approve` 标签。 -- 合并已经就绪的，或关闭不应该接受的 PR。 -- 每天对新增的 issues 进行分类和标记。有关 SIG 文档如何使用 metadata 的准则，请参见[中级贡献](/docs/contribute/intermediate/)。 - -<!-- -### Helpful GitHub queries for wranglers - -The following queries are helpful when wrangling. After working through these three queries, the remaining list of PRs to be -reviewed is usually small. These queries specifically exclude localization PRs, and only include the `master` branch (except for the last one). ---> -### 对于负责人有用的 GitHub 查询 - -执行管理操作时，以下查询很有用。完成以下三个查询后，剩余的要审阅的 PR 列表通常很小。 - -<!-- -- [No CLA, not eligible to merge](https://github.com/kubernetes/website/pulls?q=is%3Aopen+is%3Apr+label%3A%22cncf-cla%3A+no%22+-label%3Ado-not-merge+label%3Alanguage%2Fen): - Remind the contributor to sign the CLA. If they have already been reminded by both the bot and a human, close - the PR and remind them that they can open it after signing the CLA. - **Do not review PRs whose authors have not signed the CLA!** -- [Needs LGTM](https://github.com/kubernetes/website/pulls?utf8=%E2%9C%93&q=is%3Aopen+is%3Apr+-label%3Ado-not-merge+label%3Alanguage%2Fen+-label%3Algtm+): - If it needs technical review, loop in one of the reviewers suggested by the bot. If it needs docs review - or copy-editing, either suggest changes or add a copyedit commit to the PR to move it along. -- [Has LGTM, needs docs approval](https://github.com/kubernetes/website/pulls?q=is%3Aopen+is%3Apr+-label%3Ado-not-merge+label%3Alanguage%2Fen+label%3Algtm): - Determine whether any additional changes or updates need to be made for the PR to be merged. If you think the PR is ready to be merged, comment `/approve`. -- [Not against master](https://github.com/kubernetes/website/pulls?utf8=%E2%9C%93&q=is%3Aopen+is%3Apr+-label%3Ado-not-merge+label%3Alanguage%2Fen+-base%3Amaster): If it's against a `dev-` branch, it's for an upcoming release. Make sure the [release meister](https://github.com/kubernetes/sig-release/tree/master/release-team) knows about it by adding a comment with `/assign @<meister's_github-username>`. If it's against an old branch, help the PR author figure out whether it's targeted against the best branch. ---> -- [没有签署 CLA, 不能 merge](https://github.com/kubernetes/website/pulls?q=is%3Aopen+is%3Apr+label%3A%22cncf-cla%3A+no%22+-label%3Ado-not-merge+label%3Alanguage%2Fen): - 提醒贡献者签署 CLA。如果机器人和审阅者都已经提醒他们，请关闭 PR，并提醒他们在签署 CLA 后可以重新提交。 - **在作者没有签署 CLA 之前，不要审阅他们的 PR！** -- [需要 LGTM](https://github.com/kubernetes/website/pulls?utf8=%E2%9C%93&q=is%3Aopen+is%3Apr+-label%3Ado-not-merge+label%3Alanguage%2Fen+-label%3Algtm+): - 如果需要技术审查，请告知机器人所建议的审阅者。如果 PR 需要文档审查或复制编辑，提交更改建议或向 PR 提交一个 copyedit 以使之进入下一步。 -- [有 LGTM ，需要批准](https://github.com/kubernetes/website/pulls?q=is%3Aopen+is%3Apr+-label%3Ado-not-merge+label%3Alanguage%2Fen+label%3Algtm): - 确定 PR 是否需要进行其他更改或更新才能合并。如果您认为 PR 已准备好合并，请输入 `/approve`。 -- [非 master 分支的 PR](https://github.com/kubernetes/website/pulls?utf8=%E2%9C%93&q=is%3Aopen+is%3Apr+-label%3Ado-not-merge+label%3Alanguage%2Fen+-base%3Amaster)： - 如果 PR 针对 `dev-` 分支，则表示它适用于即将发布的版本。请添加带有 `/assign @<负责人的 github 账号>` 的注释，确保[发行版本负责人](https://github.com/kubernetes/sig-release/tree/master/release-team)注意到该 PR。如果 PR 是针对旧分支，请帮助 PR 作者确定是否所针对的是最合适的分支。 - -<!-- -### When to close Pull Requests - -Reviews and approvals are one tool to keep our PR queue short and current. Another tool is closure. ---> -### 什么时候关闭 PR - -审查和批准是缩短和更新我们的 PR 队列的一种方式；另一种方式是关闭 PR。 - -<!-- -- Close any PR where the CLA hasn’t been signed for two weeks. -PR authors can reopen the PR after signing the CLA, so this is a low-risk way to make sure nothing gets merged without a signed CLA. - -- Close any PR where the author has not responded to comments or feedback in 2 or more weeks. - -Don't be afraid to close pull requests. Contributors can easily reopen and resume works in progress. Oftentimes a closure notice is what spurs an author to resume and finish their contribution. - -To close a pull request, leave a `/close` comment on the PR. ---> -- 关闭两个星期未签署 CLA 的 PR。 -PR 作者可以在签署 CLA 后重新打开 PR，因此这是确保未签署 CLA 的 PR 不会被合并的一种风险较低的方法。 - -- 如果作者在两周或更长时间内未回复评论或反馈，请关闭 PR。 - -不要害怕关闭 PR。贡献者可以轻松地重新打开并继续工作。通常，关闭通知会激励作者继续完成其贡献。 - -要关闭 PR，请在 PR 上输入 `/close`。 - -{{< note >}} - -<!-- -An automated service, [`fejta-bot`](https://github.com/fejta-bot) automatically marks issues as stale after 90 days of inactivity, then closes them after an additional 30 days of inactivity when they become rotten. PR wranglers should close issues after 14-30 days of inactivity. ---> -一项名为 [`fejta-bot`](https://github.com/fejta-bot) 的自动服务会在 issues 停滞 90 天后会自动将其标记为过期；然后再等 30 天，如果仍然无人过问，则将其关闭。PR 管理者应该在 issues 处于无人过问状态 14-30 天后关闭它们。 - -{{< /note >}} - <!-- ## Propose improvements -SIG Docs -[members](/docs/contribute/participating/#members) can propose improvements. +SIG Docs [members](/docs/contribute/participate/roles-and-responsibilities/#members) can propose improvements. --> ## 提出改进建议 -SIG Docs 的 [成员](/docs/contribute/participating/#members) 可以提出改进建议。 +SIG Docs 的 [成员](/zh/docs/contribute/participate/roles-and-responsibilities/#members) 可以提出改进建议。 <!-- After you've been contributing to the Kubernetes documentation for a while, you -may have ideas for improvement to the style guide, the toolchain used to build +may have ideas for improving the [Style Guide](/docs/contribute/style/style-guide/) +, the [Content Guide](/docs/contribute/style/content-guide/), the toolchain used to build the documentation, the website style, the processes for reviewing and merging pull requests, or other aspects of the documentation. For maximum transparency, these types of proposals need to be discussed in a SIG Docs meeting or on the @@ -172,7 +50,14 @@ changes. The quickest way to get answers to questions about how the documentatio currently works is to ask in the `#sig-docs` Slack channel on [kubernetes.slack.com](https://kubernetes.slack.com) --> -在对 Kubernetes 文档贡献了一段时间后，你可能会对样式指南、用于构建文档的工具链、网页样式、评审和合入 PR 的流程，或者文档的其他方面产生改进的想法。为了尽可能透明化，这些提议都需要在 SIG Docs 会议或 [kubernetes-sig-docs 邮件列表](https://groups.google.com/forum/#!forum/kubernetes-sig-docs)上讨论。此外，在提出全面的改进之前，它能真正帮助我们了解有关“当前工作如何运作”和“以往的决定是为何做出”的背景。想了解文档的当前运作方式，最快的途径是咨询 [kubernetes.slack.com](https://kubernetes.slack.com) 中的 `#sig-docs` 聊天群组。 +在对 Kubernetes 文档贡献了一段时间后，你可能会对[样式指南](/zh/docs/contribute/style/style-guide/)、 +[内容指南](/zh/docs/contribute/style/content-guide/)、用于构建文档的工具链、网站样式、 +评审和合并 PR 的流程或者文档的其他方面产生改进的想法。 +为了尽可能透明化，这些提议都需要在 SIG Docs 会议或 +[kubernetes-sig-docs 邮件列表](https://groups.google.com/forum/#!forum/kubernetes-sig-docs)上讨论。 +此外，在提出全面的改进之前，这些讨论能真正帮助我们了解有关“当前工作如何运作”和“以往的决定是为何做出”的背景。 +想了解文档的当前运作方式，最快的途径是咨询 [kubernetes.slack.com](https://kubernetes.slack.com) +中的 `#sig-docs` 聊天群组。 <!-- After the discussion has taken place and the SIG is in agreement about the desired @@ -185,31 +70,31 @@ documentation testing might involve working with sig-testing. <!-- ## Coordinate docs for a Kubernetes release ---> -## 为 Kubernetes 版本发布协调文档 -<!-- SIG Docs [approvers](/docs/contribute/participating/#approvers) can coordinate docs for a Kubernetes release. --> -SIG Docs 的[批准者（approvers）](/docs/contribute/participating/#approvers) 可以为 Kubernetes 版本发布协调文档。 +## 为 Kubernetes 版本发布协调文档工作 + +SIG Docs 的[批准者（approvers）](/zh/docs/contribute/participating/#approvers) 可以为 +Kubernetes 版本发布协调文档工作。 <!-- Each Kubernetes release is coordinated by a team of people participating in the sig-release Special Interest Group (SIG). Others on the release team for a given -release include an overall release lead, as well as representatives from sig-pm, -sig-testing, and others. To find out more about Kubernetes release processes, +release include an overall release lead, as well as representatives from +sig-testing and others. To find out more about Kubernetes release processes, refer to [https://github.com/kubernetes/sig-release](https://github.com/kubernetes/sig-release). --> -每一个 Kubernetes 版本都是由参与 sig-release 的 SIG（特别兴趣小组）的一个团队协调的。指定版本的发布团队中还包括总体发布牵头人，以及来自 sig-pm、sig-testing 的代表等。了解更多关于 Kubernetes 版本发布的流程，请参考 [https://github.com/kubernetes/sig-release](https://github.com/kubernetes/sig-release)。 +每一个 Kubernetes 版本都是由参与 sig-release 的 SIG（特别兴趣小组）的一个团队协调的。 +指定版本的发布团队中还包括总体发布牵头人，以及来自 sig-testing 的代表等。 +要了解更多关于 Kubernetes 版本发布的流程，请参考 +[https://github.com/kubernetes/sig-release](https://github.com/kubernetes/sig-release)。 <!-- The SIG Docs representative for a given release coordinates the following tasks: ---> -SIG Docs 团队的代表需要为一个指定的版本协调以下工作： -<!-- - Monitor the feature-tracking spreadsheet for new or changed features with an impact on documentation. If documentation for a given feature won't be ready for the release, the feature may not be allowed to go into the release. @@ -224,7 +109,11 @@ SIG Docs 团队的代表需要为一个指定的版本协调以下工作： - Publish the documentation changes related to the release when the release artifacts are published. --> -- 通过特性跟踪表来监视新功能特性或现有功能特性的修改。如果版本的某个功能特性的文档没有为发布做好准备，那么该功能特性不允许进入发布版本。 + +SIG Docs 团队的代表需要为一个指定的版本协调以下工作： + +- 通过特性跟踪表来监视新功能特性或现有功能特性的修改。 + 如果版本的某个功能特性的文档没有为发布做好准备，那么该功能特性不允许进入发布版本。 - 定期参加 sig-release 会议并汇报文档的发布状态。 - 评审和修改由负责实现某功能特性的 SIG 起草的功能特性文档。 - 合入版本发布相关的 PR，并为对应发布版本维护 Git 特性分支。 @@ -235,14 +124,11 @@ SIG Docs 团队的代表需要为一个指定的版本协调以下工作： Coordinating a release is typically a 3-4 month commitment, and the duty is rotated among SIG Docs approvers. --> -协调一个版本发布通常需要 3-4 个月的时间投入，该任务由 SIG Docs approvers 轮流承担。 +协调一个版本发布通常需要 3-4 个月的时间投入，该任务由 SIG Docs 批准人轮流承担。 <!-- ## Serve as a New Contributor Ambassador ---> -## 担任新的贡献者大使 -<!-- SIG Docs [approvers](/docs/contribute/participating/#approvers) can serve as New Contributor Ambassadors. @@ -252,9 +138,14 @@ few PR submissions. Responsibilities for New Contributor Ambassadors include: --> -SIG Docs [approvers](/docs/contribute/participating/#approvers) 可以担任新的贡献者大使。 -新的贡献者大使共同努力欢迎 SIG-Docs 的新贡献者，对新贡献者的 PR 提出建议，以及在前几份 PR 提交中指导新贡献者。 +## 担任新的贡献者大使 + +SIG Docs [批准人（Approvers）](/zh/docs/contribute/participating/#approvers) +可以担任新的贡献者大使。 + +新的贡献者大使共同努力欢迎 SIG-Docs 的新贡献者，对新贡献者的 PR 提出建议， +以及在前几份 PR 提交中指导新贡献者。 新的贡献者大使的职责包括： @@ -265,11 +156,11 @@ SIG Docs [approvers](/docs/contribute/participating/#approvers) 可以担任新 - Helping new contributors create the more complex PRs they need to become Kubernetes members. - [Sponsoring contributors](/docs/contribute/advanced/#sponsor-a-new-contributor) on their path to becoming Kubernetes members. --> -- 可在 [Kubernetes #sig-docs 频道](https://kubernetes.slack.com) 上回答新贡献者的问题。 +- 监听 [Kubernetes #sig-docs 频道](https://kubernetes.slack.com) 上新贡献者的 Issue。 - 与 PR 管理者合作为新参与者寻找合适的第一个 issues。 -- 通过前几个 PR 指导新贡献者到文档存储库。 +- 通过前几个 PR 指导新贡献者为文档存储库作贡献。 - 帮助新的贡献者创建成为 Kubernetes 成员所需的更复杂的 PR。 -- [为贡献者提供担保](/docs/contribute/advanced/#sponsor-a-new-contributor)，使其成为 Kubernetes 成员。 +- [为贡献者提供保荐](#sponsor-a-new-contributor)，使其成为 Kubernetes 成员。 <!-- Current New Contributor Ambassadors are announced at each SIG-Docs meeting, and in the [Kubernetes #sig-docs channel](https://kubernetes.slack.com). @@ -278,14 +169,13 @@ Current New Contributor Ambassadors are announced at each SIG-Docs meeting, and <!-- ## Sponsor a new contributor ---> -## 为新的贡献者提供担保 -<!-- SIG Docs [reviewers](/docs/contribute/participating/#reviewers) can sponsor new contributors. --> -SIG Docs 的 [reviewers](/docs/contribute/participating/#reviewers) 可以为新的贡献者提供担保。 +## 为新的贡献者提供保荐 {#sponsor-a-new-contributor} + +SIG Docs 的[评审人（Reviewers）](/zh/docs/contribute/participating/#reviewers) 可以为新的贡献者提供保荐。 <!-- After a new contributor has successfully submitted 5 substantive pull requests @@ -294,7 +184,9 @@ to one or more Kubernetes repositories, they are eligible to apply for organization. The contributor's membership needs to be backed by two sponsors who are already reviewers. --> -新的贡献者针对一个或多个 Kubernetes 项目仓库成功提交了 5 个实质性 PR 之后，就有资格申请 Kubernetes 组织 [成员身份](/docs/contribute/participating#members)。贡献者的成员资格需要同时得到两位 reviewers 的保荐。 +新的贡献者针对一个或多个 Kubernetes 项目仓库成功提交了 5 个实质性 PR 之后， +就有资格申请 Kubernetes 组织的[成员身份](/zh/docs/contribute/participate/roles-and-responsibilities/#members)。 +贡献者的成员资格需要同时得到两位评审人的保荐。 <!-- New docs contributors can request sponsors by asking in the #sig-docs channel @@ -305,7 +197,10 @@ When they submit their membership application, reply to the application with a "+1" and include details about why you think the applicant is a good fit for membership in the Kubernetes organization. --> -新的文档贡献者可以通过咨询 [Kubernetes Slack 实例](https://kubernetes.slack.com) 上的 #sig-docs 频道或者 [SIG Docs 邮件列表](https://groups.google.com/forum/#!forum/kubernetes-sig-docs)来请求评审者保荐。如果你对申请人的工作充满信心，你自愿保荐他们。当他们提交成员资格申请时，回复 “+1” 并详细说明为什么你认为申请人适合加入 Kubernetes 组织。 +新的文档贡献者可以通过咨询 [Kubernetes Slack 实例](https://kubernetes.slack.com) +上的 #sig-docs 频道或者 [SIG Docs 邮件列表](https://groups.google.com/forum/#!forum/kubernetes-sig-docs) +来请求评审者保荐。如果你对申请人的工作充满信心，你自愿保荐他们。 +当他们提交成员资格申请时，回复 “+1” 并详细说明为什么你认为申请人适合加入 Kubernetes 组织。 <!-- ## Serve as a SIG Co-chair @@ -316,7 +211,8 @@ SIG Docs [approvers](/docs/contribute/participating/#approvers) can serve a term --> ## 担任 SIG 联合主席 -SIG Docs [approvers](/docs/contribute/participating/#approvers) 可以担任 SIG Docs 的联合主席。 +SIG Docs [批准人（Approvers）](/zh/docs/contribute/participate/roles-and-responsibilities/#approvers) +可以担任 SIG Docs 的联合主席。 ### 前提条件 @@ -332,9 +228,14 @@ Approvers must meet the following requirements to be a co-chair: Approvers 必须满足以下要求才能成为联合主席： - 已维持 SIG Docs approver 身份至少 6 个月 -- [曾领导 Kubernetes 文档发布](/docs/contribute/advanced/#coordinate-docs-for-a-kubernetes-release) 或者在两个版本发布中有实习经历 +- [曾领导 Kubernetes 文档发布](/zh/docs/contribute/advanced/#coordinate-docs-for-a-kubernetes-release) + 或者在两个版本发布中有实习经历 - 理解 SIG Docs 工作流程和工具：git、Hugo、本地化、博客子项目 -- 理解其他 Kubernetes SIG 和仓库会如何影响 SIG Docs 工作流程，包括：[k/org 中的团队](https://github.com/kubernetes/org/blob/master/config/kubernetes/sig-docs/teams.yaml)、[k/community 中的流程](https://github.com/kubernetes/community/tree/master/sig-docs)、[k/test-infra](https://github.com/kubernetes/test-infra/) 中的插件、[SIG Architecture](https://github.com/kubernetes/community/tree/master/sig-architecture) 中的角色。 +- 理解其他 Kubernetes SIG 和仓库会如何影响 SIG Docs 工作流程，包括： + [k/org 中的团队](https://github.com/kubernetes/org/blob/master/config/kubernetes/sig-docs/teams.yaml)、 + [k/community 中的流程](https://github.com/kubernetes/community/tree/master/sig-docs)、 + [k/test-infra](https://github.com/kubernetes/test-infra/) 中的插件、 + [SIG Architecture](https://github.com/kubernetes/community/tree/master/sig-architecture) 中的角色。 - 在至少 6 个月的时段内，确保每周至少投入 5 个小时（通常更多） <!-- @@ -361,11 +262,13 @@ Responsibilities include: - Keep the SIG running smoothly --> - 保持 SIG Docs 专注于通过出色的文档最大限度地提高开发人员的满意度 -- 以身作则，践行[社区行为准则](https://github.com/cncf/foundation/blob/master/code-of-conduct.md) 并要求 SIG 成员对自身行为负责 -- 通过更新贡献准则，为 SIG 学习并设置最佳实践 +- 以身作则，践行[社区行为准则](https://github.com/cncf/foundation/blob/master/code-of-conduct.md)， + 并要求 SIG 成员对自身行为负责 +- 通过更新贡献指南，为 SIG 学习并设置最佳实践 - 安排和举行 SIG 会议：每周状态更新，每季度回顾/计划会议以及其他需要的会议 - 在 KubeCon 活动和其他会议上安排和负责文档工作 -- 与 {{< glossary_tooltip text="CNCF" term_id="cncf" >}} 及其尊贵合作伙伴（包括 Google、Oracle、Azure、IBM 和华为）一起以 SIG Docs 的身份招募和宣传 +- 与 {{< glossary_tooltip text="CNCF" term_id="cncf" >}} 及其尊贵合作伙伴 + （包括 Google、Oracle、Azure、IBM 和华为）一起以 SIG Docs 的身份招募和宣传 - 负责 SIG 正常运行 <!-- @@ -379,7 +282,7 @@ To schedule and run effective meetings, these guidelines show what to do, how to --> ### 召开高效的会议 -为了安排和召开高效的会议，这些准则说明了如何做、怎样做以及原因。 +为了安排和召开高效的会议，这些指南说明了如何做、怎样做以及原因。 **坚持[社区行为准则](https://github.com/cncf/foundation/blob/master/code-of-conduct.md)**： @@ -470,4 +373,3 @@ The video uploads automatically to YouTube. 视频会自动上传到 YouTube。 - diff --git a/content/zh/docs/contribute/generate-ref-docs/_index.md b/content/zh/docs/contribute/generate-ref-docs/_index.md index ac5f61a40f..fc73d84b29 100644 --- a/content/zh/docs/contribute/generate-ref-docs/_index.md +++ b/content/zh/docs/contribute/generate-ref-docs/_index.md @@ -5,17 +5,22 @@ weight: 80 --- <!-- ---- title: Reference docs overview main_menu: true weight: 80 ---- --> <!-- -Much of the Kubernetes reference documentation is generated from Kubernetes -source code, using scripts. The topics in this section document how to generate -this type of content. +The topics in this section document how to generate the Kubernetes +reference guides. + +To build the reference documentation, see the following guide: + +* [Generating Reference Documentation Quickstart](/docs/contribute/generate-ref-docs/quickstart/) --> -许多 Kubernetes 参考文档都是使用脚本从 Kubernetes 源代码生成的。本节的主题是如何生成这种类型的文档。 +本节的主题是描述如何生成 Kubernetes 参考指南。 +要生成参考文档，请参考下面的指南： + +* [生成参考文档快速入门](/zh/docs/contribute/generate-ref-docs/quickstart/) + diff --git a/content/zh/docs/contribute/generate-ref-docs/contribute-upstream.md b/content/zh/docs/contribute/generate-ref-docs/contribute-upstream.md index f71871b296..cf7b51cbaf 100644 --- a/content/zh/docs/contribute/generate-ref-docs/contribute-upstream.md +++ b/content/zh/docs/contribute/generate-ref-docs/contribute-upstream.md @@ -1,12 +1,12 @@ --- title: 为上游 Kubernetes 代码库做出贡献 content_type: task +weight: 20 --- <!-- ---- title: Contributing to the Upstream Kubernetes Code content_type: task ---- +weight: 20 --> <!-- overview --> @@ -16,93 +16,83 @@ This page shows how to contribute to the upstream kubernetes/kubernetes project to fix bugs found in the Kubernetes API documentation or the `kube-*` components such as `kube-apiserver`, `kube-controller-manager`, etc. --> -此页面描述如何为上游 kubernetes/kubernetes 项目做出贡献，如修复 Kubernetes API 文档或 `kube-*` 组件（例如 kube-apiserver、kube-controller-manager 等）中发现的错误。 +此页面描述如何为上游 `kubernetes/kubernetes` 项目做出贡献，如修复 Kubernetes API +文档或 Kubernetes 组件（例如 `kubeadm`、`kube-apiserver`、`kube-controller-manager` 等） +中发现的错误。 <!-- If you instead want to regenerate the reference documentation for the Kubernetes API or the `kube-*` components from the upstream code, see the following instructions: ---> -相反，如果您想从上游代码重新生成 Kubernetes API 或 `kube-*` 组件的参考文档。请参考以下说明： -<!-- - [Generating Reference Documentation for the Kubernetes API](/docs/contribute/generate-ref-docs/kubernetes-api/) - [Generating Reference Documentation for the Kubernetes Components and Tools](/docs/contribute/generate-ref-docs/kubernetes-components/) --> -- [生成 Kubernetes API 的参考文档](/docs/contribute/generate-ref-docs/kubernetes-api/) -- [生成 Kubernetes 组件和工具的参考文档](/docs/contribute/generate-ref-docs/kubernetes-components/) - - +如果您仅想从上游代码重新生成 Kubernetes API 或 `kube-*` 组件的参考文档。请参考以下说明： +- [生成 Kubernetes API 的参考文档](/zh/docs/contribute/generate-ref-docs/kubernetes-api/) +- [生成 Kubernetes 组件和工具的参考文档](/zh/docs/contribute/generate-ref-docs/kubernetes-components/) ## {{% heading "prerequisites" %}} - <!-- You need to have these tools installed: + - [Git](https://git-scm.com/book/en/v2/Getting-Started-Installing-Git) + - [Golang](https://golang.org/doc/install) version 1.13+ + - [Docker](https://docs.docker.com/engine/installation/) + - [etcd](https://github.com/coreos/etcd/) --> -您需要安装以下工具： +- 你需要安装以下工具： + + - [Git](https://git-scm.com/book/en/v2/Getting-Started-Installing-Git) + - [Golang](https://golang.org/doc/install) 的 1.13 版本或更高 + - [Docker](https://docs.docker.com/engine/installation/) + - [etcd](https://github.com/coreos/etcd/) <!-- -* [Git](https://git-scm.com/book/en/v2/Getting-Started-Installing-Git) -* [Golang](https://golang.org/doc/install) version 1.9.1 or later -* [Docker](https://docs.docker.com/engine/installation/) -* [etcd](https://github.com/coreos/etcd/) +- Your $GOPATH environment variable must be set, and the location of `etcd` + must be in your $PATH environment variable. --> -* [Git](https://git-scm.com/book/en/v2/Getting-Started-Installing-Git) -* [Golang](https://golang.org/doc/install) Go 版本大于 1.9.1 -* [Docker](https://docs.docker.com/engine/installation/) -* [etcd](https://github.com/coreos/etcd/) +- 你必须设置 `GOPATH` 环境变量，并且 `etcd` 的位置必须在 `PATH` 环境变量中。 <!-- -Your $GOPATH environment variable must be set, and the location of `etcd` -must be in your $PATH environment variable. +- You need to know how to create a pull request to a GitHub repository. + Typically, this involves creating a fork of the repository. + For more information, see + [Creating a Pull Request](https://help.github.com/articles/creating-a-pull-request/) and + [GitHub Standard Fork & Pull Request Workflow](https://gist.github.com/Chaser324/ce0505fbed06b947d962). --> -必须设置 $GOPATH 环境变量，并且 `etcd` 的位置必须在 $PATH 环境变量中。 - -<!-- -You need to know how to create a pull request to a GitHub repository. -Typically, this involves creating a fork of the repository. For more -information, see -[Creating a Pull Request](https://help.github.com/articles/creating-a-pull-request/) and -[GitHub Standard Fork & Pull Request Workflow](https://gist.github.com/Chaser324/ce0505fbed06b947d962). ---> -您需要知道如何创建对 GitHub 代码仓库的拉取请求（Pull Request）。 -通常，这涉及创建代码仓库的分支。要获取更多的信息请参考[创建 PR](https://help.github.com/articles/creating-a-pull-request/) 和 -[GitHub 标准 Fork 和 PR 工作流程](https://gist.github.com/Chaser324/ce0505fbed06b947d962)。 - - - - +- 您需要知道如何创建对 GitHub 代码仓库的拉取请求（Pull Request）。 + 通常，这涉及创建代码仓库的派生副本。 + 要获取更多的信息请参考[创建 PR](https://help.github.com/articles/creating-a-pull-request/) 和 + [GitHub 标准派生和 PR 工作流程](https://gist.github.com/Chaser324/ce0505fbed06b947d962)。 <!-- steps --> <!-- ## The big picture ---> -## 基本原则 -<!-- The reference documentation for the Kubernetes API and the `kube-*` components such as `kube-apiserver`, `kube-controller-manager` are automatically generated from the source code in the [upstream Kubernetes](https://github.com/kubernetes/kubernetes/). ---> -Kubernetes API 和 `kube-*` 组件（例如 `kube-apiserver`、`kube-controller-manager`）的参考文档是根据[上游 Kubernetes](https://github.com/kubernetes/kubernetes/) 中的源代码自动生成的。 -<!-- When you see bugs in the generated documentation, you may want to consider creating a patch to fix it in the upstream project. --> +## 基本说明 + +Kubernetes API 和 `kube-*` 组件（例如 `kube-apiserver`、`kube-controller-manager`）的参考文档 +是根据[上游 Kubernetes](https://github.com/kubernetes/kubernetes/) 中的源代码自动生成的。 + 当您在生成的文档中看到错误时，您可能需要考虑创建一个 PR 用来在上游项目中对其进行修复。 <!-- ## Cloning the Kubernetes repository + +If you don't already have the kubernetes/kubernetes repository, get it now: --> ## 克隆 Kubernetes 代码仓库 -<!-- -If you don't already have the kubernetes/kubernetes repository, get it now: ---> -如果您还没有 kubernetes/kubernetes 代码仓库，请立即参照下列命令获取： +如果您还没有 kubernetes/kubernetes 代码仓库，请参照下列命令获取： ```shell mkdir $GOPATH/src @@ -117,9 +107,10 @@ For example, if you followed the preceding step to get the repository, your base directory is `$GOPATH/src/github.com/kubernetes/kubernetes.` The remaining steps refer to your base directory as `<k8s-base>`. --> -确定您的 [kubernetes/kubernetes](https://github.com/kubernetes/kubernetes) 代码仓库克隆的基本目录。 -例如，如果按照前面的步骤获取代码仓库，则您的基本目录为 `$GOPATH/src/github.com/kubernetes/kubernetes`。 -接下来其余步骤将您的基本目录称为 `<k8s-base>`。 +确定您的 [kubernetes/kubernetes](https://github.com/kubernetes/kubernetes) 代码仓库克隆的根目录。 +例如，如果按照前面的步骤获取代码仓库，则你的根目录为 `$GOPATH/src/github.com/kubernetes/kubernetes`。 +接下来其余步骤将你的根目录称为 `<k8s-base>`。 + <!-- Determine the base directory of your clone of the [kubernetes-sigs/reference-docs](https://github.com/kubernetes-sigs/reference-docs) repository. @@ -127,22 +118,24 @@ For example, if you followed the preceding step to get the repository, your base directory is `$GOPATH/src/github.com/kubernetes-sigs/reference-docs.` The remaining steps refer to your base directory as `<rdocs-base>`. --> -确定您的 [kubernetes-sigs/reference-docs](https://github.com/kubernetes-sigs/reference-docs) 代码仓库克隆的基本目录。 -例如，如果按照前面的步骤获取代码仓库，则您的基本目录为 `$GOPATH/src/github.com/kubernetes-sigs/reference-docs`。 -接下来其余步骤将您的基本目录称为 `<rdocs-base>`。 +确定您的 [kubernetes-sigs/reference-docs](https://github.com/kubernetes-sigs/reference-docs) +代码仓库克隆的根目录。 +例如，如果按照前面的步骤获取代码仓库，则你的根目录为 +`$GOPATH/src/github.com/kubernetes-sigs/reference-docs`。 +接下来其余步骤将你的根目录称为 `<rdocs-base>`。 <!-- ## Editing the Kubernetes source code ---> -## 编辑 Kubernetes 源代码 -<!-- The Kubernetes API reference documentation is automatically generated from an OpenAPI spec, which is generated from the Kubernetes source code. If you want to change the API reference documentation, the first step is to change one or more comments in the Kubernetes source code. --> -Kubernetes API 参考文档是根据 OpenAPI 规范自动生成的，该规范是从 Kubernetes 源代码生成的。如果要更改 API 参考文档，第一步是更改 Kubernetes 源代码中的一个或多个注释。 +## 编辑 Kubernetes 源代码 + +Kubernetes API 参考文档是根据 OpenAPI 规范自动生成的，该规范是从 Kubernetes 源代码生成的。 +如果要更改 API 参考文档，第一步是更改 Kubernetes 源代码中的一个或多个注释。 <!-- The documentation for the `kube-*` components is also generated from the upstream @@ -153,27 +146,25 @@ you want to fix in order to fix the generated documentation. <!-- ### Making changes to the upstream source code ---> -### 更改上游 Kubernetes 源代码 -<!-- The following steps are an example, not a general procedure. Details will be different in your situation. --> +### 更改上游 Kubernetes 源代码 + {{< note >}} -以下步骤仅作为示例，不是一般步骤，具体情况因您而异。 +以下步骤仅作为示例，不是通用步骤，具体情况因环境而异。 {{< /note >}} <!-- Here's an example of editing a comment in the Kubernetes source code. ---> -以下在 Kubernetes 源代码中编辑注释的示例。 -<!-- In your local kubernetes/kubernetes repository, check out the master branch, and make sure it is up to date: --> -在您本地的 kubernetes/kubernetes 代码仓库中，切换出本地 master 分支，并确保它是最新的： +以下在 Kubernetes 源代码中编辑注释的示例。 + +在您本地的 kubernetes/kubernetes 代码仓库中，检出 master 分支，并确保它是最新的： ```shell cd <k8s-base> @@ -184,19 +175,18 @@ git pull https://github.com/kubernetes/kubernetes master <!-- Suppose this source file in the master branch has the typo "atmost": --> -假设 master 分支中的此源文件的拼写错误为 "atmost"： +假设 master 分支中的下面源文件中包含拼写错误 "atmost"： [kubernetes/kubernetes/staging/src/k8s.io/api/apps/v1/types.go](https://github.com/kubernetes/kubernetes/blob/master/staging/src/k8s.io/api/apps/v1/types.go) <!-- In your local environment, open `types.go`, and change "atmost" to "at most". ---> -在您的本地环境中，打开 `types.go` 文件，然后将 "atmost" 更改为 "at most"。 -<!-- Verify that you have changed the file: --> -以下命令查看您已更改的文件： +在你的本地环境中，打开 `types.go` 文件，然后将 "atmost" 更改为 "at most"。 + +以下命令验证你已经更改了文件： ```shell git status @@ -216,23 +206,22 @@ On branch master <!-- ### Committing your edited file ---> -### 提交已编辑的文件 -<!-- Run `git add` and `git commit` to commit the changes you have made so far. In the next step, you will do a second commit. It is important to keep your changes separated into two commits. --> -运行 `git add` 和 `git commit` 命令提交到目前为止所做的更改。在下一步中，您将进行第二次提交，将更改分成两个提交很重要。 +### 提交已编辑的文件 + +运行 `git add` 和 `git commit` 命令提交到目前为止所做的更改。 +在下一步中，您将进行第二次提交，将更改分成两个提交很重要。 <!-- ### Generating the OpenAPI spec and related files + +Go to `<k8s-base>` and run these scripts: --> ### 生成 OpenAPI 规范和相关文件 -<!-- -Go to `<k8s-base>` and run these scripts: ---> 进入 `<k8s-base>` 目录并运行以下脚本： ```shell @@ -242,12 +231,10 @@ hack/update-generated-protobuf.sh hack/update-api-reference-docs.sh ``` -<!-- -Run `git status` to see what was generated. ---> -运行 `git status` 命令查看生成的东西。 +<!-- Run `git status` to see what was generated. --> +运行 `git status` 命令查看生成的文件。 -```shell +```none On branch master ... modified: api/openapi-spec/swagger.json @@ -264,14 +251,16 @@ For example, you could run `git diff -a api/openapi-spec/swagger.json`. This is important, because `swagger.json` is the input to the second stage of the doc generation process. --> -查看 `api/openapi-spec/swagger.json` 的内容，以确保 typo 已经被修正。例如，您可以运行 `git diff -a api/openapi-spec/swagger.json` 命令。这很重要，因为 `swagger.json` 是文档生成过程中第二阶段的输入。 +查看 `api/openapi-spec/swagger.json` 的内容，以确保拼写错误已经被修正。 +例如，您可以运行 `git diff -a api/openapi-spec/swagger.json` 命令。 +这很重要，因为 `swagger.json` 是文档生成过程中第二阶段的输入。 <!-- Run `git add` and `git commit` to commit your changes. Now you have two commits: one that contains the edited `types.go` file, and one that contains the generated OpenAPI spec and related files. Keep these two commits separate. That is, do not squash your commits. --> -运行 `git add` 和 `git commit` 命令来提交您的更改。现在您有两个提交： +运行 `git add` 和 `git commit` 命令来提交您的更改。现在您有两个提交（commits）： 一种包含编辑的 `types.go` 文件，另一种包含生成的 OpenAPI 规范和相关文件。 将这两个提交分开独立。也就是说，不要 squash 您的提交。 @@ -283,13 +272,16 @@ master branch of the Monitor your pull request, and respond to reviewer comments as needed. Continue to monitor your pull request until it is merged. --> -将您的更改作为 [PR](https://help.github.com/articles/creating-a-pull-request/) 提交到 [kubernetes/kubernetes](https://github.com/kubernetes/kubernetes) 代码仓库的 master 分支。关注您的 PR，并根据需要回复 reviewer 的评论。继续关注您的 PR，直到 PR 被合并为止。 +将您的更改作为 [PR](https://help.github.com/articles/creating-a-pull-request/) +提交到 [kubernetes/kubernetes](https://github.com/kubernetes/kubernetes) 代码仓库的 master 分支。 +关注您的 PR，并根据需要回复 reviewer 的评论。继续关注您的 PR，直到 PR 被合并为止。 <!-- [PR 57758](https://github.com/kubernetes/kubernetes/pull/57758) is an example of a pull request that fixes a typo in the Kubernetes source code. --> -[PR 57758](https://github.com/kubernetes/kubernetes/pull/57758) 是修复 Kubernetes 源代码中的拼写错误的拉取请求的示例。 +[PR 57758](https://github.com/kubernetes/kubernetes/pull/57758) 是修复 Kubernetes +源代码中的拼写错误的拉取请求的示例。 <!-- It can be tricky to determine the correct source file to be changed. In the @@ -302,22 +294,30 @@ repository and in related repositories, such as [kubernetes/apiserver](https://github.com/kubernetes/apiserver/blob/master/README.md). --> {{< note >}} -确定要更改的正确源文件可能很棘手。在前面的示例中，官方的源文件位于 `kubernetes/kubernetes` 代码仓库的 `staging` 目录中。但是根据您的情况，`staging` 目录可能不是找到官方源文件的地方。根据指导原则，请检查 [kubernetes/kubernetes](https://github.com/kubernetes/kubernetes/tree/master/staging) 代码仓库和相关代码仓库（例如 [kubernetes/apiserver](https://github.com/kubernetes/apiserver/blob/master/README.md)）中的 `README` 文件。 +确定要更改的正确源文件可能很棘手。在前面的示例中，官方的源文件位于 `kubernetes/kubernetes` +代码仓库的 `staging` 目录中。但是根据您的情况，`staging` 目录可能不是找到官方源文件的地方。 +如果需要帮助，请阅读 +[kubernetes/kubernetes](https://github.com/kubernetes/kubernetes/tree/master/staging) +代码仓库和相关代码仓库 +（例如 [kubernetes/apiserver](https://github.com/kubernetes/apiserver/blob/master/README.md)） +中的 `README` 文件。 {{< /note >}} <!-- ### Cherry picking your commit into a release branch ---> -### Cherry Pick 将您的提交纳入发布分支 -<!-- In the preceding section, you edited a file in the master branch and then ran scripts to generate an OpenAPI spec and related files. Then you submitted your changes in a pull request to the master branch of the kubernetes/kubernetes repository. Now suppose you want to backport your change into a release branch. For example, suppose the master branch is being used to develop Kubernetes version 1.10, and you want to backport your change into the release-1.9 branch. --> -在上一节中，您在 master 分支中编辑了一个文件，然后运行了脚本用来生成 OpenAPI 规范和相关文件。然后将您的更改提交到 kubernetes/kubernetes 代码仓库的 master 分支的 pull request 中。 现在，需要将您的更改反向移植到已经 release 的分支。例如，假设使用 master 分支来开发 Kubernetes 1.10 版，并且您想将更改反向移植到 release-1.9 分支。 +### 将你的提交 Cherrypick 到发布分支 + +在上一节中，你在 master 分支中编辑了一个文件，然后运行了脚本用来生成 OpenAPI 规范和相关文件。 +然后用 PR 将你的更改提交到 kubernetes/kubernetes 代码仓库的 master 分支中。 +现在，需要将你的更改反向移植到已经发布的分支。 +例如，假设 master 分支被用来开发 Kubernetes 1.10 版，并且你想将更改反向移植到 release-1.9 分支。 <!-- Recall that your pull request has two commits: one for editing `types.go` @@ -326,7 +326,10 @@ commit into the release-1.9 branch. The idea is to cherry pick the commit that e the commit that has the results of running the scripts. For instructions, see [Propose a Cherry Pick](https://git.k8s.io/community/contributors/devel/sig-release/cherry-picks.md). --> -回想一下，您的 pull request 有两个提交：一个用于编辑 `types.go`，一个用于由脚本生成的文件。下一步的目的是对您的第一次提交 cherry pick 到 release-1.9 分支。这个想法是 cherry pick 编辑了 types.go 的提交，但不是具有运行脚本结果的提交。有关说明，请参见[提出 Cherry Pick](https://git.k8s.io/community/contributors/devel/sig-release/cherry-picks.md)。 +回想一下，您的 PR 有两个提交：一个用于编辑 `types.go`，一个用于由脚本生成的文件。 +下一步是将你的第一次提交 cherrypick 到 release-1.9 分支。这样做的原因是仅 cherrypick 编辑了 types.go 的提交， +而不是具有脚本运行结果的提交。 +有关说明，请参见[提出 Cherry Pick](https://git.k8s.io/community/contributors/devel/sig-release/cherry-picks.md)。 <!-- Proposing a cherry pick requires that you have permission to set a label and a milestone in your @@ -334,14 +337,16 @@ pull request. If you don't have those permissions, you will need to work with so and milestone for you. --> {{< note >}} -提出 cherry pick 要求您有权在 pull request 中设置标签和里程碑。如果您没有这些权限，则需要与可以为您设置标签和里程碑的人员合作。 +提出 Cherry Pick 要求你有权在 PR 中设置标签和里程碑。如果您没有这些权限， +则需要与可以为你设置标签和里程碑的人员合作。 {{< /note >}} <!-- When you have a pull request in place for cherry picking your one commit into the release-1.9 branch, the next step is to run these scripts in the release-1.9 branch of your local environment. --> -当您提出一个 pull request，希望将您的一个提交 cherry pick 到 release-1.9 分支中时，下一步是在本地环境的 release-1.9 分支中运行这些脚本。 +当你发起 PR 将你的一个提交 cherry pick 到 release-1.9 分支中时，下一步是在本地环境的 release-1.9 +分支中运行如下脚本。 ```shell hack/update-generated-swagger-docs.sh @@ -354,7 +359,8 @@ hack/update-api-reference-docs.sh Now add a commit to your cherry-pick pull request that has the recently generated OpenAPI spec and related files. Monitor your pull request until it gets merged into the release-1.9 branch. --> -现在将提交添加到您的 Cherry-pick pull request 中，该请求具有最近生成的 OpenAPI 规范和相关文件。关注您的 pull request 请求，直到其合并到 release-1.9 分支中为止。 +现在将提交添加到您的 Cherry-Pick PR 中，该 PR 中包含最新生成的 OpenAPI 规范和相关文件。 +关注你的 PR，直到其合并到 release-1.9 分支中为止。 <!-- At this point, both the master branch and the release-1.9 branch have your updated `types.go` @@ -364,44 +370,43 @@ the same as the generated files in the master branch. The generated files in the contain API elements only from Kubernetes 1.9. The generated files in the master branch might contain API elements that are not in 1.9, but are under development for 1.10. --> -此时，master 分支和 release-1.9 分支都具有更新的 `types.go` 文件和一组生成的文件，这些文件反映了您对 `types.go` 所做的更改。请注意，生成的 OpenAPI 规范和其他 release-1.9 分支中生成的文件不一定与 master 分支中生成的文件相同。release-1.9 分支中生成的文件仅包含来自 Kubernetes 1.9 的 API 元素。master 分支中生成的文件可能包含不在 1.9 中但正在为 1.10 开发的 API 元素。 - +此时，master 分支和 release-1.9 分支都具有更新的 `types.go` 文件和一组生成的文件， +这些文件反映了对 `types.go` 所做的更改。 +请注意，生成的 OpenAPI 规范和其他 release-1.9 分支中生成的文件不一定与 master 分支中生成的文件相同。 +release-1.9 分支中生成的文件仅包含来自 Kubernetes 1.9 的 API 元素。 +master 分支中生成的文件可能包含不在 1.9 中但正在为 1.10 开发的 API 元素。 <!-- ## Generating the published reference docs ---> -## 生成已发布的参考文档 -<!-- The preceding section showed how to edit a source file and then generate several files, including `api/openapi-spec/swagger.json` in the `kubernetes/kubernetes` repository. The `swagger.json` file is the OpenAPI definition file to use for generating the API reference documentation. --> -上一节显示了如何编辑源文件然后生成多个文件，包括在 `kubernetes/kubernetes` 代码仓库中的 `api/openapi-spec/swagger.json`。 -`swagger.json` 文件是 OpenAPI 定义文件，可用于生成 API 参考文档。 +## 生成已发布的参考文档 + +上一节显示了如何编辑源文件然后生成多个文件，包括在 `kubernetes/kubernetes` 代码仓库中的 +`api/openapi-spec/swagger.json`。`swagger.json` 文件是 OpenAPI 定义文件，可用于生成 API 参考文档。 <!-- You are now ready to follow the [Generating Reference Documentation for the Kubernetes API](/docs/contribute/generate-ref-docs/kubernetes-api/) guide to generate the [published Kubernetes API reference documentation](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/). --> -现在，您可以按照[生成 Kubernetes API 的参考文档](/docs/contribute/generate-ref-docs/kubernetes-api/)指南来生成 +现在，您可以按照 +[生成 Kubernetes API 的参考文档](/zh/docs/contribute/generate-ref-docs/kubernetes-api/) +指南来生成 [已发布的 Kubernetes API 参考文档](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/)。 - - ## {{% heading "whatsnext" %}} - <!-- * [Generating Reference Documentation for the Kubernetes API](/docs/contribute/generate-ref-docs/kubernetes-api/) * [Generating Reference Docs for Kubernetes Components and Tools](/docs/home/contribute/generated-reference/kubernetes-components/) * [Generating Reference Documentation for kubectl Commands](/docs/home/contribute/generated-reference/kubectl/) --> -* [生成 Kubernetes API 的参考文档](/docs/contribute/generate-ref-docs/kubernetes-api/) -* [为 Kubernetes 组件和工具生成参考文档](/docs/home/contribute/generated-reference/kubernetes-components/) -* [生成 kubectl 命令的参考文档](/docs/home/contribute/generated-reference/kubectl/) - - +* [生成 Kubernetes API 的参考文档](/zh/docs/contribute/generate-ref-docs/kubernetes-api/) +* [为 Kubernetes 组件和工具生成参考文档](/zh/docs/contribute/generate-ref-docs/kubernetes-components/) +* [生成 kubectl 命令的参考文档](/zh/docs/contribute/generate-ref-docs/kubectl/) diff --git a/content/zh/docs/contribute/generate-ref-docs/kubectl.md b/content/zh/docs/contribute/generate-ref-docs/kubectl.md index c482111747..c25f07582d 100644 --- a/content/zh/docs/contribute/generate-ref-docs/kubectl.md +++ b/content/zh/docs/contribute/generate-ref-docs/kubectl.md @@ -1,106 +1,65 @@ --- title: 为 kubectl 命令集生成参考文档 content_type: task +weight: 90 --- <!-- ---- title: Generating Reference Documentation for kubectl Commands content_type: task ---- +weight: 90 --> <!-- overview --> <!-- -This page shows how to automatically generate reference pages for the -commands provided by the `kubectl` tool. +This page shows how to generate the `kubectl` command reference. --> -该页面显示了如何自动生成 `kubectl` 工具提供的命令的参考页面。 +本页面描述了如何生成 `kubectl` 命令参考。 -{{< note >}} <!-- This topic shows how to generate reference documentation for [kubectl commands](/docs/reference/generated/kubectl/kubectl-commands) like [kubectl apply](/docs/reference/generated/kubectl/kubectl-commands#apply) and [kubectl taint](/docs/reference/generated/kubectl/kubectl-commands#taint). ---> -本主题展示了如何为 [kubectl 命令集](/docs/reference/generated/kubectl/kubectl-commands) 生成参考文档，如 [kubectl apply](/docs/reference/generated/kubectl/kubectl-commands#apply) 和 [kubectl taint](/docs/reference/generated/kubectl/kubectl-commands#taint)。 -<!-- This topic does not show how to generate the [kubectl](/docs/reference/generated/kubectl/kubectl/) options reference page. For instructions on how to generate the kubectl options reference page, see [Generating Reference Pages for Kubernetes Components and Tools](/docs/home/contribute/generated-reference/kubernetes-components/). --> -本主题没有展示如何生成 [kubectl](/docs/reference/generated/kubectl/kubectl/) 组件的参考页面。相关说明请参见[为 Kubernetes 组件和工具生成参考页面](/docs/home/contribute/generated-reference/kubernetes-components/)。 + +{{< note >}} +本主题描述了如何为 [kubectl 命令](/docs/reference/generated/kubectl/kubectl-commands) +生成参考文档，如 [kubectl apply](/docs/reference/generated/kubectl/kubectl-commands#apply) 和 +[kubectl taint](/docs/reference/generated/kubectl/kubectl-commands#taint)。 +本主题没有讨论如何生成 [kubectl](/docs/reference/generated/kubectl/kubectl-commands/) 组件选项的参考页面。 +相关说明请参见[为 Kubernetes 组件和工具生成参考页面](/zh/docs/contribute/generate-ref-docs/kubernetes-components/)。 {{< /note >}} - - - ## {{% heading "prerequisites" %}} - -<!-- -* You need to have -[Git](https://git-scm.com/book/en/v2/Getting-Started-Installing-Git) -installed. ---> - -* 你需要安装 [Git](https://git-scm.com/book/en/v2/Getting-Started-Installing-Git)。 - -<!-- -* You need to have -[Golang](https://golang.org/doc/install) version 1.9.1 or later installed, -and your `$GOPATH` environment variable must be set. ---> - -* 你需要安装 1.9.1 或更高版本的 [Golang](https://golang.org/doc/install), 并在环境变量中设置 `$GOPATH`。 - -<!-- -* You need to have -[Docker](https://docs.docker.com/engine/installation/) installed. ---> - -* 你需要安装 [Docker](https://docs.docker.com/engine/installation/)。 - -<!-- -* You need to know how to create a pull request to a GitHub repository. -Typically, this involves creating a fork of the repository. For more -information, see -[Creating a Documentation Pull Request](/docs/home/contribute/create-pull-request/) and -[GitHub Standard Fork & Pull Request Workflow](https://gist.github.com/Chaser324/ce0505fbed06b947d962). ---> - -* 你需要知道如何在一个 GitHub 项目仓库中创建一个 PR。一般来说，这涉及到创建仓库的一个分支。想了解更多信息，请参见[创建一个文档 PR](/docs/home/contribute/create-pull-request/) 和 [GitHub 标准 Fork & PR 工作流](https://gist.github.com/Chaser324/ce0505fbed06b947d962)。 - - - +{{< include "prerequisites-ref-docs.md" >}} <!-- steps --> <!-- ## Setting up the local repositories ---> -## 设置本地仓库 -<!-- Create a local workspace and set your `GOPATH`. --> -创建本地工作区并设置您的 `GOPATH`。 +## 配置本地仓库 + +创建本地工作区并设置你的 `GOPATH`。 ```shell mkdir -p $HOME/<workspace> - export GOPATH=$HOME/<workspace> ``` -<!-- -Get a local clone of the following repositories: ---> +<!-- Get a local clone of the following repositories: --> 获取以下仓库的本地克隆： ```shell @@ -113,16 +72,14 @@ go get -u kubernetes-incubator/reference-docs <!-- If you don't already have the kubernetes/website repository, get it now: --> -如果您还没有下载过 `kubernetes/website` 仓库，现在下载： +如果您还没有获取过 `kubernetes/website` 仓库，现在获取之： ```shell git clone https://github.com/<your-username>/website $GOPATH/src/github.com/<your-username>/website ``` -<!-- -Get a clone of the kubernetes/kubernetes repository as k8s.io/kubernetes: ---> -克隆下载 kubernetes/kubernetes 仓库，并作为 k8s.io/kubernetes： +<!-- Get a clone of the kubernetes/kubernetes repository as k8s.io/kubernetes: --> +克隆 kubernetes/kubernetes 仓库作为 k8s.io/kubernetes： ```shell git clone https://github.com/kubernetes/kubernetes $GOPATH/src/k8s.io/kubernetes @@ -131,18 +88,15 @@ git clone https://github.com/kubernetes/kubernetes $GOPATH/src/k8s.io/kubernetes <!-- Remove the spf13 package from `$GOPATH/src/k8s.io/kubernetes/vendor/github.com`. --> -从 `$GOPATH/src/k8s.io/kubernetes/vendor/github.com` 中卸载 spf13 软件包。 +从 `$GOPATH/src/k8s.io/kubernetes/vendor/github.com` 中移除 spf13 软件包。 ```shell rm -rf $GOPATH/src/k8s.io/kubernetes/vendor/github.com/spf13 ``` -<!-- -The kubernetes/kubernetes repository provides access to the kubectl and kustomize source code. ---> +<!-- The kubernetes/kubernetes repository provides access to the kubectl and kustomize source code. --> kubernetes/kubernetes 仓库提供对 kubectl 和 kustomize 源代码的访问。 - <!-- * Determine the base directory of your clone of the [kubernetes/kubernetes](https://github.com/kubernetes/kubernetes) repository. @@ -150,7 +104,9 @@ For example, if you followed the preceding step to get the repository, your base directory is `$GOPATH/src/k8s.io/kubernetes.` The remaining steps refer to your base directory as `<k8s-base>`. --> -确定 [kubernetes/kubernetes](https://github.com/kubernetes/kubernetes) 仓库的本地主目录。例如，如果按照前面的步骤来获取该仓库，则主目录是 `$GOPATH/src/k8s.io/kubernetes.`。下文将该目录称为 `<k8s-base>`。 +* 确定 [kubernetes/kubernetes](https://github.com/kubernetes/kubernetes) 仓库的本地主目录。 + 例如，如果按照前面的步骤来获取该仓库，则主目录是 `$GOPATH/src/k8s.io/kubernetes.`。 + 下文将该目录称为 `<k8s-base>`。 <!-- * Determine the base directory of your clone of the @@ -159,198 +115,197 @@ For example, if you followed the preceding step to get the repository, your base directory is `$GOPATH/src/github.com/<your-username>/website.` The remaining steps refer to your base directory as `<web-base>`. --> -确定 [kubernetes/website](https://github.com/kubernetes/website) 仓库的本地主目录。例如，如果按照前面的步骤来获取该仓库，则主目录是 `$GOPATH/src/github.com/<your-username>/website`。下文将该目录称为 `<web-base>`。 +* 确定 [kubernetes/website](https://github.com/kubernetes/website) 仓库的本地主目录。 + 例如，如果按照前面的步骤来获取该仓库，则主目录是 `$GOPATH/src/github.com/<your-username>/website`。 + 下文将该目录称为 `<web-base>`。 <!-- * Determine the base directory of your clone of the -[kubernetes-incubator/reference-docs](https://github.com/kubernetes-incubator/reference-docs) repository. +[kubernetes-sigs/reference-docs](https://github.com/kubernetes-sigs/reference-docs) repository. For example, if you followed the preceding step to get the repository, your -base directory is `$GOPATH/src/github.com/kubernetes-incubator/reference-docs.` +base directory is `$GOPATH/src/github.com/kubernetes-sigs/reference-docs.` The remaining steps refer to your base directory as `<rdocs-base>`. --> -确定 [kubernetes-incubator/reference-docs](https://github.com/kubernetes-incubator/reference-docs) 仓库的本地主目录。例如，如果按照前面的步骤来获取该仓库，则主目录是 `$GOPATH/src/github.com/kubernetes-incubator/reference-docs`。下文将该目录称为 `<rdocs-base>`。 +* 确定 [kubernetes-sigs/reference-docs](https://github.com/kubernetes-sigs/reference-docs) + 仓库的本地主目录。例如，如果按照前面的步骤来获取该仓库，则主目录是 + `$GOPATH/src/github.com/kubernetes-sigs/reference-docs`。 + 下文将该目录称为 `<rdocs-base>`。 <!-- In your local k8s.io/kubernetes repository, check out the branch of interest, and make sure it is up to date. For example, if you want to generate docs for -Kubernetes 1.15, you could use these commands: +Kubernetes 1.17, you could use these commands: --> -在您当地的 k8s.io/kubernetes 仓库中，检查感兴趣的分支并确保它是最新的。例如，如果您想要生成 Kubernetes 1.15 的文档，您可以使用以下命令： +在本地的 k8s.io/kubernetes 仓库中，检出感兴趣的分支并确保它是最新的。例如， +如果你想要生成 Kubernetes 1.17 的文档，可以使用以下命令： ```shell cd <k8s-base> -git checkout release-1.15 -git pull https://github.com/kubernetes/kubernetes release-1.15 +git checkout v1.17.0 +git pull https://github.com/kubernetes/kubernetes v1.17.0 ``` <!-- -If you do not need to edit the kubectl source code, follow the instructions to [Edit the Makefile](#editing-makefile). +If you do not need to edit the kubectl source code, follow the instructions to +[Setting build variables](#setting-build-variables). --> -如果不需要编辑 kubectl 源码，请按照说明[编辑 Makefile](#editing-makefile)。 +如果不需要编辑 `kubectl` +源码，请按照说明[配置构建变量](#setting-build-variables)。 <!-- ## Editing the kubectl source code ---> -## 编辑 kubectl 源码 - -<!-- The kubectl command reference documentation is automatically generated from the kubectl source code. If you want to change the reference documentation, the first step is to change one or more comments in the kubectl source code. Make the change in your local kubernetes/kubernetes repository, and then submit a pull request to the master branch of [github.com/kubernetes/kubernetes](https://github.com/kubernetes/kubernetes). --> +## 编辑 kubectl 源码 -kubectl 命令集的参考文档是基于 kubectl 源码自动生成的。如果想要修改参考文档，可以从修改 kubectl 源码中的一个或多个注释开始。在本地 kubernetes/kubernetes 仓库中进行修改，然后向 [github.com/kubernetes/kubernetes](https://github.com/kubernetes/kubernetes) 的 master 分支提交 PR。 +kubectl 命令的参考文档是基于 kubectl 源码自动生成的。如果想要修改参考文档，可以从修改 +kubectl 源码中的一个或多个注释开始。在本地 kubernetes/kubernetes 仓库中进行修改，然后向 +[github.com/kubernetes/kubernetes](https://github.com/kubernetes/kubernetes) 的 master +分支提交 PR。 <!-- [PR 56673](https://github.com/kubernetes/kubernetes/pull/56673/files) is an example of a pull request that fixes a typo in the kubectl source code. ---> -[PR 56673](https://github.com/kubernetes/kubernetes/pull/56673/files) 是一个对 kubectl 源码中的笔误进行修复的 PR 示例。 - -<!-- Monitor your pull request, and respond to reviewer comments. Continue to monitor your pull request until it is merged into the master branch of the kubernetes/kubernetes repository. --> -跟踪你的 PR，并回应评审人的评论。继续跟踪你的 PR，直到它合入到 kubernetes/kubernetes 仓库的 master 分支中。 +[PR 56673](https://github.com/kubernetes/kubernetes/pull/56673/files) 是一个对 kubectl +源码中的笔误进行修复的 PR 示例。 + +跟踪你的 PR，并回应评审人的评论。继续跟踪你的 PR，直到它合入到 kubernetes/kubernetes 仓库的 +master 分支中。 <!-- ## Cherry picking your change into a release branch ---> -## 以 cherry-pick 方式将你的修改合入已发布分支 - -<!-- Your change is now in the master branch, which is used for development of the next Kubernetes release. If you want your change to appear in the docs for a Kubernetes version that has already been released, you need to propose that your change be cherry picked into the release branch. --> +## 以 cherry-pick 方式将你的修改合入已发布分支 -你的修改已合入 master 分支中，该分支用于开发下一个 Kubernetes 版本。如果你希望修改部分出现在已发布的 Kubernetes 版本文档中，则需要提议将它们以 cherry-pick 方式合入已发布分支。 +你的修改已合入 master 分支中，该分支用于开发下一个 Kubernetes 版本。 +如果你希望修改部分出现在已发布的 Kubernetes 版本文档中，则需要提议将它们以 +cherry-pick 方式合入已发布分支。 <!-- For example, suppose the master branch is being used to develop Kubernetes 1.10, and you want to backport your change to the release-1.15 branch. For instructions on how to do this, see [Propose a Cherry Pick](https://git.k8s.io/community/contributors/devel/sig-release/cherry-picks.md). ---> -例如，假设 master 分支正用于开发 Kubernetes 1.10 版本，而你希望将修改合入到已发布的 1.15 版本分支。相关的操作指南，请参见 [提议一个 cherry-pick 合入](https://git.k8s.io/community/contributors/devel/sig-release/cherry-picks.md)。 - -<!-- Monitor your cherry-pick pull request until it is merged into the release branch. --> +例如，假设 master 分支正用于开发 Kubernetes 1.16 版本，而你希望将修改合入到已发布的 1.15 版本分支。 +相关的操作指南，请参见 +[提议一个 cherry-pick](https://git.k8s.io/community/contributors/devel/sig-release/cherry-picks.md)。 + 跟踪你的 cherry-pick PR，直到它合入到已发布分支中。 -{{< note >}} <!-- Proposing a cherry pick requires that you have permission to set a label and a milestone in your pull request. If you don’t have those permissions, you will need to work with someone who can set the label and milestone for you. --> -提议一个 cherry-pick 合入，需要你有在 PR 中设置标签和里程碑的权限。如果你没有，你需要与有权限为你设置标签和里程碑的人合作完成。 +{{< note >}} +提议一个 cherry-pick 需要你有在 PR 中设置标签和里程碑的权限。 +如果你没有，你需要与有权限为你设置标签和里程碑的人合作完成。 {{< /note >}} <!-- -## Editing Makefile ---> +## Setting build variables -## 编辑 Makefile - -<!-- Go to `<rdocs-base>`, and open the `Makefile` for editing: --> +## 设置构建变量 {#setting-build-variables} 进入 `<rdocs-base>` 目录, 打开 `Makefile` 进行编辑： <!-- -* Set `K8SROOT` to `<k8s-base>`. -* Set `WEBROOT` to `<web-base>`. -* Set `MINOR_VERSION` to the minor version of the docs you want to build. For example, -if you want to build docs for Kubernetes 1.15, set `MINOR_VERSION` to 15. Save and close the `Makefile`. ---> -* 设置 `K8SROOT` 为 `<k8s-base>`。 -* 设置 `WEBROOT` 为 `<web-base>`。 -* 设置 `MINOR_VERSION` 为要构建的文档的次要版本。例如，如果您想为 Kubernetes 1.15 构建文档，请将 `MINOR_VERSION` 设置为 15。保存并关闭 `Makefile` 文件。 +* Set `K8S_ROOT` to `<k8s-base>`. +* Set `K8S_WEBROOT` to `<web-base>`. +* Set `K8S_RELEASE` to the version of the docs you want to build. + For example, if you want to build docs for Kubernetes 1.17, set `K8S_RELEASE` to 1.17. -<!-- For example, update the following variables: --> -例如，更新以下变量： +* 设置 `K8S_ROOT` 为 `<k8s-base>`。 +* 设置 `K8S_WEBROOT` 为 `<web-base>`。 +* 设置 `K8S_RELEASE` 为要构建文档的版本。 + 例如，如果您想为 Kubernetes 1.17 构建文档，请将 `K8S_RELEASE` 设置为 1.17。 + +例如： ``` -WEBROOT=$(GOPATH)/src/github.com/<your-username>/website -K8SROOT=$(GOPATH)/src/k8s.io/kubernetes -MINOR_VERSION=15 +export K8S_WEBROOT=$(GOPATH)/src/github.com/<your-username>/website +export K8S_ROOT=$(GOPATH)/src/k8s.io/kubernetes +export K8S_RELEASE=1.17 ``` <!-- -## Creating a version directory +## Creating a versioned directory + +The `createversiondirs` build target creates a versioned directory +and copies the kubectl reference configuration files to the versioned directory. +The versioned directory name follows the pattern of `v<major>_<minor>`. + +In the `<rdocs-base>` directory, run the following build target: + +```shell +cd <rdocs-base> +make createversiondirs +``` --> ## 创建版本目录 -<!-- -The version directory is a staging area for the kubectl command reference build. -The YAML files in this directory are used to create the structure and navigation -of the kubectl command reference. ---> -版本目录是 kubectl 命令集构建的临时区域。该目录中的 YAML 文件用于创建 kubectl 命令集参考的结构和导航。 +构建目标 `createversiondirs` 会生成一个版本目录并将 kubectl 参考配置文件复制到该目录中。 +版本目录的名字模式为 `v<major>_<minor>`。 -<!-- -In the `<rdocs-base>/gen-kubectldocs/generators` directory, if you do not already -have a directory named `v1_<MINOR_VERSION>`, create one now by copying the directory -for the previous version. For example, suppose you want to generate docs for -Kubernetes 1.15, but you don't already have a `v1_15` directory. Then you could -create and populate a `v1_15` directory by running these commands: ---> - -在 `gen-kubectldocs/generators` 目录中，如果你还没有一个名为 `v1_MINOR_VERSION` 的目录，那么现在通过复制前一版本的目录来创建一个。例如，假设你想要为 Kubernetes 1.15 版本生成文档，但是还没有 `v1_15` 目录，这时可以通过运行以下命令来创建并填充 `v1_15` 目录： +在 `<rdocs-base>` 目录下，执行下面的命令： ```shell -cd <k8s-base> -git checkout release-1.15 -git pull https://github.com/kubernetes/kubernetes release-1.15 +cd <rdocs-base> +make createversiondirs ``` <!-- ## Checking out a branch in k8s.io/kubernetes ---> -## 从 kubernetes/kubernetes 检出一个分支 - -<!-- In your local <k8s-base> repository, checkout the branch that has the version of Kubernetes that you want to document. For example, if you want to generate docs for Kubernetes 1.15, checkout the release-1.15 branch. Make sure you local branch is up to date. --> +## 从 kubernetes/kubernetes 检出一个分支 -在本地 <k8s-base> 仓库中，检出你想要生成文档的、包含 Kubernetes 版本的分支。例如，如果希望为 Kubernetes 1.15 版本生成文档，请检出 1.15 分支。确保本地分支是最新的。 +在本地 `<k8s-base>` 仓库中，检出你想要生成文档的、包含 Kubernetes 版本的分支。 +例如，如果希望为 Kubernetes 1.17 版本生成文档，请检出 `v1.17.0` 标记。 +确保本地分支是最新的。 ```shell cd <k8s-base> -git checkout release-1.15 -git pull https://github.com/kubernetes/kubernetes release-1.15 +git checkout v1.17.0 +git pull https://github.com/kubernetes/kubernetes v1.17.0 ``` <!-- ## Running the doc generation code ---> -## 运行文档生成代码 - -<!-- In your local kubernetes-incubator/reference-docs repository, build and run the kubectl command reference generation code. You might need to run the command as root: --> +## 运行文档生成代码 -在 kubernetes-incubator/reference-docs 仓库的本地目录中，构建并运行 kubectl 命令集参数生成代码。你可能需要以 root 用户运行命令： +在本地的 `<rdocs-base>` 目录下，运行 `copycli` 构建目标。此命令以 `root` 账号运行： ```shell cd <rdocs-base> @@ -361,16 +316,16 @@ make copycli The `copycli` command will clean the staging directories, generate the kubectl command files, and copy the collated kubectl reference HTML page and assets to `<web-base>`. --> -`copycli` 命令将清理暂存目录，生成 kubectl 命令集文件，并将整理后的 kubectl 参考 HTML 页面和文件复制到 `<web-base>`。 +`copycli` 命令将清理暂存目录，生成 kubectl 命令文件，并将整理后的 kubectl 参考 HTML 页面和 +文件复制到 `<web-base>`。 <!-- ## Locate the generated files + +Verify that these two files have been generated: --> ## 找到生成的文件 -<!-- -Verify that these two files have been generated: ---> 验证是否已生成以下两个文件： ```shell @@ -380,22 +335,19 @@ Verify that these two files have been generated: <!-- ## Locate the copied files + +Verify that all generated files have been copied to your `<web-base>`: --> ## 找到复制的文件 -<!-- -Verify that all generated files have been copied to your `<web-base>`: ---> -确认所有生成的文件都已复制到您的 `<web-base>`： +确认所有生成的文件都已复制到你的 `<web-base>`： ```shell cd <web-base> git status ``` -<!-- -The output should include the modified files: ---> +<!-- The output should include the modified files: --> 输出应包括修改后的文件： ``` @@ -403,10 +355,9 @@ static/docs/reference/generated/kubectl/kubectl-commands.html static/docs/reference/generated/kubectl/navData.js ``` -<!-- -Additionally, the output might show the modified files: ---> -此外，输出可能显示修改后的文件： +<!-- Additionally, the output might show the modified files: --> + +此外，输出可能还包含： ``` static/docs/reference/generated/kubectl/scroll.js @@ -421,12 +372,11 @@ static/docs/reference/generated/kubectl/node_modules/font-awesome/css/font-aweso <!-- ## Locally test the documentation + +Build the Kubernetes documentation in your local `<web-base>`. --> ## 在本地测试文档 -<!-- -Build the Kubernetes documentation in your local `<web-base>`. ---> 在本地 `<web-base>` 中构建 Kubernetes 文档。 ```shell @@ -434,55 +384,44 @@ cd <web-base> make docker-serve ``` -<!-- -View the [local preview](https://localhost:1313/docs/reference/generated/kubectl/kubectl-commands/). ---> +<!-- View the [local preview](https://localhost:1313/docs/reference/generated/kubectl/kubectl-commands/). --> 查看[本地预览](https://localhost:1313/docs/reference/generated/kubectl/kubectl-commands/)。 <!-- ## Adding and committing changes in kubernetes/website + +Run `git add` and `git commit` to commit the files. --> ## 在 kubernetes/website 中添加和提交更改 -<!-- -Run `git add` and `git commit` to commit the files. ---> 运行 `git add` 和 `git commit` 提交修改文件。 <!-- ## Creating a pull request ---> -## 创建 PR -<!-- Create a pull request to the `kubernetes/website` repository. Monitor your pull request, and respond to review comments as needed. Continue to monitor your pull request until it is merged. ---> -对 `kubernetes/website` 仓库创建 PR。跟踪你的 PR，并根据需要回应评审人的评论。继续跟踪你的 PR，直到它被合入。 - -<!-- A few minutes after your pull request is merged, your updated reference topics will be visible in the [published documentation](/docs/home). --> +## 创建 PR -在 PR 合入的几分钟后，你更新的参考主题将出现在[已发布文档](/docs/home/)中。 - - +对 `kubernetes/website` 仓库创建 PR。跟踪你的 PR，并根据需要回应评审人的评论。 +继续跟踪你的 PR，直到它被合入。 +在 PR 合入的几分钟后，你更新的参考主题将出现在[已发布文档](/zh/docs/home/)中。 ## {{% heading "whatsnext" %}} - <!-- -* [Generating Reference Documentation for Kubernetes Components and Tools](/docs/home/contribute/generated-reference/kubernetes-components/) -* [Generating Reference Documentation for the Kubernetes API](/docs/home/contribute/generated-reference/kubernetes-api/) -* [Generating Reference Documentation for the Kubernetes Federation API](/docs/home/contribute/generated-reference/federation-api/) +* [Generating Reference Documentation Quickstart](/docs/contribute/generate-ref-docs/quickstart/) +* [Generating Reference Documentation for Kubernetes Components and Tools](/docs/contribute/generate-ref-docs/kubernetes-components/) +* [Generating Reference Documentation for the Kubernetes API](/docs/contribute/generate-ref-docs/kubernetes-api/) --> - -* [为 Kubernetes 组件和工具生成参考文档](/docs/home/contribute/generated-reference/kubernetes-components/) -* [为 Kubernetes API 生成参考文档](/docs/home/contribute/generated-reference/kubernetes-api/) -* [为 Kubernetes 联邦 API 生成参考文档](/docs/home/contribute/generated-reference/federation-api/) +* [生成参考文档快速入门](/zh/docs/contribute/generate-ref-docs/quickstart/) +* [为 Kubernetes 组件和工具生成参考文档](/zh/docs/contribute/generate-ref-docs/kubernetes-components/) +* [为 Kubernetes API 生成参考文档](/zh/docs/contribute/generate-ref-docs/kubernetes-api/) diff --git a/content/zh/docs/contribute/generate-ref-docs/kubernetes-api.md b/content/zh/docs/contribute/generate-ref-docs/kubernetes-api.md index c31b9a2909..c000bff384 100644 --- a/content/zh/docs/contribute/generate-ref-docs/kubernetes-api.md +++ b/content/zh/docs/contribute/generate-ref-docs/kubernetes-api.md @@ -1,21 +1,22 @@ --- title: 为 Kubernetes API 生成参考文档 content_type: task +weight: 50 --- <!-- ---- title: Generating Reference Documentation for the Kubernetes API content_type: task ---- +weight: 50 --> <!-- overview --> <!-- This page shows how to update the generated reference docs for the Kubernetes API. + The Kubernetes API reference documentation is built from the [Kubernetes OpenAPI spec](https://github.com/kubernetes/kubernetes/blob/master/api/openapi-spec/swagger.json) -and tools from [kubernetes-incubator/reference-docs](https://github.com/kubernetes-incubator/reference-docs). +and tools from [kubernetes-sigs/reference-docs](https://github.com/kubernetes-sigs/reference-docs). If you find bugs in the generated documentation, you need to [fix them upstream](/docs/contribute/generate-ref-docs/contribute-upstream/). @@ -24,86 +25,54 @@ If you need only to regenerate the reference documentation from the [OpenAPI](ht spec, continue reading this page. --> 本页面展示了如何为 Kubernetes API 更新自动生成的参考文档。 -Kubernetes API 参考文档是从 [Kubernetes OpenAPI 规范](https://github.com/kubernetes/kubernetes/blob/master/api/openapi-spec/swagger.json)构建的，而工具是从 [kubernetes-incubator/reference-docs](https://github.com/kubernetes-incubator/reference-docs) 构建的。 - -如果您在生成的文档中发现错误，则需要[将其上游修复](/docs/contribute/generate-ref-docs/contribute-upstream/)。 - -如果您只需要从 [OpenAPI](https://github.com/OAI/OpenAPI-Specification) 规范中重新生成参考文档，请继续阅读此页面。 +Kubernetes API 参考文档是从 +[Kubernetes OpenAPI 规范](https://github.com/kubernetes/kubernetes/blob/master/api/openapi-spec/swagger.json) +构建的，而工具是从 +[kubernetes-sigs/reference-docs](https://github.com/kubernetes-sigs/reference-docs) 构建的。 +如果您在生成的文档中发现错误，则需要[在上游修复](/zh/docs/contribute/generate-ref-docs/contribute-upstream/)。 +如果您只需要从 [OpenAPI](https://github.com/OAI/OpenAPI-Specification) 规范中重新生成参考文档，请继续阅读此页。 ## {{% heading "prerequisites" %}} - -<!-- -You need to have these tools installed: ---> - -你需要安装以下软件： - -<!-- -* [Git](https://git-scm.com/book/en/v2/Getting-Started-Installing-Git) -* [Golang](https://golang.org/doc/install) version 1.9.1 or later ---> - -* [Git](https://git-scm.com/book/en/v2/Getting-Started-Installing-Git) -* 1.9.1 或更高版本的 [Golang](https://golang.org/doc/install) - -<!-- -You need to know how to create a pull request (PR) to a GitHub repository. -Typically, this involves creating a fork of the repository. For more -information, see -[Creating a Documentation Pull Request](/docs/contribute/start/) and -[GitHub Standard Fork & Pull Request Workflow](https://gist.github.com/Chaser324/ce0505fbed06b947d962). ---> -你需要知道如何在一个 GitHub 项目仓库中创建一个 PR。一般来说，这涉及到创建仓库的 fork 分支。想了解更多信息，请参见[创建一个文档 PR](/docs/contribute/start/) 和 [GitHub 标准 Fork & PR 工作流](https://gist.github.com/Chaser324/ce0505fbed06b947d962)。 - - - +{{< include "prerequisites-ref-docs.md" >}} <!-- steps --> <!-- ## Setting up the local repositories ---> -## 设置本地仓库 -<!-- Create a local workspace and set your `GOPATH`. --> -创建本地工作区并设置您的 `GOPATH`。 +## 配置本地仓库 + +创建本地工作区并设置你的 `GOPATH`。 ```shell mkdir -p $HOME/<workspace> - export GOPATH=$HOME/<workspace> ``` -<!-- -Get a local clone of the following repositories: ---> +<!-- Get a local clone of the following repositories: --> 获取以下仓库的本地克隆： ```shell go get -u github.com/kubernetes-incubator/reference-docs - go get -u github.com/go-openapi/loads go get -u github.com/go-openapi/spec ``` -<!-- -If you don't already have the kubernetes/website repository, get it now: --> -如果您还没有下载过 `kubernetes/website` 仓库，现在下载： +<!-- If you don't already have the kubernetes/website repository, get it now: --> +如果你还没有下载过 `kubernetes/website` 仓库，现在下载： ```shell git clone https://github.com/<your-username>/website $GOPATH/src/github.com/<your-username>/website ``` -<!-- -Get a clone of the kubernetes/kubernetes repository as k8s.io/kubernetes: ---> -克隆下载 kubernetes/kubernetes 仓库，并作为 k8s.io/kubernetes： +<!-- Get a clone of the kubernetes/kubernetes repository as k8s.io/kubernetes: --> +克隆 kubernetes/kubernetes 仓库作为 k8s.io/kubernetes： ```shell git clone https://github.com/kubernetes/kubernetes $GOPATH/src/k8s.io/kubernetes @@ -125,97 +94,91 @@ The remaining steps refer to your base directory as `<web-base>`. repository is `$GOPATH/src/github.com/kubernetes-incubator/reference-docs.` The remaining steps refer to your base directory as `<rdocs-base>`. --> -* [kubernetes/kubernetes](https://github.com/kubernetes/kubernetes) 仓库克隆后的基本目录为 `$GOPATH/src/k8s.io/kubernetes`。 -其余后续步骤将您的基本目录称为 `<k8s-base>`。 - -* [kubernetes/website](https://github.com/kubernetes/website) 仓库克隆后的基本目录为 `$GOPATH/src/github.com/<your username>/website`。 -其余后续步骤将您的基本目录称为 `<web-base>`。 - -* [kubernetes-incubator/reference-docs](https://github.com/kubernetes-incubator/reference-docs) 仓库克隆后的基本目录为 `$GOPATH/src/github.com/kubernetes-incubator/reference-docs`。 -其余后续步骤将您的基本目录称为 `<rdocs-base>`。 +* [kubernetes/kubernetes](https://github.com/kubernetes/kubernetes) 仓库克隆后的根目录为 + `$GOPATH/src/k8s.io/kubernetes`。 后续步骤将此目录称为 `<k8s-base>`。 +* [kubernetes/website](https://github.com/kubernetes/website) 仓库克隆后的根目录为 + `$GOPATH/src/github.com/<your username>/website`。后续步骤将此目录称为 `<web-base>`。 +* [kubernetes-sigs/reference-docs](https://github.com/kubernetes-sigs/reference-docs) + 仓库克隆后的基本目录为 `$GOPATH/src/github.com/kubernetes-sigs/reference-docs`。 + 后续步骤将此目录称为 `<rdocs-base>`。 <!-- ## Generating the API reference docs ---> -## 生成 API 参考文档 -<!-- This section shows how to generate the [published Kubernetes API reference documentation](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/). --> +## 生成 API 参考文档 + 本节说明如何生成[已发布的 Kubernetes API 参考文档](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/)。 <!-- -### Modifying the Makefile ---> -### 修改 Makefile 文件 +### Setting build variables -<!-- Go to `<rdocs-base>`, and open the `Makefile` for editing: --> -进入 `<rdocs-base>` 目录，然后编辑 `Makefile` 文件： +### 设置构建变量 {#setting-build-variables} <!-- -* Set `K8SROOT` to `<k8s-base>`. -* Set `WEBROOT` to `<web-base>`. -* Set `MINOR_VERSION` to the minor version of the docs you want to build. For example, -if you want to build docs for Kubernetes 1.15, set `MINOR_VERSION` to 15. Save and close the `Makefile`. +* Set `K8S_ROOT` to `<k8s-base>`. +* Set `K8S_WEBROOT` to `<web-base>`. +* Set `K8S_RELEASE` to the minor version of the docs you want to build. + For example, if you want to build docs for Kubernetes 1.17, set `K8S_RELEASE` to 1.17. --> -* 设置 `K8SROOT` 为 `<k8s-base>`. -* 设置 `WEBROOT` 为 `<web-base>`. -* 设置 `MINOR_VERSION` 为要构建的文档的次要版本。例如，如果您想为 Kubernetes 1.15 构建文档，请将 `MINOR_VERSION` 设置为 15。保存并关闭 `Makefile` 文件。 +* 设置 `K8S_ROOT` 为 `<k8s-base>`. +* 设置 `K8S_WEBROOT` 为 `<web-base>`. +* 设置 `K8S_RELEASE` 为要构建的文档的版本。 + 例如，如果您想为 Kubernetes 1.17 构建文档，请将 `K8S_RELEASE` 设置为 1.17。 -<!-- -For example, update the following variables: ---> -例如，更新以下变量： +<!-- For example, update the following variables: --> +例如： ``` -WEBROOT=$(GOPATH)/src/github.com/<your-username>/website -K8SROOT=$(GOPATH)/src/k8s.io/kubernetes -MINOR_VERSION=15 +export K8S_WEBROOT=$(GOPATH)/src/github.com/<your-username>/website +export K8S_ROOT=$(GOPATH)/src/k8s.io/kubernetes +export K8S_RELEASE=1.17 ``` <!-- -### Copying the OpenAPI spec ---> -### 复制 OpenAPI 规范 +### Creating versioned directory and fetching Open API spec -<!-- -Run the following command in `<rdocs-base>`: +The `updateapispec` build target creates the versioned build directory. +After the directory is created, the Open API spec is fetched from the +`<k8s-base>` repository. These steps ensure that the version +of the configuration files and Kubernetes Open API spec match the release version. +The versioned directory name follows the pattern of `v<major>_<minor>`. --> -在 `<rdocs-base>` 目录中运行以下命令： +### 创建版本目录并复制 OpenAPI 规范 + +构建目标 `updateapispec` 负责创建版本化的构建目录。 +目录创建了之后，从 `<k8s-base>` 仓库取回 OpenAPI 规范文件。 +这些步骤确保配置文件的版本和 Kubernetes OpenAPI 规范的版本与发行版本匹配。 +版本化目录的名称形式为 `v<major>_<minor>`。 ```shell make updateapispec ``` -<!-- -The output shows that the file was copied: ---> -输出显示文件已被复制： - -```shell -cp ~/src/k8s.io/kubernetes/api/openapi-spec/swagger.json gen-apidocs/generators/openapi-spec/swagger.json -``` - <!-- ### Building the API reference docs + +The `copyapi` target builds the API reference and +copies the generated files to directories in `<web-base>`. +Run the following command in `<rdocs-base>`: + --> ### 构建 API 参考文档 -<!-- -Run the following command in `<rdocs-base>`: ---> +构建目标 `copyapi` 会生成 API 参考文档并将所生成文件复制到 +`<web-base` 中的目录下。 在 `<rdocs-base>` 目录中运行以下命令： ```shell -make api +cd <rdocs-base> +make copyapi ``` -<!-- -Verify that these two files have been generated: ---> +<!-- Verify that these two files have been generated: --> 验证是否已生成这两个文件： ```shell @@ -223,108 +186,83 @@ Verify that these two files have been generated: [ -e "<rdocs-base>/gen-apidocs/generators/build/navData.js" ] && echo "navData.js built" || echo "no navData.js" ``` -<!-- -### Creating directories for published docs +<!-- +Go to the base of your local `<web-base>`, and +view which files have been modified: --> -### 创建发布文档的目录 - -<!-- -Create the directories in `<web-base>` for the generated API reference files: ---> -在 `<web-base>` 目录中为生成的 API 参考文件创建目录： - -```shell -mkdir -p <web-base>/static/docs/reference/generated/kubernetes-api/v1.<minor-version> -mkdir -p <web-base>/static/docs/reference/generated/kubernetes-api/v1.<minor-version>/css -mkdir -p <web-base>/static/docs/reference/generated/kubernetes-api/v1.<minor-version>/fonts -``` - -<!-- -## Copying the generated docs to the kubernetes/website repository ---> -## 将生成的文档复制到 kubernetes/website 仓库 - -<!-- -Run the following command in `<rdocs-base>` to copy the generated files to -your local kubernetes/website repository: ---> -在 `<rdocs-base>` 目录中运行以下命令，将生成的文件复制到本地 kubernetes/website 仓库。 - -```shell -make copyapi -``` - -<!-- -Go to the base of your local kubernetes/website repository, and -see which files have been modified: ---> -进入 kubernetes/website 仓库的本地主目录，并查看已修改的文件： +进入本地 `<web-base>` 目录，检查哪些文件被更改： ```shell cd <web-base> git status ``` -<!-- -The output shows the modified files: ---> -输出显示修改后的文件： +<!-- The output is similar to: --> +输出类似于： ``` -static/docs/reference/generated/kubernetes-api/v1.15/css/bootstrap.min.css -static/docs/reference/generated/kubernetes-api/v1.15/css/font-awesome.min.css -static/docs/reference/generated/kubernetes-api/v1.15/css/stylesheet.css -static/docs/reference/generated/kubernetes-api/v1.15/fonts/FontAwesome.otf -static/docs/reference/generated/kubernetes-api/v1.15/fonts/fontawesome-webfont.eot -static/docs/reference/generated/kubernetes-api/v1.15/fonts/fontawesome-webfont.svg -static/docs/reference/generated/kubernetes-api/v1.15/fonts/fontawesome-webfont.ttf -static/docs/reference/generated/kubernetes-api/v1.15/fonts/fontawesome-webfont.woff -static/docs/reference/generated/kubernetes-api/v1.15/fonts/fontawesome-webfont.woff2 -static/docs/reference/generated/kubernetes-api/v1.15/index.html -static/docs/reference/generated/kubernetes-api/v1.15/jquery.scrollTo.min.js -static/docs/reference/generated/kubernetes-api/v1.15/navData.js -static/docs/reference/generated/kubernetes-api/v1.15/scroll.js +static/docs/reference/generated/kubernetes-api/{{< param "version" >}}/css/bootstrap.min.css +static/docs/reference/generated/kubernetes-api/{{< param "version" >}}/css/font-awesome.min.css +static/docs/reference/generated/kubernetes-api/{{< param "version" >}}/css/stylesheet.css +static/docs/reference/generated/kubernetes-api/{{< param "version" >}}/fonts/FontAwesome.otf +static/docs/reference/generated/kubernetes-api/{{< param "version" >}}/fonts/fontawesome-webfont.eot +static/docs/reference/generated/kubernetes-api/{{< param "version" >}}/fonts/fontawesome-webfont.svg +static/docs/reference/generated/kubernetes-api/{{< param "version" >}}/fonts/fontawesome-webfont.ttf +static/docs/reference/generated/kubernetes-api/{{< param "version" >}}/fonts/fontawesome-webfont.woff +static/docs/reference/generated/kubernetes-api/{{< param "version" >}}/fonts/fontawesome-webfont.woff2 +static/docs/reference/generated/kubernetes-api/{{< param "version" >}}/index.html +static/docs/reference/generated/kubernetes-api/{{< param "version" >}}/js/jquery.scrollTo.min.js +static/docs/reference/generated/kubernetes-api/{{< param "version" >}}/js/navData.js +static/docs/reference/generated/kubernetes-api/{{< param "version" >}}/js/scroll.js ``` <!-- ## Updating the API reference index pages + +When generating reference documentation for a new release, update the file, +`<web-base>/content/en/docs/reference/kubernetes-api/api-index.md` with the new +version number. --> ## 更新 API 参考索引页面 +在为新发行版本生成参考文档时，需要更新下面的文件，使之包含新的版本号： +`<web-base>/content/en/docs/reference/kubernetes-api/api-index.md`。 -<!-- -* Open `<web-base>/content/en/docs/reference/kubernetes-api/index.md` for editing, and update the API reference - version number. For example: +<!-- +* Open `<web-base>/content/en/docs/reference/kubernetes-api/api-index.md` for editing, + and update the API reference version number. For example: + + ``` + title: v1.17 + [Kubernetes API v1.17](/docs/reference/generated/kubernetes-api/v1.17/) + ``` --> -* 打开 `<web-base>/content/en/docs/reference/kubernetes-api/index.md` 文件进行编辑，并且更新 API 参考版本号。例如： +* 打开并编辑 `<web-base>/content/en/docs/reference/kubernetes-api/api-index.md`， + API 参考的版本号。例如： ``` - --- - title: v1.15 - --- - - [Kubernetes API v1.15](/docs/reference/generated/kubernetes-api/v1.15/) + title: v1.17 + [Kubernetes API v1.17](/docs/reference/generated/kubernetes-api/v1.17/) ``` - -<!-- +<!-- * Open `<web-base>/content/en/docs/reference/_index.md` for editing, and add a - new link for the latest API reference. Remove the oldest API reference version. - There should be five links to the most recent API references. + new link for the latest API reference. Remove the oldest API reference version. + There should be five links to the most recent API references. --> -* 打开 `<web-base>/content/en/docs/reference/_index.md` 文件进行编辑，并添加新链接以获取最新的 API 参考。移除最旧的 API 参考版本。应该有五个指向最新 API 参考的链接。 - +* 打开编辑 `<web-base>/content/en/docs/reference/_index.md`，添加指向最新 API 参考 + 的链接，删除最老的 API 版本。 + 通常保留最近的五个版本的 API 参考的链接。 <!-- ## Locally test the API reference ---> -## 在本地测试 API 参考 -<!-- Publish a local version of the API reference. Verify the [local preview](http://localhost:1313/docs/reference/generated/kubernetes-api/v1.15/). --> +## 在本地测试 API 参考 + 发布 API 参考的本地版本。 -验证 [本地预览](http://localhost:1313/docs/reference/generated/kubernetes-api/v1.15/)。 +检查[本地预览](http://localhost:1313/docs/reference/generated/kubernetes-api/v1.15/)。 ```shell cd <web-base> @@ -333,33 +271,32 @@ make docker-serve <!-- ## Commit the changes + +In `<web-base>` run `git add` and `git commit` to commit the change. --> ## 提交更改 -<!-- -In `<web-base>` run `git add` and `git commit` to commit the change. --> 在 `<web-base>` 中运行 `git add` 和 `git commit` 来提交更改。 <!-- Submit your changes as a -[pull request](/docs/contribute/start/) to the +[pull request](/docs/contribute/new-content/open-a-pr/) to the [kubernetes/website](https://github.com/kubernetes/website) repository. Monitor your pull request, and respond to reviewer comments as needed. Continue to monitor your pull request until it has been merged. --> -将您的更改[创建 PR](/docs/contribute/start/) 提交到 [kubernetes/website](https://github.com/kubernetes/website) 仓库。监视您提交的 PR，并根据需要回复 reviewer 的评论。继续监视您的 PR，直到合并为止。 - - +基于你所生成的更改[创建 PR](/zh/docs/contribute/new-content/open-a-pr/)， +提交到 [kubernetes/website](https://github.com/kubernetes/website) 仓库。 +监视您提交的 PR，并根据需要回复 reviewer 的评论。继续监视您的 PR，直到合并为止。 ## {{% heading "whatsnext" %}} - <!-- -* [Generating Reference Docs for Kubernetes Components and Tools](/docs/home/contribute/generated-reference/kubernetes-components/) -* [Generating Reference Documentation for kubectl Commands](/docs/home/contribute/generated-reference/kubectl/) -* [Generating Reference Documentation for the Kubernetes Federation API](/docs/home/contribute/generated-reference/federation-api/) +* [Generating Reference Documentation Quickstart](/docs/contribute/generate-ref-docs/quickstart/) +* [Generating Reference Docs for Kubernetes Components and Tools](/docs/contribute/generate-ref-docs/kubernetes-components/) +* [Generating Reference Documentation for kubectl Commands](/docs/contribute/generate-ref-docs/kubectl/) --> -* [为 Kubernetes 组件和工具生成参考文档](/docs/home/contribute/generated-reference/kubernetes-components/) -* [为 kubectl 命令集生成参考文档](/docs/home/contribute/generated-reference/kubectl/) -* [为 Kubernetes 联邦 API 生成参考文档](/docs/home/contribute/generated-reference/federation-api/) +* [生成参考文档快速入门](/zh/docs/contribute/generate-ref-docs/quickstart/) +* [为 Kubernetes 组件和工具生成参考文档](/zh/docs/contribute/generate-ref-docs/kubernetes-components/) +* [为 kubectl 命令集生成参考文档](/zh/docs/contribute/generate-ref-docs/kubectl/) diff --git a/content/zh/docs/contribute/generate-ref-docs/kubernetes-components.md b/content/zh/docs/contribute/generate-ref-docs/kubernetes-components.md index 676575d2cc..0ca9d48df6 100644 --- a/content/zh/docs/contribute/generate-ref-docs/kubernetes-components.md +++ b/content/zh/docs/contribute/generate-ref-docs/kubernetes-components.md @@ -1,413 +1,50 @@ --- -title: 为 Kubernetes 组件和工具生成参考页面 +title: 为 Kubernetes 组件和工具生成参考文档 content_type: task +weight: 120 --- - <!-- ---- title: Generating Reference Pages for Kubernetes Components and Tools content_type: task ---- +weight: 120 --> <!-- overview --> <!-- -This page shows how to use the `update-imported-docs` tool to generate -reference documentation for tools and components in the -[Kubernetes](https://github.com/kubernetes/kubernetes) and -[Federation](https://github.com/kubernetes/federation) repositories. +This page shows how to build the Kubernetes component and tool reference pages. --> -本页面展示了如何使用 `update-imported-docs` 工具来为 [Kubernetes](https://github.com/kubernetes/kubernetes) 和 [Federation](https://github.com/kubernetes/federation) 仓库中的工具和组件生成参考文档。 - - +本页面描述如何构造 Kubernetes 组件和工具的参考文档。 ## {{% heading "prerequisites" %}} - <!-- -* You need a machine that is running Linux or macOS. +Start with the [Prerequisites section](/docs/contribute/generate-ref-docs/quickstart/#before-you-begin) +in the Reference Documentation Quickstart guide. --> - -* 你需要一个运行着 Linux 或 macOS 操作系统的机器。 - -<!-- -* You need to have this software installed: - - * [Git](https://git-scm.com/book/en/v2/Getting-Started-Installing-Git) - - * [Golang](https://golang.org/doc/install) version 1.9 or later - - * [make](https://www.gnu.org/software/make/) - - * [gcc compiler/linker](https://gcc.gnu.org/) ---> - -* 你需要安装以下软件： - - * [Git](https://git-scm.com/book/en/v2/Getting-Started-Installing-Git) - - * 1.9或更高版本的 [Golang](https://golang.org/doc/install) - - * [make](https://www.gnu.org/software/make/) - - * [gcc compiler/linker](https://gcc.gnu.org/) - -<!-- -* Your `$GOPATH` environment variable must be set. ---> - -* 在环境变量中设置 `$GOPATH`。 - -<!-- -* You need to know how to create a pull request to a GitHub repository. -Typically, this involves creating a fork of the repository. For more -information, see -[Creating a Documentation Pull Request](/docs/home/contribute/create-pull-request/). ---> - -* 你需要知道如何在一个 GitHub 项目仓库中创建一个 PR。一般来说，这涉及到创建仓库的一个分支。想了解更多信息，请参见[创建一个文档 PR](/docs/home/contribute/create-pull-request/)。 - - +阅读参考文档快速入门指南中的[准备工作](/zh/docs/contribute/generate-ref-docs/quickstart/#before-you-begin)节。 <!-- steps --> <!-- -## Getting two repositories +Follow the [Reference Documentation Quickstart](/docs/contribute/generate-ref-docs/quickstart/) +to generate the Kubernetes component and tool reference pages. --> - -## 下载两个仓库 - -<!-- -If you don't already have the `kubernetes/website` repository, get it now: ---> - -如果你还没有下载过 `kubernetes/website` 仓库，现在下载： - -```shell -mkdir $GOPATH/src -cd $GOPATH/src -go get github.com/kubernetes/website -``` - -<!-- -Determine the base directory of your clone of the -[kubernetes/website](https://github.com/kubernetes/website) repository. -For example, if you followed the preceding step to get the repository, -your base directory is `$GOPATH/src/github.com/kubernetes/website.` -The remaining steps refer to your base directory as `<web-base>`. ---> - -确定 [kubernetes/website](https://github.com/kubernetes/website) 仓库的本地主目录。例如，如果按照前面的步骤来获取该仓库，则主目录是 `$GOPATH/src/github.com/kubernetes/website`。下文将该目录称为 `<web-base>`。 - -<!-- -If you plan on making changes to the ref docs, and if you don't already have -the `kubernetes/kubernetes` repository, get it now: ---> - -如果你想对参考文档进行修改，但是你还没下载过 `kubernetes/kubernetes` 仓库，现在下载： - -```shell -mkdir $GOPATH/src -cd $GOPATH/src -go get github.com/kubernetes/kubernetes -``` - -<!-- -Determine the base directory of your clone of the -[kubernetes/kubernetes](https://github.com/kubernetes/kubernetes) repository. -For example, if you followed the preceding step to get the repository, -your base directory is `$GOPATH/src/github.com/kubernetes/kubernetes.` -The remaining steps refer to your base directory as `<k8s-base>`. ---> - -确定 [kubernetes/kubernetes](https://github.com/kubernetes/kubernetes) 仓库的本地主目录。例如，如果按照前面的步骤来获取该仓库，则主目录是 `$GOPATH/src/github.com/kubernetes/kubernetes`。下文将该目录称为 `<k8s-base>`。 - -{{< note >}} -<!-- -If you only need to generate, but not change, the reference docs, you don't need to -manually get the `kubernetes/kubernetes` repository. When you run the `update-imported-docs` -tool, it automatically clones the `kubernetes/kubernetes` repository. ---> - -如果你只想生成参考文档，而不需要修改，则不需要手动下载 `kubernetes/kubernetes` 仓库。当你运行 `update-imported-docs` 工具时，它会自动克隆 `kubernetes/kubernetes` 仓库。 -{{< /note >}} - -<!-- -## Editing the Kubernetes source code ---> - -## 编辑 Kubernetes 源码 - -<!-- -The reference documentation for the Kubernetes components and tools is automatically -generated from the Kubernetes source code. If you want to change the reference documentation, -the first step is to change one or more comments in the Kubernetes source code. Make the -change in your local kubernetes/kubernetes repository, and then submit a pull request to -the master branch of -[github.com/kubernetes/kubernetes](https://github.com/kubernetes/kubernetes). ---> - -Kubernetes 组件和工具的参考文档是基于 Kubernetes 源码自动生成的。如果想要修改参考文档，可以从修改 Kubernetes 源码中的一个或多个注释开始。在本地 kubernetes/kubernetes 仓库中进行修改，然后向 [github.com/kubernetes/kubernetes](https://github.com/kubernetes/kubernetes) 的 master 分支提交 PR。 - -<!-- -[PR 56942](https://github.com/kubernetes/kubernetes/pull/56942) -is an example of a pull request that makes changes to comments in the Kubernetes -source code. ---> - -[PR 56942](https://github.com/kubernetes/kubernetes/pull/56942) 是一个对 Kubernetes 源码中的注释进行修改的 PR 示例。 - -<!-- -Monitor your pull request, and respond to reviewer comments. Continue to monitor -your pull request until it is merged into the master branch of the -`kubernetes/kubernetes` repository. ---> - -跟踪你的 PR，并回应评审人的评论。继续跟踪你的 PR，直到它合入到 `kubernetes/kubernetes` 仓库的 master 分支中。 - -<!-- -## Cherry picking your change into a release branch ---> - -## 以 cherry-pick 方式将你的修改合入已发布分支 - -<!-- -Your change is now in the master branch, which is used for development of the next -Kubernetes release. If you want your change to appear in the docs for a Kubernetes -version that has already been released, you need to propose that your change be cherry -picked into the release branch. ---> - -你的修改已合入 master 分支中，该分支用于开发下一个 Kubernetes 版本。如果你希望修改部分出现在已发布的 Kubernetes 版本文档中，则需要提议将它们以 cherry-pick 方式合入已发布分支。 - -<!-- -For example, suppose the master branch is being used to develop Kubernetes 1.10, and -you want to backport your change to the release-1.9 branch. For instructions on how -to do this, see -[Propose a Cherry Pick](https://github.com/kubernetes/community/blob/master/contributors/devel/cherry-picks.md). ---> - -例如，假设 master 分支正用于开发 Kubernetes 1.10 版本，而你希望将修改合入到已发布的 1.9 版本分支。相关的操作指南，请参见 [提议一个 cherry-pick 合入](https://github.com/kubernetes/community/blob/master/contributors/devel/cherry-picks.md)。 - -<!-- -Monitor your cherry-pick pull request until it is merged into the release branch. ---> - -跟踪你的 cherry-pick PR，直到它合入到已发布分支中。 - -{{< note >}} -<!-- -Proposing a cherry pick requires that you have permission to set a label -and a milestone in your pull request. If you don’t have those permissions, you will -need to work with someone who can set the label and milestone for you. ---> - -提议一个 cherry-pick 合入，需要你有在 PR 中设置标签和里程碑的权限。如果你没有，你需要与有权限为你设置标签和里程碑的人合作完成。 -{{< /note >}} - -<!-- -## Overview of update-imported-docs ---> - -## update-imported-docs 概述 - -<!-- -The `update-imported-docs` tool is located in the `kubernetes/website/update-imported-docs/` -directory. The tool performs the following steps: ---> - -`update-imported-docs` 工具在 `kubernetes/website/update-imported-docs/` 目录下。它执行以下步骤： - -<!-- -1. Clones the related repositories specified in a configuration file. For the - purpose of generating reference docs, the repositories that are cloned by - default are `kubernetes-incubator/reference-docs` and `kubernetes/federation`. -1. Runs commands under the cloned repositories to prepare the docs generator and - then generates the Markdown files. -1. Copies the generated Markdown files to a local clone of the `kubernetes/website` - repository under locations specified in the configuration file. ---> - -1. 克隆配置文件中指定的相关仓库。为了生成参考文档，默认情况下克隆的仓库是 `kubernetes-incubator/reference-docs` 和 `kubernetes/federation`。 -1. 在克隆出的仓库下运行命令来准备文档生成器，然后生成 Markdown 文件。 -1. 将生成的 Markdown 文件复制到配置文件中指定的 `kubernetes/website` 仓库的本地目录中。 - -<!-- -When the Markdown files are in your local clone of the `kubernetes/website` -repository, you can submit them in a -[pull request](/docs/home/contribute/create-pull-request/) -to `kubernetes/website`. ---> - -当 Markdown 文件放入 `kubernetes/website` 仓库的本地目录中后，你就可以创建 [PR](/docs/home/contribute/create-pull-request/) 将它们提交到 `kubernetes/website`。 - -<!-- -## Customizing the reference.yml config file ---> - -## 自定义 reference.yml 配置文件 - -<!-- -Open `<web-base>/update-imported-docs/reference.yml` for editing. -Do not change the content for the `generate-command` entry unless you understand -what it is doing and need to change the specified release branch. ---> - -打开 `<web-base>/update-imported-docs/reference.yml` 进行编辑。不要修改 `generate-command` 条目的内容，除非你了解它的作用，并且需要修改指定的已发布分支。 - -```yaml -repos: -- name: reference-docs - remote: https://github.com/kubernetes-sigs/reference-docs.git - # This and the generate-command below needs a change when reference-docs has - # branches properly defined - branch: master - generate-command: | - cd $GOPATH - git clone https://github.com/kubernetes/kubernetes.git src/k8s.io/kubernetes - cd src/k8s.io/kubernetes - git checkout release-1.17 - make generated_files - cp -L -R vendor $GOPATH/src - rm -r vendor - cd $GOPATH - go get -v github.com/kubernetes-sigs/reference-docs/gen-compdocs - cd src/github.com/kubernetes-sigs/reference-docs/ - make comp -``` - -<!-- -In reference.yml, the `files` field is a list of `src` and `dst` fields. The `src` field -specifies the location of a generated Markdown file, and the `dst` field specifies -where to copy this file in the cloned `kubernetes/website` repository. -For example: ---> - -在 reference.yml 中，`files` 字段是 `src` 和 `dst` 字段的列表。`src` 字段指定生成的 Markdown 文件的位置，而 `dst` 字段指定将此文件复制到 `kubernetes/website` 仓库的本地目录的哪个位置。例如： - -```yaml -repos: -- name: reference-docs - remote: https://github.com/kubernetes-incubator/reference-docs.git - files: - - src: gen-compdocs/build/kube-apiserver.md - dst: content/en/docs/reference/command-line-tools-reference/kube-apiserver.md - ... -``` - -<!-- -Note that when there are many files to be copied from the same source directory -to the same destination directory, you can use wildcards in the value given to -`src` and you can just provide the directory name as the value for `dst`. -For example: ---> - -注意，当有许多文件要从同一个源目录复制到同一个目标目录时，可以使用通配符给 `src` 赋值，而使用目录名给 `dst` 赋值。例如： - -```shell - files: - - src: gen-compdocs/build/kubeadm*.md - dst: content/en/docs/reference/setup-tools/kubeadm/generated/ -``` - -<!-- -## Running the update-imported-docs tool ---> - -## 运行 update-imported-docs 工具 - -<!-- -After having reviewed and/or customized the `reference.yaml` file, you can run -the `update-imported-docs` tool: ---> - -在检查与或自定义 `reference.yaml` 文件后，运行 `update-imported-docs` 工具： - -```shell -cd <web-base>/update-imported-docs -./update-imported-docs reference.yml -``` - -<!-- -## Adding and committing changes in kubernetes/website ---> - -## 在 kubernetes/website 中添加和提交修改 - -<!-- -List the files that were generated and copied to the `kubernetes/website` -repository: ---> - -列出生成并准备合入到 `kubernetes/website` 仓库中的文件： - -``` -cd <web-base> -git status -``` - -<!-- -The output shows the new and modified files. For example, the output -might look like this: ---> - -输出展示了新增和修改的文件。例如，输出可能如下所示： - -```shell -... - - modified: content/en/docs/reference/command-line-tools-reference/cloud-controller-manager.md - modified: content/en/docs/reference/command-line-tools-reference/federation-apiserver.md - modified: content/en/docs/reference/command-line-tools-reference/federation-controller-manager.md - modified: content/en/docs/reference/command-line-tools-reference/kube-apiserver.md - modified: content/en/docs/reference/command-line-tools-reference/kube-controller-manager.md - modified: content/en/docs/reference/command-line-tools-reference/kube-proxy.md - modified: content/en/docs/reference/command-line-tools-reference/kube-scheduler.md -... -``` - -<!-- -Run `git add` and `git commit` to commit the files. ---> - -运行 `git add` 和 `git commit` 将提交上述文件。 - -<!-- -## Creating a pull request ---> - -## 创建 PR - -<!-- -Create a pull request to the `kubernetes/website` repository. Monitor your -pull request, and respond to review comments as needed. Continue to monitor -your pull request until it is merged. ---> - -对 `kubernetes/website` 仓库创建 PR。跟踪你的 PR，并根据需要回应评审人的评论。继续跟踪你的 PR，直到它被合入。 - -<!-- -A few minutes after your pull request is merged, your updated reference -topics will be visible in the -[published documentation](/docs/home/). ---> - -在 PR 合入的几分钟后，你更新的参考主题将出现在[已发布文档](/docs/home/)中。 - - +按照[参考文档快速入门](/zh/docs/contribute/generate-ref-docs/quickstart/) +指引，生成 Kubernetes 组件和工具的参考文档。 ## {{% heading "whatsnext" %}} - <!-- -* [Generating Reference Documentation for kubectl Commands](/docs/home/contribute/generated-reference/kubectl/) -* [Generating Reference Documentation for the Kubernetes API](/docs/home/contribute/generated-reference/kubernetes-api/) -* [Generating Reference Documentation for the Kubernetes Federation API](/docs/home/contribute/generated-reference/federation-api/) +* [Generating Reference Documentation Quickstart](/docs/contribute/generate-ref-docs/quickstart/) +* [Generating Reference Documentation for kubectl Commands](/docs/contribute/generate-ref-docs/kubectl/) +* [Generating Reference Documentation for the Kubernetes API](/docs/contribute/generate-ref-docs/kubernetes-api/) +* [Contributing to the Upstream Kubernetes Project for Documentation](/docs/contribute/generate-ref-docs/contribute-upstream/) --> -* [为 kubectl 命令集生成参考文档](/docs/home/contribute/generated-reference/kubectl/) -* [为 Kubernetes API 生成参考文档](/docs/home/contribute/generated-reference/kubernetes-api/) -* [为 Kubernetes 联邦 API 生成参考文档](/docs/home/contribute/generated-reference/federation-api/) +* [生成参考文档快速入门](/zh/docs/contribute/generate-ref-docs/quickstart/) +* [为 kubectll 命令生成参考文档](/zh/docs/contribute/generate-ref-docs/kubectl/) +* [为 Kubernetes API 生成参考文档](/zh/docs/contribute/generate-ref-docs/kubernetes-api/) +* [为上游 Kubernetes 项目做贡献以改进文档](/zh/docs/contribute/generate-ref-docs/contribute-upstream/) diff --git a/content/zh/docs/contribute/generate-ref-docs/prerequisites-ref-docs.md b/content/zh/docs/contribute/generate-ref-docs/prerequisites-ref-docs.md new file mode 100644 index 0000000000..4a52bfa997 --- /dev/null +++ b/content/zh/docs/contribute/generate-ref-docs/prerequisites-ref-docs.md @@ -0,0 +1,45 @@ +<!-- +### Requirements: + +- You need a machine that is running Linux or macOS. + +- You need to have these tools installed: + + - [Python](https://www.python.org/downloads/) v3.7.x + - [Git](https://git-scm.com/book/en/v2/Getting-Started-Installing-Git) + - [Golang](https://golang.org/doc/install) version 1.13+ + - [Pip](https://pypi.org/project/pip/) used to install PyYAML + - [PyYAML](https://pyyaml.org/) v5.1.2 + - [make](https://www.gnu.org/software/make/) + - [gcc compiler/linker](https://gcc.gnu.org/) + - [Docker](https://docs.docker.com/engine/installation/) (Required only for `kubectl` command reference) +--> + +### 需求 {#requirements} + +- 你需要一台 Linux 或 macOS 机器。 + +- 你需要安装以下工具： + + - [Python](https://www.python.org/downloads/) v3.7.x + - [Git](https://git-scm.com/book/en/v2/Getting-Started-Installing-Git) + - [Golang](https://golang.org/doc/install) 1.13+ 版本 + - 用来安装 PyYAML 的 [Pip](https://pypi.org/project/pip/) + - [PyYAML](https://pyyaml.org/) v5.1.2 + - [make](https://www.gnu.org/software/make/) + - [gcc compiler/linker](https://gcc.gnu.org/) + - [Docker](https://docs.docker.com/engine/installation/) （仅用于 `kubectl` 命令参考） + +<!-- +- Your `PATH` environment variable must include the required build tools, such as the `Go` binary and `python`. + +- You need to know how to create a pull request to a GitHub repository. + This involves creating your own fork of the repository. For more + information, see [Work from a local clone](/docs/contribute/intermediate/#work_from_a_local_clone). +--> +- 你的 `PATH` 环境变量必须包含所需要的构建工具，例如 `Go` 程序和 `python`。 + +- 你需要知道如何为一个 GitHub 仓库创建拉取请求（PR）。 + 这牵涉到创建仓库的派生（fork）副本。 + 有关信息可进一步查看[基于本地副本开展工作](/docs/contribute/intermediate/#work_from_a_local_clone)。 + diff --git a/content/zh/docs/contribute/generate-ref-docs/quickstart.md b/content/zh/docs/contribute/generate-ref-docs/quickstart.md new file mode 100644 index 0000000000..0c97a99163 --- /dev/null +++ b/content/zh/docs/contribute/generate-ref-docs/quickstart.md @@ -0,0 +1,405 @@ +--- +title: 快速入门 +content_type: task +weight: 40 +--- +<!-- +title: Quickstart +content_type: task +weight: 40 +--> + +<!-- overview --> + +<!-- +This page shows how to use the `update-imported-docs` script to generate +the Kubernetes reference documentation. The script automates +the build setup and generates the reference documentation for a release. +--> +本页讨论如何使用 `update-imported-docs` 脚本来生成 Kubernetes 参考文档。 +此脚本将构建的配置过程自动化，并为某个发行版本生成参考文档。 + +## {{% heading "prerequisites" %}} + +{{< include "prerequisites-ref-docs.md" >}} + +<!-- steps --> +<!-- +## Getting the docs repository + +Make sure your `website` fork is up-to-date with the `kubernetes/website` master and clone +your `website` fork. +--> +## 获取文档仓库 {#getting-the-docs-repository} + +确保你的 `website` 派生仓库与 `kubernetes/website` 主分支一致，并克隆 +你的派生仓库。 + +```shell +mkdir github.com +cd github.com +git clone git@github.com:<your_github_username>/website.git +``` + +<!-- +Determine the base directory of your clone. For example, if you followed the +preceding step to get the repository, your base directory is +`github.com/website.` The remaining steps refer to your base directory as +`<web-base>`. + +{{< note>}} +If you want to change the content of the component tools and API reference, +see the [contributing upstream guide](/docs/contribute/generate-ref-docs/contribute-upstream). +{{< /note >}} +--> +确定你的克隆副本的根目录。例如，如果你按照前面的步骤获取了仓库，你的根目录 +会是 `github.com/website`。接下来的步骤中，`<web-base>` 用来指代你的根目录。 + +{{< note>}} +如果你希望更改构建工具和 API 参考资料，可以阅读 +[上游贡献指南](/zh/docs/contribute/generate-ref-docs/contribute-upstream). +{{< /note >}} + +<!-- +## Overview of update-imported-docs + +The `update-imported-docs` script is located in the `<web-base>/update-imported-docs/` +directory. + +The script builds the following references: + +* Component and tool reference pages +* The `kubectl` command reference +* The Kubernetes API reference +--> +## update-imported-docs 的概述 + +脚本 `update-imported-docs` 位于 `<web-base>/update-imported-docs/` 目录下， +能够生成以下参考文档： + +* Kubernetes 组件和工具的参考页面 +* `kubectl` 命令参考文档 +* Kubernetes API 参考文档 + +<!-- +The `update-imported-docs` script generates the Kubernetes reference documentation +from the Kubernetes source code. The script creates a temporary directory +under `/tmp` on your machine and clones the required repositories: `kubernetes/kubernetes` and +`kubernetes-sigs/reference-docs` into this directory. +The script sets your `GOPATH` to this temporary directory. +Three additional environment variables are set: + +* `K8S_RELEASE` +* `K8S_ROOT` +* `K8S_WEBROOT` +--> +脚本 `update-imported-docs` 基于 Kubernetes 源代码生成参考文档。 +过程中会在你的机器的 `/tmp` 目录下创建临时目录，克隆所需要的仓库 +`kubernetes/kubernetes` 和 `kubernetes-sigs/reference-docs` 到此临时目录。 +脚本会将 `GOPATH` 环境变量设置为指向此临时目录。 +此外，脚本会设置三个环境变量： + +* `K8S_RELEASE` +* `K8S_ROOT` +* `K8S_WEBROOT` + +<!-- +The script requires two arguments to run successfully: + +* A YAML configuration file (`reference.yml`) +* A release version, for example:`1.17` + +The configuration file contains a `generate-command` field. +The `generate-command` field defines a series of build instructions +from `kubernetes-sigs/reference-docs/Makefile`. The `K8S_RELEASE` variable +determines the version of the release. +--> +脚本需要两个参数才能成功运行： + +* 一个 YAML 配置文件（`reference.yml`） +* 一个发行版本字符串，例如：`1.17` + +配置文件中包含 `generate-command` 字段，其中定义了一系列来自于 +`kubernetes-sigs/reference-docs/Makefile` 的构建指令。 +变量 `K8S_RELEASE` 用来确定所针对的发行版本。 + +<!-- +The `update-imported-docs` script performs the following steps: + +1. Clones the related repositories specified in a configuration file. For the + purpose of generating reference docs, the repository that is cloned by + default is `kubernetes-sigs/reference-docs`. +1. Runs commands under the cloned repositories to prepare the docs generator and + then generates the HTML and Markdown files. +1. Copies the generated HTML and Markdown files to a local clone of the `<web-base>` + repository under locations specified in the configuration file. +1. Updates `kubectl` command links from `kubectl`.md to the refer to + the sections in the `kubectl` command reference. +--> +脚本 `update-imported-docs` 执行以下步骤： + +1. 克隆配置文件中所指定的相关仓库。就生成参考文档这一目的而言，要克隆的 + 仓库默认为 `kubernetes-sigs/reference-docs`。 +1. 在所克隆的仓库下运行命令，准备文档生成器，之后生成 HTML 和 Markdown 文件。 +1. 将所生成的 HTML 和 Markdown 文件复制到 `<web-base>` 本地克隆副本中， + 放在配置文件中所指定的目录下。 +1. 更新 `kubectl.md` 文件中对 `kubectl` 命令文档的链接，使之指向 `kubectl` + 命令参考中对应的节区。 + +<!-- +When the generated files are in your local clone of the `<web-base>` +repository, you can submit them in a [pull request](/docs/contribute/start/) +to `<web-base>`. +--> +当所生成的文件已经被放到 `<web-base>` 目录下，你就可以将其提交到你的派生副本中， +并基于所作提交发起[拉取请求（PR）](/docs/contribute/start/)到 k/website 仓库。 + +<!-- +## Configuration file format + +Each configuration file may contain multiple repos that will be imported together. When +necessary, you can customize the configuration file by manually editing it. You +may create new config files for importing other groups of documents. +The following is an example of the YAML configuration file: +--> +## 配置文件格式 {#configuration-file-format} + +每个配置文件可以包含多个被导入的仓库。当必要时，你可以通过手工编辑此文件进行定制。 +你也可以通过创建新的配置文件来导入其他文档集合。 +下面是 YAML 配置文件的一个例子： + +```yaml +repos: +- name: community + remote: https://github.com/kubernetes/community.git + branch: master + files: + - src: contributors/devel/README.md + dst: docs/imported/community/devel.md + - src: contributors/guide/README.md + dst: docs/imported/community/guide.md +``` + +<!-- +Single page Markdown documents, imported by the tool, must adhere to +the [Documentation Style Guide](/docs/contribute/style/style-guide/). +--> +通过工具导入的单页面的 Markdown 文档必须遵从 +[文档样式指南](/zh/docs/contribute/style/style-guide/)。 + +<!-- +## Customizing reference.yml + +Open `<web-base>/update-imported-docs/reference.yml` for editing. +Do not change the content for the `generate-command` field unless you understand +how the command is used to build the references. +You should not need to update `reference.yml`. At times, changes in the +upstream source code, may require changes to the configuration file +(for example: golang version dependencies and third-party library changes). +If you encounter build issues, contact the SIG-Docs team on the +[#sig-docs Kubernetes Slack channel](https://kubernetes.slack.com). +--> + +## 定制 reference.yml + +打开 `<web-base>/update-imported-docs/reference.yml` 文件进行编辑。 +在不了解参考文档构造命令的情况下，不要更改 `generate-command` 字段的内容。 +你一般不需要更新 `reference.yml` 文件。不过也有时候上游的源代码发生变化， +导致需要对配置文件进行更改（例如：Golang 版本依赖或者第三方库发生变化）。 +如果你遇到类似问题，请在 [Kubernetes Slack 的 #sig-docs 频道](https://kubernetes.slack.com) +联系 SIG-Docs 团队。 + +<!-- +{{< note >}} +The `generate-command` is an optional entry, which can be used to run a +given command or a short script to generate the docs from within a repository. +{{< /note >}} + +In `reference.yml`, `files` contains a list of `src` and `dst` fields. +The `src` field contains the location of a generated Markdown file in the cloned +`kubernetes-sigs/reference-docs` build directory, and the `dst` field specifies +where to copy this file in the cloned `kubernetes/website` repository. +For example: +--> + +{{< note >}} +注意，`generate-command` 是一个可选项，用来运行指定命令或者短脚本以在仓库 +内生成文档。 +{{< /note >}} + +在 `reference.yml` 文件中，`files` 属性包含了一组 `src` 和 `dst` 字段。 +`src` 字段给出在所克隆的 `kubernetes-sigs/reference-docs` 构造目录中生成的 +Markdown 文件的位置，而 `dst` 字段则给出了对应文件要复制到的、所克隆的 +`kubernetes/website` 仓库中的位置。例如： + +```yaml +repos: +- name: reference-docs + remote: https://github.com/kubernetes-sigs/reference-docs.git + files: + - src: gen-compdocs/build/kube-apiserver.md + dst: content/en/docs/reference/command-line-tools-reference/kube-apiserver.md + ... +``` + +<!-- +Note that when there are many files to be copied from the same source directory +to the same destination directory, you can use wildcards in the value given to +`src`. You must provide the directory name as the value for `dst`. +For example: +--> +注意，如果从同一源目录中有很多文件要复制到目标目录，你可以在为 `src` 所设置的 +值中使用通配符。这时，为 `dst` 所设置的值必须是目录名称。例如： + +```yaml + files: + - src: gen-compdocs/build/kubeadm*.md + dst: content/en/docs/reference/setup-tools/kubeadm/generated/ +``` + +<!-- +## Running the update-imported-docs tool + +You can run the `update-imported-docs` tool as follows: +--> +## 运行 update-imported-docs 工具 + +你可以用如下方式运行 `update-imported-docs` 工具： + +```shell +cd <web-base>/update-imported-docs +./update-imported-docs <configuration-file.yml> <release-version> +``` + +<!-- For example: --> +例如： + +```shell +./update-imported-docs reference.yml 1.17 +``` + +<!-- Revisit: is the release configuration used --> +<!-- ## Fixing Links + +The `release.yml` configuration file contains instructions to fix relative links. +To fix relative links within your imported files, set the`gen-absolute-links` +property to `true`. You can find an example of this in +[`release.yml`](https://github.com/kubernetes/website/blob/master/update-imported-docs/release.yml). +--> +## 修复链接 + +配置文件 `release.yml` 中包含用来修复相对链接的指令。 +若要修复导入文件中的相对链接，将 `gen-absolute-links` 属性设置为 `true`。 +你可以在 [`release.yml`](https://github.com/kubernetes/website/blob/master/update-imported-docs/release.yml) +文件中找到示例。 + +<!-- +## Adding and committing changes in kubernetes/website + +List the files that were generated and copied to `<web-base>`: +--> +## 添加并提交 kubernetes/website 中的变更 + +枚举新生成并复制到 `<web-base>` 的文件： + +```shell +cd <web-base> +git status +``` + +<!-- +The output shows the new and modified files. The generated output varies +depending upon changes made to the upstream source code. + +### Generated component tool files +--> +输出显示新生成和已修改的文件。取决于上游源代码的修改多少， +所生成的输出也会不同。 + +### 生成的 Kubernetes 组件文档 + +``` +content/en/docs/reference/command-line-tools-reference/cloud-controller-manager.md +content/en/docs/reference/command-line-tools-reference/kube-apiserver.md +content/en/docs/reference/command-line-tools-reference/kube-controller-manager.md +content/en/docs/reference/command-line-tools-reference/kube-proxy.md +content/en/docs/reference/command-line-tools-reference/kube-scheduler.md +content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm.md +content/en/docs/reference/kubectl/kubectl.md +``` + +<!-- ### Generated kubectl command reference files --> +### 生成的 kubectl 命令参考文件 + +``` +static/docs/reference/generated/kubectl/kubectl-commands.html +static/docs/reference/generated/kubectl/navData.js +static/docs/reference/generated/kubectl/scroll.js +static/docs/reference/generated/kubectl/stylesheet.css +static/docs/reference/generated/kubectl/tabvisibility.js +static/docs/reference/generated/kubectl/node_modules/bootstrap/dist/css/bootstrap.min.css +static/docs/reference/generated/kubectl/node_modules/highlight.js/styles/default.css +static/docs/reference/generated/kubectl/node_modules/jquery.scrollto/jquery.scrollTo.min.js +static/docs/reference/generated/kubectl/node_modules/jquery/dist/jquery.min.js +static/docs/reference/generated/kubectl/css/font-awesome.min.css +``` + +<!-- ### Generated Kubernetes API reference directories and files --> +### 生成的 Kubernetes API 参考目录与文件 + +``` +static/docs/reference/generated/kubernetes-api/{{< param "version" >}}/index.html +static/docs/reference/generated/kubernetes-api/{{< param "version" >}}/js/navData.js +static/docs/reference/generated/kubernetes-api/{{< param "version" >}}/js/scroll.js +static/docs/reference/generated/kubernetes-api/{{< param "version" >}}/js/query.scrollTo.min.js +static/docs/reference/generated/kubernetes-api/{{< param "version" >}}/css/font-awesome.min.css +static/docs/reference/generated/kubernetes-api/{{< param "version" >}}/css/bootstrap.min.css +static/docs/reference/generated/kubernetes-api/{{< param "version" >}}/css/stylesheet.css +static/docs/reference/generated/kubernetes-api/{{< param "version" >}}/fonts/FontAwesome.otf +static/docs/reference/generated/kubernetes-api/{{< param "version" >}}/fonts/fontawesome-webfont.eot +static/docs/reference/generated/kubernetes-api/{{< param "version" >}}/fonts/fontawesome-webfont.svg +static/docs/reference/generated/kubernetes-api/{{< param "version" >}}/fonts/fontawesome-webfont.ttf +static/docs/reference/generated/kubernetes-api/{{< param "version" >}}/fonts/fontawesome-webfont.woff +static/docs/reference/generated/kubernetes-api/{{< param "version" >}}/fonts/fontawesome-webfont.woff2 +``` + +<!-- +Run `git add` and `git commit` to commit the files. + +## Creating a pull request + +Create a pull request to the `kubernetes/website` repository. Monitor your +pull request, and respond to review comments as needed. Continue to monitor +your pull request until it is merged. + +A few minutes after your pull request is merged, your updated reference +topics will be visible in the +[published documentation](/docs/home/). +--> +运行 `git add` 和 `git commit` 提交文件。 + +## 创建拉取请求 {#creating-a-pull-request} + +接下来创建一个对 `kubernetes/website` 仓库的拉取请求（PR）。 +监视所创建的 PR，并根据需要对评阅意见给出反馈。 +继续监视该 PR 直到其被合并为止。 + +当你的 PR 被合并几分钟之后，你所做的对参考文档的变更就会出现 +[发布的文档](/zh/docs/home/)上。 + +## {{% heading "whatsnext" %}} + +<!-- +To generate the individual reference documentation by manually setting up the required build repositories and +running the build targets, see the following guides: + +* [Generating Reference Documentation for Kubernetes Components and Tools](/docs/contribute/generate-ref-docs/kubernetes-components/) +* [Generating Reference Documentation for kubectl Commands](/docs/contribute/generate-ref-docs/kubectl/) +* [Generating Reference Documentation for the Kubernetes API](/docs/contribute/generate-ref-docs/kubernetes-api/) +--> +要手动设置所需的构造仓库，执行构建目标，以生成各个参考文档，可参考下面的指南： + +* [为 Kubernetes 组件和工具生成参考文档](/zh/docs/contribute/generate-ref-docs/kubernetes-components/) +* [为 kubeclt 命令生成参考文档](/zh/docs/contribute/generate-ref-docs/kubectl/) +* [为 Kubernetes API 生成参考文档](/zh/docs/contribute/generate-ref-docs/kubernetes-api/) + diff --git a/content/zh/docs/contribute/intermediate.md b/content/zh/docs/contribute/intermediate.md deleted file mode 100644 index 882904ffcb..0000000000 --- a/content/zh/docs/contribute/intermediate.md +++ /dev/null @@ -1,1451 +0,0 @@ ---- -title: 中级贡献 -slug: intermediate -content_type: concept -weight: 20 -card: - name: contribute - weight: 50 ---- -<!-- ---- -title: Intermediate contributing -slug: intermediate -content_type: concept -weight: 20 -card: - name: contribute - weight: 50 ---- ---> - -<!-- overview --> - -<!-- -This page assumes that you've read and mastered the tasks in the -[start contributing](/docs/contribute/start/) topic and are ready to -learn about more ways to contribute. ---> -本文假定你已经阅读并掌握了[开始贡献](/docs/contribute/start/)中介绍的内容，想要了解更多关于贡献的内容。 - - -{{< note >}} -<!-- -Some tasks require you to use the Git command line client and other tools. ---> -有些任务需要使用 Git 命令行客户端和其他工具。 -{{< /note >}} - - - -<!-- body --> - -<!-- -Now that you've gotten your feet wet and helped out with the Kubernetes docs in -the ways outlined in the [start contributing](/docs/contribute/start/) topic, -you may feel ready to do more. These tasks assume that you have, or are willing -to gain, deeper knowledge of the following topic areas: ---> -现在，您已经熟悉了 Kubernetes 文档，并按照[开始贡献](/docs/contribute/start/)文章中介绍的方式进行了贡献，您可能已经准备好做更多的工作。这些任务假设您已经或愿意获得以下主题领域的更深入的知识: - -<!-- -- Kubernetes concepts -- Kubernetes documentation workflows -- Where and how to find information about upcoming Kubernetes features -- Strong research skills in general ---> -- Kubernetes 概念 -- Kubernetes 文档工作流程 -- 在哪里和如何找到即将推出的 Kubernetes 功能的信息 -- 较强的研究能力 - -<!-- -These tasks are not as sequential as the beginner tasks. There is no expectation -that one person does all of them all of the time. ---> -这些任务不像初学者的任务那样是顺序的。没有人期望一个人会一直做所有的事情。 - -## 评审 pull request - -<!-- -In any given week, a specific docs approver volunteers to do initial triage -and review of [pull requests and issues](#triage-and-categorize-issues). This -person is the "PR Wrangler" for the week. The schedule is maintained using the -[PR Wrangler scheduler](https://github.com/kubernetes/website/wiki/PR-Wranglers). -To be added to this list, attend the weekly SIG Docs meeting and volunteer. Even -if you are not on the schedule for the current week, you can still review pull -requests (PRs) that are not already under active review. ---> -通常，每周都会有一个特定的文档审核志愿者对 [pull requests 和 issues](#triage-and-categorize-issues) 进行分类和审核。这个人就是本周的 “PR 轮流负责人”。排班计划在 [PR 轮流负责人排班](https://github.com/kubernetes/website/wiki/PR-Wranglers) 中维护。 -如果想要加入排班计划，需要参加每周的 SIG Docs 会议并志愿申请。 -尽管你不在本周的排班计划中，你也可以审核那些还未开始检视的 PR。 - -<!-- -In addition to the rotation, an automated system comments on each new PR and -suggests reviewers and approvers for the PR, based on the list of approvers and -reviewers in the affected files. The PR author is expected to follow the -guidance of the bot, and this also helps PRs to get reviewed quickly. ---> -除了轮换之外，自动化系统（机器人）会根据修改的文件自动推荐相应的 approver 和 reviewer。 -PR 作者应该遵循机器人的指导，这也有助于 PR 得到快速审查。 - -<!-- -We want to get pull requests (PRs) merged and published as quickly as possible. -To ensure the docs are accurate and up to date, each PR needs to be reviewed by -people who understand the content, as well as people with experience writing -great documentation. ---> -我们希望尽快合并和发布 pull requests。 -为了确保文档是准确的和最新的，每个 PR 都需要由理解内容的人以及具有编写优秀文档经验的人来评审。 - -<!-- -Reviewers and approvers need to provide actionable and constructive feedback to -keep contributors engaged and help them to improve. Sometimes helping a new -contributor get their PR ready to merge takes more time than just rewriting it -yourself, but the project is better in the long term when we have a diversity of -active participants. ---> -评审人员和批准人员需要提供可操作的和建设性的反馈，以保持贡献者的参与并帮助他们改进。 -有时候，帮助一个新的贡献者把他们的 PR 准备好合并比你自己重写它需要更多的时间， -但是从长远来看，当我们有不同的积极参与者时，这个项目会更好。 - -<!-- -Before you start reviewing PRs, make sure you are familiar with the -[Documentation Content Guide](/docs/contribute/style/content-guide/), the -[Documentation Style Guide](/docs/contribute/style/style-guide/), -and the [code of conduct](/community/code-of-conduct/). ---> -在开始评审 PR 之前，请确保熟悉[文档内容指南](/docs/contribute/style/content-guide/)、[文档风格指南](/docs/contribute/style/style-guide/)、[行为准则](/community/code-of-conduct/)。 - -<!-- -### Find a PR to review ---> -### 找一个 PR 来评审 - -<!-- -To see all open PRs, go to the **Pull Requests** tab in the GitHub repository. -A PR is eligible for review when it meets all of the following criteria: ---> -要查看所有打开的 PR，请转到 GitHub 仓库中的**Pull Requests**选项卡。 -当符合以下所有条件时，PR 才有资格进行评审： - -<!-- -- Has the `cncf-cla:yes` tag -- Does not have WIP in the description -- Does not a have tag including the phrase `do-not-merge` -- Has no merge conflicts -- Is based against the correct branch (usually `master` unless the PR relates to - a feature that has not yet been released) -- Is not being actively reviewed by another docs person (other technical - reviewers are fine), unless that person has explicitly asked for your help. In - particular, leaving lots of new comments after other review cycles have - already been completed on a PR can be discouraging and counter-productive. ---> -- 拥有 `cncf-cla:yes` 标签 -- 描述中没有 WIP -- 没有包含 `do-not-merge` 字样的标签 -- 没有合并冲突 -- 基于正确的分支(通常为 “master”，除非 PR 与某个未发布的功能相关) -- 没有被其他文档人员（或其他技术领域的评审人）评审，除非你被显式的请求参与评审。 - 需要说明的是，如果其他评审已经结束的情况下，你再留下很多新的意见，会让人感到沮丧，这适得其反。 - -<!-- -If a PR is not eligible to merge, leave a comment to let the author know about -the problem and offer to help them fix it. If they've been informed and have not -fixed the problem in several weeks or months, eventually their PR will be closed -without merging. ---> -如果 PR 不符合合并的条件，请留下评论，让作者知道问题所在，并帮助他们解决问题。 -如果他们被告知并在几周或几个月内没有解决问题，最终他们的 PR 将被关闭而不会合并。 - -<!-- -If you're new to reviewing, or you don't have a lot of bandwidth, look for PRs -with the `size/XS` or `size/S` tag set. The size is automatically determined by -the number of lines the PR changes. ---> -如果您是新手，或者您没有太多的带宽，请寻找具有 `size/XS` 或 `size/S` 标记集的 PR。 -大小由 PR 更改的行数自动设置。 - -#### Reviewers and approvers - -<!-- -The Kubernetes website repo operates differently than some of the Kubernetes -code repositories when it comes to the roles of reviewers and approvers. For -more information about the responsibilities of reviewers and approvers, see -[Participating](/docs/contribute/participating/). Here's an overview. ---> -Kubernetes 网站仓库与 Kubernetes 的一些代码仓库在涉及审核者和审批者角色时的操作方式不同。 -有关评审人员和批准人员职责的更多信息，请参见[参与](/docs/contribute/participating/)。 -这里只做一个概述。 - -<!-- -- A reviewer reviews pull request content for technical accuracy. A reviewer - indicates that a PR is technically accurate by leaving a `/lgtm` comment on - the PR. - - {{< note >}}Don't add a `/lgtm` unless you are confident in the technical - accuracy of the documentation modified or introduced in the PR.{{< /note >}} - -- An approver reviews pull request content for docs quality and adherence to - SIG Docs guidelines, such as the - [style guide](/docs/contribute/style/style-guide). Only people listed as - approvers in the - [`OWNERS`](https://github.com/kubernetes/website/blob/master/OWNERS) file can - approve a PR. To approve a PR, leave an `/approve` comment on the PR. ---> -- 当评审人员以评审 PR 的技术准确性时，评审人员发表一个 `/lgtm` 评论表示技术上是无误的。 - - {{< note >}}如果你对技术准确性不确信，不要在涉及文档修改的 PR 中回复 `/lgtm`。 {{< /note >}} - -- 批准者审核有关文档修改的内容时，注重质量和相关规范（比如[风格规范](/docs/contribute/style/style-guide)）。 - 只有在 [`OWNERS`](https://github.com/kubernetes/website/blob/master/OWNERS) 文件中列出的 - 人才可以批准 PR。批准 PR 时，需要回复一个 `/approve` 评论。 - -<!-- -A PR is merged when it has both a `/lgtm` comment from anyone in the Kubernetes -organization and an `/approve` comment from an approver in the -`sig-docs-maintainers` group, as long as it is not on hold and the PR author -has signed the CLA. ---> -如果 PR 拥有来自 Kubernetes 社区的任何人的 `/lgtm` 评论和来自 `sig-docs-maintainers` 组的 `/approve` 评论，只要它没有被 hold 并且作者已签署了 CLA，PR 就会被合并。 - -{{< note >}} -<!-- -The ["Participating"](/docs/contribute/participating/#approvers) section contains more information for reviewers and approvers, including specific responsibilities for approvers. --> -["参与"](/docs/contribute/participating/#approvers)部分包含有关 reviewers 和 approvers 的更多信息，包括 approvers 的具体职责。 -{{< /note >}} - -<!-- -### Review a PR ---> -### 审核 PR - -<!-- -1. Read the PR description and read any attached issues or links, if - applicable. "Drive-by reviewing" is sometimes more harmful than helpful, so - make sure you have the right knowledge to provide a meaningful review. - -2. If someone else is the best person to review this particular PR, let them - know by adding a comment with `/assign @<github-username>`. If you have - asked a non-docs person for technical review but still want to review the PR - from a docs point of view, keep going. - -3. Go to the **Files changed** tab. Look over all the changed lines. Removed - content has a red background, and those lines also start with a `-` symbol. - Added content has a green background, and those lines also start with a `+` - symbol. Within a line, the actual modified content has a slightly darker - green background than the rest of the line. - - - Especially if the PR uses tricky formatting or changes CSS, Javascript, - or other site-wide elements, you can preview the website with the PR - applied. Go to the **Conversation** tab and click the **Details** link - for the `deploy/netlify` test, near the bottom of the page. It opens in - the same browser window by default, so open it in a new window so you - don't lose your partial review. Switch back to the **Files changed** tab - to resume your review. - - Make sure the PR complies with the - [Documentation Style Guide](/docs/contribute/style/style-guide/) - and link the author to the relevant part of the style guide if not. - - If you have a question, comment, or other feedback about a given - change, hover over a line and click the blue-and-white `+` symbol that - appears. Type your comment and click **Start a review**. - - If you have more comments, leave them in the same way. - - By convention, if you see a small problem that does not have to do with - the main purpose of the PR, such as a typo or whitespace error, you can - call it out, prefixing your comment with `nit:` so that the author knows - you consider it trivial. They should still address it. - - When you've reviewed everything, or if you didn't have any comments, go - back to the top of the page and click **Review changes**. Choose either - **Comment** or **Request Changes**. Add a summary of your review, and - add appropriate - [Prow commands](https://prow.k8s.io/command-help) to separate lines in - the Review Summary field. SIG Docs follows the - [Kubernetes code review process](https://github.com/kubernetes/community/blob/master/contributors/guide/owners.md#the-code-review-process). - All of your comments will be sent to the PR author in a single - notification. - - - If you think the PR is ready to be merged, add the text `/approve` to - your summary. - - If the PR does not need additional technical review, add the - text `/lgtm` as well. - - If the PR *does* need additional technical review, add the text - `/assign` with the GitHub username of the person who needs to - provide technical review. Look at the `reviewers` field in the - front-matter at the top of a given Markdown file to see who can - provide technical review. - - To prevent the PR from being merged, add `/hold`. This sets the - label `do-not-merge/hold`. - - If a PR has no conflicts and has the `lgtm` and `approve` label but - no `hold` label, it is merged automatically. - - If a PR has the `lgtm` and/or `approve` labels and new changes are - detected, these labels are removed automatically. - - See - [the list of all available slash commands](https://prow.k8s.io/command-help) - that can be used in PRs. - - - If you previously selected **Request changes** and the PR author has - addressed your concerns, you can change your review status either in the - **Files changed** tab or at the bottom of the **Conversation** tab. Be - sure to add the `/approve` tag and assign technical reviewers if necessary, - so that the PR can be merged. ---> - - -1. 阅读 PR 描述，并阅读任何附加的 issues 或链接，如果有的话。 - “快速评审”有时弊大于利，所以确保你有正确的知识来提供有意义的评审。 - -2. 如果其他人是审核这个 PR 的最佳人选，请通过添加 `/assign @<github-username>` 的评论让他们知道。 - 如果你要求一个非文档人员进行技术评审，但仍然想从文档的角度来评审 PR，那就继续吧。 - -3. 转到 **Files changed** 选项卡。查看所有的修改行。删除的内容具有红色背景，这些行也以 `-` 符号开头。 - 添加的内容具有绿色背景，这些行也以 `+` 符号开始。在一行中，实际修改的内容的背景颜色比该行的其余部分略深一些。 - - - 特别是如果 PR 使用复杂的格式或更改 CSS、Javascript 或其他站点范围内的元素，您可以使用 PR 预览网站。 - 转到 **Conversation** 选项卡，单击页面底部附近的 `deploy/netlify` 测试的 **Details** 链接。 - 默认情况下，它会在同一个浏览器窗口中打开，所以在一个新窗口中打开它，这样你就不会丢失你的部分评论。 - 切换回 **Files changed** 选项卡以继续您的审阅。 - - 确保 PR 符合文档[风格指南](/docs/contribute/style/style-guide/)， - 如果不符合，请将作者链接到风格指南的相关部分。 - - 如果您对给定的更改有疑问、评论或其他反馈，请将鼠标悬停在一行上，然后单击出现的蓝白相间的 `+` 号。 - 键入您的评论并单击 **Start a review**。 - - - 如果你有更多的评论，请以同样的方式留下评论。 - - 按照惯例，如果您看到一个与 PR 的主要目的无关的小问题，比如一个打印错误或空格错误， - 您可以将它指出来，并在注释前加上 nit: 以便作者知道您认为它是无关紧要的。 - 他们仍然应该解决这个问题。 - - 当您查看完所有内容，或者没有任何评论时，回到页面顶部并单击 **Review changes**。 - 选择**Comment** 或**Request Changes**。添加评审摘要， - 并在评审摘要字段中另起一行添加适当的 [Prow 命令](https://prow.k8s.io/command-help)。 - SIG Docs 遵循 [Kubernetes 代码审查流程](https://github.com/kubernetes/community/blob/master/contributors/guide/owners.md#the-code-review-process)。 - 您所有的意见将在一个单一的评论中发送给 PR 作者。 - - - 如果您认为 PR 已经准备好合并，请将文本 `/approve` 添加到摘要中。 - - 如果 PR 不需要额外的技术审查，也可以同时添加文本 `/lgtm` 。 - - 如果 PR *确实* 需要额外的技术审查，使用 `/assign` + GitHub 用户名添加需要提供技术审查的人。 - 查看上面出现的 Markdown 文件中的`reviewers`字段，看看谁可以提供技术审阅。 - - 如果需要阻止 PR 被合并，加上 `/hold` ，就会设置 `do-not-merge/hold` 标签。 - - 如果 PR 没有冲突、有 `lgtm` 和 `approve` 标签且没有 `hold` 标签，它就会自动合并。 - - 如果 PR 拥有 `lgtm` 和 `approve` 后再有新的变更，那么这些标签会自动清除。 - - PR 中可能用到的命令，参阅 - [斜线命令列表](https://prow.k8s.io/command-help)。 - - - 如果您以前选择了**Request changes** ，并且 PR 作者已经处理了您的关注点， - 那么您可以在**Files changed** 选项卡或 **Conversation** 选项卡底部更改您的审阅状态。 - 确保添加 `/approve` 标签，并在必要时指派技术审阅人员，以便合并 PR。 - -<!-- -### Commit into another person's PR ---> -### 提交到别人的 PR - -<!-- -Leaving PR comments is helpful, but there may be times when you need to commit -into another person's PR, rather than just leaving a review. ---> -留下评论是有帮助的，但有时你需要把自己的想法融入到其他人的 PR 中，而不仅仅是留下评论。 - -<!-- -Resist the urge to "take over" for another person unless they explicitly ask -you to, or you want to resurrect a long-abandoned PR. While it may be faster -in the short term, it deprives the person of the chance to contribute. ---> -除非对方明确要求你“接手”，或者你想重新建立一个长期被抛弃的 PR，否则不要急于“接手”。 -虽然短期内这样做可能更快，但会剥夺这个人做出贡献的机会。 - -<!-- -The process you use depends on whether you need to edit a file that is already -in the scope of the PR or a file that the PR has not yet touched. ---> -您的做法（接手）取决于您是需要编辑已经在 PR 范围内的文件，还是 PR 尚未触及的文件。 - -<!-- -You can't commit into someone else's PR if either of the following things is -true: ---> -如果以下任何一件事是符合的，你就不能提交到某人的 PR: - -<!-- -- If the PR author pushed their branch directly to the - [https://github.com/kubernetes/website/](https://github.com/kubernetes/website/) - repository, only a reviewer with push access can commit into their PR. - Authors should be encouraged to push their branch to their fork before - opening the PR. -- If the PR author explicitly disallowed edits from approvers, you can't - commit into their PR unless they change this setting. ---> -- 如果 PR 作者将他们的分支直接推入 [https://github.com/kubernetes/website/](https://github.com/kubernetes/website/) 仓库，那么只有具有 push 访问权限的审阅者才能提交到他们的 PR 中。 -- 如果 PR 作者明确禁止审批者进行编辑，那么除非他们更改此设置，否则您无法提交到他们的 PR 中。 - -<!-- -#### If the file is already changed by the PR ---> -#### 文件已在 PR 中修改 - -<!-- -This method uses the GitHub UI. If you prefer, you can use the command line -even if the file you want to change is part of the PR, if you are more -comfortable working that way. ---> -这个方法使用 GitHub UI。如果您愿意，您可以使用命令行，即使您想更改的文件是 PR 的一部分，如果您更愿意这样工作的话。 - -<!-- -1. Click the **Files changed** tab. -2. Scroll down to the file you want to edit, and click the pencil icon for - that file. -3. Make your changes, add a commit message in the field below the editor, and - click **Commit changes**. ---> - -1. 点击 **Files changed** 选项卡。 -2. 向下找到你想要编辑的文件，点击铅笔图标。 -3. 修改并在下面添加提交记录，点击 **Commit changes**。 - -<!-- -Your commit is now pushed to the branch the PR represents (probably on the -author's fork) and now shows up in the PR and your changes are reflected in -the **Files changed** tab. Leave a comment letting the PR author know you -changed the PR. ---> -您的提交现在被推送到 PR 对应的分支(可能在作者的分支上)， -在 PR 中，您的更改反映在 **Files changed** 选项卡中。 -留下评论，让 PR 作者知道你修改了 PR。 - -<!-- -If the author is using the command line rather than the GitHub UI to work on -this PR, they need to fetch their fork's changes and rebase their local branch -on the branch in their fork, before doing additional work on the PR. ---> -如果作者使用命令行而不是 GitHub UI 来处理这个 PR，那么在处理 PR 之前， -他们需要获取 fork 的更改并将本地分支重新建立在 fork 中的分支上。 - -#### 如果文件没有被 PR 修改 - -<!-- -If changes need to be made to a file that is not yet included in the PR, you -need to use the command line. You can always use this method, if you prefer it -to the GitHub UI. ---> -如果需要更改尚未包含在 PR 中的文件，则需要使用命令行。 -如果您喜欢使用这个方法而不喜欢使用 GitHub UI，那么您总是可以使用这个方法。 - - -1. <!-- - Get the URL for the author's fork. You can find it near the bottom of the - **Conversation** tab. Look for the text **Add more commits by pushing to**. - The first link after this phrase is to the branch, and the second link is - to the fork. Copy the second link. Note the name of the branch for later. - --> - 获取作者的 fork 的 URL。你可以在**Conversation** 标签的底部找到它。 - 查找文本 **Add more commits by pushing to** 。 - 这个短语后面的第一个链接是到分支的，第二个链接是到 fork 的。 - 复制第二个链接。稍后会用到分支的名称。 - -2. <!-- - Add the fork as a remote. In your terminal, go to your clone of the - repository. Decide on a name to give the remote (such as the author's - GitHub username), and add the remote using the following syntax: - --> - 要给远程设置一个名称(比如作者的 GitHub 用户名)，然后使用以下语法添加远程： - - ``` - git remote add <name> <url-of-fork> - ``` - -3. <!-- - Fetch the remote. This doesn't change any local files, but updates your - clone's notion of the remote's objects (such as branches and tags) and - their current state. - --> - 获取远程。这不会更改任何本地文件，但会更新克隆的远程对象的概念(如分支和标记)及其当前状态。 - - ``` - git remote fetch <name> - ``` - -4. <!-- - Check out the remote branch. This command will fail if you already have a - local branch with the same name. - --> - 拉取远程分支。如果已经有同名的本地分支，则此命令将失败。 - - ``` - git checkout <branch-from-PR> - ``` - -5. <!-- - Make your changes, use `git add` to add them, and commit them. - --> - 进行更改，使用 `git add` 添加更改，然后提交更改。 - -6. <!-- - Push your changes to the author's remote. - --> - 将您的更改推到作者的远程。 - - ``` - git push <remote-name> <branch-name> - ``` - -7. <!-- - Go back to the GitHub IU and refresh the PR. Your changes appear. Leave the - PR author a comment letting them know you changed the PR. - --> - 回到 GitHub UI 并刷新 PR。给 PR 作者留言，让他们知道你修改了 PR。 - -<!-- -If the author is using the command line rather than the GitHub UI to work on -this PR, they need to fetch their fork's changes and rebase their local branch -on the branch in their fork, before doing additional work on the PR. ---> -如果作者使用命令行而不是 GitHub UI 来处理这个 PR，那么在处理 PR 之前， -他们需要获取 fork 的更改并将本地分支重新建立在 fork 中的分支上。 - -<!-- -## Work from a local clone ---> -## 使用本地克隆 - -<!-- -For changes that require multiple files or changes that involve creating new -files or moving files around, working from a local Git clone makes more sense -than relying on the GitHub UI. These instructions use the `git` command and -assume that you have it installed locally. You can adapt them to use a local -graphical Git client instead. ---> -对于需要多个文件的更改，或者涉及创建新文件或移动文件的更改， -使用本地 Git 克隆比依赖 GitHub UI 更有意义。 -这些指令使用 git 命令，并假设您已经在本地安装了它。 -您可以将它们调整为使用本地图形化 Git 客户机。 - -<!-- -### Clone the repository ---> -### 克隆仓库 - -<!-- -You only need to clone the repository once per physical system where you work -on the Kubernetes documentation. ---> -对于处理 Kubernetes 文档的每个物理机，只需要克隆存储库一次。 - -<!-- -1. In a terminal window, use `git clone` to clone the repository. You do not - need any credentials to clone the repository. - - ``` - git clone https://github.com/kubernetes/website - ``` - - The new directory `website` is created in your current directory, with - the contents of the GitHub repository. - -2. Change to the new `website` directory. Rename the default `origin` remote - to `upstream`. - - ``` - cd website - - git remote rename origin upstream - ``` - -3. If you have not done so, create a fork of the repository on GitHub. In your - web browser, go to - [https://github.com/kubernetes/website](https://github.com/kubernetes/website) - and click the **Fork** button. After a few seconds, you are redirected to - the URL for your fork, which is typically something like - `https://github.com/<username>/website` unless you already had a repository - called `website`. Copy this URL. - -4. Add your fork as a second remote, called `origin`: - - ``` - git remote add origin <FORK-URL> - ``` ---> - -1. 在终端中使用 `git clone` 来克隆仓库。你不需要指定任何证书。 - - ``` - git clone https://github.com/kubernetes/website - ``` - 新目录 `website` 会在当前目录中创建并包含该仓库的内容。 - -2. 进入 `website` 目录，将默认的 `origin` 重命名为远端 `upstream`。 - - ``` - cd website - - git remote rename origin upstream - ``` - -3. 如果还没有这样做，请在 GitHub 上创建存储库的分支。 - 在您的 web 浏览器中，访问 [https://github.com/kubernetes/website](https://github.com/kubernetes/website) - 并单击 Fork 按钮。几秒钟后，您将被重定向到您的 fork 的 URL，它通常类似于 `https://github.com/<username>/website`，除非您已经有一个名为 `website` 的存储库。复制这个网址。 - -4. 在你的 fork 中增加另一个远端 `origin`: - - ``` - git remote add origin <FORK-URL> - ``` - -<!-- -### Work on the local repository ---> -### 使用本地仓库 - -<!-- -Before you start a new unit of work on your local repository, you need to figure -out which branch to base your work on. The answer depends on what you are doing, -but the following guidelines apply: ---> -在本地存储库上启动新的工作单元之前，您需要确定将工作基于哪个分支。 -答案取决于你在做什么，但是下面的指导方针是适用的： - -<!-- -- For general improvements to existing content, start from `master`. -- For new content that is about features that already exist in a released - version of Kubernetes, start from `master`. -- For long-running efforts that multiple SIG Docs contributors will collaborate on, - such as content reorganization, use a specific feature branch created for that - effort. -- For new content that relates to upcoming but unreleased Kubernetes versions, - use the pre-release feature branch created for that Kubernetes version. ---> -- 对于现有内容的一般改进，可以从 `master` 开始。 -- 对于关于 Kubernetes 发布版本中已经存在的特性的新内容，请从 `master` 开始。 -- 对于多个 SIG Docs 贡献者将协作的长期工作，例如内容重组，使用为该工作创建的特定功能分支。 -- 对于与即将发布但尚未发布的 Kubernetes 版本相关的新内容，请使用为该 Kubernetes 版本创建的预发布特性分支。 - -<!-- -For more guidance, see -[Choose which branch to use](/docs/contribute/start/#choose-which-git-branch-to-use). ---> -更多指导，请参考[选择分支](/docs/contribute/start/#choose-which-git-branch-to-use)。 - -<!-- -After you decide which branch to start your work (or _base it on_, in Git -terminology), use the following workflow to be sure your work is based on the -most up-to-date version of that branch. ---> -在您决定要使用哪个分支之后(或者用 Git 术语来说，基于它)， -使用以下工作流来确保您的工作基于该分支的最新版本。 - - -1. <!-- - Fetch both the `upstream` and `origin` remotes. This updates your local - notion of what those branches contain, but does not change your local - branches at all. - --> - 拉取 `upstream` 和 `origin` 远端。 - 这将更新您对这些分支所包含内容的本地概念，但不会更改您的本地分支。 - - ``` - git fetch upstream - git fetch origin - ``` - -2. <!-- - Create a new tracking branch based on the branch you decided is the most - appropriate. This example assumes you are using `master`. - --> - 基于你选择的分支创建一个新的跟踪分支。以你使用 master 为例： - - ``` - git checkout -b <my_new_branch> upstream/master - ``` - - <!-- - This new branch is based on `upstream/master`, not your local `master`. - It tracks `upstream/master`. - --> - 新分支基于 `upstream/master`, 而不是你本地的 `master`。它跟踪 `upstream/master`。 - -3. <!--With your new branch checked out, make your changes using a text editor. - At any time, use the `git status` command to see what you've changed. - --> - 在检出的分支上使用编辑器修改。 - 你可以随时使用 `git status` 命令来查看你的更改。 - - -4. <!-- - When you are ready to submit a pull request, commit your changes. First - use `git status` to see what changes need to be added to the changeset. - There are two important sections: `Changes staged for commit` and - `Changes not staged for commit`. Any files that show up in the latter - section under `modified` or `untracked` need to be added if you want them to - be part of this commit. For each file that needs to be added, use `git add`. - --> - 当您准备提交 pull request 时，提交您的更改。 - 首先使用 git status 查看需要向变更集中添加哪些更改。 - 有两个重要的部分：`Changes staged for commit` 和 `Changes not staged for commit`。 - 如果您希望将后一节中显示的 `modified` 或 `untracked` 文件添加到提交中，你需要使用 `git add`。 - - ``` - git add example-file.md - ``` - - <!-- - When all your intended changes are included, create a commit, using the - `git commit` command: - --> - 当所有文件准备好时，使用 `git commit` 命令提交： - - ``` - git commit -m "Your commit message" - ``` - -{{< note >}} -<!-- -Do not reference a GitHub issue or pull request by ID or URL in the -commit message. If you do, it will cause that issue or pull request to get -a notification every time the commit shows up in a new Git branch. You can -link issues and pull requests together later, in the GitHub UI. ---> -不要在提交消息中引用 GitHub issue 或 PR(通过 ID 或 URL)。如果您这样做了，那么每当提交出现在新的 Git 分支中时，就会导致该 issue 或 PR 获得通知。稍后，您可以在 GitHub UI 中链接 issues 并将请求拉到一起。 -{{< /note >}} - -5. <!-- - Optionally, you can test your change by staging the site locally using the - `hugo` command. See [View your changes locally](#view-your-changes-locally). - You'll be able to view your changes after you submit the pull request, as - well. - --> - 您还可以选择使用 hugo 命令在本地暂存站点来测试您的更改。参阅[本地查看更改](#本地查看更改)。您还可以在提交 PR 后查看更改。 - -6. <!-- - Before you can create a pull request which includes your local commit, you - need to push the branch to your fork, which is the endpoint for the `origin` - remote. - --> - 在创建包含本地提交的 PR 之前，需要将分支推到 fork，也就是 `origin` 端点。 - - ``` - git push origin <my_new_branch> - ``` - <!-- - Technically, you can omit the branch name from the `push` command, but - the behavior in that case depends upon the version of Git you are using. - The results are more repeatable if you include the branch name. - --> - 从技术上讲，您可以从 push 命令中省略分支名称，但是这种情况下的行为取决于您使用的 Git 版本。 - 如果包含分支名称，结果将更加可重复。 - - -7. <!-- - At this point, if you go to https://github.com/kubernetes/website in your - web browser, GitHub detects that you pushed a new branch to your fork and - offers to create a pull request. Fill in the pull request template. - --> - 此时，如果您在 web 浏览器中访问 https://github.com/kubernetes/website, GitHub 会检测到您将一个新的分支推送到您的 fork，并提供创建一个 pull 请求。填写 pull request 模板。 - - - <!--The title should be no more than 50 characters and summarize the intent - of the change.-->标题不应超过 50 个字符，并总结更改的意图。 - - <!-- - The long-form description should contain more information about the fix, - including a line like `Fixes #12345` if the pull request fixes a GitHub - issue. This will cause the issue to be closed automatically when the - pull request is merged. - --> - 长表单描述应该包含关于修复的更多信息，如果 PR 修复了 GitHub issue， - 则应该包含类似 `Fixes #12345` 这样的行。 - 这将导致在合并 PR 时自动关闭该 issue。 - - <!-- - You can add labels or other metadata and assign reviewers. See - [Triage and categorize issues](#triage-and-categorize-issues) for the - syntax. - --> - 您可以添加标签或其他元数据并分配审阅人员。有关语法，请参见[分类 issues](#triage-and-categorize-issues)。 - - <!--Click **Create pull request**.--> 点击 **Create pull request** - -8. <!--Several automated tests will run against the state of the website with your - changes applied. If any of the tests fail, click the **Details** link for - more information. If the Netlify test completes successfully, its - **Details** link goes to a staged version of the Kubernetes website with - your changes applied. This is how reviewers will check your changes.--> - 几个自动化测试将运行与您所应用的更改的网站状态。 - 如果任何测试失败，请单击**Details**链接获取更多信息。 - 如果 Netlify 测试成功完成，它的**Details**链接将转到 Kubernetes 网站的阶段性版本， - 其中应用了您的更改。 - 这是审阅人员检查更改的方式。 - -9. <!--If you notice that more changes need to be made, or if reviewers give you - feedback, address the feedback locally, then repeat step 4 - 6 again, - creating a new commit. The new commit is added to your pull request and the - tests run again, including re-staging the Netlify staged site.--> - 如果您注意到需要进行更多的更改，或者评审人员给了您反馈，请在本地处理反馈， - 然后再次重复步骤 4 - 6，创建一个新的提交。新的提交被添加到您的 pull 请求中， - 测试再次运行，包括 Netlify。 - -10. <!--If a reviewer adds changes to your pull request, you need to fetch those - changes from your fork before you can add more changes. Use the following - commands to do this, assuming that your branch is currently checked out.--> - 如果审查员将更改添加到您的 pull 请求中，您需要从 fork 获取这些更改，然后才能添加更多的更改。 - 假设您的分支当前已签出，请使用以下命令来完成此操作。 - - ``` - git fetch origin - git rebase origin/<your-branch-name> - ``` - - <!--After rebasing, you need to add the `-f` flag to force-push new changes to - the branch to your fork.-->在 rebasing 之后，您需要添加 `-f` 标志来强制推送分支。 - - ``` - git push -f origin <your-branch-name> - ``` - -11. <!--If someone else's change is merged into the branch your work is based on, - and you have made changes to the same parts of the same files, a conflict - might occur. If the pull request shows that there are conflicts to resolve, - you can resolve them using the GitHub UI or you can resolve them locally.--> - 如果其他人的更改合并到您工作所基于的分支中，并且您对相同文件的相同部分进行了更改， - 则可能会发生冲突。如果 pull 请求显示有需要解决的冲突，您可以使用 GitHub UI 解决它们， - 或者在本地解决它们。 - - <!--First, do step 10 to be sure that your fork and your local branch are in - the same state.-->首先执行第 10 步，确保你的 fork 仓库与你本地分支一致。 - - <!--Next, fetch `upstream` and rebase your branch on the branch it was - originally based on, like `upstream/master`.--> - 接着，拉取 `upstream` 并 rebase 你的分支。 - - ``` - git fetch upstream - git rebase upstream/master - ``` - - <!--If there are conflicts Git can't automatically resolve, you can see the - conflicted files using the `git status` command. For each conflicted file, - edit it and look for the conflict markers `>>>`, `<<<`, and `===`. Resolve - the conflict and remove the conflict markers. Then add the changes to the - changeset using `git add <filename>` and continue the rebase using - `git rebase --continue`. When all commits have been applied and there are - no more conflicts, `git status` will show that you are not in a rebase and - there are no changes that need to be committed. At that point, force-push - the branch to your fork, and the pull request should no longer show any - conflicts.--> - 如果存在 Git 无法自动解决的冲突，可以使用 `git status` 命令查看冲突文件。 - 对于每个冲突文件，编辑它并查找冲突标记 `>>>`，`<<<`，and `===`。 - 解决冲突并删除冲突标记。然后使用 `git add <filename>`， - 并使用 `git rebase --continue` 继续将更改添加到更改集中。 - 当所有提交都已应用，并且没有更多冲突时，`git status` 将显示您不在 rebase 中， - 并且不需要提交任何更改。此时，强制将分支推到 fork, pull 请求应该不再显示任何冲突。 - -<!-- -If you're having trouble resolving conflicts or you get stuck with -anything else related to your pull request, ask for help on the `#sig-docs` -Slack channel or the -[kubernetes-sig-docs mailing list](https://groups.google.com/forum/#!forum/kubernetes-sig-docs). ---> -如果您在解决冲突方面遇到困难，或者您被与 pull 请求相关的任何其他事情卡住， -请在 `#sig-docs` Slack 通道或 [kubernet-sig-docs 邮件列表](https://groups.google.com/forum/#!forum/kubernetes-sig-docs) 中寻求帮助。 - -<!-- -### View your changes locally ---> -### 本地查看更改 - -<!-- -If you aren't ready to create a pull request but you want to see what your -changes look like, you can build and run a docker image to generate all the documentation and -serve it locally. ---> -如果您还没有准备好创建一个 pull 请求， -但是您希望看到您的更改是什么样子的， -那么您可以构建并运行一个 docker 映像来生成所有文档并在本地提供它。 - -<!-- -1. Build the image locally: - - ``` - make docker-image - ``` - -2. Once the `kubernetes-hugo` image has been built locally, you can build and serve the site: - - ``` - make docker-serve - ``` - -3. In your browser's address bar, enter `localhost:1313`. Hugo will watch the - filesystem for changes and rebuild the site as needed. - -4. To stop the local Hugo instance, go back to the terminal and type `Ctrl+C` - or just close the terminal window. - -Alternatively, you can install and use the `hugo` command on your development machine: - -1. [Install Hugo](https://gohugo.io/getting-started/installing/) version {{< hugoVersion >}} or later. - -2. In a terminal, go to the root directory of your clone of the Kubernetes - docs, and enter this command: - - ``` - hugo server - ``` - -3. In your browser’s address bar, enter `localhost:1313`. - -4. To stop the local Hugo instance, go back to the terminal and type `Ctrl+C` - or just close the terminal window. ---> -1. 本地构建镜像: - - ``` - make docker-image - ``` - -2. `kubernetes-hugo` 镜像构建完成后，可以构建并启动网站： - - ``` - make docker-serve - ``` - -3. 在浏览器地址栏输入 `localhost:1313`。Hugo 将监视文件系统的更改，并根据需要重新构建站点。 - -4. 如果想停掉本地 Hugo 实例，只需要在命令行中输入 `Ctrl+C` 来关闭命令行窗口。 - -<!-- -Alternatively, you can install and use the `hugo` command on your development machine: ---> -或者，您可以在您的开发机器上安装并使用 hugo 命令： - -1. <!-- - [Install Hugo](https://gohugo.io/getting-started/installing/) version {{< hugoVersion >}} or later. - --> - [安装 Hugo](https://gohugo.io/getting-started/installing/) 版本 {{< hugoVersion >}} 或更新版本. - -2. <!-- - In a terminal, go to the root directory of your clone of the Kubernetes - docs, and enter this command: - --> - 在终端中，转到您克隆的 Kubernetes 文档的根目录，并输入以下命令： - - ``` - hugo server - ``` - -3. <!-- - In your browser’s address bar, enter `localhost:1313`. - --> - 在浏览器地址栏中输入 `localhost:1313`。 - -4. <!-- - To stop the local Hugo instance, go back to the terminal and type `Ctrl+C` - or just close the terminal window. - --> - 如果想停掉本地 Hugo 实例，只需要在命令行中输入 `Ctrl+C` 来关闭命令行窗口。 - -<!-- -## Triage and categorize issues ---> -## issues 归类 - -<!-- -In any given week, a specific docs approver volunteers to do initial -[triage and review of pull requests](#review-pull-requests) and issues. To get -on this list, attend the weekly SIG Docs meeting and volunteer. Even if you are -not on the schedule for the current week, you can still review PRs. ---> -在任何给定的一周内，一个特定的文档审批者会自愿对 pull 请求和 issues 进行初步分类和审查。 -要进入这个名单，参加每周的团体文档会议和志愿者。 -即使你不在这周的时间表上，你仍然可以审核 PR。 - -<!-- -People in SIG Docs are responsible only for triaging and categorizing -documentation issues. General website issues are also filed in the -`kubernetes/website` repository. ---> -SIG 文档人员只负责对文档 issues 进行分类和分类。一般的网站 issues 也归档在 `kubernetes/website` 资源库中。 - -<!-- -When you triage an issue, you: ---> -当你对一个 issue 进行分类时： - -<!-- -- Assess whether the issue has merit. Some issues can be closed quickly by - answering a question or pointing the reporter to a resource. -- Ask the reporter for more information if the issue doesn't have enough - detail to be actionable or the template is not filled out adequately. -- Add labels (sometimes called tags), projects, or milestones to the issue. - Projects and milestones are not heavily used by the SIG Docs team. -- At your discretion, taking ownership of an issue and submitting a PR for it - (especially if it is quick or relates to work you were already doing). ---> -- 评估这个 issue 是否有价值。有些 issues 可以通过回答问题或向作者指出资源来迅速解决。 -- 如果 issue 没有足够的细节可以采取行动，或者模板没有填好，询问作者更多的信息。 -- 向 issue 添加标签(有时称为标签)、项目或者里程碑。SIG 文档团队并没有大量使用项目和里程碑。 -- 根据您的判断，对某个 issue 拥有所有权并为其提交 PR (特别是如果它是快速的或与您已经在做的工作相关的)。 - -<!-- -If you have questions about triaging an issue, ask in `#sig-docs` on Slack or -the -[kubernetes-sig-docs mailing list](https://groups.google.com/forum/#!forum/kubernetes-sig-docs). ---> -如果你针对 issue 分类有疑问，请在 Slack `#sig-docs` 频道或 [kubernetes-sig-docs 邮件列表](https://groups.google.com/forum/#!forum/kubernetes-sig-docs) 中询问。 - -<!-- -### More about labels ---> -### 有关标签的更多信息 - -<!-- -These guidelines are not set in stone and are subject to change. ---> -这些准则并非一成不变，可能会发生变化。 - -<!-- -- An issue can have multiple labels. -- Some labels use slash notation for grouping, which can be thought of like - "sub-labels". For instance, many `sig/` labels exist, such as `sig/cli` and - `sig/api-machinery`. -- Some labels are automatically added based on metadata in the files involved - in the issue, slash commands used in the comments of the issue, or - information in the issue text. -- Some labels are manually added by the person triaging the issue (or the person - reporting the issue, if they are a SIG Docs approvers). - - `Actionable`: There seems to be enough information for the issue to be fixed - or acted upon. - - `good first issue`: Someone with limited Kubernetes or SIG Docs experience - might be able to tackle this issue. - - `kind/bug`, `kind/feature`, and `kind/documentation`: If the person who - filed the issue did not fill out the template correctly, these labels may - not be assigned automatically. A bug is a problem with existing content or - functionality, and a feature is a request for new content or functionality. - The `kind/documentation` label is not currently in use. - - Priority labels: define the relative severity of the issue, as outlined in the - [Kubernetes contributor guide](https://github.com/kubernetes/community/blob/master/contributors/guide/issue-triage.md#define-priority). -- To add a label, leave a comment like `/label <label-to-add>`. The label must - already exist. If you try to add a label that does not exist, the command is - silently ignored. ---> -- 一个 issue 可以有多个标签。 -- 一些标签使用斜杠符号进行分组，可以将其视为“子标签”。例如，`sig/` 存在许多标签，例如 `sig/cli` 和 `sig/api-machinery`。 -- 系统会根据 issue 所涉及文件中的元数据，issue 注释中使用的斜杠命令或 issue 文本中的信息，自动添加一些标签。 -- 由负责 issue 分类的人员（或报告 issue 的人员，如果他们是 SIG 文档批准者）手动添加一些标签。 - - `Actionable`：似乎有足够的信息可以解决或解决此 issue。 - - `good first issue`： Kubernetes 或 SIG Docs 经验有限的人也有可能可以解决此 issue。 - - `kind/bug`、`kind/feature`、`kind/documentation`： - 如果提出 issue 的人未正确填写模板，则可能不会自动分配这些标签。 - 错误是现有内容或功能的 issue，功能是对新内容或功能的请求。`kind/documentation` 标签当前未使用。 - - 优先级标签：定义 issue 的相对严重性。 - 如 [Kubernetes 贡献者指导](https://github.com/kubernetes/community/blob/master/contributors/guide/issue-triage.md#define-priority) 中所述。 -- 要添加标签，添加 `/label <label-to-add>`。标签必须已经存在。 - 如果您尝试添加不存在的标签，该命令将被默认忽略。 - -<!-- -### Handling special issue types ---> -### 处理特殊 issue 类型 - -<!-- -We encounter the following types of issues often enough to document how to handle them. ---> -我们经常遇到以下类型的 issues，足以记录如何处理它们。 - -<!-- -#### Duplicate issues ---> -#### 重复的 issues - -<!-- -If a single problem has one or more issues open for it, the problem should be -consolidated into a single issue. You should decide which issue to keep open (or -open a new issue), port over all relevant information, link related issues, and -close all the other issues that describe the same problem. Only having a single -issue to work on will help reduce confusion and avoid duplicating work on the -same problem. ---> -如果单个问题可以解决一个或多个 issues，则应将该问题合并为一个 issue。 -您应该决定哪个 issue 保持打开状态（或打开一个新 issue），移植所有相关信息，链接相关 issues， -并关闭描述同一 issue 的所有其他 issues。只处理一个 issue 将有助于减少混乱并避免重复处理同一问题。 - -<!-- -#### Dead link issues ---> -#### 无效链接 issues - -<!-- -Depending on where the dead link is reported, different actions are required to -resolve the issue. Dead links in the API and Kubectl docs are automation issues -and should be assigned `/priority critical-urgent` until the problem can be fully understood. All other dead links are issues that need to be manually fixed and can be assigned `/priority important-longterm`. ---> -根据报告无效链接的位置，需要采取不同的措施来解决此 issue。 -API 和 Kubectl 文档中的无效链接是自动化 issues，应分配为 `/priority critical-urgent`， -直到可以完全解决该问题为止。所有其他无效链接都是需要手动修复的 issues， -可以将其分配为 `/priority important-longterm`。 - -<!-- -#### Blog issues ---> -#### 博客 issues - -<!-- -[Kubernetes Blog](https://kubernetes.io/blog/) entries are expected to become -outdated over time, so we maintain only blog entries that are less than one year old. -If an issue is related to a blog entry that is more than one year old, it should be closed -without fixing. ---> -随着时间的流逝，Kubernetes 博客条目预计会过时， -因此我们仅保留不到一年的博客条目。 -如果某个 issue 与存在超过一年的博客条目有关，则应将其关闭而不进行修复。 - -<!-- -#### Support requests or code bug reports ---> -#### 支持请求或代码错误报告 - -<!-- -Some issues opened for docs are instead issues with the underlying code, or -requests for assistance when something (like a tutorial) didn’t work. For issues -unrelated to docs, close the issue with a comment directing the requester to -support venues (Slack, Stack Overflow) and, if relevant, where to file an issue -for bugs with features (kubernetes/kubernetes is a great place to start). ---> -相反，为文档带来的一些 issues 是底层代码的 issues， -或者在某些内容（例如教程）不起作用时请求帮助。 -对于与文档无关的 issues，请关闭 issue 并指示请求者正确的支持场所（Slack，Stack Overflow）， -并在适当的地方针对具有功能缺陷的问题提出 issue（可以从 kubernetes/kubernetes 开始）。 - -<!-- -Sample response to a request for support: ---> -对支持请求的响应示例： - -```none -This issue sounds more like a request for support and less -like an issue specifically for docs. I encourage you to bring -your question to the `#kubernetes-users` channel in -[Kubernetes slack](http://slack.k8s.io/). You can also search -resources like -[Stack Overflow](http://stackoverflow.com/questions/tagged/kubernetes) -for answers to similar questions. - -You can also open issues for Kubernetes functionality in - https://github.com/kubernetes/kubernetes. - -If this is a documentation issue, please re-open this issue. -``` - -<!-- -Sample code bug report response: ---> -示例代码错误报告响应： - -```none -This sounds more like an issue with the code than an issue with -the documentation. Please open an issue at -https://github.com/kubernetes/kubernetes/issues. - -If this is a documentation issue, please re-open this issue. -``` - -<!-- -## Document new features ---> -## 记录新功能 - -<!-- -Each major Kubernetes release includes new features, and many of them need -at least a small amount of documentation to show people how to use them. ---> -每个主要的 Kubernetes 版本都包含新功能，其中许多功能至少需要少量文档才能向人们展示如何使用它们。 - -<!-- -Often, the SIG responsible for a feature submits draft documentation for the -feature as a pull request to the appropriate release branch of -`kubernetes/website` repository, and someone on the SIG Docs team provides -editorial feedback or edits the draft directly. ---> -通常，负责功能的 SIG 负责对 `kubernetes/website` 存储库的相应 release 分支发起 PR， -提交该功能的文档草稿，并且由 SIG Docs 团队中的某人提供编辑反馈或直接编辑草稿。 - -<!-- -### Find out about upcoming features ---> -### 了解即将推出的功能 - -<!-- -To find out about upcoming features, attend the weekly sig-release meeting (see -the [community](https://kubernetes.io/community/) page for upcoming meetings) -and monitor the release-specific documentation -in the [kubernetes/sig-release](https://github.com/kubernetes/sig-release/) -repository. Each release has a sub-directory under the [/sig-release/tree/master/releases/](https://github.com/kubernetes/sig-release/tree/master/releases) -directory. Each sub-directory contains a release schedule, a draft of the release -notes, and a document listing each person on the release team. ---> -要了解即将发布的功能，请参加每周一次的 sig-release 会议 -（请参阅[社区](https://kubernetes.io/community/)页面以获取即将举行的会议， -并在 [kubernetes/sig-release](https://github.com/kubernetes/sig-release/) 存储库中留意特定于发行版的文档。 -每个发行版在 [/sig-release/tree/master/releases/](https://github.com/kubernetes/sig-release/tree/master/releases) - 目录下都有一个子目录。每个子目录包含一个发布计划，一个发布说明草稿以及一个列出发布团队中每个人的文档。 - -<!-- -- The release schedule contains links to all other documents, meetings, - meeting minutes, and milestones relating to the release. It also contains - information about the goals and timeline of the release, and any special - processes in place for this release. Near the bottom of the document, several - release-related terms are defined. - - This document also contains a link to the **Feature tracking sheet**, which is - the official way to find out about all new features scheduled to go into the - release. -- The release team document lists who is responsible for each release role. If - it's not clear who to talk to about a specific feature or question you have, - either attend the release meeting to ask your question, or contact the release - lead so that they can redirect you. -- The release notes draft is a good place to find out a little more about - specific features, changes, deprecations, and more about the release. The - content is not finalized until late in the release cycle, so use caution. ---> -- 发布时间表包含与发布有关的所有其他文档、会议、会议记录和里程碑的链接。 - 它还包含有关该发行版的目标和时间表的信息，以及此发行版的任何特殊流程。 - 在文档底部附近，定义了几个与发布相关的术语。 - - 本文档还包含**Feature tracking sheet**的链接，这是查找排定要发布的所有新功能的正式方法。 - -- 发布团队文档列出了负责每个发布角色的人员。 - 如果不清楚要与谁谈论某个特定功能或问题，请参加发布会议询问您的问题， - 或者与发布负责人联系，以便他们可以重定向您。 -- 发行说明草稿是了解更多有关特定功能、更改、不推荐使用以及更多有关发行版本的好地方。 - 该内容要到发布周期的后期才能最终确定，因此请谨慎使用。 - -<!-- -#### The feature tracking sheet ---> -#### 功能跟踪表 - -<!-- -The feature tracking sheet -[for a given Kubernetes release](https://github.com/kubernetes/sig-release/tree/master/releases) lists each feature that is planned for a release. -Each line item includes the name of the feature, a link to the feature's main -GitHub issue, its stability level (Alpha, Beta, or Stable), the SIG and -individual responsible for implementing it, whether it -needs docs, a draft release note for the feature, and whether it has been -merged. Keep the following in mind: ---> -给定 Kubernetes 版本的功能跟踪表列出了计划发布的每个功能。 -每个订单项都包含功能名称，功能主要 GitHub issue 的链接，其稳定性级别（Alpha，Beta 或 Stable）， -SIG 和负责实施此功能的人员，是否需要文档，发布说明草稿功能，以及是否已合并。请记住以下几点： - -<!-- -- Beta and Stable features are generally a higher documentation priority than - Alpha features. -- It's hard to test (and therefore, document) a feature that hasn't been merged, - or is at least considered feature-complete in its PR. -- Determining whether a feature needs documentation is a manual process and - just because a feature is not marked as needing docs doesn't mean it doesn't - need them. ---> -- Beta 和稳定功能通常比 Alpha 功能具有更高的文档优先级。 -- 很难测试（因此要文档记录）尚未合并的功能，或者至少在其 PR 中被认为功能完整的功能。 -- 确定某个功能是否需要文档是一个手动过程，并且仅仅因为某个功能未标记为需要文档并不意味着它就不需要它们。 - -<!-- -### Document a feature ---> -### 记录功能 - -<!-- -As stated above, draft content for new features is usually submitted by the SIG -responsible for implementing the new feature. This means that your role may be -more of a shepherding role for a given feature than developing the documentation -from scratch. ---> -如上所述，新功能的草案内容通常由负责实施新功能的 SIG 提交。 -这意味着您的角色可能更像是给定功能的牧羊人角色。 - -<!-- -After you've chosen a feature to document/shepherd, ask about it in the `#sig-docs` -Slack channel, in a weekly sig-docs meeting, or directly on the PR filed by the -feature SIG. If you're given the go-ahead, you can edit into the PR using one of -the techniques described in -[Commit into another person's PR](#commit-into-another-persons-pr). ---> -选择要记录/跟踪的功能后，请在 `#sig-docs` Slack 频道， -每周一次的 sig-docs 会议中或直接在功能 SIG 提交的 PR 上询问有关功能。 -如果得到批准，则可以使用[提交到别人的 PR](#commit-into-another-persons-pr) 中介绍的技术来编辑 PR。 - -<!-- -If you need to write a new topic, the following links are useful: ---> -如果您需要编写新主题，则以下链接很有用： - -<!-- -- [Writing a New Topic](/docs/contribute/style/write-new-topic/) -- [Using Page Templates](/docs/contribute/style/page-templates/) -- [Documentation Style Guide](/docs/contribute/style/style-guide/) ---> -- [撰写新主题](/docs/contribute/style/write-new-topic/) -- [使用页面模板](/docs/contribute/style/page-templates/) -- [文档样式指南](/docs/contribute/style/style-guide/) - -<!-- -### SIG members documenting new features ---> -SIG 成员记录了新功能 - -<!-- -If you are a member of a SIG developing a new feature for Kubernetes, you need -to work with SIG Docs to be sure your feature is documented in time for the -release. Check the -[feature tracking spreadsheet](https://github.com/kubernetes/sig-release/tree/master/releases) -or check in the #sig-release Slack channel to verify scheduling details and -deadlines. Some deadlines related to documentation are: ---> -如果您是 Kubernetes 开发新功能的 SIG 成员，则需要一并更新 SIG 文档， -以确保在发布该功能时及时记录了您的功能。 -查看[功能跟踪电子表格](https://github.com/kubernetes/sig-release/tree/master/releases)， - 或在 #sig-release Slack 频道中查看验证计划详细信息和截止日期。 - 与文档相关的一些截止日期是： - -<!-- -- **Docs deadline - Open placeholder PRs**: Open a pull request against the - `release-X.Y` branch in the `kubernetes/website` repository, with a small - commit that you will amend later. Use the Prow command `/milestone X.Y` to - assign the PR to the relevant milestone. This alerts the docs person managing - this release that the feature docs are coming. If your feature does not need - any documentation changes, make sure the sig-release team knows this, by - mentioning it in the #sig-release Slack channel. If the feature does need - documentation but the PR is not created, the feature may be removed from the - milestone. -- **Docs deadline - PRs ready for review**: Your PR now needs to contain a first - draft of the documentation for your feature. Don't worry about formatting or - polishing. Just describe what the feature does and how to use it. The docs - person managing the release will work with you to get the content into shape - to be published. If your feature needs documentation and the first draft - content is not received, the feature may be removed from the milestone. -- **Docs complete - All PRs reviewed and ready to merge**: If your PR has not - yet been merged into the `release-X.Y` branch by this deadline, work with the - docs person managing the release to get it in. If your feature needs - documentation and the docs are not ready, the feature may be removed from the - milestone. ---> -- **文档截止期限 - 打开占位 PR** ：针对 `kubernetes/website` 仓库中的 `release-X.Y` 分支提交一个 PR， - 稍作修改(占位)，稍后您将继续修改。使用 Prow 命令 `/milestone X.Y` 将 PR 分配给相关的里程碑。 - 这会提醒管理此版本的文档人员功能文档即将发布。 - 如果您的功能不需要任何文档更改，请在 #sig-release Slack 频道中说一下， - 以确保 sig-release 团队知道这一点。 - 如果该功能确实需要文档，但未创建 PR，则该功能可能已从里程碑中删除。 -- **文档截止日期 - PR 审核**：您的 PR 现在需要包含功能文档的初稿。不必担心格式或修饰。 - 只需描述该功能的用途以及使用方法即可。管理发行版的文档人员将与您合作，使内容成形以进行发布。 - 如果您的功能需要文档且未收到第一稿内容，则该功能可能已从里程碑中删除。 -- **文档完成 - PR 已审核，准备合并**：如果您的 PR 尚未在 `release-X.Y` 此期限之前合并到分支中， - 请与管理发行版的文档人员一起合作帮助它合入。 - 如果您的功能需要文档且文档尚未准备好，该功能可能会从里程碑中删除。 - -<!-- -If your feature is an Alpha feature and is behind a feature gate, make sure you -add it to [Feature gates](/docs/reference/command-line-tools-reference/feature-gates/) -as part of your pull request. If your feature is moving out of Alpha, make sure to -remove it from that file. ---> -如果您的功能是 Alpha 功能并且由[功能开关](/docs/reference/command-line-tools-reference/feature-gates/) 控制， -请确保将其作为 PR 的一部分添加到功能开关。 -如果您的功能要移出 Alpha，请确保将其从该文件中删除。 - -<!-- -## Contribute to other repos ---> -## 贡献其他仓库 - -<!-- -The [Kubernetes project](https://github.com/kubernetes) contains more than 50 -individual repositories. Many of these repositories contain code or content that -can be considered documentation, such as user-facing help text, error messages, -user-facing text in API references, or even code comments. ---> -该 Kubernetes 项目包含超过 50 个仓库。 -这些存储库中许多都包含可以视为文档的代码或内容，例如面向用户的帮助文本，错误消息， -API 参考中的面向用户的文本，甚至是代码注释。 - -<!-- -If you see text and you aren't sure where it comes from, you can use GitHub's -search tool at the level of the Kubernetes organization to search through all -repositories for that text. This can help you figure out where to submit your -issue or PR. ---> -如果您看到文本并且不确定其来源，则可以在 Kubernetes 组织级别使用 GitHub 的搜索工具在所有存储库中搜索该文本。 -这可以帮助您确定将 issue 或 PR 提交到哪里。 - -<!-- -Each repository may have its own processes and procedures. Before you file an -issue or submit a PR, read that repository's `README.md`, `CONTRIBUTING.md`, and -`code-of-conduct.md`, if they exist. ---> -每个存储库可能都有自己的流程和过程。 -在您提交的 issue 或提交 PR，查看存储库的 `README.md`、`CONTRIBUTING.md` 以及 `code-of-conduct.md`。 - -<!-- -Most repositories use issue and PR templates. Have a look through some open -issues and PRs to get a feel for that team's processes. Make sure to fill out -the templates with as much detail as possible when you file issues or PRs. ---> -大多数存储库使用 issue 和 PR 模板。 -浏览一些未解决的 issues 和 PR，以了解该团队的流程。 -提交 issues 或 PR 时，​​请确保尽可能详细地填写模板。 - -<!-- -## Localize content ---> -## 本地化内容 - -<!-- -The Kubernetes documentation is written in English first, but we want people to -be able to read it in their language of choice. If you are comfortable -writing in another language, especially in the software domain, you can help -localize the Kubernetes documentation or provide feedback on existing localized -content. See [Localization](/docs/contribute/localization/) and ask on the -[kubernetes-sig-docs mailing list](https://groups.google.com/forum/#!forum/kubernetes-sig-docs) -or in `#sig-docs` on Slack if you are interested in helping out. ---> -Kubernetes 文档首先是用英语编写的，但是我们希望人们能够使用他们选择的语言来阅读它。 -如果您愿意用另一种语言编写，尤其是在软件领域，则可以帮助本地化 Kubernetes 文档 -或提供有关现有本地化内容的反馈。 -如果您有兴趣提供帮助，请参阅 [本地化](/docs/contribute/localization/)， -并在 [kubernetes-sig-docs 邮件列表](https://groups.google.com/forum/#!forum/kubernetes-sig-docs) 或者 Slack 的 `#sig-docs` 群组内咨询。 - -<!-- -### Working with localized content ---> -### 参与本地化工作 - -<!-- -Follow these guidelines for working with localized content: ---> -请遵循以下准则来使用本地化内容： - -<!-- -- Limit PRs to a single language. - - Each language has its own reviewers and approvers. - -- Reviewers, verify that PRs contain changes to only one language. - - If a PR contains changes to source in more than one language, ask the PR contributor to open separate PRs for each language. ---> -- 将 PR 限制为一种语言。 - - 每种语言都有其自己的审阅者和批准者。 - -- 审阅者，请验证 PR 是否仅对一种语言进行了更改。 - - 如果 PR 包含对一种以上源语言的更改，请 PR 贡献者为每种语言打开单独的 PR。 - - - -## {{% heading "whatsnext" %}} - - -<!-- -When you are comfortable with all of the tasks discussed in this topic and you -want to engage with the Kubernetes docs team in even deeper ways, read the -[advanced docs contributor](/docs/contribute/advanced/) topic. ---> -如果您熟悉本主题中讨论的所有任务，并且想与 Kubernetes 文档小组进行更深入的接触， -请阅读[文档高级贡献者](/docs/contribute/advanced/)主题。 - diff --git a/content/zh/docs/contribute/localization.md b/content/zh/docs/contribute/localization.md index bad833c974..2241265ec2 100644 --- a/content/zh/docs/contribute/localization.md +++ b/content/zh/docs/contribute/localization.md @@ -1,24 +1,24 @@ --- title: 本地化 Kubernetes 文档 content_type: concept +weight: 50 card: - name: contribute - weight: 30 + name: 贡献 + weight: 50 title: 翻译文档 --- <!-- ---- title: Localizing Kubernetes Documentation content_type: concept approvers: - remyleone - rlenferink - zacharysarah +weight: 50 card: name: contribute - weight: 30 + weight: 50 title: Translating the docs ---- --> <!-- overview --> @@ -26,9 +26,8 @@ card: <!-- This page shows you how to [localize](https://blog.mozilla.org/l10n/2011/12/14/i18n-vs-l10n-whats-the-diff/) the docs for a different language. --> -此页面显示了如何为其他语言的文档提供[本地化](https://blog.mozilla.org/l10n/2011/12/14/i18n-vs-l10n-whats-the-diff/)。 - - +此页面描述如何为其他语言的文档提供 +[本地化](https://blog.mozilla.org/l10n/2011/12/14/i18n-vs-l10n-whats-the-diff/)版本。 <!-- body --> @@ -39,11 +38,11 @@ Because contributors can't approve their own pull requests, you need at least tw All localization teams must be self-sustaining with their own resources. We're happy to host your work, but we can't translate it for you. --> -## 入门 +## 起步 由于贡献者无法批准他们自己的请求，因此您至少需要两个贡献者才能开始本地化。 -所有本地化团队必须使用自身的资源独立工作。我们很高兴支持你的工作，但无法为你翻译。 +所有本地化团队必须使用自身的资源持续工作。我们很高兴托管你的产出，但无法为你翻译。 <!-- ### Find your two-letter language code @@ -56,16 +55,19 @@ First, [create your own fork](/docs/contribute/start/#improve-existing-content) --> ### 找到两个字母的语言代码 -首先，有关本地化的两个字母的国家代码，请参考 [ISO 639-1 标准](https://www.loc.gov/standards/iso639-2/php/code_list.php)。例如，韩国的两个字母代码是 `ko`。 +首先，有关本地化的两个字母的国家代码，请参考 +[ISO 639-1 标准](https://www.loc.gov/standards/iso639-2/php/code_list.php)。 +例如，韩国的两个字母代码是 `ko`。 -### fork 并且克隆仓库 {#fork-and-clone-the-repo} +### 派生（fork）并且克隆仓库 {#fork-and-clone-the-repo} -首先，在 [kubernetes/website](https://github.com/kubernetes/website) 仓库中的 [fork 你自己的分支](/docs/contribute/start/#improve-existing-content)。 +首先，为 [kubernetes/website](https://github.com/kubernetes/website) 仓库 +[创建你自己的副本](/zh/docs/contribute/new-content/open-a-pr/#fork-the-repo)。 <!-- Then, clone your fork and `cd` into it: --> -然后，克隆 website 仓库并通过 `cd` 命令进入 website 目录： +然后，克隆你的 website 仓库副本并通过 `cd` 命令进入 website 目录： ```shell git clone https://github.com/<username>/website @@ -81,46 +83,53 @@ The PR must include all of the [minimum required content](#minimum-required-cont For an example of adding a new localization, see the PR to enable [docs in French](https://github.com/kubernetes/website/pull/12548). --> -### 发起 pr +### 发起拉取请求（PR）{#open-a-pull-request} -接下来，[提交 PR 请求](https://kubernetes.io/docs/contribute/start/#submit-a-pull-request)，将本地化添加到 `kubernetes/website` 仓库。 +接下来，[提交 PR 请求](/zh/docs/contribute/new-content/open-a-pr/#open-a-pr)， +将本地化添加到 `kubernetes/website` 仓库。 -PR 必须包含所有[最低要求的内容](#minimum-required-content)，然后才能被批准。 +该 PR 必须包含所有[最低要求的内容](#minimum-required-content)，然后才能被批准。 有关添加新本地化的示例，请参见添加[法语文档](https://github.com/kubernetes/website/pull/12548) 的 PR。 -### Join the Kubernetes GitHub organization - <!-- +### Join the Kubernetes GitHub organization Once you've opened a localization PR, you can become members of the Kubernetes GitHub organization. Each person on the team needs to create their own [Organization Membership Request](https://github.com/kubernetes/org/issues/new/choose) in the `kubernetes/org` repository. --> -提交本地化 PR 后，您可以成为 Kubernetes GitHub 组织的成员。团队中的每个人都需要在 `kubernetes/org` 仓库中创建自己的[组织成员资格申请](https://github.com/kubernetes/org/issues/new/choose)。 +### 加入到 Kubernetes GitHub 组织 + +提交本地化 PR 后，你可以成为 Kubernetes GitHub 组织的成员。 +团队中的每个人都需要在 `kubernetes/org` 仓库中创建自己的 +[组织成员申请](https://github.com/kubernetes/org/issues/new/choose)。 <!-- ### Add your localization team in GitHub Next, add your Kubernetes localization team to [`sig-docs/teams.yaml`](https://github.com/kubernetes/org/blob/master/config/kubernetes/sig-docs/teams.yaml). For an example of adding a localization team, see the PR to add the [Spanish localization team](https://github.com/kubernetes/org/pull/685). -Members of `sig-docs-**-owners` can approve PRs that change content within (and only within) your localization directory: `/content/**/`. +Members of `@kubernetes/sig-docs-**-owners` can approve PRs that change content within (and only within) your localization directory: `/content/**/`. -The `sig-docs-**-reviews` team automates review assignment for new PRs. +The `@kubernetes/sig-docs-**-reviews` team automates review assignment for new PRs. --> -### 在 GitHub 中添加您的本地化团队 +### 在 GitHub 中添加你的本地化团队 {#add-your-localization-team-in-github} -接下来，将您的 Kubernetes 本地化团队添加到[`sig-docs/teams.yaml`](https://github.com/kubernetes/org/blob/master/config/kubernetes/sig-docs/teams.yaml)。有关添加本地化团队的示例，请参见添加[西班牙本地化团队](https://github.com/kubernetes/org/pull/685) 的 PR。 +接下来，将你的 Kubernetes 本地化团队添加到 +[`sig-docs/teams.yaml`](https://github.com/kubernetes/org/blob/master/config/kubernetes/sig-docs/teams.yaml)。 +有关添加本地化团队的示例，请参见添加[西班牙本地化团队](https://github.com/kubernetes/org/pull/685) 的 PR。 -`sig-docs-**-owners` 成员可以批准更改对应本地化目录 `/content/**/` 中内容的 PR，并仅限这类 PR。 +`@kubernetes/sig-docs-**-owners` 成员可以批准更改对应本地化目录 `/content/**/` 中内容的 PR，并仅限这类 PR。 -`sig-docs-**-reviews` 团队自动分派新 PR 的审阅任务。 +`@kubernetes/sig-docs-**-reviews` 团队被自动分派新 PR 的审阅任务。 <!-- -Members of `sig-docs-l10n-admins` can create new development branches to coordinate translation efforts. +Members of `@kubernetes/website-maintainers` can create new development branches to coordinate translation efforts. Members of `website-milestone-maintainers` can use the `/milestone` [Prow command](https://prow.k8s.io/command-help) to assign a milestone to issues or PRs. --> -`sig-docs-l10n-admins` 成员可以创建新的开发分支来协调翻译工作。 +`@kubernetes/website-maintainers` 成员可以创建新的开发分支来协调翻译工作。 -`website-milestone-maintainers` 成员可以使用 `/milestone` [Prow 命令](https://prow.k8s.io/command-help) 为 issues 或 PR 设定里程碑。 +`@kubernetes/website-milestone-maintainers` 成员可以使用 `/milestone` +[Prow 命令](https://prow.k8s.io/command-help) 为 issues 或 PR 设定里程碑。 <!-- ### Configure the workflow @@ -129,9 +138,10 @@ Next, add a GitHub label for your localization in the `kubernetes/test-infra` re For an example of adding a label, see the PR for adding the [Italian language label](https://github.com/kubernetes/test-infra/pull/11316). --> -### 配置工作流程 +### 配置工作流程 {#configure-the-workflow} -接下来，在 `kubernetes/test-infra` 仓库中为您的本地化添加一个 GitHub 标签。标签可让您过滤 issues 并提出针对特定语言的 pr。 +接下来，在 `kubernetes/test-infra` 仓库中为您的本地化添加一个 GitHub 标签。 +标签可让您过滤 issues 和针对特定语言的 PR。 有关添加标签的示例，请参见添加[意大利语标签](https://github.com/kubernetes/test-infra/pull/11316)的 PR。 @@ -144,9 +154,12 @@ You can also create a Slack channel for your localization in the `kubernetes/com --> ### 寻找社区 -让 Kubernetes SIG Docs 知道您对创建本地化感兴趣！ 加入[SIG Docs Slack 频道](https://kubernetes.slack.com/messages/C1J0BPD2M/)。其他本地化团队很乐意帮助您入门并回答您的任何问题。 +让 Kubernetes SIG Docs 知道你对创建本地化感兴趣！ +加入[SIG Docs Slack 频道](https://kubernetes.slack.com/messages/C1J0BPD2M/)。 +其他本地化团队很乐意帮助你起步并回答你的任何问题。 -您还可以在 `kubernetes/community` 存储库中为本地化创建一个 Slack 频道。有关添加 Slack 频道的示例，请参见[为印尼语和葡萄牙语添加频道](https://github.com/kubernetes/community/pull/3605)的 PR。 +你还可以在 `kubernetes/community` 仓库中为你的本地化创建一个 Slack 频道。 +有关添加 Slack 频道的示例，请参见[为印尼语和葡萄牙语添加频道](https://github.com/kubernetes/community/pull/3605)的 PR。 <!-- ## Minimum required content @@ -161,9 +174,12 @@ Add a configuration block for the new language to `config.toml`, under the exist ### 修改站点配置 -Kubernetes 网站使用 Hugo 作为其 Web 框架。网站的 Hugo 配置位于[`config.toml`](https://github.com/kubernetes/website/tree/master/config.toml)文件中。为了支持新的本地化，您需要修改 `config.toml`。 +Kubernetes 网站使用 Hugo 作为其 Web 框架。网站的 Hugo 配置位于 +[`config.toml`](https://github.com/kubernetes/website/tree/master/config.toml)文件中。 +为了支持新的本地化，您需要修改 `config.toml`。 -在现有的 `[languages]` 下，将新语言的配置添加到 `config.toml` 中。例如，下面是德语的配置示例： +在现有的 `[languages]` 下，将新语言的配置添加到 `config.toml` 中。 +例如，下面是德语的配置示例： ```toml [languages.de] @@ -179,7 +195,7 @@ When assigning a `weight` parameter for your block, find the language block with For more information about Hugo's multilingual support, see "[Multilingual Mode](https://gohugo.io/content-management/multilingual/)". --> -为您的块分配一个 `weight` 参数时，找到权重最高的语言块并将其加 1。 +为你的语言块分配一个 `weight` 参数时，找到权重最高的语言块并将其加 1。 有关 Hugo 多语言支持的更多信息，请参阅"[多语言模式](https://gohugo.io/content-management/multilingual/)"。 @@ -190,7 +206,9 @@ Add a language-specific subdirectory to the [`content`](https://github.com/kuber --> ### 添加一个新的本地化目录 -将特定语言的子目录添加到仓库中的 [`content`](https://github.com/kubernetes/website/tree/master/content) 文件夹下。例如，德语的两个字母的代码是 `de`： +将特定语言的子目录添加到仓库中的 +[`content`](https://github.com/kubernetes/website/tree/master/content) 文件夹下。 +例如，德语的两个字母的代码是 `de`： ```shell mkdir content/de @@ -201,15 +219,15 @@ mkdir content/de Open a PR against the [`cncf/foundation`](https://github.com/cncf/foundation/tree/master/code-of-conduct-languages) repository to add the code of conduct in your language. -### Add a localized README --> ### 本地化社区行为准则 -针对 [`cncf/foundation`](https://github.com/cncf/foundation/tree/master/code-of-conduct-languages) 仓库提交 PR，添加您所用语言版本的行为准则。 - -### 添加本地化的 README 文件 +在 [`cncf/foundation`](https://github.com/cncf/foundation/tree/master/code-of-conduct-languages) +仓库提交 PR，添加你所用语言版本的行为准则。 <!-- +### Add a localized README + To guide other localization contributors, add a new [`README-**.md`](https://help.github.com/articles/about-readmes/) to the top level of k/website, where `**` is the two-letter language code. For example, a German README file would be `README-de.md`. Provide guidance to localization contributors in the localized `README-**.md` file. Include the same information contained in `README.md` as well as: @@ -217,17 +235,23 @@ Provide guidance to localization contributors in the localized `README-**.md` fi - A point of contact for the localization project - Any information specific to the localization --> -为了指导其他本地化贡献者，请在 k/website 的根目录添加一个新的 [`README-**.md`](https://help.github.com/articles/about-readmes/)，其中 `**` 是两个字母的语言代码。例如，德语 README 文件为 `README-de.md`。 +### 添加本地化的 README 文件 + +为了指导其他本地化贡献者，请在 k/website 的根目录添加一个新的 +[`README-**.md`](https://help.github.com/articles/about-readmes/)， +其中 `**` 是两个字母的语言代码。例如，德语 README 文件为 `README-de.md`。 在本地化的 `README-**.md` 文件中为本地化贡献者提供指导。包含 `README.md` 中包含的相同信息，以及： - 本地化项目的联系人 -- 任何有关本地化的信息 +- 任何特定于本地化的信息 <!-- After you create the localized README, add a link to the file from the main English `README.md`, and include contact information in English. You can provide a GitHub ID, email address, [Slack channel](https://slack.com/), or other method of contact. You must also provide a link to your localized Community Code of Conduct. --> -创建本地化的 README 文件后，请在英语版文件 `README.md` 中添加指向该文件的链接，并给出英文形式的联系信息。您可以提供 GitHub ID、电子邮件地址、[Slack 频道](https://slack.com/)或其他联系方式。您还必须提供指向本地化的社区行为准则的链接。 +创建本地化的 README 文件后，请在英语版文件 `README.md` 中添加指向该文件的链接， +并给出英文形式的联系信息。你可以提供 GitHub ID、电子邮件地址、 +[Slack 频道](https://slack.com/)或其他联系方式。你还必须提供指向本地化的社区行为准则的链接。 <!-- ### Setting up the OWNERS files @@ -242,9 +266,14 @@ To set the roles of each user contributing to the localization, create an `OWNER 要设置每个对本地化做出贡献用户的角色，请在特定于语言的子目录内创建一个 `OWNERS` 文件，其中： -- **reviewers**: 具有 reviewer 角色的 kubernetes 团队的列表，在本例中为在[在 GitHub 中添加您的本地化团队](#add-your-localization-team-in-github) 中创建的 `sig-docs-**-reviews` 团队。 -- **approvers**: 具有 approver 角色的 kubernetes 团队的列表，在本例中为在[在 GitHub 中添加您的本地化团队](#add-your-localization-team-in-github) 中创建的 `sig-docs-**-owners` 团队。 -- **labels**: 可以自动应用于 PR 的 GitHub 标签列表，在本例中为[配置工作流程](#configure-the-workflow)中创建的语言标签。 +- **reviewers**: 具有评审人角色的 kubernetes 团队的列表，在本例中为在 + [在 GitHub 中添加您的本地化团队](#add-your-localization-team-in-github) + 中创建的 `sig-docs-**-reviews` 团队。 +- **approvers**: 具有批准人角色的 kubernetes 团队的列表，在本例中为在 + [在 GitHub 中添加您的本地化团队](#add-your-localization-team-in-github) + 中创建的 `sig-docs-**-owners` 团队。 +- **labels**: 可以自动应用于 PR 的 GitHub 标签列表，在本例中为 + [配置工作流程](#configure-the-workflow)中创建的语言标签。 <!-- More information about the `OWNERS` file can be found at [go.k8s.io/owners](https://go.k8s.io/owners). @@ -253,9 +282,9 @@ The [Spanish OWNERS file](https://git.k8s.io/website/content/es/OWNERS), with la --> 有关 `OWNERS` 文件的更多信息，请访问[go.k8s.io/owners](https://go.k8s.io/owners)。 -带有语言代码 `es` 的[西班牙 OWNERS 文件](https://git.k8s.io/website/content/es/OWNERS)看起来像： +语言代码为 `es` 的[西班牙语 OWNERS 文件](https://git.k8s.io/website/content/es/OWNERS)看起来像： + -<!-- ```yaml # See the OWNERS docs at https://go.k8s.io/owners @@ -271,31 +300,19 @@ approvers: labels: - language/es ``` ---> -```yaml -# 在 https://go.k8s.io/owners 地址查看 OWNERS 文档 - -# 这是西班牙语的本地化项目。 -# 团队和成员位于 https://github.com/orgs/kubernetes/teams。 - -reviewers: -- sig-docs-es-reviews - -approvers: -- sig-docs-es-owners - -labels: -- language/es -``` <!-- After adding the language-specific `OWNERS` file, update the [root `OWNERS_ALIASES`](https://git.k8s.io/website/OWNERS_ALIASES) file with the new Kubernetes teams for the localization, `sig-docs-**-owners` and `sig-docs-**-reviews`. For each team, add the list of GitHub users requested in [Add your localization team in GitHub](#add-your-localization-team-in-github), in alphabetical order. --> -添加了特定语言的 OWNERS 文件之后，使用新的 Kubernetes 团队更新 [根目录下的 OWNERS_ALIAES](https://git.k8s.io/website/OWNERS_ALIASES) 文件进行本地化，即 `sig-docs-**-owners` 和 `sig-docs-**-reviews`。 +添加了特定语言的 OWNERS 文件之后，使用新的 Kubernetes 本地化团队、 +`sig-docs-**-owners` 和 `sig-docs-**-reviews` 列表更新 +[根目录下的 OWNERS_ALIAES](https://git.k8s.io/website/OWNERS_ALIASES) 文件。 -对于每个团队，请按字母顺序添加[在 GitHub 中添加您的本地化团队](#add-your-localization-team-in-github) 中请求的 GitHub 用户列表。 +对于每个团队，请按字母顺序添加 +[在 GitHub 中添加您的本地化团队](#add-your-localization-team-in-github) +中所请求的 GitHub 用户列表。 ```diff --- a/OWNERS_ALIASES @@ -340,15 +357,17 @@ Site strings | [All site strings in a new localized TOML file](https://github.co --> 描述 | 网址 -----|----- -主页 | [所有标题和副标题网址](/docs/home/) -安装 | [所有标题和副标题网址](/docs/setup/) -教程 | [Kubernetes 基础](/docs/tutorials/kubernetes-basics/), [Hello Minikube](/docs/tutorials/stateless-application/hello-minikube/) +主页 | [所有标题和副标题网址](/zh/docs/home/) +安装 | [所有标题和副标题网址](/zh/docs/setup/) +教程 | [Kubernetes 基础](/zh/docs/tutorials/kubernetes-basics/), [Hello Minikube](/zh/docs/tutorials/hello-minikube/) 网站字符串 | [新的本地化 TOML 文件中的所有网站字符串](https://github.com/kubernetes/website/tree/master/i18n) <!-- Translated documents must reside in their own `content/**/` subdirectory, but otherwise follow the same URL path as the English source. For example, to prepare the [Kubernetes Basics](/docs/tutorials/kubernetes-basics/) tutorial for translation into German, create a subfolder under the `content/de/` folder and copy the English source: --> -翻译后的文档必须保存在自己的 `content/**/` 子目录中，否则将遵循与英文源相同的 URL 路径。例如，要准备将 [Kubernetes 基础](/docs/tutorials/kubernetes-basics/) 教程翻译为德语，请在 `content/de/` 文件夹下创建一个子文件夹并复制英文源： +翻译后的文档必须保存在自己的 `content/**/` 子目录中，否则将遵循与英文源相同的 URL 路径。 +例如，要准备将 [Kubernetes 基础](/zh/docs/tutorials/kubernetes-basics/) 教程翻译为德语， +请在 `content/de/` 文件夹下创建一个子文件夹并复制英文源： ```shell mkdir -p content/de/docs/tutorials @@ -391,32 +410,31 @@ The latest version is {{< latest-version >}}, so the most recent release branch 要查找最新版本的源文件： 1. 导航到 Kubernetes website 仓库，网址为 https://github.com/kubernetes/website。 -2. 选择最新版本的 `release-1.X` 分支。 +1. 选择最新版本的 `release-1.X` 分支。 -最新版本是 {{< latest-version >}}，所以最新的发行分支是 [`{{< release-branch >}}`](https://github.com/kubernetes/website/tree/{{< release-branch >}})。 +最新版本是 {{< latest-version >}}，所以最新的发行分支是 +[`{{< release-branch >}}`](https://github.com/kubernetes/website/tree/{{< release-branch >}})。 <!-- ### Site strings in i18n/ + +Localizations must include the contents of [`i18n/en.toml`](https://github.com/kubernetes/website/blob/master/i18n/en.toml) in a new language-specific file. Using German as an example: `i18n/de.toml`. + +Add a new localization file to `i18n/`. For example, with German (`de`): +Then translate the value of each string: --> ### i18n/ 中的网站字符串 -<!-- -Localizations must include the contents of [`i18n/en.toml`](https://github.com/kubernetes/website/blob/master/i18n/en.toml) in a new language-specific file. Using German as an example: `i18n/de.toml`. ---> -本地化必须在新的语言特定文件中包含 [`i18n/en.toml`](https://github.com/kubernetes/website/blob/master/i18n/en.toml) 的内容。以德语为例：`i18n/de.toml`。 +本地化必须在新的语言特定文件中包含 +[`i18n/en.toml`](https://github.com/kubernetes/website/blob/master/i18n/en.toml) +的内容。以德语为例：`i18n/de.toml`。 -<!-- -Add a new localization file to `i18n/`. For example, with German (`de`): ---> 将新的本地化文件添加到 `i18n/`。例如德语 (`de`)： ```shell cp i18n/en.toml i18n/de.toml ``` -<!-- -Then translate the value of each string: ---> 然后翻译每个字符串的值： ```TOML @@ -436,22 +454,20 @@ Some language teams have their own language-specific style guide and glossary. F --> ### 特定语言的样式指南和词汇表 -一些语言团队有自己的特定语言风格指南和词汇表。例如，请参见[韩语本地化指南](/ko/docs/contribute/localization_ko/)。 +一些语言团队有自己的特定语言样式指南和词汇表。 +例如，请参见[韩语本地化指南](/ko/docs/contribute/localization_ko/)。 <!-- ## Branching strategy ---> -### 分支策略 -<!-- Because localization projects are highly collaborative efforts, we encourage teams to work in shared development branches. ---> -因为本地化项目是高度协同的工作，所以我们鼓励团队基于共享的开发分支工作。 -<!-- To collaborate on a development branch: --> -在开发分支上协作： +### 分支策略 +因为本地化项目是高度协同的工作，所以我们鼓励团队基于共享的开发分支工作。 + +在开发分支上协作需要： <!-- 1. A team member of [@kubernetes/sig-docs-l10n-admins](https://github.com/orgs/kubernetes/teams/sig-docs-l10n-admins) opens a development branch from a source branch on https://github.com/kubernetes/website. @@ -464,14 +480,17 @@ To collaborate on a development branch: For example, an approver on a German localization team opens the development branch `dev-1.12-de.1` directly against the k/website repository, based on the source branch for Kubernetes v1.12. --> -1. [@kubernetes/sig-docs-l10n-admins](https://github.com/orgs/kubernetes/teams/sig-docs-l10n-admins) 中的团队成员从 https://github.com/kubernetes/website 原有分支新建一个开发分支。 - 当您给 `kubernetes/org` 存储库[添加您的本地化团队](#add-your-localization-team-in-github)时，您的团队 approvers 便加入了 `sig-docs-l10n-admins`。 +1. [@kubernetes/website-maintainers](https://github.com/orgs/kubernetes/teams/website-maintainers) + 中的团队成员从 https://github.com/kubernetes/website 原有分支新建一个开发分支。 + 当你给 `kubernetes/org` 仓库[添加你的本地化团队](#add-your-localization-team-in-github)时， + 你的团队批准人便加入了 `@kubernetes/website-maintainers` 团队。 - 我们推荐以下分支命名方案： + 我们推荐以下分支命名方案： - `dev-<source version>-<language code>.<team milestone>` + `dev-<source version>-<language code>.<team milestone>` - 例如，一个德语本地化团队的 approvers 基于 Kubernetes v1.12 版本的源分支直接新建了 k/website 仓库的开发分支 `dev-1.12-de.1`。 + 例如，一个德语本地化团队的批准人基于 Kubernetes v1.12 版本的源分支， + 直接新建了 k/website 仓库的开发分支 `dev-1.12-de.1`。 <!-- 2. Individual contributors open feature branches based on the development branch. @@ -482,79 +501,81 @@ To collaborate on a development branch: 4. Periodically, an approver merges the development branch to its source branch by opening and approving a new pull request. Be sure to squash the commits before approving the pull request. --> -2. 个人贡献者基于开发分支新建特性分支。 +2. 个人贡献者基于开发分支创建新的特性分支 - 例如，一个德国贡献者新建了一个拉取请求，并将 `username:local-branch-name` 更改为 `kubernetes:dev-1.12-de.1`。 + 例如，一个德语贡献者新建了一个拉取请求，并将 `username:local-branch-name` 更改为 `kubernetes:dev-1.12-de.1`。 -3. Approvers 审查功能分支并将其合并到开发分支中。 +3. 批准人审查功能分支并将其合并到开发分支中。 -4. approver 会定期打开并批准新的 pr，将开发分支合并到其源分支。在批准 pr 之前，请确保先 squash 提交。 +4. 批准人会定期发起并批准新的 PR，将开发分支合并到其源分支。在批准 PR 之前，请确保先 squash commits。 <!-- Repeat steps 1-4 as needed until the localization is complete. For example, subsequent German development branches would be: `dev-1.12-de.2`, `dev-1.12-de.3`, etc. --> -根据需要重复步骤 1-4，直到完成本地化工作。例如，随后的德语开发分支将是：`dev-1.12-de.2`、`dev-1.12-de.3`，等等。 +根据需要重复步骤 1-4，直到完成本地化工作。例如，随后的德语开发分支将是： +`dev-1.12-de.2`、`dev-1.12-de.3`，等等。 <!-- Teams must merge localized content into the same release branch from which the content was sourced. For example, a development branch sourced from {{< release-branch >}} must be based on {{< release-branch >}}. ---> -团队必须将本地化内容合入到发布分支中，该发布分支也正是内容的来源。例如，源于 {{< release-branch >}} 的开发分支必须基于 {{< release-branch >}}。 -<!-- An approver must maintain a development branch by keeping it current with its source branch and resolving merge conflicts. The longer a development branch stays open, the more maintenance it typically requires. Consider periodically merging development branches and opening new ones, rather than maintaining one extremely long-running development branch. --> -approver 必须通过使开发分支与源分支保持最新并解决合并冲突来维护开发分支。开发分支的存在时间越长，通常需要的维护工作就越多。考虑定期合并开发分支并新建分支，而不是维护一个持续时间很长的开发分支。 +团队必须将本地化内容合入到发布分支中，该发布分支也正是内容的来源。 +例如，源于 {{< release-branch >}} 的开发分支必须基于 {{< release-branch >}}。 + +approver 必须通过使开发分支与源分支保持最新并解决合并冲突来维护开发分支。 +开发分支的存在时间越长，通常需要的维护工作就越多。 +考虑定期合并开发分支并新建分支，而不是维护一个持续时间很长的开发分支。 <!-- At the beginning of every team milestone, it's helpful to open an issue comparing upstream changes between the previous development branch and the current development branch. ---> -在每个团队里程碑的起点，打开一个 issue 来比较先前的开发分支和当前的开发分支之间的上游变化很有帮助。 - <!-- - While only approvers can open a new development branch and merge pull requests, anyone can open a pull request for a new development branch. No special permissions are required. +While only approvers can open a new development branch and merge pull requests, anyone can open a pull request for a new development branch. No special permissions are required. --> - 虽然只有 approver 才能开启新的开发分支并合并 pr，但任何人都可以为新的开发分支提交一个拉取请求（PR）。不需要特殊权限。 + +在团队每个里程碑的起点，创建一个 issue 来比较先前的开发分支和当前的开发分支之间的上游变化很有帮助。 +虽然只有批准人才能创建新的开发分支并合并 PR，但任何人都可以为新的开发分支提交一个拉取请求（PR）。 +不需要特殊权限。 <!-- For more information about working from forks or directly from the repository, see ["fork and clone the repo"](#fork-and-clone-the-repo). --> -有关基于 fork 或直接从仓库开展工作的更多信息，请参见 ["fork 和克隆"](#fork-and-clone-the-repo)。 +有关基于派生或直接从仓库开展工作的更多信息，请参见 ["派生和克隆"](#fork-and-clone-the-repo)。 <!-- ## Upstream contributions ---> -### 上游贡献 -<!-- -SIG Docs welcomes [upstream contributions and corrections](/docs/contribute/intermediate#localize-content) to the English source. +SIG Docs welcomes upstream contributions and corrections to the English source. --> -Sig Docs 欢迎[上游贡献和修正](/docs/contribute/intermediate#localize-content) 到英文原文。 +### 上游贡献 {#upstream-contributions} + +Sig Docs 欢迎对英文原文的上游贡献和修正。 <!-- ## Help an existing localization + +You can also help add or improve content to an existing localization. Join the [Slack channel](https://kubernetes.slack.com/messages/C1J0BPD2M/) for the localization, and start opening PRs to help. + Please limit pull requests to a single localization since pull requests that change content in multiple localizations could be difficult to review. --> ## 帮助现有的本地化 -<!-- -You can also help add or improve content to an existing localization. Join the [Slack channel](https://kubernetes.slack.com/messages/C1J0BPD2M/) for the localization, and start opening PRs to help. ---> -您还可以向现有本地化添加或改进内容提供帮助。加入 [Slack 频道](https://kubernetes.slack.com/messages/C1J0BPD2M/)进行本地化，然后开始新建 PR 来提供帮助。 - - +您还可以向现有本地化添加或改进内容提供帮助。 +加入本地化团队的 [Slack 频道](https://kubernetes.slack.com/messages/C1J0BPD2M/)， +然后开始新建 PR 来提供帮助。 +请限制每个 PR 只涉及一种语言，这是因为更改多种语言版本内容的 PR +可能非常难审阅。 ## {{% heading "whatsnext" %}} - <!-- Once a localization meets requirements for workflow and minimum output, SIG docs will: ---> -本地化满足工作流程和最低输出要求后，SIG 文档将： -<!-- - Enable language selection on the website - Publicize the localization's availability through [Cloud Native Computing Foundation](https://www.cncf.io/about/) (CNCF) channels, including the [Kubernetes blog](https://kubernetes.io/blog/). --> +本地化满足工作流程和最低输出要求后，SIG 文档将： + - 在网站上启用语言选择 -- 通过[Cloud Native Computing Foundation](https://www.cncf.io/about/) (CNCF) 频道, 包括[ Kubernetes 博客](https://kubernetes.io/blog/)公开本地化的可用性。 - +- 通过[Cloud Native Computing Foundation](https://www.cncf.io/about/) (CNCF) 频道, + 包括[ Kubernetes 博客](https://kubernetes.io/blog/)公开本地化的可用性。 diff --git a/content/zh/docs/contribute/new-content/_index.md b/content/zh/docs/contribute/new-content/_index.md new file mode 100644 index 0000000000..e498891fa9 --- /dev/null +++ b/content/zh/docs/contribute/new-content/_index.md @@ -0,0 +1,4 @@ +--- +title: 贡献新内容 +weight: 20 +--- diff --git a/content/zh/docs/contribute/new-content/blogs-case-studies.md b/content/zh/docs/contribute/new-content/blogs-case-studies.md new file mode 100644 index 0000000000..3df67c02d9 --- /dev/null +++ b/content/zh/docs/contribute/new-content/blogs-case-studies.md @@ -0,0 +1,224 @@ +--- +title: 提交博客和案例分析 +linktitle: 博客和案例分析 +slug: blogs-case-studies +content_type: concept +weight: 30 +--- +<!-- +title: Submitting blog posts and case studies +linktitle: Blogs and case studies +slug: blogs-case-studies +content_type: concept +weight: 30 +--> + +<!-- overview --> +<!-- +Anyone can write a blog post and submit it for review. +Case studies require extensive review before they're approved. +--> +任何人都可以撰写博客并提交评阅。 +案例分析则在被批准之前需要更多的评阅。 + +<!-- body --> + +<!-- +## The Kubernetes Blog + +The Kubernetes blog is used by the project to communicate new features, community reports, and any news that might be relevant to the Kubernetes community. +This includes end users and developers. +Most of the blog's content is about things happening in the core project, but we encourage you to submit about things happening elsewhere in the ecosystem too! + +Anyone can write a blog post and submit it for review. +--> +## Kubernetes 博客 + +Kubernetes 博客用于项目发布新功能特性、社区报告以及其他一些可能对整个社区 +很重要的新闻。 +其读者包括最终用户和开发人员。 +大多数博客的内容是关于核心项目中正在发生的事情，不过我们也鼓励你提交一些 +关于生态系统中其他地方发生的事情的博客。 + +任何人都可以撰写博客并提交评阅。 + +<!-- +### Guidelines and expectations + +- Blog posts should not be vendor pitches. + - Articles must contain content that applies broadly to the Kubernetes community. For example, a submission should focus on upstream Kubernetes as opposed to vendor-specific configurations. Check the [Documentation style guide](https://kubernetes.io/docs/contribute/style/content-guide/#what-s-allowed) for what is typically allowed on Kubernetes properties. + - Links should primarily be to the official Kubernetes documentation. When using external references, links should be diverse - For example a submission shouldn't contain only links back to a single company's blog. + - Sometimes this is a delicate balance. The [blog team](https://kubernetes.slack.com/messages/sig-docs-blog/) is there to give guidance on whether a post is appropriate for the Kubernetes blog, so don't hesitate to reach out. +--> +### 指导原则和期望 {#guidelines-and-expectations} + +- 博客内容不可以是销售用语。 + - 文章内容必须是对整个 Kubernetes 社区中很多人都有参考意义。 + 例如，所提交的文章应该关注上游的 Kubernetes 项目本身，而不是某个厂商特定的配置。 + 请参阅[文档风格指南](/zh/docs/contribute/style/content-guide/#what-s-allowed) + 以了解哪些内容是 Kubernetes 所允许的。 + - 链接应该主要指向官方的 Kubernetes 文档。 + 当引用外部信息时，链接应该是多样的。 + 例如，所提交的博客文章中不可以只包含指向某个公司的博客的链接。 + - 有些时候，这是一个比较棘手的权衡过程。 + [博客团队](https://kubernetes.slack.com/messages/sig-docs-blog/)的存在目的即是为 + Kubernetes 博客提供文章是否合适的指导意见。 + 所以，需要帮助的时候不要犹豫。 +<!-- +- Blog posts are not published on specific dates. + - Articles are reviewed by community volunteers. We'll try our best to accommodate specific timing, but we make no guarantees. + - Many core parts of the Kubernetes projects submit blog posts during release windows, delaying publication times. Consider submitting during a quieter period of the release cycle. + - If you are looking for greater coordination on post release dates, coordinating with [CNCF marketing](https://www.cncf.io/about/contact/) is a more appropriate choice than submitting a blog post. + - Sometimes reviews can get backed up. If you feel your review isn't getting the attention it needs, you can reach out to the blog team via [this slack channel](https://kubernetes.slack.com/messages/sig-docs-blog/) to ask in real time. +--> +- 博客内容并非在某特定日期发表。 + - 文章会交由社区自愿者评阅。我们会尽力满足特定的时限要求，只是无法就此作出承诺。 + - Kubernetes 项目的很多核心组件会在发布窗口期内提交博客文章，导致发表时间被推迟。 + 因此，请考虑在发布周期内较为平静的时间段提交博文。 + - 如果你希望就博文发表日期上进行较大范围的协调，请联系 + [CNCF 推广团队](https://www.cncf.io/about/contact/)。 + 这也许是比提交博客文章更合适的一种选择。 + - 有时，博客的评审可能会堆积起来。如果你觉得你的文章没有引起该有的重视， + 你可以通过[此 Slack 频道](https://kubernetes.slack.com/messages/sig-docs-blog/) + 联系博客团队，以获得实时反馈。 +<!-- +- Blog posts should be relevant to Kubernetes users. + - Topics related to participation in or results of Kubernetes SIGs activities are always on topic (see the work in the [Upstream Marketing Team](https://github.com/kubernetes/community/blob/master/communication/marketing-team/blog-guidelines.md#upstream-marketing-blog-guidelines) for support on these posts). + - The components of Kubernetes are purposely modular, so tools that use existing integration points like CNI and CSI are on topic. + - Posts about other CNCF projects may or may not be on topic. We recommend asking the blog team before submitting a draft. + - Many CNCF projects have their own blog. These are often a better choice for posts. There are times of major feature or milestone for a CNCF project that users would be interested in reading on the Kubernetes blog. +--> +- 博客内容应该对 Kubernetes 用户有用。 + - 与参与 Kubernetes SIGs 活动相关，或者与这类活动的结果相关的主题通常是切题的。 + 请参考[上游推广团队](https://github.com/kubernetes/community/blob/master/communication/marketing-team/blog-guidelines.md#upstream-marketing-blog-guidelines)的工作以获得对此类博文的支持。 + - Kubernetes 的组件都有意设计得模块化，因此使用类似 CNI、CSI 等集成点的工具 + 通常都是切题的。 + - 关于其他 CNCF 项目的博客可能切题也可能不切题。 + 我们建议你在提交草稿之前与博客团队联系。 + - 很多 CNCF 项目有自己的博客。这些博客通常是更好的选择。 + 有些时候，某个 CNCF 项目的主要功能特性或者里程碑的变化可能是用户有兴趣在 + Kubernetes 博客上阅读的内容。 +<!-- +- Blog posts should be original content + - The official blog is not for repurposing existing content from a third party as new content. + - The [license](https://github.com/kubernetes/website/blob/master/LICENSE) for the blog does allow commercial use of the content for commercial purposes, just not the other way around. +- Blog posts should aim to be future proof + - Given the development velocity of the project, we want evergreen content that won't require updates to stay accurate for the reader. + - It can be a better choice to add a tutorial or update official documentation than to write a high level overview as a blog post. + - Consider concentrating the long technical content as a call to action of the blog post, and focus on the problem space or why readers should care. +--> +- 博客文章应该是原创内容。 + - 官方博客的目的不是将某第三方已发表的内容重新作为新内容发表。 + - 博客的[授权协议](https://github.com/kubernetes/website/blob/master/LICENSE) + 的确允许出于商业目的来使用博客内容；但并不是所有可以商用的内容都适合在这里发表。 +- 博客文章的内容应该在一段时间内不过期。 + - 考虑到项目的开发速度，我们希望读者看到的是不必更新就能保持长期准确的内容。 + - 有时候，在官方文档中添加一个教程或者进行内容更新都是比博客更好的选择。 + - 可以考虑在博客文章中将较长技术内容的重点放在鼓励读者自行尝试上，或者 + 放在问题域本身或者为什么读者应该关注某个话题上。 + +<!-- +### Technical Considerations for submitting a blog post + +Submissions need to be in Markdown format to be used by the [Hugo](https://gohugo.io/) generator for the blog. There are [many resources available](https://gohugo.io/documentation/) on how to use this technology stack. + +We recognize that this requirement makes the process more difficult for less-familiar folks to submit, and we're constantly looking at solutions to lower this bar. If you have ideas on how to lower the barrier, please volunteer to help out. +--> +### 提交博客的技术考虑 + +所提交的内容应该是 Markdown 格式的，以便能够被[Hugo](https://gohugo.io/) 生成器来处理。 +关于如何使用相关技术，有[很多可用的资源](https://gohugo.io/documentation/)。 + +我们知道这一需求可能给那些对此过程不熟悉的朋友们带来不便， +我们也一直在寻找降低难度的解决方案。 +如果你有降低难度的好主意，请自荐帮忙。 + +<!-- +The SIG Docs [blog subproject](https://github.com/kubernetes/community/tree/master/sig-docs/blog-subproject) manages the review process for blog posts. For more information, see [Submit a post](https://github.com/kubernetes/community/tree/master/sig-docs/blog-subproject#submit-a-post). + +To submit a blog post follow these directions: +--> +SIG Docs [博客子项目](https://github.com/kubernetes/community/tree/master/sig-docs/blog-subproject) 负责管理博客的评阅过程。 +更多信息可参考[提交博文](https://github.com/kubernetes/community/tree/master/sig-docs/blog-subproject#submit-a-post)。 + + +要提交博文，你可以遵从以下指南： +<!-- +- [Open a pull request](/docs/contribute/new-content/new-content/#fork-the-repo) with a new blog post. New blog posts go under the [`content/en/blog/_posts`](https://github.com/kubernetes/website/tree/master/content/en/blog/_posts) directory. + +- Ensure that your blog post follows the correct naming conventions and the following frontmatter (metadata) information: + + - The Markdown file name must follow the format `YYYY-MM-DD-Your-Title-Here.md`. For example, `2020-02-07-Deploying-External-OpenStack-Cloud-Provider-With-Kubeadm.md`. + - Do **not** include dots in the filename. A name like `2020-01-01-whats-new-in-1.19.md` causes failures during a build. + - The front matter must include the following: +--> +- [发起一个包含博文的 PR](/zh/docs/contribute/new-content/open-a-pr/#fork-the-repo)。 + 新博文要创建于 [`content/en/blog/_posts`](https://github.com/kubernetes/website/tree/master/content/en/blog/_posts) 目录下。 + +- 确保你的博文遵从合适的命名规范，并带有下面的引言（元数据）信息： + + - Markdown 文件名必须符合格式 `YYYY-MM-DD-Your-Title-Here.md`。 + 例如，`2020-02-07-Deploying-External-OpenStack-Cloud-Provider-With-Kubeadm.md`。 + - **不要**在文件名中包含多余的句点。类似 `2020-01-01-whats-new-in-1.19.md` + 这类文件名会导致文件无法正确打开。 + - 引言部分必须包含以下内容： + + ```yaml + --- + layout: blog + title: "Your Title Here" + date: YYYY-MM-DD + slug: text-for-URL-link-here-no-spaces + --- + ``` +<!-- + - The first or initial commit message should be a short summary of the work being done and should stand alone as a description of the blog post. Please note that subsequent edits to your blog will be squashed into this main commit, so it should be as useful as possible. + - Examples of a good commit message: + - _Add blog post on the foo kubernetes feature_ + - _blog: foobar announcement_ + - Examples of bad commit message: + - _Add blog post_ + - _._ + - _initial commit_ + - _draft post_ + - The blog team will then review your PR and give you comments on things you might need to fix. After that the bot will merge your PR and your blog post will be published. +--> + - 第一个或者最初的提交的描述信息中应该包含一个所作工作的简单摘要， + 并作为整个博文的一个独立描述。 + 请注意，对博文的后续修改编辑都会最终合并到此主提交中，所以此提交的描述信息 + 应该尽量有用。 + - 较好的提交消息（Commit Message）示例： + - _Add blog post on the foo kubernetes feature_ + - _blog: foobar announcement_ + - 较差的提交消息示例： + - _Add blog post_ + - _._ + - _initial commit_ + - _draft post_ + - 博客团队会对 PR 内容进行评阅，为你提供一些评语以便修订。 + 之后，机器人会将你的博文合并并发表。 + +<!-- +## Submit a case study + +Case studies highlight how organizations are using Kubernetes to solve +real-world problems. The Kubernetes marketing team and members of the {{< glossary_tooltip text="CNCF" term_id="cncf" >}} collaborate with you on all case studies. + +Have a look at the source for the +[existing case studies](https://github.com/kubernetes/website/tree/master/content/en/case-studies). + +Refer to the [case study guidelines](https://github.com/cncf/foundation/blob/master/case-study-guidelines.md) and submit your request as outlined in the guidelines. +--> +## 提交案例分析 + +案例分析用来概述组织如何使用 Kubernetes 解决现实世界的问题。 +Kubernetes 市场化团队和 {{< glossary_tooltip text="CNCF" term_id="cncf" >}} 成员 +会与你一起工作，撰写所有的案例分析。 + +请查看 +[现有案例分析](https://github.com/kubernetes/website/tree/master/content/en/case-studies) +的源码。 + +参考[案例分析指南](https://github.com/cncf/foundation/blob/master/case-study-guidelines.md) +根据指南中的注意事项提交你的 PR 请求。 + diff --git a/content/zh/docs/contribute/new-content/new-features.md b/content/zh/docs/contribute/new-content/new-features.md new file mode 100644 index 0000000000..5979fcef0b --- /dev/null +++ b/content/zh/docs/contribute/new-content/new-features.md @@ -0,0 +1,267 @@ +--- +title: 为发行版本撰写功能特性文档 +linktitle: 为发行版本撰写文档 +content_type: concept +main_menu: true +weight: 20 +card: + name: 贡献 + weight: 45 + title: 为发行版本撰写功能特性文档 +--- +<!-- +title: Documenting a feature for a release +linktitle: Documenting for a release +content_type: concept +main_menu: true +weight: 20 +card: + name: contribute + weight: 45 + title: Documenting a feature for a release +--> + +<!-- overview --> + +<!-- +Each major Kubernetes release introduces new features that require documentation. +New releases also bring updates to existing features and documentation (such as upgrading a feature from alpha to beta). + +Generally, the SIG responsible for a feature submits draft documentation of the +feature as a pull request to the appropriate development branch of the +`kubernetes/website` repository, and someone on the SIG Docs team provides +editorial feedback or edits the draft directly. This section covers the branching +conventions and process used during a release by both groups. +--> +Kubernetes 的每个主要版本发布都会包含一些需要文档说明的新功能。 +新的发行版本也会对已有功能特性和文档（例如将某功能特性从 alpha 升级为 +beta）进行更新。 + +通常，负责某功能特性的 SIG 要为功能特性的文档草拟文档，并针对 `kubernetes/website` +仓库的合适的开发分支发起拉取请求。 +SIG Docs 团队会提供文字方面的反馈意见，或者直接编辑文档草稿。 +本节讨论两个小组在分支方面和发行期间所遵从的流程方面的约定。 + +<!-- body --> +<!-- +## For documentation contributors + +In general, documentation contributors don't write content from scratch for a release. +Instead, they work with the SIG creating a new feature to refine the draft documentation and make it release ready. + +After you've chosen a feature to document or assist, ask about it in the `#sig-docs` +Slack channel, in a weekly SIG Docs meeting, or directly on the PR filed by the +feature SIG. If you're given the go-ahead, you can edit into the PR using one of +the techniques described in +[Commit into another person's PR](/docs/contribute/review/for-approvers/#commit-into-another-persons-pr). +--> +## 对于文档贡献者 + +一般而言，文档贡献者不会为某个发行版本从头撰写文档。 +相反，他们会与开发该功能特性的 SIG 团队一起，对文档草稿进行润色， +使之符合发布条件。 + +在你选定了某个功能特性，为其撰写文档（主笔或辅助），请在 `#sig-docs` Slack 频道、SIG Docs 的每周例会上， +或者在功能特性对应的 PR 上提出咨询。 +如果继续工作是没有问题的，你可以使用 +[向他人的 PR 中提交](/zh/docs/contribute/review/for-approvers/#commit-into-another-persons-pr) +中描述的技术之一，参与 PR 的编辑工作。 + +<!-- +### Find out about upcoming features + +To find out about upcoming features, attend the weekly SIG Release meeting (see +the [community](https://kubernetes.io/community/) page for upcoming meetings) +and monitor the release-specific documentation +in the [kubernetes/sig-release](https://github.com/kubernetes/sig-release/) +repository. Each release has a sub-directory in the [/sig-release/tree/master/releases/](https://github.com/kubernetes/sig-release/tree/master/releases) +directory. The sub-directory contains a release schedule, a draft of the release +notes, and a document listing each person on the release team. +--> +### 了解即将发布的功能特性 + +要了解即将发布的功能特性，可以参加每周的 SIG Release 例会 +（参考[社区](https://kubernetes.io/community/)页面，了解即将召开的会议）， +监视 [kubernetes/sig-release](https://github.com/kubernetes/sig-release/) +中与发行相关的文档。 +每个发行版本在 +[/sig-release/tree/master/releases/](https://github.com/kubernetes/sig-release/tree/master/releases) +下都有一个对应的子目录。 +该子目录包含了发行版本的时间计划、发行公告的草稿以及列举发行团队名单的文档。 + +<!-- +The release schedule contains links to all other documents, meetings, +meeting minutes, and milestones relating to the release. It also contains +information about the goals and timeline of the release, and any special +processes in place for this release. Near the bottom of the document, several +release-related terms are defined. + +This document also contains a link to the **Feature tracking sheet**, which is +the official way to find out about all new features scheduled to go into the +release. +--> +发行时间计划文件中包含到所有其他文档、会议、会议记录及发行相关的里程碑的链接。 +其中也包含关于发行版本的目标列表、时间线，以及当前发行版本中就绪的特殊流程的信息。 +文档末尾附近定义了若干与该发行版本有关的术语。 + +此文档也包含到 **功能特性跟踪清单** 的链接。 +这一清单是了解哪些功能特性计划进入某发行版本的正式途径。 + +<!-- +The release team document lists who is responsible for each release role. If +it's not clear who to talk to about a specific feature or question you have, +either attend the release meeting to ask your question, or contact the release +lead so that they can redirect you. + +The release notes draft is a good place to find out about +specific features, changes, deprecations, and more about the release. The +content is not finalized until late in the release cycle, so use caution. +--> +发行团队文档列举了哪些人扮演着各个发行版本的不同角色。 +如果不清楚要联系谁来讨论特定的功能特性或者回答你的问题， +你可以参加发行团队的会议，提出你的问题，或者联系发行团队的牵头人， +这样他们就可以帮你找到正确的联系人。 + +发行说明草稿是用来发现与特定发行版本相关的功能特性、变更、废弃以及其他信息的好来源。 +由于在发行周期的后段该文档的内容才会最终定稿，参考其中的信息时请谨慎。 + +<!-- +### Feature tracking sheet + +The feature tracking sheet [for a given Kubernetes release](https://github.com/kubernetes/sig-release/tree/master/releases) +lists each feature that is planned for a release. +Each line item includes the name of the feature, a link to the feature's main +GitHub issue, its stability level (Alpha, Beta, or Stable), the SIG and +individual responsible for implementing it, whether it +needs docs, a draft release note for the feature, and whether it has been +merged. Keep the following in mind: +--> +### 特性跟踪清单 {#feature-tracking-sheet} + +针对[给定 Kubernetes 发行版本](https://github.com/kubernetes/sig-release/tree/master/releases) +特性跟踪清单中列举的是计划包含于该版本中的每个功能特性。 +每一行中都包含特性的名称、特性对应的主要 GitHub Issue，其稳定性级别（ALpha、 +Beta 或 Stable）、负责实现该特性的 SIG 和个人、是否该特性需要文档、该特性的 +发行说明草稿以及该特性是否已经被合并等等。阅读此清单时请注意： + +<!-- +- Beta and Stable features are generally a higher documentation priority than + Alpha features. +- It's hard to test (and therefore to document) a feature that hasn't been merged, + or is at least considered feature-complete in its PR. +- Determining whether a feature needs documentation is a manual process and + just because a feature is not marked as needing docs doesn't mean it doesn't + need them. +--> +- Beta 和 Stable 功能特性通常比 Alpha 特性更为需要文档支持。 +- 如果某功能特性尚未被合并，就很难测试或者为其撰写文档。 + 对于对应的 PR 而言，也很难讲特性是否完全实现。 +- 确定某个功能特性是否需要对应的文档的过程是一个手动的过程。 + 即使某个功能特性没有标记需要文档，并不意味着该功能真的不需要任何文档。 + +<!-- +## For developers or other SIG members + +This section is information for members of other Kubernetes SIGs documenting new features +for a release. + +If you are a member of a SIG developing a new feature for Kubernetes, you need +to work with SIG Docs to be sure your feature is documented in time for the +release. Check the +[feature tracking spreadsheet](https://github.com/kubernetes/sig-release/tree/master/releases) +or check in the `#sig-release` Kubernetes Slack channel to verify scheduling details and +deadlines. +--> +## 针对开发人员或其他 SIG 成员 + +本节中的信息是针对为发行版本中新功能特性撰写文档的来自其他 Kubernetes SIGs +的成员。 + +如果你是某个 SIG 的成员，负责为 Kubernetes 开发某一项新的功能特性，你需要与 +SIG Docs 一起工作，确保这一新功能在发行之前已经为之撰写文档。 +请参考[特性跟踪清单](https://github.com/kubernetes/sig-release/tree/master/releases) +或者 Kubernetes Slack 上的 `#sig-release` 频道，检查时间安排的细节以及截止日期。 + +<!-- +### Open a placeholder PR + +1. Open a pull request against the +`dev-{{< skew nextMinorVersion >}}` branch in the `kubernetes/website` repository, with a small +commit that you will amend later. +2. Use the Prow command `/milestone {{< skew nextMinorVersion >}}` to +assign the PR to the relevant milestone. This alerts the docs person managing +this release that the feature docs are coming. +--> +### 提交占位 PR {#open-a-placeholder-pr} + +1. 在 `kubernetes/website` 仓库上针对 `dev-{{< skew nextMinorVersion >}}` + 分支提交一个 PR，其中包含较少的、待以后慢慢补齐的提交内容。 +1. 使用 Prow 命令 `/milestone {{< skew nextMinorVersion >}}` 将 PR + 指派到对应的里程碑。这样做会提醒负责管理对应发行版本的文档团队成员，有 + 新的功能特性要合并到将来版本。 + +<!-- +If your feature does not need +any documentation changes, make sure the sig-release team knows this, by +mentioning it in the `#sig-release` Slack channel. If the feature does need +documentation but the PR is not created, the feature may be removed from the +milestone. +--> +如果对应的功能特性不需要任何类型的文档变更，请通过在 `#sig-release` Slack +频道声明这一点以确保 sig-release 团队了解。 +如果功能特性确实需要文档，而没有对应的 PR +提交，该功能特性可能会被从里程碑中移除。 + +<!-- +### PR ready for review + +When ready, populate your placeholder PR with feature documentation. + +Do your best to describe your feature and how to use it. If you need help +structuring your documentation, ask in the `#sig-docs` slack channel. + +When you complete your content, the documentation person assigned to your +feature reviews it. Use their suggestions to get the content to a release +ready state. + +If your feature needs documentation and the first draft content is not +received, the feature may be removed from the milestone. +--> +### PR 准备好评阅 + +时机成熟时，你可以在你的占位 PR 中完成功能特性文档。 + +尽可能为功能特性提供详尽文档以及使用说明。如果你需要文档组织方面的帮助，请 +在 `#sig-docs` Slack 频道中提问。 + +当你已经完成内容撰写，指派给你的功能特性的文档贡献者会去评阅文档。 +尽量利用他们所给出的建议，改进文档内容以达到发布就绪状态。 + +如果你的功能特性需要文档，而一直没有关于该特性的文档提交评阅， +该特性可能会被从里程碑中移除。 + +<!-- +### All PRs reviewed and ready to merge + +If your PR has not yet been merged into the `dev-{{< skew nextMinorVersion >}}` branch by the release deadline, work with the +docs person managing the release to get it in by the deadline. If your feature needs +documentation and the docs are not ready, the feature may be removed from the +milestone. + +If your feature is an Alpha feature and is behind a feature gate, make sure you +add it to [Alpha/Beta Feature gates](/docs/reference/command-line-tools-reference/feature-gates/#feature-gates-for-alpha-or-beta-features) table +as part of your pull request. If your feature is moving out of Alpha, make sure to +remove it from that table. +--> +### 所有 PRs 均经过评审且合并就绪 + +如果你的 PR 在发行截止日期之前尚未合并到 `dev-{{< skew nextMinorVersion >}}` 分支， +请与负责管理该发行版本的文档团队成员一起合作，在截止期限之前将其合并。 +如果功能特性需要文档，而文档并未就绪，该特性可能会被从里程碑中去除。 + +如果你的功能特性是 Alpha 阶段，并且受到某个特性门控的保护，在你的 PR 中，请确保将 +该特性门控添加到 +[Alpha/Beta 特性门控](/zh/docs/reference/command-line-tools-reference/feature-gates/#feature-gates-for-alpha-or-beta-features) +表格中。 +如果你的功能特性不再是 Alpha 阶段，请确保特性门控状态得到更新。 + diff --git a/content/zh/docs/contribute/new-content/open-a-pr.md b/content/zh/docs/contribute/new-content/open-a-pr.md new file mode 100644 index 0000000000..ed3476ca9b --- /dev/null +++ b/content/zh/docs/contribute/new-content/open-a-pr.md @@ -0,0 +1,881 @@ +--- +title: 发起拉取请求（PR） +content_type: concept +weight: 10 +card: + name: 贡献 + weight: 40 +--- +<!-- +title: Opening a pull request +content_type: concept +weight: 10 +card: + name: contribute + weight: 40 +--> + +<!-- overview --> +<!-- +{{< note >}} +**Code developers**: If you are documenting a new feature for an +upcoming Kubernetes release, see +[Document a new feature](/docs/contribute/new-content/new-features/). +{{< /note >}} + +To contribute new content pages or improve existing content pages, open a pull request (PR). Make sure you follow all the requirements in the [Before you begin](/docs/contribute/new-content/overview/#before-you-begin) section. +--> +{{< note >}} +**代码开发者们**：如果你在为下一个 Kubernetes 发行版本中的某功能特性 +撰写文档，请参考[为新功能撰写文档](/zh/docs/contribute/new-content/new-features/)。 +{{< /note >}} + +要贡献新的内容页面或者改进已有内容页面，请发起拉取请求（PR）。 +请确保你满足了[开始之前](/zh/docs/contribute/new-content/overview/#before-you-begin) +节中所列举的所有要求。 + +<!-- +If your change is small, or you're unfamiliar with git, read [Changes using +GitHub](#changes-using-github) to learn how to edit a page. + +If your changes are large, read [Work from a local fork](#fork-the-repo) to +learn how to make changes locally on your computer. +--> +如果你所提交的变更足够小，或者你对 git 工具不熟悉，可以阅读 +[使用 GitHub 提交变更](#changes-using-github)以了解如何编辑页面。 + +如果所提交的变更较大，请阅读[基于本地克隆副本开展工作](#fork-the-repo)以学习 +如何在你本地计算机上构造变更。 + +<!-- body --> + +<!-- +## Changes using GitHub + +If you're less experienced with git workflows, here's an easier method of +opening a pull request. + +1. On the page where you see the issue, select the pencil icon at the top right. + You can also scroll to the bottom of the page and select **Edit this page**. +2. Make your changes in the GitHub markdown editor. +3. Below the editor, fill in the **Propose file change** + form. In the first field, give your commit message a title. In + the second field, provide a description. +--> +## 使用 GitHub 提交变更 {#changes-using-github} + +如果你在 git 工作流方面欠缺经验，这里有一种发起拉取请求的更为简单的方法。 + +1. 在你发现问题的网页，选择右上角的铅笔图标。你也可以滚动到页面底端，选择 + **编辑此页面**。 +2. 在 GitHub 的 Markdown 编辑器中修改内容。 +3. 在编辑器的下方，填写 **建议文件变更** 表单。 + 在第一个字段中，为你的提交消息取一个标题。 + 在第二个字段中，为你的提交写一些描述文字。 + + {{< note >}} + 不要在提交消息中使用 [GitHub 关键词](https://help.github.com/en/github/managing-your-work-on-github/linking-a-pull-request-to-an-issue#linking-a-pull-request-to-an-issue-using-a-keyword) + 你可以在后续的 PR 描述中使用这些关键词。 + {{< /note >}} +<!-- +4. Select **Propose file change**. + +5. Select **Create pull request**. + +6. The **Open a pull request** screen appears. Fill in the form: + + - The **Subject** field of the pull request defaults to the commit summary. + You can change it if needed. + - The **Body** contains your extended commit message, if you have one, + and some template text. Add the + details the template text asks for, then delete the extra template text. + - Leave the **Allow edits from maintainers** checkbox selected. +--> +4. 选择 **Propose File Change**. +5. 选择 **Create pull request**. +6. 在 **Open a pull request** 屏幕上填写表单： + + - **Subject** 字段默认为提交的概要信息。你可以根据需要修改它。 + - **Body** 字段包含更为详细的提交消息，如果你之前有填写过的话，以及一些模板文字。 + 填写模板所要求的详细信息，之后删除多余的模板文字。 + - 确保 **Allow edits from maintainers** 复选框被勾选。 + + <!-- + PR descriptions are a great way to help reviewers understand your change. For + more information, see [Opening a PR](#open-a-pr). + --> + {{< note >}} + PR 描述信息是帮助 PR 评阅人了解你所提议的变更的重要途径。 + 更多信息请参考[发起一个 PR](#open-a-pr). + {{< /note >}} + +<!-- 7. Select **Create pull request**. --> +7. 选择 **Create pull request**. + +<!-- +### Addressing feedback in GitHub + +Before merging a pull request, Kubernetes community members review and +approve it. The `k8s-ci-robot` suggests reviewers based on the nearest +owner mentioned in the pages. If you have someone specific in mind, +leave a comment with their GitHub username in it. +--> +### 在 GitHub 上处理反馈意见 + +在合并 PR 之前，Kubernetes 社区成员会评阅并批准它。 +`k8s-ci-robot` 会基于页面中最近提及的属主来建议评阅人（reviewers）。 +如果你希望特定某人来评阅，可以留下评论，提及该用户的 GitHub 用户名。 + +<!-- +If a reviewer asks you to make changes: + +1. Go to the **Files changed** tab. +2. Select the pencil (edit) icon on any files changed by the +pull request. +3. Make the changes requested. +4. Commit the changes. + +If you are waiting on a reviewer, reach out once every 7 days. You can also post a message in the `#sig-docs` Slack channel. + +When your review is complete, a reviewer merges your PR and your changes go live a few minutes later. +--> +如果某个评阅人请你修改 PR： + +1. 前往 **Files changed** Tab 页面； +1. 选择 PR 所修改的任何文件所对应的铅笔（edit）图标； +1. 根据建议作出修改； +1. 提交所作修改。 + +如果你希望等待评阅人的反馈，可以每 7 天左右联系一次。 +你也可以在 `#sig-docs` Slack 频道发送消息。 + +当评阅过程结束，某个评阅人会合并你的 PR。 +几分钟之后，你所做的变更就会上线了。 + +<!-- +## Work from a local fork {#fork-the-repo} + +If you're more experienced with git, or if your changes are larger than a few lines, +work from a local fork. + +Make sure you have [git](https://git-scm.com/book/en/v2/Getting-Started-Installing-Git) installed on your computer. You can also use a git UI application. +--> +## 基于本地克隆副本开展工作 {#work-from-a-local-fork} + +如果你有 git 的使用经验，或者你要提议的修改不仅仅几行，请使用本地克隆副本 +来开展工作。 + +首先要确保你在本地计算机上安装了 [git](https://git-scm.com/book/en/v2/Getting-Started-Installing-Git)。 +你也可以使用 git 的带用户界面的应用。 + +<!-- +### Fork the kubernetes/website repository + +1. Navigate to the [`kubernetes/website`](https://github.com/kubernetes/website/) repository. +2. Select **Fork**. +--> +### 派生 kubernetes/website 仓库 + +1. 前往 [`kubernetes/website`](https://github.com/kubernetes/website/) 仓库； +2. 选择 **Fork**. + +<!-- +### Create a local clone and set the upstream + +3. In a terminal window, clone your fork: +--> +### 创建一个本地克隆副本并指定 upstream 仓库 + +3. 打开终端窗口，克隆你所派生的副本： + + ```bash + git clone git@github.com/<github_username>/website + ``` + +<!-- +4. Navigate to the new `website` directory. Set the `kubernetes/website` repository as the `upstream` remote: +--> +4. 前往新的 `website` 目录，将 `kubernetes/website` 仓库设置为 `upstream` + 远端： + + ```bash + cd website + git remote add upstream https://github.com/kubernetes/website.git + ``` + +<!-- +5. Confirm your `origin` and `upstream` repositories: +--> +5. 确认你现在有两个仓库，`origin` 和 `upstream`： + + ```bash + git remote -v + ``` + + <!-- Output is similar to: --> + 输出类似于： + + ```bash + origin git@github.com:<github_username>/website.git (fetch) + origin git@github.com:<github_username>/website.git (push) + upstream https://github.com/kubernetes/website (fetch) + upstream https://github.com/kubernetes/website (push) + ``` +<!-- +6. Fetch commits from your fork's `origin/master` and `kubernetes/website`'s `upstream/master`: +--> +6. 从你的克隆副本取回 `origin/master` 分支，从 `kubernetes/website` 取回 `upstream/master`： + + ```bash + git fetch origin + git fetch upstream + ``` + <!-- + This makes sure your local repository is up to date before you start making changes. + --> + 这样可以确保你本地的仓库在开始工作前是最新的。 + + <!-- + This workflow is different than the [Kubernetes Community GitHub Workflow](https://github.com/kubernetes/community/blob/master/contributors/guide/github-workflow.md). You do not need to merge your local copy of `master` with `upstream/master` before pushing updates to your fork. + --> + {{< note >}} + 此工作流程与 [Kubernetes 社区 GitHub 工作流](https://github.com/kubernetes/community/blob/master/contributors/guide/github-workflow.md)有所不同。在推送你的变更到你的远程派生副本库之前，你不需要将你本地的 `master` 与 `upstream/master` 合并。 + {{< /note >}} + +<!-- +### Create a branch + +1. Decide which branch base to your work on: + + - For improvements to existing content, use `upstream/master`. + - For new content about existing features, use `upstream/master`. + - For localized content, use the localization's conventions. For more information, see [localizing Kubernetes documentation](/docs/contribute/localization/). + - For new features in an upcoming Kubernetes release, use the feature branch. For more information, see [documenting for a release](/docs/contribute/new-content/new-features/). + - For long-running efforts that multiple SIG Docs contributors collaborate on, + like content reorganization, use a specific feature branch created for that + effort. + + If you need help choosing a branch, ask in the `#sig-docs` Slack channel. +--> +### 创建一个分支 + +1. 决定你要基于哪个分支来开展工作： + + - 针对已有内容的改进，请使用 `upstream/master`； + - 针对已有功能特性的新文档内容，请使用 `upstream/master`； + - 对于本地化内容，请基于本地化的约定。 + 可参考[对 Kubernetes 文档进行本地化](/zh/docs/contribute/localization/)了解详细信息。 + - 对于在下一个 Kubernetes 版本中新功能特性的文档，使用独立的功能特性分支。 + 参考[为发行版本功能特性撰写文档](/zh/docs/contribute/new-content/new-features/)了解更多信息。 + - 对于很多 SIG Docs 共同参与的，需较长时间才完成的任务，例如内容的重构， + 请使用为该任务创建的特性分支。 + + 如果你在选择分支上需要帮助，请在 `#sig-docs` Slack 频道提问。 + +<!-- +2. Create a new branch based on the branch identified in step 1. This example assumes the base branch is `upstream/master`: +--> +2. 基于第一步中选定的分支，创建新分支。 + 下面的例子假定基础分支是 `upstream/master`： + + ```bash + git checkout -b <my_new_branch> upstream/master + ``` +<!-- +3. Make your changes using a text editor. +--> +3. 使用文本编辑器开始构造变更。 + +<!-- +At any time, use the `git status` command to see what files you've changed. +--> +在任何时候，都可以使用 `git status` 命令查看你所改变了的文件列表。 + +<!-- +### Commit your changes + +When you are ready to submit a pull request, commit your changes. +--> +### 提交你的变更 + +当你准备好发起拉取请求（PR）时，提交你所做的变更。 + +<!-- +1. In your local repository, check which files you need to commit: + + ```bash + git status + ``` + + Output is similar to: + + ```bash + On branch <my_new_branch> + Your branch is up to date with 'origin/<my_new_branch>'. + + Changes not staged for commit: + (use "git add <file>..." to update what will be committed) + (use "git checkout -- <file>..." to discard changes in working directory) + + modified: content/en/docs/contribute/new-content/contributing-content.md + + no changes added to commit (use "git add" and/or "git commit -a") + ``` +--> +1. 在你的本地仓库中，检查你要提交的文件： + + ```bash + git status + ``` + + 输出类似于： + + ```bash + On branch <my_new_branch> + Your branch is up to date with 'origin/<my_new_branch>'. + + Changes not staged for commit: + (use "git add <file>..." to update what will be committed) + (use "git checkout -- <file>..." to discard changes in working directory) + + modified: content/en/docs/contribute/new-content/contributing-content.md + + no changes added to commit (use "git add" and/or "git commit -a") + ``` + +<!-- +2. Add the files listed under **Changes not staged for commit** to the commit: + + ```bash + git add <your_file_name> + ``` + + Repeat this for each file. +--> +2. 将 **Changes not staged for commit** 下列举的文件添加到提交中： + + ```bash + git add <your_file_name> + ``` + + 针对每个文件重复此操作。 +<!-- +3. After adding all the files, create a commit: + + ```bash + git commit -m "Your commit message" + ``` + + {{< note >}} + Do not use any [GitHub Keywords](https://help.github.com/en/github/managing-your-work-on-github/linking-a-pull-request-to-an-issue#linking-a-pull-request-to-an-issue-using-a-keyword) in your commit message. You can add those to the pull request + description later. + {{< /note >}} +--> +3. 添加完所有文件之后，创建一个提交（commit）： + + ```bash + git commit -m "Your commit message" + ``` + + {{< note >}} + 不要在提交消息中使用任何 [GitHub 关键字](https://help.github.com/en/github/managing-your-work-on-github/linking-a-pull-request-to-an-issue#linking-a-pull-request-to-an-issue-using-a-keyword)。 + 你可以在后面创建 PR 时使用这些关键字。 + {{< /note >}} +<!-- +4. Push your local branch and its new commit to your remote fork: + + ```bash + git push origin <my_new_branch> + ``` +--> +4. 推送你本地分支及其中的新提交到你的远程派生副本库： + + ```bash + git push origin <my_new_branch> + ``` + +<!-- +### Preview your changes locally {#preview-locally} + +It's a good idea to preview your changes locally before pushing them or opening a pull request. A preview lets you catch build errors or markdown formatting problems. + +You can either build the website's container image or run Hugo locally. Building the container image is slower but displays [Hugo shortcodes](/docs/contribute/style/hugo-shortcodes/), which can be useful for debugging. +--> +### 在本地预览你的变更 {#preview-locally} + +在推送变更或者发起 PR 之前在本地查看一下预览是个不错的注意。 +通过预览你可以发现构建错误或者 Markdown 格式问题。 + +你可以构造网站的容器镜像或者在本地运行 Hugo。 +构造容器镜像的方式比较慢，不过能够显示 [Hugo 短代码（shortcodes）](/zh/docs/contribute/style/hugo-shortcodes/)， +因此对于调试是很有用的。 + +{{< tabs name="tab_with_hugo" >}} +{{% tab name="在容器内执行 Hugo" %}} + +<!-- +The following commmand uses Docker as the default container engine. +You can set up the `CONTAINER_ENGINE` to override this behavior. +--> +{{< note >}} +下面的命令中使用 Docker 作为默认的容器引擎。 +如果需要重载这一行为，可以设置 `CONTAINER_ENGINE`。 +{{< /note >}} + +<!-- +1. Build the image locally: +--> +1. 在本地构造镜像； + + ```bash + # 使用 docker (默认) + make container-image + + ### 或 ### + + # 使用 podman + CONTAINER_ENGINE=podman make container-image + ``` + +<!-- +2. After building the `kubernetes-hugo` image locally, build and serve the site: +--> +2. 在本地构造了 `kubernetes-hugo` 镜像之后，可以构造并启动网站： + + ```bash + # 使用 docker (默认) + make container-serve + + ### 或 ### + + # 使用 podman + CONTAINER_ENGINE=podman make container-serve + ``` +<!-- +3. In a web browser, navigate to `https://localhost:1313`. Hugo watches the + changes and rebuilds the site as needed. +4. To stop the local Hugo instance, go back to the terminal and type `Ctrl+C`, + or close the terminal window. +--> +3. 启动浏览器，浏览 `https://localhost:1313`。 + Hugo 会监测文件的变更并根据需要重新构建网站。 + +4. 要停止本地 Hugo 实例，可返回到终端并输入 `Ctrl+C`，或者关闭终端窗口。 + +{{% /tab %}} +{{% tab name="在命令行执行 Hugo" %}} + +<!-- +Alternately, install and use the `hugo` command on your computer: +--> +另一种方式是，在你的本地计算机上安装并使用 `hugo` 命令： + +<!-- +1. Install the [Hugo](https://gohugo.io/getting-started/installing/) version specified in [`website/netlify.toml`](https://raw.githubusercontent.com/kubernetes/website/master/netlify.toml). +2. In a terminal, go to your Kubernetes website repository and start the Hugo server: +--> +1. 安装 [`website/netlify.toml`](https://raw.githubusercontent.com/kubernetes/website/master/netlify.toml) + 文件中指定的 [Hugo](https://gohugo.io/getting-started/installing/) 版本。 + +2. 启动一个终端窗口，进入 Kubernetes 网站仓库目录，启动 Hugo 服务器： + + ```bash + cd <path_to_your_repo>/website + hugo server + ``` +<!-- +3. In your browser’s address bar, enter `https://localhost:1313`. +4. To stop the local Hugo instance, go back to the terminal and type `Ctrl+C`, + or close the terminal window. +--> +3. 在浏览器的地址栏输入： `https://localhost:1313`。 +4. 要停止本地 Hugo 实例，返回到终端窗口并输入 `Ctrl+C` 或者关闭终端窗口。 +{{% /tab %}} +{{< /tabs >}} + +<!-- +### Open a pull request from your fork to kubernetes/website {#open-a-pr} +--> +### 从你的克隆副本向 kubernetes/website 发起拉取请求（PR） {#open-a-pr} + +<!-- +1. In a web browser, go to the [`kubernetes/website`](https://github.com/kubernetes/website/) repository. +2. Select **New Pull Request**. +3. Select **compare across forks**. +4. From the **head repository** drop-down menu, select your fork. +5. From the **compare** drop-down menu, select your branch. +6. Select **Create Pull Request**. +7. Add a description for your pull request: + - **Title** (50 characters or less): Summarize the intent of the change. + - **Description**: Describe the change in more detail. + - If there is a related GitHub issue, include `Fixes #12345` or `Closes #12345` in the description. GitHub's automation closes the mentioned issue after merging the PR if used. If there are other related PRs, link those as well. + - If you want advice on something specific, include any questions you'd like reviewers to think about in your description. +8. Select the **Create pull request** button. + + Congratulations! Your pull request is available in [Pull requests](https://github.com/kubernetes/website/pulls). +--> +1. 在 Web 浏览器中，前往 [`kubernetes/website`](https://github.com/kubernetes/website/) 仓库； +2. 点击 **New Pull Request**； +3. 选择 **compare across forks**； +4. 从 **head repository** 下拉菜单中，选取你的派生仓库； +5. 从 **compare** 下拉菜单中，选择你的分支； +6. 点击 **Create Pull Request**； +7. 为你的拉取请求添加一个描述： + - **Title** （不超过 50 个字符）：总结变更的目的； + - **Description**：给出变更的详细信息； + - 如果存在一个相关联的 GitHub Issue，可以在描述中包含 `Fixes #12345` 或 + `Closes #12345`。GitHub 的自动化设施能够在当前 PR 被合并时自动关闭所提及 + 的 Issue。如果有其他相关联的 PR，也可以添加对它们的链接。 + - 如果你尤其希望获得某方面的建议，可以在描述中包含你希望评阅人思考的问题。 +8. 点击 **Create pull request** 按钮。 + + 祝贺你! 你的拉取请求现在出现在 [Pull Requests](https://github.com/kubernetes/website/pulls) 列表中了！ + +<!-- +After opening a PR, GitHub runs automated tests and tries to deploy a preview using [Netlify](https://www.netlify.com/). + + - If the Netlify build fails, select **Details** for more information. + - If the Netlify build succeeds, select **Details** opens a staged version of the Kubernetes website with your changes applied. This is how reviewers check your changes. + +GitHub also automatically assigns labels to a PR, to help reviewers. You can add them too, if needed. For more information, see [Adding and removing issue labels](/docs/contribute/review/for-approvers/#adding-and-removing-issue-labels). +--> +在发起 PR 之后，GitHub 会执行一些自动化的测试，并尝试使用 +[Netlify](https://www.netlify.com/) 部署一个预览版本。 + + - 如果 Netlify 构建操作失败，可选择 **Details** 了解详细信息。 + - 如果 Netlify 构建操作成功，选择 **Details** 会打开 Kubernetes 的一个预览 + 版本，其中包含了你所作的变更。评阅人也使用这一功能来检查你的变更。 + +GitHub 也会自动为 PR 分派一些标签，以帮助评阅人。 +如果有需要，你也可以向 PR 添加标签。 +欲了解相关详细信息，可以参考 +[添加和删除 Issue 标签](/zh/docs/contribute/review/for-approvers/#adding-and-removing-issue-labels)。 + +<!-- +### Addressing feedback locally + +1. After making your changes, amend your previous commit: +--> +### 在本地处理反馈 + +1. 在本地完成修改之后，可以修补（amend）你之前的提交： + + ```bash + git commit -a --amend + ``` + + <!-- + - `-a`: commits all changes + - `--amend`: amends the previous commit, rather than creating a new one + --> + - `-a`：提交所有修改 + - `--amend`：对前一次提交进行增补，而不是创建新的提交 + +<!-- +2. Update your commit message if needed. +3. Use `git push origin <my_new_branch>` to push your changes and re-run the Netlify tests. +--> +2. 如果有必要，更新你的提交消息； +3. 使用 `git push origin <my_new_branch>` 来推送你的变更，重新出发 Netlify 测试。 + + <!-- + If you use `git commit -m` instead of amending, you must + [squash your commits](#squashing-commits) before merging. + --> + {{< note >}} + 如果你使用 `git commit -m` 而不是增补参数，在 PR 最终合并之前你必须 + [squash 你的提交](#squashing-commits)。 + {{< /note >}} + +<!-- +#### Changes from reviewers + +Sometimes reviewers commit to your pull request. Before making any other changes, fetch those commits. + +1. Fetch commits from your remote fork and rebase your working branch: +--> +#### 来自评阅人的修改 + +有时评阅人会向你的 PR 中提交修改。在作出其他修改之前，请先取回这些提交。 + +1. 从你的远程派生副本仓库取回提交，让你的工作分支基于所取回的分支： + + ```bash + git fetch origin + git rebase origin/<your-branch-name> + ``` +<!-- +2. After rebasing, force-push new changes to your fork: +--> +2. 变更基线（rebase）操作完成之后，强制推送本地的新改动到你的派生仓库： + + ```bash + git push --force-with-lease origin <your-branch-name> + ``` + +<!-- +#### Merge conflicts and rebasing + +{{< note >}} +For more information, see [Git Branching - Basic Branching and Merging](https://git-scm.com/book/en/v2/Git-Branching-Basic-Branching-and-Merging#_basic_merge_conflicts), [Advanced Merging](https://git-scm.com/book/en/v2/Git-Tools-Advanced-Merging), or ask in the `#sig-docs` Slack channel for help. +{{< /note >}} +--> +#### 合并冲突和重设基线 + +{{< note >}} +要了解更多信息，可参考 +[Git 分支管理 - 基本分支和合并](https://git-scm.com/book/en/v2/Git-Branching-Basic-Branching-and-Merging#_basic_merge_conflicts)、 +[高级合并](https://git-scm.com/book/en/v2/Git-Tools-Advanced-Merging)、 +或者在 `#sig-docs` Slack 频道寻求帮助。 +{{< /note >}} + +<!-- +If another contributor commits changes to the same file in another PR, it can create a merge conflict. You must resolve all merge conflicts in your PR. + +1. Update your fork and rebase your local branch: +--> +如果另一个贡献者在别的 PR 中提交了对同一文件的修改，这可能会造成合并冲突。 +你必须在你的 PR 中解决所有合并冲突。 + +1. 更新你的派生副本，重设本地分支的基线： + + ```bash + git fetch origin + git rebase origin/<your-branch-name> + ``` + + <!-- Then force-push the changes to your fork:--> + 之后强制推送修改到你的派生副本仓库： + + ```bash + git push --force-with-lease origin <your-branch-name> + ``` +<!-- +2. Fetch changes from `kubernetes/website`'s `upstream/master` and rebase your branch: +--> +2. 从 `kubernetes/website` 的 `upstream/master` 分支取回更改，然后重设本地分支的基线： + + ```bash + git fetch upstream + git rebase upstream/master + ``` +<!-- +3. Inspect the results of the rebase: +--> +3. 检查重设基线操作之后的状态： + + ```bash + git status + ``` + + <!-- This results in a number of files marked as conflicted. --> + 你会看到一组存在冲突的文件。 + +<!-- +4. Open each conflicted file and look for the conflict markers: `>>>`, `<<<`, and `===`. Resolve the conflict and delete the conflict marker. +--> +4. 打开每个存在冲突的文件，查找冲突标记：`>>>`、`<<<` 和 `===`。 + 解决完冲突之后删除冲突标记。 + + <!-- + For more information, see [How conflicts are presented](https://git-scm.com/docs/git-merge#_how_conflicts_are_presented). + --> + {{< note >}} + 进一步的详细信息可参见 + [冲突是怎样表示的](https://git-scm.com/docs/git-merge#_how_conflicts_are_presented). + {{< /note >}} + +<!-- +5. Add the files to the changeset: +--> +5. 添加文件到变更集合： + + ```bash + git add <filename> + ``` +<!-- +6. Continue the rebase: +--> +6. 继续执行基线变更（rebase）操作： + + ```bash + git rebase --continue + ``` + +<!-- +7. Repeat steps 2 to 5 as needed. + + After applying all commits, the `git status` command shows that the rebase is complete. +--> +7. 根据需要重复步骤 2 到 5。 + + 在应用完所有提交之后，`git status` 命令会显示 rebase 操作完成。 + +<!-- +8. Force-push the branch to your fork: +--> +8. 将分支强制推送到你的派生仓库： + + ```bash + git push --force-with-lease origin <your-branch-name> + ``` + + <!-- The pull request no longer shows any conflicts. --> + PR 不再显示存在冲突。 + +<!-- +### Squashing commits +--> +### 压缩（Squashing）提交 {#squashing-commits} + +<!-- +For more information, see [Git Tools - Rewriting History](https://git-scm.com/book/en/v2/Git-Tools-Rewriting-History), or ask in the `#sig-docs` Slack channel for help. +--> +{{< note >}} +要了解更多信息，可参看 +[Git Tools - Rewriting History](https://git-scm.com/book/en/v2/Git-Tools-Rewriting-History)， +或者在 `#sig-docs` Slack 频道寻求帮助。 +{{< /note >}} + +<!-- +If your PR has multiple commits, you must squash them into a single commit before merging your PR. You can check the number of commits on your PR's **Commits** tab or by running the `git log` command locally. +--> +如果你的 PR 包含多个提交（commits），你必须将其压缩成一个提交才能被合并。 +你可以在 PR 的 **Commits** Tab 页面查看提交个数，也可以在本地通过 +`git log` 命令查看提交个数。 + +<!-- This topic assumes `vim` as the command line text editor.--> +{{< note >}} +本主题假定使用 `vim` 作为命令行文本编辑器。 +{{< /note >}} + +<!-- +1. Start an interactive rebase: +--> +1. 启动一个交互式的 rebase 操作： + + ```bash + git rebase -i HEAD~<number_of_commits_in_branch> + ``` + + <!-- + Squashing commits is a form of rebasing. The `-i` switch tells git you want to rebase interactively. `HEAD~<number_of_commits_in_branch` indicates how many commits to look at for the rebase. + --> + 压缩提交的过程也是一种重设基线的过程。 + 这里的 `-i` 开关告诉 git 你希望交互式地执行重设基线操作。 + `HEAD~<number_of_commits_in_branch` 表明在 rebase 操作中查看多少个提交。 + + <!--Output is similar to:--> + 输出类似于； + + ```bash + pick d875112ca Original commit + pick 4fa167b80 Address feedback 1 + pick 7d54e15ee Address feedback 2 + + # Rebase 3d18sf680..7d54e15ee onto 3d183f680 (3 commands) + + ... + + # These lines can be re-ordered; they are executed from top to bottom. + ``` + + <!-- + The first section of the output lists the commits in the rebase. The second section lists the options for each commit. Changing the word `pick` changes the status of the commit once the rebase is complete. + + For the purposes of rebasing, focus on `squash` and `pick`. + --> + 输出的第一部分列举了重设基线操作中的提交。 + 第二部分给出每个提交的选项。 + 改变单词 `pick` 就可以改变重设基线操作之后提交的状态。 + + 就重设基线操作本身，我们关注 `squash` 和 `pick` 选项。 + + <!-- + For more information, see [Interactive Mode](https://git-scm.com/docs/git-rebase#_interactive_mode). + --> + {{< note >}} + 进一步的详细信息可参考 [Interactive Mode](https://git-scm.com/docs/git-rebase#_interactive_mode)。 + {{< /note >}} + +<!-- +2. Start editing the file. + Change the original text: +--> + +2. 开始编辑文件。 + + 修改原来的文本： + + ```bash + pick d875112ca Original commit + pick 4fa167b80 Address feedback 1 + pick 7d54e15ee Address feedback 2 + ``` + + <!-- To: --> + 使之成为： + + ```bash + pick d875112ca Original commit + squash 4fa167b80 Address feedback 1 + squash 7d54e15ee Address feedback 2 + ``` + + <!-- + This squashes commits `4fa167b80 Address feedback 1` and `7d54e15ee Address feedback 2` into `d875112ca Original commit`, leaving only `d875112ca Original commit` as a part of the timeline. + --> + 以上编辑操作会压缩提交 `4fa167b80 Address feedback 1` 和 `7d54e15ee Address feedback 2` + 到 `d875112ca Original commit` 中，只留下 `d875112ca Original commit` 成为时间线中的一部分。 + +<!-- +3. Save and exit your file. +4. Push your squashed commit: +--> +3. 保存文件并退出编辑器。 + +4. 推送压缩后的提交： + + ```bash + git push --force-with-lease origin <branch_name> + ``` + +<!-- +## Contribute to other repos + +The [Kubernetes project](https://github.com/kubernetes) contains 50+ repositories. Many of these repositories contain documentation: user-facing help text, error messages, API references or code comments. + +If you see text you'd like to improve, use GitHub to search all repositories in the Kubernetes organization. +This can help you figure out where to submit your issue or PR. +--> +## 贡献到其他仓库 + +[Kubernetes 项目](https://github.com/kubernetes)包含大约 50 多个仓库。 +这些仓库中很多都有文档：提供给最终用户的帮助文本、错误信息、API 参考或者代码注释等。 + +如果你发现有些文本需要改进，可以使用 GitHub 来搜索 Kubernetes 组织下的所有仓库。 +这样有助于发现要在哪里提交 Issue 或 PR。 + +<!-- +Each repository has its own processes and procedures. Before you file an +issue or submit a PR, read that repository's `README.md`, `CONTRIBUTING.md`, and +`code-of-conduct.md`, if they exist. + +Most repositories use issue and PR templates. Have a look through some open +issues and PRs to get a feel for that team's processes. Make sure to fill out +the templates with as much detail as possible when you file issues or PRs. +--> +每个仓库有其自己的流程和过程。在登记 Issue 或者发起 PR 之前，记得阅读仓库的 +`README.md`、`CONTRIBUTING.md` 和 `code-of-conduct.md` 文件，如果有的话。 + +大多数仓库都有自己的 Issue 和 PR 模版。通过查看一些待解决的 Issues 和 +PR，也可以添加对它们的链接。你可以多少了解该团队的流程。 +在登记 Issue 或提出 PR 时，务必尽量填充所给的模版，多提供详细信息。 + +## {{% heading "whatsnext" %}} + +<!-- +- Read [Reviewing](/docs/contribute/reviewing/revewing-prs) to learn more about the review process. +--> +- 阅读[评阅](/zh/docs/contribute/review/reviewing-prs)节，学习评阅过程。 + diff --git a/content/zh/docs/contribute/new-content/overview.md b/content/zh/docs/contribute/new-content/overview.md new file mode 100644 index 0000000000..0deead5b8d --- /dev/null +++ b/content/zh/docs/contribute/new-content/overview.md @@ -0,0 +1,122 @@ +--- +title: 贡献新内容概述 +linktitle: 概述 +content_type: concept +main_menu: true +weight: 5 +--- +<!-- +title: Contributing new content overview +linktitle: Overview +content_type: concept +main_menu: true +weight: 5 +--> + +<!-- overview --> +<!-- +This section contains information you should know before contributing new content. +--> +本节包含贡献新内容之前你需要知晓的一些信息。 + +<!-- body --> + +<!-- +## Contributing basics + +- Write Kubernetes documentation in Markdown and build the Kubernetes site using [Hugo](https://gohugo.io/). +- The source is in [GitHub](https://github.com/kubernetes/website). You can find Kubernetes documentation at `/content/en/docs/`. Some of the reference documentation is automatically generated from scripts in the `update-imported-docs/` directory. +- [Page content types](/docs/contribute/style/page-content-types/) describe the presentation of documentation content in Hugo. +- In addition to the standard Hugo shortcodes, we use a number of [custom Hugo shortcodes](/docs/contribute/style/hugo-shortcodes/) in our documentation to control the presentation of content. +- Documentation source is available in multiple languages in `/content/`. Each language has its own folder with a two-letter code determined by the [ISO 639-1 standard](https://www.loc.gov/standards/iso639-2/php/code_list.php). For example, English documentation source is stored in `/content/en/docs/`. +- For more information about contributing to documentation in multiple languages or starting a new translation, see [localization](/docs/contribute/localization). +--> +## 基本知识 + +- 使用 Markdown 来编写 Kubernetes 文档并使用 [Hugo](https://gohugo.io/) 来构建网站 +- 源代码位于 [GitHub](https://github.com/kubernetes/website) 仓库中。 + 你可以在 `/content/en/docs/` 目录下找到 Kubernetes 文档。 + 某些参考文档是使用位于 `update-imported-docs/` 目录下的脚本自动生成的。 +- [页面内容类型](/zh/docs/contribute/style/page-content-types/)使用 Hugo 描述文档内容的表现。 +- 除了基本的 Hugo 短代码（shortcodes）外，我们还在文档中使用一些 + [定制的 Hugo 短代码](/zh/docs/contribute/style/hugo-shortcodes/)以控制内容的表现。 +- 文档的源代码有多种语言形式，位于`/content/` 目录下。 + 每种语言都有自己的由两个字母代表的目录，这两个字母是基于 + [ISO 639-1 标准](https://www.loc.gov/standards/iso639-2/php/code_list.php)来确定的。 + 例如，英语文档源码位于`/content/en/docs/` 目录下。 +- 关于在多种语言中为文档做贡献的详细信息，以及如何启动一种新的语言翻译， + 可参考[本地化](/zh/docs/contribute/localization)文档。 + +<!-- +## Before you begin {#before-you-begin} +### Sign the CNCF CLA {#sign-the-cla} + +All Kubernetes contributors **must** read the [Contributor guide](https://github.com/kubernetes/community/blob/master/contributors/guide/README.md) and [sign the Contributor License Agreement (CLA)](https://github.com/kubernetes/community/blob/master/CLA.md). + +Pull requests from contributors who haven't signed the CLA fail the automated tests. The name and email you provide must match those found in your `git config`, and your git name and email must match those used for the CNCF CLA. +--> +## 开始之前 {#before-you-begin} + +### 签署 CNCF CLA {#sign-the-cla} + +所有 Kubernetes 贡献者 **必须** 阅读 +[贡献者指南](https://github.com/kubernetes/community/blob/master/contributors/guide/README.md) +并[签署贡献者授权同意书（Contributor License Agreement，CLA）](https://github.com/kubernetes/community/blob/master/CLA.md)。 + +来自尚未签署 CLA 的贡献者的 PR 无法通过自动化服务的测试。 +你所提供的姓名和邮件地址必须与 `git config` 中所找到的完全相同， +而且你的 git 用户名和邮件地址必须与用来签署 CNCF CLA 的一致。 + +<!-- +### Choose which Git branch to use + +When opening a pull request, you need to know in advance which branch to base your work on. + +Scenario | Branch +:---------|:------------ +Existing or new English language content for the current release | `master` +Content for a feature change release | The branch which corresponds to the major and minor version the feature change is in, using the pattern `dev-release-<version>`. For example, if a feature changes in the `{{< latest-version >}}` release, then add documentation changes to the ``dev-{{< release-branch >}}`` branch. +Content in other languages (localizations) | Use the localization's convention. See the [Localization branching strategy](/docs/contribute/localization/#branching-strategy) for more information. + +If you're still not sure which branch to choose, ask in `#sig-docs` on Slack. +--> +### 选择要使用的分支 + +在发起拉取请求时，你需要预先知道要基于哪个分支来开展工作。 + +场景 | 分支 +:---------|:------------ +针对当前发行版本的，对现有英文内容的修改或新的英文内容 | `master` +针对功能特性变更的内容 | 功能特性所对应的版本所对应的分支，分支名字模式为 `dev-release-<version>`。例如，如果某功能特性在 `{{< latest-version >}}` 版本发生变化，则对应的文档变化要添加到 `dev-{{< release-branch >}}` 分支。 +其他语言的内容（本地化）| 基于本地化团队的约定。参见[本地化分支策略](/zh/docs/contribute/localization/#branching-strategy)了解更多信息。 + +如果你仍不能确定要选择哪个分支，请在 `#sig-docs` Slack 频道上提问。 + +<!-- +If you already submitted your pull request and you know that the base branch +was wrong, you (and only you, the submitter) can change it. +--> +{{< note >}} +如果你已经提交了你的 PR，并且你发现所针对的分支选错了，你（且只能是你）可以重新选择分支。 +{{< /note >}} + +<!-- +### Languages per PR +Limit pull requests to one language per PR. If you need to make an identical change to the same code sample in multiple languages, open a separate PR for each language. +--> +### 每个 PR 牵涉的语言 + +请限制每个 PR 仅涉及一种语言。 +如果你需要对多种语言下的同一代码示例进行相同的修改，也请为每种语言发起一个独立的 PR。 + +<!-- +## Tools for contributors +The [doc contributors tools](https://github.com/kubernetes/website/tree/master/content/en/docs/doc-contributor-tools) directory in the `kubernetes/website` repository contains tools to help your contribution journey go more smoothly. +--> + +## 为贡献者提供的工具 + +`kubernetes/website` 仓库的 +[文档贡献者工具](https://github.com/kubernetes/website/tree/master/content/en/docs/doc-contributor-tools) +目录中包含了一些工具，能够助你的贡献过程更为顺畅。 + diff --git a/content/zh/docs/contribute/participate/_index.md b/content/zh/docs/contribute/participate/_index.md new file mode 100644 index 0000000000..1fcab79b2a --- /dev/null +++ b/content/zh/docs/contribute/participate/_index.md @@ -0,0 +1,225 @@ +--- +title: 参与 SIG Docs +content_type: concept +weight: 60 +card: + name: contribute + weight: 60 +--- +<!-- +title: Participating in SIG Docs +content_type: concept +weight: 60 +card: + name: contribute + weight: 60 +--> + +<!-- overview --> + +<!-- +SIG Docs is one of the +[special interest groups](https://github.com/kubernetes/community/blob/master/sig-list.md) +within the Kubernetes project, focused on writing, updating, and maintaining +the documentation for Kubernetes as a whole. See +[SIG Docs from the community github repo](https://github.com/kubernetes/community/tree/master/sig-docs) +for more information about the SIG. +--> +SIG Docs 是 Kubernetes 项目 +[特别兴趣小组](https://github.com/kubernetes/community/blob/master/sig-list.md) +中的一个，负责编写、更新和维护 Kubernetes 的总体文档。 +参见[社区 GitHub 仓库中 SIG Docs](https://github.com/kubernetes/community/tree/master/sig-docs) +以进一步了解该 SIG。 + +<!-- +SIG Docs welcomes content and reviews from all contributors. Anyone can open a +pull request (PR), and anyone is welcome to file issues about content or comment +on pull requests in progress. +--> +SIG Docs 欢迎所有贡献者提供内容和审阅。任何人可以提交拉取请求（PR）。 +欢迎所有人对文档内容创建 Issue 和对正在处理中的 PR 进行评论。 + +<!-- +You can also become a [member](/docs/contribute/participating/roles-and-responsibilities/#members), +[reviewer](/docs/contribute/participating/roles-and-responsibilities/#reviewers), or [approver](/docs/contribute/participating/roles-and-responsibilities/#approvers). These roles require greater +access and entail certain responsibilities for approving and committing changes. +See [community-membership](https://github.com/kubernetes/community/blob/master/community-membership.md) +for more information on how membership works within the Kubernetes community. + +The rest of this document outlines some unique ways these roles function within +SIG Docs, which is responsible for maintaining one of the most public-facing +aspects of Kubernetes - the Kubernetes website and documentation. +--> +你也可以成为[成员（member）](/docs/contribute/participating/roles-and-responsibilities/#members)、 +[评阅人（reviewer）](/docs/contribute/participating/roles-and-responsibilities/#reviewers) 或者 +[批准人（approver）](/docs/contribute/participating/roles-and-responsibilities/#approvers)。 +这些角色拥有更高的权限，且需要承担批准和提交变更的责任。 +有关 Kubernetes 社区中的成员如何工作的更多信息，请参见 +[社区成员身份](https://github.com/kubernetes/community/blob/master/community-membership.md)。 + +本文档的其余部分概述了这些角色在 SIG Docs 中发挥作用的一些独特方式。 +SIG Docs 负责维护 Kubernetes 最面向公众的方面之一 —— Kubernetes 网站和文档。 + +<!-- body --> + +<!-- +#### SIG Docs chairperson + +Each SIG, including SIG Docs, selects one or more SIG members to act as +chairpersons. These are points of contact between SIG Docs and other parts of +the Kubernetes organization. They require extensive knowledge of the structure +of the Kubernetes project as a whole and how SIG Docs works within it. See +[Leadership](https://github.com/kubernetes/community/tree/master/sig-docs#leadership) +for the current list of chairpersons. +--> +## SIG Docs 主席 + +每个 SIG，包括 SIG Docs，都会选出一位或多位成员作为主席。 +主席会成为 SIG Docs 和其他 Kubernetes 组织的联络接口人。 +他们需要了解整个 Kubernetes 项目的架构，并明白 SIG Docs 如何在其中运作。 +如需查询当前的主席名单，请查阅 +[领导人员](https://github.com/kubernetes/community/tree/master/sig-docs#leadership)。 + +<!-- +## SIG Docs teams and automation + +Automation in SIG Docs relies on two different mechanisms for automation: +GitHub groups and OWNERS files. +--> +## SIG Docs 团队和自动化 {#sig-docs-teams-and-automation} + +SIG 文档中的自动化服务依赖于两种不同的自动化机制: +GitHub 组和 OWNERS 文件。 + +<!-- +### GitHub teams + +There are two categories of SIG Docs [teams](https://github.com/orgs/kubernetes/teams?query=sig-docs) on GitHub: + +- `@sig-docs-{language}-owners` are approvers and leads +- `@sig-docs-{language}-reviewers` are reviewers + +Each can be referenced with their `@name` in GitHub comments to communicate with +everyone in that group. + +Sometimes Prow and GitHub teams overlap without matching exactly. For assignment of issues, pull requests, and to support PR approvals, +the automation uses information from `OWNERS` files. +--> +### GitHub 团队 {#github-teams} + +GitHub 上有两类 SIG Docs 团队： + +- `@sig-docs-{language}-owners` 包含批准人和牵头人 +- `@sig-docs-{language}-reviewers` 包含评阅人 + +可以在 GitHub 的评论中使用团队的名称 `@name` 来与团队成员沟通。 + +有时候 Prow 所定义的团队和 GitHub 团队有所重叠，并不完全一致。 +对于指派 Issue、PR 和批准 PR，自动化工具使用来自 `OWNERS` 文件的信息。 + +<!-- +### OWNERS files and front-matter + +The Kubernetes project uses an automation tool called prow for automation +related to GitHub issues and pull requests. The +[Kubernetes website repository](https://github.com/kubernetes/website) uses +two [prow plugins](https://github.com/kubernetes/test-infra/blob/master/prow/plugins): +--> +### OWNERS 文件和扉页 + +Kubernetes 项目使用名为 prow 的自动化工具来自动处理 GitHub issue 和 PR。 +[Kubernetes website 仓库](https://github.com/kubernetes/website) 使用了两个 +[prow 插件](https://github.com/kubernetes/test-infra/blob/master/prow/plugins)： + +- blunderbuss +- approve + +<!-- +These two plugins use the +[OWNERS](https://github.com/kubernetes/website/blob/master/OWNERS) and +[OWNERS_ALIASES](https://github.com/kubernetes/website/blob/master/OWNERS_ALIASES) +files in the top level of the `kubernetes/website` GitHub repository to control +how prow works within the repository. +--> +这两个插件使用位于 `kubernetes/website` 仓库顶层的 +[OWNERS](https://github.com/kubernetes/website/blob/master/OWNERS) 文件和 +[OWNERS_ALIASES](https://github.com/kubernetes/website/blob/master/OWNERS_ALIASES) +文件来控制 prow 在仓库范围的工作方式。 + +<!-- +An OWNERS file contains a list of people who are SIG Docs reviewers and +approvers. OWNERS files can also exist in subdirectories, and can override who +can act as a reviewer or approver of files in that subdirectory and its +descendents. For more information about OWNERS files in general, see +[OWNERS](https://github.com/kubernetes/community/blob/master/contributors/guide/owners.md). +--> +OWNERS 文件包含 SIG Docs 评阅人和批准人的列表。 +OWNERS 文件也可以存在于子目录中，可以在子目录层级重新设置哪些人可以作为评阅人和 +批准人，并将这一设定传递到下层子目录。 +关于 OWNERS 的更多信息，请参考 +[OWNERS](https://github.com/kubernetes/community/blob/master/contributors/guide/owners.md) +文档。 + +<!-- +In addition, an individual Markdown file can list reviewers and approvers in its +front-matter, either by listing individual GitHub usernames or GitHub groups. + +The combination of OWNERS files and front-matter in Markdown files determines +the advice PR owners get from automated systems about who to ask for technical +and editorial review of their PR. +--> +此外，每个独立的 Markdown 文件都可以在其前言部分列出评阅人和批准人， +每一项可以是 GitHub 用户名，也可以是 GitHub 组名。 + +结合 OWNERS 文件及 Markdown 文件的前言信息，自动化系统可以给 PR 作者可以就应该 +向谁请求技术和文字评阅给出建议。 + +<!-- +## How merging works + +When a pull request is merged to the branch used to publish content, that content +is published to http://kubernetes.io. To ensure that +the quality of our published content is high, we limit merging pull requests to +SIG Docs approvers. Here's how it works. + +- When a pull request has both the `lgtm` and `approve` labels, has no `hold` + labels, and all tests are passing, the pull request merges automatically. +- Kubernetes organization members and SIG Docs approvers can add comments to + prevent automatic merging of a given pull request (by adding a `/hold` comment + or withholding a `/lgtm` comment). +- Any Kubernetes member can add the `lgtm` label by adding a `/lgtm` comment. +- Only SIG Docs approvers can merge a pull request + by adding an `/approve` comment. Some approvers also perform additional + specific roles, such as [PR Wrangler](/docs/contribute/advanced#be-the-pr-wrangler-for-a-week) or + [SIG Docs chairperson](#sig-docs-chairperson). +--> +## PR 是怎样被合并的 {#how-merging-works} + +当某个拉取请求（PR）被合并到用来发布内容的分支，对应的内容就会被发布到 http://kubernetes.io。 +为了确保我们所发布的内容的质量足够好，合并 PR 的权限仅限于 +SIG Docs 批准人。下面是合并的工作机制： + +- 当某个 PR 同时具有 `lgtm` 和 `approve` 标签，没有 `hold` 标签且通过所有测试时， + 该 PR 会被自动合并。 +- Kubernetes 组织的成员和 SIG Docs 批准人可以添加评论以阻止给定 PR 的自动合并， + 即通过 `/hold` 评论或者收回某个 `/lgtm` 评论实现这点。 +- 所有 Kubernetes 成员可以通过 `/lgtm` 评论添加 `lgtm` 标签。 +- 只有 SIG Docs 批准人可以通过评论 `/approve` 合并 PR。 + 某些批准人还会执行一些其他角色，例如 + [PR 管理者](/zh/docs/contribute/participate/pr-wranglers/) 或 + [SIG Docs 主席](#sig-docs-chairperson)等。 + +## {{% heading "whatsnext" %}} + +<!-- +For more information about contributing to the Kubernetes documentation, see: + +- [Contributing new content](/docs/contribute/overview/) +- [Reviewing content](/docs/contribute/review/reviewing-prs) +- [Documentation style guide](/docs/contribute/style/) +--> +关于贡献 Kubernetes 文档的更多信息，请参考： + +- [贡献新内容](/zh/docs/contribute/new-content/overview/) +- [评阅内容](/zh/docs/contribute/review/reviewing-prs) +- [文档样式指南](/zh/docs/contribute/style/) diff --git a/content/zh/docs/contribute/participate/pr-wranglers.md b/content/zh/docs/contribute/participate/pr-wranglers.md new file mode 100644 index 0000000000..1199c5e865 --- /dev/null +++ b/content/zh/docs/contribute/participate/pr-wranglers.md @@ -0,0 +1,157 @@ +--- +title: PR 管理者 +content_type: concept +weight: 20 +--- +<!-- +title: PR wranglers +content_type: concept +weight: 20 +--> + +<!-- overview --> +<!-- +SIG Docs [approvers](/docs/contribute/participating/roles-and-responsibilites/#approvers) take week-long shifts [managing pull requests](https://github.com/kubernetes/website/wiki/PR-Wranglers) for the repository. + +This section covers the duties of a PR wrangler. For more information on giving good reviews, see [Reviewing changes](/docs/contribute/review/). +--> +SIG Docs 的[批准人（Approvers）](/zh/docs/contribute/participating/#approvers)们每周轮流负责 +[管理仓库的 PRs](https://github.com/kubernetes/website/wiki/PR-Wranglers)。 + +本节介绍 PR 管理者的职责。关于如何提供较好的评审意见，可参阅 +[评审变更](/zh/docs/contribute/review/). + + +<!-- body --> +<!-- +## Duties + +Each day in a week-long shift as PR Wrangler: + +- Triage and tag incoming issues daily. See [Triage and categorize issues](/docs/contribute/review/for-approvers/#triage-and-categorize-issues) for guidelines on how SIG Docs uses metadata. +- Review [open pull requests](https://github.com/kubernetes/website/pulls) for quality and adherence to the [Style](/docs/contribute/style/style-guide/) and [Content](/docs/contribute/style/content-guide/) guides. + - Start with the smallest PRs (`size/XS`) first, and end with the largest (`size/XXL`). Review as many PRs as you can. +- Make sure PR contributors sign the [CLA](https://github.com/kubernetes/community/blob/master/CLA.md). + - Use [this](https://github.com/zparnold/k8s-docs-pr-botherer) script to remind contributors that haven’t signed the CLA to do so. +- Provide feedback on changes and ask for technical reviews from members of other SIGs. + - Provide inline suggestions on the PR for the proposed content changes. + - If you need to verify content, comment on the PR and request more details. + - Assign relevant `sig/` label(s). + - If needed, assign reviewers from the `reviewers:` block in the file's front matter. +- Use the `/approve` comment to approve a PR for merging. Merge the PR when ready. + - PRs should have a `/lgtm` comment from another member before merging. + - Consider accepting technically accurate content that doesn't meet the [style guidelines](/docs/contribute/style/style-guide/). Open a new issue with the label `good first issue` to address style concerns. +--> +## 职责 {#duties} +在为期一周的轮值期内，PR 管理者要： + +- 每天对新增的 Issues 判定和打标签。参见 + [对 Issues 进行判定和分类](/zh/docs/contribute/review/for-approvers/#triage-and-categorize-issues) + 以了解 SIG Docs 如何使用元数据的详细信息。 +- 检查[悬决的 PR](https://github.com/kubernetes/website/pulls) 的质量并确保它们符合 + [样式指南](/zh/docs/contribute/style/style-guide/)和 + [内容指南](/zh/docs/contribute/style/content-guide/)要求。 + + - 首先查看最小的 PR（`size/XS`），然后逐渐扩展到最大的 + PR（`size/XXL`），尽可能多地评审 PR。 +- 确保贡献者完成 [CLA](https://github.com/kubernetes/community/blob/master/CLA.md) 签署。 + - 使用[此脚本](https://github.com/zparnold/k8s-docs-pr-botherer)自动提醒尚未签署 + CLA 的贡献者签署 CLA。 +- 针对提供提供反馈，请求其他 SIG 的成员进行技术审核。 + - 为 PR 所建议的内容更改提供就地反馈。 + - 如果您需要验证内容，请在 PR 上发表评论并要求贡献者提供更多细节。 + - 设置相关的 `sig/` 标签。 + - 如果需要，从文件开头的 `reviewers:` 块中指派评阅人。 +- 使用 `/approve` 评论来批准可以合并的 PR，在 PR 就绪时将其合并。 + - PR 在被合并之前，应该有来自其他成员的 `/lgtm` 评论。 + - 可以考虑接受那些技术上准确，但文风上不满足 + [风格指南](/zh/docs/contribute/style/style-guide/)要求的 PR。 + 可以登记一个新的 Issue 来解决文档风格问题，并将其标记为 `good first issue`。 + +<!-- +### Helpful GitHub queries for wranglers + +The following queries are helpful when wrangling. +After working through these queries, the remaining list of PRs to review is usually small. +These queries exclude localization PRs. All queries are against the main branch except the last one. +--> +### 对于管理人有用的 GitHub 查询 + +执行管理操作时，以下查询很有用。完成以下这些查询后，剩余的要审阅的 PR 列表通常很小。 +这些查询都不包含本地化的 PR，并仅包含主分支上的 PR（除了最后一个查询）。 + +<!-- +- [No CLA, not eligible to merge](https://github.com/kubernetes/website/pulls?q=is%3Aopen+is%3Apr+label%3A%22cncf-cla%3A+no%22+-label%3A%22do-not-merge%2Fwork-in-progress%22+-label%3A%22do-not-merge%2Fhold%22+label%3Alanguage%2Fen): + Remind the contributor to sign the CLA. If both the bot and a human have reminded them, close + the PR and remind them that they can open it after signing the CLA. + **Do not review PRs whose authors have not signed the CLA!** +- [Needs LGTM](https://github.com/kubernetes/website/pulls?q=is%3Aopen+is%3Apr+-label%3A%22cncf-cla%3A+no%22+-label%3Ado-not-merge%2Fwork-in-progress+-label%3Ado-not-merge%2Fhold+label%3Alanguage%2Fen+-label%3Algtm): + Lists PRs that need an LGTM from a member. If the PR needs technical review, loop in one of the reviewers suggested by the bot. If the content needs work, add suggestions and feedback in-line. +- [Has LGTM, needs docs approval](https://github.com/kubernetes/website/pulls?q=is%3Aopen+is%3Apr+-label%3Ado-not-merge%2Fwork-in-progress+-label%3Ado-not-merge%2Fhold+label%3Alanguage%2Fen+label%3Algtm+): + Lists PRs that need an `/approve` comment to merge. +- [Quick Wins](https://github.com/kubernetes/website/pulls?utf8=%E2%9C%93&q=is%3Apr+is%3Aopen+base%3Amaster+-label%3A%22do-not-merge%2Fwork-in-progress%22+-label%3A%22do-not-merge%2Fhold%22+label%3A%22cncf-cla%3A+yes%22+label%3A%22size%2FXS%22+label%3A%22language%2Fen%22): Lists PRs against the main branch with no clear blockers. (change "XS" in the size label as you work through the PRs [XS, S, M, L, XL, XXL]). +- [Not against the main branch](https://github.com/kubernetes/website/pulls?q=is%3Aopen+is%3Apr+label%3Alanguage%2Fen+-base%3Amaster): If the PR is against a `dev-` branch, it's for an upcoming release. Assign the [docs release manager](https://github.com/kubernetes/sig-release/tree/master/release-team#kubernetes-release-team-roles) using: `/assign @<manager's_github-username>`. If the PR is against an old branch, help the author figure out whether it's targeted against the best branch. +--> +- [未签署 CLA，不可合并的 PR](https://github.com/kubernetes/website/pulls?q=is%3Aopen+is%3Apr+label%3A%22cncf-cla%3A+no%22+-label%3A%22do-not-merge%2Fwork-in-progress%22+-label%3A%22do-not-merge%2Fhold%22+label%3Alanguage%2Fen)： + 提醒贡献者签署 CLA。如果机器人和审阅者都已经提醒他们，请关闭 PR，并提醒他们在签署 CLA 后可以重新提交。 + **在作者没有签署 CLA 之前，不要审阅他们的 PR！** + +- [需要 LGTM](https://github.com/kubernetes/website/pulls?q=is%3Aopen+is%3Apr+-label%3A%22cncf-cla%3A+no%22+-label%3Ado-not-merge%2Fwork-in-progress+-label%3Ado-not-merge%2Fhold+label%3Alanguage%2Fen+-label%3Algtm)： + 列举需要来自成员的 LGTM 评论的 PR。 + 如果需要技术审查，请告知机器人所建议的审阅者。 + 如果 PR 继续改进，就地提供更改建议或反馈。 + +- [已有 LGTM标签，需要 Docs 团队批准](https://github.com/kubernetes/website/pulls?q=is%3Aopen+is%3Apr+-label%3Ado-not-merge%2Fwork-in-progress+-label%3Ado-not-merge%2Fhold+label%3Alanguage%2Fen+label%3Algtm+)： + 列举需要 `/approve` 评论来合并的 PR。 + +- [快速批阅](https://github.com/kubernetes/website/pulls?utf8=%E2%9C%93&q=is%3Apr+is%3Aopen+base%3Amaster+-label%3A%22do-not-merge%2Fwork-in-progress%22+-label%3A%22do-not-merge%2Fhold%22+label%3A%22cncf-cla%3A+yes%22+label%3A%22size%2FXS%22+label%3A%22language%2Fen%22)： + 列举针对主分支的、没有明确合并障碍的 PR。 + 在浏览 PR 时，可以将 "XS" 尺寸标签更改为 "S"、"M"、"L"、"XL"、"XXL"。 + +- [非主分支的 PR](https://github.com/kubernetes/website/pulls?q=is%3Aopen+is%3Apr+label%3Alanguage%2Fen+-base%3Amaster)： + 如果 PR 针对 `dev-` 分支，则表示它适用于即将发布的版本。 + 请添加带有 `/assign @<负责人的 github 账号>`，将其指派给 + [发行版本负责人](https://github.com/kubernetes/sig-release/tree/master/release-team)。 + 如果 PR 是针对旧分支，请帮助 PR 作者确定是否所针对的是最合适的分支。 + +<!-- +### When to close Pull Requests + +Reviews and approvals are one tool to keep our PR queue short and current. Another tool is closure. + +Close PRs where: +- The author hasn't signed the CLA for two weeks. + + Authors can reopen the PR after signing the CLA. This is a low-risk way to make sure nothing gets merged without a signed CLA. + +- The author has not responded to comments or feedback in 2 or more weeks. + +Don't be afraid to close pull requests. Contributors can easily reopen and resume works in progress. Often a closure notice is what spurs an author to resume and finish their contribution. + +To close a pull request, leave a `/close` comment on the PR. +--> +### 何时关闭 PR {#when-to-close-pull-requests} + +审查和批准是缩短和更新我们的 PR 队列的一种方式；另一种方式是关闭 PR。 + +当以下条件满足时，可以关闭 PR： + +- 作者两周内未签署 CLA。 + PR 作者可以在签署 CLA 后重新打开 PR，因此这是确保未签署 CLA 的 PR 不会被合并的一种风险较低的方法。 + +- 作者在两周或更长时间内未回复评论或反馈。 + +不要害怕关闭 PR。贡献者可以轻松地重新打开并继续工作。 +通常，关闭通知会激励作者继续完成其贡献。 + +要关闭 PR，请在 PR 上输入 `/close` 评论。 + +<!-- +The [`fejta-bot`](https://github.com/fejta-bot) bot marks issues as stale after 90 days of inactivity. After 30 more days it marks issues as rotten and closes them. PR wranglers should close issues after 14-30 days of inactivity. +--> +{{< note >}} +一个名为 [`fejta-bot`](https://github.com/fejta-bot) 的自动服务会在 Issue 停滞 90 +天后自动将其标记为过期；然后再等 30 天，如果仍然无人过问，则将其关闭。 +PR 管理者应该在 issues 处于无人过问状态 14-30 天后关闭它们。 +{{< /note >}} + diff --git a/content/zh/docs/contribute/participate/roles-and-responsibilities.md b/content/zh/docs/contribute/participate/roles-and-responsibilities.md new file mode 100644 index 0000000000..c1359d7171 --- /dev/null +++ b/content/zh/docs/contribute/participate/roles-and-responsibilities.md @@ -0,0 +1,417 @@ +--- +title: 角色与责任 +content_type: concept +weight: 10 +--- + +<!-- overview --> + +<!-- +Anyone can contribute to Kubernetes. As your contributions to SIG Docs grow, you can apply for different levels of membership in the community. +These roles allow you to take on more responsibility within the community. +Each role requires more time and commitment. The roles are: + +- Anyone: regular contributors to the Kubernetes documentation +- Members: can assign and triage issues and provide non-binding review on pull requests +- Reviewers: can lead reviews on documentation pull requests and can vouch for a change's quality +- Approvers: can lead reviews on documentation and merge changes +--> +任何人都可以为 Kubernetes 作出贡献。随着你对 SIG Docs 的贡献增多，你可以申请 +社区内不同级别的成员资格。 +这些角色使得你可以在社区中承担更多的责任。 +每个角色都需要更多的时间和投入。具体包括： + +- 任何人（Anyone）：为 Kubernetes 文档作出贡献的普通贡献者。 +- 成员（Members）：可以对 Issue 进行分派和判别，对 PR 提出无约束性的评审意见。 +- 评审人（Reviewers）：可以领导对文档 PR 的评审，可以对变更的质量进行判别。 +- 批准人（Approvers）：可以领导对文档的评审并合并变更。 + +<!-- body --> + +<!-- +## Anyone + +Anyone with a GitHub account can contribute to Kubernetes. SIG Docs welcomes all new contributors! + +Anyone can: + +- Open an issue in any [Kubernetes](https://github.com/kubernetes/) repository, including [`kubernetes/website`](https://github.com/kubernetes/website) +- Give non-binding feedback on a pull request +- Contribute to a localization +- Suggest improvements on [Slack](http://slack.k8s.io/) or the [SIG docs mailing list](https://groups.google.com/forum/#!forum/kubernetes-sig-docs). + +After [signing the CLA](/docs/contribute/new-content/overview/#sign-the-cla), anyone can also: + +- Open a pull request to improve existing content, add new content, or write a blog post or case study +- Create diagrams, graphics assets, and embeddable screencasts and videos + +For more information, see [contributing new content](/docs/contribute/new-content/). +--> +## 任何人（Anyone） {#anyone} + +任何拥有 GitHub 账号的人都可以对 Kubernetes 作出贡献。SIG Docs +欢迎所有新的贡献者。 + +任何人都可以： + +- 在任何 [Kubernetes](https://github.com/kubernetes/) 仓库，包括 + [`kubernetes/website`](https://github.com/kubernetes/website) 上报告 Issue。 +- 对某 PR 给出无约束力的反馈信息 +- 为本地化提供帮助 +- 在 [Slack](https://slack.k8s.io/) 或 + [SIG Docs 邮件列表](https://groups.google.com/forum/#!forum/kubernetes-sig-docs) + 上提出改进建议。 + +在[签署了 CLA](/zh/docs/contribute/new-content/overview/#sign-the-cla) 之后，任何人还可以： + +- 发起拉取请求（PR），改进现有内容、添加新内容、撰写博客或者案例分析 +- 创建示意图、图形资产或者嵌入式的截屏和视频内容 + +进一步的详细信息，可参见[贡献新内容](/zh/docs/contribute/new-content/)。 + +<!-- +## Members + +A member is someone who has submitted multiple pull requests to `kubernetes/website`. Members are a part of the [Kubernetes GitHub organization](https://github.com/kubernetes). + +Members can: + +- Do everything listed under [Anyone](#anyone) +- Use the `/lgtm` comment to add the LGTM (looks good to me) label to a pull request + + {{< note >}} + Using `/lgtm` triggers automation. If you want to provide non-binding approval, simply commenting "LGTM" works too! + {{< /note >}} +- Use the `/hold` comment to block merging for a pull request +- Use the `/assign` comment to assign a reviewer to a pull request +- Provide non-binding review on pull requests +- Use automation to triage and categorize issues +- Document new features +--> +## 成员（Members） {#members} + +成员是指那些对 `kubernetes/website` 提交很多拉取请求（PR）的人。 +成员都要加入 [Kubernetes GitHub 组织](https://github.com/kubernetes)。 + +成员可以： + +- 执行[任何人](#anyone)节区所列举操作 +- 使用 `/lgtm` 评论添加 LGTM (looks good to me（我觉得可以）) 标签到某个 PR + + {{< note >}} + 使用 `/lgtm` 会触发自动化机制。如果你希望提供不拘约束力的批准意见， + 直接回复 "LGTM" 也是可以的。 + {{< /note >}} +- 利用 `/hold` 评论来阻止某个 PR 被合并 +- 使用 `/assign` 评论为某个 PR 指定评审人 +- 对 PR 提供非约束性的评审意见 +- 使用自动化机制来对 Issue 进行判别和分类 +- 为新功能特性撰写文档 + +<!-- +### Becoming a member + +After submitting at least 5 substantial pull requests and meeting the other [requirements](https://github.com/kubernetes/community/blob/master/community-membership.md#member): +--> +### 成为一个成员 {#becoming-a-member} + +在你成功地提交至少 5 个 PR 并满足 +[相关条件](https://github.com/kubernetes/community/blob/master/community-membership.md#member) +之后： + +<!-- +1. Find two [reviewers](#reviewers) or [approvers](#approvers) to [sponsor](/docs/contribute/advanced#sponsor-a-new-contributor) your membership. + + Ask for sponsorship in the [#sig-docs channel on Slack](https://kubernetes.slack.com) or on the + [SIG Docs mailing list](https://groups.google.com/forum/#!forum/kubernetes-sig-docs). + + {{< note >}} + Don't send a direct email or Slack direct message to an individual + SIG Docs member. You must request sponsorship before submitting your application. + {{< /note >}} + +2. Open a GitHub issue in the [`kubernetes/org`](https://github.com/kubernetes/org/) repository. Use the **Organization Membership Request** issue template. +--> +1. 找到两个[评审人](#reviewers)或[批准人](#approvers)为你的成员身份提供 + [担保](/zh/docs/contribute/advanced#sponsor-a-new-contributor)。 + + 通过 [Kubernetes Slack 上的 #sig-docs 频道](https://kubernetes.slack.com) 或者 + [SIG Docs 邮件列表](https://groups.google.com/forum/#!forum/kubernetes-sig-docs) + 来寻找为你担保的人。 + + {{< note >}} + 不要单独发送邮件给某个 SIG Docs 成员或在 Slack 中与其私聊。 + 在提交申请之前，一定要先确定担保人。 + {{< /note >}} + +2. 在 [`kubernetes/org`](https://github.com/kubernetes/org/) 仓库 + 使用 **Organization Membership Request** Issue 模版登记一个 Issue。 + +<!-- +3. Let your sponsors know about the GitHub issue. You can either: + - Mention their GitHub username in an issue (`@<GitHub-username>`) + - Send them the issue link using Slack or email. + + Sponsors will approve your request with a `+1` vote. Once your sponsors approve the request, a Kubernetes GitHub admin adds you as a member. Congratulations! + + If your membership request is not accepted you will receive feedback. After addressing the feedback, apply again. + +4. Accept the invitation to the Kubernetes GitHub organization in your email account. + + {{< note >}} + GitHub sends the invitation to the default email address in your account. + {{< /note >}} +--> +3. 告知你的担保人你所创建的 Issue，你可以： + + - 在 Issue 中 `@<GitHub-username>` 提及他们的 GitHub 用户名 + - 通过 Slack 或 email 直接发送给他们 Issue 链接 + + 担保人会通过 `+1` 投票来批准你的请求。一旦你的担保人批准了该请求， + 某个 Kubernetes GitHub 管理员会将你添加为组织成员。恭喜！ + + 如果你的成员请求未被接受，你会收到一些反馈。 + 当处理完反馈意见之后，可以再次发起申请。 + +4. 在你的邮件账户中接受来自 Kubernetes GitHub 组织发出的成员邀请。 + + {{< note >}} + GitHub 会将邀请发送到你的账户中所设置的默认邮件地址。 + {{< /note >}} + +<!-- +## Reviewers + +Reviewers are responsible for reviewing open pull requests. Unlike member feedback, you must address reviewer feedback. Reviewers are members of the [@kubernetes/sig-docs-{language}-reviews](https://github.com/orgs/kubernetes/teams?query=sig-docs) GitHub team. + +Reviewers can: + +- Do everything listed under [Anyone](#anyone) and [Members](#members) +- Review pull requests and provide binding feedback + + {{< note >}} + To provide non-binding feedback, prefix your comments with a phrase like "Optionally: ". + {{< /note >}} + +- Edit user-facing strings in code +- Improve code comments + +You can be a SIG Docs reviewer, or a reviewer for docs in a specific subject area. +--> +## 评审人（Reviewers） {#reviewers} + +评审人负责评审悬决的 PR。 +与成员所给的反馈不同，你必须处理评审人的反馈。 +评审人是 [@kubernetes/sig-docs-{language}-reviews](https://github.com/orgs/kubernetes/teams?query=sig-docs) GitHub 团队的成员。 + +评审人可以： + +- 执行[任何人](#anyone)和[成员](#members)节所列举的操作 +- 评审 PR 并提供具约束性的反馈信息 + + {{< note >}} + 要提供非约束性的反馈，可以在你的评语之前添加 "Optionally: " 这样的说法。 + {{< /note >}} + +- 编辑代码中用户可见的字符串 +- 改进代码注释 + +你可以是 SIG Docs 的评审人，也可以是某个主题领域的文档的评审人。 + +<!-- +### Assigning reviewers to pull requests + +Automation assigns reviewers to all pull requests. You can request a +review from a specific person by commenting: `/assign +[@_github_handle]`. + +If the assigned reviewer has not commented on the PR, another reviewer can step in. You can also assign technical reviewers as needed. + +### Using `/lgtm` + +LGTM stands for "Looks good to me" and indicates that a pull request is technically accurate and ready to merge. All PRs need a `/lgtm` comment from a reviewer and a `/approve` comment from an approver to merge. + +A `/lgtm` comment from reviewer is binding and triggers automation that adds the `lgtm` label. +--> +### 为 PR 指派评审人 {#assigning-reviewers-to-pull-requests} + +自动化引擎会为每个 PR 自动指派评审人。 +你可以通过为 PR 添加评论 `/assign [@_github_handle]` 来请求某个特定评审人来评审。 + +如果所指派的评审人未能及时评审，其他的评审人也可以参与进来。 +你可以根据需要指派技术评审人。 + +### 使用 `/lgtm` + +LGTM 代表的是 “Looks Good To Me （我觉得可以）”，用来标示某个 PR +在技术上是准确的，可以被合并。 +所有 PR 都需要来自某评审人的 `/lgtm` 评论和来自某批准人的 `/approve` +评论。 + +来自评审人的 `/lgtm` 评论是具有约束性的，会触发自动化设施添加 `lgtm` 标签。 + +<!-- +### Becoming a reviewer + +When you meet the +[requirements](https://github.com/kubernetes/community/blob/master/community-membership.md#reviewer), you can become a SIG Docs reviewer. Reviewers in other SIGs must apply separately for reviewer status in SIG Docs. + +To apply: +--> +### 成为评审人 {#becoming-a-reviewer} + +当你满足[相关条件](https://github.com/kubernetes/community/blob/master/community-membership.md#reviewer)时， +你可以成为一个 SIG Docs 评审人。 +来自其他 SIG 的评审人必须为 SIG Docs 单独申请评审人资格。 + +申请过程如下： + +<!-- +1. Open a pull request that adds your GitHub user name to a section of the +[OWNERS_ALIASES](https://github.com/kubernetes/website/blob/master/OWNERS) file +in the `kubernetes/website` repository. + + {{< note >}} + If you aren't sure where to add yourself, add yourself to `sig-docs-en-reviews`. + {{< /note >}} + +2. Assign the PR to one or more SIG-Docs approvers (user names listed under `sig-docs-{language}-owners`). + +If approved, a SIG Docs lead adds you to the appropriate GitHub team. Once added, +[@k8s-ci-robot](https://github.com/kubernetes/test-infra/tree/master/prow#bots-home) assigns and suggests you as a reviewer on new pull requests. +--> +1. 发起 PR，将你的 GitHub 用户名添加到 `kubernetes/website` 仓库中 + [OWNERS_ALIASES](https://github.com/kubernetes/website/blob/master/OWNERS) + 文件的特定节。 + + {{< note >}} + 如果你不确定要添加到哪个位置，可以将自己添加到 `sig-docs-en-reviews`。 + {{< /note >}} + +2. 将 PR 指派给一个或多个 SIG Docs 批准人（`sig-docs-{language}-owners` + 下列举的用户名）。 + +请求被批准之后，SIG Docs Leads 之一会将你添加到合适的 GitHub 团队。 +一旦添加完成， [@k8s-ci-robot](https://github.com/kubernetes/test-infra/tree/master/prow#bots-home) +会在处理未来的 PR 时，将 PR 指派给你或者建议你来评审某 PR。 + +<!-- +## Approvers + +Approvers review and approve pull requests for merging. Approvers are members of the +[@kubernetes/sig-docs-{language}-owners](https://github.com/orgs/kubernetes/teams/?query=sig-docs) GitHub teams. + +--> +## 批准人（Approvers） {#approvers} + +批准人负责评审和批准 PR 以将其合并。 +批准人是 [@kubernetes/sig-docs-{language}-owners](https://github.com/orgs/kubernetes/teams/?query=sig-docs) GitHub 团队的成员。 + +<!-- +Approvers can do the following: + +- Everything listed under [Anyone](#anyone), [Members](#members) and [Reviewers](#reviewers) +- Publish contributor content by approving and merging pull requests using the `/approve` comment +- Propose improvements to the style guide +- Propose improvements to docs tests +- Propose improvements to the Kubernetes website or other tooling + +If the PR already has a `/lgtm`, or if the approver also comments with `/lgtm`, the PR merges automatically. A SIG Docs approver should only leave a `/lgtm` on a change that doesn't need additional technical review. +--> +批准人可以执行以下操作： + +- 执行列举在[任何人](#anyone)、[成员](#members)和[评审人](#reviewers)节区的操作 +- 通过使用 `/approve` 评论来批准、合并 PRs，发布贡献者所贡献的内容。 +- 就样式指南给出改进建议 +- 对文档测试给出改进建议 +- 对 Kubernetes 网站或其他工具给出改进建议 + +如果某个 PR 已有 `/lgtm` 标签，或者批准人再回复一个 `/lgtm` ，则这个 PR 会自动合并。 +SIG Docs 批准人应该只在不需要额外的技术评审的情况下才可以标记 `/lgtm`。 + +<!-- +### Approving pull requests + +Approvers and SIG Docs leads are the only ones who can merge pull requests into the website repository. This comes with certain responsibilities. + +- Approvers can use the `/approve` command, which merges PRs into the repo. + + {{< warning >}} + A careless merge can break the site, so be sure that when you merge something, you mean it. + {{< /warning >}} + +- Make sure that proposed changes meet the [contribution guidelines](/docs/contribute/style/content-guide/#contributing-content). + + If you ever have a question, or you're not sure about something, feel free to call for additional review. +--> +### 批准 PR {#approving-pull-requests} + +只有批准人和 SIG Docs Leads 可以将 PR 合并到网站仓库。 +这意味着以下责任： + +- 批准人可以使用 `/approve` 命令将 PR 合并到仓库中。 + + {{< warning >}} + 不小心的合并可能会破坏整个站点。在执行合并操作时，务必小心。 + {{< /warning >}} + +- 确保所提议的变更满足[贡献指南](/zh/docs/contribute/style/content-guide/#contributing-content)要求 + + 如果有问题或者疑惑，可以根据需要请他人帮助评审。 + +- 在 `/approve` PR 之前，须验证 Netlify 测试是否正常通过。 + + <img src="/images/docs/contribute/netlify-pass.png" width="75%" alt="批准之前必须通过 Netlify 测试" /> + +- 在批准之前，请访问 Netlify 的页面预览来确保变更内容可正常显示。 + +- 参与 [PR 管理者轮值排班](https://github.com/kubernetes/website/wiki/PR-Wranglers) + 执行时长为一周的 PR 管理。SIG Docs 期望所有批准人都参与到此轮值工作中。 + 更多细节可参见[做一周的 PR 管理者](/zh/docs/contribute/participate/pr-wranglers/)。 + +<!-- +### Becoming an approver + +When you meet the [requirements](https://github.com/kubernetes/community/blob/master/community-membership.md#approver), you can become a SIG Docs approver. Approvers in other SIGs must apply separately for approver status in SIG Docs. +--> +### 成为批准人 {#becoming-an-approver} + +当你满足[一定条件](https://github.com/kubernetes/community/blob/master/community-membership.md#approver)时，可以成为一个 SIG Docs 批准人。 +来自其他 SIGs 的批准人也必须在 SIG Docs 独立申请批准人资格。 + +<!-- +To apply: + +1. Open a pull request adding yourself to a section of the [OWNERS_ALIASES](https://github.com/kubernetes/website/blob/master/OWNERS) file in the `kubernetes/website` repository. + + {{< note >}} + If you aren't sure where to add yourself, add yourself to `sig-docs-en-owners`. + {{< /note >}} + +2. Assign the PR to one or more current SIG Docs approvers. + +If approved, a SIG Docs lead adds you to the appropriate GitHub team. Once added, [K8s-ci-robot](https://github.com/kubernetes/test-infra/tree/master/prow#bots-home) assigns and suggests you as a reviewer on new pull requests. +--> +申请流程如下： + +1. 发起一个 PR，将自己添加到 `kubernetes/website` 仓库中 + [OWNERS_ALIASES](https://github.com/kubernetes/website/blob/master/OWNERS) + 文件的对应节区。 + + {{< note >}} + 如果你不确定要添加到哪个位置，可以将自己添加到 `sig-docs-en-owners` 中。 + {{< /note >}} + +2. 将 PR 指派给一个或多个 SIG Docs 批准人。 + +请求被批准之后，SIG Docs Leads 之一会将你添加到对应的 GitHub 团队。 +一旦添加完成， [K8s-ci-robot](https://github.com/kubernetes/test-infra/tree/master/prow#bots-home) +会在处理未来的 PR 时，将 PR 指派给你或者建议你来评审某 PR。 + +## {{% heading "whatsnext" %}} + +<!-- +- Read about [PR wrangling](/docs/contribute/participating/pr-wranglers), a role all approvers take on rotation. +--> +- 阅读[管理 PR](/zh/docs/contribute/participate/pr-wranglers/)，了解所有批准人轮值的一个角色。 + diff --git a/content/zh/docs/contribute/participating.md b/content/zh/docs/contribute/participating.md deleted file mode 100644 index 5be3a872c8..0000000000 --- a/content/zh/docs/contribute/participating.md +++ /dev/null @@ -1,533 +0,0 @@ ---- -title: 参与 SIG Docs -content_type: concept -card: - name: contribute - weight: 40 ---- - -<!-- overview --> - -<!-- -SIG Docs is one of the -[special interest groups](https://github.com/kubernetes/community/blob/master/sig-list.md) -within the Kubernetes project, focused on writing, updating, and maintaining -the documentation for Kubernetes as a whole. See -[SIG Docs from the community github repo](https://github.com/kubernetes/community/tree/master/sig-docs) -for more information about the SIG. ---> -SIG Docs 是 Kubernetes 项目中的一个 [special interest groups](https://github.com/kubernetes/community/blob/master/sig-list.md)， -总的来说，它负责编写、更新和维护 Kubernetes 文档。 - -<!-- -SIG Docs welcomes content and reviews from all contributors. Anyone can open a -pull request (PR), and anyone is welcome to file issues about content or comment -on pull requests in progress. ---> -SIG Docs 欢迎所有贡献者提供内容和检视。任何人可以提交拉取请求（PR）， -欢迎对文档内容提交 issue 和 对正在进行中的 PR 进行评论。 - -<!-- -Within SIG Docs, you may also become a [member](#members), -[reviewer](#reviewers), or [approver](#approvers). These roles require greater -access and entail certain responsibilities for approving and committing changes. -See [community-membership](https://github.com/kubernetes/community/blob/master/community-membership.md) -for more information on how membership works within the Kubernetes community. -The rest of this document outlines some unique ways these roles function within -SIG Docs, which is responsible for maintaining one of the most public-facing -aspects of Kubernetes -- the Kubernetes website and documentation. ---> -在 SIG Docs，你可以成为 [member](#members)、[reviewer](#reviewers) 或者 [approver](#approvers)。 -这些角色拥有更高的权限，并且需要承担批准和提交更改的责任。 -有关 Kubernetes 社区中的成员如何工作的更多信息，请参见 [community-membership](https://github.com/kubernetes/community/blob/master/community-membership.md)。 -本文档的其余部分概述了这些角色在 SIG Docs 中发挥作用的一些独特方式， -SIG Docs 负责维护 Kubernetes 最面向公众的方面之一 —— Kubernetes 网站和文档。 - - -<!-- body --> - -<!-- -## Roles and responsibilities ---> -## 角色和责任 - -<!-- -When a pull request is merged to the branch used to publish content (currently -`master`), that content is published and available to the world. To ensure that -the quality of our published content is high, we limit merging pull requests to -SIG Docs approvers. Here's how it works. ---> - -当一个 pull 请求被合并到用于发布内容的分支(当前为“master”)，该内容将发布并向全世界开放。 -为了确保发布内容的质量较高，每个 pull 请求需要 SIG Docs 的 approver 审批。 -它是这样工作的。 - -<!-- -- When a pull request has both the `lgtm` and `approve` labels and has no `hold` - labels, the pull request merges automatically. -- Kubernetes organization members and SIG Docs approvers can add comments to - prevent automatic merging of a given pull request (by adding a `/hold` comment - or withholding a `/lgtm` comment). -- Any Kubernetes member can add the `lgtm` label, by adding a `/lgtm` comment. -- Only an approver who is a member of SIG Docs can cause a pull request to merge - by adding an `/approve` comment. Some approvers also perform additional - specific roles, such as [PR Wrangler](#pr-wrangler) or - [SIG Docs chairperson](#sig-docs-chairperson). ---> -- 当某个 pull request 拥有 `lgtm` 和 `approve` 标签， 并且没有 `hold` 标签时，这个 pull request 会自动合入。 -- Kubernetes 组织成员 和 SIG Docs 的 approvers 可以通过评论的方式阻止某个 pull request 自动合入（评论中包含 `/hold` 或 取消 `/lgtm` 的内容）。 -- 任何 Kubernetes 成员都可以通过在评论回复 `/lgtm` 来增加 `/lgtm` 标签。 -- 只有 SIG Docs 的 approver 可以在评论中回复 `/approve` 并触发合并。 - 某些 approver 还兼具其他角色，比如 [PR Wrangler](#pr-wrangler) 或 [SIG Docs chairperson](#sig-docs-chairperson)。 - -<!-- -For more information about expectations and differences between the roles of -Kubernetes organization member and SIG Docs approvers, see -[Types of contributor](/docs/contribute#types-of-contributor). The following -sections cover more details about these roles and how they work within -SIG Docs. ---> -关于 Kubernetes 组织成员和 SIG Docs approver 的区别，请参考 [Types of contributor](/docs/contribute#types-of-contributor)。 -以下部分将详细介绍这些角色及其内部的工作方式。 - -### Anyone - -<!-- -Anyone can file an issue against any part of Kubernetes, including documentation. ---> -任何人可以针对 Kubernetes 的任何内容（包括文档）提交 issue。 - -<!-- -Anyone who has signed the CLA can submit a pull request. If you cannot sign the -CLA, the Kubernetes project cannot accept your contribution. ---> -任何人想到提交 pull request，必须要签署 CLA。 否则 Kubernetes 项目则不能接受你的贡献。 - -### Members - -<!-- -Any member of the [Kubernetes organization](https://github.com/kubernetes) can -review a pull request, and SIG Docs team members frequently request reviews from -members of other SIGs for technical accuracy. -SIG Docs also welcomes reviews and feedback regardless of a person's membership -status in the Kubernetes organization. You can indicate your approval by adding -a comment of `/lgtm` to a pull request. If you are not a member of the -Kubernetes organization, your `/lgtm` has no effect on automated systems. ---> -任何 [Kubernetes 组织成员](https://github.com/kubernetes) 都可以检视 pull request。 -SIG Docs 组成员经常需要检视来自其他 SIG 的 pull request，以确保技术上的准确性。 - -<!-- -Any member of the Kubernetes organization can add a `/hold` comment to prevent -the pull request from being merged. Any member can also remove a `/hold` comment -to cause a PR to be merged if it already has both `/lgtm` and `/approve` applied -by appropriate people. ---> -作何 Kubernetes 组织成员都可以在评论中增加 `/hold` 标签来阻止 PR 被合入。 -任何 Kubernetes 组织成员都可以移除 `/hold` 标签来让PR 合入（必须此前已有 `/lgtm` 和 `/approve` 标签）。 - -<!-- -#### Becoming a member ---> -#### 成为一个 member - -<!-- -After you have successfully submitted at least 5 substantive pull requests, you -can request [membership](https://github.com/kubernetes/community/blob/master/community-membership.md#member) -in the Kubernetes organization. Follow these steps: ---> -在你成功的提交至少 5 个PR后，你就可以向 Kubernetes 组织提交申请 [membership](https://github.com/kubernetes/community/blob/master/community-membership.md#member)。 -按照如下流程： - -<!-- -1. Find two reviewers or approvers to [sponsor](/docs/contribute/advanced#sponsor-a-new-contributor) - your membership. - - Ask for sponsorship in the [#sig-docs channel on the - Kubernetes Slack instance](https://kubernetes.slack.com) or on the - [SIG Docs mailing list](https://groups.google.com/forum/#!forum/kubernetes-sig-docs). - - {{< note >}} - Don't send a direct email or Slack direct message to an individual - SIG Docs member. - {{< /note >}} - -2. Open a GitHub issue in the `kubernetes/org` repository to request membership. - Fill out the template using the guidelines at - [Community membership](https://github.com/kubernetes/community/blob/master/community-membership.md). - -3. Let your sponsors know about the GitHub issue, either by at-mentioning them - in the GitHub issue (adding a comment with `@<GitHub-username>`) or by sending them the link directly, - so that they can add a `+1` vote. - -4. When your membership is approved, the github admin team member assigned to your request updates the - GitHub issue to show approval and then closes the GitHub issue. - Congratulations, you are now a member! ---> -1. 找到两个 reviewer 或 approver 为你提名。 - - 通过 [#sig-docs channel on the Kubernetes Slack instance](https://kubernetes.slack.com) 或者 - [SIG Docs mailing list](https://groups.google.com/forum/#!forum/kubernetes-sig-docs) - 来寻找为你提名的人。 - {{< note >}} - 不要单独发送邮件给某个人或在 Slack 中私聊。 - {{< /note >}} - -2. 在 `kubernetes/org` 仓库中提交一个 issue 发起请求。 - 按照[指导模板](https://github.com/kubernetes/community/blob/master/community-membership.md)填写请求。 - -3. 告知你的提名人，可以通过在 issue 中 `@<GitHub-username>` 或者直接发送给他们 issue 链接， - 这样他们可以过来投票（`+1`）。 - -4. 当请求被批准后，github 管理员团队成员会告诉你批准加入并且关闭 issue："Congratulations, you are now a member!"。 - -<!-- -If for some reason your membership request is not accepted right away, the -membership committee provides information or steps to take before applying -again. ---> -如果因为某些原因你的申请没有被批准，会员委员会成员会告诉你原因并指导你如何继续申请。 - -### Reviewers - -<!-- -Reviewers are members of the -[@kubernetes/sig-docs-pr-reviews](https://github.com/orgs/kubernetes/teams/sig-docs-pr-reviews) -GitHub group. See [Teams and groups within SIG Docs](#teams-and-groups-within-sig-docs). ---> -Reviewers 是 [@kubernetes/sig-docs-pr-reviews](https://github.com/orgs/kubernetes/teams/sig-docs-pr-reviews) 成员。 - -<!-- -Reviewers review documentation pull requests and provide feedback on proposed -changes. ---> -Reviewers 负责检视文档的 PR 并提供反馈。 - -<!-- -Automation assigns reviewers to pull requests, and contributors can request a -review from a specific reviewer with a comment on the pull request: `/assign -[@_github_handle]`. To indicate that a pull request is technically accurate and -requires no further changes, a reviewer adds a `/lgtm` comment to the pull -request. ---> -每个 PR 都会自动分配 reviewer，任何贡献者都可以在评论中回复 `/assign [@_github_handle]` - 来请求某个 reviewer 来检视。 -如果 reviewer 觉得没有问题且不需要进一步更改时，reviewer 会在评论中回复 `/lgtm` 。 - -<!-- -If the assigned reviewer has not yet reviewed the content, another reviewer can -step in. In addition, you can assign technical reviewers and wait for them to -provide `/lgtm`. ---> -如果自动分配的 reviewer 未能及时检视，其他的 reviewer 也会参与。 -此外，你可以指定某个 reviewer 或者等他们回复 `/lgtm`。 - -<!-- -For a trivial change or one that needs no technical review, the SIG Docs -[approver](#approvers) can provide the `/lgtm` as well. ---> -对于不重要的更改或者非技术性的检视，SIG Docs 的 [approver](#approvers) 也可以提供 `/lgtm` 标签。 - -<!-- -A `/approve` comment from a reviewer is ignored by automation. ---> -如果一个 reviewer 在评论中回复 `/approve` 会被自动忽略。 - -<!-- -For more about how to become a SIG Docs reviewer and the responsibilities and -time commitment involved, see -[Becoming a reviewer or approver](#becoming-an-approver-or-reviewer). ---> -关于如何成为 SIG Docs reviewer 以及其责任、时间承诺等更多内容，请参照 -[Becoming a reviewer or approver](#becoming-an-approver-or-reviewer)。 - -<!-- -#### Becoming a reviewer ---> -#### 成为 reviewer - -<!-- -When you meet the -[requirements](https://github.com/kubernetes/community/blob/master/community-membership.md#reviewer), -you can become a SIG Docs reviewer. Reviewers in other SIGs must apply -separately for reviewer status in SIG Docs. ---> -当你满足[需求](https://github.com/kubernetes/community/blob/master/community-membership.md#reviewer)时， -你就可以成为 SIG Docs 的 reviewer。 -其他 SIG 的 reviewer 也需要单独向 SIG Docs 申请。 - -<!-- -To apply, open a pull request to add yourself to the `reviewers` section of the -[top-level OWNERS file](https://github.com/kubernetes/website/blob/master/OWNERS) -in the `kubernetes/website` repository. Assign the PR to one or more current SIG -Docs approvers. ---> -通过提交一个 PR 并把自己加到位于 `kubernetes/website` 仓库顶层的 [top-level OWNERS file](https://github.com/kubernetes/website/blob/master/OWNERS) 文件中的 `reviewers` 部分，指定一个或多个当前 SIG Docs 的 approver。 - -<!-- -If your pull request is approved, you are now a SIG Docs reviewer. -[K8s-ci-robot](https://github.com/kubernetes/test-infra/tree/master/prow#bots-home) -will assign and suggest you as a reviewer on new pull requests. ---> -如果你的 PR 被批准，你就成为了 SIG Docs reviewer 了。 -[K8s-ci-robot](https://github.com/kubernetes/test-infra/tree/master/prow#bots-home) 会在接下来的 PR 中请求你检视。 - -<!-- -If you are approved, request that a current SIG Docs approver add you to the -[@kubernetes/sig-docs-pr-reviews](https://github.com/orgs/kubernetes/teams/sig-docs-pr-reviews) -GitHub group. Only members of the `kubernetes-website-admins` GitHub group can -add new members to a GitHub group. ---> -如果您的 PR 被批准，你就会加入 [@kubernetes/sig-docs-pr-reviews](https://github.com/orgs/kubernetes/teams/sig-docs-pr-reviews) 组。只有 `kubernetes-website-admins` 组的成员才可以加入新成员。 - -### Approvers - -<!-- -Approvers are members of the -[@kubernetes/sig-docs-maintainers](https://github.com/orgs/kubernetes/teams/sig-docs-maintainers) -GitHub group. See [Teams and groups within SIG Docs](#teams-and-groups-within-sig-docs). ---> -approver 是 GitHub [@kubernetes/sig-docs-maintainers](https://github.com/orgs/kubernetes/teams/sig-docs-maintainers) 组织成员。 -参考 [Teams and groups within SIG Docs](#teams-and-groups-within-sig-docs)。 - -<!-- -Approvers have the ability to merge a PR, and thus, to publish content on the -Kubernetes website. To approve a PR, an approver leaves an `/approve` comment on -the PR. If someone who is not an approver leaves the approval comment, -automation ignores it. ---> -approver 有权限合入 PR，这意味着他们可以发布内容到 Kubernetes 网站。 -如果一个 approver 留下 `/approve` 评论，则代表他批准了 PR。 -如果非 approver 成员尝试批准，则会被自动忽略。 - -<!-- -If the PR already has a `/lgtm`, or if the approver also comments with `/lgtm`, -the PR merges automatically. A SIG Docs approver should only leave a `/lgtm` on -a change that doesn't need additional technical review. ---> -如果某个 PR 已有 `/lgtm` 标签，approver 再回复一个 `/lgtm` ，则这个 PR 会自动合入。 -SIG Docs approver 应该只在不需要额外的技术检视的情况下才可以标记 `/lgtm`。 - -<!-- -For more about how to become a SIG Docs approver and the responsibilities and -time commitment involved, see -[Becoming a reviewer or approver](#becoming-an-approver-or-reviewer). ---> -关于如何成为 SIG Docs 的 approver 及其责任和时间承诺等信息，请参考 [Becoming a reviewer or approver](#becoming-an-approver-or-reviewer)。 - -<!-- -#### Becoming an approver ---> -#### 成为 approver - -<!-- -When you meet the -[requirements](https://github.com/kubernetes/community/blob/master/community-membership.md#approver), -you can become a SIG Docs approver. Approvers in other SIGs must apply -separately for approver status in SIG Docs. ---> -当满足[要求](https://github.com/kubernetes/community/blob/master/community-membership.md#approver) 时，你可以成为 SIG Docs 的 approver。其他的 SIG 的 approver 要想成为 SIG Docs 的 approver 需要单独申请。 - -<!-- -To apply, open a pull request to add yourself to the `approvers` section of the -[top-level OWNERS file](https://github.com/kubernetes/website/blob/master/OWNERS) -in the `kubernetes/website` repository. Assign the PR to one or more current SIG -Docs approvers. ---> -通过提交一个 PR 并把自己加到位于 `kubernetes/website` 仓库顶层的 [top-level OWNERS file](https://github.com/kubernetes/website/blob/master/OWNERS) 文件中的 `approvers` 部分，指定一个或多个当前 SIG Docs 的 approver。 - -<!-- -If your pull request is approved, you are now a SIG Docs approver. -[K8s-ci-robot](https://github.com/kubernetes/test-infra/tree/master/prow#bots-home) -will assign and suggest you as a reviewer on new pull requests. ---> -一旦你的 PR 被批准，你就是一个 SIG Docs 的 approver 了。 - -<!-- -If you are approved, request that a current SIG Docs approver add you to the -[@kubernetes/sig-docs-maintainers](https://github.com/orgs/kubernetes/teams/sig-docs-maintainers) -GitHub group. Only members of the `kubernetes-website-admins` GitHub group can -add new members to a GitHub group. ---> -如果您的 PR 被批准，你就会加入[@kubernetes/sig-docs-maintainers](https://github.com/orgs/kubernetes/teams/sig-docs-maintainers) 组。只有 `kubernetes-website-admins` 组的成员才可以加入新成员。 - -<!-- -#### Approver responsibilities ---> -#### Approver 职责 - -<!-- -Approvers improve the documentation by reviewing and merging pull requests into the website repository. Because this role carries additional privileges, approvers have additional responsibilities: ---> -Approvers 通过查看拉取请求（pr）并将其合并到网站仓库中来完善文档。因为此角色具有其他特权，所以 approvers 还具有其他职责： - -<!-- -- Approvers can use the `/approve` command, which merges PRs into the repo. - - A careless merge can break the site, so be sure that when you merge something, you mean it. - -- Make sure that proposed changes meet the contribution guidelines. - - If you ever have a question, or you're not sure about something, feel free to call for additional review. - -- Verify that netlify tests pass before you `/approve` a PR. - - <img src="/images/docs/contribute/netlify-pass.png" width="75%" alt="Netlify tests must pass before approving" /> - -- Visit the netlify page preview for a PR to make sure things look good before approving. ---> -- Approvers 可以使用 `/approve` 命令将 PR 合并到仓库中。 - - 粗心的合并会破坏站点，因此请确保在合并某些内容时，您是清楚的。 - -- 确保建议的更改符合贡献准则。 - - 如果您有任何疑问，或者不确定某个问题，请随时联系他人进行审核。 - -- 在 `/approve` PR 之前，请验证 netlify 测试是否通过。 - - <img src="/images/docs/contribute/netlify-pass.png" width="75%" alt="批准之前必须确保 Netlify 测试通过" /> - -- 请访问 netlify 页面预览 PR，确保批准前一切正常。 - -<!-- -#### PR Wrangler ---> -#### PR 协调者 - -<!-- -SIG Docs approvers participate in the -[PR Wrangler rotation scheduler](https://github.com/kubernetes/website/wiki/PR-Wranglers) -for weekly rotations. SIG Docs expects all approvers to participate in this -rotation. See -[Be the PR Wrangler for a week](/docs/contribute/advanced#be-the-pr-wrangler-for-a-week) -for more details. ---> -每个 SIG Docs approver 都会参与 [PR Wrangler rotation scheduler](https://github.com/kubernetes/website/wiki/PR-Wranglers)。 -所有 SIG Docs approver 都会参与轮值。 -更多信息，请参考[做一周的PR协调者](/docs/contribute/advanced#be-the-pr-wrangler-for-a-week)。 - -<!-- -#### SIG Docs chairperson ---> -#### SIG Docs 主席 - -<!-- -Each SIG, including SIG Docs, selects one or more SIG members to act as -chairpersons. These are points of contact between SIG Docs and other parts of -the Kubernetes organization. They require extensive knowledge of the structure -of the Kubernetes project as a whole and how SIG Docs works within it. See -[Leadership](https://github.com/kubernetes/community/tree/master/sig-docs#leadership) -for the current list of chairpersons. ---> -每个 SIG，包括 SIG Docs，都会选出 1 位或多位成员作为主席。 -主席会成为 SIG Docs 和其他 Kubernetes 组织的联络接口人。 -他们需要了解整个 Kubernetes 项目，并明白 SIG Docs 如何运作。 -如需查询当前的主席，请查阅 [Leadership](https://github.com/kubernetes/community/tree/master/sig-docs#leadership)。 - -<!-- -## SIG Docs teams and automation ---> -## SIG Docs 团队和自动化 - -<!-- -Automation in SIG Docs relies on two different mechanisms for automation: -GitHub groups and OWNERS files. ---> -SIG 文档中的自动化依赖于两种不同的自动化机制: -GitHub 组和 OWNERS 文件。 - -### GitHub groups - -<!-- -The SIG Docs group defines two teams on GitHub: ---> -SIG Docs 组定义了两个 GitHub 组： - - - [@kubernetes/sig-docs-maintainers](https://github.com/orgs/kubernetes/teams/sig-docs-maintainers) - - [@kubernetes/sig-docs-pr-reviews](https://github.com/orgs/kubernetes/teams/sig-docs-pr-reviews) - -<!-- -Each can be referenced with their `@name` in GitHub comments to communicate with -everyone in that group. ---> -可以在 GitHub 的评论中 `@name` 他们来与他们沟通。 - -<!-- -These teams overlap, but do not exactly match, the groups used by the automation -tooling. For assignment of issues, pull requests, and to support PR approvals, -the automation uses information from OWNERS files. ---> -这些团队与自动化工具使用的组有所重叠，但并不完全匹配。 -对于分配 issue、拉请求和批准 PR，自动化使用来自 OWNERS 文件的信息。 - -<!-- -### OWNERS files and front-matter ---> -### OWNERS 文件和扉页 - -<!-- -The Kubernetes project uses an automation tool called prow for automation -related to GitHub issues and pull requests. The -[Kubernetes website repository](https://github.com/kubernetes/website) uses -two [prow plugins](https://github.com/kubernetes/test-infra/blob/master/prow/plugins.yaml#L210): ---> -Kubernetes 项目使用名为 prow 的自动化工具来处理 GitHub issue 和 PR。 -[Kubernetes website repository](https://github.com/kubernetes/website) 使用了两个 -[prow 插件](https://github.com/kubernetes/test-infra/blob/master/prow/plugins.yaml#L210)： - -- blunderbuss -- approve - -<!-- -These two plugins use the -[OWNERS](https://github.com/kubernetes/website/blob/master/OWNERS) and -[OWNERS_ALIASES](https://github.com/kubernetes/website/blob/master/OWNERS_ALIASES) -files in the top level of the `kubernetes/website` GitHub repository to control -how prow works within the repository. ---> -这两个插件使用位于 `kubernetes/website` 仓库顶层的 -[OWNERS](https://github.com/kubernetes/website/blob/master/OWNERS) 和 -[OWNERS_ALIASES](https://github.com/kubernetes/website/blob/master/OWNERS_ALIASES) 来控制工作流程。 - -<!-- -An OWNERS file contains a list of people who are SIG Docs reviewers and -approvers. OWNERS files can also exist in subdirectories, and can override who -can act as a reviewer or approver of files in that subdirectory and its -descendents. For more information about OWNERS files in general, see -[OWNERS](https://github.com/kubernetes/community/blob/master/contributors/guide/owners.md). ---> -OWNERS 文件包含 SIG Docs reviewer 和 approver 的列表。 -OWNERS 文件也可以存在于子目录中中，可以重写 reviewer 和 approver，并且它自动继承上级。 -关于 OWNERS 的更多信息，请参考 [OWNERS](https://github.com/kubernetes/community/blob/master/contributors/guide/owners.md)。 - -<!-- -In addition, an individual Markdown file can list reviewers and approvers in its -front-matter, either by listing individual GitHub usernames or GitHub groups. ---> -此外，一个单独的 Markdown 格式的文件将会列出 reviewer 和 approver（扉页），或者列出 -其 GitHub 用户名 或者列出其组名。 - -<!-- -The combination of OWNERS files and front-matter in Markdown files determines -the advice PR owners get from automated systems about who to ask for technical -and editorial review of their PR. ---> -结合 OWNERS 文件及扉页可以给 PR 作者提供向谁请求检视的建议。 - - - -## {{% heading "whatsnext" %}} - - -<!-- -For more information about contributing to the Kubernetes documentation, see: ---> -关于贡献 Kubernetes 的更多文档，请参考： - -- [Start contributing](/docs/contribute/start/) -- [Documentation style](/docs/contribute/style/) - - - - diff --git a/content/zh/docs/contribute/review/_index.md b/content/zh/docs/contribute/review/_index.md new file mode 100644 index 0000000000..b3401268bb --- /dev/null +++ b/content/zh/docs/contribute/review/_index.md @@ -0,0 +1,17 @@ +--- +title: 评阅变更 +weight: 30 +--- +<!-- +title: Reviewing changes +weight: 30 +--> + +<!-- overview --> +<!-- +This section describes how to review content. +--> +本节描述如何对内容进行评阅。 + +<!-- body --> + diff --git a/content/zh/docs/contribute/review/for-approvers.md b/content/zh/docs/contribute/review/for-approvers.md new file mode 100644 index 0000000000..b801e7efcf --- /dev/null +++ b/content/zh/docs/contribute/review/for-approvers.md @@ -0,0 +1,433 @@ +--- +title: 评阅人和批准人文档 +linktitle: 评阅人和批准人 +slug: for-approvers +content_type: concept +weight: 20 +--- +<!-- +title: Reviewing for approvers and reviewers +linktitle: For approvers and reviewers +slug: for-approvers +content_type: concept +weight: 20 +--> + +<!-- overview --> +<!-- +SIG Docs [Reviewers](/docs/contribute/participate/roles-and-responsibilities/#reviewers) and [Approvers](/docs/contribute/participate/roles-and-responsibilities/#approvers) do a few extra things when reviewing a change. + +Every week a specific docs approver volunteers to triage +and review pull requests. This +person is the "PR Wrangler" for the week. See the +[PR Wrangler scheduler](https://github.com/kubernetes/website/wiki/PR-Wranglers) for more information. To become a PR Wrangler, attend the weekly SIG Docs meeting and volunteer. Even if you are not on the schedule for the current week, you can still review pull +requests (PRs) that are not already under active review. + +In addition to the rotation, a bot assigns reviewers and approvers +for the PR based on the owners for the affected files. +--> +SIG Docs +[评阅人（Reviewers）](/zh/docs/contribute/participate/roles-and-responsibilities/#reviewers) +和[批准人（Approvers）](/zh/docs/contribute/participate/roles-and-responsibilities/#approvers) +在对变更进行评审时需要做一些额外的事情。 + +每周都有一个特定的文档批准人自愿负责对 PR 进行分类和评阅。 +此角色称作该周的“PR 管理者（PR Wrangler）”。 +相关信息可参考 [PR Wrangler 排班表](https://github.com/kubernetes/website/wiki/PR-Wranglers)。 +要成为 PR Wangler，需要参加每周的 SIG Docs 例会，并自愿报名。 +即使当前这周排班没有轮到你，你仍可以评阅那些尚未被积极评阅的 PRs。 + +除了上述的轮值安排，后台机器人也会为基于所影响的文件来为 PR +指派评阅人和批准人。 + +<!-- body --> +<!-- +## Reviewing a PR +Kubernetes documentation follows the [Kubernetes code review process](https://github.com/kubernetes/community/blob/master/contributors/guide/owners.md#the-code-review-process). + +Everything described in [Reviewing a pull request](/docs/contribute/review/reviewing-prs) applies, but Reviewers and Approvers should also do the following: +--> +## 评阅 PR + +Kubernetes 文档遵循 [Kubernetes 代码评阅流程](https://github.com/kubernetes/community/blob/master/contributors/guide/owners.md#the-code-review-process)。 + +[评阅 PR](/zh/docs/contribute/review/reviewing-prs/) 文档中所描述的所有规程都适用， +不过评阅人和批准人还要做以下工作： + +<!-- +- Using the `/assign` Prow command to assign a specific reviewer to a PR as needed. This is extra important +when it comes to requesting technical review from code contributors. + + {{< note >}} + Look at the `reviewers` field in the front-matter at the top of a Markdown file to see who can + provide technical review. + {{< /note >}} + +- Making sure the PR follows the [Content](/docs/contribute/style/content-guide/) and [Style](/docs/contribute/style/style-guide/) guides; link the author to the relevant part of the guide(s) if it doesn't. +- Using the GitHub **Request Changes** option when applicable to suggest changes to the PR author. +- Changing your review status in GitHub using the `/approve` or `/lgtm` Prow commands, if your suggestions are implemented. +--> +- 根据需要使用 Prow 命令 `/assign` 指派特定的评阅人。如果某个 PR + 需要来自代码贡献者的技术审核时，这一点非常重要。 + + {{< note >}} + 你可以查看 Markdown 文件的文件头，其中的 `reviewers` 字段给出了哪些人可以为文档提供技术审核。 + {{< /note >}} + +- 确保 PR 遵从[内容指南](/zh/docs/contribute/style/content-guide/)和[样式指南](/zh/docs/contribute/style/style-guide/)； + 如果 PR 没有达到要求，指引作者阅读指南中的相关部分。 +- 适当的时候使用 GitHub **Request Changes** 选项，建议 PR 作者实施所建议的修改。 +- 当你所提供的建议被采纳后，在 GitHub 中使用 `/approve` 或 `/lgtm` Prow 命令，改变评审状态。 + +<!-- +## Commit into another person's PR + +Leaving PR comments is helpful, but there might be times when you need to commit +into another person's PR instead. + +Do not "take over" for another person unless they explicitly ask +you to, or you want to resurrect a long-abandoned PR. While it may be faster +in the short term, it deprives the person of the chance to contribute. + +The process you use depends on whether you need to edit a file that is already +in the scope of the PR, or a file that the PR has not yet touched. +--> +## 提交到他人的 PR + +为 PR 留下评语是很有用的，不过有时候你需要向他人的 PR 提交内容。 + +除非他人明确请求你的帮助或者你希望重启一个被放弃很久的 PR，不要“接手”他人的工作。 +尽管短期看来这样做可以提高效率，但是也剥夺了他人提交贡献的机会。 + +你所要遵循的流程取决于你需要编辑已经在 PR 范畴的文件，还是 PR 尚未触碰的文件。 + +<!-- +You can't commit into someone else's PR if either of the following things is +true: + +- If the PR author pushed their branch directly to the + [https://github.com/kubernetes/website/](https://github.com/kubernetes/website/) + repository. Only a reviewer with push access can commit to another user's PR. + + {{< note >}} + Encourage the author to push their branch to their fork before + opening the PR next time. + {{< /note >}} + +- The PR author explicitly disallows edits from approvers. +--> +如果处于下列情况之一，你不可以向别人的 PR 提交内容： + +- 如果 PR 作者是直接将自己的分支提交到 + [https://github.com/kubernetes/website/](https://github.com/kubernetes/website/) + 仓库。只有具有推送权限的评阅人才可以向他人的 PR 提交内容。 + + {{< note >}} + 我们应鼓励作者下次将分支推送到自己的克隆副本之后再发起 PR。 + {{< /note >}} + +- PR 作者明确地禁止批准人编辑他/她的 PR。 + +<!-- +## Prow commands for reviewing + +[Prow](https://github.com/kubernetes/test-infra/blob/master/prow/README.md) is +the Kubernetes-based CI/CD system that runs jobs against pull requests (PRs). Prow +enables chatbot-style commands to handle GitHub actions across the Kubernetes +organization, like [adding and removing labels](#adding-and-removing-issue-labels), closing issues, and assigning an approver. Enter Prow commands as GitHub comments using the `/<command-name>` format. + +The most common prow commands reviewers and approvers use are: +--> +## 评阅用的 Prow 命令 + +[Prow](https://github.com/kubernetes/test-infra/blob/master/prow/README.md) +是基于 Kubernetes 的 CI/CD 系统，基于拉取请求（PR）的触发运行不同任务。 +Prow 使得我们可以使用会话机器人一样的命令跨整个 Kubernetes 组织处理 GitHub +动作，例如[添加和删除标签](#adding-and-removing-issue-labels)、关闭 Issues +以及指派批准人等等。你可以使用 `/<命令名称>` 的形式以 GitHub 评论的方式输入 +Prow 命令。 + +评阅人和批准人最常用的 Prow 命令有： + +<!-- +{{< table caption="Prow commands for reviewing" >}} +Prow Command | Role Restrictions | Description +:------------|:------------------|:----------- +`/lgtm` | Anyone, but triggers automation if a Reviewer or Approver uses it | Signals that you've finished reviewing a PR and are satisfied with the changes. +`/approve` | Approvers | Approves a PR for merging. +`/assign` | Reviewers or Approvers | Assigns a person to review or approve a PR +`/close` | Reviewers or Approvers | Closes an issue or PR. +`/hold` | Anyone | Adds the `do-not-merge/hold` label, indicating the PR cannot be automatically merged. +`/hold cancel` | Anyone | Removes the `do-not-merge/hold` label. +{{< /table >}} + +See [the Prow command reference](https://prow.k8s.io/command-help) to see the full list +of commands you can use in a PR. +--> +{{< table caption="评阅用 Prow 命令" >}} +Prow 命令 | 角色限制 | 描述 +:------------|:------------------|:----------- +`/lgtm` | 任何人均可使用，但只有评阅人和批准人使用此命令的时候才会触发自动化操作 | 用来表明你已经完成 PR 的评阅并对其所作变更表示满意 +`/approve` | 批准人 | 批准某 PR 可以合并 +`/assign` |评阅人或批准人 | 指派某人来评阅或批准某 PR +`/close` | 评阅人或批准人 | 关闭 Issue 或 PR +`/hold` | 任何人 | 添加 `do-not-merge/hold` 标签，用来表明 PR 不应被自动合并 +`/hold cancel` | 任何人 | 去掉 `do-not-merge/hold` 标签 +{{< /table >}} + +请参考 [Prow 命令指南](https://prow.k8s.io/command-help)，了解你可以在 PR +中使用的命令的完整列表。 + +<!-- +## Triage and categorize issues + +In general, SIG Docs follows the [Kubernetes issue triage](https://github.com/kubernetes/community/blob/master/contributors/guide/issue-triage.md) process and uses the same labels. + +This GitHub Issue [filter](https://github.com/kubernetes/website/issues?q=is%3Aissue+is%3Aopen+-label%3Apriority%2Fbacklog+-label%3Apriority%2Fimportant-longterm+-label%3Apriority%2Fimportant-soon+-label%3Atriage%2Fneeds-information+-label%3Atriage%2Fsupport+sort%3Acreated-asc) +finds issues that might need triage. +--> +## 对 Issue 进行诊断和分类 + +一般而言，SIG Docs 遵从 [Kubernetes issue 判定](https://github.com/kubernetes/community/blob/master/contributors/guide/issue-triage.md) 流程并使用相同的标签。 + +此 GitHub Issue +[过滤器](https://github.com/kubernetes/website/issues?q=is%3Aissue+is%3Aopen+-label%3Apriority%2Fbacklog+-label%3Apriority%2Fimportant-longterm+-label%3Apriority%2Fimportant-soon+-label%3Atriage%2Fneeds-information+-label%3Atriage%2Fsupport+sort%3Acreated-asc) +可以用来查找需要评判的 Issues。 + +<!-- +### Triaging an issue + +1. Validate the issue + - Make sure the issue is about website documentation. Some issues can be closed quickly by + answering a question or pointing the reporter to a resource. See the + [Support requests or code bug reports](#support-requests-or-code-bug-reports) section for details. + - Assess whether the issue has merit. + - Add the `triage/needs-information` label if the issue doesn't have enough + detail to be actionable or the template is not filled out adequately. + - Close the issue if it has both the `lifecycle/stale` and `triage/needs-information` labels. +--> + +### 评判 Issue {#triaging-an-issue} + +1. 验证 Issue 的合法性 + + - 确保 Issue 是关于网站文档的。某些 Issue 可以通过回答问题或者为报告者提供 + 资源链接来快速关闭。 + 参考[请求支持或代码缺陷报告](#support-requests-or-code-bug-reports) + 节以了解详细信息。 + - 评估该 Issue 是否有价值。 + - 如果 Issue 缺少足够的细节以至于无法采取行动，或者报告者没有通过模版提供 + 足够信息，可以添加 `triage/needs-information` 标签。 + - 如果 Issue 同时标注了 `lifecycle/stale` 和 `triage/needs-information` + 标签，可以直接关闭。 + +<!-- +2. Add a priority label (the + [Issue Triage Guidelines](https://github.com/kubernetes/community/blob/master/contributors/guide/issue-triage.md#define-priority) define priority labels in detail) + + < table caption="Issue labels" > + Label | Description + :------------|:------------------ + `priority/critical-urgent` | Do this right now. + `priority/important-soon` | Do this within 3 months. + `priority/important-longterm` | Do this within 6 months. + `priority/backlog` | Deferrable indefinitely. Do when resources are available. + `priority/awaiting-more-evidence` | Placeholder for a potentially good issue so it doesn't get lost. + `help` or `good first issue` | Suitable for someone with very little Kubernetes or SIG Docs experience. See [Help Wanted and Good First Issue Labels](https://github.com/kubernetes/community/blob/master/contributors/guide/help-wanted.md) for more information. + + At your discretion, take ownership of an issue and submit a PR for it + (especially if it's quick or relates to work you're already doing). + +If you have questions about triaging an issue, ask in `#sig-docs` on Slack or +the [kubernetes-sig-docs mailing list](https://groups.google.com/forum/#!forum/kubernetes-sig-docs). +--> +2. 添加优先级标签（ + [Issue 判定指南](https://github.com/kubernetes/community/blob/master/contributors/guide/issue-triage.md#define-priority)中有优先级标签的详细定义) + + {{< table caption="Issue 标签" >}} + 标签 | 描述 + :------------|:------------------ + `priority/critical-urgent` | 应马上处理 + `priority/important-soon` | 应在 3 个月内处理 + `priority/important-longterm` | 应在 6 个月内处理 + `priority/backlog` | 可无限期地推迟，可在人手充足时处理 + `priority/awaiting-more-evidence` | 占位符，标示 Issue 可能是一个不错的 Issue，避免该 Issue 被忽略或遗忘 + `help` or `good first issue` | 适合对 Kubernetes 或 SIG Docs 经验较少的贡献者来处理。更多信息可参考[需要帮助和入门候选 Issue 标签](https://github.com/kubernetes/community/blob/master/contributors/guide/help-wanted.md)。 + {{< /table >}} + + 基于你自己的判断，你可以选择某 Issue 来处理，为之发起 PR + （尤其是那些可以很快处理或与你已经在做的工作相关的 Issue）。 + +如果你对 Issue 评判有任何问题，可以在 `#sig-docs` Slack 频道或者 +[kubernetes-sig-docs 邮件列表](https://groups.google.com/forum/#!forum/kubernetes-sig-docs) +中提问。 + +<!-- +## Adding and removing issue labels + +To add a label, leave a comment in one of the following formats: + +- `/<label-to-add>` (for example, `/good-first-issue`) +- `/<label-category> <label-to-add>` (for example, `/triage needs-information` or `/language ja`) + +To remove a label, leave a comment in one of the following formats: + +- `/remove-<label-to-remove>` (for example, `/remove-help`) +- `/remove-<label-category> <label-to-remove>` (for example, `/remove-triage needs-information`)` +--> +## 添加和删除 Issue 标签 {#adding-and-removing-issue-labels} + +要添加标签，可以用以下形式对 PR 进行评论： + +- `/<要添加的标签>` （例如, `/good-first-issue`） +- `/<标签类别> <要添加的标签>` （例如，`/triage needs-information` 或 `/language ja`） + +要移除某个标签，可以用以下形式对 PR 进行评论： + +- `/remove-<要移除的标签>` （例如，`/remove-help`） +- `/remove-<标签类别> <要移除的标签>` （例如，`/remove-triage needs-information`） + +<!-- +In both cases, the label must already exist. If you try to add a label that does not exist, the command is +silently ignored. + +For a list of all labels, see the [website repository's Labels section](https://github.com/kubernetes/website/labels). Not all labels are used by SIG Docs. +--> +在以上两种情况下，标签都必须合法存在。如果你尝试添加一个尚不存在的标签， +对应的命令会被悄悄忽略。 + +关于所有标签的完整列表，可以参考 +[Website 仓库的标签节](https://github.com/kubernetes/website/labels)。 +实际上，SIG Docs 并没有使用全部标签。 + +<!-- +### Issue lifecycle labels + +Issues are generally opened and closed quickly. +However, sometimes an issue is inactive after its opened. +Other times, an issue may need to remain open for longer than 90 days. + +{{< table caption="Issue lifecycle labels" >}} +Label | Description +:------------|:------------------ +`lifecycle/stale` | After 90 days with no activity, an issue is automatically labeled as stale. The issue will be automatically closed if the lifecycle is not manually reverted using the `/remove-lifecycle stale` command. +`lifecycle/frozen` | An issue with this label will not become stale after 90 days of inactivity. A user manually adds this label to issues that need to remain open for much longer than 90 days, such as those with a `priority/important-longterm` label. +{{< /table >}} +--> +### Issue 生命周期标签 + +Issues 通常都可以快速创建并关闭。 +不过也有些时候，某个 Issue 被创建之后会长期处于非活跃状态。 +也有一些时候，即使超过 90 天，某个 Issue 仍应保持打开状态。 + +{{< table caption="Issue 生命周期标签" >}} +标签 | 描述 +:------------|:------------------ +`lifecycle/stale` | 过去 90 天内某 Issue 无人问津，会被自动标记为停滞状态。如果 Issue 没有被 `/remove-lifecycle stale` 命令重置生命期，就会被自动关闭。 +`lifecycle/frozen` | 对应的 Issue 即使超过 90 天仍无人处理也不会进入停滞状态。用户手动添加此标签给一些需要保持打开状态超过 90 天的 Issue，例如那些带有 `priority/important-longterm` 标签的 Issue。 +{{< /table >}} + +<!-- +## Handling special issue types + +SIG Docs encounters the following types of issues often enough to document how +to handle them. + +### Duplicate issues + +If a single problem has one or more issues open for it, combine them into a single issue. +You should decide which issue to keep open (or +open a new issue), then move over all relevant information and link related issues. +Finally, label all other issues that describe the same problem with +`triage/duplicate` and close them. Only having a single issue to work on reduces confusion +and avoids duplicate work on the same problem. +--> +## 处理特殊的 Issue 类型 {#handling-special-issue-types} + +SIG Docs 常常会遇到以下类型的 Issue，因此对其处理方式描述如下。 + +### 重复的 Issue {#duplicate-issues} + +如果针对同一个问题有不止一个打开的 Issue，可以将其合并为一个 Issue。 +你需要决定保留哪个 Issue 为打开状态（或者重新登记一个新的 Issue）， +然后将所有相关的信息复制过去并提供对关联 Issues 的链接。 +最后，将所有其他描述同一问题的 Issue 标记为 `triage/duplicate` 并关闭之。 +保持只有一个 Issue 待处理有助于减少困惑，避免在同一问题上发生重复劳动。 + +<!-- +### Dead link issues + +If the dead link issue is in the API or `kubectl` documentation, assign them `/priority critical-urgent` until the problem is fully understood. Assign all other dead link issues `/priority important-longterm`, as they must be manually fixed. + +### Blog issues + +We expect [Kubernetes Blog](https://kubernetes.io/blog/) entries to become +outdated over time. Therefore, we only maintain blog entries less than a year old. +If an issue is related to a blog entry that is more than one year old, +close the issue without fixing. +--> +### 失效链接 Issues {#dead-link-issues} + +如果失效链接是关于 API 或者 `kubectl` 文档的，可以将其标记为 +`/priority critical-urgent`，直到问题原因被弄清楚为止。 +对于其他的链接失效问题，可以标记 `/priority important-longterm`， +因为这些问题都需要手动处理。 + +### 博客问题 {#blog-issues} + +我们预期 [Kubernetes 博客](https://kubernetes.io/blog/)条目随着时间推移都会过期。 +因此，我们只维护一年内的博客条目。 +如果某个 Issue 是与某个超过一年的博客条目有关的，可以直接关闭 +Issue，不必修复。 + +<!-- +### Support requests or code bug reports + +Some docs issues are actually issues with the underlying code, or requests for +assistance when something, for example a tutorial, doesn't work. +For issues unrelated to docs, close the issue with the `triage/support` label and a comment +directing the requester to support venues (Slack, Stack Overflow) and, if +relevant, the repository to file an issue for bugs with features (`kubernetes/kubernetes` +is a great place to start). + +Sample response to a request for support: +--> +### 请求支持或代码缺陷报告 {#support-requests-or-code-bug-reports} + +某些文档 Issues 实际上是关于底层代码的 Issue 或者在某方面请求协助的问题， +例如某个教程无法正常工作。 +对于与文档无关的 Issues，关闭它并打上标签 `triage/support`，可以通过评论 +告知请求者其他支持渠道（Slack、Stack Overflow）。 +如果有相关的其他仓库，可以告诉请求者应该在哪个仓库登记与功能特性相关的 Issues +（通常会是 `kubernetes/kubernetes`）。 + +下面是对支持请求的回复示例： + +```none +This issue sounds more like a request for support and less +like an issue specifically for docs. I encourage you to bring +your question to the `#kubernetes-users` channel in +[Kubernetes slack](https://slack.k8s.io/). You can also search +resources like +[Stack Overflow](https://stackoverflow.com/questions/tagged/kubernetes) +for answers to similar questions. + +You can also open issues for Kubernetes functionality in +https://github.com/kubernetes/kubernetes. + +If this is a documentation issue, please re-open this issue. +``` + +<!-- +Sample code bug report response: +--> +对代码缺陷 Issue 的回复示例： + +```none +This sounds more like an issue with the code than an issue with +the documentation. Please open an issue at +https://github.com/kubernetes/kubernetes/issues. + +If this is a documentation issue, please re-open this issue. +``` + diff --git a/content/zh/docs/contribute/review/reviewing-prs.md b/content/zh/docs/contribute/review/reviewing-prs.md new file mode 100644 index 0000000000..e420fb919a --- /dev/null +++ b/content/zh/docs/contribute/review/reviewing-prs.md @@ -0,0 +1,202 @@ +--- +title: 评阅 PRs +content_type: concept +main_menu: true +weight: 10 +--- +<!-- +title: Reviewing pull requests +content_type: concept +main_menu: true +weight: 10 +--> + +<!-- overview --> +<!-- +Anyone can review a documentation pull request. Visit the [pull requests](https://github.com/kubernetes/website/pulls) section in the Kubernetes website repository to see open pull requests. + +Reviewing documentation pull requests is a +great way to introduce yourself to the Kubernetes community. +It helps you learn the code base and build trust with other contributors. + +Before reviewing, it's a good idea to: + +- Read the [content guide](/docs/contribute/style/content-guide/) and +[style guide](/docs/contribute/style/style-guide/) so you can leave informed comments. +- Understand the different [roles and responsibilities](/docs/contribute/participating/#roles-and-responsibilities) in the Kubernetes documentation community. +--> +任何人均可评阅文档的拉取请求。访问 Kubernetes 网站仓库的 +[pull requests](https://github.com/kubernetes/website/pulls) +部分可以查看所有待处理的拉取请求（PRs）。 + +评阅文档 PR 是将你自己介绍给 Kubernetes 社区的一种很好的方式。 +它将有助于你学习代码库并与其他贡献者之间建立相互信任关系。 + +在评阅之前，可以考虑： + +- 阅读[内容指南](/zh/docs/contribute/style/content-guide/)和 + [样式指南](/zh/docs/contribute/style/style-guide/)以便给出有价值的评论。 +- 了解 Kubernetes 文档社区中不同的[角色和职责](/zh/docs/contribute/participate/roles-and-responsibilities/)。 + +<!-- body --> +<!-- +## Before you begin + +Before you start a review: + +- Read the [CNCF Code of Conduct](https://github.com/cncf/foundation/blob/master/code-of-conduct.md) and ensure that you abide by it at all times. +- Be polite, considerate, and helpful. +- Comment on positive aspects of PRs as well as changes. +- Be empathetic and mindful of how your review may be received. +- Assume good intent and ask clarifying questions. +- Experienced contributors, consider pairing with new contributors whose work requires extensive changes. +--> +## 准备工作 {#before-you-begin} + +在你开始评阅之前： + +- 阅读 [CNCF 行为准则](https://github.com/cncf/foundation/blob/master/code-of-conduct.md) + 确保你会始终遵从其中约定； +- 保持有礼貌、体谅他人，怀助人为乐初心； +- 评论时若给出修改建议，也要兼顾 PR 的积极方面 +- 保持同理心，多考虑他人收到评阅意见时的可能反应 +- 假定大家都是好意的，通过问问题澄清意图 +- 如果你是有经验的贡献者，请考虑和新贡献者一起合作，提高其产出质量 + +<!-- +## Review process + +In general, review pull requests for content and style in English. + +1. Go to + [https://github.com/kubernetes/website/pulls](https://github.com/kubernetes/website/pulls). + You see a list of every open pull request against the Kubernetes website and + docs. + +2. Filter the open PRs using one or all of the following labels: + - `cncf-cla: yes` (Recommended): PRs submitted by contributors who have not signed the CLA cannot be merged. See [Sign the CLA](/docs/contribute/new-content/overview/#sign-the-cla) for more information. + - `language/en` (Recommended): Filters for english language PRs only. + - `size/<size>`: filters for PRs of a certain size. If you're new, start with smaller PRs. + + Additionally, ensure the PR isn't marked as a work in progress. PRs using the `work in progress` label are not ready for review yet. +--> +## 评阅过程 {#review-process} + +一般而言，应该使用英语来评阅 PR 的内容和样式。 + +1. 前往 [https://github.com/kubernetes/website/pulls](https://github.com/kubernetes/website/pulls)， + 你会看到所有针对 Kubernetes 网站和文档的待处理 PRs。 + +2. 使用以下标签（组合）对待处理 PRs 进行过滤： + + - `cncf-cla: yes` （建议）：由尚未签署 CLA 的贡献者所发起的 PRs 不可以合并。 + 参考[签署 CLA](/zh/docs/contribute/new-content/overview/#sign-the-cla) 以了解更多信息。 + - `language/en` （建议）：仅查看英语语言的 PRs。 + - `size/<尺寸>`：过滤特定尺寸（规模）的 PRs。如果你刚入门，可以从较小的 PR 开始。 + + 此外，确保 PR 没有标记为尚未完成（Work in Progress）。 + 包含 `work in progress` 的 PRs 通常还没准备好被评阅。 + +<!-- +3. Once you've selected a PR to review, understand the change by: + - Reading the PR description to understand the changes made, and read any linked issues + - Reading any comments by other reviewers + - Clicking the **Files changed** tab to see the files and lines changed + - Previewing the changes in the Netlify preview build by scrolling to the PR's build check section at the bottom of the **Conversation** tab and clicking the **deploy/netlify** line's **Details** link. + +4. Go to the **Files changed** tab to start your review. + 1. Click on the `+` symbol beside the line you want to comment on. + 2. Fill in any comments you have about the line and click either **Add single comment** (if you have only one comment to make) or **Start a review** (if you have multiple comments to make). + 3. When finished, click **Review changes** at the top of the page. Here, you can add + add a summary of your review (and leave some positive comments for the contributor!), + approve the PR, comment or request changes as needed. New contributors should always + choose **Comment**. +--> +3. 选定 PR 评阅之后，可以通过以下方式理解所作的变更： + + - 阅读 PR 描述以理解所作变更，并且阅读所有关联的 Issues + - 阅读其他评阅人给出的评论 + - 点击 **Files changed** Tab 页面，查看被改变的文件和代码行 + - 滚动到 **Conversation** Tab 页面下端的 PR 构建检查节区，点击 + **deploy/netlify** 行的 **Details** 链接，预览 Netlify + 预览构建所生成的结果 + +4. 前往 **Files changed** Tab 页面，开始你的评阅工作 + + 1. 点击你希望评论的行旁边的 `+` 号 + 2. 填写你对该行的评论，之后或者选择**Add single comment** （如果你只有一条评论） + 或者 **Start a review** （如果你还有其他评论要添加） + 3. 评论结束时，点击页面顶部的 **Review changes**。这里你可以添加你的评论结语 + （记得留下一些正能量的评论！）、根据需要批准 PR、请求作者进一步修改等等。 + 新手应该选择 **Comment**。 + +<!-- +## Reviewing checklist + +When reviewing, use the following as a starting point. + +### Language and grammar + +- Are there any obvious errors in language or grammar? Is there a better way to phrase something? +- Are there any complicated or archaic words which could be replaced with a simpler word? +- Are there any words, terms or phrases in use which could be replaced with a non-discriminatory alternative? +- Does the word choice and its capitalization follow the [style guide](/docs/contribute/style/style-guide/)? +- Are there long sentences which could be shorter or less complex? +- Are there any long paragraphs which might work better as a list or table? +--> +## 评阅清单 {#reviewing-checklist} + +评阅 PR 时可以从下面的条目入手。 + +### 语言和语法 {#language-and-grammar} + +- 是否存在明显的语言或语法错误？对某事的描述有更好的方式？ +- 是否存在一些过于复杂晦涩的用词，本可以用简单词汇来代替？ +- 是否有些用词、术语或短语可以用不带歧视性的表达方式代替？ +- 用词和大小写方面是否遵从了[样式指南](/zh/docs/contribute/style/style-guide/)？ +- 是否有些句子太长，可以改得更短、更简单？ +- 是否某些段落过长，可以考虑使用列表或者表格来表达？ + +<!-- +### Content + +- Does similar content exist elsewhere on the Kubernetes site? +- Does the content excessively link to off-site, individual vendor or non-open source documentation? +--> +### 内容 {#content} + +- Kubernetes 网站上是否别处已经存在类似的内容？ +- 内容本身是否过度依赖于网站范畴之外、独立供应商或者非开源的文档？ + +<!-- +### Website + +- Did this PR change or remove a page title, slug/alias or anchor link? If so, are there broken links as a result of this PR? Is there another option, like changing the page title without changing the slug? +- Does the PR introduce a new page? If so: + - Is the page using the right [page content type](/docs/contribute/style/page-content-types/) and associated Hugo shortcodes? + - Does the page appear correctly in the section's side navigation (or at all)? + - Should the page appear on the [Docs Home](/docs/home/) listing? +- Do the changes show up in the Netlify preview? Be particularly vigilant about lists, code blocks, tables, notes and images. + +### Other + +For small issues with a PR, like typos or whitespace, prefix your comments with `nit:`. This lets the author know the issue is non-critical. +--> +### 网站 {#Website} + +- PR 是否改变或者删除了某页面的标题、slug/别名或者链接锚点？ + 如果是这样，PR 是否会导致出现新的失效链接？ + 是否有其他的办法，比如改变页面标题但不改变其 slug？ +- PR 是否引入新的页面？如果是： + - 该页面是否使用了正确的[页面内容类型](/zh/docs/contribute/style/page-content-types/) + 及相关联的 Hugo 短代码（shortcodes）？ + - 该页面能否在对应章节的侧面导航中显示？显示得正确么？ + - 该页面是否应出现在[网站主页面](/zh/docs/home/)的列表中？ +- 变更是否正确出现在 Netlify 预览中了？ + 要对列表、代码段、表格、注释和图像等元素格外留心 + +### 其他 {#other} + +对于 PR 中的小问题，例如拼写错误或者空格问题，可以在你的评论前面加上 `nit:`。 +这样做可以让作者知道该问题不是一个不得了的大问题。 + diff --git a/content/zh/docs/contribute/start.md b/content/zh/docs/contribute/start.md deleted file mode 100644 index 40da4e7e4a..0000000000 --- a/content/zh/docs/contribute/start.md +++ /dev/null @@ -1,635 +0,0 @@ ---- -title: 开始贡献 -slug: start -content_type: concept -weight: 10 -card: - name: contribute - weight: 10 ---- -<!-- ---- -title: Start contributing -slug: start -content_type: concept -weight: 10 -card: - name: contribute - weight: 10 ---- ---> - -<!-- overview --> - -<!-- -If you want to get started contributing to the Kubernetes documentation, this -page and its linked topics can help you get started. You don't need to be a -developer or a technical writer to make a big impact on the Kubernetes -documentation and user experience! All you need for the topics on this page is -a [GitHub account](https://github.com/join) and a web browser. - -If you're looking for information on how to start contributing to Kubernetes -code repositories, refer to -[the Kubernetes community guidelines](https://github.com/kubernetes/community/blob/master/governance.md). ---> -如果您想要为 Kubernetes 文档做贡献，本页面的内容和链接的主题能够给您帮助。您不必是一位开发者或者技术作者，也同样可以为 Kubernetes 文档及其用户体验带来巨大的影响！您只需要有一个 [Github 账号](https://github.com/join) 和一个浏览器。 - -如果您在寻找有关如何开始向 Kubernetes 仓库贡献代码的信息，请参考 [Kubernetes 社区指南](https://github.com/kubernetes/community/blob/master/governance.md)。 - - - - -<!-- body --> - -<!-- -## The basics about our docs ---> -## 关于我们文档的基础知识 - -<!-- -The Kubernetes documentation is written in Markdown and processed and deployed using Hugo. The source is in GitHub at [https://github.com/kubernetes/website](https://github.com/kubernetes/website). Most of the documentation source is stored in `/content/en/docs/`. Some of the reference documentation is automatically generated from scripts in the `update-imported-docs/` directory. - -You can file issues, edit content, and review changes from others, all from the -GitHub website. You can also use GitHub's embedded history and search tools. ---> -Kubernetes 文档是以 Markdown 形式编写的，使用 Hugo 进行部署。源码位于 Github 的 [https://github.com/kubernetes/website](https://github.com/kubernetes/website)。大部分文档源码位于 `/content/en/docs/`。有些参考文档是由 `update-imported-docs/` 目录内的脚本自动生产的。 - -您可以提交 issue、编辑内容或者对其他人的提交内容进行复审，这些都可以在 Github 网站上完成。您也可以使用 Github 内置的历史功能和查询工具。 - -<!-- -Not all tasks can be done in the GitHub UI, but these are discussed in the -[intermediate](/docs/contribute/intermediate/) and -[advanced](/docs/contribute/advanced/) docs contribution guides. - -### Participating in SIG Docs ---> -并非所有的任务都可以通过 Github UI 完成，这些任务会在[中级](/docs/contribute/intermediate/)和[高级](/docs/contribute/advanced/)文档贡献指南中讨论 - -### 参与文档特别兴趣小组（SIG Docs） - -<!-- -The Kubernetes documentation is maintained by a -{{< glossary_tooltip text="Special Interest Group" term_id="sig" >}} (SIG) -called SIG Docs. We [communicate](#participate-in-sig-docs-discussions) using a Slack channel, a mailing list, and -weekly video meetings. New participants are welcome. For more information, see -[Participating in SIG Docs](/docs/contribute/participating/). ---> -Kubernetes 文档是由 {{< glossary_tooltip text="特别兴趣小组" term_id="sig" >}} (SIG) 维护的，该小组名为 SIG Docs。我们通过 Slack 频道、邮件列表和网络视频周会进行[交流](#参与-sig-docs-讨论)。欢迎新的参与者加入。更多信息，请参考[参与 SIG Docs](/docs/contribute/participating/)。 - -<!-- -### Content guildelines - -The SIG Docs community created guidelines about what kind of content is allowed -in the Kubernetes documentation. Look over the [Documentation Content -Guide](/docs/contribute/style/content-guide/) to determine if the content -contribution you want to make is allowed. You can ask questions about allowed -content in the [#sig-docs]((#participate-in-sig-docs-discussions)) Slack -channel. ---> -### 内容指南 - -SIG Docs 社区创建了有关 Kubernetes 文档中允许哪种内容的指南。查看[文档内容指南](/docs/contribute/style/content-guide/)确定是否允许您要进行的内容贡献。您可以在 [#sig-docs](#参与-sig-docs-讨论) 频道中询问有关允许内容的问题。 - -<!-- -### Style guidelines - -We maintain a [style guide](/docs/contribute/style/style-guide/) with information -about choices the SIG Docs community has made about grammar, syntax, source -formatting, and typographic conventions. Look over the style guide before you -make your first contribution, and use it when you have questions. ---> -### 风格指南 - -我们维护了一个[风格指南](/docs/contribute/style/style-guide/)页面，上面有关于 SIG Docs 社区对于语法、句法、源格式和排版的约定。在您做首次贡献前或者在有疑问的时候请先查阅风格指南。 - -<!-- -Changes to the style guide are made by SIG Docs as a group. To propose a change -or addition, [add it to the agenda](https://docs.google.com/document/d/1zg6By77SGg90EVUrhDIhopjZlSDg2jCebU-Ks9cYx0w/edit#) for an upcoming SIG Docs meeting, and attend the meeting to participate in the -discussion. See the [advanced contribution](/docs/contribute/advanced/) topic for more -information. ---> -风格的变化是由 SIG Docs 组共同决定的。如您想提交变更或增加内容，请将内容[添加到议题](https://docs.google.com/document/d/1zg6By77SGg90EVUrhDIhopjZlSDg2jCebU-Ks9cYx0w/edit#)并参与会议讨论。更多信息，参见[进阶贡献](/docs/contribute/advanced/)主题。 - -<!-- -### Page templates - -We use page templates to control the presentation of our documentation pages. -Be sure to understand how these templates work by reviewing -[Using page templates](/docs/contribute/style/page-templates/). - -### Hugo shortcodes ---> -### 页面模板 - -我们使用页面模板来控制文档页面。需要确保您理解这些模版是如何工作的，请阅读[使用页面模板](/docs/contribute/style/page-templates/)。 - -### Hugo 短代码 - -<!-- -The Kubernetes documentation is transformed from Markdown to HTML using Hugo. -We make use of the standard Hugo shortcodes, as well as a few that are custom to -the Kubernetes documentation. See [Custom Hugo shortcodes](/docs/contribute/style/hugo-shortcodes/) for -information about how to use them. - -### Multiple languages ---> -Kubernetes 文档使用 Hugo 将 Markdown 转换成 HTML。我们使用标准的 Hugo 短代码，同时也会有部分为 Kubernetes 定制化的代码。有关如何使用短代码的信息，请参见[自定义 Hugo 短代码](/docs/contribute/style/hugo-shortcodes/)。 - -### 多语言 - -<!-- -Documentation source is available in multiple languages in `/content/`. Each language has its own folder with a two-letter code determined by the [ISO 639-1 standard](https://www.loc.gov/standards/iso639-2/php/code_list.php). For example, English documentation source is stored in `/content/en/docs/`. - -For more information about contributing to documentation in multiple languages, see ["Localize content"](/docs/contribute/intermediate#localize-content) in the intermediate contributing guide. ---> -在 `/content/` 目录中有文档源码的多语言版本。每个语言拥有其自己的目录，采用 [ISO 639-1 标准](https://www.loc.gov/standards/iso639-2/php/code_list.php) 的两位编码命名。例如，英文文档源码位于 `/content/en/docs/` 目录。 - -更多关于对多语言文档做贡献的信息，请参考中级贡献指南中的["本地化内容"](/docs/contribute/intermediate#localize-content)。 - -<!-- -If you're interested in starting a new localization, see ["Localization"](/docs/contribute/localization/). - -## File actionable issues ---> -如果您有兴趣开始一个新的本地化语言项目，请参考["本地化"](/docs/contribute/localization/)。 - -## 提出可操作的 issues - -<!-- -Anyone with a GitHub account can file an issue (bug report) against the -Kubernetes documentation. If you see something wrong, even if you have no idea -how to fix it, [file an issue](#how-to-file-an-issue). The exception to this -rule is a tiny bug like a typo that you intend to fix yourself. In that case, -you can instead [fix it](#improve-existing-content) without filing a bug first. - -### How to file an issue ---> -任何拥有 Github 账号的人都能对于 Kubernetes 提出可行的 issue（或者 bug report）。如果发现问题，即便您不知道如何修复它，请[提出 issue](#how-to-file-an-issue)。除非您发现微小的错误的情况，例如发现了一个拼写错误，您想自己进行修复。在这种情况下，您可以[修复它](#improve-existing-content)，而不用先提出一个 bug。 - -### 如何提出 issue - -<!-- -- **On an existing page** - - If you see a problem in an existing page in the [Kubernetes docs](/docs/), - go to the bottom of the page and click the **Create an Issue** button. If - you are not currently logged in to GitHub, log in. A GitHub issue form - appears with some pre-populated content. - - Using Markdown, fill in as many details as you can. In places where you see - empty square brackets (`[ ]`), put an `x` between the set of brackets that - represents the appropriate choice. If you have a proposed solution to fix - the issue, add it. ---> -- **对于已有页面** - - 如果您在已有的 [Kubernetes 文档](/docs/)页面，在页面底部直接点击 **创建 Issue** 按钮。如果您当前未登录 Github，那么请登录。Github 文档表单会带着预填的信息出现。 - - 使用 Markdown 格式，填写尽可能多的详细信息。在方括号 (`[ ]`) 中，使用 `x` 代码选择了该选项。如果您提交了修复 issue 的方法，也填在里面。 - -<!-- -- **Request a new page** - - If you think content should exist, but you aren't sure where it should go or - you don't think it fits within the pages that currently exist, you can - still file an issue. You can either choose an existing page near where you think the - new content should go and file the issue from that page, or go straight to - [https://github.com/kubernetes/website/issues/new/](https://github.com/kubernetes/website/issues/new/) - and file the issue from there. ---> -- **请求创建一个新页面** - - 如果认为有些内容应该存在，但您不知道应该将这些内容存放在哪里，或者任何不适合放在现有页面中，那么也可以提出一个 issue。您可以选择通过内容相近的页面创建 issue，或者直接在 [https://github.com/kubernetes/website/issues/new/](https://github.com/kubernetes/website/issues/new/)中记录 issue。 - -<!-- -### How to file great issues - -To ensure that we understand your issue and can act on it, keep these guidelines -in mind: ---> -### 如何记录好的 issues - -要确保我们能理解您的 issue，并能付诸行动，请谨记如下指南： - -<!-- -- Use the issue template, and fill out as many details as you can. -- Clearly explain the specific impact the issue has on users. -- Limit the scope of a given issue to a reasonable unit of work. For problems - with a large scope, break them down into smaller issues. - - For instance, "Fix the security docs" is not an actionable issue, but "Add - details to the 'Restricting network access' topic" might be. -- If the issue relates to another issue or pull request, you can refer to it - either by its full URL or by the issue or pull request number prefixed - with a `#` character. For instance, `Introduced by #987654`. -- Be respectful and avoid venting. For instance, "The docs about X suck" is not - helpful or actionable feedback. The - [Code of Conduct](/community/code-of-conduct/) also applies to interactions on - Kubernetes GitHub repositories. ---> -- 使用 issue 模板，尽可能填写详细的信息。 -- 清楚地描述该 issue 对用户造成的具体影响。 -- 限制 issue 的范围，以提交给合理的工作组。如果问题范围很大，将其拆分成若干个 issues。 - - 例如，“修复安全文档”就是一个不可执行的 issue，但 “为'限制网络访问'主题添加详细信息”就是可执行的。 -- 如果 issue 与另一个 issue 或者拉取请求（PR）有关，您可以通过 issue 的完整 URL 或者 PR 的序号（以 `#` 为前缀）进行关联。例如 `如 #987654`。 -- 保持尊重，避免发泄。例如，“关于 X 的文档很差”就是无用且不可执行的反馈。[行为准测](/community/code-of-conduct/) 也适用于 Kubernetes Github 仓库的交互。 - -<!-- -## Participate in SIG Docs discussions - -The SIG Docs team communicates using the following mechanisms: - -- [Join the Kubernetes Slack instance](http://slack.k8s.io/), then join the - `#sig-docs` channel, where we discuss docs issues in real-time. Be sure to - introduce yourself! -- [Join the `kubernetes-sig-docs` mailing list](https://groups.google.com/forum/#!forum/kubernetes-sig-docs), - where broader discussions take place and official decisions are recorded. -- Participate in the [weekly SIG Docs](https://github.com/kubernetes/community/tree/master/sig-docs) video meeting, which is announced on the Slack channel and the mailing list. Currently, these meetings take place on Zoom, so you'll need to download the [Zoom client](https://zoom.us/download) or dial in using a phone. ---> -## 参与 SIG Docs 讨论 - -SIG Docs 团队交流采用如下机制： - -- [加入 Kubernetes 的 Slack 工作组](http://slack.k8s.io/)，然后加入 `#sig-docs` 频道，在那里我会实时讨论文档的 issues。一定要做自我介绍！ -- [加入 `kubernetes-sig-docs` 邮件列表](https://groups.google.com/forum/#!forum/kubernetes-sig-docs)，在这里会有广泛的讨论以及官方决策的记录。 -- 参与 [SIG Docs 视频周例会](https://github.com/kubernetes/community/tree/master/sig-docs)，会通过 Slack 频道和邮件列表通知。 - 目前通过 Zoom 进行会议，所以您需要下载 [Zoom 客户端](https://zoom.us/download)，或者通过手机拨入。 - -{{< note >}} -<!-- -You can also check the SIG Docs weekly meeting on the [Kubernetes community meetings calendar](https://calendar.google.com/calendar/embed?src=cgnt364vd8s86hr2phapfjc6uk%40group.calendar.google.com&ctz=America/Los_Angeles). --->您也可以查看 [Kubernetes 社区会议日历](https://calendar.google.com/calendar/embed?src=cgnt364vd8s86hr2phapfjc6uk%40group.calendar.google.com&ctz=America/Los_Angeles)。 -{{< /note >}} - -<!-- -## Improve existing content - -To improve existing content, you file a _pull request (PR)_ after creating a -_fork_. Those two terms are [specific to GitHub](https://help.github.com/categories/collaborating-with-issues-and-pull-requests/). -For the purposes of this topic, you don't need to know everything about them, -because you can do everything using your web browser. When you continue to the -[intermediate docs contributor guide](/docs/contribute/intermediate/), you will -need more background in Git terminology. ---> -## 改进现有内容 - -要改进现有的内容，您可以在创建 _fork_ 之后起草一个 _拉取请求（PR）_ 。这两个术语是 [Github 专用的](https://help.github.com/categories/collaborating-with-issues-and-pull-requests/)。 -出于本主题的目的，您无需了解有关它们的所有信息，因为您可以通过浏览器做所有的事情。当您继续阅读[贡献者中级指南](/docs/contribute/intermediate/)，您会需要更多 Git 术语的背景知识。 - -{{< note >}} -<!-- -**Kubernetes code developers**: If you are documenting a new feature for an -upcoming Kubernetes release, your process is a bit different. See -[Document a feature](/docs/contribute/intermediate/#sig-members-documenting-new-features) for -process guidelines and information about deadlines. --->**Kubernetes 代码开发者**：如果您在撰写 Kubernetes 新版本的新功能文档，流程会稍有不同。 -关于流程指南和最后期限的信息，请参阅[编写功能文档](/docs/contribute/intermediate/#sig-members-documenting-new-features)。 -{{< /note >}} - -<!-- -### Sign the CNCF CLA {#sign-the-cla} - -Before you can contribute code or documentation to Kubernetes, you **must** read -the [Contributor guide](https://github.com/kubernetes/community/blob/master/contributors/guide/README.md) and -[sign the Contributor License Agreement (CLA)](https://github.com/kubernetes/community/blob/master/CLA.md). -Don't worry -- this doesn't take long! - -### Find something to work on ---> -## 签署 CNCF CLA {#sign-the-cla} - -在贡献 Kubernetes 的代码或文档前，您 **必须** 阅读[贡献者指南](https://github.com/kubernetes/community/blob/master/contributors/guide/README.md)，并[签署贡献者许可协议（CLA）](https://github.com/kubernetes/community/blob/master/CLA.md)。 -别担心 -- 不需要太多时间！ - -### 开始贡献 - -<!-- -If you see something you want to fix right away, just follow the instructions -below. You don't need to [file an issue](#file-actionable-issues) (although you -certainly can). - -If you want to start by finding an existing issue to work on, go to -[https://github.com/kubernetes/website/issues](https://github.com/kubernetes/website/issues) -and look for issues with the label `good first issue` (you can use -[this](https://github.com/kubernetes/website/issues?q=is%3Aopen+is%3Aissue+label%3A%22good+first+issue%22) shortcut). Read through the comments and make sure there is not an open pull -request against the issue and that nobody has left a comment saying they are -working on the issue recently (3 days is a good rule). Leave a comment saying -that you would like to work on the issue. ---> -如果您发现了一些想要马上修复的问题，只需要遵循如下指南。您不需要[提出一个 issue](#file-actionable-issues)（尽管你当然可以这么做）。 - -如果您想从处理现有的 issue 开始，前往 [https://github.com/kubernetes/website/issues](https://github.com/kubernetes/website/issues) 找一些有 `good first issue` 标签的 issue （您可以使用[这个](https://github.com/kubernetes/website/issues?q=is%3Aopen+is%3Aissue+label%3A%22good+first+issue%22) 快捷方式)。阅读评论，确保针对此 issue 没有打开的 PR，并且没有人留言说他们最近正在解决这个 issue （3 天是个很好的规则）。留言说您会去解决这个 issue。 - -<!-- -### Choose which Git branch to use - -The most important aspect of submitting pull requests is choosing which branch -to base your work on. Use these guidelines to make the decision: ---> -### 选择使用的 Git 分支 - -提交 PR 最重要的方面就是选择您工作所基于的基础分支。使用如下指南来做决定： - -<!-- -- Use `master` for fixing problems in content that is already published, or - making improvements to content that already exists. - - Use a release branch (such as `dev-{{< release-branch >}}` for the {{< release-branch >}} release) to document upcoming features - or changes for an upcoming release that is not yet published. -- Use a feature branch that has been agreed upon by SIG Docs to collaborate on - big improvements or changes to the existing documentation, including content - reorganization or changes to the look and feel of the website. - -If you're still not sure which branch to choose, ask in `#sig-docs` on Slack or -attend a weekly SIG Docs meeting to get clarity. ---> -- 用 `master` 来解决以及发布的内容中的问题，或者对于已经存在的内容进行改进。 -- 使用 release 分支（比如 `dev-{{< release-branch >}}` 用于 {{< release-branch >}} 发布）来撰写新的特性或者下个版本还未发布的变更说明。 -- 使用 SIG Docs 已经同意的 feature 分支来协作对现有文档进行重大改进或更改，包括内容重组或网站外观的更改。 - -如果您还不确定应该使用哪个分支，在 Slack 上询问 `#sig-docs` 或者参与 SIG Docs 周例会来确认。 - -<!-- -### Submit a pull request ---> -### 提交 PR - -<!-- -Follow these steps to submit a pull request to improve the Kubernetes -documentation. - -1. On the page where you see the issue, click the pencil icon at the top right. - A new GitHub page appears, with some help text. -2. If you have never created a fork of the Kubernetes documentation - repository, you are prompted to do so. Create the fork under your GitHub - username, rather than another organization you may be a member of. The - fork usually has a URL such as `https://github.com/<username>/website`, - unless you already have a repository with a conflicting name. - - The reason you are prompted to create a fork is that you do not have - access to push a branch directly to the definitive Kubernetes repository. - -3. The GitHub Markdown editor appears with the source Markdown file loaded. - Make your changes. Below the editor, fill in the **Propose file change** - form. The first field is the summary of your commit message and should be - no more than 50 characters long. The second field is optional, but can - include more detail if appropriate. ---> - -按照如下步骤提交 PR 来改善 Kubernetes 文档。 - -1. 在您提交 issue 的页面上，点击右上角的铅笔图标。新的页面就会出现，上面会有一些帮助信息。 -2. 如果您从未创建过 Kubernetes 文档仓库的 fork，会提示您需要创建。请在您的 Github 账号下创建 fork，而不是在您所在的组织下创建。fork URL 通常是这样的 `https://github.com/<username>/website`，除非您已经有一个同名的仓库，那样会造成冲突。 - 您创建 fork 的原因是您无权直接将分支推送到确定的 Kubernetes 仓库。 - -3. Github Markdown 编辑器会载入着文档源码一起出现。根据实际情况撰写变化内容。在编辑器下方填写 **Propose file change（建议修改文件）** 表格。第一个区域需要填写提交说明消息，不能超过 50 个字符。第二个区域是可选的，也能够填写更多详细信息。 - - {{< note >}} -<!-- -Do not include references to other GitHub issues or pull -requests in your commit message. You can add those to the pull request -description later. --->不要把 Github issues 或者 PR 的关联信息放在您的提交说明消息中。您可以之后把这些内容添加到 PR 的描述中。 -{{< /note >}} - - <!-- - Click **Propose file change**. The change is saved as a commit in a - new branch in your fork, which is automatically named something like - `patch-1`. - --> - 点击 **建议修改文件（Propose file change）** 按钮。变更会保存为您 fork 新分支（通常会自动命名为 `patch-1`）中的一个提交内容。 - -<!-- -4. The next screen summarizes the changes you made, by comparing your new - branch (the **head fork** and **compare** selection boxes) to the current - state of the **base fork** and **base** branch (`master` on the - `kubernetes/website` repository by default). You can change any of the - selection boxes, but don't do that now. Have a look at the difference - viewer on the bottom of the screen, and if everything looks right, click - **Create pull request**. ---> -4. 接下来屏幕会总结您的变更，将您的新分支（**head fork** 和 **compare** 选择框）与 **base fork** - 和 **base** 分支(默认是 `kubernetes/website` 的 `master` 分支)进行比较。您可以更改选择框，但现在请不要这么做。看一下屏幕底部显示的变化内容，如果看起来没问题，点击 **创建 PR（Create pull request）** 按钮。 - - {{< note >}} -<!-- -If you don't want to create the pull request now, you can do it -later, by browsing to the main URL of the Kubernetes website repository or -your fork's repository. The GitHub website will prompt you to create the -pull request if it detects that you pushed a new branch to your fork. --->如果您现在还不想创建 PR，也可以稍后再做，通过浏览 Kubernetes 网站代码仓库或者您 fork 仓库的网站主页 URL。Github 网站会检查到您推送了一个新分支到 fork，并提示创建 PR。 -{{< /note >}} - -<!-- -5. The **Open a pull request** screen appears. The subject of the pull request - is the same as the commit summary, but you can change it if needed. The - body is populated by your extended commit message (if present) and some - template text. Read the template text and fill out the details it asks for, - then delete the extra template text. If you add to the description `fixes #<000000>` - or `closes #<000000>`, where `#<000000>` is the number of an associated issue, - GitHub will automatically close the issue when the PR merges. - Leave the **Allow edits from maintainers** checkbox selected. Click - **Create pull request**. ---> -5. **Open a pull request（打开一个 PR）** 屏幕出现了。PR 的主题和提交说明的内容一致， - 如有需要您也可以修改。主体内容会自动填充您的扩展提交消息（如果存在）和一些模板文本。 - 阅读模板文本并填写要求的详细信息，然后删除额外的模板文本。 - 如果在描述中添加 `fixes #<000000>` 或者 `closes #<000000>`，其中 `#<000000>` 是相关问题的编号，则当PR合并时，GitHub 将自动关闭该问题。 - 保留选中 **Allow edits from maintainers（允许维护者编辑）** 复选框。 - 单击 **Create pull request（创建拉取请求）** 按钮。 - - <!-- - Congratulations! Your pull request is available in - [Pull requests](https://github.com/kubernetes/website/pulls). - - After a few minutes, you can preview the website with your PR's changes - applied. Go to the **Conversation** tab of your PR and click the **Details** - link for the `deploy/netlify` test, near the bottom of the page. It opens in - the same browser window by default. - --> - 祝贺您！您的 PR 就出现在了[拉取请求](https://github.com/kubernetes/website/pulls) 中。 - - 几分钟后，您可以预览 PR 所带来的变化。前往您 PR 的 **Conversation（对话）** 标签页， - 点击 `deploy/netlify` 测试的 **Details（详细信息）** 链接，它在页面底部附件。 - 默认会在同一个浏览器窗口中打开。 - - {{< note >}} - <!-- - Please limit pull requests to one language per PR. For example, if you need to make an identical change to the same code sample in multiple languages, open a separate PR for each language. - -->请将 PR 请求限制为每种 PR 只能使用一种语言。例如，如果您需要对多种语言的同一代码示例进行相同的更改，请为每种语言打开一个单独的 PR。 - {{< /note >}} - -<!-- -6. Wait for review. Generally, reviewers are suggested by the `k8s-ci-robot`. - If a reviewer asks you to make changes, you can go to the **Files changed** - tab and click the pencil icon on any files that have been changed by the - pull request. When you save the changed file, a new commit is created in - the branch being monitored by the pull request. If you are waiting on a - reviewer to review the changes, proactively reach out to the reviewer - once every 7 days. You can also drop into #sig-docs Slack channel, - which is a good place to ask for help regarding PR reviews. - -7. If your change is accepted, a reviewer merges your pull request, and the - change is live on the Kubernetes website a few minutes later. ---> -6. 等待复审。通常，复审人员会由 `k8s-ci-robot` 建议指定。如果复审人员建议您修改，您可以 - 前往 **Files changed（改变的文件内容）** 标签页，点击任意 PR 中改变的文件页面上的铅笔图标。 - 保存更改的文件时，将在 PR 监视的分支中创建新的提交。如果您正在等待复审者审核更改， - 请每 7 天主动与复审者联系一次。您也可以进入 #sig-docs Slack 频道，这是寻求有关 PR 审查的帮助的好地方。 - -7. 如果修改被接受，复审人员会合并您的 PR，修改就会在几分钟后在 Kubernetes 网站上生效。 - -<!-- -This is only one way to submit a pull request. If you are already a Git and -GitHub advanced user, you can use a local GUI or command-line Git client -instead of using the GitHub UI. Some basics about using the command-line Git -client are discussed in the [intermediate](/docs/contribute/intermediate/) docs -contribution guide. ---> -这是提交 PR 的唯一方式。如果您已经是一名 Git 和 Github 的高级用户，您也可以使用本地 GUI 或者 -Git 命令行。关于使用 Git 客户端的基础会在[中级](/docs/contribute/intermediate/) 贡献者指南中讨论。 - -<!-- -## Review docs pull requests - -People who are not yet approvers or reviewers can still review pull requests. -The reviews are not considered "binding", which means that your review alone -won't cause a pull request to be merged. However, it can still be helpful. Even -if you don't leave any review comments, you can get a sense of pull request -conventions and etiquette and get used to the workflow. ---> -## 复审文档 PR - -就算不是批注者或者复审者，也同样可以复审 PR。复审人员并不是"固定"的，意味着您单独的评审并不会让 PR 合并。然而，这依然对我们是很有帮助的。即使您没有留下任何评审意见，您可以了解 PR 的规范和礼仪，并习惯工作流程。 - -<!-- -1. Go to - [https://github.com/kubernetes/website/pulls](https://github.com/kubernetes/website/pulls). - You see a list of every open pull request against the Kubernetes website and - docs. ---> -1. 前往 [https://github.com/kubernetes/website/pulls](https://github.com/kubernetes/website/pulls)。 - 请会看到一个列表，里面包含了所有对于 Kubernetes 网站和文档提的 PR。 - -<!-- -2. By default, the only filter that is applied is `open`, so you don't see - pull requests that have already been closed or merged. It's a good idea to - apply the `cncf-cla: yes` filter, and for your first review, it's a good - idea to add `size/S` or `size/XS`. The `size` label is applied automatically - based on how many lines of code the PR modifies. You can apply filters using - the selection boxes at the top of the page, or use - [this shortcut](https://github.com/kubernetes/website/pulls?q=is%3Aopen+is%3Apr+label%3A%22cncf-cla%3A+yes%22+label%3Asize%2FS) for only small PRs. All filters are `AND`ed together, so - you can't search for both `size/XS` and `size/S` in the same query. ---> -2. 默认情况下，使用的筛选器是 `open`，所以您不会看见已经关闭或合并的 PR。 - 最好使用 `cncf-cla: yes` 筛选器，并且对于第一次复审来说，最好加上 `size/S` - 或者 `size/XS`。`size` 标签会根据 PR 修改的代码行数自动生成。 - 您可以通过页面顶端的选择框应用筛选器，或者使用 - [快捷方式](https://github.com/kubernetes/website/pulls?q=is%3Aopen+is%3Apr+label%3A%22cncf-cla%3A+yes%22+label%3Asize%2FS) - 来查找所有小型 PR。所有筛选条件都是 `与` 的，所以您不能在一次查询中同时查找 `size/XS` 和 `size/S` 的结果。 - -<!-- -3. Go to the **Files changed** tab. Look through the changes introduced in the - PR, and if applicable, also look at any linked issues. If you see a problem - or room for improvement, hover over the line and click the `+` symbol that - appears. - - You can type a comment, and either choose **Add single comment** or **Start - a review**. Typically, starting a review is better because it allows you to - leave multiple comments and notifies the PR owner only when you have - completed the review, rather than a separate notification for each comment. ---> -3. 前往 **Files changed（文件修改）** 标签页。查看 PR 中的变化部分，如果适用，也看一下关联的问题。如果您发现问题或者可以改进的空间， - 将鼠标悬浮在那一行并点击前面出现的 `+` 加号。 - - 你可以留下评论，选择 **Add single comment（仅添加评论）** 或者也可以 **Start a review（开始复审）**。典型来说，开始复审更好，因为这样您就可以在多行下留下评论，并且只有在完成复审后统一提交并通知 PR 的作者，而不是每一条评论都发送通知。 - -<!-- -4. When finished, click **Review changes** at the top of the page. You can - summarize your review, and you can choose to comment, approve, or request - changes. New contributors should always choose **Comment**. ---> -4. 完成后，点击页面顶端但 **Review changes（复审修改）** 按钮。您可以总结复审，并且可以选择comment（评论），approve（批准），或者 request changes（请求变更）。新的贡献者应该选择 **Comment（评论）**。 - -<!-- -Thanks for reviewing a pull request! When you are new to the project, it's a -good idea to ask for feedback on your pull request reviews. The `#sig-docs` -Slack channel is a great place to do this. - -## Write a blog post ---> -感谢您对于 PR 的复审工作！当您对于项目还是新人时，最好在拉取请求评论中征求反馈意见。Slack 的 `#sig-docs` 频道就是一个征求意见好去处。 - -## 撰写博客文章 - -<!-- -Anyone can write a blog post and submit it for review. Blog posts should not be -commercial in nature and should consist of content that will apply broadly to -the Kubernetes community. - -To submit a blog post, you can either submit it using the -[Kubernetes blog submission form](https://docs.google.com/forms/d/e/1FAIpQLSdMpMoSIrhte5omZbTE7nB84qcGBy8XnnXhDFoW0h7p2zwXrw/viewform), -or follow the steps below. ---> -任何人都可以撰写博客并提交复审。博客文章不应具有商业性质，而应包含广泛适用于 Kubernetes 社区的内容。 - -要提交博客文章，您可以选择使用 [Kubernetes 博客提交表单](https://docs.google.com/forms/d/e/1FAIpQLSdMpMoSIrhte5omZbTE7nB84qcGBy8XnnXhDFoW0h7p2zwXrw/viewform)或者按如下步骤进行： - -<!-- -1. [Sign the CLA](#sign-the-cla) if you have not yet done so. -2. Have a look at the Markdown format for existing blog posts in the - [website repository](https://github.com/kubernetes/website/tree/master/content/en/blog/_posts). -3. Write out your blog post in a text editor of your choice. -4. On the same link from step 2, click the **Create new file** button. Paste - your content into the editor. Name the file to match the proposed title of - the blog post, but don't put the date in the file name. The blog reviewers - will work with you on the final file name and the date the blog will be - published. -5. When you save the file, GitHub will walk you through the pull request - process. -6. A blog post reviewer will review your submission and work with you on - feedback and final details. When the blog post is approved, the blog will be - scheduled for publication. ---> -1. 如果您还未签署 CLA，请[签署 CLA](#sign-the-cla)。 -2. 查看现有博客文章的 Markdown 格式，位于[网站代码仓库](https://github.com/kubernetes/website/tree/master/content/en/blog/_posts)。 -3. 在您选择的文本编辑器中写下您的博客文章。 -4. 在步骤 2 的相同链接中，点击 **Create new file（创建新文件）** 按钮。 - 将您的内容粘贴到编辑器中。将文件命名为与博客文章的标题的名称， - 但不要将日期放在文件名中。博客复审人员将与您一起确定最终文件名和博客发布日期。 -5. 保存文件时，Github 将引导您完成 PR 过程。 -6. 博客复审人员会对您的提交对内容进行复审，并与您一起完成反馈意见和最终的详细信息。 - 博客文章获得批准后，博客将会安排时间进行发布。 - -<!-- -## Submit a case study - -Case studies highlight how organizations are using Kubernetes to solve -real-world problems. They are written in collaboration with the Kubernetes -marketing team, which is handled by the {{< glossary_tooltip text="CNCF" term_id="cncf" >}}. - -Have a look at the source for the -[existing case studies](https://github.com/kubernetes/website/tree/master/content/en/case-studies). -Use the [Kubernetes case study submission form](https://www.cncf.io/people/end-user-community/) -to submit your proposal. ---> -## 提交案例研究 - -案例研究强调组织如何使用 Kubernetes 解决实际问题。它们是由 Kubernetes 市场团队共同撰写的，由 {{< glossary_tooltip text="CNCF" term_id="cncf" >}} 进行处理。 - -看一下[现有案例研究](https://github.com/kubernetes/website/tree/master/content/en/case-studies)的源码。 -使用 [Kubernetes 案例研究提交表](https://www.cncf.io/people/end-user-community/)提交您的提案。 - - - -## {{% heading "whatsnext" %}} - - -<!-- -When you are comfortable with all of the tasks discussed in this topic and you -want to engage with the Kubernetes docs team in deeper ways, read the -[intermediate docs contribution guide](/docs/contribute/intermediate/). ---> -当您对本主题中讨论的所有任务感到满意，并且您希望以更深入的方式与 Kubernetes 文档团队合作，请阅读[中级贡献者指南](/docs/contribute/intermediate/)。 - - diff --git a/content/zh/docs/contribute/style/_index.md b/content/zh/docs/contribute/style/_index.md index aacaf26575..2b50a245fa 100644 --- a/content/zh/docs/contribute/style/_index.md +++ b/content/zh/docs/contribute/style/_index.md @@ -1,15 +1,13 @@ --- -title: 文档风格概述 +title: 文档样式概述 main_menu: true weight: 80 --- <!-- ---- title: Documentation style overview main_menu: true weight: 80 ---- --> <!-- @@ -17,5 +15,5 @@ The topics in this section provide guidance on writing style, content formatting and organization, and using Hugo customizations specific to Kubernetes documentation. --> - -本节的主题是提供有关编写风格、内容格式和组织以及使用 Hugo 定制生成 Kubernetes 文档的指导。 +本节的主题是提供有关写作风格、内容格式和组织以及如何使用 +特定于 Kubernetes 文档的 Hugo 定制代码的指导。 diff --git a/content/zh/docs/contribute/style/content-guide.md b/content/zh/docs/contribute/style/content-guide.md new file mode 100644 index 0000000000..a1784f1763 --- /dev/null +++ b/content/zh/docs/contribute/style/content-guide.md @@ -0,0 +1,142 @@ +--- +title: 文档内容指南 +linktitle: 内容指南 +content_type: concept +weight: 10 +--- +<!-- +title: Documentation Content Guide +linktitle: Content guide +content_type: concept +weight: 10 +--> + +<!-- overview --> +<!-- +This page contains guidelines for Kubernetes documentation. + +If you have questions about what's allowed, join the #sig-docs channel in +[Kubernetes Slack](http://slack.k8s.io/) and ask! + +You can register for Kubernetes Slack at http://slack.k8s.io/. + +For information on creating new content for the Kubernetes +docs, follow the [style guide](/docs/contribute/style/style-guide). +--> +本页包含 Kubernetes 文档的一些指南。 + +如果你不清楚哪些事情是可以做的，请加入到 +[Kubernetes Slack](http://slack.k8s.io/) 的 `#sig-docs` 频道提问！ +你可以在 http://slack.k8s.io 注册到 Kubernetes Slack。 + +关于为 Kubernetes 文档创建新内容的更多信息，可参考 +[样式指南](/zh/docs/contribute/style/style-guide)。 + +<!-- body --> + +<!-- +## Overview + +Source for the Kubernetes website, including the docs, resides in the +[kubernetes/website](https://github.com/kubernetes/website) repository. + +Located in the `kubernetes/website/content/<language_code>/docs` folder, the +majority of Kubernetes documentation is specific to the [Kubernetes +project](https://github.com/kubernetes/kubernetes). + +## What's allowed + +Kubernetes docs allow content for third-party projects only when: + +- Content documents software in the Kubernetes project +- Content documents software that's out of project but necessary for Kubernetes to function +- Content is canonical on kubernetes.io, or links to canonical content elsewhere +--> +## 概述 {#overview} + +Kubernetes 网站（包括其文档）源代码位于 +[kubernetes/website](https://github.com/kubernetes/website) 仓库中。 + +在 `kubernetes/website/content/<语言代码>/docs` 目录下, 绝大多数 Kubernetes +文档都是特定于 [Kubernetes 项目](https://github.com/kubernetes/kubernetes)的。 + +## 可以发布的内容 {#what-s-allowed} + +只有当以下条件满足时，Kuberentes 文档才允许第三方项目的内容： + +- 内容所描述的软件在 Kubernetes 项目内 +- 内容所描述的软件不在 Kubernetes 项目内，却是让 Kubernetes 正常工作所必需的 +- 内容是被 kubernetes.io 域名收编的，或者是其他位置的标准典型内容 + +<!-- +### Third party content + +Kubernetes documentation includes applied examples of projects in the Kubernetes project—projects that live in the [kubernetes](https://github.com/kubernetes) and +[kubernetes-sigs](https://github.com/kubernetes-sigs) GitHub organizations. + +Links to active content in the Kubernetes project are always allowed. + +Kubernetes requires some third party content to function. Examples include container runtimes (containerd, CRI-O, Docker), +[networking policy](/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/) (CNI plugins), [Ingress controllers](https://kubernetes.io/docs/concepts/services-networking/ingress-controllers/), and [logging](https://kubernetes.io/docs/concepts/cluster-administration/logging/). + +Docs can link to third-party open source software (OSS) outside the Kubernetes project only if it's necessary for Kubernetes to function. +--> +### 第三方内容 {#third-party-content} + +Kubernetes 文档包含 Kubernetes 项目下的多个项目的应用示例。 +这里的 Kubernetes 项目指的是 [kubernetes](https://github.com/kubernetes) 和 +[kubernetes-sigs](https://github.com/kubernetes-sigs) GitHub 组织 +下的项目。 + +链接到 Kubernetes 项目中活跃的内容是一直允许的。 + +Kubernetes 需要某些第三方内容才能正常工作。例如 +容器运行时（containerd、CRI-O、Docker）， +[联网策略](/zh/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/) +（CNI 插件），[Ingress 控制器](/zh/docs/concepts/services-networking/ingress-controllers/) +以及[日志](https://kubernetes.io/zh/docs/concepts/cluster-administration/logging/)等。 + +只有对应的第三方开源软件（OSS）是运行 Kubernetes 所必需的，才可以在文档中包含 +指向这些 Kubernetes 项目之外的软件的链接。 + +<!-- +### Dual sourced content + +Wherever possible, Kubernetes docs link to canonical sources instead of hosting +dual-sourced content. + +Dual-sourced content requires double the effort (or more!) to maintain +and grows stale more quickly. + +{{< note >}} +If you're a maintainer for a Kubernetes project and need help hosting your own docs, +ask for help in [#sig-docs on Kubernetes Slack](https://kubernetes.slack.com/messages/C1J0BPD2M/). +{{< /note >}} +--> +### 双重来源的内容 {#dual-sourced-content} + +只要有可能，Kubernetes 文档应该指向标准典型的信息源而不是直接托管多重来源的内容。 + +双重来源的内容需要双倍（甚至更多）的投入才能维护，而且通常很快就会变得停滞不前。 + +{{< note >}} +如果你是一个 Kubernetes 项目的维护者，需要帮忙托管你的文档， +请在 Kubernetes 的 [#sig-docs 频道](https://kubernetes.slack.com/messages/C1J0BPD2M/) +提出请求。 +{{< /note >}} + +<!-- +### More information + +If you have questions about allowed content, join the [Kubernetes Slack](http://slack.k8s.io/) #sig-docs channel and ask! +--> +### 更多信息 {#more-information} + +如果你对允许出现的内容有疑问，请加入到 [Kubernetes Slack](http://slack.k8s.io/) +的 `#sig-docs` 频道提问！ + +## {{% heading "whatsnext" %}} + +* 阅读[样式指南](/zh/docs/contribute/style/style-guide)。 + + diff --git a/content/zh/docs/contribute/style/content-organization.md b/content/zh/docs/contribute/style/content-organization.md index b8976252fc..cd9ebcd0b1 100644 --- a/content/zh/docs/contribute/style/content-organization.md +++ b/content/zh/docs/contribute/style/content-organization.md @@ -3,99 +3,80 @@ title: 内容组织 content_type: concept weight: 40 --- - <!-- ---- title: Content organization content_type: concept weight: 40 ---- --> - <!-- overview --> <!-- -This site uses Hugo. In Hugo, [content organization](https://gohugo.io/content-management/organization/) is a core concept. +This site uses Hugo. In Hugo, [content +organization](https://gohugo.io/content-management/organization/) is a core +concept. --> - 本网站使用了 Hugo。在 Hugo 中，[内容组织](https://gohugo.io/content-management/organization/) 是一个核心概念。 - - <!-- body --> - -{{% note %}} <!-- -**Hugo Tip:** Start Hugo with `hugo server --navigateToChanged` for content edit-sessions. +**Hugo Tip:** Start Hugo with `hugo server -navigateToChanged` for content edit-sessions. --> -**Hugo 提示:** 用 `hugo server --navigateToChanged` 命令启动 Hugo 以进行内容编辑会话。 -{{% /note %}} +{{< note >}} +**Hugo 提示：** 用 `hugo server --navigateToChanged` 命令启动 Hugo 以进行内容编辑会话。 +{{< /note >}} <!-- ## Page Lists + +### Page Order + +The documentation side menu, the documentation page browser etc. are listed using Hugo's default sort order, which sorts by weight (from 1), date (newest first), and finally by the link title. + +Given that, if you want to move a page or a section up, set a weight in the page's front matter: --> ## 页面列表 -<!-- -### Page Order ---> - ### 页面顺序 -<!-- -The documentation side menu, the documentation page browser etc. are listed using Hugo's default sort order, which sorts by weight (from 1), date (newest first), and finally by the link title. ---> +文档侧方菜单、文档页面浏览器等以 Hugo 的默认排序顺序列出。Hugo 会按照权重（从 1 开始）、 +日期（最新的排最前面）排序，最后按链接标题排序。 -文档侧方菜单、文档页面浏览器等以 Hugo 的默认排序顺序列出，它按照权重（从1开始）、日期（最新的排第一个）排序，最后按链接标题排序。 - -<!-- -Given that, if you want to move a page or a section up, set a weight in the page's front matter: ---> - -如果你想提升一个页面或一个章节，请在页面头部设置一个较高的权重： +有鉴于此，如果你想将一个页面或一个章节前移，请在页面头部设置一个较高的权重： ```yaml title: My Page weight: 10 ``` - -{{% note %}} <!-- For page weights, it can be smart not to use 1, 2, 3 ..., but some other interval, say 10, 20, 30... This allows you to insert pages where you want later. --> - -对于页面的权重，不建议使用连续的数值，比如1、2、3...，而是采用间隔的数值，比如10、20、30...，这样你可以将后续的页面插入到想要的位置。 -{{% /note %}} - +{{< note >}} +对于页面的权重，不建议使用连续的数值，比如1、2、3...，而应采用间隔的数值，比如10、20、30... +这样将来你可以将其他页面插入到想要的位置。 +{{< /note >}} <!-- ### Documentation Main Menu ---> -### 文档主菜单 - -<!-- The `Documentation` main menu is built from the sections below `docs/` with the `main_menu` flag set in front matter of the `_index.md` section content file: --> +### 文档主菜单 -`Documentation` 主菜单是从 `docs/` 下面的章节构建的，它在 `_index.md` 章节内容文件的头部设置了 `main_menu` 标志： - +`文档` 主菜单是从 `docs/` 下面的章节构建的。 +这些章节在其章节内容文件 `_index.md` 的头部设置了 `main_menu` 标志： ```yaml main_menu: true ``` - <!-- Note that the link title is fetched from the page's `linkTitle`, so if you want it to be something different than the title, change it in the content file: --> - -注意，链接标题是从页面的 `linkTitle` 中提取的，因此如果希望它与标题不同，请在内容文件中更改它： - +注意，链接标题来自页面的 `linkTitle` 字段，因此如果希望它与页面标题不同，请在内容文件中更改它： ```yaml main_menu: true @@ -103,36 +84,31 @@ title: Page Title linkTitle: Title used in links ``` - -{{% note %}} <!-- The above needs to be done per language. If you don't see your section in the menu, it is probably because it is not identified as a section by Hugo. Create a `_index.md` content file in the section folder. --> -以上每种语言都需要完成。如果在菜单中没有看到你的章节，这可能是因为它没有被 Hugo 标识为一个章节。请在章节对应的目录下创建 `_index.md` 内容文件。 -{{% /note %}} +{{< note >}} +以上操作需要为每种语言分别完成。如果在菜单中没有看到你的章节，这可能是因为它没有被 Hugo 识别为一个章节。 +请在章节对应的目录下创建 `_index.md` 内容文件。 +{{< /note >}} <!-- ### Documentation Side Menu ---> +The documentation side-bar menu is built from the _current section tree_ starting below `docs/`. + +It will show all sections and their pages. + +If you don't want to list a section or page, set the `toc_hide` flag to `true` in front matter: + +When you navigate to a section that has content, the specific section or page (e.g. `_index.md`) is shown. Else, the first page inside that section is shown. +--> ### 文档侧方菜单 -<!-- -The documentation side-bar menu is built from the _current section tree_ starting below `docs/`. ---> +文档侧方菜单是基于 `docs/` 下面的 _当前章节的内容树_ 构建的。 -文档侧方菜单是从 `docs/` 下面的 _current 章节的 tree_ 开始构建的。 - -<!-- -It will show all sections and their pages. ---> - -它将显示所有的章节和它们的页面。 - -<!-- -If you don't want to list a section or page, set the `toc_hide` flag to `true` in front matter: ---> +菜单默认显示所有的章节和它们的页面。 如果你不想列出某个章节或页面，请在页面头部将 `toc_hide` 标志设置为 `true`。 @@ -140,27 +116,19 @@ If you don't want to list a section or page, set the `toc_hide` flag to `true` i toc_hide: true ``` -<!-- -When you navigate to a section that has content, the specific section or page (e.g. `_index.md`) is shown. Else, the first page inside that section is shown. ---> - -当导航到具有内容的章节时，将显示出指定的章节或页面（例如 `_index.md`）。否则，将显示该章节里的第一个页面。 +当导航到具有内容的章节时，网站将显示出指定的章节或页面（例如 `_index.md`）。 +否则，将显示该章节里的第一个页面。 <!-- ### Documentation Browser ---> -### 文档浏览器 - -<!-- The page browser on the documentation home page is built using all the sections and pages that are directly below the `docs section`. ---> -文档主页上的页面浏览器是用 `docs section` 下一层的所有章节和页面构建的。 - -<!-- If you don't want to list a section or page, set the `toc_hide` flag to `true` in front matter: --> +### 文档浏览器 {#documentation-browser} + +文档主页上的页面浏览器是基于 `docs section` 下一层的所有章节和页面构建的。 如果你不想列出某个章节或页面，请在页面头部将 `toc_hide` 标志设置为 `true`。 @@ -170,34 +138,30 @@ toc_hide: true <!-- ### The Main Menu ---> -### 主菜单 - -<!-- The site links in the top-right menu -- and also in the footer -- are built by page-lookups. This is to make sure that the page actually exists. So, if the `case-studies` section does not exist in a site (language), it will not be linked to. --> +### 主菜单 -右上菜单中的网站链接（也在页脚中）是通过页面查找构建的。这是为了确保页面实际存在。因此，如果 `case-studies` 章节在网站中不存在（按语言），则它将链接不到。 - +右上菜单中的网站链接（也出现在页脚中）是通过页面查找构建的。 +这是为了确保页面实际存在。因此，如果 `case-studies` 章节在网站（或者其本地化版本）中不存在， +则不会出现对应的链接。 <!-- ## Page Bundles ---> -## 页面包 - -<!-- In addition to standalone content pages (Markdown files), Hugo supports [Page Bundles](https://gohugo.io/content-management/page-bundles/). ---> -除了独立的内容页面（Markdown文件），Hugo 还支持 [页面包](https://gohugo.io/content-management/page-bundles/)。 - -<!-- One example is [Custom Hugo Shortcodes](/docs/contribute/style/hugo-shortcodes/). It is considered a `leaf bundle`. Everything below the directory, including the `index.md`, will be part of the bundle. This also includes page-relative links, images that can be processed etc.: --> +## 页面包 -一个例子是 [定制 Hugo 短代码](/docs/contribute/style/hugo-shortcodes/)。它被认为是 `leaf bundle`。目录下的所有内容，包括 `index.md`，都是包的一部分。这还包括页面相关的链接、可被处理的图像等： +除了独立的内容页面（Markdown 文件），Hugo 还支持 +[页面包](https://gohugo.io/content-management/page-bundles/)。 + +一个例子是[定制的 Hugo 短代码（shortcodes）](/zh/docs/contribute/style/hugo-shortcodes/)。 +它被认为是 `leaf bundle`（叶子包）。 +目录下的所有内容，包括 `index.md`，都是包的一部分。此外还包括页面间相对链接、可被处理的图像等： ```bash en/docs/home/contribute/includes @@ -210,8 +174,8 @@ en/docs/home/contribute/includes <!-- Another widely used example is the `includes` bundle. It sets `headless: true` in front matter, which means that it does not get its own URL. It is only used in other pages. --> - -另一个广泛使用的例子是 `includes` 包。它在页面头部设置 `headless: true`，这意味着它没有得到自己的 URL。它只用于其他页面。 +另一个广泛使用的例子是 `includes` 包。 +这类包在页面头部设置 `headless: true`，意味着它没有得到自己的 URL。它只用于其他页面。 ```bash en/includes @@ -228,44 +192,39 @@ en/includes <!-- Some important notes to the files in the bundles: ---> -包中文件的一些重要说明： - -<!-- * For translated bundles, any missing non-content files will be inherited from languages above. This avoids duplication. * All the files in a bundle are what Hugo calls `Resources` and you can provide metadata per language, such as parameters and title, even if it does not supports front matter (YAML files etc.). See [Page Resources Metadata](https://gohugo.io/content-management/page-resources/#page-resources-metadata). * The value you get from `.RelPermalink` of a `Resource` is page-relative. See [Permalinks](https://gohugo.io/content-management/urls/#permalinks). --> +有关包中文件的一些重要说明： -* 对于已翻译的包，任何丢失的非内容文件将从上面的语言继承。这避免了重复。 -* 包中的所有文件都是 Hugo 所指的 `Resources`，你可以为每种语言提供元数据，例如参数和标题，即使它不支持头部设置（YAML 文件等）。参见[页面资源元数据](https://gohugo.io/content-management/page-resources/#page-resources-metadata)。 -* 从 `Resource` 的 `.RelPermalink` 中获得的值是页面相关的。参见 [Permalinks](https://gohugo.io/content-management/urls/#permalinks)。 - +* 已翻译的包会从上面的语言继承所有缺失的、非内容文件。这一设计可以避免重复。 +* 包中的所有文件都是 Hugo 所指的 `Resources`，你可以为用不同语言为其提供元数据， + 例如参数和标题，即使它不支持头部设置（YAML 文件等）。 + 参见[页面资源元数据](https://gohugo.io/content-management/page-resources/#page-resources-metadata)。 +* 从 `Resource` 的 `.RelPermalink` 中获得的值是相对于当前页面的。 + 参见 [Permalinks](https://gohugo.io/content-management/urls/#permalinks)。 <!-- ## Styles ---> -## 样式 - -<!-- The `SASS` source of the stylesheets for this site is stored below `src/sass` and can be built with `make sass` (note that Hugo will get `SASS` support soon, see https://github.com/gohugoio/hugo/issues/4243). --> +## 样式 {#styles} -本网站的样式表的 `SASS` 源存储在 `src/sass` 下面，可以用 `make sass` 构建（Hugo很快就会得到 `SASS` 的支持，参见https://github.com/gohugoio/hugo/issues/4243）。 - - +网站的样式表的 `SASS` 源文件存储在 `src/sass` 下面，可以用 `make sass` 构建 +（Hugo 很快就提供 `SASS` 的支持，参见 https://github.com/gohugoio/hugo/issues/4243）。 ## {{% heading "whatsnext" %}} - <!-- -* [Custom Hugo shortcodes](/docs/contribute/style/hugo-shortcodes/) -* [Style guide](/docs/contribute/style/style-guide) +* Learn about [custom Hugo shortcodes](/docs/contribute/style/hugo-shortcodes/) +* Learn about the [Style guide](/docs/contribute/style/style-guide) +* Learn about the [Content guide](/docs/contribute/style/content-guide) --> -* [定制 Hugo 短代码](/docs/contribute/style/hugo-shortcodes/) -* [样式指南](/docs/contribute/style/style-guide) - +* 了解[定制 Hugo 短代码](/zh/docs/contribute/style/hugo-shortcodes/) +* 了解[样式指南](/zh/docs/contribute/style/style-guide) +* 了解[内容指南](/zh/docs/contribute/style/content-guide) diff --git a/content/zh/docs/contribute/style/hugo-shortcodes/example1.md b/content/zh/docs/contribute/style/hugo-shortcodes/example1.md index 0656ce4883..9359bf1c16 100644 --- a/content/zh/docs/contribute/style/hugo-shortcodes/example1.md +++ b/content/zh/docs/contribute/style/hugo-shortcodes/example1.md @@ -3,21 +3,18 @@ title: 例子 #1 --- <!-- ---- title: Example #1 ---- --> <!-- This is an **example** content file inside the **includes** leaf bundle. --> - 这是一个内容文件**示例**，位于一个**includes**叶子包中。 -{{< note >}} <!-- Included content files can also contain shortcodes. --> +{{< note >}} +被包含的内容文件也可以包含短代码。 +{{< /note >}} -包含的内容文件也可以包含短代码。 -{{< /note >}} \ No newline at end of file diff --git a/content/zh/docs/contribute/style/hugo-shortcodes/example2.md b/content/zh/docs/contribute/style/hugo-shortcodes/example2.md index 356983f3c0..5648fdc199 100644 --- a/content/zh/docs/contribute/style/hugo-shortcodes/example2.md +++ b/content/zh/docs/contribute/style/hugo-shortcodes/example2.md @@ -1,17 +1,12 @@ --- title: 例子 #1 --- - <!-- ---- title: Example #1 ---- --> <!-- This is another **example** content file inside the **includes** leaf bundle. --> - 这是另一个内容文件**示例**，位于一个**includes**叶子包中。 - diff --git a/content/zh/docs/contribute/style/hugo-shortcodes/index.md b/content/zh/docs/contribute/style/hugo-shortcodes/index.md index 8f9a3a260b..dc3400c611 100644 --- a/content/zh/docs/contribute/style/hugo-shortcodes/index.md +++ b/content/zh/docs/contribute/style/hugo-shortcodes/index.md @@ -1,37 +1,41 @@ --- -approvers: -- chenopis title: 定制 Hugo 短代码 content_type: concept --- - -<!-- --- -approvers: -- chenopis +<!-- title: Custom Hugo Shortcodes content_type: concept ---- --> +--> <!-- overview --> + <!-- This page explains the custom Hugo shortcodes that can be used in Kubernetes markdown documentation. --> 本页面将介绍定制 Hugo 短代码，可以用于 Kubernetes markdown 文档书写。 <!-- Read more about shortcodes in the [Hugo documentation](https://gohugo.io/content-management/shortcodes). --> -更多关于短代码参见 [Hugo 文档](https://gohugo.io/content-management/shortcodes)。 - +关于短代码的更多信息可参见 [Hugo 文档](https://gohugo.io/content-management/shortcodes)。 <!-- body --> -<!-- ## Feature state --> + +<!-- +## Feature state + +In a markdown page (.md file) on this site, you can add a shortcode to display +version and state of the documented feature. +--> ## 功能状态 -<!-- In a markdown page (.md file) on this site, you can add a shortcode to display version and state of the documented feature. --> -本站上面的 markdown 页面，你可以加入短代码来展示已经文档介绍的功能的版本和状态(state)。 +在本站的 markdown 页面中，你可以加入短代码来展示所描述的功能特性的版本和状态。 -<!-- ### Feature state demo --> -### 功能状态演示 +<!-- +### Feature state demo -<!-- Below is a demo of the feature state snippet, which displays the feature as stable in Kubernetes version 1.10. --> -下面是一个功能状态代码段的演示，表明这个功能已经在 Kubernetes v1.10时就已经稳定了。 +Below is a demo of the feature state snippet, which displays the feature as stable +in Kubernetes version 1.10. +--> +### 功能状态示例 + +下面是一个功能状态代码段的演示，表明这个功能已经在 Kubernetes v1.10 时就已经稳定了。 ``` {{</* feature-state for_k8s_version="v1.10" state="stable" */>}} @@ -43,32 +47,33 @@ content_type: concept {{< feature-state for_k8s_version="v1.10" state="stable" >}} <!-- The valid values for `state` are: --> -`state`的可选值如下： +`state` 的可选值如下： * alpha * beta * deprecated * stable -<!-- ### Feature state code --> +<!-- +### Feature state code + +The displayed Kubernetes version defaults to that of the page or the site. +This can be changed by passing the <code>for_k8s_version</code> shortcode +parameter. +--> ### 功能状态代码 -<!-- Below is the template code for each available feature state. --> -下面是为每个现有的功能状态的模板代码。 - -<!-- The displayed Kubernetes version defaults to that of the page or the site. This can be changed by passing the <code>for_k8s_version</code> shortcode parameter. --> - -显示的 Kubernetes 默认为该页或站点版本。 -这个可以通过修改 <code>for_k8s_version</code> 短代码参数来调整。 +所显示的 Kubernetes 默认为该页或站点版本。 +可以通过修改 <code>for_k8s_version</code> 短代码参数来调整要显示的版本。 ``` -{{</* feature-state for_k8s_version="v1.10" state="stable" */>}} +{{</* feature-state for_k8s_version="v1.11" state="stable" */>}} ``` <!-- Renders to: --> 会转换为： -{{< feature-state for_k8s_version="v1.10" state="stable" >}} +{{< feature-state for_k8s_version="v1.11" state="stable" >}} <!-- #### Alpha feature --> #### Alpha 功能 @@ -82,7 +87,6 @@ content_type: concept {{< feature-state state="alpha" >}} - <!-- #### Beta feature --> #### Beta 功能 @@ -119,63 +123,165 @@ content_type: concept {{< feature-state state="deprecated" >}} -<!-- ## Glossary --> +<!-- +## Glossary + +You can reference glossary terms with an inclusion that will automatically +update and replace content with the relevant links from [our +glossary](/docs/reference/glossary/). When the term is moused-over by someone +using the online documentation, the glossary entry will display a tooltip. +--> ## 词汇 -<!-- You can reference glossary terms with an inclusion that will automatically update and replace content with the relevant links from [our glossary](/docs/reference/glossary/). When the term is moused-over by someone -using the online documentation, the glossary entry will display a tooltip. --> - -你可以通过加入术语词汇的短代码，来自动更新和替换相应链接中的内容（[我们的词汇库](/docs/reference/glossary/)） +你可以通过加入术语词汇的短代码，来自动更新和替换相应链接中的内容 +（[我们的词汇库](/zh/docs/reference/glossary/)） 这样，在浏览在线文档，鼠标移到术语上时，术语解释就会显示在提示框中。 -<!-- The raw data for glossary terms is stored at [https://github.com/kubernetes/website/tree/master/content/en/docs/reference/glossary](https://github.com/kubernetes/website/tree/master/content/en/docs/reference/glossary), with a content file for each glossary term. --> +<!-- +The raw data for glossary terms is stored at [https://github.com/kubernetes/website/tree/master/content/en/docs/reference/glossary](https://github.com/kubernetes/website/tree/master/content/en/docs/reference/glossary), with a content file for each glossary term. +--> 词汇术语的原始数据保存在 [https://github.com/kubernetes/website/tree/master/content/en/docs/reference/glossary](https://github.com/kubernetes/website/tree/master/content/en/docs/reference/glossary)，每个内容文件对应相应的术语解释。 -<!-- ### Glossary Demo --> +<!-- +### Glossary Demo + +For example, the following include within the markdown will render to +{{< glossary_tooltip text="cluster" term_id="cluster" >}} with a tooltip: +--> ### 词汇演示 -<!-- For example, the following include within the markdown will render to {{< glossary_tooltip text="cluster" term_id="cluster" >}} with a tooltip: --> +例如，下面的代码在 markdown 中将会转换为 `{{< glossary_tooltip text="cluster" term_id="cluster" >}}`， +然后在提示框中显示。 -例如，下面的代码在 markdown 中将会转换为 `{{< glossary_tooltip text="cluster" term_id="cluster" >}}`，然后在提示框中显示。 - -````liquid +```liquid {{</* glossary_tooltip text="cluster" term_id="cluster" */>}} -```` +``` -<!-- ## Tabs --> -## 标签页 +<!-- +## Table captions -<!-- In a markdown page (`.md` file) on this site, you can add a tab set to display multiple flavors of a given solution. --> -在本站的 markdown 页面（`.md` 文件）中，你可以加入一个标签页集来显示不同形式的解决方案。 - -<!-- The `tabs` shortcode takes these parameters: --> -标签页的短代码包含以下参数： - -<!-- * `name`: The name as shown on the tab. -* `codelang`: If you provide inner content to the `tab` shortcode, you can tell Hugo what code language to use for highlighting. -* `include`: The file to include in the tab. If the tab lives in a Hugo [leaf bundle](https://gohugo.io/content-management/page-bundles/#leaf-bundles), the file -- which can be any MIME type supported by Hugo -- will be looked up in the bundle itself. If not, the content page to include will be looked up relative to the current. Note that with the `include` you will not have any shortcode inner content and must use the self-closing syntax, e.g. {{</* tab name="Content File #1" include="example1" /*/>}}. Non-content files will be code-highlighted. The language to use will be taken from the filename if not provided in `codelang`. --> - -* `name`: 标签页上的名字。 -* `codelang`: 如果要在`tab`短代码中加入内部内容，需要告知 Hugo 使用的是什么代码语言，方便代码高亮。 -* `include`: 标签页中所要包含的文件。如果标签页是在 Hugo 的页面包（[leaf bundle](https://gohugo.io/content-management/page-bundles/#leaf-bundles)）中，文件（可以是 Hugo 所支持的 MIME 类型文件）将会在包中查找。如果不是，所要包含的内容页面将会在当前路径的相关路径下查找。注意，在`include`属性部分，不能加入短代码内部内容，必须要使用自结束（self-closing）的语法。 -非内容文件将会被代码高亮。如果没有在`codelang`进行声明的话，所用的代码语言将会来自文件名。 - -<!-- * If your inner content is markdown, you must use `%`-delimiter to surorund the tab, e.g. `{{%/* tab name="Tab 1" %}}This is **markdown**{{% /tab */%}}` -* You can combine the variations mentioned above inside a tab set. --> - -* 如果内部内容是 markdown， 你必须要使用 `%` 分隔符来包装标签页，例如，`{{%/* tab name="Tab 1" %}}This is **markdown**{{% /tab */%}}` -* 可以在标签页集中混合使用上面的各种变形。 - -<!-- Below is a demo of the tabs shortcode. --> -下面是演示标签页短代码。 +You can make tables more accessible to screen readers by adding a table caption. To add a [caption](https://www.w3schools.com/tags/tag_caption.asp) to a table, enclose the table with a `table` shortcode and specify the caption with the `caption` parameter. {{< note >}} -The tab **name** in a `tabs` definition must be unique within a content page. -一个内容页面下的，标签页定义中的标签页 **名** 必须是唯一的。 +Table captions are visible to screen readers but invisible when viewed in standard HTML. {{< /note >}} -<!-- ### Tabs demo: Code highlighting --> +Here's an example: +--> +## 表格标题 {#table-captions} + +通过添加表格标题，你可以让表格能够被屏幕阅读器读取。 +要向表格添加[标题（Caption）](https://www.w3schools.com/tags/tag_caption.asp)， +可用 `table` 短代码包围表格定义，并使用 `caption` 参数给出表格标题。 + +{{< note >}} +表格标题对屏幕阅读器是可见的，但在标准 HTML 中查看时是不可见的。 +{{< /note >}} + +下面是一个例子： + +<!-- + +```go-html-template +{{</* table caption="Configuration parameters" >}} +Parameter | Description | Default +`timeout` | The timeout for requests | `30s` +`logLevel` | The log level for log output | `INFO` +{{< /table */>}} + +The rendered table looks like this: + +{{< table caption="Configuration parameters" >}} +Parameter | Description | Default +`timeout` | The timeout for requests | `30s` +`logLevel` | The log level for log output | `INFO` +{{< /table >}} +--> + +```go-html-template +{{</* table caption="配置参数" >}} +参数 | 描述 | 默认值 +:---------|:------------|:------- +`timeout` | 请求的超时时长 | `30s` +`logLevel` | 日志输出的级别 | `INFO` +{{< /table */>}} +``` + +所渲染的表格如下： + +{{< table caption="配置参数" >}} +参数 | 描述 | 默认值 +:---------|:------------|:------- +`timeout` | 请求的超时时长 | `30s` +`logLevel` | 日志输出的级别 | `INFO` +{{< /table >}} + +<!-- +If you inspect the HTML for the table, you should see this element immediately after the opening `<table>` element: + +```html +<caption style="display: none;">Configuration parameters</caption> +``` +--> +如果你查看表格的 HTML 输出结果，你会看到 `<table>` 元素 +后面紧接着下面的元素： + +```html +<caption style="display: none;">配置参数</caption> +``` + +<!-- +## Tabs + +In a markdown page (`.md` file) on this site, you can add a tab set to display +multiple flavors of a given solution. + +The `tabs` shortcode takes these parameters: +--> +## 标签页 + +在本站的 markdown 页面（`.md` 文件）中，你可以加入一个标签页集来显示 +某解决方案的不同形式。 + +标签页的短代码包含以下参数： + +<!-- +* `name`: The name as shown on the tab. +* `codelang`: If you provide inner content to the `tab` shortcode, you can tell Hugo what code language to use for highlighting. +* `include`: The file to include in the tab. If the tab lives in a Hugo [leaf bundle](https://gohugo.io/content-management/page-bundles/#leaf-bundles), the file -- which can be any MIME type supported by Hugo -- will be looked up in the bundle itself. If not, the content page to include will be looked up relative to the current. Note that with the `include` you will not have any shortcode inner content and must use the self-closing syntax, e.g. {{</* tab name="Content File #1" include="example1" /*/>}}. Non-content files will be code-highlighted. The language to use will be taken from the filename if not provided in `codelang`. +--> +* `name`： 标签页上显示的名字。 +* `codelang`: 如果要在 `tab` 短代码中加入内部内容，需要告知 Hugo 使用的是什么代码语言，方便代码高亮。 +* `include`: 标签页中所要包含的文件。如果标签页是在 Hugo 的 + [叶子包](https://gohugo.io/content-management/page-bundles/#leaf-bundles)中定义， + Hugo 会在包内查找文件（可以是 Hugo 所支持的任何 MIME 类型文件）。 + 否则，Hugo 会在当前路径的相对路径下查找所要包含的内容页面。 + 注意，在 `include` 页面中不能包含短代码内容，必须要使用自结束（self-closing）语法。 + 非内容文件将会被代码高亮。 + 如果没有在 `codelang` 进行声明的话，Hugo 会根据文件名推测所用的语言。 +<!-- +* If your inner content is markdown, you must use `%`-delimiter to surorund the tab, e.g. `{{%/* tab name="Tab 1" %}}This is **markdown**{{% /tab */%}}` +* You can combine the variations mentioned above inside a tab set. +--> +* 如果内部内容是 Markdown，你必须要使用 `%` 分隔符来包装标签页。 + 例如，`{{%/* tab name="Tab 1" %}}This is **markdown**{{% /tab */%}}`。 +* 可以在标签页集中混合使用上面的各种变形。 + +<!-- +Below is a demo of the tabs shortcode. + +The tab **name** in a `tabs` definition must be unique within a content page. +--> +下面是标签页短代码的示例。 + +{{< note >}} +内容页面下的 **tabs** 定义中的标签页 **name** 必须是唯一的。 +{{< /note >}} + +<!-- +### Tabs demo: Code highlighting +--> ### 标签页演示：代码高亮 ```go-text-template @@ -252,23 +358,22 @@ println "This is tab 2." {{< tabs name="tab_with_file_include" >}} {{< tab name="Content File #1" include="example1" />}} {{< tab name="Content File #2" include="example2" />}} -{{< tab name="JSON File" include="podtemplate" />}} +{{< tab name="JSON File" include="podtemplate.json" />}} {{< /tabs >}} - - - ## {{% heading "whatsnext" %}} -<!-- * Learn about [Hugo](https://gohugo.io/). -* Learn about [writing a new topic](/docs/home/contribute/write-new-topic/). -* Learn about [using page templates](/docs/home/contribute/page-templates/). -* Learn about [staging your changes](/docs/home/contribute/stage-documentation-changes/) -* Learn about [creating a pull request](/docs/home/contribute/create-pull-request/). --> +<!-- +* Learn about [Hugo](https://gohugo.io/). +* Learn about [writing a new topic](/docs/home/contribute/style/write-new-topic/). +* Learn about [page content types](/docs/home/contribute/style/page-content-types/). +* Learn about [creating a pull request](/docs/contribute/new-content/open-a-pr/). +* Learn about [advanced contributing](/docs/contribute/advanced/). +--> * 了解 [Hugo](https://gohugo.io/)。 -* 了解 [撰写新的话题](/docs/home/contribute/write-new-topic/)。 -* 了解 [使用页面模板](/docs/home/contribute/page-templates/)。 -* 了解 [暂存修改](/docs/home/contribute/stage-documentation-changes/)。 -* 了解 [创建 pull request](/docs/home/contribute/create-pull-request/)。 +* 了解[撰写新的话题](/zh/docs/contribute/style/write-new-topic/)。 +* 了解[使用页面内容类型](/zh/docs/contribute/style/page-content-types/)。 +* 了解[发起 PR](/zh/docs/contribute/new-content/open-a-pr/)。 +* 了解[高级贡献](/zh/docs/contribute/advanced/)。 diff --git a/content/zh/docs/contribute/style/page-content-types.md b/content/zh/docs/contribute/style/page-content-types.md new file mode 100644 index 0000000000..a5526383f5 --- /dev/null +++ b/content/zh/docs/contribute/style/page-content-types.md @@ -0,0 +1,412 @@ +--- +title: 页面内容类型 +content_type: concept +weight: 30 +card: + name: 贡献 + weight: 30 +--- +<!-- +title: Page content types +content_type: concept +weight: 30 +card: + name: contribute + weight: 30 +--> + +<!-- overview --> + +<!-- +The Kubernetes documentation follows several types of page content: + +- Concept +- Task +- Tutorial +- Reference +--> +Kubernetes 文档包含以下几种页面内容类型： + +- 概念（Concept） +- 任务（Task） +- 教程（Tutorial） +- 参考（Reference） + +<!-- body --> + +<!-- +## Content sections + +Each page content type contains a number of sections defined by +Markdown comments and HTML headings. You can add content headings to +your page with the `heading` shortcode. The comments and headings help +maintain the structure of the page content types. + +Examples of Markdown comments defining page content sections: +--> +## 内容章节 {#content-sections} + +每种页面内容类型都有一些使用 Markdown 注释和 HTML 标题定义的章节。 +你可以使用 `heading` 短代码将内容标题添加到你的页面中。 +注释和标题有助于维护对应页面内容类型的结构组织。 + +定义页面内容章节的 Markdown 注释示例： + +```markdown +<!-- overview --> +``` + +```markdown +<!-- body --> +``` + +<!-- +To create common headings in your content pages, use the `heading` shortcode with +a heading string. + +Examples of heading strings: + +- whatsnext +- prerequisites +- objectives +- cleanup +- synopsis +- seealso +- options + +For example, to create a `whatsnext` heading, add the heading shortcode with the "whatsnext" string: +--> +要在内容页面中创建通用的标题，可以使用 `heading` 短代码加上标题字符串。 + +标题字符串示例： + +- whatsnext +- prerequisites +- objectives +- cleanup +- synopsis +- seealso +- options + +例如，要创建一个 `whatsnext` 标题，添加 heading 短代码并指定 "whatsnext" 字符串： + +```none +## {{%/* heading "whatsnext" */%}} +``` + +<!-- +You can declare a `prerequisites` heading as follows: +--> +你可以像下面这样声明一个 `prerequisites` 标题： + +```none +## {{%/* heading "prerequisites" */%}} +``` + +<!-- +The `heading` shortcode expects one string parameter. +The heading string parameter matches the prefix of a variable in the `i18n/<lang>.toml` files. +For example: +--> +短代码 `heading` 需要一个字符串参数。 +该字符串参数要与 `i18n/<语言>.toml` 文件中以其为前缀的某个变量匹配。 +例如： + +`i18n/en.toml`: + +```toml +[whatsnext_heading] +other = "What's next" +``` + +`i18n/ko.toml`: + +```toml +[whatsnext_heading] +other = "다음 내용" +``` + +<!-- +## Content types + +Each content type informally defines its expected page structure. +Create page content with the suggested page sections. +--> +## 内容类型 {#content-types} + +每种内容类型都非正式地定义了期望的页面结构组织。 +请按照所建议的页面章节来创建内容页面。 + +<!-- +### Concept + +A concept page explains some aspect of Kubernetes. For example, a concept +page might describe the Kubernetes Deployment object and explain the role it +plays as an application once it is deployed, scaled, and updated. Typically, concept +pages don't include sequences of steps, but instead provide links to tasks or +tutorials. + +To write a new concept page, create a Markdown file in a subdirectory of the +`/content/en/docs/concepts` directory, with the following characteristics: + +Concept pages are divided into three sections: + +| Page section | +|----------------| +| overview | +| body | +| whatsnext | +--> +### 概念 {#concept} + +概念页面用来解释 Kubernetes 的某些方面。例如，概念页面可以用来描述 Kubernetes +中的 Deployment 对象，解释其作为应用的角色如何部署、扩缩和更新。 +通常，概念页面不需要包含步骤序列，但包含指向任务或教程的链接。 + +要编写一个新的概念页面，在 `/content/en/docs/concepts` 目录下面的子目录中新建 +一个 Markdown 文件。该文件具有以下特点。 + +概念页面分为三个章节： + +| 页面章节 | +|--------------------| +| overview （概述） | +| body (主体） | +| whatsnext (接下来）| + +<!-- +The `overview` and `body` sections appear as comments in the concept page. +You can add the `whatsnext` section to your page with the `heading` shortcode. + +Fill each section with content. Follow these guidelines: + +- Organize content with H2 and H3 headings. +- For `overview`, set the topic's context with a single paragraph. +- For `body`, explain the concept. +- For `whatsnext`, provide a bulleted list of topics (5 maximum) to learn more about the concept. + +[Annotations](/docs/concepts/overview/working-with-objects/annotations/) is a +published example of a concept page. +--> +其中的 `overview` 和 `body` 章节在概念页面中显示为注释。 +你可以使用 `heading` 短代码向页面添加 `wahtsnext` 节。 + +在为每个章节撰写内容时，遵从一些规定： + +- 使用二级和三级标题（H2、H3）来组织内容 +- 在 `overview` 节中，使用一段文字来为主体部分铺陈上下文； +- 在 `body` 节中，详细解释对应概念； +- 对于 `whatsnext` 节，提供一个项目符号列表（最多 5 个），帮助读者进一步学习掌握概念 + +[注解](/zh/docs/concepts/overview/working-with-objects/annotations/)页面是一个已经 +上线的概念页面的例子。 + +<!-- +### Task + +A task page shows how to do a single thing, typically by giving a short +sequence of steps. Task pages have minimal explanation, but often provide links +to conceptual topics that provide related background and knowledge. + +To write a new task page, create a Markdown file in a subdirectory of the +`/content/en/docs/tasks` directory, with the following characteristics: + +| Page section | +|----------------| +| overview | +| prerequisites | +| steps | +| discussion | +| whatsnext | +--> +### 任务（Task） {#task} + +任务页面讲解如何完成某项工作，通常包含由为数不多的几个步骤组成的序列。 +任务页面的讲解文字很少，不过通常会包含指向概念主题的链接，以便读者 +能够了解相关的背景和知识。 + +编写新的任务页面时，在 `/content/en/docs/tasks` 目录下的子目录中创建一个 +新的 Markdown 文件。该文件特点如下。 + +| 页面章节 | +|---------------------------| +| overview （概述） | +| prerequisites （准备工作）| +| steps （步骤） | +| discussion （讨论） | +| whatsnext （接下来） | + +<!-- +The `overview`, `steps`, and `discussion` sections appear as comments in the task page. +You can add the `prerequisites` and `whatsnext` sections to your page +with the `heading` shortcode. + +Within each section, write your content. Use the following guidelines: + +- Use a minimum of H2 headings (with two leading `#` characters). The sections + themselves are titled automatically by the template. +- For `overview`, use a paragraph to set context for the entire topic. +- For `prerequisites`, use bullet lists when possible. Start adding additional + prerequisites below the `include`. The default prerequisites include a running Kubernetes cluster. +- For `steps`, use numbered lists. +- For discussion, use normal content to expand upon the information covered + in `steps`. +- For `whatsnext`, give a bullet list of up to 5 topics the reader might be + interested in reading next. + +An example of a published task topic is [Using an HTTP proxy to access the Kubernetes API](/docs/tasks/extend-kubernetes/http-proxy-access-api/). +--> +其中的 `overview`、`steps` 和 `discussion` 节在任务页面中显示为注释。 +你可以使用 `heading` 短代码添加 `prerequisites` 和 `whatsnext` 小节。 + +在每个小节内撰写内容时注意以下规定： + +- 最低使用二级标题（H2，标题行前带两个 `#` 字符）。每个小节都会由模版自动给出标题。 +- 在 `overview` 节中，用一个段落为整个任务主体设定语境； +- 在 `prerequisites` 节中，尽可能使用项目符号列表。 + 额外的环境准备条件要加在 `include` 短代码之后。 + 默认的环境准备条件是拥有一个在运行的 Kubernetes 集群。 +- 在 `steps` 节中，使用编号符号列表。 +- 在 `discussion` 节中，使用正常文字内容来对 `steps` 节中内容展开叙述。 +- 在 `whatsnext` 节中，使用项目符号列表（不超过 5 项），列举读者可能接下来有兴趣 + 阅读的主题。 + +已上线的任务主题示例之一是[使用 HTTP 代理来访问 Kubernetes API](/zh/docs/tasks/extend-kubernetes/http-proxy-access-api/)。 + +<!-- +### Tutorial + +A tutorial page shows how to accomplish a goal that is larger than a single +task. Typically a tutorial page has several sections, each of which has a +sequence of steps. For example, a tutorial might provide a walkthrough of a +code sample that illustrates a certain feature of Kubernetes. Tutorials can +include surface-level explanations, but should link to related concept topics +for deep explanations. + +To write a new tutorial page, create a Markdown file in a subdirectory of the +`/content/en/docs/tutorials` directory, with the following characteristics: + +| Page section | +|----------------| +| overview | +| prerequisites | +| objectives | +| lessoncontent | +| cleanup | +| whatsnext | +--> +### 教程（Tutorial） {#tutorial} + +教程页面描述如果完成一个比单一任务规模更大的目标。通常教程页面会有多个小节， +每个小节由一系列步骤组成。例如，每个教程可能提供对代码示例的讲解，便于用户 +了解 Kubernetes 的某个功能特性。教程可以包含表面层面的概念解释，对于更深层面 +的概念主题应该使用链接。 + +撰写新的教程页面时，在 `/content/en/docs/tutorials` 目录下面的子目录中创建新的 +Markdown 文件。该文件有以下特点。 + +| 页面节区 | +|---------------------------| +| overview （概述） | +| prerequisites （环境准备）| +| objectives （目标） | +| lessoncontent （教程内容）| +| cleanup （清理工作） | +| whatsnext （接下来） | + +<!-- +The `overview`, `objectives`, and `lessoncontent` sections appear as comments in the tutorial page. +You can add the `prerequisites`, `cleanup`, and `whatsnext` sections to your page +with the `heading` shortcode. + +Within each section, write your content. Use the following guidelines: + +- Use a minimum of H2 headings (with two leading `#` characters). The sections + themselves are titled automatically by the template. +- For `overview`, use a paragraph to set context for the entire topic. +- For `prerequisites`, use bullet lists when possible. Add additional + prerequisites below the ones included by default. +- For `objectives`, use bullet lists. +- For `lessoncontent`, use a mix of numbered lists and narrative content as + appropriate. +- For `cleanup`, use numbered lists to describe the steps to clean up the + state of the cluster after finishing the task. +- For `whatsnext`, give a bullet list of up to 5 topics the reader might be + interested in reading next. + +An example of a published tutorial topic is +[Running a Stateless Application Using a Deployment](/docs/tutorials/stateless-application/run-stateless-application-deployment/). +--> +教程页面的 `overview`、`objectives` 和 `lessoncontent` 小节显示为注释形式。 +你可以使用 `heading` 短代码根据需要添加 `prerequisites`、`cleanup` 和 +`whatsnext` 小节。 + +在每个小节中编写内容时，请注意以下规定： + +- 最低使用二级标题（H2，标题前面有两个 `#` 字符）。模版会自动为每个小节设置标题。 +- 在 `overview` 节中，用一个段落为整个主题设定语境； +- 在 `prerequisites` 节中，尽可能使用项目符号列表。 + 额外的环境准备条件要加在已包含的条件之后。 +- 在 `objectives` 节中，使用项目符号列表。 +- 在 `lessoncontent` 节中，结合使用编号符号列表和叙述性文字。 +- 在 `cleanup` 节中，使用编号符号列表来描述任务结束后清理集群状态所需要的步骤。 +- 在 `whatsnext` 节中，使用项目符号列表（不超过 5 项），列举读者可能接下来有兴趣 + 阅读的主题。 + +已发布的教程主题的一个例子是 +[使用 Deployment 运行无状态应用](/zh/docs/tasks/run-application/run-stateless-application-deployment/). + +<!-- +### Reference + +A component tool reference page shows the description and flag options output for +a Kubernetes component tool. Each page generates from scripts using the component tool commands. + +A tool reference page has several possible sections: + +| Page section | +|--------------------------------| +| synopsis | +| options | +| options from parent commands | +| examples | +| seealso | + +Examples of published tool reference pages are: + +- [kubeadm init](/docs/reference/setup-tools/kubeadm/kubeadm-init/) +- [kube-apiserver](/docs/reference/command-line-tools-reference/kube-apiserver/) +- [kubectl](/docs/reference/kubectl/kubectl/) +--> +### 参考（Reference） {#reference} + +组件工具的参考页面给出的是某个 Kubernetes 组件工具的描述和参数选项输出。 +每个页面都是使用组件工具命令基于脚本生成的。 + +每个工具参考页面可能包含以下小节： + +| 页面小节 | +|-----------------| +| synopsis (用法）| +| options（选项） | +| options from parent commands (从父命令集成的选项） | +| examples （示例）| +| seealso （参考）| + +已发布的工具参考页面示例包括： + +- [kubeadm init](/zh/docs/reference/setup-tools/kubeadm/kubeadm-init/) +- [kube-apiserver](/zh/docs/reference/command-line-tools-reference/kube-apiserver/) +- [kubectl](/zh/docs/reference/kubectl/kubectl/) + +## {{% heading "whatsnext" %}} + +<!-- +- Learn about the [Style guide](/docs/contribute/style/style-guide/) +- Learn about the [Content guide](/docs/contribute/style/content-guide/) +- Learn about [content organization](/docs/contribute/style/content-organization/) +--> +- 了解[样式指南](/zh/docs/contribute/style/style-guide/) +- 了解[内容指南](/zh/docs/contribute/style/content-guide/) +- 了解[内容组织](/zh/docs/contribute/style/content-organization/) + diff --git a/content/zh/docs/contribute/style/page-templates.md b/content/zh/docs/contribute/style/page-templates.md deleted file mode 100644 index fc427417a8..0000000000 --- a/content/zh/docs/contribute/style/page-templates.md +++ /dev/null @@ -1,353 +0,0 @@ ---- -title: 使用页面模板 -content_type: concept -weight: 30 ---- - -<!-- ---- -title: Using Page Templates -content_type: concept -weight: 30 ---- ---> - -<!-- overview --> - -<!-- -When contributing new topics, apply one of the following templates to them. -This standardizes the user experience of a given page. ---> - -当贡献新主题时，选择下列模板中的一种。 -这使指定页面的用户体验标准化。 - -<!-- -The page templates are in the -[`layouts/partials/templates`](https://git.k8s.io/website/layouts/partials/templates) -directory of the [`kubernetes/website`](https://github.com/kubernetes/website) -repository. ---> - -页面模板在 [`kubernetes/website`](https://github.com/kubernetes/website) 仓库的 [`layouts/partials/templates`](https://git.k8s.io/website/layouts/partials/templates) 目录中。 - -{{< note >}} -<!-- -Every new topic needs to use a template. If you are unsure which -template to use for a new topic, start with the -[concept template](#concept-template). ---> - -每个新主题都需要使用模板。如果你不确定新主题要使用哪个模板，请从[概念模板](#概念模板)开始。 -{{< /note >}} - - - - - -<!-- body --> - -<!-- -## Concept template ---> - -## 概念模板 - -<!-- -A concept page explains some aspect of Kubernetes. For example, a concept -page might describe the Kubernetes Deployment object and explain the role it -plays as an application once it is deployed, scaled, and updated. Typically, concept -pages don't include sequences of steps, but instead provide links to tasks or -tutorials. ---> - -每个概念页面负责解释 Kubernetes 的某方面。例如，概念页面可以描述 Kubernetes Deployment 对象，并解释当部署、扩展和更新时，它作为应用程序所扮演的角色。一般来说，概念页面不包括步骤序列，而是提供任务或教程的链接。 - - -<!-- -To write a new concept page, create a Markdown file in a subdirectory of the -`/content/en/docs/concepts` directory, with the following characteristics: ---> - -要编写新的概念页面，请在 `/content/en/docs/concepts` 目录的子目录中创建一个 Markdown 文件，其特点如下： - -<!-- -- In the page's YAML front-matter, set `content_type: concept`. -- In the page's body, set the required `capture` variables and any optional - ones you want to include: ---> - -- 在页面的 YAML 头部，设置 `content_type: concept`。 -- 在页面的 body 中，设置所需的 `capture` 变量和所有想要包含的变量： - - | 变量 | 必需? | - |---------------|-----------| - | overview | 是 | - | body | 是 | - | whatsnext | 否 | - -<!-- - The page's body will look like this (remove any optional captures you don't - need): ---> - - 页面的 body 看起来像这样（移除所有不想要的可选 `capture` 变量）： - - ``` - {{%/* capture overview */%}} - - {{%/* /capture */%}} - - {{%/* capture body */%}} - - {{%/* /capture */%}} - - {{%/* capture whatsnext */%}} - - {{%/* /capture */%}} - ``` - -<!-- -- Within each section, write your content. Use the following guidelines: - - Use a minimum of H2 headings (with two leading `#` characters). The sections - themselves are titled automatically by the template. - - For `overview`, use a paragraph to set context for the entire topic. - - For `body`, explain the concept using free-form Markdown. - - For `whatsnext`, give a bullet list of up to 5 topics the reader might be - interested in reading next. ---> - -- 在每个章节中写下你的内容。请遵从以下规则： - - 使用不低于 H2 级别的标题（避免使用 H1 的标题，但 H3、H4 的标题是可以的）（以两个 `#` 字符开头）。这些章节本身是由模板自动命名的。 - - 在 `overview` 节，用一个段落的篇幅来为当前话题设定语境。 - - 在 `body` 节，使用自由形式的 Markdown 文件来解释概念。 - - 在 `whatsnext` 节，列出读者接下来可能感兴趣的最多 5 个主题。 - -<!-- -An example of a published topic that uses the concept template is -[Annotations](/docs/concepts/overview/working-with-objects/annotations/). The -page you are currently reading also uses the concept template. ---> - -使用概念模板的已发布主题的一个示例是[注解](/docs/concepts/overview/working-with-objects/annotations/)。你当前正在阅读的页面也使用概念模板。 - -<!-- -## Task template ---> - -## 任务模板 - -<!-- -A task page shows how to do a single thing, typically by giving a short -sequence of steps. Task pages have minimal explanation, but often provide links -to conceptual topics that provide related background and knowledge. ---> - -任务页面展示了如何完成单个任务，通常是通过给出一个简短的步骤序列。任务页面中解释性质的文字极少，但是通常会给出提供相关背景和知识的概念主题的链接。 - -<!-- -To write a new task page, create a Markdown file in a subdirectory of the -`/content/en/docs/tasks` directory, with the following characteristics: ---> - -要编写新的任务页面，请在 `/content/en/docs/tasks` 目录的子目录中创建一个 Markdown 文件，其特点如下： - -<!-- -- In the page's YAML front-matter, set `content_type: task`. -- In the page's body, set the required `capture` variables and any optional - ones you want to include: ---> - -- 在页面的 YAML 头部，设置 `content_type: task`。 -- 在页面的 body 中，设置所需的 `capture` 变量和所有想要包含的变量： - - | 变量 | 必需? | - |---------------|-----------| - | overview | 是 | - | prerequisites | 是 | - | steps | 否 | - | discussion | 否 | - | whatsnext | 否 | - -<!-- - The page's body will look like this (remove any optional captures you don't - need): ---> - - 页面的 body 看起来像这样（移除所有不想要的可选 `capture` 变量）： - - ``` - {{%/* capture overview */%}} - - {{%/* /capture */%}} - - {{%/* capture prerequisites */%}} - - {{</* include "task-tutorial-prereqs.md" */>}} {{</* version-check */>}} - - {{%/* /capture */%}} - - {{%/* capture steps */%}} - - {{%/* /capture */%}} - - {{%/* capture discussion */%}} - - {{%/* /capture */%}} - - {{%/* capture whatsnext */%}} - - {{%/* /capture */%}} - ``` - -<!-- -- Within each section, write your content. Use the following guidelines: - - Use a minimum of H2 headings (with two leading `#` characters). The sections - themselves are titled automatically by the template. - - For `overview`, use a paragraph to set context for the entire topic. - - For `prerequisites`, use bullet lists when possible. Start adding additional - prerequisites below the `include`. The default prerequisites include a running Kubernetes cluster. - - For `steps`, use numbered lists. - - For discussion, use normal content to expand upon the information covered - in `steps`. - - For `whatsnext`, give a bullet list of up to 5 topics the reader might be - interested in reading next. ---> - -- 在每个章节中写下你的内容。请遵从以下规则： - - 使用不低于 H2 级别的标题（避免使用 H1 的标题，但 H3、H4 的标题是可以的）（以两个 `#` 字符开头）。这些章节本身是由模板自动命名的。 - - 在 `overview` 节，用一个段落的篇幅来为当前话题设定语境。 - - 在 `prerequisites 节`，如果有可能，请使用列表。在 `include` 下开始添加额外的先决条件。默认的先决条件包括运行中的 Kubernetes 集群。 - - 在 `steps` 节，使用编号列表。 - - 在讨论部分，使用通常的内容来扩展 `steps` 中包含的信息。 - - 在 `whatsnext` 节，列出读者接下来可能感兴趣的最多 5 个主题。 - -<!-- -An example of a published topic that uses the task template is [Using an HTTP proxy to access the Kubernetes API](/docs/tasks/access-kubernetes-api/http-proxy-access-api). ---> - -使用任务模板的已发布主题的一个示例是[使用 HTTP 代理访问 Kubernetes API](/docs/tasks/access-kubernetes-api/http-proxy-access-api)。 - -<!-- -## Tutorial template ---> - -## 教程模板 - -<!-- -A tutorial page shows how to accomplish a goal that is larger than a single -task. Typically a tutorial page has several sections, each of which has a -sequence of steps. For example, a tutorial might provide a walkthrough of a -code sample that illustrates a certain feature of Kubernetes. Tutorials can -include surface-level explanations, but should link to related concept topics -for deep explanations. ---> - -教程页面展示了如何完成比单个任务更大的目标。通常教程页有几个章节，每个章节都有步骤说明。例如，教程可以提供说明 Kubernetes 的特定特性的代码示例的演练。教程可以包括表层解释，但是应该链接到相关的概念主题以进行深入解释。 - -<!-- -To write a new tutorial page, create a Markdown file in a subdirectory of the -`/content/en/docs/tutorials` directory, with the following characteristics: ---> - -要编写新的教程页面，请在 `/content/en/docs/tutorials` 目录的子目录中创建一个 Markdown 文件，其特点如下： - -<!-- -- In the page's YAML front-matter, set `content_type: tutorial`. -- In the page's body, set the required `capture` variables and any optional - ones you want to include: ---> - -- 在页面的 YAML 头部，设置 `content_type: tutorial`。 -- 在页面的 body 中，设置所需的 `capture` 变量和所有想要包含的变量： - - | 变量 | 必需? | - |---------------|-----------| - | overview | 是 | - | prerequisites | 是 | - | objectives | 是 | - | lessoncontent | 是 | - | cleanup | 否 | - | whatsnext | 否 | - -<!-- - The page's body will look like this (remove any optional captures you don't - need): ---> - - 页面的 body 看起来像这样（移除所有不想要的可选 `capture` 变量）： - - ``` - {{%/* capture overview */%}} - - {{%/* /capture */%}} - - {{%/* capture prerequisites */%}} - - {{</* include "task-tutorial-prereqs.md" */>}} {{</* version-check */>}} - - {{%/* /capture */%}} - - {{%/* capture objectives */%}} - - {{%/* /capture */%}} - - {{%/* capture lessoncontent */%}} - - {{%/* /capture */%}} - - {{%/* capture cleanup */%}} - - {{%/* /capture */%}} - - {{%/* capture whatsnext */%}} - - {{%/* /capture */%}} - ``` - -<!-- -- Within each section, write your content. Use the following guidelines: - - Use a minimum of H2 headings (with two leading `#` characters). The sections - themselves are titled automatically by the template. - - For `overview`, use a paragraph to set context for the entire topic. - - For `prerequisites`, use bullet lists when possible. Add additional - prerequisites below the ones included by default. - - For `objectives`, use bullet lists. - - For `lessoncontent`, use a mix of numbered lists and narrative content as - appropriate. - - For `cleanup`, use numbered lists to describe the steps to clean up the - state of the cluster after finishing the task. - - For `whatsnext`, give a bullet list of up to 5 topics the reader might be - interested in reading next. ---> - -- 在每个章节中写下你的内容。请遵从以下规则： - - 使用不低于 H2 级别的标题（避免使用 H1 的标题，但 H3、H4 的标题是可以的）（以两个 `#` 字符开头）。这些章节本身是由模板自动命名的。 - - 在 `overview` 节，用一个段落的篇幅来为当前话题设定语境。 - - 在 `prerequisites` 节，如果有可能，请使用列表。在默认情况下添加额外的先决条件。 - - 在 `objectives` 节，使用列表。 - - 在 `lessoncontent` 节，适当地使用编号列表和叙述内容的组合。 - - 在 `cleanup` 节，使用编号列表描述完成任务后清理集群状态的步骤。 - - 在 `whatsnext` 节，列出读者接下来可能感兴趣的最多 5 个主题。 - -<!-- -An example of a published topic that uses the tutorial template is -[Running a Stateless Application Using a Deployment](/docs/tutorials/stateless-application/run-stateless-application-deployment/). ---> - -使用教程模板的已发布主题的一个示例是[使用部署运行无状态应用程序](/docs/tutorials/stateless-application/run-stateless-application-deployment/)。 - - - -## {{% heading "whatsnext" %}} - - -<!-- -- Learn about the [style guide](/docs/contribute/style/style-guide/) -- Learn about [content organization](/docs/contribute/style/content-organization/) ---> - -- 学习[样式指南](/docs/contribute/style/style-guide/) -- 学习[内容组织](/docs/contribute/style/content-organization/) - - diff --git a/content/zh/docs/contribute/style/style-guide.md b/content/zh/docs/contribute/style/style-guide.md new file mode 100644 index 0000000000..777a0b6ca4 --- /dev/null +++ b/content/zh/docs/contribute/style/style-guide.md @@ -0,0 +1,1209 @@ +--- +title: 文档样式指南 +linktitle: 样式指南 +content_type: concept +weight: 10 +--- +<!-- +title: Documentation Style Guide +linktitle: Style guide +content_type: concept +weight: 10 +--> + +<!-- overview --> +<!-- +This page gives writing style guidelines for the Kubernetes documentation. +These are guidelines, not rules. Use your best judgment, and feel free to +propose changes to this document in a pull request. + +For additional information on creating new content for the Kubernetes +documentation, read the [Documentation Content Guide](/docs/contribute/style/content-guide/). + +Changes to the style guide are made by SIG Docs as a group. To propose a change +or addition, [add it to the agenda](https://docs.google.com/document/d/1ddHwLK3kUMX1wVFIwlksjTk0MsqitBnWPe1LRa1Rx5A/edit) for an upcoming SIG Docs meeting, and attend the meeting to participate in the +discussion. +--> +本页讨论 Kubernetes 文档的样式指南。 +这些仅仅是指南而不是规则。 +你可以自行决定，且欢迎使用 PR 来为此文档提供修改意见。 + +关于为 Kubernetes 文档贡献新内容的更多信息，可以参考 +[文档内容指南](/zh/docs/contribute/style/content-guide/)。 + +样式指南的变更是 SIG Docs 团队集体决定。 +如要提议更改或新增条目，请先将其添加到下一次 SIG Docs 例会的 +[议程表](https://docs.google.com/document/d/1ddHwLK3kUMX1wVFIwlksjTk0MsqitBnWPe1LRa1Rx5A/edit) +上，并按时参加会议讨论。 + +<!-- body --> +<!-- +Kubernetes documentation uses [Goldmark Markdown Renderer](https://github.com/yuin/goldmark) +with some adjustments along with a few +[Hugo Shortcodes](/docs/contribute/style/hugo-shortcodes/) to support glossary entries, tabs, +and representing feature state. +--> +{{< note >}} +Kubernetes 文档使用带调整的 [Goldmark Markdown 解释器](https://github.com/yuin/goldmark/) +和一些 [Hugo 短代码](/zh/docs/contribute/style/hugo-shortcodes/) 来支持词汇表项、Tab +页以及特性门控标注。 +{{< /note >}} + +<!-- +## Language + +Kubernetes documentation has been translated into multiple languages +(see [Localization READMEs](https://github.com/kubernetes/website/blob/master/README.md#localization-readmemds)). + +The way of localizing the docs for a different language is described in [Localizing Kubernetes Documentation](/docs/contribute/localization/). + +The English-language documentation uses U.S. English spelling and grammar. + +{{< comment >}}[If you're localizing this page, you can omit the point about US English.]{{< /comment >}} +--> +## 语言 {#language} + +Kubernetes 文档已经被翻译为多个语种 +（参见 [本地化 READMEs](https://github.com/kubernetes/website/blob/master/README.md#localization-readmemds)）。 + +为文档提供一种新的语言翻译的途径可以在 +[本地化 Kubernetes 文档](/zh/docs/contribute/localization/)中找到。 + +英语文档使用美国英语的拼写和语法。 + +{{< comment >}}[如果你在翻译本页面，你可以忽略关于美国英语的这一条。]{{< /comment >}} + +<!-- +## Documentation formatting standards + +### Use camel case for API objects + +When you refer to an API object, use the same uppercase and lowercase letters +that are used in the actual object name. Typically, the names of API +objects use +[camel case](https://en.wikipedia.org/wiki/Camel_case). + +Don't split the API object name into separate words. For example, use +PodTemplateList, not Pod Template List. + +Refer to API objects without saying "object," unless omitting "object" +leads to an awkward construction. +--> +## 文档格式标准 {#documentation-formatting-standards} + +### 对 API 对象使用驼峰式命名法 {#use-camel-case-for-api-objects} + +当指代 API 对象时，请使用与实际对象名称中一样的大写和小写字母。 +通常 API 对象使用[驼峰式命名](https://en.wikipedia.org/wiki/Camel_case). + +不要将 API 对象的名称切分成多个单词。例如，使用 PodTemplateList，不要 +使用 Pod Template List。 + +引用 API 对象时不必强调 “object（对象）”，除非省略“object（object）” +会使得文字读起来很别扭。 + +<!-- +{{< table caption = "Do and Don't - API objects" >}} +Do | Don't +:--| :----- +The Pod has two containers. | The pod has two containers. +The Deployment is responsible for ... | The Deployment object is responsible for ... +A PodList is a list of Pods. | A Pod List is a list of pods. +The two ContainerPorts ... | The two ContainerPort objects ... +The two ContainerStateTerminated objects ... | The two ContainerStateTerminateds ... +{{< /table >}} +--> +{{< table caption = "关于 API 对象的约定" >}} +可以 | 不可以 +:--| :----- +Pod 有两个容器 | pod 中有两个容器 +此 Deployment 负责... | 此 Deployment 对象负责 ... +PodList 是 Pod 的列表 | Pod List 是 pods 的列表 +这两个 ContainerPorts ... | 这两个 ContainerPort 对象 ... +这两个 ContainerStateTerminated 对象 ... | 这两个 ContainerStateTerminateds ... +{{< /table >}} + +<!-- +### Use angle brackets for placeholders + +Use angle brackets for placeholders. Tell the reader what a placeholder +represents. + +1. Display information about a Pod: + + kubectl describe pod <pod-name> -n <namespace> + + If the namespace of the pod is `default`, you can omit the '-n' parameter. +--> +### 在占位符中使用尖括号 + +在占位符中使用尖括号，并让读者知道其中代表的事物。例如： + +1. 显示 Pod 信息： + + kubectl describe pod <pod-名称> -n <名字空间> + + 如果名字空间被忽略，默认为 `default`，你可以忽略 '-n' 参数。 + + +<!-- +### Use bold for user interface elements + +{{< table caption = "粗体界面元素约定" >}} +Do | Don't +:--| :----- +Click **Fork**. | Click "Fork". +Select **Other**. | Select "Other". +{{< /table >}} +--> +### 用粗体字表现用户界面元素 + +{{< table caption = "粗体界面元素约定" >}} +可以 | 不可以 +:--| :----- +点击 **Fork**. | 点击 "Fork". +选择 **Other**. | 选择 "Other". +{{< /table >}} + +<!-- +### Use italics to define or introduce new terms + +{{< table caption = "Do and Don't - Use italics for new terms" >}} +Do | Don't +:--| :----- +A _cluster_ is a set of nodes ... | A "cluster" is a set of nodes ... +These components form the _control plane_. | These components form the **control plane**. +{{< /table >}} +--> +### 定义或引入新术语时使用斜体 + +{{< table caption = "新术语约定" >}} +可以 | 不可以 +:--| :----- +每个 _集群_ 是一组节点 ... | 每个“集群”是一组节点 ... +这些组件构成了 _控制面_. | 这些组件构成了 **控制面**. +{{< /table >}} + +<!-- +### Use code style for filenames, directories, and paths + +{{< table caption = "Do and Don't - Use code style for filenames, directories, and paths" >}} +Do | Don't +:--| :----- +Open the `envars.yaml` file. | Open the envars.yaml file. +Go to the `/docs/tutorials` directory. | Go to the /docs/tutorials directory. +Open the `/_data/concepts.yaml` file. | Open the /\_data/concepts.yaml file. +{{< /table >}} +--> +### 使用代码样式表现文件名、目录和路径 + +{{< table caption = "文件名、目录和路径约定" >}} +可以 | 不可以 +:--| :----- +打开 `envars.yaml` 文件 | 打开 envars.yaml 文件 +进入到 `/docs/tutorials` 目录 | 进入到 /docs/tutorials 目录 +打开 `/_data/concepts.yaml` 文件 | 打开 /\_data/concepts.yaml 文件 +{{< /table >}} + +<!-- +### Use the international standard for punctuation inside quotes + +{{< table caption = "Do and Don't - Use the international standard for punctuation inside quotes" >}} +Do | Don't +:--| :----- +events are recorded with an associated "stage". | events are recorded with an associated "stage." +The copy is called a "fork". | The copy is called a "fork." +{{< /table >}} +--> +### 在引号内使用国际标准标点 + +{{< table caption = "标点符号约定" >}} +可以 | 不可以 +:--| :----- +事件记录中都包含对应的“stage”。 | 事件记录中都包含对应的“stage。” +此副本称作一个“fork”。| 此副本称作一个“fork。” +{{< /table >}} + +<!-- +## Inline code formatting + +### Use code style for inline code and commands + +For inline code in an HTML document, use the `<code>` tag. In a Markdown +document, use the backtick (`` ` ``). +--> +## 行间代码格式 {#inline-code-formatting} + +### 为行间代码和命令使用代码样式 + +对于 HTML 文档中的行间代码，使用 `<code>` 标记。 +在 Markdown 文档中，使用反引号（`` ` ``）。 + +<!-- +{{< table caption = "Do and Don't - Use code style for inline code and commands" >}} +Do | Don't +:--| :----- +The `kubectl run`command creates a Deployment. | The "kubectl run" command creates a Deployment. +For declarative management, use `kubectl apply`. | For declarative management, use "kubectl apply". +Enclose code samples with triple backticks. (\`\`\`)| Enclose code samples with any other syntax. +Use single backticks to enclose inline code. For example, `var example = true`. | Use two asterisks (`**`) or an underscore (`_`) to enclose inline code. For example, **var example = true**. +Use triple backticks before and after a multi-line block of code for fenced code blocks. | Use multi-line blocks of code to create diagrams, flowcharts, or other illustrations. +Use meaningful variable names that have a context. | Use variable names such as 'foo','bar', and 'baz' that are not meaningful and lack context. +Remove trailing spaces in the code. | Add trailing spaces in the code, where these are important, because the screen reader will read out the spaces as well. +{{< /table >}} +--> +{{< table caption = "行间代码和命令约定" >}} +可以 | 不可以 +:--| :----- +命令 `kubectl run` 会创建一个 Deployment | 命令 "kubectl run" 会创建一个 Deployment。 +在声明式管理中，使用 `kubectl apply`。 | 在声明式管理中，使用 "kubectl apply"。 +用三个反引号来（\`\`\`）标示代码示例 | 用其他语法来标示代码示例。 +使用单个反引号来标示行间代码。例如：`var example = true`。 | 使用两个星号（`**`）或者一个下划线（`_`）来标示行间代码。例如：**var example = true**。 +在多行代码块之前和之后使用三个反引号标示隔离的代码块。 | 使用多行代码块来创建示意图、流程图或者其他表示。 +使用符合上下文的有意义的变量名。 | 使用诸如 'foo'、'bar' 和 'baz' 这类无意义且无语境的变量名。 +删除代码中行尾空白。 | 在代码中包含行尾空白，因为屏幕抓取工具通常也会抓取空白字符。 +{{< /table >}} + +<!-- +The website supports syntax highlighting for code samples, but specifying a language is optional. Syntax highlighting in the code block should conform to the [contrast guidelines.](https://www.w3.org/WAI/WCAG21/quickref/?versions=2.0&showtechniques=141%2C143#contrast-minimum) +--> +{{< note >}} +网站支持为代码示例使用语法加亮，不过指定语法加亮是可选的。 +代码段的语法加亮要遵从[对比度指南](https://www.w3.org/WAI/WCAG21/quickref/?versions=2.0&showtechniques=141%2C143#contrast-minimum) +{{< /note >}} + +<!-- +### Use code style for object field names and namespaces + +{{< table caption = "Do and Don't - Use code style for object field names" >}} +Do | Don't +:--| :----- +Set the value of the `replicas` field in the configuration file. | Set the value of the "replicas" field in the configuration file. +The value of the `exec` field is an ExecAction object. | The value of the "exec" field is an ExecAction object. +Run the process as a Daemonset in the `kube-system` namespace. | Run the process as a Daemonset in the kube-system namespace. +{{< /table >}} +--> +### 为对象字段名和名字空间使用代码风格 + +{{< table caption = "对象字段名约定" >}} +可以 | 不可以 +:--| :----- +在配置文件中设置 `replicas` 字段的值。 | 在配置文件中设置 "replicas" 字段的值。 +`exec` 字段的值是一个 ExecAction 对象。 | "exec" 字段的值是一个 ExecAction 对象。 +在 `kube-system` 名字空间中以 Daemonset 形式运行此进程。 | 在 kube-system 名字空间中以 DaemonSet 形式运行此进程。 +{{< /table >}} + +<!-- +### Use code style for Kubernetes command tool and component names + +{{< table caption = "Do and Don't - Use code style for Kubernetes command tool and component names" >}} +Do | Don't +:--| :----- +The kubelet preserves node stability. | The `kubelet` preserves node stability. +The `kubectl` handles locating and authenticating to the API server. | The kubectl handles locating and authenticating to the apiserver. +Run the process with the certificate, `kube-apiserver --client-ca-file=FILENAME`. | Run the process with the certificate, kube-apiserver --client-ca-file=FILENAME. | +{{< /table >}} +--> +### 用代码样式书写 Kubernetes 命令工具和组件名 + +{{< table caption = "Kubernetes 命令工具和组件名" >}} +可以 | 不可以 +:--| :----- +`kubelet` 维持节点稳定性。 | kubelet 负责维护节点稳定性。 +`kubectl` 处理 API 服务器的定位和身份认证。| kubectl 处理 API 服务器的定位和身份认证。 +使用该证书运行进程 `kube-apiserver --client-ca-file=FILENAME`. | 使用证书运行进程 kube-apiserver --client-ca-file=FILENAME. | +{{< /table >}} + +<!-- +### Starting a sentence with a component tool or component name + +{{< table caption = "Do and Don't - Starting a sentence with a component tool or component name" >}} +Do | Don't +:--| :----- +The `kubeadm` tool bootstraps and provisions machines in a cluster. | `kubeadm` tool bootstraps and provisions machines in a cluster. +The kube-scheduler is the default scheduler for Kubernetes. | kube-scheduler is the default scheduler for Kubernetes. +{{< /table >}} +--> +### 用工具或组件名称开始一句话 + +{{< table caption = "工具或组件名称使用约定" >}} +可以 | 不可以 +:--| :----- +The `kubeadm` tool bootstraps and provisions machines in a cluster. | `kubeadm` tool bootstraps and provisions machines in a cluster. +The kube-scheduler is the default scheduler for Kubernetes. | kube-scheduler is the default scheduler for Kubernetes. +{{< /table >}} + +<!-- +### Use a general descriptor over a component name + +{{< table caption = "Do and Don't - Use a general descriptor over a component name" >}} +Do | Don't +:--| :----- +The Kubernetes API server offers an OpenAPI spec. | The apiserver offers an OpenAPI spec. +Aggregated APIs are subordinate API servers. | Aggregated APIs are subordinate APIServers. +{{< /table >}} +--> +### 尽量使用通用描述而不是组件名称 + +{{< table caption = "组件名称与通用描述" >}} +可以 | 不可以 +:--| :----- +Kubernetes API 服务器提供 OpenAPI 规范。| apiserver 提供 OpenAPI 规范 +聚合 APIs 是下级 API 服务器。 | 聚合 APIs 是下级 APIServers。 +{{< /table >}} + +<!-- +### Use normal style for string and integer field values + +For field values of type string or integer, use normal style without quotation marks. + +{{< table caption = "Do and Don't - Use normal style for string and integer field values" >}} +Do | Don't +:--| :----- +Set the value of `imagePullPolicy` to Always. | Set the value of `imagePullPolicy` to "Always". +Set the value of `image` to nginx:1.16. | Set the value of `image` to `nginx:1.16`. +Set the value of the `replicas` field to 2. | Set the value of the `replicas` field to `2`. +{{< /table >}} +--> +### 使用普通样式表达字符串和整数字段值 + +对于字符串或整数，使用正常样式，不要带引号。 + +{{< table caption = "字符串和整数字段值约定" >}} +可以 | 不可以 +:--| :----- +将 `imagePullPolicy` 设置为 Always。 | 将 `imagePullPolicy` 设置为 "Always"。 +将 `image` 设置为 nginx:1.16. | 将 `image` 设置为 `nginx:1.16`。 +将 `replicas` 字段值设置为 2. | 将 `replicas` 字段值设置为 `2`. +{{< /table >}} + +<!-- +## Code snippet formatting + +### Don't include the command prompt + +{{< table caption = "Do and Don't - Don't include the command prompt" >}} +Do | Don't +:--| :----- +kubectl get pods | $ kubectl get pods +{{< /table >}} +--> +## 代码段格式 + +### 不要包含命令行提示符 + +{{< table caption = "命令行提示符约定" >}} +可以 | 不可以 +:--| :----- +kubectl get pods | $ kubectl get pods +{{< /table >}} + +<!-- +### Separate commands from output + +Verify that the Pod is running on your chosen node: + + kubectl get pods --output=wide + +The output is similar to this: + + NAME READY STATUS RESTARTS AGE IP NODE + nginx 1/1 Running 0 13s 10.200.0.4 worker0 +--> +### 将命令和输出分开 + +例如： + +验证 Pod 已经在你所选的节点上运行： + + kubectl get pods --output=wide + +输出类似于： + + NAME READY STATUS RESTARTS AGE IP NODE + nginx 1/1 Running 0 13s 10.200.0.4 worker0 + +<!-- +### Versioning Kubernetes examples + +Code examples and configuration examples that include version information should be consistent with the accompanying text. + +If the information is version specific, the Kubernetes version needs to be defined in the `prerequisites` section of the [Task template](/docs/contribute/style/page-content-types/#task) or the [Tutorial template](/docs/contribute/style/page-content-types/#tutorial). Once the page is saved, the `prerequisites` section is shown as **Before you begin**. + +To specify the Kubernetes version for a task or tutorial page, include `min-kubernetes-server-version` in the front matter of the page. +--> +### 为 Kubernetes 示例给出版本 + +代码示例或者配置示例如果包含版本信息，应该与对应的文字描述一致。 + +如果所给的信息是特定于具体版本的，需要在 +[任务模版](/zh/docs/contribute/style/page-content-types/#task) +或[教程模版](/zh/docs/contribute/style/page-content-types/#tutorial) +的 `prerequisites` 小节定义 Kubernetes 版本。 +页面保存之后，`prerequisites` 小节会显示为 **开始之前**。 + +如果要为任务或教程页面指定 Kubernetes 版本，可以在文件的前言部分包含 +`min-kubernetes-server-version` 信息。 + +<!-- +If the example YAML is in a standalone file, find and review the topics that +include it as a reference. Verify that any topics using the standalone YAML +have the appropriate version information defined. If a stand-alone YAML file +is not referenced from any topics, consider deleting it instead of updating +it. + +For example, if you are writing a tutorial that is relevant to Kubernetes +version 1.8, the front-matter of your markdown file should look something +like: +--> +如果示例 YAML 是一个独立文件，找到并审查包含该文件的主题页面。 +确认使用该独立 YAML 文件的主题都定义了合适的版本信息。 +如果独立的 YAML 文件没有在任何主题中引用，可以考虑删除该文件， +而不是继续更新它。 + +例如，如果你在编写一个教程，与 Kubernetes 1.8 版本相关。那么你的 Markdown +文件的文件头应该开始起来像这样： + +```yaml +--- +title: <教程标题> +min-kubernetes-server-version: v1.8 +--- +``` + +<!-- +In code and configuration examples, do not include comments about alternative versions. +Be careful to not include incorrect statements in your examples as comments, such as: + +```yaml +apiVersion: v1 # earlier versions use... +kind: Pod +... +``` +--> +在代码和配置示例中，不要包含其他版本的注释信息。 +尤其要小心不要在示例中包含不正确的注释信息，例如： + +```yaml +apiVersion: v1 # 早期版本使用... +kind: Pod +... +``` +<!-- +## Kubernetes.io word list + +A list of Kubernetes-specific terms and words to be used consistently across the site. + +{{< table caption = "Kubernetes.io word list" >}} +Term | Usage +:--- | :---- +Kubernetes | Kubernetes should always be capitalized. +Docker | Docker should always be capitalized. +SIG Docs | SIG Docs rather than SIG-DOCS or other variations. +On-premises | On-premises or On-prem rather than On-premise or other variations. +{{< /table >}} +--> +## Kubernetes.io 术语列表 + +以下特定于 Kubernetes 的术语和词汇在使用时要保持一致性。 + +{{< table caption = "Kubernetes.io 词汇表" >}} +术语 | 用法 +:--- | :---- +Kubernetes | Kubernetes 的首字母要保持大写。 +Docker | Docker 的首字母要保持大写。 +SIG Docs | SIG Docs 是正确拼写形式，不要用 SIG-DOCS 或其他变体。 +On-premises | On-premises 或 On-prem 而不是 On-premise 或其他变体。 +{{< /table >}} + +<!-- +## Shortcodes + +Hugo [Shortcodes](https://gohugo.io/content-management/shortcodes) help create different rhetorical appeal levels. Our documentation supports three different shortcodes in this category: **Note** `{{</* note */>}}`, **Caution** `{{</* caution */>}}`, and **Warning** `{{</* warning */>}}`. + +1. Surround the text with an opening and closing shortcode. + +2. Use the following syntax to apply a style: + + ``` + {{</* note */>}} + No need to include a prefix; the shortcode automatically provides one. (Note:, Caution:, etc.) + {{</* /note */>}} + ``` + +The output is: + +{{< note >}} +The prefix you choose is the same text for the tag. +{{< /note >}} +--> + +## 短代码（Shortcodes） {#shortcodes} + +Hugo [短代码（Shortcodes）](https://gohugo.io/content-management/shortcodes) +有助于创建比较漂亮的展示效果。我们的文档支持三个不同的这类短代码。 +**注意** `{{</* note */>}}`、**小心** `{{</* caution */>}}` 和 **警告** `{{</* warning */>}}`。 + +1. 将要突出显示的文字用短代码的开始和结束形式包围。 +2. 使用下面的语法来应用某种样式： + + ``` + {{</* note */>}} + 不需要前缀；短代码会自动添加前缀（注意：、小心：等） + {{</* /note */>}} + ``` + +输出的样子是： + +{{< note >}} +你所选择的标记决定了文字的前缀。 +{{< /note >}} + +<!-- +### Note + +Use `{{</* note */>}}` to highlight a tip or a piece of information that may be helpful to know. + +For example: + +``` +{{</* note */>}} +You can _still_ use Markdown inside these callouts. +{{</* /note */>}} +``` + +The output is: + +{{< note >}} +You can _still_ use Markdown inside these callouts. +{{< /note >}} +--> +### 注释（Note） {#note} + +使用短代码 `{{</* note */>}}` 来突出显示某种提示或者有助于读者的信息。 + +例如: + +``` +{{</* note */>}} +在这类短代码中仍然 _可以_ 使用 Markdown 语法。 +{{</* /note */>}} +``` + +输出为： + +{{< note >}} +在这类短代码中仍然 _可以_ 使用 Markdown 语法。 +{{< /note >}} + +<!-- +You can use a `{{</* note */>}}` in a list: + +``` +1. Use the note shortcode in a list + +1. A second item with an embedded note + + {{</* note */>}} + Warning, Caution, and Note shortcodes, embedded in lists, need to be indented four spaces. See [Common Shortcode Issues](#common-shortcode-issues). + {{</* /note */>}} + +1. A third item in a list + +1. A fourth item in a list +``` +--> +你可以在列表中使用 `{{</* note */>}}`： + +``` +1. 在列表中使用 note 短代码 + +1. 带嵌套 note 的第二个条目 + + {{</* note */>}} + 警告、小心和注意短代码可以嵌套在列表中，但是要缩进四个空格。 + 参见[常见短代码问题](#common-shortcode-issues)。 + {{</* /note */>}} + +1. 列表中第三个条目 + +1. 列表中第四个条目 +``` + +<!-- +The output is: + +1. Use the note shortcode in a list + +1. A second item with an embedded note + + {{< note >}} + Warning, Caution, and Note shortcodes, embedded in lists, need to be indented four spaces. See [Common Shortcode Issues](#common-shortcode-issues). + {{< /note >}} + +1. A third item in a list + +1. A fourth item in a list +--> +其输出为： + +1. 在列表中使用 note 短代码 + +1. 带嵌套 note 的第二个条目 + + {{< note >}} + 警告、小心和注意短代码可以嵌套在列表中，但是要缩进四个空格。 + 参见[常见短代码问题](#common-shortcode-issues)。 + {{< /note >}} + +1. 列表中第三个条目 + +1. 列表中第四个条目 + +<!-- +### Caution + +Use `{{</* caution */>}}` to call attention to an important piece of information to avoid pitfalls. + +For example: + +``` +{{</* caution */>}} +The callout style only applies to the line directly above the tag. +{{</* /caution */>}} +``` + +The output is: + +{{< caution >}} +The callout style only applies to the line directly above the tag. +{{< /caution >}} +--> +### 小心（Caution） {#caution} + +使用 `{{</* caution */>}}` 短代码来引起读者对某段信息的重视，以避免遇到问题。 + +例如： + +``` +{{</* caution */>}} +此短代码样式仅对标记之上的一行起作用。 +{{</* /caution */>}} +``` + +其输出为： + +{{< caution >}} +此短代码样式仅对标记之上的一行起作用。 +{{< /caution >}} + +<!-- +### Warning + +Use `{{</* warning */>}}` to indicate danger or a piece of information that is crucial to follow. + +For example: + +``` +{{</* warning */>}} +Beware. +{{</* /warning */>}} +``` + +The output is: + +{{< warning >}} +Beware. +{{< /warning >}} +--> +### 警告（Warning） {#warning} + +使用 `{{</* warning */>}}` 来表明危险或者必须要重视的一则信息。 + +例如： + +``` +{{</* warning */>}} +注意事项 +{{</* /warning */>}} +``` + +其输出为： + +{{< warning >}} +注意事项 +{{< /warning >}} + +<!-- +### Katacoda Embedded Live Environment + +This button lets users run Minikube in their browser using the [Katacoda Terminal](https://www.katacoda.com/embed/panel). +It lowers the barrier of entry by allowing users to use Minikube with one click instead of going through the complete +Minikube and Kubectl installation process locally. + +The Embedded Live Environment is configured to run `minikube start` and lets users complete tutorials in the same window +as the documentation. + +{{< caution >}} +The session is limited to 15 minutes. +{{< /caution >}} + +For example: + +``` +{{</* kat-button */>}} +``` + +The output is: + +{{< kat-button >}} +--> +### Katacoda 嵌套现场环境 + +此按钮允许用户使用 [Katacoda 终端](https://www.katacoda.com/embed/panel) +在其浏览器中运行 Minikube。该环境降低了用户对 Minikube 的入门难度， +只需要一次鼠标点击即可完成，而不需要完全经历 Minikube 和 kubectl 的安装过程。 + +嵌套现场环境配置为运行 `minikube start`，允许用户在文档所在的窗口完成教程。 + +{{< caution >}} +会话限制为 15 分钟。 +{{< /caution >}} + +例如： + +``` +{{</* kat-button */>}} +``` + +其输出为： + +{{< kat-button >}} +<!-- +## Common Shortcode Issues + +### Ordered Lists + +Shortcodes will interrupt numbered lists unless you indent four spaces before the notice and the tag. + +For example: + + 1. Preheat oven to 350˚F + + 1. Prepare the batter, and pour into springform pan. + `{{</* note */>}}Grease the pan for best results.{{</* /note */>}}` + + 1. Bake for 20-25 minutes or until set. + +The output is: + +1. Preheat oven to 350˚F + +1. Prepare the batter, and pour into springform pan. + + {{< note >}}Grease the pan for best results.{{< /note >}} + +1. Bake for 20-25 minutes or until set. +--> +## 常见的短代码问题 {#common-shortcode-issues} + +### 编号列表 + +短代码会打乱编号列表的编号，除非你在信息和标志之前都缩进四个空格。 + +例如： + +``` +1. 预热到 350˚F +1. 准备好面糊，倒入烘烤盘 + {{</* note */>}}给盘子抹上油可以达到最佳效果。{{</* /note */>}} +1. 烘烤 20 到 25 分钟，或者直到满意为止。 +``` + +其输出结果为： + +1. 预热到 350˚F +1. 准备好面糊，倒入烘烤盘 + {{< note >}}给盘子抹上油可以达到最佳效果。{{< /note >}} +1. 烘烤 20 到 25 分钟，或者直到满意为止。 + +<!-- +### Include Statements + +Shortcodes inside include statements will break the build. You must insert them in the parent document, before and after you call the include. For example: + +``` +{{</* note */>}} +{{</* include "task-tutorial-prereqs.md" */>}} +{{</* /note */>}} +``` +--> +### Include 语句 + +如果短代码出现在 include 语境中，会导致网站无法构建。 +你必须将他们插入到上级文档中，分别将开始标记和结束标记插入到 include 语句之前和之后。 +例如： + +``` +{{</* note */>}} +{{</* include "task-tutorial-prereqs.md" */>}} +{{</* /note */>}} +``` + +<!-- +## Markdown elements + +### Line breaks +Use a single newline to separate block-level content like headings, lists, images, code blocks, and others. The exception is second-level headings, where it should be two newlines. Second-level headings follow the first-level (or the title) without any preceding paragraphs or texts. A two line spacing helps visualize the overall structure of content in a code editor better. +--> +## Markdown 元素 {#markdown-elements} + +### 换行 {#line-breaks} + +使用单一换行符来隔离块级内容，例如标题、列表、图片、代码块以及其他元素。 +这里的例外是二级标题，必须有两个换行符。 +二级标题紧随一级标题（或标题），中间没有段落或文字。 + +两行的留白有助于在代码编辑器中查看整个内容的结构组织。 + +<!-- +### Headings +People accessing this documentation may use a screen reader or other assistive technology (AT). [Screen readers](https://en.wikipedia.org/wiki/Screen_reader) are linear output devices, they output items on a page one at a time. If there is a lot of content on a page, you can use headings to give the page an internal structure. A good page structure helps all readers to easily navigate the page or filter topics of interest. + +{{< table caption = "Do and Don't - Headings" >}} +Do | Don't +:--| :----- +Update the title in the front matter of the page or blog post. | Use first level heading, as Hugo automatically converts the title in the front matter of the page into a first-level heading. +Use ordered headings to provide a meaningful high-level outline of your content. | Use headings level 4 through 6, unless it is absolutely necessary. If your content is that detailed, it may need to be broken into separate articles. +Use pound or hash signs (`#`) for non-blog post content. | Use underlines (`---` or `===`) to designate first-level headings. +Use sentence case for headings. For example, **Extend kubectl with plugins** | Use title case for headings. For example, **Extend Kubectl With Plugins** +{{< /table >}} +--> +### 标题 {#headings} + +访问文档的读者可能会使用屏幕抓取程序或者其他辅助技术。 +[屏幕抓取器](https://en.wikipedia.org/wiki/Screen_reader)是一种线性输出设备, +它们每次输出页面上的一个条目。 +如果页面上内容过多，你可以使用标题来为页面组织结构。 +页面的良好结构对所有读者都有帮助，使得他们更容易浏览或者过滤感兴趣的内容。 + +{{< table caption = "标题约定" >}} +可以 | 不可以 +:--| :----- +更新页面或博客在前言部分中的标题 | 使用一级标题。因为 Hugo 会自动将页面前言部分的标题转化为一级标题。 +使用编号的标题以便内容组织有一个更有意义的结构。| 使用四级到六级标题，除非非常有必要这样。如果你要编写的内容有非常多细节，可以尝试拆分成多个不同页面。 +在非博客内容页面中使用井号（`#`）| 使用下划线 `---` 或 `===` 来标记一级标题。 +使用正常大小写来标示标题。例如：**Extend kubectl with plugins** | 使用首字母大写来标示标题。例如：**Extend Kubectl With Plugins** +{{< /table >}} + +<!-- +### Paragraphs + +{{< table caption = "Do and Don't - Paragraphs" >}} +Do | Don't +:--| :----- +Try to keep paragraphs under 6 sentences. | Indent the first paragraph with space characters. For example, ⋅⋅⋅Three spaces before a paragraph will indent it. +Use three hyphens (`---`) to create a horizontal rule. Use horizontal rules for breaks in paragraph content. For example, a change of scene in a story, or a shift of topic within a section. | Use horizontal rules for decoration. +{{< /table >}} +--> +### 段落 {#paragraphs} + +{{< table caption = "段落约定" >}} +可以 | 不可以 +:--| :----- +尝试不要让段落超出 6 句话。 | 用空格来缩进第一段。例如，⋅⋅⋅段落前面的三个空格会将其缩进。 +使用三个连字符（`---`）来创建水平线。使用水平线来分隔段落内容。例如，在故事中切换场景或者在上下文中切换主题。 | 使用水平线来装饰页面。 +{{< /table >}} + +<!-- +### Links + +{{< table caption = "Do and Don't - Links" >}} +Do | Don't +Write hyperlinks that give you context for the content they link to. For example: Certain ports are open on your machines. See <a href="#check-required-ports">Check required ports</a> for more details. | Use ambiguous terms such as “click here”. For example: Certain ports are open on your machines. See <a href="#check-required-ports">here</a> for more details. +Write Markdown-style links: `[link text](URL)`. For example: `[Hugo shortcodes](/docs/contribute/style/hugo-shortcodes/#table-captions)` and the output is [Hugo shortcodes](/docs/contribute/style/hugo-shortcodes/#table-captions). | Write HTML-style links: `<a href="/media/examples/link-element-example.css" target="_blank">Visit our tutorial!</a>`, or create links that open in new tabs or windows. For example: `[example website](https://example.com){target="_blank"}` +{{< /table >}} +--> +### 链接 {#links} + +{{< table caption = "链接约定" >}} +可以 | 不可以 +:--| :----- +插入超级链接时给出它们所链接到的目标内容的上下文。例如：你的机器上某些端口处于开放状态。参见<a href="#check-required-ports">检查所需端口</a>了解更详细信息。| 使用有二义性的术语，如“点击这里”。例如：你的机器上某些端口处于打开状态。参见<a href="#check-required-ports">这里</a>了解详细信息。 +编写 Markdown 风格的链接：`[链接文本](URL)`。例如：`[Hugo 短代码](/zh/docs/contribute/style/hugo-shortcodes/#table-captions)`，输出是[Hugo 短代码](/zh/docs/contribute/style/hugo-shortcodes/#table-captions). | 编写 HTML 风格的超级链接：`<a href="/media/examples/link-element-example.css" target="_blank">访问我们的教程！</a>`，或者创建会打开新 Tab 页或新窗口的链接。例如：`[网站示例](https://example.com){target="_blank"}`。 +{{< /table >}} + +<!-- +### Lists +Group items in a list that are related to each other and need to appear in a specific order or to indicate a correlation between multiple items. When a screen reader comes across a list—whether it is an ordered or unordered list—it will be announced to the user that there is a group of list items. The user can then use the arrow keys to move up and down between the various items in the list. +Website navigation links can also be marked up as list items; after all they are nothing but a group of related links. + + - End each item in a list with a period if one or more items in the list are complete sentences. For the sake of consistency, normally either all items or none should be complete sentences. + + {{< note >}} Ordered lists that are part of an incomplete introductory sentence can be in lowercase and punctuated as if each item was a part of the introductory sentence.{{< /note >}} +--> +### 列表 {#lists} + +将一组相互关联的内容组织到一个列表中，以便表达这些条目彼此之间有先后顺序或者某种相互关联关系。 +当屏幕抓取器遇到列表时，无论该列表是否有序，它会告知用户存在一组枚举的条目。 +用户可以使用箭头键来上下移动，浏览列表中条目。 +网站导航链接也可以标记成列表条目，因为说到底他们也是一组相互关联的链接而已。 + + - 如果列表中一个或者多个条目是完整的句子，则在每个条目末尾添加句号。 + 出于一致性考虑，一般要么所有条目要么没有条目是完整句子。 + + {{< note >}} 编号列表如果是不完整的介绍性句子的一部分，可以全部用小写字母，并按照 + 每个条目都是句子的一部分来看待和处理。{{< /note >}} + +<!-- + - Use the number one (`1.`) for ordered lists. + + - Use (`+`), (`*`), or (`-`) for unordered lists. + + - Leave a blank line after each list. + + - Indent nested lists with four spaces (for example, ⋅⋅⋅⋅). + + - List items may consist of multiple paragraphs. Each subsequent paragraph in a list item must be indented by either four spaces or one tab. +--> + - 在编号列表中，使用数字一（`1.`） + + - 对非排序列表，使用加号（`+`）、星号（`*`）、或者减号（`-`） + + - 在每个列表之后留一个空行 + + - 对于嵌套的列表，相对缩进四个空格（例如，⋅⋅⋅⋅）。 + + - 列表条目可能包含多个段落。每个后续段落都要缩进或者四个空格或者一个制表符。 + +<!-- +### Tables + +The semantic purpose of a data table is to present tabular data. Sighted users can quickly scan the table but a screen reader goes through line by line. A table caption is used to create a descriptive title for a data table. Assistive technologies (AT) use the HTML table caption element to identify the table contents to the user within the page structure. + +- Add table captions using [Hugo shortcodes](/docs/contribute/style/hugo-shortcodes/#table-captions) for tables. +--> +### 表格 {#tables} + +数据表格的语义用途是呈现表格化的数据。 +用户可以快速浏览表格，但屏幕抓取器需要逐行地处理数据。 +表格标题可以用来给数据表提供一个描述性的标题。 +辅助技术使用 HTML 表格标题元素来在页面结构中辨识表格内容。 + +- 请 [Hugo 短代码](/zh/docs/contribute/style/hugo-shortcodes/#table-captions) + 为表格添加标题。 + +<!-- +## Content best practices + +This section contains suggested best practices for clear, concise, and consistent content. + +### Use present tense + +{{< table caption = "Do and Don't - Use present tense" >}} +Do | Don't +This command starts a proxy. | This command will start a proxy. + {{< /table >}} + +Exception: Use future or past tense if it is required to convey the correct +meaning. +--> +## 内容最佳实践 {#content-best-practices} + +本节包含一些建议的最佳实践，用来开发清晰、明确一致的文档内容。 + +### 使用现在时态 + +{{< table caption = "使用现在时态" >}} +可以 | 不可以 +:--| :----- +此命令启动代理。| 此命令将启动一个代理。 +{{< /table >}} + +例外：如果需要使用过去时或将来时来表达正确含义时，是可以使用的。 + +<!-- +### Use active voice + +{{< table caption = "Do and Don't - Use active voice" >}} +Do | Don't +You can explore the API using a browser. | The API can be explored using a browser. +The YAML file specifies the replica count. | The replica count is specified in the YAML file. +{{< /table >}} + +Exception: Use passive voice if active voice leads to an awkward construction. +--> +### 使用主动语态 + +{{< table caption = "使用主动语态" >}} +可以 | 不可以 +:--| :----- +你可以使用浏览器来浏览 API。| API 可以被使用浏览器来浏览。 +YAML 文件给出副本个数。 | 副本个数是在 YAML 文件中给出的。 +{{< /table >}} + +例外：如果主动语态会导致句子很难构造时，可以使用被动语态。 + +<!-- +### Use simple and direct language + +Use simple and direct language. Avoid using unnecessary phrases, such as saying "please." + +{{< table caption = "Do and Don't - Use simple and direct language" >}} +Do | Don't +To create a ReplicaSet, ... | In order to create a ReplicaSet, ... +See the configuration file. | Please see the configuration file. +View the Pods. | With this next command, we'll view the Pods. +{{< /table >}} +--> +### 使用简单直接的语言 + +使用简单直接的语言。避免不必要的短语，例如说“请”。 + +{{< table caption = "使用简单直接语言" >}} +可以 | 不可以 +:--| :----- +要创建 ReplicaSet，... | 如果你想要创建 ReplicaSet，... +参看配置文件。 | 请自行查看配置文件。 +查看 Pods。| 使用下面的命令，我们将会看到 Pods。 +{{< /table >}} + +<!-- +### Address the reader as "you" + +{{< table caption = "Do and Don't - Addressing the reader" >}} +Do | Don't +:--| :----- +You can create a Deployment by ... | We'll create a Deployment by ... +In the preceding output, you can see... | In the preceding output, we can see ... +{{< /table >}} +--> +### 将读者称为“你” + +{{< table caption = "将读者称为“你”" >}} +可以 | 不可以 +:--| :----- +你可以通过 ... 创建一个 Deployment。 | 通过...我们将创建一个 Deployment。 +在前面的输出中，你可以看到... | 在前面的输出中，我们可以看到... +{{< /table >}} + +<!-- +### Avoid Latin phrases + +Prefer English terms over Latin abbreviations. + +{{< table caption = "Do and Don't - Avoid Latin phrases" >}} +Do | Don't +For example, ... | e.g., ... +That is, ...| i.e., ... +{{< /table >}} + +Exception: Use "etc." for et cetera. +--> +### 避免拉丁短语 + +尽可能使用英语而不是拉丁语缩写。 + +{{< table caption = "避免拉丁语短语" >}} +可以 | 不可以 +:--| :----- +例如，... | e.g., ... +也就是说，...| i.e., ... +{{< /table >}} + +例外：使用 etc. 表示等等。 + +<!-- +## Patterns to avoid + +### Avoid using "we" + +Using "we" in a sentence can be confusing, because the reader might not know +whether they're part of the "we" you're describing. + +{{< table caption = "Do and Don't - Patterns to avoid" >}} +Do | Don't +Version 1.4 includes ... | In version 1.4, we have added ... +Kubernetes provides a new feature for ... | We provide a new feature ... +This page teaches you how to use Pods. | In this page, we are going to learn about Pods. +{{< /table >}} +--> +## 应避免的模式 + +### 避免使用“我们” + +在句子中使用“我们”会让人感到困惑，因为读者可能不知道这里的 +“我们”指的是谁。 + +{{< table caption = "要避免的模式" >}} +可以 | 不可以 +:--| :----- +版本 1.4 包含了 ... | 在 1.4 版本中，我们添加了 ... +Kubernetes 为 ... 提供了一项新功能。 | 我们提供了一项新功能... +本页面教你如何使用 Pods。| 在本页中，我们将会学到如何使用 Pods。 +{{< /table >}} + +<!-- +### Avoid jargon and idioms + +Some readers speak English as a second language. Avoid jargon and idioms to help them understand better. + +{{< table caption = "Do and Don't - Avoid jargon and idioms" >}} +Do | Don't +:--| :----- +Internally, ... | Under the hood, ... +Create a new cluster. | Turn up a new cluster. +{{< /table >}} +--> +### 避免使用俚语或行话 + +对某些读者而言，英语是其外语。 +避免使用一些俚语或行话有助于他们更方便的理解内容。 + +{{< table caption = "避免使用俚语或行话" >}} +可以 | 不可以 +:--| :----- +Internally, ... | Under the hood, ... +Create a new cluster. | Turn up a new cluster. +{{< /table >}} + +<!-- +### Avoid statements about the future + +Avoid making promises or giving hints about the future. If you need to talk about +an alpha feature, put the text under a heading that identifies it as alpha +information. + +### Avoid statements that will soon be out of date + +Avoid words like "currently" and "new." A feature that is new today might not be +considered new in a few months. + +{{< table caption = "Do and Don't - Avoid statements that will soon be out of date" >}} +Do | Don't +In version 1.4, ... | In the current version, ... +The Federation feature provides ... | The new Federation feature provides ... +{{< /table >}} +--> +### 避免关于将来的陈述 + +要避免对将来作出承诺或暗示。如果你需要讨论的是 Alpha 功能特性，可以将相关文字 +放在一个单独的标题下，标示为 alpha 版本信息。 + +### 避免使用很快就会过时的表达 + +避免使用一些很快就会过时的陈述，例如“目前”、“新的”。 +今天而言是新的功能，过了几个月之后就不再是新的了。 + +{{< table caption = "避免使用很快过时的表达" >}} +可以 | 不可以 +:--| :----- +在版本 1.4 中，... | 在当前版本中，... +联邦功能特性提供 ... | 新的联邦功能特性提供 ... +{{< /table >}} + +## {{% heading "whatsnext" %}} + +* 了解[编写新主题](/zh/docs/contribute/style/write-new-topic/). +* 了解[页面内容类型](/zh/docs/contribute/style/page-content-types/). +* 了解[发起 PR](/zh/docs/contribute/new-content/open-a-pr/). diff --git a/content/zh/docs/contribute/style/write-new-topic.md b/content/zh/docs/contribute/style/write-new-topic.md index 671b110881..bd5a2fce72 100644 --- a/content/zh/docs/contribute/style/write-new-topic.md +++ b/content/zh/docs/contribute/style/write-new-topic.md @@ -3,13 +3,10 @@ title: 撰写新主题 content_type: task weight: 20 --- - <!-- ---- title: Writing a new topic content_type: task weight: 20 ---- --> <!-- overview --> @@ -18,30 +15,24 @@ This page shows how to create a new topic for the Kubernetes docs. --> 本页面展示如何为 Kubernetes 文档库创建新主题。 - ## {{% heading "prerequisites" %}} <!-- Create a fork of the Kubernetes documentation repository as described in [Start contributing](/docs/contribute/start/). --> - -如[开始贡献](/docs/contribute/start/)中所述，创建 Kubernetes 文档库的分支。 - +如[发起 PR](/zh/docs/contribute/new-content/open-a-pr/)中所述，创建 Kubernetes 文档库的派生副本。 <!-- steps --> <!-- ## Choosing a page type ---> -## 选择页面类型 - -<!-- As you prepare to write a new topic, think about the page type that would fit your content the best: --> +## 选择页面类型 -当你准备写一个新的主题时，考虑一下最适合你的内容的页面类型： +当你准备编写一个新的主题时，考虑一下最适合你的内容的页面类型： <!-- Guidelines for choosing a page type @@ -52,30 +43,25 @@ Task | A task page shows how to do a single thing. The idea is to give readers a Tutorial | A tutorial page shows how to accomplish a goal that ties together several Kubernetes features. A tutorial might provide several sequences of steps that readers can actually do as they read the page. Or it might provide explanations of related pieces of code. For example, a tutorial could provide a walkthrough of a code sample. A tutorial can include brief explanations of the Kubernetes features that are being tied together, but should link to related concept topics for deep explanations of individual features. --> - -{{< table caption = "选择页面类型的准则" >}} +{{< table caption = "选择页面类型的说明" >}} 类型 | 描述 :--- | :---------- -概念 | 每个概念页面负责解释 Kubernetes 的某方面。例如，概念页面可以描述 Kubernetes Deployment 对象，并解释当部署、扩展和更新时，它作为应用程序所扮演的角色。一般来说，概念页面不包括步骤序列，而是提供任务或教程的链接。一个概念主题的示例，请参见 <a href="/docs/concepts/architecture/nodes/">节点</a>。 -任务 | 任务页面展示了如何完成单个任务。这样做的目的是给读者提供一系列的步骤，让他们在阅读时可以实际执行。任务页面可长可短，前提是它始终围绕着某个主题。在任务页面中，可以将简短的解释与要执行的步骤混合在一起。如果需要提供较长的解释，则应在概念主题中进行。相关联的任务和概念主题应该相互链接。一个简短的任务页面的实例，请参见 <a href="/docs/tasks/configure-pod-container/configure-volume-storage/">配置一个使用卷进行存储的 Pod</a>。一个较长的任务页面的实例，请参见 <a href="/docs/tasks/configure-pod-container/configure-liveness-readiness-probes/">配置活动性和就绪性探针</a>。 -教程 | 教程页面展示如何实现某个目标，该目标将几个 Kubernetes 特性联系在一起。教程可能提供一些步骤序列，读者可以在阅读页面时实际执行这些步骤。或者它可以提供相关代码片段的解释。例如，教程可以提供代码示例的讲解。教程可以包括对 Kubernetes 几个关联特性的简要解释，但应该链接到相关概念主题，以便深入解释各个特性。 +概念（Concept） | 概念页面负责解释 Kubernetes 的某方面。例如，概念页面可以描述 Kubernetes Deployment 对象，并解释当部署、扩展和更新时，它作为应用程序所扮演的角色。一般来说，概念页面不包括步骤序列，而是提供任务或教程的链接。概念主题的示例可参见 <a href="/zh/docs/concepts/architecture/nodes/">节点</a>。 +任务（Task） | 任务页面展示如何完成特定任务。其目的是给读者提供一系列的步骤，让他们在阅读时可以实际执行。任务页面可长可短，前提是它始终围绕着某个主题展开。在任务页面中，可以将简短的解释与要执行的步骤混合在一起。如果需要提供较长的解释，则应在概念主题中进行。相关联的任务和概念主题应该相互链接。一个简短的任务页面的实例可参见 <a href="/zh/docs/tasks/configure-pod-container/configure-volume-storage/">配置 Pod 使用卷存储</a>。一个较长的任务页面的实例可参见 <a href="/zh/docs/tasks/configure-pod-container/configure-liveness-readiness-probes/">配置活跃性和就绪性探针</a>。 +教程（Tutorial） | 教程页面展示如何实现某个目标，该目标将若干 Kubernetes 功能特性联系在一起。教程可能提供一些步骤序列，读者可以在阅读页面时实际执行这些步骤。或者它可以提供相关代码片段的解释。例如，教程可以提供代码示例的讲解。教程可以包括对 Kubernetes 几个关联特性的简要解释，但有关更深入的特性解释应该链接到相关概念主题。 {{< /table >}} <!-- -Use a template for each new page. Each page type has a -[template](/docs/contribute/style/page-templates/) -that you can use as you write your topic. Using templates helps ensure +Use a [content type](/docs/contribute/style/page-content-types/) for each new page +that you write. Using page type helps ensure consistency among topics of a given type. --> -为每个新页面使用模板。每种页面类型都有一个[模板](/docs/contribute/style/page-templates/)，这个模板可以在编写主题时使用。使用模板有助于确保给定类型主题之间的一致性。 +为每个新页面选择其[内容类型](/zh/docs/contribute/style/page-content-types/)。 +使用页面类型有助于确保给定类型的各主题之间保持一致。 <!-- ## Choosing a title and filename ---> -## 选择标题和文件名 - -<!-- Choose a title that has the keywords you want search engines to find. Create a filename that uses the words in your title separated by hyphens. For example, the topic with title @@ -84,45 +70,47 @@ has filename `http-proxy-access-api.md`. You don't need to put "kubernetes" in the filename, because "kubernetes" is already in the URL for the topic, for example: --> +## 选择标题和文件名 -选择一个标题，标题中包含了要通过搜索引擎要查找的关键字。创建一个文件名，使用标题中由连字符分隔的单词。例如，标题为[使用 HTTP 代理访问 Kubernetes API](/docs/tasks/access-kubernetes-api/http-proxy-access-api/) 的主题的文件名为 `http-proxy-access-api.md`。你不需要在文件名中加上 "kubernetes"，因为 "kubernetes" 已经在主题的 URL 中了，例如： +选择一个标题，确保其中包含希望搜索引擎发现的关键字。 +确定文件名时请使用标题中的单词，由连字符分隔。 +例如，标题为[Using an HTTP Proxy to Access Kubernetes API](/zh/docs/tasks/extend-kubernetes/http-proxy-access-api/) +的主题的文件名为 `http-proxy-access-api.md`。 +你不需要在文件名中加上 "kubernetes"，因为 "kubernetes" 已经在主题的 URL 中了， +例如： - /docs/tasks/access-kubernetes-api/http-proxy-access-api/ + /docs/tasks/extend-kubernetes/http-proxy-access-api/ <!-- ## Adding the topic title to the front matter ---> -## 在页面头部添加主题标题 - -<!-- In your topic, put a `title` field in the [front matter](https://gohugo.io/content-management/front-matter/). The front matter is the YAML block that is between the triple-dashed lines at the top of the page. Here's an example: + +``` +title: Using an HTTP Proxy to Access the Kubernetes API +``` --> +## 在页面前言中添加主题标题 -在你的主题中，在[页面头部](https://gohugo.io/content-management/front-matter/)设置一个 `title` 字段。页面头部是位于页面顶部三条虚线之间的 YAML 块。下面是一个例子： +在你的主题中，在[前言（front-matter）](https://gohugo.io/content-management/front-matter/) +中设置一个 `title` 字段。 +前言是位于页面顶部三条虚线之间的 YAML 块。下面是一个例子： -<!-- - --- - title: Using an HTTP Proxy to Access the Kubernetes API - --- ---> - - --- - title: 使用 HTTP 代理访问 Kubernetes API - --- +``` +--- +title: 使用 HTTP 代理访问 Kubernetes API +--- +``` <!-- ## Choosing a directory ---> -## 选择目录 - -<!-- Depending on your page type, put your new file in a subdirectory of one of these: --> +## 选择目录 根据页面类型，将新文件放入其中一个子目录中： @@ -134,31 +122,29 @@ Depending on your page type, put your new file in a subdirectory of one of these You can put your file in an existing subdirectory, or you can create a new subdirectory. --> - 你可以将文件放在现有的子目录中，也可以创建一个新的子目录。 <!-- ## Placing your topic in the table of contents ---> -## 将主题放在目录中 - -<!-- The table of contents is built dynamically using the directory structure of the documentation source. The top-level directories under `/content/en/docs/` create top-level navigation, and subdirectories each have entries in the table of contents. --> +## 将主题放在目录中 -目录是使用文档源的目录结构动态构建的。`/content/en/docs/` 下的顶层目录创建顶层导航，它和子目录在目录中都有条目。 +目录是使用文档源的目录结构动态构建的。 +`/content/en/docs/` 下的顶层目录用于创建顶层导航条目， +这些目录和它们的子目录在网站目录中都有对应条目。 <!-- Each subdirectory has a file `_index.md`, which represents the "home" page for a given subdirectory's content. The `_index.md` does not need a template. It can contain overview content about the topics in the subdirectory. --> - -每个子目录都有一个 `_index.md` 文件，它表示指定子目录内容的主页面。`_index.md` 文件不需要模板。它可以包含有关子目录中主题的概述内容。 +每个子目录都有一个 `_index.md` 文件，它表示的是该子目录内容的主页面。 +`_index.md` 文件不需要模板。它可以包含各子目录中主题的概述内容。 <!-- Other files in a directory are sorted alphabetically by default. This is almost @@ -167,22 +153,22 @@ subdirectory, set the `weight:` front-matter key to an integer. Typically, we use multiples of 10, to account for adding topics later. For instance, a topic with weight `10` will come before one with weight `20`. --> - -默认情况下，目录中的其他文件按字母顺序排序。这几乎不是最好的顺序。要控制子目录中主题的相对排序，请将页面头部的键 `weight:` 设置为整数。通常我们使用 10 的倍数，添加后续主题时 `weight` 值递增。例如，`weight` 为 `10` 的主题将位于 `weight` 为 `20` 的主题之前。 +默认情况下，目录中的其他文件按字母顺序排序。这一般不是最好的顺序。 +要控制子目录中主题的相对排序，请将页面头部的键 `weight:` 设置为整数值。 +通常我们使用 10 的倍数，添加后续主题时 `weight` 值递增。 +例如，`weight` 为 `10` 的主题将位于 `weight` 为 `20` 的主题之前。 <!-- ## Embedding code in your topic ---> -## 在主题中嵌入代码 - -<!-- If you want to include some code in your topic, you can embed the code in your file directly using the markdown code block syntax. This is recommended for the following cases (not an exhaustive list): --> +## 在主题中嵌入代码 -如果你想在主题中嵌入一些代码，可以直接使用标记代码块语法将代码嵌入到文件中。建议用于以下情况（并非详尽列表）： +如果你想在主题中嵌入一些代码，可以直接使用 Markdown 代码块语法将代码嵌入到文件中。 +建议在以下场合（并非详尽列表）使用嵌入代码： <!-- - The code shows the output from a command such as @@ -202,34 +188,41 @@ following cases (not an exhaustive list): --> - 代码显示来自命令的输出，例如 `kubectl get deploy mydeployment -o json | jq '.status'`。 -- 代码不够通用，用户无法验证。例如，你可以嵌入 YAML 文件来创建一个依赖于特定 [FlexVolume](/docs/concepts/storage/volumes#flexvolume)实现的 Pod。 -- 该代码是一个不完整的示例，因为它的目的是高亮显示大文件的部分内容。例如，在描述自定义 [PodSecurityPolicy](/docs/tasks/administer-cluster/sysctl-cluster/#podsecuritypolicy)的方法时，出于某些原因，你可以直接在主题文件中提供一个简短的片段。 -- 由于其他原因，该代码不适合用户验证。例如，当使用 `kubectl edit` 命令描述如何将新属性添加到资源时，你可以提供一个仅包含要添加的属性的简短示例。 +- 代码不够通用，用户无法验证。例如，你可以嵌入 YAML 文件来创建一个依赖于特定 + [FlexVolume](/zh/docs/concepts/storage/volumes#flexvolume) 实现的 Pod。 +- 该代码是一个不完整的示例，因为其目的是突出展现某个大文件中的部分内容。 + 例如，在描述出于某些原因定制 + [PodSecurityPolicy](/zh/docs/tasks/administer-cluster/sysctl-cluster/#podsecuritypolicy) + 的方法时，你可以在主题文件中直接提供一个短的代码段。 +- 由于某些其他原因，该代码不适合用户验证。 + 例如，当使用 `kubectl edit` 命令描述如何将新属性添加到资源时， + 你可以提供一个仅包含要添加的属性的简短示例。 <!-- ## Including code from another file ---> -## 引用来自其他文件的代码 - -<!-- Another way to include code in your topic is to create a new, complete sample file (or group of sample files) and then reference the sample from your topic. Use this method to include sample YAML files when the sample is generic and reusable, and you want the reader to try it out themselves. --> +## 引用来自其他文件的代码 -在主题中引用代码的另一种方法是创建一个新的、完整的示例文件（或示例文件组），然后从主题中引用这些示例。当示例是通用的和可重用的，并且你希望读者自己验证时，使用此方法引用示例 YAML 文件。 +在主题中引用代码的另一种方法是创建一个新的、完整的示例文件（或文件组）， +然后在主题中引用这些示例。当示例是通用的和可重用的，并且你希望读者自己验证时， +使用此方法引用示例 YAML 文件。 <!-- When adding a new standalone sample file, such as a YAML file, place the code in one of the `<LANG>/examples/` subdirectories where `<LANG>` is the language for the topic. In your topic file, use the `codenew` shortcode: --> +添加新的独立示例文件（如 YAML 文件）时，将代码放在 `<LANG>/examples/` 的某个子目录中， +其中 `<LANG>` 是该主题的语言。在主题文件中使用 `codenew` 短代码： -添加新的独立示例文件（如 YAML 文件）时，将代码放在 `<LANG>/examples/` 的某个子目录中，其中 `<LANG>` 是该主题的语言。在主题文件中使用 `codenew` 短代码： - -<pre>{{< codenew file="<RELPATH>/my-example-yaml>" >}}</pre> +```none +{{</* codenew file="<RELPATH>/my-example-yaml>" */>}} +``` <!-- where `<RELPATH>` is the path to the file to include, relative to the @@ -237,7 +230,9 @@ where `<RELPATH>` is the path to the file to include, relative to the file located at `/content/en/examples/pods/storage/gce-volume.yaml`. --> -`<RELPATH>` 是要引用的文件的路径，相对于 `examples` 目录。以下 Hugo 短代码引用了位于 `/content/en/examples/pods/storage/gce-volume.yaml` 的 YAML 文件。 +`<RELPATH>` 是要引用的文件的路径，相对于 `examples` 目录。以下 Hugo +短代码引用了位于 `/content/en/examples/pods/storage/gce-volume.yaml` 的 YAML +文件。 ```none {{</* codenew file="pods/storage/gce-volume.yaml" */>}} @@ -249,26 +244,23 @@ from interpreting them, use C-style comments directly after the `<` and before the `>` characters. View the code for this page for an example. --> {{< note >}} -要展示上述示例中的原始 Hugo 短代码并避免 Hugo 对其进行解释，请直接在 `<` 字符之后和 `>` 字符之前使用 C 样式注释。请查看此页面的代码。 +要展示上述示例中的原始 Hugo 短代码并避免 Hugo 对其进行解释， +请直接在 `<` 字符之后和 `>` 字符之前使用 C 样式注释。请查看此页面的代码。 {{< /note >}} <!-- ## Showing how to create an API object from a configuration file ---> -## 显示如何从配置文件创建 API 对象 - -<!-- If you need to demonstrate how to create an API object based on a configuration file, place the configuration file in one of the subdirectories under `<LANG>/examples`. ---> -如果需要演示如何基于配置文件创建 API 对象，请将配置文件放在 `<LANG>/examples` 下的某个子目录中。 - -<!-- In your topic, show this command: --> +## 显示如何从配置文件创建 API 对象 + +如果需要演示如何基于配置文件创建 API 对象，请将配置文件放在 `<LANG>/examples` +下的某个子目录中。 在主题中展示以下命令： @@ -283,39 +275,33 @@ Travis CI for the Website automatically runs this test case when PRs are submitted to ensure all examples pass the tests. --> {{< note >}} -将新的 YAML 文件添加到 `<LANG>/examples` 目录时，请确保该文件也在 `<LANG>/examples_test.go` 文件中被引用。当提交拉取请求时，网站的 Travis CI 会自动运行此测试用例，以确保所有示例都通过测试。 +将新的 YAML 文件添加到 `<LANG>/examples` 目录时，请确保该文件也在 +`<LANG>/examples_test.go` 文件中被引用。 +当提交拉取请求时，网站的 Travis CI 会自动运行此测试用例，以确保所有示例都通过测试。 {{< /note >}} <!-- For an example of a topic that uses this technique, see [Running a Single-Instance Stateful Application](/docs/tutorials/stateful-application/run-stateful-application/). --> - -有关使用此技术的主题的示例，请参见[运行单实例有状态的应用](/docs/tutorials/stateful-application/run-stateful-application/)。 +有关使用此技术的主题的示例，请参见 +[运行单实例有状态的应用](/zh/docs/tasks/run-application/run-single-instance-stateful-application/)。 <!-- ## Adding images to a topic + +Put image files in the `/images` directory. The preferred image format is SVG. --> +## 向主题添加图片 -## 向主题添加镜像 +将图片文件放入 `/images` 目录。首选的图片格式是 SVG。 -<!-- -Put image files in the `/images` directory. The preferred -image format is SVG. ---> - -将镜像文件放入 `/images` 目录。首选的镜像格式是 SVG。 - - - -<!-- -* Learn about [using page templates](/docs/home/contribute/page-templates/). -* Learn about [staging your changes](/docs/home/contribute/stage-documentation-changes/). -* Learn about [creating a pull request](/docs/home/contribute/create-pull-request/). ---> ## {{% heading "whatsnext" %}} -* 学习[使用页面模板](/docs/home/contribute/page-templates/)。 -* 学习[展示你的修改](/docs/home/contribute/stage-documentation-changes/)。 -* 学习[创建一个拉取请求](/docs/home/contribute/create-pull-request/)。 +<!-- +* Learn about [using page content types](/docs/contribute/style/page-content-types/). +* Learn about [creating a pull request](/docs/contribute/new-content/open-a-pr/). +--> +* 了解[使用页面内容类型](/zh/docs/contribute/style/page-content-types/). +* 了解[创建 PR](/zh/docs/contribute/new-content/open-a-pr/). diff --git a/content/zh/docs/contribute/suggesting-improvements.md b/content/zh/docs/contribute/suggesting-improvements.md new file mode 100644 index 0000000000..63383e5637 --- /dev/null +++ b/content/zh/docs/contribute/suggesting-improvements.md @@ -0,0 +1,120 @@ +--- +title: 提出内容改进建议 +slug: suggest-improvements +content_type: concept +weight: 10 +card: + name: 贡献 + weight: 20 +--- +<!-- +title: Suggesting content improvements +slug: suggest-improvements +content_type: concept +weight: 10 +card: + name: contribute + weight: 20 +--> + +<!-- overview --> + +<!-- +If you notice an issue with Kubernetes documentation, or have an idea for new content, then open an issue. All you need is a [GitHub account](https://github.com/join) and a web browser. + +In most cases, new work on Kubernetes documentation begins with an issue in GitHub. Kubernetes contributors +then review, categorize and tag issues as needed. Next, you or another member +of the Kubernetes community open a pull request with changes to resolve the issue. +--> +如果你发现 Kubernetes 文档中存在问题，或者你有一个关于新内容的想法，可以考虑 +提出一个问题（issue）。你只需要具有 [GitHub 账号](https://github.com/join)和 Web +浏览器就可以完成这件事。 + +在大多数情况下，Kubernetes 文档的新工作都是开始于 GitHub 上的某个问题。 +Kubernetes 贡献者会审阅这些问题并根据需要对其分类、打标签。 +接下来，你或者别的 Kubernetes 社区成员就可以发起一个带有变更的拉取请求， +以解决这一问题。 + +<!-- body --> + +<!-- +## Opening an issue + +If you want to suggest improvements to existing content, or notice an error, then open an issue. + +1. Go to the bottom of the page and click the **Create an Issue** button. This redirects you + to a GitHub issue page pre-populated with some headers. +2. Describe the issue or suggestion for improvement. Provide as many details as you can. +3. Click **Submit new issue**. + +After submitting, check in on your issue occasionally or turn on GitHub notifications. +Reviewers and other community members might ask questions before +they can take action on your issue. +--> +## 创建问题 {#opening-an-issue} + +如果你希望就改进已有内容提出建议，或者在文档中发现了错误，请创建一个问题（issue）。 + +1. 滚动到页面底部，点击“报告问题”按钮。浏览器会重定向到一个 GitHub 问题页面，其中 + 包含了一些预先填充的内容。 +1. 请描述遇到的问题或关于改进的建议。尽可能提供细节信息。 +1. 点击 **提交新问题**. + +提交之后，偶尔查看一下你所提交的问题，或者开启 GitHub 通知。 +评审人（reviewers）和其他社区成员可能在针对所提问题采取行动之前，问一些问题。 + +<!-- +## Suggesting new content + +If you have an idea for new content, but you aren't sure where it should go, you can +still file an issue. Either: + +- Choose an existing page in the section you think the content belongs in and click **Create an issue**. +- Go to [GitHub](https://github.com/kubernetes/website/issues/new/) and file the issue directly. +--> +## 关于新内容的建议 + +如果你对新内容有想法，但是你有不确定这些内容应该放在哪里，你仍可以提出问题。 + +- 在预期的节区中选择一个现有页面，点击 **创建 issue**. +- 前往 [GitHub Issues 页面](https://github.com/kubernetes/website/issues/new/)， + 直接记录问题。 + +<!-- +## How to file great issues + +Keep the following in mind when filing an issue: + +- Provide a clear issue description. Describe what specifically is missing, out of date, + wrong, or needs improvement. +- Explain the specific impact the issue has on users. +- Limit the scope of a given issue to a reasonable unit of work. For problems + with a large scope, break them down into smaller issues. For example, "Fix the security docs" + is too broad, but "Add details to the 'Restricting network access' topic" is specific enough + to be actionable. +- Search the existing issues to see if there's anything related or similar to the + new issue. +- If the new issue relates to another issue or pull request, refer to it + either by its full URL or by the issue or pull request number prefixed + with a `#` character. For example, `Introduced by #987654`. +- Follow the [Code of Conduct](/community/code-of-conduct/). Respect your +fellow contributors. For example, "The docs are terrible" is not + helpful or polite feedback. +--> + +## 如何更好地记录问题 + +在记录问题时，请注意以下事项： + +- 提供问题的清晰描述，描述具体缺失的内容、过期的内容、错误的内容或者需要改进的文字。 +- 解释该问题对用户的特定影响。 +- 将给定问题的范围限定在一个工作单位范围内。如果问题牵涉的领域较大，可以将其分解为多个 + 小一点的问题。例如："Fix the security docs" 是一个过于宽泛的问题，而 + "Add details to the 'Restricting network access' topic" + 就是一个足够具体的、可操作的问题。 +- 搜索现有问题的列表，查看是否已经有相关的或者类似的问题已被记录。 +- 如果新问题与某其他问题或 PR 有关联，可以使用其完整 URL 或带 `#` 字符的 PR 编号 + 来引用之。例如：`Introduced by #987654`。 +- 遵从[行为准则](/community/code-of-conduct/)。尊重同行贡献者。 + 例如，"The docs are terrible" 就是无用且无礼的反馈。 + diff --git a/content/zh/docs/home/_index.md b/content/zh/docs/home/_index.md index 9106ce3727..d0e81e59d9 100644 --- a/content/zh/docs/home/_index.md +++ b/content/zh/docs/home/_index.md @@ -13,47 +13,59 @@ menu: title: "文档" weight: 20 post: > - <p>通过演练，示例和参考文档了解如何使用 Kubernetes。你甚至可以<a href="/editdocs/" data-auto-burger-exclude>帮助贡献文档</a>！</p> -overview: > - <!-- Kubernetes is an open source container orchestration engine for automating deployment, scaling, and management of containerized applications. The open source project is hosted by the Cloud Native Computing Foundation (<a href="https://www.cncf.io/about">CNCF</a>). --> - Kubernetes 是一个开源容器编排引擎，用于容器化应用的自动化部署、扩展和管理。该项目托管在 <a href="https://www.cncf.io/about">CNCF</a>。 -<!-- cards: -- name: concepts - title: "Understand the basics" - description: "Learn about Kubernetes and its fundamental concepts." - button: "Learn Concepts" - button_path: "/docs/concepts" -- name: tutorials - title: "Try Kubernetes" - description: "Follow tutorials to learn how to deploy applications in Kubernetes." - button: "View Tutorials" - button_path: "/docs/tutorials" -- name: setup - title: "Set up a cluster" - description: "Get Kubernetes running based on your resources and needs." - button: "Set up Kubernetes" - button_path: "/docs/setup" -- name: tasks - title: "Learn how to use Kubernetes" - description: "Look up common tasks and how to perform them using a short sequence of steps." - button: "View Tasks" - button_path: "/docs/tasks" -- name: reference - title: Look up reference information - description: Browse terminology, command line syntax, API resource types, and setup tool documentation. - button: View Reference - button_path: /docs/reference -- name: contribute - title: Contribute to the docs - description: Anyone can contribute, whether you’re new to the project or you’ve been around a long time. - button: Contribute to the docs - button_path: /docs/contribute -- name: release-notes - title: Release Notes - description: If you are installing Kubernetes or upgrading to the newest version, refer to the current release notes. -- name: about - title: About the documentation - description: This website contains documentation for the current and previous 4 versions of Kubernetes. --> + <p>通过概念、教程和参考文档了解如何使用 Kubernetes。你甚至可以<a href="/editdocs/" data-auto-burger-exclude>帮助贡献文档</a>！</p> +# description: > +# Kubernetes is an open source container orchestration engine for automating deployment, scaling, and management of containerized applications. The open source project is hosted by the Cloud Native Computing Foundation. +description: > + Kubernetes 是一个开源的容器编排引擎，用来对容器化应用进行自动部署、 扩缩和管理。此开源项目由云原生计算基金会（CNCF）托管。 +# overview: +# Kubernetes is an open source container orchestration engine for automating deployment, scaling, and management of containerized applications. The open source project is hosted by the Cloud Native Computing Foundation (<a href="https://www.cncf.io/about">CNCF</a>). +overview: + Kubernetes 是一个开源的容器编排引擎，用来对容器化应用进行自动化部署、 扩缩和管理。该项目托管在 <a href="https://www.cncf.io/about">CNCF</a>。 +# cards: +# - name: concepts +# title: "Understand the basics" +# description: "Learn about Kubernetes and its fundamental concepts." +# button: "Learn Concepts" +# button_path: "/docs/concepts" +# - name: tutorials +# title: "Try Kubernetes" +# description: "Follow tutorials to learn how to deploy applications in Kubernetes." +# button: "View Tutorials" +# button_path: "/docs/tutorials" +# - name: setup +# title: "Set up a cluster" +# description: "Get Kubernetes running based on your resources and needs." +# button: "Set up Kubernetes" +# button_path: "/docs/setup" +# - name: tasks +# title: "Learn how to use Kubernetes" +# description: "Look up common tasks and how to perform them using a short sequence of steps." +# button: "View Tasks" +# button_path: "/docs/tasks" +# - name: training +# title: "Training" +# description: "Get certified in Kubernetes and make your cloud native projects successful!" +# button: "View training" +# button_path: "/training" +# - name: reference +# title: Look up reference information +# description: Browse terminology, command line syntax, API resource types, and setup tool documentation. +# button: View Reference +# button_path: /docs/reference +# - name: contribute +# title: Contribute to the docs +# description: Anyone can contribute, whether you’re new to the project or you’ve been around a long time. +# button: Contribute to the docs +# button_path: /docs/contribute +# - name: release-notes +# title: Release Notes +# description: If you are installing Kubernetes or upgrading to the newest version, refer to the current release notes. +# button: "Download Kubernetes" +# button_path: "/zh/docs/setup/release/notes" +# - name: about +# title: About the documentation +# description: This website contains documentation for the current and previous 4 versions of Kubernetes. cards: - name: concepts title: "了解基本知识" @@ -75,20 +87,27 @@ cards: description: "查看常见任务以及如何使用简单步骤执行它们。" button: "查看任务" button_path: "/zh/docs/tasks" +- name: training + title: "培训" + description: "通过 Kubernetes 认证，助你的云原生项目成功！" + button: "查看培训" + button_path: "/zh/training" - name: reference - title: 参考 - description: 术语、命令行语法、API 资源类型和设置工具文档。 + title: 查阅参考信息 + description: 浏览术语、命令行语法、API 资源类型和安装工具文档。 button: 查看参考 button_path: /zh/docs/reference - name: contribute - title: 为该文档作出贡献 + title: 为文档作贡献 description: 任何人，无论对该项目熟悉与否，都能贡献自己的力量。 - button: 参与贡献 + button: 为文档作贡献 button_path: /zh/docs/contribute -- name: download - title: 下载 Kubernetes - description: 如果你正在安装或升级 Kubernetes 的话，最好参考最新的发行版说明。 +- name: release-notes + title: 发布说明 + description: 如果你正在安装或升级 Kubernetes，最好参考最新的发布说明。 + button: "下载 Kubernetes" + button_path: "/zh/docs/setup/release/notes" - name: about title: 关于文档 - description: 该网站包含了当前版本以及前 4 个版本的 Kubernetes 文档。 + description: 本网站包含了当前及前 4 个版本的 Kubernetes 文档。 --- diff --git a/content/zh/docs/reference/_index.md b/content/zh/docs/reference/_index.md index 2c49c689d1..64091816a7 100644 --- a/content/zh/docs/reference/_index.md +++ b/content/zh/docs/reference/_index.md @@ -7,7 +7,6 @@ content_type: concept --- <!-- ---- title: Reference approvers: - chenopis @@ -15,7 +14,6 @@ linkTitle: "Reference" main_menu: true weight: 70 content_type: concept ---- --> <!-- overview --> @@ -25,20 +23,8 @@ This section of the Kubernetes documentation contains references. --> 这是 Kubernetes 文档的参考部分。 - - <!-- body --> -## API 参考 - -* [Kubernetes API 概述](/docs/reference/using-api/api-overview/) - Kubernetes API 概述。 -* Kubernetes API 版本 - * [1.17](/docs/reference/generated/kubernetes-api/v1.17/) - * [1.16](/docs/reference/generated/kubernetes-api/v1.16/) - * [1.15](/docs/reference/generated/kubernetes-api/v1.15/) - * [1.14](/docs/reference/generated/kubernetes-api/v1.14/) - * [1.13](/docs/reference/generated/kubernetes-api/v1.13/) - <!-- ## API Reference @@ -50,16 +36,15 @@ This section of the Kubernetes documentation contains references. * [1.14](/docs/reference/generated/kubernetes-api/v1.14/) * [1.13](/docs/reference/generated/kubernetes-api/v1.13/) --> +## API 参考 -## API 客户端库 - -如果您需要通过编程语言调用 Kubernetes API，您可以使用 -[客户端库](/docs/reference/using-api/client-libraries/)。以下是官方支持的客户端库： - -- [Kubernetes Go 语言客户端库](https://github.com/kubernetes/client-go/) -- [Kubernetes Python 语言客户端库](https://github.com/kubernetes-client/python) -- [Kubernetes Java 语言客户端库](https://github.com/kubernetes-client/java) -- [Kubernetes JavaScript 语言客户端库](https://github.com/kubernetes-client/javascript) +* [Kubernetes API 概述](/docs/reference/using-api/api-overview/) - Kubernetes API 概述。 +* Kubernetes API 版本 + * [1.17](/docs/reference/generated/kubernetes-api/v1.17/) + * [1.16](/docs/reference/generated/kubernetes-api/v1.16/) + * [1.15](/docs/reference/generated/kubernetes-api/v1.15/) + * [1.14](/docs/reference/generated/kubernetes-api/v1.14/) + * [1.13](/docs/reference/generated/kubernetes-api/v1.13/) <!-- ## API Client Libraries @@ -73,13 +58,15 @@ client libraries: - [Kubernetes Java client library](https://github.com/kubernetes-client/java) - [Kubernetes JavaScript client library](https://github.com/kubernetes-client/javascript) --> +## API 客户端库 -## CLI 参考 +如果您需要通过编程语言调用 Kubernetes API，您可以使用 +[客户端库](/docs/reference/using-api/client-libraries/)。以下是官方支持的客户端库： -* [kubectl](/docs/user-guide/kubectl-overview) - 主要的 CLI 工具，用于运行命令和管理 Kubernetes 集群。 - * [JSONPath](/docs/user-guide/jsonpath/) - 通过 kubectl 使用 [JSONPath 表达式](http://goessner.net/articles/JsonPath/) 的语法指南。 -* [kubeadm](/docs/admin/kubeadm/) - 此 CLI 工具可轻松配置安全的 Kubernetes 集群。 -* [kubefed](/docs/admin/kubefed/) - 此 CLI 工具可帮助您管理集群联邦。 +- [Kubernetes Go 语言客户端库](https://github.com/kubernetes/client-go/) +- [Kubernetes Python 语言客户端库](https://github.com/kubernetes-client/python) +- [Kubernetes Java 语言客户端库](https://github.com/kubernetes-client/java) +- [Kubernetes JavaScript 语言客户端库](https://github.com/kubernetes-client/javascript) <!-- ## CLI Reference @@ -89,16 +76,12 @@ client libraries: * [kubeadm](/docs/admin/kubeadm/) - CLI tool to easily provision a secure Kubernetes cluster. * [kubefed](/docs/admin/kubefed/) - CLI tool to help you administrate your federated clusters. --> +## CLI 参考 -## 配置参考 - -* [kubelet](/docs/admin/kubelet/) - 在每个节点上运行的主 *节点代理* 。kubelet 采用一组 PodSpecs 并确保所描述的容器健康地运行。 -* [kube-apiserver](/docs/admin/kube-apiserver/) - REST API，用于验证和配置 API 对象（如 pod，服务，副本控制器）的数据。 -* [kube-controller-manager](/docs/admin/kube-controller-manager/) - 一个守护进程，它嵌入到了 Kubernetes 的附带的核心控制循环。 -* [kube-proxy](/docs/admin/kube-proxy/) - 可以跨一组后端进行简单的 TCP/UDP 流转发或循环 TCP/UDP 转发。 -* [kube-scheduler](/docs/admin/kube-scheduler/) - 一个调度程序，用于管理可用性、性能和容量。 -* [federation-apiserver](/docs/admin/federation-apiserver/) - 联邦集群的 API 服务器。 -* [federation-controller-manager](/docs/admin/federation-controller-manager/) - 一个守护进程，它嵌入到了 Kubernetes 联邦的附带的核心控制循环。 +* [kubectl](/docs/user-guide/kubectl-overview) - 主要的 CLI 工具，用于运行命令和管理 Kubernetes 集群。 + * [JSONPath](/docs/user-guide/jsonpath/) - 通过 kubectl 使用 [JSONPath 表达式](http://goessner.net/articles/JsonPath/) 的语法指南。 +* [kubeadm](/docs/admin/kubeadm/) - 此 CLI 工具可轻松配置安全的 Kubernetes 集群。 +* [kubefed](/docs/admin/kubefed/) - 此 CLI 工具可帮助您管理集群联邦。 <!-- ## Config Reference @@ -108,18 +91,21 @@ client libraries: * [kube-controller-manager](/docs/admin/kube-controller-manager/) - Daemon that embeds the core control loops shipped with Kubernetes. * [kube-proxy](/docs/admin/kube-proxy/) - Can do simple TCP/UDP stream forwarding or round-robin TCP/UDP forwarding across a set of back-ends. * [kube-scheduler](/docs/admin/kube-scheduler/) - Scheduler that manages availability, performance, and capacity. -* [federation-apiserver](/docs/admin/federation-apiserver/) - API server for federated clusters. -* [federation-controller-manager](/docs/admin/federation-controller-manager/) - Daemon that embeds the core control loops shipped with Kubernetes federation. --> +## 配置参考 -## 设计文档 - -Kubernetes 功能的设计文档归档，不妨考虑从 [Kubernetes 架构](https://git.k8s.io/community/contributors/design-proposals/architecture/architecture.md) 和 [Kubernetes 设计概述](https://git.k8s.io/community/contributors/design-proposals)开始阅读。 +* [kubelet](/docs/admin/kubelet/) - 在每个节点上运行的主 *节点代理* 。kubelet 采用一组 PodSpecs 并确保所描述的容器健康地运行。 +* [kube-apiserver](/docs/admin/kube-apiserver/) - REST API，用于验证和配置 API 对象（如 pod，服务，副本控制器）的数据。 +* [kube-controller-manager](/docs/admin/kube-controller-manager/) - 一个守护进程，它嵌入到了 Kubernetes 的附带的核心控制循环。 +* [kube-proxy](/docs/admin/kube-proxy/) - 可以跨一组后端进行简单的 TCP/UDP 流转发或循环 TCP/UDP 转发。 +* [kube-scheduler](/docs/admin/kube-scheduler/) - 一个调度程序，用于管理可用性、性能和容量。 <!-- ## Design Docs An archive of the design docs for Kubernetes functionality. Good starting points are [Kubernetes Architecture](https://git.k8s.io/community/contributors/design-proposals/architecture/architecture.md) and [Kubernetes Design Overview](https://git.k8s.io/community/contributors/design-proposals). - --> +## 设计文档 + +Kubernetes 功能的设计文档归档，不妨考虑从 [Kubernetes 架构](https://git.k8s.io/community/contributors/design-proposals/architecture/architecture.md) 和 [Kubernetes 设计概述](https://git.k8s.io/community/contributors/design-proposals)开始阅读。 diff --git a/content/zh/docs/reference/access-authn-authz/admission-controllers.md b/content/zh/docs/reference/access-authn-authz/admission-controllers.md index 339b3af53d..ac42b47703 100755 --- a/content/zh/docs/reference/access-authn-authz/admission-controllers.md +++ b/content/zh/docs/reference/access-authn-authz/admission-controllers.md @@ -83,7 +83,7 @@ other admission controllers. 最后，除了对对象进行变更外，准入控制器还可以有其它作用：将相关资源作为请求处理的一部分进行变更。 增加使用配额就是一个典型的示例，说明了这样做的必要性。 -此类用法都需要相应的回收或回调过程，因为任一准入控制器都无法确定某个请能否通过所有其它准入控制器。 +此类用法都需要相应的回收或回调过程，因为任一准入控制器都无法确定某个请求能否通过所有其它准入控制器。 <!-- ## Why do I need them? diff --git a/content/zh/docs/reference/access-authn-authz/controlling-access.md b/content/zh/docs/reference/access-authn-authz/controlling-access.md index e181571a5d..edfc3aab85 100644 --- a/content/zh/docs/reference/access-authn-authz/controlling-access.md +++ b/content/zh/docs/reference/access-authn-authz/controlling-access.md @@ -5,7 +5,7 @@ approvers: title: Kubernetes API 访问控制 --- -用户通过 `kubectl`、客户端库或者通过发送 REST 请求[访问 API](/docs/user-guide/accessing-the-cluster)。 用户（自然人）和 [Kubernetes 服务账户](/docs/tasks/configure-pod-container/configure-service-account/) 都可以被授权进行 API 访问。 +用户通过 `kubectl`、客户端库或者通过发送 REST 请求[访问 API](/docs/user-guide/accessing-the-cluster)。 用户和 [Kubernetes 服务账户](/docs/tasks/configure-pod-container/configure-service-account/) 都可以被授权进行 API 访问。 请求到达 API 服务器后会经过几个阶段，具体说明如图： ![Diagram of request handling steps for Kubernetes API request](/images/docs/admin/access-control-overview.svg) diff --git a/content/zh/docs/reference/access-authn-authz/extensible-admission-controllers.md b/content/zh/docs/reference/access-authn-authz/extensible-admission-controllers.md index e1782b0419..4b0fcf0584 100644 --- a/content/zh/docs/reference/access-authn-authz/extensible-admission-controllers.md +++ b/content/zh/docs/reference/access-authn-authz/extensible-admission-controllers.md @@ -631,9 +631,9 @@ Example of a minimal response from a webhook to allow a request: * `allowed`，设置为 `true` 或 `false` <!-- -Example of a minimal response from a webhook to forbid a request: +Example of a minimal response from a webhook to allow a request: --> -Webhook 禁止请求的最简单响应示例： +Webhook 允许请求的最简单响应示例： {{< tabs name="AdmissionReview_response_allow" >}} {{% tab name="admission.k8s.io/v1" %}} diff --git a/content/zh/docs/reference/access-authn-authz/node.md b/content/zh/docs/reference/access-authn-authz/node.md index 2f0654dd00..22573d5e82 100644 --- a/content/zh/docs/reference/access-authn-authz/node.md +++ b/content/zh/docs/reference/access-authn-authz/node.md @@ -43,7 +43,7 @@ Read operations: * endpoints * nodes * pods -* secrets、configmaps、以及绑定到 kubelet 的节点的 pod 的持久卷申领和持久卷 +* secrets、configmaps、pvcs 以及绑定到 kubelet 节点的与 pod 相关的持久卷 <!-- * services diff --git a/content/zh/docs/reference/command-line-tools-reference/kube-controller-manager.md b/content/zh/docs/reference/command-line-tools-reference/kube-controller-manager.md index 448f0de7ae..602d0bdbfa 100644 --- a/content/zh/docs/reference/command-line-tools-reference/kube-controller-manager.md +++ b/content/zh/docs/reference/command-line-tools-reference/kube-controller-manager.md @@ -1,18 +1,10 @@ --- title: kube-controller-manager -notitle: true +content_type: tool-reference +weight: 30 --- -<!-- -## kube-controller-manager ---> -## kube-controller-manager - - -<!-- -### Synopsis ---> -### 概述 +## {{% heading "synopsis" %}} <!-- The Kubernetes controller manager is a daemon that embeds @@ -24,795 +16,1118 @@ current state towards the desired state. Examples of controllers that ship with Kubernetes today are the replication controller, endpoints controller, namespace controller, and serviceaccounts controller. --> -Kubernetes 控制器管理器是一个守护进程，嵌入了 Kubernetes 附带的核心控制循环。 在机器人和自动化的应用中，控制回路是一个永不休止的循环，用于调节系统状态。 在 Kubernetes 中，控制器是一个控制循环，它通过 apiserver 监视集群的共享状态，并尝试进行更改以将当前状态转为所需状态。现今，Kubernetes 自带的控制器包括副本控制器，节点控制器，命名空间控制器和serviceaccounts 控制器。 + +Kubernetes 控制器管理器是一个守护进程，内嵌随 Kubernetes 一起发布的核心控制回路。 +在机器人和自动化的应用中，控制回路是一个永不休止的循环，用于调节系统状态。 +在 Kubernetes 中，每个控制器是一个控制回路，通过 API 服务器监视集群的共享状态， +并尝试进行更改以将当前状态转为期望状态。 +目前，Kubernetes 自带的控制器例子包括副本控制器、节点控制器、命名空间控制器和服务账号控制器等。 ``` kube-controller-manager [flags] ``` +## {{% heading "options" %}} + + <table style="width: 100%; table-layout: fixed;"> +<colgroup> +<col span="1" style="width: 10px;" /> +<col span="1" /> +</colgroup> +<tbody> + +<tr> +<td colspan="2">--add-dir-header</td> +</tr> +<tr> <!-- -### Options +<td></td><td style="line-height: 130%; word-wrap: break-word;">If true, adds the file directory to the header</td> --> -### 选项 - -<table style="width: 100%; table-layout: fixed;"> - <colgroup> - <col span="1" style="width: 10px;" /> - <col span="1" /> - </colgroup> - <tbody> - - <tr> - <td colspan="2">--allocate-node-cidrs</td> - </tr> - <tr> - <td></td><td style="line-height: 130%; word-wrap: break-word;">Should CIDRs for Pods be allocated and set on the cloud provider.</td> - </tr> - - <tr> - <td colspan="2">--alsologtostderr</td> - </tr> - <tr> - <td></td><td style="line-height: 130%; word-wrap: break-word;">log to standard error as well as files</td> - </tr> - - <tr> - <td colspan="2">--attach-detach-reconcile-sync-period duration     Default: 1m0s</td> - </tr> - <tr> - <td></td><td style="line-height: 130%; word-wrap: break-word;">The reconciler sync wait time between volume attach detach. This duration must be larger than one second, and increasing this value from the default may allow for volumes to be mismatched with pods.</td> - </tr> - - <tr> - <td colspan="2">--authentication-kubeconfig string</td> - </tr> - <tr> - <td></td><td style="line-height: 130%; word-wrap: break-word;">kubeconfig file pointing at the 'core' kubernetes server with enough rights to create tokenaccessreviews.authentication.k8s.io. This is optional. If empty, all token requests are considered to be anonymous and no client CA is looked up in the cluster.</td> - </tr> - - <tr> - <td colspan="2">--authentication-skip-lookup</td> - </tr> - <tr> - <td></td><td style="line-height: 130%; word-wrap: break-word;">If false, the authentication-kubeconfig will be used to lookup missing authentication configuration from the cluster.</td> - </tr> - - <tr> - <td colspan="2">--authentication-token-webhook-cache-ttl duration     Default: 10s</td> - </tr> - <tr> - <td></td><td style="line-height: 130%; word-wrap: break-word;">The duration to cache responses from the webhook token authenticator.</td> - </tr> - - <tr> - <td colspan="2">--authentication-tolerate-lookup-failure</td> - </tr> - <tr> - <td></td><td style="line-height: 130%; word-wrap: break-word;">If true, failures to look up missing authentication configuration from the cluster are not considered fatal. Note that this can result in authentication that treats all requests as anonymous.</td> - </tr> - - <tr> - <td colspan="2">--authorization-always-allow-paths stringSlice     Default: [/healthz]</td> - </tr> - <tr> - <td></td><td style="line-height: 130%; word-wrap: break-word;">A list of HTTP paths to skip during authorization, i.e. these are authorized without contacting the 'core' kubernetes server.</td> - </tr> - - <tr> - <td colspan="2">--authorization-kubeconfig string</td> - </tr> - <tr> - <td></td><td style="line-height: 130%; word-wrap: break-word;">kubeconfig file pointing at the 'core' kubernetes server with enough rights to create subjectaccessreviews.authorization.k8s.io. This is optional. If empty, all requests not skipped by authorization are forbidden.</td> - </tr> - - <tr> - <td colspan="2">--authorization-webhook-cache-authorized-ttl duration     Default: 10s</td> - </tr> - <tr> - <td></td><td style="line-height: 130%; word-wrap: break-word;">The duration to cache 'authorized' responses from the webhook authorizer.</td> - </tr> - - <tr> - <td colspan="2">--authorization-webhook-cache-unauthorized-ttl duration     Default: 10s</td> - </tr> - <tr> - <td></td><td style="line-height: 130%; word-wrap: break-word;">The duration to cache 'unauthorized' responses from the webhook authorizer.</td> - </tr> - - <tr> - <td colspan="2">--azure-container-registry-config string</td> - </tr> - <tr> - <td></td><td style="line-height: 130%; word-wrap: break-word;">Path to the file containing Azure container registry configuration information.</td> - </tr> - - <tr> - <td colspan="2">--bind-address ip     Default: 0.0.0.0</td> - </tr> - <tr> - <td></td><td style="line-height: 130%; word-wrap: break-word;">The IP address on which to listen for the --secure-port port. The associated interface(s) must be reachable by the rest of the cluster, and by CLI/web clients. If blank, all interfaces will be used (0.0.0.0 for all IPv4 interfaces and :: for all IPv6 interfaces).</td> - </tr> - - <tr> - <td colspan="2">--cert-dir string</td> - </tr> - <tr> - <td></td><td style="line-height: 130%; word-wrap: break-word;">The directory where the TLS certs are located. If --tls-cert-file and --tls-private-key-file are provided, this flag will be ignored.</td> - </tr> - - <tr> - <td colspan="2">--cidr-allocator-type string     Default: "RangeAllocator"</td> - </tr> - <tr> - <td></td><td style="line-height: 130%; word-wrap: break-word;">Type of CIDR allocator to use</td> - </tr> - - <tr> - <td colspan="2">--client-ca-file string</td> - </tr> - <tr> - <td></td><td style="line-height: 130%; word-wrap: break-word;">If set, any request presenting a client certificate signed by one of the authorities in the client-ca-file is authenticated with an identity corresponding to the CommonName of the client certificate.</td> - </tr> - - <tr> - <td colspan="2">--cloud-config string</td> - </tr> - <tr> - <td></td><td style="line-height: 130%; word-wrap: break-word;">The path to the cloud provider configuration file. Empty string for no configuration file.</td> - </tr> - - <tr> - <td colspan="2">--cloud-provider string</td> - </tr> - <tr> - <td></td><td style="line-height: 130%; word-wrap: break-word;">The provider for cloud services. Empty string for no provider.</td> - </tr> - - <tr> - <td colspan="2">--cluster-cidr string</td> - </tr> - <tr> - <td></td><td style="line-height: 130%; word-wrap: break-word;">CIDR Range for Pods in cluster. Requires --allocate-node-cidrs to be true</td> - </tr> - - <tr> - <td colspan="2">--cluster-name string     Default: "kubernetes"</td> - </tr> - <tr> - <td></td><td style="line-height: 130%; word-wrap: break-word;">The instance prefix for the cluster.</td> - </tr> - - <tr> - <td colspan="2">--cluster-signing-cert-file string     Default: "/etc/kubernetes/ca/ca.pem"</td> - </tr> - <tr> - <td></td><td style="line-height: 130%; word-wrap: break-word;">Filename containing a PEM-encoded X509 CA certificate used to issue cluster-scoped certificates</td> - </tr> - - <tr> - <td colspan="2">--cluster-signing-key-file string     Default: "/etc/kubernetes/ca/ca.key"</td> - </tr> - <tr> - <td></td><td style="line-height: 130%; word-wrap: break-word;">Filename containing a PEM-encoded RSA or ECDSA private key used to sign cluster-scoped certificates</td> - </tr> - - <tr> - <td colspan="2">--concurrent-deployment-syncs int32     Default: 5</td> - </tr> - <tr> - <td></td><td style="line-height: 130%; word-wrap: break-word;">The number of deployment objects that are allowed to sync concurrently. Larger number = more responsive deployments, but more CPU (and network) load</td> - </tr> - - <tr> - <td colspan="2">--concurrent-endpoint-syncs int32     Default: 5</td> - </tr> - <tr> - <td></td><td style="line-height: 130%; word-wrap: break-word;">The number of endpoint syncing operations that will be done concurrently. Larger number = faster endpoint updating, but more CPU (and network) load</td> - </tr> - - <tr> - <td colspan="2">--concurrent-gc-syncs int32     Default: 20</td> - </tr> - <tr> - <td></td><td style="line-height: 130%; word-wrap: break-word;">The number of garbage collector workers that are allowed to sync concurrently.</td> - </tr> - - <tr> - <td colspan="2">--concurrent-namespace-syncs int32     Default: 10</td> - </tr> - <tr> - <td></td><td style="line-height: 130%; word-wrap: break-word;">The number of namespace objects that are allowed to sync concurrently. Larger number = more responsive namespace termination, but more CPU (and network) load</td> - </tr> - - <tr> - <td colspan="2">--concurrent-replicaset-syncs int32     Default: 5</td> - </tr> - <tr> - <td></td><td style="line-height: 130%; word-wrap: break-word;">The number of replica sets that are allowed to sync concurrently. Larger number = more responsive replica management, but more CPU (and network) load</td> - </tr> - - <tr> - <td colspan="2">--concurrent-resource-quota-syncs int32     Default: 5</td> - </tr> - <tr> - <td></td><td style="line-height: 130%; word-wrap: break-word;">The number of resource quotas that are allowed to sync concurrently. Larger number = more responsive quota management, but more CPU (and network) load</td> - </tr> - - <tr> - <td colspan="2">--concurrent-service-syncs int32     Default: 1</td> - </tr> - <tr> - <td></td><td style="line-height: 130%; word-wrap: break-word;">The number of services that are allowed to sync concurrently. Larger number = more responsive service management, but more CPU (and network) load</td> - </tr> - - <tr> - <td colspan="2">--concurrent-serviceaccount-token-syncs int32     Default: 5</td> - </tr> - <tr> - <td></td><td style="line-height: 130%; word-wrap: break-word;">The number of service account token objects that are allowed to sync concurrently. Larger number = more responsive token generation, but more CPU (and network) load</td> - </tr> - - <tr> - <td colspan="2">--concurrent-ttl-after-finished-syncs int32     Default: 5</td> - </tr> - <tr> - <td></td><td style="line-height: 130%; word-wrap: break-word;">The number of TTL-after-finished controller workers that are allowed to sync concurrently.</td> - </tr> - - <tr> - <td colspan="2">--concurrent_rc_syncs int32     Default: 5</td> - </tr> - <tr> - <td></td><td style="line-height: 130%; word-wrap: break-word;">The number of replication controllers that are allowed to sync concurrently. Larger number = more responsive replica management, but more CPU (and network) load</td> - </tr> - - <tr> - <td colspan="2">--configure-cloud-routes     Default: true</td> - </tr> - <tr> - <td></td><td style="line-height: 130%; word-wrap: break-word;">Should CIDRs allocated by allocate-node-cidrs be configured on the cloud provider.</td> - </tr> - - <tr> - <td colspan="2">--contention-profiling</td> - </tr> - <tr> - <td></td><td style="line-height: 130%; word-wrap: break-word;">Enable lock contention profiling, if profiling is enabled</td> - </tr> - - <tr> - <td colspan="2">--controller-start-interval duration</td> - </tr> - <tr> - <td></td><td style="line-height: 130%; word-wrap: break-word;">Interval between starting controller managers.</td> - </tr> - - <tr> - <td colspan="2">--controllers stringSlice     Default: [*]</td> - </tr> - <tr> - <td></td><td style="line-height: 130%; word-wrap: break-word;">A list of controllers to enable. '*' enables all on-by-default controllers, 'foo' enables the controller named 'foo', '-foo' disables the controller named 'foo'.<br/>All controllers: attachdetach, bootstrapsigner, cloud-node-lifecycle, clusterrole-aggregation, cronjob, csrapproving, csrcleaner, csrsigning, daemonset, deployment, disruption, endpoint, garbagecollector, horizontalpodautoscaling, job, namespace, nodeipam, nodelifecycle, persistentvolume-binder, persistentvolume-expander, podgc, pv-protection, pvc-protection, replicaset, replicationcontroller, resourcequota, root-ca-cert-publisher, route, service, serviceaccount, serviceaccount-token, statefulset, tokencleaner, ttl, ttl-after-finished<br/>Disabled-by-default controllers: bootstrapsigner, tokencleaner</td> - </tr> - - <tr> - <td colspan="2">--deployment-controller-sync-period duration     Default: 30s</td> - </tr> - <tr> - <td></td><td style="line-height: 130%; word-wrap: break-word;">Period for syncing the deployments.</td> - </tr> - - <tr> - <td colspan="2">--disable-attach-detach-reconcile-sync</td> - </tr> - <tr> - <td></td><td style="line-height: 130%; word-wrap: break-word;">Disable volume attach detach reconciler sync. Disabling this may cause volumes to be mismatched with pods. Use wisely.</td> - </tr> - - <tr> - <td colspan="2">--enable-dynamic-provisioning     Default: true</td> - </tr> - <tr> - <td></td><td style="line-height: 130%; word-wrap: break-word;">Enable dynamic provisioning for environments that support it.</td> - </tr> - - <tr> - <td colspan="2">--enable-garbage-collector     Default: true</td> - </tr> - <tr> - <td></td><td style="line-height: 130%; word-wrap: break-word;">Enables the generic garbage collector. MUST be synced with the corresponding flag of the kube-apiserver.</td> - </tr> - - <tr> - <td colspan="2">--enable-hostpath-provisioner</td> - </tr> - <tr> - <td></td><td style="line-height: 130%; word-wrap: break-word;">Enable HostPath PV provisioning when running without a cloud provider. This allows testing and development of provisioning features. HostPath provisioning is not supported in any way, won't work in a multi-node cluster, and should not be used for anything other than testing or development.</td> - </tr> - - <tr> - <td colspan="2">--enable-taint-manager     Default: true</td> - </tr> - <tr> - <td></td><td style="line-height: 130%; word-wrap: break-word;">WARNING: Beta feature. If set to true enables NoExecute Taints and will evict all not-tolerating Pod running on Nodes tainted with this kind of Taints.</td> - </tr> - - <tr> - <td colspan="2">--experimental-cluster-signing-duration duration     Default: 8760h0m0s</td> - </tr> - <tr> - <td></td><td style="line-height: 130%; word-wrap: break-word;">The length of duration signed certificates will be given.</td> - </tr> - - <tr> - <td colspan="2">--external-cloud-volume-plugin string</td> - </tr> - <tr> - <td></td><td style="line-height: 130%; word-wrap: break-word;">The plugin to use when cloud provider is set to external. Can be empty, should only be set when cloud-provider is external. Currently used to allow node and volume controllers to work for in tree cloud providers.</td> - </tr> - - <tr> - <td colspan="2">--feature-gates mapStringBool</td> - </tr> - <tr> - <td></td><td style="line-height: 130%; word-wrap: break-word;">A set of key=value pairs that describe feature gates for alpha/experimental features. Options are:<br/>APIListChunking=true|false (BETA - default=true)<br/>APIResponseCompression=true|false (ALPHA - default=false)<br/>AllAlpha=true|false (ALPHA - default=false)<br/>AppArmor=true|false (BETA - default=true)<br/>AttachVolumeLimit=true|false (BETA - default=true)<br/>BalanceAttachedNodeVolumes=true|false (ALPHA - default=false)<br/>BlockVolume=true|false (BETA - default=true)<br/>BoundServiceAccountTokenVolume=true|false (ALPHA - default=false)<br/>CPUManager=true|false (BETA - default=true)<br/>CRIContainerLogRotation=true|false (BETA - default=true)<br/>CSIBlockVolume=true|false (BETA - default=true)<br/>CSIDriverRegistry=true|false (BETA - default=true)<br/>CSIInlineVolume=true|false (ALPHA - default=false)<br/>CSIMigration=true|false (ALPHA - default=false)<br/>CSIMigrationAWS=true|false (ALPHA - default=false)<br/>CSIMigrationGCE=true|false (ALPHA - default=false)<br/>CSIMigrationOpenStack=true|false (ALPHA - default=false)<br/>CSINodeInfo=true|false (BETA - default=true)<br/>CustomCPUCFSQuotaPeriod=true|false (ALPHA - default=false)<br/>CustomResourcePublishOpenAPI=true|false (ALPHA - default=false)<br/>CustomResourceSubresources=true|false (BETA - default=true)<br/>CustomResourceValidation=true|false (BETA - default=true)<br/>CustomResourceWebhookConversion=true|false (ALPHA - default=false)<br/>DebugContainers=true|false (ALPHA - default=false)<br/>DevicePlugins=true|false (BETA - default=true)<br/>DryRun=true|false (BETA - default=true)<br/>DynamicAuditing=true|false (ALPHA - default=false)<br/>DynamicKubeletConfig=true|false (BETA - default=true)<br/>ExpandCSIVolumes=true|false (ALPHA - default=false)<br/>ExpandInUsePersistentVolumes=true|false (ALPHA - default=false)<br/>ExpandPersistentVolumes=true|false (BETA - default=true)<br/>ExperimentalCriticalPodAnnotation=true|false (ALPHA - default=false)<br/>ExperimentalHostUserNamespaceDefaulting=true|false (BETA - default=false)<br/>HyperVContainer=true|false (ALPHA - default=false)<br/>KubeletPodResources=true|false (ALPHA - default=false)<br/>LocalStorageCapacityIsolation=true|false (BETA - default=true)<br/>MountContainers=true|false (ALPHA - default=false)<br/>NodeLease=true|false (BETA - default=true)<br/>PodShareProcessNamespace=true|false (BETA - default=true)<br/>ProcMountType=true|false (ALPHA - default=false)<br/>QOSReserved=true|false (ALPHA - default=false)<br/>ResourceLimitsPriorityFunction=true|false (ALPHA - default=false)<br/>ResourceQuotaScopeSelectors=true|false (BETA - default=true)<br/>RotateKubeletClientCertificate=true|false (BETA - default=true)<br/>RotateKubeletServerCertificate=true|false (BETA - default=true)<br/>RunAsGroup=true|false (BETA - default=true)<br/>RuntimeClass=true|false (BETA - default=true)<br/>SCTPSupport=true|false (ALPHA - default=false)<br/>ScheduleDaemonSetPods=true|false (BETA - default=true)<br/>ServerSideApply=true|false (ALPHA - default=false)<br/>ServiceNodeExclusion=true|false (ALPHA - default=false)<br/>StorageVersionHash=true|false (ALPHA - default=false)<br/>StreamingProxyRedirects=true|false (BETA - default=true)<br/>SupportNodePidsLimit=true|false (ALPHA - default=false)<br/>SupportPodPidsLimit=true|false (BETA - default=true)<br/>Sysctls=true|false (BETA - default=true)<br/>TTLAfterFinished=true|false (ALPHA - default=false)<br/>TaintBasedEvictions=true|false (BETA - default=true)<br/>TaintNodesByCondition=true|false (BETA - default=true)<br/>TokenRequest=true|false (BETA - default=true)<br/>TokenRequestProjection=true|false (BETA - default=true)<br/>ValidateProxyRedirects=true|false (BETA - default=true)<br/>VolumeSnapshotDataSource=true|false (ALPHA - default=false)<br/>VolumeSubpathEnvExpansion=true|false (ALPHA - default=false)<br/>WinDSR=true|false (ALPHA - default=false)<br/>WinOverlay=true|false (ALPHA - default=false)<br/>WindowsGMSA=true|false (ALPHA - default=false)</td> - </tr> - - <tr> - <td colspan="2">--flex-volume-plugin-dir string     Default: "/usr/libexec/kubernetes/kubelet-plugins/volume/exec/"</td> - </tr> - <tr> - <td></td><td style="line-height: 130%; word-wrap: break-word;">Full path of the directory in which the flex volume plugin should search for additional third party volume plugins.</td> - </tr> - - <tr> - <td colspan="2">-h, --help</td> - </tr> - <tr> - <td></td><td style="line-height: 130%; word-wrap: break-word;">help for kube-controller-manager</td> - </tr> - - <tr> - <td colspan="2">--horizontal-pod-autoscaler-cpu-initialization-period duration     Default: 5m0s</td> - </tr> - <tr> - <td></td><td style="line-height: 130%; word-wrap: break-word;">The period after pod start when CPU samples might be skipped.</td> - </tr> - - <tr> - <td colspan="2">--horizontal-pod-autoscaler-downscale-stabilization duration     Default: 5m0s</td> - </tr> - <tr> - <td></td><td style="line-height: 130%; word-wrap: break-word;">The period for which autoscaler will look backwards and not scale down below any recommendation it made during that period.</td> - </tr> - - <tr> - <td colspan="2">--horizontal-pod-autoscaler-initial-readiness-delay duration     Default: 30s</td> - </tr> - <tr> - <td></td><td style="line-height: 130%; word-wrap: break-word;">The period after pod start during which readiness changes will be treated as initial readiness.</td> - </tr> - - <tr> - <td colspan="2">--horizontal-pod-autoscaler-sync-period duration     Default: 15s</td> - </tr> - <tr> - <td></td><td style="line-height: 130%; word-wrap: break-word;">The period for syncing the number of pods in horizontal pod autoscaler.</td> - </tr> - - <tr> - <td colspan="2">--horizontal-pod-autoscaler-tolerance float     Default: 0.1</td> - </tr> - <tr> - <td></td><td style="line-height: 130%; word-wrap: break-word;">The minimum change (from 1.0) in the desired-to-actual metrics ratio for the horizontal pod autoscaler to consider scaling.</td> - </tr> - - <tr> - <td colspan="2">--http2-max-streams-per-connection int</td> - </tr> - <tr> - <td></td><td style="line-height: 130%; word-wrap: break-word;">The limit that the server gives to clients for the maximum number of streams in an HTTP/2 connection. Zero means to use golang's default.</td> - </tr> - - <tr> - <td colspan="2">--kube-api-burst int32     Default: 30</td> - </tr> - <tr> - <td></td><td style="line-height: 130%; word-wrap: break-word;">Burst to use while talking with kubernetes apiserver.</td> - </tr> - - <tr> - <td colspan="2">--kube-api-content-type string     Default: "application/vnd.kubernetes.protobuf"</td> - </tr> - <tr> - <td></td><td style="line-height: 130%; word-wrap: break-word;">Content type of requests sent to apiserver.</td> - </tr> - - <tr> - <td colspan="2">--kube-api-qps float32     Default: 20</td> - </tr> - <tr> - <td></td><td style="line-height: 130%; word-wrap: break-word;">QPS to use while talking with kubernetes apiserver.</td> - </tr> - - <tr> - <td colspan="2">--kubeconfig string</td> - </tr> - <tr> - <td></td><td style="line-height: 130%; word-wrap: break-word;">Path to kubeconfig file with authorization and master location information.</td> - </tr> - - <tr> - <td colspan="2">--large-cluster-size-threshold int32     Default: 50</td> - </tr> - <tr> - <td></td><td style="line-height: 130%; word-wrap: break-word;">Number of nodes from which NodeController treats the cluster as large for the eviction logic purposes. --secondary-node-eviction-rate is implicitly overridden to 0 for clusters this size or smaller.</td> - </tr> - - <tr> - <td colspan="2">--leader-elect     Default: true</td> - </tr> - <tr> - <td></td><td style="line-height: 130%; word-wrap: break-word;">Start a leader election client and gain leadership before executing the main loop. Enable this when running replicated components for high availability.</td> - </tr> - - <tr> - <td colspan="2">--leader-elect-lease-duration duration     Default: 15s</td> - </tr> - <tr> - <td></td><td style="line-height: 130%; word-wrap: break-word;">The duration that non-leader candidates will wait after observing a leadership renewal until attempting to acquire leadership of a led but unrenewed leader slot. This is effectively the maximum duration that a leader can be stopped before it is replaced by another candidate. This is only applicable if leader election is enabled.</td> - </tr> - - <tr> - <td colspan="2">--leader-elect-renew-deadline duration     Default: 10s</td> - </tr> - <tr> - <td></td><td style="line-height: 130%; word-wrap: break-word;">The interval between attempts by the acting master to renew a leadership slot before it stops leading. This must be less than or equal to the lease duration. This is only applicable if leader election is enabled.</td> - </tr> - - <tr> - <td colspan="2">--leader-elect-resource-lock endpoints     Default: "endpoints"</td> - </tr> - <tr> - <td></td><td style="line-height: 130%; word-wrap: break-word;">The type of resource object that is used for locking during leader election. Supported options are endpoints (default) and `configmaps`.</td> - </tr> - - <tr> - <td colspan="2">--leader-elect-retry-period duration     Default: 2s</td> - </tr> - <tr> - <td></td><td style="line-height: 130%; word-wrap: break-word;">The duration the clients should wait between attempting acquisition and renewal of a leadership. This is only applicable if leader election is enabled.</td> - </tr> - - <tr> - <td colspan="2">--log-backtrace-at traceLocation     Default: :0</td> - </tr> - <tr> - <td></td><td style="line-height: 130%; word-wrap: break-word;">when logging hits line file:N, emit a stack trace</td> - </tr> - - <tr> - <td colspan="2">--log-dir string</td> - </tr> - <tr> - <td></td><td style="line-height: 130%; word-wrap: break-word;">If non-empty, write log files in this directory</td> - </tr> - - <tr> - <td colspan="2">--log-file string</td> - </tr> - <tr> - <td></td><td style="line-height: 130%; word-wrap: break-word;">If non-empty, use this log file</td> - </tr> - - <tr> - <td colspan="2">--log-flush-frequency duration     Default: 5s</td> - </tr> - <tr> - <td></td><td style="line-height: 130%; word-wrap: break-word;">Maximum number of seconds between log flushes</td> - </tr> - - <tr> - <td colspan="2">--logtostderr     Default: true</td> - </tr> - <tr> - <td></td><td style="line-height: 130%; word-wrap: break-word;">log to standard error instead of files</td> - </tr> - - <tr> - <td colspan="2">--master string</td> - </tr> - <tr> - <td></td><td style="line-height: 130%; word-wrap: break-word;">The address of the Kubernetes API server (overrides any value in kubeconfig).</td> - </tr> - - <tr> - <td colspan="2">--min-resync-period duration     Default: 12h0m0s</td> - </tr> - <tr> - <td></td><td style="line-height: 130%; word-wrap: break-word;">The resync period in reflectors will be random between MinResyncPeriod and 2*MinResyncPeriod.</td> - </tr> - - <tr> - <td colspan="2">--namespace-sync-period duration     Default: 5m0s</td> - </tr> - <tr> - <td></td><td style="line-height: 130%; word-wrap: break-word;">The period for syncing namespace life-cycle updates</td> - </tr> - - <tr> - <td colspan="2">--node-cidr-mask-size int32     Default: 24</td> - </tr> - <tr> - <td></td><td style="line-height: 130%; word-wrap: break-word;">Mask size for node cidr in cluster.</td> - </tr> - - <tr> - <td colspan="2">--node-eviction-rate float32     Default: 0.1</td> - </tr> - <tr> - <td></td><td style="line-height: 130%; word-wrap: break-word;">Number of nodes per second on which pods are deleted in case of node failure when a zone is healthy (see --unhealthy-zone-threshold for definition of healthy/unhealthy). Zone refers to entire cluster in non-multizone clusters.</td> - </tr> - - <tr> - <td colspan="2">--node-monitor-grace-period duration     Default: 40s</td> - </tr> - <tr> - <td></td><td style="line-height: 130%; word-wrap: break-word;">Amount of time which we allow running Node to be unresponsive before marking it unhealthy. Must be N times more than kubelet's nodeStatusUpdateFrequency, where N means number of retries allowed for kubelet to post node status.</td> - </tr> - - <tr> - <td colspan="2">--node-monitor-period duration     Default: 5s</td> - </tr> - <tr> - <td></td><td style="line-height: 130%; word-wrap: break-word;">The period for syncing NodeStatus in NodeController.</td> - </tr> - - <tr> - <td colspan="2">--node-startup-grace-period duration     Default: 1m0s</td> - </tr> - <tr> - <td></td><td style="line-height: 130%; word-wrap: break-word;">Amount of time which we allow starting Node to be unresponsive before marking it unhealthy.</td> - </tr> - - <tr> - <td colspan="2">--pod-eviction-timeout duration     Default: 5m0s</td> - </tr> - <tr> - <td></td><td style="line-height: 130%; word-wrap: break-word;">The grace period for deleting pods on failed nodes.</td> - </tr> - - <tr> - <td colspan="2">--profiling</td> - </tr> - <tr> - <td></td><td style="line-height: 130%; word-wrap: break-word;">Enable profiling via web interface host:port/debug/pprof/</td> - </tr> - - <tr> - <td colspan="2">--pv-recycler-increment-timeout-nfs int32     Default: 30</td> - </tr> - <tr> - <td></td><td style="line-height: 130%; word-wrap: break-word;">the increment of time added per Gi to ActiveDeadlineSeconds for an NFS scrubber pod</td> - </tr> - - <tr> - <td colspan="2">--pv-recycler-minimum-timeout-hostpath int32     Default: 60</td> - </tr> - <tr> - <td></td><td style="line-height: 130%; word-wrap: break-word;">The minimum ActiveDeadlineSeconds to use for a HostPath Recycler pod. This is for development and testing only and will not work in a multi-node cluster.</td> - </tr> - - <tr> - <td colspan="2">--pv-recycler-minimum-timeout-nfs int32     Default: 300</td> - </tr> - <tr> - <td></td><td style="line-height: 130%; word-wrap: break-word;">The minimum ActiveDeadlineSeconds to use for an NFS Recycler pod</td> - </tr> - - <tr> - <td colspan="2">--pv-recycler-pod-template-filepath-hostpath string</td> - </tr> - <tr> - <td></td><td style="line-height: 130%; word-wrap: break-word;">The file path to a pod definition used as a template for HostPath persistent volume recycling. This is for development and testing only and will not work in a multi-node cluster.</td> - </tr> - - <tr> - <td colspan="2">--pv-recycler-pod-template-filepath-nfs string</td> - </tr> - <tr> - <td></td><td style="line-height: 130%; word-wrap: break-word;">The file path to a pod definition used as a template for NFS persistent volume recycling</td> - </tr> - - <tr> - <td colspan="2">--pv-recycler-timeout-increment-hostpath int32     Default: 30</td> - </tr> - <tr> - <td></td><td style="line-height: 130%; word-wrap: break-word;">the increment of time added per Gi to ActiveDeadlineSeconds for a HostPath scrubber pod. This is for development and testing only and will not work in a multi-node cluster.</td> - </tr> - - <tr> - <td colspan="2">--pvclaimbinder-sync-period duration     Default: 15s</td> - </tr> - <tr> - <td></td><td style="line-height: 130%; word-wrap: break-word;">The period for syncing persistent volumes and persistent volume claims</td> - </tr> - - <tr> - <td colspan="2">--requestheader-allowed-names stringSlice</td> - </tr> - <tr> - <td></td><td style="line-height: 130%; word-wrap: break-word;">List of client certificate common names to allow to provide usernames in headers specified by --requestheader-username-headers. If empty, any client certificate validated by the authorities in --requestheader-client-ca-file is allowed.</td> - </tr> - - <tr> - <td colspan="2">--requestheader-client-ca-file string</td> - </tr> - <tr> - <td></td><td style="line-height: 130%; word-wrap: break-word;">Root certificate bundle to use to verify client certificates on incoming requests before trusting usernames in headers specified by --requestheader-username-headers. WARNING: generally do not depend on authorization being already done for incoming requests.</td> - </tr> - - <tr> - <td colspan="2">--requestheader-extra-headers-prefix stringSlice     Default: [x-remote-extra-]</td> - </tr> - <tr> - <td></td><td style="line-height: 130%; word-wrap: break-word;">List of request header prefixes to inspect. X-Remote-Extra- is suggested.</td> - </tr> - - <tr> - <td colspan="2">--requestheader-group-headers stringSlice     Default: [x-remote-group]</td> - </tr> - <tr> - <td></td><td style="line-height: 130%; word-wrap: break-word;">List of request headers to inspect for groups. X-Remote-Group is suggested.</td> - </tr> - - <tr> - <td colspan="2">--requestheader-username-headers stringSlice     Default: [x-remote-user]</td> - </tr> - <tr> - <td></td><td style="line-height: 130%; word-wrap: break-word;">List of request headers to inspect for usernames. X-Remote-User is common.</td> - </tr> - - <tr> - <td colspan="2">--resource-quota-sync-period duration     Default: 5m0s</td> - </tr> - <tr> - <td></td><td style="line-height: 130%; word-wrap: break-word;">The period for syncing quota usage status in the system</td> - </tr> - - <tr> - <td colspan="2">--root-ca-file string</td> - </tr> - <tr> - <td></td><td style="line-height: 130%; word-wrap: break-word;">If set, this root certificate authority will be included in service account's token secret. This must be a valid PEM-encoded CA bundle.</td> - </tr> - - <tr> - <td colspan="2">--route-reconciliation-period duration     Default: 10s</td> - </tr> - <tr> - <td></td><td style="line-height: 130%; word-wrap: break-word;">The period for reconciling routes created for Nodes by cloud provider.</td> - </tr> - - <tr> - <td colspan="2">--secondary-node-eviction-rate float32     Default: 0.01</td> - </tr> - <tr> - <td></td><td style="line-height: 130%; word-wrap: break-word;">Number of nodes per second on which pods are deleted in case of node failure when a zone is unhealthy (see --unhealthy-zone-threshold for definition of healthy/unhealthy). Zone refers to entire cluster in non-multizone clusters. This value is implicitly overridden to 0 if the cluster size is smaller than --large-cluster-size-threshold.</td> - </tr> - - <tr> - <td colspan="2">--secure-port int     Default: 10257</td> - </tr> - <tr> - <td></td><td style="line-height: 130%; word-wrap: break-word;">The port on which to serve HTTPS with authentication and authorization.If 0, don't serve HTTPS at all.</td> - </tr> - - <tr> - <td colspan="2">--service-account-private-key-file string</td> - </tr> - <tr> - <td></td><td style="line-height: 130%; word-wrap: break-word;">Filename containing a PEM-encoded private RSA or ECDSA key used to sign service account tokens.</td> - </tr> - - <tr> - <td colspan="2">--service-cluster-ip-range string</td> - </tr> - <tr> - <td></td><td style="line-height: 130%; word-wrap: break-word;">CIDR Range for Services in cluster. Requires --allocate-node-cidrs to be true</td> - </tr> - - <tr> - <td colspan="2">--skip-headers</td> - </tr> - <tr> - <td></td><td style="line-height: 130%; word-wrap: break-word;">If true, avoid header prefixes in the log messages</td> - </tr> - - <tr> - <td colspan="2">--stderrthreshold severity     Default: 2</td> - </tr> - <tr> - <td></td><td style="line-height: 130%; word-wrap: break-word;">logs at or above this threshold go to stderr</td> - </tr> - - <tr> - <td colspan="2">--terminated-pod-gc-threshold int32     Default: 12500</td> - </tr> - <tr> - <td></td><td style="line-height: 130%; word-wrap: break-word;">Number of terminated pods that can exist before the terminated pod garbage collector starts deleting terminated pods. If <= 0, the terminated pod garbage collector is disabled.</td> - </tr> - - <tr> - <td colspan="2">--tls-cert-file string</td> - </tr> - <tr> - <td></td><td style="line-height: 130%; word-wrap: break-word;">File containing the default x509 Certificate for HTTPS. (CA cert, if any, concatenated after server cert). If HTTPS serving is enabled, and --tls-cert-file and --tls-private-key-file are not provided, a self-signed certificate and key are generated for the public address and saved to the directory specified by --cert-dir.</td> - </tr> - - <tr> - <td colspan="2">--tls-cipher-suites stringSlice</td> - </tr> - <tr> - <td></td><td style="line-height: 130%; word-wrap: break-word;">Comma-separated list of cipher suites for the server. If omitted, the default Go cipher suites will be use. Possible values: TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA,TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256,TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA,TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384,TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305,TLS_ECDHE_ECDSA_WITH_RC4_128_SHA,TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA,TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA,TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256,TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA,TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384,TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305,TLS_ECDHE_RSA_WITH_RC4_128_SHA,TLS_RSA_WITH_3DES_EDE_CBC_SHA,TLS_RSA_WITH_AES_128_CBC_SHA,TLS_RSA_WITH_AES_128_CBC_SHA256,TLS_RSA_WITH_AES_128_GCM_SHA256,TLS_RSA_WITH_AES_256_CBC_SHA,TLS_RSA_WITH_AES_256_GCM_SHA384,TLS_RSA_WITH_RC4_128_SHA</td> - </tr> - - <tr> - <td colspan="2">--tls-min-version string</td> - </tr> - <tr> - <td></td><td style="line-height: 130%; word-wrap: break-word;">Minimum TLS version supported. Possible values: VersionTLS10, VersionTLS11, VersionTLS12</td> - </tr> - - <tr> - <td colspan="2">--tls-private-key-file string</td> - </tr> - <tr> - <td></td><td style="line-height: 130%; word-wrap: break-word;">File containing the default x509 private key matching --tls-cert-file.</td> - </tr> - - <tr> - <td colspan="2">--tls-sni-cert-key namedCertKey     Default: []</td> - </tr> - <tr> - <td></td><td style="line-height: 130%; word-wrap: break-word;">A pair of x509 certificate and private key file paths, optionally suffixed with a list of domain patterns which are fully qualified domain names, possibly with prefixed wildcard segments. If no domain patterns are provided, the names of the certificate are extracted. Non-wildcard matches trump over wildcard matches, explicit domain patterns trump over extracted names. For multiple key/certificate pairs, use the --tls-sni-cert-key multiple times. Examples: "example.crt,example.key" or "foo.crt,foo.key:*.foo.com,foo.com".</td> - </tr> - - <tr> - <td colspan="2">--unhealthy-zone-threshold float32     Default: 0.55</td> - </tr> - <tr> - <td></td><td style="line-height: 130%; word-wrap: break-word;">Fraction of Nodes in a zone which needs to be not Ready (minimum 3) for zone to be treated as unhealthy. </td> - </tr> - - <tr> - <td colspan="2">--use-service-account-credentials</td> - </tr> - <tr> - <td></td><td style="line-height: 130%; word-wrap: break-word;">If true, use individual service account credentials for each controller.</td> - </tr> - - <tr> - <td colspan="2">-v, --v Level</td> - </tr> - <tr> - <td></td><td style="line-height: 130%; word-wrap: break-word;">number for the log level verbosity</td> - </tr> - - <tr> - <td colspan="2">--version version[=true]</td> - </tr> - <tr> - <td></td><td style="line-height: 130%; word-wrap: break-word;">Print version information and quit</td> - </tr> - - <tr> - <td colspan="2">--vmodule moduleSpec</td> - </tr> - <tr> - <td></td><td style="line-height: 130%; word-wrap: break-word;">comma-separated list of pattern=N settings for file-filtered logging</td> - </tr> - - </tbody> +<td></td><td style="line-height: 130%; word-wrap: break-word;">若为 true，将文件目录添加到头部。</td> +</tr> + +<tr> +<td colspan="2">--allocate-node-cidrs</td> +</tr> +<tr> +<!-- +<td></td><td style="line-height: 130%; word-wrap: break-word;">Should CIDRs for Pods be allocated and set on the cloud provider.</td> +--> +<td></td><td style="line-height: 130%; word-wrap: break-word;">基于云供应商特性来为 Pod 分配和设置子网掩码。</td> +</tr> + +<tr> +<td colspan="2">--alsologtostderr</td> +</tr> +<tr> +<!-- +<td></td><td style="line-height: 130%; word-wrap: break-word;">log to standard error as well as files</td> +--> +<td></td><td style="line-height: 130%; word-wrap: break-word;">在向文件输出日志的同时，也将日志写到标准输出。</td> +</tr> + +<tr> +<!-- +<td colspan="2">--attach-detach-reconcile-sync-period duration     Default: 1m0s</td> +--> +<td colspan="2">--attach-detach-reconcile-sync-period duration     默认值：1m0s</td> +</tr> +<tr> +<!-- +<td></td><td style="line-height: 130%; word-wrap: break-word;">The reconciler sync wait time between volume attach detach. This duration must be larger than one second, and increasing this value from the default may allow for volumes to be mismatched with pods.</td> +--> +<td></td><td style="line-height: 130%; word-wrap: break-word;">协调器（reconciler）在相邻两次对存储卷进行挂载和解除挂载操作之间的等待时间。此时长必须长于 1 秒钟。此值设置为大于默认值时，可能导致存储卷无法与 Pods 匹配。</td> +</tr> + +<tr> +<td colspan="2">--authentication-kubeconfig string</td> +</tr> +<tr> +<!-- +<td></td><td style="line-height: 130%; word-wrap: break-word;">kubeconfig file pointing at the 'core' kubernetes server with enough rights to create tokenreviews.authentication.k8s.io. This is optional. If empty, all token requests are considered to be anonymous and no client CA is looked up in the cluster.</td> +--> +<td></td><td style="line-height: 130%; word-wrap: break-word;">kubeconfig 文件的路径名。该文件中包含与某 Kubernetes “核心” 服务器相关的信息，并支持足够的权限以创建 tokenreviews.authentication.k8s.io。此选项是可选的。如果设置为空值，所有令牌请求都会被认作匿名请求，Kubernetes 也不再在集群中查找客户端的 CA 证书信息。</td> +</tr> + +<tr> +<td colspan="2">--authentication-skip-lookup</td> +</tr> +<tr> +<!-- +<td></td><td style="line-height: 130%; word-wrap: break-word;">If false, the authentication-kubeconfig will be used to lookup missing authentication configuration from the cluster.</td> +--> +<td></td><td style="line-height: 130%; word-wrap: break-word;">此值为 false 时，通过 authentication-kubeconfig 参数所指定的文件会被用来检索集群中缺失的身份认证配置信息。</td> +</tr> + +<tr> +<!-- +<td colspan="2">--authentication-token-webhook-cache-ttl duration     Default: 10s</td> +--> +<td colspan="2">--authentication-token-webhook-cache-ttl duration     默认值：10s</td> +</tr> +<tr> +<!-- +<td></td><td style="line-height: 130%; word-wrap: break-word;">The duration to cache responses from the webhook token authenticator.</td> +--> +<td></td><td style="line-height: 130%; word-wrap: break-word;">对 Webhook 令牌认证设施返回结果的缓存时长。</td> +</tr> + +<tr> +<td colspan="2">--authentication-tolerate-lookup-failure</td> +</tr> +<tr> +<!-- +<td></td><td style="line-height: 130%; word-wrap: break-word;">If true, failures to look up missing authentication configuration from the cluster are not considered fatal. Note that this can result in authentication that treats all requests as anonymous.</td> +--> +<td></td><td style="line-height: 130%; word-wrap: break-word;">此值 true 时，即使无法从集群中检索到缺失的身份认证配置信息也无大碍。需要注意的是，这样设置可能导致所有请求都被视作匿名请求。</td> +</tr> + +<tr> +<!-- +<td colspan="2">--authorization-always-allow-paths stringSlice     Default: [/healthz]</td> +--> +<td colspan="2">--authorization-always-allow-paths stringSlice     默认值：[/healthz]</td> +</tr> +<tr> +<!-- +<td></td><td style="line-height: 130%; word-wrap: break-word;">A list of HTTP paths to skip during authorization, i.e. these are authorized without contacting the 'core' kubernetes server.</td> +--> +<td></td><td style="line-height: 130%; word-wrap: break-word;">鉴权过程中会忽略的一个 HTTP 路径列表。换言之，控制器管理器会对列表中路径的访问进行授权，并且无须征得 Kubernetes “核心” 服务器同意。</td> +</tr> + +<tr> +<td colspan="2">--authorization-kubeconfig string</td> +</tr> +<tr> +<!-- +<td></td><td style="line-height: 130%; word-wrap: break-word;">kubeconfig file pointing at the 'core' kubernetes server with enough rights to create subjectaccessreviews.authorization.k8s.io. This is optional. If empty, all requests not skipped by authorization are forbidden.</td> +--> +<td></td><td style="line-height: 130%; word-wrap: break-word;">包含 Kubernetes “核心” 服务器信息的 kubeconfig 文件路径，所包含信息具有创建 subjectaccessreviews.authorization.k8s.io 的足够权限。此参数是可选的。如果配置为空字符串，未被鉴权模块所忽略的请求都会被禁止。</td> +</tr> + +<tr> +<!-- +<td colspan="2">--authorization-webhook-cache-authorized-ttl duration     Default: 10s</td> +--> +<td colspan="2">--authorization-webhook-cache-authorized-ttl duration     默认值：10s</td> +</tr> +<tr> +<!-- +<td></td><td style="line-height: 130%; word-wrap: break-word;">The duration to cache 'authorized' responses from the webhook authorizer.</td> +--> +<td></td><td style="line-height: 130%; word-wrap: break-word;">对 Webhook 形式鉴权组件所返回的“已授权（Authorized）”响应的缓存时长。</td> +</tr> + +<tr> +<!-- +<td colspan="2">--authorization-webhook-cache-unauthorized-ttl duration     Default: 10s</td> +--> +<td colspan="2">--authorization-webhook-cache-unauthorized-ttl duration     默认值：10s</td> +</tr> +<tr> +<!-- +<td></td><td style="line-height: 130%; word-wrap: break-word;">The duration to cache 'unauthorized' responses from the webhook authorizer.</td> +--> +<td></td><td style="line-height: 130%; word-wrap: break-word;">对 Webhook 形式鉴权组件所返回的“未授权（Unauthorized）”响应的缓存时长。</td> +</tr> + +<tr> +<td colspan="2">--azure-container-registry-config string</td> +</tr> +<tr> +<!-- +<td></td><td style="line-height: 130%; word-wrap: break-word;">Path to the file containing Azure container registry configuration information.</td> +--> +<td></td><td style="line-height: 130%; word-wrap: break-word;">指向包含 Azure 容器仓库配置信息的文件的路径名。</td> +</tr> + +<tr> +<!-- +<td colspan="2">--bind-address ip     Default: 0.0.0.0</td> +--> +<td colspan="2">--bind-address ip     默认值：0.0.0.0</td> +</tr> +<tr> +<!-- +<td></td><td style="line-height: 130%; word-wrap: break-word;">The IP address on which to listen for the --secure-port port. The associated interface(s) must be reachable by the rest of the cluster, and by CLI/web clients. If blank or an unspecified address (0.0.0.0 or ::), all interfaces will be used.</td> +--> +<td></td><td style="line-height: 130%; word-wrap: break-word;">针对 --secure-port 端口上请求执行监听操作的 IP 地址。所对应的网络接口必须从集群中其它位置可访问（含命令行及 Web 客户端）。如果此值为空或者设定为非特定地址（0.0.0.0 或 ::），意味着所有网络接口都在监听范围。</td> +</tr> + +<tr> +<td colspan="2">--cert-dir string</td> +</tr> +<tr> +<!-- +<td></td><td style="line-height: 130%; word-wrap: break-word;">The directory where the TLS certs are located. If --tls-cert-file and --tls-private-key-file are provided, this flag will be ignored.</td> +--> +<td></td><td style="line-height: 130%; word-wrap: break-word;">TLS 证书所在的目录。如果提供了 --tls-cert-file 和 --tls-private-key-file，此标志会被忽略。</td> +</tr> + +<tr> +<!-- td colspan="2">--cidr-allocator-type string     Default: "RangeAllocator"</td --> +<td colspan="2">--cidr-allocator-type string     默认值："RangeAllocator"</td> +</tr> +<tr> +<!-- td></td><td style="line-height: 130%; word-wrap: break-word;">Type of CIDR allocator to use</td --> +<td></td><td style="line-height: 130%; word-wrap: break-word;">要使用的 CIDR 分配器类型。</td> +</tr> + +<tr> +<td colspan="2">--client-ca-file string</td> +</tr> +<tr> +<!-- td></td><td style="line-height: 130%; word-wrap: break-word;">If set, any request presenting a client certificate signed by one of the authorities in the client-ca-file is authenticated with an identity corresponding to the CommonName of the client certificate.</td --> +<td></td><td style="line-height: 130%; word-wrap: break-word;">如果设置了此标志，对于所有能够提供客户端证书的请求，若该证书由 client-ca-file 中所给机构之一签署，则该请求会被成功认证为客户端证书中 CommonName 所给的实体。</td> +</tr> + +<tr> +<td colspan="2">--cloud-config string</td> +</tr> +<tr> +<!-- td></td><td style="line-height: 130%; word-wrap: break-word;">The path to the cloud provider configuration file. Empty string for no configuration file.</td --> +<td></td><td style="line-height: 130%; word-wrap: break-word;">云驱动程序配置文件的路径。空字符串表示没有配置文件。</td> +</tr> + +<tr> +<td colspan="2">--cloud-provider string</td> +</tr> +<tr> +<!-- td></td><td style="line-height: 130%; word-wrap: break-word;">The provider for cloud services. Empty string for no provider.</td --> +<td></td><td style="line-height: 130%; word-wrap: break-word;">云服务的提供者。空字符串表示没有对应的提供者（驱动）。</td> +</tr> + +<tr> +<td colspan="2">--cluster-cidr string</td> +</tr> +<tr> +<!-- td></td><td style="line-height: 130%; word-wrap: break-word;">CIDR Range for Pods in cluster. Requires --allocate-node-cidrs to be true</td --> +<td></td><td style="line-height: 130%; word-wrap: break-word;">集群中 Pods 的 CIDR 范围。要求 --allocate-node-cidrs 标志为 true。</td> +</tr> + +<tr> +<!-- td colspan="2">--cluster-name string     Default: "kubernetes"</td --> +<td colspan="2">--cluster-name string     默认值："kubernetes"</td> +</tr> +<tr> +<!-- td></td><td style="line-height: 130%; word-wrap: break-word;">The instance prefix for the cluster.</td --> +<td></td><td style="line-height: 130%; word-wrap: break-word;">集群实例的前缀。</td> +</tr> + +<tr> +<!-- td colspan="2">--cluster-signing-cert-file string     Default: "/etc/kubernetes/ca/ca.pem"</td --> +<td colspan="2">--cluster-signing-cert-file string     默认值："/etc/kubernetes/ca/ca.pem"</td> +</tr> +<tr> +<td></td><td style="line-height: 130%; word-wrap: break-word;">包含 PEM 编码格式的 X509 CA 证书的文件名。该证书用来发放集群范围的证书。</td> +</tr> + +<tr> +<!-- td colspan="2">--cluster-signing-key-file string     Default: "/etc/kubernetes/ca/ca.key"</td --> +<td colspan="2">--cluster-signing-key-file string     默认值："/etc/kubernetes/ca/ca.key"</td> +</tr> +<tr> +<!-- td></td><td style="line-height: 130%; word-wrap: break-word;">Filename containing a PEM-encoded RSA or ECDSA private key used to sign cluster-scoped certificates</td --> +<td></td><td style="line-height: 130%; word-wrap: break-word;">包含 PEM 编码的 RSA 或 ECDSA 私钥的文件名。该私钥用来对集群范围证书签名。</td> +</tr> + +<tr> +<!-- td colspan="2">--concurrent-deployment-syncs int32     Default: 5</td --> +<td colspan="2">--concurrent-deployment-syncs int32     默认值：5</td> +</tr> +<tr> +<!-- td></td><td style="line-height: 130%; word-wrap: break-word;">The number of deployment objects that are allowed to sync concurrently. Larger number = more responsive deployments, but more CPU (and network) load</td --> +<td></td><td style="line-height: 130%; word-wrap: break-word;">可以并发同步的 Deployment 对象个数。数值越大意味着对 Deployment 的响应越及时，同时也意味着更大的 CPU（和网络带宽）压力。</td> +</tr> + +<tr> +<!-- td colspan="2">--concurrent-endpoint-syncs int32     Default: 5</td --> +<td colspan="2">--concurrent-endpoint-syncs int32     默认值：5</td> +</tr> +<tr> +<!-- td></td><td style="line-height: 130%; word-wrap: break-word;">The number of endpoint syncing operations that will be done concurrently. Larger number = faster endpoint updating, but more CPU (and network) load</td --> +<td></td><td style="line-height: 130%; word-wrap: break-word;">可以并发执行的 Endpoints 同步操作个数。数值越大意味着更快的 Endpoints 更新操作，同时也意味着更大的 CPU （和网络）压力。</td> +</tr> + +<tr> +<!-- td colspan="2">--concurrent-gc-syncs int32     Default: 20</td --> +<td colspan="2">--concurrent-gc-syncs int32     默认值：20</td> +</tr> +<tr> +<!-- td></td><td style="line-height: 130%; word-wrap: break-word;">The number of garbage collector workers that are allowed to sync concurrently.</td --> +<td></td><td style="line-height: 130%; word-wrap: break-word;">可以并发同步的垃圾收集工作线程个数。</td> +</tr> + +<tr> +<!-- td colspan="2">--concurrent-namespace-syncs int32     Default: 10</td --> +<td colspan="2">--concurrent-namespace-syncs int32     默认值：10</td> +</tr> +<tr> +<!-- td></td><td style="line-height: 130%; word-wrap: break-word;">The number of namespace objects that are allowed to sync concurrently. Larger number = more responsive namespace termination, but more CPU (and network) load</td --> +<td></td><td style="line-height: 130%; word-wrap: break-word;">可以并发同步的 Namespace 对象个数。较大的数值意味着更快的名字空间终结操作，不过也意味着更多的 CPU （和网络）占用。</td> +</tr> + +<tr> +<!-- td colspan="2">--concurrent-replicaset-syncs int32     Default: 5</td --> +<td colspan="2">--concurrent-replicaset-syncs int32     默认值：5</td> +</tr> +<tr> +<!-- td></td><td style="line-height: 130%; word-wrap: break-word;">The number of replica sets that are allowed to sync concurrently. Larger number = more responsive replica management, but more CPU (and network) load</td --> +<td></td><td style="line-height: 130%; word-wrap: break-word;">可以并发同步的 ReplicaSet 个数。数值越大意味着副本管理的响应速度越快，同时也意味着更多的 CPU （和网络）占用。</td> +</tr> + +<tr> +<!-- td colspan="2">--concurrent-resource-quota-syncs int32     Default: 5</td --> +<td colspan="2">--concurrent-resource-quota-syncs int32     默认值：5</td> +</tr> +<tr> +<!-- td></td><td style="line-height: 130%; word-wrap: break-word;">The number of resource quotas that are allowed to sync concurrently. Larger number = more responsive quota management, but more CPU (and network) load</td --> +<td></td><td style="line-height: 130%; word-wrap: break-word;">可以并发同步的 ResourceQuota 对象个数。数值越大，配额管理的响应速度越快，不过对 CPU （和网络）的占用也越高。</td> +</tr> + +<tr> +<!-- td colspan="2">--concurrent-service-endpoint-syncs int32     Default: 5</td --> +<td colspan="2">--concurrent-service-endpoint-syncs int32     默认值：5</td> +</tr> +<tr> +<!-- td></td><td style="line-height: 130%; word-wrap: break-word;">The number of service endpoint syncing operations that will be done concurrently. Larger number = faster endpoint slice updating, but more CPU (and network) load. Defaults to 5.</td --> +<td></td><td style="line-height: 130%; word-wrap: break-word;">可以并发执行的服务端点同步操作个数。数值越大，端点片段（Endpoint Slice）的更新速度越快，不过对 CPU （和网络）的占用也越高。默认值为 5。</td> +</tr> + +<tr> +<!-- td colspan="2">--concurrent-service-syncs int32     Default: 1</td --> +<td colspan="2">--concurrent-service-syncs int32     默认值：1</td> +</tr> +<tr> +<!-- td></td><td style="line-height: 130%; word-wrap: break-word;">The number of services that are allowed to sync concurrently. Larger number = more responsive service management, but more CPU (and network) load</td --> +<td></td><td style="line-height: 130%; word-wrap: break-word;">可以并发同步的 Service 对象个数。数值越大，服务管理的响应速度越快，不过对 CPU （和网络）的占用也越高。</td> +</tr> + +<tr> +<!-- td colspan="2">--concurrent-serviceaccount-token-syncs int32     Default: 5</td --> +<td colspan="2">--concurrent-serviceaccount-token-syncs int32     默认值：5</td> +</tr> +<tr> +<!-- td></td><td style="line-height: 130%; word-wrap: break-word;">The number of service account token objects that are allowed to sync concurrently. Larger number = more responsive token generation, but more CPU (and network) load</td --> +<td></td><td style="line-height: 130%; word-wrap: break-word;">可以并发同步的服务账号令牌对象个数。数值越大，令牌生成的速度越快，不过对 CPU （和网络）的占用也越高。</td> +</tr> + +<tr> +<!-- td colspan="2">--concurrent-statefulset-syncs int32     Default: 5</td --> +<td colspan="2">--concurrent-statefulset-syncs int32     默认值：5</td> +</tr> +<tr> +<!-- td></td><td style="line-height: 130%; word-wrap: break-word;">The number of statefulset objects that are allowed to sync concurrently. Larger number = more responsive statefulsets, but more CPU (and network) load</td --> +<td></td><td style="line-height: 130%; word-wrap: break-word;">可以并发同步的 StatefulSet 对象个数。数值越大，StatefulSet 管理的响应速度越快，不过对 CPU （和网络）的占用也越高。</td> +</tr> + +<tr> +<!-- td colspan="2">--concurrent-ttl-after-finished-syncs int32     Default: 5</td --> +<td colspan="2">--concurrent-ttl-after-finished-syncs int32     默认值：5</td> +</tr> +<tr> +<!-- td></td><td style="line-height: 130%; word-wrap: break-word;">The number of TTL-after-finished controller workers that are allowed to sync concurrently.</td --> +<td></td><td style="line-height: 130%; word-wrap: break-word;">可以并行同步的 TTL-after-finished 控制器线程个数。</td> +</tr> + +<tr> +<!-- td colspan="2">--concurrent_rc_syncs int32     Default: 5</td --> +<td colspan="2">--concurrent_rc_syncs int32     默认值：5</td> +</tr> +<tr> +<!-- td></td><td style="line-height: 130%; word-wrap: break-word;">The number of replication controllers that are allowed to sync concurrently. Larger number = more responsive replica management, but more CPU (and network) load</td --> +<td></td><td style="line-height: 130%; word-wrap: break-word;">可以并发同步的 ReplicationController 对象个数。数值越大，副本管理的响应速度越快，不过对 CPU （和网络）的占用也越高。</td> +</tr> + +<tr> +<!-- td colspan="2">--configure-cloud-routes     Default: true</td --> +<td colspan="2">--configure-cloud-routes     默认值：true</td> +</tr> +<tr> +<!-- td></td><td style="line-height: 130%; word-wrap: break-word;">Should CIDRs allocated by allocate-node-cidrs be configured on the cloud provider.</td --> +<td></td><td style="line-height: 130%; word-wrap: break-word;">决定是否由 --allocate-node-cidrs 所分配的 CIDR 要通过云驱动程序来配置。</td> +</tr> + +<tr> +<td colspan="2">--contention-profiling</td> +</tr> +<tr> +<!-- td></td><td style="line-height: 130%; word-wrap: break-word;">Enable lock contention profiling, if profiling is enabled</td --> +<td></td><td style="line-height: 130%; word-wrap: break-word;">在启用了性能分析（profiling）时，也启用锁竞争情况分析。</td> +</tr> + +<tr> +<td colspan="2">--controller-start-interval duration</td> +</tr> +<tr> +<!-- td></td><td style="line-height: 130%; word-wrap: break-word;">Interval between starting controller managers.</td --> +<td></td><td style="line-height: 130%; word-wrap: break-word;">在两次启动控制器管理器之间的时间间隔。</td> +</tr> + +<tr> +<!-- td colspan="2">--controllers stringSlice     Default: [*]</td --> +<td colspan="2">--controllers stringSlice     默认值：[*]</td> +</tr> +<tr> +<!-- td></td><td style="line-height: 130%; word-wrap: break-word;">A list of controllers to enable. '*' enables all on-by-default controllers, 'foo' enables the controller named 'foo', '-foo' disables the controller named 'foo'.<br/>All controllers: attachdetach, bootstrapsigner, cloud-node-lifecycle, clusterrole-aggregation, cronjob, csrapproving, csrcleaner, csrsigning, daemonset, deployment, disruption, endpoint, endpointslice, garbagecollector, horizontalpodautoscaling, job, namespace, nodeipam, nodelifecycle, persistentvolume-binder, persistentvolume-expander, podgc, pv-protection, pvc-protection, replicaset, replicationcontroller, resourcequota, root-ca-cert-publisher, route, service, serviceaccount, serviceaccount-token, statefulset, tokencleaner, ttl, ttl-after-finished<br/>Disabled-by-default controllers: bootstrapsigner, tokencleaner</td --> +<td></td><td style="line-height: 130%; word-wrap: break-word;">要启用的控制器列表。* 表示启用所有默认启用的控制器；foo 启用名为 foo 的控制器；-foo 表示禁用名为 foo 的控制器。<br/> +控制器的全集：attachdetach、bootstrapsigner、cloud-node-lifecycle、clusterrole-aggregation、cronjob、csrapproving、csrcleaner、csrsigning、daemonset、deployment、disruption、endpoint、endpointslice、garbagecollector、horizontalpodautoscaling、job、namespace、nodeipam、nodelifecycle、persistentvolume-binder、persistentvolume-expander、podgc、pv-protection、pvc-protection、replicaset、replicationcontroller、resourcequota、root-ca-cert-publisher、route、service、serviceaccount、serviceaccount-token、statefulset、tokencleaner、ttl、ttl-after-finished<br/> +默认禁用的控制器有：bootstrapsigner 和 tokencleaner。</td> +</tr> + +<tr> +<!-- td colspan="2">--deployment-controller-sync-period duration     Default: 30s</td --> +<td colspan="2">--deployment-controller-sync-period duration     默认值：30s</td> +</tr> +<tr> +<!-- td></td><td style="line-height: 130%; word-wrap: break-word;">Period for syncing the deployments.</td --> +<td></td><td style="line-height: 130%; word-wrap: break-word;">Deployment 资源的同步周期。</td> +</tr> + +<tr> +<td colspan="2">--disable-attach-detach-reconcile-sync</td> +</tr> +<tr> +<!-- td></td><td style="line-height: 130%; word-wrap: break-word;">Disable volume attach detach reconciler sync. Disabling this may cause volumes to be mismatched with pods. Use wisely.</td --> +<td></td><td style="line-height: 130%; word-wrap: break-word;">禁用卷挂接/解挂调节器的同步。禁用此同步可能导致卷存储与 Pod 之间出现错位。请小心使用。</td> +</tr> + +<tr> +<!-- td colspan="2">--enable-dynamic-provisioning     Default: true</td --> +<td colspan="2">--enable-dynamic-provisioning     默认值：true</td> +</tr> +<tr> +<!-- td></td><td style="line-height: 130%; word-wrap: break-word;">Enable dynamic provisioning for environments that support it.</td --> +<td></td><td style="line-height: 130%; word-wrap: break-word;">在环境允许的情况下启用动态卷供应。</td> +</tr> + +<tr> +<!-- td colspan="2">--enable-garbage-collector     Default: true</td --> +<td colspan="2">--enable-garbage-collector     默认值：true</td> +</tr> +<tr> +<td></td><td style="line-height: 130%; word-wrap: break-word;">启用通用垃圾收集器。必须与 kube-apiserver 中对应的标志一致。</td> +</tr> + +<tr> +<td colspan="2">--enable-hostpath-provisioner</td> +</tr> +<tr> +<!-- td></td><td style="line-height: 130%; word-wrap: break-word;">Enable HostPath PV provisioning when running without a cloud provider. This allows testing and development of provisioning features. HostPath provisioning is not supported in any way, won't work in a multi-node cluster, and should not be used for anything other than testing or development.</td --> +<td></td><td style="line-height: 130%; word-wrap: break-word;">在没有云驱动程序的情况下，启用 HostPath 持久卷的供应。此参数便于对卷供应功能进行开发和测试。 HostPath 卷供应并非受支持的功能特性，在多节点的集群中也无法工作，因此除了开发和测试环境中不应使用。</td> +</tr> + +<tr> +<!-- td colspan="2">--enable-taint-manager     Default: true</td --> +<td colspan="2">--enable-taint-manager     默认值：true</td> +</tr> +<tr> +<!-- td></td><td style="line-height: 130%; word-wrap: break-word;">WARNING: Beta feature. If set to true enables NoExecute Taints and will evict all not-tolerating Pod running on Nodes tainted with this kind of Taints.</td --> +<td></td><td style="line-height: 130%; word-wrap: break-word;">警告：Beta 阶段特性。设置为 true 时会启用 NoExecute 污点，并在所有标记了此污点的节点上逐出所有无法忍受该污点的 Pods。</td> +</tr> + +<tr> +<td colspan="2">--endpoint-updates-batch-period duration</td> +</tr> +<tr> +<!-- td></td><td style="line-height: 130%; word-wrap: break-word;">The length of endpoint updates batching period. Processing of pod changes will be delayed by this duration to join them with potential upcoming updates and reduce the overall number of endpoints updates. Larger number = higher endpoint programming latency, but lower number of endpoints revision generated</td --> +<td></td><td style="line-height: 130%; word-wrap: break-word;">端点（Endpoint）批量更新周期时长。对 Pods 变更的处理会被延迟，以便将其与即将到来的更新操作合并，从而减少端点更新操作次数。较大的数值意味着端点更新的迟滞时间会增长，也意味着所生成的端点版本个数会变少。</td> +</tr> + +<tr> +<td colspan="2">--endpointslice-updates-batch-period duration</td> +</tr> +<tr> +<!-- td></td><td style="line-height: 130%; word-wrap: break-word;">The length of endpoint slice updates batching period. Processing of pod changes will be delayed by this duration to join them with potential upcoming updates and reduce the overall number of endpoints updates. Larger number = higher endpoint programming latency, but lower number of endpoints revision generated</td --> +<td></td><td style="line-height: 130%; word-wrap: break-word;">端点片段（Endpoint Slice）批量更新周期时长。对 Pods 变更的处理会被延迟，以便将其与即将到来的更新操作合并，从而减少端点更新操作次数。较大的数值意味着端点更新的迟滞时间会增长，也意味着所生成的端点版本个数会变少。</td> +</tr> + +<tr> +<!-- td colspan="2">--experimental-cluster-signing-duration duration     Default: 8760h0m0s</td --> +<td colspan="2">--experimental-cluster-signing-duration duration     默认值：8760h0m0s</td> +</tr> +<tr> +<td></td><td style="line-height: 130%; word-wrap: break-word;">所签署的证书的有效期时长。</td> +</tr> + +<tr> +<td colspan="2">--external-cloud-volume-plugin string</td> +</tr> +<tr> +<!-- td></td><td style="line-height: 130%; word-wrap: break-word;">The plugin to use when cloud provider is set to external. Can be empty, should only be set when cloud-provider is external. Currently used to allow node and volume controllers to work for in tree cloud providers.</td --> +<td></td><td style="line-height: 130%; word-wrap: break-word;">当云驱动程序设置为 external 时要使用的插件名称。此字符串可以为空。只能在云驱动程序为 external 时设置。目前用来保证节点控制器和卷控制器能够在三种云驱动上正常工作。</td> +</tr> + +<tr> +<td colspan="2">--feature-gates mapStringBool</td> +</tr> +<tr> +<!-- td></td><td style="line-height: 130%; word-wrap: break-word;">A set of key=value pairs that describe feature gates for alpha/experimental features. Options are:<br/>APIListChunking=true|false (BETA - default=true)<br/>APIPriorityAndFairness=true|false (ALPHA - default=false)<br/>APIResponseCompression=true|false (BETA - default=true)<br/>AllAlpha=true|false (ALPHA - default=false)<br/>AllBeta=true|false (BETA - default=false)<br/>AllowInsecureBackendProxy=true|false (BETA - default=true)<br/>AnyVolumeDataSource=true|false (ALPHA - default=false)<br/>AppArmor=true|false (BETA - default=true)<br/>BalanceAttachedNodeVolumes=true|false (ALPHA - default=false)<br/>BoundServiceAccountTokenVolume=true|false (ALPHA - default=false)<br/>CPUManager=true|false (BETA - default=true)<br/>CRIContainerLogRotation=true|false (BETA - default=true)<br/>CSIInlineVolume=true|false (BETA - default=true)<br/>CSIMigration=true|false (BETA - default=true)<br/>CSIMigrationAWS=true|false (BETA - default=false)<br/>CSIMigrationAWSComplete=true|false (ALPHA - default=false)<br/>CSIMigrationAzureDisk=true|false (ALPHA - default=false)<br/>CSIMigrationAzureDiskComplete=true|false (ALPHA - default=false)<br/>CSIMigrationAzureFile=true|false (ALPHA - default=false)<br/>CSIMigrationAzureFileComplete=true|false (ALPHA - default=false)<br/>CSIMigrationGCE=true|false (BETA - default=false)<br/>CSIMigrationGCEComplete=true|false (ALPHA - default=false)<br/>CSIMigrationOpenStack=true|false (BETA - default=false)<br/>CSIMigrationOpenStackComplete=true|false (ALPHA - default=false)<br/>ConfigurableFSGroupPolicy=true|false (ALPHA - default=false)<br/>CustomCPUCFSQuotaPeriod=true|false (ALPHA - default=false)<br/>DefaultIngressClass=true|false (BETA - default=true)<br/>DevicePlugins=true|false (BETA - default=true)<br/>DryRun=true|false (BETA - default=true)<br/>DynamicAuditing=true|false (ALPHA - default=false)<br/>DynamicKubeletConfig=true|false (BETA - default=true)<br/>EndpointSlice=true|false (BETA - default=true)<br/>EndpointSliceProxying=true|false (ALPHA - default=false)<br/>EphemeralContainers=true|false (ALPHA - default=false)<br/>EvenPodsSpread=true|false (BETA - default=true)<br/>ExpandCSIVolumes=true|false (BETA - default=true)<br/>ExpandInUsePersistentVolumes=true|false (BETA - default=true)<br/>ExpandPersistentVolumes=true|false (BETA - default=true)<br/>ExperimentalHostUserNamespaceDefaulting=true|false (BETA - default=false)<br/>HPAScaleToZero=true|false (ALPHA - default=false)<br/>HugePageStorageMediumSize=true|false (ALPHA - default=false)<br/>HyperVContainer=true|false (ALPHA - default=false)<br/>IPv6DualStack=true|false (ALPHA - default=false)<br/>ImmutableEphemeralVolumes=true|false (ALPHA - default=false)<br/>KubeletPodResources=true|false (BETA - default=true)<br/>LegacyNodeRoleBehavior=true|false (ALPHA - default=true)<br/>LocalStorageCapacityIsolation=true|false (BETA - default=true)<br/>LocalStorageCapacityIsolationFSQuotaMonitoring=true|false (ALPHA - default=false)<br/>NodeDisruptionExclusion=true|false (ALPHA - default=false)<br/>NonPreemptingPriority=true|false (ALPHA - default=false)<br/>PodDisruptionBudget=true|false (BETA - default=true)<br/>PodOverhead=true|false (BETA - default=true)<br/>ProcMountType=true|false (ALPHA - default=false)<br/>QOSReserved=true|false (ALPHA - default=false)<br/>RemainingItemCount=true|false (BETA - default=true)<br/>RemoveSelfLink=true|false (ALPHA - default=false)<br/>ResourceLimitsPriorityFunction=true|false (ALPHA - default=false)<br/>RotateKubeletClientCertificate=true|false (BETA - default=true)<br/>RotateKubeletServerCertificate=true|false (BETA - default=true)<br/>RunAsGroup=true|false (BETA - default=true)<br/>RuntimeClass=true|false (BETA - default=true)<br/>SCTPSupport=true|false (ALPHA - default=false)<br/>SelectorIndex=true|false (ALPHA - default=false)<br/>ServerSideApply=true|false (BETA - default=true)<br/>ServiceAccountIssuerDiscovery=true|false (ALPHA - default=false)<br/>ServiceAppProtocol=true|false (ALPHA - default=false)<br/>ServiceNodeExclusion=true|false (ALPHA - default=false)<br/>ServiceTopology=true|false (ALPHA - default=false)<br/>StartupProbe=true|false (BETA - default=true)<br/>StorageVersionHash=true|false (BETA - default=true)<br/>SupportNodePidsLimit=true|false (BETA - default=true)<br/>SupportPodPidsLimit=true|false (BETA - default=true)<br/>Sysctls=true|false (BETA - default=true)<br/>TTLAfterFinished=true|false (ALPHA - default=false)<br/>TokenRequest=true|false (BETA - default=true)<br/>TokenRequestProjection=true|false (BETA - default=true)<br/>TopologyManager=true|false (BETA - default=true)<br/>ValidateProxyRedirects=true|false (BETA - default=true)<br/>VolumeSnapshotDataSource=true|false (BETA - default=true)<br/>WinDSR=true|false (ALPHA - default=false)<br/>WinOverlay=true|false (ALPHA - default=false)</td --> +<td></td><td style="line-height: 130%; word-wrap: break-word;">一组 key=value 耦对，用来描述测试性/试验性功能的特性门控（Feature Gate）。可选项有：<br/>APIListChunking=true|false (BETA - default=true)<br/>APIPriorityAndFairness=true|false (ALPHA - default=false)<br/>APIResponseCompression=true|false (BETA - default=true)<br/>AllAlpha=true|false (ALPHA - default=false)<br/>AllBeta=true|false (BETA - default=false)<br/>AllowInsecureBackendProxy=true|false (BETA - default=true)<br/>AnyVolumeDataSource=true|false (ALPHA - default=false)<br/>AppArmor=true|false (BETA - default=true)<br/>BalanceAttachedNodeVolumes=true|false (ALPHA - default=false)<br/>BoundServiceAccountTokenVolume=true|false (ALPHA - default=false)<br/>CPUManager=true|false (BETA - default=true)<br/>CRIContainerLogRotation=true|false (BETA - default=true)<br/>CSIInlineVolume=true|false (BETA - default=true)<br/>CSIMigration=true|false (BETA - default=true)<br/>CSIMigrationAWS=true|false (BETA - default=false)<br/>CSIMigrationAWSComplete=true|false (ALPHA - default=false)<br/>CSIMigrationAzureDisk=true|false (ALPHA - default=false)<br/>CSIMigrationAzureDiskComplete=true|false (ALPHA - default=false)<br/>CSIMigrationAzureFile=true|false (ALPHA - default=false)<br/>CSIMigrationAzureFileComplete=true|false (ALPHA - default=false)<br/>CSIMigrationGCE=true|false (BETA - default=false)<br/>CSIMigrationGCEComplete=true|false (ALPHA - default=false)<br/>CSIMigrationOpenStack=true|false (BETA - default=false)<br/>CSIMigrationOpenStackComplete=true|false (ALPHA - default=false)<br/>ConfigurableFSGroupPolicy=true|false (ALPHA - default=false)<br/>CustomCPUCFSQuotaPeriod=true|false (ALPHA - default=false)<br/>DefaultIngressClass=true|false (BETA - default=true)<br/>DevicePlugins=true|false (BETA - default=true)<br/>DryRun=true|false (BETA - default=true)<br/>DynamicAuditing=true|false (ALPHA - default=false)<br/>DynamicKubeletConfig=true|false (BETA - default=true)<br/>EndpointSlice=true|false (BETA - default=true)<br/>EndpointSliceProxying=true|false (ALPHA - default=false)<br/>EphemeralContainers=true|false (ALPHA - default=false)<br/>EvenPodsSpread=true|false (BETA - default=true)<br/>ExpandCSIVolumes=true|false (BETA - default=true)<br/>ExpandInUsePersistentVolumes=true|false (BETA - default=true)<br/>ExpandPersistentVolumes=true|false (BETA - default=true)<br/>ExperimentalHostUserNamespaceDefaulting=true|false (BETA - default=false)<br/>HPAScaleToZero=true|false (ALPHA - default=false)<br/>HugePageStorageMediumSize=true|false (ALPHA - default=false)<br/>HyperVContainer=true|false (ALPHA - default=false)<br/>IPv6DualStack=true|false (ALPHA - default=false)<br/>ImmutableEphemeralVolumes=true|false (ALPHA - default=false)<br/>KubeletPodResources=true|false (BETA - default=true)<br/>LegacyNodeRoleBehavior=true|false (ALPHA - default=true)<br/>LocalStorageCapacityIsolation=true|false (BETA - default=true)<br/>LocalStorageCapacityIsolationFSQuotaMonitoring=true|false (ALPHA - default=false)<br/>NodeDisruptionExclusion=true|false (ALPHA - default=false)<br/>NonPreemptingPriority=true|false (ALPHA - default=false)<br/>PodDisruptionBudget=true|false (BETA - default=true)<br/>PodOverhead=true|false (BETA - default=true)<br/>ProcMountType=true|false (ALPHA - default=false)<br/>QOSReserved=true|false (ALPHA - default=false)<br/>RemainingItemCount=true|false (BETA - default=true)<br/>RemoveSelfLink=true|false (ALPHA - default=false)<br/>ResourceLimitsPriorityFunction=true|false (ALPHA - default=false)<br/>RotateKubeletClientCertificate=true|false (BETA - default=true)<br/>RotateKubeletServerCertificate=true|false (BETA - default=true)<br/>RunAsGroup=true|false (BETA - default=true)<br/>RuntimeClass=true|false (BETA - default=true)<br/>SCTPSupport=true|false (ALPHA - default=false)<br/>SelectorIndex=true|false (ALPHA - default=false)<br/>ServerSideApply=true|false (BETA - default=true)<br/>ServiceAccountIssuerDiscovery=true|false (ALPHA - default=false)<br/>ServiceAppProtocol=true|false (ALPHA - default=false)<br/>ServiceNodeExclusion=true|false (ALPHA - default=false)<br/>ServiceTopology=true|false (ALPHA - default=false)<br/>StartupProbe=true|false (BETA - default=true)<br/>StorageVersionHash=true|false (BETA - default=true)<br/>SupportNodePidsLimit=true|false (BETA - default=true)<br/>SupportPodPidsLimit=true|false (BETA - default=true)<br/>Sysctls=true|false (BETA - default=true)<br/>TTLAfterFinished=true|false (ALPHA - default=false)<br/>TokenRequest=true|false (BETA - default=true)<br/>TokenRequestProjection=true|false (BETA - default=true)<br/>TopologyManager=true|false (BETA - default=true)<br/>ValidateProxyRedirects=true|false (BETA - default=true)<br/>VolumeSnapshotDataSource=true|false (BETA - default=true)<br/>WinDSR=true|false (ALPHA - default=false)<br/>WinOverlay=true|false (ALPHA - default=false)</td> +</tr> + +<tr> +<!-- td colspan="2">--flex-volume-plugin-dir string     Default: "/usr/libexec/kubernetes/kubelet-plugins/volume/exec/"</td --> +<td colspan="2">--flex-volume-plugin-dir string     默认值："/usr/libexec/kubernetes/kubelet-plugins/volume/exec/"</td> +</tr> +<tr> +<!-- td></td><td style="line-height: 130%; word-wrap: break-word;">Full path of the directory in which the flex volume plugin should search for additional third party volume plugins.</td --> +<td></td><td style="line-height: 130%; word-wrap: break-word;">FlexVolume 插件要搜索第三方卷插件的目录路径。</td> +</tr> + +<tr> +<td colspan="2">-h, --help</td> +</tr> +<tr> +<!-- td></td><td style="line-height: 130%; word-wrap: break-word;">help for kube-controller-manager</td --> +<td></td><td style="line-height: 130%; word-wrap: break-word;">kube-controller-manager 的帮助信息</td> +</tr> + +<tr> +<!-- td colspan="2">--horizontal-pod-autoscaler-cpu-initialization-period duration     Default: 5m0s</td --> +<td colspan="2">--horizontal-pod-autoscaler-cpu-initialization-period duration     默认值：5m0s</td> +</tr> +<tr> +<!-- td></td><td style="line-height: 130%; word-wrap: break-word;">The period after pod start when CPU samples might be skipped.</td --> +<td></td><td style="line-height: 130%; word-wrap: break-word;">Pod 启动之后可以忽略 CPU 采样值的时长。</td> +</tr> + +<tr> +<!-- td colspan="2">--horizontal-pod-autoscaler-downscale-stabilization duration     Default: 5m0s</td --> +<td colspan="2">--horizontal-pod-autoscaler-downscale-stabilization duration     默认值：5m0s</td> +</tr> +<tr> +<!-- td></td><td style="line-height: 130%; word-wrap: break-word;">The period for which autoscaler will look backwards and not scale down below any recommendation it made during that period.</td --> +<td></td><td style="line-height: 130%; word-wrap: break-word;">自动扩缩程序的回溯时长。自动扩缩器不会基于在给定的时长内所建议的规模对负载执行规模缩小的操作。</td> +</tr> + +<tr> +<!-- td colspan="2">--horizontal-pod-autoscaler-initial-readiness-delay duration     Default: 30s</td --> +<td colspan="2">--horizontal-pod-autoscaler-initial-readiness-delay duration     默认值：30s</td> +</tr> +<tr> +<!-- td></td><td style="line-height: 130%; word-wrap: break-word;">The period after pod start during which readiness changes will be treated as initial readiness.</td --> +<td></td><td style="line-height: 130%; word-wrap: break-word;">Pod 启动之后，在此值所给定的时长内，就绪状态的变化都不会作为初始的就绪状态。</td> +</tr> + +<tr> +<!-- td colspan="2">--horizontal-pod-autoscaler-sync-period duration     Default: 15s</td --> +<td colspan="2">--horizontal-pod-autoscaler-sync-period duration     默认值：15s</td> +</tr> +<tr> +<!-- td></td><td style="line-height: 130%; word-wrap: break-word;">The period for syncing the number of pods in horizontal pod autoscaler.</td --> +<td></td><td style="line-height: 130%; word-wrap: break-word;">水平 Pod 扩缩器对 Pods 数目执行同步操作的周期。</td> +</tr> + +<tr> +<!-- td colspan="2">--horizontal-pod-autoscaler-tolerance float     Default: 0.1</td --> +<td colspan="2">--horizontal-pod-autoscaler-tolerance float     默认值：0.1</td> +</tr> +<tr> +<td></td><td style="line-height: 130%; word-wrap: break-word;">此值为目标值与实际值的比值与 1.0 的差值。只有超过此标志所设的阈值时，HPA 才会考虑执行缩放操作。</td> +</tr> + +<tr> +<td colspan="2">--http2-max-streams-per-connection int</td> +</tr> +<tr> +<!-- td></td><td style="line-height: 130%; word-wrap: break-word;">The limit that the server gives to clients for the maximum number of streams in an HTTP/2 connection. Zero means to use golang's default.</td --> +<td></td><td style="line-height: 130%; word-wrap: break-word;">服务器为客户端所设置的 HTTP/2 连接中流式连接个数上限。此值为 0 表示采用 Go 语言库所设置的默认值。</td> +</tr> + +<tr> +<!-- td colspan="2">--kube-api-burst int32     Default: 30</td --> +<td colspan="2">--kube-api-burst int32     默认值：30</td> +</tr> +<tr> +<!-- td></td><td style="line-height: 130%; word-wrap: break-word;">Burst to use while talking with kubernetes apiserver.</td --> +<td></td><td style="line-height: 130%; word-wrap: break-word;">与 Kubernetes API 服务器通信时突发峰值请求个数上限。</td> +</tr> + +<tr> +<!-- td colspan="2">--kube-api-content-type string     Default: "application/vnd.kubernetes.protobuf"</td --> +<td colspan="2">--kube-api-content-type string     默认值："application/vnd.kubernetes.protobuf"</td> +</tr> +<tr> +<!-- td></td><td style="line-height: 130%; word-wrap: break-word;">Content type of requests sent to apiserver.</td --> +<td></td><td style="line-height: 130%; word-wrap: break-word;">向 API 服务器发送请求时使用的内容类型（Content-Type）。</td> +</tr> + +<tr> +<!-- td colspan="2">--kube-api-qps float32     Default: 20</td --> +<td colspan="2">--kube-api-qps float32     默认值：20</td> +</tr> +<tr> +<!-- td></td><td style="line-height: 130%; word-wrap: break-word;">QPS to use while talking with kubernetes apiserver.</td --> +<td></td><td style="line-height: 130%; word-wrap: break-word;">与 API 服务器通信时每秒请求数（QPS）限制。</td> +</tr> + +<tr> +<td colspan="2">--kubeconfig string</td> +</tr> +<tr> +<!-- td></td><td style="line-height: 130%; word-wrap: break-word;">Path to kubeconfig file with authorization and master location information.</td --> +<td></td><td style="line-height: 130%; word-wrap: break-word;">指向 kubeconfig 文件的路径。该文件中包含主控节点位置以及鉴权凭据信息。</td> +</tr> + +<tr> +<!-- td colspan="2">--large-cluster-size-threshold int32     Default: 50</td --> +<td colspan="2">--large-cluster-size-threshold int32     默认值：50</td> +</tr> +<tr> +<!-- td></td><td style="line-height: 130%; word-wrap: break-word;">Number of nodes from which NodeController treats the cluster as large for the eviction logic purposes. --secondary-node-eviction-rate is implicitly overridden to 0 for clusters this size or smaller.</td --> +<td></td><td style="line-height: 130%; word-wrap: break-word;">节点控制器在执行 Pod 逐出操作逻辑时，基于此标志所设置的节点个数阈值来判断所在集群是否为大规模集群。当集群规模小于等于此规模时，--secondary-node-eviction-rate 会被隐式重设为 0。</td> +</tr> + +<tr> +<!-- td colspan="2">--leader-elect     Default: true</td --> +<td colspan="2">--leader-elect     默认值：true</td> +</tr> +<tr> +<!-- td></td><td style="line-height: 130%; word-wrap: break-word;">Start a leader election client and gain leadership before executing the main loop. Enable this when running replicated components for high availability.</td --> +<td></td><td style="line-height: 130%; word-wrap: break-word;">在执行主循环之前，启动领导选举（Leader Election）客户端，并尝试获得领导者身份。在运行多副本组件时启用此标志有助于提高可用性。</td> +</tr> + +<tr> +<!-- td colspan="2">--leader-elect-lease-duration duration     Default: 15s</td --> +<td colspan="2">--leader-elect-lease-duration duration     默认值：15s</td> +</tr> +<tr> +<!-- td></td><td style="line-height: 130%; word-wrap: break-word;">The duration that non-leader candidates will wait after observing a leadership renewal until attempting to acquire leadership of a led but unrenewed leader slot. This is effectively the maximum duration that a leader can be stopped before it is replaced by another candidate. This is only applicable if leader election is enabled.</td --> +<td></td><td style="line-height: 130%; word-wrap: break-word;">对于未获得领导者身份的节点，在探测到领导者身份需要更迭时需要等待此标志所设置的时长，才能尝试去获得曾经是领导者但尚未续约的席位。本质上，这个时长也是现有领导者节点在被其他候选节点替代之前可以停止的最长时长。只有集群启用了领导者选举机制时，此标志才起作用。</td> +</tr> + +<tr> +<!-- td colspan="2">--leader-elect-renew-deadline duration     Default: 10s</td --> +<td colspan="2">--leader-elect-renew-deadline duration     默认值：10s</td> +</tr> +<tr> +<!-- td></td><td style="line-height: 130%; word-wrap: break-word;">The interval between attempts by the acting master to renew a leadership slot before it stops leading. This must be less than or equal to the lease duration. This is only applicable if leader election is enabled.</td --> +<td></td><td style="line-height: 130%; word-wrap: break-word;">当前执行领导者角色的节点在被停止履行领导职责之前可多次尝试续约领导者身份；此标志给出相邻两次尝试之间的间歇时长。此值必须小于或等于租期时长（Lease Duration）。仅在集群启用了领导者选举时有效。</td> +</tr> + +<tr> +<!-- td colspan="2">--leader-elect-resource-lock endpoints     Default: "endpointsleases"</td --> +<td colspan="2">--leader-elect-resource-lock endpoints     默认值："endpointsleases"</td> +</tr> +<tr> +<!-- td></td><td style="line-height: 130%; word-wrap: break-word;">The type of resource object that is used for locking during leader election. Supported options are endpoints (default) and configmaps.</td --> +<td></td><td style="line-height: 130%; word-wrap: break-word;">在领导者选举期间用来执行锁操作的资源对象类型。可选项为 endpointsleases （默认值）和 configmaps。</td> +</tr> + +<tr> +<!-- td colspan="2">--leader-elect-resource-name string     Default: "kube-controller-manager"</td --> +<td colspan="2">--leader-elect-resource-name string     默认值："kube-controller-manager"</td> +</tr> +<tr> +<!-- td></td><td style="line-height: 130%; word-wrap: break-word;">The name of resource object that is used for locking during leader election.</td --> +<td></td><td style="line-height: 130%; word-wrap: break-word;">在领导者选举期间，用来执行锁操作的资源对象名称。</td> +</tr> + +<tr> +<!-- td colspan="2">--leader-elect-resource-namespace string     Default: "kube-system"</td --> +<td colspan="2">--leader-elect-resource-namespace string     默认值："kube-system"</td> +</tr> +<tr> +<!-- td></td><td style="line-height: 130%; word-wrap: break-word;">The namespace of resource object that is used for locking during leader election.</td --> +<td></td><td style="line-height: 130%; word-wrap: break-word;">在领导者选举期间，用来执行锁操作的资源对象的名字空间。</td> +</tr> + +<tr> +<!-- td colspan="2">--leader-elect-retry-period duration     Default: 2s</td --> +<td colspan="2">--leader-elect-retry-period duration     默认值：2s</td> +</tr> +<tr> +<td></td><td style="line-height: 130%; word-wrap: break-word;">尝试获得领导者身份时，客户端在相邻两次尝试之间要等待的时长。此标志仅在启用了领导者选举的集群中起作用。</td> +</tr> + +<tr> +<!-- td colspan="2">--log-backtrace-at traceLocation     Default: :0</td --> +<td colspan="2">--log-backtrace-at traceLocation     默认值：:0</td> +</tr> +<tr> +<td></td><td style="line-height: 130%; word-wrap: break-word;">当执行到 file:N 所给的文件和代码行时，日志机制会生成一个调用栈快照。</td> +</tr> + +<tr> +<td colspan="2">--log-dir string</td> +</tr> +<tr> +<!-- td></td><td style="line-height: 130%; word-wrap: break-word;">If non-empty, write log files in this directory</td --> +<td></td><td style="line-height: 130%; word-wrap: break-word;">此标志为非空字符串时，日志文件会写入到所给的目录中。</td> +</tr> + +<tr> +<td colspan="2">--log-file string</td> +</tr> +<tr> +<!-- td></td><td style="line-height: 130%; word-wrap: break-word;">If non-empty, use this log file</td --> +<td></td><td style="line-height: 130%; word-wrap: break-word;">此标志为非空字符串时，意味着日志会写入到所给的文件中。</td> +</tr> + +<tr> +<!-- td colspan="2">--log-file-max-size uint     Default: 1800</td --> +<td colspan="2">--log-file-max-size uint     默认值：1800</td> +</tr> +<tr> +<!-- td></td><td style="line-height: 130%; word-wrap: break-word;">Defines the maximum size a log file can grow to. Unit is megabytes. If the value is 0, the maximum file size is unlimited.</td --> +<td></td><td style="line-height: 130%; word-wrap: break-word;">定义日志文件大小的上限。单位是兆字节（MB）。若此值为 0，则不对日志文件尺寸进行约束。</td> +</tr> + +<tr> +<!-- td colspan="2">--log-flush-frequency duration     Default: 5s</td --> +<td colspan="2">--log-flush-frequency duration     默认值：5s</td> +</tr> +<tr> +<!-- td></td><td style="line-height: 130%; word-wrap: break-word;">Maximum number of seconds between log flushes</td --> +<td></td><td style="line-height: 130%; word-wrap: break-word;">将内存中日志数据清除到日志文件中时，相邻两次清除操作之间最大间隔秒数。</td> +</tr> + +<tr> +<!-- td colspan="2">--logtostderr     Default: true</td --> +<td colspan="2">--logtostderr     默认值：true</td> +</tr> +<tr> +<!-- td></td><td style="line-height: 130%; word-wrap: break-word;">log to standard error instead of files</td --> +<td></td><td style="line-height: 130%; word-wrap: break-word;">将日志写出到标准错误输出（stderr）而不是写入到日志文件。</td> +</tr> + +<tr> +<td colspan="2">--master string</td> +</tr> +<tr> +<!-- td></td><td style="line-height: 130%; word-wrap: break-word;">The address of the Kubernetes API server (overrides any value in kubeconfig).</td --> +<td></td><td style="line-height: 130%; word-wrap: break-word;">Kubernetes API 服务器的地址。此值会覆盖 kubeconfig 文件中所给的地址。</td> +</tr> + +<tr> +<!-- td colspan="2">--max-endpoints-per-slice int32     Default: 100</td --> +<td colspan="2">--max-endpoints-per-slice int32     默认值：100</td> +</tr> +<tr> +<!-- td></td><td style="line-height: 130%; word-wrap: break-word;">The maximum number of endpoints that will be added to an EndpointSlice. More endpoints per slice will result in less endpoint slices, but larger resources. Defaults to 100.</td --> +<td></td><td style="line-height: 130%; word-wrap: break-word;">每个 EndpointSlice 中可以添加的端点个数上限。每个片段中端点个数越多，得到的片段个数越少，但是片段的规模会变得更大。默认值为 100。</td> +</tr> + +<tr> +<!-- td colspan="2">--min-resync-period duration     Default: 12h0m0s</td --> +<td colspan="2">--min-resync-period duration     默认值：12h0m0s</td> +</tr> +<tr> +<!-- td></td><td style="line-height: 130%; word-wrap: break-word;">The resync period in reflectors will be random between MinResyncPeriod and 2*MinResyncPeriod.</td --> +<td></td><td style="line-height: 130%; word-wrap: break-word;">自省程序的重新同步时隔下限。实际时隔长度会在 min-resync-period 和 2 * min-resync-period 之间。</td> +</tr> + +<tr> +<!-- td colspan="2">--namespace-sync-period duration     Default: 5m0s</td --> +<td colspan="2">--namespace-sync-period duration     默认值：5m0s</td> +</tr> +<tr> +<!-- td></td><td style="line-height: 130%; word-wrap: break-word;">The period for syncing namespace life-cycle updates</td --> +<td></td><td style="line-height: 130%; word-wrap: break-word;">对名字空间对象进行同步的周期。</td> +</tr> + +<tr> +<td colspan="2">--node-cidr-mask-size int32</td> +</tr> +<tr> +<!-- td></td><td style="line-height: 130%; word-wrap: break-word;">Mask size for node cidr in cluster. Default is 24 for IPv4 and 64 for IPv6.</td --> +<td></td><td style="line-height: 130%; word-wrap: break-word;">集群中节点 CIDR 的掩码长度。对 IPv4 而言默认为 24；对 IPv6 而言默认为 64。</td> +</tr> + +<tr> +<td colspan="2">--node-cidr-mask-size-ipv4 int32</td> +</tr> +<tr> +<!-- td></td><td style="line-height: 130%; word-wrap: break-word;">Mask size for IPv4 node cidr in dual-stack cluster. Default is 24.</td --> +<td></td><td style="line-height: 130%; word-wrap: break-word;">在双堆栈（同时支持 IPv4 和 IPv6）的集群中，节点 IPV4 CIDR 掩码长度。默认为 24。</td> +</tr> + +<tr> +<td colspan="2">--node-cidr-mask-size-ipv6 int32</td> +</tr> +<tr> +<!-- td></td><td style="line-height: 130%; word-wrap: break-word;">Mask size for IPv6 node cidr in dual-stack cluster. Default is 64.</td --> +<td></td><td style="line-height: 130%; word-wrap: break-word;">在双堆栈（同时支持 IPv4 和 IPv6）的集群中，节点 IPv6 CIDR 掩码长度。默认为 64。</td> +</tr> + +<tr> +<!-- td colspan="2">--node-eviction-rate float32     Default: 0.1</td --> +<td colspan="2">--node-eviction-rate float32     默认值：0.1</td> +</tr> +<tr> +<!-- td></td><td style="line-height: 130%; word-wrap: break-word;">Number of nodes per second on which pods are deleted in case of node failure when a zone is healthy (see --unhealthy-zone-threshold for definition of healthy/unhealthy). Zone refers to entire cluster in non-multizone clusters.</td --> +<td></td><td style="line-height: 130%; word-wrap: break-word;">当某区域变得不健康，节点失效时，每秒钟可以从此标志所设定的节点个数上删除 Pods。请参阅 --unhealthy-zone-threshold 以了解“健康”的判定标准。这里的区域（zone）在集群并不跨多个区域时指的是整个集群。</td> +</tr> + +<tr> +<!-- td colspan="2">--node-monitor-grace-period duration     Default: 40s</td --> +<td colspan="2">--node-monitor-grace-period duration     默认值：40s</td> +</tr> +<tr> +<!-- td></td><td style="line-height: 130%; word-wrap: break-word;">Amount of time which we allow running Node to be unresponsive before marking it unhealthy. Must be N times more than kubelet's nodeStatusUpdateFrequency, where N means number of retries allowed for kubelet to post node status.</td --> +<td></td><td style="line-height: 130%; word-wrap: break-word;">在将一个 Node 标记为不健康之前允许其无响应的时长上限。必须比 kubelet 的 nodeStatusUpdateFrequency 大 N 倍；这里 N 指的是 kubelet 发送节点状态的重试次数。</td> +</tr> + +<tr> +<!-- td colspan="2">--node-monitor-period duration     Default: 5s</td --> +<td colspan="2">--node-monitor-period duration     默认值：5s</td> +</tr> +<tr> +<!-- td></td><td style="line-height: 130%; word-wrap: break-word;">The period for syncing NodeStatus in NodeController.</td --> +<td></td><td style="line-height: 130%; word-wrap: break-word;">节点控制器对节点状态进行同步的重复周期。</td> +</tr> + +<tr> +<!-- td colspan="2">--node-startup-grace-period duration     Default: 1m0s</td --> +<td colspan="2">--node-startup-grace-period duration     默认值：1m0s</td> +</tr> +<tr> +<!-- td></td><td style="line-height: 130%; word-wrap: break-word;">Amount of time which we allow starting Node to be unresponsive before marking it unhealthy.</td --> +<td></td><td style="line-height: 130%; word-wrap: break-word;">在节点启动期间，节点可以处于无响应状态；但超出此标志所设置的时长仍然无响应则该节点被标记为不健康。</td> +</tr> + +<tr> +<!-- td colspan="2">--pod-eviction-timeout duration     Default: 5m0s</td --> +<td colspan="2">--pod-eviction-timeout duration     默认值：5m0s</td> +</tr> +<tr> +<!-- td></td><td style="line-height: 130%; word-wrap: break-word;">The grace period for deleting pods on failed nodes.</td --> +<td></td><td style="line-height: 130%; word-wrap: break-word;">在失效的节点上删除 Pods 时为其预留的宽限期。</td> +</tr> + +<tr> +<!-- td colspan="2">--profiling     Default: true</td --> +<td colspan="2">--profiling     默认值：true</td> +</tr> +<tr> +<!-- td></td><td style="line-height: 130%; word-wrap: break-word;">Enable profiling via web interface host:port/debug/pprof/</td --> +<td></td><td style="line-height: 130%; word-wrap: break-word;">通过位于 host:port/debug/pprof/ 的 Web 接口启用性能分析。</td> +</tr> + +<tr> +<!-- td colspan="2">--pv-recycler-increment-timeout-nfs int32     Default: 30</td --> +<td colspan="2">--pv-recycler-increment-timeout-nfs int32     默认值：30</td> +</tr> +<tr> +<td></td><td style="line-height: 130%; word-wrap: break-word;">NFS 清洗 Pod 在清洗用过的卷时，根据此标志所设置的秒数，为每清洗 1 GiB 数据增加对应超时时长，作为 activeDeadlineSeconds。</td> +</tr> + +<tr> +<!-- td colspan="2">--pv-recycler-minimum-timeout-hostpath int32     Default: 60</td --> +<td colspan="2">--pv-recycler-minimum-timeout-hostpath int32     默认值：60</td> +</tr> +<tr> +<!-- td></td><td style="line-height: 130%; word-wrap: break-word;">The minimum ActiveDeadlineSeconds to use for a HostPath Recycler pod. This is for development and testing only and will not work in a multi-node cluster.</td --> +<td></td><td style="line-height: 130%; word-wrap: break-word;">对于 HostPath 回收器 Pod，设置其 activeDeadlineSeconds 参数下限。此参数仅用于开发和测试目的，不适合在多节点集群中使用。</td> +</tr> + +<tr> +<!-- td colspan="2">--pv-recycler-minimum-timeout-nfs int32     Default: 300</td --> +<td colspan="2">--pv-recycler-minimum-timeout-nfs int32     默认值：300</td> +</tr> +<tr> +<td></td><td style="line-height: 130%; word-wrap: break-word;">NFS 回收器 Pod 要使用的 activeDeadlineSeconds 参数下限。</td> +</tr> + +<tr> +<td colspan="2">--pv-recycler-pod-template-filepath-hostpath string</td> +</tr> +<tr> +<!-- td></td><td style="line-height: 130%; word-wrap: break-word;">The file path to a pod definition used as a template for HostPath persistent volume recycling. This is for development and testing only and will not work in a multi-node cluster.</td --> +<td></td><td style="line-height: 130%; word-wrap: break-word;">对 HostPath 持久卷进行回收利用时，用作模版的 Pod 定义文件所在路径。此标志仅用于开发和测试目的，不适合多节点集群中使用。</td> +</tr> + +<tr> +<!-- td colspan="2">--pv-recycler-pod-template-filepath-nfs string</td --> +<td colspan="2">--pv-recycler-pod-template-filepath-nfs string</td> +</tr> +<tr> +<td></td><td style="line-height: 130%; word-wrap: break-word;">对 NFS 卷执行回收利用时，用作模版的 Pod 定义文件所在路径。</td> +</tr> + +<tr> +<!-- td colspan="2">--pv-recycler-timeout-increment-hostpath int32     Default: 30</td --> +<td colspan="2">--pv-recycler-timeout-increment-hostpath int32     默认值：30</td> +</tr> +<tr> +<!-- td></td><td style="line-height: 130%; word-wrap: break-word;">the increment of time added per Gi to ActiveDeadlineSeconds for a HostPath scrubber pod. This is for development and testing only and will not work in a multi-node cluster.</td --> +<td></td><td style="line-height: 130%; word-wrap: break-word;">HostPath 清洗器 Pod 在清洗对应类型持久卷时，为每 GiB 数据增加此标志所设置的秒数，作为其 activeDeadlineSeconds 参数。此标志仅用于开发和测试环境，不适合多节点集群环境。</td> +</tr> + +<tr> +<!-- td colspan="2">--pvclaimbinder-sync-period duration     Default: 15s</td --> +<td colspan="2">--pvclaimbinder-sync-period duration     默认值：15s</td> +</tr> +<tr> +<!-- td></td><td style="line-height: 130%; word-wrap: break-word;">The period for syncing persistent volumes and persistent volume claims</td --> +<td></td><td style="line-height: 130%; word-wrap: break-word;">持久卷（PV）和持久卷申领（PVC）对象的同步周期。</td> +</tr> + +<tr> +<td colspan="2">--requestheader-allowed-names stringSlice</td> +</tr> +<tr> +<!-- td></td><td style="line-height: 130%; word-wrap: break-word;">List of client certificate common names to allow to provide usernames in headers specified by --requestheader-username-headers. If empty, any client certificate validated by the authorities in --requestheader-client-ca-file is allowed.</td --> +<td></td><td style="line-height: 130%; word-wrap: break-word;">标志值是客户端证书中的 Common Names 列表。其中所列的名称可以通过 --requestheader-username-headers 所设置的 HTTP 头部来提供用户名。如果此标志值为空表，则被 --requestheader-client-ca-file 中机构所验证过的所有客户端证书都是允许的。</td> +</tr> + +<tr> +<td colspan="2">--requestheader-client-ca-file string</td> +</tr> +<tr> +<!-- td></td><td style="line-height: 130%; word-wrap: break-word;">Root certificate bundle to use to verify client certificates on incoming requests before trusting usernames in headers specified by --requestheader-username-headers. WARNING: generally do not depend on authorization being already done for incoming requests.</td --> +<td></td><td style="line-height: 130%; word-wrap: break-word;">根证书包文件名。在信任通过 --requestheader-username-headers 所指定的任何用户名之前，要使用这里的证书来检查请求中的客户证书。警告：一般不要依赖对请求所作的鉴权结果。</td> +</tr> + +<tr> +<!-- td colspan="2">--requestheader-extra-headers-prefix stringSlice     Default: [x-remote-extra-]</td --> +<td colspan="2">--requestheader-extra-headers-prefix stringSlice     默认值：[x-remote-extra-]</td> +</tr> +<tr> +<!-- td></td><td style="line-height: 130%; word-wrap: break-word;">List of request header prefixes to inspect. X-Remote-Extra- is suggested.</td --> +<td></td><td style="line-height: 130%; word-wrap: break-word;">要插入的请求头部前缀。建议使用 X-Remote-Exra-。</td> +</tr> + +<tr> +<!-- td colspan="2">--requestheader-group-headers stringSlice     Default: [x-remote-group]</td --> +<td colspan="2">--requestheader-group-headers stringSlice     默认值：[x-remote-group]</td> +</tr> +<tr> +<td></td><td style="line-height: 130%; word-wrap: break-word;">用来检查用户组名的请求头部名称列表。建议使用 X-Remote-Group。</td> +</tr> + +<tr> +<!-- td colspan="2">--requestheader-username-headers stringSlice     Default: [x-remote-user]</td--> +<td colspan="2">--requestheader-username-headers stringSlice     默认值：[x-remote-user]</td> +</tr> +<tr> +<td></td><td style="line-height: 130%; word-wrap: break-word;">用来检查用户名的请求头部名称列表。建议使用 X-Remote-User。</td> +</tr> + +<tr> +<!-- td colspan="2">--resource-quota-sync-period duration     Default: 5m0s</td --> +<td colspan="2">--resource-quota-sync-period duration     默认值：5m0s</td> +</tr> +<tr> +<td></td><td style="line-height: 130%; word-wrap: break-word;">对系统中配合用量信息进行同步的周期。</td> +</tr> + +<tr> +<td colspan="2">--root-ca-file string</td> +</tr> +<tr> +<!-- td></td><td style="line-height: 130%; word-wrap: break-word;">If set, this root certificate authority will be included in service account's token secret. This must be a valid PEM-encoded CA bundle.</td --> +<td></td><td style="line-height: 130%; word-wrap: break-word;">如果此标志非空，则在服务账号的令牌 Secret 中会包含此根证书机构。所指定标志值必须是一个合法的 PEM 编码的 CA 证书包。</td> +</tr> + +<tr> +<!-- td colspan="2">--route-reconciliation-period duration     Default: 10s</td --> +<td colspan="2">--route-reconciliation-period duration     默认值：10s</td> +</tr> +<tr> +<!-- td></td><td style="line-height: 130%; word-wrap: break-word;">The period for reconciling routes created for Nodes by cloud provider.</td --> +<td></td><td style="line-height: 130%; word-wrap: break-word;">对云驱动为节点所创建的路由信息进行调解的周期。</td> +</tr> + +<tr> +<!-- td colspan="2">--secondary-node-eviction-rate float32     Default: 0.01</td --> +<td colspan="2">--secondary-node-eviction-rate float32     默认值：0.01</td> +</tr> +<tr> +<!-- td></td><td style="line-height: 130%; word-wrap: break-word;">Number of nodes per second on which pods are deleted in case of node failure when a zone is unhealthy (see --unhealthy-zone-threshold for definition of healthy/unhealthy). Zone refers to entire cluster in non-multizone clusters. This value is implicitly overridden to 0 if the cluster size is smaller than --large-cluster-size-threshold.</td --> +<td></td><td style="line-height: 130%; word-wrap: break-word;">当区域不健康，节点失效时，每秒钟从此标志所给的节点个数上删除 Pods。参见 --unhealthy-zone-threshold 以了解“健康与否”的判定标准。在只有一个区域的集群中，区域指的是整个集群。如果集群规模小于 --large-cluster-size-threshold 所设置的节点个数时，此值被隐式地重设为 0。</td> +</tr> + +<tr> +<!-- td colspan="2">--secure-port int     Default: 10257</td --> +<td colspan="2">--secure-port int     默认值：10257</td> +</tr> +<tr> +<!-- td></td><td style="line-height: 130%; word-wrap: break-word;">The port on which to serve HTTPS with authentication and authorization. If 0, don't serve HTTPS at all.</td --> +<td></td><td style="line-height: 130%; word-wrap: break-word;">在此端口上提供 HTTPS 身份认证和鉴权操作。若此标志值为0，则不提供 HTTPS 服务。</td> +</tr> + +<tr> +<td colspan="2">--service-account-private-key-file string</td> +</tr> +<tr> +<!-- td></td><td style="line-height: 130%; word-wrap: break-word;">Filename containing a PEM-encoded private RSA or ECDSA key used to sign service account tokens.</td --> +<td></td><td style="line-height: 130%; word-wrap: break-word;">包含 PEM 编码的 RSA 或 ECDSA 私钥数据的文件名，这些私钥用来对服务账号令牌签名。</td> +</tr> + +<tr> +<td colspan="2">--service-cluster-ip-range string</td> +</tr> +<tr> +<!-- td></td><td style="line-height: 130%; word-wrap: break-word;">CIDR Range for Services in cluster. Requires --allocate-node-cidrs to be true</td --> +<td></td><td style="line-height: 130%; word-wrap: break-word;">集群中 Service 对象的 CIDR 范围。要求 --allocate-node-cidrs 标志为 true。</td> +</tr> + +<tr> +<td colspan="2">--show-hidden-metrics-for-version string</td> +</tr> +<tr> +<!-- td></td><td style="line-height: 130%; word-wrap: break-word;">The previous version for which you want to show hidden metrics. Only the previous minor version is meaningful, other values will not be allowed. The format is <major>.<minor>, e.g.: '1.16'. The purpose of this format is make sure you have the opportunity to notice if the next release hides additional metrics, rather than being surprised when they are permanently removed in the release after that.</td --> +<td></td><td style="line-height: 130%; word-wrap: break-word;">你希望展示隐藏度量值的上一个版本。只有上一个次版本号有意义，其他值都是不允许的。字符串格式为 "<major>.<minor>"。例如："1.16"。此格式的目的是确保你能够有机会注意到下一个版本隐藏了一些额外的度量值，而不是在更新版本中某些度量值被彻底删除时措手不及。</td> +</tr> + +<tr> +<td colspan="2">--skip-headers</td> +</tr> +<tr> +<!-- td></td><td style="line-height: 130%; word-wrap: break-word;">If true, avoid header prefixes in the log messages</td --> +<td></td><td style="line-height: 130%; word-wrap: break-word;">若此标志为 true，则在日志消息中避免写入头部前缀信息。</td> +</tr> + +<tr> +<td colspan="2">--skip-log-headers</td> +</tr> +<tr> +<!-- td></td><td style="line-height: 130%; word-wrap: break-word;">If true, avoid headers when opening log files</td --> +<td></td><td style="line-height: 130%; word-wrap: break-word;">若此标志为 true，则在写入日志文件时避免写入头部信息。</td> +</tr> + +<tr> +<!-- td colspan="2">--stderrthreshold severity     Default: 2</td --> +<td colspan="2">--stderrthreshold severity     默认值：2</td> +</tr> +<tr> +<!-- td></td><td style="line-height: 130%; word-wrap: break-word;">logs at or above this threshold go to stderr</td --> +<td></td><td style="line-height: 130%; word-wrap: break-word;">等于或大于此阈值的日志信息会被写入到标准错误输出（stderr）。</td> +</tr> + +<tr> +<!-- td colspan="2">--terminated-pod-gc-threshold int32     Default: 12500</td --> +<td colspan="2">--terminated-pod-gc-threshold int32     默认值：12500</td> +</tr> +<tr> +<!-- td></td><td style="line-height: 130%; word-wrap: break-word;">Number of terminated pods that can exist before the terminated pod garbage collector starts deleting terminated pods. If <= 0, the terminated pod garbage collector is disabled.</td --> +<td></td><td style="line-height: 130%; word-wrap: break-word;">在已终止 Pods 垃圾收集器删除已终止 Pods 之前，可以保留的已删除 Pods 的个数上限。若此值小于等于 0，则相当于禁止垃圾回收已终止的 Pods。</td> +</tr> + +<tr> +<td colspan="2">--tls-cert-file string</td> +</tr> +<tr> +<!-- td></td><td style="line-height: 130%; word-wrap: break-word;">File containing the default x509 Certificate for HTTPS. (CA cert, if any, concatenated after server cert). If HTTPS serving is enabled, and --tls-cert-file and --tls-private-key-file are not provided, a self-signed certificate and key are generated for the public address and saved to the directory specified by --cert-dir.</td --> +<td></td><td style="line-height: 130%; word-wrap: break-word;">包含 HTTPS 所用的默认 X509 证书的文件。如果有 CA 证书，会被串接在服务器证书之后。若启用了 HTTPS 服务且 --tls-cert-file 和 --tls-private-key-file 标志未设置，则为节点的公开地址生成自签名的证书和密钥，并保存到 --cert-dir 所给的目录中。</td> +</tr> + +<tr> +<td colspan="2">--tls-cipher-suites stringSlice</td> +</tr> +<tr> +<!-- td></td><td style="line-height: 130%; word-wrap: break-word;">Comma-separated list of cipher suites for the server. If omitted, the default Go cipher suites will be use. Possible values: TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA,TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256,TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA,TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384,TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305,TLS_ECDHE_ECDSA_WITH_RC4_128_SHA,TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA,TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA,TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256,TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA,TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384,TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305,TLS_ECDHE_RSA_WITH_RC4_128_SHA,TLS_RSA_WITH_3DES_EDE_CBC_SHA,TLS_RSA_WITH_AES_128_CBC_SHA,TLS_RSA_WITH_AES_128_CBC_SHA256,TLS_RSA_WITH_AES_128_GCM_SHA256,TLS_RSA_WITH_AES_256_CBC_SHA,TLS_RSA_WITH_AES_256_GCM_SHA384,TLS_RSA_WITH_RC4_128_SHA</td --> +<td></td><td style="line-height: 130%; word-wrap: break-word;">供服务器使用的加密包的逗号分隔列表。若忽略此标志，则使用 Go 语言默认的加密包。可选值包括：TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA,TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256,TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA,TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384,TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305,TLS_ECDHE_ECDSA_WITH_RC4_128_SHA,TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA,TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA,TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256,TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA,TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384,TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305,TLS_ECDHE_RSA_WITH_RC4_128_SHA,TLS_RSA_WITH_3DES_EDE_CBC_SHA,TLS_RSA_WITH_AES_128_CBC_SHA,TLS_RSA_WITH_AES_128_CBC_SHA256,TLS_RSA_WITH_AES_128_GCM_SHA256,TLS_RSA_WITH_AES_256_CBC_SHA,TLS_RSA_WITH_AES_256_GCM_SHA384,TLS_RSA_WITH_RC4_128_SHA</td> +</tr> + +<tr> +<td colspan="2">--tls-min-version string</td> +</tr> +<tr> +<!-- td></td><td style="line-height: 130%; word-wrap: break-word;">Minimum TLS version supported. Possible values: VersionTLS10, VersionTLS11, VersionTLS12, VersionTLS13</td --> +<td></td><td style="line-height: 130%; word-wrap: break-word;">可支持的最低 TLS 版本。可选值包括：“VersionTLS10”、“VersionTLS11”、“VersionTLS12”、“VersionTLS13”。</td> +</tr> + +<tr> +<td colspan="2">--tls-private-key-file string</td> +</tr> +<tr> +<!-- td></td><td style="line-height: 130%; word-wrap: break-word;">File containing the default x509 private key matching --tls-cert-file.</td --> +<td></td><td style="line-height: 130%; word-wrap: break-word;">包含与 --tls-cert-file 对应的默认 X509 私钥的文件。</td> +</tr> + +<tr> +<!-- td colspan="2">--tls-sni-cert-key namedCertKey     Default: []</td --> +<td colspan="2">--tls-sni-cert-key namedCertKey     默认值：[]</td> +</tr> +<tr> +<!-- td></td><td style="line-height: 130%; word-wrap: break-word;">A pair of x509 certificate and private key file paths, optionally suffixed with a list of domain patterns which are fully qualified domain names, possibly with prefixed wildcard segments. The domain patterns also allow IP addresses, but IPs should only be used if the apiserver has visibility to the IP address requested by a client. If no domain patterns are provided, the names of the certificate are extracted. Non-wildcard matches trump over wildcard matches, explicit domain patterns trump over extracted names. For multiple key/certificate pairs, use the --tls-sni-cert-key multiple times. Examples: "example.crt,example.key" or "foo.crt,foo.key:*.foo.com,foo.com".</td --> +<td></td><td style="line-height: 130%; word-wrap: break-word;">X509 证书和私钥文件路径的耦对。作为可选项，可以添加域名模式的列表，其中每个域名模式都是可以带通配片段前缀的全限定域名（FQDN）。域名模式也可以使用 IP 地址字符串，不过只有 API 服务器在所给 IP 地址上对客户端可见时才可以使用 IP 地址。在未提供域名模式时，从证书中提取域名。如果有非通配方式的匹配，则优先于通配方式的匹配；显式的域名模式优先于提取的域名。当存在多个密钥/证书耦对时，可以多次使用 --tls-sni-cert-key 标志。例如：example.crt,example.key 或 foo.crt,foo.key:*.foo.com,foo.com。</td> +</tr> + +<tr> +<!-- td colspan="2">--unhealthy-zone-threshold float32     Default: 0.55</td --> +<td colspan="2">--unhealthy-zone-threshold float32     默认值：0.55</td> +</tr> +<tr> +<!-- td></td><td style="line-height: 130%; word-wrap: break-word;">Fraction of Nodes in a zone which needs to be not Ready (minimum 3) for zone to be treated as unhealthy. </td --> +<td></td><td style="line-height: 130%; word-wrap: break-word;">仅当给定区域中处于非就绪状态的节点（最少 3 个）的占比高于此值时，才将该区域视为不健康。</td> +</tr> + +<tr> +<td colspan="2">--use-service-account-credentials</td> +</tr> +<tr> +<!-- td></td><td style="line-height: 130%; word-wrap: break-word;">If true, use individual service account credentials for each controller.</td --> +<td></td><td style="line-height: 130%; word-wrap: break-word;">当此标志为 true 时，为每个控制器单独使用服务账号凭据。</td> +</tr> + +<tr> +<td colspan="2">-v, --v Level</td> +</tr> +<tr> +<!-- td></td><td style="line-height: 130%; word-wrap: break-word;">number for the log level verbosity</td --> +<td></td><td style="line-height: 130%; word-wrap: break-word;">日志级别详细程度取值</td> +</tr> + +<tr> +<td colspan="2">--version version[=true]</td> +</tr> +<tr> +<!-- td></td><td style="line-height: 130%; word-wrap: break-word;">Print version information and quit</td --> +<td></td><td style="line-height: 130%; word-wrap: break-word;">打印版本信息之后退出</td> +</tr> + +<tr> +<td colspan="2">--vmodule moduleSpec</td> +</tr> +<tr> +<!-- td></td><td style="line-height: 130%; word-wrap: break-word;">comma-separated list of pattern=N settings for file-filtered logging</td --> +<td></td><td style="line-height: 130%; word-wrap: break-word;">由逗号分隔的列表，每一项都是 pattern=N 格式，用来执行根据文件过滤的日志行为。</td> +</tr> + +</tbody> </table> - diff --git a/content/zh/docs/reference/command-line-tools-reference/kube-proxy.md b/content/zh/docs/reference/command-line-tools-reference/kube-proxy.md index e74d615fa4..ffbc4e7ec8 100644 --- a/content/zh/docs/reference/command-line-tools-reference/kube-proxy.md +++ b/content/zh/docs/reference/command-line-tools-reference/kube-proxy.md @@ -1,12 +1,12 @@ --- title: kube-proxy -content_template: templates/tool-reference +content_type: tool-reference weight: 30 --- <!-- --- title: kube-proxy -content_template: templates/tool-reference +content_type: tool-reference weight: 28 --- --> diff --git a/content/zh/docs/reference/command-line-tools-reference/kube-scheduler.md b/content/zh/docs/reference/command-line-tools-reference/kube-scheduler.md index 183bdf46d9..a298d7b280 100644 --- a/content/zh/docs/reference/command-line-tools-reference/kube-scheduler.md +++ b/content/zh/docs/reference/command-line-tools-reference/kube-scheduler.md @@ -1,12 +1,12 @@ --- title: kube-scheduler -content_template: templates/tool-reference +content_type: tool-reference weight: 28 --- <!-- --- title: kube-scheduler -content_template: templates/tool-reference +content_type: tool-reference weight: 28 --- --> @@ -42,973 +42,973 @@ kube-scheduler [flags] </colgroup> <tbody> - <tr> - <td colspan="2">--add-dir-header</td> - </tr> - <tr> - <td></td><td style="line-height: 130%; word-wrap: break-word;"> - <!-- - If true, adds the file directory to the header - --> - 如果为 true，则将文件目录添加到标题中 - </td> - </tr> - - <tr> - <td colspan="2"> - <!-- - --address string     Default: "0.0.0.0" - --> - --address string     默认: "0.0.0.0" - </td> - </tr> - <tr> - <td></td><td style="line-height: 130%; word-wrap: break-word;"> - <!-- - DEPRECATED: the IP address on which to listen for the --port port (set to 0.0.0.0 for all IPv4 interfaces and :: for all IPv6 interfaces). See --bind-address instead. - --> - 弃用: 要监听 --port 端口的 IP 地址（对于所有 IPv4 接口设置为 0.0.0.0，对于所有 IPv6 接口设置为 ::）。 请参阅 --bind-address。 - </td> - </tr> - - <tr> - <td colspan="2">--algorithm-provider string</td> - </tr> - <tr> - <td></td><td style="line-height: 130%; word-wrap: break-word;"> - <!-- - DEPRECATED: the scheduling algorithm provider to use, one of: ClusterAutoscalerProvider | DefaultProvider - --> - 弃用: 要使用的调度算法，可选值：ClusterAutoscalerProvider | DefaultProvider - </td> - </tr> - - <tr> - <td colspan="2">--alsologtostderr</td> - </tr> - <tr> - <td></td><td style="line-height: 130%; word-wrap: break-word;"> - <!-- - 日志记录到标准错误以及文件 - --> - </td> - </tr> - - <tr> - <td colspan="2">--authentication-kubeconfig string</td> - </tr> - <tr> - <td></td><td style="line-height: 130%; word-wrap: break-word;"> - <!-- - 指向具有足够权限以创建 tokenaccessreviews.authentication.k8s.io 的 'core' kubernetes 服务器的 kubeconfig 文件。这是可选的。如果为空，则所有令牌请求均被视为匿名请求，并且不会在集群中查找任何客户端 CA。 - --> - </td> - </tr> - - <tr> - <td colspan="2">--authentication-skip-lookup</td> - </tr> - <tr> - <td></td><td style="line-height: 130%; word-wrap: break-word;"> - <!-- - If false, the authentication-kubeconfig will be used to lookup missing authentication configuration from the cluster. - --> - 如果为 false，则 authentication-kubeconfig 将用于从集群中查找缺少的身份验证配置。 - </td> - </tr> - - <tr> - <td colspan="2"> - <!-- - --authentication-token-webhook-cache-ttl duration     Default: 10s - --> - --authentication-token-webhook-cache-ttl duration     默认: 10s - </td> - </tr> - <tr> - <td></td><td style="line-height: 130%; word-wrap: break-word;"> - <!-- - The duration to cache responses from the webhook token authenticator. - --> - 缓存来自 Webhook 令牌身份验证器的响应的持续时间。 - </td> - </tr> - - <tr> - <td colspan="2"> - <!-- - --authentication-tolerate-lookup-failure     Default: true - --> - --authentication-tolerate-lookup-failure     默认: true - </td> - </tr> - <tr> - <td></td><td style="line-height: 130%; word-wrap: break-word;"> - <!-- - If true, failures to look up missing authentication configuration from the cluster are not considered fatal. Note that this can result in authentication that treats all requests as anonymous. - --> - 如果为 true，则无法从集群中查找缺少的身份验证配置是致命的。请注意，这可能导致身份验证将所有请求视为匿名。 - </td> - </tr> - - <tr> - <td colspan="2"> - <!-- - --authorization-always-allow-paths stringSlice     Default: [/healthz] - --> - --authorization-always-allow-paths stringSlice     默认: [/healthz] - </td> - </tr> - <tr> - <td></td><td style="line-height: 130%; word-wrap: break-word;"> - <!-- - A list of HTTP paths to skip during authorization, i.e. these are authorized without contacting the 'core' kubernetes server. - --> - 在授权过程中跳过的 HTTP 路径列表，即在不联系 'core' kubernetes 服务器的情况下被授权的 HTTP 路径。 - </td> - </tr> - - <tr> - <td colspan="2">--authorization-kubeconfig string</td> - </tr> - <tr> - <td></td><td style="line-height: 130%; word-wrap: break-word;"> - <!-- - kubeconfig file pointing at the 'core' kubernetes server with enough rights to create subjectaccessreviews.authorization.k8s.io. This is optional. If empty, all requests not skipped by authorization are forbidden. - --> - 指向具有足够权限以创建 subjectaccessreviews.authorization.k8s.io 的 'core' kubernetes 服务器的 kubeconfig 文件。这是可选的。如果为空，则禁止所有未经授权跳过的请求。 - </td> - </tr> - - <tr> - <td colspan="2"> - <!-- - --authorization-webhook-cache-authorized-ttl duration     Default: 10s - --> - --authorization-webhook-cache-authorized-ttl duration     默认: 10s - </td> - </tr> - <tr> - <td></td><td style="line-height: 130%; word-wrap: break-word;"> - <!-- - The duration to cache 'authorized' responses from the webhook authorizer. - --> - 缓存来自 Webhook 授权者的 'authorized' 响应的持续时间。 - </td> - </tr> - - <tr> - <td colspan="2"> - <!-- - --authorization-webhook-cache-unauthorized-ttl duration     Default: 10s - --> - --authorization-webhook-cache-unauthorized-ttl duration     默认: 10s - </td> - </tr> - <tr> - <td></td><td style="line-height: 130%; word-wrap: break-word;"> - <!-- - The duration to cache 'unauthorized' responses from the webhook authorizer. - --> - 缓存来自 Webhook 授权者的 'unauthorized' 响应的持续时间。 - </td> - </tr> - - <tr> - <td colspan="2">--azure-container-registry-config string</td> - </tr> - <tr> - <td></td><td style="line-height: 130%; word-wrap: break-word;"> - <!-- - Path to the file containing Azure container registry configuration information. - --> - 包含 Azure 容器仓库配置信息的文件的路径。 - </td> - </tr> - - <tr> - <td colspan="2"> - <!-- - --bind-address ip     Default: 0.0.0.0 - --> - --bind-address ip     默认: 0.0.0.0 - </td> - </tr> - <tr> - <td></td><td style="line-height: 130%; word-wrap: break-word;"> - <!-- - The IP address on which to listen for the --secure-port port. The associated interface(s) must be reachable by the rest of the cluster, and by CLI/web clients. If blank, all interfaces will be used (0.0.0.0 for all IPv4 interfaces and :: for all IPv6 interfaces). - --> - 侦听 --secure-port 端口的 IP 地址。集群的其余部分以及 CLI/ Web 客户端必须可以访问关联的接口。如果为空，将使用所有接口（所有 IPv4 接口使用 0.0.0.0，所有 IPv6 接口使用 ::）。 - </td> - </tr> - - <tr> - <td colspan="2">--cert-dir string</td> - </tr> - <tr> - <td></td><td style="line-height: 130%; word-wrap: break-word;"> - <!-- - The directory where the TLS certs are located. If --tls-cert-file and --tls-private-key-file are provided, this flag will be ignored. - --> - TLS 证书所在的目录。如果提供了--tls-cert-file 和 --tls private-key-file，则将忽略此参数。 - </td> - </tr> - - <tr> - <td colspan="2">--client-ca-file string</td> - </tr> - <tr> - <td></td><td style="line-height: 130%; word-wrap: break-word;"> - <!-- - If set, any request presenting a client certificate signed by one of the authorities in the client-ca-file is authenticated with an identity corresponding to the CommonName of the client certificate. - --> - 如果已设置，由 client-ca-file 中的授权机构签名的客户端证书的任何请求都将使用与客户端证书的 CommonName 对应的身份进行身份验证。 - </td> - </tr> - - <tr> - <td colspan="2">--config string</td> - </tr> - <tr> - <td></td><td style="line-height: 130%; word-wrap: break-word;"> - <!-- - The path to the configuration file. Flags override values in this file. - --> - 配置文件的路径。标志会覆盖此文件中的值。 - </td> - </tr> - - <tr> - <td colspan="2">--contention-profiling</td> - </tr> - <tr> - <td></td><td style="line-height: 130%; word-wrap: break-word;"> - <!-- - DEPRECATED: enable lock contention profiling, if profiling is enabled - --> - 弃用: 如果启用了性能分析，则启用锁竞争分析 - </td> - </tr> - - <tr> - <td colspan="2">--feature-gates mapStringBool</td> - </tr> - <tr> - <td></td><td style="line-height: 130%; word-wrap: break-word;"> - <!-- - A set of key=value pairs that describe feature gates for alpha/experimental features. Options are:<br/>APIListChunking=true|false (BETA - default=true)<br/>APIResponseCompression=true|false (BETA - default=true)<br/>AllAlpha=true|false (ALPHA - default=false)<br/>AppArmor=true|false (BETA - default=true)<br/>AttachVolumeLimit=true|false (BETA - default=true)<br/>BalanceAttachedNodeVolumes=true|false (ALPHA - default=false)<br/>BlockVolume=true|false (BETA - default=true)<br/>BoundServiceAccountTokenVolume=true|false (ALPHA - default=false)<br/>CPUManager=true|false (BETA - default=true)<br/>CRIContainerLogRotation=true|false (BETA - default=true)<br/>CSIBlockVolume=true|false (BETA - default=true)<br/>CSIDriverRegistry=true|false (BETA - default=true)<br/>CSIInlineVolume=true|false (BETA - default=true)<br/>CSIMigration=true|false (ALPHA - default=false)<br/>CSIMigrationAWS=true|false (ALPHA - default=false)<br/>CSIMigrationAzureDisk=true|false (ALPHA - default=false)<br/>CSIMigrationAzureFile=true|false (ALPHA - default=false)<br/>CSIMigrationGCE=true|false (ALPHA - default=false)<br/>CSIMigrationOpenStack=true|false (ALPHA - default=false)<br/>CSINodeInfo=true|false (BETA - default=true)<br/>CustomCPUCFSQuotaPeriod=true|false (ALPHA - default=false)<br/>CustomResourceDefaulting=true|false (BETA - default=true)<br/>DevicePlugins=true|false (BETA - default=true)<br/>DryRun=true|false (BETA - default=true)<br/>DynamicAuditing=true|false (ALPHA - default=false)<br/>DynamicKubeletConfig=true|false (BETA - default=true)<br/>EndpointSlice=true|false (ALPHA - default=false)<br/>EphemeralContainers=true|false (ALPHA - default=false)<br/>EvenPodsSpread=true|false (ALPHA - default=false)<br/>ExpandCSIVolumes=true|false (BETA - default=true)<br/>ExpandInUsePersistentVolumes=true|false (BETA - default=true)<br/>ExpandPersistentVolumes=true|false (BETA - default=true)<br/>ExperimentalHostUserNamespaceDefaulting=true|false (BETA - default=false)<br/>HPAScaleToZero=true|false (ALPHA - default=false)<br/>HyperVContainer=true|false (ALPHA - default=false)<br/>IPv6DualStack=true|false (ALPHA - default=false)<br/>KubeletPodResources=true|false (BETA - default=true)<br/>LegacyNodeRoleBehavior=true|false (ALPHA - default=true)<br/>LocalStorageCapacityIsolation=true|false (BETA - default=true)<br/>LocalStorageCapacityIsolationFSQuotaMonitoring=true|false (ALPHA - default=false)<br/>MountContainers=true|false (ALPHA - default=false)<br/>NodeDisruptionExclusion=true|false (ALPHA - default=false)<br/>NodeLease=true|false (BETA - default=true)<br/>NonPreemptingPriority=true|false (ALPHA - default=false)<br/>PodOverhead=true|false (ALPHA - default=false)<br/>PodShareProcessNamespace=true|false (BETA - default=true)<br/>ProcMountType=true|false (ALPHA - default=false)<br/>QOSReserved=true|false (ALPHA - default=false)<br/>RemainingItemCount=true|false (BETA - default=true)<br/>RemoveSelfLink=true|false (ALPHA - default=false)<br/>RequestManagement=true|false (ALPHA - default=false)<br/>ResourceLimitsPriorityFunction=true|false (ALPHA - default=false)<br/>ResourceQuotaScopeSelectors=true|false (BETA - default=true)<br/>RotateKubeletClientCertificate=true|false (BETA - default=true)<br/>RotateKubeletServerCertificate=true|false (BETA - default=true)<br/>RunAsGroup=true|false (BETA - default=true)<br/>RuntimeClass=true|false (BETA - default=true)<br/>SCTPSupport=true|false (ALPHA - default=false)<br/>ScheduleDaemonSetPods=true|false (BETA - default=true)<br/>ServerSideApply=true|false (BETA - default=true)<br/>ServiceLoadBalancerFinalizer=true|false (BETA - default=true)<br/>ServiceNodeExclusion=true|false (ALPHA - default=false)<br/>StartupProbe=true|false (BETA - default=true)<br/>StorageVersionHash=true|false (BETA - default=true)<br/>StreamingProxyRedirects=true|false (BETA - default=true)<br/>SupportNodePidsLimit=true|false (BETA - default=true)<br/>SupportPodPidsLimit=true|false (BETA - default=true)<br/>Sysctls=true|false (BETA - default=true)<br/>TTLAfterFinished=true|false (ALPHA - default=false)<br/>TaintBasedEvictions=true|false (BETA - default=true)<br/>TaintNodesByCondition=true|false (BETA - default=true)<br/>TokenRequest=true|false (BETA - default=true)<br/>TokenRequestProjection=true|false (BETA - default=true)<br/>TopologyManager=true|false (ALPHA - default=false)<br/>ValidateProxyRedirects=true|false (BETA - default=true)<br/>VolumePVCDataSource=true|false (BETA - default=true)<br/>VolumeSnapshotDataSource=true|false (ALPHA - default=false)<br/>VolumeSubpathEnvExpansion=true|false (BETA - default=true)<br/>WatchBookmark=true|false (BETA - default=true)<br/>WinDSR=true|false (ALPHA - default=false)<br/>WinOverlay=true|false (ALPHA - default=false)<br/>WindowsGMSA=true|false (BETA - default=true)<br/>WindowsRunAsUserName=true|false (ALPHA - default=false) - --> - 一组 key=value 对，描述了 alpha/experimental 特征开关。选项包括：<br/>APIListChunking=true|false (BETA - 默认值=true)<br/>APIResponseCompression=true|false (BETA - 默认值=true)<br/>AllAlpha=true|false (ALPHA - 默认值=false)<br/>AppArmor=true|false (BETA - 默认值=true)<br/>AttachVolumeLimit=true|false (BETA - 默认值=true)<br/>BalanceAttachedNodeVolumes=true|false (ALPHA - 默认值=false)<br/>BlockVolume=true|false (BETA - 默认值=true)<br/>BoundServiceAccountTokenVolume=true|false (ALPHA - 默认值=false)<br/>CPUManager=true|false (BETA - 默认值=true)<br/>CRIContainerLogRotation=true|false (BETA - 默认值=true)<br/>CSIBlockVolume=true|false (BETA - 默认值=true)<br/>CSIDriverRegistry=true|false (BETA - 默认值=true)<br/>CSIInlineVolume=true|false (BETA - 默认值=true)<br/>CSIMigration=true|false (ALPHA - 默认值=false)<br/>CSIMigrationAWS=true|false (ALPHA - 默认值=false)<br/>CSIMigrationAzureDisk=true|false (ALPHA - 默认值=false)<br/>CSIMigrationAzureFile=true|false (ALPHA - 默认值=false)<br/>CSIMigrationGCE=true|false (ALPHA - 默认值=false)<br/>CSIMigrationOpenStack=true|false (ALPHA - 默认值=false)<br/>CSINodeInfo=true|false (BETA - 默认值=true)<br/>CustomCPUCFSQuotaPeriod=true|false (ALPHA - 默认值=false)<br/>CustomResourceDefaulting=true|false (BETA - 默认值=true)<br/>DevicePlugins=true|false (BETA - 默认值=true)<br/>DryRun=true|false (BETA - 默认值=true)<br/>DynamicAuditing=true|false (ALPHA - 默认值=false)<br/>DynamicKubeletConfig=true|false (BETA - 默认值=true)<br/>EndpointSlice=true|false (ALPHA - 默认值=false)<br/>EphemeralContainers=true|false (ALPHA - 默认值=false)<br/>EvenPodsSpread=true|false (ALPHA - 默认值=false)<br/>ExpandCSIVolumes=true|false (BETA - 默认值=true)<br/>ExpandInUsePersistentVolumes=true|false (BETA - 默认值=true)<br/>ExpandPersistentVolumes=true|false (BETA - 默认值=true)<br/>ExperimentalHostUserNamespaceDefaulting=true|false (BETA - 默认值=false)<br/>HPAScaleToZero=true|false (ALPHA - 默认值=false)<br/>HyperVContainer=true|false (ALPHA - 默认值=false)<br/>IPv6DualStack=true|false (ALPHA - 默认值=false)<br/>KubeletPodResources=true|false (BETA - 默认值=true)<br/>LegacyNodeRoleBehavior=true|false (ALPHA - 默认值=true)<br/>LocalStorageCapacityIsolation=true|false (BETA - 默认值=true)<br/>LocalStorageCapacityIsolationFSQuotaMonitoring=true|false (ALPHA - 默认值=false)<br/>MountContainers=true|false (ALPHA - 默认值=false)<br/>NodeDisruptionExclusion=true|false (ALPHA - 默认值=false)<br/>NodeLease=true|false (BETA - 默认值=true)<br/>NonPreemptingPriority=true|false (ALPHA - 默认值=false)<br/>PodOverhead=true|false (ALPHA - 默认值=false)<br/>PodShareProcessNamespace=true|false (BETA - 默认值=true)<br/>ProcMountType=true|false (ALPHA - 默认值=false)<br/>QOSReserved=true|false (ALPHA - 默认值=false)<br/>RemainingItemCount=true|false (BETA - 默认值=true)<br/>RemoveSelfLink=true|false (ALPHA - 默认值=false)<br/>RequestManagement=true|false (ALPHA - 默认值=false)<br/>ResourceLimitsPriorityFunction=true|false (ALPHA - 默认值=false)<br/>ResourceQuotaScopeSelectors=true|false (BETA - 默认值=true)<br/>RotateKubeletClientCertificate=true|false (BETA - 默认值=true)<br/>RotateKubeletServerCertificate=true|false (BETA - 默认值=true)<br/>RunAsGroup=true|false (BETA - 默认值=true)<br/>RuntimeClass=true|false (BETA - 默认值=true)<br/>SCTPSupport=true|false (ALPHA - 默认值=false)<br/>ScheduleDaemonSetPods=true|false (BETA - 默认值=true)<br/>ServerSideApply=true|false (BETA - 默认值=true)<br/>ServiceLoadBalancerFinalizer=true|false (BETA - 默认值=true)<br/>ServiceNodeExclusion=true|false (ALPHA - 默认值=false)<br/>StartupProbe=true|false (BETA - 默认值=true)<br/>StorageVersionHash=true|false (BETA - 默认值=true)<br/>StreamingProxyRedirects=true|false (BETA - 默认值=true)<br/>SupportNodePidsLimit=true|false (BETA - 默认值=true)<br/>SupportPodPidsLimit=true|false (BETA - 默认值=true)<br/>Sysctls=true|false (BETA - 默认值=true)<br/>TTLAfterFinished=true|false (ALPHA - 默认值=false)<br/>TaintBasedEvictions=true|false (BETA - 默认值=true)<br/>TaintNodesByCondition=true|false (BETA - 默认值=true)<br/>TokenRequest=true|false (BETA - 默认值=true)<br/>TokenRequestProjection=true|false (BETA - 默认值=true)<br/>TopologyManager=true|false (ALPHA - 默认值=false)<br/>ValidateProxyRedirects=true|false (BETA - 默认值=true)<br/>VolumePVCDataSource=true|false (BETA - 默认值=true)<br/>VolumeSnapshotDataSource=true|false (ALPHA - 默认值=false)<br/>VolumeSubpathEnvExpansion=true|false (BETA - 默认值=true)<br/>WatchBookmark=true|false (BETA - 默认值=true)<br/>WinDSR=true|false (ALPHA - 默认值=false)<br/>WinOverlay=true|false (ALPHA - 默认值=false)<br/>WindowsGMSA=true|false (BETA - 默认值=true)<br/>WindowsRunAsUserName=true|false (ALPHA - 默认值=false) - </td> - </tr> - - <tr> - <td colspan="2"> - <!-- - --hard-pod-affinity-symmetric-weight int32     Default: 1 - --> - --hard-pod-affinity-symmetric-weight int32     默认: 1 - </td> - </tr> - <tr> - <td></td><td style="line-height: 130%; word-wrap: break-word;"> - <!-- - DEPRECATED: RequiredDuringScheduling affinity is not symmetric, but there is an implicit PreferredDuringScheduling affinity rule corresponding to every RequiredDuringScheduling affinity rule. --hard-pod-affinity-symmetric-weight represents the weight of implicit PreferredDuringScheduling affinity rule. Must be in the range 0-100.This option was moved to the policy configuration file - --> - 弃用: RequiredDuringScheduling 亲和力不是对称的，但是存在与每个 RequiredDuringScheduling 关联性规则相对应的隐式 PreferredDuringScheduling 关联性规则 --hard-pod-affinity-symmetric-weight 代表隐式 PreferredDuringScheduling 关联性规则的权重。权重必须在 0-100 范围内。此选项已移至策略配置文件。 - </td> - </tr> - - <tr> - <td colspan="2">-h, --help</td> - </tr> - <tr> - <td></td><td style="line-height: 130%; word-wrap: break-word;"> - <!-- - help for kube-scheduler - --> - kube-scheduler 帮助命令 - </td> - </tr> - - <tr> - <td colspan="2">--http2-max-streams-per-connection int</td> - </tr> - <tr> - <td></td><td style="line-height: 130%; word-wrap: break-word;"> - <!-- - The limit that the server gives to clients for the maximum number of streams in an HTTP/2 connection. Zero means to use golang's default. - --> - 服务器为客户端提供的 HTTP/2 连接最大限制。零表示使用 golang 的默认值。 - </td> - </tr> - - <tr> - <td colspan="2"> - <!-- - --kube-api-burst int32     Default: 100 - --> - --kube-api-burst int32     默认: 100 - </td> - </tr> - <tr> - <td></td><td style="line-height: 130%; word-wrap: break-word;"> - <!-- - DEPRECATED: burst to use while talking with kubernetes apiserver - --> - 弃用: 与 kubernetes apiserver 通信时使用 - </td> - </tr> - - <tr> - <td colspan="2"> - <!-- - --kube-api-content-type string     Default: "application/vnd.kubernetes.protobuf" - --> - --kube-api-content-type string     默认: "application/vnd.kubernetes.protobuf" - </td> - </tr> - <tr> - <td></td><td style="line-height: 130%; word-wrap: break-word;"> - <!-- - DEPRECATED: content type of requests sent to apiserver. - --> - 弃用: 发送到 apiserver 的请求的内容类型。 - </td> - </tr> - - <tr> - <td colspan="2"> - <!-- - --kube-api-qps float32     Default: 50 - --> - --kube-api-qps float32     默认: 50 - </td> - </tr> - <tr> - <td></td><td style="line-height: 130%; word-wrap: break-word;"> - <!-- - DEPRECATED: QPS to use while talking with kubernetes apiserver - --> - 弃用: 与 kubernetes apiserver 通信时要使用的 QPS - </td> - </tr> - - <tr> - <td colspan="2">--kubeconfig string</td> - </tr> - <tr> - <td></td><td style="line-height: 130%; word-wrap: break-word;"> - <!-- - DEPRECATED: path to kubeconfig file with authorization and master location information. - --> - 弃用: 具有授权和主节点位置信息的 kubeconfig 文件的路径。 - </td> - </tr> - - <tr> - <td colspan="2"> - <!-- - --leader-elect     Default: true - --> - --leader-elect     默认: true - </td> - </tr> - <tr> - <td></td><td style="line-height: 130%; word-wrap: break-word;"> - <!-- - Start a leader election client and gain leadership before executing the main loop. Enable this when running replicated components for high availability. - --> - 在执行主循环之前，开始领导者选举并选出领导者。为实现高可用性，运行多副本的组件并选出领导者。 - </td> - </tr> - - <tr> - <td colspan="2"> - <!-- - --leader-elect-lease-duration duration     Default: 15s - --> - --leader-elect-lease-duration duration     默认: 15s - </td> - </tr> - <tr> - <td></td><td style="line-height: 130%; word-wrap: break-word;"> - <!-- - The duration that non-leader candidates will wait after observing a leadership renewal until attempting to acquire leadership of a led but unrenewed leader slot. This is effectively the maximum duration that a leader can be stopped before it is replaced by another candidate. This is only applicable if leader election is enabled. - --> - 非领导者候选人在观察到领导者更新后将等待直到试图获得领导但未更新的领导者职位的等待时间。这实际上是领导者在被另一位候选人替代之前可以停止的最大持续时间。该情况仅在启用了领导者选举的情况下才适用。 - </td> - </tr> - - <tr> - <td colspan="2"> - <!-- - --leader-elect-renew-deadline duration     Default: 10s - --> - --leader-elect-renew-deadline duration     默认: 10s - </td> - </tr> - <tr> - <td></td><td style="line-height: 130%; word-wrap: break-word;"> - <!-- - The interval between attempts by the acting master to renew a leadership slot before it stops leading. This must be less than or equal to the lease duration. This is only applicable if leader election is enabled. - --> - </td> - 领导者尝试在停止领导之前更新领导职位的间隔时间。该时间必须小于或等于租赁期限。仅在启用了领导者选举的情况下才适用。 - </tr> - - <tr> - <td colspan="2"> - <!-- - --leader-elect-resource-lock endpoints     Default: "endpoints" - --> - --leader-elect-resource-lock endpoints     默认: "endpoints" - </td> - </tr> - <tr> - <td></td><td style="line-height: 130%; word-wrap: break-word;"> - <!-- - The type of resource object that is used for locking during leader election. Supported options are endpoints (default) and `configmaps`. - --> - 在领导者选举期间用于锁定的资源对象的类型。支持的选项是端点（默认）和 `configmaps` - </td> - </tr> - - <tr> - <td colspan="2"> - <!-- - --leader-elect-resource-name string     Default: "kube-scheduler" - --> - --leader-elect-resource-name string     默认: "kube-scheduler" - </td> - </tr> - <tr> - <td></td><td style="line-height: 130%; word-wrap: break-word;"> - <!-- - The name of resource object that is used for locking during leader election. - --> - 在领导者选举期间用于锁定的资源对象的名称。 - </td> - </tr> - - <tr> - <td colspan="2"> - <!-- - --leader-elect-resource-namespace string     Default: "kube-system" - --> - --leader-elect-resource-namespace string     默认: "kube-system" - </td> - </tr> - <tr> - <td></td><td style="line-height: 130%; word-wrap: break-word;"> - <!-- - The namespace of resource object that is used for locking during leader election. - --> - 在领导者选举期间用于锁定的资源对象的命名空间。 - </td> - </tr> - - <tr> - <td colspan="2"> - <!-- - --leader-elect-retry-period duration     Default: 2s - --> - --leader-elect-retry-period duration     默认: 2s - </td> - </tr> - <tr> - <td></td><td style="line-height: 130%; word-wrap: break-word;"> - <!-- - The duration the clients should wait between attempting acquisition and renewal of a leadership. This is only applicable if leader election is enabled. - --> - 客户应在尝试获取和更新领导之间等待的时间。仅在启用了领导者选举的情况下才适用。 - </td> - </tr> - - <tr> - <td colspan="2"> - <!-- - --lock-object-name string     Default: "kube-scheduler" - --> - --lock-object-name string     默认: "kube-scheduler" - </td> - </tr> - <tr> - <td></td><td style="line-height: 130%; word-wrap: break-word;"> - <!-- - DEPRECATED: define the name of the lock object. Will be removed in favor of leader-elect-resource-name - --> - 弃用: 定义锁对象的名称。将被删除以便使用 Leader-elect-resource-name - </td> - </tr> - - <tr> - <td colspan="2"> - <!-- - --lock-object-namespace string     Default: "kube-system" - --> - --lock-object-namespace string     默认: "kube-system" - </td> - </tr> - <tr> - <td></td><td style="line-height: 130%; word-wrap: break-word;"> - <!-- - DEPRECATED: define the namespace of the lock object. Will be removed in favor of leader-elect-resource-namespace. - --> - 弃用: 定义锁对象的命名空间。将被删除以便使用 leader-elect-resource-namespace。 - </td> - </tr> - - <tr> - <td colspan="2"> - <!-- - --log-backtrace-at traceLocation     Default: :0 - --> - --log-backtrace-at traceLocation     默认: :0 - </td> - </tr> - <tr> - <td></td><td style="line-height: 130%; word-wrap: break-word;"> - <!-- - when logging hits line file:N, emit a stack trace - --> - 当记录命中行文件：N 时发出堆栈跟踪 - </td> - </tr> - - <tr> - <td colspan="2">--log-dir string</td> - </tr> - <tr> - <td></td><td style="line-height: 130%; word-wrap: break-word;"> - <!-- - If non-empty, write log files in this directory - --> - 如果为非空，则在此目录中写入日志文件 - </td> - </tr> - - <tr> - <td colspan="2">--log-file string</td> - </tr> - <tr> - <td></td><td style="line-height: 130%; word-wrap: break-word;"> - <!-- - If non-empty, use this log file - --> - 如果为非空，请使用此日志文件 - </td> - </tr> - - <tr> - <td colspan="2"> - <!-- - --log-file-max-size uint     Default: 1800 - --> - --log-file-max-size uint     默认: 1800 - </td> - </tr> - <tr> - <td></td><td style="line-height: 130%; word-wrap: break-word;"> - <!-- - Defines the maximum size a log file can grow to. Unit is megabytes. If the value is 0, the maximum file size is unlimited. - --> - 定义日志文件可以增长到的最大值。单位为兆字节。如果值为0，则最大文件大小为无限制。 - </td> - </tr> - - <tr> - <td colspan="2"> - <!-- - --log-flush-frequency duration     Default: 5s - --> - --log-flush-frequency duration     默认: 5s - </td> - </tr> - <tr> - <td></td><td style="line-height: 130%; word-wrap: break-word;"> - <!-- - Maximum number of seconds between log flushes - --> - 两次日志刷新之间的最大秒数 - </td> - </tr> - - <tr> - <td colspan="2"> - <!-- - --logtostderr     Default: true - --> - --logtostderr     默认: true - </td> - </tr> - <tr> - <td></td><td style="line-height: 130%; word-wrap: break-word;"> - <!-- - log to standard error instead of files - --> - 日志记录到标准错误而不是文件 - </td> - </tr> - - <tr> - <td colspan="2">--master string</td> - </tr> - <tr> - <td></td><td style="line-height: 130%; word-wrap: break-word;"> - <!-- - The address of the Kubernetes API server (overrides any value in kubeconfig) - --> - Kubernetes API 服务器的地址（覆盖 kubeconfig 中的任何值） - </td> - </tr> - - <tr> - <td colspan="2">--policy-config-file string</td> - </tr> - <tr> - <td></td><td style="line-height: 130%; word-wrap: break-word;"> - <!-- - DEPRECATED: file with scheduler policy configuration. This file is used if policy ConfigMap is not provided or --use-legacy-policy-config=true - --> - 弃用：具有调度程序策略配置的文件。如果未提供 policy ConfigMap 或 --use-legacy-policy-config = true，则使用此文件 - </td> - </tr> - - <tr> - <td colspan="2">--policy-configmap string</td> - </tr> - <tr> - <td></td><td style="line-height: 130%; word-wrap: break-word;"> - <!-- - DEPRECATED: name of the ConfigMap object that contains scheduler's policy configuration. It must exist in the system namespace before scheduler initialization if --use-legacy-policy-config=false. The config must be provided as the value of an element in 'Data' map with the key='policy.cfg' - --> - 弃用: 包含调度程序策略配置的 ConfigMap 对象的名称。如果 --use-legacy-policy-config = false，则它必须在调度程序初始化之前存在于系统命名空间中。必须将配置作为键为 'policy.cfg' 的 'Data' 映射中元素的值提供 - </td> - </tr> - - <tr> - <td colspan="2"> - <!-- - --policy-configmap-namespace string     Default: "kube-system" - --> - --policy-configmap-namespace string     默认: "kube-system" - </td> - </tr> - <tr> - <td></td><td style="line-height: 130%; word-wrap: break-word;"> - <!-- - DEPRECATED: the namespace where policy ConfigMap is located. The kube-system namespace will be used if this is not provided or is empty. - --> - 弃用: 策略 ConfigMap 所在的命名空间。如果未提供或为空，则将使用 kube-system 命名空间。 - </td> - </tr> - - <tr> - <td colspan="2"> - <!-- - --port int     Default: 10251 - --> - --port int     默认: 10251 - </td> - </tr> - <tr> - <td></td><td style="line-height: 130%; word-wrap: break-word;"> - <!-- - DEPRECATED: the port on which to serve HTTP insecurely without authentication and authorization. If 0, don't serve plain HTTP at all. See --secure-port instead. - --> - 弃用: 在没有身份验证和授权的情况下不安全地为 HTTP 服务的端口。如果为0，则根本不提供 HTTP。请参见--secure-port。 - </td> - </tr> - - <tr> - <td colspan="2">--profiling</td> - </tr> - <tr> - <td></td><td style="line-height: 130%; word-wrap: break-word;"> - <!-- - DEPRECATED: enable profiling via web interface host:port/debug/pprof/ - --> - 弃用: 通过 Web 界面主机启用配置文件：port/debug/pprof/ - </td> - </tr> - - <tr> - <td colspan="2">--requestheader-allowed-names stringSlice</td> - </tr> - <tr> - <td></td><td style="line-height: 130%; word-wrap: break-word;"> - <!-- - List of client certificate common names to allow to provide usernames in headers specified by --requestheader-username-headers. If empty, any client certificate validated by the authorities in --requestheader-client-ca-file is allowed. - --> - 客户端证书通用名称列表允许在 --requestheader-username-headers 指定的头部中提供用户名。如果为空，则允许任何由权威机构 --requestheader-client-ca-file 验证的客户端证书。 - </td> - </tr> - - <tr> - <td colspan="2">--requestheader-client-ca-file string</td> - </tr> - <tr> - <td></td><td style="line-height: 130%; word-wrap: break-word;"> - <!-- - Root certificate bundle to use to verify client certificates on incoming requests before trusting usernames in headers specified by --requestheader-username-headers. WARNING: generally do not depend on authorization being already done for incoming requests. - --> - 在信任 --requestheader-username-headers 指定的头部中的用户名之前用于验证传入请求上的客户端证书的根证书包。警告：通常不依赖于传入请求已经完成的授权。 - </td> - </tr> - - <tr> - <td colspan="2"> - <!-- - --requestheader-extra-headers-prefix stringSlice     Default: [x-remote-extra-] - --> - --requestheader-extra-headers-prefix stringSlice     默认: [x-remote-extra-] - </td> - </tr> - <tr> - <td></td><td style="line-height: 130%; word-wrap: break-word;"> - <!-- - List of request header prefixes to inspect. X-Remote-Extra- is suggested. - --> - 要检查请求头部前缀列表。建议使用 X-Remote-Extra- - </td> - </tr> - - <tr> - <td colspan="2"> - <!-- - --requestheader-group-headers stringSlice     Default: [x-remote-group] - --> - --requestheader-group-headers stringSlice     默认: [x-remote-group] - </td> - </tr> - <tr> - <td></td><td style="line-height: 130%; word-wrap: break-word;"> - <!-- - List of request headers to inspect for groups. X-Remote-Group is suggested. - --> - 用于检查组的请求头部列表。建议使用 X-Remote-Group。 - </td> - </tr> - - <tr> - <td colspan="2"> - <!-- - --requestheader-username-headers stringSlice     Default: [x-remote-user] - --> - --requestheader-username-headers stringSlice     默认: [x-remote-user] - </td> - </tr> - <tr> - <td></td><td style="line-height: 130%; word-wrap: break-word;"> - <!-- - List of request headers to inspect for usernames. X-Remote-User is common. - --> - 用于检查用户名的请求头部列表。 X-Remote-User 很常见。 - </td> - </tr> - - <tr> - <td colspan="2"> - <!-- - --scheduler-name string     Default: "default-scheduler" - --> - --scheduler-name string     默认: "default-scheduler" - </td> - </tr> - <tr> - <td></td><td style="line-height: 130%; word-wrap: break-word;"> - <!-- - DEPRECATED: name of the scheduler, used to select which pods will be processed by this scheduler, based on pod's "spec.schedulerName". - --> - 弃用: 调度程序名称用于根据 Pod 的 "spec.schedulerName" 选择此调度程序将处理的 Pod。 - </td> - </tr> - - <tr> - <td colspan="2"> - <!-- - --secure-port int     Default: 10259 - --> - --secure-port int     默认: 10259 - </td> - </tr> - <tr> - <td></td><td style="line-height: 130%; word-wrap: break-word;"> - <!-- - The port on which to serve HTTPS with authentication and authorization.If 0, don't serve HTTPS at all. - --> - 通过身份验证和授权为 HTTPS 服务的端口。如果为 0，则根本不提供 HTTPS。 - </td> - </tr> - - <tr> - <td colspan="2">--skip-headers</td> - </tr> - <tr> - <td></td><td style="line-height: 130%; word-wrap: break-word;"> - <!-- - If true, avoid header prefixes in the log messages - --> - 如果为 true，请在日志消息中避免头部前缀 - </td> - </tr> - - <tr> - <td colspan="2">--skip-log-headers</td> - </tr> - <tr> - <td></td><td style="line-height: 130%; word-wrap: break-word;"> - <!-- - If true, avoid headers when opening log files - --> - 如果为true，则在打开日志文件时避免头部 - </td> - </tr> - - <tr> - <td colspan="2"> - <!-- - --stderrthreshold severity     Default: 2 - --> - --stderrthreshold severity     默认: 2 - </td> - </tr> - <tr> - <td></td><td style="line-height: 130%; word-wrap: break-word;"> - <!-- - logs at or above this threshold go to stderr - --> - 达到或超过此阈值的日志转到 stderr - </td> - </tr> - - <tr> - <td colspan="2">--tls-cert-file string</td> - </tr> - <tr> - <td></td><td style="line-height: 130%; word-wrap: break-word;"> - <!-- - File containing the default x509 Certificate for HTTPS. (CA cert, if any, concatenated after server cert). If HTTPS serving is enabled, and --tls-cert-file and --tls-private-key-file are not provided, a self-signed certificate and key are generated for the public address and saved to the directory specified by --cert-dir. - --> - 包含默认的 HTTPS x509 证书的文件。（CA证书（如果有）在服务器证书之后并置）。如果启用了 HTTPS 服务，并且未提供 --tls-cert-file 和 --tls-private-key-file，则会为公共地址生成一个自签名证书和密钥，并将其保存到 --cert-dir 指定的目录中。 - </td> - </tr> - - <tr> - <td colspan="2">--tls-cipher-suites stringSlice</td> - </tr> - <tr> - <td></td><td style="line-height: 130%; word-wrap: break-word;"> - <!-- - Comma-separated list of cipher suites for the server. If omitted, the default Go cipher suites will be use. Possible values: TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA,TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256,TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA,TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384,TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305,TLS_ECDHE_ECDSA_WITH_RC4_128_SHA,TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA,TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA,TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256,TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA,TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384,TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305,TLS_ECDHE_RSA_WITH_RC4_128_SHA,TLS_RSA_WITH_3DES_EDE_CBC_SHA,TLS_RSA_WITH_AES_128_CBC_SHA,TLS_RSA_WITH_AES_128_CBC_SHA256,TLS_RSA_WITH_AES_128_GCM_SHA256,TLS_RSA_WITH_AES_256_CBC_SHA,TLS_RSA_WITH_AES_256_GCM_SHA384,TLS_RSA_WITH_RC4_128_SHA - --> - 服务器的密码套件列表，以逗号分隔。如果省略，将使用默认的 Go 密码套件。可能的值： - TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA,TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256,TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA,TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384,TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305,TLS_ECDHE_ECDSA_WITH_RC4_128_SHA,TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA,TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA,TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256,TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA,TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384,TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305,TLS_ECDHE_RSA_WITH_RC4_128_SHA,TLS_RSA_WITH_3DES_EDE_CBC_SHA,TLS_RSA_WITH_AES_128_CBC_SHA,TLS_RSA_WITH_AES_128_CBC_SHA256,TLS_RSA_WITH_AES_128_GCM_SHA256,TLS_RSA_WITH_AES_256_CBC_SHA,TLS_RSA_WITH_AES_256_GCM_SHA384,TLS_RSA_WITH_RC4_128_SHA - </td> - </tr> - - <tr> - <td colspan="2">--tls-min-version string</td> - </tr> - <tr> - <td></td><td style="line-height: 130%; word-wrap: break-word;"> - <!-- - Minimum TLS version supported. Possible values: VersionTLS10, VersionTLS11, VersionTLS12, VersionTLS13 - --> - 支持的最低 TLS 版本。可能的值：VersionTLS10, VersionTLS11, VersionTLS12, VersionTLS13 - </td> - </tr> - - <tr> - <td colspan="2">--tls-private-key-file string</td> - </tr> - <tr> - <td></td><td style="line-height: 130%; word-wrap: break-word;"> - <!-- - File containing the default x509 private key matching --tls-cert-file. - --> - 包含与 --tls-cert-file 匹配的默认 x509 私钥的文件。 - </td> - </tr> - - <tr> - <td colspan="2"> - <!-- - --tls-sni-cert-key namedCertKey     Default: [] - --> - --tls-sni-cert-key namedCertKey     默认: [] - </td> - </tr> - <tr> - <td></td><td style="line-height: 130%; word-wrap: break-word;"> - <!-- - A pair of x509 certificate and private key file paths, optionally suffixed with a list of domain patterns which are fully qualified domain names, possibly with prefixed wildcard segments. If no domain patterns are provided, the names of the certificate are extracted. Non-wildcard matches trump over wildcard matches, explicit domain patterns trump over extracted names. For multiple key/certificate pairs, use the --tls-sni-cert-key multiple times. Examples: "example.crt,example.key" or "foo.crt,foo.key:*.foo.com,foo.com". - --> - 一对 x509 证书和私钥文件路径，可选地后缀为完全限定域名的域模式列表，并可能带有前缀的通配符段。如果未提供域模式，则获取证书名称。非通配符匹配胜过通配符匹配，显式域模式胜过获取名称。 对于多个密钥/证书对，请多次使用 --tls-sni-cert-key。例如: "example.crt,example.key" 或者 "foo.crt,foo.key:*.foo.com,foo.com"。 - </td> - </tr> - - <tr> - <td colspan="2">--use-legacy-policy-config</td> - </tr> - <tr> - <td></td><td style="line-height: 130%; word-wrap: break-word;"> - <!-- - DEPRECATED: when set to true, scheduler will ignore policy ConfigMap and uses policy config file - --> - 弃用: 设置为 true 时，调度程序将忽略策略 ConfigMap 并使用策略配置文件 - </td> - </tr> - - <tr> - <td colspan="2">-v, --v Level</td> - </tr> - <tr> - <td></td><td style="line-height: 130%; word-wrap: break-word;"> - <!-- - number for the log level verbosity - --> - 日志级别详细程度的数字 - </td> - </tr> - - <tr> - <td colspan="2">--version version[=true]</td> - </tr> - <tr> - <td></td><td style="line-height: 130%; word-wrap: break-word;"> - <!-- - Print version information and quit - --> - 打印版本信息并退出 - </td> - </tr> - - <tr> - <td colspan="2">--vmodule moduleSpec</td> - </tr> - <tr> - <td></td><td style="line-height: 130%; word-wrap: break-word;"> - <!-- - comma-separated list of pattern=N settings for file-filtered logging - --> - 以逗号分隔的 pattern = N 设置列表，用于文件过滤的日志记录 - </td> - </tr> - - <tr> - <td colspan="2">--write-config-to string</td> - </tr> - <tr> - <td></td><td style="line-height: 130%; word-wrap: break-word;"> - <!-- - If set, write the configuration values to this file and exit. - --> - 如果已设置，请将配置值写入此文件并退出。 - </td> - </tr> +<tr> + <td colspan="2">--add-dir-header</td> +</tr> +<tr> + <td></td><td style="line-height: 130%; word-wrap: break-word;"> + <!-- + If true, adds the file directory to the header + --> + 如果为 true，则将文件目录添加到标题中 + </td> +</tr> + +<tr> + <td colspan="2"> + <!-- + --address string     Default: "0.0.0.0" + --> + --address string     默认: "0.0.0.0" + </td> +</tr> +<tr> + <td></td><td style="line-height: 130%; word-wrap: break-word;"> + <!-- + DEPRECATED: the IP address on which to listen for the --port port (set to 0.0.0.0 for all IPv4 interfaces and :: for all IPv6 interfaces). See --bind-address instead. + --> + 弃用: 要监听 --port 端口的 IP 地址（对于所有 IPv4 接口设置为 0.0.0.0，对于所有 IPv6 接口设置为 ::）。 请参阅 --bind-address。 + </td> +</tr> + +<tr> + <td colspan="2">--algorithm-provider string</td> +</tr> +<tr> + <td></td><td style="line-height: 130%; word-wrap: break-word;"> + <!-- + DEPRECATED: the scheduling algorithm provider to use, one of: ClusterAutoscalerProvider | DefaultProvider + --> + 弃用: 要使用的调度算法，可选值：ClusterAutoscalerProvider | DefaultProvider + </td> +</tr> + +<tr> + <td colspan="2">--alsologtostderr</td> +</tr> +<tr> + <td></td><td style="line-height: 130%; word-wrap: break-word;"> + <!-- + 日志记录到标准错误以及文件 + --> + </td> +</tr> + +<tr> + <td colspan="2">--authentication-kubeconfig string</td> +</tr> +<tr> + <td></td><td style="line-height: 130%; word-wrap: break-word;"> + <!-- + 指向具有足够权限以创建 tokenaccessreviews.authentication.k8s.io 的 'core' kubernetes 服务器的 kubeconfig 文件。这是可选的。如果为空，则所有令牌请求均被视为匿名请求，并且不会在集群中查找任何客户端 CA。 + --> + </td> +</tr> + +<tr> + <td colspan="2">--authentication-skip-lookup</td> +</tr> +<tr> + <td></td><td style="line-height: 130%; word-wrap: break-word;"> + <!-- + If false, the authentication-kubeconfig will be used to lookup missing authentication configuration from the cluster. + --> + 如果为 false，则 authentication-kubeconfig 将用于从集群中查找缺少的身份验证配置。 + </td> +</tr> + +<tr> + <td colspan="2"> + <!-- + --authentication-token-webhook-cache-ttl duration     Default: 10s + --> + --authentication-token-webhook-cache-ttl duration     默认: 10s + </td> +</tr> +<tr> + <td></td><td style="line-height: 130%; word-wrap: break-word;"> + <!-- + The duration to cache responses from the webhook token authenticator. + --> + 缓存来自 Webhook 令牌身份验证器的响应的持续时间。 + </td> +</tr> + +<tr> + <td colspan="2"> + <!-- + --authentication-tolerate-lookup-failure     Default: true + --> + --authentication-tolerate-lookup-failure     默认: true + </td> +</tr> +<tr> + <td></td><td style="line-height: 130%; word-wrap: break-word;"> + <!-- + If true, failures to look up missing authentication configuration from the cluster are not considered fatal. Note that this can result in authentication that treats all requests as anonymous. + --> + 如果为 true，则无法从集群中查找缺少的身份验证配置是致命的。请注意，这可能导致身份验证将所有请求视为匿名。 + </td> +</tr> + +<tr> + <td colspan="2"> + <!-- + --authorization-always-allow-paths stringSlice     Default: [/healthz] + --> + --authorization-always-allow-paths stringSlice     默认: [/healthz] + </td> +</tr> +<tr> + <td></td><td style="line-height: 130%; word-wrap: break-word;"> + <!-- + A list of HTTP paths to skip during authorization, i.e. these are authorized without contacting the 'core' kubernetes server. + --> + 在授权过程中跳过的 HTTP 路径列表，即在不联系 'core' kubernetes 服务器的情况下被授权的 HTTP 路径。 + </td> +</tr> + +<tr> + <td colspan="2">--authorization-kubeconfig string</td> +</tr> +<tr> + <td></td><td style="line-height: 130%; word-wrap: break-word;"> + <!-- + kubeconfig file pointing at the 'core' kubernetes server with enough rights to create subjectaccessreviews.authorization.k8s.io. This is optional. If empty, all requests not skipped by authorization are forbidden. + --> + 指向具有足够权限以创建 subjectaccessreviews.authorization.k8s.io 的 'core' kubernetes 服务器的 kubeconfig 文件。这是可选的。如果为空，则禁止所有未经授权跳过的请求。 + </td> +</tr> + +<tr> + <td colspan="2"> + <!-- + --authorization-webhook-cache-authorized-ttl duration     Default: 10s + --> + --authorization-webhook-cache-authorized-ttl duration     默认: 10s + </td> +</tr> +<tr> + <td></td><td style="line-height: 130%; word-wrap: break-word;"> + <!-- + The duration to cache 'authorized' responses from the webhook authorizer. + --> + 缓存来自 Webhook 授权者的 'authorized' 响应的持续时间。 + </td> +</tr> + +<tr> + <td colspan="2"> + <!-- + --authorization-webhook-cache-unauthorized-ttl duration     Default: 10s + --> + --authorization-webhook-cache-unauthorized-ttl duration     默认: 10s + </td> +</tr> +<tr> + <td></td><td style="line-height: 130%; word-wrap: break-word;"> + <!-- + The duration to cache 'unauthorized' responses from the webhook authorizer. + --> + 缓存来自 Webhook 授权者的 'unauthorized' 响应的持续时间。 + </td> +</tr> + +<tr> + <td colspan="2">--azure-container-registry-config string</td> +</tr> +<tr> + <td></td><td style="line-height: 130%; word-wrap: break-word;"> + <!-- + Path to the file containing Azure container registry configuration information. + --> + 包含 Azure 容器仓库配置信息的文件的路径。 + </td> +</tr> + +<tr> + <td colspan="2"> + <!-- + --bind-address ip     Default: 0.0.0.0 + --> + --bind-address ip     默认: 0.0.0.0 + </td> +</tr> +<tr> + <td></td><td style="line-height: 130%; word-wrap: break-word;"> + <!-- + The IP address on which to listen for the --secure-port port. The associated interface(s) must be reachable by the rest of the cluster, and by CLI/web clients. If blank, all interfaces will be used (0.0.0.0 for all IPv4 interfaces and :: for all IPv6 interfaces). + --> + 侦听 --secure-port 端口的 IP 地址。集群的其余部分以及 CLI/ Web 客户端必须可以访问关联的接口。如果为空，将使用所有接口（所有 IPv4 接口使用 0.0.0.0，所有 IPv6 接口使用 ::）。 + </td> +</tr> + +<tr> + <td colspan="2">--cert-dir string</td> +</tr> +<tr> + <td></td><td style="line-height: 130%; word-wrap: break-word;"> + <!-- + The directory where the TLS certs are located. If --tls-cert-file and --tls-private-key-file are provided, this flag will be ignored. + --> + TLS 证书所在的目录。如果提供了--tls-cert-file 和 --tls private-key-file，则将忽略此参数。 + </td> +</tr> + +<tr> + <td colspan="2">--client-ca-file string</td> +</tr> +<tr> + <td></td><td style="line-height: 130%; word-wrap: break-word;"> + <!-- + If set, any request presenting a client certificate signed by one of the authorities in the client-ca-file is authenticated with an identity corresponding to the CommonName of the client certificate. + --> + 如果已设置，由 client-ca-file 中的授权机构签名的客户端证书的任何请求都将使用与客户端证书的 CommonName 对应的身份进行身份验证。 + </td> +</tr> + +<tr> + <td colspan="2">--config string</td> +</tr> +<tr> + <td></td><td style="line-height: 130%; word-wrap: break-word;"> + <!-- + The path to the configuration file. Flags override values in this file. + --> + 配置文件的路径。标志会覆盖此文件中的值。 + </td> +</tr> + +<tr> + <td colspan="2">--contention-profiling</td> +</tr> +<tr> + <td></td><td style="line-height: 130%; word-wrap: break-word;"> + <!-- + DEPRECATED: enable lock contention profiling, if profiling is enabled + --> + 弃用: 如果启用了性能分析，则启用锁竞争分析 + </td> +</tr> + +<tr> + <td colspan="2">--feature-gates mapStringBool</td> +</tr> +<tr> + <td></td><td style="line-height: 130%; word-wrap: break-word;"> + <!-- + A set of key=value pairs that describe feature gates for alpha/experimental features. Options are:<br/>APIListChunking=true|false (BETA - default=true)<br/>APIResponseCompression=true|false (BETA - default=true)<br/>AllAlpha=true|false (ALPHA - default=false)<br/>AppArmor=true|false (BETA - default=true)<br/>AttachVolumeLimit=true|false (BETA - default=true)<br/>BalanceAttachedNodeVolumes=true|false (ALPHA - default=false)<br/>BlockVolume=true|false (BETA - default=true)<br/>BoundServiceAccountTokenVolume=true|false (ALPHA - default=false)<br/>CPUManager=true|false (BETA - default=true)<br/>CRIContainerLogRotation=true|false (BETA - default=true)<br/>CSIBlockVolume=true|false (BETA - default=true)<br/>CSIDriverRegistry=true|false (BETA - default=true)<br/>CSIInlineVolume=true|false (BETA - default=true)<br/>CSIMigration=true|false (ALPHA - default=false)<br/>CSIMigrationAWS=true|false (ALPHA - default=false)<br/>CSIMigrationAzureDisk=true|false (ALPHA - default=false)<br/>CSIMigrationAzureFile=true|false (ALPHA - default=false)<br/>CSIMigrationGCE=true|false (ALPHA - default=false)<br/>CSIMigrationOpenStack=true|false (ALPHA - default=false)<br/>CSINodeInfo=true|false (BETA - default=true)<br/>CustomCPUCFSQuotaPeriod=true|false (ALPHA - default=false)<br/>CustomResourceDefaulting=true|false (BETA - default=true)<br/>DevicePlugins=true|false (BETA - default=true)<br/>DryRun=true|false (BETA - default=true)<br/>DynamicAuditing=true|false (ALPHA - default=false)<br/>DynamicKubeletConfig=true|false (BETA - default=true)<br/>EndpointSlice=true|false (ALPHA - default=false)<br/>EphemeralContainers=true|false (ALPHA - default=false)<br/>EvenPodsSpread=true|false (ALPHA - default=false)<br/>ExpandCSIVolumes=true|false (BETA - default=true)<br/>ExpandInUsePersistentVolumes=true|false (BETA - default=true)<br/>ExpandPersistentVolumes=true|false (BETA - default=true)<br/>ExperimentalHostUserNamespaceDefaulting=true|false (BETA - default=false)<br/>HPAScaleToZero=true|false (ALPHA - default=false)<br/>HyperVContainer=true|false (ALPHA - default=false)<br/>IPv6DualStack=true|false (ALPHA - default=false)<br/>KubeletPodResources=true|false (BETA - default=true)<br/>LegacyNodeRoleBehavior=true|false (ALPHA - default=true)<br/>LocalStorageCapacityIsolation=true|false (BETA - default=true)<br/>LocalStorageCapacityIsolationFSQuotaMonitoring=true|false (ALPHA - default=false)<br/>MountContainers=true|false (ALPHA - default=false)<br/>NodeDisruptionExclusion=true|false (ALPHA - default=false)<br/>NodeLease=true|false (BETA - default=true)<br/>NonPreemptingPriority=true|false (ALPHA - default=false)<br/>PodOverhead=true|false (ALPHA - default=false)<br/>PodShareProcessNamespace=true|false (BETA - default=true)<br/>ProcMountType=true|false (ALPHA - default=false)<br/>QOSReserved=true|false (ALPHA - default=false)<br/>RemainingItemCount=true|false (BETA - default=true)<br/>RemoveSelfLink=true|false (ALPHA - default=false)<br/>RequestManagement=true|false (ALPHA - default=false)<br/>ResourceLimitsPriorityFunction=true|false (ALPHA - default=false)<br/>ResourceQuotaScopeSelectors=true|false (BETA - default=true)<br/>RotateKubeletClientCertificate=true|false (BETA - default=true)<br/>RotateKubeletServerCertificate=true|false (BETA - default=true)<br/>RunAsGroup=true|false (BETA - default=true)<br/>RuntimeClass=true|false (BETA - default=true)<br/>SCTPSupport=true|false (ALPHA - default=false)<br/>ScheduleDaemonSetPods=true|false (BETA - default=true)<br/>ServerSideApply=true|false (BETA - default=true)<br/>ServiceLoadBalancerFinalizer=true|false (BETA - default=true)<br/>ServiceNodeExclusion=true|false (ALPHA - default=false)<br/>StartupProbe=true|false (BETA - default=true)<br/>StorageVersionHash=true|false (BETA - default=true)<br/>StreamingProxyRedirects=true|false (BETA - default=true)<br/>SupportNodePidsLimit=true|false (BETA - default=true)<br/>SupportPodPidsLimit=true|false (BETA - default=true)<br/>Sysctls=true|false (BETA - default=true)<br/>TTLAfterFinished=true|false (ALPHA - default=false)<br/>TaintBasedEvictions=true|false (BETA - default=true)<br/>TaintNodesByCondition=true|false (BETA - default=true)<br/>TokenRequest=true|false (BETA - default=true)<br/>TokenRequestProjection=true|false (BETA - default=true)<br/>TopologyManager=true|false (ALPHA - default=false)<br/>ValidateProxyRedirects=true|false (BETA - default=true)<br/>VolumePVCDataSource=true|false (BETA - default=true)<br/>VolumeSnapshotDataSource=true|false (ALPHA - default=false)<br/>VolumeSubpathEnvExpansion=true|false (BETA - default=true)<br/>WatchBookmark=true|false (BETA - default=true)<br/>WinDSR=true|false (ALPHA - default=false)<br/>WinOverlay=true|false (ALPHA - default=false)<br/>WindowsGMSA=true|false (BETA - default=true)<br/>WindowsRunAsUserName=true|false (ALPHA - default=false) + --> + 一组 key=value 对，描述了 alpha/experimental 特征开关。选项包括：<br/>APIListChunking=true|false (BETA - 默认值=true)<br/>APIResponseCompression=true|false (BETA - 默认值=true)<br/>AllAlpha=true|false (ALPHA - 默认值=false)<br/>AppArmor=true|false (BETA - 默认值=true)<br/>AttachVolumeLimit=true|false (BETA - 默认值=true)<br/>BalanceAttachedNodeVolumes=true|false (ALPHA - 默认值=false)<br/>BlockVolume=true|false (BETA - 默认值=true)<br/>BoundServiceAccountTokenVolume=true|false (ALPHA - 默认值=false)<br/>CPUManager=true|false (BETA - 默认值=true)<br/>CRIContainerLogRotation=true|false (BETA - 默认值=true)<br/>CSIBlockVolume=true|false (BETA - 默认值=true)<br/>CSIDriverRegistry=true|false (BETA - 默认值=true)<br/>CSIInlineVolume=true|false (BETA - 默认值=true)<br/>CSIMigration=true|false (ALPHA - 默认值=false)<br/>CSIMigrationAWS=true|false (ALPHA - 默认值=false)<br/>CSIMigrationAzureDisk=true|false (ALPHA - 默认值=false)<br/>CSIMigrationAzureFile=true|false (ALPHA - 默认值=false)<br/>CSIMigrationGCE=true|false (ALPHA - 默认值=false)<br/>CSIMigrationOpenStack=true|false (ALPHA - 默认值=false)<br/>CSINodeInfo=true|false (BETA - 默认值=true)<br/>CustomCPUCFSQuotaPeriod=true|false (ALPHA - 默认值=false)<br/>CustomResourceDefaulting=true|false (BETA - 默认值=true)<br/>DevicePlugins=true|false (BETA - 默认值=true)<br/>DryRun=true|false (BETA - 默认值=true)<br/>DynamicAuditing=true|false (ALPHA - 默认值=false)<br/>DynamicKubeletConfig=true|false (BETA - 默认值=true)<br/>EndpointSlice=true|false (ALPHA - 默认值=false)<br/>EphemeralContainers=true|false (ALPHA - 默认值=false)<br/>EvenPodsSpread=true|false (ALPHA - 默认值=false)<br/>ExpandCSIVolumes=true|false (BETA - 默认值=true)<br/>ExpandInUsePersistentVolumes=true|false (BETA - 默认值=true)<br/>ExpandPersistentVolumes=true|false (BETA - 默认值=true)<br/>ExperimentalHostUserNamespaceDefaulting=true|false (BETA - 默认值=false)<br/>HPAScaleToZero=true|false (ALPHA - 默认值=false)<br/>HyperVContainer=true|false (ALPHA - 默认值=false)<br/>IPv6DualStack=true|false (ALPHA - 默认值=false)<br/>KubeletPodResources=true|false (BETA - 默认值=true)<br/>LegacyNodeRoleBehavior=true|false (ALPHA - 默认值=true)<br/>LocalStorageCapacityIsolation=true|false (BETA - 默认值=true)<br/>LocalStorageCapacityIsolationFSQuotaMonitoring=true|false (ALPHA - 默认值=false)<br/>MountContainers=true|false (ALPHA - 默认值=false)<br/>NodeDisruptionExclusion=true|false (ALPHA - 默认值=false)<br/>NodeLease=true|false (BETA - 默认值=true)<br/>NonPreemptingPriority=true|false (ALPHA - 默认值=false)<br/>PodOverhead=true|false (ALPHA - 默认值=false)<br/>PodShareProcessNamespace=true|false (BETA - 默认值=true)<br/>ProcMountType=true|false (ALPHA - 默认值=false)<br/>QOSReserved=true|false (ALPHA - 默认值=false)<br/>RemainingItemCount=true|false (BETA - 默认值=true)<br/>RemoveSelfLink=true|false (ALPHA - 默认值=false)<br/>RequestManagement=true|false (ALPHA - 默认值=false)<br/>ResourceLimitsPriorityFunction=true|false (ALPHA - 默认值=false)<br/>ResourceQuotaScopeSelectors=true|false (BETA - 默认值=true)<br/>RotateKubeletClientCertificate=true|false (BETA - 默认值=true)<br/>RotateKubeletServerCertificate=true|false (BETA - 默认值=true)<br/>RunAsGroup=true|false (BETA - 默认值=true)<br/>RuntimeClass=true|false (BETA - 默认值=true)<br/>SCTPSupport=true|false (ALPHA - 默认值=false)<br/>ScheduleDaemonSetPods=true|false (BETA - 默认值=true)<br/>ServerSideApply=true|false (BETA - 默认值=true)<br/>ServiceLoadBalancerFinalizer=true|false (BETA - 默认值=true)<br/>ServiceNodeExclusion=true|false (ALPHA - 默认值=false)<br/>StartupProbe=true|false (BETA - 默认值=true)<br/>StorageVersionHash=true|false (BETA - 默认值=true)<br/>StreamingProxyRedirects=true|false (BETA - 默认值=true)<br/>SupportNodePidsLimit=true|false (BETA - 默认值=true)<br/>SupportPodPidsLimit=true|false (BETA - 默认值=true)<br/>Sysctls=true|false (BETA - 默认值=true)<br/>TTLAfterFinished=true|false (ALPHA - 默认值=false)<br/>TaintBasedEvictions=true|false (BETA - 默认值=true)<br/>TaintNodesByCondition=true|false (BETA - 默认值=true)<br/>TokenRequest=true|false (BETA - 默认值=true)<br/>TokenRequestProjection=true|false (BETA - 默认值=true)<br/>TopologyManager=true|false (ALPHA - 默认值=false)<br/>ValidateProxyRedirects=true|false (BETA - 默认值=true)<br/>VolumePVCDataSource=true|false (BETA - 默认值=true)<br/>VolumeSnapshotDataSource=true|false (ALPHA - 默认值=false)<br/>VolumeSubpathEnvExpansion=true|false (BETA - 默认值=true)<br/>WatchBookmark=true|false (BETA - 默认值=true)<br/>WinDSR=true|false (ALPHA - 默认值=false)<br/>WinOverlay=true|false (ALPHA - 默认值=false)<br/>WindowsGMSA=true|false (BETA - 默认值=true)<br/>WindowsRunAsUserName=true|false (ALPHA - 默认值=false) + </td> +</tr> + +<tr> + <td colspan="2"> + <!-- + --hard-pod-affinity-symmetric-weight int32     Default: 1 + --> + --hard-pod-affinity-symmetric-weight int32     默认: 1 + </td> +</tr> +<tr> + <td></td><td style="line-height: 130%; word-wrap: break-word;"> + <!-- + DEPRECATED: RequiredDuringScheduling affinity is not symmetric, but there is an implicit PreferredDuringScheduling affinity rule corresponding to every RequiredDuringScheduling affinity rule. --hard-pod-affinity-symmetric-weight represents the weight of implicit PreferredDuringScheduling affinity rule. Must be in the range 0-100.This option was moved to the policy configuration file + --> + 弃用: RequiredDuringScheduling 亲和力不是对称的，但是存在与每个 RequiredDuringScheduling 关联性规则相对应的隐式 PreferredDuringScheduling 关联性规则 --hard-pod-affinity-symmetric-weight 代表隐式 PreferredDuringScheduling 关联性规则的权重。权重必须在 0-100 范围内。此选项已移至策略配置文件。 + </td> +</tr> + +<tr> + <td colspan="2">-h, --help</td> +</tr> +<tr> + <td></td><td style="line-height: 130%; word-wrap: break-word;"> + <!-- + help for kube-scheduler + --> + kube-scheduler 帮助命令 + </td> +</tr> + +<tr> + <td colspan="2">--http2-max-streams-per-connection int</td> +</tr> +<tr> + <td></td><td style="line-height: 130%; word-wrap: break-word;"> + <!-- + The limit that the server gives to clients for the maximum number of streams in an HTTP/2 connection. Zero means to use golang's default. + --> + 服务器为客户端提供的 HTTP/2 连接最大限制。零表示使用 golang 的默认值。 + </td> +</tr> + +<tr> + <td colspan="2"> + <!-- + --kube-api-burst int32     Default: 100 + --> + --kube-api-burst int32     默认: 100 + </td> +</tr> +<tr> + <td></td><td style="line-height: 130%; word-wrap: break-word;"> + <!-- + DEPRECATED: burst to use while talking with kubernetes apiserver + --> + 弃用: 与 kubernetes apiserver 通信时使用 + </td> +</tr> + +<tr> + <td colspan="2"> + <!-- + --kube-api-content-type string     Default: "application/vnd.kubernetes.protobuf" + --> + --kube-api-content-type string     默认: "application/vnd.kubernetes.protobuf" + </td> +</tr> +<tr> + <td></td><td style="line-height: 130%; word-wrap: break-word;"> + <!-- + DEPRECATED: content type of requests sent to apiserver. + --> + 弃用: 发送到 apiserver 的请求的内容类型。 + </td> +</tr> + +<tr> + <td colspan="2"> + <!-- + --kube-api-qps float32     Default: 50 + --> + --kube-api-qps float32     默认: 50 + </td> +</tr> +<tr> + <td></td><td style="line-height: 130%; word-wrap: break-word;"> + <!-- + DEPRECATED: QPS to use while talking with kubernetes apiserver + --> + 弃用: 与 kubernetes apiserver 通信时要使用的 QPS + </td> +</tr> + +<tr> + <td colspan="2">--kubeconfig string</td> +</tr> +<tr> + <td></td><td style="line-height: 130%; word-wrap: break-word;"> + <!-- + DEPRECATED: path to kubeconfig file with authorization and master location information. + --> + 弃用: 具有授权和主节点位置信息的 kubeconfig 文件的路径。 + </td> +</tr> + +<tr> + <td colspan="2"> + <!-- + --leader-elect     Default: true + --> + --leader-elect     默认: true + </td> +</tr> +<tr> + <td></td><td style="line-height: 130%; word-wrap: break-word;"> + <!-- + Start a leader election client and gain leadership before executing the main loop. Enable this when running replicated components for high availability. + --> + 在执行主循环之前，开始领导者选举并选出领导者。为实现高可用性，运行多副本的组件并选出领导者。 + </td> +</tr> + +<tr> + <td colspan="2"> + <!-- + --leader-elect-lease-duration duration     Default: 15s + --> + --leader-elect-lease-duration duration     默认: 15s + </td> +</tr> +<tr> + <td></td><td style="line-height: 130%; word-wrap: break-word;"> + <!-- + The duration that non-leader candidates will wait after observing a leadership renewal until attempting to acquire leadership of a led but unrenewed leader slot. This is effectively the maximum duration that a leader can be stopped before it is replaced by another candidate. This is only applicable if leader election is enabled. + --> + 非领导者候选人在观察到领导者更新后将等待直到试图获得领导但未更新的领导者职位的等待时间。这实际上是领导者在被另一位候选人替代之前可以停止的最大持续时间。该情况仅在启用了领导者选举的情况下才适用。 + </td> +</tr> + +<tr> + <td colspan="2"> + <!-- + --leader-elect-renew-deadline duration     Default: 10s + --> + --leader-elect-renew-deadline duration     默认: 10s + </td> +</tr> +<tr> + <td></td><td style="line-height: 130%; word-wrap: break-word;"> + <!-- + The interval between attempts by the acting master to renew a leadership slot before it stops leading. This must be less than or equal to the lease duration. This is only applicable if leader election is enabled. + --> + </td> + 领导者尝试在停止领导之前更新领导职位的间隔时间。该时间必须小于或等于租赁期限。仅在启用了领导者选举的情况下才适用。 +</tr> + +<tr> + <td colspan="2"> + <!-- + --leader-elect-resource-lock endpoints     Default: "endpoints" + --> + --leader-elect-resource-lock endpoints     默认: "endpoints" + </td> +</tr> +<tr> + <td></td><td style="line-height: 130%; word-wrap: break-word;"> + <!-- + The type of resource object that is used for locking during leader election. Supported options are endpoints (default) and `configmaps`. + --> + 在领导者选举期间用于锁定的资源对象的类型。支持的选项是端点（默认）和 `configmaps` + </td> +</tr> + +<tr> + <td colspan="2"> + <!-- + --leader-elect-resource-name string     Default: "kube-scheduler" + --> + --leader-elect-resource-name string     默认: "kube-scheduler" + </td> +</tr> +<tr> + <td></td><td style="line-height: 130%; word-wrap: break-word;"> + <!-- + The name of resource object that is used for locking during leader election. + --> + 在领导者选举期间用于锁定的资源对象的名称。 + </td> +</tr> + +<tr> + <td colspan="2"> + <!-- + --leader-elect-resource-namespace string     Default: "kube-system" + --> + --leader-elect-resource-namespace string     默认: "kube-system" + </td> +</tr> +<tr> + <td></td><td style="line-height: 130%; word-wrap: break-word;"> + <!-- + The namespace of resource object that is used for locking during leader election. + --> + 在领导者选举期间用于锁定的资源对象的命名空间。 + </td> +</tr> + +<tr> + <td colspan="2"> + <!-- + --leader-elect-retry-period duration     Default: 2s + --> + --leader-elect-retry-period duration     默认: 2s + </td> +</tr> +<tr> + <td></td><td style="line-height: 130%; word-wrap: break-word;"> + <!-- + The duration the clients should wait between attempting acquisition and renewal of a leadership. This is only applicable if leader election is enabled. + --> + 客户应在尝试获取和更新领导之间等待的时间。仅在启用了领导者选举的情况下才适用。 + </td> +</tr> + +<tr> + <td colspan="2"> + <!-- + --lock-object-name string     Default: "kube-scheduler" + --> + --lock-object-name string     默认: "kube-scheduler" + </td> +</tr> +<tr> + <td></td><td style="line-height: 130%; word-wrap: break-word;"> + <!-- + DEPRECATED: define the name of the lock object. Will be removed in favor of leader-elect-resource-name + --> + 弃用: 定义锁对象的名称。将被删除以便使用 Leader-elect-resource-name + </td> +</tr> + +<tr> + <td colspan="2"> + <!-- + --lock-object-namespace string     Default: "kube-system" + --> + --lock-object-namespace string     默认: "kube-system" + </td> +</tr> +<tr> + <td></td><td style="line-height: 130%; word-wrap: break-word;"> + <!-- + DEPRECATED: define the namespace of the lock object. Will be removed in favor of leader-elect-resource-namespace. + --> + 弃用: 定义锁对象的命名空间。将被删除以便使用 leader-elect-resource-namespace。 + </td> +</tr> + +<tr> + <td colspan="2"> + <!-- + --log-backtrace-at traceLocation     Default: :0 + --> + --log-backtrace-at traceLocation     默认: :0 + </td> +</tr> +<tr> + <td></td><td style="line-height: 130%; word-wrap: break-word;"> + <!-- + when logging hits line file:N, emit a stack trace + --> + 当记录命中行文件：N 时发出堆栈跟踪 + </td> +</tr> + +<tr> + <td colspan="2">--log-dir string</td> +</tr> +<tr> + <td></td><td style="line-height: 130%; word-wrap: break-word;"> + <!-- + If non-empty, write log files in this directory + --> + 如果为非空，则在此目录中写入日志文件 + </td> +</tr> + +<tr> + <td colspan="2">--log-file string</td> +</tr> +<tr> + <td></td><td style="line-height: 130%; word-wrap: break-word;"> + <!-- + If non-empty, use this log file + --> + 如果为非空，请使用此日志文件 + </td> +</tr> + +<tr> + <td colspan="2"> + <!-- + --log-file-max-size uint     Default: 1800 + --> + --log-file-max-size uint     默认: 1800 + </td> +</tr> +<tr> + <td></td><td style="line-height: 130%; word-wrap: break-word;"> + <!-- + Defines the maximum size a log file can grow to. Unit is megabytes. If the value is 0, the maximum file size is unlimited. + --> + 定义日志文件可以增长到的最大值。单位为兆字节。如果值为0，则最大文件大小为无限制。 + </td> +</tr> + +<tr> + <td colspan="2"> + <!-- + --log-flush-frequency duration     Default: 5s + --> + --log-flush-frequency duration     默认: 5s + </td> +</tr> +<tr> + <td></td><td style="line-height: 130%; word-wrap: break-word;"> + <!-- + Maximum number of seconds between log flushes + --> + 两次日志刷新之间的最大秒数 + </td> +</tr> + +<tr> + <td colspan="2"> + <!-- + --logtostderr     Default: true + --> + --logtostderr     默认: true + </td> +</tr> +<tr> + <td></td><td style="line-height: 130%; word-wrap: break-word;"> + <!-- + log to standard error instead of files + --> + 日志记录到标准错误而不是文件 + </td> +</tr> + +<tr> + <td colspan="2">--master string</td> +</tr> +<tr> + <td></td><td style="line-height: 130%; word-wrap: break-word;"> + <!-- + The address of the Kubernetes API server (overrides any value in kubeconfig) + --> + Kubernetes API 服务器的地址（覆盖 kubeconfig 中的任何值） + </td> +</tr> + +<tr> + <td colspan="2">--policy-config-file string</td> +</tr> +<tr> + <td></td><td style="line-height: 130%; word-wrap: break-word;"> + <!-- + DEPRECATED: file with scheduler policy configuration. This file is used if policy ConfigMap is not provided or --use-legacy-policy-config=true + --> + 弃用：具有调度程序策略配置的文件。如果未提供 policy ConfigMap 或 --use-legacy-policy-config = true，则使用此文件 + </td> +</tr> + +<tr> + <td colspan="2">--policy-configmap string</td> +</tr> +<tr> + <td></td><td style="line-height: 130%; word-wrap: break-word;"> + <!-- + DEPRECATED: name of the ConfigMap object that contains scheduler's policy configuration. It must exist in the system namespace before scheduler initialization if --use-legacy-policy-config=false. The config must be provided as the value of an element in 'Data' map with the key='policy.cfg' + --> + 弃用: 包含调度程序策略配置的 ConfigMap 对象的名称。如果 --use-legacy-policy-config = false，则它必须在调度程序初始化之前存在于系统命名空间中。必须将配置作为键为 'policy.cfg' 的 'Data' 映射中元素的值提供 + </td> +</tr> + +<tr> + <td colspan="2"> + <!-- + --policy-configmap-namespace string     Default: "kube-system" + --> + --policy-configmap-namespace string     默认: "kube-system" + </td> +</tr> +<tr> + <td></td><td style="line-height: 130%; word-wrap: break-word;"> + <!-- + DEPRECATED: the namespace where policy ConfigMap is located. The kube-system namespace will be used if this is not provided or is empty. + --> + 弃用: 策略 ConfigMap 所在的命名空间。如果未提供或为空，则将使用 kube-system 命名空间。 + </td> +</tr> + +<tr> + <td colspan="2"> + <!-- + --port int     Default: 10251 + --> + --port int     默认: 10251 + </td> +</tr> +<tr> + <td></td><td style="line-height: 130%; word-wrap: break-word;"> + <!-- + DEPRECATED: the port on which to serve HTTP insecurely without authentication and authorization. If 0, don't serve plain HTTP at all. See --secure-port instead. + --> + 弃用: 在没有身份验证和授权的情况下不安全地为 HTTP 服务的端口。如果为0，则根本不提供 HTTP。请参见--secure-port。 + </td> +</tr> + +<tr> + <td colspan="2">--profiling</td> +</tr> +<tr> + <td></td><td style="line-height: 130%; word-wrap: break-word;"> + <!-- + DEPRECATED: enable profiling via web interface host:port/debug/pprof/ + --> + 弃用: 通过 Web 界面主机启用配置文件：port/debug/pprof/ + </td> +</tr> + +<tr> + <td colspan="2">--requestheader-allowed-names stringSlice</td> +</tr> +<tr> + <td></td><td style="line-height: 130%; word-wrap: break-word;"> + <!-- + List of client certificate common names to allow to provide usernames in headers specified by --requestheader-username-headers. If empty, any client certificate validated by the authorities in --requestheader-client-ca-file is allowed. + --> + 客户端证书通用名称列表允许在 --requestheader-username-headers 指定的头部中提供用户名。如果为空，则允许任何由权威机构 --requestheader-client-ca-file 验证的客户端证书。 + </td> +</tr> + +<tr> + <td colspan="2">--requestheader-client-ca-file string</td> +</tr> +<tr> + <td></td><td style="line-height: 130%; word-wrap: break-word;"> + <!-- + Root certificate bundle to use to verify client certificates on incoming requests before trusting usernames in headers specified by --requestheader-username-headers. WARNING: generally do not depend on authorization being already done for incoming requests. + --> + 在信任 --requestheader-username-headers 指定的头部中的用户名之前用于验证传入请求上的客户端证书的根证书包。警告：通常不依赖于传入请求已经完成的授权。 + </td> +</tr> + +<tr> + <td colspan="2"> + <!-- + --requestheader-extra-headers-prefix stringSlice     Default: [x-remote-extra-] + --> + --requestheader-extra-headers-prefix stringSlice     默认: [x-remote-extra-] + </td> +</tr> +<tr> + <td></td><td style="line-height: 130%; word-wrap: break-word;"> + <!-- + List of request header prefixes to inspect. X-Remote-Extra- is suggested. + --> + 要检查请求头部前缀列表。建议使用 X-Remote-Extra- + </td> +</tr> + +<tr> + <td colspan="2"> + <!-- + --requestheader-group-headers stringSlice     Default: [x-remote-group] + --> + --requestheader-group-headers stringSlice     默认: [x-remote-group] + </td> +</tr> +<tr> + <td></td><td style="line-height: 130%; word-wrap: break-word;"> + <!-- + List of request headers to inspect for groups. X-Remote-Group is suggested. + --> + 用于检查组的请求头部列表。建议使用 X-Remote-Group。 + </td> +</tr> + +<tr> + <td colspan="2"> + <!-- + --requestheader-username-headers stringSlice     Default: [x-remote-user] + --> + --requestheader-username-headers stringSlice     默认: [x-remote-user] + </td> +</tr> +<tr> + <td></td><td style="line-height: 130%; word-wrap: break-word;"> + <!-- + List of request headers to inspect for usernames. X-Remote-User is common. + --> + 用于检查用户名的请求头部列表。 X-Remote-User 很常见。 + </td> +</tr> + +<tr> + <td colspan="2"> + <!-- + --scheduler-name string     Default: "default-scheduler" + --> + --scheduler-name string     默认: "default-scheduler" + </td> +</tr> +<tr> + <td></td><td style="line-height: 130%; word-wrap: break-word;"> + <!-- + DEPRECATED: name of the scheduler, used to select which pods will be processed by this scheduler, based on pod's "spec.schedulerName". + --> + 弃用: 调度程序名称用于根据 Pod 的 "spec.schedulerName" 选择此调度程序将处理的 Pod。 + </td> +</tr> + +<tr> + <td colspan="2"> + <!-- + --secure-port int     Default: 10259 + --> + --secure-port int     默认: 10259 + </td> +</tr> +<tr> + <td></td><td style="line-height: 130%; word-wrap: break-word;"> + <!-- + The port on which to serve HTTPS with authentication and authorization.If 0, don't serve HTTPS at all. + --> + 通过身份验证和授权为 HTTPS 服务的端口。如果为 0，则根本不提供 HTTPS。 + </td> +</tr> + +<tr> + <td colspan="2">--skip-headers</td> +</tr> +<tr> + <td></td><td style="line-height: 130%; word-wrap: break-word;"> + <!-- + If true, avoid header prefixes in the log messages + --> + 如果为 true，请在日志消息中避免头部前缀 + </td> +</tr> + +<tr> + <td colspan="2">--skip-log-headers</td> +</tr> +<tr> + <td></td><td style="line-height: 130%; word-wrap: break-word;"> + <!-- + If true, avoid headers when opening log files + --> + 如果为true，则在打开日志文件时避免头部 + </td> +</tr> + +<tr> + <td colspan="2"> + <!-- + --stderrthreshold severity     Default: 2 + --> + --stderrthreshold severity     默认: 2 + </td> +</tr> +<tr> + <td></td><td style="line-height: 130%; word-wrap: break-word;"> + <!-- + logs at or above this threshold go to stderr + --> + 达到或超过此阈值的日志转到 stderr + </td> +</tr> + +<tr> + <td colspan="2">--tls-cert-file string</td> +</tr> +<tr> + <td></td><td style="line-height: 130%; word-wrap: break-word;"> + <!-- + File containing the default x509 Certificate for HTTPS. (CA cert, if any, concatenated after server cert). If HTTPS serving is enabled, and --tls-cert-file and --tls-private-key-file are not provided, a self-signed certificate and key are generated for the public address and saved to the directory specified by --cert-dir. + --> + 包含默认的 HTTPS x509 证书的文件。（CA证书（如果有）在服务器证书之后并置）。如果启用了 HTTPS 服务，并且未提供 --tls-cert-file 和 --tls-private-key-file，则会为公共地址生成一个自签名证书和密钥，并将其保存到 --cert-dir 指定的目录中。 + </td> +</tr> + +<tr> + <td colspan="2">--tls-cipher-suites stringSlice</td> +</tr> +<tr> + <td></td><td style="line-height: 130%; word-wrap: break-word;"> + <!-- + Comma-separated list of cipher suites for the server. If omitted, the default Go cipher suites will be use. Possible values: TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA,TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256,TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA,TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384,TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305,TLS_ECDHE_ECDSA_WITH_RC4_128_SHA,TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA,TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA,TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256,TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA,TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384,TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305,TLS_ECDHE_RSA_WITH_RC4_128_SHA,TLS_RSA_WITH_3DES_EDE_CBC_SHA,TLS_RSA_WITH_AES_128_CBC_SHA,TLS_RSA_WITH_AES_128_CBC_SHA256,TLS_RSA_WITH_AES_128_GCM_SHA256,TLS_RSA_WITH_AES_256_CBC_SHA,TLS_RSA_WITH_AES_256_GCM_SHA384,TLS_RSA_WITH_RC4_128_SHA + --> + 服务器的密码套件列表，以逗号分隔。如果省略，将使用默认的 Go 密码套件。可能的值： + TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA,TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256,TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA,TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384,TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305,TLS_ECDHE_ECDSA_WITH_RC4_128_SHA,TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA,TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA,TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256,TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA,TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384,TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305,TLS_ECDHE_RSA_WITH_RC4_128_SHA,TLS_RSA_WITH_3DES_EDE_CBC_SHA,TLS_RSA_WITH_AES_128_CBC_SHA,TLS_RSA_WITH_AES_128_CBC_SHA256,TLS_RSA_WITH_AES_128_GCM_SHA256,TLS_RSA_WITH_AES_256_CBC_SHA,TLS_RSA_WITH_AES_256_GCM_SHA384,TLS_RSA_WITH_RC4_128_SHA + </td> +</tr> + +<tr> + <td colspan="2">--tls-min-version string</td> +</tr> +<tr> + <td></td><td style="line-height: 130%; word-wrap: break-word;"> + <!-- + Minimum TLS version supported. Possible values: VersionTLS10, VersionTLS11, VersionTLS12, VersionTLS13 + --> + 支持的最低 TLS 版本。可能的值：VersionTLS10, VersionTLS11, VersionTLS12, VersionTLS13 + </td> +</tr> + +<tr> + <td colspan="2">--tls-private-key-file string</td> +</tr> +<tr> + <td></td><td style="line-height: 130%; word-wrap: break-word;"> + <!-- + File containing the default x509 private key matching --tls-cert-file. + --> + 包含与 --tls-cert-file 匹配的默认 x509 私钥的文件。 + </td> +</tr> + +<tr> + <td colspan="2"> + <!-- + --tls-sni-cert-key namedCertKey     Default: [] + --> + --tls-sni-cert-key namedCertKey     默认: [] + </td> +</tr> +<tr> + <td></td><td style="line-height: 130%; word-wrap: break-word;"> + <!-- + A pair of x509 certificate and private key file paths, optionally suffixed with a list of domain patterns which are fully qualified domain names, possibly with prefixed wildcard segments. If no domain patterns are provided, the names of the certificate are extracted. Non-wildcard matches trump over wildcard matches, explicit domain patterns trump over extracted names. For multiple key/certificate pairs, use the --tls-sni-cert-key multiple times. Examples: "example.crt,example.key" or "foo.crt,foo.key:*.foo.com,foo.com". + --> + 一对 x509 证书和私钥文件路径，可选地后缀为完全限定域名的域模式列表，并可能带有前缀的通配符段。如果未提供域模式，则获取证书名称。非通配符匹配胜过通配符匹配，显式域模式胜过获取名称。 对于多个密钥/证书对，请多次使用 --tls-sni-cert-key。例如: "example.crt,example.key" 或者 "foo.crt,foo.key:*.foo.com,foo.com"。 + </td> +</tr> + +<tr> + <td colspan="2">--use-legacy-policy-config</td> +</tr> +<tr> + <td></td><td style="line-height: 130%; word-wrap: break-word;"> + <!-- + DEPRECATED: when set to true, scheduler will ignore policy ConfigMap and uses policy config file + --> + 弃用: 设置为 true 时，调度程序将忽略策略 ConfigMap 并使用策略配置文件 + </td> +</tr> + +<tr> + <td colspan="2">-v, --v Level</td> +</tr> +<tr> + <td></td><td style="line-height: 130%; word-wrap: break-word;"> + <!-- + number for the log level verbosity + --> + 日志级别详细程度的数字 + </td> +</tr> + +<tr> + <td colspan="2">--version version[=true]</td> +</tr> +<tr> + <td></td><td style="line-height: 130%; word-wrap: break-word;"> + <!-- + Print version information and quit + --> + 打印版本信息并退出 + </td> +</tr> + +<tr> + <td colspan="2">--vmodule moduleSpec</td> +</tr> +<tr> + <td></td><td style="line-height: 130%; word-wrap: break-word;"> + <!-- + comma-separated list of pattern=N settings for file-filtered logging + --> + 以逗号分隔的 pattern = N 设置列表，用于文件过滤的日志记录 + </td> +</tr> + +<tr> + <td colspan="2">--write-config-to string</td> +</tr> +<tr> + <td></td><td style="line-height: 130%; word-wrap: break-word;"> + <!-- + If set, write the configuration values to this file and exit. + --> + 如果已设置，请将配置值写入此文件并退出。 + </td> +</tr> </tbody> </table> diff --git a/content/zh/docs/reference/command-line-tools-reference/kubelet.md b/content/zh/docs/reference/command-line-tools-reference/kubelet.md index 024c1cece4..9cfb1dbddd 100644 --- a/content/zh/docs/reference/command-line-tools-reference/kubelet.md +++ b/content/zh/docs/reference/command-line-tools-reference/kubelet.md @@ -1,6 +1,6 @@ --- title: kubelet -content_template: templates/tool-reference +content_type: tool-reference weight: 28 --- @@ -11,7 +11,7 @@ weight: 28 The kubelet is the primary "node agent" that runs on each node. It can register the node with the apiserver using one of: the hostname; a flag to override the hostname; or specific logic for a cloud provider. --> -kubelet 是在每个 Node 节点上运行的主要 “节点代理”。它向 apiserver 注册节点时可以使用主机名（hostname）；可以提供用于覆盖主机名的参数；还可以执行特定于某云服务商的逻辑。 +kubelet 是在每个 Node 节点上运行的主要 “节点代理”。它可以通过以下方式向 apiserver 进行注册：主机名（hostname）；覆盖主机名的参数；某云服务商的特定逻辑。 <!-- The kubelet works in terms of a PodSpec. A PodSpec is a YAML or JSON object that describes a pod. The kubelet takes a set of PodSpecs that are provided through various mechanisms (primarily through the apiserver) and ensures that the containers described in those PodSpecs are running and healthy. The kubelet doesn't manage containers which were not created by Kubernetes. diff --git a/content/zh/docs/reference/glossary/addons.md b/content/zh/docs/reference/glossary/addons.md new file mode 100644 index 0000000000..c4280561ac --- /dev/null +++ b/content/zh/docs/reference/glossary/addons.md @@ -0,0 +1,37 @@ +--- +title: 附加组件 +id: addons +date: 2019-12-15 +full_link: /docs/concepts/cluster-administration/addons/ +short_description: > + 扩展 Kubernetes 功能的资源。 + +aka: +tags: +- tool +--- + 扩展 Kubernetes 功能的资源。 + +<!-- +--- +title: Add-ons +id: addons +date: 2019-12-15 +full_link: /docs/concepts/cluster-administration/addons/ +short_description: > + Resources that extend the functionality of Kubernetes. + +aka: +tags: +- tool +--- + Resources that extend the functionality of Kubernetes. +--> + + +<!--more--> + +<!-- +[Installing addons](/docs/concepts/cluster-administration/addons/) explains more about using add-ons with your cluster, and lists some popular add-ons. +--> +[安装附加组件](/docs/concepts/cluster-administration/addons/) 阐释了更多关于如何在集群内使用附加组件，并列出了一些流行的附加组件。 diff --git a/content/zh/docs/reference/glossary/cidr.md b/content/zh/docs/reference/glossary/cidr.md new file mode 100644 index 0000000000..7e0a97d31e --- /dev/null +++ b/content/zh/docs/reference/glossary/cidr.md @@ -0,0 +1,36 @@ +--- +title: CIDR +id: cidr +date: 2019-11-12 +full_link: +short_description: > + CIDR 是一种描述 IP 地址块的符号，被广泛使用于各种网络配置中。 + +aka: +tags: +- networking +--- +CIDR (无类域间路由) 是一种描述 IP 地址块的符号，被广泛使用于各种网络配置中。 + +<!-- +--- +title: CIDR +id: cidr +date: 2019-11-12 +full_link: +short_description: > + CIDR is a notation for describing blocks of IP addresses and is used heavily in various networking configurations. + +aka: +tags: +- networking +--- +CIDR (Classless Inter-Domain Routing) is a notation for describing blocks of IP addresses and is used heavily in various networking configurations. +--> + +<!--more--> + +<!-- +In the context of Kubernetes, each {{< glossary_tooltip text="Node" term_id="node" >}} is assigned a range of IP addresses through the start address and a subnet mask using CIDR. This allows Nodes to assign each {{< glossary_tooltip text="Pod" term_id="pod" >}} a unique IP address. Although originally a concept for IPv4, CIDR has also been expanded to include IPv6. +--> +在 Kubernetes 的上下文中，每个 {{< glossary_tooltip text="节点" term_id="node" >}} 以 CIDR 形式（含起始地址和子网掩码）获得一个 IP 地址段，从而能够为每个 {{< glossary_tooltip text="Pod" term_id="pod" >}} 分配一个独一无二的 IP 地址。虽然其概念最初源自 IPv4，CIDR 已经被扩展为涵盖 IPv6。 diff --git a/content/zh/docs/reference/glossary/disruption.md b/content/zh/docs/reference/glossary/disruption.md new file mode 100644 index 0000000000..0d8133938e --- /dev/null +++ b/content/zh/docs/reference/glossary/disruption.md @@ -0,0 +1,45 @@ +--- +title: 干扰 +id: disruption +date: 2019-09-10 +full_link: /docs/concepts/workloads/pods/disruptions/ +short_description: > + 导致 Pod 服务停止的事件。 +aka: +tags: +- fundamental +--- + 干扰是指导致一个或者多个 {{< glossary_tooltip term_id="pod" text="Pod" >}} 服务停止的事件。 +干扰会影响工作负载资源，比如 {{< glossary_tooltip term_id="deployment" >}} 这种依赖于受影响 Pod 的资源。 + +<!-- +--- +title: Disruption +id: disruption +date: 2019-09-10 +full_link: /docs/concepts/workloads/pods/disruptions/ +short_description: > + An event that leads to Pod(s) going out of service +aka: +tags: +- fundamental +--- + Disruptions are events that lead to one or more +{{< glossary_tooltip term_id="pod" text="Pods" >}} going out of service. +A disruption has consequences for workload resources, such as +{{< glossary_tooltip term_id="deployment" >}}, that rely on the affected +Pods. + --> + +<!--more--> + +<!-- +If you, as cluster operator, destroy a Pod that belongs to an application, +Kubernetes terms that a _voluntary disruption_. If a Pod goes offline +because of a Node failure, or an outage affecting a wider failure zone, +Kubernetes terms that an _involuntary disruption_. + +See [Disruptions](/docs/concepts/workloads/pods/disruptions/) for more information. + --> +如果您作为一个集群操作人员，销毁了一个从属于某个应用的 Pod, Kubernetes 视之为 _自愿干扰_。如果由于节点故障 +或者影响更大区域故障的断电导致 Pod 离线，Kubrenetes 视之为 _非愿干扰_。 \ No newline at end of file diff --git a/content/zh/docs/reference/glossary/host-aliases.md b/content/zh/docs/reference/glossary/host-aliases.md new file mode 100644 index 0000000000..6581acf209 --- /dev/null +++ b/content/zh/docs/reference/glossary/host-aliases.md @@ -0,0 +1,37 @@ +--- +title: HostAliases +id: HostAliases +date: 2019-01-31 +full_link: /docs/reference/generated/kubernetes-api/{{< param "version" >}}/#hostalias-v1-core +short_description: > + 主机别名 (HostAliases) 是一组 IP 地址和主机名的映射，用于注入到 Pod 内的 hosts 文件。 + +aka: +tags: +- operation +--- + 主机别名 (HostAliases) 是一组 IP 地址和主机名的映射，用于注入到 {{< glossary_tooltip text="Pod" term_id="pod" >}} 内的 hosts 文件。 + +<!-- +--- +title: HostAliases +id: HostAliases +date: 2019-01-31 +full_link: /docs/reference/generated/kubernetes-api/{{< param "version" >}}/#hostalias-v1-core +short_description: > + A HostAliases is a mapping between the IP address and hostname to be injected into a Pod's hosts file. + +aka: +tags: +- operation +--- + A HostAliases is a mapping between the IP address and hostname to be injected into a {{< glossary_tooltip text="Pod" term_id="pod" >}}'s hosts file. +--> + +<!--more--> + +<!-- +[HostAliases](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#hostalias-v1-core) is an optional list of hostnames and IP addresses that will be injected into the Pod's hosts file if specified. This is only valid for non-hostNetwork Pods. +--> +[HostAliases](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#hostalias-v1-core) 是一个包含主机名和 IP 地址的可选列表，配置后将被注入到 Pod 内的 hosts 文件中。 +该选项仅适用于没有配置 hostNetwork 的 Pod. diff --git a/content/zh/docs/reference/glossary/index.md b/content/zh/docs/reference/glossary/index.md index 0c13697ff9..d5d593d062 100755 --- a/content/zh/docs/reference/glossary/index.md +++ b/content/zh/docs/reference/glossary/index.md @@ -1,14 +1,11 @@ --- -approvers: -- chenopis -- abiogenesis-now title: 标准化词汇表 layout: glossary noedit: true default_active_tag: fundamental weight: 5 card: - name: 参考 + name: reference weight: 10 title: 词汇表 --- diff --git a/content/zh/docs/reference/glossary/mainfest.md b/content/zh/docs/reference/glossary/mainfest.md new file mode 100644 index 0000000000..3987ff67d6 --- /dev/null +++ b/content/zh/docs/reference/glossary/mainfest.md @@ -0,0 +1,34 @@ +--- +title: 清单 +id: manifest +date: 2019-06-28 +short_description: > + 一个或多个 Kubernetes API 对象的序列化规范。 + +aka: +tags: +- fundamental +--- + JSON 或 YAML 格式的 Kubernetes API 对象规范。 + +<!-- +--- +title: Manifest +id: manifest +date: 2019-06-28 +short_description: > + A serialized specification of one or more Kubernetes API objects. + +aka: +tags: +- fundamental +--- + Specification of a Kubernetes API object in JSON or YAML format. +--> + +<!--more--> + +<!-- +A manifest specifies the desired state of an object that Kubernetes will maintain when you apply the manifest. Each configuration file can contain multiple manifests. + --> +清单指定了在应用该清单时 Kubrenetes 将维护的对象的期望状态。每个配置文件可包含多个清单。 \ No newline at end of file diff --git a/content/zh/docs/reference/glossary/master.md b/content/zh/docs/reference/glossary/master.md new file mode 100644 index 0000000000..5ef02a8ccf --- /dev/null +++ b/content/zh/docs/reference/glossary/master.md @@ -0,0 +1,34 @@ +--- +title: Master +id: master +date: 2020-04-16 +short_description: > + 遗留术语，作为运行控制平面的节点的同义词使用。 + +aka: +tags: +- fundamental +--- + 遗留术语，作为运行 {{< glossary_tooltip text="控制平面" term_id="control-plane" >}} 的 {{< glossary_tooltip text="节点" term_id="node" >}} 的同义词使用。 + +<!-- +--- +title: Master +id: master +date: 2020-04-16 +short_description: > + Legacy term, used as synonym for nodes running the control plane. + +aka: +tags: +- fundamental +--- + Legacy term, used as synonym for {{< glossary_tooltip text="nodes" term_id="node" >}} hosting the {{< glossary_tooltip text="control plane" term_id="control-plane" >}}. + --> + +<!--more--> + +<!-- +The term is still being used by some provisioning tools, such as {{< glossary_tooltip text="kubeadm" term_id="kubeadm" >}}, and managed services, to {{< glossary_tooltip text="label" term_id="label" >}} {{< glossary_tooltip text="nodes" term_id="node" >}} with `kubernetes.io/role` and control placement of {{< glossary_tooltip text="control plane" term_id="control-plane" >}} {{< glossary_tooltip text="pods" term_id="pod" >}}. +--> +该术语仍被一些配置工具使用，如 {{< glossary_tooltip text="kubeadm" term_id="kubeadm" >}} 以及托管的服务，为 {{< glossary_tooltip text="节点" term_id="node" >}} 添加 `kubernetes.io/role` 的 {{< glossary_tooltip text="标签" term_id="label" >}}，以及管理控制平面 Pod 的调度。 \ No newline at end of file diff --git a/content/zh/docs/reference/kubectl/cheatsheet.md b/content/zh/docs/reference/kubectl/cheatsheet.md index 4ef61cac63..0ede5fb604 100644 --- a/content/zh/docs/reference/kubectl/cheatsheet.md +++ b/content/zh/docs/reference/kubectl/cheatsheet.md @@ -1,9 +1,5 @@ --- title: kubectl 备忘单 -reviewers: -- erictune -- krousey -- clove content_type: concept card: name: reference @@ -23,34 +19,42 @@ card: <!-- overview --> -<!-- See also: [Kubectl Overview](/docs/reference/kubectl/overview/) and [JsonPath Guide](/docs/reference/kubectl/jsonpath). --> -也可以看下: [Kubectl 概述](/docs/reference/kubectl/overview/) 和 [JsonPath 指南](/docs/reference/kubectl/jsonpath)。 +<!-- +See also: [Kubectl Overview](/docs/reference/kubectl/overview/) and [JsonPath Guide](/docs/reference/kubectl/jsonpath). + +This page is an overview of the `kubectl` command. +--> +另见: [Kubectl 概述](/docs/reference/kubectl/overview/) 和 [JsonPath 指南](/docs/reference/kubectl/jsonpath)。 -<!-- This page is an overview of the `kubectl` command. --> 本页面是 `kubectl` 命令的概述。 - <!-- body --> -<!-- # kubectl - Cheat Sheet --> -## kubectl - 备忘单 +<!-- +# kubectl - Cheat Sheet + +## Kubectl Autocomplete +--> +# kubectl - 备忘单 -<!-- ## Kubectl Autocomplete --> ## Kubectl 自动补全 ### BASH -<!-- ```bash +<!-- +```bash source <(kubectl completion bash) # setup autocomplete in bash into the current shell, bash-completion package should be installed first. echo "source <(kubectl completion bash)" >> ~/.bashrc # add autocomplete permanently to your bash shell. -``` --> +``` + +You can also use a shorthand alias for `kubectl` that also works with completion: +--> ```bash source <(kubectl completion bash) # 在 bash 中设置当前 shell 的自动补全，要先安装 bash-completion 包。 echo "source <(kubectl completion bash)" >> ~/.bashrc # 在您的 bash shell 中永久的添加自动补全 ``` -<!-- You can also use a shorthand alias for `kubectl` that also works with completion: --> 您还可以为 `kubectl` 使用一个速记别名，该别名也可以与 completion 一起使用： ```bash @@ -60,25 +64,32 @@ complete -F __start_kubectl k ### ZSH -<!-- ```bash +<!-- +```bash source <(kubectl completion zsh) # setup autocomplete in zsh into the current shell echo "if [ $commands[kubectl] ]; then source <(kubectl completion zsh); fi" >> ~/.zshrc # add autocomplete permanently to your zsh shell -``` --> +``` +--> ```bash source <(kubectl completion zsh) # 在 zsh 中设置当前 shell 的自动补全 echo "if [ $commands[kubectl] ]; then source <(kubectl completion zsh); fi" >> ~/.zshrc # 在您的 zsh shell 中永久的添加自动补全 ``` -<!-- ## Kubectl Context and Configuration +<!-- +## Kubectl Context and Configuration Set which Kubernetes cluster `kubectl` communicates with and modifies configuration information. See [Authenticating Across Clusters with kubeconfig](/docs/tasks/access-application-cluster/configure-access-multiple-clusters/) documentation for -detailed config file information. --> +detailed config file information. +--> ## Kubectl 上下文和配置 -设置 `kubectl` 与哪个 Kubernetes 集群进行通信并修改配置信息。查看 [使用 kubeconfig 跨集群授权访问](/docs/tasks/access-application-cluster/configure-access-multiple-clusters/) 文档获取详情配置文件信息。 +设置 `kubectl` 与哪个 Kubernetes 集群进行通信并修改配置信息。查看 +[使用 kubeconfig 跨集群授权访问](/docs/tasks/access-application-cluster/configure-access-multiple-clusters/) +文档获取配置文件详细信息。 -<!-- ```bash +<!-- +``bash kubectl config view # Show Merged kubeconfig settings. # use multiple kubeconfig files at the same time and view merged config @@ -89,9 +100,10 @@ kubectl config view # get the password for the e2e user kubectl config view -o jsonpath='{.users[?(@.name == "e2e")].user.password}' -kubectl config view -o jsonpath='{.users[].name}' # get a list of users +kubectl config view -o jsonpath='{.users[].name}' # display the first user +kubectl config view -o jsonpath='{.users[*].name}' # get a list of users kubectl config get-contexts # display list of contexts -kubectl config current-context # display the current-context +kubectl config current-context # display the current-context kubectl config use-context my-cluster-name # set the default context to my-cluster-name # add a new cluster to your kubeconf that supports basic auth @@ -105,7 +117,8 @@ kubectl config set-context gce --user=cluster-admin --namespace=foo \ && kubectl config use-context gce kubectl config unset users.foo # delete user foo -``` --> +``` +--> ```bash kubectl config view # 显示合并的 kubeconfig 配置。 @@ -115,36 +128,54 @@ KUBECONFIG=~/.kube/config:~/.kube/kubconfig2 kubectl config view # 获取 e2e 用户的密码 kubectl config view -o jsonpath='{.users[?(@.name == "e2e")].user.password}' -kubectl config current-context # 展示当前所处的上下文 -kubectl config use-context my-cluster-name # 设置默认的上下文为 my-cluster-name +kubectl config view -o jsonpath='{.users[].name}' # 显示第一个用户 +kubectl config view -o jsonpath='{.users[*].name}' # 获取用户列表 +kubectl config get-contexts # 显示上下文列表 +kubectl config current-context # 展示当前所处的上下文 +kubectl config use-context my-cluster-name # 设置默认的上下文为 my-cluster-name -# 添加新的集群配置到 kubeconf 中，使用 basic auth 进行鉴权 +# 添加新的集群配置到 kubeconf 中，使用 basic auth 进行身份认证 kubectl config set-credentials kubeuser/foo.kubernetes.com --username=kubeuser --password=kubepassword -# 使用特定的用户名和命名空间设置上下文。 +# 在指定上下文中持久性地保存名字空间，供所有后续 kubectl 命令使用 +kubectl config set-context --current --namespace=ggckad-s2 + +# 使用特定的用户名和名字空间设置上下文 kubectl config set-context gce --user=cluster-admin --namespace=foo \ && kubectl config use-context gce + +kubectl config unset users.foo # 删除用户 foo ``` -<!-- ## Apply -`apply` manages applications through files defining Kubernetes resources. It creates and updates resources in a cluster through running `kubectl apply`. This is the recommended way of managing Kubernetes applications on production. See [Kubectl Book](https://kubectl.docs.kubernetes.io). --> +<!-- ## Apply -`apply` 通过定义 Kubernetes 资源的文件管理应用程序。它通过运行 `kubectl apply` 在集群中创建和更新资源。这是在生产中管理 Kubernetes 应用程序的推荐方法。查阅 [Kubectl 文档](https://kubectl.docs.kubernetes.io)。 +`apply` manages applications through files defining Kubernetes resources. It creates and updates resources in a cluster through running `kubectl apply`. This is the recommended way of managing Kubernetes applications on production. See [Kubectl Book](https://kubectl.docs.kubernetes.io). +--> +## Apply +`apply` 通过定义 Kubernetes 资源的文件来管理应用。它通过运行 +`kubectl apply` 在集群中创建和更新资源。 +这是在生产中管理 Kubernetes 应用的推荐方法。 +参见 [Kubectl 文档](https://kubectl.docs.kubernetes.io)。 -<!-- ## Creating Objects --> -## 创建对象 +<!-- +## Creating Objects -<!-- Kubernetes manifests can be defined in json or yaml. The file extension `.yaml`, -`.yml`, and `.json` can be used. --> -Kubernetes 配置可以用 json 或 yaml 定义。可以使用的文件扩展名有 `.yaml`，`.yml` 和 `.json`。 +Kubernetes manifests can be defined in YAML or JSON. The file extension `.yaml`, +`.yml`, and `.json` can be used. +--> +## 创建对象 {#creating-objects} -<!-- ```bash +Kubernetes 配置可以用 YAML 或 JSON 定义。可以使用的文件扩展名有 +`.yaml`、`.yml` 和 `.json`。 + +<!-- +```bash kubectl apply -f ./my-manifest.yaml # create resource(s) kubectl apply -f ./my1.yaml -f ./my2.yaml # create from multiple files kubectl apply -f ./dir # create resource(s) in all manifest files in dir kubectl apply -f https://git.io/vPieo # create resource(s) from url -kubectl create deployment nginx --image=nginx # start a single instance of nginx -kubectl explain pods,svc # get the documentation for pod and svc manifests +kubectl create deployment nginx --image=nginx # start a single instance of nginx +kubectl explain pods # get the documentation for pod and svc manifests # Create multiple YAML objects from stdin cat <<EOF | kubectl apply -f - @@ -184,17 +215,17 @@ data: password: $(echo -n "s33msi4" | base64 -w0) username: $(echo -n "jane" | base64 -w0) EOF - -``` --> +``` +--> ```bash kubectl apply -f ./my-manifest.yaml # 创建资源 kubectl apply -f ./my1.yaml -f ./my2.yaml # 使用多个文件创建 -kubectl apply -f ./dir # 从目录下的全部配置文件创建资源 -kubectl apply -f https://git.io/vPieo # 从 url 中创建资源 -kubectl create deployment nginx --image=nginx # 启动单实例 nginx -kubectl explain pods,svc # 获取 pod，svc 配置的文档说明 +kubectl apply -f ./dir # 基于目录下的所有清单文件创建资源 +kubectl apply -f https://git.io/vPieo # 从 URL 中创建资源 +kubectl create deployment nginx --image=nginx # 启动单实例 nginx +kubectl explain pods,svc # 获取 pod 清单的文档说明 -# 从标准输入中的多个 YAML 对象中创建 +# 从标准输入创建多个 YAML 对象 cat <<EOF | kubectl apply -f - apiVersion: v1 kind: Pod @@ -232,34 +263,35 @@ data: password: $(echo -n "s33msi4" | base64 -w0) username: $(echo -n "jane" | base64 -w0) EOF - ``` -<!-- ## Viewing, Finding Resources --> -## 获取和查找资源 +<!-- +## Viewing, Finding Resources +--> +## 查看和查找资源 -<!-- ```bash +<!-- +```bash # Get commands with basic output kubectl get services # List all services in the namespace kubectl get pods --all-namespaces # List all pods in all namespaces kubectl get pods -o wide # List all pods in the namespace, with more details kubectl get deployment my-dep # List a particular deployment -kubectl get pods --include-uninitialized # List all pods in the namespace, including uninitialized ones +kubectl get pods # List all pods in the namespace kubectl get pod my-pod -o yaml # Get a pod's YAML -kubectl get pod my-pod -o yaml --export # Get a pod's YAML without cluster specific information # Describe commands with verbose output kubectl describe nodes my-node kubectl describe pods my-pod -kubectl get services --sort-by=.metadata.name # List Services Sorted by Name +# List Services Sorted by Name +kubectl get services --sort-by=.metadata.name # List pods Sorted by Restart Count kubectl get pods --sort-by='.status.containerStatuses[0].restartCount' -# List pods in test namespace sorted by capacity - -kubectl get pods -n test --sort-by=.spec.capacity.storage +# List PersistentVolumes sorted by capacity +kubectl get pv --sort-by=.spec.capacity.storage # Get the version label of all pods with label app=cassandra kubectl get pods --selector=app=cassandra -o \ @@ -281,10 +313,6 @@ sel=${$(kubectl get rc my-rc --output=json | jq -j '.spec.selector | to_entries echo $(kubectl get pods --selector=$sel --output=jsonpath={.items..metadata.name}) # Show labels for all pods (or any other Kubernetes object that supports labelling) -# Also uses "jq" -for item in $( kubectl get pod --output=name); do printf "Labels for %s\n" "$item" | grep --color -E '[^/]+$' && kubectl get "$item" --output=json | jq -r -S '.metadata.labels | to_entries | .[] | " \(.key)=\(.value)"' 2>/dev/null; printf "\n"; done - -# Or this command can be used as well to get all the labels associated with pods kubectl get pods --show-labels # Check which nodes are ready @@ -294,86 +322,91 @@ JSONPATH='{range .items[*]}{@.metadata.name}:{range @.status.conditions[*]}{@.ty # List all Secrets currently in use by a pod kubectl get pods -o json | jq '.items[].spec.containers[].env[]?.valueFrom.secretKeyRef.name' | grep -v null | sort | uniq +# List all containerIDs of initContainer of all pods +# Helpful when cleaning up stopped containers, while avoiding removal of initContainers. +kubectl get pods --all-namespaces -o jsonpath='{range .items[*].status.initContainerStatuses[*]}{.containerID}{"\n"}{end}' | cut -d/ -f3 + # List Events sorted by timestamp kubectl get events --sort-by=.metadata.creationTimestamp -``` --> -```bash -# 使用 get 命令获取基本输出 -kubectl get services # 列出当前命名空间下的所有 services -kubectl get pods --all-namespaces # 列出所有命名空间下的全部的 pods -kubectl get pods -o wide # 列出当前命名空间下的全部 pods，有更多的详细信息 -kubectl get deployment my-dep # 列出某个特定的 deployment -kubectl get pods --include-uninitialized # 列出当前命名空间下的全部 pods，包含未初始化的 -kubectl get pod my-pod -o yaml # 获取一个 pod 的 YAML -kubectl get pod my-pod -o yaml --export # 获取一个没有集群特定信息的 YAML -# 使用 describe 命令获取详细输出 +# Compares the current state of the cluster against the state that the cluster would be in if the manifest was applied. +kubectl diff -f ./my-manifest.yaml +``` +--> +```bash +# get 命令的基本输出 +kubectl get services # 列出当前命名空间下的所有 services +kubectl get pods --all-namespaces # 列出所有命名空间下的全部的 Pods +kubectl get pods -o wide # 列出当前命名空间下的全部 Pods，并显示更详细的信息 +kubectl get deployment my-dep # 列出某个特定的 Deployment +kubectl get pods # 列出当前命名空间下的全部 Pods +kubectl get pod my-pod -o yaml # 获取一个 pod 的 YAML + +# describe 命令的详细输出 kubectl describe nodes my-node kubectl describe pods my-pod -kubectl get services --sort-by=.metadata.name # 列出当前命名空间下所有 services，按照名称排序 +# 列出当前名字空间下所有 Services，按名称排序 +kubectl get services --sort-by=.metadata.name -# 列出 pods 按照重启次数进行排序 +# 列出 Pods，按重启次数排序 kubectl get pods --sort-by='.status.containerStatuses[0].restartCount' -# 列出测试命名空间中的 Pod，按容量排序 -kubectl get pods -n test --sort-by=.spec.capacity.storage +# 列举所有 PV 持久卷，按容量排序 +kubectl get pv --sort-by=.spec.capacity.storage -# 获取包含 app=cassandra 标签全部 pods 的 version 标签 +# 获取包含 app=cassandra 标签的所有 Pods 的 version 标签 kubectl get pods --selector=app=cassandra -o \ jsonpath='{.items[*].metadata.labels.version}' -# 获取所有工作节点(使用选择器以排除标签名称为 'node-role.kubernetes.io/master' 的结果) +# 获取所有工作节点（使用选择器以排除标签名称为 'node-role.kubernetes.io/master' 的结果） kubectl get node --selector='!node-role.kubernetes.io/master' -# 获取当前命名空间中正在运行的 pods +# 获取当前命名空间中正在运行的 Pods kubectl get pods --field-selector=status.phase=Running -# 获取全部 node 的 ExternalIP 地址 +# 获取全部节点的 ExternalIP 地址 kubectl get nodes -o jsonpath='{.items[*].status.addresses[?(@.type=="ExternalIP")].address}' -# 列出属于某个特定 RC 的 pods 的名称 -# "jq" 命令对于 jsonpath 过于复杂的转换非常有用，可以在 https://stedolan.github.io/jq/ 找到它。 +# 列出属于某个特定 RC 的 Pods 的名称 +# 在转换对于 jsonpath 过于复杂的场合，"jq" 命令很有用；可以在 https://stedolan.github.io/jq/ 找到它。 sel=${$(kubectl get rc my-rc --output=json | jq -j '.spec.selector | to_entries | .[] | "\(.key)=\(.value),"')%?} echo $(kubectl get pods --selector=$sel --output=jsonpath={.items..metadata.name}) -# 显示所有 Pod 的标签(或任何其他支持标签的 Kubernetes 对象) -# 也可以使用 "jq" -for item in $( kubectl get pod --output=name); do printf "Labels for %s\n" "$item" | grep --color -E '[^/]+$' && kubectl get "$item" --output=json | jq -r -S '.metadata.labels | to_entries | .[] | " \(.key)=\(.value)"' 2>/dev/null; printf "\n"; done - -# 或也可以使用此命令来获取与容器关联的所有标签 +# 显示所有 Pods 的标签（或任何其他支持标签的 Kubernetes 对象） kubectl get pods --show-labels -# 检查哪些节点处于 ready +# 检查哪些节点处于就绪状态 JSONPATH='{range .items[*]}{@.metadata.name}:{range @.status.conditions[*]}{@.type}={@.status};{end}{end}' \ && kubectl get nodes -o jsonpath="$JSONPATH" | grep "Ready=True" -# 列出被一个 pod 使用的全部 secret +# 列出被一个 Pod 使用的全部 Secret kubectl get pods -o json | jq '.items[].spec.containers[].env[]?.valueFrom.secretKeyRef.name' | grep -v null | sort | uniq -# 列出 events，按照创建时间排序 +# 列举所有 Pods 中初始化容器的容器 ID（containerID） +# Helpful when cleaning up stopped containers, while avoiding removal of initContainers. +kubectl get pods --all-namespaces -o jsonpath='{range .items[*].status.initContainerStatuses[*]}{.containerID}{"\n"}{end}' | cut -d/ -f3 + +# 列出事件（Events），按时间戳排序 kubectl get events --sort-by=.metadata.creationTimestamp + +# 比较当前的集群状态和假定某清单被应用之后的集群状态 +kubectl diff -f ./my-manifest.yaml ``` -<!-- ## Updating Resources --> +<!-- +## Updating Resources +--> ## 更新资源 -<!-- As of version 1.11 `rolling-update` have been deprecated (see [CHANGELOG-1.11.md](https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG/CHANGELOG-1.11.md)), use `rollout` instead. --> -从版本 1.11 开始，`rolling-update` 已被弃用（参见 [CHANGELOG-1.11.md](https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG/CHANGELOG-1.11.md))，请使用 `rollout` 代替。 - -<!-- ```bash +<!-- +```bash kubectl set image deployment/frontend www=image:v2 # Rolling update "www" containers of "frontend" deployment, updating the image kubectl rollout history deployment/frontend # Check the history of deployments including the revision kubectl rollout undo deployment/frontend # Rollback to the previous deployment kubectl rollout undo deployment/frontend --to-revision=2 # Rollback to a specific revision kubectl rollout status -w deployment/frontend # Watch rolling update status of "frontend" deployment until completion - - -# deprecated starting version 1.11 -kubectl rolling-update frontend-v1 -f frontend-v2.json # (deprecated) Rolling update pods of frontend-v1 -kubectl rolling-update frontend-v1 frontend-v2 --image=image:v2 # (deprecated) Change the name of the resource and update the image -kubectl rolling-update frontend --image=image:v2 # (deprecated) Update the pods image of frontend -kubectl rolling-update frontend-v1 frontend-v2 --rollback # (deprecated) Abort existing rollout in progress +kubectl rollout restart deployment/frontend # Rolling restart of the "frontend" deployment cat pod.json | kubectl replace -f - # Replace a pod based on the JSON passed into std @@ -389,41 +422,39 @@ kubectl get pod mypod -o yaml | sed 's/\(image: myimage\):.*$/\1:v4/' | kubectl kubectl label pods my-pod new-label=awesome # Add a Label kubectl annotate pods my-pod icon-url=http://goo.gl/XXBTWq # Add an annotation kubectl autoscale deployment foo --min=2 --max=10 # Auto scale a deployment "foo" -``` --> +``` +--> ```bash -kubectl set image deployment/frontend www=image:v2 # 滚动更新 "frontend" deployment 的 "www" 容器镜像 -kubectl rollout history deployment/frontend # 检查部署的历史记录，包括版本 +kubectl set image deployment/frontend www=image:v2 # 滚动更新 "frontend" Deployment 的 "www" 容器镜像 +kubectl rollout history deployment/frontend # 检查 Deployment 的历史记录，包括版本 kubectl rollout undo deployment/frontend # 回滚到上次部署版本 kubectl rollout undo deployment/frontend --to-revision=2 # 回滚到特定部署版本 -kubectl rollout status -w deployment/frontend # Watch "frontend" deployment 的滚动升级状态直到完成 +kubectl rollout status -w deployment/frontend # 监视 "frontend" Deployment 的滚动升级状态直到完成 +kubectl rollout restart deployment/frontend # 轮替重启 "frontend" Deployment -# 从 1.11 版本开始弃用 -kubectl rolling-update frontend-v1 -f frontend-v2.json # (弃用) 滚动升级 frontend-v1 的 pods -kubectl rolling-update frontend-v1 frontend-v2 --image=image:v2 # (弃用) 修改资源的名称并更新镜像 -kubectl rolling-update frontend --image=image:v2 # (弃用) 更新 frontend 的 pods 的镜像 -kubectl rolling-update frontend-v1 frontend-v2 --rollback # (弃用) 终止已经进行中的 rollout +cat pod.json | kubectl replace -f - # 通过传入到标准输入的 JSON 来替换 Pod -cat pod.json | kubectl replace -f - # 通过传入到标准输入的 JSON 来替换 pod - -# 强制进行替换，会删除然后再创建资源，会导致服务不可用。 +# 强制替换，删除后重建资源。会导致服务不可用。 kubectl replace --force -f ./pod.json # 为多副本的 nginx 创建服务，使用 80 端口提供服务，连接到容器的 8000 端口。 kubectl expose rc nginx --port=80 --target-port=8000 -# 更新单容器 pod 的镜像标签到 v4 +# 将某单容器 Pod 的镜像版本（标签）更新到 v4 kubectl get pod mypod -o yaml | sed 's/\(image: myimage\):.*$/\1:v4/' | kubectl replace -f - kubectl label pods my-pod new-label=awesome # 添加标签 kubectl annotate pods my-pod icon-url=http://goo.gl/XXBTWq # 添加注解 -kubectl autoscale deployment foo --min=2 --max=10 # 使 "foo" deployment 自动伸缩容 +kubectl autoscale deployment foo --min=2 --max=10 # 对 "foo" Deployment 自动伸缩容 ``` <!-- ## Patching Resources --> -## 局部更新资源 +## 部分更新资源 -<!-- ```bash -kubectl patch node k8s-node-1 -p '{"spec":{"unschedulable":true}}' # Partially update a node +<!-- +```bash +# Partially update a node +kubectl patch node k8s-node-1 -p '{"spec":{"unschedulable":true}}' # Update a container's image; spec.containers[*].name is required because it's a merge key kubectl patch pod valid-pod -p '{"spec":{"containers":[{"name":"kubernetes-serve-hostname","image":"new image"}]}}' @@ -436,38 +467,48 @@ kubectl patch deployment valid-deployment --type json -p='[{"op": "remove", " # Add a new element to a positional array kubectl patch sa default --type='json' -p='[{"op": "add", "path": "/secrets/1", "value": {"name": "whatever" } }]' -``` --> +``` +--> ```bash -kubectl patch node k8s-node-1 -p '{"spec":{"unschedulable":true}}' # 部分更新 node +# 部分更新某节点 +kubectl patch node k8s-node-1 -p '{"spec":{"unschedulable":true}}' -#更新容器的镜像；spec.containers[*].name 是必须的。因为它是一个合并 key。 +# 更新容器的镜像；spec.containers[*].name 是必须的。因为它是一个合并性质的主键。 kubectl patch pod valid-pod -p '{"spec":{"containers":[{"name":"kubernetes-serve-hostname","image":"new image"}]}}' -# 使用带位置数组的 json patch 更新容器的镜像 +# 使用带位置数组的 JSON patch 更新容器的镜像 kubectl patch pod valid-pod --type='json' -p='[{"op": "replace", "path": "/spec/containers/0/image", "value":"new image"}]' -# 使用带位置数组的 json patch 禁用 deployment 的 livenessProbe +# 使用带位置数组的 JSON patch 禁用某 Deployment 的 livenessProbe kubectl patch deployment valid-deployment --type json -p='[{"op": "remove", "path": "/spec/template/spec/containers/0/livenessProbe"}]' # 在带位置数组中添加元素 kubectl patch sa default --type='json' -p='[{"op": "add", "path": "/secrets/1", "value": {"name": "whatever" } }]' ``` -<!-- ## Editing Resources --> -## 编辑资源 -<!-- The edit any API resource in an editor. --> -在编辑器中编辑任何 API 资源 +<!-- +## Editing Resources -<!-- ```bash +The edit any API resource in an editor. +--> +## 编辑资源 + +使用你偏爱的编辑器编辑 API 资源。 + +<!-- +```bash kubectl edit svc/docker-registry # Edit the service named docker-registry KUBE_EDITOR="nano" kubectl edit svc/docker-registry # Use an alternative editor -``` --> +``` +--> ```bash -kubectl edit svc/docker-registry # 编辑名为 docker-registry 的 service +kubectl edit svc/docker-registry # 编辑名为 docker-registry 的服务 KUBE_EDITOR="nano" kubectl edit svc/docker-registry # 使用其他编辑器 ``` -<!-- ## Scaling Resources --> +<!-- +## Scaling Resources +--> ## 对资源进行伸缩 <!-- ```bash @@ -475,40 +516,47 @@ kubectl scale --replicas=3 rs/foo # Scale a repl kubectl scale --replicas=3 -f foo.yaml # Scale a resource specified in "foo.yaml" to 3 kubectl scale --current-replicas=2 --replicas=3 deployment/mysql # If the deployment named mysql's current size is 2, scale mysql to 3 kubectl scale --replicas=5 rc/foo rc/bar rc/baz # Scale multiple replication controllers -``` --> +``` +--> ```bash kubectl scale --replicas=3 rs/foo # 将名为 'foo' 的副本集伸缩到 3 副本 kubectl scale --replicas=3 -f foo.yaml # 将在 "foo.yaml" 中的特定资源伸缩到 3 个副本 -kubectl scale --current-replicas=2 --replicas=3 deployment/mysql # 如果名为 mysql 的 deployment 的副本当前是 2，那么将它伸缩到 3 -kubectl scale --replicas=5 rc/foo rc/bar rc/baz # 伸缩多个 replication controllers +kubectl scale --current-replicas=2 --replicas=3 deployment/mysql # 如果名为 mysql 的 Deployment 的副本当前是 2，那么将它伸缩到 3 +kubectl scale --replicas=5 rc/foo rc/bar rc/baz # 伸缩多个副本控制器 ``` -<!-- ## Deleting Resources --> +<!-- +## Deleting Resources +--> ## 删除资源 <!-- ```bash kubectl delete -f ./pod.json # Delete a pod using the type and name specified in pod.json kubectl delete pod,service baz foo # Delete pods and services with same names "baz" and "foo" kubectl delete pods,services -l name=myLabel # Delete pods and services with label name=myLabel -kubectl delete pods,services -l name=myLabel --include-uninitialized # Delete pods and services, including uninitialized ones, with label name=myLabel -kubectl -n my-ns delete po,svc --all # Delete all pods and services, including uninitialized ones, in namespace my-ns, +kubectl delete pods,services -l name=myLabel # Delete pods and services with label name=myLabel +kubectl -n my-ns delete po,svc --all # Delete all pods and services in namespace my-ns, # Delete all pods matching the awk pattern1 or pattern2 kubectl get pods -n mynamespace --no-headers=true | awk '/pattern1|pattern2/{print $1}' | xargs kubectl delete -n mynamespace pod -``` --> +``` +--> ```bash -kubectl delete -f ./pod.json # 删除在 pod.json 中指定的类型和名称的 pod -kubectl delete pod,service baz foo # 删除名称为 "baz" 和 "foo" 的 pod 和 service -kubectl delete pods,services -l name=myLabel # 删除包含 name=myLabel 标签的 pods 和 services -kubectl delete pods,services -l name=myLabel --include-uninitialized # 删除包含 label name=myLabel 标签的 pods 和 services，包括未初始化的 -kubectl -n my-ns delete po,svc --all # 删除在 my-ns 命名空间中全部的 pods 和 services ，包括未初始化的 -# 删除所有与 pattern1 或 pattern2 匹配的 pod +kubectl delete -f ./pod.json # 删除在 pod.json 中指定的类型和名称的 Pod +kubectl delete pod,service baz foo # 删除名称为 "baz" 和 "foo" 的 Pod 和服务 +kubectl delete pods,services -l name=myLabel # 删除包含 name=myLabel 标签的 pods 和服务 +kubectl delete pods,services -l name=myLabel --include-uninitialized # 删除包含 label name=myLabel 标签的 Pods 和服务 +kubectl -n my-ns delete po,svc --all # 删除在 my-ns 名字空间中全部的 Pods 和服务 +# 删除所有与 pattern1 或 pattern2 awk 模式匹配的 Pods kubectl get pods -n mynamespace --no-headers=true | awk '/pattern1|pattern2/{print $1}' | xargs kubectl delete -n mynamespace pod ``` -<!-- ## Interacting with running Pods --> +<!-- +## Interacting with running Pods +--> ## 与运行中的 Pods 进行交互 -<!-- ```bash +<!-- +```bash kubectl logs my-pod # dump pod logs (stdout) kubectl logs -l name=myLabel # dump pod logs, with label name=myLabel (stdout) kubectl logs my-pod --previous # dump pod logs (stdout) for a previous instantiation of a container @@ -519,34 +567,47 @@ kubectl logs -f my-pod # stream pod logs (stdout) kubectl logs -f my-pod -c my-container # stream pod container logs (stdout, multi-container case) kubectl logs -f -l name=myLabel --all-containers # stream all pods logs with label name=myLabel (stdout) kubectl run -i --tty busybox --image=busybox -- sh # Run pod as interactive shell +kubectl run nginx --image=nginx -n +mynamespace # Run pod nginx in a specific namespace +kubectl run nginx --image=nginx # Run pod nginx and write its spec into a file called pod.yaml +--dry-run=client -o yaml > pod.yaml + kubectl attach my-pod -i # Attach to Running Container kubectl port-forward my-pod 5000:6000 # Listen on port 5000 on the local machine and forward to port 6000 on my-pod kubectl exec my-pod -- ls / # Run command in existing pod (1 container case) kubectl exec my-pod -c my-container -- ls / # Run command in existing pod (multi-container case) kubectl top pod POD_NAME --containers # Show metrics for a given pod and its containers -``` --> +``` +--> ```bash -kubectl logs my-pod # 获取 pod 日志(标准输出) -kubectl logs -l name=myLabel # 获取 pod label name=myLabel 日志(标准输出) -kubectl logs my-pod --previous # 获取上个容器实例的 pod 日志(标准输出) -kubectl logs my-pod -c my-container # 获取 pod 的容器日志 (标准输出, 多容器的场景) -kubectl logs -l name=myLabel -c my-container # 获取 label name=myLabel pod 的容器日志 (标准输出, 多容器的场景) -kubectl logs my-pod -c my-container --previous # 获取 pod 的上个容器实例日志 (标准输出, 多容器的场景) -kubectl logs -f my-pod # 流式输出 pod 的日志 (标准输出) -kubectl logs -f my-pod -c my-container # 流式输出 pod 容器的日志 (标准输出, 多容器的场景) -kubectl logs -f -l name=myLabel --all-containers # 流式输出 label name=myLabel pod 的日志 (标准输出) -kubectl run -i --tty busybox --image=busybox -- sh # 以交互式 shell 运行 pod -kubectl attach my-pod -i # 进入到一个运行中的容器中 +kubectl logs my-pod # 获取 pod 日志（标准输出） +kubectl logs -l name=myLabel # 获取含 name=myLabel 标签的 Pods 的日志（标准输出） +kubectl logs my-pod --previous # 获取上个容器实例的 pod 日志（标准输出） +kubectl logs my-pod -c my-container # 获取 Pod 容器的日志（标准输出, 多容器场景） +kubectl logs -l name=myLabel -c my-container # 获取含 name=myLabel 标签的 Pod 容器日志（标准输出, 多容器场景） +kubectl logs my-pod -c my-container --previous # 获取 Pod 中某容器的上个实例的日志（标准输出, 多容器场景） +kubectl logs -f my-pod # 流式输出 Pod 的日志（标准输出） +kubectl logs -f my-pod -c my-container # 流式输出 Pod 容器的日志（标准输出, 多容器场景） +kubectl logs -f -l name=myLabel --all-containers # 流式输出含 name=myLabel 标签的 Pod 的所有日志（标准输出） +kubectl run -i --tty busybox --image=busybox -- sh # 以交互式 Shell 运行 Pod +kubectl run nginx --image=nginx -n mynamespace # 在指定名字空间中运行 nginx Pod +kubectl run nginx --image=nginx # 运行 ngins Pod 并将其规约写入到名为 pod.yaml 的文件 + --dry-run=client -o yaml > pod.yaml + +kubectl attach my-pod -i # 挂接到一个运行的容器中 kubectl port-forward my-pod 5000:6000 # 在本地计算机上侦听端口 5000 并转发到 my-pod 上的端口 6000 -kubectl exec my-pod -- ls / # 在已有的 pod 中运行命令(单容器的场景) -kubectl exec my-pod -c my-container -- ls / # 在已有的 pod 中运行命令(多容器的场景) -kubectl top pod POD_NAME --containers # 显示给定 pod 和容器的监控数据 +kubectl exec my-pod -- ls / # 在已有的 Pod 中运行命令（单容器场景） +kubectl exec my-pod -c my-container -- ls / # 在已有的 Pod 中运行命令（多容器场景） +kubectl top pod POD_NAME --containers # 显示给定 Pod 和其中容器的监控数据 ``` -<!-- ## Interacting with Nodes and Cluster --> +<!-- +## Interacting with Nodes and Cluster +--> ## 与节点和集群进行交互 -<!-- ```bash +<!-- +```bash kubectl cordon my-node # Mark my-node as unschedulable kubectl drain my-node # Drain my-node in preparation for maintenance kubectl uncordon my-node # Mark my-node as schedulable @@ -557,57 +618,70 @@ kubectl cluster-info dump --output-directory=/path/to/cluster-state # Dump cur # If a taint with that key and effect already exists, its value is replaced as specified. kubectl taint nodes foo dedicated=special-user:NoSchedule -``` --> +``` +--> ```bash -kubectl cordon my-node # 设置 my-node 节点为不可调度 -kubectl drain my-node # 对 my-node 节点进行驱逐操作，为节点维护做准备 -kubectl uncordon my-node # 设置 my-node 节点为可以调度 -kubectl top node my-node # 显示给定 node 的指标 -kubectl cluster-info # 显示 master 和 services 的地址 -kubectl cluster-info dump # 将当前集群状态输出到标准输出 +kubectl cordon my-node # 标记 my-node 节点为不可调度 +kubectl drain my-node # 对 my-node 节点进行清空操作，为节点维护做准备 +kubectl uncordon my-node # 标记 my-node 节点为可以调度 +kubectl top node my-node # 显示给定节点的度量值 +kubectl cluster-info # 显示主控节点和服务的地址 +kubectl cluster-info dump # 将当前集群状态转储到标准输出 kubectl cluster-info dump --output-directory=/path/to/cluster-state # 将当前集群状态输出到 /path/to/cluster-state -# 如果已存在具有该键和效果的污点，则其值将按指定替换 +# 如果已存在具有指定键和效果的污点，则替换其值为指定值 kubectl taint nodes foo dedicated=special-user:NoSchedule ``` -<!-- ### Resource types --> +<!-- +### Resource types +--> ### 资源类型 -<!-- List all supported resource types along with their shortnames, [API group](/docs/concepts/overview/kubernetes-api/#api-groups), whether they are [namespaced](/docs/concepts/overview/working-with-objects/namespaces), and [Kind](/docs/concepts/overview/working-with-objects/kubernetes-objects): --> -列出全部支持的资源类型和它们的简称, [API group](/docs/concepts/overview/kubernetes-api/#api-groups), 无论它们是否是 [namespaced](/docs/concepts/overview/working-with-objects/namespaces), [Kind](/docs/concepts/overview/working-with-objects/kubernetes-objects)。 +<!-- +List all supported resource types along with their shortnames, [API group](/docs/concepts/overview/kubernetes-api/#api-groups), whether they are [namespaced](/docs/concepts/overview/working-with-objects/namespaces), and [Kind](/docs/concepts/overview/working-with-objects/kubernetes-objects): +--> +列出所支持的全部资源类型和它们的简称、[API 组](/docs/concepts/overview/kubernetes-api/#api-groups), 是否是[名字空间作用域](/docs/concepts/overview/working-with-objects/namespaces) 和 [Kind](/docs/concepts/overview/working-with-objects/kubernetes-objects)。 ```bash kubectl api-resources ``` -<!-- Other operations for exploring API resources: --> +<!-- +Other operations for exploring API resources: +--> 用于探索 API 资源的其他操作： -<!-- ```bash +<!-- +```bash kubectl api-resources --namespaced=true # All namespaced resources kubectl api-resources --namespaced=false # All non-namespaced resources kubectl api-resources -o name # All resources with simple output (just the resource name) kubectl api-resources -o wide # All resources with expanded (aka "wide") output kubectl api-resources --verbs=list,get # All resources that support the "list" and "get" request verbs kubectl api-resources --api-group=extensions # All resources in the "extensions" API group -``` --> +``` +--> ```bash -kubectl api-resources --namespaced=true # 所有在命名空间中的资源 -kubectl api-resources --namespaced=false # 所有不在命名空间中的资源 -kubectl api-resources -o name # 输出简单的所有资源（只是资源名称） -kubectl api-resources -o wide # 具有扩展（又称 "wide"）输出的所有资源 +kubectl api-resources --namespaced=true # 所有命名空间作用域的资源 +kubectl api-resources --namespaced=false # 所有非命名空间作用域的资源 +kubectl api-resources -o name # 用简单格式列举所有资源（仅显示资源名称） +kubectl api-resources -o wide # 用扩展格式列举所有资源（又称 "wide" 格式） kubectl api-resources --verbs=list,get # 支持 "list" 和 "get" 请求动词的所有资源 kubectl api-resources --api-group=extensions # "extensions" API 组中的所有资源 ``` -<!-- ### Formatting output --> +<!-- +### Formatting output + +To output details to your terminal window in a specific format, you can add either the `-o` or `--output` flags to a supported `kubectl` command. +--> ### 格式化输出 -<!-- To output details to your terminal window in a specific format, you can add either the `-o` or `--output` flags to a supported `kubectl` command. --> 要以特定格式将详细信息输出到终端窗口，可以将 `-o` 或 `--output` 参数添加到支持的 `kubectl` 命令。 -<!-- Output format | Description +<!--O +utput format | Description --------------| ----------- `-o=custom-columns=<spec>` | Print a table using a comma separated list of custom columns `-o=custom-columns-file=<filename>` | Print a table using the custom columns template in the `<filename>` file @@ -616,25 +690,63 @@ kubectl api-resources --api-group=extensions # "extensions" API 组中的所有 `-o=jsonpath-file=<filename>` | Print the fields defined by the [jsonpath](/docs/reference/kubectl/jsonpath) expression in the `<filename>` file `-o=name` | Print only the resource name and nothing else `-o=wide` | Output in the plain-text format with any additional information, and for pods, the node name is included -`-o=yaml` | Output a YAML formatted API object --> -输出格式 | 描述 +`-o=yaml` | Output a YAML formatted API object +--> +输出格式 | 描述 --------------| ----------- -`-o=custom-columns=<spec>` | 使用逗号分隔的自定义列列表打印表格 +`-o=custom-columns=<spec>` | 使用逗号分隔的自定义列来打印表格 `-o=custom-columns-file=<filename>` | 使用 `<filename>` 文件中的自定义列模板打印表格 `-o=json` | 输出 JSON 格式的 API 对象 `-o=jsonpath=<template>` | 打印 [jsonpath](/docs/reference/kubectl/jsonpath) 表达式中定义的字段 -`-o=jsonpath-file=<filename>` | 在 `<filename>` 文件中打印由 [jsonpath](/docs/reference/kubectl/jsonpath) 表达式定义的字段。 -`-o=name` | 仅打印资源名称而不打印任何其他内容 -`-o=wide` | 使用任何其他信息以纯文本格式输出，对于 pod 来说，包含了节点名称 +`-o=jsonpath-file=<filename>` | 打印在 `<filename>` 文件中定义的 [jsonpath](/docs/reference/kubectl/jsonpath) 表达式所指定的字段。 +`-o=name` | 仅打印资源名称而不打印其他内容 +`-o=wide` | 以纯文本格式输出额外信息，对于 Pod 来说，输出中包含了节点名称 `-o=yaml` | 输出 YAML 格式的 API 对象 -<!-- ### Kubectl output verbosity and debugging --> +<!-- +Examples using `-o=custom-columns`: + +```bash +# All images running in a cluster +kubectl get pods -A -o=custom-columns='DATA:spec.containers[*].image' + + # All images excluding "k8s.gcr.io/coredns:1.6.2" +kubectl get pods -A -o=custom-columns='DATA:spec.containers[?(@.image!="k8s.gcr.io/coredns:1.6.2")].image' + +# All fields under metadata regardless of name +kubectl get pods -A -o=custom-columns='DATA:metadata.*' + +More examples in the kubectl [reference documentation](/docs/reference/kubectl/overview/#custom-columns). +``` +--> +使用 `-o=custom-columns` 的示例： + +```bash +# 集群中运行着的所有镜像 +kubectl get pods -A -o=custom-columns='DATA:spec.containers[*].image' + + # 除 "k8s.gcr.io/coredns:1.6.2" 之外的所有镜像 +kubectl get pods -A -o=custom-columns='DATA:spec.containers[?(@.image!="k8s.gcr.io/coredns:1.6.2")].image' + +# 输出 metadata 下面的所有字段，无论 Pod 名字为何 +kubectl get pods -A -o=custom-columns='DATA:metadata.*' +``` + +有关更多示例，请参看 kubectl [参考文档](/docs/reference/kubectl/overview/#custom-columns)。 + +<!-- +### Kubectl output verbosity and debugging + +Kubectl verbosity is controlled with the `-v` or `--v` flags followed by an integer representing the log level. General Kubernetes logging conventions and the associated log levels are described [here](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-instrumentation/logging.md). +--> ### Kubectl 日志输出详细程度和调试 -<!-- Kubectl verbosity is controlled with the `-v` or `--v` flags followed by an integer representing the log level. General Kubernetes logging conventions and the associated log levels are described [here](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-instrumentation/logging.md). --> -Kubectl 日志输出详细程度是通过 `-v` 或者 `--v` 来控制的，参数后跟了一个数字表示日志的级别。Kubernetes 通用的日志习惯和相关的日志级别在 [这里](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-instrumentation/logging.md) 有相应的描述。 +Kubectl 日志输出详细程度是通过 `-v` 或者 `--v` 来控制的，参数后跟一个数字表示日志的级别。 +Kubernetes 通用的日志习惯和相关的日志级别在 +[这里](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-instrumentation/logging.md) 有相应的描述。 -<!-- Verbosity | Description +<!-- +Verbosity | Description --------------| ----------- `--v=0` | Generally useful for this to *always* be visible to a cluster operator. `--v=1` | A reasonable default log level if you don't want verbosity. @@ -644,37 +756,30 @@ Kubectl 日志输出详细程度是通过 `-v` 或者 `--v` 来控制的，参 `--v=6` | Display requested resources. `--v=7` | Display HTTP request headers. `--v=8` | Display HTTP request contents. -`--v=9` | Display HTTP request contents without truncation of contents. --> -详细程度 | 描述 +`--v=9` | Display HTTP request contents without truncation of contents. +--> +详细程度 | 描述 --------------| ----------- -`--v=0` | 通常对此有用，*始终*对运维人员可见。 -`--v=1` | 如果您不想要详细程度，则为合理的默认日志级别。 -`--v=2` | 有关服务的有用稳定状态信息以及可能与系统中的重大更改相关的重要日志消息。这是大多数系统的建议默认日志级别。 -`--v=3` | 有关更改的扩展信息。 -`--v=4` | Debug 级别。 -`--v=6` | 显示请求的资源。 +`--v=0` | 用于那些应该 *始终* 对运维人员可见的信息，因为这些信息一般很有用。 +`--v=1` | 如果您不想要看到冗余信息，此值是一个合理的默认日志级别。 +`--v=2` | 输出有关服务的稳定状态的信息以及重要的日志消息，这些信息可能与系统中的重大变化有关。这是建议大多数系统设置的默认日志级别。 +`--v=3` | 包含有关系统状态变化的扩展信息。 +`--v=4` | 包含调试级别的冗余信息。 +`--v=6` | 显示所请求的资源。 `--v=7` | 显示 HTTP 请求头。 `--v=8` | 显示 HTTP 请求内容。 -`--v=9` | 显示 HTTP 请求内容而不截断内容。 - - +`--v=9` | 显示 HTTP 请求内容而且不截断内容。 ## {{% heading "whatsnext" %}} - -<!-- * Learn more about [Overview of kubectl](/docs/reference/kubectl/overview/). - +<!-- +* Learn more about [Overview of kubectl](/docs/reference/kubectl/overview/). * See [kubectl](/docs/reference/kubectl/kubectl/) options. - * Also [kubectl Usage Conventions](/docs/reference/kubectl/conventions/) to understand how to use it in reusable scripts. - -* See more community [kubectl cheatsheets](https://github.com/dennyzhang/cheatsheet-kubernetes-A4). --> -* 学习更多关于 [kubectl 概述](/docs/reference/kubectl/overview/)。 - -* 查看 [kubectl](/docs/reference/kubectl/kubectl/) 选项. - -* 也可以查看 [kubectl 使用约定](/docs/reference/kubectl/conventions/) 来理解如果在可以复用的脚本中使用它。 - -* 查看更多社区 [kubectl 备忘单](https://github.com/dennyzhang/cheatsheet-kubernetes-A4)。 - +* See more community [kubectl cheatsheets](https://github.com/dennyzhang/cheatsheet-kubernetes-A4). +--> +* 进一步了解 [kubectl 概述](/docs/reference/kubectl/overview/)。 +* 参阅 [kubectl](/docs/reference/kubectl/kubectl/) 选项. +* 参阅 [kubectl 使用约定](/docs/reference/kubectl/conventions/)来理解如何在可复用的脚本中使用它。 +* 查看社区中其他的 [kubectl 备忘单](https://github.com/dennyzhang/cheatsheet-kubernetes-A4)。 diff --git a/content/zh/docs/reference/kubectl/kubectl.md b/content/zh/docs/reference/kubectl/kubectl.md index 299f7f8fd9..a40844d663 100644 --- a/content/zh/docs/reference/kubectl/kubectl.md +++ b/content/zh/docs/reference/kubectl/kubectl.md @@ -1,12 +1,12 @@ --- title: kubectl -content_template: templates/tool-reference +content_type: tool-reference weight: 28 --- <!-- --- title: kubectl -content_template: templates/tool-reference +content_type: tool-reference weight: 28 --- --> diff --git a/content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_upgrade_diff.md b/content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_upgrade_diff.md index 0a1580d4f4..62c1fd2152 100644 --- a/content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_upgrade_diff.md +++ b/content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_upgrade_diff.md @@ -1,141 +1,185 @@ <!-- + + ### Synopsis + Show what differences would be applied to existing static pod manifests. See also: kubeadm upgrade apply --dry-run + +``` +kubeadm upgrade diff [version] [flags] +``` --> ### 概述 -显示哪些差异将被应用于现有的静态 pod 资源清单。参考: kubeadm upgrade apply --dry-run + +显示哪些差异将被应用于现有的静态 pod 资源清单。参考: kubeadm upgrade apply --dry-run ``` kubeadm upgrade diff [version] [flags] ``` <!-- + ### Options -``` -<tr> - <td colspan="2">--api-server-manifest string     Default: "/etc/kubernetes/manifests/kube-apiserver.yaml"</td> -</tr> -<tr> - <td></td><td style="line-height: 130%; word-wrap: break-word;">path to API server manifest</td> -</tr> + <table style="width: 100%; table-layout: fixed;"> +<colgroup> +<col span="1" style="width: 10px;" /> +<col span="1" /> +</colgroup> +<tbody> <tr> - <td colspan="2">--config string</td> +<td colspan="2">--api-server-manifest string     Default: "/etc/kubernetes/manifests/kube-apiserver.yaml"</td> </tr> <tr> - <td></td><td style="line-height: 130%; word-wrap: break-word;">Path to a kubeadm configuration file.</td> +<td></td><td style="line-height: 130%; word-wrap: break-word;">path to API server manifest</td> </tr> - -<tr> - <td colspan="2">-c, --context-lines int     Default: 3</td> -</tr> -<tr> - <td></td><td style="line-height: 130%; word-wrap: break-word;">How many lines of context in the diff</td> -</tr> - -<tr> - <td colspan="2">--controller-manager-manifest string     Default: "/etc/kubernetes/manifests/kube-controller-manager.yaml"</td> -</tr> -<tr> - <td></td><td style="line-height: 130%; word-wrap: break-word;">path to controller manifest</td> -</tr> - -<tr> - <td colspan="2">-h, --help</td> -</tr> -<tr> - <td></td><td style="line-height: 130%; word-wrap: break-word;">help for diff</td> -</tr> - -<tr> - <td colspan="2">--kubeconfig string     Default: "/etc/kubernetes/admin.conf"</td> -</tr> -<tr> - <td></td><td style="line-height: 130%; word-wrap: break-word;">The kubeconfig file to use when talking to the cluster. If the flag is not set, a set of standard locations can be searched for an existing kubeconfig file.</td> -</tr> - -<tr> - <td colspan="2">--scheduler-manifest string     Default: "/etc/kubernetes/manifests/kube-scheduler.yaml"</td> -</tr> -<tr> - <td></td><td style="line-height: 130%; word-wrap: break-word;">path to scheduler manifest</td> -</tr> -``` - --> ### 选项 -<tr> - <td colspan="2">--api-server-manifest string     默认值： "/etc/kubernetes/manifests/kube-apiserver.yaml"</td> -</tr> -<tr> - <td></td><td style="line-height: 130%; word-wrap: break-word;">API服务器清单的路径</td> -</tr> + <table style="width: 100%; table-layout: fixed;"> +<colgroup> +<col span="1" style="width: 10px;" /> +<col span="1" /> +</colgroup> +<tbody> <tr> - <td colspan="2">--config string</td> +<td colspan="2">--api-server-manifest string     默认值："/etc/kubernetes/manifests/kube-apiserver.yaml"</td> </tr> <tr> - <td></td><td style="line-height: 130%; word-wrap: break-word;"> API 服务器清单的路径。</td> +<td></td><td style="line-height: 130%; word-wrap: break-word;">API服务器清单的路径</td> +</tr> +<!-- +<tr> +<td colspan="2">--config string</td> +</tr> +<tr> +<td></td><td style="line-height: 130%; word-wrap: break-word;">Path to a kubeadm configuration file.</td> +</tr> +--> +<tr> +<td colspan="2">--config string</td> +</tr> +<tr> +<td></td><td style="line-height: 130%; word-wrap: break-word;">kubeadm 配置文件的路径</td> +</tr> +<!-- +<tr> +<td colspan="2">-c, --context-lines int     Default: 3</td> +</tr> +<tr> +<td></td><td style="line-height: 130%; word-wrap: break-word;">How many lines of context in the diff</td> +</tr> +--> +<tr> +<td colspan="2">-c, --context-lines int     默认值：3</td> +</tr> +<tr> +<td></td><td style="line-height: 130%; word-wrap: break-word;">差异中有多少行上下文</td> +</tr> +<!-- +<tr> +<td colspan="2">--controller-manager-manifest string     Default: "/etc/kubernetes/manifests/kube-controller-manager.yaml"</td> +</tr> +<tr> +<td></td><td style="line-height: 130%; word-wrap: break-word;">path to controller manifest</td> +</tr> +--> +<tr> +<td colspan="2">--controller-manager-manifest string     默认值： "/etc/kubernetes/manifests/kube-controller-manager.yaml"</td> +</tr> +<tr> +<td></td><td style="line-height: 130%; word-wrap: break-word;">控制器清单的路径</td> +</tr> +<!-- +<tr> +<td colspan="2">-h, --help</td> +</tr> +<tr> +<td></td><td style="line-height: 130%; word-wrap: break-word;">help for diff</td> +</tr> +--> +<tr> +<td colspan="2">-h, --help</td> +</tr> +<tr> +<td></td><td style="line-height: 130%; word-wrap: break-word;">帮助</td> +</tr> +<!-- +<tr> +<td colspan="2">--kubeconfig string     Default: "/etc/kubernetes/admin.conf"</td> +</tr> +<tr> +<td></td><td style="line-height: 130%; word-wrap: break-word;">The kubeconfig file to use when talking to the cluster. If the flag is not set, a set of standard locations can be searched for an existing kubeconfig file.</td> +</tr> +--> +<tr> +<td colspan="2">--kubeconfig string     默认值："/etc/kubernetes/admin.conf"</td> +</tr> +<tr> +<td></td><td style="line-height: 130%; word-wrap: break-word;">与集群通信时使用的 kubeconfig 文件，如果标志是未设置，则可以在一组标准位置中搜索现有的 kubeconfig 文件。</td> +</tr> +<!-- +<tr> +<td colspan="2">--scheduler-manifest string     Default: "/etc/kubernetes/manifests/kube-scheduler.yaml"</td> +</tr> +<tr> +<td></td><td style="line-height: 130%; word-wrap: break-word;">path to scheduler manifest</td> </tr> +</tbody> +</table> +--> <tr> - <td colspan="2">-c, --context-lines int     默认值： 3</td> +<td colspan="2">--scheduler-manifest string     默认值："/etc/kubernetes/manifests/kube-scheduler.yaml"</td> </tr> <tr> - <td></td><td style="line-height: 130%; word-wrap: break-word;">差异中有多少行上下文</td> +<td></td><td style="line-height: 130%; word-wrap: break-word;">调度程序清单的路径</td> </tr> -<tr> - <td colspan="2">--controller-manager-manifest string     默认值： "/etc/kubernetes/manifests/kube-controller-manager.yaml"</td> -</tr> -<tr> - <td></td><td style="line-height: 130%; word-wrap: break-word;">控制器清单的路径</td> -</tr> - -<tr> - <td colspan="2">-h, --help</td> -</tr> -<tr> - <td></td><td style="line-height: 130%; word-wrap: break-word;">帮助</td> -</tr> - -<tr> - <td colspan="2">--kubeconfig string     默认值： "/etc/kubernetes/admin.conf"</td> -</tr> -<tr> - <td></td><td style="line-height: 130%; word-wrap: break-word;">与集群通信时使用的 kubeconfig 文件，如果标志是未设置，则可以在一组标准位置中搜索现有的 kubeconfig 文件。</td> -</tr> - -<tr> - <td colspan="2">--scheduler-manifest string     默认值："/etc/kubernetes/manifests/kube-scheduler.yaml"</td> -</tr> -<tr> - <td></td><td style="line-height: 130%; word-wrap: break-word;">调度程序清单的路径</td> -</tr> +</tbody> +</table> <!-- ### Options inherited from parent commands -``` + <table style="width: 100%; table-layout: fixed;"> +<colgroup> +<col span="1" style="width: 10px;" /> +<col span="1" /> +</colgroup> +<tbody> + <tr> - <td colspan="2">--rootfs string</td> +<td colspan="2">--rootfs string</td> </tr> <tr> - <td></td><td style="line-height: 130%; word-wrap: break-word;">[EXPERIMENTAL] The path to the 'real' host root filesystem.</td> +<td></td><td style="line-height: 130%; word-wrap: break-word;">[EXPERIMENTAL] The path to the 'real' host root filesystem.</td> </tr> -``` + +</tbody> +</table> --> + ### 从父命令继承的选项 + <table style="width: 100%; table-layout: fixed;"> +<colgroup> +<col span="1" style="width: 10px;" /> +<col span="1" /> +</colgroup> +<tbody> <tr> - <td colspan="2">--rootfs string</td> +<td colspan="2">--rootfs string</td> </tr> <tr> - <td></td><td style="line-height: 130%; word-wrap: break-word;">[EXPERIMENTAL] “真实”主机根文件系统的路径。</td> +<td></td><td style="line-height: 130%; word-wrap: break-word;">[EXPERIMENTAL] “真实”主机根文件系统的路径。</td> </tr> +</tbody> +</table> + diff --git a/content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_upgrade_plan.md b/content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_upgrade_plan.md index d69f9194b6..6c64e38f0f 100644 --- a/content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_upgrade_plan.md +++ b/content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_upgrade_plan.md @@ -1,147 +1,203 @@ <!-- + +``` ### Synopsis + Check which versions are available to upgrade to and validate whether your current cluster is upgradeable. To skip the internet check, pass in the optional [version] parameter ---> -### 概述 -检查可升级到哪些版本，并验证您当前的集群是否可升级。 要跳过互联网检查，请传递可选的 [version] 参数 - -``` +​``` kubeadm upgrade plan [version] [flags] -``` -<!-- +​``` + ### Options + <table style="width: 100%; table-layout: fixed;"> +<colgroup> +<col span="1" style="width: 10px;" /> +<col span="1" /> +</colgroup> +<tbody> + <tr> - <td colspan="2">--allow-experimental-upgrades</td> +<td colspan="2">--allow-experimental-upgrades</td> </tr> <tr> - <td></td><td style="line-height: 130%; word-wrap: break-word;">Show unstable versions of Kubernetes as an upgrade alternative and allow upgrading to an alpha/beta/release candidate versions of Kubernetes.</td> +<td></td><td style="line-height: 130%; word-wrap: break-word;">Show unstable versions of Kubernetes as an upgrade alternative and allow upgrading to an alpha/beta/release candidate versions of Kubernetes.</td> </tr> <tr> - <td colspan="2">--allow-release-candidate-upgrades</td> +<td colspan="2">--allow-release-candidate-upgrades</td> </tr> <tr> - <td></td><td style="line-height: 130%; word-wrap: break-word;">Show release candidate versions of Kubernetes as an upgrade alternative and allow upgrading to a release candidate versions of Kubernetes.</td> +<td></td><td style="line-height: 130%; word-wrap: break-word;">Show release candidate versions of Kubernetes as an upgrade alternative and allow upgrading to a release candidate versions of Kubernetes.</td> </tr> <tr> - <td colspan="2">--config string</td> +<td colspan="2">--config string</td> </tr> <tr> - <td></td><td style="line-height: 130%; word-wrap: break-word;">Path to a kubeadm configuration file.</td> +<td></td><td style="line-height: 130%; word-wrap: break-word;">Path to a kubeadm configuration file.</td> </tr> <tr> - <td colspan="2">--feature-gates string</td> +<td colspan="2">--feature-gates string</td> </tr> <tr> - <td></td><td style="line-height: 130%; word-wrap: break-word;">A set of key=value pairs that describe feature gates for various features. Options are:<br/>IPv6DualStack=true|false (ALPHA - default=false)</td> +<td></td><td style="line-height: 130%; word-wrap: break-word;">A set of key=value pairs that describe feature gates for various features. Options are:<br/>IPv6DualStack=true|false (ALPHA - default=false)<br/>PublicKeysECDSA=true|false (ALPHA - default=false)</td> </tr> <tr> - <td colspan="2">-h, --help</td> +<td colspan="2">-h, --help</td> </tr> <tr> - <td></td><td style="line-height: 130%; word-wrap: break-word;">help for plan</td> +<td></td><td style="line-height: 130%; word-wrap: break-word;">help for plan</td> </tr> <tr> - <td colspan="2">--ignore-preflight-errors stringSlice</td> +<td colspan="2">--ignore-preflight-errors stringSlice</td> </tr> <tr> - <td></td><td style="line-height: 130%; word-wrap: break-word;">A list of checks whose errors will be shown as warnings. Example: 'IsPrivilegedUser,Swap'. Value 'all' ignores errors from all checks.</td> +<td></td><td style="line-height: 130%; word-wrap: break-word;">A list of checks whose errors will be shown as warnings. Example: 'IsPrivilegedUser,Swap'. Value 'all' ignores errors from all checks.</td> </tr> <tr> - <td colspan="2">--kubeconfig string     Default: "/etc/kubernetes/admin.conf"</td> +<td colspan="2">--kubeconfig string     Default: "/etc/kubernetes/admin.conf"</td> </tr> <tr> - <td></td><td style="line-height: 130%; word-wrap: break-word;">The kubeconfig file to use when talking to the cluster. If the flag is not set, a set of standard locations can be searched for an existing kubeconfig file.</td> +<td></td><td style="line-height: 130%; word-wrap: break-word;">The kubeconfig file to use when talking to the cluster. If the flag is not set, a set of standard locations can be searched for an existing kubeconfig file.</td> </tr> <tr> - <td colspan="2">--print-config</td> +<td colspan="2">--print-config</td> </tr> <tr> - <td></td><td style="line-height: 130%; word-wrap: break-word;">Specifies whether the configuration file that will be used in the upgrade should be printed or not.</td> -</tr> ---> -### 选项 - -<tr> - <td colspan="2">--allow-experimental-upgrades</td> -</tr> -<tr> - <td></td><td style="line-height: 130%; word-wrap: break-word;">显示不稳定版本的 Kubernetes 作为升级替代方案，并允许升级到 Kubernetes 的 Alpha/Beta/发行候选版本。</td> +<td></td><td style="line-height: 130%; word-wrap: break-word;">Specifies whether the configuration file that will be used in the upgrade should be printed or not.</td> </tr> -<tr> - <td colspan="2">--allow-release-candidate-upgrades</td> -</tr> -<tr> - <td></td><td style="line-height: 130%; word-wrap: break-word;">显示 Kubernetes 的发行候选版本作为升级选择，并允许升级到 Kubernetes 的发行候选版本。</td> -</tr> +</tbody> +</table> -<tr> - <td colspan="2">--config string</td> -</tr> -<tr> - <td></td><td style="line-height: 130%; word-wrap: break-word;">kubeadm 配置文件的路径。</td> -</tr> -<tr> - <td colspan="2">--feature-gates string</td> -</tr> -<tr> - <td></td><td style="line-height: 130%; word-wrap: break-word;">一组描述各种特征特性门控的键值对。选项有：<br/>IPv6DualStack=true|false (ALPHA - default=false)</td> -</tr> -<tr> - <td colspan="2">-h, --help</td> -</tr> -<tr> - <td></td><td style="line-height: 130%; word-wrap: break-word;">帮助</td> -</tr> - -<tr> - <td colspan="2">--ignore-preflight-errors stringSlice</td> -</tr> -<tr> - <td></td><td style="line-height: 130%; word-wrap: break-word;">检查清单，其错误将显示为警告。 例如：“IsPrivilegedUser，Swap”。 值 “all” 忽略所有检查的错误。</td> -</tr> - -<tr> - <td colspan="2">--kubeconfig string     Default: "/etc/kubernetes/admin.conf"</td> -</tr> -<tr> - <td></td><td style="line-height: 130%; word-wrap: break-word;">与集群通信时使用的 kubeconfig 文件。 如果标志为未设置，则可以在一组标准位置中搜索现有的 kubeconfig 文件。</td> -</tr> - -<tr> - <td colspan="2">--print-config</td> -</tr> -<tr> - <td></td><td style="line-height: 130%; word-wrap: break-word;">指定是否打印将在升级中使用的配置文件。</td> -</tr> - -<!-- ### Options inherited from parent commands -<tr> - <td colspan="2">--rootfs string</td> -</tr> -<tr> - <td></td><td style="line-height: 130%; word-wrap: break-word;">[EXPERIMENTAL] The path to the 'real' host root filesystem.</td> -</tr> ---> -### 从父命令继承的选项 + <table style="width: 100%; table-layout: fixed;"> +<colgroup> +<col span="1" style="width: 10px;" /> +<col span="1" /> +</colgroup> +<tbody> <tr> - <td colspan="2">--rootfs string</td> +<td colspan="2">--rootfs string</td> </tr> <tr> - <td></td><td style="line-height: 130%; word-wrap: break-word;">[EXPERIMENTAL] “真实”主机根文件系统的路径。</td> +<td></td><td style="line-height: 130%; word-wrap: break-word;">[EXPERIMENTAL] The path to the 'real' host root filesystem.</td> </tr> + +</tbody> +</table> +``` + +--> + +``` +### 概述 + + +检查可升级到哪些版本，并验证您当前的集群是否可升级。 要跳过互联网检查，请传递可选的 [version] 参数 + +​``` +kubeadm upgrade plan [version] [flags] +​``` + +### 选项 + + <table style="width: 100%; table-layout: fixed;"> +<colgroup> +<col span="1" style="width: 10px;" /> +<col span="1" /> +</colgroup> +<tbody> + +<tr> +<td colspan="2">--allow-experimental-upgrades</td> +</tr> +<tr> +<td></td><td style="line-height: 130%; word-wrap: break-word;">显示不稳定版本的 Kubernetes 作为升级替代方案，并允许升级到 Kubernetes 的 Alpha/Beta/发行候选版本。</td> +</tr> + +<tr> +<td colspan="2">--allow-release-candidate-upgrades</td> +</tr> +<tr> +<td></td><td style="line-height: 130%; word-wrap: break-word;">显示 Kubernetes 的发行候选版本作为升级选择，并允许升级到 Kubernetes 的发行候选版本。</td> +</tr> + +<tr> +<td colspan="2">--config string</td> +</tr> +<tr> +<td></td><td style="line-height: 130%; word-wrap: break-word;">配置文件的路径。</td> +</tr> + +<tr> +<td colspan="2">--feature-gates string</td> +</tr> +<tr> +<td></td><td style="line-height: 130%; word-wrap: break-word;">一组描述各种特征特性门控的键值对。选项有：IPv6DualStack=true|false (ALPHA - default=false) PublicKeysECDSA=true|false (ALPHA - default=false)</td> +</tr> + +<tr> +<td colspan="2">-h, --help</td> +</tr> +<tr> +<td></td><td style="line-height: 130%; word-wrap: break-word;">帮助</td> +</tr> + +<tr> +<td colspan="2">--ignore-preflight-errors stringSlice</td> +</tr> +<tr> +<td></td><td style="line-height: 130%; word-wrap: break-word;">检查清单，其错误将显示为警告。 例如：“IsPrivilegedUser，Swap”。 值 “all” 忽略所有检查的错误。</td> +</tr> + +<tr> +<td colspan="2">--kubeconfig string     Default: "/etc/kubernetes/admin.conf"</td> +</tr> +<tr> +<td></td><td style="line-height: 130%; word-wrap: break-word;">与集群通信时使用的 kubeconfig 文件。 如果标志为未设置，则可以在一组标准位置中搜索现有的 kubeconfig 文件。</td> +</tr> + +<tr> +<td colspan="2">--print-config</td> +</tr> +<tr> +<td></td><td style="line-height: 130%; word-wrap: break-word;">指定是否打印将在升级中使用的配置文件。</td> +</tr> + +</tbody> +</table> + + + +### 从父命令继承的选项 + + <table style="width: 100%; table-layout: fixed;"> +<colgroup> +<col span="1" style="width: 10px;" /> +<col span="1" /> +</colgroup> +<tbody> + +<tr> +<td colspan="2">--rootfs string</td> +</tr> +<tr> +<td></td><td style="line-height: 130%; word-wrap: break-word;">[EXPERIMENTAL] “真实”主机根文件系统的路径。</td> +</tr> + +</tbody> +</table> +``` diff --git a/content/zh/docs/reference/setup-tools/kubeadm/kubeadm.md b/content/zh/docs/reference/setup-tools/kubeadm/kubeadm.md index 1d6b42f446..ad5e7a2665 100644 --- a/content/zh/docs/reference/setup-tools/kubeadm/kubeadm.md +++ b/content/zh/docs/reference/setup-tools/kubeadm/kubeadm.md @@ -1,33 +1,63 @@ --- -# title: Overview of kubeadm title: kubeadm 概述 weight: 10 +card: + name: reference + weight: 40 --- +<!-- +reviewers: +- luxas +- jbeda +title: Overview of kubeadm +weight: 10 +card: + name: reference + weight: 40 +--> + <img src="https://raw.githubusercontent.com/cncf/artwork/master/projects/kubernetes/certified-kubernetes/versionless/color/certified-kubernetes-color.png" align="right" width="150px"> -<!-- Kubeadm is a tool built to provide `kubeadm init` and `kubeadm join` as best-practice “fast paths” for creating Kubernetes clusters. --> +<!-- +Kubeadm is a tool built to provide `kubeadm init` and `kubeadm join` as best-practice “fast paths” for creating Kubernetes clusters. +--> Kubeadm 是一个工具，它提供了 `kubeadm init` 以及 `kubeadm join` 这两个命令作为快速创建 kubernetes 集群的最佳实践。 -<!-- kubeadm performs the actions necessary to get a minimum viable cluster up and running. By design, it cares only about bootstrapping, not about provisioning machines. Likewise, installing various nice-to-have addons, like the Kubernetes Dashboard, monitoring solutions, and cloud-specific addons, is not in scope. --> +<!-- +kubeadm performs the actions necessary to get a minimum viable cluster up and running. By design, it cares only about bootstrapping, not about provisioning machines. Likewise, installing various nice-to-have addons, like the Kubernetes Dashboard, monitoring solutions, and cloud-specific addons, is not in scope. +--> kubeadm 通过执行必要的操作来启动和运行一个最小可用的集群。它被故意设计为只关心启动集群，而不是准备节点环境的工作。同样的，诸如安装各种各样的可有可无的插件，例如 Kubernetes 控制面板、监控解决方案以及特定云提供商的插件，这些都不在它负责的范围。 -<!-- Instead, we expect higher-level and more tailored tooling to be built on top of kubeadm, and ideally, using kubeadm as the basis of all deployments will make it easier to create conformant clusters. --> +<!-- +Instead, we expect higher-level and more tailored tooling to be built on top of kubeadm, and ideally, using kubeadm as the basis of all deployments will make it easier to create conformant clusters. +--> 相反，我们期望由一个基于 kubeadm 从更高层设计的更加合适的工具来做这些事情；并且，理想情况下，使用 kubeadm 作为所有部署的基础将会使得创建一个符合期望的集群变得容易。 +<!-- +## How to install + +To install kubeadm, see the [installation guide](/docs/setup/production-environment/tools/kubeadm/install-kubeadm). +--> +## 如何安装 +要安装 kubeadm，请参考[安装指南](/docs/setup/production-environment/tools/kubeadm/install-kubeadm)。 + ## 接下可以做什么 -<!-- * [kubeadm init](/docs/reference/setup-tools/kubeadm/kubeadm-init) to bootstrap a Kubernetes master node --> -* [kubeadm init](/docs/reference/setup-tools/kubeadm/kubeadm-init) 启动一个 Kubernetes 主节点 -<!-- * [kubeadm join](/docs/reference/setup-tools/kubeadm/kubeadm-join) to bootstrap a Kubernetes worker node and join it to the cluster --> -* [kubeadm join](/docs/reference/setup-tools/kubeadm/kubeadm-join) 启动一个 Kubernetes 工作节点并且将其加入到集群 -<!-- * [kubeadm upgrade](/docs/reference/setup-tools/kubeadm/kubeadm-upgrade) to upgrade a Kubernetes cluster to a newer version --> -* [kubeadm upgrade](/docs/reference/setup-tools/kubeadm/kubeadm-upgrade) 更新一个 Kubernetes 集群到新版本 -<!-- * [kubeadm config](/docs/reference/setup-tools/kubeadm/kubeadm-config) if you initialized your cluster using kubeadm v1.7.x or lower, to configure your cluster for `kubeadm upgrade` --> +<!-- +* [kubeadm init](/docs/reference/setup-tools/kubeadm/kubeadm-init) to bootstrap a Kubernetes master node +* [kubeadm join](/docs/reference/setup-tools/kubeadm/kubeadm-join) to bootstrap a Kubernetes worker node and join it to the cluster +* [kubeadm upgrade](/docs/reference/setup-tools/kubeadm/kubeadm-upgrade) to upgrade a Kubernetes cluster to a newer version +* [kubeadm config](/docs/reference/setup-tools/kubeadm/kubeadm-config) if you initialized your cluster using kubeadm v1.7.x or lower, to configure your cluster for `kubeadm upgrade` +* [kubeadm token](/docs/reference/setup-tools/kubeadm/kubeadm-token) to manage tokens for `kubeadm join` +* [kubeadm reset](/docs/reference/setup-tools/kubeadm/kubeadm-reset) to revert any changes made to this host by `kubeadm init` or `kubeadm join` +* [kubeadm version](/docs/reference/setup-tools/kubeadm/kubeadm-version) to print the kubeadm version +* [kubeadm alpha](/docs/reference/setup-tools/kubeadm/kubeadm-alpha) to preview a set of features made available for gathering feedback from the community +--> +* [kubeadm init](/docs/reference/setup-tools/kubeadm/kubeadm-init) 启动引导一个 Kubernetes 主节点 +* [kubeadm join](/docs/reference/setup-tools/kubeadm/kubeadm-join) 启动引导一个 Kubernetes 工作节点并且将其加入到集群 +* [kubeadm upgrade](/docs/reference/setup-tools/kubeadm/kubeadm-upgrade) 更新 Kubernetes 集群到新版本 * [kubeadm config](/docs/reference/setup-tools/kubeadm/kubeadm-config) 如果你使用 kubeadm v1.7.x 或者更低版本，你需要对你的集群做一些配置以便使用 `kubeadm upgrade` 命令 -<!-- * [kubeadm token](/docs/reference/setup-tools/kubeadm/kubeadm-token) to manage tokens for `kubeadm join` --> * [kubeadm token](/docs/reference/setup-tools/kubeadm/kubeadm-token) 使用 `kubeadm join` 来管理令牌 -<!-- * [kubeadm reset](/docs/reference/setup-tools/kubeadm/kubeadm-reset) to revert any changes made to this host by `kubeadm init` or `kubeadm join` --> -* [kubeadm reset](/docs/reference/setup-tools/kubeadm/kubeadm-reset) 还原之前使用 `kubeadm init` 或者 `kubeadm join` 对节点产生的改变 -<!-- * [kubeadm version](/docs/reference/setup-tools/kubeadm/kubeadm-version) to print the kubeadm version --> +* [kubeadm reset](/docs/reference/setup-tools/kubeadm/kubeadm-reset) 还原之前使用 `kubeadm init` 或者 `kubeadm join` 对节点所作改变 * [kubeadm version](/docs/reference/setup-tools/kubeadm/kubeadm-version) 打印出 kubeadm 版本 -<!-- * [kubeadm alpha](/docs/reference/setup-tools/kubeadm/kubeadm-alpha) to preview a set of features made available for gathering feedback from the community --> * [kubeadm alpha](/docs/reference/setup-tools/kubeadm/kubeadm-alpha) 预览一组可用的新功能以便从社区搜集反馈 + diff --git a/content/zh/docs/reference/tools.md b/content/zh/docs/reference/tools.md index fa41dcaf8c..caec8028c9 100644 --- a/content/zh/docs/reference/tools.md +++ b/content/zh/docs/reference/tools.md @@ -38,15 +38,6 @@ Kubernetes 包含一些内置工具，可以帮助用户更好的使用 Kubernet --> [`kubeadm`](/docs/tasks/tools/install-kubeadm/) 是一个命令行工具，可以用来在物理机、云服务器或虚拟机（目前处于 alpha 阶段）上轻松部署一个安全可靠的 Kubernetes 集群。 -## Kubefed - -<!-- -[`kubefed`](/docs/tasks/federation/set-up-cluster-federation-kubefed/) is the command line tool -to help you administrate your federated clusters. ---> -[`kubefed`](/docs/tasks/federation/set-up-cluster-federation-kubefed/) 是一个命令行工具，可以用来帮助用户管理联邦集群。 - - ## Minikube <!-- diff --git a/content/zh/docs/setup/_index.md b/content/zh/docs/setup/_index.md index 08ce8ca8de..81e8d38ef8 100644 --- a/content/zh/docs/setup/_index.md +++ b/content/zh/docs/setup/_index.md @@ -5,7 +5,7 @@ main_menu: true weight: 20 content_type: concept card: - name: 设置 + name: setup weight: 20 anchors: - anchor: "#learning-environment" @@ -15,7 +15,6 @@ card: --- <!-- ---- reviewers: - brendandburns - erictune @@ -33,7 +32,6 @@ card: title: Learning environment - anchor: "#production-environment" title: Production environment ---- --> <!-- overview --> diff --git a/content/zh/docs/setup/best-practices/certificates.md b/content/zh/docs/setup/best-practices/certificates.md index 40a9da84a1..67fe1c9942 100644 --- a/content/zh/docs/setup/best-practices/certificates.md +++ b/content/zh/docs/setup/best-practices/certificates.md @@ -55,7 +55,7 @@ Kubernetes 需要 PKI 才能执行以下操作： * API 服务器的客户端证书，用于和 etcd 的会话 * 控制器管理器的客户端证书/kubeconfig，用于和 API server 的会话 * 调度器的客户端证书/kubeconfig，用于和 API server 的会话 -* [前端代理][proxy] 的客户端及服务端证书 +* [前端代理](/zh/docs/tasks/extend-kubernetes/configure-aggregation-layer/) 的客户端及服务端证书 {{< note >}} <!-- @@ -280,6 +280,3 @@ These files are used as follows: [usage]: https://godoc.org/k8s.io/api/certificates/v1beta1#KeyUsage [kubeadm]: /docs/reference/setup-tools/kubeadm/kubeadm/ -[proxy]: /docs/tasks/access-kubernetes-api/configure-aggregation-layer/ - - diff --git a/content/zh/docs/setup/independent/create-cluster-kubeadm.md b/content/zh/docs/setup/independent/create-cluster-kubeadm.md index c00f723631..2f80c85c2d 100644 --- a/content/zh/docs/setup/independent/create-cluster-kubeadm.md +++ b/content/zh/docs/setup/independent/create-cluster-kubeadm.md @@ -388,7 +388,7 @@ support [Network Policy](/docs/concepts/services-networking/networkpolicies/). S - IPv6 support was added in [CNI v0.6.0](https://github.com/containernetworking/cni/releases/tag/v0.6.0). - [CNI bridge](https://github.com/containernetworking/plugins/blob/master/plugins/main/bridge/README.md) and [local-ipam](https://github.com/containernetworking/plugins/blob/master/plugins/ipam/host-local/README.md) are the only supported IPv6 network plugins in Kubernetes version 1.9. --> -**网络必须在部署任何应用之前部署好。此外，在网络安装之前是 CoreDNS 不会启用的。 +**网络必须在部署任何应用之前部署好。此外，在网络安装之前 CoreDNS 是不会启用的。 kubeadm 只支持基于容器网络接口（CNI）的网络而且不支持 kubenet 。** 有一些项目为 Kubernetes 提供使用 CNI 的 Pod 网络，其中一些也支持[网络策略](/docs/concepts/services-networking/networkpolicies/). diff --git a/content/zh/docs/setup/learning-environment/minikube.md b/content/zh/docs/setup/learning-environment/minikube.md index e8d19fe322..5696f59519 100644 --- a/content/zh/docs/setup/learning-environment/minikube.md +++ b/content/zh/docs/setup/learning-environment/minikube.md @@ -60,7 +60,7 @@ Minikube 支持以下 Kubernetes 功能： <!-- See [Installing Minikube](/docs/tasks/tools/install-minikube/). --> -请参阅[安装 Minikube](/docs/tasks/tools/install-minikube/)。 +请参阅[安装 Minikube](/zh/docs/tasks/tools/install-minikube/)。 <!-- ## Quickstart diff --git a/content/zh/docs/setup/production-environment/container-runtimes.md b/content/zh/docs/setup/production-environment/container-runtimes.md index fb3dde5428..2873951241 100644 --- a/content/zh/docs/setup/production-environment/container-runtimes.md +++ b/content/zh/docs/setup/production-environment/container-runtimes.md @@ -41,7 +41,7 @@ Please refer to this link for more information about this issue 我们发现 runc 在运行容器，处理系统文件描述符时存在一个漏洞。 恶意容器可以利用此漏洞覆盖 runc 二进制文件的内容，并以此在主机系统的容器上运行任意的命令。 -请参考此链接以获取有关此问题的更多信息 [cve-2019-5736 : runc vulnerability ] (https://access.redhat.com/security/cve/cve-2019-5736) +请参考此链接以获取有关此问题的更多信息 [cve-2019-5736 : runc vulnerability ](https://access.redhat.com/security/cve/cve-2019-5736) {{< /caution >}} <!-- @@ -134,7 +134,8 @@ Use the following commands to install Docker on your system: 使用以下命令在您的系统上安装 Docker： {{< tabs name="tab-cri-docker-installation" >}} -{{< tab name="Ubuntu 16.04+" codelang="bash" >}} +{{% tab name="Ubuntu 16.04+" %}} + <!-- # Install Docker CE ## Set up the repository: @@ -145,15 +146,19 @@ apt-get update && apt-get install \ ### Add Docker’s official GPG key curl -fsSL https://download.docker.com/linux/ubuntu/gpg | apt-key add - --> + +```shell # 安装 Docker CE ## 设置仓库 ### 安装软件包以允许 apt 通过 HTTPS 使用存储库 apt-get update && apt-get install \ apt-transport-https ca-certificates curl software-properties-common +``` +```shell ### 新增 Docker 的 官方 GPG 秘钥 curl -fsSL https://download.docker.com/linux/ubuntu/gpg | apt-key add - - +``` <!-- ### Add Docker apt repository. add-apt-repository \ @@ -181,15 +186,23 @@ EOF mkdir -p /etc/systemd/system/docker.service.d --> +```shell ### 添加 Docker apt 仓库 add-apt-repository \ "deb [arch=amd64] https://download.docker.com/linux/ubuntu \ $(lsb_release -cs) \ stable" +``` +```shell ## 安装 Docker CE -apt-get update && apt-get install docker-ce=18.06.2~ce~3-0~ubuntu +apt-get update && apt-get install -y\ + containerd.io=1.2.13-2 \ + docker-ce=5:19.03.11~3-0~ubuntu-$(lsb_release -cs) \ + docker-ce-cli=5:19.03.11~3-0~ubuntu-$(lsb_release -cs) +``` +```shell # 设置 daemon cat > /etc/docker/daemon.json <<EOF { @@ -201,19 +214,23 @@ cat > /etc/docker/daemon.json <<EOF "storage-driver": "overlay2" } EOF +``` +```shell mkdir -p /etc/systemd/system/docker.service.d - +``` <!-- # Restart docker. systemctl daemon-reload systemctl restart docker --> +```shell # 重启 docker. systemctl daemon-reload systemctl restart docker -{{< /tab >}} -{{< tab name="CentOS/RHEL 7.4+" codelang="bash" >}} +``` +{{% /tab %}} +{{% tab name="CentOS/RHEL 7.4+" %}} <!-- # Install Docker CE @@ -252,22 +269,31 @@ EOF mkdir -p /etc/systemd/system/docker.service.d --> +```shell # 安装 Docker CE ## 设置仓库 ### 安装所需包 yum install yum-utils device-mapper-persistent-data lvm2 +``` +```shell ### 新增 Docker 仓库。 yum-config-manager \ --add-repo \ https://download.docker.com/linux/centos/docker-ce.repo +``` +```shell ## 安装 Docker CE. yum update && yum install docker-ce-18.06.2.ce +``` +```shell ## 创建 /etc/docker 目录。 mkdir /etc/docker +``` +```shell # 设置 daemon。 cat > /etc/docker/daemon.json <<EOF { @@ -282,24 +308,43 @@ cat > /etc/docker/daemon.json <<EOF ] } EOF +``` +```shell mkdir -p /etc/systemd/system/docker.service.d - +``` <!-- # Restart Docker systemctl daemon-reload systemctl restart docker --> +```shell # 重启 Docker systemctl daemon-reload systemctl restart docker -{{< /tab >}} -{{< /tabs >}} +``` +{{% /tab %}} +{{% /tabs %}} + +<!-- +If you want the docker service to start on boot, run the following command: + +```shell +sudo systemctl enable docker +``` +--> + +如果你想开机即启动 docker 服务，执行以下命令： + +```shell +sudo systemctl enable docker +``` <!-- Refer to the [official Docker installation guides](https://docs.docker.com/engine/installation/) for more information. --> + 请参阅[官方 Docker 安装指南](https://docs.docker.com/engine/installation/) 来获取更多的信息。 @@ -349,7 +394,113 @@ sysctl --system ``` {{< tabs name="tab-cri-cri-o-installation" >}} -{{< tab name="Ubuntu 16.04" codelang="bash" >}} +{{% tab name="Debian" %}} + +<!-- +```shell +# Debian Unstable/Sid +echo 'deb http://download.opensuse.org/repositories/devel:/kubic:/libcontainers:/stable/Debian_Unstable/ /' > /etc/apt/sources.list.d/devel:kubic:libcontainers:stable.list +wget -nv https://download.opensuse.org/repositories/devel:kubic:libcontainers:stable/Debian_Unstable/Release.key -O- | sudo apt-key add - +``` +--> + +```shell +# Debian Unstable/Sid +echo 'deb http://download.opensuse.org/repositories/devel:/kubic:/libcontainers:/stable/Debian_Unstable/ /' > /etc/apt/sources.list.d/devel:kubic:libcontainers:stable.list +wget -nv https://download.opensuse.org/repositories/devel:kubic:libcontainers:stable/Debian_Unstable/Release.key -O- | sudo apt-key add - +``` + +<!-- +```shell +# Debian Testing +echo 'deb http://download.opensuse.org/repositories/devel:/kubic:/libcontainers:/stable/Debian_Testing/ /' > /etc/apt/sources.list.d/devel:kubic:libcontainers:stable.list +wget -nv https://download.opensuse.org/repositories/devel:kubic:libcontainers:stable/Debian_Testing/Release.key -O- | sudo apt-key add - +``` +--> + +```shell +# Debian Testing +echo 'deb http://download.opensuse.org/repositories/devel:/kubic:/libcontainers:/stable/Debian_Testing/ /' > /etc/apt/sources.list.d/devel:kubic:libcontainers:stable.list +wget -nv https://download.opensuse.org/repositories/devel:kubic:libcontainers:stable/Debian_Testing/Release.key -O- | sudo apt-key add - +``` + +<!-- +```shell +# Debian 10 +echo 'deb http://download.opensuse.org/repositories/devel:/kubic:/libcontainers:/stable/Debian_10/ /' > /etc/apt/sources.list.d/devel:kubic:libcontainers:stable.list +wget -nv https://download.opensuse.org/repositories/devel:kubic:libcontainers:stable/Debian_10/Release.key -O- | sudo apt-key add - +``` +--> + +```shell +# Debian 10 +echo 'deb http://download.opensuse.org/repositories/devel:/kubic:/libcontainers:/stable/Debian_10/ /' > /etc/apt/sources.list.d/devel:kubic:libcontainers:stable.list +wget -nv https://download.opensuse.org/repositories/devel:kubic:libcontainers:stable/Debian_10/Release.key -O- | sudo apt-key add - +``` + +<!-- +```shell +# Raspbian 10 +echo 'deb http://download.opensuse.org/repositories/devel:/kubic:/libcontainers:/stable/Raspbian_10/ /' > /etc/apt/sources.list.d/devel:kubic:libcontainers:stable.list +wget -nv https://download.opensuse.org/repositories/devel:kubic:libcontainers:stable/Raspbian_10/Release.key -O- | sudo apt-key add - +``` +--> + +```shell +# Raspbian 10 +echo 'deb http://download.opensuse.org/repositories/devel:/kubic:/libcontainers:/stable/Raspbian_10/ /' > /etc/apt/sources.list.d/devel:kubic:libcontainers:stable.list +wget -nv https://download.opensuse.org/repositories/devel:kubic:libcontainers:stable/Raspbian_10/Release.key -O- | sudo apt-key add - +``` + +<!-- +and then install CRI-O: +```shell +sudo apt-get install cri-o-1.17 +``` +--> + +随后安装 CRI-O: + +```shell +sudo apt-get install cri-o-1.17 +``` + +{{% /tab %}} + +{{% tab name="Ubuntu 18.04, 19.04 and 19.10" %}} + +<!-- +```shell +# Configure package repository +. /etc/os-release +sudo sh -c "echo 'deb http://download.opensuse.org/repositories/devel:/kubic:/libcontainers:/stable/x${NAME}_${VERSION_ID}/ /' > /etc/apt/sources.list.d/devel:kubic:libcontainers:stable.list" +wget -nv https://download.opensuse.org/repositories/devel:kubic:libcontainers:stable/x${NAME}_${VERSION_ID}/Release.key -O- | sudo apt-key add - +sudo apt-get update +``` +--> + +```shell +# 配置仓库 +. /etc/os-release +sudo sh -c "echo 'deb http://download.opensuse.org/repositories/devel:/kubic:/libcontainers:/stable/x${NAME}_${VERSION_ID}/ /' > /etc/apt/sources.list.d/devel:kubic:libcontainers:stable.list" +wget -nv https://download.opensuse.org/repositories/devel:kubic:libcontainers:stable/x${NAME}_${VERSION_ID}/Release.key -O- | sudo apt-key add - +sudo apt-get update +``` + +<!-- +```shell +# Install CRI-O +sudo apt-get install cri-o-1.17 +``` +--> + +```shell +# 安装 CRI-O +sudo apt-get install cri-o-1.17 +``` +{{% /tab %}} + +{{% tab name="Ubuntu 16.04" %}} <!-- # Install prerequisites @@ -362,6 +513,7 @@ apt-get update # Install CRI-O apt-get install cri-o-1.15 --> +```shell # 安装必备软件 apt-get update apt-get install software-properties-common @@ -371,9 +523,9 @@ apt-get update # 安装 CRI-O apt-get install cri-o-1.15 - -{{< /tab >}} -{{< tab name="CentOS/RHEL 7.4+" codelang="bash" >}} +``` +{{% /tab %}} +{{% tab name="CentOS/RHEL 7.4+" codelang="bash" %}} <!-- # Install prerequisites @@ -382,19 +534,33 @@ yum-config-manager --add-repo=https://cbs.centos.org/repos/paas7-crio-115-releas # Install CRI-O yum install --nogpgcheck cri-o --> + +```shell # 安装必备软件 yum-config-manager --add-repo=https://cbs.centos.org/repos/paas7-crio-115-release/x86_64/os/ +``` +```shell # 安装 CRI-O yum install --nogpgcheck cri-o +``` + +{{% /tab %}} + +{{% tab name="openSUSE Tumbleweed" %}} + +```shell +sudo zypper install cri-o +``` +{{% /tab %}} -{{< /tab >}} {{< /tabs >}} <!-- ### Start CRI-O ``` +systemctl daemon-reload systemctl start crio ``` @@ -407,7 +573,7 @@ for more information. systemctl start crio ``` -请参阅[CRI-O 安装指南](https://github.com/kubernetes-sigs/cri-o#getting-started) +请参阅 [CRI-O 安装指南](https://github.com/kubernetes-sigs/cri-o#getting-started) 来获取更多的信息。 <!-- @@ -471,103 +637,150 @@ sysctl --system ### 安装 containerd {{< tabs name="tab-cri-containerd-installation" >}} -{{< tab name="Ubuntu 16.04" codelang="bash" >}} +{{% tab name="Ubuntu 16.04" %}} <!-- +```shell # Install containerd ## Set up the repository ### Install packages to allow apt to use a repository over HTTPS apt-get update && apt-get install -y apt-transport-https ca-certificates curl software-properties-common +``` +```shell ### Add Docker’s official GPG key curl -fsSL https://download.docker.com/linux/ubuntu/gpg | apt-key add - +``` +```shell ### Add Docker apt repository. add-apt-repository \ "deb [arch=amd64] https://download.docker.com/linux/ubuntu \ $(lsb_release -cs) \ stable" +``` +```shell ## Install containerd apt-get update && apt-get install -y containerd.io +``` +```shell # Configure containerd mkdir -p /etc/containerd containerd config default > /etc/containerd/config.toml +``` --> + +```shell # 安装 containerd ## 设置仓库 ### 安装软件包以允许 apt 通过 HTTPS 使用存储库 apt-get update && apt-get install -y apt-transport-https ca-certificates curl software-properties-common +``` +```shell ### 安装 Docker 的官方 GPG 密钥 curl -fsSL https://download.docker.com/linux/ubuntu/gpg | apt-key add - +``` +```shell ### 新增 Docker apt 仓库。 add-apt-repository \ "deb [arch=amd64] https://download.docker.com/linux/ubuntu \ $(lsb_release -cs) \ stable" +``` +```shell ## 安装 containerd apt-get update && apt-get install -y containerd.io +``` +```shell # 配置 containerd mkdir -p /etc/containerd containerd config default > /etc/containerd/config.toml +``` <!-- +```shell # Restart containerd systemctl restart containerd +``` --> +```shell # 重启 containerd systemctl restart containerd +``` {{< /tab >}} -{{< tab name="CentOS/RHEL 7.4+" codelang="bash" >}} +{{% tab name="CentOS/RHEL 7.4+" %}} <!-- +```shell # Install containerd ## Set up the repository ### Install required packages yum install yum-utils device-mapper-persistent-data lvm2 +``` +```shell ### Add docker repository yum-config-manager \ --add-repo \ https://download.docker.com/linux/centos/docker-ce.repo +``` +```shell ## Install containerd yum update && yum install containerd.io +``` +```shell # Configure containerd mkdir -p /etc/containerd containerd config default > /etc/containerd/config.toml +``` --> + +```shell # 安装 containerd ## 设置仓库 ### 安装所需包 yum install yum-utils device-mapper-persistent-data lvm2 +``` +```shell ### 新增 Docker 仓库 yum-config-manager \ --add-repo \ https://download.docker.com/linux/centos/docker-ce.repo +``` +```shell ## 安装 containerd yum update && yum install containerd.io +``` +```shell # 配置 containerd mkdir -p /etc/containerd containerd config default > /etc/containerd/config.toml - +``` <!-- +```shell # Restart containerd systemctl restart containerd +``` --> + +```shell # 重启 containerd systemctl restart containerd -{{< /tab >}} +``` +{{% /tab %}} {{< /tabs >}} <!-- +```shell ### systemd To use the `systemd` cgroup driver, set `plugins.cri.systemd_cgroup = true` in `/etc/containerd/config.toml`. @@ -577,6 +790,7 @@ When using kubeadm, manually configure the ## Other CRI runtimes: frakti Refer to the [Frakti QuickStart guide](https://github.com/kubernetes/frakti#quickstart) for more information. +``` --> ### systemd @@ -587,5 +801,3 @@ Refer to the [Frakti QuickStart guide](https://github.com/kubernetes/frakti#quic ## 其他的 CRI 运行时：frakti 请参阅 [Frakti 快速开始指南](https://github.com/kubernetes/frakti#quickstart) 来获取更多的信息。 - - diff --git a/content/zh/docs/setup/production-environment/tools/kubeadm/kubelet-integration.md b/content/zh/docs/setup/production-environment/tools/kubeadm/kubelet-integration.md index e10bafa969..8416f5969f 100644 --- a/content/zh/docs/setup/production-environment/tools/kubeadm/kubelet-integration.md +++ b/content/zh/docs/setup/production-environment/tools/kubeadm/kubelet-integration.md @@ -373,9 +373,8 @@ Kubernetes 版本对应的 DEB 和 RPM 软件包是： | Package name | Description | |--------------|-------------| | `kubeadm` | 给 kubelet 安装 `/usr/bin/kubeadm` CLI 工具和 [kubelet 插件](#the-kubelet-drop-in-file-for-systemd)。 | -| `kubelet` | 安装 `/usr/bin/kubelet` 二进制文件。 | +| `kubelet` | 安装 `/usr/bin/kubelet` 二进制文件和 `/opt/cni/bin` CNI 二进制文件。 | | `kubectl` | 安装 `/usr/bin/kubectl` 二进制文件。 | -| `kubernetes-cni` | 将官方的 CNI 二进制文件安装到 `/opt/cni/bin` 目录中 | | `cri-tools` | 从 [cri-tools git 仓库](https://github.com/kubernetes-incubator/cri-tools)中安装 `/usr/bin/crictl` 二进制文件。 | diff --git a/content/zh/docs/setup/production-environment/tools/kubeadm/troubleshooting-kubeadm.md b/content/zh/docs/setup/production-environment/tools/kubeadm/troubleshooting-kubeadm.md index e00a71127c..43176afae3 100644 --- a/content/zh/docs/setup/production-environment/tools/kubeadm/troubleshooting-kubeadm.md +++ b/content/zh/docs/setup/production-environment/tools/kubeadm/troubleshooting-kubeadm.md @@ -486,7 +486,7 @@ CoreDNS 处于 `CrashLoopBackOff` 时的另一个原因是当 Kubernetes 中部 Disabling SELinux or setting `allowPrivilegeEscalation` to `true` can compromise the security of your cluster. --> -**警告**：禁用 SELinux 或设置 `allowPrivilegeEscalation` 为 `true` 可能会损害集群的安全性。 +禁用 SELinux 或设置 `allowPrivilegeEscalation` 为 `true` 可能会损害集群的安全性。 {{< /warning >}} <!-- diff --git a/content/zh/docs/setup/production-environment/turnkey/aws.md b/content/zh/docs/setup/production-environment/turnkey/aws.md index e67a0a4c99..64bff1dab9 100644 --- a/content/zh/docs/setup/production-environment/turnkey/aws.md +++ b/content/zh/docs/setup/production-environment/turnkey/aws.md @@ -48,14 +48,9 @@ To create a Kubernetes cluster on AWS, you will need an Access Key ID and a Secr * [Kubernetes Operations](https://github.com/kubernetes/kops) - 生产级 K8s 的安装、升级和管理。支持在 AWS 运行 Debian、Ubuntu、CentOS 和 RHEL。 <!-- -* [CoreOS Tectonic](https://coreos.com/tectonic/) includes the open-source [Tectonic Installer](https://github.com/coreos/tectonic-installer) that creates Kubernetes clusters with Container Linux nodes on AWS. +* [kube-aws](https://github.com/kubernetes-incubator/kube-aws), creates and manages Kubernetes clusters with [Flatcar Linux](https://www.flatcar-linux.org/) nodes, using AWS tools: EC2, CloudFormation and Autoscaling. --> -* [CoreOS Tectonic](https://coreos.com/tectonic/) 包括开源的 [Tectonic 安装程序](https://github.com/coreos/tectonic-installer)，它用于在 AWS 上创建带有 Container Linux 节点的 Kubernetes 集群。 - -<!-- -* CoreOS originated and the Kubernetes Incubator maintains [a CLI tool, kube-aws](https://github.com/kubernetes-incubator/kube-aws), that creates and manages Kubernetes clusters with [Container Linux](https://coreos.com/why/) nodes, using AWS tools: EC2, CloudFormation and Autoscaling. ---> -* 起源于 CoreOS，Kubernetes Incubator 维护的 [CLI 工具， kube-aws ](https://github.com/kubernetes-incubator/kube-aws)，该工具使用 [Container Linux](https://coreos.com/why/) 节点创建和管理 Kubernetes 集群，它使用了 AWS 工具：EC2、CloudFormation 和 Autoscaling。 +* [kube-aws](https://github.com/kubernetes-incubator/kube-aws) 使用 [Flatcar Linux](https://www.flatcar-linux.org/) 节点创建和管理 Kubernetes 集群，它使用了 AWS 工具：EC2、CloudFormation 和 Autoscaling。 <!-- * [KubeOne](https://github.com/kubermatic/kubeone) is an open source cluster lifecycle management tool that creates, upgrades and manages Kubernetes Highly-Available clusters. diff --git a/content/zh/docs/setup/production-environment/turnkey/clc.md b/content/zh/docs/setup/production-environment/turnkey/clc.md new file mode 100644 index 0000000000..6be7d06157 --- /dev/null +++ b/content/zh/docs/setup/production-environment/turnkey/clc.md @@ -0,0 +1,532 @@ +--- +title: 在 CenturyLink Cloud 上运行 Kubernetes +--- +<!-- +--- +title: Running Kubernetes on CenturyLink Cloud +--- +---> + + +<!-- +These scripts handle the creation, deletion and expansion of Kubernetes clusters on CenturyLink Cloud. + +You can accomplish all these tasks with a single command. We have made the Ansible playbooks used to perform these tasks available [here](https://github.com/CenturyLinkCloud/adm-kubernetes-on-clc/blob/master/ansible/README.md). +---> +这些脚本适用于在 CenturyLink Cloud 上创建、删除和扩展 Kubernetes 集群。 + +您可以使用单个命令完成所有任务。我们提供了用于执行这些任务的 Ansible 手册 [点击这里](https://github.com/CenturyLinkCloud/adm-kubernetes-on-clc/blob/master/ansible/README.md) + +<!-- +## Find Help + +If you run into any problems or want help with anything, we are here to help. Reach out to use via any of the following ways: + +- Submit a github issue +- Send an email to Kubernetes AT ctl DOT io +- Visit [http://info.ctl.io/kubernetes](http://info.ctl.io/kubernetes) +---> +## 寻求帮助 + +如果运行出现问题或者想要寻求帮助，我们非常乐意帮忙。通过以下方式获取帮助： + +- 提交 github issue +- 给 Kubernetes AT ctl DOT io 发送邮件 +- 访问 [http://info.ctl.io/kubernetes](http://info.ctl.io/kubernetes) + +<!-- +## Clusters of VMs or Physical Servers, your choice. + +- We support Kubernetes clusters on both Virtual Machines or Physical Servers. If you want to use physical servers for the worker nodes (minions), simple use the --minion_type=bareMetal flag. +- For more information on physical servers, visit: [https://www.ctl.io/bare-metal/](https://www.ctl.io/bare-metal/) +- Physical serves are only available in the VA1 and GB3 data centers. +- VMs are available in all 13 of our public cloud locations +---> +## 基于 VM 或物理服务器的集群可供选择 + +- 我们在虚拟机或物理服务器上都支持 Kubernetes 集群。如果要将物理服务器用于辅助 Node（minions），则只需使用 --minion_type=bareMetal 标志。 +- 有关物理服务器的更多信息，请访问： [https://www.ctl.io/bare-metal/](https://www.ctl.io/bare-metal/) +- 仅在 VA1 和 GB3 数据中心提供物理服务。 +- 13个公共云位置都可以使用虚拟机。 + +<!-- +## Requirements + +The requirements to run this script are: + +- A linux administrative host (tested on ubuntu and macOS) +- python 2 (tested on 2.7.11) + - pip (installed with python as of 2.7.9) +- git +- A CenturyLink Cloud account with rights to create new hosts +- An active VPN connection to the CenturyLink Cloud from your linux host +---> +## 要求 + +运行此脚本的要求有： + +- Linux 管理主机（在 ubuntu 和 macOS 上测试） +- python 2（在 2.7.11 版本上测试） + - pip（从 2.7.9 版开始与 python 一起安装） +- git +- 具有新建主机权限的 CenturyLink Cloud 帐户 +- 从 Linux 主机到 CenturyLink Cloud 的有效 VPN 连接 + +<!-- +## Script Installation + +After you have all the requirements met, please follow these instructions to install this script. + +1) Clone this repository and cd into it. +---> +## 脚本安装 + +满足所有要求后，请按照以下说明安装此脚本。 + +1）克隆此存储库并通过 cd 进入。 + +```shell +git clone https://github.com/CenturyLinkCloud/adm-kubernetes-on-clc +``` + +<!-- +2) Install all requirements, including +---> +2）安装所有要求的部分，包括 + + * Ansible + * CenturyLink Cloud SDK + * Ansible Modules + +```shell +sudo pip install -r ansible/requirements.txt +``` + +<!-- +3) Create the credentials file from the template and use it to set your ENV variables +---> +3）从模板创建凭证文件，并使用它来设置您的 ENV 变量 + +```shell +cp ansible/credentials.sh.template ansible/credentials.sh +vi ansible/credentials.sh +source ansible/credentials.sh + +``` + +<!-- +4) Grant your machine access to the CenturyLink Cloud network by using a VM inside the network or [ configuring a VPN connection to the CenturyLink Cloud network.](https://www.ctl.io/knowledge-base/network/how-to-configure-client-vpn/) +---> +4）使用内网的虚拟机或 [ 配置与 CenturyLink Cloud 网络的 VPN 连接.](https://www.ctl.io/knowledge-base/network/how-to-configure-client-vpn/) 授予您的计算机对 CenturyLink Cloud 网络的访问权限。 + +<!-- +#### Script Installation Example: Ubuntu 14 Walkthrough + +If you use an ubuntu 14, for your convenience we have provided a step by step guide to install the requirements and install the script. +---> +#### 脚本安装示例：Ubuntu 14 演练 + +如果您使用 Ubuntu 14，为方便起见，我们会提供分步指导帮助安装必备条件和脚本。 + +```shell +# system +apt-get update +apt-get install -y git python python-crypto +curl -O https://bootstrap.pypa.io/get-pip.py +python get-pip.py + +# installing this repository +mkdir -p ~home/k8s-on-clc +cd ~home/k8s-on-clc +git clone https://github.com/CenturyLinkCloud/adm-kubernetes-on-clc.git +cd adm-kubernetes-on-clc/ +pip install -r requirements.txt + +# getting started +cd ansible +cp credentials.sh.template credentials.sh; vi credentials.sh +source credentials.sh +``` + + + +<!-- +## Cluster Creation + +To create a new Kubernetes cluster, simply run the ```kube-up.sh``` script. A complete +list of script options and some examples are listed below. +---> +## 创建集群 + +要创建一个新的 Kubernetes 集群，只需运行 ```kube-up.sh``` 脚本即可。以下是一套完整的脚本选项列表和一些示例。 + +```shell +CLC_CLUSTER_NAME=[name of kubernetes cluster] +cd ./adm-kubernetes-on-clc +bash kube-up.sh -c="$CLC_CLUSTER_NAME" +``` + +<!-- +It takes about 15 minutes to create the cluster. Once the script completes, it +will output some commands that will help you setup kubectl on your machine to +point to the new cluster. + +When the cluster creation is complete, the configuration files for it are stored +locally on your administrative host, in the following directory +---> +创建集群大约需要15分钟。脚本完成后，它将输出一些命令，这些命令将帮助您在计算机上设置 kubectl 以指向新集群。 + +完成集群创建后，其配置文件会存储在本地管理主机的以下目录中 + +```shell +> CLC_CLUSTER_HOME=$HOME/.clc_kube/$CLC_CLUSTER_NAME/ +``` + + +<!-- +#### Cluster Creation: Script Options +---> +#### 创建集群：脚本选项 + +```shell +Usage: kube-up.sh [OPTIONS] +Create servers in the CenturyLinkCloud environment and initialize a Kubernetes cluster +Environment variables CLC_V2_API_USERNAME and CLC_V2_API_PASSWD must be set in +order to access the CenturyLinkCloud API + +All options (both short and long form) require arguments, and must include "=" +between option name and option value. + + -h (--help) display this help and exit + -c= (--clc_cluster_name=) set the name of the cluster, as used in CLC group names + -t= (--minion_type=) standard -> VM (default), bareMetal -> physical] + -d= (--datacenter=) VA1 (default) + -m= (--minion_count=) number of kubernetes minion nodes + -mem= (--vm_memory=) number of GB ram for each minion + -cpu= (--vm_cpu=) number of virtual cps for each minion node + -phyid= (--server_conf_id=) physical server configuration id, one of + physical_server_20_core_conf_id + physical_server_12_core_conf_id + physical_server_4_core_conf_id (default) + -etcd_separate_cluster=yes create a separate cluster of three etcd nodes, + otherwise run etcd on the master node +``` + +<!-- +## Cluster Expansion + +To expand an existing Kubernetes cluster, run the ```add-kube-node.sh``` +script. A complete list of script options and some examples are listed [below](#cluster-expansion-script-options). +This script must be run from the same host that created the cluster (or a host +that has the cluster artifact files stored in ```~/.clc_kube/$cluster_name```). +---> +## 扩展集群 + +要扩展现有的Kubernetes集群，请运行```add-kube-node.sh``` 脚本。脚本选项的完整列表和一些示例在 [下面](#cluster-expansion-script-options) 列出。该脚本必须运行在创建集群的同一个主机（或储存集群工件文件的 ```~/.clc_kube/$cluster_name``` 主机）。 + +```shell +cd ./adm-kubernetes-on-clc +bash add-kube-node.sh -c="name_of_kubernetes_cluster" -m=2 +``` + +<!-- +#### Cluster Expansion: Script Options +---> +#### 扩展集群：脚本选项 + +```shell +Usage: add-kube-node.sh [OPTIONS] +Create servers in the CenturyLinkCloud environment and add to an +existing CLC kubernetes cluster + +Environment variables CLC_V2_API_USERNAME and CLC_V2_API_PASSWD must be set in +order to access the CenturyLinkCloud API + + -h (--help) display this help and exit + -c= (--clc_cluster_name=) set the name of the cluster, as used in CLC group names + -m= (--minion_count=) number of kubernetes minion nodes to add +``` + +<!-- +## Cluster Deletion + +There are two ways to delete an existing cluster: + +1) Use our python script: +---> +## 删除集群 + +有两种方法可以删除集群： + +1）使用 Python 脚本： + +```shell +python delete_cluster.py --cluster=clc_cluster_name --datacenter=DC1 +``` + +<!-- +2) Use the CenturyLink Cloud UI. To delete a cluster, log into the CenturyLink +Cloud control portal and delete the parent server group that contains the +Kubernetes Cluster. We hope to add a scripted option to do this soon. +---> +2）使用 CenturyLink Cloud UI。要删除集群，请登录 CenturyLink Cloud 控制页面并删除包含 Kubernetes 集群的父服务器组。我们希望能够添加脚本选项以尽快完成此操作。 + +<!-- +## Examples + +Create a cluster with name of k8s_1, 1 master node and 3 worker minions (on physical machines), in VA1 +---> +## 示例 + +在 VA1 中创建一个集群，名称为 k8s_1，具备1个主 Node 和3个辅助 Minion（在物理机上） + +```shell +bash kube-up.sh --clc_cluster_name=k8s_1 --minion_type=bareMetal --minion_count=3 --datacenter=VA1 +``` + +<!-- +Create a cluster with name of k8s_2, an ha etcd cluster on 3 VMs and 6 worker minions (on VMs), in VA1 +---> +在 VA1 中创建一个 ha etcd 集群，名称为 k8s_2，运行在3个虚拟机和6个辅助 Minion（在虚拟机上） + +```shell +bash kube-up.sh --clc_cluster_name=k8s_2 --minion_type=standard --minion_count=6 --datacenter=VA1 --etcd_separate_cluster=yes +``` + +<!-- +Create a cluster with name of k8s_3, 1 master node, and 10 worker minions (on VMs) with higher mem/cpu, in UC1: +---> +在 UC1 中创建一个集群，名称为k8s_3，具备1个主 Node 和10个具有更高 mem/cpu 的辅助 Minion（在虚拟机上）： + +```shell +bash kube-up.sh --clc_cluster_name=k8s_3 --minion_type=standard --minion_count=10 --datacenter=VA1 -mem=6 -cpu=4 +``` + + + +<!-- +## Cluster Features and Architecture + +We configure the Kubernetes cluster with the following features: + +* KubeDNS: DNS resolution and service discovery +* Heapster/InfluxDB: For metric collection. Needed for Grafana and auto-scaling. +* Grafana: Kubernetes/Docker metric dashboard +* KubeUI: Simple web interface to view Kubernetes state +* Kube Dashboard: New web interface to interact with your cluster +---> +## 集群功能和架构 + +我们使用以下功能配置 Kubernetes 集群： + +* KubeDNS：DNS 解析和服务发现 +* Heapster / InfluxDB：用于指标收集，是 Grafana 和 auto-scaling 需要的。 +* Grafana：Kubernetes/Docker 指标仪表板 +* KubeUI：用于查看 Kubernetes 状态的简单 Web 界面 +* Kube 仪表板：新的 Web 界面可与您的集群进行交互 + +<!-- +We use the following to create the Kubernetes cluster: +---> +使用以下工具创建 Kubernetes 集群： + +* Kubernetes 1.1.7 +* Ubuntu 14.04 +* Flannel 0.5.4 +* Docker 1.9.1-0~trusty +* Etcd 2.2.2 + +<!-- +## Optional add-ons + +* Logging: We offer an integrated centralized logging ELK platform so that all + Kubernetes and docker logs get sent to the ELK stack. To install the ELK stack + and configure Kubernetes to send logs to it, follow [the log + aggregation documentation](https://github.com/CenturyLinkCloud/adm-kubernetes-on-clc/blob/master/log_aggregration.md). Note: We don't install this by default as + the footprint isn't trivial. +---> +## 可选附件 +* 日志记录：我们提供了一个集成的集中式日志记录 ELK 平台，以便将所有 Kubernetes 和 docker 日志发送到 ELK 堆栈。要安装 ELK 堆栈并配置 Kubernetes 向其发送日志，请遵循 [日志聚合文档](https://github.com/CenturyLinkCloud/adm-kubernetes-on-clc/blob/master/log_aggregration.md)。注意：默认情况下我们不安装此程序，因为占用空间并不小。 + +<!-- +## Cluster management + +The most widely used tool for managing a Kubernetes cluster is the command-line +utility ```kubectl```. If you do not already have a copy of this binary on your +administrative machine, you may run the script ```install_kubectl.sh``` which will +download it and install it in ```/usr/bin/local```. +---> +## 管理集群 + +管理 Kubernetes 集群最常用工具是 command-line 实用程序 ```kubectl```。如果您的管理器上还没有此二进制文件的副本，可以运行脚本 ```install_kubectl.sh```，它将下载该脚本并将其安装在 ```/usr/bin/local``` 中。 + +<!-- +The script requires that the environment variable ```CLC_CLUSTER_NAME``` be defined. ```install_kubectl.sh``` also writes a configuration file which will embed the necessary +authentication certificates for the particular cluster. The configuration file is +written to the ```${CLC_CLUSTER_HOME}/kube``` directory +---> +该脚本要求定义环境变量 ```CLC_CLUSTER_NAME```。```install_kubectl.sh``` 还将写入一个配置文件，该文件为特定集群嵌入必要的认证证书。配置文件被写入 ```${CLC_CLUSTER_HOME}/kube``` 目录中 + + +```shell +export KUBECONFIG=${CLC_CLUSTER_HOME}/kube/config +kubectl version +kubectl cluster-info +``` + +<!-- +### Accessing the cluster programmatically + +It's possible to use the locally stored client certificates to access the apiserver. For example, you may want to use any of the [Kubernetes API client libraries](/docs/reference/using-api/client-libraries/) to program against your Kubernetes cluster in the programming language of your choice. + +To demonstrate how to use these locally stored certificates, we provide the following example of using ```curl``` to communicate to the master apiserver via https: +---> +### 以编程方式访问集群 + +可以使用本地存储的客户端证书来访问 apiserver。例如，您可以使用 [Kubernetes API 客户端库](/docs/reference/using-api/client-libraries/) 选择编程语言对 Kubernetes 集群进行编程。 + +为了演示如何使用这些本地存储的证书，我们提供以下示例，使用 ```curl``` 通过 https 与主 apiserver 进行通信： + +```shell +curl \ + --cacert ${CLC_CLUSTER_HOME}/pki/ca.crt \ + --key ${CLC_CLUSTER_HOME}/pki/kubecfg.key \ + --cert ${CLC_CLUSTER_HOME}/pki/kubecfg.crt https://${MASTER_IP}:6443 +``` + +<!-- +But please note, this *does not* work out of the box with the ```curl``` binary +distributed with macOS. +---> +但是请注意，这 *不能* 与 MacOS 一起发行的 ```curl``` 二进制文件分开使用。 + +<!-- +### Accessing the cluster with a browser + +We install [the kubernetes dashboard](/docs/tasks/web-ui-dashboard/). When you +create a cluster, the script should output URLs for these interfaces like this: + +kubernetes-dashboard is running at ```https://${MASTER_IP}:6443/api/v1/namespaces/kube-system/services/kubernetes-dashboard/proxy```. +---> +### 使用浏览器访问集群 + +安装 [Kubernetes 仪表板](/docs/tasks/web-ui-dashboard/)。创建集群时，脚本会为这些接口输出 URL，如下所示： + +kubernetes-dashboard 在以下位置运行 ```https://${MASTER_IP}:6443/api/v1/namespaces/kube-system/services/kubernetes-dashboard/proxy``` + +<!-- +Note on Authentication to the UIs: + +The cluster is set up to use basic authentication for the user _admin_. +Hitting the url at ```https://${MASTER_IP}:6443``` will +require accepting the self-signed certificate +from the apiserver, and then presenting the admin +password written to file at: ```> _${CLC_CLUSTER_HOME}/kube/admin_password.txt_``` +---> +对 UI 进行身份验证的注意事项： + +群集设置为对用户 _admin_ 使用基本的身份验证。进入 URL ```https://${MASTER_IP}:6443``` 获取从 apiserver 上接收的自签名证书，然后出示管理员密码并写入文件 ```> _${CLC_CLUSTER_HOME}/kube/admin_password.txt_``` + + +<!-- +### Configuration files + +Various configuration files are written into the home directory *CLC_CLUSTER_HOME* under ```.clc_kube/${CLC_CLUSTER_NAME}``` in several subdirectories. You can use these files +to access the cluster from machines other than where you created the cluster from. +---> +### 配置文件 + +多个配置文件被写入几个子目录，子目录在 ```.clc_kube/${CLC_CLUSTER_NAME}``` 下的主目录 *CLC_CLUSTER_HOME* 中。使用这些文件可以从创建群集的计算机之外的其他计算机访问群集。 + +<!-- +* ```config/```: Ansible variable files containing parameters describing the master and minion hosts +* ```hosts/```: hosts files listing access information for the Ansible playbooks +* ```kube/```: ```kubectl``` configuration files, and the basic-authentication password for admin access to the Kubernetes API +* ```pki/```: public key infrastructure files enabling TLS communication in the cluster +* ```ssh/```: SSH keys for root access to the hosts +---> +* ```config/```：Ansible 变量文件，包含描述主机和从机的参数 +* ```hosts/```: 主机文件，列出了 Ansible 手册的访问信息 +* ```kube/```: ```kubectl``` 配置文件，包含管理员访问 Kubernetes API 所需的基本身份验证密码 +* ```pki/```: 公钥基础结构文件，用于在集群中启用 TLS 通信 +* ```ssh/```: 对主机进行根访问的 SSH 密钥 + + +<!-- +## ```kubectl``` usage examples + +There are a great many features of _kubectl_. Here are a few examples + +List existing nodes, pods, services and more, in all namespaces, or in just one: +---> +## ```kubectl``` 使用示例 + +_kubectl_ 有很多功能，例如 + +列出所有或者一个命名空间中存在的 Node，Pod，服务等。 + +```shell +kubectl get nodes +kubectl get --all-namespaces pods +kubectl get --all-namespaces services +kubectl get --namespace=kube-system replicationcontrollers +``` + +<!-- +The Kubernetes API server exposes services on web URLs, which are protected by requiring +client certificates. If you run a kubectl proxy locally, ```kubectl``` will provide +the necessary certificates and serve locally over http. +---> +Kubernetes API 服务器在 Web URL 上公开服务，这些 URL 受客户端证书的保护。如果您在本地运行 kubectl 代理，```kubectl``` 将提供必要的证书，并通过 http 在本地提供服务。 + +```shell +kubectl proxy -p 8001 +``` + +<!-- +Then, you can access urls like ```http://127.0.0.1:8001/api/v1/namespaces/kube-system/services/kubernetes-dashboard/proxy/``` without the need for client certificates in your browser. +---> +然后，您可以访问 ```http://127.0.0.1:8001/api/v1/namespaces/kube-system/services/kubernetes-dashboard/proxy/``` 之类的 URL，不再需要浏览器中的客户端证书 。 + + +<!-- +## What Kubernetes features do not work on CenturyLink Cloud + +These are the known items that don't work on CenturyLink cloud but do work on other cloud providers: + +- At this time, there is no support services of the type [LoadBalancer](/docs/tasks/access-application-cluster/create-external-load-balancer/). We are actively working on this and hope to publish the changes sometime around April 2016. + +- At this time, there is no support for persistent storage volumes provided by + CenturyLink Cloud. However, customers can bring their own persistent storage + offering. We ourselves use Gluster. +---> +## Kubernetes 的哪些功能无法在 CenturyLink Cloud 上使用 + +这些是已知的在 CenturyLink Cloud 上不能使用，但在其他云提供商中可以使用： + +- 目前，没有 [LoadBalancer](/docs/tasks/access-application-cluster/create-external-load-balancer/)类型的支持服务。我们正在为此积极努力，并希望在2016年4月左右发布更改。 + +- 目前，不支持 CenturyLink Cloud 提供的永久存储卷。但是，客户可以自带永久性存储产品。我们自己使用 Gluster。 + + +<!-- +## Ansible Files + +If you want more information about our Ansible files, please [read this file](https://github.com/CenturyLinkCloud/adm-kubernetes-on-clc/blob/master/ansible/README.md) +---> +## Ansible 文件 + +如果您想了解有关 Ansible 文件的更多信息，请 [浏览此文件](https://github.com/CenturyLinkCloud/adm-kubernetes-on-clc/blob/master/ansible/README.md) + +<!-- +## Further reading + +Please see the [Kubernetes docs](/docs/) for more details on administering +and using a Kubernetes cluster. +---> +## 更多 + +有关管理和使用 Kubernetes 集群的更多详细信息，请参见 [Kubernetes 文档](/docs/) + + + diff --git a/content/zh/docs/setup/release/notes.md b/content/zh/docs/setup/release/notes.md new file mode 100644 index 0000000000..804e0c3670 --- /dev/null +++ b/content/zh/docs/setup/release/notes.md @@ -0,0 +1,1372 @@ +--- +title: v1.18 发布说明 +weight: 10 +card: + name: release-notes + weight: 20 + anchors: + - anchor: "#" + title: 当前发行说明 + - anchor: "#urgent-upgrade-notes" + title: 紧急升级说明 +--- + +<!-- NEW RELEASE NOTES ENTRY --> + +# v1.18.0 + +[Documentation](https://docs.k8s.io) + +## Downloads for v1.18.0 + +filename | sha512 hash +-------- | ----------- +[kubernetes.tar.gz](https://dl.k8s.io/v1.18.0/kubernetes.tar.gz) | `cd5b86a3947a4f2cea6d857743ab2009be127d782b6f2eb4d37d88918a5e433ad2c7ba34221c34089ba5ba13701f58b657f0711401e51c86f4007cb78744dee7` +[kubernetes-src.tar.gz](https://dl.k8s.io/v1.18.0/kubernetes-src.tar.gz) | `fb42cf133355ef18f67c8c4bb555aa1f284906c06e21fa41646e086d34ece774e9d547773f201799c0c703ce48d4d0e62c6ba5b2a4d081e12a339a423e111e52` + +### Client Binaries + +filename | sha512 hash +-------- | ----------- +[kubernetes-client-darwin-386.tar.gz](https://dl.k8s.io/v1.18.0/kubernetes-client-darwin-386.tar.gz) | `26df342ef65745df12fa52931358e7f744111b6fe1e0bddb8c3c6598faf73af997c00c8f9c509efcd7cd7e82a0341a718c08fbd96044bfb58e80d997a6ebd3c2` +[kubernetes-client-darwin-amd64.tar.gz](https://dl.k8s.io/v1.18.0/kubernetes-client-darwin-amd64.tar.gz) | `803a0fed122ef6b85f7a120b5485723eaade765b7bc8306d0c0da03bd3df15d800699d15ea2270bb7797fa9ce6a81da90e730dc793ea4ed8c0149b63d26eca30` +[kubernetes-client-linux-386.tar.gz](https://dl.k8s.io/v1.18.0/kubernetes-client-linux-386.tar.gz) | `110844511b70f9f3ebb92c15105e6680a05a562cd83f79ce2d2e25c2dd70f0dbd91cae34433f61364ae1ce4bd573b635f2f632d52de8f72b54acdbc95a15e3f0` +[kubernetes-client-linux-amd64.tar.gz](https://dl.k8s.io/v1.18.0/kubernetes-client-linux-amd64.tar.gz) | `594ca3eadc7974ec4d9e4168453e36ca434812167ef8359086cd64d048df525b7bd46424e7cc9c41e65c72bda3117326ba1662d1c9d739567f10f5684fd85bee` +[kubernetes-client-linux-arm.tar.gz](https://dl.k8s.io/v1.18.0/kubernetes-client-linux-arm.tar.gz) | `d3627b763606557a6c9a5766c34198ec00b3a3cd72a55bc2cb47731060d31c4af93543fb53f53791062bb5ace2f15cbaa8592ac29009641e41bd656b0983a079` +[kubernetes-client-linux-arm64.tar.gz](https://dl.k8s.io/v1.18.0/kubernetes-client-linux-arm64.tar.gz) | `ba9056eff1452cbdaef699efbf88f74f5309b3f7808d372ebf6918442d0c9fea1653c00b9db3b7626399a460eef9b1fa9e29b827b7784f34561cbc380554e2ea` +[kubernetes-client-linux-ppc64le.tar.gz](https://dl.k8s.io/v1.18.0/kubernetes-client-linux-ppc64le.tar.gz) | `f80fb3769358cb20820ff1a1ce9994de5ed194aabe6c73fb8b8048bffc394d1b926de82c204f0e565d53ffe7562faa87778e97a3ccaaaf770034a992015e3a86` +[kubernetes-client-linux-s390x.tar.gz](https://dl.k8s.io/v1.18.0/kubernetes-client-linux-s390x.tar.gz) | `a9b658108b6803d60fa3cd4e76d9e58bf75201017164fe54054b7ccadbb68c4ad7ba7800746940bc518d90475e6c0a96965a26fa50882f4f0e56df404f4ae586` +[kubernetes-client-windows-386.tar.gz](https://dl.k8s.io/v1.18.0/kubernetes-client-windows-386.tar.gz) | `18adffab5d1be146906fd8531f4eae7153576aac235150ce2da05aee5ae161f6bd527e8dec34ae6131396cd4b3771e0d54ce770c065244ad3175a1afa63c89e1` +[kubernetes-client-windows-amd64.tar.gz](https://dl.k8s.io/v1.18.0/kubernetes-client-windows-amd64.tar.gz) | `162396256429cef07154f817de2a6b67635c770311f414e38b1e2db25961443f05d7b8eb1f8da46dec8e31c5d1d2cd45f0c95dad1bc0e12a0a7278a62a0b9a6b` + +### Server Binaries + +filename | sha512 hash +-------- | ----------- +[kubernetes-server-linux-amd64.tar.gz](https://dl.k8s.io/v1.18.0/kubernetes-server-linux-amd64.tar.gz) | `a92f8d201973d5dfa44a398e95fcf6a7b4feeb1ef879ab3fee1c54370e21f59f725f27a9c09ace8c42c96ac202e297fd458e486c489e05f127a5cade53b8d7c4` +[kubernetes-server-linux-arm.tar.gz](https://dl.k8s.io/v1.18.0/kubernetes-server-linux-arm.tar.gz) | `62fbff3256bc0a83f70244b09149a8d7870d19c2c4b6dee8ca2714fc7388da340876a0f540d2ae9bbd8b81fdedaf4b692c72d2840674db632ba2431d1df1a37d` +[kubernetes-server-linux-arm64.tar.gz](https://dl.k8s.io/v1.18.0/kubernetes-server-linux-arm64.tar.gz) | `842910a7013f61a60d670079716b207705750d55a9e4f1f93696d19d39e191644488170ac94d8740f8e3aa3f7f28f61a4347f69d7e93d149c69ac0efcf3688fe` +[kubernetes-server-linux-ppc64le.tar.gz](https://dl.k8s.io/v1.18.0/kubernetes-server-linux-ppc64le.tar.gz) | `95c5b952ac1c4127a5c3b519b664972ee1fb5e8e902551ce71c04e26ad44b39da727909e025614ac1158c258dc60f504b9a354c5ab7583c2ad769717b30b3836` +[kubernetes-server-linux-s390x.tar.gz](https://dl.k8s.io/v1.18.0/kubernetes-server-linux-s390x.tar.gz) | `a46522d2119a0fd58074564c1fa95dd8a929a79006b82ba3c4245611da8d2db9fd785c482e1b61a9aa361c5c9a6d73387b0e15e6a7a3d84fffb3f65db3b9deeb` + +### Node Binaries + +filename | sha512 hash +-------- | ----------- +[kubernetes-node-linux-amd64.tar.gz](https://dl.k8s.io/v1.18.0/kubernetes-node-linux-amd64.tar.gz) | `f714f80feecb0756410f27efb4cf4a1b5232be0444fbecec9f25cb85a7ccccdcb5be588cddee935294f460046c0726b90f7acc52b20eeb0c46a7200cf10e351a` +[kubernetes-node-linux-arm.tar.gz](https://dl.k8s.io/v1.18.0/kubernetes-node-linux-arm.tar.gz) | `806000b5f6d723e24e2f12d19d1b9b3d16c74b855f51c7063284adf1fcc57a96554a3384f8c05a952c6f6b929a05ed12b69151b1e620c958f74c9600f3db0fcb` +[kubernetes-node-linux-arm64.tar.gz](https://dl.k8s.io/v1.18.0/kubernetes-node-linux-arm64.tar.gz) | `c207e9ab60587d135897b5366af79efe9d2833f33401e469b2a4e0d74ecd2cf6bb7d1e5bc18d80737acbe37555707f63dd581ccc6304091c1d98dafdd30130b7` +[kubernetes-node-linux-ppc64le.tar.gz](https://dl.k8s.io/v1.18.0/kubernetes-node-linux-ppc64le.tar.gz) | `a542ed5ed02722af44ef12d1602f363fcd4e93cf704da2ea5d99446382485679626835a40ae2ba47a4a26dce87089516faa54479a1cfdee2229e8e35aa1c17d7` +[kubernetes-node-linux-s390x.tar.gz](https://dl.k8s.io/v1.18.0/kubernetes-node-linux-s390x.tar.gz) | `651e0db73ee67869b2ae93cb0574168e4bd7918290fc5662a6b12b708fa628282e3f64be2b816690f5a2d0f4ff8078570f8187e65dee499a876580a7a63d1d19` +[kubernetes-node-windows-amd64.tar.gz](https://dl.k8s.io/v1.18.0/kubernetes-node-windows-amd64.tar.gz) | `d726ed904f9f7fe7e8831df621dc9094b87e767410a129aa675ee08417b662ddec314e165f29ecb777110fbfec0dc2893962b6c71950897ba72baaa7eb6371ed` + +## Changelog since v1.17.0 + +A complete changelog for the release notes is now hosted in a customizable +format at [https://relnotes.k8s.io][1]. Check it out and please give us your +feedback! + +[1]: https://relnotes.k8s.io/?releaseVersions=1.18.0 + +## What’s New (Major Themes) + +### Kubernetes Topology Manager Moves to Beta - Align Up! + +A beta feature of Kubernetes in release 1.18, the [Topology Manager feature](https://github.com/nolancon/website/blob/f4200307260ea3234540ef13ed80de325e1a7267/content/en/docs/tasks/administer-cluster/topology-manager.md) enables NUMA alignment of CPU and devices (such as SR-IOV VFs) that will allow your workload to run in an environment optimized for low-latency. Prior to the introduction of the Topology Manager, the CPU and Device Manager would make resource allocation decisions independent of each other. This could result in undesirable allocations on multi-socket systems, causing degraded performance on latency critical applications. + +### Serverside Apply - Beta 2 + +Server-side Apply was promoted to Beta in 1.16, but is now introducing a second Beta in 1.18. This new version will track and manage changes to fields of all new Kubernetes objects, allowing you to know what changed your resources and when. + +### Extending Ingress with and replacing a deprecated annotation with IngressClass + +In Kubernetes 1.18, there are two significant additions to Ingress: A new `pathType` field and a new `IngressClass` resource. The `pathType` field allows specifying how paths should be matched. In addition to the default `ImplementationSpecific` type, there are new `Exact` and `Prefix` path types. + +The `IngressClass` resource is used to describe a type of Ingress within a Kubernetes cluster. Ingresses can specify the class they are associated with by using a new `ingressClassName` field on Ingresses. This new resource and field replace the deprecated `kubernetes.io/ingress.class` annotation. + +### SIG CLI introduces kubectl debug + +SIG CLI was debating the need for a debug utility for quite some time already. With the development of [ephemeral containers](https://kubernetes.io/docs/concepts/workloads/pods/ephemeral-containers/), it became more obvious how we can support developers with tooling built on top of `kubectl exec`. The addition of the `kubectl debug` [command](https://github.com/kubernetes/enhancements/blob/master/keps/sig-cli/20190805-kubectl-debug.md) (it is alpha but your feedback is more than welcome), allows developers to easily debug their Pods inside the cluster. We think this addition is invaluable. This command allows one to create a temporary container which runs next to the Pod one is trying to examine, but also attaches to the console for interactive troubleshooting. + +### Introducing Windows CSI support alpha for Kubernetes + +With the release of Kubernetes 1.18, an alpha version of CSI Proxy for Windows is getting released. CSI proxy enables non-privileged (pre-approved) containers to perform privileged storage operations on Windows. CSI drivers can now be supported in Windows by leveraging CSI proxy. +SIG Storage made a lot of progress in the 1.18 release. +In particular, the following storage features are moving to GA in Kubernetes 1.18: +- Raw Block Support: Allow volumes to be surfaced as block devices inside containers instead of just mounted filesystems. +- Volume Cloning: Duplicate a PersistentVolumeClaim and underlying storage volume using the Kubernetes API via CSI. +- CSIDriver Kubernetes API Object: Simplifies CSI driver discovery and allows CSI Drivers to customize Kubernetes behavior. + +SIG Storage is also introducing the following new storage features as alpha in Kubernetes 1.18: +- Windows CSI Support: Enabling containerized CSI node plugins in Windows via new [CSIProxy](https://github.com/kubernetes-csi/csi-proxy) +- Recursive Volume Ownership OnRootMismatch Option: Add a new “OnRootMismatch” policy that can help shorten the mount time for volumes that require ownership change and have many directories and files. + +### Other notable announcements + +SIG Network is moving IPv6 to Beta in Kubernetes 1.18, after incrementing significantly the test coverage with new CI jobs. + +NodeLocal DNSCache is an add-on that runs a dnsCache pod as a daemonset to improve clusterDNS performance and reliability. The feature has been in Alpha since 1.13 release. The SIG Network is announcing the GA graduation of Node Local DNSCache [#1351](https://github.com/kubernetes/enhancements/pull/1351) + +## Known Issues + +No Known Issues Reported + +## Urgent Upgrade Notes + +### (No, really, you MUST read this before you upgrade) + +#### kube-apiserver: +- in an `--encryption-provider-config` config file, an explicit `cacheSize: 0` parameter previously silently defaulted to caching 1000 keys. In Kubernetes 1.18, this now returns a config validation error. To disable caching, you can specify a negative cacheSize value in Kubernetes 1.18+. +- consumers of the 'certificatesigningrequests/approval' API must now have permission to 'approve' CSRs for the specific signer requested by the CSR. More information on the new signerName field and the required authorization can be found at https://kubernetes.io/docs/reference/access-authn-authz/certificate-signing-requests#authorization ([#88246](https://github.com/kubernetes/kubernetes/pull/88246), [@munnerz](https://github.com/munnerz)) [SIG API Machinery, Apps, Auth, CLI, Node and Testing] +- The following features are unconditionally enabled and the corresponding `--feature-gates` flags have been removed: `PodPriority`, `TaintNodesByCondition`, `ResourceQuotaScopeSelectors` and `ScheduleDaemonSetPods` ([#86210](https://github.com/kubernetes/kubernetes/pull/86210), [@draveness](https://github.com/draveness)) [SIG Apps and Scheduling] + +#### kubelet: +- `--enable-cadvisor-endpoints` is now disabled by default. If you need access to the cAdvisor v1 Json API please enable it explicitly in the kubelet command line. Please note that this flag was deprecated in 1.15 and will be removed in 1.19. ([#87440](https://github.com/kubernetes/kubernetes/pull/87440), [@dims](https://github.com/dims)) [SIG Instrumentation, Node and Testing] +- Promote CSIMigrationOpenStack to Beta (off by default since it requires installation of the OpenStack Cinder CSI Driver. The in-tree AWS OpenStack Cinder driver "kubernetes.io/cinder" was deprecated in 1.16 and will be removed in 1.20. Users should enable CSIMigration + CSIMigrationOpenStack features and install the OpenStack Cinder CSI Driver (https://github.com/kubernetes-sigs/cloud-provider-openstack) to avoid disruption to existing Pod and PVC objects at that time. Users should start using the OpenStack Cinder CSI Driver directly for any new volumes. ([#85637](https://github.com/kubernetes/kubernetes/pull/85637), [@dims](https://github.com/dims)) [SIG Cloud Provider] + +#### kubectl: +- `kubectl` and k8s.io/client-go no longer default to a server address of `http://localhost:8080`. If you own one of these legacy clusters, you are *strongly* encouraged to secure your server. If you cannot secure your server, you can set the `$KUBERNETES_MASTER` environment variable to `http://localhost:8080` to continue defaulting the server address. `kubectl` users can also set the server address using the `--server` flag, or in a kubeconfig file specified via `--kubeconfig` or `$KUBECONFIG`. ([#86173](https://github.com/kubernetes/kubernetes/pull/86173), [@soltysh](https://github.com/soltysh)) [SIG API Machinery, CLI and Testing] +- `kubectl run` has removed the previously deprecated generators, along with flags unrelated to creating pods. `kubectl run` now only creates pods. See specific `kubectl create` subcommands to create objects other than pods. +([#87077](https://github.com/kubernetes/kubernetes/pull/87077), [@soltysh](https://github.com/soltysh)) [SIG Architecture, CLI and Testing] +- The deprecated command `kubectl rolling-update` has been removed ([#88057](https://github.com/kubernetes/kubernetes/pull/88057), [@julianvmodesto](https://github.com/julianvmodesto)) [SIG Architecture, CLI and Testing] + +#### client-go: +- Signatures on methods in generated clientsets, dynamic, metadata, and scale clients have been modified to accept `context.Context` as a first argument. Signatures of Create, Update, and Patch methods have been updated to accept CreateOptions, UpdateOptions and PatchOptions respectively. Signatures of Delete and DeleteCollection methods now accept DeleteOptions by value instead of by reference. Generated clientsets with the previous interface have been added in new "deprecated" packages to allow incremental migration to the new APIs. The deprecated packages will be removed in the 1.21 release. A tool is available at http://sigs.k8s.io/clientgofix to rewrite method invocations to the new signatures. + +- The following deprecated metrics are removed, please convert to the corresponding metrics: + - The following replacement metrics are available from v1.14.0: + - `rest_client_request_latency_seconds` -> `rest_client_request_duration_seconds` + - `scheduler_scheduling_latency_seconds` -> `scheduler_scheduling_duration_seconds ` + - `docker_operations` -> `docker_operations_total` + - `docker_operations_latency_microseconds` -> `docker_operations_duration_seconds` + - `docker_operations_errors` -> `docker_operations_errors_total` + - `docker_operations_timeout` -> `docker_operations_timeout_total` + - `network_plugin_operations_latency_microseconds` -> `network_plugin_operations_duration_seconds` + - `kubelet_pod_worker_latency_microseconds` -> `kubelet_pod_worker_duration_seconds` + - `kubelet_pod_start_latency_microseconds` -> `kubelet_pod_start_duration_seconds` + - `kubelet_cgroup_manager_latency_microseconds` -> `kubelet_cgroup_manager_duration_seconds` + - `kubelet_pod_worker_start_latency_microseconds` -> `kubelet_pod_worker_start_duration_seconds` + - `kubelet_pleg_relist_latency_microseconds` -> `kubelet_pleg_relist_duration_seconds` + - `kubelet_pleg_relist_interval_microseconds` -> `kubelet_pleg_relist_interval_seconds` + - `kubelet_eviction_stats_age_microseconds` -> `kubelet_eviction_stats_age_seconds` + - `kubelet_runtime_operations` -> `kubelet_runtime_operations_total` + - `kubelet_runtime_operations_latency_microseconds` -> `kubelet_runtime_operations_duration_seconds` + - `kubelet_runtime_operations_errors` -> `kubelet_runtime_operations_errors_total` + - `kubelet_device_plugin_registration_count` -> `kubelet_device_plugin_registration_total` + - `kubelet_device_plugin_alloc_latency_microseconds` -> `kubelet_device_plugin_alloc_duration_seconds` + - `scheduler_e2e_scheduling_latency_microseconds` -> `scheduler_e2e_scheduling_duration_seconds` + - `scheduler_scheduling_algorithm_latency_microseconds` -> `scheduler_scheduling_algorithm_duration_seconds` + - `scheduler_scheduling_algorithm_predicate_evaluation` -> `scheduler_scheduling_algorithm_predicate_evaluation_seconds` + - `scheduler_scheduling_algorithm_priority_evaluation` -> `scheduler_scheduling_algorithm_priority_evaluation_seconds` + - `scheduler_scheduling_algorithm_preemption_evaluation` -> `scheduler_scheduling_algorithm_preemption_evaluation_seconds` + - `scheduler_binding_latency_microseconds` -> `scheduler_binding_duration_seconds` + - `kubeproxy_sync_proxy_rules_latency_microseconds` -> `kubeproxy_sync_proxy_rules_duration_seconds` + - `apiserver_request_latencies` -> `apiserver_request_duration_seconds` + - `apiserver_dropped_requests` -> `apiserver_dropped_requests_total` + - `etcd_request_latencies_summary` -> `etcd_request_duration_seconds` + - `apiserver_storage_transformation_latencies_microseconds ` -> `apiserver_storage_transformation_duration_seconds` + - `apiserver_storage_data_key_generation_latencies_microseconds` -> `apiserver_storage_data_key_generation_duration_seconds` + - `apiserver_request_count` -> `apiserver_request_total` + - `apiserver_request_latencies_summary` + - The following replacement metrics are available from v1.15.0: + - `apiserver_storage_transformation_failures_total` -> `apiserver_storage_transformation_operations_total` ([#76496](https://github.com/kubernetes/kubernetes/pull/76496), [@danielqsj](https://github.com/danielqsj)) [SIG API Machinery, Cluster Lifecycle, Instrumentation, Network, Node and Scheduling] + +## Changes by Kind + +### Deprecation + +#### kube-apiserver: +- the following deprecated APIs can no longer be served: + - All resources under `apps/v1beta1` and `apps/v1beta2` - use `apps/v1` instead + - `daemonsets`, `deployments`, `replicasets` resources under `extensions/v1beta1` - use `apps/v1` instead + - `networkpolicies` resources under `extensions/v1beta1` - use `networking.k8s.io/v1` instead + - `podsecuritypolicies` resources under `extensions/v1beta1` - use `policy/v1beta1` instead ([#85903](https://github.com/kubernetes/kubernetes/pull/85903), [@liggitt](https://github.com/liggitt)) [SIG API Machinery, Apps, Cluster Lifecycle, Instrumentation and Testing] + +#### kube-controller-manager: +- Azure service annotation service.beta.kubernetes.io/azure-load-balancer-disable-tcp-reset has been deprecated. Its support would be removed in a future release. ([#88462](https://github.com/kubernetes/kubernetes/pull/88462), [@feiskyer](https://github.com/feiskyer)) [SIG Cloud Provider] + +#### kubelet: +- The StreamingProxyRedirects feature and `--redirect-container-streaming` flag are deprecated, and will be removed in a future release. The default behavior (proxy streaming requests through the kubelet) will be the only supported option. If you are setting `--redirect-container-streaming=true`, then you must migrate off this configuration. The flag will no longer be able to be enabled starting in v1.20. If you are not setting the flag, no action is necessary. ([#88290](https://github.com/kubernetes/kubernetes/pull/88290), [@tallclair](https://github.com/tallclair)) [SIG API Machinery and Node] +- resource metrics endpoint `/metrics/resource/v1alpha1` as well as all metrics under this endpoint have been deprecated. Please convert to the following metrics emitted by endpoint `/metrics/resource`: + - scrape_error --> scrape_error + - node_cpu_usage_seconds_total --> node_cpu_usage_seconds + - node_memory_working_set_bytes --> node_memory_working_set_bytes + - container_cpu_usage_seconds_total --> container_cpu_usage_seconds + - container_memory_working_set_bytes --> container_memory_working_set_bytes + - scrape_error --> scrape_error + ([#86282](https://github.com/kubernetes/kubernetes/pull/86282), [@RainbowMango](https://github.com/RainbowMango)) [SIG Node] +- In a future release, kubelet will no longer create the CSI NodePublishVolume target directory, in accordance with the CSI specification. CSI drivers may need to be updated accordingly to properly create and process the target path. ([#75535](https://github.com/kubernetes/kubernetes/issues/75535)) [SIG Storage] + +#### kube-proxy: +- `--healthz-port` and `--metrics-port` flags are deprecated, please use `--healthz-bind-address` and `--metrics-bind-address` instead ([#88512](https://github.com/kubernetes/kubernetes/pull/88512), [@SataQiu](https://github.com/SataQiu)) [SIG Network] +- a new `EndpointSliceProxying` feature gate has been added to control the use of EndpointSlices in kube-proxy. The EndpointSlice feature gate that used to control this behavior no longer affects kube-proxy. This feature has been disabled by default. ([#86137](https://github.com/kubernetes/kubernetes/pull/86137), [@robscott](https://github.com/robscott)) + +#### kubeadm: +- command line option "kubelet-version" for `kubeadm upgrade node` has been deprecated and will be removed in a future release. ([#87942](https://github.com/kubernetes/kubernetes/pull/87942), [@SataQiu](https://github.com/SataQiu)) [SIG Cluster Lifecycle] +- deprecate the usage of the experimental flag '--use-api' under the 'kubeadm alpha certs renew' command. ([#88827](https://github.com/kubernetes/kubernetes/pull/88827), [@neolit123](https://github.com/neolit123)) [SIG Cluster Lifecycle] +- kube-dns is deprecated and will not be supported in a future version ([#86574](https://github.com/kubernetes/kubernetes/pull/86574), [@SataQiu](https://github.com/SataQiu)) [SIG Cluster Lifecycle] +- the `ClusterStatus` struct present in the kubeadm-config ConfigMap is deprecated and will be removed in a future version. It is going to be maintained by kubeadm until it gets removed. The same information can be found on `etcd` and `kube-apiserver` pod annotations, `kubeadm.kubernetes.io/etcd.advertise-client-urls` and `kubeadm.kubernetes.io/kube-apiserver.advertise-address.endpoint` respectively. ([#87656](https://github.com/kubernetes/kubernetes/pull/87656), [@ereslibre](https://github.com/ereslibre)) [SIG Cluster Lifecycle] + +#### kubectl: +- the boolean and unset values for the --dry-run flag are deprecated and a value --dry-run=server|client|none will be required in a future version. ([#87580](https://github.com/kubernetes/kubernetes/pull/87580), [@julianvmodesto](https://github.com/julianvmodesto)) [SIG CLI] +- `kubectl apply --server-dry-run` is deprecated and replaced with --dry-run=server ([#87580](https://github.com/kubernetes/kubernetes/pull/87580), [@julianvmodesto](https://github.com/julianvmodesto)) [SIG CLI] + +#### add-ons: +- Remove cluster-monitoring addon ([#85512](https://github.com/kubernetes/kubernetes/pull/85512), [@serathius](https://github.com/serathius)) [SIG Cluster Lifecycle, Instrumentation, Scalability and Testing] + +#### kube-scheduler: +- The `scheduling_duration_seconds` summary metric is deprecated ([#86586](https://github.com/kubernetes/kubernetes/pull/86586), [@xiaoanyunfei](https://github.com/xiaoanyunfei)) [SIG Scheduling] +- The `scheduling_algorithm_predicate_evaluation_seconds` and + `scheduling_algorithm_priority_evaluation_seconds` metrics are deprecated, replaced by `framework_extension_point_duration_seconds[extension_point="Filter"]` and `framework_extension_point_duration_seconds[extension_point="Score"]`. ([#86584](https://github.com/kubernetes/kubernetes/pull/86584), [@xiaoanyunfei](https://github.com/xiaoanyunfei)) [SIG Scheduling] +- `AlwaysCheckAllPredicates` is deprecated in scheduler Policy API. ([#86369](https://github.com/kubernetes/kubernetes/pull/86369), [@Huang-Wei](https://github.com/Huang-Wei)) [SIG Scheduling] + +#### Other deprecations: +- The k8s.io/node-api component is no longer updated. Instead, use the RuntimeClass types located within k8s.io/api, and the generated clients located within k8s.io/client-go ([#87503](https://github.com/kubernetes/kubernetes/pull/87503), [@liggitt](https://github.com/liggitt)) [SIG Node and Release] +- Removed the 'client' label from apiserver_request_total. ([#87669](https://github.com/kubernetes/kubernetes/pull/87669), [@logicalhan](https://github.com/logicalhan)) [SIG API Machinery and Instrumentation] + +### API Change + +#### New API types/versions: +- A new IngressClass resource has been added to enable better Ingress configuration. ([#88509](https://github.com/kubernetes/kubernetes/pull/88509), [@robscott](https://github.com/robscott)) [SIG API Machinery, Apps, CLI, Network, Node and Testing] +- The CSIDriver API has graduated to storage.k8s.io/v1, and is now available for use. ([#84814](https://github.com/kubernetes/kubernetes/pull/84814), [@huffmanca](https://github.com/huffmanca)) [SIG Storage] + +#### New API fields: +- autoscaling/v2beta2 HorizontalPodAutoscaler added a `spec.behavior` field that allows scale behavior to be configured. Behaviors are specified separately for scaling up and down. In each direction a stabilization window can be specified as well as a list of policies and how to select amongst them. Policies can limit the absolute number of pods added or removed, or the percentage of pods added or removed. ([#74525](https://github.com/kubernetes/kubernetes/pull/74525), [@gliush](https://github.com/gliush)) [SIG API Machinery, Apps, Autoscaling and CLI] +- Ingress: + - `spec.ingressClassName` replaces the deprecated `kubernetes.io/ingress.class` annotation, and allows associating an Ingress object with a particular controller. + - path definitions added a `pathType` field to allow indicating how the specified path should be matched against incoming requests. Valid values are `Exact`, `Prefix`, and `ImplementationSpecific` ([#88587](https://github.com/kubernetes/kubernetes/pull/88587), [@cmluciano](https://github.com/cmluciano)) [SIG Apps, Cluster Lifecycle and Network] +- The alpha feature `AnyVolumeDataSource` enables PersistentVolumeClaim objects to use the spec.dataSource field to reference a custom type as a data source ([#88636](https://github.com/kubernetes/kubernetes/pull/88636), [@bswartz](https://github.com/bswartz)) [SIG Apps and Storage] +- The alpha feature `ConfigurableFSGroupPolicy` enables v1 Pods to specify a spec.securityContext.fsGroupChangePolicy policy to control how file permissions are applied to volumes mounted into the pod. ([#88488](https://github.com/kubernetes/kubernetes/pull/88488), [@gnufied](https://github.com/gnufied)) [SIG Storage] +- The alpha feature `ServiceAppProtocol` enables setting an `appProtocol` field in ServicePort and EndpointPort definitions. ([#88503](https://github.com/kubernetes/kubernetes/pull/88503), [@robscott](https://github.com/robscott)) [SIG Apps and Network] +- The alpha feature `ImmutableEphemeralVolumes` enables an `immutable` field in both Secret and ConfigMap objects to mark their contents as immutable. ([#86377](https://github.com/kubernetes/kubernetes/pull/86377), [@wojtek-t](https://github.com/wojtek-t)) [SIG Apps, CLI and Testing] + +#### Other API changes: +- The beta feature `ServerSideApply` enables tracking and managing changed fields for all new objects, which means there will be `managedFields` in `metadata` with the list of managers and their owned fields. +- The alpha feature `ServiceAccountIssuerDiscovery` enables publishing OIDC discovery information and service account token verification keys at `/.well-known/openid-configuration` and `/openid/v1/jwks` endpoints by API servers configured to issue service account tokens. ([#80724](https://github.com/kubernetes/kubernetes/pull/80724), [@cceckman](https://github.com/cceckman)) [SIG API Machinery, Auth, Cluster Lifecycle and Testing] +- CustomResourceDefinition schemas that use `x-kubernetes-list-map-keys` to specify properties that uniquely identify list items must make those properties required or have a default value, to ensure those properties are present for all list items. See https://kubernetes.io/docs/reference/using-api/api-concepts/#merge-strategy for details. ([#88076](https://github.com/kubernetes/kubernetes/pull/88076), [@eloyekunle](https://github.com/eloyekunle)) [SIG API Machinery and Testing] +- CustomResourceDefinition schemas that use `x-kubernetes-list-type: map` or `x-kubernetes-list-type: set` now enable validation that the list items in the corresponding custom resources are unique. ([#84920](https://github.com/kubernetes/kubernetes/pull/84920), [@sttts](https://github.com/sttts)) [SIG API Machinery] + +#### Configuration file changes: + +#### kube-apiserver: +- The `--egress-selector-config-file` configuration file now accepts an apiserver.k8s.io/v1beta1 EgressSelectorConfiguration configuration object, and has been updated to allow specifying HTTP or GRPC connections to the network proxy ([#87179](https://github.com/kubernetes/kubernetes/pull/87179), [@Jefftree](https://github.com/Jefftree)) [SIG API Machinery, Cloud Provider and Cluster Lifecycle] + +#### kube-scheduler: +- A kubescheduler.config.k8s.io/v1alpha2 configuration file version is now accepted, with support for multiple scheduling profiles ([#87628](https://github.com/kubernetes/kubernetes/pull/87628), [@alculquicondor](https://github.com/alculquicondor)) [SIG Scheduling] + - HardPodAffinityWeight moved from a top level ComponentConfig parameter to a PluginConfig parameter of InterPodAffinity Plugin in `kubescheduler.config.k8s.io/v1alpha2` ([#88002](https://github.com/kubernetes/kubernetes/pull/88002), [@alculquicondor](https://github.com/alculquicondor)) [SIG Scheduling and Testing] + - Kube-scheduler can run more than one scheduling profile. Given a pod, the profile is selected by using its `.spec.schedulerName`. ([#88285](https://github.com/kubernetes/kubernetes/pull/88285), [@alculquicondor](https://github.com/alculquicondor)) [SIG Apps, Scheduling and Testing] + - Scheduler Extenders can now be configured in the v1alpha2 component config ([#88768](https://github.com/kubernetes/kubernetes/pull/88768), [@damemi](https://github.com/damemi)) [SIG Release, Scheduling and Testing] + - The PostFilter of scheduler framework is renamed to PreScore in kubescheduler.config.k8s.io/v1alpha2. ([#87751](https://github.com/kubernetes/kubernetes/pull/87751), [@skilxn-go](https://github.com/skilxn-go)) [SIG Scheduling and Testing] + +#### kube-proxy: +- Added kube-proxy flags `--ipvs-tcp-timeout`, `--ipvs-tcpfin-timeout`, `--ipvs-udp-timeout` to configure IPVS connection timeouts. ([#85517](https://github.com/kubernetes/kubernetes/pull/85517), [@andrewsykim](https://github.com/andrewsykim)) [SIG Cluster Lifecycle and Network] +- Added optional `--detect-local-mode` flag to kube-proxy. Valid values are "ClusterCIDR" (default matching previous behavior) and "NodeCIDR" ([#87748](https://github.com/kubernetes/kubernetes/pull/87748), [@satyasm](https://github.com/satyasm)) [SIG Cluster Lifecycle, Network and Scheduling] +- Kube-controller-manager and kube-scheduler expose profiling by default to match the kube-apiserver. Use `--enable-profiling=false` to disable. ([#88663](https://github.com/kubernetes/kubernetes/pull/88663), [@deads2k](https://github.com/deads2k)) [SIG API Machinery, Cloud Provider and Scheduling] +- Kubelet pod resources API now provides the information about active pods only. ([#79409](https://github.com/kubernetes/kubernetes/pull/79409), [@takmatsu](https://github.com/takmatsu)) [SIG Node] +- New flag `--endpointslice-updates-batch-period` in kube-controller-manager can be used to reduce the number of endpointslice updates generated by pod changes. ([#88745](https://github.com/kubernetes/kubernetes/pull/88745), [@mborsz](https://github.com/mborsz)) [SIG API Machinery, Apps and Network] +- New flag `--show-hidden-metrics-for-version` in kube-proxy, kubelet, kube-controller-manager, and kube-scheduler can be used to show all hidden metrics that are deprecated in the previous minor release. ([#85279](https://github.com/kubernetes/kubernetes/pull/85279), [@RainbowMango](https://github.com/RainbowMango)) [SIG Cluster Lifecycle and Network] + +#### Features graduated to beta: + - StartupProbe ([#83437](https://github.com/kubernetes/kubernetes/pull/83437), [@matthyx](https://github.com/matthyx)) [SIG Node, Scalability and Testing] + +#### Features graduated to GA: + - VolumePVCDataSource ([#88686](https://github.com/kubernetes/kubernetes/pull/88686), [@j-griffith](https://github.com/j-griffith)) [SIG Storage] + - TaintBasedEvictions ([#87487](https://github.com/kubernetes/kubernetes/pull/87487), [@skilxn-go](https://github.com/skilxn-go)) [SIG API Machinery, Apps, Node, Scheduling and Testing] + - BlockVolume and CSIBlockVolume ([#88673](https://github.com/kubernetes/kubernetes/pull/88673), [@jsafrane](https://github.com/jsafrane)) [SIG Storage] + - Windows RunAsUserName ([#87790](https://github.com/kubernetes/kubernetes/pull/87790), [@marosset](https://github.com/marosset)) [SIG Apps and Windows] +- The following feature gates are removed, because the associated features were unconditionally enabled in previous releases: CustomResourceValidation, CustomResourceSubresources, CustomResourceWebhookConversion, CustomResourcePublishOpenAPI, CustomResourceDefaulting ([#87475](https://github.com/kubernetes/kubernetes/pull/87475), [@liggitt](https://github.com/liggitt)) [SIG API Machinery] + +### Feature + +- API request throttling (due to a high rate of requests) is now reported in client-go logs at log level 2. The messages are of the form:`Throttling request took 1.50705208s, request: GET:<URL>` The presence of these messages may indicate to the administrator the need to tune the cluster accordingly. ([#87740](https://github.com/kubernetes/kubernetes/pull/87740), [@jennybuckley](https://github.com/jennybuckley)) [SIG API Machinery] +- Add support for mount options to the FC volume plugin ([#87499](https://github.com/kubernetes/kubernetes/pull/87499), [@ejweber](https://github.com/ejweber)) [SIG Storage] +- Added a config-mode flag in azure auth module to enable getting AAD token without spn: prefix in audience claim. When it's not specified, the default behavior doesn't change. ([#87630](https://github.com/kubernetes/kubernetes/pull/87630), [@weinong](https://github.com/weinong)) [SIG API Machinery, Auth, CLI and Cloud Provider] +- Allow for configuration of CoreDNS replica count ([#85837](https://github.com/kubernetes/kubernetes/pull/85837), [@pickledrick](https://github.com/pickledrick)) [SIG Cluster Lifecycle] +- Allow user to specify resource using --filename flag when invoking kubectl exec ([#88460](https://github.com/kubernetes/kubernetes/pull/88460), [@soltysh](https://github.com/soltysh)) [SIG CLI and Testing] +- Apiserver added a new flag --goaway-chance which is the fraction of requests that will be closed gracefully(GOAWAY) to prevent HTTP/2 clients from getting stuck on a single apiserver. ([#88567](https://github.com/kubernetes/kubernetes/pull/88567), [@answer1991](https://github.com/answer1991)) [SIG API Machinery] +- Azure Cloud Provider now supports using Azure network resources (Virtual Network, Load Balancer, Public IP, Route Table, Network Security Group, etc.) in different AAD Tenant and Subscription than those for the Kubernetes cluster. To use the feature, please reference https://github.com/kubernetes-sigs/cloud-provider-azure/blob/master/docs/cloud-provider-config.md#host-network-resources-in-different-aad-tenant-and-subscription. ([#88384](https://github.com/kubernetes/kubernetes/pull/88384), [@bowen5](https://github.com/bowen5)) [SIG Cloud Provider] +- Azure VMSS/VMSSVM clients now suppress requests on throttling ([#86740](https://github.com/kubernetes/kubernetes/pull/86740), [@feiskyer](https://github.com/feiskyer)) [SIG Cloud Provider] +- Azure cloud provider cache TTL is configurable, list of the azure cloud provider is as following: + - "availabilitySetNodesCacheTTLInSeconds" + - "vmssCacheTTLInSeconds" + - "vmssVirtualMachinesCacheTTLInSeconds" + - "vmCacheTTLInSeconds" + - "loadBalancerCacheTTLInSeconds" + - "nsgCacheTTLInSeconds" + - "routeTableCacheTTLInSeconds" + ([#86266](https://github.com/kubernetes/kubernetes/pull/86266), [@zqingqing1](https://github.com/zqingqing1)) [SIG Cloud Provider] +- Azure global rate limit is switched to per-client. A set of new rate limit configure options are introduced, including routeRateLimit, SubnetsRateLimit, InterfaceRateLimit, RouteTableRateLimit, LoadBalancerRateLimit, PublicIPAddressRateLimit, SecurityGroupRateLimit, VirtualMachineRateLimit, StorageAccountRateLimit, DiskRateLimit, SnapshotRateLimit, VirtualMachineScaleSetRateLimit and VirtualMachineSizeRateLimit. The original rate limit options would be default values for those new client's rate limiter. ([#86515](https://github.com/kubernetes/kubernetes/pull/86515), [@feiskyer](https://github.com/feiskyer)) [SIG Cloud Provider] +- Azure network and VM clients now suppress requests on throttling ([#87122](https://github.com/kubernetes/kubernetes/pull/87122), [@feiskyer](https://github.com/feiskyer)) [SIG Cloud Provider] +- Azure storage clients now suppress requests on throttling ([#87306](https://github.com/kubernetes/kubernetes/pull/87306), [@feiskyer](https://github.com/feiskyer)) [SIG Cloud Provider] +- Azure: add support for single stack IPv6 ([#88448](https://github.com/kubernetes/kubernetes/pull/88448), [@aramase](https://github.com/aramase)) [SIG Cloud Provider] +- DefaultConstraints can be specified for PodTopologySpread Plugin in the scheduler’s ComponentConfig ([#88671](https://github.com/kubernetes/kubernetes/pull/88671), [@alculquicondor](https://github.com/alculquicondor)) [SIG Scheduling] +- DisableAvailabilitySetNodes is added to avoid VM list for VMSS clusters. It should only be used when vmType is "vmss" and all the nodes (including control plane nodes) are VMSS virtual machines. ([#87685](https://github.com/kubernetes/kubernetes/pull/87685), [@feiskyer](https://github.com/feiskyer)) [SIG Cloud Provider] +- Elasticsearch supports automatically setting the advertise address ([#85944](https://github.com/kubernetes/kubernetes/pull/85944), [@SataQiu](https://github.com/SataQiu)) [SIG Cluster Lifecycle and Instrumentation] +- EndpointSlices will now be enabled by default. A new `EndpointSliceProxying` feature gate determines if kube-proxy will use EndpointSlices, this is disabled by default. ([#86137](https://github.com/kubernetes/kubernetes/pull/86137), [@robscott](https://github.com/robscott)) [SIG Network] +- Kube-proxy: Added dual-stack IPv4/IPv6 support to the iptables proxier. ([#82462](https://github.com/kubernetes/kubernetes/pull/82462), [@vllry](https://github.com/vllry)) [SIG Network] +- Kubeadm now supports automatic calculations of dual-stack node cidr masks to kube-controller-manager. ([#85609](https://github.com/kubernetes/kubernetes/pull/85609), [@Arvinderpal](https://github.com/Arvinderpal)) [SIG Cluster Lifecycle] +- Kubeadm: add a upgrade health check that deploys a Job ([#81319](https://github.com/kubernetes/kubernetes/pull/81319), [@neolit123](https://github.com/neolit123)) [SIG Cluster Lifecycle] +- Kubeadm: add the experimental feature gate PublicKeysECDSA that can be used to create a + cluster with ECDSA certificates from "kubeadm init". Renewal of existing ECDSA certificates is also supported using "kubeadm alpha certs renew", but not switching between the RSA and ECDSA algorithms on the fly or during upgrades. ([#86953](https://github.com/kubernetes/kubernetes/pull/86953), [@rojkov](https://github.com/rojkov)) [SIG API Machinery, Auth and Cluster Lifecycle] +- Kubeadm: implemented structured output of 'kubeadm config images list' command in JSON, YAML, Go template and JsonPath formats ([#86810](https://github.com/kubernetes/kubernetes/pull/86810), [@bart0sh](https://github.com/bart0sh)) [SIG Cluster Lifecycle] +- Kubeadm: on kubeconfig certificate renewal, keep the embedded CA in sync with the one on disk ([#88052](https://github.com/kubernetes/kubernetes/pull/88052), [@neolit123](https://github.com/neolit123)) [SIG Cluster Lifecycle] +- Kubeadm: reject a node joining the cluster if a node with the same name already exists ([#81056](https://github.com/kubernetes/kubernetes/pull/81056), [@neolit123](https://github.com/neolit123)) [SIG Cluster Lifecycle] +- Kubeadm: support Windows specific kubelet flags in kubeadm-flags.env ([#88287](https://github.com/kubernetes/kubernetes/pull/88287), [@gab-satchi](https://github.com/gab-satchi)) [SIG Cluster Lifecycle and Windows] +- Kubeadm: support automatic retry after failing to pull image ([#86899](https://github.com/kubernetes/kubernetes/pull/86899), [@SataQiu](https://github.com/SataQiu)) [SIG Cluster Lifecycle] +- Kubeadm: upgrade supports fallback to the nearest known etcd version if an unknown k8s version is passed ([#88373](https://github.com/kubernetes/kubernetes/pull/88373), [@SataQiu](https://github.com/SataQiu)) [SIG Cluster Lifecycle] +- Kubectl/drain: add disable-eviction option.Force drain to use delete, even if eviction is supported. This will bypass checking PodDisruptionBudgets, and should be used with caution. ([#85571](https://github.com/kubernetes/kubernetes/pull/85571), [@michaelgugino](https://github.com/michaelgugino)) [SIG CLI] +- Kubectl/drain: add skip-wait-for-delete-timeout option. If a pod’s `DeletionTimestamp` is older than N seconds, skip waiting for the pod. Seconds must be greater than 0 to skip. ([#85577](https://github.com/kubernetes/kubernetes/pull/85577), [@michaelgugino](https://github.com/michaelgugino)) [SIG CLI] +- Option `preConfiguredBackendPoolLoadBalancerTypes` is added to azure cloud provider for the pre-configured load balancers, possible values: `""`, `"internal"`, `"external"`,`"all"` ([#86338](https://github.com/kubernetes/kubernetes/pull/86338), [@gossion](https://github.com/gossion)) [SIG Cloud Provider] +- PodTopologySpread plugin now excludes terminatingPods when making scheduling decisions. ([#87845](https://github.com/kubernetes/kubernetes/pull/87845), [@Huang-Wei](https://github.com/Huang-Wei)) [SIG Scheduling] +- Provider/azure: Network security groups can now be in a separate resource group. ([#87035](https://github.com/kubernetes/kubernetes/pull/87035), [@CecileRobertMichon](https://github.com/CecileRobertMichon)) [SIG Cloud Provider] +- SafeSysctlWhitelist: add net.ipv4.ping_group_range ([#85463](https://github.com/kubernetes/kubernetes/pull/85463), [@AkihiroSuda](https://github.com/AkihiroSuda)) [SIG Auth] +- Scheduler framework permit plugins now run at the end of the scheduling cycle, after reserve plugins. Waiting on permit will remain in the beginning of the binding cycle. ([#88199](https://github.com/kubernetes/kubernetes/pull/88199), [@mateuszlitwin](https://github.com/mateuszlitwin)) [SIG Scheduling] +- Scheduler: Add DefaultBinder plugin ([#87430](https://github.com/kubernetes/kubernetes/pull/87430), [@alculquicondor](https://github.com/alculquicondor)) [SIG Scheduling and Testing] +- Skip default spreading scoring plugin for pods that define TopologySpreadConstraints ([#87566](https://github.com/kubernetes/kubernetes/pull/87566), [@skilxn-go](https://github.com/skilxn-go)) [SIG Scheduling] +- The kubectl --dry-run flag now accepts the values 'client', 'server', and 'none', to support client-side and server-side dry-run strategies. The boolean and unset values for the --dry-run flag are deprecated and a value will be required in a future version. ([#87580](https://github.com/kubernetes/kubernetes/pull/87580), [@julianvmodesto](https://github.com/julianvmodesto)) [SIG CLI] +- Support server-side dry-run in kubectl with --dry-run=server for commands including apply, patch, create, run, annotate, label, set, autoscale, drain, rollout undo, and expose. ([#87714](https://github.com/kubernetes/kubernetes/pull/87714), [@julianvmodesto](https://github.com/julianvmodesto)) [SIG API Machinery, CLI and Testing] +- Add --dry-run=server|client to kubectl delete, taint, replace ([#88292](https://github.com/kubernetes/kubernetes/pull/88292), [@julianvmodesto](https://github.com/julianvmodesto)) [SIG CLI and Testing] +- The feature PodTopologySpread (feature gate `EvenPodsSpread`) has been enabled by default in 1.18. ([#88105](https://github.com/kubernetes/kubernetes/pull/88105), [@Huang-Wei](https://github.com/Huang-Wei)) [SIG Scheduling and Testing] +- The kubelet and the default docker runtime now support running ephemeral containers in the Linux process namespace of a target container. Other container runtimes must implement support for this feature before it will be available for that runtime. ([#84731](https://github.com/kubernetes/kubernetes/pull/84731), [@verb](https://github.com/verb)) [SIG Node] +- The underlying format of the `CPUManager` state file has changed. Upgrades should be seamless, but any third-party tools that rely on reading the previous format need to be updated. ([#84462](https://github.com/kubernetes/kubernetes/pull/84462), [@klueska](https://github.com/klueska)) [SIG Node and Testing] +- Update CNI version to v0.8.5 ([#78819](https://github.com/kubernetes/kubernetes/pull/78819), [@justaugustus](https://github.com/justaugustus)) [SIG API Machinery, Cluster Lifecycle, Network, Release and Testing] +- Webhooks have alpha support for network proxy ([#85870](https://github.com/kubernetes/kubernetes/pull/85870), [@Jefftree](https://github.com/Jefftree)) [SIG API Machinery, Auth and Testing] +- When client certificate files are provided, reload files for new connections, and close connections when a certificate changes. ([#79083](https://github.com/kubernetes/kubernetes/pull/79083), [@jackkleeman](https://github.com/jackkleeman)) [SIG API Machinery, Auth, Node and Testing] +- When deleting objects using kubectl with the --force flag, you are no longer required to also specify --grace-period=0. ([#87776](https://github.com/kubernetes/kubernetes/pull/87776), [@brianpursley](https://github.com/brianpursley)) [SIG CLI] +- Windows nodes on GCE can use virtual TPM-based authentication to the control plane. ([#85466](https://github.com/kubernetes/kubernetes/pull/85466), [@pjh](https://github.com/pjh)) [SIG Cluster Lifecycle] +- You can now pass "--node-ip ::" to kubelet to indicate that it should autodetect an IPv6 address to use as the node's primary address. ([#85850](https://github.com/kubernetes/kubernetes/pull/85850), [@danwinship](https://github.com/danwinship)) [SIG Cloud Provider, Network and Node] +- `kubectl` now contains a `kubectl alpha debug` command. This command allows attaching an ephemeral container to a running pod for the purposes of debugging. ([#88004](https://github.com/kubernetes/kubernetes/pull/88004), [@verb](https://github.com/verb)) [SIG CLI] +- TLS Server Name overrides can now be specified in a kubeconfig file and via --tls-server-name in kubectl ([#88769](https://github.com/kubernetes/kubernetes/pull/88769), [@deads2k](https://github.com/deads2k)) [SIG API Machinery, Auth and CLI] + +#### Metrics: +- Add `rest_client_rate_limiter_duration_seconds` metric to component-base to track client side rate limiter latency in seconds. Broken down by verb and URL. ([#88134](https://github.com/kubernetes/kubernetes/pull/88134), [@jennybuckley](https://github.com/jennybuckley)) [SIG API Machinery, Cluster Lifecycle and Instrumentation] +- Added two client certificate metrics for exec auth: + - `rest_client_certificate_expiration_seconds` a gauge reporting the lifetime of the current client certificate. Reports the time of expiry in seconds since January 1, 1970 UTC. + - `rest_client_certificate_rotation_age` a histogram reporting the age of a just rotated client certificate in seconds. ([#84382](https://github.com/kubernetes/kubernetes/pull/84382), [@sambdavidson](https://github.com/sambdavidson)) [SIG API Machinery, Auth, Cluster Lifecycle and Instrumentation] +- Controller manager serve workqueue metrics ([#87967](https://github.com/kubernetes/kubernetes/pull/87967), [@zhan849](https://github.com/zhan849)) [SIG API Machinery] +- Following metrics have been turned off: + - kubelet_pod_worker_latency_microseconds + - kubelet_pod_start_latency_microseconds + - kubelet_cgroup_manager_latency_microseconds + - kubelet_pod_worker_start_latency_microseconds + - kubelet_pleg_relist_latency_microseconds + - kubelet_pleg_relist_interval_microseconds + - kubelet_eviction_stats_age_microseconds + - kubelet_runtime_operations + - kubelet_runtime_operations_latency_microseconds + - kubelet_runtime_operations_errors + - kubelet_device_plugin_registration_count + - kubelet_device_plugin_alloc_latency_microseconds + - kubelet_docker_operations + - kubelet_docker_operations_latency_microseconds + - kubelet_docker_operations_errors + - kubelet_docker_operations_timeout + - network_plugin_operations_latency_microseconds ([#83841](https://github.com/kubernetes/kubernetes/pull/83841), [@RainbowMango](https://github.com/RainbowMango)) [SIG Network and Node] +- Kube-apiserver metrics will now include request counts, latencies, and response sizes for /healthz, /livez, and /readyz requests. ([#83598](https://github.com/kubernetes/kubernetes/pull/83598), [@jktomer](https://github.com/jktomer)) [SIG API Machinery] +- Kubelet now exports a `server_expiration_renew_failure` and `client_expiration_renew_failure` metric counter if the certificate rotations cannot be performed. ([#84614](https://github.com/kubernetes/kubernetes/pull/84614), [@rphillips](https://github.com/rphillips)) [SIG API Machinery, Auth, CLI, Cloud Provider, Cluster Lifecycle, Instrumentation, Node and Release] +- Kubelet: the metric process_start_time_seconds be marked as with the ALPHA stability level. ([#85446](https://github.com/kubernetes/kubernetes/pull/85446), [@RainbowMango](https://github.com/RainbowMango)) [SIG API Machinery, Cluster Lifecycle, Instrumentation and Node] +- New metric `kubelet_pleg_last_seen_seconds` to aid diagnosis of PLEG not healthy issues. ([#86251](https://github.com/kubernetes/kubernetes/pull/86251), [@bboreham](https://github.com/bboreham)) [SIG Node] + +### Other (Bug, Cleanup or Flake) + +- Fixed a regression with clients prior to 1.15 not being able to update podIP in pod status, or podCIDR in node spec, against >= 1.16 API servers ([#88505](https://github.com/kubernetes/kubernetes/pull/88505), [@liggitt](https://github.com/liggitt)) [SIG Apps and Network] +- Fixed "kubectl describe statefulsets.apps" printing garbage for rolling update partition ([#85846](https://github.com/kubernetes/kubernetes/pull/85846), [@phil9909](https://github.com/phil9909)) [SIG CLI] +- Add a event to PV when filesystem on PV does not match actual filesystem on disk ([#86982](https://github.com/kubernetes/kubernetes/pull/86982), [@gnufied](https://github.com/gnufied)) [SIG Storage] +- Add azure disk WriteAccelerator support ([#87945](https://github.com/kubernetes/kubernetes/pull/87945), [@andyzhangx](https://github.com/andyzhangx)) [SIG Cloud Provider and Storage] +- Add delays between goroutines for vm instance update ([#88094](https://github.com/kubernetes/kubernetes/pull/88094), [@aramase](https://github.com/aramase)) [SIG Cloud Provider] +- Add init containers log to cluster dump info. ([#88324](https://github.com/kubernetes/kubernetes/pull/88324), [@zhouya0](https://github.com/zhouya0)) [SIG CLI] +- Addons: elasticsearch discovery supports IPv6 ([#85543](https://github.com/kubernetes/kubernetes/pull/85543), [@SataQiu](https://github.com/SataQiu)) [SIG Cluster Lifecycle and Instrumentation] +- Adds "volume.beta.kubernetes.io/migrated-to" annotation to PV's and PVC's when they are migrated to signal external provisioners to pick up those objects for Provisioning and Deleting. ([#87098](https://github.com/kubernetes/kubernetes/pull/87098), [@davidz627](https://github.com/davidz627)) [SIG Storage] +- All api-server log request lines in a more greppable format. ([#87203](https://github.com/kubernetes/kubernetes/pull/87203), [@lavalamp](https://github.com/lavalamp)) [SIG API Machinery] +- Azure VMSS LoadBalancerBackendAddressPools updating has been improved with sequential-sync + concurrent-async requests. ([#88699](https://github.com/kubernetes/kubernetes/pull/88699), [@feiskyer](https://github.com/feiskyer)) [SIG Cloud Provider] +- Azure cloud provider now obtains AAD token who audience claim will not have spn: prefix ([#87590](https://github.com/kubernetes/kubernetes/pull/87590), [@weinong](https://github.com/weinong)) [SIG Cloud Provider] +- AzureFile and CephFS use the new Mount library that prevents logging of sensitive mount options. ([#88684](https://github.com/kubernetes/kubernetes/pull/88684), [@saad-ali](https://github.com/saad-ali)) [SIG Storage] +- Bind dns-horizontal containers to linux nodes to avoid Windows scheduling on kubernetes cluster includes linux nodes and windows nodes ([#83364](https://github.com/kubernetes/kubernetes/pull/83364), [@wawa0210](https://github.com/wawa0210)) [SIG Cluster Lifecycle and Windows] +- Bind kube-dns containers to linux nodes to avoid Windows scheduling ([#83358](https://github.com/kubernetes/kubernetes/pull/83358), [@wawa0210](https://github.com/wawa0210)) [SIG Cluster Lifecycle and Windows] +- Bind metadata-agent containers to linux nodes to avoid Windows scheduling on kubernetes cluster includes linux nodes and windows nodes ([#83363](https://github.com/kubernetes/kubernetes/pull/83363), [@wawa0210](https://github.com/wawa0210)) [SIG Cluster Lifecycle, Instrumentation and Windows] +- Bind metrics-server containers to linux nodes to avoid Windows scheduling on kubernetes cluster includes linux nodes and windows nodes ([#83362](https://github.com/kubernetes/kubernetes/pull/83362), [@wawa0210](https://github.com/wawa0210)) [SIG Cluster Lifecycle, Instrumentation and Windows] +- Bug fixes: Make sure we include latest packages node #351 (@caseydavenport) ([#84163](https://github.com/kubernetes/kubernetes/pull/84163), [@david-tigera](https://github.com/david-tigera)) [SIG Cluster Lifecycle] +- CPU limits are now respected for Windows containers. If a node is over-provisioned, no weighting is used, only limits are respected. ([#86101](https://github.com/kubernetes/kubernetes/pull/86101), [@PatrickLang](https://github.com/PatrickLang)) [SIG Node, Testing and Windows] +- Changed core_pattern on COS nodes to be an absolute path. ([#86329](https://github.com/kubernetes/kubernetes/pull/86329), [@mml](https://github.com/mml)) [SIG Cluster Lifecycle and Node] +- Client-go certificate manager rotation gained the ability to preserve optional intermediate chains accompanying issued certificates ([#88744](https://github.com/kubernetes/kubernetes/pull/88744), [@jackkleeman](https://github.com/jackkleeman)) [SIG API Machinery and Auth] +- Cloud provider config CloudProviderBackoffMode has been removed since it won't be used anymore. ([#88463](https://github.com/kubernetes/kubernetes/pull/88463), [@feiskyer](https://github.com/feiskyer)) [SIG Cloud Provider] +- Conformance image now depends on stretch-slim instead of debian-hyperkube-base as that image is being deprecated and removed. ([#88702](https://github.com/kubernetes/kubernetes/pull/88702), [@dims](https://github.com/dims)) [SIG Cluster Lifecycle, Release and Testing] +- Deprecate --generator flag from kubectl create commands ([#88655](https://github.com/kubernetes/kubernetes/pull/88655), [@soltysh](https://github.com/soltysh)) [SIG CLI] +- During initialization phase (preflight), kubeadm now verifies the presence of the conntrack executable ([#85857](https://github.com/kubernetes/kubernetes/pull/85857), [@hnanni](https://github.com/hnanni)) [SIG Cluster Lifecycle] +- EndpointSlice should not contain endpoints for terminating pods ([#89056](https://github.com/kubernetes/kubernetes/pull/89056), [@andrewsykim](https://github.com/andrewsykim)) [SIG Apps and Network] +- Evictions due to pods breaching their ephemeral storage limits are now recorded by the `kubelet_evictions` metric and can be alerted on. ([#87906](https://github.com/kubernetes/kubernetes/pull/87906), [@smarterclayton](https://github.com/smarterclayton)) [SIG Node] +- Filter published OpenAPI schema by making nullable, required fields non-required in order to avoid kubectl to wrongly reject null values. ([#85722](https://github.com/kubernetes/kubernetes/pull/85722), [@sttts](https://github.com/sttts)) [SIG API Machinery] +- Fix /readyz to return error immediately after a shutdown is initiated, before the --shutdown-delay-duration has elapsed. ([#88911](https://github.com/kubernetes/kubernetes/pull/88911), [@tkashem](https://github.com/tkashem)) [SIG API Machinery] +- Fix API Server potential memory leak issue in processing watch request. ([#85410](https://github.com/kubernetes/kubernetes/pull/85410), [@answer1991](https://github.com/answer1991)) [SIG API Machinery] +- Fix EndpointSlice controller race condition and ensure that it handles external changes to EndpointSlices. ([#85703](https://github.com/kubernetes/kubernetes/pull/85703), [@robscott](https://github.com/robscott)) [SIG Apps and Network] +- Fix IPv6 addresses lost issue in pure ipv6 vsphere environment ([#86001](https://github.com/kubernetes/kubernetes/pull/86001), [@hubv](https://github.com/hubv)) [SIG Cloud Provider] +- Fix LoadBalancer rule checking so that no unexpected LoadBalancer updates are made ([#85990](https://github.com/kubernetes/kubernetes/pull/85990), [@feiskyer](https://github.com/feiskyer)) [SIG Cloud Provider] +- Fix a bug in kube-proxy that caused it to crash when using load balancers with a different IP family ([#87117](https://github.com/kubernetes/kubernetes/pull/87117), [@aojea](https://github.com/aojea)) [SIG Network] +- Fix a bug in port-forward: named port not working with service ([#85511](https://github.com/kubernetes/kubernetes/pull/85511), [@oke-py](https://github.com/oke-py)) [SIG CLI] +- Fix a bug in the dual-stack IPVS proxier where stale IPv6 endpoints were not being cleaned up ([#87695](https://github.com/kubernetes/kubernetes/pull/87695), [@andrewsykim](https://github.com/andrewsykim)) [SIG Network] +- Fix a bug that orphan revision cannot be adopted and statefulset cannot be synced ([#86801](https://github.com/kubernetes/kubernetes/pull/86801), [@likakuli](https://github.com/likakuli)) [SIG Apps] +- Fix a bug where ExternalTrafficPolicy is not applied to service ExternalIPs. ([#88786](https://github.com/kubernetes/kubernetes/pull/88786), [@freehan](https://github.com/freehan)) [SIG Network] +- Fix a bug where kubenet fails to parse the tc output. ([#83572](https://github.com/kubernetes/kubernetes/pull/83572), [@chendotjs](https://github.com/chendotjs)) [SIG Network] +- Fix a regression in kubenet that prevent pods to obtain ip addresses ([#85993](https://github.com/kubernetes/kubernetes/pull/85993), [@chendotjs](https://github.com/chendotjs)) [SIG Network and Node] +- Fix azure file AuthorizationFailure ([#85475](https://github.com/kubernetes/kubernetes/pull/85475), [@andyzhangx](https://github.com/andyzhangx)) [SIG Cloud Provider and Storage] +- Fix bug where EndpointSlice controller would attempt to modify shared objects. ([#85368](https://github.com/kubernetes/kubernetes/pull/85368), [@robscott](https://github.com/robscott)) [SIG API Machinery, Apps and Network] +- Fix handling of aws-load-balancer-security-groups annotation. Security-Groups assigned with this annotation are no longer modified by kubernetes which is the expected behaviour of most users. Also no unnecessary Security-Groups are created anymore if this annotation is used. ([#83446](https://github.com/kubernetes/kubernetes/pull/83446), [@Elias481](https://github.com/Elias481)) [SIG Cloud Provider] +- Fix invalid VMSS updates due to incorrect cache ([#89002](https://github.com/kubernetes/kubernetes/pull/89002), [@ArchangelSDY](https://github.com/ArchangelSDY)) [SIG Cloud Provider] +- Fix isCurrentInstance for Windows by removing the dependency of hostname. ([#89138](https://github.com/kubernetes/kubernetes/pull/89138), [@feiskyer](https://github.com/feiskyer)) [SIG Cloud Provider] +- Fix issue #85805 about a resource not found in azure cloud provider when LoadBalancer specified in another resource group. ([#86502](https://github.com/kubernetes/kubernetes/pull/86502), [@levimm](https://github.com/levimm)) [SIG Cloud Provider] +- Fix kubectl annotate error when local=true is set ([#86952](https://github.com/kubernetes/kubernetes/pull/86952), [@zhouya0](https://github.com/zhouya0)) [SIG CLI] +- Fix kubectl create deployment image name ([#86636](https://github.com/kubernetes/kubernetes/pull/86636), [@zhouya0](https://github.com/zhouya0)) [SIG CLI] +- Fix `kubectl drain ignore` daemonsets and others. ([#87361](https://github.com/kubernetes/kubernetes/pull/87361), [@zhouya0](https://github.com/zhouya0)) [SIG CLI] +- Fix missing "apiVersion" for "involvedObject" in Events for Nodes. ([#87537](https://github.com/kubernetes/kubernetes/pull/87537), [@uthark](https://github.com/uthark)) [SIG Apps and Node] +- Fix nil pointer dereference in azure cloud provider ([#85975](https://github.com/kubernetes/kubernetes/pull/85975), [@ldx](https://github.com/ldx)) [SIG Cloud Provider] +- Fix regression in statefulset conversion which prevents applying a statefulset multiple times. ([#87706](https://github.com/kubernetes/kubernetes/pull/87706), [@liggitt](https://github.com/liggitt)) [SIG Apps and Testing] +- Fix route conflicted operations when updating multiple routes together ([#88209](https://github.com/kubernetes/kubernetes/pull/88209), [@feiskyer](https://github.com/feiskyer)) [SIG Cloud Provider] +- Fix that prevents repeated fetching of PVC/PV objects by kubelet when processing of pod volumes fails. While this prevents hammering API server in these error scenarios, it means that some errors in processing volume(s) for a pod could now take up to 2-3 minutes before retry. ([#88141](https://github.com/kubernetes/kubernetes/pull/88141), [@tedyu](https://github.com/tedyu)) [SIG Node and Storage] +- Fix the bug PIP's DNS is deleted if no DNS label service annotation isn't set. ([#87246](https://github.com/kubernetes/kubernetes/pull/87246), [@nilo19](https://github.com/nilo19)) [SIG Cloud Provider] +- Fix control plane hosts rolling upgrade causing thundering herd of LISTs on etcd leading to control plane unavailability. ([#86430](https://github.com/kubernetes/kubernetes/pull/86430), [@wojtek-t](https://github.com/wojtek-t)) [SIG API Machinery, Node and Testing] +- Fix: add azure disk migration support for CSINode ([#88014](https://github.com/kubernetes/kubernetes/pull/88014), [@andyzhangx](https://github.com/andyzhangx)) [SIG Cloud Provider and Storage] +- Fix: add non-retriable errors in azure clients ([#87941](https://github.com/kubernetes/kubernetes/pull/87941), [@andyzhangx](https://github.com/andyzhangx)) [SIG Cloud Provider] +- Fix: add remediation in azure disk attach/detach ([#88444](https://github.com/kubernetes/kubernetes/pull/88444), [@andyzhangx](https://github.com/andyzhangx)) [SIG Cloud Provider] +- Fix: azure data disk should use same key as os disk by default ([#86351](https://github.com/kubernetes/kubernetes/pull/86351), [@andyzhangx](https://github.com/andyzhangx)) [SIG Cloud Provider] +- Fix: azure disk could not mounted on Standard_DC4s/DC2s instances ([#86612](https://github.com/kubernetes/kubernetes/pull/86612), [@andyzhangx](https://github.com/andyzhangx)) [SIG Cloud Provider and Storage] +- Fix: azure file mount timeout issue ([#88610](https://github.com/kubernetes/kubernetes/pull/88610), [@andyzhangx](https://github.com/andyzhangx)) [SIG Cloud Provider and Storage] +- Fix: check disk status before disk azure disk ([#88360](https://github.com/kubernetes/kubernetes/pull/88360), [@andyzhangx](https://github.com/andyzhangx)) [SIG Cloud Provider] +- Fix: corrupted mount point in csi driver ([#88569](https://github.com/kubernetes/kubernetes/pull/88569), [@andyzhangx](https://github.com/andyzhangx)) [SIG Storage] +- Fix: get azure disk lun timeout issue ([#88158](https://github.com/kubernetes/kubernetes/pull/88158), [@andyzhangx](https://github.com/andyzhangx)) [SIG Cloud Provider and Storage] +- Fix: update azure disk max count ([#88201](https://github.com/kubernetes/kubernetes/pull/88201), [@andyzhangx](https://github.com/andyzhangx)) [SIG Cloud Provider and Storage] +- Fixed "requested device X but found Y" attach error on AWS. ([#85675](https://github.com/kubernetes/kubernetes/pull/85675), [@jsafrane](https://github.com/jsafrane)) [SIG Cloud Provider and Storage] +- Fixed NetworkPolicy validation that `Except` values are accepted when they are outside the CIDR range. ([#86578](https://github.com/kubernetes/kubernetes/pull/86578), [@tnqn](https://github.com/tnqn)) [SIG Network] +- Fixed a bug in the TopologyManager. Previously, the TopologyManager would only guarantee alignment if container creation was serialized in some way. Alignment is now guaranteed under all scenarios of container creation. ([#87759](https://github.com/kubernetes/kubernetes/pull/87759), [@klueska](https://github.com/klueska)) [SIG Node] +- Fixed a bug which could prevent a provider ID from ever being set for node if an error occurred determining the provider ID when the node was added. ([#87043](https://github.com/kubernetes/kubernetes/pull/87043), [@zjs](https://github.com/zjs)) [SIG Apps and Cloud Provider] +- Fixed a data race in the kubelet image manager that can cause static pod workers to silently stop working. ([#88915](https://github.com/kubernetes/kubernetes/pull/88915), [@roycaihw](https://github.com/roycaihw)) [SIG Node] +- Fixed a panic in the kubelet cleaning up pod volumes ([#86277](https://github.com/kubernetes/kubernetes/pull/86277), [@tedyu](https://github.com/tedyu)) [SIG Storage] +- Fixed a regression where the kubelet would fail to update the ready status of pods. ([#84951](https://github.com/kubernetes/kubernetes/pull/84951), [@tedyu](https://github.com/tedyu)) [SIG Node] +- Fixed an issue that could cause the kubelet to incorrectly run concurrent pod reconciliation loops and crash. ([#89055](https://github.com/kubernetes/kubernetes/pull/89055), [@tedyu](https://github.com/tedyu)) [SIG Node] +- Fixed block CSI volume cleanup after timeouts. ([#88660](https://github.com/kubernetes/kubernetes/pull/88660), [@jsafrane](https://github.com/jsafrane)) [SIG Storage] +- Fixed cleaning of CSI raw block volumes. ([#87978](https://github.com/kubernetes/kubernetes/pull/87978), [@jsafrane](https://github.com/jsafrane)) [SIG Storage] +- Fixed AWS Cloud Provider attempting to delete LoadBalancer security group it didn’t provision, and fixed AWS Cloud Provider creating a default LoadBalancer security group even if annotation `service.beta.kubernetes.io/aws-load-balancer-security-groups` is present because the intended behavior of aws-load-balancer-security-groups is to replace all security groups assigned to the load balancer. ([#84265](https://github.com/kubernetes/kubernetes/pull/84265), [@bhagwat070919](https://github.com/bhagwat070919)) [SIG Cloud Provider] +- Fixed two scheduler metrics (pending_pods and schedule_attempts_total) not being recorded ([#87692](https://github.com/kubernetes/kubernetes/pull/87692), [@everpeace](https://github.com/everpeace)) [SIG Scheduling] +- Fixes an issue with kubelet-reported pod status on deleted/recreated pods. ([#86320](https://github.com/kubernetes/kubernetes/pull/86320), [@liggitt](https://github.com/liggitt)) [SIG Node] +- Fixes conversion error in multi-version custom resources that could cause metadata.generation to increment on no-op patches or updates of a custom resource. ([#88995](https://github.com/kubernetes/kubernetes/pull/88995), [@liggitt](https://github.com/liggitt)) [SIG API Machinery] +- Fixes issue where AAD token obtained by kubectl is incompatible with on-behalf-of flow and oidc. The audience claim before this fix has "spn:" prefix. After this fix, "spn:" prefix is omitted. ([#86412](https://github.com/kubernetes/kubernetes/pull/86412), [@weinong](https://github.com/weinong)) [SIG API Machinery, Auth and Cloud Provider] +- Fixes an issue where you can't attach more than 15 GCE Persistent Disks to c2, n2, m1, m2 machine types. ([#88602](https://github.com/kubernetes/kubernetes/pull/88602), [@yuga711](https://github.com/yuga711)) [SIG Storage] +- Fixes kube-proxy when EndpointSlice feature gate is enabled on Windows. ([#86016](https://github.com/kubernetes/kubernetes/pull/86016), [@robscott](https://github.com/robscott)) [SIG Auth and Network] +- Fixes kubelet crash in client certificate rotation cases ([#88079](https://github.com/kubernetes/kubernetes/pull/88079), [@liggitt](https://github.com/liggitt)) [SIG API Machinery, Auth and Node] +- Fixes service account token admission error in clusters that do not run the service account token controller ([#87029](https://github.com/kubernetes/kubernetes/pull/87029), [@liggitt](https://github.com/liggitt)) [SIG Auth] +- Fixes v1.17.0 regression in --service-cluster-ip-range handling with IPv4 ranges larger than 65536 IP addresses ([#86534](https://github.com/kubernetes/kubernetes/pull/86534), [@liggitt](https://github.com/liggitt)) [SIG Network] +- Fixes wrong validation result of NetworkPolicy PolicyTypes ([#85747](https://github.com/kubernetes/kubernetes/pull/85747), [@tnqn](https://github.com/tnqn)) [SIG Network] +- For subprotocol negotiation, both client and server protocol is required now. ([#86646](https://github.com/kubernetes/kubernetes/pull/86646), [@tedyu](https://github.com/tedyu)) [SIG API Machinery and Node] +- For volumes that allow attaches across multiple nodes, attach and detach operations across different nodes are now executed in parallel. ([#88678](https://github.com/kubernetes/kubernetes/pull/88678), [@verult](https://github.com/verult)) [SIG Storage] +- Garbage collector now can correctly orphan ControllerRevisions when StatefulSets are deleted with orphan propagation policy. ([#84984](https://github.com/kubernetes/kubernetes/pull/84984), [@cofyc](https://github.com/cofyc)) [SIG Apps] +- `Get-kube.sh` uses the gcloud's current local GCP service account for auth when the provider is GCE or GKE instead of the metadata server default ([#88383](https://github.com/kubernetes/kubernetes/pull/88383), [@BenTheElder](https://github.com/BenTheElder)) [SIG Cluster Lifecycle] +- Golang/x/net has been updated to bring in fixes for CVE-2020-9283 ([#88381](https://github.com/kubernetes/kubernetes/pull/88381), [@BenTheElder](https://github.com/BenTheElder)) [SIG API Machinery, CLI, Cloud Provider, Cluster Lifecycle and Instrumentation] +- If a serving certificate’s param specifies a name that is an IP for an SNI certificate, it will have priority for replying to server connections. ([#85308](https://github.com/kubernetes/kubernetes/pull/85308), [@deads2k](https://github.com/deads2k)) [SIG API Machinery] +- Improved yaml parsing performance ([#85458](https://github.com/kubernetes/kubernetes/pull/85458), [@cjcullen](https://github.com/cjcullen)) [SIG API Machinery, CLI, Cloud Provider, Cluster Lifecycle, Instrumentation and Node] +- Improves performance of the node authorizer ([#87696](https://github.com/kubernetes/kubernetes/pull/87696), [@liggitt](https://github.com/liggitt)) [SIG Auth] +- In GKE alpha clusters it will be possible to use the service annotation `cloud.google.com/network-tier: Standard` ([#88487](https://github.com/kubernetes/kubernetes/pull/88487), [@zioproto](https://github.com/zioproto)) [SIG Cloud Provider] +- Includes FSType when describing CSI persistent volumes. ([#85293](https://github.com/kubernetes/kubernetes/pull/85293), [@huffmanca](https://github.com/huffmanca)) [SIG CLI and Storage] +- Iptables/userspace proxy: improve performance by getting local addresses only once per sync loop, instead of for every external IP ([#85617](https://github.com/kubernetes/kubernetes/pull/85617), [@andrewsykim](https://github.com/andrewsykim)) [SIG API Machinery, CLI, Cloud Provider, Cluster Lifecycle, Instrumentation and Network] +- Kube-aggregator: always sets unavailableGauge metric to reflect the current state of a service. ([#87778](https://github.com/kubernetes/kubernetes/pull/87778), [@p0lyn0mial](https://github.com/p0lyn0mial)) [SIG API Machinery] +- Kube-apiserver: fixed a conflict error encountered attempting to delete a pod with gracePeriodSeconds=0 and a resourceVersion precondition ([#85516](https://github.com/kubernetes/kubernetes/pull/85516), [@michaelgugino](https://github.com/michaelgugino)) [SIG API Machinery] +- Kube-proxy no longer modifies shared EndpointSlices. ([#86092](https://github.com/kubernetes/kubernetes/pull/86092), [@robscott](https://github.com/robscott)) [SIG Network] +- Kube-proxy: on dual-stack mode, if it is not able to get the IP Family of an endpoint, logs it with level InfoV(4) instead of Warning, avoiding flooding the logs for endpoints without addresses ([#88934](https://github.com/kubernetes/kubernetes/pull/88934), [@aojea](https://github.com/aojea)) [SIG Network] +- Kubeadm allows to configure single-stack clusters if dual-stack is enabled ([#87453](https://github.com/kubernetes/kubernetes/pull/87453), [@aojea](https://github.com/aojea)) [SIG API Machinery, Cluster Lifecycle and Network] +- Kubeadm now includes CoreDNS version 1.6.7 ([#86260](https://github.com/kubernetes/kubernetes/pull/86260), [@rajansandeep](https://github.com/rajansandeep)) [SIG Cluster Lifecycle] +- Kubeadm upgrades always persist the etcd backup for stacked ([#86861](https://github.com/kubernetes/kubernetes/pull/86861), [@SataQiu](https://github.com/SataQiu)) [SIG Cluster Lifecycle] +- Kubeadm: 'kubeadm alpha kubelet config download' has been removed, please use 'kubeadm upgrade node phase kubelet-config' instead ([#87944](https://github.com/kubernetes/kubernetes/pull/87944), [@SataQiu](https://github.com/SataQiu)) [SIG Cluster Lifecycle] +- Kubeadm: Forward cluster name to the controller-manager arguments ([#85817](https://github.com/kubernetes/kubernetes/pull/85817), [@ereslibre](https://github.com/ereslibre)) [SIG Cluster Lifecycle] +- Kubeadm: add support for the "ci/k8s-master" version label as a replacement for "ci-cross/*", which no longer exists. ([#86609](https://github.com/kubernetes/kubernetes/pull/86609), [@Pensu](https://github.com/Pensu)) [SIG Cluster Lifecycle] +- Kubeadm: apply further improvements to the tentative support for concurrent etcd member join. Fixes a bug where multiple members can receive the same hostname. Increase the etcd client dial timeout and retry timeout for add/remove/... operations. ([#87505](https://github.com/kubernetes/kubernetes/pull/87505), [@neolit123](https://github.com/neolit123)) [SIG Cluster Lifecycle] +- Kubeadm: don't write the kubelet environment file on "upgrade apply" ([#85412](https://github.com/kubernetes/kubernetes/pull/85412), [@boluisa](https://github.com/boluisa)) [SIG Cluster Lifecycle] +- Kubeadm: fix potential panic when executing "kubeadm reset" with a corrupted kubelet.conf file ([#86216](https://github.com/kubernetes/kubernetes/pull/86216), [@neolit123](https://github.com/neolit123)) [SIG Cluster Lifecycle] +- Kubeadm: fix the bug that 'kubeadm upgrade' hangs in single node cluster ([#88434](https://github.com/kubernetes/kubernetes/pull/88434), [@SataQiu](https://github.com/SataQiu)) [SIG Cluster Lifecycle] +- Kubeadm: make sure images are pre-pulled even if a tag did not change but their contents changed ([#85603](https://github.com/kubernetes/kubernetes/pull/85603), [@bart0sh](https://github.com/bart0sh)) [SIG Cluster Lifecycle] +- Kubeadm: remove 'kubeadm upgrade node config' command since it was deprecated in v1.15, please use 'kubeadm upgrade node phase kubelet-config' instead ([#87975](https://github.com/kubernetes/kubernetes/pull/87975), [@SataQiu](https://github.com/SataQiu)) [SIG Cluster Lifecycle] +- Kubeadm: remove the deprecated CoreDNS feature-gate. It was set to "true" since v1.11 when the feature went GA. In v1.13 it was marked as deprecated and hidden from the CLI. ([#87400](https://github.com/kubernetes/kubernetes/pull/87400), [@neolit123](https://github.com/neolit123)) [SIG Cluster Lifecycle] +- Kubeadm: retry `kubeadm-config` ConfigMap creation or mutation if the apiserver is not responding. This will improve resiliency when joining new control plane nodes. ([#85763](https://github.com/kubernetes/kubernetes/pull/85763), [@ereslibre](https://github.com/ereslibre)) [SIG Cluster Lifecycle] +- Kubeadm: tolerate whitespace when validating certificate authority PEM data in kubeconfig files ([#86705](https://github.com/kubernetes/kubernetes/pull/86705), [@neolit123](https://github.com/neolit123)) [SIG Cluster Lifecycle] +- Kubeadm: use bind-address option to configure the kube-controller-manager and kube-scheduler http probes ([#86493](https://github.com/kubernetes/kubernetes/pull/86493), [@aojea](https://github.com/aojea)) [SIG Cluster Lifecycle] +- Kubeadm: uses the api-server AdvertiseAddress IP family to choose the etcd endpoint IP family for non external etcd clusters ([#85745](https://github.com/kubernetes/kubernetes/pull/85745), [@aojea](https://github.com/aojea)) [SIG Cluster Lifecycle] +- Kubectl cluster-info dump --output-directory=xxx now generates files with an extension depending on the output format. ([#82070](https://github.com/kubernetes/kubernetes/pull/82070), [@olivierlemasle](https://github.com/olivierlemasle)) [SIG CLI] +- `Kubectl describe <type>` and `kubectl top pod` will return a message saying `"No resources found"` or `"No resources found in <namespace> namespace"` if there are no results to display. ([#87527](https://github.com/kubernetes/kubernetes/pull/87527), [@brianpursley](https://github.com/brianpursley)) [SIG CLI] +- `Kubectl drain node --dry-run` will list pods that would be evicted or deleted ([#82660](https://github.com/kubernetes/kubernetes/pull/82660), [@sallyom](https://github.com/sallyom)) [SIG CLI] +- `Kubectl set resources` will no longer return an error if passed an empty change for a resource. `kubectl set subject` will no longer return an error if passed an empty change for a resource. ([#85490](https://github.com/kubernetes/kubernetes/pull/85490), [@sallyom](https://github.com/sallyom)) [SIG CLI] +- Kubelet metrics gathered through metrics-server or prometheus should no longer timeout for Windows nodes running more than 3 pods. ([#87730](https://github.com/kubernetes/kubernetes/pull/87730), [@marosset](https://github.com/marosset)) [SIG Node, Testing and Windows] +- Kubelet metrics have been changed to buckets. For example the `exec/{podNamespace}/{podID}/{containerName}` is now just exec. ([#87913](https://github.com/kubernetes/kubernetes/pull/87913), [@cheftako](https://github.com/cheftako)) [SIG Node] +- Kubelets perform fewer unnecessary pod status update operations on the API server. ([#88591](https://github.com/kubernetes/kubernetes/pull/88591), [@smarterclayton](https://github.com/smarterclayton)) [SIG Node and Scalability] +- Kubernetes will try to acquire the iptables lock every 100 msec during 5 seconds instead of every second. This is especially useful for environments using kube-proxy in iptables mode with a high churn rate of services. ([#85771](https://github.com/kubernetes/kubernetes/pull/85771), [@aojea](https://github.com/aojea)) [SIG Network] +- Limit number of instances in a single update to GCE target pool to 1000. ([#87881](https://github.com/kubernetes/kubernetes/pull/87881), [@wojtek-t](https://github.com/wojtek-t)) [SIG Cloud Provider, Network and Scalability] +- Make Azure clients only retry on specified HTTP status codes ([#88017](https://github.com/kubernetes/kubernetes/pull/88017), [@feiskyer](https://github.com/feiskyer)) [SIG Cloud Provider] +- Make error message and service event message more clear ([#86078](https://github.com/kubernetes/kubernetes/pull/86078), [@feiskyer](https://github.com/feiskyer)) [SIG Cloud Provider] +- Minimize AWS NLB health check timeout when externalTrafficPolicy set to Local ([#73363](https://github.com/kubernetes/kubernetes/pull/73363), [@kellycampbell](https://github.com/kellycampbell)) [SIG Cloud Provider] +- Pause image contains "Architecture" in non-amd64 images ([#87954](https://github.com/kubernetes/kubernetes/pull/87954), [@BenTheElder](https://github.com/BenTheElder)) [SIG Release] +- Pause image upgraded to 3.2 in kubelet and kubeadm. ([#88173](https://github.com/kubernetes/kubernetes/pull/88173), [@BenTheElder](https://github.com/BenTheElder)) [SIG CLI, Cluster Lifecycle, Node and Testing] +- Plugin/PluginConfig and Policy APIs are mutually exclusive when running the scheduler ([#88864](https://github.com/kubernetes/kubernetes/pull/88864), [@alculquicondor](https://github.com/alculquicondor)) [SIG Scheduling] +- Remove `FilteredNodesStatuses` argument from `PreScore`'s interface. ([#88189](https://github.com/kubernetes/kubernetes/pull/88189), [@skilxn-go](https://github.com/skilxn-go)) [SIG Scheduling and Testing] +- Resolved a performance issue in the node authorizer index maintenance. ([#87693](https://github.com/kubernetes/kubernetes/pull/87693), [@liggitt](https://github.com/liggitt)) [SIG Auth] +- Resolved regression in admission, authentication, and authorization webhook performance in v1.17.0-rc.1 ([#85810](https://github.com/kubernetes/kubernetes/pull/85810), [@liggitt](https://github.com/liggitt)) [SIG API Machinery and Testing] +- Resolves performance regression in `kubectl get all` and in client-go discovery clients constructed using `NewDiscoveryClientForConfig` or `NewDiscoveryClientForConfigOrDie`. ([#86168](https://github.com/kubernetes/kubernetes/pull/86168), [@liggitt](https://github.com/liggitt)) [SIG API Machinery] +- Reverted a kubectl azure auth module change where oidc claim spn: prefix was omitted resulting a breaking behavior with existing Azure AD OIDC enabled api-server ([#87507](https://github.com/kubernetes/kubernetes/pull/87507), [@weinong](https://github.com/weinong)) [SIG API Machinery, Auth and Cloud Provider] +- Shared informers are now more reliable in the face of network disruption. ([#86015](https://github.com/kubernetes/kubernetes/pull/86015), [@squeed](https://github.com/squeed)) [SIG API Machinery] +- Specifying PluginConfig for the same plugin more than once fails scheduler startup. + Specifying extenders and configuring .ignoredResources for the NodeResourcesFit plugin fails ([#88870](https://github.com/kubernetes/kubernetes/pull/88870), [@alculquicondor](https://github.com/alculquicondor)) [SIG Scheduling] +- Terminating a restartPolicy=Never pod no longer has a chance to report the pod succeeded when it actually failed. ([#88440](https://github.com/kubernetes/kubernetes/pull/88440), [@smarterclayton](https://github.com/smarterclayton)) [SIG Node and Testing] +- The CSR signing cert/key pairs will be reloaded from disk like the kube-apiserver cert/key pairs ([#86816](https://github.com/kubernetes/kubernetes/pull/86816), [@deads2k](https://github.com/deads2k)) [SIG API Machinery, Apps and Auth] +- The EventRecorder from k8s.io/client-go/tools/events will now create events in the default namespace (instead of kube-system) when the related object does not have it set. ([#88815](https://github.com/kubernetes/kubernetes/pull/88815), [@enj](https://github.com/enj)) [SIG API Machinery] +- The audit event sourceIPs list will now always end with the IP that sent the request directly to the API server. ([#87167](https://github.com/kubernetes/kubernetes/pull/87167), [@tallclair](https://github.com/tallclair)) [SIG API Machinery and Auth] +- The sample-apiserver aggregated conformance test has updated to use the Kubernetes v1.17.0 sample apiserver ([#84735](https://github.com/kubernetes/kubernetes/pull/84735), [@liggitt](https://github.com/liggitt)) [SIG API Machinery, Architecture, CLI and Testing] +- To reduce chances of throttling, VM cache is set to nil when Azure node provisioning state is deleting ([#87635](https://github.com/kubernetes/kubernetes/pull/87635), [@feiskyer](https://github.com/feiskyer)) [SIG Cloud Provider] +- VMSS cache is added so that less chances of VMSS GET throttling ([#85885](https://github.com/kubernetes/kubernetes/pull/85885), [@nilo19](https://github.com/nilo19)) [SIG Cloud Provider] +- Wait for kubelet & kube-proxy to be ready on Windows node within 10s ([#85228](https://github.com/kubernetes/kubernetes/pull/85228), [@YangLu1031](https://github.com/YangLu1031)) [SIG Cluster Lifecycle] +- `kubectl apply -f <file> --prune -n <namespace>` should prune all resources not defined in the file in the cli specified namespace. ([#85613](https://github.com/kubernetes/kubernetes/pull/85613), [@MartinKaburu](https://github.com/MartinKaburu)) [SIG CLI] +- `kubectl create clusterrolebinding` creates rbac.authorization.k8s.io/v1 object ([#85889](https://github.com/kubernetes/kubernetes/pull/85889), [@oke-py](https://github.com/oke-py)) [SIG CLI] +- `kubectl diff` now returns 1 only on diff finding changes, and >1 on kubectl errors. The "exit status code 1" message has also been muted. ([#87437](https://github.com/kubernetes/kubernetes/pull/87437), [@apelisse](https://github.com/apelisse)) [SIG CLI and Testing] + +## Dependencies + +- Update Calico to v3.8.4 ([#84163](https://github.com/kubernetes/kubernetes/pull/84163), [@david-tigera](https://github.com/david-tigera))[SIG Cluster Lifecycle] +- Update aws-sdk-go dependency to v1.28.2 ([#87253](https://github.com/kubernetes/kubernetes/pull/87253), [@SaranBalaji90](https://github.com/SaranBalaji90))[SIG API Machinery and Cloud Provider] +- Update CNI version to v0.8.5 ([#78819](https://github.com/kubernetes/kubernetes/pull/78819), [@justaugustus](https://github.com/justaugustus))[SIG Release, Testing, Network, Cluster Lifecycle and API Machinery] +- Update cri-tools to v1.17.0 ([#86305](https://github.com/kubernetes/kubernetes/pull/86305), [@saschagrunert](https://github.com/saschagrunert))[SIG Release and Cluster Lifecycle] +- Pause image upgraded to 3.2 in kubelet and kubeadm ([#88173](https://github.com/kubernetes/kubernetes/pull/88173), [@BenTheElder](https://github.com/BenTheElder))[SIG CLI, Node, Testing and Cluster Lifecycle] +- Update CoreDNS version to 1.6.7 in kubeadm ([#86260](https://github.com/kubernetes/kubernetes/pull/86260), [@rajansandeep](https://github.com/rajansandeep))[SIG Cluster Lifecycle] +- Update golang.org/x/crypto to fix CVE-2020-9283 ([#8838](https://github.com/kubernetes/kubernetes/pull/88381), [@BenTheElder](https://github.com/BenTheElder))[SIG CLI, Instrumentation, API Machinery, CLuster Lifecycle and Cloud Provider] +- Update Go to 1.13.8 ([#87648](https://github.com/kubernetes/kubernetes/pull/87648), [@ialidzhikov](https://github.com/ialidzhikov))[SIG Release and Testing] +- Update Cluster-Autoscaler to 1.18.0 ([#89095](https://github.com/kubernetes/kubernetes/pull/89095), [@losipiuk](https://github.com/losipiuk))[SIG Autoscaling and Cluster Lifecycle] + + + +# v1.18.0-rc.1 + +[Documentation](https://docs.k8s.io) + +## Downloads for v1.18.0-rc.1 + +filename | sha512 hash +-------- | ----------- +[kubernetes.tar.gz](https://dl.k8s.io/v1.18.0-rc.1/kubernetes.tar.gz) | `c17231d5de2e0677e8af8259baa11a388625821c79b86362049f2edb366404d6f4b4587b8f13ccbceeb2f32c6a9fe98607f779c0f3e1caec438f002e3a2c8c21` +[kubernetes-src.tar.gz](https://dl.k8s.io/v1.18.0-rc.1/kubernetes-src.tar.gz) | `e84ffad57c301f5d6e90f916b996d5abb0c987928c3ca6b1565f7b042588f839b994ca12c43fc36f0ffb63f9fabc15110eb08be253b8939f49cd951e956da618` + +### Client Binaries + +filename | sha512 hash +-------- | ----------- +[kubernetes-client-darwin-386.tar.gz](https://dl.k8s.io/v1.18.0-rc.1/kubernetes-client-darwin-386.tar.gz) | `1aea99923d492436b3eb91aaecffac94e5d0aa2b38a0930d266fda85c665bbc4569745c409aa302247df3b578ce60324e7a489eb26240e97d4e65a67428ea3d1` +[kubernetes-client-darwin-amd64.tar.gz](https://dl.k8s.io/v1.18.0-rc.1/kubernetes-client-darwin-amd64.tar.gz) | `07fa7340a959740bd52b83ff44438bbd988e235277dad1e43f125f08ac85230a24a3b755f4e4c8645743444fa2b66a3602fc445d7da6d2fc3770e8c21ba24b33` +[kubernetes-client-linux-386.tar.gz](https://dl.k8s.io/v1.18.0-rc.1/kubernetes-client-linux-386.tar.gz) | `48cebd26448fdd47aa36257baa4c716a98fda055bbf6a05230f2a3fe3c1b99b4e483668661415392190f3eebb9cb6e15c784626b48bb2541d93a37902f0e3974` +[kubernetes-client-linux-amd64.tar.gz](https://dl.k8s.io/v1.18.0-rc.1/kubernetes-client-linux-amd64.tar.gz) | `c3a5fedf263f07a07f59c01fea6c63c1e0b76ee8dc67c45b6c134255c28ed69171ccc2f91b6a45d6a8ec5570a0a7562e24c33b9d7b0d1a864f4dc04b178b3c04` +[kubernetes-client-linux-arm.tar.gz](https://dl.k8s.io/v1.18.0-rc.1/kubernetes-client-linux-arm.tar.gz) | `a6b11a55bd38583bbaac14931a6862f8ce6493afe30947ba29e5556654a571593358278df59412bbeb6888fa127e9ae4c0047a9d46cb59394995010796df6b14` +[kubernetes-client-linux-arm64.tar.gz](https://dl.k8s.io/v1.18.0-rc.1/kubernetes-client-linux-arm64.tar.gz) | `9e15331ac8010154a9b64f5488969fc8ee2f21059639896cb84c5cf4f05f4c9d1d8970cb6f9831de6b34013848227c1972c12a698d07aac1ecc056e972fe6f79` +[kubernetes-client-linux-ppc64le.tar.gz](https://dl.k8s.io/v1.18.0-rc.1/kubernetes-client-linux-ppc64le.tar.gz) | `f828fe6252678de9d4822e482f5873309ae9139b2db87298ab3273ce45d38aa07b6b9b42b76c140705f27ba71e101d58b43e59ac7259d7c08dc647ea809e207c` +[kubernetes-client-linux-s390x.tar.gz](https://dl.k8s.io/v1.18.0-rc.1/kubernetes-client-linux-s390x.tar.gz) | `19da4b45f0666c063934af616f3e7ed3caa99d4ee1e46d53efadc7a8a4d38e43a36ced7249acd7ad3dcc4b4f60d8451b4f7ec7727e478ee2fadd14d353228bce` +[kubernetes-client-windows-386.tar.gz](https://dl.k8s.io/v1.18.0-rc.1/kubernetes-client-windows-386.tar.gz) | `775c9afb6cb3e7c4ba53e9f48a5df2cf207234a33059bd74448bc9f177dd120fb3f9c58ab45048a566326acc43bc8a67e886e10ef99f20780c8f63bb17426ebd` +[kubernetes-client-windows-amd64.tar.gz](https://dl.k8s.io/v1.18.0-rc.1/kubernetes-client-windows-amd64.tar.gz) | `208d2595a5b57ac97aac75b4a2a6130f0c937f781a030bde1a432daf4bc51f2fa523fca2eb84c38798489c4b536ee90aad22f7be8477985d9691d51ad8e1c4dc` + +### Server Binaries + +filename | sha512 hash +-------- | ----------- +[kubernetes-server-linux-amd64.tar.gz](https://dl.k8s.io/v1.18.0-rc.1/kubernetes-server-linux-amd64.tar.gz) | `dcf832eae04f9f52ff473754ef5cfe697b35f4dc1a282622c94fa10943c8c35f4a8777a0c58c7de871c3c428c8973bf72d6bcd8751416d4c682125268b8fcefe` +[kubernetes-server-linux-arm.tar.gz](https://dl.k8s.io/v1.18.0-rc.1/kubernetes-server-linux-arm.tar.gz) | `a04e34bea28eb1c8b492e8b1dd3c0dd87ebee71a7dbbef72be10a335e553361af7e48296e504f9844496b04e66350871114d20cfac3f3b49550d8be60f324ba3` +[kubernetes-server-linux-arm64.tar.gz](https://dl.k8s.io/v1.18.0-rc.1/kubernetes-server-linux-arm64.tar.gz) | `a6af086b07a8c2e498f32b43e6511bf6a5e6baf358c572c6910c8df17cd6cae94f562f459714fcead1595767cb14c7f639c5735f1411173bbd38d5604c082a77` +[kubernetes-server-linux-ppc64le.tar.gz](https://dl.k8s.io/v1.18.0-rc.1/kubernetes-server-linux-ppc64le.tar.gz) | `5a960ef5ba0c255f587f2ac0b028cd03136dc91e4efc5d1becab46417852e5524d18572b6f66259531ec6fea997da3c4d162ac153a9439672154375053fec6c7` +[kubernetes-server-linux-s390x.tar.gz](https://dl.k8s.io/v1.18.0-rc.1/kubernetes-server-linux-s390x.tar.gz) | `0f32c7d9b14bc238b9a5764d8f00edc4d3bf36bcf06b340b81061424e6070768962425194a8c2025c3a7ffb97b1de551d3ad23d1591ae34dd4e3ba25ab364c33` + +### Node Binaries + +filename | sha512 hash +-------- | ----------- +[kubernetes-node-linux-amd64.tar.gz](https://dl.k8s.io/v1.18.0-rc.1/kubernetes-node-linux-amd64.tar.gz) | `27d8955d535d14f3f4dca501fd27e4f06fad84c6da878ea5332a5c83b6955667f6f731bfacaf5a3a23c09f14caa400f9bee927a0f269f5374de7f79cd1919b3b` +[kubernetes-node-linux-arm.tar.gz](https://dl.k8s.io/v1.18.0-rc.1/kubernetes-node-linux-arm.tar.gz) | `0d56eccad63ba608335988e90b377fe8ae978b177dc836cdb803a5c99d99e8f3399a666d9477ca9cfe5964944993e85c416aec10a99323e3246141efc0b1cc9e` +[kubernetes-node-linux-arm64.tar.gz](https://dl.k8s.io/v1.18.0-rc.1/kubernetes-node-linux-arm64.tar.gz) | `79bb9be66f9e892d866b28e5cc838245818edb9706981fab6ccbff493181b341c1fcf6fe5d2342120a112eb93af413f5ba191cfba1ab4c4a8b0546a5ad8ec220` +[kubernetes-node-linux-ppc64le.tar.gz](https://dl.k8s.io/v1.18.0-rc.1/kubernetes-node-linux-ppc64le.tar.gz) | `3e9e2c6f9a2747d828069511dce8b4034c773c2d122f005f4508e22518055c1e055268d9d86773bbd26fbd2d887d783f408142c6c2f56ab2f2365236fd4d2635` +[kubernetes-node-linux-s390x.tar.gz](https://dl.k8s.io/v1.18.0-rc.1/kubernetes-node-linux-s390x.tar.gz) | `4f96e018c336fa13bb6df6f7217fe46a2b5c47f806f786499c429604ccba2ebe558503ab2c72f63250aa25b61dae2d166e4b80ae10f6ab37d714f87c1dcf6691` +[kubernetes-node-windows-amd64.tar.gz](https://dl.k8s.io/v1.18.0-rc.1/kubernetes-node-windows-amd64.tar.gz) | `ab110d76d506746af345e5897ef4f6993d5f53ac818ba69a334f3641047351aa63bfb3582841a9afca51dd0baff8b9010077d9c8ec85d2d69e4172b8d4b338b0` + +## Changelog since v1.18.0-beta.2 + +## Changes by Kind + +### API Change + +- Removes ConfigMap as suggestion for IngressClass parameters ([#89093](https://github.com/kubernetes/kubernetes/pull/89093), [@robscott](https://github.com/robscott)) [SIG Network] + +### Other (Bug, Cleanup or Flake) + +- EndpointSlice should not contain endpoints for terminating pods ([#89056](https://github.com/kubernetes/kubernetes/pull/89056), [@andrewsykim](https://github.com/andrewsykim)) [SIG Apps and Network] +- Fix a bug where ExternalTrafficPolicy is not applied to service ExternalIPs. ([#88786](https://github.com/kubernetes/kubernetes/pull/88786), [@freehan](https://github.com/freehan)) [SIG Network] +- Fix invalid VMSS updates due to incorrect cache ([#89002](https://github.com/kubernetes/kubernetes/pull/89002), [@ArchangelSDY](https://github.com/ArchangelSDY)) [SIG Cloud Provider] +- Fix isCurrentInstance for Windows by removing the dependency of hostname. ([#89138](https://github.com/kubernetes/kubernetes/pull/89138), [@feiskyer](https://github.com/feiskyer)) [SIG Cloud Provider] +- Fixed a data race in kubelet image manager that can cause static pod workers to silently stop working. ([#88915](https://github.com/kubernetes/kubernetes/pull/88915), [@roycaihw](https://github.com/roycaihw)) [SIG Node] +- Fixed an issue that could cause the kubelet to incorrectly run concurrent pod reconciliation loops and crash. ([#89055](https://github.com/kubernetes/kubernetes/pull/89055), [@tedyu](https://github.com/tedyu)) [SIG Node] +- Kube-proxy: on dual-stack mode, if it is not able to get the IP Family of an endpoint, logs it with level InfoV(4) instead of Warning, avoiding flooding the logs for endpoints without addresses ([#88934](https://github.com/kubernetes/kubernetes/pull/88934), [@aojea](https://github.com/aojea)) [SIG Network] +- Update Cluster Autoscaler to 1.18.0; changelog: https://github.com/kubernetes/autoscaler/releases/tag/cluster-autoscaler-1.18.0 ([#89095](https://github.com/kubernetes/kubernetes/pull/89095), [@losipiuk](https://github.com/losipiuk)) [SIG Autoscaling and Cluster Lifecycle] + + +# v1.18.0-beta.2 + +[Documentation](https://docs.k8s.io) + +## Downloads for v1.18.0-beta.2 + +filename | sha512 hash +-------- | ----------- +[kubernetes.tar.gz](https://dl.k8s.io/v1.18.0-beta.2/kubernetes.tar.gz) | `3017430ca17f8a3523669b4a02c39cedfc6c48b07281bc0a67a9fbe9d76547b76f09529172cc01984765353a6134a43733b7315e0dff370bba2635dd2a6289af` +[kubernetes-src.tar.gz](https://dl.k8s.io/v1.18.0-beta.2/kubernetes-src.tar.gz) | `c5fd60601380a99efff4458b1c9cf4dc02195f6f756b36e590e54dff68f7064daf32cf63980dddee13ef9dec7a60ad4eeb47a288083fdbbeeef4bc038384e9ea` + +### Client Binaries + +filename | sha512 hash +-------- | ----------- +[kubernetes-client-darwin-386.tar.gz](https://dl.k8s.io/v1.18.0-beta.2/kubernetes-client-darwin-386.tar.gz) | `7e49ede167b9271d4171e477fa21d267b2fb35f80869337d5b323198dc12f71b61441975bf925ad6e6cd7b61cbf6372d386417dc1e5c9b3c87ae651021c37237` +[kubernetes-client-darwin-amd64.tar.gz](https://dl.k8s.io/v1.18.0-beta.2/kubernetes-client-darwin-amd64.tar.gz) | `3f5cdf0e85eee7d0773e0ae2df1c61329dea90e0da92b02dae1ffd101008dc4bade1c4951fc09f0cad306f0bcb7d16da8654334ddee43d5015913cc4ac8f3eda` +[kubernetes-client-linux-386.tar.gz](https://dl.k8s.io/v1.18.0-beta.2/kubernetes-client-linux-386.tar.gz) | `b67b41c11bfecb88017c33feee21735c56f24cf6f7851b63c752495fc0fb563cd417a67a81f46bca091f74dc00fca1f296e483d2e3dfe2004ea4b42e252d30b9` +[kubernetes-client-linux-amd64.tar.gz](https://dl.k8s.io/v1.18.0-beta.2/kubernetes-client-linux-amd64.tar.gz) | `1fef2197cb80003e3a5c26f05e889af9d85fbbc23e27747944d2997ace4bfa28f3670b13c08f5e26b7e274176b4e2df89c1162aebd8b9506e63b39b311b2d405` +[kubernetes-client-linux-arm.tar.gz](https://dl.k8s.io/v1.18.0-beta.2/kubernetes-client-linux-arm.tar.gz) | `84e5f4d9776490219ee94a84adccd5dfc7c0362eb330709771afcde95ec83f03d96fe7399eec218e47af0a1e6445e24d95e6f9c66c0882ef8233a09ff2022420` +[kubernetes-client-linux-arm64.tar.gz](https://dl.k8s.io/v1.18.0-beta.2/kubernetes-client-linux-arm64.tar.gz) | `ba613b114e0cca32fa21a3d10f845aa2f215d3af54e775f917ff93919f7dd7075efe254e4047a85a1f4b817fc2bd78006c2e8873885f1208cbc02db99e2e2e25` +[kubernetes-client-linux-ppc64le.tar.gz](https://dl.k8s.io/v1.18.0-beta.2/kubernetes-client-linux-ppc64le.tar.gz) | `502a6938d8c4bbe04abbd19b59919d86765058ff72334848be4012cec493e0e7027c6cd950cf501367ac2026eea9f518110cb72d1c792322b396fc2f73d23217` +[kubernetes-client-linux-s390x.tar.gz](https://dl.k8s.io/v1.18.0-beta.2/kubernetes-client-linux-s390x.tar.gz) | `c24700e0ed2ef5c1d2dd282d638c88d90392ae90ea420837b39fd8e1cfc19525017325ccda71d8472fdaea174762208c09e1bba9bbc77c89deef6fac5e847ba2` +[kubernetes-client-windows-386.tar.gz](https://dl.k8s.io/v1.18.0-beta.2/kubernetes-client-windows-386.tar.gz) | `0d4c5a741b052f790c8b0923c9586ee9906225e51cf4dc8a56fc303d4d61bb5bf77fba9e65151dec7be854ff31da8fc2dcd3214563e1b4b9951e6af4aa643da4` +[kubernetes-client-windows-amd64.tar.gz](https://dl.k8s.io/v1.18.0-beta.2/kubernetes-client-windows-amd64.tar.gz) | `841ef2e306c0c9593f04d9528ee019bf3b667761227d9afc1d6ca8bf1aa5631dc25f5fe13ff329c4bf0c816b971fd0dec808f879721e0f3bf51ce49772b38010` + +### Server Binaries + +filename | sha512 hash +-------- | ----------- +[kubernetes-server-linux-amd64.tar.gz](https://dl.k8s.io/v1.18.0-beta.2/kubernetes-server-linux-amd64.tar.gz) | `b373df2e6ef55215e712315a5508e85a39126bd81b7b93c6b6305238919a88c740077828a6f19bcd97141951048ef7a19806ef6b1c3e1772dbc45715c5fcb3af` +[kubernetes-server-linux-arm.tar.gz](https://dl.k8s.io/v1.18.0-beta.2/kubernetes-server-linux-arm.tar.gz) | `b8103cb743c23076ce8dd7c2da01c8dd5a542fbac8480e82dc673139c8ee5ec4495ca33695e7a18dd36412cf1e18ed84c8de05042525ddd8e869fbdfa2766569` +[kubernetes-server-linux-arm64.tar.gz](https://dl.k8s.io/v1.18.0-beta.2/kubernetes-server-linux-arm64.tar.gz) | `8f8f05cf64fb9c8d80cdcb4935b2d3e3edc48bdd303231ae12f93e3f4d979237490744a11e24ba7f52dbb017ca321a8e31624dcffa391b8afda3d02078767fa0` +[kubernetes-server-linux-ppc64le.tar.gz](https://dl.k8s.io/v1.18.0-beta.2/kubernetes-server-linux-ppc64le.tar.gz) | `b313b911c46f2ec129537407af3f165f238e48caeb4b9e530783ffa3659304a544ed02bef8ece715c279373b9fb2c781bd4475560e02c4b98a6d79837bc81938` +[kubernetes-server-linux-s390x.tar.gz](https://dl.k8s.io/v1.18.0-beta.2/kubernetes-server-linux-s390x.tar.gz) | `a1b6b06571141f507b12e5ef98efb88f4b6b9aba924722b2a74f11278d29a2972ab8290608360151d124608e6e24da0eb3516d484cb5fa12ff2987562f15964a` + +### Node Binaries + +filename | sha512 hash +-------- | ----------- +[kubernetes-node-linux-amd64.tar.gz](https://dl.k8s.io/v1.18.0-beta.2/kubernetes-node-linux-amd64.tar.gz) | `20e02ca327543cddb2568ead3d5de164cbfb2914ab6416106d906bf12fcfbc4e55b13bea4d6a515e8feab038e2c929d72c4d6909dfd7881ba69fd1e8c772ab99` +[kubernetes-node-linux-arm.tar.gz](https://dl.k8s.io/v1.18.0-beta.2/kubernetes-node-linux-arm.tar.gz) | `ecd817ef05d6284f9c6592b84b0a48ea31cf4487030c9fb36518474b2a33dad11b9c852774682e60e4e8b074e6bea7016584ca281dddbe2994da5eaf909025c0` +[kubernetes-node-linux-arm64.tar.gz](https://dl.k8s.io/v1.18.0-beta.2/kubernetes-node-linux-arm64.tar.gz) | `0020d32b7908ffd5055c8b26a8b3033e4702f89efcfffe3f6fcdb8a9921fa8eaaed4193c85597c24afd8c523662454f233521bb7055841a54c182521217ccc9d` +[kubernetes-node-linux-ppc64le.tar.gz](https://dl.k8s.io/v1.18.0-beta.2/kubernetes-node-linux-ppc64le.tar.gz) | `e065411d66d486e7793449c1b2f5a412510b913bf7f4e728c0a20e275642b7668957050dc266952cdff09acc391369ae6ac5230184db89af6823ba400745f2fc` +[kubernetes-node-linux-s390x.tar.gz](https://dl.k8s.io/v1.18.0-beta.2/kubernetes-node-linux-s390x.tar.gz) | `082ee90413beaaea41d6cbe9a18f7d783a95852607f3b94190e0ca12aacdd97d87e233b87117871bfb7d0a4b6302fbc7688549492a9bc50a2f43a5452504d3ce` +[kubernetes-node-windows-amd64.tar.gz](https://dl.k8s.io/v1.18.0-beta.2/kubernetes-node-windows-amd64.tar.gz) | `fb5aca0cc36be703f9d4033eababd581bac5de8399c50594db087a99ed4cb56e4920e960eb81d0132d696d094729254eeda2a5c0cb6e65e3abca6c8d61da579e` + +## Changelog since v1.18.0-beta.1 + +## Urgent Upgrade Notes + +### (No, really, you MUST read this before you upgrade) + +- `kubectl` no longer defaults to `http://localhost:8080`. If you own one of these legacy clusters, you are *strongly- encouraged to secure your server. If you cannot secure your server, you can set `KUBERNETES_MASTER` if you were relying on that behavior and you're a client-go user. Set `--server`, `--kubeconfig` or `KUBECONFIG` to make it work in `kubectl`. ([#86173](https://github.com/kubernetes/kubernetes/pull/86173), [@soltysh](https://github.com/soltysh)) [SIG API Machinery, CLI and Testing] + +## Changes by Kind + +### Deprecation + +- AlgorithmSource is removed from v1alpha2 Scheduler ComponentConfig ([#87999](https://github.com/kubernetes/kubernetes/pull/87999), [@damemi](https://github.com/damemi)) [SIG Scheduling] +- Kube-proxy: deprecate `--healthz-port` and `--metrics-port` flag, please use `--healthz-bind-address` and `--metrics-bind-address` instead ([#88512](https://github.com/kubernetes/kubernetes/pull/88512), [@SataQiu](https://github.com/SataQiu)) [SIG Network] +- Kubeadm: deprecate the usage of the experimental flag '--use-api' under the 'kubeadm alpha certs renew' command. ([#88827](https://github.com/kubernetes/kubernetes/pull/88827), [@neolit123](https://github.com/neolit123)) [SIG Cluster Lifecycle] + +### API Change + +- A new IngressClass resource has been added to enable better Ingress configuration. ([#88509](https://github.com/kubernetes/kubernetes/pull/88509), [@robscott](https://github.com/robscott)) [SIG API Machinery, Apps, CLI, Network, Node and Testing] +- Added GenericPVCDataSource feature gate to enable using arbitrary custom resources as the data source for a PVC. ([#88636](https://github.com/kubernetes/kubernetes/pull/88636), [@bswartz](https://github.com/bswartz)) [SIG Apps and Storage] +- Allow user to specify fsgroup permission change policy for pods ([#88488](https://github.com/kubernetes/kubernetes/pull/88488), [@gnufied](https://github.com/gnufied)) [SIG Apps and Storage] +- BlockVolume and CSIBlockVolume features are now GA. ([#88673](https://github.com/kubernetes/kubernetes/pull/88673), [@jsafrane](https://github.com/jsafrane)) [SIG Apps, Node and Storage] +- CustomResourceDefinition schemas that use `x-kubernetes-list-map-keys` to specify properties that uniquely identify list items must make those properties required or have a default value, to ensure those properties are present for all list items. See https://kubernetes.io/docs/reference/using-api/api-concepts/#merge-strategy for details. ([#88076](https://github.com/kubernetes/kubernetes/pull/88076), [@eloyekunle](https://github.com/eloyekunle)) [SIG API Machinery and Testing] +- Fixes a regression with clients prior to 1.15 not being able to update podIP in pod status, or podCIDR in node spec, against >= 1.16 API servers ([#88505](https://github.com/kubernetes/kubernetes/pull/88505), [@liggitt](https://github.com/liggitt)) [SIG Apps and Network] +- Ingress: Add Exact and Prefix maching to Ingress PathTypes ([#88587](https://github.com/kubernetes/kubernetes/pull/88587), [@cmluciano](https://github.com/cmluciano)) [SIG Apps, Cluster Lifecycle and Network] +- Ingress: Add alternate backends via TypedLocalObjectReference ([#88775](https://github.com/kubernetes/kubernetes/pull/88775), [@cmluciano](https://github.com/cmluciano)) [SIG Apps and Network] +- Ingress: allow wildcard hosts in IngressRule ([#88858](https://github.com/kubernetes/kubernetes/pull/88858), [@cmluciano](https://github.com/cmluciano)) [SIG Network] +- Kube-controller-manager and kube-scheduler expose profiling by default to match the kube-apiserver. Use `--enable-profiling=false` to disable. ([#88663](https://github.com/kubernetes/kubernetes/pull/88663), [@deads2k](https://github.com/deads2k)) [SIG API Machinery, Cloud Provider and Scheduling] +- Move TaintBasedEvictions feature gates to GA ([#87487](https://github.com/kubernetes/kubernetes/pull/87487), [@skilxn-go](https://github.com/skilxn-go)) [SIG API Machinery, Apps, Node, Scheduling and Testing] +- New flag --endpointslice-updates-batch-period in kube-controller-manager can be used to reduce number of endpointslice updates generated by pod changes. ([#88745](https://github.com/kubernetes/kubernetes/pull/88745), [@mborsz](https://github.com/mborsz)) [SIG API Machinery, Apps and Network] +- Scheduler Extenders can now be configured in the v1alpha2 component config ([#88768](https://github.com/kubernetes/kubernetes/pull/88768), [@damemi](https://github.com/damemi)) [SIG Release, Scheduling and Testing] +- The apiserver/v1alph1#EgressSelectorConfiguration API is now beta. ([#88502](https://github.com/kubernetes/kubernetes/pull/88502), [@caesarxuchao](https://github.com/caesarxuchao)) [SIG API Machinery] +- The storage.k8s.io/CSIDriver has moved to GA, and is now available for use. ([#84814](https://github.com/kubernetes/kubernetes/pull/84814), [@huffmanca](https://github.com/huffmanca)) [SIG API Machinery, Apps, Auth, Node, Scheduling, Storage and Testing] +- VolumePVCDataSource moves to GA in 1.18 release ([#88686](https://github.com/kubernetes/kubernetes/pull/88686), [@j-griffith](https://github.com/j-griffith)) [SIG Apps, CLI and Cluster Lifecycle] + +### Feature + +- Add `rest_client_rate_limiter_duration_seconds` metric to component-base to track client side rate limiter latency in seconds. Broken down by verb and URL. ([#88134](https://github.com/kubernetes/kubernetes/pull/88134), [@jennybuckley](https://github.com/jennybuckley)) [SIG API Machinery, Cluster Lifecycle and Instrumentation] +- Allow user to specify resource using --filename flag when invoking kubectl exec ([#88460](https://github.com/kubernetes/kubernetes/pull/88460), [@soltysh](https://github.com/soltysh)) [SIG CLI and Testing] +- Apiserver add a new flag --goaway-chance which is the fraction of requests that will be closed gracefully(GOAWAY) to prevent HTTP/2 clients from getting stuck on a single apiserver. + After the connection closed(received GOAWAY), the client's other in-flight requests won't be affected, and the client will reconnect. + The flag min value is 0 (off), max is .02 (1/50 requests); .001 (1/1000) is a recommended starting point. + Clusters with single apiservers, or which don't use a load balancer, should NOT enable this. ([#88567](https://github.com/kubernetes/kubernetes/pull/88567), [@answer1991](https://github.com/answer1991)) [SIG API Machinery] +- Azure: add support for single stack IPv6 ([#88448](https://github.com/kubernetes/kubernetes/pull/88448), [@aramase](https://github.com/aramase)) [SIG Cloud Provider] +- DefaultConstraints can be specified for the PodTopologySpread plugin in the component config ([#88671](https://github.com/kubernetes/kubernetes/pull/88671), [@alculquicondor](https://github.com/alculquicondor)) [SIG Scheduling] +- Kubeadm: support Windows specific kubelet flags in kubeadm-flags.env ([#88287](https://github.com/kubernetes/kubernetes/pull/88287), [@gab-satchi](https://github.com/gab-satchi)) [SIG Cluster Lifecycle and Windows] +- Kubectl cluster-info dump changed to only display a message telling you the location where the output was written when the output is not standard output. ([#88765](https://github.com/kubernetes/kubernetes/pull/88765), [@brianpursley](https://github.com/brianpursley)) [SIG CLI] +- Print NotReady when pod is not ready based on its conditions. ([#88240](https://github.com/kubernetes/kubernetes/pull/88240), [@soltysh](https://github.com/soltysh)) [SIG CLI] +- Scheduler Extender API is now located under k8s.io/kube-scheduler/extender ([#88540](https://github.com/kubernetes/kubernetes/pull/88540), [@damemi](https://github.com/damemi)) [SIG Release, Scheduling and Testing] +- Signatures on scale client methods have been modified to accept `context.Context` as a first argument. Signatures of Get, Update, and Patch methods have been updated to accept GetOptions, UpdateOptions and PatchOptions respectively. ([#88599](https://github.com/kubernetes/kubernetes/pull/88599), [@julianvmodesto](https://github.com/julianvmodesto)) [SIG API Machinery, Apps, Autoscaling and CLI] +- Signatures on the dynamic client methods have been modified to accept `context.Context` as a first argument. Signatures of Delete and DeleteCollection methods now accept DeleteOptions by value instead of by reference. ([#88906](https://github.com/kubernetes/kubernetes/pull/88906), [@liggitt](https://github.com/liggitt)) [SIG API Machinery, Apps, CLI, Cluster Lifecycle, Storage and Testing] +- Signatures on the metadata client methods have been modified to accept `context.Context` as a first argument. Signatures of Delete and DeleteCollection methods now accept DeleteOptions by value instead of by reference. ([#88910](https://github.com/kubernetes/kubernetes/pull/88910), [@liggitt](https://github.com/liggitt)) [SIG API Machinery, Apps and Testing] +- Webhooks will have alpha support for network proxy ([#85870](https://github.com/kubernetes/kubernetes/pull/85870), [@Jefftree](https://github.com/Jefftree)) [SIG API Machinery, Auth and Testing] +- When client certificate files are provided, reload files for new connections, and close connections when a certificate changes. ([#79083](https://github.com/kubernetes/kubernetes/pull/79083), [@jackkleeman](https://github.com/jackkleeman)) [SIG API Machinery, Auth, Node and Testing] +- When deleting objects using kubectl with the --force flag, you are no longer required to also specify --grace-period=0. ([#87776](https://github.com/kubernetes/kubernetes/pull/87776), [@brianpursley](https://github.com/brianpursley)) [SIG CLI] +- `kubectl` now contains a `kubectl alpha debug` command. This command allows attaching an ephemeral container to a running pod for the purposes of debugging. ([#88004](https://github.com/kubernetes/kubernetes/pull/88004), [@verb](https://github.com/verb)) [SIG CLI] + +### Documentation + +- Update Japanese translation for kubectl help ([#86837](https://github.com/kubernetes/kubernetes/pull/86837), [@inductor](https://github.com/inductor)) [SIG CLI and Docs] +- `kubectl plugin` now prints a note how to install krew ([#88577](https://github.com/kubernetes/kubernetes/pull/88577), [@corneliusweig](https://github.com/corneliusweig)) [SIG CLI] + +### Other (Bug, Cleanup or Flake) + +- Azure VMSS LoadBalancerBackendAddressPools updating has been improved with squential-sync + concurrent-async requests. ([#88699](https://github.com/kubernetes/kubernetes/pull/88699), [@feiskyer](https://github.com/feiskyer)) [SIG Cloud Provider] +- AzureFile and CephFS use new Mount library that prevents logging of sensitive mount options. ([#88684](https://github.com/kubernetes/kubernetes/pull/88684), [@saad-ali](https://github.com/saad-ali)) [SIG API Machinery, CLI, Cloud Provider, Cluster Lifecycle, Instrumentation and Storage] +- Build: Enable kube-cross image-building on K8s Infra ([#88562](https://github.com/kubernetes/kubernetes/pull/88562), [@justaugustus](https://github.com/justaugustus)) [SIG Release and Testing] +- Client-go certificate manager rotation gained the ability to preserve optional intermediate chains accompanying issued certificates ([#88744](https://github.com/kubernetes/kubernetes/pull/88744), [@jackkleeman](https://github.com/jackkleeman)) [SIG API Machinery and Auth] +- Conformance image now depends on stretch-slim instead of debian-hyperkube-base as that image is being deprecated and removed. ([#88702](https://github.com/kubernetes/kubernetes/pull/88702), [@dims](https://github.com/dims)) [SIG Cluster Lifecycle, Release and Testing] +- Deprecate --generator flag from kubectl create commands ([#88655](https://github.com/kubernetes/kubernetes/pull/88655), [@soltysh](https://github.com/soltysh)) [SIG CLI] +- FIX: prevent apiserver from panicking when failing to load audit webhook config file ([#88879](https://github.com/kubernetes/kubernetes/pull/88879), [@JoshVanL](https://github.com/JoshVanL)) [SIG API Machinery and Auth] +- Fix /readyz to return error immediately after a shutdown is initiated, before the --shutdown-delay-duration has elapsed. ([#88911](https://github.com/kubernetes/kubernetes/pull/88911), [@tkashem](https://github.com/tkashem)) [SIG API Machinery] +- Fix a bug where kubenet fails to parse the tc output. ([#83572](https://github.com/kubernetes/kubernetes/pull/83572), [@chendotjs](https://github.com/chendotjs)) [SIG Network] +- Fix describe ingress annotations not sorted. ([#88394](https://github.com/kubernetes/kubernetes/pull/88394), [@zhouya0](https://github.com/zhouya0)) [SIG CLI] +- Fix handling of aws-load-balancer-security-groups annotation. Security-Groups assigned with this annotation are no longer modified by kubernetes which is the expected behaviour of most users. Also no unnecessary Security-Groups are created anymore if this annotation is used. ([#83446](https://github.com/kubernetes/kubernetes/pull/83446), [@Elias481](https://github.com/Elias481)) [SIG Cloud Provider] +- Fix kubectl create deployment image name ([#86636](https://github.com/kubernetes/kubernetes/pull/86636), [@zhouya0](https://github.com/zhouya0)) [SIG CLI] +- Fix missing "apiVersion" for "involvedObject" in Events for Nodes. ([#87537](https://github.com/kubernetes/kubernetes/pull/87537), [@uthark](https://github.com/uthark)) [SIG Apps and Node] +- Fix that prevents repeated fetching of PVC/PV objects by kubelet when processing of pod volumes fails. While this prevents hammering API server in these error scenarios, it means that some errors in processing volume(s) for a pod could now take up to 2-3 minutes before retry. ([#88141](https://github.com/kubernetes/kubernetes/pull/88141), [@tedyu](https://github.com/tedyu)) [SIG Node and Storage] +- Fix: azure file mount timeout issue ([#88610](https://github.com/kubernetes/kubernetes/pull/88610), [@andyzhangx](https://github.com/andyzhangx)) [SIG Cloud Provider and Storage] +- Fix: corrupted mount point in csi driver ([#88569](https://github.com/kubernetes/kubernetes/pull/88569), [@andyzhangx](https://github.com/andyzhangx)) [SIG Storage] +- Fixed a bug in the TopologyManager. Previously, the TopologyManager would only guarantee alignment if container creation was serialized in some way. Alignment is now guaranteed under all scenarios of container creation. ([#87759](https://github.com/kubernetes/kubernetes/pull/87759), [@klueska](https://github.com/klueska)) [SIG Node] +- Fixed block CSI volume cleanup after timeouts. ([#88660](https://github.com/kubernetes/kubernetes/pull/88660), [@jsafrane](https://github.com/jsafrane)) [SIG Node and Storage] +- Fixes issue where you can't attach more than 15 GCE Persistent Disks to c2, n2, m1, m2 machine types. ([#88602](https://github.com/kubernetes/kubernetes/pull/88602), [@yuga711](https://github.com/yuga711)) [SIG Storage] +- For volumes that allow attaches across multiple nodes, attach and detach operations across different nodes are now executed in parallel. ([#88678](https://github.com/kubernetes/kubernetes/pull/88678), [@verult](https://github.com/verult)) [SIG Apps, Node and Storage] +- Hide kubectl.kubernetes.io/last-applied-configuration in describe command ([#88758](https://github.com/kubernetes/kubernetes/pull/88758), [@soltysh](https://github.com/soltysh)) [SIG Auth and CLI] +- In GKE alpha clusters it will be possible to use the service annotation `cloud.google.com/network-tier: Standard` ([#88487](https://github.com/kubernetes/kubernetes/pull/88487), [@zioproto](https://github.com/zioproto)) [SIG Cloud Provider] +- Kubelets perform fewer unnecessary pod status update operations on the API server. ([#88591](https://github.com/kubernetes/kubernetes/pull/88591), [@smarterclayton](https://github.com/smarterclayton)) [SIG Node and Scalability] +- Plugin/PluginConfig and Policy APIs are mutually exclusive when running the scheduler ([#88864](https://github.com/kubernetes/kubernetes/pull/88864), [@alculquicondor](https://github.com/alculquicondor)) [SIG Scheduling] +- Specifying PluginConfig for the same plugin more than once fails scheduler startup. + + Specifying extenders and configuring .ignoredResources for the NodeResourcesFit plugin fails ([#88870](https://github.com/kubernetes/kubernetes/pull/88870), [@alculquicondor](https://github.com/alculquicondor)) [SIG Scheduling] +- Support TLS Server Name overrides in kubeconfig file and via --tls-server-name in kubectl ([#88769](https://github.com/kubernetes/kubernetes/pull/88769), [@deads2k](https://github.com/deads2k)) [SIG API Machinery, Auth and CLI] +- Terminating a restartPolicy=Never pod no longer has a chance to report the pod succeeded when it actually failed. ([#88440](https://github.com/kubernetes/kubernetes/pull/88440), [@smarterclayton](https://github.com/smarterclayton)) [SIG Node and Testing] +- The EventRecorder from k8s.io/client-go/tools/events will now create events in the default namespace (instead of kube-system) when the related object does not have it set. ([#88815](https://github.com/kubernetes/kubernetes/pull/88815), [@enj](https://github.com/enj)) [SIG API Machinery] +- The audit event sourceIPs list will now always end with the IP that sent the request directly to the API server. ([#87167](https://github.com/kubernetes/kubernetes/pull/87167), [@tallclair](https://github.com/tallclair)) [SIG API Machinery and Auth] +- Update to use golang 1.13.8 ([#87648](https://github.com/kubernetes/kubernetes/pull/87648), [@ialidzhikov](https://github.com/ialidzhikov)) [SIG Release and Testing] +- Validate kube-proxy flags --ipvs-tcp-timeout, --ipvs-tcpfin-timeout, --ipvs-udp-timeout ([#88657](https://github.com/kubernetes/kubernetes/pull/88657), [@chendotjs](https://github.com/chendotjs)) [SIG Network] + + +# v1.18.0-beta.1 + +[Documentation](https://docs.k8s.io) + +## Downloads for v1.18.0-beta.1 + +filename | sha512 hash +-------- | ----------- +[kubernetes.tar.gz](https://dl.k8s.io/v1.18.0-beta.1/kubernetes.tar.gz) | `7c182ca905b3a31871c01ab5fdaf46f074547536c7975e069ff230af0d402dfc0346958b1d084bd2c108582ffc407484e6a15a1cd93e9affbe34b6e99409ef1f` +[kubernetes-src.tar.gz](https://dl.k8s.io/v1.18.0-beta.1/kubernetes-src.tar.gz) | `d104b8c792b1517bd730787678c71c8ee3b259de81449192a49a1c6e37a6576d28f69b05c2019cc4a4c40ddeb4d60b80138323df3f85db8682caabf28e67c2de` + +### Client Binaries + +filename | sha512 hash +-------- | ----------- +[kubernetes-client-darwin-386.tar.gz](https://dl.k8s.io/v1.18.0-beta.1/kubernetes-client-darwin-386.tar.gz) | `bc337bb8f200a789be4b97ce99b9d7be78d35ebd64746307c28339dc4628f56d9903e0818c0888aaa9364357a528d1ac6fd34f74377000f292ec502fbea3837e` +[kubernetes-client-darwin-amd64.tar.gz](https://dl.k8s.io/v1.18.0-beta.1/kubernetes-client-darwin-amd64.tar.gz) | `38dfa5e0b0cfff39942c913a6bcb2ad8868ec43457d35cffba08217bb6e7531720e0731f8588505f4c81193ce5ec0e5fe6870031cf1403fbbde193acf7e53540` +[kubernetes-client-linux-386.tar.gz](https://dl.k8s.io/v1.18.0-beta.1/kubernetes-client-linux-386.tar.gz) | `8e63ec7ce29c69241120c037372c6c779e3f16253eabd612c7cbe6aa89326f5160eb5798004d723c5cd72d458811e98dac3574842eb6a57b2798ecd2bbe5bcf9` +[kubernetes-client-linux-amd64.tar.gz](https://dl.k8s.io/v1.18.0-beta.1/kubernetes-client-linux-amd64.tar.gz) | `c1be9f184a7c3f896a785c41cd6ece9d90d8cb9b1f6088bdfb5557d8856c55e455f6688f5f54c2114396d5ae7adc0361e34ebf8e9c498d0187bd785646ccc1d0` +[kubernetes-client-linux-arm.tar.gz](https://dl.k8s.io/v1.18.0-beta.1/kubernetes-client-linux-arm.tar.gz) | `8eab02453cfd9e847632a774a0e0cf3a33c7619fb4ced7f1840e1f71444e8719b1c8e8cbfdd1f20bb909f3abe39cdcac74f14cb9c878c656d35871b7c37c7cbe` +[kubernetes-client-linux-arm64.tar.gz](https://dl.k8s.io/v1.18.0-beta.1/kubernetes-client-linux-arm64.tar.gz) | `f7df0ec02d2e7e63278d5386e8153cfe2b691b864f17b6452cc824a5f328d688976c975b076e60f1c6b3c859e93e477134fbccc53bb49d9e846fb038b34eee48` +[kubernetes-client-linux-ppc64le.tar.gz](https://dl.k8s.io/v1.18.0-beta.1/kubernetes-client-linux-ppc64le.tar.gz) | `36dd5b10addca678a518e6d052c9d6edf473e3f87388a2f03f714c93c5fbfe99ace16cf3b382a531be20a8fe6f4160f8d891800dd2cff5f23c9ca12c2f4a151b` +[kubernetes-client-linux-s390x.tar.gz](https://dl.k8s.io/v1.18.0-beta.1/kubernetes-client-linux-s390x.tar.gz) | `5bdbb44b996ab4ccf3a383780270f5cfdbf174982c300723c8bddf0a48ae5e459476031c1d51b9d30ffd621d0a126c18a5de132ef1d92fca2f3e477665ea10cc` +[kubernetes-client-windows-386.tar.gz](https://dl.k8s.io/v1.18.0-beta.1/kubernetes-client-windows-386.tar.gz) | `5dea3d4c4e91ef889850143b361974250e99a3c526f5efee23ff9ccdcd2ceca4a2247e7c4f236bdfa77d2150157da5d676ac9c3ba26cf3a2f1e06d8827556f77` +[kubernetes-client-windows-amd64.tar.gz](https://dl.k8s.io/v1.18.0-beta.1/kubernetes-client-windows-amd64.tar.gz) | `db298e698391368703e6aea7f4345aec5a4b8c69f9d8ff6c99fb5804a6cea16d295fb01e70fe943ade3d4ce9200a081ad40da21bd331317ec9213f69b4d6c48f` + +### Server Binaries + +filename | sha512 hash +-------- | ----------- +[kubernetes-server-linux-amd64.tar.gz](https://dl.k8s.io/v1.18.0-beta.1/kubernetes-server-linux-amd64.tar.gz) | `c6284929dd5940e750b48db72ffbc09f73c5ec31ab3db283babb8e4e07cd8cbb27642f592009caae4717981c0db82c16312849ef4cbafe76acc4264c7d5864ac` +[kubernetes-server-linux-arm.tar.gz](https://dl.k8s.io/v1.18.0-beta.1/kubernetes-server-linux-arm.tar.gz) | `6fc9552cf082c54cc0833b19876117c87ba7feb5a12c7e57f71b52208daf03eaef3ca56bd22b7bce2d6e81b5a23537cf6f5497a6eaa356c0aab1d3de26c309f9` +[kubernetes-server-linux-arm64.tar.gz](https://dl.k8s.io/v1.18.0-beta.1/kubernetes-server-linux-arm64.tar.gz) | `b794b9c399e548949b5bfb2fe71123e86c2034847b2c99aca34b6de718a35355bbecdae9dc2a81c49e3c82fb4b5862526a3f63c2862b438895e12c5ea884f22e` +[kubernetes-server-linux-ppc64le.tar.gz](https://dl.k8s.io/v1.18.0-beta.1/kubernetes-server-linux-ppc64le.tar.gz) | `fddaed7a54f97046a91c29534645811c6346e973e22950b2607b8c119c2377e9ec2d32144f81626078cdaeca673129cc4016c1a3dbd3d43674aa777089fb56ac` +[kubernetes-server-linux-s390x.tar.gz](https://dl.k8s.io/v1.18.0-beta.1/kubernetes-server-linux-s390x.tar.gz) | `65951a534bb55069c7419f41cbcdfe2fae31541d8a3f9eca11fc2489addf281c5ad2d13719212657da0be5b898f22b57ac39446d99072872fbacb0a7d59a4f74` + +### Node Binaries + +filename | sha512 hash +-------- | ----------- +[kubernetes-node-linux-amd64.tar.gz](https://dl.k8s.io/v1.18.0-beta.1/kubernetes-node-linux-amd64.tar.gz) | `992059efb5cae7ed0ef55820368d854bad1c6d13a70366162cd3b5111ce24c371c7c87ded2012f055e08b2ff1b4ef506e1f4e065daa3ac474fef50b5efa4fb07` +[kubernetes-node-linux-arm.tar.gz](https://dl.k8s.io/v1.18.0-beta.1/kubernetes-node-linux-arm.tar.gz) | `c63ae0f8add5821ad267774314b8c8c1ffe3b785872bf278e721fd5dfdad1a5db1d4db3720bea0a36bf10d9c6dd93e247560162c0eac6e1b743246f587d3b27a` +[kubernetes-node-linux-arm64.tar.gz](https://dl.k8s.io/v1.18.0-beta.1/kubernetes-node-linux-arm64.tar.gz) | `47adb9ddf6eaf8f475b89f59ee16fbd5df183149a11ad1574eaa645b47a6d58aec2ca70ba857ce9f1a5793d44cf7a61ebc6874793bb685edaf19410f4f76fd13` +[kubernetes-node-linux-ppc64le.tar.gz](https://dl.k8s.io/v1.18.0-beta.1/kubernetes-node-linux-ppc64le.tar.gz) | `a3bc4a165567c7b76a3e45ab7b102d6eb3ecf373eb048173f921a4964cf9be8891d0d5b8dafbd88c3af7b0e21ef3d41c1e540c3347ddd84b929b3a3d02ceb7b2` +[kubernetes-node-linux-s390x.tar.gz](https://dl.k8s.io/v1.18.0-beta.1/kubernetes-node-linux-s390x.tar.gz) | `109ddf37c748f69584c829db57107c3518defe005c11fcd2a1471845c15aae0a3c89aafdd734229f4069ed18856cc650c80436684e1bdc43cfee3149b0324746` +[kubernetes-node-windows-amd64.tar.gz](https://dl.k8s.io/v1.18.0-beta.1/kubernetes-node-windows-amd64.tar.gz) | `a3a75d2696ad3136476ad7d811e8eabaff5111b90e592695e651d6111f819ebf0165b8b7f5adc05afb5f7f01d1e5fb64876cb696e492feb20a477a5800382b7a` + +## Changelog since v1.18.0-beta.0 + +## Urgent Upgrade Notes + +### (No, really, you MUST read this before you upgrade) + +- The StreamingProxyRedirects feature and `--redirect-container-streaming` flag are deprecated, and will be removed in a future release. The default behavior (proxy streaming requests through the kubelet) will be the only supported option. + If you are setting `--redirect-container-streaming=true`, then you must migrate off this configuration. The flag will no longer be able to be enabled starting in v1.20. If you are not setting the flag, no action is necessary. ([#88290](https://github.com/kubernetes/kubernetes/pull/88290), [@tallclair](https://github.com/tallclair)) [SIG API Machinery and Node] + +- Yes. + + Feature Name: Support using network resources (VNet, LB, IP, etc.) in different AAD Tenant and Subscription than those for the cluster. + + Changes in Pull Request: + + 1. Add properties `networkResourceTenantID` and `networkResourceSubscriptionID` in cloud provider auth config section, which indicates the location of network resources. + 2. Add function `GetMultiTenantServicePrincipalToken` to fetch multi-tenant service principal token, which will be used by Azure VM/VMSS Clients in this feature. + 3. Add function `GetNetworkResourceServicePrincipalToken` to fetch network resource service principal token, which will be used by Azure Network Resource (Load Balancer, Public IP, Route Table, Network Security Group and their sub level resources) Clients in this feature. + 4. Related unit tests. + + None. + + User Documentation: In PR https://github.com/kubernetes-sigs/cloud-provider-azure/pull/301 ([#88384](https://github.com/kubernetes/kubernetes/pull/88384), [@bowen5](https://github.com/bowen5)) [SIG Cloud Provider] + +## Changes by Kind + +### Deprecation + +- Azure service annotation service.beta.kubernetes.io/azure-load-balancer-disable-tcp-reset has been deprecated. Its support would be removed in a future release. ([#88462](https://github.com/kubernetes/kubernetes/pull/88462), [@feiskyer](https://github.com/feiskyer)) [SIG Cloud Provider] + +### API Change + +- API additions to apiserver types ([#87179](https://github.com/kubernetes/kubernetes/pull/87179), [@Jefftree](https://github.com/Jefftree)) [SIG API Machinery, Cloud Provider and Cluster Lifecycle] +- Add Scheduling Profiles to kubescheduler.config.k8s.io/v1alpha2 ([#88087](https://github.com/kubernetes/kubernetes/pull/88087), [@alculquicondor](https://github.com/alculquicondor)) [SIG Scheduling and Testing] +- Added support for multiple sizes huge pages on a container level ([#84051](https://github.com/kubernetes/kubernetes/pull/84051), [@bart0sh](https://github.com/bart0sh)) [SIG Apps, Node and Storage] +- AppProtocol is a new field on Service and Endpoints resources, enabled with the ServiceAppProtocol feature gate. ([#88503](https://github.com/kubernetes/kubernetes/pull/88503), [@robscott](https://github.com/robscott)) [SIG Apps and Network] +- Fixed missing validation of uniqueness of list items in lists with `x-kubernetes-list-type: map` or x-kubernetes-list-type: set` in CustomResources. ([#84920](https://github.com/kubernetes/kubernetes/pull/84920), [@sttts](https://github.com/sttts)) [SIG API Machinery] +- Introduces optional --detect-local flag to kube-proxy. + Currently the only supported value is "cluster-cidr", + which is the default if not specified. ([#87748](https://github.com/kubernetes/kubernetes/pull/87748), [@satyasm](https://github.com/satyasm)) [SIG Cluster Lifecycle, Network and Scheduling] +- Kube-scheduler can run more than one scheduling profile. Given a pod, the profile is selected by using its `.spec.SchedulerName`. ([#88285](https://github.com/kubernetes/kubernetes/pull/88285), [@alculquicondor](https://github.com/alculquicondor)) [SIG Apps, Scheduling and Testing] +- Moving Windows RunAsUserName feature to GA ([#87790](https://github.com/kubernetes/kubernetes/pull/87790), [@marosset](https://github.com/marosset)) [SIG Apps and Windows] + +### Feature + +- Add --dry-run to kubectl delete, taint, replace ([#88292](https://github.com/kubernetes/kubernetes/pull/88292), [@julianvmodesto](https://github.com/julianvmodesto)) [SIG CLI and Testing] +- Add huge page stats to Allocated resources in "kubectl describe node" ([#80605](https://github.com/kubernetes/kubernetes/pull/80605), [@odinuge](https://github.com/odinuge)) [SIG CLI] +- Kubeadm: The ClusterStatus struct present in the kubeadm-config ConfigMap is deprecated and will be removed on a future version. It is going to be maintained by kubeadm until it gets removed. The same information can be found on `etcd` and `kube-apiserver` pod annotations, `kubeadm.kubernetes.io/etcd.advertise-client-urls` and `kubeadm.kubernetes.io/kube-apiserver.advertise-address.endpoint` respectively. ([#87656](https://github.com/kubernetes/kubernetes/pull/87656), [@ereslibre](https://github.com/ereslibre)) [SIG Cluster Lifecycle] +- Kubeadm: add the experimental feature gate PublicKeysECDSA that can be used to create a + cluster with ECDSA certificates from "kubeadm init". Renewal of existing ECDSA certificates is + also supported using "kubeadm alpha certs renew", but not switching between the RSA and + ECDSA algorithms on the fly or during upgrades. ([#86953](https://github.com/kubernetes/kubernetes/pull/86953), [@rojkov](https://github.com/rojkov)) [SIG API Machinery, Auth and Cluster Lifecycle] +- Kubeadm: on kubeconfig certificate renewal, keep the embedded CA in sync with the one on disk ([#88052](https://github.com/kubernetes/kubernetes/pull/88052), [@neolit123](https://github.com/neolit123)) [SIG Cluster Lifecycle] +- Kubeadm: upgrade supports fallback to the nearest known etcd version if an unknown k8s version is passed ([#88373](https://github.com/kubernetes/kubernetes/pull/88373), [@SataQiu](https://github.com/SataQiu)) [SIG Cluster Lifecycle] +- New flag `--show-hidden-metrics-for-version` in kube-scheduler can be used to show all hidden metrics that deprecated in the previous minor release. ([#84913](https://github.com/kubernetes/kubernetes/pull/84913), [@serathius](https://github.com/serathius)) [SIG Instrumentation and Scheduling] +- Scheduler framework permit plugins now run at the end of the scheduling cycle, after reserve plugins. Waiting on permit will remain in the beginning of the binding cycle. ([#88199](https://github.com/kubernetes/kubernetes/pull/88199), [@mateuszlitwin](https://github.com/mateuszlitwin)) [SIG Scheduling] +- The kubelet and the default docker runtime now support running ephemeral containers in the Linux process namespace of a target container. Other container runtimes must implement this feature before it will be available in that runtime. ([#84731](https://github.com/kubernetes/kubernetes/pull/84731), [@verb](https://github.com/verb)) [SIG Node] + +### Other (Bug, Cleanup or Flake) + +- Add delays between goroutines for vm instance update ([#88094](https://github.com/kubernetes/kubernetes/pull/88094), [@aramase](https://github.com/aramase)) [SIG Cloud Provider] +- Add init containers log to cluster dump info. ([#88324](https://github.com/kubernetes/kubernetes/pull/88324), [@zhouya0](https://github.com/zhouya0)) [SIG CLI] +- CPU limits are now respected for Windows containers. If a node is over-provisioned, no weighting is used - only limits are respected. ([#86101](https://github.com/kubernetes/kubernetes/pull/86101), [@PatrickLang](https://github.com/PatrickLang)) [SIG Node, Testing and Windows] +- Cloud provider config CloudProviderBackoffMode has been removed since it won't be used anymore. ([#88463](https://github.com/kubernetes/kubernetes/pull/88463), [@feiskyer](https://github.com/feiskyer)) [SIG Cloud Provider] +- Evictions due to pods breaching their ephemeral storage limits are now recorded by the `kubelet_evictions` metric and can be alerted on. ([#87906](https://github.com/kubernetes/kubernetes/pull/87906), [@smarterclayton](https://github.com/smarterclayton)) [SIG Node] +- Fix: add remediation in azure disk attach/detach ([#88444](https://github.com/kubernetes/kubernetes/pull/88444), [@andyzhangx](https://github.com/andyzhangx)) [SIG Cloud Provider] +- Fix: check disk status before disk azure disk ([#88360](https://github.com/kubernetes/kubernetes/pull/88360), [@andyzhangx](https://github.com/andyzhangx)) [SIG Cloud Provider] +- Fixed cleaning of CSI raw block volumes. ([#87978](https://github.com/kubernetes/kubernetes/pull/87978), [@jsafrane](https://github.com/jsafrane)) [SIG Storage] +- Get-kube.sh uses the gcloud's current local GCP service account for auth when the provider is GCE or GKE instead of the metadata server default ([#88383](https://github.com/kubernetes/kubernetes/pull/88383), [@BenTheElder](https://github.com/BenTheElder)) [SIG Cluster Lifecycle] +- Golang/x/net has been updated to bring in fixes for CVE-2020-9283 ([#88381](https://github.com/kubernetes/kubernetes/pull/88381), [@BenTheElder](https://github.com/BenTheElder)) [SIG API Machinery, CLI, Cloud Provider, Cluster Lifecycle and Instrumentation] +- Kubeadm now includes CoreDNS version 1.6.7 ([#86260](https://github.com/kubernetes/kubernetes/pull/86260), [@rajansandeep](https://github.com/rajansandeep)) [SIG Cluster Lifecycle] +- Kubeadm: fix the bug that 'kubeadm upgrade' hangs in single node cluster ([#88434](https://github.com/kubernetes/kubernetes/pull/88434), [@SataQiu](https://github.com/SataQiu)) [SIG Cluster Lifecycle] +- Optimize kubectl version help info ([#88313](https://github.com/kubernetes/kubernetes/pull/88313), [@zhouya0](https://github.com/zhouya0)) [SIG CLI] +- Removes the deprecated command `kubectl rolling-update` ([#88057](https://github.com/kubernetes/kubernetes/pull/88057), [@julianvmodesto](https://github.com/julianvmodesto)) [SIG Architecture, CLI and Testing] + + +# v1.18.0-alpha.5 + +[Documentation](https://docs.k8s.io) + +## Downloads for v1.18.0-alpha.5 + +filename | sha512 hash +-------- | ----------- +[kubernetes.tar.gz](https://dl.k8s.io/v1.18.0-alpha.5/kubernetes.tar.gz) | `6452cac2b80721e9f577cb117c29b9ac6858812b4275c2becbf74312566f7d016e8b34019bd1bf7615131b191613bf9b973e40ad9ac8f6de9007d41ef2d7fd70` +[kubernetes-src.tar.gz](https://dl.k8s.io/v1.18.0-alpha.5/kubernetes-src.tar.gz) | `e41d9d4dd6910a42990051fcdca4bf5d3999df46375abd27ffc56aae9b455ae984872302d590da6aa85bba6079334fb5fe511596b415ee79843dee1c61c137da` + +### Client Binaries + +filename | sha512 hash +-------- | ----------- +[kubernetes-client-darwin-386.tar.gz](https://dl.k8s.io/v1.18.0-alpha.5/kubernetes-client-darwin-386.tar.gz) | `5c95935863492b31d4aaa6be93260088dafea27663eb91edca980ca3a8485310e60441bc9050d4d577e9c3f7ffd96db516db8d64321124cec1b712e957c9fe1c` +[kubernetes-client-darwin-amd64.tar.gz](https://dl.k8s.io/v1.18.0-alpha.5/kubernetes-client-darwin-amd64.tar.gz) | `868faa578b3738604d8be62fae599ccc556799f1ce54807f1fe72599f20f8a1f98ad8152fac14a08a463322530b696d375253ba3653325e74b587df6e0510da3` +[kubernetes-client-linux-386.tar.gz](https://dl.k8s.io/v1.18.0-alpha.5/kubernetes-client-linux-386.tar.gz) | `76a89d1d30b476b47f8fb808e342f89608e5c1c1787c4c06f2d7e763f9482e2ae8b31e6ad26541972e2b9a3a7c28327e3150cdd355e8b8d8b050a801bbf08d49` +[kubernetes-client-linux-amd64.tar.gz](https://dl.k8s.io/v1.18.0-alpha.5/kubernetes-client-linux-amd64.tar.gz) | `07ad96a09b44d1c707d7c68312c5d69b101a3424bf1e6e9400b2e7a3fba78df04302985d473ddd640d8f3f0257be34110dbe1304b9565dd9d7a4639b7b7b85fd` +[kubernetes-client-linux-arm.tar.gz](https://dl.k8s.io/v1.18.0-alpha.5/kubernetes-client-linux-arm.tar.gz) | `c04fed9fa370a75c1b8e18b2be0821943bb9befcc784d14762ea3278e73600332a9b324d5eeaa1801d20ad6be07a553c41dcf4fa7ab3eadd0730ab043d687c8c` +[kubernetes-client-linux-arm64.tar.gz](https://dl.k8s.io/v1.18.0-alpha.5/kubernetes-client-linux-arm64.tar.gz) | `4199147dea9954333df26d34248a1cb7b02ebbd6380ffcd42d9f9ed5fdabae45a59215474dab3c11436c82e60bd27cbd03b3dde288bf611cd3e78b87c783c6a9` +[kubernetes-client-linux-ppc64le.tar.gz](https://dl.k8s.io/v1.18.0-alpha.5/kubernetes-client-linux-ppc64le.tar.gz) | `4f6d4d61d1c52d3253ca19031ebcd4bad06d19b68bbaaab5c8e8c590774faea4a5ceab1f05f2706b61780927e1467815b3479342c84d45df965aba78414727c4` +[kubernetes-client-linux-s390x.tar.gz](https://dl.k8s.io/v1.18.0-alpha.5/kubernetes-client-linux-s390x.tar.gz) | `e2a454151ae5dd891230fb516a3f73f73ab97832db66fd3d12e7f1657a569f58a9fe2654d50ddd7d8ec88a5ff5094199323a4c6d7d44dcf7edb06cca11dd4de1` +[kubernetes-client-windows-386.tar.gz](https://dl.k8s.io/v1.18.0-alpha.5/kubernetes-client-windows-386.tar.gz) | `14b262ba3b71c41f545db2a017cf1746075ada5745a858d2a62bc9df7c5dc10607220375db85e2c4cb85307b09709e58bc66a407488e0961191e3249dc7742b0` +[kubernetes-client-windows-amd64.tar.gz](https://dl.k8s.io/v1.18.0-alpha.5/kubernetes-client-windows-amd64.tar.gz) | `26353c294755a917216664364b524982b7f5fc6aa832ce90134bb178df8a78604963c68873f121ea5f2626ff615bdbf2ffe54e00578739cde6df42ffae034732` + +### Server Binaries + +filename | sha512 hash +-------- | ----------- +[kubernetes-server-linux-amd64.tar.gz](https://dl.k8s.io/v1.18.0-alpha.5/kubernetes-server-linux-amd64.tar.gz) | `ba77e0e7c610f59647c1b2601f82752964a0f54b7ad609a89b00fcfd553d0f0249f6662becbabaa755bb769b36a2000779f08022c40fb8cc61440337481317a1` +[kubernetes-server-linux-arm.tar.gz](https://dl.k8s.io/v1.18.0-alpha.5/kubernetes-server-linux-arm.tar.gz) | `45e87b3e844ea26958b0b489e8c9b90900a3253000850f5ff9e87ffdcafba72ab8fd17b5ba092051a58a4bc277912c047a85940ec7f093dff6f9e8bf6fed3b42` +[kubernetes-server-linux-arm64.tar.gz](https://dl.k8s.io/v1.18.0-alpha.5/kubernetes-server-linux-arm64.tar.gz) | `155e136e3124ead69c594eead3398d6cfdbb8f823c324880e8a7bbd1b570b05d13a77a69abd0a6758cfcc7923971cc6da4d3e0c1680fd519b632803ece00d5ce` +[kubernetes-server-linux-ppc64le.tar.gz](https://dl.k8s.io/v1.18.0-alpha.5/kubernetes-server-linux-ppc64le.tar.gz) | `3fa0fb8221da19ad9d03278961172b7fa29a618b30abfa55e7243bb937dede8df56658acf02e6b61e7274fbc9395e237f49c62f2a83017eca2a69f67af31c01c` +[kubernetes-server-linux-s390x.tar.gz](https://dl.k8s.io/v1.18.0-alpha.5/kubernetes-server-linux-s390x.tar.gz) | `db3199c3d7ba0b326d71dc8b80f50b195e79e662f71386a3b2976d47d13d7b0136887cc21df6f53e70a3d733da6eac7bbbf3bab2df8a1909a3cee4b44c32dd0b` + +### Node Binaries + +filename | sha512 hash +-------- | ----------- +[kubernetes-node-linux-amd64.tar.gz](https://dl.k8s.io/v1.18.0-alpha.5/kubernetes-node-linux-amd64.tar.gz) | `addcdfbad7f12647e6babb8eadf853a374605c8f18bf63f416fa4d3bf1b903aa206679d840433206423a984bb925e7983366edcdf777cf5daef6ef88e53d6dfa` +[kubernetes-node-linux-arm.tar.gz](https://dl.k8s.io/v1.18.0-alpha.5/kubernetes-node-linux-arm.tar.gz) | `b2ac54e0396e153523d116a2aaa32c919d6243931e0104cd47a23f546d710e7abdaa9eae92d978ce63c92041e63a9b56f5dd8fd06c812a7018a10ecac440f768` +[kubernetes-node-linux-arm64.tar.gz](https://dl.k8s.io/v1.18.0-alpha.5/kubernetes-node-linux-arm64.tar.gz) | `7aab36f2735cba805e4fd109831a1af0f586a88db3f07581b6dc2a2aab90076b22c96b490b4f6461a8fb690bf78948b6d514274f0d6fb0664081de2d44dc48e1` +[kubernetes-node-linux-ppc64le.tar.gz](https://dl.k8s.io/v1.18.0-alpha.5/kubernetes-node-linux-ppc64le.tar.gz) | `a579936f07ebf86f69f297ac50ba4c34caf2c0b903f73190eb581c78382b05ef36d41ade5bfd25d7b1b658cfcbee3d7125702a18e7480f9b09a62733a512a18a` +[kubernetes-node-linux-s390x.tar.gz](https://dl.k8s.io/v1.18.0-alpha.5/kubernetes-node-linux-s390x.tar.gz) | `58fa0359ddd48835192fab1136a2b9b45d1927b04411502c269cda07cb8a8106536973fb4c7fedf1d41893a524c9fe2e21078fdf27bfbeed778273d024f14449` +[kubernetes-node-windows-amd64.tar.gz](https://dl.k8s.io/v1.18.0-alpha.5/kubernetes-node-windows-amd64.tar.gz) | `9086c03cd92b440686cea6d8c4e48045cc46a43ab92ae0e70350b3f51804b9e2aaae7178142306768bae00d9ef6dd938167972bfa90b12223540093f735a45db` + +## Changelog since v1.18.0-alpha.3 + +### Deprecation + +- Kubeadm: command line option "kubelet-version" for `kubeadm upgrade node` has been deprecated and will be removed in a future release. ([#87942](https://github.com/kubernetes/kubernetes/pull/87942), [@SataQiu](https://github.com/SataQiu)) [SIG Cluster Lifecycle] + +### API Change + +- Kubelet podresources API now provides the information about active pods only. ([#79409](https://github.com/kubernetes/kubernetes/pull/79409), [@takmatsu](https://github.com/takmatsu)) [SIG Node] +- Remove deprecated fields from .leaderElection in kubescheduler.config.k8s.io/v1alpha2 ([#87904](https://github.com/kubernetes/kubernetes/pull/87904), [@alculquicondor](https://github.com/alculquicondor)) [SIG Scheduling] +- Signatures on generated clientset methods have been modified to accept `context.Context` as a first argument. Signatures of generated Create, Update, and Patch methods have been updated to accept CreateOptions, UpdateOptions and PatchOptions respectively. Clientsets that with the previous interface have been added in new "deprecated" packages to allow incremental migration to the new APIs. The deprecated packages will be removed in the 1.21 release. ([#87299](https://github.com/kubernetes/kubernetes/pull/87299), [@mikedanese](https://github.com/mikedanese)) [SIG API Machinery, Apps, Auth, Autoscaling, CLI, Cloud Provider, Cluster Lifecycle, Instrumentation, Network, Node, Scheduling, Storage, Testing and Windows] +- The k8s.io/node-api component is no longer updated. Instead, use the RuntimeClass types located within k8s.io/api, and the generated clients located within k8s.io/client-go ([#87503](https://github.com/kubernetes/kubernetes/pull/87503), [@liggitt](https://github.com/liggitt)) [SIG Node and Release] + +### Feature + +- Add indexer for storage cacher ([#85445](https://github.com/kubernetes/kubernetes/pull/85445), [@shaloulcy](https://github.com/shaloulcy)) [SIG API Machinery] +- Add support for mount options to the FC volume plugin ([#87499](https://github.com/kubernetes/kubernetes/pull/87499), [@ejweber](https://github.com/ejweber)) [SIG Storage] +- Added a config-mode flag in azure auth module to enable getting AAD token without spn: prefix in audience claim. When it's not specified, the default behavior doesn't change. ([#87630](https://github.com/kubernetes/kubernetes/pull/87630), [@weinong](https://github.com/weinong)) [SIG API Machinery, Auth, CLI and Cloud Provider] +- Introduced BackoffManager interface for backoff management ([#87829](https://github.com/kubernetes/kubernetes/pull/87829), [@zhan849](https://github.com/zhan849)) [SIG API Machinery] +- PodTopologySpread plugin now excludes terminatingPods when making scheduling decisions. ([#87845](https://github.com/kubernetes/kubernetes/pull/87845), [@Huang-Wei](https://github.com/Huang-Wei)) [SIG Scheduling] +- Promote CSIMigrationOpenStack to Beta (off by default since it requires installation of the OpenStack Cinder CSI Driver) + The in-tree AWS OpenStack Cinder "kubernetes.io/cinder" was already deprecated a while ago and will be removed in 1.20. Users should enable CSIMigration + CSIMigrationOpenStack features and install the OpenStack Cinder CSI Driver (https://github.com/kubernetes-sigs/cloud-provider-openstack) to avoid disruption to existing Pod and PVC objects at that time. + Users should start using the OpenStack Cinder CSI Driver directly for any new volumes. ([#85637](https://github.com/kubernetes/kubernetes/pull/85637), [@dims](https://github.com/dims)) [SIG Cloud Provider] + +### Design + +- The scheduler Permit extension point doesn't return a boolean value in its Allow() and Reject() functions. ([#87936](https://github.com/kubernetes/kubernetes/pull/87936), [@Huang-Wei](https://github.com/Huang-Wei)) [SIG Scheduling] + +### Other (Bug, Cleanup or Flake) + +- Adds "volume.beta.kubernetes.io/migrated-to" annotation to PV's and PVC's when they are migrated to signal external provisioners to pick up those objects for Provisioning and Deleting. ([#87098](https://github.com/kubernetes/kubernetes/pull/87098), [@davidz627](https://github.com/davidz627)) [SIG Apps and Storage] +- Fix a bug in the dual-stack IPVS proxier where stale IPv6 endpoints were not being cleaned up ([#87695](https://github.com/kubernetes/kubernetes/pull/87695), [@andrewsykim](https://github.com/andrewsykim)) [SIG Network] +- Fix kubectl drain ignore daemonsets and others. ([#87361](https://github.com/kubernetes/kubernetes/pull/87361), [@zhouya0](https://github.com/zhouya0)) [SIG CLI] +- Fix: add azure disk migration support for CSINode ([#88014](https://github.com/kubernetes/kubernetes/pull/88014), [@andyzhangx](https://github.com/andyzhangx)) [SIG Cloud Provider and Storage] +- Fix: add non-retriable errors in azure clients ([#87941](https://github.com/kubernetes/kubernetes/pull/87941), [@andyzhangx](https://github.com/andyzhangx)) [SIG Cloud Provider] +- Fixed NetworkPolicy validation that Except values are accepted when they are outside the CIDR range. ([#86578](https://github.com/kubernetes/kubernetes/pull/86578), [@tnqn](https://github.com/tnqn)) [SIG Network] +- Improves performance of the node authorizer ([#87696](https://github.com/kubernetes/kubernetes/pull/87696), [@liggitt](https://github.com/liggitt)) [SIG Auth] +- Iptables/userspace proxy: improve performance by getting local addresses only once per sync loop, instead of for every external IP ([#85617](https://github.com/kubernetes/kubernetes/pull/85617), [@andrewsykim](https://github.com/andrewsykim)) [SIG API Machinery, CLI, Cloud Provider, Cluster Lifecycle, Instrumentation and Network] +- Kube-aggregator: always sets unavailableGauge metric to reflect the current state of a service. ([#87778](https://github.com/kubernetes/kubernetes/pull/87778), [@p0lyn0mial](https://github.com/p0lyn0mial)) [SIG API Machinery] +- Kubeadm allows to configure single-stack clusters if dual-stack is enabled ([#87453](https://github.com/kubernetes/kubernetes/pull/87453), [@aojea](https://github.com/aojea)) [SIG API Machinery, Cluster Lifecycle and Network] +- Kubeadm: 'kubeadm alpha kubelet config download' has been removed, please use 'kubeadm upgrade node phase kubelet-config' instead ([#87944](https://github.com/kubernetes/kubernetes/pull/87944), [@SataQiu](https://github.com/SataQiu)) [SIG Cluster Lifecycle] +- Kubeadm: remove 'kubeadm upgrade node config' command since it was deprecated in v1.15, please use 'kubeadm upgrade node phase kubelet-config' instead ([#87975](https://github.com/kubernetes/kubernetes/pull/87975), [@SataQiu](https://github.com/SataQiu)) [SIG Cluster Lifecycle] +- Kubectl describe <type> and kubectl top pod will return a message saying "No resources found" or "No resources found in <namespace> namespace" if there are no results to display. ([#87527](https://github.com/kubernetes/kubernetes/pull/87527), [@brianpursley](https://github.com/brianpursley)) [SIG CLI] +- Kubelet metrics gathered through metrics-server or prometheus should no longer timeout for Windows nodes running more than 3 pods. ([#87730](https://github.com/kubernetes/kubernetes/pull/87730), [@marosset](https://github.com/marosset)) [SIG Node, Testing and Windows] +- Kubelet metrics have been changed to buckets. + For example the exec/{podNamespace}/{podID}/{containerName} is now just exec. ([#87913](https://github.com/kubernetes/kubernetes/pull/87913), [@cheftako](https://github.com/cheftako)) [SIG Node] +- Limit number of instances in a single update to GCE target pool to 1000. ([#87881](https://github.com/kubernetes/kubernetes/pull/87881), [@wojtek-t](https://github.com/wojtek-t)) [SIG Cloud Provider, Network and Scalability] +- Make Azure clients only retry on specified HTTP status codes ([#88017](https://github.com/kubernetes/kubernetes/pull/88017), [@feiskyer](https://github.com/feiskyer)) [SIG Cloud Provider] +- Pause image contains "Architecture" in non-amd64 images ([#87954](https://github.com/kubernetes/kubernetes/pull/87954), [@BenTheElder](https://github.com/BenTheElder)) [SIG Release] +- Pods that are considered for preemption and haven't started don't produce an error log. ([#87900](https://github.com/kubernetes/kubernetes/pull/87900), [@alculquicondor](https://github.com/alculquicondor)) [SIG Scheduling] +- Prevent error message from being displayed when running kubectl plugin list and your path includes an empty string ([#87633](https://github.com/kubernetes/kubernetes/pull/87633), [@brianpursley](https://github.com/brianpursley)) [SIG CLI] +- `kubectl create clusterrolebinding` creates rbac.authorization.k8s.io/v1 object ([#85889](https://github.com/kubernetes/kubernetes/pull/85889), [@oke-py](https://github.com/oke-py)) [SIG CLI] + +# v1.18.0-alpha.4 + +[Documentation](https://docs.k8s.io) + +## Important note about manual tag + +Due to a [tagging bug in our Release Engineering tooling](https://github.com/kubernetes/release/issues/1080) during `v1.18.0-alpha.3`, we needed to push a manual tag (`v1.18.0-alpha.4`). + +**No binaries have been produced or will be provided for `v1.18.0-alpha.4`.** + +The changelog for `v1.18.0-alpha.4` is included as part of the [changelog since v1.18.0-alpha.3][#changelog-since-v1180-alpha3] section. + +# v1.18.0-alpha.3 + +[Documentation](https://docs.k8s.io) + +## Downloads for v1.18.0-alpha.3 + +filename | sha512 hash +-------- | ----------- +[kubernetes.tar.gz](https://dl.k8s.io/v1.18.0-alpha.3/kubernetes.tar.gz) | `60bf3bfc23b428f53fd853bac18a4a905b980fcc0bacd35ccd6357a89cfc26e47de60975ea6b712e65980e6b9df82a22331152d9f08ed4dba44558ba23a422d4` +[kubernetes-src.tar.gz](https://dl.k8s.io/v1.18.0-alpha.3/kubernetes-src.tar.gz) | `8adf1016565a7c93713ab6fa4293c2d13b4f6e4e1ec4dcba60bd71e218b4dbe9ef5eb7dbb469006743f498fc7ddeb21865cd12bec041af60b1c0edce8b7aecd5` + +### Client Binaries + +filename | sha512 hash +-------- | ----------- +[kubernetes-client-darwin-386.tar.gz](https://dl.k8s.io/v1.18.0-alpha.3/kubernetes-client-darwin-386.tar.gz) | `abb32e894e8280c772e96227b574da81cd1eac374b8d29158b7f222ed550087c65482eef4a9817dfb5f2baf0d9b85fcdfa8feced0fbc1aacced7296853b57e1f` +[kubernetes-client-darwin-amd64.tar.gz](https://dl.k8s.io/v1.18.0-alpha.3/kubernetes-client-darwin-amd64.tar.gz) | `5e4b1a993264e256ec1656305de7c306094cae9781af8f1382df4ce4eed48ce030827fde1a5e757d4ad57233d52075c9e4e93a69efbdc1102e4ba810705ccddc` +[kubernetes-client-linux-386.tar.gz](https://dl.k8s.io/v1.18.0-alpha.3/kubernetes-client-linux-386.tar.gz) | `68da39c2ae101d2b38f6137ceda07eb0c2124794982a62ef483245dbffb0611c1441ca085fa3127e7a9977f45646788832a783544ff06954114548ea0e526e46` +[kubernetes-client-linux-amd64.tar.gz](https://dl.k8s.io/v1.18.0-alpha.3/kubernetes-client-linux-amd64.tar.gz) | `dc236ffa8ad426620e50181419e9bebe3c161e953dbfb8a019f61b11286e1eb950b40d7cc03423bdf3e6974973bcded51300f98b55570c29732fa492dcde761d` +[kubernetes-client-linux-arm.tar.gz](https://dl.k8s.io/v1.18.0-alpha.3/kubernetes-client-linux-arm.tar.gz) | `ab0a8bd6dc31ea160b731593cdc490b3cc03668b1141cf95310bd7060dcaf55c7ee9842e0acae81063fdacb043c3552ccdd12a94afd71d5310b3ce056fdaa06c` +[kubernetes-client-linux-arm64.tar.gz](https://dl.k8s.io/v1.18.0-alpha.3/kubernetes-client-linux-arm64.tar.gz) | `159ea083c601710d0d6aea423eeb346c99ffaf2abd137d35a53e87a07f5caf12fca8790925f3196f67b768fa92a024f83b50325dbca9ccd4dde6c59acdce3509` +[kubernetes-client-linux-ppc64le.tar.gz](https://dl.k8s.io/v1.18.0-alpha.3/kubernetes-client-linux-ppc64le.tar.gz) | `16b0459adfa26575d13be49ab53ac7f0ffd05e184e4e13d2dfbfe725d46bb8ac891e1fd8aebe36ecd419781d4cc5cf3bd2aaaf5263cf283724618c4012408f40` +[kubernetes-client-linux-s390x.tar.gz](https://dl.k8s.io/v1.18.0-alpha.3/kubernetes-client-linux-s390x.tar.gz) | `d5aa1f5d89168995d2797eb839a04ce32560f405b38c1c0baaa0e313e4771ae7bb3b28e22433ad5897d36aadf95f73eb69d8d411d31c4115b6b0adf5fe041f85` +[kubernetes-client-windows-386.tar.gz](https://dl.k8s.io/v1.18.0-alpha.3/kubernetes-client-windows-386.tar.gz) | `374e16a1e52009be88c94786f80174d82dff66399bf294c9bee18a2159c42251c5debef1109a92570799148b08024960c6c50b8299a93fd66ebef94f198f34e9` +[kubernetes-client-windows-amd64.tar.gz](https://dl.k8s.io/v1.18.0-alpha.3/kubernetes-client-windows-amd64.tar.gz) | `5a94c1068c19271f810b994adad8e62fae03b3d4473c7c9e6d056995ff7757ea61dd8d140c9267dd41e48808876673ce117826d35a3c1bb5652752f11a044d57` + +### Server Binaries + +filename | sha512 hash +-------- | ----------- +[kubernetes-server-linux-amd64.tar.gz](https://dl.k8s.io/v1.18.0-alpha.3/kubernetes-server-linux-amd64.tar.gz) | `a677bec81f0eba75114b92ff955bac74512b47e53959d56a685dae5edd527283d91485b1e86ad74ef389c5405863badf7eb22e2f0c9a568a4d0cb495c6a5c32f` +[kubernetes-server-linux-arm.tar.gz](https://dl.k8s.io/v1.18.0-alpha.3/kubernetes-server-linux-arm.tar.gz) | `2fb696f86ff13ebeb5f3cf2b254bf41303644c5ea84a292782eac6123550702655284d957676d382698c091358e5c7fe73f32803699c19be7138d6530fe413b6` +[kubernetes-server-linux-arm64.tar.gz](https://dl.k8s.io/v1.18.0-alpha.3/kubernetes-server-linux-arm64.tar.gz) | `738e95da9cfb8f1309479078098de1c38cef5e1dd5ee1129b77651a936a412b7cd0cf15e652afc7421219646a98846ab31694970432e48dea9c9cafa03aa59cf` +[kubernetes-server-linux-ppc64le.tar.gz](https://dl.k8s.io/v1.18.0-alpha.3/kubernetes-server-linux-ppc64le.tar.gz) | `7a85bfcbb2aa636df60c41879e96e788742ecd72040cb0db2a93418439c125218c58a4cfa96d01b0296c295793e94c544e87c2d98d50b49bc4cb06b41f874376` +[kubernetes-server-linux-s390x.tar.gz](https://dl.k8s.io/v1.18.0-alpha.3/kubernetes-server-linux-s390x.tar.gz) | `1f1cdb2efa3e7cac857203d8845df2fdaa5cf1f20df764efffff29371945ec58f6deeba06f8fbf70b96faf81b0c955bf4cb84e30f9516cb2cc1ed27c2d2185a6` + +### Node Binaries + +filename | sha512 hash +-------- | ----------- +[kubernetes-node-linux-amd64.tar.gz](https://dl.k8s.io/v1.18.0-alpha.3/kubernetes-node-linux-amd64.tar.gz) | `4ccfced3f5ba4adfa58f4a9d1b2c5bdb3e89f9203ab0e27d11eb1c325ac323ebe63c015d2c9d070b233f5d1da76cab5349da3528511c1cd243e66edc9af381c4` +[kubernetes-node-linux-arm.tar.gz](https://dl.k8s.io/v1.18.0-alpha.3/kubernetes-node-linux-arm.tar.gz) | `d695a69d18449062e4c129e54ec8384c573955f8108f4b78adc2ec929719f2196b995469c728dd6656c63c44cda24315543939f85131ebc773cfe0de689df55b` +[kubernetes-node-linux-arm64.tar.gz](https://dl.k8s.io/v1.18.0-alpha.3/kubernetes-node-linux-arm64.tar.gz) | `21df1da88c89000abc22f97e482c3aaa5ce53ec9628d83dda2e04a1d86c4d53be46c03ed6f1f211df3ee5071bce39d944ff7716b5b6ada3b9c4821d368b0a898` +[kubernetes-node-linux-ppc64le.tar.gz](https://dl.k8s.io/v1.18.0-alpha.3/kubernetes-node-linux-ppc64le.tar.gz) | `ff77e3aacb6ed9d89baed92ef542c8b5cec83151b6421948583cf608bca3b779dce41fc6852961e00225d5e1502f6a634bfa61a36efa90e1aee90dedb787c2d2` +[kubernetes-node-linux-s390x.tar.gz](https://dl.k8s.io/v1.18.0-alpha.3/kubernetes-node-linux-s390x.tar.gz) | `57d75b7977ec1a0f6e7ed96a304dbb3b8664910f42ca19aab319a9ec33535ff5901dfca4abcb33bf5741cde6d152acd89a5f8178f0efe1dc24430e0c1af5b98f` +[kubernetes-node-windows-amd64.tar.gz](https://dl.k8s.io/v1.18.0-alpha.3/kubernetes-node-windows-amd64.tar.gz) | `63fdbb71773cfd73a914c498e69bb9eea3fc314366c99ffb8bd42ec5b4dae807682c83c1eb5cfb1e2feb4d11d9e49cc85ba644e954241320a835798be7653d61` + +## Changelog since v1.18.0-alpha.2 + +### Deprecation + +- Remove all the generators from kubectl run. It will now only create pods. Additionally, deprecates all the flags that are not relevant anymore. ([#87077](https://github.com/kubernetes/kubernetes/pull/87077), [@soltysh](https://github.com/soltysh)) [SIG Architecture, SIG CLI, and SIG Testing] +- kubeadm: kube-dns is deprecated and will not be supported in a future version ([#86574](https://github.com/kubernetes/kubernetes/pull/86574), [@SataQiu](https://github.com/SataQiu)) [SIG Cluster Lifecycle] + +### API Change + +- Add kubescheduler.config.k8s.io/v1alpha2 ([#87628](https://github.com/kubernetes/kubernetes/pull/87628), [@alculquicondor](https://github.com/alculquicondor)) [SIG Scheduling] +- --enable-cadvisor-endpoints is now disabled by default. If you need access to the cAdvisor v1 Json API please enable it explicitly in the kubelet command line. Please note that this flag was deprecated in 1.15 and will be removed in 1.19. ([#87440](https://github.com/kubernetes/kubernetes/pull/87440), [@dims](https://github.com/dims)) [SIG Instrumentation, SIG Node, and SIG Testing] +- The following feature gates are removed, because the associated features were unconditionally enabled in previous releases: CustomResourceValidation, CustomResourceSubresources, CustomResourceWebhookConversion, CustomResourcePublishOpenAPI, CustomResourceDefaulting ([#87475](https://github.com/kubernetes/kubernetes/pull/87475), [@liggitt](https://github.com/liggitt)) [SIG API Machinery] + +### Feature + +- aggragation api will have alpha support for network proxy ([#87515](https://github.com/kubernetes/kubernetes/pull/87515), [@Sh4d1](https://github.com/Sh4d1)) [SIG API Machinery] +- API request throttling (due to a high rate of requests) is now reported in client-go logs at log level 2. The messages are of the form + + Throttling request took 1.50705208s, request: GET:<URL> + + The presence of these messages, may indicate to the administrator the need to tune the cluster accordingly. ([#87740](https://github.com/kubernetes/kubernetes/pull/87740), [@jennybuckley](https://github.com/jennybuckley)) [SIG API Machinery] +- kubeadm: reject a node joining the cluster if a node with the same name already exists ([#81056](https://github.com/kubernetes/kubernetes/pull/81056), [@neolit123](https://github.com/neolit123)) [SIG Cluster Lifecycle] +- disableAvailabilitySetNodes is added to avoid VM list for VMSS clusters. It should only be used when vmType is "vmss" and all the nodes (including masters) are VMSS virtual machines. ([#87685](https://github.com/kubernetes/kubernetes/pull/87685), [@feiskyer](https://github.com/feiskyer)) [SIG Cloud Provider] +- The kubectl --dry-run flag now accepts the values 'client', 'server', and 'none', to support client-side and server-side dry-run strategies. The boolean and unset values for the --dry-run flag are deprecated and a value will be required in a future version. ([#87580](https://github.com/kubernetes/kubernetes/pull/87580), [@julianvmodesto](https://github.com/julianvmodesto)) [SIG CLI] +- Add support for pre-allocated hugepages for more than one page size ([#82820](https://github.com/kubernetes/kubernetes/pull/82820), [@odinuge](https://github.com/odinuge)) [SIG Apps] +- Update CNI version to v0.8.5 ([#78819](https://github.com/kubernetes/kubernetes/pull/78819), [@justaugustus](https://github.com/justaugustus)) [SIG API Machinery, SIG Cluster Lifecycle, SIG Network, SIG Release, and SIG Testing] +- Skip default spreading scoring plugin for pods that define TopologySpreadConstraints ([#87566](https://github.com/kubernetes/kubernetes/pull/87566), [@skilxn-go](https://github.com/skilxn-go)) [SIG Scheduling] +- Added more details to taint toleration errors ([#87250](https://github.com/kubernetes/kubernetes/pull/87250), [@starizard](https://github.com/starizard)) [SIG Apps, and SIG Scheduling] +- Scheduler: Add DefaultBinder plugin ([#87430](https://github.com/kubernetes/kubernetes/pull/87430), [@alculquicondor](https://github.com/alculquicondor)) [SIG Scheduling, and SIG Testing] +- Kube-apiserver metrics will now include request counts, latencies, and response sizes for /healthz, /livez, and /readyz requests. ([#83598](https://github.com/kubernetes/kubernetes/pull/83598), [@jktomer](https://github.com/jktomer)) [SIG API Machinery] + +### Other (Bug, Cleanup or Flake) + +- Fix the masters rolling upgrade causing thundering herd of LISTs on etcd leading to control plane unavailability. ([#86430](https://github.com/kubernetes/kubernetes/pull/86430), [@wojtek-t](https://github.com/wojtek-t)) [SIG API Machinery, SIG Node, and SIG Testing] +- `kubectl diff` now returns 1 only on diff finding changes, and >1 on kubectl errors. The "exit status code 1" message as also been muted. ([#87437](https://github.com/kubernetes/kubernetes/pull/87437), [@apelisse](https://github.com/apelisse)) [SIG CLI, and SIG Testing] +- To reduce chances of throttling, VM cache is set to nil when Azure node provisioning state is deleting ([#87635](https://github.com/kubernetes/kubernetes/pull/87635), [@feiskyer](https://github.com/feiskyer)) [SIG Cloud Provider] +- Fix regression in statefulset conversion which prevented applying a statefulset multiple times. ([#87706](https://github.com/kubernetes/kubernetes/pull/87706), [@liggitt](https://github.com/liggitt)) [SIG Apps, and SIG Testing] +- fixed two scheduler metrics (pending_pods and schedule_attempts_total) not being recorded ([#87692](https://github.com/kubernetes/kubernetes/pull/87692), [@everpeace](https://github.com/everpeace)) [SIG Scheduling] +- Resolved a performance issue in the node authorizer index maintenance. ([#87693](https://github.com/kubernetes/kubernetes/pull/87693), [@liggitt](https://github.com/liggitt)) [SIG Auth] +- Removed the 'client' label from apiserver_request_total. ([#87669](https://github.com/kubernetes/kubernetes/pull/87669), [@logicalhan](https://github.com/logicalhan)) [SIG API Machinery, and SIG Instrumentation] +- `(*"k8s.io/client-go/rest".Request).{Do,DoRaw,Stream,Watch}` now require callers to pass a `context.Context` as an argument. The context is used for timeout and cancellation signaling and to pass supplementary information to round trippers in the wrapped transport chain. If you don't need any of this functionality, it is sufficient to pass a context created with `context.Background()` to these functions. The `(*"k8s.io/client-go/rest".Request).Context` method is removed now that all methods that execute a request accept a context directly. ([#87597](https://github.com/kubernetes/kubernetes/pull/87597), [@mikedanese](https://github.com/mikedanese)) [SIG API Machinery, SIG Apps, SIG Auth, SIG Autoscaling, SIG CLI, SIG Cloud Provider, SIG Cluster Lifecycle, SIG Instrumentation, SIG Network, SIG Node, SIG Scheduling, SIG Storage, and SIG Testing] +- For volumes that allow attaches across multiple nodes, attach and detach operations across different nodes are now executed in parallel. ([#87258](https://github.com/kubernetes/kubernetes/pull/87258), [@verult](https://github.com/verult)) [SIG Apps, SIG Node, and SIG Storage] +- kubeadm: apply further improvements to the tentative support for concurrent etcd member join. Fixes a bug where multiple members can receive the same hostname. Increase the etcd client dial timeout and retry timeout for add/remove/... operations. ([#87505](https://github.com/kubernetes/kubernetes/pull/87505), [@neolit123](https://github.com/neolit123)) [SIG Cluster Lifecycle] +- Reverted a kubectl azure auth module change where oidc claim spn: prefix was omitted resulting a breaking behavior with existing Azure AD OIDC enabled api-server ([#87507](https://github.com/kubernetes/kubernetes/pull/87507), [@weinong](https://github.com/weinong)) [SIG API Machinery, SIG Auth, and SIG Cloud Provider] +- Update cri-tools to v1.17.0 ([#86305](https://github.com/kubernetes/kubernetes/pull/86305), [@saschagrunert](https://github.com/saschagrunert)) [SIG Cluster Lifecycle, and SIG Release] +- kubeadm: remove the deprecated CoreDNS feature-gate. It was set to "true" since v1.11 when the feature went GA. In v1.13 it was marked as deprecated and hidden from the CLI. ([#87400](https://github.com/kubernetes/kubernetes/pull/87400), [@neolit123](https://github.com/neolit123)) [SIG Cluster Lifecycle] +- Shared informers are now more reliable in the face of network disruption. ([#86015](https://github.com/kubernetes/kubernetes/pull/86015), [@squeed](https://github.com/squeed)) [SIG API Machinery] +- the CSR signing cert/key pairs will be reloaded from disk like the kube-apiserver cert/key pairs ([#86816](https://github.com/kubernetes/kubernetes/pull/86816), [@deads2k](https://github.com/deads2k)) [SIG API Machinery, SIG Apps, and SIG Auth] +- "kubectl describe statefulsets.apps" prints garbage for rolling update partition ([#85846](https://github.com/kubernetes/kubernetes/pull/85846), [@phil9909](https://github.com/phil9909)) [SIG CLI] + + +<!-- NEW RELEASE NOTES ENTRY --> + + +# v1.18.0-alpha.2 + +[Documentation](https://docs.k8s.io) + +## Downloads for v1.18.0-alpha.2 + + +filename | sha512 hash +-------- | ----------- +[kubernetes.tar.gz](https://dl.k8s.io/v1.18.0-alpha.2/kubernetes.tar.gz) | `7af83386b4b35353f0aa1bdaf73599eb08b1d1ca11ecc2c606854aff754db69f3cd3dc761b6d7fc86f01052f615ca53185f33dbf9e53b2f926b0f02fc103fbd3` +[kubernetes-src.tar.gz](https://dl.k8s.io/v1.18.0-alpha.2/kubernetes-src.tar.gz) | `a14b02a0a0bde97795a836a8f5897b0ee6b43e010e13e43dd4cca80a5b962a1ef3704eedc7916fed1c38ec663a71db48c228c91e5daacba7d9370df98c7ddfb6` + +### Client Binaries + +filename | sha512 hash +-------- | ----------- +[kubernetes-client-darwin-386.tar.gz](https://dl.k8s.io/v1.18.0-alpha.2/kubernetes-client-darwin-386.tar.gz) | `427f214d47ded44519007de2ae87160c56c2920358130e474b768299751a9affcbc1b1f0f936c39c6138837bca2a97792a6700896976e98c4beee8a1944cfde1` +[kubernetes-client-darwin-amd64.tar.gz](https://dl.k8s.io/v1.18.0-alpha.2/kubernetes-client-darwin-amd64.tar.gz) | `861fd81ac3bd45765575bedf5e002a2294aba48ef9e15980fc7d6783985f7d7fcde990ea0aef34690977a88df758722ec0a2e170d5dcc3eb01372e64e5439192` +[kubernetes-client-linux-386.tar.gz](https://dl.k8s.io/v1.18.0-alpha.2/kubernetes-client-linux-386.tar.gz) | `7d59b05d6247e2606a8321c72cd239713373d876dbb43b0fb7f1cb857fa6c998038b41eeed78d9eb67ce77b0b71776ceed428cce0f8d2203c5181b473e0bd86c` +[kubernetes-client-linux-amd64.tar.gz](https://dl.k8s.io/v1.18.0-alpha.2/kubernetes-client-linux-amd64.tar.gz) | `7cdefb4e32bad9d2df5bb8e7e0a6f4dab2ae6b7afef5d801ac5c342d4effdeacd799081fa2dec699ecf549200786c7623c3176252010f12494a95240dd63311d` +[kubernetes-client-linux-arm.tar.gz](https://dl.k8s.io/v1.18.0-alpha.2/kubernetes-client-linux-arm.tar.gz) | `6212bbf0fa1d01ced77dcca2c4b76b73956cd3c6b70e0701c1fe0df5ff37160835f6b84fa2481e0e6979516551b14d8232d1c72764a559a3652bfe2a1e7488ff` +[kubernetes-client-linux-arm64.tar.gz](https://dl.k8s.io/v1.18.0-alpha.2/kubernetes-client-linux-arm64.tar.gz) | `1f0d9990700510165ee471acb2f88222f1b80e8f6deb351ce14cf50a70a9840fb99606781e416a13231c74b2bd7576981b5348171aa33b628d2666e366cd4629` +[kubernetes-client-linux-ppc64le.tar.gz](https://dl.k8s.io/v1.18.0-alpha.2/kubernetes-client-linux-ppc64le.tar.gz) | `77e00ba12a32db81e96f8de84609de93f32c61bb3f53875a57496d213aa6d1b92c09ad5a6de240a78e1a5bf77fac587ff92874f34a10f8909ae08ca32fda45d2` +[kubernetes-client-linux-s390x.tar.gz](https://dl.k8s.io/v1.18.0-alpha.2/kubernetes-client-linux-s390x.tar.gz) | `a39ec2044bed5a4570e9c83068e0fc0ce923ccffa44380f8bbc3247426beaff79c8a84613bcb58b05f0eb3afbc34c79fe3309aa2e0b81abcfd0aa04770e62e05` +[kubernetes-client-windows-386.tar.gz](https://dl.k8s.io/v1.18.0-alpha.2/kubernetes-client-windows-386.tar.gz) | `1a0ab88f9b7e34b60ab31d5538e97202a256ad8b7b7ed5070cae5f2f12d5d4edeae615db7a34ebbe254004b6393c6b2480100b09e30e59c9139492a3019a596a` +[kubernetes-client-windows-amd64.tar.gz](https://dl.k8s.io/v1.18.0-alpha.2/kubernetes-client-windows-amd64.tar.gz) | `1966eb5dfb78c1bc33aaa6389f32512e3aa92584250a0164182f3566c81d901b59ec78ee4e25df658bc1dd221b5a9527d6ce3b6c487ca3e3c0b319a077caa735` + +### Server Binaries + +filename | sha512 hash +-------- | ----------- +[kubernetes-server-linux-amd64.tar.gz](https://dl.k8s.io/v1.18.0-alpha.2/kubernetes-server-linux-amd64.tar.gz) | `f814d6a3872e4572aa4da297c29def4c1fad8eba0903946780b6bf9788c72b99d71085c5aef9e12c01133b26fa4563c1766ba724ad2a8af2670a24397951a94d` +[kubernetes-server-linux-arm.tar.gz](https://dl.k8s.io/v1.18.0-alpha.2/kubernetes-server-linux-arm.tar.gz) | `56aa08225e546c92c2ff88ac57d3db7dd5e63640772ea72a429f080f7069827138cbc206f6f5fe3a0c01bfca043a9eda305ecdc1dcb864649114893e46b6dc84` +[kubernetes-server-linux-arm64.tar.gz](https://dl.k8s.io/v1.18.0-alpha.2/kubernetes-server-linux-arm64.tar.gz) | `fb87128d905211ba097aa860244a376575ae2edbaca6e51402a24bc2964854b9b273e09df3d31a2bcffc91509f7eecb2118b183fb0e0eb544f33403fa235c274` +[kubernetes-server-linux-ppc64le.tar.gz](https://dl.k8s.io/v1.18.0-alpha.2/kubernetes-server-linux-ppc64le.tar.gz) | `6d21fbf39b9d3a0df9642407d6f698fabdc809aca83af197bceb58a81b25846072f407f8fb7caae2e02dc90912e3e0f5894f062f91bcb69f8c2329625d3dfeb7` +[kubernetes-server-linux-s390x.tar.gz](https://dl.k8s.io/v1.18.0-alpha.2/kubernetes-server-linux-s390x.tar.gz) | `ddcda4dc360ca97705f71bf2a18ddacd7b7ddf77535b62e699e97a1b2dd24843751313351d0112e238afe69558e8271eba4d27ab77bb67b4b9e3fbde6eec85c9` + +### Node Binaries + +filename | sha512 hash +-------- | ----------- +[kubernetes-node-linux-amd64.tar.gz](https://dl.k8s.io/v1.18.0-alpha.2/kubernetes-node-linux-amd64.tar.gz) | `78915a9bde35c70c67014f0cea8754849db4f6a84491a3ad9678fd3bc0203e43af5a63cfafe104ae1d56b05ce74893a87a6dcd008d7859e1af6b3bce65425b5d` +[kubernetes-node-linux-arm.tar.gz](https://dl.k8s.io/v1.18.0-alpha.2/kubernetes-node-linux-arm.tar.gz) | `3218e811abcb0cb09d80742def339be3916db5e9bbc62c0dc8e6d87085f7e3d9eeed79dea081906f1de78ddd07b7e3acdbd7765fdb838d262bb35602fd1df106` +[kubernetes-node-linux-arm64.tar.gz](https://dl.k8s.io/v1.18.0-alpha.2/kubernetes-node-linux-arm64.tar.gz) | `fa22de9c4440b8fb27f4e77a5a63c5e1c8aa8aa30bb79eda843b0f40498c21b8c0ad79fff1d841bb9fef53fe20da272506de9a86f81a0b36d028dbeab2e482ce` +[kubernetes-node-linux-ppc64le.tar.gz](https://dl.k8s.io/v1.18.0-alpha.2/kubernetes-node-linux-ppc64le.tar.gz) | `bbda9b5cc66e8f13d235703b2a85e2c4f02fa16af047be4d27a3e198e11eb11706e4a0fbb6c20978c770b069cd4cd9894b661f09937df9d507411548c36576e0` +[kubernetes-node-linux-s390x.tar.gz](https://dl.k8s.io/v1.18.0-alpha.2/kubernetes-node-linux-s390x.tar.gz) | `b2ed1eda013069adce2aac00b86d75b84e006cfce9bafac0b5a2bafcb60f8f2cb346b5ea44eafa72d777871abef1ea890eb3a2a05de28968f9316fa88886a8ed` +[kubernetes-node-windows-amd64.tar.gz](https://dl.k8s.io/v1.18.0-alpha.2/kubernetes-node-windows-amd64.tar.gz) | `bd8eb23dba711f31b5148257076b1bbe9629f2a75de213b2c779bd5b29279e9bf22f8bde32f4bc814f4c0cc49e19671eb8b24f4105f0fe2c1490c4b78ec3c704` + +## Changelog since v1.18.0-alpha.1 + +### Other notable changes + +* Bump golang/mock version to v1.3.1 ([#87326](https://github.com/kubernetes/kubernetes/pull/87326), [@wawa0210](https://github.com/wawa0210)) +* fix a bug that orphan revision cannot be adopted and statefulset cannot be synced ([#86801](https://github.com/kubernetes/kubernetes/pull/86801), [@likakuli](https://github.com/likakuli)) +* Azure storage clients now suppress requests on throttling ([#87306](https://github.com/kubernetes/kubernetes/pull/87306), [@feiskyer](https://github.com/feiskyer)) +* Introduce Alpha field `Immutable` in both Secret and ConfigMap objects to mark their contents as immutable. The implementation is hidden behind feature gate `ImmutableEphemeralVolumes` (currently in Alpha stage). ([#86377](https://github.com/kubernetes/kubernetes/pull/86377), [@wojtek-t](https://github.com/wojtek-t)) +* EndpointSlices will now be enabled by default. A new `EndpointSliceProxying` feature gate determines if kube-proxy will use EndpointSlices, this is disabled by default. ([#86137](https://github.com/kubernetes/kubernetes/pull/86137), [@robscott](https://github.com/robscott)) +* kubeadm upgrades always persist the etcd backup for stacked ([#86861](https://github.com/kubernetes/kubernetes/pull/86861), [@SataQiu](https://github.com/SataQiu)) +* Fix the bug PIP's DNS is deleted if no DNS label service annotation isn't set. ([#87246](https://github.com/kubernetes/kubernetes/pull/87246), [@nilo19](https://github.com/nilo19)) +* New flag `--show-hidden-metrics-for-version` in kube-controller-manager can be used to show all hidden metrics that deprecated in the previous minor release. ([#85281](https://github.com/kubernetes/kubernetes/pull/85281), [@RainbowMango](https://github.com/RainbowMango)) +* Azure network and VM clients now suppress requests on throttling ([#87122](https://github.com/kubernetes/kubernetes/pull/87122), [@feiskyer](https://github.com/feiskyer)) +* `kubectl apply -f <file> --prune -n <namespace>` should prune all resources not defined in the file in the cli specified namespace. ([#85613](https://github.com/kubernetes/kubernetes/pull/85613), [@MartinKaburu](https://github.com/MartinKaburu)) +* Fixes service account token admission error in clusters that do not run the service account token controller ([#87029](https://github.com/kubernetes/kubernetes/pull/87029), [@liggitt](https://github.com/liggitt)) +* CustomResourceDefinition status fields are no longer required for client validation when submitting manifests. ([#87213](https://github.com/kubernetes/kubernetes/pull/87213), [@hasheddan](https://github.com/hasheddan)) +* All apiservers log request lines in a more greppable format. ([#87203](https://github.com/kubernetes/kubernetes/pull/87203), [@lavalamp](https://github.com/lavalamp)) +* provider/azure: Network security groups can now be in a separate resource group. ([#87035](https://github.com/kubernetes/kubernetes/pull/87035), [@CecileRobertMichon](https://github.com/CecileRobertMichon)) +* Cleaned up the output from `kubectl describe CSINode <name>`. ([#85283](https://github.com/kubernetes/kubernetes/pull/85283), [@huffmanca](https://github.com/huffmanca)) +* Fixed the following ([#84265](https://github.com/kubernetes/kubernetes/pull/84265), [@bhagwat070919](https://github.com/bhagwat070919)) + * - AWS Cloud Provider attempts to delete LoadBalancer security group it didn’t provision + * - AWS Cloud Provider creates default LoadBalancer security group even if annotation [service.beta.kubernetes.io/aws-load-balancer-security-groups] is present +* kubelet: resource metrics endpoint `/metrics/resource/v1alpha1` as well as all metrics under this endpoint have been deprecated. ([#86282](https://github.com/kubernetes/kubernetes/pull/86282), [@RainbowMango](https://github.com/RainbowMango)) + * Please convert to the following metrics emitted by endpoint `/metrics/resource`: + * - scrape_error --> scrape_error + * - node_cpu_usage_seconds_total --> node_cpu_usage_seconds + * - node_memory_working_set_bytes --> node_memory_working_set_bytes + * - container_cpu_usage_seconds_total --> container_cpu_usage_seconds + * - container_memory_working_set_bytes --> container_memory_working_set_bytes + * - scrape_error --> scrape_error +* You can now pass "--node-ip ::" to kubelet to indicate that it should autodetect an IPv6 address to use as the node's primary address. ([#85850](https://github.com/kubernetes/kubernetes/pull/85850), [@danwinship](https://github.com/danwinship)) +* kubeadm: support automatic retry after failing to pull image ([#86899](https://github.com/kubernetes/kubernetes/pull/86899), [@SataQiu](https://github.com/SataQiu)) +* TODO ([#87044](https://github.com/kubernetes/kubernetes/pull/87044), [@jennybuckley](https://github.com/jennybuckley)) +* Improved yaml parsing performance ([#85458](https://github.com/kubernetes/kubernetes/pull/85458), [@cjcullen](https://github.com/cjcullen)) +* Fixed a bug which could prevent a provider ID from ever being set for node if an error occurred determining the provider ID when the node was added. ([#87043](https://github.com/kubernetes/kubernetes/pull/87043), [@zjs](https://github.com/zjs)) +* fix a regression in kubenet that prevent pods to obtain ip addresses ([#85993](https://github.com/kubernetes/kubernetes/pull/85993), [@chendotjs](https://github.com/chendotjs)) +* Bind kube-dns containers to linux nodes to avoid Windows scheduling ([#83358](https://github.com/kubernetes/kubernetes/pull/83358), [@wawa0210](https://github.com/wawa0210)) +* The following features are unconditionally enabled and the corresponding `--feature-gates` flags have been removed: `PodPriority`, `TaintNodesByCondition`, `ResourceQuotaScopeSelectors` and `ScheduleDaemonSetPods` ([#86210](https://github.com/kubernetes/kubernetes/pull/86210), [@draveness](https://github.com/draveness)) +* Bind dns-horizontal containers to linux nodes to avoid Windows scheduling on kubernetes cluster includes linux nodes and windows nodes ([#83364](https://github.com/kubernetes/kubernetes/pull/83364), [@wawa0210](https://github.com/wawa0210)) +* fix kubectl annotate error when local=true is set ([#86952](https://github.com/kubernetes/kubernetes/pull/86952), [@zhouya0](https://github.com/zhouya0)) +* Bug fixes: ([#84163](https://github.com/kubernetes/kubernetes/pull/84163), [@david-tigera](https://github.com/david-tigera)) + * Make sure we include latest packages node #351 ([@caseydavenport](https://github.com/caseydavenport)) +* fix kuebctl apply set-last-applied namespaces error ([#86474](https://github.com/kubernetes/kubernetes/pull/86474), [@zhouya0](https://github.com/zhouya0)) +* Add VolumeBinder method to FrameworkHandle interface, which allows user to get the volume binder when implementing scheduler framework plugins. ([#86940](https://github.com/kubernetes/kubernetes/pull/86940), [@skilxn-go](https://github.com/skilxn-go)) +* elasticsearch supports automatically setting the advertise address ([#85944](https://github.com/kubernetes/kubernetes/pull/85944), [@SataQiu](https://github.com/SataQiu)) +* If a serving certificates param specifies a name that is an IP for an SNI certificate, it will have priority for replying to server connections. ([#85308](https://github.com/kubernetes/kubernetes/pull/85308), [@deads2k](https://github.com/deads2k)) +* kube-proxy: Added dual-stack IPv4/IPv6 support to the iptables proxier. ([#82462](https://github.com/kubernetes/kubernetes/pull/82462), [@vllry](https://github.com/vllry)) +* Azure VMSS/VMSSVM clients now suppress requests on throttling ([#86740](https://github.com/kubernetes/kubernetes/pull/86740), [@feiskyer](https://github.com/feiskyer)) +* New metric kubelet_pleg_last_seen_seconds to aid diagnosis of PLEG not healthy issues. ([#86251](https://github.com/kubernetes/kubernetes/pull/86251), [@bboreham](https://github.com/bboreham)) +* For subprotocol negotiation, both client and server protocol is required now. ([#86646](https://github.com/kubernetes/kubernetes/pull/86646), [@tedyu](https://github.com/tedyu)) +* kubeadm: use bind-address option to configure the kube-controller-manager and kube-scheduler http probes ([#86493](https://github.com/kubernetes/kubernetes/pull/86493), [@aojea](https://github.com/aojea)) +* Marked scheduler's metrics scheduling_algorithm_predicate_evaluation_seconds and ([#86584](https://github.com/kubernetes/kubernetes/pull/86584), [@xiaoanyunfei](https://github.com/xiaoanyunfei)) + * scheduling_algorithm_priority_evaluation_seconds as deprecated. Those are replaced by framework_extension_point_duration_seconds[extenstion_point="Filter"] and framework_extension_point_duration_seconds[extenstion_point="Score"] respectively. +* Marked scheduler's scheduling_duration_seconds Summary metric as deprecated ([#86586](https://github.com/kubernetes/kubernetes/pull/86586), [@xiaoanyunfei](https://github.com/xiaoanyunfei)) +* Add instructions about how to bring up e2e test cluster ([#85836](https://github.com/kubernetes/kubernetes/pull/85836), [@YangLu1031](https://github.com/YangLu1031)) +* If a required flag is not provided to a command, the user will only see the required flag error message, instead of the entire usage menu. ([#86693](https://github.com/kubernetes/kubernetes/pull/86693), [@sallyom](https://github.com/sallyom)) +* kubeadm: tolerate whitespace when validating certificate authority PEM data in kubeconfig files ([#86705](https://github.com/kubernetes/kubernetes/pull/86705), [@neolit123](https://github.com/neolit123)) +* kubeadm: add support for the "ci/k8s-master" version label as a replacement for "ci-cross/*", which no longer exists. ([#86609](https://github.com/kubernetes/kubernetes/pull/86609), [@Pensu](https://github.com/Pensu)) +* Fix EndpointSlice controller race condition and ensure that it handles external changes to EndpointSlices. ([#85703](https://github.com/kubernetes/kubernetes/pull/85703), [@robscott](https://github.com/robscott)) +* Fix nil pointer dereference in azure cloud provider ([#85975](https://github.com/kubernetes/kubernetes/pull/85975), [@ldx](https://github.com/ldx)) +* fix: azure disk could not mounted on Standard_DC4s/DC2s instances ([#86612](https://github.com/kubernetes/kubernetes/pull/86612), [@andyzhangx](https://github.com/andyzhangx)) +* Fixes v1.17.0 regression in --service-cluster-ip-range handling with IPv4 ranges larger than 65536 IP addresses ([#86534](https://github.com/kubernetes/kubernetes/pull/86534), [@liggitt](https://github.com/liggitt)) +* Adds back support for AlwaysCheckAllPredicates flag. ([#86496](https://github.com/kubernetes/kubernetes/pull/86496), [@ahg-g](https://github.com/ahg-g)) +* Azure global rate limit is switched to per-client. A set of new rate limit configure options are introduced, including routeRateLimit, SubnetsRateLimit, InterfaceRateLimit, RouteTableRateLimit, LoadBalancerRateLimit, PublicIPAddressRateLimit, SecurityGroupRateLimit, VirtualMachineRateLimit, StorageAccountRateLimit, DiskRateLimit, SnapshotRateLimit, VirtualMachineScaleSetRateLimit and VirtualMachineSizeRateLimit. ([#86515](https://github.com/kubernetes/kubernetes/pull/86515), [@feiskyer](https://github.com/feiskyer)) + * The original rate limit options would be default values for those new client's rate limiter. +* Fix issue [#85805](https://github.com/kubernetes/kubernetes/pull/85805) about resource not found in azure cloud provider when lb specified in other resource group. ([#86502](https://github.com/kubernetes/kubernetes/pull/86502), [@levimm](https://github.com/levimm)) +* `AlwaysCheckAllPredicates` is deprecated in scheduler Policy API. ([#86369](https://github.com/kubernetes/kubernetes/pull/86369), [@Huang-Wei](https://github.com/Huang-Wei)) +* Kubernetes KMS provider for data encryption now supports disabling the in-memory data encryption key (DEK) cache by setting cachesize to a negative value. ([#86294](https://github.com/kubernetes/kubernetes/pull/86294), [@enj](https://github.com/enj)) +* option `preConfiguredBackendPoolLoadBalancerTypes` is added to azure cloud provider for the pre-configured load balancers, possible values: `""`, `"internal"`, "external"`, `"all"` ([#86338](https://github.com/kubernetes/kubernetes/pull/86338), [@gossion](https://github.com/gossion)) +* Promote StartupProbe to beta for 1.18 release ([#83437](https://github.com/kubernetes/kubernetes/pull/83437), [@matthyx](https://github.com/matthyx)) +* Fixes issue where AAD token obtained by kubectl is incompatible with on-behalf-of flow and oidc. ([#86412](https://github.com/kubernetes/kubernetes/pull/86412), [@weinong](https://github.com/weinong)) + * The audience claim before this fix has "spn:" prefix. After this fix, "spn:" prefix is omitted. +* change CounterVec to Counter about PLEGDiscardEvent ([#86167](https://github.com/kubernetes/kubernetes/pull/86167), [@yiyang5055](https://github.com/yiyang5055)) +* hollow-node do not use remote CRI anymore ([#86425](https://github.com/kubernetes/kubernetes/pull/86425), [@jkaniuk](https://github.com/jkaniuk)) +* hollow-node use fake CRI ([#85879](https://github.com/kubernetes/kubernetes/pull/85879), [@gongguan](https://github.com/gongguan)) + + + +# v1.18.0-alpha.1 + +[Documentation](https://docs.k8s.io) + +## Downloads for v1.18.0-alpha.1 + + +filename | sha512 hash +-------- | ----------- +[kubernetes.tar.gz](https://dl.k8s.io/v1.18.0-alpha.1/kubernetes.tar.gz) | `0c4904efc7f4f1436119c91dc1b6c93b3bd9c7490362a394bff10099c18e1e7600c4f6e2fcbaeb2d342a36c4b20692715cf7aa8ada6dfac369f44cc9292529d7` +[kubernetes-src.tar.gz](https://dl.k8s.io/v1.18.0-alpha.1/kubernetes-src.tar.gz) | `0a50fc6816c730ca5ae4c4f26d5ad7b049607d29f6a782a4e5b4b05ac50e016486e269dafcc6a163bd15e1a192780a9a987f1bb959696993641c603ed1e841c8` + +### Client Binaries + +filename | sha512 hash +-------- | ----------- +[kubernetes-client-darwin-386.tar.gz](https://dl.k8s.io/v1.18.0-alpha.1/kubernetes-client-darwin-386.tar.gz) | `c6d75f7f3f20bef17fc7564a619b54e6f4a673d041b7c9ec93663763a1cc8dd16aecd7a2af70e8d54825a0eecb9762cf2edfdade840604c9a32ecd9cc2d5ac3c` +[kubernetes-client-darwin-amd64.tar.gz](https://dl.k8s.io/v1.18.0-alpha.1/kubernetes-client-darwin-amd64.tar.gz) | `ca1f19db289933beace6daee6fc30af19b0e260634ef6e89f773464a05e24551c791be58b67da7a7e2a863e28b7cbcc7b24b6b9bf467113c26da76ac8f54fdb6` +[kubernetes-client-linux-386.tar.gz](https://dl.k8s.io/v1.18.0-alpha.1/kubernetes-client-linux-386.tar.gz) | `af2e673653eb39c3f24a54efc68e1055f9258bdf6cf8fea42faf42c05abefc2da853f42faac3b166c37e2a7533020b8993b98c0d6d80a5b66f39e91d8ae0a3fb` +[kubernetes-client-linux-amd64.tar.gz](https://dl.k8s.io/v1.18.0-alpha.1/kubernetes-client-linux-amd64.tar.gz) | `9009032c3f94ac8a78c1322a28e16644ce3b20989eb762685a1819148aed6e883ca8e1200e5ec37ec0853f115c67e09b5d697d6cf5d4c45f653788a2d3a2f84f` +[kubernetes-client-linux-arm.tar.gz](https://dl.k8s.io/v1.18.0-alpha.1/kubernetes-client-linux-arm.tar.gz) | `afba9595b37a3f2eead6e3418573f7ce093b55467dce4da0b8de860028576b96b837a2fd942f9c276e965da694e31fbd523eeb39aefb902d7e7a2f169344d271` +[kubernetes-client-linux-arm64.tar.gz](https://dl.k8s.io/v1.18.0-alpha.1/kubernetes-client-linux-arm64.tar.gz) | `04fc3b2fe3f271807f0bc6c61be52456f26a1af904964400be819b7914519edc72cbab9afab2bb2e2ba1a108963079367cedfb253c9364c0175d1fcc64d52f5c` +[kubernetes-client-linux-ppc64le.tar.gz](https://dl.k8s.io/v1.18.0-alpha.1/kubernetes-client-linux-ppc64le.tar.gz) | `04c7edab874b33175ff7bebfff5b3a032bc6eb088fcd7387ffcd5b3fa71395ca8c5f9427b7ddb496e92087dfdb09eaf14a46e9513071d3bd73df76c182922d38` +[kubernetes-client-linux-s390x.tar.gz](https://dl.k8s.io/v1.18.0-alpha.1/kubernetes-client-linux-s390x.tar.gz) | `499287dbbc33399a37b9f3b35e0124ff20b17b6619f25a207ee9c606ef261af61fa0c328dde18c7ce2d3dfb2eea2376623bc3425d16bc8515932a68b44f8bede` +[kubernetes-client-windows-386.tar.gz](https://dl.k8s.io/v1.18.0-alpha.1/kubernetes-client-windows-386.tar.gz) | `cf84aeddf00f126fb13c0436b116dd0464a625659e44c84bf863517db0406afb4eefd86807e7543c4f96006d275772fbf66214ae7d582db5865c84ac3545b3e6` +[kubernetes-client-windows-amd64.tar.gz](https://dl.k8s.io/v1.18.0-alpha.1/kubernetes-client-windows-amd64.tar.gz) | `69f20558ccd5cd6dbaccf29307210db4e687af21f6d71f68c69d3a39766862686ac1333ab8a5012010ca5c5e3c11676b45e498e3d4c38773da7d24bcefc46d95` + +### Server Binaries + +filename | sha512 hash +-------- | ----------- +[kubernetes-server-linux-amd64.tar.gz](https://dl.k8s.io/v1.18.0-alpha.1/kubernetes-server-linux-amd64.tar.gz) | `3f29df2ce904a0f10db4c1d7a425a36f420867b595da3fa158ae430bfead90def2f2139f51425b349faa8a9303dcf20ea01657cb6ea28eb6ad64f5bb32ce2ed1` +[kubernetes-server-linux-arm.tar.gz](https://dl.k8s.io/v1.18.0-alpha.1/kubernetes-server-linux-arm.tar.gz) | `4a21073b2273d721fbf062c254840be5c8471a010bcc0c731b101729e36e61f637cb7fcb521a22e8d24808510242f4fff8a6ca40f10e9acd849c2a47bf135f27` +[kubernetes-server-linux-arm64.tar.gz](https://dl.k8s.io/v1.18.0-alpha.1/kubernetes-server-linux-arm64.tar.gz) | `7f1cb6d721bedc90e28b16f99bea7e59f5ad6267c31ef39c14d34db6ad6aad87ee51d2acdd01b6903307c1c00b58ff6b785a03d5a491cc3f8a4df9a1d76d406c` +[kubernetes-server-linux-ppc64le.tar.gz](https://dl.k8s.io/v1.18.0-alpha.1/kubernetes-server-linux-ppc64le.tar.gz) | `8f2b552030b5274b1c2c7c166eacd5a14b0c6ca0f23042f4c52efe87e22a167ba4460dcd66615a5ecd26d9e88336be1fb555548392e70efe59070dd2c314da98` +[kubernetes-server-linux-s390x.tar.gz](https://dl.k8s.io/v1.18.0-alpha.1/kubernetes-server-linux-s390x.tar.gz) | `8d9f2c96f66edafb7c8b3aa90960d29b41471743842aede6b47b3b2e61f4306fb6fc60b9ebc18820c547ee200bfedfe254c1cde962d447c791097dd30e79abdb` + +### Node Binaries + +filename | sha512 hash +-------- | ----------- +[kubernetes-node-linux-amd64.tar.gz](https://dl.k8s.io/v1.18.0-alpha.1/kubernetes-node-linux-amd64.tar.gz) | `84194cb081d1502f8ca68143569f9707d96f1a28fcf0c574ebd203321463a8b605f67bb2a365eaffb14fbeb8d55c8d3fa17431780b242fb9cba3a14426a0cd4a` +[kubernetes-node-linux-arm.tar.gz](https://dl.k8s.io/v1.18.0-alpha.1/kubernetes-node-linux-arm.tar.gz) | `0091e108ab94fd8683b89c597c4fdc2fbf4920b007cfcd5297072c44bc3a230dfe5ceed16473e15c3e6cf5edab866d7004b53edab95be0400cc60e009eee0d9d` +[kubernetes-node-linux-arm64.tar.gz](https://dl.k8s.io/v1.18.0-alpha.1/kubernetes-node-linux-arm64.tar.gz) | `b7e85682cc2848a35d52fd6f01c247f039ee1b5dd03345713821ea10a7fa9939b944f91087baae95eaa0665d11857c1b81c454f720add077287b091f9f19e5d3` +[kubernetes-node-linux-ppc64le.tar.gz](https://dl.k8s.io/v1.18.0-alpha.1/kubernetes-node-linux-ppc64le.tar.gz) | `cd1f0849e9c62b5d2c93ff0cebf58843e178d8a88317f45f76de0db5ae020b8027e9503a5fccc96445184e0d77ecdf6f57787176ac31dbcbd01323cd0a190cbb` +[kubernetes-node-linux-s390x.tar.gz](https://dl.k8s.io/v1.18.0-alpha.1/kubernetes-node-linux-s390x.tar.gz) | `e1e697a34424c75d75415b613b81c8af5f64384226c5152d869f12fd7db1a3e25724975b73fa3d89e56e4bf78d5fd07e68a709ba8566f53691ba6a88addc79ea` +[kubernetes-node-windows-amd64.tar.gz](https://dl.k8s.io/v1.18.0-alpha.1/kubernetes-node-windows-amd64.tar.gz) | `c725a19a4013c74e22383ad3fb4cb799b3e161c4318fdad066daf806730a89bc3be3ff0f75678d02b3cbe52b2ef0c411c0639968e200b9df470be40bb2c015cc` + +## Changelog since v1.17.0 + +### Action Required + +* action required ([#85363](https://github.com/kubernetes/kubernetes/pull/85363), [@immutableT](https://github.com/immutableT)) + * 1. Currently, if users were to explicitly specify CacheSize of 0 for KMS provider, they would end-up with a provider that caches up to 1000 keys. This PR changes this behavior. + * Post this PR, when users supply 0 for CacheSize this will result in a validation error. + * 2. CacheSize type was changed from int32 to *int32. This allows defaulting logic to differentiate between cases where users explicitly supplied 0 vs. not supplied any value. + * 3. KMS Provider's endpoint (path to Unix socket) is now validated when the EncryptionConfiguration files is loaded. This used to be handled by the GRPCService. + +### Other notable changes + +* fix: azure data disk should use same key as os disk by default ([#86351](https://github.com/kubernetes/kubernetes/pull/86351), [@andyzhangx](https://github.com/andyzhangx)) +* New flag `--show-hidden-metrics-for-version` in kube-proxy can be used to show all hidden metrics that deprecated in the previous minor release. ([#85279](https://github.com/kubernetes/kubernetes/pull/85279), [@RainbowMango](https://github.com/RainbowMango)) +* Remove cluster-monitoring addon ([#85512](https://github.com/kubernetes/kubernetes/pull/85512), [@serathius](https://github.com/serathius)) +* Changed core_pattern on COS nodes to be an absolute path. ([#86329](https://github.com/kubernetes/kubernetes/pull/86329), [@mml](https://github.com/mml)) +* Track mount operations as uncertain if operation fails with non-final error ([#82492](https://github.com/kubernetes/kubernetes/pull/82492), [@gnufied](https://github.com/gnufied)) +* add kube-proxy flags --ipvs-tcp-timeout, --ipvs-tcpfin-timeout, --ipvs-udp-timeout to configure IPVS connection timeouts. ([#85517](https://github.com/kubernetes/kubernetes/pull/85517), [@andrewsykim](https://github.com/andrewsykim)) +* The sample-apiserver aggregated conformance test has updated to use the Kubernetes v1.17.0 sample apiserver ([#84735](https://github.com/kubernetes/kubernetes/pull/84735), [@liggitt](https://github.com/liggitt)) +* The underlying format of the `CPUManager` state file has changed. Upgrades should be seamless, but any third-party tools that rely on reading the previous format need to be updated. ([#84462](https://github.com/kubernetes/kubernetes/pull/84462), [@klueska](https://github.com/klueska)) +* kubernetes will try to acquire the iptables lock every 100 msec during 5 seconds instead of every second. This specially useful for environments using kube-proxy in iptables mode with a high churn rate of services. ([#85771](https://github.com/kubernetes/kubernetes/pull/85771), [@aojea](https://github.com/aojea)) +* Fixed a panic in the kubelet cleaning up pod volumes ([#86277](https://github.com/kubernetes/kubernetes/pull/86277), [@tedyu](https://github.com/tedyu)) +* azure cloud provider cache TTL is configurable, list of the azure cloud provider is as following: ([#86266](https://github.com/kubernetes/kubernetes/pull/86266), [@zqingqing1](https://github.com/zqingqing1)) + * - "availabilitySetNodesCacheTTLInSeconds" + * - "vmssCacheTTLInSeconds" + * - "vmssVirtualMachinesCacheTTLInSeconds" + * - "vmCacheTTLInSeconds" + * - "loadBalancerCacheTTLInSeconds" + * - "nsgCacheTTLInSeconds" + * - "routeTableCacheTTLInSeconds" +* Fixes kube-proxy when EndpointSlice feature gate is enabled on Windows. ([#86016](https://github.com/kubernetes/kubernetes/pull/86016), [@robscott](https://github.com/robscott)) +* Fixes wrong validation result of NetworkPolicy PolicyTypes ([#85747](https://github.com/kubernetes/kubernetes/pull/85747), [@tnqn](https://github.com/tnqn)) +* Fixes an issue with kubelet-reported pod status on deleted/recreated pods. ([#86320](https://github.com/kubernetes/kubernetes/pull/86320), [@liggitt](https://github.com/liggitt)) +* kube-apiserver no longer serves the following deprecated APIs: ([#85903](https://github.com/kubernetes/kubernetes/pull/85903), [@liggitt](https://github.com/liggitt)) + * All resources under `apps/v1beta1` and `apps/v1beta2` - use `apps/v1` instead + * `daemonsets`, `deployments`, `replicasets` resources under `extensions/v1beta1` - use `apps/v1` instead + * `networkpolicies` resources under `extensions/v1beta1` - use `networking.k8s.io/v1` instead + * `podsecuritypolicies` resources under `extensions/v1beta1` - use `policy/v1beta1` instead +* kubeadm: fix potential panic when executing "kubeadm reset" with a corrupted kubelet.conf file ([#86216](https://github.com/kubernetes/kubernetes/pull/86216), [@neolit123](https://github.com/neolit123)) +* Fix a bug in port-forward: named port not working with service ([#85511](https://github.com/kubernetes/kubernetes/pull/85511), [@oke-py](https://github.com/oke-py)) +* kube-proxy no longer modifies shared EndpointSlices. ([#86092](https://github.com/kubernetes/kubernetes/pull/86092), [@robscott](https://github.com/robscott)) +* allow for configuration of CoreDNS replica count ([#85837](https://github.com/kubernetes/kubernetes/pull/85837), [@pickledrick](https://github.com/pickledrick)) +* Fixed a regression where the kubelet would fail to update the ready status of pods. ([#84951](https://github.com/kubernetes/kubernetes/pull/84951), [@tedyu](https://github.com/tedyu)) +* Resolves performance regression in client-go discovery clients constructed using `NewDiscoveryClientForConfig` or `NewDiscoveryClientForConfigOrDie`. ([#86168](https://github.com/kubernetes/kubernetes/pull/86168), [@liggitt](https://github.com/liggitt)) +* Make error message and service event message more clear ([#86078](https://github.com/kubernetes/kubernetes/pull/86078), [@feiskyer](https://github.com/feiskyer)) +* e2e-test-framework: add e2e test namespace dump if all tests succeed but the cleanup fails. ([#85542](https://github.com/kubernetes/kubernetes/pull/85542), [@schrodit](https://github.com/schrodit)) +* SafeSysctlWhitelist: add net.ipv4.ping_group_range ([#85463](https://github.com/kubernetes/kubernetes/pull/85463), [@AkihiroSuda](https://github.com/AkihiroSuda)) +* kubelet: the metric process_start_time_seconds be marked as with the ALPHA stability level. ([#85446](https://github.com/kubernetes/kubernetes/pull/85446), [@RainbowMango](https://github.com/RainbowMango)) +* API request throttling (due to a high rate of requests) is now reported in the kubelet (and other component) logs by default. The messages are of the form ([#80649](https://github.com/kubernetes/kubernetes/pull/80649), [@RobertKrawitz](https://github.com/RobertKrawitz)) + * Throttling request took 1.50705208s, request: GET:<URL> + * The presence of large numbers of these messages, particularly with long delay times, may indicate to the administrator the need to tune the cluster accordingly. +* Fix API Server potential memory leak issue in processing watch request. ([#85410](https://github.com/kubernetes/kubernetes/pull/85410), [@answer1991](https://github.com/answer1991)) +* Verify kubelet & kube-proxy can recover after being killed on Windows nodes ([#84886](https://github.com/kubernetes/kubernetes/pull/84886), [@YangLu1031](https://github.com/YangLu1031)) +* Fixed an issue that the scheduler only returns the first failure reason. ([#86022](https://github.com/kubernetes/kubernetes/pull/86022), [@Huang-Wei](https://github.com/Huang-Wei)) +* kubectl/drain: add skip-wait-for-delete-timeout option. ([#85577](https://github.com/kubernetes/kubernetes/pull/85577), [@michaelgugino](https://github.com/michaelgugino)) + * If pod DeletionTimestamp older than N seconds, skip waiting for the pod. Seconds must be greater than 0 to skip. +* Following metrics have been turned off: ([#83841](https://github.com/kubernetes/kubernetes/pull/83841), [@RainbowMango](https://github.com/RainbowMango)) + * - kubelet_pod_worker_latency_microseconds + * - kubelet_pod_start_latency_microseconds + * - kubelet_cgroup_manager_latency_microseconds + * - kubelet_pod_worker_start_latency_microseconds + * - kubelet_pleg_relist_latency_microseconds + * - kubelet_pleg_relist_interval_microseconds + * - kubelet_eviction_stats_age_microseconds + * - kubelet_runtime_operations + * - kubelet_runtime_operations_latency_microseconds + * - kubelet_runtime_operations_errors + * - kubelet_device_plugin_registration_count + * - kubelet_device_plugin_alloc_latency_microseconds + * - kubelet_docker_operations + * - kubelet_docker_operations_latency_microseconds + * - kubelet_docker_operations_errors + * - kubelet_docker_operations_timeout + * - network_plugin_operations_latency_microseconds +* - Renamed Kubelet metric certificate_manager_server_expiration_seconds to certificate_manager_server_ttl_seconds and changed to report the second until expiration at read time rather than absolute time of expiry. ([#85874](https://github.com/kubernetes/kubernetes/pull/85874), [@sambdavidson](https://github.com/sambdavidson)) + * - Improved accuracy of Kubelet metric rest_client_exec_plugin_ttl_seconds. +* Bind metadata-agent containers to linux nodes to avoid Windows scheduling on kubernetes cluster includes linux nodes and windows nodes ([#83363](https://github.com/kubernetes/kubernetes/pull/83363), [@wawa0210](https://github.com/wawa0210)) +* Bind metrics-server containers to linux nodes to avoid Windows scheduling on kubernetes cluster includes linux nodes and windows nodes ([#83362](https://github.com/kubernetes/kubernetes/pull/83362), [@wawa0210](https://github.com/wawa0210)) +* During initialization phase (preflight), kubeadm now verifies the presence of the conntrack executable ([#85857](https://github.com/kubernetes/kubernetes/pull/85857), [@hnanni](https://github.com/hnanni)) +* VMSS cache is added so that less chances of VMSS GET throttling ([#85885](https://github.com/kubernetes/kubernetes/pull/85885), [@nilo19](https://github.com/nilo19)) +* Update go-winio module version from 0.4.11 to 0.4.14 ([#85739](https://github.com/kubernetes/kubernetes/pull/85739), [@wawa0210](https://github.com/wawa0210)) +* Fix LoadBalancer rule checking so that no unexpected LoadBalancer updates are made ([#85990](https://github.com/kubernetes/kubernetes/pull/85990), [@feiskyer](https://github.com/feiskyer)) +* kubectl drain node --dry-run will list pods that would be evicted or deleted ([#82660](https://github.com/kubernetes/kubernetes/pull/82660), [@sallyom](https://github.com/sallyom)) +* Windows nodes on GCE can use TPM-based authentication to the master. ([#85466](https://github.com/kubernetes/kubernetes/pull/85466), [@pjh](https://github.com/pjh)) +* kubectl/drain: add disable-eviction option. ([#85571](https://github.com/kubernetes/kubernetes/pull/85571), [@michaelgugino](https://github.com/michaelgugino)) + * Force drain to use delete, even if eviction is supported. This will bypass checking PodDisruptionBudgets, and should be used with caution. +* kubeadm now errors out whenever a not supported component config version is supplied for the kubelet and kube-proxy ([#85639](https://github.com/kubernetes/kubernetes/pull/85639), [@rosti](https://github.com/rosti)) +* Fixed issue with addon-resizer using deprecated extensions APIs ([#85793](https://github.com/kubernetes/kubernetes/pull/85793), [@bskiba](https://github.com/bskiba)) +* Includes FSType when describing CSI persistent volumes. ([#85293](https://github.com/kubernetes/kubernetes/pull/85293), [@huffmanca](https://github.com/huffmanca)) +* kubelet now exports a "server_expiration_renew_failure" and "client_expiration_renew_failure" metric counter if the certificate rotations cannot be performed. ([#84614](https://github.com/kubernetes/kubernetes/pull/84614), [@rphillips](https://github.com/rphillips)) +* kubeadm: don't write the kubelet environment file on "upgrade apply" ([#85412](https://github.com/kubernetes/kubernetes/pull/85412), [@boluisa](https://github.com/boluisa)) +* fix azure file AuthorizationFailure ([#85475](https://github.com/kubernetes/kubernetes/pull/85475), [@andyzhangx](https://github.com/andyzhangx)) +* Resolved regression in admission, authentication, and authorization webhook performance in v1.17.0-rc.1 ([#85810](https://github.com/kubernetes/kubernetes/pull/85810), [@liggitt](https://github.com/liggitt)) +* kubeadm: uses the apiserver AdvertiseAddress IP family to choose the etcd endpoint IP family for non external etcd clusters ([#85745](https://github.com/kubernetes/kubernetes/pull/85745), [@aojea](https://github.com/aojea)) +* kubeadm: Forward cluster name to the controller-manager arguments ([#85817](https://github.com/kubernetes/kubernetes/pull/85817), [@ereslibre](https://github.com/ereslibre)) +* Fixed "requested device X but found Y" attach error on AWS. ([#85675](https://github.com/kubernetes/kubernetes/pull/85675), [@jsafrane](https://github.com/jsafrane)) +* addons: elasticsearch discovery supports IPv6 ([#85543](https://github.com/kubernetes/kubernetes/pull/85543), [@SataQiu](https://github.com/SataQiu)) +* kubeadm: retry `kubeadm-config` ConfigMap creation or mutation if the apiserver is not responding. This will improve resiliency when joining new control plane nodes. ([#85763](https://github.com/kubernetes/kubernetes/pull/85763), [@ereslibre](https://github.com/ereslibre)) +* Update Cluster Autoscaler to 1.17.0; changelog: https://github.com/kubernetes/autoscaler/releases/tag/cluster-autoscaler-1.17.0 ([#85610](https://github.com/kubernetes/kubernetes/pull/85610), [@losipiuk](https://github.com/losipiuk)) +* Filter published OpenAPI schema by making nullable, required fields non-required in order to avoid kubectl to wrongly reject null values. ([#85722](https://github.com/kubernetes/kubernetes/pull/85722), [@sttts](https://github.com/sttts)) +* kubectl set resources will no longer return an error if passed an empty change for a resource. ([#85490](https://github.com/kubernetes/kubernetes/pull/85490), [@sallyom](https://github.com/sallyom)) + * kubectl set subject will no longer return an error if passed an empty change for a resource. +* kube-apiserver: fixed a conflict error encountered attempting to delete a pod with gracePeriodSeconds=0 and a resourceVersion precondition ([#85516](https://github.com/kubernetes/kubernetes/pull/85516), [@michaelgugino](https://github.com/michaelgugino)) +* kubeadm: add a upgrade health check that deploys a Job ([#81319](https://github.com/kubernetes/kubernetes/pull/81319), [@neolit123](https://github.com/neolit123)) +* kubeadm: make sure images are pre-pulled even if a tag did not change but their contents changed ([#85603](https://github.com/kubernetes/kubernetes/pull/85603), [@bart0sh](https://github.com/bart0sh)) +* kube-apiserver: Fixes a bug that hidden metrics can not be enabled by the command-line option `--show-hidden-metrics-for-version`. ([#85444](https://github.com/kubernetes/kubernetes/pull/85444), [@RainbowMango](https://github.com/RainbowMango)) +* kubeadm now supports automatic calculations of dual-stack node cidr masks to kube-controller-manager. ([#85609](https://github.com/kubernetes/kubernetes/pull/85609), [@Arvinderpal](https://github.com/Arvinderpal)) +* Fix bug where EndpointSlice controller would attempt to modify shared objects. ([#85368](https://github.com/kubernetes/kubernetes/pull/85368), [@robscott](https://github.com/robscott)) +* Use context to check client closed instead of http.CloseNotifier in processing watch request which will reduce 1 goroutine for each request if proto is HTTP/2.x . ([#85408](https://github.com/kubernetes/kubernetes/pull/85408), [@answer1991](https://github.com/answer1991)) +* kubeadm: reset raises warnings if it cannot delete folders ([#85265](https://github.com/kubernetes/kubernetes/pull/85265), [@SataQiu](https://github.com/SataQiu)) +* Wait for kubelet & kube-proxy to be ready on Windows node within 10s ([#85228](https://github.com/kubernetes/kubernetes/pull/85228), [@YangLu1031](https://github.com/YangLu1031)) diff --git a/content/zh/docs/setup/release/version-skew-policy.md b/content/zh/docs/setup/release/version-skew-policy.md index 25bfbb8cf6..0bc7b4e4e0 100644 --- a/content/zh/docs/setup/release/version-skew-policy.md +++ b/content/zh/docs/setup/release/version-skew-policy.md @@ -22,7 +22,10 @@ Specific cluster deployment tools may place additional restrictions on version s <!-- body --> +<!-- ## Supported versions +--> +## 版本支持策略 <!-- Kubernetes versions are expressed as **x.y.z**, @@ -54,11 +57,16 @@ Minor releases occur approximately every 3 months, so each minor release branch --> 小版本大约每3个月发布一个，所以每个小版本分支会维护9个月。 +<!-- ## Supported version skew +--> +## 版本倾斜策略 ### kube-apiserver +<!-- In [highly-available (HA) clusters](/docs/setup/production-environment/tools/kubeadm/high-availability/), the newest and oldest `kube-apiserver` instances must be within one minor version. +--> 在 [高可用（HA）集群](/docs/setup/production-environment/tools/kubeadm/high-availability/) 中， 多个 `kube-apiserver` 实例小版本号最多差1。 @@ -109,7 +117,10 @@ Example: * 如果 `kube-apiserver` 的多个实例同时存在 **1.13** 和 **1.12** * `kubelet` 只能是 **1.12** 或 **1.11**（**1.13** 不再支持，因为它比**1.12**版本的 `kube-apiserver` 更新） +<!-- ### kube-controller-manager, kube-scheduler, and cloud-controller-manager +--> +### kube-controller-manager、 kube-scheduler 和 cloud-controller-manager <!-- `kube-controller-manager`, `kube-scheduler`, and `cloud-controller-manager` must not be newer than the `kube-apiserver` instances they communicate with. They are expected to match the `kube-apiserver` minor version, but may be up to one minor version older (to allow live upgrades). @@ -232,7 +243,10 @@ require `kube-apiserver` to not skip minor versions when upgrading, even in sing {{< /note >}} +<!-- ### kube-controller-manager, kube-scheduler, and cloud-controller-manager +--> +### kube-controller-manager、 kube-scheduler 和 cloud-controller-manager <!-- Pre-requisites: diff --git a/content/zh/docs/tasks/access-application-cluster/access-cluster.md b/content/zh/docs/tasks/access-application-cluster/access-cluster.md index c839c2951f..5ed7151349 100644 --- a/content/zh/docs/tasks/access-application-cluster/access-cluster.md +++ b/content/zh/docs/tasks/access-application-cluster/access-cluster.md @@ -145,7 +145,7 @@ In Kubernetes version 1.3 or later, `kubectl config view` no longer displays the ```shell $ APISERVER=$(kubectl config view | grep server | cut -f 2- -d ":" | tr -d " ") -$ TOKEN=$(kubectl describe secret $(kubectl get secrets | grep default | cut -f1 -d ' ') | grep -E '^token' | cut -f2 -d':' | tr -d '\t') +$ TOKEN=$(kubectl describe secret $(kubectl get secrets | grep default | cut -f1 -d ' ') | grep -E '^token' | cut -f2 -d':' | tr -d ' ') $ curl $APISERVER/api --header "Authorization: Bearer $TOKEN" --insecure { "kind": "APIVersions", diff --git a/content/zh/docs/tasks/access-application-cluster/configure-access-multiple-clusters.md b/content/zh/docs/tasks/access-application-cluster/configure-access-multiple-clusters.md index d577256a6e..f1553da086 100644 --- a/content/zh/docs/tasks/access-application-cluster/configure-access-multiple-clusters.md +++ b/content/zh/docs/tasks/access-application-cluster/configure-access-multiple-clusters.md @@ -1,29 +1,67 @@ --- title: 配置对多集群的访问 content_type: task +card: + name: tasks + weight: 40 --- - +<!-- +title: Configure Access to Multiple Clusters +content_type: task +weight: 30 +card: + name: tasks + weight: 40 +--> <!-- overview --> - +<!-- +This page shows how to configure access to multiple clusters by using +configuration files. After your clusters, users, and contexts are defined in +one or more configuration files, you can quickly switch between clusters by using the +`kubectl config use-context` command. +--> 本文展示如何使用配置文件来配置对多个集群的访问。 在将集群、用户和上下文定义在一个或多个配置文件中之后，用户可以使用 `kubectl config use-context` 命令快速地在集群之间进行切换。 +<!-- +A file that is used to configure access to a cluster is sometimes called +a *kubeconfig file*. This is a generic way of referring to configuration files. +It does not mean that there is a file named `kubeconfig`. +--> {{< note >}} 用于配置集群访问的文件有时被称为 *kubeconfig 文件*。 这是一种引用配置文件的通用方式，并不意味着存在一个名为 `kubeconfig` 的文件。 {{< /note >}} - - ## {{% heading "prerequisites" %}} +{{< include "task-tutorial-prereqs.md" >}} -需要安装 [`kubectl`](/docs/tasks/tools/install-kubectl/) 命令行工具。 - - +<!-- +To check that {{< glossary_tooltip text="kubectl" term_id="kubectl" >}} is installed, +run `kubectl version --client`. The kubectl version should be +[within one minor version](/docs/setup/release/version-skew-policy/#kubectl) of your +cluster's API server. +--> +要检查 {{< glossary_tooltip text="kubectl" term_id="kubectl" >}} 是否安装， +执行 `kubectl version --client` 命令。 +kubectl 的版本应该与集群的 API 服务器 +[使用同一次版本号](/docs/setup/release/version-skew-policy/#kubectl)。 <!-- steps --> +<!-- +## Define clusters, users, and contexts +Suppose you have two clusters, one for development work and one for scratch work. +In the `development` cluster, your frontend developers work in a namespace called `frontend`, +and your storage developers work in a namespace called `storage`. In your `scratch` cluster, +developers work in the default namespace, or they create auxiliary namespaces as they +see fit. Access to the development cluster requires authentication by certificate. Access +to the scratch cluster requires authentication by username and password. + +Create a directory named `config-exercise`. In your +`config-exercise` directory, create a file named `config-demo` with this content: +--> ## 定义集群、用户和上下文 假设用户有两个集群，一个用于正式开发工作，一个用于其它临时用途（scratch）。 @@ -58,6 +96,14 @@ contexts: name: exp-scratch ``` +<!-- +A configuration file describes clusters, users, and contexts. Your `config-demo` file +has the framework to describe two clusters, two users, and three contexts. + +Go to your `config-exercise` directory. Enter these commands to add cluster details to +your configuration file: +--> + 配置文件描述了集群、用户名和上下文。 `config-demo` 文件中含有描述两个集群、两个用户和三个上下文的框架。 进入 `config-exercise` 目录。 输入以下命令，将群集详细信息添加到配置文件中： @@ -67,6 +113,9 @@ kubectl config --kubeconfig=config-demo set-cluster development --server=https:/ kubectl config --kubeconfig=config-demo set-cluster scratch --server=https://5.6.7.8 --insecure-skip-tls-verify ``` +<!-- +Add user details to your configuration file: +--> 将用户详细信息添加到配置文件中： ```shell @@ -74,6 +123,20 @@ kubectl config --kubeconfig=config-demo set-credentials developer --client-certi kubectl config --kubeconfig=config-demo set-credentials experimenter --username=exp --password=some-password ``` +<!-- +- To delete a user you can run `kubectl --kubeconfig=config-demo config unset users.<name>` +- To remove a cluster, you can run `kubectl --kubeconfig=config-demo config unset clusters.<name>` +- To remove a context, you can run `kubectl --kubeconfig=config-demo config unset contexts.<name>` +--> + +注意： +- 要删除用户，可以运行 `kubectl --kubeconfig=config-demo config unset users.<name>` +- 要删除集群，可以运行 `kubectl --kubeconfig=config-demo config unset clusters.<name>` +- 要删除上下文，可以运行 `kubectl --kubeconfig=config-demo config unset contexts.<name>` + +<!-- +Add context details to your configuration file: +--> 将上下文详细信息添加到配置文件中： ```shell @@ -82,12 +145,19 @@ kubectl config --kubeconfig=config-demo set-context dev-storage --cluster=develo kubectl config --kubeconfig=config-demo set-context exp-scratch --cluster=scratch --namespace=default --user=experimenter ``` +<!-- +Open your `config-demo` file to see the added details. As an alternative to opening the +`config-demo` file, you can use the `config view` command. +--> 打开 `config-demo` 文件查看添加的详细信息。 也可以使用 `config view` 命令进行查看： ```shell kubectl config --kubeconfig=config-demo view ``` +<!-- +The output shows the two clusters, two users, and three contexts: +--> 输出展示了两个集群、两个用户和三个上下文： ```yaml @@ -131,8 +201,32 @@ users: username: exp ``` +<!-- +The `fake-ca-file`, `fake-cert-file` and `fake-key-file` above are the placeholders +for the pathnames of the certificate files. You need change these to the actual pathnames +of certificate files in your environment. + +Sometimes you may want to use Base64-encoded data embedded here instead of separate +certificate files; in that case you need add the suffix `-data` to the keys, for example, +`certificate-authority-data`, `client-certificate-data`, `client-key-data`. +--> +其中的 `fake-ca-file`、`fake-cert-file` 和 `fake-key-file` 是证书文件路径名的占位符。 +你需要更改这些值，使之对应你的环境中证书文件的实际路径名。 + +有时你可能希望在这里使用 BASE64 编码的数据而不是一个个独立的证书文件。 +如果是这样，你需要在键名上添加 `-data` 后缀。例如， +`certificate-authority-data`、`client-certificate-data` 和 `client-key-data`。 + +<!-- +Each context is a triple (cluster, user, namespace). For example, the +`dev-frontend` context says, "Use the credentials of the `developer` +user to access the `frontend` namespace of the `development` cluster". + +Set the current context: +--> 每个上下文包含三部分（集群、用户和名字空间），例如， -`dev-frontend` 上下文表明：使用 `developer` 用户的凭证来访问 `development` 集群的 `frontend` 名字空间。 +`dev-frontend` 上下文表明：使用 `developer` 用户的凭证来访问 `development` 集群的 +`frontend` 名字空间。 设置当前上下文： @@ -140,7 +234,16 @@ users: kubectl config --kubeconfig=config-demo use-context dev-frontend ``` -现在当输入 `kubectl` 命令时，相应动作会应用于 `dev-frontend` 上下文中所列的集群和名字空间，同时，命令会使用 `dev-frontend` 上下文中所列用户的凭证。 +<!-- +Now whenever you enter a `kubectl` command, the action will apply to the cluster, +and namespace listed in the `dev-frontend` context. And the command will use +the credentials of the user listed in the `dev-frontend` context. + +To see only the configuration information associated with +the current context, use the `--minify` flag. +--> +现在当输入 `kubectl` 命令时，相应动作会应用于 `dev-frontend` 上下文中所列的集群和名字空间， +同时，命令会使用 `dev-frontend` 上下文中所列用户的凭证。 使用 `--minify` 参数，来查看与当前上下文相关联的配置信息。 @@ -148,6 +251,9 @@ kubectl config --kubeconfig=config-demo use-context dev-frontend kubectl config --kubeconfig=config-demo view --minify ``` +<!-- +The output shows configuration information associated with the `dev-frontend` context: +--> 输出结果展示了 `dev-frontend` 上下文相关的配置信息： ```yaml @@ -173,6 +279,11 @@ users: client-key: fake-key-file ``` +<!-- +Now suppose you want to work for a while in the scratch cluster. + +Change the current context to `exp-scratch`: +--> 现在假设用户希望在其它临时用途集群中工作一段时间。 将当前上下文更改为 `exp-scratch`： @@ -181,7 +292,16 @@ users: kubectl config --kubeconfig=config-demo use-context exp-scratch ``` -现在用户 `kubectl` 下达的任何命令都将应用于 `scratch` 集群的默认名字空间。 同时，命令会使用 `exp-scratch` 上下文中所列用户的凭证。 +<!-- +Now any `kubectl` command you give will apply to the default namespace of +the `scratch` cluster. And the command will use the credentials of the user +listed in the `exp-scratch` context. + +View configuration associated with the new current context, `exp-scratch`. +--> + +现在你发出的所有 `kubectl` 命令都将应用于 `scratch` 集群的默认名字空间。 +同时，命令会使用 `exp-scratch` 上下文中所列用户的凭证。 查看更新后的当前上下文 `exp-scratch` 相关的配置： @@ -189,6 +309,12 @@ kubectl config --kubeconfig=config-demo use-context exp-scratch kubectl config --kubeconfig=config-demo view --minify ``` +<!-- +Finally, suppose you want to work for a while in the `storage` namespace of the +`development` cluster. + +Change the current context to `dev-storage`: +--> 最后，假设用户希望在 `development` 集群中的 `storage` 名字空间下工作一段时间。 将当前上下文更改为 `dev-storage`： @@ -197,13 +323,21 @@ kubectl config --kubeconfig=config-demo view --minify kubectl config --kubeconfig=config-demo use-context dev-storage ``` +<!-- +View configuration associated with the new current context, `dev-storage`. +--> 查看更新后的当前上下文 `dev-storage` 相关的配置： - ```shell kubectl config --kubeconfig=config-demo view --minify ``` +<!-- +## Create a second configuration file + +In your `config-exercise` directory, create a file named `config-demo-2` with this content: +--> + ## 创建第二个配置文件 在 `config-exercise` 目录中，创建名为 `config-demo-2` 的文件，其中包含以下内容： @@ -221,32 +355,77 @@ contexts: name: dev-ramp-up ``` +<!-- +The preceding configuration file defines a new context named `dev-ramp-up`. +--> 上述配置文件定义了一个新的上下文，名为 `dev-ramp-up`。 +<!-- +## Set the KUBECONFIG environment variable + +See whether you have an environment variable named `KUBECONFIG`. If so, save the +current value of your `KUBECONFIG` environment variable, so you can restore it later. +For example: +--> ## 设置 KUBECONFIG 环境变量 查看是否有名为 `KUBECONFIG` 的环境变量。 如有，保存 `KUBECONFIG` 环境变量当前的值，以便稍后恢复。 -例如，在 Linux 中： +例如： +### Linux ```shell -export KUBECONFIG_SAVED=$KUBECONFIG +export KUBECONFIG_SAVED=$KUBECONFIG ``` -`KUBECONFIG` 环境变量是配置文件路径的列表，该列表在 Linux 和 Mac 中以冒号分隔，在 Windows 中以分号分隔。 如果有 `KUBECONFIG` 环境变量，请熟悉列表中的配置文件。 +### Windows PowerShell +```shell +$Env:KUBECONFIG_SAVED=$ENV:KUBECONFIG +``` -临时添加两条路径到 `KUBECONFIG` 环境变量中。 例如，在 Linux 中： +<!-- + The `KUBECONFIG` environment variable is a list of paths to configuration files. The list is +colon-delimited for Linux and Mac, and semicolon-delimited for Windows. If you have +a `KUBECONFIG` environment variable, familiarize yourself with the configuration files +in the list. + +Temporarily append two paths to your `KUBECONFIG` environment variable. For example: +--> +`KUBECONFIG` 环境变量是配置文件路径的列表，该列表在 Linux 和 Mac 中以冒号分隔， +在 Windows 中以分号分隔。 +如果有 `KUBECONFIG` 环境变量，请熟悉列表中的配置文件。 + +临时添加两条路径到 `KUBECONFIG` 环境变量中。 例如： + +### Linux ```shell export KUBECONFIG=$KUBECONFIG:config-demo:config-demo-2 ``` +### Windows PowerShell + +```shell +$Env:KUBECONFIG=("config-demo;config-demo-2") +``` + +<!-- +In your `config-exercise` directory, enter this command: +--> 在 `config-exercise` 目录中输入以下命令： ```shell kubectl config view ``` -输出展示了 `KUBECONFIG` 环境变量中所列举的所有文件合并后的信息。 特别地， 注意合并信息中包含来自 `config-demo-2` 文件的 `dev-ramp-up` 上下文和来自 `config-demo` 文件的三个上下文： +<!-- +The output shows merged information from all the files listed in your `KUBECONFIG` +environment variable. In particular, notice that the merged information has the +`dev-ramp-up` context from the `config-demo-2` file and the three contexts from +the `config-demo` file: +--> +输出展示了 `KUBECONFIG` 环境变量中所列举的所有文件合并后的信息。 +特别地，注意合并信息中包含来自 `config-demo-2` 文件的 `dev-ramp-up` 上下文和来自 +`config-demo` 文件的三个上下文： ```yaml contexts: @@ -272,49 +451,93 @@ contexts: name: exp-scratch ``` -更多关于 kubeconfig 文件如何合并的信息，请参考 -[使用 kubeconfig 文件组织集群访问](/docs/concepts/configuration/organize-cluster-access-kubeconfig/) +<!-- +For more information about how kubeconfig files are merged, see +[Organizing Cluster Access Using kubeconfig Files](/docs/concepts/configuration/organize-cluster-access-kubeconfig/) +--> +关于 kubeconfig 文件如何合并的更多信息，请参考 +[使用 kubeconfig 文件组织集群访问](/zh/docs/concepts/configuration/organize-cluster-access-kubeconfig/) +<!-- +## Explore the $HOME/.kube directory + +If you already have a cluster, and you can use `kubectl` to interact with +the cluster, then you probably have a file named `config` in the `$HOME/.kube` +directory. + +Go to `$HOME/.kube`, and see what files are there. Typically, there is a file named +`config`. There might also be other configuration files in this directory. Briefly +familiarize yourself with the contents of these files. +--> ## 探索 $HOME/.kube 目录 -如果用户已经拥有一个集群，可以使用 `kubectl` 与集群进行交互。 那么很可能在 `$HOME/.kube` 目录下有一个名为 `config` 的文件。 +如果用户已经拥有一个集群，可以使用 `kubectl` 与集群进行交互， +那么很可能在 `$HOME/.kube` 目录下有一个名为 `config` 的文件。 -进入 `$HOME/.kube` 目录， 看看那里有什么文件。 通常会有一个名为 -`config` 的文件，目录中可能还有其他配置文件。 请简单地熟悉这些文件的内容。 +进入 `$HOME/.kube` 目录，看看那里有什么文件。通常会有一个名为 +`config` 的文件，目录中可能还有其他配置文件。请简单地熟悉这些文件的内容。 +<!-- +## Append $HOME/.kube/config to your KUBECONFIG environment variable + +If you have a `$HOME/.kube/config` file, and it's not already listed in your +`KUBECONFIG` environment variable, append it to your `KUBECONFIG` environment variable now. +For example: +--> ## 将 $HOME/.kube/config 追加到 KUBECONFIG 环境变量中 如果有 `$HOME/.kube/config` 文件，并且还未列在 `KUBECONFIG` 环境变量中， 那么现在将它追加到 `KUBECONFIG` 环境变量中。 -例如，在 Linux 中： +例如： + +### Linux ```shell export KUBECONFIG=$KUBECONFIG:$HOME/.kube/config ``` -在配置练习目录中输入以下命令，来查看当前 `KUBECONFIG` 环境变量中列举的所有文件合并后的配置信息： +### Windows Powershell + +```shell +$Env:KUBECONFIG="$Env:KUBECONFIG;$HOME\.kube\config" +``` + +<!-- +View configuration information merged from all the files that are now listed +in your `KUBECONFIG` environment variable. In your config-exercise directory, enter: +--> +在配置练习目录中输入以下命令，查看当前 `KUBECONFIG` 环境变量中列举的所有文件合并后的配置信息： ```shell kubectl config view ``` +<!-- +## Clean up + +Return your `KUBECONFIG` environment variable to its original value. For example: +--> ## 清理 -将 `KUBECONFIG` 环境变量还原为原始值。 例如，在 Linux 中： +将 `KUBECONFIG` 环境变量还原为原始值。 例如： +### Linux ```shell export KUBECONFIG=$KUBECONFIG_SAVED ``` - +### Windows PowerShell +```shell +$Env:KUBECONFIG=$ENV:KUBECONFIG_SAVED +``` ## {{% heading "whatsnext" %}} +<!-- +* [Organizing Cluster Access Using kubeconfig Files](/docs/concepts/configuration/organize-cluster-access-kubeconfig/) +* [kubectl config](/docs/reference/generated/kubectl/kubectl-commands#config) +--> -* [使用 kubeconfig 文件组织集群访问](/docs/concepts/configuration/organize-cluster-access-kubeconfig/) -* [kubectl 配置](/docs/user-guide/kubectl/{{< param "version" >}}/) - - - - +* [使用 kubeconfig 文件组织集群访问](/zh/docs/concepts/configuration/organize-cluster-access-kubeconfig/) +* [kubectl config](/docs/reference/generated/kubectl/kubectl-commands#config) diff --git a/content/zh/docs/tasks/access-application-cluster/create-external-load-balancer.md b/content/zh/docs/tasks/access-application-cluster/create-external-load-balancer.md index 86d83cd34b..d6887556e2 100644 --- a/content/zh/docs/tasks/access-application-cluster/create-external-load-balancer.md +++ b/content/zh/docs/tasks/access-application-cluster/create-external-load-balancer.md @@ -190,13 +190,16 @@ traffic spreading. <!-- * `service.spec.healthCheckNodePort` - specifies the health check nodePort -(numeric port number) for the service. If not specified, `healthCheckNodePort` is -created by the service API backend with the allocated `nodePort`. It will use the -user-specified `nodePort` value if specified by the client. It only has an +(numeric port number) for the service. If `healthCheckNodePort` isn't specified, +the service controller allocates a port from your cluster's NodePort range. You +can configure that range by setting an API server command line option, +`--service-node-port-range`. It will use the +user-specified `healthCheckNodePort` value if specified by the client. It only has an effect when `type` is set to LoadBalancer and `externalTrafficPolicy` is set to Local. --> -* `service.spec.healthCheckNodePort` - 指定服务的 healthcheck nodePort（数字端口号）。如果未指定，则 serviceCheckNodePort 由服务 API 后端使用已分配的 nodePort 创建。如果客户端指定，它将使用客户端指定的 nodePort 值。仅当 type 设置为 LoadBalancer 并且 externalTrafficPolicy 设置为 Local 时才生效。 + +* `service.spec.healthCheckNodePort` - 指定服务的 healthcheck nodePort（数字端口号）。如果未指定 `healthCheckNodePort`，服务控制器从集群的 NodePort 范围内分配一个端口。您可以通过设置 API 服务器的命令行选项 `--service-node-port-range` 来配置上述范围。它将会使用用户指定的 `healthCheckNodePort` 值（如果被客户端指定）。仅当 `type` 设置为 LoadBalancer 并且 `externalTrafficPolicy` 设置为 Local 时才生效。 <!-- Setting `externalTrafficPolicy` to Local in the Service configuration file diff --git a/content/zh/docs/tasks/access-application-cluster/ingress-minikube.md b/content/zh/docs/tasks/access-application-cluster/ingress-minikube.md new file mode 100644 index 0000000000..dab03002d3 --- /dev/null +++ b/content/zh/docs/tasks/access-application-cluster/ingress-minikube.md @@ -0,0 +1,421 @@ +--- +title: 在 Minikube 环境中使用 NGINX Ingress 控制器配置 Ingress +content_type: task +weight: 100 +--- +<!-- +title: Set up Ingress on Minikube with the NGINX Ingress Controller +content_type: task +weight: 100 +--> + +<!-- overview --> + +<!-- +An [Ingress](/docs/concepts/services-networking/ingress/) is an API object that defines rules which allow external access +to services in a cluster. An [Ingress controller](/docs/concepts/services-networking/ingress-controllers/) fulfills the rules set in the Ingress. + +This page shows you how to set up a simple Ingress which routes requests to Service web or web2 depending on the HTTP URI. +--> +[Ingress](/zh/docs/concepts/services-networking/ingress/)是一种 API 对象，其中定义了一些规则使得集群中的 +服务可以从集群外访问。 +[Ingress 控制器](/zh/docs/concepts/services-networking/ingress-controllers/) +负责满足 Ingress 中所设置的规则。 + +本节为你展示如何配置一个简单的 Ingress，根据 HTTP URI 将服务请求路由到 +服务 `web` 或 `web2`。 + +## {{% heading "prerequisites" %}} + +{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}} + +<!-- steps --> + +<!-- +## Create a Minikube cluster + +1. Click **Launch Terminal** +--> +## 创建一个 Minikube 集群 + +1. 点击 **Launch Terminal** + + {{< kat-button >}} + +<!-- +1. (Optional) If you installed Minikube locally, run the following command: +--> +2. （可选操作）如果你在本地安装了 Minikube，运行下面的命令： + + ```shell + minikube start + ``` + +<!-- +## Enable the Ingress controller + +1. To enable the NGINX Ingress controller, run the following command: +--> +## 启用 Ingress 控制器 + +1. 为了启用 NGINIX Ingress 控制器，可以运行下面的命令： + + + ```shell + minikube addons enable ingress + ``` + +<!-- +1. Verify that the NGINX Ingress controller is running +--> +2. 检查验证 NGINX Ingress 控制器处于运行状态： + + ```shell + kubectl get pods -n kube-system + ``` + + <!-- This can take up to a minute. --> + {{< note >}}这一操作可供需要近一分钟时间。{{< /note >}} + + 输出： + + ```shell + NAME READY STATUS RESTARTS AGE + default-http-backend-59868b7dd6-xb8tq 1/1 Running 0 1m + kube-addon-manager-minikube 1/1 Running 0 3m + kube-dns-6dcb57bcc8-n4xd4 3/3 Running 0 2m + kubernetes-dashboard-5498ccf677-b8p5h 1/1 Running 0 2m + nginx-ingress-controller-5984b97644-rnkrg 1/1 Running 0 1m + storage-provisioner 1/1 Running 0 2m + ``` + +<!-- +## Deploy a hello, world app + +1. Create a Deployment using the following command: +--> +## 部署一个 Hello World 应用 + +1. 使用下面的命令创建一个 Deployment： + + ```shell + kubectl create deployment web --image=gcr.io/google-samples/hello-app:1.0 + ``` + + <!--Output:--> + 输出： + + ``` + deployment.apps/web created + ``` + +<!-- +1. Expose the Deployment: +--> +2. 将 Deployment 暴露出来： + + ```shell + kubectl expose deployment web --type=NodePort --port=8080 + ``` + + <!-- Output: --> + 输出： + + ``` + service/web exposed + ``` + +<!-- +1. Verify the Service is created and is available on a node port: +--> +3. 验证 Service 已经创建，并且可能从节点端口访问： + + ```shell + kubectl get service web + ``` + + <!-- Output: --> + 输出： + + ```shell + NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE + web NodePort 10.104.133.249 <none> 8080:31637/TCP 12m + ``` + +<!-- +1. Visit the service via NodePort: +--> +4. 使用节点端口信息访问服务： + + ```shell + minikube service web --url + ``` + + <!-- Output: --> + 输出： + + ```shell + http://172.17.0.15:31637 + ``` + + <!-- + Katacoda environment only: at the top of the terminal panel, click the plus sign, and then click **Select port to view on Host 1**. Enter the NodePort, in this case `31637`, and then click **Display Port**. + --> + {{< note >}} + 如果使用的是 Katacoda 环境，在终端面板顶端，请点击加号标志。 + 然后点击 **Select port to view on Host 1**。 + 输入节点和端口号（这里是`31637`），之后点击 **Display Port**。 + {{< /note >}} + + <!-- Output: --> + 输出： + + ```shell + Hello, world! + Version: 1.0.0 + Hostname: web-55b8c6998d-8k564 + ``` + + <!-- + You can now access the sample app via the Minikube IP address and NodePort. The next step lets you access + the app using the Ingress resource. + --> + 你现在应该可以通过 Minikube 的 IP 地址和节点端口来访问示例应用了。 + 下一步是让自己能够通过 Ingress 资源来访问应用。 + +<!-- +## Create an Ingress resource + +The following file is an Ingress resource that sends traffic to your Service via hello-world.info. + +1. Create `example-ingress.yaml` from the following file: +--> +## 创建一个 Ingress 资源 + +下面是一个 Ingress 资源的配置文件，负责通过 `hello-world.info` 将服务请求 +转发到你的服务。 + +1. 根据下面的 YAML 创建文件 `example-ingress.yaml`： + + ```yaml + apiVersion: networking.k8s.io/v1beta1 + kind: Ingress + metadata: + name: example-ingress + annotations: + nginx.ingress.kubernetes.io/rewrite-target: /$1 + spec: + rules: + - host: hello-world.info + http: + paths: + - path: / + backend: + serviceName: web + servicePort: 8080 + ``` + +<!-- +1. Create the Ingress resource by running the following command: +--> +2. 通过运行下面的命令创建 Ingress 资源： + + ```shell + kubectl apply -f example-ingress.yaml + ``` + + <!-- Output: --> + 输出： + + ```shell + ingress.networking.k8s.io/example-ingress created + ``` +<!-- +1. Verify the IP address is set: +--> +3. 验证 IP 地址已被设置： + + ```shell + kubectl get ingress + ``` + + <!-- This can take a couple of minutes. --> + {{< note >}}此操作可能需要几分钟时间。{{< /note >}} + + ```shell + NAME HOSTS ADDRESS PORTS AGE + example-ingress hello-world.info 172.17.0.15 80 38s + ``` + +<!-- +1. Add the following line to the bottom of the `/etc/hosts` file. +--> +4. 在 `/etc/hosts` 文件的末尾添加以下内容： + + <!-- + If you are running Minikube locally, use `minikube ip` to get the external IP. The IP address displayed within the ingress list will be the internal IP. + --> + {{< note >}} + 如果你在本地运行 Minikube 环境，需要使用 `minikube ip` 获得外部 IP 地址。 + Ingress 列表中显示的 IP 地址会是内部 IP 地址。 + {{< /note >}} + ``` + 172.17.0.15 hello-world.info + ``` + + <!-- This sends requests from hello-world.info to Minikube. --> + 此设置使得来自 `hello-world.info` 的请求被发送到 Minikube。 + +<!-- +1. Verify that the Ingress controller is directing traffic: +--> +5. 验证 Ingress 控制器能够转发请求流量： + + ```shell + curl hello-world.info + ``` + + <!-- Output: --> + 输出： + + ```shell + Hello, world! + Version: 1.0.0 + Hostname: web-55b8c6998d-8k564 + ``` + + <!-- + If you are running Minikube locally, you can visit hello-world.info from your browser. + --> + {{< note >}} + 如果你在使用本地 Minikube 环境，你可以从浏览器中访问 hellow-world.info。 + {{< /note >}} + +<!-- +## Create Second Deployment + +1. Create a v2 Deployment using the following command: +--> +## 创建第二个 Deployment + +1. 使用下面的命令创建 v2 的 Deployment： + + ```shell + kubectl create deployment web2 --image=gcr.io/google-samples/hello-app:2.0 + ``` + <!-- Output: --> + 输出： + + ```shell + deployment.apps/web2 created + ``` + +<!-- +1. Expose the Deployment: +--> +2. 将 Deployment 暴露出来： + + ```shell + kubectl expose deployment web2 --port=8080 --type=NodePort + ``` + + <!-- Output: --> + 输出： + + ```shell + service/web2 exposed + ``` + +<!-- +## Edit Ingress + +1. Edit the existing `example-ingress.yaml` and add the following lines: +--> +## 编辑 Ingress + +1. 编辑现有的 `example-ingress.yaml`，添加以下行： + + + ```yaml + - path: /v2 + backend: + serviceName: web2 + servicePort: 8080 + ``` + +<!-- +1. Apply the changes: +--> +2. 应用所作变更： + + ```shell + kubectl apply -f example-ingress.yaml + ``` + + <!-- Output: --> + 输出： + + ```shell + ingress.networking/example-ingress configured + ``` + +<!-- +## Test Your Ingress + +1. Access the 1st version of the Hello World app. +--> +## 测试你的 Ingress + +1. 访问 HelloWorld 应用的第一个版本： + + ```shell + curl hello-world.info + ``` + + <!-- Output: --> + 输出： + + ``` + Hello, world! + Version: 1.0.0 + Hostname: web-55b8c6998d-8k564 + ``` + +<!-- +1. Access the 2nd version of the Hello World app. +--> +2. 访问 HelloWorld 应用的第二个版本： + + ```shell + curl hello-world.info/v2 + ``` + + <!-- Output: --> + 输出： + + ``` + Hello, world! + Version: 2.0.0 + Hostname: web2-75cd47646f-t8cjk + ``` + + <!-- + If you are running Minikube locally, you can visit hello-world.info and hello-world.info/v2 from your browser + --> + {{< note >}} + 如果你在本地运行 Minikube 环境，你可以使用浏览器来访问 + hellow-world.info 和 hello-world.info/v2。 + {{< /note >}} + +## {{% heading "whatsnext" %}} + +<!-- +* Read more about [Ingress](/docs/concepts/services-networking/ingress/) +* Read more about [Ingress Controllers](/docs/concepts/services-networking/ingress-controllers/) +* Read more about [Services](/docs/concepts/services-networking/service/) +--> + +* 进一步了解 [Ingress](/zh/docs/concepts/services-networking/ingress/)。 +* 进一步了解 [Ingress 控制器](/zh/docs/concepts/services-networking/ingress-controllers/) +* 进一步了解[服务](/zh/docs/concepts/services-networking/service/) + diff --git a/content/zh/docs/tasks/administer-cluster/change-pv-reclaim-policy.md b/content/zh/docs/tasks/administer-cluster/change-pv-reclaim-policy.md index d36686c38a..a2b6d89e0c 100644 --- a/content/zh/docs/tasks/administer-cluster/change-pv-reclaim-policy.md +++ b/content/zh/docs/tasks/administer-cluster/change-pv-reclaim-policy.md @@ -22,7 +22,7 @@ content_type: task ## 为什么要更改 PersistentVolume 的回收策略 -`PersistentVolumes` 可以有多种回收策略，包括 "Retain"、"Recycle" 和 "Delete"。对于动态配置的 `PersistentVolumes` 来说，默认回收策略为 "Delete"。这表示当用户删除对应的 `PersistentVolumeClaim` 时，动态配置的 volume 将被自动删除。如果 volume 包含重要数据时，这种自动行为可能是不合适的。那种情况下，更适合使用 "Retain" 策略。使用 "Retain" 时，如果用户删除 `PersistentVolumeClaim`，对应的 `PersistentVolume` 不会被删除。相反，它将变为 `Released` 状态，表示所有的数据可以被手动恢复。 +PersistentVolumes 可以有多种回收策略，包括 "Retain"、"Recycle" 和 "Delete"。对于动态配置的 PersistentVolumes 来说，默认回收策略为 "Delete"。这表示当用户删除对应的 PersistentVolumeClaim 时，动态配置的 volume 将被自动删除。如果 volume 包含重要数据时，这种自动行为可能是不合适的。那种情况下，更适合使用 "Retain" 策略。使用 "Retain" 时，如果用户删除 PersistentVolumeClaim，对应的 PersistentVolume 不会被删除。相反，它将变为 Released 状态，表示所有的数据可以被手动恢复。 ## 更改 PersistentVolume 的回收策略 diff --git a/content/zh/docs/tasks/administer-cluster/declare-network-policy.md b/content/zh/docs/tasks/administer-cluster/declare-network-policy.md index 7620b37f9d..f54c581d5d 100644 --- a/content/zh/docs/tasks/administer-cluster/declare-network-policy.md +++ b/content/zh/docs/tasks/administer-cluster/declare-network-policy.md @@ -1,53 +1,93 @@ --- -approvers: -- caseydavenport -- danwinship title: 声明网络策略 content_type: task --- +<!-- +reviewers: +- caseydavenport +- danwinship +title: Declare Network Policy +min-kubernetes-server-version: v1.8 +content_type: task +--> <!-- overview --> - -本文可以帮助您开始使用 Kubernetes 的 [NetworkPolicy API](/docs/concepts/services-networking/network-policies/) 声明网络策略去管理 Pod 之间的通信 - - +<!-- +This document helps you get started using the Kubernetes [NetworkPolicy API](/docs/concepts/services-networking/network-policies/) to declare network policies that govern how pods communicate with each other. +--> +本文可以帮助您开始使用 Kubernetes 的 [NetworkPolicy API](/zh/docs/concepts/services-networking/network-policies/) 声明网络策略去管理 Pod 之间的通信 ## {{% heading "prerequisites" %}} +{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}} +<!-- +Make sure you've configured a network provider with network policy support. There are a number of network providers that support NetworkPolicy, including: +* [Calico](/docs/tasks/administer-cluster/network-policy-provider/calico-network-policy/) +* [Cilium](/docs/tasks/administer-cluster/network-policy-provider/cilium-network-policy/) +* [Kube-router](/docs/tasks/administer-cluster/network-policy-provider/kube-router-network-policy/) +* [Romana](/docs/tasks/administer-cluster/network-policy-provider/romana-network-policy/) +* [Weave Net](/docs/tasks/administer-cluster/network-policy-provider/weave-network-policy/) +--> 您首先需要有一个支持网络策略的 Kubernetes 集群。已经有许多支持 NetworkPolicy 的网络提供商，包括： -* [Calico](/docs/tasks/configure-pod-container/calico-network-policy/) -* [Romana](/docs/tasks/configure-pod-container/romana-network-policy/) -* [Weave 网络](/docs/tasks/configure-pod-container/weave-network-policy/) - - -**注意**：以上列表是根据产品名称按字母顺序排序，而不是按推荐或偏好排序。下面示例对于使用了上面任何提供商的 Kubernetes 集群都是有效的 - +* [Calico](/zh/docs/tasks/configure-pod-container/calico-network-policy/) +* [Cilium](/zh/docs/tasks/administer-cluster/network-policy-provider/cilium-network-policy/) +* [Kube-router](/zh/docs/tasks/administer-cluster/network-policy-provider/kube-router-network-policy/) +* [Romana](/zh/docs/tasks/configure-pod-container/romana-network-policy/) +* [Weave 网络](/zh/docs/tasks/configure-pod-container/weave-network-policy/) +<!-- +The above list is sorted alphabetically by product name, not by recommendation or preference. This example is valid for a Kubernetes cluster using any of these providers. +--> +{{< note >}} +以上列表是根据产品名称按字母顺序排序，而不是按推荐或偏好排序。 +下面示例对于使用了上面任何提供商的 Kubernetes 集群都是有效的 +{{< /note >}} <!-- steps --> +<!-- +## Create an `nginx` deployment and expose it via a service -## 创建一个`nginx` deployment 并且通过服务将其暴露 - +To see how Kubernetes network policy works, start off by creating an `nginx` Deployment. +--> +## 创建一个`nginx` Deployment 并且通过服务将其暴露 为了查看 Kubernetes 网络策略是怎样工作的，可以从创建一个`nginx` deployment 并且通过服务将其暴露开始 ```console -$ kubectl create deployment nginx --image=nginx +kubectl create deployment nginx --image=nginx +``` +```none deployment "nginx" created -$ kubectl expose deployment nginx --port=80 +``` + +<!-- +Expose the Deployment through a Service called `nginx`. +--> +将此 Deployment 以名为 `nginx` 的 Service 暴露出来： + +```console +kubectl expose deployment nginx --port=80 +``` +```none service "nginx" exposed ``` - -在 default 命名空间下运行了两个 `nginx` pod，而且通过一个名字为 `nginx` 的服务进行了暴露 +<!-- +The above commands create a Deployment with an nginx Pod and expose the Deployment through a Service named `nginx`. The `nginx` Pod and Deployment are found in the `default` namespace. +--> +上述命令创建了一个带有一个 nginx 的 Deployment，并将之通过名为 `nginx` 的 +Service 暴露出来。名为 `nginx` 的 Pod 和 Deployment 都位于 `default` +名字空间内。 ```console -$ kubectl get svc,pod +kubectl get svc,pod +``` +```none NAME CLUSTER-IP EXTERNAL-IP PORT(S) AGE svc/kubernetes 10.100.0.1 <none> 443/TCP 46m svc/nginx 10.100.0.16 <none> 80/TCP 33s @@ -56,93 +96,128 @@ NAME READY STATUS RESTARTS AGE po/nginx-701339712-e0qfq 1/1 Running 0 35s ``` +<!-- +## Test the service by accessing it from another Pod -## 测试服务能够被其它的 pod 访问 +You should be able to access the new `nginx` service from other Pods. To access the `nginx` Service from another Pod in the `default` namespace, start a busybox container: +--> +## 通过从 Pod 访问服务对其进行测试 - -您应该可以从其它的 pod 访问这个新的 `nginx` 服务。为了验证它，从 default 命名空间下的其它 pod 来访问该服务。请您确保在该命名空间下没有执行孤立动作。 - - -启动一个 busybox 容器，然后在容器中使用 `wget` 命令去访问 `nginx` 服务： +您应该可以从其它的 Pod 访问这个新的 `nginx` 服务。 +要从 default 命名空间中的其它s Pod 来访问该服务。可以启动一个 busybox 容器： ```console -$ kubectl run busybox --rm -ti --image=busybox /bin/sh -Waiting for pod default/busybox-472357175-y0m47 to be running, status is Pending, pod ready: false +kubectl run busybox --rm -ti --image=busybox /bin/sh +``` -Hit enter for command prompt +<!-- +In your shell, run the following command: +--> +在你的 Shell 中，运行下面的命令： -/ # wget --spider --timeout=1 nginx +```shell +wget --spider --timeout=1 nginx +``` +```none Connecting to nginx (10.100.0.16:80) -/ # +remote file exists ``` +<!-- +## Limit access to the `nginx` service -## 限制访问 `nginx` 服务 +To limit the access to the `nginx` service so that only Pods with the label `access: true` can query it, create a NetworkPolicy object as follows: +--> +## 限制 `nginx` 服务的访问 +如果想限制对 `nginx` 服务的访问，只让那些拥有标签 `access: true` 的 Pod 访问它， +那么可以创建一个如下所示的 NetworkPolicy 对象： -如果说您想限制 `nginx` 服务，只让那些拥有标签 `access: true` 的 pod 访问它，那么您可以创建一个只允许从那些 pod 连接的 `NetworkPolicy`： +{{< codenew file="service/networking/nginx-policy.yaml" >}} -```yaml -kind: NetworkPolicy -apiVersion: networking.k8s.io/v1 -metadata: - name: access-nginx -spec: - podSelector: - matchLabels: - run: nginx - ingress: - - from: - - podSelector: - matchLabels: - access: "true" -``` +<!-- +The name of a NetworkPolicy object must be a valid +[DNS subdomain name](/docs/concepts/overview/working-with-objects/names#dns-subdomain-names). +--> +NetworkPolicy 对象的名称必须是一个合法的 +[DNS 子域名](/zh/docs/concepts/overview/working-with-objects/names#dns-subdomain-names). +<!-- +NetworkPolicy includes a `podSelector` which selects the grouping of Pods to which the policy applies. You can see this policy selects Pods with the label `app=nginx`. The label was automatically added to the Pod in the `nginx` Deployment. An empty `podSelector` selects all pods in the namespace. +--> +{{< note >}} +NetworkPolicy 中包含选择策略所适用的 Pods 集合的 `podSelector`。 +你可以看到上面的策略选择的是带有标签 `app=nginx` 的 Pods。 +此标签是被自动添加到 `nginx` Deployment 中的 Pod 上的。 +如果 `podSelector` 为空，则意味着选择的是名字空间中的所有 Pods。 +{{< /note >}} +<!-- +## Assign the policy to the service + +Use kubectl to create a NetworkPolicy from the above `nginx-policy.yaml` file: +--> ## 为服务指定策略 - -使用 kubectl 工具根据上面的 nginx-policy.yaml 文件创建一个 NetworkPolicy： +使用 kubectl 根据上面的 `nginx-policy.yaml` 文件创建一个 NetworkPolicy： ```console -$ kubectl create -f nginx-policy.yaml -networkpolicy "access-nginx" created +kubectl apply -f https://k8s.io/examples/service/networking/nginx-policy.yaml +``` +```none +networkpolicy.networking.k8s.io/access-nginx created ``` +<!-- +## Test access to the service when access label is not defined -## 当访问标签没有定义时测试访问服务 +When you attempt to access the `nginx` Service from a Pod without the correct labels, the request times out: +--> +## 测试没有定义访问标签时访问服务 - -如果您尝试从没有设定正确标签的 pod 中去访问 `nginx` 服务，请求将会超时： +如果你尝试从没有设定正确标签的 Pod 中去访问 `nginx` 服务，请求将会超时： ```console -$ kubectl run busybox --rm -ti --image=busybox /bin/sh -Waiting for pod default/busybox-472357175-y0m47 to be running, status is Pending, pod ready: false +kubectl run busybox --rm -ti --image=busybox -- /bin/sh +``` -Hit enter for command prompt +<!-- +In your shell, run the command: +--> +在 Shell 中运行命令： -/ # wget --spider --timeout=1 nginx +```shell +wget --spider --timeout=1 nginx +``` + +```none Connecting to nginx (10.100.0.16:80) wget: download timed out -/ # ``` +<!-- +## Define access label and test again +You can create a Pod with the correct labels to see that the request is allowed: +--> ## 定义访问标签后再次测试 - -创建一个拥有正确标签的 pod，您将看到请求是被允许的： +创建一个拥有正确标签的 Pod，你将看到请求是被允许的： ```console -$ kubectl run busybox --rm -ti --labels="access=true" --image=busybox /bin/sh -Waiting for pod default/busybox-472357175-y0m47 to be running, status is Pending, pod ready: false +kubectl run busybox --rm -ti --labels="access=true" --image=busybox -- /bin/sh +``` +<!-- +In your shell, run the command: +--> +在 Shell 中运行命令： -Hit enter for command prompt - -/ # wget --spider --timeout=1 nginx -Connecting to nginx (10.100.0.16:80) -/ # +```shell +wget --spider --timeout=1 nginx ``` - +```none +Connecting to nginx (10.100.0.16:80) +remote file exists +``` diff --git a/content/zh/docs/tasks/administer-cluster/dns-debugging-resolution.md b/content/zh/docs/tasks/administer-cluster/dns-debugging-resolution.md index 41b392fd07..5a34f2331d 100644 --- a/content/zh/docs/tasks/administer-cluster/dns-debugging-resolution.md +++ b/content/zh/docs/tasks/administer-cluster/dns-debugging-resolution.md @@ -504,7 +504,6 @@ Systemd-resolved 会用一个 stub 文件来覆盖 `/etc/resolv.conf`从而在 kubeadm (>= 1.11) 会自动检测`systemd-resolved`并对应的更改 kubelet 的标签。 <!-- - Kubernetes installs do not configure the nodes' `resolv.conf` files to use the cluster DNS by default, because that process is inherently distribution-specific. This should probably be implemented eventually. @@ -522,9 +521,7 @@ If you are using Alpine version 3.3 or earlier as your base image, DNS may not work properly owing to a known issue with Alpine. Check [here](https://github.com/kubernetes/kubernetes/issues/30215) for more information. - --> - Kubernetes 的安装并不会默认配置节点的 `resolv.conf` 文件来使用集群的 DNS 服务，因为这个配置对于不同的发行版本是不一样的。这个问题应该迟早会被解决的。 Linux 的 libc 会在仅有三个 DNS 的 `nameserver` 和六个 DNS 的`search` 记录时会不可思议的卡死 ([详情请查阅这个2005年的bug](https://bugzilla.redhat.com/show_bug.cgi?id=168253))。Kubernetes 需要占用一个 `nameserver` 记录和三个`search`记录。这意味着如果一个本地的安装已经使用了三个`nameserver`或者使用了超过三个的 `search`记录，那有些配置很可能会丢失。有一个不完整的解决方案就是在节点上使用`dnsmasq`来提供更多的`nameserver`配置，但是无法提供更多的`search`记录。您也可以使用kubelet 的 `--resolv-conf` 标签来解决这个问题。 @@ -532,24 +529,6 @@ Linux 的 libc 会在仅有三个 DNS 的 `nameserver` 和六个 DNS 的`search` 如果您是使用 Alpine 3.3 或者更早版本作为您的基础镜像，DNS 可能会由于Alpine 一个已知的问题导致无法正常工作，请查看[这里](https://github.com/kubernetes/kubernetes/issues/30215)获取更多资料。 <!-- - -## Kubernetes Federation (Multiple Zone support) - -Release 1.3 introduced Cluster Federation support for multi-site Kubernetes -installations. This required some minor (backward-compatible) changes to the -way the Kubernetes cluster DNS server processes DNS queries, to facilitate -the lookup of federated services (which span multiple Kubernetes clusters). -See the [Cluster Federation Administrators' Guide](/docs/concepts/cluster-administration/federation/) -for more details on Cluster Federation and multi-site support. - -## --> - -## Kubernetes Federation (支持多区域部署) - -自从 1.3 版本支持了多个 Kubernetes 的联邦集群后，集群 DNS 服务在处理 DNS 请求时需要有一些微弱的调整 (这是向下兼容的)，从而可以使用跨越多个 Kubernetes 集群的联邦服务。请看 [联邦集群管理向导](/docs/concepts/cluster-administration/federation/) 获取更多关于联邦集群和多点支持的信息。 - -<!-- - ## References - [DNS for Services and Pods](/docs/concepts/services-networking/dns-pod-service/) @@ -557,10 +536,7 @@ for more details on Cluster Federation and multi-site support. ## What's next - [Autoscaling the DNS Service in a Cluster](/docs/tasks/administer-cluster/dns-horizontal-autoscaling/). - - - -## --> +--> ## 参考 @@ -572,6 +548,3 @@ for more details on Cluster Federation and multi-site support. - [集群里自动伸缩 DNS Service](/docs/tasks/administer-cluster/dns-horizontal-autoscaling/). - - - diff --git a/content/zh/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade.md b/content/zh/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade.md index ad176a8e5f..b005e3e343 100644 --- a/content/zh/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade.md +++ b/content/zh/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade.md @@ -28,10 +28,12 @@ please refer to following pages instead: 要查看 kubeadm 创建的有关旧版本集群升级的信息，请参考以下页面： <!-- +- [Upgrading kubeadm cluster from 1.16 to 1.17](https://v1-17.docs.kubernetes.io/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade/) - [Upgrading kubeadm cluster from 1.15 to 1.16](https://v1-16.docs.kubernetes.io/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade/) - [Upgrading kubeadm cluster from 1.14 to 1.15](https://v1-15.docs.kubernetes.io/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade-1-15/) - [Upgrading kubeadm cluster from 1.13 to 1.14](https://v1-15.docs.kubernetes.io/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade-1-14/) --> +- [将 kubeadm 集群从 1.16 升级到 1.17](https://v1-17.docs.kubernetes.io/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade/) - [将 kubeadm 集群从 1.15 升级到 1.16](https://v1-16.docs.kubernetes.io/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade/) - [将 kubeadm 集群从 1.14 升级到 1.15](https://v1-15.docs.kubernetes.io/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade-1-15/) - [将 kubeadm 集群从 1.13 升级到 1.14](https://v1-15.docs.kubernetes.io/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade-1-14/) @@ -43,17 +45,14 @@ The upgrade workflow at high level is the following: 1. Upgrade additional control plane nodes. 1. Upgrade worker nodes. --> -高版本升级工作流如下： +升级工作的基本流程如下： 1. 升级主控制平面节点。 1. 升级其他控制平面节点。 1. 升级工作节点。 - - ## {{% heading "prerequisites" %}} - <!-- - You need to have a kubeadm Kubernetes cluster running version 1.16.0 or later. - [Swap must be disabled](https://serverfault.com/questions/684771/best-way-to-disable-swap-in-linux). @@ -84,8 +83,6 @@ The upgrade workflow at high level is the following: - 您只能从一个次版本升级到下一个次版本，或者同样次版本的补丁版。也就是说，升级时无法跳过版本。 例如，您只能从 1.y 升级到 1.y+1，而不能从 from 1.y 升级到 1.y+2。 - - <!-- steps --> <!-- @@ -94,335 +91,362 @@ The upgrade workflow at high level is the following: ## 确定要升级到哪个版本 <!-- -1. Find the latest stable 1.17 version: +Find the latest stable 1.18 version: - {{< tabs name="k8s_install_versions" >}} - {{% tab name="Ubuntu, Debian or HypriotOS" %}} +{{< tabs name="k8s_install_versions" >}} +{{% tab name="Ubuntu, Debian or HypriotOS" %}} apt update apt-cache policy kubeadm - # find the latest 1.17 version in the list - # it should look like 1.17.x-00, where x is the latest patch - {{% /tab %}} - {{% tab name="CentOS, RHEL or Fedora" %}} + # find the latest 1.18 version in the list + # it should look like 1.18.x-00, where x is the latest patch +{{% /tab %}} +{{% tab name="CentOS, RHEL or Fedora" %}} yum list --showduplicates kubeadm --disableexcludes=kubernetes - # find the latest 1.17 version in the list - # it should look like 1.17.x-0, where x is the latest patch - {{% /tab %}} - {{< /tabs >}} + # find the latest 1.18 version in the list + # it should look like 1.18.x-0, where x is the latest patch +{{% /tab %}} +{{< /tabs >}} --> -1. 找到最新的稳定版 1.17: +找到最新的稳定版 1.18： - {{< tabs name="k8s_install_versions" >}} - {{% tab name="Ubuntu, Debian or HypriotOS" %}} +{{< tabs name="k8s_install_versions" >}} +{{% tab name="Ubuntu, Debian or HypriotOS" %}} apt update apt-cache policy kubeadm - # 在列表中查找最新的 1.17 版本 - # 它看起来应该是 1.17.x-00 ，其中 x 是最新的补丁 - {{% /tab %}} - {{% tab name="CentOS, RHEL or Fedora" %}} + # 在列表中查找最新的 1.18 版本 + # 它看起来应该是 1.18.x-00 ，其中 x 是最新的补丁 +{{% /tab %}} +{{% tab name="CentOS, RHEL or Fedora" %}} yum list --showduplicates kubeadm --disableexcludes=kubernetes - # 在列表中查找最新的 1.17 版本 - # 它看起来应该是 1.17.x-0 ，其中 x 是最新的补丁 - {{% /tab %}} - {{< /tabs >}} + # 在列表中查找最新的 1.18 版本 + # 它看起来应该是 1.18.x-0 ，其中 x 是最新的补丁版本 +{{% /tab %}} +{{< /tabs >}} <!-- -## Upgrade the first control plane node +## Upgrade the control plane node + +### Upgrade the first control plane node --> -## 升级第一个控制平面节点 +## 升级控制平面节点 + +### 升级第一个控制面节点 <!-- -1. On your first control plane node, upgrade kubeadm: +- On your first control plane node, upgrade kubeadm: - {{< tabs name="k8s_install_kubeadm_first_cp" >}} - {{% tab name="Ubuntu, Debian or HypriotOS" %}} - # replace x in 1.17.x-00 with the latest patch version +{{< tabs name="k8s_install_kubeadm_first_cp" >}} +{{% tab name="Ubuntu, Debian or HypriotOS" %}} + # replace x in 1.18.x-00 with the latest patch version apt-mark unhold kubeadm && \ - apt-get update && apt-get install -y kubeadm=1.17.x-00 && \ + apt-get update && apt-get install -y kubeadm=1.18.x-00 && \ apt-mark hold kubeadm - {{% /tab %}} - {{% tab name="CentOS, RHEL or Fedora" %}} - # replace x in 1.17.x-0 with the latest patch version - yum install -y kubeadm-1.17.x-0 --disableexcludes=kubernetes - {{% /tab %}} - {{< /tabs >}} +{{% /tab %}} +{{% tab name="CentOS, RHEL or Fedora" %}} + # replace x in 1.18.x-0 with the latest patch version + yum install -y kubeadm-1.18.x-0 -disableexcludes=kubernetes +{{% /tab %}} +{{< /tabs >}} --> -1. 在第一个控制平面节点上，升级 kubeadm : +- 在第一个控制平面节点上，升级 kubeadm : - {{< tabs name="k8s_install_kubeadm_first_cp" >}} - {{% tab name="Ubuntu, Debian or HypriotOS" %}} - # 用最新的修补程序版本替换 1.17.x-00 中的 x +{{< tabs name="k8s_install_kubeadm_first_cp" >}} +{{% tab name="Ubuntu, Debian or HypriotOS" %}} + # 用最新的修补程序版本替换 1.18.x-00 中的 x apt-mark unhold kubeadm && \ - apt-get update && apt-get install -y kubeadm=1.17.x-00 && \ + apt-get update && apt-get install -y kubeadm=1.18.x-00 && \ apt-mark hold kubeadm - {{% /tab %}} - {{% tab name="CentOS, RHEL or Fedora" %}} - # 用最新的修补程序版本替换 1.17.x-0 中的 x - yum install -y kubeadm-1.17.x-0 --disableexcludes=kubernetes - {{% /tab %}} - {{< /tabs >}} +{{% /tab %}} +{{% tab name="CentOS, RHEL or Fedora" %}} + # 用最新的修补程序版本替换 1.18.x-0 中的 x + yum install -y kubeadm-1.18.x-0 --disableexcludes=kubernetes +{{% /tab %}} +{{< /tabs >}} <!-- -1. Verify that the download works and has the expected version: +- Verify that the download works and has the expected version: - ```shell - kubeadm version - ``` + ```shell + kubeadm version + ``` --> -1. 验证 kubeadm 版本： +- 验证下载操作正常，并且 kubeadm 版本正确： - ```shell - kubeadm version - ``` + ```shell + kubeadm version + ``` <!-- -1. Drain the control plane node: +- Drain the control plane node: + ```shell + # replace <cp-node-name> with the name of your control plane node + kubectl drain $CP_NODE -ignore-daemonsets + ``` --> -1. 腾空控制平面节点： +- 腾空控制平面节点： - ```shell - kubectl drain $CP_NODE --ignore-daemonsets - ``` + ```shell + # 将 <cp-node-name> 替换为你自己的控制面节点名称 + kubectl drain <cp-node-name> --ignore-daemonsets + ``` <!-- -1. On the control plane node, run: +- On the control plane node, run: --> -1. 在主节点上，运行: +- 在控制面节点上，运行: - ```shell - sudo kubeadm upgrade plan - ``` + ```shell + sudo kubeadm upgrade plan + ``` - <!-- - You should see output similar to this: - --> - 您应该可以看到与下面类似的输出： + <!-- + You should see output similar to this: + --> + 您应该可以看到与下面类似的输出： - ```shell - [preflight] Running pre-flight checks. - [upgrade] Making sure the cluster is healthy: - [upgrade/config] Making sure the configuration is correct: - [upgrade/config] Reading configuration from the cluster... - [upgrade/config] FYI: You can look at this config file with 'kubectl -n kube-system get cm kubeadm-config -oyaml' - [upgrade] Fetching available versions to upgrade to - [upgrade/versions] Cluster version: v1.16.0 - [upgrade/versions] kubeadm version: v1.17.0 + ```none + [upgrade/config] Making sure the configuration is correct: + [upgrade/config] Reading configuration from the cluster... + [upgrade/config] FYI: You can look at this config file with 'kubectl -n kube-system get cm kubeadm-config -oyaml' + [preflight] Running pre-flight checks. + [upgrade] Running cluster health checks + [upgrade] Fetching available versions to upgrade to + [upgrade/versions] Cluster version: v1.17.3 + [upgrade/versions] kubeadm version: v1.18.0 + [upgrade/versions] Latest stable version: v1.18.0 + [upgrade/versions] Latest version in the v1.17 series: v1.18.0 - Components that must be upgraded manually after you have upgraded the control plane with 'kubeadm upgrade apply': - COMPONENT CURRENT AVAILABLE - Kubelet 1 x v1.16.0 v1.17.0 + Components that must be upgraded manually after you have upgraded the control plane with 'kubeadm upgrade apply': + COMPONENT CURRENT AVAILABLE + Kubelet 1 x v1.17.3 v1.18.0 - Upgrade to the latest version in the v1.13 series: + Upgrade to the latest version in the v1.17 series: - COMPONENT CURRENT AVAILABLE - API Server v1.16.0 v1.17.0 - Controller Manager v1.16.0 v1.17.0 - Scheduler v1.16.0 v1.17.0 - Kube Proxy v1.16.0 v1.17.0 - CoreDNS 1.6.2 1.6.5 - Etcd 3.3.15 3.4.3-0 + COMPONENT CURRENT AVAILABLE + API Server v1.17.3 v1.18.0 + Controller Manager v1.17.3 v1.18.0 + Scheduler v1.17.3 v1.18.0 + Kube Proxy v1.17.3 v1.18.0 + CoreDNS 1.6.5 1.6.7 + Etcd 3.4.3 3.4.3-0 - You can now apply the upgrade by executing the following command: + You can now apply the upgrade by executing the following command: - kubeadm upgrade apply v1.17.0 + kubeadm upgrade apply v1.18.0 - _____________________________________________________________________ - ``` + _____________________________________________________________________ + ``` - <!-- - This command checks that your cluster can be upgraded, and fetches the versions you can upgrade to. - --> - 此命令检查您的集群是否可以升级，并可以获取到升级的版本。 + <!-- + This command checks that your cluster can be upgraded, and fetches the versions you can upgrade to. + --> + 此命令检查您的集群是否可以升级，并可以获取到升级的版本。 <!-- -1. Choose a version to upgrade to, and run the appropriate command. For example: +`kubeadm upgrade` also automatically renews the certificates that it manages on this node. +To opt-out of certificate renewal the flag `-certificate-renewal=false` can be used. +For more information see the [certificate management guide](/docs/tasks/administer-cluster/kubeadm/kubeadm-certs). --> -1. 选择要升级到的版本，然后运行相应的命令。例如: - ```shell - sudo kubeadm upgrade apply v1.17.x - ``` - - <!-- - - Replace `x` with the patch version you picked for this ugprade. - --> - - 将 `x` 替换为您为此升级选择的修补程序版本。 - - <!-- - You should see output similar to this: - --> - 您应该可以看见与下面类似的输出： - - ```shell - [preflight] Running pre-flight checks. - [upgrade] Making sure the cluster is healthy: - [upgrade/config] Making sure the configuration is correct: - [upgrade/config] Reading configuration from the cluster... - [upgrade/config] FYI: You can look at this config file with 'kubectl -n kube-system get cm kubeadm-config -oyaml' - [upgrade/version] You have chosen to change the cluster version to "v1.17.0" - [upgrade/versions] Cluster version: v1.16.0 - [upgrade/versions] kubeadm version: v1.17.0 - [upgrade/confirm] Are you sure you want to proceed with the upgrade? [y/N]: y - [upgrade/prepull] Will prepull images for components [kube-apiserver kube-controller-manager kube-scheduler etcd] - [upgrade/prepull] Prepulling image for component etcd. - [upgrade/prepull] Prepulling image for component kube-scheduler. - [upgrade/prepull] Prepulling image for component kube-apiserver. - [upgrade/prepull] Prepulling image for component kube-controller-manager. - [apiclient] Found 0 Pods for label selector k8s-app=upgrade-prepull-etcd - [apiclient] Found 0 Pods for label selector k8s-app=upgrade-prepull-kube-scheduler - [apiclient] Found 0 Pods for label selector k8s-app=upgrade-prepull-kube-controller-manager - [apiclient] Found 0 Pods for label selector k8s-app=upgrade-prepull-kube-apiserver - [apiclient] Found 1 Pods for label selector k8s-app=upgrade-prepull-etcd - [apiclient] Found 1 Pods for label selector k8s-app=upgrade-prepull-kube-controller-manager - [apiclient] Found 1 Pods for label selector k8s-app=upgrade-prepull-kube-scheduler - [apiclient] Found 1 Pods for label selector k8s-app=upgrade-prepull-kube-apiserver - [upgrade/prepull] Prepulled image for component etcd. - [upgrade/prepull] Prepulled image for component kube-apiserver. - [upgrade/prepull] Prepulled image for component kube-scheduler. - [upgrade/prepull] Prepulled image for component kube-controller-manager. - [upgrade/prepull] Successfully prepulled the images for all the control plane components - [upgrade/apply] Upgrading your Static Pod-hosted control plane to version "v1.17.0"... - Static pod: kube-apiserver-myhost hash: 6436b0d8ee0136c9d9752971dda40400 - Static pod: kube-controller-manager-myhost hash: 8ee730c1a5607a87f35abb2183bf03f2 - Static pod: kube-scheduler-myhost hash: 4b52d75cab61380f07c0c5a69fb371d4 - [upgrade/etcd] Upgrading to TLS for etcd - Static pod: etcd-myhost hash: 877025e7dd7adae8a04ee20ca4ecb239 - [upgrade/staticpods] Moved new manifest to "/etc/kubernetes/manifests/etcd.yaml" and backed up old manifest to "/etc/kubernetes/tmp/kubeadm-backup-manifests-2019-03-14-20-52-44/etcd.yaml" - [upgrade/staticpods] Waiting for the kubelet to restart the component - [upgrade/staticpods] This might take a minute or longer depending on the component/version gap (timeout 5m0s) - Static pod: etcd-myhost hash: 877025e7dd7adae8a04ee20ca4ecb239 - Static pod: etcd-myhost hash: 877025e7dd7adae8a04ee20ca4ecb239 - Static pod: etcd-myhost hash: 64a28f011070816f4beb07a9c96d73b6 - [apiclient] Found 1 Pods for label selector component=etcd - [upgrade/staticpods] Component "etcd" upgraded successfully! - [upgrade/etcd] Waiting for etcd to become available - [upgrade/staticpods] Writing new Static Pod manifests to "/etc/kubernetes/tmp/kubeadm-upgraded-manifests043818770" - [upgrade/staticpods] Moved new manifest to "/etc/kubernetes/manifests/kube-apiserver.yaml" and backed up old manifest to "/etc/kubernetes/tmp/kubeadm-backup-manifests-2019-03-14-20-52-44/kube-apiserver.yaml" - [upgrade/staticpods] Waiting for the kubelet to restart the component - [upgrade/staticpods] This might take a minute or longer depending on the component/version gap (timeout 5m0s) - Static pod: kube-apiserver-myhost hash: 6436b0d8ee0136c9d9752971dda40400 - Static pod: kube-apiserver-myhost hash: 6436b0d8ee0136c9d9752971dda40400 - Static pod: kube-apiserver-myhost hash: 6436b0d8ee0136c9d9752971dda40400 - Static pod: kube-apiserver-myhost hash: b8a6533e241a8c6dab84d32bb708b8a1 - [apiclient] Found 1 Pods for label selector component=kube-apiserver - [upgrade/staticpods] Component "kube-apiserver" upgraded successfully! - [upgrade/staticpods] Moved new manifest to "/etc/kubernetes/manifests/kube-controller-manager.yaml" and backed up old manifest to "/etc/kubernetes/tmp/kubeadm-backup-manifests-2019-03-14-20-52-44/kube-controller-manager.yaml" - [upgrade/staticpods] Waiting for the kubelet to restart the component - [upgrade/staticpods] This might take a minute or longer depending on the component/version gap (timeout 5m0s) - Static pod: kube-controller-manager-myhost hash: 8ee730c1a5607a87f35abb2183bf03f2 - Static pod: kube-controller-manager-myhost hash: 6f77d441d2488efd9fc2d9a9987ad30b - [apiclient] Found 1 Pods for label selector component=kube-controller-manager - [upgrade/staticpods] Component "kube-controller-manager" upgraded successfully! - [upgrade/staticpods] Moved new manifest to "/etc/kubernetes/manifests/kube-scheduler.yaml" and backed up old manifest to "/etc/kubernetes/tmp/kubeadm-backup-manifests-2019-03-14-20-52-44/kube-scheduler.yaml" - [upgrade/staticpods] Waiting for the kubelet to restart the component - [upgrade/staticpods] This might take a minute or longer depending on the component/version gap (timeout 5m0s) - Static pod: kube-scheduler-myhost hash: 4b52d75cab61380f07c0c5a69fb371d4 - Static pod: kube-scheduler-myhost hash: a24773c92bb69c3748fcce5e540b7574 - [apiclient] Found 1 Pods for label selector component=kube-scheduler - [upgrade/staticpods] Component "kube-scheduler" upgraded successfully! - [upload-config] storing the configuration used in ConfigMap "kubeadm-config" in the "kube-system" Namespace - [kubelet] Creating a ConfigMap "kubelet-config-1.17" in namespace kube-system with the configuration for the kubelets in the cluster - [kubelet-start] Downloading configuration for the kubelet from the "kubelet-config-1.17" ConfigMap in the kube-system namespace - [kubelet-start] Writing kubelet configuration to file "/var/lib/kubelet/config.yaml" - [bootstrap-token] configured RBAC rules to allow Node Bootstrap tokens to post CSRs in order for nodes to get long term certificate credentials - [bootstrap-token] configured RBAC rules to allow the csrapprover controller automatically approve CSRs from a Node Bootstrap Token - [bootstrap-token] configured RBAC rules to allow certificate rotation for all node client certificates in the cluster - [addons] Applied essential addon: CoreDNS - [addons] Applied essential addon: kube-proxy - - [upgrade/successful] SUCCESS! Your cluster was upgraded to "v1.17.0". Enjoy! - - [upgrade/kubelet] Now that your control plane is upgraded, please proceed with upgrading your kubelets if you haven't already done so. - ``` +{{< note >}} +`kubeadm upgrade` 也会自动对它在此节点上管理的证书进行续约。 +如果选择不对证书进行续约，可以使用标志 `--certificate-renewal=false`。 +关于更多细节信息，可参见[证书管理指南](/docs/tasks/administer-cluster/kubeadm/kubeadm-certs)。 +{{</ note >}} <!-- -1. Manually upgrade your CNI provider plugin. ---> -1. 手动升级你的 CNI 供应商插件。 +- Choose a version to upgrade to, and run the appropriate command. For example: + + ```shell + # replace x with the patch version you picked for this upgrade + sudo kubeadm upgrade apply v1.18.x + ``` +--> +- 选择要升级到的版本，然后运行相应的命令。例如: + + ```shell + # 将 x 替换为你为此次升级所选的补丁版本号 + sudo kubeadm upgrade apply v1.18.x + ``` + + <!-- + You should see output similar to this: + --> + 您应该可以看见与下面类似的输出： + + ```none + [upgrade/config] Making sure the configuration is correct: + [upgrade/config] Reading configuration from the cluster... + [upgrade/config] FYI: You can look at this config file with 'kubectl -n kube-system get cm kubeadm-config -oyaml' + [preflight] Running pre-flight checks. + [upgrade] Running cluster health checks + [upgrade/version] You have chosen to change the cluster version to "v1.18.0" + [upgrade/versions] Cluster version: v1.17.3 + [upgrade/versions] kubeadm version: v1.18.0 + [upgrade/confirm] Are you sure you want to proceed with the upgrade? [y/N]: y + [upgrade/prepull] Will prepull images for components [kube-apiserver kube-controller-manager kube-scheduler etcd] + [upgrade/prepull] Prepulling image for component etcd. + [upgrade/prepull] Prepulling image for component kube-apiserver. + [upgrade/prepull] Prepulling image for component kube-controller-manager. + [upgrade/prepull] Prepulling image for component kube-scheduler. + [apiclient] Found 1 Pods for label selector k8s-app=upgrade-prepull-kube-controller-manager + [apiclient] Found 0 Pods for label selector k8s-app=upgrade-prepull-etcd + [apiclient] Found 0 Pods for label selector k8s-app=upgrade-prepull-kube-scheduler + [apiclient] Found 1 Pods for label selector k8s-app=upgrade-prepull-kube-apiserver + [apiclient] Found 1 Pods for label selector k8s-app=upgrade-prepull-etcd + [apiclient] Found 1 Pods for label selector k8s-app=upgrade-prepull-kube-scheduler + [upgrade/prepull] Prepulled image for component etcd. + [upgrade/prepull] Prepulled image for component kube-apiserver. + [upgrade/prepull] Prepulled image for component kube-controller-manager. + [upgrade/prepull] Prepulled image for component kube-scheduler. + [upgrade/prepull] Successfully prepulled the images for all the control plane components + [upgrade/apply] Upgrading your Static Pod-hosted control plane to version "v1.18.0"... + Static pod: kube-apiserver-myhost hash: 2cc222e1a577b40a8c2832320db54b46 + Static pod: kube-controller-manager-myhost hash: f7ce4bc35cb6e646161578ac69910f18 + Static pod: kube-scheduler-myhost hash: e3025acd90e7465e66fa19c71b916366 + [upgrade/etcd] Upgrading to TLS for etcd + [upgrade/etcd] Non fatal issue encountered during upgrade: the desired etcd version for this Kubernetes version "v1.18.0" is "3.4.3-0", but the current etcd version is "3.4.3". Won't downgrade etcd, instead just continue + [upgrade/staticpods] Writing new Static Pod manifests to "/etc/kubernetes/tmp/kubeadm-upgraded-manifests308527012" + W0308 18:48:14.535122 3082 manifests.go:225] the default kube-apiserver authorization-mode is "Node,RBAC"; using "Node,RBAC" + [upgrade/staticpods] Preparing for "kube-apiserver" upgrade + [upgrade/staticpods] Renewing apiserver certificate + [upgrade/staticpods] Renewing apiserver-kubelet-client certificate + [upgrade/staticpods] Renewing front-proxy-client certificate + [upgrade/staticpods] Renewing apiserver-etcd-client certificate + [upgrade/staticpods] Moved new manifest to "/etc/kubernetes/manifests/kube-apiserver.yaml" and backed up old manifest to "/etc/kubernetes/tmp/kubeadm-backup-manifests-2020-03-08-18-48-14/kube-apiserver.yaml" + [upgrade/staticpods] Waiting for the kubelet to restart the component + [upgrade/staticpods] This might take a minute or longer depending on the component/version gap (timeout 5m0s) + Static pod: kube-apiserver-myhost hash: 2cc222e1a577b40a8c2832320db54b46 + Static pod: kube-apiserver-myhost hash: 609429acb0d71dce6725836dd97d8bf4 + [apiclient] Found 1 Pods for label selector component=kube-apiserver + [upgrade/staticpods] Component "kube-apiserver" upgraded successfully! + [upgrade/staticpods] Preparing for "kube-controller-manager" upgrade + [upgrade/staticpods] Renewing controller-manager.conf certificate + [upgrade/staticpods] Moved new manifest to "/etc/kubernetes/manifests/kube-controller-manager.yaml" and backed up old manifest to "/etc/kubernetes/tmp/kubeadm-backup-manifests-2020-03-08-18-48-14/kube-controller-manager.yaml" + [upgrade/staticpods] Waiting for the kubelet to restart the component + [upgrade/staticpods] This might take a minute or longer depending on the component/version gap (timeout 5m0s) + Static pod: kube-controller-manager-myhost hash: f7ce4bc35cb6e646161578ac69910f18 + Static pod: kube-controller-manager-myhost hash: c7a1232ba2c5dc15641c392662fe5156 + [apiclient] Found 1 Pods for label selector component=kube-controller-manager + [upgrade/staticpods] Component "kube-controller-manager" upgraded successfully! + [upgrade/staticpods] Preparing for "kube-scheduler" upgrade + [upgrade/staticpods] Renewing scheduler.conf certificate + [upgrade/staticpods] Moved new manifest to "/etc/kubernetes/manifests/kube-scheduler.yaml" and backed up old manifest to "/etc/kubernetes/tmp/kubeadm-backup-manifests-2020-03-08-18-48-14/kube-scheduler.yaml" + [upgrade/staticpods] Waiting for the kubelet to restart the component + [upgrade/staticpods] This might take a minute or longer depending on the component/version gap (timeout 5m0s) + Static pod: kube-scheduler-myhost hash: e3025acd90e7465e66fa19c71b916366 + Static pod: kube-scheduler-myhost hash: b1b721486ae0ac504c160dcdc457ab0d + [apiclient] Found 1 Pods for label selector component=kube-scheduler + [upgrade/staticpods] Component "kube-scheduler" upgraded successfully! + [upload-config] Storing the configuration used in ConfigMap "kubeadm-config" in the "kube-system" Namespace + [kubelet] Creating a ConfigMap "kubelet-config-1.18" in namespace kube-system with the configuration for the kubelets in the cluster + [kubelet-start] Downloading configuration for the kubelet from the "kubelet-config-1.18" ConfigMap in the kube-system namespace + [kubelet-start] Writing kubelet configuration to file "/var/lib/kubelet/config.yaml" + [bootstrap-token] configured RBAC rules to allow Node Bootstrap tokens to post CSRs in order for nodes to get long term certificate credentials + [bootstrap-token] configured RBAC rules to allow the csrapprover controller automatically approve CSRs from a Node Bootstrap Token + [bootstrap-token] configured RBAC rules to allow certificate rotation for all node client certificates in the cluster + [addons] Applied essential addon: CoreDNS + [addons] Applied essential addon: kube-proxy + + [upgrade/successful] SUCCESS! Your cluster was upgraded to "v1.18.0". Enjoy! + + [upgrade/kubelet] Now that your control plane is upgraded, please proceed with upgrading your kubelets if you haven't already done so. + ``` + +<!-- +- Manually upgrade your CNI provider plugin. - <!-- Your Container Network Interface (CNI) provider may have its own upgrade instructions to follow. Check the [addons](/docs/concepts/cluster-administration/addons/) page to find your CNI provider and see whether additional upgrade steps are required. - --> - 您的容器网络接口（CNI）应该提供了程序自身的升级说明。 - 检查[插件](/docs/concepts/cluster-administration/addons/)页面查找您 CNI 所提供的程序，并查看是否需要其他升级步骤。 - <!-- This step is not required on additional control plane nodes if the CNI provider runs as a DaemonSet. - --> - 如果 CNI 提供程序作为 DaemonSet 运行，则在其他控制平面节点上不需要此步骤。 +--> +- 手动升级你的 CNI 驱动插件。 + + 您的容器网络接口（CNI）驱动应该提供了程序自身的升级说明。 + 检查[插件](/docs/concepts/cluster-administration/addons/)页面查找您 CNI 所提供的程序，并查看是否需要其他升级步骤。 + + 如果 CNI 提供程序作为 DaemonSet 运行，则在其他控制平面节点上不需要此步骤。 <!-- -1. Uncordon the control plane node ---> -1. 取消对控制面节点的保护 +- Uncordon the control plane node ```shell - kubectl uncordon $CP_NODE - ``` - -<!-- -1. Upgrade the kubelet and kubectl on the control plane node: ---> -1. 升级控制平面节点上的 kubelet 和 kubectl ： - {{< tabs name="k8s_install_kubelet" >}} - {{% tab name="Ubuntu, Debian or HypriotOS" %}} - # 用最新的修补程序版本替换 1.17.x-00 中的 x - apt-mark unhold kubelet kubectl && \ - apt-get update && apt-get install -y kubelet=1.17.x-00 kubectl=1.17.x-00 && \ - apt-mark hold kubelet kubectl - {{% /tab %}} - {{% tab name="CentOS, RHEL or Fedora" %}} - # 用最新的修补程序版本替换 1.17.x-00 中的 x - yum install -y kubelet-1.17.x-0 kubectl-1.17.x-0 --disableexcludes=kubernetes - {{% /tab %}} - {{< /tabs >}} - - -<!-- -1. Restart the kubelet ---> -1. 重启 kubelet - - ```shell - sudo systemctl restart kubelet + # replace <cp-node-name> with the name of your control plane node + kubectl uncordon <cp-node-name> ``` +--> +- 取消对控制面节点的保护 + + ```shell + # 将 <cp-node-name> 替换为你的控制面节点名称 + kubectl uncordon <cp-node-name> + ``` <!-- -## Upgrade additional control plane nodes ---> -## 升级其他控制平面节点 +### Upgrade additional control plane nodes -<!-- -1. Same as the first control plane node but use: +Same as the first control plane node but use: --> -1. 与第一个控制平面节点相同，但使用： +### 升级其他控制面节点 + +与第一个控制面节点类似，不过使用下面的命令： ``` -sudo kubeadm upgrade node experimental-control-plane +sudo kubeadm upgrade node ``` +<!-- instead of: --> 而不是： ``` sudo kubeadm upgrade apply ``` +<!-- Also `sudo kubeadm upgrade plan` is not needed. --> +同时，也不需要执行 `sudo kubeadm upgrade plan`。 + <!-- -Also `sudo kubeadm upgrade plan` is not needed. +### Upgrade kubelet and kubectl --> -也不需要 `sudo kubeadm upgrade plan` 。 +### 升级 kubelet 和 kubectl + +{{< tabs name="k8s_install_kubelet" >}} +{{% tab name="Ubuntu、Debian 或 HypriotOS" %}} + # 用最新的补丁版本替换 1.18.x-00 中的 x + apt-mark unhold kubelet kubectl && \ + apt-get update && apt-get install -y kubelet=1.18.x-00 kubectl=1.18.x-00 && \ + apt-mark hold kubelet kubectl + - + # 从 apt-get 的 1.1 版本开始，你也可以使用下面的方法： + apt-get update && \ + apt-get install -y --allow-change-held-packages kubelet=1.18.x-00 kubectl=1.18.x-00 +{{% /tab %}} +{{% tab name="CentOS、RHEL 或 Fedora" %}} + # 用最新的补丁版本替换 1.18.x-00 中的 x + yum install -y kubelet-1.18.x-0 kubectl-1.18.x-0 --disableexcludes=kubernetes +{{% /tab %}} +{{< /tabs >}} + +<!-- +Restart the kubelet +--> +重启 kubelet + +```shell +sudo systemctl daemon-reload +sudo systemctl restart kubelet +``` <!-- ## Upgrade worker nodes ---> -## 升级工作节点 -<!-- The upgrade procedure on worker nodes should be executed one node at a time or few nodes at a time, without compromising the minimum required capacity for running your workloads. --> +## 升级工作节点 + 工作节点上的升级过程应该一次执行一个节点，或者一次执行几个节点，以不影响运行工作负载所需的最小容量。 <!-- @@ -431,35 +455,39 @@ without compromising the minimum required capacity for running your workloads. ### 升级 kubeadm <!-- -1. Upgrade kubeadm on all worker nodes: +- Upgrade kubeadm on all worker nodes: - {{< tabs name="k8s_install_kubeadm_worker_nodes" >}} - {{% tab name="Ubuntu, Debian or HypriotOS" %}} - # replace x in 1.17.x-00 with the latest patch version +{{< tabs name="k8s_install_kubeadm_worker_nodes" >}} +{{% tab name="Ubuntu, Debian or HypriotOS" %}} + # replace x in 1.18.x-00 with the latest patch version apt-mark unhold kubeadm && \ - apt-get update && apt-get install -y kubeadm=1.17.x-00 && \ + apt-get update && apt-get install -y kubeadm=1.18.x-00 && \ apt-mark hold kubeadm - {{% /tab %}} - {{% tab name="CentOS, RHEL or Fedora" %}} - # replace x in 1.17.x-0 with the latest patch version - yum install -y kubeadm-1.17.x-0 --disableexcludes=kubernetes - {{% /tab %}} - {{< /tabs >}} +{{% /tab %}} +{{% tab name="CentOS, RHEL or Fedora" %}} + # replace x in 1.18.x-0 with the latest patch version + yum install -y kubeadm-1.18.x-0 -disableexcludes=kubernetes +{{% /tab %}} +{{< /tabs >}} --> -1. 在所有工作节点升级 kubeadm : +- 在所有工作节点升级 kubeadm: - {{< tabs name="k8s_install_kubeadm_worker_nodes" >}} - {{% tab name="Ubuntu, Debian or HypriotOS" %}} - # 用最新的修补程序版本替换 1.17.x-00 中的 x +{{< tabs name="k8s_install_kubeadm_worker_nodes" >}} +{{% tab name="Ubuntu、Debian 或 HypriotOS" %}} + # 将 1.18.x-00 中的 x 替换为最新的补丁版本 apt-mark unhold kubeadm && \ - apt-get update && apt-get install -y kubeadm=1.17.x-00 && \ + apt-get update && apt-get install -y kubeadm=1.18.x-00 && \ apt-mark hold kubeadm - {{% /tab %}} - {{% tab name="CentOS, RHEL or Fedora" %}} - # 用最新的修补程序版本替换 1.17.x-00 中的 x - yum install -y kubeadm-1.17.x-0 --disableexcludes=kubernetes - {{% /tab %}} - {{< /tabs >}} + - + # 从 apt-get 的 1.1 版本开始，你也可以使用下面的方法： + apt-get update && \ + apt-get install -y --allow-change-held-packages kubeadm=1.18.x-00 +{{% /tab %}} +{{% tab name="CentOS、RHEL 或 Fedora" %}} + # 用最新的补丁版本替换 1.18.x-00 中的 x + yum install -y kubeadm-1.18.x-0 --disableexcludes=kubernetes +{{% /tab %}} +{{< /tabs >}} <!-- ### Cordon the node @@ -470,8 +498,8 @@ without compromising the minimum required capacity for running your workloads. 1. Prepare the node for maintenance by marking it unschedulable and evicting the workloads. Run: ```shell - kubectl drain $NODE --ignore-daemonsets - ``` + # replace <node-to-drain> with the name of your node you are draining + kubectl drain <node-to-drain> --ignore-daemonsets You should see output similar to this: @@ -481,22 +509,23 @@ without compromising the minimum required capacity for running your workloads. node/ip-172-31-85-18 drained ``` --> -1. 通过将节点标记为不可调度并逐出工作负载，为维护做好准备。运行： +- 通过将节点标记为不可调度并逐出工作负载，为维护做好准备。运行： - ```shell - kubectl drain $NODE --ignore-daemonsets - ``` + ```shell + # 将 <node-to-drain> 替换为你正在腾空的节点的名称 + kubectl drain <node-to-drain> --ignore-daemonsets + ``` - <!-- - You should see output similar to this: - --> - 您应该可以看见与下面类似的输出： + <!-- + You should see output similar to this: + --> + 你应该可以看见与下面类似的输出： - ```shell - node/ip-172-31-85-18 cordoned - WARNING: ignoring DaemonSet-managed Pods: kube-system/kube-proxy-dj7d7, kube-system/weave-net-z65qx - node/ip-172-31-85-18 drained - ``` + ```shell + node/ip-172-31-85-18 cordoned + WARNING: ignoring DaemonSet-managed Pods: kube-system/kube-proxy-dj7d7, kube-system/weave-net-z65qx + node/ip-172-31-85-18 drained + ``` <!-- ### Upgrade the kubelet config @@ -507,22 +536,14 @@ without compromising the minimum required capacity for running your workloads. 1. Upgrade the kubelet config: ```shell - sudo kubeadm upgrade node config --kubelet-version v1.14.x + sudo kubeadm upgrade node ``` - - Replace `x` with the patch version you picked for this ugprade. --> -1. 升级 kubelet 配置: - - ```shell - sudo kubeadm upgrade node config --kubelet-version v1.14.x - ``` - - <!-- - Replace `x` with the patch version you picked for this ugprade. - --> - 用最新的修补程序版本替换 1.14.x-00 中的 x +- 升级 kubelet 配置: + ```shell + sudo kubeadm upgrade node + ``` <!-- ### Upgrade kubelet and kubectl @@ -530,66 +551,60 @@ without compromising the minimum required capacity for running your workloads. ### 升级 kubelet 与 kubectl <!-- -1. Upgrade the Kubernetes package version by running the Linux package manager for your distribution: - - {{< tabs name="k8s_kubelet_and_kubectl" >}} - {{% tab name="Ubuntu, Debian or HypriotOS" %}} - # replace x in 1.17.x-00 with the latest patch version - apt-mark unhold kubelet kubectl && \ - apt-get update && apt-get install -y kubelet=1.17.x-00 kubectl=1.17.x-00 && \ - apt-mark hold kubelet kubectl - {{% /tab %}} - {{% tab name="CentOS, RHEL or Fedora" %}} - # replace x in 1.17.x-0 with the latest patch version - yum install -y kubelet-1.17.x-0 kubectl-1.17.x-0 --disableexcludes=kubernetes - {{% /tab %}} - {{< /tabs >}} +- Upgrade the kubelet and kubectl on all worker nodes: --> -1. 通过运行适用于您的 Linux 发行版包管理器升级 Kubernetes 软件包版本： +- 在所有工作节点上升级 kubelet 和 kubectl： - {{< tabs name="k8s_kubelet_and_kubectl" >}} - {{% tab name="Ubuntu, Debian or HypriotOS" %}} - # 用最新的修补程序版本替换 1.17.x-00 中的 xs +{{< tabs name="k8s_kubelet_and_kubectl" >}} +{{% tab name="Ubuntu、Debian 或 HypriotOS" %}} + # 将 1.18.x-00 中的 x 替换为最新的补丁版本 apt-mark unhold kubelet kubectl && \ - apt-get update && apt-get install -y kubelet=1.17.x-00 kubectl=1.17.x-00 && \ + apt-get update && apt-get install -y kubelet=1.18.x-00 kubectl=1.18.x-00 && \ apt-mark hold kubelet kubectl - {{% /tab %}} - {{% tab name="CentOS, RHEL or Fedora" %}} - # 用最新的修补程序版本替换 1.17.x-00 中的 x - yum install -y kubelet-1.17.x-0 kubectl-1.17.x-0 --disableexcludes=kubernetes - {{% /tab %}} - {{< /tabs >}} + - + # 从 apt-get 的 1.1 版本开始，你也可以使用下面的方法： + apt-get update && \ + apt-get install -y --allow-change-held-packages kubelet=1.18.x-00 kubectl=1.18.x-00 +{{% /tab %}} +{{% tab name="CentOS, RHEL or Fedora" %}} + # 将 1.18.x-00 中的 x 替换为最新的补丁版本 + yum install -y kubelet-1.18.x-0 kubectl-1.18.x-0 --disableexcludes=kubernetes +{{% /tab %}} +{{< /tabs >}} <!-- -1. Restart the kubelet +- Restart the kubelet ```shell + sudo systemctl daemon-reload sudo systemctl restart kubelet ``` --> -1. 重启 kubelet - - ```shell - sudo systemctl restart kubelet - ``` +- 重启 kubelet + ```shell + sudo systemctl daemon-reload + sudo systemctl restart kubelet + ``` <!-- ### Uncordon the node --> ### 取消对节点的保护 <!-- -1. Bring the node back online by marking it schedulable: +- Bring the node back online by marking it schedulable: ```shell - kubectl uncordon $NODE + # replace <node-to-drain> with the name of your node + kubectl uncordon <node-to-drain> ``` --> -1. 通过将节点标记为可调度，让节点重新上线: +- 通过将节点标记为可调度，让节点重新上线: - ```shell - kubectl uncordon $NODE - ``` + ```shell + # 将 <node-to-drain> 替换为当前节点的名称 + kubectl uncordon <node-to-drain> + ``` <!-- ## Verify the status of the cluster @@ -613,8 +628,6 @@ The `STATUS` column should show `Ready` for all your nodes, and the version numb --> `STATUS` 应显示所有节点为 `Ready` 状态，并且版本号已经被更新。 - - <!-- ## Recovering from a failure state @@ -629,6 +642,35 @@ To recover from a bad state, you can also run `kubeadm upgrade --force` without 此命令是幂等的，并最终确保实际状态是您声明的所需状态。 要从故障状态恢复，您还可以运行 `kubeadm upgrade --force` 而不去更改集群正在运行的版本。 +<!-- +During upgrade kubeadm writes the following backup folders under `/etc/kubernetes/tmp`: +- `kubeadm-backup-etcd-<date>-<time>` +- `kubeadm-backup-manifests-<date>-<time>` + +`kubeadm-backup-etcd` contains a backup of the local etcd member data for this control-plane Node. +In case of an etcd upgrade failure and if the automatic rollback does not work, the contents of this folder +can be manually restored in `/var/lib/etcd`. In case external etcd is used this backup folder will be empty. + +`kubeadm-backup-manifests` contains a backup of the static Pod manifest files for this control-plane Node. +In case of a upgrade failure and if the automatic rollback does not work, the contents of this folder can be +manually restored in `/etc/kubernetes/manifests`. If for some reason there is no difference between a pre-upgrade +and post-upgrade manifest file for a certain component, a backup file for it will not be written. +--> +在升级期间，kubeadm 向 `/etc/kubernetes/tmp` 目录下的如下备份文件夹写入数据： + +- `kubeadm-backup-etcd-<date>-<time>` +- `kubeadm-backup-manifests-<date>-<time>` + +`kubeadm-backup-etcd` 包含当前控制面节点本地 etcd 成员数据的备份。 +如果 etcd 升级失败并且自动回滚也无法修复，则可以将此文件夹中的内容复制到 +`/var/lib/etcd` 进行手工修复。如果使用的是外部的 etcd，则此备份文件夹为空。 + +`kubeadm-backup-manifests` 包含当前控制面节点的静态 Pod 清单文件的备份版本。 +如果升级失败并且无法自动回滚，则此文件夹中的内容可以复制到 +`/etc/kubernetes/manifests` 目录实现手工恢复。 +如果由于某些原因，在升级前后某个组件的清单未发生变化，则 kubeadm 也不会为之 +生成备份版本。 + <!-- ## How it works @@ -644,27 +686,42 @@ To recover from a bad state, you can also run `kubeadm upgrade --force` without - Applies the new `kube-dns` and `kube-proxy` manifests and makes sure that all necessary RBAC rules are created. - Creates new certificate and key files of the API server and backs up old files if they're about to expire in 180 days. --> -## 它是怎么工作的 +## 工作原理 `kubeadm upgrade apply` 做了以下工作： - 检查您的集群是否处于可升级状态: - API 服务器是可访问的 - 所有节点处于 `Ready` 状态 - - 控制平面是健康的 + - 控制面是健康的 - 强制执行版本 skew 策略。 -- 确保控制平面的镜像是可用的或可拉取到服务器上。 -- 升级控制平面组件或回滚（如果其中任何一个组件无法启动）。 +- 确保控制面的镜像是可用的或可拉取到服务器上。 +- 升级控制面组件或回滚（如果其中任何一个组件无法启动）。 - 应用新的 `kube-dns` 和 `kube-proxy` 清单，并强制创建所有必需的 RBAC 规则。 - 如果旧文件在 180 天后过期，将创建 API 服务器的新证书和密钥文件并备份旧文件。 <!-- -`kubeadm upgrade node experimental-control-plane` does the following on additional control plane nodes: +`kubeadm upgrade node` does the following on additional control plane nodes: - Fetches the kubeadm `ClusterConfiguration` from the cluster. - Optionally backups the kube-apiserver certificate. - Upgrades the static Pod manifests for the control plane components. +- Upgrades the kubelet configuration for this node. --> -`kubeadm upgrade node experimental-control-plane` 在其他控制平面节点上执行以下操作： +`kubeadm upgrade node` 在其他控制平节点上执行以下操作： + - 从集群中获取 kubeadm `ClusterConfiguration`。 - 可选地备份 kube-apiserver 证书。 - 升级控制平面组件的静态 Pod 清单。 +- 为本节点升级 kubelet 配置 + +<!-- +`kubeadm upgrade node` does the following on worker nodes: + +- Fetches the kubeadm `ClusterConfiguration` from the cluster. +- Upgrades the kubelet configuration for this node. +--> +`kubeadm upgrade node` 在工作节点上完成以下工作： + +- 从集群取回 kubeadm `ClusterConfiguration`。 +- 为本节点升级 kubelet 配置 + diff --git a/content/zh/docs/tasks/administer-cluster/namespaces.md b/content/zh/docs/tasks/administer-cluster/namespaces.md index f2e63f5d48..9c5ce28310 100644 --- a/content/zh/docs/tasks/administer-cluster/namespaces.md +++ b/content/zh/docs/tasks/administer-cluster/namespaces.md @@ -127,6 +127,13 @@ See the [design doc](https://git.k8s.io/community/contributors/design-proposals/ ## 创建命名空间 +<!-- +Avoid creating namespace with prefix `kube-`, since it is reserved for Kubernetes system namespaces. +--> +{{< note >}} +避免使用前缀 `kube-` 创建命名空间，因为它是为 Kubernetes 系统命名空间保留的。 +{{< /note >}} + <!-- 1. Create a new YAML file called `my-namespace.yaml` with the contents: --> 1. 新建一个名为 `my-namespace.yaml` 的 YAML 文件，并写入下列内容： diff --git a/content/zh/docs/tasks/administer-cluster/reserve-compute-resources.md b/content/zh/docs/tasks/administer-cluster/reserve-compute-resources.md index 3b26ba5ba9..8e68d12845 100644 --- a/content/zh/docs/tasks/administer-cluster/reserve-compute-resources.md +++ b/content/zh/docs/tasks/administer-cluster/reserve-compute-resources.md @@ -5,6 +5,7 @@ reviewers: - dashpole title: 为系统守护进程预留计算资源 content_type: task +min-kubernetes-server-version: 1.8 --- <!-- --- @@ -14,6 +15,7 @@ reviewers: - dashpole title: Reserve Compute Resources for System Daemons content_type: task +min-kubernetes-server-version: 1.8 --- --> @@ -31,18 +33,23 @@ compute resources for system daemons. Kubernetes recommends cluster administrators to configure `Node Allocatable` based on their workload density on each node. --> -Kubernetes 的节点可以按照 `Capacity` 调度。默认情况下 pod 能够使用节点全部可用容量。这是个问题，因为节点自己通常运行了不少驱动 OS 和 Kubernetes 的系统守护进程。除非为这些系统守护进程留出资源，否则它们将与 pod 争夺资源并导致节点资源短缺问题。 - -`kubelet` 公开了一个名为 `Node Allocatable` 的特性，有助于为系统守护进程预留计算资源。Kubernetes 推荐集群管理员按照每个节点上的工作负载密度配置 `Node Allocatable`。 - +Kubernetes 的节点可以按照 `Capacity` 调度。默认情况下 pod 能够使用节点全部可用容量。 +这是个问题，因为节点自己通常运行了不少驱动 OS 和 Kubernetes 的系统守护进程。 +除非为这些系统守护进程留出资源，否则它们将与 pod 争夺资源并导致节点资源短缺问题。 +`kubelet` 公开了一个名为 `Node Allocatable` 的特性，有助于为系统守护进程预留计算资源。 +Kubernetes 推荐集群管理员按照每个节点上的工作负载密度配置 `Node Allocatable`。 ## {{% heading "prerequisites" %}} {{< include "task-tutorial-prereqs.md" >}} {{< version-check >}} - - +<!-- +Your Kubernetes server must be at or later than version 1.17 to use +the kubelet command line option `--reserved-cpus` to set an +[explicitly reserved CPU list](#explicitly-reserved-cpu-list). +--> +您的 kubernetes 服务器版本必须至少是 1.17 版本，才能使用 kubelet 命令行选项 `--reserved-cpus` 来设置 [显式 CPU 保留列表](#explicitly-reserved-cpu-list) <!-- steps --> @@ -94,7 +101,8 @@ Resources can be reserved for two categories of system daemons in the `kubelet`. --------------------------- ``` -Kubernetes 节点上的 `Allocatable` 被定义为 pod 可用计算资源量。调度器不会超额申请 `Allocatable`。目前支持 `CPU`, `memory` 和 `ephemeral-storage` 这几个参数。 +Kubernetes 节点上的 `Allocatable` 被定义为 pod 可用计算资源量。调度器不会超额申请 `Allocatable`。 +目前支持 `CPU`, `memory` 和 `ephemeral-storage` 这几个参数。 可分配的节点暴露为 API 中 `v1.Node` 对象的一部分，也是 CLI 中 `kubectl describe node` 的一部分。 @@ -110,7 +118,8 @@ under a cgroup hierarchy managed by the `kubelet`. --> ### 启用 QoS 和 Pod 级别的 cgroups -为了恰当的在节点范围实施 node allocatable，您必须通过 `--cgroups-per-qos` 标志启用新的 cgroup 层次结构。这个标志是默认启用的。启用后，`kubelet` 将在其管理的 cgroup 层次结构中创建所有终端用户的 pod。 +为了恰当的在节点范围实施 node allocatable，您必须通过 `--cgroups-per-qos` 标志启用新的 cgroup 层次结构。 +这个标志是默认启用的。启用后，`kubelet` 将在其管理的 cgroup 层次结构中创建所有终端用户的 Pod。 <!-- ### Configuring a cgroup driver @@ -141,7 +150,8 @@ be configured to use the `systemd` cgroup driver. * `cgroupfs` 是默认的驱动，在主机上直接操作 cgroup 文件系统以对 cgroup 沙箱进行管理。 * `systemd` 是可选的驱动，使用 init 系统支持的资源的瞬时切片管理 cgroup 沙箱。 -取决于相关容器运行时的配置，操作员可能需要选择一个特定的 cgroup 驱动来保证系统正常运行。例如如果操作员使用 `docker` 运行时提供的 `systemd` cgroup 驱动时，必须配置 `kubelet` 使用 `systemd` cgroup 驱动。 +取决于相关容器运行时的配置，操作员可能需要选择一个特定的 cgroup 驱动来保证系统正常运行。 +例如如果操作员使用 `docker` 运行时提供的 `systemd` cgroup 驱动时，必须配置 `kubelet` 使用 `systemd` cgroup 驱动。 <!-- ### Kube Reserved @@ -152,13 +162,7 @@ be configured to use the `systemd` cgroup driver. `kube-reserved` is meant to capture resource reservation for kubernetes system daemons like the `kubelet`, `container runtime`, `node problem detector`, etc. It is not meant to reserve resources for system daemons that are run as pods. -`kube-reserved` is typically a function of `pod density` on the nodes. [This -performance dashboard](http://node-perf-dash.k8s.io/#/builds) exposes `cpu` and -`memory` usage profiles of `kubelet` and `docker engine` at multiple levels of -pod density. [This blog -post](https://kubernetes.io/blog/2016/11/visualize-kubelet-performance-with-node-dashboard) -explains how the dashboard can be interpreted to come up with a suitable -`kube-reserved` reservation. +`kube-reserved` is typically a function of `pod density` on the nodes. In addition to `cpu`, `memory`, and `ephemeral-storage`, `pid` may be specified to reserve the specified number of process IDs for @@ -185,14 +189,14 @@ exist. Kubelet will fail if an invalid cgroup is specified. `kube-reserved` 是为了给诸如 `kubelet`、`container runtime`、`node problem detector` 等 kubernetes 系统守护进程争取资源预留。 这并不代表要给以 pod 形式运行的系统守护进程保留资源。`kube-reserved` 通常是节点上的一个 `pod 密度` 功能。 -[这个性能仪表盘](http://node-perf-dash.k8s.io/#/builds) 从 pod 密度的多个层面展示了 `kubelet` 和 `docker engine` 的 `cpu` 和 `内存` 使用情况。 -[这个博文](https://kubernetes.io/blog/2016/11/visualize-kubelet-performance-with-node-dashboard)解释了如何仪表板以提出合适的 `kube-reserved` 预留。 除了 `cpu`，`内存` 和 `ephemeral-storage` 之外，`pid` 可能是指定为 kubernetes 系统守护进程预留指定数量的进程 ID。 要选择性的在系统守护进程上执行 `kube-reserved`，需要把 kubelet 的 `--kube-reserved-cgroup` 标志的值设置为 kube 守护进程的父控制组。 -推荐将 kubernetes 系统守护进程放置于顶级控制组之下（例如 systemd 机器上的 `runtime.slice`）。理想情况下每个系统守护进程都应该在其自己的子控制组中运行。请参考[这篇文档](https://git.k8s.io/community/contributors/design-proposals/node/node-allocatable.md#recommended-cgroups-setup)，获取更过关于推荐控制组层次结构的细节。 +推荐将 kubernetes 系统守护进程放置于顶级控制组之下（例如 systemd 机器上的 `runtime.slice`）。 +理想情况下每个系统守护进程都应该在其自己的子控制组中运行。 +请参考[这篇文档](https://git.k8s.io/community/contributors/design-proposals/node/node-allocatable.md#recommended-cgroups-setup)，获取更过关于推荐控制组层次结构的细节。 请注意，如果 `--kube-reserved-cgroup` 不存在，Kubelet 将**不会**创建它。如果指定了一个无效的 cgroup，Kubelet 将会失败。 @@ -243,7 +247,7 @@ exist. Kubelet will fail if an invalid cgroup is specified. <!-- ### Explicitly Reserved CPU List --> -### 明确保留的 CPU 列表 +### 显式保留的 CPU 列表 {#explicitly-reserved-cpu-list} {{< feature-state for_k8s_version="v1.17" state="stable" >}} - **Kubelet Flag**: `--reserved-cpus=0-3` @@ -272,7 +276,10 @@ defined by this option, other mechanism outside Kubernetes should be used. For example: in Centos, you can do this using the tuned toolset. --> 此选项是专门为 Telco 或 NFV 用例设计的，在这些用例中不受控制的中断或计时器可能会影响其工作负载性能。 -可以使用此选项为系统或 kubernetes 守护程序以及中断或计时器定义显式的 cpuset，因此系统上的其余 CPU 可以专门用于工作负载，而不受不受控制的中断或计时器的影响较小。要将系统守护程序、kubernetes 守护程序和中断或计时器移动到此选项定义的显式 cpuset 上，应使用 Kubernetes 之外的其他机制。 +可以使用此选项为系统或 kubernetes 守护程序以及中断或计时器定义显式的 cpuset，因此系统上的 +其余 CPU 可以专门用于工作负载，而不受不受控制的中断或计时器的影响较小。 +要将系统守护程序、kubernetes 守护程序和中断或计时器移动到此选项定义的显式 cpuset 上， +应使用 Kubernetes 之外的其他机制。 例如：在 Centos 系统中，可以使用 tuned 工具集来执行此操作。 <!-- @@ -283,7 +290,7 @@ For example: in Centos, you can do this using the tuned toolset. Memory pressure at the node level leads to System OOMs which affects the entire node and all pods running on it. Nodes can go offline temporarily until memory has been reclaimed. To avoid (or reduce the probability of) system OOMs kubelet -provides [`Out of Resource`](./out-of-resource.md) management. Evictions are +provides [`Out of Resource`](/docs/tasks/administer-cluster/out-of-resource/) management. Evictions are supported for `memory` and `ephemeral-storage` only. By reserving some memory via `--eviction-hard` flag, the `kubelet` attempts to `evict` pods whenever memory availability on the node drops below the reserved value. Hypothetically, if @@ -296,7 +303,9 @@ available for pods. - **Kubelet Flag**: `--eviction-hard=[memory.available<500Mi]` 节点级别的内存压力将导致系统内存不足，这将影响到整个节点及其上运行的所有 pod。节点可以暂时离线直到内存已经回收为止。 -为了防止（或减少可能性）系统内存不足，kubelet 提供了[资源不足](./out-of-resource.md)管理。驱逐操作只支持 `memory` 和 `ephemeral-storage`。 +为了防止（或减少可能性）系统内存不足，kubelet 提供了 +[资源不足](/zh/docs/tasks/administer-cluster/out-of-resource/)管理。 +驱逐操作只支持 `memory` 和 `ephemeral-storage`。 通过 `--eviction-hard` 标志预留一些内存后，当节点上的可用内存降至保留值以下时，`kubelet` 将尝试`驱逐` pod。 假设，如果节点上不存在系统守护进程，pod 将不能使用超过 `capacity-eviction-hard` 的资源。因此，为驱逐而预留的资源对 pod 是不可用的。 @@ -310,7 +319,7 @@ The scheduler treats `Allocatable` as the available `capacity` for pods. `kubelet` enforce `Allocatable` across pods by default. Enforcement is performed by evicting pods whenever the overall usage across all pods exceeds `Allocatable`. More details on eviction policy can be found -[here](./out-of-resource.md#eviction-policy). This enforcement is controlled by +[here](/docs/tasks/administer-cluster/out-of-resource/#eviction-policy). This enforcement is controlled by specifying `pods` value to the kubelet flag `--enforce-node-allocatable`. @@ -326,9 +335,14 @@ respectively. 调度器将 `Allocatable` 按 pod 的可用 `capacity` 对待。 -`kubelet` 默认在 pod 中执行 `Allocatable`。无论何时，如果所有 pod 的总用量超过了 `Allocatable`，驱逐 pod 的措施将被执行。有关驱逐策略的更多细节可以在[这里](./out-of-resource.md#eviction-policy)找到。请通过设置 kubelet `--enforce-node-allocatable` 标志值为 `pods` 控制这个措施。 +`kubelet` 默认在 Pod 中执行 `Allocatable`。无论何时，如果所有 pod 的总用量超过了 `Allocatable`， +驱逐 pod 的措施将被执行。有关驱逐策略的更多细节可以在 +[这里](/zh/docs/tasks/administer-cluster/out-of-resource/#eviction-policy).找到。 +请通过设置 kubelet `--enforce-node-allocatable` 标志值为 `pods` 控制这个措施。 -可选的，通过在相同标志中同时指定 `kube-reserved` 和 `system-reserved` 值能够使 `kubelet` 执行 `kube-reserved` 和 `system-reserved`。请注意，要想执行 `kube-reserved` 或者 `system-reserved` 时，需要分别指定 `--kube-reserved-cgroup` 或者 `--system-reserved-cgroup`。 +可选的，通过在相同标志中同时指定 `kube-reserved` 和 `system-reserved` 值能够使 `kubelet` +执行 `kube-reserved` 和 `system-reserved`。请注意，要想执行 `kube-reserved` 或者 `system-reserved` 时， +需要分别指定 `--kube-reserved-cgroup` 或者 `--system-reserved-cgroup`。 <!-- ## General Guidelines @@ -359,17 +373,23 @@ So expect a drop in `Allocatable` capacity in future releases. --> ## 一般原则 -系统守护进程期望被按照类似 `Guaranteed` pod 一样对待。系统守护进程可以在其范围控制组中爆发式增长，您需要将这个行为作为 kubernetes 部署的一部分进行管理。 -例如，`kubelet` 应该有它自己的控制组并和容器运行时共享 `Kube-reserved` 资源。然而，如果执行了 `kube-reserved`，则 kubelet 不能突然爆发并耗尽节点的所有可用资源。 +系统守护进程期望被按照类似 `Guaranteed` pod 一样对待。系统守护进程可以在其范围控制组中爆发式增长， +您需要将这个行为作为 kubernetes 部署的一部分进行管理。 +例如，`kubelet` 应该有它自己的控制组并和容器运行时共享 `Kube-reserved` 资源。 +然而，如果执行了 `kube-reserved`，则 kubelet 不能突然爆发并耗尽节点的所有可用资源。 -在执行 `system-reserved` 预留操作时请加倍小心，因为它可能导致节点上的关键系统服务 CPU 资源短缺或因为内存不足而被终止。 -建议只有当用户详尽地描述了他们的节点以得出精确的估计时才强制执行 `system-reserved`，并且如果该组中的任何进程都是 oom_killed，则对他们恢复的能力充满信心。 +在执行 `system-reserved` 预留操作时请加倍小心，因为它可能导致节点上的关键系统服务 CPU 资源短缺 +或因为内存不足而被终止。 +建议只有当用户详尽地描述了他们的节点以得出精确的估计时才强制执行 `system-reserved`， +并且如果该组中的任何进程都是 oom_killed，则对他们恢复的能力充满信心。 * 在 `pods` 上执行 `Allocatable` 作为开始。 * 一旦足够用于追踪系统守护进程的监控和告警的机制到位，请尝试基于用量探索方式执行 `kube-reserved`。 * 随着时间推进，如果绝对必要，可以执行 `system-reserved`。 -随着时间的增长以及越来越多特性的加入，kube 系统守护进程对资源的需求可能也会增加。以后 kubernetes 项目将尝试减少对节点系统守护进程的利用，但目前那并不是优先事项。所以，请期待在将来的发布中将 `Allocatable` 容量降低。 +随着时间的增长以及越来越多特性的加入，kube 系统守护进程对资源的需求可能也会增加。 +以后 kubernetes 项目将尝试减少对节点系统守护进程的利用，但目前那并不是优先事项。 +所以，请期待在将来的发布中将 `Allocatable` 容量降低。 @@ -408,58 +428,8 @@ usage is higher than `31.5Gi` or `storage` is greater than `90Gi` 在这个场景下，`Allocatable` 将会是 `14.5 CPUs`、`28.5Gi` 内存以及 `88Gi` 本地存储。 调度器保证这个节点上的所有 pod `请求`的内存总量不超过 `28.5Gi`，存储不超过 `88Gi`。 -当 pod 的内存使用总量超过 `28.5Gi` 或者磁盘使用总量超过 `88Gi` 时，Kubelet 将会驱逐它们。如果节点上的所有进程都尽可能多的使用 CPU，则 pod 加起来不能使用超过 `14.5 CPUs` 的资源。 - -当没有执行 `kube-reserved` 和/或 `system-reserved` 且系统守护进程使用量超过其预留时，如果节点内存用量高于 `31.5Gi` 或`存储`大于 `90Gi`，kubelet 将会驱逐 pod。 - -<!-- -## Feature Availability - -As of Kubernetes version 1.2, it has been possible to **optionally** specify -`kube-reserved` and `system-reserved` reservations. The scheduler switched to -using `Allocatable` instead of `Capacity` when available in the same release. - -As of Kubernetes version 1.6, `eviction-thresholds` are being considered by -computing `Allocatable`. To revert to the old behavior set -`--experimental-allocatable-ignore-eviction` kubelet flag to `true`. - -As of Kubernetes version 1.6, `kubelet` enforces `Allocatable` on pods using -control groups. To revert to the old behavior unset `--enforce-node-allocatable` -kubelet flag. Note that unless `--kube-reserved`, or `--system-reserved` or -`--eviction-hard` flags have non-default values, `Allocatable` enforcement does -not affect existing deployments. - -As of Kubernetes version 1.6, `kubelet` launches pods in their own cgroup -sandbox in a dedicated part of the cgroup hierarchy it manages. Operators are -required to drain their nodes prior to upgrade of the `kubelet` from prior -versions in order to ensure pods and their associated containers are launched in -the proper part of the cgroup hierarchy. - -As of Kubernetes version 1.7, `kubelet` supports specifying `storage` as a resource -for `kube-reserved` and `system-reserved`. - -As of Kubernetes version 1.8, the `storage` key name was changed to `ephemeral-storage` -for the alpha release. ---> -## 可用特性 - -截至 Kubernetes 1.2 版本，已经可以**可选**的指定 `kube-reserved` 和 `system-reserved` 预留。当在相同的发布中都可用时，调度器将转为使用 `Allocatable` 替代 `Capacity`。 - -截至 Kubernetes 1.6 版本，`eviction-thresholds` 是通过计算 `Allocatable` 进行考虑。要使用旧版本的行为，请设置 `--experimental-allocatable-ignore-eviction` kubelet 标志为 `true`。 - -截至 Kubernetes 1.6 版本，`kubelet` 使用控制组在 pod 上执行 `Allocatable`。要使用旧版本行为，请取消设置 `--enforce-node-allocatable` kubelet 标志。请注意，除非 `--kube-reserved` 或者 `--system-reserved` 或者 `--eviction-hard` 标志没有默认参数，否则 `Allocatable` 的实施不会影响已经存在的 deployment。 - -截至 Kubernetes 1.6 版本，`kubelet` 在 pod 自己的 cgroup 沙箱中启动它们，这个 cgroup 沙箱在 `kubelet` 管理的 cgroup 层次结构中的一个独占部分中。在从前一个版本升级 kubelet 之前，要求操作员 drain 节点，以保证 pod 及其关联的容器在 cgroup 层次结构中合适的部分中启动。 - -截至 Kubernetes 1.7 版本，`kubelet` 支持指定 `storage` 为 `kube-reserved` 和 `system-reserved` 的资源。 - -截至 Kubernetes 1.8 版本，对于 alpha 版本，`storage` 键值名称已更改为 `ephemeral-storage`。 - -<!-- -As of Kubernetes version 1.17, you can optionally specify -explicit cpuset by `reserved-cpus` as CPUs reserved for OS system -daemons/interrupts/timers and Kubernetes daemons. ---> -从 Kubernetes 1.17 版本开始，可以选择将 `reserved-cpus` 显式 cpuset 指定为操作系统守护程序、中断、计时器和 Kubernetes 守护程序保留的 CPU。 - +当 pod 的内存使用总量超过 `28.5Gi` 或者磁盘使用总量超过 `88Gi` 时，Kubelet 将会驱逐它们。 +如果节点上的所有进程都尽可能多的使用 CPU，则 pod 加起来不能使用超过 `14.5 CPUs` 的资源。 +当没有执行 `kube-reserved` 和/或 `system-reserved` 且系统守护进程使用量超过其预留时， +如果节点内存用量高于 `31.5Gi` 或`存储`大于 `90Gi`，kubelet 将会驱逐 pod。 diff --git a/content/zh/docs/tasks/configure-pod-container/assign-memory-resource.md b/content/zh/docs/tasks/configure-pod-container/assign-memory-resource.md index 74556aa9a1..c869ab0e9f 100644 --- a/content/zh/docs/tasks/configure-pod-container/assign-memory-resource.md +++ b/content/zh/docs/tasks/configure-pod-container/assign-memory-resource.md @@ -515,25 +515,25 @@ kubectl delete namespace mem-example ### 应用开发者扩展阅读 -* [为容器和 Pod 分配 CPU 资源](/docs/tasks/configure-pod-container/assign-cpu-resource/) +* [为容器和 Pod 分配 CPU 资源](/zh/docs/tasks/configure-pod-container/assign-cpu-resource/) -* [配置 Pod 的服务质量](/docs/tasks/configure-pod-container/quality-service-pod/) +* [配置 Pod 的服务质量](/zh/docs/tasks/configure-pod-container/quality-service-pod/) ### 集群管理员扩展阅读 -* [为命名空间配置默认的内存请求和限制](/docs/tasks/administer-cluster/memory-default-namespace/) +* [为命名空间配置默认的内存请求和限制](/zh/docs/tasks/administer-cluster/manage-resources/memory-default-namespace/) -* [为命名空间配置默认的 CPU 请求和限制](/docs/tasks/administer-cluster/cpu-default-namespace/) +* [为命名空间配置默认的 CPU 请求和限制](/zh/docs/tasks/administer-cluster/manage-resources/cpu-default-namespace/) -* [配置命名空间的最小和最大内存约束](/docs/tasks/administer-cluster/memory-constraint-namespace/) +* [配置命名空间的最小和最大内存约束](/zh/docs/tasks/administer-cluster/manage-resources/memory-constraint-namespace/) -* [配置命名空间的最小和最大 CPU 约束](/docs/tasks/administer-cluster/cpu-constraint-namespace/) +* [配置命名空间的最小和最大 CPU 约束](/zh/docs/tasks/administer-cluster/manage-resources/cpu-constraint-namespace/) -* [为命名空间配置内存和 CPU 配额](/docs/tasks/administer-cluster/quota-memory-cpu-namespace/) +* [为命名空间配置内存和 CPU 配额](/zh/docs/tasks/administer-cluster/manage-resources/quota-memory-cpu-namespace/) -* [配置命名空间下 Pod 总数](/docs/tasks/administer-cluster/quota-pod-namespace/) +* [配置命名空间下 Pod 总数](/zh/docs/tasks/administer-cluster/manage-resources/quota-pod-namespace/) -* [配置 API 对象配额](/docs/tasks/administer-cluster/quota-api-object/) +* [配置 API 对象配额](/zh/docs/tasks/administer-cluster/quota-api-object/) diff --git a/content/zh/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes.md b/content/zh/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes.md index bc4bdbdda4..737e668f55 100644 --- a/content/zh/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes.md +++ b/content/zh/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes.md @@ -457,7 +457,7 @@ to 1 second. Minimum value is 1. * `successThreshold`: Minimum consecutive successes for the probe to be considered successful after having failed. Defaults to 1. Must be 1 for liveness. Minimum value is 1. -* `failureThreshold`: When a Pod starts and the probe fails, Kubernetes will +* `failureThreshold`: When a probe fails, Kubernetes will try `failureThreshold` times before giving up. Giving up in case of liveness probe means restarting the container. In case of readiness probe the Pod will be marked Unready. Defaults to 3. Minimum value is 1. --> @@ -465,7 +465,7 @@ Defaults to 3. Minimum value is 1. * `periodSeconds`：执行探测的时间间隔（单位是秒）。默认是 10 秒。最小值是 1。 * `timeoutSeconds`：探测的超时后等待多少秒。默认值是 1 秒。最小值是 1。 * `successThreshold`：探测器在失败后，被视为成功的最小连续成功数。默认值是 1。存活探测的这个值必须是 1。最小值是 1。 -* `failureThreshold`：当 Pod 启动了并且探测到失败，Kubernetes 的重试次数。存活探测情况下的放弃就意味着重新启动容器。就绪探测情况下的放弃 Pod 会被打上未就绪的标签。默认值是 3。最小值是 1。 +* `failureThreshold`：当探测失败时，Kubernetes 的重试次数。存活探测情况下的放弃就意味着重新启动容器。就绪探测情况下的放弃 Pod 会被打上未就绪的标签。默认值是 3。最小值是 1。 <!-- [HTTP probes](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#httpgetaction-v1-core) diff --git a/content/zh/docs/tasks/configure-pod-container/configure-pod-configmap.md b/content/zh/docs/tasks/configure-pod-container/configure-pod-configmap.md index c150314bd6..5ccf0ed36c 100644 --- a/content/zh/docs/tasks/configure-pod-container/configure-pod-configmap.md +++ b/content/zh/docs/tasks/configure-pod-container/configure-pod-configmap.md @@ -6,14 +6,14 @@ card: name: tasks weight: 50 --- -<!-- --- +<!-- title: Configure a Pod to Use a ConfigMap content_type: task weight: 150 card: name: tasks weight: 50 ---- --> +--> <!-- overview --> <!-- ConfigMaps allow you to decouple configuration artifacts from image content to keep containerized applications portable. This page provides a series of usage examples demonstrating how to create ConfigMaps and configure Pods using data stored in ConfigMaps. --> @@ -83,7 +83,7 @@ wget https://kubernetes.io/examples/configmap/game.properties -O configure-pod-c wget https://kubernetes.io/examples/configmap/ui.properties -O configure-pod-container/configmap/ui.properties # 创建 configmap -kubectl create c game-config --from-file=configure-pod-container/configmap/ +kubectl create configmap game-config --from-file=configure-pod-container/configmap/ ``` <!-- combines the contents of the `configure-pod-container/configmap/` directory --> @@ -331,7 +331,7 @@ data: ``` <!-- #### Define the key to use when creating a ConfigMap from a file --> -#### 定义从文件创建 ConfigMap 时要使用的密钥 +#### 定义从文件创建 ConfigMap 时要使用的键 <!-- You can define a key other than the file name to use in the `data` section of your ConfigMap when using the `--from-file` argument: --> 您可以在使用 `--from-file` 参数时,在 ConfigMap 的 `data` 部分中定义除文件名以外的其他键: @@ -341,7 +341,7 @@ kubectl create configmap game-config-3 --from-file=<my-key-name>=<path-to-file> ``` <!-- where `<my-key-name>` is the key you want to use in the ConfigMap and `<path-to-file>` is the location of the data source file you want the key to represent. --> -`<my-key-name>` 是您要在 ConfigMap 中使用的密钥， `<path-to-file>` 是您想要键表示数据源文件的位置。 +`<my-key-name>` 是您要在 ConfigMap 中使用的键名， `<path-to-file>` 是您想要键表示数据源文件的位置。 <!-- For example: --> 例如: @@ -487,7 +487,7 @@ new ConfigMap is generated each time the content is modified. --> 请注意，生成的 ConfigMap 名称具有通过对内容进行散列而附加的后缀，这样可以确保每次修改内容时都会生成新的 ConfigMap。 <!-- #### Define the key to use when generating a ConfigMap from a file --> -#### 定义从文件生成 ConfigMap 时要使用的密钥 +#### 定义从文件生成 ConfigMap 时要使用的键 <!-- You can define a key other than the file name to use in the ConfigMap generator. For example, to generate a ConfigMap from files `configure-pod-container/configmap/kubectl/game.properties` with the key `game-special-key` --> @@ -664,7 +664,7 @@ very charm ## 将 ConfigMap 数据添加到一个容器中 <!-- As explained in [Create ConfigMaps from files](#create-configmaps-from-files), when you create a ConfigMap using ``--from-file``, the filename becomes a key stored in the `data` section of the ConfigMap. The file contents become the key's value. --> -如[根据文件创建ConfigMap](＃create-configmaps-from-files)中所述，当您使用 ``--from-file`` 创建 ConfigMap 时，文件名成为存储在 ConfigMap 的 `data` 部分中的密钥，文件内容成为密钥的值。 +如[根据文件创建ConfigMap](＃create-configmaps-from-files)中所述，当您使用 ``--from-file`` 创建 ConfigMap 时，文件名成为存储在 ConfigMap 的 `data` 部分中的键，文件内容成为键对应的值。 <!-- The examples in this section refer to a ConfigMap named special-config, shown below. --> 本节中的示例引用了一个名为 special-config 的 ConfigMap，如下所示： @@ -679,7 +679,7 @@ kubectl create -f https://kubernetes.io/examples/configmap/configmap-multikeys.y ``` <!-- ### Populate a Volume with data stored in a ConfigMap --> -### 使用存储在 ConfigMap 中的数据填充容器 +### 使用存储在 ConfigMap 中的数据填充数据卷 <!-- Add the ConfigMap name under the `volumes` section of the Pod specification. This adds the ConfigMap data to the directory specified as `volumeMounts.mountPath` (in this case, `/etc/config`). @@ -711,12 +711,12 @@ SPECIAL_TYPE {{< /caution >}} <!-- ### Add ConfigMap data to a specific path in the Volume --> -### 将 ConfigMap 数据添加到容器中的特定路径 +### 将 ConfigMap 数据添加到数据卷中的特定路径 <!-- Use the `path` field to specify the desired file path for specific ConfigMap items. In this case, the `SPECIAL_LEVEL` item will be mounted in the `config-volume` volume at `/etc/config/keys`. --> 使用 `path` 字段为特定的 ConfigMap 项目指定所需的文件路径。 -在这种情况下, `SPECIAL_LEVEL` 将安装在 `/etc/config/keys` 目录下的 `config-volume` 容器中。 +在这种情况下, `SPECIAL_LEVEL` 将挂载在 `/etc/config/keys` 目录下的 `config-volume` 数据卷中。 {{< codenew file="pods/pod-configmap-volume-specific-key.yaml" >}} @@ -736,25 +736,25 @@ very {{< caution >}} <!-- Like before, all previous files in the `/etc/config/` directory will be deleted. --> -和以前一样，`/etc/config/` 目录中的所有先前文件都将被删除。 +如之前所说，`/etc/config/` 目录中所有先前的文件都将被删除。 {{< /caution >}} <!-- ### Project keys to specific paths and file permissions --> -### 项目密钥以指定路径和文件权限 +### 映射键以指定路径和文件权限 <!-- You can project keys to specific paths and specific permissions on a per-file basis. The [Secrets](/docs/concepts/configuration/secret/#using-secrets-as-files-from-a-pod) user guide explains the syntax. --> -您可以将密钥映射到每个文件的特定路径和特定权限。[Secrets](/docs/concepts/configuration/secret/#using-secrets-as-files-from-a-pod) 用户指南说明了语法。 +您可以通过映射键来指定每个文件的特定路径和特定权限。[Secrets](/docs/concepts/configuration/secret/#using-secrets-as-files-from-a-pod) 用户指南说明了语法。 <!-- ### Mounted ConfigMaps are updated automatically --> ### 挂载的 ConfigMap 将自动更新 <!-- When a ConfigMap already being consumed in a volume is updated, projected keys are eventually updated as well. Kubelet is checking whether the mounted ConfigMap is fresh on every periodic sync. However, it is using its local ttl-based cache for getting the current value of the ConfigMap. As a result, the total delay from the moment when the ConfigMap is updated to the moment when new keys are projected to the pod can be as long as kubelet sync period + ttl of ConfigMaps cache in kubelet. --> -更新已经在容器中使用的 ConfigMap 时，最终也会更新映射键。Kubelet 实时检查是否在每个定期同步中都更新已安装的 ConfigMap。它使用其基于本地 ttl 的缓存来获取 ConfigMap 的当前值。结果，从更新 ConfigMap 到将新密钥映射到 Pod 的总延迟可以与 ConfigMap 在 kubelet 中缓存的 kubelet 同步周期 ttl 一样长。 +更新已经在数据卷中使用的 ConfigMap 时，最终也会更新映射键。Kubelet 在每次定期同步时都会检查已挂载的 ConfigMap 是否过期。它使用其基于本地 ttl 的缓存来获取 ConfigMap 的当前值。因此，更新 ConfigMap 到将新键映射到 Pod 的总延迟可能与 kubelet 同步周期 + ConfigMap 在 kubelet 中缓存的 ttl 一样长。 {{< note >}} <!-- A container using a ConfigMap as a [subPath](/docs/concepts/storage/volumes/#using-subpath) volume will not receive ConfigMap updates. --> -使用 ConfigMap 作为子路径[subPath](/docs/concepts/storage/volumes/#using-subpath)的容器将不会收到 ConfigMap 更新。 +使用 ConfigMap 作为[子路径](/docs/concepts/storage/volumes/#using-subpath)的数据卷将不会收到 ConfigMap 更新。 {{< /note >}} @@ -769,11 +769,11 @@ ConfigMap API 资源将配置数据存储为键值对。数据可以在 Pod 中 {{< note >}} <!-- ConfigMaps should reference properties files, not replace them. Think of the ConfigMap as representing something similar to the Linux `/etc` directory and its contents. For example, if you create a [Kubernetes Volume](/docs/concepts/storage/volumes/) from a ConfigMap, each data item in the ConfigMap is represented by an individual file in the volume. --> -ConfigMap 应该引用属性文件，而不是替换它们。可以将 ConfigMap 表示为类似于 Linux `/etc` 目录及其内容的东西。例如，如果您从 ConfigMap 创建[Kubernetes Volume](/docs/concepts/storage/volumes/)，则 ConfigMap 中的每个数据项都由该容器中的单个文件表示。 +ConfigMap 应该引用属性文件，而不是替换它们。可以将 ConfigMap 理解为类似于 Linux `/etc` 目录及其内容的东西。例如，如果您从 ConfigMap 创建[Kubernetes Volume](/docs/concepts/storage/volumes/)，则 ConfigMap 中的每个数据项都由该数据卷中的单个文件表示。 {{< /note >}} <!-- The ConfigMap's `data` field contains the configuration data. As shown in the example below, this can be simple -- like individual properties defined using `--from-literal` -- or complex -- like configuration files or JSON blobs defined using `--from-file`. --> -ConfigMap 的 `data` 字段包含配置数据。如下例所示，它可以很简单 -- 就像使用 `--from-literal` -- 定义的单个属性一样，也可以很复杂 -- 例如使用 `--from-file` 定义的配置文件或 JSON blob。 +ConfigMap 的 `data` 字段包含配置数据。如下例所示，它可以简单（如用 `--from-literal` 的单个属性定义）或复杂（如用 `--from-file` 的配置文件或 JSON blob定义）。 ```yaml apiVersion: v1 @@ -797,7 +797,7 @@ data: ### 限制规定 <!-- - You must create a ConfigMap before referencing it in a Pod specification (unless you mark the ConfigMap as "optional"). If you reference a ConfigMap that doesn't exist, the Pod won't start. Likewise, references to keys that don't exist in the ConfigMap will prevent the pod from starting. --> -- 在 Pod 规范中引用它之前，必须先创建一个 ConfigMap(除非将 ConfigMap 标记为"可选")。如果引用的 ConfigMap 不存在，则 Pod 将不会启动。同样，对 ConfigMap 中不存在的键的引用将阻止容器启动。 +- 在 Pod 规范中引用之前，必须先创建一个 ConfigMap(除非将 ConfigMap 标记为"可选")。如果引用的 ConfigMap 不存在，则 Pod 将不会启动。同样，引用 ConfigMap 中不存在的键也会阻止 Pod 启动。 <!-- - If you use `envFrom` to define environment variables from ConfigMaps, keys that are considered invalid will be skipped. The pod will be allowed to start, but the invalid names will be recorded in the event log (`InvalidVariableNames`). The log message lists each skipped key. For example: --> - 如果您使用 `envFrom` 从 ConfigMap 中定义环境变量，那么将忽略被认为无效的键。可以启动 Pod，但无效名称将记录在事件日志中(InvalidVariableNames)。日志消息列出了每个跳过的键。例如: @@ -814,15 +814,14 @@ data: ``` <!-- - ConfigMaps reside in a specific [namespace](/docs/concepts/overview/working-with-objects/namespaces/). A ConfigMap can only be referenced by pods residing in the same namespace. --> -- ConfigMaps reside in a specific [命令空间](/docs/concepts/overview/working-with-objects/namespaces/). A ConfigMap can only be referenced by pods residing in the same namespace. -ConfigMap 驻留在特定的[命令空间](/docs/concepts/overview/working-with-objects/namespaces/)中。ConfigMap 只能由位于相同命令空间中的 Pod 引用。 +- ConfigMap 位于特定的[命名空间](/docs/concepts/overview/working-with-objects/namespaces/)中. 每个 ConfigMap 只能被同一命名空间中的 Pod 引用. <!-- - Kubelet doesn't support the use of ConfigMaps for pods not found on the API server. This includes pods created via the Kubelet's `--manifest-url` flag, `--config` flag, or the Kubelet REST API. --> -- Kubelet 不支持将 ConfigMap 用于未在 API 服务器上找到的 Pod。这包括通过 Kubelet 的 `--manifest-url` 参数，`--config` 参数或者 Kubelet REST API 创建的容器。 +- Kubelet 不支持将 ConfigMap 用于未在 API 服务器上找到的 Pod。包括通过 Kubelet 的 `--manifest-url` 参数，`--config` 参数或者 Kubelet REST API 创建的容器。 {{< note >}} <!-- These are not commonly-used ways to create pods. --> - 这些不是创建 pods 的常用方法。 + 以上并不是创建 Pod 的常用方法。 {{< /note >}} diff --git a/content/zh/docs/tasks/debug-application-cluster/debug-application-introspection.md b/content/zh/docs/tasks/debug-application-cluster/debug-application-introspection.md index 23383abb8b..6be1e8946f 100644 --- a/content/zh/docs/tasks/debug-application-cluster/debug-application-introspection.md +++ b/content/zh/docs/tasks/debug-application-cluster/debug-application-introspection.md @@ -532,14 +532,14 @@ Learn about additional debugging tools, including: * [Logging](/docs/concepts/cluster-administration/logging/) * [Monitoring](/docs/tasks/debug-application-cluster/resource-usage-monitoring/) * [Getting into containers via `exec`](/docs/tasks/debug-application-cluster/get-shell-running-container/) -* [Connecting to containers via proxies](/docs/tasks/access-kubernetes-api/http-proxy-access-api/) +* [Connecting to containers via proxies](/docs/tasks/extend-kubernetes/http-proxy-access-api/) * [Connecting to containers via port forwarding](/docs/tasks/access-application-cluster/port-forward-access-application-cluster/) * [Inspect Kubernetes node with crictl](/docs/tasks/debug-application-cluster/crictl/) --> * [日志](/docs/concepts/cluster-administration/logging/) * [监控](/docs/tasks/debug-application-cluster/resource-usage-monitoring/) * [使用 `exec` 进入容器](/docs/tasks/debug-application-cluster/get-shell-running-container/) -* [使用代理连接容器](/docs/tasks/access-kubernetes-api/http-proxy-access-api/) +* [使用代理连接容器](/docs/tasks/extend-kubernetes/http-proxy-access-api/) * [使用端口转发连接容器](/docs/tasks/access-application-cluster/port-forward-access-application-cluster/) * [使用 crictl 检查节点](/docs/tasks/debug-application-cluster/crictl/) diff --git a/content/zh/docs/tasks/debug-application-cluster/debug-application.md b/content/zh/docs/tasks/debug-application-cluster/debug-application.md index d13718617f..8e7b751951 100644 --- a/content/zh/docs/tasks/debug-application-cluster/debug-application.md +++ b/content/zh/docs/tasks/debug-application-cluster/debug-application.md @@ -1,102 +1,160 @@ --- title: 应用故障排查 +content_type: concept --- +<!-- +title: Troubleshoot Applications +content_type: concept +--> -本指南帮助用户来调试kubernetes上那些没有正常运行的应用。 -本指南*不能*调试集群。如果想调试集群的话，请参阅[这里](/docs/admin/cluster-troubleshooting)。 +<!-- overview --> -{{< toc >}} +<!-- +This guide is to help users debug applications that are deployed into Kubernetes and not behaving correctly. +This is *not* a guide for people who want to debug their cluster. For that you should check out +[this guide](/docs/admin/cluster-troubleshooting). +--> -## 诊断问题 +本指南帮助用户调试那些部署到 Kubernetes 上后没有正常运行的应用。 +本指南 *并非* 指导用户如何调试集群。 +如果想调试集群的话，请参阅[这里](/zh/docs/tasks/debug-application-cluster/debug-cluster/)。 -故障排查的第一步是先给问题分下类。这个问题是什么？Pods，Replication Controller或者Service？ + +<!-- body --> + +<!-- +## Diagnosing the problem + +The first step in troubleshooting is triage. What is the problem? Is it your Pods, your Replication Controller or +your Service? * [Debugging Pods](#debugging-pods) * [Debugging Replication Controllers](#debugging-replication-controllers) * [Debugging Services](#debugging-services) +--> +## 诊断问题 {#diagnosing-the-problem} +故障排查的第一步是先给问题分类。问题是什么？是关于 Pods、Replication Controller 还是 Service？ + +* [调试 Pods](#debugging-pods) +* [调试副本控制器](#debugging-replication-controllers) +* [调试服务](#debugging-services) + +<!-- ### Debugging Pods -调试pod的第一步是看一下这个pod的信息，用如下命令查看一下pod的当前状态和最近的事件： +The first step in debugging a Pod is taking a look at it. Check the current state of the Pod and recent events with the following command: +--> +### 调试 Pods {#debugging-pods} + +调试 Pod 的第一步是查看 Pod 信息。用如下命令查看 Pod 的当前状态和最近的事件： ```shell -$ kubectl describe pods ${POD_NAME} +kubectl describe pods ${POD_NAME} ``` -查看一下pod中的容器所处的状态。这些容器的状态都是`Running`吗？最近有没有重启过？ +<!-- +Look at the state of the containers in the pod. Are they all `Running`? Have there been recent restarts? -后面的调试都是要依靠pods的状态的。 +Continue debugging depending on the state of the pods. +--> +查看一下 Pod 中的容器所处的状态。这些容器的状态都是 `Running` 吗？最近有没有重启过？ -#### pod停留在pending状态 +后面的调试都是要依靠 Pod 的状态的。 -如果一个pod卡在`Pending`状态，则表示这个pod没有被调度到一个节点上。通常这是因为资源不足引起的。 -敲一下`kubectl describe ...`这个命令，输出的信息里面应该有显示为什么没被调度的原因。 +<!-- +#### My pod stays pending + +If a Pod is stuck in `Pending` it means that it can not be scheduled onto a node. Generally this is because +there are insufficient resources of one type or another that prevent scheduling. Look at the output of the +`kubectl describe ...` command above. There should be messages from the scheduler about why it can not schedule +your pod. Reasons include: +--> +#### Pod 停滞在 Pending 状态 + +如果一个 Pod 停滞在 `Pending` 状态，表示 Pod 没有被调度到节点上。通常这是因为 +某种类型的资源不足导致无法调度。 +查看上面的 `kubectl describe ...` 命令的输出，其中应该显示了为什么没被调度的原因。 常见原因如下： +<!-- +* **You don't have enough resources**: You may have exhausted the supply of CPU or Memory in your cluster, in this case +you need to delete Pods, adjust resource requests, or add new nodes to your cluster. See [Compute Resources document](/docs/user-guide/compute-resources/#my-pods-are-pending-with-event-message-failedscheduling) for more information. + +* **You are using `hostPort`**: When you bind a Pod to a `hostPort` there are a limited number of places that pod can be +scheduled. In most cases, `hostPort` is unnecessary, try using a Service object to expose your Pod. If you do require +`hostPort` then you can only schedule as many Pods as there are nodes in your Kubernetes cluster. +--> * **资源不足**: -你可能耗尽了集群上所有的CPU和内存，此时，你需要删除pods，调整资源请求，或者增加节点。 -更多信息请参阅[Compute Resources document](/docs/user-guide/compute-resources/#my-pods-are-pending-with-event-message-failedscheduling) + 你可能耗尽了集群上所有的 CPU 或内存。此时，你需要删除 Pod、调整资源请求或者为集群添加节点。 + 更多信息请参阅[计算资源文档](/zh/docs/concepts/configuration/manage-resources-containers/) -* **使用了`hostPort`**: -如果绑定一个pod到`hostPort`，那么能创建的pod个数就有限了。 -多数情况下，`hostPort`是非必要的，而应该采用服务来暴露pod。 -如果确实需要使用`hostPort`，那么能创建的pod的数量就是节点的个数。 +* **使用了 `hostPort`**: + 如果绑定 Pod 到 `hostPort`，那么能够运行该 Pod 的节点就有限了。 + 多数情况下，`hostPort` 是非必要的，而应该采用 Service 对象来暴露 Pod。 + 如果确实需要使用 `hostPort`，那么集群中节点的个数就是所能创建的 Pod + 的数量上限。 +<!-- +#### My pod stays waiting -#### pod停留在waiting状态 +If a Pod is stuck in the `Waiting` state, then it has been scheduled to a worker node, but it can't run on that machine. +Again, the information from `kubectl describe ...` should be informative. The most common cause of `Waiting` pods is a failure to pull the image. There are three things to check: -如果一个pod卡在`Waiting`状态，则表示这个pod已经调试到节点上，但是没有运行起来。 -再次敲一下`kubectl describe ...`这个命令来查看相关信息。 -最常见的原因是拉取镜像失败。可以通过以下三种方式来检查： +* Make sure that you have the name of the image correct. +* Have you pushed the image to the repository? +* Run a manual `docker pull <image>` on your machine to see if the image can be pulled. +--> +#### Pod 停滞在 Waiting 状态 -* 使用的镜像名字正确吗？ -* 镜像仓库里有没有这个镜像？ -* 用`docker pull <image>`命令手动拉下镜像试试。 +如果 Pod 停滞在 `Waiting` 状态，则表示 Pod 已经被调度到某工作节点，但是无法在该节点上运行。 +同样，`kubectl describe ...` 命令的输出可能很有用。 +`Waiting` 状态的最常见原因是拉取镜像失败。要检查的有三个方面： -#### pod处于crashing状态或者unhealthy +* 确保镜像名字拼写正确 +* 确保镜像已被推送到镜像仓库 +* 用手动命令 `docker pull <镜像>` 试试看镜像是否可拉取 -首先，看一下容器的log: +<!-- +#### My pod is crashing or otherwise unhealthy + +Once your pod has been scheduled, the methods described in [Debug Running Pods]( +/docs/tasks/debug-application-cluster/debug-running-pod/) are available for debugging. +--> +#### Pod 处于 Crashing 或别的不健康状态 + +一旦 Pod 被调度，就可以采用 +[调试运行中的 Pod](/zh/docs/concepts/configuration/manage-resources-containers/) +中小鞥在的方法来进一步调试。 + +<!-- +#### My pod is running but not doing what I told it to do + +If your pod is not behaving as you expected, it may be that there was an error in your +pod description (e.g. `mypod.yaml` file on your local machine), and that the error +was silently ignored when you created the pod. Often a section of the pod description +is nested incorrectly, or a key name is typed incorrectly, and so the key is ignored. +For example, if you misspelled `command` as `commnd` then the pod will be created but +will not use the command line you intended it to use. +--> +#### Pod 处于 Running 态但是没有正常工作 + +如果 Pod 行为不符合预期，很可能 Pod 描述（例如你本地机器上的 `mypod.yaml`）中有问题， +并且该错误在创建 Pod 时被忽略掉，没有报错。 +通常，Pod 的定义中节区嵌套关系错误、字段名字拼错的情况都会引起对应内容被忽略掉。 +例如，如果你误将 `command` 写成 `commnd`，Pod 虽然可以创建，但它不会执行 +你期望它执行的命令行。 + +<!-- +The first thing to do is to delete your pod and try creating it again with the `--validate` option. +For example, run `kubectl apply --validate -f mypod.yaml`. +If you misspelled `command` as `commnd` then will give an error like this: +--> +可以做的第一件事是删除你的 Pod，并尝试才有 `--validate` 选项重新创建。 +例如，运行 `kubectl apply --validate -f mypod.yaml`。 +如果 `command` 被误拼成 `commnd`，你将会看到下面的错误信息： -```shell -$ kubectl logs ${POD_NAME} ${CONTAINER_NAME} ``` - -如果容器是crashed的，用如下命令可以看到crash的log: - -```shell -$ kubectl logs --previous ${POD_NAME} ${CONTAINER_NAME} -``` - -或者，用`exec`在容器内运行一些命令： - -```shell -$ kubectl exec ${POD_NAME} -c ${CONTAINER_NAME} -- ${CMD} ${ARG1} ${ARG2} ... ${ARGN} -``` - -注意：当一个pod内只有一个容器时，可以不带参数`-c ${CONTAINER_NAME}`。 - -例如，名为Cassandra的pod，处于running态，要查看它的log，可运行如下命令： - -```shell -$ kubectl exec cassandra -- cat /var/log/cassandra/system.log -``` - -如果以上方法都不起作用，找到这个pod所在的节点并用SSH登录进去做进一步的分析。 -通常情况下，是不需要在Kubernetes API中再给出另外的工具的。 -因此，如果你发现需要ssh进一个主机来分析问题时，请在GitHub上提一个特性请求，描述一个你的场景并说明为什么已经提供的工具不能满足需求。 - - -#### pod处于running态，但是没有正常工作 - -如果创建的pod不符合预期，那么创建pod的描述文件应该是存在某种错误的，并且这个错误在创建pod时被忽略掉。 -通常pod的定义中，章节被错误的嵌套，或者一个字段名字被写错，都可能会引起被忽略掉。 -例如，希望在pod中用命令行执行某个命令，但是将`command`写成`commnd`，pod虽然可以创建，但命令并没有执行。 - -如何查出来哪里出错？ -首先，删掉这个pod再重新创建一个，重创时，像下面这样带着`--validate`这个参数： -`kubectl create --validate -f mypod.yaml`，`command`写成`commnd`的拼写错误就会打印出来了。 - -```shell I0805 10:43:25.129850 46757 schema.go:126] unknown field: commnd I0805 10:43:25.129973 46757 schema.go:129] this may be a false alarm, see https://github.com/kubernetes/kubernetes/issues/6842 pods/mypod @@ -104,42 +162,84 @@ pods/mypod <!-- TODO: Now that #11914 is merged, this advice may need to be updated --> -如果上面方法没有看到相关异常的信息，那么接下来就要验证从apiserver获取到的pod是否与期望的一致，比如创建Pod的yaml文件是mypod.yaml。 - -运行如下命令来获取apiserver创建的pod信息并保存成一个文件： -`kubectl get pods/mypod -o yaml > mypod-on-apiserver.yaml`。 - -然后手动对这两个文件进行比较: -apiserver获得的yaml文件中的一些行，不在创建pod的yaml文件内，这是正常的。 -如果创建Pod的yaml文件内的一些行，在piserver获得的yaml文件中不存在，可以说明创建pod的yaml中的定义有问题。 - +<!-- +The next thing to check is whether the pod on the apiserver +matches the pod you meant to create (e.g. in a yaml file on your local machine). +For example, run `kubectl get pods/mypod -o yaml > mypod-on-apiserver.yaml` and then +manually compare the original pod description, `mypod.yaml` with the one you got +back from apiserver, `mypod-on-apiserver.yaml`. There will typically be some +lines on the "apiserver" version that are not on the original version. This is +expected. However, if there are lines on the original that are not on the apiserver +version, then this may indicate a problem with your pod spec. +--> +接下来就要检查的是 API 服务器上的 Pod 与你所期望创建的是否匹配 +（例如，你原本使用本机上的一个 YAML 文件来创建 Pod）。 +例如，运行 `kubectl get pods/mypod -o yaml > mypod-on-apiserver.yaml`，之后 +手动比较 `mypod.yaml` 与从 API 服务器取回的 Pod 描述。 +从 API 服务器处获得的 YAML 通常包含一些创建 Pod 所用的 YAML 中不存在的行，这是正常的。 +不过，如果如果源文件中有些行在 API 服务器版本中不存在，则意味着 +Pod 规约是有问题的。 +<!-- ### Debugging Replication Controllers -RC相当简单。他们要么能创建pod，要么不能。如果不能创建pod，请参阅上述[Debugging Pods](#debugging-pods)。 +Replication controllers are fairly straightforward. They can either create Pods or they can't. If they can't +create pods, then please refer to the [instructions above](#debugging-pods) to debug your pods. -也可以使用`kubectl describe rc ${CONTROLLER_NAME}`命令来监视RC相关的事件。 +You can also use `kubectl describe rc ${CONTROLLER_NAME}` to introspect events related to the replication +controller. +--> +### 调试副本控制器 {#debugging-replication-controllers} +副本控制器相对比较简单直接。它们要么能创建 Pod，要么不能。 +如果不能创建 Pod，请参阅[上述说明](#debugging-pods)调试 Pod。 + +你也可以使用 `kubectl describe rc ${CONTROLLER_NAME}` 命令来检视副本控制器相关的事件。 + +<!-- ### Debugging Services -服务提供了多个Pod之间的负载均衡功能。 -有一些常见的问题可以造成服务无法正常工作。以下说明将有助于调试服务的问题。 +Services provide load balancing across a set of pods. There are several common problems that can make Services +not work properly. The following instructions should help debug Service problems. -首先，验证服务是否有端点。对于每一个Service对像，apiserver使`endpoints`资源可用。 +First, verify that there are endpoints for the service. For every Service object, the apiserver makes an `endpoints` resource available. -通过如下命令可以查看endpoints资源： +You can view this resource with: +--> +### 调试服务 {#debugging-services} + +服务支持在多个 Pod 间负载均衡。 +有一些常见的问题可以造成服务无法正常工作。 +以下说明将有助于调试服务的问题。 + +首先，验证服务是否有端点。对于每一个 Service 对象，API 服务器为其提供 +对应的 `endpoints` 资源。 + +通过如下命令可以查看 endpoints 资源： ```shell -$ kubectl get endpoints ${SERVICE_NAME} +kubectl get endpoints ${SERVICE_NAME} ``` -确保endpoints与服务内容器个数一致。 -例如，如果你创建了一个nginx服务，它有3个副本，那么你就会在这个服务的endpoints中看到3个不同的IP地址。 +<!-- +Make sure that the endpoints match up with the number of pods that you expect to be members of your service. +For example, if your Service is for an nginx container with 3 replicas, you would expect to see three different +IP addresses in the Service's endpoints. +--> +确保 Endpoints 与服务成员 Pod 个数一致。 +例如，如果你的 Service 用来运行 3 个副本的 nginx 容器，你应该会在服务的 Endpoints +中看到 3 个不同的 IP 地址。 -#### 服务缺少endpoints +<!-- +#### My service is missing endpoints -如果缺少endpoints，请尝试使用服务的labels列出所有的pod。 -假如有一个服务，有如下的label： +If you are missing endpoints, try listing pods using the labels that Service uses. Imagine that you have +a Service where the labels are: +--> +#### 服务缺少 Endpoints + +如果没有 Endpoints，请尝试使用 Service 所使用的标签列出 Pod。 +假定你的服务包含如下标签选择算符： ```yaml ... @@ -149,29 +249,70 @@ spec: type: frontend ``` -你可以使用如下命令列出与selector相匹配的pod，并验证这些pod是否归属于创建的服务： - +<!-- +You can use: ```shell -$ kubectl get pods --selector=name=nginx,type=frontend +kubectl get pods --selector=name=nginx,type=frontend ``` -如果pod列表附合预期，但是endpoints仍然为空，那么可能没有暴露出正确的端口。 -如果服务指定了`containerPort`，但是列表中的Pod没有列出该端口，则不会将其添加到端口列表。 +to list pods that match this selector. Verify that the list matches the Pods that you expect to provide your Service. +--> -验证该pod的`containerPort`与服务的`containerPort`是否匹配。 +你可以使用如下命令列出与选择算符相匹配的 Pod，并验证这些 Pod 是否归属于创建的服务： -#### 网络业务不工作 +```shell +kubectl get pods --selector=name=nginx,type=frontend +``` -如果可以连接到服务上，但是连接立即被断开了，并且在endpoints列表中有endpoints，可能是代理和pods之间不通。 +<!-- +If the list of pods matches expectations, but your endpoints are still empty, it's possible that you don't +have the right ports exposed. If your service has a `containerPort` specified, but the Pods that are +selected don't have that port listed, then they won't be added to the endpoints list. -确认以下3件事情： +Verify that the pod's `containerPort` matches up with the Service's `targetPort` +--> +如果 Pod 列表符合预期，但是 Endpoints 仍然为空，那么可能暴露的端口不正确。 +如果服务指定了 `containerPort`，但是所选中的 Pod 没有列出该端口，这些 Pod +不会被添加到 Endpoints 列表。 - * Pods工作是否正常？ 看一下重启计数，并参阅[Debugging Pods](#debugging-pods)； - * 可以直接连接到pod上吗？获取pod的IP地址，然后尝试直接连接到该IP上； - * 应用是否在配置的端口上进行服务？Kubernetes不进行端口重映射，所以如果应用在8080端口上服务，那么`containerPort`字段就需要设定为8080。 +验证 Pod 的 `containerPort` 与服务的 `targetPort` 是否匹配。 -#### 更多信息 +<!-- +#### Network traffic is not forwarded -如果上述都不能解决你的问题，请按照[Debugging Service document](/docs/user-guide/debugging-services)中的介绍来确保你的`Service`处于running态，有`Endpoints`，`Pods`真正的在服务；你有DNS在工作，安装了iptables规则，kube-proxy也没有异常行为。 +If you can connect to the service, but the connection is immediately dropped, and there are endpoints +in the endpoints list, it's likely that the proxy can't contact your pods. + +There are three things to +check: + + * Are your pods working correctly? Look for restart count, and [debug pods](#debugging-pods). + * Can you connect to your pods directly? Get the IP address for the Pod, and try to connect directly to that IP. + * Is your application serving on the port that you configured? Kubernetes doesn't do port remapping, so if your application serves on 8080, the `containerPort` field needs to be 8080. +--> +#### 网络流量未被转发 + +如果你可以连接到服务上，但是连接立即被断开了，并且在 Endpoints 列表中有末端表项， +可能是代理无法连接到 Pod。 + +要检查的有以下三项： + +* Pod 工作是否正常？ 看一下重启计数，并参阅[调试 Pod](#debugging-pods)； +* 是否可以直接连接到 Pod？获取 Pod 的 IP 地址，然后尝试直接连接到该 IP； +* 应用是否在配置的端口上进行服务？Kubernetes 不进行端口重映射，所以如果应用在 + 8080 端口上服务，那么 `containerPort` 字段就要设定为 8080。 + +## {{% heading "whatsnext" %}} + +<!-- +If none of the above solves your problem, follow the instructions in [Debugging Service document](/docs/user-guide/debugging-services) to make sure that your `Service` is running, has `Endpoints`, and your `Pods` are actually serving; you have DNS working, iptables rules installed, and kube-proxy does not seem to be misbehaving. + +You may also visit [troubleshooting document](/docs/troubleshooting/) for more information. +--> +如果上述方法都不能解决你的问题，请按照 +[调试服务文档](/zh/docs/tasks/debug-application-cluster/debug-service/)中的介绍， +确保你的 `Service` 处于 Running 态，有 `Endpoints` 被创建，`Pod` 真的在提供服务； +DNS 服务已配置并正常工作，iptables 规则也以安装并且 `kube-proxy` 也没有异常行为。 + +你也可以访问[故障排查文档](/zh/docs/tasks/debug-application-cluster/troubleshooting/ )来获取更多信息。 -你也可以访问[troubleshooting document](/docs/troubleshooting/)来获取更多信息。 diff --git a/content/zh/docs/tasks/debug-application-cluster/debug-service.md b/content/zh/docs/tasks/debug-application-cluster/debug-service.md index 76cccc17d3..426020b47d 100644 --- a/content/zh/docs/tasks/debug-application-cluster/debug-service.md +++ b/content/zh/docs/tasks/debug-application-cluster/debug-service.md @@ -19,180 +19,93 @@ title: Debug Services <!-- overview --> <!-- An issue that comes up rather frequently for new installations of Kubernetes is -that a `Service` is not working properly. You've run your `Deployment` and -created a `Service`, but you get no response when you try to access it. -This document will hopefully help you to figure out what's going wrong. +that a Service is not working properly. You've run your Pods through a +Deployment (or other workload controller) and created a Service, but you +get no response when you try to access it. This document will hopefully help +you to figure out what's going wrong. --> -对于新安装的 Kubernetes，经常出现的一个问题是 `Service` 没有正常工作。如果您已经运行了 `Deployment` 并创建了一个 `Service`，但是当您尝试访问它时没有得到响应，希望这份文档能帮助您找出问题所在。 - - +对于新安装的 Kubernetes，经常出现的问题是 Service 无法正常运行。 您已经通过 +Deployment（或其他工作负载控制器）运行了 Pod，并创建 Service ，但是 +当您尝试访问它时，没有任何响应。此文档有望对您有所帮助并找出问题所在。 <!-- body --> - -<!-- -## Conventions - -Throughout this doc you will see various commands that you can run. Some -commands need to be run within a `Pod`, others on a Kubernetes `Node`, and others -can run anywhere you have `kubectl` and credentials for the cluster. To make it -clear what is expected, this document will use the following conventions. - -If the command "COMMAND" is expected to run in a `Pod` and produce "OUTPUT": - -```shell -u@pod$ COMMAND -OUTPUT -``` - -If the command "COMMAND" is expected to run on a `Node` and produce "OUTPUT": - -```shell -u@node$ COMMAND -OUTPUT -``` - -If the command is "kubectl ARGS": - -```shell -$ kubectl ARGS -OUTPUT -``` ---> -## 约定 - -在整个文档中，您将看到各种可以运行的命令。有些命令需要在 `Pod` 中运行，有些命令需要在 Kubernetes `Node` 上运行，还有一些命令可以在您拥有 `kubectl` 和集群凭证的任何地方运行。为了明确预期的效果，本文档将使用以下约定。 - -如果命令 "COMMAND" 期望在 `Pod` 中运行，并且产生 "OUTPUT"： - -```shell -u@pod$ COMMAND -OUTPUT -``` - -如果命令 "COMMAND" 期望在 `Node` 上运行，并且产生 "OUTPUT"： - -```shell -u@node$ COMMAND -OUTPUT -``` - -如果命令是 "kubectl ARGS"： - -```shell -$ kubectl ARGS -OUTPUT -``` - <!-- ## Running commands in a Pod -For many steps here you will want to see what a `Pod` running in the cluster -sees. The simplest way to do this is to run an interactive busybox `Pod`: - -```none -$ kubectl run -it --rm --restart=Never busybox --image=busybox sh -If you don't see a command prompt, try pressing enter. -/ # -``` - -If you already have a running `Pod` that you prefer to use, you can run a -command in it using: - -```shell -$ kubectl exec <POD-NAME> -c <CONTAINER-NAME> -- <COMMAND> -``` +For many steps here you will want to see what a Pod running in the cluster +sees. The simplest way to do this is to run an interactive alpine Pod: --> ## 在 pod 中运行命令 -对于这里的许多步骤，您可能希望知道运行在集群中的 `Pod` 看起来是什么样的。最简单的方法是运行一个交互式的 busybox `Pod`： - +对于这里的许多步骤，您可能希望知道运行在集群中的 Pod 看起来是什么样的。最简单的方法是运行一个交互式的 alpine Pod： ```none -$ kubectl run -it --rm --restart=Never busybox --image=busybox sh -如果你没有看到命令提示符，请尝试按 Enter 键。 -/ # +$ kubectl run -it --rm --restart=Never alpine --image=alpine sh +If you don't see a command prompt, try pressing enter. ``` +<!-- +{{< note >}} +If you don't see a command prompt, try pressing enter. +{{< /note >}} -如果您已经有了您喜欢使用的正在运行的 `Pod`，则可以运行一下命令去使用： +If you already have a running Pod that you prefer to use, you can run a +command in it using: +--> +{{< note >}} +如果你没有看到命令提示符，请尝试按 Enter 键。 +{{< /note >}} + +如果您已经有了您想使用的正在运行的 Pod，则可以运行以下命令去进入： ```shell -$ kubectl exec <POD-NAME> -c <CONTAINER-NAME> -- <COMMAND> +kubectl exec <POD-NAME> -c <CONTAINER-NAME> -- <COMMAND> ``` + <!-- ## Setup -For the purposes of this walk-through, let's run some `Pods`. Since you're -probably debugging your own `Service` you can substitute your own details, or you +For the purposes of this walk-through, let's run some Pods. Since you're +probably debugging your own Service you can substitute your own details, or you can follow along and get a second data point. - -```shell -$ kubectl run hostnames --image=k8s.gcr.io/serve_hostname \ - --labels=app=hostnames \ - --port=9376 \ - --replicas=3 -deployment.apps/hostnames created -``` - -`kubectl` commands will print the type and name of the resource created or mutated, which can then be used in subsequent commands. -{{< note >}} -This is the same as if you started the `Deployment` with the following YAML: - -```yaml -apiVersion: apps/v1 -kind: Deployment -metadata: - name: hostnames -spec: - selector: - matchLabels: - app: hostnames - replicas: 3 - template: - metadata: - labels: - app: hostnames - spec: - containers: - - name: hostnames - image: k8s.gcr.io/serve_hostname - ports: - - containerPort: 9376 - protocol: TCP -``` -{{< /note >}} - -Confirm your `Pods` are running: - -```shell -$ kubectl get pods -l app=hostnames -NAME READY STATUS RESTARTS AGE -hostnames-632524106-bbpiw 1/1 Running 0 2m -hostnames-632524106-ly40y 1/1 Running 0 2m -hostnames-632524106-tlaok 1/1 Running 0 2m -``` --> ## 设置 -为了完成本次演练的目的，我们先运行几个 `Pod`。因为可能正在调试您自己的 `Service`，所以，您可以使用自己的详细信息进行替换，或者，您也可以跟随并开始下面的步骤来获得第二个数据点。 +为了完成本次实践的任务，我们先运行几个 Pod。由于您可能正在调试自己的 Service，所以，您可以使用自己的信息进行替换，或者，您也可以跟随并开始下面的步骤来获得第二个数据点。 ```shell -$ kubectl run hostnames --image=k8s.gcr.io/serve_hostname \ - --labels=app=hostnames \ - --port=9376 \ - --replicas=3 +$ kubectl create deployment hostnames --image=k8s.gcr.io/serve_hostname +``` +```none deployment.apps/hostnames created ``` +<!-- +`kubectl` commands will print the type and name of the resource created or mutated, which can then be used in subsequent commands. + +Let's scale the deployment to 3 replicas. +--> `kubectl` 命令将打印创建或变更的资源的类型和名称，它们可以在后续命令中使用。 -{{< note >}} -这与您使用以下 YAML 启动 `Deployment` 相同： +让我们将这个 deployment 的副本数扩至 3。 +```shell +kubectl scale deployment hostnames --replicas=3 +``` +```none +deployment.apps/hostnames scaled +``` + +<!-- +Note that this is the same as if you had the Deployment with the following YAML: +--> +请注意这与您使用以下 YAML 方式启动 Deployment 类似： ```yaml apiVersion: apps/v1 kind: Deployment metadata: + labels: + app: hostnames name: hostnames spec: selector: @@ -207,185 +120,259 @@ spec: containers: - name: hostnames image: k8s.gcr.io/serve_hostname - ports: - - containerPort: 9376 - protocol: TCP ``` -{{< /note >}} -确认您的 `Pods` 是运行状态: +<!-- +The label "app" is automatically set by `kubectl create deployment` to the name of the Deployment. + +You can confirm your Pods are running: +--> + +"app" 标签是 `kubectl create deployment` 根据 Deployment 名称自动设置的。 + +确认您的 Pods 是运行状态: ```shell -$ kubectl get pods -l app=hostnames +kubectl get pods -l app=hostnames +``` +```none NAME READY STATUS RESTARTS AGE hostnames-632524106-bbpiw 1/1 Running 0 2m hostnames-632524106-ly40y 1/1 Running 0 2m hostnames-632524106-tlaok 1/1 Running 0 2m ``` +<!-- +You can also confirm that your Pods are serving. You can get the list of +Pod IP addresses and test them directly. +--> +您还可以确认您的 Pod 是否正在运行。您可以获取 Pod IP 地址列表并直接对其进行测试。 + +```shell +kubectl get pods -l app=hostnames \ + -o go-template='{{range .items}}{{.status.podIP}}{{"\n"}}{{end}}' +``` +```none +10.244.0.5 +10.244.0.6 +10.244.0.7 +``` + + +<!-- +The example container used for this walk-through simply serves its own hostname +via HTTP on port 9376, but if you are debugging your own app, you'll want to +use whatever port number your Pods are listening on. + +From within a pod: +--> +用于本教程的示例容器仅通过 HTTP 在端口 9376 上提供其自己的主机名，但是如果要调试自己的应用程序，则需要使用您的 Pod 正在侦听的端口号。 + +在 pod 内运行： + +```shell +for ep in 10.244.0.5:9376 10.244.0.6:9376 10.244.0.7:9376; do + wget -qO- $ep +done +``` +<!-- +This should produce something like: +--> +输出类似这样： + +``` +hostnames-632524106-bbpiw +hostnames-632524106-ly40y +hostnames-632524106-tlaok +``` + +<!-- +If you are not getting the responses you expect at this point, your Pods +might not be healthy or might not be listening on the port you think they are. +You might find `kubectl logs` to be useful for seeing what is happening, or +perhaps you need to `kubectl exec` directly into your Pods and debug from +there. + +Assuming everything has gone to plan so far, you can start to investigate why +your Service doesn't work. +--> +如果此时您没有收到期望的响应，则您的 Pod 状态可能不健康，或者可能没有在您认为正确的端口上进行监听。 +您可能会发现 `kubectl logs` 命令对于查看正在发生的事情很有用，或者您可能需要通过`kubectl exec` 直接进入 Pod 中并从那里进行调试。 + +假设到目前为止一切都已按计划进行，那么您可以开始调查为何您的 Service 无法正常工作。 + <!-- ## Does the Service exist? -The astute reader will have noticed that we did not actually create a `Service` +The astute reader will have noticed that you did not actually create a Service yet - that is intentional. This is a step that sometimes gets forgotten, and is the first thing to check. -So what would happen if I tried to access a non-existent `Service`? Assuming you -have another `Pod` that consumes this `Service` by name you would get something -like: - -```shell -u@pod$ wget -O- hostnames -Resolving hostnames (hostnames)... failed: Name or service not known. -wget: unable to resolve host address 'hostnames' -``` - -So the first thing to check is whether that `Service` actually exists: - -```shell -$ kubectl get svc hostnames -No resources found. -Error from server (NotFound): services "hostnames" not found -``` - -So we have a culprit, let's create the `Service`. As before, this is for the -walk-through - you can use your own `Service`'s details here. - -```shell -$ kubectl expose deployment hostnames --port=80 --target-port=9376 -service/hostnames exposed -``` - -And read it back, just to be sure: - -```shell -$ kubectl get svc hostnames -NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE -hostnames ClusterIP 10.0.1.175 <none> 80/TCP 5s -``` - -As before, this is the same as if you had started the `Service` with YAML: - -```yaml -apiVersion: v1 -kind: Service -metadata: - name: hostnames -spec: - selector: - app: hostnames - ports: - - name: default - protocol: TCP - port: 80 - targetPort: 9376 -``` - -Now you can confirm that the `Service` exists. +What would happen if you tried to access a non-existent Service? If +you have another Pod that consumes this Service by name you would get +something like: --> -## Service 存在吗？ +## Service 是否存在？ -细心的读者会注意到我们还没有真正创建一个 `Service` - 其实这是我们有意的。这是一个有时会被遗忘的步骤，也是第一件要检查的事情。 +细心的读者会注意到我们实际上尚未创建 Service -这是有意而为之。 这一步有时会被遗忘，这是首先要检查的步骤。 -那么，如果我试图访问一个不存在的 `Service`，会发生什么呢？假设您有另一个 `Pod`，想通过名称使用这个 `Service`，您将得到如下内容： +那么，如果我尝试访问不存在的 Service 会怎样？ 假设您有另一个 Pod 通过名称匹配到 Service ，您将得到类似结果： ```shell -u@pod$ wget -O- hostnames +wget -O- hostnames +``` +```none Resolving hostnames (hostnames)... failed: Name or service not known. wget: unable to resolve host address 'hostnames' ``` - -因此，首先要检查的是 `Service` 是否确实存在： +<!-- +The first thing to check is whether that Service actually exists: +--> +首先要检查的是该 Service 是否真实存在： ```shell -$ kubectl get svc hostnames +kubectl get svc hostnames +``` +```none No resources found. Error from server (NotFound): services "hostnames" not found ``` -我们已经有一个罪魁祸首了，让我们来创建 `Service`。就像前面一样，这里的内容仅仅是为了步骤的执行 - 在这里您可以使用自己的 `Service` 细节。 - -```shell -$ kubectl expose deployment hostnames --port=80 --target-port=9376 -service/hostnames exposed -``` - -再查询一遍，确定一下： - -```shell -$ kubectl get svc hostnames -NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE -hostnames ClusterIP 10.0.1.175 <none> 80/TCP 5s -``` - -与前面相同，这与您使用 YAML 启动的 `Service` 一样： - -```yaml -apiVersion: v1 -kind: Service -metadata: - name: hostnames -spec: - selector: - app: hostnames - ports: - - name: default - protocol: TCP - port: 80 - targetPort: 9376 -``` - -现在您可以确认 `Service` 存在。 - <!-- -## Does the Service work by DNS? +Let's create the Service. As before, this is for the walk-through - you can +use your own Service's details here. +--> +让我们创建 Service。 和以前一样，在这次实践中 - 您可以在此处使用自己的 Service 的内容。 +```shell +kubectl expose deployment hostnames --port=80 --target-port=9376 +``` +```none +service/hostnames exposed +``` -From a `Pod` in the same `Namespace`: +<!-- +And read it back, just to be sure: +--> +重新运行查询命令，确认没有问题： ```shell -u@pod$ nslookup hostnames +kubectl get svc hostnames +``` +```none +NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE +hostnames ClusterIP 10.0.1.175 <none> 80/TCP 5s +``` + +<!-- +Now you know that the Service exists. + +As before, this is the same as if you had started the `Service` with YAML: +--> +现在您知道了 Service 确实存在。 + +就像之前通过 YAML 方式启动 'Service' 一样： + +```yaml +apiVersion: v1 +kind: Service +metadata: + name: hostnames +spec: + selector: + app: hostnames + ports: + - name: default + protocol: TCP + port: 80 + targetPort: 9376 +``` +<!-- +In order to highlight the full range of configuration, the Service you created +here uses a different port number than the Pods. For many real-world +Services, these values might be the same. +--> +为了突出配置范围的完整性，您在此处创建的 Service 使用的端口号与 Pods 不同。对于许多真实的 Service，这些值可以是相同的。 + + +<!-- +## Does the Service work by DNS name? + +One of the most common ways that clients consume a Service is through a DNS +name. + +From a Pod in the same Namespace: +--> +## Service 是否可通过 DNS 名字访问？ + +通常客户端通过 DNS 名称来匹配到 Service。 + +从相同命名空间下的 Pod 中运行以下命令： +```shell +nslookup hostnames +``` +```none Address 1: 10.0.0.10 kube-dns.kube-system.svc.cluster.local Name: hostnames Address 1: 10.0.1.175 hostnames.default.svc.cluster.local ``` - -If this fails, perhaps your `Pod` and `Service` are in different -`Namespaces`, try a namespace-qualified name: +<!-- +If this fails, perhaps your Pod and Service are in different +Namespaces, try a namespace-qualified name (again, from within a Pod): +--> +如果失败，那么您的 Pod 和 Service 可能位于不同的命名空间中，请尝试使用限定命名空间的名称（同样在 Pod 内运行）： ```shell -u@pod$ nslookup hostnames.default +nslookup hostnames.default +``` +```none Address 1: 10.0.0.10 kube-dns.kube-system.svc.cluster.local Name: hostnames.default Address 1: 10.0.1.175 hostnames.default.svc.cluster.local ``` +<!-- If this works, you'll need to adjust your app to use a cross-namespace name, or -run your app and `Service` in the same `Namespace`. If this still fails, try a +run your app and Service in the same Namespace. If this still fails, try a fully-qualified name: +--> +如果成功，那么需要调整您的应用，使用跨命名空间的名称去访问它，或者，在相同的命名空间中运行应用和 Service。如果仍然失败，请尝试一个完全限定的名称： ```shell -u@pod$ nslookup hostnames.default.svc.cluster.local +nslookup hostnames.default.svc.cluster.local +``` +```none Address 1: 10.0.0.10 kube-dns.kube-system.svc.cluster.local Name: hostnames.default.svc.cluster.local Address 1: 10.0.1.175 hostnames.default.svc.cluster.local ``` +<!-- Note the suffix here: "default.svc.cluster.local". The "default" is the -`Namespace` we're operating in. The "svc" denotes that this is a `Service`. +Namespace you're operating in. The "svc" denotes that this is a Service. The "cluster.local" is your cluster domain, which COULD be different in your own cluster. You can also try this from a `Node` in the cluster: {{< note >}} -10.0.0.10 is my DNS `Service`, yours might be different). +10.0.0.10 is the cluster's DNS Service IP, yours might be different. +{{< /note >}} +--> +注意这里的后缀："default.svc.cluster.local"。"default" 是我们正在操作的命名空间。"svc" 表示这是一个 Service。"cluster.local" 是您的集群域，在您自己的集群中可能会有所不同。 + +您也可以在集群中的节点上尝试此操作： + +{{< note >}} +10.0.0.10 是我的 DNS 服务 IP，您的可能有所不同。 {{< /note >}} ```shell -u@node$ nslookup hostnames.default.svc.cluster.local 10.0.0.10 +nslookup hostnames.default.svc.cluster.local 10.0.0.10 +``` +```none Server: 10.0.0.10 Address: 10.0.0.10#53 @@ -393,105 +380,68 @@ Name: hostnames.default.svc.cluster.local Address: 10.0.1.175 ``` +<!-- If you are able to do a fully-qualified name lookup but not a relative one, you -need to check that your `/etc/resolv.conf` file is correct. +need to check that your `/etc/resolv.conf` file in your Pod is correct. From +within a Pod: +--> +如果您能够使用完全限定的名称查找，但不能使用相对名称，则需要检查您 Pod 中的 `/etc/resolv.conf` 文件是否正确。在 Pod 中运行以下命令： ```shell -u@pod$ cat /etc/resolv.conf +cat /etc/resolv.conf +``` +<!-- +You should see something like: +--> +您应该可以看到类似这样的输出： + +``` nameserver 10.0.0.10 search default.svc.cluster.local svc.cluster.local cluster.local example.com options ndots:5 ``` +<!-- The `nameserver` line must indicate your cluster's DNS `Service`. This is passed into `kubelet` with the `--cluster-dns` flag. The `search` line must include an appropriate suffix for you to find the -`Service` name. In this case it is looking for `Services` in the local -`Namespace` (`default.svc.cluster.local`), `Services` in all `Namespaces` -(`svc.cluster.local`), and the cluster (`cluster.local`). Depending on your own -install you might have additional records after that (up to 6 total). The -cluster suffix is passed into `kubelet` with the `--cluster-domain` flag. We -assume that is "cluster.local" in this document, but yours might be different, -in which case you should change that in all of the commands above. +Service name. In this case it is looking for Services in the local +Namespace ("default.svc.cluster.local"), Services in all Namespaces +("svc.cluster.local"), and lastly for names in the cluster ("cluster.local"). +Depending on your own install you might have additional records after that (up +to 6 total). The cluster suffix is passed into `kubelet` with the +`--cluster-domain` flag. Throughout this document, the cluster suffix is +assumed to be "cluster.local". Your own clusters might be configured +differently, in which case you should change that in all of the previous +commands. The `options` line must set `ndots` high enough that your DNS client library considers search paths at all. Kubernetes sets this to 5 by default, which is high enough to cover all of the DNS names it generates. --> -## Service 是否通过 DNS 工作？ +`nameserver` 行必须指示您的集群的 DNS Service，它通过 `--cluster-dns` 标志传递到 kubelet。 -从相同 `Namespace` 下的 `Pod` 中运行： - -```shell -u@pod$ nslookup hostnames -Address 1: 10.0.0.10 kube-dns.kube-system.svc.cluster.local - -Name: hostnames -Address 1: 10.0.1.175 hostnames.default.svc.cluster.local -``` - -如果失败，那么您的 `Pod` 和 `Service` 可能位于不同的 `Namespace` 中，请尝试使用限定命名空间的名称： - -```shell -u@pod$ nslookup hostnames.default -Address 1: 10.0.0.10 kube-dns.kube-system.svc.cluster.local - -Name: hostnames.default -Address 1: 10.0.1.175 hostnames.default.svc.cluster.local -``` - -如果成功，那么需要调整您的应用，使用跨命名空间的名称去访问服务，或者，在相同的 `Namespace` 中运行应用和 `Service`。如果仍然失败，请尝试一个完全限定的名称： - -```shell -u@pod$ nslookup hostnames.default.svc.cluster.local -Address 1: 10.0.0.10 kube-dns.kube-system.svc.cluster.local - -Name: hostnames.default.svc.cluster.local -Address 1: 10.0.1.175 hostnames.default.svc.cluster.local -``` - -注意这里的后缀："default.svc.cluster.local"。"default" 是我们正在操作的 `Namespace`。"svc" 表示这是一个 `Service`。"cluster.local" 是您的集群域，在您自己的集群中可能会有所不同。 - -您也可以在集群中的 Node 上尝试此操作： - -{{< note >}} -10.0.0.10 是我的 DNS `Service`，您的可能不同）. -{{< /note >}} - -```shell -u@node$ nslookup hostnames.default.svc.cluster.local 10.0.0.10 -Server: 10.0.0.10 -Address: 10.0.0.10#53 - -Name: hostnames.default.svc.cluster.local -Address: 10.0.1.175 -``` - -如果您能够使用完全限定的名称查找，但不能使用相对名称，则需要检查 `/etc/resolv.conf` 文件是否正确。 - -```shell -u@pod$ cat /etc/resolv.conf -nameserver 10.0.0.10 -search default.svc.cluster.local svc.cluster.local cluster.local example.com -options ndots:5 -``` - -`nameserver` 行必须指示您的集群的 DNS `Service`，它通过 `--cluster-dns` 标志传递到 `kubelet`。 - -`search` 行必须包含一个适当的后缀，以便查找 `Service` 名称。在本例中，它在本地 `Namespace`（`default.svc.cluster.local`）、所有 `Namespace` 中的 `Service`（`svc.cluster.local`）以及集群（`cluster.local`）中查找服务。 根据您自己的安装情况，可能会有额外的记录（最多 6 条）。集群后缀通过 `--cluster-domain` 标志传递给 `kubelet`。 本文档中，我们假定它是 “cluster.local”，但是您的可能不同，这种情况下，您应该在上面的所有命令中更改它。 +`search` 行必须包含一个适当的后缀，以便查找 Service 名称。在本例中，它在本地命名空间（`default.svc.cluster.local`）、所有命名空间中的 `Service`（`svc.cluster.local`）最后是集群（`cluster.local`）中查找 Service 的名称。根据您自己的安装情况，可能会有额外的记录（最多 6 条）。 +集群后缀通过 `--cluster-domain` 标志传递给 `kubelet`。 本文档中，我们假定后缀是 “cluster.local”。您的集群配置可能不同，这种情况下，您应该在上面的所有命令中更改它。 `options` 行必须设置足够高的 `ndots`，以便 DNS 客户端库考虑搜索路径。在默认情况下，Kubernetes 将这个值设置为 5，这个值足够高，足以覆盖它生成的所有 DNS 名称。 <!-- -### Does any Service exist in DNS? +### Does any Service work by DNS name? {#does-any-service-exist-in-dns} -If the above still fails - DNS lookups are not working for your `Service` - we +If the above still fails, DNS lookups are not working for your Service. You can take a step back and see what else is not working. The Kubernetes master -`Service` should always work: +Service should always work. From within a Pod: +--> +### 是否存在 Service 能通过 DNS 名称访问？{#does-any-service-exist-in-dns} + +如果上面的方式仍然失败，DNS 查找不到您需要的 Service ，您可以后退一步，看看还有什么其它东西没有正常工作。Kubernetes 主 Service 应该一直是工作的。在 Pod 中运行如下命令： ```shell -u@pod$ nslookup kubernetes.default +nslookup kubernetes.default +``` +```none Server: 10.0.0.10 Address 1: 10.0.0.10 kube-dns.kube-system.svc.cluster.local @@ -499,121 +449,59 @@ Name: kubernetes.default Address 1: 10.0.0.1 kubernetes.default.svc.cluster.local ``` -If this fails, you might need to go to the kube-proxy section of this doc, or -even go back to the top of this document and start over, but instead of -debugging your own `Service`, debug DNS. +<!-- +If this fails, please see the [kube-proxy](#is-the-kube-proxy-working) section +of this document, or even go back to the top of this document and start over, +but instead of debugging your own Service, debug the DNS Service. ## Does the Service work by IP? -Assuming we can confirm that DNS works, the next thing to test is whether your -`Service` works at all. From a node in your cluster, access the `Service`'s -IP (from `kubectl get` above). - -```shell -u@node$ curl 10.0.1.175:80 -hostnames-0uton - -u@node$ curl 10.0.1.175:80 -hostnames-yp2kp - -u@node$ curl 10.0.1.175:80 -hostnames-bvc05 -``` - -If your `Service` is working, you should get correct responses. If not, there -are a number of things that could be going wrong. Read on. +Assuming you have confirmed that DNS works, the next thing to test is whether your +Service works by its IP address. From a Pod in your cluster, access the +Service's IP (from `kubectl get` above). --> -### DNS 中是否存在任何服务？ - -如果上面仍然失败 - DNS 查找不到您需要的 `Service` - 我们可以后退一步，看看还有什么不起作用。Kubernetes 主 `Service` 应该一直是工作的： - -```shell -u@pod$ nslookup kubernetes.default -Server: 10.0.0.10 -Address 1: 10.0.0.10 kube-dns.kube-system.svc.cluster.local - -Name: kubernetes.default -Address 1: 10.0.0.1 kubernetes.default.svc.cluster.local -``` - -如果失败，您可能需要转到这个文档的 kube-proxy 部分，或者甚至回到文档的顶部重新开始，但不是调试您自己的 `Service`，而是调试 DNS。 +如果失败，您可能需要转到这个文档的 [kube-proxy](#is-the-kube-proxy-working) 部分，或者甚至回到文档的顶部重新开始，但不是调试您自己的 Service ，而是调试 DNS Service。 ### Service 能够通过 IP 访问么？ -假设我们可以确认 DNS 工作正常，那么接下来要测试的是您的 `Service` 是否工作正常。从集群中的一个节点，访问 `Service` 的 IP（从上面的 `kubectl get` 命令获取）。 +假设您已经确认 DNS 工作正常，那么接下来要测试的是您的 Service 能否通过它的 IP 正常访问。从集群中的一个 Pod，尝试访问 Service 的 IP（从上面的 `kubectl get` 命令获取）。 ```shell -u@node$ curl 10.0.1.175:80 -hostnames-0uton - -u@node$ curl 10.0.1.175:80 -hostnames-yp2kp - -u@node$ curl 10.0.1.175:80 -hostnames-bvc05 +for i in $(seq 1 3); do + wget -qO- 10.0.1.175:80 +done ``` -如果 `Service` 是正常的，您应该得到正确的响应。如果没有，有很多可能出错的地方，请继续。 +<!-- +This should produce something like: +--> +输出应该类似这样： + +``` +hostnames-632524106-bbpiw +hostnames-632524106-ly40y +hostnames-632524106-tlaok +``` <!-- -## Is the Service correct? +If your Service is working, you should get correct responses. If not, there +are a number of things that could be going wrong. Read on. +--> +如果 Service 状态是正常的，您应该得到正确的响应。如果没有，有很多可能出错的地方，请继续阅读。 + +<!-- +## Is the Service defined correctly? It might sound silly, but you should really double and triple check that your `Service` is correct and matches your `Pod`'s port. Read back your `Service` and verify it: - -```shell -$ kubectl get service hostnames -o json -``` -```json -{ - "kind": "Service", - "apiVersion": "v1", - "metadata": { - "name": "hostnames", - "namespace": "default", - "uid": "428c8b6c-24bc-11e5-936d-42010af0a9bc", - "resourceVersion": "347189", - "creationTimestamp": "2015-07-07T15:24:29Z", - "labels": { - "app": "hostnames" - } - }, - "spec": { - "ports": [ - { - "name": "default", - "protocol": "TCP", - "port": 80, - "targetPort": 9376, - "nodePort": 0 - } - ], - "selector": { - "app": "hostnames" - }, - "clusterIP": "10.0.1.175", - "type": "ClusterIP", - "sessionAffinity": "None" - }, - "status": { - "loadBalancer": {} - } -} -``` - -Is the port you are trying to access in `spec.ports[]`? Is the `targetPort` -correct for your `Pods` (many `Pods` choose to use a different port than the -`Service`)? If you meant it to be a numeric port, is it a number (9376) or a -string "9376"? If you meant it to be a named port, do your `Pods` expose a port -with the same name? Is the port's `protocol` the same as the `Pod`'s? --> -## Service 是对的吗？ +## Service 的配置是否正确？ -这听起来可能很愚蠢，但您应该加倍甚至三倍检查您的 `Service` 是否正确，并且与您的 `Pod` 匹配。查看您的 `Service` 并验证它： +这听起来可能很愚蠢，但您应该两次甚至三次检查您的 Service 配置是否正确，并且与您的 Pod 匹配。查看您的 Service 配置并验证它： ```shell -$ kubectl get service hostnames -o json +kubectl get service hostnames -o json ``` ```json { @@ -622,7 +510,6 @@ $ kubectl get service hostnames -o json "metadata": { "name": "hostnames", "namespace": "default", - "selfLink": "/api/v1/namespaces/default/services/hostnames", "uid": "428c8b6c-24bc-11e5-936d-42010af0a9bc", "resourceVersion": "347189", "creationTimestamp": "2015-07-07T15:24:29Z", @@ -652,174 +539,176 @@ $ kubectl get service hostnames -o json } } ``` - -`spec.ports[]` 中描述的是您想要尝试访问的端口吗？`targetPort` 对您的 `Pod` 来说正确吗（许多 `Pod` 选择使用与 `Service` 不同的端口）？如果您想把它变成一个数字端口，那么它是一个数字（9376）还是字符串 “9376”？如果您想把它当作一个指定的端口，那么您的 `Pod` 是否公开了一个同名端口？端口的 `protocol` 和 `Pod` 的一样吗？ +<!-- +* Is the Service port you are trying to access listed in `spec.ports[]`? +* Is the `targetPort` correct for your Pods (some Pods use a different port than the Service)? +* If you meant to use a numeric port, is it a number (9376) or a string "9376"? +* If you meant to use a named port, do your Pods expose a port with the same name? +* Is the port's `protocol` correct for your Pods? +--> +* 您想要访问的 Service 端口是否在 `spec.ports[]` 中列出？ +* `targetPort` 对您的 Pod 来说正确吗（许多 Pod 使用与 Service 不同的端口）？ +* 如果您想使用数值型端口，那么它的类型是一个数值（9376）还是字符串 “9376”？ +* 如果您想使用名称型端口，那么您的 Pod 是否暴露了一个同名端口？ +* 端口的 `protocol` 和 Pod 的是否对应？ <!-- ## Does the Service have any Endpoints? -If you got this far, we assume that you have confirmed that your `Service` -exists and is resolved by DNS. Now let's check that the `Pods` you ran are -actually being selected by the `Service`. +If you got this far, you have confirmed that your Service is correctly +defined and is resolved by DNS. Now let's check that the Pods you ran are +actually being selected by the Service. -Earlier we saw that the `Pods` were running. We can re-check that: +Earlier you saw that the Pods were running. You can re-check that: +--> +## Service 有 Endpoint 吗？ + +如果您已经走到了这一步，您已经确认您的 Service 被正确定义，并能通过 DNS 解析。现在，让我们检查一下，您运行的 Pod 确实是由 Service 选择的。 + +早些时候，我们已经看到 Pod 是运行状态。我们可以再检查一下： ```shell -$ kubectl get pods -l app=hostnames -NAME READY STATUS RESTARTS AGE -hostnames-0uton 1/1 Running 0 1h -hostnames-bvc05 1/1 Running 0 1h -hostnames-yp2kp 1/1 Running 0 1h +kubectl get pods -l app=hostnames ``` +```none +NAME READY STATUS RESTARTS AGE +hostnames-632524106-bbpiw 1/1 Running 0 1h +hostnames-632524106-ly40y 1/1 Running 0 1h +hostnames-632524106-tlaok 1/1 Running 0 1h +``` +<!-- +The `-l app=hostnames` argument is a label selector - just like our Service +has. -The "AGE" column says that these `Pods` are about an hour old, which implies that +The "AGE" column says that these Pods are about an hour old, which implies that they are running fine and not crashing. -The `-l app=hostnames` argument is a label selector - just like our `Service` -has. Inside the Kubernetes system is a control loop which evaluates the -selector of every `Service` and saves the results into an `Endpoints` object. +The "RESTARTS" column says that these pods are not crashing frequently or being +restarted. Frequent restarts could lead to intermittent connectivity issues. +If the restart count is high, read more about how to [debug pods](/docs/tasks/debug-application-cluster/debug-pod-replication-controller/#debugging-pods). -```shell -$ kubectl get endpoints hostnames -NAME ENDPOINTS -hostnames 10.244.0.5:9376,10.244.0.6:9376,10.244.0.7:9376 -``` - -This confirms that the endpoints controller has found the correct `Pods` for -your `Service`. If the `hostnames` row is blank, you should check that the -`spec.selector` field of your `Service` actually selects for `metadata.labels` -values on your `Pods`. A common mistake is to have a typo or other error, such -as the `Service` selecting for `run=hostnames`, but the `Deployment` specifying -`app=hostnames`. +Inside the Kubernetes system is a control loop which evaluates the selector of +every Service and saves the results into a corresponding Endpoints object. --> -## Service 有端点吗？ +`-l app=hostnames` 参数是一个标签选择器 - 和我们 Service 中的一样。 -如果您已经走到了这一步，我们假设您已经确认您的 `Service` 存在，并能通过 DNS 解析。现在，让我们检查一下，您运行的 `Pod` 确实是由 `Service` 选择的。 +"AGE" 列表明这些 Pod 已经启动一个小时了，这意味着它们运行良好，而不是崩溃。 -早些时候，我们已经看到 `Pod` 是运行状态。我们可以再检查一下： +"RESTARTS" 列表明 Pod 没有经常崩溃或重启。经常性崩溃可能导致间歇性连接问题。如果重启数过大，通过[调试 pod](/docs/tasks/debug-application-cluster/debug-pod-replication-controller/#debugging-pods)了解更多。 + +在 Kubernetes 系统中有一个控制循环，它评估每个 Service 的选择器，并将结果保存到 Endpoints 对象中。 ```shell -$ kubectl get pods -l app=hostnames -NAME READY STATUS RESTARTS AGE -hostnames-0uton 1/1 Running 0 1h -hostnames-bvc05 1/1 Running 0 1h -hostnames-yp2kp 1/1 Running 0 1h -``` +kubectl get endpoints hostnames -"AGE" 列表明这些 `Pod` 已经启动一个小时了，这意味着它们运行良好，而不是崩溃。 - -`-l app=hostnames` 参数是一个标签选择器 - 就像我们的 `Service` 一样。在 Kubernetes 系统中有一个控制循环，它评估每个 `Service` 的选择器，并将结果保存到 `Endpoints` 对象中。 - -```shell -$ kubectl get endpoints hostnames NAME ENDPOINTS hostnames 10.244.0.5:9376,10.244.0.6:9376,10.244.0.7:9376 ``` -这证实 endpoints 控制器已经为您的 `Service` 找到了正确的 `Pods`。如果 `hostnames` 行为空，则应检查 `Service` 的 `spec.selector` 字段，以及您实际想选择的 `Pods` 的 `metadata.labels` 的值。常见的错误是输入错误或其他错误，例如 `Service` 想选择 `run=hostnames`，但是 `Deployment` 指定的是 `app=hostnames`。 +<!-- +This confirms that the endpoints controller has found the correct Pods for +your Service. If the `ENDPOINTS` column is `<none>`, you should check that +the `spec.selector` field of your Service actually selects for +`metadata.labels` values on your Pods. A common mistake is to have a typo or +other error, such as the Service selecting for `app=hostnames`, but the +Deployment specifying `run=hostnames`, as in versions previous to 1.18, where +the `kubectl run` command could have been also used to create a Deployment. +--> +这证实 endpoint 控制器已经为您的 Service 找到了正确的 Pods。如果 `Endpoint` 列的值为 `<none>`，则应检查 Service 的 `spec.selector` 字段，以及您实际想选择的 Pod 的 `metadata.labels` 的值。常见的错误是输入错误或其他错误，例如 Service 想选择 `app=hostnames`，但是 Deployment 指定的是 `run=hostnames`。在 1.18之前的版本中 `kubectl run` 也可以被用来创建 Deployment。 <!-- ## Are the Pods working? -At this point, we know that your `Service` exists and has selected your `Pods`. -Let's check that the `Pods` are actually working - we can bypass the `Service` -mechanism and go straight to the `Pods`. +At this point, you know that your Service exists and has selected your Pods. +At the beginning of this walk-through, you verified the Pods themselves. +Let's check again that the Pods are actually working - you can bypass the +Service mechanism and go straight to the Pods, as listed by the Endpoints +above. {{< note >}} -These commands use the `Pod` port (9376), rather than the `Service` port (80). +These commands use the Pod port (9376), rather than the Service port (80). {{< /note >}} -```shell -u@pod$ wget -qO- 10.244.0.5:9376 -hostnames-0uton - -pod $ wget -qO- 10.244.0.6:9376 -hostnames-bvc05 - -u@pod$ wget -qO- 10.244.0.7:9376 -hostnames-yp2kp -``` - -We expect each `Pod` in the `Endpoints` list to return its own hostname. If -this is not what happens (or whatever the correct behavior is for your own -`Pods`), you should investigate what's happening there. You might find -`kubectl logs` to be useful or `kubectl exec` directly to your `Pods` and check -service from there. - -Another thing to check is that your `Pods` are not crashing or being restarted. -Frequent restarts could lead to intermittent connectivity issues. - -```shell -$ kubectl get pods -l app=hostnames -NAME READY STATUS RESTARTS AGE -hostnames-632524106-bbpiw 1/1 Running 0 2m -hostnames-632524106-ly40y 1/1 Running 0 2m -hostnames-632524106-tlaok 1/1 Running 0 2m -``` - -If the restart count is high, read more about how to [debug -pods](/docs/tasks/debug-application-cluster/debug-pod-replication-controller/#debugging-pods). +From within a Pod: --> ## Pod 正常工作吗？ -到了这步，我们知道您的 `Service` 存在并选择了您的 `Pods`。让我们检查一下 `Pod` 是否真的在工作 - 我们可以绕过 `Service` 机制，直接进入 `Pod`。 +至此，您知道您的 Service 已存在，并且已匹配到您的Pod。在本实践的开始，您验证了 Pod 本身。 +让我们再次检查 Pod 是否确实在工作-您可以绕过 Service 机制并直接转到 Pod，如上面的 Endpoint 所示。 {{< note >}} -这些命令使用的是 `Pod` 端口（9376），而不是 `Service` 端口（80）。 +这些命令使用的是 Pod 端口（9376），而不是 Service 端口（80）。 {{< /note >}} -```shell -u@pod$ wget -qO- 10.244.0.5:9376 -hostnames-0uton - -pod $ wget -qO- 10.244.0.6:9376 -hostnames-bvc05 - -u@pod$ wget -qO- 10.244.0.7:9376 -hostnames-yp2kp -``` - -我们期望的是 `Endpoints` 列表中的每个 `Pod` 返回自己的主机名。如果这没有发生（或者您自己的 `Pod` 的正确行为没有发生），您应该调查发生了什么。您会发现 `kubectl logs` 这个时候非常有用，或者使用 `kubectl exec` 直接进入到您的 `Pod`，并从那里检查服务。 - -另一件要检查的事情是，您的 Pod 没有崩溃或正在重新启动。频繁的重新启动可能会导致断断续续的连接问题。 +在 Pod 中运行： ```shell -$ kubectl get pods -l app=hostnames -NAME READY STATUS RESTARTS AGE -hostnames-632524106-bbpiw 1/1 Running 0 2m -hostnames-632524106-ly40y 1/1 Running 0 2m -hostnames-632524106-tlaok 1/1 Running 0 2m +for ep in 10.244.0.5:9376 10.244.0.6:9376 10.244.0.7:9376; do + wget -qO- $ep +done ``` -如果重新启动计数很高，请查阅有关如何[调试 pods](/docs/tasks/debug-application-cluster/debug-pod-replication-controller/#debugging-pods) 获取更多信息。 +<!-- +This should produce something like: +--> +输出应该类似这样： +``` +hostnames-632524106-bbpiw +hostnames-632524106-ly40y +hostnames-632524106-tlaok +``` + +<!-- +You expect each Pod in the Endpoints list to return its own hostname. If +this is not what happens (or whatever the correct behavior is for your own +Pods), you should investigate what's happening there. +--> +您希望 Endpoint 列表中的每个 Pod 都返回自己的主机名。 如果这不是发生的情况（或您自己的 Pod 的正确行为是什么），您应调查那里发生了什么。 <!-- ## Is the kube-proxy working? -If you get here, your `Service` is running, has `Endpoints`, and your `Pods` -are actually serving. At this point, the whole `Service` proxy mechanism is +If you get here, your Service is running, has Endpoints, and your Pods +are actually serving. At this point, the whole Service proxy mechanism is suspect. Let's confirm it, piece by piece. + +The default implementation of Services, and the one used on most clusters, is +kube-proxy. This is a program that runs on every node and configures one of a +small set of mechanisms for providing the Service abstraction. If your +cluster does not use kube-proxy, the following sections will not apply, and you +will have to investigate whatever implementation of Services you are using. --> ## kube-proxy 正常工作吗？ -如果您到了这里，那么您的 `Service` 正在运行，也有 `Endpoints`，而您的 `Pod` 实际上也正在服务。在这一点上，整个 `Service` 代理机制是否正常就是可疑的了。我们来确认一下，一部分一部分来。 +如果您到达这里，则说明您的 Service 正在运行，拥有 Endpoint ，Pod 真正在运行。 此时此刻，整个 Service 代理机制是可疑的。 让我们一步一步地确认它没问题。 + + Service 的默认实现（在大多数集群上应用的）是 kube-proxy。这是一个在每个节点上运行的程序，并配置一小组用于提供 Service 抽象的机制之一。如果您的集群不使用 kube-proxy，则以下各节将不适用，您将必须检查您正在使用的 Service 的实现方式。 <!-- -### Is kube-proxy running? +## Is the kube-proxy working? -Confirm that `kube-proxy` is running on your `Nodes`. You should get something -like the below: +Confirm that `kube-proxy` is running on your Nodes. Running directly on a +Node, you should get something like the below: +--> +### kube-proxy 正常运行吗？ + +确认 `kube-proxy` 正在节点上运行。 在节点上直接运行，您将会得到类似以下的输出： ```shell -u@node$ ps auxw | grep kube-proxy +ps auxw | grep kube-proxy +``` +```none root 4194 0.4 0.1 101864 17696 ? Sl Jul04 25:43 /usr/local/bin/kube-proxy --master=https://kubernetes-master --kubeconfig=/var/lib/kube-proxy/kubeconfig --v=2 ``` +<!-- Next, confirm that it is not failing something obvious, like contacting the master. To do this, you'll have to look at the logs. Accessing the logs -depends on your `Node` OS. On some OSes it is a file, such as +depends on your Node OS. On some OSes it is a file, such as /var/log/kube-proxy.log, while other OSes use `journalctl` to access logs. You should see something like: +--> +下一步，确认它并没有出现明显的失败，比如连接主节点失败。要做到这一点，您必须查看日志。访问日志取决于您节点的操作系统。在某些操作系统是一个文件，如 /var/log/messages kube-proxy.log，而其他操作系统使用 `journalctl` 访问日志。您应该看到类似的输出： ```none I1027 22:14:53.995134 5063 server.go:200] Running in resource-only container "/kube-proxy" @@ -834,8 +723,9 @@ I1027 22:14:54.040154 5063 proxier.go:294] Adding new service "kube-system/ku I1027 22:14:54.040223 5063 proxier.go:294] Adding new service "kube-system/kube-dns:dns-tcp" at 10.0.0.10:53/TCP ``` +<!-- If you see error messages about not being able to contact the master, you -should double-check your `Node` configuration and installation steps. +should double-check your Node configuration and installation steps. One of the possible reasons that `kube-proxy` cannot run correctly is that the required `conntrack` binary cannot be found. This may happen on some Linux @@ -844,233 +734,206 @@ installing Kubernetes from scratch. If this is the case, you need to manually install the `conntrack` package (e.g. `sudo apt install conntrack` on Ubuntu) and then retry. --> -### kube-proxy 在运行吗？ - -确认 `kube-proxy` 正在您的 `Nodes` 上运行。您应该得到如下内容： - -```shell -u@node$ ps auxw | grep kube-proxy -root 4194 0.4 0.1 101864 17696 ? Sl Jul04 25:43 /usr/local/bin/kube-proxy --master=https://kubernetes-master --kubeconfig=/var/lib/kube-proxy/kubeconfig --v=2 -``` - -下一步，确认它并没有出现明显的失败，比如连接主节点失败。要做到这一点，您必须查看日志。访问日志取决于您的 `Node` 操作系统。在某些操作系统是一个文件，如 /var/log/messages kube-proxy.log，而其他操作系统使用 `journalctl` 访问日志。您应该看到类似的东西： - -```none -I1027 22:14:53.995134 5063 server.go:200] Running in resource-only container "/kube-proxy" -I1027 22:14:53.998163 5063 server.go:247] Using iptables Proxier. -I1027 22:14:53.999055 5063 server.go:255] Tearing down userspace rules. Errors here are acceptable. -I1027 22:14:54.038140 5063 proxier.go:352] Setting endpoints for "kube-system/kube-dns:dns-tcp" to [10.244.1.3:53] -I1027 22:14:54.038164 5063 proxier.go:352] Setting endpoints for "kube-system/kube-dns:dns" to [10.244.1.3:53] -I1027 22:14:54.038209 5063 proxier.go:352] Setting endpoints for "default/kubernetes:https" to [10.240.0.2:443] -I1027 22:14:54.038238 5063 proxier.go:429] Not syncing iptables until Services and Endpoints have been received from master -I1027 22:14:54.040048 5063 proxier.go:294] Adding new service "default/kubernetes:https" at 10.0.0.1:443/TCP -I1027 22:14:54.040154 5063 proxier.go:294] Adding new service "kube-system/kube-dns:dns" at 10.0.0.10:53/UDP -I1027 22:14:54.040223 5063 proxier.go:294] Adding new service "kube-system/kube-dns:dns-tcp" at 10.0.0.10:53/TCP -``` - 如果您看到有关无法连接主节点的错误消息，则应再次检查节点配置和安装步骤。 `kube-proxy` 无法正确运行的可能原因之一是找不到所需的 `conntrack` 二进制文件。在一些 Linux 系统上，这也是可能发生的，这取决于您如何安装集群，例如，您正在从头开始安装 Kubernetes。如果是这样的话，您需要手动安装 `conntrack` 包（例如，在 Ubuntu 上使用 `sudo apt install conntrack`），然后重试。 <!-- -### Is kube-proxy writing iptables rules? +Kube-proxy can run in one of a few modes. In the log listed above, the +line `Using iptables Proxier` indicates that kube-proxy is running in +"iptables" mode. The most common other mode is "ipvs". The older "userspace" +mode has largely been replaced by these. -One of the main responsibilities of `kube-proxy` is to write the `iptables` -rules which implement `Services`. Let's check that those rules are getting -written. +#### Iptables mode -The kube-proxy can run in "userspace" mode, "iptables" mode or "ipvs" mode. -Hopefully you are using the "iptables" mode or "ipvs" mode. You -should see one of the following cases. +In "iptables" mode, you should see something like the following on a Node: +--> +Kube-proxy 可以在这些模式之一中运行。在上述日志中，`Using iptables Proxier` 行表示 kube-proxy 在 "iptables" 模式下运行。最常见的另一种模式是 "ipvs"。先前的 "userspace" +模式已经被这些所代替。 -#### Userspace +#### Iptables 模式 + +在 "iptables" 模式中, 您应该可以在节点上看到如下输出: ```shell -u@node$ iptables-save | grep hostnames +iptables-save | grep hostnames +``` +```none +-A KUBE-SEP-57KPRZ3JQVENLNBR -s 10.244.3.6/32 -m comment --comment "default/hostnames:" -j MARK --set-xmark 0x00004000/0x00004000 +-A KUBE-SEP-57KPRZ3JQVENLNBR -p tcp -m comment --comment "default/hostnames:" -m tcp -j DNAT --to-destination 10.244.3.6:9376 +-A KUBE-SEP-WNBA2IHDGP2BOBGZ -s 10.244.1.7/32 -m comment --comment "default/hostnames:" -j MARK --set-xmark 0x00004000/0x00004000 +-A KUBE-SEP-WNBA2IHDGP2BOBGZ -p tcp -m comment --comment "default/hostnames:" -m tcp -j DNAT --to-destination 10.244.1.7:9376 +-A KUBE-SEP-X3P2623AGDH6CDF3 -s 10.244.2.3/32 -m comment --comment "default/hostnames:" -j MARK --set-xmark 0x00004000/0x00004000 +-A KUBE-SEP-X3P2623AGDH6CDF3 -p tcp -m comment --comment "default/hostnames:" -m tcp -j DNAT --to-destination 10.244.2.3:9376 +-A KUBE-SERVICES -d 10.0.1.175/32 -p tcp -m comment --comment "default/hostnames: cluster IP" -m tcp --dport 80 -j KUBE-SVC-NWV5X2332I4OT4T3 +-A KUBE-SVC-NWV5X2332I4OT4T3 -m comment --comment "default/hostnames:" -m statistic --mode random --probability 0.33332999982 -j KUBE-SEP-WNBA2IHDGP2BOBGZ +-A KUBE-SVC-NWV5X2332I4OT4T3 -m comment --comment "default/hostnames:" -m statistic --mode random --probability 0.50000000000 -j KUBE-SEP-X3P2623AGDH6CDF3 +-A KUBE-SVC-NWV5X2332I4OT4T3 -m comment --comment "default/hostnames:" -j KUBE-SEP-57KPRZ3JQVENLNBR +``` + +<!-- +For each port of each Service, there should be 1 rule in `KUBE-SERVICES` and +one `KUBE-SVC-<hash>` chain. For each Pod endpoint, there should be a small +number of rules in that `KUBE-SVC-<hash>` and one `KUBE-SEP-<hash>` chain with +a small number of rules in it. The exact rules will vary based on your exact +config (including node-ports and load-balancers). + +#### IPVS mode + +In "ipvs" mode, you should see something like the following on a Node: +--> +对于每个 Service 的所有端口，应有 1 条规则、一个链。对于每个 Pod endpoint，在那个XX应该有一些规则，也应该包含小数目的规则。实际的规则数量可能会根据您实际的配置（包括节点端口和负载均衡）有所不同。 +For each port of each Service, there should be 1 rule in `KUBE-SERVICES` and +one `KUBE-SVC-<hash>` chain. For each Pod endpoint, there should be a small +number of rules in that `KUBE-SVC-<hash>` and one `KUBE-SEP-<hash>` chain with +a small number of rules in it. The exact rules will vary based on your exact +config (including node-ports and load-balancers). + +#### IPVS 模式 + +在 "ipvs" 模式中, 您应该在节点下看到如下输出： + +```shell +ipvsadm -ln +``` +```none +Prot LocalAddress:Port Scheduler Flags + -> RemoteAddress:Port Forward Weight ActiveConn InActConn +... +TCP 10.0.1.175:80 rr + -> 10.244.0.5:9376 Masq 1 0 0 + -> 10.244.0.6:9376 Masq 1 0 0 + -> 10.244.0.7:9376 Masq 1 0 0 +... +``` + +<!-- +For each port of each Service, plus any NodePorts, external IPs, and +load-balancer IPs, kube-proxy will create a virtual server. For each Pod +endpoint, it will create corresponding real servers. In this example, service +hostnames(`10.0.1.175:80`) has 3 endpoints(`10.244.0.5:9376`, +`10.244.0.6:9376`, `10.244.0.7:9376`). + +#### Userspace mode + +In rare cases, you may be using "userspace" mode. From your Node: +--> +对于每个 Service 的每个端口，还有 NodePort，外部 IP 和 +负载平衡器 IP，kube-proxy 将创建一个虚拟服务器。 对于每个 Pod Endpoint ，它将创建相应的真实服务器。 在此示例中，服务主机名(`10.0.1.175:80`)拥有 3 个 endpoint（`10.244.0.5:9376`, +`10.244.0.6:9376`, `10.244.0.7:9376`)。 + +#### Userspace 模式 + +在少数情况下，您可能会用到 "userspace" 模式，在您的节点上运行： + +```shell +iptables-save | grep hostnames +``` +```none -A KUBE-PORTALS-CONTAINER -d 10.0.1.175/32 -p tcp -m comment --comment "default/hostnames:default" -m tcp --dport 80 -j REDIRECT --to-ports 48577 -A KUBE-PORTALS-HOST -d 10.0.1.175/32 -p tcp -m comment --comment "default/hostnames:default" -m tcp --dport 80 -j DNAT --to-destination 10.240.115.247:48577 ``` -There should be 2 rules for each port on your `Service` (just one in this -example) - a "KUBE-PORTALS-CONTAINER" and a "KUBE-PORTALS-HOST". If you do -not see these, try restarting `kube-proxy` with the `-V` flag set to 4, and -then look at the logs again. +<!-- +There should be 2 rules for each port of your Service (just one in this +example) - a "KUBE-PORTALS-CONTAINER" and a "KUBE-PORTALS-HOST". -Almost nobody should be using the "userspace" mode any more, so we won't spend +Almost nobody should be using the "userspace" mode any more, so you won't spend more time on it here. ---> -### kube-proxy 是否在写 iptables 规则？ -`kube-proxy` 的主要职责之一是写实现 `Services` 的 `iptables` 规则。让我们检查一下这些规则是否已经被写好了。 - -kube-proxy 可以在 "userspace" 模式、 "iptables" 模式或者 "ipvs" 模式下运行。 -希望您正在使用 "iptables" 模式或者 "ipvs" 模式。您应该看到以下情况之一。 - -#### Userpace - -```shell -u@node$ iptables-save | grep hostnames --A KUBE-PORTALS-CONTAINER -d 10.0.1.175/32 -p tcp -m comment --comment "default/hostnames:default" -m tcp --dport 80 -j REDIRECT --to-ports 48577 --A KUBE-PORTALS-HOST -d 10.0.1.175/32 -p tcp -m comment --comment "default/hostnames:default" -m tcp --dport 80 -j DNAT --to-destination 10.240.115.247:48577 -``` - -您的 `Service` 上的每个端口应该有两个规则（本例中只有一个）- "KUBE-PORTALS-CONTAINER" 和 "KUBE-PORTALS-HOST"。如果您没有看到这些，请尝试将 `-V` 标志设置为 4 之后重新启动 `kube-proxy`，然后再次查看日志。 - -几乎没有人应该再使用 "userspace" 模式了，所以我们不会在这里花费更多的时间。 - -<!-- -#### Iptables - -```shell -u@node$ iptables-save | grep hostnames --A KUBE-SEP-57KPRZ3JQVENLNBR -s 10.244.3.6/32 -m comment --comment "default/hostnames:" -j MARK --set-xmark 0x00004000/0x00004000 --A KUBE-SEP-57KPRZ3JQVENLNBR -p tcp -m comment --comment "default/hostnames:" -m tcp -j DNAT --to-destination 10.244.3.6:9376 --A KUBE-SEP-WNBA2IHDGP2BOBGZ -s 10.244.1.7/32 -m comment --comment "default/hostnames:" -j MARK --set-xmark 0x00004000/0x00004000 --A KUBE-SEP-WNBA2IHDGP2BOBGZ -p tcp -m comment --comment "default/hostnames:" -m tcp -j DNAT --to-destination 10.244.1.7:9376 --A KUBE-SEP-X3P2623AGDH6CDF3 -s 10.244.2.3/32 -m comment --comment "default/hostnames:" -j MARK --set-xmark 0x00004000/0x00004000 --A KUBE-SEP-X3P2623AGDH6CDF3 -p tcp -m comment --comment "default/hostnames:" -m tcp -j DNAT --to-destination 10.244.2.3:9376 --A KUBE-SERVICES -d 10.0.1.175/32 -p tcp -m comment --comment "default/hostnames: cluster IP" -m tcp --dport 80 -j KUBE-SVC-NWV5X2332I4OT4T3 --A KUBE-SVC-NWV5X2332I4OT4T3 -m comment --comment "default/hostnames:" -m statistic --mode random --probability 0.33332999982 -j KUBE-SEP-WNBA2IHDGP2BOBGZ --A KUBE-SVC-NWV5X2332I4OT4T3 -m comment --comment "default/hostnames:" -m statistic --mode random --probability 0.50000000000 -j KUBE-SEP-X3P2623AGDH6CDF3 --A KUBE-SVC-NWV5X2332I4OT4T3 -m comment --comment "default/hostnames:" -j KUBE-SEP-57KPRZ3JQVENLNBR -``` - -There should be 1 rule in `KUBE-SERVICES`, 1 or 2 rules per endpoint in -`KUBE-SVC-(hash)` (depending on `SessionAffinity`), one `KUBE-SEP-(hash)` chain -per endpoint, and a few rules in each `KUBE-SEP-(hash)` chain. The exact rules -will vary based on your exact config (including node-ports and load-balancers). ---> -#### Iptables - -```shell -u@node$ iptables-save | grep hostnames --A KUBE-SEP-57KPRZ3JQVENLNBR -s 10.244.3.6/32 -m comment --comment "default/hostnames:" -j MARK --set-xmark 0x00004000/0x00004000 --A KUBE-SEP-57KPRZ3JQVENLNBR -p tcp -m comment --comment "default/hostnames:" -m tcp -j DNAT --to-destination 10.244.3.6:9376 --A KUBE-SEP-WNBA2IHDGP2BOBGZ -s 10.244.1.7/32 -m comment --comment "default/hostnames:" -j MARK --set-xmark 0x00004000/0x00004000 --A KUBE-SEP-WNBA2IHDGP2BOBGZ -p tcp -m comment --comment "default/hostnames:" -m tcp -j DNAT --to-destination 10.244.1.7:9376 --A KUBE-SEP-X3P2623AGDH6CDF3 -s 10.244.2.3/32 -m comment --comment "default/hostnames:" -j MARK --set-xmark 0x00004000/0x00004000 --A KUBE-SEP-X3P2623AGDH6CDF3 -p tcp -m comment --comment "default/hostnames:" -m tcp -j DNAT --to-destination 10.244.2.3:9376 --A KUBE-SERVICES -d 10.0.1.175/32 -p tcp -m comment --comment "default/hostnames: cluster IP" -m tcp --dport 80 -j KUBE-SVC-NWV5X2332I4OT4T3 --A KUBE-SVC-NWV5X2332I4OT4T3 -m comment --comment "default/hostnames:" -m statistic --mode random --probability 0.33332999982 -j KUBE-SEP-WNBA2IHDGP2BOBGZ --A KUBE-SVC-NWV5X2332I4OT4T3 -m comment --comment "default/hostnames:" -m statistic --mode random --probability 0.50000000000 -j KUBE-SEP-X3P2623AGDH6CDF3 --A KUBE-SVC-NWV5X2332I4OT4T3 -m comment --comment "default/hostnames:" -j KUBE-SEP-57KPRZ3JQVENLNBR -``` - -`KUBE-SERVICES` 中应该有 1 条规则，`KUBE-SVC-(hash)` 中每个端点有 1 或 2 条规则（取决于 `SessionAffinity`），每个端点中应有 1 条 `KUBE-SEP-(hash)` 链。准确的规则将根据您的确切配置（包括节点、端口组合以及负载均衡器设置）而有所不同。 - -<!-- -#### IPVS - -```shell -u@node$ ipvsadm -ln -Prot LocalAddress:Port Scheduler Flags - -> RemoteAddress:Port Forward Weight ActiveConn InActConn -... -TCP 10.0.1.175:80 rr - -> 10.244.0.5:9376 Masq 1 0 0 - -> 10.244.0.6:9376 Masq 1 0 0 - -> 10.244.0.7:9376 Masq 1 0 0 -... -``` - -IPVS proxy will create a virtual server for each service address(e.g. Cluster IP, External IP, NodePort IP, Load Balancer IP etc.) and some corresponding real servers for endpoints of the service, if any. In this example, service hostnames(`10.0.1.175:80`) has 3 endpoints(`10.244.0.5:9376`, `10.244.0.6:9376`, `10.244.0.7:9376`) and you'll get results similar to above. ---> -#### IPVS - -```shell -u@node$ ipvsadm -ln -Prot LocalAddress:Port Scheduler Flags - -> RemoteAddress:Port Forward Weight ActiveConn InActConn -... -TCP 10.0.1.175:80 rr - -> 10.244.0.5:9376 Masq 1 0 0 - -> 10.244.0.6:9376 Masq 1 0 0 - -> 10.244.0.7:9376 Masq 1 0 0 -... -``` - -IPVS 代理将为每个服务器地址（例如集群 IP、外部 IP、节点端口 IP、负载均衡 IP等）创建虚拟服务器，并为服务的端点创建一些相应的真实服务器（如果有）。在这个例子中，服务器主机名（`10.0.1.175:80`）有 3 个端点(`10.244.0.5:9376`, `10.244.0.6:9376`, `10.244.0.7:9376`)，你会得到类似上面的结果。 - - -<!-- ### Is kube-proxy proxying? -Assuming you do see the above rules, try again to access your `Service` by IP: +Assuming you do see one the above cases, try again to access your Service by +IP from one of your Nodes: +--> +对于 Service （本例中只有一个）的每个端口，应当有 2 条规则： 一个 "KUBE-PORTALS-CONTAINER" 和一个 "KUBE-PORTALS-HOST"。 + +几乎没有人应该再使用 "userspace" 模式，因此您在这里不会花更多的时间。 + +### kube-proxy 是否在运行? + +假设您确实遇到上述情况之一，请重试从节点上通过 IP 访问您的 Service ： ```shell -u@node$ curl 10.0.1.175:80 -hostnames-0uton +curl 10.0.1.175:80 +``` +```none +hostnames-632524106-bbpiw ``` +<!-- If this fails and you are using the userspace proxy, you can try accessing the proxy directly. If you are using the iptables proxy, skip this section. Look back at the `iptables-save` output above, and extract the -port number that `kube-proxy` is using for your `Service`. In the above +port number that `kube-proxy` is using for your Service. In the above examples it is "48577". Now connect to that: - -```shell -u@node$ curl localhost:48577 -hostnames-yp2kp -``` - -If this still fails, look at the `kube-proxy` logs for specific lines like: - -```shell -Setting endpoints for default/hostnames:default to [10.244.0.5:9376 10.244.0.6:9376 10.244.0.7:9376] -``` - -If you don't see those, try restarting `kube-proxy` with the `-V` flag set to 4, and -then look at the logs again. --> -### kube-proxy 在执行代理操作么？ +如果失败，并且您正在使用用户空间代理，则可以尝试直接访问代理。 如果您使用的是 iptables 代理，请跳过本节。 -假设您确实看到了上述规则，请再次尝试通过 IP 访问您的 `Service`： +回顾上面的 `iptables-save` 输出，并提取 `kube-proxy` 用于您的 Service 的端口号。在上面的例子中，它是 “48577”。现在试着连接它： ```shell -u@node$ curl 10.0.1.175:80 -hostnames-0uton +curl localhost:48577 ``` - -如果失败了，并且您正在使用 userspace 代理，您可以尝试直接访问代理。如果您使用的是 iptables 代理，请跳过本节。 - -回顾上面的 `iptables-save` 输出，并提取 `kube-proxy` 用于您的 `Service` 的端口号。在上面的例子中，它是 “48577”。现在连接到它： - -```shell -u@node$ curl localhost:48577 -hostnames-yp2kp +```none +hostnames-632524106-tlaok ``` -如果仍然失败，请查看 `kube-proxy` 日志中的特定行，如： - -```shell -Setting endpoints for default/hostnames:default to [10.244.0.5:9376 10.244.0.6:9376 10.244.0.7:9376] -``` - -如果您没有看到这些，请尝试将 `-V` 标志设置为 4 并重新启动 `kube-proxy`，然后再查看日志。 - <!-- -### A Pod cannot reach itself via Service IP +If this still fails, look at the `kube-proxy` logs for specific lines like: +--> +如果仍然失败，请查看 `kube-proxy` 日志中的特定行，如： + +```none +Setting endpoints for default/hostnames:default to [10.244.0.5:9376 10.244.0.6:9376 10.244.0.7:9376] +``` + +<!-- +If you don't see those, try restarting `kube-proxy` with the `-v` flag set to 4, and +then look at the logs again. + +### Edge case: A Pod fails to reach itself via the Service IP {#a-pod-fails-to-reach-itself-via-the-service-ip} + +This might sound unlikely, but it does happen and it is supposed to work. This can happen when the network is not properly configured for "hairpin" traffic, usually when `kube-proxy` is running in `iptables` mode and Pods are connected with bridge network. The `Kubelet` exposes a `hairpin-mode` -[flag](/docs/admin/kubelet/) that allows endpoints of a Service to loadbalance back to themselves -if they try to access their own Service VIP. The `hairpin-mode` flag must either be -set to `hairpin-veth` or `promiscuous-bridge`. +[flag](/docs/admin/kubelet/) that allows endpoints of a Service to loadbalance +back to themselves if they try to access their own Service VIP. The +`hairpin-mode` flag must either be set to `hairpin-veth` or +`promiscuous-bridge`. The common steps to trouble shoot this are as follows: * Confirm `hairpin-mode` is set to `hairpin-veth` or `promiscuous-bridge`. You should see something like the below. `hairpin-mode` is set to `promiscuous-bridge` in the following example. +--> +如果您没有看到这些，请尝试将 `-V` 标志设置为 4 并重新启动 `kube-proxy`，然后再查看日志。 + +### 边缘案例: 一个 Pod 无法通过 Service IP 连接到它本身{#a-pod-fails-to-reach-itself-via-the-service-ip}。 + +这听起来似乎不太可能，但是确实发生了，并且应该可行。 + +如果网络没有为“发夹模式”流量生成正确配置，通常当 `kube-proxy` 以 `iptables` 模式运行，并且 Pod 与桥接网络连接时，就会发生这种情况。`Kubelet`暴露了 `hairpin-mode`[标志](/docs/admin/kubelet/)，如果 Service 的 endpoint 尝试访问自己的 Service VIP，则该端点可以把流量负载均衡回来到它们自身。 +`hairpin-mode` 标志必须被设置为 `hairpin-veth` 或者`promiscuous-bridge`。 + +解决此问题的常见步骤如下： + +* 确认 `hairpin-mode` 被设置为 `hairpin-veth` 或 `promiscuous-bridge`. +您应该可以看到下面这样。本例中 `hairpin-mode` 被设置为 +`promiscuous-bridge` 。 ```shell -u@node$ ps auxw|grep kubelet +ps auxw | grep kubelet +``` +```none root 3392 1.1 0.8 186804 65208 ? Sl 00:51 11:11 /usr/local/bin/kubelet --enable-debugging-handlers=true --config=/etc/kubernetes/manifests --allow-privileged=True --v=4 --cluster-dns=10.0.0.10 --cluster-domain=cluster.local --configure-cbr0=true --cgroup-root=/ --system-cgroups=/system --hairpin-mode=promiscuous-bridge --runtime-cgroups=/docker-daemon --kubelet-cgroups=/kubelet --babysit-daemons=true --max-pods=110 --serialize-image-pulls=false --outofdisk-transition-frequency=0 - ``` +<!-- * Confirm the effective `hairpin-mode`. To do this, you'll have to look at kubelet log. Accessing the logs depends on your Node OS. On some OSes it is a file, such as /var/log/kubelet.log, while other OSes use `journalctl` @@ -1078,104 +941,83 @@ to access logs. Please be noted that the effective hairpin mode may not match `--hairpin-mode` flag due to compatibility. Check if there is any log lines with key word `hairpin` in kubelet.log. There should be log lines indicating the effective hairpin mode, like something below. +--> -```shell + +* 确认有效的 `hairpin-mode`。要做到这一点，您必须查看 kubelet 日志。访问日志取决于节点的操作系统。在一些操作系统上，它是一个文件，如 /var/log/kubelet.log，而其他操作系统则使用 `journalctl` 访问日志。请注意，由于兼容性，有效的 `hairpin-mode` 可能不匹配 `--hairpin-mode` 标志。在 kubelet.log 中检查是否有带有关键字 `hairpin` 的日志行。应该有日志行指示有效的 `hairpin-mode`，就像下面这样。 + +```none I0629 00:51:43.648698 3252 kubelet.go:380] Hairpin mode set to "promiscuous-bridge" ``` +<!-- * If the effective hairpin mode is `hairpin-veth`, ensure the `Kubelet` has the permission to operate in `/sys` on node. If everything works properly, you should see something like: - -```shell -for intf in /sys/devices/virtual/net/cbr0/brif/*; do cat $intf/hairpin_mode; done -1 -1 -1 -1 -``` - -* If the effective hairpin mode is `promiscuous-bridge`, ensure `Kubelet` -has the permission to manipulate linux bridge on node. If cbr0` bridge is -used and configured properly, you should see: - -```shell -u@node$ ifconfig cbr0 |grep PROMISC -UP BROADCAST RUNNING PROMISC MULTICAST MTU:1460 Metric:1 - -``` - -* Seek help if none of above works out. --> -### Pod 无法通过 Service IP 访问自己 - -如果网络没有为“发夹模式”流量生成正确配置，通常当 `kube-proxy` 以 `iptables` 模式运行，并且 Pod 与桥接网络连接时，就会发生这种情况。`Kubelet` 公开了一个 `hairpin-mode` 标志，如果 pod 试图访问它们自己的 Service VIP，就可以让 Service 的端点重新负载到他们自己身上。`hairpin-mode` 标志必须设置为 `hairpin-veth` 或者 `promiscuous-bridge`。 - -解决这一问题的常见步骤如下： - -* 确认 `hairpin-mode` 被设置为 `hairpin-veth` 或者 `promiscuous-bridge`。您应该看到下面这样的内容。在下面的示例中，`hairpin-mode` 被设置为 `promiscuous-bridge`。 - -```shell -u@node$ ps auxw|grep kubelet -root 3392 1.1 0.8 186804 65208 ? Sl 00:51 11:11 /usr/local/bin/kubelet --enable-debugging-handlers=true --config=/etc/kubernetes/manifests --allow-privileged=True --v=4 --cluster-dns=10.0.0.10 --cluster-domain=cluster.local --configure-cbr0=true --cgroup-root=/ --system-cgroups=/system --hairpin-mode=promiscuous-bridge --runtime-cgroups=/docker-daemon --kubelet-cgroups=/kubelet --babysit-daemons=true --max-pods=110 --serialize-image-pulls=false --outofdisk-transition-frequency=0 - -``` - -* 确认有效的 `hairpin-mode`。要做到这一点，您必须查看 kubelet 日志。访问日志取决于节点的操作系统。在一些操作系统上，它是一个文件，如 /var/log/kubelet.log，而其他操作系统则使用 `journalctl` 访问日志。请注意，由于兼容性，有效的 `hairpin-mode` 可能不匹配 `--hairpin-mode` 标志。在 kubelet.log 中检查是否有带有关键字 `hairpin` 的日志行。应该有日志行指示有效的 `hairpin-mode`，比如下面的内容。 -```shell -I0629 00:51:43.648698 3252 kubelet.go:380] Hairpin mode set to "promiscuous-bridge" -``` - -* 如果有效的发夹模式是 `hairpin-veth`，请确保 `Kubelet` 具有在节点上的 `/sys` 中操作的权限。如果一切正常工作，您应该看到如下内容： +* 如果有效的发卡模式是 `hairpin-veth`, 保证 `Kubelet` 有操作节点上 `/sys` 的权限。如果一切正常，您将会看到如下输出: ```shell for intf in /sys/devices/virtual/net/cbr0/brif/*; do cat $intf/hairpin_mode; done +``` +```none 1 1 1 1 ``` -* 如果有效的发夹模式是 `promiscuous-bridge`，则请确保 `Kubelet` 拥有在节点上操纵 Linux 网桥的权限。如果正确使用和配置了 cbr0 网桥，您应该看到： - -```shell -u@node$ ifconfig cbr0 |grep PROMISC -UP BROADCAST RUNNING PROMISC MULTICAST MTU:1460 Metric:1 - -``` - -* 如果上述任何一项都没有效果，请寻求帮助。 - <!-- +* If the effective hairpin mode is `promiscuous-bridge`, ensure `Kubelet` +has the permission to manipulate linux bridge on node. If `cbr0` bridge is +used and configured properly, you should see: +--> +* 如果有效的发卡模式是 `promiscuous-bridge`, 保证 `Kubelet` 有操作节点上 linux bridge 的权限。如果 `cbr0` 桥正在被使用且被正确设置，您将会看到如下输出: + +```shell +ifconfig cbr0 |grep PROMISC +``` +```none +UP BROADCAST RUNNING PROMISC MULTICAST MTU:1460 Metric:1 +``` + +<!-- +* Seek help if none of above works out. + ## Seek help -If you get this far, something very strange is happening. Your `Service` is -running, has `Endpoints`, and your `Pods` are actually serving. You have DNS -working, `iptables` rules installed, and `kube-proxy` does not seem to be -misbehaving. And yet your `Service` is not working. You should probably let -us know, so we can help investigate! +If you get this far, something very strange is happening. Your Service is +running, has Endpoints, and your Pods are actually serving. You have DNS +working, and `kube-proxy` does not seem to be misbehaving. And yet your +Service is not working. Please let us know what is going on, so we can help +investigate! Contact us on [Slack](/docs/troubleshooting/#slack) or [Forum](https://discuss.kubernetes.io) or [GitHub](https://github.com/kubernetes/kubernetes). + + +## {{% heading "whatsnext" %}} + + +Visit [troubleshooting document](/docs/troubleshooting/) for more information. --> +* 如果以上步骤都不能解决问题，请寻求帮助。 + ## 寻求帮助 -如果您走到这一步，那么就真的是奇怪的事情发生了。您的 `Service` 正在运行，有 `Endpoints`，您的 `Pods` 也确实在服务中。您的 DNS 正常，`iptables` 规则已经安装，`kube-proxy` 看起来也正常。然而 `Service` 不起作用。这种情况下，您应该让我们知道，这样我们可以帮助调查！ - -使用 [Slack](/docs/troubleshooting/#slack) 或者 [Forum](https://discuss.kubernetes.io) 或者 [GitHub](https://github.com/kubernetes/kubernetes) 联系我们。 +如果您走到这一步，那么就真的是奇怪的事情发生了。您的 Service 正在运行，有 Endpoint ，您的 Pods 也确实在服务中。您的 DNS 正常，`iptables` 规则已经安装，`kube-proxy` 看起来也正常。然而 Service 还是没有正常工作。这种情况下，请告诉我们，这样我们可以帮助调查！ +通过 +[Slack](/docs/troubleshooting/#slack) 或者 +[Forum](https://discuss.kubernetes.io) 或者 +[GitHub](https://github.com/kubernetes/kubernetes) +联系我们。 ## {{% heading "whatsnext" %}} -<!-- -Visit [troubleshooting document](/docs/troubleshooting/) for more information. ---> -访问[故障排查文档](/docs/troubleshooting/)获取更多信息。 - - - +访问 [故障排查文档](/docs/troubleshooting/) 获取更多信息。 diff --git a/content/zh/docs/tasks/extend-kubernetes/http-proxy-access-api.md b/content/zh/docs/tasks/extend-kubernetes/http-proxy-access-api.md index a186e78a44..32a782b5ac 100644 --- a/content/zh/docs/tasks/extend-kubernetes/http-proxy-access-api.md +++ b/content/zh/docs/tasks/extend-kubernetes/http-proxy-access-api.md @@ -31,7 +31,7 @@ This page shows how to use an HTTP proxy to access the Kubernetes API. * 如果您的集群中还没有任何应用，使用如下命令启动一个 Hello World 应用： ```shell -kubectl run node-hello --image=gcr.io/google-samples/node-hello:1.0 --port=8080 +kubectl create deployment node-hello --image=gcr.io/google-samples/node-hello:1.0 --port=8080 ``` diff --git a/content/zh/docs/tasks/extend-kubernetes/setup-extension-api-server.md b/content/zh/docs/tasks/extend-kubernetes/setup-extension-api-server.md index bd3c600296..dd162bdc15 100644 --- a/content/zh/docs/tasks/extend-kubernetes/setup-extension-api-server.md +++ b/content/zh/docs/tasks/extend-kubernetes/setup-extension-api-server.md @@ -78,7 +78,7 @@ Alternatively, you can use an existing 3rd party solution, such as [apiserver-bu 1. Create a Kubernetes cluster role binding from the service account in your namespace to the `system:auth-delegator` cluster role to delegate auth decisions to the Kubernetes core API server. 1. Create a Kubernetes role binding from the service account in your namespace to the `extension-apiserver-authentication-reader` role. This allows your extension api-server to access the `extension-apiserver-authentication` configmap. 1. Create a Kubernetes apiservice. The CA cert above should be base64 encoded, stripped of new lines and used as the spec.caBundle in the apiservice. This should not be namespaced. If using the [kube-aggregator API](https://github.com/kubernetes/kube-aggregator/), only pass in the PEM encoded CA bundle because the base 64 encoding is done for you. -1. Use kubectl to get your resource. It should return "No resources found." Which means that everything worked but you currently have no objects of that resource type created yet. +1. Use kubectl to get your resource. When run, kubectl should return "No resources found.". This message indicates that everything worked but you currently have no objects of that resource type created. --> 1. 确保启用了 APIService API（检查 `--runtime-config`）。默认应该是启用的，除非被特意关闭了。 1. 您可能需要制定一个 RBAC 规则，以允许您添加 APIService 对象，或让您的集群管理员创建一个。（由于 API 扩展会影响整个集群，因此不建议在实时集群中对 API 扩展进行测试/开发/调试） @@ -94,7 +94,7 @@ Alternatively, you can use an existing 3rd party solution, such as [apiserver-bu 1. 以您命令空间中的 service account 创建一个 Kubernetes 集群角色绑定，绑定到 `system:auth-delegator` 集群角色，以将 auth 决策委派给 Kubernetes 核心 API 服务器。 1. 以您命令空间中的 service account 创建一个 Kubernetes 集群角色绑定，绑定到 `extension-apiserver-authentication-reader` 角色。这将让您的扩展 api-server 能够访问 `extension-apiserver-authentication` configmap。 1. 创建一个 Kubernetes apiservice。上述的 CA 证书应该使用 base64 编码，剥离新行并用作 apiservice 中的 spec.caBundle。这不应该是命名空间化的。如果使用了 [kube-aggregator API](https://github.com/kubernetes/kube-aggregator/)，那么只需要传入 PEM 编码的 CA 绑定，因为 base 64 编码已经完成了。 -1. 使用 kubectl 来获得您的资源。它应该返回 "找不到资源"。这意味着一切正常，但您目前还没有创建该资源类型的对象。 +1. 使用 kubectl 来获得您的资源。它应该返回 "找不到资源"。此消息表示一切正常，但您目前还没有创建该资源类型的对象。 @@ -109,8 +109,3 @@ Alternatively, you can use an existing 3rd party solution, such as [apiserver-bu * 如果你还未配置，请 [配置聚合层](/docs/tasks/access-kubernetes-api/configure-aggregation-layer/) 并启用 apiserver 的相关参数。 * 高级概述，请参阅 [使用聚合层扩展 Kubernetes API](/docs/concepts/api-extension/apiserver-aggregation)。 * 了解如何 [使用 Custom Resource Definition 扩展 Kubernetes API](/docs/tasks/access-kubernetes-api/extend-api-custom-resource-definitions/)。 - - - - - diff --git a/content/zh/docs/tasks/federation/_index.md b/content/zh/docs/tasks/federation/_index.md deleted file mode 100755 index 41b5f58674..0000000000 --- a/content/zh/docs/tasks/federation/_index.md +++ /dev/null @@ -1,4 +0,0 @@ ---- -title: "联邦 - 在多个集群上运行一个应用" -weight: 120 ---- diff --git a/content/zh/docs/tasks/federation/administer-federation/_index.md b/content/zh/docs/tasks/federation/administer-federation/_index.md deleted file mode 100644 index 72d12f92fc..0000000000 --- a/content/zh/docs/tasks/federation/administer-federation/_index.md +++ /dev/null @@ -1,4 +0,0 @@ ---- -title: "管理联邦控制平面" -weight: 160 ---- diff --git a/content/zh/docs/tasks/federation/administer-federation/configmap.md b/content/zh/docs/tasks/federation/administer-federation/configmap.md deleted file mode 100644 index 0c2e619338..0000000000 --- a/content/zh/docs/tasks/federation/administer-federation/configmap.md +++ /dev/null @@ -1,148 +0,0 @@ ---- -title: 联邦 ConfigMap -content_type: task ---- -<!-- ---- -title: Federated ConfigMap -content_type: task ---- ---> - -<!-- overview --> - -{{< deprecationfilewarning >}} -{{< include "federation-deprecation-warning-note.md" >}} -{{< /deprecationfilewarning >}} -<!-- -This guide explains how to use ConfigMaps in a Federation control plane. - -Federated ConfigMaps are very similar to the traditional [Kubernetes -ConfigMaps](/docs/tasks/configure-pod-container/configure-pod-configmap/) and provide the same functionality. -Creating them in the federation control plane ensures that they are synchronized -across all the clusters in federation. ---> -本指南介绍如何在联邦控制平面中使用 ConfigMap。 - -联邦 ConfigMap 与传统 [Kubernetes -ConfigMap](/docs/tasks/configure-pod-container/configure-pod-configmap/) 非常相似且提供相同的功能。 -在联邦控制平面中创建它们可以确保它们在联邦的所有集群中同步。 - - - -## {{% heading "prerequisites" %}} - - -* {{< include "federated-task-tutorial-prereqs.md" >}} -<!-- -* You should also have a basic -[working knowledge of Kubernetes](/docs/tutorials/kubernetes-basics/) in -general and [ConfigMaps](/docs/tasks/configure-pod-container/configure-pod-configmap/) in particular. ---> -* 通常我们还期望您拥有基本的 [Kubernetes 应用知识](/docs/tutorials/kubernetes-basics/)， -特别是 [ConfigMap](/docs/tasks/configure-pod-container/configure-pod-configmap/) 相关的应用知识。 - - -<!-- steps --> - -<!-- -## Creating a Federated ConfigMap - -The API for Federated ConfigMap is 100% compatible with the -API for traditional Kubernetes ConfigMap. You can create a ConfigMap by sending -a request to the federation apiserver. - -You can do that using [kubectl](/docs/user-guide/kubectl/) by running: - -``` shell -kubectl --context=federation-cluster create -f myconfigmap.yaml -``` - -The `--context=federation-cluster` flag tells kubectl to submit the -request to the Federation apiserver instead of sending it to a Kubernetes -cluster. - -Once a Federated ConfigMap is created, the federation control plane will create -a matching ConfigMap in all underlying Kubernetes clusters. -You can verify this by checking each of the underlying clusters, for example: - -``` shell -kubectl --context=gce-asia-east1a get configmap myconfigmap -``` - -The above assumes that you have a context named 'gce-asia-east1a' -configured in your client for your cluster in that zone. - -These ConfigMaps in underlying clusters will match the Federated ConfigMap. ---> -## 创建联邦 ConfigMap - -联邦 ConfigMap 的 API 100% 兼容传统 Kubernetes ConfigMap 的 API。您可以通过向联邦 apiserver 发送请求来创建 ConfigMap。 -您可以通过使用 [kubectl](/docs/user-guide/kubectl/) 运行下面的指令来创建联邦 ConfigMap： - -``` shell -kubectl --context=federation-cluster create -f myconfigmap.yaml -``` - -`--context=federation-cluster` 参数告诉 kubectl 将请求提交到联邦 apiserver 而不是发送给某一个 Kubernetes 集群。 - -一旦联邦 ConfigMap 被创建，联邦控制平面就会在所有底层 Kubernetes 集群中创建匹配的 ConfigMap。 -您可以通过检查底层每个集群来对其进行验证，例如： - -``` shell -kubectl --context=gce-asia-east1a get configmap myconfigmap -``` - -上面的命令假定您在客户端中配置了一个叫做 ‘gce-asia-east1a’ 的上下文。 - -这些底层集群中的 ConfigMap 将与 联邦 ConfigMap 相匹配。 - -<!-- -## Updating a Federated ConfigMap - -You can update a Federated ConfigMap as you would update a Kubernetes -ConfigMap; however, for a Federated ConfigMap, you must send the request to -the federation apiserver instead of sending it to a specific Kubernetes cluster. -The federation control plane ensures that whenever the Federated ConfigMap is -updated, it updates the corresponding ConfigMaps in all underlying clusters to -match it. ---> -## 更新联邦 ConfigMap - -您可以像更新 Kubernetes ConfigMap 一样更新联邦 ConfigMap。 -但是对于联邦 ConfigMap，您必须发送请求到联邦 apiserver 而不是某个特定的 Kubernetes 集群。 -联邦控制平面会确保每当联邦 ConfigMap 更新时，它会更新所有底层集群中的 ConfigMap 来和更新后的内容保持一致。 - -<!-- -## Deleting a Federated ConfigMap - -You can delete a Federated ConfigMap as you would delete a Kubernetes -ConfigMap; however, for a Federated ConfigMap, you must send the request to -the federation apiserver instead of sending it to a specific Kubernetes cluster. - -For example, you can do that using kubectl by running: - -```shell -kubectl --context=federation-cluster delete configmap -``` ---> -## 删除联邦 ConfigMap - -您可以像删除 Kubernetes ConfigMap 一样删除联邦 ConfigMap。 -但是，对于联邦 ConfigMap，您必须发送请求到联邦 apiserver 而不是某个特定的 Kubernetes 集群。 -例如，您可以使用 kubectl 运行下面的命令来删除联邦 ConfigMap： - -```shell -kubectl --context=federation-cluster delete configmap -``` - -{{< note >}} -<!-- -Deleting a Federated ConfigMap does not delete the corresponding ConfigMaps from underlying clusters. You must delete the underlying ConfigMaps manually. ---> -要注意的是这时删除联邦 ConfigMap 并不会删除底层集群中对应的 ConfigMap。您必须自己手动删除底层集群中的 ConfigMap。 -{{< /note >}} - - - - diff --git a/content/zh/docs/tasks/federation/administer-federation/daemonset.md b/content/zh/docs/tasks/federation/administer-federation/daemonset.md deleted file mode 100644 index 88ed66d090..0000000000 --- a/content/zh/docs/tasks/federation/administer-federation/daemonset.md +++ /dev/null @@ -1,136 +0,0 @@ ---- -title: 联邦 DaemonSet -content_type: task ---- -<!-- ---- -title: Federated DaemonSet -content_type: task ---- ---> - -<!-- overview --> - -{{< deprecationfilewarning >}} -{{< include "federation-deprecation-warning-note.md" >}} -{{< /deprecationfilewarning >}} - -<!-- -This guide explains how to use DaemonSets in a federation control plane. - -DaemonSets in the federation control plane ("Federated Daemonsets" in -this guide) are very similar to the traditional Kubernetes -[DaemonSets](/docs/concepts/workloads/controllers/daemonset/) and provide the same functionality. -Creating them in the federation control plane ensures that they are synchronized -across all the clusters in federation. ---> -本指南说明了如何在联邦控制平面中使用 DaemonSet。 - -联邦控制平面中的 DaemonSet（在本指南中称为 “联邦 DaemonSet”）与传统的 Kubernetes [DaemonSet](/docs/concepts/workloads/controllers/daemonset/) 非常类似，并提供相同的功能。在联邦控制平面中创建联邦 DaemonSet 可以确保它们同步到联邦的所有集群中。 - - - -## {{% heading "prerequisites" %}} - - -* {{< include "federated-task-tutorial-prereqs.md" >}} -<!-- -* You should also have a basic -[working knowledge of Kubernetes](/docs/tutorials/kubernetes-basics/) in -general and [DaemonSets](/docs/concepts/workloads/controllers/daemonset/) in particular. ---> -* 你还应该具备基本的 [Kubernetes 应用知识](/docs/tutorials/kubernetes-basics/)，特别是 [DaemonSet](/docs/concepts/workloads/controllers/daemonset/) 相关的应用知识。 - - - -<!-- steps --> - -<!-- -## Creating a Federated Daemonset - -The API for Federated Daemonset is 100% compatible with the -API for traditional Kubernetes DaemonSet. You can create a DaemonSet by sending -a request to the federation apiserver. - -You can do that using [kubectl](/docs/user-guide/kubectl/) by running: - -``` shell -kubectl --context=federation-cluster create -f mydaemonset.yaml -``` - -The `--context=federation-cluster` flag tells kubectl to submit the -request to the Federation apiserver instead of sending it to a Kubernetes -cluster. - -Once a Federated Daemonset is created, the federation control plane will create -a matching DaemonSet in all underlying Kubernetes clusters. -You can verify this by checking each of the underlying clusters, for example: - -``` shell -kubectl --context=gce-asia-east1a get daemonset mydaemonset -``` - -The above assumes that you have a context named 'gce-asia-east1a' -configured in your client for your cluster in that zone. ---> -## 创建联邦 Daemonset - -联邦 Daemonset 的 API 和传统的 Kubernetes Daemonset API 是 100% 兼容的。您可以通过向联邦 apiserver 发送请求来创建一个 DaemonSet。 - -您可以通过使用 [kubectl](/docs/user-guide/kubectl/) 运行下面的指令来创建联邦 Daemonset： - -``` shell -kubectl --context=federation-cluster create -f mydaemonset.yaml -``` - -`--context=federation-cluster` 参数告诉 kubectl 发送请求到联邦 apiserver 而不是某个 Kubernetes 集群。 - -一旦联邦 Daemonset 被创建，联邦控制平面就会在所有底层 Kubernetes 集群中创建匹配的 Daemonset。您可以通过检查底层每个集群来对其进行验证，例如： - -``` shell -kubectl --context=gce-asia-east1a get daemonset mydaemonset -``` - -上面的命令假定您在客户端中配置了一个叫做 ‘gce-asia-east1a’ 的上下文。 - - -<!-- -## Updating a Federated Daemonset - -You can update a Federated Daemonset as you would update a Kubernetes -DaemonSet; however, for a Federated Daemonset, you must send the request to -the federation apiserver instead of sending it to a specific Kubernetes cluster. -The federation control plane ensures that whenever the Federated Daemonset is -updated, it updates the corresponding DaemonSets in all underlying clusters to -match it. ---> -## 更新联邦 Daemonset - -您可以像更新 Kubernetes Daemonset 一样更新联邦 Daemonset。但是，对于联邦 Daemonset，您必须发送请求到联邦 apiserver 而不是某个特定的 Kubernetes 集群。联邦控制平面会确保每当联邦 Daemonset 更新时，它会更新所有底层集群中的 Daemonset 来和更新后的内容保持一致。 - -<!-- -## Deleting a Federated Daemonset - -You can delete a Federated Daemonset as you would delete a Kubernetes -DaemonSet; however, for a Federated Daemonset, you must send the request to -the federation apiserver instead of sending it to a specific Kubernetes cluster. - -For example, you can do that using kubectl by running: - -```shell -kubectl --context=federation-cluster delete daemonset mydaemonset -``` ---> -## 删除联邦 Daemonset - -您可以像删除 Kubernetes Daemonset 一样删除联邦 Daemonset。但是，对于联邦 Daemonset，您必须发送请求到联邦 apiserver 而不是某个特定的 Kubernetes 集群。 - -例如，您可以使用 kubectl 运行下面的命令来删除联邦 Daemonset： - -```shell -kubectl --context=federation-cluster delete daemonset mydaemonset -``` - - - - diff --git a/content/zh/docs/tasks/federation/administer-federation/deployment.md b/content/zh/docs/tasks/federation/administer-federation/deployment.md deleted file mode 100644 index 1d4e53ffa4..0000000000 --- a/content/zh/docs/tasks/federation/administer-federation/deployment.md +++ /dev/null @@ -1,177 +0,0 @@ ---- -title: 联邦 Deployment -content_type: task ---- -<!-- ---- -title: Federated Deployment -content_type: task ---- ---> - -<!-- overview --> - -{{< deprecationfilewarning >}} -{{< include "federation-deprecation-warning-note.md" >}} -{{< /deprecationfilewarning >}} - -<!-- -This guide explains how to use Deployments in the Federation control plane. - -Deployments in the federation control plane (referred to as "Federated Deployments" in -this guide) are very similar to the traditional [Kubernetes -Deployment](/docs/concepts/workloads/controllers/deployment/) and provide the same functionality. -Creating them in the federation control plane ensures that the desired number of -replicas exist across the registered clusters. ---> -本指南说明了如何在联邦控制平面中使用 Deployment。 - -联邦控制平面中的 Deployment（在本指南中称为 “联邦 Deployment”）与传统的 [Kubernetes -Deployment](/docs/concepts/workloads/controllers/deployment/) 非常类似，并提供相同的功能。在联邦控制平面中创建联邦 Deployment 确保所需的副本数存在于注册的群集中。 - -{{< feature-state for_k8s_version="1.5" state="alpha" >}} - -<!-- -Some features -(such as full rollout compatibility) are still in development. ---> -一些特性（例如完整的 rollout 兼容性）仍在开发中。 - - -## {{% heading "prerequisites" %}} - - -* {{< include "federated-task-tutorial-prereqs.md" >}} -<!-- -* You should also have a basic -[working knowledge of Kubernetes](/docs/tutorials/kubernetes-basics/) in -general and [Deployments](/docs/concepts/workloads/controllers/deployment/) in particular. ---> -* 您还应当拥有基本的 [Kubernetes 应用知识](/docs/tutorials/kubernetes-basics/)，特别是在 [Deployments](/docs/concepts/workloads/controllers/deployment/) 方面。 - - - -<!-- steps --> -<!-- -## Creating a Federated Deployment - -The API for Federated Deployment is compatible with the -API for traditional Kubernetes Deployment. You can create a Deployment by sending -a request to the federation apiserver. - -You can do that using [kubectl](/docs/user-guide/kubectl/) by running: - -``` shell -kubectl --context=federation-cluster create -f mydeployment.yaml -``` - -The `--context=federation-cluster` flag tells kubectl to submit the -request to the Federation apiserver instead of sending it to a Kubernetes -cluster. - -Once a Federated Deployment is created, the federation control plane will create -a Deployment in all underlying Kubernetes clusters. -You can verify this by checking each of the underlying clusters, for example: - -``` shell -kubectl --context=gce-asia-east1a get deployment mydep -``` - -The above assumes that you have a context named 'gce-asia-east1a' -configured in your client for your cluster in that zone. - -These Deployments in underlying clusters will match the federation Deployment -_except_ in the number of replicas and revision-related annotations. -Federation control plane ensures that the -sum of replicas in each cluster combined matches the desired number of replicas in the -Federated Deployment. ---> -## 创建联邦 Deployment - -联邦 Deployment 的 API 和传统的 Kubernetes Deployment API 是兼容的。 您可以通过向联邦 apiserver 发送请求来创建一个 Deployment。 - -您可以通过使用 [kubectl](/docs/user-guide/kubectl/) 运行下面的指令： - -``` shell -kubectl --context=federation-cluster create -f mydeployment.yaml -``` - -`--context=federation-cluster` 参数告诉 kubectl 发送请求到联邦 apiserver 而不是某个 Kubernetes 集群。 - -一旦联邦 Deployment 被创建，联邦控制平面会在所有底层 Kubernetes 集群中创建一个 Deployment。 您可以通过检查底层每个集群来对其进行验证，例如： - -``` shell -kubectl --context=gce-asia-east1a get deployment mydep -``` - -上面的命令假定您在客户端中配置了一个叫做 ‘gce-asia-east1a’ 的上下文， - -底层集群中的这些 Deployment 会匹配联邦 Deployment 中副本数和修订版本相关注解_之外_的信息。 联邦控制平面确保所有集群中的副本总数与联邦 Deployment 中请求的副本数量匹配。 - -<!-- -### Spreading Replicas in Underlying Clusters - -By default, replicas are spread equally in all the underlying clusters. For example: -if you have 3 registered clusters and you create a Federated Deployment with -`spec.replicas = 9`, then each Deployment in the 3 clusters will have -`spec.replicas=3`. -To modify the number of replicas in each cluster, you can specify -[FederatedReplicaSetPreference](https://github.com/kubernetes/federation/blob/{{< param "githubbranch" >}}/apis/federation/types.go) -as an annotation with key `federation.kubernetes.io/deployment-preferences` -on Federated Deployment. ---> -### 在底层集群中分布副本 - -默认情况下，副本会被平均分布到所有的底层集群中。例如：如果您有 3 个注册的集群并且创建了一个副本数为 9(`spec.replicas = 9`) 的联邦 Deployment，那么这 3 个集群中的每个 Deployment 都将有 3 个副本 (`spec.replicas=3`)。 -为修改每个集群中的副本数，您可以在联邦 Deployment 中以注解的形式指定 [FederatedReplicaSetPreference](https://github.com/kubernetes/federation/blob/{{< param "githubbranch" >}}/apis/federation/types.go)，其中注解的键为 `federation.kubernetes.io/deployment-preferences`。 - - -<!-- -## Updating a Federated Deployment - -You can update a Federated Deployment as you would update a Kubernetes -Deployment; however, for a Federated Deployment, you must send the request to -the federation apiserver instead of sending it to a specific Kubernetes cluster. -The federation control plane ensures that whenever the Federated Deployment is -updated, it updates the corresponding Deployments in all underlying clusters to -match it. So if the rolling update strategy was chosen then the underlying -cluster will do the rolling update independently and `maxSurge` and `maxUnavailable` -will apply only to individual clusters. This behavior may change in the future. - -If your update includes a change in number of replicas, the federation -control plane will change the number of replicas in underlying clusters to -ensure that their sum remains equal to the number of desired replicas in -Federated Deployment. ---> -## 更新联邦 Deployment - -您可以像更新 Kubernetes Deployment 一样更新联邦 Deployment。但是，对于联邦 Deployment，您必须发送请求到联邦 apiserver 而不是某个特定的 Kubernetes 集群。联邦控制平面会确保每当联邦 Deployment 更新时，它会更新所有底层集群中相应的 Deployment 来和更新后的内容保持一致。 所以如果（在联邦 Deployment 中）选择了滚动更新，那么底层集群会独立地进行滚动更新，并且联邦 Deployment 中的 `maxSurge` 和 `maxUnavailable` 只会应用于独立的集群中。将来这种行为可能会改变。 - -如果您的更新包括副本数量的变化，联邦控制平面会改变底层集群中的副本数量，以确保它们的总数等于联邦 Deployment 中请求的数量。 - -<!-- -## Deleting a Federated Deployment - -You can delete a Federated Deployment as you would delete a Kubernetes -Deployment; however, for a Federated Deployment, you must send the request to -the federation apiserver instead of sending it to a specific Kubernetes cluster. - -For example, you can do that using kubectl by running: - -```shell -kubectl --context=federation-cluster delete deployment mydep -``` ---> -## 删除联邦 Deployment - -您可以像删除 Kubernetes Deployment 一样删除联邦 Deployment。但是，对于联邦 Deployment，您必须发送请求到联邦 apiserver 而不是某个特定的 Kubernetes 集群。 - -例如，您可以使用 kubectl 运行下面的命令来删除联邦 Deployment： - -```shell -kubectl --context=federation-cluster delete deployment mydep -``` - - - - diff --git a/content/zh/docs/tasks/federation/administer-federation/events.md b/content/zh/docs/tasks/federation/administer-federation/events.md deleted file mode 100644 index 56f0a644f6..0000000000 --- a/content/zh/docs/tasks/federation/administer-federation/events.md +++ /dev/null @@ -1,87 +0,0 @@ ---- -title: 联邦事件 -content_type: concept ---- - -<!-- ---- -title: Federated Events -content_type: concept ---- ---> - -<!-- overview --> - -{{< deprecationfilewarning >}} -{{< include "federation-deprecation-warning-note.md" >}} -{{< /deprecationfilewarning >}} - -<!-- -This guide explains how to use events in federation control plane to help in debugging. ---> -本指南介绍如何在联邦控制平面中使用事件来帮助调试。 - - - - -<!-- body --> - -<!-- -## Prerequisites ---> - -## 先决条件 - -<!-- -This guide assumes that you have a running Kubernetes Cluster -Federation installation. If not, then head over to the -[federation admin guide](/docs/concepts/cluster-administration/federation/) to learn how to -bring up a cluster federation (or have your cluster administrator do -this for you). Other tutorials, for example -[this one](https://github.com/kelseyhightower/kubernetes-cluster-federation) -by Kelsey Hightower, are also available to help you. ---> - -本指南假定您正在运行 Kubernetes 集群联邦安装。 -如果没有，请转到[联邦管理员指南](/docs/concepts/cluster-administration/federation/)，了解如何启动集群联邦（或让集群管理员为您执行此操作）。 -其他教程，例如[这个](https://github.com/kelseyhightower/kubernetes-cluster-federation)由 Kelsey Hightower，也可为您提供帮助。 - -<!-- -You should also have a basic -[working knowledge of Kubernetes](/docs/tutorials/kubernetes-basics/) in -general. ---> -你还应该具备 [kubernetes 基本工作知识](/docs/tutorials/kubernetes-basics/)。 - -<!-- -## View federation events ---> - -## 查看联邦事件 - -<!-- -Events in federation control plane (referred to as "federation events" in -this guide) are very similar to the traditional Kubernetes -Events providing the same functionality. -Federation Events are stored only in federation control plane and are not passed on to the underlying Kubernetes clusters. ---> -联邦控制平面中的事件（本指南中称为“联邦事件”）与提供相同功能的传统 Kubernetes 事件非常相似。 -联邦事件仅存储在联邦控制平面中，不会传递给基础 Kubernetes 集群。 - -<!-- -Federation controllers create events as they process API resources to surface to the -user, the state that they are in. -You can get all events from federation apiserver by running: ---> -联邦控制器在处理 API 资源时创建事件，以便向用户显示它们所处的状态。您可以通过运行以下命令从联邦 apiserver 获取所有事件： - -```shell -kubectl --context=federation-cluster get events -``` - -<!-- -The standard kubectl get, update, delete commands will all work. ---> -标准的 kubectl get，update，delete 命令都可以正常工作。 - - diff --git a/content/zh/docs/tasks/federation/administer-federation/job.md b/content/zh/docs/tasks/federation/administer-federation/job.md deleted file mode 100644 index 27983d7924..0000000000 --- a/content/zh/docs/tasks/federation/administer-federation/job.md +++ /dev/null @@ -1,191 +0,0 @@ ---- -title: 联邦 Job -content_type: task ---- - -<!-- ---- -title: Federated Jobs -content_type: task ---- ---> - -<!-- overview --> - -{{< deprecationfilewarning >}} -{{< include "federation-deprecation-warning-note.md" >}} -{{< /deprecationfilewarning >}} - -<!-- -This guide explains how to use jobs in the federation control plane. - -Jobs in the federation control plane (referred to as "federated jobs" in -this guide) are similar to the traditional [Kubernetes -jobs](/docs/concepts/workloads/controllers/job/), and provide the same functionality. -Creating jobs in the federation control plane ensures that the desired number of -parallelism and completions exist across the registered clusters. ---> -本指南解释了如何在联邦控制平面中使用 job。 - -联邦控制平面中的一次性任务（在本指南中称为“联邦一次性任务”）类似于传统的 [Kubernetes 一次性任务](/docs/concepts/workloads/controllers/job/)，并且提供相同的功能。 -在联邦控制平面中创建 job 可以确保在已注册的集群中存在所需的并行性和完成数。 - - - -## {{% heading "prerequisites" %}} - - -* {{< include "federated-task-tutorial-prereqs.md" >}} -* 你需要具备基本的 [Kubernetes 的工作知识](/docs/tutorials/kubernetes-basics/)，特别是 [job](/docs/concepts/workloads/controllers/jobs-run-to-completion/)。 - -<!-- -* You should also have a basic -[working knowledge of Kubernetes](/docs/tutorials/kubernetes-basics/) in -general and [jobs](/docs/concepts/workloads/controllers/jobs-run-to-completion/) in particular. ---> - - - -<!-- steps --> - -<!-- -## Creating a federated job ---> - -## 创建一个联邦 job - -<!-- -The API for federated jobs is fully compatible with the -API for traditional Kubernetes jobs. You can create a job by sending -a request to the federation apiserver. - -You can do that using [kubectl](/docs/user-guide/kubectl/) by running: ---> - -用于联邦 job 的 API 与用于传统 Kubernetes job 的 API 完全兼容。您可以通过向联邦 apiserver 发送请求来创建 job。 - -你可以使用 [kubectl](/docs/user-guide/kubectl/) 来运行： - -``` shell -kubectl --context=federation-cluster create -f myjob.yaml -``` - -<!-- -The `--context=federation-cluster` flag tells kubectl to submit the -request to the federation API server instead of sending it to a Kubernetes -cluster. ---> -`--context=federation-cluster` 参数告诉 kubectl 将请求提交到联邦 API 服务器，而不是发送到 Kubernetes 集群。 - -<!-- -Once a federated job is created, the federation control plane creates -a job in all underlying Kubernetes clusters. -You can verify this by checking each of the underlying clusters, for example: ---> -一旦创建了联邦 job，联邦控制平面将在所有底层 Kubernetes 集群中创建一个 job。 -你可以通过检查每个集群底层来验证这一点，例如： - -``` shell -kubectl --context=gce-asia-east1a get job myjob -``` - -<!-- -The previous example assumes that you have a context named `gce-asia-east1a` -configured in your client for your cluster in that zone. ---> -前面的示例假设你的客户端中为该区域中的集群配置了一个名为 `gce-asia-east1a` 的上下文。 - -<!-- -The jobs in the underlying clusters match the federated job -except in the number of parallelism and completions. The federation control plane ensures that the -sum of the parallelism and completions in each cluster matches the desired number of parallelism and completions in the -federated job. ---> -集群底层中的 job 与联邦 job 匹配，但并行性和完成数不匹配。 -联邦控制平面确保每个集群中的并行性和完成数之和与联合作业中所需的并行度和完成数匹配。 - -<!-- -### Spreading job tasks in underlying clusters ---> - -### 将 job 任务分散到集群底层中 - -<!-- -By default, parallelism and completions are spread equally in all underlying clusters. For example: -if you have 3 registered clusters and you create a federated job with -`spec.parallelism = 9` and `spec.completions = 18`, then each job in the 3 clusters has -`spec.parallelism = 3` and `spec.completions = 6`. -To modify the number of parallelism and completions in each cluster, you can specify -[ReplicaAllocationPreferences](https://github.com/kubernetes/federation/blob/{{< param "githubbranch" >}}/apis/federation/types.go) -as an annotation with key `federation.kubernetes.io/job-preferences` -on the federated job. ---> -默认情况下，并行性和完成数在所有底层集群中平均分布。例如： -如果你有 3 个已注册的集群，并且创建了一个联邦 job -`spec.parallelism = 9` 和 `spec.completions = 18`，那么 3 个集群中的每个 job 都有 `spec.parallelism = 3` 和 `spec.completions = 6`。 -要修改每个集群中的并行性和完成数，可以指定 [ReplicaAllocationPreferences](https://github.com/kubernetes/federation/blob/{{< param "githubbranch" >}}/apis/federation/types.go) -作为 `federation.kubernetes.io/job-preferences` 联邦 job 上的 key 的注释。 - -<!-- -## Updating a federated job ---> - -## 更新联邦 job - -<!-- -You can update a federated job as you would update a Kubernetes -job; however, for a federated job, you must send the request to -the federation API server instead of sending it to a specific Kubernetes cluster. -The federation control plane ensures that whenever the federated job is -updated, it updates the corresponding job in all underlying clusters to -match it. ---> -可以像更新 Kubernetes job 一样更新联邦 job；但是，对于联邦 job，必须将请求发送到联邦 API 服务器，不是发送到指定的 Kubernetes 集群。 -联邦控制平面确保无论何时更新联邦 job，它都会更新所有集群底层中的相应 job 以匹配它。 - -<!-- -If your update includes a change in number of parallelism and completions, the federation -control plane changes the number of parallelism and completions in underlying clusters to -ensure that their sum remains equal to the number of desired parallelism and completions in -federated job. ---> -如果您的更新包含并行性和完成数的更改，则联邦控制平面将更改集群底层中的并行性和完成数， -确保它们的总和仍然等于联邦 job 中所需的并行性和完成数。 - -<!-- -## Deleting a federated job ---> - -## 删除联邦 job - -<!-- -You can delete a federated job as you would delete a Kubernetes -job; however, for a federated job, you must send the request to -the federation API server instead of sending it to a specific Kubernetes cluster. ---> -可以删除联邦 job，就像删除 Kubernetes job 一样;但是，对于联邦 job，必须将请求发送到联邦 API 服务器，不是发送到指定的 Kubernetes 集群。 - -<!-- -For example, with kubectl: ---> -例如，使用 kubectl： - -```shell -kubectl --context=federation-cluster delete job myjob -``` - -{{< note >}} - -<!-- -Deleting a federated job will not delete the -corresponding jobs from underlying clusters. -You must delete the underlying jobs manually. ---> -删除联邦作业不会从基础集群中删除相应的 job。 -您必须手动删除基础 job。 - -{{< /note >}} - - - - diff --git a/content/zh/docs/tasks/federation/administer-federation/namespaces.md b/content/zh/docs/tasks/federation/administer-federation/namespaces.md deleted file mode 100644 index f5032b52f3..0000000000 --- a/content/zh/docs/tasks/federation/administer-federation/namespaces.md +++ /dev/null @@ -1,158 +0,0 @@ ---- -title: 联邦命名空间 -content_type: task ---- - -<!-- ---- -title: Federated Namespaces -content_type: task ---- ---> - -<!-- overview --> - -{{< deprecationfilewarning >}} -{{< include "federation-deprecation-warning-note.md" >}} -{{< /deprecationfilewarning >}} - -<!-- -This guide explains how to use Namespaces in Federation control plane. ---> -本指南介绍如何在联邦控制平面中使用命名空间。 - -<!-- -Namespaces in federation control plane (referred to as "federated Namespaces" in -this guide) are very similar to the traditional [Kubernetes -Namespaces](/docs/concepts/overview/working-with-objects/namespaces/) providing the same functionality. -Creating them in the federation control plane ensures that they are synchronized -across all the clusters in federation. ---> -联邦控制平面中的命名空间（本指南中称为“联邦命名空间”）与提供相同功能的传统 Kubernetes 命名空间非常相似。 -在联邦控制平面中创建它们可确保它们在联邦中的所有集群之间同步 - - - -## {{% heading "prerequisites" %}} - - -* {{< include "federated-task-tutorial-prereqs.md" >}} -* 您还需要具备基本的 [Kubernetes 工作知识](/docs/tutorials/Kubernetes-basics/)， -特别是[命名空间](/docs/concepts/overview/working-objects/Namespaces/)。 - -<!-- -You are also expected to have a basic -[working knowledge of Kubernetes](/docs/tutorials/kubernetes-basics/) in -general and [Namespaces](/docs/concepts/overview/working-with-objects/namespaces/) in particular. ---> - - - -<!-- steps --> - -<!-- -## Creating a Federated Namespace ---> - -## 创建联邦命名空间 - -<!-- -The API for Federated Namespaces is 100% compatible with the -API for traditional Kubernetes Namespaces. You can create a Namespace by sending -a request to the federation apiserver. ---> -联邦命名空间的 API 与传统 Kubernetes 命名空间的 API 100％ 兼容。您可以通过向联邦身份验证程序发送请求来创建命名空间。 - -<!-- -You can do that using kubectl by running: ---> -您可以通过运行以下命令使用 kubectl 执行此操作： - -``` shell -kubectl --context=federation-cluster create -f myns.yaml -``` - -<!-- -The `--context=federation-cluster` flag tells kubectl to submit the -request to the Federation apiserver instead of sending it to a Kubernetes -cluster. ---> -`--context=federation-cluster` 参数通知 kubectl 将请求提交给联邦 apiserver，而不是将其发送到 Kubernetes 集群。 - -<!-- -Once a federated Namespace is created, the federation control plane will create -a matching Namespace in all underlying Kubernetes clusters. -You can verify this by checking each of the underlying clusters, for example: ---> -创建联邦命名空间后，联邦控制平面将在所有基础 Kubernetes 集群中创建匹配的命名空间。您可以通过检查每个基础集群来验证这一点，例如： - -``` shell -kubectl --context=gce-asia-east1a get namespaces myns -``` - -<!-- -The above assumes that you have a context named 'gce-asia-east1a' -configured in your client for your cluster in that zone. The name and -spec of the underlying Namespace will match those of -the Federated Namespace that you created above. ---> -以上假设您在客户端中为该区域中的集群配置了名为 “gce-asia-east1a” 的上下文。 -基础命名空间的名称和规范将与您在上面创建的联邦命名空间的名称和规范相匹配。 - -<!-- -## Updating a Federated Namespace ---> - -## 更新联邦命名空间 - -<!-- -You can update a federated Namespace as you would update a Kubernetes -Namespace, just send the request to federation apiserver instead of sending it -to a specific Kubernetes cluster. -Federation control plane will ensure that whenever the federated Namespace is -updated, it updates the corresponding Namespaces in all underlying clusters to -match it. ---> -您可以像更新 Kubernetes 命名空间一样更新联邦命名空间，只需将请求发送到联邦身份验证程序，而不是将其发送到指定的 Kubernetes 集群。 -联邦控制平面将确保每当更新联邦命名空间时，它都会更新所有基础集群中的相应命名空间以与其匹配。 - -<!-- -## Deleting a Federated Namespace ---> - -## 删除联邦命名空间 - -<!-- -You can delete a federated Namespace as you would delete a Kubernetes -Namespace, just send the request to federation apiserver instead of sending it -to a specific Kubernetes cluster. ---> -你可以删除联邦命名空间，就像删除 Kubernetes 命名空间一样，只需将请求发送到联邦身份验证器，而不是发送到指定的 Kubernetes 群集。 - -<!-- -For example, you can do that using kubectl by running: ---> -例如，您可以通过运行以下命令使用 kubectl 执行此操作： - -```shell -kubectl --context=federation-cluster delete ns myns -``` - -<!-- -As in Kubernetes, deleting a federated Namespace will delete all resources in that -Namespace from the federation control plane. ---> -与在 Kubernetes 中一样，删除联邦命名空间将从联邦控制平面中删除该命名空间中的所有资源。 - -{{< note >}} - -<!-- -At this point, deleting a federated Namespace will not delete the corresponding Namespace, or resources in those Namespaces, from underlying clusters. Users must delete them manually. We intend to fix this in the future. ---> -此时，删除联邦命名空间，不会从底层集群中删除相应的命名空间或这些命名空间中的资源。用户必须手动删除它们。我们打算将来解决这个问题。 - -{{< /note >}} - - - - diff --git a/content/zh/docs/tasks/federation/administer-federation/replicaset.md b/content/zh/docs/tasks/federation/administer-federation/replicaset.md deleted file mode 100644 index af7ae0efe9..0000000000 --- a/content/zh/docs/tasks/federation/administer-federation/replicaset.md +++ /dev/null @@ -1,220 +0,0 @@ ---- -title: 联邦 ReplicaSet -content_type: task ---- -<!-- ---- -title: Federated ReplicaSets -content_type: task ---- ---> - -<!-- overview --> - -{{< deprecationfilewarning >}} -{{< include "federation-deprecation-warning-note.md" >}} -{{< /deprecationfilewarning >}} - -<!-- -This guide explains how to use ReplicaSets in the Federation control plane. - -ReplicaSets in the federation control plane (referred to as "federated ReplicaSets" in -this guide) are very similar to the traditional [Kubernetes -ReplicaSets](/docs/concepts/workloads/controllers/replicaset/), and provide the same functionality. -Creating them in the federation control plane ensures that the desired number of -replicas exist across the registered clusters. ---> -本指南阐述了如何在联邦控制平面中使用 ReplicaSet。 -在联邦控制平面中的 ReplicaSet (在本指南中称为”联邦 ReplicaSet”) 和传统的 [Kubernetes -ReplicaSet](/docs/concepts/workloads/controllers/replicaset/) 很相似，提供了一样的功能。在联邦控制平面中创建联邦 ReplicaSet 可以确保在联邦的所有集群中都有预期数量的副本。 - - -## {{% heading "prerequisites" %}} - - -* {{< include "federated-task-tutorial-prereqs.md" >}} -<!-- -* You should also have a basic -[working knowledge of Kubernetes](/docs/tutorials/kubernetes-basics/) in -general and [ReplicaSets](/docs/concepts/workloads/controllers/replicaset/) in particular. ---> -* 你还应该具备基本的 [Kubernetes 应用知识](/docs/tutorials/kubernetes-basics/)，特别是 [ReplicaSets](/docs/concepts/workloads/controllers/replicaset/) 相关的应用知识。 - - - -<!-- steps --> - -<!-- -## Creating a Federated ReplicaSet - -The API for Federated ReplicaSet is 100% compatible with the -API for traditional Kubernetes ReplicaSet. You can create a ReplicaSet by sending -a request to the federation apiserver. - -You can do that using [kubectl](/docs/user-guide/kubectl/) by running: - -``` shell -kubectl --context=federation-cluster create -f myrs.yaml -``` - -The `--context=federation-cluster` flag tells kubectl to submit the -request to the Federation apiserver instead of sending it to a Kubernetes -cluster. - -Once a federated ReplicaSet is created, the federation control plane will create -a ReplicaSet in all underlying Kubernetes clusters. -You can verify this by checking each of the underlying clusters, for example: - -``` shell -kubectl --context=gce-asia-east1a get rs myrs -``` - -The above assumes that you have a context named 'gce-asia-east1a' -configured in your client for your cluster in that zone. - -The ReplicaSets in the underlying clusters will match the federation ReplicaSet -except in the number of replicas. The federation control plane will ensure that the -sum of the replicas in each cluster match the desired number of replicas in the -federation ReplicaSet. ---> -## 创建联邦 ReplicaSet - -联邦 ReplicaSet 的 API 和传统的 Kubernetes ReplicaSet API 是 100% 兼容的。您可以通过请求联邦 apiserver 来创建联邦 ReplicaSet。 - -您可以通过使用 [kubectl](/docs/user-guide/kubectl/) 运行下面的指令来创建联邦 ReplicaSet： - -``` shell -kubectl --context=federation-cluster create -f myrs.yaml -``` - -`--context=federation-cluster` 参数告诉 kubectl 发送请求到联邦 apiserver 而不是某个 Kubernetes 集群。 - -一旦联邦 ReplicaSet 被创建了，联邦控制平面就会在所有底层 Kubernetes 集群中创建一个 ReplicaSet。您可以通过检查底层每个集群来对其进行验证，例如： - -``` shell -kubectl --context=gce-asia-east1a get rs myrs -``` - -上面的命令假定您在客户端中配置了一个叫做 ‘gce-asia-east1a’ 的上下文。 - -底层集群中的 ReplicaSet 的副本数将会和联邦 ReplicaSet 的副本数保持一致。联邦控制平面将确保联邦的所有集群都和联邦 ReplicaSet 有同样的副本数。 - -<!-- -### Spreading Replicas in Underlying Clusters - -By default, replicas are spread equally in all the underlying clusters. For example: -if you have 3 registered clusters and you create a federated ReplicaSet with -`spec.replicas = 9`, then each ReplicaSet in the 3 clusters will have -`spec.replicas=3`. -To modify the number of replicas in each cluster, you can add an annotation with -key `federation.kubernetes.io/replica-set-preferences` to the federated ReplicaSet. -The value of the annoation is a serialized JSON that contains fields shown in -the following example: - -``` -{ - "rebalance": true, - "clusters": { - "foo": { - "minReplicas": 10, - "maxReplicas": 50, - "weight": 100 - }, - "bar": { - "minReplicas": 10, - "maxReplicas": 100, - "weight": 200 - } - } -} -``` - -The `rebalance` boolean field specifies whether replicas already scheduled and running -may be moved in order to match current state to the specified preferences. -The `clusters` object field contains a map where users can specify the constraints -for replica placement across the clusters (`foo` and `bar` in the example). -For each cluster, you can specify the minimum number of replicas that should be -assigned to it (default is zero), the maximum number of replicas the cluster can -accept (default is unbounded) and a number expressing the relative weight of -preferences to place additional replicas to that cluster. ---> -### 底层集群中副本的分布 - -默认情况下，副本在所有底层集群中是均匀分布的。例如：如果您有 3 个注册的集群并且用 `spec.replicas = 9` 参数创建了一个联邦 ReplicaSet，然后在这 3 个集群中每个 ReplicaSet 的副本数会是 `spec.replicas=3`。 -如果要修改每个集群中的副本数，您可以在联邦 ReplicaSet 中使用 `federation.kubernetes.io/replica-set-preferences` 作为注解键值来修改联合副本集。 -注解的键值是序列化的 JSON，其中包含以下示例中显示的字段： - -``` -{ - "rebalance": true, - "clusters": { - "foo": { - "minReplicas": 10, - "maxReplicas": 50, - "weight": 100 - }, - "bar": { - "minReplicas": 10, - "maxReplicas": 100, - "weight": 200 - } - } -} -``` -`rebalance` 布尔字段指定是否可以移动已调度和正在运行的副本，以便将当前状态与指定的首选项相匹配。 -`clusters` 对象字段包含一个映射，用户可以在其中指定跨集群的副本放置的约束（示例中为 `foo` 和 `bar`）。 -对于每个集群，您可以指定应分配给它的最小副本数（默认值为零），集群可以接受的最大副本数（默认为无限制）以及表示要添加该群集的副本的首选项的相对权重的数字。 - -<!-- -## Updating a Federated ReplicaSet - -You can update a federated ReplicaSet as you would update a Kubernetes -ReplicaSet; however, for a federated ReplicaSet, you must send the request to -the federation apiserver instead of sending it to a specific Kubernetes cluster. -The Federation control plane ensures that whenever the federated ReplicaSet is -updated, it updates the corresponding ReplicaSet in all underlying clusters to -match it. -If your update includes a change in number of replicas, the federation -control plane will change the number of replicas in underlying clusters to -ensure that their sum remains equal to the number of desired replicas in -federated ReplicaSet. ---> -## 更新联邦 ReplicaSet - -您可以像更新 Kubernetes ReplicaSet 一样更新联邦 ReplicaSet。但是对于联邦 ReplicaSet，您必须发送请求到联邦 apiserver 而不是某个特定的 Kubernetes 集群。联邦控制平面会确保任何时候联邦 ReplicaSet 更新后，它会将对应的 ReplicaSet 更新到所有的底层集群中来和它保持一致。 - -如果您做了包含副本数量的更改，联邦控制平面将会更改底层集群中的副本数以确保它们的总数和联邦 ReplicaSet 期望的副本数保持一致。 - -<!-- -## Deleting a Federated ReplicaSet - -You can delete a federated ReplicaSet as you would delete a Kubernetes -ReplicaSet; however, for a federated ReplicaSet, you must send the request to -the federation apiserver instead of sending it to a specific Kubernetes cluster. - -For example, you can do that using kubectl by running: - -```shell -kubectl --context=federation-cluster delete rs myrs -``` ---> -## 删除联邦 ReplicaSet - -您可以像删除 Kubernetes ReplicaSet 一样删除联邦 ReplicaSet。但是对于联邦 ReplicaSet ，您必须发送请求到联邦 apiserver 而不是某个特定的 Kubernetes 集群。 - -例如，您可以使用 kubectl 运行下面的命令来删除联邦 ReplicaSet： - -```shell -kubectl --context=federation-cluster delete rs myrs -``` - -{{< note >}} -<!-- -At this point, deleting a federated ReplicaSet will not delete the corresponding ReplicaSets from underlying clusters. You must delete the underlying ReplicaSets manually. We intend to fix this in the future. ---> -要注意的是这时删除联邦 ReplicaSet 并不会删除底层集群中对应的 ReplicaSet。您必须自己手动删除底层集群中的 ReplicaSet。我们打算在将来修复这个问题。 -{{< /note >}} - - - - diff --git a/content/zh/docs/tasks/federation/administer-federation/secret.md b/content/zh/docs/tasks/federation/administer-federation/secret.md deleted file mode 100644 index 5b185ddb29..0000000000 --- a/content/zh/docs/tasks/federation/administer-federation/secret.md +++ /dev/null @@ -1,164 +0,0 @@ ---- -title: 联邦 Secret -content_type: concept ---- - -<!-- ---- -title: Federated Secrets -content_type: concept ---- ---> - -<!-- overview --> - -{{< deprecationfilewarning >}} -{{< include "federation-deprecation-warning-note.md" >}} -{{< /deprecationfilewarning >}} - -<!-- -This guide explains how to use secrets in Federation control plane. - -Secrets in federation control plane (referred to as "federated secrets" in -this guide) are very similar to the traditional [Kubernetes -Secrets](/docs/concepts/configuration/secret/) providing the same functionality. -Creating them in the federation control plane ensures that they are synchronized -across all the clusters in federation. ---> -本指南解释了如何在联邦控制平面中使用 secret。 - -联邦控制平面中的 Secret（在本指南中称为“联邦 secret”）与提供相同功能的传统 [Kubernetes Secret](/docs/concepts/configuration/secret/) 非常相似。 -在联邦控制平面中创建它们可以确保它们跨联邦中的所有集群同步。 - - - - -<!-- body --> - -<!-- -## Prerequisites ---> - -## 先决条件 - -<!-- -This guide assumes that you have a running Kubernetes Cluster -Federation installation. If not, then head over to the -[federation admin guide](/docs/admin/federation/) to learn how to -bring up a cluster federation (or have your cluster administrator do -this for you). Other tutorials, for example -[this one](https://github.com/kelseyhightower/kubernetes-cluster-federation) -by Kelsey Hightower, are also available to help you. ---> -本指南假设你有一个正在运行的 Kubernetes 集群联邦安装。 -如果没有，请访问[联邦管理指南](/docs/admin/federation/)，了解如何启动联邦集群（或者让集群管理员为你做这件事）。 -其他教程，例如[这里](https://github.com/kelseyhightower/kubernetes-cluster-federation) Kelsey Hightower，也可以帮助您。 - -<!-- -You should also have a basic -[working knowledge of Kubernetes](/docs/tutorials/kubernetes-basics/) in -general and [Secrets](/docs/concepts/configuration/secret/) in particular. ---> -你还应该具有一个基本的 [Kubernetes 工作知识](/docs/tutorials/kubernetes-basics/)， -特别是 [Secret](/docs/concepts/configuration/secret/)。 - -<!-- -## Creating a Federated Secret ---> - -## 创建联邦 Secret - -<!-- -The API for Federated Secret is 100% compatible with the -API for traditional Kubernetes Secret. You can create a secret by sending -a request to the federation apiserver. ---> -用于联邦 Secret 的 API 与用于传统的 Kubernetes Secret 的 API 100% 兼容。 -您可以通过向联邦 apiserver 发送请求来创建一个 Secret。 - -<!-- -You can do that using [kubectl](/docs/user-guide/kubectl/) by running: ---> -你可以使用 [kubectl](/docs/user-guide/kubectl/) 来运行： - -``` shell -kubectl --context=federation-cluster create -f mysecret.yaml -``` - -<!-- -The `--context=federation-cluster` flag tells kubectl to submit the -request to the Federation apiserver instead of sending it to a Kubernetes -cluster. ---> -`--context=federation-cluster` 参数通知 kubectl 将请求提交给联邦 apiserver，而不是将其发送到 Kubernetes 集群。 - -<!-- -Once a federated secret is created, the federation control plane will create -a matching secret in all underlying Kubernetes clusters. -You can verify this by checking each of the underlying clusters, for example: ---> -创建联邦命名空间后，联邦控制平面将在所有基础 Kubernetes 集群中创建匹配的命名空间。您可以通过检查每个基础集群来验证这一点，例如： - -``` shell -kubectl --context=gce-asia-east1a get secret mysecret -``` - -<!-- -The above assumes that you have a context named 'gce-asia-east1a' -configured in your client for your cluster in that zone. - -These secrets in underlying clusters will match the federated secret. ---> -以上假设您在客户端中为该区域中的集群配置了名为 “gce-asia-east1a” 的上下文。 -集群底层中的这些 secret 将与联邦 secret 匹配。 - -<!-- -## Updating a Federated Secret ---> - -## 更新联邦 Secret - -<!-- -You can update a federated secret as you would update a Kubernetes -secret; however, for a federated secret, you must send the request to -the federation apiserver instead of sending it to a specific Kubernetes cluster. -The Federation control plane ensures that whenever the federated secret is -updated, it updates the corresponding secrets in all underlying clusters to -match it. ---> -您可以像更新 Kubernetes secret 一样更新联邦 secret，但是，对于联邦 secret 必须将请求发送到联邦 apiserver， -而不是将其发送到指定的 Kubernetes 集群。联邦控制平面将确保每当更新联邦 secret 时，它都会更新所有基础集群中的相应 secret 以与其匹配。 - -<!-- -## Deleting a Federated Secret ---> - -## 删除联邦 Secret - -<!-- -You can delete a federated secret as you would delete a Kubernetes -secret; however, for a federated secret, you must send the request to -the federation apiserver instead of sending it to a specific Kubernetes cluster. ---> -你可以删除一个联邦 secret，就像删除一个 Kubernetes secret 一样；但是， -对于联邦 secret，必须将请求发送到联邦 apiserver，而不是发送到指定的 Kubernetes 集群。 - -<!-- -For example, you can do that using kubectl by running: ---> -例如，您可以通过运行以下命令使用 kubectl 执行此操作： - -```shell -kubectl --context=federation-cluster delete secret mysecret -``` - -{{< note >}} - -<!-- -At this point, deleting a federated secret will not delete the corresponding secrets from underlying clusters. You must delete the underlying secrets manually. We intend to fix this in the future. ---> -此时，删除联邦 secret 不会从集群底层中删除相应的 secret。你必须手动删除底层 secret。我们打算将来解决这个问题。 - -{{< /note >}} - - diff --git a/content/zh/docs/tasks/federation/federation-service-discovery.md b/content/zh/docs/tasks/federation/federation-service-discovery.md deleted file mode 100644 index b3237e0122..0000000000 --- a/content/zh/docs/tasks/federation/federation-service-discovery.md +++ /dev/null @@ -1,509 +0,0 @@ ---- -title: 使用联合服务来实现跨集群的服务发现 -content_type: task -weight: 140 ---- -<!-- --- -title: Cross-cluster Service Discovery using Federated Services -reviewers: -- bprashanth -- quinton-hoole -content_type: task -weight: 140 ---- --> - -<!-- overview --> - -{{< deprecationfilewarning >}} -{{< include "federation-deprecation-warning-note.md" >}} -{{< /deprecationfilewarning >}} - -<!-- This guide explains how to use Kubernetes Federated Services to deploy -a common Service across multiple Kubernetes clusters. This makes it -easy to achieve cross-cluster service discovery and availability zone -fault tolerance for your Kubernetes applications. --> -本指南说明了如何使用 Kubernetes 联合服务跨多个 Kubernetes 集群部署通用服务。这样可以轻松实现 Kubernetes 应用程序的跨集群服务发现和可用区容错。 - - -<!-- Federated Services are created in much that same way as traditional -[Kubernetes Services](/docs/concepts/services-networking/service/) by making an API -call which specifies the desired properties of your service. In the -case of Federated Services, this API call is directed to the -Federation API endpoint, rather than a Kubernetes cluster API -endpoint. The API for Federated Services is 100% compatible with the -API for traditional Kubernetes Services. --> -联合服务的创建与传统服务几乎相同 [Kubernetes Services](/docs/concepts/services-networking/service/) 即通过 API 调用来指定所需的服务属性。对于联合服务，此 API 调用定向到联合身份验证 API 接入点，而不是 Kubernetes 集群 API 接入点。联合服务的 API 与传统 Kubernetes 服务的 API 是 100% 兼容的。 - -<!-- Once created, the Federated Service automatically: --> -创建后，联合服务会自动: - -<!-- 1. Creates matching Kubernetes Services in every cluster underlying your Cluster Federation, -2. Monitors the health of those service "shards" (and the clusters in which they reside), and -3. Manages a set of DNS records in a public DNS provider (like Google Cloud DNS, or AWS Route 53), thus ensuring that clients -of your federated service can seamlessly locate an appropriate healthy service endpoint at all times, even in the event of cluster, -availability zone or regional outages. --> -1. 在基础集群联合的每个集群中创建匹配的 Kubernetes 服务, -2. 监视那些服务 "分片"(及其驻留的集群)的运行状况,以及 -3. 在公共 DNS 提供商(例如 Google Cloud DNS 或 AWS Route 53)中管理一组 DNS 记录,即使在集群可用区域中断的情况下，也能确保您联合服务的客户端始终可以无缝地定位合适的健康服务接入点。 - -<!-- Clients inside your federated Kubernetes clusters (that is Pods) will -automatically find the local shard of the Federated Service in their -cluster if it exists and is healthy, or the closest healthy shard in a -different cluster if it does not. --> -如果存在健康的分片，联合 Kubernetes 集群(即 Pods )中的客户端将自动在其中找到联合服务的本地分片集群或者集群中最接近的健康分片;如果不存在，则使用最接近的其他集群的健康分片。 - - - -{{< toc >}} - -## {{% heading "prerequisites" %}} - - -{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}} - - - -<!-- steps --> - -<!-- ## Prerequisites --> -## 前提 - -<!-- This guide assumes that you have a running Kubernetes Cluster -Federation installation. If not, then head over to the -[federation admin guide](/docs/admin/federation/) to learn how to -bring up a cluster federation (or have your cluster administrator do -this for you). Other tutorials, for example -[this one](https://github.com/kelseyhightower/kubernetes-cluster-federation) -by Kelsey Hightower, are also available to help you. --> -本指南假设您已经安装 Kubernetes 联合集群。如果没有，则访问 [联合集群管理指南](/docs/admin/federation/)了解如何建立联合集群(或让您的集群管理员为您执行此操作)。其他教程，例如 Kelsey Hightower 编写的 [案例](https://github.com/kelseyhightower/kubernetes-cluster-federation)或许有用。 - -<!-- You should also have a basic -[working knowledge of Kubernetes](/docs/tutorials/kubernetes-basics/) in -general, and [Services](/docs/concepts/services-networking/service/) in particular. --> -一般而言，您应该还有基本的 [Kubernetes 工作常识](/docs/tutorials/kubernetes-basics/)，特别是 [Services](/docs/concepts/services-networking/service/)。 - -<!-- ## Hybrid cloud capabilities --> -## 混合云功能 - -<!-- Federations of Kubernetes Clusters can include clusters running in -different cloud providers (such as Google Cloud or AWS), and on-premises -(such as on OpenStack). Simply create all of the clusters that you -require, in the appropriate cloud providers and/or locations, and -register each cluster's API endpoint and credentials with your -Federation API Server (See the -[federation admin guide](/docs/admin/federation/) for details). --> -Kubernetes 联合集群需要可以在不同的云提供商(例如 Google Cloud 或 AWS)和本地(例如 OpenStack)环境中运行。只需在合适的云提供商创建所需的所有集群，向您的联合身份验证 API 服务器注册每个集群的 API 接入点和凭据(有关详细信息，请参见 [联合管理指南](/docs/admin/federation/))。 - -<!-- Thereafter, your applications and services can span different clusters -and cloud providers as described in more detail below. --> -此后，您的应用程序和服务可以跨越不同的集群和云提供商，如下所述。 - -<!-- ## Creating a federated service --> -## 创建联合服务 - -<!-- This is done in the usual way, for example: --> -常见方式创建，例如: - -``` shell -kubectl --context=federation-cluster create -f services/nginx.yaml -``` - -<!-- The '--context=federation-cluster' flag tells kubectl to submit the -request to the Federation API endpoint, with the appropriate -credentials. If you have not yet configured such a context, visit the -[federation admin guide](/docs/admin/federation/) or one of the -[administration tutorials](https://github.com/kelseyhightower/kubernetes-cluster-federation) -to find out how to do so. --> -'--context=federation-cluster' 标志通知 kubectl 使用合适的凭据将请求提交到联合 API 接入点。如果您尚未配置此类上下文，请访问 [联合管理指南](/docs/admin/federation/)或者 [管理教程](https://github.com/kelseyhightower/kubernetes-cluster-federation)找出解决方案。 - -<!-- As described above, the Federated Service will automatically create -and maintain matching Kubernetes services in all of the clusters -underlying your federation. --> -如上所述，联合服务将自动创建并在所有集群中维护匹配的 Kubernetes 服务以支持联合。 - -<!-- You can verify this by checking in each of the underlying clusters, for example: --> -您可以通过核对每个基础集群的信息来验证这一点, 例如: - -``` shell -kubectl --context=gce-asia-east1a get services nginx -NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE -nginx ClusterIP 10.63.250.98 104.199.136.89 80/TCP 9m -``` - -<!-- The above assumes that you have a context named 'gce-asia-east1a' -configured in your client for your cluster in that zone. The name and -namespace of the underlying services will automatically match those of -the Federated Service that you created above (and if you happen to -have had services of the same name and namespace already existing in -any of those clusters, they will be automatically adopted by the -Federation and updated to conform with the specification of your -Federated Service - either way, the end result will be the same). --> -以上假设您有一个名为 'gce-asia-east1a' 上下文在客户端中为该区域中的集群配置。基础服务的名称和命名空间将自动与您在上面创建的联合服务匹配(如果服务的名称和命名空间与集群中任意一个服务器的名称和命名空间相同，它们将被联合并更新为符合您的规范联合服务 - 无论哪种方式，最终结果都是相同的)。 - -<!-- The status of your Federated Service will automatically reflect the -real-time status of the underlying Kubernetes services, for example: --> -联合服务的状态将自动反映基础 Kubernetes 服务的实时状态，例如: - -``` shell -kubectl --context=federation-cluster describe services nginx -``` -``` -Name: nginx -Namespace: default -Labels: run=nginx -Annotations: <none> -Selector: run=nginx -Type: LoadBalancer -IP: 10.63.250.98 -LoadBalancer Ingress: 104.197.246.190, 130.211.57.243, 104.196.14.231, 104.199.136.89, ... -Port: http 80/TCP -Endpoints: <none> -Session Affinity: None -Events: <none> -``` - -<!-- {{< note >}} -The 'LoadBalancer Ingress' addresses of your Federated Service -correspond with the 'LoadBalancer Ingress' addresses of all of the -underlying Kubernetes services (once these have been allocated - this -may take a few seconds). For inter-cluster and inter-cloud-provider -networking between service shards to work correctly, your services -need to have an externally visible IP address. [Service Type: -Loadbalancer](/docs/concepts/services-networking/service/#loadbalancer) -is typically used for this, although other options -(for example [External IPs](/docs/concepts/services-networking/service/#external-ips)) exist. -{{< /note >}} --> -{{< note >}} -联合服务的 'LoadBalancer Ingress' 地址与所有基础 Kubernetes 服务的 'LoadBalancer Ingress' 地址相对应(一旦分配了这些地址，这可能需要几秒钟)。为了使服务分片之间的集群和云提供商之间的网络正常工作，您的服务需要具有一个外部可见的 IP 地址。[Service Type:Loadbalancer](/docs/concepts/services-networking/service/#loadbalancer)。尽管存在其他选项(例如 [外部 IP](/docs/concepts/services-networking/service/#external-ips)),但通常会使用 [Service 类型:Loadbalancer](/docs/concepts/services-networking/service/#loadbalancer)。 -{{< /note >}} - -<!-- Note also that we have not yet provisioned any backend Pods to receive -the network traffic directed to these addresses (that is 'Service -Endpoints'), so the Federated Service does not yet consider these to -be healthy service shards, and has accordingly not yet added their -addresses to the DNS records for this Federated Service (more on this -aspect later). --> -还要注意，我们尚未设置任何后端 Pod 来接收定向到这些地址的网络流量(即 'Service Endpoints')，因此联合服务尚未将它们视为健康的服务分片，并且尚未将其地址添加到联合服务的 DNS 记录中(稍后在此方面进行介绍)。 - -<!-- ## Adding backend pods --> -## 添加后端 pods - -<!-- To render the underlying service shards healthy, we need to add -backend Pods behind them. This is currently done directly against the -API endpoints of the underlying clusters (although in future the -Federation server will be able to do all this for you with a single -command, to save you the trouble). For example, to create backend Pods -in 13 underlying clusters: --> -为了使基础服务分片健康，我们需要在它们后面添加后端 Pod。当前，这是直接针对基础集群 API 接入点完成的(尽管将来，联合服务将能够通过单个命令为您完成所有这些操作，从而省去了麻烦)。例如，在13个基础集群中创建后端 Pod: - -``` shell -for CLUSTER in asia-east1-c asia-east1-a asia-east1-b \ - europe-west1-d europe-west1-c europe-west1-b \ - us-central1-f us-central1-a us-central1-b us-central1-c \ - us-east1-d us-east1-c us-east1-b -do - kubectl --context=$CLUSTER run nginx --image=nginx:1.11.1-alpine --port=80 -done -``` - -<!-- Note that `kubectl run` automatically adds the `run=nginx` labels required to associate the backend pods with their services. --> -注意，`kubectl run` 会自动添加 `run=nginx` 标签，这是将后端 pod 与其服务关联起来所必需的。 - -<!-- ## Verifying public DNS records --> -## 验证公共 DNS 记录 - -<!-- Once the above Pods have successfully started and have begun listening -for connections, Kubernetes will report them as healthy endpoints of -the service in that cluster (through automatic health checks). The Cluster -Federation will in turn consider each of these -service 'shards' to be healthy, and place them in serving by -automatically configuring corresponding public DNS records. You can -use your preferred interface to your configured DNS provider to verify -this. For example, if your Federation is configured to use Google -Cloud DNS, and a managed DNS domain 'example.com': --> -一旦上述 Pod 成功启动并开始侦听连接，Kubernetes 就会将它们报告为该集群中服务的正常接入点(通过自动运行状况检查)。反过来，联合集群会将这些服务 '分片' 中的每一个视为健康，并通过自动配置相应的公共 DNS 记录将其置于服务中。您可以使用首选接口访问已配置的 DNS 提供程序来进行验证。例如，如果您的联邦配置为使用 Google Cloud DNS 和托管 DNS 域名 'example.com'。 - -``` shell -gcloud dns managed-zones describe example-dot-com -``` -``` -creationTime: '2016-06-26T18:18:39.229Z' -description: Example domain for Kubernetes Cluster Federation -dnsName: example.com. -id: '3229332181334243121' -kind: dns#managedZone -name: example-dot-com -nameServers: -- ns-cloud-a1.googledomains.com. -- ns-cloud-a2.googledomains.com. -- ns-cloud-a3.googledomains.com. -- ns-cloud-a4.googledomains.com. -``` - -```shell -gcloud dns record-sets list --zone example-dot-com -``` -``` -NAME TYPE TTL DATA -example.com. NS 21600 ns-cloud-e1.googledomains.com., ns-cloud-e2.googledomains.com. -example.com. OA 21600 ns-cloud-e1.googledomains.com. cloud-dns-hostmaster.google.com. 1 21600 3600 1209600 300 -nginx.mynamespace.myfederation.svc.example.com. A 180 104.197.246.190, 130.211.57.243, 104.196.14.231, 104.199.136.89,... -nginx.mynamespace.myfederation.svc.us-central1-a.example.com. A 180 104.197.247.191 -nginx.mynamespace.myfederation.svc.us-central1-b.example.com. A 180 104.197.244.180 -nginx.mynamespace.myfederation.svc.us-central1-c.example.com. A 180 104.197.245.170 -nginx.mynamespace.myfederation.svc.us-central1-f.example.com. CNAME 180 nginx.mynamespace.myfederation.svc.us-central1.example.com. -nginx.mynamespace.myfederation.svc.us-central1.example.com. A 180 104.197.247.191, 104.197.244.180, 104.197.245.170 -nginx.mynamespace.myfederation.svc.asia-east1-a.example.com. A 180 130.211.57.243 -nginx.mynamespace.myfederation.svc.asia-east1-b.example.com. CNAME 180 nginx.mynamespace.myfederation.svc.asia-east1.example.com. -nginx.mynamespace.myfederation.svc.asia-east1-c.example.com. A 180 130.211.56.221 -nginx.mynamespace.myfederation.svc.asia-east1.example.com. A 180 130.211.57.243, 130.211.56.221 -nginx.mynamespace.myfederation.svc.europe-west1.example.com. CNAME 180 nginx.mynamespace.myfederation.svc.example.com. -nginx.mynamespace.myfederation.svc.europe-west1-d.example.com. CNAME 180 nginx.mynamespace.myfederation.svc.europe-west1.example.com. -... etc. -``` - -<!-- {{< note >}} -If your Federation is configured to use AWS Route53, you can use one of the equivalent AWS tools, for example: - -``` shell -aws route53 list-hosted-zones -``` -and - -``` shell -aws route53 list-resource-record-sets --hosted-zone-id Z3ECL0L9QLOVBX -``` -{{< /note >}} --> -{{< note >}} -如果您的联邦配置为使用 AWS Route53，则可以使用类似的 AWS 工具，例如: - -``` shell -aws route53 list-hosted-zones -``` -和 - -``` shell -aws route53 list-resource-record-sets --hosted-zone-id Z3ECL0L9QLOVBX -``` -{{< /note >}} - -<!-- Whatever DNS provider you use, any DNS query tool (for example 'dig' -or 'nslookup') will of course also allow you to see the records -created by the Federation for you. Note that you should either point -these tools directly at your DNS provider (such as `dig -@ns-cloud-e1.googledomains.com...`) or expect delays in the order of -your configured TTL (180 seconds, by default) before seeing updates, -due to caching by intermediate DNS servers. --> -无论使用哪种 DNS 提供商，任何 DNS 查询工具(例如 'dig' 或者 'nslookup')都将允许您查看联邦会为您创建的记录。请注意，您应该将这些工具直接指向您的 DNS 提供商(例如 `dig @ ns-cloud-e1.googledomains.com ...`),或者由于中间 DNS 服务器进行了缓存，因此在看到更新之前，预计延迟会按照配置的 TTL 顺序(默认为 180 秒)进行。 - -<!-- ### Some notes about the above example --> -### 有关上述示例的一些注意事项 - -<!-- 1. Notice that there is a normal ('A') record for each service shard that has at least one healthy backend endpoint. For example, in us-central1-a, 104.197.247.191 is the external IP address of the service shard in that zone, and in asia-east1-a the address is 130.211.56.221. -2. Similarly, there are regional 'A' records which include all healthy shards in that region. For example, 'us-central1'. These regional records are useful for clients which do not have a particular zone preference, and as a building block for the automated locality and failover mechanism described below. -3. For zones where there are currently no healthy backend endpoints, a CNAME ('Canonical Name') record is used to alias (automatically redirect) those queries to the next closest healthy zone. In the example, the service shard in us-central1-f currently has no healthy backend endpoints (that is Pods), so a CNAME record has been created to automatically redirect queries to other shards in that region (us-central1 in this case). -4. Similarly, if no healthy shards exist in the enclosing region, the search progresses further afield. In the europe-west1-d availability zone, there are no healthy backends, so queries are redirected to the broader europe-west1 region (which also has no healthy backends), and onward to the global set of healthy addresses (' nginx.mynamespace.myfederation.svc.example.com.'). --> -1. 请注意，每个具有至少一个正常后端端点的服务分片都有一条正常('A')记录。例如，在 us-central1-a 中，104.197.247.191 是该区域中服务分片的外部 IP 地址，在 asia-east1-a 中，该地址是 130.211.56.221。 -2. 同样，也有区域 'A' 记录，其中包括该区域中所有健康的分片。例如，'us-central1'。这些区域记录对于没有特定区域首选项的客户很有用，并且作为下文所述的自动位置和故障转移机制的基础。 -3. 对于当前没有健康后端终结点的区域，将使用 CNAME ('Canonical Name') 记录将这些查询别名(自动重定向)到下一个最接近的健康区域。在此示例中，us-central1-f 中的服务分片当前没有健康的后端端点(即Pods)，因此已创建 CNAME 记录来自动将查询重定向到该区域中的其他分片(在本例中为 us-central1)。 -4. 类似地，如果封闭区域中不存在健康分片，则搜索将进一步进行。在 europe-west1-d 可用性区域中,没有健康的后端,因此查询将重定向到更广阔的 Europe-west1 区域(也没有健康的后端),然后再重定向到全局的健康地址集('nginx.mynamespace.myfederation.svc.example.com.')。 - -<!-- The above set of DNS records is automatically kept in sync with the -current state of health of all service shards globally by the -Federated Service system. DNS resolver libraries (which are invoked by -all clients) automatically traverse the hierarchy of 'CNAME' and 'A' -records to return the correct set of healthy IP addresses. Clients can -then select any one of the returned addresses to initiate a network -connection (and fail over automatically to one of the other equivalent -addresses if required). --> -上面的 DNS 记录集由联邦服务系统自动与全球所有服务分片的当前健康状况保持同步。DNS 解析库(由所有客户端调用)自动遍历 'CNAME' 与 'A' 记录的层次结构，以返回正确健康的 IP 地址集。然后，客户端可以选择任何返回的地址来启动网络连接(并根据需要自动故障转移到其他等效地址之一)。 - -<!-- ## Discovering a federated service --> -## 发现联合服务 - -<!-- ### From pods inside your federated clusters --> -### 从联合集群内的 Pods 来发现 - -<!-- By default, Kubernetes clusters come pre-configured with a -cluster-local DNS server ('KubeDNS'), as well as an intelligently -constructed DNS search path which together ensure that DNS queries -like "myservice", "myservice.mynamespace", -"bobsservice.othernamespace" etc issued by your software running -inside Pods are automatically expanded and resolved correctly to the -appropriate service IP of services running in the local cluster. --> -默认情况下，Kubernetes 集群预先配置了本地集群 DNS 服务器('KubeDNS')以及智能构建的 DNS 搜索路径，这些路径共同确保由 Pods 内部运行软件发出的 DNS 查询如 "myservice", "myservice.mynamespace","bobsservice.othernamespace" 等，会自动扩展并正确解析为本地集群运行服务的相应服务 IP。 - -<!-- With the introduction of Federated Services and Cross-Cluster Service -Discovery, this concept is extended to cover Kubernetes services -running in any other cluster across your Cluster Federation, globally. -To take advantage of this extended range, you use a slightly different -DNS name of the form ```"<servicename>.<namespace>.<federationname>"``` -to resolve Federated Services. For example, you might use -`myservice.mynamespace.myfederation`. Using a different DNS name also -avoids having your existing applications accidentally traversing -cross-zone or cross-region networks and you incurring perhaps unwanted -network charges or latency, without you explicitly opting in to this -behavior. --> -随着联合服务和跨集群服务发现的引入，该概念已扩展到涵盖在全球集群联盟中任何其他集群中运行的 Kubernetes 服务。要利用此扩展范围，您可以使用形式稍有不同的 DNS 名称，形式为 ```"<servicename>.<namespace>.<federationname>"``` 来解析联合服务。例如，您可以使用 `myservice.mynamespace.myfederation`。使用不同的 DNS 名称还可以避免现有应用程序意外穿越跨区域或跨区域网络，并且可能招致不必要的网络费用或延迟，而无需您明确选择采取这种行为。 - -<!-- So, using our NGINX example service above, and the Federated Service -DNS name form just described, let's consider an example: A Pod in a -cluster in the `us-central1-f` availability zone needs to contact our -NGINX service. Rather than use the service's traditional cluster-local -DNS name (`"nginx.mynamespace"`, which is automatically expanded -to `"nginx.mynamespace.svc.cluster.local"`) it can now use the -service's Federated DNS name, which is -`"nginx.mynamespace.myfederation"`. This will be automatically -expanded and resolved to the closest healthy shard of my NGINX -service, wherever in the world that may be. If a healthy shard exists -in the local cluster, that service's cluster-local (typically -10.x.y.z) IP address will be returned (by the cluster-local KubeDNS). -This is almost exactly equivalent to non-federated service resolution -(almost because KubeDNS actually returns both a CNAME and an A record -for local federated services, but applications will be oblivious -to this minor technical difference). --> -因此，使用上面的 NGINX 示例服务和刚才描述的联合服务 DNS 名称表单，让我们考虑一个示例:`us-central1-f` 可用性区域集群中的 Pod 需要联系我们的 NGINX 服务。现在，可以使用服务的联合 DNS 名称，而不是使用服务的传统集群本地 DNS 名称(`"nginx.mynamespace"` 会自动扩展为 `"nginx.mynamespace.svc.cluster.local"`)。无论位于世界何处，它都会自动扩展并解析为我的 NGINX 服务中最接近的健康分片。如果本地集群中存在健康的分片，则将返回该服务的集群本地(通常为10.x.y.z)的 IP 地址(由集群本地的 KubeDNS)。这几乎完全等同于非联合服务解析(几乎是因为 KubeDNS 实际上为本地联合服务返回了 CNAME 和 A 记录，但是应用程序将忽略这种微小的技术差异)。 - -<!-- But if the service does not exist in the local cluster (or it exists -but has no healthy backend pods), the DNS query is automatically -expanded to ```"nginx.mynamespace.myfederation.svc.us-central1-f.example.com"``` -(that is, logically "find the external IP of one of the shards closest to -my availability zone"). This expansion is performed automatically by -KubeDNS, which returns the associated CNAME record. This results in -automatic traversal of the hierarchy of DNS records in the above -example, and ends up at one of the external IPs of the Federated -Service in the local us-central1 region (that is 104.197.247.191, -104.197.244.180 or 104.197.245.170). --> -但是，如果服务在本地集群中不存在(或者存在但没有正常的后端 Pod),则 DNS 查询会自动扩展为 ```"nginx.mynamespace.myfederation.svc.us-central1-f.example.com"```(也就是说，从逻辑上 "找到最接近我可用区的一个分片的外部 IP")。此扩展由 KubeDNS 自动执行，它返回关联的 CNAME 记录。这将导致在上面的示例中自动遍历 DNS 记录的层次结构，并最终到达本地 us-central1 区域中联合服务的外部 IP 之一(即 104.197.247.191, 104.197.244.180 或 104.197.245.170 )。 - -<!-- It is of course possible to explicitly target service shards in -availability zones and regions other than the ones local to a Pod by -specifying the appropriate DNS names explicitly, and not relying on -automatic DNS expansion. For example, -"nginx.mynamespace.myfederation.svc.europe-west1.example.com" will -resolve to all of the currently healthy service shards in Europe, even -if the Pod issuing the lookup is located in the U.S., and irrespective -of whether or not there are healthy shards of the service in the U.S. -This is useful for remote monitoring and other similar applications. --> -当然，可以通过明确地指定合适的 DNS 名称而不依赖于自动 DNS 扩展，在 Pod 本地的可用区域和可用区域之外的区域中明确地定位服务分片。例如，即使发出查询的 Pod 位于美国，"nginx.mynamespace.myfederation.svc.europe-west1.example.com" 也将解析欧洲目前所有健康的服务分片,并且无论美国是否有健康的服务分片。这对于远程监视和其他类似应用程序很有用。 - -<!-- ### From other clients outside your federated clusters --> -### 来自联合集群之外的其他客户端 - -<!-- Much of the above discussion applies equally to external clients, -except that the automatic DNS expansion described is no longer -possible. So external clients need to specify one of the fully -qualified DNS names of the Federated Service, be that a zonal, -regional or global name. For convenience reasons, it is often a good -idea to manually configure additional static CNAME records in your -service, for example: --> -上面大部分讨论都同样适用于外部客户端，除了不再描述所描述的自动 DNS 扩展。因此，外部客户端需要指定联合服务的标准 DNS 名称，可以是地带名称，区域名称或者全局名称。为了方便起见，通常最好在服务中手动配置其他静态 CNAME 记录，例如: - -``` shell -eu.nginx.acme.com CNAME nginx.mynamespace.myfederation.svc.europe-west1.example.com. -us.nginx.acme.com CNAME nginx.mynamespace.myfederation.svc.us-central1.example.com. -nginx.acme.com CNAME nginx.mynamespace.myfederation.svc.example.com. -``` -<!-- That way your clients can always use the short form on the left, and -always be automatically routed to the closest healthy shard on their -home continent. All of the required failover is handled for you -automatically by Kubernetes Cluster Federation. Future releases will -improve upon this even further. --> -这样，您的客户就可以始终使用左侧的缩写形式，并始终被自动路由到其本国大陆上最接近的健康分片。Kubernetes 联邦集群自动为您处理所有必需的故障转移。将来的发行版将对此进行进一步改进。 - -<!-- ## Handling failures of backend pods and whole clusters --> -## 处理后端 Pod 和整个集群的故障 - -<!-- Standard Kubernetes service cluster-IP's already ensure that -non-responsive individual Pod endpoints are automatically taken out of -service with low latency (a few seconds). In addition, as alluded -above, the Kubernetes Cluster Federation system automatically monitors -the health of clusters and the endpoints behind all of the shards of -your Federated Service, taking shards in and out of service as -required (for example, when all of the endpoints behind a service, or perhaps -the entire cluster or availability zone go down, or conversely recover -from an outage). Due to the latency inherent in DNS caching (the cache -timeout, or TTL for Federated Service DNS records is configured to 3 -minutes, by default, but can be adjusted), it may take up to that long -for all clients to completely fail over to an alternative cluster in -the case of catastrophic failure. However, given the number of -discrete IP addresses which can be returned for each regional service -endpoint (such as us-central1 above, which has three alternatives) -many clients will fail over automatically to one of the alternative -IP's in less time than that given appropriate configuration. --> -标准的 Kubernetes 服务集群 IP 已确保无响应的单个 Pod 端点以低延迟(几秒钟)自动退出服务。此外，如上所述，Kubernetes 联邦集群系统会自动监视集群的状态以及联合服务的所有分片后面的端点，并根据需要使分片进入和退出服务(例如，当服务后面的所有端点或者整个集群或可用性区域出现故障时，或者相反地从中断中恢复时)。由于 DNS 缓存固有的延迟(默认情况下,缓存超时或联合服务 DNS 记录的 TTL 配置为3分钟，可以调整),在灾难性故障的情况下，所有客户端可能要花费很长时间才能完全故障转移到备用集群。但是，鉴于每个区域服务端点可以返回的离散 IP 地址数量(例如上面的 us-central1，它有三个替代方案),与给定的合适配置相比，许多客户端将在更少的时间内自动故障转移到其他 IP。 - - - -<!-- discussion --> - -<!-- ## Troubleshooting --> -## 故障排除 - -<!-- ### I cannot connect to my cluster federation API --> -### 我无法连接到联合集群 API -<!-- Check that your --> -检查您的 - -<!-- 1. Client (typically kubectl) is correctly configured (including API endpoints and login credentials). -2. Cluster Federation API server is running and network-reachable. --> -1. 客户端(通常是 kubectl)已正确配置(包括 API 端点和登录凭据)。 -2. 联合集群 API 服务器正在运行并且可以访问网络。 - -<!-- See the [federation admin guide](/docs/admin/federation/) to learn -how to bring up a cluster federation correctly (or have your cluster administrator do this for you), and how to correctly configure your client. --> -请参阅 [联合集群管理员指南](/docs/admin/federation/)了解如何正确启动联邦集群(或让您的集群管理员为您执行此操作),以及如何正确配置客户端。 - -<!-- ### I can create a federated service successfully against the cluster federation API, but no matching services are created in my underlying clusters --> -### 我可以针对联合集群 API 成功创建联合服务,但是在我的基础集群中没有创建匹配的服务。 -<!-- Check that: --> -检查: - -<!-- 1. Your clusters are correctly registered in the Cluster Federation API (`kubectl describe clusters`). -2. Your clusters are all 'Active'. This means that the cluster Federation system was able to connect and authenticate against the clusters' endpoints. If not, consult the logs of the federation-controller-manager pod to ascertain what the failure might be. - ``` - kubectl --namespace=federation logs $(kubectl get pods --namespace=federation -l module=federation-controller-manager -o name) - ``` -3. That the login credentials provided to the Cluster Federation API for the clusters have the correct authorization and quota to create services in the relevant namespace in the clusters. Again you should see associated error messages providing more detail in the above log file if this is not the case. -4. Whether any other error is preventing the service creation operation from succeeding (look for `service-controller` errors in the output of `kubectl logs federation-controller-manager --namespace federation`). --> -1. 您的集群已在联合集群 API 中正确注册(`kubectl describe clusters`)。 -2. 您的集群都是 "活跃的"。这意味着集群联合身份验证系统能够针对集群的端点进行连接和身份验证。如果不是，请查阅federation-controller-manager pod 的日志，以确定可能是什么故障。 - ``` - kubectl --namespace=federation logs $(kubectl get pods --namespace=federation -l module=federation-controller-manager -o name) - ``` -3. 集群提供给联合集群 API 的登录凭据具有正确的授权和配额，可以在集群的相关命名空间中创建服务。如果不是这种情况，您将再次在上述日志文件中看到相关的错误消息，以提供更多详细信息。 -4. 是否有其他错误阻止服务创建操作成功(请在 `kubectl logs federation-controller-manager --namespace federation` 的输出中查找 `service-controller` 错误)。 - -<!-- ### I can create a federated service successfully, but no matching DNS records are created in my DNS provider. -Check that: --> -### 我可以成功创建联合服务，但是在我的 DNS 提供程序中没有创建匹配的 DNS 记录。 -检查: - -<!-- 1. Your federation name, DNS provider, DNS domain name are configured correctly. Consult the [federation admin guide](/docs/admin/federation/) or [tutorial](https://github.com/kelseyhightower/kubernetes-cluster-federation) to learn -how to configure your Cluster Federation system's DNS provider (or have your cluster administrator do this for you). -2. Confirm that the Cluster Federation's service-controller is successfully connecting to and authenticating against your selected DNS provider (look for `service-controller` errors or successes in the output of `kubectl logs federation-controller-manager --namespace federation`). -3. Confirm that the Cluster Federation's service-controller is successfully creating DNS records in your DNS provider (or outputting errors in its logs explaining in more detail what's failing). --> -1. 您的联邦集群名称，DNS 提供程序，DNS 域名已正确配置。请参阅 [联邦集群管理指南](/docs/admin/federation/)或者 [教程](https://github.com/kelseyhightower/kubernetes-cluster-federation)了解如何配置联合集群系统的 DNS 提供程序(或让您的集群管理员为您执行此操作)。 -2. 确认联合集群的服务控制器已成功连接到所选的 DNS 提供程序并对其进行身份验证(在 `kubectl logs federation-controller-manager --namespace federation` 的输出中查找 `service-controller` 错误或者成功)。 -3. 确认联合集群的服务控制器已在您的 DNS 提供程序中成功创建了 DNS 记录(或在其日志中输出错误，以更详细地解释失败原因)。 - -<!-- ### Matching DNS records are created in my DNS provider, but clients are unable to resolve against those names -Check that: --> -### 在我的 DNS 提供程序中创建了匹配的 DNS 记录，但是客户端无法根据这些名称进行解析 -检查: - -<!-- 1. The DNS registrar that manages your federation DNS domain has been correctly configured to point to your configured DNS provider's nameservers. See for example [Google Domains Documentation](https://support.google.com/domains/answer/3290309?hl=en&ref_topic=3251230) and [Google Cloud DNS Documentation](https://cloud.google.com/dns/update-name-servers), or equivalent guidance from your domain registrar and DNS provider. --> -1. 已正确配置用于管理联合 DNS 域名的 DNS 注册器，使其指向已配置的 DNS 提供程序的名称服务器。例如，请参见 [Google Domains 文档](https://support.google.com/domains/answer/3290309?hl=en&ref_topic=3251230)与 [Google Cloud DNS 文档](https://cloud.google.com/dns/update-name-servers),或者域名注册商和 DNS 提供商的等效指南。 - -<!-- ### This troubleshooting guide did not help me solve my problem --> -### 此疑难解答指南没有帮助我解决问题 - -<!-- 1. Please use one of our [support channels](/docs/tasks/debug-application-cluster/troubleshooting/) to seek assistance. --> -1. 请使用我们的 [支持渠道](/docs/tasks/debug-application-cluster/troubleshooting/)寻求帮助。 - -<!-- ## For more information --> -## 更多信息 - - <!-- * [Federation proposal](https://git.k8s.io/community/contributors/design-proposals/multicluster/federation.md) details use cases that motivated this work. --> - * [联合提议](https://git.k8s.io/community/contributors/design-proposals/multicluster/federation.md) 详细介绍了促进这项工作的用例。 - diff --git a/content/zh/docs/tasks/federation/set-up-coredns-provider-federation.md b/content/zh/docs/tasks/federation/set-up-coredns-provider-federation.md deleted file mode 100644 index 8193d928dc..0000000000 --- a/content/zh/docs/tasks/federation/set-up-coredns-provider-federation.md +++ /dev/null @@ -1,254 +0,0 @@ ---- -title: 将 CoreDNS 设置为联邦集群的 DNS 提供者 -content_type: tutorial -weight: 130 ---- - -<!-- ---- -title: Set up CoreDNS as DNS provider for Cluster Federation -content_type: tutorial -weight: 130 ---- ---> - -<!-- overview --> - -{{< deprecationfilewarning >}} -{{< include "federation-deprecation-warning-note.md" >}} -{{< /deprecationfilewarning >}} - -<!-- -This page shows how to configure and deploy CoreDNS to be used as the -DNS provider for Cluster Federation. ---> -此页面显示如何配置和部署 CoreDNS，将其用作联邦集群的 DNS 提供者 - - - - -## {{% heading "objectives" %}} - - -<!-- -* Configure and deploy CoreDNS server -* Bring up federation with CoreDNS as dns provider -* Setup CoreDNS server in nameserver lookup chain ---> - -* 配置和部署 CoreDNS 服务器 -* 使用 CoreDNS 作为 dns 提供者设置联邦 -* 在 nameserver 查找链中设置 CoreDNS 服务器 - - - - -## {{% heading "prerequisites" %}} - - -<!-- -* You need to have a running Kubernetes cluster (which is -referenced as host cluster). Please see one of the -[getting started](/docs/setup/) guides for -installation instructions for your platform. -* Support for `LoadBalancer` services in member clusters of federation is -mandatory to enable `CoreDNS` for service discovery across federated clusters. ---> - -* 你需要有一个正在运行的 Kubernetes 集群（作为主机集群引用）。请参阅[入门指南](/docs/setup/)，了解平台的安装说明。 -* 必须在联邦的集群成员中支持 `LoadBalancer` 服务，用来支持跨联邦集群的 `CoreDNS` 服务发现。 - - - - -<!-- lessoncontent --> - -<!-- -## Deploying CoreDNS and etcd charts ---> - -## 部署 CoreDNS 和 etcd 图表 - -<!-- -CoreDNS can be deployed in various configurations. Explained below is a -reference and can be tweaked to suit the needs of the platform and the -cluster federation. ---> -CoreDNS 可以部署在各种配置中。下面解释的是一个参考，可以根据平台和联邦集群的需要进行调整。 - -<!-- -To deploy CoreDNS, we shall make use of helm charts. CoreDNS will be -deployed with [etcd](https://coreos.com/etcd) as the backend and should -be pre-installed. etcd can also be deployed using helm charts. Shown -below are the instructions to deploy etcd. ----> -为了部署 CoreDNS，我们将利用图表。 -CoreDNS 将部署 [etcd](https://coreos.com/etcd) 作为后端，并且应该预先安装。etcd 也可以使用图表进行部署。下面显示了部署 etcd 的说明。 - - helm install --namespace my-namespace --name etcd-operator stable/etcd-operator - helm upgrade --namespace my-namespace --set cluster.enabled=true etcd-operator stable/etcd-operator - -<!-- -*Note: etcd default deployment configurations can be overridden, suiting the -host cluster.* ---> -*注意：etcd 默认部署配置可以被覆盖，适合主机集群。* - -<!-- -After deployment succeeds, etcd can be accessed with the -[http://etcd-cluster.my-namespace:2379](http://etcd-cluster.my-namespace:2379) endpoint within the host cluster. ---> -部署成功后，可以使用主机集群中的 [http://etcd-cluster.my-namespace:2379](http://etcd-cluster.my-namespace:2379) 端点访问 etcd。 - -<!-- -The CoreDNS default configuration should be customized to suit the federation. -Shown below is the Values.yaml, which overrides the default -configuration parameters on the CoreDNS chart. ---> -应该定制 CoreDNS 默认配置适应联邦。 -下面显示的是 Values.yaml，它覆盖了 CoreDNS 图表上的默认配置参数。 - -```yaml -isClusterService: false -serviceType: "LoadBalancer" -plugins: - kubernetes: - enabled: false - etcd: - enabled: true - zones: - - "example.com." - endpoint: "http://etcd-cluster.my-namespace:2379" -``` - -<!-- -The above configuration file needs some explanation: ---> -以上配置文件需要说明： - -<!-- - - `isClusterService` specifies whether CoreDNS should be deployed as a -cluster-service, which is the default. You need to set it to false, so -that CoreDNS is deployed as a Kubernetes application service. - - `serviceType` specifies the type of Kubernetes service to be created -for CoreDNS. You need to choose either "LoadBalancer" or "NodePort" to -make the CoreDNS service accessible outside the Kubernetes cluster. - - Disable `plugins.kubernetes`, which is enabled by default by -setting `plugins.kubernetes.enabled` to false. - - Enable `plugins.etcd` by setting `plugins.etcd.enabled` to -true. - - Configure the DNS zone (federation domain) for which CoreDNS is -authoritative by setting `plugins.etcd.zones` as shown above. - - Configure the etcd endpoint which was deployed earlier by setting -`plugins.etcd.endpoint` ---> - - `isClusterService` 指定是否应该将 CoreDNS 部署为集群服务，这是默认值。 -你需要将其设置为 false，以便将 CoreDNS 部署为 Kubernetes 应用程序服务。 - - `serviceType` 指定为核心用户创建的 Kubernetes 服务的类型。 -你需要选择 `LoadBalancer` 或 `NodePort`，以便在 Kubernetes 集群之外访问 CoreDNS 服务。 - - 禁用 `plugins.kubernetes`，默认情况下通过设置 `plugins.kubernetes.enabled` 为 false。 - - 启用 `plugins.etcd`，通过设置 `plugins.etcd.enabled` 为 true。 - - 通过设置 `plugins.etcd.zones` 来配置 CoreDNS 具有权威性的 DNS 域（联邦域）。如上所示。 - - 通过设置 `plugins.etcd.endpoint` 来配置早期部署的 etcd 端点 - -<!-- -Now deploy CoreDNS by running - - helm install --namespace my-namespace --name coredns -f Values.yaml stable/coredns - -Verify that both etcd and CoreDNS pods are running as expected. ---> -现在部署 CoreDNS 来运行 - - helm install --namespace my-namespace --name coredns -f Values.yaml stable/coredns - -验证 etcd 和 CoreDNS，pod 都按预期运行。 - -<!-- -## Deploying Federation with CoreDNS as DNS provider ---> - -## 使用 CoreDNS 作为 DNS 提供者部署联邦 - -<!-- -The Federation control plane can be deployed using `kubefed init`. CoreDNS -can be chosen as the DNS provider by specifying two additional parameters. ---> -可以使用 `kubefed init` 部署联邦控制平面。通过指定两个附加参数，可以选择 CoreDNS 作为 DNS 提供者。 - - --dns-provider=coredns - --dns-provider-config=coredns-provider.conf - -<!-- -coredns-provider.conf has below format: ---> -coredns-provider.conf 的格式如下： - - [Global] - etcd-endpoints = http://etcd-cluster.my-namespace:2379 - zones = example.com. - coredns-endpoints = <coredns-server-ip>:<port> - -<!-- - - `etcd-endpoints` is the endpoint to access etcd. - - `zones` is the federation domain for which CoreDNS is authoritative and is same as --dns-zone-name flag of `kubefed init`. - - `coredns-endpoints` is the endpoint to access CoreDNS server. This is an optional parameter introduced from v1.7 onwards. ---> - - - `etcd-endpoints` 是访问 etcd 的端点。 - - `zones` 是 CoreDNS 具有权威性的联邦域，它与 `kubefed init` 的 --dns-zone-name 参数相同。 - - `coredns-endpoints` 是访问 CoreDNS 服务器的端点。这是从 v1.7 开始引入的一个可选参数。 - -{{< note >}} -<!-- -`plugins.etcd.zones` in the CoreDNS configuration and the `--dns-zone-name` flag to `kubefed init` should match. ---> -CoreDNS 配置中的 `plugins.etcd.zones` 和 `kubefed init` 的 `--dns-zone-name` 参数应该匹配。 -{{< /note >}} - -<!-- -## Setup CoreDNS server in nameserver resolv.conf chain ---> - -## 在 nameserver resolv.conf 链中设置 CoreDNS 服务器 - -{{< note >}} -<!-- -The following section applies only to versions prior to v1.7 -and will be automatically taken care of if the `coredns-endpoints` -parameter is configured in `coredns-provider.conf` as described in -section above. ---> -下面的部分只适用于 v1.7 之前的版本，如果 `coredns-endpoint` 参数是 -在 `coredns-provider.conf` 中配置的，就会自动处理。 - -{{< /note >}} - -<!-- -Once the federation control plane is deployed and federated clusters -are joined to the federation, you need to add the CoreDNS server to the -pod's nameserver resolv.conf chain in all the federated clusters as this -self hosted CoreDNS server is not discoverable publicly. This can be -achieved by adding the below line to `dnsmasq` container's arg in -`kube-dns` deployment. ---> -一旦部署了联邦控制平面并将联邦集群连接到联邦， -你需要将 CoreDNS 服务器添加到所有联邦集群中 pod 的 nameserver resolv.conf 链，因为这个自托管的 CoreDNS 服务器是不可公开发现的。 -这可以通过在 `kube-dns` 部署中将下面的行添加到 `dnsmasq` 容器的参数中来实现。 - - - --server=/example.com./<CoreDNS endpoint> - -<!-- -Replace `example.com` above with federation domain. ---> -将上面的 `example.com` 替换为联邦域。 - -<!-- -Now the federated cluster is ready for cross-cluster service discovery! ---> -现在联邦集群已经为跨集群服务发现做好了准备！ - - - - diff --git a/content/zh/docs/tasks/federation/set-up-placement-policies-federation.md b/content/zh/docs/tasks/federation/set-up-placement-policies-federation.md deleted file mode 100644 index 1dfc62e3fd..0000000000 --- a/content/zh/docs/tasks/federation/set-up-placement-policies-federation.md +++ /dev/null @@ -1,331 +0,0 @@ ---- -title: 在联邦中设置放置策略 -content_type: task ---- - -<!-- -title: Set up placement policies in Federation -content_type: task ---> - -<!-- overview --> - -{{< deprecationfilewarning >}} -{{< include "federation-deprecation-warning-note.md" >}} -{{< /deprecationfilewarning >}} - -<!-- -This page shows how to enforce policy-based placement decisions over Federated -resources using an external policy engine. ---> -此页面显示如何使用外部策略引擎对联邦资源强制执行基于策略的放置决策。 - - - -## {{% heading "prerequisites" %}} - - -<!-- -You need to have a running Kubernetes cluster (which is referenced as host -cluster). Please see one of the [getting started](/docs/setup/) -guides for installation instructions for your platform. ---> -您需要一个正在运行的 Kubernetes 集群(它被引用为主机集群)。有关您的平台的安装说明，请参阅[入门](/docs/setup/)指南。 - - - -<!-- steps --> - -<!-- -## Deploying Federation and configuring an external policy engine ---> -## Deploying 联邦并配置外部策略引擎 - -<!-- -The Federation control plane can be deployed using `kubefed init`. ---> -可以使用 `kubefed init` 部署联邦控制平面。 - -<!-- -After deploying the Federation control plane, you must configure an Admission -Controller in the Federation API server that enforces placement decisions -received from the external policy engine. ---> -Deploying 联邦控制平面之后，必须在联邦 API 服务器中配置一个准入控制器，该控制器强制执行从外部策略引擎接收到的放置决策。 - - - kubectl create -f scheduling-policy-admission.yaml - -<!-- -Shown below is an example ConfigMap for the Admission Controller: ---> -下图是准入控制器的 ConfigMap 示例： - -{{< codenew file="federation/scheduling-policy-admission.yaml" >}} - -<!-- -The ConfigMap contains three files: ---> -ConfigMap 包含三个文件： - -<!-- -* `config.yml` specifies the location of the `SchedulingPolicy` Admission - Controller config file. -* `scheduling-policy-config.yml` specifies the location of the kubeconfig file - required to contact the external policy engine. This file can also include a - `retryBackoff` value that controls the initial retry backoff delay in - milliseconds. -* `opa-kubeconfig` is a standard kubeconfig containing the URL and credentials - needed to contact the external policy engine. ---> -* `config.yml` 指定 `调度策略` 准入控制器配置文件的位置。 -* `scheduling-policy-config.yml` 指定与外部策略引擎联系所需的 kubeconfig 文件的位置。 -该文件还可以包含一个 `retryBackoff` 值，该值以毫秒为单位控制初始重试 backoff 延迟。 -* `opa-kubeconfig` 是一个标准的 kubeconfig，包含联系外部策略引擎所需的 URL 和凭证。 - -<!-- -Edit the Federation API server deployment to enable the `SchedulingPolicy` -Admission Controller. ---> -编辑联邦 API 服务器部署以启用 `SchedulingPolicy` 准入控制器。 - - kubectl -n federation-system edit deployment federation-apiserver - -<!-- -Update the Federation API server command line arguments to enable the Admission -Controller and mount the ConfigMap into the container. If there's an existing -`--enable-admission-plugins` flag, append `,SchedulingPolicy` instead of adding -another line. ---> -更新 Federation API 服务器命令行参数以启用准入控制器， -并将 ConfigMap 挂载到容器中。如果存在现有的 `-enable-admissionplugins` 参数，则追加 `SchedulingPolicy` 而不是添加另一行。 - - - --enable-admission-plugins=SchedulingPolicy - --admission-control-config-file=/etc/kubernetes/admission/config.yml - -<!-- -Add the following volume to the Federation API server pod: ---> -将以下卷添加到联邦 API 服务器 pod： - - - name: admission-config - configMap: - name: admission - -<!-- -Add the following volume mount the Federation API server `apiserver` container: ---> -添加以下卷挂载联邦 API 服务器的 `apiserver` 容器： - - volumeMounts: - - name: admission-config - mountPath: /etc/kubernetes/admission - -<!-- -## Deploying an external policy engine ---> - -## Deploying 外部策略引擎 - -<!-- -The [Open Policy Agent (OPA)](http://openpolicyagent.org) is an open source, -general-purpose policy engine that you can use to enforce policy-based placement -decisions in the Federation control plane. ---> -[Open Policy Agent (OPA)](http://openpolicyagent.org) 是一个开源的通用策略引擎， -您可以使用它在联邦控制平面中执行基于策略的放置决策。 - -<!-- -Create a Service in the host cluster to contact the external policy engine: ---> -在主机群集中创建服务以联系外部策略引擎： - - kubectl create -f policy-engine-service.yaml - -<!-- -Shown below is an example Service for OPA. ---> -下面显示的是 OPA 的示例服务。 - -{{< codenew file="federation/policy-engine-service.yaml" >}} - -<!-- -Create a Deployment in the host cluster with the Federation control plane: ---> -使用联邦控制平面在主机群集中创建部署： - - kubectl create -f policy-engine-deployment.yaml - -<!-- -Shown below is an example Deployment for OPA. ---> -下面显示的是 OPA 的部署示例。 - -{{< codenew file="federation/policy-engine-deployment.yaml" >}} - -<!-- -## Configuring placement policies via ConfigMaps ---> - -## 通过 ConfigMaps 配置放置策略 - -<!-- -The external policy engine will discover placement policies created in the -`kube-federation-scheduling-policy` namespace in the Federation API server. ---> -外部策略引擎将发现在 Federation API 服务器的 `kube-federation-scheduling-policy` -命名空间中创建的放置策略。 - -<!-- -Create the namespace if it does not already exist: ---> -如果命名空间尚不存在，请创建它： - - kubectl --context=federation create namespace kube-federation-scheduling-policy - -<!-- -Configure a sample policy to test the external policy engine: ---> -配置一个示例策略来测试外部策略引擎: - -``` -# OPA supports a high-level declarative language named Rego for authoring and -# enforcing policies. For more information on Rego, visit -# http://openpolicyagent.org. - -# Rego policies are namespaced by the "package" directive. -package kubernetes.placement - -# Imports provide aliases for data inside the policy engine. In this case, the -# policy simply refers to "clusters" below. -import data.kubernetes.clusters - -# The "annotations" rule generates a JSON object containing the key -# "federation.kubernetes.io/replica-set-preferences" mapped to <preferences>. -# The preferences values is generated dynamically by OPA when it evaluates the -# rule. -# -# The SchedulingPolicy Admission Controller running inside the Federation API -# server will merge these annotations into incoming Federated resources. By -# setting replica-set-preferences, we can control the placement of Federated -# ReplicaSets. -# -# Rules are defined to generate JSON values (booleans, strings, objects, etc.) -# When OPA evaluates a rule, it generates a value IF all of the expressions in -# the body evaluate successfully. All rules can be understood intuitively as -# <head> if <body> where <body> is true if <expr-1> AND <expr-2> AND ... -# <expr-N> is true (for some set of data.) -annotations["federation.kubernetes.io/replica-set-preferences"] = preferences { - input.kind = "ReplicaSet" - value = {"clusters": cluster_map, "rebalance": true} - json.marshal(value, preferences) -} - -# This "annotations" rule generates a value for the "federation.alpha.kubernetes.io/cluster-selector" -# annotation. -# -# In English, the policy asserts that resources in the "production" namespace -# that are not annotated with "criticality=low" MUST be placed on clusters -# labelled with "on-premises=true". -annotations["federation.alpha.kubernetes.io/cluster-selector"] = selector { - input.metadata.namespace = "production" - not input.metadata.annotations.criticality = "low" - json.marshal([{ - "operator": "=", - "key": "on-premises", - "values": "[true]", - }], selector) -} - -# Generates a set of cluster names that satisfy the incoming Federated -# ReplicaSet's requirements. In this case, just PCI compliance. -replica_set_clusters[cluster_name] { - clusters[cluster_name] - not insufficient_pci[cluster_name] -} - -# Generates a set of clusters that must not be used for Federated ReplicaSets -# that request PCI compliance. -insufficient_pci[cluster_name] { - clusters[cluster_name] - input.metadata.annotations["requires-pci"] = "true" - not pci_clusters[cluster_name] -} - -# Generates a set of clusters that are PCI certified. In this case, we assume -# clusters are annotated to indicate if they have passed PCI compliance audits. -pci_clusters[cluster_name] { - clusters[cluster_name].metadata.annotations["pci-certified"] = "true" -} - -# Helper rule to generate a mapping of desired clusters to weights. In this -# case, weights are static. -cluster_map[cluster_name] = {"weight": 1} { - replica_set_clusters[cluster_name] -} -``` - -<!-- -Shown below is the command to create the sample policy: ---> -下面显示的是创建示例策略的命令： - - kubectl --context=federation -n kube-federation-scheduling-policy create configmap scheduling-policy --from-file=policy.rego - -<!-- -This sample policy illustrates a few key ideas: ---> -这个示例策略说明了一些关键思想： - -<!-- -* Placement policies can refer to any field in Federated resources. -* Placement policies can leverage external context (for example, Cluster - metadata) to make decisions. -* Administrative policy can be managed centrally. -* Policies can define simple interfaces (such as the `requires-pci` annotation) to - avoid duplicating logic in manifests. ---> - -* 位置策略可以引用联邦资源中的任何字段。 -* 放置策略可以利用外部上下文(例如，集群元数据)来做出决策。 -* 管理策略可以集中管理。 -* 策略可以定义简单的接口(例如 `requirements -pci` 注解)，以避免在清单中重复逻辑。 - -<!-- -## Testing placement policies ---> - -## 测试放置政策 - -<!-- -Annotate one of the clusters to indicate that it is PCI certified. ---> -注释其中一个集群以表明它是经过 PCI 认证的。 - - kubectl --context=federation annotate clusters cluster-name-1 pci-certified=true - -<!-- -Deploy a Federated ReplicaSet to test the placement policy. ---> -部署联邦副本来测试放置策略。 - -{{< codenew file="federation/replicaset-example-policy.yaml" >}} - -<!-- -Shown below is the command to deploy a ReplicaSet that *does* match the policy. ---> -下面显示的命令用于部署与策略匹配的副本集。 - - kubectl --context=federation create -f replicaset-example-policy.yaml - -<!-- -Inspect the ReplicaSet to confirm the appropriate annotations have been applied: ---> -检查副本集以确认已应用适当的注解： - - kubectl --context=federation get rs nginx-pci -o jsonpath='{.metadata.annotations}' - - - - diff --git a/content/zh/docs/tasks/job/automated-tasks-with-cron-jobs.md b/content/zh/docs/tasks/job/automated-tasks-with-cron-jobs.md index 131ef52219..503741d091 100644 --- a/content/zh/docs/tasks/job/automated-tasks-with-cron-jobs.md +++ b/content/zh/docs/tasks/job/automated-tasks-with-cron-jobs.md @@ -27,7 +27,7 @@ Cron jobs are useful for creating periodic and recurring tasks, like running bac Cron jobs can also schedule individual tasks for a specific time, such as if you want to schedule a job for a low activity period. --> -你可以利用 [CronJobs](/docs/concepts/workloads/controllers/cron-jobs) 执行基于时间调度的任务。这些自动化任务和 Linux 或者 Unix 系统的 [Cron](https://en.wikipedia.org/wiki/Cron) 任务类似。 +你可以利用 [CronJobs](/zh/docs/concepts/workloads/controllers/cron-jobs) 执行基于时间调度的任务。这些自动化任务和 Linux 或者 Unix 系统的 [Cron](https://en.wikipedia.org/wiki/Cron) 任务类似。 CronJobs 在创建周期性以及重复性的任务时很有帮助，例如执行备份操作或者发送邮件。CronJobs 也可以在特定时间调度单个任务，例如你想调度低活跃周期的任务。 @@ -51,7 +51,7 @@ For more limitations, see [CronJobs](/docs/concepts/workloads/controllers/cron-j CronJobs 有一些限制和特点。 例如，在特定状况下，同一个 CronJob 可以创建多个任务。 因此，任务应该是幂等的。 -查看更多限制，请参考 [CronJobs](/docs/concepts/workloads/controllers/cron-jobs)。 +查看更多限制，请参考 [CronJobs](/zh/docs/concepts/workloads/controllers/cron-jobs)。 @@ -67,7 +67,7 @@ for more), and then restart both the API server and the controller manager component. --> -* 你需要一个版本 >=1.8 且工作正常的 Kubernetes 集群。对于更早的版本（ <1.8 ），你需要对 API 服务器设置 `--runtime-config=batch/v2alpha1=true` 来开启 `batch/v2alpha1` API，(更多信息请查看 [为你的集群开启或关闭 API 版本](/docs/admin/cluster-management/#turn-on-or-off-an-api-version-for-your-cluster) +* 你需要一个版本 >=1.8 且工作正常的 Kubernetes 集群。对于更早的版本（ <1.8 ），你需要对 API 服务器设置 `--runtime-config=batch/v2alpha1=true` 来开启 `batch/v2alpha1` API，(更多信息请查看 [为你的集群开启或关闭 API 版本](/zh/docs/tasks/administer-cluster/cluster-management/#打开或关闭集群的-api-版本) ), 然后重启 API 服务器和控制管理器。 @@ -192,7 +192,7 @@ Deleting the cron job removes all the jobs and pods it created and stops it from You can read more about removing jobs in [garbage collection](/docs/concepts/workloads/controllers/garbage-collection/). --> -删除 CronJob 会清除它创建的所有任务和 Pod，并阻止它创建额外的任务。你可以查阅 [垃圾收集](/docs/concepts/workloads/controllers/garbage-collection/)。 +删除 CronJob 会清除它创建的所有任务和 Pod，并阻止它创建额外的任务。你可以查阅 [垃圾收集](/zh/docs/concepts/workloads/controllers/garbage-collection/)。 <!-- ## Writing a Cron Job Spec @@ -206,7 +206,7 @@ A cron job config also needs a [`.spec` section](https://git.k8s.io/community/co ## 编写 CronJob 声明信息 -像 Kubernetes 的其他配置一样，CronJob 需要 `apiVersion`、 `kind`、 和 `metadata` 域。配置文件的一般信息，请参考 [部署应用](/docs/user-guide/deploying-applications) 和 [使用 kubectl 管理资源](/docs/user-guide/working-with-resources). +像 Kubernetes 的其他配置一样，CronJob 需要 `apiVersion`、 `kind`、 和 `metadata` 域。配置文件的一般信息，请参考 [部署应用](/zh/docs/tasks/run-application/run-stateless-application-deployment/) 和 [使用 kubectl 管理资源](/zh/docs/concepts/overview/working-with-objects/object-management/). CronJob 配置也需要包括[`.spec`](https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status). diff --git a/content/zh/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough.md b/content/zh/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough.md index d7db4ef10b..58ee1d72a2 100644 --- a/content/zh/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough.md +++ b/content/zh/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough.md @@ -74,7 +74,7 @@ Dockerfile 内容如下： ``` FROM php:5-apache -ADD index.php /var/www/html/index.php +COPY index.php /var/www/html/index.php RUN chmod a+rx index.php ``` <!-- diff --git a/content/zh/docs/tasks/run-application/run-replicated-stateful-application.md b/content/zh/docs/tasks/run-application/run-replicated-stateful-application.md index d35a0efefa..368f7e0486 100644 --- a/content/zh/docs/tasks/run-application/run-replicated-stateful-application.md +++ b/content/zh/docs/tasks/run-application/run-replicated-stateful-application.md @@ -35,8 +35,7 @@ on general patterns for running stateful applications in Kubernetes. --> ## {{% heading "prerequisites" %}} -<!-- * {{< include "task-tutorial-prereqs.md" >}} {{< version-check >}} -* {{< include "default-storage-class-prereqs.md" >}} +<!-- * This tutorial assumes you are familiar with [PersistentVolumes](/docs/concepts/storage/persistent-volumes/) and [StatefulSets](/docs/concepts/workloads/controllers/statefulset/), diff --git a/content/zh/docs/tasks/service-catalog/install-service-catalog-using-helm.md b/content/zh/docs/tasks/service-catalog/install-service-catalog-using-helm.md index 37bc08ed3d..91116c46f0 100644 --- a/content/zh/docs/tasks/service-catalog/install-service-catalog-using-helm.md +++ b/content/zh/docs/tasks/service-catalog/install-service-catalog-using-helm.md @@ -40,7 +40,7 @@ Use [Helm](https://helm.sh/) to install Service Catalog on your Kubernetes clust * 您必须启用 Kubernetes 集群的 DNS 功能。 * 如果使用基于云的 Kubernetes 集群或 {{< glossary_tooltip text="Minikube" term_id="minikube" >}}，则可能已经启用了集群 DNS。 * 如果您正在使用 `hack/local-up-cluster.sh`，请确保设置了 `KUBE_ENABLE_CLUSTER_DNS` 环境变量，然后运行安装脚本。 -* [安装和设置 v1.7 或更高版本的 kubectl](https://kubernetes.io/docs/tasks/tools/install-kubectl/)，确保将其配置为连接到 Kubernetes 集群。 +* [安装和设置 v1.7 或更高版本的 kubectl](/zh/docs/tasks/tools/install-kubectl/)，确保将其配置为连接到 Kubernetes 集群。 * 安装 v2.7.0 或更高版本的 [Helm](http://helm.sh/)。 * 遵照 [Helm 安装说明](https://github.com/kubernetes/helm/blob/master/docs/install.md)。 * 如果已经安装了适当版本的 Helm，请执行 `helm init` 来安装 Helm 的服务器端组件 Tiller。 @@ -142,7 +142,7 @@ Install Service Catalog from the root of the Helm repository using the following --> 使用以下命令从 Helm 存储库的根目录安装 Service Catalog： -{{< tabs name="helm-versions" >}} +{{< tabs name="helm-versions" >}} {{% tab name="Helm version 3" %}} ```shell helm install catalog svc-cat/catalog --namespace catalog @@ -163,5 +163,3 @@ helm install svc-cat/catalog --name catalog --namespace catalog --> * 查看[示例服务代理](https://github.com/openservicebrokerapi/servicebroker/blob/mastergettingStarted.md#sample-service-brokers)。 * 探索 [kubernetes-incubator/service-catalog](https://github.com/kubernetes-incubator/service-catalog) 项目。 - - diff --git a/content/zh/docs/tasks/tools/install-kubectl.md b/content/zh/docs/tasks/tools/install-kubectl.md index 723c6c25b0..577e48d40f 100644 --- a/content/zh/docs/tasks/tools/install-kubectl.md +++ b/content/zh/docs/tasks/tools/install-kubectl.md @@ -1,20 +1,24 @@ --- -reviewers: -- mikedanese -title: 安装并设置 kubectl +title: 安装并配置 kubectl content_type: task weight: 10 +card: + name: tasks + weight: 20 + title: 安装 kubectl --- <!-- ---- reviewers: -- bgrant0607 - mikedanese title: Install and Set Up kubectl content_type: task weight: 10 ---- +card: + name: tasks + weight: 20 + title: Install kubectl --> + <!-- overview --> <!-- Use the Kubernetes command-line tool, [kubectl](/docs/user-guide/kubectl/), to deploy and manage applications on Kubernetes. Using kubectl, you can inspect cluster resources; create, delete, and update components; look at your new cluster; and bring up example apps. diff --git a/content/zh/docs/tasks/tools/install-minikube.md b/content/zh/docs/tasks/tools/install-minikube.md index 55439a64e0..fce7facc9d 100644 --- a/content/zh/docs/tasks/tools/install-minikube.md +++ b/content/zh/docs/tasks/tools/install-minikube.md @@ -402,8 +402,14 @@ For setting the `--vm-driver` with `minikube start`, enter the name of the hyper [指定 VM 驱动程序](/docs/setup/learning-environment/minikube/#specifying-the-vm-driver) 列举了 `--vm-driver` 值的完整列表。 {{< /note >}} +{{< note >}} +由于国内无法直接连接 k8s.gcr.io，推荐使用阿里云镜像仓库，在 `minikube start` 中添加 `--image-repository` 参数。 +{{< /note >}} + ```shell minikube start --vm-driver=<driver_name> +# Or when you need +minikube start --vm-driver=<driver_name> --image-repository=registry.cn-hangzhou.aliyuncs.com/google_containers ``` <!-- @@ -481,4 +487,3 @@ minikube delete --> * [使用 Minikube 在本地运行 Kubernetes](/docs/setup/learning-environment/minikube/) - diff --git a/content/zh/docs/tutorials/configuration/configure-redis-using-configmap.md b/content/zh/docs/tutorials/configuration/configure-redis-using-configmap.md index d43ee91103..f57514b47e 100644 --- a/content/zh/docs/tutorials/configuration/configure-redis-using-configmap.md +++ b/content/zh/docs/tutorials/configuration/configure-redis-using-configmap.md @@ -136,7 +136,7 @@ the configuration was correctly applied: 使用 `kubectl exec` 进入 pod 并运行 `redis-cli` 工具来验证配置已正确应用： ```shell -kubectl exec -it redis redis-cli +kubectl exec -it redis -- redis-cli 127.0.0.1:6379> CONFIG GET maxmemory 1) "maxmemory" 2) "2097152" diff --git a/content/zh/docs/tutorials/kubernetes-basics/create-cluster/cluster-interactive.html b/content/zh/docs/tutorials/kubernetes-basics/create-cluster/cluster-interactive.html index ae0974c817..01dea341b8 100644 --- a/content/zh/docs/tutorials/kubernetes-basics/create-cluster/cluster-interactive.html +++ b/content/zh/docs/tutorials/kubernetes-basics/create-cluster/cluster-interactive.html @@ -40,7 +40,7 @@ weight: 20 <!-- <a class="btn btn-lg btn-success" href="/docs/tutorials/kubernetes-basics/deploy-app/deploy-intro/" role="button">Continue to Module 2<span class="btn__next">›</span></a> --> - <a class="btn btn-lg btn-success" href="/docs/tutorials/kubernetes-basics/deploy-app/deploy-intro/" role="button">继续阅读第二单元<span class="btn__next">›</span></a> + <a class="btn btn-lg btn-success" href="/zh/docs/tutorials/kubernetes-basics/deploy-app/deploy-intro/" role="button">继续阅读第二单元<span class="btn__next">›</span></a> </div> </div> diff --git a/content/zh/docs/tutorials/kubernetes-basics/deploy-app/deploy-interactive.html b/content/zh/docs/tutorials/kubernetes-basics/deploy-app/deploy-interactive.html index 96a9257ee5..4adb6a44a2 100644 --- a/content/zh/docs/tutorials/kubernetes-basics/deploy-app/deploy-interactive.html +++ b/content/zh/docs/tutorials/kubernetes-basics/deploy-app/deploy-interactive.html @@ -1,5 +1,5 @@ --- -title: 交互式教程 - 部署应用程序 +title: 交互式教程 - 部署应用 weight: 20 --- @@ -33,7 +33,7 @@ weight: 20 <div class="row"> <div class="col-md-12"> <!-- <a class="btn btn-lg btn-success" href="/docs/tutorials/kubernetes-basics/explore/explore-intro/" role="button">Continue to Module 3<span class="btn__next">›</span></a> --> - <a class="btn btn-lg btn-success" href="/docs/tutorials/kubernetes-basics/explore/explore-intro/" role="button">继续阅读第3单元<span class="btn__next">›</span></a> + <a class="btn btn-lg btn-success" href="/zh/docs/tutorials/kubernetes-basics/explore/explore-intro/" role="button">继续阅读第3单元<span class="btn__next">›</span></a> </div> </div> @@ -42,4 +42,4 @@ weight: 20 </div> </body> -</html> \ No newline at end of file +</html> diff --git a/content/zh/docs/tutorials/kubernetes-basics/explore/explore-interactive.html b/content/zh/docs/tutorials/kubernetes-basics/explore/explore-interactive.html index f5b2f96955..32f52502b4 100644 --- a/content/zh/docs/tutorials/kubernetes-basics/explore/explore-interactive.html +++ b/content/zh/docs/tutorials/kubernetes-basics/explore/explore-interactive.html @@ -1,5 +1,5 @@ --- -title: 交互式教程-探索您的应用程序 +title: 交互式教程-了解你的应用 weight: 20 --- @@ -42,7 +42,7 @@ weight: 20 </div> <div class="row"> <div class="col-md-12"> - <a class="btn btn-lg btn-success" href="/docs/tutorials/kubernetes-basics/expose/expose-intro/" role="button">Continue to Module 4<span class="btn__next">›</span></a> + <a class="btn btn-lg btn-success" href="/zh/docs/tutorials/kubernetes-basics/expose/expose-intro/" role="button">继续阅读第4单元<span class="btn__next">›</span></a> </div> </div> diff --git a/content/zh/docs/tutorials/kubernetes-basics/explore/explore-intro.html b/content/zh/docs/tutorials/kubernetes-basics/explore/explore-intro.html index c1d09f790d..eca0105bbe 100644 --- a/content/zh/docs/tutorials/kubernetes-basics/explore/explore-intro.html +++ b/content/zh/docs/tutorials/kubernetes-basics/explore/explore-intro.html @@ -210,7 +210,7 @@ weight: 10 <!-- <a class="btn btn-lg btn-success" href="/docs/tutorials/kubernetes-basics/explore/explore-interactive/" role="button">Start Interactive Tutorial <span class="btn__next">›</span></a> --> - <a class="btn btn-lg btn-success" href="/docs/tutorials/kubernetes-basics/explore/explore-interactive/" role="button"> 开始交互式教程 <span class="btn__next">›</span></a> + <a class="btn btn-lg btn-success" href="/zh/docs/tutorials/kubernetes-basics/explore/explore-interactive/" role="button"> 开始交互式教程 <span class="btn__next">›</span></a> </div> </div> diff --git a/content/zh/docs/tutorials/kubernetes-basics/expose/expose-interactive.html b/content/zh/docs/tutorials/kubernetes-basics/expose/expose-interactive.html index b4d6a795b8..55297633a7 100644 --- a/content/zh/docs/tutorials/kubernetes-basics/expose/expose-interactive.html +++ b/content/zh/docs/tutorials/kubernetes-basics/expose/expose-interactive.html @@ -1,5 +1,5 @@ --- -title: 交互式教程 - 发布您的应用程序 +title: 交互式教程 - 暴露你的应用 weight: 20 --- @@ -38,7 +38,7 @@ weight: 20 </div> <div class="row"> <div class="col-md-12"> - <a class="btn btn-lg btn-success" href="/docs/tutorials/kubernetes-basics/scale/scale-intro/" role="button">Continue to Module 5<span class="btn__next">›</span></a> + <a class="btn btn-lg btn-success" href="/zh/docs/tutorials/kubernetes-basics/scale/scale-intro/" role="button">继续阅读第5单元<span class="btn__next">›</span></a> </div> </div> diff --git a/content/zh/docs/tutorials/kubernetes-basics/expose/expose-intro.html b/content/zh/docs/tutorials/kubernetes-basics/expose/expose-intro.html index 8adf05965b..3806ef7f69 100644 --- a/content/zh/docs/tutorials/kubernetes-basics/expose/expose-intro.html +++ b/content/zh/docs/tutorials/kubernetes-basics/expose/expose-intro.html @@ -1,5 +1,6 @@ --- -title: Using a Service to Expose Your App +<!--title: Using a Service to Expose Your App--> +title: 使用 Service 暴露您的应用 weight: 10 --- @@ -17,42 +18,61 @@ weight: 10 <div class="row"> <div class="col-md-8"> - <h3>Objectives</h3> +<!-- <h3>Objectives</h3>--> + <h3>目标</h3> <ul> - <li>Learn about a Service in Kubernetes</li> - <li>Understand how labels and LabelSelector objects relate to a Service</li> - <li>Expose an application outside a Kubernetes cluster using a Service</li> +<!-- <li>Learn about a Service in Kubernetes</li>--> +<!-- <li>Understand how labels and LabelSelector objects relate to a Service</li>--> +<!-- <li>Expose an application outside a Kubernetes cluster using a Service</li>--> + <li>了解 Kubernetes 中的 Service </li> + <li>了解 标签(Label) 和 标签选择器(Label Selector) 对象如何与 Service 关联</li> + <li>在 Kubernetes 集群外用 Service 暴露应用</li> </ul> </div> <div class="col-md-8"> - <h3>Overview of Kubernetes Services</h3> +<!-- <h3>Overview of Kubernetes Services</h3>--> + <h3>Kubernetes Service 总览</h3> - <p>Kubernetes <a href="/docs/concepts/workloads/pods/pod-overview/">Pods</a> are mortal. Pods in fact have a <a href="/docs/concepts/workloads/pods/pod-lifecycle/">lifecycle</a>. When a worker node dies, the Pods running on the Node are also lost. A <a href="/docs/concepts/workloads/controllers/replicaset/">ReplicaSet</a> might then dynamically drive the cluster back to desired state via creation of new Pods to keep your application running. As another example, consider an image-processing backend with 3 replicas. Those replicas are exchangeable; the front-end system should not care about backend replicas or even if a Pod is lost and recreated. That said, each Pod in a Kubernetes cluster has a unique IP address, even Pods on the same Node, so there needs to be a way of automatically reconciling changes among Pods so that your applications continue to function.</p> +<!-- <p>Kubernetes <a href="/docs/concepts/workloads/pods/pod-overview/">Pods</a> are mortal. Pods in fact have a <a href="/docs/concepts/workloads/pods/pod-lifecycle/">lifecycle</a>. When a worker node dies, the Pods running on the Node are also lost. A <a href="/docs/concepts/workloads/controllers/replicaset/">ReplicaSet</a> might then dynamically drive the cluster back to desired state via creation of new Pods to keep your application running. As another example, consider an image-processing backend with 3 replicas. Those replicas are exchangeable; the front-end system should not care about backend replicas or even if a Pod is lost and recreated. That said, each Pod in a Kubernetes cluster has a unique IP address, even Pods on the same Node, so there needs to be a way of automatically reconciling changes among Pods so that your applications continue to function.</p>--> + <p> Kubernetes <a href="/zh/docs/concepts/workloads/pods/pod-overview/">Pod</a> 是转瞬即逝的。 Pod 实际上拥有 <a href="/zh/docs/concepts/workloads/pods/pod-lifecycle/">生命周期</a>。 当一个工作 Node 挂掉后, 在 Node 上运行的 Pod 也会消亡。 <a href="/zh/docs/concepts/workloads/controllers/replicaset/">ReplicaSet</a> 会自动地通过创建新的 Pod 驱动集群回到目标状态，以保证应用程序正常运行。 换一个例子，考虑一个具有3个副本数的用作图像处理的后端程序。这些副本是可替换的; 前端系统不应该关心后端副本，即使 Pod 丢失或重新创建。也就是说，Kubernetes 集群中的每个 Pod (即使是在同一个 Node 上的 Pod )都有一个惟一的 IP 地址，因此需要一种方法自动协调 Pod 之间的变更，以便应用程序保持运行。</p> - <p>A Service in Kubernetes is an abstraction which defines a logical set of Pods and a policy by which to access them. Services enable a loose coupling between dependent Pods. A Service is defined using YAML <a href="/docs/concepts/configuration/overview/#general-configuration-tips">(preferred)</a> or JSON, like all Kubernetes objects. The set of Pods targeted by a Service is usually determined by a <i>LabelSelector</i> (see below for why you might want a Service without including <code>selector</code> in the spec).</p> +<!-- <p>A Service in Kubernetes is an abstraction which defines a logical set of Pods and a policy by which to access them. Services enable a loose coupling between dependent Pods. A Service is defined using YAML <a href="/docs/concepts/configuration/overview/#general-configuration-tips">(preferred)</a> or JSON, like all Kubernetes objects. The set of Pods targeted by a Service is usually determined by a <i>LabelSelector</i> (see below for why you might want a Service without including <code>selector</code> in the spec).</p>--> + <p> Kubernetes 中的服务(Service)是一种抽象概念，它定义了 Pod 的逻辑集和访问 Pod 的协议。Service 使从属 Pod 之间的松耦合成为可能。 和其他 Kubernetes 对象一样, Service 用 YAML <a href="/zh/docs/concepts/configuration/overview/#general-configuration-tips">(更推荐)</a> 或者 JSON 来定义. Service 下的一组 Pod 通常由 <i>LabelSelector</i> (请参阅下面的说明为什么您可能想要一个 spec 中不包含<code>selector</code>的服务)来标记。</p> - <p>Although each Pod has a unique IP address, those IPs are not exposed outside the cluster without a Service. Services allow your applications to receive traffic. Services can be exposed in different ways by specifying a <code>type</code> in the ServiceSpec:</p> +<!-- <p>Although each Pod has a unique IP address, those IPs are not exposed outside the cluster without a Service. Services allow your applications to receive traffic. Services can be exposed in different ways by specifying a <code>type</code> in the ServiceSpec:</p>--> + <p>尽管每个 Pod 都有一个唯一的 IP 地址，但是如果没有 Service ，这些 IP 不会暴露在群集外部。Service 允许您的应用程序接收流量。Service 也可以用在 ServiceSpec 标记<code>type</code>的方式暴露</p> <ul> - <li><i>ClusterIP</i> (default) - Exposes the Service on an internal IP in the cluster. This type makes the Service only reachable from within the cluster.</li> - <li><i>NodePort</i> - Exposes the Service on the same port of each selected Node in the cluster using NAT. Makes a Service accessible from outside the cluster using <code><NodeIP>:<NodePort></code>. Superset of ClusterIP.</li> - <li><i>LoadBalancer</i> - Creates an external load balancer in the current cloud (if supported) and assigns a fixed, external IP to the Service. Superset of NodePort.</li> - <li><i>ExternalName</i> - Exposes the Service using an arbitrary name (specified by <code>externalName</code> in the spec) by returning a CNAME record with the name. No proxy is used. This type requires v1.7 or higher of <code>kube-dns</code>.</li> +<!-- <li><i>ClusterIP</i> (default) - Exposes the Service on an internal IP in the cluster. This type makes the Service only reachable from within the cluster.</li>--> +<!-- <li><i>NodePort</i> - Exposes the Service on the same port of each selected Node in the cluster using NAT. Makes a Service accessible from outside the cluster using <code><NodeIP>:<NodePort></code>. Superset of ClusterIP.</li>--> +<!-- <li><i>LoadBalancer</i> - Creates an external load balancer in the current cloud (if supported) and assigns a fixed, external IP to the Service. Superset of NodePort.</li>--> +<!-- <li><i>ExternalName</i> - Exposes the Service using an arbitrary name (specified by <code>externalName</code> in the spec) by returning a CNAME record with the name. No proxy is used. This type requires v1.7 or higher of <code>kube-dns</code>.</li>--> + <li><i>ClusterIP</i> (默认) - 在集群的内部 IP 上公开 Service 。这种类型使得 Service 只能从集群内访问。</li> + <li><i>NodePort</i> - 使用 NAT 在集群中每个选定 Node 的相同端口上公开 Service 。使用<code><NodeIP>:<NodePort></code> 从集群外部访问 Service。是 ClusterIP 的超集。</li> + <li><i>LoadBalancer</i> - 在当前云中创建一个外部负载均衡器(如果支持的话)，并为 Service 分配一个固定的外部IP。是 NodePort 的超集。</li> + <li><i>ExternalName</i> - 通过返回带有该名称的 CNAME 记录，使用任意名称(由 spec 中的<code>externalName</code>指定)公开 Service。不使用代理。这种类型需要<code>kube-dns</code>的v1.7或更高版本。</li> </ul> - <p>More information about the different types of Services can be found in the <a href="/docs/tutorials/services/source-ip/">Using Source IP</a> tutorial. Also see <a href="/docs/concepts/services-networking/connect-applications-service">Connecting Applications with Services</a>.</p> - <p>Additionally, note that there are some use cases with Services that involve not defining <code>selector</code> in the spec. A Service created without <code>selector</code> will also not create the corresponding Endpoints object. This allows users to manually map a Service to specific endpoints. Another possibility why there may be no selector is you are strictly using <code>type: ExternalName</code>.</p> +<!-- <p>More information about the different types of Services can be found in the <a href="/docs/tutorials/services/source-ip/">Using Source IP</a> tutorial. Also see <a href="/docs/concepts/services-networking/connect-applications-service">Connecting Applications with Services</a>.</p>--> + <p>更多关于不同 Service 类型的信息可以在<a href="/zh/docs/tutorials/services/source-ip/">使用源 IP </a> 教程。 也请参阅 <a href="/zh/docs/concepts/services-networking/connect-applications-service">连接应用程序和 Service </a>。</p> +<!-- <p>Additionally, note that there are some use cases with Services that involve not defining <code>selector</code> in the spec. A Service created without <code>selector</code> will also not create the corresponding Endpoints object. This allows users to manually map a Service to specific endpoints. Another possibility why there may be no selector is you are strictly using <code>type: ExternalName</code>.</p>--> + <p>另外，需要注意的是有一些 Service 的用例没有在 spec 中定义<code>selector</code>。 一个没有<code>selector</code>创建的 Service 也不会创建相应的端点对象。这允许用户手动将服务映射到特定的端点。没有 selector 的另一种可能是您严格使用<code>type: ExternalName</code>来标记。</p> </div> <div class="col-md-4"> <div class="content__box content__box_lined"> - <h3>Summary</h3> +<!-- <h3>Summary</h3>--> + <h3>总结</h3> <ul> - <li>Exposing Pods to external traffic</li> - <li>Load balancing traffic across multiple Pods</li> - <li>Using labels</li> +<!-- <li>Exposing Pods to external traffic</li>--> +<!-- <li>Load balancing traffic across multiple Pods</li>--> +<!-- <li>Using labels</li>--> + <li>将 Pod 暴露给外部通信</li> + <li>跨多个 Pod 的负载均衡</li> + <li>使用标签(Label)</li> </ul> </div> <div class="content__box content__box_fill"> - <p><i>A Kubernetes Service is an abstraction layer which defines a logical set of Pods and enables external traffic exposure, load balancing and service discovery for those Pods.</i></p> +<!-- <p><i>A Kubernetes Service is an abstraction layer which defines a logical set of Pods and enables external traffic exposure, load balancing and service discovery for those Pods.</i></p>--> + <p><i>Kubernetes 的 Service 是一个抽象层，它定义了一组 Pod 的逻辑集，并为这些 Pod 支持外部流量暴露、负载平衡和服务发现。</i></p> </div> </div> </div> @@ -60,7 +80,7 @@ weight: 10 <div class="row"> <div class="col-md-8"> - <h3>Services and Labels</h3> + <h3>Service 和 Label</h3> </div> </div> @@ -72,18 +92,24 @@ weight: 10 <div class="row"> <div class="col-md-8"> - <p>A Service routes traffic across a set of Pods. Services are the abstraction that allow pods to die and replicate in Kubernetes without impacting your application. Discovery and routing among dependent Pods (such as the frontend and backend components in an application) is handled by Kubernetes Services.</p> - <p>Services match a set of Pods using <a href="/docs/concepts/overview/working-with-objects/labels">labels and selectors</a>, a grouping primitive that allows logical operation on objects in Kubernetes. Labels are key/value pairs attached to objects and can be used in any number of ways:</p> +<!-- <p>A Service routes traffic across a set of Pods. Services are the abstraction that allow pods to die and replicate in Kubernetes without impacting your application. Discovery and routing among dependent Pods (such as the frontend and backend components in an application) is handled by Kubernetes Services.</p>--> + <p>Service 通过一组 Pod 路由通信。Service 是一种抽象，它允许 Pod 死亡并在 Kubernetes 中复制，而不会影响应用程序。在依赖的 Pod (如应用程序中的前端和后端组件)之间进行发现和路由是由Kubernetes Service 处理的。</p> +<!-- <p>Services match a set of Pods using <a href="/docs/concepts/overview/working-with-objects/labels">labels and selectors</a>, a grouping primitive that allows logical operation on objects in Kubernetes. Labels are key/value pairs attached to objects and can be used in any number of ways:</p>--> + <p>Service 匹配一组 Pod 是使用 <a href="/zh/docs/concepts/overview/working-with-objects/labels">标签(Label)和选择器(Selector)</a>, 它们是允许对 Kubernetes 中的对象进行逻辑操作的一种分组原语。标签(Label)是附加在对象上的键/值对，可以以多种方式使用:</p> <ul> - <li>Designate objects for development, test, and production</li> - <li>Embed version tags</li> - <li>Classify an object using tags</li> +<!-- <li>Designate objects for development, test, and production</li>--> +<!-- <li>Embed version tags</li>--> +<!-- <li>Classify an object using tags</li>--> + <li>指定用于开发，测试和生产的对象</li> + <li>嵌入版本标签</li> + <li>使用 Label 将对象进行分类</li> </ul> </div> <div class="col-md-4"> <div class="content__box content__box_fill"> - <p><i>You can create a Service at the same time you create a Deployment by using<br><code>--expose</code> in kubectl.</i></p> +<!-- <p><i>You can create a Service at the same time you create a Deployment by using<br><code>--expose</code> in kubectl.</i></p>--> + <p><i>你也可以在创建 Deployment 的同时用 <code>--expose</code>创建一个 Service 。</i></p> </div> </div> </div> @@ -98,13 +124,15 @@ weight: 10 <br> <div class="row"> <div class="col-md-8"> - <p>Labels can be attached to objects at creation time or later on. They can be modified at any time. Let's expose our application now using a Service and apply some labels.</p> +<!-- <p>Labels can be attached to objects at creation time or later on. They can be modified at any time. Let's expose our application now using a Service and apply some labels.</p>--> + <p> 标签(Label)可以在创建时或之后附加到对象上。他们可以随时被修改。现在使用 Service 发布我们的应用程序并添加一些 Label 。</p> </div> </div> <br> <div class="row"> <div class="col-md-12"> - <a class="btn btn-lg btn-success" href="/docs/tutorials/kubernetes-basics/expose/expose-interactive/" role="button">Start Interactive Tutorial<span class="btn__next">›</span></a> +<!-- <a class="btn btn-lg btn-success" href="/docs/tutorials/kubernetes-basics/expose/expose-interactive/" role="button">Start Interactive Tutorial<span class="btn__next">›</span></a>--> + <a class="btn btn-lg btn-success" href="/zh/docs/tutorials/kubernetes-basics/expose/expose-interactive/" role="button">开始交互式教程<span class="btn__next">›</span></a> </div> </div> </main> diff --git a/content/zh/docs/tutorials/kubernetes-basics/scale/_index.md b/content/zh/docs/tutorials/kubernetes-basics/scale/_index.md index fedbce58bb..d13662df44 100644 --- a/content/zh/docs/tutorials/kubernetes-basics/scale/_index.md +++ b/content/zh/docs/tutorials/kubernetes-basics/scale/_index.md @@ -1,4 +1,4 @@ --- -title: 伸缩您的应用 +title: 缩放你的应用 weight: 50 --- diff --git a/content/zh/docs/tutorials/kubernetes-basics/scale/scale-interactive.html b/content/zh/docs/tutorials/kubernetes-basics/scale/scale-interactive.html index 489d3dfe25..d612cdfce4 100644 --- a/content/zh/docs/tutorials/kubernetes-basics/scale/scale-interactive.html +++ b/content/zh/docs/tutorials/kubernetes-basics/scale/scale-interactive.html @@ -1,5 +1,5 @@ --- -title: 交互教程 - 缩放你的应用程序 +title: 交互教程 - 缩放你的应用 weight: 20 --- <!-- @@ -34,7 +34,7 @@ weight: 20 </div> <div class="row"> <div class="col-md-12"> - <a class="btn btn-lg btn-success" href="/docs/tutorials/kubernetes-basics/update/update-intro/" role="button"><!--Continue to Module 6-->继续参阅第6单元<span class="btn__next">›</span></a> + <a class="btn btn-lg btn-success" href="/zh/docs/tutorials/kubernetes-basics/update/update-intro/" role="button"><!--Continue to Module 6-->继续参阅第6单元<span class="btn__next">›</span></a> </div> </div> diff --git a/content/zh/docs/tutorials/kubernetes-basics/scale/scale-intro.html b/content/zh/docs/tutorials/kubernetes-basics/scale/scale-intro.html index d019e222f7..73151bdcb8 100644 --- a/content/zh/docs/tutorials/kubernetes-basics/scale/scale-intro.html +++ b/content/zh/docs/tutorials/kubernetes-basics/scale/scale-intro.html @@ -126,8 +126,8 @@ weight: 10 <div class="row"> <div class="col-md-12"> - <!-- <a class="btn btn-lg btn-success" href="/docs/tutorials/kubernetes-basics/scale-interactive/" role="button">Start Interactive Tutorial <span class="btn__next">›</span></a> --> - <a class="btn btn-lg btn-success" href="/docs/tutorials/kubernetes-basics/scale-interactive/" role="button">开始互动教程 <span class="btn__next">›</span></a> + <!-- <a class="btn btn-lg btn-success" href="/docs/tutorials/kubernetes-basics/scale/scale-interactive/" role="button">Start Interactive Tutorial <span class="btn__next">›</span></a> --> + <a class="btn btn-lg btn-success" href="/zh/docs/tutorials/kubernetes-basics/scale/scale-interactive/" role="button">开始互动教程 <span class="btn__next">›</span></a> </div> </div> diff --git a/content/zh/docs/tutorials/kubernetes-basics/update/update-interactive.html b/content/zh/docs/tutorials/kubernetes-basics/update/update-interactive.html index c917534b56..0f9ea050c3 100644 --- a/content/zh/docs/tutorials/kubernetes-basics/update/update-interactive.html +++ b/content/zh/docs/tutorials/kubernetes-basics/update/update-interactive.html @@ -1,5 +1,5 @@ --- -title: 交互式教程 - 更新应用 +title: 交互式教程 - 更新你的应用 weight: 20 --- <!-- @@ -32,7 +32,7 @@ weight: 20 </div> <div class="row"> <div class="col-md-12"> - <a class="btn btn-lg btn-success" href="/docs/tutorials/kubernetes-basics/" role="button">回到 Kubernetes 的基础<span class="btn__next">›</span></a> + <a class="btn btn-lg btn-success" href="/zh/docs/tutorials/kubernetes-basics/" role="button">回到 Kubernetes 的基础<span class="btn__next">›</span></a> </div> </div> </main> diff --git a/content/zh/docs/tutorials/kubernetes-basics/update/update-intro.html b/content/zh/docs/tutorials/kubernetes-basics/update/update-intro.html index 3a3dc16967..e4dab0b07c 100644 --- a/content/zh/docs/tutorials/kubernetes-basics/update/update-intro.html +++ b/content/zh/docs/tutorials/kubernetes-basics/update/update-intro.html @@ -97,19 +97,19 @@ weight: 10 <li data-target="#myCarousel" data-slide-to="3"></li> </ol> <div class="carousel-inner" role="listbox"> - <div class="item active"> + <div class="item carousel-item active"> <img src="/docs/tutorials/kubernetes-basics/public/images/module_06_rollingupdates1.svg" > </div> - <div class="item"> + <div class="item carousel-item"> <img src="/docs/tutorials/kubernetes-basics/public/images/module_06_rollingupdates2.svg"> </div> - <div class="item"> + <div class="item carousel-item"> <img src="/docs/tutorials/kubernetes-basics/public/images/module_06_rollingupdates3.svg"> </div> - <div class="item"> + <div class="item carousel-item"> <img src="/docs/tutorials/kubernetes-basics/public/images/module_06_rollingupdates4.svg"> </div> </div> @@ -177,7 +177,7 @@ weight: 10 <!-- <a class="btn btn-lg btn-success" href="/docs/tutorials/kubernetes-basics/update/update-interactive/" role="button">Start Interactive Tutorial <span class="btn__next">›</span></a> --> - <a class="btn btn-lg btn-success" href="/docs/tutorials/kubernetes-basics/update/update-interactive/" role="button">启动交互教程<span class="btn__next">›</span></a> + <a class="btn btn-lg btn-success" href="/zh/docs/tutorials/kubernetes-basics/update/update-interactive/" role="button">启动交互教程<span class="btn__next">›</span></a> </div> </div> diff --git a/content/zh/docs/tutorials/services/source-ip.md b/content/zh/docs/tutorials/services/source-ip.md index d44eb358a0..bd0fdc9629 100644 --- a/content/zh/docs/tutorials/services/source-ip.md +++ b/content/zh/docs/tutorials/services/source-ip.md @@ -150,7 +150,7 @@ service/nodeport exposed ```console NODEPORT=$(kubectl get -o jsonpath="{.spec.ports[0].nodePort}" services nodeport) -NODES=$(kubectl get nodes -o jsonpath='{ $.items[*].status.addresses[?(@.type=="ExternalIP")].address }') +NODES=$(kubectl get nodes -o jsonpath='{ $.items[*].status.addresses[?(@.type=="InternalIP")].address }') ``` 如果你的集群运行在一个云服务上，你可能需要为上面报告的 `nodes:nodeport` 开启一条防火墙规则。 diff --git a/content/zh/docs/tutorials/stateful-application/basic-stateful-set.md b/content/zh/docs/tutorials/stateful-application/basic-stateful-set.md index 868c13def6..7ba6a1bb0e 100644 --- a/content/zh/docs/tutorials/stateful-application/basic-stateful-set.md +++ b/content/zh/docs/tutorials/stateful-application/basic-stateful-set.md @@ -867,12 +867,12 @@ Patch the StatefulSet to decrement the partition. 请注意，虽然更新策略是 `RollingUpdate`，StatefulSet 控制器还是会使用原始的容器恢复 Pod。这是因为 Pod 的序号比 `updateStrategy` 指定的 `partition` 更小。 -#### 灰度扩容 +#### 灰度发布 -你可以通过减少 [上文](#分段更新)指定的 `partition` 来进行灰度扩容，以此来测试你的程序的改动。 +你可以通过减少 [上文](#分段更新)指定的 `partition` 来进行灰度发布，以此来测试你的程序的改动。 -Patch StatefulSet 来减少分区。 +通过 patch 命令修改 StatefulSet 来减少分区。 ```shell kubectl patch statefulset web -p '{"spec":{"updateStrategy":{"type":"RollingUpdate","rollingUpdate":{"partition":2}}}}' @@ -977,9 +977,9 @@ The partition is currently set to `2`. Set the partition to `0`. `web-1` 被按照原来的配置恢复，因为 Pod 的序号小于分区。当指定了分区时，如果更新了 StatefulSet 的 `.spec.template`，则所有序号大于或等于分区的 Pod 都将被更新。如果一个序号小于分区的 Pod 被删除或者终止，它将被按照原来的配置恢复。 -#### 分阶段的扩容 +#### 分阶段的发布 -你可以使用类似[灰度扩容](#灰度扩容)的方法执行一次分阶段的扩容（例如一次线性的、等比的或者指数形式的扩容）。要执行一次分阶段的扩容，你需要设置 `partition` 为希望控制器暂停更新的序号。 +你可以使用类似[灰度发布](#灰度发布)的方法执行一次分阶段的发布（例如一次线性的、等比的或者指数形式的发布）。要执行一次分阶段的发布，你需要设置 `partition` 为希望控制器暂停更新的序号。 分区当前为`2`。请将分区设置为`0`。 diff --git a/content/zh/docs/tutorials/stateful-application/mysql-wordpress-persistent-volume.md b/content/zh/docs/tutorials/stateful-application/mysql-wordpress-persistent-volume.md index e5e53815d9..81922142af 100644 --- a/content/zh/docs/tutorials/stateful-application/mysql-wordpress-persistent-volume.md +++ b/content/zh/docs/tutorials/stateful-application/mysql-wordpress-persistent-volume.md @@ -1,15 +1,23 @@ --- title: 示例：使用 Persistent Volumes 部署 WordPress 和 MySQL -reviewers: -- ahmetb content_type: tutorial weight: 20 card: name: tutorials weight: 40 - title: "Stateful 示例: Wordpress with Persistent Volumes" + title: "有状态应用示例: 带持久卷的 Wordpress" --- - +<!-- +title: "Example: Deploying WordPress and MySQL with Persistent Volumes" +reviewers: +- ahmetb +content_type: tutorial +weight: 20 +card: + name: tutorials + weight: 40 + title: "Stateful Example: Wordpress with Persistent Volumes" +--> <!-- overview --> <!-- diff --git a/content/zh/docs/tutorials/stateless-application/guestbook.md b/content/zh/docs/tutorials/stateless-application/guestbook.md index 062f9957c9..260867dbe3 100644 --- a/content/zh/docs/tutorials/stateless-application/guestbook.md +++ b/content/zh/docs/tutorials/stateless-application/guestbook.md @@ -1,19 +1,23 @@ --- title: "示例：使用 Redis 部署 PHP 留言板应用程序" -reviewers: -- ahmetb content_type: tutorial weight: 20 +card: + name: tutorials + weight: 30 + title: "无状态应用示例：基于 Redis 的 PHP Guestbook" --- <!-- ---- title: "Example: Deploying PHP Guestbook application with Redis" reviewers: - ahmetb content_type: tutorial weight: 20 ---- +card: + name: tutorials + weight: 30 + title: "Stateless Example: PHP Guestbook with Redis" --> <!-- overview --> diff --git a/content/zh/examples/admin/sched/my-scheduler.yaml b/content/zh/examples/admin/sched/my-scheduler.yaml index a2ccc08da5..800595862b 100644 --- a/content/zh/examples/admin/sched/my-scheduler.yaml +++ b/content/zh/examples/admin/sched/my-scheduler.yaml @@ -17,6 +17,19 @@ roleRef: name: system:kube-scheduler apiGroup: rbac.authorization.k8s.io --- +apiVersion: rbac.authorization.k8s.io/v1 +kind: ClusterRoleBinding +metadata: + name: my-scheduler-as-volume-scheduler +subjects: +- kind: ServiceAccount + name: my-scheduler + namespace: kube-system +roleRef: + kind: ClusterRole + name: system:volume-scheduler + apiGroup: rbac.authorization.k8s.io +--- apiVersion: apps/v1 kind: Deployment metadata: diff --git a/content/zh/examples/application/deployment-retainkeys.yaml b/content/zh/examples/application/deployment-retainkeys.yaml new file mode 100644 index 0000000000..b5e04f0cc1 --- /dev/null +++ b/content/zh/examples/application/deployment-retainkeys.yaml @@ -0,0 +1,19 @@ +apiVersion: apps/v1 # for versions before 1.9.0 use apps/v1beta2 +kind: Deployment +metadata: + name: retainkeys-demo +spec: + selector: + matchLabels: + app: nginx + strategy: + rollingUpdate: + maxSurge: 30% + template: + metadata: + labels: + app: nginx + spec: + containers: + - name: retainkeys-demo-ctr + image: nginx diff --git a/content/zh/examples/controllers/fluentd-daemonset-update.yaml b/content/zh/examples/controllers/fluentd-daemonset-update.yaml new file mode 100644 index 0000000000..dcf08d4fc9 --- /dev/null +++ b/content/zh/examples/controllers/fluentd-daemonset-update.yaml @@ -0,0 +1,48 @@ +apiVersion: apps/v1 +kind: DaemonSet +metadata: + name: fluentd-elasticsearch + namespace: kube-system + labels: + k8s-app: fluentd-logging +spec: + selector: + matchLabels: + name: fluentd-elasticsearch + updateStrategy: + type: RollingUpdate + rollingUpdate: + maxUnavailable: 1 + template: + metadata: + labels: + name: fluentd-elasticsearch + spec: + tolerations: + # this toleration is to have the daemonset runnable on master nodes + # remove it if your masters can't run pods + - key: node-role.kubernetes.io/master + effect: NoSchedule + containers: + - name: fluentd-elasticsearch + image: quay.io/fluentd_elasticsearch/fluentd:v2.5.2 + resources: + limits: + memory: 200Mi + requests: + cpu: 100m + memory: 200Mi + volumeMounts: + - name: varlog + mountPath: /var/log + - name: varlibdockercontainers + mountPath: /var/lib/docker/containers + readOnly: true + terminationGracePeriodSeconds: 30 + volumes: + - name: varlog + hostPath: + path: /var/log + - name: varlibdockercontainers + hostPath: + path: /var/lib/docker/containers diff --git a/content/zh/examples/controllers/fluentd-daemonset.yaml b/content/zh/examples/controllers/fluentd-daemonset.yaml new file mode 100644 index 0000000000..0e1e7d3345 --- /dev/null +++ b/content/zh/examples/controllers/fluentd-daemonset.yaml @@ -0,0 +1,42 @@ +apiVersion: apps/v1 +kind: DaemonSet +metadata: + name: fluentd-elasticsearch + namespace: kube-system + labels: + k8s-app: fluentd-logging +spec: + selector: + matchLabels: + name: fluentd-elasticsearch + updateStrategy: + type: RollingUpdate + rollingUpdate: + maxUnavailable: 1 + template: + metadata: + labels: + name: fluentd-elasticsearch + spec: + tolerations: + # this toleration is to have the daemonset runnable on master nodes + # remove it if your masters can't run pods + - key: node-role.kubernetes.io/master + effect: NoSchedule + containers: + - name: fluentd-elasticsearch + image: quay.io/fluentd_elasticsearch/fluentd:v2.5.2 + volumeMounts: + - name: varlog + mountPath: /var/log + - name: varlibdockercontainers + mountPath: /var/lib/docker/containers + readOnly: true + terminationGracePeriodSeconds: 30 + volumes: + - name: varlog + hostPath: + path: /var/log + - name: varlibdockercontainers + hostPath: + path: /var/lib/docker/containers diff --git a/content/zh/examples/examples_test.go b/content/zh/examples/examples_test.go index 7c9664b64c..9e81fc6e97 100644 --- a/content/zh/examples/examples_test.go +++ b/content/zh/examples/examples_test.go @@ -28,34 +28,105 @@ import ( "testing" "k8s.io/apimachinery/pkg/runtime" + "k8s.io/apimachinery/pkg/runtime/schema" "k8s.io/apimachinery/pkg/types" "k8s.io/apimachinery/pkg/util/validation/field" "k8s.io/apimachinery/pkg/util/yaml" - utilfeature "k8s.io/apiserver/pkg/util/feature" + // "k8s.io/apiserver/pkg/util/feature" "k8s.io/kubernetes/pkg/api/legacyscheme" - "k8s.io/kubernetes/pkg/api/testapi" + "k8s.io/kubernetes/pkg/apis/apps" apps_validation "k8s.io/kubernetes/pkg/apis/apps/validation" + "k8s.io/kubernetes/pkg/apis/autoscaling" autoscaling_validation "k8s.io/kubernetes/pkg/apis/autoscaling/validation" + "k8s.io/kubernetes/pkg/apis/batch" batch_validation "k8s.io/kubernetes/pkg/apis/batch/validation" + api "k8s.io/kubernetes/pkg/apis/core" "k8s.io/kubernetes/pkg/apis/core/validation" - "k8s.io/kubernetes/pkg/apis/extensions" - ext_validation "k8s.io/kubernetes/pkg/apis/extensions/validation" + + "k8s.io/kubernetes/pkg/apis/networking" + networking_validation "k8s.io/kubernetes/pkg/apis/networking/validation" + "k8s.io/kubernetes/pkg/apis/policy" policy_validation "k8s.io/kubernetes/pkg/apis/policy/validation" + "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" + "k8s.io/kubernetes/pkg/capabilities" "k8s.io/kubernetes/pkg/registry/batch/job" + + // initialize install packages + _ "k8s.io/kubernetes/pkg/apis/apps/install" + _ "k8s.io/kubernetes/pkg/apis/autoscaling/install" + _ "k8s.io/kubernetes/pkg/apis/batch/install" + _ "k8s.io/kubernetes/pkg/apis/core/install" + _ "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" ) +var ( + Groups map[string]TestGroup + serializer runtime.SerializerInfo +) + +// TestGroup contains GroupVersion to uniquely identify the API +type TestGroup struct { + externalGroupVersion schema.GroupVersion +} + +// GroupVersion makes copy of schema.GroupVersion +func (g TestGroup) GroupVersion() *schema.GroupVersion { + copyOfGroupVersion := g.externalGroupVersion + return ©OfGroupVersion +} + +// Codec returns the codec for the API version to test against +func (g TestGroup) Codec() runtime.Codec { + if serializer.Serializer == nil { + return legacyscheme.Codecs.LegacyCodec(g.externalGroupVersion) + } + return legacyscheme.Codecs.CodecForVersions(serializer.Serializer, legacyscheme.Codecs.UniversalDeserializer(), schema.GroupVersions{g.externalGroupVersion}, nil) +} + +func initGroups() { + Groups = make(map[string]TestGroup) + + groupNames := []string{ + api.GroupName, + apps.GroupName, + autoscaling.GroupName, + batch.GroupName, + networking.GroupName, + policy.GroupName, + rbac.GroupName, + settings.GroupName, + storage.GroupName, + } + + for _, gn := range groupNames { + versions := legacyscheme.Scheme.PrioritizedVersionsForGroup(gn) + Groups[gn] = TestGroup{ + externalGroupVersion: schema.GroupVersion{ + Group: gn, + Version: versions[0].Version, + }, + } + } +} + func getCodecForObject(obj runtime.Object) (runtime.Codec, error) { kinds, _, err := legacyscheme.Scheme.ObjectKinds(obj) if err != nil { @@ -63,7 +134,7 @@ func getCodecForObject(obj runtime.Object) (runtime.Codec, error) { } kind := kinds[0] - for _, group := range testapi.Groups { + for _, group := range Groups { if group.GroupVersion().Group != kind.Group { continue } @@ -85,7 +156,7 @@ func getCodecForObject(obj runtime.Object) (runtime.Codec, error) { func validateObject(obj runtime.Object) (errors field.ErrorList) { // Enable CustomPodDNS for testing - utilfeature.DefaultFeatureGate.Set("CustomPodDNS=true") + // feature.DefaultFeatureGate.Set("CustomPodDNS=true") switch t := obj.(type) { case *api.ConfigMap: if t.Namespace == "" { @@ -96,7 +167,7 @@ func validateObject(obj runtime.Object) (errors field.ErrorList) { if t.Namespace == "" { t.Namespace = api.NamespaceDefault } - errors = validation.ValidateEndpoints(t) + errors = validation.ValidateEndpointsCreate(t) case *api.LimitRange: if t.Namespace == "" { t.Namespace = api.NamespaceDefault @@ -115,7 +186,10 @@ func validateObject(obj runtime.Object) (errors field.ErrorList) { if t.Namespace == "" { t.Namespace = api.NamespaceDefault } - errors = validation.ValidatePod(t) + opts := validation.PodValidationOptions{ + AllowMultipleHugePageResources: true, + } + errors = validation.ValidatePod(t, opts) case *api.PodList: for i := range t.Items { errors = append(errors, validateObject(&t.Items[i])...) @@ -148,7 +222,7 @@ func validateObject(obj runtime.Object) (errors field.ErrorList) { if t.Namespace == "" { t.Namespace = api.NamespaceDefault } - errors = validation.ValidateService(t) + errors = validation.ValidateService(t, true) case *api.ServiceAccount: if t.Namespace == "" { t.Namespace = api.NamespaceDefault @@ -189,11 +263,15 @@ func validateObject(obj runtime.Object) (errors field.ErrorList) { t.Namespace = api.NamespaceDefault } errors = apps_validation.ValidateDeployment(t) - case *extensions.Ingress: + case *networking.Ingress: if t.Namespace == "" { t.Namespace = api.NamespaceDefault } - errors = ext_validation.ValidateIngress(t) + gv := schema.GroupVersion{ + Group: networking.GroupName, + Version: legacyscheme.Scheme.PrioritizedVersionsForGroup(networking.GroupName)[0].Version, + } + errors = networking_validation.ValidateIngressCreate(t, gv) case *policy.PodSecurityPolicy: errors = policy_validation.ValidatePodSecurityPolicy(t) case *apps.ReplicaSet: @@ -206,6 +284,11 @@ func validateObject(obj runtime.Object) (errors field.ErrorList) { t.Namespace = api.NamespaceDefault } errors = batch_validation.ValidateCronJob(t) + case *networking.NetworkPolicy: + if t.Namespace == "" { + t.Namespace = api.NamespaceDefault + } + errors = networking_validation.ValidateNetworkPolicy(t) case *policy.PodDisruptionBudget: if t.Namespace == "" { t.Namespace = api.NamespaceDefault @@ -247,10 +330,6 @@ func walkConfigFiles(inDir string, t *testing.T, fn func(name, path string, data if err != nil { return err } - // workaround for Jekyllr limit - if bytes.HasPrefix(data, []byte("---\n")) { - return fmt.Errorf("YAML file cannot start with \"---\", please remove the first line") - } name := strings.TrimSuffix(file, ext) var docs [][]byte @@ -286,11 +365,14 @@ func walkConfigFiles(inDir string, t *testing.T, fn func(name, path string, data } func TestExampleObjectSchemas(t *testing.T) { + initGroups() + // Please help maintain the alphabeta order in the map cases := map[string]map[string][]runtime.Object{ "admin": { - "namespace-dev": {&api.Namespace{}}, - "namespace-prod": {&api.Namespace{}}, + "namespace-dev": {&api.Namespace{}}, + "namespace-prod": {&api.Namespace{}}, + "snowflake-deployment": {&apps.Deployment{}}, }, "admin/cloud": { "ccm-example": {&api.ServiceAccount{}, &rbac.ClusterRoleBinding{}, &apps.DaemonSet{}}, @@ -298,6 +380,7 @@ func TestExampleObjectSchemas(t *testing.T) { "admin/dns": { "busybox": {&api.Pod{}}, "dns-horizontal-autoscaler": {&apps.Deployment{}}, + "dnsutils": {&api.Pod{}}, }, "admin/logging": { "fluentd-sidecar-config": {&api.ConfigMap{}}, @@ -343,21 +426,23 @@ func TestExampleObjectSchemas(t *testing.T) { "storagelimits": {&api.LimitRange{}}, }, "admin/sched": { - "my-scheduler": {&api.ServiceAccount{}, &rbac.ClusterRoleBinding{}, &apps.Deployment{}}, + "my-scheduler": {&api.ServiceAccount{}, &rbac.ClusterRoleBinding{}, &rbac.ClusterRoleBinding{}, &apps.Deployment{}}, "pod1": {&api.Pod{}}, "pod2": {&api.Pod{}}, "pod3": {&api.Pod{}}, }, "application": { - "deployment": {&apps.Deployment{}}, - "deployment-patch": {&apps.Deployment{}}, - "deployment-scale": {&apps.Deployment{}}, - "deployment-update": {&apps.Deployment{}}, - "nginx-app": {&api.Service{}, &apps.Deployment{}}, - "nginx-with-request": {&apps.Deployment{}}, - "shell-demo": {&api.Pod{}}, - "simple_deployment": {&apps.Deployment{}}, - "update_deployment": {&apps.Deployment{}}, + "deployment": {&apps.Deployment{}}, + "deployment-patch": {&apps.Deployment{}}, + "deployment-retainkeys": {&apps.Deployment{}}, + "deployment-scale": {&apps.Deployment{}}, + "deployment-update": {&apps.Deployment{}}, + "nginx-app": {&api.Service{}, &apps.Deployment{}}, + "nginx-with-request": {&apps.Deployment{}}, + "php-apache": {&apps.Deployment{}, &api.Service{}}, + "shell-demo": {&api.Pod{}}, + "simple_deployment": {&apps.Deployment{}}, + "update_deployment": {&apps.Deployment{}}, }, "application/cassandra": { "cassandra-service": {&api.Service{}}, @@ -413,15 +498,17 @@ func TestExampleObjectSchemas(t *testing.T) { "configmap-multikeys": {&api.ConfigMap{}}, }, "controllers": { - "daemonset": {&apps.DaemonSet{}}, - "frontend": {&apps.ReplicaSet{}}, - "hpa-rs": {&autoscaling.HorizontalPodAutoscaler{}}, - "job": {&batch.Job{}}, - "replicaset": {&apps.ReplicaSet{}}, - "replication": {&api.ReplicationController{}}, - "replication-nginx-1.7.9": {&api.ReplicationController{}}, - "replication-nginx-1.9.2": {&api.ReplicationController{}}, - "nginx-deployment": {&apps.Deployment{}}, + "daemonset": {&apps.DaemonSet{}}, + "fluentd-daemonset": {&apps.DaemonSet{}}, + "fluentd-daemonset-update": {&apps.DaemonSet{}}, + "frontend": {&apps.ReplicaSet{}}, + "hpa-rs": {&autoscaling.HorizontalPodAutoscaler{}}, + "job": {&batch.Job{}}, + "replicaset": {&apps.ReplicaSet{}}, + "replication": {&api.ReplicationController{}}, + "replication-nginx-1.14.2": {&api.ReplicationController{}}, + "replication-nginx-1.16.1": {&api.ReplicationController{}}, + "nginx-deployment": {&apps.Deployment{}}, }, "debug": { "counter-pod": {&api.Pod{}}, @@ -455,6 +542,8 @@ func TestExampleObjectSchemas(t *testing.T) { "pod-configmap-volume": {&api.Pod{}}, "pod-configmap-volume-specific-key": {&api.Pod{}}, "pod-multiple-configmap-env-variable": {&api.Pod{}}, + "pod-nginx-preferred-affinity": {&api.Pod{}}, + "pod-nginx-required-affinity": {&api.Pod{}}, "pod-nginx-specific-node": {&api.Pod{}}, "pod-nginx": {&api.Pod{}}, "pod-projected-svc-token": {&api.Pod{}}, @@ -462,6 +551,7 @@ func TestExampleObjectSchemas(t *testing.T) { "pod-single-configmap-env-variable": {&api.Pod{}}, "pod-with-node-affinity": {&api.Pod{}}, "pod-with-pod-affinity": {&api.Pod{}}, + "pod-with-toleration": {&api.Pod{}}, "private-reg-pod": {&api.Pod{}}, "share-process-namespace": {&api.Pod{}}, "simple-pod": {&api.Pod{}}, @@ -471,14 +561,17 @@ func TestExampleObjectSchemas(t *testing.T) { "redis-pod": {&api.Pod{}}, }, "pods/inject": { - "dapi-envars-container": {&api.Pod{}}, - "dapi-envars-pod": {&api.Pod{}}, - "dapi-volume": {&api.Pod{}}, - "dapi-volume-resources": {&api.Pod{}}, - "envars": {&api.Pod{}}, - "secret": {&api.Secret{}}, - "secret-envars-pod": {&api.Pod{}}, - "secret-pod": {&api.Pod{}}, + "dapi-envars-container": {&api.Pod{}}, + "dapi-envars-pod": {&api.Pod{}}, + "dapi-volume": {&api.Pod{}}, + "dapi-volume-resources": {&api.Pod{}}, + "envars": {&api.Pod{}}, + "pod-multiple-secret-env-variable": {&api.Pod{}}, + "pod-secret-envFrom": {&api.Pod{}}, + "pod-single-secret-env-variable": {&api.Pod{}}, + "secret": {&api.Secret{}}, + "secret-envars-pod": {&api.Pod{}}, + "secret-pod": {&api.Pod{}}, }, "pods/probe": { "exec-liveness": {&api.Pod{}}, @@ -517,38 +610,53 @@ func TestExampleObjectSchemas(t *testing.T) { "redis": {&api.Pod{}}, }, "policy": { + "baseline-psp": {&policy.PodSecurityPolicy{}}, + "example-psp": {&policy.PodSecurityPolicy{}}, "privileged-psp": {&policy.PodSecurityPolicy{}}, "restricted-psp": {&policy.PodSecurityPolicy{}}, - "example-psp": {&policy.PodSecurityPolicy{}}, "zookeeper-pod-disruption-budget-maxunavailable": {&policy.PodDisruptionBudget{}}, - "zookeeper-pod-disruption-budget-minunavailable": {&policy.PodDisruptionBudget{}}, + "zookeeper-pod-disruption-budget-minavailable": {&policy.PodDisruptionBudget{}}, }, "service": { - "nginx-service": {&api.Service{}}, + "nginx-service": {&api.Service{}}, + "load-balancer-example": {&apps.Deployment{}}, }, "service/access": { - "frontend": {&api.Service{}, &apps.Deployment{}}, - "hello-service": {&api.Service{}}, - "hello": {&apps.Deployment{}}, + "frontend": {&api.Service{}, &apps.Deployment{}}, + "hello-application": {&apps.Deployment{}}, + "hello-service": {&api.Service{}}, + "hello": {&apps.Deployment{}}, }, "service/networking": { - "curlpod": {&apps.Deployment{}}, - "custom-dns": {&api.Pod{}}, - "hostaliases-pod": {&api.Pod{}}, - "ingress": {&extensions.Ingress{}}, - "nginx-secure-app": {&api.Service{}, &apps.Deployment{}}, - "nginx-svc": {&api.Service{}}, - "run-my-nginx": {&apps.Deployment{}}, + "curlpod": {&apps.Deployment{}}, + "custom-dns": {&api.Pod{}}, + "dual-stack-default-svc": {&api.Service{}}, + "dual-stack-ipv4-svc": {&api.Service{}}, + "dual-stack-ipv6-lb-svc": {&api.Service{}}, + "dual-stack-ipv6-svc": {&api.Service{}}, + "hostaliases-pod": {&api.Pod{}}, + "ingress": {&networking.Ingress{}}, + "network-policy-allow-all-egress": {&networking.NetworkPolicy{}}, + "network-policy-allow-all-ingress": {&networking.NetworkPolicy{}}, + "network-policy-default-deny-egress": {&networking.NetworkPolicy{}}, + "network-policy-default-deny-ingress": {&networking.NetworkPolicy{}}, + "network-policy-default-deny-all": {&networking.NetworkPolicy{}}, + "nginx-policy": {&networking.NetworkPolicy{}}, + "nginx-secure-app": {&api.Service{}, &apps.Deployment{}}, + "nginx-svc": {&api.Service{}}, + "run-my-nginx": {&apps.Deployment{}}, }, "windows": { - "configmap-pod": {&api.ConfigMap{}, &api.Pod{}}, - "daemonset": {&apps.DaemonSet{}}, - "deploy-hyperv": {&apps.Deployment{}}, - "deploy-resource": {&apps.Deployment{}}, - "emptydir-pod": {&api.Pod{}}, - "hostpath-volume-pod": {&api.Pod{}}, - "secret-pod": {&api.Secret{}, &api.Pod{}}, - "simple-pod": {&api.Pod{}}, + "configmap-pod": {&api.ConfigMap{}, &api.Pod{}}, + "daemonset": {&apps.DaemonSet{}}, + "deploy-hyperv": {&apps.Deployment{}}, + "deploy-resource": {&apps.Deployment{}}, + "emptydir-pod": {&api.Pod{}}, + "hostpath-volume-pod": {&api.Pod{}}, + "run-as-username-container": {&api.Pod{}}, + "run-as-username-pod": {&api.Pod{}}, + "secret-pod": {&api.Secret{}, &api.Pod{}}, + "simple-pod": {&api.Pod{}}, }, } diff --git a/content/zh/examples/policy/baseline-psp.yaml b/content/zh/examples/policy/baseline-psp.yaml new file mode 100644 index 0000000000..36e440588b --- /dev/null +++ b/content/zh/examples/policy/baseline-psp.yaml @@ -0,0 +1,74 @@ +apiVersion: policy/v1beta1 +kind: PodSecurityPolicy +metadata: + name: baseline + annotations: + # Optional: Allow the default AppArmor profile, requires setting the default. + apparmor.security.beta.kubernetes.io/allowedProfileNames: 'runtime/default' + apparmor.security.beta.kubernetes.io/defaultProfileName: 'runtime/default' + # Optional: Allow the default seccomp profile, requires setting the default. + seccomp.security.alpha.kubernetes.io/allowedProfileNames: 'docker/default,runtime/default,unconfined' + seccomp.security.alpha.kubernetes.io/defaultProfileName: 'unconfined' +spec: + privileged: false + # The moby default capability set, defined here: + # https://github.com/moby/moby/blob/0a5cec2833f82a6ad797d70acbf9cbbaf8956017/oci/caps/defaults.go#L6-L19 + allowedCapabilities: + - 'CHOWN' + - 'DAC_OVERRIDE' + - 'FSETID' + - 'FOWNER' + - 'MKNOD' + - 'NET_RAW' + - 'SETGID' + - 'SETUID' + - 'SETFCAP' + - 'SETPCAP' + - 'NET_BIND_SERVICE' + - 'SYS_CHROOT' + - 'KILL' + - 'AUDIT_WRITE' + # Allow all volume types except hostpath + volumes: + # 'core' volume types + - 'configMap' + - 'emptyDir' + - 'projected' + - 'secret' + - 'downwardAPI' + # Assume that persistentVolumes set up by the cluster admin are safe to use. + - 'persistentVolumeClaim' + # Allow all other non-hostpath volume types. + - 'awsElasticBlockStore' + - 'azureDisk' + - 'azureFile' + - 'cephFS' + - 'cinder' + - 'csi' + - 'fc' + - 'flexVolume' + - 'flocker' + - 'gcePersistentDisk' + - 'gitRepo' + - 'glusterfs' + - 'iscsi' + - 'nfs' + - 'photonPersistentDisk' + - 'portworxVolume' + - 'quobyte' + - 'rbd' + - 'scaleIO' + - 'storageos' + - 'vsphereVolume' + hostNetwork: false + hostIPC: false + hostPID: false + readOnlyRootFilesystem: false + runAsUser: + rule: 'RunAsAny' + seLinux: + rule: 'RunAsAny' + supplementalGroups: + rule: 'RunAsAny' + fsGroup: + rule: 'RunAsAny' diff --git a/content/zh/examples/service/networking/network-policy-allow-all-egress.yaml b/content/zh/examples/service/networking/network-policy-allow-all-egress.yaml index 42b2a2a296..2534307925 100644 --- a/content/zh/examples/service/networking/network-policy-allow-all-egress.yaml +++ b/content/zh/examples/service/networking/network-policy-allow-all-egress.yaml @@ -1,4 +1,3 @@ ---- apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: diff --git a/content/zh/examples/service/networking/network-policy-allow-all-ingress.yaml b/content/zh/examples/service/networking/network-policy-allow-all-ingress.yaml index 462912dae4..19dd2d4714 100644 --- a/content/zh/examples/service/networking/network-policy-allow-all-ingress.yaml +++ b/content/zh/examples/service/networking/network-policy-allow-all-ingress.yaml @@ -1,4 +1,3 @@ ---- apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: diff --git a/content/zh/examples/service/networking/network-policy-default-deny-all.yaml b/content/zh/examples/service/networking/network-policy-default-deny-all.yaml index 5c0086bd71..589f15eb3e 100644 --- a/content/zh/examples/service/networking/network-policy-default-deny-all.yaml +++ b/content/zh/examples/service/networking/network-policy-default-deny-all.yaml @@ -1,4 +1,3 @@ ---- apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: diff --git a/content/zh/examples/service/networking/network-policy-default-deny-egress.yaml b/content/zh/examples/service/networking/network-policy-default-deny-egress.yaml index a4659e1417..a6ca49cbc6 100644 --- a/content/zh/examples/service/networking/network-policy-default-deny-egress.yaml +++ b/content/zh/examples/service/networking/network-policy-default-deny-egress.yaml @@ -1,4 +1,3 @@ ---- apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: diff --git a/content/zh/examples/service/networking/network-policy-default-deny-ingress.yaml b/content/zh/examples/service/networking/network-policy-default-deny-ingress.yaml index e823802487..1a97947dc4 100644 --- a/content/zh/examples/service/networking/network-policy-default-deny-ingress.yaml +++ b/content/zh/examples/service/networking/network-policy-default-deny-ingress.yaml @@ -1,4 +1,3 @@ ---- apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: diff --git a/content/zh/includes/task-tutorial-prereqs.md b/content/zh/includes/task-tutorial-prereqs.md index a9de9e7844..acd083bde5 100644 --- a/content/zh/includes/task-tutorial-prereqs.md +++ b/content/zh/includes/task-tutorial-prereqs.md @@ -1,5 +1,5 @@ 你必须拥有一个 Kubernetes 的集群，同时你的 Kubernetes 集群必须带有 kubectl 命令行工具。 -如果你还没有集群，你可以通过 [Minikube](/docs/getting-started-guides/minikube) 构建一 +如果你还没有集群，你可以通过 [Minikube](/zh/docs/setup/learning-environment/minikube/) 构建一 个你自己的集群，或者你可以使用下面任意一个 Kubernetes 工具构建： <!-- You need to have a Kubernetes cluster, and the kubectl command-line tool must diff --git a/content/zh/training/_index.html b/content/zh/training/_index.html index 69a9bac043..ba3a2df60f 100644 --- a/content/zh/training/_index.html +++ b/content/zh/training/_index.html @@ -8,14 +8,12 @@ class: training --- <!-- ---- title: Training bigheader: Kubernetes Training and Certification abstract: Training programs, certifications, and partners. layout: basic cid: training class: training ---- --> <section class="call-to-action"> diff --git a/data/concepts.yml b/data/concepts.yml deleted file mode 100644 index be47572d3a..0000000000 --- a/data/concepts.yml +++ /dev/null @@ -1,129 +0,0 @@ -bigheader: "Concepts" -abstract: "Detailed explanations of Kubernetes system concepts and abstractions." -landing_page: /docs/concepts/index/ -toc: -- docs/concepts/index.md - -- title: Overview - landing_page: /docs/concepts/overview/what-is-kubernetes/ - section: - - docs/concepts/overview/what-is-kubernetes.md - - docs/concepts/overview/components.md - - docs/concepts/overview/kubernetes-api.md - - title: Working with Kubernetes Objects - section: - - docs/concepts/overview/working-with-objects/kubernetes-objects.md - - docs/concepts/overview/working-with-objects/names.md - - docs/concepts/overview/working-with-objects/namespaces.md - - docs/concepts/overview/working-with-objects/labels.md - - docs/concepts/overview/working-with-objects/annotations.md - - docs/concepts/overview/working-with-objects/common-labels.md - - title: Object Management Using kubectl - section: - - docs/concepts/overview/object-management-kubectl/overview.md - - docs/concepts/overview/object-management-kubectl/imperative-command.md - - docs/concepts/overview/object-management-kubectl/imperative-config.md - - docs/concepts/overview/object-management-kubectl/declarative-config.md - -- title: Kubernetes Architecture - landing_page: /docs/concepts/architecture/nodes/ - section: - - docs/concepts/architecture/nodes.md - - docs/concepts/architecture/master-node-communication.md - - docs/concepts/architecture/cloud-controller.md - -- title: Extending Kubernetes - landing_page: /docs/concepts/api-extension/custom-resources/ - section: - - docs/concepts/overview/extending.md - - title: Extending the Kubernetes API - section: - - docs/concepts/api-extension/apiserver-aggregation.md - - docs/concepts/api-extension/custom-resources.md - - title: Compute, Storage, and Networking Extensions - section: - - docs/concepts/cluster-administration/network-plugins.md - - docs/concepts/cluster-administration/device-plugins.md - - docs/concepts/service-catalog/index.md - -- title: Containers - landing_page: /docs/concepts/containers/images/ - section: - - docs/concepts/containers/images.md - - docs/concepts/containers/container-environment-variables.md - - docs/concepts/containers/container-lifecycle-hooks.md - -- title: Workloads - landing_page: /docs/concepts/workloads/pods/pod-overview/ - section: - - title: Pods - section: - - docs/concepts/workloads/pods/pod-overview.md - - docs/concepts/workloads/pods/pod.md - - docs/concepts/workloads/pods/pod-lifecycle.md - - docs/concepts/workloads/pods/init-containers.md - - docs/concepts/workloads/pods/podpreset.md - - docs/concepts/workloads/pods/disruptions.md - - title: Controllers - section: - - docs/concepts/workloads/controllers/replicaset.md - - docs/concepts/workloads/controllers/replicationcontroller.md - - docs/concepts/workloads/controllers/deployment.md - - docs/concepts/workloads/controllers/statefulset.md - - docs/concepts/workloads/controllers/daemonset.md - - docs/concepts/workloads/controllers/garbage-collection.md - - docs/concepts/workloads/controllers/jobs-run-to-completion.md - - docs/concepts/workloads/controllers/cron-jobs.md - -- title: Configuration - landing_page: /docs/concepts/configuration/overview/ - section: - - docs/concepts/configuration/overview.md - - docs/concepts/configuration/manage-compute-resources-container.md - - docs/concepts/configuration/assign-pod-node.md - - docs/concepts/configuration/taint-and-toleration.md - - docs/concepts/configuration/secret.md - - docs/concepts/configuration/organize-cluster-access-kubeconfig.md - - docs/concepts/configuration/pod-priority-preemption.md - -- title: Services, Load Balancing, and Networking - landing_page: /docs/concepts/services-networking/service/ - section: - - docs/concepts/services-networking/service.md - - docs/concepts/services-networking/dns-pod-service.md - - docs/concepts/services-networking/connect-applications-service.md - - docs/concepts/services-networking/ingress.md - - docs/concepts/services-networking/endpoint-slices.md - - docs/concepts/services-networking/network-policies.md - - docs/concepts/services-networking/add-entries-to-pod-etc-hosts-with-host-aliases.md - - docs/concepts/services-networking/dual-stack.md - -- title: Storage - landing_page: /docs/concepts/storage/volumes/ - section: - - docs/concepts/storage/volumes.md - - docs/concepts/storage/persistent-volumes.md - - docs/concepts/storage/storage-classes.md - - docs/concepts/storage/dynamic-provisioning.md - -- title: Cluster Administration - landing_page: /docs/concepts/cluster-administration/cluster-administration-overview/ - section: - - docs/concepts/cluster-administration/cluster-administration-overview.md - - docs/concepts/cluster-administration/certificates.md - - docs/concepts/cluster-administration/cloud-providers.md - - docs/concepts/cluster-administration/manage-deployment.md - - docs/concepts/cluster-administration/networking.md - - docs/concepts/cluster-administration/network-plugins.md - - docs/concepts/cluster-administration/logging.md - - docs/concepts/cluster-administration/monitoring.md - - docs/concepts/cluster-administration/kubelet-garbage-collection.md - - docs/concepts/cluster-administration/sysctl-cluster.md - - docs/concepts/cluster-administration/authenticate-across-clusters-kubeconfig.md - - docs/concepts/cluster-administration/master-node-communication.md - - docs/concepts/cluster-administration/proxies.md - - docs/concepts/cluster-administration/device-plugins.md - - title: Policies - section: - - docs/concepts/policy/resource-quotas.md - - docs/concepts/policy/pod-security-policy.md diff --git a/data/docs-home.yml b/data/docs-home.yml deleted file mode 100644 index 42d3cad567..0000000000 --- a/data/docs-home.yml +++ /dev/null @@ -1,28 +0,0 @@ -bigheader: "About" -abstract: "Documentation for using and learning about Kubernetes." -toc: -- docs/home/index.md - -- title: Supported Doc Versions - path: /docs/home/supported-doc-versions/ - -- title: Contributing to the Kubernetes Docs - landing_page: /editdocs/ - section: - - editdocs.md - - docs/home/contribute/participating.md - - docs/home/contribute/create-pull-request.md - - docs/home/contribute/write-new-topic.md - - docs/home/contribute/stage-documentation-changes.md - - docs/home/contribute/page-templates.md - - docs/home/contribute/review-issues.md - - docs/home/contribute/style-guide.md - - docs/home/contribute/includes.md - - docs/home/contribute/localization.md - - docs/home/contribute/blog-post.md - - - title: Updating Automatically Generated Reference Pages - section: - - docs/home/contribute/generated-reference/kubernetes-components.md - - docs/home/contribute/generated-reference/kubectl.md - - docs/home/contribute/generated-reference/kubernetes-api.md diff --git a/data/globals.yml b/data/globals.yml deleted file mode 100644 index 664d7ed66a..0000000000 --- a/data/globals.yml +++ /dev/null @@ -1,11 +0,0 @@ -tocs: -- docs-home -- guides -- setup -- tasks -- tutorials -- concepts -- reference -- samples -- support -- imported diff --git a/data/overrides.yml b/data/overrides.yml deleted file mode 100644 index a8b503e146..0000000000 --- a/data/overrides.yml +++ /dev/null @@ -1,7 +0,0 @@ -overrides: -- path: docs/admin/cloud-controller-manager.md -- path: docs/admin/kube-apiserver.md -- path: docs/admin/kube-controller-manager.md -- path: docs/admin/kube-proxy.md -- path: docs/admin/kube-scheduler.md -- path: docs/admin/kubelet.md diff --git a/data/reference.yml b/data/reference.yml deleted file mode 100644 index 26eee2d91f..0000000000 --- a/data/reference.yml +++ /dev/null @@ -1,94 +0,0 @@ -bigheader: "Reference" -abstract: "Design docs, concept definitions, and references for APIs and CLIs." -landing_page: /docs/reference/index/ -toc: -- docs/reference/index.md - -- title: Standardized Glossary - path: /docs/reference/glossary/ - -- title: Using the API - landing_page: /docs/reference/api-overview/ - section: - - docs/reference/api-overview.md - - docs/reference/client-libraries.md - - title: Accessing the API - section: - - docs/admin/accessing-the-api.md - - docs/admin/authentication.md - - docs/admin/bootstrap-tokens.md - - docs/admin/certificate-signing-requests.md - - docs/admin/admission-controllers.md - - docs/admin/extensible-admission-controllers.md - - docs/admin/service-accounts-admin.md - - title: Authorization - section: - - docs/admin/authorization/index.md - - docs/admin/authorization/abac.md - - docs/admin/authorization/rbac.md - - docs/admin/authorization/node.md - - docs/admin/authorization/webhook.md - - docs/reference/api-concepts.md - - docs/reference/deprecation-policy.md - - docs/reference/workloads-18-19.md - -- title: API Reference - landing_page: /docs/reference/generated/kubernetes-api/v1.10/ - section: - - title: v1.10 - path: /docs/reference/generated/kubernetes-api/v1.10/ - - docs/reference/labels-annotations-taints.md - - title: OpenAPI and Swagger - section: - - title: OpenAPI Spec - path: https://git.k8s.io/kubernetes/api/openapi-spec/ - - title: Swagger Spec - path: https://git.k8s.io/kubernetes/api/swagger-spec/ - -- title: kubectl CLI - landing_page: /docs/user-guide/kubectl-overview/ - section: - - docs/reference/kubectl/overview.md - - docs/reference/generated/kubectl/kubectl.md - - title: kubectl Commands - path: /docs/reference/generated/kubectl/kubectl-commands.html - - docs/reference/kubectl/docker-cli-to-kubectl.md - - docs/reference/kubectl/conventions.md - - docs/reference/kubectl/jsonpath.md - - docs/reference/kubectl/cheatsheet.md - -- title: Setup Tools Reference - landing_page: /docs/reference/setup-tools/kubeadm/kubeadm/ - section: - - title: Kubeadm - section: - - docs/reference/setup-tools/kubeadm/kubeadm.md - - docs/reference/setup-tools/kubeadm/kubeadm-init.md - - docs/reference/setup-tools/kubeadm/kubeadm-join.md - - docs/reference/setup-tools/kubeadm/kubeadm-upgrade.md - - docs/reference/setup-tools/kubeadm/kubeadm-config.md - - docs/reference/setup-tools/kubeadm/kubeadm-reset.md - - docs/reference/setup-tools/kubeadm/kubeadm-token.md - - docs/reference/setup-tools/kubeadm/kubeadm-version.md - - docs/reference/setup-tools/kubeadm/kubeadm-alpha.md - - docs/reference/setup-tools/kubeadm/implementation-details.md - -- title: Command-line Tools Reference - landing_page: /docs/admin/kubelet/ - section: - - docs/reference/feature-gates.md - - docs/reference/generated/kubelet.md - - docs/admin/kubelet-authentication-authorization.md - - docs/reference/generated/kube-apiserver.md - - docs/reference/generated/kube-controller-manager.md - - docs/reference/generated/kube-proxy.md - - docs/reference/generated/kube-scheduler.md - - docs/admin/kubelet-tls-bootstrapping.md - - docs/reference/generated/cloud-controller-manager.md - -- title: Kubernetes Issues and Security - landing_page: https://github.com/kubernetes/kubernetes/issues/ - section: - - title: Kubernetes Issue Tracker on GitHub - path: https://github.com/kubernetes/kubernetes/issues/ - - docs/reference/security.md diff --git a/data/repos.yml b/data/repos.yml deleted file mode 100644 index 21e7eb3e04..0000000000 --- a/data/repos.yml +++ /dev/null @@ -1,2 +0,0 @@ -en: kubernetes/website -cn: kubernetes/kubernetes-docs-zh \ No newline at end of file diff --git a/data/search.yml b/data/search.yml deleted file mode 100644 index a534aa852c..0000000000 --- a/data/search.yml +++ /dev/null @@ -1,4 +0,0 @@ -bigheader: "" -abstract: "" -toc: -- docs/search.md diff --git a/data/setup.yml b/data/setup.yml deleted file mode 100644 index b51c4d89a3..0000000000 --- a/data/setup.yml +++ /dev/null @@ -1,117 +0,0 @@ -bigheader: "Setup" -abstract: "Instructions for setting up a Kubernetes cluster." -landing_page: /docs/setup/index/ -toc: -- docs/setup/index.md -- docs/setup/pick-right-solution.md - -- title: Downloading Kubernetes - landing_page: /docs/setup/release/notes/ - section: - - docs/setup/release/notes.md - - docs/setup/building-from-source.md - -- title: Version 1.10 Troubleshooting - landing page: /docs/reference/pvc-finalizer-downgrade-issue/ - section: - - docs/reference/pvc-finalizer-downgrade-issue.md - -- title: Independent Solutions - landing_page: /docs/getting-started-guides/minikube/ - section: - - docs/getting-started-guides/minikube.md - - - title: Bootstrapping Clusters with kubeadm - section: - - docs/setup/independent/install-kubeadm.md - - docs/setup/independent/create-cluster-kubeadm.md - - docs/setup/independent/troubleshooting-kubeadm.md - - docs/setup/independent/high-availability.md - - - docs/getting-started-guides/scratch.md - - docs/getting-started-guides/alternatives.md - -- title: Hosted Solutions - landing_page: /docs/setup/pick-right-solution/#hosted-solutions - section: - - title: Running Kubernetes on Google Kubernetes Engine - path: https://cloud.google.com/kubernetes-engine/docs/before-you-begin/ - - title: Running Kubernetes on Azure Container Service - path: https://docs.microsoft.com/en-us/azure/container-service/container-service-kubernetes-walkthrough - - title: Running Kubernetes on IBM Cloud Kubernetes Service - path: https://cloud.ibm.com/docs/containers?topic=containers-getting-started - -- title: Turn-key Cloud Solutions - landing_page: /docs/getting-started-guides/alibaba-cloud/ - section: - - docs/getting-started-guides/alibaba-cloud.md - - docs/getting-started-guides/aws.md - - docs/getting-started-guides/azure.md - - docs/getting-started-guides/clc.md - - docs/getting-started-guides/gce.md - - title: Running Kubernetes on IBM Cloud - path: https://github.com/patrocinio/kubernetes-softlayer - -- title: Custom Solutions - landing_page: /docs/getting-started-guides/coreos/index/ - section: - - title: Custom Cloud Solutions - section: - - docs/getting-started-guides/coreos/index.md - - docs/getting-started-guides/ubuntu/index.md - - docs/getting-started-guides/kops.md - - docs/getting-started-guides/kubespray.md - - docs/getting-started-guides/running-cloud-controller.md - - - title: On-Premises VMs - section: - - docs/getting-started-guides/coreos/index.md - - docs/getting-started-guides/cloudstack.md - - title: VMware vSphere - path: https://vmware.github.io/vsphere-storage-for-kubernetes/documentation/ - - docs/getting-started-guides/dcos.md - - docs/getting-started-guides/ovirt.md - - - title: Bare Metal - section: - - docs/getting-started-guides/fedora/fedora_manual_config.md - - docs/getting-started-guides/fedora/flannel_multi_node_cluster.md - - docs/getting-started-guides/coreos/index.md - - docs/getting-started-guides/ubuntu/index.md - - - title: Ubuntu - section: - - docs/getting-started-guides/ubuntu/index.md - - docs/getting-started-guides/ubuntu/validation.md - - docs/getting-started-guides/ubuntu/backups.md - - docs/getting-started-guides/ubuntu/upgrades.md - - docs/getting-started-guides/ubuntu/scaling.md - - docs/getting-started-guides/ubuntu/installation.md - - docs/getting-started-guides/ubuntu/monitoring.md - - docs/getting-started-guides/ubuntu/networking.md - - docs/getting-started-guides/ubuntu/security.md - - docs/getting-started-guides/ubuntu/storage.md - - docs/getting-started-guides/ubuntu/troubleshooting.md - - docs/getting-started-guides/ubuntu/decommissioning.md - - docs/getting-started-guides/ubuntu/operational-considerations.md - - docs/getting-started-guides/ubuntu/glossary.md - - docs/getting-started-guides/ubuntu/local.md - - docs/getting-started-guides/ubuntu/logging.md - - docs/getting-started-guides/ubuntu/rancher.md - - docs/getting-started-guides/windows/index.md - - - docs/admin/node-conformance.md - -- title: Installing Addons - path: /docs/concepts/cluster-administration/addons/ - -- title: Building Large Clusters - path: /docs/admin/cluster-large/ - -- title: Running in Multiple Zones - path: /docs/setup/best-practices/multiple-zones/ - -- title: Building High-Availability Clusters - path: /docs/admin/high-availability/building/ - -- docs/setup/version-skew-policy.md diff --git a/data/tasks.yml b/data/tasks.yml deleted file mode 100644 index 4220e059cc..0000000000 --- a/data/tasks.yml +++ /dev/null @@ -1,215 +0,0 @@ -bigheader: "Tasks" -abstract: "Step-by-step instructions for performing operations with Kubernetes." -landing_page: /docs/tasks/index/ -toc: -- docs/tasks/index.md - -- title: Install Tools - landing_page: /docs/tasks/tools/install-kubectl/ - section: - - docs/tasks/tools/install-kubectl.md - - docs/tasks/tools/install-minikube.md - - docs/setup/independent/install-kubeadm.md - -- title: Configure Pods and Containers - landing_page: /docs/tasks/configure-pod-container/configure-pod-initialization/ - section: - - docs/tasks/configure-pod-container/assign-memory-resource.md - - docs/tasks/configure-pod-container/assign-cpu-resource.md - - docs/tasks/configure-pod-container/quality-service-pod.md - - docs/tasks/configure-pod-container/assign-cpu-ram-container.md - - docs/tasks/configure-pod-container/extended-resource.md - - docs/tasks/configure-pod-container/configure-volume-storage.md - - docs/tasks/configure-pod-container/configure-persistent-volume-storage.md - - docs/tasks/configure-pod-container/configure-projected-volume-storage.md - - docs/tasks/configure-pod-container/projected-volume.md - - docs/tasks/configure-pod-container/security-context.md - - docs/tasks/inject-data-application/environment-variable-expose-pod-information.md - - docs/tasks/configure-pod-container/configure-service-account.md - - docs/tasks/configure-pod-container/pull-image-private-registry.md - - docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes.md - - docs/tasks/configure-pod-container/assign-pods-nodes.md - - docs/tasks/configure-pod-container/configure-pod-initialization.md - - docs/tasks/configure-pod-container/attach-handler-lifecycle-event.md - - docs/tasks/configure-pod-container/configure-pod-configmap.md - - docs/tasks/configure-pod-container/share-process-namespace.md - - docs/tools/kompose/user-guide.md - -- title: Inject Data Into Applications - landing_page: /docs/tasks/inject-data-application/define-environment-variable-container/ - section: - - docs/tasks/inject-data-application/define-command-argument-container.md - - docs/tasks/inject-data-application/define-environment-variable-container.md - - docs/tasks/inject-data-application/environment-variable-expose-pod-information.md - - docs/tasks/inject-data-application/downward-api-volume-expose-pod-information.md - - docs/tasks/inject-data-application/distribute-credentials-secure.md - - docs/tasks/inject-data-application/podpreset.md - -- title: Run Applications - landing_page: /docs/tasks/run-application/run-stateless-application-deployment/ - section: - - docs/tasks/run-application/run-stateless-application-deployment.md - - docs/tasks/run-application/run-single-instance-stateful-application.md - - docs/tasks/run-application/run-replicated-stateful-application.md - - docs/tasks/run-application/update-api-object-kubectl-patch.md - - docs/tasks/run-application/upgrade-pet-set-to-stateful-set.md - - docs/tasks/run-application/scale-stateful-set.md - - docs/tasks/run-application/delete-stateful-set.md - - docs/tasks/run-application/force-delete-stateful-set-pod.md - - docs/tasks/run-application/rolling-update-replication-controller.md - - docs/tasks/run-application/horizontal-pod-autoscale.md - - docs/tasks/run-application/horizontal-pod-autoscale-walkthrough.md - - docs/tasks/run-application/configure-pdb.md - -- title: Run Jobs - landing_page: /docs/tasks/job/parallel-processing-expansion/ - section: - - docs/tasks/job/automated-tasks-with-cron-jobs.md - - docs/tasks/job/parallel-processing-expansion.md - - docs/tasks/job/coarse-parallel-processing-work-queue/index.md - - docs/tasks/job/fine-parallel-processing-work-queue/index.md - -- title: Access Applications in a Cluster - landing_page: /docs/tasks/access-application-cluster/web-ui-dashboard/ - section: - - docs/tasks/access-application-cluster/web-ui-dashboard.md - - docs/tasks/access-application-cluster/access-cluster.md - - docs/tasks/access-application-cluster/configure-access-multiple-clusters.md - - docs/tasks/access-application-cluster/port-forward-access-application-cluster.md - - docs/tasks/access-application-cluster/load-balance-access-application-cluster.md - - docs/tasks/access-application-cluster/service-access-application-cluster.md - - docs/tasks/access-application-cluster/connecting-frontend-backend.md - - docs/tasks/access-application-cluster/create-external-load-balancer.md - - docs/tasks/access-application-cluster/configure-cloud-provider-firewall.md - - docs/tasks/access-application-cluster/list-all-running-container-images.md - - docs/tasks/access-application-cluster/communicate-containers-same-pod-shared-volume.md - - title: Configuring DNS for a Cluster - path: https://github.com/kubernetes/kubernetes/tree/release-1.5/examples/cluster-dns - -- title: Monitor, Log, and Debug - landing_page: /docs/tasks/debug-application-cluster/resource-usage-monitoring/ - section: - - docs/tasks/debug-application-cluster/resource-metrics-pipeline.md - - docs/tasks/debug-application-cluster/resource-usage-monitoring.md - - docs/tasks/debug-application-cluster/get-shell-running-container.md - - docs/tasks/debug-application-cluster/monitor-node-health.md - - docs/tasks/debug-application-cluster/logging-stackdriver.md - - docs/tasks/debug-application-cluster/events-stackdriver.md - - docs/tasks/debug-application-cluster/logging-elasticsearch-kibana.md - - docs/tasks/debug-application-cluster/determine-reason-pod-failure.md - - docs/tasks/debug-application-cluster/debug-init-containers.md - - docs/tasks/debug-application-cluster/debug-pod-replication-controller.md - - docs/tasks/debug-application-cluster/debug-service.md - - docs/tasks/debug-application-cluster/debug-cluster.md - - docs/tasks/debug-application-cluster/debug-application.md - - docs/tasks/debug-application-cluster/debug-stateful-set.md - - docs/tasks/debug-application-cluster/debug-application-introspection.md - - docs/tasks/debug-application-cluster/audit.md - - docs/tasks/debug-application-cluster/local-debugging.md - - title: Use Explorer to Examine the Runtime Environment - path: https://github.com/kubernetes/kubernetes/tree/release-1.5/examples/explorer - -- title: Extend Kubernetes - landing_page: /docs/tasks/access-kubernetes-api/extend-api-custom-resource-definitions/ - section: - - docs/tasks/access-kubernetes-api/http-proxy-access-api.md - - docs/tasks/access-kubernetes-api/extend-api-custom-resource-definitions.md - - docs/tasks/access-kubernetes-api/migrate-third-party-resource.md - - docs/tasks/access-kubernetes-api/configure-aggregation-layer.md - - docs/tasks/access-kubernetes-api/setup-extension-api-server.md - - docs/tasks/service-catalog/install-service-catalog-using-helm.md - - docs/tasks/service-catalog/install-service-catalog-using-sc.md - -- title: TLS - landing_page: /docs/tasks/tls/managing-tls-in-a-cluster/ - section: - - docs/tasks/tls/managing-tls-in-a-cluster.md - - docs/tasks/tls/certificate-rotation.md - -- title: Network - landing_page: tasks/network/validate-dual-stack/ - section: - - docs/tasks/network/validate-dual-stack.md - -- title: Administer a Cluster - landing_page: /docs/tasks/administer-cluster/memory-default-namespace/ - section: - - title: Upgrading or downgrading Kubernetes - section: - - docs/tasks/administer-cluster/upgrade-downgrade/upgrade-1-6.md - - docs/tasks/administer-cluster/upgrade-downgrade/kubeadm-upgrade-1-7.md - - docs/tasks/administer-cluster/upgrade-downgrade/kubeadm-upgrade-1-8.md - - docs/tasks/administer-cluster/upgrade-downgrade/kubeadm-upgrade-1-9.md - - docs/tasks/administer-cluster/upgrade-downgrade/kubeadm-upgrade-ha.md - - title: Manage Memory, CPU, and API Resources - section: - - docs/tasks/administer-cluster/memory-default-namespace.md - - docs/tasks/administer-cluster/cpu-default-namespace.md - - docs/tasks/administer-cluster/memory-constraint-namespace.md - - docs/tasks/administer-cluster/cpu-constraint-namespace.md - - docs/tasks/administer-cluster/apply-resource-quota-limit.md - - docs/tasks/administer-cluster/quota-memory-cpu-namespace.md - - docs/tasks/administer-cluster/quota-pod-namespace.md - - docs/tasks/administer-cluster/quota-api-object.md - - docs/tasks/administer-cluster/extended-resource-node.md - - docs/tasks/administer-cluster/cpu-management-policies.md - - docs/tasks/administer-cluster/access-cluster-api.md - - docs/tasks/administer-cluster/access-cluster-services.md - - docs/tasks/administer-cluster/securing-a-cluster.md - - docs/tasks/administer-cluster/sysctl-cluster.md - - docs/tasks/administer-cluster/encrypt-data.md - - docs/tasks/administer-cluster/configure-upgrade-etcd.md - - docs/tasks/administer-cluster/static-pod.md - - docs/tasks/administer-cluster/cluster-management.md - - docs/tasks/administer-cluster/namespaces.md - - docs/tasks/administer-cluster/namespaces-walkthrough.md - - docs/tasks/administer-cluster/dns-horizontal-autoscaling.md - - docs/tasks/administer-cluster/coredns.md - - docs/tasks/administer-cluster/safely-drain-node.md - - docs/tasks/administer-cluster/cpu-memory-limit.md - - docs/tasks/administer-cluster/out-of-resource.md - - docs/tasks/administer-cluster/reserve-compute-resources.md - - docs/tasks/administer-cluster/guaranteed-scheduling-critical-addon-pods.md - - docs/tasks/administer-cluster/declare-network-policy.md - - docs/tasks/administer-cluster/kms-provider.md - - title: Install Network Policy Provider - section: - - docs/tasks/administer-cluster/calico-network-policy.md - - docs/tasks/administer-cluster/cilium-network-policy.md - - docs/tasks/administer-cluster/kube-router-network-policy.md - - docs/tasks/administer-cluster/romana-network-policy.md - - docs/tasks/administer-cluster/weave-network-policy.md - - docs/tasks/administer-cluster/reconfigure-kubelet.md - - docs/tasks/administer-cluster/kubelet-config-file.md - - docs/tasks/administer-cluster/change-pv-reclaim-policy.md - - docs/tasks/administer-cluster/configure-pod-disruption-budget.md - - docs/tasks/administer-cluster/limit-storage-consumption.md - - docs/tasks/administer-cluster/change-default-storage-class.md - - docs/tasks/administer-cluster/running-cloud-controller.md - - docs/tasks/administer-cluster/developing-cloud-controller-manager.md - - docs/tasks/administer-cluster/highly-available-master.md - - docs/tasks/administer-cluster/configure-multiple-schedulers.md - - docs/tasks/administer-cluster/ip-masq-agent.md - - docs/tasks/administer-cluster/dns-custom-nameservers.md - - docs/tasks/administer-cluster/dns-debugging-resolution.md - - docs/tasks/administer-cluster/pvc-protection.md - - docs/tasks/administer-cluster/storage-object-in-use-protection.md - - docs/tasks/administer-cluster/endpoint-slices.md - -- title: Manage Cluster Daemons - landing_page: /docs/tasks/manage-daemon/update-daemon-set/ - section: - - docs/tasks/manage-daemon/update-daemon-set.md - - docs/tasks/manage-daemon/rollback-daemon-set.md - -- title: Manage GPUs - path: /docs/tasks/manage-gpus/scheduling-gpus/ - -- title: Manage HugePages - path: /docs/tasks/manage-hugepages/scheduling-hugepages/ - -- title: Extend kubectl with plugins - path: /docs/tasks/extend-kubectl/kubectl-plugins/ - -- title: Troubleshooting - path: /docs/tasks/debug-application-cluster/troubleshooting/ diff --git a/data/tools.yml b/data/tools.yml deleted file mode 100644 index 0f5a970d3c..0000000000 --- a/data/tools.yml +++ /dev/null @@ -1,20 +0,0 @@ -bigheader: "Tools" -abstract: "Tools to help you use and enhance Kubernetes." -toc: -- docs/tools/index.md - -- title: Native Tools - section: - - title: Kubectl - path: /docs/reference/kubectl/overview/ - - title: Kubeadm - path: /docs/getting-started-guides/kubeadm - - title: Kubernetes Dashboard - path: /docs/user-guide/ui/ - -- title: Third-Party Tools - section: - - docs/tools/kompose/index.md - - docs/tools/kompose/user-guide.md - - title: Helm - path: https://github.com/kubernetes/helm diff --git a/data/tutorials.yml b/data/tutorials.yml deleted file mode 100644 index 8bb60c071c..0000000000 --- a/data/tutorials.yml +++ /dev/null @@ -1,71 +0,0 @@ -bigheader: "Tutorials" -abstract: "Detailed walkthroughs of common Kubernetes operations and workflows." -landing_page: /docs/tutorials/index/ -toc: -- docs/tutorials/index.md -- title: Kubernetes Basics - landing_page: /docs/tutorials/kubernetes-basics/index/ - section: - - docs/tutorials/kubernetes-basics/index.html - - title: 1. Create a Cluster - section: - - docs/tutorials/kubernetes-basics/cluster-intro.html - - docs/tutorials/kubernetes-basics/cluster-interactive.html - - title: 2. Deploy an App - section: - - docs/tutorials/kubernetes-basics/deploy-intro.html - - docs/tutorials/kubernetes-basics/deploy-interactive.html - - title: 3. Explore Your App - section: - - docs/tutorials/kubernetes-basics/explore-intro.html - - docs/tutorials/kubernetes-basics/explore-interactive.html - - title: 4. Expose Your App Publicly - section: - - docs/tutorials/kubernetes-basics/expose-intro.html - - docs/tutorials/kubernetes-basics/expose-interactive.html - - title: 5. Scale Your App - section: - - docs/tutorials/kubernetes-basics/scale-intro.html - - docs/tutorials/kubernetes-basics/scale-interactive.html - - title: 6. Update Your App - section: - - docs/tutorials/kubernetes-basics/update-intro.html - - docs/tutorials/kubernetes-basics/update-interactive.html -- title: Online Training Courses - landing_page: /docs/tutorials/online-training/overview/ - section: - - docs/tutorials/online-training/overview.md - - title: Scalable Microservices with Kubernetes (Udacity) - path: https://www.udacity.com/course/scalable-microservices-with-kubernetes--ud615 - - title: Introduction to Kubernetes (edX) - path: https://www.edx.org/course/introduction-kubernetes-linuxfoundationx-lfs158x# -- title: Hello Minikube - path: /docs/tutorials/stateless-application/hello-minikube/ -- title: Configuration - landing_page: /docs/tutorials/configuration/configure-redis-using-configmap/ - section: - - docs/tutorials/configuration/configure-redis-using-configmap.md -- title: Stateless Applications - landing_page: /docs/tutorials/stateless-application/guestbook/ - section: - - docs/tasks/run-application/run-stateless-application-deployment.md - - docs/tutorials/stateless-application/guestbook.md - - docs/tasks/access-application-cluster/service-access-application-cluster.md - - docs/tutorials/stateless-application/expose-external-ip-address.md -- title: Stateful Applications - landing_page: /docs/tutorials/stateful-application/basic-stateful-set/ - section: - - docs/tutorials/stateful-application/basic-stateful-set.md - - docs/tasks/run-application/run-single-instance-stateful-application.md - - docs/tasks/run-application/run-replicated-stateful-application.md - - docs/tutorials/stateful-application/mysql-wordpress-persistent-volume.md - - docs/tutorials/stateful-application/cassandra.md - - docs/tutorials/stateful-application/zookeeper.md -- title: Clusters - landing_page: /docs/tutorials/clusters/apparmor/ - section: - - docs/tutorials/clusters/apparmor.md -- title: Services - landing_page: /docs/tutorials/services/source-ip/ - section: - - docs/tutorials/services/source-ip.md diff --git a/functions-src/deploy-succeeded.js b/functions-src/deploy-succeeded.js deleted file mode 100644 index afe5c7e593..0000000000 --- a/functions-src/deploy-succeeded.js +++ /dev/null @@ -1,77 +0,0 @@ -"use strict"; - -const - { IncomingWebhook } = require('@slack/client'), - kubernetesSiteRoot = 'https://kubernetes.io', - fetch = require('node-fetch').default, - { SLACK_WEBHOOK_URL } = process.env; - -const webhook = new IncomingWebhook(SLACK_WEBHOOK_URL); - -// A random smattering of Kubernetes documentation pages -// We can add as many pages here as we'd like -const kubernetesEndpoints = [ - 'docs/home', - 'docs/tutorials/configuration/configure-redis-using-configmap', - -] - -// Ensure that the SLACK_WEBHOOK_URL environment variable is set -const checkEnv = () => { - if (!SLACK_WEBHOOK_URL) { - return { - statusCode: 422, - body: "[FAILURE] The Slack webhook URL must be set via the SLACK_WEBHOOK_URL environment variable" - } - } -} - -// This function posts a warning message to Slack -const sendSlackMessage = (msg) => { - const slackMessageObject = { - username: "noindex checker", - text: msg - } - - // Send the message to the webhook - webhook.send(slackMessageObject, (err, res) => { - return (err) ? { statusCode: 422, body: `[ERROR] Slack webhook error: ${err}` } : - { statusCode: 200, body: `[SUCCESS] Response received from Slack: ${JSON.stringify(res)}` }; - }); -} - -// Iterate through each Kubernetes endpoint to check for noindex headers -const checkEndpoints = () => { - kubernetesEndpoints.forEach((endpoint) => { - const url = `${kubernetesSiteRoot}/${endpoint}`; - - fetch(url) - .then(res => { - const headers = res.headers; - - if ('x-robots-tag' in headers.raw() && (headers.get('x-robots-tag') == 'noindex')) { - const msg = `[WARNING] "X-Robots-Tag: noindex" header found on the following page: ${url}`; - - // Send Slack notification - sendSlackMessage(msg); - - return { statusCode: 404, body: msg }; - } else { - const msg = `[SUCCESS] No improper X-Robots-Tag: noindex headers found on ${url}`; - - return { statusCode: 200, body: msg }; - } - }) - .catch(err => { - return { statusCode: 422, body: err }; - }); - }); -} - -// The handler function -exports.handler = async (event, context) => { - checkEnv(); - - // Below are the various deploy succeeded checks - checkEndpoints(); -} diff --git a/go.mod b/go.mod new file mode 100644 index 0000000000..30c6741140 --- /dev/null +++ b/go.mod @@ -0,0 +1,34 @@ +module k8s.io/website + +go 1.14 + +require ( + k8s.io/apimachinery v0.18.4 + k8s.io/kubernetes v1.18.4 +) + +replace ( + k8s.io/api => k8s.io/api v0.18.4 + k8s.io/apiextensions-apiserver => k8s.io/apiextensions-apiserver v0.18.4 + k8s.io/apimachinery => k8s.io/apimachinery v0.18.4 + k8s.io/apiserver => k8s.io/apiserver v0.18.4 + k8s.io/cli-runtime => k8s.io/cli-runtime v0.18.4 + k8s.io/client-go => k8s.io/client-go v0.18.4 + k8s.io/cloud-provider => k8s.io/cloud-provider v0.18.4 + k8s.io/cluster-bootstrap => k8s.io/cluster-bootstrap v0.18.4 + k8s.io/code-generator => k8s.io/code-generator v0.18.4 + k8s.io/component-base => k8s.io/component-base v0.18.4 + k8s.io/cri-api => k8s.io/cri-api v0.18.4 + k8s.io/csi-translation-lib => k8s.io/csi-translation-lib v0.18.4 + k8s.io/kube-aggregator => k8s.io/kube-aggregator v0.18.4 + k8s.io/kube-controller-manager => k8s.io/kube-controller-manager v0.18.4 + k8s.io/kube-proxy => k8s.io/kube-proxy v0.18.4 + k8s.io/kube-scheduler => k8s.io/kube-scheduler v0.18.4 + k8s.io/kubectl => k8s.io/kubectl v0.18.4 + k8s.io/kubelet => k8s.io/kubelet v0.18.4 + k8s.io/legacy-cloud-providers => k8s.io/legacy-cloud-providers v0.18.4 + k8s.io/metrics => k8s.io/metrics v0.18.4 + k8s.io/sample-apiserver => k8s.io/sample-apiserver v0.18.4 + k8s.io/sample-cli-plugin => k8s.io/sample-cli-plugin v0.18.4 + k8s.io/sample-controller => k8s.io/sample-controller v0.18.4 +) diff --git a/go.sum b/go.sum new file mode 100644 index 0000000000..d0f82ad655 --- /dev/null +++ b/go.sum @@ -0,0 +1,761 @@ +bitbucket.org/bertimus9/systemstat v0.0.0-20180207000608-0eeff89b0690/go.mod h1:Ulb78X89vxKYgdL24HMTiXYHlyHEvruOj1ZPlqeNEZM= +cloud.google.com/go v0.26.0/go.mod h1:aQUYkXzVsufM+DwF1aE+0xfcU+56JwCaLick0ClmMTw= +cloud.google.com/go v0.34.0/go.mod h1:aQUYkXzVsufM+DwF1aE+0xfcU+56JwCaLick0ClmMTw= +cloud.google.com/go v0.38.0/go.mod h1:990N+gfupTy94rShfmMCWGDn0LpTmnzTp2qbd1dvSRU= +github.com/Azure/azure-sdk-for-go v35.0.0+incompatible/go.mod h1:9XXNKU+eRnpl9moKnB4QOLf1HestfXbmab5FXxiDBjc= +github.com/Azure/go-ansiterm v0.0.0-20170929234023-d6e3b3328b78/go.mod h1:LmzpDX56iTiv29bbRTIsUNlaFfuhWRQBWjQdVyAevI8= +github.com/Azure/go-autorest/autorest v0.9.0/go.mod h1:xyHB1BMZT0cuDHU7I0+g046+BFDTQ8rEZB0s4Yfa6bI= +github.com/Azure/go-autorest/autorest/adal v0.5.0/go.mod h1:8Z9fGy2MpX0PvDjB1pEgQTmVqjGhiHBW7RJJEciWzS0= +github.com/Azure/go-autorest/autorest/date v0.1.0/go.mod h1:plvfp3oPSKwf2DNjlBjWF/7vwR+cUD/ELuzDCXwHUVA= +github.com/Azure/go-autorest/autorest/mocks v0.1.0/go.mod h1:OTyCOPRA2IgIlWxVYxBee2F5Gr4kF2zd2J5cFRaIDN0= +github.com/Azure/go-autorest/autorest/mocks v0.2.0/go.mod h1:OTyCOPRA2IgIlWxVYxBee2F5Gr4kF2zd2J5cFRaIDN0= +github.com/Azure/go-autorest/autorest/to v0.2.0/go.mod h1:GunWKJp1AEqgMaGLV+iocmRAJWqST1wQYhyyjXJ3SJc= +github.com/Azure/go-autorest/autorest/validation v0.1.0/go.mod h1:Ha3z/SqBeaalWQvokg3NZAlQTalVMtOIAs1aGK7G6u8= +github.com/Azure/go-autorest/logger v0.1.0/go.mod h1:oExouG+K6PryycPJfVSxi/koC6LSNgds39diKLz7Vrc= +github.com/Azure/go-autorest/tracing v0.5.0/go.mod h1:r/s2XiOKccPW3HrqB+W0TQzfbtp2fGCgRFtBroKn4Dk= +github.com/BurntSushi/toml v0.3.1/go.mod h1:xHWCNGjB5oqiDr8zfno3MHue2Ht5sIBksp03qcyfWMU= +github.com/BurntSushi/xgb v0.0.0-20160522181843-27f122750802/go.mod h1:IVnqGOEym/WlBOVXweHU+Q+/VP0lqqI8lqeDx9IjBqo= +github.com/GoogleCloudPlatform/k8s-cloud-provider v0.0.0-20190822182118-27a4ced34534/go.mod h1:iroGtC8B3tQiqtds1l+mgk/BBOrxbqjH+eUfFQYRc14= +github.com/JeffAshton/win_pdh v0.0.0-20161109143554-76bb4ee9f0ab/go.mod h1:3VYc5hodBMJ5+l/7J4xAyMeuM2PNuepvHlGs8yilUCA= +github.com/MakeNowJust/heredoc v0.0.0-20170808103936-bb23615498cd/go.mod h1:64YHyfSL2R96J44Nlwm39UHepQbyR5q10x7iYa1ks2E= +github.com/Microsoft/go-winio v0.4.14/go.mod h1:qXqCSQ3Xa7+6tgxaGTIe4Kpcdsi+P8jBhyzoq1bpyYA= +github.com/Microsoft/hcsshim v0.0.0-20190417211021-672e52e9209d/go.mod h1:Op3hHsoHPAvb6lceZHDtd9OkTew38wNoXnJs8iY7rUg= +github.com/NYTimes/gziphandler v0.0.0-20170623195520-56545f4a5d46/go.mod h1:3wb06e3pkSAbeQ52E9H9iFoQsEEwGN64994WTCIhntQ= +github.com/OpenPeeDeeP/depguard v1.0.0/go.mod h1:7/4sitnI9YlQgTLLk734QlzXT8DuHVnAyztLplQjk+o= +github.com/OpenPeeDeeP/depguard v1.0.1/go.mod h1:xsIw86fROiiwelg+jB2uM9PiKihMMmUx/1V+TNhjQvM= +github.com/PuerkitoBio/purell v1.0.0/go.mod h1:c11w/QuzBsJSee3cPx9rAFu61PvFxuPbtSwDGJws/X0= +github.com/PuerkitoBio/purell v1.1.0/go.mod h1:c11w/QuzBsJSee3cPx9rAFu61PvFxuPbtSwDGJws/X0= +github.com/PuerkitoBio/purell v1.1.1/go.mod h1:c11w/QuzBsJSee3cPx9rAFu61PvFxuPbtSwDGJws/X0= +github.com/PuerkitoBio/urlesc v0.0.0-20160726150825-5bd2802263f2/go.mod h1:uGdkoq3SwY9Y+13GIhn11/XLaGBb4BfwItxLd5jeuXE= +github.com/PuerkitoBio/urlesc v0.0.0-20170810143723-de5bf2ad4578/go.mod h1:uGdkoq3SwY9Y+13GIhn11/XLaGBb4BfwItxLd5jeuXE= +github.com/Rican7/retry v0.1.0/go.mod h1:FgOROf8P5bebcC1DS0PdOQiqGUridaZvikzUmkFW6gg= +github.com/StackExchange/wmi v0.0.0-20180116203802-5d049714c4a6/go.mod h1:3eOhrUMpNV+6aFIbp5/iudMxNCF27Vw2OZgy4xEx0Fg= +github.com/agnivade/levenshtein v1.0.1/go.mod h1:CURSv5d9Uaml+FovSIICkLbAUZ9S4RqaHDIsdSBg7lM= +github.com/ajstarks/svgo v0.0.0-20180226025133-644b8db467af/go.mod h1:K08gAheRH3/J6wwsYMMT4xOr94bZjxIelGM0+d/wbFw= +github.com/alecthomas/template v0.0.0-20160405071501-a0175ee3bccc/go.mod h1:LOuyumcjzFXgccqObfd/Ljyb9UuFJ6TxHnclSeseNhc= +github.com/alecthomas/units v0.0.0-20151022065526-2efee857e7cf/go.mod h1:ybxpYRFXyAe+OPACYpWeL0wqObRcbAqCMya13uyzqw0= +github.com/andreyvit/diff v0.0.0-20170406064948-c7f18ee00883/go.mod h1:rCTlJbsFo29Kk6CurOXKm700vrz8f0KW0JNfpkRJY/8= +github.com/anmitsu/go-shlex v0.0.0-20161002113705-648efa622239/go.mod h1:2FmKhYUyUczH0OGQWaF5ceTx0UBShxjsH6f8oGKYe2c= +github.com/armon/circbuf v0.0.0-20150827004946-bbbad097214e/go.mod h1:3U/XgcO3hCbHZ8TKRvWD2dDTCfh9M9ya+I9JpbB7O8o= +github.com/armon/consul-api v0.0.0-20180202201655-eb2c6b5be1b6/go.mod h1:grANhF5doyWs3UAsr3K4I6qtAmlQcZDesFNEHPZAzj8= +github.com/asaskevich/govalidator v0.0.0-20180720115003-f9ffefc3facf/go.mod h1:lB+ZfQJz7igIIfQNfa7Ml4HSf2uFQQRzpGGRXenZAgY= +github.com/asaskevich/govalidator v0.0.0-20190424111038-f61b66f89f4a/go.mod h1:lB+ZfQJz7igIIfQNfa7Ml4HSf2uFQQRzpGGRXenZAgY= +github.com/auth0/go-jwt-middleware v0.0.0-20170425171159-5493cabe49f7/go.mod h1:LWMyo4iOLWXHGdBki7NIht1kHru/0wM179h+d3g8ATM= +github.com/aws/aws-sdk-go v1.28.2/go.mod h1:KmX6BPdI08NWTb3/sm4ZGu5ShLoqVDhKgpiN924inxo= +github.com/bazelbuild/bazel-gazelle v0.18.2/go.mod h1:D0ehMSbS+vesFsLGiD6JXu3mVEzOlfUl8wNnq+x/9p0= +github.com/bazelbuild/bazel-gazelle v0.19.1-0.20191105222053-70208cbdc798/go.mod h1:rPwzNHUqEzngx1iVBfO/2X2npKaT3tqPqqHW6rVsn/A= +github.com/bazelbuild/buildtools v0.0.0-20190731111112-f720930ceb60/go.mod h1:5JP0TXzWDHXv8qvxRC4InIazwdyDseBDbzESUMKk1yU= +github.com/bazelbuild/buildtools v0.0.0-20190917191645-69366ca98f89/go.mod h1:5JP0TXzWDHXv8qvxRC4InIazwdyDseBDbzESUMKk1yU= +github.com/bazelbuild/rules_go v0.0.0-20190719190356-6dae44dc5cab/go.mod h1:MC23Dc/wkXEyk3Wpq6lCqz0ZAYOZDw2DR5y3N1q2i7M= +github.com/beorn7/perks v0.0.0-20180321164747-3a771d992973/go.mod h1:Dwedo/Wpr24TaqPxmxbtue+5NUziq4I4S80YR8gNf3Q= +github.com/beorn7/perks v1.0.0 h1:HWo1m869IqiPhD389kmkxeTalrjNbbJTC8LXupb+sl0= +github.com/beorn7/perks v1.0.0/go.mod h1:KWe93zE9D1o94FZ5RNwFwVgaQK1VOXiVxmqh+CedLV8= +github.com/bgentry/speakeasy v0.1.0/go.mod h1:+zsyZBPWlz7T6j88CTgSN5bM796AkVf0kBD4zp0CCIs= +github.com/bifurcation/mint v0.0.0-20180715133206-93c51c6ce115/go.mod h1:zVt7zX3K/aDCk9Tj+VM7YymsX66ERvzCJzw8rFCX2JU= +github.com/blang/semver v3.5.0+incompatible h1:CGxCgetQ64DKk7rdZ++Vfnb1+ogGNnB17OJKJXD2Cfs= +github.com/blang/semver v3.5.0+incompatible/go.mod h1:kRBLl5iJ+tD4TcOOxsy/0fnwebNt5EWlYSAyrTnjyyk= +github.com/boltdb/bolt v1.3.1/go.mod h1:clJnj/oiGkjum5o1McbSZDSLxVThjynRyGBgiAx27Ps= +github.com/bradfitz/go-smtpd v0.0.0-20170404230938-deb6d6237625/go.mod h1:HYsPBTaaSFSlLx/70C2HPIMNZpVV8+vt/A+FMnYP11g= +github.com/caddyserver/caddy v1.0.3/go.mod h1:G+ouvOY32gENkJC+jhgl62TyhvqEsFaDiZ4uw0RzP1E= +github.com/cenkalti/backoff v2.1.1+incompatible/go.mod h1:90ReRw6GdpyfrHakVjL/QHaoyV4aDUVVkXQJJJ3NXXM= +github.com/census-instrumentation/opencensus-proto v0.2.1/go.mod h1:f6KPmirojxKA12rnyqOA5BBL4O983OfeGPqjHWSTneU= +github.com/cespare/prettybench v0.0.0-20150116022406-03b8cfe5406c/go.mod h1:Xe6ZsFhtM8HrDku0pxJ3/Lr51rwykrzgFwpmTzleatY= +github.com/chai2010/gettext-go v0.0.0-20160711120539-c6fed771bfd5/go.mod h1:/iP1qXHoty45bqomnu2LM+VVyAEdWN+vtSHGlQgyxbw= +github.com/checkpoint-restore/go-criu v0.0.0-20181120144056-17b0214f6c48/go.mod h1:TrMrLQfeENAPYPRsJuq3jsqdlRh3lvi6trTZJG8+tho= +github.com/cheekybits/genny v0.0.0-20170328200008-9127e812e1e9/go.mod h1:+tQajlRqAUrPI7DOSpB0XAqZYtQakVtB7wXkRAgjxjQ= +github.com/cilium/ebpf v0.0.0-20191025125908-95b36a581eed/go.mod h1:MA5e5Lr8slmEg9bt0VpxxWqJlO4iwu3FBdHUzV7wQVg= +github.com/client9/misspell v0.3.4/go.mod h1:qj6jICC3Q7zFZvVWo7KLAzC3yx5G7kyvSDkc90ppPyw= +github.com/clusterhq/flocker-go v0.0.0-20160920122132-2b8b7259d313/go.mod h1:P1wt9Z3DP8O6W3rvwCt0REIlshg1InHImaLW0t3ObY0= +github.com/cockroachdb/datadriven v0.0.0-20190809214429-80d97fb3cbaa h1:OaNxuTZr7kxeODyLWsRMC+OD03aFUH+mW6r2d+MWa5Y= +github.com/cockroachdb/datadriven v0.0.0-20190809214429-80d97fb3cbaa/go.mod h1:zn76sxSg3SzpJ0PPJaLDCu+Bu0Lg3sKTORVIj19EIF8= +github.com/codegangsta/negroni v1.0.0/go.mod h1:v0y3T5G7Y1UlFfyxFn/QLRU4a2EuNau2iZY63YTKWo0= +github.com/container-storage-interface/spec v1.2.0/go.mod h1:6URME8mwIBbpVyZV93Ce5St17xBiQJQY67NDsuohiy4= +github.com/containerd/console v0.0.0-20170925154832-84eeaae905fa/go.mod h1:Tj/on1eG8kiEhd0+fhSDzsPAFESxzBBvdyEgyryXffw= +github.com/containerd/containerd v1.0.2/go.mod h1:bC6axHOhabU15QhwfG7w5PipXdVtMXFTttgp+kVtyUA= +github.com/containerd/typeurl v0.0.0-20190228175220-2a93cfde8c20/go.mod h1:Cm3kwCdlkCfMSHURc+r6fwoGH6/F1hH3S4sg0rLFWPc= +github.com/containernetworking/cni v0.7.1/go.mod h1:LGwApLUm2FpoOfxTDEeq8T9ipbpZ61X79hmU3w8FmsY= +github.com/coredns/corefile-migration v1.0.6/go.mod h1:OFwBp/Wc9dJt5cAZzHWMNhK1r5L0p0jDwIBc6j8NC8E= +github.com/coreos/etcd v3.3.10+incompatible/go.mod h1:uF7uidLiAD3TWHmW31ZFd/JWoc32PjwdhPthX9715RE= +github.com/coreos/go-etcd v2.0.0+incompatible/go.mod h1:Jez6KQU2B/sWsbdaef3ED8NzMklzPG4d5KIOhIy30Tk= +github.com/coreos/go-oidc v2.1.0+incompatible/go.mod h1:CgnwVTmzoESiwO9qyAFEMiHoZ1nMCKZlZ9V6mm3/LKc= +github.com/coreos/go-semver v0.2.0/go.mod h1:nnelYz7RCh+5ahJtPPxZlU+153eP4D4r3EedlOD2RNk= +github.com/coreos/go-semver v0.3.0 h1:wkHLiw0WNATZnSG7epLsujiMCgPAc9xhjJ4tgnAxmfM= +github.com/coreos/go-semver v0.3.0/go.mod h1:nnelYz7RCh+5ahJtPPxZlU+153eP4D4r3EedlOD2RNk= +github.com/coreos/go-systemd v0.0.0-20180511133405-39ca1b05acc7/go.mod h1:F5haX7vjVVG0kc13fIWeqUViNPyEJxv/OmvnBo0Yme4= +github.com/coreos/go-systemd v0.0.0-20181012123002-c6f51f82210d/go.mod h1:F5haX7vjVVG0kc13fIWeqUViNPyEJxv/OmvnBo0Yme4= +github.com/coreos/go-systemd v0.0.0-20190321100706-95778dfbb74e h1:Wf6HqHfScWJN9/ZjdUKyjop4mf3Qdd+1TvvltAvM3m8= +github.com/coreos/go-systemd v0.0.0-20190321100706-95778dfbb74e/go.mod h1:F5haX7vjVVG0kc13fIWeqUViNPyEJxv/OmvnBo0Yme4= +github.com/coreos/pkg v0.0.0-20160727233714-3ac0863d7acf/go.mod h1:E3G3o1h8I7cfcXa63jLwjI0eiQQMgzzUDFVpN/nH/eA= +github.com/coreos/pkg v0.0.0-20180108230652-97fdf19511ea h1:n2Ltr3SrfQlf/9nOna1DoGKxLx3qTSI8Ttl6Xrqp6mw= +github.com/coreos/pkg v0.0.0-20180108230652-97fdf19511ea/go.mod h1:E3G3o1h8I7cfcXa63jLwjI0eiQQMgzzUDFVpN/nH/eA= +github.com/cpuguy83/go-md2man v1.0.10/go.mod h1:SmD6nW6nTyfqj6ABTjUi3V3JVMnlJmwcJI5acqYI6dE= +github.com/creack/pty v1.1.7/go.mod h1:lj5s0c3V2DBrqTV7llrYr5NG6My20zk30Fl46Y7DoTY= +github.com/cyphar/filepath-securejoin v0.2.2/go.mod h1:FpkQEhXnPnOthhzymB7CGsFk2G9VLXONKD9G7QGMM+4= +github.com/davecgh/go-spew v1.1.0/go.mod h1:J7Y8YcW2NihsgmVo/mv3lAwl/skON4iLHjSsI+c5H38= +github.com/davecgh/go-spew v1.1.1 h1:vj9j/u1bqnvCEfJOwUhtlOARqs3+rkHYY13jYWTU97c= +github.com/davecgh/go-spew v1.1.1/go.mod h1:J7Y8YcW2NihsgmVo/mv3lAwl/skON4iLHjSsI+c5H38= +github.com/daviddengcn/go-colortext v0.0.0-20160507010035-511bcaf42ccd/go.mod h1:dv4zxwHi5C/8AeI+4gX4dCWOIvNi7I6JCSX0HvlKPgE= +github.com/dgrijalva/jwt-go v3.2.0+incompatible h1:7qlOGliEKZXTDg6OTjfoBKDXWrumCAMpl/TFQ4/5kLM= +github.com/dgrijalva/jwt-go v3.2.0+incompatible/go.mod h1:E3ru+11k8xSBh+hMPgOLZmtrrCbhqsmaPHjLKYnJCaQ= +github.com/dnaeon/go-vcr v1.0.1/go.mod h1:aBB1+wY4s93YsC3HHjMBMrwTj2R9FHDzUr9KyGc8n1E= +github.com/docker/distribution v2.7.1+incompatible h1:a5mlkVzth6W5A4fOsS3D2EO5BUmsJpcB+cRlLU7cSug= +github.com/docker/distribution v2.7.1+incompatible/go.mod h1:J2gT2udsDAN96Uj4KfcMRqY0/ypR+oyYUYmja8H+y+w= +github.com/docker/docker v0.7.3-0.20190327010347-be7ac8be2ae0/go.mod h1:eEKB0N0r5NX/I1kEveEz05bcu8tLC/8azJZsviup8Sk= +github.com/docker/go-connections v0.3.0/go.mod h1:Gbd7IOopHjR8Iph03tsViu4nIes5XhDvyHbTtUxmeec= +github.com/docker/go-units v0.3.3/go.mod h1:fgPhTUdO+D/Jk86RDLlptpiXQzgHJF7gydDDbaIK4Dk= +github.com/docker/go-units v0.4.0/go.mod h1:fgPhTUdO+D/Jk86RDLlptpiXQzgHJF7gydDDbaIK4Dk= +github.com/docker/spdystream v0.0.0-20160310174837-449fdfce4d96/go.mod h1:Qh8CwZgvJUkLughtfhJv5dyTYa91l1fOUCrgjqmcifM= +github.com/dustin/go-humanize v0.0.0-20171111073723-bb3d318650d4/go.mod h1:HtrtbFcZ19U5GC7JDqmcUSB87Iq5E25KnS6fMYU6eOk= +github.com/dustin/go-humanize v1.0.0 h1:VSnTsYCnlFHaM2/igO1h6X3HA71jcobQuxemgkq4zYo= +github.com/dustin/go-humanize v1.0.0/go.mod h1:HtrtbFcZ19U5GC7JDqmcUSB87Iq5E25KnS6fMYU6eOk= +github.com/elazarl/goproxy v0.0.0-20180725130230-947c36da3153/go.mod h1:/Zj4wYkgs4iZTTu3o/KG3Itv/qCCa8VVMlb3i9OVuzc= +github.com/emicklei/go-restful v0.0.0-20170410110728-ff4f55a20633/go.mod h1:otzb+WCGbkyDHkqmQmT5YD2WR4BBwUdeQoFo8l/7tVs= +github.com/emicklei/go-restful v2.9.5+incompatible/go.mod h1:otzb+WCGbkyDHkqmQmT5YD2WR4BBwUdeQoFo8l/7tVs= +github.com/envoyproxy/go-control-plane v0.9.1-0.20191026205805-5f8ba28d4473/go.mod h1:YTl/9mNaCwkRvm6d1a2C3ymFceY/DCBVvsKhRF0iEA4= +github.com/envoyproxy/protoc-gen-validate v0.1.0/go.mod h1:iSmxcyjqTsJpI2R4NaDN7+kN2VEUnK/pcBlmesArF7c= +github.com/euank/go-kmsg-parser v2.0.0+incompatible/go.mod h1:MhmAMZ8V4CYH4ybgdRwPr2TU5ThnS43puaKEMpja1uw= +github.com/evanphx/json-patch v4.2.0+incompatible/go.mod h1:50XU6AFN0ol/bzJsmQLiYLvXMP4fmwYFNcr97nuDLSk= +github.com/exponent-io/jsonpath v0.0.0-20151013193312-d6023ce2651d/go.mod h1:ZZMPRZwes7CROmyNKgQzC3XPs6L/G2EJLHddWejkmf4= +github.com/fatih/camelcase v1.0.0/go.mod h1:yN2Sb0lFhZJUdVvtELVWefmrXpuZESvPmqwoZc+/fpc= +github.com/fatih/color v1.6.0/go.mod h1:Zm6kSWBoL9eyXnKyktHP6abPY2pDugNf5KwzbycvMj4= +github.com/fatih/color v1.7.0/go.mod h1:Zm6kSWBoL9eyXnKyktHP6abPY2pDugNf5KwzbycvMj4= +github.com/flynn/go-shlex v0.0.0-20150515145356-3f9db97f8568/go.mod h1:xEzjJPgXI435gkrCt3MPfRiAkVrwSbHsst4LCFVfpJc= +github.com/fogleman/gg v1.2.1-0.20190220221249-0403632d5b90/go.mod h1:R/bRT+9gY/C5z7JzPU0zXsXHKM4/ayA+zqcVNZzPa1k= +github.com/fsnotify/fsnotify v1.4.7/go.mod h1:jwhsz4b93w/PPRr/qN1Yymfu8t87LnFCMoQvtojpjFo= +github.com/ghodss/yaml v0.0.0-20150909031657-73d445a93680/go.mod h1:4dBDuWmgqj2HViK6kFavaiC9ZROes6MMH2rRYeMEF04= +github.com/ghodss/yaml v1.0.0/go.mod h1:4dBDuWmgqj2HViK6kFavaiC9ZROes6MMH2rRYeMEF04= +github.com/gliderlabs/ssh v0.1.1/go.mod h1:U7qILu1NlMHj9FlMhZLlkCdDnU1DBEAqr0aevW3Awn0= +github.com/globalsign/mgo v0.0.0-20180905125535-1ca0a4f7cbcb/go.mod h1:xkRDCp4j0OGD1HRkm4kmhM+pmpv3AKq5SU7GMg4oO/Q= +github.com/globalsign/mgo v0.0.0-20181015135952-eeefdecb41b8/go.mod h1:xkRDCp4j0OGD1HRkm4kmhM+pmpv3AKq5SU7GMg4oO/Q= +github.com/go-acme/lego v2.5.0+incompatible/go.mod h1:yzMNe9CasVUhkquNvti5nAtPmG94USbYxYrZfTkIn0M= +github.com/go-bindata/go-bindata v3.1.1+incompatible/go.mod h1:xK8Dsgwmeed+BBsSy2XTopBn/8uK2HWuGSnA11C3Joo= +github.com/go-critic/go-critic v0.3.5-0.20190526074819-1df300866540/go.mod h1:+sE8vrLDS2M0pZkBk0wy6+nLdKexVDrl/jBqQOTDThA= +github.com/go-kit/kit v0.8.0/go.mod h1:xBxKIO96dXMWWy0MnWVtmwkA9/13aqxPnvrjFYMA2as= +github.com/go-lintpack/lintpack v0.5.2/go.mod h1:NwZuYi2nUHho8XEIZ6SIxihrnPoqBTDqfpXvXAN0sXM= +github.com/go-logfmt/logfmt v0.3.0/go.mod h1:Qt1PoO58o5twSAckw1HlFXLmHsOX5/0LbT9GBnD5lWE= +github.com/go-logr/logr v0.1.0/go.mod h1:ixOQHD9gLJUVQQ2ZOR7zLEifBX6tGkNJF4QyIY7sIas= +github.com/go-ole/go-ole v1.2.1/go.mod h1:7FAglXiTm7HKlQRDeOQ6ZNUHidzCWXuZWq/1dTyBNF8= +github.com/go-openapi/analysis v0.0.0-20180825180245-b006789cd277/go.mod h1:k70tL6pCuVxPJOHXQ+wIac1FUrvNkHolPie/cLEU6hI= +github.com/go-openapi/analysis v0.17.0/go.mod h1:IowGgpVeD0vNm45So8nr+IcQ3pxVtpRoBWb8PVZO0ik= +github.com/go-openapi/analysis v0.18.0/go.mod h1:IowGgpVeD0vNm45So8nr+IcQ3pxVtpRoBWb8PVZO0ik= +github.com/go-openapi/analysis v0.19.2/go.mod h1:3P1osvZa9jKjb8ed2TPng3f0i/UY9snX6gxi44djMjk= +github.com/go-openapi/analysis v0.19.5/go.mod h1:hkEAkxagaIvIP7VTn8ygJNkd4kAYON2rCu0v0ObL0AU= +github.com/go-openapi/errors v0.17.0/go.mod h1:LcZQpmvG4wyF5j4IhA73wkLFQg+QJXOQHVjmcZxhka0= +github.com/go-openapi/errors v0.18.0/go.mod h1:LcZQpmvG4wyF5j4IhA73wkLFQg+QJXOQHVjmcZxhka0= +github.com/go-openapi/errors v0.19.2/go.mod h1:qX0BLWsyaKfvhluLejVpVNwNRdXZhEbTA4kxxpKBC94= +github.com/go-openapi/jsonpointer v0.0.0-20160704185906-46af16f9f7b1/go.mod h1:+35s3my2LFTysnkMfxsJBAMHj/DoqoB9knIWoYG/Vk0= +github.com/go-openapi/jsonpointer v0.17.0/go.mod h1:cOnomiV+CVVwFLk0A/MExoFMjwdsUdVpsRhURCKh+3M= +github.com/go-openapi/jsonpointer v0.18.0/go.mod h1:cOnomiV+CVVwFLk0A/MExoFMjwdsUdVpsRhURCKh+3M= +github.com/go-openapi/jsonpointer v0.19.2/go.mod h1:3akKfEdA7DF1sugOqz1dVQHBcuDBPKZGEoHC/NkiQRg= +github.com/go-openapi/jsonpointer v0.19.3/go.mod h1:Pl9vOtqEWErmShwVjC8pYs9cog34VGT37dQOVbmoatg= +github.com/go-openapi/jsonreference v0.0.0-20160704190145-13c6e3589ad9/go.mod h1:W3Z9FmVs9qj+KR4zFKmDPGiLdk1D9Rlm7cyMvf57TTg= +github.com/go-openapi/jsonreference v0.17.0/go.mod h1:g4xxGn04lDIRh0GJb5QlpE3HfopLOL6uZrK/VgnsK9I= +github.com/go-openapi/jsonreference v0.18.0/go.mod h1:g4xxGn04lDIRh0GJb5QlpE3HfopLOL6uZrK/VgnsK9I= +github.com/go-openapi/jsonreference v0.19.2/go.mod h1:jMjeRr2HHw6nAVajTXJ4eiUwohSTlpa0o73RUL1owJc= +github.com/go-openapi/jsonreference v0.19.3/go.mod h1:rjx6GuL8TTa9VaixXglHmQmIL98+wF9xc8zWvFonSJ8= +github.com/go-openapi/loads v0.17.0/go.mod h1:72tmFy5wsWx89uEVddd0RjRWPZm92WRLhf7AC+0+OOU= +github.com/go-openapi/loads v0.18.0/go.mod h1:72tmFy5wsWx89uEVddd0RjRWPZm92WRLhf7AC+0+OOU= +github.com/go-openapi/loads v0.19.0/go.mod h1:72tmFy5wsWx89uEVddd0RjRWPZm92WRLhf7AC+0+OOU= +github.com/go-openapi/loads v0.19.2/go.mod h1:QAskZPMX5V0C2gvfkGZzJlINuP7Hx/4+ix5jWFxsNPs= +github.com/go-openapi/loads v0.19.4/go.mod h1:zZVHonKd8DXyxyw4yfnVjPzBjIQcLt0CCsn0N0ZrQsk= +github.com/go-openapi/runtime v0.0.0-20180920151709-4f900dc2ade9/go.mod h1:6v9a6LTXWQCdL8k1AO3cvqx5OtZY/Y9wKTgaoP6YRfA= +github.com/go-openapi/runtime v0.19.0/go.mod h1:OwNfisksmmaZse4+gpV3Ne9AyMOlP1lt4sK4FXt0O64= +github.com/go-openapi/runtime v0.19.4/go.mod h1:X277bwSUBxVlCYR3r7xgZZGKVvBd/29gLDlFGtJ8NL4= +github.com/go-openapi/spec v0.0.0-20160808142527-6aced65f8501/go.mod h1:J8+jY1nAiCcj+friV/PDoE1/3eeccG9LYBs0tYvLOWc= +github.com/go-openapi/spec v0.17.0/go.mod h1:XkF/MOi14NmjsfZ8VtAKf8pIlbZzyoTvZsdfssdxcBI= +github.com/go-openapi/spec v0.18.0/go.mod h1:XkF/MOi14NmjsfZ8VtAKf8pIlbZzyoTvZsdfssdxcBI= +github.com/go-openapi/spec v0.19.2/go.mod h1:sCxk3jxKgioEJikev4fgkNmwS+3kuYdJtcsZsD5zxMY= +github.com/go-openapi/spec v0.19.3/go.mod h1:FpwSN1ksY1eteniUU7X0N/BgJ7a4WvBFVA8Lj9mJglo= +github.com/go-openapi/strfmt v0.17.0/go.mod h1:P82hnJI0CXkErkXi8IKjPbNBM6lV6+5pLP5l494TcyU= +github.com/go-openapi/strfmt v0.18.0/go.mod h1:P82hnJI0CXkErkXi8IKjPbNBM6lV6+5pLP5l494TcyU= +github.com/go-openapi/strfmt v0.19.0/go.mod h1:+uW+93UVvGGq2qGaZxdDeJqSAqBqBdl+ZPMF/cC8nDY= +github.com/go-openapi/strfmt v0.19.3/go.mod h1:0yX7dbo8mKIvc3XSKp7MNfxw4JytCfCD6+bY1AVL9LU= +github.com/go-openapi/swag v0.0.0-20160704191624-1d0bd113de87/go.mod h1:DXUve3Dpr1UfpPtxFw+EFuQ41HhCWZfha5jSVRG7C7I= +github.com/go-openapi/swag v0.17.0/go.mod h1:AByQ+nYG6gQg71GINrmuDXCPWdL640yX49/kXLo40Tg= +github.com/go-openapi/swag v0.18.0/go.mod h1:AByQ+nYG6gQg71GINrmuDXCPWdL640yX49/kXLo40Tg= +github.com/go-openapi/swag v0.19.2/go.mod h1:POnQmlKehdgb5mhVOsnJFsivZCEZ/vjK9gh66Z9tfKk= +github.com/go-openapi/swag v0.19.5/go.mod h1:POnQmlKehdgb5mhVOsnJFsivZCEZ/vjK9gh66Z9tfKk= +github.com/go-openapi/validate v0.18.0/go.mod h1:Uh4HdOzKt19xGIGm1qHf/ofbX1YQ4Y+MYsct2VUrAJ4= +github.com/go-openapi/validate v0.19.2/go.mod h1:1tRCw7m3jtI8eNWEEliiAqUIcBztB2KDnRCRMUi7GTA= +github.com/go-openapi/validate v0.19.5/go.mod h1:8DJv2CVJQ6kGNpFW6eV9N3JviE1C85nY1c2z52x1Gk4= +github.com/go-ozzo/ozzo-validation v3.5.0+incompatible/go.mod h1:gsEKFIVnabGBt6mXmxK0MoFy+cZoTJY6mu5Ll3LVLBU= +github.com/go-stack/stack v1.8.0/go.mod h1:v0f6uXyyMGvRgIKkXu+yp6POWl0qKG85gN/melR3HDY= +github.com/go-toolsmith/astcast v1.0.0/go.mod h1:mt2OdQTeAQcY4DQgPSArJjHCcOwlX+Wl/kwN+LbLGQ4= +github.com/go-toolsmith/astcopy v1.0.0/go.mod h1:vrgyG+5Bxrnz4MZWPF+pI4R8h3qKRjjyvV/DSez4WVQ= +github.com/go-toolsmith/astequal v0.0.0-20180903214952-dcb477bfacd6/go.mod h1:H+xSiq0+LtiDC11+h1G32h7Of5O3CYFJ99GVbS5lDKY= +github.com/go-toolsmith/astequal v1.0.0/go.mod h1:H+xSiq0+LtiDC11+h1G32h7Of5O3CYFJ99GVbS5lDKY= +github.com/go-toolsmith/astfmt v0.0.0-20180903215011-8f8ee99c3086/go.mod h1:mP93XdblcopXwlyN4X4uodxXQhldPGZbcEJIimQHrkg= +github.com/go-toolsmith/astfmt v1.0.0/go.mod h1:cnWmsOAuq4jJY6Ct5YWlVLmcmLMn1JUPuQIHCY7CJDw= +github.com/go-toolsmith/astinfo v0.0.0-20180906194353-9809ff7efb21/go.mod h1:dDStQCHtmZpYOmjRP/8gHHnCCch3Zz3oEgCdZVdtweU= +github.com/go-toolsmith/astp v0.0.0-20180903215135-0af7e3c24f30/go.mod h1:SV2ur98SGypH1UjcPpCatrV5hPazG6+IfNHbkDXBRrk= +github.com/go-toolsmith/astp v1.0.0/go.mod h1:RSyrtpVlfTFGDYRbrjyWP1pYu//tSFcvdYrA8meBmLI= +github.com/go-toolsmith/pkgload v0.0.0-20181119091011-e9e65178eee8/go.mod h1:WoMrjiy4zvdS+Bg6z9jZH82QXwkcgCBX6nOfnmdaHks= +github.com/go-toolsmith/pkgload v1.0.0/go.mod h1:5eFArkbO80v7Z0kdngIxsRXRMTaX4Ilcwuh3clNrQJc= +github.com/go-toolsmith/strparse v1.0.0/go.mod h1:YI2nUKP9YGZnL/L1/DLFBfixrcjslWct4wyljWhSRy8= +github.com/go-toolsmith/typep v1.0.0/go.mod h1:JSQCQMUPdRlMZFswiq3TGpNp1GMktqkR2Ns5AIQkATU= +github.com/gobwas/glob v0.2.3/go.mod h1:d3Ez4x06l9bZtSvzIay5+Yzi0fmZzPgnTbPcKjJAkT8= +github.com/godbus/dbus v0.0.0-20181101234600-2ff6f7ffd60f/go.mod h1:/YcGZj5zSblfDWMMoOzV4fas9FZnQYTkDnsGvmh2Grw= +github.com/gogo/protobuf v1.1.1/go.mod h1:r8qH/GZQm5c6nD/R0oafs1akxWv10x8SbQlK7atdtwQ= +github.com/gogo/protobuf v1.2.1/go.mod h1:hp+jE20tsWTFYpLwKvXlhS1hjn+gTNwPg2I6zVXpSg4= +github.com/gogo/protobuf v1.3.1 h1:DqDEcV5aeaTmdFBePNpYsp3FlcVH/2ISVVM9Qf8PSls= +github.com/gogo/protobuf v1.3.1/go.mod h1:SlYgWuQ5SjCEi6WLHjHCa1yvBfUnHcTbrrZtXPKa29o= +github.com/golang/freetype v0.0.0-20170609003504-e2365dfdc4a0/go.mod h1:E/TSTwGwJL78qG/PmXZO1EjYhfJinVAhrmmHX6Z8B9k= +github.com/golang/glog v0.0.0-20160126235308-23def4e6c14b h1:VKtxabqXZkF25pY9ekfRL6a582T4P37/31XEstQ5p58= +github.com/golang/glog v0.0.0-20160126235308-23def4e6c14b/go.mod h1:SBH7ygxi8pfUlaOkMMuAQtPIUF8ecWP5IEl/CR7VP2Q= +github.com/golang/groupcache v0.0.0-20160516000752-02826c3e7903 h1:LbsanbbD6LieFkXbj9YNNBupiGHJgFeLpO0j0Fza1h8= +github.com/golang/groupcache v0.0.0-20160516000752-02826c3e7903/go.mod h1:cIg4eruTrX1D+g88fzRXU5OdNfaM+9IcxsU14FzY7Hc= +github.com/golang/mock v1.0.0/go.mod h1:oTYuIxOrZwtPieC+H1uAHpcLFnEyAGVDL/k47Jfbm0A= +github.com/golang/mock v1.1.1/go.mod h1:oTYuIxOrZwtPieC+H1uAHpcLFnEyAGVDL/k47Jfbm0A= +github.com/golang/mock v1.2.0/go.mod h1:oTYuIxOrZwtPieC+H1uAHpcLFnEyAGVDL/k47Jfbm0A= +github.com/golang/mock v1.3.1/go.mod h1:sBzyDLLjw3U8JLTeZvSv8jJB+tU5PVekmnlKIyFUx0Y= +github.com/golang/protobuf v0.0.0-20161109072736-4bd1920723d7/go.mod h1:6lQm79b+lXiMfvg/cZm0SGofjICqVBUtrP5yJMmIC1U= +github.com/golang/protobuf v1.2.0/go.mod h1:6lQm79b+lXiMfvg/cZm0SGofjICqVBUtrP5yJMmIC1U= +github.com/golang/protobuf v1.3.1/go.mod h1:6lQm79b+lXiMfvg/cZm0SGofjICqVBUtrP5yJMmIC1U= +github.com/golang/protobuf v1.3.2 h1:6nsPYzhq5kReh6QImI3k5qWzO4PEbvbIW2cwSfR/6xs= +github.com/golang/protobuf v1.3.2/go.mod h1:6lQm79b+lXiMfvg/cZm0SGofjICqVBUtrP5yJMmIC1U= +github.com/golangci/check v0.0.0-20180506172741-cfe4005ccda2/go.mod h1:k9Qvh+8juN+UKMCS/3jFtGICgW8O96FVaZsaxdzDkR4= +github.com/golangci/dupl v0.0.0-20180902072040-3e9179ac440a/go.mod h1:ryS0uhF+x9jgbj/N71xsEqODy9BN81/GonCZiOzirOk= +github.com/golangci/errcheck v0.0.0-20181223084120-ef45e06d44b6/go.mod h1:DbHgvLiFKX1Sh2T1w8Q/h4NAI8MHIpzCdnBUDTXU3I0= +github.com/golangci/go-misc v0.0.0-20180628070357-927a3d87b613/go.mod h1:SyvUF2NxV+sN8upjjeVYr5W7tyxaT1JVtvhKhOn2ii8= +github.com/golangci/go-tools v0.0.0-20190318055746-e32c54105b7c/go.mod h1:unzUULGw35sjyOYjUt0jMTXqHlZPpPc6e+xfO4cd6mM= +github.com/golangci/goconst v0.0.0-20180610141641-041c5f2b40f3/go.mod h1:JXrF4TWy4tXYn62/9x8Wm/K/dm06p8tCKwFRDPZG/1o= +github.com/golangci/gocyclo v0.0.0-20180528134321-2becd97e67ee/go.mod h1:ozx7R9SIwqmqf5pRP90DhR2Oay2UIjGuKheCBCNwAYU= +github.com/golangci/gofmt v0.0.0-20181222123516-0b8337e80d98/go.mod h1:9qCChq59u/eW8im404Q2WWTrnBUQKjpNYKMbU4M7EFU= +github.com/golangci/golangci-lint v1.18.0/go.mod h1:kaqo8l0OZKYPtjNmG4z4HrWLgcYNIJ9B9q3LWri9uLg= +github.com/golangci/gosec v0.0.0-20190211064107-66fb7fc33547/go.mod h1:0qUabqiIQgfmlAmulqxyiGkkyF6/tOGSnY2cnPVwrzU= +github.com/golangci/ineffassign v0.0.0-20190609212857-42439a7714cc/go.mod h1:e5tpTHCfVze+7EpLEozzMB3eafxo2KT5veNg1k6byQU= +github.com/golangci/lint-1 v0.0.0-20190420132249-ee948d087217/go.mod h1:66R6K6P6VWk9I95jvqGxkqJxVWGFy9XlDwLwVz1RCFg= +github.com/golangci/maligned v0.0.0-20180506175553-b1d89398deca/go.mod h1:tvlJhZqDe4LMs4ZHD0oMUlt9G2LWuDGoisJTBzLMV9o= +github.com/golangci/misspell v0.0.0-20180809174111-950f5d19e770/go.mod h1:dEbvlSfYbMQDtrpRMQU675gSDLDNa8sCPPChZ7PhiVA= +github.com/golangci/prealloc v0.0.0-20180630174525-215b22d4de21/go.mod h1:tf5+bzsHdTM0bsB7+8mt0GUMvjCgwLpTapNZHU8AajI= +github.com/golangci/revgrep v0.0.0-20180526074752-d9c87f5ffaf0/go.mod h1:qOQCunEYvmd/TLamH+7LlVccLvUH5kZNhbCgTHoBbp4= +github.com/golangci/unconvert v0.0.0-20180507085042-28b1c447d1f4/go.mod h1:Izgrg8RkN3rCIMLGE9CyYmU9pY2Jer6DgANEnZ/L/cQ= +github.com/golangplus/bytes v0.0.0-20160111154220-45c989fe5450/go.mod h1:Bk6SMAONeMXrxql8uvOKuAZSu8aM5RUGv+1C6IJaEho= +github.com/golangplus/fmt v0.0.0-20150411045040-2a5d6d7d2995/go.mod h1:lJgMEyOkYFkPcDKwRXegd+iM6E7matEszMG5HhwytU8= +github.com/golangplus/testing v0.0.0-20180327235837-af21d9c3145e/go.mod h1:0AA//k/eakGydO4jKRoRL2j92ZKSzTgj9tclaCrvXHk= +github.com/google/btree v0.0.0-20180813153112-4030bb1f1f0c/go.mod h1:lNA+9X1NB3Zf8V7Ke586lFgjr2dZNuvo3lPJSGZ5JPQ= +github.com/google/btree v1.0.0 h1:0udJVsspx3VBr5FwtLhQQtuAsVc79tTq0ocGIPAU6qo= +github.com/google/btree v1.0.0/go.mod h1:lNA+9X1NB3Zf8V7Ke586lFgjr2dZNuvo3lPJSGZ5JPQ= +github.com/google/cadvisor v0.35.0/go.mod h1:1nql6U13uTHaLYB8rLS5x9IJc2qT6Xd/Tr1sTX6NE48= +github.com/google/go-cmp v0.2.0/go.mod h1:oXzfMopK8JAjlY9xF4vHSVASa0yLyX7SntLO5aqRK0M= +github.com/google/go-cmp v0.3.0 h1:crn/baboCvb5fXaQ0IJ1SGTsTVrWpDsCWC8EGETZijY= +github.com/google/go-cmp v0.3.0/go.mod h1:8QqcDgzrUqlUb/G2PQTWiueGozuR1884gddMywk6iLU= +github.com/google/go-github v17.0.0+incompatible/go.mod h1:zLgOLi98H3fifZn+44m+umXrS52loVEgC2AApnigrVQ= +github.com/google/go-querystring v1.0.0/go.mod h1:odCYkC5MyYFN7vkCjXpyrEuKhc/BUO6wN/zVPAxq5ck= +github.com/google/gofuzz v1.0.0/go.mod h1:dBl0BpW6vV/+mYPU4Po3pmUjxk6FQPldtuIdl/M65Eg= +github.com/google/gofuzz v1.1.0 h1:Hsa8mG0dQ46ij8Sl2AYJDUv1oA9/d6Vk+3LG99Oe02g= +github.com/google/gofuzz v1.1.0/go.mod h1:dBl0BpW6vV/+mYPU4Po3pmUjxk6FQPldtuIdl/M65Eg= +github.com/google/martian v2.1.0+incompatible/go.mod h1:9I4somxYTbIHy5NJKHRl3wXiIaQGbYVAs8BPL6v8lEs= +github.com/google/pprof v0.0.0-20181206194817-3ea8567a2e57/go.mod h1:zfwlbNMJ+OItoe0UupaVj+oy1omPYYDuagoSzA8v9mc= +github.com/google/renameio v0.1.0/go.mod h1:KWCgfxg9yswjAJkECMjeO8J8rahYeXnNhOm40UhjYkI= +github.com/google/uuid v1.0.0/go.mod h1:TIyPZe4MgqvfeYDBFedMoGGpEw/LqOeaOT+nhxU+yHo= +github.com/google/uuid v1.1.1 h1:Gkbcsh/GbpXz7lPftLA3P6TYMwjCLYm83jiFQZF/3gY= +github.com/google/uuid v1.1.1/go.mod h1:TIyPZe4MgqvfeYDBFedMoGGpEw/LqOeaOT+nhxU+yHo= +github.com/googleapis/gax-go/v2 v2.0.4/go.mod h1:0Wqv26UfaUD9n4G6kQubkQ+KchISgw+vpHVxEJEs9eg= +github.com/googleapis/gnostic v0.0.0-20170729233727-0c5108395e2d/go.mod h1:sJBsCZ4ayReDTBIg8b9dl28c5xFWyhBTVRp3pOg5EKY= +github.com/googleapis/gnostic v0.1.0/go.mod h1:sJBsCZ4ayReDTBIg8b9dl28c5xFWyhBTVRp3pOg5EKY= +github.com/gophercloud/gophercloud v0.1.0/go.mod h1:vxM41WHh5uqHVBMZHzuwNOHh8XEoIEcSTewFxm1c5g8= +github.com/gopherjs/gopherjs v0.0.0-20181017120253-0766667cb4d1/go.mod h1:wJfORRmW1u3UXTncJ5qlYoELFm8eSnnEO6hX4iZ3EWY= +github.com/gorilla/context v1.1.1/go.mod h1:kBGZzfjB9CEq2AlWe17Uuf7NDRt0dE0s8S51q0aT7Yg= +github.com/gorilla/mux v1.7.0/go.mod h1:1lud6UwP+6orDFRuTfBEV8e9/aOM/c4fVVCaMa2zaAs= +github.com/gorilla/websocket v0.0.0-20170926233335-4201258b820c/go.mod h1:E7qHFY5m1UJ88s3WnNqhKjPHQ0heANvMoAMk2YaljkQ= +github.com/gorilla/websocket v1.4.0 h1:WDFjx/TMzVgy9VdMMQi2K2Emtwi2QcUQsztZ/zLaH/Q= +github.com/gorilla/websocket v1.4.0/go.mod h1:E7qHFY5m1UJ88s3WnNqhKjPHQ0heANvMoAMk2YaljkQ= +github.com/gostaticanalysis/analysisutil v0.0.0-20190318220348-4088753ea4d3/go.mod h1:eEOZF4jCKGi+aprrirO9e7WKB3beBRtWgqGunKl6pKE= +github.com/gostaticanalysis/analysisutil v0.0.3/go.mod h1:eEOZF4jCKGi+aprrirO9e7WKB3beBRtWgqGunKl6pKE= +github.com/gregjones/httpcache v0.0.0-20180305231024-9cad4c3443a7/go.mod h1:FecbI9+v66THATjSRHfNgh1IVFe/9kFxbXtjV0ctIMA= +github.com/grpc-ecosystem/go-grpc-middleware v1.0.1-0.20190118093823-f849b5445de4 h1:z53tR0945TRRQO/fLEVPI6SMv7ZflF0TEaTAoU7tOzg= +github.com/grpc-ecosystem/go-grpc-middleware v1.0.1-0.20190118093823-f849b5445de4/go.mod h1:FiyG127CGDf3tlThmgyCl78X/SZQqEOJBCDaAfeWzPs= +github.com/grpc-ecosystem/go-grpc-prometheus v1.2.0 h1:Ovs26xHkKqVztRpIrF/92BcuyuQ/YW4NSIpoGtfXNho= +github.com/grpc-ecosystem/go-grpc-prometheus v1.2.0/go.mod h1:8NvIoxWQoOIhqOTXgfV/d3M/q6VIi02HzZEHgUlZvzk= +github.com/grpc-ecosystem/grpc-gateway v1.9.5 h1:UImYN5qQ8tuGpGE16ZmjvcTtTw24zw1QAp/SlnNrZhI= +github.com/grpc-ecosystem/grpc-gateway v1.9.5/go.mod h1:vNeuVxBJEsws4ogUvrchl83t/GYV9WGTSLVdBhOQFDY= +github.com/hashicorp/go-syslog v1.0.0/go.mod h1:qPfqrKkXGihmCqbJM2mZgkZGvKG1dFdvsLplgctolz4= +github.com/hashicorp/golang-lru v0.0.0-20180201235237-0fb14efe8c47/go.mod h1:/m3WP610KZHVQ1SGc6re/UDhFvYD7pJ4Ao+sR/qLZy8= +github.com/hashicorp/golang-lru v0.5.0/go.mod h1:/m3WP610KZHVQ1SGc6re/UDhFvYD7pJ4Ao+sR/qLZy8= +github.com/hashicorp/golang-lru v0.5.1 h1:0hERBMJE1eitiLkihrMvRVBYAkpHzc/J3QdDN+dAcgU= +github.com/hashicorp/golang-lru v0.5.1/go.mod h1:/m3WP610KZHVQ1SGc6re/UDhFvYD7pJ4Ao+sR/qLZy8= +github.com/hashicorp/hcl v0.0.0-20180404174102-ef8a98b0bbce/go.mod h1:oZtUIOe8dh44I2q6ScRibXws4Ajl+d+nod3AaR9vL5w= +github.com/hashicorp/hcl v1.0.0/go.mod h1:E5yfLk+7swimpb2L/Alb/PJmXilQ/rhwaUYs4T20WEQ= +github.com/heketi/heketi v9.0.1-0.20190917153846-c2e2a4ab7ab9+incompatible/go.mod h1:bB9ly3RchcQqsQ9CpyaQwvva7RS5ytVoSoholZQON6o= +github.com/heketi/tests v0.0.0-20151005000721-f3775cbcefd6/go.mod h1:xGMAM8JLi7UkZt1i4FQeQy0R2T8GLUwQhOP5M1gBhy4= +github.com/hpcloud/tail v1.0.0/go.mod h1:ab1qPbhIpdTxEkNHXyeSf5vhxWSCs/tWer42PpOxQnU= +github.com/imdario/mergo v0.3.5 h1:JboBksRwiiAJWvIYJVo46AfV+IAIKZpfrSzVKj42R4Q= +github.com/imdario/mergo v0.3.5/go.mod h1:2EnlNZ0deacrJVfApfmtdGgDfMuh/nq6Ok1EcJh5FfA= +github.com/inconshreveable/mousetrap v1.0.0/go.mod h1:PxqpIevigyE2G7u3NXJIT2ANytuPF1OarO4DADm73n8= +github.com/jellevandenhooff/dkim v0.0.0-20150330215556-f50fe3d243e1/go.mod h1:E0B/fFc00Y+Rasa88328GlI/XbtyysCtTHZS8h7IrBU= +github.com/jimstudt/http-authentication v0.0.0-20140401203705-3eca13d6893a/go.mod h1:wK6yTYYcgjHE1Z1QtXACPDjcFJyBskHEdagmnq3vsP8= +github.com/jmespath/go-jmespath v0.0.0-20180206201540-c2b33e8439af/go.mod h1:Nht3zPeWKUH0NzdCt2Blrr5ys8VGpn0CEB0cQHVjt7k= +github.com/jonboulle/clockwork v0.1.0 h1:VKV+ZcuP6l3yW9doeqz6ziZGgcynBVQO+obU0+0hcPo= +github.com/jonboulle/clockwork v0.1.0/go.mod h1:Ii8DK3G1RaLaWxj9trq07+26W01tbo22gdxWY5EU2bo= +github.com/json-iterator/go v1.1.6/go.mod h1:+SdeFBvtyEkXs7REEP0seUULqWtbJapLOCVDaaPEHmU= +github.com/json-iterator/go v1.1.7/go.mod h1:KdQUCv79m/52Kvf8AW2vK1V8akMuk1QjK/uOdHXbAo4= +github.com/json-iterator/go v1.1.8 h1:QiWkFLKq0T7mpzwOTu6BzNDbfTE8OLrYhVKYMLF46Ok= +github.com/json-iterator/go v1.1.8/go.mod h1:KdQUCv79m/52Kvf8AW2vK1V8akMuk1QjK/uOdHXbAo4= +github.com/jstemmer/go-junit-report v0.0.0-20190106144839-af01ea7f8024/go.mod h1:6v2b51hI/fHJwM22ozAgKL4VKDeJcHhJFhtBdhmNjmU= +github.com/jtolds/gls v4.20.0+incompatible/go.mod h1:QJZ7F/aHp+rZTRtaJ1ow/lLfFfVYBRgL+9YlvaHOwJU= +github.com/julienschmidt/httprouter v1.2.0/go.mod h1:SYymIcj16QtmaHHD7aYtjjsJG7VTCxuUUipMqKk8s4w= +github.com/jung-kurt/gofpdf v1.0.3-0.20190309125859-24315acbbda5/go.mod h1:7Id9E/uU8ce6rXgefFLlgrJj/GYY22cpxn+r32jIOes= +github.com/karrick/godirwalk v1.7.5/go.mod h1:2c9FRhkDxdIbgkOnCEvnSWs71Bhugbl46shStcFDJ34= +github.com/kisielk/errcheck v1.1.0/go.mod h1:EZBBE59ingxPouuu3KfxchcWSUPOHkagtvWXihfKN4Q= +github.com/kisielk/errcheck v1.2.0/go.mod h1:/BMXB+zMLi60iA8Vv6Ksmxu/1UDYcXs4uQLJ+jE2L00= +github.com/kisielk/gotool v0.0.0-20161130080628-0de1eaf82fa3/go.mod h1:jxZFDH7ILpTPQTk+E2s+z4CUas9lVNjIuKR4c5/zKgM= +github.com/kisielk/gotool v1.0.0/go.mod h1:XhKaO+MFFWcvkIS/tQcRk01m1F5IRFswLeQ+oQHNcck= +github.com/klauspost/compress v1.4.0/go.mod h1:RyIbtBH6LamlWaDj8nUwkbUhJ87Yi3uG0guNDohfE1A= +github.com/klauspost/compress v1.4.1/go.mod h1:RyIbtBH6LamlWaDj8nUwkbUhJ87Yi3uG0guNDohfE1A= +github.com/klauspost/cpuid v0.0.0-20180405133222-e7e905edc00e/go.mod h1:Pj4uuM528wm8OyEC2QMXAi2YiTZ96dNQPGgoMS4s3ek= +github.com/klauspost/cpuid v1.2.0/go.mod h1:Pj4uuM528wm8OyEC2QMXAi2YiTZ96dNQPGgoMS4s3ek= +github.com/konsorten/go-windows-terminal-sequences v1.0.1 h1:mweAR1A6xJ3oS2pRaGiHgQ4OO8tzTaLawm8vnODuwDk= +github.com/konsorten/go-windows-terminal-sequences v1.0.1/go.mod h1:T0+1ngSBFLxvqU3pZ+m/2kptfBszLMUkC4ZK/EgS/cQ= +github.com/kr/logfmt v0.0.0-20140226030751-b84e30acd515/go.mod h1:+0opPa2QZZtGFBFZlji/RkVcI2GknAs/DXo4wKdlNEc= +github.com/kr/pretty v0.1.0 h1:L/CwN0zerZDmRFUapSPitk6f+Q3+0za1rQkzVuMiMFI= +github.com/kr/pretty v0.1.0/go.mod h1:dAy3ld7l9f0ibDNOQOHHMYYIIbhfbHSm3C4ZsoJORNo= +github.com/kr/pty v1.1.1/go.mod h1:pFQYn66WHrOpPYNljwOMqo10TkYh1fy3cYio2l3bCsQ= +github.com/kr/pty v1.1.3/go.mod h1:pFQYn66WHrOpPYNljwOMqo10TkYh1fy3cYio2l3bCsQ= +github.com/kr/pty v1.1.5/go.mod h1:9r2w37qlBe7rQ6e1fg1S/9xpWHSnaqNdHD3WcMdbPDA= +github.com/kr/text v0.1.0 h1:45sCR5RtlFHMR4UwH9sdQ5TC8v0qDQCHnXt+kaKSTVE= +github.com/kr/text v0.1.0/go.mod h1:4Jbv+DJW3UT/LiOwJeYQe1efqtUx/iVham/4vfdArNI= +github.com/kylelemons/godebug v0.0.0-20170820004349-d65d576e9348/go.mod h1:B69LEHPfb2qLo0BaaOLcbitczOKLWTsrBG9LczfCD4k= +github.com/libopenstorage/openstorage v1.0.0/go.mod h1:Sp1sIObHjat1BeXhfMqLZ14wnOzEhNx2YQedreMcUyc= +github.com/liggitt/tabwriter v0.0.0-20181228230101-89fcab3d43de/go.mod h1:zAbeS9B/r2mtpb6U+EI2rYA5OAXxsYw6wTamcNW+zcE= +github.com/lithammer/dedent v1.1.0/go.mod h1:jrXYCQtgg0nJiN+StA2KgR7w6CiQNv9Fd/Z9BP0jIOc= +github.com/logrusorgru/aurora v0.0.0-20181002194514-a7b3b318ed4e/go.mod h1:7rIyQOR62GCctdiQpZ/zOJlFyk6y+94wXzv6RNZgaR4= +github.com/lpabon/godbc v0.1.1/go.mod h1:Jo9QV0cf3U6jZABgiJ2skINAXb9j8m51r07g4KI92ZA= +github.com/lucas-clemente/aes12 v0.0.0-20171027163421-cd47fb39b79f/go.mod h1:JpH9J1c9oX6otFSgdUHwUBUizmKlrMjxWnIAjff4m04= +github.com/lucas-clemente/quic-clients v0.1.0/go.mod h1:y5xVIEoObKqULIKivu+gD/LU90pL73bTdtQjPBvtCBk= +github.com/lucas-clemente/quic-go v0.10.2/go.mod h1:hvaRS9IHjFLMq76puFJeWNfmn+H70QZ/CXoxqw9bzao= +github.com/lucas-clemente/quic-go-certificates v0.0.0-20160823095156-d2f86524cced/go.mod h1:NCcRLrOTZbzhZvixZLlERbJtDtYsmMw8Jc4vS8Z0g58= +github.com/magiconair/properties v1.7.6/go.mod h1:PppfXfuXeibc/6YijjN8zIbojt8czPbwD3XqdrwzmxQ= +github.com/magiconair/properties v1.8.0/go.mod h1:PppfXfuXeibc/6YijjN8zIbojt8czPbwD3XqdrwzmxQ= +github.com/magiconair/properties v1.8.1/go.mod h1:PppfXfuXeibc/6YijjN8zIbojt8czPbwD3XqdrwzmxQ= +github.com/mailru/easyjson v0.0.0-20160728113105-d5b7844b561a/go.mod h1:C1wdFJiN94OJF2b5HbByQZoLdCWB1Yqtg26g4irojpc= +github.com/mailru/easyjson v0.0.0-20180823135443-60711f1a8329/go.mod h1:C1wdFJiN94OJF2b5HbByQZoLdCWB1Yqtg26g4irojpc= +github.com/mailru/easyjson v0.0.0-20190312143242-1de009706dbe/go.mod h1:C1wdFJiN94OJF2b5HbByQZoLdCWB1Yqtg26g4irojpc= +github.com/mailru/easyjson v0.0.0-20190614124828-94de47d64c63/go.mod h1:C1wdFJiN94OJF2b5HbByQZoLdCWB1Yqtg26g4irojpc= +github.com/mailru/easyjson v0.0.0-20190626092158-b2ccc519800e/go.mod h1:C1wdFJiN94OJF2b5HbByQZoLdCWB1Yqtg26g4irojpc= +github.com/mailru/easyjson v0.7.0/go.mod h1:KAzv3t3aY1NaHWoQz1+4F1ccyAH66Jk7yos7ldAVICs= +github.com/marten-seemann/qtls v0.2.3/go.mod h1:xzjG7avBwGGbdZ8dTGxlBnLArsVKLvwmjgmPuiQEcYk= +github.com/mattn/go-colorable v0.0.9/go.mod h1:9vuHe8Xs5qXnSaW/c/ABM9alt+Vo+STaOChaDxuIBZU= +github.com/mattn/go-isatty v0.0.3/go.mod h1:M+lRXTBqGeGNdLjl/ufCoiOlB5xdOkqRJdNxMWT7Zi4= +github.com/mattn/go-isatty v0.0.4/go.mod h1:M+lRXTBqGeGNdLjl/ufCoiOlB5xdOkqRJdNxMWT7Zi4= +github.com/mattn/go-isatty v0.0.9/go.mod h1:YNRxwqDuOph6SZLI9vUUz6OYw3QyUt7WiY2yME+cCiQ= +github.com/mattn/go-runewidth v0.0.2/go.mod h1:LwmH8dsx7+W8Uxz3IHJYH5QSwggIsqBzpuz5H//U1FU= +github.com/mattn/go-shellwords v1.0.5/go.mod h1:3xCvwCdWdlDJUrvuMn7Wuy9eWs4pE8vqg+NOMyg4B2o= +github.com/mattn/goveralls v0.0.2/go.mod h1:8d1ZMHsd7fW6IRPKQh46F2WRpyib5/X4FOpevwGNQEw= +github.com/matttproud/golang_protobuf_extensions v1.0.1 h1:4hp9jkHxhMHkqkrB3Ix0jegS5sx/RkqARlsWZ6pIwiU= +github.com/matttproud/golang_protobuf_extensions v1.0.1/go.mod h1:D8He9yQNgCq6Z5Ld7szi9bcBfOoFv/3dc6xSMkL2PC0= +github.com/mesos/mesos-go v0.0.9/go.mod h1:kPYCMQ9gsOXVAle1OsoY4I1+9kPu8GHkf88aV59fDr4= +github.com/mholt/certmagic v0.6.2-0.20190624175158-6a42ef9fe8c2/go.mod h1:g4cOPxcjV0oFq3qwpjSA30LReKD8AoIfwAY9VvG35NY= +github.com/miekg/dns v1.1.3/go.mod h1:W1PPwlIAgtquWBMBEV9nkV9Cazfe8ScdGz/Lj7v3Nrg= +github.com/miekg/dns v1.1.4/go.mod h1:W1PPwlIAgtquWBMBEV9nkV9Cazfe8ScdGz/Lj7v3Nrg= +github.com/mindprince/gonvml v0.0.0-20190828220739-9ebdce4bb989/go.mod h1:2eu9pRWp8mo84xCg6KswZ+USQHjwgRhNp06sozOdsTY= +github.com/mistifyio/go-zfs v2.1.1+incompatible/go.mod h1:8AuVvqP/mXw1px98n46wfvcGfQ4ci2FwoAjKYxuo3Z4= +github.com/mitchellh/go-homedir v1.0.0/go.mod h1:SfyaCUpYCn1Vlf4IUYiD9fPX4A5wJrkLzIz1N1q0pr0= +github.com/mitchellh/go-homedir v1.1.0/go.mod h1:SfyaCUpYCn1Vlf4IUYiD9fPX4A5wJrkLzIz1N1q0pr0= +github.com/mitchellh/go-ps v0.0.0-20170309133038-4fdf99ab2936/go.mod h1:r1VsdOzOPt1ZSrGZWFoNhsAedKnEd6r9Np1+5blZCWk= +github.com/mitchellh/go-wordwrap v1.0.0/go.mod h1:ZXFpozHsX6DPmq2I0TCekCxypsnAUbP2oI0UX1GXzOo= +github.com/mitchellh/mapstructure v0.0.0-20180220230111-00c29f56e238/go.mod h1:FVVH3fgwuzCH5S8UJGiWEs2h04kUh9fWfEaFds41c1Y= +github.com/mitchellh/mapstructure v1.1.2/go.mod h1:FVVH3fgwuzCH5S8UJGiWEs2h04kUh9fWfEaFds41c1Y= +github.com/modern-go/concurrent v0.0.0-20180228061459-e0a39a4cb421/go.mod h1:6dJC0mAP4ikYIbvyc7fijjWJddQyLn8Ig3JB5CqoB9Q= +github.com/modern-go/concurrent v0.0.0-20180306012644-bacd9c7ef1dd h1:TRLaZ9cD/w8PVh93nsPXa1VrQ6jlwL5oN8l14QlcNfg= +github.com/modern-go/concurrent v0.0.0-20180306012644-bacd9c7ef1dd/go.mod h1:6dJC0mAP4ikYIbvyc7fijjWJddQyLn8Ig3JB5CqoB9Q= +github.com/modern-go/reflect2 v0.0.0-20180701023420-4b7aa43c6742/go.mod h1:bx2lNnkwVCuqBIxFjflWJWanXIb3RllmbCylyMrvgv0= +github.com/modern-go/reflect2 v1.0.1 h1:9f412s+6RmYXLWZSEzVVgPGK7C2PphHj5RJrvfx9AWI= +github.com/modern-go/reflect2 v1.0.1/go.mod h1:bx2lNnkwVCuqBIxFjflWJWanXIb3RllmbCylyMrvgv0= +github.com/mohae/deepcopy v0.0.0-20170603005431-491d3605edfb/go.mod h1:TaXosZuwdSHYgviHp1DAtfrULt5eUgsSMsZf+YrPgl8= +github.com/morikuni/aec v1.0.0/go.mod h1:BbKIizmSmc5MMPqRYbxO4ZU0S0+P200+tUnFx7PXmsc= +github.com/mozilla/tls-observatory v0.0.0-20180409132520-8791a200eb40/go.mod h1:SrKMQvPiws7F7iqYp8/TX+IhxCYhzr6N/1yb8cwHsGk= +github.com/mrunalp/fileutils v0.0.0-20171103030105-7d4729fb3618/go.mod h1:x8F1gnqOkIEiO4rqoeEEEqQbo7HjGMTvyoq3gej4iT0= +github.com/munnerz/goautoneg v0.0.0-20120707110453-a547fc61f48d/go.mod h1:+n7T8mK8HuQTcFwEeznm/DIxMOiR9yIdICNftLE1DvQ= +github.com/munnerz/goautoneg v0.0.0-20191010083416-a7dc8b61c822/go.mod h1:+n7T8mK8HuQTcFwEeznm/DIxMOiR9yIdICNftLE1DvQ= +github.com/mvdan/xurls v1.1.0/go.mod h1:tQlNn3BED8bE/15hnSL2HLkDeLWpNPAwtw7wkEq44oU= +github.com/mwitkow/go-conntrack v0.0.0-20161129095857-cc309e4a2223/go.mod h1:qRWi+5nqEBWmkhHvq77mSJWrCKwh8bxhgT7d/eI7P4U= +github.com/mxk/go-flowrate v0.0.0-20140419014527-cca7078d478f/go.mod h1:ZdcZmHo+o7JKHSa8/e818NopupXU1YMK5fe1lsApnBw= +github.com/naoina/go-stringutil v0.1.0/go.mod h1:XJ2SJL9jCtBh+P9q5btrd/Ylo8XwT/h1USek5+NqSA0= +github.com/naoina/toml v0.1.1/go.mod h1:NBIhNtsFMo3G2szEBne+bO4gS192HuIYRqfvOWb4i1E= +github.com/nbutton23/zxcvbn-go v0.0.0-20160627004424-a22cb81b2ecd/go.mod h1:o96djdrsSGy3AWPyBgZMAGfxZNfgntdJG+11KU4QvbU= +github.com/nbutton23/zxcvbn-go v0.0.0-20171102151520-eafdab6b0663/go.mod h1:o96djdrsSGy3AWPyBgZMAGfxZNfgntdJG+11KU4QvbU= +github.com/olekukonko/tablewriter v0.0.0-20170122224234-a0225b3f23b5/go.mod h1:vsDQFd/mU46D+Z4whnwzcISnGGzXWMclvtLoiIKAKIo= +github.com/onsi/ginkgo v0.0.0-20170829012221-11459a886d9c/go.mod h1:lLunBs/Ym6LB5Z9jYTR76FiuTmxDTDusOGeTQH+WWjE= +github.com/onsi/ginkgo v1.6.0/go.mod h1:lLunBs/Ym6LB5Z9jYTR76FiuTmxDTDusOGeTQH+WWjE= +github.com/onsi/ginkgo v1.8.0/go.mod h1:lLunBs/Ym6LB5Z9jYTR76FiuTmxDTDusOGeTQH+WWjE= +github.com/onsi/ginkgo v1.11.0/go.mod h1:lLunBs/Ym6LB5Z9jYTR76FiuTmxDTDusOGeTQH+WWjE= +github.com/onsi/gomega v0.0.0-20170829124025-dcabb60a477c/go.mod h1:C1qb7wdrVGGVU+Z6iS04AVkA3Q65CEZX59MT0QO5uiA= +github.com/onsi/gomega v1.4.2/go.mod h1:ex+gbHU/CVuBBDIJjb2X0qEXbFg53c61hWP/1CpauHY= +github.com/onsi/gomega v1.4.3/go.mod h1:ex+gbHU/CVuBBDIJjb2X0qEXbFg53c61hWP/1CpauHY= +github.com/onsi/gomega v1.5.0/go.mod h1:ex+gbHU/CVuBBDIJjb2X0qEXbFg53c61hWP/1CpauHY= +github.com/onsi/gomega v1.7.0/go.mod h1:ex+gbHU/CVuBBDIJjb2X0qEXbFg53c61hWP/1CpauHY= +github.com/opencontainers/go-digest v1.0.0-rc1 h1:WzifXhOVOEOuFYOJAW6aQqW0TooG2iki3E3Ii+WN7gQ= +github.com/opencontainers/go-digest v1.0.0-rc1/go.mod h1:cMLVZDEM3+U2I4VmLI6N8jQYUd2OVphdqWwCJHrFt2s= +github.com/opencontainers/image-spec v1.0.1/go.mod h1:BtxoFyWECRxE4U/7sNtV5W15zMzWCbyJoFRP3s7yZA0= +github.com/opencontainers/runc v1.0.0-rc10/go.mod h1:qT5XzbpPznkRYVz/mWwUaVBUv2rmF59PVA73FjuZG0U= +github.com/opencontainers/runtime-spec v1.0.0/go.mod h1:jwyrGlmzljRJv/Fgzds9SsS/C5hL+LL3ko9hs6T5lQ0= +github.com/opencontainers/selinux v1.3.1-0.20190929122143-5215b1806f52/go.mod h1:+BLncwf63G4dgOzykXAxcmnFlUaOlkDdmw/CqsW6pjs= +github.com/pborman/uuid v1.2.0/go.mod h1:X/NO0urCmaxf9VXbdlT7C2Yzkj2IKimNn4k+gtPdI/k= +github.com/pelletier/go-toml v1.1.0/go.mod h1:5z9KED0ma1S8pY6P1sdut58dfprrGBbd/94hg7ilaic= +github.com/pelletier/go-toml v1.2.0/go.mod h1:5z9KED0ma1S8pY6P1sdut58dfprrGBbd/94hg7ilaic= +github.com/peterbourgon/diskv v2.0.1+incompatible/go.mod h1:uqqh8zWWbv1HBMNONnaR/tNboyR3/BZd58JJSHlUSCU= +github.com/pkg/errors v0.8.0/go.mod h1:bwawxfHBFNV+L2hUp1rHADufV3IMtnDRdf1r5NINEl0= +github.com/pkg/errors v0.8.1 h1:iURUrRGxPUNPdy5/HRSm+Yj6okJ6UtLINN0Q9M4+h3I= +github.com/pkg/errors v0.8.1/go.mod h1:bwawxfHBFNV+L2hUp1rHADufV3IMtnDRdf1r5NINEl0= +github.com/pmezard/go-difflib v1.0.0 h1:4DBwDE0NGyQoBHbLQYPwSUPoCMWR5BEzIk/f1lZbAQM= +github.com/pmezard/go-difflib v1.0.0/go.mod h1:iKH77koFhYxTK1pcRnkKkqfTogsbg7gZNVY4sRDYZ/4= +github.com/pquerna/cachecontrol v0.0.0-20171018203845-0dec1b30a021/go.mod h1:prYjPmNq4d1NPVmpShWobRqXY3q7Vp+80DqgxxUrUIA= +github.com/pquerna/ffjson v0.0.0-20180717144149-af8b230fcd20/go.mod h1:YARuvh7BUWHNhzDq2OM5tzR2RiCcN2D7sapiKyCel/M= +github.com/prometheus/client_golang v0.9.1/go.mod h1:7SWBe2y4D6OKWSNQJUaRYU/AaXPKyh/dDVn+NZz0KFw= +github.com/prometheus/client_golang v1.0.0 h1:vrDKnkGzuGvhNAL56c7DBz29ZL+KxnoR0x7enabFceM= +github.com/prometheus/client_golang v1.0.0/go.mod h1:db9x61etRT2tGnBNRi70OPL5FsnadC4Ky3P0J6CfImo= +github.com/prometheus/client_model v0.0.0-20180712105110-5c3871d89910/go.mod h1:MbSGuTsp3dbXC40dX6PRTWyKYBIrTGTE9sqQNg2J8bo= +github.com/prometheus/client_model v0.0.0-20190129233127-fd36f4220a90/go.mod h1:xMI15A0UPsDsEKsMN9yxemIoYk6Tm2C1GtYGdfGttqA= +github.com/prometheus/client_model v0.0.0-20190812154241-14fe0d1b01d4/go.mod h1:xMI15A0UPsDsEKsMN9yxemIoYk6Tm2C1GtYGdfGttqA= +github.com/prometheus/client_model v0.2.0 h1:uq5h0d+GuxiXLJLNABMgp2qUWDPiLvgCzz2dUR+/W/M= +github.com/prometheus/client_model v0.2.0/go.mod h1:xMI15A0UPsDsEKsMN9yxemIoYk6Tm2C1GtYGdfGttqA= +github.com/prometheus/common v0.4.1 h1:K0MGApIoQvMw27RTdJkPbr3JZ7DNbtxQNyi5STVM6Kw= +github.com/prometheus/common v0.4.1/go.mod h1:TNfzLD0ON7rHzMJeJkieUDPYmFC7Snx/y86RQel1bk4= +github.com/prometheus/procfs v0.0.0-20181005140218-185b4288413d/go.mod h1:c3At6R/oaqEKCNdg8wHV1ftS6bRYblBhIjjI8uT2IGk= +github.com/prometheus/procfs v0.0.2 h1:6LJUbpNm42llc4HRCuvApCSWB/WfhuNo9K98Q9sNGfs= +github.com/prometheus/procfs v0.0.2/go.mod h1:TjEm7ze935MbeOT/UhFTIMYKhuLP4wbCsTZCD3I8kEA= +github.com/quasilyte/go-consistent v0.0.0-20190521200055-c6f3937de18c/go.mod h1:5STLWrekHfjyYwxBRVRXNOSewLJ3PWfDJd1VyTS21fI= +github.com/quobyte/api v0.1.2/go.mod h1:jL7lIHrmqQ7yh05OJ+eEEdHr0u/kmT1Ff9iHd+4H6VI= +github.com/remyoudompheng/bigfft v0.0.0-20170806203942-52369c62f446/go.mod h1:uYEyJGbgTkfkS4+E/PavXkNJcbFIpEtjt2B0KDQ5+9M= +github.com/robfig/cron v1.1.0 h1:jk4/Hud3TTdcrJgUOBgsqrZBarcxl6ADIjSC2iniwLY= +github.com/robfig/cron v1.1.0/go.mod h1:JGuDeoQd7Z6yL4zQhZ3OPEVHB7fL6Ka6skscFHfmt2k= +github.com/rogpeppe/fastuuid v0.0.0-20150106093220-6724a57986af/go.mod h1:XWv6SoW27p1b0cqNHllgS5HIMJraePCO15w5zCzIWYg= +github.com/rogpeppe/go-internal v1.1.0/go.mod h1:M8bDsm7K2OlrFYOpmOWEs/qY81heoFRclV5y23lUDJ4= +github.com/rogpeppe/go-internal v1.3.0/go.mod h1:M8bDsm7K2OlrFYOpmOWEs/qY81heoFRclV5y23lUDJ4= +github.com/rubiojr/go-vhd v0.0.0-20160810183302-0bfd3b39853c/go.mod h1:DM5xW0nvfNNm2uytzsvhI3OnX8uzaRAg8UX/CnDqbto= +github.com/russross/blackfriday v0.0.0-20170610170232-067529f716f4/go.mod h1:JO/DiYxRf+HjHt06OyowR9PTA263kcR/rfWxYHBV53g= +github.com/russross/blackfriday v1.5.2/go.mod h1:JO/DiYxRf+HjHt06OyowR9PTA263kcR/rfWxYHBV53g= +github.com/ryanuber/go-glob v0.0.0-20170128012129-256dc444b735/go.mod h1:807d1WSdnB0XRJzKNil9Om6lcp/3a0v4qIHxIXzX/Yc= +github.com/satori/go.uuid v1.2.0/go.mod h1:dA0hQrYB0VpLJoorglMZABFdXlWrHn1NEOzdhQKdks0= +github.com/seccomp/libseccomp-golang v0.9.1/go.mod h1:GbW5+tmTXfcxTToHLXlScSlAvWlF4P2Ca7zGrPiEpWo= +github.com/sergi/go-diff v1.0.0/go.mod h1:0CfEIISq7TuYL3j771MWULgwwjU+GofnZX9QAmXWZgo= +github.com/shirou/gopsutil v0.0.0-20180427012116-c95755e4bcd7/go.mod h1:5b4v6he4MtMOwMlS0TUMTu2PcXUg8+E1lC7eC3UO/RA= +github.com/shirou/w32 v0.0.0-20160930032740-bb4de0191aa4/go.mod h1:qsXQc7+bwAM3Q1u/4XEfrquwF8Lw7D7y5cD8CuHnfIc= +github.com/shurcooL/go v0.0.0-20180423040247-9e1955d9fb6e/go.mod h1:TDJrrUr11Vxrven61rcy3hJMUqaf/CLWYhHNPmT14Lk= +github.com/shurcooL/go-goon v0.0.0-20170922171312-37c2f522c041/go.mod h1:N5mDOmsrJOB+vfqUK+7DmDyjhSLIIBnXo9lvZJj3MWQ= +github.com/sirupsen/logrus v1.0.5/go.mod h1:pMByvHTf9Beacp5x1UXfOR9xyW/9antXMhjMPG0dEzc= +github.com/sirupsen/logrus v1.0.6/go.mod h1:pMByvHTf9Beacp5x1UXfOR9xyW/9antXMhjMPG0dEzc= +github.com/sirupsen/logrus v1.2.0/go.mod h1:LxeOpSwHxABJmUn/MG1IvRgCAasNZTLOkJPxbbu5VWo= +github.com/sirupsen/logrus v1.4.1/go.mod h1:ni0Sbl8bgC9z8RoU9G6nDWqqs/fq4eDPysMBDgk/93Q= +github.com/sirupsen/logrus v1.4.2 h1:SPIRibHv4MatM3XXNO2BJeFLZwZ2LvZgfQ5+UNI2im4= +github.com/sirupsen/logrus v1.4.2/go.mod h1:tLMulIdttU9McNUspp0xgXVQah82FyeX6MwdIuYE2rE= +github.com/smartystreets/assertions v0.0.0-20180927180507-b2de0cb4f26d/go.mod h1:OnSkiWE9lh6wB0YB77sQom3nweQdgAjqCqsofrRNTgc= +github.com/smartystreets/goconvey v1.6.4/go.mod h1:syvi0/a8iFYH4r/RixwvyeAJjdLS9QV7WQ/tjFTllLA= +github.com/soheilhy/cmux v0.1.4 h1:0HKaf1o97UwFjHH9o5XsHUOF+tqmdA7KEzXLpiyaw0E= +github.com/soheilhy/cmux v0.1.4/go.mod h1:IM3LyeVVIOuxMH7sFAkER9+bJ4dT7Ms6E4xg4kGIyLM= +github.com/sourcegraph/go-diff v0.5.1/go.mod h1:j2dHj3m8aZgQO8lMTcTnBcXkRRRqi34cd2MNlA9u1mE= +github.com/spf13/afero v1.1.0/go.mod h1:j4pytiNVoe2o6bmDsKpLACNPDBIoEAkihy7loJ1B0CQ= +github.com/spf13/afero v1.1.2/go.mod h1:j4pytiNVoe2o6bmDsKpLACNPDBIoEAkihy7loJ1B0CQ= +github.com/spf13/afero v1.2.2 h1:5jhuqJyZCZf2JRofRvN/nIFgIWNzPa3/Vz8mYylgbWc= +github.com/spf13/afero v1.2.2/go.mod h1:9ZxEEn6pIJ8Rxe320qSDBk6AsU0r9pR7Q4OcevTdifk= +github.com/spf13/cast v1.2.0/go.mod h1:r2rcYCSwa1IExKTDiTfzaxqT2FNHs8hODu4LnUfgKEg= +github.com/spf13/cast v1.3.0/go.mod h1:Qx5cxh0v+4UWYiBimWS+eyWzqEqokIECu5etghLkUJE= +github.com/spf13/cobra v0.0.2/go.mod h1:1l0Ry5zgKvJasoi3XT1TypsSe7PqH0Sj9dhYf7v3XqQ= +github.com/spf13/cobra v0.0.3/go.mod h1:1l0Ry5zgKvJasoi3XT1TypsSe7PqH0Sj9dhYf7v3XqQ= +github.com/spf13/cobra v0.0.5/go.mod h1:3K3wKZymM7VvHMDS9+Akkh4K60UwM26emMESw8tLCHU= +github.com/spf13/jwalterweatherman v0.0.0-20180109140146-7c0cea34c8ec/go.mod h1:cQK4TGJAtQXfYWX+Ddv3mKDzgVb68N+wFjFa4jdeBTo= +github.com/spf13/jwalterweatherman v1.0.0/go.mod h1:cQK4TGJAtQXfYWX+Ddv3mKDzgVb68N+wFjFa4jdeBTo= +github.com/spf13/jwalterweatherman v1.1.0/go.mod h1:aNWZUN0dPAAO/Ljvb5BEdw96iTZ0EXowPYD95IqWIGo= +github.com/spf13/pflag v0.0.0-20170130214245-9ff6c6923cff/go.mod h1:DYY7MBk1bdzusC3SYhjObp+wFpr4gzcvqqNjLnInEg4= +github.com/spf13/pflag v1.0.1/go.mod h1:DYY7MBk1bdzusC3SYhjObp+wFpr4gzcvqqNjLnInEg4= +github.com/spf13/pflag v1.0.3/go.mod h1:DYY7MBk1bdzusC3SYhjObp+wFpr4gzcvqqNjLnInEg4= +github.com/spf13/pflag v1.0.5 h1:iy+VFUOCP1a+8yFto/drg2CJ5u0yRoB7fZw3DKv/JXA= +github.com/spf13/pflag v1.0.5/go.mod h1:McXfInJRrz4CZXVZOBLb0bTZqETkiAhM9Iw0y3An2Bg= +github.com/spf13/viper v1.0.2/go.mod h1:A8kyI5cUJhb8N+3pkfONlcEcZbueH6nhAm0Fq7SrnBM= +github.com/spf13/viper v1.3.2/go.mod h1:ZiWeW+zYFKm7srdB9IoDzzZXaJaI5eL9QjNiN/DMA2s= +github.com/storageos/go-api v0.0.0-20180912212459-343b3eff91fc/go.mod h1:ZrLn+e0ZuF3Y65PNF6dIwbJPZqfmtCXxFm9ckv0agOY= +github.com/stretchr/objx v0.1.0/go.mod h1:HFkY916IF+rwdDfMAkV7OtwuqBVzrE8GR6GFx+wExME= +github.com/stretchr/objx v0.1.1/go.mod h1:HFkY916IF+rwdDfMAkV7OtwuqBVzrE8GR6GFx+wExME= +github.com/stretchr/objx v0.2.0/go.mod h1:qt09Ya8vawLte6SNmTgCsAVtYtaKzEcn8ATUoHMkEqE= +github.com/stretchr/testify v1.2.2/go.mod h1:a8OnRcib4nhh0OaRAV+Yts87kKdq0PP7pXfy6kDkUVs= +github.com/stretchr/testify v1.3.0/go.mod h1:M5WIy9Dh21IEIfnGCwXGc5bZfKNJtfHm1UVUgZn+9EI= +github.com/stretchr/testify v1.4.0 h1:2E4SXV/wtOkTonXsotYi4li6zVWxYlZuYNCXe9XRJyk= +github.com/stretchr/testify v1.4.0/go.mod h1:j7eGeouHqKxXV5pUuKE4zz7dFj8WfuZ+81PSLYec5m4= +github.com/syndtr/gocapability v0.0.0-20180916011248-d98352740cb2/go.mod h1:hkRG7XYTFWNJGYcbNJQlaLq0fg1yr4J4t/NcTQtrfww= +github.com/tarm/serial v0.0.0-20180830185346-98f6abe2eb07/go.mod h1:kDXzergiv9cbyO7IOYJZWg1U88JhDg3PB6klq9Hg2pA= +github.com/thecodeteam/goscaleio v0.1.0/go.mod h1:68sdkZAsK8bvEwBlbQnlLS+xU+hvLYM/iQ8KXej1AwM= +github.com/tidwall/pretty v1.0.0/go.mod h1:XNkn88O1ChpSDQmQeStsy+sBenx6DDtFZJxhVysOjyk= +github.com/timakin/bodyclose v0.0.0-20190721030226-87058b9bfcec/go.mod h1:Qimiffbc6q9tBWlVV6x0P9sat/ao1xEkREYPPj9hphk= +github.com/tmc/grpc-websocket-proxy v0.0.0-20170815181823-89b8d40f7ca8 h1:ndzgwNDnKIqyCvHTXaCqh9KlOWKvBry6nuXMJmonVsE= +github.com/tmc/grpc-websocket-proxy v0.0.0-20170815181823-89b8d40f7ca8/go.mod h1:ncp9v5uamzpCO7NfCPTXjqaC+bZgJeR0sMTm6dMHP7U= +github.com/ugorji/go/codec v0.0.0-20181204163529-d75b2dcb6bc8/go.mod h1:VFNgLljTbGfSG7qAOspJ7OScBnGdDN/yBr0sguwnwf0= +github.com/ultraware/funlen v0.0.1/go.mod h1:Dp4UiAus7Wdb9KUZsYWZEWiRzGuM2kXM1lPbfaF6xhA= +github.com/ultraware/funlen v0.0.2/go.mod h1:Dp4UiAus7Wdb9KUZsYWZEWiRzGuM2kXM1lPbfaF6xhA= +github.com/urfave/cli v1.20.0/go.mod h1:70zkFmudgCuE/ngEzBv17Jvp/497gISqfk5gWijbERA= +github.com/urfave/negroni v1.0.0/go.mod h1:Meg73S6kFm/4PpbYdq35yYWoCZ9mS/YSx+lKnmiohz4= +github.com/valyala/bytebufferpool v1.0.0/go.mod h1:6bBcMArwyJ5K/AmCkWv1jt77kVWyCJ6HpOuEn7z0Csc= +github.com/valyala/fasthttp v1.2.0/go.mod h1:4vX61m6KN+xDduDNwXrhIAVZaZaZiQ1luJk8LWSxF3s= +github.com/valyala/quicktemplate v1.1.1/go.mod h1:EH+4AkTd43SvgIbQHYu59/cJyxDoOVRUAfrukLPuGJ4= +github.com/valyala/tcplisten v0.0.0-20161114210144-ceec8f93295a/go.mod h1:v3UYOV9WzVtRmSR+PDvWpU/qWl4Wa5LApYYX4ZtKbio= +github.com/vektah/gqlparser v1.1.2/go.mod h1:1ycwN7Ij5njmMkPPAOaRFY4rET2Enx7IkVv3vaXspKw= +github.com/vishvananda/netlink v1.0.0/go.mod h1:+SR5DhBJrl6ZM7CoCKvpw5BKroDKQ+PJqOg65H/2ktk= +github.com/vishvananda/netns v0.0.0-20171111001504-be1fbeda1936/go.mod h1:ZjcWmFBXmLKZu9Nxj3WKYEafiSqer2rnvPr0en9UNpI= +github.com/vmware/govmomi v0.20.3/go.mod h1:URlwyTFZX72RmxtxuaFL2Uj3fD1JTvZdx59bHWk6aFU= +github.com/xiang90/probing v0.0.0-20190116061207-43a291ad63a2 h1:eY9dn8+vbi4tKz5Qo6v2eYzo7kUS51QINcR5jNpbZS8= +github.com/xiang90/probing v0.0.0-20190116061207-43a291ad63a2/go.mod h1:UETIi67q53MR2AWcXfiuqkDkRtnGDLqkBTpCHuJHxtU= +github.com/xlab/handysort v0.0.0-20150421192137-fb3537ed64a1/go.mod h1:QcJo0QPSfTONNIgpN5RA8prR7fF8nkF6cTWTcNerRO8= +github.com/xordataexchange/crypt v0.0.3-0.20170626215501-b2862e3d0a77/go.mod h1:aYKd//L2LvnjZzWKhF00oedf4jCCReLcmhLdhm1A27Q= +go.etcd.io/bbolt v1.3.3 h1:MUGmc65QhB3pIlaQ5bB4LwqSj6GIonVJXpZiaKNyaKk= +go.etcd.io/bbolt v1.3.3/go.mod h1:IbVyRI1SCnLcuJnV2u8VeU0CEYM7e686BmAb1XKL+uU= +go.etcd.io/etcd v0.0.0-20191023171146-3cf2f69b5738 h1:VcrIfasaLFkyjk6KNlXQSzO+B0fZcnECiDrKJsfxka0= +go.etcd.io/etcd v0.0.0-20191023171146-3cf2f69b5738/go.mod h1:dnLIgRNXwCJa5e+c6mIZCrds/GIG4ncV9HhK5PX7jPg= +go.mongodb.org/mongo-driver v1.0.3/go.mod h1:u7ryQJ+DOzQmeO7zB6MHyr8jkEQvC8vH7qLUO4lqsUM= +go.mongodb.org/mongo-driver v1.1.1/go.mod h1:u7ryQJ+DOzQmeO7zB6MHyr8jkEQvC8vH7qLUO4lqsUM= +go.mongodb.org/mongo-driver v1.1.2/go.mod h1:u7ryQJ+DOzQmeO7zB6MHyr8jkEQvC8vH7qLUO4lqsUM= +go.opencensus.io v0.21.0/go.mod h1:mSImk1erAIZhrmZN+AvHh14ztQfjbGwt4TtuofqLduU= +go.uber.org/atomic v1.3.2 h1:2Oa65PReHzfn29GpvgsYwloV9AVFHPDk8tYxt2c2tr4= +go.uber.org/atomic v1.3.2/go.mod h1:gD2HeocX3+yG+ygLZcrzQJaqmWj9AIm7n08wl/qW/PE= +go.uber.org/multierr v1.1.0 h1:HoEmRHQPVSqub6w2z2d2EOVs2fjyFRGyofhKuyDq0QI= +go.uber.org/multierr v1.1.0/go.mod h1:wR5kodmAFQ0UK8QlbwjlSNy0Z68gJhDJUG5sjR94q/0= +go.uber.org/zap v1.10.0 h1:ORx85nbTijNz8ljznvCMR1ZBIPKFn3jQrag10X2AsuM= +go.uber.org/zap v1.10.0/go.mod h1:vwi/ZaCAaUcBkycHslxD9B2zi4UTXhF60s6SWpuDF0Q= +go4.org v0.0.0-20180809161055-417644f6feb5/go.mod h1:MkTOUMDaeVYJUOUsaDXIhWPZYa1yOyC1qaOBpL57BhE= +golang.org/x/build v0.0.0-20190927031335-2835ba2e683f/go.mod h1:fYw7AShPAhGMdXqA9gRadk/CcMsvLlClpE5oBwnS3dM= +golang.org/x/crypto v0.0.0-20180426230345-b49d69b5da94/go.mod h1:6SG95UA2DQfeDnfUPMdvaQW0Q7yPrPDi9nlGo2tz2b4= +golang.org/x/crypto v0.0.0-20180904163835-0709b304e793/go.mod h1:6SG95UA2DQfeDnfUPMdvaQW0Q7yPrPDi9nlGo2tz2b4= +golang.org/x/crypto v0.0.0-20181203042331-505ab145d0a9/go.mod h1:6SG95UA2DQfeDnfUPMdvaQW0Q7yPrPDi9nlGo2tz2b4= +golang.org/x/crypto v0.0.0-20190123085648-057139ce5d2b/go.mod h1:6SG95UA2DQfeDnfUPMdvaQW0Q7yPrPDi9nlGo2tz2b4= +golang.org/x/crypto v0.0.0-20190211182817-74369b46fc67/go.mod h1:6SG95UA2DQfeDnfUPMdvaQW0Q7yPrPDi9nlGo2tz2b4= +golang.org/x/crypto v0.0.0-20190228161510-8dd112bcdc25/go.mod h1:djNgcEr1/C05ACkg1iLfiJU5Ep61QUkGW8qpdssI0+w= +golang.org/x/crypto v0.0.0-20190308221718-c2843e01d9a2/go.mod h1:djNgcEr1/C05ACkg1iLfiJU5Ep61QUkGW8qpdssI0+w= +golang.org/x/crypto v0.0.0-20190313024323-a1f597ede03a/go.mod h1:djNgcEr1/C05ACkg1iLfiJU5Ep61QUkGW8qpdssI0+w= +golang.org/x/crypto v0.0.0-20190320223903-b7391e95e576/go.mod h1:djNgcEr1/C05ACkg1iLfiJU5Ep61QUkGW8qpdssI0+w= +golang.org/x/crypto v0.0.0-20190424203555-c05e17bb3b2d/go.mod h1:yigFU9vqHzYiE8UmvKecakEJjdnWj3jj499lnFckfCI= +golang.org/x/crypto v0.0.0-20190510104115-cbcb75029529/go.mod h1:yigFU9vqHzYiE8UmvKecakEJjdnWj3jj499lnFckfCI= +golang.org/x/crypto v0.0.0-20190611184440-5c40567a22f8/go.mod h1:yigFU9vqHzYiE8UmvKecakEJjdnWj3jj499lnFckfCI= +golang.org/x/crypto v0.0.0-20190617133340-57b3e21c3d56/go.mod h1:yigFU9vqHzYiE8UmvKecakEJjdnWj3jj499lnFckfCI= +golang.org/x/crypto v0.0.0-20200220183623-bac4c82f6975 h1:/Tl7pH94bvbAAHBdZJT947M/+gp0+CqQXDtMRC0fseo= +golang.org/x/crypto v0.0.0-20200220183623-bac4c82f6975/go.mod h1:LzIPMQfyMNhhGPhUkYOs5KpL4U8rLKemX1yGLhDgUto= +golang.org/x/exp v0.0.0-20180321215751-8460e604b9de/go.mod h1:CJ0aWSM057203Lf6IL+f9T1iT9GByDxfZKAQTCR3kQA= +golang.org/x/exp v0.0.0-20180807140117-3d87b88a115f/go.mod h1:CJ0aWSM057203Lf6IL+f9T1iT9GByDxfZKAQTCR3kQA= +golang.org/x/exp v0.0.0-20190121172915-509febef88a4/go.mod h1:CJ0aWSM057203Lf6IL+f9T1iT9GByDxfZKAQTCR3kQA= +golang.org/x/exp v0.0.0-20190125153040-c74c464bbbf2/go.mod h1:CJ0aWSM057203Lf6IL+f9T1iT9GByDxfZKAQTCR3kQA= +golang.org/x/exp v0.0.0-20190312203227-4b39c73a6495/go.mod h1:ZjyILWgesfNpC6sMxTJOJm9Kp84zZh5NQWvqDGG3Qr8= +golang.org/x/image v0.0.0-20180708004352-c73c2afc3b81/go.mod h1:ux5Hcp/YLpHSI86hEcLt0YII63i6oz57MZXIpbrjZUs= +golang.org/x/image v0.0.0-20190227222117-0694c2d4d067/go.mod h1:kZ7UVZpmo3dzQBMxlp+ypCbDeSB+sBbTgSJuh5dn5js= +golang.org/x/lint v0.0.0-20181026193005-c67002cb31c3/go.mod h1:UVdnD1Gm6xHRNCYTkRU2/jEulfH38KcIWyp/GAMgvoE= +golang.org/x/lint v0.0.0-20190227174305-5b3e6a55c961/go.mod h1:wehouNa3lNwaWXcvxsM5YxQ5yQlVC4a0KAMCusXpPoU= +golang.org/x/lint v0.0.0-20190301231843-5614ed5bae6f/go.mod h1:UVdnD1Gm6xHRNCYTkRU2/jEulfH38KcIWyp/GAMgvoE= +golang.org/x/lint v0.0.0-20190313153728-d0100b6bd8b3/go.mod h1:6SW0HCj/g11FgYtHlgUYUwCkIfeOF89ocIRzGO/8vkc= +golang.org/x/lint v0.0.0-20190409202823-959b441ac422/go.mod h1:6SW0HCj/g11FgYtHlgUYUwCkIfeOF89ocIRzGO/8vkc= +golang.org/x/mobile v0.0.0-20190312151609-d3739f865fa6/go.mod h1:z+o9i4GpDbdi3rU15maQ/Ox0txvL9dWGYEHz965HBQE= +golang.org/x/mod v0.0.0-20190513183733-4bf6d317e70e/go.mod h1:mXi4GBBbnImb6dmsKGUJ2LatrhH/nqhxcFungHvyanc= +golang.org/x/net v0.0.0-20170114055629-f2499483f923/go.mod h1:mL1N/T3taQHkDXs73rZJwtUhF3w3ftmwwsq0BUmARs4= +golang.org/x/net v0.0.0-20170915142106-8351a756f30f/go.mod h1:mL1N/T3taQHkDXs73rZJwtUhF3w3ftmwwsq0BUmARs4= +golang.org/x/net v0.0.0-20180724234803-3673e40ba225/go.mod h1:mL1N/T3taQHkDXs73rZJwtUhF3w3ftmwwsq0BUmARs4= +golang.org/x/net v0.0.0-20180826012351-8a410e7b638d/go.mod h1:mL1N/T3taQHkDXs73rZJwtUhF3w3ftmwwsq0BUmARs4= +golang.org/x/net v0.0.0-20180906233101-161cd47e91fd/go.mod h1:mL1N/T3taQHkDXs73rZJwtUhF3w3ftmwwsq0BUmARs4= +golang.org/x/net v0.0.0-20180911220305-26e67e76b6c3/go.mod h1:mL1N/T3taQHkDXs73rZJwtUhF3w3ftmwwsq0BUmARs4= +golang.org/x/net v0.0.0-20181005035420-146acd28ed58/go.mod h1:mL1N/T3taQHkDXs73rZJwtUhF3w3ftmwwsq0BUmARs4= +golang.org/x/net v0.0.0-20181102091132-c10e9556a7bc/go.mod h1:mL1N/T3taQHkDXs73rZJwtUhF3w3ftmwwsq0BUmARs4= +golang.org/x/net v0.0.0-20181114220301-adae6a3d119a/go.mod h1:mL1N/T3taQHkDXs73rZJwtUhF3w3ftmwwsq0BUmARs4= +golang.org/x/net v0.0.0-20181220203305-927f97764cc3/go.mod h1:mL1N/T3taQHkDXs73rZJwtUhF3w3ftmwwsq0BUmARs4= +golang.org/x/net v0.0.0-20190108225652-1e06a53dbb7e/go.mod h1:mL1N/T3taQHkDXs73rZJwtUhF3w3ftmwwsq0BUmARs4= +golang.org/x/net v0.0.0-20190125091013-d26f9f9a57f3/go.mod h1:mL1N/T3taQHkDXs73rZJwtUhF3w3ftmwwsq0BUmARs4= +golang.org/x/net v0.0.0-20190213061140-3a22650c66bd/go.mod h1:mL1N/T3taQHkDXs73rZJwtUhF3w3ftmwwsq0BUmARs4= +golang.org/x/net v0.0.0-20190311183353-d8887717615a/go.mod h1:t9HGtf8HONx5eT2rtn7q6eTqICYqUVnKs3thJo3Qplg= +golang.org/x/net v0.0.0-20190320064053-1272bf9dcd53/go.mod h1:t9HGtf8HONx5eT2rtn7q6eTqICYqUVnKs3thJo3Qplg= +golang.org/x/net v0.0.0-20190328230028-74de082e2cca/go.mod h1:t9HGtf8HONx5eT2rtn7q6eTqICYqUVnKs3thJo3Qplg= +golang.org/x/net v0.0.0-20190404232315-eb5bcb51f2a3/go.mod h1:t9HGtf8HONx5eT2rtn7q6eTqICYqUVnKs3thJo3Qplg= +golang.org/x/net v0.0.0-20190502183928-7f726cade0ab/go.mod h1:t9HGtf8HONx5eT2rtn7q6eTqICYqUVnKs3thJo3Qplg= +golang.org/x/net v0.0.0-20190503192946-f4e77d36d62c/go.mod h1:t9HGtf8HONx5eT2rtn7q6eTqICYqUVnKs3thJo3Qplg= +golang.org/x/net v0.0.0-20190613194153-d28f0bde5980/go.mod h1:z5CRVTTTmAJ677TzLLGU+0bjPO0LkuOLi4/5GtJWs/s= +golang.org/x/net v0.0.0-20190620200207-3b0461eec859/go.mod h1:z5CRVTTTmAJ677TzLLGU+0bjPO0LkuOLi4/5GtJWs/s= +golang.org/x/net v0.0.0-20190813141303-74dc4d7220e7/go.mod h1:z5CRVTTTmAJ677TzLLGU+0bjPO0LkuOLi4/5GtJWs/s= +golang.org/x/net v0.0.0-20190827160401-ba9fcec4b297/go.mod h1:z5CRVTTTmAJ677TzLLGU+0bjPO0LkuOLi4/5GtJWs/s= +golang.org/x/net v0.0.0-20191004110552-13f9640d40b9 h1:rjwSpXsdiK0dV8/Naq3kAw9ymfAeJIyd0upUIElB+lI= +golang.org/x/net v0.0.0-20191004110552-13f9640d40b9/go.mod h1:z5CRVTTTmAJ677TzLLGU+0bjPO0LkuOLi4/5GtJWs/s= +golang.org/x/oauth2 v0.0.0-20180821212333-d2e6202438be/go.mod h1:N/0e6XlmueqKjAGxoOufVs8QHGRruUQn6yWY3a++T0U= +golang.org/x/oauth2 v0.0.0-20190226205417-e64efc72b421/go.mod h1:gOpvHmFTYa4IltrdGE7lF6nIHvwfUNPOp7c8zoXwtLw= +golang.org/x/oauth2 v0.0.0-20190402181905-9f3314589c9a/go.mod h1:gOpvHmFTYa4IltrdGE7lF6nIHvwfUNPOp7c8zoXwtLw= +golang.org/x/oauth2 v0.0.0-20190604053449-0f29369cfe45 h1:SVwTIAaPC2U/AvvLNZ2a7OVsmBpC8L5BlwK1whH3hm0= +golang.org/x/oauth2 v0.0.0-20190604053449-0f29369cfe45/go.mod h1:gOpvHmFTYa4IltrdGE7lF6nIHvwfUNPOp7c8zoXwtLw= +golang.org/x/perf v0.0.0-20180704124530-6e6d33e29852/go.mod h1:JLpeXjPJfIyPr5TlbXLkXWLhP8nz10XfvxElABhCtcw= +golang.org/x/sync v0.0.0-20180314180146-1d60e4601c6f/go.mod h1:RxMgew5VJxzue5/jJTE5uejpjVlOe/izrB70Jof72aM= +golang.org/x/sync v0.0.0-20181108010431-42b317875d0f/go.mod h1:RxMgew5VJxzue5/jJTE5uejpjVlOe/izrB70Jof72aM= +golang.org/x/sync v0.0.0-20181221193216-37e7f081c4d4/go.mod h1:RxMgew5VJxzue5/jJTE5uejpjVlOe/izrB70Jof72aM= +golang.org/x/sync v0.0.0-20190227155943-e225da77a7e6/go.mod h1:RxMgew5VJxzue5/jJTE5uejpjVlOe/izrB70Jof72aM= +golang.org/x/sync v0.0.0-20190423024810-112230192c58/go.mod h1:RxMgew5VJxzue5/jJTE5uejpjVlOe/izrB70Jof72aM= +golang.org/x/sync v0.0.0-20190911185100-cd5d95a43a6e/go.mod h1:RxMgew5VJxzue5/jJTE5uejpjVlOe/izrB70Jof72aM= +golang.org/x/sys v0.0.0-20170830134202-bb24a47a89ea/go.mod h1:STP8DvDyc/dI5b8T5hshtkjS+E42TnysNCUPdjciGhY= +golang.org/x/sys v0.0.0-20171026204733-164713f0dfce/go.mod h1:STP8DvDyc/dI5b8T5hshtkjS+E42TnysNCUPdjciGhY= +golang.org/x/sys v0.0.0-20180830151530-49385e6e1522/go.mod h1:STP8DvDyc/dI5b8T5hshtkjS+E42TnysNCUPdjciGhY= +golang.org/x/sys v0.0.0-20180905080454-ebe1bf3edb33/go.mod h1:STP8DvDyc/dI5b8T5hshtkjS+E42TnysNCUPdjciGhY= +golang.org/x/sys v0.0.0-20180909124046-d0be0721c37e/go.mod h1:STP8DvDyc/dI5b8T5hshtkjS+E42TnysNCUPdjciGhY= +golang.org/x/sys v0.0.0-20181107165924-66b7b1311ac8/go.mod h1:STP8DvDyc/dI5b8T5hshtkjS+E42TnysNCUPdjciGhY= +golang.org/x/sys v0.0.0-20181116152217-5ac8a444bdc5/go.mod h1:STP8DvDyc/dI5b8T5hshtkjS+E42TnysNCUPdjciGhY= +golang.org/x/sys v0.0.0-20181205085412-a5c9d58dba9a/go.mod h1:STP8DvDyc/dI5b8T5hshtkjS+E42TnysNCUPdjciGhY= +golang.org/x/sys v0.0.0-20190122071731-054c452bb702/go.mod h1:STP8DvDyc/dI5b8T5hshtkjS+E42TnysNCUPdjciGhY= +golang.org/x/sys v0.0.0-20190124100055-b90733256f2e/go.mod h1:STP8DvDyc/dI5b8T5hshtkjS+E42TnysNCUPdjciGhY= +golang.org/x/sys v0.0.0-20190209173611-3b5209105503/go.mod h1:STP8DvDyc/dI5b8T5hshtkjS+E42TnysNCUPdjciGhY= +golang.org/x/sys v0.0.0-20190215142949-d0b11bdaac8a/go.mod h1:STP8DvDyc/dI5b8T5hshtkjS+E42TnysNCUPdjciGhY= +golang.org/x/sys v0.0.0-20190228124157-a34e9553db1e/go.mod h1:STP8DvDyc/dI5b8T5hshtkjS+E42TnysNCUPdjciGhY= +golang.org/x/sys v0.0.0-20190312061237-fead79001313/go.mod h1:h1NjWce9XRLGQEsW7wpKNCjG9DtNlClVuFLEZdDNbEs= +golang.org/x/sys v0.0.0-20190321052220-f7bb7a8bee54/go.mod h1:h1NjWce9XRLGQEsW7wpKNCjG9DtNlClVuFLEZdDNbEs= +golang.org/x/sys v0.0.0-20190412213103-97732733099d/go.mod h1:h1NjWce9XRLGQEsW7wpKNCjG9DtNlClVuFLEZdDNbEs= +golang.org/x/sys v0.0.0-20190422165155-953cdadca894/go.mod h1:h1NjWce9XRLGQEsW7wpKNCjG9DtNlClVuFLEZdDNbEs= +golang.org/x/sys v0.0.0-20190502175342-a43fa875dd82/go.mod h1:h1NjWce9XRLGQEsW7wpKNCjG9DtNlClVuFLEZdDNbEs= +golang.org/x/sys v0.0.0-20190507160741-ecd444e8653b/go.mod h1:h1NjWce9XRLGQEsW7wpKNCjG9DtNlClVuFLEZdDNbEs= +golang.org/x/sys v0.0.0-20190616124812-15dcb6c0061f/go.mod h1:h1NjWce9XRLGQEsW7wpKNCjG9DtNlClVuFLEZdDNbEs= +golang.org/x/sys v0.0.0-20190813064441-fde4db37ae7a/go.mod h1:h1NjWce9XRLGQEsW7wpKNCjG9DtNlClVuFLEZdDNbEs= +golang.org/x/sys v0.0.0-20190826190057-c7b8b68b1456/go.mod h1:h1NjWce9XRLGQEsW7wpKNCjG9DtNlClVuFLEZdDNbEs= +golang.org/x/sys v0.0.0-20191022100944-742c48ecaeb7 h1:HmbHVPwrPEKPGLAcHSrMe6+hqSUlvZU0rab6x5EXfGU= +golang.org/x/sys v0.0.0-20191022100944-742c48ecaeb7/go.mod h1:h1NjWce9XRLGQEsW7wpKNCjG9DtNlClVuFLEZdDNbEs= +golang.org/x/text v0.0.0-20160726164857-2910a502d2bf/go.mod h1:NqM8EUOU14njkJ3fqMW+pc6Ldnwhi/IjpwHt7yyuwOQ= +golang.org/x/text v0.0.0-20170915090833-1cbadb444a80/go.mod h1:NqM8EUOU14njkJ3fqMW+pc6Ldnwhi/IjpwHt7yyuwOQ= +golang.org/x/text v0.3.0/go.mod h1:NqM8EUOU14njkJ3fqMW+pc6Ldnwhi/IjpwHt7yyuwOQ= +golang.org/x/text v0.3.1-0.20180807135948-17ff2d5776d2/go.mod h1:NqM8EUOU14njkJ3fqMW+pc6Ldnwhi/IjpwHt7yyuwOQ= +golang.org/x/text v0.3.2 h1:tW2bmiBqwgJj/UpqtC8EpXEZVYOwU0yG4iWbprSVAcs= +golang.org/x/text v0.3.2/go.mod h1:bEr9sfX3Q8Zfm5fL9x+3itogRgK3+ptLWKqgva+5dAk= +golang.org/x/time v0.0.0-20180412165947-fbb02b2291d2/go.mod h1:tRJNPiyCQ0inRvYxbN9jk5I+vvW/OXSQhTDSoE431IQ= +golang.org/x/time v0.0.0-20181108054448-85acf8d2951c/go.mod h1:tRJNPiyCQ0inRvYxbN9jk5I+vvW/OXSQhTDSoE431IQ= +golang.org/x/time v0.0.0-20190308202827-9d24e82272b4 h1:SvFZT6jyqRaOeXpc5h/JSfZenJ2O330aBsf7JfSUXmQ= +golang.org/x/time v0.0.0-20190308202827-9d24e82272b4/go.mod h1:tRJNPiyCQ0inRvYxbN9jk5I+vvW/OXSQhTDSoE431IQ= +golang.org/x/tools v0.0.0-20170915040203-e531a2a1c15f/go.mod h1:n7NCudcB/nEzxVGmLbDWY5pfWTLqBcC2KZ6jyYvM4mQ= +golang.org/x/tools v0.0.0-20180221164845-07fd8470d635/go.mod h1:n7NCudcB/nEzxVGmLbDWY5pfWTLqBcC2KZ6jyYvM4mQ= +golang.org/x/tools v0.0.0-20180525024113-a5b4c53f6e8b/go.mod h1:n7NCudcB/nEzxVGmLbDWY5pfWTLqBcC2KZ6jyYvM4mQ= +golang.org/x/tools v0.0.0-20180917221912-90fa682c2a6e/go.mod h1:n7NCudcB/nEzxVGmLbDWY5pfWTLqBcC2KZ6jyYvM4mQ= +golang.org/x/tools v0.0.0-20181011042414-1f849cf54d09/go.mod h1:n7NCudcB/nEzxVGmLbDWY5pfWTLqBcC2KZ6jyYvM4mQ= +golang.org/x/tools v0.0.0-20181030221726-6c7e314b6563/go.mod h1:n7NCudcB/nEzxVGmLbDWY5pfWTLqBcC2KZ6jyYvM4mQ= +golang.org/x/tools v0.0.0-20181117154741-2ddaf7f79a09/go.mod h1:n7NCudcB/nEzxVGmLbDWY5pfWTLqBcC2KZ6jyYvM4mQ= +golang.org/x/tools v0.0.0-20190110163146-51295c7ec13a/go.mod h1:n7NCudcB/nEzxVGmLbDWY5pfWTLqBcC2KZ6jyYvM4mQ= +golang.org/x/tools v0.0.0-20190114222345-bf090417da8b/go.mod h1:n7NCudcB/nEzxVGmLbDWY5pfWTLqBcC2KZ6jyYvM4mQ= +golang.org/x/tools v0.0.0-20190121143147-24cd39ecf745/go.mod h1:n7NCudcB/nEzxVGmLbDWY5pfWTLqBcC2KZ6jyYvM4mQ= +golang.org/x/tools v0.0.0-20190122202912-9c309ee22fab/go.mod h1:n7NCudcB/nEzxVGmLbDWY5pfWTLqBcC2KZ6jyYvM4mQ= +golang.org/x/tools v0.0.0-20190125232054-d66bd3c5d5a6/go.mod h1:n7NCudcB/nEzxVGmLbDWY5pfWTLqBcC2KZ6jyYvM4mQ= +golang.org/x/tools v0.0.0-20190206041539-40960b6deb8e/go.mod h1:n7NCudcB/nEzxVGmLbDWY5pfWTLqBcC2KZ6jyYvM4mQ= +golang.org/x/tools v0.0.0-20190226205152-f727befe758c/go.mod h1:9Yl7xja0Znq3iFh3HoIrodX9oNMXvdceNzlUR8zjMvY= +golang.org/x/tools v0.0.0-20190311212946-11955173bddd/go.mod h1:LCzVGOaR6xXOjkQ3onu1FJEFr0SW1gC7cKk1uF8kGRs= +golang.org/x/tools v0.0.0-20190311215038-5c2858a9cfe5/go.mod h1:LCzVGOaR6xXOjkQ3onu1FJEFr0SW1gC7cKk1uF8kGRs= +golang.org/x/tools v0.0.0-20190312151545-0bb0c0a6e846/go.mod h1:LCzVGOaR6xXOjkQ3onu1FJEFr0SW1gC7cKk1uF8kGRs= +golang.org/x/tools v0.0.0-20190312170243-e65039ee4138/go.mod h1:LCzVGOaR6xXOjkQ3onu1FJEFr0SW1gC7cKk1uF8kGRs= +golang.org/x/tools v0.0.0-20190322203728-c1a832b0ad89/go.mod h1:LCzVGOaR6xXOjkQ3onu1FJEFr0SW1gC7cKk1uF8kGRs= +golang.org/x/tools v0.0.0-20190328211700-ab21143f2384/go.mod h1:LCzVGOaR6xXOjkQ3onu1FJEFr0SW1gC7cKk1uF8kGRs= +golang.org/x/tools v0.0.0-20190425150028-36563e24a262/go.mod h1:RgjU9mgBXZiqYHBnxXauZ1Gv1EHHAz9KjViQ78xBX0Q= +golang.org/x/tools v0.0.0-20190506145303-2d16b83fe98c/go.mod h1:RgjU9mgBXZiqYHBnxXauZ1Gv1EHHAz9KjViQ78xBX0Q= +golang.org/x/tools v0.0.0-20190521203540-521d6ed310dd/go.mod h1:RgjU9mgBXZiqYHBnxXauZ1Gv1EHHAz9KjViQ78xBX0Q= +golang.org/x/tools v0.0.0-20190524140312-2c0ae7006135/go.mod h1:RgjU9mgBXZiqYHBnxXauZ1Gv1EHHAz9KjViQ78xBX0Q= +golang.org/x/tools v0.0.0-20190614205625-5aca471b1d59/go.mod h1:/rFqwRUd4F7ZHNgwSSTFct+R/Kf4OFW1sUzUTQQTgfc= +golang.org/x/tools v0.0.0-20190617190820-da514acc4774/go.mod h1:/rFqwRUd4F7ZHNgwSSTFct+R/Kf4OFW1sUzUTQQTgfc= +golang.org/x/tools v0.0.0-20190621195816-6e04913cbbac/go.mod h1:/rFqwRUd4F7ZHNgwSSTFct+R/Kf4OFW1sUzUTQQTgfc= +golang.org/x/tools v0.0.0-20190909030654-5b82db07426d/go.mod h1:b+2E5dAYhXwXZwtnZ6UAqBI28+e2cm9otk0dWdXHAEo= +golang.org/x/tools v0.0.0-20190920225731-5eefd052ad72/go.mod h1:b+2E5dAYhXwXZwtnZ6UAqBI28+e2cm9otk0dWdXHAEo= +golang.org/x/xerrors v0.0.0-20190717185122-a985d3407aa7/go.mod h1:I/5z698sn9Ka8TeJc9MKroUUfqBBauWjQqLJ2OPfmY0= +gonum.org/v1/gonum v0.0.0-20180816165407-929014505bf4/go.mod h1:Y+Yx5eoAFn32cQvJDxZx5Dpnq+c3wtXuadVZAcxbbBo= +gonum.org/v1/gonum v0.0.0-20190331200053-3d26580ed485/go.mod h1:2ltnJ7xHfj0zHS40VVPYEAAMTa3ZGguvHGBSJeRWqE0= +gonum.org/v1/gonum v0.6.2/go.mod h1:9mxDZsDKxgMAuccQkewq682L+0eCu4dCN2yonUJTCLU= +gonum.org/v1/netlib v0.0.0-20190313105609-8cb42192e0e0/go.mod h1:wa6Ws7BG/ESfp6dHfk7C6KdzKA7wR7u/rKwOGE66zvw= +gonum.org/v1/netlib v0.0.0-20190331212654-76723241ea4e/go.mod h1:kS+toOQn6AQKjmKJ7gzohV1XkqsFehRA2FbsbkopSuQ= +gonum.org/v1/plot v0.0.0-20190515093506-e2840ee46a6b/go.mod h1:Wt8AAjI+ypCyYX3nZBvf6cAIx93T+c/OS2HFAYskSZc= +google.golang.org/api v0.4.0/go.mod h1:8k5glujaEP+g9n7WNsDg8QP6cUVNI86fCNMcbazEtwE= +google.golang.org/api v0.6.1-0.20190607001116-5213b8090861/go.mod h1:btoxGiFvQNVUZQ8W08zLtrVS08CNpINPEfxXxgJL1Q4= +google.golang.org/appengine v1.1.0/go.mod h1:EbEs0AVv82hx2wNQdGPgUI5lhzA/G0D9YwlJXL52JkM= +google.golang.org/appengine v1.4.0/go.mod h1:xpcJRLb0r/rnEns0DIKYYv+WjYCduHsrkT7/EB5XEv4= +google.golang.org/appengine v1.5.0 h1:KxkO13IPW4Lslp2bz+KHP2E3gtFlrIGNThxkZQ3g+4c= +google.golang.org/appengine v1.5.0/go.mod h1:xpcJRLb0r/rnEns0DIKYYv+WjYCduHsrkT7/EB5XEv4= +google.golang.org/genproto v0.0.0-20180817151627-c66870c02cf8/go.mod h1:JiN7NxoALGmiZfu7CAH4rXhgtRTLTxftemlI0sWmxmc= +google.golang.org/genproto v0.0.0-20190307195333-5fe7a883aa19/go.mod h1:VzzqZJRnGkLBvHegQrXjBqPurQTc5/KpmUdxsrq26oE= +google.golang.org/genproto v0.0.0-20190418145605-e7d98fc518a7/go.mod h1:VzzqZJRnGkLBvHegQrXjBqPurQTc5/KpmUdxsrq26oE= +google.golang.org/genproto v0.0.0-20190502173448-54afdca5d873/go.mod h1:VzzqZJRnGkLBvHegQrXjBqPurQTc5/KpmUdxsrq26oE= +google.golang.org/genproto v0.0.0-20190819201941-24fa4b261c55 h1:gSJIx1SDwno+2ElGhA4+qG2zF97qiUzTM+rQ0klBOcE= +google.golang.org/genproto v0.0.0-20190819201941-24fa4b261c55/go.mod h1:DMBHOl98Agz4BDEuKkezgsaosCRResVns1a3J2ZsMNc= +google.golang.org/grpc v1.19.0/go.mod h1:mqu4LbDTu4XGKhr4mRzUsmM4RtVoemTSY81AxZiDr8c= +google.golang.org/grpc v1.20.1/go.mod h1:10oTOabMzJvdu6/UiuZezV6QK5dSlG84ov/aaiqXj38= +google.golang.org/grpc v1.23.0/go.mod h1:Y5yQAOtifL1yxbo5wqy6BxZv8vAUGQwXBOALyacEbxg= +google.golang.org/grpc v1.23.1/go.mod h1:Y5yQAOtifL1yxbo5wqy6BxZv8vAUGQwXBOALyacEbxg= +google.golang.org/grpc v1.26.0 h1:2dTRdpdFEEhJYQD8EMLB61nnrzSCTbG38PhqdhvOltg= +google.golang.org/grpc v1.26.0/go.mod h1:qbnxyOmOxrQa7FizSgH+ReBfzJrCY1pSN7KXBS8abTk= +gopkg.in/airbrake/gobrake.v2 v2.0.9/go.mod h1:/h5ZAUhDkGaJfjzjKLSjv6zCL6O0LLBxU4K+aSYdM/U= +gopkg.in/alecthomas/kingpin.v2 v2.2.6/go.mod h1:FMv+mEhP44yOT+4EoQTLFTRgOQ1FBLkstjWtayDeSgw= +gopkg.in/check.v1 v0.0.0-20161208181325-20d25e280405/go.mod h1:Co6ibVJAznAaIkqp8huTwlJQCZ016jof/cbN4VW5Yz0= +gopkg.in/check.v1 v1.0.0-20180628173108-788fd7840127 h1:qIbj1fsPNlZgppZ+VLlY7N33q108Sa+fhmuc+sWQYwY= +gopkg.in/check.v1 v1.0.0-20180628173108-788fd7840127/go.mod h1:Co6ibVJAznAaIkqp8huTwlJQCZ016jof/cbN4VW5Yz0= +gopkg.in/cheggaaa/pb.v1 v1.0.25/go.mod h1:V/YB90LKu/1FcN3WVnfiiE5oMCibMjukxqG/qStrOgw= +gopkg.in/errgo.v2 v2.1.0/go.mod h1:hNsd1EY+bozCKY1Ytp96fpM3vjJbqLJn88ws8XvfDNI= +gopkg.in/fsnotify.v1 v1.4.7/go.mod h1:Tz8NjZHkW78fSQdbUxIjBTcgA1z1m8ZHf0WmKUhAMys= +gopkg.in/gcfg.v1 v1.2.0/go.mod h1:yesOnuUOFQAhST5vPY4nbZsb/huCgGGXlipJsBn0b3o= +gopkg.in/gemnasium/logrus-airbrake-hook.v2 v2.1.2/go.mod h1:Xk6kEKp8OKb+X14hQBKWaSkCsqBpgog8nAV2xsGOxlo= +gopkg.in/inf.v0 v0.9.1 h1:73M5CoZyi3ZLMOyDlQh031Cx6N9NDJ2Vvfl76EDAgDc= +gopkg.in/inf.v0 v0.9.1/go.mod h1:cWUDdTG/fYaXco+Dcufb5Vnc6Gp2YChqWtbxRZE0mXw= +gopkg.in/mcuadros/go-syslog.v2 v2.2.1/go.mod h1:l5LPIyOOyIdQquNg+oU6Z3524YwrcqEm0aKH+5zpt2U= +gopkg.in/natefinch/lumberjack.v2 v2.0.0/go.mod h1:l0ndWWf7gzL7RNwBG7wST/UCcT4T24xpD6X8LsfU/+k= +gopkg.in/resty.v1 v1.12.0/go.mod h1:mDo4pnntr5jdWRML875a/NmxYqAlA73dVijT2AXvQQo= +gopkg.in/square/go-jose.v2 v2.2.2/go.mod h1:M9dMgbHiYLoDGQrXy7OpJDJWiKiU//h+vD76mk0e1AI= +gopkg.in/tomb.v1 v1.0.0-20141024135613-dd632973f1e7/go.mod h1:dt/ZhP58zS4L8KSrWDmTeBkI65Dw0HsyUHuEVlX15mw= +gopkg.in/warnings.v0 v0.1.1/go.mod h1:jksf8JmL6Qr/oQM2OXTHunEvvTAsrWBLb6OOjuVWRNI= +gopkg.in/yaml.v2 v2.0.0-20170812160011-eb3733d160e7/go.mod h1:JAlM8MvJe8wmxCU4Bli9HhUf9+ttbYbLASfIpnQbh74= +gopkg.in/yaml.v2 v2.2.1/go.mod h1:hI93XBmqTisBFMUTm0b8Fm+jr3Dg1NNxqwp+5A1VGuI= +gopkg.in/yaml.v2 v2.2.2/go.mod h1:hI93XBmqTisBFMUTm0b8Fm+jr3Dg1NNxqwp+5A1VGuI= +gopkg.in/yaml.v2 v2.2.4/go.mod h1:hI93XBmqTisBFMUTm0b8Fm+jr3Dg1NNxqwp+5A1VGuI= +gopkg.in/yaml.v2 v2.2.8 h1:obN1ZagJSUGI0Ek/LBmuj4SNLPfIny3KsKFopxRdj10= +gopkg.in/yaml.v2 v2.2.8/go.mod h1:hI93XBmqTisBFMUTm0b8Fm+jr3Dg1NNxqwp+5A1VGuI= +gotest.tools v2.1.0+incompatible/go.mod h1:DsYFclhRJ6vuDpmuTbkuFWG+y2sxOXAzmJt81HFBacw= +gotest.tools v2.2.0+incompatible/go.mod h1:DsYFclhRJ6vuDpmuTbkuFWG+y2sxOXAzmJt81HFBacw= +gotest.tools/gotestsum v0.3.5/go.mod h1:Mnf3e5FUzXbkCfynWBGOwLssY7gTQgCHObK9tMpAriY= +grpc.go4.org v0.0.0-20170609214715-11d0a25b4919/go.mod h1:77eQGdRu53HpSqPFJFmuJdjuHRquDANNeA4x7B8WQ9o= +honnef.co/go/tools v0.0.0-20190102054323-c2f93a96b099/go.mod h1:rf3lG4BRIbNafJWhAfAdb/ePZxsR/4RtNHQocxwk9r4= +honnef.co/go/tools v0.0.0-20190106161140-3f1c8253044a/go.mod h1:rf3lG4BRIbNafJWhAfAdb/ePZxsR/4RtNHQocxwk9r4= +honnef.co/go/tools v0.0.0-20190418001031-e561f6794a2a/go.mod h1:rf3lG4BRIbNafJWhAfAdb/ePZxsR/4RtNHQocxwk9r4= +honnef.co/go/tools v0.0.0-20190523083050-ea95bdfd59fc/go.mod h1:rf3lG4BRIbNafJWhAfAdb/ePZxsR/4RtNHQocxwk9r4= +honnef.co/go/tools v0.0.1-2019.2.2/go.mod h1:a3bituU0lyd329TUQxRnasdCoJDkEUEAqEt0JzvZhAg= +k8s.io/api v0.18.4 h1:8x49nBRxuXGUlDlwlWd3RMY1SayZrzFfxea3UZSkFw4= +k8s.io/api v0.18.4/go.mod h1:lOIQAKYgai1+vz9J7YcDZwC26Z0zQewYOGWdyIPUUQ4= +k8s.io/apiextensions-apiserver v0.18.4/go.mod h1:NYeyeYq4SIpFlPxSAB6jHPIdvu3hL0pc36wuRChybio= +k8s.io/apimachinery v0.18.4 h1:ST2beySjhqwJoIFk6p7Hp5v5O0hYY6Gngq/gUYXTPIA= +k8s.io/apimachinery v0.18.4/go.mod h1:OaXp26zu/5J7p0f92ASynJa1pZo06YlV9fG7BoWbCko= +k8s.io/apiserver v0.18.4 h1:pn1jSQkfboPSirZopkVpEdLW4FcQLnYMaIY8LFxxj30= +k8s.io/apiserver v0.18.4/go.mod h1:q+zoFct5ABNnYkGIaGQ3bcbUNdmPyOCoEBcg51LChY8= +k8s.io/cli-runtime v0.18.4/go.mod h1:9/hS/Cuf7NVzWR5F/5tyS6xsnclxoPLVtwhnkJG1Y4g= +k8s.io/client-go v0.18.4 h1:un55V1Q/B3JO3A76eS0kUSywgGK/WR3BQ8fHQjNa6Zc= +k8s.io/client-go v0.18.4/go.mod h1:f5sXwL4yAZRkAtzOxRWUhA/N8XzGCb+nPZI8PfobZ9g= +k8s.io/cloud-provider v0.18.4/go.mod h1:JdI6cuSFPSPANEciv0v5qfwztkeyFCVc1S3krLYrw0E= +k8s.io/cluster-bootstrap v0.18.4/go.mod h1:hNG705ec9SMN2BGlJ81R2CnyJjNKfROtAxvI9JXZdiM= +k8s.io/code-generator v0.18.4/go.mod h1:TgNEVx9hCyPGpdtCWA34olQYLkh3ok9ar7XfSsr8b6c= +k8s.io/component-base v0.18.4 h1:Kr53Fp1iCGNsl9Uv4VcRvLy7YyIqi9oaJOQ7SXtKI98= +k8s.io/component-base v0.18.4/go.mod h1:7jr/Ef5PGmKwQhyAz/pjByxJbC58mhKAhiaDu0vXfPk= +k8s.io/cri-api v0.18.4/go.mod h1:OJtpjDvfsKoLGhvcc0qfygved0S0dGX56IJzPbqTG1s= +k8s.io/csi-translation-lib v0.18.4/go.mod h1:FTci2m8/3oN8E+8OyblBXei8w4mwbiH4boNPeob4piE= +k8s.io/gengo v0.0.0-20190128074634-0689ccc1d7d6/go.mod h1:ezvh/TsK7cY6rbqRK0oQQ8IAqLxYwwyPxAX1Pzy0ii0= +k8s.io/gengo v0.0.0-20200114144118-36b2048a9120/go.mod h1:ezvh/TsK7cY6rbqRK0oQQ8IAqLxYwwyPxAX1Pzy0ii0= +k8s.io/heapster v1.2.0-beta.1/go.mod h1:h1uhptVXMwC8xtZBYsPXKVi8fpdlYkTs6k949KozGrM= +k8s.io/klog v0.0.0-20181102134211-b9b56d5dfc92/go.mod h1:Gq+BEi5rUBO/HRz0bTSXDUcqjScdoY3a9IHpCEIOOfk= +k8s.io/klog v0.3.0/go.mod h1:Gq+BEi5rUBO/HRz0bTSXDUcqjScdoY3a9IHpCEIOOfk= +k8s.io/klog v1.0.0 h1:Pt+yjF5aB1xDSVbau4VsWe+dQNzA0qv1LlXdC2dF6Q8= +k8s.io/klog v1.0.0/go.mod h1:4Bi6QPql/J/LkTDqv7R/cd3hPo4k2DG6Ptcz060Ez5I= +k8s.io/kube-aggregator v0.18.4/go.mod h1:xOVy4wqhpivXCt07Diwdms2gonG+SONVx+1e7O+GfC0= +k8s.io/kube-controller-manager v0.18.4/go.mod h1:GrY1S0F7zA0LQlt0ApOLt4iMpphKTk3mFrQl1+usrfs= +k8s.io/kube-openapi v0.0.0-20200410145947-61e04a5be9a6/go.mod h1:GRQhZsXIAJ1xR0C9bd8UpWHZ5plfAS9fzPjJuQ6JL3E= +k8s.io/kube-proxy v0.18.4/go.mod h1:h2c+ckQC1XpybDs53mWhLCvvM6txduWVLPQwwvGqR9M= +k8s.io/kube-scheduler v0.18.4/go.mod h1:vRFb/8Yi7hh670beaPrXttMpjt7H8EooDkgwFm8ts4k= +k8s.io/kubectl v0.18.4/go.mod h1:EzB+nfeUWk6fm6giXQ8P4Fayw3dsN+M7Wjy23mTRtB0= +k8s.io/kubelet v0.18.4/go.mod h1:D0V9JYaTJRF+ry+9JfnM4uyg3ySRLQ02XjfQ5f2u4CM= +k8s.io/kubernetes v1.18.4 h1:AYtJ24PIT91P1K8ekCrvay8LK8WctWhC5+NI0HZ8sqE= +k8s.io/kubernetes v1.18.4/go.mod h1:Efg82S+Ti02A/Mww53bxroc7IgzX2bgPsf6hT8gAs3M= +k8s.io/legacy-cloud-providers v0.18.4/go.mod h1:Mnxtra7DxVrODfGZHPsrkLi22lwmZOlWkjyyO3vW+WM= +k8s.io/metrics v0.18.4/go.mod h1:luze4fyI9JG4eLDZy0kFdYEebqNfi0QrG4xNEbPkHOs= +k8s.io/repo-infra v0.0.1-alpha.1/go.mod h1:wO1t9WaB99V80ljbeENTnayuEEwNZt7gECYh/CEyOJ8= +k8s.io/sample-apiserver v0.18.4/go.mod h1:j5XH5FUmMd/ztoz+9ch0+hL+lsvWdgxnTV7l3P3Ijoo= +k8s.io/system-validators v1.0.4/go.mod h1:HgSgTg4NAGNoYYjKsUyk52gdNi2PVDswQ9Iyn66R7NI= +k8s.io/utils v0.0.0-20200324210504-a9aa75ae1b89 h1:d4vVOjXm687F1iLSP2q3lyPPuyvTUt3aVoBpi2DqRsU= +k8s.io/utils v0.0.0-20200324210504-a9aa75ae1b89/go.mod h1:sZAwmy6armz5eXlNoLmJcl4F1QuKu7sr+mFQ0byX7Ew= +modernc.org/cc v1.0.0/go.mod h1:1Sk4//wdnYJiUIxnW8ddKpaOJCF37yAdqYnkxUpaYxw= +modernc.org/golex v1.0.0/go.mod h1:b/QX9oBD/LhixY6NDh+IdGv17hgB+51fET1i2kPSmvk= +modernc.org/mathutil v1.0.0/go.mod h1:wU0vUrJsVWBZ4P6e7xtFJEhFSNsfRLJ8H458uRjg03k= +modernc.org/strutil v1.0.0/go.mod h1:lstksw84oURvj9y3tn8lGvRxyRC1S2+g5uuIzNfIOBs= +modernc.org/xc v1.0.0/go.mod h1:mRNCo0bvLjGhHO9WsyuKVU4q0ceiDDDoEeWDJHrNx8I= +mvdan.cc/interfacer v0.0.0-20180901003855-c20040233aed/go.mod h1:Xkxe497xwlCKkIaQYRfC7CSLworTXY9RMqwhhCm+8Nc= +mvdan.cc/lint v0.0.0-20170908181259-adc824a0674b/go.mod h1:2odslEg/xrtNQqCYg2/jCoyKnw3vv5biOc3JnIcYfL4= +mvdan.cc/unparam v0.0.0-20190209190245-fbb59629db34/go.mod h1:H6SUd1XjIs+qQCyskXg5OFSrilMRUkD8ePJpHKDPaeY= +rsc.io/pdf v0.1.1/go.mod h1:n8OzWcQ6Sp37PL01nO98y4iUCRdTGarVfzxY20ICaU4= +sigs.k8s.io/apiserver-network-proxy/konnectivity-client v0.0.7 h1:uuHDyjllyzRyCIvvn0OBjiRB0SgBZGqHNYAmjR7fO50= +sigs.k8s.io/apiserver-network-proxy/konnectivity-client v0.0.7/go.mod h1:PHgbrJT7lCHcxMU+mDHEm+nx46H4zuuHZkDP6icnhu0= +sigs.k8s.io/kustomize v2.0.3+incompatible/go.mod h1:MkjgH3RdOWrievjo6c9T245dYlB5QeXV4WCbnt/PEpU= +sigs.k8s.io/structured-merge-diff/v3 v3.0.0-20200116222232-67a7b8c61874/go.mod h1:PlARxl6Hbt/+BC80dRLi1qAmnMqwqDg62YvvVkZjemw= +sigs.k8s.io/structured-merge-diff/v3 v3.0.0 h1:dOmIZBMfhcHS09XZkMyUgkq5trg3/jRyJYFZUiaOp8E= +sigs.k8s.io/structured-merge-diff/v3 v3.0.0/go.mod h1:PlARxl6Hbt/+BC80dRLi1qAmnMqwqDg62YvvVkZjemw= +sigs.k8s.io/yaml v1.1.0/go.mod h1:UJmg0vDUVViEyp3mgSv9WPwZCDxu4rQW1olrI1uml+o= +sigs.k8s.io/yaml v1.2.0 h1:kr/MCeFWJWTwyaHoR9c8EjH9OumOmoF9YGiZd7lFm/Q= +sigs.k8s.io/yaml v1.2.0/go.mod h1:yfXDCHCao9+ENCvLSE62v9VSji2MKu5jeNfTrofGhJc= +sourcegraph.com/sqs/pbtypes v0.0.0-20180604144634-d3ebe8f20ae4/go.mod h1:ketZ/q3QxT9HOBeFhu6RdvsftgpsbFHBF5Cas6cDKZ0= +vbom.ml/util v0.0.0-20160121211510-db5cfe13f5cc/go.mod h1:so/NYdZXCz+E3ZpW0uAoCj6uzU2+8OWDFv/HxUSs7kI= diff --git a/i18n/de.toml b/i18n/de.toml index 4155902ec7..cd4c3d7924 100644 --- a/i18n/de.toml +++ b/i18n/de.toml @@ -15,6 +15,9 @@ other = "Aufräumen" [prerequisites_heading] other = "Bevor Sie beginnen" +[subscribe_button] +other = "Abonnieren" + [whatsnext_heading] other = "Nächste Schritte" diff --git a/i18n/en.toml b/i18n/en.toml index eb6f20dde1..c59107c7c8 100644 --- a/i18n/en.toml +++ b/i18n/en.toml @@ -210,8 +210,11 @@ other = "Your Kubernetes server must be at or later than version " [version_check_tocheck] other = "To check the version, enter " +[version_menu] +other = "Versions" + [warning] other = "Warning:" [whatsnext_heading] -other = "What's next" \ No newline at end of file +other = "What's next" diff --git a/i18n/ja.toml b/i18n/ja.toml index db01fd5878..460e68b3f7 100644 --- a/i18n/ja.toml +++ b/i18n/ja.toml @@ -58,6 +58,9 @@ other = "このページは役に立ちましたか？" [feedback_yes] other = "はい" +[input_placeholder_email_address] +other = "メールアドレス" + [latest_version] other = "最新バージョン" @@ -187,11 +190,11 @@ other = "作業するKubernetesサーバーは次のバージョン以降のも [version_check_tocheck] other = "バージョンを確認するには次のコマンドを実行してください: " -[whatsnext_heading] -other = "次の項目" +[version_menu] +other = "バージョン" [warning] other = "警告:" -[input_placeholder_email_address] -other = "メールアドレス" +[whatsnext_heading] +other = "次の項目" diff --git a/i18n/pt.toml b/i18n/pt.toml index 833e4ba627..9b715dcf8f 100644 --- a/i18n/pt.toml +++ b/i18n/pt.toml @@ -1,26 +1,54 @@ -# i18n strings for the Portuguese (main) site. - -[deprecation_warning] -other = " a documentação não é mais mantida ativamente. A versão que você está visualizando no momento é uma captura instantânea estática. Para obter documentação atualizada, consulte " - -[deprecation_file_warning] -other = "Descontinuado" - -[objectives_heading] -other = "Objetivos" + # i18n strings for the Portuguese (main) site. +[caution] +other = "Cuidado:" [cleanup_heading] other = "Limpando" -[prerequisites_heading] -other = "Antes de você começar" +[community_events_calendar] +other = "Calendário de Eventos" -[whatsnext_heading] -other = "Qual é o próximo" +[community_forum_name] +other = "Fórum" + +[community_github_name] +other = "GitHub" + +# Community links + +[community_slack_name] +other = "Slack" + +[community_stack_overflow_name] +other = "Stack Overflow" + +[community_twitter_name] +other = "Twitter" + +[deprecation_file_warning] +other = "Descontinuado" + +[deprecation_warning] +other = " a documentação não é mais mantida ativamente. A versão que você está visualizando no momento é uma captura instantânea estática. Para obter documentação atualizada, consulte " + +[docs_label_browse] +other = "Procurar documentos" + +[docs_label_contributors] +other = "Colaboradores" + +[docs_label_i_am] +other = "Eu sou..." + +[docs_label_users] +other = "Usuários" [feedback_heading] other = "Comentários" +[feedback_no] +other = "Não" + [feedback_question] other = "Esta página foi útil?" @@ -30,169 +58,138 @@ other = "Sim" [input_placeholder_email_address] other = "endereço de e-mail" -[feedback_no] -other = "Não" - [latest_version] other = "última versão." -[version_check_mustbe] -other = "Seu servidor Kubernetes deve ser versão" - -[version_check_mustbeorlater] -other = "O seu servidor Kubernetes deve estar em ou depois da versão " - -[version_check_tocheck] -other = "Para verificar a versão, digite " - -[caution] -other = "Cuidado:" - -[note] -other = "Nota:" - -[warning] -other = "Aviso:" - -[main_read_about] -other = "Ler sobre" - -[main_read_more] -other = "Consulte Mais informação" - -[main_github_invite] -other = "Interessado em mergulhar na base de código do Kubernetes?" - -[main_github_view_on] -other = "Veja no Github" - -[main_github_create_an_issue] -other = "Abra um bug" - -[main_community_explore] -other = "Explore a comunidade" - -[main_kubernetes_features] -other = "Recursos do Kubernetes" - -[main_cncf_project] -other = """Nós somos uma <a href="https://cncf.io/">CNCF</a> projeto graduado</p>""" - -[main_kubeweekly_baseline] -other = "Interessado em receber as últimas novidades sobre Kubernetes? Inscreva-se no KubeWeekly." - -[main_kubernetes_past_link] -other = "Veja boletins passados" - -[main_kubeweekly_signup] -other = "Se inscrever" - -[main_contribute] -other = "Contribuir" - -[main_edit_this_page] -other = "Edite essa página" - -[main_page_history] -other ="História da página" - -[main_page_last_modified_on] -other = "Última modificação da página em" - -[main_by] -other = "por" - -[main_documentation_license] -other = """Os autores do Kubernetes | Documentação Distribuída sob <a href="https://git.k8s.io/website/LICENSE" class="light-text">CC BY 4.0</a>""" - -[main_copyright_notice] -other = """A Fundação Linux ®. Todos os direitos reservados. A Linux Foundation tem marcas registradas e usa marcas registradas. Para uma lista de marcas registradas da The Linux Foundation, por favor, veja nossa <a href="https://www.linuxfoundation.org/trademark-usage" class="light-text">Página de uso de marca registrada</a>""" - -# Labels for the docs portal home page. -[docs_label_browse] -other = "Procurar documentos" - -[docs_label_contributors] -other = "Colaboradores" - -[docs_label_users] -other = "Usuários" - -[docs_label_i_am] -other = "Eu sou..." - -# layouts > blog > pager - -[layouts_blog_pager_prev] -other = "<< Anterior" - [layouts_blog_pager_next] other = "Próximo >>" -# layouts > blog > list +[layouts_blog_pager_prev] +other = "<< Anterior" [layouts_case_studies_list_tell] other = "Conte seu caso" -# layouts > docs > glossary +[layouts_docs_glossary_aka] +other = "Também conhecido como" + +[layouts_docs_glossary_click_details_after] +other = "indicadores abaixo para uma maior explicação sobre um termo em particular." + +[layouts_docs_glossary_click_details_before] +other = "Clique nos" [layouts_docs_glossary_description] other = "Este glossário pretende ser uma lista padronizada e abrangente da terminologia do Kubernetes. Inclui termos técnicos específicos dos K8s, além de termos mais gerais que fornecem um contexto útil." +[layouts_docs_glossary_deselect_all] +other = "Desmarcar tudo" + [layouts_docs_glossary_filter] other = "Filtrar termos de acordo com suas tags" [layouts_docs_glossary_select_all] other = "Selecionar tudo" -[layouts_docs_glossary_deselect_all] -other = "Desmarcar tudo" - -[layouts_docs_glossary_aka] -other = "Também conhecido como" - -[layouts_docs_glossary_click_details_before] -other = "Clique nos" - -[layouts_docs_glossary_click_details_after] -other = "indicadores abaixo para uma maior explicação sobre um termo em particular." - -# layouts > docs > search - -[layouts_docs_search_fetching] -other = "Buscando resultados.." - -# layouts > partial > feedback - -[layouts_docs_partials_feedback_thanks] -other = "Obrigado pelo feedback. Se você tiver uma pergunta específica sobre como utilizar o Kubernetes, faça em" +[layouts_docs_partials_feedback_improvement] +other = "sugerir uma melhoria" [layouts_docs_partials_feedback_issue] other = "Abra um bug no repositório do GitHub se você deseja " -[layouts_docs_partials_feedback_problem] -other = "reportar um problema" - [layouts_docs_partials_feedback_or] other = "ou" -[layouts_docs_partials_feedback_improvement] -other = "sugerir uma melhoria" +[layouts_docs_partials_feedback_problem] +other = "reportar um problema" -# Community links -[community_twitter_name] -other = "Twitter" -[community_github_name] -other = "GitHub" -[community_slack_name] -other = "Slack" -[community_stack_overflow_name] -other = "Stack Overflow" -[community_forum_name] -other = "Fórum" -[community_events_calendar] -other = "Calendário de Eventos" +[layouts_docs_partials_feedback_thanks] +other = "Obrigado pelo feedback. Se você tiver uma pergunta específica sobre como utilizar o Kubernetes, faça em" + +[layouts_docs_search_fetching] +other = "Buscando resultados.." + +# Main page localization + +[main_by] +other = "por" + +[main_cncf_project] +other = """Nós somos uma <a href="https://cncf.io/">CNCF</a> projeto graduado</p>""" + +[main_community_explore] +other = "Explore a comunidade" + +[main_contribute] +other = "Contribuir" + +[main_copyright_notice] +other = """A Fundação Linux ®. Todos os direitos reservados. A Linux Foundation tem marcas registradas e usa marcas registradas. Para uma lista de marcas registradas da The Linux Foundation, por favor, veja nossa <a href="https://www.linuxfoundation.org/trademark-usage" class="light-text">Página de uso de marca registrada</a>""" + +[main_documentation_license] +other = """Os autores do Kubernetes | Documentação Distribuída sob <a href="https://git.k8s.io/website/LICENSE" class="light-text">CC BY 4.0</a>""" + +[main_edit_this_page] +other = "Edite essa página" + +[main_github_create_an_issue] +other = "Abra um bug" + +[main_github_invite] +other = "Interessado em mergulhar na base de código do Kubernetes?" + +[main_github_view_on] +other = "Veja no Github" + +[main_kubernetes_features] +other = "Recursos do Kubernetes" + +[main_kubernetes_past_link] +other = "Veja boletins passados" + +[main_kubeweekly_baseline] +other = "Interessado em receber as últimas novidades sobre Kubernetes? Inscreva-se no KubeWeekly." + +[main_kubeweekly_signup] +other = "Se inscrever" + +[main_page_history] +other ="História da página" + +[main_page_last_modified_on] +other = "Última modificação da página em" + +[main_read_about] +other = "Ler sobre" + +[main_read_more] +other = "Consulte Mais informação" + +# Miscellaneous + +[note] +other = "Nota:" + +[objectives_heading] +other = "Objetivos" + +[prerequisites_heading] +other = "Antes de você começar" -# UI elements [ui_search_placeholder] other = "Procurar" + +[version_check_mustbeorlater] +other = "O seu servidor Kubernetes deve estar em ou depois da versão " + +[version_check_mustbe] +other = "Seu servidor Kubernetes deve ser versão" + +[version_check_tocheck] +other = "Para verificar a versão, digite " + +[warning] +other = "Aviso:" + +[whatsnext_heading] +other = "Qual é o próximo" diff --git a/i18n/zh.toml b/i18n/zh.toml index c42c53fd70..7446f8589a 100644 --- a/i18n/zh.toml +++ b/i18n/zh.toml @@ -2,7 +2,7 @@ # 注意：修改此文件时请维持字符串名称的字母顺序并与英文版保持一致 [caution] -other = "警告:" +other = "注意：" [cleanup_heading] other = "清理现场" @@ -28,6 +28,9 @@ other = "Twitter" [community_youtube_name] other = "YouTube" +[deprecation_title] +other = "您正在查看 Kubernetes 版本的文档：" + [deprecation_warning] other = " 版本的文档已不再维护。您现在看到的版本来自于一份静态的快照。如需查阅最新文档，请点击" @@ -46,6 +49,9 @@ other = "我是..." [docs_label_users] other = "用户" +[examples_heading] +other = "示例" + [feedback_heading] other = "反馈" @@ -58,6 +64,9 @@ other = "此页是否对您有帮助？" [feedback_yes] other = "是" +[input_placeholder_email_address] +other = "电子邮件地址" + [latest_version] other = "最新版本。" @@ -164,17 +173,26 @@ other = "了解" other = "了解更多" [note] -other = "注意：" +other = "说明：" [objectives_heading] other = "教程目标" +[options_heading] +other = "选项" + [prerequisites_heading] other = "准备开始" +[seealso_heading] +other = "另请参见" + [subscribe_button] other = "订阅" +[synopsis_heading] +other = "简介" + [ui_search_placeholder] other = "搜索" @@ -191,7 +209,4 @@ other = "要获知版本信息，请输入 " other = "警告：" [whatsnext_heading] -other = "接下来" - -[input_placeholder_email_address] -other = "电子邮件地址" +other = "接下来" \ No newline at end of file diff --git a/layouts/case-studies/list.html b/layouts/case-studies/list.html index 05aca4ecb1..deec393953 100644 --- a/layouts/case-studies/list.html +++ b/layouts/case-studies/list.html @@ -3,11 +3,11 @@ {{ with site.Params.language_alternatives }} {{ range . }} {{ with (where $.Translations ".Lang" . ) }} - {{ $p := index . 0 }} + {{ $p := index . 0 }} {{ $pages = $pages | lang.Merge $p.Pages }} {{ end }} {{ end }} -{{ end }} +{{ end }} {{ $featured := (where $pages "Params.featured" true).ByWeight | first 4 }} <section id="mainContent"> <div class="main-section"> @@ -59,7 +59,7 @@ {{ end }} </a> {{ end }} - <a target="_blank" href="https://docs.google.com/a/google.com/forms/d/e/1FAIpQLScuI7Ye3VQHQTwBASrgkjQDSS5TP0g3AXfFhwSM9YpHgxRKFA/viewform" class="tell-your-story"><img height="127px"src="/images/case_studies/story.svg" alt="{{ T "layouts_case_studies_list_tell" }}"></a> + <a target="_blank" href="https://docs.google.com/a/google.com/forms/d/e/1FAIpQLScuI7Ye3VQHQTwBASrgkjQDSS5TP0g3AXfFhwSM9YpHgxRKFA/viewform" class="tell-your-story"><img height="127px"src="/images/case-studies/story.svg" alt="{{ T "layouts_case_studies_list_tell" }}"></a> </div> </div> </section> diff --git a/layouts/case-studies/single-baseof.html b/layouts/case-studies/single-baseof.html index e97cbf934d..64b48a4e13 100644 --- a/layouts/case-studies/single-baseof.html +++ b/layouts/case-studies/single-baseof.html @@ -9,5 +9,7 @@ {{ partialCached "footer.html" . }} <!-- Disabling this as elements queries do not appear to exist on case studies --> <!-- {{ partialCached "footer-scripts.html" . }} --> + {{ partialCached "scripts.html" . }} + </body> </html> \ No newline at end of file diff --git a/layouts/docs/list.html b/layouts/docs/list.html index ef24f907e1..81403b5396 100644 --- a/layouts/docs/list.html +++ b/layouts/docs/list.html @@ -1,6 +1,5 @@ {{ define "main" }} <div class="td-content"> - {{ with .Params.description }}<div class="lead">{{ . | markdownify }}</div>{{ end }} {{ $hasContent := false }} {{ with .File }} {{ if ne .Filename "" }} @@ -11,6 +10,7 @@ {{ partial "docs/content-page" (dict "ctx" $ "page" $ ) }} {{ else }} <h1>{{ .Title }}</h1> + {{ with .Params.description }}<div class="lead">{{ . | markdownify }}</div>{{ end }} {{ end }} {{ partial "section-index.html" . }} </div> diff --git a/layouts/partials/announcement.html b/layouts/partials/announcement.html index 9313885ab0..2ec2e96e35 100644 --- a/layouts/partials/announcement.html +++ b/layouts/partials/announcement.html @@ -1,7 +1,7 @@ {{ if .Page.Param "announcement" }} <section lang="en" id="announcement" style="background-color:{{ .Page.Param "announcement_bg" }}"> <aside> - <div class="content announcement main-section"> + <div class="content announcement main-section" data-nosnippet> <h4 class="announcement"> {{ T "announcement_title" | markdownify }} diff --git a/layouts/partials/docs/content-page.html b/layouts/partials/docs/content-page.html index 35e9cb8f07..3aaf803f06 100644 --- a/layouts/partials/docs/content-page.html +++ b/layouts/partials/docs/content-page.html @@ -7,6 +7,7 @@ </p> {{ if not .page.Params.notitle }} <h1>{{ .page.Title }}</h1> + {{ $desc := .page.Description }} + {{ with .page.Params.description }}<div class="lead">{{ $desc | markdownify }}</div>{{ end }} {{ end }} - -{{ .page.Content }} \ No newline at end of file +{{ .page.Content }} diff --git a/layouts/partials/docs/docs-portal-card.html b/layouts/partials/docs/docs-portal-card.html index 6dc145072d..c203573e13 100644 --- a/layouts/partials/docs/docs-portal-card.html +++ b/layouts/partials/docs/docs-portal-card.html @@ -19,9 +19,11 @@ {{ end }} {{ end }} </ul> - <br> - <button id="btn-concepts" class="button" onClick="location.href='{{ .button_path | relLangURL }}';" aria-label="{{ .title }}">{{ .button }}</button> - <br> - <br> + {{ if .button }} + <br> + <button id="btn-concepts" class="button" onClick="location.href='{{ .button_path | relLangURL }}';" aria-label="{{ .title }}">{{ .button }}</button> + <br> + <br> + {{ end }} </div> {{ end }} \ No newline at end of file diff --git a/layouts/partials/frontpage-announcement.html b/layouts/partials/frontpage-announcement.html index 0db8e32805..5dce29e035 100644 --- a/layouts/partials/frontpage-announcement.html +++ b/layouts/partials/frontpage-announcement.html @@ -1,7 +1,7 @@ {{ if .Page.Param "announcement" }} <section lang="en" id="fp-announcement" style="background-color:{{ .Page.Param "announcement_bg" }}"> - <main> - <div class="content announcement main-section"> + <aside > + <div class="content announcement main-section" data-nosnippet> <h3> {{ T "announcement_title" | markdownify }} @@ -9,6 +9,6 @@ <p>{{ T "announcement_message" | markdownify }}</p> </div> - </main> + </aside> </section> {{ end }} \ No newline at end of file diff --git a/layouts/partials/git-info.html b/layouts/partials/git-info.html index d37a47dd77..2f01fd8d28 100644 --- a/layouts/partials/git-info.html +++ b/layouts/partials/git-info.html @@ -3,9 +3,11 @@ <hr/> <div class="issue-button-container"> + {{ if eq (getenv "HUGO_ENV") "production" }} <p> <a href=""><img alt="Analytics" src="https://kubernetes-site.appspot.com/UA-36037335-10/GitHub/{{ .Path }}?pixel"/></a> </p> + {{ end }} {{ if and (ne .Kind "404") (not (strings.Contains .Path "search")) }} {{ if not .Params.no_issue }} <script type="text/javascript"> diff --git a/layouts/partials/head.html b/layouts/partials/head.html index 43d1a91c67..47f6e92daf 100644 --- a/layouts/partials/head.html +++ b/layouts/partials/head.html @@ -10,8 +10,12 @@ gtag('config', 'UA-36037335-10'); </script> -<!-- Docsy head.html begins here --> +<!-- alternative translations --> +{{ range .Translations -}} +<link rel="alternate" hreflang="{{ .Language.Lang }}" href="{{ .Permalink }}"> +{{ end -}} +<!-- Docsy head.html begins here --> <meta charset="utf-8"> <meta name="viewport" content="width=device-width, initial-scale=1, shrink-to-fit=no"> {{ hugo.Generator }} @@ -34,7 +38,7 @@ {{ end }} {{ partialCached "head-css.html" . "asdf" }} <script - src="https://code.jquery.com/jquery-3.3.1.min.js" + src="{{ "js/jquery-3.3.1.min.js" | relURL }}" integrity="sha256-FgpCb/KJQlLNfOu91ta32o/NMZxltwRo8QtmkMRdAu8=" crossorigin="anonymous"></script> {{ if and (.Site.Params.offlineSearch) (not .Site.Params.gcs_engine_id) }} @@ -50,7 +54,14 @@ "@context": "https://schema.org", "@type": "Organization", "url": "https://kubernetes.io", - "logo": "https://kubernetes.io/images/favicon.png" + "logo": "https://kubernetes.io/images/favicon.png", +{{- if not .Site.Params.deprecated }} + "potentialAction": { + "@type": "SearchAction", + "target": {{ printf "%s%s" ("/docs/search/" | absURL) "?q={search_term_string}" }}, + "query-input": "required name=search_term_string" + } +{{ end }} } </script> <meta name="theme-color" content="#326ce5"> @@ -74,16 +85,14 @@ <meta property="og:image" content="{{ "/images/kubernetes-horizontal-color.png" | relURL }}"> {{ end }} <meta property="og:type" content="{{ $ogType }}"> -<script src="{{ "js/anchor-4.1.1.min.js" | relURL }}"></script> <script src="{{ "js/jquery-ui-1.12.1.min.js" | relURL }}"></script> <script src="{{ "js/sweetalert-2.1.2.min.js" | relURL }}"></script> -{{ if eq .Params.mermaid true }} +{{ if .HasShortcode "mermaid" }} <!-- Copied from https://unpkg.com/mermaid@8.5.0/dist/mermaid.min.js --> <script async src="{{ "js/mermaid.min.js" | relURL }}"></script> {{ end }} <script src="{{ "js/script.js" | relURL }}"></script> -<script src="{{ "js/custom-jekyll/tags.js" | relURL }}"></script> {{ with .Params.js }}{{ range (split . ",") }}<script src="{{ (trim . " ") | relURL }}"></script><!-- custom js added --> -{{ end }}{{ else }}<!-- no custom js detected -->{{ end }} \ No newline at end of file +{{ end }}{{ else }}<!-- no custom js detected -->{{ end }} diff --git a/layouts/partials/navbar-lang-selector.html b/layouts/partials/navbar-lang-selector.html new file mode 100644 index 0000000000..6f8bfc42f4 --- /dev/null +++ b/layouts/partials/navbar-lang-selector.html @@ -0,0 +1,10 @@ +{{/* Link directly to documentation etc., if possible. */}} +{{ $langPage := cond (gt (len .Translations) 0) . .Site.Home }} +<a class="nav-link dropdown-toggle" href="#" id="navbarDropdownMenuLink" role="button" data-toggle="dropdown" aria-haspopup="true" aria-expanded="false"> + {{ $langPage.Language.LanguageName }} +</a> +<div class="dropdown-menu dropdown-menu-right" aria-labelledby="navbarDropdownMenuLink"> + {{ range $langPage.Translations }} + <a class="dropdown-item" href="{{ .RelPermalink }}">{{ .Language.LanguageName }}</a> + {{ end }} +</div> diff --git a/layouts/partials/navbar-version-selector.html b/layouts/partials/navbar-version-selector.html new file mode 100644 index 0000000000..09e872053f --- /dev/null +++ b/layouts/partials/navbar-version-selector.html @@ -0,0 +1,8 @@ +<a class="nav-link dropdown-toggle" href="#" id="navbarDropdown" role="button" data-toggle="dropdown" aria-haspopup="true" aria-expanded="false"> + {{ T "version_menu" }} +</a> +<div class="dropdown-menu dropdown-menu-right" aria-labelledby="navbarDropdownMenuLink"> + {{ range .Site.Params.versions }} + <a class="dropdown-item" href="{{ .url }}">{{ .version }}</a> + {{ end }} +</div> \ No newline at end of file diff --git a/layouts/partials/search-input.html b/layouts/partials/search-input.html index f6ec2bc000..c41a5052f2 100644 --- a/layouts/partials/search-input.html +++ b/layouts/partials/search-input.html @@ -1,10 +1,30 @@ {{ if or .Site.Params.gcs_engine_id .Site.Params.algolia_docsearch }} - <input type="search" class="form-control td-search-input" placeholder=" {{ T "ui_search" }}" aria-label="{{ T "ui_search" }}" autocomplete="off"> + <input + type="search" + class="form-control td-search-input" + placeholder=" {{ T "ui_search_placeholder" }}" + aria-label="{{ T "ui_search_placeholder" }}" + autocomplete="off" + > {{ else if .Site.Params.offlineSearch }} <div id="search-nav-container"> - <input type="search" id="search-input" autocomplete="off" class="form-control td-search-input" placeholder=" {{ T "ui_search" }}" autocomplete="on"> + <input + type="search" + id="search-input" + autocomplete="off" + class="form-control td-search-input" + placeholder=" {{ T "ui_search_placeholder" }}" + autocomplete="off" + > <div id="search-results" class="container"></div> </div> {{ else if .Site.Params.k8s_search }} - <input type="search" class="form-control td-search-input" name="q" placeholder=" {{ T "ui_search" }}" aria-label="{{ T "ui_search" }}" autocomplete="off"> + <input + type="search" + class="form-control td-search-input" + name="q" + placeholder=" {{ T "ui_search_placeholder" }}" + aria-label="{{ T "ui_search_placeholder" }}" + autocomplete="off" + > {{ end }} \ No newline at end of file diff --git a/layouts/partials/sidebar-tree.html b/layouts/partials/sidebar-tree.html index 4980f7c20c..f8c9832432 100644 --- a/layouts/partials/sidebar-tree.html +++ b/layouts/partials/sidebar-tree.html @@ -8,7 +8,7 @@ </button> </form> {{ end }} - <nav class="collapse td-sidebar-nav pt-2 pl-4" id="td-section-nav"> + <nav class="collapse td-sidebar-nav" id="td-section-nav"> <!-- {{ if (gt (len .Site.Home.Translations) 0) }} <div class="nav-item dropdown d-block d-lg-none"> {{ partial "navbar-lang-selector.html" . }} @@ -37,7 +37,7 @@ <li class="collapse {{ if $show }}show{{ end }}" id="{{ $sid }}"> {{ $pages := where (union $s.Pages $s.Sections).ByWeight ".Params.toc_hide" "!=" true }} {{ with site.Params.language_alternatives }} - {{ range . }} + {{ range . }} {{ with (where $.section.Translations ".Lang" . ) }} {{ $p := index . 0 }} {{ $pages = $pages | lang.Merge (union $p.Pages $p.Sections) }} diff --git a/layouts/shortcodes/announcement.html b/layouts/shortcodes/announcement.html deleted file mode 100644 index 66455dc347..0000000000 --- a/layouts/shortcodes/announcement.html +++ /dev/null @@ -1,14 +0,0 @@ -{{ if .Page.Param "announcement" }} -<link rel="stylesheet" href="{{ "css/announcement.css" | relURL }}"> -<section id="announcement"> - <main> - <div class="content announcement main-section"> - - <h3> - {{ .Page.Param "announcement_message" | markdownify }} - </h3> - - </div> - </main> -</section> -{{ end }} \ No newline at end of file diff --git a/layouts/shortcodes/capture.html b/layouts/shortcodes/capture.html index 6cb2e5a9c9..cc762273c3 100644 --- a/layouts/shortcodes/capture.html +++ b/layouts/shortcodes/capture.html @@ -3,5 +3,6 @@ {{- if not $id -}} {{- errorf "missing id in capture" -}} {{- end -}} -{{- $capture_id := printf "__cid_%s" $id -}} -{{- .Page.Scratch.Set $capture_id .Inner -}} \ No newline at end of file +{{- $capture_id := printf "capture %s" $id -}} +{{- .Page.Scratch.Set $capture_id .Inner -}} +{{ warnf "Invalid shortcode: %s, in %q" $capture_id (relLangURL .Page.Path) }} \ No newline at end of file diff --git a/layouts/shortcodes/deprecationwarning.html b/layouts/shortcodes/deprecationwarning.html deleted file mode 100644 index f26244ed75..0000000000 --- a/layouts/shortcodes/deprecationwarning.html +++ /dev/null @@ -1,13 +0,0 @@ -{{ if .Page.Param "deprecated" }} -<section id="deprecationWarning"> - <main> - <div class="content deprecation-warning"> - <h3> - Kubernetes {{ .Page.Param "version" }} - {{ T "deprecation_warning" }} - <a href="{{ site.Params.currentUrl }}">{{ T "latest_version" }}</a> - </h3> - </div> - </main> -</section> -{{ end }} diff --git a/layouts/shortcodes/glossary_definition.html b/layouts/shortcodes/glossary_definition.html index 2104d1dbc6..76d38fc14b 100644 --- a/layouts/shortcodes/glossary_definition.html +++ b/layouts/shortcodes/glossary_definition.html @@ -4,7 +4,7 @@ {{- $prepend := .Get "prepend" }} {{- $glossaryBundle := site.GetPage "page" "docs/reference/glossary" -}} {{- $glossaryItems := $glossaryBundle.Resources.ByType "page" -}} -{{- $term_info := $glossaryItems.GetMatch (printf "%s*" $id ) -}} +{{- $term_info := $glossaryItems.GetMatch (printf "%s.md" $id ) -}} {{- if not $term_info -}} {{- errorf "[%s] %q: %q is not a valid glossary term_id, see ./docs/reference/glossary/* for a full list" site.Language.Lang .Page.Path $id -}} {{- end -}} diff --git a/layouts/shortcodes/note.html b/layouts/shortcodes/note.html index 1da48797c5..1161c2366c 100644 --- a/layouts/shortcodes/note.html +++ b/layouts/shortcodes/note.html @@ -1,3 +1,3 @@ <blockquote class="note"> - <div><strong>{{ T "note" }}</strong> {{ replaceRE "\\s+|\n" " " .Inner | markdownify }}</div> + <div><strong>{{ T "note" }}</strong> {{ trim .Inner " \n" | markdownify }}</div> </blockquote> \ No newline at end of file diff --git a/layouts/shortcodes/upcoming-events.html b/layouts/shortcodes/upcoming-events.html index d6bbaa8c2a..75d8fde0f9 100644 --- a/layouts/shortcodes/upcoming-events.html +++ b/layouts/shortcodes/upcoming-events.html @@ -2,16 +2,4 @@ {{/* Setting external resource based on whether hugo is running locally or public */}} -{{ if .Site.IsServer }} -{{ $jurl := printf "" $date }} -{{ else }} -{{ $jurl := printf "https://www.googleapis.com/calendar/v3/calendars/nt2tcnbtbied3l6gi2h29slvc0%%40group.calendar.google.com/events?orderBy=startTime&singleEvents=true&%s&key=AIzaSyAST-sCyPJzMQJSl6_vRPW9r4DNLPaDIyM" $date }} -{{ $dataJ := getJSON $jurl }} - -{{ range first 4 $dataJ.items }} - {{ $url := findRE "(http|ftp|https)://([\\w_-]+(?:(?:\\.[\\w_-]+)+))([\\w.,@?^=%&:/~+#-]*[\\w@?^=%&/~+#-])?" .description }} - {{ $url := index $url 0 }} - <div class="event"><a href="{{ safeHTML $url }}">{{ .summary }}</a> - {{ .location }} - {{ .start.date }}</div> -{{ end }} - -{{ end }} +{{/* Disabled as this is breaking website builds */}} diff --git a/netlify.toml b/netlify.toml index e17b26ac21..db0604fad3 100644 --- a/netlify.toml +++ b/netlify.toml @@ -4,11 +4,12 @@ # DO NOT REMOVE THIS (contact @kubernetes/sig-docs-leads) publish = "public" functions = "functions" -command = "git submodule update --init --recursive && make non-production-build" +command = "git submodule update --init --recursive --depth 1 && make non-production-build" [build.environment] -HUGO_VERSION = "0.70.0" +HUGO_VERSION = "0.74.3" NODE_VERSION = "10.20.0" +RUBY_VERSION = "2.7.1" [context.production.environment] HUGO_BASEURL = "https://kubernetes.io/" @@ -16,13 +17,13 @@ HUGO_ENV = "production" HUGO_ENABLEGITINFO = "true" [context.deploy-preview] -command = "git submodule update --init --recursive && make deploy-preview" +command = "git submodule update --init --recursive --depth 1 && make deploy-preview" [context.branch-deploy] -command = "git submodule update --init --recursive && make deploy-preview" +command = "git submodule update --init --recursive --depth 1 && make deploy-preview" [context.master] # This context is triggered by the `master` branch and allows search indexing # DO NOT REMOVE THIS (contact @kubernetes/sig-docs-leads) publish = "public" -command = "git submodule update --init --recursive && make production-build" +command = "git submodule update --init --recursive --depth 1 && make production-build" diff --git a/package-lock.json b/package-lock.json new file mode 100644 index 0000000000..ab0163bc23 --- /dev/null +++ b/package-lock.json @@ -0,0 +1,996 @@ +{ + "requires": true, + "lockfileVersion": 1, + "dependencies": { + "@babel/runtime-corejs3": { + "version": "7.10.4", + "resolved": "https://registry.npmjs.org/@babel/runtime-corejs3/-/runtime-corejs3-7.10.4.tgz", + "integrity": "sha512-BFlgP2SoLO9HJX9WBwN67gHWMBhDX/eDz64Jajd6mR/UAUzqrNMm99d4qHnVaKscAElZoFiPv+JpR/Siud5lXw==", + "dev": true, + "requires": { + "core-js-pure": "^3.0.0", + "regenerator-runtime": "^0.13.4" + } + }, + "@nodelib/fs.scandir": { + "version": "2.1.3", + "resolved": "https://registry.npmjs.org/@nodelib/fs.scandir/-/fs.scandir-2.1.3.tgz", + "integrity": "sha512-eGmwYQn3gxo4r7jdQnkrrN6bY478C3P+a/y72IJukF8LjB6ZHeB3c+Ehacj3sYeSmUXGlnA67/PmbM9CVwL7Dw==", + "dev": true, + "requires": { + "@nodelib/fs.stat": "2.0.3", + "run-parallel": "^1.1.9" + } + }, + "@nodelib/fs.stat": { + "version": "2.0.3", + "resolved": "https://registry.npmjs.org/@nodelib/fs.stat/-/fs.stat-2.0.3.tgz", + "integrity": "sha512-bQBFruR2TAwoevBEd/NWMoAAtNGzTRgdrqnYCc7dhzfoNvqPzLyqlEQnzZ3kVnNrSp25iyxE00/3h2fqGAGArA==", + "dev": true + }, + "@nodelib/fs.walk": { + "version": "1.2.4", + "resolved": "https://registry.npmjs.org/@nodelib/fs.walk/-/fs.walk-1.2.4.tgz", + "integrity": "sha512-1V9XOY4rDW0rehzbrcqAmHnz8e7SKvX27gh8Gt2WgB0+pdzdiLV83p72kZPU+jvMbS1qU5mauP2iOvO8rhmurQ==", + "dev": true, + "requires": { + "@nodelib/fs.scandir": "2.1.3", + "fastq": "^1.6.0" + } + }, + "@types/color-name": { + "version": "1.1.1", + "resolved": "https://registry.npmjs.org/@types/color-name/-/color-name-1.1.1.tgz", + "integrity": "sha512-rr+OQyAjxze7GgWrSaJwydHStIhHq2lvY3BOC2Mj7KnzI7XK0Uw1TOOdI9lDoajEbSWLiYgoo4f1R51erQfhPQ==", + "dev": true + }, + "ansi-regex": { + "version": "5.0.0", + "resolved": "https://registry.npmjs.org/ansi-regex/-/ansi-regex-5.0.0.tgz", + "integrity": "sha512-bY6fj56OUQ0hU1KjFNDQuJFezqKdrAyFdIevADiqrWHwSlbmBNMHp5ak2f40Pm8JTFyM2mqxkG6ngkHO11f/lg==", + "dev": true + }, + "ansi-styles": { + "version": "3.2.1", + "resolved": "https://registry.npmjs.org/ansi-styles/-/ansi-styles-3.2.1.tgz", + "integrity": "sha512-VT0ZI6kZRdTh8YyJw3SMbYm/u+NqfsAxEpWO0Pf9sq8/e94WxxOpPKx9FR1FlyCtOVDNOQ+8ntlqFxiRc+r5qA==", + "dev": true, + "requires": { + "color-convert": "^1.9.0" + } + }, + "anymatch": { + "version": "3.1.1", + "resolved": "https://registry.npmjs.org/anymatch/-/anymatch-3.1.1.tgz", + "integrity": "sha512-mM8522psRCqzV+6LhomX5wgp25YVibjh8Wj23I5RPkPppSVSjyKD2A2mBJmWGa+KN7f2D6LNh9jkBCeyLktzjg==", + "dev": true, + "requires": { + "normalize-path": "^3.0.0", + "picomatch": "^2.0.4" + } + }, + "argparse": { + "version": "1.0.10", + "resolved": "https://registry.npmjs.org/argparse/-/argparse-1.0.10.tgz", + "integrity": "sha512-o5Roy6tNG4SL/FOkCAN6RzjiakZS25RLYFrcMttJqbdd8BWrnA+fGz57iN5Pb06pvBGvl5gQ0B48dJlslXvoTg==", + "dev": true, + "requires": { + "sprintf-js": "~1.0.2" + } + }, + "array-union": { + "version": "2.1.0", + "resolved": "https://registry.npmjs.org/array-union/-/array-union-2.1.0.tgz", + "integrity": "sha512-HGyxoOTYUyCM6stUe6EJgnd4EoewAI7zMdfqO+kGjnlZmBDz/cR5pf8r/cR4Wq60sL/p0IkcjUEEPwS3GFrIyw==", + "dev": true + }, + "at-least-node": { + "version": "1.0.0", + "resolved": "https://registry.npmjs.org/at-least-node/-/at-least-node-1.0.0.tgz", + "integrity": "sha512-+q/t7Ekv1EDY2l6Gda6LLiX14rU9TV20Wa3ofeQmwPFZbOMo9DXrLbOjFaaclkXKWidIaopwAObQDqwWtGUjqg==", + "dev": true + }, + "autoprefixer": { + "version": "9.8.4", + "resolved": "https://registry.npmjs.org/autoprefixer/-/autoprefixer-9.8.4.tgz", + "integrity": "sha512-84aYfXlpUe45lvmS+HoAWKCkirI/sw4JK0/bTeeqgHYco3dcsOn0NqdejISjptsYwNji/21dnkDri9PsYKk89A==", + "dev": true, + "requires": { + "browserslist": "^4.12.0", + "caniuse-lite": "^1.0.30001087", + "colorette": "^1.2.0", + "normalize-range": "^0.1.2", + "num2fraction": "^1.2.2", + "postcss": "^7.0.32", + "postcss-value-parser": "^4.1.0" + } + }, + "binary-extensions": { + "version": "2.1.0", + "resolved": "https://registry.npmjs.org/binary-extensions/-/binary-extensions-2.1.0.tgz", + "integrity": "sha512-1Yj8h9Q+QDF5FzhMs/c9+6UntbD5MkRfRwac8DoEm9ZfUBZ7tZ55YcGVAzEe4bXsdQHEk+s9S5wsOKVdZrw0tQ==", + "dev": true + }, + "braces": { + "version": "3.0.2", + "resolved": "https://registry.npmjs.org/braces/-/braces-3.0.2.tgz", + "integrity": "sha512-b8um+L1RzM3WDSzvhm6gIz1yfTbBt6YTlcEKAvsmqCZZFw46z626lVj9j1yEPW33H5H+lBQpZMP1k8l+78Ha0A==", + "dev": true, + "requires": { + "fill-range": "^7.0.1" + } + }, + "browserslist": { + "version": "4.12.2", + "resolved": "https://registry.npmjs.org/browserslist/-/browserslist-4.12.2.tgz", + "integrity": "sha512-MfZaeYqR8StRZdstAK9hCKDd2StvePCYp5rHzQCPicUjfFliDgmuaBNPHYUTpAywBN8+Wc/d7NYVFkO0aqaBUw==", + "dev": true, + "requires": { + "caniuse-lite": "^1.0.30001088", + "electron-to-chromium": "^1.3.483", + "escalade": "^3.0.1", + "node-releases": "^1.1.58" + } + }, + "caller-callsite": { + "version": "2.0.0", + "resolved": "https://registry.npmjs.org/caller-callsite/-/caller-callsite-2.0.0.tgz", + "integrity": "sha1-hH4PzgoiN1CpoCfFSzNzGtMVQTQ=", + "dev": true, + "requires": { + "callsites": "^2.0.0" + } + }, + "caller-path": { + "version": "2.0.0", + "resolved": "https://registry.npmjs.org/caller-path/-/caller-path-2.0.0.tgz", + "integrity": "sha1-Ro+DBE42mrIBD6xfBs7uFbsssfQ=", + "dev": true, + "requires": { + "caller-callsite": "^2.0.0" + } + }, + "callsites": { + "version": "2.0.0", + "resolved": "https://registry.npmjs.org/callsites/-/callsites-2.0.0.tgz", + "integrity": "sha1-BuuE8A7qQT2oav/vrL/7Ngk7PFA=", + "dev": true + }, + "camelcase": { + "version": "5.3.1", + "resolved": "https://registry.npmjs.org/camelcase/-/camelcase-5.3.1.tgz", + "integrity": "sha512-L28STB170nwWS63UjtlEOE3dldQApaJXZkOI1uMFfzf3rRuPegHaHesyee+YxQ+W6SvRDQV6UrdOdRiR153wJg==", + "dev": true + }, + "caniuse-lite": { + "version": "1.0.30001093", + "resolved": "https://registry.npmjs.org/caniuse-lite/-/caniuse-lite-1.0.30001093.tgz", + "integrity": "sha512-0+ODNoOjtWD5eS9aaIpf4K0gQqZfILNY4WSNuYzeT1sXni+lMrrVjc0odEobJt6wrODofDZUX8XYi/5y7+xl8g==", + "dev": true + }, + "chalk": { + "version": "2.4.2", + "resolved": "https://registry.npmjs.org/chalk/-/chalk-2.4.2.tgz", + "integrity": "sha512-Mti+f9lpJNcwF4tWV8/OrTTtF1gZi+f8FqlyAdouralcFWFQWF2+NgCHShjkCb+IFBLq9buZwE1xckQU4peSuQ==", + "dev": true, + "requires": { + "ansi-styles": "^3.2.1", + "escape-string-regexp": "^1.0.5", + "supports-color": "^5.3.0" + }, + "dependencies": { + "supports-color": { + "version": "5.5.0", + "resolved": "https://registry.npmjs.org/supports-color/-/supports-color-5.5.0.tgz", + "integrity": "sha512-QjVjwdXIt408MIiAqCX4oUKsgU2EqAGzs2Ppkm4aQYbjm+ZEWEcW4SfFNTr4uMNZma0ey4f5lgLrkB0aX0QMow==", + "dev": true, + "requires": { + "has-flag": "^3.0.0" + } + } + } + }, + "chokidar": { + "version": "3.4.0", + "resolved": "https://registry.npmjs.org/chokidar/-/chokidar-3.4.0.tgz", + "integrity": "sha512-aXAaho2VJtisB/1fg1+3nlLJqGOuewTzQpd/Tz0yTg2R0e4IGtshYvtjowyEumcBv2z+y4+kc75Mz7j5xJskcQ==", + "dev": true, + "requires": { + "anymatch": "~3.1.1", + "braces": "~3.0.2", + "fsevents": "~2.1.2", + "glob-parent": "~5.1.0", + "is-binary-path": "~2.1.0", + "is-glob": "~4.0.1", + "normalize-path": "~3.0.0", + "readdirp": "~3.4.0" + } + }, + "cliui": { + "version": "6.0.0", + "resolved": "https://registry.npmjs.org/cliui/-/cliui-6.0.0.tgz", + "integrity": "sha512-t6wbgtoCXvAzst7QgXxJYqPt0usEfbgQdftEPbLL/cvv6HPE5VgvqCuAIDR0NgU52ds6rFwqrgakNLrHEjCbrQ==", + "dev": true, + "requires": { + "string-width": "^4.2.0", + "strip-ansi": "^6.0.0", + "wrap-ansi": "^6.2.0" + } + }, + "color-convert": { + "version": "1.9.3", + "resolved": "https://registry.npmjs.org/color-convert/-/color-convert-1.9.3.tgz", + "integrity": "sha512-QfAUtd+vFdAtFQcC8CCyYt1fYWxSqAiK2cSD6zDB8N3cpsEBAvRxp9zOGg6G/SHHJYAT88/az/IuDGALsNVbGg==", + "dev": true, + "requires": { + "color-name": "1.1.3" + } + }, + "color-name": { + "version": "1.1.3", + "resolved": "https://registry.npmjs.org/color-name/-/color-name-1.1.3.tgz", + "integrity": "sha1-p9BVi9icQveV3UIyj3QIMcpTvCU=", + "dev": true + }, + "colorette": { + "version": "1.2.0", + "resolved": "https://registry.npmjs.org/colorette/-/colorette-1.2.0.tgz", + "integrity": "sha512-soRSroY+OF/8OdA3PTQXwaDJeMc7TfknKKrxeSCencL2a4+Tx5zhxmmv7hdpCjhKBjehzp8+bwe/T68K0hpIjw==", + "dev": true + }, + "core-js-pure": { + "version": "3.6.5", + "resolved": "https://registry.npmjs.org/core-js-pure/-/core-js-pure-3.6.5.tgz", + "integrity": "sha512-lacdXOimsiD0QyNf9BC/mxivNJ/ybBGJXQFKzRekp1WTHoVUWsUHEn+2T8GJAzzIhyOuXA+gOxCVN3l+5PLPUA==", + "dev": true + }, + "cosmiconfig": { + "version": "5.2.1", + "resolved": "https://registry.npmjs.org/cosmiconfig/-/cosmiconfig-5.2.1.tgz", + "integrity": "sha512-H65gsXo1SKjf8zmrJ67eJk8aIRKV5ff2D4uKZIBZShbhGSpEmsQOPW/SKMKYhSTrqR7ufy6RP69rPogdaPh/kA==", + "dev": true, + "requires": { + "import-fresh": "^2.0.0", + "is-directory": "^0.3.1", + "js-yaml": "^3.13.1", + "parse-json": "^4.0.0" + } + }, + "decamelize": { + "version": "3.2.0", + "resolved": "https://registry.npmjs.org/decamelize/-/decamelize-3.2.0.tgz", + "integrity": "sha512-4TgkVUsmmu7oCSyGBm5FvfMoACuoh9EOidm7V5/J2X2djAwwt57qb3F2KMP2ITqODTCSwb+YRV+0Zqrv18k/hw==", + "dev": true, + "requires": { + "xregexp": "^4.2.4" + } + }, + "dependency-graph": { + "version": "0.9.0", + "resolved": "https://registry.npmjs.org/dependency-graph/-/dependency-graph-0.9.0.tgz", + "integrity": "sha512-9YLIBURXj4DJMFALxXw9K3Y3rwb5Fk0X5/8ipCzaN84+gKxoHK43tVKRNakCQbiEx07E8Uwhuq21BpUagFhZ8w==", + "dev": true + }, + "dir-glob": { + "version": "3.0.1", + "resolved": "https://registry.npmjs.org/dir-glob/-/dir-glob-3.0.1.tgz", + "integrity": "sha512-WkrWp9GR4KXfKGYzOLmTuGVi1UWFfws377n9cc55/tb6DuqyF6pcQ5AbiHEshaDpY9v6oaSr2XCDidGmMwdzIA==", + "dev": true, + "requires": { + "path-type": "^4.0.0" + } + }, + "electron-to-chromium": { + "version": "1.3.487", + "resolved": "https://registry.npmjs.org/electron-to-chromium/-/electron-to-chromium-1.3.487.tgz", + "integrity": "sha512-m4QS3IDShxauFfYFpnEzRCcUI55oKB9acEnHCuY/hSCZMz9Pz2KJj+UBnGHxRxS/mS1aphqOQ5wI6gc3yDZ7ew==", + "dev": true + }, + "emoji-regex": { + "version": "8.0.0", + "resolved": "https://registry.npmjs.org/emoji-regex/-/emoji-regex-8.0.0.tgz", + "integrity": "sha512-MSjYzcWNOA0ewAHpz0MxpYFvwg6yjy1NG3xteoqz644VCo/RPgnr1/GGt+ic3iJTzQ8Eu3TdM14SawnVUmGE6A==", + "dev": true + }, + "error-ex": { + "version": "1.3.2", + "resolved": "https://registry.npmjs.org/error-ex/-/error-ex-1.3.2.tgz", + "integrity": "sha512-7dFHNmqeFSEt2ZBsCriorKnn3Z2pj+fd9kmI6QoWw4//DL+icEBfc0U7qJCisqrTsKTjw4fNFy2pW9OqStD84g==", + "dev": true, + "requires": { + "is-arrayish": "^0.2.1" + } + }, + "escalade": { + "version": "3.0.1", + "resolved": "https://registry.npmjs.org/escalade/-/escalade-3.0.1.tgz", + "integrity": "sha512-DR6NO3h9niOT+MZs7bjxlj2a1k+POu5RN8CLTPX2+i78bRi9eLe7+0zXgUHMnGXWybYcL61E9hGhPKqedy8tQA==", + "dev": true + }, + "escape-string-regexp": { + "version": "1.0.5", + "resolved": "https://registry.npmjs.org/escape-string-regexp/-/escape-string-regexp-1.0.5.tgz", + "integrity": "sha1-G2HAViGQqN/2rjuyzwIAyhMLhtQ=", + "dev": true + }, + "esprima": { + "version": "4.0.1", + "resolved": "https://registry.npmjs.org/esprima/-/esprima-4.0.1.tgz", + "integrity": "sha512-eGuFFw7Upda+g4p+QHvnW0RyTX/SVeJBDM/gCtMARO0cLuT2HcEKnTPvhjV6aGeqrCB/sbNop0Kszm0jsaWU4A==", + "dev": true + }, + "fast-glob": { + "version": "3.2.4", + "resolved": "https://registry.npmjs.org/fast-glob/-/fast-glob-3.2.4.tgz", + "integrity": "sha512-kr/Oo6PX51265qeuCYsyGypiO5uJFgBS0jksyG7FUeCyQzNwYnzrNIMR1NXfkZXsMYXYLRAHgISHBz8gQcxKHQ==", + "dev": true, + "requires": { + "@nodelib/fs.stat": "^2.0.2", + "@nodelib/fs.walk": "^1.2.3", + "glob-parent": "^5.1.0", + "merge2": "^1.3.0", + "micromatch": "^4.0.2", + "picomatch": "^2.2.1" + } + }, + "fastq": { + "version": "1.8.0", + "resolved": "https://registry.npmjs.org/fastq/-/fastq-1.8.0.tgz", + "integrity": "sha512-SMIZoZdLh/fgofivvIkmknUXyPnvxRE3DhtZ5Me3Mrsk5gyPL42F0xr51TdRXskBxHfMp+07bcYzfsYEsSQA9Q==", + "dev": true, + "requires": { + "reusify": "^1.0.4" + } + }, + "fill-range": { + "version": "7.0.1", + "resolved": "https://registry.npmjs.org/fill-range/-/fill-range-7.0.1.tgz", + "integrity": "sha512-qOo9F+dMUmC2Lcb4BbVvnKJxTPjCm+RRpe4gDuGrzkL7mEVl/djYSu2OdQ2Pa302N4oqkSg9ir6jaLWJ2USVpQ==", + "dev": true, + "requires": { + "to-regex-range": "^5.0.1" + } + }, + "find-up": { + "version": "4.1.0", + "resolved": "https://registry.npmjs.org/find-up/-/find-up-4.1.0.tgz", + "integrity": "sha512-PpOwAdQ/YlXQ2vj8a3h8IipDuYRi3wceVQQGYWxNINccq40Anw7BlsEXCMbt1Zt+OLA6Fq9suIpIWD0OsnISlw==", + "dev": true, + "requires": { + "locate-path": "^5.0.0", + "path-exists": "^4.0.0" + } + }, + "fs-extra": { + "version": "9.0.1", + "resolved": "https://registry.npmjs.org/fs-extra/-/fs-extra-9.0.1.tgz", + "integrity": "sha512-h2iAoN838FqAFJY2/qVpzFXy+EBxfVE220PalAqQLDVsFOHLJrZvut5puAbCdNv6WJk+B8ihI+k0c7JK5erwqQ==", + "dev": true, + "requires": { + "at-least-node": "^1.0.0", + "graceful-fs": "^4.2.0", + "jsonfile": "^6.0.1", + "universalify": "^1.0.0" + } + }, + "fsevents": { + "version": "2.1.3", + "resolved": "https://registry.npmjs.org/fsevents/-/fsevents-2.1.3.tgz", + "integrity": "sha512-Auw9a4AxqWpa9GUfj370BMPzzyncfBABW8Mab7BGWBYDj4Isgq+cDKtx0i6u9jcX9pQDnswsaaOTgTmA5pEjuQ==", + "dev": true, + "optional": true + }, + "get-caller-file": { + "version": "2.0.5", + "resolved": "https://registry.npmjs.org/get-caller-file/-/get-caller-file-2.0.5.tgz", + "integrity": "sha512-DyFP3BM/3YHTQOCUL/w0OZHR0lpKeGrxotcHWcqNEdnltqFwXVfhEBQ94eIo34AfQpo0rGki4cyIiftY06h2Fg==", + "dev": true + }, + "get-stdin": { + "version": "7.0.0", + "resolved": "https://registry.npmjs.org/get-stdin/-/get-stdin-7.0.0.tgz", + "integrity": "sha512-zRKcywvrXlXsA0v0i9Io4KDRaAw7+a1ZpjRwl9Wox8PFlVCCHra7E9c4kqXCoCM9nR5tBkaTTZRBoCm60bFqTQ==", + "dev": true + }, + "glob-parent": { + "version": "5.1.1", + "resolved": "https://registry.npmjs.org/glob-parent/-/glob-parent-5.1.1.tgz", + "integrity": "sha512-FnI+VGOpnlGHWZxthPGR+QhR78fuiK0sNLkHQv+bL9fQi57lNNdquIbna/WrfROrolq8GK5Ek6BiMwqL/voRYQ==", + "dev": true, + "requires": { + "is-glob": "^4.0.1" + } + }, + "globby": { + "version": "11.0.1", + "resolved": "https://registry.npmjs.org/globby/-/globby-11.0.1.tgz", + "integrity": "sha512-iH9RmgwCmUJHi2z5o2l3eTtGBtXek1OYlHrbcxOYugyHLmAsZrPj43OtHThd62Buh/Vv6VyCBD2bdyWcGNQqoQ==", + "dev": true, + "requires": { + "array-union": "^2.1.0", + "dir-glob": "^3.0.1", + "fast-glob": "^3.1.1", + "ignore": "^5.1.4", + "merge2": "^1.3.0", + "slash": "^3.0.0" + } + }, + "graceful-fs": { + "version": "4.2.4", + "resolved": "https://registry.npmjs.org/graceful-fs/-/graceful-fs-4.2.4.tgz", + "integrity": "sha512-WjKPNJF79dtJAVniUlGGWHYGz2jWxT6VhN/4m1NdkbZ2nOsEF+cI1Edgql5zCRhs/VsQYRvrXctxktVXZUkixw==", + "dev": true + }, + "has-flag": { + "version": "3.0.0", + "resolved": "https://registry.npmjs.org/has-flag/-/has-flag-3.0.0.tgz", + "integrity": "sha1-tdRU3CGZriJWmfNGfloH87lVuv0=", + "dev": true + }, + "ignore": { + "version": "5.1.8", + "resolved": "https://registry.npmjs.org/ignore/-/ignore-5.1.8.tgz", + "integrity": "sha512-BMpfD7PpiETpBl/A6S498BaIJ6Y/ABT93ETbby2fP00v4EbvPBXWEoaR1UBPKs3iR53pJY7EtZk5KACI57i1Uw==", + "dev": true + }, + "import-cwd": { + "version": "2.1.0", + "resolved": "https://registry.npmjs.org/import-cwd/-/import-cwd-2.1.0.tgz", + "integrity": "sha1-qmzzbnInYShcs3HsZRn1PiQ1sKk=", + "dev": true, + "requires": { + "import-from": "^2.1.0" + } + }, + "import-fresh": { + "version": "2.0.0", + "resolved": "https://registry.npmjs.org/import-fresh/-/import-fresh-2.0.0.tgz", + "integrity": "sha1-2BNVwVYS04bGH53dOSLUMEgipUY=", + "dev": true, + "requires": { + "caller-path": "^2.0.0", + "resolve-from": "^3.0.0" + } + }, + "import-from": { + "version": "2.1.0", + "resolved": "https://registry.npmjs.org/import-from/-/import-from-2.1.0.tgz", + "integrity": "sha1-M1238qev/VOqpHHUuAId7ja387E=", + "dev": true, + "requires": { + "resolve-from": "^3.0.0" + } + }, + "is-arrayish": { + "version": "0.2.1", + "resolved": "https://registry.npmjs.org/is-arrayish/-/is-arrayish-0.2.1.tgz", + "integrity": "sha1-d8mYQFJ6qOyxqLppe4BkWnqSap0=", + "dev": true + }, + "is-binary-path": { + "version": "2.1.0", + "resolved": "https://registry.npmjs.org/is-binary-path/-/is-binary-path-2.1.0.tgz", + "integrity": "sha512-ZMERYes6pDydyuGidse7OsHxtbI7WVeUEozgR/g7rd0xUimYNlvZRE/K2MgZTjWy725IfelLeVcEM97mmtRGXw==", + "dev": true, + "requires": { + "binary-extensions": "^2.0.0" + } + }, + "is-directory": { + "version": "0.3.1", + "resolved": "https://registry.npmjs.org/is-directory/-/is-directory-0.3.1.tgz", + "integrity": "sha1-YTObbyR1/Hcv2cnYP1yFddwVSuE=", + "dev": true + }, + "is-extglob": { + "version": "2.1.1", + "resolved": "https://registry.npmjs.org/is-extglob/-/is-extglob-2.1.1.tgz", + "integrity": "sha1-qIwCU1eR8C7TfHahueqXc8gz+MI=", + "dev": true + }, + "is-fullwidth-code-point": { + "version": "3.0.0", + "resolved": "https://registry.npmjs.org/is-fullwidth-code-point/-/is-fullwidth-code-point-3.0.0.tgz", + "integrity": "sha512-zymm5+u+sCsSWyD9qNaejV3DFvhCKclKdizYaJUuHA83RLjb7nSuGnddCHGv0hk+KY7BMAlsWeK4Ueg6EV6XQg==", + "dev": true + }, + "is-glob": { + "version": "4.0.1", + "resolved": "https://registry.npmjs.org/is-glob/-/is-glob-4.0.1.tgz", + "integrity": "sha512-5G0tKtBTFImOqDnLB2hG6Bp2qcKEFduo4tZu9MT/H6NQv/ghhy30o55ufafxJ/LdH79LLs2Kfrn85TLKyA7BUg==", + "dev": true, + "requires": { + "is-extglob": "^2.1.1" + } + }, + "is-number": { + "version": "7.0.0", + "resolved": "https://registry.npmjs.org/is-number/-/is-number-7.0.0.tgz", + "integrity": "sha512-41Cifkg6e8TylSpdtTpeLVMqvSBEVzTttHvERD741+pnZ8ANv0004MRL43QKPDlK9cGvNp6NZWZUBlbGXYxxng==", + "dev": true + }, + "js-yaml": { + "version": "3.14.0", + "resolved": "https://registry.npmjs.org/js-yaml/-/js-yaml-3.14.0.tgz", + "integrity": "sha512-/4IbIeHcD9VMHFqDR/gQ7EdZdLimOvW2DdcxFjdyyZ9NsbS+ccrXqVWDtab/lRl5AlUqmpBx8EhPaWR+OtY17A==", + "dev": true, + "requires": { + "argparse": "^1.0.7", + "esprima": "^4.0.0" + } + }, + "json-parse-better-errors": { + "version": "1.0.2", + "resolved": "https://registry.npmjs.org/json-parse-better-errors/-/json-parse-better-errors-1.0.2.tgz", + "integrity": "sha512-mrqyZKfX5EhL7hvqcV6WG1yYjnjeuYDzDhhcAAUrq8Po85NBQBJP+ZDUT75qZQ98IkUoBqdkExkukOU7Ts2wrw==", + "dev": true + }, + "jsonfile": { + "version": "6.0.1", + "resolved": "https://registry.npmjs.org/jsonfile/-/jsonfile-6.0.1.tgz", + "integrity": "sha512-jR2b5v7d2vIOust+w3wtFKZIfpC2pnRmFAhAC/BuweZFQR8qZzxH1OyrQ10HmdVYiXWkYUqPVsz91cG7EL2FBg==", + "dev": true, + "requires": { + "graceful-fs": "^4.1.6", + "universalify": "^1.0.0" + } + }, + "locate-path": { + "version": "5.0.0", + "resolved": "https://registry.npmjs.org/locate-path/-/locate-path-5.0.0.tgz", + "integrity": "sha512-t7hw9pI+WvuwNJXwk5zVHpyhIqzg2qTlklJOf0mVxGSbe3Fp2VieZcduNYjaLDoy6p9uGpQEGWG87WpMKlNq8g==", + "dev": true, + "requires": { + "p-locate": "^4.1.0" + } + }, + "lodash": { + "version": "4.17.15", + "resolved": "https://registry.npmjs.org/lodash/-/lodash-4.17.15.tgz", + "integrity": "sha512-8xOcRHvCjnocdS5cpwXQXVzmmh5e5+saE2QGoeQmbKmRS6J3VQppPOIt0MnmE+4xlZoumy0GPG0D0MVIQbNA1A==", + "dev": true + }, + "log-symbols": { + "version": "2.2.0", + "resolved": "https://registry.npmjs.org/log-symbols/-/log-symbols-2.2.0.tgz", + "integrity": "sha512-VeIAFslyIerEJLXHziedo2basKbMKtTw3vfn5IzG0XTjhAVEJyNHnL2p7vc+wBDSdQuUpNw3M2u6xb9QsAY5Eg==", + "dev": true, + "requires": { + "chalk": "^2.0.1" + } + }, + "merge2": { + "version": "1.4.1", + "resolved": "https://registry.npmjs.org/merge2/-/merge2-1.4.1.tgz", + "integrity": "sha512-8q7VEgMJW4J8tcfVPy8g09NcQwZdbwFEqhe/WZkoIzjn/3TGDwtOCYtXGxA3O8tPzpczCCDgv+P2P5y00ZJOOg==", + "dev": true + }, + "micromatch": { + "version": "4.0.2", + "resolved": "https://registry.npmjs.org/micromatch/-/micromatch-4.0.2.tgz", + "integrity": "sha512-y7FpHSbMUMoyPbYUSzO6PaZ6FyRnQOpHuKwbo1G+Knck95XVU4QAiKdGEnj5wwoS7PlOgthX/09u5iFJ+aYf5Q==", + "dev": true, + "requires": { + "braces": "^3.0.1", + "picomatch": "^2.0.5" + } + }, + "node-releases": { + "version": "1.1.58", + "resolved": "https://registry.npmjs.org/node-releases/-/node-releases-1.1.58.tgz", + "integrity": "sha512-NxBudgVKiRh/2aPWMgPR7bPTX0VPmGx5QBwCtdHitnqFE5/O8DeBXuIMH1nwNnw/aMo6AjOrpsHzfY3UbUJ7yg==", + "dev": true + }, + "normalize-path": { + "version": "3.0.0", + "resolved": "https://registry.npmjs.org/normalize-path/-/normalize-path-3.0.0.tgz", + "integrity": "sha512-6eZs5Ls3WtCisHWp9S2GUy8dqkpGi4BVSz3GaqiE6ezub0512ESztXUwUB6C6IKbQkY2Pnb/mD4WYojCRwcwLA==", + "dev": true + }, + "normalize-range": { + "version": "0.1.2", + "resolved": "https://registry.npmjs.org/normalize-range/-/normalize-range-0.1.2.tgz", + "integrity": "sha1-LRDAa9/TEuqXd2laTShDlFa3WUI=", + "dev": true + }, + "num2fraction": { + "version": "1.2.2", + "resolved": "https://registry.npmjs.org/num2fraction/-/num2fraction-1.2.2.tgz", + "integrity": "sha1-b2gragJ6Tp3fpFZM0lidHU5mnt4=", + "dev": true + }, + "p-limit": { + "version": "2.3.0", + "resolved": "https://registry.npmjs.org/p-limit/-/p-limit-2.3.0.tgz", + "integrity": "sha512-//88mFWSJx8lxCzwdAABTJL2MyWB12+eIY7MDL2SqLmAkeKU9qxRvWuSyTjm3FUmpBEMuFfckAIqEaVGUDxb6w==", + "dev": true, + "requires": { + "p-try": "^2.0.0" + } + }, + "p-locate": { + "version": "4.1.0", + "resolved": "https://registry.npmjs.org/p-locate/-/p-locate-4.1.0.tgz", + "integrity": "sha512-R79ZZ/0wAxKGu3oYMlz8jy/kbhsNrS7SKZ7PxEHBgJ5+F2mtFW2fK2cOtBh1cHYkQsbzFV7I+EoRKe6Yt0oK7A==", + "dev": true, + "requires": { + "p-limit": "^2.2.0" + } + }, + "p-try": { + "version": "2.2.0", + "resolved": "https://registry.npmjs.org/p-try/-/p-try-2.2.0.tgz", + "integrity": "sha512-R4nPAVTAU0B9D35/Gk3uJf/7XYbQcyohSKdvAxIRSNghFl4e71hVoGnBNQz9cWaXxO2I10KTC+3jMdvvoKw6dQ==", + "dev": true + }, + "parse-json": { + "version": "4.0.0", + "resolved": "https://registry.npmjs.org/parse-json/-/parse-json-4.0.0.tgz", + "integrity": "sha1-vjX1Qlvh9/bHRxhPmKeIy5lHfuA=", + "dev": true, + "requires": { + "error-ex": "^1.3.1", + "json-parse-better-errors": "^1.0.1" + } + }, + "path-exists": { + "version": "4.0.0", + "resolved": "https://registry.npmjs.org/path-exists/-/path-exists-4.0.0.tgz", + "integrity": "sha512-ak9Qy5Q7jYb2Wwcey5Fpvg2KoAc/ZIhLSLOSBmRmygPsGwkVVt0fZa0qrtMz+m6tJTAHfZQ8FnmB4MG4LWy7/w==", + "dev": true + }, + "path-type": { + "version": "4.0.0", + "resolved": "https://registry.npmjs.org/path-type/-/path-type-4.0.0.tgz", + "integrity": "sha512-gDKb8aZMDeD/tZWs9P6+q0J9Mwkdl6xMV8TjnGP3qJVJ06bdMgkbBlLU8IdfOsIsFz2BW1rNVT3XuNEl8zPAvw==", + "dev": true + }, + "picomatch": { + "version": "2.2.2", + "resolved": "https://registry.npmjs.org/picomatch/-/picomatch-2.2.2.tgz", + "integrity": "sha512-q0M/9eZHzmr0AulXyPwNfZjtwZ/RBZlbN3K3CErVrk50T2ASYI7Bye0EvekFY3IP1Nt2DHu0re+V2ZHIpMkuWg==", + "dev": true + }, + "pify": { + "version": "2.3.0", + "resolved": "https://registry.npmjs.org/pify/-/pify-2.3.0.tgz", + "integrity": "sha1-7RQaasBDqEnqWISY59yosVMw6Qw=", + "dev": true + }, + "postcss": { + "version": "7.0.32", + "resolved": "https://registry.npmjs.org/postcss/-/postcss-7.0.32.tgz", + "integrity": "sha512-03eXong5NLnNCD05xscnGKGDZ98CyzoqPSMjOe6SuoQY7Z2hIj0Ld1g/O/UQRuOle2aRtiIRDg9tDcTGAkLfKw==", + "dev": true, + "requires": { + "chalk": "^2.4.2", + "source-map": "^0.6.1", + "supports-color": "^6.1.0" + } + }, + "postcss-cli": { + "version": "7.1.1", + "resolved": "https://registry.npmjs.org/postcss-cli/-/postcss-cli-7.1.1.tgz", + "integrity": "sha512-bYQy5ydAQJKCMSpvaMg0ThPBeGYqhQXumjbFOmWnL4u65CYXQ16RfS6afGQpit0dGv/fNzxbdDtx8dkqOhhIbg==", + "dev": true, + "requires": { + "chalk": "^4.0.0", + "chokidar": "^3.3.0", + "dependency-graph": "^0.9.0", + "fs-extra": "^9.0.0", + "get-stdin": "^7.0.0", + "globby": "^11.0.0", + "postcss": "^7.0.0", + "postcss-load-config": "^2.0.0", + "postcss-reporter": "^6.0.0", + "pretty-hrtime": "^1.0.3", + "read-cache": "^1.0.0", + "yargs": "^15.0.2" + }, + "dependencies": { + "ansi-styles": { + "version": "4.2.1", + "resolved": "https://registry.npmjs.org/ansi-styles/-/ansi-styles-4.2.1.tgz", + "integrity": "sha512-9VGjrMsG1vePxcSweQsN20KY/c4zN0h9fLjqAbwbPfahM3t+NL+M9HC8xeXG2I8pX5NoamTGNuomEUFI7fcUjA==", + "dev": true, + "requires": { + "@types/color-name": "^1.1.1", + "color-convert": "^2.0.1" + } + }, + "chalk": { + "version": "4.1.0", + "resolved": "https://registry.npmjs.org/chalk/-/chalk-4.1.0.tgz", + "integrity": "sha512-qwx12AxXe2Q5xQ43Ac//I6v5aXTipYrSESdOgzrN+9XjgEpyjpKuvSGaN4qE93f7TQTlerQQ8S+EQ0EyDoVL1A==", + "dev": true, + "requires": { + "ansi-styles": "^4.1.0", + "supports-color": "^7.1.0" + } + }, + "color-convert": { + "version": "2.0.1", + "resolved": "https://registry.npmjs.org/color-convert/-/color-convert-2.0.1.tgz", + "integrity": "sha512-RRECPsj7iu/xb5oKYcsFHSppFNnsj/52OVTRKb4zP5onXwVF3zVmmToNcOfGC+CRDpfK/U584fMg38ZHCaElKQ==", + "dev": true, + "requires": { + "color-name": "~1.1.4" + } + }, + "color-name": { + "version": "1.1.4", + "resolved": "https://registry.npmjs.org/color-name/-/color-name-1.1.4.tgz", + "integrity": "sha512-dOy+3AuW3a2wNbZHIuMZpTcgjGuLU/uBL/ubcZF9OXbDo8ff4O8yVp5Bf0efS8uEoYo5q4Fx7dY9OgQGXgAsQA==", + "dev": true + }, + "has-flag": { + "version": "4.0.0", + "resolved": "https://registry.npmjs.org/has-flag/-/has-flag-4.0.0.tgz", + "integrity": "sha512-EykJT/Q1KjTWctppgIAgfSO0tKVuZUjhgMr17kqTumMl6Afv3EISleU7qZUzoXDFTAHTDC4NOoG/ZxU3EvlMPQ==", + "dev": true + }, + "supports-color": { + "version": "7.1.0", + "resolved": "https://registry.npmjs.org/supports-color/-/supports-color-7.1.0.tgz", + "integrity": "sha512-oRSIpR8pxT1Wr2FquTNnGet79b3BWljqOuoW/h4oBhxJ/HUbX5nX6JSruTkvXDCFMwDPvsaTTbvMLKZWSy0R5g==", + "dev": true, + "requires": { + "has-flag": "^4.0.0" + } + } + } + }, + "postcss-load-config": { + "version": "2.1.0", + "resolved": "https://registry.npmjs.org/postcss-load-config/-/postcss-load-config-2.1.0.tgz", + "integrity": "sha512-4pV3JJVPLd5+RueiVVB+gFOAa7GWc25XQcMp86Zexzke69mKf6Nx9LRcQywdz7yZI9n1udOxmLuAwTBypypF8Q==", + "dev": true, + "requires": { + "cosmiconfig": "^5.0.0", + "import-cwd": "^2.0.0" + } + }, + "postcss-reporter": { + "version": "6.0.1", + "resolved": "https://registry.npmjs.org/postcss-reporter/-/postcss-reporter-6.0.1.tgz", + "integrity": "sha512-LpmQjfRWyabc+fRygxZjpRxfhRf9u/fdlKf4VHG4TSPbV2XNsuISzYW1KL+1aQzx53CAppa1bKG4APIB/DOXXw==", + "dev": true, + "requires": { + "chalk": "^2.4.1", + "lodash": "^4.17.11", + "log-symbols": "^2.2.0", + "postcss": "^7.0.7" + } + }, + "postcss-value-parser": { + "version": "4.1.0", + "resolved": "https://registry.npmjs.org/postcss-value-parser/-/postcss-value-parser-4.1.0.tgz", + "integrity": "sha512-97DXOFbQJhk71ne5/Mt6cOu6yxsSfM0QGQyl0L25Gca4yGWEGJaig7l7gbCX623VqTBNGLRLaVUCnNkcedlRSQ==", + "dev": true + }, + "pretty-hrtime": { + "version": "1.0.3", + "resolved": "https://registry.npmjs.org/pretty-hrtime/-/pretty-hrtime-1.0.3.tgz", + "integrity": "sha1-t+PqQkNaTJsnWdmeDyAesZWALuE=", + "dev": true + }, + "read-cache": { + "version": "1.0.0", + "resolved": "https://registry.npmjs.org/read-cache/-/read-cache-1.0.0.tgz", + "integrity": "sha1-5mTvMRYRZsl1HNvo28+GtftY93Q=", + "dev": true, + "requires": { + "pify": "^2.3.0" + } + }, + "readdirp": { + "version": "3.4.0", + "resolved": "https://registry.npmjs.org/readdirp/-/readdirp-3.4.0.tgz", + "integrity": "sha512-0xe001vZBnJEK+uKcj8qOhyAKPzIT+gStxWr3LCB0DwcXR5NZJ3IaC+yGnHCYzB/S7ov3m3EEbZI2zeNvX+hGQ==", + "dev": true, + "requires": { + "picomatch": "^2.2.1" + } + }, + "regenerator-runtime": { + "version": "0.13.5", + "resolved": "https://registry.npmjs.org/regenerator-runtime/-/regenerator-runtime-0.13.5.tgz", + "integrity": "sha512-ZS5w8CpKFinUzOwW3c83oPeVXoNsrLsaCoLtJvAClH135j/R77RuymhiSErhm2lKcwSCIpmvIWSbDkIfAqKQlA==", + "dev": true + }, + "require-directory": { + "version": "2.1.1", + "resolved": "https://registry.npmjs.org/require-directory/-/require-directory-2.1.1.tgz", + "integrity": "sha1-jGStX9MNqxyXbiNE/+f3kqam30I=", + "dev": true + }, + "require-main-filename": { + "version": "2.0.0", + "resolved": "https://registry.npmjs.org/require-main-filename/-/require-main-filename-2.0.0.tgz", + "integrity": "sha512-NKN5kMDylKuldxYLSUfrbo5Tuzh4hd+2E8NPPX02mZtn1VuREQToYe/ZdlJy+J3uCpfaiGF05e7B8W0iXbQHmg==", + "dev": true + }, + "resolve-from": { + "version": "3.0.0", + "resolved": "https://registry.npmjs.org/resolve-from/-/resolve-from-3.0.0.tgz", + "integrity": "sha1-six699nWiBvItuZTM17rywoYh0g=", + "dev": true + }, + "reusify": { + "version": "1.0.4", + "resolved": "https://registry.npmjs.org/reusify/-/reusify-1.0.4.tgz", + "integrity": "sha512-U9nH88a3fc/ekCF1l0/UP1IosiuIjyTh7hBvXVMHYgVcfGvt897Xguj2UOLDeI5BG2m7/uwyaLVT6fbtCwTyzw==", + "dev": true + }, + "run-parallel": { + "version": "1.1.9", + "resolved": "https://registry.npmjs.org/run-parallel/-/run-parallel-1.1.9.tgz", + "integrity": "sha512-DEqnSRTDw/Tc3FXf49zedI638Z9onwUotBMiUFKmrO2sdFKIbXamXGQ3Axd4qgphxKB4kw/qP1w5kTxnfU1B9Q==", + "dev": true + }, + "set-blocking": { + "version": "2.0.0", + "resolved": "https://registry.npmjs.org/set-blocking/-/set-blocking-2.0.0.tgz", + "integrity": "sha1-BF+XgtARrppoA93TgrJDkrPYkPc=", + "dev": true + }, + "slash": { + "version": "3.0.0", + "resolved": "https://registry.npmjs.org/slash/-/slash-3.0.0.tgz", + "integrity": "sha512-g9Q1haeby36OSStwb4ntCGGGaKsaVSjQ68fBxoQcutl5fS1vuY18H3wSt3jFyFtrkx+Kz0V1G85A4MyAdDMi2Q==", + "dev": true + }, + "source-map": { + "version": "0.6.1", + "resolved": "https://registry.npmjs.org/source-map/-/source-map-0.6.1.tgz", + "integrity": "sha512-UjgapumWlbMhkBgzT7Ykc5YXUT46F0iKu8SGXq0bcwP5dz/h0Plj6enJqjz1Zbq2l5WaqYnrVbwWOWMyF3F47g==", + "dev": true + }, + "sprintf-js": { + "version": "1.0.3", + "resolved": "https://registry.npmjs.org/sprintf-js/-/sprintf-js-1.0.3.tgz", + "integrity": "sha1-BOaSb2YolTVPPdAVIDYzuFcpfiw=", + "dev": true + }, + "string-width": { + "version": "4.2.0", + "resolved": "https://registry.npmjs.org/string-width/-/string-width-4.2.0.tgz", + "integrity": "sha512-zUz5JD+tgqtuDjMhwIg5uFVV3dtqZ9yQJlZVfq4I01/K5Paj5UHj7VyrQOJvzawSVlKpObApbfD0Ed6yJc+1eg==", + "dev": true, + "requires": { + "emoji-regex": "^8.0.0", + "is-fullwidth-code-point": "^3.0.0", + "strip-ansi": "^6.0.0" + } + }, + "strip-ansi": { + "version": "6.0.0", + "resolved": "https://registry.npmjs.org/strip-ansi/-/strip-ansi-6.0.0.tgz", + "integrity": "sha512-AuvKTrTfQNYNIctbR1K/YGTR1756GycPsg7b9bdV9Duqur4gv6aKqHXah67Z8ImS7WEz5QVcOtlfW2rZEugt6w==", + "dev": true, + "requires": { + "ansi-regex": "^5.0.0" + } + }, + "supports-color": { + "version": "6.1.0", + "resolved": "https://registry.npmjs.org/supports-color/-/supports-color-6.1.0.tgz", + "integrity": "sha512-qe1jfm1Mg7Nq/NSh6XE24gPXROEVsWHxC1LIx//XNlD9iw7YZQGjZNjYN7xGaEG6iKdA8EtNFW6R0gjnVXp+wQ==", + "dev": true, + "requires": { + "has-flag": "^3.0.0" + } + }, + "to-regex-range": { + "version": "5.0.1", + "resolved": "https://registry.npmjs.org/to-regex-range/-/to-regex-range-5.0.1.tgz", + "integrity": "sha512-65P7iz6X5yEr1cwcgvQxbbIw7Uk3gOy5dIdtZ4rDveLqhrdJP+Li/Hx6tyK0NEb+2GCyneCMJiGqrADCSNk8sQ==", + "dev": true, + "requires": { + "is-number": "^7.0.0" + } + }, + "universalify": { + "version": "1.0.0", + "resolved": "https://registry.npmjs.org/universalify/-/universalify-1.0.0.tgz", + "integrity": "sha512-rb6X1W158d7pRQBg5gkR8uPaSfiids68LTJQYOtEUhoJUWBdaQHsuT/EUduxXYxcrt4r5PJ4fuHW1MHT6p0qug==", + "dev": true + }, + "which-module": { + "version": "2.0.0", + "resolved": "https://registry.npmjs.org/which-module/-/which-module-2.0.0.tgz", + "integrity": "sha1-2e8H3Od7mQK4o6j6SzHD4/fm6Ho=", + "dev": true + }, + "wrap-ansi": { + "version": "6.2.0", + "resolved": "https://registry.npmjs.org/wrap-ansi/-/wrap-ansi-6.2.0.tgz", + "integrity": "sha512-r6lPcBGxZXlIcymEu7InxDMhdW0KDxpLgoFLcguasxCaJ/SOIZwINatK9KY/tf+ZrlywOKU0UDj3ATXUBfxJXA==", + "dev": true, + "requires": { + "ansi-styles": "^4.0.0", + "string-width": "^4.1.0", + "strip-ansi": "^6.0.0" + }, + "dependencies": { + "ansi-styles": { + "version": "4.2.1", + "resolved": "https://registry.npmjs.org/ansi-styles/-/ansi-styles-4.2.1.tgz", + "integrity": "sha512-9VGjrMsG1vePxcSweQsN20KY/c4zN0h9fLjqAbwbPfahM3t+NL+M9HC8xeXG2I8pX5NoamTGNuomEUFI7fcUjA==", + "dev": true, + "requires": { + "@types/color-name": "^1.1.1", + "color-convert": "^2.0.1" + } + }, + "color-convert": { + "version": "2.0.1", + "resolved": "https://registry.npmjs.org/color-convert/-/color-convert-2.0.1.tgz", + "integrity": "sha512-RRECPsj7iu/xb5oKYcsFHSppFNnsj/52OVTRKb4zP5onXwVF3zVmmToNcOfGC+CRDpfK/U584fMg38ZHCaElKQ==", + "dev": true, + "requires": { + "color-name": "~1.1.4" + } + }, + "color-name": { + "version": "1.1.4", + "resolved": "https://registry.npmjs.org/color-name/-/color-name-1.1.4.tgz", + "integrity": "sha512-dOy+3AuW3a2wNbZHIuMZpTcgjGuLU/uBL/ubcZF9OXbDo8ff4O8yVp5Bf0efS8uEoYo5q4Fx7dY9OgQGXgAsQA==", + "dev": true + } + } + }, + "xregexp": { + "version": "4.3.0", + "resolved": "https://registry.npmjs.org/xregexp/-/xregexp-4.3.0.tgz", + "integrity": "sha512-7jXDIFXh5yJ/orPn4SXjuVrWWoi4Cr8jfV1eHv9CixKSbU+jY4mxfrBwAuDvupPNKpMUY+FeIqsVw/JLT9+B8g==", + "dev": true, + "requires": { + "@babel/runtime-corejs3": "^7.8.3" + } + }, + "y18n": { + "version": "4.0.0", + "resolved": "https://registry.npmjs.org/y18n/-/y18n-4.0.0.tgz", + "integrity": "sha512-r9S/ZyXu/Xu9q1tYlpsLIsa3EeLXXk0VwlxqTcFRfg9EhMW+17kbt9G0NrgCmhGb5vT2hyhJZLfDGx+7+5Uj/w==", + "dev": true + }, + "yargs": { + "version": "15.4.0", + "resolved": "https://registry.npmjs.org/yargs/-/yargs-15.4.0.tgz", + "integrity": "sha512-D3fRFnZwLWp8jVAAhPZBsmeIHY8tTsb8ItV9KaAaopmC6wde2u6Yw29JBIZHXw14kgkRnYmDgmQU4FVMDlIsWw==", + "dev": true, + "requires": { + "cliui": "^6.0.0", + "decamelize": "^3.2.0", + "find-up": "^4.1.0", + "get-caller-file": "^2.0.1", + "require-directory": "^2.1.1", + "require-main-filename": "^2.0.0", + "set-blocking": "^2.0.0", + "string-width": "^4.2.0", + "which-module": "^2.0.0", + "y18n": "^4.0.0", + "yargs-parser": "^18.1.2" + } + }, + "yargs-parser": { + "version": "18.1.3", + "resolved": "https://registry.npmjs.org/yargs-parser/-/yargs-parser-18.1.3.tgz", + "integrity": "sha512-o50j0JeToy/4K6OZcaQmW6lyXXKhq7csREXcDwk2omFPJEwUNOVtJKvmDr9EI1fAJZUyZcRF7kxGBWmRXudrCQ==", + "dev": true, + "requires": { + "camelcase": "^5.0.0", + "decamelize": "^1.2.0" + }, + "dependencies": { + "decamelize": { + "version": "1.2.0", + "resolved": "https://registry.npmjs.org/decamelize/-/decamelize-1.2.0.tgz", + "integrity": "sha1-9lNNFRSCabIDUue+4m9QH5oZEpA=", + "dev": true + } + } + } + } +} diff --git a/package.json b/package.json index 139221f29f..f96c7422c8 100644 --- a/package.json +++ b/package.json @@ -1,12 +1,7 @@ { "private": true, "devDependencies": { - "@babel/core": "^7.0.1", - "@slack/client": "^4.4.0", - "autoprefixer": "^9.7.6", - "babel-loader": "^8.0.2", - "netlify-lambda": "^0.4.0", - "node-fetch": "^2.2.0", + "autoprefixer": "^9.8.4", "postcss-cli": "^7.1.1" } } diff --git a/postcss.config.js b/postcss.config.js new file mode 100644 index 0000000000..ad6eb708f9 --- /dev/null +++ b/postcss.config.js @@ -0,0 +1,21 @@ +/* +Copyright 2018 Google LLC + +Licensed under the Apache License, Version 2.0 (the "License"); +you may not use this file except in compliance with the License. +You may obtain a copy of the License at + + https://www.apache.org/licenses/LICENSE-2.0 + +Unless required by applicable law or agreed to in writing, software +distributed under the License is distributed on an "AS IS" BASIS, +WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. +See the License for the specific language governing permissions and +limitations under the License. +*/ + +module.exports = { + plugins: { + autoprefixer: {} + }, +} diff --git a/scripts/hash-files.sh b/scripts/hash-files.sh new file mode 100755 index 0000000000..0040f4355b --- /dev/null +++ b/scripts/hash-files.sh @@ -0,0 +1,10 @@ +#!/bin/sh +# this script emits as hash for the files listed in $@ +if command -v shasum >/dev/null 2>&1; then + cat "$@" | shasum -a 256 | cut -d' ' -f1 +elif command -v sha256sum >/dev/null 2>&1; then + cat "$@" | sha256sum | cut -d' ' -f1 +else + echo "missing shasum tool" 1>&2 + exit 1 +fi diff --git a/scripts/linkchecker.py b/scripts/linkchecker.py new file mode 100755 index 0000000000..71f40ac22b --- /dev/null +++ b/scripts/linkchecker.py @@ -0,0 +1,425 @@ +#!/usr/bin/env python3 +# +# This a link checker for Kubernetes documentation website. +# - We cover the following cases for the language you provide via `-l`, which +# defaults to 'en'. +# - If the language specified is not English (`en`), we check if you are +# actually using the localized links. For example, if you specify `zh` as +# the language, and for link target `/docs/foo/bar`, we check if the English +# version exists AND if the Chinese version exists as well. A checking record +# is produced if the link can use the localized version. +# +# Usage: linkchecker.py -h +# +# Cases handled: +# +# - [foo](#bar) : ignored currently +# + [foo](http://bar) : insecure links to external site +# + [foo](https://k8s.io/website/...) : hardcoded site domain name +# +# + [foo](/<lang>/docs/bar/...) : where <lang> is not 'en' +# + /<lang>/docs/bar : contains shortcode, so ignore, or +# + /<lang>/docs/bar : is a image link (ignore currently), or +# + /<lang>/docs/bar : points to shared (non-localized) page, or +# + /<lang>/docs/bar.md : exists for current lang, or +# + /<lang>/docs/bar/_index.md : exists for current lang, or +# + /<lang>/docs/bar/ : is a redirect entry, or +# + /<lang>/docs/bar : is something we don't understand, then ERR +# +# + [foo](/docs/bar/...) +# + /docs/bar : contains shortcode, so ignore, or +# + /docs/bar : is a image link (ignore currently), or +# + /docs/bar : points to a shared (non-localized) page, or +# + /docs/bar.md : exists for current lang, or +# + /docs/bar/_index.md : exists for current lang, or +# + /docs/bar : is a redirect entry, or +# + /docs/bar : is something we don't understand +# + +import argparse +import glob +import os +import re +import sys + +# These are the bad links that doesn't hurt, though good to fix +BAD_LINK_TYPES = { + "B01": { + "reason": "Using bad protocol", + "level": "WARNING", + }, + "B02": { + "reason": "Link target is a redirect entry", + "level": "WARNING", + }, + "B03": { + "reason": "Intra-site linkes should use relative path", + "level": "WARNING", + }, +} + +# Constants for colored printing +C_RED = "\033[31m" +C_GREEN = "\033[32m" +C_YELLOW = "\033[33m" +C_GRAY = "\033[90m" +C_CYAN = "\033[36m" +C_END = "\033[0m" + +# Command line arguments shared across functions +ARGS = None +# Global result dictionary keyed by page examined +RESULT = {} +# Cached redirect entries +REDIRECTS = {} + + +def new_record(level, message, target): + """Create new checking record. + + :param level: Record severity level, one of 'INFO', 'WARNING' and 'ERROR' + :param message: Error message string + :param target: The link target in question + :returns: A string representation the checking result, may contain ASCII + coded terminal colors, or None if the record is suppressed. + """ + global ARGS + + # Skip info when verbose + if ARGS.verbose == False and level == "INFO": + return None + + result = None + if ARGS.no_color: + result = target + ": " + message + else: + target = C_GRAY + target + C_END + if level == "INFO": + result = target + ": " + C_GREEN + message + C_END + elif level == "WARNING": + result = target + ": " + C_YELLOW+ message + C_END + else: # default to error + result = target + ": " + C_RED + message + C_END + + return result + + +def dump_result(): + """Dump result to stdout.""" + global RESULT, ARGS + + for path, path_output in RESULT.items(): + norm_path = os.path.normpath(path) + if ARGS.no_color: + print("File: " + norm_path) + else: + print(C_CYAN + "File: " + norm_path + C_END) + for p in path_output: + print(" "*4 + p) + return + + +def strip_comments(content): + """Manual striping of comments from file content. + + Many localized content pages contain original English content in comments. + These comments have to be stripped out before analyzing the links. + Doing this using regular expression is difficult. Even the grep tool is + not suitable for this use case. + + NOTE: We strived to preserve line numbers when producing the resulted + text. This can be useful in future if we want to print out the line + numbers for bad links. + """ + result = [] + in_comment = False + for line in content: + idx1 = line.find("<!--") + idx2 = line.find("-->") + if not in_comment: + # only care if new comment started + if idx1 < 0: + result.append(line) + continue + + # single line comment + if idx2 > 0: + result.append(line[:idx1] + line[idx2+4:]) + continue + result.append(line[:idx1]) + in_comment = True + continue + + # already in comment block + if idx2 < 0: # ignore whole line + result.append("") + continue + result.append(line[idx2+4:]) + in_comment = False + + return result + + +def normalize_filename(name, ftype="markdown"): + """Guess the filename based on a link target. + + This function only deals with regular files. + """ + if name.endswith("/"): + name = name[:-1] + if ftype == "markdown": + name += ".md" + else: + name += ".html" + return name + + +def check_file_exists(base, path, ftype="markdown"): + """Check if the target file exists. + + NOTE: We build a normalized path using 'base' and 'path' values. Suppose + the resulted path string is 'foo/bar', we check if 'foo/bar.md' exists, + AND we check if 'foo/bar/_index.md' exists. + + :param base: The base directory to begin with + :param path: The link target which is a relative path string + :returns: A boolean indicating whether the target file exists. + """ + # NOTE: anchor is ignored, can be a todo item + parts = path.split("#") + + fn = normalize_filename(parts[0], ftype=ftype) + target = base + fn + + if os.path.isfile(target): + return True + + dir_name = base + parts[0] + if os.path.isdir(dir_name): + if os.path.isfile(dir_name + "/_index.md"): + return True + if os.path.isfile(dir_name + "/_index.html"): + return True + # /docs/contribute/style/hugo-shortcodes/ has this + if os.path.isfile(dir_name + "/index.md"): + return True + return False + + +def get_redirect(path): + """Check if the path exists in the redirect database. + + NOTE: We do NOT check if the redirect target is there or not. We do an + **exact** matching for redirection entries. + :returns: The redirect target if any, or None if not found. + """ + global REDIRECTS + + def _check_redirect(t): + for key, value in REDIRECTS.items(): + if key == t: # EXACT MATCH + return value + return None + + # NOTE: anchor is ignored, can be a future todo + parts = path.split("#") + target = parts[0] + if not target.endswith("/"): + target += "/" + + new_target = _check_redirect(target) + last_target = new_target + while new_target: + new_target = _check_redirect(new_target) + if new_target is None: + break + last_target = new_target + + return last_target + + +def check_target(page, anchor, target): + """Check a link from anchor to target on provided page. + + :param page: Currently not used. Passed here in case we want to check the + in-page links in the future. + :param anchor: Anchor string from the content page. This is provided to + help handle cases where target is empty. + :param target: The link target string to check + :returns: A checking record (string) if errors found, or None if we can + find the target link. + """ + target = target.strip() + # B01: bad protocol + if target.startswith("http://"): + return new_record("WARNING", "Use HTTPS rather than HTTP", target) + + # full link + if target.startswith("https://"): + # B03: self link, should revise to relative path + if (target.startswith("https://k8s.io/docs") or + target.startswith("https://kubernetes.io/docs")): + return new_record("ERROR", "Should use relative paths", target) + # external link, skip + return new_record("INFO", "External link, skipped", target) + + # in-page link + # TODO: check if the target anchor does exists + if target.startswith("#"): + return new_record("INFO", "In-page link, skipped", target) + + # Link has shortcode + if target.find("{{") > 0: + return new_record("INFO", "Link has shortcode, skipped", target) + + # TODO: check links to examples + if target.startswith("/examples/"): + return new_record("WARNING", "Examples link, skipped", target) + + # it is an embedded image + # TODO: an image might get translated as well + if target.endswith(".png") or target.endswith(".svg"): + return new_record("INFO", "Link to image, skipped", target) + + # link to English or localized page + if (target.startswith("/docs/") or + target.startswith("/" + ARGS.lang + "/docs/")): + + # target is shared reference (kubectl or kubernetes-api? + if (target.find("/docs/reference/generated/kubectl/") >= 0 or + target.find("/docs/reference/generated/kubernetes-api/") >= 0): + if check_file_exists(ROOT + "/static", target, "html"): + return None + return new_record("ERROR", "Missing shared reference", target) + + # target is a markdown (.md) or a "<dir>/_index.md"? + if target.startswith("/docs/"): + base = os.path.join(ROOT, "content", "en") + else: + # localized target + base = os.path.join(ROOT, "content") + ok = check_file_exists(base, target) + if ok: + # We do't do additional checks for English site even if it has + # links to a non-English page + if ARGS.lang == "en": + return None + + # If we are already checking localized link, fine + if target.startswith("/" + ARGS.lang + "/docs/"): + return None + + # additional check for localization even if English target exists + base = os.path.join(ROOT, "content", ARGS.lang) + found = check_file_exists(base, target) + if not found: + # Still to be translated + return None + msg = ("Localized page detected, please append '/%s' to the target" + % ARGS.lang) + return new_record("ERROR", "Link not using localized page", target) + + # taget might be a redirect entry + real_target = get_redirect(target) + if real_target: + msg = ("Link using redirect records, should use %s instead" % + real_target) + return new_record("WARNING", msg, target) + return new_record("ERROR", "Missing link for [%s]" % anchor, target) + + msg = "Link may be wrong for the anchor [%s]" % anchor + return new_record("WARNING", msg, target) + + +def validate_links(page): + """Find and validate links on a content page. + + The checking records are consolidated into the global variable RESULT. + """ + try: + with open(page, "r") as f: + data = f.readlines() + except Exception as ex: + print("[Error] failed in reading markdown file: " + str(ex)) + return + + content = "\n".join(strip_comments(data)) + + # Single results: searches for pattern: []() + link_pattern = r"\[([`/\w\s\n]*)\]\(([^\)]*)\)" + regex = re.compile(link_pattern) + + matches = regex.findall(content) + records = [] + for m in matches: + r = check_target(page, m[0], m[1]) + if r: + records.append(r) + if len(records): + RESULT[page] = records + + +def parse_arguments(): + """Argument parser. + + Result is returned and saved into global variable ARGS. + """ + parser = argparse.ArgumentParser(description="Links checker for docs.") + parser.add_argument("-l", dest="lang", default="en", metavar="<LANG>", + help=("two letter language code, e.g. 'zh'. " + "(default='en')")) + parser.add_argument("-v", dest="verbose", action="store_true", + help="switch on verbose level") + parser.add_argument("-f", dest="filter", default="/docs/**/*.md", + metavar="<FILTER>", + help=("File pattern to scan, e.g. '/docs/foo.md'. " + "(default='/docs/foo/*.md')")) + parser.add_argument("-n", "--no-color", action="store_true", + help="Suppress colored printing.") + + return parser.parse_args() + + +def main(): + """The main entry of the program.""" + global ARGS, ROOT, REDIRECTS + + ARGS = parse_arguments() + print("Language: " + ARGS.lang) + ROOT = os.path.join(os.path.dirname(__file__), '..') + content_dir = os.path.join(ROOT, 'content') + lang_dir = os.path.join(content_dir, ARGS.lang) + + # read redirects data + redirects_fn = os.path.join(ROOT, "static", "_redirects") + try: + with open(redirects_fn, "r") as f: + data = f.readlines() + for item in data: + parts = item.split() + # There are entries without 301 specified + if len(parts) < 2: + continue + entry = parts[0] + # There are some entries not ended with "/" + if entry.endswith("/"): + REDIRECTS[entry] = parts[1] + else: + REDIRECTS[entry + "/"] = parts[1] + + except Exception as ex: + print("[Error] failed in reading redirects file: " + str(ex)) + return + + folders = [f for f in glob.glob(lang_dir + ARGS.filter, recursive=True)] + for page in folders: + validate_links(page) + + dump_result() + + # Done + print("Completed link validation.") + + +if __name__ == '__main__': + sys.exit(main()) diff --git a/scripts/replace-capture.sh b/scripts/replace-capture.sh index 231a361ed1..4221c48e37 100755 --- a/scripts/replace-capture.sh +++ b/scripts/replace-capture.sh @@ -1,8 +1,37 @@ #!/bin/bash # set K8S_WEBSITE in your env to your docs website root +# or rely on this script to determine it automatically +# You must run the script inside the repository for that to work +# # Note: website/content/<lang>/docs -CONTENT_DIR=${K8S_WEBSITE}/content + +find_content_dir() { + local self + local top + if command git rev-parse --is-inside-work-tree > /dev/null 2>&1 ; then + self="$0" + top="$(command git rev-parse --show-toplevel)" + while ( cd "${top}/.." && command git rev-parse --is-inside-work-tree> /dev/null 2>&1 ); do + top="$( cd "${top}/.." && "${self}" )" + done + printf "%s/content" "${top}" + else + printf "Could not autodetect CONTENT_DIR\n" 1>&2 + exit 1 + fi +} + +if [ -z ${K8S_WEBSITE+x} ]; then + CONTENT_DIR="$( find_content_dir )" +else + CONTENT_DIR=${K8S_WEBSITE}/content +fi + +if ! [ -d "${CONTENT_DIR}" ]; then + printf "Directory %s not found\n" "${CONTENT_DIR}" 1>&2 + exit 1 +fi # 16 langs # de en es fr hi id it ja ko no pl pt ru uk vi zh diff --git a/static/_redirects b/static/_redirects index 242518f7ef..54868bf685 100644 --- a/static/_redirects +++ b/static/_redirects @@ -20,7 +20,7 @@ /vi/docs/ /vi/docs/home/ 301! /zh/docs/ /zh/docs/home/ 301! /blog/2018/03/kubernetes-1.10-stabilizing-storage-security-networking/ /blog/2018/03/26/kubernetes-1.10-stabilizing-storage-security-networking/ 301! -/docs/admin/ /docs/concepts/cluster-administration/cluster-administration-overview/ 301 +/docs/admin/ /docs/concepts/cluster-administration/ 301 /docs/admin/add-ons/ /docs/concepts/cluster-administration/addons/ 301 /docs/admin/addons/ /docs/concepts/cluster-administration/addons/ 301 /docs/admin/apparmor/ /docs/tutorials/clusters/apparmor/ 301 @@ -72,10 +72,11 @@ /docs/concepts/abstractions/controllers/statefulsets/ /docs/concepts/workloads/controllers/statefulset/ 301 /docs/concepts/abstractions/init-containers/ /docs/concepts/workloads/pods/init-containers/ 301 /docs/concepts/abstractions/overview/ /docs/concepts/overview/working-with-objects/kubernetes-objects/ 301 -/docs/concepts/abstractions/pod/ /docs/concepts/workloads/pods/pod-overview/ 301 +/docs/concepts/abstractions/pod/ /docs/concepts/workloads/pods/ 301 /docs/concepts/api-extension/apiserver-aggregation/ /docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation/ 301 /docs/concepts/api-extension/custom-resources/ /docs/concepts/extend-kubernetes/api-extension/custom-resources/ 301 -/docs/concepts/cluster/ /docs/concepts/cluster-administration/cluster-administration-overview/ 301 +/docs/concepts/containers/overview/ /docs/concepts/containers/ 301 +/docs/concepts/cluster-administration/cluster-administration-overview/ /docs/concepts/cluster-administration/ 301 /docs/concepts/cluster-administration/access-cluster/ /docs/tasks/access-application-cluster/access-cluster/ 301 /docs/concepts/cluster-administration/audit/ /docs/tasks/debug-application-cluster/audit/ 301 /docs/concepts/cluster-administration/authenticate-across-clusters-kubeconfig /docs/tasks/access-application-cluster/authenticate-across-clusters-kubeconfig/ 301 @@ -98,12 +99,13 @@ /docs/concepts/configuration/scheduler-perf-tuning/ /docs/concepts/scheduling-eviction/scheduler-perf-tuning/ 301 /docs/concepts/configuration/scheduling-framework/ /docs/concepts/scheduling-eviction/scheduling-framework/ 301 /docs/concepts/configuration/taint-and-toleration/ /docs/concepts/scheduling-eviction/taint-and-toleration/ 301 +/docs/concepts/extend-kubernetes/extend-cluster/ /docs/concepts/extend-kubernetes/ 301 /docs/concepts/jobs/cron-jobs/ /docs/concepts/workloads/controllers/cron-jobs/ 301 /docs/concepts/jobs/run-to-completion-finite-workloads/ /docs/concepts/workloads/controllers/job/ 301 /docs/concepts/nodes/node/ /docs/concepts/architecture/nodes/ 301 /docs/concepts/object-metadata/annotations/ /docs/concepts/overview/working-with-objects/annotations/ 301 /docs/concepts/overview/ /docs/concepts/overview/what-is-kubernetes/ 301 -/docs/concepts/overview/extending/ /docs/concepts/extend-kubernetes/extend-cluster/ 301 +/docs/concepts/overview/extending/ /docs/concepts/extend-kubernetes/ 301 /docs/concepts/policy/container-capabilities/ /docs/tasks/configure-pod-container/security-context/#set-capabilities-for-a-container/ 301 /docs/concepts/policy/security-context/ /docs/tasks/configure-pod-container/security-context/ 301 /docs/concepts/scheduling/kube-scheduler/ /docs/concepts/scheduling-eviction/kube-scheduler/ 301 @@ -124,12 +126,14 @@ /docs/concepts/overview/object-management-kubectl/imperative-config/ /docs/tasks/manage-kubernetes-objects/imperative-config/ 301 /docs/concepts/overview/object-management-kubectl/kustomization/ /docs/tasks/manage-kubernetes-objects/kustomization/ 301 /docs/concepts/workloads/controllers/cron-jobs/deployment/ /docs/concepts/workloads/controllers/cron-jobs/ 301 -/docs/concepts/workloads/controllers/daemonset/docs/concepts/workloads/pods/pod/ /docs/concepts/workloads/pods/pod/ 301 -/docs/concepts/workloads/controllers/deployment/docs/concepts/workloads/pods/pod/ /docs/concepts/workloads/pods/pod/ 301 -/docs/concepts/workloads/controllers/job/ /docs/concepts/workloads/controllers/job/ 301 +/docs/concepts/workloads/controllers/daemonset/docs/concepts/workloads/pods/pod/ /docs/concepts/workloads/pods/ 301 +/docs/concepts/workloads/controllers/deployment/docs/concepts/workloads/pods/pod/ /docs/concepts/workloads/pods/ 301 + /docs/concepts/workloads/controllers/jobs-run-to-completion/ /docs/concepts/workloads/controllers/job/ 301 /docs/concepts/workloads/controllers/statefulsets/ /docs/concepts/workloads/controllers/statefulset/ 301 /docs/concepts/workloads/controllers/statefulset.md /docs/concepts/workloads/controllers/statefulset/ 301! +/docs/concepts/workloads/pods/pod/ /docs/concepts/workloads/pods/ 301 +/docs/concepts/workloads/pods/pod-overview/ /docs/concepts/workloads/pods/ 301 /docs/concepts/workloads/pods/init-containers/Kubernetes/ /docs/concepts/workloads/pods/init-containers/ 301 /docs/consumer-guideline/pod-security-coverage/ /docs/concepts/policy/pod-security-policy/ 301 @@ -213,6 +217,7 @@ /docs/tasks/administer-cluster/certificate-rotation/ /docs/reference/command-line-tools-reference/kubelet-tls-bootstrapping/ 301 /docs/tasks/administer-cluster/cilium-network-policy/ /docs/tasks/administer-cluster/network-policy-provider/cilium-network-policy/ 301 /docs/tasks/administer-cluster/configure-namespace-isolation/ /docs/concepts/services-networking/network-policies/ 301 +/docs/tasks/administer-cluster/configure-multiple-schedulers/ /docs/tasks/extend-kubernetes/configure-multiple-schedulers/ 301 /docs/tasks/administer-cluster/configure-pod-disruption-budget/ /docs/tasks/run-application/configure-pdb/ 301 /docs/tasks/administer-cluster/cpu-constraint-namespace/ /docs/tasks/administer-cluster/manage-resources/cpu-constraint-namespace/ 301 /docs/tasks/administer-cluster/cpu-default-namespace/ /docs/tasks/administer-cluster/manage-resources/cpu-default-namespace 301 @@ -229,7 +234,7 @@ /docs/tasks/administer-cluster/memory-constraint-namespace/ /docs/tasks/administer-cluster/manage-resources/memory-constraint-namespace/ 301 /docs/tasks/administer-cluster/memory-default-namespace/ /docs/tasks/administer-cluster/manage-resources/memory-default-namespace/ 301 /docs/tasks/administer-cluster/out-of-resource/memory-available.sh /docs/tasks/administer-cluster/memory-available.sh 301 -/docs/tasks/administer-cluster/overview/ /docs/concepts/cluster-administration/cluster-administration-overview/ 301 +/docs/tasks/administer-cluster/overview/ /docs/concepts/cluster-administration/ 301 /docs/tasks/administer-cluster/quota-memory-cpu-namespace/ /docs/tasks/administer-cluster/manage-resources/quota-memory-cpu-namespace/ 301 /docs/tasks/administer-cluster/quota-pod-namespace/ /docs/tasks/administer-cluster/manage-resources/quota-pod-namespace/ 301 /docs/tasks/administer-cluster/reserve-compute-resources/out-of-resource.md /docs/tasks/administer-cluster/out-of-resource/ 301 @@ -297,7 +302,6 @@ /docs/tutorials/kubernetes-basics/update-intro/ /docs/tutorials/kubernetes-basics/update/update-intro/ 301 /ja/docs/tutorials/kubernetes-basics/update-intro/ /ja/docs/tutorials/kubernetes-basics/update/update-intro/ 301 /ko/docs/tutorials/kubernetes-basics/update-intro/ /ko/docs/tutorials/kubernetes-basics/update/update-intro/ 301 -/docs/tutorials/example-tutorial-template.md -> /example-templates/example-tutorial-template.md 301 /docs/tutorials/object-management-kubectl/declarative-object-management-configuration/ /docs/concepts/overview/object-management-kubectl/declarative-config/ 301 /docs/tutorials/object-management-kubectl/imperative-object-management-command/ /docs/concepts/overview/object-management-kubectl/imperative-command/ 301 /docs/tutorials/object-management-kubectl/imperative-object-management-configuration/ /docs/concepts/overview/object-management-kubectl/imperative-config/ 301 @@ -381,14 +385,14 @@ /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/tasks/inject-data-application/podpreset/ 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-overview/ 301 +/docs/user-guide/pod-templates/ /docs/concepts/workloads/pods/#pod-templates 301 /docs/user-guide/pods/ /docs/concepts/workloads/pods/pod/ 301 /docs/user-guide/pods/init-container/ /docs/concepts/workloads/pods/init-containers/ 301 -/docs/user-guide/pods/multi-container/ /docs/tasks/access-application-cluster/communicate-containers-same-pod-shared-volume/ 301 -/docs/user-guide/pods/single-container/ /docs/tasks/run-application/run-stateless-application-deployment/ 301 +/docs/user-guide/pods/multi-container/ /docs/concepts/workloads/pods/#using-pods 301 +/docs/user-guide/pods/single-container/ /docs/concepts/workloads/pods/#using-pods 301 /docs/user-guide/prereqs/ /docs/tasks/tools/install-kubectl/ 301 /docs/user-guide/production-pods/ /docs/tasks/ 301 /docs/user-guide/projected-volume/ /docs/tasks/configure-pod-container/configure-projected-volume-storage/ 301 @@ -438,7 +442,8 @@ /docs/admin/kubeadm/ /docs/reference/generated/kubeadm/ 301 /docs/admin/kubelet/ /docs/reference/generated/kubelet/ 301 -/docs/reference/generated/kubeadm/ /docs/reference/setup-tools/kubeadm/kubeadm/ 301 +/docs/reference/generated/kubeadm/ /docs/reference/setup-tools/kubeadm/ 301 +/docs/reference/setup-tools/kubeadm/kubeadm/ /docs/reference/setup-tools/kubeadm/ 301 /editdocs/ /docs/contribute/ 301 /docs/home/editdocs/ /docs/contribute/ 301 @@ -491,4 +496,4 @@ /docs/setup/multiple-zones/ /docs/setup/best-practices/multiple-zones/ 301 /docs/setup/cluster-large/ /docs/setup/best-practices/cluster-large/ 301 /docs/setup/node-conformance/ /docs/setup/best-practices/node-conformance/ 301 -/docs/setup/certificates/ /docs/setup/best-practices/certificates/ 301 \ No newline at end of file +/docs/setup/certificates/ /docs/setup/best-practices/certificates/ 301 diff --git a/static/css/README.md b/static/css/README.md new file mode 100644 index 0000000000..1b7f01d417 --- /dev/null +++ b/static/css/README.md @@ -0,0 +1,12 @@ +# NOTE + + +This directory contains stylesheet files referenced by different sections of +the website. Please use caution when moving/renaming them. + +## Style Sheets used by API reference + +- bootstrap-4.3.1.min.css +- fontawesome-4.7.0.min.css +- style_apiref.css + diff --git a/static/css/announcement.css b/static/css/announcement.css index 54d4c5db55..96d1065133 100644 --- a/static/css/announcement.css +++ b/static/css/announcement.css @@ -33,7 +33,7 @@ min-height: 30vh; } -#fp-announcement main { +#fp-announcement aside { padding-top: 125px; padding-bottom: 35px; } diff --git a/static/docs/reference/generated/kubernetes-api/v1.18/css/bootstrap.min.css b/static/css/bootstrap-4.3.1.min.css similarity index 100% rename from static/docs/reference/generated/kubernetes-api/v1.18/css/bootstrap.min.css rename to static/css/bootstrap-4.3.1.min.css diff --git a/static/css/custom-jekyll/tags.css b/static/css/custom-jekyll/tags.css index 3b929925e8..1ff6d12e85 100644 --- a/static/css/custom-jekyll/tags.css +++ b/static/css/custom-jekyll/tags.css @@ -27,7 +27,7 @@ /* Position the tooltip text */ position: absolute; - z-index: 1; + z-index: 10; bottom: 125%; left: 50%; margin-left: -150px; diff --git a/static/docs/reference/generated/kubernetes-api/v1.18/css/font-awesome.min.css b/static/css/fontawesome-4.7.0.min.css similarity index 100% rename from static/docs/reference/generated/kubernetes-api/v1.18/css/font-awesome.min.css rename to static/css/fontawesome-4.7.0.min.css diff --git a/static/css/glossary.css b/static/css/glossary.css index 56d9289f87..fbe429b81b 100644 --- a/static/css/glossary.css +++ b/static/css/glossary.css @@ -6,8 +6,11 @@ background-image: url(../images/link.png); background-repeat: no-repeat; display: inline-block; + vertical-align: middle; + font-size: 0; color: transparent; - width: 20px; + width: 17px; + height: 17px; margin-left: 10px; } diff --git a/static/css/style_amadeus.css b/static/css/style_amadeus.css index bf4d9e3c82..709ecb078d 100644 --- a/static/css/style_amadeus.css +++ b/static/css/style_amadeus.css @@ -50,7 +50,7 @@ h1 { padding-bottom:0.5%; padding-left:10%; font-size:32px; - background: url('/images/CaseStudy_amadeus_banner1.jpg'); + background: url('/images/case-studies/amadeus/banner1.jpg'); background-size:100% auto; background-repeat:no-repeat; } @@ -82,7 +82,7 @@ h1 { font-size:24px; letter-spacing:0.03em; line-height:34px; - background: url('/images/CaseStudy_amadeus_banner3.jpg'); + background: url('/images/case-studies/amadeus/banner3.jpg'); background-size:100% auto; } @@ -95,7 +95,7 @@ h1 { font-size:24px; letter-spacing:0.03em; line-height:34px; - background: url('/images/CaseStudy_amadeus_banner4.jpg'); + background: url('/images/case-studies/amadeus/banner4.jpg'); background-size:100% auto; } @@ -276,7 +276,7 @@ h4 { .logo { width:8%; } - + .col1 { width: 95%; padding-right:8%; @@ -310,7 +310,7 @@ h4 { padding-bottom:2%; padding-left:10%; font-size:18px; - background: url('/images/CaseStudy_amadeus_banner1.jpg'); + background: url('/images/case-studies/amadeus/banner1.jpg'); background-size:100% auto; } @@ -340,7 +340,7 @@ h4 { line-height:23px; width:90%; float:left; - background: url('/images/CaseStudy_amadeus_banner3.jpg'); + background: url('/images/case-studies/amadeus/banner3.jpg'); } .banner4 { @@ -354,7 +354,7 @@ h4 { line-height:24px; width:100%; float:left; - background: url('/images/CaseStudy_amadeus_banner4.jpg'); + background: url('/images/case-studies/amadeus/banner4.jpg'); } .banner5 { @@ -439,7 +439,7 @@ h4 { } /* End Media 910px */ @media screen and (max-width: 580px){ - + .header_logo { width:60%; margin-bottom:1%; @@ -448,6 +448,6 @@ h4 { } .banner1 { - background: url('/images/CaseStudy_amadeus_banner_mobile.jpg'); + background: url('/images/case-studies/amadeus/banner_mobile.jpg'); } } diff --git a/static/css/style_ancestry.css b/static/css/style_ancestry.css index d5ecfd98d7..9f93d22bb9 100644 --- a/static/css/style_ancestry.css +++ b/static/css/style_ancestry.css @@ -43,7 +43,7 @@ h1 { padding-bottom:0.5%; padding-left:10.9%; font-size:32px; - background: url('/images/CaseStudy_ancestry_banner1.jpg'); + background: url('/images/case-studies/ancestry/banner1.jpg'); background-size:100% auto; background-repeat:no-repeat; } @@ -74,7 +74,7 @@ h1 { font-size:21px; letter-spacing:0.03em; line-height:32px; - background: url('/images/CaseStudy_ancestry_banner3.jpg'); + background: url('/images/case-studies/ancestry/banner3.jpg'); background-size:100% auto; } @@ -87,7 +87,7 @@ h1 { font-size:21px; letter-spacing:0.03em; line-height:32px; - background: url('/images/CaseStudy_ancestry_banner4.jpg'); + background: url('/images/case-studies/ancestry/banner4.jpg'); background-size:100% auto; } @@ -263,7 +263,7 @@ h4 { .logo { width:8%; } - + .col1 { width: 90%; padding-left:5%; diff --git a/static/docs/reference/generated/kubernetes-api/v1.18/css/stylesheet.css b/static/css/style_apiref.css similarity index 100% rename from static/docs/reference/generated/kubernetes-api/v1.18/css/stylesheet.css rename to static/css/style_apiref.css diff --git a/static/css/style_blablacar.css b/static/css/style_blablacar.css old mode 100755 new mode 100644 index e5e45c2284..ffa005ee71 --- a/static/css/style_blablacar.css +++ b/static/css/style_blablacar.css @@ -47,7 +47,7 @@ h1 { padding-bottom:0.5%; padding-left:10%; font-size:34px; - background: url('/images/CaseStudy_blablacar_banner1.jpg'); + background: url('/images/case-studies/blablacar/banner1.jpg'); background-size:100% auto; background-repeat:no-repeat; } @@ -78,7 +78,7 @@ h1 { font-size:24px; letter-spacing:0.03em; line-height:34px; - background: url('/images/CaseStudy_blablacar_banner3.jpg'); + background: url('/images/case-studies/blablacar/banner3.jpg'); background-size:100% auto; } @@ -91,7 +91,7 @@ h1 { font-size:25px; letter-spacing:0.03em; line-height:34px; - background: url('/images/CaseStudy_blablacar_banner4.jpg'); + background: url('/images/case-studies/blablacar/banner4.jpg'); background-size:100% auto; } @@ -304,7 +304,7 @@ h4 { padding-bottom:2%; padding-left:10%; font-size:18px; - background: url('/images/CaseStudy_blablacar_banner1.jpg'); + background: url('/images/case-studies/blablacar/banner1.jpg'); background-size:100% auto; } @@ -334,7 +334,7 @@ h4 { line-height:23px; width:90%; float:left; - background: url('/images/CaseStudy_blablacar_banner3.jpg'); + background: url('/images/case-studies/blablacar/banner3.jpg'); } .banner4 { @@ -348,7 +348,7 @@ h4 { line-height:24px; width:100%; float:left; - background: url('/images/CaseStudy_blablacar_banner4.jpg'); + background: url('/images/case-studies/blablacar/banner4.jpg'); } .banner5 { @@ -441,6 +441,6 @@ h4 { } .banner1 { - background: url('/images/CaseStudy_blablacar_banner1_mobile.jpg'); + background: url('/images/case-studies/blablacar/banner1_mobile.jpg'); } } diff --git a/static/css/style_blackrock.css b/static/css/style_blackrock.css index 8c05f839a9..61d997ba41 100644 --- a/static/css/style_blackrock.css +++ b/static/css/style_blackrock.css @@ -47,7 +47,7 @@ h1 { padding-bottom:0.5%; padding-left:10%; font-size:32px; - background: url('/images/CaseStudy_blackrock_banner1.jpg'); + background: url('/images/case-studies/blackrock/banner1.jpg'); background-size:100% auto; background-repeat:no-repeat; } @@ -78,7 +78,7 @@ h1 { font-size:24px; letter-spacing:0.03em; line-height:34px; - background: url('/images/CaseStudy_blackrock_banner3.jpg'); + background: url('/images/case-studies/blackrock/banner3.jpg'); background-size:100% auto; } @@ -91,7 +91,7 @@ h1 { font-size:24px; letter-spacing:0.03em; line-height:34px; - background: url('/images/CaseStudy_blackrock_banner4.jpg'); + background: url('/images/case-studies/blackrock/banner4.jpg'); background-size:100% auto; } @@ -302,7 +302,7 @@ h4 { padding-bottom:2%; padding-left:10%; font-size:18px; - background: url('/images/CaseStudy_blackrock_banner1.jpg'); + background: url('/images/case-studies/blackrock/banner1.jpg'); background-size:100% auto; } @@ -332,7 +332,7 @@ h4 { line-height:23px; width:90%; float:left; - background: url('/images/CaseStudy_blackrock_banner3.jpg'); + background: url('/images/case-studies/blackrock/banner3.jpg'); } .banner4 { @@ -346,7 +346,7 @@ h4 { line-height:24px; width:100%; float:left; - background: url('/images/CaseStudy_blackrock_banner4.jpg'); + background: url('/images/case-studies/blackrock/banner4.jpg'); } .banner5 { @@ -431,7 +431,7 @@ h4 { } /* End Media 910px */ @media screen and (max-width: 580px){ - + .header_logo { width:60%; margin-bottom:1%; diff --git a/static/css/style_box.css b/static/css/style_box.css index 90c4e8ea00..9ca316ed1e 100644 --- a/static/css/style_box.css +++ b/static/css/style_box.css @@ -44,7 +44,7 @@ h1 { padding-bottom:0.5%; padding-left:9.9%; font-size:32px; - background: url('/images/CaseStudy_box_banner1.jpg'); + background: url('/images/case-studies/box/banner1.jpg'); background-size:100% auto; background-repeat:no-repeat; } @@ -72,7 +72,7 @@ h1 { font-size:21px; letter-spacing:0.03em; line-height:32px; - background: url('/images/CaseStudy_box_banner3.jpg'); + background: url('/images/case-studies/box/banner3.jpg'); background-size:100% auto; } @@ -85,7 +85,7 @@ h1 { font-size:21px; letter-spacing:0.03em; line-height:32px; - background: url('/images/CaseStudy_box_banner4.jpg'); + background: url('/images/case-studies/box/banner4.jpg'); background-size:100% auto; } @@ -256,7 +256,7 @@ h4 { .logo { width:8%; } - + .col1 { width: 100%; padding-left:5%; @@ -292,7 +292,7 @@ h4 { padding-bottom:2%; padding-left:10%; font-size:18px; - background: url('/images/CaseStudy_box_banner1.jpg'); + background: url('/images/case-studies/box/banner1.jpg'); background-size:100% auto; } @@ -323,7 +323,7 @@ h4 { line-height:24px; width:100%; float:left; - background: url('/images/CaseStudy_box_banner3.jpg'); + background: url('/images/case-studies/box/banner3.jpg'); } .banner4 { @@ -337,7 +337,7 @@ h4 { line-height:24px; width:100%; float:left; - background: url('/images/CaseStudy_box_banner4.jpg'); + background: url('/images/case-studies/box/banner4.jpg'); } .banner5 { diff --git a/static/css/style_buffer.css b/static/css/style_buffer.css old mode 100755 new mode 100644 index 0928365b13..299a1aea21 --- a/static/css/style_buffer.css +++ b/static/css/style_buffer.css @@ -45,7 +45,7 @@ h1 { padding-bottom:0.5%; padding-left:9.9%; font-size:32px; - background: url('/images/CaseStudy_buffer_banner3.jpg'); + background: url('/images/case-studies/buffer/banner3.jpg'); background-size:100% auto; background-repeat:no-repeat; } @@ -75,7 +75,7 @@ h1 { font-size:21px; letter-spacing:0.03em; line-height:32px; - background: url('/images/CaseStudy_buffer_banner1.jpg'); + background: url('/images/case-studies/buffer/banner1.jpg'); background-size:100% auto; } @@ -88,7 +88,7 @@ h1 { font-size:21px; letter-spacing:0.03em; line-height:32px; - background: url('/images/CaseStudy_buffer_banner4.jpg'); + background: url('/images/case-studies/buffer/banner4.jpg'); background-size:100% auto; } @@ -259,7 +259,7 @@ h4 { .logo { width:8%; } - + .col1 { width: 100%; padding-left:5%; @@ -295,7 +295,7 @@ h4 { padding-bottom:2%; padding-left:10%; font-size:18px; - background: url('/images/CaseStudy_buffer_banner3.jpg'); + background: url('/images/case-studies/buffer/banner3.jpg'); background-size:100% auto; } @@ -328,7 +328,7 @@ h4 { padding-left:15%; padding-right:10%; float:left; - background: url('/images/CaseStudy_buffer_banner1.jpg'); + background: url('/images/case-studies/buffer/banner1.jpg'); } .banner4 { @@ -342,7 +342,7 @@ h4 { line-height:24px; width:100%; float:left; - background: url('/images/CaseStudy_buffer_banner4.jpg'); + background: url('/images/case-studies/buffer/banner4.jpg'); } .banner5 { diff --git a/static/css/style_crowdfire.css b/static/css/style_crowdfire.css index a03bfb4bd5..3e153e1006 100644 --- a/static/css/style_crowdfire.css +++ b/static/css/style_crowdfire.css @@ -47,7 +47,7 @@ h1 { padding-bottom:0.5%; padding-left:10%; font-size:32px; - background: url('/images/CaseStudy_crowdfire_banner1.jpg'); + background: url('/images/case-studies/crowdfire/banner1.jpg'); background-size:100% auto; background-repeat:no-repeat; } @@ -78,7 +78,7 @@ h1 { font-size:24px; letter-spacing:0.03em; line-height:34px; - background: url('/images/CaseStudy_crowdfire_banner3.jpg'); + background: url('/images/case-studies/crowdfire/banner3.jpg'); background-size:100% auto; } @@ -91,7 +91,7 @@ h1 { font-size:24px; letter-spacing:0.03em; line-height:34px; - background: url('/images/CaseStudy_crowdfire_banner4.jpg'); + background: url('/images/case-studies/crowdfire/banner4.jpg'); background-size:100% auto; } @@ -268,7 +268,7 @@ h4 { .logo { width:8%; } - + .col1 { width: 95%; padding-right:8%; @@ -302,7 +302,7 @@ h4 { padding-bottom:2%; padding-left:10%; font-size:18px; - background: url('/images/CaseStudy_crowdfire_banner1.jpg'); + background: url('/images/case-studies/crowdfire/banner1.jpg'); background-size:100% auto; } @@ -332,7 +332,7 @@ h4 { line-height:23px; width:90%; float:left; - background: url('/images/CaseStudy_crowdfire_banner3.jpg'); + background: url('/images/case-studies/crowdfire/banner3.jpg'); } .banner4 { @@ -346,7 +346,7 @@ h4 { line-height:24px; width:100%; float:left; - background: url('/images/CaseStudy_crowdfire_banner4.jpg'); + background: url('/images/case-studies/crowdfire/banner4.jpg'); } .banner5 { @@ -441,6 +441,6 @@ h4 { } .banner1 { - background: url('/images/CaseStudy_crowdfire_banner1.jpg'); + background: url('/images/case-studies/crowdfire/banner1.jpg'); } } diff --git a/static/css/style_golfnow.css b/static/css/style_golfnow.css index b33d3cfdab..abd875080d 100644 --- a/static/css/style_golfnow.css +++ b/static/css/style_golfnow.css @@ -18,7 +18,7 @@ body { } footer { - background-color:#ffffff !important; + background-color:#ffffff !important; } h1 { @@ -44,7 +44,7 @@ h1 { padding-bottom:0.5%; padding-left:9.9%; font-size:32px; - background: url('/images/CaseStudy_golfnow_banner1.jpg'); + background: url('/images/case-studies/golfnow/banner1.jpg'); background-size:100% auto; background-repeat:no-repeat; } @@ -74,7 +74,7 @@ h1 { font-size:21px; letter-spacing:0.03em; line-height:32px; - background: url('/images/CaseStudy_golfnow_banner3.jpg'); + background: url('/images/case-studies/golfnow/banner3.jpg'); background-size:100% auto; } @@ -87,7 +87,7 @@ h1 { font-size:21px; letter-spacing:0.03em; line-height:32px; - background: url('/images/CaseStudy_golfnow_banner4.jpg'); + background: url('/images/case-studies/golfnow/banner4.jpg'); background-size:100% auto; } @@ -294,7 +294,7 @@ h4 { padding-bottom:2%; padding-left:10%; font-size:18px; - background: url('/images/CaseStudy_golfnow_banner1.jpg'); + background: url('/images/case-studies/golfnow/banner1.jpg'); background-size:100% auto; } @@ -327,7 +327,7 @@ h4 { padding-left:15%; padding-right:10%; float:left; - background: url('/images/CaseStudy_golfnow_banner3.jpg'); + background: url('/images/case-studies/golfnow/banner3.jpg'); } .banner4 { @@ -341,7 +341,7 @@ h4 { line-height:24px; width:100%; float:left; - background: url('/images/CaseStudy_golfnow_banner4.jpg'); + background: url('/images/case-studies/golfnow/banner4.jpg'); } .banner5 { @@ -402,7 +402,7 @@ h4 { text-align:center; color:#ffffff; } - + .fullcol { margin-top:6%; } diff --git a/static/css/style_haufegroup.css b/static/css/style_haufegroup.css index b472a3d57f..b8cee6ca6e 100644 --- a/static/css/style_haufegroup.css +++ b/static/css/style_haufegroup.css @@ -47,7 +47,7 @@ h1 { padding-bottom:0.5%; padding-left:10%; font-size:32px; - background: url('/images/CaseStudy_haufegroup_banner1.jpg'); + background: url('/images/case-studies/haufegroup/banner1.jpg'); background-size:100% auto; background-repeat:no-repeat; } @@ -78,7 +78,7 @@ h1 { font-size:24px; letter-spacing:0.03em; line-height:34px; - background: url('/images/CaseStudy_haufegroup_banner3.jpg'); + background: url('/images/case-studies/haufegroup/banner3.jpg'); background-size:100% auto; } @@ -91,7 +91,7 @@ h1 { font-size:24px; letter-spacing:0.03em; line-height:34px; - background: url('/images/CaseStudy_haufegroup_banner4.jpg'); + background: url('/images/case-studies/haufegroup/banner4.jpg'); background-size:100% auto; } @@ -302,7 +302,7 @@ h4 { padding-bottom:2%; padding-left:10%; font-size:18px; - background: url('/images/CaseStudy_haufegroup_banner1.jpg'); + background: url('/images/case-studies/haufegroup/banner1.jpg'); background-size:100% auto; } @@ -332,7 +332,7 @@ h4 { line-height:23px; width:90%; float:left; - background: url('/images/CaseStudy_haufegroup_banner3.jpg'); + background: url('/images/case-studies/haufegroup/banner3.jpg'); } .banner4 { @@ -346,7 +346,7 @@ h4 { line-height:24px; width:100%; float:left; - background: url('/images/CaseStudy_haufegroup_banner4.jpg'); + background: url('/images/case-studies/haufegroup/banner4.jpg'); } .banner5 { @@ -439,6 +439,6 @@ h4 { } .banner1 { - background: url('/images/CaseStudy_haufegroup_banner1.jpg'); + background: url('/images/case-studies/haufegroup/banner1.jpg'); } } diff --git a/static/css/style_huawei.css b/static/css/style_huawei.css index 05c4f30ee0..a1d449e621 100644 --- a/static/css/style_huawei.css +++ b/static/css/style_huawei.css @@ -47,7 +47,7 @@ h1 { padding-bottom:0.5%; padding-left:10%; font-size:32px; - background: url('/images/CaseStudy_huawei_banner1.jpg'); + background: url('/images/case-studies/huawei/banner1.jpg'); background-size:100% auto; background-repeat:no-repeat; } @@ -78,7 +78,7 @@ h1 { font-size:24px; letter-spacing:0.03em; line-height:34px; - background: url('/images/CaseStudy_huawei_banner3.jpg'); + background: url('/images/case-studies/huawei/banner3.jpg'); background-size:100% auto; } @@ -91,7 +91,7 @@ h1 { font-size:24px; letter-spacing:0.03em; line-height:34px; - background: url('/images/CaseStudy_huawei_banner4.jpg'); + background: url('/images/case-studies/huawei/banner4.jpg'); background-size:100% auto; } @@ -302,7 +302,7 @@ h4 { padding-bottom:2%; padding-left:10%; font-size:18px; - background: url('/images/CaseStudy_huawei_banner1.jpg'); + background: url('/images/case-studies/huawei/banner1.jpg'); background-size:100% auto; } @@ -332,7 +332,7 @@ h4 { line-height:23px; width:90%; float:left; - background: url('/images/CaseStudy_huawei_banner3.jpg'); + background: url('/images/case-studies/huawei/banner3.jpg'); } .banner4 { @@ -346,7 +346,7 @@ h4 { line-height:24px; width:100%; float:left; - background: url('/images/CaseStudy_huawei_banner4.jpg'); + background: url('/images/case-studies/huawei/banner4.jpg'); } .banner5 { @@ -439,6 +439,6 @@ h4 { } .banner1 { - background: url('/images/CaseStudy_blablacar_banner1_mobile.jpg'); + background: url('/images/case-studies/blablacar/banner1_mobile.jpg'); } } diff --git a/static/css/style_peardeck.css b/static/css/style_peardeck.css index 610dc29b85..0ec3a55bef 100644 --- a/static/css/style_peardeck.css +++ b/static/css/style_peardeck.css @@ -44,7 +44,7 @@ h1 { padding-bottom:0.5%; padding-left:10%; font-size:32px; - background: url('/images/CaseStudy_peardeck_banner3.jpg'); + background: url('/images/case-studies/peardeck/banner3.jpg'); background-size:100% auto; background-repeat:no-repeat; } @@ -74,7 +74,7 @@ h1 { font-size:21px; letter-spacing:0.03em; line-height:32px; - background: url('/images/CaseStudy_peardeck_banner1.jpg'); + background: url('/images/case-studies/peardeck/banner1.jpg'); background-size:100% auto; } @@ -87,7 +87,7 @@ h1 { font-size:21px; letter-spacing:0.03em; line-height:32px; - background: url('/images/CaseStudy_peardeck_banner2.jpg'); + background: url('/images/case-studies/peardeck/banner2.jpg'); background-size:100% auto; } @@ -294,7 +294,7 @@ h4 { padding-bottom:2%; padding-left:10%; font-size:18px; - background: url('/images/CaseStudy_peardeck_banner1.jpg'); + background: url('/images/case-studies/peardeck/banner1.jpg'); background-size:100% auto; } @@ -327,7 +327,7 @@ h4 { padding-left:15%; padding-right:10%; float:left; - background: url('/images/CaseStudy_peardeck_banner3.jpg'); + background: url('/images/case-studies/peardeck/banner3.jpg'); } .banner4 { @@ -341,7 +341,7 @@ h4 { line-height:24px; width:100%; float:left; - background: url('/images/CaseStudy_peardeck_banner2.jpg'); + background: url('/images/case-studies/peardeck/banner2.jpg'); } .banner5 { diff --git a/static/css/style_user_journeys.css b/static/css/style_user_journeys.css deleted file mode 100644 index aa21c87851..0000000000 --- a/static/css/style_user_journeys.css +++ /dev/null @@ -1,848 +0,0 @@ -@font-face { - font-family: 'Material Icons'; - font-style: normal; - font-weight: 400; - src: url(iconfont/MaterialIcons-Regular.eot); /* For IE6-8 */ - src: local('Material Icons'), - local('MaterialIcons-Regular'), - url('../fonts/MaterialIcons-Regular.eot?#iefix') format('embedded-opentype'), /* IE6-IE8 */ - url('../fonts/MaterialIcons-Regular.woff2') format('woff2'), /* Super Modern Browsers */ - url('../fonts/MaterialIcons-Regular.woff') format('woff'), /* Modern Browsers */ - url('../fonts/MaterialIcons-Regular.svg#MaterialIcons-Regular') format('svg'), /* Legacy iOS */ - url('../fonts/MaterialIcons-Regular.ttf') format('truetype'); /* Safari, Android, iOS */ -} - -.material-icons { - font-family: 'Material Icons'; - font-weight: normal; - font-style: normal; - font-size: 24px; /* Preferred icon size */ - display: inline-block; - line-height: 1; - text-transform: none; - letter-spacing: normal; - word-wrap: normal; - white-space: nowrap; - direction: ltr; - - /* Support for all WebKit browsers. */ - -webkit-font-smoothing: antialiased; - /* Support for Safari and Chrome. */ - text-rendering: optimizeLegibility; - - /* Support for Firefox. */ - -moz-osx-font-smoothing: grayscale; - - /* Support for IE. */ - font-feature-settings: 'liga'; -} - -body { - margin:0 auto; -} - -.infobarWrapper a { - color:#303030; -} - -#encyclopedia { - padding: 0px !important; -} - -span .editthispage { - display: -webkit-inline-box !important; -} - -.editthispage { - display: -webkit-inline-box !important; -} - -h1 { - padding-top: 3% !important; - padding-bottom: 1.5% !important; - padding-left: 3% !important; - padding-right: 3% !important; - text-align: center !important; - font-size: 22pt !important; - font-weight:normal; - color:#303030; -} - -.container { - width:80%; -} - -.issue-button-container { - width: 75%; - margin-left: 15%; - padding-left: 1.5%; - padding-bottom: 2%; -} - -.anchor { - display: block; - position: relative; - top: -50px; - visibility: hidden; -} - -.pages a { - font-family: 'roboto'; - font-size:11pt; - text-decoration:none !important; - letter-spacing:0.03em; - color:#606060; -} - -.pages a:hover{ - color:black; -} - -.docstitle a{ - font-family: 'roboto'; - font-size:16pt; - margin-bottom:50px !important; - color:#3371e3 !important; - text-decoration:none !important; -} - -.docstitle { - margin-bottom:10px !important; -} - -.emphasize-box { - background-color: #dde1e4; - margin: 2% 10%; - padding-top: 20px; - padding-bottom: 5px; -} - -.emphasize-box li { - font-size: 14px !important; -} - -.browsedocs { - font-family: 'roboto' !important; - width:75%; - margin-top:2%; - margin-bottom:5%; - margin-left:15%; - line-height:2em; -} - -.browsecolumn { - float:left; - width: 33%; -} - -.browsesection { - float:left; - display:block; - width:100%; - margin:2%; -} - -.pages { - width:100%; - color:#606060 !important; -} - -.browseheader { - font-family: 'roboto'; - text-align:center; - padding:1%; - color:white !important; - font-weight:100; - font-size:18px; - text-transform:uppercase; - font-weight:400; - background-color:#303030; - letter-spacing:0.08em; - background-repeat:repeat; - background-size:contain; - background-position:center; -} - -.browseheader a{ - color:white !important; -} - -.topheader { - background-color: white !important; - color:#303030; - font-family: 'roboto'; - text-align:center; - padding:3%; - font-weight:300; - font-size:24pt; - letter-spacing:0.06em; -} - -.docssectionheaders { - background-color: #eeeeee !important; - color:#3371e3; - font-family: 'roboto'; - text-align:center; - padding: 3%; - margin: 6% 0% 2% 0%; - font-weight:300; - font-size:18pt; - letter-spacing:0.06em; -} - -.docscols { - width:100%; - float:left; -} - -.section1 { - width:100%; - float:left; -} - -.docscol1 { - background-color:#eeeeee; - padding:2%; - margin-right:2%; - width:28% !important; - display:inline-block; - float:left; -} - -.docscol2 { - background-color:#ffffff; - border:1px solid #aaaaaa; - padding:2%; - width:27% !important; - float:left; - margin-right:2%; - display:inline-block; -} - -.docscol3 { - background-color:#ffffff; - padding:1.5%; - width:27% !important; - display:inline-block; - float:right; - border:1px solid blue; -} - -.docscoltitle { - float:left; - padding-top:0; - margin-right:2%; - padding-bottom:3%; - font-size:16pt; - line-height:20pt; - font-weight:400; - color:#3371e3; -} - -.docsfullcol1 { - width:95%; - padding:2%; - margin:3%; -} - -.docsfullcol2 { - width:95%; - padding:2%; - background-color:#eeeeee; - margin:3%; -} - -.docsfullcol3 { - background-color:#ffffff; - padding:2%; - width:95%; - display:inline-block; - border:1px solid blue; - margin:3%; -} - -.docsfullcol1icon { - width:5%; - padding:2%; -} - -.docstitle2 { - padding:0%; - padding-bottom:3%; - font-size:16pt; - text-align:center; - font-weight:400; - padding-top:2%; - color:#3371e3; -} - -.docsButton { - background-color:#3371e3; - color:white; - border: 2px solid #ffffff; - -moz-border-radius: 5px; - -webkit-border-radius: 5px; - border-radius: 5px; /* future proofing */ - -khtml-border-radius: 5px; /* for old Konqueror browsers */ - border: 2px solid #ffffff; - padding:1%; - text-decoration:none; - margin:0%; -} - -.material-icons { - font-size:50pt !important; - color:#3371e3; -} - -.paths { - padding:1%; - background-color:#3371e3; - text-align:center; -} - -.display-bar { - padding:1%; - background-color:#303030; - text-align:center; - font-size:18px; - font-family: 'roboto'; - text-transform:uppercase; - text-align:center; - letter-spacing:0.1em; - color:#ffffff; -} - -.cards { - padding:3%; - width:80%; - margin-left:10%; - background-color:#ffffff; - text-align:center; - font-family: 'roboto'; - text-transform:uppercase; - text-align:center; - letter-spacing:0.1em; -} - -.cards > div { - display: none; -} - -button { - -moz-border-radius: 5px; - -webkit-border-radius: 5px; - border-radius: 5px; /* future proofing */ - -khtml-border-radius: 5px; /* for old Konqueror browsers */ - border: 2px solid #ffffff; - padding:1%; - margin:1%; - color:#ffffff; - font-family: 'roboto'; - text-transform:uppercase; - text-align:center; - letter-spacing:0.1em; - display: inline-block; -} - -.navButton { - white-space:nowrap; - -moz-border-radius: 5px; - -webkit-border-radius: 5px; - border-radius: 5px; /* future proofing */ - -khtml-border-radius: 5px; /* for old Konqueror browsers */ - border: 2px solid #ffffff; - padding:1%; - margin:1%; - color:#3371e3; - background-color:white; - font-family: 'roboto'; - text-transform:uppercase; - text-align:center; - letter-spacing:0.1em; - display: inline-block; - cursor: pointer; -} - -.navButton:active { - background-color:#3371e3; - color:white; - border: 2px solid #ffffff; -} - -.navButton:visited { - background-color:#3371e3; - color:white; - border: 2px solid #ffffff; -} - -.navButton:focus { - background-color:#3371e3 !important; - color:white; - border: 2px solid #ffffff; -} - -.navButton:hover, .keepShow { - background-color:#3371e3; - color:white; - border: 2px solid #ffffff; -} - -.buttons { - background-color:#3371e3; - white-space:nowrap; - cursor:pointer; - -moz-border-radius: 5px; - -webkit-border-radius: 5px; - border-radius: 5px; /* future proofing */ - -khtml-border-radius: 5px; /* for old Konqueror browsers */ - border: 2px solid #ffffff; - padding: 2%; - margin:1%; - color:#ffffff; - font-family: 'roboto'; - text-transform:uppercase; - text-align:center; - letter-spacing:0.1em; - display: inline-block; - vertical-align:middle; - line-height:1.3em; -} - -.buttonoption1 { - background-color:#3371e3; - -moz-border-radius: 5px; - -webkit-border-radius: 5px; - border-radius: 5px; /* future proofing */ - -khtml-border-radius: 5px; /* for old Konqueror browsers */ - border: 2px solid #ffffff; - padding:2%; - margin:1%; - color:#ffffff; - font-family: 'roboto'; - text-transform:uppercase; - text-align:center; - letter-spacing:0.1em; - display: inline-block; - width:250px; - vertical-align:middle; -} - -.buttons:active .active{ - background-color:white; - color:#3371e3; - border: 2px solid #3371e3; -} - -.buttons:hover { - background-color:white; - color:#3371e3; - border: 2px solid #3371e3; - cursor: pointer; -} - -.buttons:target { - background-color:white; - color:#3371e3; - border: 2px solid #3371e3; -} - -.buttons:visited { - background-color:white; - color:#3371e3; - border: 2px solid #3371e3; -} - -.buttons.selected { - background-color:white; - color:#3371e3; - border: 2px solid #3371e3; -} - -/*.keepShow { - background-color:white; - color:#3371e3; - border: 2px solid white; -}*/ - -.level { - background-color:#ffffff; - -moz-border-radius: 5px; - -webkit-border-radius: 5px; - border-radius: 5px; /* future proofing */ - -khtml-border-radius: 5px; /* for old Konqueror browsers */ - border: 2px solid #303030; - padding:0%; - padding-top:3%; - margin:1%; - margin-top:4%; - color:#303030; - font-family: 'roboto'; - font-weight:100; - text-transform:none; - text-align:center; - letter-spacing:0.1em; - display: inline-block; - width:250px; cursor: pointer; - cursor: pointer; -} - -.level:hover, .level.selected { - background-color:#dddddd; - -moz-border-radius: 5px; - -webkit-border-radius: 5px; - border-radius: 5px; /* future proofing */ - -khtml-border-radius: 5px; /* for old Konqueror browsers */ - border: 2px solid #303030; - cursor: pointer; -} - -.tab1text{ - padding:5%; - color:#303030; - font-size:15px; - line-height:22px; -} - -.tabbottom { - background-color:#303030; - color:#ffffff;; - font-family:'roboto'; - width:100%; - margin:0px; - font-size:34 !important; -} - -i { - font-size:44px !important; - text-align:center; - color:#000066; -} - -.infobarWrapper { - visibility: hidden; - margin-bottom:5%; -} - -.infobar { - padding:0%; - background-color:#3371e3; - text-align:center; - -moz-border-radius: 5px; - -webkit-border-radius: 5px; - border-radius: 5px; /* future proofing */ - -khtml-border-radius: 5px; /* for old Konqueror browsers */ - border: 2px solid #ffffff; - padding:2%; - font-size:22px; - line-height:30px; - letter-spacing:0.07em; - text-transform:uppercase; - margin:3%; - font-weight:bold; - color:#ffffff; - font-family: 'roboto'; - width:70%; - margin-left:15%; - margin-bottom:3%; -} - -.whitebar { - -moz-border-radius: 5px; - -webkit-border-radius: 5px; - border-radius: 5px; /* future proofing */ - -khtml-border-radius: 5px; /* for old Konqueror browsers */ - background-color:#ffffff; - text-transform:none; - padding:3%; - letter-spacing:0.6pt; - font-size:15px; - z-index:99; - font-weight:400; - line-height:18pt; - color:#606060; - margin:1%; - text-align:left; -} - -.whitebararrow{ - float:right; - padding:3%; - font-size:15px; - z-index:99; - font-weight:100; - line-height:18pt; - color:#606060; - margin:1%; - text-align:right; -} - -.hide { - float:left; - font-size:16px; - padding-left:2%; - padding-bottom:5%; -} - -.fa { - line-height:0.7em !important; -} - -.infoicon { - float:left; - padding-bottom:2%; - padding-right:2%; - margin-bottom:10%; - color:#3371e3 !important; -} - -.numberCircle { - display:inline-block; - line-height:0px; - border-radius:5px; - border:2px solid; - font-weight:300; - font-size:24px; -} - -.numberCircle span { - display:inline-block; - padding-top:50%; padding-bottom:50%; - margin-left:12px; - margin-right:12px; -} - -.docButton { - -moz-border-radius: 5px; - -webkit-border-radius: 5px; - border-radius: 5px; /* future proofing */ - -khtml-border-radius: 5px; /* for old Konqueror browsers */ - border: 1.5px solid #3371e3; - padding:1%; - background-color:#eeeeee; - font-size:13px; - margin:.5%; - color:#3371e3; - font-family: 'roboto'; - text-transform:uppercase; - text-align:center; - letter-spacing:0.1em; - display: inline-block; -} - -.docButton:hover { - border: 1.5px solid #3371e3; - background-color:#3371e3; - font-size:13px; - color:#eeeeee; -} - -.tablebar { - text-align:center; - background-color:#eeeeee; - padding:1.5%; -} - -.aboutsection { - background-color:white; - font-family: 'roboto'; - font-weight:300 !important; - font-size:14px; - letter-spacing:0.05em; - line-height:22px; - width:70%; - margin-left:15%; - padding-bottom:5%; -} - -.aboutsection p { - font-size: 16px; - text-align:center; - font-weight:300; - line-height: 1.75em; - letter-spacing: 0.1px; - margin-bottom: 0.75em; -} - -.aboutsection a { - text-decoration: underline; - color:#3371e3; - font-weight:400; -} - -.aboutcolumn { - float:left; - width: 50%; - text-align: center; -} - -.docsection1 { - background-color:white; - font-family: 'roboto'; - font-weight:300 !important; - font-size:14px; - letter-spacing:0.05em; - line-height:22px; - width:65%; - margin-left:17%; - margin-top : 10%; - padding:4%; -} - -#persona-definition { - visibility: hidden; -} - -.about-k8s-content { - width: 100%; - float: right; -} - -.docsection1 a { - text-decoration: underline; -} - -.docsection1 p { - font-size: 16px; - font-weight:300; - line-height: 1.75em; - letter-spacing: 0.1px; - margin-bottom: 0.75em; -} - -.docsection1 li { - margin-bottom: 0.75em; - margin-left: 3em; - font-size: 16px; - font-weight:300; - line-height: 1.75em; - letter-spacing: 0.1px; -} - -.docsection1 ol li { - list-style: decimal; -} - -.docsection1 ul li { - list-style: disc; -} - -.docsection1 code { - font-family: Menlo, Monaco, Consolas, 'Courier New', monospace; - font-size: 90%; - padding: 2px 4px; - color: #c7254e; - border-radius: 4px; - background-color: #f9f2f4; -} - -.intro { - background-color:white; - font-family: 'roboto'; - padding:3%; - font-weight:100; - font-size:14px; - letter-spacing:0.05em; - line-height:22px; - width:100%; - margin-left:10%; -} - -.introtext { - float:right; - background-color:white; - font-family: 'roboto'; - padding:3%; - font-weight:100; - font-size:14px; - letter-spacing:0.05em; - line-height:22px; - width:50%; - margin-left:10%; -} - -.track { - background-color:#3371e3; - font-family: 'roboto'; - padding:1%; - color:white; - font-weight:500; - text-align:center; - text-transform:uppercase; - font-size:16px; - letter-spacing:0.05em; - line-height:22px; - width:100%; -} - -.sections { - background-color:#303030; - font-family: 'roboto'; - padding:1%; - color:white; - font-weight:500; - text-align:center; - text-transform:uppercase; - font-size:18px; - letter-spacing:0.05em; - line-height:22px; - width:100%; -} - -.quotedocs { - line-height:26pt; - font-size:16pt; -} - -table { - width: 100%; - border: 1px solid #ccc; - border-spacing: 0; - margin-top: 30px; - margin-bottom: 30px; -} - -thead, tr:nth-child(even) { - background-color: light-grey; -} - -thead { - background-color: #555; - color: white; -} - -th, td { - padding: 8px; - text-align: left; - margin: 0; - border: 1px solid #ccc; -} - -th { - font-weight: normal; -} - -@media screen and (max-width: 640px) { - - .browsecolumn { - width: 95%; - } - - .paths { - margin-top : 10%; - padding:4%; - } - - .navButton { - padding:2%; - } - - .buttons { - padding:4%; - } - - .whitebar { - padding:5%; - } -} - diff --git a/static/css/style_wink.css b/static/css/style_wink.css old mode 100755 new mode 100644 index 226426d233..9dce4c391d --- a/static/css/style_wink.css +++ b/static/css/style_wink.css @@ -40,7 +40,7 @@ h1 { padding-bottom:0.5%; padding-left:9.9%; font-size:32px; - background: url('/images/CaseStudy_wink_banner1.jpg'); + background: url('/images/case-studies/wink/banner1.jpg'); background-size:100% auto; background-repeat:no-repeat; } @@ -70,7 +70,7 @@ h1 { font-size:21px; letter-spacing:0.03em; line-height:32px; - background: url('/images/CaseStudy_wink_banner3.jpg'); + background: url('/images/case-studies/wink/banner3.jpg'); background-size:100% auto; } @@ -83,7 +83,7 @@ h1 { font-size:21px; letter-spacing:0.03em; line-height:32px; - background: url('/images/CaseStudy_wink_banner4.jpg'); + background: url('/images/case-studies/wink/banner4.jpg'); background-size:100% auto; } @@ -290,7 +290,7 @@ h4 { padding-bottom:2%; padding-left:10%; font-size:18px; - background: url('/images/CaseStudy_wink_banner1.jpg'); + background: url('/images/case-studies/wink/banner1.jpg'); background-size:100% auto; } @@ -323,7 +323,7 @@ h4 { padding-left:15%; padding-right:10%; float:left; - background: url('/images/CaseStudy_wink_banner3.jpg'); + background: url('/images/case-studies/wink/banner3.jpg'); } .banner4 { @@ -337,7 +337,7 @@ h4 { line-height:24px; width:100%; float:left; - background: url('/images/CaseStudy_wink_banner4.jpg'); + background: url('/images/case-studies/wink/banner4.jpg'); } .banner5 { diff --git a/static/css/style_zalando.css b/static/css/style_zalando.css index c962f4f76d..a7e9cd4397 100644 --- a/static/css/style_zalando.css +++ b/static/css/style_zalando.css @@ -47,7 +47,7 @@ h1 { padding-bottom:0.5%; padding-left:10%; font-size:32px; - background: url('/images/CaseStudy_zalando_banner1.jpg'); + background: url('/images/case-studies/zalando/banner1.jpg'); background-size:100% auto; background-repeat:no-repeat; } @@ -78,7 +78,7 @@ h1 { font-size:24px; letter-spacing:0.03em; line-height:34px; - background: url('/images/CaseStudy_zalando_banner3.jpg'); + background: url('/images/case-studies/zalando/banner3.jpg'); background-size:100% auto; } @@ -91,7 +91,7 @@ h1 { font-size:24px; letter-spacing:0.03em; line-height:34px; - background: url('/images/CaseStudy_zalando_banner4.jpg'); + background: url('/images/case-studies/zalando/banner4.jpg'); background-size:100% auto; } @@ -302,7 +302,7 @@ h4 { padding-bottom:2%; padding-left:10%; font-size:18px; - background: url('/images/CaseStudy_zalando_banner1.jpg'); + background: url('/images/case-studies/zalando/banner1.jpg'); background-size:100% auto; } @@ -332,7 +332,7 @@ h4 { line-height:23px; width:90%; float:left; - background: url('/images/CaseStudy_zalando_banner3.jpg'); + background: url('/images/case-studies/zalando/banner3.jpg'); } .banner4 { @@ -346,7 +346,7 @@ h4 { line-height:24px; width:100%; float:left; - background: url('/images/CaseStudy_zalando_banner4.jpg'); + background: url('/images/case-studies/zalando/banner4.jpg'); } .banner5 { diff --git a/static/docs/reference/generated/kubectl/stylesheet.css b/static/docs/reference/generated/kubectl/stylesheet.css index 6077c67a9e..f16bcac9c3 100644 --- a/static/docs/reference/generated/kubectl/stylesheet.css +++ b/static/docs/reference/generated/kubectl/stylesheet.css @@ -296,11 +296,7 @@ hr { clear: both; } - .body-content > h3, .body-content > h4, .body-content > h5, .body-content > h6, .body-content > p, .body-content > ul > li, .body-content > ul > li { - width: 52%; - } - - .body-content table { + .body-content > * { width: 52%; } diff --git a/static/docs/reference/generated/kubernetes-api/v1.18/index.html b/static/docs/reference/generated/kubernetes-api/v1.18/index.html index f02d6cc8c6..9186045c54 100644 --- a/static/docs/reference/generated/kubernetes-api/v1.18/index.html +++ b/static/docs/reference/generated/kubernetes-api/v1.18/index.html @@ -4,9 +4,9 @@ <META charset="UTF-8"> <TITLE>Kubernetes API Reference Docs - - - + + +
@@ -47944,10 +47944,10 @@ The contents of the target Secret's Data field will be presented in a volume
- - + + - + diff --git a/static/example-templates/example-tutorial-template.md b/static/example-templates/example-tutorial-template.md deleted file mode 100644 index ec2b70cc8e..0000000000 --- a/static/example-templates/example-tutorial-template.md +++ /dev/null @@ -1,69 +0,0 @@ ---- -title: Example Tutorial Template -reviewers: -- chenopis -content_template: templates/tutorial ---- - -{{% capture overview %}} - -{{< note >}} -Be sure to also [create an entry in the table of contents](/docs/home/contribute/write-new-topic/#creating-an-entry-in-the-table-of-contents) for your new document. -{{< /note >}} - -This page shows how to ... - -{{% /capture %}} - -{{% capture prerequisites %}} - -* {{< include "task-tutorial-prereqs.md" >}} {{< version-check >}} -* Do this. -* Do this too. - -{{% /capture %}} - -{{% capture objectives %}} - -* Learn this. -* Build this. -* Run this. - -{{% /capture %}} - -{{% capture lessoncontent %}} - -## Building ... - -1. Do this. -1. Do this next. Possibly read this [related explanation](...). - -## Running ... - -1. Do this. -1. Do this next. - -## Understanding the code -Here's something interesting about the code you ran in the preceding steps. - -{{% /capture %}} - -{{% capture cleanup %}} - -**[Optional Section]** - -* Delete this. -* Stop this. - -{{% /capture %}} - -{{% capture whatsnext %}} - -**[Optional Section]** - -* Learn more about [Writing a New Topic](/docs/home/contribute/write-new-topic/). -* See [Using Page Templates - Tutorial template](/docs/home/contribute/page-templates/#tutorial_template) for how to use this template. - -{{% /capture %}} - - diff --git a/static/docs/reference/generated/kubernetes-api/v1.18/fonts/FontAwesome.otf b/static/fonts/FontAwesome.otf similarity index 100% rename from static/docs/reference/generated/kubernetes-api/v1.18/fonts/FontAwesome.otf rename to static/fonts/FontAwesome.otf diff --git a/static/docs/reference/generated/kubernetes-api/v1.18/fonts/fontawesome-webfont.eot b/static/fonts/fontawesome-webfont.eot similarity index 100% rename from static/docs/reference/generated/kubernetes-api/v1.18/fonts/fontawesome-webfont.eot rename to static/fonts/fontawesome-webfont.eot diff --git a/static/docs/reference/generated/kubernetes-api/v1.18/fonts/fontawesome-webfont.svg b/static/fonts/fontawesome-webfont.svg similarity index 100% rename from static/docs/reference/generated/kubernetes-api/v1.18/fonts/fontawesome-webfont.svg rename to static/fonts/fontawesome-webfont.svg diff --git a/static/docs/reference/generated/kubernetes-api/v1.18/fonts/fontawesome-webfont.ttf b/static/fonts/fontawesome-webfont.ttf similarity index 100% rename from static/docs/reference/generated/kubernetes-api/v1.18/fonts/fontawesome-webfont.ttf rename to static/fonts/fontawesome-webfont.ttf diff --git a/static/docs/reference/generated/kubernetes-api/v1.18/fonts/fontawesome-webfont.woff b/static/fonts/fontawesome-webfont.woff similarity index 100% rename from static/docs/reference/generated/kubernetes-api/v1.18/fonts/fontawesome-webfont.woff rename to static/fonts/fontawesome-webfont.woff diff --git a/static/docs/reference/generated/kubernetes-api/v1.18/fonts/fontawesome-webfont.woff2 b/static/fonts/fontawesome-webfont.woff2 similarity index 100% rename from static/docs/reference/generated/kubernetes-api/v1.18/fonts/fontawesome-webfont.woff2 rename to static/fonts/fontawesome-webfont.woff2 diff --git a/static/images/CaseStudy_adform_banner1.jpg b/static/images/case-studies/adform/banner1.jpg similarity index 100% rename from static/images/CaseStudy_adform_banner1.jpg rename to static/images/case-studies/adform/banner1.jpg diff --git a/static/images/CaseStudy_adform_banner3.jpg b/static/images/case-studies/adform/banner3.jpg similarity index 100% rename from static/images/CaseStudy_adform_banner3.jpg rename to static/images/case-studies/adform/banner3.jpg diff --git a/static/images/CaseStudy_adform_banner4.jpg b/static/images/case-studies/adform/banner4.jpg similarity index 100% rename from static/images/CaseStudy_adform_banner4.jpg rename to static/images/case-studies/adform/banner4.jpg diff --git a/static/images/Adidas1.png b/static/images/case-studies/adidas/banner1.png similarity index 100% rename from static/images/Adidas1.png rename to static/images/case-studies/adidas/banner1.png diff --git a/static/images/Adidas2.png b/static/images/case-studies/adidas/banner2.png similarity index 100% rename from static/images/Adidas2.png rename to static/images/case-studies/adidas/banner2.png diff --git a/static/images/Adidas3.png b/static/images/case-studies/adidas/banner3.png similarity index 100% rename from static/images/Adidas3.png rename to static/images/case-studies/adidas/banner3.png diff --git a/static/images/CaseStudy_amadeus_banner1.jpg b/static/images/case-studies/amadeus/banner1.jpg similarity index 100% rename from static/images/CaseStudy_amadeus_banner1.jpg rename to static/images/case-studies/amadeus/banner1.jpg diff --git a/static/images/CaseStudy_amadeus_banner_mobile.jpg b/static/images/case-studies/amadeus/banner1_mobile.jpg similarity index 100% rename from static/images/CaseStudy_amadeus_banner_mobile.jpg rename to static/images/case-studies/amadeus/banner1_mobile.jpg diff --git a/static/images/CaseStudy_amadeus_banner3.jpg b/static/images/case-studies/amadeus/banner3.jpg similarity index 100% rename from static/images/CaseStudy_amadeus_banner3.jpg rename to static/images/case-studies/amadeus/banner3.jpg diff --git a/static/images/CaseStudy_amadeus_banner4.jpg b/static/images/case-studies/amadeus/banner4.jpg similarity index 100% rename from static/images/CaseStudy_amadeus_banner4.jpg rename to static/images/case-studies/amadeus/banner4.jpg diff --git a/static/images/CaseStudy_ancestry_banner1.jpg b/static/images/case-studies/ancestry/banner1.jpg similarity index 100% rename from static/images/CaseStudy_ancestry_banner1.jpg rename to static/images/case-studies/ancestry/banner1.jpg diff --git a/static/images/CaseStudy_ancestry_banner3.jpg b/static/images/case-studies/ancestry/banner3.jpg similarity index 100% rename from static/images/CaseStudy_ancestry_banner3.jpg rename to static/images/case-studies/ancestry/banner3.jpg diff --git a/static/images/CaseStudy_ancestry_banner4.jpg b/static/images/case-studies/ancestry/banner4.jpg similarity index 100% rename from static/images/CaseStudy_ancestry_banner4.jpg rename to static/images/case-studies/ancestry/banner4.jpg diff --git a/static/images/CaseStudy_antfinancial_banner1.jpg b/static/images/case-studies/antfinancial/banner1.jpg similarity index 100% rename from static/images/CaseStudy_antfinancial_banner1.jpg rename to static/images/case-studies/antfinancial/banner1.jpg diff --git a/static/images/CaseStudy_antfinancial_banner3.jpg b/static/images/case-studies/antfinancial/banner3.jpg similarity index 100% rename from static/images/CaseStudy_antfinancial_banner3.jpg rename to static/images/case-studies/antfinancial/banner3.jpg diff --git a/static/images/CaseStudy_antfinancial_banner4.jpg b/static/images/case-studies/antfinancial/banner4.jpg similarity index 100% rename from static/images/CaseStudy_antfinancial_banner4.jpg rename to static/images/case-studies/antfinancial/banner4.jpg diff --git a/static/images/CaseStudy_appdirect_banner1.jpg b/static/images/case-studies/appdirect/banner1.jpg similarity index 100% rename from static/images/CaseStudy_appdirect_banner1.jpg rename to static/images/case-studies/appdirect/banner1.jpg diff --git a/static/images/CaseStudy_appdirect_banner3.jpg b/static/images/case-studies/appdirect/banner3.jpg similarity index 100% rename from static/images/CaseStudy_appdirect_banner3.jpg rename to static/images/case-studies/appdirect/banner3.jpg diff --git a/static/images/CaseStudy_appdirect_banner4.jpg b/static/images/case-studies/appdirect/banner4.jpg similarity index 100% rename from static/images/CaseStudy_appdirect_banner4.jpg rename to static/images/case-studies/appdirect/banner4.jpg diff --git a/static/images/Babylon1.jpg b/static/images/case-studies/babylon/banner1.jpg similarity index 100% rename from static/images/Babylon1.jpg rename to static/images/case-studies/babylon/banner1.jpg diff --git a/static/images/Babylon2.jpg b/static/images/case-studies/babylon/banner2.jpg similarity index 100% rename from static/images/Babylon2.jpg rename to static/images/case-studies/babylon/banner2.jpg diff --git a/static/images/babylon4.jpg b/static/images/case-studies/babylon/banner4.jpg similarity index 100% rename from static/images/babylon4.jpg rename to static/images/case-studies/babylon/banner4.jpg diff --git a/static/images/CaseStudy_blablacar_banner1.jpg b/static/images/case-studies/blablacar/banner1.jpg similarity index 100% rename from static/images/CaseStudy_blablacar_banner1.jpg rename to static/images/case-studies/blablacar/banner1.jpg diff --git a/static/images/CaseStudy_blablacar_banner1_mobile.jpg b/static/images/case-studies/blablacar/banner1_mobile.jpg similarity index 100% rename from static/images/CaseStudy_blablacar_banner1_mobile.jpg rename to static/images/case-studies/blablacar/banner1_mobile.jpg diff --git a/static/images/CaseStudy_blablacar_banner3.jpg b/static/images/case-studies/blablacar/banner3.jpg similarity index 100% rename from static/images/CaseStudy_blablacar_banner3.jpg rename to static/images/case-studies/blablacar/banner3.jpg diff --git a/static/images/CaseStudy_blablacar_banner4.jpg b/static/images/case-studies/blablacar/banner4.jpg similarity index 100% rename from static/images/CaseStudy_blablacar_banner4.jpg rename to static/images/case-studies/blablacar/banner4.jpg diff --git a/static/images/CaseStudy_blackrock_banner1.jpg b/static/images/case-studies/blackrock/banner1.jpg similarity index 100% rename from static/images/CaseStudy_blackrock_banner1.jpg rename to static/images/case-studies/blackrock/banner1.jpg diff --git a/static/images/CaseStudy_blackrock_banner3.jpg b/static/images/case-studies/blackrock/banner3.jpg similarity index 100% rename from static/images/CaseStudy_blackrock_banner3.jpg rename to static/images/case-studies/blackrock/banner3.jpg diff --git a/static/images/CaseStudy_blackrock_banner4.jpg b/static/images/case-studies/blackrock/banner4.jpg similarity index 100% rename from static/images/CaseStudy_blackrock_banner4.jpg rename to static/images/case-studies/blackrock/banner4.jpg diff --git a/static/images/booking1.jpg b/static/images/case-studies/booking/banner1.jpg similarity index 100% rename from static/images/booking1.jpg rename to static/images/case-studies/booking/banner1.jpg diff --git a/static/images/booking2.JPG b/static/images/case-studies/booking/banner2.jpg similarity index 100% rename from static/images/booking2.JPG rename to static/images/case-studies/booking/banner2.jpg diff --git a/static/images/booking3.jpg b/static/images/case-studies/booking/banner3.jpg similarity index 100% rename from static/images/booking3.jpg rename to static/images/case-studies/booking/banner3.jpg diff --git a/static/images/BoozAllen1.png b/static/images/case-studies/booz-allen/banner1.png similarity index 100% rename from static/images/BoozAllen1.png rename to static/images/case-studies/booz-allen/banner1.png diff --git a/static/images/BoozAllen2.jpg b/static/images/case-studies/booz-allen/banner2.jpg similarity index 100% rename from static/images/BoozAllen2.jpg rename to static/images/case-studies/booz-allen/banner2.jpg diff --git a/static/images/BoozAllen4.jpg b/static/images/case-studies/booz-allen/banner4.jpg similarity index 100% rename from static/images/BoozAllen4.jpg rename to static/images/case-studies/booz-allen/banner4.jpg diff --git a/static/images/CaseStudy_bose_banner1.jpg b/static/images/case-studies/bose/banner1.jpg similarity index 100% rename from static/images/CaseStudy_bose_banner1.jpg rename to static/images/case-studies/bose/banner1.jpg diff --git a/static/images/CaseStudy_bose_banner3.jpg b/static/images/case-studies/bose/banner3.jpg similarity index 100% rename from static/images/CaseStudy_bose_banner3.jpg rename to static/images/case-studies/bose/banner3.jpg diff --git a/static/images/CaseStudy_bose_banner4.jpg b/static/images/case-studies/bose/banner4.jpg similarity index 100% rename from static/images/CaseStudy_bose_banner4.jpg rename to static/images/case-studies/bose/banner4.jpg diff --git a/static/images/CaseStudy_box_banner1.jpg b/static/images/case-studies/box/banner1.jpg similarity index 100% rename from static/images/CaseStudy_box_banner1.jpg rename to static/images/case-studies/box/banner1.jpg diff --git a/static/images/CaseStudy_box_banner3.jpg b/static/images/case-studies/box/banner3.jpg similarity index 100% rename from static/images/CaseStudy_box_banner3.jpg rename to static/images/case-studies/box/banner3.jpg diff --git a/static/images/CaseStudy_box_banner4.jpg b/static/images/case-studies/box/banner4.jpg similarity index 100% rename from static/images/CaseStudy_box_banner4.jpg rename to static/images/case-studies/box/banner4.jpg diff --git a/static/images/CaseStudy_buffer_banner1.jpg b/static/images/case-studies/buffer/banner1.jpg similarity index 100% rename from static/images/CaseStudy_buffer_banner1.jpg rename to static/images/case-studies/buffer/banner1.jpg diff --git a/static/images/CaseStudy_buffer_banner3.jpg b/static/images/case-studies/buffer/banner3.jpg similarity index 100% rename from static/images/CaseStudy_buffer_banner3.jpg rename to static/images/case-studies/buffer/banner3.jpg diff --git a/static/images/CaseStudy_buffer_banner4.jpg b/static/images/case-studies/buffer/banner4.jpg similarity index 100% rename from static/images/CaseStudy_buffer_banner4.jpg rename to static/images/case-studies/buffer/banner4.jpg diff --git a/static/images/CaseStudy_capitalone_banner1.jpg b/static/images/case-studies/capitalone/banner1.jpg similarity index 100% rename from static/images/CaseStudy_capitalone_banner1.jpg rename to static/images/case-studies/capitalone/banner1.jpg diff --git a/static/images/CaseStudy_capitalone_banner3.jpg b/static/images/case-studies/capitalone/banner3.jpg similarity index 100% rename from static/images/CaseStudy_capitalone_banner3.jpg rename to static/images/case-studies/capitalone/banner3.jpg diff --git a/static/images/CaseStudy_capitalone_banner4.jpg b/static/images/case-studies/capitalone/banner4.jpg similarity index 100% rename from static/images/CaseStudy_capitalone_banner4.jpg rename to static/images/case-studies/capitalone/banner4.jpg diff --git a/static/images/CaseStudy_cern_banner1.jpg b/static/images/case-studies/cern/banner1.jpg similarity index 100% rename from static/images/CaseStudy_cern_banner1.jpg rename to static/images/case-studies/cern/banner1.jpg diff --git a/static/images/CaseStudy_cern_banner3.jpg b/static/images/case-studies/cern/banner3.jpg similarity index 100% rename from static/images/CaseStudy_cern_banner3.jpg rename to static/images/case-studies/cern/banner3.jpg diff --git a/static/images/CaseStudy_cern_banner4.jpg b/static/images/case-studies/cern/banner4.jpg similarity index 100% rename from static/images/CaseStudy_cern_banner4.jpg rename to static/images/case-studies/cern/banner4.jpg diff --git a/static/images/CaseStudy_chinaunicom_banner1.jpg b/static/images/case-studies/chinaunicom/banner1.jpg similarity index 100% rename from static/images/CaseStudy_chinaunicom_banner1.jpg rename to static/images/case-studies/chinaunicom/banner1.jpg diff --git a/static/images/CaseStudy_chinaunicom_banner3.jpg b/static/images/case-studies/chinaunicom/banner3.jpg similarity index 100% rename from static/images/CaseStudy_chinaunicom_banner3.jpg rename to static/images/case-studies/chinaunicom/banner3.jpg diff --git a/static/images/CaseStudy_chinaunicom_banner4.jpg b/static/images/case-studies/chinaunicom/banner4.jpg similarity index 100% rename from static/images/CaseStudy_chinaunicom_banner4.jpg rename to static/images/case-studies/chinaunicom/banner4.jpg diff --git a/static/images/CaseStudy_crowdfire_banner1.jpg b/static/images/case-studies/crowdfire/banner1.jpg similarity index 100% rename from static/images/CaseStudy_crowdfire_banner1.jpg rename to static/images/case-studies/crowdfire/banner1.jpg diff --git a/static/images/CaseStudy_crowdfire_banner3.jpg b/static/images/case-studies/crowdfire/banner3.jpg similarity index 100% rename from static/images/CaseStudy_crowdfire_banner3.jpg rename to static/images/case-studies/crowdfire/banner3.jpg diff --git a/static/images/CaseStudy_crowdfire_banner4.jpg b/static/images/case-studies/crowdfire/banner4.jpg similarity index 100% rename from static/images/CaseStudy_crowdfire_banner4.jpg rename to static/images/case-studies/crowdfire/banner4.jpg diff --git a/static/images/Denso1.png b/static/images/case-studies/denso/banner1.png similarity index 100% rename from static/images/Denso1.png rename to static/images/case-studies/denso/banner1.png diff --git a/static/images/Denso2.jpg b/static/images/case-studies/denso/banner2.jpg similarity index 100% rename from static/images/Denso2.jpg rename to static/images/case-studies/denso/banner2.jpg diff --git a/static/images/Denso4.jpg b/static/images/case-studies/denso/banner4.jpg similarity index 100% rename from static/images/Denso4.jpg rename to static/images/case-studies/denso/banner4.jpg diff --git a/static/images/CaseStudy_ft_banner1.jpg b/static/images/case-studies/ft/banner1.jpg similarity index 100% rename from static/images/CaseStudy_ft_banner1.jpg rename to static/images/case-studies/ft/banner1.jpg diff --git a/static/images/CaseStudy_ft_banner3.jpg b/static/images/case-studies/ft/banner3.jpg similarity index 100% rename from static/images/CaseStudy_ft_banner3.jpg rename to static/images/case-studies/ft/banner3.jpg diff --git a/static/images/CaseStudy_ft_banner4.jpg b/static/images/case-studies/ft/banner4.jpg similarity index 100% rename from static/images/CaseStudy_ft_banner4.jpg rename to static/images/case-studies/ft/banner4.jpg diff --git a/static/images/CaseStudy_golfnow_banner1.jpg b/static/images/case-studies/golfnow/banner1.jpg similarity index 100% rename from static/images/CaseStudy_golfnow_banner1.jpg rename to static/images/case-studies/golfnow/banner1.jpg diff --git a/static/images/CaseStudy_golfnow_banner3.jpg b/static/images/case-studies/golfnow/banner3.jpg similarity index 100% rename from static/images/CaseStudy_golfnow_banner3.jpg rename to static/images/case-studies/golfnow/banner3.jpg diff --git a/static/images/CaseStudy_golfnow_banner4.jpg b/static/images/case-studies/golfnow/banner4.jpg similarity index 100% rename from static/images/CaseStudy_golfnow_banner4.jpg rename to static/images/case-studies/golfnow/banner4.jpg diff --git a/static/images/CaseStudy_haufegroup_banner1.jpg b/static/images/case-studies/haufegroup/banner1.jpg similarity index 100% rename from static/images/CaseStudy_haufegroup_banner1.jpg rename to static/images/case-studies/haufegroup/banner1.jpg diff --git a/static/images/CaseStudy_haufegroup_banner3.jpg b/static/images/case-studies/haufegroup/banner3.jpg similarity index 100% rename from static/images/CaseStudy_haufegroup_banner3.jpg rename to static/images/case-studies/haufegroup/banner3.jpg diff --git a/static/images/CaseStudy_haufegroup_banner4.jpg b/static/images/case-studies/haufegroup/banner4.jpg similarity index 100% rename from static/images/CaseStudy_haufegroup_banner4.jpg rename to static/images/case-studies/haufegroup/banner4.jpg diff --git a/static/images/CaseStudy_huawei_banner1.jpg b/static/images/case-studies/huawei/banner1.jpg similarity index 100% rename from static/images/CaseStudy_huawei_banner1.jpg rename to static/images/case-studies/huawei/banner1.jpg diff --git a/static/images/CaseStudy_huawei_banner3.jpg b/static/images/case-studies/huawei/banner3.jpg similarity index 100% rename from static/images/CaseStudy_huawei_banner3.jpg rename to static/images/case-studies/huawei/banner3.jpg diff --git a/static/images/CaseStudy_huawei_banner4.jpg b/static/images/case-studies/huawei/banner4.jpg similarity index 100% rename from static/images/CaseStudy_huawei_banner4.jpg rename to static/images/case-studies/huawei/banner4.jpg diff --git a/static/images/CaseStudy_ibm_banner1.jpg b/static/images/case-studies/ibm/banner1.jpg similarity index 100% rename from static/images/CaseStudy_ibm_banner1.jpg rename to static/images/case-studies/ibm/banner1.jpg diff --git a/static/images/CaseStudy_ibm_banner3.jpg b/static/images/case-studies/ibm/banner3.jpg similarity index 100% rename from static/images/CaseStudy_ibm_banner3.jpg rename to static/images/case-studies/ibm/banner3.jpg diff --git a/static/images/CaseStudy_ibm_banner4.jpg b/static/images/case-studies/ibm/banner4.jpg similarity index 100% rename from static/images/CaseStudy_ibm_banner4.jpg rename to static/images/case-studies/ibm/banner4.jpg diff --git a/static/images/CaseStudy_ing_banner1.jpg b/static/images/case-studies/ing/banner1.jpg similarity index 100% rename from static/images/CaseStudy_ing_banner1.jpg rename to static/images/case-studies/ing/banner1.jpg diff --git a/static/images/CaseStudy_ing_banner3.jpg b/static/images/case-studies/ing/banner3.jpg similarity index 100% rename from static/images/CaseStudy_ing_banner3.jpg rename to static/images/case-studies/ing/banner3.jpg diff --git a/static/images/CaseStudy_ing_banner4.jpg b/static/images/case-studies/ing/banner4.jpg similarity index 100% rename from static/images/CaseStudy_ing_banner4.jpg rename to static/images/case-studies/ing/banner4.jpg diff --git a/static/images/CaseStudy_jdcom_banner1.jpg b/static/images/case-studies/jdcom/banner1.jpg similarity index 100% rename from static/images/CaseStudy_jdcom_banner1.jpg rename to static/images/case-studies/jdcom/banner1.jpg diff --git a/static/images/CaseStudy_jdcom_banner3.jpg b/static/images/case-studies/jdcom/banner3.jpg similarity index 100% rename from static/images/CaseStudy_jdcom_banner3.jpg rename to static/images/case-studies/jdcom/banner3.jpg diff --git a/static/images/CaseStudy_jdcom_banner4.jpg b/static/images/case-studies/jdcom/banner4.jpg similarity index 100% rename from static/images/CaseStudy_jdcom_banner4.jpg rename to static/images/case-studies/jdcom/banner4.jpg diff --git a/static/images/CaseStudy_montreal_banner1.jpg b/static/images/case-studies/montreal/banner1.jpg similarity index 100% rename from static/images/CaseStudy_montreal_banner1.jpg rename to static/images/case-studies/montreal/banner1.jpg diff --git a/static/images/CaseStudy_montreal_banner3.jpg b/static/images/case-studies/montreal/banner3.jpg similarity index 100% rename from static/images/CaseStudy_montreal_banner3.jpg rename to static/images/case-studies/montreal/banner3.jpg diff --git a/static/images/CaseStudy_montreal_banner4.jpg b/static/images/case-studies/montreal/banner4.jpg similarity index 100% rename from static/images/CaseStudy_montreal_banner4.jpg rename to static/images/case-studies/montreal/banner4.jpg diff --git a/static/images/CaseStudy_naic_banner1.jpg b/static/images/case-studies/naic/banner1.jpg similarity index 100% rename from static/images/CaseStudy_naic_banner1.jpg rename to static/images/case-studies/naic/banner1.jpg diff --git a/static/images/CaseStudy_naic_banner3.jpg b/static/images/case-studies/naic/banner3.jpg similarity index 100% rename from static/images/CaseStudy_naic_banner3.jpg rename to static/images/case-studies/naic/banner3.jpg diff --git a/static/images/CaseStudy_naic_banner4.jpg b/static/images/case-studies/naic/banner4.jpg similarity index 100% rename from static/images/CaseStudy_naic_banner4.jpg rename to static/images/case-studies/naic/banner4.jpg diff --git a/static/images/CaseStudy_nav_banner1.jpg b/static/images/case-studies/nav/banner1.jpg similarity index 100% rename from static/images/CaseStudy_nav_banner1.jpg rename to static/images/case-studies/nav/banner1.jpg diff --git a/static/images/CaseStudy_nav_banner3.jpg b/static/images/case-studies/nav/banner3.jpg similarity index 100% rename from static/images/CaseStudy_nav_banner3.jpg rename to static/images/case-studies/nav/banner3.jpg diff --git a/static/images/CaseStudy_nav_banner4.jpg b/static/images/case-studies/nav/banner4.jpg similarity index 100% rename from static/images/CaseStudy_nav_banner4.jpg rename to static/images/case-studies/nav/banner4.jpg diff --git a/static/images/CaseStudy_nerdalize_banner1.jpg b/static/images/case-studies/nerdalize/banner1.jpg similarity index 100% rename from static/images/CaseStudy_nerdalize_banner1.jpg rename to static/images/case-studies/nerdalize/banner1.jpg diff --git a/static/images/CaseStudy_nerdalize_banner3.jpg b/static/images/case-studies/nerdalize/banner3.jpg similarity index 100% rename from static/images/CaseStudy_nerdalize_banner3.jpg rename to static/images/case-studies/nerdalize/banner3.jpg diff --git a/static/images/CaseStudy_nerdalize_banner4.jpg b/static/images/case-studies/nerdalize/banner4.jpg similarity index 100% rename from static/images/CaseStudy_nerdalize_banner4.jpg rename to static/images/case-studies/nerdalize/banner4.jpg diff --git a/static/images/CaseStudy_netease_banner1.jpg b/static/images/case-studies/netease/banner1.jpg similarity index 100% rename from static/images/CaseStudy_netease_banner1.jpg rename to static/images/case-studies/netease/banner1.jpg diff --git a/static/images/CaseStudy_netease_banner3.jpg b/static/images/case-studies/netease/banner3.jpg similarity index 100% rename from static/images/CaseStudy_netease_banner3.jpg rename to static/images/case-studies/netease/banner3.jpg diff --git a/static/images/CaseStudy_netease_banner4.jpg b/static/images/case-studies/netease/banner4.jpg similarity index 100% rename from static/images/CaseStudy_netease_banner4.jpg rename to static/images/case-studies/netease/banner4.jpg diff --git a/static/images/CaseStudy_newyorktimes_banner1.jpg b/static/images/case-studies/newyorktimes/banner1.jpg similarity index 100% rename from static/images/CaseStudy_newyorktimes_banner1.jpg rename to static/images/case-studies/newyorktimes/banner1.jpg diff --git a/static/images/CaseStudy_newyorktimes_banner3.jpg b/static/images/case-studies/newyorktimes/banner3.jpg similarity index 100% rename from static/images/CaseStudy_newyorktimes_banner3.jpg rename to static/images/case-studies/newyorktimes/banner3.jpg diff --git a/static/images/CaseStudy_newyorktimes_banner4.jpg b/static/images/case-studies/newyorktimes/banner4.jpg similarity index 100% rename from static/images/CaseStudy_newyorktimes_banner4.jpg rename to static/images/case-studies/newyorktimes/banner4.jpg diff --git a/static/images/CaseStudy_nokia_banner1.jpg b/static/images/case-studies/nokia/banner1.jpg similarity index 100% rename from static/images/CaseStudy_nokia_banner1.jpg rename to static/images/case-studies/nokia/banner1.jpg diff --git a/static/images/CaseStudy_nokia_banner3.jpg b/static/images/case-studies/nokia/banner3.jpg similarity index 100% rename from static/images/CaseStudy_nokia_banner3.jpg rename to static/images/case-studies/nokia/banner3.jpg diff --git a/static/images/CaseStudy_nokia_banner4.jpg b/static/images/case-studies/nokia/banner4.jpg similarity index 100% rename from static/images/CaseStudy_nokia_banner4.jpg rename to static/images/case-studies/nokia/banner4.jpg diff --git a/static/images/CaseStudy_nordstrom_banner1.jpg b/static/images/case-studies/nordstrom/banner1.jpg similarity index 100% rename from static/images/CaseStudy_nordstrom_banner1.jpg rename to static/images/case-studies/nordstrom/banner1.jpg diff --git a/static/images/CaseStudy_nordstrom_banner3.jpg b/static/images/case-studies/nordstrom/banner3.jpg similarity index 100% rename from static/images/CaseStudy_nordstrom_banner3.jpg rename to static/images/case-studies/nordstrom/banner3.jpg diff --git a/static/images/CaseStudy_nordstrom_banner4.jpg b/static/images/case-studies/nordstrom/banner4.jpg similarity index 100% rename from static/images/CaseStudy_nordstrom_banner4.jpg rename to static/images/case-studies/nordstrom/banner4.jpg diff --git a/static/images/CaseStudy_northwestern_banner1.jpg b/static/images/case-studies/northwestern/banner1.jpg similarity index 100% rename from static/images/CaseStudy_northwestern_banner1.jpg rename to static/images/case-studies/northwestern/banner1.jpg diff --git a/static/images/CaseStudy_northwestern_banner3.jpg b/static/images/case-studies/northwestern/banner3.jpg similarity index 100% rename from static/images/CaseStudy_northwestern_banner3.jpg rename to static/images/case-studies/northwestern/banner3.jpg diff --git a/static/images/CaseStudy_northwestern_banner4.jpg b/static/images/case-studies/northwestern/banner4.jpg similarity index 100% rename from static/images/CaseStudy_northwestern_banner4.jpg rename to static/images/case-studies/northwestern/banner4.jpg diff --git a/static/images/CaseStudy_ocado_banner1.jpg b/static/images/case-studies/ocado/banner1.jpg similarity index 100% rename from static/images/CaseStudy_ocado_banner1.jpg rename to static/images/case-studies/ocado/banner1.jpg diff --git a/static/images/CaseStudy_ocado_banner3.jpg b/static/images/case-studies/ocado/banner3.jpg similarity index 100% rename from static/images/CaseStudy_ocado_banner3.jpg rename to static/images/case-studies/ocado/banner3.jpg diff --git a/static/images/CaseStudy_ocado_banner4.jpg b/static/images/case-studies/ocado/banner4.jpg similarity index 100% rename from static/images/CaseStudy_ocado_banner4.jpg rename to static/images/case-studies/ocado/banner4.jpg diff --git a/static/images/CaseStudy_openAI_banner1.jpg b/static/images/case-studies/openAI/banner1.jpg similarity index 100% rename from static/images/CaseStudy_openAI_banner1.jpg rename to static/images/case-studies/openAI/banner1.jpg diff --git a/static/images/CaseStudy_openAI_banner3.jpg b/static/images/case-studies/openAI/banner3.jpg similarity index 100% rename from static/images/CaseStudy_openAI_banner3.jpg rename to static/images/case-studies/openAI/banner3.jpg diff --git a/static/images/CaseStudy_openAI_banner4.jpg b/static/images/case-studies/openAI/banner4.jpg similarity index 100% rename from static/images/CaseStudy_openAI_banner4.jpg rename to static/images/case-studies/openAI/banner4.jpg diff --git a/static/images/CaseStudy_peardeck_banner1.jpg b/static/images/case-studies/peardeck/banner1.jpg similarity index 100% rename from static/images/CaseStudy_peardeck_banner1.jpg rename to static/images/case-studies/peardeck/banner1.jpg diff --git a/static/images/CaseStudy_peardeck_banner2.jpg b/static/images/case-studies/peardeck/banner2.jpg similarity index 100% rename from static/images/CaseStudy_peardeck_banner2.jpg rename to static/images/case-studies/peardeck/banner2.jpg diff --git a/static/images/CaseStudy_peardeck_banner3.jpg b/static/images/case-studies/peardeck/banner3.jpg similarity index 100% rename from static/images/CaseStudy_peardeck_banner3.jpg rename to static/images/case-studies/peardeck/banner3.jpg diff --git a/static/images/CaseStudy_pearson_banner1.jpg b/static/images/case-studies/pearson/banner1.jpg similarity index 100% rename from static/images/CaseStudy_pearson_banner1.jpg rename to static/images/case-studies/pearson/banner1.jpg diff --git a/static/images/CaseStudy_pearson_banner3.jpg b/static/images/case-studies/pearson/banner3.jpg similarity index 100% rename from static/images/CaseStudy_pearson_banner3.jpg rename to static/images/case-studies/pearson/banner3.jpg diff --git a/static/images/CaseStudy_pearson_banner4.jpg b/static/images/case-studies/pearson/banner4.jpg similarity index 100% rename from static/images/CaseStudy_pearson_banner4.jpg rename to static/images/case-studies/pearson/banner4.jpg diff --git a/static/images/CaseStudy_pingcap_banner1.jpg b/static/images/case-studies/pingcap/banner1.jpg similarity index 100% rename from static/images/CaseStudy_pingcap_banner1.jpg rename to static/images/case-studies/pingcap/banner1.jpg diff --git a/static/images/CaseStudy_pingcap_banner3.jpg b/static/images/case-studies/pingcap/banner3.jpg similarity index 100% rename from static/images/CaseStudy_pingcap_banner3.jpg rename to static/images/case-studies/pingcap/banner3.jpg diff --git a/static/images/CaseStudy_pingcap_banner4.jpg b/static/images/case-studies/pingcap/banner4.jpg similarity index 100% rename from static/images/CaseStudy_pingcap_banner4.jpg rename to static/images/case-studies/pingcap/banner4.jpg diff --git a/static/images/CaseStudy_pinterest_banner1.jpg b/static/images/case-studies/pinterest/banner1.jpg similarity index 100% rename from static/images/CaseStudy_pinterest_banner1.jpg rename to static/images/case-studies/pinterest/banner1.jpg diff --git a/static/images/CaseStudy_pinterest_banner3.jpg b/static/images/case-studies/pinterest/banner3.jpg similarity index 100% rename from static/images/CaseStudy_pinterest_banner3.jpg rename to static/images/case-studies/pinterest/banner3.jpg diff --git a/static/images/CaseStudy_pinterest_banner4.jpg b/static/images/case-studies/pinterest/banner4.jpg similarity index 100% rename from static/images/CaseStudy_pinterest_banner4.jpg rename to static/images/case-studies/pinterest/banner4.jpg diff --git a/static/images/CaseStudy_prowise_banner1.jpg b/static/images/case-studies/prowise/banner1.jpg similarity index 100% rename from static/images/CaseStudy_prowise_banner1.jpg rename to static/images/case-studies/prowise/banner1.jpg diff --git a/static/images/CaseStudy_prowise_banner3.jpg b/static/images/case-studies/prowise/banner3.jpg similarity index 100% rename from static/images/CaseStudy_prowise_banner3.jpg rename to static/images/case-studies/prowise/banner3.jpg diff --git a/static/images/CaseStudy_prowise_banner4.jpg b/static/images/case-studies/prowise/banner4.jpg similarity index 100% rename from static/images/CaseStudy_prowise_banner4.jpg rename to static/images/case-studies/prowise/banner4.jpg diff --git a/static/images/CaseStudy_ricardoch_banner1.png b/static/images/case-studies/ricardoch/banner1.png similarity index 100% rename from static/images/CaseStudy_ricardoch_banner1.png rename to static/images/case-studies/ricardoch/banner1.png diff --git a/static/images/CaseStudy_ricardoch_banner3.png b/static/images/case-studies/ricardoch/banner3.png similarity index 100% rename from static/images/CaseStudy_ricardoch_banner3.png rename to static/images/case-studies/ricardoch/banner3.png diff --git a/static/images/CaseStudy_ricardoch_banner4.png b/static/images/case-studies/ricardoch/banner4.png similarity index 100% rename from static/images/CaseStudy_ricardoch_banner4.png rename to static/images/case-studies/ricardoch/banner4.png diff --git a/static/images/CaseStudy_slamtec_banner1.jpg b/static/images/case-studies/slamtec/banner1.jpg similarity index 100% rename from static/images/CaseStudy_slamtec_banner1.jpg rename to static/images/case-studies/slamtec/banner1.jpg diff --git a/static/images/CaseStudy_slamtec_banner3.jpg b/static/images/case-studies/slamtec/banner3.jpg similarity index 100% rename from static/images/CaseStudy_slamtec_banner3.jpg rename to static/images/case-studies/slamtec/banner3.jpg diff --git a/static/images/CaseStudy_slamtec_banner4.jpg b/static/images/case-studies/slamtec/banner4.jpg similarity index 100% rename from static/images/CaseStudy_slamtec_banner4.jpg rename to static/images/case-studies/slamtec/banner4.jpg diff --git a/static/images/CaseStudy_slingtv_banner1.jpg b/static/images/case-studies/slingtv/banner1.jpg similarity index 100% rename from static/images/CaseStudy_slingtv_banner1.jpg rename to static/images/case-studies/slingtv/banner1.jpg diff --git a/static/images/CaseStudy_slingtv_banner3.jpg b/static/images/case-studies/slingtv/banner3.jpg similarity index 100% rename from static/images/CaseStudy_slingtv_banner3.jpg rename to static/images/case-studies/slingtv/banner3.jpg diff --git a/static/images/CaseStudy_slingtv_banner4.jpg b/static/images/case-studies/slingtv/banner4.jpg similarity index 100% rename from static/images/CaseStudy_slingtv_banner4.jpg rename to static/images/case-studies/slingtv/banner4.jpg diff --git a/static/images/CaseStudy_sos_banner1.jpg b/static/images/case-studies/sos/banner1.jpg similarity index 100% rename from static/images/CaseStudy_sos_banner1.jpg rename to static/images/case-studies/sos/banner1.jpg diff --git a/static/images/CaseStudy_sos_banner3.jpg b/static/images/case-studies/sos/banner3.jpg similarity index 100% rename from static/images/CaseStudy_sos_banner3.jpg rename to static/images/case-studies/sos/banner3.jpg diff --git a/static/images/CaseStudy_sos_banner4.jpg b/static/images/case-studies/sos/banner4.jpg similarity index 100% rename from static/images/CaseStudy_sos_banner4.jpg rename to static/images/case-studies/sos/banner4.jpg diff --git a/static/images/CaseStudy_spotify_banner1.jpg b/static/images/case-studies/spotify/banner1.jpg similarity index 100% rename from static/images/CaseStudy_spotify_banner1.jpg rename to static/images/case-studies/spotify/banner1.jpg diff --git a/static/images/CaseStudy_spotify_banner3.jpg b/static/images/case-studies/spotify/banner3.jpg similarity index 100% rename from static/images/CaseStudy_spotify_banner3.jpg rename to static/images/case-studies/spotify/banner3.jpg diff --git a/static/images/CaseStudy_spotify_banner4.jpg b/static/images/case-studies/spotify/banner4.jpg similarity index 100% rename from static/images/CaseStudy_spotify_banner4.jpg rename to static/images/case-studies/spotify/banner4.jpg diff --git a/static/images/CaseStudy_squarespace_banner1.jpg b/static/images/case-studies/squarespace/banner1.jpg similarity index 100% rename from static/images/CaseStudy_squarespace_banner1.jpg rename to static/images/case-studies/squarespace/banner1.jpg diff --git a/static/images/CaseStudy_squarespace_banner3.jpg b/static/images/case-studies/squarespace/banner3.jpg similarity index 100% rename from static/images/CaseStudy_squarespace_banner3.jpg rename to static/images/case-studies/squarespace/banner3.jpg diff --git a/static/images/CaseStudy_squarespace_banner4.jpg b/static/images/case-studies/squarespace/banner4.jpg similarity index 100% rename from static/images/CaseStudy_squarespace_banner4.jpg rename to static/images/case-studies/squarespace/banner4.jpg diff --git a/static/images/case_studies/story.png b/static/images/case-studies/story.png similarity index 100% rename from static/images/case_studies/story.png rename to static/images/case-studies/story.png diff --git a/static/images/case_studies/story.svg b/static/images/case-studies/story.svg similarity index 100% rename from static/images/case_studies/story.svg rename to static/images/case-studies/story.svg diff --git a/static/images/CaseStudy_thredup_banner1.jpg b/static/images/case-studies/thredup/banner1.jpg similarity index 100% rename from static/images/CaseStudy_thredup_banner1.jpg rename to static/images/case-studies/thredup/banner1.jpg diff --git a/static/images/CaseStudy_thredup_banner3.jpg b/static/images/case-studies/thredup/banner3.jpg similarity index 100% rename from static/images/CaseStudy_thredup_banner3.jpg rename to static/images/case-studies/thredup/banner3.jpg diff --git a/static/images/CaseStudy_thredup_banner4.jpg b/static/images/case-studies/thredup/banner4.jpg similarity index 100% rename from static/images/CaseStudy_thredup_banner4.jpg rename to static/images/case-studies/thredup/banner4.jpg diff --git a/static/images/case_studies/video_thumb.jpg b/static/images/case-studies/video_thumb.jpg similarity index 100% rename from static/images/case_studies/video_thumb.jpg rename to static/images/case-studies/video_thumb.jpg diff --git a/static/images/case_studies/video_thumb1.png b/static/images/case-studies/video_thumb1.png similarity index 100% rename from static/images/case_studies/video_thumb1.png rename to static/images/case-studies/video_thumb1.png diff --git a/static/images/CaseStudy_vsco_banner1.jpg b/static/images/case-studies/vsco/banner1.jpg similarity index 100% rename from static/images/CaseStudy_vsco_banner1.jpg rename to static/images/case-studies/vsco/banner1.jpg diff --git a/static/images/CaseStudy_vsco_banner2.jpg b/static/images/case-studies/vsco/banner2.jpg similarity index 100% rename from static/images/CaseStudy_vsco_banner2.jpg rename to static/images/case-studies/vsco/banner2.jpg diff --git a/static/images/CaseStudy_vsco_banner4.jpg b/static/images/case-studies/vsco/banner4.jpg similarity index 100% rename from static/images/CaseStudy_vsco_banner4.jpg rename to static/images/case-studies/vsco/banner4.jpg diff --git a/static/images/CaseStudy_wink_banner1.jpg b/static/images/case-studies/wink/banner1.jpg similarity index 100% rename from static/images/CaseStudy_wink_banner1.jpg rename to static/images/case-studies/wink/banner1.jpg diff --git a/static/images/CaseStudy_wink_banner3.jpg b/static/images/case-studies/wink/banner3.jpg similarity index 100% rename from static/images/CaseStudy_wink_banner3.jpg rename to static/images/case-studies/wink/banner3.jpg diff --git a/static/images/CaseStudy_wink_banner4.jpg b/static/images/case-studies/wink/banner4.jpg similarity index 100% rename from static/images/CaseStudy_wink_banner4.jpg rename to static/images/case-studies/wink/banner4.jpg diff --git a/static/images/case_studies/wmc.png b/static/images/case-studies/wmc.png similarity index 100% rename from static/images/case_studies/wmc.png rename to static/images/case-studies/wmc.png diff --git a/static/images/CaseStudy_woorank_banner1.jpg b/static/images/case-studies/woorank/banner1.jpg similarity index 100% rename from static/images/CaseStudy_woorank_banner1.jpg rename to static/images/case-studies/woorank/banner1.jpg diff --git a/static/images/CaseStudy_woorank_banner3.jpg b/static/images/case-studies/woorank/banner3.jpg similarity index 100% rename from static/images/CaseStudy_woorank_banner3.jpg rename to static/images/case-studies/woorank/banner3.jpg diff --git a/static/images/CaseStudy_woorank_banner4.jpg b/static/images/case-studies/woorank/banner4.jpg similarity index 100% rename from static/images/CaseStudy_woorank_banner4.jpg rename to static/images/case-studies/woorank/banner4.jpg diff --git a/static/images/CaseStudy_workiva_banner1.jpg b/static/images/case-studies/workiva/banner1.jpg similarity index 100% rename from static/images/CaseStudy_workiva_banner1.jpg rename to static/images/case-studies/workiva/banner1.jpg diff --git a/static/images/CaseStudy_workiva_banner3.jpg b/static/images/case-studies/workiva/banner3.jpg similarity index 100% rename from static/images/CaseStudy_workiva_banner3.jpg rename to static/images/case-studies/workiva/banner3.jpg diff --git a/static/images/CaseStudy_workiva_banner4.jpg b/static/images/case-studies/workiva/banner4.jpg similarity index 100% rename from static/images/CaseStudy_workiva_banner4.jpg rename to static/images/case-studies/workiva/banner4.jpg diff --git a/static/images/case_studies/yahoojapan.png b/static/images/case-studies/yahoojapan.png similarity index 100% rename from static/images/case_studies/yahoojapan.png rename to static/images/case-studies/yahoojapan.png diff --git a/static/images/CaseStudy_ygrene_banner1.jpg b/static/images/case-studies/ygrene/banner1.jpg similarity index 100% rename from static/images/CaseStudy_ygrene_banner1.jpg rename to static/images/case-studies/ygrene/banner1.jpg diff --git a/static/images/CaseStudy_ygrene_banner3.jpg b/static/images/case-studies/ygrene/banner3.jpg similarity index 100% rename from static/images/CaseStudy_ygrene_banner3.jpg rename to static/images/case-studies/ygrene/banner3.jpg diff --git a/static/images/CaseStudy_ygrene_banner4.jpg b/static/images/case-studies/ygrene/banner4.jpg similarity index 100% rename from static/images/CaseStudy_ygrene_banner4.jpg rename to static/images/case-studies/ygrene/banner4.jpg diff --git a/static/images/CaseStudy_zalando_banner1.jpg b/static/images/case-studies/zalando/banner1.jpg similarity index 100% rename from static/images/CaseStudy_zalando_banner1.jpg rename to static/images/case-studies/zalando/banner1.jpg diff --git a/static/images/CaseStudy_zalando_banner3.jpg b/static/images/case-studies/zalando/banner3.jpg similarity index 100% rename from static/images/CaseStudy_zalando_banner3.jpg rename to static/images/case-studies/zalando/banner3.jpg diff --git a/static/images/CaseStudy_zalando_banner4.jpg b/static/images/case-studies/zalando/banner4.jpg similarity index 100% rename from static/images/CaseStudy_zalando_banner4.jpg rename to static/images/case-studies/zalando/banner4.jpg diff --git a/static/images/copycode.svg b/static/images/copycode.svg index 5ad51cc151..6358377eeb 100644 --- a/static/images/copycode.svg +++ b/static/images/copycode.svg @@ -1,3 +1,3 @@ - + \ No newline at end of file diff --git a/static/images/docs/sourceip-externaltrafficpolicy.svg b/static/images/docs/sourceip-externaltrafficpolicy.svg new file mode 100644 index 0000000000..eace834f71 --- /dev/null +++ b/static/images/docs/sourceip-externaltrafficpolicy.svg @@ -0,0 +1,473 @@ + +image/svg+xmlSource IP with externalTrafficPolicyServiceLoad balancerconfigurationServiceNode 2Node 1Health check of node 2returns 500Health check of node 1returns 200 diff --git a/static/images/journeys/placeholder.png b/static/images/journeys/placeholder.png deleted file mode 100644 index bc45d90bec..0000000000 Binary files a/static/images/journeys/placeholder.png and /dev/null differ diff --git a/static/images/logos/redhat_logo.png b/static/images/logos/redhat_logo.png deleted file mode 100755 index c62e9572cb..0000000000 Binary files a/static/images/logos/redhat_logo.png and /dev/null differ diff --git a/static/images/logos/soundcloud_logo.png b/static/images/logos/soundcloud_logo.png deleted file mode 100755 index 8d2ee48e92..0000000000 Binary files a/static/images/logos/soundcloud_logo.png and /dev/null differ diff --git a/static/images/logos/verizon_logo.png b/static/images/logos/verizon_logo.png deleted file mode 100755 index e4ca861a77..0000000000 Binary files a/static/images/logos/verizon_logo.png and /dev/null differ diff --git a/static/images/logos/viacom_logo.png b/static/images/logos/viacom_logo.png deleted file mode 100755 index 2aea90b1b2..0000000000 Binary files a/static/images/logos/viacom_logo.png and /dev/null differ diff --git a/static/images/logos/wepay_logo.png b/static/images/logos/wepay_logo.png deleted file mode 100755 index 3f5e91baaf..0000000000 Binary files a/static/images/logos/wepay_logo.png and /dev/null differ diff --git a/static/images/metadocs/jekyll-tags-glossary-injector.gif b/static/images/metadocs/jekyll-tags-glossary-injector.gif deleted file mode 100644 index 8392c567ef..0000000000 Binary files a/static/images/metadocs/jekyll-tags-glossary-injector.gif and /dev/null differ diff --git a/static/images/metadocs/jekyll-tags-glossary-tooltip.png b/static/images/metadocs/jekyll-tags-glossary-tooltip.png deleted file mode 100644 index f93a0efb00..0000000000 Binary files a/static/images/metadocs/jekyll-tags-glossary-tooltip.png and /dev/null differ diff --git a/static/images/square-logos/accenture.png b/static/images/square-logos/accenture.png deleted file mode 100644 index 473e6afd7e..0000000000 Binary files a/static/images/square-logos/accenture.png and /dev/null differ diff --git a/static/images/square-logos/alauda.png b/static/images/square-logos/alauda.png deleted file mode 100644 index e2a7ce35ed..0000000000 Binary files a/static/images/square-logos/alauda.png and /dev/null differ diff --git a/static/images/square-logos/alibaba.png b/static/images/square-logos/alibaba.png deleted file mode 100644 index 985a220099..0000000000 Binary files a/static/images/square-logos/alibaba.png and /dev/null differ diff --git a/static/images/square-logos/altoros.png b/static/images/square-logos/altoros.png deleted file mode 100644 index 5bcc06cb9c..0000000000 Binary files a/static/images/square-logos/altoros.png and /dev/null differ diff --git a/static/images/square-logos/aporeto.png b/static/images/square-logos/aporeto.png deleted file mode 100644 index 94e16c7e2a..0000000000 Binary files a/static/images/square-logos/aporeto.png and /dev/null differ diff --git a/static/images/square-logos/appformix.png b/static/images/square-logos/appformix.png deleted file mode 100644 index 47ad7e9722..0000000000 Binary files a/static/images/square-logos/appformix.png and /dev/null differ diff --git a/static/images/square-logos/applatix.png b/static/images/square-logos/applatix.png deleted file mode 100644 index 15a30708ca..0000000000 Binary files a/static/images/square-logos/applatix.png and /dev/null differ diff --git a/static/images/square-logos/apprenda.png b/static/images/square-logos/apprenda.png deleted file mode 100644 index 61274f1bbb..0000000000 Binary files a/static/images/square-logos/apprenda.png and /dev/null differ diff --git a/static/images/square-logos/appscode.png b/static/images/square-logos/appscode.png deleted file mode 100644 index 0bdd49f6e5..0000000000 Binary files a/static/images/square-logos/appscode.png and /dev/null differ diff --git a/static/images/square-logos/aqua.png b/static/images/square-logos/aqua.png deleted file mode 100644 index ae480d582a..0000000000 Binary files a/static/images/square-logos/aqua.png and /dev/null differ diff --git a/static/images/square-logos/asag.png b/static/images/square-logos/asag.png deleted file mode 100644 index a0eb75e61c..0000000000 Binary files a/static/images/square-logos/asag.png and /dev/null differ diff --git a/static/images/square-logos/asm.png b/static/images/square-logos/asm.png deleted file mode 100644 index c6e43aea46..0000000000 Binary files a/static/images/square-logos/asm.png and /dev/null differ diff --git a/static/images/square-logos/avinetworks.png b/static/images/square-logos/avinetworks.png deleted file mode 100644 index d4019c21e0..0000000000 Binary files a/static/images/square-logos/avinetworks.png and /dev/null differ diff --git a/static/images/square-logos/aws.png b/static/images/square-logos/aws.png deleted file mode 100644 index acff063541..0000000000 Binary files a/static/images/square-logos/aws.png and /dev/null differ diff --git a/static/images/square-logos/azure.png b/static/images/square-logos/azure.png deleted file mode 100644 index 4e13cf9317..0000000000 Binary files a/static/images/square-logos/azure.png and /dev/null differ diff --git a/static/images/square-logos/baidu.png b/static/images/square-logos/baidu.png deleted file mode 100644 index 7a95a47ed5..0000000000 Binary files a/static/images/square-logos/baidu.png and /dev/null differ diff --git a/static/images/square-logos/banzai.png b/static/images/square-logos/banzai.png deleted file mode 100644 index a736357e79..0000000000 Binary files a/static/images/square-logos/banzai.png and /dev/null differ diff --git a/static/images/square-logos/biarca.png b/static/images/square-logos/biarca.png deleted file mode 100644 index d99a06d245..0000000000 Binary files a/static/images/square-logos/biarca.png and /dev/null differ diff --git a/static/images/square-logos/bigbinary.png b/static/images/square-logos/bigbinary.png deleted file mode 100644 index f9c9d41e0d..0000000000 Binary files a/static/images/square-logos/bigbinary.png and /dev/null differ diff --git a/static/images/square-logos/bitnami.png b/static/images/square-logos/bitnami.png deleted file mode 100644 index de807faf78..0000000000 Binary files a/static/images/square-logos/bitnami.png and /dev/null differ diff --git a/static/images/square-logos/bloombase.png b/static/images/square-logos/bloombase.png deleted file mode 100644 index 00189e99df..0000000000 Binary files a/static/images/square-logos/bloombase.png and /dev/null differ diff --git a/static/images/square-logos/bluefyre.png b/static/images/square-logos/bluefyre.png deleted file mode 100644 index 6d207c0b0a..0000000000 Binary files a/static/images/square-logos/bluefyre.png and /dev/null differ diff --git a/static/images/square-logos/bocloud.png b/static/images/square-logos/bocloud.png deleted file mode 100644 index 6751ab9047..0000000000 Binary files a/static/images/square-logos/bocloud.png and /dev/null differ diff --git a/static/images/square-logos/bootkube.png b/static/images/square-logos/bootkube.png deleted file mode 100644 index 1261237b3a..0000000000 Binary files a/static/images/square-logos/bootkube.png and /dev/null differ diff --git a/static/images/square-logos/boozallenhamilton.png b/static/images/square-logos/boozallenhamilton.png deleted file mode 100644 index 23efaf41af..0000000000 Binary files a/static/images/square-logos/boozallenhamilton.png and /dev/null differ diff --git a/static/images/square-logos/ca.png b/static/images/square-logos/ca.png deleted file mode 100644 index 96089e040b..0000000000 Binary files a/static/images/square-logos/ca.png and /dev/null differ diff --git a/static/images/square-logos/caicloud.png b/static/images/square-logos/caicloud.png deleted file mode 100644 index 6c065aa954..0000000000 Binary files a/static/images/square-logos/caicloud.png and /dev/null differ diff --git a/static/images/square-logos/canonical.png b/static/images/square-logos/canonical.png deleted file mode 100644 index 680b80cde8..0000000000 Binary files a/static/images/square-logos/canonical.png and /dev/null differ diff --git a/static/images/square-logos/cascadeo.png b/static/images/square-logos/cascadeo.png deleted file mode 100644 index cc6311199e..0000000000 Binary files a/static/images/square-logos/cascadeo.png and /dev/null differ diff --git a/static/images/square-logos/cff.png b/static/images/square-logos/cff.png deleted file mode 100644 index 9fb872fefa..0000000000 Binary files a/static/images/square-logos/cff.png and /dev/null differ diff --git a/static/images/square-logos/circulo.png b/static/images/square-logos/circulo.png deleted file mode 100644 index 9108e0a144..0000000000 Binary files a/static/images/square-logos/circulo.png and /dev/null differ diff --git a/static/images/square-logos/cisco.png b/static/images/square-logos/cisco.png deleted file mode 100644 index 077e12e47f..0000000000 Binary files a/static/images/square-logos/cisco.png and /dev/null differ diff --git a/static/images/square-logos/citrix.png b/static/images/square-logos/citrix.png deleted file mode 100644 index 76a5682209..0000000000 Binary files a/static/images/square-logos/citrix.png and /dev/null differ diff --git a/static/images/square-logos/claranet.png b/static/images/square-logos/claranet.png deleted file mode 100644 index 63e208eb5b..0000000000 Binary files a/static/images/square-logos/claranet.png and /dev/null differ diff --git a/static/images/square-logos/cloudbase.png b/static/images/square-logos/cloudbase.png deleted file mode 100644 index 84acc37b3e..0000000000 Binary files a/static/images/square-logos/cloudbase.png and /dev/null differ diff --git a/static/images/square-logos/cloudbourne.png b/static/images/square-logos/cloudbourne.png deleted file mode 100644 index 89d5f24c26..0000000000 Binary files a/static/images/square-logos/cloudbourne.png and /dev/null differ diff --git a/static/images/square-logos/cloudkite.png b/static/images/square-logos/cloudkite.png deleted file mode 100644 index 7cbe6604b5..0000000000 Binary files a/static/images/square-logos/cloudkite.png and /dev/null differ diff --git a/static/images/square-logos/cloudops.png b/static/images/square-logos/cloudops.png deleted file mode 100644 index 731a0c11af..0000000000 Binary files a/static/images/square-logos/cloudops.png and /dev/null differ diff --git a/static/images/square-logos/cloudperceptions.png b/static/images/square-logos/cloudperceptions.png deleted file mode 100644 index c829e0f638..0000000000 Binary files a/static/images/square-logos/cloudperceptions.png and /dev/null differ diff --git a/static/images/square-logos/cloudplex.png b/static/images/square-logos/cloudplex.png deleted file mode 100644 index 2a34dd0aa8..0000000000 Binary files a/static/images/square-logos/cloudplex.png and /dev/null differ diff --git a/static/images/square-logos/cobe.png b/static/images/square-logos/cobe.png deleted file mode 100644 index ff42b0e1ed..0000000000 Binary files a/static/images/square-logos/cobe.png and /dev/null differ diff --git a/static/images/square-logos/cockroach_labs.png b/static/images/square-logos/cockroach_labs.png deleted file mode 100644 index 85750b1d7f..0000000000 Binary files a/static/images/square-logos/cockroach_labs.png and /dev/null differ diff --git a/static/images/square-logos/codecrux.png b/static/images/square-logos/codecrux.png deleted file mode 100644 index 9c4d62535a..0000000000 Binary files a/static/images/square-logos/codecrux.png and /dev/null differ diff --git a/static/images/square-logos/codedellemc.png b/static/images/square-logos/codedellemc.png deleted file mode 100644 index 2b428ce6cf..0000000000 Binary files a/static/images/square-logos/codedellemc.png and /dev/null differ diff --git a/static/images/square-logos/codefresh.png b/static/images/square-logos/codefresh.png deleted file mode 100644 index 844a3b2306..0000000000 Binary files a/static/images/square-logos/codefresh.png and /dev/null differ diff --git a/static/images/square-logos/componentsoft.png b/static/images/square-logos/componentsoft.png deleted file mode 100644 index a86ede2b74..0000000000 Binary files a/static/images/square-logos/componentsoft.png and /dev/null differ diff --git a/static/images/square-logos/container_solutions.png b/static/images/square-logos/container_solutions.png deleted file mode 100644 index a386cf9ab2..0000000000 Binary files a/static/images/square-logos/container_solutions.png and /dev/null differ diff --git a/static/images/square-logos/containership.png b/static/images/square-logos/containership.png deleted file mode 100644 index cb8d0365b8..0000000000 Binary files a/static/images/square-logos/containership.png and /dev/null differ diff --git a/static/images/square-logos/contino.png b/static/images/square-logos/contino.png deleted file mode 100644 index f2d42c95b0..0000000000 Binary files a/static/images/square-logos/contino.png and /dev/null differ diff --git a/static/images/square-logos/controlplane.png b/static/images/square-logos/controlplane.png deleted file mode 100644 index 2b6e1c388b..0000000000 Binary files a/static/images/square-logos/controlplane.png and /dev/null differ diff --git a/static/images/square-logos/core_os.png b/static/images/square-logos/core_os.png deleted file mode 100644 index 395c14ac2d..0000000000 Binary files a/static/images/square-logos/core_os.png and /dev/null differ diff --git a/static/images/square-logos/coreos.png b/static/images/square-logos/coreos.png deleted file mode 100644 index a0d6b069fc..0000000000 Binary files a/static/images/square-logos/coreos.png and /dev/null differ diff --git a/static/images/square-logos/coscale.png b/static/images/square-logos/coscale.png deleted file mode 100644 index dddeb17b64..0000000000 Binary files a/static/images/square-logos/coscale.png and /dev/null differ diff --git a/static/images/square-logos/creationline.png b/static/images/square-logos/creationline.png deleted file mode 100644 index df701e530f..0000000000 Binary files a/static/images/square-logos/creationline.png and /dev/null differ diff --git a/static/images/square-logos/crunchy.png b/static/images/square-logos/crunchy.png deleted file mode 100644 index 5f1e631c00..0000000000 Binary files a/static/images/square-logos/crunchy.png and /dev/null differ diff --git a/static/images/square-logos/daocloud.png b/static/images/square-logos/daocloud.png deleted file mode 100644 index c26d87882f..0000000000 Binary files a/static/images/square-logos/daocloud.png and /dev/null differ diff --git a/static/images/square-logos/datacore.png b/static/images/square-logos/datacore.png deleted file mode 100644 index 7ad5d89069..0000000000 Binary files a/static/images/square-logos/datacore.png and /dev/null differ diff --git a/static/images/square-logos/datadog.png b/static/images/square-logos/datadog.png deleted file mode 100644 index aeab0f227f..0000000000 Binary files a/static/images/square-logos/datadog.png and /dev/null differ diff --git a/static/images/square-logos/dataspine.png b/static/images/square-logos/dataspine.png deleted file mode 100644 index 95ab24a311..0000000000 Binary files a/static/images/square-logos/dataspine.png and /dev/null differ diff --git a/static/images/square-logos/datawire.png b/static/images/square-logos/datawire.png deleted file mode 100644 index 2834558b1b..0000000000 Binary files a/static/images/square-logos/datawire.png and /dev/null differ diff --git a/static/images/square-logos/datera.png b/static/images/square-logos/datera.png deleted file mode 100644 index 11b52eadb7..0000000000 Binary files a/static/images/square-logos/datera.png and /dev/null differ diff --git a/static/images/square-logos/deis.png b/static/images/square-logos/deis.png deleted file mode 100644 index 278b8a44e0..0000000000 Binary files a/static/images/square-logos/deis.png and /dev/null differ diff --git a/static/images/square-logos/devopsguru.png b/static/images/square-logos/devopsguru.png deleted file mode 100644 index 5d9f621d9b..0000000000 Binary files a/static/images/square-logos/devopsguru.png and /dev/null differ diff --git a/static/images/square-logos/diamanti.png b/static/images/square-logos/diamanti.png deleted file mode 100644 index 37f1d98998..0000000000 Binary files a/static/images/square-logos/diamanti.png and /dev/null differ diff --git a/static/images/square-logos/distelli.png b/static/images/square-logos/distelli.png deleted file mode 100644 index d31e1d4226..0000000000 Binary files a/static/images/square-logos/distelli.png and /dev/null differ diff --git a/static/images/square-logos/docker.png b/static/images/square-logos/docker.png deleted file mode 100644 index a5b69ba901..0000000000 Binary files a/static/images/square-logos/docker.png and /dev/null differ diff --git a/static/images/square-logos/easynube.png b/static/images/square-logos/easynube.png deleted file mode 100644 index 29be3e5a8d..0000000000 Binary files a/static/images/square-logos/easynube.png and /dev/null differ diff --git a/static/images/square-logos/easystack.png b/static/images/square-logos/easystack.png deleted file mode 100644 index d47f14d125..0000000000 Binary files a/static/images/square-logos/easystack.png and /dev/null differ diff --git a/static/images/square-logos/ein.png b/static/images/square-logos/ein.png deleted file mode 100644 index 144b749d1f..0000000000 Binary files a/static/images/square-logos/ein.png and /dev/null differ diff --git a/static/images/square-logos/eking.png b/static/images/square-logos/eking.png deleted file mode 100644 index 58db57e78a..0000000000 Binary files a/static/images/square-logos/eking.png and /dev/null differ diff --git a/static/images/square-logos/elastickube.png b/static/images/square-logos/elastickube.png deleted file mode 100644 index 957c55a8e6..0000000000 Binary files a/static/images/square-logos/elastickube.png and /dev/null differ diff --git a/static/images/square-logos/elastifile.png b/static/images/square-logos/elastifile.png deleted file mode 100644 index 38016cb316..0000000000 Binary files a/static/images/square-logos/elastifile.png and /dev/null differ diff --git a/static/images/square-logos/elastisys.png b/static/images/square-logos/elastisys.png deleted file mode 100644 index d74b18368c..0000000000 Binary files a/static/images/square-logos/elastisys.png and /dev/null differ diff --git a/static/images/square-logos/endocode.png b/static/images/square-logos/endocode.png deleted file mode 100644 index c12dac87ba..0000000000 Binary files a/static/images/square-logos/endocode.png and /dev/null differ diff --git a/static/images/square-logos/eta.png b/static/images/square-logos/eta.png deleted file mode 100644 index ec9ab9d5cb..0000000000 Binary files a/static/images/square-logos/eta.png and /dev/null differ diff --git a/static/images/square-logos/f5networks.png b/static/images/square-logos/f5networks.png deleted file mode 100644 index 8072fe745a..0000000000 Binary files a/static/images/square-logos/f5networks.png and /dev/null differ diff --git a/static/images/square-logos/fluentd.png b/static/images/square-logos/fluentd.png deleted file mode 100644 index 81844e68c5..0000000000 Binary files a/static/images/square-logos/fluentd.png and /dev/null differ diff --git a/static/images/square-logos/gce.png b/static/images/square-logos/gce.png deleted file mode 100644 index df147c9764..0000000000 Binary files a/static/images/square-logos/gce.png and /dev/null differ diff --git a/static/images/square-logos/gcp.png b/static/images/square-logos/gcp.png deleted file mode 100644 index 6c7ae62a5f..0000000000 Binary files a/static/images/square-logos/gcp.png and /dev/null differ diff --git a/static/images/square-logos/ghostcloud.png b/static/images/square-logos/ghostcloud.png deleted file mode 100644 index 36d6810a11..0000000000 Binary files a/static/images/square-logos/ghostcloud.png and /dev/null differ diff --git a/static/images/square-logos/giantswarm.png b/static/images/square-logos/giantswarm.png deleted file mode 100644 index 344f8f1489..0000000000 Binary files a/static/images/square-logos/giantswarm.png and /dev/null differ diff --git a/static/images/square-logos/gitlab.png b/static/images/square-logos/gitlab.png deleted file mode 100644 index c1beb23c6c..0000000000 Binary files a/static/images/square-logos/gitlab.png and /dev/null differ diff --git a/static/images/square-logos/google.png b/static/images/square-logos/google.png deleted file mode 100644 index 99eed95928..0000000000 Binary files a/static/images/square-logos/google.png and /dev/null differ diff --git a/static/images/square-logos/gopaddle.png b/static/images/square-logos/gopaddle.png deleted file mode 100644 index 144d4fb746..0000000000 Binary files a/static/images/square-logos/gopaddle.png and /dev/null differ diff --git a/static/images/square-logos/gravitational.png b/static/images/square-logos/gravitational.png deleted file mode 100644 index 141c986c48..0000000000 Binary files a/static/images/square-logos/gravitational.png and /dev/null differ diff --git a/static/images/square-logos/greenfield.png b/static/images/square-logos/greenfield.png deleted file mode 100644 index 90b2669c39..0000000000 Binary files a/static/images/square-logos/greenfield.png and /dev/null differ diff --git a/static/images/square-logos/guardicore.png b/static/images/square-logos/guardicore.png deleted file mode 100644 index b0b82839db..0000000000 Binary files a/static/images/square-logos/guardicore.png and /dev/null differ diff --git a/static/images/square-logos/harbur.png b/static/images/square-logos/harbur.png deleted file mode 100644 index ed09fe4227..0000000000 Binary files a/static/images/square-logos/harbur.png and /dev/null differ diff --git a/static/images/square-logos/harmony.png b/static/images/square-logos/harmony.png deleted file mode 100644 index a6b5dd19d6..0000000000 Binary files a/static/images/square-logos/harmony.png and /dev/null differ diff --git a/static/images/square-logos/harness.png b/static/images/square-logos/harness.png deleted file mode 100644 index 6063369d81..0000000000 Binary files a/static/images/square-logos/harness.png and /dev/null differ diff --git a/static/images/square-logos/hasura.png b/static/images/square-logos/hasura.png deleted file mode 100644 index 0b809d77b8..0000000000 Binary files a/static/images/square-logos/hasura.png and /dev/null differ diff --git a/static/images/square-logos/hedvig.png b/static/images/square-logos/hedvig.png deleted file mode 100644 index 6ef09d7c7a..0000000000 Binary files a/static/images/square-logos/hedvig.png and /dev/null differ diff --git a/static/images/square-logos/heptio.png b/static/images/square-logos/heptio.png deleted file mode 100644 index 7e7eaef5a0..0000000000 Binary files a/static/images/square-logos/heptio.png and /dev/null differ diff --git a/static/images/square-logos/hitachi.png b/static/images/square-logos/hitachi.png deleted file mode 100644 index 3e15b057df..0000000000 Binary files a/static/images/square-logos/hitachi.png and /dev/null differ diff --git a/static/images/square-logos/hpe.png b/static/images/square-logos/hpe.png deleted file mode 100644 index 5d2965a6da..0000000000 Binary files a/static/images/square-logos/hpe.png and /dev/null differ diff --git a/static/images/square-logos/huawei.png b/static/images/square-logos/huawei.png deleted file mode 100644 index c18d0aedb1..0000000000 Binary files a/static/images/square-logos/huawei.png and /dev/null differ diff --git a/static/images/square-logos/humio.png b/static/images/square-logos/humio.png deleted file mode 100644 index 8e35a8eae2..0000000000 Binary files a/static/images/square-logos/humio.png and /dev/null differ diff --git a/static/images/square-logos/ibm.png b/static/images/square-logos/ibm.png deleted file mode 100644 index ae4228e1c7..0000000000 Binary files a/static/images/square-logos/ibm.png and /dev/null differ diff --git a/static/images/square-logos/ibmcloud.png b/static/images/square-logos/ibmcloud.png deleted file mode 100644 index 58cd076aef..0000000000 Binary files a/static/images/square-logos/ibmcloud.png and /dev/null differ diff --git a/static/images/square-logos/ibmprivate.png b/static/images/square-logos/ibmprivate.png deleted file mode 100644 index d353db3239..0000000000 Binary files a/static/images/square-logos/ibmprivate.png and /dev/null differ diff --git a/static/images/square-logos/inexcco.png b/static/images/square-logos/inexcco.png deleted file mode 100644 index ee1c032e73..0000000000 Binary files a/static/images/square-logos/inexcco.png and /dev/null differ diff --git a/static/images/square-logos/infosys.png b/static/images/square-logos/infosys.png deleted file mode 100644 index d2df5b73b8..0000000000 Binary files a/static/images/square-logos/infosys.png and /dev/null differ diff --git a/static/images/square-logos/infracloud.png b/static/images/square-logos/infracloud.png deleted file mode 100644 index 0c8ed78cb5..0000000000 Binary files a/static/images/square-logos/infracloud.png and /dev/null differ diff --git a/static/images/square-logos/instana.png b/static/images/square-logos/instana.png deleted file mode 100644 index 339875e604..0000000000 Binary files a/static/images/square-logos/instana.png and /dev/null differ diff --git a/static/images/square-logos/intel.png b/static/images/square-logos/intel.png deleted file mode 100644 index 0100964f55..0000000000 Binary files a/static/images/square-logos/intel.png and /dev/null differ diff --git a/static/images/square-logos/inwinstack.png b/static/images/square-logos/inwinstack.png deleted file mode 100644 index 5a849db4da..0000000000 Binary files a/static/images/square-logos/inwinstack.png and /dev/null differ diff --git a/static/images/square-logos/isotoma.png b/static/images/square-logos/isotoma.png deleted file mode 100644 index b1ac23d905..0000000000 Binary files a/static/images/square-logos/isotoma.png and /dev/null differ diff --git a/static/images/square-logos/jetbrains.png b/static/images/square-logos/jetbrains.png deleted file mode 100644 index f9303abccd..0000000000 Binary files a/static/images/square-logos/jetbrains.png and /dev/null differ diff --git a/static/images/square-logos/jetstack.png b/static/images/square-logos/jetstack.png deleted file mode 100644 index f7b5a140a0..0000000000 Binary files a/static/images/square-logos/jetstack.png and /dev/null differ diff --git a/static/images/square-logos/jfrog.png b/static/images/square-logos/jfrog.png deleted file mode 100644 index 8812ca4084..0000000000 Binary files a/static/images/square-logos/jfrog.png and /dev/null differ diff --git a/static/images/square-logos/joyent.png b/static/images/square-logos/joyent.png deleted file mode 100644 index 706935c3bc..0000000000 Binary files a/static/images/square-logos/joyent.png and /dev/null differ diff --git a/static/images/square-logos/kasten.png b/static/images/square-logos/kasten.png deleted file mode 100644 index bd4eede5d2..0000000000 Binary files a/static/images/square-logos/kasten.png and /dev/null differ diff --git a/static/images/square-logos/kenzan.png b/static/images/square-logos/kenzan.png deleted file mode 100644 index 410be938e0..0000000000 Binary files a/static/images/square-logos/kenzan.png and /dev/null differ diff --git a/static/images/square-logos/kinvolk.png b/static/images/square-logos/kinvolk.png deleted file mode 100644 index eefda49dda..0000000000 Binary files a/static/images/square-logos/kinvolk.png and /dev/null differ diff --git a/static/images/square-logos/kismatic.png b/static/images/square-logos/kismatic.png deleted file mode 100644 index 60e3b8f889..0000000000 Binary files a/static/images/square-logos/kismatic.png and /dev/null differ diff --git a/static/images/square-logos/kloia.png b/static/images/square-logos/kloia.png deleted file mode 100644 index f65b69b09d..0000000000 Binary files a/static/images/square-logos/kloia.png and /dev/null differ diff --git a/static/images/square-logos/kong.png b/static/images/square-logos/kong.png deleted file mode 100644 index 0cd5e29c70..0000000000 Binary files a/static/images/square-logos/kong.png and /dev/null differ diff --git a/static/images/square-logos/kontena.png b/static/images/square-logos/kontena.png deleted file mode 100644 index e7a8ae6969..0000000000 Binary files a/static/images/square-logos/kontena.png and /dev/null differ diff --git a/static/images/square-logos/kraken.png b/static/images/square-logos/kraken.png deleted file mode 100644 index 24f09cbf74..0000000000 Binary files a/static/images/square-logos/kraken.png and /dev/null differ diff --git a/static/images/square-logos/kubeadm.png b/static/images/square-logos/kubeadm.png deleted file mode 100644 index 1261237b3a..0000000000 Binary files a/static/images/square-logos/kubeadm.png and /dev/null differ diff --git a/static/images/square-logos/kubermatic.png b/static/images/square-logos/kubermatic.png deleted file mode 100644 index b804ce49a7..0000000000 Binary files a/static/images/square-logos/kubermatic.png and /dev/null differ diff --git a/static/images/square-logos/kubernetic.png b/static/images/square-logos/kubernetic.png deleted file mode 100644 index e5f4265158..0000000000 Binary files a/static/images/square-logos/kubernetic.png and /dev/null differ diff --git a/static/images/square-logos/kublr.png b/static/images/square-logos/kublr.png deleted file mode 100644 index 615afa9e00..0000000000 Binary files a/static/images/square-logos/kublr.png and /dev/null differ diff --git a/static/images/square-logos/kumina.png b/static/images/square-logos/kumina.png deleted file mode 100644 index 24d18ab148..0000000000 Binary files a/static/images/square-logos/kumina.png and /dev/null differ diff --git a/static/images/square-logos/landoop.png b/static/images/square-logos/landoop.png deleted file mode 100644 index 67aa861727..0000000000 Binary files a/static/images/square-logos/landoop.png and /dev/null differ diff --git a/static/images/square-logos/lf-training.png b/static/images/square-logos/lf-training.png deleted file mode 100644 index 3d0992ddc0..0000000000 Binary files a/static/images/square-logos/lf-training.png and /dev/null differ diff --git a/static/images/square-logos/livewyer.png b/static/images/square-logos/livewyer.png deleted file mode 100644 index e49b2d55c9..0000000000 Binary files a/static/images/square-logos/livewyer.png and /dev/null differ diff --git a/static/images/square-logos/logdna.png b/static/images/square-logos/logdna.png deleted file mode 100644 index 0bc3b9a5cf..0000000000 Binary files a/static/images/square-logos/logdna.png and /dev/null differ diff --git a/static/images/square-logos/loodse.png b/static/images/square-logos/loodse.png deleted file mode 100644 index f63af1d154..0000000000 Binary files a/static/images/square-logos/loodse.png and /dev/null differ diff --git a/static/images/square-logos/lovable.png b/static/images/square-logos/lovable.png deleted file mode 100644 index 6488415d6a..0000000000 Binary files a/static/images/square-logos/lovable.png and /dev/null differ diff --git a/static/images/square-logos/lti.png b/static/images/square-logos/lti.png deleted file mode 100644 index 2a9ea5e121..0000000000 Binary files a/static/images/square-logos/lti.png and /dev/null differ diff --git a/static/images/square-logos/mashape.png b/static/images/square-logos/mashape.png deleted file mode 100644 index 05692530d2..0000000000 Binary files a/static/images/square-logos/mashape.png and /dev/null differ diff --git a/static/images/square-logos/mesosphere.png b/static/images/square-logos/mesosphere.png deleted file mode 100644 index 8c27904573..0000000000 Binary files a/static/images/square-logos/mesosphere.png and /dev/null differ diff --git a/static/images/square-logos/microsoft.png b/static/images/square-logos/microsoft.png deleted file mode 100644 index 04eac6dbb8..0000000000 Binary files a/static/images/square-logos/microsoft.png and /dev/null differ diff --git a/static/images/square-logos/mirantis.png b/static/images/square-logos/mirantis.png deleted file mode 100644 index 838fb43853..0000000000 Binary files a/static/images/square-logos/mirantis.png and /dev/null differ diff --git a/static/images/square-logos/mobilise.png b/static/images/square-logos/mobilise.png deleted file mode 100644 index 0a20f4b3bb..0000000000 Binary files a/static/images/square-logos/mobilise.png and /dev/null differ diff --git a/static/images/square-logos/naitways.png b/static/images/square-logos/naitways.png deleted file mode 100644 index 318b9c047f..0000000000 Binary files a/static/images/square-logos/naitways.png and /dev/null differ diff --git a/static/images/square-logos/nats.png b/static/images/square-logos/nats.png deleted file mode 100644 index 4dcb111683..0000000000 Binary files a/static/images/square-logos/nats.png and /dev/null differ diff --git a/static/images/square-logos/navops.png b/static/images/square-logos/navops.png deleted file mode 100644 index cce489c241..0000000000 Binary files a/static/images/square-logos/navops.png and /dev/null differ diff --git a/static/images/square-logos/nebulaworks.png b/static/images/square-logos/nebulaworks.png deleted file mode 100644 index 73711e5b2f..0000000000 Binary files a/static/images/square-logos/nebulaworks.png and /dev/null differ diff --git a/static/images/square-logos/netapp.png b/static/images/square-logos/netapp.png deleted file mode 100644 index 2df5317e8d..0000000000 Binary files a/static/images/square-logos/netapp.png and /dev/null differ diff --git a/static/images/square-logos/netease.png b/static/images/square-logos/netease.png deleted file mode 100644 index a3cab26047..0000000000 Binary files a/static/images/square-logos/netease.png and /dev/null differ diff --git a/static/images/square-logos/netsil.png b/static/images/square-logos/netsil.png deleted file mode 100644 index 633b583b13..0000000000 Binary files a/static/images/square-logos/netsil.png and /dev/null differ diff --git a/static/images/square-logos/neuvector.png b/static/images/square-logos/neuvector.png deleted file mode 100644 index 255f7c76e1..0000000000 Binary files a/static/images/square-logos/neuvector.png and /dev/null differ diff --git a/static/images/square-logos/newcontext.png b/static/images/square-logos/newcontext.png deleted file mode 100644 index 074e3e5cb9..0000000000 Binary files a/static/images/square-logos/newcontext.png and /dev/null differ diff --git a/static/images/square-logos/nirmata.png b/static/images/square-logos/nirmata.png deleted file mode 100644 index 455e7dbf16..0000000000 Binary files a/static/images/square-logos/nirmata.png and /dev/null differ diff --git a/static/images/square-logos/nttdata.png b/static/images/square-logos/nttdata.png deleted file mode 100644 index d9a9f246c7..0000000000 Binary files a/static/images/square-logos/nttdata.png and /dev/null differ diff --git a/static/images/square-logos/nuagenetworks.png b/static/images/square-logos/nuagenetworks.png deleted file mode 100644 index c84a1414a7..0000000000 Binary files a/static/images/square-logos/nuagenetworks.png and /dev/null differ diff --git a/static/images/square-logos/objectcomputing.png b/static/images/square-logos/objectcomputing.png deleted file mode 100644 index 622e6b98a6..0000000000 Binary files a/static/images/square-logos/objectcomputing.png and /dev/null differ diff --git a/static/images/square-logos/octo.png b/static/images/square-logos/octo.png deleted file mode 100644 index 5585100d2f..0000000000 Binary files a/static/images/square-logos/octo.png and /dev/null differ diff --git a/static/images/square-logos/opcito.png b/static/images/square-logos/opcito.png deleted file mode 100644 index c48ed00ec1..0000000000 Binary files a/static/images/square-logos/opcito.png and /dev/null differ diff --git a/static/images/square-logos/openebs.png b/static/images/square-logos/openebs.png deleted file mode 100644 index 5f1a9d193a..0000000000 Binary files a/static/images/square-logos/openebs.png and /dev/null differ diff --git a/static/images/square-logos/opensense.png b/static/images/square-logos/opensense.png deleted file mode 100644 index f7d0439c37..0000000000 Binary files a/static/images/square-logos/opensense.png and /dev/null differ diff --git a/static/images/square-logos/openshift.png b/static/images/square-logos/openshift.png deleted file mode 100644 index 563d13f0c8..0000000000 Binary files a/static/images/square-logos/openshift.png and /dev/null differ diff --git a/static/images/square-logos/opszero.png b/static/images/square-logos/opszero.png deleted file mode 100644 index 5640b9d61f..0000000000 Binary files a/static/images/square-logos/opszero.png and /dev/null differ diff --git a/static/images/square-logos/oracle.png b/static/images/square-logos/oracle.png deleted file mode 100644 index 68f942474d..0000000000 Binary files a/static/images/square-logos/oracle.png and /dev/null differ diff --git a/static/images/square-logos/oraclelinux.png b/static/images/square-logos/oraclelinux.png deleted file mode 100644 index 919e09bcfa..0000000000 Binary files a/static/images/square-logos/oraclelinux.png and /dev/null differ diff --git a/static/images/square-logos/outcold.png b/static/images/square-logos/outcold.png deleted file mode 100644 index c759f89f24..0000000000 Binary files a/static/images/square-logos/outcold.png and /dev/null differ diff --git a/static/images/square-logos/pivotal.png b/static/images/square-logos/pivotal.png deleted file mode 100644 index bb20cd13e6..0000000000 Binary files a/static/images/square-logos/pivotal.png and /dev/null differ diff --git a/static/images/square-logos/platform9.png b/static/images/square-logos/platform9.png deleted file mode 100644 index c44a3cd7e3..0000000000 Binary files a/static/images/square-logos/platform9.png and /dev/null differ diff --git a/static/images/square-logos/polarseven.png b/static/images/square-logos/polarseven.png deleted file mode 100644 index 21025273fb..0000000000 Binary files a/static/images/square-logos/polarseven.png and /dev/null differ diff --git a/static/images/square-logos/portworx.png b/static/images/square-logos/portworx.png deleted file mode 100644 index 917a15fcd6..0000000000 Binary files a/static/images/square-logos/portworx.png and /dev/null differ diff --git a/static/images/square-logos/poseidon.png b/static/images/square-logos/poseidon.png deleted file mode 100644 index 0711b8e3eb..0000000000 Binary files a/static/images/square-logos/poseidon.png and /dev/null differ diff --git a/static/images/square-logos/puppet.png b/static/images/square-logos/puppet.png deleted file mode 100644 index 48f1870545..0000000000 Binary files a/static/images/square-logos/puppet.png and /dev/null differ diff --git a/static/images/square-logos/pure_storage.png b/static/images/square-logos/pure_storage.png deleted file mode 100644 index da174118fc..0000000000 Binary files a/static/images/square-logos/pure_storage.png and /dev/null differ diff --git a/static/images/square-logos/qstack.png b/static/images/square-logos/qstack.png deleted file mode 100644 index 4f45038f20..0000000000 Binary files a/static/images/square-logos/qstack.png and /dev/null differ diff --git a/static/images/square-logos/rackn.png b/static/images/square-logos/rackn.png deleted file mode 100644 index 809b7f5a7b..0000000000 Binary files a/static/images/square-logos/rackn.png and /dev/null differ diff --git a/static/images/square-logos/rancher-labs.png b/static/images/square-logos/rancher-labs.png deleted file mode 100644 index 7f660ba005..0000000000 Binary files a/static/images/square-logos/rancher-labs.png and /dev/null differ diff --git a/static/images/square-logos/rancher.png b/static/images/square-logos/rancher.png deleted file mode 100644 index 585c0aadf6..0000000000 Binary files a/static/images/square-logos/rancher.png and /dev/null differ diff --git a/static/images/square-logos/reactive_ops.png b/static/images/square-logos/reactive_ops.png deleted file mode 100644 index 5d699e0194..0000000000 Binary files a/static/images/square-logos/reactive_ops.png and /dev/null differ diff --git a/static/images/square-logos/redhat.png b/static/images/square-logos/redhat.png deleted file mode 100644 index 776563d7c4..0000000000 Binary files a/static/images/square-logos/redhat.png and /dev/null differ diff --git a/static/images/square-logos/redis.png b/static/images/square-logos/redis.png deleted file mode 100644 index 98ffeef39c..0000000000 Binary files a/static/images/square-logos/redis.png and /dev/null differ diff --git a/static/images/square-logos/redzara.png b/static/images/square-logos/redzara.png deleted file mode 100644 index 4aa3b9bbbe..0000000000 Binary files a/static/images/square-logos/redzara.png and /dev/null differ diff --git a/static/images/square-logos/rxm.png b/static/images/square-logos/rxm.png deleted file mode 100644 index be800f741d..0000000000 Binary files a/static/images/square-logos/rxm.png and /dev/null differ diff --git a/static/images/square-logos/samsung_sds.png b/static/images/square-logos/samsung_sds.png deleted file mode 100644 index 2afbc1b5a0..0000000000 Binary files a/static/images/square-logos/samsung_sds.png and /dev/null differ diff --git a/static/images/square-logos/sap.png b/static/images/square-logos/sap.png deleted file mode 100644 index ad815694cd..0000000000 Binary files a/static/images/square-logos/sap.png and /dev/null differ diff --git a/static/images/square-logos/semantix.png b/static/images/square-logos/semantix.png deleted file mode 100644 index 02935f9ff4..0000000000 Binary files a/static/images/square-logos/semantix.png and /dev/null differ diff --git a/static/images/square-logos/sematext.png b/static/images/square-logos/sematext.png deleted file mode 100644 index 82e842ba5a..0000000000 Binary files a/static/images/square-logos/sematext.png and /dev/null differ diff --git a/static/images/square-logos/servian.png b/static/images/square-logos/servian.png deleted file mode 100644 index aeaaa58a21..0000000000 Binary files a/static/images/square-logos/servian.png and /dev/null differ diff --git a/static/images/square-logos/shiwaforce.png b/static/images/square-logos/shiwaforce.png deleted file mode 100644 index c0cb93c468..0000000000 Binary files a/static/images/square-logos/shiwaforce.png and /dev/null differ diff --git a/static/images/square-logos/signalfx.png b/static/images/square-logos/signalfx.png deleted file mode 100644 index 957c31c232..0000000000 Binary files a/static/images/square-logos/signalfx.png and /dev/null differ diff --git a/static/images/square-logos/skippbox.png b/static/images/square-logos/skippbox.png deleted file mode 100644 index 2ec4fa46e0..0000000000 Binary files a/static/images/square-logos/skippbox.png and /dev/null differ diff --git a/static/images/square-logos/softserve.png b/static/images/square-logos/softserve.png deleted file mode 100644 index 29047e03a3..0000000000 Binary files a/static/images/square-logos/softserve.png and /dev/null differ diff --git a/static/images/square-logos/solinea.png b/static/images/square-logos/solinea.png deleted file mode 100644 index fb44caa989..0000000000 Binary files a/static/images/square-logos/solinea.png and /dev/null differ diff --git a/static/images/square-logos/spheresoftware.png b/static/images/square-logos/spheresoftware.png deleted file mode 100644 index a336cf697e..0000000000 Binary files a/static/images/square-logos/spheresoftware.png and /dev/null differ diff --git a/static/images/square-logos/spotinst.png b/static/images/square-logos/spotinst.png deleted file mode 100644 index 14ea926d0b..0000000000 Binary files a/static/images/square-logos/spotinst.png and /dev/null differ diff --git a/static/images/square-logos/stackiq.png b/static/images/square-logos/stackiq.png deleted file mode 100644 index 6d579ccc90..0000000000 Binary files a/static/images/square-logos/stackiq.png and /dev/null differ diff --git a/static/images/square-logos/stackoverdrive.png b/static/images/square-logos/stackoverdrive.png deleted file mode 100644 index 381c5bba4a..0000000000 Binary files a/static/images/square-logos/stackoverdrive.png and /dev/null differ diff --git a/static/images/square-logos/stackpoint.png b/static/images/square-logos/stackpoint.png deleted file mode 100644 index dd2822d493..0000000000 Binary files a/static/images/square-logos/stackpoint.png and /dev/null differ diff --git a/static/images/square-logos/stackstate.png b/static/images/square-logos/stackstate.png deleted file mode 100644 index f97d9da51f..0000000000 Binary files a/static/images/square-logos/stackstate.png and /dev/null differ diff --git a/static/images/square-logos/supergiant.png b/static/images/square-logos/supergiant.png deleted file mode 100644 index 11d199f6be..0000000000 Binary files a/static/images/square-logos/supergiant.png and /dev/null differ diff --git a/static/images/square-logos/superorbital.png b/static/images/square-logos/superorbital.png deleted file mode 100644 index f28bae65c8..0000000000 Binary files a/static/images/square-logos/superorbital.png and /dev/null differ diff --git a/static/images/square-logos/suse.png b/static/images/square-logos/suse.png deleted file mode 100644 index 44439403d1..0000000000 Binary files a/static/images/square-logos/suse.png and /dev/null differ diff --git a/static/images/square-logos/sys_dig.png b/static/images/square-logos/sys_dig.png deleted file mode 100644 index eea97119fc..0000000000 Binary files a/static/images/square-logos/sys_dig.png and /dev/null differ diff --git a/static/images/square-logos/syseleven.png b/static/images/square-logos/syseleven.png deleted file mode 100644 index f23fd969d1..0000000000 Binary files a/static/images/square-logos/syseleven.png and /dev/null differ diff --git a/static/images/square-logos/tectonic.png b/static/images/square-logos/tectonic.png deleted file mode 100644 index b7fb27c1c2..0000000000 Binary files a/static/images/square-logos/tectonic.png and /dev/null differ diff --git a/static/images/square-logos/tencent.png b/static/images/square-logos/tencent.png deleted file mode 100644 index ee4e8286ee..0000000000 Binary files a/static/images/square-logos/tencent.png and /dev/null differ diff --git a/static/images/square-logos/tenxcloud.png b/static/images/square-logos/tenxcloud.png deleted file mode 100644 index d18d1e91f2..0000000000 Binary files a/static/images/square-logos/tenxcloud.png and /dev/null differ diff --git a/static/images/square-logos/tigera.png b/static/images/square-logos/tigera.png deleted file mode 100644 index 0f1d1b9c5f..0000000000 Binary files a/static/images/square-logos/tigera.png and /dev/null differ diff --git a/static/images/square-logos/treasuredata.png b/static/images/square-logos/treasuredata.png deleted file mode 100644 index 2b705ce13c..0000000000 Binary files a/static/images/square-logos/treasuredata.png and /dev/null differ diff --git a/static/images/square-logos/twistlock.png b/static/images/square-logos/twistlock.png deleted file mode 100644 index d4ebb91738..0000000000 Binary files a/static/images/square-logos/twistlock.png and /dev/null differ diff --git a/static/images/square-logos/vexxhost.png b/static/images/square-logos/vexxhost.png deleted file mode 100644 index c7060c021c..0000000000 Binary files a/static/images/square-logos/vexxhost.png and /dev/null differ diff --git a/static/images/square-logos/vmware.png b/static/images/square-logos/vmware.png deleted file mode 100644 index 703bd0ad0a..0000000000 Binary files a/static/images/square-logos/vmware.png and /dev/null differ diff --git a/static/images/square-logos/wavefront.png b/static/images/square-logos/wavefront.png deleted file mode 100644 index 31d482a1ce..0000000000 Binary files a/static/images/square-logos/wavefront.png and /dev/null differ diff --git a/static/images/square-logos/weave_works.png b/static/images/square-logos/weave_works.png deleted file mode 100644 index cc41a92701..0000000000 Binary files a/static/images/square-logos/weave_works.png and /dev/null differ diff --git a/static/images/square-logos/wercker.png b/static/images/square-logos/wercker.png deleted file mode 100644 index d8434fed90..0000000000 Binary files a/static/images/square-logos/wercker.png and /dev/null differ diff --git a/static/images/square-logos/wise2c.png b/static/images/square-logos/wise2c.png deleted file mode 100644 index 7d6182faf5..0000000000 Binary files a/static/images/square-logos/wise2c.png and /dev/null differ diff --git a/static/images/square-logos/wisecloud.png b/static/images/square-logos/wisecloud.png deleted file mode 100644 index dd7ecdc9db..0000000000 Binary files a/static/images/square-logos/wisecloud.png and /dev/null differ diff --git a/static/images/square-logos/woqutech.png b/static/images/square-logos/woqutech.png deleted file mode 100644 index d96fa45f0d..0000000000 Binary files a/static/images/square-logos/woqutech.png and /dev/null differ diff --git a/static/images/square-logos/zte.png b/static/images/square-logos/zte.png deleted file mode 100644 index b99b826b85..0000000000 Binary files a/static/images/square-logos/zte.png and /dev/null differ diff --git a/static/js/README.md b/static/js/README.md new file mode 100644 index 0000000000..943135836f --- /dev/null +++ b/static/js/README.md @@ -0,0 +1,11 @@ +# NOTE + + +This directory contains scripts files referenced by different sections of +the website. Please use caution when moving/renaming them. + +## Scripts used by API reference + +- bootstrap-4.3.1.min.js +- jquery-3.3.1.min.js (indirect dependency from bootstrap-4.3.1.min.js) +- jquery.scrollTo-2.1.2.min.js diff --git a/static/js/anchor-4.1.1.min.js b/static/js/anchor-4.1.1.min.js deleted file mode 100644 index 29a64acae6..0000000000 --- a/static/js/anchor-4.1.1.min.js +++ /dev/null @@ -1,6 +0,0 @@ -/** - * AnchorJS - v4.1.1 - 2018-07-01 - * https://github.com/bryanbraun/anchorjs - * Copyright (c) 2018 Bryan Braun; Licensed MIT - */ -!function(A,e){"use strict";"function"==typeof define&&define.amd?define([],e):"object"==typeof module&&module.exports?module.exports=e():(A.AnchorJS=e(),A.anchors=new A.AnchorJS)}(this,function(){"use strict";return function(A){function d(A){A.icon=A.hasOwnProperty("icon")?A.icon:"",A.visible=A.hasOwnProperty("visible")?A.visible:"hover",A.placement=A.hasOwnProperty("placement")?A.placement:"right",A.ariaLabel=A.hasOwnProperty("ariaLabel")?A.ariaLabel:"Anchor",A.class=A.hasOwnProperty("class")?A.class:"",A.truncate=A.hasOwnProperty("truncate")?Math.floor(A.truncate):64}function f(A){var e;if("string"==typeof A||A instanceof String)e=[].slice.call(document.querySelectorAll(A));else{if(!(Array.isArray(A)||A instanceof NodeList))throw new Error("The selector provided to AnchorJS was invalid.");e=[].slice.call(A)}return e}this.options=A||{},this.elements=[],d(this.options),this.isTouchDevice=function(){return!!("ontouchstart"in window||window.DocumentTouch&&document instanceof DocumentTouch)},this.add=function(A){var e,t,i,n,o,s,r,a,c,h,l,u=[];if(d(this.options),"touch"===(l=this.options.visible)&&(l=this.isTouchDevice()?"always":"hover"),A||(A="h2, h3, h4, h5, h6"),0===(e=f(A)).length)return this;for(function(){if(null===document.head.querySelector("style.anchorjs")){var A,e=document.createElement("style");e.className="anchorjs",e.appendChild(document.createTextNode("")),void 0===(A=document.head.querySelector('[rel="stylesheet"], style'))?document.head.appendChild(e):document.head.insertBefore(e,A),e.sheet.insertRule(" .anchorjs-link { opacity: 0; text-decoration: none; -webkit-font-smoothing: antialiased; -moz-osx-font-smoothing: grayscale; }",e.sheet.cssRules.length),e.sheet.insertRule(" *:hover > .anchorjs-link, .anchorjs-link:focus { opacity: 1; }",e.sheet.cssRules.length),e.sheet.insertRule(" [data-anchorjs-icon]::after { content: attr(data-anchorjs-icon); }",e.sheet.cssRules.length),e.sheet.insertRule(' @font-face { font-family: "anchorjs-icons"; src: url(data:n/a;base64,AAEAAAALAIAAAwAwT1MvMg8yG2cAAAE4AAAAYGNtYXDp3gC3AAABpAAAAExnYXNwAAAAEAAAA9wAAAAIZ2x5ZlQCcfwAAAH4AAABCGhlYWQHFvHyAAAAvAAAADZoaGVhBnACFwAAAPQAAAAkaG10eASAADEAAAGYAAAADGxvY2EACACEAAAB8AAAAAhtYXhwAAYAVwAAARgAAAAgbmFtZQGOH9cAAAMAAAAAunBvc3QAAwAAAAADvAAAACAAAQAAAAEAAHzE2p9fDzz1AAkEAAAAAADRecUWAAAAANQA6R8AAAAAAoACwAAAAAgAAgAAAAAAAAABAAADwP/AAAACgAAA/9MCrQABAAAAAAAAAAAAAAAAAAAAAwABAAAAAwBVAAIAAAAAAAIAAAAAAAAAAAAAAAAAAAAAAAMCQAGQAAUAAAKZAswAAACPApkCzAAAAesAMwEJAAAAAAAAAAAAAAAAAAAAARAAAAAAAAAAAAAAAAAAAAAAQAAg//0DwP/AAEADwABAAAAAAQAAAAAAAAAAAAAAIAAAAAAAAAIAAAACgAAxAAAAAwAAAAMAAAAcAAEAAwAAABwAAwABAAAAHAAEADAAAAAIAAgAAgAAACDpy//9//8AAAAg6cv//f///+EWNwADAAEAAAAAAAAAAAAAAAAACACEAAEAAAAAAAAAAAAAAAAxAAACAAQARAKAAsAAKwBUAAABIiYnJjQ3NzY2MzIWFxYUBwcGIicmNDc3NjQnJiYjIgYHBwYUFxYUBwYGIwciJicmNDc3NjIXFhQHBwYUFxYWMzI2Nzc2NCcmNDc2MhcWFAcHBgYjARQGDAUtLXoWOR8fORYtLTgKGwoKCjgaGg0gEhIgDXoaGgkJBQwHdR85Fi0tOAobCgoKOBoaDSASEiANehoaCQkKGwotLXoWOR8BMwUFLYEuehYXFxYugC44CQkKGwo4GkoaDQ0NDXoaShoKGwoFBe8XFi6ALjgJCQobCjgaShoNDQ0NehpKGgobCgoKLYEuehYXAAAADACWAAEAAAAAAAEACAAAAAEAAAAAAAIAAwAIAAEAAAAAAAMACAAAAAEAAAAAAAQACAAAAAEAAAAAAAUAAQALAAEAAAAAAAYACAAAAAMAAQQJAAEAEAAMAAMAAQQJAAIABgAcAAMAAQQJAAMAEAAMAAMAAQQJAAQAEAAMAAMAAQQJAAUAAgAiAAMAAQQJAAYAEAAMYW5jaG9yanM0MDBAAGEAbgBjAGgAbwByAGoAcwA0ADAAMABAAAAAAwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABAAH//wAP) format("truetype"); }',e.sheet.cssRules.length)}}(),t=document.querySelectorAll("[id]"),i=[].map.call(t,function(A){return A.id}),o=0;o\]\.\/\(\)\*\\\n\t\b\v]/g,"-").replace(/-{2,}/g,"-").substring(0,this.options.truncate).replace(/^-+|-+$/gm,"").toLowerCase()},this.hasAnchorJSLink=function(A){var e=A.firstChild&&-1<(" "+A.firstChild.className+" ").indexOf(" anchorjs-link "),t=A.lastChild&&-1<(" "+A.lastChild.className+" ").indexOf(" anchorjs-link ");return e||t||!1}}}); \ No newline at end of file diff --git a/static/js/custom-jekyll/tags.js b/static/js/custom-jekyll/tags.js deleted file mode 100644 index d99660ee60..0000000000 --- a/static/js/custom-jekyll/tags.js +++ /dev/null @@ -1,15 +0,0 @@ -$( document ).ready(function() { - // Shows permalink when term name is hovered over - $(".glossary-injector").each(function() { - var placeholder = $("#" + $(this).data("placeholder-id")); - var originalContent = placeholder.html(); - - var glossaryDef = $($(this).find(".injector-def")[0]).html(); - - $(this).mouseenter(function() { - placeholder.html(glossaryDef); - }).mouseleave(function(){ - placeholder.html(originalContent); - }); - }); -}); diff --git a/static/js/jquery-3.2.1.min.js b/static/js/jquery-3.2.1.min.js deleted file mode 100644 index 644d35e274..0000000000 --- a/static/js/jquery-3.2.1.min.js +++ /dev/null @@ -1,4 +0,0 @@ -/*! jQuery v3.2.1 | (c) JS Foundation and other contributors | jquery.org/license */ -!function(a,b){"use strict";"object"==typeof module&&"object"==typeof module.exports?module.exports=a.document?b(a,!0):function(a){if(!a.document)throw new Error("jQuery requires a window with a document");return b(a)}:b(a)}("undefined"!=typeof window?window:this,function(a,b){"use strict";var c=[],d=a.document,e=Object.getPrototypeOf,f=c.slice,g=c.concat,h=c.push,i=c.indexOf,j={},k=j.toString,l=j.hasOwnProperty,m=l.toString,n=m.call(Object),o={};function p(a,b){b=b||d;var c=b.createElement("script");c.text=a,b.head.appendChild(c).parentNode.removeChild(c)}var q="3.2.1",r=function(a,b){return new r.fn.init(a,b)},s=/^[\s\uFEFF\xA0]+|[\s\uFEFF\xA0]+$/g,t=/^-ms-/,u=/-([a-z])/g,v=function(a,b){return b.toUpperCase()};r.fn=r.prototype={jquery:q,constructor:r,length:0,toArray:function(){return f.call(this)},get:function(a){return null==a?f.call(this):a<0?this[a+this.length]:this[a]},pushStack:function(a){var b=r.merge(this.constructor(),a);return b.prevObject=this,b},each:function(a){return r.each(this,a)},map:function(a){return this.pushStack(r.map(this,function(b,c){return a.call(b,c,b)}))},slice:function(){return this.pushStack(f.apply(this,arguments))},first:function(){return this.eq(0)},last:function(){return this.eq(-1)},eq:function(a){var b=this.length,c=+a+(a<0?b:0);return this.pushStack(c>=0&&c0&&b-1 in a)}var x=function(a){var b,c,d,e,f,g,h,i,j,k,l,m,n,o,p,q,r,s,t,u="sizzle"+1*new Date,v=a.document,w=0,x=0,y=ha(),z=ha(),A=ha(),B=function(a,b){return a===b&&(l=!0),0},C={}.hasOwnProperty,D=[],E=D.pop,F=D.push,G=D.push,H=D.slice,I=function(a,b){for(var c=0,d=a.length;c+~]|"+K+")"+K+"*"),S=new RegExp("="+K+"*([^\\]'\"]*?)"+K+"*\\]","g"),T=new RegExp(N),U=new RegExp("^"+L+"$"),V={ID:new RegExp("^#("+L+")"),CLASS:new RegExp("^\\.("+L+")"),TAG:new RegExp("^("+L+"|[*])"),ATTR:new RegExp("^"+M),PSEUDO:new RegExp("^"+N),CHILD:new RegExp("^:(only|first|last|nth|nth-last)-(child|of-type)(?:\\("+K+"*(even|odd|(([+-]|)(\\d*)n|)"+K+"*(?:([+-]|)"+K+"*(\\d+)|))"+K+"*\\)|)","i"),bool:new RegExp("^(?:"+J+")$","i"),needsContext:new RegExp("^"+K+"*[>+~]|:(even|odd|eq|gt|lt|nth|first|last)(?:\\("+K+"*((?:-\\d)?\\d*)"+K+"*\\)|)(?=[^-]|$)","i")},W=/^(?:input|select|textarea|button)$/i,X=/^h\d$/i,Y=/^[^{]+\{\s*\[native \w/,Z=/^(?:#([\w-]+)|(\w+)|\.([\w-]+))$/,$=/[+~]/,_=new RegExp("\\\\([\\da-f]{1,6}"+K+"?|("+K+")|.)","ig"),aa=function(a,b,c){var d="0x"+b-65536;return d!==d||c?b:d<0?String.fromCharCode(d+65536):String.fromCharCode(d>>10|55296,1023&d|56320)},ba=/([\0-\x1f\x7f]|^-?\d)|^-$|[^\0-\x1f\x7f-\uFFFF\w-]/g,ca=function(a,b){return b?"\0"===a?"\ufffd":a.slice(0,-1)+"\\"+a.charCodeAt(a.length-1).toString(16)+" ":"\\"+a},da=function(){m()},ea=ta(function(a){return a.disabled===!0&&("form"in a||"label"in a)},{dir:"parentNode",next:"legend"});try{G.apply(D=H.call(v.childNodes),v.childNodes),D[v.childNodes.length].nodeType}catch(fa){G={apply:D.length?function(a,b){F.apply(a,H.call(b))}:function(a,b){var c=a.length,d=0;while(a[c++]=b[d++]);a.length=c-1}}}function ga(a,b,d,e){var f,h,j,k,l,o,r,s=b&&b.ownerDocument,w=b?b.nodeType:9;if(d=d||[],"string"!=typeof a||!a||1!==w&&9!==w&&11!==w)return d;if(!e&&((b?b.ownerDocument||b:v)!==n&&m(b),b=b||n,p)){if(11!==w&&(l=Z.exec(a)))if(f=l[1]){if(9===w){if(!(j=b.getElementById(f)))return d;if(j.id===f)return d.push(j),d}else if(s&&(j=s.getElementById(f))&&t(b,j)&&j.id===f)return d.push(j),d}else{if(l[2])return G.apply(d,b.getElementsByTagName(a)),d;if((f=l[3])&&c.getElementsByClassName&&b.getElementsByClassName)return G.apply(d,b.getElementsByClassName(f)),d}if(c.qsa&&!A[a+" "]&&(!q||!q.test(a))){if(1!==w)s=b,r=a;else if("object"!==b.nodeName.toLowerCase()){(k=b.getAttribute("id"))?k=k.replace(ba,ca):b.setAttribute("id",k=u),o=g(a),h=o.length;while(h--)o[h]="#"+k+" "+sa(o[h]);r=o.join(","),s=$.test(a)&&qa(b.parentNode)||b}if(r)try{return G.apply(d,s.querySelectorAll(r)),d}catch(x){}finally{k===u&&b.removeAttribute("id")}}}return i(a.replace(P,"$1"),b,d,e)}function ha(){var a=[];function b(c,e){return a.push(c+" ")>d.cacheLength&&delete b[a.shift()],b[c+" "]=e}return b}function ia(a){return a[u]=!0,a}function ja(a){var b=n.createElement("fieldset");try{return!!a(b)}catch(c){return!1}finally{b.parentNode&&b.parentNode.removeChild(b),b=null}}function ka(a,b){var c=a.split("|"),e=c.length;while(e--)d.attrHandle[c[e]]=b}function la(a,b){var c=b&&a,d=c&&1===a.nodeType&&1===b.nodeType&&a.sourceIndex-b.sourceIndex;if(d)return d;if(c)while(c=c.nextSibling)if(c===b)return-1;return a?1:-1}function ma(a){return function(b){var c=b.nodeName.toLowerCase();return"input"===c&&b.type===a}}function na(a){return function(b){var c=b.nodeName.toLowerCase();return("input"===c||"button"===c)&&b.type===a}}function oa(a){return function(b){return"form"in b?b.parentNode&&b.disabled===!1?"label"in b?"label"in b.parentNode?b.parentNode.disabled===a:b.disabled===a:b.isDisabled===a||b.isDisabled!==!a&&ea(b)===a:b.disabled===a:"label"in b&&b.disabled===a}}function pa(a){return ia(function(b){return b=+b,ia(function(c,d){var e,f=a([],c.length,b),g=f.length;while(g--)c[e=f[g]]&&(c[e]=!(d[e]=c[e]))})})}function qa(a){return a&&"undefined"!=typeof a.getElementsByTagName&&a}c=ga.support={},f=ga.isXML=function(a){var b=a&&(a.ownerDocument||a).documentElement;return!!b&&"HTML"!==b.nodeName},m=ga.setDocument=function(a){var b,e,g=a?a.ownerDocument||a:v;return g!==n&&9===g.nodeType&&g.documentElement?(n=g,o=n.documentElement,p=!f(n),v!==n&&(e=n.defaultView)&&e.top!==e&&(e.addEventListener?e.addEventListener("unload",da,!1):e.attachEvent&&e.attachEvent("onunload",da)),c.attributes=ja(function(a){return a.className="i",!a.getAttribute("className")}),c.getElementsByTagName=ja(function(a){return a.appendChild(n.createComment("")),!a.getElementsByTagName("*").length}),c.getElementsByClassName=Y.test(n.getElementsByClassName),c.getById=ja(function(a){return o.appendChild(a).id=u,!n.getElementsByName||!n.getElementsByName(u).length}),c.getById?(d.filter.ID=function(a){var b=a.replace(_,aa);return function(a){return a.getAttribute("id")===b}},d.find.ID=function(a,b){if("undefined"!=typeof b.getElementById&&p){var c=b.getElementById(a);return c?[c]:[]}}):(d.filter.ID=function(a){var b=a.replace(_,aa);return function(a){var c="undefined"!=typeof a.getAttributeNode&&a.getAttributeNode("id");return c&&c.value===b}},d.find.ID=function(a,b){if("undefined"!=typeof b.getElementById&&p){var c,d,e,f=b.getElementById(a);if(f){if(c=f.getAttributeNode("id"),c&&c.value===a)return[f];e=b.getElementsByName(a),d=0;while(f=e[d++])if(c=f.getAttributeNode("id"),c&&c.value===a)return[f]}return[]}}),d.find.TAG=c.getElementsByTagName?function(a,b){return"undefined"!=typeof b.getElementsByTagName?b.getElementsByTagName(a):c.qsa?b.querySelectorAll(a):void 0}:function(a,b){var c,d=[],e=0,f=b.getElementsByTagName(a);if("*"===a){while(c=f[e++])1===c.nodeType&&d.push(c);return d}return f},d.find.CLASS=c.getElementsByClassName&&function(a,b){if("undefined"!=typeof b.getElementsByClassName&&p)return b.getElementsByClassName(a)},r=[],q=[],(c.qsa=Y.test(n.querySelectorAll))&&(ja(function(a){o.appendChild(a).innerHTML="",a.querySelectorAll("[msallowcapture^='']").length&&q.push("[*^$]="+K+"*(?:''|\"\")"),a.querySelectorAll("[selected]").length||q.push("\\["+K+"*(?:value|"+J+")"),a.querySelectorAll("[id~="+u+"-]").length||q.push("~="),a.querySelectorAll(":checked").length||q.push(":checked"),a.querySelectorAll("a#"+u+"+*").length||q.push(".#.+[+~]")}),ja(function(a){a.innerHTML="";var b=n.createElement("input");b.setAttribute("type","hidden"),a.appendChild(b).setAttribute("name","D"),a.querySelectorAll("[name=d]").length&&q.push("name"+K+"*[*^$|!~]?="),2!==a.querySelectorAll(":enabled").length&&q.push(":enabled",":disabled"),o.appendChild(a).disabled=!0,2!==a.querySelectorAll(":disabled").length&&q.push(":enabled",":disabled"),a.querySelectorAll("*,:x"),q.push(",.*:")})),(c.matchesSelector=Y.test(s=o.matches||o.webkitMatchesSelector||o.mozMatchesSelector||o.oMatchesSelector||o.msMatchesSelector))&&ja(function(a){c.disconnectedMatch=s.call(a,"*"),s.call(a,"[s!='']:x"),r.push("!=",N)}),q=q.length&&new RegExp(q.join("|")),r=r.length&&new RegExp(r.join("|")),b=Y.test(o.compareDocumentPosition),t=b||Y.test(o.contains)?function(a,b){var c=9===a.nodeType?a.documentElement:a,d=b&&b.parentNode;return a===d||!(!d||1!==d.nodeType||!(c.contains?c.contains(d):a.compareDocumentPosition&&16&a.compareDocumentPosition(d)))}:function(a,b){if(b)while(b=b.parentNode)if(b===a)return!0;return!1},B=b?function(a,b){if(a===b)return l=!0,0;var d=!a.compareDocumentPosition-!b.compareDocumentPosition;return d?d:(d=(a.ownerDocument||a)===(b.ownerDocument||b)?a.compareDocumentPosition(b):1,1&d||!c.sortDetached&&b.compareDocumentPosition(a)===d?a===n||a.ownerDocument===v&&t(v,a)?-1:b===n||b.ownerDocument===v&&t(v,b)?1:k?I(k,a)-I(k,b):0:4&d?-1:1)}:function(a,b){if(a===b)return l=!0,0;var c,d=0,e=a.parentNode,f=b.parentNode,g=[a],h=[b];if(!e||!f)return a===n?-1:b===n?1:e?-1:f?1:k?I(k,a)-I(k,b):0;if(e===f)return la(a,b);c=a;while(c=c.parentNode)g.unshift(c);c=b;while(c=c.parentNode)h.unshift(c);while(g[d]===h[d])d++;return d?la(g[d],h[d]):g[d]===v?-1:h[d]===v?1:0},n):n},ga.matches=function(a,b){return ga(a,null,null,b)},ga.matchesSelector=function(a,b){if((a.ownerDocument||a)!==n&&m(a),b=b.replace(S,"='$1']"),c.matchesSelector&&p&&!A[b+" "]&&(!r||!r.test(b))&&(!q||!q.test(b)))try{var d=s.call(a,b);if(d||c.disconnectedMatch||a.document&&11!==a.document.nodeType)return d}catch(e){}return ga(b,n,null,[a]).length>0},ga.contains=function(a,b){return(a.ownerDocument||a)!==n&&m(a),t(a,b)},ga.attr=function(a,b){(a.ownerDocument||a)!==n&&m(a);var e=d.attrHandle[b.toLowerCase()],f=e&&C.call(d.attrHandle,b.toLowerCase())?e(a,b,!p):void 0;return void 0!==f?f:c.attributes||!p?a.getAttribute(b):(f=a.getAttributeNode(b))&&f.specified?f.value:null},ga.escape=function(a){return(a+"").replace(ba,ca)},ga.error=function(a){throw new Error("Syntax error, unrecognized expression: "+a)},ga.uniqueSort=function(a){var b,d=[],e=0,f=0;if(l=!c.detectDuplicates,k=!c.sortStable&&a.slice(0),a.sort(B),l){while(b=a[f++])b===a[f]&&(e=d.push(f));while(e--)a.splice(d[e],1)}return k=null,a},e=ga.getText=function(a){var b,c="",d=0,f=a.nodeType;if(f){if(1===f||9===f||11===f){if("string"==typeof a.textContent)return a.textContent;for(a=a.firstChild;a;a=a.nextSibling)c+=e(a)}else if(3===f||4===f)return a.nodeValue}else while(b=a[d++])c+=e(b);return c},d=ga.selectors={cacheLength:50,createPseudo:ia,match:V,attrHandle:{},find:{},relative:{">":{dir:"parentNode",first:!0}," ":{dir:"parentNode"},"+":{dir:"previousSibling",first:!0},"~":{dir:"previousSibling"}},preFilter:{ATTR:function(a){return a[1]=a[1].replace(_,aa),a[3]=(a[3]||a[4]||a[5]||"").replace(_,aa),"~="===a[2]&&(a[3]=" "+a[3]+" "),a.slice(0,4)},CHILD:function(a){return a[1]=a[1].toLowerCase(),"nth"===a[1].slice(0,3)?(a[3]||ga.error(a[0]),a[4]=+(a[4]?a[5]+(a[6]||1):2*("even"===a[3]||"odd"===a[3])),a[5]=+(a[7]+a[8]||"odd"===a[3])):a[3]&&ga.error(a[0]),a},PSEUDO:function(a){var b,c=!a[6]&&a[2];return V.CHILD.test(a[0])?null:(a[3]?a[2]=a[4]||a[5]||"":c&&T.test(c)&&(b=g(c,!0))&&(b=c.indexOf(")",c.length-b)-c.length)&&(a[0]=a[0].slice(0,b),a[2]=c.slice(0,b)),a.slice(0,3))}},filter:{TAG:function(a){var b=a.replace(_,aa).toLowerCase();return"*"===a?function(){return!0}:function(a){return a.nodeName&&a.nodeName.toLowerCase()===b}},CLASS:function(a){var b=y[a+" "];return b||(b=new RegExp("(^|"+K+")"+a+"("+K+"|$)"))&&y(a,function(a){return b.test("string"==typeof a.className&&a.className||"undefined"!=typeof a.getAttribute&&a.getAttribute("class")||"")})},ATTR:function(a,b,c){return function(d){var e=ga.attr(d,a);return null==e?"!="===b:!b||(e+="","="===b?e===c:"!="===b?e!==c:"^="===b?c&&0===e.indexOf(c):"*="===b?c&&e.indexOf(c)>-1:"$="===b?c&&e.slice(-c.length)===c:"~="===b?(" "+e.replace(O," ")+" ").indexOf(c)>-1:"|="===b&&(e===c||e.slice(0,c.length+1)===c+"-"))}},CHILD:function(a,b,c,d,e){var f="nth"!==a.slice(0,3),g="last"!==a.slice(-4),h="of-type"===b;return 1===d&&0===e?function(a){return!!a.parentNode}:function(b,c,i){var j,k,l,m,n,o,p=f!==g?"nextSibling":"previousSibling",q=b.parentNode,r=h&&b.nodeName.toLowerCase(),s=!i&&!h,t=!1;if(q){if(f){while(p){m=b;while(m=m[p])if(h?m.nodeName.toLowerCase()===r:1===m.nodeType)return!1;o=p="only"===a&&!o&&"nextSibling"}return!0}if(o=[g?q.firstChild:q.lastChild],g&&s){m=q,l=m[u]||(m[u]={}),k=l[m.uniqueID]||(l[m.uniqueID]={}),j=k[a]||[],n=j[0]===w&&j[1],t=n&&j[2],m=n&&q.childNodes[n];while(m=++n&&m&&m[p]||(t=n=0)||o.pop())if(1===m.nodeType&&++t&&m===b){k[a]=[w,n,t];break}}else if(s&&(m=b,l=m[u]||(m[u]={}),k=l[m.uniqueID]||(l[m.uniqueID]={}),j=k[a]||[],n=j[0]===w&&j[1],t=n),t===!1)while(m=++n&&m&&m[p]||(t=n=0)||o.pop())if((h?m.nodeName.toLowerCase()===r:1===m.nodeType)&&++t&&(s&&(l=m[u]||(m[u]={}),k=l[m.uniqueID]||(l[m.uniqueID]={}),k[a]=[w,t]),m===b))break;return t-=e,t===d||t%d===0&&t/d>=0}}},PSEUDO:function(a,b){var c,e=d.pseudos[a]||d.setFilters[a.toLowerCase()]||ga.error("unsupported pseudo: "+a);return e[u]?e(b):e.length>1?(c=[a,a,"",b],d.setFilters.hasOwnProperty(a.toLowerCase())?ia(function(a,c){var d,f=e(a,b),g=f.length;while(g--)d=I(a,f[g]),a[d]=!(c[d]=f[g])}):function(a){return e(a,0,c)}):e}},pseudos:{not:ia(function(a){var b=[],c=[],d=h(a.replace(P,"$1"));return d[u]?ia(function(a,b,c,e){var f,g=d(a,null,e,[]),h=a.length;while(h--)(f=g[h])&&(a[h]=!(b[h]=f))}):function(a,e,f){return b[0]=a,d(b,null,f,c),b[0]=null,!c.pop()}}),has:ia(function(a){return function(b){return ga(a,b).length>0}}),contains:ia(function(a){return a=a.replace(_,aa),function(b){return(b.textContent||b.innerText||e(b)).indexOf(a)>-1}}),lang:ia(function(a){return U.test(a||"")||ga.error("unsupported lang: "+a),a=a.replace(_,aa).toLowerCase(),function(b){var c;do if(c=p?b.lang:b.getAttribute("xml:lang")||b.getAttribute("lang"))return c=c.toLowerCase(),c===a||0===c.indexOf(a+"-");while((b=b.parentNode)&&1===b.nodeType);return!1}}),target:function(b){var c=a.location&&a.location.hash;return c&&c.slice(1)===b.id},root:function(a){return a===o},focus:function(a){return a===n.activeElement&&(!n.hasFocus||n.hasFocus())&&!!(a.type||a.href||~a.tabIndex)},enabled:oa(!1),disabled:oa(!0),checked:function(a){var b=a.nodeName.toLowerCase();return"input"===b&&!!a.checked||"option"===b&&!!a.selected},selected:function(a){return a.parentNode&&a.parentNode.selectedIndex,a.selected===!0},empty:function(a){for(a=a.firstChild;a;a=a.nextSibling)if(a.nodeType<6)return!1;return!0},parent:function(a){return!d.pseudos.empty(a)},header:function(a){return X.test(a.nodeName)},input:function(a){return W.test(a.nodeName)},button:function(a){var b=a.nodeName.toLowerCase();return"input"===b&&"button"===a.type||"button"===b},text:function(a){var b;return"input"===a.nodeName.toLowerCase()&&"text"===a.type&&(null==(b=a.getAttribute("type"))||"text"===b.toLowerCase())},first:pa(function(){return[0]}),last:pa(function(a,b){return[b-1]}),eq:pa(function(a,b,c){return[c<0?c+b:c]}),even:pa(function(a,b){for(var c=0;c=0;)a.push(d);return a}),gt:pa(function(a,b,c){for(var d=c<0?c+b:c;++d1?function(b,c,d){var e=a.length;while(e--)if(!a[e](b,c,d))return!1;return!0}:a[0]}function va(a,b,c){for(var d=0,e=b.length;d-1&&(f[j]=!(g[j]=l))}}else r=wa(r===g?r.splice(o,r.length):r),e?e(null,g,r,i):G.apply(g,r)})}function ya(a){for(var b,c,e,f=a.length,g=d.relative[a[0].type],h=g||d.relative[" "],i=g?1:0,k=ta(function(a){return a===b},h,!0),l=ta(function(a){return I(b,a)>-1},h,!0),m=[function(a,c,d){var e=!g&&(d||c!==j)||((b=c).nodeType?k(a,c,d):l(a,c,d));return b=null,e}];i1&&ua(m),i>1&&sa(a.slice(0,i-1).concat({value:" "===a[i-2].type?"*":""})).replace(P,"$1"),c,i0,e=a.length>0,f=function(f,g,h,i,k){var l,o,q,r=0,s="0",t=f&&[],u=[],v=j,x=f||e&&d.find.TAG("*",k),y=w+=null==v?1:Math.random()||.1,z=x.length;for(k&&(j=g===n||g||k);s!==z&&null!=(l=x[s]);s++){if(e&&l){o=0,g||l.ownerDocument===n||(m(l),h=!p);while(q=a[o++])if(q(l,g||n,h)){i.push(l);break}k&&(w=y)}c&&((l=!q&&l)&&r--,f&&t.push(l))}if(r+=s,c&&s!==r){o=0;while(q=b[o++])q(t,u,g,h);if(f){if(r>0)while(s--)t[s]||u[s]||(u[s]=E.call(i));u=wa(u)}G.apply(i,u),k&&!f&&u.length>0&&r+b.length>1&&ga.uniqueSort(i)}return k&&(w=y,j=v),t};return c?ia(f):f}return h=ga.compile=function(a,b){var c,d=[],e=[],f=A[a+" "];if(!f){b||(b=g(a)),c=b.length;while(c--)f=ya(b[c]),f[u]?d.push(f):e.push(f);f=A(a,za(e,d)),f.selector=a}return f},i=ga.select=function(a,b,c,e){var f,i,j,k,l,m="function"==typeof a&&a,n=!e&&g(a=m.selector||a);if(c=c||[],1===n.length){if(i=n[0]=n[0].slice(0),i.length>2&&"ID"===(j=i[0]).type&&9===b.nodeType&&p&&d.relative[i[1].type]){if(b=(d.find.ID(j.matches[0].replace(_,aa),b)||[])[0],!b)return c;m&&(b=b.parentNode),a=a.slice(i.shift().value.length)}f=V.needsContext.test(a)?0:i.length;while(f--){if(j=i[f],d.relative[k=j.type])break;if((l=d.find[k])&&(e=l(j.matches[0].replace(_,aa),$.test(i[0].type)&&qa(b.parentNode)||b))){if(i.splice(f,1),a=e.length&&sa(i),!a)return G.apply(c,e),c;break}}}return(m||h(a,n))(e,b,!p,c,!b||$.test(a)&&qa(b.parentNode)||b),c},c.sortStable=u.split("").sort(B).join("")===u,c.detectDuplicates=!!l,m(),c.sortDetached=ja(function(a){return 1&a.compareDocumentPosition(n.createElement("fieldset"))}),ja(function(a){return a.innerHTML="","#"===a.firstChild.getAttribute("href")})||ka("type|href|height|width",function(a,b,c){if(!c)return a.getAttribute(b,"type"===b.toLowerCase()?1:2)}),c.attributes&&ja(function(a){return a.innerHTML="",a.firstChild.setAttribute("value",""),""===a.firstChild.getAttribute("value")})||ka("value",function(a,b,c){if(!c&&"input"===a.nodeName.toLowerCase())return a.defaultValue}),ja(function(a){return null==a.getAttribute("disabled")})||ka(J,function(a,b,c){var d;if(!c)return a[b]===!0?b.toLowerCase():(d=a.getAttributeNode(b))&&d.specified?d.value:null}),ga}(a);r.find=x,r.expr=x.selectors,r.expr[":"]=r.expr.pseudos,r.uniqueSort=r.unique=x.uniqueSort,r.text=x.getText,r.isXMLDoc=x.isXML,r.contains=x.contains,r.escapeSelector=x.escape;var y=function(a,b,c){var d=[],e=void 0!==c;while((a=a[b])&&9!==a.nodeType)if(1===a.nodeType){if(e&&r(a).is(c))break;d.push(a)}return d},z=function(a,b){for(var c=[];a;a=a.nextSibling)1===a.nodeType&&a!==b&&c.push(a);return c},A=r.expr.match.needsContext;function B(a,b){return a.nodeName&&a.nodeName.toLowerCase()===b.toLowerCase()}var C=/^<([a-z][^\/\0>:\x20\t\r\n\f]*)[\x20\t\r\n\f]*\/?>(?:<\/\1>|)$/i,D=/^.[^:#\[\.,]*$/;function E(a,b,c){return r.isFunction(b)?r.grep(a,function(a,d){return!!b.call(a,d,a)!==c}):b.nodeType?r.grep(a,function(a){return a===b!==c}):"string"!=typeof b?r.grep(a,function(a){return i.call(b,a)>-1!==c}):D.test(b)?r.filter(b,a,c):(b=r.filter(b,a),r.grep(a,function(a){return i.call(b,a)>-1!==c&&1===a.nodeType}))}r.filter=function(a,b,c){var d=b[0];return c&&(a=":not("+a+")"),1===b.length&&1===d.nodeType?r.find.matchesSelector(d,a)?[d]:[]:r.find.matches(a,r.grep(b,function(a){return 1===a.nodeType}))},r.fn.extend({find:function(a){var b,c,d=this.length,e=this;if("string"!=typeof a)return this.pushStack(r(a).filter(function(){for(b=0;b1?r.uniqueSort(c):c},filter:function(a){return this.pushStack(E(this,a||[],!1))},not:function(a){return this.pushStack(E(this,a||[],!0))},is:function(a){return!!E(this,"string"==typeof a&&A.test(a)?r(a):a||[],!1).length}});var F,G=/^(?:\s*(<[\w\W]+>)[^>]*|#([\w-]+))$/,H=r.fn.init=function(a,b,c){var e,f;if(!a)return this;if(c=c||F,"string"==typeof a){if(e="<"===a[0]&&">"===a[a.length-1]&&a.length>=3?[null,a,null]:G.exec(a),!e||!e[1]&&b)return!b||b.jquery?(b||c).find(a):this.constructor(b).find(a);if(e[1]){if(b=b instanceof r?b[0]:b,r.merge(this,r.parseHTML(e[1],b&&b.nodeType?b.ownerDocument||b:d,!0)),C.test(e[1])&&r.isPlainObject(b))for(e in b)r.isFunction(this[e])?this[e](b[e]):this.attr(e,b[e]);return this}return f=d.getElementById(e[2]),f&&(this[0]=f,this.length=1),this}return a.nodeType?(this[0]=a,this.length=1,this):r.isFunction(a)?void 0!==c.ready?c.ready(a):a(r):r.makeArray(a,this)};H.prototype=r.fn,F=r(d);var I=/^(?:parents|prev(?:Until|All))/,J={children:!0,contents:!0,next:!0,prev:!0};r.fn.extend({has:function(a){var b=r(a,this),c=b.length;return this.filter(function(){for(var a=0;a-1:1===c.nodeType&&r.find.matchesSelector(c,a))){f.push(c);break}return this.pushStack(f.length>1?r.uniqueSort(f):f)},index:function(a){return a?"string"==typeof a?i.call(r(a),this[0]):i.call(this,a.jquery?a[0]:a):this[0]&&this[0].parentNode?this.first().prevAll().length:-1},add:function(a,b){return this.pushStack(r.uniqueSort(r.merge(this.get(),r(a,b))))},addBack:function(a){return this.add(null==a?this.prevObject:this.prevObject.filter(a))}});function K(a,b){while((a=a[b])&&1!==a.nodeType);return a}r.each({parent:function(a){var b=a.parentNode;return b&&11!==b.nodeType?b:null},parents:function(a){return y(a,"parentNode")},parentsUntil:function(a,b,c){return y(a,"parentNode",c)},next:function(a){return K(a,"nextSibling")},prev:function(a){return K(a,"previousSibling")},nextAll:function(a){return y(a,"nextSibling")},prevAll:function(a){return y(a,"previousSibling")},nextUntil:function(a,b,c){return y(a,"nextSibling",c)},prevUntil:function(a,b,c){return y(a,"previousSibling",c)},siblings:function(a){return z((a.parentNode||{}).firstChild,a)},children:function(a){return z(a.firstChild)},contents:function(a){return B(a,"iframe")?a.contentDocument:(B(a,"template")&&(a=a.content||a),r.merge([],a.childNodes))}},function(a,b){r.fn[a]=function(c,d){var e=r.map(this,b,c);return"Until"!==a.slice(-5)&&(d=c),d&&"string"==typeof d&&(e=r.filter(d,e)),this.length>1&&(J[a]||r.uniqueSort(e),I.test(a)&&e.reverse()),this.pushStack(e)}});var L=/[^\x20\t\r\n\f]+/g;function M(a){var b={};return r.each(a.match(L)||[],function(a,c){b[c]=!0}),b}r.Callbacks=function(a){a="string"==typeof a?M(a):r.extend({},a);var b,c,d,e,f=[],g=[],h=-1,i=function(){for(e=e||a.once,d=b=!0;g.length;h=-1){c=g.shift();while(++h-1)f.splice(c,1),c<=h&&h--}),this},has:function(a){return a?r.inArray(a,f)>-1:f.length>0},empty:function(){return f&&(f=[]),this},disable:function(){return e=g=[],f=c="",this},disabled:function(){return!f},lock:function(){return e=g=[],c||b||(f=c=""),this},locked:function(){return!!e},fireWith:function(a,c){return e||(c=c||[],c=[a,c.slice?c.slice():c],g.push(c),b||i()),this},fire:function(){return j.fireWith(this,arguments),this},fired:function(){return!!d}};return j};function N(a){return a}function O(a){throw a}function P(a,b,c,d){var e;try{a&&r.isFunction(e=a.promise)?e.call(a).done(b).fail(c):a&&r.isFunction(e=a.then)?e.call(a,b,c):b.apply(void 0,[a].slice(d))}catch(a){c.apply(void 0,[a])}}r.extend({Deferred:function(b){var c=[["notify","progress",r.Callbacks("memory"),r.Callbacks("memory"),2],["resolve","done",r.Callbacks("once memory"),r.Callbacks("once memory"),0,"resolved"],["reject","fail",r.Callbacks("once memory"),r.Callbacks("once memory"),1,"rejected"]],d="pending",e={state:function(){return d},always:function(){return f.done(arguments).fail(arguments),this},"catch":function(a){return e.then(null,a)},pipe:function(){var a=arguments;return r.Deferred(function(b){r.each(c,function(c,d){var e=r.isFunction(a[d[4]])&&a[d[4]];f[d[1]](function(){var a=e&&e.apply(this,arguments);a&&r.isFunction(a.promise)?a.promise().progress(b.notify).done(b.resolve).fail(b.reject):b[d[0]+"With"](this,e?[a]:arguments)})}),a=null}).promise()},then:function(b,d,e){var f=0;function g(b,c,d,e){return function(){var h=this,i=arguments,j=function(){var a,j;if(!(b=f&&(d!==O&&(h=void 0,i=[a]),c.rejectWith(h,i))}};b?k():(r.Deferred.getStackHook&&(k.stackTrace=r.Deferred.getStackHook()),a.setTimeout(k))}}return r.Deferred(function(a){c[0][3].add(g(0,a,r.isFunction(e)?e:N,a.notifyWith)),c[1][3].add(g(0,a,r.isFunction(b)?b:N)),c[2][3].add(g(0,a,r.isFunction(d)?d:O))}).promise()},promise:function(a){return null!=a?r.extend(a,e):e}},f={};return r.each(c,function(a,b){var g=b[2],h=b[5];e[b[1]]=g.add,h&&g.add(function(){d=h},c[3-a][2].disable,c[0][2].lock),g.add(b[3].fire),f[b[0]]=function(){return f[b[0]+"With"](this===f?void 0:this,arguments),this},f[b[0]+"With"]=g.fireWith}),e.promise(f),b&&b.call(f,f),f},when:function(a){var b=arguments.length,c=b,d=Array(c),e=f.call(arguments),g=r.Deferred(),h=function(a){return function(c){d[a]=this,e[a]=arguments.length>1?f.call(arguments):c,--b||g.resolveWith(d,e)}};if(b<=1&&(P(a,g.done(h(c)).resolve,g.reject,!b),"pending"===g.state()||r.isFunction(e[c]&&e[c].then)))return g.then();while(c--)P(e[c],h(c),g.reject);return g.promise()}});var Q=/^(Eval|Internal|Range|Reference|Syntax|Type|URI)Error$/;r.Deferred.exceptionHook=function(b,c){a.console&&a.console.warn&&b&&Q.test(b.name)&&a.console.warn("jQuery.Deferred exception: "+b.message,b.stack,c)},r.readyException=function(b){a.setTimeout(function(){throw b})};var R=r.Deferred();r.fn.ready=function(a){return R.then(a)["catch"](function(a){r.readyException(a)}),this},r.extend({isReady:!1,readyWait:1,ready:function(a){(a===!0?--r.readyWait:r.isReady)||(r.isReady=!0,a!==!0&&--r.readyWait>0||R.resolveWith(d,[r]))}}),r.ready.then=R.then;function S(){d.removeEventListener("DOMContentLoaded",S), -a.removeEventListener("load",S),r.ready()}"complete"===d.readyState||"loading"!==d.readyState&&!d.documentElement.doScroll?a.setTimeout(r.ready):(d.addEventListener("DOMContentLoaded",S),a.addEventListener("load",S));var T=function(a,b,c,d,e,f,g){var h=0,i=a.length,j=null==c;if("object"===r.type(c)){e=!0;for(h in c)T(a,b,h,c[h],!0,f,g)}else if(void 0!==d&&(e=!0,r.isFunction(d)||(g=!0),j&&(g?(b.call(a,d),b=null):(j=b,b=function(a,b,c){return j.call(r(a),c)})),b))for(;h1,null,!0)},removeData:function(a){return this.each(function(){X.remove(this,a)})}}),r.extend({queue:function(a,b,c){var d;if(a)return b=(b||"fx")+"queue",d=W.get(a,b),c&&(!d||Array.isArray(c)?d=W.access(a,b,r.makeArray(c)):d.push(c)),d||[]},dequeue:function(a,b){b=b||"fx";var c=r.queue(a,b),d=c.length,e=c.shift(),f=r._queueHooks(a,b),g=function(){r.dequeue(a,b)};"inprogress"===e&&(e=c.shift(),d--),e&&("fx"===b&&c.unshift("inprogress"),delete f.stop,e.call(a,g,f)),!d&&f&&f.empty.fire()},_queueHooks:function(a,b){var c=b+"queueHooks";return W.get(a,c)||W.access(a,c,{empty:r.Callbacks("once memory").add(function(){W.remove(a,[b+"queue",c])})})}}),r.fn.extend({queue:function(a,b){var c=2;return"string"!=typeof a&&(b=a,a="fx",c--),arguments.length\x20\t\r\n\f]+)/i,la=/^$|\/(?:java|ecma)script/i,ma={option:[1,""],thead:[1,"","
"],col:[2,"","
"],tr:[2,"","
"],td:[3,"","
"],_default:[0,"",""]};ma.optgroup=ma.option,ma.tbody=ma.tfoot=ma.colgroup=ma.caption=ma.thead,ma.th=ma.td;function na(a,b){var c;return c="undefined"!=typeof a.getElementsByTagName?a.getElementsByTagName(b||"*"):"undefined"!=typeof a.querySelectorAll?a.querySelectorAll(b||"*"):[],void 0===b||b&&B(a,b)?r.merge([a],c):c}function oa(a,b){for(var c=0,d=a.length;c-1)e&&e.push(f);else if(j=r.contains(f.ownerDocument,f),g=na(l.appendChild(f),"script"),j&&oa(g),c){k=0;while(f=g[k++])la.test(f.type||"")&&c.push(f)}return l}!function(){var a=d.createDocumentFragment(),b=a.appendChild(d.createElement("div")),c=d.createElement("input");c.setAttribute("type","radio"),c.setAttribute("checked","checked"),c.setAttribute("name","t"),b.appendChild(c),o.checkClone=b.cloneNode(!0).cloneNode(!0).lastChild.checked,b.innerHTML="",o.noCloneChecked=!!b.cloneNode(!0).lastChild.defaultValue}();var ra=d.documentElement,sa=/^key/,ta=/^(?:mouse|pointer|contextmenu|drag|drop)|click/,ua=/^([^.]*)(?:\.(.+)|)/;function va(){return!0}function wa(){return!1}function xa(){try{return d.activeElement}catch(a){}}function ya(a,b,c,d,e,f){var g,h;if("object"==typeof b){"string"!=typeof c&&(d=d||c,c=void 0);for(h in b)ya(a,h,c,d,b[h],f);return a}if(null==d&&null==e?(e=c,d=c=void 0):null==e&&("string"==typeof c?(e=d,d=void 0):(e=d,d=c,c=void 0)),e===!1)e=wa;else if(!e)return a;return 1===f&&(g=e,e=function(a){return r().off(a),g.apply(this,arguments)},e.guid=g.guid||(g.guid=r.guid++)),a.each(function(){r.event.add(this,b,e,d,c)})}r.event={global:{},add:function(a,b,c,d,e){var f,g,h,i,j,k,l,m,n,o,p,q=W.get(a);if(q){c.handler&&(f=c,c=f.handler,e=f.selector),e&&r.find.matchesSelector(ra,e),c.guid||(c.guid=r.guid++),(i=q.events)||(i=q.events={}),(g=q.handle)||(g=q.handle=function(b){return"undefined"!=typeof r&&r.event.triggered!==b.type?r.event.dispatch.apply(a,arguments):void 0}),b=(b||"").match(L)||[""],j=b.length;while(j--)h=ua.exec(b[j])||[],n=p=h[1],o=(h[2]||"").split(".").sort(),n&&(l=r.event.special[n]||{},n=(e?l.delegateType:l.bindType)||n,l=r.event.special[n]||{},k=r.extend({type:n,origType:p,data:d,handler:c,guid:c.guid,selector:e,needsContext:e&&r.expr.match.needsContext.test(e),namespace:o.join(".")},f),(m=i[n])||(m=i[n]=[],m.delegateCount=0,l.setup&&l.setup.call(a,d,o,g)!==!1||a.addEventListener&&a.addEventListener(n,g)),l.add&&(l.add.call(a,k),k.handler.guid||(k.handler.guid=c.guid)),e?m.splice(m.delegateCount++,0,k):m.push(k),r.event.global[n]=!0)}},remove:function(a,b,c,d,e){var f,g,h,i,j,k,l,m,n,o,p,q=W.hasData(a)&&W.get(a);if(q&&(i=q.events)){b=(b||"").match(L)||[""],j=b.length;while(j--)if(h=ua.exec(b[j])||[],n=p=h[1],o=(h[2]||"").split(".").sort(),n){l=r.event.special[n]||{},n=(d?l.delegateType:l.bindType)||n,m=i[n]||[],h=h[2]&&new RegExp("(^|\\.)"+o.join("\\.(?:.*\\.|)")+"(\\.|$)"),g=f=m.length;while(f--)k=m[f],!e&&p!==k.origType||c&&c.guid!==k.guid||h&&!h.test(k.namespace)||d&&d!==k.selector&&("**"!==d||!k.selector)||(m.splice(f,1),k.selector&&m.delegateCount--,l.remove&&l.remove.call(a,k));g&&!m.length&&(l.teardown&&l.teardown.call(a,o,q.handle)!==!1||r.removeEvent(a,n,q.handle),delete i[n])}else for(n in i)r.event.remove(a,n+b[j],c,d,!0);r.isEmptyObject(i)&&W.remove(a,"handle events")}},dispatch:function(a){var b=r.event.fix(a),c,d,e,f,g,h,i=new Array(arguments.length),j=(W.get(this,"events")||{})[b.type]||[],k=r.event.special[b.type]||{};for(i[0]=b,c=1;c=1))for(;j!==this;j=j.parentNode||this)if(1===j.nodeType&&("click"!==a.type||j.disabled!==!0)){for(f=[],g={},c=0;c-1:r.find(e,this,null,[j]).length),g[e]&&f.push(d);f.length&&h.push({elem:j,handlers:f})}return j=this,i\x20\t\r\n\f]*)[^>]*)\/>/gi,Aa=/\s*$/g;function Ea(a,b){return B(a,"table")&&B(11!==b.nodeType?b:b.firstChild,"tr")?r(">tbody",a)[0]||a:a}function Fa(a){return a.type=(null!==a.getAttribute("type"))+"/"+a.type,a}function Ga(a){var b=Ca.exec(a.type);return b?a.type=b[1]:a.removeAttribute("type"),a}function Ha(a,b){var c,d,e,f,g,h,i,j;if(1===b.nodeType){if(W.hasData(a)&&(f=W.access(a),g=W.set(b,f),j=f.events)){delete g.handle,g.events={};for(e in j)for(c=0,d=j[e].length;c1&&"string"==typeof q&&!o.checkClone&&Ba.test(q))return a.each(function(e){var f=a.eq(e);s&&(b[0]=q.call(this,e,f.html())),Ja(f,b,c,d)});if(m&&(e=qa(b,a[0].ownerDocument,!1,a,d),f=e.firstChild,1===e.childNodes.length&&(e=f),f||d)){for(h=r.map(na(e,"script"),Fa),i=h.length;l")},clone:function(a,b,c){var d,e,f,g,h=a.cloneNode(!0),i=r.contains(a.ownerDocument,a);if(!(o.noCloneChecked||1!==a.nodeType&&11!==a.nodeType||r.isXMLDoc(a)))for(g=na(h),f=na(a),d=0,e=f.length;d0&&oa(g,!i&&na(a,"script")),h},cleanData:function(a){for(var b,c,d,e=r.event.special,f=0;void 0!==(c=a[f]);f++)if(U(c)){if(b=c[W.expando]){if(b.events)for(d in b.events)e[d]?r.event.remove(c,d):r.removeEvent(c,d,b.handle);c[W.expando]=void 0}c[X.expando]&&(c[X.expando]=void 0)}}}),r.fn.extend({detach:function(a){return Ka(this,a,!0)},remove:function(a){return Ka(this,a)},text:function(a){return T(this,function(a){return void 0===a?r.text(this):this.empty().each(function(){1!==this.nodeType&&11!==this.nodeType&&9!==this.nodeType||(this.textContent=a)})},null,a,arguments.length)},append:function(){return Ja(this,arguments,function(a){if(1===this.nodeType||11===this.nodeType||9===this.nodeType){var b=Ea(this,a);b.appendChild(a)}})},prepend:function(){return Ja(this,arguments,function(a){if(1===this.nodeType||11===this.nodeType||9===this.nodeType){var b=Ea(this,a);b.insertBefore(a,b.firstChild)}})},before:function(){return Ja(this,arguments,function(a){this.parentNode&&this.parentNode.insertBefore(a,this)})},after:function(){return Ja(this,arguments,function(a){this.parentNode&&this.parentNode.insertBefore(a,this.nextSibling)})},empty:function(){for(var a,b=0;null!=(a=this[b]);b++)1===a.nodeType&&(r.cleanData(na(a,!1)),a.textContent="");return this},clone:function(a,b){return a=null!=a&&a,b=null==b?a:b,this.map(function(){return r.clone(this,a,b)})},html:function(a){return T(this,function(a){var b=this[0]||{},c=0,d=this.length;if(void 0===a&&1===b.nodeType)return b.innerHTML;if("string"==typeof a&&!Aa.test(a)&&!ma[(ka.exec(a)||["",""])[1].toLowerCase()]){a=r.htmlPrefilter(a);try{for(;c1)}});function _a(a,b,c,d,e){return new _a.prototype.init(a,b,c,d,e)}r.Tween=_a,_a.prototype={constructor:_a,init:function(a,b,c,d,e,f){this.elem=a,this.prop=c,this.easing=e||r.easing._default,this.options=b,this.start=this.now=this.cur(),this.end=d,this.unit=f||(r.cssNumber[c]?"":"px")},cur:function(){var a=_a.propHooks[this.prop];return a&&a.get?a.get(this):_a.propHooks._default.get(this)},run:function(a){var b,c=_a.propHooks[this.prop];return this.options.duration?this.pos=b=r.easing[this.easing](a,this.options.duration*a,0,1,this.options.duration):this.pos=b=a,this.now=(this.end-this.start)*b+this.start,this.options.step&&this.options.step.call(this.elem,this.now,this),c&&c.set?c.set(this):_a.propHooks._default.set(this),this}},_a.prototype.init.prototype=_a.prototype,_a.propHooks={_default:{get:function(a){var b;return 1!==a.elem.nodeType||null!=a.elem[a.prop]&&null==a.elem.style[a.prop]?a.elem[a.prop]:(b=r.css(a.elem,a.prop,""),b&&"auto"!==b?b:0)},set:function(a){r.fx.step[a.prop]?r.fx.step[a.prop](a):1!==a.elem.nodeType||null==a.elem.style[r.cssProps[a.prop]]&&!r.cssHooks[a.prop]?a.elem[a.prop]=a.now:r.style(a.elem,a.prop,a.now+a.unit)}}},_a.propHooks.scrollTop=_a.propHooks.scrollLeft={set:function(a){a.elem.nodeType&&a.elem.parentNode&&(a.elem[a.prop]=a.now)}},r.easing={linear:function(a){return a},swing:function(a){return.5-Math.cos(a*Math.PI)/2},_default:"swing"},r.fx=_a.prototype.init,r.fx.step={};var ab,bb,cb=/^(?:toggle|show|hide)$/,db=/queueHooks$/;function eb(){bb&&(d.hidden===!1&&a.requestAnimationFrame?a.requestAnimationFrame(eb):a.setTimeout(eb,r.fx.interval),r.fx.tick())}function fb(){return a.setTimeout(function(){ab=void 0}),ab=r.now()}function gb(a,b){var c,d=0,e={height:a};for(b=b?1:0;d<4;d+=2-b)c=ca[d],e["margin"+c]=e["padding"+c]=a;return b&&(e.opacity=e.width=a),e}function hb(a,b,c){for(var d,e=(kb.tweeners[b]||[]).concat(kb.tweeners["*"]),f=0,g=e.length;f1)},removeAttr:function(a){return this.each(function(){r.removeAttr(this,a)})}}),r.extend({attr:function(a,b,c){var d,e,f=a.nodeType;if(3!==f&&8!==f&&2!==f)return"undefined"==typeof a.getAttribute?r.prop(a,b,c):(1===f&&r.isXMLDoc(a)||(e=r.attrHooks[b.toLowerCase()]||(r.expr.match.bool.test(b)?lb:void 0)),void 0!==c?null===c?void r.removeAttr(a,b):e&&"set"in e&&void 0!==(d=e.set(a,c,b))?d:(a.setAttribute(b,c+""),c):e&&"get"in e&&null!==(d=e.get(a,b))?d:(d=r.find.attr(a,b), -null==d?void 0:d))},attrHooks:{type:{set:function(a,b){if(!o.radioValue&&"radio"===b&&B(a,"input")){var c=a.value;return a.setAttribute("type",b),c&&(a.value=c),b}}}},removeAttr:function(a,b){var c,d=0,e=b&&b.match(L);if(e&&1===a.nodeType)while(c=e[d++])a.removeAttribute(c)}}),lb={set:function(a,b,c){return b===!1?r.removeAttr(a,c):a.setAttribute(c,c),c}},r.each(r.expr.match.bool.source.match(/\w+/g),function(a,b){var c=mb[b]||r.find.attr;mb[b]=function(a,b,d){var e,f,g=b.toLowerCase();return d||(f=mb[g],mb[g]=e,e=null!=c(a,b,d)?g:null,mb[g]=f),e}});var nb=/^(?:input|select|textarea|button)$/i,ob=/^(?:a|area)$/i;r.fn.extend({prop:function(a,b){return T(this,r.prop,a,b,arguments.length>1)},removeProp:function(a){return this.each(function(){delete this[r.propFix[a]||a]})}}),r.extend({prop:function(a,b,c){var d,e,f=a.nodeType;if(3!==f&&8!==f&&2!==f)return 1===f&&r.isXMLDoc(a)||(b=r.propFix[b]||b,e=r.propHooks[b]),void 0!==c?e&&"set"in e&&void 0!==(d=e.set(a,c,b))?d:a[b]=c:e&&"get"in e&&null!==(d=e.get(a,b))?d:a[b]},propHooks:{tabIndex:{get:function(a){var b=r.find.attr(a,"tabindex");return b?parseInt(b,10):nb.test(a.nodeName)||ob.test(a.nodeName)&&a.href?0:-1}}},propFix:{"for":"htmlFor","class":"className"}}),o.optSelected||(r.propHooks.selected={get:function(a){var b=a.parentNode;return b&&b.parentNode&&b.parentNode.selectedIndex,null},set:function(a){var b=a.parentNode;b&&(b.selectedIndex,b.parentNode&&b.parentNode.selectedIndex)}}),r.each(["tabIndex","readOnly","maxLength","cellSpacing","cellPadding","rowSpan","colSpan","useMap","frameBorder","contentEditable"],function(){r.propFix[this.toLowerCase()]=this});function pb(a){var b=a.match(L)||[];return b.join(" ")}function qb(a){return a.getAttribute&&a.getAttribute("class")||""}r.fn.extend({addClass:function(a){var b,c,d,e,f,g,h,i=0;if(r.isFunction(a))return this.each(function(b){r(this).addClass(a.call(this,b,qb(this)))});if("string"==typeof a&&a){b=a.match(L)||[];while(c=this[i++])if(e=qb(c),d=1===c.nodeType&&" "+pb(e)+" "){g=0;while(f=b[g++])d.indexOf(" "+f+" ")<0&&(d+=f+" ");h=pb(d),e!==h&&c.setAttribute("class",h)}}return this},removeClass:function(a){var b,c,d,e,f,g,h,i=0;if(r.isFunction(a))return this.each(function(b){r(this).removeClass(a.call(this,b,qb(this)))});if(!arguments.length)return this.attr("class","");if("string"==typeof a&&a){b=a.match(L)||[];while(c=this[i++])if(e=qb(c),d=1===c.nodeType&&" "+pb(e)+" "){g=0;while(f=b[g++])while(d.indexOf(" "+f+" ")>-1)d=d.replace(" "+f+" "," ");h=pb(d),e!==h&&c.setAttribute("class",h)}}return this},toggleClass:function(a,b){var c=typeof a;return"boolean"==typeof b&&"string"===c?b?this.addClass(a):this.removeClass(a):r.isFunction(a)?this.each(function(c){r(this).toggleClass(a.call(this,c,qb(this),b),b)}):this.each(function(){var b,d,e,f;if("string"===c){d=0,e=r(this),f=a.match(L)||[];while(b=f[d++])e.hasClass(b)?e.removeClass(b):e.addClass(b)}else void 0!==a&&"boolean"!==c||(b=qb(this),b&&W.set(this,"__className__",b),this.setAttribute&&this.setAttribute("class",b||a===!1?"":W.get(this,"__className__")||""))})},hasClass:function(a){var b,c,d=0;b=" "+a+" ";while(c=this[d++])if(1===c.nodeType&&(" "+pb(qb(c))+" ").indexOf(b)>-1)return!0;return!1}});var rb=/\r/g;r.fn.extend({val:function(a){var b,c,d,e=this[0];{if(arguments.length)return d=r.isFunction(a),this.each(function(c){var e;1===this.nodeType&&(e=d?a.call(this,c,r(this).val()):a,null==e?e="":"number"==typeof e?e+="":Array.isArray(e)&&(e=r.map(e,function(a){return null==a?"":a+""})),b=r.valHooks[this.type]||r.valHooks[this.nodeName.toLowerCase()],b&&"set"in b&&void 0!==b.set(this,e,"value")||(this.value=e))});if(e)return b=r.valHooks[e.type]||r.valHooks[e.nodeName.toLowerCase()],b&&"get"in b&&void 0!==(c=b.get(e,"value"))?c:(c=e.value,"string"==typeof c?c.replace(rb,""):null==c?"":c)}}}),r.extend({valHooks:{option:{get:function(a){var b=r.find.attr(a,"value");return null!=b?b:pb(r.text(a))}},select:{get:function(a){var b,c,d,e=a.options,f=a.selectedIndex,g="select-one"===a.type,h=g?null:[],i=g?f+1:e.length;for(d=f<0?i:g?f:0;d-1)&&(c=!0);return c||(a.selectedIndex=-1),f}}}}),r.each(["radio","checkbox"],function(){r.valHooks[this]={set:function(a,b){if(Array.isArray(b))return a.checked=r.inArray(r(a).val(),b)>-1}},o.checkOn||(r.valHooks[this].get=function(a){return null===a.getAttribute("value")?"on":a.value})});var sb=/^(?:focusinfocus|focusoutblur)$/;r.extend(r.event,{trigger:function(b,c,e,f){var g,h,i,j,k,m,n,o=[e||d],p=l.call(b,"type")?b.type:b,q=l.call(b,"namespace")?b.namespace.split("."):[];if(h=i=e=e||d,3!==e.nodeType&&8!==e.nodeType&&!sb.test(p+r.event.triggered)&&(p.indexOf(".")>-1&&(q=p.split("."),p=q.shift(),q.sort()),k=p.indexOf(":")<0&&"on"+p,b=b[r.expando]?b:new r.Event(p,"object"==typeof b&&b),b.isTrigger=f?2:3,b.namespace=q.join("."),b.rnamespace=b.namespace?new RegExp("(^|\\.)"+q.join("\\.(?:.*\\.|)")+"(\\.|$)"):null,b.result=void 0,b.target||(b.target=e),c=null==c?[b]:r.makeArray(c,[b]),n=r.event.special[p]||{},f||!n.trigger||n.trigger.apply(e,c)!==!1)){if(!f&&!n.noBubble&&!r.isWindow(e)){for(j=n.delegateType||p,sb.test(j+p)||(h=h.parentNode);h;h=h.parentNode)o.push(h),i=h;i===(e.ownerDocument||d)&&o.push(i.defaultView||i.parentWindow||a)}g=0;while((h=o[g++])&&!b.isPropagationStopped())b.type=g>1?j:n.bindType||p,m=(W.get(h,"events")||{})[b.type]&&W.get(h,"handle"),m&&m.apply(h,c),m=k&&h[k],m&&m.apply&&U(h)&&(b.result=m.apply(h,c),b.result===!1&&b.preventDefault());return b.type=p,f||b.isDefaultPrevented()||n._default&&n._default.apply(o.pop(),c)!==!1||!U(e)||k&&r.isFunction(e[p])&&!r.isWindow(e)&&(i=e[k],i&&(e[k]=null),r.event.triggered=p,e[p](),r.event.triggered=void 0,i&&(e[k]=i)),b.result}},simulate:function(a,b,c){var d=r.extend(new r.Event,c,{type:a,isSimulated:!0});r.event.trigger(d,null,b)}}),r.fn.extend({trigger:function(a,b){return this.each(function(){r.event.trigger(a,b,this)})},triggerHandler:function(a,b){var c=this[0];if(c)return r.event.trigger(a,b,c,!0)}}),r.each("blur focus focusin focusout resize scroll click dblclick mousedown mouseup mousemove mouseover mouseout mouseenter mouseleave change select submit keydown keypress keyup contextmenu".split(" "),function(a,b){r.fn[b]=function(a,c){return arguments.length>0?this.on(b,null,a,c):this.trigger(b)}}),r.fn.extend({hover:function(a,b){return this.mouseenter(a).mouseleave(b||a)}}),o.focusin="onfocusin"in a,o.focusin||r.each({focus:"focusin",blur:"focusout"},function(a,b){var c=function(a){r.event.simulate(b,a.target,r.event.fix(a))};r.event.special[b]={setup:function(){var d=this.ownerDocument||this,e=W.access(d,b);e||d.addEventListener(a,c,!0),W.access(d,b,(e||0)+1)},teardown:function(){var d=this.ownerDocument||this,e=W.access(d,b)-1;e?W.access(d,b,e):(d.removeEventListener(a,c,!0),W.remove(d,b))}}});var tb=a.location,ub=r.now(),vb=/\?/;r.parseXML=function(b){var c;if(!b||"string"!=typeof b)return null;try{c=(new a.DOMParser).parseFromString(b,"text/xml")}catch(d){c=void 0}return c&&!c.getElementsByTagName("parsererror").length||r.error("Invalid XML: "+b),c};var wb=/\[\]$/,xb=/\r?\n/g,yb=/^(?:submit|button|image|reset|file)$/i,zb=/^(?:input|select|textarea|keygen)/i;function Ab(a,b,c,d){var e;if(Array.isArray(b))r.each(b,function(b,e){c||wb.test(a)?d(a,e):Ab(a+"["+("object"==typeof e&&null!=e?b:"")+"]",e,c,d)});else if(c||"object"!==r.type(b))d(a,b);else for(e in b)Ab(a+"["+e+"]",b[e],c,d)}r.param=function(a,b){var c,d=[],e=function(a,b){var c=r.isFunction(b)?b():b;d[d.length]=encodeURIComponent(a)+"="+encodeURIComponent(null==c?"":c)};if(Array.isArray(a)||a.jquery&&!r.isPlainObject(a))r.each(a,function(){e(this.name,this.value)});else for(c in a)Ab(c,a[c],b,e);return d.join("&")},r.fn.extend({serialize:function(){return r.param(this.serializeArray())},serializeArray:function(){return this.map(function(){var a=r.prop(this,"elements");return a?r.makeArray(a):this}).filter(function(){var a=this.type;return this.name&&!r(this).is(":disabled")&&zb.test(this.nodeName)&&!yb.test(a)&&(this.checked||!ja.test(a))}).map(function(a,b){var c=r(this).val();return null==c?null:Array.isArray(c)?r.map(c,function(a){return{name:b.name,value:a.replace(xb,"\r\n")}}):{name:b.name,value:c.replace(xb,"\r\n")}}).get()}});var Bb=/%20/g,Cb=/#.*$/,Db=/([?&])_=[^&]*/,Eb=/^(.*?):[ \t]*([^\r\n]*)$/gm,Fb=/^(?:about|app|app-storage|.+-extension|file|res|widget):$/,Gb=/^(?:GET|HEAD)$/,Hb=/^\/\//,Ib={},Jb={},Kb="*/".concat("*"),Lb=d.createElement("a");Lb.href=tb.href;function Mb(a){return function(b,c){"string"!=typeof b&&(c=b,b="*");var d,e=0,f=b.toLowerCase().match(L)||[];if(r.isFunction(c))while(d=f[e++])"+"===d[0]?(d=d.slice(1)||"*",(a[d]=a[d]||[]).unshift(c)):(a[d]=a[d]||[]).push(c)}}function Nb(a,b,c,d){var e={},f=a===Jb;function g(h){var i;return e[h]=!0,r.each(a[h]||[],function(a,h){var j=h(b,c,d);return"string"!=typeof j||f||e[j]?f?!(i=j):void 0:(b.dataTypes.unshift(j),g(j),!1)}),i}return g(b.dataTypes[0])||!e["*"]&&g("*")}function Ob(a,b){var c,d,e=r.ajaxSettings.flatOptions||{};for(c in b)void 0!==b[c]&&((e[c]?a:d||(d={}))[c]=b[c]);return d&&r.extend(!0,a,d),a}function Pb(a,b,c){var d,e,f,g,h=a.contents,i=a.dataTypes;while("*"===i[0])i.shift(),void 0===d&&(d=a.mimeType||b.getResponseHeader("Content-Type"));if(d)for(e in h)if(h[e]&&h[e].test(d)){i.unshift(e);break}if(i[0]in c)f=i[0];else{for(e in c){if(!i[0]||a.converters[e+" "+i[0]]){f=e;break}g||(g=e)}f=f||g}if(f)return f!==i[0]&&i.unshift(f),c[f]}function Qb(a,b,c,d){var e,f,g,h,i,j={},k=a.dataTypes.slice();if(k[1])for(g in a.converters)j[g.toLowerCase()]=a.converters[g];f=k.shift();while(f)if(a.responseFields[f]&&(c[a.responseFields[f]]=b),!i&&d&&a.dataFilter&&(b=a.dataFilter(b,a.dataType)),i=f,f=k.shift())if("*"===f)f=i;else if("*"!==i&&i!==f){if(g=j[i+" "+f]||j["* "+f],!g)for(e in j)if(h=e.split(" "),h[1]===f&&(g=j[i+" "+h[0]]||j["* "+h[0]])){g===!0?g=j[e]:j[e]!==!0&&(f=h[0],k.unshift(h[1]));break}if(g!==!0)if(g&&a["throws"])b=g(b);else try{b=g(b)}catch(l){return{state:"parsererror",error:g?l:"No conversion from "+i+" to "+f}}}return{state:"success",data:b}}r.extend({active:0,lastModified:{},etag:{},ajaxSettings:{url:tb.href,type:"GET",isLocal:Fb.test(tb.protocol),global:!0,processData:!0,async:!0,contentType:"application/x-www-form-urlencoded; charset=UTF-8",accepts:{"*":Kb,text:"text/plain",html:"text/html",xml:"application/xml, text/xml",json:"application/json, text/javascript"},contents:{xml:/\bxml\b/,html:/\bhtml/,json:/\bjson\b/},responseFields:{xml:"responseXML",text:"responseText",json:"responseJSON"},converters:{"* text":String,"text html":!0,"text json":JSON.parse,"text xml":r.parseXML},flatOptions:{url:!0,context:!0}},ajaxSetup:function(a,b){return b?Ob(Ob(a,r.ajaxSettings),b):Ob(r.ajaxSettings,a)},ajaxPrefilter:Mb(Ib),ajaxTransport:Mb(Jb),ajax:function(b,c){"object"==typeof b&&(c=b,b=void 0),c=c||{};var e,f,g,h,i,j,k,l,m,n,o=r.ajaxSetup({},c),p=o.context||o,q=o.context&&(p.nodeType||p.jquery)?r(p):r.event,s=r.Deferred(),t=r.Callbacks("once memory"),u=o.statusCode||{},v={},w={},x="canceled",y={readyState:0,getResponseHeader:function(a){var b;if(k){if(!h){h={};while(b=Eb.exec(g))h[b[1].toLowerCase()]=b[2]}b=h[a.toLowerCase()]}return null==b?null:b},getAllResponseHeaders:function(){return k?g:null},setRequestHeader:function(a,b){return null==k&&(a=w[a.toLowerCase()]=w[a.toLowerCase()]||a,v[a]=b),this},overrideMimeType:function(a){return null==k&&(o.mimeType=a),this},statusCode:function(a){var b;if(a)if(k)y.always(a[y.status]);else for(b in a)u[b]=[u[b],a[b]];return this},abort:function(a){var b=a||x;return e&&e.abort(b),A(0,b),this}};if(s.promise(y),o.url=((b||o.url||tb.href)+"").replace(Hb,tb.protocol+"//"),o.type=c.method||c.type||o.method||o.type,o.dataTypes=(o.dataType||"*").toLowerCase().match(L)||[""],null==o.crossDomain){j=d.createElement("a");try{j.href=o.url,j.href=j.href,o.crossDomain=Lb.protocol+"//"+Lb.host!=j.protocol+"//"+j.host}catch(z){o.crossDomain=!0}}if(o.data&&o.processData&&"string"!=typeof o.data&&(o.data=r.param(o.data,o.traditional)),Nb(Ib,o,c,y),k)return y;l=r.event&&o.global,l&&0===r.active++&&r.event.trigger("ajaxStart"),o.type=o.type.toUpperCase(),o.hasContent=!Gb.test(o.type),f=o.url.replace(Cb,""),o.hasContent?o.data&&o.processData&&0===(o.contentType||"").indexOf("application/x-www-form-urlencoded")&&(o.data=o.data.replace(Bb,"+")):(n=o.url.slice(f.length),o.data&&(f+=(vb.test(f)?"&":"?")+o.data,delete o.data),o.cache===!1&&(f=f.replace(Db,"$1"),n=(vb.test(f)?"&":"?")+"_="+ub++ +n),o.url=f+n),o.ifModified&&(r.lastModified[f]&&y.setRequestHeader("If-Modified-Since",r.lastModified[f]),r.etag[f]&&y.setRequestHeader("If-None-Match",r.etag[f])),(o.data&&o.hasContent&&o.contentType!==!1||c.contentType)&&y.setRequestHeader("Content-Type",o.contentType),y.setRequestHeader("Accept",o.dataTypes[0]&&o.accepts[o.dataTypes[0]]?o.accepts[o.dataTypes[0]]+("*"!==o.dataTypes[0]?", "+Kb+"; q=0.01":""):o.accepts["*"]);for(m in o.headers)y.setRequestHeader(m,o.headers[m]);if(o.beforeSend&&(o.beforeSend.call(p,y,o)===!1||k))return y.abort();if(x="abort",t.add(o.complete),y.done(o.success),y.fail(o.error),e=Nb(Jb,o,c,y)){if(y.readyState=1,l&&q.trigger("ajaxSend",[y,o]),k)return y;o.async&&o.timeout>0&&(i=a.setTimeout(function(){y.abort("timeout")},o.timeout));try{k=!1,e.send(v,A)}catch(z){if(k)throw z;A(-1,z)}}else A(-1,"No Transport");function A(b,c,d,h){var j,m,n,v,w,x=c;k||(k=!0,i&&a.clearTimeout(i),e=void 0,g=h||"",y.readyState=b>0?4:0,j=b>=200&&b<300||304===b,d&&(v=Pb(o,y,d)),v=Qb(o,v,y,j),j?(o.ifModified&&(w=y.getResponseHeader("Last-Modified"),w&&(r.lastModified[f]=w),w=y.getResponseHeader("etag"),w&&(r.etag[f]=w)),204===b||"HEAD"===o.type?x="nocontent":304===b?x="notmodified":(x=v.state,m=v.data,n=v.error,j=!n)):(n=x,!b&&x||(x="error",b<0&&(b=0))),y.status=b,y.statusText=(c||x)+"",j?s.resolveWith(p,[m,x,y]):s.rejectWith(p,[y,x,n]),y.statusCode(u),u=void 0,l&&q.trigger(j?"ajaxSuccess":"ajaxError",[y,o,j?m:n]),t.fireWith(p,[y,x]),l&&(q.trigger("ajaxComplete",[y,o]),--r.active||r.event.trigger("ajaxStop")))}return y},getJSON:function(a,b,c){return r.get(a,b,c,"json")},getScript:function(a,b){return r.get(a,void 0,b,"script")}}),r.each(["get","post"],function(a,b){r[b]=function(a,c,d,e){return r.isFunction(c)&&(e=e||d,d=c,c=void 0),r.ajax(r.extend({url:a,type:b,dataType:e,data:c,success:d},r.isPlainObject(a)&&a))}}),r._evalUrl=function(a){return r.ajax({url:a,type:"GET",dataType:"script",cache:!0,async:!1,global:!1,"throws":!0})},r.fn.extend({wrapAll:function(a){var b;return this[0]&&(r.isFunction(a)&&(a=a.call(this[0])),b=r(a,this[0].ownerDocument).eq(0).clone(!0),this[0].parentNode&&b.insertBefore(this[0]),b.map(function(){var a=this;while(a.firstElementChild)a=a.firstElementChild;return a}).append(this)),this},wrapInner:function(a){return r.isFunction(a)?this.each(function(b){r(this).wrapInner(a.call(this,b))}):this.each(function(){var b=r(this),c=b.contents();c.length?c.wrapAll(a):b.append(a)})},wrap:function(a){var b=r.isFunction(a);return this.each(function(c){r(this).wrapAll(b?a.call(this,c):a)})},unwrap:function(a){return this.parent(a).not("body").each(function(){r(this).replaceWith(this.childNodes)}),this}}),r.expr.pseudos.hidden=function(a){return!r.expr.pseudos.visible(a)},r.expr.pseudos.visible=function(a){return!!(a.offsetWidth||a.offsetHeight||a.getClientRects().length)},r.ajaxSettings.xhr=function(){try{return new a.XMLHttpRequest}catch(b){}};var Rb={0:200,1223:204},Sb=r.ajaxSettings.xhr();o.cors=!!Sb&&"withCredentials"in Sb,o.ajax=Sb=!!Sb,r.ajaxTransport(function(b){var c,d;if(o.cors||Sb&&!b.crossDomain)return{send:function(e,f){var g,h=b.xhr();if(h.open(b.type,b.url,b.async,b.username,b.password),b.xhrFields)for(g in b.xhrFields)h[g]=b.xhrFields[g];b.mimeType&&h.overrideMimeType&&h.overrideMimeType(b.mimeType),b.crossDomain||e["X-Requested-With"]||(e["X-Requested-With"]="XMLHttpRequest");for(g in e)h.setRequestHeader(g,e[g]);c=function(a){return function(){c&&(c=d=h.onload=h.onerror=h.onabort=h.onreadystatechange=null,"abort"===a?h.abort():"error"===a?"number"!=typeof h.status?f(0,"error"):f(h.status,h.statusText):f(Rb[h.status]||h.status,h.statusText,"text"!==(h.responseType||"text")||"string"!=typeof h.responseText?{binary:h.response}:{text:h.responseText},h.getAllResponseHeaders()))}},h.onload=c(),d=h.onerror=c("error"),void 0!==h.onabort?h.onabort=d:h.onreadystatechange=function(){4===h.readyState&&a.setTimeout(function(){c&&d()})},c=c("abort");try{h.send(b.hasContent&&b.data||null)}catch(i){if(c)throw i}},abort:function(){c&&c()}}}),r.ajaxPrefilter(function(a){a.crossDomain&&(a.contents.script=!1)}),r.ajaxSetup({accepts:{script:"text/javascript, application/javascript, application/ecmascript, application/x-ecmascript"},contents:{script:/\b(?:java|ecma)script\b/},converters:{"text script":function(a){return r.globalEval(a),a}}}),r.ajaxPrefilter("script",function(a){void 0===a.cache&&(a.cache=!1),a.crossDomain&&(a.type="GET")}),r.ajaxTransport("script",function(a){if(a.crossDomain){var b,c;return{send:function(e,f){b=r("